From nobody Mon Feb 2 16:41:34 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BAE1A87CC; Mon, 2 Feb 2015 16:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jel45RCIUUYD; Mon, 2 Feb 2015 16:41:27 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF411A8747; Mon, 2 Feb 2015 16:41:27 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lj1so88925009pab.5; Mon, 02 Feb 2015 16:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:to; bh=q4bxXNftyFurDe9Z+uo5IUw8PrqEn4cHq2bt026qKT0=; b=a2jbckDtuCAOKeZgKtaoACu6wmChZVK6tc2ZHV/zNQzj9iIgEzntBOYkbmmqC1K3w0 a13wJuBxxqx9tRh4AXWtGdOjJ5hvfrHLC+ogdWMM80CI0JwFhXWoSF7kxxTTd3aMW1G7 D74s/AOsYPWqlsa/il2VjzS5rAsXCIN00L+tudRelrFruJ0iGhjfFDGjDdHmlmDqzd4b ZeQMrXAKK3w2Z0CqF1pfoLMy66i6mhb5JNJ7kLxAjV4lVwVzTZb0Aiob5Unz5BZpyy+A N+LsVuGPnzJwyUhVZgQbPtRPFmr5igkVGFmnqVv8mRHqohquACcSMCO63INJCkyKYfh7 JZ6g== X-Received: by 10.70.129.75 with SMTP id nu11mr893312pdb.151.1422924086753; Mon, 02 Feb 2015 16:41:26 -0800 (PST) Received: from [10.43.188.151] ([166.170.42.125]) by mx.google.com with ESMTPSA id oe5sm234906pbc.33.2015.02.02.16.41.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Feb 2015 16:41:26 -0800 (PST) From: Dino Farinacci Content-Type: multipart/alternative; boundary=Apple-Mail-2D7AF672-9752-4884-834F-6E9E205CDB42 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <5CD12478-B9AC-4ADC-9743-B4461CD88574@gmail.com> Date: Mon, 2 Feb 2015 16:41:22 -0800 References: <6F5149063CE40341BE7953160A93C5A0012526E4@eusaamb109.ericsson.se> To: LISP mailing list list , pim@ietf.org X-Mailer: iPhone Mail (12B466) Archived-At: Subject: [lisp] Fwd: [pim] PIM WG recharter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 00:41:31 -0000 --Apple-Mail-2D7AF672-9752-4884-834F-6E9E205CDB42 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Forwarding to the LISP WG mailing list.=20 Dino Begin forwarded message: > From: Mike McBride > Date: February 2, 2015 at 4:06:47 PM PST > To: "pim@ietf.org" > Subject: Re: [pim] PIM WG recharter >=20 > Thank you for the input on the recharter text. Very helpful. Below is the l= atest revision and the newest text is in red and encapsulated in *s. Hopeful= ly this clearly addresses concerns about potential land grabbing (again, goo= d bier folks, we like you, but don't want you, we hope you find a nice new h= ome) and yet allows mcast wg to be the catch all for the mcast protocol home= less. If you don't like certain wording please propose better text. We are h= oping to have consensus by end of this week. > =20 > thanks, > mike > =20 > Charter for Working Group > =20 > The standardization of PIM was completed with RFC 4601 within the PIM WG. T= he MCAST WG has determined there is additional work to be accomplished and i= s chartered to standardize extensions to RFC 4601 - Protocol Independent Mul= ticast Version 2 - Sparse Mode, along with extensions to PIM-SSM and PIM-BID= IR. These multicast extensions will involve reliability, resiliency, scalabi= lity, management, mobility and security. The MCAST WG will continue to work o= n developing the IGMP/MLD protocols as *required* to achieve the robustness n= eeded, particularly in mobile environments. > =20 > As other WGs determine that support for multicast in their domains require= s multicast specific extensions to PIM, IGMP/MLD, IGPs, or other yet to be i= nvented multicast specific protocols, then such extensions *and protocols* s= hould be developed within the MCAST WG *if they don't have a more relevant W= G home*. Additional work on existing PIM-BIDIR, BSR and SSM drafts may also b= e necessary by the WG as these drafts progress through Standards Track. > =20 > *The MCAST WG will be responsible for protocol development for both multic= ast overlays and underlays unless otherwise specified in another working gro= up. When multicast related specifications occur outside the MCAST WG, the MC= AST WG will provide advice as requested.* > =20 > The working group has produced MIB modules for PIM in RFC 5060 and RFC 524= 0. The MCAST WG will work on proposals that update or extend the existing MI= B modules and will develop YANG modules for multicast protocols. > =20 > The MCAST WG will further enhance RFC4601 as an even more scalable, effici= ent and robust multicast routing protocol, which is capable of supporting th= ousands of groups, different types of multicast applications, and all major u= nderlying layer-2 subnetwork technologies. We will accomplish these enhancem= ents by submitting drafts, to the IESG, involving reliable multicast, pim jo= in attributes and authentication. > =20 > There is a significant number of errata that need to be addressed in order= to advance RFC4601 to Internet Standard. The MCAST WG will correct the erra= ta and update RFC4601. > =20 > The working group will initiate a new re-chartering effort if it is determ= ined that a Version 3 of PIM is required. > =20 > =20 > =20 > -----Original Message----- > From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Mike McBride > Sent: Thursday, January 22, 2015 11:31 PM > To: pim@ietf.org > Subject: [pim] PIM WG recharter > =20 > Hello all, > =20 > Stig and I hope you had a wonderful start to your new year. > =20 > We hope to have a wonderful start for pim in 2015 as well. We've discussed= rechartering for the past year and Stig and I have made a first pass below.= Thanks to Bill Atwood and Lucy Yong in providing edits to this draft. Pleas= e review and comment on this proposed new charter and wg renaming. Through t= he MCAST WG (Protocols) and the MBONED WG (Operations) we should be able to m= ore effectively standardize multicast technologies. > =20 > Thanks, > mike > =20 > New: > =20 > Charter for Working Group > =20 > The standardization of PIM was completed with RFC 4601 within the PIM WG. T= he MCAST WG has determined there is additional work to be accomplished and i= s chartered to standardize extensions to RFC 4601 - Protocol Independent Mul= ticast Version 2 - Sparse Mode, along with extensions to PIM-SSM and PIM-BID= IR. These multicast extensions will involve reliability, resiliency, scalabi= lity, management, mobility and security. The MCAST WG will continue to work o= n developing the IGMP/MLD protocols as needed to achieve the robustness need= ed, particularly in mobile environments. > =20 > As other WGs determine that support for multicast in their domains require= s multicast specific extensions to PIM, IGMP/MLD, IGPs, or other yet to be i= nvented multicast specific protocols, then such extensions should be develop= ed within the MCAST WG. Additional work on existing PIM-BIDIR, BSR and SSM d= rafts may also be necessary by the WG as these drafts progress through Stand= ards Track. > =20 > The working group has produced MIB modules for PIM in RFC 5060 and RFC 524= 0. The MCAST WG will work on proposals that update or extend the existing MI= B modules and will develop YANG modules for multicast protocols. > =20 > The MCAST WG will further enhance RFC4601 as an even more scalable, effici= ent and robust multicast routing protocol, which is capable of supporting th= ousands of groups, different types of multicast applications, and all major u= nderlying layer-2 subnetwork technologies. We will accomplish these enhancem= ents by submitting drafts, to the IESG, involving reliable multicast, pim jo= in attributes and authentication. > =20 > There is a significant number of errata that need to be addressed in order= to advance RFC4601 to Internet Standard. The MCAST WG will correct the erra= ta and update RFC4601. > =20 > The working group will initiate a new re-chartering effort if it is determ= ined that a Version 3 of PIM is required. > =20 > Current: > =20 > Charter for Working Group > =20 > The Protocol Independent Multicast (PIM) Working Group has completed the s= tandardization of PIM with RFC 4601. The WG has determined there is addition= al work to be accomplished and is chartered to standardize extensions to RFC= 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM ex= tensions will involve reliability, resiliency, scalability, management, and s= ecurity. > =20 > If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/o= r L3VPNs requires extensions to PIM, then such extensions will be developed w= ithin the PIM WG. > =20 > Additional work on the PIM-BIDIR and BSR drafts may also be necessary by t= he WG as these drafts progress through Standards Track. > =20 > The working group has produced MIB modules for PIM in RFC 5060 and RFC 524= 0. The working group currently has no plans to do further work on management= for PIM. If proposals are brought forward to update or extend the existing M= IB modules or to develop YANG modules, the working group will be rechartered= . > =20 > The PIM WG will further enhance RFC4601 as an even more scalable, efficien= t and robust multicast routing protocol, which is capable of supporting thou= sands of groups, different types of multicast applications, and all major un= derlying layer-2 subnetwork technologies. > We will accomplish these enhancements by submitting drafts, to the IESG, i= nvolving reliable pim, pim join attributes and pim authentication. > =20 > The working group primarily works on extensions to PIM, but may take on wo= rk related to IGMP/MLD. > =20 > There is a significant number of errata that need to be addressed in order= to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, a= s necessary, and update RFC4601. > =20 > The working group will initiate a new re-chartering effort if it is determ= ined that a Version 3 of PIM is required. > =20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > =20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim --Apple-Mail-2D7AF672-9752-4884-834F-6E9E205CDB42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Forwarding to the LISP WG mailing list. 

Dino


Begin forwarded message:

From: Mike McBride <mike.mcbride@ericsson.com>
Date: February 2, 2015 at 4:06:47 PM PST
To: "pim@ietf.org" <pim@ietf.org>
Subject: Re: [pim] PIM WG recharter

Thank you for the input on the recharter text. Very helpful. Below is the latest revision and the newest text is in red and encapsulated in *s. Hopefully this clearly addresses concerns about potential land grabbing (again, good bier folks, we like you, but don't want you, we hope you find a nice new home) and yet allows mcast wg to be the catch all for the mcast protocol homeless. If you don't like certain wording please propose better text. We are hoping to have consensus by end of this week.
 
thanks,
mike
 
Charter for Working Group
 
The standardization of PIM was completed with RFC 4601 within the PIM WG. The MCAST WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode, along with extensions to PIM-SSM and PIM-BIDIR. These multicast extensions will involve reliability, resiliency, scalability, management, mobility and security. The MCAST WG will continue to work on developing the IGMP/MLD protocols as *required* to achieve the robustness needed, particularly in mobile environments.
 
As other WGs determine that support for multicast in their domains requires multicast specific extensions to PIM, IGMP/MLD, IGPs, or other yet to be invented multicast specific protocols, then such extensions *and protocols* should be developed within the MCAST WG *if they don't have a more relevant WG home*. Additional work on existing PIM-BIDIR, BSR and SSM drafts may also be necessary by the WG as these drafts progress through Standards Track.
 
*The MCAST WG will be responsible for protocol development for both multicast overlays and underlays unless otherwise specified in another working group. When multicast related specifications occur outside the MCAST WG, the MCAST WG will provide advice as requested.*
 
The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The MCAST WG will work on proposals that update or extend the existing MIB modules and will develop YANG modules for multicast protocols.
 
The MCAST WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable multicast, pim join attributes and authentication.
 
There is a significant number of errata that need to be addressed in order to advance RFC4601 to Internet Standard. The MCAST WG will correct the errata and update RFC4601.
 
The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required.
 
 
 
-----Original Message-----
From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Mike McBride
Sent: Thursday, January 22, 2015 11:31 PM
To: pim@ietf.org
Subject: [pim] PIM WG recharter
 
Hello all,
 
Stig and I hope you had a wonderful start to your new year.
 
We hope to have a wonderful start for pim in 2015 as well. We've discussed rechartering for the past year and Stig and I have made a first pass below. Thanks to Bill Atwood and Lucy Yong in providing edits to this draft. Please review and comment on this proposed new charter and wg renaming. Through the MCAST WG (Protocols) and the MBONED WG (Operations) we should be able to more effectively standardize multicast technologies.
 
Thanks,
mike
 
New:
 
Charter for Working Group
 
The standardization of PIM was completed with RFC 4601 within the PIM WG. The MCAST WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode, along with extensions to PIM-SSM and PIM-BIDIR. These multicast extensions will involve reliability, resiliency, scalability, management, mobility and security. The MCAST WG will continue to work on developing the IGMP/MLD protocols as needed to achieve the robustness needed, particularly in mobile environments.
 
As other WGs determine that support for multicast in their domains requires multicast specific extensions to PIM, IGMP/MLD, IGPs, or other yet to be invented multicast specific protocols, then such extensions should be developed within the MCAST WG. Additional work on existing PIM-BIDIR, BSR and SSM drafts may also be necessary by the WG as these drafts progress through Standards Track.
 
The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The MCAST WG will work on proposals that update or extend the existing MIB modules and will develop YANG modules for multicast protocols.
 
The MCAST WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable multicast, pim join attributes and authentication.
 
There is a significant number of errata that need to be addressed in order to advance RFC4601 to Internet Standard. The MCAST WG will correct the errata and update RFC4601.
 
The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required.
 
Current:
 
Charter for Working Group
 
The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security.
 
If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions will be developed within the PIM WG.
 
Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track.
 
The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The working group currently has no plans to do further work on management for PIM. If proposals are brought forward to update or extend the existing MIB modules or to develop YANG modules, the working group will be rechartered.
 
The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies.
We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication.
 
The working group primarily works on extensions to PIM, but may take on work related to IGMP/MLD.
 
There is a significant number of errata that need to be addressed in order to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, as necessary, and update RFC4601.
 
The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required.
 
_______________________________________________
pim mailing list
 
_______________________________________________
pim mailing list
pim@ietf.org
https://www.ietf.org/mailman/listinfo/pim
--Apple-Mail-2D7AF672-9752-4884-834F-6E9E205CDB42-- From nobody Tue Feb 3 08:53:12 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554471A1B04; Tue, 3 Feb 2015 08:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYgcnaqUaY7U; Tue, 3 Feb 2015 08:53:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A46D21A1B4F; Tue, 3 Feb 2015 08:53:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 290A118048B; Tue, 3 Feb 2015 08:52:47 -0800 (PST) To: kouvelas@cisco.com, gschudel@cisco.com, atjain@juniper.net, vimoreno@cisco.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150203165247.290A118048B@rfc-editor.org> Date: Tue, 3 Feb 2015 08:52:47 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, lisp@ietf.org Subject: [lisp] [Errata Verified] RFC7052 (4235) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:53:06 -0000 The following errata report has been verified for RFC7052, "Locator/ID Separation Protocol (LISP) MIB". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7052&eid=4235 -------------------------------------- Status: Verified Type: Technical Reported by: Isidor Kouvelas Date Reported: 2015-01-17 Verified by: Brian Haberman (IESG) Section: 7 Original Text ------------- Example 3: As an example where LCAF is used, suppose that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it is part of LISP Instance ID 101. In this case, the values within lispMapCacheEntry would be: lispMapCacheEidLength = 11 lispMapCacheEid = 16387, 7, 2, 101, 1, 192.0.2.0, 24 ... [skip] ... where 11 is the total length in octets of the next object (lispMapCacheEID of type LispAddressType). Then, the value 16387 indicates the LCAF AF (see the IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 7 indicates that the LCAF AF is 7 octets in length in this case, 2 indicates that LCAF Type 2 encoding is used (see the LCAF document), 101 gives the Instance ID, 1 gives the AFI (per the IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0 is the IPv4 address, and 24 is the mask-length in bits. Note that the lispMapCacheEidLength value of 11 octets is used to compute the length of the last field in lispMapCacheEid to be 1 octet -- as computed by 11 - (2 + 1 + 1 + 1 + 1 + 4) = 1. Corrected Text -------------- Example 3: As an example where LCAF is used, suppose that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it is part of LISP Instance ID 101. In this case, the values within lispMapCacheEntry would be: lispMapCacheEidLength = 14 lispMapCacheEid = 16387, 10, 2, 101, 1, 192.0.2.0, 24 ... [skip] ... where 14 is the total length in octets of the next object (lispMapCacheEID of type LispAddressType). Then, the value 16387 indicates the LCAF AF (see the IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 10 indicates that the LCAF AF is 10 octets in length in this case, 2 indicates that LCAF Type 2 encoding is used (see the LCAF document), 101 gives the Instance ID, 1 gives the AFI (per the IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0 is the IPv4 address, and 24 is the mask-length in bits. Note that the lispMapCacheEidLength value of 14 octets is used to compute the length of the last field in lispMapCacheEid to be 1 octet -- as computed by 14 - (2 + 1 + 1 + 3 + 2 + 4) = 1. Notes ----- The Instance ID within the type 2 LCAF is 24 bits and requires 3 octets (incorrectly calculated as 1) The AFI within the LCAF type 2 requires 2 octets (incorrectly calculated as 1) -------------------------------------- RFC7052 (draft-ietf-lisp-mib-13) -------------------------------------- Title : Locator/ID Separation Protocol (LISP) MIB Publication Date : October 2013 Author(s) : G. Schudel, A. Jain, V. Moreno Category : EXPERIMENTAL Source : Locator/ID Separation Protocol Area : Internet Stream : IETF Verifying Party : IESG From nobody Wed Feb 4 00:10:40 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D304E1A7004; Wed, 4 Feb 2015 00:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0myOLWj0hirZ; Wed, 4 Feb 2015 00:10:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8557C1A6F2D; Wed, 4 Feb 2015 00:10:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, ggx@gigix.net, draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150204081031.15138.75465.idtracker@ietfa.amsl.com> Date: Wed, 04 Feb 2015 00:10:31 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [lisp] Last Call Expired: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:10:33 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Wed Feb 4 01:24:37 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACED41A86F5 for ; Wed, 4 Feb 2015 01:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8anrLFkOD1Ss for ; Wed, 4 Feb 2015 01:24:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 674A11A86EF for ; Wed, 4 Feb 2015 01:24:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B7DE3180092; Wed, 4 Feb 2015 01:24:19 -0800 (PST) To: gschudel@cisco.com, atjain@juniper.net, vimoreno@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, jmh@joelhalpern.com, ggx@gigix.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150204092419.B7DE3180092@rfc-editor.org> Date: Wed, 4 Feb 2015 01:24:19 -0800 (PST) Archived-At: Cc: lisp@ietf.org, rfc-editor@rfc-editor.org Subject: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 09:24:36 -0000 The following errata report has been submitted for RFC7052, "Locator/ID Separation Protocol (LISP) MIB". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7052&eid=4256 -------------------------------------- Type: Technical Reported by: Isidor Kouvelas Section: 7 Original Text ------------- REFERENCE "RFC 6830, Section 14.2 and LISP Canonical Address Format (LCAF), Work in Progress, March 2013." SYNTAX OCTET STRING (SIZE (5..39)) Corrected Text -------------- REFERENCE "RFC 6830, Section 14.2 and LISP Canonical Address Format (LCAF), Work in Progress, March 2013." SYNTAX OCTET STRING (SIZE (0..39)) Notes ----- The minimum octet string length of 5 specified for the LispAddressType is incorrect. The smallest non-empty address is an IPv4 address that is not using the LCAF format to include an instance ID. This requires 8 octets (see example 1 above keeping in mind that the AFI requires 2 octets). However, in many places in the MIB definition the LispAddressType is used as the type for attributes where “unspecified” is a valid return. For example in lispEidRegistrationLastRegisterSender, an EID prefix that is configured on a Map-Server may not have any active registrations. To encode the absence of an address the minimum length of zero should be allowed. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7052 (draft-ietf-lisp-mib-13) -------------------------------------- Title : Locator/ID Separation Protocol (LISP) MIB Publication Date : October 2013 Author(s) : G. Schudel, A. Jain, V. Moreno Category : EXPERIMENTAL Source : Locator/ID Separation Protocol Area : Internet Stream : IETF Verifying Party : IESG From nobody Thu Feb 5 14:58:04 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAE51A87C0 for ; Thu, 5 Feb 2015 14:57:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gD5wdW2rYlu for ; Thu, 5 Feb 2015 14:57:54 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 0AF3B1A8745 for ; Thu, 5 Feb 2015 14:57:54 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so2475865igd.4 for ; Thu, 05 Feb 2015 14:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TbgI1wh5J/DzVaOkE5DXlFPosMf6FxsDaQ1kELvPiyI=; b=Ve3HWwTSJC2MFwiOLd75NLf/cbsuYCqnkbluKN+XpYJHJOjjo4u9CQSuoBnbsnvkZX TaIhwiCgyVVCsgLz+egU0jK/4E5HqnQihr0+WWtAIC7hLHouQ2jJYQEaVtMHlnsPH5Oy saXrTEpZlzTpkOBwHD+v4RazwIVpnkvcJKkMusbBhgDr9Ig7+JEtV4VDtC6VVDrihdLb yIM1Z+NVyxn6mrYfuoMt/ecHAFI/nddeDYUrrqz1rBACq0iLwf656rEJ23Mws9XPXLnY t8rfZgaXkUVr6pr76scV8BZXzk6EEgPNZtp/PZkcJ8hT2tMpIqjLCZACcnEON76Yueek FczA== MIME-Version: 1.0 X-Received: by 10.50.18.49 with SMTP id t17mr1078846igd.3.1423177073200; Thu, 05 Feb 2015 14:57:53 -0800 (PST) Received: by 10.107.8.69 with HTTP; Thu, 5 Feb 2015 14:57:53 -0800 (PST) In-Reply-To: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> References: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> Date: Thu, 5 Feb 2015 23:57:53 +0100 Message-ID: From: Albert Cabellos To: Luigi Iannone Content-Type: multipart/alternative; boundary=089e0149c0a0e6d49e050e5f3b91 Archived-At: Cc: Joel Halpern Direct , Damien Saucez , LISP mailing list list Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-ddt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 22:57:56 -0000 --089e0149c0a0e6d49e050e5f3b91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all I read the draft and I think that it=C2=B4s ready for AD. Albert On Thu, Jan 29, 2015 at 4:36 PM, Luigi Iannone wrote: > Hi All, > > The authors of draft-ietf-lisp-ddt-02 > [http://tools.ietf.org/html/draft-ietf-lisp-ddt-02], > as well as several active WG participants, > requested the WG Last Call for this document. > > This email starts a 14 days WG Last Call, to end February 13th, 2015. > > Please review this WG document and let the WG know if you agree that it i= s > ready for handing to the AD. > If you have objections, please state your reasons why, and explain what i= t > would take to address your concerns. > > Thanks > > Luigi & Joel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --089e0149c0a0e6d49e050e5f3b91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all

I read the draft and I think tha= t it=C2=B4s ready for AD.

Albert

On Thu, Jan 29, 2015 at 4:3= 6 PM, Luigi Iannone <ggx@gigix.net> wrote:
Hi All,

The author= s of draft-ietf-lisp-ddt-02=C2=A0
as well as several active WG participant= s,
requested the WG Last Call for this document.

This email starts a 14 days WG Last Call, to end February 13th, 2015.
<= br>Please review this WG document and let the WG know if you agree that it = is ready for handing to the AD.
If you have objections, please st= ate your reasons why, and explain what it would take to address your concer= ns.

Thanks

Luigi & Jo= el

_____________________________________________= __
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp


--089e0149c0a0e6d49e050e5f3b91-- From nobody Thu Feb 5 15:11:50 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117D81A1B3E for ; Thu, 5 Feb 2015 15:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt6NY0fzGy1V for ; Thu, 5 Feb 2015 15:11:32 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4160A1A0397 for ; Thu, 5 Feb 2015 15:11:31 -0800 (PST) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id t15NBTFn001138; Fri, 6 Feb 2015 00:11:30 +0100 Received: from [10.61.81.30] (173-38-208-169.cisco.com [173.38.208.169]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id 9C9FB7D0; Fri, 6 Feb 2015 00:11:29 +0100 (CET) Message-ID: <54D3F8A0.9080706@ac.upc.edu> Date: Fri, 06 Feb 2015 00:11:28 +0100 From: Florin Coras User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lisp@ietf.org References: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-ddt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 23:11:37 -0000 I also support this document going into working group last call. Florin On 2/5/15 11:57 PM, Albert Cabellos wrote: > Hi all > > I read the draft and I think that its ready for AD. > > Albert > > On Thu, Jan 29, 2015 at 4:36 PM, Luigi Iannone > wrote: > > Hi All, > > The authors of draft-ietf-lisp-ddt-02 > [http://tools.ietf.org/html/draft-ietf-lisp-ddt-02], > as well as several active WG participants, > requested the WG Last Call for this document. > > This email starts a 14 days WG Last Call, to end February 13th, 2015. > > Please review this WG document and let the WG know if you agree > that it is ready for handing to the AD. > If you have objections, please state your reasons why, and explain > what it would take to address your concerns. > > Thanks > > Luigi & Joel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Feb 6 02:22:37 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF12F1A1B8F for ; Fri, 6 Feb 2015 02:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no60SP1XjwEF for ; Fri, 6 Feb 2015 02:22:29 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id BB8CD1A1B23 for ; Fri, 6 Feb 2015 02:22:28 -0800 (PST) Received: from gw-2.ac.upc.es (gw-2.ac.upc.es [147.83.30.8]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id t16AMReo019716 for ; Fri, 6 Feb 2015 11:22:27 +0100 Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) by gw-2.ac.upc.es (Postfix) with ESMTPSA id 1E02BB0 for ; Fri, 6 Feb 2015 11:22:27 +0100 (CET) Received: by mail-yh0-f51.google.com with SMTP id z6so5790863yhz.10 for ; Fri, 06 Feb 2015 02:22:25 -0800 (PST) X-Received: by 10.170.169.4 with SMTP id l4mr870364ykd.119.1423218145765; Fri, 06 Feb 2015 02:22:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.115.144 with HTTP; Fri, 6 Feb 2015 02:22:05 -0800 (PST) In-Reply-To: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> References: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> From: Alberto Rodriguez-Natal Date: Fri, 6 Feb 2015 11:22:05 +0100 Message-ID: To: LISP mailing list list Content-Type: multipart/alternative; boundary=001a113a0c34043024050e68cc57 Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-ddt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 10:22:32 -0000 --001a113a0c34043024050e68cc57 Content-Type: text/plain; charset=UTF-8 I've read the document and I believe it should be handled to the AD. Alberto On Thu, Jan 29, 2015 at 4:36 PM, Luigi Iannone wrote: > Hi All, > > The authors of draft-ietf-lisp-ddt-02 > [http://tools.ietf.org/html/draft-ietf-lisp-ddt-02], > as well as several active WG participants, > requested the WG Last Call for this document. > > This email starts a 14 days WG Last Call, to end February 13th, 2015. > > Please review this WG document and let the WG know if you agree that it is > ready for handing to the AD. > If you have objections, please state your reasons why, and explain what it > would take to address your concerns. > > Thanks > > Luigi & Joel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --001a113a0c34043024050e68cc57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've read the document and I believe it should be= handled to the AD.

Alberto

On Thu, Jan 29, 2015 at 4:36 PM, Luigi Ian= none <ggx@gigix.net> wrote:
Hi All,

The authors of draft-ietf-= lisp-ddt-02=C2=A0
as well as several active WG participants,
reque= sted the WG Last Call for this document.

This email star= ts a 14 days WG Last Call, to end February 13th, 2015.

Please review= this WG document and let the WG know if you agree that it is ready for han= ding to the AD.
If you have objections, please state your reasons= why, and explain what it would take to address your concerns.
Thanks

Luigi & Joel

_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp


--001a113a0c34043024050e68cc57-- From nobody Fri Feb 6 05:25:30 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8D1A1AAC for ; Fri, 6 Feb 2015 05:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFZMWbOocO0l for ; Fri, 6 Feb 2015 05:25:23 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C271A1A17 for ; Fri, 6 Feb 2015 05:25:23 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 043F0880E2; Fri, 6 Feb 2015 05:25:23 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2175C136829E; Fri, 6 Feb 2015 05:25:22 -0800 (PST) Message-ID: <54D4C0BB.3030906@innovationslab.net> Date: Fri, 06 Feb 2015 08:25:15 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: gschudel@cisco.com, atjain@juniper.net, vimoreno@cisco.com, ted.lemon@nominum.com, jmh@joelhalpern.com, ggx@gigix.net References: <20150204092419.B7DE3180092@rfc-editor.org> In-Reply-To: <20150204092419.B7DE3180092@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HgVWEWEwe2prun4wMSqdJno5KhnsgmaO6" Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 13:25:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HgVWEWEwe2prun4wMSqdJno5KhnsgmaO6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Isidor, I think we need to discuss this to really see if this is a problem. Can you give an example where the minimum length doesn't work? I looked through all instances of LispAddressType and would expect NULL entries to still have some info needed in the LispAddressType variable. Additionally, it appears that all instances of a mib variable of type LispAddressType has an associated length field that is also constrained to values (5..39). If the LispAddressType TC needed to be changed to (0..39), wouldn't all those length fields need to change as well? Regards, Brian On 2/4/15 4:24 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC7052, > "Locator/ID Separation Protocol (LISP) MIB". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7052&eid=3D4256 >=20 > -------------------------------------- > Type: Technical > Reported by: Isidor Kouvelas >=20 > Section: 7 >=20 > Original Text > ------------- > REFERENCE > "RFC 6830, Section 14.2 and > LISP Canonical Address Format (LCAF), Work in Progress, > March 2013." > SYNTAX OCTET STRING (SIZE (5..39)) >=20 >=20 > Corrected Text > -------------- > REFERENCE > "RFC 6830, Section 14.2 and > LISP Canonical Address Format (LCAF), Work in Progress, > March 2013." > SYNTAX OCTET STRING (SIZE (0..39)) >=20 >=20 > Notes > ----- > The minimum octet string length of 5 specified for the LispAddressType = is incorrect. The smallest non-empty address is an IPv4 address that is n= ot using the LCAF format to include an instance ID. This requires 8 octet= s (see example 1 above keeping in mind that the AFI requires 2 octets). H= owever, in many places in the MIB definition the LispAddressType is used = as the type for attributes where =C3=A2=E2=82=AC=C5=93unspecified=C3=A2=E2= =82=AC=C2=9D is a valid return. For example in lispEidRegistrationLastReg= isterSender, an EID prefix that is configured on a Map-Server may not hav= e any active registrations. To encode the absence of an address the minim= um length of zero should be allowed. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7052 (draft-ietf-lisp-mib-13) > -------------------------------------- > Title : Locator/ID Separation Protocol (LISP) MIB > Publication Date : October 2013 > Author(s) : G. Schudel, A. Jain, V. Moreno > Category : EXPERIMENTAL > Source : Locator/ID Separation Protocol > Area : Internet > Stream : IETF > Verifying Party : IESG >=20 --HgVWEWEwe2prun4wMSqdJno5KhnsgmaO6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU1MDBAAoJEBOZRqCi7goq23MH/ij9F1FnmQWl5i08+T+DraZi uaHFFdAgjhZNaOa7xtH/W9BNJssJ2r/V2BZ4f2HBRoKUDbEWWodf8VZlGx/cQErD ty2TBTPzC2CyriiP1TE/6NP3hZtLRokTFOsMPQ7CaomgF+tKUzXgScLDapikvaWY VDo+zOOYwnhixjNbVQQKv3J7seWQUrJvcIlJGNp3J2gQOdsbwYRv/PMbpCFhpwUU 1CNxk0v7aRvGPBr30Da+NYcmUfDXJTCb2PuvZHIvf+Q0kWedpW+uS1BkMmzjExZB wPXgGDt9Psrq/U9QR5px84bG24WhJj3N0/ORUHn23gMq11pWJUnrqYh2FkZnw6k= =0n+f -----END PGP SIGNATURE----- --HgVWEWEwe2prun4wMSqdJno5KhnsgmaO6-- From nobody Fri Feb 6 06:51:26 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DBE1A1AE2 for ; Fri, 6 Feb 2015 06:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8mVLV8zIhA3 for ; Fri, 6 Feb 2015 06:51:17 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515D91A1AD0 for ; Fri, 6 Feb 2015 06:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5346; q=dns/txt; s=iport; t=1423234277; x=1424443877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kxPQd/Mu1ZZnBZNnPr5xWClSF5E+fJwLP+UxL2eoWyI=; b=VP1gFJ+Pcf4mZKNJynrhe/uGOvYvYucgbbdSK9lBphMzWRRi2E6jq891 TauXA5xOGTIFEMQgYkL+FFLwyAAPAi/G6YNbCYMEj9p9M1xYQqz/TpB76 hyYf0Ifvxzkc8EhjyTyDemyN2MagJMAXz+ivQdD0JbiN7cyi1RU6d17nP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwGAALU1FStJA2H/2dsb2JhbABAGoMGUloEgn29OYImhXECHH1DAQEBAQF9hAwBAQEDASMRRQULAgEGAhgCAiYCAgIwFRACBA4FiCUIDTeiJpxslX4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGLJ4MwB4JoLoETBYVSiUiJLIEXgwOOUiKCAg0PgVBvARGBMn4BAQE X-IronPort-AV: E=Sophos;i="5.09,529,1418083200"; d="scan'208";a="390909951" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP; 06 Feb 2015 14:51:16 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t16EpGjD016207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 14:51:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 08:51:16 -0600 From: "Isidoros Kouvelas (kouvelas)" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC7052 (4256) Thread-Index: AQHQQFxlnTg8pe7qO0ib4DaVqyuxIpzkBIuAgAAYCoA= Date: Fri, 6 Feb 2015 14:51:15 +0000 Message-ID: References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> In-Reply-To: <54D4C0BB.3030906@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.67] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:51:21 -0000 QnJpYW4sDQoNClllcyB5b3UgYXJlIHJpZ2h0LCB0aGUgbGVuZ3RoIGZpZWxkcyB0aGF0IGFyZSBw YWlyZWQgd2l0aCBlYWNoIHVzZSBvZiBMaXNwQWRkcmVzc1R5cGUgYWxzbyBoYXZlIHRvIGhhdmUg dGhlaXIgbWluaW11bSB2YWx1ZSBhZGp1c3RlZC4gQlRXIHRoZXNlIGxlbmd0aCBmaWVsZHMgYXJl IHJlZHVuZGFudCBhcyB0aGUgb2N0ZXQgc3RyaW5nIGVuY29kaW5nIGNvbnRhaW5zIHRoZSBsZW5n dGggc28gdGhlIHZhbHVlIGVuZHMgdXAgYmVpbmcgcmVwZWF0ZWQgaW4gdGhlIE9JRC4gWW91IGFy ZSBhbHNvIHJpZ2h0IHRoYXQgaW4gYWxsIGNhc2VzIHdoZXJlIHRoZSBMaXNwQWRkcmVzc1R5cGUg aXMgdXNlZCBhcyBwYXJ0IG9mIGEga2V5IGluIGEgdGFibGUsIHRoZSBhZGRyZXNzIGhhcyB0byBi ZSBzcGVjaWZpZWQgYW5kIHRoZXJlZm9yZSB0aGUgZW5mb3JjZWQgbWluaW11bSBsZW5ndGggaXMg bm90IGFuIGlzc3VlLiBUaGUgb25seSBjYXNlIEkgYmVsaWV2ZSB3aGVyZSB0aGUgdHlwZSBpcyB1 c2VkIGZvciBhbiBhdHRyaWJ1dGUgaXMgbGlzcEVpZFJlZ2lzdHJhdGlvbkxhc3RSZWdpc3RlclNl bmRlci4gQSBsaXNwRWlkUmVnaXN0cmF0aW9uRW50cnkgbWF5IGJlIGNvbmZpZ3VyZWQgb24gdGhl IE1hcC1TZXJ2ZXIgYnV0IG5vdCByZWdpc3RlcmVkIGJ5IGFuIHhUUiBpbiB3aGljaCBjYXNlIHRo ZSBsaXNwRWlkUmVnaXN0cmF0aW9uTGFzdFJlZ2lzdGVyU2VuZGVyIHdpbGwgYmUgdW5zcGVjaWZp ZWQuDQoNCnJlZ2FyZHMNCklzaWRvcg0KDQpPbiBGZWIgNiwgMjAxNSwgYXQgMTU6MjUsIEJyaWFu IEhhYmVybWFuIDxicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ+IHdyb3RlOg0KDQo+IEhpIElzaWRv ciwNCj4gICAgIEkgdGhpbmsgd2UgbmVlZCB0byBkaXNjdXNzIHRoaXMgdG8gcmVhbGx5IHNlZSBp ZiB0aGlzIGlzIGEgcHJvYmxlbS4NCj4gQ2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUgd2hlcmUgdGhl IG1pbmltdW0gbGVuZ3RoIGRvZXNuJ3Qgd29yaz8gIEkNCj4gbG9va2VkIHRocm91Z2ggYWxsIGlu c3RhbmNlcyBvZiBMaXNwQWRkcmVzc1R5cGUgYW5kIHdvdWxkIGV4cGVjdCBOVUxMDQo+IGVudHJp ZXMgdG8gc3RpbGwgaGF2ZSBzb21lIGluZm8gbmVlZGVkIGluIHRoZSBMaXNwQWRkcmVzc1R5cGUg dmFyaWFibGUuDQo+IEFkZGl0aW9uYWxseSwgaXQgYXBwZWFycyB0aGF0IGFsbCBpbnN0YW5jZXMg b2YgYSBtaWIgdmFyaWFibGUgb2YgdHlwZQ0KPiBMaXNwQWRkcmVzc1R5cGUgaGFzIGFuIGFzc29j aWF0ZWQgbGVuZ3RoIGZpZWxkIHRoYXQgaXMgYWxzbyBjb25zdHJhaW5lZA0KPiB0byB2YWx1ZXMg KDUuLjM5KS4gIElmIHRoZSBMaXNwQWRkcmVzc1R5cGUgVEMgbmVlZGVkIHRvIGJlIGNoYW5nZWQg dG8NCj4gKDAuLjM5KSwgd291bGRuJ3QgYWxsIHRob3NlIGxlbmd0aCBmaWVsZHMgbmVlZCB0byBj aGFuZ2UgYXMgd2VsbD8NCj4gDQo+IFJlZ2FyZHMsDQo+IEJyaWFuDQo+IA0KPiBPbiAyLzQvMTUg NDoyNCBBTSwgUkZDIEVycmF0YSBTeXN0ZW0gd3JvdGU6DQo+PiBUaGUgZm9sbG93aW5nIGVycmF0 YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM3MDUyLA0KPj4gIkxvY2F0b3IvSUQg U2VwYXJhdGlvbiBQcm90b2NvbCAoTElTUCkgTUlCIi4NCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVs b3cgYW5kIGF0Og0KPj4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBo cD9yZmM9NzA1MiZlaWQ9NDI1Ng0KPj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4gVHlwZTogVGVjaG5pY2FsDQo+PiBSZXBvcnRlZCBieTogSXNpZG9yIEtv dXZlbGFzIDxrb3V2ZWxhc0BjaXNjby5jb20+DQo+PiANCj4+IFNlY3Rpb246IDcNCj4+IA0KPj4g T3JpZ2luYWwgVGV4dA0KPj4gLS0tLS0tLS0tLS0tLQ0KPj4gICAgUkVGRVJFTkNFDQo+PiAgICAg ICAgIlJGQyA2ODMwLCBTZWN0aW9uIDE0LjIgYW5kDQo+PiAgICAgICAgIExJU1AgQ2Fub25pY2Fs IEFkZHJlc3MgRm9ybWF0IChMQ0FGKSwgV29yayBpbiBQcm9ncmVzcywNCj4+ICAgICAgICAgTWFy Y2ggMjAxMy4iDQo+PiAgICBTWU5UQVggT0NURVQgU1RSSU5HIChTSVpFICg1Li4zOSkpDQo+PiAN Cj4+IA0KPj4gQ29ycmVjdGVkIFRleHQNCj4+IC0tLS0tLS0tLS0tLS0tDQo+PiAgICBSRUZFUkVO Q0UNCj4+ICAgICAgICAiUkZDIDY4MzAsIFNlY3Rpb24gMTQuMiBhbmQNCj4+ICAgICAgICAgTElT UCBDYW5vbmljYWwgQWRkcmVzcyBGb3JtYXQgKExDQUYpLCBXb3JrIGluIFByb2dyZXNzLA0KPj4g ICAgICAgICBNYXJjaCAyMDEzLiINCj4+ICAgIFNZTlRBWCBPQ1RFVCBTVFJJTkcgKFNJWkUgKDAu LjM5KSkNCj4+IA0KPj4gDQo+PiBOb3Rlcw0KPj4gLS0tLS0NCj4+IFRoZSBtaW5pbXVtIG9jdGV0 IHN0cmluZyBsZW5ndGggb2YgNSBzcGVjaWZpZWQgZm9yIHRoZSBMaXNwQWRkcmVzc1R5cGUgaXMg aW5jb3JyZWN0LiBUaGUgc21hbGxlc3Qgbm9uLWVtcHR5IGFkZHJlc3MgaXMgYW4gSVB2NCBhZGRy ZXNzIHRoYXQgaXMgbm90IHVzaW5nIHRoZSBMQ0FGIGZvcm1hdCB0byBpbmNsdWRlIGFuIGluc3Rh bmNlIElELiBUaGlzIHJlcXVpcmVzIDggb2N0ZXRzIChzZWUgZXhhbXBsZSAxIGFib3ZlIGtlZXBp bmcgaW4gbWluZCB0aGF0IHRoZSBBRkkgcmVxdWlyZXMgMiBvY3RldHMpLiBIb3dldmVyLCBpbiBt YW55IHBsYWNlcyBpbiB0aGUgTUlCIGRlZmluaXRpb24gdGhlIExpc3BBZGRyZXNzVHlwZSBpcyB1 c2VkIGFzIHRoZSB0eXBlIGZvciBhdHRyaWJ1dGVzIHdoZXJlIMOi4oKsxZN1bnNwZWNpZmllZMOi 4oKswp0gaXMgYSB2YWxpZCByZXR1cm4uIEZvciBleGFtcGxlIGluIGxpc3BFaWRSZWdpc3RyYXRp b25MYXN0UmVnaXN0ZXJTZW5kZXIsIGFuIEVJRCBwcmVmaXggdGhhdCBpcyBjb25maWd1cmVkIG9u IGEgTWFwLVNlcnZlciBtYXkgbm90IGhhdmUgYW55IGFjdGl2ZSByZWdpc3RyYXRpb25zLiBUbyBl bmNvZGUgdGhlIGFic2VuY2Ugb2YgYW4gYWRkcmVzcyB0aGUgbWluaW11bSBsZW5ndGggb2YgemVy byBzaG91bGQgYmUgYWxsb3dlZC4NCj4+IA0KPj4gSW5zdHJ1Y3Rpb25zOg0KPj4gLS0tLS0tLS0t LS0tLQ0KPj4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4g SWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj4+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRo ZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yDQo+PiByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9u IGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cpDQo+PiBjYW4gbG9nIGluIHRv IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4gDQo+ PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBSRkM3MDUy IChkcmFmdC1pZXRmLWxpc3AtbWliLTEzKQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+IFRpdGxlICAgICAgICAgICAgICAgOiBMb2NhdG9yL0lEIFNlcGFyYXRp b24gUHJvdG9jb2wgKExJU1ApIE1JQg0KPj4gUHVibGljYXRpb24gRGF0ZSAgICA6IE9jdG9iZXIg MjAxMw0KPj4gQXV0aG9yKHMpICAgICAgICAgICA6IEcuIFNjaHVkZWwsIEEuIEphaW4sIFYuIE1v cmVubw0KPj4gQ2F0ZWdvcnkgICAgICAgICAgICA6IEVYUEVSSU1FTlRBTA0KPj4gU291cmNlICAg ICAgICAgICAgICA6IExvY2F0b3IvSUQgU2VwYXJhdGlvbiBQcm90b2NvbA0KPj4gQXJlYSAgICAg ICAgICAgICAgICA6IEludGVybmV0DQo+PiBTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPj4g VmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCg0K From nobody Fri Feb 6 07:06:50 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3D1A1B2D for ; Fri, 6 Feb 2015 07:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geeyAgJCIaje for ; Fri, 6 Feb 2015 07:06:45 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3691A1B2B for ; Fri, 6 Feb 2015 07:06:45 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 483AE880F4; Fri, 6 Feb 2015 07:06:45 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 84D6413682A3; Fri, 6 Feb 2015 07:06:44 -0800 (PST) Message-ID: <54D4D87E.7060807@innovationslab.net> Date: Fri, 06 Feb 2015 10:06:38 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Isidoros Kouvelas (kouvelas)" References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AnL9j2CviLDa28pMewvKvclvuHmdcFuAu" Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:06:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AnL9j2CviLDa28pMewvKvclvuHmdcFuAu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Isidor, I agree that the length fields are redundant, but vaguely remember during the MIB development someone indicating why they thought they were useful. The description of lispEidRegistrationLastRegisterSender doesn't indicate a scenario where it could be unspecified. If it is configured on the Map Server, would it make sense to use an address from the Map Server for the sender? Another option would be to encode a special IP address (255.255.255.255 or 0.0.0.0) as the unspecified addres= s. I am concerned that the level of churn in the MIB of changing 13 length constraints may be high and the length field was a discussion during the consensus call on the document. Do others have an opinion? Regards, Brian On 2/6/15 9:51 AM, Isidoros Kouvelas (kouvelas) wrote: > Brian, >=20 > Yes you are right, the length fields that are paired with each use of > LispAddressType also have to have their minimum value adjusted. BTW > these length fields are redundant as the octet string encoding > contains the length so the value ends up being repeated in the OID. > You are also right that in all cases where the LispAddressType is > used as part of a key in a table, the address has to be specified and > therefore the enforced minimum length is not an issue. The only case > I believe where the type is used for an attribute is > lispEidRegistrationLastRegisterSender. A lispEidRegistrationEntry may > be configured on the Map-Server but not registered by an xTR in which > case the lispEidRegistrationLastRegisterSender will be unspecified. >=20 > regards Isidor >=20 > On Feb 6, 2015, at 15:25, Brian Haberman > wrote: >=20 >> Hi Isidor, I think we need to discuss this to really see if this is >> a problem. Can you give an example where the minimum length doesn't >> work? I looked through all instances of LispAddressType and would >> expect NULL entries to still have some info needed in the >> LispAddressType variable. Additionally, it appears that all >> instances of a mib variable of type LispAddressType has an >> associated length field that is also constrained to values (5..39). >> If the LispAddressType TC needed to be changed to (0..39), wouldn't >> all those length fields need to change as well? >>=20 >> Regards, Brian >>=20 >> On 2/4/15 4:24 AM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC7052,=20 >>> "Locator/ID Separation Protocol (LISP) MIB". >>>=20 >>> -------------------------------------- You may review the report >>> below and at:=20 >>> http://www.rfc-editor.org/errata_search.php?rfc=3D7052&eid=3D4256 >>>=20 >>> -------------------------------------- Type: Technical Reported >>> by: Isidor Kouvelas >>>=20 >>> Section: 7 >>>=20 >>> Original Text ------------- REFERENCE "RFC 6830, Section 14.2 >>> and LISP Canonical Address Format (LCAF), Work in Progress, March >>> 2013." SYNTAX OCTET STRING (SIZE (5..39)) >>>=20 >>>=20 >>> Corrected Text -------------- REFERENCE "RFC 6830, Section 14.2 >>> and LISP Canonical Address Format (LCAF), Work in Progress, March >>> 2013." SYNTAX OCTET STRING (SIZE (0..39)) >>>=20 >>>=20 >>> Notes ----- The minimum octet string length of 5 specified for >>> the LispAddressType is incorrect. The smallest non-empty address >>> is an IPv4 address that is not using the LCAF format to include >>> an instance ID. This requires 8 octets (see example 1 above >>> keeping in mind that the AFI requires 2 octets). However, in many >>> places in the MIB definition the LispAddressType is used as the >>> type for attributes where =C3=A2=E2=82=AC=C5=93unspecified=C3=A2=E2=82= =AC=C2=9D is a valid return. >>> For example in lispEidRegistrationLastRegisterSender, an EID >>> prefix that is configured on a Map-Server may not have any active >>> registrations. To encode the absence of an address the minimum >>> length of zero should be allowed. >>>=20 >>> Instructions: ------------- This erratum is currently posted as >>> "Reported". If necessary, please use "Reply All" to discuss >>> whether it should be verified or rejected. When a decision is >>> reached, the verifying party (IESG) can log in to change the >>> status and edit the report, if necessary. >>>=20 >>> -------------------------------------- RFC7052 >>> (draft-ietf-lisp-mib-13) --------------------------------------=20 >>> Title : Locator/ID Separation Protocol (LISP) MIB=20 >>> Publication Date : October 2013 Author(s) : G. >>> Schudel, A. Jain, V. Moreno Category : EXPERIMENTAL=20 >>> Source : Locator/ID Separation Protocol Area >>> : Internet Stream : IETF Verifying Party : IESG >=20 --AnL9j2CviLDa28pMewvKvclvuHmdcFuAu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU1NiDAAoJEBOZRqCi7goqfqgIAIw0pls/SEqppvFfdvBwGKZ3 /DQV6GRqVEQLPQ7TIH/olLLYmmh1wlzHU3u2I+/qcSVsQfCWqRmqk8cYY/jaog2w /K6Cri321XtLBP8PbvdgtOKRXJLgUA2Pvc0uqxkfftjwynBSEfGGf6cNpH/T5SZY 0C2jLCqzt3NqX4xnBLXb+DnTqawCgf/nnR4OJiIvLuSv7np3YZ+fV+hDhTS0mvQB CuUYwD6XERmzPiyd7f4x8Am76hdh3wLXG9EjoSpf9a0xIcTy0uxmXS5PhprcgcAH wjcMyHc2I+5IbQ5gs7bF7LY+eBMqfMh07R3QJ0BliHDurl4WRte/UNuis9D1B5Q= =skxl -----END PGP SIGNATURE----- --AnL9j2CviLDa28pMewvKvclvuHmdcFuAu-- From nobody Fri Feb 6 07:19:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9B21A1B34 for ; Fri, 6 Feb 2015 07:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMwvtA9uNDCM for ; Fri, 6 Feb 2015 07:19:05 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1271A1B2C for ; Fri, 6 Feb 2015 07:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7908; q=dns/txt; s=iport; t=1423235945; x=1424445545; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IYok3cE5vgP7BUiCP4xlGblOioyYNApa3jVNXx47UF8=; b=cf2OUyyKM/OxbSpeblCQHpSYT5iemYtN3k6TvadrKY4vk7bAY4+JAFPY 7AdM8JIFfsQ1mcXi1t4HWxxrZBNQrjYgxK2uTLs2/UhpJKGM9FNnVjlxn OQHV5DDObu4VTBpPTJsGPkGbnX/yPag8QPVordiXlabknx+FbQFX6wrnr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BgCA2tRU/4sNJK1AGoMGUloEgn29OYImhXECHH1DAQEBAQF9hAwBAQEDASMRRQULAgEGAhgCAiYCAgIwFRACBA4FiCUIDTeiLJxslXwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGLJ4JZPBsHgmgugRMFhVKJSIksgReDA45SIoICDQ+BUG8BEXFBfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,529,1418083200"; d="scan'208";a="121171287" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 06 Feb 2015 15:19:04 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t16FJ4Oi010427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 15:19:04 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 09:19:04 -0600 From: "Isidoros Kouvelas (kouvelas)" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC7052 (4256) Thread-Index: AQHQQFxlnTg8pe7qO0ib4DaVqyuxIpzkBIuAgAAYCoCAAARKAIAAA3qA Date: Fri, 6 Feb 2015 15:19:03 +0000 Message-ID: References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> In-Reply-To: <54D4D87E.7060807@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.67] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:19:15 -0000 QnJpYW4sDQoNCkkgYW0gbm90IHN1cmUgd2hhdCB0aGUgbWluaW11bSBsZW5ndGggb2YgNSBjb3Vs ZCBjb3JyZXNwb25kIHRvIGdpdmVuIHRoZSBtaW5pbXVtIGxlbmd0aCBvZiBhbiBJUHY0IGFkZHJl c3Mgd2lsbCBiZSA4IG9jdGV0cyAoaW5jbHVkaW5nIHR3byBmb3IgQUZJLCBvbmUgZm9yIHRoZSBp bnRlcm5hbCBsZW5ndGggZmllbGQgYW5kIG9uZSBmb3IgdGhlIG1hc2sgbGVuZ3RoKS4gU28gSSB3 b3VsZCBiZSBpbnRlcmVzdGVkIGluIHRoZSBkaXNjdXNzaW9uIGNvbnRleHQgeW91IHJlZmVyIHRv Lg0KDQpSZWdhcmRpbmcgdGhlIHVuc3BlY2lmaWVkIGFkZHJlc3Mgc3BlY2lmaWNhdGlvbiBJIHRo aW5rIHRoYXQgbWFraW5nIGl0IGV4cGxpY2l0ICh6ZXJvIGxlbmd0aCkgd291bGQgYmUgY2xlYW5l ciB0aGFuIGVuY29kaW5nIGEgc3BlY2lhbCBhZGRyZXNzLiBUbyBsaW1pdCB0aGUgbnVtYmVyIG9m IGNoYW5nZXMgdG8gdGhlIE1JQiB3ZSBjb3VsZCBvbmx5IGZpeCB0aGUgTGlzcEFkZHJlc3NUeXBl IG9jdGV0IHN0cmluZyBkZWZpbml0aW9uIGFzIHdlbGwgYXMgbGlzcEVpZFJlZ2lzdHJhdGlvbkxh c3RSZWdpc3RlclNlbmRlckxlbmd0aC4NCg0KUmVnYXJkaW5nIHRoZSBleGFtcGxlIGJlbG93LCB0 aGUgbm9ybWFsIGNhc2UgaXMgdGhhdCBhbGwgRUlEIHByZWZpeGVzIGFyZSBjb25maWd1cmVkIG9u IHRoZSBNYXAtU2VydmVyIGFuZCB0aGVuIHJlZ2lzdGVyZWQgYnkgdGhlIHhUUnMuIFJlcG9ydGlu ZyB0aGUgTVMgYXMgdGhlIFJlZ2lzdGVyU2VuZGVyIG9mIHRoZSBFSUQgcHJlZml4ZXMgdGhhdCBo YXZlIG5vdCBiZWVuIHJlZ2lzdGVyZWQgd291bGQgbm90IHdvcmsuDQoNCnJlZ2FyZHMNCklzaWRv cg0KDQpPbiBGZWIgNiwgMjAxNSwgYXQgMTc6MDYsIEJyaWFuIEhhYmVybWFuIDxicmlhbkBpbm5v dmF0aW9uc2xhYi5uZXQ+IHdyb3RlOg0KDQo+IEhpIElzaWRvciwNCj4gICAgIEkgYWdyZWUgdGhh dCB0aGUgbGVuZ3RoIGZpZWxkcyBhcmUgcmVkdW5kYW50LCBidXQgdmFndWVseSByZW1lbWJlcg0K PiBkdXJpbmcgdGhlIE1JQiBkZXZlbG9wbWVudCBzb21lb25lIGluZGljYXRpbmcgd2h5IHRoZXkg dGhvdWdodCB0aGV5IHdlcmUNCj4gdXNlZnVsLiAgVGhlIGRlc2NyaXB0aW9uIG9mIGxpc3BFaWRS ZWdpc3RyYXRpb25MYXN0UmVnaXN0ZXJTZW5kZXINCj4gZG9lc24ndCBpbmRpY2F0ZSBhIHNjZW5h cmlvIHdoZXJlIGl0IGNvdWxkIGJlIHVuc3BlY2lmaWVkLiAgSWYgaXQgaXMNCj4gY29uZmlndXJl ZCBvbiB0aGUgTWFwIFNlcnZlciwgd291bGQgaXQgbWFrZSBzZW5zZSB0byB1c2UgYW4gYWRkcmVz cyBmcm9tDQo+IHRoZSBNYXAgU2VydmVyIGZvciB0aGUgc2VuZGVyPyBBbm90aGVyIG9wdGlvbiB3 b3VsZCBiZSB0byBlbmNvZGUgYQ0KPiBzcGVjaWFsIElQIGFkZHJlc3MgKDI1NS4yNTUuMjU1LjI1 NSBvciAwLjAuMC4wKSBhcyB0aGUgdW5zcGVjaWZpZWQgYWRkcmVzcy4NCj4gDQo+ICAgICBJIGFt IGNvbmNlcm5lZCB0aGF0IHRoZSBsZXZlbCBvZiBjaHVybiBpbiB0aGUgTUlCIG9mIGNoYW5naW5n IDEzDQo+IGxlbmd0aCBjb25zdHJhaW50cyBtYXkgYmUgaGlnaCBhbmQgdGhlIGxlbmd0aCBmaWVs ZCB3YXMgYSBkaXNjdXNzaW9uDQo+IGR1cmluZyB0aGUgY29uc2Vuc3VzIGNhbGwgb24gdGhlIGRv Y3VtZW50LiAgRG8gb3RoZXJzIGhhdmUgYW4gb3Bpbmlvbj8NCj4gDQo+IFJlZ2FyZHMsDQo+IEJy aWFuDQo+IA0KPiBPbiAyLzYvMTUgOTo1MSBBTSwgSXNpZG9yb3MgS291dmVsYXMgKGtvdXZlbGFz KSB3cm90ZToNCj4+IEJyaWFuLA0KPj4gDQo+PiBZZXMgeW91IGFyZSByaWdodCwgdGhlIGxlbmd0 aCBmaWVsZHMgdGhhdCBhcmUgcGFpcmVkIHdpdGggZWFjaCB1c2Ugb2YNCj4+IExpc3BBZGRyZXNz VHlwZSBhbHNvIGhhdmUgdG8gaGF2ZSB0aGVpciBtaW5pbXVtIHZhbHVlIGFkanVzdGVkLiBCVFcN Cj4+IHRoZXNlIGxlbmd0aCBmaWVsZHMgYXJlIHJlZHVuZGFudCBhcyB0aGUgb2N0ZXQgc3RyaW5n IGVuY29kaW5nDQo+PiBjb250YWlucyB0aGUgbGVuZ3RoIHNvIHRoZSB2YWx1ZSBlbmRzIHVwIGJl aW5nIHJlcGVhdGVkIGluIHRoZSBPSUQuDQo+PiBZb3UgYXJlIGFsc28gcmlnaHQgdGhhdCBpbiBh bGwgY2FzZXMgd2hlcmUgdGhlIExpc3BBZGRyZXNzVHlwZSBpcw0KPj4gdXNlZCBhcyBwYXJ0IG9m IGEga2V5IGluIGEgdGFibGUsIHRoZSBhZGRyZXNzIGhhcyB0byBiZSBzcGVjaWZpZWQgYW5kDQo+ PiB0aGVyZWZvcmUgdGhlIGVuZm9yY2VkIG1pbmltdW0gbGVuZ3RoIGlzIG5vdCBhbiBpc3N1ZS4g VGhlIG9ubHkgY2FzZQ0KPj4gSSBiZWxpZXZlIHdoZXJlIHRoZSB0eXBlIGlzIHVzZWQgZm9yIGFu IGF0dHJpYnV0ZSBpcw0KPj4gbGlzcEVpZFJlZ2lzdHJhdGlvbkxhc3RSZWdpc3RlclNlbmRlci4g QSBsaXNwRWlkUmVnaXN0cmF0aW9uRW50cnkgbWF5DQo+PiBiZSBjb25maWd1cmVkIG9uIHRoZSBN YXAtU2VydmVyIGJ1dCBub3QgcmVnaXN0ZXJlZCBieSBhbiB4VFIgaW4gd2hpY2gNCj4+IGNhc2Ug dGhlIGxpc3BFaWRSZWdpc3RyYXRpb25MYXN0UmVnaXN0ZXJTZW5kZXIgd2lsbCBiZSB1bnNwZWNp ZmllZC4NCj4+IA0KPj4gcmVnYXJkcyBJc2lkb3INCj4+IA0KPj4gT24gRmViIDYsIDIwMTUsIGF0 IDE1OjI1LCBCcmlhbiBIYWJlcm1hbiA8YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0Pg0KPj4gd3Jv dGU6DQo+PiANCj4+PiBIaSBJc2lkb3IsIEkgdGhpbmsgd2UgbmVlZCB0byBkaXNjdXNzIHRoaXMg dG8gcmVhbGx5IHNlZSBpZiB0aGlzIGlzDQo+Pj4gYSBwcm9ibGVtLiBDYW4geW91IGdpdmUgYW4g ZXhhbXBsZSB3aGVyZSB0aGUgbWluaW11bSBsZW5ndGggZG9lc24ndA0KPj4+IHdvcms/ICBJIGxv b2tlZCB0aHJvdWdoIGFsbCBpbnN0YW5jZXMgb2YgTGlzcEFkZHJlc3NUeXBlIGFuZCB3b3VsZA0K Pj4+IGV4cGVjdCBOVUxMIGVudHJpZXMgdG8gc3RpbGwgaGF2ZSBzb21lIGluZm8gbmVlZGVkIGlu IHRoZQ0KPj4+IExpc3BBZGRyZXNzVHlwZSB2YXJpYWJsZS4gQWRkaXRpb25hbGx5LCBpdCBhcHBl YXJzIHRoYXQgYWxsDQo+Pj4gaW5zdGFuY2VzIG9mIGEgbWliIHZhcmlhYmxlIG9mIHR5cGUgTGlz cEFkZHJlc3NUeXBlIGhhcyBhbg0KPj4+IGFzc29jaWF0ZWQgbGVuZ3RoIGZpZWxkIHRoYXQgaXMg YWxzbyBjb25zdHJhaW5lZCB0byB2YWx1ZXMgKDUuLjM5KS4NCj4+PiBJZiB0aGUgTGlzcEFkZHJl c3NUeXBlIFRDIG5lZWRlZCB0byBiZSBjaGFuZ2VkIHRvICgwLi4zOSksIHdvdWxkbid0DQo+Pj4g YWxsIHRob3NlIGxlbmd0aCBmaWVsZHMgbmVlZCB0byBjaGFuZ2UgYXMgd2VsbD8NCj4+PiANCj4+ PiBSZWdhcmRzLCBCcmlhbg0KPj4+IA0KPj4+IE9uIDIvNC8xNSA0OjI0IEFNLCBSRkMgRXJyYXRh IFN5c3RlbSB3cm90ZToNCj4+Pj4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVu IHN1Ym1pdHRlZCBmb3IgUkZDNzA1MiwgDQo+Pj4+ICJMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJv dG9jb2wgKExJU1ApIE1JQiIuDQo+Pj4+IA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0DQo+Pj4+IGJlbG93IGFuZCBh dDogDQo+Pj4+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZj PTcwNTImZWlkPTQyNTYNCj4+Pj4gDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tIFR5cGU6IFRlY2huaWNhbCBSZXBvcnRlZA0KPj4+PiBieTogSXNpZG9yIEtvdXZl bGFzIDxrb3V2ZWxhc0BjaXNjby5jb20+DQo+Pj4+IA0KPj4+PiBTZWN0aW9uOiA3DQo+Pj4+IA0K Pj4+PiBPcmlnaW5hbCBUZXh0IC0tLS0tLS0tLS0tLS0gUkVGRVJFTkNFICJSRkMgNjgzMCwgU2Vj dGlvbiAxNC4yDQo+Pj4+IGFuZCBMSVNQIENhbm9uaWNhbCBBZGRyZXNzIEZvcm1hdCAoTENBRiks IFdvcmsgaW4gUHJvZ3Jlc3MsIE1hcmNoDQo+Pj4+IDIwMTMuIiBTWU5UQVggT0NURVQgU1RSSU5H IChTSVpFICg1Li4zOSkpDQo+Pj4+IA0KPj4+PiANCj4+Pj4gQ29ycmVjdGVkIFRleHQgLS0tLS0t LS0tLS0tLS0gUkVGRVJFTkNFICJSRkMgNjgzMCwgU2VjdGlvbiAxNC4yDQo+Pj4+IGFuZCBMSVNQ IENhbm9uaWNhbCBBZGRyZXNzIEZvcm1hdCAoTENBRiksIFdvcmsgaW4gUHJvZ3Jlc3MsIE1hcmNo DQo+Pj4+IDIwMTMuIiBTWU5UQVggT0NURVQgU1RSSU5HIChTSVpFICgwLi4zOSkpDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gTm90ZXMgLS0tLS0gVGhlIG1pbmltdW0gb2N0ZXQgc3RyaW5nIGxlbmd0aCBv ZiA1IHNwZWNpZmllZCBmb3INCj4+Pj4gdGhlIExpc3BBZGRyZXNzVHlwZSBpcyBpbmNvcnJlY3Qu IFRoZSBzbWFsbGVzdCBub24tZW1wdHkgYWRkcmVzcw0KPj4+PiBpcyBhbiBJUHY0IGFkZHJlc3Mg dGhhdCBpcyBub3QgdXNpbmcgdGhlIExDQUYgZm9ybWF0IHRvIGluY2x1ZGUNCj4+Pj4gYW4gaW5z dGFuY2UgSUQuIFRoaXMgcmVxdWlyZXMgOCBvY3RldHMgKHNlZSBleGFtcGxlIDEgYWJvdmUNCj4+ Pj4ga2VlcGluZyBpbiBtaW5kIHRoYXQgdGhlIEFGSSByZXF1aXJlcyAyIG9jdGV0cykuIEhvd2V2 ZXIsIGluIG1hbnkNCj4+Pj4gcGxhY2VzIGluIHRoZSBNSUIgZGVmaW5pdGlvbiB0aGUgTGlzcEFk ZHJlc3NUeXBlIGlzIHVzZWQgYXMgdGhlDQo+Pj4+IHR5cGUgZm9yIGF0dHJpYnV0ZXMgd2hlcmUg w6LigqzFk3Vuc3BlY2lmaWVkw6LigqzCnSBpcyBhIHZhbGlkIHJldHVybi4NCj4+Pj4gRm9yIGV4 YW1wbGUgaW4gbGlzcEVpZFJlZ2lzdHJhdGlvbkxhc3RSZWdpc3RlclNlbmRlciwgYW4gRUlEDQo+ Pj4+IHByZWZpeCB0aGF0IGlzIGNvbmZpZ3VyZWQgb24gYSBNYXAtU2VydmVyIG1heSBub3QgaGF2 ZSBhbnkgYWN0aXZlDQo+Pj4+IHJlZ2lzdHJhdGlvbnMuIFRvIGVuY29kZSB0aGUgYWJzZW5jZSBv ZiBhbiBhZGRyZXNzIHRoZSBtaW5pbXVtDQo+Pj4+IGxlbmd0aCBvZiB6ZXJvIHNob3VsZCBiZSBh bGxvd2VkLg0KPj4+PiANCj4+Pj4gSW5zdHJ1Y3Rpb25zOiAtLS0tLS0tLS0tLS0tIFRoaXMgZXJy YXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzDQo+Pj4+ICJSZXBvcnRlZCIuIElmIG5lY2Vzc2Fy eSwgcGxlYXNlIHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzDQo+Pj4+IHdoZXRoZXIgaXQgc2hv dWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMNCj4+Pj4gcmVh Y2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVTRykgY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhl DQo+Pj4+IHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQo+Pj4+IA0K Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSRkM3MDUyDQo+Pj4+ IChkcmFmdC1pZXRmLWxpc3AtbWliLTEzKSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSANCj4+Pj4gVGl0bGUgICAgICAgICAgICAgICA6IExvY2F0b3IvSUQgU2VwYXJhdGlv biBQcm90b2NvbCAoTElTUCkgTUlCIA0KPj4+PiBQdWJsaWNhdGlvbiBEYXRlICAgIDogT2N0b2Jl ciAyMDEzIEF1dGhvcihzKSAgICAgICAgICAgOiBHLg0KPj4+PiBTY2h1ZGVsLCBBLiBKYWluLCBW LiBNb3Jlbm8gQ2F0ZWdvcnkgICAgICAgICAgICA6IEVYUEVSSU1FTlRBTCANCj4+Pj4gU291cmNl ICAgICAgICAgICAgICA6IExvY2F0b3IvSUQgU2VwYXJhdGlvbiBQcm90b2NvbCBBcmVhDQo+Pj4+ IDogSW50ZXJuZXQgU3RyZWFtICAgICAgICAgICAgICA6IElFVEYgVmVyaWZ5aW5nIFBhcnR5ICAg ICA6IElFU0cNCj4+IA0KPiANCg0K From nobody Fri Feb 6 07:44:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C211A1BDA for ; Fri, 6 Feb 2015 07:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHrbiIxEt5Qj for ; Fri, 6 Feb 2015 07:44:20 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F28F1A1BB0 for ; Fri, 6 Feb 2015 07:44:11 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5AD2388126; Fri, 6 Feb 2015 07:44:11 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7B3B113682A3; Fri, 6 Feb 2015 07:44:10 -0800 (PST) Message-ID: <54D4E142.6020409@innovationslab.net> Date: Fri, 06 Feb 2015 10:44:02 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Isidoros Kouvelas (kouvelas)" References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s9Tt6vpDcuUpo0JB4waJthO7h1RjIMGT4" Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:44:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s9Tt6vpDcuUpo0JB4waJthO7h1RjIMGT4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Isidor, On 2/6/15 10:19 AM, Isidoros Kouvelas (kouvelas) wrote: > Brian, >=20 > I am not sure what the minimum length of 5 could correspond to given > the minimum length of an IPv4 address will be 8 octets (including two > for AFI, one for the internal length field and one for the mask > length). So I would be interested in the discussion context you refer > to. It turns out that the discussion during review was with the upper limit. I can't find any reference to discussions on the lower limit. Authors? >=20 > Regarding the unspecified address specification I think that making > it explicit (zero length) would be cleaner than encoding a special > address. To limit the number of changes to the MIB we could only fix > the LispAddressType octet string definition as well as > lispEidRegistrationLastRegisterSenderLength. >=20 > Regarding the example below, the normal case is that all EID prefixes > are configured on the Map-Server and then registered by the xTRs. > Reporting the MS as the RegisterSender of the EID prefixes that have > not been registered would not work. So, is your suggestion to change the lower limit on the TC and the lower limit for just the lispEidRegistrationLastRegisterSenderLength? I would still like some input from others in the WG on this issue. Regards, Brian --s9Tt6vpDcuUpo0JB4waJthO7h1RjIMGT4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU1OFJAAoJEBOZRqCi7goqCWQH/RNbZ5sljN72Xi69zoBDu+3q SyUmAkCe8QheLzsT0RkcxlhEGlLFpJHTYCLPVtsFcL7cPGysJgJilLLn4cWFUKoE wSDtZalubNGQnrRyHi5hQS5wH955YHEvuWpcbQy7fZNEJxDz6lX9ZZjp8Y8mr06y /0M3Ddd2UcdM1otTq6oanvMa16toW5cee+nKfo4lmRZzT4L96xl7jqtp3eBPJ4XN w4CYmHBn/8tj548qtl/trrz++DwVYvDSMZAvsQrrwi1VevZpe8BH17cJ3w0keV4t rm9+Nhvlayy5KAvwxKuE2SVazOFTQ0q7jrBpk6wnicExtKENq+ANathVrO60wHA= =1i23 -----END PGP SIGNATURE----- --s9Tt6vpDcuUpo0JB4waJthO7h1RjIMGT4-- From nobody Fri Feb 6 07:48:37 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAC61A1BDA for ; Fri, 6 Feb 2015 07:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-MVciVuMyVp for ; Fri, 6 Feb 2015 07:48:35 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81321A1BAF for ; Fri, 6 Feb 2015 07:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1814; q=dns/txt; s=iport; t=1423237714; x=1424447314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ps1oECA7l2eu7k4GHrQSPo08EcdjT7CcveslrMS2xLk=; b=aFzLEo0mPtrAkvvhY12tChGZLsXUDO9Nk+DuAiJQXShED22H2gQZtDLF i4OiN+7lM0CiIlVpNz/IRqQE68D/SXIPhuAY5VRO5+H3H5BggGzBa7Y6C sUYP/lyLLqs4H97PdS0+5NtICwOj9cFz800Hko6etpGOsMS82kbRG2lo3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A1BgAs4dRU/4MNJK1agwaBLATANogXAoEZQwEBAQEBfYQMAQEBAwE6PwULAgEIGB4QMiUCBA4FiCUI1W4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjEiCWSQzB4MWgRMBBI8aiSyBF44Xgz4iggIND4FQb4EDQX4BAQE X-IronPort-AV: E=Sophos;i="5.09,529,1418083200"; d="scan'208";a="121161329" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 06 Feb 2015 15:48:34 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t16FmXUK021504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 15:48:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 09:48:33 -0600 From: "Isidoros Kouvelas (kouvelas)" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC7052 (4256) Thread-Index: AQHQQFxlnTg8pe7qO0ib4DaVqyuxIpzkBIuAgAAYCoCAAARKAIAAA3qAgAAG+QCAAAFFgA== Date: Fri, 6 Feb 2015 15:48:33 +0000 Message-ID: <91124685-79A3-4781-A87A-65029EE70219@cisco.com> References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> <54D4E142.6020409@innovationslab.net> In-Reply-To: <54D4E142.6020409@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <0CD3CB62D80CB546AA45FE201356F753@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:48:36 -0000 Brian, I would rather see all the uses of LispAddressType have the lower limit of = the associated length fields changed to zero but given your concern on the = number of changes to the document I think just changing lispEidRegistration= LastRegisterSenderLength would satisfy the current requirement. thanks Isidor On Feb 6, 2015, at 17:44, Brian Haberman wrote: > Isidor, >=20 > On 2/6/15 10:19 AM, Isidoros Kouvelas (kouvelas) wrote: >> Brian, >>=20 >> I am not sure what the minimum length of 5 could correspond to given >> the minimum length of an IPv4 address will be 8 octets (including two >> for AFI, one for the internal length field and one for the mask >> length). So I would be interested in the discussion context you refer >> to. >=20 > It turns out that the discussion during review was with the upper limit. > I can't find any reference to discussions on the lower limit. Authors? >=20 >>=20 >> Regarding the unspecified address specification I think that making >> it explicit (zero length) would be cleaner than encoding a special >> address. To limit the number of changes to the MIB we could only fix >> the LispAddressType octet string definition as well as >> lispEidRegistrationLastRegisterSenderLength. >>=20 >> Regarding the example below, the normal case is that all EID prefixes >> are configured on the Map-Server and then registered by the xTRs. >> Reporting the MS as the RegisterSender of the EID prefixes that have >> not been registered would not work. >=20 > So, is your suggestion to change the lower limit on the TC and the lower > limit for just the lispEidRegistrationLastRegisterSenderLength? >=20 > I would still like some input from others in the WG on this issue. >=20 > Regards, > Brian >=20 From nobody Fri Feb 6 09:58:26 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944241A8703 for ; Fri, 6 Feb 2015 09:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Qgw_wDp8Tv for ; Fri, 6 Feb 2015 09:58:15 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1B21A86FC for ; Fri, 6 Feb 2015 09:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=775; q=dns/txt; s=iport; t=1423245493; x=1424455093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qGX0tYVtQfkuaQt1Jh9FgNNl80lp9q0lpoKFZ4jJbGI=; b=IPZ+IzAcsKxds3a64Ci8esa6IKJu5uo7DeNWxnPW6O30I8e/AYvPLUHZ fr+riiSRqErSC5LW22l7SdenDtsSfzOobutqlRR6CqbcvD83z/7wy2umG DfMvuA7u10YGx1VrF6pte6embFXy05+bAN0RtH0FTkrgQUS6b6bAtYRDE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DBBQB8ANVU/5FdJa1XA4MGUloEwl6FcQKBGUMBAQEBAX2EDQEBAwE6NQoFCwIBCDYQMiUCBA4FiCUIDdV8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4xIgk4LBgEdIxACBRGDBYETBYVSh2WBY4kskmwigg+BX28BgQIIFyJ+AQEB X-IronPort-AV: E=Sophos;i="5.09,530,1418083200"; d="scan'208";a="121272174" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 06 Feb 2015 17:58:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t16HwBsf019333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 17:58:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 11:58:11 -0600 From: "Gregg Schudel (gschudel)" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC7052 (4256) Thread-Index: AQHQQFxls8Hl+pKXQkekcAzaN3dwL5zkBIuAgAAYB4CAAARNAIAAA3iAgAAG+wCAACVyAA== Date: Fri, 6 Feb 2015 17:58:10 +0000 Message-ID: <8A99A6AF-5E6D-458B-B7F8-8B4DE2FEA182@cisco.com> References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> <54D4E142.6020409@innovationslab.net> In-Reply-To: <54D4E142.6020409@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.216.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B6C5D0E120AA74E9DD31523813FFD27@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:58:23 -0000 On Feb 6, 2015, at 7:44 AM, Brian Haberman wrote= : > It turns out that the discussion during review was with the upper limit. > I can't find any reference to discussions on the lower limit. Authors? going back to check Brian - it was a while ago. thanks! Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From nobody Mon Feb 9 10:46:50 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C3D1A1B92; Mon, 9 Feb 2015 10:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LjzpFABFVQU; Mon, 9 Feb 2015 10:29:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9D11A1B57; Mon, 9 Feb 2015 10:29:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209182913.16220.11841.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 10:29:13 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:29:14 -0000 IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Mon Feb 9 10:48:11 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DA7521A1B57; Mon, 9 Feb 2015 10:29:14 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C3D1A1B92; Mon, 9 Feb 2015 10:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LjzpFABFVQU; Mon, 9 Feb 2015 10:29:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9D11A1B57; Mon, 9 Feb 2015 10:29:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209182913.16220.11841.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 10:29:13 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:29:15 -0000 IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Mon Feb 9 15:51:26 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274DC1A8AA8; Mon, 9 Feb 2015 15:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcypb1843DqV; Mon, 9 Feb 2015 15:39:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A48671A8A93; Mon, 9 Feb 2015 15:39:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209233909.7729.6535.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 15:39:09 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:39:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : An Architectural Introduction to the Locator/ID Separation Protocol (LISP) Authors : Albert Cabellos Damien Saucez Filename : draft-ietf-lisp-introduction-11.txt Pages : 27 Date : 2015-02-09 Abstract: This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-introduction-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-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 Mon Feb 9 15:51:35 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14FE1A8AA8; Mon, 9 Feb 2015 15:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikN9DaMMJII8; Mon, 9 Feb 2015 15:39:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B25E31A8AA0; Mon, 9 Feb 2015 15:39:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209233909.7729.32161.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 15:39:09 -0800 Archived-At: Subject: [lisp] New Version Notification - draft-ietf-lisp-introduction-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:39:12 -0000 A new version (-11) has been submitted for draft-ietf-lisp-introduction: http://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-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. IETF Secretariat. From nobody Mon Feb 9 15:51:37 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C7B071A8AA9; Mon, 9 Feb 2015 15:39:12 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14FE1A8AA8; Mon, 9 Feb 2015 15:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikN9DaMMJII8; Mon, 9 Feb 2015 15:39:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B25E31A8AA0; Mon, 9 Feb 2015 15:39:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209233909.7729.32161.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 15:39:09 -0800 Archived-At: Subject: [lisp] New Version Notification - draft-ietf-lisp-introduction-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:39:13 -0000 A new version (-11) has been submitted for draft-ietf-lisp-introduction: http://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-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. IETF Secretariat. From nobody Mon Feb 9 15:51:41 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B911A8A9E for ; Mon, 9 Feb 2015 15:43:54 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CfeaFarScjl for ; Mon, 9 Feb 2015 15:43:52 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0CD1A8AA2 for ; Mon, 9 Feb 2015 15:43:49 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so19996888igj.4 for ; Mon, 09 Feb 2015 15:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=i064nya0pAf9RxptAyU68lsANN+EoHqgHILgM/XEf1I=; b=Nt++YLDAh64+m0KDoML9RR2ztHwDzowo3xXnWleIhXPdjtTqtsxv8mi291pTesVLZV le5rsZNybo7QaEvljGjrfUkXQuv27Nm0UV0evG3o03Z9aFtqGoMQOfUhQIBlifnD/xj8 guMFOP4xgqejCU3Cqa7B1RNRA7wepP4vhBFgU472n8ggyQ5QBJs4SdIBi+7MVzDxyhyz bZOHWSDJn/+ONQllrcOoWFmKQiCWTFqTJkMFq6Jr8N1wHc7KNfa5PssOQYgPpqeKHqjV v2Hw4JDxoxGN7BZBktwt92zZ/Ly82yxH6F1EIH2RDR8dqamZLLNI3rKBAgunYZjdymiO Qk+g== MIME-Version: 1.0 X-Received: by 10.50.142.38 with SMTP id rt6mr20056131igb.17.1423525429071; Mon, 09 Feb 2015 15:43:49 -0800 (PST) Received: by 10.107.8.36 with HTTP; Mon, 9 Feb 2015 15:43:49 -0800 (PST) In-Reply-To: <20150209233909.7729.6535.idtracker@ietfa.amsl.com> References: <20150209233909.7729.6535.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 00:43:49 +0100 Message-ID: From: Albert Cabellos To: "lisp@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3a950877a32050eb0573e Archived-At: Cc: Damien Saucez Subject: Re: [lisp] I-D Action: draft-ietf-lisp-introduction-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:43:54 -0000 --001a11c3a950877a32050eb0573e Content-Type: text/plain; charset=UTF-8 Updated following Radia Perlman's review. Albert On Tue, Feb 10, 2015 at 12:39 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol Working > Group of the IETF. > > Title : An Architectural Introduction to the Locator/ID > Separation Protocol (LISP) > Authors : Albert Cabellos > Damien Saucez > Filename : draft-ietf-lisp-introduction-11.txt > Pages : 27 > Date : 2015-02-09 > > Abstract: > This document describes the architecture of the Locator/ID Separation > Protocol (LISP), making it easier to read the rest of the LISP > specifications and providing a basis for discussion about the details > of the LISP protocols. This document is used for introductory > purposes, more details can be found in RFC6830, the protocol > specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lisp-introduction-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-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/ > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --001a11c3a950877a32050eb0573e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Updated following=C2=A0Radia=C2=A0= Perlman's review.

Albert

On Tue, Feb 10, 2015 at 12:39 AM, = <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Locator/ID Separation Protocol Worki= ng Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= An Architectural Introduction to the Locator/ID Separation Protocol (LISP)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Albe= rt Cabellos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Damien Saucez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lisp-introduction-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 27
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-02-09

Abstract:
=C2=A0 =C2=A0This document describes the architecture of the Locator/ID Sep= aration
=C2=A0 =C2=A0Protocol (LISP), making it easier to read the rest of the LISP=
=C2=A0 =C2=A0specifications and providing a basis for discussion about the = details
=C2=A0 =C2=A0of the LISP protocols.=C2=A0 This document is used for introdu= ctory
=C2=A0 =C2=A0purposes, more details can be found in RFC6830, the protocol =C2=A0 =C2=A0specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-introduc= tion/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-introduction-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-in= troduction-11


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/

_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--001a11c3a950877a32050eb0573e-- From nobody Tue Feb 10 00:06:39 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706221A0143 for ; Tue, 10 Feb 2015 00:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBf6iCdCkq07 for ; Tue, 10 Feb 2015 00:06:25 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F71A000F for ; Tue, 10 Feb 2015 00:06:24 -0800 (PST) Received: from gw-2.ac.upc.es (gw-2.ac.upc.es [147.83.30.8]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id t1A86K7L017232; Tue, 10 Feb 2015 09:06:20 +0100 Received: from [10.61.96.201] (173-38-208-169.cisco.com [173.38.208.169]) by gw-2.ac.upc.es (Postfix) with ESMTPSA id 9A22AC5; Tue, 10 Feb 2015 09:06:19 +0100 (CET) Message-ID: <54D9BBF6.70506@lispmob.org> Date: Tue, 10 Feb 2015 10:06:14 +0200 From: Lori Jakab Organization: LISPmob MIME-Version: 1.0 To: Luigi Iannone , LISP mailing list list References: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> In-Reply-To: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Halpern Direct , Damien Saucez Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-ddt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 08:06:35 -0000 Hi, I read the draft and I think it is ready to be handed to the AD. Regards, -Lori On 01/29/2015 05:36 PM, Luigi Iannone wrote: > Hi All, > > The authors of draft-ietf-lisp-ddt-02 > [http://tools.ietf.org/html/draft-ietf-lisp-ddt-02], > as well as several active WG participants, > requested the WG Last Call for this document. > > This email starts a 14 days WG Last Call, to end February 13th, 2015. > > Please review this WG document and let the WG know if you agree that it > is ready for handing to the AD. > If you have objections, please state your reasons why, and explain what > it would take to address your concerns. > > Thanks > > Luigi & Joel From nobody Tue Feb 10 09:25:19 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C811A1ACE; Tue, 10 Feb 2015 09:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKF-BFRBibZX; Tue, 10 Feb 2015 09:25:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B51A009E; Tue, 10 Feb 2015 09:25:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210172500.17783.56448.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 09:25:00 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:25:05 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Tue Feb 10 09:25:36 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AFD5B1A1ADD; Tue, 10 Feb 2015 09:25:05 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C811A1ACE; Tue, 10 Feb 2015 09:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKF-BFRBibZX; Tue, 10 Feb 2015 09:25:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B51A009E; Tue, 10 Feb 2015 09:25:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210172500.17783.56448.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 09:25:00 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:25:05 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Tue Feb 10 09:25:37 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B361A1AAC; Tue, 10 Feb 2015 09:25:23 -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, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI6yY094CwnI; Tue, 10 Feb 2015 09:25:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB681A1AB2; Tue, 10 Feb 2015 09:25:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210172509.17845.72905.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 09:25:09 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] Telechat update notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:25:24 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Tue Feb 10 09:25:46 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 674781A1ADD; Tue, 10 Feb 2015 09:25:24 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B361A1AAC; Tue, 10 Feb 2015 09:25:23 -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, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI6yY094CwnI; Tue, 10 Feb 2015 09:25:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB681A1AB2; Tue, 10 Feb 2015 09:25:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210172509.17845.72905.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 09:25:09 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] Telechat update notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:25:24 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Tue Feb 10 15:25:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6D1A6FFE; Tue, 10 Feb 2015 15:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmYpT4oBs9T2; Tue, 10 Feb 2015 15:25:27 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3855A1A1AF8; Tue, 10 Feb 2015 15:25:26 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1ANPL8d010201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 18:25:22 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1ANPL8d010201 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423610723; bh=Tvg8AcQrD6sh0bMJsaDGtkB/x9w=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gAul6nkg0Xe8rjDElLK2/QK5RyXwJrUQJj35UEzDt543U2HnQrEjFsgLTA3qZykAK bu4ke94dAaREiDdNcPe+xXbU0q10mVt2cE8bal9QrSuZWOOjVV6CZgCUyjL3hgzMmZ 4NgdKYAaWHErnj40kAOGg43jH966+m5GDXqu1w7Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1ANPL8d010201 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 10 Feb 2015 18:25:06 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1ANP5sm024795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 18:25:05 -0500 Received: from MXHUB201.corp.emc.com (10.253.68.27) by mxhub33.corp.emc.com (10.254.93.81) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 10 Feb 2015 18:25:05 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB201.corp.emc.com ([10.253.68.27]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 18:25:05 -0500 From: "Black, David" To: "acabello@ac.upc.edu" , "damien.saucez@inria.fr" , "ops-dir@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-lisp-introduction-11 Thread-Index: AdBFiMToswN7n7S2Sw+GOUWYxLLMyg== Date: Tue, 10 Feb 2015 23:25:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "Black, David" , "ietf@ietf.org" , "lisp@ietf.org" Subject: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:25:32 -0000 I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-lisp-introduction-11 Reviewer: David Black Review Date: Feb 10, 2015 IETF LC End Date: Feb 4, 2015 (on -10) Summary: This draft is on the right track, but has open issues described in the review. First of all, I apologize for this review showing up after the end of IETF Last Call on this draft. I plead being one of the victims of this year's flu vaccine being poorly matched to the prevalent flu viruses. The draft is generally well written and provides a nice introduction to LISP - good job. Most of the usual OPS-Dir questions in Appendix A of RFC 5706 do not apply, as they are better addressed by the additional material in the RFCs that specify the actual LISP protocol specifications. Nonetheless, there are a few that apply, as noted in the issues below. I found a couple of major issues that I hope arise from the summarization of LISP in this draft, as opposed to being problems in the actual LISP protocols. I also found a few minor issues, the most important of which is the need for additional security considerations discussion on misdelivery, with particular attention to VPNs. -- Major issues -- [A] EID mobility vs. EID prefixes - 5. Mobility I understand how this works when mapping is per-EID, but how does this work when the EID of the system that moves is part of an EID prefix, as discusse= d in Section 3.4.1? Even if the answer is a long version of "Don't do that!" it should be explained. - 7.4. LISP for Virtual Machine Mobility in Data Centers I don't understand how this works when EID prefixes are used, as each VM has its own EID or EIDs, hence the entire prefix range does not move when the VM moves. For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix A of RFC 5706: Has deployment been discussed? and specifically under: * Is the proposed specification deployable? If not, how could it be improved? as EID prefixes appear to be undeployable for Mobility and VM Mobility usag= e. [B] LISP Multicast vs. EID/RLOC separate - 6. Multicast This is interesting, multicast addresses (G) look like they're an exception to the EID/RLOC separation as the same destination IP multicast address is used for both purposes. This could use some more discussion, as it's unexpected based on the contents of the draft up to this point. - 7.2. LISP for IPv6 Co-existence LISP encapsulations allows to transport packets using EIDs from a given address family (e.g., IPv6) with packets from other address families (e.g., IPv4). How does that work for multicast traffic, where the destination address (G) has to be the same in both the inner and outer headers? Are ETRs and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? - 7.3. LISP for Virtual Private Networks This also has multicast problems, as there is only one instance of each multicast address (G) in the underlay network. I think I can figure out ho= w to make multicast work for this use case, but it's not immediately obvious, and the result when the same underlay multicast address is used by more than one VPN could well deliver some traffic to ETRs that have to discard it because the Instance ID is wrong (and that excessive delivery is a security consideration, see minor issue on Section 8 below). I think an explanation is in order. For OPS-Dir, this multicast issue [B] falls under A.1.4 in Appendix A of RFC 5706: Have the Requirements on other protocols and functional components been discussed? -- Minor Issues -- There seems to be an implicit assumption that the end host and its ITR (xTR) are in the same domain or Autonomous System. For incremental deployment, I don't think that's always the case, but I think that only has editorial impact on this document, as I don't think any of the fundamental LISP mechanisms are affected. The authors should look for use of "domain" and "Autonomous System" and ensure that the text is generalized to the case where the end host and ITR are more widely separated. Despite multiple mentions of incremental deployment, I did not see a discussion of how that might be accomplished. There is some useful content in Section 3.5, but that's at best an incomplete explanation. This is an OPS-Dir review concern - it falls under A.1.3 in Appendix A of RFC 5706: Has the migration path been discussed? - 3.3.1. LISP Encapsulation the source port is selected by=20 the ITR and ignored on reception. Please mention multipathing (e.g., ECMP and LAG) as possible influences on how source ports are selected, as this imposes some limits on what an ITR can reasonably do. For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix A of RFC 5706: Have the Requirements on other protocols and functional components been discussed? This decision was made because the typical transport protocols used by the applications already include a checksum, by neglecting the additional UDP encapsulation checksum xTRs can forward packets more efficiently. Groan! I have an exquisite set of scars on UDP zero checksums for IPv6 from working on the MPLS in UDP draft, so I may be overly sensitive to this concern. The downside of this efficiency is that there is no checksum coverage of the IPv6 header when zero UDP checksums are used. That should at least be mentioned here, with a summary of why that's ok - the detailed justification for why that's ok can be left to other documents. For OPS-Dir, this UDP zero checksum for IPv6 concern also falls under A.1.4 in Appendix A of RFC 5706: Have the Requirements on other protocols and functional components been discussed? - 8 Security Considerations This should discuss possibility of misdelivery of LISP-encapsulated packets to the wrong ETR and the resulting security consequences. This is particularly relevant to the VPN use case in Section 7.3. This discussion should also note that omitting the UDP checksum for IPv6 increases the opportunity for misdelivery. For OPS-Dir, this security concern falls under A.1.5 in Appendix A of RFC 5706: Has the impact on network operation been discussed? This is because dealing with any such misdelivery will have an operational impact. -- Nits/Editorial Comments -- - Top of p.4: The initial motivation in the LISP effort is to be find in the "find" -> "found" - Section 3.1, first bullet item Devices are assigned with relatively opaque identity meaningful addresses that are independent of their topological location. I don't understand "relatively opaque identity meaningful" and suggest rewriting the sentence. In particular - opaque to what? meaningful to what in what manner? - Section 3.2, second paragraph Judging from the figure, xTRs are the common case, with single- function ITRs and ETRs being rare. It might be good to say that and discuss when ITRs and ETRs that are not xTRs are appropriate to use. - 3rd paragraph on p.7: Finally, the LISP architecture emphasizes a cost effective incremental deployment. I'd delete "cost effective" here and look for other occurrences of "cost" as candidates for deletion. This is supposed to be a technical document, so discussion of costs is a bit off-target. - First item after Figure 2: 1. HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining and A or AAAA record. "and A" -> "an A" (spelling checkers don't catch everything). - 3.3.1. LISP Encapsulation On the other hand, Recursive tunnels are nested tunnels and are implemented by using multiple LISP encapsulations on a packet. The above sentence seems out of place in the middle of a paragraph about Re-encapsulating tunnels and routers - I suggest moving it down into its own paragraph and perhaps adding a sentence about where/how Recursive tunnels may be useful. - 3.3.2. LISP Forwarding State In the LISP architecture, ITRs keep just enough information to route traffic flowing through it. "it." -> "them." Meaning that, ITRs retrieve from the LISP Mapping System mappings between EID prefixes and RLOCs that are used to encapsulate packets. This is the first use of the notion of EID prefixes. That concept should be explained before it is used, although a forward reference to section 3.4.1 may suffice. It might be better to rewrite this paragraph in terms of EIDs and leave the notion of EID prefixes to section 3.4.1. - 4.4. MTU Handling Additionally, LISP also recommends inferring reachability of locators by using information provided by the underlay, in particular: It'd be useful to add a sentence or two about how LISP and the techniques in this section interact with host use of PMTUD and PLPMTUD. - Next to last paragraph on p.17: Additionally, LISP also recommends inferring reachability of locators by using information provided by the underlay, in particular: This looks like it's a paragraph early and needs to be moved down to after the paragraph that follows it. idnits 2.13.01 didn't find any nits. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Tue Feb 10 15:46:08 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CE91A8757; Tue, 10 Feb 2015 15:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnv5HAN9MAz9; Tue, 10 Feb 2015 15:45:58 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D081A8756; Tue, 10 Feb 2015 15:45:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7DF1324072B; Tue, 10 Feb 2015 15:45:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 53F742403A3; Tue, 10 Feb 2015 15:45:56 -0800 (PST) Message-ID: <54DA982D.60200@joelhalpern.com> Date: Tue, 10 Feb 2015 18:45:49 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Black, David" , "acabello@ac.upc.edu" , "damien.saucez@inria.fr" , "ops-dir@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:46:01 -0000 I will leave most of these for the authors to comment on. With regard to your question about incremental deployment, that is the domain of the LISP Deployment document, and was deliberately only lightly covered here. I am not sure what we can do to address your comment without duplicating the entirety of that document. With regard to UDP Zero, this was approved by the IESG and published as an RFC. It is part of the way the protocol is defined. If there are specific changes you would like to see in the explanatory text, I am sure we could include them. If you are looking for a change in the behavior, this document can not make changes to the LISP behavior. Yours, Joel On 2/10/15 6:25 PM, Black, David wrote: > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the operational > aspects of the IETF drafts. Comments that are not addressed in last call > may be included in AD reviews during the IESG review. Document editors > and WG chairs should treat these comments just like any other last call > comments. > > Document: draft-ietf-lisp-introduction-11 > Reviewer: David Black > Review Date: Feb 10, 2015 > IETF LC End Date: Feb 4, 2015 (on -10) > > Summary: This draft is on the right track, but has open issues > described in the review. > > First of all, I apologize for this review showing up after the end of > IETF Last Call on this draft. I plead being one of the victims of this > year's flu vaccine being poorly matched to the prevalent flu viruses. > > The draft is generally well written and provides a nice introduction to > LISP - good job. Most of the usual OPS-Dir questions in Appendix A of > RFC 5706 do not apply, as they are better addressed by the additional > material in the RFCs that specify the actual LISP protocol specifications. > Nonetheless, there are a few that apply, as noted in the issues below. > > I found a couple of major issues that I hope arise from the > summarization of LISP in this draft, as opposed to being problems in > the actual LISP protocols. I also found a few minor issues, the most > important of which is the need for additional security considerations > discussion on misdelivery, with particular attention to VPNs. > > -- Major issues -- > > [A] EID mobility vs. EID prefixes > > - 5. Mobility > > I understand how this works when mapping is per-EID, but how does this work > when the EID of the system that moves is part of an EID prefix, as discussed > in Section 3.4.1? Even if the answer is a long version of "Don't do that!" > it should be explained. > > - 7.4. LISP for Virtual Machine Mobility in Data Centers > > I don't understand how this works when EID prefixes are used, as each VM > has its own EID or EIDs, hence the entire prefix range does not move when > the VM moves. > > For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix A > of RFC 5706: Has deployment been discussed? and specifically under: > > * Is the proposed specification deployable? If not, how could > it be improved? > > as EID prefixes appear to be undeployable for Mobility and VM Mobility usage. > > [B] LISP Multicast vs. EID/RLOC separate > > - 6. Multicast > > This is interesting, multicast addresses (G) look like they're an exception > to the EID/RLOC separation as the same destination IP multicast address > is used for both purposes. This could use some more discussion, as it's > unexpected based on the contents of the draft up to this point. > > - 7.2. LISP for IPv6 Co-existence > > LISP encapsulations allows to transport packets using EIDs from a > given address family (e.g., IPv6) with packets from other address > families (e.g., IPv4). > > How does that work for multicast traffic, where the destination address > (G) has to be the same in both the inner and outer headers? Are ETRs > and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? > > - 7.3. LISP for Virtual Private Networks > > This also has multicast problems, as there is only one instance of each > multicast address (G) in the underlay network. I think I can figure out how > to make multicast work for this use case, but it's not immediately obvious, > and the result when the same underlay multicast address is used by more > than one VPN could well deliver some traffic to ETRs that have to discard > it because the Instance ID is wrong (and that excessive delivery is a > security consideration, see minor issue on Section 8 below). I think an > explanation is in order. > > For OPS-Dir, this multicast issue [B] falls under A.1.4 in Appendix A of > RFC 5706: Have the Requirements on other protocols and functional > components been discussed? > > -- Minor Issues -- > > There seems to be an implicit assumption that the end host and its > ITR (xTR) are in the same domain or Autonomous System. For incremental > deployment, I don't think that's always the case, but I think that only > has editorial impact on this document, as I don't think any of the > fundamental LISP mechanisms are affected. The authors should look for > use of "domain" and "Autonomous System" and ensure that the text is > generalized to the case where the end host and ITR are more widely > separated. > > Despite multiple mentions of incremental deployment, I did not > see a discussion of how that might be accomplished. There is some > useful content in Section 3.5, but that's at best an incomplete > explanation. This is an OPS-Dir review concern - it falls under > A.1.3 in Appendix A of RFC 5706: Has the migration path been discussed? > > - 3.3.1. LISP Encapsulation > > the source port is selected by > the ITR and ignored on reception. > > Please mention multipathing (e.g., ECMP and LAG) as possible influences > on how source ports are selected, as this imposes some limits on what an > ITR can reasonably do. > > For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix A of > RFC 5706: Have the Requirements on other protocols and functional > components been discussed? > > This decision was made because the > typical transport protocols used by the applications already include > a checksum, by neglecting the additional UDP encapsulation checksum > xTRs can forward packets more efficiently. > > Groan! I have an exquisite set of scars on UDP zero checksums for IPv6 > from working on the MPLS in UDP draft, so I may be overly sensitive to > this concern. The downside of this efficiency is that there is no > checksum coverage of the IPv6 header when zero UDP checksums are used. > That should at least be mentioned here, with a summary of why that's ok > - the detailed justification for why that's ok can be left to other > documents. > > For OPS-Dir, this UDP zero checksum for IPv6 concern also falls under > A.1.4 in Appendix A of RFC 5706: > Have the Requirements on other protocols and functional > components been discussed? > > - 8 Security Considerations > > This should discuss possibility of misdelivery of LISP-encapsulated > packets to the wrong ETR and the resulting security consequences. This > is particularly relevant to the VPN use case in Section 7.3. This > discussion should also note that omitting the UDP checksum for IPv6 > increases the opportunity for misdelivery. > > For OPS-Dir, this security concern falls under A.1.5 in Appendix A of > RFC 5706: Has the impact on network operation been discussed? > > This is because dealing with any such misdelivery will have an operational > impact. > > -- Nits/Editorial Comments -- > > - Top of p.4: > > The initial motivation in the LISP effort is to be find in the > > "find" -> "found" > > - Section 3.1, first bullet item > > Devices are assigned with relatively opaque identity > meaningful addresses that are independent of their topological > location. > > I don't understand "relatively opaque identity meaningful" and > suggest rewriting the sentence. In particular - opaque to what? > meaningful to what in what manner? > > - Section 3.2, second paragraph > > Judging from the figure, xTRs are the common case, with single- > function ITRs and ETRs being rare. It might be good to say that > and discuss when ITRs and ETRs that are not xTRs are appropriate > to use. > > - 3rd paragraph on p.7: > > > Finally, the LISP architecture emphasizes a cost effective > incremental deployment. > > I'd delete "cost effective" here and look for other occurrences > of "cost" as candidates for deletion. This is supposed to be > a technical document, so discussion of costs is a bit off-target. > > - First item after Figure 2: > > 1. HostA retrieves the EID_B of HostB, typically querying the DNS > and obtaining and A or AAAA record. > > "and A" -> "an A" (spelling checkers don't catch everything). > > - 3.3.1. LISP Encapsulation > > On the other hand, Recursive > tunnels are nested tunnels and are implemented by using multiple LISP > encapsulations on a packet. > > The above sentence seems out of place in the middle of a paragraph about > Re-encapsulating tunnels and routers - I suggest moving it down into its > own paragraph and perhaps adding a sentence about where/how Recursive > tunnels may be useful. > > - 3.3.2. LISP Forwarding State > > In the LISP architecture, ITRs keep just enough information to route > traffic flowing through it. > > "it." -> "them." > > Meaning that, ITRs retrieve from the > LISP Mapping System mappings between EID prefixes and RLOCs that are > used to encapsulate packets. > > This is the first use of the notion of EID prefixes. That concept should > be explained before it is used, although a forward reference to section > 3.4.1 may suffice. It might be better to rewrite this paragraph in terms > of EIDs and leave the notion of EID prefixes to section 3.4.1. > > - 4.4. MTU Handling > > Additionally, LISP also recommends inferring reachability of locators > by using information provided by the underlay, in particular: > > It'd be useful to add a sentence or two about how LISP and the techniques > in this section interact with host use of PMTUD and PLPMTUD. > > - Next to last paragraph on p.17: > > Additionally, LISP also recommends inferring reachability of locators > by using information provided by the underlay, in particular: > > This looks like it's a paragraph early and needs to be moved down to > after the paragraph that follows it. > > idnits 2.13.01 didn't find any nits. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > From nobody Tue Feb 10 16:02:22 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2684F1A1B87; Tue, 10 Feb 2015 16:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1LvUS58S8J9; Tue, 10 Feb 2015 16:02:10 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409741A1BB7; Tue, 10 Feb 2015 16:02:09 -0800 (PST) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1B025Vh006174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 19:02:06 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t1B025Vh006174 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423612926; bh=99OGHccG7Cvjt5NfgpiFhHe0M1s=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WkybXxkpAJMZnaUk4gHbChJGaE1hBM0CqS7d7QJJ82MvtF4S16HQDAoyXFChdjGVX HGgpJ/bGXGWjxCpjfuBR2f2QYsQVv1GOoxdq4dK0lmbSqRFm4B54dl2E3A1Rkg4inE bPOUATi2VlaliiwgQUSqsoUStorI7TziuwAAdFx4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t1B025Vh006174 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 10 Feb 2015 19:01:57 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1B021jJ002942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 19:02:01 -0500 Received: from MXHUB101.corp.emc.com (10.253.50.15) by mxhub19.corp.emc.com (10.254.93.48) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 10 Feb 2015 19:02:00 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB101.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 19:02:00 -0500 From: "Black, David" To: "Joel M. Halpern" , "acabello@ac.upc.edu" , "damien.saucez@inria.fr" , "ops-dir@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-lisp-introduction-11 Thread-Index: AdBFiMToswN7n7S2Sw+GOUWYxLLMygALNZaAAApeNDA= Date: Wed, 11 Feb 2015 00:02:00 +0000 Message-ID: References: <54DA982D.60200@joelhalpern.com> In-Reply-To: <54DA982D.60200@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "Black, David" , "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 00:02:18 -0000 Joel, Thanks for the quick response. On incremental deployment, a few sentences on the role/usage of PITRs and PETRs in incremental deployment plus considerations for how both EIDs and fully routable IPv4 and IPv6 addresses can be used as destination addresses from the same LISP host would be helpful (e.g., I'm reasonably certain that this has implications for which IP address blocks can be used for EIDs, if for no other reason than PETRs announce EID address blocks as fully routabl= e in the Internet). On UDP zero checksum for IPv6, I'm not looking for protocol changes, but I'd like to see some summarized discussion of the design rationale that aligns what LISP does with RFC 6936. As noted in the review, the full details don't belong here, but a technical summary of why this is ok beyond "The IESG said so" ;-) would be helpful. FWIW I'm not a strong believer in that sort of "proof by authority" :-). Thanks, --David > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, February 10, 2015 6:46 PM > To: Black, David; acabello@ac.upc.edu; damien.saucez@inria.fr; ops- > dir@ietf.org > Cc: ietf@ietf.org; lisp@ietf.org > Subject: Re: OPS-Dir review of draft-ietf-lisp-introduction-11 >=20 > I will leave most of these for the authors to comment on. >=20 > With regard to your question about incremental deployment, that is the > domain of the LISP Deployment document, and was deliberately only > lightly covered here. I am not sure what we can do to address your > comment without duplicating the entirety of that document. >=20 > With regard to UDP Zero, this was approved by the IESG and published as > an RFC. It is part of the way the protocol is defined. If there are > specific changes you would like to see in the explanatory text, I am > sure we could include them. If you are looking for a change in the > behavior, this document can not make changes to the LISP behavior. >=20 > Yours, > Joel >=20 > On 2/10/15 6:25 PM, Black, David wrote: > > I have reviewed this document as part of the Operational directorate's > > ongoing effort to review all IETF documents being processed by the IESG= . > > These comments were written with the intent of improving the operationa= l > > aspects of the IETF drafts. Comments that are not addressed in last cal= l > > may be included in AD reviews during the IESG review. Document editors > > and WG chairs should treat these comments just like any other last call > > comments. > > > > Document: draft-ietf-lisp-introduction-11 > > Reviewer: David Black > > Review Date: Feb 10, 2015 > > IETF LC End Date: Feb 4, 2015 (on -10) > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > First of all, I apologize for this review showing up after the end of > > IETF Last Call on this draft. I plead being one of the victims of this > > year's flu vaccine being poorly matched to the prevalent flu viruses. > > > > The draft is generally well written and provides a nice introduction to > > LISP - good job. Most of the usual OPS-Dir questions in Appendix A of > > RFC 5706 do not apply, as they are better addressed by the additional > > material in the RFCs that specify the actual LISP protocol specificatio= ns. > > Nonetheless, there are a few that apply, as noted in the issues below. > > > > I found a couple of major issues that I hope arise from the > > summarization of LISP in this draft, as opposed to being problems in > > the actual LISP protocols. I also found a few minor issues, the most > > important of which is the need for additional security considerations > > discussion on misdelivery, with particular attention to VPNs. > > > > -- Major issues -- > > > > [A] EID mobility vs. EID prefixes > > > > - 5. Mobility > > > > I understand how this works when mapping is per-EID, but how does this = work > > when the EID of the system that moves is part of an EID prefix, as disc= ussed > > in Section 3.4.1? Even if the answer is a long version of "Don't do th= at!" > > it should be explained. > > > > - 7.4. LISP for Virtual Machine Mobility in Data Centers > > > > I don't understand how this works when EID prefixes are used, as each V= M > > has its own EID or EIDs, hence the entire prefix range does not move wh= en > > the VM moves. > > > > For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix A > > of RFC 5706: Has deployment been discussed? and specifically under: > > > > * Is the proposed specification deployable? If not, how could > > it be improved? > > > > as EID prefixes appear to be undeployable for Mobility and VM Mobility > usage. > > > > [B] LISP Multicast vs. EID/RLOC separate > > > > - 6. Multicast > > > > This is interesting, multicast addresses (G) look like they're an excep= tion > > to the EID/RLOC separation as the same destination IP multicast address > > is used for both purposes. This could use some more discussion, as it'= s > > unexpected based on the contents of the draft up to this point. > > > > - 7.2. LISP for IPv6 Co-existence > > > > LISP encapsulations allows to transport packets using EIDs from a > > given address family (e.g., IPv6) with packets from other address > > families (e.g., IPv4). > > > > How does that work for multicast traffic, where the destination address > > (G) has to be the same in both the inner and outer headers? Are ETRs > > and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? > > > > - 7.3. LISP for Virtual Private Networks > > > > This also has multicast problems, as there is only one instance of each > > multicast address (G) in the underlay network. I think I can figure ou= t how > > to make multicast work for this use case, but it's not immediately obvi= ous, > > and the result when the same underlay multicast address is used by more > > than one VPN could well deliver some traffic to ETRs that have to disca= rd > > it because the Instance ID is wrong (and that excessive delivery is a > > security consideration, see minor issue on Section 8 below). I think a= n > > explanation is in order. > > > > For OPS-Dir, this multicast issue [B] falls under A.1.4 in Appendix A o= f > > RFC 5706: Have the Requirements on other protocols and functional > > components been discussed? > > > > -- Minor Issues -- > > > > There seems to be an implicit assumption that the end host and its > > ITR (xTR) are in the same domain or Autonomous System. For incremental > > deployment, I don't think that's always the case, but I think that only > > has editorial impact on this document, as I don't think any of the > > fundamental LISP mechanisms are affected. The authors should look for > > use of "domain" and "Autonomous System" and ensure that the text is > > generalized to the case where the end host and ITR are more widely > > separated. > > > > Despite multiple mentions of incremental deployment, I did not > > see a discussion of how that might be accomplished. There is some > > useful content in Section 3.5, but that's at best an incomplete > > explanation. This is an OPS-Dir review concern - it falls under > > A.1.3 in Appendix A of RFC 5706: Has the migration path been discussed? > > > > - 3.3.1. LISP Encapsulation > > > > the source port is selected by > > the ITR and ignored on reception. > > > > Please mention multipathing (e.g., ECMP and LAG) as possible influences > > on how source ports are selected, as this imposes some limits on what a= n > > ITR can reasonably do. > > > > For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix A = of > > RFC 5706: Have the Requirements on other protocols and functional > > components been discussed? > > > > This decision was made because the > > typical transport protocols used by the applications already includ= e > > a checksum, by neglecting the additional UDP encapsulation checksum > > xTRs can forward packets more efficiently. > > > > Groan! I have an exquisite set of scars on UDP zero checksums for IPv6 > > from working on the MPLS in UDP draft, so I may be overly sensitive to > > this concern. The downside of this efficiency is that there is no > > checksum coverage of the IPv6 header when zero UDP checksums are used. > > That should at least be mentioned here, with a summary of why that's ok > > - the detailed justification for why that's ok can be left to other > > documents. > > > > For OPS-Dir, this UDP zero checksum for IPv6 concern also falls under > > A.1.4 in Appendix A of RFC 5706: > > Have the Requirements on other protocols and functional > > components been discussed? > > > > - 8 Security Considerations > > > > This should discuss possibility of misdelivery of LISP-encapsulated > > packets to the wrong ETR and the resulting security consequences. This > > is particularly relevant to the VPN use case in Section 7.3. This > > discussion should also note that omitting the UDP checksum for IPv6 > > increases the opportunity for misdelivery. > > > > For OPS-Dir, this security concern falls under A.1.5 in Appendix A of > > RFC 5706: Has the impact on network operation been discussed? > > > > This is because dealing with any such misdelivery will have an operatio= nal > > impact. > > > > -- Nits/Editorial Comments -- > > > > - Top of p.4: > > > > The initial motivation in the LISP effort is to be find in the > > > > "find" -> "found" > > > > - Section 3.1, first bullet item > > > > Devices are assigned with relatively opaque identity > > meaningful addresses that are independent of their topological > > location. > > > > I don't understand "relatively opaque identity meaningful" and > > suggest rewriting the sentence. In particular - opaque to what? > > meaningful to what in what manner? > > > > - Section 3.2, second paragraph > > > > Judging from the figure, xTRs are the common case, with single- > > function ITRs and ETRs being rare. It might be good to say that > > and discuss when ITRs and ETRs that are not xTRs are appropriate > > to use. > > > > - 3rd paragraph on p.7: > > > > > > Finally, the LISP architecture emphasizes a cost effective > > incremental deployment. > > > > I'd delete "cost effective" here and look for other occurrences > > of "cost" as candidates for deletion. This is supposed to be > > a technical document, so discussion of costs is a bit off-target. > > > > - First item after Figure 2: > > > > 1. HostA retrieves the EID_B of HostB, typically querying the DNS > > and obtaining and A or AAAA record. > > > > "and A" -> "an A" (spelling checkers don't catch everything). > > > > - 3.3.1. LISP Encapsulation > > > > On the other hand, Recursive > > tunnels are nested tunnels and are implemented by using multiple LI= SP > > encapsulations on a packet. > > > > The above sentence seems out of place in the middle of a paragraph abou= t > > Re-encapsulating tunnels and routers - I suggest moving it down into it= s > > own paragraph and perhaps adding a sentence about where/how Recursive > > tunnels may be useful. > > > > - 3.3.2. LISP Forwarding State > > > > In the LISP architecture, ITRs keep just enough information to rout= e > > traffic flowing through it. > > > > "it." -> "them." > > > > Meaning that, ITRs retrieve from the > > LISP Mapping System mappings between EID prefixes and RLOCs that ar= e > > used to encapsulate packets. > > > > This is the first use of the notion of EID prefixes. That concept shou= ld > > be explained before it is used, although a forward reference to section > > 3.4.1 may suffice. It might be better to rewrite this paragraph in ter= ms > > of EIDs and leave the notion of EID prefixes to section 3.4.1. > > > > - 4.4. MTU Handling > > > > Additionally, LISP also recommends inferring reachability of locato= rs > > by using information provided by the underlay, in particular: > > > > It'd be useful to add a sentence or two about how LISP and the techniqu= es > > in this section interact with host use of PMTUD and PLPMTUD. > > > > - Next to last paragraph on p.17: > > > > Additionally, LISP also recommends inferring reachability of locato= rs > > by using information provided by the underlay, in particular: > > > > This looks like it's a paragraph early and needs to be moved down to > > after the paragraph that follows it. > > > > idnits 2.13.01 didn't find any nits. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > david.black@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > > From nobody Tue Feb 10 23:06:47 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9936D1A87A4; Tue, 10 Feb 2015 23:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcpCv14D6feb; Tue, 10 Feb 2015 23:06:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 436CA1A86F2; Tue, 10 Feb 2015 23:06:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070623.27739.48597.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:23 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 07:06:40 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Tue Feb 10 23:06:49 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 478F71A86F2; Tue, 10 Feb 2015 23:06:40 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9936D1A87A4; Tue, 10 Feb 2015 23:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcpCv14D6feb; Tue, 10 Feb 2015 23:06:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 436CA1A86F2; Tue, 10 Feb 2015 23:06:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070623.27739.48597.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:23 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 07:06:40 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Wed Feb 11 11:19:26 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503031A8ADB; Wed, 11 Feb 2015 11:19:20 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZeX6Skin-1L; Wed, 11 Feb 2015 11:19:13 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54121A8AB3; Wed, 11 Feb 2015 11:19:08 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id kx10so5877849pab.13; Wed, 11 Feb 2015 11:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4MlUd1bTb7GfTqKb/0oDHe7kW4C9x1V3lwxkKAFzmuo=; b=Wsq2q7TL1UJize75pGZlHc/850y4wrkI0TWXApFQRqIvNNAtUbeXj1+Y7z83Ol3FDA 2zWKICsUxxz30GVKPwjoszt2V3TEw2aNV459TYVg+dllsv2vm8rFzMiH3rFB1voKLNxG XPwRlGSH0G+mFYjcBRE0/rIrrlCzj2F6vX/JvuVXY3VfeQUc7mIHqryVYfLOeA52Y0UC CHO7MwUgbWfx8DX1nHnkjEjbr41ogOuamyqlNhpCljs9bVVbqu2gJhWtt8PnXzEKKdd0 vn2P9uiDBM9Lwtj7lOGkYX/6IbBPuurdLxaBa6o8kA7BhDryZDpXzv8XYPSQdknWEDhC JfEg== X-Received: by 10.66.124.137 with SMTP id mi9mr140019pab.144.1423682347981; Wed, 11 Feb 2015 11:19:07 -0800 (PST) Received: from [172.20.10.2] ([166.170.37.0]) by mx.google.com with ESMTPSA id ei3sm837366pbc.91.2015.02.11.11.19.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Feb 2015 11:19:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: <54DA982D.60200@joelhalpern.com> Date: Wed, 11 Feb 2015 11:19:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DA982D.60200@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:19:20 -0000 > I will leave most of these for the authors to comment on. See my comments inline. Thanks David for your detailed review and = commentary. > With regard to your question about incremental deployment, that is the = domain of the LISP Deployment document, and was deliberately only = lightly covered here. I am not sure what we can do to address your = comment without duplicating the entirety of that document. That is the risk we may have with many of your comments. We have a lot = of detail in the already 9 published RFCs and this document really is = to take all that detail and summarize as an easily understandable = description of a cohesive design. > With regard to UDP Zero, this was approved by the IESG and published = as an RFC. It is part of the way the protocol is defined. If there are = specific changes you would like to see in the explanatory text, I am = sure=20 Definitely agreed. In fact we instigated UDP zero. And I continually = talk to hardware engineers and they all believe we made the right = decision. So hats off to the IETF for being practical. > we could include them. If you are looking for a change in the = behavior, this document can not make changes to the LISP behavior. Yes, an important point. >> I found a couple of major issues that I hope arise from the >> summarization of LISP in this draft, as opposed to being problems in >> the actual LISP protocols. I also found a few minor issues, the most >> important of which is the need for additional security considerations >> discussion on misdelivery, with particular attention to VPNs. Thanks a ton. >> -- Major issues -- >>=20 >> [A] EID mobility vs. EID prefixes >>=20 >> - 5. Mobility >>=20 >> I understand how this works when mapping is per-EID, but how does = this work >> when the EID of the system that moves is part of an EID prefix, as = discussed >> in Section 3.4.1? Even if the answer is a long version of "Don't do = that!" >> it should be explained. No, from the start of the LISP design (circa 2007), an prefix is what = moves. And a specific EID is simply a /32 or /128 prefix. Here is a = practical example: You have a cluster of servers that communicate together for a particular = application. They application cluster is running in a set of VMs. Those = VMs are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are = currently running in a brick-and-mortar data center. Now there is a = desire to move the VM cluster to a cloud provider. What is moved is the = EID-prefix of the cluster. The mapping system is told that the = EID-prefix is changing its RLOC-set from the brick-and-mortar xTRs to = the cloud providers xTRs. >>=20 >> - 7.4. LISP for Virtual Machine Mobility in Data Centers >>=20 >> I don't understand how this works when EID prefixes are used, as each = VM >> has its own EID or EIDs, hence the entire prefix range does not move = when >> the VM moves. >>=20 >> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix = A >> of RFC 5706: Has deployment been discussed? and specifically under: >>=20 >> * Is the proposed specification deployable? If not, how = could >> it be improved? >>=20 >> as EID prefixes appear to be undeployable for Mobility and VM = Mobility usage. See above example. >> [B] LISP Multicast vs. EID/RLOC separate >>=20 >> - 6. Multicast >>=20 >> This is interesting, multicast addresses (G) look like they're an = exception They are really not. Since multicast addresses *identify* a group of = receivers, it is very much an EID and aheres to the definition of an = EID. Multicast addresses never had topological signficance but the state = representing a distribution tree does tell you were the members are (but = the identity of the members are not know in multicast). So it makes perfect sense to register multicast addresses to the mapping = system as EIDs and they can map to RLOCs of sites that have joined the = group. See draft-farinacci-signal-free-multicast as just one example. = RFC6831 and draft-farinacci-lisp-mr-signaling are other examples. >> to the EID/RLOC separation as the same destination IP multicast = address >> is used for both purposes. This could use some more discussion, as = it's >> unexpected based on the contents of the draft up to this point. I believe the level of detail we have in the introduction document is at = the right level or we'll err on having way too many details crop in. >> - 7.2. LISP for IPv6 Co-existence >>=20 >> LISP encapsulations allows to transport packets using EIDs from a >> given address family (e.g., IPv6) with packets from other address >> families (e.g., IPv4). >>=20 >> How does that work for multicast traffic, where the destination = address >> (G) has to be the same in both the inner and outer headers? Are ETRs >> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RLOC = set that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR = that receives the packet from S-EID-ipv6 would replicate the packet and = multicast encapsulate to ipv4-multicast and unicast encapsualte to = ipv4-unicast. >> - 7.3. LISP for Virtual Private Networks >>=20 >> This also has multicast problems, as there is only one instance of = each >> multicast address (G) in the underlay network. I think I can figure = out how You can map from EID-G to RLOC-G one to one. But we have seen over the = last decade in a half that with general multicast deployment that = many-to-1 is desirable. Hence, now that we have a way to map with a = network-based database, we can map multiple EID-Gs to a single (or = multiple) RLOC-Gs. >> to make multicast work for this use case, but it's not immediately = obvious, >> and the result when the same underlay multicast address is used by = more >> than one VPN could well deliver some traffic to ETRs that have to = discard This is a necessary evil when the underlay is state challenged. But it = is a state/bandwidth tradeoff. We have found with MVPN deployment that = the network admin configures the underly or simply unicasts. >> it because the Instance ID is wrong (and that excessive delivery is a >> security consideration, see minor issue on Section 8 below). I think = an >> explanation is in order. There are just too many combinations to make a high-level description = simple to understand. The current introduction text does a find job = providing references for someone to go off and get the details. >> -- Minor Issues -- >>=20 >> There seems to be an implicit assumption that the end host and its >> ITR (xTR) are in the same domain or Autonomous System. For = incremental This is true when you call the domain a "LISP site". But if the site is = unchanged and one uses PITRs, maybe even close to the site, like in a PE = router, then the PITR is definitely in another AS. But note I said PITR = and not ITR. The reason being is because an ITR is configured with = database-mapping prefixes that is uses to encapsulate packets from such = addresses. Versus the PITR being an ITR with *no database-mappings* = providing a much more larger/or more aggregtable service. >> deployment, I don't think that's always the case, but I think that = only >> has editorial impact on this document, as I don't think any of the >> fundamental LISP mechanisms are affected. The authors should look = for >> use of "domain" and "Autonomous System" and ensure that the text is >> generalized to the case where the end host and ITR are more widely >> separated. We are overloaded with terms that create topological or organization = boundary. Hence why we created "LISP site" which is also the same as a = "LISP VPN site". Where a "LISP site" that has multiple tennants would be = multiple "LISP VPN sites". >> Despite multiple mentions of incremental deployment, I did not >> see a discussion of how that might be accomplished. There is some There are PxTRs and NATs. And references to the LISP interworking RFC. >> useful content in Section 3.5, but that's at best an incomplete >> explanation. This is an OPS-Dir review concern - it falls under >> A.1.3 in Appendix A of RFC 5706: Has the migration path been = discussed? >>=20 >> - 3.3.1. LISP Encapsulation >>=20 >> the source port is selected by >> the ITR and ignored on reception. >>=20 >> Please mention multipathing (e.g., ECMP and LAG) as possible = influences >> on how source ports are selected, as this imposes some limits on what = an >> ITR can reasonably do. ECMP/LAG don't influence which source port is selected. It is a 5-tuple = hash of the inner header that selects a source port that influences how = an underlay router would load-split traffic. >> For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix = A of >> RFC 5706: Have the Requirements on other protocols and functional >> components been discussed? >>=20 >> This decision was made because the >> typical transport protocols used by the applications already = include >> a checksum, by neglecting the additional UDP encapsulation = checksum >> xTRs can forward packets more efficiently. >>=20 >> Groan! I have an exquisite set of scars on UDP zero checksums for = IPv6 >> from working on the MPLS in UDP draft, so I may be overly sensitive = to >> this concern. The downside of this efficiency is that there is no >> checksum coverage of the IPv6 header when zero UDP checksums are = used. >> That should at least be mentioned here, with a summary of why that's = ok >> - the detailed justification for why that's ok can be left to other >> documents. My head spins every time I hear about this subject. This subject has = been talked about from 100s of people for a decade. We have CRC on = links, we have apps that use TCP and UDP checksums. Nuf said. >>=20 >> -- Nits/Editorial Comments -- >>=20 >> - Top of p.4: >>=20 >> The initial motivation in the LISP effort is to be find in the >>=20 >> "find" -> "found" >>=20 >> - Section 3.1, first bullet item We will certainly fixe these. Thanks. >>=20 >> Devices are assigned with relatively opaque identity >> meaningful addresses that are independent of their topological >> location. >>=20 >> I don't understand "relatively opaque identity meaningful" and >> suggest rewriting the sentence. In particular - opaque to what? >> meaningful to what in what manner? Well beacuse it is as accurate as it can be. If automobiles are going to = be assigned EIDs from a VIN number allocation from a manufacture, the = address is relatively opaque. If a VM in a data-center is going to be = assigned an EID from the set of prefixes already being used and = allocated to that data-center, then there is a good chance that address = is in a power-of-2 block that is summarizable in the IGP. >>=20 >> - Section 3.2, second paragraph >>=20 >> Judging from the figure, xTRs are the common case, with single- >> function ITRs and ETRs being rare. It might be good to say that >> and discuss when ITRs and ETRs that are not xTRs are appropriate >> to use. When you want egress path selection to happen further out in the = toplogical from the source location, then you put an ITR-only system = there. Where ingress to the same source (destination in this direction), = the ETR can be closer to the destination. >>=20 >> - 3rd paragraph on p.7: >>=20 >>=20 >> Finally, the LISP architecture emphasizes a cost effective >> incremental deployment. >>=20 >> I'd delete "cost effective" here and look for other occurrences >> of "cost" as candidates for deletion. This is supposed to be >> a technical document, so discussion of costs is a bit off-target. Fair enough. >> - First item after Figure 2: >>=20 >> 1. HostA retrieves the EID_B of HostB, typically querying the DNS >> and obtaining and A or AAAA record. >>=20 >> "and A" -> "an A" (spelling checkers don't catch everything). Already noted and will be fixed. >>=20 >> - 3.3.1. LISP Encapsulation >>=20 >> On the other hand, Recursive >> tunnels are nested tunnels and are implemented by using multiple = LISP >> encapsulations on a packet. >>=20 >> The above sentence seems out of place in the middle of a paragraph = about >> Re-encapsulating tunnels and routers - I suggest moving it down into = its >> own paragraph and perhaps adding a sentence about where/how Recursive >> tunnels may be useful. Good suggestion and makes sense. >> - 3.3.2. LISP Forwarding State >>=20 >> In the LISP architecture, ITRs keep just enough information to = route >> traffic flowing through it. >>=20 >> "it." -> "them." >>=20 >> Meaning that, ITRs retrieve from the >> LISP Mapping System mappings between EID prefixes and RLOCs that = are >> used to encapsulate packets. >>=20 >> This is the first use of the notion of EID prefixes. That concept = should >> be explained before it is used, although a forward reference to = section >> 3.4.1 may suffice. It might be better to rewrite this paragraph in = terms >> of EIDs and leave the notion of EID prefixes to section 3.4.1. Hmm, I'll let Albert and Damien decide if we should state "EID-prefixes" = everywhere instead of just "EID". >>=20 >> - 4.4. MTU Handling >>=20 >> Additionally, LISP also recommends inferring reachability of = locators >> by using information provided by the underlay, in particular: >>=20 >> It'd be useful to add a sentence or two about how LISP and the = techniques >> in this section interact with host use of PMTUD and PLPMTUD. This is a lot of detail because in RFC6830 we have 3 positions or = options on the subject. And we did provide a reference to RFC6830 for = this topic. >> - Next to last paragraph on p.17: >>=20 >> Additionally, LISP also recommends inferring reachability of = locators >> by using information provided by the underlay, in particular: >>=20 >> This looks like it's a paragraph early and needs to be moved down to >> after the paragraph that follows it. Agree. >> idnits 2.13.01 didn't find any nits. >>=20 >> Thanks, >> --David Thanks again David. Dino From nobody Wed Feb 11 15:08:04 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EF51A8734; Wed, 11 Feb 2015 15:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-EzVczDVC19; Wed, 11 Feb 2015 15:07:30 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B991A873E; Wed, 11 Feb 2015 15:07:25 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1BN7IdT011248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 18:07:21 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t1BN7IdT011248 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423696042; bh=3tQda+WPHbyUS5o5BHYBjTQ1jOE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UlJgQHKQJJrcPE0z2zqY13yg2oCGGJdKVT9LtZJyQDpY9ih+kEXLk9mygSuKuH/tT zzv5zj4NaX8eod8pmUgykP/h2RX3JRWdxKMrILwDYQq0uiHth+gfiwspCRd6qS0EkI mHhasO2wjYZ7b9Qc/Ok3Mvaq4a1vCCLc9+TORz68= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t1BN7IdT011248 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 11 Feb 2015 18:07:09 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1BN7A5k031865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 18:07:10 -0500 Received: from MXHUB209.corp.emc.com (10.253.68.35) by mxhub33.corp.emc.com (10.254.93.81) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 11 Feb 2015 18:07:09 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB209.corp.emc.com ([10.253.68.35]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 18:07:09 -0500 From: "Black, David" To: Dino Farinacci , "Joel M. Halpern" Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 Thread-Index: AdBFiMToswN7n7S2Sw+GOUWYxLLMygALNZaAACj504AABFG2sA== Date: Wed, 11 Feb 2015 23:07:09 +0000 Message-ID: References: <54DA982D.60200@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 23:07:48 -0000 Dino - thanks for the response. On the major issues, it looks like both [A] and [B] involve only the text in this draft and nothing beyond, which is good news. I have a simple text suggestion for [A], but it looks like [B] is going to require some careful editing, as one of the primary causes is that the draft is sloppy in using the same symbol "G" to represent both EID and RLOC multicast groups. On the minor issues, I have text suggestions for three of the four, and I'd like to temporarily defer further discussion the IPv6 UDP zero checksum "tarpit" in favor of resolving everything else first. On the nits/editorial comments, all the suggestions in your email are fine with me. FWIW, I regard that portion of a review as almost entirely subject to the draft authors' discretion (and editorial taste). > >> [A] EID mobility vs. EID prefixes > > ... from the start of the LISP design (circa 2007), an prefix is what mov= es. > And a specific EID is simply a /32 or /128 prefix. Here is a practical > example: A statement that the mobility use cases need to employ /32 and /128 prefixe= s, and not anything coarser should suffice. That should be added to Section 5= . > >> [B] LISP Multicast vs. EID/RLOC separate > >> > >> - 6. Multicast > >> > >> This is interesting, multicast addresses (G) look like they're an exce= ption >=20 > They are really not. My concern is that as I read the draft, it leaves me with the strong impres= sion that the same multicast addresses (G) are being used in both the overlay (as EIDs) and the underlay (as RLOCs). From your response, I conclude that= this is not the case (and I have no argument with that). Rather, Section 6 need= s to bluntly state that multicast addresses are mapped between EID and RLOC spac= e at both ITRs and ETRs, so that the following inference is obvious from the tex= t (it's currently not obvious): > So it makes perfect sense to register multicast addresses to the mapping > system as EIDs and they can map to RLOCs of sites that have joined the gr= oup. As part of this, I strongly recommend moving away from use of "G" to refer = to multicast groups in both the overlay and underlay. Careful use of G-EID and G-RLOC would significantly improve clarity. --- If the above are done for [A] and [B] in Sections 5 and 6, then the text fo= r the use cases in Section 7 should not need further attention. --- > >> -- Minor Issues -- > >> > >> There seems to be an implicit assumption that the end host and its > >> ITR (xTR) are in the same domain or Autonomous System. For incrementa= l >=20 > This is true when you call the domain a "LISP site". But if the site is > unchanged and one uses PITRs, maybe even close to the site, like in a PE > router, then the PITR is definitely in another AS. Looking at the text, it seems that "LISP site" and "domain" are the same concept for this draft. That would be useful to state, IMHO but I'll leave the decision on whether to do so to you and the draft authors. On rereading, my concerns seem to be triggered mostly by this sentence in Section 3.2: The edge consists of LISP sites (e.g., an Autonomous System) that use EID addresses. I think a small change to the last sentence in that paragraph would resolve my concern without distracting from the narrative: OLD EIDs do not contain inter-domain topological information and because of this, EIDs are usually routable at the edge (within LISP sites) or in the non-LISP Internet. NEW EIDs do not contain inter-domain topological information and because of this, EIDs are usually routable at the edge (within LISP sites) or in the non-LISP Internet; see Section 3.5 for discussion of LISP site internetworking with non-LISP sites and domains in the Internet. > >> Despite multiple mentions of incremental deployment, I did not > >> see a discussion of how that might be accomplished. >=20 > There are PxTRs and NATs. And references to the LISP interworking RFC. Ok, can we just say so in Section 3.5? Adding the following sentence to the end of the section would suffice: PITRs, PETRs and LISP-NAT support incremental deployment of LISP by providing significant flexibility in location of the boundaries between the LISP and non-LISP portions of the network, and making it reasonable to change those boundaries over time. > >> - 3.3.1. LISP Encapsulation > >> > >> the source port is selected by > >> the ITR and ignored on reception. > >> > >> Please mention multipathing (e.g., ECMP and LAG) as possible influence= s > >> on how source ports are selected, as this imposes some limits on what = an > >> ITR can reasonably do. >=20 > ECMP/LAG don't influence which source port is selected. It is a 5-tuple h= ash > of the inner header that selects a source port that influences how an und= erlay > router would load-split traffic. Please state that a 5-tuple hash is used. ECMP/LAG is among the important reasons why, but that doesn't need to be stated if you prefer not to. An example of something that needs to be excluded is that using a random number generator to set the source port would be wrong - I could suggest citing draft-ietf-dart-dscp-rtp for related discussion (and lots more details), but I don't think that's necessary. -- IPv6 zero UDP checksum > My head spins every time I hear about this subject. This subject has been > talked about from 100s of people for a decade. We have CRC on links, we h= ave > apps that use TCP and UDP checksums. Nuf said. Understood - there's more than one set of scars on this one :-(. Let's com= e back to this topic after we've resolved everything else, and please keep in mind that I tagged this as a minor issue, not a major one (e.g., the above chang= es for [A] and [B] are far more important, IMHO). Thanks, --David > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Wednesday, February 11, 2015 2:19 PM > To: Joel M. Halpern > Cc: Black, David; Albert Cabellos; Damien Saucez; ops-dir@ietf.org; > ietf@ietf.org; lisp@ietf.org > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >=20 > > I will leave most of these for the authors to comment on. >=20 > See my comments inline. Thanks David for your detailed review and comment= ary. >=20 > > With regard to your question about incremental deployment, that is the > domain of the LISP Deployment document, and was deliberately only lightly > covered here. I am not sure what we can do to address your comment witho= ut > duplicating the entirety of that document. >=20 > That is the risk we may have with many of your comments. We have a lot of > detail in the already 9 published RFCs and this document really is to ta= ke > all that detail and summarize as an easily understandable description of = a > cohesive design. >=20 > > With regard to UDP Zero, this was approved by the IESG and published as= an > RFC. It is part of the way the protocol is defined. If there are specif= ic > changes you would like to see in the explanatory text, I am sure >=20 > Definitely agreed. In fact we instigated UDP zero. And I continually talk= to > hardware engineers and they all believe we made the right decision. So ha= ts > off to the IETF for being practical. >=20 > > we could include them. If you are looking for a change in the behavior= , > this document can not make changes to the LISP behavior. >=20 > Yes, an important point. >=20 > >> I found a couple of major issues that I hope arise from the > >> summarization of LISP in this draft, as opposed to being problems in > >> the actual LISP protocols. I also found a few minor issues, the most > >> important of which is the need for additional security considerations > >> discussion on misdelivery, with particular attention to VPNs. >=20 > Thanks a ton. >=20 > >> -- Major issues -- > >> > >> [A] EID mobility vs. EID prefixes > >> > >> - 5. Mobility > >> > >> I understand how this works when mapping is per-EID, but how does this= work > >> when the EID of the system that moves is part of an EID prefix, as > discussed > >> in Section 3.4.1? Even if the answer is a long version of "Don't do t= hat!" > >> it should be explained. >=20 > No, from the start of the LISP design (circa 2007), an prefix is what mov= es. > And a specific EID is simply a /32 or /128 prefix. Here is a practical > example: >=20 > You have a cluster of servers that communicate together for a particular > application. They application cluster is running in a set of VMs. Those V= Ms > are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are curr= ently > running in a brick-and-mortar data center. Now there is a desire to move = the > VM cluster to a cloud provider. What is moved is the EID-prefix of the > cluster. The mapping system is told that the EID-prefix is changing its R= LOC- > set from the brick-and-mortar xTRs to the cloud providers xTRs. >=20 > >> > >> - 7.4. LISP for Virtual Machine Mobility in Data Centers > >> > >> I don't understand how this works when EID prefixes are used, as each = VM > >> has its own EID or EIDs, hence the entire prefix range does not move w= hen > >> the VM moves. > >> > >> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix A > >> of RFC 5706: Has deployment been discussed? and specifically under: > >> > >> * Is the proposed specification deployable? If not, how could > >> it be improved? > >> > >> as EID prefixes appear to be undeployable for Mobility and VM Mobility > usage. >=20 > See above example. >=20 > >> [B] LISP Multicast vs. EID/RLOC separate > >> > >> - 6. Multicast > >> > >> This is interesting, multicast addresses (G) look like they're an exce= ption >=20 > They are really not. Since multicast addresses *identify* a group of > receivers, it is very much an EID and aheres to the definition of an EID. > Multicast addresses never had topological signficance but the state > representing a distribution tree does tell you were the members are (but = the > identity of the members are not know in multicast). >=20 > So it makes perfect sense to register multicast addresses to the mapping > system as EIDs and they can map to RLOCs of sites that have joined the gr= oup. > See draft-farinacci-signal-free-multicast as just one example. RFC6831 an= d > draft-farinacci-lisp-mr-signaling are other examples. >=20 > >> to the EID/RLOC separation as the same destination IP multicast addres= s > >> is used for both purposes. This could use some more discussion, as it= 's > >> unexpected based on the contents of the draft up to this point. >=20 > I believe the level of detail we have in the introduction document is at = the > right level or we'll err on having way too many details crop in. >=20 > >> - 7.2. LISP for IPv6 Co-existence > >> > >> LISP encapsulations allows to transport packets using EIDs from a > >> given address family (e.g., IPv6) with packets from other address > >> families (e.g., IPv4). > >> > >> How does that work for multicast traffic, where the destination addres= s > >> (G) has to be the same in both the inner and outer headers? Are ETRs > >> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? >=20 > The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RLOC = set > that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that > receives the packet from S-EID-ipv6 would replicate the packet and multic= ast > encapsulate to ipv4-multicast and unicast encapsualte to ipv4-unicast. >=20 > >> - 7.3. LISP for Virtual Private Networks > >> > >> This also has multicast problems, as there is only one instance of eac= h > >> multicast address (G) in the underlay network. I think I can figure o= ut > how >=20 > You can map from EID-G to RLOC-G one to one. But we have seen over the la= st > decade in a half that with general multicast deployment that many-to-1 is > desirable. Hence, now that we have a way to map with a network-based data= base, > we can map multiple EID-Gs to a single (or multiple) RLOC-Gs. >=20 > >> to make multicast work for this use case, but it's not immediately obv= ious, > >> and the result when the same underlay multicast address is used by mor= e > >> than one VPN could well deliver some traffic to ETRs that have to disc= ard >=20 > This is a necessary evil when the underlay is state challenged. But it is= a > state/bandwidth tradeoff. We have found with MVPN deployment that the net= work > admin configures the underly or simply unicasts. >=20 > >> it because the Instance ID is wrong (and that excessive delivery is a > >> security consideration, see minor issue on Section 8 below). I think = an > >> explanation is in order. >=20 > There are just too many combinations to make a high-level description sim= ple > to understand. The current introduction text does a find job providing > references for someone to go off and get the details. >=20 > >> -- Minor Issues -- > >> > >> There seems to be an implicit assumption that the end host and its > >> ITR (xTR) are in the same domain or Autonomous System. For incrementa= l >=20 > This is true when you call the domain a "LISP site". But if the site is > unchanged and one uses PITRs, maybe even close to the site, like in a PE > router, then the PITR is definitely in another AS. But note I said PITR a= nd > not ITR. The reason being is because an ITR is configured with database- > mapping prefixes that is uses to encapsulate packets from such addresses. > Versus the PITR being an ITR with *no database-mappings* providing a much= more > larger/or more aggregtable service. >=20 > >> deployment, I don't think that's always the case, but I think that onl= y > >> has editorial impact on this document, as I don't think any of the > >> fundamental LISP mechanisms are affected. The authors should look for > >> use of "domain" and "Autonomous System" and ensure that the text is > >> generalized to the case where the end host and ITR are more widely > >> separated. >=20 > We are overloaded with terms that create topological or organization boun= dary. > Hence why we created "LISP site" which is also the same as a "LISP VPN si= te". > Where a "LISP site" that has multiple tennants would be multiple "LISP VP= N > sites". >=20 > >> Despite multiple mentions of incremental deployment, I did not > >> see a discussion of how that might be accomplished. There is some >=20 > There are PxTRs and NATs. And references to the LISP interworking RFC. >=20 > >> useful content in Section 3.5, but that's at best an incomplete > >> explanation. This is an OPS-Dir review concern - it falls under > >> A.1.3 in Appendix A of RFC 5706: Has the migration path been discussed= ? > >> > >> - 3.3.1. LISP Encapsulation > >> > >> the source port is selected by > >> the ITR and ignored on reception. > >> > >> Please mention multipathing (e.g., ECMP and LAG) as possible influence= s > >> on how source ports are selected, as this imposes some limits on what = an > >> ITR can reasonably do. >=20 > ECMP/LAG don't influence which source port is selected. It is a 5-tuple h= ash > of the inner header that selects a source port that influences how an und= erlay > router would load-split traffic. >=20 > >> For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix A= of > >> RFC 5706: Have the Requirements on other protocols and functional > >> components been discussed? > >> > >> This decision was made because the > >> typical transport protocols used by the applications already includ= e > >> a checksum, by neglecting the additional UDP encapsulation checksum > >> xTRs can forward packets more efficiently. > >> > >> Groan! I have an exquisite set of scars on UDP zero checksums for IPv= 6 > >> from working on the MPLS in UDP draft, so I may be overly sensitive to > >> this concern. The downside of this efficiency is that there is no > >> checksum coverage of the IPv6 header when zero UDP checksums are used. > >> That should at least be mentioned here, with a summary of why that's o= k > >> - the detailed justification for why that's ok can be left to other > >> documents. >=20 > My head spins every time I hear about this subject. This subject has been > talked about from 100s of people for a decade. We have CRC on links, we h= ave > apps that use TCP and UDP checksums. Nuf said. >=20 > >> > >> -- Nits/Editorial Comments -- > >> > >> - Top of p.4: > >> > >> The initial motivation in the LISP effort is to be find in the > >> > >> "find" -> "found" > >> > >> - Section 3.1, first bullet item >=20 > We will certainly fixe these. Thanks. >=20 > >> > >> Devices are assigned with relatively opaque identity > >> meaningful addresses that are independent of their topological > >> location. > >> > >> I don't understand "relatively opaque identity meaningful" and > >> suggest rewriting the sentence. In particular - opaque to what? > >> meaningful to what in what manner? >=20 > Well beacuse it is as accurate as it can be. If automobiles are going to = be > assigned EIDs from a VIN number allocation from a manufacture, the addres= s is > relatively opaque. If a VM in a data-center is going to be assigned an EI= D > from the set of prefixes already being used and allocated to that data-ce= nter, > then there is a good chance that address is in a power-of-2 block that is > summarizable in the IGP. >=20 > >> > >> - Section 3.2, second paragraph > >> > >> Judging from the figure, xTRs are the common case, with single- > >> function ITRs and ETRs being rare. It might be good to say that > >> and discuss when ITRs and ETRs that are not xTRs are appropriate > >> to use. >=20 > When you want egress path selection to happen further out in the toplogic= al > from the source location, then you put an ITR-only system there. Where in= gress > to the same source (destination in this direction), the ETR can be closer= to > the destination. >=20 > >> > >> - 3rd paragraph on p.7: > >> > >> > >> Finally, the LISP architecture emphasizes a cost effective > >> incremental deployment. > >> > >> I'd delete "cost effective" here and look for other occurrences > >> of "cost" as candidates for deletion. This is supposed to be > >> a technical document, so discussion of costs is a bit off-target. >=20 > Fair enough. >=20 > >> - First item after Figure 2: > >> > >> 1. HostA retrieves the EID_B of HostB, typically querying the DNS > >> and obtaining and A or AAAA record. > >> > >> "and A" -> "an A" (spelling checkers don't catch everything). >=20 > Already noted and will be fixed. >=20 > >> > >> - 3.3.1. LISP Encapsulation > >> > >> On the other hand, Recursive > >> tunnels are nested tunnels and are implemented by using multiple LI= SP > >> encapsulations on a packet. > >> > >> The above sentence seems out of place in the middle of a paragraph abo= ut > >> Re-encapsulating tunnels and routers - I suggest moving it down into i= ts > >> own paragraph and perhaps adding a sentence about where/how Recursive > >> tunnels may be useful. >=20 > Good suggestion and makes sense. >=20 > >> - 3.3.2. LISP Forwarding State > >> > >> In the LISP architecture, ITRs keep just enough information to rout= e > >> traffic flowing through it. > >> > >> "it." -> "them." > >> > >> Meaning that, ITRs retrieve from the > >> LISP Mapping System mappings between EID prefixes and RLOCs that ar= e > >> used to encapsulate packets. > >> > >> This is the first use of the notion of EID prefixes. That concept sho= uld > >> be explained before it is used, although a forward reference to sectio= n > >> 3.4.1 may suffice. It might be better to rewrite this paragraph in te= rms > >> of EIDs and leave the notion of EID prefixes to section 3.4.1. >=20 > Hmm, I'll let Albert and Damien decide if we should state "EID-prefixes" > everywhere instead of just "EID". >=20 > >> > >> - 4.4. MTU Handling > >> > >> Additionally, LISP also recommends inferring reachability of locato= rs > >> by using information provided by the underlay, in particular: > >> > >> It'd be useful to add a sentence or two about how LISP and the techniq= ues > >> in this section interact with host use of PMTUD and PLPMTUD. >=20 > This is a lot of detail because in RFC6830 we have 3 positions or options= on > the subject. And we did provide a reference to RFC6830 for this topic. >=20 > >> - Next to last paragraph on p.17: > >> > >> Additionally, LISP also recommends inferring reachability of locato= rs > >> by using information provided by the underlay, in particular: > >> > >> This looks like it's a paragraph early and needs to be moved down to > >> after the paragraph that follows it. >=20 > Agree. >=20 > >> idnits 2.13.01 didn't find any nits. > >> > >> Thanks, > >> --David >=20 > Thanks again David. >=20 > Dino From nobody Wed Feb 11 15:33:15 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3D1A0163; Wed, 11 Feb 2015 15:33:10 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lpOTxYI2Kzj; Wed, 11 Feb 2015 15:33:00 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609151A0143; Wed, 11 Feb 2015 15:33:00 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id l13so1244005iga.1; Wed, 11 Feb 2015 15:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZCM3k6EkE0qhy6JM8uoApjA/2FIxAfuqC12BUltxqOY=; b=bdUdq+6drC47sKDYVdzPDoAhVsE+4L6VKBpuuYdbQkThGV4n9HGPIELgBB5NANwfqq n+vC2U3FEhI4RS8lFhdLCYGWDbyl8yNcmuy82UPhs3y7rn3OGOEMKrk+TSKCZvQ6Jq4/ YGfY83iOisB5H+4KQrjm9X7/rQgcY2wUytaupv9Y4uw1NHaEIkhB4k+PY0NhHCEPaADo YzosLTD7ROMwQbzvyxY8vkaYBaxzHWBQOz3L4gEbOfo3YH4kPruxr0amCwTT9bYyhqax eWl2R3D929XqeGsOVtOEeyifkPzU2NhWvtyQVOi72M4ELt6vUVsPWULhREWOYIKXS+qb ElXg== MIME-Version: 1.0 X-Received: by 10.50.107.36 with SMTP id gz4mr547655igb.25.1423697579461; Wed, 11 Feb 2015 15:32:59 -0800 (PST) Received: by 10.107.8.36 with HTTP; Wed, 11 Feb 2015 15:32:59 -0800 (PST) In-Reply-To: References: <54DA982D.60200@joelhalpern.com> Date: Thu, 12 Feb 2015 00:32:59 +0100 Message-ID: From: Albert Cabellos To: "Black, David" Content-Type: multipart/alternative; boundary=047d7b1117bf7dd4f8050ed86cef Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 23:33:10 -0000 --047d7b1117bf7dd4f8050ed86cef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David Thanks for your comments, I am parsing them and I=C2=B4ll suggest new text aiming to address them ASAP. I would also like to better understand [A] before doing this. With LISP an EID-preifx can have an arbitrary length and can move (i.e., change its RLOC bindings), in the specific case of a VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively). What doesn't work is the mobility of a node (assigned with a /32 or /128) *within* a coarser EID-prefix, in this case you need to split the prefix into more specifics and register them independently in the Mapping System, effectively creating new EID-prefixes. Please let me know if this clarifies your comment, in this case I will suggest new text for Section 5. Albert On Thu, Feb 12, 2015 at 12:07 AM, Black, David wrote: > Dino - thanks for the response. > > On the major issues, it looks like both [A] and [B] involve only the text > in this draft and nothing beyond, which is good news. I have a simple te= xt > suggestion for [A], but it looks like [B] is going to require some carefu= l > editing, as one of the primary causes is that the draft is sloppy in usin= g > the same symbol "G" to represent both EID and RLOC multicast groups. > > On the minor issues, I have text suggestions for three of the four, and > I'd like to temporarily defer further discussion the IPv6 UDP zero > checksum "tarpit" in favor of resolving everything else first. > > On the nits/editorial comments, all the suggestions in your email are fin= e > with me. FWIW, I regard that portion of a review as almost entirely > subject to the draft authors' discretion (and editorial taste). > > > >> [A] EID mobility vs. EID prefixes > > > > ... from the start of the LISP design (circa 2007), an prefix is what > moves. > > And a specific EID is simply a /32 or /128 prefix. Here is a practical > > example: > > A statement that the mobility use cases need to employ /32 and /128 > prefixes, > and not anything coarser should suffice. That should be added to Section > 5. > > > >> [B] LISP Multicast vs. EID/RLOC separate > > >> > > >> - 6. Multicast > > >> > > >> This is interesting, multicast addresses (G) look like they're an > exception > > > > They are really not. > > My concern is that as I read the draft, it leaves me with the strong > impression > that the same multicast addresses (G) are being used in both the overlay > (as EIDs) and the underlay (as RLOCs). From your response, I conclude > that this > is not the case (and I have no argument with that). Rather, Section 6 > needs to > bluntly state that multicast addresses are mapped between EID and RLOC > space at > both ITRs and ETRs, so that the following inference is obvious from the > text > (it's currently not obvious): > > > So it makes perfect sense to register multicast addresses to the mappin= g > > system as EIDs and they can map to RLOCs of sites that have joined the > group. > > As part of this, I strongly recommend moving away from use of "G" to refe= r > to > multicast groups in both the overlay and underlay. Careful use of G-EID > and G-RLOC would significantly improve clarity. > > --- > If the above are done for [A] and [B] in Sections 5 and 6, then the text > for the > use cases in Section 7 should not need further attention. > --- > > > >> -- Minor Issues -- > > >> > > >> There seems to be an implicit assumption that the end host and its > > >> ITR (xTR) are in the same domain or Autonomous System. For > incremental > > > > This is true when you call the domain a "LISP site". But if the site is > > unchanged and one uses PITRs, maybe even close to the site, like in a P= E > > router, then the PITR is definitely in another AS. > > Looking at the text, it seems that "LISP site" and "domain" are the same > concept for this draft. That would be useful to state, IMHO but I'll lea= ve > the decision on whether to do so to you and the draft authors. > > On rereading, my concerns seem to be triggered mostly by this sentence in > Section 3.2: > > The edge consists of LISP sites (e.g., an > Autonomous System) that use EID addresses. > > I think a small change to the last sentence in that paragraph would resol= ve > my concern without distracting from the narrative: > > OLD > EIDs do not > contain inter-domain topological information and because of this, > EIDs are usually routable at the edge (within LISP sites) or in the > non-LISP Internet. > NEW > EIDs do not > contain inter-domain topological information and because of this, > EIDs are usually routable at the edge (within LISP sites) or in the > non-LISP Internet; see Section 3.5 for discussion of LISP site > internetworking with non-LISP sites and domains in the Internet. > > > >> Despite multiple mentions of incremental deployment, I did not > > >> see a discussion of how that might be accomplished. > > > > There are PxTRs and NATs. And references to the LISP interworking RFC. > > Ok, can we just say so in Section 3.5? Adding the following sentence > to the end of the section would suffice: > > PITRs, PETRs and LISP-NAT support incremental deployment of LISP > by providing significant flexibility in location of the boundaries > between the LISP and non-LISP portions of the network, and making > it reasonable to change those boundaries over time. > > > >> - 3.3.1. LISP Encapsulation > > >> > > >> the source port is selected by > > >> the ITR and ignored on reception. > > >> > > >> Please mention multipathing (e.g., ECMP and LAG) as possible > influences > > >> on how source ports are selected, as this imposes some limits on wha= t > an > > >> ITR can reasonably do. > > > > ECMP/LAG don't influence which source port is selected. It is a 5-tuple > hash > > of the inner header that selects a source port that influences how an > underlay > > router would load-split traffic. > > Please state that a 5-tuple hash is used. ECMP/LAG is among the importan= t > reasons why, but that doesn't need to be stated if you prefer not to. An > example of something that needs to be excluded is that using a random > number generator to set the source port would be wrong - I could suggest > citing draft-ietf-dart-dscp-rtp for related discussion (and lots more > details), but I don't think that's necessary. > > -- IPv6 zero UDP checksum > > > My head spins every time I hear about this subject. This subject has be= en > > talked about from 100s of people for a decade. We have CRC on links, we > have > > apps that use TCP and UDP checksums. Nuf said. > > Understood - there's more than one set of scars on this one :-(. Let's > come back > to this topic after we've resolved everything else, and please keep in mi= nd > that I tagged this as a minor issue, not a major one (e.g., the above > changes > for [A] and [B] are far more important, IMHO). > > Thanks, > --David > > > -----Original Message----- > > From: Dino Farinacci [mailto:farinacci@gmail.com] > > Sent: Wednesday, February 11, 2015 2:19 PM > > To: Joel M. Halpern > > Cc: Black, David; Albert Cabellos; Damien Saucez; ops-dir@ietf.org; > > ietf@ietf.org; lisp@ietf.org > > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 > > > > > I will leave most of these for the authors to comment on. > > > > See my comments inline. Thanks David for your detailed review and > commentary. > > > > > With regard to your question about incremental deployment, that is th= e > > domain of the LISP Deployment document, and was deliberately only light= ly > > covered here. I am not sure what we can do to address your comment > without > > duplicating the entirety of that document. > > > > That is the risk we may have with many of your comments. We have a lot = of > > detail in the already 9 published RFCs and this document really is to > take > > all that detail and summarize as an easily understandable description o= f > a > > cohesive design. > > > > > With regard to UDP Zero, this was approved by the IESG and published > as an > > RFC. It is part of the way the protocol is defined. If there are > specific > > changes you would like to see in the explanatory text, I am sure > > > > Definitely agreed. In fact we instigated UDP zero. And I continually > talk to > > hardware engineers and they all believe we made the right decision. So > hats > > off to the IETF for being practical. > > > > > we could include them. If you are looking for a change in the > behavior, > > this document can not make changes to the LISP behavior. > > > > Yes, an important point. > > > > >> I found a couple of major issues that I hope arise from the > > >> summarization of LISP in this draft, as opposed to being problems in > > >> the actual LISP protocols. I also found a few minor issues, the mos= t > > >> important of which is the need for additional security consideration= s > > >> discussion on misdelivery, with particular attention to VPNs. > > > > Thanks a ton. > > > > >> -- Major issues -- > > >> > > >> [A] EID mobility vs. EID prefixes > > >> > > >> - 5. Mobility > > >> > > >> I understand how this works when mapping is per-EID, but how does > this work > > >> when the EID of the system that moves is part of an EID prefix, as > > discussed > > >> in Section 3.4.1? Even if the answer is a long version of "Don't do > that!" > > >> it should be explained. > > > > No, from the start of the LISP design (circa 2007), an prefix is what > moves. > > And a specific EID is simply a /32 or /128 prefix. Here is a practical > > example: > > > > You have a cluster of servers that communicate together for a particula= r > > application. They application cluster is running in a set of VMs. Those > VMs > > are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are > currently > > running in a brick-and-mortar data center. Now there is a desire to mov= e > the > > VM cluster to a cloud provider. What is moved is the EID-prefix of the > > cluster. The mapping system is told that the EID-prefix is changing its > RLOC- > > set from the brick-and-mortar xTRs to the cloud providers xTRs. > > > > >> > > >> - 7.4. LISP for Virtual Machine Mobility in Data Centers > > >> > > >> I don't understand how this works when EID prefixes are used, as eac= h > VM > > >> has its own EID or EIDs, hence the entire prefix range does not move > when > > >> the VM moves. > > >> > > >> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix= A > > >> of RFC 5706: Has deployment been discussed? and specifically under: > > >> > > >> * Is the proposed specification deployable? If not, how cou= ld > > >> it be improved? > > >> > > >> as EID prefixes appear to be undeployable for Mobility and VM Mobili= ty > > usage. > > > > See above example. > > > > >> [B] LISP Multicast vs. EID/RLOC separate > > >> > > >> - 6. Multicast > > >> > > >> This is interesting, multicast addresses (G) look like they're an > exception > > > > They are really not. Since multicast addresses *identify* a group of > > receivers, it is very much an EID and aheres to the definition of an EI= D. > > Multicast addresses never had topological signficance but the state > > representing a distribution tree does tell you were the members are (bu= t > the > > identity of the members are not know in multicast). > > > > So it makes perfect sense to register multicast addresses to the mappin= g > > system as EIDs and they can map to RLOCs of sites that have joined the > group. > > See draft-farinacci-signal-free-multicast as just one example. RFC6831 > and > > draft-farinacci-lisp-mr-signaling are other examples. > > > > >> to the EID/RLOC separation as the same destination IP multicast > address > > >> is used for both purposes. This could use some more discussion, as > it's > > >> unexpected based on the contents of the draft up to this point. > > > > I believe the level of detail we have in the introduction document is a= t > the > > right level or we'll err on having way too many details crop in. > > > > >> - 7.2. LISP for IPv6 Co-existence > > >> > > >> LISP encapsulations allows to transport packets using EIDs from a > > >> given address family (e.g., IPv6) with packets from other address > > >> families (e.g., IPv4). > > >> > > >> How does that work for multicast traffic, where the destination > address > > >> (G) has to be the same in both the inner and outer headers? Are ETR= s > > >> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? > > > > The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RLO= C > set > > that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that > > receives the packet from S-EID-ipv6 would replicate the packet and > multicast > > encapsulate to ipv4-multicast and unicast encapsualte to ipv4-unicast. > > > > >> - 7.3. LISP for Virtual Private Networks > > >> > > >> This also has multicast problems, as there is only one instance of > each > > >> multicast address (G) in the underlay network. I think I can figure > out > > how > > > > You can map from EID-G to RLOC-G one to one. But we have seen over the > last > > decade in a half that with general multicast deployment that many-to-1 = is > > desirable. Hence, now that we have a way to map with a network-based > database, > > we can map multiple EID-Gs to a single (or multiple) RLOC-Gs. > > > > >> to make multicast work for this use case, but it's not immediately > obvious, > > >> and the result when the same underlay multicast address is used by > more > > >> than one VPN could well deliver some traffic to ETRs that have to > discard > > > > This is a necessary evil when the underlay is state challenged. But it > is a > > state/bandwidth tradeoff. We have found with MVPN deployment that the > network > > admin configures the underly or simply unicasts. > > > > >> it because the Instance ID is wrong (and that excessive delivery is = a > > >> security consideration, see minor issue on Section 8 below). I thin= k > an > > >> explanation is in order. > > > > There are just too many combinations to make a high-level description > simple > > to understand. The current introduction text does a find job providing > > references for someone to go off and get the details. > > > > >> -- Minor Issues -- > > >> > > >> There seems to be an implicit assumption that the end host and its > > >> ITR (xTR) are in the same domain or Autonomous System. For > incremental > > > > This is true when you call the domain a "LISP site". But if the site is > > unchanged and one uses PITRs, maybe even close to the site, like in a P= E > > router, then the PITR is definitely in another AS. But note I said PITR > and > > not ITR. The reason being is because an ITR is configured with database= - > > mapping prefixes that is uses to encapsulate packets from such addresse= s. > > Versus the PITR being an ITR with *no database-mappings* providing a > much more > > larger/or more aggregtable service. > > > > >> deployment, I don't think that's always the case, but I think that > only > > >> has editorial impact on this document, as I don't think any of the > > >> fundamental LISP mechanisms are affected. The authors should look f= or > > >> use of "domain" and "Autonomous System" and ensure that the text is > > >> generalized to the case where the end host and ITR are more widely > > >> separated. > > > > We are overloaded with terms that create topological or organization > boundary. > > Hence why we created "LISP site" which is also the same as a "LISP VPN > site". > > Where a "LISP site" that has multiple tennants would be multiple "LISP > VPN > > sites". > > > > >> Despite multiple mentions of incremental deployment, I did not > > >> see a discussion of how that might be accomplished. There is some > > > > There are PxTRs and NATs. And references to the LISP interworking RFC. > > > > >> useful content in Section 3.5, but that's at best an incomplete > > >> explanation. This is an OPS-Dir review concern - it falls under > > >> A.1.3 in Appendix A of RFC 5706: Has the migration path been > discussed? > > >> > > >> - 3.3.1. LISP Encapsulation > > >> > > >> the source port is selected by > > >> the ITR and ignored on reception. > > >> > > >> Please mention multipathing (e.g., ECMP and LAG) as possible > influences > > >> on how source ports are selected, as this imposes some limits on wha= t > an > > >> ITR can reasonably do. > > > > ECMP/LAG don't influence which source port is selected. It is a 5-tuple > hash > > of the inner header that selects a source port that influences how an > underlay > > router would load-split traffic. > > > > >> For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix > A of > > >> RFC 5706: Have the Requirements on other protocols and functional > > >> components been discussed? > > >> > > >> This decision was made because the > > >> typical transport protocols used by the applications already > include > > >> a checksum, by neglecting the additional UDP encapsulation checks= um > > >> xTRs can forward packets more efficiently. > > >> > > >> Groan! I have an exquisite set of scars on UDP zero checksums for > IPv6 > > >> from working on the MPLS in UDP draft, so I may be overly sensitive = to > > >> this concern. The downside of this efficiency is that there is no > > >> checksum coverage of the IPv6 header when zero UDP checksums are use= d. > > >> That should at least be mentioned here, with a summary of why that's > ok > > >> - the detailed justification for why that's ok can be left to other > > >> documents. > > > > My head spins every time I hear about this subject. This subject has be= en > > talked about from 100s of people for a decade. We have CRC on links, we > have > > apps that use TCP and UDP checksums. Nuf said. > > > > >> > > >> -- Nits/Editorial Comments -- > > >> > > >> - Top of p.4: > > >> > > >> The initial motivation in the LISP effort is to be find in the > > >> > > >> "find" -> "found" > > >> > > >> - Section 3.1, first bullet item > > > > We will certainly fixe these. Thanks. > > > > >> > > >> Devices are assigned with relatively opaque identity > > >> meaningful addresses that are independent of their topological > > >> location. > > >> > > >> I don't understand "relatively opaque identity meaningful" and > > >> suggest rewriting the sentence. In particular - opaque to what? > > >> meaningful to what in what manner? > > > > Well beacuse it is as accurate as it can be. If automobiles are going t= o > be > > assigned EIDs from a VIN number allocation from a manufacture, the > address is > > relatively opaque. If a VM in a data-center is going to be assigned an > EID > > from the set of prefixes already being used and allocated to that > data-center, > > then there is a good chance that address is in a power-of-2 block that = is > > summarizable in the IGP. > > > > >> > > >> - Section 3.2, second paragraph > > >> > > >> Judging from the figure, xTRs are the common case, with single- > > >> function ITRs and ETRs being rare. It might be good to say that > > >> and discuss when ITRs and ETRs that are not xTRs are appropriate > > >> to use. > > > > When you want egress path selection to happen further out in the > toplogical > > from the source location, then you put an ITR-only system there. Where > ingress > > to the same source (destination in this direction), the ETR can be > closer to > > the destination. > > > > >> > > >> - 3rd paragraph on p.7: > > >> > > >> > > >> Finally, the LISP architecture emphasizes a cost effective > > >> incremental deployment. > > >> > > >> I'd delete "cost effective" here and look for other occurrences > > >> of "cost" as candidates for deletion. This is supposed to be > > >> a technical document, so discussion of costs is a bit off-target. > > > > Fair enough. > > > > >> - First item after Figure 2: > > >> > > >> 1. HostA retrieves the EID_B of HostB, typically querying the DN= S > > >> and obtaining and A or AAAA record. > > >> > > >> "and A" -> "an A" (spelling checkers don't catch everything). > > > > Already noted and will be fixed. > > > > >> > > >> - 3.3.1. LISP Encapsulation > > >> > > >> On the other hand, Recursive > > >> tunnels are nested tunnels and are implemented by using multiple > LISP > > >> encapsulations on a packet. > > >> > > >> The above sentence seems out of place in the middle of a paragraph > about > > >> Re-encapsulating tunnels and routers - I suggest moving it down into > its > > >> own paragraph and perhaps adding a sentence about where/how Recursiv= e > > >> tunnels may be useful. > > > > Good suggestion and makes sense. > > > > >> - 3.3.2. LISP Forwarding State > > >> > > >> In the LISP architecture, ITRs keep just enough information to > route > > >> traffic flowing through it. > > >> > > >> "it." -> "them." > > >> > > >> Meaning that, ITRs retrieve from the > > >> LISP Mapping System mappings between EID prefixes and RLOCs that > are > > >> used to encapsulate packets. > > >> > > >> This is the first use of the notion of EID prefixes. That concept > should > > >> be explained before it is used, although a forward reference to > section > > >> 3.4.1 may suffice. It might be better to rewrite this paragraph in > terms > > >> of EIDs and leave the notion of EID prefixes to section 3.4.1. > > > > Hmm, I'll let Albert and Damien decide if we should state "EID-prefixes= " > > everywhere instead of just "EID". > > > > >> > > >> - 4.4. MTU Handling > > >> > > >> Additionally, LISP also recommends inferring reachability of > locators > > >> by using information provided by the underlay, in particular: > > >> > > >> It'd be useful to add a sentence or two about how LISP and the > techniques > > >> in this section interact with host use of PMTUD and PLPMTUD. > > > > This is a lot of detail because in RFC6830 we have 3 positions or > options on > > the subject. And we did provide a reference to RFC6830 for this topic. > > > > >> - Next to last paragraph on p.17: > > >> > > >> Additionally, LISP also recommends inferring reachability of > locators > > >> by using information provided by the underlay, in particular: > > >> > > >> This looks like it's a paragraph early and needs to be moved down to > > >> after the paragraph that follows it. > > > > Agree. > > > > >> idnits 2.13.01 didn't find any nits. > > >> > > >> Thanks, > > >> --David > > > > Thanks again David. > > > > Dino > > --047d7b1117bf7dd4f8050ed86cef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David

Thanks for your comments, I am= parsing them and I=C2=B4ll suggest new text aiming to address them ASAP.

I would also like to better understand [A] before d= oing this.

With LISP an EID-preifx can have an arb= itrary length and can move (i.e., change its RLOC bindings), in the specifi= c case of a VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IP= v6 respectively). What doesn't work is the mobility of a node (assigned= with a /32 or /128) *within* a coarser EID-prefix, in this case you need t= o split the prefix into more specifics and register them independently in t= he Mapping System, effectively creating new EID-prefixes.

Please let me know if this clarifies your comment, in this case I w= ill suggest new text for Section 5.

Albert



On Thu, Feb 12, 2015 at 12:07 AM, Black, David <david.black@e= mc.com> wrote:
Dino - thank= s for the response.

On the major issues, it looks like both [A] and [B] involve only the text in this draft and nothing beyond, which is good news.=C2=A0 I have a simple= text
suggestion for [A], but it looks like [B] is going to require some careful<= br> editing, as one of the primary causes is that the draft is sloppy in using<= br> the same symbol "G" to represent both EID and RLOC multicast grou= ps.

On the minor issues, I have text suggestions for three of the four, and
I'd like to temporarily defer further discussion the IPv6 UDP zero
checksum "tarpit" in favor of resolving everything else first.
On the nits/editorial comments, all the suggestions in your email are fine<= br> with me.=C2=A0 FWIW, I regard that portion of a review as almost entirely subject to the draft authors' discretion (and editorial taste).

> >> [A] EID mobility vs. EID prefixes
>
> ... from the start of the LISP design (circa 2007), an prefix i= s what moves.
> And a specific EID is simply a /32 or /128 prefix. He= re is a practical
> example:

A statement that the mobility use cases need to employ /32 and /128 = prefixes,
and not anything coarser should suffice.=C2=A0 That should be added to Sect= ion 5.

> >> [B] LISP Multicast vs. EID/RLOC separate
> >>
> >> - 6. Multicast
> >>
> >> This is interesting, multicast addresses (G) look like they&#= 39;re an exception
>
> They are really not.

My concern is that as I read the draft, it leaves me with the strong= impression
that the same multicast addresses (G) are being used in both the overlay (as EIDs) and the underlay (as RLOCs).=C2=A0 From your response, I conclude= that this
is not the case (and I have no argument with that).=C2=A0 Rather, Section 6= needs to
bluntly state that multicast addresses are mapped between EID and RLOC spac= e at
both ITRs and ETRs, so that the following inference is obvious from the tex= t
(it's currently not obvious):

> So it makes perfect sense to register multicast addresses to the mappi= ng
> system as EIDs and they can map to RLOCs of sites that have joined the= group.

As part of this, I strongly recommend moving away from use of "= G" to refer to
multicast groups in both the overlay and underlay.=C2=A0 Careful use of G-E= ID
and G-RLOC would significantly improve clarity.

---
If the above are done for [A] and [B] in Sections 5 and 6, then the text fo= r the
use cases in Section 7 should not need further attention.
---

> >> -- Minor Issues --
> >>
> >> There seems to be an implicit assumption that the end host an= d its
> >> ITR (xTR) are in the same domain or Autonomous System.=C2=A0 = For incremental
>
> This is true when you call the domain a "LISP site". But if = the site is
> unchanged and one uses PITRs, maybe even close to the site, like in a = PE
> router, then the PITR is definitely in another AS.

Looking at the text, it seems that "LISP site" and "d= omain" are the same
concept for this draft.=C2=A0 That would be useful to state, IMHO but I'= ;ll leave
the decision on whether to do so to you and the draft authors.

On rereading, my concerns seem to be triggered mostly by this sentence in Section 3.2:

=C2=A0 =C2=A0The edge consists of LISP sites (e.g., an
=C2=A0 =C2=A0Autonomous System) that use EID addresses.

I think a small change to the last sentence in that paragraph would resolve=
my concern without distracting from the narrative:

OLD
=C2=A0 =C2=A0EIDs do not
=C2=A0 =C2=A0contain inter-domain topological information and because of th= is,
=C2=A0 =C2=A0EIDs are usually routable at the edge (within LISP sites) or i= n the
=C2=A0 =C2=A0non-LISP Internet.
NEW
=C2=A0 =C2=A0EIDs do not
=C2=A0 =C2=A0contain inter-domain topological information and because of th= is,
=C2=A0 =C2=A0EIDs are usually routable at the edge (within LISP sites) or i= n the
=C2=A0 =C2=A0non-LISP Internet; see Section 3.5 for discussion of LISP site=
=C2=A0 =C2=A0internetworking with non-LISP sites and domains in the Interne= t.

> >> Despite multiple=C2=A0 mentions of incremental deployment, I = did not
> >> see a discussion of how that might be accomplished.
>
> There are PxTRs and NATs. And references to th= e LISP interworking RFC.

Ok, can we just say so in Section 3.5?=C2=A0 Adding the following se= ntence
to the end of the section would suffice:

=C2=A0 =C2=A0PITRs, PETRs and LISP-NAT support incremental deployment of LI= SP
=C2=A0 =C2=A0by providing significant flexibility in location of the bounda= ries
=C2=A0 =C2=A0between the LISP and non-LISP portions of the network, and mak= ing
=C2=A0 =C2=A0it reasonable to change those boundaries over time.

> >> - 3.3.1.=C2=A0 LISP Encapsulation
> >>
> >>=C2=A0 =C2=A0 the source port is selected by
> >>=C2=A0 =C2=A0 the ITR and ignored on reception.
> >>
> >> Please mention multipathing (e.g., ECMP and LAG) as possible = influences
> >> on how source ports are selected, as this imposes some limits= on what an
> >> ITR can reasonably do.
>
> ECMP/LAG don't influence which source port is selected. It is a 5-= tuple hash
> of the inner header that selects a source port that influences how an = underlay
> router would load-split traffic.

Please state that a 5-tuple hash is used.=C2=A0 ECMP/LAG is among th= e important
reasons why, but that doesn't need to be stated if you prefer not to.= =C2=A0 An
example of something that needs to be excluded is that using a random
number generator to set the source port would be wrong - I could suggest citing draft-ietf-dart-dscp-rtp for related discussion (and lots more
details), but I don't think that's necessary.

-- IPv6 zero UDP checksum

> My head spins every time I hear about this subject. This subject has b= een
> talked about from 100s of people for a decade. We have CRC on links, w= e have
> apps that use TCP and UDP checksums. Nuf said.

Understood - there's more than one set of scars on this one :-(.= =C2=A0 Let's come back
to this topic after we've resolved everything else, and please keep in = mind
that I tagged this as a minor issue, not a major one (e.g., the above chang= es
for [A] and [B] are far more important, IMHO).

Thanks,
--David

> -----Original Message-----
> From: Dino Farinacci [mailto:fa= rinacci@gmail.com]
> Sent: Wednesday, February 11, 2015 2:19 PM
> To: Joel M. Halpern
> Cc: Black, David; Albert Cabellos; Damien Saucez; ops-dir@ietf.org;
> ietf@ietf.org; lisp@ietf.org
> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11<= br> >
> > I will leave most = of these for the authors to comment on.
>
> See my comments inline. Thanks David for your detailed review and comm= entary.
>
> > With regard to your question about incremental deployment, that i= s the
> domain of the LISP Deployment document, and was deliberately only ligh= tly
> covered here.=C2=A0 I am not sure what we can do to address your comme= nt without
> duplicating the entirety of that document.
>
> That is the risk we may have with many of your comments. We have a lot= of
> detail in the already 9 published RFCs=C2=A0 and this document really = is to take
> all that detail and summarize as an easily understandable description = of a
> cohesive design.
>
> > With regard to UDP Zero, this was approved by the IESG and publis= hed as an
> RFC.=C2=A0 It is part of the way the protocol is defined.=C2=A0 If the= re are specific
> changes you would like to see in the explanatory text, I am sure
>
> Definitely agreed. In fact we instigated UDP zero. And I continually t= alk to
> hardware engineers and they all believe we made the right decision. So= hats
> off to the IETF for being practical.
>
> > we could include them.=C2=A0 If you are looking for a change in t= he behavior,
> this document can not make changes to the LISP behavior.
>
> Yes, an important point.
>
> >> I found a couple of major issues that I hope arise from the > >> summarization of LISP in this draft, as opposed to being prob= lems in
> >> the actual LISP protocols.=C2=A0 I also found a few minor iss= ues, the most
> >> important of which is the need for additional security consid= erations
> >> discussion on misdelivery, with particular attention to VPNs.=
>
> Thanks a ton.
>
> >> -- Major issues --
> >>
> >> [A] EID mobility vs. EID prefixes
> >>
> >> - 5. Mobility
> >>
> >> I understand how this works when mapping is per-EID, but how = does this work
> >> when the EID of the system that moves is part of an EID prefi= x, as
> discussed
> >> in Section 3.4.1?=C2=A0 Even if the answer is a long version = of "Don't do that!"
> >> it should be explained.
>
> No, from the start of the LISP design (circa 2007), an prefix is what = moves.
> And a specific EID is simply a /32 or /128 prefix. Here is a practical=
> example:
>
> You have a cluster of servers that communicate together for a particul= ar
> application. They application cluster is running in a set of VMs. Thos= e VMs
> are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are c= urrently
> running in a brick-and-mortar data center. Now there is a desire to mo= ve the
> VM cluster to a cloud provider. What is moved is the EID-prefix of the=
> cluster. The mapping system is told that the EID-prefix is changing it= s RLOC-
> set from the brick-and-mortar xTRs to the cloud providers xTRs.
>
> >>
> >> - 7.4.=C2=A0 LISP for Virtual Machine Mobility in Data Center= s
> >>
> >> I don't understand how this works when EID prefixes are u= sed, as each VM
> >> has its own EID or EIDs, hence the entire prefix range does n= ot move when
> >> the VM moves.
> >>
> >> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in A= ppendix A
> >> of RFC 5706:=C2=A0 Has deployment been discussed? and specifi= cally under:
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Is the proposed specificat= ion deployable?=C2=A0 If not, how could
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it be improved?
> >>
> >> as EID prefixes appear to be undeployable for Mobility and VM= Mobility
> usage.
>
> See above example.
>
> >> [B] LISP Multicast vs. EID/RLOC separate
> >>
> >> - 6. Multicast
> >>
> >> This is interesting, multicast addresses (G) look like they&#= 39;re an exception
>
> They are really not. Since multicast addresses *identify* a group of > receivers, it is very much an EID and aheres to the definition of an E= ID.
> Multicast addresses never had topological signficance but the state > representing a distribution tree does tell you were the members are (b= ut the
> identity of the members are not know in multicast).
>
> So it makes perfect sense to register multicast addresses to the mappi= ng
> system as EIDs and they can map to RLOCs of sites that have joined the= group.
> See draft-farinacci-signal-free-multicast as just one example. RFC6831= and
> draft-farinacci-lisp-mr-signaling are other examples.
>
> >> to the EID/RLOC separation as the same destination IP multica= st address
> >> is used for both purposes.=C2=A0 This could use some more dis= cussion, as it's
> >> unexpected based on the contents of the draft up to this poin= t.
>
> I believe the level of detail we have in the introduction document is = at the
> right level or we'll err on having way too many details crop in. >
> >> - 7.2.=C2=A0 LISP for IPv6 Co-existence
> >>
> >>=C2=A0 =C2=A0 LISP encapsulations allows to transport packets = using EIDs from a
> >>=C2=A0 =C2=A0 given address family (e.g., IPv6) with packets f= rom other address
> >>=C2=A0 =C2=A0 families (e.g., IPv4).
> >>
> >> How does that work for multicast traffic, where the destinati= on address
> >> (G) has to be the same in both the inner and outer headers?= =C2=A0 Are ETRs
> >> and ITRs expected to map IPv6 multicast addresses to IPv4 and= v.v.?
>
> The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RL= OC set
> that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that=
> receives the packet from S-EID-ipv6 would replicate the packet and mul= ticast
> encapsulate to ipv4-multicast and unicast encapsualte to ipv4-unicast.=
>
> >> - 7.3.=C2=A0 LISP for Virtual Private Networks
> >>
> >> This also has multicast problems, as there is only one instan= ce of each
> >> multicast address (G) in the underlay network.=C2=A0 I think = I can figure out
> how
>
> You can map from EID-G to RLOC-G one to one. But we have seen over the= last
> decade in a half that with general multicast deployment that many-to-1= is
> desirable. Hence, now that we have a way to map with a network-based d= atabase,
> we can map multiple EID-Gs to a single (or multiple) RLOC-Gs.
>
> >> to make multicast work for this use case, but it's not im= mediately obvious,
> >> and the result when the same underlay multicast address is us= ed by more
> >> than one VPN could well deliver some traffic to ETRs that hav= e to discard
>
> This is a necessary evil when the underlay is state challenged. But it= is a
> state/bandwidth tradeoff. We have found with MVPN deployment that the = network
> admin configures the underly or simply unicasts.
>
> >> it because the Instance ID is wrong (and that excessive deliv= ery is a
> >> security consideration, see minor issue on Section 8 below).= =C2=A0 I think an
> >> explanation is in order.
>
> There are just too many combinations to make a high-level description = simple
> to understand. The current introduction text does a find job providing=
> references for someone to go off and get the details.
>
> >> -- Minor Issues --
> >>
> >> There seems to be an implicit assumption that the end host an= d its
> >> ITR (xTR) are in the same domain or Autonomous System.=C2=A0 = For incremental
>
> This is true when you call the domain a "LISP site". But if = the site is
> unchanged and one uses PITRs, maybe even close to the site, like in a = PE
> router, then the PITR is definitely in another AS. But note I said PIT= R and
> not ITR. The reason being is because an ITR is configured with databas= e-
> mapping prefixes that is uses to encapsulate packets from such address= es.
> Versus the PITR being an ITR with *no database-mappings* providing a m= uch more
> larger/or more aggregtable service.
>
> >> deployment, I don't think that's always the case, but= I think that only
> >> has editorial impact on this document, as I don't think a= ny of the
> >> fundamental LISP mechanisms are affected.=C2=A0 The authors s= hould look for
> >> use of "domain" and "Autonomous System" a= nd ensure that the text is
> >> generalized to the case where the end host and ITR are more w= idely
> >> separated.
>
> We are overloaded with terms that create topological or organization b= oundary.
> Hence why we created "LISP site" which is also the same as a= "LISP VPN site".
> Where a "LISP site" that has multiple tennants would be mult= iple "LISP VPN
> sites".
>
> >> Despite multiple=C2=A0 mentions of incremental deployment, I = did not
> >> see a discussion of how that might be accomplished.=C2=A0 The= re is some
>
> There are PxTRs and NATs. And references to the LISP interworking RFC.=
>
> >> useful content in Section 3.5, but that's at best an inco= mplete
> >> explanation.=C2=A0 This is an OPS-Dir review concern - it fal= ls under
> >> A.1.3 in Appendix A of RFC 5706: Has the migration path been = discussed?
> >>
> >> - 3.3.1.=C2=A0 LISP Encapsulation
> >>
> >>=C2=A0 =C2=A0 the source port is selected by
> >>=C2=A0 =C2=A0 the ITR and ignored on reception.
> >>
> >> Please mention multipathing (e.g., ECMP and LAG) as possible = influences
> >> on how source ports are selected, as this imposes some limits= on what an
> >> ITR can reasonably do.
>
> ECMP/LAG don't influence which source port is selected. It is a 5-= tuple hash
> of the inner header that selects a source port that influences how an = underlay
> router would load-split traffic.
>
> >> For OPS-Dir, this multipathing concern falls under A.1.4 in A= ppendix A of
> >> RFC 5706: Have the Requirements on other protocols and functi= onal
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 components been discussed?
> >>
> >>=C2=A0 =C2=A0 This decision was made because the
> >>=C2=A0 =C2=A0 typical transport protocols used by the applicat= ions already include
> >>=C2=A0 =C2=A0 a checksum, by neglecting the additional UDP enc= apsulation checksum
> >>=C2=A0 =C2=A0 xTRs can forward packets more efficiently.
> >>
> >> Groan!=C2=A0 I have an exquisite set of scars on UDP zero che= cksums for IPv6
> >> from working on the MPLS in UDP draft, so I may be overly sen= sitive to
> >> this concern.=C2=A0 The downside of this efficiency is that t= here is no
> >> checksum coverage of the IPv6 header when zero UDP checksums = are used.
> >> That should at least be mentioned here, with a summary of why= that's ok
> >> - the detailed justification for why that's ok can be lef= t to other
> >> documents.
>
> My head spins every time I hear about this subject. This subject has b= een
> talked about from 100s of people for a decade. We have CRC on links, w= e have
> apps that use TCP and UDP checksums. Nuf said.
>
> >>
> >> -- Nits/Editorial Comments --
> >>
> >> - Top of p.4:
> >>
> >>=C2=A0 =C2=A0 The initial motivation in the LISP effort is to = be find in the
> >>
> >> "find" -> "found"
> >>
> >> - Section 3.1, first bullet item
>
> We will certainly fixe these. Thanks.
>
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Devices are assigned with relativel= y opaque identity
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0meaningful addresses that are indep= endent of their topological
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0location.
> >>
> >> I don't understand "relatively opaque identity meani= ngful" and
> >> suggest rewriting the sentence.=C2=A0 In particular - opaque = to what?
> >> meaningful to what in what manner?
>
> Well beacuse it is as accurate as it can be. If automobiles are going = to be
> assigned EIDs from a VIN number allocation from a manufacture, the add= ress is
> relatively opaque. If a VM in a data-center is going to be assigned an= EID
> from the set of prefixes already being used and allocated to that data= -center,
> then there is a good chance that address is in a power-of-2 block that= is
> summarizable in the IGP.
>
> >>
> >> - Section 3.2, second paragraph
> >>
> >> Judging from the figure, xTRs are the common case, with singl= e-
> >> function ITRs and ETRs being rare.=C2=A0 It might be good to = say that
> >> and discuss when ITRs and ETRs that are not xTRs are appropri= ate
> >> to use.
>
> When you want egress path selection to happen further out in the toplo= gical
> from the source location, then you put an ITR-only system there. Where= ingress
> to the same source (destination in this direction), the ETR can be clo= ser to
> the destination.
>
> >>
> >> - 3rd paragraph on p.7:
> >>
> >>
> >>=C2=A0 =C2=A0 Finally, the LISP architecture emphasizes a cost= effective
> >>=C2=A0 =C2=A0 incremental deployment.
> >>
> >> I'd delete "cost effective" here and look for o= ther occurrences
> >> of "cost" as candidates for deletion.=C2=A0 This is= supposed to be
> >> a technical document, so discussion of costs is a bit off-tar= get.
>
> Fair enough.
>
> >> - First item after Figure 2:
> >>
> >>=C2=A0 =C2=A0 1.=C2=A0 HostA retrieves the EID_B of HostB, typ= ically querying the DNS
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and obtaining and A or AAAA record= .
> >>
> >> "and A" -> "an A"=C2=A0 (spelling chec= kers don't catch everything).
>
> Already noted and will be fixed.
>
> >>
> >> - 3.3.1.=C2=A0 LISP Encapsulation
> >>
> >>=C2=A0 =C2=A0 On the other hand, Recursive
> >>=C2=A0 =C2=A0 tunnels are nested tunnels and are implemented b= y using multiple LISP
> >>=C2=A0 =C2=A0 encapsulations on a packet.
> >>
> >> The above sentence seems out of place in the middle of a para= graph about
> >> Re-encapsulating tunnels and routers - I suggest moving it do= wn into its
> >> own paragraph and perhaps adding a sentence about where/how R= ecursive
> >> tunnels may be useful.
>
> Good suggestion and makes sense.
>
> >> - 3.3.2.=C2=A0 LISP Forwarding State
> >>
> >>=C2=A0 =C2=A0 In the LISP architecture, ITRs keep just enough = information to route
> >>=C2=A0 =C2=A0 traffic flowing through it.
> >>
> >> "it." -> "them."
> >>
> >>=C2=A0 =C2=A0 Meaning that, ITRs retrieve from the
> >>=C2=A0 =C2=A0 LISP Mapping System mappings between EID prefixe= s and RLOCs that are
> >>=C2=A0 =C2=A0 used to encapsulate packets.
> >>
> >> This is the first use of the notion of EID prefixes.=C2=A0 Th= at concept should
> >> be explained before it is used, although a forward reference = to section
> >> 3.4.1 may suffice.=C2=A0 It might be better to rewrite this p= aragraph in terms
> >> of EIDs and leave the notion of EID prefixes to section 3.4.1= .
>
> Hmm, I'll let Albert and Damien decide if we should state "EI= D-prefixes"
> everywhere instead of just "EID".
>
> >>
> >> - 4.4.=C2=A0 MTU Handling
> >>
> >>=C2=A0 =C2=A0 Additionally, LISP also recommends inferring rea= chability of locators
> >>=C2=A0 =C2=A0 by using information provided by the underlay, i= n particular:
> >>
> >> It'd be useful to add a sentence or two about how LISP an= d the techniques
> >> in this section interact with host use of PMTUD and PLPMTUD.<= br> >
> This is a lot of detail because in RFC6830 we have 3 positions or opti= ons on
> the subject. And we did provide a reference to RFC6830 for this topic.=
>
> >> - Next to last paragraph on p.17:
> >>
> >>=C2=A0 =C2=A0 Additionally, LISP also recommends inferring rea= chability of locators
> >>=C2=A0 =C2=A0 by using information provided by the underlay, i= n particular:
> >>
> >> This looks like it's a paragraph early and needs to be mo= ved down to
> >> after the paragraph that follows it.
>
> Agree.
>
> >> idnits 2.13.01 didn't find any nits.
> >>
> >> Thanks,
> >> --David
>
> Thanks again David.
>
> Dino


--047d7b1117bf7dd4f8050ed86cef-- From nobody Wed Feb 11 15:40:51 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDF91A1A80; Wed, 11 Feb 2015 15:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_gp23JoIKev; Wed, 11 Feb 2015 15:40:34 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087771A1A7B; Wed, 11 Feb 2015 15:40:32 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1BNeR6Z025789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 18:40:28 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t1BNeR6Z025789 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423698029; bh=HofYwgpgAHWmOsyr5hn/1v8HUnc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ENOhRA7583sz2AUlpeNvoayMghupkmHhHW//37rRU5aqM3cYtJT0EDTx/Wc2XH/yM n7k38nhS2YJHhVCwl9DeKoj0Qq7OYYiHw79VPzoymhMj7/ge+jh6/uSQ+4A7bJPfmu sH5Bm03YGhEEJ/RmncPqIR/dJB60bo6U/j3Rl11I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t1BNeR6Z025789 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 11 Feb 2015 18:40:21 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1BNeIq0026280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 18:40:18 -0500 Received: from MXHUB201.corp.emc.com (10.253.68.27) by mxhub04.corp.emc.com (10.254.141.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 11 Feb 2015 18:40:17 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB201.corp.emc.com ([10.253.68.27]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 18:40:17 -0500 From: "Black, David" To: "acabello@ac.upc.edu" Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 Thread-Index: AdBFiMToswN7n7S2Sw+GOUWYxLLMygALNZaAACj504AABFG2sAAEjFWAAApdi3A= Date: Wed, 11 Feb 2015 23:40:17 +0000 Message-ID: References: <54DA982D.60200@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363640C1MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 23:40:48 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363640C1MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxiZXJ0LA0KDQpBcyBub3RlZCBiZWxvdywgb24gdGhlIEVJRCBwcmVmaXggZm9yIG1vYmls aXR5IGlzc3VlLCBhIHNpbXBsZSBzdGF0ZW1lbnQgaW4gU2VjdGlvbiA1IHRvIHRoZSBlZmZlY3Qg dGhhdCDigJxpbiB0aGUgc3BlY2lmaWMgY2FzZSBvZiBhIFZNL21vYmlsZSBub2RlIHRoZSBFSUQt cHJlZml4IHNob3VsZCBiZSAvMzIgb3IgLzEyOCAoSVB2NCBvciBJUHY2IHJlc3BlY3RpdmVseSni gJ0gd2lsbCBzdWZmaWNlLiAgRGV0YWlscyBvbiB3aGF0IHRvIGRvIHdoZW4gdGhhdCBhZHZpY2Ug aXMgaWdub3JlZCBjYW4gYmUgbGVmdCB0byBvdGhlciBkb2N1bWVudHMuDQoNClRoYW5rcywNCi0t RGF2aWQNCg0KRnJvbTogQWxiZXJ0IENhYmVsbG9zIFttYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdt YWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMTUgNjozMyBQTQ0KVG86 IEJsYWNrLCBEYXZpZA0KQ2M6IERpbm8gRmFyaW5hY2NpOyBKb2VsIE0uIEhhbHBlcm47IERhbWll biBTYXVjZXo7IG9wcy1kaXJAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWlu dHJvZHVjdGlvbi0xMQ0KDQpIaSBEYXZpZA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIEkg YW0gcGFyc2luZyB0aGVtIGFuZCBJwrRsbCBzdWdnZXN0IG5ldyB0ZXh0IGFpbWluZyB0byBhZGRy ZXNzIHRoZW0gQVNBUC4NCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3RhbmQg W0FdIGJlZm9yZSBkb2luZyB0aGlzLg0KDQpXaXRoIExJU1AgYW4gRUlELXByZWlmeCBjYW4gaGF2 ZSBhbiBhcmJpdHJhcnkgbGVuZ3RoIGFuZCBjYW4gbW92ZSAoaS5lLiwgY2hhbmdlIGl0cyBSTE9D IGJpbmRpbmdzKSwgaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgYSBWTS9tb2JpbGUgbm9kZSB0aGUg RUlELXByZWZpeCBzaG91bGQgYmUgLzMyIG9yIC8xMjggKElQdjQgb3IgSVB2NiByZXNwZWN0aXZl bHkpLiBXaGF0IGRvZXNuJ3Qgd29yayBpcyB0aGUgbW9iaWxpdHkgb2YgYSBub2RlIChhc3NpZ25l ZCB3aXRoIGEgLzMyIG9yIC8xMjgpICp3aXRoaW4qIGEgY29hcnNlciBFSUQtcHJlZml4LCBpbiB0 aGlzIGNhc2UgeW91IG5lZWQgdG8gc3BsaXQgdGhlIHByZWZpeCBpbnRvIG1vcmUgc3BlY2lmaWNz IGFuZCByZWdpc3RlciB0aGVtIGluZGVwZW5kZW50bHkgaW4gdGhlIE1hcHBpbmcgU3lzdGVtLCBl ZmZlY3RpdmVseSBjcmVhdGluZyBuZXcgRUlELXByZWZpeGVzLg0KDQpQbGVhc2UgbGV0IG1lIGtu b3cgaWYgdGhpcyBjbGFyaWZpZXMgeW91ciBjb21tZW50LCBpbiB0aGlzIGNhc2UgSSB3aWxsIHN1 Z2dlc3QgbmV3IHRleHQgZm9yIFNlY3Rpb24gNS4NCg0KQWxiZXJ0DQoNCg0KDQpPbiBUaHUsIEZl YiAxMiwgMjAxNSBhdCAxMjowNyBBTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29t PG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4gd3JvdGU6DQpEaW5vIC0gdGhhbmtzIGZvciB0 aGUgcmVzcG9uc2UuDQoNCk9uIHRoZSBtYWpvciBpc3N1ZXMsIGl0IGxvb2tzIGxpa2UgYm90aCBb QV0gYW5kIFtCXSBpbnZvbHZlIG9ubHkgdGhlIHRleHQNCmluIHRoaXMgZHJhZnQgYW5kIG5vdGhp bmcgYmV5b25kLCB3aGljaCBpcyBnb29kIG5ld3MuICBJIGhhdmUgYSBzaW1wbGUgdGV4dA0Kc3Vn Z2VzdGlvbiBmb3IgW0FdLCBidXQgaXQgbG9va3MgbGlrZSBbQl0gaXMgZ29pbmcgdG8gcmVxdWly ZSBzb21lIGNhcmVmdWwNCmVkaXRpbmcsIGFzIG9uZSBvZiB0aGUgcHJpbWFyeSBjYXVzZXMgaXMg dGhhdCB0aGUgZHJhZnQgaXMgc2xvcHB5IGluIHVzaW5nDQp0aGUgc2FtZSBzeW1ib2wgIkciIHRv IHJlcHJlc2VudCBib3RoIEVJRCBhbmQgUkxPQyBtdWx0aWNhc3QgZ3JvdXBzLg0KDQpPbiB0aGUg bWlub3IgaXNzdWVzLCBJIGhhdmUgdGV4dCBzdWdnZXN0aW9ucyBmb3IgdGhyZWUgb2YgdGhlIGZv dXIsIGFuZA0KSSdkIGxpa2UgdG8gdGVtcG9yYXJpbHkgZGVmZXIgZnVydGhlciBkaXNjdXNzaW9u IHRoZSBJUHY2IFVEUCB6ZXJvDQpjaGVja3N1bSAidGFycGl0IiBpbiBmYXZvciBvZiByZXNvbHZp bmcgZXZlcnl0aGluZyBlbHNlIGZpcnN0Lg0KDQpPbiB0aGUgbml0cy9lZGl0b3JpYWwgY29tbWVu dHMsIGFsbCB0aGUgc3VnZ2VzdGlvbnMgaW4geW91ciBlbWFpbCBhcmUgZmluZQ0Kd2l0aCBtZS4g IEZXSVcsIEkgcmVnYXJkIHRoYXQgcG9ydGlvbiBvZiBhIHJldmlldyBhcyBhbG1vc3QgZW50aXJl bHkNCnN1YmplY3QgdG8gdGhlIGRyYWZ0IGF1dGhvcnMnIGRpc2NyZXRpb24gKGFuZCBlZGl0b3Jp YWwgdGFzdGUpLg0KDQo+ID4+IFtBXSBFSUQgbW9iaWxpdHkgdnMuIEVJRCBwcmVmaXhlcw0KPg0K PiAuLi4gZnJvbSB0aGUgc3RhcnQgb2YgdGhlIExJU1AgZGVzaWduIChjaXJjYSAyMDA3KSwgYW4g cHJlZml4IGlzIHdoYXQgbW92ZXMuDQo+IEFuZCBhIHNwZWNpZmljIEVJRCBpcyBzaW1wbHkgYSAv MzIgb3IgLzEyOCBwcmVmaXguIEhlcmUgaXMgYSBwcmFjdGljYWwNCj4gZXhhbXBsZToNCg0KQSBz dGF0ZW1lbnQgdGhhdCB0aGUgbW9iaWxpdHkgdXNlIGNhc2VzIG5lZWQgdG8gZW1wbG95IC8zMiBh bmQgLzEyOCBwcmVmaXhlcywNCmFuZCBub3QgYW55dGhpbmcgY29hcnNlciBzaG91bGQgc3VmZmlj ZS4gIFRoYXQgc2hvdWxkIGJlIGFkZGVkIHRvIFNlY3Rpb24gNS4NCg0KPiA+PiBbQl0gTElTUCBN dWx0aWNhc3QgdnMuIEVJRC9STE9DIHNlcGFyYXRlDQo+ID4+DQo+ID4+IC0gNi4gTXVsdGljYXN0 DQo+ID4+DQo+ID4+IFRoaXMgaXMgaW50ZXJlc3RpbmcsIG11bHRpY2FzdCBhZGRyZXNzZXMgKEcp IGxvb2sgbGlrZSB0aGV5J3JlIGFuIGV4Y2VwdGlvbg0KPg0KPiBUaGV5IGFyZSByZWFsbHkgbm90 Lg0KDQpNeSBjb25jZXJuIGlzIHRoYXQgYXMgSSByZWFkIHRoZSBkcmFmdCwgaXQgbGVhdmVzIG1l IHdpdGggdGhlIHN0cm9uZyBpbXByZXNzaW9uDQp0aGF0IHRoZSBzYW1lIG11bHRpY2FzdCBhZGRy ZXNzZXMgKEcpIGFyZSBiZWluZyB1c2VkIGluIGJvdGggdGhlIG92ZXJsYXkNCihhcyBFSURzKSBh bmQgdGhlIHVuZGVybGF5IChhcyBSTE9DcykuICBGcm9tIHlvdXIgcmVzcG9uc2UsIEkgY29uY2x1 ZGUgdGhhdCB0aGlzDQppcyBub3QgdGhlIGNhc2UgKGFuZCBJIGhhdmUgbm8gYXJndW1lbnQgd2l0 aCB0aGF0KS4gIFJhdGhlciwgU2VjdGlvbiA2IG5lZWRzIHRvDQpibHVudGx5IHN0YXRlIHRoYXQg bXVsdGljYXN0IGFkZHJlc3NlcyBhcmUgbWFwcGVkIGJldHdlZW4gRUlEIGFuZCBSTE9DIHNwYWNl IGF0DQpib3RoIElUUnMgYW5kIEVUUnMsIHNvIHRoYXQgdGhlIGZvbGxvd2luZyBpbmZlcmVuY2Ug aXMgb2J2aW91cyBmcm9tIHRoZSB0ZXh0DQooaXQncyBjdXJyZW50bHkgbm90IG9idmlvdXMpOg0K DQo+IFNvIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gcmVnaXN0ZXIgbXVsdGljYXN0IGFkZHJl c3NlcyB0byB0aGUgbWFwcGluZw0KPiBzeXN0ZW0gYXMgRUlEcyBhbmQgdGhleSBjYW4gbWFwIHRv IFJMT0NzIG9mIHNpdGVzIHRoYXQgaGF2ZSBqb2luZWQgdGhlIGdyb3VwLg0KDQpBcyBwYXJ0IG9m IHRoaXMsIEkgc3Ryb25nbHkgcmVjb21tZW5kIG1vdmluZyBhd2F5IGZyb20gdXNlIG9mICJHIiB0 byByZWZlciB0bw0KbXVsdGljYXN0IGdyb3VwcyBpbiBib3RoIHRoZSBvdmVybGF5IGFuZCB1bmRl cmxheS4gIENhcmVmdWwgdXNlIG9mIEctRUlEDQphbmQgRy1STE9DIHdvdWxkIHNpZ25pZmljYW50 bHkgaW1wcm92ZSBjbGFyaXR5Lg0KDQotLS0NCklmIHRoZSBhYm92ZSBhcmUgZG9uZSBmb3IgW0Fd IGFuZCBbQl0gaW4gU2VjdGlvbnMgNSBhbmQgNiwgdGhlbiB0aGUgdGV4dCBmb3IgdGhlDQp1c2Ug Y2FzZXMgaW4gU2VjdGlvbiA3IHNob3VsZCBub3QgbmVlZCBmdXJ0aGVyIGF0dGVudGlvbi4NCi0t LQ0KDQo+ID4+IC0tIE1pbm9yIElzc3VlcyAtLQ0KPiA+Pg0KPiA+PiBUaGVyZSBzZWVtcyB0byBi ZSBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIHRoYXQgdGhlIGVuZCBob3N0IGFuZCBpdHMNCj4gPj4g SVRSICh4VFIpIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3IgQXV0b25vbW91cyBTeXN0ZW0uICBG b3IgaW5jcmVtZW50YWwNCj4NCj4gVGhpcyBpcyB0cnVlIHdoZW4geW91IGNhbGwgdGhlIGRvbWFp biBhICJMSVNQIHNpdGUiLiBCdXQgaWYgdGhlIHNpdGUgaXMNCj4gdW5jaGFuZ2VkIGFuZCBvbmUg dXNlcyBQSVRScywgbWF5YmUgZXZlbiBjbG9zZSB0byB0aGUgc2l0ZSwgbGlrZSBpbiBhIFBFDQo+ IHJvdXRlciwgdGhlbiB0aGUgUElUUiBpcyBkZWZpbml0ZWx5IGluIGFub3RoZXIgQVMuDQoNCkxv b2tpbmcgYXQgdGhlIHRleHQsIGl0IHNlZW1zIHRoYXQgIkxJU1Agc2l0ZSIgYW5kICJkb21haW4i IGFyZSB0aGUgc2FtZQ0KY29uY2VwdCBmb3IgdGhpcyBkcmFmdC4gIFRoYXQgd291bGQgYmUgdXNl ZnVsIHRvIHN0YXRlLCBJTUhPIGJ1dCBJJ2xsIGxlYXZlDQp0aGUgZGVjaXNpb24gb24gd2hldGhl ciB0byBkbyBzbyB0byB5b3UgYW5kIHRoZSBkcmFmdCBhdXRob3JzLg0KDQpPbiByZXJlYWRpbmcs IG15IGNvbmNlcm5zIHNlZW0gdG8gYmUgdHJpZ2dlcmVkIG1vc3RseSBieSB0aGlzIHNlbnRlbmNl IGluDQpTZWN0aW9uIDMuMjoNCg0KICAgVGhlIGVkZ2UgY29uc2lzdHMgb2YgTElTUCBzaXRlcyAo ZS5nLiwgYW4NCiAgIEF1dG9ub21vdXMgU3lzdGVtKSB0aGF0IHVzZSBFSUQgYWRkcmVzc2VzLg0K DQpJIHRoaW5rIGEgc21hbGwgY2hhbmdlIHRvIHRoZSBsYXN0IHNlbnRlbmNlIGluIHRoYXQgcGFy YWdyYXBoIHdvdWxkIHJlc29sdmUNCm15IGNvbmNlcm4gd2l0aG91dCBkaXN0cmFjdGluZyBmcm9t IHRoZSBuYXJyYXRpdmU6DQoNCk9MRA0KICAgRUlEcyBkbyBub3QNCiAgIGNvbnRhaW4gaW50ZXIt ZG9tYWluIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNlIG9mIHRoaXMsDQogICBF SURzIGFyZSB1c3VhbGx5IHJvdXRhYmxlIGF0IHRoZSBlZGdlICh3aXRoaW4gTElTUCBzaXRlcykg b3IgaW4gdGhlDQogICBub24tTElTUCBJbnRlcm5ldC4NCk5FVw0KICAgRUlEcyBkbyBub3QNCiAg IGNvbnRhaW4gaW50ZXItZG9tYWluIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNl IG9mIHRoaXMsDQogICBFSURzIGFyZSB1c3VhbGx5IHJvdXRhYmxlIGF0IHRoZSBlZGdlICh3aXRo aW4gTElTUCBzaXRlcykgb3IgaW4gdGhlDQogICBub24tTElTUCBJbnRlcm5ldDsgc2VlIFNlY3Rp b24gMy41IGZvciBkaXNjdXNzaW9uIG9mIExJU1Agc2l0ZQ0KICAgaW50ZXJuZXR3b3JraW5nIHdp dGggbm9uLUxJU1Agc2l0ZXMgYW5kIGRvbWFpbnMgaW4gdGhlIEludGVybmV0Lg0KDQo+ID4+IERl c3BpdGUgbXVsdGlwbGUgIG1lbnRpb25zIG9mIGluY3JlbWVudGFsIGRlcGxveW1lbnQsIEkgZGlk IG5vdA0KPiA+PiBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGF0IG1pZ2h0IGJlIGFjY29tcGxp c2hlZC4NCj4NCj4gVGhlcmUgYXJlIFB4VFJzIGFuZCBOQVRzLiBBbmQgcmVmZXJlbmNlcyB0byB0 aGUgTElTUCBpbnRlcndvcmtpbmcgUkZDLg0KDQpPaywgY2FuIHdlIGp1c3Qgc2F5IHNvIGluIFNl Y3Rpb24gMy41PyAgQWRkaW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UNCnRvIHRoZSBlbmQgb2Yg dGhlIHNlY3Rpb24gd291bGQgc3VmZmljZToNCg0KICAgUElUUnMsIFBFVFJzIGFuZCBMSVNQLU5B VCBzdXBwb3J0IGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgTElTUA0KICAgYnkgcHJvdmlkaW5n IHNpZ25pZmljYW50IGZsZXhpYmlsaXR5IGluIGxvY2F0aW9uIG9mIHRoZSBib3VuZGFyaWVzDQog ICBiZXR3ZWVuIHRoZSBMSVNQIGFuZCBub24tTElTUCBwb3J0aW9ucyBvZiB0aGUgbmV0d29yaywg YW5kIG1ha2luZw0KICAgaXQgcmVhc29uYWJsZSB0byBjaGFuZ2UgdGhvc2UgYm91bmRhcmllcyBv dmVyIHRpbWUuDQoNCj4gPj4gLSAzLjMuMS4gIExJU1AgRW5jYXBzdWxhdGlvbg0KPiA+Pg0KPiA+ PiAgICB0aGUgc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQgYnkNCj4gPj4gICAgdGhlIElUUiBhbmQg aWdub3JlZCBvbiByZWNlcHRpb24uDQo+ID4+DQo+ID4+IFBsZWFzZSBtZW50aW9uIG11bHRpcGF0 aGluZyAoZS5nLiwgRUNNUCBhbmQgTEFHKSBhcyBwb3NzaWJsZSBpbmZsdWVuY2VzDQo+ID4+IG9u IGhvdyBzb3VyY2UgcG9ydHMgYXJlIHNlbGVjdGVkLCBhcyB0aGlzIGltcG9zZXMgc29tZSBsaW1p dHMgb24gd2hhdCBhbg0KPiA+PiBJVFIgY2FuIHJlYXNvbmFibHkgZG8uDQo+DQo+IEVDTVAvTEFH IGRvbid0IGluZmx1ZW5jZSB3aGljaCBzb3VyY2UgcG9ydCBpcyBzZWxlY3RlZC4gSXQgaXMgYSA1 LXR1cGxlIGhhc2gNCj4gb2YgdGhlIGlubmVyIGhlYWRlciB0aGF0IHNlbGVjdHMgYSBzb3VyY2Ug cG9ydCB0aGF0IGluZmx1ZW5jZXMgaG93IGFuIHVuZGVybGF5DQo+IHJvdXRlciB3b3VsZCBsb2Fk LXNwbGl0IHRyYWZmaWMuDQoNClBsZWFzZSBzdGF0ZSB0aGF0IGEgNS10dXBsZSBoYXNoIGlzIHVz ZWQuICBFQ01QL0xBRyBpcyBhbW9uZyB0aGUgaW1wb3J0YW50DQpyZWFzb25zIHdoeSwgYnV0IHRo YXQgZG9lc24ndCBuZWVkIHRvIGJlIHN0YXRlZCBpZiB5b3UgcHJlZmVyIG5vdCB0by4gIEFuDQpl eGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGV4Y2x1ZGVkIGlzIHRoYXQgdXNp bmcgYSByYW5kb20NCm51bWJlciBnZW5lcmF0b3IgdG8gc2V0IHRoZSBzb3VyY2UgcG9ydCB3b3Vs ZCBiZSB3cm9uZyAtIEkgY291bGQgc3VnZ2VzdA0KY2l0aW5nIGRyYWZ0LWlldGYtZGFydC1kc2Nw LXJ0cCBmb3IgcmVsYXRlZCBkaXNjdXNzaW9uIChhbmQgbG90cyBtb3JlDQpkZXRhaWxzKSwgYnV0 IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIG5lY2Vzc2FyeS4NCg0KLS0gSVB2NiB6ZXJvIFVEUCBjaGVj a3N1bQ0KDQo+IE15IGhlYWQgc3BpbnMgZXZlcnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBzdWJq ZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW4NCj4gdGFsa2VkIGFib3V0IGZyb20gMTAwcyBvZiBw ZW9wbGUgZm9yIGEgZGVjYWRlLiBXZSBoYXZlIENSQyBvbiBsaW5rcywgd2UgaGF2ZQ0KPiBhcHBz IHRoYXQgdXNlIFRDUCBhbmQgVURQIGNoZWNrc3Vtcy4gTnVmIHNhaWQuDQoNClVuZGVyc3Rvb2Qg LSB0aGVyZSdzIG1vcmUgdGhhbiBvbmUgc2V0IG9mIHNjYXJzIG9uIHRoaXMgb25lIDotKC4gIExl dCdzIGNvbWUgYmFjaw0KdG8gdGhpcyB0b3BpYyBhZnRlciB3ZSd2ZSByZXNvbHZlZCBldmVyeXRo aW5nIGVsc2UsIGFuZCBwbGVhc2Uga2VlcCBpbiBtaW5kDQp0aGF0IEkgdGFnZ2VkIHRoaXMgYXMg YSBtaW5vciBpc3N1ZSwgbm90IGEgbWFqb3Igb25lIChlLmcuLCB0aGUgYWJvdmUgY2hhbmdlcw0K Zm9yIFtBXSBhbmQgW0JdIGFyZSBmYXIgbW9yZSBpbXBvcnRhbnQsIElNSE8pLg0KDQpUaGFua3Ms DQotLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGlubyBG YXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tPG1haWx0bzpmYXJpbmFjY2lAZ21h aWwuY29tPl0NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSAyOjE5IFBNDQo+ IFRvOiBKb2VsIE0uIEhhbHBlcm4NCj4gQ2M6IEJsYWNrLCBEYXZpZDsgQWxiZXJ0IENhYmVsbG9z OyBEYW1pZW4gU2F1Y2V6OyBvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3Jn PjsNCj4gaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IGxpc3BAaWV0Zi5vcmc8 bWFpbHRvOmxpc3BAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbbGlzcF0gT1BTLURpciByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMQ0KPg0KPiA+IEkgd2lsbCBsZWF2 ZSBtb3N0IG9mIHRoZXNlIGZvciB0aGUgYXV0aG9ycyB0byBjb21tZW50IG9uLg0KPg0KPiBTZWUg bXkgY29tbWVudHMgaW5saW5lLiBUaGFua3MgRGF2aWQgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3 IGFuZCBjb21tZW50YXJ5Lg0KPg0KPiA+IFdpdGggcmVnYXJkIHRvIHlvdXIgcXVlc3Rpb24gYWJv dXQgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgdGhhdCBpcyB0aGUNCj4gZG9tYWluIG9mIHRoZSBM SVNQIERlcGxveW1lbnQgZG9jdW1lbnQsIGFuZCB3YXMgZGVsaWJlcmF0ZWx5IG9ubHkgbGlnaHRs eQ0KPiBjb3ZlcmVkIGhlcmUuICBJIGFtIG5vdCBzdXJlIHdoYXQgd2UgY2FuIGRvIHRvIGFkZHJl c3MgeW91ciBjb21tZW50IHdpdGhvdXQNCj4gZHVwbGljYXRpbmcgdGhlIGVudGlyZXR5IG9mIHRo YXQgZG9jdW1lbnQuDQo+DQo+IFRoYXQgaXMgdGhlIHJpc2sgd2UgbWF5IGhhdmUgd2l0aCBtYW55 IG9mIHlvdXIgY29tbWVudHMuIFdlIGhhdmUgYSBsb3Qgb2YNCj4gZGV0YWlsIGluIHRoZSBhbHJl YWR5IDkgcHVibGlzaGVkIFJGQ3MgIGFuZCB0aGlzIGRvY3VtZW50IHJlYWxseSBpcyB0byB0YWtl DQo+IGFsbCB0aGF0IGRldGFpbCBhbmQgc3VtbWFyaXplIGFzIGFuIGVhc2lseSB1bmRlcnN0YW5k YWJsZSBkZXNjcmlwdGlvbiBvZiBhDQo+IGNvaGVzaXZlIGRlc2lnbi4NCj4NCj4gPiBXaXRoIHJl Z2FyZCB0byBVRFAgWmVybywgdGhpcyB3YXMgYXBwcm92ZWQgYnkgdGhlIElFU0cgYW5kIHB1Ymxp c2hlZCBhcyBhbg0KPiBSRkMuICBJdCBpcyBwYXJ0IG9mIHRoZSB3YXkgdGhlIHByb3RvY29sIGlz IGRlZmluZWQuICBJZiB0aGVyZSBhcmUgc3BlY2lmaWMNCj4gY2hhbmdlcyB5b3Ugd291bGQgbGlr ZSB0byBzZWUgaW4gdGhlIGV4cGxhbmF0b3J5IHRleHQsIEkgYW0gc3VyZQ0KPg0KPiBEZWZpbml0 ZWx5IGFncmVlZC4gSW4gZmFjdCB3ZSBpbnN0aWdhdGVkIFVEUCB6ZXJvLiBBbmQgSSBjb250aW51 YWxseSB0YWxrIHRvDQo+IGhhcmR3YXJlIGVuZ2luZWVycyBhbmQgdGhleSBhbGwgYmVsaWV2ZSB3 ZSBtYWRlIHRoZSByaWdodCBkZWNpc2lvbi4gU28gaGF0cw0KPiBvZmYgdG8gdGhlIElFVEYgZm9y IGJlaW5nIHByYWN0aWNhbC4NCj4NCj4gPiB3ZSBjb3VsZCBpbmNsdWRlIHRoZW0uICBJZiB5b3Ug YXJlIGxvb2tpbmcgZm9yIGEgY2hhbmdlIGluIHRoZSBiZWhhdmlvciwNCj4gdGhpcyBkb2N1bWVu dCBjYW4gbm90IG1ha2UgY2hhbmdlcyB0byB0aGUgTElTUCBiZWhhdmlvci4NCj4NCj4gWWVzLCBh biBpbXBvcnRhbnQgcG9pbnQuDQo+DQo+ID4+IEkgZm91bmQgYSBjb3VwbGUgb2YgbWFqb3IgaXNz dWVzIHRoYXQgSSBob3BlIGFyaXNlIGZyb20gdGhlDQo+ID4+IHN1bW1hcml6YXRpb24gb2YgTElT UCBpbiB0aGlzIGRyYWZ0LCBhcyBvcHBvc2VkIHRvIGJlaW5nIHByb2JsZW1zIGluDQo+ID4+IHRo ZSBhY3R1YWwgTElTUCBwcm90b2NvbHMuICBJIGFsc28gZm91bmQgYSBmZXcgbWlub3IgaXNzdWVz LCB0aGUgbW9zdA0KPiA+PiBpbXBvcnRhbnQgb2Ygd2hpY2ggaXMgdGhlIG5lZWQgZm9yIGFkZGl0 aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gPj4gZGlzY3Vzc2lvbiBvbiBtaXNkZWxp dmVyeSwgd2l0aCBwYXJ0aWN1bGFyIGF0dGVudGlvbiB0byBWUE5zLg0KPg0KPiBUaGFua3MgYSB0 b24uDQo+DQo+ID4+IC0tIE1ham9yIGlzc3VlcyAtLQ0KPiA+Pg0KPiA+PiBbQV0gRUlEIG1vYmls aXR5IHZzLiBFSUQgcHJlZml4ZXMNCj4gPj4NCj4gPj4gLSA1LiBNb2JpbGl0eQ0KPiA+Pg0KPiA+ PiBJIHVuZGVyc3RhbmQgaG93IHRoaXMgd29ya3Mgd2hlbiBtYXBwaW5nIGlzIHBlci1FSUQsIGJ1 dCBob3cgZG9lcyB0aGlzIHdvcmsNCj4gPj4gd2hlbiB0aGUgRUlEIG9mIHRoZSBzeXN0ZW0gdGhh dCBtb3ZlcyBpcyBwYXJ0IG9mIGFuIEVJRCBwcmVmaXgsIGFzDQo+IGRpc2N1c3NlZA0KPiA+PiBp biBTZWN0aW9uIDMuNC4xPyAgRXZlbiBpZiB0aGUgYW5zd2VyIGlzIGEgbG9uZyB2ZXJzaW9uIG9m ICJEb24ndCBkbyB0aGF0ISINCj4gPj4gaXQgc2hvdWxkIGJlIGV4cGxhaW5lZC4NCj4NCj4gTm8s IGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBMSVNQIGRlc2lnbiAoY2lyY2EgMjAwNyksIGFuIHByZWZp eCBpcyB3aGF0IG1vdmVzLg0KPiBBbmQgYSBzcGVjaWZpYyBFSUQgaXMgc2ltcGx5IGEgLzMyIG9y IC8xMjggcHJlZml4LiBIZXJlIGlzIGEgcHJhY3RpY2FsDQo+IGV4YW1wbGU6DQo+DQo+IFlvdSBo YXZlIGEgY2x1c3RlciBvZiBzZXJ2ZXJzIHRoYXQgY29tbXVuaWNhdGUgdG9nZXRoZXIgZm9yIGEg cGFydGljdWxhcg0KPiBhcHBsaWNhdGlvbi4gVGhleSBhcHBsaWNhdGlvbiBjbHVzdGVyIGlzIHJ1 bm5pbmcgaW4gYSBzZXQgb2YgVk1zLiBUaG9zZSBWTXMNCj4gYXJlIGFzc2lnbmVkIEVJRHMgZnJv bSBhIGNvbW1vbiBwb3dlci1vZi0yIEVJRC1wcmVmaXguIFRob3NlIFZNcyBhcmUgY3VycmVudGx5 DQo+IHJ1bm5pbmcgaW4gYSBicmljay1hbmQtbW9ydGFyIGRhdGEgY2VudGVyLiBOb3cgdGhlcmUg aXMgYSBkZXNpcmUgdG8gbW92ZSB0aGUNCj4gVk0gY2x1c3RlciB0byBhIGNsb3VkIHByb3ZpZGVy LiBXaGF0IGlzIG1vdmVkIGlzIHRoZSBFSUQtcHJlZml4IG9mIHRoZQ0KPiBjbHVzdGVyLiBUaGUg bWFwcGluZyBzeXN0ZW0gaXMgdG9sZCB0aGF0IHRoZSBFSUQtcHJlZml4IGlzIGNoYW5naW5nIGl0 cyBSTE9DLQ0KPiBzZXQgZnJvbSB0aGUgYnJpY2stYW5kLW1vcnRhciB4VFJzIHRvIHRoZSBjbG91 ZCBwcm92aWRlcnMgeFRScy4NCj4NCj4gPj4NCj4gPj4gLSA3LjQuICBMSVNQIGZvciBWaXJ0dWFs IE1hY2hpbmUgTW9iaWxpdHkgaW4gRGF0YSBDZW50ZXJzDQo+ID4+DQo+ID4+IEkgZG9uJ3QgdW5k ZXJzdGFuZCBob3cgdGhpcyB3b3JrcyB3aGVuIEVJRCBwcmVmaXhlcyBhcmUgdXNlZCwgYXMgZWFj aCBWTQ0KPiA+PiBoYXMgaXRzIG93biBFSUQgb3IgRUlEcywgaGVuY2UgdGhlIGVudGlyZSBwcmVm aXggcmFuZ2UgZG9lcyBub3QgbW92ZSB3aGVuDQo+ID4+IHRoZSBWTSBtb3Zlcy4NCj4gPj4NCj4g Pj4gRm9yIE9QUy1EaXIsIHRoaXMgRUlEIHByZWZpeCBpc3N1ZSBbQV0gZmFsbHMgdW5kZXIgQS4x LjEgaW4gQXBwZW5kaXggQQ0KPiA+PiBvZiBSRkMgNTcwNjogIEhhcyBkZXBsb3ltZW50IGJlZW4g ZGlzY3Vzc2VkPyBhbmQgc3BlY2lmaWNhbGx5IHVuZGVyOg0KPiA+Pg0KPiA+PiAgICAgICAgKiAg SXMgdGhlIHByb3Bvc2VkIHNwZWNpZmljYXRpb24gZGVwbG95YWJsZT8gIElmIG5vdCwgaG93IGNv dWxkDQo+ID4+ICAgICAgICAgICBpdCBiZSBpbXByb3ZlZD8NCj4gPj4NCj4gPj4gYXMgRUlEIHBy ZWZpeGVzIGFwcGVhciB0byBiZSB1bmRlcGxveWFibGUgZm9yIE1vYmlsaXR5IGFuZCBWTSBNb2Jp bGl0eQ0KPiB1c2FnZS4NCj4NCj4gU2VlIGFib3ZlIGV4YW1wbGUuDQo+DQo+ID4+IFtCXSBMSVNQ IE11bHRpY2FzdCB2cy4gRUlEL1JMT0Mgc2VwYXJhdGUNCj4gPj4NCj4gPj4gLSA2LiBNdWx0aWNh c3QNCj4gPj4NCj4gPj4gVGhpcyBpcyBpbnRlcmVzdGluZywgbXVsdGljYXN0IGFkZHJlc3NlcyAo RykgbG9vayBsaWtlIHRoZXkncmUgYW4gZXhjZXB0aW9uDQo+DQo+IFRoZXkgYXJlIHJlYWxseSBu b3QuIFNpbmNlIG11bHRpY2FzdCBhZGRyZXNzZXMgKmlkZW50aWZ5KiBhIGdyb3VwIG9mDQo+IHJl Y2VpdmVycywgaXQgaXMgdmVyeSBtdWNoIGFuIEVJRCBhbmQgYWhlcmVzIHRvIHRoZSBkZWZpbml0 aW9uIG9mIGFuIEVJRC4NCj4gTXVsdGljYXN0IGFkZHJlc3NlcyBuZXZlciBoYWQgdG9wb2xvZ2lj YWwgc2lnbmZpY2FuY2UgYnV0IHRoZSBzdGF0ZQ0KPiByZXByZXNlbnRpbmcgYSBkaXN0cmlidXRp b24gdHJlZSBkb2VzIHRlbGwgeW91IHdlcmUgdGhlIG1lbWJlcnMgYXJlIChidXQgdGhlDQo+IGlk ZW50aXR5IG9mIHRoZSBtZW1iZXJzIGFyZSBub3Qga25vdyBpbiBtdWx0aWNhc3QpLg0KPg0KPiBT byBpdCBtYWtlcyBwZXJmZWN0IHNlbnNlIHRvIHJlZ2lzdGVyIG11bHRpY2FzdCBhZGRyZXNzZXMg dG8gdGhlIG1hcHBpbmcNCj4gc3lzdGVtIGFzIEVJRHMgYW5kIHRoZXkgY2FuIG1hcCB0byBSTE9D cyBvZiBzaXRlcyB0aGF0IGhhdmUgam9pbmVkIHRoZSBncm91cC4NCj4gU2VlIGRyYWZ0LWZhcmlu YWNjaS1zaWduYWwtZnJlZS1tdWx0aWNhc3QgYXMganVzdCBvbmUgZXhhbXBsZS4gUkZDNjgzMSBh bmQNCj4gZHJhZnQtZmFyaW5hY2NpLWxpc3AtbXItc2lnbmFsaW5nIGFyZSBvdGhlciBleGFtcGxl cy4NCj4NCj4gPj4gdG8gdGhlIEVJRC9STE9DIHNlcGFyYXRpb24gYXMgdGhlIHNhbWUgZGVzdGlu YXRpb24gSVAgbXVsdGljYXN0IGFkZHJlc3MNCj4gPj4gaXMgdXNlZCBmb3IgYm90aCBwdXJwb3Nl cy4gIFRoaXMgY291bGQgdXNlIHNvbWUgbW9yZSBkaXNjdXNzaW9uLCBhcyBpdCdzDQo+ID4+IHVu ZXhwZWN0ZWQgYmFzZWQgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSBkcmFmdCB1cCB0byB0aGlzIHBv aW50Lg0KPg0KPiBJIGJlbGlldmUgdGhlIGxldmVsIG9mIGRldGFpbCB3ZSBoYXZlIGluIHRoZSBp bnRyb2R1Y3Rpb24gZG9jdW1lbnQgaXMgYXQgdGhlDQo+IHJpZ2h0IGxldmVsIG9yIHdlJ2xsIGVy ciBvbiBoYXZpbmcgd2F5IHRvbyBtYW55IGRldGFpbHMgY3JvcCBpbi4NCj4NCj4gPj4gLSA3LjIu ICBMSVNQIGZvciBJUHY2IENvLWV4aXN0ZW5jZQ0KPiA+Pg0KPiA+PiAgICBMSVNQIGVuY2Fwc3Vs YXRpb25zIGFsbG93cyB0byB0cmFuc3BvcnQgcGFja2V0cyB1c2luZyBFSURzIGZyb20gYQ0KPiA+ PiAgICBnaXZlbiBhZGRyZXNzIGZhbWlseSAoZS5nLiwgSVB2Nikgd2l0aCBwYWNrZXRzIGZyb20g b3RoZXIgYWRkcmVzcw0KPiA+PiAgICBmYW1pbGllcyAoZS5nLiwgSVB2NCkuDQo+ID4+DQo+ID4+ IEhvdyBkb2VzIHRoYXQgd29yayBmb3IgbXVsdGljYXN0IHRyYWZmaWMsIHdoZXJlIHRoZSBkZXN0 aW5hdGlvbiBhZGRyZXNzDQo+ID4+IChHKSBoYXMgdG8gYmUgdGhlIHNhbWUgaW4gYm90aCB0aGUg aW5uZXIgYW5kIG91dGVyIGhlYWRlcnM/ICBBcmUgRVRScw0KPiA+PiBhbmQgSVRScyBleHBlY3Rl ZCB0byBtYXAgSVB2NiBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIElQdjQgYW5kIHYudi4/DQo+DQo+ IFRoZSBtYXBwaW5nIHN5c3RlbSBjYW4gbWFwIGFuIChTLUVJRC1pcHY2LCBncm91cC1pcHY2KSAy LXR1cGxlIHRvIGEgUkxPQyBzZXQNCj4gdGhhdCBsb29rZWQgbGlrZSB0aGlzIChpcHY0LW11bHRp Y2FzdCwgaXB2NC11bmljYXN0KSBtZWFuIHRoZSBJVFIgdGhhdA0KPiByZWNlaXZlcyB0aGUgcGFj a2V0IGZyb20gUy1FSUQtaXB2NiB3b3VsZCByZXBsaWNhdGUgdGhlIHBhY2tldCBhbmQgbXVsdGlj YXN0DQo+IGVuY2Fwc3VsYXRlIHRvIGlwdjQtbXVsdGljYXN0IGFuZCB1bmljYXN0IGVuY2Fwc3Vh bHRlIHRvIGlwdjQtdW5pY2FzdC4NCj4NCj4gPj4gLSA3LjMuICBMSVNQIGZvciBWaXJ0dWFsIFBy aXZhdGUgTmV0d29ya3MNCj4gPj4NCj4gPj4gVGhpcyBhbHNvIGhhcyBtdWx0aWNhc3QgcHJvYmxl bXMsIGFzIHRoZXJlIGlzIG9ubHkgb25lIGluc3RhbmNlIG9mIGVhY2gNCj4gPj4gbXVsdGljYXN0 IGFkZHJlc3MgKEcpIGluIHRoZSB1bmRlcmxheSBuZXR3b3JrLiAgSSB0aGluayBJIGNhbiBmaWd1 cmUgb3V0DQo+IGhvdw0KPg0KPiBZb3UgY2FuIG1hcCBmcm9tIEVJRC1HIHRvIFJMT0MtRyBvbmUg dG8gb25lLiBCdXQgd2UgaGF2ZSBzZWVuIG92ZXIgdGhlIGxhc3QNCj4gZGVjYWRlIGluIGEgaGFs ZiB0aGF0IHdpdGggZ2VuZXJhbCBtdWx0aWNhc3QgZGVwbG95bWVudCB0aGF0IG1hbnktdG8tMSBp cw0KPiBkZXNpcmFibGUuIEhlbmNlLCBub3cgdGhhdCB3ZSBoYXZlIGEgd2F5IHRvIG1hcCB3aXRo IGEgbmV0d29yay1iYXNlZCBkYXRhYmFzZSwNCj4gd2UgY2FuIG1hcCBtdWx0aXBsZSBFSUQtR3Mg dG8gYSBzaW5nbGUgKG9yIG11bHRpcGxlKSBSTE9DLUdzLg0KPg0KPiA+PiB0byBtYWtlIG11bHRp Y2FzdCB3b3JrIGZvciB0aGlzIHVzZSBjYXNlLCBidXQgaXQncyBub3QgaW1tZWRpYXRlbHkgb2J2 aW91cywNCj4gPj4gYW5kIHRoZSByZXN1bHQgd2hlbiB0aGUgc2FtZSB1bmRlcmxheSBtdWx0aWNh c3QgYWRkcmVzcyBpcyB1c2VkIGJ5IG1vcmUNCj4gPj4gdGhhbiBvbmUgVlBOIGNvdWxkIHdlbGwg ZGVsaXZlciBzb21lIHRyYWZmaWMgdG8gRVRScyB0aGF0IGhhdmUgdG8gZGlzY2FyZA0KPg0KPiBU aGlzIGlzIGEgbmVjZXNzYXJ5IGV2aWwgd2hlbiB0aGUgdW5kZXJsYXkgaXMgc3RhdGUgY2hhbGxl bmdlZC4gQnV0IGl0IGlzIGENCj4gc3RhdGUvYmFuZHdpZHRoIHRyYWRlb2ZmLiBXZSBoYXZlIGZv dW5kIHdpdGggTVZQTiBkZXBsb3ltZW50IHRoYXQgdGhlIG5ldHdvcmsNCj4gYWRtaW4gY29uZmln dXJlcyB0aGUgdW5kZXJseSBvciBzaW1wbHkgdW5pY2FzdHMuDQo+DQo+ID4+IGl0IGJlY2F1c2Ug dGhlIEluc3RhbmNlIElEIGlzIHdyb25nIChhbmQgdGhhdCBleGNlc3NpdmUgZGVsaXZlcnkgaXMg YQ0KPiA+PiBzZWN1cml0eSBjb25zaWRlcmF0aW9uLCBzZWUgbWlub3IgaXNzdWUgb24gU2VjdGlv biA4IGJlbG93KS4gIEkgdGhpbmsgYW4NCj4gPj4gZXhwbGFuYXRpb24gaXMgaW4gb3JkZXIuDQo+ DQo+IFRoZXJlIGFyZSBqdXN0IHRvbyBtYW55IGNvbWJpbmF0aW9ucyB0byBtYWtlIGEgaGlnaC1s ZXZlbCBkZXNjcmlwdGlvbiBzaW1wbGUNCj4gdG8gdW5kZXJzdGFuZC4gVGhlIGN1cnJlbnQgaW50 cm9kdWN0aW9uIHRleHQgZG9lcyBhIGZpbmQgam9iIHByb3ZpZGluZw0KPiByZWZlcmVuY2VzIGZv ciBzb21lb25lIHRvIGdvIG9mZiBhbmQgZ2V0IHRoZSBkZXRhaWxzLg0KPg0KPiA+PiAtLSBNaW5v ciBJc3N1ZXMgLS0NCj4gPj4NCj4gPj4gVGhlcmUgc2VlbXMgdG8gYmUgYW4gaW1wbGljaXQgYXNz dW1wdGlvbiB0aGF0IHRoZSBlbmQgaG9zdCBhbmQgaXRzDQo+ID4+IElUUiAoeFRSKSBhcmUgaW4g dGhlIHNhbWUgZG9tYWluIG9yIEF1dG9ub21vdXMgU3lzdGVtLiAgRm9yIGluY3JlbWVudGFsDQo+ DQo+IFRoaXMgaXMgdHJ1ZSB3aGVuIHlvdSBjYWxsIHRoZSBkb21haW4gYSAiTElTUCBzaXRlIi4g QnV0IGlmIHRoZSBzaXRlIGlzDQo+IHVuY2hhbmdlZCBhbmQgb25lIHVzZXMgUElUUnMsIG1heWJl IGV2ZW4gY2xvc2UgdG8gdGhlIHNpdGUsIGxpa2UgaW4gYSBQRQ0KPiByb3V0ZXIsIHRoZW4gdGhl IFBJVFIgaXMgZGVmaW5pdGVseSBpbiBhbm90aGVyIEFTLiBCdXQgbm90ZSBJIHNhaWQgUElUUiBh bmQNCj4gbm90IElUUi4gVGhlIHJlYXNvbiBiZWluZyBpcyBiZWNhdXNlIGFuIElUUiBpcyBjb25m aWd1cmVkIHdpdGggZGF0YWJhc2UtDQo+IG1hcHBpbmcgcHJlZml4ZXMgdGhhdCBpcyB1c2VzIHRv IGVuY2Fwc3VsYXRlIHBhY2tldHMgZnJvbSBzdWNoIGFkZHJlc3Nlcy4NCj4gVmVyc3VzIHRoZSBQ SVRSIGJlaW5nIGFuIElUUiB3aXRoICpubyBkYXRhYmFzZS1tYXBwaW5ncyogcHJvdmlkaW5nIGEg bXVjaCBtb3JlDQo+IGxhcmdlci9vciBtb3JlIGFnZ3JlZ3RhYmxlIHNlcnZpY2UuDQo+DQo+ID4+ IGRlcGxveW1lbnQsIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGFsd2F5cyB0aGUgY2FzZSwgYnV0IEkg dGhpbmsgdGhhdCBvbmx5DQo+ID4+IGhhcyBlZGl0b3JpYWwgaW1wYWN0IG9uIHRoaXMgZG9jdW1l bnQsIGFzIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZQ0KPiA+PiBmdW5kYW1lbnRhbCBMSVNQIG1l Y2hhbmlzbXMgYXJlIGFmZmVjdGVkLiAgVGhlIGF1dGhvcnMgc2hvdWxkIGxvb2sgZm9yDQo+ID4+ IHVzZSBvZiAiZG9tYWluIiBhbmQgIkF1dG9ub21vdXMgU3lzdGVtIiBhbmQgZW5zdXJlIHRoYXQg dGhlIHRleHQgaXMNCj4gPj4gZ2VuZXJhbGl6ZWQgdG8gdGhlIGNhc2Ugd2hlcmUgdGhlIGVuZCBo b3N0IGFuZCBJVFIgYXJlIG1vcmUgd2lkZWx5DQo+ID4+IHNlcGFyYXRlZC4NCj4NCj4gV2UgYXJl IG92ZXJsb2FkZWQgd2l0aCB0ZXJtcyB0aGF0IGNyZWF0ZSB0b3BvbG9naWNhbCBvciBvcmdhbml6 YXRpb24gYm91bmRhcnkuDQo+IEhlbmNlIHdoeSB3ZSBjcmVhdGVkICJMSVNQIHNpdGUiIHdoaWNo IGlzIGFsc28gdGhlIHNhbWUgYXMgYSAiTElTUCBWUE4gc2l0ZSIuDQo+IFdoZXJlIGEgIkxJU1Ag c2l0ZSIgdGhhdCBoYXMgbXVsdGlwbGUgdGVubmFudHMgd291bGQgYmUgbXVsdGlwbGUgIkxJU1Ag VlBODQo+IHNpdGVzIi4NCj4NCj4gPj4gRGVzcGl0ZSBtdWx0aXBsZSAgbWVudGlvbnMgb2YgaW5j cmVtZW50YWwgZGVwbG95bWVudCwgSSBkaWQgbm90DQo+ID4+IHNlZSBhIGRpc2N1c3Npb24gb2Yg aG93IHRoYXQgbWlnaHQgYmUgYWNjb21wbGlzaGVkLiAgVGhlcmUgaXMgc29tZQ0KPg0KPiBUaGVy ZSBhcmUgUHhUUnMgYW5kIE5BVHMuIEFuZCByZWZlcmVuY2VzIHRvIHRoZSBMSVNQIGludGVyd29y a2luZyBSRkMuDQo+DQo+ID4+IHVzZWZ1bCBjb250ZW50IGluIFNlY3Rpb24gMy41LCBidXQgdGhh dCdzIGF0IGJlc3QgYW4gaW5jb21wbGV0ZQ0KPiA+PiBleHBsYW5hdGlvbi4gIFRoaXMgaXMgYW4g T1BTLURpciByZXZpZXcgY29uY2VybiAtIGl0IGZhbGxzIHVuZGVyDQo+ID4+IEEuMS4zIGluIEFw cGVuZGl4IEEgb2YgUkZDIDU3MDY6IEhhcyB0aGUgbWlncmF0aW9uIHBhdGggYmVlbiBkaXNjdXNz ZWQ/DQo+ID4+DQo+ID4+IC0gMy4zLjEuICBMSVNQIEVuY2Fwc3VsYXRpb24NCj4gPj4NCj4gPj4g ICAgdGhlIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkIGJ5DQo+ID4+ICAgIHRoZSBJVFIgYW5kIGln bm9yZWQgb24gcmVjZXB0aW9uLg0KPiA+Pg0KPiA+PiBQbGVhc2UgbWVudGlvbiBtdWx0aXBhdGhp bmcgKGUuZy4sIEVDTVAgYW5kIExBRykgYXMgcG9zc2libGUgaW5mbHVlbmNlcw0KPiA+PiBvbiBo b3cgc291cmNlIHBvcnRzIGFyZSBzZWxlY3RlZCwgYXMgdGhpcyBpbXBvc2VzIHNvbWUgbGltaXRz IG9uIHdoYXQgYW4NCj4gPj4gSVRSIGNhbiByZWFzb25hYmx5IGRvLg0KPg0KPiBFQ01QL0xBRyBk b24ndCBpbmZsdWVuY2Ugd2hpY2ggc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQuIEl0IGlzIGEgNS10 dXBsZSBoYXNoDQo+IG9mIHRoZSBpbm5lciBoZWFkZXIgdGhhdCBzZWxlY3RzIGEgc291cmNlIHBv cnQgdGhhdCBpbmZsdWVuY2VzIGhvdyBhbiB1bmRlcmxheQ0KPiByb3V0ZXIgd291bGQgbG9hZC1z cGxpdCB0cmFmZmljLg0KPg0KPiA+PiBGb3IgT1BTLURpciwgdGhpcyBtdWx0aXBhdGhpbmcgY29u Y2VybiBmYWxscyB1bmRlciBBLjEuNCBpbiBBcHBlbmRpeCBBIG9mDQo+ID4+IFJGQyA1NzA2OiBI YXZlIHRoZSBSZXF1aXJlbWVudHMgb24gb3RoZXIgcHJvdG9jb2xzIGFuZCBmdW5jdGlvbmFsDQo+ ID4+ICAgICAgICBjb21wb25lbnRzIGJlZW4gZGlzY3Vzc2VkPw0KPiA+Pg0KPiA+PiAgICBUaGlz IGRlY2lzaW9uIHdhcyBtYWRlIGJlY2F1c2UgdGhlDQo+ID4+ICAgIHR5cGljYWwgdHJhbnNwb3J0 IHByb3RvY29scyB1c2VkIGJ5IHRoZSBhcHBsaWNhdGlvbnMgYWxyZWFkeSBpbmNsdWRlDQo+ID4+ ICAgIGEgY2hlY2tzdW0sIGJ5IG5lZ2xlY3RpbmcgdGhlIGFkZGl0aW9uYWwgVURQIGVuY2Fwc3Vs YXRpb24gY2hlY2tzdW0NCj4gPj4gICAgeFRScyBjYW4gZm9yd2FyZCBwYWNrZXRzIG1vcmUgZWZm aWNpZW50bHkuDQo+ID4+DQo+ID4+IEdyb2FuISAgSSBoYXZlIGFuIGV4cXVpc2l0ZSBzZXQgb2Yg c2NhcnMgb24gVURQIHplcm8gY2hlY2tzdW1zIGZvciBJUHY2DQo+ID4+IGZyb20gd29ya2luZyBv biB0aGUgTVBMUyBpbiBVRFAgZHJhZnQsIHNvIEkgbWF5IGJlIG92ZXJseSBzZW5zaXRpdmUgdG8N Cj4gPj4gdGhpcyBjb25jZXJuLiAgVGhlIGRvd25zaWRlIG9mIHRoaXMgZWZmaWNpZW5jeSBpcyB0 aGF0IHRoZXJlIGlzIG5vDQo+ID4+IGNoZWNrc3VtIGNvdmVyYWdlIG9mIHRoZSBJUHY2IGhlYWRl ciB3aGVuIHplcm8gVURQIGNoZWNrc3VtcyBhcmUgdXNlZC4NCj4gPj4gVGhhdCBzaG91bGQgYXQg bGVhc3QgYmUgbWVudGlvbmVkIGhlcmUsIHdpdGggYSBzdW1tYXJ5IG9mIHdoeSB0aGF0J3Mgb2sN Cj4gPj4gLSB0aGUgZGV0YWlsZWQganVzdGlmaWNhdGlvbiBmb3Igd2h5IHRoYXQncyBvayBjYW4g YmUgbGVmdCB0byBvdGhlcg0KPiA+PiBkb2N1bWVudHMuDQo+DQo+IE15IGhlYWQgc3BpbnMgZXZl cnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBzdWJqZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW4N Cj4gdGFsa2VkIGFib3V0IGZyb20gMTAwcyBvZiBwZW9wbGUgZm9yIGEgZGVjYWRlLiBXZSBoYXZl IENSQyBvbiBsaW5rcywgd2UgaGF2ZQ0KPiBhcHBzIHRoYXQgdXNlIFRDUCBhbmQgVURQIGNoZWNr c3Vtcy4gTnVmIHNhaWQuDQo+DQo+ID4+DQo+ID4+IC0tIE5pdHMvRWRpdG9yaWFsIENvbW1lbnRz IC0tDQo+ID4+DQo+ID4+IC0gVG9wIG9mIHAuNDoNCj4gPj4NCj4gPj4gICAgVGhlIGluaXRpYWwg bW90aXZhdGlvbiBpbiB0aGUgTElTUCBlZmZvcnQgaXMgdG8gYmUgZmluZCBpbiB0aGUNCj4gPj4N Cj4gPj4gImZpbmQiIC0+ICJmb3VuZCINCj4gPj4NCj4gPj4gLSBTZWN0aW9uIDMuMSwgZmlyc3Qg YnVsbGV0IGl0ZW0NCj4NCj4gV2Ugd2lsbCBjZXJ0YWlubHkgZml4ZSB0aGVzZS4gVGhhbmtzLg0K Pg0KPiA+Pg0KPiA+PiAgICAgICBEZXZpY2VzIGFyZSBhc3NpZ25lZCB3aXRoIHJlbGF0aXZlbHkg b3BhcXVlIGlkZW50aXR5DQo+ID4+ICAgICAgIG1lYW5pbmdmdWwgYWRkcmVzc2VzIHRoYXQgYXJl IGluZGVwZW5kZW50IG9mIHRoZWlyIHRvcG9sb2dpY2FsDQo+ID4+ICAgICAgIGxvY2F0aW9uLg0K PiA+Pg0KPiA+PiBJIGRvbid0IHVuZGVyc3RhbmQgInJlbGF0aXZlbHkgb3BhcXVlIGlkZW50aXR5 IG1lYW5pbmdmdWwiIGFuZA0KPiA+PiBzdWdnZXN0IHJld3JpdGluZyB0aGUgc2VudGVuY2UuICBJ biBwYXJ0aWN1bGFyIC0gb3BhcXVlIHRvIHdoYXQ/DQo+ID4+IG1lYW5pbmdmdWwgdG8gd2hhdCBp biB3aGF0IG1hbm5lcj8NCj4NCj4gV2VsbCBiZWFjdXNlIGl0IGlzIGFzIGFjY3VyYXRlIGFzIGl0 IGNhbiBiZS4gSWYgYXV0b21vYmlsZXMgYXJlIGdvaW5nIHRvIGJlDQo+IGFzc2lnbmVkIEVJRHMg ZnJvbSBhIFZJTiBudW1iZXIgYWxsb2NhdGlvbiBmcm9tIGEgbWFudWZhY3R1cmUsIHRoZSBhZGRy ZXNzIGlzDQo+IHJlbGF0aXZlbHkgb3BhcXVlLiBJZiBhIFZNIGluIGEgZGF0YS1jZW50ZXIgaXMg Z29pbmcgdG8gYmUgYXNzaWduZWQgYW4gRUlEDQo+IGZyb20gdGhlIHNldCBvZiBwcmVmaXhlcyBh bHJlYWR5IGJlaW5nIHVzZWQgYW5kIGFsbG9jYXRlZCB0byB0aGF0IGRhdGEtY2VudGVyLA0KPiB0 aGVuIHRoZXJlIGlzIGEgZ29vZCBjaGFuY2UgdGhhdCBhZGRyZXNzIGlzIGluIGEgcG93ZXItb2Yt MiBibG9jayB0aGF0IGlzDQo+IHN1bW1hcml6YWJsZSBpbiB0aGUgSUdQLg0KPg0KPiA+Pg0KPiA+ PiAtIFNlY3Rpb24gMy4yLCBzZWNvbmQgcGFyYWdyYXBoDQo+ID4+DQo+ID4+IEp1ZGdpbmcgZnJv bSB0aGUgZmlndXJlLCB4VFJzIGFyZSB0aGUgY29tbW9uIGNhc2UsIHdpdGggc2luZ2xlLQ0KPiA+ PiBmdW5jdGlvbiBJVFJzIGFuZCBFVFJzIGJlaW5nIHJhcmUuICBJdCBtaWdodCBiZSBnb29kIHRv IHNheSB0aGF0DQo+ID4+IGFuZCBkaXNjdXNzIHdoZW4gSVRScyBhbmQgRVRScyB0aGF0IGFyZSBu b3QgeFRScyBhcmUgYXBwcm9wcmlhdGUNCj4gPj4gdG8gdXNlLg0KPg0KPiBXaGVuIHlvdSB3YW50 IGVncmVzcyBwYXRoIHNlbGVjdGlvbiB0byBoYXBwZW4gZnVydGhlciBvdXQgaW4gdGhlIHRvcGxv Z2ljYWwNCj4gZnJvbSB0aGUgc291cmNlIGxvY2F0aW9uLCB0aGVuIHlvdSBwdXQgYW4gSVRSLW9u bHkgc3lzdGVtIHRoZXJlLiBXaGVyZSBpbmdyZXNzDQo+IHRvIHRoZSBzYW1lIHNvdXJjZSAoZGVz dGluYXRpb24gaW4gdGhpcyBkaXJlY3Rpb24pLCB0aGUgRVRSIGNhbiBiZSBjbG9zZXIgdG8NCj4g dGhlIGRlc3RpbmF0aW9uLg0KPg0KPiA+Pg0KPiA+PiAtIDNyZCBwYXJhZ3JhcGggb24gcC43Og0K PiA+Pg0KPiA+Pg0KPiA+PiAgICBGaW5hbGx5LCB0aGUgTElTUCBhcmNoaXRlY3R1cmUgZW1waGFz aXplcyBhIGNvc3QgZWZmZWN0aXZlDQo+ID4+ICAgIGluY3JlbWVudGFsIGRlcGxveW1lbnQuDQo+ ID4+DQo+ID4+IEknZCBkZWxldGUgImNvc3QgZWZmZWN0aXZlIiBoZXJlIGFuZCBsb29rIGZvciBv dGhlciBvY2N1cnJlbmNlcw0KPiA+PiBvZiAiY29zdCIgYXMgY2FuZGlkYXRlcyBmb3IgZGVsZXRp b24uICBUaGlzIGlzIHN1cHBvc2VkIHRvIGJlDQo+ID4+IGEgdGVjaG5pY2FsIGRvY3VtZW50LCBz byBkaXNjdXNzaW9uIG9mIGNvc3RzIGlzIGEgYml0IG9mZi10YXJnZXQuDQo+DQo+IEZhaXIgZW5v dWdoLg0KPg0KPiA+PiAtIEZpcnN0IGl0ZW0gYWZ0ZXIgRmlndXJlIDI6DQo+ID4+DQo+ID4+ICAg IDEuICBIb3N0QSByZXRyaWV2ZXMgdGhlIEVJRF9CIG9mIEhvc3RCLCB0eXBpY2FsbHkgcXVlcnlp bmcgdGhlIEROUw0KPiA+PiAgICAgICAgYW5kIG9idGFpbmluZyBhbmQgQSBvciBBQUFBIHJlY29y ZC4NCj4gPj4NCj4gPj4gImFuZCBBIiAtPiAiYW4gQSIgIChzcGVsbGluZyBjaGVja2VycyBkb24n dCBjYXRjaCBldmVyeXRoaW5nKS4NCj4NCj4gQWxyZWFkeSBub3RlZCBhbmQgd2lsbCBiZSBmaXhl ZC4NCj4NCj4gPj4NCj4gPj4gLSAzLjMuMS4gIExJU1AgRW5jYXBzdWxhdGlvbg0KPiA+Pg0KPiA+ PiAgICBPbiB0aGUgb3RoZXIgaGFuZCwgUmVjdXJzaXZlDQo+ID4+ICAgIHR1bm5lbHMgYXJlIG5l c3RlZCB0dW5uZWxzIGFuZCBhcmUgaW1wbGVtZW50ZWQgYnkgdXNpbmcgbXVsdGlwbGUgTElTUA0K PiA+PiAgICBlbmNhcHN1bGF0aW9ucyBvbiBhIHBhY2tldC4NCj4gPj4NCj4gPj4gVGhlIGFib3Zl IHNlbnRlbmNlIHNlZW1zIG91dCBvZiBwbGFjZSBpbiB0aGUgbWlkZGxlIG9mIGEgcGFyYWdyYXBo IGFib3V0DQo+ID4+IFJlLWVuY2Fwc3VsYXRpbmcgdHVubmVscyBhbmQgcm91dGVycyAtIEkgc3Vn Z2VzdCBtb3ZpbmcgaXQgZG93biBpbnRvIGl0cw0KPiA+PiBvd24gcGFyYWdyYXBoIGFuZCBwZXJo YXBzIGFkZGluZyBhIHNlbnRlbmNlIGFib3V0IHdoZXJlL2hvdyBSZWN1cnNpdmUNCj4gPj4gdHVu bmVscyBtYXkgYmUgdXNlZnVsLg0KPg0KPiBHb29kIHN1Z2dlc3Rpb24gYW5kIG1ha2VzIHNlbnNl Lg0KPg0KPiA+PiAtIDMuMy4yLiAgTElTUCBGb3J3YXJkaW5nIFN0YXRlDQo+ID4+DQo+ID4+ICAg IEluIHRoZSBMSVNQIGFyY2hpdGVjdHVyZSwgSVRScyBrZWVwIGp1c3QgZW5vdWdoIGluZm9ybWF0 aW9uIHRvIHJvdXRlDQo+ID4+ICAgIHRyYWZmaWMgZmxvd2luZyB0aHJvdWdoIGl0Lg0KPiA+Pg0K PiA+PiAiaXQuIiAtPiAidGhlbS4iDQo+ID4+DQo+ID4+ICAgIE1lYW5pbmcgdGhhdCwgSVRScyBy ZXRyaWV2ZSBmcm9tIHRoZQ0KPiA+PiAgICBMSVNQIE1hcHBpbmcgU3lzdGVtIG1hcHBpbmdzIGJl dHdlZW4gRUlEIHByZWZpeGVzIGFuZCBSTE9DcyB0aGF0IGFyZQ0KPiA+PiAgICB1c2VkIHRvIGVu Y2Fwc3VsYXRlIHBhY2tldHMuDQo+ID4+DQo+ID4+IFRoaXMgaXMgdGhlIGZpcnN0IHVzZSBvZiB0 aGUgbm90aW9uIG9mIEVJRCBwcmVmaXhlcy4gIFRoYXQgY29uY2VwdCBzaG91bGQNCj4gPj4gYmUg ZXhwbGFpbmVkIGJlZm9yZSBpdCBpcyB1c2VkLCBhbHRob3VnaCBhIGZvcndhcmQgcmVmZXJlbmNl IHRvIHNlY3Rpb24NCj4gPj4gMy40LjEgbWF5IHN1ZmZpY2UuICBJdCBtaWdodCBiZSBiZXR0ZXIg dG8gcmV3cml0ZSB0aGlzIHBhcmFncmFwaCBpbiB0ZXJtcw0KPiA+PiBvZiBFSURzIGFuZCBsZWF2 ZSB0aGUgbm90aW9uIG9mIEVJRCBwcmVmaXhlcyB0byBzZWN0aW9uIDMuNC4xLg0KPg0KPiBIbW0s IEknbGwgbGV0IEFsYmVydCBhbmQgRGFtaWVuIGRlY2lkZSBpZiB3ZSBzaG91bGQgc3RhdGUgIkVJ RC1wcmVmaXhlcyINCj4gZXZlcnl3aGVyZSBpbnN0ZWFkIG9mIGp1c3QgIkVJRCIuDQo+DQo+ID4+ DQo+ID4+IC0gNC40LiAgTVRVIEhhbmRsaW5nDQo+ID4+DQo+ID4+ICAgIEFkZGl0aW9uYWxseSwg TElTUCBhbHNvIHJlY29tbWVuZHMgaW5mZXJyaW5nIHJlYWNoYWJpbGl0eSBvZiBsb2NhdG9ycw0K PiA+PiAgICBieSB1c2luZyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgdW5kZXJsYXksIGlu IHBhcnRpY3VsYXI6DQo+ID4+DQo+ID4+IEl0J2QgYmUgdXNlZnVsIHRvIGFkZCBhIHNlbnRlbmNl IG9yIHR3byBhYm91dCBob3cgTElTUCBhbmQgdGhlIHRlY2huaXF1ZXMNCj4gPj4gaW4gdGhpcyBz ZWN0aW9uIGludGVyYWN0IHdpdGggaG9zdCB1c2Ugb2YgUE1UVUQgYW5kIFBMUE1UVUQuDQo+DQo+ IFRoaXMgaXMgYSBsb3Qgb2YgZGV0YWlsIGJlY2F1c2UgaW4gUkZDNjgzMCB3ZSBoYXZlIDMgcG9z aXRpb25zIG9yIG9wdGlvbnMgb24NCj4gdGhlIHN1YmplY3QuIEFuZCB3ZSBkaWQgcHJvdmlkZSBh IHJlZmVyZW5jZSB0byBSRkM2ODMwIGZvciB0aGlzIHRvcGljLg0KPg0KPiA+PiAtIE5leHQgdG8g bGFzdCBwYXJhZ3JhcGggb24gcC4xNzoNCj4gPj4NCj4gPj4gICAgQWRkaXRpb25hbGx5LCBMSVNQ IGFsc28gcmVjb21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmlsaXR5IG9mIGxvY2F0b3JzDQo+ID4+ ICAgIGJ5IHVzaW5nIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSB1bmRlcmxheSwgaW4gcGFy dGljdWxhcjoNCj4gPj4NCj4gPj4gVGhpcyBsb29rcyBsaWtlIGl0J3MgYSBwYXJhZ3JhcGggZWFy bHkgYW5kIG5lZWRzIHRvIGJlIG1vdmVkIGRvd24gdG8NCj4gPj4gYWZ0ZXIgdGhlIHBhcmFncmFw aCB0aGF0IGZvbGxvd3MgaXQuDQo+DQo+IEFncmVlLg0KPg0KPiA+PiBpZG5pdHMgMi4xMy4wMSBk aWRuJ3QgZmluZCBhbnkgbml0cy4NCj4gPj4NCj4gPj4gVGhhbmtzLA0KPiA+PiAtLURhdmlkDQo+ DQo+IFRoYW5rcyBhZ2FpbiBEYXZpZC4NCj4NCj4gRGlubw0KDQo= --_000_CE03DB3D7B45C245BCA0D243277949363640C1MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFt ZTppbTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBu b25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ SGkgQWxiZXJ0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMgbm90ZWQgYmVsb3csIG9uIHRo ZSBFSUQgcHJlZml4IGZvciBtb2JpbGl0eSBpc3N1ZSwgYSBzaW1wbGUgc3RhdGVtZW50IGluIFNl Y3Rpb24gNSB0byB0aGUgZWZmZWN0IHRoYXQg4oCcaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgYSBW TS9tb2JpbGUgbm9kZSB0aGUgRUlELXByZWZpeCBzaG91bGQNCiBiZSAvMzIgb3IgLzEyOCAoSVB2 NCBvciBJUHY2IHJlc3BlY3RpdmVseSnigJ0gd2lsbCBzdWZmaWNlLiZuYnNwOyBEZXRhaWxzIG9u IHdoYXQgdG8gZG8gd2hlbiB0aGF0IGFkdmljZSBpcyBpZ25vcmVkIGNhbiBiZSBsZWZ0IHRvIG90 aGVyIGRvY3VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MsPGJy Pg0KLS1EYXZpZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gQWxiZXJ0IENhYmVsbG9zIFttYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdt YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE1 IDY6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj4gRGlu byBGYXJpbmFjY2k7IEpvZWwgTS4gSGFscGVybjsgRGFtaWVuIFNhdWNlejsgb3BzLWRpckBpZXRm Lm9yZzsgaWV0ZkBpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24t MTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgRGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyBmb3IgeW91ciBjb21tZW50cywgSSBhbSBwYXJzaW5nIHRoZW0gYW5kIEnCtGxsIHN1Z2dl c3QgbmV3IHRleHQgYWltaW5nIHRvIGFkZHJlc3MgdGhlbSBBU0FQLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGFsc28gbGlrZSB0 byBiZXR0ZXIgdW5kZXJzdGFuZCBbQV0gYmVmb3JlIGRvaW5nIHRoaXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggTElTUCBhbiBFSUQt cHJlaWZ4IGNhbiBoYXZlIGFuIGFyYml0cmFyeSBsZW5ndGggYW5kIGNhbiBtb3ZlIChpLmUuLCBj aGFuZ2UgaXRzIFJMT0MgYmluZGluZ3MpLCBpbiB0aGUgc3BlY2lmaWMgY2FzZSBvZiBhIFZNL21v YmlsZSBub2RlIHRoZSBFSUQtcHJlZml4IHNob3VsZCBiZSAvMzIgb3IgLzEyOCAoSVB2NCBvciBJ UHY2IHJlc3BlY3RpdmVseSkuIFdoYXQgZG9lc24ndCB3b3JrIGlzIHRoZSBtb2JpbGl0eQ0KIG9m IGEgbm9kZSAoYXNzaWduZWQgd2l0aCBhIC8zMiBvciAvMTI4KSAqd2l0aGluKiBhIGNvYXJzZXIg RUlELXByZWZpeCwgaW4gdGhpcyBjYXNlIHlvdSBuZWVkIHRvIHNwbGl0IHRoZSBwcmVmaXggaW50 byBtb3JlIHNwZWNpZmljcyBhbmQgcmVnaXN0ZXIgdGhlbSBpbmRlcGVuZGVudGx5IGluIHRoZSBN YXBwaW5nIFN5c3RlbSwgZWZmZWN0aXZlbHkgY3JlYXRpbmcgbmV3IEVJRC1wcmVmaXhlcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNl IGxldCBtZSBrbm93IGlmIHRoaXMgY2xhcmlmaWVzIHlvdXIgY29tbWVudCwgaW4gdGhpcyBjYXNl IEkgd2lsbCBzdWdnZXN0IG5ldyB0ZXh0IGZvciBTZWN0aW9uIDUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsYmVydDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRmViIDEyLCAyMDE1 IGF0IDEyOjA3IEFNLCBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFj a0BlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGlubyAtIHRoYW5rcyBm b3IgdGhlIHJlc3BvbnNlLjxicj4NCjxicj4NCk9uIHRoZSBtYWpvciBpc3N1ZXMsIGl0IGxvb2tz IGxpa2UgYm90aCBbQV0gYW5kIFtCXSBpbnZvbHZlIG9ubHkgdGhlIHRleHQ8YnI+DQppbiB0aGlz IGRyYWZ0IGFuZCBub3RoaW5nIGJleW9uZCwgd2hpY2ggaXMgZ29vZCBuZXdzLiZuYnNwOyBJIGhh dmUgYSBzaW1wbGUgdGV4dDxicj4NCnN1Z2dlc3Rpb24gZm9yIFtBXSwgYnV0IGl0IGxvb2tzIGxp a2UgW0JdIGlzIGdvaW5nIHRvIHJlcXVpcmUgc29tZSBjYXJlZnVsPGJyPg0KZWRpdGluZywgYXMg b25lIG9mIHRoZSBwcmltYXJ5IGNhdXNlcyBpcyB0aGF0IHRoZSBkcmFmdCBpcyBzbG9wcHkgaW4g dXNpbmc8YnI+DQp0aGUgc2FtZSBzeW1ib2wgJnF1b3Q7RyZxdW90OyB0byByZXByZXNlbnQgYm90 aCBFSUQgYW5kIFJMT0MgbXVsdGljYXN0IGdyb3Vwcy48YnI+DQo8YnI+DQpPbiB0aGUgbWlub3Ig aXNzdWVzLCBJIGhhdmUgdGV4dCBzdWdnZXN0aW9ucyBmb3IgdGhyZWUgb2YgdGhlIGZvdXIsIGFu ZDxicj4NCkknZCBsaWtlIHRvIHRlbXBvcmFyaWx5IGRlZmVyIGZ1cnRoZXIgZGlzY3Vzc2lvbiB0 aGUgSVB2NiBVRFAgemVybzxicj4NCmNoZWNrc3VtICZxdW90O3RhcnBpdCZxdW90OyBpbiBmYXZv ciBvZiByZXNvbHZpbmcgZXZlcnl0aGluZyBlbHNlIGZpcnN0Ljxicj4NCjxicj4NCk9uIHRoZSBu aXRzL2VkaXRvcmlhbCBjb21tZW50cywgYWxsIHRoZSBzdWdnZXN0aW9ucyBpbiB5b3VyIGVtYWls IGFyZSBmaW5lPGJyPg0Kd2l0aCBtZS4mbmJzcDsgRldJVywgSSByZWdhcmQgdGhhdCBwb3J0aW9u IG9mIGEgcmV2aWV3IGFzIGFsbW9zdCBlbnRpcmVseTxicj4NCnN1YmplY3QgdG8gdGhlIGRyYWZ0 IGF1dGhvcnMnIGRpc2NyZXRpb24gKGFuZCBlZGl0b3JpYWwgdGFzdGUpLjxicj4NCjxicj4NCiZn dDsgJmd0OyZndDsgW0FdIEVJRCBtb2JpbGl0eSB2cy4gRUlEIHByZWZpeGVzPGJyPg0KJmd0Ozxi cj4NCiZndDsgLi4uIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBMSVNQIGRlc2lnbiAoY2lyY2EgMjAw NyksIGFuIHByZWZpeCBpcyB3aGF0IG1vdmVzLjxicj4NCiZndDsgQW5kIGEgc3BlY2lmaWMgRUlE IGlzIHNpbXBseSBhIC8zMiBvciAvMTI4IHByZWZpeC4gSGVyZSBpcyBhIHByYWN0aWNhbDxicj4N CiZndDsgZXhhbXBsZTo8YnI+DQo8YnI+DQpBIHN0YXRlbWVudCB0aGF0IHRoZSBtb2JpbGl0eSB1 c2UgY2FzZXMgbmVlZCB0byBlbXBsb3kgLzMyIGFuZCAvMTI4IHByZWZpeGVzLDxicj4NCmFuZCBu b3QgYW55dGhpbmcgY29hcnNlciBzaG91bGQgc3VmZmljZS4mbmJzcDsgVGhhdCBzaG91bGQgYmUg YWRkZWQgdG8gU2VjdGlvbiA1Ljxicj4NCjxicj4NCiZndDsgJmd0OyZndDsgW0JdIExJU1AgTXVs dGljYXN0IHZzLiBFSUQvUkxPQyBzZXBhcmF0ZTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7IC0gNi4gTXVsdGljYXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgVGhpcyBpcyBpbnRlcmVzdGluZywgbXVsdGljYXN0IGFkZHJlc3NlcyAoRykgbG9vayBs aWtlIHRoZXkncmUgYW4gZXhjZXB0aW9uPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhleSBhcmUgcmVh bGx5IG5vdC48YnI+DQo8YnI+DQpNeSBjb25jZXJuIGlzIHRoYXQgYXMgSSByZWFkIHRoZSBkcmFm dCwgaXQgbGVhdmVzIG1lIHdpdGggdGhlIHN0cm9uZyBpbXByZXNzaW9uPGJyPg0KdGhhdCB0aGUg c2FtZSBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBhcmUgYmVpbmcgdXNlZCBpbiBib3RoIHRoZSBv dmVybGF5PGJyPg0KKGFzIEVJRHMpIGFuZCB0aGUgdW5kZXJsYXkgKGFzIFJMT0NzKS4mbmJzcDsg RnJvbSB5b3VyIHJlc3BvbnNlLCBJIGNvbmNsdWRlIHRoYXQgdGhpczxicj4NCmlzIG5vdCB0aGUg Y2FzZSAoYW5kIEkgaGF2ZSBubyBhcmd1bWVudCB3aXRoIHRoYXQpLiZuYnNwOyBSYXRoZXIsIFNl Y3Rpb24gNiBuZWVkcyB0bzxicj4NCmJsdW50bHkgc3RhdGUgdGhhdCBtdWx0aWNhc3QgYWRkcmVz c2VzIGFyZSBtYXBwZWQgYmV0d2VlbiBFSUQgYW5kIFJMT0Mgc3BhY2UgYXQ8YnI+DQpib3RoIElU UnMgYW5kIEVUUnMsIHNvIHRoYXQgdGhlIGZvbGxvd2luZyBpbmZlcmVuY2UgaXMgb2J2aW91cyBm cm9tIHRoZSB0ZXh0PGJyPg0KKGl0J3MgY3VycmVudGx5IG5vdCBvYnZpb3VzKTo8YnI+DQo8YnI+ DQomZ3Q7IFNvIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gcmVnaXN0ZXIgbXVsdGljYXN0IGFk ZHJlc3NlcyB0byB0aGUgbWFwcGluZzxicj4NCiZndDsgc3lzdGVtIGFzIEVJRHMgYW5kIHRoZXkg Y2FuIG1hcCB0byBSTE9DcyBvZiBzaXRlcyB0aGF0IGhhdmUgam9pbmVkIHRoZSBncm91cC48YnI+ DQo8YnI+DQpBcyBwYXJ0IG9mIHRoaXMsIEkgc3Ryb25nbHkgcmVjb21tZW5kIG1vdmluZyBhd2F5 IGZyb20gdXNlIG9mICZxdW90O0cmcXVvdDsgdG8gcmVmZXIgdG88YnI+DQptdWx0aWNhc3QgZ3Jv dXBzIGluIGJvdGggdGhlIG92ZXJsYXkgYW5kIHVuZGVybGF5LiZuYnNwOyBDYXJlZnVsIHVzZSBv ZiBHLUVJRDxicj4NCmFuZCBHLVJMT0Mgd291bGQgc2lnbmlmaWNhbnRseSBpbXByb3ZlIGNsYXJp dHkuPGJyPg0KPGJyPg0KLS0tPGJyPg0KSWYgdGhlIGFib3ZlIGFyZSBkb25lIGZvciBbQV0gYW5k IFtCXSBpbiBTZWN0aW9ucyA1IGFuZCA2LCB0aGVuIHRoZSB0ZXh0IGZvciB0aGU8YnI+DQp1c2Ug Y2FzZXMgaW4gU2VjdGlvbiA3IHNob3VsZCBub3QgbmVlZCBmdXJ0aGVyIGF0dGVudGlvbi48YnI+ DQotLS08YnI+DQo8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tIE1pbm9yIElzc3VlcyAtLTxicj4NCiZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoZXJlIHNlZW1zIHRvIGJlIGFuIGltcGxp Y2l0IGFzc3VtcHRpb24gdGhhdCB0aGUgZW5kIGhvc3QgYW5kIGl0czxicj4NCiZndDsgJmd0OyZn dDsgSVRSICh4VFIpIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3IgQXV0b25vbW91cyBTeXN0ZW0u Jm5ic3A7IEZvciBpbmNyZW1lbnRhbDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgaXMgdHJ1ZSB3 aGVuIHlvdSBjYWxsIHRoZSBkb21haW4gYSAmcXVvdDtMSVNQIHNpdGUmcXVvdDsuIEJ1dCBpZiB0 aGUgc2l0ZSBpczxicj4NCiZndDsgdW5jaGFuZ2VkIGFuZCBvbmUgdXNlcyBQSVRScywgbWF5YmUg ZXZlbiBjbG9zZSB0byB0aGUgc2l0ZSwgbGlrZSBpbiBhIFBFPGJyPg0KJmd0OyByb3V0ZXIsIHRo ZW4gdGhlIFBJVFIgaXMgZGVmaW5pdGVseSBpbiBhbm90aGVyIEFTLjxicj4NCjxicj4NCkxvb2tp bmcgYXQgdGhlIHRleHQsIGl0IHNlZW1zIHRoYXQgJnF1b3Q7TElTUCBzaXRlJnF1b3Q7IGFuZCAm cXVvdDtkb21haW4mcXVvdDsgYXJlIHRoZSBzYW1lPGJyPg0KY29uY2VwdCBmb3IgdGhpcyBkcmFm dC4mbmJzcDsgVGhhdCB3b3VsZCBiZSB1c2VmdWwgdG8gc3RhdGUsIElNSE8gYnV0IEknbGwgbGVh dmU8YnI+DQp0aGUgZGVjaXNpb24gb24gd2hldGhlciB0byBkbyBzbyB0byB5b3UgYW5kIHRoZSBk cmFmdCBhdXRob3JzLjxicj4NCjxicj4NCk9uIHJlcmVhZGluZywgbXkgY29uY2VybnMgc2VlbSB0 byBiZSB0cmlnZ2VyZWQgbW9zdGx5IGJ5IHRoaXMgc2VudGVuY2UgaW48YnI+DQpTZWN0aW9uIDMu Mjo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIGVkZ2UgY29uc2lzdHMgb2YgTElTUCBzaXRl cyAoZS5nLiwgYW48YnI+DQombmJzcDsgJm5ic3A7QXV0b25vbW91cyBTeXN0ZW0pIHRoYXQgdXNl IEVJRCBhZGRyZXNzZXMuPGJyPg0KPGJyPg0KSSB0aGluayBhIHNtYWxsIGNoYW5nZSB0byB0aGUg bGFzdCBzZW50ZW5jZSBpbiB0aGF0IHBhcmFncmFwaCB3b3VsZCByZXNvbHZlPGJyPg0KbXkgY29u Y2VybiB3aXRob3V0IGRpc3RyYWN0aW5nIGZyb20gdGhlIG5hcnJhdGl2ZTo8YnI+DQo8YnI+DQpP TEQ8YnI+DQombmJzcDsgJm5ic3A7RUlEcyBkbyBub3Q8YnI+DQombmJzcDsgJm5ic3A7Y29udGFp biBpbnRlci1kb21haW4gdG9wb2xvZ2ljYWwgaW5mb3JtYXRpb24gYW5kIGJlY2F1c2Ugb2YgdGhp cyw8YnI+DQombmJzcDsgJm5ic3A7RUlEcyBhcmUgdXN1YWxseSByb3V0YWJsZSBhdCB0aGUgZWRn ZSAod2l0aGluIExJU1Agc2l0ZXMpIG9yIGluIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtub24tTElT UCBJbnRlcm5ldC48YnI+DQpORVc8YnI+DQombmJzcDsgJm5ic3A7RUlEcyBkbyBub3Q8YnI+DQom bmJzcDsgJm5ic3A7Y29udGFpbiBpbnRlci1kb21haW4gdG9wb2xvZ2ljYWwgaW5mb3JtYXRpb24g YW5kIGJlY2F1c2Ugb2YgdGhpcyw8YnI+DQombmJzcDsgJm5ic3A7RUlEcyBhcmUgdXN1YWxseSBy b3V0YWJsZSBhdCB0aGUgZWRnZSAod2l0aGluIExJU1Agc2l0ZXMpIG9yIGluIHRoZTxicj4NCiZu YnNwOyAmbmJzcDtub24tTElTUCBJbnRlcm5ldDsgc2VlIFNlY3Rpb24gMy41IGZvciBkaXNjdXNz aW9uIG9mIExJU1Agc2l0ZTxicj4NCiZuYnNwOyAmbmJzcDtpbnRlcm5ldHdvcmtpbmcgd2l0aCBu b24tTElTUCBzaXRlcyBhbmQgZG9tYWlucyBpbiB0aGUgSW50ZXJuZXQuPGJyPg0KPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBEZXNwaXRlIG11bHRpcGxlJm5ic3A7IG1lbnRpb25zIG9mIGluY3JlbWVudGFs IGRlcGxveW1lbnQsIEkgZGlkIG5vdDxicj4NCiZndDsgJmd0OyZndDsgc2VlIGEgZGlzY3Vzc2lv biBvZiBob3cgdGhhdCBtaWdodCBiZSBhY2NvbXBsaXNoZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsg VGhlcmUgYXJlIFB4VFJzIGFuZCBOQVRzLiBBbmQgcmVmZXJlbmNlcyB0byB0aGUgTElTUCBpbnRl cndvcmtpbmcgUkZDLjxicj4NCjxicj4NCk9rLCBjYW4gd2UganVzdCBzYXkgc28gaW4gU2VjdGlv biAzLjU/Jm5ic3A7IEFkZGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlPGJyPg0KdG8gdGhlIGVu ZCBvZiB0aGUgc2VjdGlvbiB3b3VsZCBzdWZmaWNlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtQ SVRScywgUEVUUnMgYW5kIExJU1AtTkFUIHN1cHBvcnQgaW5jcmVtZW50YWwgZGVwbG95bWVudCBv ZiBMSVNQPGJyPg0KJm5ic3A7ICZuYnNwO2J5IHByb3ZpZGluZyBzaWduaWZpY2FudCBmbGV4aWJp bGl0eSBpbiBsb2NhdGlvbiBvZiB0aGUgYm91bmRhcmllczxicj4NCiZuYnNwOyAmbmJzcDtiZXR3 ZWVuIHRoZSBMSVNQIGFuZCBub24tTElTUCBwb3J0aW9ucyBvZiB0aGUgbmV0d29yaywgYW5kIG1h a2luZzxicj4NCiZuYnNwOyAmbmJzcDtpdCByZWFzb25hYmxlIHRvIGNoYW5nZSB0aG9zZSBib3Vu ZGFyaWVzIG92ZXIgdGltZS48YnI+DQo8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gMy4zLjEuJm5ic3A7 IExJU1AgRW5jYXBzdWxhdGlvbjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyB0aGUgc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQgYnk8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgSVRSIGFuZCBpZ25vcmVkIG9uIHJlY2VwdGlvbi48YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBQbGVhc2UgbWVudGlvbiBtdWx0aXBh dGhpbmcgKGUuZy4sIEVDTVAgYW5kIExBRykgYXMgcG9zc2libGUgaW5mbHVlbmNlczxicj4NCiZn dDsgJmd0OyZndDsgb24gaG93IHNvdXJjZSBwb3J0cyBhcmUgc2VsZWN0ZWQsIGFzIHRoaXMgaW1w b3NlcyBzb21lIGxpbWl0cyBvbiB3aGF0IGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJVFIgY2FuIHJl YXNvbmFibHkgZG8uPGJyPg0KJmd0Ozxicj4NCiZndDsgRUNNUC9MQUcgZG9uJ3QgaW5mbHVlbmNl IHdoaWNoIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkLiBJdCBpcyBhIDUtdHVwbGUgaGFzaDxicj4N CiZndDsgb2YgdGhlIGlubmVyIGhlYWRlciB0aGF0IHNlbGVjdHMgYSBzb3VyY2UgcG9ydCB0aGF0 IGluZmx1ZW5jZXMgaG93IGFuIHVuZGVybGF5PGJyPg0KJmd0OyByb3V0ZXIgd291bGQgbG9hZC1z cGxpdCB0cmFmZmljLjxicj4NCjxicj4NClBsZWFzZSBzdGF0ZSB0aGF0IGEgNS10dXBsZSBoYXNo IGlzIHVzZWQuJm5ic3A7IEVDTVAvTEFHIGlzIGFtb25nIHRoZSBpbXBvcnRhbnQ8YnI+DQpyZWFz b25zIHdoeSwgYnV0IHRoYXQgZG9lc24ndCBuZWVkIHRvIGJlIHN0YXRlZCBpZiB5b3UgcHJlZmVy IG5vdCB0by4mbmJzcDsgQW48YnI+DQpleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IG5lZWRzIHRv IGJlIGV4Y2x1ZGVkIGlzIHRoYXQgdXNpbmcgYSByYW5kb208YnI+DQpudW1iZXIgZ2VuZXJhdG9y IHRvIHNldCB0aGUgc291cmNlIHBvcnQgd291bGQgYmUgd3JvbmcgLSBJIGNvdWxkIHN1Z2dlc3Q8 YnI+DQpjaXRpbmcgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwIGZvciByZWxhdGVkIGRpc2N1c3Np b24gKGFuZCBsb3RzIG1vcmU8YnI+DQpkZXRhaWxzKSwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCdz IG5lY2Vzc2FyeS48YnI+DQo8YnI+DQotLSBJUHY2IHplcm8gVURQIGNoZWNrc3VtPGJyPg0KPGJy Pg0KJmd0OyBNeSBoZWFkIHNwaW5zIGV2ZXJ5IHRpbWUgSSBoZWFyIGFib3V0IHRoaXMgc3ViamVj dC4gVGhpcyBzdWJqZWN0IGhhcyBiZWVuPGJyPg0KJmd0OyB0YWxrZWQgYWJvdXQgZnJvbSAxMDBz IG9mIHBlb3BsZSBmb3IgYSBkZWNhZGUuIFdlIGhhdmUgQ1JDIG9uIGxpbmtzLCB3ZSBoYXZlPGJy Pg0KJmd0OyBhcHBzIHRoYXQgdXNlIFRDUCBhbmQgVURQIGNoZWNrc3Vtcy4gTnVmIHNhaWQuPGJy Pg0KPGJyPg0KVW5kZXJzdG9vZCAtIHRoZXJlJ3MgbW9yZSB0aGFuIG9uZSBzZXQgb2Ygc2NhcnMg b24gdGhpcyBvbmUgOi0oLiZuYnNwOyBMZXQncyBjb21lIGJhY2s8YnI+DQp0byB0aGlzIHRvcGlj IGFmdGVyIHdlJ3ZlIHJlc29sdmVkIGV2ZXJ5dGhpbmcgZWxzZSwgYW5kIHBsZWFzZSBrZWVwIGlu IG1pbmQ8YnI+DQp0aGF0IEkgdGFnZ2VkIHRoaXMgYXMgYSBtaW5vciBpc3N1ZSwgbm90IGEgbWFq b3Igb25lIChlLmcuLCB0aGUgYWJvdmUgY2hhbmdlczxicj4NCmZvciBbQV0gYW5kIFtCXSBhcmUg ZmFyIG1vcmUgaW1wb3J0YW50LCBJTUhPKS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KLS1EYXZp ZDxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgRnJvbTogRGlubyBGYXJpbmFj Y2kgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbSI+ZmFyaW5hY2Np QGdtYWlsLmNvbTwvYT5dPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE1IDI6MTkgUE08L3NwYW4+PGJyPg0KPHNwYW4gY2xh c3M9ImltIj4mZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImltIj4mZ3Q7IENjOiBCbGFjaywgRGF2aWQ7IEFsYmVydCBDYWJlbGxvczsgRGFtaWVuIFNhdWNl ejsgPGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmciPg0Kb3BzLWRpckBpZXRmLm9yZzwv YT47PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyA8YSBocmVmPSJtYWlsdG86aWV0 ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYu b3JnIj4NCmxpc3BAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0 OyBTdWJqZWN0OiBSZTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1p bnRyb2R1Y3Rpb24tMTE8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgJmd0OyBJIHdpbGwgbGVhdmUgbW9zdCBvZiB0aGVz ZSBmb3IgdGhlIGF1dGhvcnMgdG8gY29tbWVudCBvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWUg bXkgY29tbWVudHMgaW5saW5lLiBUaGFua3MgRGF2aWQgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3 IGFuZCBjb21tZW50YXJ5Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgV2l0aCByZWdhcmQgdG8g eW91ciBxdWVzdGlvbiBhYm91dCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LCB0aGF0IGlzIHRoZTxi cj4NCiZndDsgZG9tYWluIG9mIHRoZSBMSVNQIERlcGxveW1lbnQgZG9jdW1lbnQsIGFuZCB3YXMg ZGVsaWJlcmF0ZWx5IG9ubHkgbGlnaHRseTxicj4NCiZndDsgY292ZXJlZCBoZXJlLiZuYnNwOyBJ IGFtIG5vdCBzdXJlIHdoYXQgd2UgY2FuIGRvIHRvIGFkZHJlc3MgeW91ciBjb21tZW50IHdpdGhv dXQ8YnI+DQomZ3Q7IGR1cGxpY2F0aW5nIHRoZSBlbnRpcmV0eSBvZiB0aGF0IGRvY3VtZW50Ljxi cj4NCiZndDs8YnI+DQomZ3Q7IFRoYXQgaXMgdGhlIHJpc2sgd2UgbWF5IGhhdmUgd2l0aCBtYW55 IG9mIHlvdXIgY29tbWVudHMuIFdlIGhhdmUgYSBsb3Qgb2Y8YnI+DQomZ3Q7IGRldGFpbCBpbiB0 aGUgYWxyZWFkeSA5IHB1Ymxpc2hlZCBSRkNzJm5ic3A7IGFuZCB0aGlzIGRvY3VtZW50IHJlYWxs eSBpcyB0byB0YWtlPGJyPg0KJmd0OyBhbGwgdGhhdCBkZXRhaWwgYW5kIHN1bW1hcml6ZSBhcyBh biBlYXNpbHkgdW5kZXJzdGFuZGFibGUgZGVzY3JpcHRpb24gb2YgYTxicj4NCiZndDsgY29oZXNp dmUgZGVzaWduLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgV2l0aCByZWdhcmQgdG8gVURQIFpl cm8sIHRoaXMgd2FzIGFwcHJvdmVkIGJ5IHRoZSBJRVNHIGFuZCBwdWJsaXNoZWQgYXMgYW48YnI+ DQomZ3Q7IFJGQy4mbmJzcDsgSXQgaXMgcGFydCBvZiB0aGUgd2F5IHRoZSBwcm90b2NvbCBpcyBk ZWZpbmVkLiZuYnNwOyBJZiB0aGVyZSBhcmUgc3BlY2lmaWM8YnI+DQomZ3Q7IGNoYW5nZXMgeW91 IHdvdWxkIGxpa2UgdG8gc2VlIGluIHRoZSBleHBsYW5hdG9yeSB0ZXh0LCBJIGFtIHN1cmU8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBEZWZpbml0ZWx5IGFncmVlZC4gSW4gZmFjdCB3ZSBpbnN0aWdhdGVk IFVEUCB6ZXJvLiBBbmQgSSBjb250aW51YWxseSB0YWxrIHRvPGJyPg0KJmd0OyBoYXJkd2FyZSBl bmdpbmVlcnMgYW5kIHRoZXkgYWxsIGJlbGlldmUgd2UgbWFkZSB0aGUgcmlnaHQgZGVjaXNpb24u IFNvIGhhdHM8YnI+DQomZ3Q7IG9mZiB0byB0aGUgSUVURiBmb3IgYmVpbmcgcHJhY3RpY2FsLjxi cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgd2UgY291bGQgaW5jbHVkZSB0aGVtLiZuYnNwOyBJZiB5 b3UgYXJlIGxvb2tpbmcgZm9yIGEgY2hhbmdlIGluIHRoZSBiZWhhdmlvciw8YnI+DQomZ3Q7IHRo aXMgZG9jdW1lbnQgY2FuIG5vdCBtYWtlIGNoYW5nZXMgdG8gdGhlIExJU1AgYmVoYXZpb3IuPGJy Pg0KJmd0Ozxicj4NCiZndDsgWWVzLCBhbiBpbXBvcnRhbnQgcG9pbnQuPGJyPg0KJmd0Ozxicj4N CiZndDsgJmd0OyZndDsgSSBmb3VuZCBhIGNvdXBsZSBvZiBtYWpvciBpc3N1ZXMgdGhhdCBJIGhv cGUgYXJpc2UgZnJvbSB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHN1bW1hcml6YXRpb24gb2YgTElT UCBpbiB0aGlzIGRyYWZ0LCBhcyBvcHBvc2VkIHRvIGJlaW5nIHByb2JsZW1zIGluPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyB0aGUgYWN0dWFsIExJU1AgcHJvdG9jb2xzLiZuYnNwOyBJIGFsc28gZm91bmQg YSBmZXcgbWlub3IgaXNzdWVzLCB0aGUgbW9zdDxicj4NCiZndDsgJmd0OyZndDsgaW1wb3J0YW50 IG9mIHdoaWNoIGlzIHRoZSBuZWVkIGZvciBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBkaXNjdXNzaW9uIG9uIG1pc2RlbGl2ZXJ5LCB3aXRoIHBh cnRpY3VsYXIgYXR0ZW50aW9uIHRvIFZQTnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIGEg dG9uLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tIE1ham9yIGlzc3VlcyAtLTxicj4N CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFtBXSBFSUQgbW9iaWxpdHkgdnMuIEVJ RCBwcmVmaXhlczxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gNS4gTW9i aWxpdHk8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQg aG93IHRoaXMgd29ya3Mgd2hlbiBtYXBwaW5nIGlzIHBlci1FSUQsIGJ1dCBob3cgZG9lcyB0aGlz IHdvcms8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdoZW4gdGhlIEVJRCBvZiB0aGUgc3lzdGVtIHRoYXQg bW92ZXMgaXMgcGFydCBvZiBhbiBFSUQgcHJlZml4LCBhczxicj4NCiZndDsgZGlzY3Vzc2VkPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBpbiBTZWN0aW9uIDMuNC4xPyZuYnNwOyBFdmVuIGlmIHRoZSBhbnN3 ZXIgaXMgYSBsb25nIHZlcnNpb24gb2YgJnF1b3Q7RG9uJ3QgZG8gdGhhdCEmcXVvdDs8YnI+DQom Z3Q7ICZndDsmZ3Q7IGl0IHNob3VsZCBiZSBleHBsYWluZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsg Tm8sIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBMSVNQIGRlc2lnbiAoY2lyY2EgMjAwNyksIGFuIHBy ZWZpeCBpcyB3aGF0IG1vdmVzLjxicj4NCiZndDsgQW5kIGEgc3BlY2lmaWMgRUlEIGlzIHNpbXBs eSBhIC8zMiBvciAvMTI4IHByZWZpeC4gSGVyZSBpcyBhIHByYWN0aWNhbDxicj4NCiZndDsgZXhh bXBsZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZb3UgaGF2ZSBhIGNsdXN0ZXIgb2Ygc2VydmVycyB0 aGF0IGNvbW11bmljYXRlIHRvZ2V0aGVyIGZvciBhIHBhcnRpY3VsYXI8YnI+DQomZ3Q7IGFwcGxp Y2F0aW9uLiBUaGV5IGFwcGxpY2F0aW9uIGNsdXN0ZXIgaXMgcnVubmluZyBpbiBhIHNldCBvZiBW TXMuIFRob3NlIFZNczxicj4NCiZndDsgYXJlIGFzc2lnbmVkIEVJRHMgZnJvbSBhIGNvbW1vbiBw b3dlci1vZi0yIEVJRC1wcmVmaXguIFRob3NlIFZNcyBhcmUgY3VycmVudGx5PGJyPg0KJmd0OyBy dW5uaW5nIGluIGEgYnJpY2stYW5kLW1vcnRhciBkYXRhIGNlbnRlci4gTm93IHRoZXJlIGlzIGEg ZGVzaXJlIHRvIG1vdmUgdGhlPGJyPg0KJmd0OyBWTSBjbHVzdGVyIHRvIGEgY2xvdWQgcHJvdmlk ZXIuIFdoYXQgaXMgbW92ZWQgaXMgdGhlIEVJRC1wcmVmaXggb2YgdGhlPGJyPg0KJmd0OyBjbHVz dGVyLiBUaGUgbWFwcGluZyBzeXN0ZW0gaXMgdG9sZCB0aGF0IHRoZSBFSUQtcHJlZml4IGlzIGNo YW5naW5nIGl0cyBSTE9DLTxicj4NCiZndDsgc2V0IGZyb20gdGhlIGJyaWNrLWFuZC1tb3J0YXIg eFRScyB0byB0aGUgY2xvdWQgcHJvdmlkZXJzIHhUUnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gNy40LiZuYnNwOyBMSVNQIGZvciBWaXJ0dWFsIE1h Y2hpbmUgTW9iaWxpdHkgaW4gRGF0YSBDZW50ZXJzPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGlzIHdvcmtzIHdoZW4gRUlEIHBy ZWZpeGVzIGFyZSB1c2VkLCBhcyBlYWNoIFZNPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBoYXMgaXRzIG93 biBFSUQgb3IgRUlEcywgaGVuY2UgdGhlIGVudGlyZSBwcmVmaXggcmFuZ2UgZG9lcyBub3QgbW92 ZSB3aGVuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGUgVk0gbW92ZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgRm9yIE9QUy1EaXIsIHRoaXMgRUlEIHByZWZpeCBpc3N1ZSBb QV0gZmFsbHMgdW5kZXIgQS4xLjEgaW4gQXBwZW5kaXggQTxicj4NCiZndDsgJmd0OyZndDsgb2Yg UkZDIDU3MDY6Jm5ic3A7IEhhcyBkZXBsb3ltZW50IGJlZW4gZGlzY3Vzc2VkPyBhbmQgc3BlY2lm aWNhbGx5IHVuZGVyOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICombmJzcDsgSXMgdGhlIHByb3Bvc2VkIHNwZWNpZmljYXRp b24gZGVwbG95YWJsZT8mbmJzcDsgSWYgbm90LCBob3cgY291bGQ8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpdCBiZSBpbXByb3ZlZD88 YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhcyBFSUQgcHJlZml4ZXMgYXBw ZWFyIHRvIGJlIHVuZGVwbG95YWJsZSBmb3IgTW9iaWxpdHkgYW5kIFZNIE1vYmlsaXR5PGJyPg0K Jmd0OyB1c2FnZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWUgYWJvdmUgZXhhbXBsZS48YnI+DQom Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBbQl0gTElTUCBNdWx0aWNhc3QgdnMuIEVJRC9STE9DIHNl cGFyYXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSA2LiBNdWx0aWNh c3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIGludGVyZXN0 aW5nLCBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBsb29rIGxpa2UgdGhleSdyZSBhbiBleGNlcHRp b248YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGV5IGFyZSByZWFsbHkgbm90LiBTaW5jZSBtdWx0aWNh c3QgYWRkcmVzc2VzICppZGVudGlmeSogYSBncm91cCBvZjxicj4NCiZndDsgcmVjZWl2ZXJzLCBp dCBpcyB2ZXJ5IG11Y2ggYW4gRUlEIGFuZCBhaGVyZXMgdG8gdGhlIGRlZmluaXRpb24gb2YgYW4g RUlELjxicj4NCiZndDsgTXVsdGljYXN0IGFkZHJlc3NlcyBuZXZlciBoYWQgdG9wb2xvZ2ljYWwg c2lnbmZpY2FuY2UgYnV0IHRoZSBzdGF0ZTxicj4NCiZndDsgcmVwcmVzZW50aW5nIGEgZGlzdHJp YnV0aW9uIHRyZWUgZG9lcyB0ZWxsIHlvdSB3ZXJlIHRoZSBtZW1iZXJzIGFyZSAoYnV0IHRoZTxi cj4NCiZndDsgaWRlbnRpdHkgb2YgdGhlIG1lbWJlcnMgYXJlIG5vdCBrbm93IGluIG11bHRpY2Fz dCkuPGJyPg0KJmd0Ozxicj4NCiZndDsgU28gaXQgbWFrZXMgcGVyZmVjdCBzZW5zZSB0byByZWdp c3RlciBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIHRoZSBtYXBwaW5nPGJyPg0KJmd0OyBzeXN0ZW0g YXMgRUlEcyBhbmQgdGhleSBjYW4gbWFwIHRvIFJMT0NzIG9mIHNpdGVzIHRoYXQgaGF2ZSBqb2lu ZWQgdGhlIGdyb3VwLjxicj4NCiZndDsgU2VlIGRyYWZ0LWZhcmluYWNjaS1zaWduYWwtZnJlZS1t dWx0aWNhc3QgYXMganVzdCBvbmUgZXhhbXBsZS4gUkZDNjgzMSBhbmQ8YnI+DQomZ3Q7IGRyYWZ0 LWZhcmluYWNjaS1saXNwLW1yLXNpZ25hbGluZyBhcmUgb3RoZXIgZXhhbXBsZXMuPGJyPg0KJmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgdG8gdGhlIEVJRC9STE9DIHNlcGFyYXRpb24gYXMgdGhlIHNh bWUgZGVzdGluYXRpb24gSVAgbXVsdGljYXN0IGFkZHJlc3M8YnI+DQomZ3Q7ICZndDsmZ3Q7IGlz IHVzZWQgZm9yIGJvdGggcHVycG9zZXMuJm5ic3A7IFRoaXMgY291bGQgdXNlIHNvbWUgbW9yZSBk aXNjdXNzaW9uLCBhcyBpdCdzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1bmV4cGVjdGVkIGJhc2VkIG9u IHRoZSBjb250ZW50cyBvZiB0aGUgZHJhZnQgdXAgdG8gdGhpcyBwb2ludC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJIGJlbGlldmUgdGhlIGxldmVsIG9mIGRldGFpbCB3ZSBoYXZlIGluIHRoZSBpbnRy b2R1Y3Rpb24gZG9jdW1lbnQgaXMgYXQgdGhlPGJyPg0KJmd0OyByaWdodCBsZXZlbCBvciB3ZSds bCBlcnIgb24gaGF2aW5nIHdheSB0b28gbWFueSBkZXRhaWxzIGNyb3AgaW4uPGJyPg0KJmd0Ozxi cj4NCiZndDsgJmd0OyZndDsgLSA3LjIuJm5ic3A7IExJU1AgZm9yIElQdjYgQ28tZXhpc3RlbmNl PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IExJU1Ag ZW5jYXBzdWxhdGlvbnMgYWxsb3dzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIHVzaW5nIEVJRHMgZnJv bSBhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgZ2l2ZW4gYWRkcmVzcyBmYW1pbHkg KGUuZy4sIElQdjYpIHdpdGggcGFja2V0cyBmcm9tIG90aGVyIGFkZHJlc3M8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyBmYW1pbGllcyAoZS5nLiwgSVB2NCkuPGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSG93IGRvZXMgdGhhdCB3b3JrIGZvciBtdWx0aWNhc3Qg dHJhZmZpYywgd2hlcmUgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3M8YnI+DQomZ3Q7ICZndDsmZ3Q7 IChHKSBoYXMgdG8gYmUgdGhlIHNhbWUgaW4gYm90aCB0aGUgaW5uZXIgYW5kIG91dGVyIGhlYWRl cnM/Jm5ic3A7IEFyZSBFVFJzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhbmQgSVRScyBleHBlY3RlZCB0 byBtYXAgSVB2NiBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIElQdjQgYW5kIHYudi4/PGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhlIG1hcHBpbmcgc3lzdGVtIGNhbiBtYXAgYW4gKFMtRUlELWlwdjYsIGdy b3VwLWlwdjYpIDItdHVwbGUgdG8gYSBSTE9DIHNldDxicj4NCiZndDsgdGhhdCBsb29rZWQgbGlr ZSB0aGlzIChpcHY0LW11bHRpY2FzdCwgaXB2NC11bmljYXN0KSBtZWFuIHRoZSBJVFIgdGhhdDxi cj4NCiZndDsgcmVjZWl2ZXMgdGhlIHBhY2tldCBmcm9tIFMtRUlELWlwdjYgd291bGQgcmVwbGlj YXRlIHRoZSBwYWNrZXQgYW5kIG11bHRpY2FzdDxicj4NCiZndDsgZW5jYXBzdWxhdGUgdG8gaXB2 NC1tdWx0aWNhc3QgYW5kIHVuaWNhc3QgZW5jYXBzdWFsdGUgdG8gaXB2NC11bmljYXN0Ljxicj4N CiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gNy4zLiZuYnNwOyBMSVNQIGZvciBWaXJ0dWFsIFBy aXZhdGUgTmV0d29ya3M8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlz IGFsc28gaGFzIG11bHRpY2FzdCBwcm9ibGVtcywgYXMgdGhlcmUgaXMgb25seSBvbmUgaW5zdGFu Y2Ugb2YgZWFjaDxicj4NCiZndDsgJmd0OyZndDsgbXVsdGljYXN0IGFkZHJlc3MgKEcpIGluIHRo ZSB1bmRlcmxheSBuZXR3b3JrLiZuYnNwOyBJIHRoaW5rIEkgY2FuIGZpZ3VyZSBvdXQ8YnI+DQom Z3Q7IGhvdzxicj4NCiZndDs8YnI+DQomZ3Q7IFlvdSBjYW4gbWFwIGZyb20gRUlELUcgdG8gUkxP Qy1HIG9uZSB0byBvbmUuIEJ1dCB3ZSBoYXZlIHNlZW4gb3ZlciB0aGUgbGFzdDxicj4NCiZndDsg ZGVjYWRlIGluIGEgaGFsZiB0aGF0IHdpdGggZ2VuZXJhbCBtdWx0aWNhc3QgZGVwbG95bWVudCB0 aGF0IG1hbnktdG8tMSBpczxicj4NCiZndDsgZGVzaXJhYmxlLiBIZW5jZSwgbm93IHRoYXQgd2Ug aGF2ZSBhIHdheSB0byBtYXAgd2l0aCBhIG5ldHdvcmstYmFzZWQgZGF0YWJhc2UsPGJyPg0KJmd0 OyB3ZSBjYW4gbWFwIG11bHRpcGxlIEVJRC1HcyB0byBhIHNpbmdsZSAob3IgbXVsdGlwbGUpIFJM T0MtR3MuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgdG8gbWFrZSBtdWx0aWNhc3Qgd29y ayBmb3IgdGhpcyB1c2UgY2FzZSwgYnV0IGl0J3Mgbm90IGltbWVkaWF0ZWx5IG9idmlvdXMsPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBhbmQgdGhlIHJlc3VsdCB3aGVuIHRoZSBzYW1lIHVuZGVybGF5IG11 bHRpY2FzdCBhZGRyZXNzIGlzIHVzZWQgYnkgbW9yZTxicj4NCiZndDsgJmd0OyZndDsgdGhhbiBv bmUgVlBOIGNvdWxkIHdlbGwgZGVsaXZlciBzb21lIHRyYWZmaWMgdG8gRVRScyB0aGF0IGhhdmUg dG8gZGlzY2FyZDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgaXMgYSBuZWNlc3NhcnkgZXZpbCB3 aGVuIHRoZSB1bmRlcmxheSBpcyBzdGF0ZSBjaGFsbGVuZ2VkLiBCdXQgaXQgaXMgYTxicj4NCiZn dDsgc3RhdGUvYmFuZHdpZHRoIHRyYWRlb2ZmLiBXZSBoYXZlIGZvdW5kIHdpdGggTVZQTiBkZXBs b3ltZW50IHRoYXQgdGhlIG5ldHdvcms8YnI+DQomZ3Q7IGFkbWluIGNvbmZpZ3VyZXMgdGhlIHVu ZGVybHkgb3Igc2ltcGx5IHVuaWNhc3RzLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0 IGJlY2F1c2UgdGhlIEluc3RhbmNlIElEIGlzIHdyb25nIChhbmQgdGhhdCBleGNlc3NpdmUgZGVs aXZlcnkgaXMgYTxicj4NCiZndDsgJmd0OyZndDsgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiwgc2Vl IG1pbm9yIGlzc3VlIG9uIFNlY3Rpb24gOCBiZWxvdykuJm5ic3A7IEkgdGhpbmsgYW48YnI+DQom Z3Q7ICZndDsmZ3Q7IGV4cGxhbmF0aW9uIGlzIGluIG9yZGVyLjxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoZXJlIGFyZSBqdXN0IHRvbyBtYW55IGNvbWJpbmF0aW9ucyB0byBtYWtlIGEgaGlnaC1sZXZl bCBkZXNjcmlwdGlvbiBzaW1wbGU8YnI+DQomZ3Q7IHRvIHVuZGVyc3RhbmQuIFRoZSBjdXJyZW50 IGludHJvZHVjdGlvbiB0ZXh0IGRvZXMgYSBmaW5kIGpvYiBwcm92aWRpbmc8YnI+DQomZ3Q7IHJl ZmVyZW5jZXMgZm9yIHNvbWVvbmUgdG8gZ28gb2ZmIGFuZCBnZXQgdGhlIGRldGFpbHMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS0gTWlub3IgSXNzdWVzIC0tPGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhlcmUgc2VlbXMgdG8gYmUgYW4gaW1wbGljaXQgYXNz dW1wdGlvbiB0aGF0IHRoZSBlbmQgaG9zdCBhbmQgaXRzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJVFIg KHhUUikgYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBvciBBdXRvbm9tb3VzIFN5c3RlbS4mbmJzcDsg Rm9yIGluY3JlbWVudGFsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBpcyB0cnVlIHdoZW4geW91 IGNhbGwgdGhlIGRvbWFpbiBhICZxdW90O0xJU1Agc2l0ZSZxdW90Oy4gQnV0IGlmIHRoZSBzaXRl IGlzPGJyPg0KJmd0OyB1bmNoYW5nZWQgYW5kIG9uZSB1c2VzIFBJVFJzLCBtYXliZSBldmVuIGNs b3NlIHRvIHRoZSBzaXRlLCBsaWtlIGluIGEgUEU8YnI+DQomZ3Q7IHJvdXRlciwgdGhlbiB0aGUg UElUUiBpcyBkZWZpbml0ZWx5IGluIGFub3RoZXIgQVMuIEJ1dCBub3RlIEkgc2FpZCBQSVRSIGFu ZDxicj4NCiZndDsgbm90IElUUi4gVGhlIHJlYXNvbiBiZWluZyBpcyBiZWNhdXNlIGFuIElUUiBp cyBjb25maWd1cmVkIHdpdGggZGF0YWJhc2UtPGJyPg0KJmd0OyBtYXBwaW5nIHByZWZpeGVzIHRo YXQgaXMgdXNlcyB0byBlbmNhcHN1bGF0ZSBwYWNrZXRzIGZyb20gc3VjaCBhZGRyZXNzZXMuPGJy Pg0KJmd0OyBWZXJzdXMgdGhlIFBJVFIgYmVpbmcgYW4gSVRSIHdpdGggKm5vIGRhdGFiYXNlLW1h cHBpbmdzKiBwcm92aWRpbmcgYSBtdWNoIG1vcmU8YnI+DQomZ3Q7IGxhcmdlci9vciBtb3JlIGFn Z3JlZ3RhYmxlIHNlcnZpY2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgZGVwbG95bWVu dCwgSSBkb24ndCB0aGluayB0aGF0J3MgYWx3YXlzIHRoZSBjYXNlLCBidXQgSSB0aGluayB0aGF0 IG9ubHk8YnI+DQomZ3Q7ICZndDsmZ3Q7IGhhcyBlZGl0b3JpYWwgaW1wYWN0IG9uIHRoaXMgZG9j dW1lbnQsIGFzIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZTxicj4NCiZndDsgJmd0OyZndDsgZnVu ZGFtZW50YWwgTElTUCBtZWNoYW5pc21zIGFyZSBhZmZlY3RlZC4mbmJzcDsgVGhlIGF1dGhvcnMg c2hvdWxkIGxvb2sgZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1c2Ugb2YgJnF1b3Q7ZG9tYWluJnF1 b3Q7IGFuZCAmcXVvdDtBdXRvbm9tb3VzIFN5c3RlbSZxdW90OyBhbmQgZW5zdXJlIHRoYXQgdGhl IHRleHQgaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IGdlbmVyYWxpemVkIHRvIHRoZSBjYXNlIHdoZXJl IHRoZSBlbmQgaG9zdCBhbmQgSVRSIGFyZSBtb3JlIHdpZGVseTxicj4NCiZndDsgJmd0OyZndDsg c2VwYXJhdGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGFyZSBvdmVybG9hZGVkIHdpdGggdGVy bXMgdGhhdCBjcmVhdGUgdG9wb2xvZ2ljYWwgb3Igb3JnYW5pemF0aW9uIGJvdW5kYXJ5Ljxicj4N CiZndDsgSGVuY2Ugd2h5IHdlIGNyZWF0ZWQgJnF1b3Q7TElTUCBzaXRlJnF1b3Q7IHdoaWNoIGlz IGFsc28gdGhlIHNhbWUgYXMgYSAmcXVvdDtMSVNQIFZQTiBzaXRlJnF1b3Q7Ljxicj4NCiZndDsg V2hlcmUgYSAmcXVvdDtMSVNQIHNpdGUmcXVvdDsgdGhhdCBoYXMgbXVsdGlwbGUgdGVubmFudHMg d291bGQgYmUgbXVsdGlwbGUgJnF1b3Q7TElTUCBWUE48YnI+DQomZ3Q7IHNpdGVzJnF1b3Q7Ljxi cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IERlc3BpdGUgbXVsdGlwbGUmbmJzcDsgbWVudGlv bnMgb2YgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgSSBkaWQgbm90PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGF0IG1pZ2h0IGJlIGFjY29tcGxpc2hlZC4mbmJz cDsgVGhlcmUgaXMgc29tZTxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSBQeFRScyBhbmQg TkFUcy4gQW5kIHJlZmVyZW5jZXMgdG8gdGhlIExJU1AgaW50ZXJ3b3JraW5nIFJGQy48YnI+DQom Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1c2VmdWwgY29udGVudCBpbiBTZWN0aW9uIDMuNSwgYnV0 IHRoYXQncyBhdCBiZXN0IGFuIGluY29tcGxldGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGV4cGxhbmF0 aW9uLiZuYnNwOyBUaGlzIGlzIGFuIE9QUy1EaXIgcmV2aWV3IGNvbmNlcm4gLSBpdCBmYWxscyB1 bmRlcjxicj4NCiZndDsgJmd0OyZndDsgQS4xLjMgaW4gQXBwZW5kaXggQSBvZiBSRkMgNTcwNjog SGFzIHRoZSBtaWdyYXRpb24gcGF0aCBiZWVuIGRpc2N1c3NlZD88YnI+DQomZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtIDMuMy4xLiZuYnNwOyBMSVNQIEVuY2Fwc3VsYXRpb248YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhlIHNvdXJj ZSBwb3J0IGlzIHNlbGVjdGVkIGJ5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhl IElUUiBhbmQgaWdub3JlZCBvbiByZWNlcHRpb24uPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgUGxlYXNlIG1lbnRpb24gbXVsdGlwYXRoaW5nIChlLmcuLCBFQ01QIGFuZCBM QUcpIGFzIHBvc3NpYmxlIGluZmx1ZW5jZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9uIGhvdyBzb3Vy Y2UgcG9ydHMgYXJlIHNlbGVjdGVkLCBhcyB0aGlzIGltcG9zZXMgc29tZSBsaW1pdHMgb24gd2hh dCBhbjxicj4NCiZndDsgJmd0OyZndDsgSVRSIGNhbiByZWFzb25hYmx5IGRvLjxicj4NCiZndDs8 YnI+DQomZ3Q7IEVDTVAvTEFHIGRvbid0IGluZmx1ZW5jZSB3aGljaCBzb3VyY2UgcG9ydCBpcyBz ZWxlY3RlZC4gSXQgaXMgYSA1LXR1cGxlIGhhc2g8YnI+DQomZ3Q7IG9mIHRoZSBpbm5lciBoZWFk ZXIgdGhhdCBzZWxlY3RzIGEgc291cmNlIHBvcnQgdGhhdCBpbmZsdWVuY2VzIGhvdyBhbiB1bmRl cmxheTxicj4NCiZndDsgcm91dGVyIHdvdWxkIGxvYWQtc3BsaXQgdHJhZmZpYy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGb3IgT1BTLURpciwgdGhpcyBtdWx0aXBhdGhpbmcgY29uY2Vy biBmYWxscyB1bmRlciBBLjEuNCBpbiBBcHBlbmRpeCBBIG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBS RkMgNTcwNjogSGF2ZSB0aGUgUmVxdWlyZW1lbnRzIG9uIG90aGVyIHByb3RvY29scyBhbmQgZnVu Y3Rpb25hbDxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29t cG9uZW50cyBiZWVuIGRpc2N1c3NlZD88YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBkZWNpc2lvbiB3YXMgbWFkZSBiZWNhdXNlIHRoZTxicj4N CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHR5cGljYWwgdHJhbnNwb3J0IHByb3RvY29scyB1 c2VkIGJ5IHRoZSBhcHBsaWNhdGlvbnMgYWxyZWFkeSBpbmNsdWRlPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgYSBjaGVja3N1bSwgYnkgbmVnbGVjdGluZyB0aGUgYWRkaXRpb25hbCBV RFAgZW5jYXBzdWxhdGlvbiBjaGVja3N1bTxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7 IHhUUnMgY2FuIGZvcndhcmQgcGFja2V0cyBtb3JlIGVmZmljaWVudGx5Ljxicj4NCiZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEdyb2FuISZuYnNwOyBJIGhhdmUgYW4gZXhxdWlzaXRl IHNldCBvZiBzY2FycyBvbiBVRFAgemVybyBjaGVja3N1bXMgZm9yIElQdjY8YnI+DQomZ3Q7ICZn dDsmZ3Q7IGZyb20gd29ya2luZyBvbiB0aGUgTVBMUyBpbiBVRFAgZHJhZnQsIHNvIEkgbWF5IGJl IG92ZXJseSBzZW5zaXRpdmUgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoaXMgY29uY2Vybi4mbmJz cDsgVGhlIGRvd25zaWRlIG9mIHRoaXMgZWZmaWNpZW5jeSBpcyB0aGF0IHRoZXJlIGlzIG5vPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBjaGVja3N1bSBjb3ZlcmFnZSBvZiB0aGUgSVB2NiBoZWFkZXIgd2hl biB6ZXJvIFVEUCBjaGVja3N1bXMgYXJlIHVzZWQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGF0IHNo b3VsZCBhdCBsZWFzdCBiZSBtZW50aW9uZWQgaGVyZSwgd2l0aCBhIHN1bW1hcnkgb2Ygd2h5IHRo YXQncyBvazxicj4NCiZndDsgJmd0OyZndDsgLSB0aGUgZGV0YWlsZWQganVzdGlmaWNhdGlvbiBm b3Igd2h5IHRoYXQncyBvayBjYW4gYmUgbGVmdCB0byBvdGhlcjxicj4NCiZndDsgJmd0OyZndDsg ZG9jdW1lbnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE15IGhlYWQgc3BpbnMgZXZlcnkgdGltZSBJ IGhlYXIgYWJvdXQgdGhpcyBzdWJqZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW48YnI+DQomZ3Q7 IHRhbGtlZCBhYm91dCBmcm9tIDEwMHMgb2YgcGVvcGxlIGZvciBhIGRlY2FkZS4gV2UgaGF2ZSBD UkMgb24gbGlua3MsIHdlIGhhdmU8YnI+DQomZ3Q7IGFwcHMgdGhhdCB1c2UgVENQIGFuZCBVRFAg Y2hlY2tzdW1zLiBOdWYgc2FpZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgLS0gTml0cy9FZGl0b3JpYWwgQ29tbWVudHMgLS08YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtIFRvcCBvZiBwLjQ6PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IFRoZSBpbml0aWFsIG1vdGl2YXRpb24gaW4g dGhlIExJU1AgZWZmb3J0IGlzIHRvIGJlIGZpbmQgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsgJnF1b3Q7ZmluZCZxdW90OyAtJmd0OyAmcXVvdDtmb3VuZCZxdW90 Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gU2VjdGlvbiAzLjEsIGZp cnN0IGJ1bGxldCBpdGVtPGJyPg0KJmd0Ozxicj4NCiZndDsgV2Ugd2lsbCBjZXJ0YWlubHkgZml4 ZSB0aGVzZS4gVGhhbmtzLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RldmljZXMgYXJlIGFzc2lnbmVkIHdp dGggcmVsYXRpdmVseSBvcGFxdWUgaWRlbnRpdHk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7bWVhbmluZ2Z1bCBhZGRyZXNzZXMgdGhhdCBhcmUgaW5kZXBlbmRl bnQgb2YgdGhlaXIgdG9wb2xvZ2ljYWw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7bG9jYXRpb24uPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgSSBkb24ndCB1bmRlcnN0YW5kICZxdW90O3JlbGF0aXZlbHkgb3BhcXVlIGlkZW50aXR5IG1l YW5pbmdmdWwmcXVvdDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzdWdnZXN0IHJld3JpdGluZyB0 aGUgc2VudGVuY2UuJm5ic3A7IEluIHBhcnRpY3VsYXIgLSBvcGFxdWUgdG8gd2hhdD88YnI+DQom Z3Q7ICZndDsmZ3Q7IG1lYW5pbmdmdWwgdG8gd2hhdCBpbiB3aGF0IG1hbm5lcj88YnI+DQomZ3Q7 PGJyPg0KJmd0OyBXZWxsIGJlYWN1c2UgaXQgaXMgYXMgYWNjdXJhdGUgYXMgaXQgY2FuIGJlLiBJ ZiBhdXRvbW9iaWxlcyBhcmUgZ29pbmcgdG8gYmU8YnI+DQomZ3Q7IGFzc2lnbmVkIEVJRHMgZnJv bSBhIFZJTiBudW1iZXIgYWxsb2NhdGlvbiBmcm9tIGEgbWFudWZhY3R1cmUsIHRoZSBhZGRyZXNz IGlzPGJyPg0KJmd0OyByZWxhdGl2ZWx5IG9wYXF1ZS4gSWYgYSBWTSBpbiBhIGRhdGEtY2VudGVy IGlzIGdvaW5nIHRvIGJlIGFzc2lnbmVkIGFuIEVJRDxicj4NCiZndDsgZnJvbSB0aGUgc2V0IG9m IHByZWZpeGVzIGFscmVhZHkgYmVpbmcgdXNlZCBhbmQgYWxsb2NhdGVkIHRvIHRoYXQgZGF0YS1j ZW50ZXIsPGJyPg0KJmd0OyB0aGVuIHRoZXJlIGlzIGEgZ29vZCBjaGFuY2UgdGhhdCBhZGRyZXNz IGlzIGluIGEgcG93ZXItb2YtMiBibG9jayB0aGF0IGlzPGJyPg0KJmd0OyBzdW1tYXJpemFibGUg aW4gdGhlIElHUC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgLSBTZWN0aW9uIDMuMiwgc2Vjb25kIHBhcmFncmFwaDxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7IEp1ZGdpbmcgZnJvbSB0aGUgZmlndXJlLCB4VFJzIGFyZSB0aGUgY29t bW9uIGNhc2UsIHdpdGggc2luZ2xlLTxicj4NCiZndDsgJmd0OyZndDsgZnVuY3Rpb24gSVRScyBh bmQgRVRScyBiZWluZyByYXJlLiZuYnNwOyBJdCBtaWdodCBiZSBnb29kIHRvIHNheSB0aGF0PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBhbmQgZGlzY3VzcyB3aGVuIElUUnMgYW5kIEVUUnMgdGhhdCBhcmUg bm90IHhUUnMgYXJlIGFwcHJvcHJpYXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0byB1c2UuPGJyPg0K Jmd0Ozxicj4NCiZndDsgV2hlbiB5b3Ugd2FudCBlZ3Jlc3MgcGF0aCBzZWxlY3Rpb24gdG8gaGFw cGVuIGZ1cnRoZXIgb3V0IGluIHRoZSB0b3Bsb2dpY2FsPGJyPg0KJmd0OyBmcm9tIHRoZSBzb3Vy Y2UgbG9jYXRpb24sIHRoZW4geW91IHB1dCBhbiBJVFItb25seSBzeXN0ZW0gdGhlcmUuIFdoZXJl IGluZ3Jlc3M8YnI+DQomZ3Q7IHRvIHRoZSBzYW1lIHNvdXJjZSAoZGVzdGluYXRpb24gaW4gdGhp cyBkaXJlY3Rpb24pLCB0aGUgRVRSIGNhbiBiZSBjbG9zZXIgdG88YnI+DQomZ3Q7IHRoZSBkZXN0 aW5hdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsg LSAzcmQgcGFyYWdyYXBoIG9uIHAuNzo8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IEZpbmFsbHksIHRoZSBMSVNQIGFy Y2hpdGVjdHVyZSBlbXBoYXNpemVzIGEgY29zdCBlZmZlY3RpdmU8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBpbmNyZW1lbnRhbCBkZXBsb3ltZW50Ljxicj4NCiZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7IEknZCBkZWxldGUgJnF1b3Q7Y29zdCBlZmZlY3RpdmUmcXVvdDsg aGVyZSBhbmQgbG9vayBmb3Igb3RoZXIgb2NjdXJyZW5jZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9m ICZxdW90O2Nvc3QmcXVvdDsgYXMgY2FuZGlkYXRlcyBmb3IgZGVsZXRpb24uJm5ic3A7IFRoaXMg aXMgc3VwcG9zZWQgdG8gYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGEgdGVjaG5pY2FsIGRvY3VtZW50 LCBzbyBkaXNjdXNzaW9uIG9mIGNvc3RzIGlzIGEgYml0IG9mZi10YXJnZXQuPGJyPg0KJmd0Ozxi cj4NCiZndDsgRmFpciBlbm91Z2guPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSBGaXJz dCBpdGVtIGFmdGVyIEZpZ3VyZSAyOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAxLiZuYnNwOyBIb3N0QSByZXRyaWV2ZXMgdGhlIEVJRF9CIG9mIEhv c3RCLCB0eXBpY2FsbHkgcXVlcnlpbmcgdGhlIEROUzxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIG9idGFpbmluZyBhbmQgQSBvciBBQUFBIHJlY29yZC48 YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmcXVvdDthbmQgQSZxdW90OyAt Jmd0OyAmcXVvdDthbiBBJnF1b3Q7Jm5ic3A7IChzcGVsbGluZyBjaGVja2VycyBkb24ndCBjYXRj aCBldmVyeXRoaW5nKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbHJlYWR5IG5vdGVkIGFuZCB3aWxs IGJlIGZpeGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAtIDMuMy4xLiZuYnNwOyBMSVNQIEVuY2Fwc3VsYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIFJlY3Vyc2l2 ZTxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHR1bm5lbHMgYXJlIG5lc3RlZCB0dW5u ZWxzIGFuZCBhcmUgaW1wbGVtZW50ZWQgYnkgdXNpbmcgbXVsdGlwbGUgTElTUDxicj4NCiZndDsg Jmd0OyZndDsmbmJzcDsgJm5ic3A7IGVuY2Fwc3VsYXRpb25zIG9uIGEgcGFja2V0Ljxicj4NCiZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoZSBhYm92ZSBzZW50ZW5jZSBzZWVtcyBv dXQgb2YgcGxhY2UgaW4gdGhlIG1pZGRsZSBvZiBhIHBhcmFncmFwaCBhYm91dDxicj4NCiZndDsg Jmd0OyZndDsgUmUtZW5jYXBzdWxhdGluZyB0dW5uZWxzIGFuZCByb3V0ZXJzIC0gSSBzdWdnZXN0 IG1vdmluZyBpdCBkb3duIGludG8gaXRzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvd24gcGFyYWdyYXBo IGFuZCBwZXJoYXBzIGFkZGluZyBhIHNlbnRlbmNlIGFib3V0IHdoZXJlL2hvdyBSZWN1cnNpdmU8 YnI+DQomZ3Q7ICZndDsmZ3Q7IHR1bm5lbHMgbWF5IGJlIHVzZWZ1bC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBHb29kIHN1Z2dlc3Rpb24gYW5kIG1ha2VzIHNlbnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7IC0gMy4zLjIuJm5ic3A7IExJU1AgRm9yd2FyZGluZyBTdGF0ZTxicj4NCiZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBJbiB0aGUgTElTUCBhcmNo aXRlY3R1cmUsIElUUnMga2VlcCBqdXN0IGVub3VnaCBpbmZvcm1hdGlvbiB0byByb3V0ZTxicj4N CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHRyYWZmaWMgZmxvd2luZyB0aHJvdWdoIGl0Ljxi cj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZxdW90O2l0LiZxdW90OyAtJmd0 OyAmcXVvdDt0aGVtLiZxdW90Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBNZWFuaW5nIHRoYXQsIElUUnMgcmV0cmlldmUgZnJvbSB0aGU8YnI+DQom Z3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBMSVNQIE1hcHBpbmcgU3lzdGVtIG1hcHBpbmdzIGJl dHdlZW4gRUlEIHByZWZpeGVzIGFuZCBSTE9DcyB0aGF0IGFyZTxicj4NCiZndDsgJmd0OyZndDsm bmJzcDsgJm5ic3A7IHVzZWQgdG8gZW5jYXBzdWxhdGUgcGFja2V0cy48YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIHRoZSBmaXJzdCB1c2Ugb2YgdGhlIG5vdGlv biBvZiBFSUQgcHJlZml4ZXMuJm5ic3A7IFRoYXQgY29uY2VwdCBzaG91bGQ8YnI+DQomZ3Q7ICZn dDsmZ3Q7IGJlIGV4cGxhaW5lZCBiZWZvcmUgaXQgaXMgdXNlZCwgYWx0aG91Z2ggYSBmb3J3YXJk IHJlZmVyZW5jZSB0byBzZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAzLjQuMSBtYXkgc3VmZmlj ZS4mbmJzcDsgSXQgbWlnaHQgYmUgYmV0dGVyIHRvIHJld3JpdGUgdGhpcyBwYXJhZ3JhcGggaW4g dGVybXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9mIEVJRHMgYW5kIGxlYXZlIHRoZSBub3Rpb24gb2Yg RUlEIHByZWZpeGVzIHRvIHNlY3Rpb24gMy40LjEuPGJyPg0KJmd0Ozxicj4NCiZndDsgSG1tLCBJ J2xsIGxldCBBbGJlcnQgYW5kIERhbWllbiBkZWNpZGUgaWYgd2Ugc2hvdWxkIHN0YXRlICZxdW90 O0VJRC1wcmVmaXhlcyZxdW90Ozxicj4NCiZndDsgZXZlcnl3aGVyZSBpbnN0ZWFkIG9mIGp1c3Qg JnF1b3Q7RUlEJnF1b3Q7Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyAtIDQuNC4mbmJzcDsgTVRVIEhhbmRsaW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IEFkZGl0aW9uYWxseSwgTElTUCBhbHNvIHJlY29t bWVuZHMgaW5mZXJyaW5nIHJlYWNoYWJpbGl0eSBvZiBsb2NhdG9yczxicj4NCiZndDsgJmd0OyZn dDsmbmJzcDsgJm5ic3A7IGJ5IHVzaW5nIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSB1bmRl cmxheSwgaW4gcGFydGljdWxhcjo8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBJdCdkIGJlIHVzZWZ1bCB0byBhZGQgYSBzZW50ZW5jZSBvciB0d28gYWJvdXQgaG93IExJU1Ag YW5kIHRoZSB0ZWNobmlxdWVzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbiB0aGlzIHNlY3Rpb24gaW50 ZXJhY3Qgd2l0aCBob3N0IHVzZSBvZiBQTVRVRCBhbmQgUExQTVRVRC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaGlzIGlzIGEgbG90IG9mIGRldGFpbCBiZWNhdXNlIGluIFJGQzY4MzAgd2UgaGF2ZSAz IHBvc2l0aW9ucyBvciBvcHRpb25zIG9uPGJyPg0KJmd0OyB0aGUgc3ViamVjdC4gQW5kIHdlIGRp ZCBwcm92aWRlIGEgcmVmZXJlbmNlIHRvIFJGQzY4MzAgZm9yIHRoaXMgdG9waWMuPGJyPg0KJmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgLSBOZXh0IHRvIGxhc3QgcGFyYWdyYXBoIG9uIHAuMTc6PGJy Pg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IEFkZGl0aW9u YWxseSwgTElTUCBhbHNvIHJlY29tbWVuZHMgaW5mZXJyaW5nIHJlYWNoYWJpbGl0eSBvZiBsb2Nh dG9yczxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IGJ5IHVzaW5nIGluZm9ybWF0aW9u IHByb3ZpZGVkIGJ5IHRoZSB1bmRlcmxheSwgaW4gcGFydGljdWxhcjo8YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGxvb2tzIGxpa2UgaXQncyBhIHBhcmFncmFwaCBl YXJseSBhbmQgbmVlZHMgdG8gYmUgbW92ZWQgZG93biB0bzxicj4NCiZndDsgJmd0OyZndDsgYWZ0 ZXIgdGhlIHBhcmFncmFwaCB0aGF0IGZvbGxvd3MgaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWdy ZWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgaWRuaXRzIDIuMTMuMDEgZGlkbid0IGZp bmQgYW55IG5pdHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhhbmtz LDxicj4NCiZndDsgJmd0OyZndDsgLS1EYXZpZDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBh Z2FpbiBEYXZpZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBEaW5vPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949363640C1MX104CL02corpemcc_-- From nobody Wed Feb 11 16:19:12 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E851A874E; Wed, 11 Feb 2015 16:19:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoAFMOFC9-EB; Wed, 11 Feb 2015 16:18:57 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583151A874B; Wed, 11 Feb 2015 16:18:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F2503240171; Wed, 11 Feb 2015 16:18:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from localhost (mobile-166-171-056-075.mycingular.net [166.171.56.75]) by maila2.tigertech.net (Postfix) with ESMTPA id BD99F2400B5; Wed, 11 Feb 2015 16:18:53 -0800 (PST) Date: Wed, 11 Feb 2015 19:18:47 -0500 Message-ID: Importance: low From: "Jmh.direct" To: david.black@emc.com, acabello@ac.upc.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_125122668737117" Archived-At: Cc: ops-dir@ietf.org, lisp@ietf.org, damien.saucez@inria.fr, ietf@ietf.org Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 00:19:06 -0000 ----_com.android.email_125122668737117 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB0aGlubCB3ZSBtYXkgd2FudCB0byBzZXBhcmF0ZSBWTSBtb2JpbGl0eSBmcm9tIG1vYmlsZSBk ZXZpY2VzLiDCoE9tIHRoZSBWTSBjYXNlLCBhbSBlbnRpcmUgc2V0dmljZSBuZXR3b3JrIG1heSBi ZSBtb3ZlZCB0byB0aGUgZGF0YSBjZW50ZXIsIGFuZCBzbyB0aGUgRUlEIGJsb2NrIGZvciB0aGF0 IHNldCBjYW4gYmUgbW92ZWQuIMKgSW4gdGhlIGNhc2Ugb2YgaW5kaXZpZHVhbGx5IG1vYmlsZSBk ZWJpY2VzIG9yIHNvbWUgdmF0aWF0aW9ucyBvbiBkYXRhIGNlbnRlciBtb2JpbGl0eSwgdGhlcmUg aXMgYSBuZWVkIHRvIG1za2Ugc3VyZSB0aGUgZnVsbCBFSUQgaXMgYWR2ZXJ0aXNlZCBpbiB0aGUg bWFwcGluZyBzeXN0ZW0uCgpZb3VycywKSm9lbAoKClNlbnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0 cGhvbmUgb24gQVQmVAoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpTdWJqZWN0 OiBSRTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rp b24tMTEgCkZyb206ICJCbGFjaywgRGF2aWQiIDxkYXZpZC5ibGFja0BlbWMuY29tPiAKVG86ICJh Y2FiZWxsb0BhYy51cGMuZWR1IiA8YWNhYmVsbG9AYWMudXBjLmVkdT4gCkNDOiBEaW5vIEZhcmlu YWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4sIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFs cGVybi5jb20+LERhbWllbiBTYXVjZXogPGRhbWllbi5zYXVjZXpAaW5yaWEuZnI+LCJvcHMtZGly QGlldGYub3JnIiA8b3BzLWRpckBpZXRmLm9yZz4sImlldGZAaWV0Zi5vcmciIDxpZXRmQGlldGYu b3JnPiwibGlzcEBpZXRmLm9yZyIgPGxpc3BAaWV0Zi5vcmc+LCJCbGFjaywgRGF2aWQiIDxkYXZp ZC5ibGFja0BlbWMuY29tPiAKCkhpIEFsYmVydCwKCsKgCgpBcyBub3RlZCBiZWxvdywgb24gdGhl IEVJRCBwcmVmaXggZm9yIG1vYmlsaXR5IGlzc3VlLCBhIHNpbXBsZSBzdGF0ZW1lbnQgaW4gU2Vj dGlvbiA1IHRvIHRoZSBlZmZlY3QgdGhhdCDigJxpbiB0aGUgc3BlY2lmaWMgY2FzZSBvZiBhIFZN L21vYmlsZSBub2RlIHRoZSBFSUQtcHJlZml4IHNob3VsZCBiZSAvMzIgb3IgLzEyOCAoSVB2NCBv ciBJUHY2IHJlc3BlY3RpdmVseSnigJ0gd2lsbCBzdWZmaWNlLsKgIERldGFpbHMgb24gd2hhdCB0 byBkbyB3aGVuIHRoYXQgYWR2aWNlIGlzIGlnbm9yZWQgY2FuIGJlIGxlZnQgdG8gb3RoZXIgZG9j dW1lbnRzLgoKwqAKClRoYW5rcywKLS1EYXZpZAoKwqAKCkZyb206IEFsYmVydCBDYWJlbGxvcyBb bWFpbHRvOmFsYmVydC5jYWJlbGxvc0BnbWFpbC5jb21dIApTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDExLCAyMDE1IDY6MzMgUE0KVG86IEJsYWNrLCBEYXZpZApDYzogRGlubyBGYXJpbmFjY2k7 IEpvZWwgTS4gSGFscGVybjsgRGFtaWVuIFNhdWNlejsgb3BzLWRpckBpZXRmLm9yZzsgaWV0ZkBp ZXRmLm9yZzsgbGlzcEBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTEKCsKgCgpIaSBEYXZpZAoKwqAKClRo YW5rcyBmb3IgeW91ciBjb21tZW50cywgSSBhbSBwYXJzaW5nIHRoZW0gYW5kIEnCtGxsIHN1Z2dl c3QgbmV3IHRleHQgYWltaW5nIHRvIGFkZHJlc3MgdGhlbSBBU0FQLgoKwqAKCkkgd291bGQgYWxz byBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIFtBXSBiZWZvcmUgZG9pbmcgdGhpcy4KCsKgCgpX aXRoIExJU1AgYW4gRUlELXByZWlmeCBjYW4gaGF2ZSBhbiBhcmJpdHJhcnkgbGVuZ3RoIGFuZCBj YW4gbW92ZSAoaS5lLiwgY2hhbmdlIGl0cyBSTE9DIGJpbmRpbmdzKSwgaW4gdGhlIHNwZWNpZmlj IGNhc2Ugb2YgYSBWTS9tb2JpbGUgbm9kZSB0aGUgRUlELXByZWZpeCBzaG91bGQgYmUgLzMyIG9y IC8xMjggKElQdjQgb3IgSVB2NiByZXNwZWN0aXZlbHkpLiBXaGF0IGRvZXNuJ3Qgd29yayBpcyB0 aGUgbW9iaWxpdHkgb2YgYSBub2RlIChhc3NpZ25lZCB3aXRoIGEgLzMyIG9yIC8xMjgpICp3aXRo aW4qIGEgY29hcnNlciBFSUQtcHJlZml4LCBpbiB0aGlzIGNhc2UgeW91IG5lZWQgdG8gc3BsaXQg dGhlIHByZWZpeCBpbnRvIG1vcmUgc3BlY2lmaWNzIGFuZCByZWdpc3RlciB0aGVtIGluZGVwZW5k ZW50bHkgaW4gdGhlIE1hcHBpbmcgU3lzdGVtLCBlZmZlY3RpdmVseSBjcmVhdGluZyBuZXcgRUlE LXByZWZpeGVzLgoKwqAKClBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGlzIGNsYXJpZmllcyB5b3Vy IGNvbW1lbnQsIGluIHRoaXMgY2FzZSBJIHdpbGwgc3VnZ2VzdCBuZXcgdGV4dCBmb3IgU2VjdGlv biA1LgoKwqAKCkFsYmVydAoKwqAKCsKgCgrCoAoKT24gVGh1LCBGZWIgMTIsIDIwMTUgYXQgMTI6 MDcgQU0sIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6CgpEaW5vIC0g dGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuCgpPbiB0aGUgbWFqb3IgaXNzdWVzLCBpdCBsb29rcyBs aWtlIGJvdGggW0FdIGFuZCBbQl0gaW52b2x2ZSBvbmx5IHRoZSB0ZXh0CmluIHRoaXMgZHJhZnQg YW5kIG5vdGhpbmcgYmV5b25kLCB3aGljaCBpcyBnb29kIG5ld3MuwqAgSSBoYXZlIGEgc2ltcGxl IHRleHQKc3VnZ2VzdGlvbiBmb3IgW0FdLCBidXQgaXQgbG9va3MgbGlrZSBbQl0gaXMgZ29pbmcg dG8gcmVxdWlyZSBzb21lIGNhcmVmdWwKZWRpdGluZywgYXMgb25lIG9mIHRoZSBwcmltYXJ5IGNh dXNlcyBpcyB0aGF0IHRoZSBkcmFmdCBpcyBzbG9wcHkgaW4gdXNpbmcKdGhlIHNhbWUgc3ltYm9s ICJHIiB0byByZXByZXNlbnQgYm90aCBFSUQgYW5kIFJMT0MgbXVsdGljYXN0IGdyb3Vwcy4KCk9u IHRoZSBtaW5vciBpc3N1ZXMsIEkgaGF2ZSB0ZXh0IHN1Z2dlc3Rpb25zIGZvciB0aHJlZSBvZiB0 aGUgZm91ciwgYW5kCkknZCBsaWtlIHRvIHRlbXBvcmFyaWx5IGRlZmVyIGZ1cnRoZXIgZGlzY3Vz c2lvbiB0aGUgSVB2NiBVRFAgemVybwpjaGVja3N1bSAidGFycGl0IiBpbiBmYXZvciBvZiByZXNv bHZpbmcgZXZlcnl0aGluZyBlbHNlIGZpcnN0LgoKT24gdGhlIG5pdHMvZWRpdG9yaWFsIGNvbW1l bnRzLCBhbGwgdGhlIHN1Z2dlc3Rpb25zIGluIHlvdXIgZW1haWwgYXJlIGZpbmUKd2l0aCBtZS7C oCBGV0lXLCBJIHJlZ2FyZCB0aGF0IHBvcnRpb24gb2YgYSByZXZpZXcgYXMgYWxtb3N0IGVudGly ZWx5CnN1YmplY3QgdG8gdGhlIGRyYWZ0IGF1dGhvcnMnIGRpc2NyZXRpb24gKGFuZCBlZGl0b3Jp YWwgdGFzdGUpLgoKPiA+PiBbQV0gRUlEIG1vYmlsaXR5IHZzLiBFSUQgcHJlZml4ZXMKPgo+IC4u LiBmcm9tIHRoZSBzdGFydCBvZiB0aGUgTElTUCBkZXNpZ24gKGNpcmNhIDIwMDcpLCBhbiBwcmVm aXggaXMgd2hhdCBtb3Zlcy4KPiBBbmQgYSBzcGVjaWZpYyBFSUQgaXMgc2ltcGx5IGEgLzMyIG9y IC8xMjggcHJlZml4LiBIZXJlIGlzIGEgcHJhY3RpY2FsCj4gZXhhbXBsZToKCkEgc3RhdGVtZW50 IHRoYXQgdGhlIG1vYmlsaXR5IHVzZSBjYXNlcyBuZWVkIHRvIGVtcGxveSAvMzIgYW5kIC8xMjgg cHJlZml4ZXMsCmFuZCBub3QgYW55dGhpbmcgY29hcnNlciBzaG91bGQgc3VmZmljZS7CoCBUaGF0 IHNob3VsZCBiZSBhZGRlZCB0byBTZWN0aW9uIDUuCgo+ID4+IFtCXSBMSVNQIE11bHRpY2FzdCB2 cy4gRUlEL1JMT0Mgc2VwYXJhdGUKPiA+Pgo+ID4+IC0gNi4gTXVsdGljYXN0Cj4gPj4KPiA+PiBU aGlzIGlzIGludGVyZXN0aW5nLCBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBsb29rIGxpa2UgdGhl eSdyZSBhbiBleGNlcHRpb24KPgo+IFRoZXkgYXJlIHJlYWxseSBub3QuCgpNeSBjb25jZXJuIGlz IHRoYXQgYXMgSSByZWFkIHRoZSBkcmFmdCwgaXQgbGVhdmVzIG1lIHdpdGggdGhlIHN0cm9uZyBp bXByZXNzaW9uCnRoYXQgdGhlIHNhbWUgbXVsdGljYXN0IGFkZHJlc3NlcyAoRykgYXJlIGJlaW5n IHVzZWQgaW4gYm90aCB0aGUgb3ZlcmxheQooYXMgRUlEcykgYW5kIHRoZSB1bmRlcmxheSAoYXMg UkxPQ3MpLsKgIEZyb20geW91ciByZXNwb25zZSwgSSBjb25jbHVkZSB0aGF0IHRoaXMKaXMgbm90 IHRoZSBjYXNlIChhbmQgSSBoYXZlIG5vIGFyZ3VtZW50IHdpdGggdGhhdCkuwqAgUmF0aGVyLCBT ZWN0aW9uIDYgbmVlZHMgdG8KYmx1bnRseSBzdGF0ZSB0aGF0IG11bHRpY2FzdCBhZGRyZXNzZXMg YXJlIG1hcHBlZCBiZXR3ZWVuIEVJRCBhbmQgUkxPQyBzcGFjZSBhdApib3RoIElUUnMgYW5kIEVU UnMsIHNvIHRoYXQgdGhlIGZvbGxvd2luZyBpbmZlcmVuY2UgaXMgb2J2aW91cyBmcm9tIHRoZSB0 ZXh0CihpdCdzIGN1cnJlbnRseSBub3Qgb2J2aW91cyk6Cgo+IFNvIGl0IG1ha2VzIHBlcmZlY3Qg c2Vuc2UgdG8gcmVnaXN0ZXIgbXVsdGljYXN0IGFkZHJlc3NlcyB0byB0aGUgbWFwcGluZwo+IHN5 c3RlbSBhcyBFSURzIGFuZCB0aGV5IGNhbiBtYXAgdG8gUkxPQ3Mgb2Ygc2l0ZXMgdGhhdCBoYXZl IGpvaW5lZCB0aGUgZ3JvdXAuCgpBcyBwYXJ0IG9mIHRoaXMsIEkgc3Ryb25nbHkgcmVjb21tZW5k IG1vdmluZyBhd2F5IGZyb20gdXNlIG9mICJHIiB0byByZWZlciB0bwptdWx0aWNhc3QgZ3JvdXBz IGluIGJvdGggdGhlIG92ZXJsYXkgYW5kIHVuZGVybGF5LsKgIENhcmVmdWwgdXNlIG9mIEctRUlE CmFuZCBHLVJMT0Mgd291bGQgc2lnbmlmaWNhbnRseSBpbXByb3ZlIGNsYXJpdHkuCgotLS0KSWYg dGhlIGFib3ZlIGFyZSBkb25lIGZvciBbQV0gYW5kIFtCXSBpbiBTZWN0aW9ucyA1IGFuZCA2LCB0 aGVuIHRoZSB0ZXh0IGZvciB0aGUKdXNlIGNhc2VzIGluIFNlY3Rpb24gNyBzaG91bGQgbm90IG5l ZWQgZnVydGhlciBhdHRlbnRpb24uCi0tLQoKPiA+PiAtLSBNaW5vciBJc3N1ZXMgLS0KPiA+Pgo+ ID4+IFRoZXJlIHNlZW1zIHRvIGJlIGFuIGltcGxpY2l0IGFzc3VtcHRpb24gdGhhdCB0aGUgZW5k IGhvc3QgYW5kIGl0cwo+ID4+IElUUiAoeFRSKSBhcmUgaW4gdGhlIHNhbWUgZG9tYWluIG9yIEF1 dG9ub21vdXMgU3lzdGVtLsKgIEZvciBpbmNyZW1lbnRhbAo+Cj4gVGhpcyBpcyB0cnVlIHdoZW4g eW91IGNhbGwgdGhlIGRvbWFpbiBhICJMSVNQIHNpdGUiLiBCdXQgaWYgdGhlIHNpdGUgaXMKPiB1 bmNoYW5nZWQgYW5kIG9uZSB1c2VzIFBJVFJzLCBtYXliZSBldmVuIGNsb3NlIHRvIHRoZSBzaXRl LCBsaWtlIGluIGEgUEUKPiByb3V0ZXIsIHRoZW4gdGhlIFBJVFIgaXMgZGVmaW5pdGVseSBpbiBh bm90aGVyIEFTLgoKTG9va2luZyBhdCB0aGUgdGV4dCwgaXQgc2VlbXMgdGhhdCAiTElTUCBzaXRl IiBhbmQgImRvbWFpbiIgYXJlIHRoZSBzYW1lCmNvbmNlcHQgZm9yIHRoaXMgZHJhZnQuwqAgVGhh dCB3b3VsZCBiZSB1c2VmdWwgdG8gc3RhdGUsIElNSE8gYnV0IEknbGwgbGVhdmUKdGhlIGRlY2lz aW9uIG9uIHdoZXRoZXIgdG8gZG8gc28gdG8geW91IGFuZCB0aGUgZHJhZnQgYXV0aG9ycy4KCk9u IHJlcmVhZGluZywgbXkgY29uY2VybnMgc2VlbSB0byBiZSB0cmlnZ2VyZWQgbW9zdGx5IGJ5IHRo aXMgc2VudGVuY2UgaW4KU2VjdGlvbiAzLjI6CgrCoCDCoFRoZSBlZGdlIGNvbnNpc3RzIG9mIExJ U1Agc2l0ZXMgKGUuZy4sIGFuCsKgIMKgQXV0b25vbW91cyBTeXN0ZW0pIHRoYXQgdXNlIEVJRCBh ZGRyZXNzZXMuCgpJIHRoaW5rIGEgc21hbGwgY2hhbmdlIHRvIHRoZSBsYXN0IHNlbnRlbmNlIGlu IHRoYXQgcGFyYWdyYXBoIHdvdWxkIHJlc29sdmUKbXkgY29uY2VybiB3aXRob3V0IGRpc3RyYWN0 aW5nIGZyb20gdGhlIG5hcnJhdGl2ZToKCk9MRArCoCDCoEVJRHMgZG8gbm90CsKgIMKgY29udGFp biBpbnRlci1kb21haW4gdG9wb2xvZ2ljYWwgaW5mb3JtYXRpb24gYW5kIGJlY2F1c2Ugb2YgdGhp cywKwqAgwqBFSURzIGFyZSB1c3VhbGx5IHJvdXRhYmxlIGF0IHRoZSBlZGdlICh3aXRoaW4gTElT UCBzaXRlcykgb3IgaW4gdGhlCsKgIMKgbm9uLUxJU1AgSW50ZXJuZXQuCk5FVwrCoCDCoEVJRHMg ZG8gbm90CsKgIMKgY29udGFpbiBpbnRlci1kb21haW4gdG9wb2xvZ2ljYWwgaW5mb3JtYXRpb24g YW5kIGJlY2F1c2Ugb2YgdGhpcywKwqAgwqBFSURzIGFyZSB1c3VhbGx5IHJvdXRhYmxlIGF0IHRo ZSBlZGdlICh3aXRoaW4gTElTUCBzaXRlcykgb3IgaW4gdGhlCsKgIMKgbm9uLUxJU1AgSW50ZXJu ZXQ7IHNlZSBTZWN0aW9uIDMuNSBmb3IgZGlzY3Vzc2lvbiBvZiBMSVNQIHNpdGUKwqAgwqBpbnRl cm5ldHdvcmtpbmcgd2l0aCBub24tTElTUCBzaXRlcyBhbmQgZG9tYWlucyBpbiB0aGUgSW50ZXJu ZXQuCgo+ID4+IERlc3BpdGUgbXVsdGlwbGXCoCBtZW50aW9ucyBvZiBpbmNyZW1lbnRhbCBkZXBs b3ltZW50LCBJIGRpZCBub3QKPiA+PiBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGF0IG1pZ2h0 IGJlIGFjY29tcGxpc2hlZC4KPgo+IFRoZXJlIGFyZSBQeFRScyBhbmQgTkFUcy4gQW5kIHJlZmVy ZW5jZXMgdG8gdGhlIExJU1AgaW50ZXJ3b3JraW5nIFJGQy4KCk9rLCBjYW4gd2UganVzdCBzYXkg c28gaW4gU2VjdGlvbiAzLjU/wqAgQWRkaW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UKdG8gdGhl IGVuZCBvZiB0aGUgc2VjdGlvbiB3b3VsZCBzdWZmaWNlOgoKwqAgwqBQSVRScywgUEVUUnMgYW5k IExJU1AtTkFUIHN1cHBvcnQgaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiBMSVNQCsKgIMKgYnkg cHJvdmlkaW5nIHNpZ25pZmljYW50IGZsZXhpYmlsaXR5IGluIGxvY2F0aW9uIG9mIHRoZSBib3Vu ZGFyaWVzCsKgIMKgYmV0d2VlbiB0aGUgTElTUCBhbmQgbm9uLUxJU1AgcG9ydGlvbnMgb2YgdGhl IG5ldHdvcmssIGFuZCBtYWtpbmcKwqAgwqBpdCByZWFzb25hYmxlIHRvIGNoYW5nZSB0aG9zZSBi b3VuZGFyaWVzIG92ZXIgdGltZS4KCj4gPj4gLSAzLjMuMS7CoCBMSVNQIEVuY2Fwc3VsYXRpb24K PiA+Pgo+ID4+wqAgwqAgdGhlIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkIGJ5Cj4gPj7CoCDCoCB0 aGUgSVRSIGFuZCBpZ25vcmVkIG9uIHJlY2VwdGlvbi4KPiA+Pgo+ID4+IFBsZWFzZSBtZW50aW9u IG11bHRpcGF0aGluZyAoZS5nLiwgRUNNUCBhbmQgTEFHKSBhcyBwb3NzaWJsZSBpbmZsdWVuY2Vz Cj4gPj4gb24gaG93IHNvdXJjZSBwb3J0cyBhcmUgc2VsZWN0ZWQsIGFzIHRoaXMgaW1wb3NlcyBz b21lIGxpbWl0cyBvbiB3aGF0IGFuCj4gPj4gSVRSIGNhbiByZWFzb25hYmx5IGRvLgo+Cj4gRUNN UC9MQUcgZG9uJ3QgaW5mbHVlbmNlIHdoaWNoIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkLiBJdCBp cyBhIDUtdHVwbGUgaGFzaAo+IG9mIHRoZSBpbm5lciBoZWFkZXIgdGhhdCBzZWxlY3RzIGEgc291 cmNlIHBvcnQgdGhhdCBpbmZsdWVuY2VzIGhvdyBhbiB1bmRlcmxheQo+IHJvdXRlciB3b3VsZCBs b2FkLXNwbGl0IHRyYWZmaWMuCgpQbGVhc2Ugc3RhdGUgdGhhdCBhIDUtdHVwbGUgaGFzaCBpcyB1 c2VkLsKgIEVDTVAvTEFHIGlzIGFtb25nIHRoZSBpbXBvcnRhbnQKcmVhc29ucyB3aHksIGJ1dCB0 aGF0IGRvZXNuJ3QgbmVlZCB0byBiZSBzdGF0ZWQgaWYgeW91IHByZWZlciBub3QgdG8uwqAgQW4K ZXhhbXBsZSBvZiBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBleGNsdWRlZCBpcyB0aGF0IHVz aW5nIGEgcmFuZG9tCm51bWJlciBnZW5lcmF0b3IgdG8gc2V0IHRoZSBzb3VyY2UgcG9ydCB3b3Vs ZCBiZSB3cm9uZyAtIEkgY291bGQgc3VnZ2VzdApjaXRpbmcgZHJhZnQtaWV0Zi1kYXJ0LWRzY3At cnRwIGZvciByZWxhdGVkIGRpc2N1c3Npb24gKGFuZCBsb3RzIG1vcmUKZGV0YWlscyksIGJ1dCBJ IGRvbid0IHRoaW5rIHRoYXQncyBuZWNlc3NhcnkuCgotLSBJUHY2IHplcm8gVURQIGNoZWNrc3Vt Cgo+IE15IGhlYWQgc3BpbnMgZXZlcnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBzdWJqZWN0LiBU aGlzIHN1YmplY3QgaGFzIGJlZW4KPiB0YWxrZWQgYWJvdXQgZnJvbSAxMDBzIG9mIHBlb3BsZSBm b3IgYSBkZWNhZGUuIFdlIGhhdmUgQ1JDIG9uIGxpbmtzLCB3ZSBoYXZlCj4gYXBwcyB0aGF0IHVz ZSBUQ1AgYW5kIFVEUCBjaGVja3N1bXMuIE51ZiBzYWlkLgoKVW5kZXJzdG9vZCAtIHRoZXJlJ3Mg bW9yZSB0aGFuIG9uZSBzZXQgb2Ygc2NhcnMgb24gdGhpcyBvbmUgOi0oLsKgIExldCdzIGNvbWUg YmFjawp0byB0aGlzIHRvcGljIGFmdGVyIHdlJ3ZlIHJlc29sdmVkIGV2ZXJ5dGhpbmcgZWxzZSwg YW5kIHBsZWFzZSBrZWVwIGluIG1pbmQKdGhhdCBJIHRhZ2dlZCB0aGlzIGFzIGEgbWlub3IgaXNz dWUsIG5vdCBhIG1ham9yIG9uZSAoZS5nLiwgdGhlIGFib3ZlIGNoYW5nZXMKZm9yIFtBXSBhbmQg W0JdIGFyZSBmYXIgbW9yZSBpbXBvcnRhbnQsIElNSE8pLgoKVGhhbmtzLAotLURhdmlkCgo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogRGlubyBGYXJpbmFjY2kgW21haWx0bzpm YXJpbmFjY2lAZ21haWwuY29tXQo+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMTUg MjoxOSBQTQo+IFRvOiBKb2VsIE0uIEhhbHBlcm4KPiBDYzogQmxhY2ssIERhdmlkOyBBbGJlcnQg Q2FiZWxsb3M7IERhbWllbiBTYXVjZXo7IG9wcy1kaXJAaWV0Zi5vcmc7Cj4gaWV0ZkBpZXRmLm9y ZzsgbGlzcEBpZXRmLm9yZwo+IFN1YmplY3Q6IFJlOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMQo+Cgo+ID4gSSB3aWxsIGxlYXZlIG1vc3Qg b2YgdGhlc2UgZm9yIHRoZSBhdXRob3JzIHRvIGNvbW1lbnQgb24uCj4KPiBTZWUgbXkgY29tbWVu dHMgaW5saW5lLiBUaGFua3MgRGF2aWQgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3IGFuZCBjb21t ZW50YXJ5Lgo+Cj4gPiBXaXRoIHJlZ2FyZCB0byB5b3VyIHF1ZXN0aW9uIGFib3V0IGluY3JlbWVu dGFsIGRlcGxveW1lbnQsIHRoYXQgaXMgdGhlCj4gZG9tYWluIG9mIHRoZSBMSVNQIERlcGxveW1l bnQgZG9jdW1lbnQsIGFuZCB3YXMgZGVsaWJlcmF0ZWx5IG9ubHkgbGlnaHRseQo+IGNvdmVyZWQg aGVyZS7CoCBJIGFtIG5vdCBzdXJlIHdoYXQgd2UgY2FuIGRvIHRvIGFkZHJlc3MgeW91ciBjb21t ZW50IHdpdGhvdXQKPiBkdXBsaWNhdGluZyB0aGUgZW50aXJldHkgb2YgdGhhdCBkb2N1bWVudC4K Pgo+IFRoYXQgaXMgdGhlIHJpc2sgd2UgbWF5IGhhdmUgd2l0aCBtYW55IG9mIHlvdXIgY29tbWVu dHMuIFdlIGhhdmUgYSBsb3Qgb2YKPiBkZXRhaWwgaW4gdGhlIGFscmVhZHkgOSBwdWJsaXNoZWQg UkZDc8KgIGFuZCB0aGlzIGRvY3VtZW50IHJlYWxseSBpcyB0byB0YWtlCj4gYWxsIHRoYXQgZGV0 YWlsIGFuZCBzdW1tYXJpemUgYXMgYW4gZWFzaWx5IHVuZGVyc3RhbmRhYmxlIGRlc2NyaXB0aW9u IG9mIGEKPiBjb2hlc2l2ZSBkZXNpZ24uCj4KPiA+IFdpdGggcmVnYXJkIHRvIFVEUCBaZXJvLCB0 aGlzIHdhcyBhcHByb3ZlZCBieSB0aGUgSUVTRyBhbmQgcHVibGlzaGVkIGFzIGFuCj4gUkZDLsKg IEl0IGlzIHBhcnQgb2YgdGhlIHdheSB0aGUgcHJvdG9jb2wgaXMgZGVmaW5lZC7CoCBJZiB0aGVy ZSBhcmUgc3BlY2lmaWMKPiBjaGFuZ2VzIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBpbiB0aGUgZXhw bGFuYXRvcnkgdGV4dCwgSSBhbSBzdXJlCj4KPiBEZWZpbml0ZWx5IGFncmVlZC4gSW4gZmFjdCB3 ZSBpbnN0aWdhdGVkIFVEUCB6ZXJvLiBBbmQgSSBjb250aW51YWxseSB0YWxrIHRvCj4gaGFyZHdh cmUgZW5naW5lZXJzIGFuZCB0aGV5IGFsbCBiZWxpZXZlIHdlIG1hZGUgdGhlIHJpZ2h0IGRlY2lz aW9uLiBTbyBoYXRzCj4gb2ZmIHRvIHRoZSBJRVRGIGZvciBiZWluZyBwcmFjdGljYWwuCj4KPiA+ IHdlIGNvdWxkIGluY2x1ZGUgdGhlbS7CoCBJZiB5b3UgYXJlIGxvb2tpbmcgZm9yIGEgY2hhbmdl IGluIHRoZSBiZWhhdmlvciwKPiB0aGlzIGRvY3VtZW50IGNhbiBub3QgbWFrZSBjaGFuZ2VzIHRv IHRoZSBMSVNQIGJlaGF2aW9yLgo+Cj4gWWVzLCBhbiBpbXBvcnRhbnQgcG9pbnQuCj4KPiA+PiBJ IGZvdW5kIGEgY291cGxlIG9mIG1ham9yIGlzc3VlcyB0aGF0IEkgaG9wZSBhcmlzZSBmcm9tIHRo ZQo+ID4+IHN1bW1hcml6YXRpb24gb2YgTElTUCBpbiB0aGlzIGRyYWZ0LCBhcyBvcHBvc2VkIHRv IGJlaW5nIHByb2JsZW1zIGluCj4gPj4gdGhlIGFjdHVhbCBMSVNQIHByb3RvY29scy7CoCBJIGFs c28gZm91bmQgYSBmZXcgbWlub3IgaXNzdWVzLCB0aGUgbW9zdAo+ID4+IGltcG9ydGFudCBvZiB3 aGljaCBpcyB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucwo+ ID4+IGRpc2N1c3Npb24gb24gbWlzZGVsaXZlcnksIHdpdGggcGFydGljdWxhciBhdHRlbnRpb24g dG8gVlBOcy4KPgo+IFRoYW5rcyBhIHRvbi4KPgo+ID4+IC0tIE1ham9yIGlzc3VlcyAtLQo+ID4+ Cj4gPj4gW0FdIEVJRCBtb2JpbGl0eSB2cy4gRUlEIHByZWZpeGVzCj4gPj4KPiA+PiAtIDUuIE1v YmlsaXR5Cj4gPj4KPiA+PiBJIHVuZGVyc3RhbmQgaG93IHRoaXMgd29ya3Mgd2hlbiBtYXBwaW5n IGlzIHBlci1FSUQsIGJ1dCBob3cgZG9lcyB0aGlzIHdvcmsKPiA+PiB3aGVuIHRoZSBFSUQgb2Yg dGhlIHN5c3RlbSB0aGF0IG1vdmVzIGlzIHBhcnQgb2YgYW4gRUlEIHByZWZpeCwgYXMKPiBkaXNj dXNzZWQKPiA+PiBpbiBTZWN0aW9uIDMuNC4xP8KgIEV2ZW4gaWYgdGhlIGFuc3dlciBpcyBhIGxv bmcgdmVyc2lvbiBvZiAiRG9uJ3QgZG8gdGhhdCEiCj4gPj4gaXQgc2hvdWxkIGJlIGV4cGxhaW5l ZC4KPgo+IE5vLCBmcm9tIHRoZSBzdGFydCBvZiB0aGUgTElTUCBkZXNpZ24gKGNpcmNhIDIwMDcp LCBhbiBwcmVmaXggaXMgd2hhdCBtb3Zlcy4KPiBBbmQgYSBzcGVjaWZpYyBFSUQgaXMgc2ltcGx5 IGEgLzMyIG9yIC8xMjggcHJlZml4LiBIZXJlIGlzIGEgcHJhY3RpY2FsCj4gZXhhbXBsZToKPgo+ IFlvdSBoYXZlIGEgY2x1c3RlciBvZiBzZXJ2ZXJzIHRoYXQgY29tbXVuaWNhdGUgdG9nZXRoZXIg Zm9yIGEgcGFydGljdWxhcgo+IGFwcGxpY2F0aW9uLiBUaGV5IGFwcGxpY2F0aW9uIGNsdXN0ZXIg aXMgcnVubmluZyBpbiBhIHNldCBvZiBWTXMuIFRob3NlIFZNcwo+IGFyZSBhc3NpZ25lZCBFSURz IGZyb20gYSBjb21tb24gcG93ZXItb2YtMiBFSUQtcHJlZml4LiBUaG9zZSBWTXMgYXJlIGN1cnJl bnRseQo+IHJ1bm5pbmcgaW4gYSBicmljay1hbmQtbW9ydGFyIGRhdGEgY2VudGVyLiBOb3cgdGhl cmUgaXMgYSBkZXNpcmUgdG8gbW92ZSB0aGUKPiBWTSBjbHVzdGVyIHRvIGEgY2xvdWQgcHJvdmlk ZXIuIFdoYXQgaXMgbW92ZWQgaXMgdGhlIEVJRC1wcmVmaXggb2YgdGhlCj4gY2x1c3Rlci4gVGhl IG1hcHBpbmcgc3lzdGVtIGlzIHRvbGQgdGhhdCB0aGUgRUlELXByZWZpeCBpcyBjaGFuZ2luZyBp dHMgUkxPQy0KPiBzZXQgZnJvbSB0aGUgYnJpY2stYW5kLW1vcnRhciB4VFJzIHRvIHRoZSBjbG91 ZCBwcm92aWRlcnMgeFRScy4KPgo+ID4+Cj4gPj4gLSA3LjQuwqAgTElTUCBmb3IgVmlydHVhbCBN YWNoaW5lIE1vYmlsaXR5IGluIERhdGEgQ2VudGVycwo+ID4+Cj4gPj4gSSBkb24ndCB1bmRlcnN0 YW5kIGhvdyB0aGlzIHdvcmtzIHdoZW4gRUlEIHByZWZpeGVzIGFyZSB1c2VkLCBhcyBlYWNoIFZN Cj4gPj4gaGFzIGl0cyBvd24gRUlEIG9yIEVJRHMsIGhlbmNlIHRoZSBlbnRpcmUgcHJlZml4IHJh bmdlIGRvZXMgbm90IG1vdmUgd2hlbgo+ID4+IHRoZSBWTSBtb3Zlcy4KPiA+Pgo+ID4+IEZvciBP UFMtRGlyLCB0aGlzIEVJRCBwcmVmaXggaXNzdWUgW0FdIGZhbGxzIHVuZGVyIEEuMS4xIGluIEFw cGVuZGl4IEEKPiA+PiBvZiBSRkMgNTcwNjrCoCBIYXMgZGVwbG95bWVudCBiZWVuIGRpc2N1c3Nl ZD8gYW5kIHNwZWNpZmljYWxseSB1bmRlcjoKPiA+Pgo+ID4+wqAgwqAgwqAgwqAgKsKgIElzIHRo ZSBwcm9wb3NlZCBzcGVjaWZpY2F0aW9uIGRlcGxveWFibGU/wqAgSWYgbm90LCBob3cgY291bGQK PiA+PsKgIMKgIMKgIMKgIMKgIMKgaXQgYmUgaW1wcm92ZWQ/Cj4gPj4KPiA+PiBhcyBFSUQgcHJl Zml4ZXMgYXBwZWFyIHRvIGJlIHVuZGVwbG95YWJsZSBmb3IgTW9iaWxpdHkgYW5kIFZNIE1vYmls aXR5Cj4gdXNhZ2UuCj4KPiBTZWUgYWJvdmUgZXhhbXBsZS4KPgo+ID4+IFtCXSBMSVNQIE11bHRp Y2FzdCB2cy4gRUlEL1JMT0Mgc2VwYXJhdGUKPiA+Pgo+ID4+IC0gNi4gTXVsdGljYXN0Cj4gPj4K PiA+PiBUaGlzIGlzIGludGVyZXN0aW5nLCBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBsb29rIGxp a2UgdGhleSdyZSBhbiBleGNlcHRpb24KPgo+IFRoZXkgYXJlIHJlYWxseSBub3QuIFNpbmNlIG11 bHRpY2FzdCBhZGRyZXNzZXMgKmlkZW50aWZ5KiBhIGdyb3VwIG9mCj4gcmVjZWl2ZXJzLCBpdCBp cyB2ZXJ5IG11Y2ggYW4gRUlEIGFuZCBhaGVyZXMgdG8gdGhlIGRlZmluaXRpb24gb2YgYW4gRUlE Lgo+IE11bHRpY2FzdCBhZGRyZXNzZXMgbmV2ZXIgaGFkIHRvcG9sb2dpY2FsIHNpZ25maWNhbmNl IGJ1dCB0aGUgc3RhdGUKPiByZXByZXNlbnRpbmcgYSBkaXN0cmlidXRpb24gdHJlZSBkb2VzIHRl bGwgeW91IHdlcmUgdGhlIG1lbWJlcnMgYXJlIChidXQgdGhlCj4gaWRlbnRpdHkgb2YgdGhlIG1l bWJlcnMgYXJlIG5vdCBrbm93IGluIG11bHRpY2FzdCkuCj4KPiBTbyBpdCBtYWtlcyBwZXJmZWN0 IHNlbnNlIHRvIHJlZ2lzdGVyIG11bHRpY2FzdCBhZGRyZXNzZXMgdG8gdGhlIG1hcHBpbmcKPiBz eXN0ZW0gYXMgRUlEcyBhbmQgdGhleSBjYW4gbWFwIHRvIFJMT0NzIG9mIHNpdGVzIHRoYXQgaGF2 ZSBqb2luZWQgdGhlIGdyb3VwLgo+IFNlZSBkcmFmdC1mYXJpbmFjY2ktc2lnbmFsLWZyZWUtbXVs dGljYXN0IGFzIGp1c3Qgb25lIGV4YW1wbGUuIFJGQzY4MzEgYW5kCj4gZHJhZnQtZmFyaW5hY2Np LWxpc3AtbXItc2lnbmFsaW5nIGFyZSBvdGhlciBleGFtcGxlcy4KPgo+ID4+IHRvIHRoZSBFSUQv UkxPQyBzZXBhcmF0aW9uIGFzIHRoZSBzYW1lIGRlc3RpbmF0aW9uIElQIG11bHRpY2FzdCBhZGRy ZXNzCj4gPj4gaXMgdXNlZCBmb3IgYm90aCBwdXJwb3Nlcy7CoCBUaGlzIGNvdWxkIHVzZSBzb21l IG1vcmUgZGlzY3Vzc2lvbiwgYXMgaXQncwo+ID4+IHVuZXhwZWN0ZWQgYmFzZWQgb24gdGhlIGNv bnRlbnRzIG9mIHRoZSBkcmFmdCB1cCB0byB0aGlzIHBvaW50Lgo+Cj4gSSBiZWxpZXZlIHRoZSBs ZXZlbCBvZiBkZXRhaWwgd2UgaGF2ZSBpbiB0aGUgaW50cm9kdWN0aW9uIGRvY3VtZW50IGlzIGF0 IHRoZQo+IHJpZ2h0IGxldmVsIG9yIHdlJ2xsIGVyciBvbiBoYXZpbmcgd2F5IHRvbyBtYW55IGRl dGFpbHMgY3JvcCBpbi4KPgo+ID4+IC0gNy4yLsKgIExJU1AgZm9yIElQdjYgQ28tZXhpc3RlbmNl Cj4gPj4KPiA+PsKgIMKgIExJU1AgZW5jYXBzdWxhdGlvbnMgYWxsb3dzIHRvIHRyYW5zcG9ydCBw YWNrZXRzIHVzaW5nIEVJRHMgZnJvbSBhCj4gPj7CoCDCoCBnaXZlbiBhZGRyZXNzIGZhbWlseSAo ZS5nLiwgSVB2Nikgd2l0aCBwYWNrZXRzIGZyb20gb3RoZXIgYWRkcmVzcwo+ID4+wqAgwqAgZmFt aWxpZXMgKGUuZy4sIElQdjQpLgo+ID4+Cj4gPj4gSG93IGRvZXMgdGhhdCB3b3JrIGZvciBtdWx0 aWNhc3QgdHJhZmZpYywgd2hlcmUgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MKPiA+PiAoRykgaGFz IHRvIGJlIHRoZSBzYW1lIGluIGJvdGggdGhlIGlubmVyIGFuZCBvdXRlciBoZWFkZXJzP8KgIEFy ZSBFVFJzCj4gPj4gYW5kIElUUnMgZXhwZWN0ZWQgdG8gbWFwIElQdjYgbXVsdGljYXN0IGFkZHJl c3NlcyB0byBJUHY0IGFuZCB2LnYuPwo+Cj4gVGhlIG1hcHBpbmcgc3lzdGVtIGNhbiBtYXAgYW4g KFMtRUlELWlwdjYsIGdyb3VwLWlwdjYpIDItdHVwbGUgdG8gYSBSTE9DIHNldAo+IHRoYXQgbG9v a2VkIGxpa2UgdGhpcyAoaXB2NC1tdWx0aWNhc3QsIGlwdjQtdW5pY2FzdCkgbWVhbiB0aGUgSVRS IHRoYXQKPiByZWNlaXZlcyB0aGUgcGFja2V0IGZyb20gUy1FSUQtaXB2NiB3b3VsZCByZXBsaWNh dGUgdGhlIHBhY2tldCBhbmQgbXVsdGljYXN0Cj4gZW5jYXBzdWxhdGUgdG8gaXB2NC1tdWx0aWNh c3QgYW5kIHVuaWNhc3QgZW5jYXBzdWFsdGUgdG8gaXB2NC11bmljYXN0Lgo+Cj4gPj4gLSA3LjMu wqAgTElTUCBmb3IgVmlydHVhbCBQcml2YXRlIE5ldHdvcmtzCj4gPj4KPiA+PiBUaGlzIGFsc28g aGFzIG11bHRpY2FzdCBwcm9ibGVtcywgYXMgdGhlcmUgaXMgb25seSBvbmUgaW5zdGFuY2Ugb2Yg ZWFjaAo+ID4+IG11bHRpY2FzdCBhZGRyZXNzIChHKSBpbiB0aGUgdW5kZXJsYXkgbmV0d29yay7C oCBJIHRoaW5rIEkgY2FuIGZpZ3VyZSBvdXQKPiBob3cKPgo+IFlvdSBjYW4gbWFwIGZyb20gRUlE LUcgdG8gUkxPQy1HIG9uZSB0byBvbmUuIEJ1dCB3ZSBoYXZlIHNlZW4gb3ZlciB0aGUgbGFzdAo+ IGRlY2FkZSBpbiBhIGhhbGYgdGhhdCB3aXRoIGdlbmVyYWwgbXVsdGljYXN0IGRlcGxveW1lbnQg dGhhdCBtYW55LXRvLTEgaXMKPiBkZXNpcmFibGUuIEhlbmNlLCBub3cgdGhhdCB3ZSBoYXZlIGEg d2F5IHRvIG1hcCB3aXRoIGEgbmV0d29yay1iYXNlZCBkYXRhYmFzZSwKPiB3ZSBjYW4gbWFwIG11 bHRpcGxlIEVJRC1HcyB0byBhIHNpbmdsZSAob3IgbXVsdGlwbGUpIFJMT0MtR3MuCj4KPiA+PiB0 byBtYWtlIG11bHRpY2FzdCB3b3JrIGZvciB0aGlzIHVzZSBjYXNlLCBidXQgaXQncyBub3QgaW1t ZWRpYXRlbHkgb2J2aW91cywKPiA+PiBhbmQgdGhlIHJlc3VsdCB3aGVuIHRoZSBzYW1lIHVuZGVy bGF5IG11bHRpY2FzdCBhZGRyZXNzIGlzIHVzZWQgYnkgbW9yZQo+ID4+IHRoYW4gb25lIFZQTiBj b3VsZCB3ZWxsIGRlbGl2ZXIgc29tZSB0cmFmZmljIHRvIEVUUnMgdGhhdCBoYXZlIHRvIGRpc2Nh cmQKPgo+IFRoaXMgaXMgYSBuZWNlc3NhcnkgZXZpbCB3aGVuIHRoZSB1bmRlcmxheSBpcyBzdGF0 ZSBjaGFsbGVuZ2VkLiBCdXQgaXQgaXMgYQo+IHN0YXRlL2JhbmR3aWR0aCB0cmFkZW9mZi4gV2Ug aGF2ZSBmb3VuZCB3aXRoIE1WUE4gZGVwbG95bWVudCB0aGF0IHRoZSBuZXR3b3JrCj4gYWRtaW4g Y29uZmlndXJlcyB0aGUgdW5kZXJseSBvciBzaW1wbHkgdW5pY2FzdHMuCj4KPiA+PiBpdCBiZWNh dXNlIHRoZSBJbnN0YW5jZSBJRCBpcyB3cm9uZyAoYW5kIHRoYXQgZXhjZXNzaXZlIGRlbGl2ZXJ5 IGlzIGEKPiA+PiBzZWN1cml0eSBjb25zaWRlcmF0aW9uLCBzZWUgbWlub3IgaXNzdWUgb24gU2Vj dGlvbiA4IGJlbG93KS7CoCBJIHRoaW5rIGFuCj4gPj4gZXhwbGFuYXRpb24gaXMgaW4gb3JkZXIu Cj4KPiBUaGVyZSBhcmUganVzdCB0b28gbWFueSBjb21iaW5hdGlvbnMgdG8gbWFrZSBhIGhpZ2gt bGV2ZWwgZGVzY3JpcHRpb24gc2ltcGxlCj4gdG8gdW5kZXJzdGFuZC4gVGhlIGN1cnJlbnQgaW50 cm9kdWN0aW9uIHRleHQgZG9lcyBhIGZpbmQgam9iIHByb3ZpZGluZwo+IHJlZmVyZW5jZXMgZm9y IHNvbWVvbmUgdG8gZ28gb2ZmIGFuZCBnZXQgdGhlIGRldGFpbHMuCj4KPiA+PiAtLSBNaW5vciBJ c3N1ZXMgLS0KPiA+Pgo+ID4+IFRoZXJlIHNlZW1zIHRvIGJlIGFuIGltcGxpY2l0IGFzc3VtcHRp b24gdGhhdCB0aGUgZW5kIGhvc3QgYW5kIGl0cwo+ID4+IElUUiAoeFRSKSBhcmUgaW4gdGhlIHNh bWUgZG9tYWluIG9yIEF1dG9ub21vdXMgU3lzdGVtLsKgIEZvciBpbmNyZW1lbnRhbAo+Cj4gVGhp cyBpcyB0cnVlIHdoZW4geW91IGNhbGwgdGhlIGRvbWFpbiBhICJMSVNQIHNpdGUiLiBCdXQgaWYg dGhlIHNpdGUgaXMKPiB1bmNoYW5nZWQgYW5kIG9uZSB1c2VzIFBJVFJzLCBtYXliZSBldmVuIGNs b3NlIHRvIHRoZSBzaXRlLCBsaWtlIGluIGEgUEUKPiByb3V0ZXIsIHRoZW4gdGhlIFBJVFIgaXMg ZGVmaW5pdGVseSBpbiBhbm90aGVyIEFTLiBCdXQgbm90ZSBJIHNhaWQgUElUUiBhbmQKPiBub3Qg SVRSLiBUaGUgcmVhc29uIGJlaW5nIGlzIGJlY2F1c2UgYW4gSVRSIGlzIGNvbmZpZ3VyZWQgd2l0 aCBkYXRhYmFzZS0KPiBtYXBwaW5nIHByZWZpeGVzIHRoYXQgaXMgdXNlcyB0byBlbmNhcHN1bGF0 ZSBwYWNrZXRzIGZyb20gc3VjaCBhZGRyZXNzZXMuCj4gVmVyc3VzIHRoZSBQSVRSIGJlaW5nIGFu IElUUiB3aXRoICpubyBkYXRhYmFzZS1tYXBwaW5ncyogcHJvdmlkaW5nIGEgbXVjaCBtb3JlCj4g bGFyZ2VyL29yIG1vcmUgYWdncmVndGFibGUgc2VydmljZS4KPgo+ID4+IGRlcGxveW1lbnQsIEkg ZG9uJ3QgdGhpbmsgdGhhdCdzIGFsd2F5cyB0aGUgY2FzZSwgYnV0IEkgdGhpbmsgdGhhdCBvbmx5 Cj4gPj4gaGFzIGVkaXRvcmlhbCBpbXBhY3Qgb24gdGhpcyBkb2N1bWVudCwgYXMgSSBkb24ndCB0 aGluayBhbnkgb2YgdGhlCj4gPj4gZnVuZGFtZW50YWwgTElTUCBtZWNoYW5pc21zIGFyZSBhZmZl Y3RlZC7CoCBUaGUgYXV0aG9ycyBzaG91bGQgbG9vayBmb3IKPiA+PiB1c2Ugb2YgImRvbWFpbiIg YW5kICJBdXRvbm9tb3VzIFN5c3RlbSIgYW5kIGVuc3VyZSB0aGF0IHRoZSB0ZXh0IGlzCj4gPj4g Z2VuZXJhbGl6ZWQgdG8gdGhlIGNhc2Ugd2hlcmUgdGhlIGVuZCBob3N0IGFuZCBJVFIgYXJlIG1v cmUgd2lkZWx5Cj4gPj4gc2VwYXJhdGVkLgo+Cj4gV2UgYXJlIG92ZXJsb2FkZWQgd2l0aCB0ZXJt cyB0aGF0IGNyZWF0ZSB0b3BvbG9naWNhbCBvciBvcmdhbml6YXRpb24gYm91bmRhcnkuCj4gSGVu Y2Ugd2h5IHdlIGNyZWF0ZWQgIkxJU1Agc2l0ZSIgd2hpY2ggaXMgYWxzbyB0aGUgc2FtZSBhcyBh ICJMSVNQIFZQTiBzaXRlIi4KPiBXaGVyZSBhICJMSVNQIHNpdGUiIHRoYXQgaGFzIG11bHRpcGxl IHRlbm5hbnRzIHdvdWxkIGJlIG11bHRpcGxlICJMSVNQIFZQTgo+IHNpdGVzIi4KPgo+ID4+IERl c3BpdGUgbXVsdGlwbGXCoCBtZW50aW9ucyBvZiBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LCBJIGRp ZCBub3QKPiA+PiBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGF0IG1pZ2h0IGJlIGFjY29tcGxp c2hlZC7CoCBUaGVyZSBpcyBzb21lCj4KPiBUaGVyZSBhcmUgUHhUUnMgYW5kIE5BVHMuIEFuZCBy ZWZlcmVuY2VzIHRvIHRoZSBMSVNQIGludGVyd29ya2luZyBSRkMuCj4KPiA+PiB1c2VmdWwgY29u dGVudCBpbiBTZWN0aW9uIDMuNSwgYnV0IHRoYXQncyBhdCBiZXN0IGFuIGluY29tcGxldGUKPiA+ PiBleHBsYW5hdGlvbi7CoCBUaGlzIGlzIGFuIE9QUy1EaXIgcmV2aWV3IGNvbmNlcm4gLSBpdCBm YWxscyB1bmRlcgo+ID4+IEEuMS4zIGluIEFwcGVuZGl4IEEgb2YgUkZDIDU3MDY6IEhhcyB0aGUg bWlncmF0aW9uIHBhdGggYmVlbiBkaXNjdXNzZWQ/Cj4gPj4KPiA+PiAtIDMuMy4xLsKgIExJU1Ag RW5jYXBzdWxhdGlvbgo+ID4+Cj4gPj7CoCDCoCB0aGUgc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQg YnkKPiA+PsKgIMKgIHRoZSBJVFIgYW5kIGlnbm9yZWQgb24gcmVjZXB0aW9uLgo+ID4+Cj4gPj4g UGxlYXNlIG1lbnRpb24gbXVsdGlwYXRoaW5nIChlLmcuLCBFQ01QIGFuZCBMQUcpIGFzIHBvc3Np YmxlIGluZmx1ZW5jZXMKPiA+PiBvbiBob3cgc291cmNlIHBvcnRzIGFyZSBzZWxlY3RlZCwgYXMg dGhpcyBpbXBvc2VzIHNvbWUgbGltaXRzIG9uIHdoYXQgYW4KPiA+PiBJVFIgY2FuIHJlYXNvbmFi bHkgZG8uCj4KPiBFQ01QL0xBRyBkb24ndCBpbmZsdWVuY2Ugd2hpY2ggc291cmNlIHBvcnQgaXMg c2VsZWN0ZWQuIEl0IGlzIGEgNS10dXBsZSBoYXNoCj4gb2YgdGhlIGlubmVyIGhlYWRlciB0aGF0 IHNlbGVjdHMgYSBzb3VyY2UgcG9ydCB0aGF0IGluZmx1ZW5jZXMgaG93IGFuIHVuZGVybGF5Cj4g cm91dGVyIHdvdWxkIGxvYWQtc3BsaXQgdHJhZmZpYy4KPgo+ID4+IEZvciBPUFMtRGlyLCB0aGlz IG11bHRpcGF0aGluZyBjb25jZXJuIGZhbGxzIHVuZGVyIEEuMS40IGluIEFwcGVuZGl4IEEgb2YK PiA+PiBSRkMgNTcwNjogSGF2ZSB0aGUgUmVxdWlyZW1lbnRzIG9uIG90aGVyIHByb3RvY29scyBh bmQgZnVuY3Rpb25hbAo+ID4+wqAgwqAgwqAgwqAgY29tcG9uZW50cyBiZWVuIGRpc2N1c3NlZD8K PiA+Pgo+ID4+wqAgwqAgVGhpcyBkZWNpc2lvbiB3YXMgbWFkZSBiZWNhdXNlIHRoZQo+ID4+wqAg wqAgdHlwaWNhbCB0cmFuc3BvcnQgcHJvdG9jb2xzIHVzZWQgYnkgdGhlIGFwcGxpY2F0aW9ucyBh bHJlYWR5IGluY2x1ZGUKPiA+PsKgIMKgIGEgY2hlY2tzdW0sIGJ5IG5lZ2xlY3RpbmcgdGhlIGFk ZGl0aW9uYWwgVURQIGVuY2Fwc3VsYXRpb24gY2hlY2tzdW0KPiA+PsKgIMKgIHhUUnMgY2FuIGZv cndhcmQgcGFja2V0cyBtb3JlIGVmZmljaWVudGx5Lgo+ID4+Cj4gPj4gR3JvYW4hwqAgSSBoYXZl IGFuIGV4cXVpc2l0ZSBzZXQgb2Ygc2NhcnMgb24gVURQIHplcm8gY2hlY2tzdW1zIGZvciBJUHY2 Cj4gPj4gZnJvbSB3b3JraW5nIG9uIHRoZSBNUExTIGluIFVEUCBkcmFmdCwgc28gSSBtYXkgYmUg b3Zlcmx5IHNlbnNpdGl2ZSB0bwo+ID4+IHRoaXMgY29uY2Vybi7CoCBUaGUgZG93bnNpZGUgb2Yg dGhpcyBlZmZpY2llbmN5IGlzIHRoYXQgdGhlcmUgaXMgbm8KPiA+PiBjaGVja3N1bSBjb3ZlcmFn ZSBvZiB0aGUgSVB2NiBoZWFkZXIgd2hlbiB6ZXJvIFVEUCBjaGVja3N1bXMgYXJlIHVzZWQuCj4g Pj4gVGhhdCBzaG91bGQgYXQgbGVhc3QgYmUgbWVudGlvbmVkIGhlcmUsIHdpdGggYSBzdW1tYXJ5 IG9mIHdoeSB0aGF0J3Mgb2sKPiA+PiAtIHRoZSBkZXRhaWxlZCBqdXN0aWZpY2F0aW9uIGZvciB3 aHkgdGhhdCdzIG9rIGNhbiBiZSBsZWZ0IHRvIG90aGVyCj4gPj4gZG9jdW1lbnRzLgo+Cj4gTXkg aGVhZCBzcGlucyBldmVyeSB0aW1lIEkgaGVhciBhYm91dCB0aGlzIHN1YmplY3QuIFRoaXMgc3Vi amVjdCBoYXMgYmVlbgo+IHRhbGtlZCBhYm91dCBmcm9tIDEwMHMgb2YgcGVvcGxlIGZvciBhIGRl Y2FkZS4gV2UgaGF2ZSBDUkMgb24gbGlua3MsIHdlIGhhdmUKPiBhcHBzIHRoYXQgdXNlIFRDUCBh bmQgVURQIGNoZWNrc3Vtcy4gTnVmIHNhaWQuCj4KPiA+Pgo+ID4+IC0tIE5pdHMvRWRpdG9yaWFs IENvbW1lbnRzIC0tCj4gPj4KPiA+PiAtIFRvcCBvZiBwLjQ6Cj4gPj4KPiA+PsKgIMKgIFRoZSBp bml0aWFsIG1vdGl2YXRpb24gaW4gdGhlIExJU1AgZWZmb3J0IGlzIHRvIGJlIGZpbmQgaW4gdGhl Cj4gPj4KPiA+PiAiZmluZCIgLT4gImZvdW5kIgo+ID4+Cj4gPj4gLSBTZWN0aW9uIDMuMSwgZmly c3QgYnVsbGV0IGl0ZW0KPgo+IFdlIHdpbGwgY2VydGFpbmx5IGZpeGUgdGhlc2UuIFRoYW5rcy4K Pgo+ID4+Cj4gPj7CoCDCoCDCoCDCoERldmljZXMgYXJlIGFzc2lnbmVkIHdpdGggcmVsYXRpdmVs eSBvcGFxdWUgaWRlbnRpdHkKPiA+PsKgIMKgIMKgIMKgbWVhbmluZ2Z1bCBhZGRyZXNzZXMgdGhh dCBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlaXIgdG9wb2xvZ2ljYWwKPiA+PsKgIMKgIMKgIMKgbG9j YXRpb24uCj4gPj4KPiA+PiBJIGRvbid0IHVuZGVyc3RhbmQgInJlbGF0aXZlbHkgb3BhcXVlIGlk ZW50aXR5IG1lYW5pbmdmdWwiIGFuZAo+ID4+IHN1Z2dlc3QgcmV3cml0aW5nIHRoZSBzZW50ZW5j ZS7CoCBJbiBwYXJ0aWN1bGFyIC0gb3BhcXVlIHRvIHdoYXQ/Cj4gPj4gbWVhbmluZ2Z1bCB0byB3 aGF0IGluIHdoYXQgbWFubmVyPwo+Cj4gV2VsbCBiZWFjdXNlIGl0IGlzIGFzIGFjY3VyYXRlIGFz IGl0IGNhbiBiZS4gSWYgYXV0b21vYmlsZXMgYXJlIGdvaW5nIHRvIGJlCj4gYXNzaWduZWQgRUlE cyBmcm9tIGEgVklOIG51bWJlciBhbGxvY2F0aW9uIGZyb20gYSBtYW51ZmFjdHVyZSwgdGhlIGFk ZHJlc3MgaXMKPiByZWxhdGl2ZWx5IG9wYXF1ZS4gSWYgYSBWTSBpbiBhIGRhdGEtY2VudGVyIGlz IGdvaW5nIHRvIGJlIGFzc2lnbmVkIGFuIEVJRAo+IGZyb20gdGhlIHNldCBvZiBwcmVmaXhlcyBh bHJlYWR5IGJlaW5nIHVzZWQgYW5kIGFsbG9jYXRlZCB0byB0aGF0IGRhdGEtY2VudGVyLAo+IHRo ZW4gdGhlcmUgaXMgYSBnb29kIGNoYW5jZSB0aGF0IGFkZHJlc3MgaXMgaW4gYSBwb3dlci1vZi0y IGJsb2NrIHRoYXQgaXMKPiBzdW1tYXJpemFibGUgaW4gdGhlIElHUC4KPgo+ID4+Cj4gPj4gLSBT ZWN0aW9uIDMuMiwgc2Vjb25kIHBhcmFncmFwaAo+ID4+Cj4gPj4gSnVkZ2luZyBmcm9tIHRoZSBm aWd1cmUsIHhUUnMgYXJlIHRoZSBjb21tb24gY2FzZSwgd2l0aCBzaW5nbGUtCj4gPj4gZnVuY3Rp b24gSVRScyBhbmQgRVRScyBiZWluZyByYXJlLsKgIEl0IG1pZ2h0IGJlIGdvb2QgdG8gc2F5IHRo YXQKPiA+PiBhbmQgZGlzY3VzcyB3aGVuIElUUnMgYW5kIEVUUnMgdGhhdCBhcmUgbm90IHhUUnMg YXJlIGFwcHJvcHJpYXRlCj4gPj4gdG8gdXNlLgo+Cj4gV2hlbiB5b3Ugd2FudCBlZ3Jlc3MgcGF0 aCBzZWxlY3Rpb24gdG8gaGFwcGVuIGZ1cnRoZXIgb3V0IGluIHRoZSB0b3Bsb2dpY2FsCj4gZnJv bSB0aGUgc291cmNlIGxvY2F0aW9uLCB0aGVuIHlvdSBwdXQgYW4gSVRSLW9ubHkgc3lzdGVtIHRo ZXJlLiBXaGVyZSBpbmdyZXNzCj4gdG8gdGhlIHNhbWUgc291cmNlIChkZXN0aW5hdGlvbiBpbiB0 aGlzIGRpcmVjdGlvbiksIHRoZSBFVFIgY2FuIGJlIGNsb3NlciB0bwo+IHRoZSBkZXN0aW5hdGlv bi4KPgo+ID4+Cj4gPj4gLSAzcmQgcGFyYWdyYXBoIG9uIHAuNzoKPiA+Pgo+ID4+Cj4gPj7CoCDC oCBGaW5hbGx5LCB0aGUgTElTUCBhcmNoaXRlY3R1cmUgZW1waGFzaXplcyBhIGNvc3QgZWZmZWN0 aXZlCj4gPj7CoCDCoCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50Lgo+ID4+Cj4gPj4gSSdkIGRlbGV0 ZSAiY29zdCBlZmZlY3RpdmUiIGhlcmUgYW5kIGxvb2sgZm9yIG90aGVyIG9jY3VycmVuY2VzCj4g Pj4gb2YgImNvc3QiIGFzIGNhbmRpZGF0ZXMgZm9yIGRlbGV0aW9uLsKgIFRoaXMgaXMgc3VwcG9z ZWQgdG8gYmUKPiA+PiBhIHRlY2huaWNhbCBkb2N1bWVudCwgc28gZGlzY3Vzc2lvbiBvZiBjb3N0 cyBpcyBhIGJpdCBvZmYtdGFyZ2V0Lgo+Cj4gRmFpciBlbm91Z2guCj4KPiA+PiAtIEZpcnN0IGl0 ZW0gYWZ0ZXIgRmlndXJlIDI6Cj4gPj4KPiA+PsKgIMKgIDEuwqAgSG9zdEEgcmV0cmlldmVzIHRo ZSBFSURfQiBvZiBIb3N0QiwgdHlwaWNhbGx5IHF1ZXJ5aW5nIHRoZSBETlMKPiA+PsKgIMKgIMKg IMKgIGFuZCBvYnRhaW5pbmcgYW5kIEEgb3IgQUFBQSByZWNvcmQuCj4gPj4KPiA+PiAiYW5kIEEi IC0+ICJhbiBBIsKgIChzcGVsbGluZyBjaGVja2VycyBkb24ndCBjYXRjaCBldmVyeXRoaW5nKS4K Pgo+IEFscmVhZHkgbm90ZWQgYW5kIHdpbGwgYmUgZml4ZWQuCj4KPiA+Pgo+ID4+IC0gMy4zLjEu wqAgTElTUCBFbmNhcHN1bGF0aW9uCj4gPj4KPiA+PsKgIMKgIE9uIHRoZSBvdGhlciBoYW5kLCBS ZWN1cnNpdmUKPiA+PsKgIMKgIHR1bm5lbHMgYXJlIG5lc3RlZCB0dW5uZWxzIGFuZCBhcmUgaW1w bGVtZW50ZWQgYnkgdXNpbmcgbXVsdGlwbGUgTElTUAo+ID4+wqAgwqAgZW5jYXBzdWxhdGlvbnMg b24gYSBwYWNrZXQuCj4gPj4KPiA+PiBUaGUgYWJvdmUgc2VudGVuY2Ugc2VlbXMgb3V0IG9mIHBs YWNlIGluIHRoZSBtaWRkbGUgb2YgYSBwYXJhZ3JhcGggYWJvdXQKPiA+PiBSZS1lbmNhcHN1bGF0 aW5nIHR1bm5lbHMgYW5kIHJvdXRlcnMgLSBJIHN1Z2dlc3QgbW92aW5nIGl0IGRvd24gaW50byBp dHMKPiA+PiBvd24gcGFyYWdyYXBoIGFuZCBwZXJoYXBzIGFkZGluZyBhIHNlbnRlbmNlIGFib3V0 IHdoZXJlL2hvdyBSZWN1cnNpdmUKPiA+PiB0dW5uZWxzIG1heSBiZSB1c2VmdWwuCj4KPiBHb29k IHN1Z2dlc3Rpb24gYW5kIG1ha2VzIHNlbnNlLgo+Cj4gPj4gLSAzLjMuMi7CoCBMSVNQIEZvcndh cmRpbmcgU3RhdGUKPiA+Pgo+ID4+wqAgwqAgSW4gdGhlIExJU1AgYXJjaGl0ZWN0dXJlLCBJVFJz IGtlZXAganVzdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gcm91dGUKPiA+PsKgIMKgIHRyYWZmaWMg Zmxvd2luZyB0aHJvdWdoIGl0Lgo+ID4+Cj4gPj4gIml0LiIgLT4gInRoZW0uIgo+ID4+Cj4gPj7C oCDCoCBNZWFuaW5nIHRoYXQsIElUUnMgcmV0cmlldmUgZnJvbSB0aGUKPiA+PsKgIMKgIExJU1Ag TWFwcGluZyBTeXN0ZW0gbWFwcGluZ3MgYmV0d2VlbiBFSUQgcHJlZml4ZXMgYW5kIFJMT0NzIHRo YXQgYXJlCj4gPj7CoCDCoCB1c2VkIHRvIGVuY2Fwc3VsYXRlIHBhY2tldHMuCj4gPj4KPiA+PiBU aGlzIGlzIHRoZSBmaXJzdCB1c2Ugb2YgdGhlIG5vdGlvbiBvZiBFSUQgcHJlZml4ZXMuwqAgVGhh dCBjb25jZXB0IHNob3VsZAo+ID4+IGJlIGV4cGxhaW5lZCBiZWZvcmUgaXQgaXMgdXNlZCwgYWx0 aG91Z2ggYSBmb3J3YXJkIHJlZmVyZW5jZSB0byBzZWN0aW9uCj4gPj4gMy40LjEgbWF5IHN1ZmZp Y2UuwqAgSXQgbWlnaHQgYmUgYmV0dGVyIHRvIHJld3JpdGUgdGhpcyBwYXJhZ3JhcGggaW4gdGVy bXMKPiA+PiBvZiBFSURzIGFuZCBsZWF2ZSB0aGUgbm90aW9uIG9mIEVJRCBwcmVmaXhlcyB0byBz ZWN0aW9uIDMuNC4xLgo+Cj4gSG1tLCBJJ2xsIGxldCBBbGJlcnQgYW5kIERhbWllbiBkZWNpZGUg aWYgd2Ugc2hvdWxkIHN0YXRlICJFSUQtcHJlZml4ZXMiCj4gZXZlcnl3aGVyZSBpbnN0ZWFkIG9m IGp1c3QgIkVJRCIuCj4KPiA+Pgo+ID4+IC0gNC40LsKgIE1UVSBIYW5kbGluZwo+ID4+Cj4gPj7C oCDCoCBBZGRpdGlvbmFsbHksIExJU1AgYWxzbyByZWNvbW1lbmRzIGluZmVycmluZyByZWFjaGFi aWxpdHkgb2YgbG9jYXRvcnMKPiA+PsKgIMKgIGJ5IHVzaW5nIGluZm9ybWF0aW9uIHByb3ZpZGVk IGJ5IHRoZSB1bmRlcmxheSwgaW4gcGFydGljdWxhcjoKPiA+Pgo+ID4+IEl0J2QgYmUgdXNlZnVs IHRvIGFkZCBhIHNlbnRlbmNlIG9yIHR3byBhYm91dCBob3cgTElTUCBhbmQgdGhlIHRlY2huaXF1 ZXMKPiA+PiBpbiB0aGlzIHNlY3Rpb24gaW50ZXJhY3Qgd2l0aCBob3N0IHVzZSBvZiBQTVRVRCBh bmQgUExQTVRVRC4KPgo+IFRoaXMgaXMgYSBsb3Qgb2YgZGV0YWlsIGJlY2F1c2UgaW4gUkZDNjgz MCB3ZSBoYXZlIDMgcG9zaXRpb25zIG9yIG9wdGlvbnMgb24KPiB0aGUgc3ViamVjdC4gQW5kIHdl IGRpZCBwcm92aWRlIGEgcmVmZXJlbmNlIHRvIFJGQzY4MzAgZm9yIHRoaXMgdG9waWMuCj4KPiA+ PiAtIE5leHQgdG8gbGFzdCBwYXJhZ3JhcGggb24gcC4xNzoKPiA+Pgo+ID4+wqAgwqAgQWRkaXRp b25hbGx5LCBMSVNQIGFsc28gcmVjb21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmlsaXR5IG9mIGxv Y2F0b3JzCj4gPj7CoCDCoCBieSB1c2luZyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgdW5k ZXJsYXksIGluIHBhcnRpY3VsYXI6Cj4gPj4KPiA+PiBUaGlzIGxvb2tzIGxpa2UgaXQncyBhIHBh cmFncmFwaCBlYXJseSBhbmQgbmVlZHMgdG8gYmUgbW92ZWQgZG93biB0bwo+ID4+IGFmdGVyIHRo ZSBwYXJhZ3JhcGggdGhhdCBmb2xsb3dzIGl0Lgo+Cj4gQWdyZWUuCj4KPiA+PiBpZG5pdHMgMi4x My4wMSBkaWRuJ3QgZmluZCBhbnkgbml0cy4KPiA+Pgo+ID4+IFRoYW5rcywKPiA+PiAtLURhdmlk Cj4KPiBUaGFua3MgYWdhaW4gRGF2aWQuCj4KPiBEaW5vCgrCoA== ----_com.android.email_125122668737117 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5JIHRoaW5sIHdlIG1heSB3YW50IHRv IHNlcGFyYXRlIFZNIG1vYmlsaXR5IGZyb20gbW9iaWxlIGRldmljZXMuICZuYnNwO09tIHRoZSBW TSBjYXNlLCBhbSBlbnRpcmUgc2V0dmljZSBuZXR3b3JrIG1heSBiZSBtb3ZlZCB0byB0aGUgZGF0 YSBjZW50ZXIsIGFuZCBzbyB0aGUgRUlEIGJsb2NrIGZvciB0aGF0IHNldCBjYW4gYmUgbW92ZWQu ICZuYnNwO0luIHRoZSBjYXNlIG9mIGluZGl2aWR1YWxseSBtb2JpbGUgZGViaWNlcyBvciBzb21l IHZhdGlhdGlvbnMgb24gZGF0YSBjZW50ZXIgbW9iaWxpdHksIHRoZXJlIGlzIGEgbmVlZCB0byBt c2tlIHN1cmUgdGhlIGZ1bGwgRUlEIGlzIGFkdmVydGlzZWQgaW4gdGhlIG1hcHBpbmcgc3lzdGVt LjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91cnMsPC9kaXY+PGRpdj5Kb2VsPC9kaXY+PGRpdj48YnI+ PGJyPjxzcGFuIHN0eWxlPSJmb250LXNpemU6ODclIj5TZW50IGZyb20gbXkgU2Ftc3VuZyBzbWFy dHBob25lIG9uIEFUJmFtcDtUPC9zcGFuPiA8L2Rpdj48YnI+PGJyPjxicj4tLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPlN1YmplY3Q6IFJFOiBbbGlzcF0gT1BTLURpciByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMSA8YnI+RnJvbTogIkJsYWNrLCBE YXZpZCIgJmx0O2RhdmlkLmJsYWNrQGVtYy5jb20mZ3Q7IDxicj5UbzogImFjYWJlbGxvQGFjLnVw Yy5lZHUiICZsdDthY2FiZWxsb0BhYy51cGMuZWR1Jmd0OyA8YnI+Q0M6IERpbm8gRmFyaW5hY2Np ICZsdDtmYXJpbmFjY2lAZ21haWwuY29tJmd0OywiSm9lbCBNLiBIYWxwZXJuIiAmbHQ7am1oQGpv ZWxoYWxwZXJuLmNvbSZndDssRGFtaWVuIFNhdWNleiAmbHQ7ZGFtaWVuLnNhdWNlekBpbnJpYS5m ciZndDssIm9wcy1kaXJAaWV0Zi5vcmciICZsdDtvcHMtZGlyQGlldGYub3JnJmd0OywiaWV0ZkBp ZXRmLm9yZyIgJmx0O2lldGZAaWV0Zi5vcmcmZ3Q7LCJsaXNwQGlldGYub3JnIiAmbHQ7bGlzcEBp ZXRmLm9yZyZndDssIkJsYWNrLCBEYXZpZCIgJmx0O2RhdmlkLmJsYWNrQGVtYy5jb20mZ3Q7IDxi cj48YnI+PGJyPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBBbGJlcnQsPG86cD48L286cD48L3NwYW4+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ QXMgbm90ZWQgYmVsb3csIG9uIHRoZSBFSUQgcHJlZml4IGZvciBtb2JpbGl0eSBpc3N1ZSwgYSBz aW1wbGUgc3RhdGVtZW50IGluIFNlY3Rpb24gNSB0byB0aGUgZWZmZWN0IHRoYXQg4oCcaW4gdGhl IHNwZWNpZmljIGNhc2Ugb2YgYSBWTS9tb2JpbGUgbm9kZSB0aGUgRUlELXByZWZpeCBzaG91bGQK IGJlIC8zMiBvciAvMTI4IChJUHY0IG9yIElQdjYgcmVzcGVjdGl2ZWx5KeKAnSB3aWxsIHN1ZmZp Y2UuJm5ic3A7IERldGFpbHMgb24gd2hhdCB0byBkbyB3aGVuIHRoYXQgYWR2aWNlIGlzIGlnbm9y ZWQgY2FuIGJlIGxlZnQgdG8gb3RoZXIgZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlRoYW5rcyw8YnI+Ci0tRGF2aWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+CjxkaXY+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsYmVydCBDYWJlbGxvcyBbbWFpbHRvOmFsYmVydC5j YWJlbGxvc0BnbWFpbC5jb21dCjxicj4KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkg MTEsIDIwMTUgNjozMyBQTTxicj4KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+CjxiPkNjOjwv Yj4gRGlubyBGYXJpbmFjY2k7IEpvZWwgTS4gSGFscGVybjsgRGFtaWVuIFNhdWNlejsgb3BzLWRp ckBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZzxicj4KPGI+U3ViamVjdDo8 L2I+IFJlOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVj dGlvbi0xMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgRGF2aWQ8bzpwPjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Mg Zm9yIHlvdXIgY29tbWVudHMsIEkgYW0gcGFyc2luZyB0aGVtIGFuZCBJwrRsbCBzdWdnZXN0IG5l dyB0ZXh0IGFpbWluZyB0byBhZGRyZXNzIHRoZW0gQVNBUC48bzpwPjwvbzpwPjwvcD4KPC9kaXY+ CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4K PGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBhbHNvIGxpa2UgdG8gYmV0dGVyIHVu ZGVyc3RhbmQgW0FdIGJlZm9yZSBkb2luZyB0aGlzLjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2 Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIExJU1AgYW4gRUlELXByZWlmeCBjYW4gaGF2ZSBh biBhcmJpdHJhcnkgbGVuZ3RoIGFuZCBjYW4gbW92ZSAoaS5lLiwgY2hhbmdlIGl0cyBSTE9DIGJp bmRpbmdzKSwgaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgYSBWTS9tb2JpbGUgbm9kZSB0aGUgRUlE LXByZWZpeCBzaG91bGQgYmUgLzMyIG9yIC8xMjggKElQdjQgb3IgSVB2NiByZXNwZWN0aXZlbHkp LiBXaGF0IGRvZXNuJ3Qgd29yayBpcyB0aGUgbW9iaWxpdHkKIG9mIGEgbm9kZSAoYXNzaWduZWQg d2l0aCBhIC8zMiBvciAvMTI4KSAqd2l0aGluKiBhIGNvYXJzZXIgRUlELXByZWZpeCwgaW4gdGhp cyBjYXNlIHlvdSBuZWVkIHRvIHNwbGl0IHRoZSBwcmVmaXggaW50byBtb3JlIHNwZWNpZmljcyBh bmQgcmVnaXN0ZXIgdGhlbSBpbmRlcGVuZGVudGx5IGluIHRoZSBNYXBwaW5nIFN5c3RlbSwgZWZm ZWN0aXZlbHkgY3JlYXRpbmcgbmV3IEVJRC1wcmVmaXhlcy48bzpwPjwvbzpwPjwvcD4KPC9kaXY+ CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4K PGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgY2xh cmlmaWVzIHlvdXIgY29tbWVudCwgaW4gdGhpcyBjYXNlIEkgd2lsbCBzdWdnZXN0IG5ldyB0ZXh0 IGZvciBTZWN0aW9uIDUuPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsYmVydDxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIEZlYiAxMiwgMjAxNSBhdCAxMjowNyBBTSwgQmxhY2ssIERhdmlkICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLmJsYWNrQGVt Yy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGlubyAtIHRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLjxicj4KPGJyPgpPbiB0aGUgbWFqb3IgaXNz dWVzLCBpdCBsb29rcyBsaWtlIGJvdGggW0FdIGFuZCBbQl0gaW52b2x2ZSBvbmx5IHRoZSB0ZXh0 PGJyPgppbiB0aGlzIGRyYWZ0IGFuZCBub3RoaW5nIGJleW9uZCwgd2hpY2ggaXMgZ29vZCBuZXdz LiZuYnNwOyBJIGhhdmUgYSBzaW1wbGUgdGV4dDxicj4Kc3VnZ2VzdGlvbiBmb3IgW0FdLCBidXQg aXQgbG9va3MgbGlrZSBbQl0gaXMgZ29pbmcgdG8gcmVxdWlyZSBzb21lIGNhcmVmdWw8YnI+CmVk aXRpbmcsIGFzIG9uZSBvZiB0aGUgcHJpbWFyeSBjYXVzZXMgaXMgdGhhdCB0aGUgZHJhZnQgaXMg c2xvcHB5IGluIHVzaW5nPGJyPgp0aGUgc2FtZSBzeW1ib2wgIkciIHRvIHJlcHJlc2VudCBib3Ro IEVJRCBhbmQgUkxPQyBtdWx0aWNhc3QgZ3JvdXBzLjxicj4KPGJyPgpPbiB0aGUgbWlub3IgaXNz dWVzLCBJIGhhdmUgdGV4dCBzdWdnZXN0aW9ucyBmb3IgdGhyZWUgb2YgdGhlIGZvdXIsIGFuZDxi cj4KSSdkIGxpa2UgdG8gdGVtcG9yYXJpbHkgZGVmZXIgZnVydGhlciBkaXNjdXNzaW9uIHRoZSBJ UHY2IFVEUCB6ZXJvPGJyPgpjaGVja3N1bSAidGFycGl0IiBpbiBmYXZvciBvZiByZXNvbHZpbmcg ZXZlcnl0aGluZyBlbHNlIGZpcnN0Ljxicj4KPGJyPgpPbiB0aGUgbml0cy9lZGl0b3JpYWwgY29t bWVudHMsIGFsbCB0aGUgc3VnZ2VzdGlvbnMgaW4geW91ciBlbWFpbCBhcmUgZmluZTxicj4Kd2l0 aCBtZS4mbmJzcDsgRldJVywgSSByZWdhcmQgdGhhdCBwb3J0aW9uIG9mIGEgcmV2aWV3IGFzIGFs bW9zdCBlbnRpcmVseTxicj4Kc3ViamVjdCB0byB0aGUgZHJhZnQgYXV0aG9ycycgZGlzY3JldGlv biAoYW5kIGVkaXRvcmlhbCB0YXN0ZSkuPGJyPgo8YnI+CiZndDsgJmd0OyZndDsgW0FdIEVJRCBt b2JpbGl0eSB2cy4gRUlEIHByZWZpeGVzPGJyPgomZ3Q7PGJyPgomZ3Q7IC4uLiBmcm9tIHRoZSBz dGFydCBvZiB0aGUgTElTUCBkZXNpZ24gKGNpcmNhIDIwMDcpLCBhbiBwcmVmaXggaXMgd2hhdCBt b3Zlcy48YnI+CiZndDsgQW5kIGEgc3BlY2lmaWMgRUlEIGlzIHNpbXBseSBhIC8zMiBvciAvMTI4 IHByZWZpeC4gSGVyZSBpcyBhIHByYWN0aWNhbDxicj4KJmd0OyBleGFtcGxlOjxicj4KPGJyPgpB IHN0YXRlbWVudCB0aGF0IHRoZSBtb2JpbGl0eSB1c2UgY2FzZXMgbmVlZCB0byBlbXBsb3kgLzMy IGFuZCAvMTI4IHByZWZpeGVzLDxicj4KYW5kIG5vdCBhbnl0aGluZyBjb2Fyc2VyIHNob3VsZCBz dWZmaWNlLiZuYnNwOyBUaGF0IHNob3VsZCBiZSBhZGRlZCB0byBTZWN0aW9uIDUuPGJyPgo8YnI+ CiZndDsgJmd0OyZndDsgW0JdIExJU1AgTXVsdGljYXN0IHZzLiBFSUQvUkxPQyBzZXBhcmF0ZTxi cj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIDYuIE11bHRpY2FzdDxicj4KJmd0 OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIGludGVyZXN0aW5nLCBtdWx0aWNh c3QgYWRkcmVzc2VzIChHKSBsb29rIGxpa2UgdGhleSdyZSBhbiBleGNlcHRpb248YnI+CiZndDs8 YnI+CiZndDsgVGhleSBhcmUgcmVhbGx5IG5vdC48YnI+Cjxicj4KTXkgY29uY2VybiBpcyB0aGF0 IGFzIEkgcmVhZCB0aGUgZHJhZnQsIGl0IGxlYXZlcyBtZSB3aXRoIHRoZSBzdHJvbmcgaW1wcmVz c2lvbjxicj4KdGhhdCB0aGUgc2FtZSBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBhcmUgYmVpbmcg dXNlZCBpbiBib3RoIHRoZSBvdmVybGF5PGJyPgooYXMgRUlEcykgYW5kIHRoZSB1bmRlcmxheSAo YXMgUkxPQ3MpLiZuYnNwOyBGcm9tIHlvdXIgcmVzcG9uc2UsIEkgY29uY2x1ZGUgdGhhdCB0aGlz PGJyPgppcyBub3QgdGhlIGNhc2UgKGFuZCBJIGhhdmUgbm8gYXJndW1lbnQgd2l0aCB0aGF0KS4m bmJzcDsgUmF0aGVyLCBTZWN0aW9uIDYgbmVlZHMgdG88YnI+CmJsdW50bHkgc3RhdGUgdGhhdCBt dWx0aWNhc3QgYWRkcmVzc2VzIGFyZSBtYXBwZWQgYmV0d2VlbiBFSUQgYW5kIFJMT0Mgc3BhY2Ug YXQ8YnI+CmJvdGggSVRScyBhbmQgRVRScywgc28gdGhhdCB0aGUgZm9sbG93aW5nIGluZmVyZW5j ZSBpcyBvYnZpb3VzIGZyb20gdGhlIHRleHQ8YnI+CihpdCdzIGN1cnJlbnRseSBub3Qgb2J2aW91 cyk6PGJyPgo8YnI+CiZndDsgU28gaXQgbWFrZXMgcGVyZmVjdCBzZW5zZSB0byByZWdpc3RlciBt dWx0aWNhc3QgYWRkcmVzc2VzIHRvIHRoZSBtYXBwaW5nPGJyPgomZ3Q7IHN5c3RlbSBhcyBFSURz IGFuZCB0aGV5IGNhbiBtYXAgdG8gUkxPQ3Mgb2Ygc2l0ZXMgdGhhdCBoYXZlIGpvaW5lZCB0aGUg Z3JvdXAuPGJyPgo8YnI+CkFzIHBhcnQgb2YgdGhpcywgSSBzdHJvbmdseSByZWNvbW1lbmQgbW92 aW5nIGF3YXkgZnJvbSB1c2Ugb2YgIkciIHRvIHJlZmVyIHRvPGJyPgptdWx0aWNhc3QgZ3JvdXBz IGluIGJvdGggdGhlIG92ZXJsYXkgYW5kIHVuZGVybGF5LiZuYnNwOyBDYXJlZnVsIHVzZSBvZiBH LUVJRDxicj4KYW5kIEctUkxPQyB3b3VsZCBzaWduaWZpY2FudGx5IGltcHJvdmUgY2xhcml0eS48 YnI+Cjxicj4KLS0tPGJyPgpJZiB0aGUgYWJvdmUgYXJlIGRvbmUgZm9yIFtBXSBhbmQgW0JdIGlu IFNlY3Rpb25zIDUgYW5kIDYsIHRoZW4gdGhlIHRleHQgZm9yIHRoZTxicj4KdXNlIGNhc2VzIGlu IFNlY3Rpb24gNyBzaG91bGQgbm90IG5lZWQgZnVydGhlciBhdHRlbnRpb24uPGJyPgotLS08YnI+ Cjxicj4KJmd0OyAmZ3Q7Jmd0OyAtLSBNaW5vciBJc3N1ZXMgLS08YnI+CiZndDsgJmd0OyZndDs8 YnI+CiZndDsgJmd0OyZndDsgVGhlcmUgc2VlbXMgdG8gYmUgYW4gaW1wbGljaXQgYXNzdW1wdGlv biB0aGF0IHRoZSBlbmQgaG9zdCBhbmQgaXRzPGJyPgomZ3Q7ICZndDsmZ3Q7IElUUiAoeFRSKSBh cmUgaW4gdGhlIHNhbWUgZG9tYWluIG9yIEF1dG9ub21vdXMgU3lzdGVtLiZuYnNwOyBGb3IgaW5j cmVtZW50YWw8YnI+CiZndDs8YnI+CiZndDsgVGhpcyBpcyB0cnVlIHdoZW4geW91IGNhbGwgdGhl IGRvbWFpbiBhICJMSVNQIHNpdGUiLiBCdXQgaWYgdGhlIHNpdGUgaXM8YnI+CiZndDsgdW5jaGFu Z2VkIGFuZCBvbmUgdXNlcyBQSVRScywgbWF5YmUgZXZlbiBjbG9zZSB0byB0aGUgc2l0ZSwgbGlr ZSBpbiBhIFBFPGJyPgomZ3Q7IHJvdXRlciwgdGhlbiB0aGUgUElUUiBpcyBkZWZpbml0ZWx5IGlu IGFub3RoZXIgQVMuPGJyPgo8YnI+Ckxvb2tpbmcgYXQgdGhlIHRleHQsIGl0IHNlZW1zIHRoYXQg IkxJU1Agc2l0ZSIgYW5kICJkb21haW4iIGFyZSB0aGUgc2FtZTxicj4KY29uY2VwdCBmb3IgdGhp cyBkcmFmdC4mbmJzcDsgVGhhdCB3b3VsZCBiZSB1c2VmdWwgdG8gc3RhdGUsIElNSE8gYnV0IEkn bGwgbGVhdmU8YnI+CnRoZSBkZWNpc2lvbiBvbiB3aGV0aGVyIHRvIGRvIHNvIHRvIHlvdSBhbmQg dGhlIGRyYWZ0IGF1dGhvcnMuPGJyPgo8YnI+Ck9uIHJlcmVhZGluZywgbXkgY29uY2VybnMgc2Vl bSB0byBiZSB0cmlnZ2VyZWQgbW9zdGx5IGJ5IHRoaXMgc2VudGVuY2UgaW48YnI+ClNlY3Rpb24g My4yOjxicj4KPGJyPgombmJzcDsgJm5ic3A7VGhlIGVkZ2UgY29uc2lzdHMgb2YgTElTUCBzaXRl cyAoZS5nLiwgYW48YnI+CiZuYnNwOyAmbmJzcDtBdXRvbm9tb3VzIFN5c3RlbSkgdGhhdCB1c2Ug RUlEIGFkZHJlc3Nlcy48YnI+Cjxicj4KSSB0aGluayBhIHNtYWxsIGNoYW5nZSB0byB0aGUgbGFz dCBzZW50ZW5jZSBpbiB0aGF0IHBhcmFncmFwaCB3b3VsZCByZXNvbHZlPGJyPgpteSBjb25jZXJu IHdpdGhvdXQgZGlzdHJhY3RpbmcgZnJvbSB0aGUgbmFycmF0aXZlOjxicj4KPGJyPgpPTEQ8YnI+ CiZuYnNwOyAmbmJzcDtFSURzIGRvIG5vdDxicj4KJm5ic3A7ICZuYnNwO2NvbnRhaW4gaW50ZXIt ZG9tYWluIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNlIG9mIHRoaXMsPGJyPgom bmJzcDsgJm5ic3A7RUlEcyBhcmUgdXN1YWxseSByb3V0YWJsZSBhdCB0aGUgZWRnZSAod2l0aGlu IExJU1Agc2l0ZXMpIG9yIGluIHRoZTxicj4KJm5ic3A7ICZuYnNwO25vbi1MSVNQIEludGVybmV0 Ljxicj4KTkVXPGJyPgombmJzcDsgJm5ic3A7RUlEcyBkbyBub3Q8YnI+CiZuYnNwOyAmbmJzcDtj b250YWluIGludGVyLWRvbWFpbiB0b3BvbG9naWNhbCBpbmZvcm1hdGlvbiBhbmQgYmVjYXVzZSBv ZiB0aGlzLDxicj4KJm5ic3A7ICZuYnNwO0VJRHMgYXJlIHVzdWFsbHkgcm91dGFibGUgYXQgdGhl IGVkZ2UgKHdpdGhpbiBMSVNQIHNpdGVzKSBvciBpbiB0aGU8YnI+CiZuYnNwOyAmbmJzcDtub24t TElTUCBJbnRlcm5ldDsgc2VlIFNlY3Rpb24gMy41IGZvciBkaXNjdXNzaW9uIG9mIExJU1Agc2l0 ZTxicj4KJm5ic3A7ICZuYnNwO2ludGVybmV0d29ya2luZyB3aXRoIG5vbi1MSVNQIHNpdGVzIGFu ZCBkb21haW5zIGluIHRoZSBJbnRlcm5ldC48YnI+Cjxicj4KJmd0OyAmZ3Q7Jmd0OyBEZXNwaXRl IG11bHRpcGxlJm5ic3A7IG1lbnRpb25zIG9mIGluY3JlbWVudGFsIGRlcGxveW1lbnQsIEkgZGlk IG5vdDxicj4KJmd0OyAmZ3Q7Jmd0OyBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGF0IG1pZ2h0 IGJlIGFjY29tcGxpc2hlZC48YnI+CiZndDs8YnI+CiZndDsgVGhlcmUgYXJlIFB4VFJzIGFuZCBO QVRzLiBBbmQgcmVmZXJlbmNlcyB0byB0aGUgTElTUCBpbnRlcndvcmtpbmcgUkZDLjxicj4KPGJy PgpPaywgY2FuIHdlIGp1c3Qgc2F5IHNvIGluIFNlY3Rpb24gMy41PyZuYnNwOyBBZGRpbmcgdGhl IGZvbGxvd2luZyBzZW50ZW5jZTxicj4KdG8gdGhlIGVuZCBvZiB0aGUgc2VjdGlvbiB3b3VsZCBz dWZmaWNlOjxicj4KPGJyPgombmJzcDsgJm5ic3A7UElUUnMsIFBFVFJzIGFuZCBMSVNQLU5BVCBz dXBwb3J0IGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgTElTUDxicj4KJm5ic3A7ICZuYnNwO2J5 IHByb3ZpZGluZyBzaWduaWZpY2FudCBmbGV4aWJpbGl0eSBpbiBsb2NhdGlvbiBvZiB0aGUgYm91 bmRhcmllczxicj4KJm5ic3A7ICZuYnNwO2JldHdlZW4gdGhlIExJU1AgYW5kIG5vbi1MSVNQIHBv cnRpb25zIG9mIHRoZSBuZXR3b3JrLCBhbmQgbWFraW5nPGJyPgombmJzcDsgJm5ic3A7aXQgcmVh c29uYWJsZSB0byBjaGFuZ2UgdGhvc2UgYm91bmRhcmllcyBvdmVyIHRpbWUuPGJyPgo8YnI+CiZn dDsgJmd0OyZndDsgLSAzLjMuMS4mbmJzcDsgTElTUCBFbmNhcHN1bGF0aW9uPGJyPgomZ3Q7ICZn dDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgc291cmNlIHBvcnQgaXMg c2VsZWN0ZWQgYnk8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHRoZSBJVFIgYW5kIGln bm9yZWQgb24gcmVjZXB0aW9uLjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBQ bGVhc2UgbWVudGlvbiBtdWx0aXBhdGhpbmcgKGUuZy4sIEVDTVAgYW5kIExBRykgYXMgcG9zc2li bGUgaW5mbHVlbmNlczxicj4KJmd0OyAmZ3Q7Jmd0OyBvbiBob3cgc291cmNlIHBvcnRzIGFyZSBz ZWxlY3RlZCwgYXMgdGhpcyBpbXBvc2VzIHNvbWUgbGltaXRzIG9uIHdoYXQgYW48YnI+CiZndDsg Jmd0OyZndDsgSVRSIGNhbiByZWFzb25hYmx5IGRvLjxicj4KJmd0Ozxicj4KJmd0OyBFQ01QL0xB RyBkb24ndCBpbmZsdWVuY2Ugd2hpY2ggc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQuIEl0IGlzIGEg NS10dXBsZSBoYXNoPGJyPgomZ3Q7IG9mIHRoZSBpbm5lciBoZWFkZXIgdGhhdCBzZWxlY3RzIGEg c291cmNlIHBvcnQgdGhhdCBpbmZsdWVuY2VzIGhvdyBhbiB1bmRlcmxheTxicj4KJmd0OyByb3V0 ZXIgd291bGQgbG9hZC1zcGxpdCB0cmFmZmljLjxicj4KPGJyPgpQbGVhc2Ugc3RhdGUgdGhhdCBh IDUtdHVwbGUgaGFzaCBpcyB1c2VkLiZuYnNwOyBFQ01QL0xBRyBpcyBhbW9uZyB0aGUgaW1wb3J0 YW50PGJyPgpyZWFzb25zIHdoeSwgYnV0IHRoYXQgZG9lc24ndCBuZWVkIHRvIGJlIHN0YXRlZCBp ZiB5b3UgcHJlZmVyIG5vdCB0by4mbmJzcDsgQW48YnI+CmV4YW1wbGUgb2Ygc29tZXRoaW5nIHRo YXQgbmVlZHMgdG8gYmUgZXhjbHVkZWQgaXMgdGhhdCB1c2luZyBhIHJhbmRvbTxicj4KbnVtYmVy IGdlbmVyYXRvciB0byBzZXQgdGhlIHNvdXJjZSBwb3J0IHdvdWxkIGJlIHdyb25nIC0gSSBjb3Vs ZCBzdWdnZXN0PGJyPgpjaXRpbmcgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwIGZvciByZWxhdGVk IGRpc2N1c3Npb24gKGFuZCBsb3RzIG1vcmU8YnI+CmRldGFpbHMpLCBidXQgSSBkb24ndCB0aGlu ayB0aGF0J3MgbmVjZXNzYXJ5Ljxicj4KPGJyPgotLSBJUHY2IHplcm8gVURQIGNoZWNrc3VtPGJy Pgo8YnI+CiZndDsgTXkgaGVhZCBzcGlucyBldmVyeSB0aW1lIEkgaGVhciBhYm91dCB0aGlzIHN1 YmplY3QuIFRoaXMgc3ViamVjdCBoYXMgYmVlbjxicj4KJmd0OyB0YWxrZWQgYWJvdXQgZnJvbSAx MDBzIG9mIHBlb3BsZSBmb3IgYSBkZWNhZGUuIFdlIGhhdmUgQ1JDIG9uIGxpbmtzLCB3ZSBoYXZl PGJyPgomZ3Q7IGFwcHMgdGhhdCB1c2UgVENQIGFuZCBVRFAgY2hlY2tzdW1zLiBOdWYgc2FpZC48 YnI+Cjxicj4KVW5kZXJzdG9vZCAtIHRoZXJlJ3MgbW9yZSB0aGFuIG9uZSBzZXQgb2Ygc2NhcnMg b24gdGhpcyBvbmUgOi0oLiZuYnNwOyBMZXQncyBjb21lIGJhY2s8YnI+CnRvIHRoaXMgdG9waWMg YWZ0ZXIgd2UndmUgcmVzb2x2ZWQgZXZlcnl0aGluZyBlbHNlLCBhbmQgcGxlYXNlIGtlZXAgaW4g bWluZDxicj4KdGhhdCBJIHRhZ2dlZCB0aGlzIGFzIGEgbWlub3IgaXNzdWUsIG5vdCBhIG1ham9y IG9uZSAoZS5nLiwgdGhlIGFib3ZlIGNoYW5nZXM8YnI+CmZvciBbQV0gYW5kIFtCXSBhcmUgZmFy IG1vcmUgaW1wb3J0YW50LCBJTUhPKS48YnI+Cjxicj4KVGhhbmtzLDxicj4KLS1EYXZpZDxicj4K PGJyPgo8c3BhbiBjbGFzcz0iaW0iPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L3Nw YW4+PGJyPgo8c3BhbiBjbGFzcz0iaW0iPiZndDsgRnJvbTogRGlubyBGYXJpbmFjY2kgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbSI+ZmFyaW5hY2NpQGdtYWlsLmNv bTwvYT5dPC9zcGFuPjxicj4KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IFNlbnQ6IFdlZG5lc2RheSwg RmVicnVhcnkgMTEsIDIwMTUgMjoxOSBQTTwvc3Bhbj48YnI+CjxzcGFuIGNsYXNzPSJpbSI+Jmd0 OyBUbzogSm9lbCBNLiBIYWxwZXJuPC9zcGFuPjxicj4KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IENj OiBCbGFjaywgRGF2aWQ7IEFsYmVydCBDYWJlbGxvczsgRGFtaWVuIFNhdWNlejsgPGEgaHJlZj0i bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmciPgpvcHMtZGlyQGlldGYub3JnPC9hPjs8L3NwYW4+PGJy Pgo8c3BhbiBjbGFzcz0iaW0iPiZndDsgPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmll dGZAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+Cmxpc3BAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxicj4KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IFN1YmplY3Q6IFJlOiBb bGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMTwv c3Bhbj48YnI+CjxzcGFuIGNsYXNzPSJpbSI+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPGRp dj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij4mZ3Q7ICZndDsgSSB3aWxsIGxlYXZlIG1vc3Qgb2YgdGhlc2UgZm9yIHRoZSBhdXRob3JzIHRv IGNvbW1lbnQgb24uPGJyPgomZ3Q7PGJyPgomZ3Q7IFNlZSBteSBjb21tZW50cyBpbmxpbmUuIFRo YW5rcyBEYXZpZCBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRhcnkuPGJyPgom Z3Q7PGJyPgomZ3Q7ICZndDsgV2l0aCByZWdhcmQgdG8geW91ciBxdWVzdGlvbiBhYm91dCBpbmNy ZW1lbnRhbCBkZXBsb3ltZW50LCB0aGF0IGlzIHRoZTxicj4KJmd0OyBkb21haW4gb2YgdGhlIExJ U1AgRGVwbG95bWVudCBkb2N1bWVudCwgYW5kIHdhcyBkZWxpYmVyYXRlbHkgb25seSBsaWdodGx5 PGJyPgomZ3Q7IGNvdmVyZWQgaGVyZS4mbmJzcDsgSSBhbSBub3Qgc3VyZSB3aGF0IHdlIGNhbiBk byB0byBhZGRyZXNzIHlvdXIgY29tbWVudCB3aXRob3V0PGJyPgomZ3Q7IGR1cGxpY2F0aW5nIHRo ZSBlbnRpcmV0eSBvZiB0aGF0IGRvY3VtZW50Ljxicj4KJmd0Ozxicj4KJmd0OyBUaGF0IGlzIHRo ZSByaXNrIHdlIG1heSBoYXZlIHdpdGggbWFueSBvZiB5b3VyIGNvbW1lbnRzLiBXZSBoYXZlIGEg bG90IG9mPGJyPgomZ3Q7IGRldGFpbCBpbiB0aGUgYWxyZWFkeSA5IHB1Ymxpc2hlZCBSRkNzJm5i c3A7IGFuZCB0aGlzIGRvY3VtZW50IHJlYWxseSBpcyB0byB0YWtlPGJyPgomZ3Q7IGFsbCB0aGF0 IGRldGFpbCBhbmQgc3VtbWFyaXplIGFzIGFuIGVhc2lseSB1bmRlcnN0YW5kYWJsZSBkZXNjcmlw dGlvbiBvZiBhPGJyPgomZ3Q7IGNvaGVzaXZlIGRlc2lnbi48YnI+CiZndDs8YnI+CiZndDsgJmd0 OyBXaXRoIHJlZ2FyZCB0byBVRFAgWmVybywgdGhpcyB3YXMgYXBwcm92ZWQgYnkgdGhlIElFU0cg YW5kIHB1Ymxpc2hlZCBhcyBhbjxicj4KJmd0OyBSRkMuJm5ic3A7IEl0IGlzIHBhcnQgb2YgdGhl IHdheSB0aGUgcHJvdG9jb2wgaXMgZGVmaW5lZC4mbmJzcDsgSWYgdGhlcmUgYXJlIHNwZWNpZmlj PGJyPgomZ3Q7IGNoYW5nZXMgeW91IHdvdWxkIGxpa2UgdG8gc2VlIGluIHRoZSBleHBsYW5hdG9y eSB0ZXh0LCBJIGFtIHN1cmU8YnI+CiZndDs8YnI+CiZndDsgRGVmaW5pdGVseSBhZ3JlZWQuIElu IGZhY3Qgd2UgaW5zdGlnYXRlZCBVRFAgemVyby4gQW5kIEkgY29udGludWFsbHkgdGFsayB0bzxi cj4KJmd0OyBoYXJkd2FyZSBlbmdpbmVlcnMgYW5kIHRoZXkgYWxsIGJlbGlldmUgd2UgbWFkZSB0 aGUgcmlnaHQgZGVjaXNpb24uIFNvIGhhdHM8YnI+CiZndDsgb2ZmIHRvIHRoZSBJRVRGIGZvciBi ZWluZyBwcmFjdGljYWwuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsgd2UgY291bGQgaW5jbHVkZSB0 aGVtLiZuYnNwOyBJZiB5b3UgYXJlIGxvb2tpbmcgZm9yIGEgY2hhbmdlIGluIHRoZSBiZWhhdmlv ciw8YnI+CiZndDsgdGhpcyBkb2N1bWVudCBjYW4gbm90IG1ha2UgY2hhbmdlcyB0byB0aGUgTElT UCBiZWhhdmlvci48YnI+CiZndDs8YnI+CiZndDsgWWVzLCBhbiBpbXBvcnRhbnQgcG9pbnQuPGJy PgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEkgZm91bmQgYSBjb3VwbGUgb2YgbWFqb3IgaXNzdWVz IHRoYXQgSSBob3BlIGFyaXNlIGZyb20gdGhlPGJyPgomZ3Q7ICZndDsmZ3Q7IHN1bW1hcml6YXRp b24gb2YgTElTUCBpbiB0aGlzIGRyYWZ0LCBhcyBvcHBvc2VkIHRvIGJlaW5nIHByb2JsZW1zIGlu PGJyPgomZ3Q7ICZndDsmZ3Q7IHRoZSBhY3R1YWwgTElTUCBwcm90b2NvbHMuJm5ic3A7IEkgYWxz byBmb3VuZCBhIGZldyBtaW5vciBpc3N1ZXMsIHRoZSBtb3N0PGJyPgomZ3Q7ICZndDsmZ3Q7IGlt cG9ydGFudCBvZiB3aGljaCBpcyB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCBzZWN1cml0eSBjb25z aWRlcmF0aW9uczxicj4KJmd0OyAmZ3Q7Jmd0OyBkaXNjdXNzaW9uIG9uIG1pc2RlbGl2ZXJ5LCB3 aXRoIHBhcnRpY3VsYXIgYXR0ZW50aW9uIHRvIFZQTnMuPGJyPgomZ3Q7PGJyPgomZ3Q7IFRoYW5r cyBhIHRvbi48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDsgLS0gTWFqb3IgaXNzdWVzIC0tPGJy PgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IFtBXSBFSUQgbW9iaWxpdHkgdnMuIEVJ RCBwcmVmaXhlczxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIDUuIE1vYmls aXR5PGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEkgdW5kZXJzdGFuZCBob3cg dGhpcyB3b3JrcyB3aGVuIG1hcHBpbmcgaXMgcGVyLUVJRCwgYnV0IGhvdyBkb2VzIHRoaXMgd29y azxicj4KJmd0OyAmZ3Q7Jmd0OyB3aGVuIHRoZSBFSUQgb2YgdGhlIHN5c3RlbSB0aGF0IG1vdmVz IGlzIHBhcnQgb2YgYW4gRUlEIHByZWZpeCwgYXM8YnI+CiZndDsgZGlzY3Vzc2VkPGJyPgomZ3Q7 ICZndDsmZ3Q7IGluIFNlY3Rpb24gMy40LjE/Jm5ic3A7IEV2ZW4gaWYgdGhlIGFuc3dlciBpcyBh IGxvbmcgdmVyc2lvbiBvZiAiRG9uJ3QgZG8gdGhhdCEiPGJyPgomZ3Q7ICZndDsmZ3Q7IGl0IHNo b3VsZCBiZSBleHBsYWluZWQuPGJyPgomZ3Q7PGJyPgomZ3Q7IE5vLCBmcm9tIHRoZSBzdGFydCBv ZiB0aGUgTElTUCBkZXNpZ24gKGNpcmNhIDIwMDcpLCBhbiBwcmVmaXggaXMgd2hhdCBtb3Zlcy48 YnI+CiZndDsgQW5kIGEgc3BlY2lmaWMgRUlEIGlzIHNpbXBseSBhIC8zMiBvciAvMTI4IHByZWZp eC4gSGVyZSBpcyBhIHByYWN0aWNhbDxicj4KJmd0OyBleGFtcGxlOjxicj4KJmd0Ozxicj4KJmd0 OyBZb3UgaGF2ZSBhIGNsdXN0ZXIgb2Ygc2VydmVycyB0aGF0IGNvbW11bmljYXRlIHRvZ2V0aGVy IGZvciBhIHBhcnRpY3VsYXI8YnI+CiZndDsgYXBwbGljYXRpb24uIFRoZXkgYXBwbGljYXRpb24g Y2x1c3RlciBpcyBydW5uaW5nIGluIGEgc2V0IG9mIFZNcy4gVGhvc2UgVk1zPGJyPgomZ3Q7IGFy ZSBhc3NpZ25lZCBFSURzIGZyb20gYSBjb21tb24gcG93ZXItb2YtMiBFSUQtcHJlZml4LiBUaG9z ZSBWTXMgYXJlIGN1cnJlbnRseTxicj4KJmd0OyBydW5uaW5nIGluIGEgYnJpY2stYW5kLW1vcnRh ciBkYXRhIGNlbnRlci4gTm93IHRoZXJlIGlzIGEgZGVzaXJlIHRvIG1vdmUgdGhlPGJyPgomZ3Q7 IFZNIGNsdXN0ZXIgdG8gYSBjbG91ZCBwcm92aWRlci4gV2hhdCBpcyBtb3ZlZCBpcyB0aGUgRUlE LXByZWZpeCBvZiB0aGU8YnI+CiZndDsgY2x1c3Rlci4gVGhlIG1hcHBpbmcgc3lzdGVtIGlzIHRv bGQgdGhhdCB0aGUgRUlELXByZWZpeCBpcyBjaGFuZ2luZyBpdHMgUkxPQy08YnI+CiZndDsgc2V0 IGZyb20gdGhlIGJyaWNrLWFuZC1tb3J0YXIgeFRScyB0byB0aGUgY2xvdWQgcHJvdmlkZXJzIHhU UnMuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0gNy40LiZu YnNwOyBMSVNQIGZvciBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkgaW4gRGF0YSBDZW50ZXJzPGJy PgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cg dGhpcyB3b3JrcyB3aGVuIEVJRCBwcmVmaXhlcyBhcmUgdXNlZCwgYXMgZWFjaCBWTTxicj4KJmd0 OyAmZ3Q7Jmd0OyBoYXMgaXRzIG93biBFSUQgb3IgRUlEcywgaGVuY2UgdGhlIGVudGlyZSBwcmVm aXggcmFuZ2UgZG9lcyBub3QgbW92ZSB3aGVuPGJyPgomZ3Q7ICZndDsmZ3Q7IHRoZSBWTSBtb3Zl cy48YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgRm9yIE9QUy1EaXIsIHRoaXMg RUlEIHByZWZpeCBpc3N1ZSBbQV0gZmFsbHMgdW5kZXIgQS4xLjEgaW4gQXBwZW5kaXggQTxicj4K Jmd0OyAmZ3Q7Jmd0OyBvZiBSRkMgNTcwNjombmJzcDsgSGFzIGRlcGxveW1lbnQgYmVlbiBkaXNj dXNzZWQ/IGFuZCBzcGVjaWZpY2FsbHkgdW5kZXI6PGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7 ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICombmJzcDsgSXMgdGhlIHByb3Bv c2VkIHNwZWNpZmljYXRpb24gZGVwbG95YWJsZT8mbmJzcDsgSWYgbm90LCBob3cgY291bGQ8YnI+ CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2l0 IGJlIGltcHJvdmVkPzxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBhcyBFSUQg cHJlZml4ZXMgYXBwZWFyIHRvIGJlIHVuZGVwbG95YWJsZSBmb3IgTW9iaWxpdHkgYW5kIFZNIE1v YmlsaXR5PGJyPgomZ3Q7IHVzYWdlLjxicj4KJmd0Ozxicj4KJmd0OyBTZWUgYWJvdmUgZXhhbXBs ZS48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDsgW0JdIExJU1AgTXVsdGljYXN0IHZzLiBFSUQv UkxPQyBzZXBhcmF0ZTxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIDYuIE11 bHRpY2FzdDxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIGludGVy ZXN0aW5nLCBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBsb29rIGxpa2UgdGhleSdyZSBhbiBleGNl cHRpb248YnI+CiZndDs8YnI+CiZndDsgVGhleSBhcmUgcmVhbGx5IG5vdC4gU2luY2UgbXVsdGlj YXN0IGFkZHJlc3NlcyAqaWRlbnRpZnkqIGEgZ3JvdXAgb2Y8YnI+CiZndDsgcmVjZWl2ZXJzLCBp dCBpcyB2ZXJ5IG11Y2ggYW4gRUlEIGFuZCBhaGVyZXMgdG8gdGhlIGRlZmluaXRpb24gb2YgYW4g RUlELjxicj4KJmd0OyBNdWx0aWNhc3QgYWRkcmVzc2VzIG5ldmVyIGhhZCB0b3BvbG9naWNhbCBz aWduZmljYW5jZSBidXQgdGhlIHN0YXRlPGJyPgomZ3Q7IHJlcHJlc2VudGluZyBhIGRpc3RyaWJ1 dGlvbiB0cmVlIGRvZXMgdGVsbCB5b3Ugd2VyZSB0aGUgbWVtYmVycyBhcmUgKGJ1dCB0aGU8YnI+ CiZndDsgaWRlbnRpdHkgb2YgdGhlIG1lbWJlcnMgYXJlIG5vdCBrbm93IGluIG11bHRpY2FzdCku PGJyPgomZ3Q7PGJyPgomZ3Q7IFNvIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gcmVnaXN0ZXIg bXVsdGljYXN0IGFkZHJlc3NlcyB0byB0aGUgbWFwcGluZzxicj4KJmd0OyBzeXN0ZW0gYXMgRUlE cyBhbmQgdGhleSBjYW4gbWFwIHRvIFJMT0NzIG9mIHNpdGVzIHRoYXQgaGF2ZSBqb2luZWQgdGhl IGdyb3VwLjxicj4KJmd0OyBTZWUgZHJhZnQtZmFyaW5hY2NpLXNpZ25hbC1mcmVlLW11bHRpY2Fz dCBhcyBqdXN0IG9uZSBleGFtcGxlLiBSRkM2ODMxIGFuZDxicj4KJmd0OyBkcmFmdC1mYXJpbmFj Y2ktbGlzcC1tci1zaWduYWxpbmcgYXJlIG90aGVyIGV4YW1wbGVzLjxicj4KJmd0Ozxicj4KJmd0 OyAmZ3Q7Jmd0OyB0byB0aGUgRUlEL1JMT0Mgc2VwYXJhdGlvbiBhcyB0aGUgc2FtZSBkZXN0aW5h dGlvbiBJUCBtdWx0aWNhc3QgYWRkcmVzczxicj4KJmd0OyAmZ3Q7Jmd0OyBpcyB1c2VkIGZvciBi b3RoIHB1cnBvc2VzLiZuYnNwOyBUaGlzIGNvdWxkIHVzZSBzb21lIG1vcmUgZGlzY3Vzc2lvbiwg YXMgaXQnczxicj4KJmd0OyAmZ3Q7Jmd0OyB1bmV4cGVjdGVkIGJhc2VkIG9uIHRoZSBjb250ZW50 cyBvZiB0aGUgZHJhZnQgdXAgdG8gdGhpcyBwb2ludC48YnI+CiZndDs8YnI+CiZndDsgSSBiZWxp ZXZlIHRoZSBsZXZlbCBvZiBkZXRhaWwgd2UgaGF2ZSBpbiB0aGUgaW50cm9kdWN0aW9uIGRvY3Vt ZW50IGlzIGF0IHRoZTxicj4KJmd0OyByaWdodCBsZXZlbCBvciB3ZSdsbCBlcnIgb24gaGF2aW5n IHdheSB0b28gbWFueSBkZXRhaWxzIGNyb3AgaW4uPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7 IC0gNy4yLiZuYnNwOyBMSVNQIGZvciBJUHY2IENvLWV4aXN0ZW5jZTxicj4KJmd0OyAmZ3Q7Jmd0 Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgTElTUCBlbmNhcHN1bGF0aW9ucyBhbGxv d3MgdG8gdHJhbnNwb3J0IHBhY2tldHMgdXNpbmcgRUlEcyBmcm9tIGE8YnI+CiZndDsgJmd0OyZn dDsmbmJzcDsgJm5ic3A7IGdpdmVuIGFkZHJlc3MgZmFtaWx5IChlLmcuLCBJUHY2KSB3aXRoIHBh Y2tldHMgZnJvbSBvdGhlciBhZGRyZXNzPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBm YW1pbGllcyAoZS5nLiwgSVB2NCkuPGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7 IEhvdyBkb2VzIHRoYXQgd29yayBmb3IgbXVsdGljYXN0IHRyYWZmaWMsIHdoZXJlIHRoZSBkZXN0 aW5hdGlvbiBhZGRyZXNzPGJyPgomZ3Q7ICZndDsmZ3Q7IChHKSBoYXMgdG8gYmUgdGhlIHNhbWUg aW4gYm90aCB0aGUgaW5uZXIgYW5kIG91dGVyIGhlYWRlcnM/Jm5ic3A7IEFyZSBFVFJzPGJyPgom Z3Q7ICZndDsmZ3Q7IGFuZCBJVFJzIGV4cGVjdGVkIHRvIG1hcCBJUHY2IG11bHRpY2FzdCBhZGRy ZXNzZXMgdG8gSVB2NCBhbmQgdi52Lj88YnI+CiZndDs8YnI+CiZndDsgVGhlIG1hcHBpbmcgc3lz dGVtIGNhbiBtYXAgYW4gKFMtRUlELWlwdjYsIGdyb3VwLWlwdjYpIDItdHVwbGUgdG8gYSBSTE9D IHNldDxicj4KJmd0OyB0aGF0IGxvb2tlZCBsaWtlIHRoaXMgKGlwdjQtbXVsdGljYXN0LCBpcHY0 LXVuaWNhc3QpIG1lYW4gdGhlIElUUiB0aGF0PGJyPgomZ3Q7IHJlY2VpdmVzIHRoZSBwYWNrZXQg ZnJvbSBTLUVJRC1pcHY2IHdvdWxkIHJlcGxpY2F0ZSB0aGUgcGFja2V0IGFuZCBtdWx0aWNhc3Q8 YnI+CiZndDsgZW5jYXBzdWxhdGUgdG8gaXB2NC1tdWx0aWNhc3QgYW5kIHVuaWNhc3QgZW5jYXBz dWFsdGUgdG8gaXB2NC11bmljYXN0Ljxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIDcuMy4m bmJzcDsgTElTUCBmb3IgVmlydHVhbCBQcml2YXRlIE5ldHdvcmtzPGJyPgomZ3Q7ICZndDsmZ3Q7 PGJyPgomZ3Q7ICZndDsmZ3Q7IFRoaXMgYWxzbyBoYXMgbXVsdGljYXN0IHByb2JsZW1zLCBhcyB0 aGVyZSBpcyBvbmx5IG9uZSBpbnN0YW5jZSBvZiBlYWNoPGJyPgomZ3Q7ICZndDsmZ3Q7IG11bHRp Y2FzdCBhZGRyZXNzIChHKSBpbiB0aGUgdW5kZXJsYXkgbmV0d29yay4mbmJzcDsgSSB0aGluayBJ IGNhbiBmaWd1cmUgb3V0PGJyPgomZ3Q7IGhvdzxicj4KJmd0Ozxicj4KJmd0OyBZb3UgY2FuIG1h cCBmcm9tIEVJRC1HIHRvIFJMT0MtRyBvbmUgdG8gb25lLiBCdXQgd2UgaGF2ZSBzZWVuIG92ZXIg dGhlIGxhc3Q8YnI+CiZndDsgZGVjYWRlIGluIGEgaGFsZiB0aGF0IHdpdGggZ2VuZXJhbCBtdWx0 aWNhc3QgZGVwbG95bWVudCB0aGF0IG1hbnktdG8tMSBpczxicj4KJmd0OyBkZXNpcmFibGUuIEhl bmNlLCBub3cgdGhhdCB3ZSBoYXZlIGEgd2F5IHRvIG1hcCB3aXRoIGEgbmV0d29yay1iYXNlZCBk YXRhYmFzZSw8YnI+CiZndDsgd2UgY2FuIG1hcCBtdWx0aXBsZSBFSUQtR3MgdG8gYSBzaW5nbGUg KG9yIG11bHRpcGxlKSBSTE9DLUdzLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyB0byBtYWtl IG11bHRpY2FzdCB3b3JrIGZvciB0aGlzIHVzZSBjYXNlLCBidXQgaXQncyBub3QgaW1tZWRpYXRl bHkgb2J2aW91cyw8YnI+CiZndDsgJmd0OyZndDsgYW5kIHRoZSByZXN1bHQgd2hlbiB0aGUgc2Ft ZSB1bmRlcmxheSBtdWx0aWNhc3QgYWRkcmVzcyBpcyB1c2VkIGJ5IG1vcmU8YnI+CiZndDsgJmd0 OyZndDsgdGhhbiBvbmUgVlBOIGNvdWxkIHdlbGwgZGVsaXZlciBzb21lIHRyYWZmaWMgdG8gRVRS cyB0aGF0IGhhdmUgdG8gZGlzY2FyZDxicj4KJmd0Ozxicj4KJmd0OyBUaGlzIGlzIGEgbmVjZXNz YXJ5IGV2aWwgd2hlbiB0aGUgdW5kZXJsYXkgaXMgc3RhdGUgY2hhbGxlbmdlZC4gQnV0IGl0IGlz IGE8YnI+CiZndDsgc3RhdGUvYmFuZHdpZHRoIHRyYWRlb2ZmLiBXZSBoYXZlIGZvdW5kIHdpdGgg TVZQTiBkZXBsb3ltZW50IHRoYXQgdGhlIG5ldHdvcms8YnI+CiZndDsgYWRtaW4gY29uZmlndXJl cyB0aGUgdW5kZXJseSBvciBzaW1wbHkgdW5pY2FzdHMuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsm Z3Q7IGl0IGJlY2F1c2UgdGhlIEluc3RhbmNlIElEIGlzIHdyb25nIChhbmQgdGhhdCBleGNlc3Np dmUgZGVsaXZlcnkgaXMgYTxicj4KJmd0OyAmZ3Q7Jmd0OyBzZWN1cml0eSBjb25zaWRlcmF0aW9u LCBzZWUgbWlub3IgaXNzdWUgb24gU2VjdGlvbiA4IGJlbG93KS4mbmJzcDsgSSB0aGluayBhbjxi cj4KJmd0OyAmZ3Q7Jmd0OyBleHBsYW5hdGlvbiBpcyBpbiBvcmRlci48YnI+CiZndDs8YnI+CiZn dDsgVGhlcmUgYXJlIGp1c3QgdG9vIG1hbnkgY29tYmluYXRpb25zIHRvIG1ha2UgYSBoaWdoLWxl dmVsIGRlc2NyaXB0aW9uIHNpbXBsZTxicj4KJmd0OyB0byB1bmRlcnN0YW5kLiBUaGUgY3VycmVu dCBpbnRyb2R1Y3Rpb24gdGV4dCBkb2VzIGEgZmluZCBqb2IgcHJvdmlkaW5nPGJyPgomZ3Q7IHJl ZmVyZW5jZXMgZm9yIHNvbWVvbmUgdG8gZ28gb2ZmIGFuZCBnZXQgdGhlIGRldGFpbHMuPGJyPgom Z3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0tIE1pbm9yIElzc3VlcyAtLTxicj4KJmd0OyAmZ3Q7Jmd0 Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBUaGVyZSBzZWVtcyB0byBiZSBhbiBpbXBsaWNpdCBhc3N1bXB0 aW9uIHRoYXQgdGhlIGVuZCBob3N0IGFuZCBpdHM8YnI+CiZndDsgJmd0OyZndDsgSVRSICh4VFIp IGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3IgQXV0b25vbW91cyBTeXN0ZW0uJm5ic3A7IEZvciBp bmNyZW1lbnRhbDxicj4KJmd0Ozxicj4KJmd0OyBUaGlzIGlzIHRydWUgd2hlbiB5b3UgY2FsbCB0 aGUgZG9tYWluIGEgIkxJU1Agc2l0ZSIuIEJ1dCBpZiB0aGUgc2l0ZSBpczxicj4KJmd0OyB1bmNo YW5nZWQgYW5kIG9uZSB1c2VzIFBJVFJzLCBtYXliZSBldmVuIGNsb3NlIHRvIHRoZSBzaXRlLCBs aWtlIGluIGEgUEU8YnI+CiZndDsgcm91dGVyLCB0aGVuIHRoZSBQSVRSIGlzIGRlZmluaXRlbHkg aW4gYW5vdGhlciBBUy4gQnV0IG5vdGUgSSBzYWlkIFBJVFIgYW5kPGJyPgomZ3Q7IG5vdCBJVFIu IFRoZSByZWFzb24gYmVpbmcgaXMgYmVjYXVzZSBhbiBJVFIgaXMgY29uZmlndXJlZCB3aXRoIGRh dGFiYXNlLTxicj4KJmd0OyBtYXBwaW5nIHByZWZpeGVzIHRoYXQgaXMgdXNlcyB0byBlbmNhcHN1 bGF0ZSBwYWNrZXRzIGZyb20gc3VjaCBhZGRyZXNzZXMuPGJyPgomZ3Q7IFZlcnN1cyB0aGUgUElU UiBiZWluZyBhbiBJVFIgd2l0aCAqbm8gZGF0YWJhc2UtbWFwcGluZ3MqIHByb3ZpZGluZyBhIG11 Y2ggbW9yZTxicj4KJmd0OyBsYXJnZXIvb3IgbW9yZSBhZ2dyZWd0YWJsZSBzZXJ2aWNlLjxicj4K Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBkZXBsb3ltZW50LCBJIGRvbid0IHRoaW5rIHRoYXQncyBh bHdheXMgdGhlIGNhc2UsIGJ1dCBJIHRoaW5rIHRoYXQgb25seTxicj4KJmd0OyAmZ3Q7Jmd0OyBo YXMgZWRpdG9yaWFsIGltcGFjdCBvbiB0aGlzIGRvY3VtZW50LCBhcyBJIGRvbid0IHRoaW5rIGFu eSBvZiB0aGU8YnI+CiZndDsgJmd0OyZndDsgZnVuZGFtZW50YWwgTElTUCBtZWNoYW5pc21zIGFy ZSBhZmZlY3RlZC4mbmJzcDsgVGhlIGF1dGhvcnMgc2hvdWxkIGxvb2sgZm9yPGJyPgomZ3Q7ICZn dDsmZ3Q7IHVzZSBvZiAiZG9tYWluIiBhbmQgIkF1dG9ub21vdXMgU3lzdGVtIiBhbmQgZW5zdXJl IHRoYXQgdGhlIHRleHQgaXM8YnI+CiZndDsgJmd0OyZndDsgZ2VuZXJhbGl6ZWQgdG8gdGhlIGNh c2Ugd2hlcmUgdGhlIGVuZCBob3N0IGFuZCBJVFIgYXJlIG1vcmUgd2lkZWx5PGJyPgomZ3Q7ICZn dDsmZ3Q7IHNlcGFyYXRlZC48YnI+CiZndDs8YnI+CiZndDsgV2UgYXJlIG92ZXJsb2FkZWQgd2l0 aCB0ZXJtcyB0aGF0IGNyZWF0ZSB0b3BvbG9naWNhbCBvciBvcmdhbml6YXRpb24gYm91bmRhcnku PGJyPgomZ3Q7IEhlbmNlIHdoeSB3ZSBjcmVhdGVkICJMSVNQIHNpdGUiIHdoaWNoIGlzIGFsc28g dGhlIHNhbWUgYXMgYSAiTElTUCBWUE4gc2l0ZSIuPGJyPgomZ3Q7IFdoZXJlIGEgIkxJU1Agc2l0 ZSIgdGhhdCBoYXMgbXVsdGlwbGUgdGVubmFudHMgd291bGQgYmUgbXVsdGlwbGUgIkxJU1AgVlBO PGJyPgomZ3Q7IHNpdGVzIi48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDsgRGVzcGl0ZSBtdWx0 aXBsZSZuYnNwOyBtZW50aW9ucyBvZiBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LCBJIGRpZCBub3Q8 YnI+CiZndDsgJmd0OyZndDsgc2VlIGEgZGlzY3Vzc2lvbiBvZiBob3cgdGhhdCBtaWdodCBiZSBh Y2NvbXBsaXNoZWQuJm5ic3A7IFRoZXJlIGlzIHNvbWU8YnI+CiZndDs8YnI+CiZndDsgVGhlcmUg YXJlIFB4VFJzIGFuZCBOQVRzLiBBbmQgcmVmZXJlbmNlcyB0byB0aGUgTElTUCBpbnRlcndvcmtp bmcgUkZDLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyB1c2VmdWwgY29udGVudCBpbiBTZWN0 aW9uIDMuNSwgYnV0IHRoYXQncyBhdCBiZXN0IGFuIGluY29tcGxldGU8YnI+CiZndDsgJmd0OyZn dDsgZXhwbGFuYXRpb24uJm5ic3A7IFRoaXMgaXMgYW4gT1BTLURpciByZXZpZXcgY29uY2VybiAt IGl0IGZhbGxzIHVuZGVyPGJyPgomZ3Q7ICZndDsmZ3Q7IEEuMS4zIGluIEFwcGVuZGl4IEEgb2Yg UkZDIDU3MDY6IEhhcyB0aGUgbWlncmF0aW9uIHBhdGggYmVlbiBkaXNjdXNzZWQ/PGJyPgomZ3Q7 ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0gMy4zLjEuJm5ic3A7IExJU1AgRW5jYXBzdWxh dGlvbjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhl IHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkIGJ5PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyB0aGUgSVRSIGFuZCBpZ25vcmVkIG9uIHJlY2VwdGlvbi48YnI+CiZndDsgJmd0OyZndDs8YnI+ CiZndDsgJmd0OyZndDsgUGxlYXNlIG1lbnRpb24gbXVsdGlwYXRoaW5nIChlLmcuLCBFQ01QIGFu ZCBMQUcpIGFzIHBvc3NpYmxlIGluZmx1ZW5jZXM8YnI+CiZndDsgJmd0OyZndDsgb24gaG93IHNv dXJjZSBwb3J0cyBhcmUgc2VsZWN0ZWQsIGFzIHRoaXMgaW1wb3NlcyBzb21lIGxpbWl0cyBvbiB3 aGF0IGFuPGJyPgomZ3Q7ICZndDsmZ3Q7IElUUiBjYW4gcmVhc29uYWJseSBkby48YnI+CiZndDs8 YnI+CiZndDsgRUNNUC9MQUcgZG9uJ3QgaW5mbHVlbmNlIHdoaWNoIHNvdXJjZSBwb3J0IGlzIHNl bGVjdGVkLiBJdCBpcyBhIDUtdHVwbGUgaGFzaDxicj4KJmd0OyBvZiB0aGUgaW5uZXIgaGVhZGVy IHRoYXQgc2VsZWN0cyBhIHNvdXJjZSBwb3J0IHRoYXQgaW5mbHVlbmNlcyBob3cgYW4gdW5kZXJs YXk8YnI+CiZndDsgcm91dGVyIHdvdWxkIGxvYWQtc3BsaXQgdHJhZmZpYy48YnI+CiZndDs8YnI+ CiZndDsgJmd0OyZndDsgRm9yIE9QUy1EaXIsIHRoaXMgbXVsdGlwYXRoaW5nIGNvbmNlcm4gZmFs bHMgdW5kZXIgQS4xLjQgaW4gQXBwZW5kaXggQSBvZjxicj4KJmd0OyAmZ3Q7Jmd0OyBSRkMgNTcw NjogSGF2ZSB0aGUgUmVxdWlyZW1lbnRzIG9uIG90aGVyIHByb3RvY29scyBhbmQgZnVuY3Rpb25h bDxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb21wb25lbnRz IGJlZW4gZGlzY3Vzc2VkPzxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgVGhpcyBkZWNpc2lvbiB3YXMgbWFkZSBiZWNhdXNlIHRoZTxicj4KJmd0OyAmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgdHlwaWNhbCB0cmFuc3BvcnQgcHJvdG9jb2xzIHVzZWQgYnkgdGhl IGFwcGxpY2F0aW9ucyBhbHJlYWR5IGluY2x1ZGU8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5i c3A7IGEgY2hlY2tzdW0sIGJ5IG5lZ2xlY3RpbmcgdGhlIGFkZGl0aW9uYWwgVURQIGVuY2Fwc3Vs YXRpb24gY2hlY2tzdW08YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHhUUnMgY2FuIGZv cndhcmQgcGFja2V0cyBtb3JlIGVmZmljaWVudGx5Ljxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0 OyAmZ3Q7Jmd0OyBHcm9hbiEmbmJzcDsgSSBoYXZlIGFuIGV4cXVpc2l0ZSBzZXQgb2Ygc2NhcnMg b24gVURQIHplcm8gY2hlY2tzdW1zIGZvciBJUHY2PGJyPgomZ3Q7ICZndDsmZ3Q7IGZyb20gd29y a2luZyBvbiB0aGUgTVBMUyBpbiBVRFAgZHJhZnQsIHNvIEkgbWF5IGJlIG92ZXJseSBzZW5zaXRp dmUgdG88YnI+CiZndDsgJmd0OyZndDsgdGhpcyBjb25jZXJuLiZuYnNwOyBUaGUgZG93bnNpZGUg b2YgdGhpcyBlZmZpY2llbmN5IGlzIHRoYXQgdGhlcmUgaXMgbm88YnI+CiZndDsgJmd0OyZndDsg Y2hlY2tzdW0gY292ZXJhZ2Ugb2YgdGhlIElQdjYgaGVhZGVyIHdoZW4gemVybyBVRFAgY2hlY2tz dW1zIGFyZSB1c2VkLjxicj4KJmd0OyAmZ3Q7Jmd0OyBUaGF0IHNob3VsZCBhdCBsZWFzdCBiZSBt ZW50aW9uZWQgaGVyZSwgd2l0aCBhIHN1bW1hcnkgb2Ygd2h5IHRoYXQncyBvazxicj4KJmd0OyAm Z3Q7Jmd0OyAtIHRoZSBkZXRhaWxlZCBqdXN0aWZpY2F0aW9uIGZvciB3aHkgdGhhdCdzIG9rIGNh biBiZSBsZWZ0IHRvIG90aGVyPGJyPgomZ3Q7ICZndDsmZ3Q7IGRvY3VtZW50cy48YnI+CiZndDs8 YnI+CiZndDsgTXkgaGVhZCBzcGlucyBldmVyeSB0aW1lIEkgaGVhciBhYm91dCB0aGlzIHN1Ympl Y3QuIFRoaXMgc3ViamVjdCBoYXMgYmVlbjxicj4KJmd0OyB0YWxrZWQgYWJvdXQgZnJvbSAxMDBz IG9mIHBlb3BsZSBmb3IgYSBkZWNhZGUuIFdlIGhhdmUgQ1JDIG9uIGxpbmtzLCB3ZSBoYXZlPGJy PgomZ3Q7IGFwcHMgdGhhdCB1c2UgVENQIGFuZCBVRFAgY2hlY2tzdW1zLiBOdWYgc2FpZC48YnI+ CiZndDs8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgLS0gTml0cy9FZGl0b3Jp YWwgQ29tbWVudHMgLS08YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgLSBUb3Ag b2YgcC40Ojxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg VGhlIGluaXRpYWwgbW90aXZhdGlvbiBpbiB0aGUgTElTUCBlZmZvcnQgaXMgdG8gYmUgZmluZCBp biB0aGU8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgImZpbmQiIC0mZ3Q7ICJm b3VuZCI8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgLSBTZWN0aW9uIDMuMSwg Zmlyc3QgYnVsbGV0IGl0ZW08YnI+CiZndDs8YnI+CiZndDsgV2Ugd2lsbCBjZXJ0YWlubHkgZml4 ZSB0aGVzZS4gVGhhbmtzLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RldmljZXMgYXJlIGFzc2lnbmVkIHdpdGgg cmVsYXRpdmVseSBvcGFxdWUgaWRlbnRpdHk8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDttZWFuaW5nZnVsIGFkZHJlc3NlcyB0aGF0IGFyZSBpbmRlcGVuZGVudCBv ZiB0aGVpciB0b3BvbG9naWNhbDxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2xvY2F0aW9uLjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBJIGRv bid0IHVuZGVyc3RhbmQgInJlbGF0aXZlbHkgb3BhcXVlIGlkZW50aXR5IG1lYW5pbmdmdWwiIGFu ZDxicj4KJmd0OyAmZ3Q7Jmd0OyBzdWdnZXN0IHJld3JpdGluZyB0aGUgc2VudGVuY2UuJm5ic3A7 IEluIHBhcnRpY3VsYXIgLSBvcGFxdWUgdG8gd2hhdD88YnI+CiZndDsgJmd0OyZndDsgbWVhbmlu Z2Z1bCB0byB3aGF0IGluIHdoYXQgbWFubmVyPzxicj4KJmd0Ozxicj4KJmd0OyBXZWxsIGJlYWN1 c2UgaXQgaXMgYXMgYWNjdXJhdGUgYXMgaXQgY2FuIGJlLiBJZiBhdXRvbW9iaWxlcyBhcmUgZ29p bmcgdG8gYmU8YnI+CiZndDsgYXNzaWduZWQgRUlEcyBmcm9tIGEgVklOIG51bWJlciBhbGxvY2F0 aW9uIGZyb20gYSBtYW51ZmFjdHVyZSwgdGhlIGFkZHJlc3MgaXM8YnI+CiZndDsgcmVsYXRpdmVs eSBvcGFxdWUuIElmIGEgVk0gaW4gYSBkYXRhLWNlbnRlciBpcyBnb2luZyB0byBiZSBhc3NpZ25l ZCBhbiBFSUQ8YnI+CiZndDsgZnJvbSB0aGUgc2V0IG9mIHByZWZpeGVzIGFscmVhZHkgYmVpbmcg dXNlZCBhbmQgYWxsb2NhdGVkIHRvIHRoYXQgZGF0YS1jZW50ZXIsPGJyPgomZ3Q7IHRoZW4gdGhl cmUgaXMgYSBnb29kIGNoYW5jZSB0aGF0IGFkZHJlc3MgaXMgaW4gYSBwb3dlci1vZi0yIGJsb2Nr IHRoYXQgaXM8YnI+CiZndDsgc3VtbWFyaXphYmxlIGluIHRoZSBJR1AuPGJyPgomZ3Q7PGJyPgom Z3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0gU2VjdGlvbiAzLjIsIHNlY29uZCBwYXJh Z3JhcGg8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgSnVkZ2luZyBmcm9tIHRo ZSBmaWd1cmUsIHhUUnMgYXJlIHRoZSBjb21tb24gY2FzZSwgd2l0aCBzaW5nbGUtPGJyPgomZ3Q7 ICZndDsmZ3Q7IGZ1bmN0aW9uIElUUnMgYW5kIEVUUnMgYmVpbmcgcmFyZS4mbmJzcDsgSXQgbWln aHQgYmUgZ29vZCB0byBzYXkgdGhhdDxicj4KJmd0OyAmZ3Q7Jmd0OyBhbmQgZGlzY3VzcyB3aGVu IElUUnMgYW5kIEVUUnMgdGhhdCBhcmUgbm90IHhUUnMgYXJlIGFwcHJvcHJpYXRlPGJyPgomZ3Q7 ICZndDsmZ3Q7IHRvIHVzZS48YnI+CiZndDs8YnI+CiZndDsgV2hlbiB5b3Ugd2FudCBlZ3Jlc3Mg cGF0aCBzZWxlY3Rpb24gdG8gaGFwcGVuIGZ1cnRoZXIgb3V0IGluIHRoZSB0b3Bsb2dpY2FsPGJy PgomZ3Q7IGZyb20gdGhlIHNvdXJjZSBsb2NhdGlvbiwgdGhlbiB5b3UgcHV0IGFuIElUUi1vbmx5 IHN5c3RlbSB0aGVyZS4gV2hlcmUgaW5ncmVzczxicj4KJmd0OyB0byB0aGUgc2FtZSBzb3VyY2Ug KGRlc3RpbmF0aW9uIGluIHRoaXMgZGlyZWN0aW9uKSwgdGhlIEVUUiBjYW4gYmUgY2xvc2VyIHRv PGJyPgomZ3Q7IHRoZSBkZXN0aW5hdGlvbi48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDs8YnI+ CiZndDsgJmd0OyZndDsgLSAzcmQgcGFyYWdyYXBoIG9uIHAuNzo8YnI+CiZndDsgJmd0OyZndDs8 YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IEZpbmFsbHks IHRoZSBMSVNQIGFyY2hpdGVjdHVyZSBlbXBoYXNpemVzIGEgY29zdCBlZmZlY3RpdmU8YnI+CiZn dDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IGluY3JlbWVudGFsIGRlcGxveW1lbnQuPGJyPgomZ3Q7 ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEknZCBkZWxldGUgImNvc3QgZWZmZWN0aXZlIiBo ZXJlIGFuZCBsb29rIGZvciBvdGhlciBvY2N1cnJlbmNlczxicj4KJmd0OyAmZ3Q7Jmd0OyBvZiAi Y29zdCIgYXMgY2FuZGlkYXRlcyBmb3IgZGVsZXRpb24uJm5ic3A7IFRoaXMgaXMgc3VwcG9zZWQg dG8gYmU8YnI+CiZndDsgJmd0OyZndDsgYSB0ZWNobmljYWwgZG9jdW1lbnQsIHNvIGRpc2N1c3Np b24gb2YgY29zdHMgaXMgYSBiaXQgb2ZmLXRhcmdldC48YnI+CiZndDs8YnI+CiZndDsgRmFpciBl bm91Z2guPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0gRmlyc3QgaXRlbSBhZnRlciBGaWd1 cmUgMjo8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IDEu Jm5ic3A7IEhvc3RBIHJldHJpZXZlcyB0aGUgRUlEX0Igb2YgSG9zdEIsIHR5cGljYWxseSBxdWVy eWluZyB0aGUgRE5TPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGFuZCBvYnRhaW5pbmcgYW5kIEEgb3IgQUFBQSByZWNvcmQuPGJyPgomZ3Q7ICZndDsmZ3Q7PGJy PgomZ3Q7ICZndDsmZ3Q7ICJhbmQgQSIgLSZndDsgImFuIEEiJm5ic3A7IChzcGVsbGluZyBjaGVj a2VycyBkb24ndCBjYXRjaCBldmVyeXRoaW5nKS48YnI+CiZndDs8YnI+CiZndDsgQWxyZWFkeSBu b3RlZCBhbmQgd2lsbCBiZSBmaXhlZC48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZn dDsgJmd0OyZndDsgLSAzLjMuMS4mbmJzcDsgTElTUCBFbmNhcHN1bGF0aW9uPGJyPgomZ3Q7ICZn dDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBPbiB0aGUgb3RoZXIgaGFuZCwg UmVjdXJzaXZlPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0dW5uZWxzIGFyZSBuZXN0 ZWQgdHVubmVscyBhbmQgYXJlIGltcGxlbWVudGVkIGJ5IHVzaW5nIG11bHRpcGxlIExJU1A8YnI+ CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IGVuY2Fwc3VsYXRpb25zIG9uIGEgcGFja2V0Ljxi cj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBUaGUgYWJvdmUgc2VudGVuY2Ugc2Vl bXMgb3V0IG9mIHBsYWNlIGluIHRoZSBtaWRkbGUgb2YgYSBwYXJhZ3JhcGggYWJvdXQ8YnI+CiZn dDsgJmd0OyZndDsgUmUtZW5jYXBzdWxhdGluZyB0dW5uZWxzIGFuZCByb3V0ZXJzIC0gSSBzdWdn ZXN0IG1vdmluZyBpdCBkb3duIGludG8gaXRzPGJyPgomZ3Q7ICZndDsmZ3Q7IG93biBwYXJhZ3Jh cGggYW5kIHBlcmhhcHMgYWRkaW5nIGEgc2VudGVuY2UgYWJvdXQgd2hlcmUvaG93IFJlY3Vyc2l2 ZTxicj4KJmd0OyAmZ3Q7Jmd0OyB0dW5uZWxzIG1heSBiZSB1c2VmdWwuPGJyPgomZ3Q7PGJyPgom Z3Q7IEdvb2Qgc3VnZ2VzdGlvbiBhbmQgbWFrZXMgc2Vuc2UuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZn dDsmZ3Q7IC0gMy4zLjIuJm5ic3A7IExJU1AgRm9yd2FyZGluZyBTdGF0ZTxicj4KJmd0OyAmZ3Q7 Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgSW4gdGhlIExJU1AgYXJjaGl0ZWN0 dXJlLCBJVFJzIGtlZXAganVzdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gcm91dGU8YnI+CiZndDsg Jmd0OyZndDsmbmJzcDsgJm5ic3A7IHRyYWZmaWMgZmxvd2luZyB0aHJvdWdoIGl0Ljxicj4KJmd0 OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAiaXQuIiAtJmd0OyAidGhlbS4iPGJyPgomZ3Q7 ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBNZWFuaW5nIHRoYXQsIElU UnMgcmV0cmlldmUgZnJvbSB0aGU8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IExJU1Ag TWFwcGluZyBTeXN0ZW0gbWFwcGluZ3MgYmV0d2VlbiBFSUQgcHJlZml4ZXMgYW5kIFJMT0NzIHRo YXQgYXJlPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB1c2VkIHRvIGVuY2Fwc3VsYXRl IHBhY2tldHMuPGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IFRoaXMgaXMgdGhl IGZpcnN0IHVzZSBvZiB0aGUgbm90aW9uIG9mIEVJRCBwcmVmaXhlcy4mbmJzcDsgVGhhdCBjb25j ZXB0IHNob3VsZDxicj4KJmd0OyAmZ3Q7Jmd0OyBiZSBleHBsYWluZWQgYmVmb3JlIGl0IGlzIHVz ZWQsIGFsdGhvdWdoIGEgZm9yd2FyZCByZWZlcmVuY2UgdG8gc2VjdGlvbjxicj4KJmd0OyAmZ3Q7 Jmd0OyAzLjQuMSBtYXkgc3VmZmljZS4mbmJzcDsgSXQgbWlnaHQgYmUgYmV0dGVyIHRvIHJld3Jp dGUgdGhpcyBwYXJhZ3JhcGggaW4gdGVybXM8YnI+CiZndDsgJmd0OyZndDsgb2YgRUlEcyBhbmQg bGVhdmUgdGhlIG5vdGlvbiBvZiBFSUQgcHJlZml4ZXMgdG8gc2VjdGlvbiAzLjQuMS48YnI+CiZn dDs8YnI+CiZndDsgSG1tLCBJJ2xsIGxldCBBbGJlcnQgYW5kIERhbWllbiBkZWNpZGUgaWYgd2Ug c2hvdWxkIHN0YXRlICJFSUQtcHJlZml4ZXMiPGJyPgomZ3Q7IGV2ZXJ5d2hlcmUgaW5zdGVhZCBv ZiBqdXN0ICJFSUQiLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0 OyAtIDQuNC4mbmJzcDsgTVRVIEhhbmRsaW5nPGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyBBZGRpdGlvbmFsbHksIExJU1AgYWxzbyByZWNvbW1lbmRzIGlu ZmVycmluZyByZWFjaGFiaWxpdHkgb2YgbG9jYXRvcnM8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsg Jm5ic3A7IGJ5IHVzaW5nIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSB1bmRlcmxheSwgaW4g cGFydGljdWxhcjo8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgSXQnZCBiZSB1 c2VmdWwgdG8gYWRkIGEgc2VudGVuY2Ugb3IgdHdvIGFib3V0IGhvdyBMSVNQIGFuZCB0aGUgdGVj aG5pcXVlczxicj4KJmd0OyAmZ3Q7Jmd0OyBpbiB0aGlzIHNlY3Rpb24gaW50ZXJhY3Qgd2l0aCBo b3N0IHVzZSBvZiBQTVRVRCBhbmQgUExQTVRVRC48YnI+CiZndDs8YnI+CiZndDsgVGhpcyBpcyBh IGxvdCBvZiBkZXRhaWwgYmVjYXVzZSBpbiBSRkM2ODMwIHdlIGhhdmUgMyBwb3NpdGlvbnMgb3Ig b3B0aW9ucyBvbjxicj4KJmd0OyB0aGUgc3ViamVjdC4gQW5kIHdlIGRpZCBwcm92aWRlIGEgcmVm ZXJlbmNlIHRvIFJGQzY4MzAgZm9yIHRoaXMgdG9waWMuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsm Z3Q7IC0gTmV4dCB0byBsYXN0IHBhcmFncmFwaCBvbiBwLjE3Ojxicj4KJmd0OyAmZ3Q7Jmd0Ozxi cj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgQWRkaXRpb25hbGx5LCBMSVNQIGFsc28gcmVj b21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmlsaXR5IG9mIGxvY2F0b3JzPGJyPgomZ3Q7ICZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyBieSB1c2luZyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgdW5k ZXJsYXksIGluIHBhcnRpY3VsYXI6PGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7 IFRoaXMgbG9va3MgbGlrZSBpdCdzIGEgcGFyYWdyYXBoIGVhcmx5IGFuZCBuZWVkcyB0byBiZSBt b3ZlZCBkb3duIHRvPGJyPgomZ3Q7ICZndDsmZ3Q7IGFmdGVyIHRoZSBwYXJhZ3JhcGggdGhhdCBm b2xsb3dzIGl0Ljxicj4KJmd0Ozxicj4KJmd0OyBBZ3JlZS48YnI+CiZndDs8YnI+CiZndDsgJmd0 OyZndDsgaWRuaXRzIDIuMTMuMDEgZGlkbid0IGZpbmQgYW55IG5pdHMuPGJyPgomZ3Q7ICZndDsm Z3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IFRoYW5rcyw8YnI+CiZndDsgJmd0OyZndDsgLS1EYXZpZDxi cj4KJmd0Ozxicj4KJmd0OyBUaGFua3MgYWdhaW4gRGF2aWQuPGJyPgomZ3Q7PGJyPgomZ3Q7IERp bm88bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjwvZGl2PgoKIDwv Ym9keT4= ----_com.android.email_125122668737117-- From nobody Wed Feb 11 16:29:53 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C1E1A6F28; Wed, 11 Feb 2015 16:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 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, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK93fMFpzsQp; Wed, 11 Feb 2015 16:29:39 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFC91A1EEF; Wed, 11 Feb 2015 16:29:38 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1C0TVL7003257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 19:29:32 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t1C0TVL7003257 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423700973; bh=LpKpCz0r81XvShgHaSetsAOOtXI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=wVKjY/aCH9tbPLCd6EIhWnqmi1Ksu0kdY2csLjAGFnyfKNmlthRPCjodCqC6SorTt ovBOiUxpQ9XuRjZlVxdR3uA0v+uxrE1MsVPtpHkw8fvNsfs9tcWxonJNPFmagFF7pZ Mf30SmBi0MP2vAg/i9HTBiym6HXz432xi57+ZntM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t1C0TVL7003257 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 11 Feb 2015 19:29:14 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1C0TGui021866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 19:29:16 -0500 Received: from MXHUB201.corp.emc.com (10.253.68.27) by mxhub19.corp.emc.com (10.254.93.48) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 11 Feb 2015 19:29:15 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB201.corp.emc.com ([10.253.68.27]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 19:29:15 -0500 From: "Black, David" To: "Jmh.direct" , "acabello@ac.upc.edu" Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 Thread-Index: AQHQRll3swN7n7S2Sw+GOUWYxLLMypzsJ58w Date: Thu, 12 Feb 2015 00:29:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493636438EMX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , "damien.saucez@inria.fr" , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 00:29:49 -0000 --_000_CE03DB3D7B45C245BCA0D2432779493636438EMX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJbiB0aGUgVk0gY2FzZSwgYW0gZW50aXJlIHNlcnZpY2UgbmV0d29yayBtYXkgYmUgbW92ZWQg dG8gdGhlIGRhdGEgY2VudGVyLCBhbmQgc28gdGhlIEVJRCBibG9jayBmb3IgdGhhdCBzZXQgY2Fu IGJlIG1vdmVkLg0KDQpGb3IgYSBzaW5nbGUgVk0sIHRoYXQgd291bGQgYXBwbHkgaWYgdGhlIFZN IGlzIHVzaW5nIGFuIGVudGlyZSBFSUQgYmxvY2sgLSBtb3N0IGluZGl2aWR1YWwgVk1zIGFyZW7i gJl0L2RvbuKAmXQuICBJbmRpdmlkdWFsIC8zMiBhbmQgLzEyOCBhZGRyZXNzZXMgYXJlIGNvbW1v biBmb3IgaW5kaXZpZHVhbCBWTXMsIHNvIHRoYXTigJlzIHdoYXTigJlzIG5lZWRlZCBpbiBnZW5l cmFsIGZvciBpbmRpdmlkdWFsIFZNIG1vdmVtZW50Lg0KDQpJ4oCZZCBleHBlY3QgdGhlIEVJRCBi bG9jayBtb3ZlIGNhc2UgdG8gYXBwbHkgZm9yIG1vdmVtZW50IG9mIGEgZ3JvdXAgb2YgVk1zIHRo YXQgYXJlIHVzaW5nIHN1Y2ggYSBibG9jayAoZS5nLiwgYXMgYSBzdWJuZXQpLCBidXQgVk0gbGl2 ZSBtaWdyYXRpb25zIGNhbm5vdCBiZSBzeW5jaHJvbml6ZWQgaW4gZ2VuZXJhbCAoY29sZCBtaWdy YXRpb25zIG9mIHBvd2VyZWQtb2ZmIFZNcyBjYW4gYmUsIG9idmlvdXNseSksIHNvIGV2ZW4gaW4g dGhpcyBjYXNlIHdoZXJlIHRoZSBlbnRpcmUgRUlEIGJsb2NrIG1vdmVzLCBpZiBsaXZlIFZNIG1p Z3JhdGlvbnMgYXJlIGludm9sdmVkLCB0aGVyZSBhcmUgaW50ZXJtZWRpYXRlIHN0YWdlcyB3aGVy ZSB0aGUgRUlEIGJsb2NrIGlzIHNwbGl0IGJldHdlZW4gTElTUCBzaXRlcyAuLi4gYW5kIGhlbmNl IC8zMiBhbmQgLzEyOCBwcmVmaXhlcyBhcmUgc3RpbGwgd2hhdOKAmXMgd2FudGVkLg0KDQpUaGFu a3MsDQotLURhdmlkDQoNCkZyb206IEptaC5kaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxo YWxwZXJuLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMTUgNzoxOSBQTQ0K VG86IEJsYWNrLCBEYXZpZDsgYWNhYmVsbG9AYWMudXBjLmVkdQ0KQ2M6IGZhcmluYWNjaUBnbWFp bC5jb207IGptaEBqb2VsaGFscGVybi5jb207IGRhbWllbi5zYXVjZXpAaW5yaWEuZnI7IG9wcy1k aXJAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBb bGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMQ0K SW1wb3J0YW5jZTogTG93DQoNCkkgdGhpbmwgd2UgbWF5IHdhbnQgdG8gc2VwYXJhdGUgVk0gbW9i aWxpdHkgZnJvbSBtb2JpbGUgZGV2aWNlcy4gIE9tIHRoZSBWTSBjYXNlLCBhbSBlbnRpcmUgc2V0 dmljZSBuZXR3b3JrIG1heSBiZSBtb3ZlZCB0byB0aGUgZGF0YSBjZW50ZXIsIGFuZCBzbyB0aGUg RUlEIGJsb2NrIGZvciB0aGF0IHNldCBjYW4gYmUgbW92ZWQuICBJbiB0aGUgY2FzZSBvZiBpbmRp dmlkdWFsbHkgbW9iaWxlIGRlYmljZXMgb3Igc29tZSB2YXRpYXRpb25zIG9uIGRhdGEgY2VudGVy IG1vYmlsaXR5LCB0aGVyZSBpcyBhIG5lZWQgdG8gbXNrZSBzdXJlIHRoZSBmdWxsIEVJRCBpcyBh ZHZlcnRpc2VkIGluIHRoZSBtYXBwaW5nIHN5c3RlbS4NCg0KWW91cnMsDQpKb2VsDQoNCg0KU2Vu dCBmcm9tIG15IFNhbXN1bmcgc21hcnRwaG9uZSBvbiBBVCZUDQoNCg0KDQotLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0OiBSRTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTENCkZyb206ICJCbGFjaywgRGF2aWQi IDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4NClRvOiAi YWNhYmVsbG9AYWMudXBjLmVkdTxtYWlsdG86YWNhYmVsbG9AYWMudXBjLmVkdT4iIDxhY2FiZWxs b0BhYy51cGMuZWR1PG1haWx0bzphY2FiZWxsb0BhYy51cGMuZWR1Pj4NCkNDOiBEaW5vIEZhcmlu YWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbTxtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbT4+LCJK b2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPj4sRGFtaWVuIFNhdWNleiA8ZGFtaWVuLnNhdWNlekBpbnJpYS5mcjxtYWlsdG86ZGFt aWVuLnNhdWNlekBpbnJpYS5mcj4+LCJvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGll dGYub3JnPiIgPG9wcy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+PiwiaWV0 ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4iIDxpZXRmQGlldGYub3JnPG1haWx0bzpp ZXRmQGlldGYub3JnPj4sImxpc3BAaWV0Zi5vcmc8bWFpbHRvOmxpc3BAaWV0Zi5vcmc+IiA8bGlz cEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4+LCJCbGFjaywgRGF2aWQiIDxkYXZpZC5i bGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4NCg0KSGkgQWxiZXJ0LA0K DQpBcyBub3RlZCBiZWxvdywgb24gdGhlIEVJRCBwcmVmaXggZm9yIG1vYmlsaXR5IGlzc3VlLCBh IHNpbXBsZSBzdGF0ZW1lbnQgaW4gU2VjdGlvbiA1IHRvIHRoZSBlZmZlY3QgdGhhdCDigJxpbiB0 aGUgc3BlY2lmaWMgY2FzZSBvZiBhIFZNL21vYmlsZSBub2RlIHRoZSBFSUQtcHJlZml4IHNob3Vs ZCBiZSAvMzIgb3IgLzEyOCAoSVB2NCBvciBJUHY2IHJlc3BlY3RpdmVseSnigJ0gd2lsbCBzdWZm aWNlLiAgRGV0YWlscyBvbiB3aGF0IHRvIGRvIHdoZW4gdGhhdCBhZHZpY2UgaXMgaWdub3JlZCBj YW4gYmUgbGVmdCB0byBvdGhlciBkb2N1bWVudHMuDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KRnJv bTogQWxiZXJ0IENhYmVsbG9zIFttYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdtYWlsLmNvbV0NClNl bnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMTUgNjozMyBQTQ0KVG86IEJsYWNrLCBEYXZp ZA0KQ2M6IERpbm8gRmFyaW5hY2NpOyBKb2VsIE0uIEhhbHBlcm47IERhbWllbiBTYXVjZXo7IG9w cy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBpZXRmQGlldGYub3JnPG1h aWx0bzppZXRmQGlldGYub3JnPjsgbGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWlu dHJvZHVjdGlvbi0xMQ0KDQpIaSBEYXZpZA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIEkg YW0gcGFyc2luZyB0aGVtIGFuZCBJwrRsbCBzdWdnZXN0IG5ldyB0ZXh0IGFpbWluZyB0byBhZGRy ZXNzIHRoZW0gQVNBUC4NCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3RhbmQg W0FdIGJlZm9yZSBkb2luZyB0aGlzLg0KDQpXaXRoIExJU1AgYW4gRUlELXByZWlmeCBjYW4gaGF2 ZSBhbiBhcmJpdHJhcnkgbGVuZ3RoIGFuZCBjYW4gbW92ZSAoaS5lLiwgY2hhbmdlIGl0cyBSTE9D IGJpbmRpbmdzKSwgaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgYSBWTS9tb2JpbGUgbm9kZSB0aGUg RUlELXByZWZpeCBzaG91bGQgYmUgLzMyIG9yIC8xMjggKElQdjQgb3IgSVB2NiByZXNwZWN0aXZl bHkpLiBXaGF0IGRvZXNuJ3Qgd29yayBpcyB0aGUgbW9iaWxpdHkgb2YgYSBub2RlIChhc3NpZ25l ZCB3aXRoIGEgLzMyIG9yIC8xMjgpICp3aXRoaW4qIGEgY29hcnNlciBFSUQtcHJlZml4LCBpbiB0 aGlzIGNhc2UgeW91IG5lZWQgdG8gc3BsaXQgdGhlIHByZWZpeCBpbnRvIG1vcmUgc3BlY2lmaWNz IGFuZCByZWdpc3RlciB0aGVtIGluZGVwZW5kZW50bHkgaW4gdGhlIE1hcHBpbmcgU3lzdGVtLCBl ZmZlY3RpdmVseSBjcmVhdGluZyBuZXcgRUlELXByZWZpeGVzLg0KDQpQbGVhc2UgbGV0IG1lIGtu b3cgaWYgdGhpcyBjbGFyaWZpZXMgeW91ciBjb21tZW50LCBpbiB0aGlzIGNhc2UgSSB3aWxsIHN1 Z2dlc3QgbmV3IHRleHQgZm9yIFNlY3Rpb24gNS4NCg0KQWxiZXJ0DQoNCg0KDQpPbiBUaHUsIEZl YiAxMiwgMjAxNSBhdCAxMjowNyBBTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29t PG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4gd3JvdGU6DQpEaW5vIC0gdGhhbmtzIGZvciB0 aGUgcmVzcG9uc2UuDQoNCk9uIHRoZSBtYWpvciBpc3N1ZXMsIGl0IGxvb2tzIGxpa2UgYm90aCBb QV0gYW5kIFtCXSBpbnZvbHZlIG9ubHkgdGhlIHRleHQNCmluIHRoaXMgZHJhZnQgYW5kIG5vdGhp bmcgYmV5b25kLCB3aGljaCBpcyBnb29kIG5ld3MuICBJIGhhdmUgYSBzaW1wbGUgdGV4dA0Kc3Vn Z2VzdGlvbiBmb3IgW0FdLCBidXQgaXQgbG9va3MgbGlrZSBbQl0gaXMgZ29pbmcgdG8gcmVxdWly ZSBzb21lIGNhcmVmdWwNCmVkaXRpbmcsIGFzIG9uZSBvZiB0aGUgcHJpbWFyeSBjYXVzZXMgaXMg dGhhdCB0aGUgZHJhZnQgaXMgc2xvcHB5IGluIHVzaW5nDQp0aGUgc2FtZSBzeW1ib2wgIkciIHRv IHJlcHJlc2VudCBib3RoIEVJRCBhbmQgUkxPQyBtdWx0aWNhc3QgZ3JvdXBzLg0KDQpPbiB0aGUg bWlub3IgaXNzdWVzLCBJIGhhdmUgdGV4dCBzdWdnZXN0aW9ucyBmb3IgdGhyZWUgb2YgdGhlIGZv dXIsIGFuZA0KSSdkIGxpa2UgdG8gdGVtcG9yYXJpbHkgZGVmZXIgZnVydGhlciBkaXNjdXNzaW9u IHRoZSBJUHY2IFVEUCB6ZXJvDQpjaGVja3N1bSAidGFycGl0IiBpbiBmYXZvciBvZiByZXNvbHZp bmcgZXZlcnl0aGluZyBlbHNlIGZpcnN0Lg0KDQpPbiB0aGUgbml0cy9lZGl0b3JpYWwgY29tbWVu dHMsIGFsbCB0aGUgc3VnZ2VzdGlvbnMgaW4geW91ciBlbWFpbCBhcmUgZmluZQ0Kd2l0aCBtZS4g IEZXSVcsIEkgcmVnYXJkIHRoYXQgcG9ydGlvbiBvZiBhIHJldmlldyBhcyBhbG1vc3QgZW50aXJl bHkNCnN1YmplY3QgdG8gdGhlIGRyYWZ0IGF1dGhvcnMnIGRpc2NyZXRpb24gKGFuZCBlZGl0b3Jp YWwgdGFzdGUpLg0KDQo+ID4+IFtBXSBFSUQgbW9iaWxpdHkgdnMuIEVJRCBwcmVmaXhlcw0KPg0K PiAuLi4gZnJvbSB0aGUgc3RhcnQgb2YgdGhlIExJU1AgZGVzaWduIChjaXJjYSAyMDA3KSwgYW4g cHJlZml4IGlzIHdoYXQgbW92ZXMuDQo+IEFuZCBhIHNwZWNpZmljIEVJRCBpcyBzaW1wbHkgYSAv MzIgb3IgLzEyOCBwcmVmaXguIEhlcmUgaXMgYSBwcmFjdGljYWwNCj4gZXhhbXBsZToNCg0KQSBz dGF0ZW1lbnQgdGhhdCB0aGUgbW9iaWxpdHkgdXNlIGNhc2VzIG5lZWQgdG8gZW1wbG95IC8zMiBh bmQgLzEyOCBwcmVmaXhlcywNCmFuZCBub3QgYW55dGhpbmcgY29hcnNlciBzaG91bGQgc3VmZmlj ZS4gIFRoYXQgc2hvdWxkIGJlIGFkZGVkIHRvIFNlY3Rpb24gNS4NCg0KPiA+PiBbQl0gTElTUCBN dWx0aWNhc3QgdnMuIEVJRC9STE9DIHNlcGFyYXRlDQo+ID4+DQo+ID4+IC0gNi4gTXVsdGljYXN0 DQo+ID4+DQo+ID4+IFRoaXMgaXMgaW50ZXJlc3RpbmcsIG11bHRpY2FzdCBhZGRyZXNzZXMgKEcp IGxvb2sgbGlrZSB0aGV5J3JlIGFuIGV4Y2VwdGlvbg0KPg0KPiBUaGV5IGFyZSByZWFsbHkgbm90 Lg0KDQpNeSBjb25jZXJuIGlzIHRoYXQgYXMgSSByZWFkIHRoZSBkcmFmdCwgaXQgbGVhdmVzIG1l IHdpdGggdGhlIHN0cm9uZyBpbXByZXNzaW9uDQp0aGF0IHRoZSBzYW1lIG11bHRpY2FzdCBhZGRy ZXNzZXMgKEcpIGFyZSBiZWluZyB1c2VkIGluIGJvdGggdGhlIG92ZXJsYXkNCihhcyBFSURzKSBh bmQgdGhlIHVuZGVybGF5IChhcyBSTE9DcykuICBGcm9tIHlvdXIgcmVzcG9uc2UsIEkgY29uY2x1 ZGUgdGhhdCB0aGlzDQppcyBub3QgdGhlIGNhc2UgKGFuZCBJIGhhdmUgbm8gYXJndW1lbnQgd2l0 aCB0aGF0KS4gIFJhdGhlciwgU2VjdGlvbiA2IG5lZWRzIHRvDQpibHVudGx5IHN0YXRlIHRoYXQg bXVsdGljYXN0IGFkZHJlc3NlcyBhcmUgbWFwcGVkIGJldHdlZW4gRUlEIGFuZCBSTE9DIHNwYWNl IGF0DQpib3RoIElUUnMgYW5kIEVUUnMsIHNvIHRoYXQgdGhlIGZvbGxvd2luZyBpbmZlcmVuY2Ug aXMgb2J2aW91cyBmcm9tIHRoZSB0ZXh0DQooaXQncyBjdXJyZW50bHkgbm90IG9idmlvdXMpOg0K DQo+IFNvIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gcmVnaXN0ZXIgbXVsdGljYXN0IGFkZHJl c3NlcyB0byB0aGUgbWFwcGluZw0KPiBzeXN0ZW0gYXMgRUlEcyBhbmQgdGhleSBjYW4gbWFwIHRv IFJMT0NzIG9mIHNpdGVzIHRoYXQgaGF2ZSBqb2luZWQgdGhlIGdyb3VwLg0KDQpBcyBwYXJ0IG9m IHRoaXMsIEkgc3Ryb25nbHkgcmVjb21tZW5kIG1vdmluZyBhd2F5IGZyb20gdXNlIG9mICJHIiB0 byByZWZlciB0bw0KbXVsdGljYXN0IGdyb3VwcyBpbiBib3RoIHRoZSBvdmVybGF5IGFuZCB1bmRl cmxheS4gIENhcmVmdWwgdXNlIG9mIEctRUlEDQphbmQgRy1STE9DIHdvdWxkIHNpZ25pZmljYW50 bHkgaW1wcm92ZSBjbGFyaXR5Lg0KDQotLS0NCklmIHRoZSBhYm92ZSBhcmUgZG9uZSBmb3IgW0Fd IGFuZCBbQl0gaW4gU2VjdGlvbnMgNSBhbmQgNiwgdGhlbiB0aGUgdGV4dCBmb3IgdGhlDQp1c2Ug Y2FzZXMgaW4gU2VjdGlvbiA3IHNob3VsZCBub3QgbmVlZCBmdXJ0aGVyIGF0dGVudGlvbi4NCi0t LQ0KDQo+ID4+IC0tIE1pbm9yIElzc3VlcyAtLQ0KPiA+Pg0KPiA+PiBUaGVyZSBzZWVtcyB0byBi ZSBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIHRoYXQgdGhlIGVuZCBob3N0IGFuZCBpdHMNCj4gPj4g SVRSICh4VFIpIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3IgQXV0b25vbW91cyBTeXN0ZW0uICBG b3IgaW5jcmVtZW50YWwNCj4NCj4gVGhpcyBpcyB0cnVlIHdoZW4geW91IGNhbGwgdGhlIGRvbWFp biBhICJMSVNQIHNpdGUiLiBCdXQgaWYgdGhlIHNpdGUgaXMNCj4gdW5jaGFuZ2VkIGFuZCBvbmUg dXNlcyBQSVRScywgbWF5YmUgZXZlbiBjbG9zZSB0byB0aGUgc2l0ZSwgbGlrZSBpbiBhIFBFDQo+ IHJvdXRlciwgdGhlbiB0aGUgUElUUiBpcyBkZWZpbml0ZWx5IGluIGFub3RoZXIgQVMuDQoNCkxv b2tpbmcgYXQgdGhlIHRleHQsIGl0IHNlZW1zIHRoYXQgIkxJU1Agc2l0ZSIgYW5kICJkb21haW4i IGFyZSB0aGUgc2FtZQ0KY29uY2VwdCBmb3IgdGhpcyBkcmFmdC4gIFRoYXQgd291bGQgYmUgdXNl ZnVsIHRvIHN0YXRlLCBJTUhPIGJ1dCBJJ2xsIGxlYXZlDQp0aGUgZGVjaXNpb24gb24gd2hldGhl ciB0byBkbyBzbyB0byB5b3UgYW5kIHRoZSBkcmFmdCBhdXRob3JzLg0KDQpPbiByZXJlYWRpbmcs IG15IGNvbmNlcm5zIHNlZW0gdG8gYmUgdHJpZ2dlcmVkIG1vc3RseSBieSB0aGlzIHNlbnRlbmNl IGluDQpTZWN0aW9uIDMuMjoNCg0KICAgVGhlIGVkZ2UgY29uc2lzdHMgb2YgTElTUCBzaXRlcyAo ZS5nLiwgYW4NCiAgIEF1dG9ub21vdXMgU3lzdGVtKSB0aGF0IHVzZSBFSUQgYWRkcmVzc2VzLg0K DQpJIHRoaW5rIGEgc21hbGwgY2hhbmdlIHRvIHRoZSBsYXN0IHNlbnRlbmNlIGluIHRoYXQgcGFy YWdyYXBoIHdvdWxkIHJlc29sdmUNCm15IGNvbmNlcm4gd2l0aG91dCBkaXN0cmFjdGluZyBmcm9t IHRoZSBuYXJyYXRpdmU6DQoNCk9MRA0KICAgRUlEcyBkbyBub3QNCiAgIGNvbnRhaW4gaW50ZXIt ZG9tYWluIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNlIG9mIHRoaXMsDQogICBF SURzIGFyZSB1c3VhbGx5IHJvdXRhYmxlIGF0IHRoZSBlZGdlICh3aXRoaW4gTElTUCBzaXRlcykg b3IgaW4gdGhlDQogICBub24tTElTUCBJbnRlcm5ldC4NCk5FVw0KICAgRUlEcyBkbyBub3QNCiAg IGNvbnRhaW4gaW50ZXItZG9tYWluIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNl IG9mIHRoaXMsDQogICBFSURzIGFyZSB1c3VhbGx5IHJvdXRhYmxlIGF0IHRoZSBlZGdlICh3aXRo aW4gTElTUCBzaXRlcykgb3IgaW4gdGhlDQogICBub24tTElTUCBJbnRlcm5ldDsgc2VlIFNlY3Rp b24gMy41IGZvciBkaXNjdXNzaW9uIG9mIExJU1Agc2l0ZQ0KICAgaW50ZXJuZXR3b3JraW5nIHdp dGggbm9uLUxJU1Agc2l0ZXMgYW5kIGRvbWFpbnMgaW4gdGhlIEludGVybmV0Lg0KDQo+ID4+IERl c3BpdGUgbXVsdGlwbGUgIG1lbnRpb25zIG9mIGluY3JlbWVudGFsIGRlcGxveW1lbnQsIEkgZGlk IG5vdA0KPiA+PiBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGF0IG1pZ2h0IGJlIGFjY29tcGxp c2hlZC4NCj4NCj4gVGhlcmUgYXJlIFB4VFJzIGFuZCBOQVRzLiBBbmQgcmVmZXJlbmNlcyB0byB0 aGUgTElTUCBpbnRlcndvcmtpbmcgUkZDLg0KDQpPaywgY2FuIHdlIGp1c3Qgc2F5IHNvIGluIFNl Y3Rpb24gMy41PyAgQWRkaW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UNCnRvIHRoZSBlbmQgb2Yg dGhlIHNlY3Rpb24gd291bGQgc3VmZmljZToNCg0KICAgUElUUnMsIFBFVFJzIGFuZCBMSVNQLU5B VCBzdXBwb3J0IGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgTElTUA0KICAgYnkgcHJvdmlkaW5n IHNpZ25pZmljYW50IGZsZXhpYmlsaXR5IGluIGxvY2F0aW9uIG9mIHRoZSBib3VuZGFyaWVzDQog ICBiZXR3ZWVuIHRoZSBMSVNQIGFuZCBub24tTElTUCBwb3J0aW9ucyBvZiB0aGUgbmV0d29yaywg YW5kIG1ha2luZw0KICAgaXQgcmVhc29uYWJsZSB0byBjaGFuZ2UgdGhvc2UgYm91bmRhcmllcyBv dmVyIHRpbWUuDQoNCj4gPj4gLSAzLjMuMS4gIExJU1AgRW5jYXBzdWxhdGlvbg0KPiA+Pg0KPiA+ PiAgICB0aGUgc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQgYnkNCj4gPj4gICAgdGhlIElUUiBhbmQg aWdub3JlZCBvbiByZWNlcHRpb24uDQo+ID4+DQo+ID4+IFBsZWFzZSBtZW50aW9uIG11bHRpcGF0 aGluZyAoZS5nLiwgRUNNUCBhbmQgTEFHKSBhcyBwb3NzaWJsZSBpbmZsdWVuY2VzDQo+ID4+IG9u IGhvdyBzb3VyY2UgcG9ydHMgYXJlIHNlbGVjdGVkLCBhcyB0aGlzIGltcG9zZXMgc29tZSBsaW1p dHMgb24gd2hhdCBhbg0KPiA+PiBJVFIgY2FuIHJlYXNvbmFibHkgZG8uDQo+DQo+IEVDTVAvTEFH IGRvbid0IGluZmx1ZW5jZSB3aGljaCBzb3VyY2UgcG9ydCBpcyBzZWxlY3RlZC4gSXQgaXMgYSA1 LXR1cGxlIGhhc2gNCj4gb2YgdGhlIGlubmVyIGhlYWRlciB0aGF0IHNlbGVjdHMgYSBzb3VyY2Ug cG9ydCB0aGF0IGluZmx1ZW5jZXMgaG93IGFuIHVuZGVybGF5DQo+IHJvdXRlciB3b3VsZCBsb2Fk LXNwbGl0IHRyYWZmaWMuDQoNClBsZWFzZSBzdGF0ZSB0aGF0IGEgNS10dXBsZSBoYXNoIGlzIHVz ZWQuICBFQ01QL0xBRyBpcyBhbW9uZyB0aGUgaW1wb3J0YW50DQpyZWFzb25zIHdoeSwgYnV0IHRo YXQgZG9lc24ndCBuZWVkIHRvIGJlIHN0YXRlZCBpZiB5b3UgcHJlZmVyIG5vdCB0by4gIEFuDQpl eGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGV4Y2x1ZGVkIGlzIHRoYXQgdXNp bmcgYSByYW5kb20NCm51bWJlciBnZW5lcmF0b3IgdG8gc2V0IHRoZSBzb3VyY2UgcG9ydCB3b3Vs ZCBiZSB3cm9uZyAtIEkgY291bGQgc3VnZ2VzdA0KY2l0aW5nIGRyYWZ0LWlldGYtZGFydC1kc2Nw LXJ0cCBmb3IgcmVsYXRlZCBkaXNjdXNzaW9uIChhbmQgbG90cyBtb3JlDQpkZXRhaWxzKSwgYnV0 IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIG5lY2Vzc2FyeS4NCg0KLS0gSVB2NiB6ZXJvIFVEUCBjaGVj a3N1bQ0KDQo+IE15IGhlYWQgc3BpbnMgZXZlcnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBzdWJq ZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW4NCj4gdGFsa2VkIGFib3V0IGZyb20gMTAwcyBvZiBw ZW9wbGUgZm9yIGEgZGVjYWRlLiBXZSBoYXZlIENSQyBvbiBsaW5rcywgd2UgaGF2ZQ0KPiBhcHBz IHRoYXQgdXNlIFRDUCBhbmQgVURQIGNoZWNrc3Vtcy4gTnVmIHNhaWQuDQoNClVuZGVyc3Rvb2Qg LSB0aGVyZSdzIG1vcmUgdGhhbiBvbmUgc2V0IG9mIHNjYXJzIG9uIHRoaXMgb25lIDotKC4gIExl dCdzIGNvbWUgYmFjaw0KdG8gdGhpcyB0b3BpYyBhZnRlciB3ZSd2ZSByZXNvbHZlZCBldmVyeXRo aW5nIGVsc2UsIGFuZCBwbGVhc2Uga2VlcCBpbiBtaW5kDQp0aGF0IEkgdGFnZ2VkIHRoaXMgYXMg YSBtaW5vciBpc3N1ZSwgbm90IGEgbWFqb3Igb25lIChlLmcuLCB0aGUgYWJvdmUgY2hhbmdlcw0K Zm9yIFtBXSBhbmQgW0JdIGFyZSBmYXIgbW9yZSBpbXBvcnRhbnQsIElNSE8pLg0KDQpUaGFua3Ms DQotLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGlubyBG YXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tPG1haWx0bzpmYXJpbmFjY2lAZ21h aWwuY29tPl0NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSAyOjE5IFBNDQo+ IFRvOiBKb2VsIE0uIEhhbHBlcm4NCj4gQ2M6IEJsYWNrLCBEYXZpZDsgQWxiZXJ0IENhYmVsbG9z OyBEYW1pZW4gU2F1Y2V6OyBvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3Jn PjsNCj4gaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IGxpc3BAaWV0Zi5vcmc8 bWFpbHRvOmxpc3BAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbbGlzcF0gT1BTLURpciByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMQ0KPg0KPiA+IEkgd2lsbCBsZWF2 ZSBtb3N0IG9mIHRoZXNlIGZvciB0aGUgYXV0aG9ycyB0byBjb21tZW50IG9uLg0KPg0KPiBTZWUg bXkgY29tbWVudHMgaW5saW5lLiBUaGFua3MgRGF2aWQgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3 IGFuZCBjb21tZW50YXJ5Lg0KPg0KPiA+IFdpdGggcmVnYXJkIHRvIHlvdXIgcXVlc3Rpb24gYWJv dXQgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgdGhhdCBpcyB0aGUNCj4gZG9tYWluIG9mIHRoZSBM SVNQIERlcGxveW1lbnQgZG9jdW1lbnQsIGFuZCB3YXMgZGVsaWJlcmF0ZWx5IG9ubHkgbGlnaHRs eQ0KPiBjb3ZlcmVkIGhlcmUuICBJIGFtIG5vdCBzdXJlIHdoYXQgd2UgY2FuIGRvIHRvIGFkZHJl c3MgeW91ciBjb21tZW50IHdpdGhvdXQNCj4gZHVwbGljYXRpbmcgdGhlIGVudGlyZXR5IG9mIHRo YXQgZG9jdW1lbnQuDQo+DQo+IFRoYXQgaXMgdGhlIHJpc2sgd2UgbWF5IGhhdmUgd2l0aCBtYW55 IG9mIHlvdXIgY29tbWVudHMuIFdlIGhhdmUgYSBsb3Qgb2YNCj4gZGV0YWlsIGluIHRoZSBhbHJl YWR5IDkgcHVibGlzaGVkIFJGQ3MgIGFuZCB0aGlzIGRvY3VtZW50IHJlYWxseSBpcyB0byB0YWtl DQo+IGFsbCB0aGF0IGRldGFpbCBhbmQgc3VtbWFyaXplIGFzIGFuIGVhc2lseSB1bmRlcnN0YW5k YWJsZSBkZXNjcmlwdGlvbiBvZiBhDQo+IGNvaGVzaXZlIGRlc2lnbi4NCj4NCj4gPiBXaXRoIHJl Z2FyZCB0byBVRFAgWmVybywgdGhpcyB3YXMgYXBwcm92ZWQgYnkgdGhlIElFU0cgYW5kIHB1Ymxp c2hlZCBhcyBhbg0KPiBSRkMuICBJdCBpcyBwYXJ0IG9mIHRoZSB3YXkgdGhlIHByb3RvY29sIGlz IGRlZmluZWQuICBJZiB0aGVyZSBhcmUgc3BlY2lmaWMNCj4gY2hhbmdlcyB5b3Ugd291bGQgbGlr ZSB0byBzZWUgaW4gdGhlIGV4cGxhbmF0b3J5IHRleHQsIEkgYW0gc3VyZQ0KPg0KPiBEZWZpbml0 ZWx5IGFncmVlZC4gSW4gZmFjdCB3ZSBpbnN0aWdhdGVkIFVEUCB6ZXJvLiBBbmQgSSBjb250aW51 YWxseSB0YWxrIHRvDQo+IGhhcmR3YXJlIGVuZ2luZWVycyBhbmQgdGhleSBhbGwgYmVsaWV2ZSB3 ZSBtYWRlIHRoZSByaWdodCBkZWNpc2lvbi4gU28gaGF0cw0KPiBvZmYgdG8gdGhlIElFVEYgZm9y IGJlaW5nIHByYWN0aWNhbC4NCj4NCj4gPiB3ZSBjb3VsZCBpbmNsdWRlIHRoZW0uICBJZiB5b3Ug YXJlIGxvb2tpbmcgZm9yIGEgY2hhbmdlIGluIHRoZSBiZWhhdmlvciwNCj4gdGhpcyBkb2N1bWVu dCBjYW4gbm90IG1ha2UgY2hhbmdlcyB0byB0aGUgTElTUCBiZWhhdmlvci4NCj4NCj4gWWVzLCBh biBpbXBvcnRhbnQgcG9pbnQuDQo+DQo+ID4+IEkgZm91bmQgYSBjb3VwbGUgb2YgbWFqb3IgaXNz dWVzIHRoYXQgSSBob3BlIGFyaXNlIGZyb20gdGhlDQo+ID4+IHN1bW1hcml6YXRpb24gb2YgTElT UCBpbiB0aGlzIGRyYWZ0LCBhcyBvcHBvc2VkIHRvIGJlaW5nIHByb2JsZW1zIGluDQo+ID4+IHRo ZSBhY3R1YWwgTElTUCBwcm90b2NvbHMuICBJIGFsc28gZm91bmQgYSBmZXcgbWlub3IgaXNzdWVz LCB0aGUgbW9zdA0KPiA+PiBpbXBvcnRhbnQgb2Ygd2hpY2ggaXMgdGhlIG5lZWQgZm9yIGFkZGl0 aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gPj4gZGlzY3Vzc2lvbiBvbiBtaXNkZWxp dmVyeSwgd2l0aCBwYXJ0aWN1bGFyIGF0dGVudGlvbiB0byBWUE5zLg0KPg0KPiBUaGFua3MgYSB0 b24uDQo+DQo+ID4+IC0tIE1ham9yIGlzc3VlcyAtLQ0KPiA+Pg0KPiA+PiBbQV0gRUlEIG1vYmls aXR5IHZzLiBFSUQgcHJlZml4ZXMNCj4gPj4NCj4gPj4gLSA1LiBNb2JpbGl0eQ0KPiA+Pg0KPiA+ PiBJIHVuZGVyc3RhbmQgaG93IHRoaXMgd29ya3Mgd2hlbiBtYXBwaW5nIGlzIHBlci1FSUQsIGJ1 dCBob3cgZG9lcyB0aGlzIHdvcmsNCj4gPj4gd2hlbiB0aGUgRUlEIG9mIHRoZSBzeXN0ZW0gdGhh dCBtb3ZlcyBpcyBwYXJ0IG9mIGFuIEVJRCBwcmVmaXgsIGFzDQo+IGRpc2N1c3NlZA0KPiA+PiBp biBTZWN0aW9uIDMuNC4xPyAgRXZlbiBpZiB0aGUgYW5zd2VyIGlzIGEgbG9uZyB2ZXJzaW9uIG9m ICJEb24ndCBkbyB0aGF0ISINCj4gPj4gaXQgc2hvdWxkIGJlIGV4cGxhaW5lZC4NCj4NCj4gTm8s IGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBMSVNQIGRlc2lnbiAoY2lyY2EgMjAwNyksIGFuIHByZWZp eCBpcyB3aGF0IG1vdmVzLg0KPiBBbmQgYSBzcGVjaWZpYyBFSUQgaXMgc2ltcGx5IGEgLzMyIG9y IC8xMjggcHJlZml4LiBIZXJlIGlzIGEgcHJhY3RpY2FsDQo+IGV4YW1wbGU6DQo+DQo+IFlvdSBo YXZlIGEgY2x1c3RlciBvZiBzZXJ2ZXJzIHRoYXQgY29tbXVuaWNhdGUgdG9nZXRoZXIgZm9yIGEg cGFydGljdWxhcg0KPiBhcHBsaWNhdGlvbi4gVGhleSBhcHBsaWNhdGlvbiBjbHVzdGVyIGlzIHJ1 bm5pbmcgaW4gYSBzZXQgb2YgVk1zLiBUaG9zZSBWTXMNCj4gYXJlIGFzc2lnbmVkIEVJRHMgZnJv bSBhIGNvbW1vbiBwb3dlci1vZi0yIEVJRC1wcmVmaXguIFRob3NlIFZNcyBhcmUgY3VycmVudGx5 DQo+IHJ1bm5pbmcgaW4gYSBicmljay1hbmQtbW9ydGFyIGRhdGEgY2VudGVyLiBOb3cgdGhlcmUg aXMgYSBkZXNpcmUgdG8gbW92ZSB0aGUNCj4gVk0gY2x1c3RlciB0byBhIGNsb3VkIHByb3ZpZGVy LiBXaGF0IGlzIG1vdmVkIGlzIHRoZSBFSUQtcHJlZml4IG9mIHRoZQ0KPiBjbHVzdGVyLiBUaGUg bWFwcGluZyBzeXN0ZW0gaXMgdG9sZCB0aGF0IHRoZSBFSUQtcHJlZml4IGlzIGNoYW5naW5nIGl0 cyBSTE9DLQ0KPiBzZXQgZnJvbSB0aGUgYnJpY2stYW5kLW1vcnRhciB4VFJzIHRvIHRoZSBjbG91 ZCBwcm92aWRlcnMgeFRScy4NCj4NCj4gPj4NCj4gPj4gLSA3LjQuICBMSVNQIGZvciBWaXJ0dWFs IE1hY2hpbmUgTW9iaWxpdHkgaW4gRGF0YSBDZW50ZXJzDQo+ID4+DQo+ID4+IEkgZG9uJ3QgdW5k ZXJzdGFuZCBob3cgdGhpcyB3b3JrcyB3aGVuIEVJRCBwcmVmaXhlcyBhcmUgdXNlZCwgYXMgZWFj aCBWTQ0KPiA+PiBoYXMgaXRzIG93biBFSUQgb3IgRUlEcywgaGVuY2UgdGhlIGVudGlyZSBwcmVm aXggcmFuZ2UgZG9lcyBub3QgbW92ZSB3aGVuDQo+ID4+IHRoZSBWTSBtb3Zlcy4NCj4gPj4NCj4g Pj4gRm9yIE9QUy1EaXIsIHRoaXMgRUlEIHByZWZpeCBpc3N1ZSBbQV0gZmFsbHMgdW5kZXIgQS4x LjEgaW4gQXBwZW5kaXggQQ0KPiA+PiBvZiBSRkMgNTcwNjogIEhhcyBkZXBsb3ltZW50IGJlZW4g ZGlzY3Vzc2VkPyBhbmQgc3BlY2lmaWNhbGx5IHVuZGVyOg0KPiA+Pg0KPiA+PiAgICAgICAgKiAg SXMgdGhlIHByb3Bvc2VkIHNwZWNpZmljYXRpb24gZGVwbG95YWJsZT8gIElmIG5vdCwgaG93IGNv dWxkDQo+ID4+ICAgICAgICAgICBpdCBiZSBpbXByb3ZlZD8NCj4gPj4NCj4gPj4gYXMgRUlEIHBy ZWZpeGVzIGFwcGVhciB0byBiZSB1bmRlcGxveWFibGUgZm9yIE1vYmlsaXR5IGFuZCBWTSBNb2Jp bGl0eQ0KPiB1c2FnZS4NCj4NCj4gU2VlIGFib3ZlIGV4YW1wbGUuDQo+DQo+ID4+IFtCXSBMSVNQ IE11bHRpY2FzdCB2cy4gRUlEL1JMT0Mgc2VwYXJhdGUNCj4gPj4NCj4gPj4gLSA2LiBNdWx0aWNh c3QNCj4gPj4NCj4gPj4gVGhpcyBpcyBpbnRlcmVzdGluZywgbXVsdGljYXN0IGFkZHJlc3NlcyAo RykgbG9vayBsaWtlIHRoZXkncmUgYW4gZXhjZXB0aW9uDQo+DQo+IFRoZXkgYXJlIHJlYWxseSBu b3QuIFNpbmNlIG11bHRpY2FzdCBhZGRyZXNzZXMgKmlkZW50aWZ5KiBhIGdyb3VwIG9mDQo+IHJl Y2VpdmVycywgaXQgaXMgdmVyeSBtdWNoIGFuIEVJRCBhbmQgYWhlcmVzIHRvIHRoZSBkZWZpbml0 aW9uIG9mIGFuIEVJRC4NCj4gTXVsdGljYXN0IGFkZHJlc3NlcyBuZXZlciBoYWQgdG9wb2xvZ2lj YWwgc2lnbmZpY2FuY2UgYnV0IHRoZSBzdGF0ZQ0KPiByZXByZXNlbnRpbmcgYSBkaXN0cmlidXRp b24gdHJlZSBkb2VzIHRlbGwgeW91IHdlcmUgdGhlIG1lbWJlcnMgYXJlIChidXQgdGhlDQo+IGlk ZW50aXR5IG9mIHRoZSBtZW1iZXJzIGFyZSBub3Qga25vdyBpbiBtdWx0aWNhc3QpLg0KPg0KPiBT byBpdCBtYWtlcyBwZXJmZWN0IHNlbnNlIHRvIHJlZ2lzdGVyIG11bHRpY2FzdCBhZGRyZXNzZXMg dG8gdGhlIG1hcHBpbmcNCj4gc3lzdGVtIGFzIEVJRHMgYW5kIHRoZXkgY2FuIG1hcCB0byBSTE9D cyBvZiBzaXRlcyB0aGF0IGhhdmUgam9pbmVkIHRoZSBncm91cC4NCj4gU2VlIGRyYWZ0LWZhcmlu YWNjaS1zaWduYWwtZnJlZS1tdWx0aWNhc3QgYXMganVzdCBvbmUgZXhhbXBsZS4gUkZDNjgzMSBh bmQNCj4gZHJhZnQtZmFyaW5hY2NpLWxpc3AtbXItc2lnbmFsaW5nIGFyZSBvdGhlciBleGFtcGxl cy4NCj4NCj4gPj4gdG8gdGhlIEVJRC9STE9DIHNlcGFyYXRpb24gYXMgdGhlIHNhbWUgZGVzdGlu YXRpb24gSVAgbXVsdGljYXN0IGFkZHJlc3MNCj4gPj4gaXMgdXNlZCBmb3IgYm90aCBwdXJwb3Nl cy4gIFRoaXMgY291bGQgdXNlIHNvbWUgbW9yZSBkaXNjdXNzaW9uLCBhcyBpdCdzDQo+ID4+IHVu ZXhwZWN0ZWQgYmFzZWQgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSBkcmFmdCB1cCB0byB0aGlzIHBv aW50Lg0KPg0KPiBJIGJlbGlldmUgdGhlIGxldmVsIG9mIGRldGFpbCB3ZSBoYXZlIGluIHRoZSBp bnRyb2R1Y3Rpb24gZG9jdW1lbnQgaXMgYXQgdGhlDQo+IHJpZ2h0IGxldmVsIG9yIHdlJ2xsIGVy ciBvbiBoYXZpbmcgd2F5IHRvbyBtYW55IGRldGFpbHMgY3JvcCBpbi4NCj4NCj4gPj4gLSA3LjIu ICBMSVNQIGZvciBJUHY2IENvLWV4aXN0ZW5jZQ0KPiA+Pg0KPiA+PiAgICBMSVNQIGVuY2Fwc3Vs YXRpb25zIGFsbG93cyB0byB0cmFuc3BvcnQgcGFja2V0cyB1c2luZyBFSURzIGZyb20gYQ0KPiA+ PiAgICBnaXZlbiBhZGRyZXNzIGZhbWlseSAoZS5nLiwgSVB2Nikgd2l0aCBwYWNrZXRzIGZyb20g b3RoZXIgYWRkcmVzcw0KPiA+PiAgICBmYW1pbGllcyAoZS5nLiwgSVB2NCkuDQo+ID4+DQo+ID4+ IEhvdyBkb2VzIHRoYXQgd29yayBmb3IgbXVsdGljYXN0IHRyYWZmaWMsIHdoZXJlIHRoZSBkZXN0 aW5hdGlvbiBhZGRyZXNzDQo+ID4+IChHKSBoYXMgdG8gYmUgdGhlIHNhbWUgaW4gYm90aCB0aGUg aW5uZXIgYW5kIG91dGVyIGhlYWRlcnM/ICBBcmUgRVRScw0KPiA+PiBhbmQgSVRScyBleHBlY3Rl ZCB0byBtYXAgSVB2NiBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIElQdjQgYW5kIHYudi4/DQo+DQo+ IFRoZSBtYXBwaW5nIHN5c3RlbSBjYW4gbWFwIGFuIChTLUVJRC1pcHY2LCBncm91cC1pcHY2KSAy LXR1cGxlIHRvIGEgUkxPQyBzZXQNCj4gdGhhdCBsb29rZWQgbGlrZSB0aGlzIChpcHY0LW11bHRp Y2FzdCwgaXB2NC11bmljYXN0KSBtZWFuIHRoZSBJVFIgdGhhdA0KPiByZWNlaXZlcyB0aGUgcGFj a2V0IGZyb20gUy1FSUQtaXB2NiB3b3VsZCByZXBsaWNhdGUgdGhlIHBhY2tldCBhbmQgbXVsdGlj YXN0DQo+IGVuY2Fwc3VsYXRlIHRvIGlwdjQtbXVsdGljYXN0IGFuZCB1bmljYXN0IGVuY2Fwc3Vh bHRlIHRvIGlwdjQtdW5pY2FzdC4NCj4NCj4gPj4gLSA3LjMuICBMSVNQIGZvciBWaXJ0dWFsIFBy aXZhdGUgTmV0d29ya3MNCj4gPj4NCj4gPj4gVGhpcyBhbHNvIGhhcyBtdWx0aWNhc3QgcHJvYmxl bXMsIGFzIHRoZXJlIGlzIG9ubHkgb25lIGluc3RhbmNlIG9mIGVhY2gNCj4gPj4gbXVsdGljYXN0 IGFkZHJlc3MgKEcpIGluIHRoZSB1bmRlcmxheSBuZXR3b3JrLiAgSSB0aGluayBJIGNhbiBmaWd1 cmUgb3V0DQo+IGhvdw0KPg0KPiBZb3UgY2FuIG1hcCBmcm9tIEVJRC1HIHRvIFJMT0MtRyBvbmUg dG8gb25lLiBCdXQgd2UgaGF2ZSBzZWVuIG92ZXIgdGhlIGxhc3QNCj4gZGVjYWRlIGluIGEgaGFs ZiB0aGF0IHdpdGggZ2VuZXJhbCBtdWx0aWNhc3QgZGVwbG95bWVudCB0aGF0IG1hbnktdG8tMSBp cw0KPiBkZXNpcmFibGUuIEhlbmNlLCBub3cgdGhhdCB3ZSBoYXZlIGEgd2F5IHRvIG1hcCB3aXRo IGEgbmV0d29yay1iYXNlZCBkYXRhYmFzZSwNCj4gd2UgY2FuIG1hcCBtdWx0aXBsZSBFSUQtR3Mg dG8gYSBzaW5nbGUgKG9yIG11bHRpcGxlKSBSTE9DLUdzLg0KPg0KPiA+PiB0byBtYWtlIG11bHRp Y2FzdCB3b3JrIGZvciB0aGlzIHVzZSBjYXNlLCBidXQgaXQncyBub3QgaW1tZWRpYXRlbHkgb2J2 aW91cywNCj4gPj4gYW5kIHRoZSByZXN1bHQgd2hlbiB0aGUgc2FtZSB1bmRlcmxheSBtdWx0aWNh c3QgYWRkcmVzcyBpcyB1c2VkIGJ5IG1vcmUNCj4gPj4gdGhhbiBvbmUgVlBOIGNvdWxkIHdlbGwg ZGVsaXZlciBzb21lIHRyYWZmaWMgdG8gRVRScyB0aGF0IGhhdmUgdG8gZGlzY2FyZA0KPg0KPiBU aGlzIGlzIGEgbmVjZXNzYXJ5IGV2aWwgd2hlbiB0aGUgdW5kZXJsYXkgaXMgc3RhdGUgY2hhbGxl bmdlZC4gQnV0IGl0IGlzIGENCj4gc3RhdGUvYmFuZHdpZHRoIHRyYWRlb2ZmLiBXZSBoYXZlIGZv dW5kIHdpdGggTVZQTiBkZXBsb3ltZW50IHRoYXQgdGhlIG5ldHdvcmsNCj4gYWRtaW4gY29uZmln dXJlcyB0aGUgdW5kZXJseSBvciBzaW1wbHkgdW5pY2FzdHMuDQo+DQo+ID4+IGl0IGJlY2F1c2Ug dGhlIEluc3RhbmNlIElEIGlzIHdyb25nIChhbmQgdGhhdCBleGNlc3NpdmUgZGVsaXZlcnkgaXMg YQ0KPiA+PiBzZWN1cml0eSBjb25zaWRlcmF0aW9uLCBzZWUgbWlub3IgaXNzdWUgb24gU2VjdGlv biA4IGJlbG93KS4gIEkgdGhpbmsgYW4NCj4gPj4gZXhwbGFuYXRpb24gaXMgaW4gb3JkZXIuDQo+ DQo+IFRoZXJlIGFyZSBqdXN0IHRvbyBtYW55IGNvbWJpbmF0aW9ucyB0byBtYWtlIGEgaGlnaC1s ZXZlbCBkZXNjcmlwdGlvbiBzaW1wbGUNCj4gdG8gdW5kZXJzdGFuZC4gVGhlIGN1cnJlbnQgaW50 cm9kdWN0aW9uIHRleHQgZG9lcyBhIGZpbmQgam9iIHByb3ZpZGluZw0KPiByZWZlcmVuY2VzIGZv ciBzb21lb25lIHRvIGdvIG9mZiBhbmQgZ2V0IHRoZSBkZXRhaWxzLg0KPg0KPiA+PiAtLSBNaW5v ciBJc3N1ZXMgLS0NCj4gPj4NCj4gPj4gVGhlcmUgc2VlbXMgdG8gYmUgYW4gaW1wbGljaXQgYXNz dW1wdGlvbiB0aGF0IHRoZSBlbmQgaG9zdCBhbmQgaXRzDQo+ID4+IElUUiAoeFRSKSBhcmUgaW4g dGhlIHNhbWUgZG9tYWluIG9yIEF1dG9ub21vdXMgU3lzdGVtLiAgRm9yIGluY3JlbWVudGFsDQo+ DQo+IFRoaXMgaXMgdHJ1ZSB3aGVuIHlvdSBjYWxsIHRoZSBkb21haW4gYSAiTElTUCBzaXRlIi4g QnV0IGlmIHRoZSBzaXRlIGlzDQo+IHVuY2hhbmdlZCBhbmQgb25lIHVzZXMgUElUUnMsIG1heWJl IGV2ZW4gY2xvc2UgdG8gdGhlIHNpdGUsIGxpa2UgaW4gYSBQRQ0KPiByb3V0ZXIsIHRoZW4gdGhl IFBJVFIgaXMgZGVmaW5pdGVseSBpbiBhbm90aGVyIEFTLiBCdXQgbm90ZSBJIHNhaWQgUElUUiBh bmQNCj4gbm90IElUUi4gVGhlIHJlYXNvbiBiZWluZyBpcyBiZWNhdXNlIGFuIElUUiBpcyBjb25m aWd1cmVkIHdpdGggZGF0YWJhc2UtDQo+IG1hcHBpbmcgcHJlZml4ZXMgdGhhdCBpcyB1c2VzIHRv IGVuY2Fwc3VsYXRlIHBhY2tldHMgZnJvbSBzdWNoIGFkZHJlc3Nlcy4NCj4gVmVyc3VzIHRoZSBQ SVRSIGJlaW5nIGFuIElUUiB3aXRoICpubyBkYXRhYmFzZS1tYXBwaW5ncyogcHJvdmlkaW5nIGEg bXVjaCBtb3JlDQo+IGxhcmdlci9vciBtb3JlIGFnZ3JlZ3RhYmxlIHNlcnZpY2UuDQo+DQo+ID4+ IGRlcGxveW1lbnQsIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGFsd2F5cyB0aGUgY2FzZSwgYnV0IEkg dGhpbmsgdGhhdCBvbmx5DQo+ID4+IGhhcyBlZGl0b3JpYWwgaW1wYWN0IG9uIHRoaXMgZG9jdW1l bnQsIGFzIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZQ0KPiA+PiBmdW5kYW1lbnRhbCBMSVNQIG1l Y2hhbmlzbXMgYXJlIGFmZmVjdGVkLiAgVGhlIGF1dGhvcnMgc2hvdWxkIGxvb2sgZm9yDQo+ID4+ IHVzZSBvZiAiZG9tYWluIiBhbmQgIkF1dG9ub21vdXMgU3lzdGVtIiBhbmQgZW5zdXJlIHRoYXQg dGhlIHRleHQgaXMNCj4gPj4gZ2VuZXJhbGl6ZWQgdG8gdGhlIGNhc2Ugd2hlcmUgdGhlIGVuZCBo b3N0IGFuZCBJVFIgYXJlIG1vcmUgd2lkZWx5DQo+ID4+IHNlcGFyYXRlZC4NCj4NCj4gV2UgYXJl IG92ZXJsb2FkZWQgd2l0aCB0ZXJtcyB0aGF0IGNyZWF0ZSB0b3BvbG9naWNhbCBvciBvcmdhbml6 YXRpb24gYm91bmRhcnkuDQo+IEhlbmNlIHdoeSB3ZSBjcmVhdGVkICJMSVNQIHNpdGUiIHdoaWNo IGlzIGFsc28gdGhlIHNhbWUgYXMgYSAiTElTUCBWUE4gc2l0ZSIuDQo+IFdoZXJlIGEgIkxJU1Ag c2l0ZSIgdGhhdCBoYXMgbXVsdGlwbGUgdGVubmFudHMgd291bGQgYmUgbXVsdGlwbGUgIkxJU1Ag VlBODQo+IHNpdGVzIi4NCj4NCj4gPj4gRGVzcGl0ZSBtdWx0aXBsZSAgbWVudGlvbnMgb2YgaW5j cmVtZW50YWwgZGVwbG95bWVudCwgSSBkaWQgbm90DQo+ID4+IHNlZSBhIGRpc2N1c3Npb24gb2Yg aG93IHRoYXQgbWlnaHQgYmUgYWNjb21wbGlzaGVkLiAgVGhlcmUgaXMgc29tZQ0KPg0KPiBUaGVy ZSBhcmUgUHhUUnMgYW5kIE5BVHMuIEFuZCByZWZlcmVuY2VzIHRvIHRoZSBMSVNQIGludGVyd29y a2luZyBSRkMuDQo+DQo+ID4+IHVzZWZ1bCBjb250ZW50IGluIFNlY3Rpb24gMy41LCBidXQgdGhh dCdzIGF0IGJlc3QgYW4gaW5jb21wbGV0ZQ0KPiA+PiBleHBsYW5hdGlvbi4gIFRoaXMgaXMgYW4g T1BTLURpciByZXZpZXcgY29uY2VybiAtIGl0IGZhbGxzIHVuZGVyDQo+ID4+IEEuMS4zIGluIEFw cGVuZGl4IEEgb2YgUkZDIDU3MDY6IEhhcyB0aGUgbWlncmF0aW9uIHBhdGggYmVlbiBkaXNjdXNz ZWQ/DQo+ID4+DQo+ID4+IC0gMy4zLjEuICBMSVNQIEVuY2Fwc3VsYXRpb24NCj4gPj4NCj4gPj4g ICAgdGhlIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkIGJ5DQo+ID4+ICAgIHRoZSBJVFIgYW5kIGln bm9yZWQgb24gcmVjZXB0aW9uLg0KPiA+Pg0KPiA+PiBQbGVhc2UgbWVudGlvbiBtdWx0aXBhdGhp bmcgKGUuZy4sIEVDTVAgYW5kIExBRykgYXMgcG9zc2libGUgaW5mbHVlbmNlcw0KPiA+PiBvbiBo b3cgc291cmNlIHBvcnRzIGFyZSBzZWxlY3RlZCwgYXMgdGhpcyBpbXBvc2VzIHNvbWUgbGltaXRz IG9uIHdoYXQgYW4NCj4gPj4gSVRSIGNhbiByZWFzb25hYmx5IGRvLg0KPg0KPiBFQ01QL0xBRyBk b24ndCBpbmZsdWVuY2Ugd2hpY2ggc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQuIEl0IGlzIGEgNS10 dXBsZSBoYXNoDQo+IG9mIHRoZSBpbm5lciBoZWFkZXIgdGhhdCBzZWxlY3RzIGEgc291cmNlIHBv cnQgdGhhdCBpbmZsdWVuY2VzIGhvdyBhbiB1bmRlcmxheQ0KPiByb3V0ZXIgd291bGQgbG9hZC1z cGxpdCB0cmFmZmljLg0KPg0KPiA+PiBGb3IgT1BTLURpciwgdGhpcyBtdWx0aXBhdGhpbmcgY29u Y2VybiBmYWxscyB1bmRlciBBLjEuNCBpbiBBcHBlbmRpeCBBIG9mDQo+ID4+IFJGQyA1NzA2OiBI YXZlIHRoZSBSZXF1aXJlbWVudHMgb24gb3RoZXIgcHJvdG9jb2xzIGFuZCBmdW5jdGlvbmFsDQo+ ID4+ICAgICAgICBjb21wb25lbnRzIGJlZW4gZGlzY3Vzc2VkPw0KPiA+Pg0KPiA+PiAgICBUaGlz IGRlY2lzaW9uIHdhcyBtYWRlIGJlY2F1c2UgdGhlDQo+ID4+ICAgIHR5cGljYWwgdHJhbnNwb3J0 IHByb3RvY29scyB1c2VkIGJ5IHRoZSBhcHBsaWNhdGlvbnMgYWxyZWFkeSBpbmNsdWRlDQo+ID4+ ICAgIGEgY2hlY2tzdW0sIGJ5IG5lZ2xlY3RpbmcgdGhlIGFkZGl0aW9uYWwgVURQIGVuY2Fwc3Vs YXRpb24gY2hlY2tzdW0NCj4gPj4gICAgeFRScyBjYW4gZm9yd2FyZCBwYWNrZXRzIG1vcmUgZWZm aWNpZW50bHkuDQo+ID4+DQo+ID4+IEdyb2FuISAgSSBoYXZlIGFuIGV4cXVpc2l0ZSBzZXQgb2Yg c2NhcnMgb24gVURQIHplcm8gY2hlY2tzdW1zIGZvciBJUHY2DQo+ID4+IGZyb20gd29ya2luZyBv biB0aGUgTVBMUyBpbiBVRFAgZHJhZnQsIHNvIEkgbWF5IGJlIG92ZXJseSBzZW5zaXRpdmUgdG8N Cj4gPj4gdGhpcyBjb25jZXJuLiAgVGhlIGRvd25zaWRlIG9mIHRoaXMgZWZmaWNpZW5jeSBpcyB0 aGF0IHRoZXJlIGlzIG5vDQo+ID4+IGNoZWNrc3VtIGNvdmVyYWdlIG9mIHRoZSBJUHY2IGhlYWRl ciB3aGVuIHplcm8gVURQIGNoZWNrc3VtcyBhcmUgdXNlZC4NCj4gPj4gVGhhdCBzaG91bGQgYXQg bGVhc3QgYmUgbWVudGlvbmVkIGhlcmUsIHdpdGggYSBzdW1tYXJ5IG9mIHdoeSB0aGF0J3Mgb2sN Cj4gPj4gLSB0aGUgZGV0YWlsZWQganVzdGlmaWNhdGlvbiBmb3Igd2h5IHRoYXQncyBvayBjYW4g YmUgbGVmdCB0byBvdGhlcg0KPiA+PiBkb2N1bWVudHMuDQo+DQo+IE15IGhlYWQgc3BpbnMgZXZl cnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBzdWJqZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW4N Cj4gdGFsa2VkIGFib3V0IGZyb20gMTAwcyBvZiBwZW9wbGUgZm9yIGEgZGVjYWRlLiBXZSBoYXZl IENSQyBvbiBsaW5rcywgd2UgaGF2ZQ0KPiBhcHBzIHRoYXQgdXNlIFRDUCBhbmQgVURQIGNoZWNr c3Vtcy4gTnVmIHNhaWQuDQo+DQo+ID4+DQo+ID4+IC0tIE5pdHMvRWRpdG9yaWFsIENvbW1lbnRz IC0tDQo+ID4+DQo+ID4+IC0gVG9wIG9mIHAuNDoNCj4gPj4NCj4gPj4gICAgVGhlIGluaXRpYWwg bW90aXZhdGlvbiBpbiB0aGUgTElTUCBlZmZvcnQgaXMgdG8gYmUgZmluZCBpbiB0aGUNCj4gPj4N Cj4gPj4gImZpbmQiIC0+ICJmb3VuZCINCj4gPj4NCj4gPj4gLSBTZWN0aW9uIDMuMSwgZmlyc3Qg YnVsbGV0IGl0ZW0NCj4NCj4gV2Ugd2lsbCBjZXJ0YWlubHkgZml4ZSB0aGVzZS4gVGhhbmtzLg0K Pg0KPiA+Pg0KPiA+PiAgICAgICBEZXZpY2VzIGFyZSBhc3NpZ25lZCB3aXRoIHJlbGF0aXZlbHkg b3BhcXVlIGlkZW50aXR5DQo+ID4+ICAgICAgIG1lYW5pbmdmdWwgYWRkcmVzc2VzIHRoYXQgYXJl IGluZGVwZW5kZW50IG9mIHRoZWlyIHRvcG9sb2dpY2FsDQo+ID4+ICAgICAgIGxvY2F0aW9uLg0K PiA+Pg0KPiA+PiBJIGRvbid0IHVuZGVyc3RhbmQgInJlbGF0aXZlbHkgb3BhcXVlIGlkZW50aXR5 IG1lYW5pbmdmdWwiIGFuZA0KPiA+PiBzdWdnZXN0IHJld3JpdGluZyB0aGUgc2VudGVuY2UuICBJ biBwYXJ0aWN1bGFyIC0gb3BhcXVlIHRvIHdoYXQ/DQo+ID4+IG1lYW5pbmdmdWwgdG8gd2hhdCBp biB3aGF0IG1hbm5lcj8NCj4NCj4gV2VsbCBiZWFjdXNlIGl0IGlzIGFzIGFjY3VyYXRlIGFzIGl0 IGNhbiBiZS4gSWYgYXV0b21vYmlsZXMgYXJlIGdvaW5nIHRvIGJlDQo+IGFzc2lnbmVkIEVJRHMg ZnJvbSBhIFZJTiBudW1iZXIgYWxsb2NhdGlvbiBmcm9tIGEgbWFudWZhY3R1cmUsIHRoZSBhZGRy ZXNzIGlzDQo+IHJlbGF0aXZlbHkgb3BhcXVlLiBJZiBhIFZNIGluIGEgZGF0YS1jZW50ZXIgaXMg Z29pbmcgdG8gYmUgYXNzaWduZWQgYW4gRUlEDQo+IGZyb20gdGhlIHNldCBvZiBwcmVmaXhlcyBh bHJlYWR5IGJlaW5nIHVzZWQgYW5kIGFsbG9jYXRlZCB0byB0aGF0IGRhdGEtY2VudGVyLA0KPiB0 aGVuIHRoZXJlIGlzIGEgZ29vZCBjaGFuY2UgdGhhdCBhZGRyZXNzIGlzIGluIGEgcG93ZXItb2Yt MiBibG9jayB0aGF0IGlzDQo+IHN1bW1hcml6YWJsZSBpbiB0aGUgSUdQLg0KPg0KPiA+Pg0KPiA+ PiAtIFNlY3Rpb24gMy4yLCBzZWNvbmQgcGFyYWdyYXBoDQo+ID4+DQo+ID4+IEp1ZGdpbmcgZnJv bSB0aGUgZmlndXJlLCB4VFJzIGFyZSB0aGUgY29tbW9uIGNhc2UsIHdpdGggc2luZ2xlLQ0KPiA+ PiBmdW5jdGlvbiBJVFJzIGFuZCBFVFJzIGJlaW5nIHJhcmUuICBJdCBtaWdodCBiZSBnb29kIHRv IHNheSB0aGF0DQo+ID4+IGFuZCBkaXNjdXNzIHdoZW4gSVRScyBhbmQgRVRScyB0aGF0IGFyZSBu b3QgeFRScyBhcmUgYXBwcm9wcmlhdGUNCj4gPj4gdG8gdXNlLg0KPg0KPiBXaGVuIHlvdSB3YW50 IGVncmVzcyBwYXRoIHNlbGVjdGlvbiB0byBoYXBwZW4gZnVydGhlciBvdXQgaW4gdGhlIHRvcGxv Z2ljYWwNCj4gZnJvbSB0aGUgc291cmNlIGxvY2F0aW9uLCB0aGVuIHlvdSBwdXQgYW4gSVRSLW9u bHkgc3lzdGVtIHRoZXJlLiBXaGVyZSBpbmdyZXNzDQo+IHRvIHRoZSBzYW1lIHNvdXJjZSAoZGVz dGluYXRpb24gaW4gdGhpcyBkaXJlY3Rpb24pLCB0aGUgRVRSIGNhbiBiZSBjbG9zZXIgdG8NCj4g dGhlIGRlc3RpbmF0aW9uLg0KPg0KPiA+Pg0KPiA+PiAtIDNyZCBwYXJhZ3JhcGggb24gcC43Og0K PiA+Pg0KPiA+Pg0KPiA+PiAgICBGaW5hbGx5LCB0aGUgTElTUCBhcmNoaXRlY3R1cmUgZW1waGFz aXplcyBhIGNvc3QgZWZmZWN0aXZlDQo+ID4+ICAgIGluY3JlbWVudGFsIGRlcGxveW1lbnQuDQo+ ID4+DQo+ID4+IEknZCBkZWxldGUgImNvc3QgZWZmZWN0aXZlIiBoZXJlIGFuZCBsb29rIGZvciBv dGhlciBvY2N1cnJlbmNlcw0KPiA+PiBvZiAiY29zdCIgYXMgY2FuZGlkYXRlcyBmb3IgZGVsZXRp b24uICBUaGlzIGlzIHN1cHBvc2VkIHRvIGJlDQo+ID4+IGEgdGVjaG5pY2FsIGRvY3VtZW50LCBz byBkaXNjdXNzaW9uIG9mIGNvc3RzIGlzIGEgYml0IG9mZi10YXJnZXQuDQo+DQo+IEZhaXIgZW5v dWdoLg0KPg0KPiA+PiAtIEZpcnN0IGl0ZW0gYWZ0ZXIgRmlndXJlIDI6DQo+ID4+DQo+ID4+ICAg IDEuICBIb3N0QSByZXRyaWV2ZXMgdGhlIEVJRF9CIG9mIEhvc3RCLCB0eXBpY2FsbHkgcXVlcnlp bmcgdGhlIEROUw0KPiA+PiAgICAgICAgYW5kIG9idGFpbmluZyBhbmQgQSBvciBBQUFBIHJlY29y ZC4NCj4gPj4NCj4gPj4gImFuZCBBIiAtPiAiYW4gQSIgIChzcGVsbGluZyBjaGVja2VycyBkb24n dCBjYXRjaCBldmVyeXRoaW5nKS4NCj4NCj4gQWxyZWFkeSBub3RlZCBhbmQgd2lsbCBiZSBmaXhl ZC4NCj4NCj4gPj4NCj4gPj4gLSAzLjMuMS4gIExJU1AgRW5jYXBzdWxhdGlvbg0KPiA+Pg0KPiA+ PiAgICBPbiB0aGUgb3RoZXIgaGFuZCwgUmVjdXJzaXZlDQo+ID4+ICAgIHR1bm5lbHMgYXJlIG5l c3RlZCB0dW5uZWxzIGFuZCBhcmUgaW1wbGVtZW50ZWQgYnkgdXNpbmcgbXVsdGlwbGUgTElTUA0K PiA+PiAgICBlbmNhcHN1bGF0aW9ucyBvbiBhIHBhY2tldC4NCj4gPj4NCj4gPj4gVGhlIGFib3Zl IHNlbnRlbmNlIHNlZW1zIG91dCBvZiBwbGFjZSBpbiB0aGUgbWlkZGxlIG9mIGEgcGFyYWdyYXBo IGFib3V0DQo+ID4+IFJlLWVuY2Fwc3VsYXRpbmcgdHVubmVscyBhbmQgcm91dGVycyAtIEkgc3Vn Z2VzdCBtb3ZpbmcgaXQgZG93biBpbnRvIGl0cw0KPiA+PiBvd24gcGFyYWdyYXBoIGFuZCBwZXJo YXBzIGFkZGluZyBhIHNlbnRlbmNlIGFib3V0IHdoZXJlL2hvdyBSZWN1cnNpdmUNCj4gPj4gdHVu bmVscyBtYXkgYmUgdXNlZnVsLg0KPg0KPiBHb29kIHN1Z2dlc3Rpb24gYW5kIG1ha2VzIHNlbnNl Lg0KPg0KPiA+PiAtIDMuMy4yLiAgTElTUCBGb3J3YXJkaW5nIFN0YXRlDQo+ID4+DQo+ID4+ICAg IEluIHRoZSBMSVNQIGFyY2hpdGVjdHVyZSwgSVRScyBrZWVwIGp1c3QgZW5vdWdoIGluZm9ybWF0 aW9uIHRvIHJvdXRlDQo+ID4+ICAgIHRyYWZmaWMgZmxvd2luZyB0aHJvdWdoIGl0Lg0KPiA+Pg0K PiA+PiAiaXQuIiAtPiAidGhlbS4iDQo+ID4+DQo+ID4+ICAgIE1lYW5pbmcgdGhhdCwgSVRScyBy ZXRyaWV2ZSBmcm9tIHRoZQ0KPiA+PiAgICBMSVNQIE1hcHBpbmcgU3lzdGVtIG1hcHBpbmdzIGJl dHdlZW4gRUlEIHByZWZpeGVzIGFuZCBSTE9DcyB0aGF0IGFyZQ0KPiA+PiAgICB1c2VkIHRvIGVu Y2Fwc3VsYXRlIHBhY2tldHMuDQo+ID4+DQo+ID4+IFRoaXMgaXMgdGhlIGZpcnN0IHVzZSBvZiB0 aGUgbm90aW9uIG9mIEVJRCBwcmVmaXhlcy4gIFRoYXQgY29uY2VwdCBzaG91bGQNCj4gPj4gYmUg ZXhwbGFpbmVkIGJlZm9yZSBpdCBpcyB1c2VkLCBhbHRob3VnaCBhIGZvcndhcmQgcmVmZXJlbmNl IHRvIHNlY3Rpb24NCj4gPj4gMy40LjEgbWF5IHN1ZmZpY2UuICBJdCBtaWdodCBiZSBiZXR0ZXIg dG8gcmV3cml0ZSB0aGlzIHBhcmFncmFwaCBpbiB0ZXJtcw0KPiA+PiBvZiBFSURzIGFuZCBsZWF2 ZSB0aGUgbm90aW9uIG9mIEVJRCBwcmVmaXhlcyB0byBzZWN0aW9uIDMuNC4xLg0KPg0KPiBIbW0s IEknbGwgbGV0IEFsYmVydCBhbmQgRGFtaWVuIGRlY2lkZSBpZiB3ZSBzaG91bGQgc3RhdGUgIkVJ RC1wcmVmaXhlcyINCj4gZXZlcnl3aGVyZSBpbnN0ZWFkIG9mIGp1c3QgIkVJRCIuDQo+DQo+ID4+ DQo+ID4+IC0gNC40LiAgTVRVIEhhbmRsaW5nDQo+ID4+DQo+ID4+ICAgIEFkZGl0aW9uYWxseSwg TElTUCBhbHNvIHJlY29tbWVuZHMgaW5mZXJyaW5nIHJlYWNoYWJpbGl0eSBvZiBsb2NhdG9ycw0K PiA+PiAgICBieSB1c2luZyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgdW5kZXJsYXksIGlu IHBhcnRpY3VsYXI6DQo+ID4+DQo+ID4+IEl0J2QgYmUgdXNlZnVsIHRvIGFkZCBhIHNlbnRlbmNl IG9yIHR3byBhYm91dCBob3cgTElTUCBhbmQgdGhlIHRlY2huaXF1ZXMNCj4gPj4gaW4gdGhpcyBz ZWN0aW9uIGludGVyYWN0IHdpdGggaG9zdCB1c2Ugb2YgUE1UVUQgYW5kIFBMUE1UVUQuDQo+DQo+ IFRoaXMgaXMgYSBsb3Qgb2YgZGV0YWlsIGJlY2F1c2UgaW4gUkZDNjgzMCB3ZSBoYXZlIDMgcG9z aXRpb25zIG9yIG9wdGlvbnMgb24NCj4gdGhlIHN1YmplY3QuIEFuZCB3ZSBkaWQgcHJvdmlkZSBh IHJlZmVyZW5jZSB0byBSRkM2ODMwIGZvciB0aGlzIHRvcGljLg0KPg0KPiA+PiAtIE5leHQgdG8g bGFzdCBwYXJhZ3JhcGggb24gcC4xNzoNCj4gPj4NCj4gPj4gICAgQWRkaXRpb25hbGx5LCBMSVNQ IGFsc28gcmVjb21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmlsaXR5IG9mIGxvY2F0b3JzDQo+ID4+ ICAgIGJ5IHVzaW5nIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSB1bmRlcmxheSwgaW4gcGFy dGljdWxhcjoNCj4gPj4NCj4gPj4gVGhpcyBsb29rcyBsaWtlIGl0J3MgYSBwYXJhZ3JhcGggZWFy bHkgYW5kIG5lZWRzIHRvIGJlIG1vdmVkIGRvd24gdG8NCj4gPj4gYWZ0ZXIgdGhlIHBhcmFncmFw aCB0aGF0IGZvbGxvd3MgaXQuDQo+DQo+IEFncmVlLg0KPg0KPiA+PiBpZG5pdHMgMi4xMy4wMSBk aWRuJ3QgZmluZCBhbnkgbml0cy4NCj4gPj4NCj4gPj4gVGhhbmtzLA0KPiA+PiAtLURhdmlkDQo+ DQo+IFRoYW5rcyBhZ2FpbiBEYXZpZC4NCj4NCj4gRGlubw0KDQo= --_000_CE03DB3D7B45C245BCA0D2432779493636438EMX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uaW0NCgl7bXNvLXN0eWxlLW5hbWU6aW07fQ0Kc3Bhbi5CYWxsb29uVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRl eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mZ3Q7DQo8L3NwYW4+SW4gdGhlIFZNIGNhc2UsIGFtIGVudGlyZSBzZXJ2aWNlIG5ldHdvcmsg bWF5IGJlIG1vdmVkIHRvIHRoZSBkYXRhIGNlbnRlciwgYW5kIHNvIHRoZSBFSUQgYmxvY2sgZm9y IHRoYXQgc2V0IGNhbiBiZSBtb3ZlZC4gJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Rm9yIGEgc2luZ2xlIFZNLCB0aGF0IHdvdWxkIGFwcGx5IGlm IHRoZSBWTSBpcyB1c2luZyBhbiBlbnRpcmUgRUlEIGJsb2NrIC0gbW9zdCBpbmRpdmlkdWFsIFZN cyBhcmVu4oCZdC9kb27igJl0LiZuYnNwOyBJbmRpdmlkdWFsIC8zMiBhbmQgLzEyOCBhZGRyZXNz ZXMgYXJlIGNvbW1vbiBmb3IgaW5kaXZpZHVhbA0KIFZNcywgc28gdGhhdOKAmXMgd2hhdOKAmXMg bmVlZGVkIGluIGdlbmVyYWwgZm9yIGluZGl2aWR1YWwgVk0gbW92ZW1lbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5J4oCZZCBleHBlY3QgdGhlIEVJRCBibG9jayBtb3ZlIGNhc2UgdG8gYXBw bHkgZm9yIG1vdmVtZW50IG9mIGEgZ3JvdXAgb2YgVk1zIHRoYXQgYXJlIHVzaW5nIHN1Y2ggYSBi bG9jayAoZS5nLiwgYXMgYSBzdWJuZXQpLCBidXQgVk0gbGl2ZSBtaWdyYXRpb25zIGNhbm5vdCBi ZSBzeW5jaHJvbml6ZWQNCiBpbiBnZW5lcmFsIChjb2xkIG1pZ3JhdGlvbnMgb2YgcG93ZXJlZC1v ZmYgVk1zIGNhbiBiZSwgb2J2aW91c2x5KSwgc28gZXZlbiBpbiB0aGlzIGNhc2Ugd2hlcmUgdGhl IGVudGlyZSBFSUQgYmxvY2sgbW92ZXMsIGlmIGxpdmUgVk0gbWlncmF0aW9ucyBhcmUgaW52b2x2 ZWQsIHRoZXJlIGFyZSBpbnRlcm1lZGlhdGUgc3RhZ2VzIHdoZXJlIHRoZSBFSUQgYmxvY2sgaXMg c3BsaXQgYmV0d2VlbiBMSVNQIHNpdGVzIC4uLiBhbmQgaGVuY2UgLzMyIGFuZA0KIC8xMjggcHJl Zml4ZXMgYXJlIHN0aWxsIHdoYXTigJlzIHdhbnRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+VGhhbmtzLDxicj4NCi0tRGF2aWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSm1oLmRpcmVj dCBbbWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMTUgNzoxOSBQTTxicj4NCjxiPlRvOjwvYj4gQmxh Y2ssIERhdmlkOyBhY2FiZWxsb0BhYy51cGMuZWR1PGJyPg0KPGI+Q2M6PC9iPiBmYXJpbmFjY2lA Z21haWwuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBkYW1pZW4uc2F1Y2V6QGlucmlhLmZyOyBv cHMtZGlyQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBsaXNwQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWlu dHJvZHVjdGlvbi0xMTxicj4NCjxiPkltcG9ydGFuY2U6PC9iPiBMb3c8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5sIHdlIG1heSB3YW50IHRvIHNl cGFyYXRlIFZNIG1vYmlsaXR5IGZyb20gbW9iaWxlIGRldmljZXMuICZuYnNwO09tIHRoZSBWTSBj YXNlLCBhbSBlbnRpcmUgc2V0dmljZSBuZXR3b3JrIG1heSBiZSBtb3ZlZCB0byB0aGUgZGF0YSBj ZW50ZXIsIGFuZCBzbyB0aGUgRUlEIGJsb2NrIGZvciB0aGF0IHNldCBjYW4gYmUgbW92ZWQuICZu YnNwO0luIHRoZSBjYXNlIG9mIGluZGl2aWR1YWxseSBtb2JpbGUgZGViaWNlcyBvcg0KIHNvbWUg dmF0aWF0aW9ucyBvbiBkYXRhIGNlbnRlciBtb2JpbGl0eSwgdGhlcmUgaXMgYSBuZWVkIHRvIG1z a2Ugc3VyZSB0aGUgZnVsbCBFSUQgaXMgYWR2ZXJ0aXNlZCBpbiB0aGUgbWFwcGluZyBzeXN0ZW0u PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3Vycyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5TZW50IGZyb20gbXkgU2Ftc3VuZyBz bWFydHBob25lIG9uIEFUJmFtcDtUPC9zcGFuPiA8bzpwPg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxi cj4NCjxicj4NCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+DQpTdWJqZWN0 OiBSRTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rp b24tMTEgPGJyPg0KRnJvbTogJnF1b3Q7QmxhY2ssIERhdmlkJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7DQo8 YnI+DQpUbzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmFjYWJlbGxvQGFjLnVwYy5lZHUiPmFjYWJl bGxvQGFjLnVwYy5lZHU8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWNhYmVsbG9AYWMu dXBjLmVkdSI+YWNhYmVsbG9AYWMudXBjLmVkdTwvYT4mZ3Q7DQo8YnI+DQpDQzogRGlubyBGYXJp bmFjY2kgJmx0OzxhIGhyZWY9Im1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tIj5mYXJpbmFjY2lA Z21haWwuY29tPC9hPiZndDssJnF1b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7 LERhbWllbiBTYXVjZXogJmx0OzxhIGhyZWY9Im1haWx0bzpkYW1pZW4uc2F1Y2V6QGlucmlhLmZy Ij5kYW1pZW4uc2F1Y2V6QGlucmlhLmZyPC9hPiZndDssJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9w cy1kaXJAaWV0Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9 Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIj5vcHMtZGlyQGlldGYub3JnPC9hPiZndDssJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4mZ3Q7LCZx dW90OzxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIj5saXNwQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciPmxpc3BAaWV0Zi5vcmc8L2E+Jmd0 OywmcXVvdDtCbGFjaywNCiBEYXZpZCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJs YWNrQGVtYy5jb20iPmRhdmlkLmJsYWNrQGVtYy5jb208L2E+Jmd0OyA8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5IaSBBbGJlcnQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMgbm90ZWQg YmVsb3csIG9uIHRoZSBFSUQgcHJlZml4IGZvciBtb2JpbGl0eSBpc3N1ZSwgYSBzaW1wbGUgc3Rh dGVtZW50IGluIFNlY3Rpb24gNSB0byB0aGUgZWZmZWN0IHRoYXQg4oCcaW4NCiB0aGUgc3BlY2lm aWMgY2FzZSBvZiBhIFZNL21vYmlsZSBub2RlIHRoZSBFSUQtcHJlZml4IHNob3VsZCBiZSAvMzIg b3IgLzEyOCAoSVB2NCBvciBJUHY2IHJlc3BlY3RpdmVseSnigJ0gd2lsbCBzdWZmaWNlLiZuYnNw OyBEZXRhaWxzIG9uIHdoYXQgdG8gZG8gd2hlbiB0aGF0IGFkdmljZSBpcyBpZ25vcmVkIGNhbiBi ZSBsZWZ0IHRvIG90aGVyIGRvY3VtZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+VGhhbmtzLDxicj4NCi0tRGF2aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gQWxiZXJ0IENhYmVsbG9zIFs8YSBocmVmPSJtYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdt YWlsLmNvbSI+bWFpbHRvOmFsYmVydC5jYWJlbGxvc0BnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMTUgNjozMyBQTTxicj4NCjxiPlRv OjwvYj4gQmxhY2ssIERhdmlkPGJyPg0KPGI+Q2M6PC9iPiBEaW5vIEZhcmluYWNjaTsgSm9lbCBN LiBIYWxwZXJuOyBEYW1pZW4gU2F1Y2V6OyA8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9y ZyI+DQpvcHMtZGlyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmci PmlldGZAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+DQpsaXNw QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2xpc3BdIE9QUy1EaXIgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTE8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIERhdmlkPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB5b3Vy IGNvbW1lbnRzLCBJIGFtIHBhcnNpbmcgdGhlbSBhbmQgScK0bGwgc3VnZ2VzdCBuZXcgdGV4dCBh aW1pbmcgdG8gYWRkcmVzcyB0aGVtIEFTQVAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIGFsc28gbGlrZSB0byBiZXR0ZXIg dW5kZXJzdGFuZCBbQV0gYmVmb3JlIGRvaW5nIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaXRoIExJU1AgYW4gRUlELXByZWlm eCBjYW4gaGF2ZSBhbiBhcmJpdHJhcnkgbGVuZ3RoIGFuZCBjYW4gbW92ZSAoaS5lLiwgY2hhbmdl IGl0cyBSTE9DIGJpbmRpbmdzKSwgaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgYSBWTS9tb2JpbGUg bm9kZSB0aGUgRUlELXByZWZpeCBzaG91bGQgYmUgLzMyIG9yIC8xMjgNCiAoSVB2NCBvciBJUHY2 IHJlc3BlY3RpdmVseSkuIFdoYXQgZG9lc24ndCB3b3JrIGlzIHRoZSBtb2JpbGl0eSBvZiBhIG5v ZGUgKGFzc2lnbmVkIHdpdGggYSAvMzIgb3IgLzEyOCkgKndpdGhpbiogYSBjb2Fyc2VyIEVJRC1w cmVmaXgsIGluIHRoaXMgY2FzZSB5b3UgbmVlZCB0byBzcGxpdCB0aGUgcHJlZml4IGludG8gbW9y ZSBzcGVjaWZpY3MgYW5kIHJlZ2lzdGVyIHRoZW0gaW5kZXBlbmRlbnRseSBpbiB0aGUgTWFwcGlu ZyBTeXN0ZW0sIGVmZmVjdGl2ZWx5DQogY3JlYXRpbmcgbmV3IEVJRC1wcmVmaXhlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBsZWFz ZSBsZXQgbWUga25vdyBpZiB0aGlzIGNsYXJpZmllcyB5b3VyIGNvbW1lbnQsIGluIHRoaXMgY2Fz ZSBJIHdpbGwgc3VnZ2VzdCBuZXcgdGV4dCBmb3IgU2VjdGlvbiA1LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxiZXJ0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUs IEZlYiAxMiwgMjAxNSBhdCAxMjowNyBBTSwgQmxhY2ssIERhdmlkICZsdDs8YSBocmVmPSJtYWls dG86ZGF2aWQuYmxhY2tAZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLmJsYWNrQGVtYy5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ RGlubyAtIHRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLjxicj4NCjxicj4NCk9uIHRoZSBtYWpvciBp c3N1ZXMsIGl0IGxvb2tzIGxpa2UgYm90aCBbQV0gYW5kIFtCXSBpbnZvbHZlIG9ubHkgdGhlIHRl eHQ8YnI+DQppbiB0aGlzIGRyYWZ0IGFuZCBub3RoaW5nIGJleW9uZCwgd2hpY2ggaXMgZ29vZCBu ZXdzLiZuYnNwOyBJIGhhdmUgYSBzaW1wbGUgdGV4dDxicj4NCnN1Z2dlc3Rpb24gZm9yIFtBXSwg YnV0IGl0IGxvb2tzIGxpa2UgW0JdIGlzIGdvaW5nIHRvIHJlcXVpcmUgc29tZSBjYXJlZnVsPGJy Pg0KZWRpdGluZywgYXMgb25lIG9mIHRoZSBwcmltYXJ5IGNhdXNlcyBpcyB0aGF0IHRoZSBkcmFm dCBpcyBzbG9wcHkgaW4gdXNpbmc8YnI+DQp0aGUgc2FtZSBzeW1ib2wgJnF1b3Q7RyZxdW90OyB0 byByZXByZXNlbnQgYm90aCBFSUQgYW5kIFJMT0MgbXVsdGljYXN0IGdyb3Vwcy48YnI+DQo8YnI+ DQpPbiB0aGUgbWlub3IgaXNzdWVzLCBJIGhhdmUgdGV4dCBzdWdnZXN0aW9ucyBmb3IgdGhyZWUg b2YgdGhlIGZvdXIsIGFuZDxicj4NCkknZCBsaWtlIHRvIHRlbXBvcmFyaWx5IGRlZmVyIGZ1cnRo ZXIgZGlzY3Vzc2lvbiB0aGUgSVB2NiBVRFAgemVybzxicj4NCmNoZWNrc3VtICZxdW90O3RhcnBp dCZxdW90OyBpbiBmYXZvciBvZiByZXNvbHZpbmcgZXZlcnl0aGluZyBlbHNlIGZpcnN0Ljxicj4N Cjxicj4NCk9uIHRoZSBuaXRzL2VkaXRvcmlhbCBjb21tZW50cywgYWxsIHRoZSBzdWdnZXN0aW9u cyBpbiB5b3VyIGVtYWlsIGFyZSBmaW5lPGJyPg0Kd2l0aCBtZS4mbmJzcDsgRldJVywgSSByZWdh cmQgdGhhdCBwb3J0aW9uIG9mIGEgcmV2aWV3IGFzIGFsbW9zdCBlbnRpcmVseTxicj4NCnN1Ympl Y3QgdG8gdGhlIGRyYWZ0IGF1dGhvcnMnIGRpc2NyZXRpb24gKGFuZCBlZGl0b3JpYWwgdGFzdGUp Ljxicj4NCjxicj4NCiZndDsgJmd0OyZndDsgW0FdIEVJRCBtb2JpbGl0eSB2cy4gRUlEIHByZWZp eGVzPGJyPg0KJmd0Ozxicj4NCiZndDsgLi4uIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBMSVNQIGRl c2lnbiAoY2lyY2EgMjAwNyksIGFuIHByZWZpeCBpcyB3aGF0IG1vdmVzLjxicj4NCiZndDsgQW5k IGEgc3BlY2lmaWMgRUlEIGlzIHNpbXBseSBhIC8zMiBvciAvMTI4IHByZWZpeC4gSGVyZSBpcyBh IHByYWN0aWNhbDxicj4NCiZndDsgZXhhbXBsZTo8YnI+DQo8YnI+DQpBIHN0YXRlbWVudCB0aGF0 IHRoZSBtb2JpbGl0eSB1c2UgY2FzZXMgbmVlZCB0byBlbXBsb3kgLzMyIGFuZCAvMTI4IHByZWZp eGVzLDxicj4NCmFuZCBub3QgYW55dGhpbmcgY29hcnNlciBzaG91bGQgc3VmZmljZS4mbmJzcDsg VGhhdCBzaG91bGQgYmUgYWRkZWQgdG8gU2VjdGlvbiA1Ljxicj4NCjxicj4NCiZndDsgJmd0OyZn dDsgW0JdIExJU1AgTXVsdGljYXN0IHZzLiBFSUQvUkxPQyBzZXBhcmF0ZTxicj4NCiZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gNi4gTXVsdGljYXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgVGhpcyBpcyBpbnRlcmVzdGluZywgbXVsdGljYXN0IGFkZHJl c3NlcyAoRykgbG9vayBsaWtlIHRoZXkncmUgYW4gZXhjZXB0aW9uPGJyPg0KJmd0Ozxicj4NCiZn dDsgVGhleSBhcmUgcmVhbGx5IG5vdC48YnI+DQo8YnI+DQpNeSBjb25jZXJuIGlzIHRoYXQgYXMg SSByZWFkIHRoZSBkcmFmdCwgaXQgbGVhdmVzIG1lIHdpdGggdGhlIHN0cm9uZyBpbXByZXNzaW9u PGJyPg0KdGhhdCB0aGUgc2FtZSBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBhcmUgYmVpbmcgdXNl ZCBpbiBib3RoIHRoZSBvdmVybGF5PGJyPg0KKGFzIEVJRHMpIGFuZCB0aGUgdW5kZXJsYXkgKGFz IFJMT0NzKS4mbmJzcDsgRnJvbSB5b3VyIHJlc3BvbnNlLCBJIGNvbmNsdWRlIHRoYXQgdGhpczxi cj4NCmlzIG5vdCB0aGUgY2FzZSAoYW5kIEkgaGF2ZSBubyBhcmd1bWVudCB3aXRoIHRoYXQpLiZu YnNwOyBSYXRoZXIsIFNlY3Rpb24gNiBuZWVkcyB0bzxicj4NCmJsdW50bHkgc3RhdGUgdGhhdCBt dWx0aWNhc3QgYWRkcmVzc2VzIGFyZSBtYXBwZWQgYmV0d2VlbiBFSUQgYW5kIFJMT0Mgc3BhY2Ug YXQ8YnI+DQpib3RoIElUUnMgYW5kIEVUUnMsIHNvIHRoYXQgdGhlIGZvbGxvd2luZyBpbmZlcmVu Y2UgaXMgb2J2aW91cyBmcm9tIHRoZSB0ZXh0PGJyPg0KKGl0J3MgY3VycmVudGx5IG5vdCBvYnZp b3VzKTo8YnI+DQo8YnI+DQomZ3Q7IFNvIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gcmVnaXN0 ZXIgbXVsdGljYXN0IGFkZHJlc3NlcyB0byB0aGUgbWFwcGluZzxicj4NCiZndDsgc3lzdGVtIGFz IEVJRHMgYW5kIHRoZXkgY2FuIG1hcCB0byBSTE9DcyBvZiBzaXRlcyB0aGF0IGhhdmUgam9pbmVk IHRoZSBncm91cC48YnI+DQo8YnI+DQpBcyBwYXJ0IG9mIHRoaXMsIEkgc3Ryb25nbHkgcmVjb21t ZW5kIG1vdmluZyBhd2F5IGZyb20gdXNlIG9mICZxdW90O0cmcXVvdDsgdG8gcmVmZXIgdG88YnI+ DQptdWx0aWNhc3QgZ3JvdXBzIGluIGJvdGggdGhlIG92ZXJsYXkgYW5kIHVuZGVybGF5LiZuYnNw OyBDYXJlZnVsIHVzZSBvZiBHLUVJRDxicj4NCmFuZCBHLVJMT0Mgd291bGQgc2lnbmlmaWNhbnRs eSBpbXByb3ZlIGNsYXJpdHkuPGJyPg0KPGJyPg0KLS0tPGJyPg0KSWYgdGhlIGFib3ZlIGFyZSBk b25lIGZvciBbQV0gYW5kIFtCXSBpbiBTZWN0aW9ucyA1IGFuZCA2LCB0aGVuIHRoZSB0ZXh0IGZv ciB0aGU8YnI+DQp1c2UgY2FzZXMgaW4gU2VjdGlvbiA3IHNob3VsZCBub3QgbmVlZCBmdXJ0aGVy IGF0dGVudGlvbi48YnI+DQotLS08YnI+DQo8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tIE1pbm9yIElz c3VlcyAtLTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoZXJlIHNlZW1z IHRvIGJlIGFuIGltcGxpY2l0IGFzc3VtcHRpb24gdGhhdCB0aGUgZW5kIGhvc3QgYW5kIGl0czxi cj4NCiZndDsgJmd0OyZndDsgSVRSICh4VFIpIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3IgQXV0 b25vbW91cyBTeXN0ZW0uJm5ic3A7IEZvciBpbmNyZW1lbnRhbDxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoaXMgaXMgdHJ1ZSB3aGVuIHlvdSBjYWxsIHRoZSBkb21haW4gYSAmcXVvdDtMSVNQIHNpdGUm cXVvdDsuIEJ1dCBpZiB0aGUgc2l0ZSBpczxicj4NCiZndDsgdW5jaGFuZ2VkIGFuZCBvbmUgdXNl cyBQSVRScywgbWF5YmUgZXZlbiBjbG9zZSB0byB0aGUgc2l0ZSwgbGlrZSBpbiBhIFBFPGJyPg0K Jmd0OyByb3V0ZXIsIHRoZW4gdGhlIFBJVFIgaXMgZGVmaW5pdGVseSBpbiBhbm90aGVyIEFTLjxi cj4NCjxicj4NCkxvb2tpbmcgYXQgdGhlIHRleHQsIGl0IHNlZW1zIHRoYXQgJnF1b3Q7TElTUCBz aXRlJnF1b3Q7IGFuZCAmcXVvdDtkb21haW4mcXVvdDsgYXJlIHRoZSBzYW1lPGJyPg0KY29uY2Vw dCBmb3IgdGhpcyBkcmFmdC4mbmJzcDsgVGhhdCB3b3VsZCBiZSB1c2VmdWwgdG8gc3RhdGUsIElN SE8gYnV0IEknbGwgbGVhdmU8YnI+DQp0aGUgZGVjaXNpb24gb24gd2hldGhlciB0byBkbyBzbyB0 byB5b3UgYW5kIHRoZSBkcmFmdCBhdXRob3JzLjxicj4NCjxicj4NCk9uIHJlcmVhZGluZywgbXkg Y29uY2VybnMgc2VlbSB0byBiZSB0cmlnZ2VyZWQgbW9zdGx5IGJ5IHRoaXMgc2VudGVuY2UgaW48 YnI+DQpTZWN0aW9uIDMuMjo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIGVkZ2UgY29uc2lz dHMgb2YgTElTUCBzaXRlcyAoZS5nLiwgYW48YnI+DQombmJzcDsgJm5ic3A7QXV0b25vbW91cyBT eXN0ZW0pIHRoYXQgdXNlIEVJRCBhZGRyZXNzZXMuPGJyPg0KPGJyPg0KSSB0aGluayBhIHNtYWxs IGNoYW5nZSB0byB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0aGF0IHBhcmFncmFwaCB3b3VsZCByZXNv bHZlPGJyPg0KbXkgY29uY2VybiB3aXRob3V0IGRpc3RyYWN0aW5nIGZyb20gdGhlIG5hcnJhdGl2 ZTo8YnI+DQo8YnI+DQpPTEQ8YnI+DQombmJzcDsgJm5ic3A7RUlEcyBkbyBub3Q8YnI+DQombmJz cDsgJm5ic3A7Y29udGFpbiBpbnRlci1kb21haW4gdG9wb2xvZ2ljYWwgaW5mb3JtYXRpb24gYW5k IGJlY2F1c2Ugb2YgdGhpcyw8YnI+DQombmJzcDsgJm5ic3A7RUlEcyBhcmUgdXN1YWxseSByb3V0 YWJsZSBhdCB0aGUgZWRnZSAod2l0aGluIExJU1Agc2l0ZXMpIG9yIGluIHRoZTxicj4NCiZuYnNw OyAmbmJzcDtub24tTElTUCBJbnRlcm5ldC48YnI+DQpORVc8YnI+DQombmJzcDsgJm5ic3A7RUlE cyBkbyBub3Q8YnI+DQombmJzcDsgJm5ic3A7Y29udGFpbiBpbnRlci1kb21haW4gdG9wb2xvZ2lj YWwgaW5mb3JtYXRpb24gYW5kIGJlY2F1c2Ugb2YgdGhpcyw8YnI+DQombmJzcDsgJm5ic3A7RUlE cyBhcmUgdXN1YWxseSByb3V0YWJsZSBhdCB0aGUgZWRnZSAod2l0aGluIExJU1Agc2l0ZXMpIG9y IGluIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtub24tTElTUCBJbnRlcm5ldDsgc2VlIFNlY3Rpb24g My41IGZvciBkaXNjdXNzaW9uIG9mIExJU1Agc2l0ZTxicj4NCiZuYnNwOyAmbmJzcDtpbnRlcm5l dHdvcmtpbmcgd2l0aCBub24tTElTUCBzaXRlcyBhbmQgZG9tYWlucyBpbiB0aGUgSW50ZXJuZXQu PGJyPg0KPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBEZXNwaXRlIG11bHRpcGxlJm5ic3A7IG1lbnRpb25z IG9mIGluY3JlbWVudGFsIGRlcGxveW1lbnQsIEkgZGlkIG5vdDxicj4NCiZndDsgJmd0OyZndDsg c2VlIGEgZGlzY3Vzc2lvbiBvZiBob3cgdGhhdCBtaWdodCBiZSBhY2NvbXBsaXNoZWQuPGJyPg0K Jmd0Ozxicj4NCiZndDsgVGhlcmUgYXJlIFB4VFJzIGFuZCBOQVRzLiBBbmQgcmVmZXJlbmNlcyB0 byB0aGUgTElTUCBpbnRlcndvcmtpbmcgUkZDLjxicj4NCjxicj4NCk9rLCBjYW4gd2UganVzdCBz YXkgc28gaW4gU2VjdGlvbiAzLjU/Jm5ic3A7IEFkZGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNl PGJyPg0KdG8gdGhlIGVuZCBvZiB0aGUgc2VjdGlvbiB3b3VsZCBzdWZmaWNlOjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDtQSVRScywgUEVUUnMgYW5kIExJU1AtTkFUIHN1cHBvcnQgaW5jcmVtZW50 YWwgZGVwbG95bWVudCBvZiBMSVNQPGJyPg0KJm5ic3A7ICZuYnNwO2J5IHByb3ZpZGluZyBzaWdu aWZpY2FudCBmbGV4aWJpbGl0eSBpbiBsb2NhdGlvbiBvZiB0aGUgYm91bmRhcmllczxicj4NCiZu YnNwOyAmbmJzcDtiZXR3ZWVuIHRoZSBMSVNQIGFuZCBub24tTElTUCBwb3J0aW9ucyBvZiB0aGUg bmV0d29yaywgYW5kIG1ha2luZzxicj4NCiZuYnNwOyAmbmJzcDtpdCByZWFzb25hYmxlIHRvIGNo YW5nZSB0aG9zZSBib3VuZGFyaWVzIG92ZXIgdGltZS48YnI+DQo8YnI+DQomZ3Q7ICZndDsmZ3Q7 IC0gMy4zLjEuJm5ic3A7IExJU1AgRW5jYXBzdWxhdGlvbjxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQg Ynk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgSVRSIGFuZCBpZ25vcmVkIG9u IHJlY2VwdGlvbi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBQbGVhc2Ug bWVudGlvbiBtdWx0aXBhdGhpbmcgKGUuZy4sIEVDTVAgYW5kIExBRykgYXMgcG9zc2libGUgaW5m bHVlbmNlczxicj4NCiZndDsgJmd0OyZndDsgb24gaG93IHNvdXJjZSBwb3J0cyBhcmUgc2VsZWN0 ZWQsIGFzIHRoaXMgaW1wb3NlcyBzb21lIGxpbWl0cyBvbiB3aGF0IGFuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBJVFIgY2FuIHJlYXNvbmFibHkgZG8uPGJyPg0KJmd0Ozxicj4NCiZndDsgRUNNUC9MQUcg ZG9uJ3QgaW5mbHVlbmNlIHdoaWNoIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkLiBJdCBpcyBhIDUt dHVwbGUgaGFzaDxicj4NCiZndDsgb2YgdGhlIGlubmVyIGhlYWRlciB0aGF0IHNlbGVjdHMgYSBz b3VyY2UgcG9ydCB0aGF0IGluZmx1ZW5jZXMgaG93IGFuIHVuZGVybGF5PGJyPg0KJmd0OyByb3V0 ZXIgd291bGQgbG9hZC1zcGxpdCB0cmFmZmljLjxicj4NCjxicj4NClBsZWFzZSBzdGF0ZSB0aGF0 IGEgNS10dXBsZSBoYXNoIGlzIHVzZWQuJm5ic3A7IEVDTVAvTEFHIGlzIGFtb25nIHRoZSBpbXBv cnRhbnQ8YnI+DQpyZWFzb25zIHdoeSwgYnV0IHRoYXQgZG9lc24ndCBuZWVkIHRvIGJlIHN0YXRl ZCBpZiB5b3UgcHJlZmVyIG5vdCB0by4mbmJzcDsgQW48YnI+DQpleGFtcGxlIG9mIHNvbWV0aGlu ZyB0aGF0IG5lZWRzIHRvIGJlIGV4Y2x1ZGVkIGlzIHRoYXQgdXNpbmcgYSByYW5kb208YnI+DQpu dW1iZXIgZ2VuZXJhdG9yIHRvIHNldCB0aGUgc291cmNlIHBvcnQgd291bGQgYmUgd3JvbmcgLSBJ IGNvdWxkIHN1Z2dlc3Q8YnI+DQpjaXRpbmcgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwIGZvciBy ZWxhdGVkIGRpc2N1c3Npb24gKGFuZCBsb3RzIG1vcmU8YnI+DQpkZXRhaWxzKSwgYnV0IEkgZG9u J3QgdGhpbmsgdGhhdCdzIG5lY2Vzc2FyeS48YnI+DQo8YnI+DQotLSBJUHY2IHplcm8gVURQIGNo ZWNrc3VtPGJyPg0KPGJyPg0KJmd0OyBNeSBoZWFkIHNwaW5zIGV2ZXJ5IHRpbWUgSSBoZWFyIGFi b3V0IHRoaXMgc3ViamVjdC4gVGhpcyBzdWJqZWN0IGhhcyBiZWVuPGJyPg0KJmd0OyB0YWxrZWQg YWJvdXQgZnJvbSAxMDBzIG9mIHBlb3BsZSBmb3IgYSBkZWNhZGUuIFdlIGhhdmUgQ1JDIG9uIGxp bmtzLCB3ZSBoYXZlPGJyPg0KJmd0OyBhcHBzIHRoYXQgdXNlIFRDUCBhbmQgVURQIGNoZWNrc3Vt cy4gTnVmIHNhaWQuPGJyPg0KPGJyPg0KVW5kZXJzdG9vZCAtIHRoZXJlJ3MgbW9yZSB0aGFuIG9u ZSBzZXQgb2Ygc2NhcnMgb24gdGhpcyBvbmUgOi0oLiZuYnNwOyBMZXQncyBjb21lIGJhY2s8YnI+ DQp0byB0aGlzIHRvcGljIGFmdGVyIHdlJ3ZlIHJlc29sdmVkIGV2ZXJ5dGhpbmcgZWxzZSwgYW5k IHBsZWFzZSBrZWVwIGluIG1pbmQ8YnI+DQp0aGF0IEkgdGFnZ2VkIHRoaXMgYXMgYSBtaW5vciBp c3N1ZSwgbm90IGEgbWFqb3Igb25lIChlLmcuLCB0aGUgYWJvdmUgY2hhbmdlczxicj4NCmZvciBb QV0gYW5kIFtCXSBhcmUgZmFyIG1vcmUgaW1wb3J0YW50LCBJTUhPKS48YnI+DQo8YnI+DQpUaGFu a3MsPGJyPg0KLS1EYXZpZDxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgRnJv bTogRGlubyBGYXJpbmFjY2kgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZmFyaW5hY2NpQGdtYWls LmNvbSI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwvYT5dPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJp bSI+Jmd0OyBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE1IDI6MTkgUE08L3NwYW4+ PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm48L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IENjOiBCbGFjaywgRGF2aWQ7IEFsYmVydCBDYWJlbGxv czsgRGFtaWVuIFNhdWNlejsgPGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmciPg0Kb3Bz LWRpckBpZXRmLm9yZzwvYT47PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyA8YSBo cmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1h aWx0bzpsaXNwQGlldGYub3JnIj4NCmxpc3BAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJpbSI+Jmd0OyBTdWJqZWN0OiBSZTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRy YWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTE8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPiZndDsgJmd0OyBJIHdpbGwgbGVhdmUgbW9zdCBvZiB0aGVzZSBmb3IgdGhlIGF1dGhvcnMg dG8gY29tbWVudCBvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWUgbXkgY29tbWVudHMgaW5saW5l LiBUaGFua3MgRGF2aWQgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3IGFuZCBjb21tZW50YXJ5Ljxi cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgV2l0aCByZWdhcmQgdG8geW91ciBxdWVzdGlvbiBhYm91 dCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LCB0aGF0IGlzIHRoZTxicj4NCiZndDsgZG9tYWluIG9m IHRoZSBMSVNQIERlcGxveW1lbnQgZG9jdW1lbnQsIGFuZCB3YXMgZGVsaWJlcmF0ZWx5IG9ubHkg bGlnaHRseTxicj4NCiZndDsgY292ZXJlZCBoZXJlLiZuYnNwOyBJIGFtIG5vdCBzdXJlIHdoYXQg d2UgY2FuIGRvIHRvIGFkZHJlc3MgeW91ciBjb21tZW50IHdpdGhvdXQ8YnI+DQomZ3Q7IGR1cGxp Y2F0aW5nIHRoZSBlbnRpcmV0eSBvZiB0aGF0IGRvY3VtZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoYXQgaXMgdGhlIHJpc2sgd2UgbWF5IGhhdmUgd2l0aCBtYW55IG9mIHlvdXIgY29tbWVudHMu IFdlIGhhdmUgYSBsb3Qgb2Y8YnI+DQomZ3Q7IGRldGFpbCBpbiB0aGUgYWxyZWFkeSA5IHB1Ymxp c2hlZCBSRkNzJm5ic3A7IGFuZCB0aGlzIGRvY3VtZW50IHJlYWxseSBpcyB0byB0YWtlPGJyPg0K Jmd0OyBhbGwgdGhhdCBkZXRhaWwgYW5kIHN1bW1hcml6ZSBhcyBhbiBlYXNpbHkgdW5kZXJzdGFu ZGFibGUgZGVzY3JpcHRpb24gb2YgYTxicj4NCiZndDsgY29oZXNpdmUgZGVzaWduLjxicj4NCiZn dDs8YnI+DQomZ3Q7ICZndDsgV2l0aCByZWdhcmQgdG8gVURQIFplcm8sIHRoaXMgd2FzIGFwcHJv dmVkIGJ5IHRoZSBJRVNHIGFuZCBwdWJsaXNoZWQgYXMgYW48YnI+DQomZ3Q7IFJGQy4mbmJzcDsg SXQgaXMgcGFydCBvZiB0aGUgd2F5IHRoZSBwcm90b2NvbCBpcyBkZWZpbmVkLiZuYnNwOyBJZiB0 aGVyZSBhcmUgc3BlY2lmaWM8YnI+DQomZ3Q7IGNoYW5nZXMgeW91IHdvdWxkIGxpa2UgdG8gc2Vl IGluIHRoZSBleHBsYW5hdG9yeSB0ZXh0LCBJIGFtIHN1cmU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBE ZWZpbml0ZWx5IGFncmVlZC4gSW4gZmFjdCB3ZSBpbnN0aWdhdGVkIFVEUCB6ZXJvLiBBbmQgSSBj b250aW51YWxseSB0YWxrIHRvPGJyPg0KJmd0OyBoYXJkd2FyZSBlbmdpbmVlcnMgYW5kIHRoZXkg YWxsIGJlbGlldmUgd2UgbWFkZSB0aGUgcmlnaHQgZGVjaXNpb24uIFNvIGhhdHM8YnI+DQomZ3Q7 IG9mZiB0byB0aGUgSUVURiBmb3IgYmVpbmcgcHJhY3RpY2FsLjxicj4NCiZndDs8YnI+DQomZ3Q7 ICZndDsgd2UgY291bGQgaW5jbHVkZSB0aGVtLiZuYnNwOyBJZiB5b3UgYXJlIGxvb2tpbmcgZm9y IGEgY2hhbmdlIGluIHRoZSBiZWhhdmlvciw8YnI+DQomZ3Q7IHRoaXMgZG9jdW1lbnQgY2FuIG5v dCBtYWtlIGNoYW5nZXMgdG8gdGhlIExJU1AgYmVoYXZpb3IuPGJyPg0KJmd0Ozxicj4NCiZndDsg WWVzLCBhbiBpbXBvcnRhbnQgcG9pbnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSBm b3VuZCBhIGNvdXBsZSBvZiBtYWpvciBpc3N1ZXMgdGhhdCBJIGhvcGUgYXJpc2UgZnJvbSB0aGU8 YnI+DQomZ3Q7ICZndDsmZ3Q7IHN1bW1hcml6YXRpb24gb2YgTElTUCBpbiB0aGlzIGRyYWZ0LCBh cyBvcHBvc2VkIHRvIGJlaW5nIHByb2JsZW1zIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGUgYWN0 dWFsIExJU1AgcHJvdG9jb2xzLiZuYnNwOyBJIGFsc28gZm91bmQgYSBmZXcgbWlub3IgaXNzdWVz LCB0aGUgbW9zdDxicj4NCiZndDsgJmd0OyZndDsgaW1wb3J0YW50IG9mIHdoaWNoIGlzIHRoZSBu ZWVkIGZvciBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBkaXNjdXNzaW9uIG9uIG1pc2RlbGl2ZXJ5LCB3aXRoIHBhcnRpY3VsYXIgYXR0ZW50aW9u IHRvIFZQTnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIGEgdG9uLjxicj4NCiZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7IC0tIE1ham9yIGlzc3VlcyAtLTxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7IFtBXSBFSUQgbW9iaWxpdHkgdnMuIEVJRCBwcmVmaXhlczxicj4NCiZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gNS4gTW9iaWxpdHk8YnI+DQomZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQgaG93IHRoaXMgd29ya3Mgd2hl biBtYXBwaW5nIGlzIHBlci1FSUQsIGJ1dCBob3cgZG9lcyB0aGlzIHdvcms8YnI+DQomZ3Q7ICZn dDsmZ3Q7IHdoZW4gdGhlIEVJRCBvZiB0aGUgc3lzdGVtIHRoYXQgbW92ZXMgaXMgcGFydCBvZiBh biBFSUQgcHJlZml4LCBhczxicj4NCiZndDsgZGlzY3Vzc2VkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBp biBTZWN0aW9uIDMuNC4xPyZuYnNwOyBFdmVuIGlmIHRoZSBhbnN3ZXIgaXMgYSBsb25nIHZlcnNp b24gb2YgJnF1b3Q7RG9uJ3QgZG8gdGhhdCEmcXVvdDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0IHNo b3VsZCBiZSBleHBsYWluZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgTm8sIGZyb20gdGhlIHN0YXJ0 IG9mIHRoZSBMSVNQIGRlc2lnbiAoY2lyY2EgMjAwNyksIGFuIHByZWZpeCBpcyB3aGF0IG1vdmVz Ljxicj4NCiZndDsgQW5kIGEgc3BlY2lmaWMgRUlEIGlzIHNpbXBseSBhIC8zMiBvciAvMTI4IHBy ZWZpeC4gSGVyZSBpcyBhIHByYWN0aWNhbDxicj4NCiZndDsgZXhhbXBsZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBZb3UgaGF2ZSBhIGNsdXN0ZXIgb2Ygc2VydmVycyB0aGF0IGNvbW11bmljYXRlIHRv Z2V0aGVyIGZvciBhIHBhcnRpY3VsYXI8YnI+DQomZ3Q7IGFwcGxpY2F0aW9uLiBUaGV5IGFwcGxp Y2F0aW9uIGNsdXN0ZXIgaXMgcnVubmluZyBpbiBhIHNldCBvZiBWTXMuIFRob3NlIFZNczxicj4N CiZndDsgYXJlIGFzc2lnbmVkIEVJRHMgZnJvbSBhIGNvbW1vbiBwb3dlci1vZi0yIEVJRC1wcmVm aXguIFRob3NlIFZNcyBhcmUgY3VycmVudGx5PGJyPg0KJmd0OyBydW5uaW5nIGluIGEgYnJpY2st YW5kLW1vcnRhciBkYXRhIGNlbnRlci4gTm93IHRoZXJlIGlzIGEgZGVzaXJlIHRvIG1vdmUgdGhl PGJyPg0KJmd0OyBWTSBjbHVzdGVyIHRvIGEgY2xvdWQgcHJvdmlkZXIuIFdoYXQgaXMgbW92ZWQg aXMgdGhlIEVJRC1wcmVmaXggb2YgdGhlPGJyPg0KJmd0OyBjbHVzdGVyLiBUaGUgbWFwcGluZyBz eXN0ZW0gaXMgdG9sZCB0aGF0IHRoZSBFSUQtcHJlZml4IGlzIGNoYW5naW5nIGl0cyBSTE9DLTxi cj4NCiZndDsgc2V0IGZyb20gdGhlIGJyaWNrLWFuZC1tb3J0YXIgeFRScyB0byB0aGUgY2xvdWQg cHJvdmlkZXJzIHhUUnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IC0gNy40LiZuYnNwOyBMSVNQIGZvciBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkgaW4g RGF0YSBDZW50ZXJzPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSBkb24n dCB1bmRlcnN0YW5kIGhvdyB0aGlzIHdvcmtzIHdoZW4gRUlEIHByZWZpeGVzIGFyZSB1c2VkLCBh cyBlYWNoIFZNPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBoYXMgaXRzIG93biBFSUQgb3IgRUlEcywgaGVu Y2UgdGhlIGVudGlyZSBwcmVmaXggcmFuZ2UgZG9lcyBub3QgbW92ZSB3aGVuPGJyPg0KJmd0OyAm Z3Q7Jmd0OyB0aGUgVk0gbW92ZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgRm9yIE9QUy1EaXIsIHRoaXMgRUlEIHByZWZpeCBpc3N1ZSBbQV0gZmFsbHMgdW5kZXIgQS4x LjEgaW4gQXBwZW5kaXggQTxicj4NCiZndDsgJmd0OyZndDsgb2YgUkZDIDU3MDY6Jm5ic3A7IEhh cyBkZXBsb3ltZW50IGJlZW4gZGlzY3Vzc2VkPyBhbmQgc3BlY2lmaWNhbGx5IHVuZGVyOjxicj4N CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICombmJzcDsgSXMgdGhlIHByb3Bvc2VkIHNwZWNpZmljYXRpb24gZGVwbG95YWJsZT8mbmJz cDsgSWYgbm90LCBob3cgY291bGQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpdCBiZSBpbXByb3ZlZD88YnI+DQomZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhcyBFSUQgcHJlZml4ZXMgYXBwZWFyIHRvIGJlIHVuZGVwbG95 YWJsZSBmb3IgTW9iaWxpdHkgYW5kIFZNIE1vYmlsaXR5PGJyPg0KJmd0OyB1c2FnZS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBTZWUgYWJvdmUgZXhhbXBsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBbQl0gTElTUCBNdWx0aWNhc3QgdnMuIEVJRC9STE9DIHNlcGFyYXRlPGJyPg0KJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSA2LiBNdWx0aWNhc3Q8YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIGludGVyZXN0aW5nLCBtdWx0aWNhc3QgYWRk cmVzc2VzIChHKSBsb29rIGxpa2UgdGhleSdyZSBhbiBleGNlcHRpb248YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaGV5IGFyZSByZWFsbHkgbm90LiBTaW5jZSBtdWx0aWNhc3QgYWRkcmVzc2VzICppZGVu dGlmeSogYSBncm91cCBvZjxicj4NCiZndDsgcmVjZWl2ZXJzLCBpdCBpcyB2ZXJ5IG11Y2ggYW4g RUlEIGFuZCBhaGVyZXMgdG8gdGhlIGRlZmluaXRpb24gb2YgYW4gRUlELjxicj4NCiZndDsgTXVs dGljYXN0IGFkZHJlc3NlcyBuZXZlciBoYWQgdG9wb2xvZ2ljYWwgc2lnbmZpY2FuY2UgYnV0IHRo ZSBzdGF0ZTxicj4NCiZndDsgcmVwcmVzZW50aW5nIGEgZGlzdHJpYnV0aW9uIHRyZWUgZG9lcyB0 ZWxsIHlvdSB3ZXJlIHRoZSBtZW1iZXJzIGFyZSAoYnV0IHRoZTxicj4NCiZndDsgaWRlbnRpdHkg b2YgdGhlIG1lbWJlcnMgYXJlIG5vdCBrbm93IGluIG11bHRpY2FzdCkuPGJyPg0KJmd0Ozxicj4N CiZndDsgU28gaXQgbWFrZXMgcGVyZmVjdCBzZW5zZSB0byByZWdpc3RlciBtdWx0aWNhc3QgYWRk cmVzc2VzIHRvIHRoZSBtYXBwaW5nPGJyPg0KJmd0OyBzeXN0ZW0gYXMgRUlEcyBhbmQgdGhleSBj YW4gbWFwIHRvIFJMT0NzIG9mIHNpdGVzIHRoYXQgaGF2ZSBqb2luZWQgdGhlIGdyb3VwLjxicj4N CiZndDsgU2VlIGRyYWZ0LWZhcmluYWNjaS1zaWduYWwtZnJlZS1tdWx0aWNhc3QgYXMganVzdCBv bmUgZXhhbXBsZS4gUkZDNjgzMSBhbmQ8YnI+DQomZ3Q7IGRyYWZ0LWZhcmluYWNjaS1saXNwLW1y LXNpZ25hbGluZyBhcmUgb3RoZXIgZXhhbXBsZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgdG8gdGhlIEVJRC9STE9DIHNlcGFyYXRpb24gYXMgdGhlIHNhbWUgZGVzdGluYXRpb24gSVAg bXVsdGljYXN0IGFkZHJlc3M8YnI+DQomZ3Q7ICZndDsmZ3Q7IGlzIHVzZWQgZm9yIGJvdGggcHVy cG9zZXMuJm5ic3A7IFRoaXMgY291bGQgdXNlIHNvbWUgbW9yZSBkaXNjdXNzaW9uLCBhcyBpdCdz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1bmV4cGVjdGVkIGJhc2VkIG9uIHRoZSBjb250ZW50cyBvZiB0 aGUgZHJhZnQgdXAgdG8gdGhpcyBwb2ludC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGJlbGlldmUg dGhlIGxldmVsIG9mIGRldGFpbCB3ZSBoYXZlIGluIHRoZSBpbnRyb2R1Y3Rpb24gZG9jdW1lbnQg aXMgYXQgdGhlPGJyPg0KJmd0OyByaWdodCBsZXZlbCBvciB3ZSdsbCBlcnIgb24gaGF2aW5nIHdh eSB0b28gbWFueSBkZXRhaWxzIGNyb3AgaW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsg LSA3LjIuJm5ic3A7IExJU1AgZm9yIElQdjYgQ28tZXhpc3RlbmNlPGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IExJU1AgZW5jYXBzdWxhdGlvbnMgYWxs b3dzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIHVzaW5nIEVJRHMgZnJvbSBhPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgZ2l2ZW4gYWRkcmVzcyBmYW1pbHkgKGUuZy4sIElQdjYpIHdpdGgg cGFja2V0cyBmcm9tIG90aGVyIGFkZHJlc3M8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyBmYW1pbGllcyAoZS5nLiwgSVB2NCkuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgSG93IGRvZXMgdGhhdCB3b3JrIGZvciBtdWx0aWNhc3QgdHJhZmZpYywgd2hlcmUgdGhl IGRlc3RpbmF0aW9uIGFkZHJlc3M8YnI+DQomZ3Q7ICZndDsmZ3Q7IChHKSBoYXMgdG8gYmUgdGhl IHNhbWUgaW4gYm90aCB0aGUgaW5uZXIgYW5kIG91dGVyIGhlYWRlcnM/Jm5ic3A7IEFyZSBFVFJz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhbmQgSVRScyBleHBlY3RlZCB0byBtYXAgSVB2NiBtdWx0aWNh c3QgYWRkcmVzc2VzIHRvIElQdjQgYW5kIHYudi4/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIG1h cHBpbmcgc3lzdGVtIGNhbiBtYXAgYW4gKFMtRUlELWlwdjYsIGdyb3VwLWlwdjYpIDItdHVwbGUg dG8gYSBSTE9DIHNldDxicj4NCiZndDsgdGhhdCBsb29rZWQgbGlrZSB0aGlzIChpcHY0LW11bHRp Y2FzdCwgaXB2NC11bmljYXN0KSBtZWFuIHRoZSBJVFIgdGhhdDxicj4NCiZndDsgcmVjZWl2ZXMg dGhlIHBhY2tldCBmcm9tIFMtRUlELWlwdjYgd291bGQgcmVwbGljYXRlIHRoZSBwYWNrZXQgYW5k IG11bHRpY2FzdDxicj4NCiZndDsgZW5jYXBzdWxhdGUgdG8gaXB2NC1tdWx0aWNhc3QgYW5kIHVu aWNhc3QgZW5jYXBzdWFsdGUgdG8gaXB2NC11bmljYXN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IC0gNy4zLiZuYnNwOyBMSVNQIGZvciBWaXJ0dWFsIFByaXZhdGUgTmV0d29ya3M8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGFsc28gaGFzIG11bHRpY2Fz dCBwcm9ibGVtcywgYXMgdGhlcmUgaXMgb25seSBvbmUgaW5zdGFuY2Ugb2YgZWFjaDxicj4NCiZn dDsgJmd0OyZndDsgbXVsdGljYXN0IGFkZHJlc3MgKEcpIGluIHRoZSB1bmRlcmxheSBuZXR3b3Jr LiZuYnNwOyBJIHRoaW5rIEkgY2FuIGZpZ3VyZSBvdXQ8YnI+DQomZ3Q7IGhvdzxicj4NCiZndDs8 YnI+DQomZ3Q7IFlvdSBjYW4gbWFwIGZyb20gRUlELUcgdG8gUkxPQy1HIG9uZSB0byBvbmUuIEJ1 dCB3ZSBoYXZlIHNlZW4gb3ZlciB0aGUgbGFzdDxicj4NCiZndDsgZGVjYWRlIGluIGEgaGFsZiB0 aGF0IHdpdGggZ2VuZXJhbCBtdWx0aWNhc3QgZGVwbG95bWVudCB0aGF0IG1hbnktdG8tMSBpczxi cj4NCiZndDsgZGVzaXJhYmxlLiBIZW5jZSwgbm93IHRoYXQgd2UgaGF2ZSBhIHdheSB0byBtYXAg d2l0aCBhIG5ldHdvcmstYmFzZWQgZGF0YWJhc2UsPGJyPg0KJmd0OyB3ZSBjYW4gbWFwIG11bHRp cGxlIEVJRC1HcyB0byBhIHNpbmdsZSAob3IgbXVsdGlwbGUpIFJMT0MtR3MuPGJyPg0KJmd0Ozxi cj4NCiZndDsgJmd0OyZndDsgdG8gbWFrZSBtdWx0aWNhc3Qgd29yayBmb3IgdGhpcyB1c2UgY2Fz ZSwgYnV0IGl0J3Mgbm90IGltbWVkaWF0ZWx5IG9idmlvdXMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBh bmQgdGhlIHJlc3VsdCB3aGVuIHRoZSBzYW1lIHVuZGVybGF5IG11bHRpY2FzdCBhZGRyZXNzIGlz IHVzZWQgYnkgbW9yZTxicj4NCiZndDsgJmd0OyZndDsgdGhhbiBvbmUgVlBOIGNvdWxkIHdlbGwg ZGVsaXZlciBzb21lIHRyYWZmaWMgdG8gRVRScyB0aGF0IGhhdmUgdG8gZGlzY2FyZDxicj4NCiZn dDs8YnI+DQomZ3Q7IFRoaXMgaXMgYSBuZWNlc3NhcnkgZXZpbCB3aGVuIHRoZSB1bmRlcmxheSBp cyBzdGF0ZSBjaGFsbGVuZ2VkLiBCdXQgaXQgaXMgYTxicj4NCiZndDsgc3RhdGUvYmFuZHdpZHRo IHRyYWRlb2ZmLiBXZSBoYXZlIGZvdW5kIHdpdGggTVZQTiBkZXBsb3ltZW50IHRoYXQgdGhlIG5l dHdvcms8YnI+DQomZ3Q7IGFkbWluIGNvbmZpZ3VyZXMgdGhlIHVuZGVybHkgb3Igc2ltcGx5IHVu aWNhc3RzLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0IGJlY2F1c2UgdGhlIEluc3Rh bmNlIElEIGlzIHdyb25nIChhbmQgdGhhdCBleGNlc3NpdmUgZGVsaXZlcnkgaXMgYTxicj4NCiZn dDsgJmd0OyZndDsgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiwgc2VlIG1pbm9yIGlzc3VlIG9uIFNl Y3Rpb24gOCBiZWxvdykuJm5ic3A7IEkgdGhpbmsgYW48YnI+DQomZ3Q7ICZndDsmZ3Q7IGV4cGxh bmF0aW9uIGlzIGluIG9yZGVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSBqdXN0IHRv byBtYW55IGNvbWJpbmF0aW9ucyB0byBtYWtlIGEgaGlnaC1sZXZlbCBkZXNjcmlwdGlvbiBzaW1w bGU8YnI+DQomZ3Q7IHRvIHVuZGVyc3RhbmQuIFRoZSBjdXJyZW50IGludHJvZHVjdGlvbiB0ZXh0 IGRvZXMgYSBmaW5kIGpvYiBwcm92aWRpbmc8YnI+DQomZ3Q7IHJlZmVyZW5jZXMgZm9yIHNvbWVv bmUgdG8gZ28gb2ZmIGFuZCBnZXQgdGhlIGRldGFpbHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgLS0gTWlub3IgSXNzdWVzIC0tPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgVGhlcmUgc2VlbXMgdG8gYmUgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiB0aGF0IHRoZSBl bmQgaG9zdCBhbmQgaXRzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJVFIgKHhUUikgYXJlIGluIHRoZSBz YW1lIGRvbWFpbiBvciBBdXRvbm9tb3VzIFN5c3RlbS4mbmJzcDsgRm9yIGluY3JlbWVudGFsPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhpcyBpcyB0cnVlIHdoZW4geW91IGNhbGwgdGhlIGRvbWFpbiBh ICZxdW90O0xJU1Agc2l0ZSZxdW90Oy4gQnV0IGlmIHRoZSBzaXRlIGlzPGJyPg0KJmd0OyB1bmNo YW5nZWQgYW5kIG9uZSB1c2VzIFBJVFJzLCBtYXliZSBldmVuIGNsb3NlIHRvIHRoZSBzaXRlLCBs aWtlIGluIGEgUEU8YnI+DQomZ3Q7IHJvdXRlciwgdGhlbiB0aGUgUElUUiBpcyBkZWZpbml0ZWx5 IGluIGFub3RoZXIgQVMuIEJ1dCBub3RlIEkgc2FpZCBQSVRSIGFuZDxicj4NCiZndDsgbm90IElU Ui4gVGhlIHJlYXNvbiBiZWluZyBpcyBiZWNhdXNlIGFuIElUUiBpcyBjb25maWd1cmVkIHdpdGgg ZGF0YWJhc2UtPGJyPg0KJmd0OyBtYXBwaW5nIHByZWZpeGVzIHRoYXQgaXMgdXNlcyB0byBlbmNh cHN1bGF0ZSBwYWNrZXRzIGZyb20gc3VjaCBhZGRyZXNzZXMuPGJyPg0KJmd0OyBWZXJzdXMgdGhl IFBJVFIgYmVpbmcgYW4gSVRSIHdpdGggKm5vIGRhdGFiYXNlLW1hcHBpbmdzKiBwcm92aWRpbmcg YSBtdWNoIG1vcmU8YnI+DQomZ3Q7IGxhcmdlci9vciBtb3JlIGFnZ3JlZ3RhYmxlIHNlcnZpY2Uu PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgZGVwbG95bWVudCwgSSBkb24ndCB0aGluayB0 aGF0J3MgYWx3YXlzIHRoZSBjYXNlLCBidXQgSSB0aGluayB0aGF0IG9ubHk8YnI+DQomZ3Q7ICZn dDsmZ3Q7IGhhcyBlZGl0b3JpYWwgaW1wYWN0IG9uIHRoaXMgZG9jdW1lbnQsIGFzIEkgZG9uJ3Qg dGhpbmsgYW55IG9mIHRoZTxicj4NCiZndDsgJmd0OyZndDsgZnVuZGFtZW50YWwgTElTUCBtZWNo YW5pc21zIGFyZSBhZmZlY3RlZC4mbmJzcDsgVGhlIGF1dGhvcnMgc2hvdWxkIGxvb2sgZm9yPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyB1c2Ugb2YgJnF1b3Q7ZG9tYWluJnF1b3Q7IGFuZCAmcXVvdDtBdXRv bm9tb3VzIFN5c3RlbSZxdW90OyBhbmQgZW5zdXJlIHRoYXQgdGhlIHRleHQgaXM8YnI+DQomZ3Q7 ICZndDsmZ3Q7IGdlbmVyYWxpemVkIHRvIHRoZSBjYXNlIHdoZXJlIHRoZSBlbmQgaG9zdCBhbmQg SVRSIGFyZSBtb3JlIHdpZGVseTxicj4NCiZndDsgJmd0OyZndDsgc2VwYXJhdGVkLjxicj4NCiZn dDs8YnI+DQomZ3Q7IFdlIGFyZSBvdmVybG9hZGVkIHdpdGggdGVybXMgdGhhdCBjcmVhdGUgdG9w b2xvZ2ljYWwgb3Igb3JnYW5pemF0aW9uIGJvdW5kYXJ5Ljxicj4NCiZndDsgSGVuY2Ugd2h5IHdl IGNyZWF0ZWQgJnF1b3Q7TElTUCBzaXRlJnF1b3Q7IHdoaWNoIGlzIGFsc28gdGhlIHNhbWUgYXMg YSAmcXVvdDtMSVNQIFZQTiBzaXRlJnF1b3Q7Ljxicj4NCiZndDsgV2hlcmUgYSAmcXVvdDtMSVNQ IHNpdGUmcXVvdDsgdGhhdCBoYXMgbXVsdGlwbGUgdGVubmFudHMgd291bGQgYmUgbXVsdGlwbGUg JnF1b3Q7TElTUCBWUE48YnI+DQomZ3Q7IHNpdGVzJnF1b3Q7Ljxicj4NCiZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7IERlc3BpdGUgbXVsdGlwbGUmbmJzcDsgbWVudGlvbnMgb2YgaW5jcmVtZW50YWwg ZGVwbG95bWVudCwgSSBkaWQgbm90PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzZWUgYSBkaXNjdXNzaW9u IG9mIGhvdyB0aGF0IG1pZ2h0IGJlIGFjY29tcGxpc2hlZC4mbmJzcDsgVGhlcmUgaXMgc29tZTxi cj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSBQeFRScyBhbmQgTkFUcy4gQW5kIHJlZmVyZW5j ZXMgdG8gdGhlIExJU1AgaW50ZXJ3b3JraW5nIFJGQy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyB1c2VmdWwgY29udGVudCBpbiBTZWN0aW9uIDMuNSwgYnV0IHRoYXQncyBhdCBiZXN0IGFu IGluY29tcGxldGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGV4cGxhbmF0aW9uLiZuYnNwOyBUaGlzIGlz IGFuIE9QUy1EaXIgcmV2aWV3IGNvbmNlcm4gLSBpdCBmYWxscyB1bmRlcjxicj4NCiZndDsgJmd0 OyZndDsgQS4xLjMgaW4gQXBwZW5kaXggQSBvZiBSRkMgNTcwNjogSGFzIHRoZSBtaWdyYXRpb24g cGF0aCBiZWVuIGRpc2N1c3NlZD88YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAtIDMuMy4xLiZuYnNwOyBMSVNQIEVuY2Fwc3VsYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhlIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVk IGJ5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhlIElUUiBhbmQgaWdub3JlZCBv biByZWNlcHRpb24uPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgUGxlYXNl IG1lbnRpb24gbXVsdGlwYXRoaW5nIChlLmcuLCBFQ01QIGFuZCBMQUcpIGFzIHBvc3NpYmxlIGlu Zmx1ZW5jZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9uIGhvdyBzb3VyY2UgcG9ydHMgYXJlIHNlbGVj dGVkLCBhcyB0aGlzIGltcG9zZXMgc29tZSBsaW1pdHMgb24gd2hhdCBhbjxicj4NCiZndDsgJmd0 OyZndDsgSVRSIGNhbiByZWFzb25hYmx5IGRvLjxicj4NCiZndDs8YnI+DQomZ3Q7IEVDTVAvTEFH IGRvbid0IGluZmx1ZW5jZSB3aGljaCBzb3VyY2UgcG9ydCBpcyBzZWxlY3RlZC4gSXQgaXMgYSA1 LXR1cGxlIGhhc2g8YnI+DQomZ3Q7IG9mIHRoZSBpbm5lciBoZWFkZXIgdGhhdCBzZWxlY3RzIGEg c291cmNlIHBvcnQgdGhhdCBpbmZsdWVuY2VzIGhvdyBhbiB1bmRlcmxheTxicj4NCiZndDsgcm91 dGVyIHdvdWxkIGxvYWQtc3BsaXQgdHJhZmZpYy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBGb3IgT1BTLURpciwgdGhpcyBtdWx0aXBhdGhpbmcgY29uY2VybiBmYWxscyB1bmRlciBBLjEu NCBpbiBBcHBlbmRpeCBBIG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBSRkMgNTcwNjogSGF2ZSB0aGUg UmVxdWlyZW1lbnRzIG9uIG90aGVyIHByb3RvY29scyBhbmQgZnVuY3Rpb25hbDxicj4NCiZndDsg Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29tcG9uZW50cyBiZWVuIGRpc2N1 c3NlZD88YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg VGhpcyBkZWNpc2lvbiB3YXMgbWFkZSBiZWNhdXNlIHRoZTxicj4NCiZndDsgJmd0OyZndDsmbmJz cDsgJm5ic3A7IHR5cGljYWwgdHJhbnNwb3J0IHByb3RvY29scyB1c2VkIGJ5IHRoZSBhcHBsaWNh dGlvbnMgYWxyZWFkeSBpbmNsdWRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgYSBj aGVja3N1bSwgYnkgbmVnbGVjdGluZyB0aGUgYWRkaXRpb25hbCBVRFAgZW5jYXBzdWxhdGlvbiBj aGVja3N1bTxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHhUUnMgY2FuIGZvcndhcmQg cGFja2V0cyBtb3JlIGVmZmljaWVudGx5Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IEdyb2FuISZuYnNwOyBJIGhhdmUgYW4gZXhxdWlzaXRlIHNldCBvZiBzY2FycyBvbiBV RFAgemVybyBjaGVja3N1bXMgZm9yIElQdjY8YnI+DQomZ3Q7ICZndDsmZ3Q7IGZyb20gd29ya2lu ZyBvbiB0aGUgTVBMUyBpbiBVRFAgZHJhZnQsIHNvIEkgbWF5IGJlIG92ZXJseSBzZW5zaXRpdmUg dG88YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoaXMgY29uY2Vybi4mbmJzcDsgVGhlIGRvd25zaWRlIG9m IHRoaXMgZWZmaWNpZW5jeSBpcyB0aGF0IHRoZXJlIGlzIG5vPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBj aGVja3N1bSBjb3ZlcmFnZSBvZiB0aGUgSVB2NiBoZWFkZXIgd2hlbiB6ZXJvIFVEUCBjaGVja3N1 bXMgYXJlIHVzZWQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGF0IHNob3VsZCBhdCBsZWFzdCBiZSBt ZW50aW9uZWQgaGVyZSwgd2l0aCBhIHN1bW1hcnkgb2Ygd2h5IHRoYXQncyBvazxicj4NCiZndDsg Jmd0OyZndDsgLSB0aGUgZGV0YWlsZWQganVzdGlmaWNhdGlvbiBmb3Igd2h5IHRoYXQncyBvayBj YW4gYmUgbGVmdCB0byBvdGhlcjxicj4NCiZndDsgJmd0OyZndDsgZG9jdW1lbnRzLjxicj4NCiZn dDs8YnI+DQomZ3Q7IE15IGhlYWQgc3BpbnMgZXZlcnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBz dWJqZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW48YnI+DQomZ3Q7IHRhbGtlZCBhYm91dCBmcm9t IDEwMHMgb2YgcGVvcGxlIGZvciBhIGRlY2FkZS4gV2UgaGF2ZSBDUkMgb24gbGlua3MsIHdlIGhh dmU8YnI+DQomZ3Q7IGFwcHMgdGhhdCB1c2UgVENQIGFuZCBVRFAgY2hlY2tzdW1zLiBOdWYgc2Fp ZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS0gTml0 cy9FZGl0b3JpYWwgQ29tbWVudHMgLS08YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyAtIFRvcCBvZiBwLjQ6PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsm bmJzcDsgJm5ic3A7IFRoZSBpbml0aWFsIG1vdGl2YXRpb24gaW4gdGhlIExJU1AgZWZmb3J0IGlz IHRvIGJlIGZpbmQgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsg JnF1b3Q7ZmluZCZxdW90OyAtJmd0OyAmcXVvdDtmb3VuZCZxdW90Ozxicj4NCiZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gU2VjdGlvbiAzLjEsIGZpcnN0IGJ1bGxldCBpdGVtPGJy Pg0KJmd0Ozxicj4NCiZndDsgV2Ugd2lsbCBjZXJ0YWlubHkgZml4ZSB0aGVzZS4gVGhhbmtzLjxi cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0RldmljZXMgYXJlIGFzc2lnbmVkIHdpdGggcmVsYXRpdmVseSBvcGFx dWUgaWRlbnRpdHk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 bWVhbmluZ2Z1bCBhZGRyZXNzZXMgdGhhdCBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlaXIgdG9wb2xv Z2ljYWw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bG9jYXRp b24uPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSBkb24ndCB1bmRlcnN0 YW5kICZxdW90O3JlbGF0aXZlbHkgb3BhcXVlIGlkZW50aXR5IG1lYW5pbmdmdWwmcXVvdDsgYW5k PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzdWdnZXN0IHJld3JpdGluZyB0aGUgc2VudGVuY2UuJm5ic3A7 IEluIHBhcnRpY3VsYXIgLSBvcGFxdWUgdG8gd2hhdD88YnI+DQomZ3Q7ICZndDsmZ3Q7IG1lYW5p bmdmdWwgdG8gd2hhdCBpbiB3aGF0IG1hbm5lcj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZWxsIGJl YWN1c2UgaXQgaXMgYXMgYWNjdXJhdGUgYXMgaXQgY2FuIGJlLiBJZiBhdXRvbW9iaWxlcyBhcmUg Z29pbmcgdG8gYmU8YnI+DQomZ3Q7IGFzc2lnbmVkIEVJRHMgZnJvbSBhIFZJTiBudW1iZXIgYWxs b2NhdGlvbiBmcm9tIGEgbWFudWZhY3R1cmUsIHRoZSBhZGRyZXNzIGlzPGJyPg0KJmd0OyByZWxh dGl2ZWx5IG9wYXF1ZS4gSWYgYSBWTSBpbiBhIGRhdGEtY2VudGVyIGlzIGdvaW5nIHRvIGJlIGFz c2lnbmVkIGFuIEVJRDxicj4NCiZndDsgZnJvbSB0aGUgc2V0IG9mIHByZWZpeGVzIGFscmVhZHkg YmVpbmcgdXNlZCBhbmQgYWxsb2NhdGVkIHRvIHRoYXQgZGF0YS1jZW50ZXIsPGJyPg0KJmd0OyB0 aGVuIHRoZXJlIGlzIGEgZ29vZCBjaGFuY2UgdGhhdCBhZGRyZXNzIGlzIGluIGEgcG93ZXItb2Yt MiBibG9jayB0aGF0IGlzPGJyPg0KJmd0OyBzdW1tYXJpemFibGUgaW4gdGhlIElHUC48YnI+DQom Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSBTZWN0aW9uIDMuMiwg c2Vjb25kIHBhcmFncmFwaDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEp1 ZGdpbmcgZnJvbSB0aGUgZmlndXJlLCB4VFJzIGFyZSB0aGUgY29tbW9uIGNhc2UsIHdpdGggc2lu Z2xlLTxicj4NCiZndDsgJmd0OyZndDsgZnVuY3Rpb24gSVRScyBhbmQgRVRScyBiZWluZyByYXJl LiZuYnNwOyBJdCBtaWdodCBiZSBnb29kIHRvIHNheSB0aGF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBh bmQgZGlzY3VzcyB3aGVuIElUUnMgYW5kIEVUUnMgdGhhdCBhcmUgbm90IHhUUnMgYXJlIGFwcHJv cHJpYXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0byB1c2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hl biB5b3Ugd2FudCBlZ3Jlc3MgcGF0aCBzZWxlY3Rpb24gdG8gaGFwcGVuIGZ1cnRoZXIgb3V0IGlu IHRoZSB0b3Bsb2dpY2FsPGJyPg0KJmd0OyBmcm9tIHRoZSBzb3VyY2UgbG9jYXRpb24sIHRoZW4g eW91IHB1dCBhbiBJVFItb25seSBzeXN0ZW0gdGhlcmUuIFdoZXJlIGluZ3Jlc3M8YnI+DQomZ3Q7 IHRvIHRoZSBzYW1lIHNvdXJjZSAoZGVzdGluYXRpb24gaW4gdGhpcyBkaXJlY3Rpb24pLCB0aGUg RVRSIGNhbiBiZSBjbG9zZXIgdG88YnI+DQomZ3Q7IHRoZSBkZXN0aW5hdGlvbi48YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSAzcmQgcGFyYWdyYXBoIG9u IHAuNzo8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmbmJzcDsgJm5ic3A7IEZpbmFsbHksIHRoZSBMSVNQIGFyY2hpdGVjdHVyZSBlbXBoYXNp emVzIGEgY29zdCBlZmZlY3RpdmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBpbmNy ZW1lbnRhbCBkZXBsb3ltZW50Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 IEknZCBkZWxldGUgJnF1b3Q7Y29zdCBlZmZlY3RpdmUmcXVvdDsgaGVyZSBhbmQgbG9vayBmb3Ig b3RoZXIgb2NjdXJyZW5jZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9mICZxdW90O2Nvc3QmcXVvdDsg YXMgY2FuZGlkYXRlcyBmb3IgZGVsZXRpb24uJm5ic3A7IFRoaXMgaXMgc3VwcG9zZWQgdG8gYmU8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGEgdGVjaG5pY2FsIGRvY3VtZW50LCBzbyBkaXNjdXNzaW9uIG9m IGNvc3RzIGlzIGEgYml0IG9mZi10YXJnZXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgRmFpciBlbm91 Z2guPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSBGaXJzdCBpdGVtIGFmdGVyIEZpZ3Vy ZSAyOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAx LiZuYnNwOyBIb3N0QSByZXRyaWV2ZXMgdGhlIEVJRF9CIG9mIEhvc3RCLCB0eXBpY2FsbHkgcXVl cnlpbmcgdGhlIEROUzxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgYW5kIG9idGFpbmluZyBhbmQgQSBvciBBQUFBIHJlY29yZC48YnI+DQomZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmcXVvdDthbmQgQSZxdW90OyAtJmd0OyAmcXVvdDthbiBBJnF1 b3Q7Jm5ic3A7IChzcGVsbGluZyBjaGVja2VycyBkb24ndCBjYXRjaCBldmVyeXRoaW5nKS48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBBbHJlYWR5IG5vdGVkIGFuZCB3aWxsIGJlIGZpeGVkLjxicj4NCiZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtIDMuMy4xLiZuYnNwOyBM SVNQIEVuY2Fwc3VsYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIFJlY3Vyc2l2ZTxicj4NCiZndDsgJmd0OyZn dDsmbmJzcDsgJm5ic3A7IHR1bm5lbHMgYXJlIG5lc3RlZCB0dW5uZWxzIGFuZCBhcmUgaW1wbGVt ZW50ZWQgYnkgdXNpbmcgbXVsdGlwbGUgTElTUDxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5i c3A7IGVuY2Fwc3VsYXRpb25zIG9uIGEgcGFja2V0Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7IFRoZSBhYm92ZSBzZW50ZW5jZSBzZWVtcyBvdXQgb2YgcGxhY2UgaW4gdGhl IG1pZGRsZSBvZiBhIHBhcmFncmFwaCBhYm91dDxicj4NCiZndDsgJmd0OyZndDsgUmUtZW5jYXBz dWxhdGluZyB0dW5uZWxzIGFuZCByb3V0ZXJzIC0gSSBzdWdnZXN0IG1vdmluZyBpdCBkb3duIGlu dG8gaXRzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvd24gcGFyYWdyYXBoIGFuZCBwZXJoYXBzIGFkZGlu ZyBhIHNlbnRlbmNlIGFib3V0IHdoZXJlL2hvdyBSZWN1cnNpdmU8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHR1bm5lbHMgbWF5IGJlIHVzZWZ1bC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBHb29kIHN1Z2dlc3Rp b24gYW5kIG1ha2VzIHNlbnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0gMy4zLjIu Jm5ic3A7IExJU1AgRm9yd2FyZGluZyBTdGF0ZTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBJbiB0aGUgTElTUCBhcmNoaXRlY3R1cmUsIElUUnMga2Vl cCBqdXN0IGVub3VnaCBpbmZvcm1hdGlvbiB0byByb3V0ZTxicj4NCiZndDsgJmd0OyZndDsmbmJz cDsgJm5ic3A7IHRyYWZmaWMgZmxvd2luZyB0aHJvdWdoIGl0Ljxicj4NCiZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZxdW90O2l0LiZxdW90OyAtJmd0OyAmcXVvdDt0aGVtLiZxdW90 Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBNZWFu aW5nIHRoYXQsIElUUnMgcmV0cmlldmUgZnJvbSB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyBMSVNQIE1hcHBpbmcgU3lzdGVtIG1hcHBpbmdzIGJldHdlZW4gRUlEIHByZWZpeGVz IGFuZCBSTE9DcyB0aGF0IGFyZTxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHVzZWQg dG8gZW5jYXBzdWxhdGUgcGFja2V0cy48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBUaGlzIGlzIHRoZSBmaXJzdCB1c2Ugb2YgdGhlIG5vdGlvbiBvZiBFSUQgcHJlZml4ZXMu Jm5ic3A7IFRoYXQgY29uY2VwdCBzaG91bGQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IGJlIGV4cGxhaW5l ZCBiZWZvcmUgaXQgaXMgdXNlZCwgYWx0aG91Z2ggYSBmb3J3YXJkIHJlZmVyZW5jZSB0byBzZWN0 aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAzLjQuMSBtYXkgc3VmZmljZS4mbmJzcDsgSXQgbWlnaHQg YmUgYmV0dGVyIHRvIHJld3JpdGUgdGhpcyBwYXJhZ3JhcGggaW4gdGVybXM8YnI+DQomZ3Q7ICZn dDsmZ3Q7IG9mIEVJRHMgYW5kIGxlYXZlIHRoZSBub3Rpb24gb2YgRUlEIHByZWZpeGVzIHRvIHNl Y3Rpb24gMy40LjEuPGJyPg0KJmd0Ozxicj4NCiZndDsgSG1tLCBJJ2xsIGxldCBBbGJlcnQgYW5k IERhbWllbiBkZWNpZGUgaWYgd2Ugc2hvdWxkIHN0YXRlICZxdW90O0VJRC1wcmVmaXhlcyZxdW90 Ozxicj4NCiZndDsgZXZlcnl3aGVyZSBpbnN0ZWFkIG9mIGp1c3QgJnF1b3Q7RUlEJnF1b3Q7Ljxi cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtIDQuNC4mbmJz cDsgTVRVIEhhbmRsaW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmbmJz cDsgJm5ic3A7IEFkZGl0aW9uYWxseSwgTElTUCBhbHNvIHJlY29tbWVuZHMgaW5mZXJyaW5nIHJl YWNoYWJpbGl0eSBvZiBsb2NhdG9yczxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IGJ5 IHVzaW5nIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSB1bmRlcmxheSwgaW4gcGFydGljdWxh cjo8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJdCdkIGJlIHVzZWZ1bCB0 byBhZGQgYSBzZW50ZW5jZSBvciB0d28gYWJvdXQgaG93IExJU1AgYW5kIHRoZSB0ZWNobmlxdWVz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbiB0aGlzIHNlY3Rpb24gaW50ZXJhY3Qgd2l0aCBob3N0IHVz ZSBvZiBQTVRVRCBhbmQgUExQTVRVRC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGlzIGEgbG90 IG9mIGRldGFpbCBiZWNhdXNlIGluIFJGQzY4MzAgd2UgaGF2ZSAzIHBvc2l0aW9ucyBvciBvcHRp b25zIG9uPGJyPg0KJmd0OyB0aGUgc3ViamVjdC4gQW5kIHdlIGRpZCBwcm92aWRlIGEgcmVmZXJl bmNlIHRvIFJGQzY4MzAgZm9yIHRoaXMgdG9waWMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgLSBOZXh0IHRvIGxhc3QgcGFyYWdyYXBoIG9uIHAuMTc6PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IEFkZGl0aW9uYWxseSwgTElTUCBhbHNvIHJl Y29tbWVuZHMgaW5mZXJyaW5nIHJlYWNoYWJpbGl0eSBvZiBsb2NhdG9yczxicj4NCiZndDsgJmd0 OyZndDsmbmJzcDsgJm5ic3A7IGJ5IHVzaW5nIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSB1 bmRlcmxheSwgaW4gcGFydGljdWxhcjo8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBUaGlzIGxvb2tzIGxpa2UgaXQncyBhIHBhcmFncmFwaCBlYXJseSBhbmQgbmVlZHMgdG8g YmUgbW92ZWQgZG93biB0bzxicj4NCiZndDsgJmd0OyZndDsgYWZ0ZXIgdGhlIHBhcmFncmFwaCB0 aGF0IGZvbGxvd3MgaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWdyZWUuPGJyPg0KJmd0Ozxicj4N CiZndDsgJmd0OyZndDsgaWRuaXRzIDIuMTMuMDEgZGlkbid0IGZpbmQgYW55IG5pdHMuPGJyPg0K Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsgJmd0OyZn dDsgLS1EYXZpZDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBhZ2FpbiBEYXZpZC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBEaW5vPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D2432779493636438EMX104CL02corpemcc_-- From nobody Wed Feb 11 17:59:30 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8451A8A3E; Wed, 11 Feb 2015 17:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxcgLYafeyg0; Wed, 11 Feb 2015 17:59:16 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FBE1A8A25; Wed, 11 Feb 2015 17:59:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BC7D41BC8762; Wed, 11 Feb 2015 17:59:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from localhost (mobile-166-171-058-239.mycingular.net [166.171.58.239]) by mailc2.tigertech.net (Postfix) with ESMTPA id F33B01BC8724; Wed, 11 Feb 2015 17:59:12 -0800 (PST) Date: Wed, 11 Feb 2015 20:59:06 -0500 Message-ID: Importance: low From: "Jmh.direct" To: david.black@emc.com, acabello@ac.upc.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_127491863198918" Archived-At: Cc: ops-dir@ietf.org, lisp@ietf.org, damien.saucez@inria.fr, ietf@ietf.org Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:59:23 -0000 ----_com.android.email_127491863198918 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGVtZWJlciB0aGF0IGFuIEVJRCBwcmVmaXggcmVwcmVzZW50cyBhIHNpdGUuIMKgQSB0ZW5hbnQg bmV0d29yayBpbiBhIGRhdGEgY2VudGVyIGlzIGEgdmlhYmxlIHNpdGUuIMKgU28gdGhlIHByZWZp eCBhcyByZWdpc3RlcmVkIGZvciB0aGF0LiDCoE1vYmlsdXR5IG9mIFZNcyB3aXRoIHRoZSB0ZW5h bnQgbmV0d29yayBjYW4gYmUgaGFuZGxlZCBpbnRlcm5hbGx5LgoKWXB1IGNvdWxkIGluc3RlYWQg YWR2ZXJ0aXNlIGVhY2ggVk0gRUlELiDCoFRnZSBmYWN0IHRoYXQgYm90aCBjYXNlZCB3b3JrIG1h a2VzIGRvaW5nIGFuIGludHJvZHVjdG9yeSBkZXNjcmlwdGlvbiBhIGJpdCB0cmlja3kuCgpZb3Vy cywKSm9lbAoKClNlbnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmVAoKLS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpTdWJqZWN0OiBSRTogW2xpc3BdIE9QUy1EaXIg cmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTEgCkZyb206ICJCbGFjaywg RGF2aWQiIDxkYXZpZC5ibGFja0BlbWMuY29tPiAKVG86ICJKbWguZGlyZWN0IiA8am1oLmRpcmVj dEBqb2VsaGFscGVybi5jb20+LCJhY2FiZWxsb0BhYy51cGMuZWR1IiA8YWNhYmVsbG9AYWMudXBj LmVkdT4gCkNDOiAiZmFyaW5hY2NpQGdtYWlsLmNvbSIgPGZhcmluYWNjaUBnbWFpbC5jb20+LCJq bWhAam9lbGhhbHBlcm4uY29tIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4sImRhbWllbi5zYXVjZXpA aW5yaWEuZnIiIDxkYW1pZW4uc2F1Y2V6QGlucmlhLmZyPiwib3BzLWRpckBpZXRmLm9yZyIgPG9w cy1kaXJAaWV0Zi5vcmc+LCJpZXRmQGlldGYub3JnIiA8aWV0ZkBpZXRmLm9yZz4sImxpc3BAaWV0 Zi5vcmciIDxsaXNwQGlldGYub3JnPiwiQmxhY2ssIERhdmlkIiA8ZGF2aWQuYmxhY2tAZW1jLmNv bT4gCgo+IEluIHRoZSBWTSBjYXNlLCBhbSBlbnRpcmUgc2VydmljZSBuZXR3b3JrIG1heSBiZSBt b3ZlZCB0byB0aGUgZGF0YSBjZW50ZXIsIGFuZCBzbyB0aGUgRUlEIGJsb2NrIGZvciB0aGF0IHNl dCBjYW4gYmUgbW92ZWQuIMKgCgrCoAoKRm9yIGEgc2luZ2xlIFZNLCB0aGF0IHdvdWxkIGFwcGx5 IGlmIHRoZSBWTSBpcyB1c2luZyBhbiBlbnRpcmUgRUlEIGJsb2NrIC0gbW9zdCBpbmRpdmlkdWFs IFZNcyBhcmVu4oCZdC9kb27igJl0LsKgIEluZGl2aWR1YWwgLzMyIGFuZCAvMTI4IGFkZHJlc3Nl cyBhcmUgY29tbW9uIGZvciBpbmRpdmlkdWFsIFZNcywgc28gdGhhdOKAmXMgd2hhdOKAmXMgbmVl ZGVkIGluIGdlbmVyYWwgZm9yIGluZGl2aWR1YWwgVk0gbW92ZW1lbnQuCgrCoAoKSeKAmWQgZXhw ZWN0IHRoZSBFSUQgYmxvY2sgbW92ZSBjYXNlIHRvIGFwcGx5IGZvciBtb3ZlbWVudCBvZiBhIGdy b3VwIG9mIFZNcyB0aGF0IGFyZSB1c2luZyBzdWNoIGEgYmxvY2sgKGUuZy4sIGFzIGEgc3VibmV0 KSwgYnV0IFZNIGxpdmUgbWlncmF0aW9ucyBjYW5ub3QgYmUgc3luY2hyb25pemVkIGluIGdlbmVy YWwgKGNvbGQgbWlncmF0aW9ucyBvZiBwb3dlcmVkLW9mZiBWTXMgY2FuIGJlLCBvYnZpb3VzbHkp LCBzbyBldmVuIGluIHRoaXMgY2FzZSB3aGVyZSB0aGUgZW50aXJlIEVJRCBibG9jayBtb3Zlcywg aWYgbGl2ZSBWTSBtaWdyYXRpb25zIGFyZSBpbnZvbHZlZCwgdGhlcmUgYXJlIGludGVybWVkaWF0 ZSBzdGFnZXMgd2hlcmUgdGhlIEVJRCBibG9jayBpcyBzcGxpdCBiZXR3ZWVuIExJU1Agc2l0ZXMg Li4uIGFuZCBoZW5jZSAvMzIgYW5kIC8xMjggcHJlZml4ZXMgYXJlIHN0aWxsIHdoYXTigJlzIHdh bnRlZC4KCsKgCgpUaGFua3MsCi0tRGF2aWQKCsKgCgpGcm9tOiBKbWguZGlyZWN0IFttYWlsdG86 am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIApTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEx LCAyMDE1IDc6MTkgUE0KVG86IEJsYWNrLCBEYXZpZDsgYWNhYmVsbG9AYWMudXBjLmVkdQpDYzog ZmFyaW5hY2NpQGdtYWlsLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgZGFtaWVuLnNhdWNlekBp bnJpYS5mcjsgb3BzLWRpckBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZwpT dWJqZWN0OiBSRTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRy b2R1Y3Rpb24tMTEKSW1wb3J0YW5jZTogTG93CgrCoAoKSSB0aGlubCB3ZSBtYXkgd2FudCB0byBz ZXBhcmF0ZSBWTSBtb2JpbGl0eSBmcm9tIG1vYmlsZSBkZXZpY2VzLiDCoE9tIHRoZSBWTSBjYXNl LCBhbSBlbnRpcmUgc2V0dmljZSBuZXR3b3JrIG1heSBiZSBtb3ZlZCB0byB0aGUgZGF0YSBjZW50 ZXIsIGFuZCBzbyB0aGUgRUlEIGJsb2NrIGZvciB0aGF0IHNldCBjYW4gYmUgbW92ZWQuIMKgSW4g dGhlIGNhc2Ugb2YgaW5kaXZpZHVhbGx5IG1vYmlsZSBkZWJpY2VzIG9yIHNvbWUgdmF0aWF0aW9u cyBvbiBkYXRhIGNlbnRlciBtb2JpbGl0eSwgdGhlcmUgaXMgYSBuZWVkIHRvIG1za2Ugc3VyZSB0 aGUgZnVsbCBFSUQgaXMgYWR2ZXJ0aXNlZCBpbiB0aGUgbWFwcGluZyBzeXN0ZW0uCgrCoAoKWW91 cnMsCgpKb2VsCgoKClNlbnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmVAoKCgoK LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpTdWJqZWN0OiBSRTogW2xpc3BdIE9Q Uy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTEgCkZyb206ICJC bGFjaywgRGF2aWQiIDxkYXZpZC5ibGFja0BlbWMuY29tPiAKVG86ICJhY2FiZWxsb0BhYy51cGMu ZWR1IiA8YWNhYmVsbG9AYWMudXBjLmVkdT4gCkNDOiBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2Np QGdtYWlsLmNvbT4sIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+LERhbWll biBTYXVjZXogPGRhbWllbi5zYXVjZXpAaW5yaWEuZnI+LCJvcHMtZGlyQGlldGYub3JnIiA8b3Bz LWRpckBpZXRmLm9yZz4sImlldGZAaWV0Zi5vcmciIDxpZXRmQGlldGYub3JnPiwibGlzcEBpZXRm Lm9yZyIgPGxpc3BAaWV0Zi5vcmc+LCJCbGFjaywgRGF2aWQiIDxkYXZpZC5ibGFja0BlbWMuY29t PiAKCgpIaSBBbGJlcnQsCgrCoAoKQXMgbm90ZWQgYmVsb3csIG9uIHRoZSBFSUQgcHJlZml4IGZv ciBtb2JpbGl0eSBpc3N1ZSwgYSBzaW1wbGUgc3RhdGVtZW50IGluIFNlY3Rpb24gNSB0byB0aGUg ZWZmZWN0IHRoYXQg4oCcaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgYSBWTS9tb2JpbGUgbm9kZSB0 aGUgRUlELXByZWZpeCBzaG91bGQgYmUgLzMyIG9yIC8xMjggKElQdjQgb3IgSVB2NiByZXNwZWN0 aXZlbHkp4oCdIHdpbGwgc3VmZmljZS7CoCBEZXRhaWxzIG9uIHdoYXQgdG8gZG8gd2hlbiB0aGF0 IGFkdmljZSBpcyBpZ25vcmVkIGNhbiBiZSBsZWZ0IHRvIG90aGVyIGRvY3VtZW50cy4KCsKgCgpU aGFua3MsCi0tRGF2aWQKCsKgCgpGcm9tOiBBbGJlcnQgQ2FiZWxsb3MgW21haWx0bzphbGJlcnQu Y2FiZWxsb3NAZ21haWwuY29tXSAKU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSA2 OjMzIFBNClRvOiBCbGFjaywgRGF2aWQKQ2M6IERpbm8gRmFyaW5hY2NpOyBKb2VsIE0uIEhhbHBl cm47IERhbWllbiBTYXVjZXo7IG9wcy1kaXJAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGxpc3BA aWV0Zi5vcmcKU3ViamVjdDogUmU6IFtsaXNwXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRm LWxpc3AtaW50cm9kdWN0aW9uLTExCgrCoAoKSGkgRGF2aWQKCsKgCgpUaGFua3MgZm9yIHlvdXIg Y29tbWVudHMsIEkgYW0gcGFyc2luZyB0aGVtIGFuZCBJwrRsbCBzdWdnZXN0IG5ldyB0ZXh0IGFp bWluZyB0byBhZGRyZXNzIHRoZW0gQVNBUC4KCsKgCgpJIHdvdWxkIGFsc28gbGlrZSB0byBiZXR0 ZXIgdW5kZXJzdGFuZCBbQV0gYmVmb3JlIGRvaW5nIHRoaXMuCgrCoAoKV2l0aCBMSVNQIGFuIEVJ RC1wcmVpZnggY2FuIGhhdmUgYW4gYXJiaXRyYXJ5IGxlbmd0aCBhbmQgY2FuIG1vdmUgKGkuZS4s IGNoYW5nZSBpdHMgUkxPQyBiaW5kaW5ncyksIGluIHRoZSBzcGVjaWZpYyBjYXNlIG9mIGEgVk0v bW9iaWxlIG5vZGUgdGhlIEVJRC1wcmVmaXggc2hvdWxkIGJlIC8zMiBvciAvMTI4IChJUHY0IG9y IElQdjYgcmVzcGVjdGl2ZWx5KS4gV2hhdCBkb2Vzbid0IHdvcmsgaXMgdGhlIG1vYmlsaXR5IG9m IGEgbm9kZSAoYXNzaWduZWQgd2l0aCBhIC8zMiBvciAvMTI4KSAqd2l0aGluKiBhIGNvYXJzZXIg RUlELXByZWZpeCwgaW4gdGhpcyBjYXNlIHlvdSBuZWVkIHRvIHNwbGl0IHRoZSBwcmVmaXggaW50 byBtb3JlIHNwZWNpZmljcyBhbmQgcmVnaXN0ZXIgdGhlbSBpbmRlcGVuZGVudGx5IGluIHRoZSBN YXBwaW5nIFN5c3RlbSwgZWZmZWN0aXZlbHkgY3JlYXRpbmcgbmV3IEVJRC1wcmVmaXhlcy4KCsKg CgpQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhpcyBjbGFyaWZpZXMgeW91ciBjb21tZW50LCBpbiB0 aGlzIGNhc2UgSSB3aWxsIHN1Z2dlc3QgbmV3IHRleHQgZm9yIFNlY3Rpb24gNS4KCsKgCgpBbGJl cnQKCsKgCgrCoAoKwqAKCk9uIFRodSwgRmViIDEyLCAyMDE1IGF0IDEyOjA3IEFNLCBCbGFjaywg RGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+IHdyb3RlOgoKRGlubyAtIHRoYW5rcyBmb3IgdGhl IHJlc3BvbnNlLgoKT24gdGhlIG1ham9yIGlzc3VlcywgaXQgbG9va3MgbGlrZSBib3RoIFtBXSBh bmQgW0JdIGludm9sdmUgb25seSB0aGUgdGV4dAppbiB0aGlzIGRyYWZ0IGFuZCBub3RoaW5nIGJl eW9uZCwgd2hpY2ggaXMgZ29vZCBuZXdzLsKgIEkgaGF2ZSBhIHNpbXBsZSB0ZXh0CnN1Z2dlc3Rp b24gZm9yIFtBXSwgYnV0IGl0IGxvb2tzIGxpa2UgW0JdIGlzIGdvaW5nIHRvIHJlcXVpcmUgc29t ZSBjYXJlZnVsCmVkaXRpbmcsIGFzIG9uZSBvZiB0aGUgcHJpbWFyeSBjYXVzZXMgaXMgdGhhdCB0 aGUgZHJhZnQgaXMgc2xvcHB5IGluIHVzaW5nCnRoZSBzYW1lIHN5bWJvbCAiRyIgdG8gcmVwcmVz ZW50IGJvdGggRUlEIGFuZCBSTE9DIG11bHRpY2FzdCBncm91cHMuCgpPbiB0aGUgbWlub3IgaXNz dWVzLCBJIGhhdmUgdGV4dCBzdWdnZXN0aW9ucyBmb3IgdGhyZWUgb2YgdGhlIGZvdXIsIGFuZApJ J2QgbGlrZSB0byB0ZW1wb3JhcmlseSBkZWZlciBmdXJ0aGVyIGRpc2N1c3Npb24gdGhlIElQdjYg VURQIHplcm8KY2hlY2tzdW0gInRhcnBpdCIgaW4gZmF2b3Igb2YgcmVzb2x2aW5nIGV2ZXJ5dGhp bmcgZWxzZSBmaXJzdC4KCk9uIHRoZSBuaXRzL2VkaXRvcmlhbCBjb21tZW50cywgYWxsIHRoZSBz dWdnZXN0aW9ucyBpbiB5b3VyIGVtYWlsIGFyZSBmaW5lCndpdGggbWUuwqAgRldJVywgSSByZWdh cmQgdGhhdCBwb3J0aW9uIG9mIGEgcmV2aWV3IGFzIGFsbW9zdCBlbnRpcmVseQpzdWJqZWN0IHRv IHRoZSBkcmFmdCBhdXRob3JzJyBkaXNjcmV0aW9uIChhbmQgZWRpdG9yaWFsIHRhc3RlKS4KCj4g Pj4gW0FdIEVJRCBtb2JpbGl0eSB2cy4gRUlEIHByZWZpeGVzCj4KPiAuLi4gZnJvbSB0aGUgc3Rh cnQgb2YgdGhlIExJU1AgZGVzaWduIChjaXJjYSAyMDA3KSwgYW4gcHJlZml4IGlzIHdoYXQgbW92 ZXMuCj4gQW5kIGEgc3BlY2lmaWMgRUlEIGlzIHNpbXBseSBhIC8zMiBvciAvMTI4IHByZWZpeC4g SGVyZSBpcyBhIHByYWN0aWNhbAo+IGV4YW1wbGU6CgpBIHN0YXRlbWVudCB0aGF0IHRoZSBtb2Jp bGl0eSB1c2UgY2FzZXMgbmVlZCB0byBlbXBsb3kgLzMyIGFuZCAvMTI4IHByZWZpeGVzLAphbmQg bm90IGFueXRoaW5nIGNvYXJzZXIgc2hvdWxkIHN1ZmZpY2UuwqAgVGhhdCBzaG91bGQgYmUgYWRk ZWQgdG8gU2VjdGlvbiA1LgoKPiA+PiBbQl0gTElTUCBNdWx0aWNhc3QgdnMuIEVJRC9STE9DIHNl cGFyYXRlCj4gPj4KPiA+PiAtIDYuIE11bHRpY2FzdAo+ID4+Cj4gPj4gVGhpcyBpcyBpbnRlcmVz dGluZywgbXVsdGljYXN0IGFkZHJlc3NlcyAoRykgbG9vayBsaWtlIHRoZXkncmUgYW4gZXhjZXB0 aW9uCj4KPiBUaGV5IGFyZSByZWFsbHkgbm90LgoKTXkgY29uY2VybiBpcyB0aGF0IGFzIEkgcmVh ZCB0aGUgZHJhZnQsIGl0IGxlYXZlcyBtZSB3aXRoIHRoZSBzdHJvbmcgaW1wcmVzc2lvbgp0aGF0 IHRoZSBzYW1lIG11bHRpY2FzdCBhZGRyZXNzZXMgKEcpIGFyZSBiZWluZyB1c2VkIGluIGJvdGgg dGhlIG92ZXJsYXkKKGFzIEVJRHMpIGFuZCB0aGUgdW5kZXJsYXkgKGFzIFJMT0NzKS7CoCBGcm9t IHlvdXIgcmVzcG9uc2UsIEkgY29uY2x1ZGUgdGhhdCB0aGlzCmlzIG5vdCB0aGUgY2FzZSAoYW5k IEkgaGF2ZSBubyBhcmd1bWVudCB3aXRoIHRoYXQpLsKgIFJhdGhlciwgU2VjdGlvbiA2IG5lZWRz IHRvCmJsdW50bHkgc3RhdGUgdGhhdCBtdWx0aWNhc3QgYWRkcmVzc2VzIGFyZSBtYXBwZWQgYmV0 d2VlbiBFSUQgYW5kIFJMT0Mgc3BhY2UgYXQKYm90aCBJVFJzIGFuZCBFVFJzLCBzbyB0aGF0IHRo ZSBmb2xsb3dpbmcgaW5mZXJlbmNlIGlzIG9idmlvdXMgZnJvbSB0aGUgdGV4dAooaXQncyBjdXJy ZW50bHkgbm90IG9idmlvdXMpOgoKPiBTbyBpdCBtYWtlcyBwZXJmZWN0IHNlbnNlIHRvIHJlZ2lz dGVyIG11bHRpY2FzdCBhZGRyZXNzZXMgdG8gdGhlIG1hcHBpbmcKPiBzeXN0ZW0gYXMgRUlEcyBh bmQgdGhleSBjYW4gbWFwIHRvIFJMT0NzIG9mIHNpdGVzIHRoYXQgaGF2ZSBqb2luZWQgdGhlIGdy b3VwLgoKQXMgcGFydCBvZiB0aGlzLCBJIHN0cm9uZ2x5IHJlY29tbWVuZCBtb3ZpbmcgYXdheSBm cm9tIHVzZSBvZiAiRyIgdG8gcmVmZXIgdG8KbXVsdGljYXN0IGdyb3VwcyBpbiBib3RoIHRoZSBv dmVybGF5IGFuZCB1bmRlcmxheS7CoCBDYXJlZnVsIHVzZSBvZiBHLUVJRAphbmQgRy1STE9DIHdv dWxkIHNpZ25pZmljYW50bHkgaW1wcm92ZSBjbGFyaXR5LgoKLS0tCklmIHRoZSBhYm92ZSBhcmUg ZG9uZSBmb3IgW0FdIGFuZCBbQl0gaW4gU2VjdGlvbnMgNSBhbmQgNiwgdGhlbiB0aGUgdGV4dCBm b3IgdGhlCnVzZSBjYXNlcyBpbiBTZWN0aW9uIDcgc2hvdWxkIG5vdCBuZWVkIGZ1cnRoZXIgYXR0 ZW50aW9uLgotLS0KCj4gPj4gLS0gTWlub3IgSXNzdWVzIC0tCj4gPj4KPiA+PiBUaGVyZSBzZWVt cyB0byBiZSBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIHRoYXQgdGhlIGVuZCBob3N0IGFuZCBpdHMK PiA+PiBJVFIgKHhUUikgYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBvciBBdXRvbm9tb3VzIFN5c3Rl bS7CoCBGb3IgaW5jcmVtZW50YWwKPgo+IFRoaXMgaXMgdHJ1ZSB3aGVuIHlvdSBjYWxsIHRoZSBk b21haW4gYSAiTElTUCBzaXRlIi4gQnV0IGlmIHRoZSBzaXRlIGlzCj4gdW5jaGFuZ2VkIGFuZCBv bmUgdXNlcyBQSVRScywgbWF5YmUgZXZlbiBjbG9zZSB0byB0aGUgc2l0ZSwgbGlrZSBpbiBhIFBF Cj4gcm91dGVyLCB0aGVuIHRoZSBQSVRSIGlzIGRlZmluaXRlbHkgaW4gYW5vdGhlciBBUy4KCkxv b2tpbmcgYXQgdGhlIHRleHQsIGl0IHNlZW1zIHRoYXQgIkxJU1Agc2l0ZSIgYW5kICJkb21haW4i IGFyZSB0aGUgc2FtZQpjb25jZXB0IGZvciB0aGlzIGRyYWZ0LsKgIFRoYXQgd291bGQgYmUgdXNl ZnVsIHRvIHN0YXRlLCBJTUhPIGJ1dCBJJ2xsIGxlYXZlCnRoZSBkZWNpc2lvbiBvbiB3aGV0aGVy IHRvIGRvIHNvIHRvIHlvdSBhbmQgdGhlIGRyYWZ0IGF1dGhvcnMuCgpPbiByZXJlYWRpbmcsIG15 IGNvbmNlcm5zIHNlZW0gdG8gYmUgdHJpZ2dlcmVkIG1vc3RseSBieSB0aGlzIHNlbnRlbmNlIGlu ClNlY3Rpb24gMy4yOgoKwqAgwqBUaGUgZWRnZSBjb25zaXN0cyBvZiBMSVNQIHNpdGVzIChlLmcu LCBhbgrCoCDCoEF1dG9ub21vdXMgU3lzdGVtKSB0aGF0IHVzZSBFSUQgYWRkcmVzc2VzLgoKSSB0 aGluayBhIHNtYWxsIGNoYW5nZSB0byB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0aGF0IHBhcmFncmFw aCB3b3VsZCByZXNvbHZlCm15IGNvbmNlcm4gd2l0aG91dCBkaXN0cmFjdGluZyBmcm9tIHRoZSBu YXJyYXRpdmU6CgpPTEQKwqAgwqBFSURzIGRvIG5vdArCoCDCoGNvbnRhaW4gaW50ZXItZG9tYWlu IHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNlIG9mIHRoaXMsCsKgIMKgRUlEcyBh cmUgdXN1YWxseSByb3V0YWJsZSBhdCB0aGUgZWRnZSAod2l0aGluIExJU1Agc2l0ZXMpIG9yIGlu IHRoZQrCoCDCoG5vbi1MSVNQIEludGVybmV0LgpORVcKwqAgwqBFSURzIGRvIG5vdArCoCDCoGNv bnRhaW4gaW50ZXItZG9tYWluIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNlIG9m IHRoaXMsCsKgIMKgRUlEcyBhcmUgdXN1YWxseSByb3V0YWJsZSBhdCB0aGUgZWRnZSAod2l0aGlu IExJU1Agc2l0ZXMpIG9yIGluIHRoZQrCoCDCoG5vbi1MSVNQIEludGVybmV0OyBzZWUgU2VjdGlv biAzLjUgZm9yIGRpc2N1c3Npb24gb2YgTElTUCBzaXRlCsKgIMKgaW50ZXJuZXR3b3JraW5nIHdp dGggbm9uLUxJU1Agc2l0ZXMgYW5kIGRvbWFpbnMgaW4gdGhlIEludGVybmV0LgoKPiA+PiBEZXNw aXRlIG11bHRpcGxlwqAgbWVudGlvbnMgb2YgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgSSBkaWQg bm90Cj4gPj4gc2VlIGEgZGlzY3Vzc2lvbiBvZiBob3cgdGhhdCBtaWdodCBiZSBhY2NvbXBsaXNo ZWQuCj4KPiBUaGVyZSBhcmUgUHhUUnMgYW5kIE5BVHMuIEFuZCByZWZlcmVuY2VzIHRvIHRoZSBM SVNQIGludGVyd29ya2luZyBSRkMuCgpPaywgY2FuIHdlIGp1c3Qgc2F5IHNvIGluIFNlY3Rpb24g My41P8KgIEFkZGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlCnRvIHRoZSBlbmQgb2YgdGhlIHNl Y3Rpb24gd291bGQgc3VmZmljZToKCsKgIMKgUElUUnMsIFBFVFJzIGFuZCBMSVNQLU5BVCBzdXBw b3J0IGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgTElTUArCoCDCoGJ5IHByb3ZpZGluZyBzaWdu aWZpY2FudCBmbGV4aWJpbGl0eSBpbiBsb2NhdGlvbiBvZiB0aGUgYm91bmRhcmllcwrCoCDCoGJl dHdlZW4gdGhlIExJU1AgYW5kIG5vbi1MSVNQIHBvcnRpb25zIG9mIHRoZSBuZXR3b3JrLCBhbmQg bWFraW5nCsKgIMKgaXQgcmVhc29uYWJsZSB0byBjaGFuZ2UgdGhvc2UgYm91bmRhcmllcyBvdmVy IHRpbWUuCgo+ID4+IC0gMy4zLjEuwqAgTElTUCBFbmNhcHN1bGF0aW9uCj4gPj4KPiA+PsKgIMKg IHRoZSBzb3VyY2UgcG9ydCBpcyBzZWxlY3RlZCBieQo+ID4+wqAgwqAgdGhlIElUUiBhbmQgaWdu b3JlZCBvbiByZWNlcHRpb24uCj4gPj4KPiA+PiBQbGVhc2UgbWVudGlvbiBtdWx0aXBhdGhpbmcg KGUuZy4sIEVDTVAgYW5kIExBRykgYXMgcG9zc2libGUgaW5mbHVlbmNlcwo+ID4+IG9uIGhvdyBz b3VyY2UgcG9ydHMgYXJlIHNlbGVjdGVkLCBhcyB0aGlzIGltcG9zZXMgc29tZSBsaW1pdHMgb24g d2hhdCBhbgo+ID4+IElUUiBjYW4gcmVhc29uYWJseSBkby4KPgo+IEVDTVAvTEFHIGRvbid0IGlu Zmx1ZW5jZSB3aGljaCBzb3VyY2UgcG9ydCBpcyBzZWxlY3RlZC4gSXQgaXMgYSA1LXR1cGxlIGhh c2gKPiBvZiB0aGUgaW5uZXIgaGVhZGVyIHRoYXQgc2VsZWN0cyBhIHNvdXJjZSBwb3J0IHRoYXQg aW5mbHVlbmNlcyBob3cgYW4gdW5kZXJsYXkKPiByb3V0ZXIgd291bGQgbG9hZC1zcGxpdCB0cmFm ZmljLgoKUGxlYXNlIHN0YXRlIHRoYXQgYSA1LXR1cGxlIGhhc2ggaXMgdXNlZC7CoCBFQ01QL0xB RyBpcyBhbW9uZyB0aGUgaW1wb3J0YW50CnJlYXNvbnMgd2h5LCBidXQgdGhhdCBkb2Vzbid0IG5l ZWQgdG8gYmUgc3RhdGVkIGlmIHlvdSBwcmVmZXIgbm90IHRvLsKgIEFuCmV4YW1wbGUgb2Ygc29t ZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgZXhjbHVkZWQgaXMgdGhhdCB1c2luZyBhIHJhbmRvbQpu dW1iZXIgZ2VuZXJhdG9yIHRvIHNldCB0aGUgc291cmNlIHBvcnQgd291bGQgYmUgd3JvbmcgLSBJ IGNvdWxkIHN1Z2dlc3QKY2l0aW5nIGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cCBmb3IgcmVsYXRl ZCBkaXNjdXNzaW9uIChhbmQgbG90cyBtb3JlCmRldGFpbHMpLCBidXQgSSBkb24ndCB0aGluayB0 aGF0J3MgbmVjZXNzYXJ5LgoKLS0gSVB2NiB6ZXJvIFVEUCBjaGVja3N1bQoKPiBNeSBoZWFkIHNw aW5zIGV2ZXJ5IHRpbWUgSSBoZWFyIGFib3V0IHRoaXMgc3ViamVjdC4gVGhpcyBzdWJqZWN0IGhh cyBiZWVuCj4gdGFsa2VkIGFib3V0IGZyb20gMTAwcyBvZiBwZW9wbGUgZm9yIGEgZGVjYWRlLiBX ZSBoYXZlIENSQyBvbiBsaW5rcywgd2UgaGF2ZQo+IGFwcHMgdGhhdCB1c2UgVENQIGFuZCBVRFAg Y2hlY2tzdW1zLiBOdWYgc2FpZC4KClVuZGVyc3Rvb2QgLSB0aGVyZSdzIG1vcmUgdGhhbiBvbmUg c2V0IG9mIHNjYXJzIG9uIHRoaXMgb25lIDotKC7CoCBMZXQncyBjb21lIGJhY2sKdG8gdGhpcyB0 b3BpYyBhZnRlciB3ZSd2ZSByZXNvbHZlZCBldmVyeXRoaW5nIGVsc2UsIGFuZCBwbGVhc2Uga2Vl cCBpbiBtaW5kCnRoYXQgSSB0YWdnZWQgdGhpcyBhcyBhIG1pbm9yIGlzc3VlLCBub3QgYSBtYWpv ciBvbmUgKGUuZy4sIHRoZSBhYm92ZSBjaGFuZ2VzCmZvciBbQV0gYW5kIFtCXSBhcmUgZmFyIG1v cmUgaW1wb3J0YW50LCBJTUhPKS4KClRoYW5rcywKLS1EYXZpZAoKPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQo+IEZyb206IERpbm8gRmFyaW5hY2NpIFttYWlsdG86ZmFyaW5hY2NpQGdtYWls LmNvbV0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE1IDI6MTkgUE0KPiBUbzog Sm9lbCBNLiBIYWxwZXJuCj4gQ2M6IEJsYWNrLCBEYXZpZDsgQWxiZXJ0IENhYmVsbG9zOyBEYW1p ZW4gU2F1Y2V6OyBvcHMtZGlyQGlldGYub3JnOwo+IGlldGZAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5v cmcKPiBTdWJqZWN0OiBSZTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlz cC1pbnRyb2R1Y3Rpb24tMTEKPgoKPiA+IEkgd2lsbCBsZWF2ZSBtb3N0IG9mIHRoZXNlIGZvciB0 aGUgYXV0aG9ycyB0byBjb21tZW50IG9uLgo+Cj4gU2VlIG15IGNvbW1lbnRzIGlubGluZS4gVGhh bmtzIERhdmlkIGZvciB5b3VyIGRldGFpbGVkIHJldmlldyBhbmQgY29tbWVudGFyeS4KPgo+ID4g V2l0aCByZWdhcmQgdG8geW91ciBxdWVzdGlvbiBhYm91dCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50 LCB0aGF0IGlzIHRoZQo+IGRvbWFpbiBvZiB0aGUgTElTUCBEZXBsb3ltZW50IGRvY3VtZW50LCBh bmQgd2FzIGRlbGliZXJhdGVseSBvbmx5IGxpZ2h0bHkKPiBjb3ZlcmVkIGhlcmUuwqAgSSBhbSBu b3Qgc3VyZSB3aGF0IHdlIGNhbiBkbyB0byBhZGRyZXNzIHlvdXIgY29tbWVudCB3aXRob3V0Cj4g ZHVwbGljYXRpbmcgdGhlIGVudGlyZXR5IG9mIHRoYXQgZG9jdW1lbnQuCj4KPiBUaGF0IGlzIHRo ZSByaXNrIHdlIG1heSBoYXZlIHdpdGggbWFueSBvZiB5b3VyIGNvbW1lbnRzLiBXZSBoYXZlIGEg bG90IG9mCj4gZGV0YWlsIGluIHRoZSBhbHJlYWR5IDkgcHVibGlzaGVkIFJGQ3PCoCBhbmQgdGhp cyBkb2N1bWVudCByZWFsbHkgaXMgdG8gdGFrZQo+IGFsbCB0aGF0IGRldGFpbCBhbmQgc3VtbWFy aXplIGFzIGFuIGVhc2lseSB1bmRlcnN0YW5kYWJsZSBkZXNjcmlwdGlvbiBvZiBhCj4gY29oZXNp dmUgZGVzaWduLgo+Cj4gPiBXaXRoIHJlZ2FyZCB0byBVRFAgWmVybywgdGhpcyB3YXMgYXBwcm92 ZWQgYnkgdGhlIElFU0cgYW5kIHB1Ymxpc2hlZCBhcyBhbgo+IFJGQy7CoCBJdCBpcyBwYXJ0IG9m IHRoZSB3YXkgdGhlIHByb3RvY29sIGlzIGRlZmluZWQuwqAgSWYgdGhlcmUgYXJlIHNwZWNpZmlj Cj4gY2hhbmdlcyB5b3Ugd291bGQgbGlrZSB0byBzZWUgaW4gdGhlIGV4cGxhbmF0b3J5IHRleHQs IEkgYW0gc3VyZQo+Cj4gRGVmaW5pdGVseSBhZ3JlZWQuIEluIGZhY3Qgd2UgaW5zdGlnYXRlZCBV RFAgemVyby4gQW5kIEkgY29udGludWFsbHkgdGFsayB0bwo+IGhhcmR3YXJlIGVuZ2luZWVycyBh bmQgdGhleSBhbGwgYmVsaWV2ZSB3ZSBtYWRlIHRoZSByaWdodCBkZWNpc2lvbi4gU28gaGF0cwo+ IG9mZiB0byB0aGUgSUVURiBmb3IgYmVpbmcgcHJhY3RpY2FsLgo+Cj4gPiB3ZSBjb3VsZCBpbmNs dWRlIHRoZW0uwqAgSWYgeW91IGFyZSBsb29raW5nIGZvciBhIGNoYW5nZSBpbiB0aGUgYmVoYXZp b3IsCj4gdGhpcyBkb2N1bWVudCBjYW4gbm90IG1ha2UgY2hhbmdlcyB0byB0aGUgTElTUCBiZWhh dmlvci4KPgo+IFllcywgYW4gaW1wb3J0YW50IHBvaW50Lgo+Cj4gPj4gSSBmb3VuZCBhIGNvdXBs ZSBvZiBtYWpvciBpc3N1ZXMgdGhhdCBJIGhvcGUgYXJpc2UgZnJvbSB0aGUKPiA+PiBzdW1tYXJp emF0aW9uIG9mIExJU1AgaW4gdGhpcyBkcmFmdCwgYXMgb3Bwb3NlZCB0byBiZWluZyBwcm9ibGVt cyBpbgo+ID4+IHRoZSBhY3R1YWwgTElTUCBwcm90b2NvbHMuwqAgSSBhbHNvIGZvdW5kIGEgZmV3 IG1pbm9yIGlzc3VlcywgdGhlIG1vc3QKPiA+PiBpbXBvcnRhbnQgb2Ygd2hpY2ggaXMgdGhlIG5l ZWQgZm9yIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMKPiA+PiBkaXNjdXNzaW9u IG9uIG1pc2RlbGl2ZXJ5LCB3aXRoIHBhcnRpY3VsYXIgYXR0ZW50aW9uIHRvIFZQTnMuCj4KPiBU aGFua3MgYSB0b24uCj4KPiA+PiAtLSBNYWpvciBpc3N1ZXMgLS0KPiA+Pgo+ID4+IFtBXSBFSUQg bW9iaWxpdHkgdnMuIEVJRCBwcmVmaXhlcwo+ID4+Cj4gPj4gLSA1LiBNb2JpbGl0eQo+ID4+Cj4g Pj4gSSB1bmRlcnN0YW5kIGhvdyB0aGlzIHdvcmtzIHdoZW4gbWFwcGluZyBpcyBwZXItRUlELCBi dXQgaG93IGRvZXMgdGhpcyB3b3JrCj4gPj4gd2hlbiB0aGUgRUlEIG9mIHRoZSBzeXN0ZW0gdGhh dCBtb3ZlcyBpcyBwYXJ0IG9mIGFuIEVJRCBwcmVmaXgsIGFzCj4gZGlzY3Vzc2VkCj4gPj4gaW4g U2VjdGlvbiAzLjQuMT/CoCBFdmVuIGlmIHRoZSBhbnN3ZXIgaXMgYSBsb25nIHZlcnNpb24gb2Yg IkRvbid0IGRvIHRoYXQhIgo+ID4+IGl0IHNob3VsZCBiZSBleHBsYWluZWQuCj4KPiBObywgZnJv bSB0aGUgc3RhcnQgb2YgdGhlIExJU1AgZGVzaWduIChjaXJjYSAyMDA3KSwgYW4gcHJlZml4IGlz IHdoYXQgbW92ZXMuCj4gQW5kIGEgc3BlY2lmaWMgRUlEIGlzIHNpbXBseSBhIC8zMiBvciAvMTI4 IHByZWZpeC4gSGVyZSBpcyBhIHByYWN0aWNhbAo+IGV4YW1wbGU6Cj4KPiBZb3UgaGF2ZSBhIGNs dXN0ZXIgb2Ygc2VydmVycyB0aGF0IGNvbW11bmljYXRlIHRvZ2V0aGVyIGZvciBhIHBhcnRpY3Vs YXIKPiBhcHBsaWNhdGlvbi4gVGhleSBhcHBsaWNhdGlvbiBjbHVzdGVyIGlzIHJ1bm5pbmcgaW4g YSBzZXQgb2YgVk1zLiBUaG9zZSBWTXMKPiBhcmUgYXNzaWduZWQgRUlEcyBmcm9tIGEgY29tbW9u IHBvd2VyLW9mLTIgRUlELXByZWZpeC4gVGhvc2UgVk1zIGFyZSBjdXJyZW50bHkKPiBydW5uaW5n IGluIGEgYnJpY2stYW5kLW1vcnRhciBkYXRhIGNlbnRlci4gTm93IHRoZXJlIGlzIGEgZGVzaXJl IHRvIG1vdmUgdGhlCj4gVk0gY2x1c3RlciB0byBhIGNsb3VkIHByb3ZpZGVyLiBXaGF0IGlzIG1v dmVkIGlzIHRoZSBFSUQtcHJlZml4IG9mIHRoZQo+IGNsdXN0ZXIuIFRoZSBtYXBwaW5nIHN5c3Rl bSBpcyB0b2xkIHRoYXQgdGhlIEVJRC1wcmVmaXggaXMgY2hhbmdpbmcgaXRzIFJMT0MtCj4gc2V0 IGZyb20gdGhlIGJyaWNrLWFuZC1tb3J0YXIgeFRScyB0byB0aGUgY2xvdWQgcHJvdmlkZXJzIHhU UnMuCj4KPiA+Pgo+ID4+IC0gNy40LsKgIExJU1AgZm9yIFZpcnR1YWwgTWFjaGluZSBNb2JpbGl0 eSBpbiBEYXRhIENlbnRlcnMKPiA+Pgo+ID4+IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhpcyB3 b3JrcyB3aGVuIEVJRCBwcmVmaXhlcyBhcmUgdXNlZCwgYXMgZWFjaCBWTQo+ID4+IGhhcyBpdHMg b3duIEVJRCBvciBFSURzLCBoZW5jZSB0aGUgZW50aXJlIHByZWZpeCByYW5nZSBkb2VzIG5vdCBt b3ZlIHdoZW4KPiA+PiB0aGUgVk0gbW92ZXMuCj4gPj4KPiA+PiBGb3IgT1BTLURpciwgdGhpcyBF SUQgcHJlZml4IGlzc3VlIFtBXSBmYWxscyB1bmRlciBBLjEuMSBpbiBBcHBlbmRpeCBBCj4gPj4g b2YgUkZDIDU3MDY6wqAgSGFzIGRlcGxveW1lbnQgYmVlbiBkaXNjdXNzZWQ/IGFuZCBzcGVjaWZp Y2FsbHkgdW5kZXI6Cj4gPj4KPiA+PsKgIMKgIMKgIMKgICrCoCBJcyB0aGUgcHJvcG9zZWQgc3Bl Y2lmaWNhdGlvbiBkZXBsb3lhYmxlP8KgIElmIG5vdCwgaG93IGNvdWxkCj4gPj7CoCDCoCDCoCDC oCDCoCDCoGl0IGJlIGltcHJvdmVkPwo+ID4+Cj4gPj4gYXMgRUlEIHByZWZpeGVzIGFwcGVhciB0 byBiZSB1bmRlcGxveWFibGUgZm9yIE1vYmlsaXR5IGFuZCBWTSBNb2JpbGl0eQo+IHVzYWdlLgo+ Cj4gU2VlIGFib3ZlIGV4YW1wbGUuCj4KPiA+PiBbQl0gTElTUCBNdWx0aWNhc3QgdnMuIEVJRC9S TE9DIHNlcGFyYXRlCj4gPj4KPiA+PiAtIDYuIE11bHRpY2FzdAo+ID4+Cj4gPj4gVGhpcyBpcyBp bnRlcmVzdGluZywgbXVsdGljYXN0IGFkZHJlc3NlcyAoRykgbG9vayBsaWtlIHRoZXkncmUgYW4g ZXhjZXB0aW9uCj4KPiBUaGV5IGFyZSByZWFsbHkgbm90LiBTaW5jZSBtdWx0aWNhc3QgYWRkcmVz c2VzICppZGVudGlmeSogYSBncm91cCBvZgo+IHJlY2VpdmVycywgaXQgaXMgdmVyeSBtdWNoIGFu IEVJRCBhbmQgYWhlcmVzIHRvIHRoZSBkZWZpbml0aW9uIG9mIGFuIEVJRC4KPiBNdWx0aWNhc3Qg YWRkcmVzc2VzIG5ldmVyIGhhZCB0b3BvbG9naWNhbCBzaWduZmljYW5jZSBidXQgdGhlIHN0YXRl Cj4gcmVwcmVzZW50aW5nIGEgZGlzdHJpYnV0aW9uIHRyZWUgZG9lcyB0ZWxsIHlvdSB3ZXJlIHRo ZSBtZW1iZXJzIGFyZSAoYnV0IHRoZQo+IGlkZW50aXR5IG9mIHRoZSBtZW1iZXJzIGFyZSBub3Qg a25vdyBpbiBtdWx0aWNhc3QpLgo+Cj4gU28gaXQgbWFrZXMgcGVyZmVjdCBzZW5zZSB0byByZWdp c3RlciBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIHRoZSBtYXBwaW5nCj4gc3lzdGVtIGFzIEVJRHMg YW5kIHRoZXkgY2FuIG1hcCB0byBSTE9DcyBvZiBzaXRlcyB0aGF0IGhhdmUgam9pbmVkIHRoZSBn cm91cC4KPiBTZWUgZHJhZnQtZmFyaW5hY2NpLXNpZ25hbC1mcmVlLW11bHRpY2FzdCBhcyBqdXN0 IG9uZSBleGFtcGxlLiBSRkM2ODMxIGFuZAo+IGRyYWZ0LWZhcmluYWNjaS1saXNwLW1yLXNpZ25h bGluZyBhcmUgb3RoZXIgZXhhbXBsZXMuCj4KPiA+PiB0byB0aGUgRUlEL1JMT0Mgc2VwYXJhdGlv biBhcyB0aGUgc2FtZSBkZXN0aW5hdGlvbiBJUCBtdWx0aWNhc3QgYWRkcmVzcwo+ID4+IGlzIHVz ZWQgZm9yIGJvdGggcHVycG9zZXMuwqAgVGhpcyBjb3VsZCB1c2Ugc29tZSBtb3JlIGRpc2N1c3Np b24sIGFzIGl0J3MKPiA+PiB1bmV4cGVjdGVkIGJhc2VkIG9uIHRoZSBjb250ZW50cyBvZiB0aGUg ZHJhZnQgdXAgdG8gdGhpcyBwb2ludC4KPgo+IEkgYmVsaWV2ZSB0aGUgbGV2ZWwgb2YgZGV0YWls IHdlIGhhdmUgaW4gdGhlIGludHJvZHVjdGlvbiBkb2N1bWVudCBpcyBhdCB0aGUKPiByaWdodCBs ZXZlbCBvciB3ZSdsbCBlcnIgb24gaGF2aW5nIHdheSB0b28gbWFueSBkZXRhaWxzIGNyb3AgaW4u Cj4KPiA+PiAtIDcuMi7CoCBMSVNQIGZvciBJUHY2IENvLWV4aXN0ZW5jZQo+ID4+Cj4gPj7CoCDC oCBMSVNQIGVuY2Fwc3VsYXRpb25zIGFsbG93cyB0byB0cmFuc3BvcnQgcGFja2V0cyB1c2luZyBF SURzIGZyb20gYQo+ID4+wqAgwqAgZ2l2ZW4gYWRkcmVzcyBmYW1pbHkgKGUuZy4sIElQdjYpIHdp dGggcGFja2V0cyBmcm9tIG90aGVyIGFkZHJlc3MKPiA+PsKgIMKgIGZhbWlsaWVzIChlLmcuLCBJ UHY0KS4KPiA+Pgo+ID4+IEhvdyBkb2VzIHRoYXQgd29yayBmb3IgbXVsdGljYXN0IHRyYWZmaWMs IHdoZXJlIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzCj4gPj4gKEcpIGhhcyB0byBiZSB0aGUgc2Ft ZSBpbiBib3RoIHRoZSBpbm5lciBhbmQgb3V0ZXIgaGVhZGVycz/CoCBBcmUgRVRScwo+ID4+IGFu ZCBJVFJzIGV4cGVjdGVkIHRvIG1hcCBJUHY2IG11bHRpY2FzdCBhZGRyZXNzZXMgdG8gSVB2NCBh bmQgdi52Lj8KPgo+IFRoZSBtYXBwaW5nIHN5c3RlbSBjYW4gbWFwIGFuIChTLUVJRC1pcHY2LCBn cm91cC1pcHY2KSAyLXR1cGxlIHRvIGEgUkxPQyBzZXQKPiB0aGF0IGxvb2tlZCBsaWtlIHRoaXMg KGlwdjQtbXVsdGljYXN0LCBpcHY0LXVuaWNhc3QpIG1lYW4gdGhlIElUUiB0aGF0Cj4gcmVjZWl2 ZXMgdGhlIHBhY2tldCBmcm9tIFMtRUlELWlwdjYgd291bGQgcmVwbGljYXRlIHRoZSBwYWNrZXQg YW5kIG11bHRpY2FzdAo+IGVuY2Fwc3VsYXRlIHRvIGlwdjQtbXVsdGljYXN0IGFuZCB1bmljYXN0 IGVuY2Fwc3VhbHRlIHRvIGlwdjQtdW5pY2FzdC4KPgo+ID4+IC0gNy4zLsKgIExJU1AgZm9yIFZp cnR1YWwgUHJpdmF0ZSBOZXR3b3Jrcwo+ID4+Cj4gPj4gVGhpcyBhbHNvIGhhcyBtdWx0aWNhc3Qg cHJvYmxlbXMsIGFzIHRoZXJlIGlzIG9ubHkgb25lIGluc3RhbmNlIG9mIGVhY2gKPiA+PiBtdWx0 aWNhc3QgYWRkcmVzcyAoRykgaW4gdGhlIHVuZGVybGF5IG5ldHdvcmsuwqAgSSB0aGluayBJIGNh biBmaWd1cmUgb3V0Cj4gaG93Cj4KPiBZb3UgY2FuIG1hcCBmcm9tIEVJRC1HIHRvIFJMT0MtRyBv bmUgdG8gb25lLiBCdXQgd2UgaGF2ZSBzZWVuIG92ZXIgdGhlIGxhc3QKPiBkZWNhZGUgaW4gYSBo YWxmIHRoYXQgd2l0aCBnZW5lcmFsIG11bHRpY2FzdCBkZXBsb3ltZW50IHRoYXQgbWFueS10by0x IGlzCj4gZGVzaXJhYmxlLiBIZW5jZSwgbm93IHRoYXQgd2UgaGF2ZSBhIHdheSB0byBtYXAgd2l0 aCBhIG5ldHdvcmstYmFzZWQgZGF0YWJhc2UsCj4gd2UgY2FuIG1hcCBtdWx0aXBsZSBFSUQtR3Mg dG8gYSBzaW5nbGUgKG9yIG11bHRpcGxlKSBSTE9DLUdzLgo+Cj4gPj4gdG8gbWFrZSBtdWx0aWNh c3Qgd29yayBmb3IgdGhpcyB1c2UgY2FzZSwgYnV0IGl0J3Mgbm90IGltbWVkaWF0ZWx5IG9idmlv dXMsCj4gPj4gYW5kIHRoZSByZXN1bHQgd2hlbiB0aGUgc2FtZSB1bmRlcmxheSBtdWx0aWNhc3Qg YWRkcmVzcyBpcyB1c2VkIGJ5IG1vcmUKPiA+PiB0aGFuIG9uZSBWUE4gY291bGQgd2VsbCBkZWxp dmVyIHNvbWUgdHJhZmZpYyB0byBFVFJzIHRoYXQgaGF2ZSB0byBkaXNjYXJkCj4KPiBUaGlzIGlz IGEgbmVjZXNzYXJ5IGV2aWwgd2hlbiB0aGUgdW5kZXJsYXkgaXMgc3RhdGUgY2hhbGxlbmdlZC4g QnV0IGl0IGlzIGEKPiBzdGF0ZS9iYW5kd2lkdGggdHJhZGVvZmYuIFdlIGhhdmUgZm91bmQgd2l0 aCBNVlBOIGRlcGxveW1lbnQgdGhhdCB0aGUgbmV0d29yawo+IGFkbWluIGNvbmZpZ3VyZXMgdGhl IHVuZGVybHkgb3Igc2ltcGx5IHVuaWNhc3RzLgo+Cj4gPj4gaXQgYmVjYXVzZSB0aGUgSW5zdGFu Y2UgSUQgaXMgd3JvbmcgKGFuZCB0aGF0IGV4Y2Vzc2l2ZSBkZWxpdmVyeSBpcyBhCj4gPj4gc2Vj dXJpdHkgY29uc2lkZXJhdGlvbiwgc2VlIG1pbm9yIGlzc3VlIG9uIFNlY3Rpb24gOCBiZWxvdyku wqAgSSB0aGluayBhbgo+ID4+IGV4cGxhbmF0aW9uIGlzIGluIG9yZGVyLgo+Cj4gVGhlcmUgYXJl IGp1c3QgdG9vIG1hbnkgY29tYmluYXRpb25zIHRvIG1ha2UgYSBoaWdoLWxldmVsIGRlc2NyaXB0 aW9uIHNpbXBsZQo+IHRvIHVuZGVyc3RhbmQuIFRoZSBjdXJyZW50IGludHJvZHVjdGlvbiB0ZXh0 IGRvZXMgYSBmaW5kIGpvYiBwcm92aWRpbmcKPiByZWZlcmVuY2VzIGZvciBzb21lb25lIHRvIGdv IG9mZiBhbmQgZ2V0IHRoZSBkZXRhaWxzLgo+Cj4gPj4gLS0gTWlub3IgSXNzdWVzIC0tCj4gPj4K PiA+PiBUaGVyZSBzZWVtcyB0byBiZSBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIHRoYXQgdGhlIGVu ZCBob3N0IGFuZCBpdHMKPiA+PiBJVFIgKHhUUikgYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBvciBB dXRvbm9tb3VzIFN5c3RlbS7CoCBGb3IgaW5jcmVtZW50YWwKPgo+IFRoaXMgaXMgdHJ1ZSB3aGVu IHlvdSBjYWxsIHRoZSBkb21haW4gYSAiTElTUCBzaXRlIi4gQnV0IGlmIHRoZSBzaXRlIGlzCj4g dW5jaGFuZ2VkIGFuZCBvbmUgdXNlcyBQSVRScywgbWF5YmUgZXZlbiBjbG9zZSB0byB0aGUgc2l0 ZSwgbGlrZSBpbiBhIFBFCj4gcm91dGVyLCB0aGVuIHRoZSBQSVRSIGlzIGRlZmluaXRlbHkgaW4g YW5vdGhlciBBUy4gQnV0IG5vdGUgSSBzYWlkIFBJVFIgYW5kCj4gbm90IElUUi4gVGhlIHJlYXNv biBiZWluZyBpcyBiZWNhdXNlIGFuIElUUiBpcyBjb25maWd1cmVkIHdpdGggZGF0YWJhc2UtCj4g bWFwcGluZyBwcmVmaXhlcyB0aGF0IGlzIHVzZXMgdG8gZW5jYXBzdWxhdGUgcGFja2V0cyBmcm9t IHN1Y2ggYWRkcmVzc2VzLgo+IFZlcnN1cyB0aGUgUElUUiBiZWluZyBhbiBJVFIgd2l0aCAqbm8g ZGF0YWJhc2UtbWFwcGluZ3MqIHByb3ZpZGluZyBhIG11Y2ggbW9yZQo+IGxhcmdlci9vciBtb3Jl IGFnZ3JlZ3RhYmxlIHNlcnZpY2UuCj4KPiA+PiBkZXBsb3ltZW50LCBJIGRvbid0IHRoaW5rIHRo YXQncyBhbHdheXMgdGhlIGNhc2UsIGJ1dCBJIHRoaW5rIHRoYXQgb25seQo+ID4+IGhhcyBlZGl0 b3JpYWwgaW1wYWN0IG9uIHRoaXMgZG9jdW1lbnQsIGFzIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRo ZQo+ID4+IGZ1bmRhbWVudGFsIExJU1AgbWVjaGFuaXNtcyBhcmUgYWZmZWN0ZWQuwqAgVGhlIGF1 dGhvcnMgc2hvdWxkIGxvb2sgZm9yCj4gPj4gdXNlIG9mICJkb21haW4iIGFuZCAiQXV0b25vbW91 cyBTeXN0ZW0iIGFuZCBlbnN1cmUgdGhhdCB0aGUgdGV4dCBpcwo+ID4+IGdlbmVyYWxpemVkIHRv IHRoZSBjYXNlIHdoZXJlIHRoZSBlbmQgaG9zdCBhbmQgSVRSIGFyZSBtb3JlIHdpZGVseQo+ID4+ IHNlcGFyYXRlZC4KPgo+IFdlIGFyZSBvdmVybG9hZGVkIHdpdGggdGVybXMgdGhhdCBjcmVhdGUg dG9wb2xvZ2ljYWwgb3Igb3JnYW5pemF0aW9uIGJvdW5kYXJ5Lgo+IEhlbmNlIHdoeSB3ZSBjcmVh dGVkICJMSVNQIHNpdGUiIHdoaWNoIGlzIGFsc28gdGhlIHNhbWUgYXMgYSAiTElTUCBWUE4gc2l0 ZSIuCj4gV2hlcmUgYSAiTElTUCBzaXRlIiB0aGF0IGhhcyBtdWx0aXBsZSB0ZW5uYW50cyB3b3Vs ZCBiZSBtdWx0aXBsZSAiTElTUCBWUE4KPiBzaXRlcyIuCj4KPiA+PiBEZXNwaXRlIG11bHRpcGxl wqAgbWVudGlvbnMgb2YgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgSSBkaWQgbm90Cj4gPj4gc2Vl IGEgZGlzY3Vzc2lvbiBvZiBob3cgdGhhdCBtaWdodCBiZSBhY2NvbXBsaXNoZWQuwqAgVGhlcmUg aXMgc29tZQo+Cj4gVGhlcmUgYXJlIFB4VFJzIGFuZCBOQVRzLiBBbmQgcmVmZXJlbmNlcyB0byB0 aGUgTElTUCBpbnRlcndvcmtpbmcgUkZDLgo+Cj4gPj4gdXNlZnVsIGNvbnRlbnQgaW4gU2VjdGlv biAzLjUsIGJ1dCB0aGF0J3MgYXQgYmVzdCBhbiBpbmNvbXBsZXRlCj4gPj4gZXhwbGFuYXRpb24u wqAgVGhpcyBpcyBhbiBPUFMtRGlyIHJldmlldyBjb25jZXJuIC0gaXQgZmFsbHMgdW5kZXIKPiA+ PiBBLjEuMyBpbiBBcHBlbmRpeCBBIG9mIFJGQyA1NzA2OiBIYXMgdGhlIG1pZ3JhdGlvbiBwYXRo IGJlZW4gZGlzY3Vzc2VkPwo+ID4+Cj4gPj4gLSAzLjMuMS7CoCBMSVNQIEVuY2Fwc3VsYXRpb24K PiA+Pgo+ID4+wqAgwqAgdGhlIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkIGJ5Cj4gPj7CoCDCoCB0 aGUgSVRSIGFuZCBpZ25vcmVkIG9uIHJlY2VwdGlvbi4KPiA+Pgo+ID4+IFBsZWFzZSBtZW50aW9u IG11bHRpcGF0aGluZyAoZS5nLiwgRUNNUCBhbmQgTEFHKSBhcyBwb3NzaWJsZSBpbmZsdWVuY2Vz Cj4gPj4gb24gaG93IHNvdXJjZSBwb3J0cyBhcmUgc2VsZWN0ZWQsIGFzIHRoaXMgaW1wb3NlcyBz b21lIGxpbWl0cyBvbiB3aGF0IGFuCj4gPj4gSVRSIGNhbiByZWFzb25hYmx5IGRvLgo+Cj4gRUNN UC9MQUcgZG9uJ3QgaW5mbHVlbmNlIHdoaWNoIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkLiBJdCBp cyBhIDUtdHVwbGUgaGFzaAo+IG9mIHRoZSBpbm5lciBoZWFkZXIgdGhhdCBzZWxlY3RzIGEgc291 cmNlIHBvcnQgdGhhdCBpbmZsdWVuY2VzIGhvdyBhbiB1bmRlcmxheQo+IHJvdXRlciB3b3VsZCBs b2FkLXNwbGl0IHRyYWZmaWMuCj4KPiA+PiBGb3IgT1BTLURpciwgdGhpcyBtdWx0aXBhdGhpbmcg Y29uY2VybiBmYWxscyB1bmRlciBBLjEuNCBpbiBBcHBlbmRpeCBBIG9mCj4gPj4gUkZDIDU3MDY6 IEhhdmUgdGhlIFJlcXVpcmVtZW50cyBvbiBvdGhlciBwcm90b2NvbHMgYW5kIGZ1bmN0aW9uYWwK PiA+PsKgIMKgIMKgIMKgIGNvbXBvbmVudHMgYmVlbiBkaXNjdXNzZWQ/Cj4gPj4KPiA+PsKgIMKg IFRoaXMgZGVjaXNpb24gd2FzIG1hZGUgYmVjYXVzZSB0aGUKPiA+PsKgIMKgIHR5cGljYWwgdHJh bnNwb3J0IHByb3RvY29scyB1c2VkIGJ5IHRoZSBhcHBsaWNhdGlvbnMgYWxyZWFkeSBpbmNsdWRl Cj4gPj7CoCDCoCBhIGNoZWNrc3VtLCBieSBuZWdsZWN0aW5nIHRoZSBhZGRpdGlvbmFsIFVEUCBl bmNhcHN1bGF0aW9uIGNoZWNrc3VtCj4gPj7CoCDCoCB4VFJzIGNhbiBmb3J3YXJkIHBhY2tldHMg bW9yZSBlZmZpY2llbnRseS4KPiA+Pgo+ID4+IEdyb2FuIcKgIEkgaGF2ZSBhbiBleHF1aXNpdGUg c2V0IG9mIHNjYXJzIG9uIFVEUCB6ZXJvIGNoZWNrc3VtcyBmb3IgSVB2Ngo+ID4+IGZyb20gd29y a2luZyBvbiB0aGUgTVBMUyBpbiBVRFAgZHJhZnQsIHNvIEkgbWF5IGJlIG92ZXJseSBzZW5zaXRp dmUgdG8KPiA+PiB0aGlzIGNvbmNlcm4uwqAgVGhlIGRvd25zaWRlIG9mIHRoaXMgZWZmaWNpZW5j eSBpcyB0aGF0IHRoZXJlIGlzIG5vCj4gPj4gY2hlY2tzdW0gY292ZXJhZ2Ugb2YgdGhlIElQdjYg aGVhZGVyIHdoZW4gemVybyBVRFAgY2hlY2tzdW1zIGFyZSB1c2VkLgo+ID4+IFRoYXQgc2hvdWxk IGF0IGxlYXN0IGJlIG1lbnRpb25lZCBoZXJlLCB3aXRoIGEgc3VtbWFyeSBvZiB3aHkgdGhhdCdz IG9rCj4gPj4gLSB0aGUgZGV0YWlsZWQganVzdGlmaWNhdGlvbiBmb3Igd2h5IHRoYXQncyBvayBj YW4gYmUgbGVmdCB0byBvdGhlcgo+ID4+IGRvY3VtZW50cy4KPgo+IE15IGhlYWQgc3BpbnMgZXZl cnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBzdWJqZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW4K PiB0YWxrZWQgYWJvdXQgZnJvbSAxMDBzIG9mIHBlb3BsZSBmb3IgYSBkZWNhZGUuIFdlIGhhdmUg Q1JDIG9uIGxpbmtzLCB3ZSBoYXZlCj4gYXBwcyB0aGF0IHVzZSBUQ1AgYW5kIFVEUCBjaGVja3N1 bXMuIE51ZiBzYWlkLgo+Cj4gPj4KPiA+PiAtLSBOaXRzL0VkaXRvcmlhbCBDb21tZW50cyAtLQo+ ID4+Cj4gPj4gLSBUb3Agb2YgcC40Ogo+ID4+Cj4gPj7CoCDCoCBUaGUgaW5pdGlhbCBtb3RpdmF0 aW9uIGluIHRoZSBMSVNQIGVmZm9ydCBpcyB0byBiZSBmaW5kIGluIHRoZQo+ID4+Cj4gPj4gImZp bmQiIC0+ICJmb3VuZCIKPiA+Pgo+ID4+IC0gU2VjdGlvbiAzLjEsIGZpcnN0IGJ1bGxldCBpdGVt Cj4KPiBXZSB3aWxsIGNlcnRhaW5seSBmaXhlIHRoZXNlLiBUaGFua3MuCj4KPiA+Pgo+ID4+wqAg wqAgwqAgwqBEZXZpY2VzIGFyZSBhc3NpZ25lZCB3aXRoIHJlbGF0aXZlbHkgb3BhcXVlIGlkZW50 aXR5Cj4gPj7CoCDCoCDCoCDCoG1lYW5pbmdmdWwgYWRkcmVzc2VzIHRoYXQgYXJlIGluZGVwZW5k ZW50IG9mIHRoZWlyIHRvcG9sb2dpY2FsCj4gPj7CoCDCoCDCoCDCoGxvY2F0aW9uLgo+ID4+Cj4g Pj4gSSBkb24ndCB1bmRlcnN0YW5kICJyZWxhdGl2ZWx5IG9wYXF1ZSBpZGVudGl0eSBtZWFuaW5n ZnVsIiBhbmQKPiA+PiBzdWdnZXN0IHJld3JpdGluZyB0aGUgc2VudGVuY2UuwqAgSW4gcGFydGlj dWxhciAtIG9wYXF1ZSB0byB3aGF0Pwo+ID4+IG1lYW5pbmdmdWwgdG8gd2hhdCBpbiB3aGF0IG1h bm5lcj8KPgo+IFdlbGwgYmVhY3VzZSBpdCBpcyBhcyBhY2N1cmF0ZSBhcyBpdCBjYW4gYmUuIElm IGF1dG9tb2JpbGVzIGFyZSBnb2luZyB0byBiZQo+IGFzc2lnbmVkIEVJRHMgZnJvbSBhIFZJTiBu dW1iZXIgYWxsb2NhdGlvbiBmcm9tIGEgbWFudWZhY3R1cmUsIHRoZSBhZGRyZXNzIGlzCj4gcmVs YXRpdmVseSBvcGFxdWUuIElmIGEgVk0gaW4gYSBkYXRhLWNlbnRlciBpcyBnb2luZyB0byBiZSBh c3NpZ25lZCBhbiBFSUQKPiBmcm9tIHRoZSBzZXQgb2YgcHJlZml4ZXMgYWxyZWFkeSBiZWluZyB1 c2VkIGFuZCBhbGxvY2F0ZWQgdG8gdGhhdCBkYXRhLWNlbnRlciwKPiB0aGVuIHRoZXJlIGlzIGEg Z29vZCBjaGFuY2UgdGhhdCBhZGRyZXNzIGlzIGluIGEgcG93ZXItb2YtMiBibG9jayB0aGF0IGlz Cj4gc3VtbWFyaXphYmxlIGluIHRoZSBJR1AuCj4KPiA+Pgo+ID4+IC0gU2VjdGlvbiAzLjIsIHNl Y29uZCBwYXJhZ3JhcGgKPiA+Pgo+ID4+IEp1ZGdpbmcgZnJvbSB0aGUgZmlndXJlLCB4VFJzIGFy ZSB0aGUgY29tbW9uIGNhc2UsIHdpdGggc2luZ2xlLQo+ID4+IGZ1bmN0aW9uIElUUnMgYW5kIEVU UnMgYmVpbmcgcmFyZS7CoCBJdCBtaWdodCBiZSBnb29kIHRvIHNheSB0aGF0Cj4gPj4gYW5kIGRp c2N1c3Mgd2hlbiBJVFJzIGFuZCBFVFJzIHRoYXQgYXJlIG5vdCB4VFJzIGFyZSBhcHByb3ByaWF0 ZQo+ID4+IHRvIHVzZS4KPgo+IFdoZW4geW91IHdhbnQgZWdyZXNzIHBhdGggc2VsZWN0aW9uIHRv IGhhcHBlbiBmdXJ0aGVyIG91dCBpbiB0aGUgdG9wbG9naWNhbAo+IGZyb20gdGhlIHNvdXJjZSBs b2NhdGlvbiwgdGhlbiB5b3UgcHV0IGFuIElUUi1vbmx5IHN5c3RlbSB0aGVyZS4gV2hlcmUgaW5n cmVzcwo+IHRvIHRoZSBzYW1lIHNvdXJjZSAoZGVzdGluYXRpb24gaW4gdGhpcyBkaXJlY3Rpb24p LCB0aGUgRVRSIGNhbiBiZSBjbG9zZXIgdG8KPiB0aGUgZGVzdGluYXRpb24uCj4KPiA+Pgo+ID4+ IC0gM3JkIHBhcmFncmFwaCBvbiBwLjc6Cj4gPj4KPiA+Pgo+ID4+wqAgwqAgRmluYWxseSwgdGhl IExJU1AgYXJjaGl0ZWN0dXJlIGVtcGhhc2l6ZXMgYSBjb3N0IGVmZmVjdGl2ZQo+ID4+wqAgwqAg aW5jcmVtZW50YWwgZGVwbG95bWVudC4KPiA+Pgo+ID4+IEknZCBkZWxldGUgImNvc3QgZWZmZWN0 aXZlIiBoZXJlIGFuZCBsb29rIGZvciBvdGhlciBvY2N1cnJlbmNlcwo+ID4+IG9mICJjb3N0IiBh cyBjYW5kaWRhdGVzIGZvciBkZWxldGlvbi7CoCBUaGlzIGlzIHN1cHBvc2VkIHRvIGJlCj4gPj4g YSB0ZWNobmljYWwgZG9jdW1lbnQsIHNvIGRpc2N1c3Npb24gb2YgY29zdHMgaXMgYSBiaXQgb2Zm LXRhcmdldC4KPgo+IEZhaXIgZW5vdWdoLgo+Cj4gPj4gLSBGaXJzdCBpdGVtIGFmdGVyIEZpZ3Vy ZSAyOgo+ID4+Cj4gPj7CoCDCoCAxLsKgIEhvc3RBIHJldHJpZXZlcyB0aGUgRUlEX0Igb2YgSG9z dEIsIHR5cGljYWxseSBxdWVyeWluZyB0aGUgRE5TCj4gPj7CoCDCoCDCoCDCoCBhbmQgb2J0YWlu aW5nIGFuZCBBIG9yIEFBQUEgcmVjb3JkLgo+ID4+Cj4gPj4gImFuZCBBIiAtPiAiYW4gQSLCoCAo c3BlbGxpbmcgY2hlY2tlcnMgZG9uJ3QgY2F0Y2ggZXZlcnl0aGluZykuCj4KPiBBbHJlYWR5IG5v dGVkIGFuZCB3aWxsIGJlIGZpeGVkLgo+Cj4gPj4KPiA+PiAtIDMuMy4xLsKgIExJU1AgRW5jYXBz dWxhdGlvbgo+ID4+Cj4gPj7CoCDCoCBPbiB0aGUgb3RoZXIgaGFuZCwgUmVjdXJzaXZlCj4gPj7C oCDCoCB0dW5uZWxzIGFyZSBuZXN0ZWQgdHVubmVscyBhbmQgYXJlIGltcGxlbWVudGVkIGJ5IHVz aW5nIG11bHRpcGxlIExJU1AKPiA+PsKgIMKgIGVuY2Fwc3VsYXRpb25zIG9uIGEgcGFja2V0Lgo+ ID4+Cj4gPj4gVGhlIGFib3ZlIHNlbnRlbmNlIHNlZW1zIG91dCBvZiBwbGFjZSBpbiB0aGUgbWlk ZGxlIG9mIGEgcGFyYWdyYXBoIGFib3V0Cj4gPj4gUmUtZW5jYXBzdWxhdGluZyB0dW5uZWxzIGFu ZCByb3V0ZXJzIC0gSSBzdWdnZXN0IG1vdmluZyBpdCBkb3duIGludG8gaXRzCj4gPj4gb3duIHBh cmFncmFwaCBhbmQgcGVyaGFwcyBhZGRpbmcgYSBzZW50ZW5jZSBhYm91dCB3aGVyZS9ob3cgUmVj dXJzaXZlCj4gPj4gdHVubmVscyBtYXkgYmUgdXNlZnVsLgo+Cj4gR29vZCBzdWdnZXN0aW9uIGFu ZCBtYWtlcyBzZW5zZS4KPgo+ID4+IC0gMy4zLjIuwqAgTElTUCBGb3J3YXJkaW5nIFN0YXRlCj4g Pj4KPiA+PsKgIMKgIEluIHRoZSBMSVNQIGFyY2hpdGVjdHVyZSwgSVRScyBrZWVwIGp1c3QgZW5v dWdoIGluZm9ybWF0aW9uIHRvIHJvdXRlCj4gPj7CoCDCoCB0cmFmZmljIGZsb3dpbmcgdGhyb3Vn aCBpdC4KPiA+Pgo+ID4+ICJpdC4iIC0+ICJ0aGVtLiIKPiA+Pgo+ID4+wqAgwqAgTWVhbmluZyB0 aGF0LCBJVFJzIHJldHJpZXZlIGZyb20gdGhlCj4gPj7CoCDCoCBMSVNQIE1hcHBpbmcgU3lzdGVt IG1hcHBpbmdzIGJldHdlZW4gRUlEIHByZWZpeGVzIGFuZCBSTE9DcyB0aGF0IGFyZQo+ID4+wqAg wqAgdXNlZCB0byBlbmNhcHN1bGF0ZSBwYWNrZXRzLgo+ID4+Cj4gPj4gVGhpcyBpcyB0aGUgZmly c3QgdXNlIG9mIHRoZSBub3Rpb24gb2YgRUlEIHByZWZpeGVzLsKgIFRoYXQgY29uY2VwdCBzaG91 bGQKPiA+PiBiZSBleHBsYWluZWQgYmVmb3JlIGl0IGlzIHVzZWQsIGFsdGhvdWdoIGEgZm9yd2Fy ZCByZWZlcmVuY2UgdG8gc2VjdGlvbgo+ID4+IDMuNC4xIG1heSBzdWZmaWNlLsKgIEl0IG1pZ2h0 IGJlIGJldHRlciB0byByZXdyaXRlIHRoaXMgcGFyYWdyYXBoIGluIHRlcm1zCj4gPj4gb2YgRUlE cyBhbmQgbGVhdmUgdGhlIG5vdGlvbiBvZiBFSUQgcHJlZml4ZXMgdG8gc2VjdGlvbiAzLjQuMS4K Pgo+IEhtbSwgSSdsbCBsZXQgQWxiZXJ0IGFuZCBEYW1pZW4gZGVjaWRlIGlmIHdlIHNob3VsZCBz dGF0ZSAiRUlELXByZWZpeGVzIgo+IGV2ZXJ5d2hlcmUgaW5zdGVhZCBvZiBqdXN0ICJFSUQiLgo+ Cj4gPj4KPiA+PiAtIDQuNC7CoCBNVFUgSGFuZGxpbmcKPiA+Pgo+ID4+wqAgwqAgQWRkaXRpb25h bGx5LCBMSVNQIGFsc28gcmVjb21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmlsaXR5IG9mIGxvY2F0 b3JzCj4gPj7CoCDCoCBieSB1c2luZyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgdW5kZXJs YXksIGluIHBhcnRpY3VsYXI6Cj4gPj4KPiA+PiBJdCdkIGJlIHVzZWZ1bCB0byBhZGQgYSBzZW50 ZW5jZSBvciB0d28gYWJvdXQgaG93IExJU1AgYW5kIHRoZSB0ZWNobmlxdWVzCj4gPj4gaW4gdGhp cyBzZWN0aW9uIGludGVyYWN0IHdpdGggaG9zdCB1c2Ugb2YgUE1UVUQgYW5kIFBMUE1UVUQuCj4K PiBUaGlzIGlzIGEgbG90IG9mIGRldGFpbCBiZWNhdXNlIGluIFJGQzY4MzAgd2UgaGF2ZSAzIHBv c2l0aW9ucyBvciBvcHRpb25zIG9uCj4gdGhlIHN1YmplY3QuIEFuZCB3ZSBkaWQgcHJvdmlkZSBh IHJlZmVyZW5jZSB0byBSRkM2ODMwIGZvciB0aGlzIHRvcGljLgo+Cj4gPj4gLSBOZXh0IHRvIGxh c3QgcGFyYWdyYXBoIG9uIHAuMTc6Cj4gPj4KPiA+PsKgIMKgIEFkZGl0aW9uYWxseSwgTElTUCBh bHNvIHJlY29tbWVuZHMgaW5mZXJyaW5nIHJlYWNoYWJpbGl0eSBvZiBsb2NhdG9ycwo+ID4+wqAg wqAgYnkgdXNpbmcgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlIHVuZGVybGF5LCBpbiBwYXJ0 aWN1bGFyOgo+ID4+Cj4gPj4gVGhpcyBsb29rcyBsaWtlIGl0J3MgYSBwYXJhZ3JhcGggZWFybHkg YW5kIG5lZWRzIHRvIGJlIG1vdmVkIGRvd24gdG8KPiA+PiBhZnRlciB0aGUgcGFyYWdyYXBoIHRo YXQgZm9sbG93cyBpdC4KPgo+IEFncmVlLgo+Cj4gPj4gaWRuaXRzIDIuMTMuMDEgZGlkbid0IGZp bmQgYW55IG5pdHMuCj4gPj4KPiA+PiBUaGFua3MsCj4gPj4gLS1EYXZpZAo+Cj4gVGhhbmtzIGFn YWluIERhdmlkLgo+Cj4gRGlubwoKwqA= ----_com.android.email_127491863198918 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5UZW1lYmVyIHRoYXQgYW4gRUlEIHBy ZWZpeCByZXByZXNlbnRzIGEgc2l0ZS4gJm5ic3A7QSB0ZW5hbnQgbmV0d29yayBpbiBhIGRhdGEg Y2VudGVyIGlzIGEgdmlhYmxlIHNpdGUuICZuYnNwO1NvIHRoZSBwcmVmaXggYXMgcmVnaXN0ZXJl ZCBmb3IgdGhhdC4gJm5ic3A7TW9iaWx1dHkgb2YgVk1zIHdpdGggdGhlIHRlbmFudCBuZXR3b3Jr IGNhbiBiZSBoYW5kbGVkIGludGVybmFsbHkuPGRpdj48YnI+PC9kaXY+PGRpdj5ZcHUgY291bGQg aW5zdGVhZCBhZHZlcnRpc2UgZWFjaCBWTSBFSUQuICZuYnNwO1RnZSBmYWN0IHRoYXQgYm90aCBj YXNlZCB3b3JrIG1ha2VzIGRvaW5nIGFuIGludHJvZHVjdG9yeSBkZXNjcmlwdGlvbiBhIGJpdCB0 cmlja3kuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Zb3Vycyw8L2Rpdj48ZGl2PkpvZWw8L2Rp dj48ZGl2Pjxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4NyUiPlNlbnQgZnJvbSBteSBT YW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmYW1wO1Q8L3NwYW4+IDwvZGl2Pjxicj48YnI+PGJyPi0t LS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+U3ViamVjdDogUkU6IFtsaXNwXSBP UFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTExIDxicj5Gcm9t OiAiQmxhY2ssIERhdmlkIiAmbHQ7ZGF2aWQuYmxhY2tAZW1jLmNvbSZndDsgPGJyPlRvOiAiSm1o LmRpcmVjdCIgJmx0O2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tJmd0OywiYWNhYmVsbG9AYWMu dXBjLmVkdSIgJmx0O2FjYWJlbGxvQGFjLnVwYy5lZHUmZ3Q7IDxicj5DQzogImZhcmluYWNjaUBn bWFpbC5jb20iICZsdDtmYXJpbmFjY2lAZ21haWwuY29tJmd0Oywiam1oQGpvZWxoYWxwZXJuLmNv bSIgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7LCJkYW1pZW4uc2F1Y2V6QGlucmlhLmZyIiAm bHQ7ZGFtaWVuLnNhdWNlekBpbnJpYS5mciZndDssIm9wcy1kaXJAaWV0Zi5vcmciICZsdDtvcHMt ZGlyQGlldGYub3JnJmd0OywiaWV0ZkBpZXRmLm9yZyIgJmx0O2lldGZAaWV0Zi5vcmcmZ3Q7LCJs aXNwQGlldGYub3JnIiAmbHQ7bGlzcEBpZXRmLm9yZyZndDssIkJsYWNrLCBEYXZpZCIgJmx0O2Rh dmlkLmJsYWNrQGVtYy5jb20mZ3Q7IDxicj48YnI+PGJyPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7Cjwvc3Bh bj5JbiB0aGUgVk0gY2FzZSwgYW0gZW50aXJlIHNlcnZpY2UgbmV0d29yayBtYXkgYmUgbW92ZWQg dG8gdGhlIGRhdGEgY2VudGVyLCBhbmQgc28gdGhlIEVJRCBibG9jayBmb3IgdGhhdCBzZXQgY2Fu IGJlIG1vdmVkLiAmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Rm9yIGEgc2luZ2xlIFZNLCB0aGF0IHdvdWxkIGFwcGx5IGlmIHRoZSBWTSBpcyB1c2lu ZyBhbiBlbnRpcmUgRUlEIGJsb2NrIC0gbW9zdCBpbmRpdmlkdWFsIFZNcyBhcmVu4oCZdC9kb27i gJl0LiZuYnNwOyBJbmRpdmlkdWFsIC8zMiBhbmQgLzEyOCBhZGRyZXNzZXMgYXJlIGNvbW1vbiBm b3IgaW5kaXZpZHVhbAogVk1zLCBzbyB0aGF04oCZcyB3aGF04oCZcyBuZWVkZWQgaW4gZ2VuZXJh bCBmb3IgaW5kaXZpZHVhbCBWTSBtb3ZlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5J4oCZ ZCBleHBlY3QgdGhlIEVJRCBibG9jayBtb3ZlIGNhc2UgdG8gYXBwbHkgZm9yIG1vdmVtZW50IG9m IGEgZ3JvdXAgb2YgVk1zIHRoYXQgYXJlIHVzaW5nIHN1Y2ggYSBibG9jayAoZS5nLiwgYXMgYSBz dWJuZXQpLCBidXQgVk0gbGl2ZSBtaWdyYXRpb25zIGNhbm5vdCBiZSBzeW5jaHJvbml6ZWQKIGlu IGdlbmVyYWwgKGNvbGQgbWlncmF0aW9ucyBvZiBwb3dlcmVkLW9mZiBWTXMgY2FuIGJlLCBvYnZp b3VzbHkpLCBzbyBldmVuIGluIHRoaXMgY2FzZSB3aGVyZSB0aGUgZW50aXJlIEVJRCBibG9jayBt b3ZlcywgaWYgbGl2ZSBWTSBtaWdyYXRpb25zIGFyZSBpbnZvbHZlZCwgdGhlcmUgYXJlIGludGVy bWVkaWF0ZSBzdGFnZXMgd2hlcmUgdGhlIEVJRCBibG9jayBpcyBzcGxpdCBiZXR3ZWVuIExJU1Ag c2l0ZXMgLi4uIGFuZCBoZW5jZSAvMzIgYW5kCiAvMTI4IHByZWZpeGVzIGFyZSBzdGlsbCB3aGF0 4oCZcyB3YW50ZWQuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzLDxi cj4KLS1EYXZpZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ CjxkaXY+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEptaC5kaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbV0KPGJyPgo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSA3OjE5 IFBNPGJyPgo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZDsgYWNhYmVsbG9AYWMudXBjLmVkdTxicj4K PGI+Q2M6PC9iPiBmYXJpbmFjY2lAZ21haWwuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBkYW1p ZW4uc2F1Y2V6QGlucmlhLmZyOyBvcHMtZGlyQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBsaXNw QGlldGYub3JnPGJyPgo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtsaXNwXSBPUFMtRGlyIHJldmlldyBv ZiBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTExPGJyPgo8Yj5JbXBvcnRhbmNlOjwvYj4g TG93PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5sIHdl IG1heSB3YW50IHRvIHNlcGFyYXRlIFZNIG1vYmlsaXR5IGZyb20gbW9iaWxlIGRldmljZXMuICZu YnNwO09tIHRoZSBWTSBjYXNlLCBhbSBlbnRpcmUgc2V0dmljZSBuZXR3b3JrIG1heSBiZSBtb3Zl ZCB0byB0aGUgZGF0YSBjZW50ZXIsIGFuZCBzbyB0aGUgRUlEIGJsb2NrIGZvciB0aGF0IHNldCBj YW4gYmUgbW92ZWQuICZuYnNwO0luIHRoZSBjYXNlIG9mIGluZGl2aWR1YWxseSBtb2JpbGUgZGVi aWNlcyBvcgogc29tZSB2YXRpYXRpb25zIG9uIGRhdGEgY2VudGVyIG1vYmlsaXR5LCB0aGVyZSBp cyBhIG5lZWQgdG8gbXNrZSBzdXJlIHRoZSBmdWxsIEVJRCBpcyBhZHZlcnRpc2VkIGluIHRoZSBt YXBwaW5nIHN5c3RlbS48bzpwPjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z b3Vycyw8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpv ZWw8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4K PGJyPgo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+U2VudCBmcm9tIG15IFNhbXN1bmcg c21hcnRwaG9uZSBvbiBBVCZhbXA7VDwvc3Bhbj4gPG86cD4KPC9vOnA+PC9wPgo8L2Rpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+Cjxicj4K PGJyPgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPgpTdWJqZWN0OiBSRTog W2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTEg PGJyPgpGcm9tOiAiQmxhY2ssIERhdmlkIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJsYWNr QGVtYy5jb20iPmRhdmlkLmJsYWNrQGVtYy5jb208L2E+Jmd0Owo8YnI+ClRvOiAiPGEgaHJlZj0i bWFpbHRvOmFjYWJlbGxvQGFjLnVwYy5lZHUiPmFjYWJlbGxvQGFjLnVwYy5lZHU8L2E+IiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFjYWJlbGxvQGFjLnVwYy5lZHUiPmFjYWJlbGxvQGFjLnVwYy5lZHU8 L2E+Jmd0Owo8YnI+CkNDOiBEaW5vIEZhcmluYWNjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhcmlu YWNjaUBnbWFpbC5jb20iPmZhcmluYWNjaUBnbWFpbC5jb208L2E+Jmd0OywiSm9lbCBNLiBIYWxw ZXJuIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFs cGVybi5jb208L2E+Jmd0OyxEYW1pZW4gU2F1Y2V6ICZsdDs8YSBocmVmPSJtYWlsdG86ZGFtaWVu LnNhdWNlekBpbnJpYS5mciI+ZGFtaWVuLnNhdWNlekBpbnJpYS5mcjwvYT4mZ3Q7LCI8YSBocmVm PSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyI+b3BzLWRpckBpZXRmLm9yZzwvYT4iCiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+Jmd0Oywi PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+IiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+Jmd0OywiPGEgaHJl Zj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciPmxpc3BAaWV0Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmxpc3BAaWV0Zi5vcmciPmxpc3BAaWV0Zi5vcmc8L2E+Jmd0OywiQmxhY2ssCiBEYXZp ZCIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIj5kYXZpZC5ibGFja0Bl bWMuY29tPC9hPiZndDsgPGJyPgo8YnI+CjxvOnA+PC9vOnA+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBBbGJlcnQsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkFzIG5vdGVkIGJlbG93LCBvbiB0aGUgRUlEIHByZWZpeCBmb3IgbW9i aWxpdHkgaXNzdWUsIGEgc2ltcGxlIHN0YXRlbWVudCBpbiBTZWN0aW9uIDUgdG8gdGhlIGVmZmVj dCB0aGF0IOKAnGluCiB0aGUgc3BlY2lmaWMgY2FzZSBvZiBhIFZNL21vYmlsZSBub2RlIHRoZSBF SUQtcHJlZml4IHNob3VsZCBiZSAvMzIgb3IgLzEyOCAoSVB2NCBvciBJUHY2IHJlc3BlY3RpdmVs eSnigJ0gd2lsbCBzdWZmaWNlLiZuYnNwOyBEZXRhaWxzIG9uIHdoYXQgdG8gZG8gd2hlbiB0aGF0 IGFkdmljZSBpcyBpZ25vcmVkIGNhbiBiZSBsZWZ0IHRvIG90aGVyIGRvY3VtZW50cy48L3NwYW4+ PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzLDxicj4KLS1EYXZpZDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBBbGJlcnQgQ2FiZWxsb3MgWzxhIGhyZWY9Im1haWx0bzphbGJl cnQuY2FiZWxsb3NAZ21haWwuY29tIj5tYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdtYWlsLmNvbTwv YT5dCjxicj4KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMTUgNjozMyBQ TTxicj4KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+CjxiPkNjOjwvYj4gRGlubyBGYXJpbmFj Y2k7IEpvZWwgTS4gSGFscGVybjsgRGFtaWVuIFNhdWNlejsgPGEgaHJlZj0ibWFpbHRvOm9wcy1k aXJAaWV0Zi5vcmciPgpvcHMtZGlyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlldGZA aWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9y ZyI+Cmxpc3BAaWV0Zi5vcmc8L2E+PGJyPgo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtsaXNwXSBPUFMt RGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTExPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgRGF2aWQ8bzpwPjwv bzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzLCBJIGFtIHBhcnNpbmcgdGhlbSBhbmQgScK0bGwgc3VnZ2VzdCBuZXcgdGV4dCBhaW1p bmcgdG8gYWRkcmVzcyB0aGVtIEFTQVAuPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIGFsc28gbGlrZSB0byBiZXR0ZXIgdW5kZXJzdGFu ZCBbQV0gYmVmb3JlIGRvaW5nIHRoaXMuPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5XaXRoIExJU1AgYW4gRUlELXByZWlmeCBjYW4gaGF2ZSBhbiBh cmJpdHJhcnkgbGVuZ3RoIGFuZCBjYW4gbW92ZSAoaS5lLiwgY2hhbmdlIGl0cyBSTE9DIGJpbmRp bmdzKSwgaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgYSBWTS9tb2JpbGUgbm9kZSB0aGUgRUlELXBy ZWZpeCBzaG91bGQgYmUgLzMyIG9yIC8xMjgKIChJUHY0IG9yIElQdjYgcmVzcGVjdGl2ZWx5KS4g V2hhdCBkb2Vzbid0IHdvcmsgaXMgdGhlIG1vYmlsaXR5IG9mIGEgbm9kZSAoYXNzaWduZWQgd2l0 aCBhIC8zMiBvciAvMTI4KSAqd2l0aGluKiBhIGNvYXJzZXIgRUlELXByZWZpeCwgaW4gdGhpcyBj YXNlIHlvdSBuZWVkIHRvIHNwbGl0IHRoZSBwcmVmaXggaW50byBtb3JlIHNwZWNpZmljcyBhbmQg cmVnaXN0ZXIgdGhlbSBpbmRlcGVuZGVudGx5IGluIHRoZSBNYXBwaW5nIFN5c3RlbSwgZWZmZWN0 aXZlbHkKIGNyZWF0aW5nIG5ldyBFSUQtcHJlZml4ZXMuPG86cD48L286cD48L3A+CjwvZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4K PGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhpcyBj bGFyaWZpZXMgeW91ciBjb21tZW50LCBpbiB0aGlzIGNhc2UgSSB3aWxsIHN1Z2dlc3QgbmV3IHRl eHQgZm9yIFNlY3Rpb24gNS48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFsYmVydDxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIFRodSwgRmViIDEyLCAyMDE1IGF0IDEyOjA3IEFNLCBCbGFjaywgRGF2aWQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkRpbm8gLSB0aGFua3MgZm9yIHRoZSByZXNwb25zZS48YnI+Cjxicj4K T24gdGhlIG1ham9yIGlzc3VlcywgaXQgbG9va3MgbGlrZSBib3RoIFtBXSBhbmQgW0JdIGludm9s dmUgb25seSB0aGUgdGV4dDxicj4KaW4gdGhpcyBkcmFmdCBhbmQgbm90aGluZyBiZXlvbmQsIHdo aWNoIGlzIGdvb2QgbmV3cy4mbmJzcDsgSSBoYXZlIGEgc2ltcGxlIHRleHQ8YnI+CnN1Z2dlc3Rp b24gZm9yIFtBXSwgYnV0IGl0IGxvb2tzIGxpa2UgW0JdIGlzIGdvaW5nIHRvIHJlcXVpcmUgc29t ZSBjYXJlZnVsPGJyPgplZGl0aW5nLCBhcyBvbmUgb2YgdGhlIHByaW1hcnkgY2F1c2VzIGlzIHRo YXQgdGhlIGRyYWZ0IGlzIHNsb3BweSBpbiB1c2luZzxicj4KdGhlIHNhbWUgc3ltYm9sICJHIiB0 byByZXByZXNlbnQgYm90aCBFSUQgYW5kIFJMT0MgbXVsdGljYXN0IGdyb3Vwcy48YnI+Cjxicj4K T24gdGhlIG1pbm9yIGlzc3VlcywgSSBoYXZlIHRleHQgc3VnZ2VzdGlvbnMgZm9yIHRocmVlIG9m IHRoZSBmb3VyLCBhbmQ8YnI+CkknZCBsaWtlIHRvIHRlbXBvcmFyaWx5IGRlZmVyIGZ1cnRoZXIg ZGlzY3Vzc2lvbiB0aGUgSVB2NiBVRFAgemVybzxicj4KY2hlY2tzdW0gInRhcnBpdCIgaW4gZmF2 b3Igb2YgcmVzb2x2aW5nIGV2ZXJ5dGhpbmcgZWxzZSBmaXJzdC48YnI+Cjxicj4KT24gdGhlIG5p dHMvZWRpdG9yaWFsIGNvbW1lbnRzLCBhbGwgdGhlIHN1Z2dlc3Rpb25zIGluIHlvdXIgZW1haWwg YXJlIGZpbmU8YnI+CndpdGggbWUuJm5ic3A7IEZXSVcsIEkgcmVnYXJkIHRoYXQgcG9ydGlvbiBv ZiBhIHJldmlldyBhcyBhbG1vc3QgZW50aXJlbHk8YnI+CnN1YmplY3QgdG8gdGhlIGRyYWZ0IGF1 dGhvcnMnIGRpc2NyZXRpb24gKGFuZCBlZGl0b3JpYWwgdGFzdGUpLjxicj4KPGJyPgomZ3Q7ICZn dDsmZ3Q7IFtBXSBFSUQgbW9iaWxpdHkgdnMuIEVJRCBwcmVmaXhlczxicj4KJmd0Ozxicj4KJmd0 OyAuLi4gZnJvbSB0aGUgc3RhcnQgb2YgdGhlIExJU1AgZGVzaWduIChjaXJjYSAyMDA3KSwgYW4g cHJlZml4IGlzIHdoYXQgbW92ZXMuPGJyPgomZ3Q7IEFuZCBhIHNwZWNpZmljIEVJRCBpcyBzaW1w bHkgYSAvMzIgb3IgLzEyOCBwcmVmaXguIEhlcmUgaXMgYSBwcmFjdGljYWw8YnI+CiZndDsgZXhh bXBsZTo8YnI+Cjxicj4KQSBzdGF0ZW1lbnQgdGhhdCB0aGUgbW9iaWxpdHkgdXNlIGNhc2VzIG5l ZWQgdG8gZW1wbG95IC8zMiBhbmQgLzEyOCBwcmVmaXhlcyw8YnI+CmFuZCBub3QgYW55dGhpbmcg Y29hcnNlciBzaG91bGQgc3VmZmljZS4mbmJzcDsgVGhhdCBzaG91bGQgYmUgYWRkZWQgdG8gU2Vj dGlvbiA1Ljxicj4KPGJyPgomZ3Q7ICZndDsmZ3Q7IFtCXSBMSVNQIE11bHRpY2FzdCB2cy4gRUlE L1JMT0Mgc2VwYXJhdGU8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgLSA2LiBN dWx0aWNhc3Q8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgVGhpcyBpcyBpbnRl cmVzdGluZywgbXVsdGljYXN0IGFkZHJlc3NlcyAoRykgbG9vayBsaWtlIHRoZXkncmUgYW4gZXhj ZXB0aW9uPGJyPgomZ3Q7PGJyPgomZ3Q7IFRoZXkgYXJlIHJlYWxseSBub3QuPGJyPgo8YnI+Ck15 IGNvbmNlcm4gaXMgdGhhdCBhcyBJIHJlYWQgdGhlIGRyYWZ0LCBpdCBsZWF2ZXMgbWUgd2l0aCB0 aGUgc3Ryb25nIGltcHJlc3Npb248YnI+CnRoYXQgdGhlIHNhbWUgbXVsdGljYXN0IGFkZHJlc3Nl cyAoRykgYXJlIGJlaW5nIHVzZWQgaW4gYm90aCB0aGUgb3ZlcmxheTxicj4KKGFzIEVJRHMpIGFu ZCB0aGUgdW5kZXJsYXkgKGFzIFJMT0NzKS4mbmJzcDsgRnJvbSB5b3VyIHJlc3BvbnNlLCBJIGNv bmNsdWRlIHRoYXQgdGhpczxicj4KaXMgbm90IHRoZSBjYXNlIChhbmQgSSBoYXZlIG5vIGFyZ3Vt ZW50IHdpdGggdGhhdCkuJm5ic3A7IFJhdGhlciwgU2VjdGlvbiA2IG5lZWRzIHRvPGJyPgpibHVu dGx5IHN0YXRlIHRoYXQgbXVsdGljYXN0IGFkZHJlc3NlcyBhcmUgbWFwcGVkIGJldHdlZW4gRUlE IGFuZCBSTE9DIHNwYWNlIGF0PGJyPgpib3RoIElUUnMgYW5kIEVUUnMsIHNvIHRoYXQgdGhlIGZv bGxvd2luZyBpbmZlcmVuY2UgaXMgb2J2aW91cyBmcm9tIHRoZSB0ZXh0PGJyPgooaXQncyBjdXJy ZW50bHkgbm90IG9idmlvdXMpOjxicj4KPGJyPgomZ3Q7IFNvIGl0IG1ha2VzIHBlcmZlY3Qgc2Vu c2UgdG8gcmVnaXN0ZXIgbXVsdGljYXN0IGFkZHJlc3NlcyB0byB0aGUgbWFwcGluZzxicj4KJmd0 OyBzeXN0ZW0gYXMgRUlEcyBhbmQgdGhleSBjYW4gbWFwIHRvIFJMT0NzIG9mIHNpdGVzIHRoYXQg aGF2ZSBqb2luZWQgdGhlIGdyb3VwLjxicj4KPGJyPgpBcyBwYXJ0IG9mIHRoaXMsIEkgc3Ryb25n bHkgcmVjb21tZW5kIG1vdmluZyBhd2F5IGZyb20gdXNlIG9mICJHIiB0byByZWZlciB0bzxicj4K bXVsdGljYXN0IGdyb3VwcyBpbiBib3RoIHRoZSBvdmVybGF5IGFuZCB1bmRlcmxheS4mbmJzcDsg Q2FyZWZ1bCB1c2Ugb2YgRy1FSUQ8YnI+CmFuZCBHLVJMT0Mgd291bGQgc2lnbmlmaWNhbnRseSBp bXByb3ZlIGNsYXJpdHkuPGJyPgo8YnI+Ci0tLTxicj4KSWYgdGhlIGFib3ZlIGFyZSBkb25lIGZv ciBbQV0gYW5kIFtCXSBpbiBTZWN0aW9ucyA1IGFuZCA2LCB0aGVuIHRoZSB0ZXh0IGZvciB0aGU8 YnI+CnVzZSBjYXNlcyBpbiBTZWN0aW9uIDcgc2hvdWxkIG5vdCBuZWVkIGZ1cnRoZXIgYXR0ZW50 aW9uLjxicj4KLS0tPGJyPgo8YnI+CiZndDsgJmd0OyZndDsgLS0gTWlub3IgSXNzdWVzIC0tPGJy PgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IFRoZXJlIHNlZW1zIHRvIGJlIGFuIGlt cGxpY2l0IGFzc3VtcHRpb24gdGhhdCB0aGUgZW5kIGhvc3QgYW5kIGl0czxicj4KJmd0OyAmZ3Q7 Jmd0OyBJVFIgKHhUUikgYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBvciBBdXRvbm9tb3VzIFN5c3Rl bS4mbmJzcDsgRm9yIGluY3JlbWVudGFsPGJyPgomZ3Q7PGJyPgomZ3Q7IFRoaXMgaXMgdHJ1ZSB3 aGVuIHlvdSBjYWxsIHRoZSBkb21haW4gYSAiTElTUCBzaXRlIi4gQnV0IGlmIHRoZSBzaXRlIGlz PGJyPgomZ3Q7IHVuY2hhbmdlZCBhbmQgb25lIHVzZXMgUElUUnMsIG1heWJlIGV2ZW4gY2xvc2Ug dG8gdGhlIHNpdGUsIGxpa2UgaW4gYSBQRTxicj4KJmd0OyByb3V0ZXIsIHRoZW4gdGhlIFBJVFIg aXMgZGVmaW5pdGVseSBpbiBhbm90aGVyIEFTLjxicj4KPGJyPgpMb29raW5nIGF0IHRoZSB0ZXh0 LCBpdCBzZWVtcyB0aGF0ICJMSVNQIHNpdGUiIGFuZCAiZG9tYWluIiBhcmUgdGhlIHNhbWU8YnI+ CmNvbmNlcHQgZm9yIHRoaXMgZHJhZnQuJm5ic3A7IFRoYXQgd291bGQgYmUgdXNlZnVsIHRvIHN0 YXRlLCBJTUhPIGJ1dCBJJ2xsIGxlYXZlPGJyPgp0aGUgZGVjaXNpb24gb24gd2hldGhlciB0byBk byBzbyB0byB5b3UgYW5kIHRoZSBkcmFmdCBhdXRob3JzLjxicj4KPGJyPgpPbiByZXJlYWRpbmcs IG15IGNvbmNlcm5zIHNlZW0gdG8gYmUgdHJpZ2dlcmVkIG1vc3RseSBieSB0aGlzIHNlbnRlbmNl IGluPGJyPgpTZWN0aW9uIDMuMjo8YnI+Cjxicj4KJm5ic3A7ICZuYnNwO1RoZSBlZGdlIGNvbnNp c3RzIG9mIExJU1Agc2l0ZXMgKGUuZy4sIGFuPGJyPgombmJzcDsgJm5ic3A7QXV0b25vbW91cyBT eXN0ZW0pIHRoYXQgdXNlIEVJRCBhZGRyZXNzZXMuPGJyPgo8YnI+CkkgdGhpbmsgYSBzbWFsbCBj aGFuZ2UgdG8gdGhlIGxhc3Qgc2VudGVuY2UgaW4gdGhhdCBwYXJhZ3JhcGggd291bGQgcmVzb2x2 ZTxicj4KbXkgY29uY2VybiB3aXRob3V0IGRpc3RyYWN0aW5nIGZyb20gdGhlIG5hcnJhdGl2ZTo8 YnI+Cjxicj4KT0xEPGJyPgombmJzcDsgJm5ic3A7RUlEcyBkbyBub3Q8YnI+CiZuYnNwOyAmbmJz cDtjb250YWluIGludGVyLWRvbWFpbiB0b3BvbG9naWNhbCBpbmZvcm1hdGlvbiBhbmQgYmVjYXVz ZSBvZiB0aGlzLDxicj4KJm5ic3A7ICZuYnNwO0VJRHMgYXJlIHVzdWFsbHkgcm91dGFibGUgYXQg dGhlIGVkZ2UgKHdpdGhpbiBMSVNQIHNpdGVzKSBvciBpbiB0aGU8YnI+CiZuYnNwOyAmbmJzcDtu b24tTElTUCBJbnRlcm5ldC48YnI+Ck5FVzxicj4KJm5ic3A7ICZuYnNwO0VJRHMgZG8gbm90PGJy PgombmJzcDsgJm5ic3A7Y29udGFpbiBpbnRlci1kb21haW4gdG9wb2xvZ2ljYWwgaW5mb3JtYXRp b24gYW5kIGJlY2F1c2Ugb2YgdGhpcyw8YnI+CiZuYnNwOyAmbmJzcDtFSURzIGFyZSB1c3VhbGx5 IHJvdXRhYmxlIGF0IHRoZSBlZGdlICh3aXRoaW4gTElTUCBzaXRlcykgb3IgaW4gdGhlPGJyPgom bmJzcDsgJm5ic3A7bm9uLUxJU1AgSW50ZXJuZXQ7IHNlZSBTZWN0aW9uIDMuNSBmb3IgZGlzY3Vz c2lvbiBvZiBMSVNQIHNpdGU8YnI+CiZuYnNwOyAmbmJzcDtpbnRlcm5ldHdvcmtpbmcgd2l0aCBu b24tTElTUCBzaXRlcyBhbmQgZG9tYWlucyBpbiB0aGUgSW50ZXJuZXQuPGJyPgo8YnI+CiZndDsg Jmd0OyZndDsgRGVzcGl0ZSBtdWx0aXBsZSZuYnNwOyBtZW50aW9ucyBvZiBpbmNyZW1lbnRhbCBk ZXBsb3ltZW50LCBJIGRpZCBub3Q8YnI+CiZndDsgJmd0OyZndDsgc2VlIGEgZGlzY3Vzc2lvbiBv ZiBob3cgdGhhdCBtaWdodCBiZSBhY2NvbXBsaXNoZWQuPGJyPgomZ3Q7PGJyPgomZ3Q7IFRoZXJl IGFyZSBQeFRScyBhbmQgTkFUcy4gQW5kIHJlZmVyZW5jZXMgdG8gdGhlIExJU1AgaW50ZXJ3b3Jr aW5nIFJGQy48YnI+Cjxicj4KT2ssIGNhbiB3ZSBqdXN0IHNheSBzbyBpbiBTZWN0aW9uIDMuNT8m bmJzcDsgQWRkaW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U8YnI+CnRvIHRoZSBlbmQgb2YgdGhl IHNlY3Rpb24gd291bGQgc3VmZmljZTo8YnI+Cjxicj4KJm5ic3A7ICZuYnNwO1BJVFJzLCBQRVRS cyBhbmQgTElTUC1OQVQgc3VwcG9ydCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IG9mIExJU1A8YnI+ CiZuYnNwOyAmbmJzcDtieSBwcm92aWRpbmcgc2lnbmlmaWNhbnQgZmxleGliaWxpdHkgaW4gbG9j YXRpb24gb2YgdGhlIGJvdW5kYXJpZXM8YnI+CiZuYnNwOyAmbmJzcDtiZXR3ZWVuIHRoZSBMSVNQ IGFuZCBub24tTElTUCBwb3J0aW9ucyBvZiB0aGUgbmV0d29yaywgYW5kIG1ha2luZzxicj4KJm5i c3A7ICZuYnNwO2l0IHJlYXNvbmFibGUgdG8gY2hhbmdlIHRob3NlIGJvdW5kYXJpZXMgb3ZlciB0 aW1lLjxicj4KPGJyPgomZ3Q7ICZndDsmZ3Q7IC0gMy4zLjEuJm5ic3A7IExJU1AgRW5jYXBzdWxh dGlvbjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhl IHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkIGJ5PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyB0aGUgSVRSIGFuZCBpZ25vcmVkIG9uIHJlY2VwdGlvbi48YnI+CiZndDsgJmd0OyZndDs8YnI+ CiZndDsgJmd0OyZndDsgUGxlYXNlIG1lbnRpb24gbXVsdGlwYXRoaW5nIChlLmcuLCBFQ01QIGFu ZCBMQUcpIGFzIHBvc3NpYmxlIGluZmx1ZW5jZXM8YnI+CiZndDsgJmd0OyZndDsgb24gaG93IHNv dXJjZSBwb3J0cyBhcmUgc2VsZWN0ZWQsIGFzIHRoaXMgaW1wb3NlcyBzb21lIGxpbWl0cyBvbiB3 aGF0IGFuPGJyPgomZ3Q7ICZndDsmZ3Q7IElUUiBjYW4gcmVhc29uYWJseSBkby48YnI+CiZndDs8 YnI+CiZndDsgRUNNUC9MQUcgZG9uJ3QgaW5mbHVlbmNlIHdoaWNoIHNvdXJjZSBwb3J0IGlzIHNl bGVjdGVkLiBJdCBpcyBhIDUtdHVwbGUgaGFzaDxicj4KJmd0OyBvZiB0aGUgaW5uZXIgaGVhZGVy IHRoYXQgc2VsZWN0cyBhIHNvdXJjZSBwb3J0IHRoYXQgaW5mbHVlbmNlcyBob3cgYW4gdW5kZXJs YXk8YnI+CiZndDsgcm91dGVyIHdvdWxkIGxvYWQtc3BsaXQgdHJhZmZpYy48YnI+Cjxicj4KUGxl YXNlIHN0YXRlIHRoYXQgYSA1LXR1cGxlIGhhc2ggaXMgdXNlZC4mbmJzcDsgRUNNUC9MQUcgaXMg YW1vbmcgdGhlIGltcG9ydGFudDxicj4KcmVhc29ucyB3aHksIGJ1dCB0aGF0IGRvZXNuJ3QgbmVl ZCB0byBiZSBzdGF0ZWQgaWYgeW91IHByZWZlciBub3QgdG8uJm5ic3A7IEFuPGJyPgpleGFtcGxl IG9mIHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGV4Y2x1ZGVkIGlzIHRoYXQgdXNpbmcgYSBy YW5kb208YnI+Cm51bWJlciBnZW5lcmF0b3IgdG8gc2V0IHRoZSBzb3VyY2UgcG9ydCB3b3VsZCBi ZSB3cm9uZyAtIEkgY291bGQgc3VnZ2VzdDxicj4KY2l0aW5nIGRyYWZ0LWlldGYtZGFydC1kc2Nw LXJ0cCBmb3IgcmVsYXRlZCBkaXNjdXNzaW9uIChhbmQgbG90cyBtb3JlPGJyPgpkZXRhaWxzKSwg YnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIG5lY2Vzc2FyeS48YnI+Cjxicj4KLS0gSVB2NiB6ZXJv IFVEUCBjaGVja3N1bTxicj4KPGJyPgomZ3Q7IE15IGhlYWQgc3BpbnMgZXZlcnkgdGltZSBJIGhl YXIgYWJvdXQgdGhpcyBzdWJqZWN0LiBUaGlzIHN1YmplY3QgaGFzIGJlZW48YnI+CiZndDsgdGFs a2VkIGFib3V0IGZyb20gMTAwcyBvZiBwZW9wbGUgZm9yIGEgZGVjYWRlLiBXZSBoYXZlIENSQyBv biBsaW5rcywgd2UgaGF2ZTxicj4KJmd0OyBhcHBzIHRoYXQgdXNlIFRDUCBhbmQgVURQIGNoZWNr c3Vtcy4gTnVmIHNhaWQuPGJyPgo8YnI+ClVuZGVyc3Rvb2QgLSB0aGVyZSdzIG1vcmUgdGhhbiBv bmUgc2V0IG9mIHNjYXJzIG9uIHRoaXMgb25lIDotKC4mbmJzcDsgTGV0J3MgY29tZSBiYWNrPGJy Pgp0byB0aGlzIHRvcGljIGFmdGVyIHdlJ3ZlIHJlc29sdmVkIGV2ZXJ5dGhpbmcgZWxzZSwgYW5k IHBsZWFzZSBrZWVwIGluIG1pbmQ8YnI+CnRoYXQgSSB0YWdnZWQgdGhpcyBhcyBhIG1pbm9yIGlz c3VlLCBub3QgYSBtYWpvciBvbmUgKGUuZy4sIHRoZSBhYm92ZSBjaGFuZ2VzPGJyPgpmb3IgW0Fd IGFuZCBbQl0gYXJlIGZhciBtb3JlIGltcG9ydGFudCwgSU1ITykuPGJyPgo8YnI+ClRoYW5rcyw8 YnI+Ci0tRGF2aWQ8YnI+Cjxicj4KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPC9zcGFuPjxicj4KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IEZyb206IERpbm8g RmFyaW5hY2NpIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20iPmZh cmluYWNjaUBnbWFpbC5jb208L2E+XTwvc3Bhbj48YnI+CjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE1IDI6MTkgUE08L3NwYW4+PGJyPgo8c3Bh biBjbGFzcz0iaW0iPiZndDsgVG86IEpvZWwgTS4gSGFscGVybjwvc3Bhbj48YnI+CjxzcGFuIGNs YXNzPSJpbSI+Jmd0OyBDYzogQmxhY2ssIERhdmlkOyBBbGJlcnQgQ2FiZWxsb3M7IERhbWllbiBT YXVjZXo7IDxhIGhyZWY9Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIj4Kb3BzLWRpckBpZXRmLm9y ZzwvYT47PC9zcGFuPjxicj4KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpp ZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0 Zi5vcmciPgpsaXNwQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+CjxzcGFuIGNsYXNzPSJpbSI+Jmd0 OyBTdWJqZWN0OiBSZTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1p bnRyb2R1Y3Rpb24tMTE8L3NwYW4+PGJyPgo8c3BhbiBjbGFzcz0iaW0iPiZndDs8L3NwYW4+PG86 cD48L286cD48L3A+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyAmZ3Q7IEkgd2ls bCBsZWF2ZSBtb3N0IG9mIHRoZXNlIGZvciB0aGUgYXV0aG9ycyB0byBjb21tZW50IG9uLjxicj4K Jmd0Ozxicj4KJmd0OyBTZWUgbXkgY29tbWVudHMgaW5saW5lLiBUaGFua3MgRGF2aWQgZm9yIHlv dXIgZGV0YWlsZWQgcmV2aWV3IGFuZCBjb21tZW50YXJ5Ljxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7 IFdpdGggcmVnYXJkIHRvIHlvdXIgcXVlc3Rpb24gYWJvdXQgaW5jcmVtZW50YWwgZGVwbG95bWVu dCwgdGhhdCBpcyB0aGU8YnI+CiZndDsgZG9tYWluIG9mIHRoZSBMSVNQIERlcGxveW1lbnQgZG9j dW1lbnQsIGFuZCB3YXMgZGVsaWJlcmF0ZWx5IG9ubHkgbGlnaHRseTxicj4KJmd0OyBjb3ZlcmVk IGhlcmUuJm5ic3A7IEkgYW0gbm90IHN1cmUgd2hhdCB3ZSBjYW4gZG8gdG8gYWRkcmVzcyB5b3Vy IGNvbW1lbnQgd2l0aG91dDxicj4KJmd0OyBkdXBsaWNhdGluZyB0aGUgZW50aXJldHkgb2YgdGhh dCBkb2N1bWVudC48YnI+CiZndDs8YnI+CiZndDsgVGhhdCBpcyB0aGUgcmlzayB3ZSBtYXkgaGF2 ZSB3aXRoIG1hbnkgb2YgeW91ciBjb21tZW50cy4gV2UgaGF2ZSBhIGxvdCBvZjxicj4KJmd0OyBk ZXRhaWwgaW4gdGhlIGFscmVhZHkgOSBwdWJsaXNoZWQgUkZDcyZuYnNwOyBhbmQgdGhpcyBkb2N1 bWVudCByZWFsbHkgaXMgdG8gdGFrZTxicj4KJmd0OyBhbGwgdGhhdCBkZXRhaWwgYW5kIHN1bW1h cml6ZSBhcyBhbiBlYXNpbHkgdW5kZXJzdGFuZGFibGUgZGVzY3JpcHRpb24gb2YgYTxicj4KJmd0 OyBjb2hlc2l2ZSBkZXNpZ24uPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsgV2l0aCByZWdhcmQgdG8g VURQIFplcm8sIHRoaXMgd2FzIGFwcHJvdmVkIGJ5IHRoZSBJRVNHIGFuZCBwdWJsaXNoZWQgYXMg YW48YnI+CiZndDsgUkZDLiZuYnNwOyBJdCBpcyBwYXJ0IG9mIHRoZSB3YXkgdGhlIHByb3RvY29s IGlzIGRlZmluZWQuJm5ic3A7IElmIHRoZXJlIGFyZSBzcGVjaWZpYzxicj4KJmd0OyBjaGFuZ2Vz IHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBpbiB0aGUgZXhwbGFuYXRvcnkgdGV4dCwgSSBhbSBzdXJl PGJyPgomZ3Q7PGJyPgomZ3Q7IERlZmluaXRlbHkgYWdyZWVkLiBJbiBmYWN0IHdlIGluc3RpZ2F0 ZWQgVURQIHplcm8uIEFuZCBJIGNvbnRpbnVhbGx5IHRhbGsgdG88YnI+CiZndDsgaGFyZHdhcmUg ZW5naW5lZXJzIGFuZCB0aGV5IGFsbCBiZWxpZXZlIHdlIG1hZGUgdGhlIHJpZ2h0IGRlY2lzaW9u LiBTbyBoYXRzPGJyPgomZ3Q7IG9mZiB0byB0aGUgSUVURiBmb3IgYmVpbmcgcHJhY3RpY2FsLjxi cj4KJmd0Ozxicj4KJmd0OyAmZ3Q7IHdlIGNvdWxkIGluY2x1ZGUgdGhlbS4mbmJzcDsgSWYgeW91 IGFyZSBsb29raW5nIGZvciBhIGNoYW5nZSBpbiB0aGUgYmVoYXZpb3IsPGJyPgomZ3Q7IHRoaXMg ZG9jdW1lbnQgY2FuIG5vdCBtYWtlIGNoYW5nZXMgdG8gdGhlIExJU1AgYmVoYXZpb3IuPGJyPgom Z3Q7PGJyPgomZ3Q7IFllcywgYW4gaW1wb3J0YW50IHBvaW50Ljxicj4KJmd0Ozxicj4KJmd0OyAm Z3Q7Jmd0OyBJIGZvdW5kIGEgY291cGxlIG9mIG1ham9yIGlzc3VlcyB0aGF0IEkgaG9wZSBhcmlz ZSBmcm9tIHRoZTxicj4KJmd0OyAmZ3Q7Jmd0OyBzdW1tYXJpemF0aW9uIG9mIExJU1AgaW4gdGhp cyBkcmFmdCwgYXMgb3Bwb3NlZCB0byBiZWluZyBwcm9ibGVtcyBpbjxicj4KJmd0OyAmZ3Q7Jmd0 OyB0aGUgYWN0dWFsIExJU1AgcHJvdG9jb2xzLiZuYnNwOyBJIGFsc28gZm91bmQgYSBmZXcgbWlu b3IgaXNzdWVzLCB0aGUgbW9zdDxicj4KJmd0OyAmZ3Q7Jmd0OyBpbXBvcnRhbnQgb2Ygd2hpY2gg aXMgdGhlIG5lZWQgZm9yIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnM8YnI+CiZn dDsgJmd0OyZndDsgZGlzY3Vzc2lvbiBvbiBtaXNkZWxpdmVyeSwgd2l0aCBwYXJ0aWN1bGFyIGF0 dGVudGlvbiB0byBWUE5zLjxicj4KJmd0Ozxicj4KJmd0OyBUaGFua3MgYSB0b24uPGJyPgomZ3Q7 PGJyPgomZ3Q7ICZndDsmZ3Q7IC0tIE1ham9yIGlzc3VlcyAtLTxicj4KJmd0OyAmZ3Q7Jmd0Ozxi cj4KJmd0OyAmZ3Q7Jmd0OyBbQV0gRUlEIG1vYmlsaXR5IHZzLiBFSUQgcHJlZml4ZXM8YnI+CiZn dDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgLSA1LiBNb2JpbGl0eTxicj4KJmd0OyAmZ3Q7 Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQgaG93IHRoaXMgd29ya3Mgd2hlbiBt YXBwaW5nIGlzIHBlci1FSUQsIGJ1dCBob3cgZG9lcyB0aGlzIHdvcms8YnI+CiZndDsgJmd0OyZn dDsgd2hlbiB0aGUgRUlEIG9mIHRoZSBzeXN0ZW0gdGhhdCBtb3ZlcyBpcyBwYXJ0IG9mIGFuIEVJ RCBwcmVmaXgsIGFzPGJyPgomZ3Q7IGRpc2N1c3NlZDxicj4KJmd0OyAmZ3Q7Jmd0OyBpbiBTZWN0 aW9uIDMuNC4xPyZuYnNwOyBFdmVuIGlmIHRoZSBhbnN3ZXIgaXMgYSBsb25nIHZlcnNpb24gb2Yg IkRvbid0IGRvIHRoYXQhIjxicj4KJmd0OyAmZ3Q7Jmd0OyBpdCBzaG91bGQgYmUgZXhwbGFpbmVk Ljxicj4KJmd0Ozxicj4KJmd0OyBObywgZnJvbSB0aGUgc3RhcnQgb2YgdGhlIExJU1AgZGVzaWdu IChjaXJjYSAyMDA3KSwgYW4gcHJlZml4IGlzIHdoYXQgbW92ZXMuPGJyPgomZ3Q7IEFuZCBhIHNw ZWNpZmljIEVJRCBpcyBzaW1wbHkgYSAvMzIgb3IgLzEyOCBwcmVmaXguIEhlcmUgaXMgYSBwcmFj dGljYWw8YnI+CiZndDsgZXhhbXBsZTo8YnI+CiZndDs8YnI+CiZndDsgWW91IGhhdmUgYSBjbHVz dGVyIG9mIHNlcnZlcnMgdGhhdCBjb21tdW5pY2F0ZSB0b2dldGhlciBmb3IgYSBwYXJ0aWN1bGFy PGJyPgomZ3Q7IGFwcGxpY2F0aW9uLiBUaGV5IGFwcGxpY2F0aW9uIGNsdXN0ZXIgaXMgcnVubmlu ZyBpbiBhIHNldCBvZiBWTXMuIFRob3NlIFZNczxicj4KJmd0OyBhcmUgYXNzaWduZWQgRUlEcyBm cm9tIGEgY29tbW9uIHBvd2VyLW9mLTIgRUlELXByZWZpeC4gVGhvc2UgVk1zIGFyZSBjdXJyZW50 bHk8YnI+CiZndDsgcnVubmluZyBpbiBhIGJyaWNrLWFuZC1tb3J0YXIgZGF0YSBjZW50ZXIuIE5v dyB0aGVyZSBpcyBhIGRlc2lyZSB0byBtb3ZlIHRoZTxicj4KJmd0OyBWTSBjbHVzdGVyIHRvIGEg Y2xvdWQgcHJvdmlkZXIuIFdoYXQgaXMgbW92ZWQgaXMgdGhlIEVJRC1wcmVmaXggb2YgdGhlPGJy PgomZ3Q7IGNsdXN0ZXIuIFRoZSBtYXBwaW5nIHN5c3RlbSBpcyB0b2xkIHRoYXQgdGhlIEVJRC1w cmVmaXggaXMgY2hhbmdpbmcgaXRzIFJMT0MtPGJyPgomZ3Q7IHNldCBmcm9tIHRoZSBicmljay1h bmQtbW9ydGFyIHhUUnMgdG8gdGhlIGNsb3VkIHByb3ZpZGVycyB4VFJzLjxicj4KJmd0Ozxicj4K Jmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIDcuNC4mbmJzcDsgTElTUCBmb3IgVmly dHVhbCBNYWNoaW5lIE1vYmlsaXR5IGluIERhdGEgQ2VudGVyczxicj4KJmd0OyAmZ3Q7Jmd0Ozxi cj4KJmd0OyAmZ3Q7Jmd0OyBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoaXMgd29ya3Mgd2hlbiBF SUQgcHJlZml4ZXMgYXJlIHVzZWQsIGFzIGVhY2ggVk08YnI+CiZndDsgJmd0OyZndDsgaGFzIGl0 cyBvd24gRUlEIG9yIEVJRHMsIGhlbmNlIHRoZSBlbnRpcmUgcHJlZml4IHJhbmdlIGRvZXMgbm90 IG1vdmUgd2hlbjxicj4KJmd0OyAmZ3Q7Jmd0OyB0aGUgVk0gbW92ZXMuPGJyPgomZ3Q7ICZndDsm Z3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEZvciBPUFMtRGlyLCB0aGlzIEVJRCBwcmVmaXggaXNzdWUg W0FdIGZhbGxzIHVuZGVyIEEuMS4xIGluIEFwcGVuZGl4IEE8YnI+CiZndDsgJmd0OyZndDsgb2Yg UkZDIDU3MDY6Jm5ic3A7IEhhcyBkZXBsb3ltZW50IGJlZW4gZGlzY3Vzc2VkPyBhbmQgc3BlY2lm aWNhbGx5IHVuZGVyOjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAqJm5ic3A7IElzIHRoZSBwcm9wb3NlZCBzcGVjaWZpY2F0aW9u IGRlcGxveWFibGU/Jm5ic3A7IElmIG5vdCwgaG93IGNvdWxkPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpdCBiZSBpbXByb3ZlZD88YnI+ CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgYXMgRUlEIHByZWZpeGVzIGFwcGVhciB0 byBiZSB1bmRlcGxveWFibGUgZm9yIE1vYmlsaXR5IGFuZCBWTSBNb2JpbGl0eTxicj4KJmd0OyB1 c2FnZS48YnI+CiZndDs8YnI+CiZndDsgU2VlIGFib3ZlIGV4YW1wbGUuPGJyPgomZ3Q7PGJyPgom Z3Q7ICZndDsmZ3Q7IFtCXSBMSVNQIE11bHRpY2FzdCB2cy4gRUlEL1JMT0Mgc2VwYXJhdGU8YnI+ CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgLSA2LiBNdWx0aWNhc3Q8YnI+CiZndDsg Jmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgVGhpcyBpcyBpbnRlcmVzdGluZywgbXVsdGljYXN0 IGFkZHJlc3NlcyAoRykgbG9vayBsaWtlIHRoZXkncmUgYW4gZXhjZXB0aW9uPGJyPgomZ3Q7PGJy PgomZ3Q7IFRoZXkgYXJlIHJlYWxseSBub3QuIFNpbmNlIG11bHRpY2FzdCBhZGRyZXNzZXMgKmlk ZW50aWZ5KiBhIGdyb3VwIG9mPGJyPgomZ3Q7IHJlY2VpdmVycywgaXQgaXMgdmVyeSBtdWNoIGFu IEVJRCBhbmQgYWhlcmVzIHRvIHRoZSBkZWZpbml0aW9uIG9mIGFuIEVJRC48YnI+CiZndDsgTXVs dGljYXN0IGFkZHJlc3NlcyBuZXZlciBoYWQgdG9wb2xvZ2ljYWwgc2lnbmZpY2FuY2UgYnV0IHRo ZSBzdGF0ZTxicj4KJmd0OyByZXByZXNlbnRpbmcgYSBkaXN0cmlidXRpb24gdHJlZSBkb2VzIHRl bGwgeW91IHdlcmUgdGhlIG1lbWJlcnMgYXJlIChidXQgdGhlPGJyPgomZ3Q7IGlkZW50aXR5IG9m IHRoZSBtZW1iZXJzIGFyZSBub3Qga25vdyBpbiBtdWx0aWNhc3QpLjxicj4KJmd0Ozxicj4KJmd0 OyBTbyBpdCBtYWtlcyBwZXJmZWN0IHNlbnNlIHRvIHJlZ2lzdGVyIG11bHRpY2FzdCBhZGRyZXNz ZXMgdG8gdGhlIG1hcHBpbmc8YnI+CiZndDsgc3lzdGVtIGFzIEVJRHMgYW5kIHRoZXkgY2FuIG1h cCB0byBSTE9DcyBvZiBzaXRlcyB0aGF0IGhhdmUgam9pbmVkIHRoZSBncm91cC48YnI+CiZndDsg U2VlIGRyYWZ0LWZhcmluYWNjaS1zaWduYWwtZnJlZS1tdWx0aWNhc3QgYXMganVzdCBvbmUgZXhh bXBsZS4gUkZDNjgzMSBhbmQ8YnI+CiZndDsgZHJhZnQtZmFyaW5hY2NpLWxpc3AtbXItc2lnbmFs aW5nIGFyZSBvdGhlciBleGFtcGxlcy48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDsgdG8gdGhl IEVJRC9STE9DIHNlcGFyYXRpb24gYXMgdGhlIHNhbWUgZGVzdGluYXRpb24gSVAgbXVsdGljYXN0 IGFkZHJlc3M8YnI+CiZndDsgJmd0OyZndDsgaXMgdXNlZCBmb3IgYm90aCBwdXJwb3Nlcy4mbmJz cDsgVGhpcyBjb3VsZCB1c2Ugc29tZSBtb3JlIGRpc2N1c3Npb24sIGFzIGl0J3M8YnI+CiZndDsg Jmd0OyZndDsgdW5leHBlY3RlZCBiYXNlZCBvbiB0aGUgY29udGVudHMgb2YgdGhlIGRyYWZ0IHVw IHRvIHRoaXMgcG9pbnQuPGJyPgomZ3Q7PGJyPgomZ3Q7IEkgYmVsaWV2ZSB0aGUgbGV2ZWwgb2Yg ZGV0YWlsIHdlIGhhdmUgaW4gdGhlIGludHJvZHVjdGlvbiBkb2N1bWVudCBpcyBhdCB0aGU8YnI+ CiZndDsgcmlnaHQgbGV2ZWwgb3Igd2UnbGwgZXJyIG9uIGhhdmluZyB3YXkgdG9vIG1hbnkgZGV0 YWlscyBjcm9wIGluLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIDcuMi4mbmJzcDsgTElT UCBmb3IgSVB2NiBDby1leGlzdGVuY2U8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZn dDsmbmJzcDsgJm5ic3A7IExJU1AgZW5jYXBzdWxhdGlvbnMgYWxsb3dzIHRvIHRyYW5zcG9ydCBw YWNrZXRzIHVzaW5nIEVJRHMgZnJvbSBhPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBn aXZlbiBhZGRyZXNzIGZhbWlseSAoZS5nLiwgSVB2Nikgd2l0aCBwYWNrZXRzIGZyb20gb3RoZXIg YWRkcmVzczxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgZmFtaWxpZXMgKGUuZy4sIElQ djQpLjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBIb3cgZG9lcyB0aGF0IHdv cmsgZm9yIG11bHRpY2FzdCB0cmFmZmljLCB3aGVyZSB0aGUgZGVzdGluYXRpb24gYWRkcmVzczxi cj4KJmd0OyAmZ3Q7Jmd0OyAoRykgaGFzIHRvIGJlIHRoZSBzYW1lIGluIGJvdGggdGhlIGlubmVy IGFuZCBvdXRlciBoZWFkZXJzPyZuYnNwOyBBcmUgRVRSczxicj4KJmd0OyAmZ3Q7Jmd0OyBhbmQg SVRScyBleHBlY3RlZCB0byBtYXAgSVB2NiBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIElQdjQgYW5k IHYudi4/PGJyPgomZ3Q7PGJyPgomZ3Q7IFRoZSBtYXBwaW5nIHN5c3RlbSBjYW4gbWFwIGFuIChT LUVJRC1pcHY2LCBncm91cC1pcHY2KSAyLXR1cGxlIHRvIGEgUkxPQyBzZXQ8YnI+CiZndDsgdGhh dCBsb29rZWQgbGlrZSB0aGlzIChpcHY0LW11bHRpY2FzdCwgaXB2NC11bmljYXN0KSBtZWFuIHRo ZSBJVFIgdGhhdDxicj4KJmd0OyByZWNlaXZlcyB0aGUgcGFja2V0IGZyb20gUy1FSUQtaXB2NiB3 b3VsZCByZXBsaWNhdGUgdGhlIHBhY2tldCBhbmQgbXVsdGljYXN0PGJyPgomZ3Q7IGVuY2Fwc3Vs YXRlIHRvIGlwdjQtbXVsdGljYXN0IGFuZCB1bmljYXN0IGVuY2Fwc3VhbHRlIHRvIGlwdjQtdW5p Y2FzdC48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDsgLSA3LjMuJm5ic3A7IExJU1AgZm9yIFZp cnR1YWwgUHJpdmF0ZSBOZXR3b3Jrczxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0 OyBUaGlzIGFsc28gaGFzIG11bHRpY2FzdCBwcm9ibGVtcywgYXMgdGhlcmUgaXMgb25seSBvbmUg aW5zdGFuY2Ugb2YgZWFjaDxicj4KJmd0OyAmZ3Q7Jmd0OyBtdWx0aWNhc3QgYWRkcmVzcyAoRykg aW4gdGhlIHVuZGVybGF5IG5ldHdvcmsuJm5ic3A7IEkgdGhpbmsgSSBjYW4gZmlndXJlIG91dDxi cj4KJmd0OyBob3c8YnI+CiZndDs8YnI+CiZndDsgWW91IGNhbiBtYXAgZnJvbSBFSUQtRyB0byBS TE9DLUcgb25lIHRvIG9uZS4gQnV0IHdlIGhhdmUgc2VlbiBvdmVyIHRoZSBsYXN0PGJyPgomZ3Q7 IGRlY2FkZSBpbiBhIGhhbGYgdGhhdCB3aXRoIGdlbmVyYWwgbXVsdGljYXN0IGRlcGxveW1lbnQg dGhhdCBtYW55LXRvLTEgaXM8YnI+CiZndDsgZGVzaXJhYmxlLiBIZW5jZSwgbm93IHRoYXQgd2Ug aGF2ZSBhIHdheSB0byBtYXAgd2l0aCBhIG5ldHdvcmstYmFzZWQgZGF0YWJhc2UsPGJyPgomZ3Q7 IHdlIGNhbiBtYXAgbXVsdGlwbGUgRUlELUdzIHRvIGEgc2luZ2xlIChvciBtdWx0aXBsZSkgUkxP Qy1Hcy48YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDsgdG8gbWFrZSBtdWx0aWNhc3Qgd29yayBm b3IgdGhpcyB1c2UgY2FzZSwgYnV0IGl0J3Mgbm90IGltbWVkaWF0ZWx5IG9idmlvdXMsPGJyPgom Z3Q7ICZndDsmZ3Q7IGFuZCB0aGUgcmVzdWx0IHdoZW4gdGhlIHNhbWUgdW5kZXJsYXkgbXVsdGlj YXN0IGFkZHJlc3MgaXMgdXNlZCBieSBtb3JlPGJyPgomZ3Q7ICZndDsmZ3Q7IHRoYW4gb25lIFZQ TiBjb3VsZCB3ZWxsIGRlbGl2ZXIgc29tZSB0cmFmZmljIHRvIEVUUnMgdGhhdCBoYXZlIHRvIGRp c2NhcmQ8YnI+CiZndDs8YnI+CiZndDsgVGhpcyBpcyBhIG5lY2Vzc2FyeSBldmlsIHdoZW4gdGhl IHVuZGVybGF5IGlzIHN0YXRlIGNoYWxsZW5nZWQuIEJ1dCBpdCBpcyBhPGJyPgomZ3Q7IHN0YXRl L2JhbmR3aWR0aCB0cmFkZW9mZi4gV2UgaGF2ZSBmb3VuZCB3aXRoIE1WUE4gZGVwbG95bWVudCB0 aGF0IHRoZSBuZXR3b3JrPGJyPgomZ3Q7IGFkbWluIGNvbmZpZ3VyZXMgdGhlIHVuZGVybHkgb3Ig c2ltcGx5IHVuaWNhc3RzLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBpdCBiZWNhdXNlIHRo ZSBJbnN0YW5jZSBJRCBpcyB3cm9uZyAoYW5kIHRoYXQgZXhjZXNzaXZlIGRlbGl2ZXJ5IGlzIGE8 YnI+CiZndDsgJmd0OyZndDsgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiwgc2VlIG1pbm9yIGlzc3Vl IG9uIFNlY3Rpb24gOCBiZWxvdykuJm5ic3A7IEkgdGhpbmsgYW48YnI+CiZndDsgJmd0OyZndDsg ZXhwbGFuYXRpb24gaXMgaW4gb3JkZXIuPGJyPgomZ3Q7PGJyPgomZ3Q7IFRoZXJlIGFyZSBqdXN0 IHRvbyBtYW55IGNvbWJpbmF0aW9ucyB0byBtYWtlIGEgaGlnaC1sZXZlbCBkZXNjcmlwdGlvbiBz aW1wbGU8YnI+CiZndDsgdG8gdW5kZXJzdGFuZC4gVGhlIGN1cnJlbnQgaW50cm9kdWN0aW9uIHRl eHQgZG9lcyBhIGZpbmQgam9iIHByb3ZpZGluZzxicj4KJmd0OyByZWZlcmVuY2VzIGZvciBzb21l b25lIHRvIGdvIG9mZiBhbmQgZ2V0IHRoZSBkZXRhaWxzLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7 Jmd0OyAtLSBNaW5vciBJc3N1ZXMgLS08YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZn dDsgVGhlcmUgc2VlbXMgdG8gYmUgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiB0aGF0IHRoZSBlbmQg aG9zdCBhbmQgaXRzPGJyPgomZ3Q7ICZndDsmZ3Q7IElUUiAoeFRSKSBhcmUgaW4gdGhlIHNhbWUg ZG9tYWluIG9yIEF1dG9ub21vdXMgU3lzdGVtLiZuYnNwOyBGb3IgaW5jcmVtZW50YWw8YnI+CiZn dDs8YnI+CiZndDsgVGhpcyBpcyB0cnVlIHdoZW4geW91IGNhbGwgdGhlIGRvbWFpbiBhICJMSVNQ IHNpdGUiLiBCdXQgaWYgdGhlIHNpdGUgaXM8YnI+CiZndDsgdW5jaGFuZ2VkIGFuZCBvbmUgdXNl cyBQSVRScywgbWF5YmUgZXZlbiBjbG9zZSB0byB0aGUgc2l0ZSwgbGlrZSBpbiBhIFBFPGJyPgom Z3Q7IHJvdXRlciwgdGhlbiB0aGUgUElUUiBpcyBkZWZpbml0ZWx5IGluIGFub3RoZXIgQVMuIEJ1 dCBub3RlIEkgc2FpZCBQSVRSIGFuZDxicj4KJmd0OyBub3QgSVRSLiBUaGUgcmVhc29uIGJlaW5n IGlzIGJlY2F1c2UgYW4gSVRSIGlzIGNvbmZpZ3VyZWQgd2l0aCBkYXRhYmFzZS08YnI+CiZndDsg bWFwcGluZyBwcmVmaXhlcyB0aGF0IGlzIHVzZXMgdG8gZW5jYXBzdWxhdGUgcGFja2V0cyBmcm9t IHN1Y2ggYWRkcmVzc2VzLjxicj4KJmd0OyBWZXJzdXMgdGhlIFBJVFIgYmVpbmcgYW4gSVRSIHdp dGggKm5vIGRhdGFiYXNlLW1hcHBpbmdzKiBwcm92aWRpbmcgYSBtdWNoIG1vcmU8YnI+CiZndDsg bGFyZ2VyL29yIG1vcmUgYWdncmVndGFibGUgc2VydmljZS48YnI+CiZndDs8YnI+CiZndDsgJmd0 OyZndDsgZGVwbG95bWVudCwgSSBkb24ndCB0aGluayB0aGF0J3MgYWx3YXlzIHRoZSBjYXNlLCBi dXQgSSB0aGluayB0aGF0IG9ubHk8YnI+CiZndDsgJmd0OyZndDsgaGFzIGVkaXRvcmlhbCBpbXBh Y3Qgb24gdGhpcyBkb2N1bWVudCwgYXMgSSBkb24ndCB0aGluayBhbnkgb2YgdGhlPGJyPgomZ3Q7 ICZndDsmZ3Q7IGZ1bmRhbWVudGFsIExJU1AgbWVjaGFuaXNtcyBhcmUgYWZmZWN0ZWQuJm5ic3A7 IFRoZSBhdXRob3JzIHNob3VsZCBsb29rIGZvcjxicj4KJmd0OyAmZ3Q7Jmd0OyB1c2Ugb2YgImRv bWFpbiIgYW5kICJBdXRvbm9tb3VzIFN5c3RlbSIgYW5kIGVuc3VyZSB0aGF0IHRoZSB0ZXh0IGlz PGJyPgomZ3Q7ICZndDsmZ3Q7IGdlbmVyYWxpemVkIHRvIHRoZSBjYXNlIHdoZXJlIHRoZSBlbmQg aG9zdCBhbmQgSVRSIGFyZSBtb3JlIHdpZGVseTxicj4KJmd0OyAmZ3Q7Jmd0OyBzZXBhcmF0ZWQu PGJyPgomZ3Q7PGJyPgomZ3Q7IFdlIGFyZSBvdmVybG9hZGVkIHdpdGggdGVybXMgdGhhdCBjcmVh dGUgdG9wb2xvZ2ljYWwgb3Igb3JnYW5pemF0aW9uIGJvdW5kYXJ5Ljxicj4KJmd0OyBIZW5jZSB3 aHkgd2UgY3JlYXRlZCAiTElTUCBzaXRlIiB3aGljaCBpcyBhbHNvIHRoZSBzYW1lIGFzIGEgIkxJ U1AgVlBOIHNpdGUiLjxicj4KJmd0OyBXaGVyZSBhICJMSVNQIHNpdGUiIHRoYXQgaGFzIG11bHRp cGxlIHRlbm5hbnRzIHdvdWxkIGJlIG11bHRpcGxlICJMSVNQIFZQTjxicj4KJmd0OyBzaXRlcyIu PGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IERlc3BpdGUgbXVsdGlwbGUmbmJzcDsgbWVudGlv bnMgb2YgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgSSBkaWQgbm90PGJyPgomZ3Q7ICZndDsmZ3Q7 IHNlZSBhIGRpc2N1c3Npb24gb2YgaG93IHRoYXQgbWlnaHQgYmUgYWNjb21wbGlzaGVkLiZuYnNw OyBUaGVyZSBpcyBzb21lPGJyPgomZ3Q7PGJyPgomZ3Q7IFRoZXJlIGFyZSBQeFRScyBhbmQgTkFU cy4gQW5kIHJlZmVyZW5jZXMgdG8gdGhlIExJU1AgaW50ZXJ3b3JraW5nIFJGQy48YnI+CiZndDs8 YnI+CiZndDsgJmd0OyZndDsgdXNlZnVsIGNvbnRlbnQgaW4gU2VjdGlvbiAzLjUsIGJ1dCB0aGF0 J3MgYXQgYmVzdCBhbiBpbmNvbXBsZXRlPGJyPgomZ3Q7ICZndDsmZ3Q7IGV4cGxhbmF0aW9uLiZu YnNwOyBUaGlzIGlzIGFuIE9QUy1EaXIgcmV2aWV3IGNvbmNlcm4gLSBpdCBmYWxscyB1bmRlcjxi cj4KJmd0OyAmZ3Q7Jmd0OyBBLjEuMyBpbiBBcHBlbmRpeCBBIG9mIFJGQyA1NzA2OiBIYXMgdGhl IG1pZ3JhdGlvbiBwYXRoIGJlZW4gZGlzY3Vzc2VkPzxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0 OyAmZ3Q7Jmd0OyAtIDMuMy4xLiZuYnNwOyBMSVNQIEVuY2Fwc3VsYXRpb248YnI+CiZndDsgJmd0 OyZndDs8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IHRoZSBzb3VyY2UgcG9ydCBpcyBz ZWxlY3RlZCBieTxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhlIElUUiBhbmQgaWdu b3JlZCBvbiByZWNlcHRpb24uPGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IFBs ZWFzZSBtZW50aW9uIG11bHRpcGF0aGluZyAoZS5nLiwgRUNNUCBhbmQgTEFHKSBhcyBwb3NzaWJs ZSBpbmZsdWVuY2VzPGJyPgomZ3Q7ICZndDsmZ3Q7IG9uIGhvdyBzb3VyY2UgcG9ydHMgYXJlIHNl bGVjdGVkLCBhcyB0aGlzIGltcG9zZXMgc29tZSBsaW1pdHMgb24gd2hhdCBhbjxicj4KJmd0OyAm Z3Q7Jmd0OyBJVFIgY2FuIHJlYXNvbmFibHkgZG8uPGJyPgomZ3Q7PGJyPgomZ3Q7IEVDTVAvTEFH IGRvbid0IGluZmx1ZW5jZSB3aGljaCBzb3VyY2UgcG9ydCBpcyBzZWxlY3RlZC4gSXQgaXMgYSA1 LXR1cGxlIGhhc2g8YnI+CiZndDsgb2YgdGhlIGlubmVyIGhlYWRlciB0aGF0IHNlbGVjdHMgYSBz b3VyY2UgcG9ydCB0aGF0IGluZmx1ZW5jZXMgaG93IGFuIHVuZGVybGF5PGJyPgomZ3Q7IHJvdXRl ciB3b3VsZCBsb2FkLXNwbGl0IHRyYWZmaWMuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEZv ciBPUFMtRGlyLCB0aGlzIG11bHRpcGF0aGluZyBjb25jZXJuIGZhbGxzIHVuZGVyIEEuMS40IGlu IEFwcGVuZGl4IEEgb2Y8YnI+CiZndDsgJmd0OyZndDsgUkZDIDU3MDY6IEhhdmUgdGhlIFJlcXVp cmVtZW50cyBvbiBvdGhlciBwcm90b2NvbHMgYW5kIGZ1bmN0aW9uYWw8YnI+CiZndDsgJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29tcG9uZW50cyBiZWVuIGRpc2N1c3NlZD88 YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IFRoaXMgZGVj aXNpb24gd2FzIG1hZGUgYmVjYXVzZSB0aGU8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7 IHR5cGljYWwgdHJhbnNwb3J0IHByb3RvY29scyB1c2VkIGJ5IHRoZSBhcHBsaWNhdGlvbnMgYWxy ZWFkeSBpbmNsdWRlPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBhIGNoZWNrc3VtLCBi eSBuZWdsZWN0aW5nIHRoZSBhZGRpdGlvbmFsIFVEUCBlbmNhcHN1bGF0aW9uIGNoZWNrc3VtPGJy PgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB4VFJzIGNhbiBmb3J3YXJkIHBhY2tldHMgbW9y ZSBlZmZpY2llbnRseS48YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgR3JvYW4h Jm5ic3A7IEkgaGF2ZSBhbiBleHF1aXNpdGUgc2V0IG9mIHNjYXJzIG9uIFVEUCB6ZXJvIGNoZWNr c3VtcyBmb3IgSVB2Njxicj4KJmd0OyAmZ3Q7Jmd0OyBmcm9tIHdvcmtpbmcgb24gdGhlIE1QTFMg aW4gVURQIGRyYWZ0LCBzbyBJIG1heSBiZSBvdmVybHkgc2Vuc2l0aXZlIHRvPGJyPgomZ3Q7ICZn dDsmZ3Q7IHRoaXMgY29uY2Vybi4mbmJzcDsgVGhlIGRvd25zaWRlIG9mIHRoaXMgZWZmaWNpZW5j eSBpcyB0aGF0IHRoZXJlIGlzIG5vPGJyPgomZ3Q7ICZndDsmZ3Q7IGNoZWNrc3VtIGNvdmVyYWdl IG9mIHRoZSBJUHY2IGhlYWRlciB3aGVuIHplcm8gVURQIGNoZWNrc3VtcyBhcmUgdXNlZC48YnI+ CiZndDsgJmd0OyZndDsgVGhhdCBzaG91bGQgYXQgbGVhc3QgYmUgbWVudGlvbmVkIGhlcmUsIHdp dGggYSBzdW1tYXJ5IG9mIHdoeSB0aGF0J3Mgb2s8YnI+CiZndDsgJmd0OyZndDsgLSB0aGUgZGV0 YWlsZWQganVzdGlmaWNhdGlvbiBmb3Igd2h5IHRoYXQncyBvayBjYW4gYmUgbGVmdCB0byBvdGhl cjxicj4KJmd0OyAmZ3Q7Jmd0OyBkb2N1bWVudHMuPGJyPgomZ3Q7PGJyPgomZ3Q7IE15IGhlYWQg c3BpbnMgZXZlcnkgdGltZSBJIGhlYXIgYWJvdXQgdGhpcyBzdWJqZWN0LiBUaGlzIHN1YmplY3Qg aGFzIGJlZW48YnI+CiZndDsgdGFsa2VkIGFib3V0IGZyb20gMTAwcyBvZiBwZW9wbGUgZm9yIGEg ZGVjYWRlLiBXZSBoYXZlIENSQyBvbiBsaW5rcywgd2UgaGF2ZTxicj4KJmd0OyBhcHBzIHRoYXQg dXNlIFRDUCBhbmQgVURQIGNoZWNrc3Vtcy4gTnVmIHNhaWQuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZn dDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0tIE5pdHMvRWRpdG9yaWFsIENvbW1lbnRzIC0tPGJy PgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0gVG9wIG9mIHAuNDo8YnI+CiZndDsg Jmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IFRoZSBpbml0aWFsIG1vdGl2 YXRpb24gaW4gdGhlIExJU1AgZWZmb3J0IGlzIHRvIGJlIGZpbmQgaW4gdGhlPGJyPgomZ3Q7ICZn dDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7ICJmaW5kIiAtJmd0OyAiZm91bmQiPGJyPgomZ3Q7ICZn dDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0gU2VjdGlvbiAzLjEsIGZpcnN0IGJ1bGxldCBpdGVt PGJyPgomZ3Q7PGJyPgomZ3Q7IFdlIHdpbGwgY2VydGFpbmx5IGZpeGUgdGhlc2UuIFRoYW5rcy48 YnI+CiZndDs8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtEZXZpY2VzIGFyZSBhc3NpZ25lZCB3aXRoIHJlbGF0aXZlbHkgb3BhcXVl IGlkZW50aXR5PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWVh bmluZ2Z1bCBhZGRyZXNzZXMgdGhhdCBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlaXIgdG9wb2xvZ2lj YWw8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2NhdGlvbi48 YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgSSBkb24ndCB1bmRlcnN0YW5kICJy ZWxhdGl2ZWx5IG9wYXF1ZSBpZGVudGl0eSBtZWFuaW5nZnVsIiBhbmQ8YnI+CiZndDsgJmd0OyZn dDsgc3VnZ2VzdCByZXdyaXRpbmcgdGhlIHNlbnRlbmNlLiZuYnNwOyBJbiBwYXJ0aWN1bGFyIC0g b3BhcXVlIHRvIHdoYXQ/PGJyPgomZ3Q7ICZndDsmZ3Q7IG1lYW5pbmdmdWwgdG8gd2hhdCBpbiB3 aGF0IG1hbm5lcj88YnI+CiZndDs8YnI+CiZndDsgV2VsbCBiZWFjdXNlIGl0IGlzIGFzIGFjY3Vy YXRlIGFzIGl0IGNhbiBiZS4gSWYgYXV0b21vYmlsZXMgYXJlIGdvaW5nIHRvIGJlPGJyPgomZ3Q7 IGFzc2lnbmVkIEVJRHMgZnJvbSBhIFZJTiBudW1iZXIgYWxsb2NhdGlvbiBmcm9tIGEgbWFudWZh Y3R1cmUsIHRoZSBhZGRyZXNzIGlzPGJyPgomZ3Q7IHJlbGF0aXZlbHkgb3BhcXVlLiBJZiBhIFZN IGluIGEgZGF0YS1jZW50ZXIgaXMgZ29pbmcgdG8gYmUgYXNzaWduZWQgYW4gRUlEPGJyPgomZ3Q7 IGZyb20gdGhlIHNldCBvZiBwcmVmaXhlcyBhbHJlYWR5IGJlaW5nIHVzZWQgYW5kIGFsbG9jYXRl ZCB0byB0aGF0IGRhdGEtY2VudGVyLDxicj4KJmd0OyB0aGVuIHRoZXJlIGlzIGEgZ29vZCBjaGFu Y2UgdGhhdCBhZGRyZXNzIGlzIGluIGEgcG93ZXItb2YtMiBibG9jayB0aGF0IGlzPGJyPgomZ3Q7 IHN1bW1hcml6YWJsZSBpbiB0aGUgSUdQLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4K Jmd0OyAmZ3Q7Jmd0OyAtIFNlY3Rpb24gMy4yLCBzZWNvbmQgcGFyYWdyYXBoPGJyPgomZ3Q7ICZn dDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEp1ZGdpbmcgZnJvbSB0aGUgZmlndXJlLCB4VFJzIGFy ZSB0aGUgY29tbW9uIGNhc2UsIHdpdGggc2luZ2xlLTxicj4KJmd0OyAmZ3Q7Jmd0OyBmdW5jdGlv biBJVFJzIGFuZCBFVFJzIGJlaW5nIHJhcmUuJm5ic3A7IEl0IG1pZ2h0IGJlIGdvb2QgdG8gc2F5 IHRoYXQ8YnI+CiZndDsgJmd0OyZndDsgYW5kIGRpc2N1c3Mgd2hlbiBJVFJzIGFuZCBFVFJzIHRo YXQgYXJlIG5vdCB4VFJzIGFyZSBhcHByb3ByaWF0ZTxicj4KJmd0OyAmZ3Q7Jmd0OyB0byB1c2Uu PGJyPgomZ3Q7PGJyPgomZ3Q7IFdoZW4geW91IHdhbnQgZWdyZXNzIHBhdGggc2VsZWN0aW9uIHRv IGhhcHBlbiBmdXJ0aGVyIG91dCBpbiB0aGUgdG9wbG9naWNhbDxicj4KJmd0OyBmcm9tIHRoZSBz b3VyY2UgbG9jYXRpb24sIHRoZW4geW91IHB1dCBhbiBJVFItb25seSBzeXN0ZW0gdGhlcmUuIFdo ZXJlIGluZ3Jlc3M8YnI+CiZndDsgdG8gdGhlIHNhbWUgc291cmNlIChkZXN0aW5hdGlvbiBpbiB0 aGlzIGRpcmVjdGlvbiksIHRoZSBFVFIgY2FuIGJlIGNsb3NlciB0bzxicj4KJmd0OyB0aGUgZGVz dGluYXRpb24uPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0g M3JkIHBhcmFncmFwaCBvbiBwLjc6PGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7 PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBGaW5hbGx5LCB0aGUgTElTUCBhcmNoaXRl Y3R1cmUgZW1waGFzaXplcyBhIGNvc3QgZWZmZWN0aXZlPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyBpbmNyZW1lbnRhbCBkZXBsb3ltZW50Ljxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0 OyAmZ3Q7Jmd0OyBJJ2QgZGVsZXRlICJjb3N0IGVmZmVjdGl2ZSIgaGVyZSBhbmQgbG9vayBmb3Ig b3RoZXIgb2NjdXJyZW5jZXM8YnI+CiZndDsgJmd0OyZndDsgb2YgImNvc3QiIGFzIGNhbmRpZGF0 ZXMgZm9yIGRlbGV0aW9uLiZuYnNwOyBUaGlzIGlzIHN1cHBvc2VkIHRvIGJlPGJyPgomZ3Q7ICZn dDsmZ3Q7IGEgdGVjaG5pY2FsIGRvY3VtZW50LCBzbyBkaXNjdXNzaW9uIG9mIGNvc3RzIGlzIGEg Yml0IG9mZi10YXJnZXQuPGJyPgomZ3Q7PGJyPgomZ3Q7IEZhaXIgZW5vdWdoLjxicj4KJmd0Ozxi cj4KJmd0OyAmZ3Q7Jmd0OyAtIEZpcnN0IGl0ZW0gYWZ0ZXIgRmlndXJlIDI6PGJyPgomZ3Q7ICZn dDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAxLiZuYnNwOyBIb3N0QSByZXRy aWV2ZXMgdGhlIEVJRF9CIG9mIEhvc3RCLCB0eXBpY2FsbHkgcXVlcnlpbmcgdGhlIEROUzxicj4K Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQgb2J0YWluaW5nIGFu ZCBBIG9yIEFBQUEgcmVjb3JkLjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAi YW5kIEEiIC0mZ3Q7ICJhbiBBIiZuYnNwOyAoc3BlbGxpbmcgY2hlY2tlcnMgZG9uJ3QgY2F0Y2gg ZXZlcnl0aGluZykuPGJyPgomZ3Q7PGJyPgomZ3Q7IEFscmVhZHkgbm90ZWQgYW5kIHdpbGwgYmUg Zml4ZWQuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IC0gMy4z LjEuJm5ic3A7IExJU1AgRW5jYXBzdWxhdGlvbjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIFJlY3Vyc2l2ZTxicj4KJmd0 OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdHVubmVscyBhcmUgbmVzdGVkIHR1bm5lbHMgYW5kIGFy ZSBpbXBsZW1lbnRlZCBieSB1c2luZyBtdWx0aXBsZSBMSVNQPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyBlbmNhcHN1bGF0aW9ucyBvbiBhIHBhY2tldC48YnI+CiZndDsgJmd0OyZndDs8 YnI+CiZndDsgJmd0OyZndDsgVGhlIGFib3ZlIHNlbnRlbmNlIHNlZW1zIG91dCBvZiBwbGFjZSBp biB0aGUgbWlkZGxlIG9mIGEgcGFyYWdyYXBoIGFib3V0PGJyPgomZ3Q7ICZndDsmZ3Q7IFJlLWVu Y2Fwc3VsYXRpbmcgdHVubmVscyBhbmQgcm91dGVycyAtIEkgc3VnZ2VzdCBtb3ZpbmcgaXQgZG93 biBpbnRvIGl0czxicj4KJmd0OyAmZ3Q7Jmd0OyBvd24gcGFyYWdyYXBoIGFuZCBwZXJoYXBzIGFk ZGluZyBhIHNlbnRlbmNlIGFib3V0IHdoZXJlL2hvdyBSZWN1cnNpdmU8YnI+CiZndDsgJmd0OyZn dDsgdHVubmVscyBtYXkgYmUgdXNlZnVsLjxicj4KJmd0Ozxicj4KJmd0OyBHb29kIHN1Z2dlc3Rp b24gYW5kIG1ha2VzIHNlbnNlLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIDMuMy4yLiZu YnNwOyBMSVNQIEZvcndhcmRpbmcgU3RhdGU8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0 OyZndDsmbmJzcDsgJm5ic3A7IEluIHRoZSBMSVNQIGFyY2hpdGVjdHVyZSwgSVRScyBrZWVwIGp1 c3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHJvdXRlPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyB0cmFmZmljIGZsb3dpbmcgdGhyb3VnaCBpdC48YnI+CiZndDsgJmd0OyZndDs8YnI+CiZn dDsgJmd0OyZndDsgIml0LiIgLSZndDsgInRoZW0uIjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0 OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgTWVhbmluZyB0aGF0LCBJVFJzIHJldHJpZXZlIGZyb20g dGhlPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBMSVNQIE1hcHBpbmcgU3lzdGVtIG1h cHBpbmdzIGJldHdlZW4gRUlEIHByZWZpeGVzIGFuZCBSTE9DcyB0aGF0IGFyZTxicj4KJmd0OyAm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdXNlZCB0byBlbmNhcHN1bGF0ZSBwYWNrZXRzLjxicj4KJmd0 OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIHRoZSBmaXJzdCB1c2Ugb2YgdGhl IG5vdGlvbiBvZiBFSUQgcHJlZml4ZXMuJm5ic3A7IFRoYXQgY29uY2VwdCBzaG91bGQ8YnI+CiZn dDsgJmd0OyZndDsgYmUgZXhwbGFpbmVkIGJlZm9yZSBpdCBpcyB1c2VkLCBhbHRob3VnaCBhIGZv cndhcmQgcmVmZXJlbmNlIHRvIHNlY3Rpb248YnI+CiZndDsgJmd0OyZndDsgMy40LjEgbWF5IHN1 ZmZpY2UuJm5ic3A7IEl0IG1pZ2h0IGJlIGJldHRlciB0byByZXdyaXRlIHRoaXMgcGFyYWdyYXBo IGluIHRlcm1zPGJyPgomZ3Q7ICZndDsmZ3Q7IG9mIEVJRHMgYW5kIGxlYXZlIHRoZSBub3Rpb24g b2YgRUlEIHByZWZpeGVzIHRvIHNlY3Rpb24gMy40LjEuPGJyPgomZ3Q7PGJyPgomZ3Q7IEhtbSwg SSdsbCBsZXQgQWxiZXJ0IGFuZCBEYW1pZW4gZGVjaWRlIGlmIHdlIHNob3VsZCBzdGF0ZSAiRUlE LXByZWZpeGVzIjxicj4KJmd0OyBldmVyeXdoZXJlIGluc3RlYWQgb2YganVzdCAiRUlEIi48YnI+ CiZndDs8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsgLSA0LjQuJm5ic3A7IE1U VSBIYW5kbGluZzxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgQWRkaXRpb25hbGx5LCBMSVNQIGFsc28gcmVjb21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmls aXR5IG9mIGxvY2F0b3JzPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBieSB1c2luZyBp bmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgdW5kZXJsYXksIGluIHBhcnRpY3VsYXI6PGJyPgom Z3Q7ICZndDsmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IEl0J2QgYmUgdXNlZnVsIHRvIGFkZCBhIHNl bnRlbmNlIG9yIHR3byBhYm91dCBob3cgTElTUCBhbmQgdGhlIHRlY2huaXF1ZXM8YnI+CiZndDsg Jmd0OyZndDsgaW4gdGhpcyBzZWN0aW9uIGludGVyYWN0IHdpdGggaG9zdCB1c2Ugb2YgUE1UVUQg YW5kIFBMUE1UVUQuPGJyPgomZ3Q7PGJyPgomZ3Q7IFRoaXMgaXMgYSBsb3Qgb2YgZGV0YWlsIGJl Y2F1c2UgaW4gUkZDNjgzMCB3ZSBoYXZlIDMgcG9zaXRpb25zIG9yIG9wdGlvbnMgb248YnI+CiZn dDsgdGhlIHN1YmplY3QuIEFuZCB3ZSBkaWQgcHJvdmlkZSBhIHJlZmVyZW5jZSB0byBSRkM2ODMw IGZvciB0aGlzIHRvcGljLjxicj4KJmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyAtIE5leHQgdG8gbGFz dCBwYXJhZ3JhcGggb24gcC4xNzo8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZndDsm bmJzcDsgJm5ic3A7IEFkZGl0aW9uYWxseSwgTElTUCBhbHNvIHJlY29tbWVuZHMgaW5mZXJyaW5n IHJlYWNoYWJpbGl0eSBvZiBsb2NhdG9yczxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg YnkgdXNpbmcgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlIHVuZGVybGF5LCBpbiBwYXJ0aWN1 bGFyOjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGxvb2tzIGxpa2Ug aXQncyBhIHBhcmFncmFwaCBlYXJseSBhbmQgbmVlZHMgdG8gYmUgbW92ZWQgZG93biB0bzxicj4K Jmd0OyAmZ3Q7Jmd0OyBhZnRlciB0aGUgcGFyYWdyYXBoIHRoYXQgZm9sbG93cyBpdC48YnI+CiZn dDs8YnI+CiZndDsgQWdyZWUuPGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IGlkbml0cyAyLjEz LjAxIGRpZG4ndCBmaW5kIGFueSBuaXRzLjxicj4KJmd0OyAmZ3Q7Jmd0Ozxicj4KJmd0OyAmZ3Q7 Jmd0OyBUaGFua3MsPGJyPgomZ3Q7ICZndDsmZ3Q7IC0tRGF2aWQ8YnI+CiZndDs8YnI+CiZndDsg VGhhbmtzIGFnYWluIERhdmlkLjxicj4KJmd0Ozxicj4KJmd0OyBEaW5vPG86cD48L286cD48L3A+ CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CgogPC9i b2R5Pg== ----_com.android.email_127491863198918-- From nobody Wed Feb 11 20:39:47 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA401A8F3C; Wed, 11 Feb 2015 20:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEN4tD66a72y; Wed, 11 Feb 2015 20:39:36 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (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 36FBA1A037C; Wed, 11 Feb 2015 20:39:36 -0800 (PST) Received: by pdev10 with SMTP id v10so9211870pde.10; Wed, 11 Feb 2015 20:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pT674uF5d7A1bPwxc9xMC+lNANWuXem4qFTHyjZ8oLI=; b=R/sx3WhcYT0pOi/NzaN0Y2LMD5KSSdd6hGKpZf67WYHrSeflahmD0zPspo+O2CxejP GiJY0fiPJjq4/Z2DUQopbm5icL1RBVt/xc8/3yV85/JsGJWK9Yavi634hUd4qYOHtwFS rIXW1rkXQ+BS/SiibxWvleREueY4PZjF8ClCqxfi9x7b3AfBSlb6Jw5eDSbmw/Ldu75g fsegPFroqsVuw9oJhzAzhwGfKrjybU73Z1mzM1dSJhoflUtX953hKfBLQrjZ8gICPYRx q03iw5I2xgOtapTLg2jafzqLo5Ujui1K2QPLaGhaZnk//4kLTolcC4e7mRaf0K+SVnfp pSig== X-Received: by 10.68.94.69 with SMTP id da5mr3034376pbb.99.1423715975834; Wed, 11 Feb 2015 20:39:35 -0800 (PST) Received: from [172.20.10.2] ([166.170.38.252]) by mx.google.com with ESMTPSA id c2sm2348754pdi.25.2015.02.11.20.39.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Feb 2015 20:39:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: Date: Wed, 11 Feb 2015 20:39:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DA982D.60200@joelhalpern.com> To: "Black, David" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 04:39:40 -0000 > Dino - thanks for the response. >=20 > On the major issues, it looks like both [A] and [B] involve only the = text > in this draft and nothing beyond, which is good news. I have a simple = text > suggestion for [A], but it looks like [B] is going to require some = careful > editing, as one of the primary causes is that the draft is sloppy in = using > the same symbol "G" to represent both EID and RLOC multicast groups. Okay for [A] but not true for [B]. In RFC6831, a multicast address G is = not in the mapping database because signaling is performed from ETR to = ITR. What's in the mapping database is the EID S from the (S,G) the = source sends from and to. > On the minor issues, I have text suggestions for three of the four, = and > I'd like to temporarily defer further discussion the IPv6 UDP zero > checksum "tarpit" in favor of resolving everything else first. Sounds good David. > On the nits/editorial comments, all the suggestions in your email are = fine > with me. FWIW, I regard that portion of a review as almost entirely > subject to the draft authors' discretion (and editorial taste). >=20 >>>> [A] EID mobility vs. EID prefixes >>=20 >> ... from the start of the LISP design (circa 2007), an prefix is what = moves. >> And a specific EID is simply a /32 or /128 prefix. Here is a = practical >> example: >=20 > A statement that the mobility use cases need to employ /32 and /128 = prefixes, > and not anything coarser should suffice. That should be added to = Section 5. Well I think it is not true. Because EID-prefixes are moved but is = outside of the VM-mobility use-case. >=20 >>>> [B] LISP Multicast vs. EID/RLOC separate >>>>=20 >>>> - 6. Multicast >>>>=20 >>>> This is interesting, multicast addresses (G) look like they're an = exception >>=20 >> They are really not. >=20 > My concern is that as I read the draft, it leaves me with the strong = impression > that the same multicast addresses (G) are being used in both the = overlay > (as EIDs) and the underlay (as RLOCs). =46rom your response, I = conclude that this Understand. We state in RFC6831 that it can map one-to-one or = many-to-one. We'll make that more clear in the introduction document. > is not the case (and I have no argument with that). Rather, Section 6 = needs to > bluntly state that multicast addresses are mapped between EID and RLOC = space at > both ITRs and ETRs, so that the following inference is obvious from = the text > (it's currently not obvious): Right, agree. > So it makes perfect sense to register multicast addresses to the = mapping >> system as EIDs and they can map to RLOCs of sites that have joined = the group. >=20 > As part of this, I strongly recommend moving away from use of "G" to = refer to > multicast groups in both the overlay and underlay. Careful use of = G-EID > and G-RLOC would significantly improve clarity. Well we have not used G-EID in any documentation. And since we want to = encourage the use of SSM in the underlay and how we signal in the = overlay, we simply call the "eid" the 2-tuple (S,G). > --- > If the above are done for [A] and [B] in Sections 5 and 6, then the = text for the > use cases in Section 7 should not need further attention. > --- >=20 >>>> -- Minor Issues -- >>>>=20 >>>> There seems to be an implicit assumption that the end host and its >>>> ITR (xTR) are in the same domain or Autonomous System. For = incremental >>=20 >> This is true when you call the domain a "LISP site". But if the site = is >> unchanged and one uses PITRs, maybe even close to the site, like in a = PE >> router, then the PITR is definitely in another AS. >=20 > Looking at the text, it seems that "LISP site" and "domain" are the = same > concept for this draft. That would be useful to state, IMHO but I'll = leave > the decision on whether to do so to you and the draft authors. >=20 > On rereading, my concerns seem to be triggered mostly by this sentence = in > Section 3.2: >=20 > The edge consists of LISP sites (e.g., an > Autonomous System) that use EID addresses. >=20 > I think a small change to the last sentence in that paragraph would = resolve > my concern without distracting from the narrative: >=20 > OLD > EIDs do not > contain inter-domain topological information and because of this, > EIDs are usually routable at the edge (within LISP sites) or in the > non-LISP Internet. > NEW > EIDs do not > contain inter-domain topological information and because of this, > EIDs are usually routable at the edge (within LISP sites) or in the > non-LISP Internet; see Section 3.5 for discussion of LISP site > internetworking with non-LISP sites and domains in the Internet. Ack. >=20 >>>> Despite multiple mentions of incremental deployment, I did not >>>> see a discussion of how that might be accomplished. >>=20 >> There are PxTRs and NATs. And references to the LISP interworking = RFC. >=20 > Ok, can we just say so in Section 3.5? Adding the following sentence > to the end of the section would suffice: >=20 > PITRs, PETRs and LISP-NAT support incremental deployment of LISP > by providing significant flexibility in location of the boundaries > between the LISP and non-LISP portions of the network, and making > it reasonable to change those boundaries over time. Yes. > - 3.3.1. LISP Encapsulation >>>>=20 >>>> the source port is selected by >>>> the ITR and ignored on reception. >>>>=20 >>>> Please mention multipathing (e.g., ECMP and LAG) as possible = influences >>>> on how source ports are selected, as this imposes some limits on = what an >>>> ITR can reasonably do. >>=20 >> ECMP/LAG don't influence which source port is selected. It is a = 5-tuple hash >> of the inner header that selects a source port that influences how an = underlay >> router would load-split traffic. >=20 > Please state that a 5-tuple hash is used. ECMP/LAG is among the = important Well there can be other ways to hash and that is detail not needed at = this level IMO. We suggest a 5-tuple hash in RFC6830. > reasons why, but that doesn't need to be stated if you prefer not to. = An > example of something that needs to be excluded is that using a random > number generator to set the source port would be wrong - I could = suggest > citing draft-ietf-dart-dscp-rtp for related discussion (and lots more > details), but I don't think that's necessary. How about stating the source-port should not change for a flow or it = causes an underlay router to resequence packets over lags? > -- IPv6 zero UDP checksum >=20 >> My head spins every time I hear about this subject. This subject has = been >> talked about from 100s of people for a decade. We have CRC on links, = we have >> apps that use TCP and UDP checksums. Nuf said. >=20 > Understood - there's more than one set of scars on this one :-(. = Let's come back > to this topic after we've resolved everything else, and please keep in = mind > that I tagged this as a minor issue, not a major one (e.g., the above = changes > for [A] and [B] are far more important, IMHO). Ack. Thanks again. Dino >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, February 11, 2015 2:19 PM >> To: Joel M. Halpern >> Cc: Black, David; Albert Cabellos; Damien Saucez; ops-dir@ietf.org; >> ietf@ietf.org; lisp@ietf.org >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >>=20 >>> I will leave most of these for the authors to comment on. >>=20 >> See my comments inline. Thanks David for your detailed review and = commentary. >>=20 >>> With regard to your question about incremental deployment, that is = the >> domain of the LISP Deployment document, and was deliberately only = lightly >> covered here. I am not sure what we can do to address your comment = without >> duplicating the entirety of that document. >>=20 >> That is the risk we may have with many of your comments. We have a = lot of >> detail in the already 9 published RFCs and this document really is = to take >> all that detail and summarize as an easily understandable description = of a >> cohesive design. >>=20 >>> With regard to UDP Zero, this was approved by the IESG and published = as an >> RFC. It is part of the way the protocol is defined. If there are = specific >> changes you would like to see in the explanatory text, I am sure >>=20 >> Definitely agreed. In fact we instigated UDP zero. And I continually = talk to >> hardware engineers and they all believe we made the right decision. = So hats >> off to the IETF for being practical. >>=20 >>> we could include them. If you are looking for a change in the = behavior, >> this document can not make changes to the LISP behavior. >>=20 >> Yes, an important point. >>=20 >>>> I found a couple of major issues that I hope arise from the >>>> summarization of LISP in this draft, as opposed to being problems = in >>>> the actual LISP protocols. I also found a few minor issues, the = most >>>> important of which is the need for additional security = considerations >>>> discussion on misdelivery, with particular attention to VPNs. >>=20 >> Thanks a ton. >>=20 >>>> -- Major issues -- >>>>=20 >>>> [A] EID mobility vs. EID prefixes >>>>=20 >>>> - 5. Mobility >>>>=20 >>>> I understand how this works when mapping is per-EID, but how does = this work >>>> when the EID of the system that moves is part of an EID prefix, as >> discussed >>>> in Section 3.4.1? Even if the answer is a long version of "Don't = do that!" >>>> it should be explained. >>=20 >> No, from the start of the LISP design (circa 2007), an prefix is what = moves. >> And a specific EID is simply a /32 or /128 prefix. Here is a = practical >> example: >>=20 >> You have a cluster of servers that communicate together for a = particular >> application. They application cluster is running in a set of VMs. = Those VMs >> are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are = currently >> running in a brick-and-mortar data center. Now there is a desire to = move the >> VM cluster to a cloud provider. What is moved is the EID-prefix of = the >> cluster. The mapping system is told that the EID-prefix is changing = its RLOC- >> set from the brick-and-mortar xTRs to the cloud providers xTRs. >>=20 >>>>=20 >>>> - 7.4. LISP for Virtual Machine Mobility in Data Centers >>>>=20 >>>> I don't understand how this works when EID prefixes are used, as = each VM >>>> has its own EID or EIDs, hence the entire prefix range does not = move when >>>> the VM moves. >>>>=20 >>>> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in = Appendix A >>>> of RFC 5706: Has deployment been discussed? and specifically = under: >>>>=20 >>>> * Is the proposed specification deployable? If not, how = could >>>> it be improved? >>>>=20 >>>> as EID prefixes appear to be undeployable for Mobility and VM = Mobility >> usage. >>=20 >> See above example. >>=20 >>>> [B] LISP Multicast vs. EID/RLOC separate >>>>=20 >>>> - 6. Multicast >>>>=20 >>>> This is interesting, multicast addresses (G) look like they're an = exception >>=20 >> They are really not. Since multicast addresses *identify* a group of >> receivers, it is very much an EID and aheres to the definition of an = EID. >> Multicast addresses never had topological signficance but the state >> representing a distribution tree does tell you were the members are = (but the >> identity of the members are not know in multicast). >>=20 >> So it makes perfect sense to register multicast addresses to the = mapping >> system as EIDs and they can map to RLOCs of sites that have joined = the group. >> See draft-farinacci-signal-free-multicast as just one example. = RFC6831 and >> draft-farinacci-lisp-mr-signaling are other examples. >>=20 >>>> to the EID/RLOC separation as the same destination IP multicast = address >>>> is used for both purposes. This could use some more discussion, as = it's >>>> unexpected based on the contents of the draft up to this point. >>=20 >> I believe the level of detail we have in the introduction document is = at the >> right level or we'll err on having way too many details crop in. >>=20 >>>> - 7.2. LISP for IPv6 Co-existence >>>>=20 >>>> LISP encapsulations allows to transport packets using EIDs from a >>>> given address family (e.g., IPv6) with packets from other address >>>> families (e.g., IPv4). >>>>=20 >>>> How does that work for multicast traffic, where the destination = address >>>> (G) has to be the same in both the inner and outer headers? Are = ETRs >>>> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? >>=20 >> The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a = RLOC set >> that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR = that >> receives the packet from S-EID-ipv6 would replicate the packet and = multicast >> encapsulate to ipv4-multicast and unicast encapsualte to = ipv4-unicast. >>=20 >>>> - 7.3. LISP for Virtual Private Networks >>>>=20 >>>> This also has multicast problems, as there is only one instance of = each >>>> multicast address (G) in the underlay network. I think I can = figure out >> how >>=20 >> You can map from EID-G to RLOC-G one to one. But we have seen over = the last >> decade in a half that with general multicast deployment that = many-to-1 is >> desirable. Hence, now that we have a way to map with a network-based = database, >> we can map multiple EID-Gs to a single (or multiple) RLOC-Gs. >>=20 >>>> to make multicast work for this use case, but it's not immediately = obvious, >>>> and the result when the same underlay multicast address is used by = more >>>> than one VPN could well deliver some traffic to ETRs that have to = discard >>=20 >> This is a necessary evil when the underlay is state challenged. But = it is a >> state/bandwidth tradeoff. We have found with MVPN deployment that the = network >> admin configures the underly or simply unicasts. >>=20 >>>> it because the Instance ID is wrong (and that excessive delivery is = a >>>> security consideration, see minor issue on Section 8 below). I = think an >>>> explanation is in order. >>=20 >> There are just too many combinations to make a high-level description = simple >> to understand. The current introduction text does a find job = providing >> references for someone to go off and get the details. >>=20 >>>> -- Minor Issues -- >>>>=20 >>>> There seems to be an implicit assumption that the end host and its >>>> ITR (xTR) are in the same domain or Autonomous System. For = incremental >>=20 >> This is true when you call the domain a "LISP site". But if the site = is >> unchanged and one uses PITRs, maybe even close to the site, like in a = PE >> router, then the PITR is definitely in another AS. But note I said = PITR and >> not ITR. The reason being is because an ITR is configured with = database- >> mapping prefixes that is uses to encapsulate packets from such = addresses. >> Versus the PITR being an ITR with *no database-mappings* providing a = much more >> larger/or more aggregtable service. >>=20 >>>> deployment, I don't think that's always the case, but I think that = only >>>> has editorial impact on this document, as I don't think any of the >>>> fundamental LISP mechanisms are affected. The authors should look = for >>>> use of "domain" and "Autonomous System" and ensure that the text is >>>> generalized to the case where the end host and ITR are more widely >>>> separated. >>=20 >> We are overloaded with terms that create topological or organization = boundary. >> Hence why we created "LISP site" which is also the same as a "LISP = VPN site". >> Where a "LISP site" that has multiple tennants would be multiple = "LISP VPN >> sites". >>=20 >>>> Despite multiple mentions of incremental deployment, I did not >>>> see a discussion of how that might be accomplished. There is some >>=20 >> There are PxTRs and NATs. And references to the LISP interworking = RFC. >>=20 >>>> useful content in Section 3.5, but that's at best an incomplete >>>> explanation. This is an OPS-Dir review concern - it falls under >>>> A.1.3 in Appendix A of RFC 5706: Has the migration path been = discussed? >>>>=20 >>>> - 3.3.1. LISP Encapsulation >>>>=20 >>>> the source port is selected by >>>> the ITR and ignored on reception. >>>>=20 >>>> Please mention multipathing (e.g., ECMP and LAG) as possible = influences >>>> on how source ports are selected, as this imposes some limits on = what an >>>> ITR can reasonably do. >>=20 >> ECMP/LAG don't influence which source port is selected. It is a = 5-tuple hash >> of the inner header that selects a source port that influences how an = underlay >> router would load-split traffic. >>=20 >>>> For OPS-Dir, this multipathing concern falls under A.1.4 in = Appendix A of >>>> RFC 5706: Have the Requirements on other protocols and functional >>>> components been discussed? >>>>=20 >>>> This decision was made because the >>>> typical transport protocols used by the applications already = include >>>> a checksum, by neglecting the additional UDP encapsulation = checksum >>>> xTRs can forward packets more efficiently. >>>>=20 >>>> Groan! I have an exquisite set of scars on UDP zero checksums for = IPv6 >>>> from working on the MPLS in UDP draft, so I may be overly sensitive = to >>>> this concern. The downside of this efficiency is that there is no >>>> checksum coverage of the IPv6 header when zero UDP checksums are = used. >>>> That should at least be mentioned here, with a summary of why = that's ok >>>> - the detailed justification for why that's ok can be left to other >>>> documents. >>=20 >> My head spins every time I hear about this subject. This subject has = been >> talked about from 100s of people for a decade. We have CRC on links, = we have >> apps that use TCP and UDP checksums. Nuf said. >>=20 >>>>=20 >>>> -- Nits/Editorial Comments -- >>>>=20 >>>> - Top of p.4: >>>>=20 >>>> The initial motivation in the LISP effort is to be find in the >>>>=20 >>>> "find" -> "found" >>>>=20 >>>> - Section 3.1, first bullet item >>=20 >> We will certainly fixe these. Thanks. >>=20 >>>>=20 >>>> Devices are assigned with relatively opaque identity >>>> meaningful addresses that are independent of their topological >>>> location. >>>>=20 >>>> I don't understand "relatively opaque identity meaningful" and >>>> suggest rewriting the sentence. In particular - opaque to what? >>>> meaningful to what in what manner? >>=20 >> Well beacuse it is as accurate as it can be. If automobiles are going = to be >> assigned EIDs from a VIN number allocation from a manufacture, the = address is >> relatively opaque. If a VM in a data-center is going to be assigned = an EID >> from the set of prefixes already being used and allocated to that = data-center, >> then there is a good chance that address is in a power-of-2 block = that is >> summarizable in the IGP. >>=20 >>>>=20 >>>> - Section 3.2, second paragraph >>>>=20 >>>> Judging from the figure, xTRs are the common case, with single- >>>> function ITRs and ETRs being rare. It might be good to say that >>>> and discuss when ITRs and ETRs that are not xTRs are appropriate >>>> to use. >>=20 >> When you want egress path selection to happen further out in the = toplogical >> from the source location, then you put an ITR-only system there. = Where ingress >> to the same source (destination in this direction), the ETR can be = closer to >> the destination. >>=20 >>>>=20 >>>> - 3rd paragraph on p.7: >>>>=20 >>>>=20 >>>> Finally, the LISP architecture emphasizes a cost effective >>>> incremental deployment. >>>>=20 >>>> I'd delete "cost effective" here and look for other occurrences >>>> of "cost" as candidates for deletion. This is supposed to be >>>> a technical document, so discussion of costs is a bit off-target. >>=20 >> Fair enough. >>=20 >>>> - First item after Figure 2: >>>>=20 >>>> 1. HostA retrieves the EID_B of HostB, typically querying the = DNS >>>> and obtaining and A or AAAA record. >>>>=20 >>>> "and A" -> "an A" (spelling checkers don't catch everything). >>=20 >> Already noted and will be fixed. >>=20 >>>>=20 >>>> - 3.3.1. LISP Encapsulation >>>>=20 >>>> On the other hand, Recursive >>>> tunnels are nested tunnels and are implemented by using multiple = LISP >>>> encapsulations on a packet. >>>>=20 >>>> The above sentence seems out of place in the middle of a paragraph = about >>>> Re-encapsulating tunnels and routers - I suggest moving it down = into its >>>> own paragraph and perhaps adding a sentence about where/how = Recursive >>>> tunnels may be useful. >>=20 >> Good suggestion and makes sense. >>=20 >>>> - 3.3.2. LISP Forwarding State >>>>=20 >>>> In the LISP architecture, ITRs keep just enough information to = route >>>> traffic flowing through it. >>>>=20 >>>> "it." -> "them." >>>>=20 >>>> Meaning that, ITRs retrieve from the >>>> LISP Mapping System mappings between EID prefixes and RLOCs that = are >>>> used to encapsulate packets. >>>>=20 >>>> This is the first use of the notion of EID prefixes. That concept = should >>>> be explained before it is used, although a forward reference to = section >>>> 3.4.1 may suffice. It might be better to rewrite this paragraph in = terms >>>> of EIDs and leave the notion of EID prefixes to section 3.4.1. >>=20 >> Hmm, I'll let Albert and Damien decide if we should state = "EID-prefixes" >> everywhere instead of just "EID". >>=20 >>>>=20 >>>> - 4.4. MTU Handling >>>>=20 >>>> Additionally, LISP also recommends inferring reachability of = locators >>>> by using information provided by the underlay, in particular: >>>>=20 >>>> It'd be useful to add a sentence or two about how LISP and the = techniques >>>> in this section interact with host use of PMTUD and PLPMTUD. >>=20 >> This is a lot of detail because in RFC6830 we have 3 positions or = options on >> the subject. And we did provide a reference to RFC6830 for this = topic. >>=20 >>>> - Next to last paragraph on p.17: >>>>=20 >>>> Additionally, LISP also recommends inferring reachability of = locators >>>> by using information provided by the underlay, in particular: >>>>=20 >>>> This looks like it's a paragraph early and needs to be moved down = to >>>> after the paragraph that follows it. >>=20 >> Agree. >>=20 >>>> idnits 2.13.01 didn't find any nits. >>>>=20 >>>> Thanks, >>>> --David >>=20 >> Thanks again David. >>=20 >> Dino >=20 From nobody Thu Feb 12 00:24:02 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A971A1BA9 for ; Thu, 12 Feb 2015 00:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMWAbwksxxLa for ; Thu, 12 Feb 2015 00:23:59 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 A9D9F1A03E3 for ; Thu, 12 Feb 2015 00:23:59 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id l15so2226788wiw.5 for ; Thu, 12 Feb 2015 00:23:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6/QIH69zcTm/KF0B48Fme2THI9csc3cJsQktaaWagPs=; b=J5oyDk7Wfuv4Z+PbP2SKU14jlCbVQ/o10RDDi48M+HnPCD6l2jnNHiAGiqc1uMaYAP cTPTrFmhFtds2TdZPKVoRtBCLYG5T6ol97aAkhkmFHMtghsipc+GSme+i00IFwVgENNK kfgXxB6PqcNqWX2/H1c1OJgS6z1F451H/FNwaaJ6+UCqF6sOL0Oji12XSuuf/gGiS48O BZ5fAruDSZGBP8yyPOqhUymNehHVr/jilpGDheWr8ph+nFsWBCU/VCQCGDRTDnHtGkTW z4AuIwDZRxbv+yEOQFoPdf4z0CdMmKEQB1PWkt5s2vT/Po+kI7a3GJElbO2w57kaxuC9 ew/w== X-Gm-Message-State: ALoCoQmjyGT6CTaEkAgRFWdgBLoy7XFp6aq2uTF712fP8Oc9njvLGR0lmiBGk5zQ6NtiWj3D+fIm X-Received: by 10.180.198.74 with SMTP id ja10mr3940580wic.52.1423729438279; Thu, 12 Feb 2015 00:23:58 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:d183:b125:16a1:f065? ([2001:660:330f:a4:d183:b125:16a1:f065]) by mx.google.com with ESMTPSA id k6sm1497508wia.6.2015.02.12.00.23.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 00:23:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Thu, 12 Feb 2015 09:23:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7317886D-8A3B-4C79-8F82-1A961FCE7A46@gigix.net> References: <54DA982D.60200@joelhalpern.com> To: Dino Farinacci X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 08:24:01 -0000 > On 12 Feb 2015, at 05:39, Dino Farinacci wrote: >=20 [snip] >=20 >> So it makes perfect sense to register multicast addresses to the = mapping >>> system as EIDs and they can map to RLOCs of sites that have joined = the group. >>=20 >> As part of this, I strongly recommend moving away from use of "G" to = refer to >> multicast groups in both the overlay and underlay. Careful use of = G-EID >> and G-RLOC would significantly improve clarity. >=20 > Well we have not used G-EID in any documentation. And since we want to = encourage the use of SSM in the underlay and how we signal in the = overlay, we simply call the "eid" the 2-tuple (S,G). I second DIno on this point. In the evolution of this document one discussion point was about the = terminology to use.=20 The final choice was to avoid to introduce any terminology not used in = the current set of RFCs. Introducing =E2=80=9CG-EID=E2=80=9D and "G-RLOC=E2=80=9D would go = against that decision (and confuse the reader since it will never agin = find such terms). What if we drop the dashes? =20 G-EID =3D> the EID multicast group G=20 G-RLOC =3D> the RLOC multicast group G Yes bit prolix! Could this work? Luigi= From nobody Thu Feb 12 00:29:10 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC991A1BED for ; Thu, 12 Feb 2015 00:29:03 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25QkOedMrHFl for ; Thu, 12 Feb 2015 00:28:54 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 7455B1A03E3 for ; Thu, 12 Feb 2015 00:28:53 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so2314841wiv.2 for ; Thu, 12 Feb 2015 00:28:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=oZSNFZkFRLevC65MytmnHxXuPG/3FJubVOS0/Lt+bW0=; b=aKjD8AZiVFMoWFLCCL3dfskhVsDqGNuTYT2mwpmXoNgCHSKvOn+OLIAfoJZ7ZOVqAc FAlTJISPpNlLPbVpfeSMfMq2DJpOL9u18vlH7q1WnCyYJMCVwuKWne7q/RlfAEtBpLb3 geraNneyKKUFpc4HIfixFYgbUqFLfLkryn6E+FAVc8/gPTe/C3NY+ggy9qU/0qW1Btxc 1r0H8IjQ9Miv5/YVpzllZrvZjdB2ZEmG2DfyJMd54qM+2HUz/oYml0plV63E0GiGNJ0p 3Mar/D7YsIE1UoxyuKE/dkNHzes2KeNbo+caOJXgu2tRhjK7Z1Do13kX16WSHHYAZw1D +gBw== X-Gm-Message-State: ALoCoQkk5Ir52egCJIWQxOt7+7MrMXCCu1ojsJNu+8EUhKM00FkoS+m6WF/HljskBPCUIj3xMDFY X-Received: by 10.180.92.199 with SMTP id co7mr3687807wib.47.1423729732118; Thu, 12 Feb 2015 00:28:52 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:d183:b125:16a1:f065? ([2001:660:330f:a4:d183:b125:16a1:f065]) by mx.google.com with ESMTPSA id m4sm4639253wjb.25.2015.02.12.00.28.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 00:28:50 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FF201527-D975-4E24-AF6F-51C34073DA7D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Thu, 12 Feb 2015 09:28:51 +0100 Message-Id: <1A8253CB-7E12-4949-BBAB-45BD6DF2F496@gigix.net> References: To: "Jmh.direct" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ops-dir@ietf.org, ietf@ietf.org, david.black@emc.com, Damien Saucez , lisp@ietf.org Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 08:29:03 -0000 --Apple-Mail=_FF201527-D975-4E24-AF6F-51C34073DA7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Aren=E2=80=99t we going into to much details for the intro document? What if we change the sentence in the following way: OLD (suggested by David) "in the specific case of a VM/mobile node the EID-prefix should be /32 = or /128 (IPv4 or IPv6 respectively)=E2=80=9D NEW "In the mobility case the EID-prefix can be as small as a full /32 or = /128 (IPv4 or IPv6 respectively) depending on the mobility use-case = (e.g., subnet mobility vs single VM/Mobile node mobility)" Opinions? > On 12 Feb 2015, at 02:59, Jmh.direct = wrote: >=20 > Temeber that an EID prefix represents a site. A tenant network in a = data center is a viable site. So the prefix as registered for that. = Mobiluty of VMs with the tenant network can be handled internally. >=20 > Ypu could instead advertise each VM EID. Tge fact that both cased = work makes doing an introductory description a bit tricky. >=20 > Yours, > Joel >=20 >=20 > Sent from my Samsung smartphone on AT&T >=20 >=20 >=20 > -------- Original message -------- > Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11=20= > From: "Black, David" =20 > To: "Jmh.direct" ,"acabello@ac.upc.edu" = =20 > CC: "farinacci@gmail.com" ,"jmh@joelhalpern.com" = ,"damien.saucez@inria.fr" = ,"ops-dir@ietf.org" = ,"ietf@ietf.org" ,"lisp@ietf.org" = ,"Black, David" =20 >=20 >=20 > > In the VM case, am entire service network may be moved to the data = center, and so the EID block for that set can be moved. =20 >=20 > =20 >=20 > For a single VM, that would apply if the VM is using an entire EID = block - most individual VMs aren=E2=80=99t/don=E2=80=99t. Individual = /32 and /128 addresses are common for individual VMs, so that=E2=80=99s = what=E2=80=99s needed in general for individual VM movement. >=20 > =20 >=20 > I=E2=80=99d expect the EID block move case to apply for movement of a = group of VMs that are using such a block (e.g., as a subnet), but VM = live migrations cannot be synchronized in general (cold migrations of = powered-off VMs can be, obviously), so even in this case where the = entire EID block moves, if live VM migrations are involved, there are = intermediate stages where the EID block is split between LISP sites ... = and hence /32 and /128 prefixes are still what=E2=80=99s wanted. >=20 > =20 >=20 > Thanks, > --David >=20 > =20 >=20 > From: Jmh.direct [mailto:jmh.direct@joelhalpern.com]=20 > Sent: Wednesday, February 11, 2015 7:19 PM > To: Black, David; acabello@ac.upc.edu > Cc: farinacci@gmail.com; jmh@joelhalpern.com; damien.saucez@inria.fr; = ops-dir@ietf.org; ietf@ietf.org; lisp@ietf.org > Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 > Importance: Low >=20 > =20 >=20 > I thinl we may want to separate VM mobility from mobile devices. Om = the VM case, am entire setvice network may be moved to the data center, = and so the EID block for that set can be moved. In the case of = individually mobile debices or some vatiations on data center mobility, = there is a need to mske sure the full EID is advertised in the mapping = system. >=20 > =20 >=20 > Yours, >=20 > Joel >=20 >=20 >=20 > Sent from my Samsung smartphone on AT&T >=20 >=20 >=20 >=20 > -------- Original message -------- > Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11=20= > From: "Black, David" >=20 > To: "acabello@ac.upc.edu " = >=20 > CC: Dino Farinacci >,"Joel M. Halpern" >,Damien Saucez >,"ops-dir@ietf.org = " >,"ietf@ietf.org " = >,"lisp@ietf.org = " >,"Black, = David" >=20 >=20 >=20 > Hi Albert, >=20 > =20 >=20 > As noted below, on the EID prefix for mobility issue, a simple = statement in Section 5 to the effect that =E2=80=9Cin the specific case = of a VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IPv6 = respectively)=E2=80=9D will suffice. Details on what to do when that = advice is ignored can be left to other documents. >=20 > =20 >=20 > Thanks, > --David >=20 > =20 >=20 > From: Albert Cabellos [mailto:albert.cabellos@gmail.com = ]=20 > Sent: Wednesday, February 11, 2015 6:33 PM > To: Black, David > Cc: Dino Farinacci; Joel M. Halpern; Damien Saucez; ops-dir@ietf.org = ; ietf@ietf.org ; = lisp@ietf.org > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >=20 > =20 >=20 > Hi David >=20 > =20 >=20 > Thanks for your comments, I am parsing them and I=C2=B4ll suggest new = text aiming to address them ASAP. >=20 > =20 >=20 > I would also like to better understand [A] before doing this. >=20 > =20 >=20 > With LISP an EID-preifx can have an arbitrary length and can move = (i.e., change its RLOC bindings), in the specific case of a VM/mobile = node the EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively). = What doesn't work is the mobility of a node (assigned with a /32 or = /128) *within* a coarser EID-prefix, in this case you need to split the = prefix into more specifics and register them independently in the = Mapping System, effectively creating new EID-prefixes. >=20 > =20 >=20 > Please let me know if this clarifies your comment, in this case I will = suggest new text for Section 5. >=20 > =20 >=20 > Albert >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Thu, Feb 12, 2015 at 12:07 AM, Black, David > wrote: >=20 > Dino - thanks for the response. >=20 > On the major issues, it looks like both [A] and [B] involve only the = text > in this draft and nothing beyond, which is good news. I have a simple = text > suggestion for [A], but it looks like [B] is going to require some = careful > editing, as one of the primary causes is that the draft is sloppy in = using > the same symbol "G" to represent both EID and RLOC multicast groups. >=20 > On the minor issues, I have text suggestions for three of the four, = and > I'd like to temporarily defer further discussion the IPv6 UDP zero > checksum "tarpit" in favor of resolving everything else first. >=20 > On the nits/editorial comments, all the suggestions in your email are = fine > with me. FWIW, I regard that portion of a review as almost entirely > subject to the draft authors' discretion (and editorial taste). >=20 > > >> [A] EID mobility vs. EID prefixes > > > > ... from the start of the LISP design (circa 2007), an prefix is = what moves. > > And a specific EID is simply a /32 or /128 prefix. Here is a = practical > > example: >=20 > A statement that the mobility use cases need to employ /32 and /128 = prefixes, > and not anything coarser should suffice. That should be added to = Section 5. >=20 > > >> [B] LISP Multicast vs. EID/RLOC separate > > >> > > >> - 6. Multicast > > >> > > >> This is interesting, multicast addresses (G) look like they're an = exception > > > > They are really not. >=20 > My concern is that as I read the draft, it leaves me with the strong = impression > that the same multicast addresses (G) are being used in both the = overlay > (as EIDs) and the underlay (as RLOCs). =46rom your response, I = conclude that this > is not the case (and I have no argument with that). Rather, Section 6 = needs to > bluntly state that multicast addresses are mapped between EID and RLOC = space at > both ITRs and ETRs, so that the following inference is obvious from = the text > (it's currently not obvious): >=20 > > So it makes perfect sense to register multicast addresses to the = mapping > > system as EIDs and they can map to RLOCs of sites that have joined = the group. >=20 > As part of this, I strongly recommend moving away from use of "G" to = refer to > multicast groups in both the overlay and underlay. Careful use of = G-EID > and G-RLOC would significantly improve clarity. >=20 > --- > If the above are done for [A] and [B] in Sections 5 and 6, then the = text for the > use cases in Section 7 should not need further attention. > --- >=20 > > >> -- Minor Issues -- > > >> > > >> There seems to be an implicit assumption that the end host and = its > > >> ITR (xTR) are in the same domain or Autonomous System. For = incremental > > > > This is true when you call the domain a "LISP site". But if the site = is > > unchanged and one uses PITRs, maybe even close to the site, like in = a PE > > router, then the PITR is definitely in another AS. >=20 > Looking at the text, it seems that "LISP site" and "domain" are the = same > concept for this draft. That would be useful to state, IMHO but I'll = leave > the decision on whether to do so to you and the draft authors. >=20 > On rereading, my concerns seem to be triggered mostly by this sentence = in > Section 3.2: >=20 > The edge consists of LISP sites (e.g., an > Autonomous System) that use EID addresses. >=20 > I think a small change to the last sentence in that paragraph would = resolve > my concern without distracting from the narrative: >=20 > OLD > EIDs do not > contain inter-domain topological information and because of this, > EIDs are usually routable at the edge (within LISP sites) or in the > non-LISP Internet. > NEW > EIDs do not > contain inter-domain topological information and because of this, > EIDs are usually routable at the edge (within LISP sites) or in the > non-LISP Internet; see Section 3.5 for discussion of LISP site > internetworking with non-LISP sites and domains in the Internet. >=20 > > >> Despite multiple mentions of incremental deployment, I did not > > >> see a discussion of how that might be accomplished. > > > > There are PxTRs and NATs. And references to the LISP interworking = RFC. >=20 > Ok, can we just say so in Section 3.5? Adding the following sentence > to the end of the section would suffice: >=20 > PITRs, PETRs and LISP-NAT support incremental deployment of LISP > by providing significant flexibility in location of the boundaries > between the LISP and non-LISP portions of the network, and making > it reasonable to change those boundaries over time. >=20 > > >> - 3.3.1. LISP Encapsulation > > >> > > >> the source port is selected by > > >> the ITR and ignored on reception. > > >> > > >> Please mention multipathing (e.g., ECMP and LAG) as possible = influences > > >> on how source ports are selected, as this imposes some limits on = what an > > >> ITR can reasonably do. > > > > ECMP/LAG don't influence which source port is selected. It is a = 5-tuple hash > > of the inner header that selects a source port that influences how = an underlay > > router would load-split traffic. >=20 > Please state that a 5-tuple hash is used. ECMP/LAG is among the = important > reasons why, but that doesn't need to be stated if you prefer not to. = An > example of something that needs to be excluded is that using a random > number generator to set the source port would be wrong - I could = suggest > citing draft-ietf-dart-dscp-rtp for related discussion (and lots more > details), but I don't think that's necessary. >=20 > -- IPv6 zero UDP checksum >=20 > > My head spins every time I hear about this subject. This subject has = been > > talked about from 100s of people for a decade. We have CRC on links, = we have > > apps that use TCP and UDP checksums. Nuf said. >=20 > Understood - there's more than one set of scars on this one :-(. = Let's come back > to this topic after we've resolved everything else, and please keep in = mind > that I tagged this as a minor issue, not a major one (e.g., the above = changes > for [A] and [B] are far more important, IMHO). >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Dino Farinacci [mailto:farinacci@gmail.com = ] > > Sent: Wednesday, February 11, 2015 2:19 PM > > To: Joel M. Halpern > > Cc: Black, David; Albert Cabellos; Damien Saucez; ops-dir@ietf.org = ; > > ietf@ietf.org ; lisp@ietf.org = > > Subject: Re: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11 > > >=20 > > > I will leave most of these for the authors to comment on. > > > > See my comments inline. Thanks David for your detailed review and = commentary. > > > > > With regard to your question about incremental deployment, that is = the > > domain of the LISP Deployment document, and was deliberately only = lightly > > covered here. I am not sure what we can do to address your comment = without > > duplicating the entirety of that document. > > > > That is the risk we may have with many of your comments. We have a = lot of > > detail in the already 9 published RFCs and this document really is = to take > > all that detail and summarize as an easily understandable = description of a > > cohesive design. > > > > > With regard to UDP Zero, this was approved by the IESG and = published as an > > RFC. It is part of the way the protocol is defined. If there are = specific > > changes you would like to see in the explanatory text, I am sure > > > > Definitely agreed. In fact we instigated UDP zero. And I continually = talk to > > hardware engineers and they all believe we made the right decision. = So hats > > off to the IETF for being practical. > > > > > we could include them. If you are looking for a change in the = behavior, > > this document can not make changes to the LISP behavior. > > > > Yes, an important point. > > > > >> I found a couple of major issues that I hope arise from the > > >> summarization of LISP in this draft, as opposed to being problems = in > > >> the actual LISP protocols. I also found a few minor issues, the = most > > >> important of which is the need for additional security = considerations > > >> discussion on misdelivery, with particular attention to VPNs. > > > > Thanks a ton. > > > > >> -- Major issues -- > > >> > > >> [A] EID mobility vs. EID prefixes > > >> > > >> - 5. Mobility > > >> > > >> I understand how this works when mapping is per-EID, but how does = this work > > >> when the EID of the system that moves is part of an EID prefix, = as > > discussed > > >> in Section 3.4.1? Even if the answer is a long version of "Don't = do that!" > > >> it should be explained. > > > > No, from the start of the LISP design (circa 2007), an prefix is = what moves. > > And a specific EID is simply a /32 or /128 prefix. Here is a = practical > > example: > > > > You have a cluster of servers that communicate together for a = particular > > application. They application cluster is running in a set of VMs. = Those VMs > > are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are = currently > > running in a brick-and-mortar data center. Now there is a desire to = move the > > VM cluster to a cloud provider. What is moved is the EID-prefix of = the > > cluster. The mapping system is told that the EID-prefix is changing = its RLOC- > > set from the brick-and-mortar xTRs to the cloud providers xTRs. > > > > >> > > >> - 7.4. LISP for Virtual Machine Mobility in Data Centers > > >> > > >> I don't understand how this works when EID prefixes are used, as = each VM > > >> has its own EID or EIDs, hence the entire prefix range does not = move when > > >> the VM moves. > > >> > > >> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in = Appendix A > > >> of RFC 5706: Has deployment been discussed? and specifically = under: > > >> > > >> * Is the proposed specification deployable? If not, how = could > > >> it be improved? > > >> > > >> as EID prefixes appear to be undeployable for Mobility and VM = Mobility > > usage. > > > > See above example. > > > > >> [B] LISP Multicast vs. EID/RLOC separate > > >> > > >> - 6. Multicast > > >> > > >> This is interesting, multicast addresses (G) look like they're an = exception > > > > They are really not. Since multicast addresses *identify* a group of > > receivers, it is very much an EID and aheres to the definition of an = EID. > > Multicast addresses never had topological signficance but the state > > representing a distribution tree does tell you were the members are = (but the > > identity of the members are not know in multicast). > > > > So it makes perfect sense to register multicast addresses to the = mapping > > system as EIDs and they can map to RLOCs of sites that have joined = the group. > > See draft-farinacci-signal-free-multicast as just one example. = RFC6831 and > > draft-farinacci-lisp-mr-signaling are other examples. > > > > >> to the EID/RLOC separation as the same destination IP multicast = address > > >> is used for both purposes. This could use some more discussion, = as it's > > >> unexpected based on the contents of the draft up to this point. > > > > I believe the level of detail we have in the introduction document = is at the > > right level or we'll err on having way too many details crop in. > > > > >> - 7.2. LISP for IPv6 Co-existence > > >> > > >> LISP encapsulations allows to transport packets using EIDs = from a > > >> given address family (e.g., IPv6) with packets from other = address > > >> families (e.g., IPv4). > > >> > > >> How does that work for multicast traffic, where the destination = address > > >> (G) has to be the same in both the inner and outer headers? Are = ETRs > > >> and ITRs expected to map IPv6 multicast addresses to IPv4 and = v.v.? > > > > The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a = RLOC set > > that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR = that > > receives the packet from S-EID-ipv6 would replicate the packet and = multicast > > encapsulate to ipv4-multicast and unicast encapsualte to = ipv4-unicast. > > > > >> - 7.3. LISP for Virtual Private Networks > > >> > > >> This also has multicast problems, as there is only one instance = of each > > >> multicast address (G) in the underlay network. I think I can = figure out > > how > > > > You can map from EID-G to RLOC-G one to one. But we have seen over = the last > > decade in a half that with general multicast deployment that = many-to-1 is > > desirable. Hence, now that we have a way to map with a network-based = database, > > we can map multiple EID-Gs to a single (or multiple) RLOC-Gs. > > > > >> to make multicast work for this use case, but it's not = immediately obvious, > > >> and the result when the same underlay multicast address is used = by more > > >> than one VPN could well deliver some traffic to ETRs that have to = discard > > > > This is a necessary evil when the underlay is state challenged. But = it is a > > state/bandwidth tradeoff. We have found with MVPN deployment that = the network > > admin configures the underly or simply unicasts. > > > > >> it because the Instance ID is wrong (and that excessive delivery = is a > > >> security consideration, see minor issue on Section 8 below). I = think an > > >> explanation is in order. > > > > There are just too many combinations to make a high-level = description simple > > to understand. The current introduction text does a find job = providing > > references for someone to go off and get the details. > > > > >> -- Minor Issues -- > > >> > > >> There seems to be an implicit assumption that the end host and = its > > >> ITR (xTR) are in the same domain or Autonomous System. For = incremental > > > > This is true when you call the domain a "LISP site". But if the site = is > > unchanged and one uses PITRs, maybe even close to the site, like in = a PE > > router, then the PITR is definitely in another AS. But note I said = PITR and > > not ITR. The reason being is because an ITR is configured with = database- > > mapping prefixes that is uses to encapsulate packets from such = addresses. > > Versus the PITR being an ITR with *no database-mappings* providing a = much more > > larger/or more aggregtable service. > > > > >> deployment, I don't think that's always the case, but I think = that only > > >> has editorial impact on this document, as I don't think any of = the > > >> fundamental LISP mechanisms are affected. The authors should = look for > > >> use of "domain" and "Autonomous System" and ensure that the text = is > > >> generalized to the case where the end host and ITR are more = widely > > >> separated. > > > > We are overloaded with terms that create topological or organization = boundary. > > Hence why we created "LISP site" which is also the same as a "LISP = VPN site". > > Where a "LISP site" that has multiple tennants would be multiple = "LISP VPN > > sites". > > > > >> Despite multiple mentions of incremental deployment, I did not > > >> see a discussion of how that might be accomplished. There is = some > > > > There are PxTRs and NATs. And references to the LISP interworking = RFC. > > > > >> useful content in Section 3.5, but that's at best an incomplete > > >> explanation. This is an OPS-Dir review concern - it falls under > > >> A.1.3 in Appendix A of RFC 5706: Has the migration path been = discussed? > > >> > > >> - 3.3.1. LISP Encapsulation > > >> > > >> the source port is selected by > > >> the ITR and ignored on reception. > > >> > > >> Please mention multipathing (e.g., ECMP and LAG) as possible = influences > > >> on how source ports are selected, as this imposes some limits on = what an > > >> ITR can reasonably do. > > > > ECMP/LAG don't influence which source port is selected. It is a = 5-tuple hash > > of the inner header that selects a source port that influences how = an underlay > > router would load-split traffic. > > > > >> For OPS-Dir, this multipathing concern falls under A.1.4 in = Appendix A of > > >> RFC 5706: Have the Requirements on other protocols and functional > > >> components been discussed? > > >> > > >> This decision was made because the > > >> typical transport protocols used by the applications already = include > > >> a checksum, by neglecting the additional UDP encapsulation = checksum > > >> xTRs can forward packets more efficiently. > > >> > > >> Groan! I have an exquisite set of scars on UDP zero checksums = for IPv6 > > >> from working on the MPLS in UDP draft, so I may be overly = sensitive to > > >> this concern. The downside of this efficiency is that there is = no > > >> checksum coverage of the IPv6 header when zero UDP checksums are = used. > > >> That should at least be mentioned here, with a summary of why = that's ok > > >> - the detailed justification for why that's ok can be left to = other > > >> documents. > > > > My head spins every time I hear about this subject. This subject has = been > > talked about from 100s of people for a decade. We have CRC on links, = we have > > apps that use TCP and UDP checksums. Nuf said. > > > > >> > > >> -- Nits/Editorial Comments -- > > >> > > >> - Top of p.4: > > >> > > >> The initial motivation in the LISP effort is to be find in the > > >> > > >> "find" -> "found" > > >> > > >> - Section 3.1, first bullet item > > > > We will certainly fixe these. Thanks. > > > > >> > > >> Devices are assigned with relatively opaque identity > > >> meaningful addresses that are independent of their = topological > > >> location. > > >> > > >> I don't understand "relatively opaque identity meaningful" and > > >> suggest rewriting the sentence. In particular - opaque to what? > > >> meaningful to what in what manner? > > > > Well beacuse it is as accurate as it can be. If automobiles are = going to be > > assigned EIDs from a VIN number allocation from a manufacture, the = address is > > relatively opaque. If a VM in a data-center is going to be assigned = an EID > > from the set of prefixes already being used and allocated to that = data-center, > > then there is a good chance that address is in a power-of-2 block = that is > > summarizable in the IGP. > > > > >> > > >> - Section 3.2, second paragraph > > >> > > >> Judging from the figure, xTRs are the common case, with single- > > >> function ITRs and ETRs being rare. It might be good to say that > > >> and discuss when ITRs and ETRs that are not xTRs are appropriate > > >> to use. > > > > When you want egress path selection to happen further out in the = toplogical > > from the source location, then you put an ITR-only system there. = Where ingress > > to the same source (destination in this direction), the ETR can be = closer to > > the destination. > > > > >> > > >> - 3rd paragraph on p.7: > > >> > > >> > > >> Finally, the LISP architecture emphasizes a cost effective > > >> incremental deployment. > > >> > > >> I'd delete "cost effective" here and look for other occurrences > > >> of "cost" as candidates for deletion. This is supposed to be > > >> a technical document, so discussion of costs is a bit off-target. > > > > Fair enough. > > > > >> - First item after Figure 2: > > >> > > >> 1. HostA retrieves the EID_B of HostB, typically querying the = DNS > > >> and obtaining and A or AAAA record. > > >> > > >> "and A" -> "an A" (spelling checkers don't catch everything). > > > > Already noted and will be fixed. > > > > >> > > >> - 3.3.1. LISP Encapsulation > > >> > > >> On the other hand, Recursive > > >> tunnels are nested tunnels and are implemented by using = multiple LISP > > >> encapsulations on a packet. > > >> > > >> The above sentence seems out of place in the middle of a = paragraph about > > >> Re-encapsulating tunnels and routers - I suggest moving it down = into its > > >> own paragraph and perhaps adding a sentence about where/how = Recursive > > >> tunnels may be useful. > > > > Good suggestion and makes sense. > > > > >> - 3.3.2. LISP Forwarding State > > >> > > >> In the LISP architecture, ITRs keep just enough information to = route > > >> traffic flowing through it. > > >> > > >> "it." -> "them." > > >> > > >> Meaning that, ITRs retrieve from the > > >> LISP Mapping System mappings between EID prefixes and RLOCs = that are > > >> used to encapsulate packets. > > >> > > >> This is the first use of the notion of EID prefixes. That = concept should > > >> be explained before it is used, although a forward reference to = section > > >> 3.4.1 may suffice. It might be better to rewrite this paragraph = in terms > > >> of EIDs and leave the notion of EID prefixes to section 3.4.1. > > > > Hmm, I'll let Albert and Damien decide if we should state = "EID-prefixes" > > everywhere instead of just "EID". > > > > >> > > >> - 4.4. MTU Handling > > >> > > >> Additionally, LISP also recommends inferring reachability of = locators > > >> by using information provided by the underlay, in particular: > > >> > > >> It'd be useful to add a sentence or two about how LISP and the = techniques > > >> in this section interact with host use of PMTUD and PLPMTUD. > > > > This is a lot of detail because in RFC6830 we have 3 positions or = options on > > the subject. And we did provide a reference to RFC6830 for this = topic. > > > > >> - Next to last paragraph on p.17: > > >> > > >> Additionally, LISP also recommends inferring reachability of = locators > > >> by using information provided by the underlay, in particular: > > >> > > >> This looks like it's a paragraph early and needs to be moved down = to > > >> after the paragraph that follows it. > > > > Agree. > > > > >> idnits 2.13.01 didn't find any nits. > > >> > > >> Thanks, > > >> --David > > > > Thanks again David. > > > > Dino >=20 > =20 >=20 --Apple-Mail=_FF201527-D975-4E24-AF6F-51C34073DA7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Aren=E2=80=99t we going into to much details for the intro = document?

What = if we change the sentence in the following way:

OLD (suggested by David)

"in the specific case of = a VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IPv6 = respectively)=E2=80=9D

NEW

"In the mobility case the EID-prefix can be as small as a = full /32 or /128 (IPv4 or IPv6 respectively) depending on the mobility = use-case (e.g., subnet mobility vs single VM/Mobile node = mobility)"


Opinions?


On 12 Feb 2015, at 02:59, = Jmh.direct <jmh.direct@joelhalpern.com> wrote:

Temeber that an EID prefix represents a site. =  A tenant network in a data center is a viable site.  So the = prefix as registered for that.  Mobiluty of VMs with the tenant = network can be handled internally.

Ypu could instead advertise each VM = EID.  Tge fact that both cased work makes doing an introductory = description a bit tricky.

Yours,
Joel


Sent = from my Samsung smartphone on AT&T



-------- Original message --------
Subject: RE: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11
From: "Black, David" = <david.black@emc.com>
To: "Jmh.direct" = <jmh.direct@joelhalpern.com>,"acabello@ac.upc.edu" = <acabello@ac.upc.edu>
CC: "farinacci@gmail.com" = <farinacci@gmail.com>,"jmh@joelhalpern.com" = <jmh@joelhalpern.com>,"damien.saucez@inria.fr" <damien.saucez@inria.fr>,"ops-dir@ietf.org" <ops-dir@ietf.org>,"ietf@ietf.org" <ietf@ietf.org>,"lisp@ietf.org" <lisp@ietf.org>,"Black, = David" <david.black@emc.com>


> In the VM case, am entire service network may be moved to the = data center, and so the EID block for that set can be moved.  

 

For a = single VM, that would apply if the VM is using an entire EID block - = most individual VMs aren=E2=80=99t/don=E2=80=99t.  Individual /32 = and /128 addresses are common for individual VMs, so that=E2=80=99s what=E2=80=99s needed in general for individual = VM movement.

 

I=E2=80=99= d expect the EID block move case to apply for movement of a group of VMs = that are using such a block (e.g., as a subnet), but VM live migrations = cannot be synchronized in general (cold migrations of powered-off VMs can be, obviously), so = even in this case where the entire EID block moves, if live VM = migrations are involved, there are intermediate stages where the EID = block is split between LISP sites ... and hence /32 and /128 prefixes are still what=E2=80=99s wanted.

 

Thanks,
--David

 

From: Jmh.direct [mailto:jmh.direct@joelhalpern.com]
Sent: Wednesday, February 11, 2015 7:19 PM
To: Black, David; acabello@ac.upc.edu
Cc: farinacci@gmail.com; jmh@joelhalpern.com; damien.saucez@inria.fr; ops-dir@ietf.org; ietf@ietf.org; lisp@ietf.org
Subject: RE: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11
Importance: Low

 

I thinl we may want to separate VM mobility from = mobile devices.  Om the VM case, am entire setvice network may be = moved to the data center, and so the EID block for that set can be = moved.  In the case of individually mobile debices or some vatiations on data center mobility, there is a need to mske sure = the full EID is advertised in the mapping system.

 

Yours,

Joel



Sent from my Samsung = smartphone on AT&T




-------- Original message --------
Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 =
From: "Black, David" <david.black@emc.com>
To: "acabello@ac.upc.edu" <acabello@ac.upc.edu>=
CC: Dino Farinacci <farinacci@gmail.com>,"Joel M. Halpern" <jmh@joelhalpern.com>,Damien Saucez <damien.saucez@inria.fr>,"ops-dir@ietf.org" <ops-dir@ietf.org>,"ietf@ietf.org" <ietf@ietf.org>,"lisp@ietf.org" <lisp@ietf.org>,"Black, David" <david.black@emc.com>

Hi = Albert,

 

As = noted below, on the EID prefix for mobility issue, a simple statement in = Section 5 to the effect that =E2=80=9Cin the specific case of a VM/mobile node the EID-prefix should be /32 or = /128 (IPv4 or IPv6 respectively)=E2=80=9D will suffice.  Details on = what to do when that advice is ignored can be left to other = documents.

 

Thanks,
--David

 

From: Albert Cabellos [mailto:albert.cabellos@gmail.com]
Sent: Wednesday, February 11, 2015 6:33 PM
To: Black, David
Cc: Dino Farinacci; Joel M. Halpern; Damien Saucez; ops-dir@ietf.org; ietf@ietf.org; = lisp@ietf.org
Subject: Re: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11

 

Hi = David

 

Thanks for = your comments, I am parsing them and I=C2=B4ll suggest new text aiming = to address them ASAP.

 

I would = also like to better understand [A] before doing this.

 

With LISP = an EID-preifx can have an arbitrary length and can move (i.e., change = its RLOC bindings), in the specific case of a VM/mobile node the = EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively). What doesn't work is the mobility of a = node (assigned with a /32 or /128) *within* a coarser EID-prefix, in = this case you need to split the prefix into more specifics and register = them independently in the Mapping System, effectively creating new EID-prefixes.

 

Please let = me know if this clarifies your comment, in this case I will suggest new = text for Section 5.

 

Albert

 

 

 

On Thu, Feb = 12, 2015 at 12:07 AM, Black, David <david.black@emc.com> wrote:

Dino - = thanks for the response.

On the major issues, it looks like both [A] and [B] involve only the = text
in this draft and nothing beyond, which is good news.  I have a = simple text
suggestion for [A], but it looks like [B] is going to require some = careful
editing, as one of the primary causes is that the draft is sloppy in = using
the same symbol "G" to represent both EID and RLOC multicast groups.

On the minor issues, I have text suggestions for three of the four, = and
I'd like to temporarily defer further discussion the IPv6 UDP zero
checksum "tarpit" in favor of resolving everything else first.

On the nits/editorial comments, all the suggestions in your email are = fine
with me.  FWIW, I regard that portion of a review as almost = entirely
subject to the draft authors' discretion (and editorial taste).

> >> [A] EID mobility vs. EID prefixes
>
> ... from the start of the LISP design (circa 2007), an prefix is = what moves.
> And a specific EID is simply a /32 or /128 prefix. Here is a = practical
> example:

A statement that the mobility use cases need to employ /32 and /128 = prefixes,
and not anything coarser should suffice.  That should be added to = Section 5.

> >> [B] LISP Multicast vs. EID/RLOC separate
> >>
> >> - 6. Multicast
> >>
> >> This is interesting, multicast addresses (G) look like = they're an exception
>
> They are really not.

My concern is that as I read the draft, it leaves me with the strong = impression
that the same multicast addresses (G) are being used in both the = overlay
(as EIDs) and the underlay (as RLOCs).  =46rom your response, I = conclude that this
is not the case (and I have no argument with that).  Rather, = Section 6 needs to
bluntly state that multicast addresses are mapped between EID and RLOC = space at
both ITRs and ETRs, so that the following inference is obvious from the = text
(it's currently not obvious):

> So it makes perfect sense to register multicast addresses to the = mapping
> system as EIDs and they can map to RLOCs of sites that have joined = the group.

As part of this, I strongly recommend moving away from use of "G" to = refer to
multicast groups in both the overlay and underlay.  Careful use of = G-EID
and G-RLOC would significantly improve clarity.

---
If the above are done for [A] and [B] in Sections 5 and 6, then the text = for the
use cases in Section 7 should not need further attention.
---

> >> -- Minor Issues --
> >>
> >> There seems to be an implicit assumption that the end host = and its
> >> ITR (xTR) are in the same domain or Autonomous = System.  For incremental
>
> This is true when you call the domain a "LISP site". But if the = site is
> unchanged and one uses PITRs, maybe even close to the site, like in = a PE
> router, then the PITR is definitely in another AS.

Looking at the text, it seems that "LISP site" and "domain" are the = same
concept for this draft.  That would be useful to state, IMHO but = I'll leave
the decision on whether to do so to you and the draft authors.

On rereading, my concerns seem to be triggered mostly by this sentence = in
Section 3.2:

   The edge consists of LISP sites (e.g., an
   Autonomous System) that use EID addresses.

I think a small change to the last sentence in that paragraph would = resolve
my concern without distracting from the narrative:

OLD
   EIDs do not
   contain inter-domain topological information and because of = this,
   EIDs are usually routable at the edge (within LISP sites) = or in the
   non-LISP Internet.
NEW
   EIDs do not
   contain inter-domain topological information and because of = this,
   EIDs are usually routable at the edge (within LISP sites) = or in the
   non-LISP Internet; see Section 3.5 for discussion of LISP = site
   internetworking with non-LISP sites and domains in the = Internet.

> >> Despite multiple  mentions of incremental deployment, = I did not
> >> see a discussion of how that might be accomplished.
>
> There are PxTRs and NATs. And references to the LISP interworking = RFC.

Ok, can we just say so in Section 3.5?  Adding the following = sentence
to the end of the section would suffice:

   PITRs, PETRs and LISP-NAT support incremental deployment of = LISP
   by providing significant flexibility in location of the = boundaries
   between the LISP and non-LISP portions of the network, and = making
   it reasonable to change those boundaries over time.

> >> - 3.3.1.  LISP Encapsulation
> >>
> >>    the source port is selected by
> >>    the ITR and ignored on reception.
> >>
> >> Please mention multipathing (e.g., ECMP and LAG) as = possible influences
> >> on how source ports are selected, as this imposes some = limits on what an
> >> ITR can reasonably do.
>
> ECMP/LAG don't influence which source port is selected. It is a = 5-tuple hash
> of the inner header that selects a source port that influences how = an underlay
> router would load-split traffic.

Please state that a 5-tuple hash is used.  ECMP/LAG is among the = important
reasons why, but that doesn't need to be stated if you prefer not = to.  An
example of something that needs to be excluded is that using a random
number generator to set the source port would be wrong - I could = suggest
citing draft-ietf-dart-dscp-rtp for related discussion (and lots more
details), but I don't think that's necessary.

-- IPv6 zero UDP checksum

> My head spins every time I hear about this subject. This subject = has been
> talked about from 100s of people for a decade. We have CRC on = links, we have
> apps that use TCP and UDP checksums. Nuf said.

Understood - there's more than one set of scars on this one :-(.  = Let's come back
to this topic after we've resolved everything else, and please keep in = mind
that I tagged this as a minor issue, not a major one (e.g., the above = changes
for [A] and [B] are far more important, IMHO).

Thanks,
--David

> -----Original Message-----
> From: Dino Farinacci [mailto:farinacci@gmail.com]
> Sent: Wednesday, February 11, 2015 2:19 = PM
> To: Joel M. Halpern
> Cc: Black, David; Albert Cabellos; Damien = Saucez; ops-dir@ietf.org;
> ietf@ietf.org; = lisp@ietf.org
> Subject: Re: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11
>

> > I will = leave most of these for the authors to comment on.
>
> See my comments inline. Thanks David for your detailed review and = commentary.
>
> > With regard to your question about incremental deployment, = that is the
> domain of the LISP Deployment document, and was deliberately only = lightly
> covered here.  I am not sure what we can do to address your = comment without
> duplicating the entirety of that document.
>
> That is the risk we may have with many of your comments. We have a = lot of
> detail in the already 9 published RFCs  and this document = really is to take
> all that detail and summarize as an easily understandable = description of a
> cohesive design.
>
> > With regard to UDP Zero, this was approved by the IESG and = published as an
> RFC.  It is part of the way the protocol is defined.  If = there are specific
> changes you would like to see in the explanatory text, I am sure
>
> Definitely agreed. In fact we instigated UDP zero. And I = continually talk to
> hardware engineers and they all believe we made the right decision. = So hats
> off to the IETF for being practical.
>
> > we could include them.  If you are looking for a change = in the behavior,
> this document can not make changes to the LISP behavior.
>
> Yes, an important point.
>
> >> I found a couple of major issues that I hope arise from = the
> >> summarization of LISP in this draft, as opposed to being = problems in
> >> the actual LISP protocols.  I also found a few minor = issues, the most
> >> important of which is the need for additional security = considerations
> >> discussion on misdelivery, with particular attention to = VPNs.
>
> Thanks a ton.
>
> >> -- Major issues --
> >>
> >> [A] EID mobility vs. EID prefixes
> >>
> >> - 5. Mobility
> >>
> >> I understand how this works when mapping is per-EID, but = how does this work
> >> when the EID of the system that moves is part of an EID = prefix, as
> discussed
> >> in Section 3.4.1?  Even if the answer is a long = version of "Don't do that!"
> >> it should be explained.
>
> No, from the start of the LISP design (circa 2007), an prefix is = what moves.
> And a specific EID is simply a /32 or /128 prefix. Here is a = practical
> example:
>
> You have a cluster of servers that communicate together for a = particular
> application. They application cluster is running in a set of VMs. = Those VMs
> are assigned EIDs from a common power-of-2 EID-prefix. Those VMs = are currently
> running in a brick-and-mortar data center. Now there is a desire to = move the
> VM cluster to a cloud provider. What is moved is the EID-prefix of = the
> cluster. The mapping system is told that the EID-prefix is changing = its RLOC-
> set from the brick-and-mortar xTRs to the cloud providers xTRs.
>
> >>
> >> - 7.4.  LISP for Virtual Machine Mobility in Data = Centers
> >>
> >> I don't understand how this works when EID prefixes are = used, as each VM
> >> has its own EID or EIDs, hence the entire prefix range = does not move when
> >> the VM moves.
> >>
> >> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 = in Appendix A
> >> of RFC 5706:  Has deployment been discussed? and = specifically under:
> >>
> >>        *  Is the proposed = specification deployable?  If not, how could
> >>           it be improved?
> >>
> >> as EID prefixes appear to be undeployable for Mobility and = VM Mobility
> usage.
>
> See above example.
>
> >> [B] LISP Multicast vs. EID/RLOC separate
> >>
> >> - 6. Multicast
> >>
> >> This is interesting, multicast addresses (G) look like = they're an exception
>
> They are really not. Since multicast addresses *identify* a group = of
> receivers, it is very much an EID and aheres to the definition of = an EID.
> Multicast addresses never had topological signficance but the = state
> representing a distribution tree does tell you were the members are = (but the
> identity of the members are not know in multicast).
>
> So it makes perfect sense to register multicast addresses to the = mapping
> system as EIDs and they can map to RLOCs of sites that have joined = the group.
> See draft-farinacci-signal-free-multicast as just one example. = RFC6831 and
> draft-farinacci-lisp-mr-signaling are other examples.
>
> >> to the EID/RLOC separation as the same destination IP = multicast address
> >> is used for both purposes.  This could use some more = discussion, as it's
> >> unexpected based on the contents of the draft up to this = point.
>
> I believe the level of detail we have in the introduction document = is at the
> right level or we'll err on having way too many details crop in.
>
> >> - 7.2.  LISP for IPv6 Co-existence
> >>
> >>    LISP encapsulations allows to transport = packets using EIDs from a
> >>    given address family (e.g., IPv6) with = packets from other address
> >>    families (e.g., IPv4).
> >>
> >> How does that work for multicast traffic, where the = destination address
> >> (G) has to be the same in both the inner and outer = headers?  Are ETRs
> >> and ITRs expected to map IPv6 multicast addresses to IPv4 = and v.v.?
>
> The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a = RLOC set
> that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR = that
> receives the packet from S-EID-ipv6 would replicate the packet and = multicast
> encapsulate to ipv4-multicast and unicast encapsualte to = ipv4-unicast.
>
> >> - 7.3.  LISP for Virtual Private Networks
> >>
> >> This also has multicast problems, as there is only one = instance of each
> >> multicast address (G) in the underlay network.  I = think I can figure out
> how
>
> You can map from EID-G to RLOC-G one to one. But we have seen over = the last
> decade in a half that with general multicast deployment that = many-to-1 is
> desirable. Hence, now that we have a way to map with a = network-based database,
> we can map multiple EID-Gs to a single (or multiple) RLOC-Gs.
>
> >> to make multicast work for this use case, but it's not = immediately obvious,
> >> and the result when the same underlay multicast address is = used by more
> >> than one VPN could well deliver some traffic to ETRs that = have to discard
>
> This is a necessary evil when the underlay is state challenged. But = it is a
> state/bandwidth tradeoff. We have found with MVPN deployment that = the network
> admin configures the underly or simply unicasts.
>
> >> it because the Instance ID is wrong (and that excessive = delivery is a
> >> security consideration, see minor issue on Section 8 = below).  I think an
> >> explanation is in order.
>
> There are just too many combinations to make a high-level = description simple
> to understand. The current introduction text does a find job = providing
> references for someone to go off and get the details.
>
> >> -- Minor Issues --
> >>
> >> There seems to be an implicit assumption that the end host = and its
> >> ITR (xTR) are in the same domain or Autonomous = System.  For incremental
>
> This is true when you call the domain a "LISP site". But if the = site is
> unchanged and one uses PITRs, maybe even close to the site, like in = a PE
> router, then the PITR is definitely in another AS. But note I said = PITR and
> not ITR. The reason being is because an ITR is configured with = database-
> mapping prefixes that is uses to encapsulate packets from such = addresses.
> Versus the PITR being an ITR with *no database-mappings* providing = a much more
> larger/or more aggregtable service.
>
> >> deployment, I don't think that's always the case, but I = think that only
> >> has editorial impact on this document, as I don't think = any of the
> >> fundamental LISP mechanisms are affected.  The = authors should look for
> >> use of "domain" and "Autonomous System" and ensure that = the text is
> >> generalized to the case where the end host and ITR are = more widely
> >> separated.
>
> We are overloaded with terms that create topological or = organization boundary.
> Hence why we created "LISP site" which is also the same as a "LISP = VPN site".
> Where a "LISP site" that has multiple tennants would be multiple = "LISP VPN
> sites".
>
> >> Despite multiple  mentions of incremental deployment, = I did not
> >> see a discussion of how that might be accomplished.  = There is some
>
> There are PxTRs and NATs. And references to the LISP interworking = RFC.
>
> >> useful content in Section 3.5, but that's at best an = incomplete
> >> explanation.  This is an OPS-Dir review concern - it = falls under
> >> A.1.3 in Appendix A of RFC 5706: Has the migration path = been discussed?
> >>
> >> - 3.3.1.  LISP Encapsulation
> >>
> >>    the source port is selected by
> >>    the ITR and ignored on reception.
> >>
> >> Please mention multipathing (e.g., ECMP and LAG) as = possible influences
> >> on how source ports are selected, as this imposes some = limits on what an
> >> ITR can reasonably do.
>
> ECMP/LAG don't influence which source port is selected. It is a = 5-tuple hash
> of the inner header that selects a source port that influences how = an underlay
> router would load-split traffic.
>
> >> For OPS-Dir, this multipathing concern falls under A.1.4 = in Appendix A of
> >> RFC 5706: Have the Requirements on other protocols and = functional
> >>        components been discussed?
> >>
> >>    This decision was made because the
> >>    typical transport protocols used by the = applications already include
> >>    a checksum, by neglecting the additional UDP = encapsulation checksum
> >>    xTRs can forward packets more efficiently.
> >>
> >> Groan!  I have an exquisite set of scars on UDP zero = checksums for IPv6
> >> from working on the MPLS in UDP draft, so I may be overly = sensitive to
> >> this concern.  The downside of this efficiency is = that there is no
> >> checksum coverage of the IPv6 header when zero UDP = checksums are used.
> >> That should at least be mentioned here, with a summary of = why that's ok
> >> - the detailed justification for why that's ok can be left = to other
> >> documents.
>
> My head spins every time I hear about this subject. This subject = has been
> talked about from 100s of people for a decade. We have CRC on = links, we have
> apps that use TCP and UDP checksums. Nuf said.
>
> >>
> >> -- Nits/Editorial Comments --
> >>
> >> - Top of p.4:
> >>
> >>    The initial motivation in the LISP effort is = to be find in the
> >>
> >> "find" -> "found"
> >>
> >> - Section 3.1, first bullet item
>
> We will certainly fixe these. Thanks.
>
> >>
> >>       Devices are assigned with = relatively opaque identity
> >>       meaningful addresses that are = independent of their topological
> >>       location.
> >>
> >> I don't understand "relatively opaque identity meaningful" = and
> >> suggest rewriting the sentence.  In particular - = opaque to what?
> >> meaningful to what in what manner?
>
> Well beacuse it is as accurate as it can be. If automobiles are = going to be
> assigned EIDs from a VIN number allocation from a manufacture, the = address is
> relatively opaque. If a VM in a data-center is going to be assigned = an EID
> from the set of prefixes already being used and allocated to that = data-center,
> then there is a good chance that address is in a power-of-2 block = that is
> summarizable in the IGP.
>
> >>
> >> - Section 3.2, second paragraph
> >>
> >> Judging from the figure, xTRs are the common case, with = single-
> >> function ITRs and ETRs being rare.  It might be good = to say that
> >> and discuss when ITRs and ETRs that are not xTRs are = appropriate
> >> to use.
>
> When you want egress path selection to happen further out in the = toplogical
> from the source location, then you put an ITR-only system there. = Where ingress
> to the same source (destination in this direction), the ETR can be = closer to
> the destination.
>
> >>
> >> - 3rd paragraph on p.7:
> >>
> >>
> >>    Finally, the LISP architecture emphasizes a = cost effective
> >>    incremental deployment.
> >>
> >> I'd delete "cost effective" here and look for other = occurrences
> >> of "cost" as candidates for deletion.  This is = supposed to be
> >> a technical document, so discussion of costs is a bit = off-target.
>
> Fair enough.
>
> >> - First item after Figure 2:
> >>
> >>    1.  HostA retrieves the EID_B of HostB, = typically querying the DNS
> >>        and obtaining and A or AAAA = record.
> >>
> >> "and A" -> "an A"  (spelling checkers don't catch = everything).
>
> Already noted and will be fixed.
>
> >>
> >> - 3.3.1.  LISP Encapsulation
> >>
> >>    On the other hand, Recursive
> >>    tunnels are nested tunnels and are = implemented by using multiple LISP
> >>    encapsulations on a packet.
> >>
> >> The above sentence seems out of place in the middle of a = paragraph about
> >> Re-encapsulating tunnels and routers - I suggest moving it = down into its
> >> own paragraph and perhaps adding a sentence about = where/how Recursive
> >> tunnels may be useful.
>
> Good suggestion and makes sense.
>
> >> - 3.3.2.  LISP Forwarding State
> >>
> >>    In the LISP architecture, ITRs keep just = enough information to route
> >>    traffic flowing through it.
> >>
> >> "it." -> "them."
> >>
> >>    Meaning that, ITRs retrieve from the
> >>    LISP Mapping System mappings between EID = prefixes and RLOCs that are
> >>    used to encapsulate packets.
> >>
> >> This is the first use of the notion of EID prefixes.  = That concept should
> >> be explained before it is used, although a forward = reference to section
> >> 3.4.1 may suffice.  It might be better to rewrite = this paragraph in terms
> >> of EIDs and leave the notion of EID prefixes to section = 3.4.1.
>
> Hmm, I'll let Albert and Damien decide if we should state = "EID-prefixes"
> everywhere instead of just "EID".
>
> >>
> >> - 4.4.  MTU Handling
> >>
> >>    Additionally, LISP also recommends inferring = reachability of locators
> >>    by using information provided by the = underlay, in particular:
> >>
> >> It'd be useful to add a sentence or two about how LISP and = the techniques
> >> in this section interact with host use of PMTUD and = PLPMTUD.
>
> This is a lot of detail because in RFC6830 we have 3 positions or = options on
> the subject. And we did provide a reference to RFC6830 for this = topic.
>
> >> - Next to last paragraph on p.17:
> >>
> >>    Additionally, LISP also recommends inferring = reachability of locators
> >>    by using information provided by the = underlay, in particular:
> >>
> >> This looks like it's a paragraph early and needs to be = moved down to
> >> after the paragraph that follows it.
>
> Agree.
>
> >> idnits 2.13.01 didn't find any nits.
> >>
> >> Thanks,
> >> --David
>
> Thanks again David.
>
> Dino

 


= --Apple-Mail=_FF201527-D975-4E24-AF6F-51C34073DA7D-- From nobody Thu Feb 12 05:15:41 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEE71A8739; Thu, 12 Feb 2015 05:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llacm4M1bdI3; Thu, 12 Feb 2015 05:14:59 -0800 (PST) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (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 CBE4C1A016A; Thu, 12 Feb 2015 05:14:59 -0800 (PST) Received: by pdbfl12 with SMTP id fl12so11922720pdb.2; Thu, 12 Feb 2015 05:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w+DevvZ0qFe39mtxH5Z55QmcWPYiNph5aovSDrDogpw=; b=WqdEVPD/t4wEu3niTIv4eN2Ky+GXlF+dHBuhGN6RMLty6cl0K6A82fLHOLYny+lyfS KxZUSL+gRcL+Yq4exIHGfJzy/9TRUNbcHeVmrIv6HIifMXbC7qIdghOrDZ4sAyARUPKM QnPwUz1wwyQVACshSyXpJz8YbbVPO0sFfoQR7IlY2CR1tNYZxSk3knTzJer7l8BiOERE sCI7ge/LZDMSYjPWUWpitmcyRRHOWc/4s85lxNZSKARJc4ryRhXBAAl72zzuaFncH6nG oasrAlwYOZQcPU9Q1Ge9Z1TIfsyPGuRQhyvh56XDf7hkV0WAJIOcvn/NlPosEgcH+aRH kJ5w== X-Received: by 10.66.65.234 with SMTP id a10mr6543246pat.120.1423746899479; Thu, 12 Feb 2015 05:14:59 -0800 (PST) Received: from [10.231.66.55] ([166.170.38.252]) by mx.google.com with ESMTPSA id sy2sm3859518pbc.8.2015.02.12.05.14.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 05:14:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12B466) In-Reply-To: <7317886D-8A3B-4C79-8F82-1A961FCE7A46@gigix.net> Date: Thu, 12 Feb 2015 05:14:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DA982D.60200@joelhalpern.com> <7317886D-8A3B-4C79-8F82-1A961FCE7A46@gigix.net> To: Luigi Iannone Archived-At: Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:15:13 -0000 > G-EID =3D> the EID multicast group G=20 > G-RLOC =3D> the RLOC multicast group G "inner and outer group addresses" have been used in various LISP multicast d= ocuments.=20 Dino= From nobody Thu Feb 12 05:16:33 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F3A1A87D4; Thu, 12 Feb 2015 05:16:31 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qF7sSCr8ZRD; Thu, 12 Feb 2015 05:16:30 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 CA7581A8739; Thu, 12 Feb 2015 05:16:29 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id fa1so11460734pad.2; Thu, 12 Feb 2015 05:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TAq84aHQETX8StM7z3yWNdgiR+g5LUOHIPxCWXlbRrE=; b=XpLF0WzyhtMHKPJw79g11hYUVe2fDuZDZHPK8y1INNN5RGi7Yh4qzAFDxTC3EB/CfF IszLElfQA3O6oReLPa1KawAxh9cRTUv5t8c6glyPT5NEqFJ5785qyV9X30j2k6Iu/abr jUI+imRJJcEovqAnBmy/EEtdeaEQVM/E+Izy+FcoG6fCD5FIqhMK9Thvp0SzC+CcC5dP U81gKtP4tVkSn81UVs0VM1I7AdvluwggGPGpiDyl1VgylMzzWg8wTra/Wdofzk6SVhyf w8meg0/TF7tnxF7Cj7hukeTCBInfJkyLZwRYGp0HXpxN1zYYiBmC5pN7rZelFlK9QdBL ITkQ== X-Received: by 10.68.231.102 with SMTP id tf6mr6561544pbc.40.1423746989142; Thu, 12 Feb 2015 05:16:29 -0800 (PST) Received: from [10.231.66.55] ([166.170.38.252]) by mx.google.com with ESMTPSA id sg4sm3880250pac.11.2015.02.12.05.16.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 05:16:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12B466) In-Reply-To: <1A8253CB-7E12-4949-BBAB-45BD6DF2F496@gigix.net> Date: Thu, 12 Feb 2015 05:16:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7424A9E9-AB40-4267-B955-6A1AF2786ADB@gmail.com> References: <1A8253CB-7E12-4949-BBAB-45BD6DF2F496@gigix.net> To: Luigi Iannone Archived-At: Cc: "Jmh.direct" , "ops-dir@ietf.org" , "lisp@ietf.org" , "david.black@emc.com" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:16:31 -0000 > NEW >=20 > "In the mobility case the EID-prefix can be as small as a full /32 or /128= (IPv4 or IPv6 respectively) depending on the mobility use-case (e.g., subne= t mobility vs single VM/Mobile node mobility)" >=20 > Opinions? I agree it is better and handles different cases without explicitly stating i= t here. Dino= From nobody Thu Feb 12 06:21:06 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B768F1A88D9; Thu, 12 Feb 2015 06:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gUwGR83YoNH; Thu, 12 Feb 2015 06:20:48 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E811A8857; Thu, 12 Feb 2015 06:20:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 89B181C049F; Thu, 12 Feb 2015 06:20:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7BA8A1C059F; Thu, 12 Feb 2015 06:20:16 -0800 (PST) Message-ID: <54DCB679.8060606@joelhalpern.com> Date: Thu, 12 Feb 2015 09:19:37 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Luigi Iannone References: <1A8253CB-7E12-4949-BBAB-45BD6DF2F496@gigix.net> In-Reply-To: <1A8253CB-7E12-4949-BBAB-45BD6DF2F496@gigix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ops-dir@ietf.org, ietf@ietf.org, david.black@emc.com, Damien Saucez , lisp@ietf.org Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:20:55 -0000 That proposed text works for me. Yours, Joel On 2/12/15 3:28 AM, Luigi Iannone wrote: > Hi, > > Aren’t we going into to much details for the intro document? > > What if we change the sentence in the following way: > > OLD (suggested by David) > > "in the specific case of a VM/mobile node the EID-prefix should be /32 > or /128 (IPv4 or IPv6 respectively)” > > NEW > > "In the mobility case the EID-prefix can be as small as a full /32 or > /128 (IPv4 or IPv6 respectively) depending on the mobility use-case > (e.g., subnet mobility vs single VM/Mobile node mobility)" > > > Opinions? > > >> On 12 Feb 2015, at 02:59, Jmh.direct > > wrote: >> >> Temeber that an EID prefix represents a site. A tenant network in a >> data center is a viable site. So the prefix as registered for that. >> Mobiluty of VMs with the tenant network can be handled internally. >> >> Ypu could instead advertise each VM EID. Tge fact that both cased >> work makes doing an introductory description a bit tricky. >> >> Yours, >> Joel >> >> >> Sent from my Samsung smartphone on AT&T >> >> >> >> -------- Original message -------- >> Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >> From: "Black, David" > >> To: "Jmh.direct" > >,"acabello@ac.upc.edu >> " > > >> CC: "farinacci@gmail.com " >> > >,"jmh@joelhalpern.com >> " > >,"damien.saucez@inria.fr >> " > >,"ops-dir@ietf.org >> " > >,"ietf@ietf.org " >> >,"lisp@ietf.org >> " >,"Black, >> David" > >> >> >> > In the VM case, am entire service network may be moved to the data >> center, and so the EID block for that set can be moved. >> >> For a single VM, that would apply if the VM is using an entire EID >> block - most individual VMs aren’t/don’t. Individual /32 and /128 >> addresses are common for individual VMs, so that’s what’s needed in >> general for individual VM movement. >> >> I’d expect the EID block move case to apply for movement of a group of >> VMs that are using such a block (e.g., as a subnet), but VM live >> migrations cannot be synchronized in general (cold migrations of >> powered-off VMs can be, obviously), so even in this case where the >> entire EID block moves, if live VM migrations are involved, there are >> intermediate stages where the EID block is split between LISP sites >> ... and hence /32 and /128 prefixes are still what’s wanted. >> >> Thanks, >> --David >> >> *From:*Jmh.direct [mailto:jmh.direct@joelhalpern.com] >> *Sent:* Wednesday, February 11, 2015 7:19 PM >> *To:* Black, David; acabello@ac.upc.edu >> *Cc:* farinacci@gmail.com ; >> jmh@joelhalpern.com ; >> damien.saucez@inria.fr ; >> ops-dir@ietf.org ; ietf@ietf.org >> ; lisp@ietf.org >> *Subject:* RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >> *Importance:* Low >> >> I thinl we may want to separate VM mobility from mobile devices. Om >> the VM case, am entire setvice network may be moved to the data >> center, and so the EID block for that set can be moved. In the case >> of individually mobile debices or some vatiations on data center >> mobility, there is a need to mske sure the full EID is advertised in >> the mapping system. >> >> Yours, >> >> Joel >> >> >> >> Sent from my Samsung smartphone on AT&T >> >> >> >> >> -------- Original message -------- >> Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >> From: "Black, David" > >> To: "acabello@ac.upc.edu " >> > >> CC: Dino Farinacci > >,"Joel M. Halpern" > >,Damien Saucez > >,"ops-dir@ietf.org >> " > >,"ietf@ietf.org " >> >,"lisp@ietf.org >> " >,"Black, >> David" > >> >> Hi Albert, >> >> As noted below, on the EID prefix for mobility issue, a simple >> statement in Section 5 to the effect that “in the specific case of a >> VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IPv6 >> respectively)” will suffice. Details on what to do when that advice >> is ignored can be left to other documents. >> >> Thanks, >> --David >> >> *From:*Albert Cabellos [mailto:albert.cabellos@gmail.com] >> *Sent:* Wednesday, February 11, 2015 6:33 PM >> *To:* Black, David >> *Cc:* Dino Farinacci; Joel M. Halpern; Damien Saucez; ops-dir@ietf.org >> ; ietf@ietf.org ; >> lisp@ietf.org >> *Subject:* Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >> >> Hi David >> >> Thanks for your comments, I am parsing them and I´ll suggest new text >> aiming to address them ASAP. >> >> I would also like to better understand [A] before doing this. >> >> With LISP an EID-preifx can have an arbitrary length and can move >> (i.e., change its RLOC bindings), in the specific case of a VM/mobile >> node the EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively). >> What doesn't work is the mobility of a node (assigned with a /32 or >> /128) *within* a coarser EID-prefix, in this case you need to split >> the prefix into more specifics and register them independently in the >> Mapping System, effectively creating new EID-prefixes. >> >> Please let me know if this clarifies your comment, in this case I will >> suggest new text for Section 5. >> >> Albert >> >> On Thu, Feb 12, 2015 at 12:07 AM, Black, David > > wrote: >> >> Dino - thanks for the response. >> >> On the major issues, it looks like both [A] and [B] involve only the text >> in this draft and nothing beyond, which is good news. I have a simple >> text >> suggestion for [A], but it looks like [B] is going to require some careful >> editing, as one of the primary causes is that the draft is sloppy in using >> the same symbol "G" to represent both EID and RLOC multicast groups. >> >> On the minor issues, I have text suggestions for three of the four, and >> I'd like to temporarily defer further discussion the IPv6 UDP zero >> checksum "tarpit" in favor of resolving everything else first. >> >> On the nits/editorial comments, all the suggestions in your email are fine >> with me. FWIW, I regard that portion of a review as almost entirely >> subject to the draft authors' discretion (and editorial taste). >> >> > >> [A] EID mobility vs. EID prefixes >> > >> > ... from the start of the LISP design (circa 2007), an prefix is >> what moves. >> > And a specific EID is simply a /32 or /128 prefix. Here is a practical >> > example: >> >> A statement that the mobility use cases need to employ /32 and /128 >> prefixes, >> and not anything coarser should suffice. That should be added to >> Section 5. >> >> > >> [B] LISP Multicast vs. EID/RLOC separate >> > >> >> > >> - 6. Multicast >> > >> >> > >> This is interesting, multicast addresses (G) look like they're an >> exception >> > >> > They are really not. >> >> My concern is that as I read the draft, it leaves me with the strong >> impression >> that the same multicast addresses (G) are being used in both the overlay >> (as EIDs) and the underlay (as RLOCs). From your response, I conclude >> that this >> is not the case (and I have no argument with that). Rather, Section 6 >> needs to >> bluntly state that multicast addresses are mapped between EID and RLOC >> space at >> both ITRs and ETRs, so that the following inference is obvious from >> the text >> (it's currently not obvious): >> >> > So it makes perfect sense to register multicast addresses to the mapping >> > system as EIDs and they can map to RLOCs of sites that have joined >> the group. >> >> As part of this, I strongly recommend moving away from use of "G" to >> refer to >> multicast groups in both the overlay and underlay. Careful use of G-EID >> and G-RLOC would significantly improve clarity. >> >> --- >> If the above are done for [A] and [B] in Sections 5 and 6, then the >> text for the >> use cases in Section 7 should not need further attention. >> --- >> >> > >> -- Minor Issues -- >> > >> >> > >> There seems to be an implicit assumption that the end host and its >> > >> ITR (xTR) are in the same domain or Autonomous System. For >> incremental >> > >> > This is true when you call the domain a "LISP site". But if the site is >> > unchanged and one uses PITRs, maybe even close to the site, like in a PE >> > router, then the PITR is definitely in another AS. >> >> Looking at the text, it seems that "LISP site" and "domain" are the same >> concept for this draft. That would be useful to state, IMHO but I'll >> leave >> the decision on whether to do so to you and the draft authors. >> >> On rereading, my concerns seem to be triggered mostly by this sentence in >> Section 3.2: >> >> The edge consists of LISP sites (e.g., an >> Autonomous System) that use EID addresses. >> >> I think a small change to the last sentence in that paragraph would >> resolve >> my concern without distracting from the narrative: >> >> OLD >> EIDs do not >> contain inter-domain topological information and because of this, >> EIDs are usually routable at the edge (within LISP sites) or in the >> non-LISP Internet. >> NEW >> EIDs do not >> contain inter-domain topological information and because of this, >> EIDs are usually routable at the edge (within LISP sites) or in the >> non-LISP Internet; see Section 3.5 for discussion of LISP site >> internetworking with non-LISP sites and domains in the Internet. >> >> > >> Despite multiple mentions of incremental deployment, I did not >> > >> see a discussion of how that might be accomplished. >> > >> > There are PxTRs and NATs. And references to the LISP interworking RFC. >> >> Ok, can we just say so in Section 3.5? Adding the following sentence >> to the end of the section would suffice: >> >> PITRs, PETRs and LISP-NAT support incremental deployment of LISP >> by providing significant flexibility in location of the boundaries >> between the LISP and non-LISP portions of the network, and making >> it reasonable to change those boundaries over time. >> >> > >> - 3.3.1. LISP Encapsulation >> > >> >> > >> the source port is selected by >> > >> the ITR and ignored on reception. >> > >> >> > >> Please mention multipathing (e.g., ECMP and LAG) as possible >> influences >> > >> on how source ports are selected, as this imposes some limits on >> what an >> > >> ITR can reasonably do. >> > >> > ECMP/LAG don't influence which source port is selected. It is a >> 5-tuple hash >> > of the inner header that selects a source port that influences how >> an underlay >> > router would load-split traffic. >> >> Please state that a 5-tuple hash is used. ECMP/LAG is among the important >> reasons why, but that doesn't need to be stated if you prefer not to. An >> example of something that needs to be excluded is that using a random >> number generator to set the source port would be wrong - I could suggest >> citing draft-ietf-dart-dscp-rtp for related discussion (and lots more >> details), but I don't think that's necessary. >> >> -- IPv6 zero UDP checksum >> >> > My head spins every time I hear about this subject. This subject has >> been >> > talked about from 100s of people for a decade. We have CRC on links, >> we have >> > apps that use TCP and UDP checksums. Nuf said. >> >> Understood - there's more than one set of scars on this one :-(. >> Let's come back >> to this topic after we've resolved everything else, and please keep in >> mind >> that I tagged this as a minor issue, not a major one (e.g., the above >> changes >> for [A] and [B] are far more important, IMHO). >> >> Thanks, >> --David >> >> > -----Original Message----- >> > From: Dino Farinacci [mailto:farinacci@gmail.com ] >> > Sent: Wednesday, February 11, 2015 2:19 PM >> > To: Joel M. Halpern >> > Cc: Black, David; Albert Cabellos; Damien Saucez;ops-dir@ietf.org ; >> >ietf@ietf.org ; lisp@ietf.org >> > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >> > >> >> > > I will leave most of these for the authors to comment on. >> > >> > See my comments inline. Thanks David for your detailed review and >> commentary. >> > >> > > With regard to your question about incremental deployment, that is the >> > domain of the LISP Deployment document, and was deliberately only >> lightly >> > covered here. I am not sure what we can do to address your comment >> without >> > duplicating the entirety of that document. >> > >> > That is the risk we may have with many of your comments. We have a >> lot of >> > detail in the already 9 published RFCs and this document really is >> to take >> > all that detail and summarize as an easily understandable >> description of a >> > cohesive design. >> > >> > > With regard to UDP Zero, this was approved by the IESG and >> published as an >> > RFC. It is part of the way the protocol is defined. If there are >> specific >> > changes you would like to see in the explanatory text, I am sure >> > >> > Definitely agreed. In fact we instigated UDP zero. And I continually >> talk to >> > hardware engineers and they all believe we made the right decision. >> So hats >> > off to the IETF for being practical. >> > >> > > we could include them. If you are looking for a change in the >> behavior, >> > this document can not make changes to the LISP behavior. >> > >> > Yes, an important point. >> > >> > >> I found a couple of major issues that I hope arise from the >> > >> summarization of LISP in this draft, as opposed to being problems in >> > >> the actual LISP protocols. I also found a few minor issues, the most >> > >> important of which is the need for additional security considerations >> > >> discussion on misdelivery, with particular attention to VPNs. >> > >> > Thanks a ton. >> > >> > >> -- Major issues -- >> > >> >> > >> [A] EID mobility vs. EID prefixes >> > >> >> > >> - 5. Mobility >> > >> >> > >> I understand how this works when mapping is per-EID, but how does >> this work >> > >> when the EID of the system that moves is part of an EID prefix, as >> > discussed >> > >> in Section 3.4.1? Even if the answer is a long version of "Don't >> do that!" >> > >> it should be explained. >> > >> > No, from the start of the LISP design (circa 2007), an prefix is >> what moves. >> > And a specific EID is simply a /32 or /128 prefix. Here is a practical >> > example: >> > >> > You have a cluster of servers that communicate together for a particular >> > application. They application cluster is running in a set of VMs. >> Those VMs >> > are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are >> currently >> > running in a brick-and-mortar data center. Now there is a desire to >> move the >> > VM cluster to a cloud provider. What is moved is the EID-prefix of the >> > cluster. The mapping system is told that the EID-prefix is changing >> its RLOC- >> > set from the brick-and-mortar xTRs to the cloud providers xTRs. >> > >> > >> >> > >> - 7.4. LISP for Virtual Machine Mobility in Data Centers >> > >> >> > >> I don't understand how this works when EID prefixes are used, as >> each VM >> > >> has its own EID or EIDs, hence the entire prefix range does not >> move when >> > >> the VM moves. >> > >> >> > >> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in >> Appendix A >> > >> of RFC 5706: Has deployment been discussed? and specifically under: >> > >> >> > >> * Is the proposed specification deployable? If not, how >> could >> > >> it be improved? >> > >> >> > >> as EID prefixes appear to be undeployable for Mobility and VM >> Mobility >> > usage. >> > >> > See above example. >> > >> > >> [B] LISP Multicast vs. EID/RLOC separate >> > >> >> > >> - 6. Multicast >> > >> >> > >> This is interesting, multicast addresses (G) look like they're an >> exception >> > >> > They are really not. Since multicast addresses *identify* a group of >> > receivers, it is very much an EID and aheres to the definition of an >> EID. >> > Multicast addresses never had topological signficance but the state >> > representing a distribution tree does tell you were the members are >> (but the >> > identity of the members are not know in multicast). >> > >> > So it makes perfect sense to register multicast addresses to the mapping >> > system as EIDs and they can map to RLOCs of sites that have joined >> the group. >> > See draft-farinacci-signal-free-multicast as just one example. >> RFC6831 and >> > draft-farinacci-lisp-mr-signaling are other examples. >> > >> > >> to the EID/RLOC separation as the same destination IP multicast >> address >> > >> is used for both purposes. This could use some more discussion, >> as it's >> > >> unexpected based on the contents of the draft up to this point. >> > >> > I believe the level of detail we have in the introduction document >> is at the >> > right level or we'll err on having way too many details crop in. >> > >> > >> - 7.2. LISP for IPv6 Co-existence >> > >> >> > >> LISP encapsulations allows to transport packets using EIDs from a >> > >> given address family (e.g., IPv6) with packets from other address >> > >> families (e.g., IPv4). >> > >> >> > >> How does that work for multicast traffic, where the destination >> address >> > >> (G) has to be the same in both the inner and outer headers? Are ETRs >> > >> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? >> > >> > The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a >> RLOC set >> > that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that >> > receives the packet from S-EID-ipv6 would replicate the packet and >> multicast >> > encapsulate to ipv4-multicast and unicast encapsualte to ipv4-unicast. >> > >> > >> - 7.3. LISP for Virtual Private Networks >> > >> >> > >> This also has multicast problems, as there is only one instance >> of each >> > >> multicast address (G) in the underlay network. I think I can >> figure out >> > how >> > >> > You can map from EID-G to RLOC-G one to one. But we have seen over >> the last >> > decade in a half that with general multicast deployment that >> many-to-1 is >> > desirable. Hence, now that we have a way to map with a network-based >> database, >> > we can map multiple EID-Gs to a single (or multiple) RLOC-Gs. >> > >> > >> to make multicast work for this use case, but it's not >> immediately obvious, >> > >> and the result when the same underlay multicast address is used >> by more >> > >> than one VPN could well deliver some traffic to ETRs that have to >> discard >> > >> > This is a necessary evil when the underlay is state challenged. But >> it is a >> > state/bandwidth tradeoff. We have found with MVPN deployment that >> the network >> > admin configures the underly or simply unicasts. >> > >> > >> it because the Instance ID is wrong (and that excessive delivery is a >> > >> security consideration, see minor issue on Section 8 below). I >> think an >> > >> explanation is in order. >> > >> > There are just too many combinations to make a high-level >> description simple >> > to understand. The current introduction text does a find job providing >> > references for someone to go off and get the details. >> > >> > >> -- Minor Issues -- >> > >> >> > >> There seems to be an implicit assumption that the end host and its >> > >> ITR (xTR) are in the same domain or Autonomous System. For >> incremental >> > >> > This is true when you call the domain a "LISP site". But if the site is >> > unchanged and one uses PITRs, maybe even close to the site, like in a PE >> > router, then the PITR is definitely in another AS. But note I said >> PITR and >> > not ITR. The reason being is because an ITR is configured with database- >> > mapping prefixes that is uses to encapsulate packets from such >> addresses. >> > Versus the PITR being an ITR with *no database-mappings* providing a >> much more >> > larger/or more aggregtable service. >> > >> > >> deployment, I don't think that's always the case, but I think >> that only >> > >> has editorial impact on this document, as I don't think any of the >> > >> fundamental LISP mechanisms are affected. The authors should >> look for >> > >> use of "domain" and "Autonomous System" and ensure that the text is >> > >> generalized to the case where the end host and ITR are more widely >> > >> separated. >> > >> > We are overloaded with terms that create topological or organization >> boundary. >> > Hence why we created "LISP site" which is also the same as a "LISP >> VPN site". >> > Where a "LISP site" that has multiple tennants would be multiple >> "LISP VPN >> > sites". >> > >> > >> Despite multiple mentions of incremental deployment, I did not >> > >> see a discussion of how that might be accomplished. There is some >> > >> > There are PxTRs and NATs. And references to the LISP interworking RFC. >> > >> > >> useful content in Section 3.5, but that's at best an incomplete >> > >> explanation. This is an OPS-Dir review concern - it falls under >> > >> A.1.3 in Appendix A of RFC 5706: Has the migration path been >> discussed? >> > >> >> > >> - 3.3.1. LISP Encapsulation >> > >> >> > >> the source port is selected by >> > >> the ITR and ignored on reception. >> > >> >> > >> Please mention multipathing (e.g., ECMP and LAG) as possible >> influences >> > >> on how source ports are selected, as this imposes some limits on >> what an >> > >> ITR can reasonably do. >> > >> > ECMP/LAG don't influence which source port is selected. It is a >> 5-tuple hash >> > of the inner header that selects a source port that influences how >> an underlay >> > router would load-split traffic. >> > >> > >> For OPS-Dir, this multipathing concern falls under A.1.4 in >> Appendix A of >> > >> RFC 5706: Have the Requirements on other protocols and functional >> > >> components been discussed? >> > >> >> > >> This decision was made because the >> > >> typical transport protocols used by the applications already >> include >> > >> a checksum, by neglecting the additional UDP encapsulation >> checksum >> > >> xTRs can forward packets more efficiently. >> > >> >> > >> Groan! I have an exquisite set of scars on UDP zero checksums >> for IPv6 >> > >> from working on the MPLS in UDP draft, so I may be overly >> sensitive to >> > >> this concern. The downside of this efficiency is that there is no >> > >> checksum coverage of the IPv6 header when zero UDP checksums are >> used. >> > >> That should at least be mentioned here, with a summary of why >> that's ok >> > >> - the detailed justification for why that's ok can be left to other >> > >> documents. >> > >> > My head spins every time I hear about this subject. This subject has >> been >> > talked about from 100s of people for a decade. We have CRC on links, >> we have >> > apps that use TCP and UDP checksums. Nuf said. >> > >> > >> >> > >> -- Nits/Editorial Comments -- >> > >> >> > >> - Top of p.4: >> > >> >> > >> The initial motivation in the LISP effort is to be find in the >> > >> >> > >> "find" -> "found" >> > >> >> > >> - Section 3.1, first bullet item >> > >> > We will certainly fixe these. Thanks. >> > >> > >> >> > >> Devices are assigned with relatively opaque identity >> > >> meaningful addresses that are independent of their topological >> > >> location. >> > >> >> > >> I don't understand "relatively opaque identity meaningful" and >> > >> suggest rewriting the sentence. In particular - opaque to what? >> > >> meaningful to what in what manner? >> > >> > Well beacuse it is as accurate as it can be. If automobiles are >> going to be >> > assigned EIDs from a VIN number allocation from a manufacture, the >> address is >> > relatively opaque. If a VM in a data-center is going to be assigned >> an EID >> > from the set of prefixes already being used and allocated to that >> data-center, >> > then there is a good chance that address is in a power-of-2 block >> that is >> > summarizable in the IGP. >> > >> > >> >> > >> - Section 3.2, second paragraph >> > >> >> > >> Judging from the figure, xTRs are the common case, with single- >> > >> function ITRs and ETRs being rare. It might be good to say that >> > >> and discuss when ITRs and ETRs that are not xTRs are appropriate >> > >> to use. >> > >> > When you want egress path selection to happen further out in the >> toplogical >> > from the source location, then you put an ITR-only system there. >> Where ingress >> > to the same source (destination in this direction), the ETR can be >> closer to >> > the destination. >> > >> > >> >> > >> - 3rd paragraph on p.7: >> > >> >> > >> >> > >> Finally, the LISP architecture emphasizes a cost effective >> > >> incremental deployment. >> > >> >> > >> I'd delete "cost effective" here and look for other occurrences >> > >> of "cost" as candidates for deletion. This is supposed to be >> > >> a technical document, so discussion of costs is a bit off-target. >> > >> > Fair enough. >> > >> > >> - First item after Figure 2: >> > >> >> > >> 1. HostA retrieves the EID_B of HostB, typically querying the DNS >> > >> and obtaining and A or AAAA record. >> > >> >> > >> "and A" -> "an A" (spelling checkers don't catch everything). >> > >> > Already noted and will be fixed. >> > >> > >> >> > >> - 3.3.1. LISP Encapsulation >> > >> >> > >> On the other hand, Recursive >> > >> tunnels are nested tunnels and are implemented by using >> multiple LISP >> > >> encapsulations on a packet. >> > >> >> > >> The above sentence seems out of place in the middle of a >> paragraph about >> > >> Re-encapsulating tunnels and routers - I suggest moving it down >> into its >> > >> own paragraph and perhaps adding a sentence about where/how Recursive >> > >> tunnels may be useful. >> > >> > Good suggestion and makes sense. >> > >> > >> - 3.3.2. LISP Forwarding State >> > >> >> > >> In the LISP architecture, ITRs keep just enough information to >> route >> > >> traffic flowing through it. >> > >> >> > >> "it." -> "them." >> > >> >> > >> Meaning that, ITRs retrieve from the >> > >> LISP Mapping System mappings between EID prefixes and RLOCs >> that are >> > >> used to encapsulate packets. >> > >> >> > >> This is the first use of the notion of EID prefixes. That >> concept should >> > >> be explained before it is used, although a forward reference to >> section >> > >> 3.4.1 may suffice. It might be better to rewrite this paragraph >> in terms >> > >> of EIDs and leave the notion of EID prefixes to section 3.4.1. >> > >> > Hmm, I'll let Albert and Damien decide if we should state "EID-prefixes" >> > everywhere instead of just "EID". >> > >> > >> >> > >> - 4.4. MTU Handling >> > >> >> > >> Additionally, LISP also recommends inferring reachability of >> locators >> > >> by using information provided by the underlay, in particular: >> > >> >> > >> It'd be useful to add a sentence or two about how LISP and the >> techniques >> > >> in this section interact with host use of PMTUD and PLPMTUD. >> > >> > This is a lot of detail because in RFC6830 we have 3 positions or >> options on >> > the subject. And we did provide a reference to RFC6830 for this topic. >> > >> > >> - Next to last paragraph on p.17: >> > >> >> > >> Additionally, LISP also recommends inferring reachability of >> locators >> > >> by using information provided by the underlay, in particular: >> > >> >> > >> This looks like it's a paragraph early and needs to be moved down to >> > >> after the paragraph that follows it. >> > >> > Agree. >> > >> > >> idnits 2.13.01 didn't find any nits. >> > >> >> > >> Thanks, >> > >> --David >> > >> > Thanks again David. >> > >> > Dino >> > From nobody Thu Feb 12 06:48:51 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2D41A8A66; Thu, 12 Feb 2015 06:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RorYPRf8rfzm; Thu, 12 Feb 2015 06:48:43 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A639A1A8A92; Thu, 12 Feb 2015 06:48:42 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEmX3N022770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 09:48:35 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t1CEmX3N022770 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423752516; bh=9dTp4rKt7VuossCG+8Lma2HDnEA=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=nMUkQWBBw18Q98QN/JQtHgem8mlIgei9N/zPsdeAN06AMwUo0AvMwabwYgtGhGkgq 9pFEdS8FxuGcjMu5QlOL1n8rVwPATQY2sDu7TUvbx0LmWBsjL5OMEsE7hiGPoXwGJ1 ykFowCl9ZcSAPrqh0xokbUexp6wdi4ghy/DrIGm4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t1CEmX3N022770 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Thu, 12 Feb 2015 09:48:07 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEmI7C003819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 09:48:19 -0500 Received: from MXHUB205.corp.emc.com (10.253.68.31) by mxhub19.corp.emc.com (10.254.93.48) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 12 Feb 2015 09:48:18 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB205.corp.emc.com ([10.253.68.31]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 09:48:18 -0500 From: "Black, David" To: "Joel M. Halpern" , Luigi Iannone Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [A] Thread-Index: AdBG0u/AYK/A807ISYeKjR+9qoImuA== Date: Thu, 12 Feb 2015 14:48:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [A] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:48:49 -0000 KzEgLSB0aGUgY3J1Y2lhbCBjb25jZXB0IHRvIGludHJvZHVjZSAoSU1ITykgaXMgdGhhdCB0aGUg InByZWZpeCIgY2FuIGJlIGEgc2luZ2xlIElQIGFkZHJlc3MuDQoNClRoYW5rcywNCi0tRGF2aWQN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZWwgTS4gSGFscGVy biBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAxMiwgMjAxNSA5OjIwIEFNDQo+IFRvOiBMdWlnaSBJYW5ub25lDQo+IENjOiBCbGFjaywgRGF2 aWQ7IGFjYWJlbGxvQGFjLnVwYy5lZHU7IG9wcy1kaXJAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmc7 DQo+IGZhcmluYWNjaUBnbWFpbC5jb207IERhbWllbiBTYXVjZXo7IGlldGZAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtsaXNwXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtaW50 cm9kdWN0aW9uLTExDQo+IA0KPiBUaGF0IHByb3Bvc2VkIHRleHQgd29ya3MgZm9yIG1lLg0KPiBZ b3VycywNCj4gSm9lbA0KPiANCj4gT24gMi8xMi8xNSAzOjI4IEFNLCBMdWlnaSBJYW5ub25lIHdy b3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gQXJlbuKAmXQgd2UgZ29pbmcgaW50byB0byBtdWNoIGRl dGFpbHMgZm9yIHRoZSBpbnRybyBkb2N1bWVudD8NCj4gPg0KPiA+IFdoYXQgaWYgd2UgY2hhbmdl IHRoZSBzZW50ZW5jZSBpbiB0aGUgZm9sbG93aW5nIHdheToNCj4gPg0KPiA+IE9MRCAoc3VnZ2Vz dGVkIGJ5IERhdmlkKQ0KPiA+DQo+ID4gImluIHRoZSBzcGVjaWZpYyBjYXNlIG9mIGEgVk0vbW9i aWxlIG5vZGUgdGhlIEVJRC1wcmVmaXggc2hvdWxkIGJlIC8zMg0KPiA+IG9yIC8xMjggKElQdjQg b3IgSVB2NiByZXNwZWN0aXZlbHkp4oCdDQo+ID4NCj4gPiBORVcNCj4gPg0KPiA+ICJJbiB0aGUg bW9iaWxpdHkgY2FzZSB0aGUgRUlELXByZWZpeCBjYW4gYmUgYXMgc21hbGwgYXMgYSBmdWxsIC8z MiBvcg0KPiA+IC8xMjggKElQdjQgb3IgSVB2NiByZXNwZWN0aXZlbHkpIGRlcGVuZGluZyBvbiB0 aGUgbW9iaWxpdHkgdXNlLWNhc2UNCj4gPiAoZS5nLiwgc3VibmV0IG1vYmlsaXR5IHZzIHNpbmds ZSBWTS9Nb2JpbGUgbm9kZSBtb2JpbGl0eSkiDQo+ID4NCj4gPg0KPiA+IE9waW5pb25zPw0KPiA+ DQo+ID4NCj4gPj4gT24gMTIgRmViIDIwMTUsIGF0IDAyOjU5LCBKbWguZGlyZWN0IDxqbWguZGly ZWN0QGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA8bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4u Y29tPj4gd3JvdGU6DQo+ID4+DQo+ID4+IFRlbWViZXIgdGhhdCBhbiBFSUQgcHJlZml4IHJlcHJl c2VudHMgYSBzaXRlLiAgQSB0ZW5hbnQgbmV0d29yayBpbiBhDQo+ID4+IGRhdGEgY2VudGVyIGlz IGEgdmlhYmxlIHNpdGUuICBTbyB0aGUgcHJlZml4IGFzIHJlZ2lzdGVyZWQgZm9yIHRoYXQuDQo+ ID4+ICBNb2JpbHV0eSBvZiBWTXMgd2l0aCB0aGUgdGVuYW50IG5ldHdvcmsgY2FuIGJlIGhhbmRs ZWQgaW50ZXJuYWxseS4NCj4gPj4NCj4gPj4gWXB1IGNvdWxkIGluc3RlYWQgYWR2ZXJ0aXNlIGVh Y2ggVk0gRUlELiAgVGdlIGZhY3QgdGhhdCBib3RoIGNhc2VkDQo+ID4+IHdvcmsgbWFrZXMgZG9p bmcgYW4gaW50cm9kdWN0b3J5IGRlc2NyaXB0aW9uIGEgYml0IHRyaWNreS4NCj4gPj4NCj4gPj4g WW91cnMsDQo+ID4+IEpvZWwNCj4gPj4NCj4gPj4NCj4gPj4gU2VudCBmcm9tIG15IFNhbXN1bmcg c21hcnRwaG9uZSBvbiBBVCZUDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS0NCj4gPj4gU3ViamVjdDogUkU6IFtsaXNwXSBPUFMtRGlyIHJl dmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTExDQo+ID4+IEZyb206ICJCbGFj aywgRGF2aWQiIDxkYXZpZC5ibGFja0BlbWMuY29tIDxtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNv bT4+DQo+ID4+IFRvOiAiSm1oLmRpcmVjdCIgPGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tDQo+ ID4+IDxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+PiwiYWNhYmVsbG9AYWMudXBj LmVkdQ0KPiA+PiA8bWFpbHRvOmFjYWJlbGxvQGFjLnVwYy5lZHU+IiA8YWNhYmVsbG9AYWMudXBj LmVkdQ0KPiA+PiA8bWFpbHRvOmFjYWJlbGxvQGFjLnVwYy5lZHU+Pg0KPiA+PiBDQzogImZhcmlu YWNjaUBnbWFpbC5jb20gPG1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tPiINCj4gPj4gPGZhcmlu YWNjaUBnbWFpbC5jb20NCj4gPj4gPG1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tPj4sImptaEBq b2VsaGFscGVybi5jb20NCj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiIgPGptaEBq b2VsaGFscGVybi5jb20NCj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sImRhbWll bi5zYXVjZXpAaW5yaWEuZnINCj4gPj4gPG1haWx0bzpkYW1pZW4uc2F1Y2V6QGlucmlhLmZyPiIg PGRhbWllbi5zYXVjZXpAaW5yaWEuZnINCj4gPj4gPG1haWx0bzpkYW1pZW4uc2F1Y2V6QGlucmlh LmZyPj4sIm9wcy1kaXJAaWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPiIg PG9wcy1kaXJAaWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPj4sImlldGZA aWV0Zi5vcmcgPG1haWx0bzppZXRmQGlldGYub3JnPiINCj4gPj4gPGlldGZAaWV0Zi5vcmcgPG1h aWx0bzppZXRmQGlldGYub3JnPj4sImxpc3BAaWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpsaXNwQGll dGYub3JnPiIgPGxpc3BAaWV0Zi5vcmcgPG1haWx0bzpsaXNwQGlldGYub3JnPj4sIkJsYWNrLA0K PiA+PiBEYXZpZCIgPGRhdmlkLmJsYWNrQGVtYy5jb20gPG1haWx0bzpkYXZpZC5ibGFja0BlbWMu Y29tPj4NCj4gPj4NCj4gPj4NCj4gPj4gPiBJbiB0aGUgVk0gY2FzZSwgYW0gZW50aXJlIHNlcnZp Y2UgbmV0d29yayBtYXkgYmUgbW92ZWQgdG8gdGhlIGRhdGENCj4gPj4gY2VudGVyLCBhbmQgc28g dGhlIEVJRCBibG9jayBmb3IgdGhhdCBzZXQgY2FuIGJlIG1vdmVkLg0KPiA+Pg0KPiA+PiBGb3Ig YSBzaW5nbGUgVk0sIHRoYXQgd291bGQgYXBwbHkgaWYgdGhlIFZNIGlzIHVzaW5nIGFuIGVudGly ZSBFSUQNCj4gPj4gYmxvY2sgLSBtb3N0IGluZGl2aWR1YWwgVk1zIGFyZW7igJl0L2RvbuKAmXQu ICBJbmRpdmlkdWFsIC8zMiBhbmQgLzEyOA0KPiA+PiBhZGRyZXNzZXMgYXJlIGNvbW1vbiBmb3Ig aW5kaXZpZHVhbCBWTXMsIHNvIHRoYXTigJlzIHdoYXTigJlzIG5lZWRlZCBpbg0KPiA+PiBnZW5l cmFsIGZvciBpbmRpdmlkdWFsIFZNIG1vdmVtZW50Lg0KPiA+Pg0KPiA+PiBJ4oCZZCBleHBlY3Qg dGhlIEVJRCBibG9jayBtb3ZlIGNhc2UgdG8gYXBwbHkgZm9yIG1vdmVtZW50IG9mIGEgZ3JvdXAg b2YNCj4gPj4gVk1zIHRoYXQgYXJlIHVzaW5nIHN1Y2ggYSBibG9jayAoZS5nLiwgYXMgYSBzdWJu ZXQpLCBidXQgVk0gbGl2ZQ0KPiA+PiBtaWdyYXRpb25zIGNhbm5vdCBiZSBzeW5jaHJvbml6ZWQg aW4gZ2VuZXJhbCAoY29sZCBtaWdyYXRpb25zIG9mDQo+ID4+IHBvd2VyZWQtb2ZmIFZNcyBjYW4g YmUsIG9idmlvdXNseSksIHNvIGV2ZW4gaW4gdGhpcyBjYXNlIHdoZXJlIHRoZQ0KPiA+PiBlbnRp cmUgRUlEIGJsb2NrIG1vdmVzLCBpZiBsaXZlIFZNIG1pZ3JhdGlvbnMgYXJlIGludm9sdmVkLCB0 aGVyZSBhcmUNCj4gPj4gaW50ZXJtZWRpYXRlIHN0YWdlcyB3aGVyZSB0aGUgRUlEIGJsb2NrIGlz IHNwbGl0IGJldHdlZW4gTElTUCBzaXRlcw0KPiA+PiAuLi4gYW5kIGhlbmNlIC8zMiBhbmQgLzEy OCBwcmVmaXhlcyBhcmUgc3RpbGwgd2hhdOKAmXMgd2FudGVkLg0KPiA+Pg0KPiA+PiBUaGFua3Ms DQo+ID4+IC0tRGF2aWQNCj4gPj4NCj4gPj4gKkZyb206KkptaC5kaXJlY3QgW21haWx0bzpqbWgu ZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0NCj4gPj4gKlNlbnQ6KiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDExLCAyMDE1IDc6MTkgUE0NCj4gPj4gKlRvOiogQmxhY2ssIERhdmlkOyBhY2FiZWxsb0BhYy51 cGMuZWR1IDxtYWlsdG86YWNhYmVsbG9AYWMudXBjLmVkdT4NCj4gPj4gKkNjOiogZmFyaW5hY2Np QGdtYWlsLmNvbSA8bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20+Ow0KPiA+PiBqbWhAam9lbGhh bHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47DQo+ID4+IGRhbWllbi5zYXVj ZXpAaW5yaWEuZnIgPG1haWx0bzpkYW1pZW4uc2F1Y2V6QGlucmlhLmZyPjsNCj4gPj4gb3BzLWRp ckBpZXRmLm9yZyA8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBpZXRmQGlldGYub3JnDQo+ID4+ IDxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IGxpc3BAaWV0Zi5vcmcgPG1haWx0bzpsaXNwQGlldGYu b3JnPg0KPiA+PiAqU3ViamVjdDoqIFJFOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQt aWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMQ0KPiA+PiAqSW1wb3J0YW5jZToqIExvdw0KPiA+Pg0K PiA+PiBJIHRoaW5sIHdlIG1heSB3YW50IHRvIHNlcGFyYXRlIFZNIG1vYmlsaXR5IGZyb20gbW9i aWxlIGRldmljZXMuICBPbQ0KPiA+PiB0aGUgVk0gY2FzZSwgYW0gZW50aXJlIHNldHZpY2UgbmV0 d29yayBtYXkgYmUgbW92ZWQgdG8gdGhlIGRhdGENCj4gPj4gY2VudGVyLCBhbmQgc28gdGhlIEVJ RCBibG9jayBmb3IgdGhhdCBzZXQgY2FuIGJlIG1vdmVkLiAgSW4gdGhlIGNhc2UNCj4gPj4gb2Yg aW5kaXZpZHVhbGx5IG1vYmlsZSBkZWJpY2VzIG9yIHNvbWUgdmF0aWF0aW9ucyBvbiBkYXRhIGNl bnRlcg0KPiA+PiBtb2JpbGl0eSwgdGhlcmUgaXMgYSBuZWVkIHRvIG1za2Ugc3VyZSB0aGUgZnVs bCBFSUQgaXMgYWR2ZXJ0aXNlZCBpbg0KPiA+PiB0aGUgbWFwcGluZyBzeXN0ZW0uDQo+ID4+DQo+ ID4+IFlvdXJzLA0KPiA+Pg0KPiA+PiBKb2VsDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFNlbnQg ZnJvbSBteSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmVA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiAtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tDQo+ID4+IFN1YmplY3Q6 IFJFOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlv bi0xMQ0KPiA+PiBGcm9tOiAiQmxhY2ssIERhdmlkIiA8ZGF2aWQuYmxhY2tAZW1jLmNvbSA8bWFp bHRvOmRhdmlkLmJsYWNrQGVtYy5jb20+Pg0KPiA+PiBUbzogImFjYWJlbGxvQGFjLnVwYy5lZHUg PG1haWx0bzphY2FiZWxsb0BhYy51cGMuZWR1PiINCj4gPj4gPGFjYWJlbGxvQGFjLnVwYy5lZHUg PG1haWx0bzphY2FiZWxsb0BhYy51cGMuZWR1Pj4NCj4gPj4gQ0M6IERpbm8gRmFyaW5hY2NpIDxm YXJpbmFjY2lAZ21haWwuY29tDQo+ID4+IDxtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbT4+LCJK b2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+IDxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT4+LERhbWllbiBTYXVjZXogPGRhbWllbi5zYXVjZXpAaW5yaWEuZnINCj4g Pj4gPG1haWx0bzpkYW1pZW4uc2F1Y2V6QGlucmlhLmZyPj4sIm9wcy1kaXJAaWV0Zi5vcmcNCj4g Pj4gPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPiIgPG9wcy1kaXJAaWV0Zi5vcmcNCj4gPj4gPG1h aWx0bzpvcHMtZGlyQGlldGYub3JnPj4sImlldGZAaWV0Zi5vcmcgPG1haWx0bzppZXRmQGlldGYu b3JnPiINCj4gPj4gPGlldGZAaWV0Zi5vcmcgPG1haWx0bzppZXRmQGlldGYub3JnPj4sImxpc3BA aWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpsaXNwQGlldGYub3JnPiIgPGxpc3BAaWV0Zi5vcmcgPG1h aWx0bzpsaXNwQGlldGYub3JnPj4sIkJsYWNrLA0KPiA+PiBEYXZpZCIgPGRhdmlkLmJsYWNrQGVt Yy5jb20gPG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4NCj4gPj4NCj4gPj4gSGkgQWxiZXJ0 LA0KPiA+Pg0KPiA+PiBBcyBub3RlZCBiZWxvdywgb24gdGhlIEVJRCBwcmVmaXggZm9yIG1vYmls aXR5IGlzc3VlLCBhIHNpbXBsZQ0KPiA+PiBzdGF0ZW1lbnQgaW4gU2VjdGlvbiA1IHRvIHRoZSBl ZmZlY3QgdGhhdCDigJxpbiB0aGUgc3BlY2lmaWMgY2FzZSBvZiBhDQo+ID4+IFZNL21vYmlsZSBu b2RlIHRoZSBFSUQtcHJlZml4IHNob3VsZCBiZSAvMzIgb3IgLzEyOCAoSVB2NCBvciBJUHY2DQo+ ID4+IHJlc3BlY3RpdmVseSnigJ0gd2lsbCBzdWZmaWNlLiAgRGV0YWlscyBvbiB3aGF0IHRvIGRv IHdoZW4gdGhhdCBhZHZpY2UNCj4gPj4gaXMgaWdub3JlZCBjYW4gYmUgbGVmdCB0byBvdGhlciBk b2N1bWVudHMuDQo+ID4+DQo+ID4+IFRoYW5rcywNCj4gPj4gLS1EYXZpZA0KPiA+Pg0KPiA+PiAq RnJvbToqQWxiZXJ0IENhYmVsbG9zIFttYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdtYWlsLmNvbV0N Cj4gPj4gKlNlbnQ6KiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE1IDY6MzMgUE0NCj4gPj4g KlRvOiogQmxhY2ssIERhdmlkDQo+ID4+ICpDYzoqIERpbm8gRmFyaW5hY2NpOyBKb2VsIE0uIEhh bHBlcm47IERhbWllbiBTYXVjZXo7IG9wcy1kaXJAaWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpvcHMt ZGlyQGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZyA8bWFpbHRvOmlldGZAaWV0Zi5vcmc+Ow0KPiA+ PiBsaXNwQGlldGYub3JnIDxtYWlsdG86bGlzcEBpZXRmLm9yZz4NCj4gPj4gKlN1YmplY3Q6KiBS ZTogW2xpc3BdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24t MTENCj4gPj4NCj4gPj4gSGkgRGF2aWQNCj4gPj4NCj4gPj4gVGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLCBJIGFtIHBhcnNpbmcgdGhlbSBhbmQgScK0bGwgc3VnZ2VzdCBuZXcgdGV4dA0KPiA+PiBh aW1pbmcgdG8gYWRkcmVzcyB0aGVtIEFTQVAuDQo+ID4+DQo+ID4+IEkgd291bGQgYWxzbyBsaWtl IHRvIGJldHRlciB1bmRlcnN0YW5kIFtBXSBiZWZvcmUgZG9pbmcgdGhpcy4NCj4gPj4NCj4gPj4g V2l0aCBMSVNQIGFuIEVJRC1wcmVpZnggY2FuIGhhdmUgYW4gYXJiaXRyYXJ5IGxlbmd0aCBhbmQg Y2FuIG1vdmUNCj4gPj4gKGkuZS4sIGNoYW5nZSBpdHMgUkxPQyBiaW5kaW5ncyksIGluIHRoZSBz cGVjaWZpYyBjYXNlIG9mIGEgVk0vbW9iaWxlDQo+ID4+IG5vZGUgdGhlIEVJRC1wcmVmaXggc2hv dWxkIGJlIC8zMiBvciAvMTI4IChJUHY0IG9yIElQdjYgcmVzcGVjdGl2ZWx5KS4NCj4gPj4gV2hh dCBkb2Vzbid0IHdvcmsgaXMgdGhlIG1vYmlsaXR5IG9mIGEgbm9kZSAoYXNzaWduZWQgd2l0aCBh IC8zMiBvcg0KPiA+PiAvMTI4KSAqd2l0aGluKiBhIGNvYXJzZXIgRUlELXByZWZpeCwgaW4gdGhp cyBjYXNlIHlvdSBuZWVkIHRvIHNwbGl0DQo+ID4+IHRoZSBwcmVmaXggaW50byBtb3JlIHNwZWNp ZmljcyBhbmQgcmVnaXN0ZXIgdGhlbSBpbmRlcGVuZGVudGx5IGluIHRoZQ0KPiA+PiBNYXBwaW5n IFN5c3RlbSwgZWZmZWN0aXZlbHkgY3JlYXRpbmcgbmV3IEVJRC1wcmVmaXhlcy4NCj4gPj4NCj4g Pj4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgY2xhcmlmaWVzIHlvdXIgY29tbWVudCwgaW4g dGhpcyBjYXNlIEkgd2lsbA0KPiA+PiBzdWdnZXN0IG5ldyB0ZXh0IGZvciBTZWN0aW9uIDUuDQo+ ID4+DQo+ID4+IEFsYmVydA0KPiA+Pg0KPiA+PiBPbiBUaHUsIEZlYiAxMiwgMjAxNSBhdCAxMjow NyBBTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tDQo+ID4+IDxtYWlsdG86ZGF2 aWQuYmxhY2tAZW1jLmNvbT4+IHdyb3RlOg0KPiA+Pg0KPiA+PiBEaW5vIC0gdGhhbmtzIGZvciB0 aGUgcmVzcG9uc2UuDQo+ID4+DQo+ID4+IE9uIHRoZSBtYWpvciBpc3N1ZXMsIGl0IGxvb2tzIGxp a2UgYm90aCBbQV0gYW5kIFtCXSBpbnZvbHZlIG9ubHkgdGhlIHRleHQNCj4gPj4gaW4gdGhpcyBk cmFmdCBhbmQgbm90aGluZyBiZXlvbmQsIHdoaWNoIGlzIGdvb2QgbmV3cy4gIEkgaGF2ZSBhIHNp bXBsZQ0KPiA+PiB0ZXh0DQo+ID4+IHN1Z2dlc3Rpb24gZm9yIFtBXSwgYnV0IGl0IGxvb2tzIGxp a2UgW0JdIGlzIGdvaW5nIHRvIHJlcXVpcmUgc29tZSBjYXJlZnVsDQo+ID4+IGVkaXRpbmcsIGFz IG9uZSBvZiB0aGUgcHJpbWFyeSBjYXVzZXMgaXMgdGhhdCB0aGUgZHJhZnQgaXMgc2xvcHB5IGlu IHVzaW5nDQo+ID4+IHRoZSBzYW1lIHN5bWJvbCAiRyIgdG8gcmVwcmVzZW50IGJvdGggRUlEIGFu ZCBSTE9DIG11bHRpY2FzdCBncm91cHMuDQo+ID4+DQo+ID4+IE9uIHRoZSBtaW5vciBpc3N1ZXMs IEkgaGF2ZSB0ZXh0IHN1Z2dlc3Rpb25zIGZvciB0aHJlZSBvZiB0aGUgZm91ciwgYW5kDQo+ID4+ IEknZCBsaWtlIHRvIHRlbXBvcmFyaWx5IGRlZmVyIGZ1cnRoZXIgZGlzY3Vzc2lvbiB0aGUgSVB2 NiBVRFAgemVybw0KPiA+PiBjaGVja3N1bSAidGFycGl0IiBpbiBmYXZvciBvZiByZXNvbHZpbmcg ZXZlcnl0aGluZyBlbHNlIGZpcnN0Lg0KPiA+Pg0KPiA+PiBPbiB0aGUgbml0cy9lZGl0b3JpYWwg Y29tbWVudHMsIGFsbCB0aGUgc3VnZ2VzdGlvbnMgaW4geW91ciBlbWFpbCBhcmUgZmluZQ0KPiA+ PiB3aXRoIG1lLiAgRldJVywgSSByZWdhcmQgdGhhdCBwb3J0aW9uIG9mIGEgcmV2aWV3IGFzIGFs bW9zdCBlbnRpcmVseQ0KPiA+PiBzdWJqZWN0IHRvIHRoZSBkcmFmdCBhdXRob3JzJyBkaXNjcmV0 aW9uIChhbmQgZWRpdG9yaWFsIHRhc3RlKS4NCj4gPj4NCj4gPj4gPiA+PiBbQV0gRUlEIG1vYmls aXR5IHZzLiBFSUQgcHJlZml4ZXMNCj4gPj4gPg0KPiA+PiA+IC4uLiBmcm9tIHRoZSBzdGFydCBv ZiB0aGUgTElTUCBkZXNpZ24gKGNpcmNhIDIwMDcpLCBhbiBwcmVmaXggaXMNCj4gPj4gd2hhdCBt b3Zlcy4NCj4gPj4gPiBBbmQgYSBzcGVjaWZpYyBFSUQgaXMgc2ltcGx5IGEgLzMyIG9yIC8xMjgg cHJlZml4LiBIZXJlIGlzIGEgcHJhY3RpY2FsDQo+ID4+ID4gZXhhbXBsZToNCj4gPj4NCj4gPj4g QSBzdGF0ZW1lbnQgdGhhdCB0aGUgbW9iaWxpdHkgdXNlIGNhc2VzIG5lZWQgdG8gZW1wbG95IC8z MiBhbmQgLzEyOA0KPiA+PiBwcmVmaXhlcywNCj4gPj4gYW5kIG5vdCBhbnl0aGluZyBjb2Fyc2Vy IHNob3VsZCBzdWZmaWNlLiAgVGhhdCBzaG91bGQgYmUgYWRkZWQgdG8NCj4gPj4gU2VjdGlvbiA1 Lg0KPiA+Pg0KPiA+PiA+ID4+IFtCXSBMSVNQIE11bHRpY2FzdCB2cy4gRUlEL1JMT0Mgc2VwYXJh dGUNCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IC0gNi4gTXVsdGljYXN0DQo+ID4+ID4gPj4NCj4gPj4g PiA+PiBUaGlzIGlzIGludGVyZXN0aW5nLCBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBsb29rIGxp a2UgdGhleSdyZSBhbg0KPiA+PiBleGNlcHRpb24NCj4gPj4gPg0KPiA+PiA+IFRoZXkgYXJlIHJl YWxseSBub3QuDQo+ID4+DQo+ID4+IE15IGNvbmNlcm4gaXMgdGhhdCBhcyBJIHJlYWQgdGhlIGRy YWZ0LCBpdCBsZWF2ZXMgbWUgd2l0aCB0aGUgc3Ryb25nDQo+ID4+IGltcHJlc3Npb24NCj4gPj4g dGhhdCB0aGUgc2FtZSBtdWx0aWNhc3QgYWRkcmVzc2VzIChHKSBhcmUgYmVpbmcgdXNlZCBpbiBi b3RoIHRoZSBvdmVybGF5DQo+ID4+IChhcyBFSURzKSBhbmQgdGhlIHVuZGVybGF5IChhcyBSTE9D cykuICBGcm9tIHlvdXIgcmVzcG9uc2UsIEkgY29uY2x1ZGUNCj4gPj4gdGhhdCB0aGlzDQo+ID4+ IGlzIG5vdCB0aGUgY2FzZSAoYW5kIEkgaGF2ZSBubyBhcmd1bWVudCB3aXRoIHRoYXQpLiAgUmF0 aGVyLCBTZWN0aW9uIDYNCj4gPj4gbmVlZHMgdG8NCj4gPj4gYmx1bnRseSBzdGF0ZSB0aGF0IG11 bHRpY2FzdCBhZGRyZXNzZXMgYXJlIG1hcHBlZCBiZXR3ZWVuIEVJRCBhbmQgUkxPQw0KPiA+PiBz cGFjZSBhdA0KPiA+PiBib3RoIElUUnMgYW5kIEVUUnMsIHNvIHRoYXQgdGhlIGZvbGxvd2luZyBp bmZlcmVuY2UgaXMgb2J2aW91cyBmcm9tDQo+ID4+IHRoZSB0ZXh0DQo+ID4+IChpdCdzIGN1cnJl bnRseSBub3Qgb2J2aW91cyk6DQo+ID4+DQo+ID4+ID4gU28gaXQgbWFrZXMgcGVyZmVjdCBzZW5z ZSB0byByZWdpc3RlciBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIHRoZSBtYXBwaW5nDQo+ID4+ID4g c3lzdGVtIGFzIEVJRHMgYW5kIHRoZXkgY2FuIG1hcCB0byBSTE9DcyBvZiBzaXRlcyB0aGF0IGhh dmUgam9pbmVkDQo+ID4+IHRoZSBncm91cC4NCj4gPj4NCj4gPj4gQXMgcGFydCBvZiB0aGlzLCBJ IHN0cm9uZ2x5IHJlY29tbWVuZCBtb3ZpbmcgYXdheSBmcm9tIHVzZSBvZiAiRyIgdG8NCj4gPj4g cmVmZXIgdG8NCj4gPj4gbXVsdGljYXN0IGdyb3VwcyBpbiBib3RoIHRoZSBvdmVybGF5IGFuZCB1 bmRlcmxheS4gIENhcmVmdWwgdXNlIG9mIEctRUlEDQo+ID4+IGFuZCBHLVJMT0Mgd291bGQgc2ln bmlmaWNhbnRseSBpbXByb3ZlIGNsYXJpdHkuDQo+ID4+DQo+ID4+IC0tLQ0KPiA+PiBJZiB0aGUg YWJvdmUgYXJlIGRvbmUgZm9yIFtBXSBhbmQgW0JdIGluIFNlY3Rpb25zIDUgYW5kIDYsIHRoZW4g dGhlDQo+ID4+IHRleHQgZm9yIHRoZQ0KPiA+PiB1c2UgY2FzZXMgaW4gU2VjdGlvbiA3IHNob3Vs ZCBub3QgbmVlZCBmdXJ0aGVyIGF0dGVudGlvbi4NCj4gPj4gLS0tDQo+ID4+DQo+ID4+ID4gPj4g LS0gTWlub3IgSXNzdWVzIC0tDQo+ID4+ID4gPj4NCj4gPj4gPiA+PiBUaGVyZSBzZWVtcyB0byBi ZSBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIHRoYXQgdGhlIGVuZCBob3N0IGFuZCBpdHMNCj4gPj4g PiA+PiBJVFIgKHhUUikgYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBvciBBdXRvbm9tb3VzIFN5c3Rl bS4gIEZvcg0KPiA+PiBpbmNyZW1lbnRhbA0KPiA+PiA+DQo+ID4+ID4gVGhpcyBpcyB0cnVlIHdo ZW4geW91IGNhbGwgdGhlIGRvbWFpbiBhICJMSVNQIHNpdGUiLiBCdXQgaWYgdGhlIHNpdGUgaXMN Cj4gPj4gPiB1bmNoYW5nZWQgYW5kIG9uZSB1c2VzIFBJVFJzLCBtYXliZSBldmVuIGNsb3NlIHRv IHRoZSBzaXRlLCBsaWtlIGluIGEgUEUNCj4gPj4gPiByb3V0ZXIsIHRoZW4gdGhlIFBJVFIgaXMg ZGVmaW5pdGVseSBpbiBhbm90aGVyIEFTLg0KPiA+Pg0KPiA+PiBMb29raW5nIGF0IHRoZSB0ZXh0 LCBpdCBzZWVtcyB0aGF0ICJMSVNQIHNpdGUiIGFuZCAiZG9tYWluIiBhcmUgdGhlIHNhbWUNCj4g Pj4gY29uY2VwdCBmb3IgdGhpcyBkcmFmdC4gIFRoYXQgd291bGQgYmUgdXNlZnVsIHRvIHN0YXRl LCBJTUhPIGJ1dCBJJ2xsDQo+ID4+IGxlYXZlDQo+ID4+IHRoZSBkZWNpc2lvbiBvbiB3aGV0aGVy IHRvIGRvIHNvIHRvIHlvdSBhbmQgdGhlIGRyYWZ0IGF1dGhvcnMuDQo+ID4+DQo+ID4+IE9uIHJl cmVhZGluZywgbXkgY29uY2VybnMgc2VlbSB0byBiZSB0cmlnZ2VyZWQgbW9zdGx5IGJ5IHRoaXMg c2VudGVuY2UgaW4NCj4gPj4gU2VjdGlvbiAzLjI6DQo+ID4+DQo+ID4+ICAgIFRoZSBlZGdlIGNv bnNpc3RzIG9mIExJU1Agc2l0ZXMgKGUuZy4sIGFuDQo+ID4+ICAgIEF1dG9ub21vdXMgU3lzdGVt KSB0aGF0IHVzZSBFSUQgYWRkcmVzc2VzLg0KPiA+Pg0KPiA+PiBJIHRoaW5rIGEgc21hbGwgY2hh bmdlIHRvIHRoZSBsYXN0IHNlbnRlbmNlIGluIHRoYXQgcGFyYWdyYXBoIHdvdWxkDQo+ID4+IHJl c29sdmUNCj4gPj4gbXkgY29uY2VybiB3aXRob3V0IGRpc3RyYWN0aW5nIGZyb20gdGhlIG5hcnJh dGl2ZToNCj4gPj4NCj4gPj4gT0xEDQo+ID4+ICAgIEVJRHMgZG8gbm90DQo+ID4+ICAgIGNvbnRh aW4gaW50ZXItZG9tYWluIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIGFuZCBiZWNhdXNlIG9mIHRo aXMsDQo+ID4+ICAgIEVJRHMgYXJlIHVzdWFsbHkgcm91dGFibGUgYXQgdGhlIGVkZ2UgKHdpdGhp biBMSVNQIHNpdGVzKSBvciBpbiB0aGUNCj4gPj4gICAgbm9uLUxJU1AgSW50ZXJuZXQuDQo+ID4+ IE5FVw0KPiA+PiAgICBFSURzIGRvIG5vdA0KPiA+PiAgICBjb250YWluIGludGVyLWRvbWFpbiB0 b3BvbG9naWNhbCBpbmZvcm1hdGlvbiBhbmQgYmVjYXVzZSBvZiB0aGlzLA0KPiA+PiAgICBFSURz IGFyZSB1c3VhbGx5IHJvdXRhYmxlIGF0IHRoZSBlZGdlICh3aXRoaW4gTElTUCBzaXRlcykgb3Ig aW4gdGhlDQo+ID4+ICAgIG5vbi1MSVNQIEludGVybmV0OyBzZWUgU2VjdGlvbiAzLjUgZm9yIGRp c2N1c3Npb24gb2YgTElTUCBzaXRlDQo+ID4+ICAgIGludGVybmV0d29ya2luZyB3aXRoIG5vbi1M SVNQIHNpdGVzIGFuZCBkb21haW5zIGluIHRoZSBJbnRlcm5ldC4NCj4gPj4NCj4gPj4gPiA+PiBE ZXNwaXRlIG11bHRpcGxlICBtZW50aW9ucyBvZiBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LCBJIGRp ZCBub3QNCj4gPj4gPiA+PiBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGF0IG1pZ2h0IGJlIGFj Y29tcGxpc2hlZC4NCj4gPj4gPg0KPiA+PiA+IFRoZXJlIGFyZSBQeFRScyBhbmQgTkFUcy4gQW5k IHJlZmVyZW5jZXMgdG8gdGhlIExJU1AgaW50ZXJ3b3JraW5nIFJGQy4NCj4gPj4NCj4gPj4gT2ss IGNhbiB3ZSBqdXN0IHNheSBzbyBpbiBTZWN0aW9uIDMuNT8gIEFkZGluZyB0aGUgZm9sbG93aW5n IHNlbnRlbmNlDQo+ID4+IHRvIHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24gd291bGQgc3VmZmljZToN Cj4gPj4NCj4gPj4gICAgUElUUnMsIFBFVFJzIGFuZCBMSVNQLU5BVCBzdXBwb3J0IGluY3JlbWVu dGFsIGRlcGxveW1lbnQgb2YgTElTUA0KPiA+PiAgICBieSBwcm92aWRpbmcgc2lnbmlmaWNhbnQg ZmxleGliaWxpdHkgaW4gbG9jYXRpb24gb2YgdGhlIGJvdW5kYXJpZXMNCj4gPj4gICAgYmV0d2Vl biB0aGUgTElTUCBhbmQgbm9uLUxJU1AgcG9ydGlvbnMgb2YgdGhlIG5ldHdvcmssIGFuZCBtYWtp bmcNCj4gPj4gICAgaXQgcmVhc29uYWJsZSB0byBjaGFuZ2UgdGhvc2UgYm91bmRhcmllcyBvdmVy IHRpbWUuDQo+ID4+DQo+ID4+ID4gPj4gLSAzLjMuMS4gIExJU1AgRW5jYXBzdWxhdGlvbg0KPiA+ PiA+ID4+DQo+ID4+ID4gPj4gICAgdGhlIHNvdXJjZSBwb3J0IGlzIHNlbGVjdGVkIGJ5DQo+ID4+ ID4gPj4gICAgdGhlIElUUiBhbmQgaWdub3JlZCBvbiByZWNlcHRpb24uDQo+ID4+ID4gPj4NCj4g Pj4gPiA+PiBQbGVhc2UgbWVudGlvbiBtdWx0aXBhdGhpbmcgKGUuZy4sIEVDTVAgYW5kIExBRykg YXMgcG9zc2libGUNCj4gPj4gaW5mbHVlbmNlcw0KPiA+PiA+ID4+IG9uIGhvdyBzb3VyY2UgcG9y dHMgYXJlIHNlbGVjdGVkLCBhcyB0aGlzIGltcG9zZXMgc29tZSBsaW1pdHMgb24NCj4gPj4gd2hh dCBhbg0KPiA+PiA+ID4+IElUUiBjYW4gcmVhc29uYWJseSBkby4NCj4gPj4gPg0KPiA+PiA+IEVD TVAvTEFHIGRvbid0IGluZmx1ZW5jZSB3aGljaCBzb3VyY2UgcG9ydCBpcyBzZWxlY3RlZC4gSXQg aXMgYQ0KPiA+PiA1LXR1cGxlIGhhc2gNCj4gPj4gPiBvZiB0aGUgaW5uZXIgaGVhZGVyIHRoYXQg c2VsZWN0cyBhIHNvdXJjZSBwb3J0IHRoYXQgaW5mbHVlbmNlcyBob3cNCj4gPj4gYW4gdW5kZXJs YXkNCj4gPj4gPiByb3V0ZXIgd291bGQgbG9hZC1zcGxpdCB0cmFmZmljLg0KPiA+Pg0KPiA+PiBQ bGVhc2Ugc3RhdGUgdGhhdCBhIDUtdHVwbGUgaGFzaCBpcyB1c2VkLiAgRUNNUC9MQUcgaXMgYW1v bmcgdGhlIGltcG9ydGFudA0KPiA+PiByZWFzb25zIHdoeSwgYnV0IHRoYXQgZG9lc24ndCBuZWVk IHRvIGJlIHN0YXRlZCBpZiB5b3UgcHJlZmVyIG5vdCB0by4gIEFuDQo+ID4+IGV4YW1wbGUgb2Yg c29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgZXhjbHVkZWQgaXMgdGhhdCB1c2luZyBhIHJhbmRv bQ0KPiA+PiBudW1iZXIgZ2VuZXJhdG9yIHRvIHNldCB0aGUgc291cmNlIHBvcnQgd291bGQgYmUg d3JvbmcgLSBJIGNvdWxkIHN1Z2dlc3QNCj4gPj4gY2l0aW5nIGRyYWZ0LWlldGYtZGFydC1kc2Nw LXJ0cCBmb3IgcmVsYXRlZCBkaXNjdXNzaW9uIChhbmQgbG90cyBtb3JlDQo+ID4+IGRldGFpbHMp LCBidXQgSSBkb24ndCB0aGluayB0aGF0J3MgbmVjZXNzYXJ5Lg0KPiA+Pg0KPiA+PiAtLSBJUHY2 IHplcm8gVURQIGNoZWNrc3VtDQo+ID4+DQo+ID4+ID4gTXkgaGVhZCBzcGlucyBldmVyeSB0aW1l IEkgaGVhciBhYm91dCB0aGlzIHN1YmplY3QuIFRoaXMgc3ViamVjdCBoYXMNCj4gPj4gYmVlbg0K PiA+PiA+IHRhbGtlZCBhYm91dCBmcm9tIDEwMHMgb2YgcGVvcGxlIGZvciBhIGRlY2FkZS4gV2Ug aGF2ZSBDUkMgb24gbGlua3MsDQo+ID4+IHdlIGhhdmUNCj4gPj4gPiBhcHBzIHRoYXQgdXNlIFRD UCBhbmQgVURQIGNoZWNrc3Vtcy4gTnVmIHNhaWQuDQo+ID4+DQo+ID4+IFVuZGVyc3Rvb2QgLSB0 aGVyZSdzIG1vcmUgdGhhbiBvbmUgc2V0IG9mIHNjYXJzIG9uIHRoaXMgb25lIDotKC4NCj4gPj4g TGV0J3MgY29tZSBiYWNrDQo+ID4+IHRvIHRoaXMgdG9waWMgYWZ0ZXIgd2UndmUgcmVzb2x2ZWQg ZXZlcnl0aGluZyBlbHNlLCBhbmQgcGxlYXNlIGtlZXAgaW4NCj4gPj4gbWluZA0KPiA+PiB0aGF0 IEkgdGFnZ2VkIHRoaXMgYXMgYSBtaW5vciBpc3N1ZSwgbm90IGEgbWFqb3Igb25lIChlLmcuLCB0 aGUgYWJvdmUNCj4gPj4gY2hhbmdlcw0KPiA+PiBmb3IgW0FdIGFuZCBbQl0gYXJlIGZhciBtb3Jl IGltcG9ydGFudCwgSU1ITykuDQo+ID4+DQo+ID4+IFRoYW5rcywNCj4gPj4gLS1EYXZpZA0KPiA+ Pg0KPiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4gRnJvbTogRGlubyBG YXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tDQo+IDxtYWlsdG86ZmFyaW5hY2Np QGdtYWlsLmNvbT5dDQo+ID4+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSAy OjE5IFBNDQo+ID4+ID4gVG86IEpvZWwgTS4gSGFscGVybg0KPiA+PiA+IENjOiBCbGFjaywgRGF2 aWQ7IEFsYmVydCBDYWJlbGxvczsgRGFtaWVuIFNhdWNlejtvcHMtZGlyQGlldGYub3JnDQo+IDxt YWlsdG86b3BzLWRpckBpZXRmLm9yZz47DQo+ID4+ID5pZXRmQGlldGYub3JnIDxtYWlsdG86aWV0 ZkBpZXRmLm9yZz47IGxpc3BAaWV0Zi5vcmcgPG1haWx0bzpsaXNwQGlldGYub3JnPg0KPiA+PiA+ IFN1YmplY3Q6IFJlOiBbbGlzcF0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWlu dHJvZHVjdGlvbi0xMQ0KPiA+PiA+DQo+ID4+DQo+ID4+ID4gPiBJIHdpbGwgbGVhdmUgbW9zdCBv ZiB0aGVzZSBmb3IgdGhlIGF1dGhvcnMgdG8gY29tbWVudCBvbi4NCj4gPj4gPg0KPiA+PiA+IFNl ZSBteSBjb21tZW50cyBpbmxpbmUuIFRoYW5rcyBEYXZpZCBmb3IgeW91ciBkZXRhaWxlZCByZXZp ZXcgYW5kDQo+ID4+IGNvbW1lbnRhcnkuDQo+ID4+ID4NCj4gPj4gPiA+IFdpdGggcmVnYXJkIHRv IHlvdXIgcXVlc3Rpb24gYWJvdXQgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgdGhhdCBpcyB0aGUN Cj4gPj4gPiBkb21haW4gb2YgdGhlIExJU1AgRGVwbG95bWVudCBkb2N1bWVudCwgYW5kIHdhcyBk ZWxpYmVyYXRlbHkgb25seQ0KPiA+PiBsaWdodGx5DQo+ID4+ID4gY292ZXJlZCBoZXJlLiAgSSBh bSBub3Qgc3VyZSB3aGF0IHdlIGNhbiBkbyB0byBhZGRyZXNzIHlvdXIgY29tbWVudA0KPiA+PiB3 aXRob3V0DQo+ID4+ID4gZHVwbGljYXRpbmcgdGhlIGVudGlyZXR5IG9mIHRoYXQgZG9jdW1lbnQu DQo+ID4+ID4NCj4gPj4gPiBUaGF0IGlzIHRoZSByaXNrIHdlIG1heSBoYXZlIHdpdGggbWFueSBv ZiB5b3VyIGNvbW1lbnRzLiBXZSBoYXZlIGENCj4gPj4gbG90IG9mDQo+ID4+ID4gZGV0YWlsIGlu IHRoZSBhbHJlYWR5IDkgcHVibGlzaGVkIFJGQ3MgIGFuZCB0aGlzIGRvY3VtZW50IHJlYWxseSBp cw0KPiA+PiB0byB0YWtlDQo+ID4+ID4gYWxsIHRoYXQgZGV0YWlsIGFuZCBzdW1tYXJpemUgYXMg YW4gZWFzaWx5IHVuZGVyc3RhbmRhYmxlDQo+ID4+IGRlc2NyaXB0aW9uIG9mIGENCj4gPj4gPiBj b2hlc2l2ZSBkZXNpZ24uDQo+ID4+ID4NCj4gPj4gPiA+IFdpdGggcmVnYXJkIHRvIFVEUCBaZXJv LCB0aGlzIHdhcyBhcHByb3ZlZCBieSB0aGUgSUVTRyBhbmQNCj4gPj4gcHVibGlzaGVkIGFzIGFu DQo+ID4+ID4gUkZDLiAgSXQgaXMgcGFydCBvZiB0aGUgd2F5IHRoZSBwcm90b2NvbCBpcyBkZWZp bmVkLiAgSWYgdGhlcmUgYXJlDQo+ID4+IHNwZWNpZmljDQo+ID4+ID4gY2hhbmdlcyB5b3Ugd291 bGQgbGlrZSB0byBzZWUgaW4gdGhlIGV4cGxhbmF0b3J5IHRleHQsIEkgYW0gc3VyZQ0KPiA+PiA+ DQo+ID4+ID4gRGVmaW5pdGVseSBhZ3JlZWQuIEluIGZhY3Qgd2UgaW5zdGlnYXRlZCBVRFAgemVy by4gQW5kIEkgY29udGludWFsbHkNCj4gPj4gdGFsayB0bw0KPiA+PiA+IGhhcmR3YXJlIGVuZ2lu ZWVycyBhbmQgdGhleSBhbGwgYmVsaWV2ZSB3ZSBtYWRlIHRoZSByaWdodCBkZWNpc2lvbi4NCj4g Pj4gU28gaGF0cw0KPiA+PiA+IG9mZiB0byB0aGUgSUVURiBmb3IgYmVpbmcgcHJhY3RpY2FsLg0K PiA+PiA+DQo+ID4+ID4gPiB3ZSBjb3VsZCBpbmNsdWRlIHRoZW0uICBJZiB5b3UgYXJlIGxvb2tp bmcgZm9yIGEgY2hhbmdlIGluIHRoZQ0KPiA+PiBiZWhhdmlvciwNCj4gPj4gPiB0aGlzIGRvY3Vt ZW50IGNhbiBub3QgbWFrZSBjaGFuZ2VzIHRvIHRoZSBMSVNQIGJlaGF2aW9yLg0KPiA+PiA+DQo+ ID4+ID4gWWVzLCBhbiBpbXBvcnRhbnQgcG9pbnQuDQo+ID4+ID4NCj4gPj4gPiA+PiBJIGZvdW5k IGEgY291cGxlIG9mIG1ham9yIGlzc3VlcyB0aGF0IEkgaG9wZSBhcmlzZSBmcm9tIHRoZQ0KPiA+ PiA+ID4+IHN1bW1hcml6YXRpb24gb2YgTElTUCBpbiB0aGlzIGRyYWZ0LCBhcyBvcHBvc2VkIHRv IGJlaW5nIHByb2JsZW1zIGluDQo+ID4+ID4gPj4gdGhlIGFjdHVhbCBMSVNQIHByb3RvY29scy4g IEkgYWxzbyBmb3VuZCBhIGZldyBtaW5vciBpc3N1ZXMsIHRoZSBtb3N0DQo+ID4+ID4gPj4gaW1w b3J0YW50IG9mIHdoaWNoIGlzIHRoZSBuZWVkIGZvciBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zDQo+ID4+ID4gPj4gZGlzY3Vzc2lvbiBvbiBtaXNkZWxpdmVyeSwgd2l0aCBwYXJ0 aWN1bGFyIGF0dGVudGlvbiB0byBWUE5zLg0KPiA+PiA+DQo+ID4+ID4gVGhhbmtzIGEgdG9uLg0K PiA+PiA+DQo+ID4+ID4gPj4gLS0gTWFqb3IgaXNzdWVzIC0tDQo+ID4+ID4gPj4NCj4gPj4gPiA+ PiBbQV0gRUlEIG1vYmlsaXR5IHZzLiBFSUQgcHJlZml4ZXMNCj4gPj4gPiA+Pg0KPiA+PiA+ID4+ IC0gNS4gTW9iaWxpdHkNCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IEkgdW5kZXJzdGFuZCBob3cgdGhp cyB3b3JrcyB3aGVuIG1hcHBpbmcgaXMgcGVyLUVJRCwgYnV0IGhvdyBkb2VzDQo+ID4+IHRoaXMg d29yaw0KPiA+PiA+ID4+IHdoZW4gdGhlIEVJRCBvZiB0aGUgc3lzdGVtIHRoYXQgbW92ZXMgaXMg cGFydCBvZiBhbiBFSUQgcHJlZml4LCBhcw0KPiA+PiA+IGRpc2N1c3NlZA0KPiA+PiA+ID4+IGlu IFNlY3Rpb24gMy40LjE/ICBFdmVuIGlmIHRoZSBhbnN3ZXIgaXMgYSBsb25nIHZlcnNpb24gb2Yg IkRvbid0DQo+ID4+IGRvIHRoYXQhIg0KPiA+PiA+ID4+IGl0IHNob3VsZCBiZSBleHBsYWluZWQu DQo+ID4+ID4NCj4gPj4gPiBObywgZnJvbSB0aGUgc3RhcnQgb2YgdGhlIExJU1AgZGVzaWduIChj aXJjYSAyMDA3KSwgYW4gcHJlZml4IGlzDQo+ID4+IHdoYXQgbW92ZXMuDQo+ID4+ID4gQW5kIGEg c3BlY2lmaWMgRUlEIGlzIHNpbXBseSBhIC8zMiBvciAvMTI4IHByZWZpeC4gSGVyZSBpcyBhIHBy YWN0aWNhbA0KPiA+PiA+IGV4YW1wbGU6DQo+ID4+ID4NCj4gPj4gPiBZb3UgaGF2ZSBhIGNsdXN0 ZXIgb2Ygc2VydmVycyB0aGF0IGNvbW11bmljYXRlIHRvZ2V0aGVyIGZvciBhIHBhcnRpY3VsYXIN Cj4gPj4gPiBhcHBsaWNhdGlvbi4gVGhleSBhcHBsaWNhdGlvbiBjbHVzdGVyIGlzIHJ1bm5pbmcg aW4gYSBzZXQgb2YgVk1zLg0KPiA+PiBUaG9zZSBWTXMNCj4gPj4gPiBhcmUgYXNzaWduZWQgRUlE cyBmcm9tIGEgY29tbW9uIHBvd2VyLW9mLTIgRUlELXByZWZpeC4gVGhvc2UgVk1zIGFyZQ0KPiA+ PiBjdXJyZW50bHkNCj4gPj4gPiBydW5uaW5nIGluIGEgYnJpY2stYW5kLW1vcnRhciBkYXRhIGNl bnRlci4gTm93IHRoZXJlIGlzIGEgZGVzaXJlIHRvDQo+ID4+IG1vdmUgdGhlDQo+ID4+ID4gVk0g Y2x1c3RlciB0byBhIGNsb3VkIHByb3ZpZGVyLiBXaGF0IGlzIG1vdmVkIGlzIHRoZSBFSUQtcHJl Zml4IG9mIHRoZQ0KPiA+PiA+IGNsdXN0ZXIuIFRoZSBtYXBwaW5nIHN5c3RlbSBpcyB0b2xkIHRo YXQgdGhlIEVJRC1wcmVmaXggaXMgY2hhbmdpbmcNCj4gPj4gaXRzIFJMT0MtDQo+ID4+ID4gc2V0 IGZyb20gdGhlIGJyaWNrLWFuZC1tb3J0YXIgeFRScyB0byB0aGUgY2xvdWQgcHJvdmlkZXJzIHhU UnMuDQo+ID4+ID4NCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IC0gNy40LiAgTElTUCBmb3IgVmlydHVh bCBNYWNoaW5lIE1vYmlsaXR5IGluIERhdGEgQ2VudGVycw0KPiA+PiA+ID4+DQo+ID4+ID4gPj4g SSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGlzIHdvcmtzIHdoZW4gRUlEIHByZWZpeGVzIGFyZSB1 c2VkLCBhcw0KPiA+PiBlYWNoIFZNDQo+ID4+ID4gPj4gaGFzIGl0cyBvd24gRUlEIG9yIEVJRHMs IGhlbmNlIHRoZSBlbnRpcmUgcHJlZml4IHJhbmdlIGRvZXMgbm90DQo+ID4+IG1vdmUgd2hlbg0K PiA+PiA+ID4+IHRoZSBWTSBtb3Zlcy4NCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IEZvciBPUFMtRGly LCB0aGlzIEVJRCBwcmVmaXggaXNzdWUgW0FdIGZhbGxzIHVuZGVyIEEuMS4xIGluDQo+ID4+IEFw cGVuZGl4IEENCj4gPj4gPiA+PiBvZiBSRkMgNTcwNjogIEhhcyBkZXBsb3ltZW50IGJlZW4gZGlz Y3Vzc2VkPyBhbmQgc3BlY2lmaWNhbGx5IHVuZGVyOg0KPiA+PiA+ID4+DQo+ID4+ID4gPj4gICAg ICAgICogIElzIHRoZSBwcm9wb3NlZCBzcGVjaWZpY2F0aW9uIGRlcGxveWFibGU/ICBJZiBub3Qs IGhvdw0KPiA+PiBjb3VsZA0KPiA+PiA+ID4+ICAgICAgICAgICBpdCBiZSBpbXByb3ZlZD8NCj4g Pj4gPiA+Pg0KPiA+PiA+ID4+IGFzIEVJRCBwcmVmaXhlcyBhcHBlYXIgdG8gYmUgdW5kZXBsb3lh YmxlIGZvciBNb2JpbGl0eSBhbmQgVk0NCj4gPj4gTW9iaWxpdHkNCj4gPj4gPiB1c2FnZS4NCj4g Pj4gPg0KPiA+PiA+IFNlZSBhYm92ZSBleGFtcGxlLg0KPiA+PiA+DQo+ID4+ID4gPj4gW0JdIExJ U1AgTXVsdGljYXN0IHZzLiBFSUQvUkxPQyBzZXBhcmF0ZQ0KPiA+PiA+ID4+DQo+ID4+ID4gPj4g LSA2LiBNdWx0aWNhc3QNCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IFRoaXMgaXMgaW50ZXJlc3Rpbmcs IG11bHRpY2FzdCBhZGRyZXNzZXMgKEcpIGxvb2sgbGlrZSB0aGV5J3JlIGFuDQo+ID4+IGV4Y2Vw dGlvbg0KPiA+PiA+DQo+ID4+ID4gVGhleSBhcmUgcmVhbGx5IG5vdC4gU2luY2UgbXVsdGljYXN0 IGFkZHJlc3NlcyAqaWRlbnRpZnkqIGEgZ3JvdXAgb2YNCj4gPj4gPiByZWNlaXZlcnMsIGl0IGlz IHZlcnkgbXVjaCBhbiBFSUQgYW5kIGFoZXJlcyB0byB0aGUgZGVmaW5pdGlvbiBvZiBhbg0KPiA+ PiBFSUQuDQo+ID4+ID4gTXVsdGljYXN0IGFkZHJlc3NlcyBuZXZlciBoYWQgdG9wb2xvZ2ljYWwg c2lnbmZpY2FuY2UgYnV0IHRoZSBzdGF0ZQ0KPiA+PiA+IHJlcHJlc2VudGluZyBhIGRpc3RyaWJ1 dGlvbiB0cmVlIGRvZXMgdGVsbCB5b3Ugd2VyZSB0aGUgbWVtYmVycyBhcmUNCj4gPj4gKGJ1dCB0 aGUNCj4gPj4gPiBpZGVudGl0eSBvZiB0aGUgbWVtYmVycyBhcmUgbm90IGtub3cgaW4gbXVsdGlj YXN0KS4NCj4gPj4gPg0KPiA+PiA+IFNvIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gcmVnaXN0 ZXIgbXVsdGljYXN0IGFkZHJlc3NlcyB0byB0aGUgbWFwcGluZw0KPiA+PiA+IHN5c3RlbSBhcyBF SURzIGFuZCB0aGV5IGNhbiBtYXAgdG8gUkxPQ3Mgb2Ygc2l0ZXMgdGhhdCBoYXZlIGpvaW5lZA0K PiA+PiB0aGUgZ3JvdXAuDQo+ID4+ID4gU2VlIGRyYWZ0LWZhcmluYWNjaS1zaWduYWwtZnJlZS1t dWx0aWNhc3QgYXMganVzdCBvbmUgZXhhbXBsZS4NCj4gPj4gUkZDNjgzMSBhbmQNCj4gPj4gPiBk cmFmdC1mYXJpbmFjY2ktbGlzcC1tci1zaWduYWxpbmcgYXJlIG90aGVyIGV4YW1wbGVzLg0KPiA+ PiA+DQo+ID4+ID4gPj4gdG8gdGhlIEVJRC9STE9DIHNlcGFyYXRpb24gYXMgdGhlIHNhbWUgZGVz dGluYXRpb24gSVAgbXVsdGljYXN0DQo+ID4+IGFkZHJlc3MNCj4gPj4gPiA+PiBpcyB1c2VkIGZv ciBib3RoIHB1cnBvc2VzLiAgVGhpcyBjb3VsZCB1c2Ugc29tZSBtb3JlIGRpc2N1c3Npb24sDQo+ ID4+IGFzIGl0J3MNCj4gPj4gPiA+PiB1bmV4cGVjdGVkIGJhc2VkIG9uIHRoZSBjb250ZW50cyBv ZiB0aGUgZHJhZnQgdXAgdG8gdGhpcyBwb2ludC4NCj4gPj4gPg0KPiA+PiA+IEkgYmVsaWV2ZSB0 aGUgbGV2ZWwgb2YgZGV0YWlsIHdlIGhhdmUgaW4gdGhlIGludHJvZHVjdGlvbiBkb2N1bWVudA0K PiA+PiBpcyBhdCB0aGUNCj4gPj4gPiByaWdodCBsZXZlbCBvciB3ZSdsbCBlcnIgb24gaGF2aW5n IHdheSB0b28gbWFueSBkZXRhaWxzIGNyb3AgaW4uDQo+ID4+ID4NCj4gPj4gPiA+PiAtIDcuMi4g IExJU1AgZm9yIElQdjYgQ28tZXhpc3RlbmNlDQo+ID4+ID4gPj4NCj4gPj4gPiA+PiAgICBMSVNQ IGVuY2Fwc3VsYXRpb25zIGFsbG93cyB0byB0cmFuc3BvcnQgcGFja2V0cyB1c2luZyBFSURzIGZy b20gYQ0KPiA+PiA+ID4+ICAgIGdpdmVuIGFkZHJlc3MgZmFtaWx5IChlLmcuLCBJUHY2KSB3aXRo IHBhY2tldHMgZnJvbSBvdGhlciBhZGRyZXNzDQo+ID4+ID4gPj4gICAgZmFtaWxpZXMgKGUuZy4s IElQdjQpLg0KPiA+PiA+ID4+DQo+ID4+ID4gPj4gSG93IGRvZXMgdGhhdCB3b3JrIGZvciBtdWx0 aWNhc3QgdHJhZmZpYywgd2hlcmUgdGhlIGRlc3RpbmF0aW9uDQo+ID4+IGFkZHJlc3MNCj4gPj4g PiA+PiAoRykgaGFzIHRvIGJlIHRoZSBzYW1lIGluIGJvdGggdGhlIGlubmVyIGFuZCBvdXRlciBo ZWFkZXJzPyAgQXJlIEVUUnMNCj4gPj4gPiA+PiBhbmQgSVRScyBleHBlY3RlZCB0byBtYXAgSVB2 NiBtdWx0aWNhc3QgYWRkcmVzc2VzIHRvIElQdjQgYW5kIHYudi4/DQo+ID4+ID4NCj4gPj4gPiBU aGUgbWFwcGluZyBzeXN0ZW0gY2FuIG1hcCBhbiAoUy1FSUQtaXB2NiwgZ3JvdXAtaXB2NikgMi10 dXBsZSB0byBhDQo+ID4+IFJMT0Mgc2V0DQo+ID4+ID4gdGhhdCBsb29rZWQgbGlrZSB0aGlzIChp cHY0LW11bHRpY2FzdCwgaXB2NC11bmljYXN0KSBtZWFuIHRoZSBJVFIgdGhhdA0KPiA+PiA+IHJl Y2VpdmVzIHRoZSBwYWNrZXQgZnJvbSBTLUVJRC1pcHY2IHdvdWxkIHJlcGxpY2F0ZSB0aGUgcGFj a2V0IGFuZA0KPiA+PiBtdWx0aWNhc3QNCj4gPj4gPiBlbmNhcHN1bGF0ZSB0byBpcHY0LW11bHRp Y2FzdCBhbmQgdW5pY2FzdCBlbmNhcHN1YWx0ZSB0byBpcHY0LXVuaWNhc3QuDQo+ID4+ID4NCj4g Pj4gPiA+PiAtIDcuMy4gIExJU1AgZm9yIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3Jrcw0KPiA+PiA+ ID4+DQo+ID4+ID4gPj4gVGhpcyBhbHNvIGhhcyBtdWx0aWNhc3QgcHJvYmxlbXMsIGFzIHRoZXJl IGlzIG9ubHkgb25lIGluc3RhbmNlDQo+ID4+IG9mIGVhY2gNCj4gPj4gPiA+PiBtdWx0aWNhc3Qg YWRkcmVzcyAoRykgaW4gdGhlIHVuZGVybGF5IG5ldHdvcmsuICBJIHRoaW5rIEkgY2FuDQo+ID4+ IGZpZ3VyZSBvdXQNCj4gPj4gPiBob3cNCj4gPj4gPg0KPiA+PiA+IFlvdSBjYW4gbWFwIGZyb20g RUlELUcgdG8gUkxPQy1HIG9uZSB0byBvbmUuIEJ1dCB3ZSBoYXZlIHNlZW4gb3Zlcg0KPiA+PiB0 aGUgbGFzdA0KPiA+PiA+IGRlY2FkZSBpbiBhIGhhbGYgdGhhdCB3aXRoIGdlbmVyYWwgbXVsdGlj YXN0IGRlcGxveW1lbnQgdGhhdA0KPiA+PiBtYW55LXRvLTEgaXMNCj4gPj4gPiBkZXNpcmFibGUu IEhlbmNlLCBub3cgdGhhdCB3ZSBoYXZlIGEgd2F5IHRvIG1hcCB3aXRoIGEgbmV0d29yay1iYXNl ZA0KPiA+PiBkYXRhYmFzZSwNCj4gPj4gPiB3ZSBjYW4gbWFwIG11bHRpcGxlIEVJRC1HcyB0byBh IHNpbmdsZSAob3IgbXVsdGlwbGUpIFJMT0MtR3MuDQo+ID4+ID4NCj4gPj4gPiA+PiB0byBtYWtl IG11bHRpY2FzdCB3b3JrIGZvciB0aGlzIHVzZSBjYXNlLCBidXQgaXQncyBub3QNCj4gPj4gaW1t ZWRpYXRlbHkgb2J2aW91cywNCj4gPj4gPiA+PiBhbmQgdGhlIHJlc3VsdCB3aGVuIHRoZSBzYW1l IHVuZGVybGF5IG11bHRpY2FzdCBhZGRyZXNzIGlzIHVzZWQNCj4gPj4gYnkgbW9yZQ0KPiA+PiA+ ID4+IHRoYW4gb25lIFZQTiBjb3VsZCB3ZWxsIGRlbGl2ZXIgc29tZSB0cmFmZmljIHRvIEVUUnMg dGhhdCBoYXZlIHRvDQo+ID4+IGRpc2NhcmQNCj4gPj4gPg0KPiA+PiA+IFRoaXMgaXMgYSBuZWNl c3NhcnkgZXZpbCB3aGVuIHRoZSB1bmRlcmxheSBpcyBzdGF0ZSBjaGFsbGVuZ2VkLiBCdXQNCj4g Pj4gaXQgaXMgYQ0KPiA+PiA+IHN0YXRlL2JhbmR3aWR0aCB0cmFkZW9mZi4gV2UgaGF2ZSBmb3Vu ZCB3aXRoIE1WUE4gZGVwbG95bWVudCB0aGF0DQo+ID4+IHRoZSBuZXR3b3JrDQo+ID4+ID4gYWRt aW4gY29uZmlndXJlcyB0aGUgdW5kZXJseSBvciBzaW1wbHkgdW5pY2FzdHMuDQo+ID4+ID4NCj4g Pj4gPiA+PiBpdCBiZWNhdXNlIHRoZSBJbnN0YW5jZSBJRCBpcyB3cm9uZyAoYW5kIHRoYXQgZXhj ZXNzaXZlIGRlbGl2ZXJ5IGlzIGENCj4gPj4gPiA+PiBzZWN1cml0eSBjb25zaWRlcmF0aW9uLCBz ZWUgbWlub3IgaXNzdWUgb24gU2VjdGlvbiA4IGJlbG93KS4gIEkNCj4gPj4gdGhpbmsgYW4NCj4g Pj4gPiA+PiBleHBsYW5hdGlvbiBpcyBpbiBvcmRlci4NCj4gPj4gPg0KPiA+PiA+IFRoZXJlIGFy ZSBqdXN0IHRvbyBtYW55IGNvbWJpbmF0aW9ucyB0byBtYWtlIGEgaGlnaC1sZXZlbA0KPiA+PiBk ZXNjcmlwdGlvbiBzaW1wbGUNCj4gPj4gPiB0byB1bmRlcnN0YW5kLiBUaGUgY3VycmVudCBpbnRy b2R1Y3Rpb24gdGV4dCBkb2VzIGEgZmluZCBqb2IgcHJvdmlkaW5nDQo+ID4+ID4gcmVmZXJlbmNl cyBmb3Igc29tZW9uZSB0byBnbyBvZmYgYW5kIGdldCB0aGUgZGV0YWlscy4NCj4gPj4gPg0KPiA+ PiA+ID4+IC0tIE1pbm9yIElzc3VlcyAtLQ0KPiA+PiA+ID4+DQo+ID4+ID4gPj4gVGhlcmUgc2Vl bXMgdG8gYmUgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiB0aGF0IHRoZSBlbmQgaG9zdCBhbmQgaXRz DQo+ID4+ID4gPj4gSVRSICh4VFIpIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3IgQXV0b25vbW91 cyBTeXN0ZW0uICBGb3INCj4gPj4gaW5jcmVtZW50YWwNCj4gPj4gPg0KPiA+PiA+IFRoaXMgaXMg dHJ1ZSB3aGVuIHlvdSBjYWxsIHRoZSBkb21haW4gYSAiTElTUCBzaXRlIi4gQnV0IGlmIHRoZSBz aXRlIGlzDQo+ID4+ID4gdW5jaGFuZ2VkIGFuZCBvbmUgdXNlcyBQSVRScywgbWF5YmUgZXZlbiBj bG9zZSB0byB0aGUgc2l0ZSwgbGlrZSBpbiBhIFBFDQo+ID4+ID4gcm91dGVyLCB0aGVuIHRoZSBQ SVRSIGlzIGRlZmluaXRlbHkgaW4gYW5vdGhlciBBUy4gQnV0IG5vdGUgSSBzYWlkDQo+ID4+IFBJ VFIgYW5kDQo+ID4+ID4gbm90IElUUi4gVGhlIHJlYXNvbiBiZWluZyBpcyBiZWNhdXNlIGFuIElU UiBpcyBjb25maWd1cmVkIHdpdGggZGF0YWJhc2UtDQo+ID4+ID4gbWFwcGluZyBwcmVmaXhlcyB0 aGF0IGlzIHVzZXMgdG8gZW5jYXBzdWxhdGUgcGFja2V0cyBmcm9tIHN1Y2gNCj4gPj4gYWRkcmVz c2VzLg0KPiA+PiA+IFZlcnN1cyB0aGUgUElUUiBiZWluZyBhbiBJVFIgd2l0aCAqbm8gZGF0YWJh c2UtbWFwcGluZ3MqIHByb3ZpZGluZyBhDQo+ID4+IG11Y2ggbW9yZQ0KPiA+PiA+IGxhcmdlci9v ciBtb3JlIGFnZ3JlZ3RhYmxlIHNlcnZpY2UuDQo+ID4+ID4NCj4gPj4gPiA+PiBkZXBsb3ltZW50 LCBJIGRvbid0IHRoaW5rIHRoYXQncyBhbHdheXMgdGhlIGNhc2UsIGJ1dCBJIHRoaW5rDQo+ID4+ IHRoYXQgb25seQ0KPiA+PiA+ID4+IGhhcyBlZGl0b3JpYWwgaW1wYWN0IG9uIHRoaXMgZG9jdW1l bnQsIGFzIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZQ0KPiA+PiA+ID4+IGZ1bmRhbWVudGFsIExJ U1AgbWVjaGFuaXNtcyBhcmUgYWZmZWN0ZWQuICBUaGUgYXV0aG9ycyBzaG91bGQNCj4gPj4gbG9v ayBmb3INCj4gPj4gPiA+PiB1c2Ugb2YgImRvbWFpbiIgYW5kICJBdXRvbm9tb3VzIFN5c3RlbSIg YW5kIGVuc3VyZSB0aGF0IHRoZSB0ZXh0IGlzDQo+ID4+ID4gPj4gZ2VuZXJhbGl6ZWQgdG8gdGhl IGNhc2Ugd2hlcmUgdGhlIGVuZCBob3N0IGFuZCBJVFIgYXJlIG1vcmUgd2lkZWx5DQo+ID4+ID4g Pj4gc2VwYXJhdGVkLg0KPiA+PiA+DQo+ID4+ID4gV2UgYXJlIG92ZXJsb2FkZWQgd2l0aCB0ZXJt cyB0aGF0IGNyZWF0ZSB0b3BvbG9naWNhbCBvciBvcmdhbml6YXRpb24NCj4gPj4gYm91bmRhcnku DQo+ID4+ID4gSGVuY2Ugd2h5IHdlIGNyZWF0ZWQgIkxJU1Agc2l0ZSIgd2hpY2ggaXMgYWxzbyB0 aGUgc2FtZSBhcyBhICJMSVNQDQo+ID4+IFZQTiBzaXRlIi4NCj4gPj4gPiBXaGVyZSBhICJMSVNQ IHNpdGUiIHRoYXQgaGFzIG11bHRpcGxlIHRlbm5hbnRzIHdvdWxkIGJlIG11bHRpcGxlDQo+ID4+ ICJMSVNQIFZQTg0KPiA+PiA+IHNpdGVzIi4NCj4gPj4gPg0KPiA+PiA+ID4+IERlc3BpdGUgbXVs dGlwbGUgIG1lbnRpb25zIG9mIGluY3JlbWVudGFsIGRlcGxveW1lbnQsIEkgZGlkIG5vdA0KPiA+ PiA+ID4+IHNlZSBhIGRpc2N1c3Npb24gb2YgaG93IHRoYXQgbWlnaHQgYmUgYWNjb21wbGlzaGVk LiAgVGhlcmUgaXMgc29tZQ0KPiA+PiA+DQo+ID4+ID4gVGhlcmUgYXJlIFB4VFJzIGFuZCBOQVRz LiBBbmQgcmVmZXJlbmNlcyB0byB0aGUgTElTUCBpbnRlcndvcmtpbmcgUkZDLg0KPiA+PiA+DQo+ ID4+ID4gPj4gdXNlZnVsIGNvbnRlbnQgaW4gU2VjdGlvbiAzLjUsIGJ1dCB0aGF0J3MgYXQgYmVz dCBhbiBpbmNvbXBsZXRlDQo+ID4+ID4gPj4gZXhwbGFuYXRpb24uICBUaGlzIGlzIGFuIE9QUy1E aXIgcmV2aWV3IGNvbmNlcm4gLSBpdCBmYWxscyB1bmRlcg0KPiA+PiA+ID4+IEEuMS4zIGluIEFw cGVuZGl4IEEgb2YgUkZDIDU3MDY6IEhhcyB0aGUgbWlncmF0aW9uIHBhdGggYmVlbg0KPiA+PiBk aXNjdXNzZWQ/DQo+ID4+ID4gPj4NCj4gPj4gPiA+PiAtIDMuMy4xLiAgTElTUCBFbmNhcHN1bGF0 aW9uDQo+ID4+ID4gPj4NCj4gPj4gPiA+PiAgICB0aGUgc291cmNlIHBvcnQgaXMgc2VsZWN0ZWQg YnkNCj4gPj4gPiA+PiAgICB0aGUgSVRSIGFuZCBpZ25vcmVkIG9uIHJlY2VwdGlvbi4NCj4gPj4g PiA+Pg0KPiA+PiA+ID4+IFBsZWFzZSBtZW50aW9uIG11bHRpcGF0aGluZyAoZS5nLiwgRUNNUCBh bmQgTEFHKSBhcyBwb3NzaWJsZQ0KPiA+PiBpbmZsdWVuY2VzDQo+ID4+ID4gPj4gb24gaG93IHNv dXJjZSBwb3J0cyBhcmUgc2VsZWN0ZWQsIGFzIHRoaXMgaW1wb3NlcyBzb21lIGxpbWl0cyBvbg0K PiA+PiB3aGF0IGFuDQo+ID4+ID4gPj4gSVRSIGNhbiByZWFzb25hYmx5IGRvLg0KPiA+PiA+DQo+ ID4+ID4gRUNNUC9MQUcgZG9uJ3QgaW5mbHVlbmNlIHdoaWNoIHNvdXJjZSBwb3J0IGlzIHNlbGVj dGVkLiBJdCBpcyBhDQo+ID4+IDUtdHVwbGUgaGFzaA0KPiA+PiA+IG9mIHRoZSBpbm5lciBoZWFk ZXIgdGhhdCBzZWxlY3RzIGEgc291cmNlIHBvcnQgdGhhdCBpbmZsdWVuY2VzIGhvdw0KPiA+PiBh biB1bmRlcmxheQ0KPiA+PiA+IHJvdXRlciB3b3VsZCBsb2FkLXNwbGl0IHRyYWZmaWMuDQo+ID4+ ID4NCj4gPj4gPiA+PiBGb3IgT1BTLURpciwgdGhpcyBtdWx0aXBhdGhpbmcgY29uY2VybiBmYWxs cyB1bmRlciBBLjEuNCBpbg0KPiA+PiBBcHBlbmRpeCBBIG9mDQo+ID4+ID4gPj4gUkZDIDU3MDY6 IEhhdmUgdGhlIFJlcXVpcmVtZW50cyBvbiBvdGhlciBwcm90b2NvbHMgYW5kIGZ1bmN0aW9uYWwN Cj4gPj4gPiA+PiAgICAgICAgY29tcG9uZW50cyBiZWVuIGRpc2N1c3NlZD8NCj4gPj4gPiA+Pg0K PiA+PiA+ID4+ICAgIFRoaXMgZGVjaXNpb24gd2FzIG1hZGUgYmVjYXVzZSB0aGUNCj4gPj4gPiA+ PiAgICB0eXBpY2FsIHRyYW5zcG9ydCBwcm90b2NvbHMgdXNlZCBieSB0aGUgYXBwbGljYXRpb25z IGFscmVhZHkNCj4gPj4gaW5jbHVkZQ0KPiA+PiA+ID4+ICAgIGEgY2hlY2tzdW0sIGJ5IG5lZ2xl Y3RpbmcgdGhlIGFkZGl0aW9uYWwgVURQIGVuY2Fwc3VsYXRpb24NCj4gPj4gY2hlY2tzdW0NCj4g Pj4gPiA+PiAgICB4VFJzIGNhbiBmb3J3YXJkIHBhY2tldHMgbW9yZSBlZmZpY2llbnRseS4NCj4g Pj4gPiA+Pg0KPiA+PiA+ID4+IEdyb2FuISAgSSBoYXZlIGFuIGV4cXVpc2l0ZSBzZXQgb2Ygc2Nh cnMgb24gVURQIHplcm8gY2hlY2tzdW1zDQo+ID4+IGZvciBJUHY2DQo+ID4+ID4gPj4gZnJvbSB3 b3JraW5nIG9uIHRoZSBNUExTIGluIFVEUCBkcmFmdCwgc28gSSBtYXkgYmUgb3Zlcmx5DQo+ID4+ IHNlbnNpdGl2ZSB0bw0KPiA+PiA+ID4+IHRoaXMgY29uY2Vybi4gIFRoZSBkb3duc2lkZSBvZiB0 aGlzIGVmZmljaWVuY3kgaXMgdGhhdCB0aGVyZSBpcyBubw0KPiA+PiA+ID4+IGNoZWNrc3VtIGNv dmVyYWdlIG9mIHRoZSBJUHY2IGhlYWRlciB3aGVuIHplcm8gVURQIGNoZWNrc3VtcyBhcmUNCj4g Pj4gdXNlZC4NCj4gPj4gPiA+PiBUaGF0IHNob3VsZCBhdCBsZWFzdCBiZSBtZW50aW9uZWQgaGVy ZSwgd2l0aCBhIHN1bW1hcnkgb2Ygd2h5DQo+ID4+IHRoYXQncyBvaw0KPiA+PiA+ID4+IC0gdGhl IGRldGFpbGVkIGp1c3RpZmljYXRpb24gZm9yIHdoeSB0aGF0J3Mgb2sgY2FuIGJlIGxlZnQgdG8g b3RoZXINCj4gPj4gPiA+PiBkb2N1bWVudHMuDQo+ID4+ID4NCj4gPj4gPiBNeSBoZWFkIHNwaW5z IGV2ZXJ5IHRpbWUgSSBoZWFyIGFib3V0IHRoaXMgc3ViamVjdC4gVGhpcyBzdWJqZWN0IGhhcw0K PiA+PiBiZWVuDQo+ID4+ID4gdGFsa2VkIGFib3V0IGZyb20gMTAwcyBvZiBwZW9wbGUgZm9yIGEg ZGVjYWRlLiBXZSBoYXZlIENSQyBvbiBsaW5rcywNCj4gPj4gd2UgaGF2ZQ0KPiA+PiA+IGFwcHMg dGhhdCB1c2UgVENQIGFuZCBVRFAgY2hlY2tzdW1zLiBOdWYgc2FpZC4NCj4gPj4gPg0KPiA+PiA+ ID4+DQo+ID4+ID4gPj4gLS0gTml0cy9FZGl0b3JpYWwgQ29tbWVudHMgLS0NCj4gPj4gPiA+Pg0K PiA+PiA+ID4+IC0gVG9wIG9mIHAuNDoNCj4gPj4gPiA+Pg0KPiA+PiA+ID4+ICAgIFRoZSBpbml0 aWFsIG1vdGl2YXRpb24gaW4gdGhlIExJU1AgZWZmb3J0IGlzIHRvIGJlIGZpbmQgaW4gdGhlDQo+ ID4+ID4gPj4NCj4gPj4gPiA+PiAiZmluZCIgLT4gImZvdW5kIg0KPiA+PiA+ID4+DQo+ID4+ID4g Pj4gLSBTZWN0aW9uIDMuMSwgZmlyc3QgYnVsbGV0IGl0ZW0NCj4gPj4gPg0KPiA+PiA+IFdlIHdp bGwgY2VydGFpbmx5IGZpeGUgdGhlc2UuIFRoYW5rcy4NCj4gPj4gPg0KPiA+PiA+ID4+DQo+ID4+ ID4gPj4gICAgICAgRGV2aWNlcyBhcmUgYXNzaWduZWQgd2l0aCByZWxhdGl2ZWx5IG9wYXF1ZSBp ZGVudGl0eQ0KPiA+PiA+ID4+ICAgICAgIG1lYW5pbmdmdWwgYWRkcmVzc2VzIHRoYXQgYXJlIGlu ZGVwZW5kZW50IG9mIHRoZWlyIHRvcG9sb2dpY2FsDQo+ID4+ID4gPj4gICAgICAgbG9jYXRpb24u DQo+ID4+ID4gPj4NCj4gPj4gPiA+PiBJIGRvbid0IHVuZGVyc3RhbmQgInJlbGF0aXZlbHkgb3Bh cXVlIGlkZW50aXR5IG1lYW5pbmdmdWwiIGFuZA0KPiA+PiA+ID4+IHN1Z2dlc3QgcmV3cml0aW5n IHRoZSBzZW50ZW5jZS4gIEluIHBhcnRpY3VsYXIgLSBvcGFxdWUgdG8gd2hhdD8NCj4gPj4gPiA+ PiBtZWFuaW5nZnVsIHRvIHdoYXQgaW4gd2hhdCBtYW5uZXI/DQo+ID4+ID4NCj4gPj4gPiBXZWxs IGJlYWN1c2UgaXQgaXMgYXMgYWNjdXJhdGUgYXMgaXQgY2FuIGJlLiBJZiBhdXRvbW9iaWxlcyBh cmUNCj4gPj4gZ29pbmcgdG8gYmUNCj4gPj4gPiBhc3NpZ25lZCBFSURzIGZyb20gYSBWSU4gbnVt YmVyIGFsbG9jYXRpb24gZnJvbSBhIG1hbnVmYWN0dXJlLCB0aGUNCj4gPj4gYWRkcmVzcyBpcw0K PiA+PiA+IHJlbGF0aXZlbHkgb3BhcXVlLiBJZiBhIFZNIGluIGEgZGF0YS1jZW50ZXIgaXMgZ29p bmcgdG8gYmUgYXNzaWduZWQNCj4gPj4gYW4gRUlEDQo+ID4+ID4gZnJvbSB0aGUgc2V0IG9mIHBy ZWZpeGVzIGFscmVhZHkgYmVpbmcgdXNlZCBhbmQgYWxsb2NhdGVkIHRvIHRoYXQNCj4gPj4gZGF0 YS1jZW50ZXIsDQo+ID4+ID4gdGhlbiB0aGVyZSBpcyBhIGdvb2QgY2hhbmNlIHRoYXQgYWRkcmVz cyBpcyBpbiBhIHBvd2VyLW9mLTIgYmxvY2sNCj4gPj4gdGhhdCBpcw0KPiA+PiA+IHN1bW1hcml6 YWJsZSBpbiB0aGUgSUdQLg0KPiA+PiA+DQo+ID4+ID4gPj4NCj4gPj4gPiA+PiAtIFNlY3Rpb24g My4yLCBzZWNvbmQgcGFyYWdyYXBoDQo+ID4+ID4gPj4NCj4gPj4gPiA+PiBKdWRnaW5nIGZyb20g dGhlIGZpZ3VyZSwgeFRScyBhcmUgdGhlIGNvbW1vbiBjYXNlLCB3aXRoIHNpbmdsZS0NCj4gPj4g PiA+PiBmdW5jdGlvbiBJVFJzIGFuZCBFVFJzIGJlaW5nIHJhcmUuICBJdCBtaWdodCBiZSBnb29k IHRvIHNheSB0aGF0DQo+ID4+ID4gPj4gYW5kIGRpc2N1c3Mgd2hlbiBJVFJzIGFuZCBFVFJzIHRo YXQgYXJlIG5vdCB4VFJzIGFyZSBhcHByb3ByaWF0ZQ0KPiA+PiA+ID4+IHRvIHVzZS4NCj4gPj4g Pg0KPiA+PiA+IFdoZW4geW91IHdhbnQgZWdyZXNzIHBhdGggc2VsZWN0aW9uIHRvIGhhcHBlbiBm dXJ0aGVyIG91dCBpbiB0aGUNCj4gPj4gdG9wbG9naWNhbA0KPiA+PiA+IGZyb20gdGhlIHNvdXJj ZSBsb2NhdGlvbiwgdGhlbiB5b3UgcHV0IGFuIElUUi1vbmx5IHN5c3RlbSB0aGVyZS4NCj4gPj4g V2hlcmUgaW5ncmVzcw0KPiA+PiA+IHRvIHRoZSBzYW1lIHNvdXJjZSAoZGVzdGluYXRpb24gaW4g dGhpcyBkaXJlY3Rpb24pLCB0aGUgRVRSIGNhbiBiZQ0KPiA+PiBjbG9zZXIgdG8NCj4gPj4gPiB0 aGUgZGVzdGluYXRpb24uDQo+ID4+ID4NCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IC0gM3JkIHBhcmFn cmFwaCBvbiBwLjc6DQo+ID4+ID4gPj4NCj4gPj4gPiA+Pg0KPiA+PiA+ID4+ICAgIEZpbmFsbHks IHRoZSBMSVNQIGFyY2hpdGVjdHVyZSBlbXBoYXNpemVzIGEgY29zdCBlZmZlY3RpdmUNCj4gPj4g PiA+PiAgICBpbmNyZW1lbnRhbCBkZXBsb3ltZW50Lg0KPiA+PiA+ID4+DQo+ID4+ID4gPj4gSSdk IGRlbGV0ZSAiY29zdCBlZmZlY3RpdmUiIGhlcmUgYW5kIGxvb2sgZm9yIG90aGVyIG9jY3VycmVu Y2VzDQo+ID4+ID4gPj4gb2YgImNvc3QiIGFzIGNhbmRpZGF0ZXMgZm9yIGRlbGV0aW9uLiAgVGhp cyBpcyBzdXBwb3NlZCB0byBiZQ0KPiA+PiA+ID4+IGEgdGVjaG5pY2FsIGRvY3VtZW50LCBzbyBk aXNjdXNzaW9uIG9mIGNvc3RzIGlzIGEgYml0IG9mZi10YXJnZXQuDQo+ID4+ID4NCj4gPj4gPiBG YWlyIGVub3VnaC4NCj4gPj4gPg0KPiA+PiA+ID4+IC0gRmlyc3QgaXRlbSBhZnRlciBGaWd1cmUg MjoNCj4gPj4gPiA+Pg0KPiA+PiA+ID4+ICAgIDEuICBIb3N0QSByZXRyaWV2ZXMgdGhlIEVJRF9C IG9mIEhvc3RCLCB0eXBpY2FsbHkgcXVlcnlpbmcgdGhlIEROUw0KPiA+PiA+ID4+ICAgICAgICBh bmQgb2J0YWluaW5nIGFuZCBBIG9yIEFBQUEgcmVjb3JkLg0KPiA+PiA+ID4+DQo+ID4+ID4gPj4g ImFuZCBBIiAtPiAiYW4gQSIgIChzcGVsbGluZyBjaGVja2VycyBkb24ndCBjYXRjaCBldmVyeXRo aW5nKS4NCj4gPj4gPg0KPiA+PiA+IEFscmVhZHkgbm90ZWQgYW5kIHdpbGwgYmUgZml4ZWQuDQo+ ID4+ID4NCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IC0gMy4zLjEuICBMSVNQIEVuY2Fwc3VsYXRpb24N Cj4gPj4gPiA+Pg0KPiA+PiA+ID4+ICAgIE9uIHRoZSBvdGhlciBoYW5kLCBSZWN1cnNpdmUNCj4g Pj4gPiA+PiAgICB0dW5uZWxzIGFyZSBuZXN0ZWQgdHVubmVscyBhbmQgYXJlIGltcGxlbWVudGVk IGJ5IHVzaW5nDQo+ID4+IG11bHRpcGxlIExJU1ANCj4gPj4gPiA+PiAgICBlbmNhcHN1bGF0aW9u cyBvbiBhIHBhY2tldC4NCj4gPj4gPiA+Pg0KPiA+PiA+ID4+IFRoZSBhYm92ZSBzZW50ZW5jZSBz ZWVtcyBvdXQgb2YgcGxhY2UgaW4gdGhlIG1pZGRsZSBvZiBhDQo+ID4+IHBhcmFncmFwaCBhYm91 dA0KPiA+PiA+ID4+IFJlLWVuY2Fwc3VsYXRpbmcgdHVubmVscyBhbmQgcm91dGVycyAtIEkgc3Vn Z2VzdCBtb3ZpbmcgaXQgZG93bg0KPiA+PiBpbnRvIGl0cw0KPiA+PiA+ID4+IG93biBwYXJhZ3Jh cGggYW5kIHBlcmhhcHMgYWRkaW5nIGEgc2VudGVuY2UgYWJvdXQgd2hlcmUvaG93IFJlY3Vyc2l2 ZQ0KPiA+PiA+ID4+IHR1bm5lbHMgbWF5IGJlIHVzZWZ1bC4NCj4gPj4gPg0KPiA+PiA+IEdvb2Qg c3VnZ2VzdGlvbiBhbmQgbWFrZXMgc2Vuc2UuDQo+ID4+ID4NCj4gPj4gPiA+PiAtIDMuMy4yLiAg TElTUCBGb3J3YXJkaW5nIFN0YXRlDQo+ID4+ID4gPj4NCj4gPj4gPiA+PiAgICBJbiB0aGUgTElT UCBhcmNoaXRlY3R1cmUsIElUUnMga2VlcCBqdXN0IGVub3VnaCBpbmZvcm1hdGlvbiB0bw0KPiA+ PiByb3V0ZQ0KPiA+PiA+ID4+ICAgIHRyYWZmaWMgZmxvd2luZyB0aHJvdWdoIGl0Lg0KPiA+PiA+ ID4+DQo+ID4+ID4gPj4gIml0LiIgLT4gInRoZW0uIg0KPiA+PiA+ID4+DQo+ID4+ID4gPj4gICAg TWVhbmluZyB0aGF0LCBJVFJzIHJldHJpZXZlIGZyb20gdGhlDQo+ID4+ID4gPj4gICAgTElTUCBN YXBwaW5nIFN5c3RlbSBtYXBwaW5ncyBiZXR3ZWVuIEVJRCBwcmVmaXhlcyBhbmQgUkxPQ3MNCj4g Pj4gdGhhdCBhcmUNCj4gPj4gPiA+PiAgICB1c2VkIHRvIGVuY2Fwc3VsYXRlIHBhY2tldHMuDQo+ ID4+ID4gPj4NCj4gPj4gPiA+PiBUaGlzIGlzIHRoZSBmaXJzdCB1c2Ugb2YgdGhlIG5vdGlvbiBv ZiBFSUQgcHJlZml4ZXMuICBUaGF0DQo+ID4+IGNvbmNlcHQgc2hvdWxkDQo+ID4+ID4gPj4gYmUg ZXhwbGFpbmVkIGJlZm9yZSBpdCBpcyB1c2VkLCBhbHRob3VnaCBhIGZvcndhcmQgcmVmZXJlbmNl IHRvDQo+ID4+IHNlY3Rpb24NCj4gPj4gPiA+PiAzLjQuMSBtYXkgc3VmZmljZS4gIEl0IG1pZ2h0 IGJlIGJldHRlciB0byByZXdyaXRlIHRoaXMgcGFyYWdyYXBoDQo+ID4+IGluIHRlcm1zDQo+ID4+ ID4gPj4gb2YgRUlEcyBhbmQgbGVhdmUgdGhlIG5vdGlvbiBvZiBFSUQgcHJlZml4ZXMgdG8gc2Vj dGlvbiAzLjQuMS4NCj4gPj4gPg0KPiA+PiA+IEhtbSwgSSdsbCBsZXQgQWxiZXJ0IGFuZCBEYW1p ZW4gZGVjaWRlIGlmIHdlIHNob3VsZCBzdGF0ZSAiRUlELXByZWZpeGVzIg0KPiA+PiA+IGV2ZXJ5 d2hlcmUgaW5zdGVhZCBvZiBqdXN0ICJFSUQiLg0KPiA+PiA+DQo+ID4+ID4gPj4NCj4gPj4gPiA+ PiAtIDQuNC4gIE1UVSBIYW5kbGluZw0KPiA+PiA+ID4+DQo+ID4+ID4gPj4gICAgQWRkaXRpb25h bGx5LCBMSVNQIGFsc28gcmVjb21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmlsaXR5IG9mDQo+ID4+ IGxvY2F0b3JzDQo+ID4+ID4gPj4gICAgYnkgdXNpbmcgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkg dGhlIHVuZGVybGF5LCBpbiBwYXJ0aWN1bGFyOg0KPiA+PiA+ID4+DQo+ID4+ID4gPj4gSXQnZCBi ZSB1c2VmdWwgdG8gYWRkIGEgc2VudGVuY2Ugb3IgdHdvIGFib3V0IGhvdyBMSVNQIGFuZCB0aGUN Cj4gPj4gdGVjaG5pcXVlcw0KPiA+PiA+ID4+IGluIHRoaXMgc2VjdGlvbiBpbnRlcmFjdCB3aXRo IGhvc3QgdXNlIG9mIFBNVFVEIGFuZCBQTFBNVFVELg0KPiA+PiA+DQo+ID4+ID4gVGhpcyBpcyBh IGxvdCBvZiBkZXRhaWwgYmVjYXVzZSBpbiBSRkM2ODMwIHdlIGhhdmUgMyBwb3NpdGlvbnMgb3IN Cj4gPj4gb3B0aW9ucyBvbg0KPiA+PiA+IHRoZSBzdWJqZWN0LiBBbmQgd2UgZGlkIHByb3ZpZGUg YSByZWZlcmVuY2UgdG8gUkZDNjgzMCBmb3IgdGhpcyB0b3BpYy4NCj4gPj4gPg0KPiA+PiA+ID4+ IC0gTmV4dCB0byBsYXN0IHBhcmFncmFwaCBvbiBwLjE3Og0KPiA+PiA+ID4+DQo+ID4+ID4gPj4g ICAgQWRkaXRpb25hbGx5LCBMSVNQIGFsc28gcmVjb21tZW5kcyBpbmZlcnJpbmcgcmVhY2hhYmls aXR5IG9mDQo+ID4+IGxvY2F0b3JzDQo+ID4+ID4gPj4gICAgYnkgdXNpbmcgaW5mb3JtYXRpb24g cHJvdmlkZWQgYnkgdGhlIHVuZGVybGF5LCBpbiBwYXJ0aWN1bGFyOg0KPiA+PiA+ID4+DQo+ID4+ ID4gPj4gVGhpcyBsb29rcyBsaWtlIGl0J3MgYSBwYXJhZ3JhcGggZWFybHkgYW5kIG5lZWRzIHRv IGJlIG1vdmVkIGRvd24gdG8NCj4gPj4gPiA+PiBhZnRlciB0aGUgcGFyYWdyYXBoIHRoYXQgZm9s bG93cyBpdC4NCj4gPj4gPg0KPiA+PiA+IEFncmVlLg0KPiA+PiA+DQo+ID4+ID4gPj4gaWRuaXRz IDIuMTMuMDEgZGlkbid0IGZpbmQgYW55IG5pdHMuDQo+ID4+ID4gPj4NCj4gPj4gPiA+PiBUaGFu a3MsDQo+ID4+ID4gPj4gLS1EYXZpZA0KPiA+PiA+DQo+ID4+ID4gVGhhbmtzIGFnYWluIERhdmlk Lg0KPiA+PiA+DQo+ID4+ID4gRGlubw0KPiA+Pg0KPiA+DQo= From nobody Thu Feb 12 06:51:46 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6D41A8AB7; Thu, 12 Feb 2015 06:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xwd5bnRi12y; Thu, 12 Feb 2015 06:51:36 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4681E1A8924; Thu, 12 Feb 2015 06:50:54 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEojRN024352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 09:50:46 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1CEojRN024352 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423752648; bh=Ec4Zq3puoXWw69NNoIVl+Gryfj8=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kiqeoZ9891KBJwIRRSiR+iSoZkcOiXUyckt1yLfH1fn5xKmszccMZ+5D0JYYgHw43 DPwsty5F7minrfPQjKyXfMEnyntQSvIFH5kgcAlBr7gtodfVx2g10oPqON6/InNRVK 65+G9eWRjwN586jijqF6rjbxero66AbbjY6Fgw1g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1CEojRN024352 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd55.lss.emc.com (RSA Interceptor); Thu, 12 Feb 2015 09:50:36 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEoY5o012947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 09:50:37 -0500 Received: from MXHUB209.corp.emc.com (10.253.68.35) by mxhub12.corp.emc.com (10.254.92.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 12 Feb 2015 09:50:34 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB209.corp.emc.com ([10.253.68.35]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 09:50:34 -0500 From: "Black, David" To: Dino Farinacci , Luigi Iannone Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] Thread-Index: AdBG00B2C5gGCfkjSoSGM0r5AEMtyQ== Date: Thu, 12 Feb 2015 14:50:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:51:38 -0000 I don't care what terms are used - it just needs to be absolutely clear tha= t the inner and outer multicast addresses are not the same and that mapping between them (which could take a number of forms) is involved. Thanks, --David > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Thursday, February 12, 2015 8:15 AM > To: Luigi Iannone > Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; Damie= n > Saucez; ietf@ietf.org > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >=20 > > G-EID =3D> the EID multicast group G > > G-RLOC =3D> the RLOC multicast group G >=20 > "inner and outer group addresses" have been used in various LISP multicas= t > documents. >=20 > Dino From nobody Thu Feb 12 06:57:06 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668EB1A906E; Thu, 12 Feb 2015 06:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdDKolq-UUwt; Thu, 12 Feb 2015 06:56:58 -0800 (PST) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (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 E52501A8FD2; Thu, 12 Feb 2015 06:56:55 -0800 (PST) Received: by pdno5 with SMTP id o5so12430025pdn.8; Thu, 12 Feb 2015 06:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VcXPYS47W/9vVXCicx2jyNaUgh1RaFMDRKvjpmD2hw0=; b=asZKfh/6GH9uuCqp41z0pDfCq1uue65O47PFBUUmgfhYR06TeyMcHtHmJhYyJikHq0 dXKCd93S24IeiXdmkeZirOpBSo/MGorVV7FAhKmNXg0BIWalhR0IMn1wHRsGon/MmW40 n29Kwagrx6qfMyGfFQBDop6r/rTA4vVIww+IIVvE+xgLAwoOqfh+ZRLNJlonLKAqEx2P N+p2fQoHL0wJjhcCJnao1jKAOyUzk2cmPkq/PXCKaKX+giNAjErAosEza0ZW8GMQAw00 pFj65cSGYlQ/DzrMBZEhXTFZ0tmjwXZ0I5JOVRDp5LbZh3JLx+r2Kg1kVADrxNRFLdjP fUXw== X-Received: by 10.66.164.232 with SMTP id yt8mr7014709pab.128.1423753015613; Thu, 12 Feb 2015 06:56:55 -0800 (PST) Received: from [10.231.66.55] ([166.170.38.252]) by mx.google.com with ESMTPSA id uy8sm4055633pbc.31.2015.02.12.06.56.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 06:56:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Thu, 12 Feb 2015 06:56:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> References: To: "Black, David" Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:57:00 -0000 They can be the same if the underlay provider wants to control overlay's gro= up address allocation.=20 Dino > On Feb 12, 2015, at 6:50 AM, Black, David wrote: >=20 > I don't care what terms are used - it just needs to be absolutely clear th= at > the inner and outer multicast addresses are not the same and that mapping > between them (which could take a number of forms) is involved. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Thursday, February 12, 2015 8:15 AM >> To: Luigi Iannone >> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; Damie= n >> Saucez; ietf@ietf.org >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >>=20 >>> G-EID =3D> the EID multicast group G >>> G-RLOC =3D> the RLOC multicast group G >>=20 >> "inner and outer group addresses" have been used in various LISP multicas= t >> documents. >>=20 >> Dino From nobody Thu Feb 12 06:57:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759321A8FD2; Thu, 12 Feb 2015 06:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbzy3CCKI1mS; Thu, 12 Feb 2015 06:56:55 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCA11A9034; Thu, 12 Feb 2015 06:56:48 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEuii8025971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 09:56:45 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1CEuii8025971 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423753005; bh=oVwRu7xFbdu9oedaHjfs4ixQt6k=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jtUmvAu8M9f1kzMBoFwUtJ0NibF4WpYHZ+jLany1ALU1kQB8RP8aXAf2/Tx1B1dro SPwFs8dZ4Q1A4eiHo1KXs5LQOZgHkA44Fo7i06dkozezzuQjWVFyit4swbNB1andxw 8cq1UOR0GXr6/Ga8DddzqYE4o33pQbbD3OYOCt1E= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1CEuii8025971 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd52.lss.emc.com (RSA Interceptor); Thu, 12 Feb 2015 09:56:33 -0500 Received: from mxhub39.corp.emc.com (mxhub39.corp.emc.com [128.222.70.106]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEuUj3015251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 09:56:30 -0500 Received: from MXHUB201.corp.emc.com (10.253.68.27) by mxhub39.corp.emc.com (128.222.70.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 12 Feb 2015 09:56:30 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB201.corp.emc.com ([10.253.68.27]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 09:56:30 -0500 From: "Black, David" To: Dino Farinacci Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 - UDP source port Thread-Index: AdBG1BDNpP1URRymT6aDs25Gmr0uCg== Date: Thu, 12 Feb 2015 14:56:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 - UDP source port X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:57:02 -0000 [A] and [B] are handled in other messages. On UDP source port selection: > > Please state that a 5-tuple hash is used. ECMP/LAG is among the import= ant >=20 > Well there can be other ways to hash and that is detail not needed at thi= s level IMO. We suggest a 5-tuple hash in RFC6830. > > > reasons why, but that doesn't need to be stated if you prefer not to. = An > > example of something that needs to be excluded is that using a random > > number generator to set the source port would be wrong - I could sugges= t > > citing draft-ietf-dart-dscp-rtp for related discussion (and lots more > > details), but I don't think that's necessary. > > How about stating the source-port should not change for a flow or it caus= es an underlay router to > resequence packets over lags? This is for ECMP in addition to LAG - if you go this route, please do cite = the dart draft (informative reference) for its supporting discussion about = transport protocol (mis)behavior in the face of within-flow resequencing. = It would also be helpful to say that a 5-tuple hash is one way to achieve t= his (and see RFC 6830 for details). Thanks, --David > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Wednesday, February 11, 2015 11:40 PM > To: Black, David > Cc: Joel M. Halpern; Albert Cabellos; Damien Saucez; ops-dir@ietf.org; > ietf@ietf.org; lisp@ietf.org > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >=20 > > Dino - thanks for the response. > > > > On the major issues, it looks like both [A] and [B] involve only the te= xt > > in this draft and nothing beyond, which is good news. I have a simple = text > > suggestion for [A], but it looks like [B] is going to require some care= ful > > editing, as one of the primary causes is that the draft is sloppy in us= ing > > the same symbol "G" to represent both EID and RLOC multicast groups. >=20 > Okay for [A] but not true for [B]. In RFC6831, a multicast address G is n= ot in > the mapping database because signaling is performed from ETR to ITR. What= 's in > the mapping database is the EID S from the (S,G) the source sends from an= d to. >=20 > > On the minor issues, I have text suggestions for three of the four, and > > I'd like to temporarily defer further discussion the IPv6 UDP zero > > checksum "tarpit" in favor of resolving everything else first. >=20 > Sounds good David. >=20 > > On the nits/editorial comments, all the suggestions in your email are f= ine > > with me. FWIW, I regard that portion of a review as almost entirely > > subject to the draft authors' discretion (and editorial taste). > > > >>>> [A] EID mobility vs. EID prefixes > >> > >> ... from the start of the LISP design (circa 2007), an prefix is what > moves. > >> And a specific EID is simply a /32 or /128 prefix. Here is a practical > >> example: > > > > A statement that the mobility use cases need to employ /32 and /128 > prefixes, > > and not anything coarser should suffice. That should be added to Secti= on 5. >=20 > Well I think it is not true. Because EID-prefixes are moved but is outsid= e of > the VM-mobility use-case. >=20 > > > >>>> [B] LISP Multicast vs. EID/RLOC separate > >>>> > >>>> - 6. Multicast > >>>> > >>>> This is interesting, multicast addresses (G) look like they're an > exception > >> > >> They are really not. > > > > My concern is that as I read the draft, it leaves me with the strong > impression > > that the same multicast addresses (G) are being used in both the overla= y > > (as EIDs) and the underlay (as RLOCs). From your response, I conclude = that > this >=20 > Understand. We state in RFC6831 that it can map one-to-one or many-to-one= . > We'll make that more clear in the introduction document. >=20 > > is not the case (and I have no argument with that). Rather, Section 6 = needs > to > > bluntly state that multicast addresses are mapped between EID and RLOC = space > at > > both ITRs and ETRs, so that the following inference is obvious from the= text > > (it's currently not obvious): >=20 > Right, agree. >=20 > > So it makes perfect sense to register multicast addresses to the mappin= g > >> system as EIDs and they can map to RLOCs of sites that have joined the > group. > > > > As part of this, I strongly recommend moving away from use of "G" to re= fer > to > > multicast groups in both the overlay and underlay. Careful use of G-EI= D > > and G-RLOC would significantly improve clarity. >=20 > Well we have not used G-EID in any documentation. And since we want to > encourage the use of SSM in the underlay and how we signal in the overlay= , we > simply call the "eid" the 2-tuple (S,G). >=20 > > --- > > If the above are done for [A] and [B] in Sections 5 and 6, then the tex= t for > the > > use cases in Section 7 should not need further attention. > > --- > > > >>>> -- Minor Issues -- > >>>> > >>>> There seems to be an implicit assumption that the end host and its > >>>> ITR (xTR) are in the same domain or Autonomous System. For incremen= tal > >> > >> This is true when you call the domain a "LISP site". But if the site i= s > >> unchanged and one uses PITRs, maybe even close to the site, like in a = PE > >> router, then the PITR is definitely in another AS. > > > > Looking at the text, it seems that "LISP site" and "domain" are the sam= e > > concept for this draft. That would be useful to state, IMHO but I'll l= eave > > the decision on whether to do so to you and the draft authors. > > > > On rereading, my concerns seem to be triggered mostly by this sentence = in > > Section 3.2: > > > > The edge consists of LISP sites (e.g., an > > Autonomous System) that use EID addresses. > > > > I think a small change to the last sentence in that paragraph would res= olve > > my concern without distracting from the narrative: > > > > OLD > > EIDs do not > > contain inter-domain topological information and because of this, > > EIDs are usually routable at the edge (within LISP sites) or in the > > non-LISP Internet. > > NEW > > EIDs do not > > contain inter-domain topological information and because of this, > > EIDs are usually routable at the edge (within LISP sites) or in the > > non-LISP Internet; see Section 3.5 for discussion of LISP site > > internetworking with non-LISP sites and domains in the Internet. >=20 > Ack. >=20 > > > >>>> Despite multiple mentions of incremental deployment, I did not > >>>> see a discussion of how that might be accomplished. > >> > >> There are PxTRs and NATs. And references to the LISP interworking RFC. > > > > Ok, can we just say so in Section 3.5? Adding the following sentence > > to the end of the section would suffice: > > > > PITRs, PETRs and LISP-NAT support incremental deployment of LISP > > by providing significant flexibility in location of the boundaries > > between the LISP and non-LISP portions of the network, and making > > it reasonable to change those boundaries over time. >=20 > Yes. >=20 > > - 3.3.1. LISP Encapsulation > >>>> > >>>> the source port is selected by > >>>> the ITR and ignored on reception. > >>>> > >>>> Please mention multipathing (e.g., ECMP and LAG) as possible influen= ces > >>>> on how source ports are selected, as this imposes some limits on wha= t an > >>>> ITR can reasonably do. > >> > >> ECMP/LAG don't influence which source port is selected. It is a 5-tupl= e > hash > >> of the inner header that selects a source port that influences how an > underlay > >> router would load-split traffic. > > > > Please state that a 5-tuple hash is used. ECMP/LAG is among the import= ant >=20 > Well there can be other ways to hash and that is detail not needed at thi= s > level IMO. We suggest a 5-tuple hash in RFC6830. >=20 > > reasons why, but that doesn't need to be stated if you prefer not to. = An > > example of something that needs to be excluded is that using a random > > number generator to set the source port would be wrong - I could sugges= t > > citing draft-ietf-dart-dscp-rtp for related discussion (and lots more > > details), but I don't think that's necessary. >=20 > How about stating the source-port should not change for a flow or it caus= es an > underlay router to resequence packets over lags? >=20 > > -- IPv6 zero UDP checksum > > > >> My head spins every time I hear about this subject. This subject has b= een > >> talked about from 100s of people for a decade. We have CRC on links, w= e > have > >> apps that use TCP and UDP checksums. Nuf said. > > > > Understood - there's more than one set of scars on this one :-(. Let's= come > back > > to this topic after we've resolved everything else, and please keep in = mind > > that I tagged this as a minor issue, not a major one (e.g., the above > changes > > for [A] and [B] are far more important, IMHO). >=20 > Ack. Thanks again. >=20 > Dino >=20 > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farinacci@gmail.com] > >> Sent: Wednesday, February 11, 2015 2:19 PM > >> To: Joel M. Halpern > >> Cc: Black, David; Albert Cabellos; Damien Saucez; ops-dir@ietf.org; > >> ietf@ietf.org; lisp@ietf.org > >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 > >> > >>> I will leave most of these for the authors to comment on. > >> > >> See my comments inline. Thanks David for your detailed review and > commentary. > >> > >>> With regard to your question about incremental deployment, that is th= e > >> domain of the LISP Deployment document, and was deliberately only ligh= tly > >> covered here. I am not sure what we can do to address your comment wi= thout > >> duplicating the entirety of that document. > >> > >> That is the risk we may have with many of your comments. We have a lot= of > >> detail in the already 9 published RFCs and this document really is to= take > >> all that detail and summarize as an easily understandable description = of a > >> cohesive design. > >> > >>> With regard to UDP Zero, this was approved by the IESG and published = as an > >> RFC. It is part of the way the protocol is defined. If there are spe= cific > >> changes you would like to see in the explanatory text, I am sure > >> > >> Definitely agreed. In fact we instigated UDP zero. And I continually t= alk > to > >> hardware engineers and they all believe we made the right decision. So= hats > >> off to the IETF for being practical. > >> > >>> we could include them. If you are looking for a change in the behavi= or, > >> this document can not make changes to the LISP behavior. > >> > >> Yes, an important point. > >> > >>>> I found a couple of major issues that I hope arise from the > >>>> summarization of LISP in this draft, as opposed to being problems in > >>>> the actual LISP protocols. I also found a few minor issues, the mos= t > >>>> important of which is the need for additional security consideration= s > >>>> discussion on misdelivery, with particular attention to VPNs. > >> > >> Thanks a ton. > >> > >>>> -- Major issues -- > >>>> > >>>> [A] EID mobility vs. EID prefixes > >>>> > >>>> - 5. Mobility > >>>> > >>>> I understand how this works when mapping is per-EID, but how does th= is > work > >>>> when the EID of the system that moves is part of an EID prefix, as > >> discussed > >>>> in Section 3.4.1? Even if the answer is a long version of "Don't do > that!" > >>>> it should be explained. > >> > >> No, from the start of the LISP design (circa 2007), an prefix is what > moves. > >> And a specific EID is simply a /32 or /128 prefix. Here is a practical > >> example: > >> > >> You have a cluster of servers that communicate together for a particul= ar > >> application. They application cluster is running in a set of VMs. Thos= e VMs > >> are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are > currently > >> running in a brick-and-mortar data center. Now there is a desire to mo= ve > the > >> VM cluster to a cloud provider. What is moved is the EID-prefix of the > >> cluster. The mapping system is told that the EID-prefix is changing it= s > RLOC- > >> set from the brick-and-mortar xTRs to the cloud providers xTRs. > >> > >>>> > >>>> - 7.4. LISP for Virtual Machine Mobility in Data Centers > >>>> > >>>> I don't understand how this works when EID prefixes are used, as eac= h VM > >>>> has its own EID or EIDs, hence the entire prefix range does not move= when > >>>> the VM moves. > >>>> > >>>> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix= A > >>>> of RFC 5706: Has deployment been discussed? and specifically under: > >>>> > >>>> * Is the proposed specification deployable? If not, how coul= d > >>>> it be improved? > >>>> > >>>> as EID prefixes appear to be undeployable for Mobility and VM Mobili= ty > >> usage. > >> > >> See above example. > >> > >>>> [B] LISP Multicast vs. EID/RLOC separate > >>>> > >>>> - 6. Multicast > >>>> > >>>> This is interesting, multicast addresses (G) look like they're an > exception > >> > >> They are really not. Since multicast addresses *identify* a group of > >> receivers, it is very much an EID and aheres to the definition of an E= ID. > >> Multicast addresses never had topological signficance but the state > >> representing a distribution tree does tell you were the members are (b= ut > the > >> identity of the members are not know in multicast). > >> > >> So it makes perfect sense to register multicast addresses to the mappi= ng > >> system as EIDs and they can map to RLOCs of sites that have joined the > group. > >> See draft-farinacci-signal-free-multicast as just one example. RFC6831= and > >> draft-farinacci-lisp-mr-signaling are other examples. > >> > >>>> to the EID/RLOC separation as the same destination IP multicast addr= ess > >>>> is used for both purposes. This could use some more discussion, as = it's > >>>> unexpected based on the contents of the draft up to this point. > >> > >> I believe the level of detail we have in the introduction document is = at > the > >> right level or we'll err on having way too many details crop in. > >> > >>>> - 7.2. LISP for IPv6 Co-existence > >>>> > >>>> LISP encapsulations allows to transport packets using EIDs from a > >>>> given address family (e.g., IPv6) with packets from other address > >>>> families (e.g., IPv4). > >>>> > >>>> How does that work for multicast traffic, where the destination addr= ess > >>>> (G) has to be the same in both the inner and outer headers? Are ETR= s > >>>> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.? > >> > >> The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RL= OC > set > >> that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that > >> receives the packet from S-EID-ipv6 would replicate the packet and > multicast > >> encapsulate to ipv4-multicast and unicast encapsualte to ipv4-unicast. > >> > >>>> - 7.3. LISP for Virtual Private Networks > >>>> > >>>> This also has multicast problems, as there is only one instance of e= ach > >>>> multicast address (G) in the underlay network. I think I can figure= out > >> how > >> > >> You can map from EID-G to RLOC-G one to one. But we have seen over the= last > >> decade in a half that with general multicast deployment that many-to-1= is > >> desirable. Hence, now that we have a way to map with a network-based > database, > >> we can map multiple EID-Gs to a single (or multiple) RLOC-Gs. > >> > >>>> to make multicast work for this use case, but it's not immediately > obvious, > >>>> and the result when the same underlay multicast address is used by m= ore > >>>> than one VPN could well deliver some traffic to ETRs that have to di= scard > >> > >> This is a necessary evil when the underlay is state challenged. But it= is a > >> state/bandwidth tradeoff. We have found with MVPN deployment that the > network > >> admin configures the underly or simply unicasts. > >> > >>>> it because the Instance ID is wrong (and that excessive delivery is = a > >>>> security consideration, see minor issue on Section 8 below). I thin= k an > >>>> explanation is in order. > >> > >> There are just too many combinations to make a high-level description > simple > >> to understand. The current introduction text does a find job providing > >> references for someone to go off and get the details. > >> > >>>> -- Minor Issues -- > >>>> > >>>> There seems to be an implicit assumption that the end host and its > >>>> ITR (xTR) are in the same domain or Autonomous System. For incremen= tal > >> > >> This is true when you call the domain a "LISP site". But if the site i= s > >> unchanged and one uses PITRs, maybe even close to the site, like in a = PE > >> router, then the PITR is definitely in another AS. But note I said PIT= R and > >> not ITR. The reason being is because an ITR is configured with databas= e- > >> mapping prefixes that is uses to encapsulate packets from such address= es. > >> Versus the PITR being an ITR with *no database-mappings* providing a m= uch > more > >> larger/or more aggregtable service. > >> > >>>> deployment, I don't think that's always the case, but I think that o= nly > >>>> has editorial impact on this document, as I don't think any of the > >>>> fundamental LISP mechanisms are affected. The authors should look f= or > >>>> use of "domain" and "Autonomous System" and ensure that the text is > >>>> generalized to the case where the end host and ITR are more widely > >>>> separated. > >> > >> We are overloaded with terms that create topological or organization > boundary. > >> Hence why we created "LISP site" which is also the same as a "LISP VPN > site". > >> Where a "LISP site" that has multiple tennants would be multiple "LISP= VPN > >> sites". > >> > >>>> Despite multiple mentions of incremental deployment, I did not > >>>> see a discussion of how that might be accomplished. There is some > >> > >> There are PxTRs and NATs. And references to the LISP interworking RFC. > >> > >>>> useful content in Section 3.5, but that's at best an incomplete > >>>> explanation. This is an OPS-Dir review concern - it falls under > >>>> A.1.3 in Appendix A of RFC 5706: Has the migration path been discuss= ed? > >>>> > >>>> - 3.3.1. LISP Encapsulation > >>>> > >>>> the source port is selected by > >>>> the ITR and ignored on reception. > >>>> > >>>> Please mention multipathing (e.g., ECMP and LAG) as possible influen= ces > >>>> on how source ports are selected, as this imposes some limits on wha= t an > >>>> ITR can reasonably do. > >> > >> ECMP/LAG don't influence which source port is selected. It is a 5-tupl= e > hash > >> of the inner header that selects a source port that influences how an > underlay > >> router would load-split traffic. > >> > >>>> For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix= A of > >>>> RFC 5706: Have the Requirements on other protocols and functional > >>>> components been discussed? > >>>> > >>>> This decision was made because the > >>>> typical transport protocols used by the applications already inclu= de > >>>> a checksum, by neglecting the additional UDP encapsulation checksu= m > >>>> xTRs can forward packets more efficiently. > >>>> > >>>> Groan! I have an exquisite set of scars on UDP zero checksums for I= Pv6 > >>>> from working on the MPLS in UDP draft, so I may be overly sensitive = to > >>>> this concern. The downside of this efficiency is that there is no > >>>> checksum coverage of the IPv6 header when zero UDP checksums are use= d. > >>>> That should at least be mentioned here, with a summary of why that's= ok > >>>> - the detailed justification for why that's ok can be left to other > >>>> documents. > >> > >> My head spins every time I hear about this subject. This subject has b= een > >> talked about from 100s of people for a decade. We have CRC on links, w= e > have > >> apps that use TCP and UDP checksums. Nuf said. > >> > >>>> > >>>> -- Nits/Editorial Comments -- > >>>> > >>>> - Top of p.4: > >>>> > >>>> The initial motivation in the LISP effort is to be find in the > >>>> > >>>> "find" -> "found" > >>>> > >>>> - Section 3.1, first bullet item > >> > >> We will certainly fixe these. Thanks. > >> > >>>> > >>>> Devices are assigned with relatively opaque identity > >>>> meaningful addresses that are independent of their topological > >>>> location. > >>>> > >>>> I don't understand "relatively opaque identity meaningful" and > >>>> suggest rewriting the sentence. In particular - opaque to what? > >>>> meaningful to what in what manner? > >> > >> Well beacuse it is as accurate as it can be. If automobiles are going = to be > >> assigned EIDs from a VIN number allocation from a manufacture, the add= ress > is > >> relatively opaque. If a VM in a data-center is going to be assigned an= EID > >> from the set of prefixes already being used and allocated to that data= - > center, > >> then there is a good chance that address is in a power-of-2 block that= is > >> summarizable in the IGP. > >> > >>>> > >>>> - Section 3.2, second paragraph > >>>> > >>>> Judging from the figure, xTRs are the common case, with single- > >>>> function ITRs and ETRs being rare. It might be good to say that > >>>> and discuss when ITRs and ETRs that are not xTRs are appropriate > >>>> to use. > >> > >> When you want egress path selection to happen further out in the toplo= gical > >> from the source location, then you put an ITR-only system there. Where > ingress > >> to the same source (destination in this direction), the ETR can be clo= ser > to > >> the destination. > >> > >>>> > >>>> - 3rd paragraph on p.7: > >>>> > >>>> > >>>> Finally, the LISP architecture emphasizes a cost effective > >>>> incremental deployment. > >>>> > >>>> I'd delete "cost effective" here and look for other occurrences > >>>> of "cost" as candidates for deletion. This is supposed to be > >>>> a technical document, so discussion of costs is a bit off-target. > >> > >> Fair enough. > >> > >>>> - First item after Figure 2: > >>>> > >>>> 1. HostA retrieves the EID_B of HostB, typically querying the DNS > >>>> and obtaining and A or AAAA record. > >>>> > >>>> "and A" -> "an A" (spelling checkers don't catch everything). > >> > >> Already noted and will be fixed. > >> > >>>> > >>>> - 3.3.1. LISP Encapsulation > >>>> > >>>> On the other hand, Recursive > >>>> tunnels are nested tunnels and are implemented by using multiple L= ISP > >>>> encapsulations on a packet. > >>>> > >>>> The above sentence seems out of place in the middle of a paragraph a= bout > >>>> Re-encapsulating tunnels and routers - I suggest moving it down into= its > >>>> own paragraph and perhaps adding a sentence about where/how Recursiv= e > >>>> tunnels may be useful. > >> > >> Good suggestion and makes sense. > >> > >>>> - 3.3.2. LISP Forwarding State > >>>> > >>>> In the LISP architecture, ITRs keep just enough information to rou= te > >>>> traffic flowing through it. > >>>> > >>>> "it." -> "them." > >>>> > >>>> Meaning that, ITRs retrieve from the > >>>> LISP Mapping System mappings between EID prefixes and RLOCs that a= re > >>>> used to encapsulate packets. > >>>> > >>>> This is the first use of the notion of EID prefixes. That concept s= hould > >>>> be explained before it is used, although a forward reference to sect= ion > >>>> 3.4.1 may suffice. It might be better to rewrite this paragraph in = terms > >>>> of EIDs and leave the notion of EID prefixes to section 3.4.1. > >> > >> Hmm, I'll let Albert and Damien decide if we should state "EID-prefixe= s" > >> everywhere instead of just "EID". > >> > >>>> > >>>> - 4.4. MTU Handling > >>>> > >>>> Additionally, LISP also recommends inferring reachability of locat= ors > >>>> by using information provided by the underlay, in particular: > >>>> > >>>> It'd be useful to add a sentence or two about how LISP and the techn= iques > >>>> in this section interact with host use of PMTUD and PLPMTUD. > >> > >> This is a lot of detail because in RFC6830 we have 3 positions or opti= ons > on > >> the subject. And we did provide a reference to RFC6830 for this topic. > >> > >>>> - Next to last paragraph on p.17: > >>>> > >>>> Additionally, LISP also recommends inferring reachability of locat= ors > >>>> by using information provided by the underlay, in particular: > >>>> > >>>> This looks like it's a paragraph early and needs to be moved down to > >>>> after the paragraph that follows it. > >> > >> Agree. > >> > >>>> idnits 2.13.01 didn't find any nits. > >>>> > >>>> Thanks, > >>>> --David > >> > >> Thanks again David. > >> > >> Dino > > From nobody Thu Feb 12 06:59:22 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA15E1A909C; Thu, 12 Feb 2015 06:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-E4HQjqXy8M; Thu, 12 Feb 2015 06:59:16 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2AD1A9128; Thu, 12 Feb 2015 06:59:09 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEx4eh004637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 09:59:06 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t1CEx4eh004637 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423753146; bh=IM1+xjtK9mZHJtVM0uKYhzKpC0g=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=pLCJWxA7SinQuypPYA3Y9LYfzJ4B/ZT9JR/uyPAqhCf0ZEXNRNnqCyn7yPG7fEaIa 8JVPo8r2Gxz5zPngBWh4gZqT9GKpSjzzfZc9HycDGowbVv4aeBHd7tBVmE4vTdXNsw eDSBqacaKwcF+KOTsDoNXSP+SiE+DpkteX7R8mL0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t1CEx4eh004637 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd04.lss.emc.com (RSA Interceptor); Thu, 12 Feb 2015 09:58:49 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CEwqAm023962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 09:58:52 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub06.corp.emc.com (128.222.70.203) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 12 Feb 2015 09:58:52 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 09:58:51 -0500 From: "Black, David" To: Dino Farinacci Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] Thread-Index: AdBG00B2C5gGCfkjSoSGM0r5AEMtyQAKst+AAAp1mJA= Date: Thu, 12 Feb 2015 14:58:51 +0000 Message-ID: References: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> In-Reply-To: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , "Black, David" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:59:19 -0000 "can be the same" is fine (i.e., if the mapping produces the same output as= its input, that's ok, but mapping is involved). The current draft text (as I read it) implies "are always the same" and tha= t needs to be corrected. Thanks, --David > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Thursday, February 12, 2015 9:57 AM > To: Black, David > Cc: Luigi Iannone; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; Dami= en > Saucez; ietf@ietf.org > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] >=20 > They can be the same if the underlay provider wants to control overlay's = group > address allocation. >=20 > Dino >=20 >=20 > > On Feb 12, 2015, at 6:50 AM, Black, David wrote: > > > > I don't care what terms are used - it just needs to be absolutely clear= that > > the inner and outer multicast addresses are not the same and that mappi= ng > > between them (which could take a number of forms) is involved. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farinacci@gmail.com] > >> Sent: Thursday, February 12, 2015 8:15 AM > >> To: Luigi Iannone > >> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; Da= mien > >> Saucez; ietf@ietf.org > >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 > >> > >>> G-EID =3D> the EID multicast group G > >>> G-RLOC =3D> the RLOC multicast group G > >> > >> "inner and outer group addresses" have been used in various LISP multi= cast > >> documents. > >> > >> Dino From nobody Thu Feb 12 08:34:39 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67781A006F; Thu, 12 Feb 2015 08:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQcm8qJkqxTL; Thu, 12 Feb 2015 08:34:33 -0800 (PST) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (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 EA5331A00B2; Thu, 12 Feb 2015 08:34:32 -0800 (PST) Received: by pdbfp1 with SMTP id fp1so8731246pdb.5; Thu, 12 Feb 2015 08:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YGuhvx/n7wsBdv7t9n4w828QSVgnM4Wpl999GbKN8yU=; b=mHDGAThN5soNOCDiHuUe0wGbGIYfaI5JW3Tlk2OMF9AwrWXGEVUjJ3K2jgeYiHzGLK 344EmmHWCqxUjX0PK7oNSVTIyQ/UJc8wnSkN7CYTCZ0JYHg2l8iH5lUObVf3K5KyP8el qDfINsexCONGqhXWbT9g5Y/b5QyfSfK8TOpAvCe7k5qEbMci3WQh3et8c8JN4do09Pwt tCXrx9m6aeCXc5EgF0QIHBeqzpTQLUAXbeV7E/knhgjxXaWAEedM9QgkfRiNLpUWEiuh U48m/jbvf8+PFTOXDWzOk2WzF0tNnS5nG2jiIeQMyBRp8HbdSHyaVDRfmevVQ0CAxlQC rOXQ== X-Received: by 10.68.237.2 with SMTP id uy2mr7905303pbc.72.1423758872435; Thu, 12 Feb 2015 08:34:32 -0800 (PST) Received: from [192.168.1.238] ([207.145.253.66]) by mx.google.com with ESMTPSA id z1sm4198325pda.78.2015.02.12.08.34.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 08:34:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: Date: Thu, 12 Feb 2015 07:37:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9B998A6E-BFDA-48BB-BC91-5134A294ADF1@gmail.com> References: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> To: "Black, David" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:34:36 -0000 Got it. Agree. Dino > On Feb 12, 2015, at 6:58 AM, Black, David wrote: >=20 > "can be the same" is fine (i.e., if the mapping produces the same = output as its input, that's ok, but mapping is involved). > The current draft text (as I read it) implies "are always the same" = and that needs to be corrected. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Thursday, February 12, 2015 9:57 AM >> To: Black, David >> Cc: Luigi Iannone; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; = Damien >> Saucez; ietf@ietf.org >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 = [B] >>=20 >> They can be the same if the underlay provider wants to control = overlay's group >> address allocation. >>=20 >> Dino >>=20 >>=20 >>> On Feb 12, 2015, at 6:50 AM, Black, David = wrote: >>>=20 >>> I don't care what terms are used - it just needs to be absolutely = clear that >>> the inner and outer multicast addresses are not the same and that = mapping >>> between them (which could take a number of forms) is involved. >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Thursday, February 12, 2015 8:15 AM >>>> To: Luigi Iannone >>>> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; = Damien >>>> Saucez; ietf@ietf.org >>>> Subject: Re: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11 >>>>=20 >>>>> G-EID =3D> the EID multicast group G >>>>> G-RLOC =3D> the RLOC multicast group G >>>>=20 >>>> "inner and outer group addresses" have been used in various LISP = multicast >>>> documents. >>>>=20 >>>> Dino From nobody Thu Feb 12 08:36:01 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B79F1A00A2; Thu, 12 Feb 2015 08:35:59 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLuDHIR8L8ou; Thu, 12 Feb 2015 08:35:50 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135B11A00E6; Thu, 12 Feb 2015 08:35:50 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id kx10so12525461pab.0; Thu, 12 Feb 2015 08:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n6mvWGmmKVxybYWFNkQEROkEA9br2ArFz9/GURBmWr0=; b=T+4DphQSK9sfOadxO6hIW+dm1PZLlTCTkYgZDx0LDl901weiuRwxSMSo51sBBRDO36 ulJuwkKrbN5na6Th8YjFCISAAXSl6z2MsHbtwUV26D2Os1PQ3BKQ8RDSIZWED7kyrQ7e NIrQhd0wGuZC2GYpyR1aU9+caDwOapSJZxrAQfF6GQAIg0DB8vpGDSiyDO/mxzFY1rfW 30qq9EWikURvxu7Bpr6D1lY89tqj61dqNd3P6OXWiMTm8Ac7IukqDtoYSQtGELEYtrUc Jj0ftPSVcIxbbGAwIQbzmV3XAcHoX53UZ+3yp0Mx9ls8CA1qThjRjcdvmlqJSCcseCM8 Kmeg== X-Received: by 10.70.103.162 with SMTP id fx2mr8142687pdb.24.1423758949321; Thu, 12 Feb 2015 08:35:49 -0800 (PST) Received: from [192.168.1.238] ([207.145.253.66]) by mx.google.com with ESMTPSA id z1sm4198325pda.78.2015.02.12.08.35.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 08:35:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: Date: Thu, 12 Feb 2015 08:07:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Black, David" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "lisp@ietf.org" , Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 - UDP source port X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:35:59 -0000 Ack. Agree. Dino > On Feb 12, 2015, at 6:56 AM, Black, David wrote: >=20 > [A] and [B] are handled in other messages. On UDP source port = selection: >=20 >>> Please state that a 5-tuple hash is used. ECMP/LAG is among the = important >>=20 >> Well there can be other ways to hash and that is detail not needed at = this level IMO. We suggest a 5-tuple hash in RFC6830. >>=20 >>> reasons why, but that doesn't need to be stated if you prefer not = to. An >>> example of something that needs to be excluded is that using a = random >>> number generator to set the source port would be wrong - I could = suggest >>> citing draft-ietf-dart-dscp-rtp for related discussion (and lots = more >>> details), but I don't think that's necessary. >>=20 >> How about stating the source-port should not change for a flow or it = causes an underlay router to >> resequence packets over lags? >=20 > This is for ECMP in addition to LAG - if you go this route, please do = cite the dart draft (informative reference) for its supporting = discussion about transport protocol (mis)behavior in the face of = within-flow resequencing. It would also be helpful to say that a = 5-tuple hash is one way to achieve this (and see RFC 6830 for details). >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, February 11, 2015 11:40 PM >> To: Black, David >> Cc: Joel M. Halpern; Albert Cabellos; Damien Saucez; = ops-dir@ietf.org; >> ietf@ietf.org; lisp@ietf.org >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >>=20 >>> Dino - thanks for the response. >>>=20 >>> On the major issues, it looks like both [A] and [B] involve only the = text >>> in this draft and nothing beyond, which is good news. I have a = simple text >>> suggestion for [A], but it looks like [B] is going to require some = careful >>> editing, as one of the primary causes is that the draft is sloppy in = using >>> the same symbol "G" to represent both EID and RLOC multicast groups. >>=20 >> Okay for [A] but not true for [B]. In RFC6831, a multicast address G = is not in >> the mapping database because signaling is performed from ETR to ITR. = What's in >> the mapping database is the EID S from the (S,G) the source sends = from and to. >>=20 >>> On the minor issues, I have text suggestions for three of the four, = and >>> I'd like to temporarily defer further discussion the IPv6 UDP zero >>> checksum "tarpit" in favor of resolving everything else first. >>=20 >> Sounds good David. >>=20 >>> On the nits/editorial comments, all the suggestions in your email = are fine >>> with me. FWIW, I regard that portion of a review as almost entirely >>> subject to the draft authors' discretion (and editorial taste). >>>=20 >>>>>> [A] EID mobility vs. EID prefixes >>>>=20 >>>> ... from the start of the LISP design (circa 2007), an prefix is = what >> moves. >>>> And a specific EID is simply a /32 or /128 prefix. Here is a = practical >>>> example: >>>=20 >>> A statement that the mobility use cases need to employ /32 and /128 >> prefixes, >>> and not anything coarser should suffice. That should be added to = Section 5. >>=20 >> Well I think it is not true. Because EID-prefixes are moved but is = outside of >> the VM-mobility use-case. >>=20 >>>=20 >>>>>> [B] LISP Multicast vs. EID/RLOC separate >>>>>>=20 >>>>>> - 6. Multicast >>>>>>=20 >>>>>> This is interesting, multicast addresses (G) look like they're an >> exception >>>>=20 >>>> They are really not. >>>=20 >>> My concern is that as I read the draft, it leaves me with the strong >> impression >>> that the same multicast addresses (G) are being used in both the = overlay >>> (as EIDs) and the underlay (as RLOCs). =46rom your response, I = conclude that >> this >>=20 >> Understand. We state in RFC6831 that it can map one-to-one or = many-to-one. >> We'll make that more clear in the introduction document. >>=20 >>> is not the case (and I have no argument with that). Rather, Section = 6 needs >> to >>> bluntly state that multicast addresses are mapped between EID and = RLOC space >> at >>> both ITRs and ETRs, so that the following inference is obvious from = the text >>> (it's currently not obvious): >>=20 >> Right, agree. >>=20 >>> So it makes perfect sense to register multicast addresses to the = mapping >>>> system as EIDs and they can map to RLOCs of sites that have joined = the >> group. >>>=20 >>> As part of this, I strongly recommend moving away from use of "G" to = refer >> to >>> multicast groups in both the overlay and underlay. Careful use of = G-EID >>> and G-RLOC would significantly improve clarity. >>=20 >> Well we have not used G-EID in any documentation. And since we want = to >> encourage the use of SSM in the underlay and how we signal in the = overlay, we >> simply call the "eid" the 2-tuple (S,G). >>=20 >>> --- >>> If the above are done for [A] and [B] in Sections 5 and 6, then the = text for >> the >>> use cases in Section 7 should not need further attention. >>> --- >>>=20 >>>>>> -- Minor Issues -- >>>>>>=20 >>>>>> There seems to be an implicit assumption that the end host and = its >>>>>> ITR (xTR) are in the same domain or Autonomous System. For = incremental >>>>=20 >>>> This is true when you call the domain a "LISP site". But if the = site is >>>> unchanged and one uses PITRs, maybe even close to the site, like in = a PE >>>> router, then the PITR is definitely in another AS. >>>=20 >>> Looking at the text, it seems that "LISP site" and "domain" are the = same >>> concept for this draft. That would be useful to state, IMHO but = I'll leave >>> the decision on whether to do so to you and the draft authors. >>>=20 >>> On rereading, my concerns seem to be triggered mostly by this = sentence in >>> Section 3.2: >>>=20 >>> The edge consists of LISP sites (e.g., an >>> Autonomous System) that use EID addresses. >>>=20 >>> I think a small change to the last sentence in that paragraph would = resolve >>> my concern without distracting from the narrative: >>>=20 >>> OLD >>> EIDs do not >>> contain inter-domain topological information and because of this, >>> EIDs are usually routable at the edge (within LISP sites) or in the >>> non-LISP Internet. >>> NEW >>> EIDs do not >>> contain inter-domain topological information and because of this, >>> EIDs are usually routable at the edge (within LISP sites) or in the >>> non-LISP Internet; see Section 3.5 for discussion of LISP site >>> internetworking with non-LISP sites and domains in the Internet. >>=20 >> Ack. >>=20 >>>=20 >>>>>> Despite multiple mentions of incremental deployment, I did not >>>>>> see a discussion of how that might be accomplished. >>>>=20 >>>> There are PxTRs and NATs. And references to the LISP interworking = RFC. >>>=20 >>> Ok, can we just say so in Section 3.5? Adding the following = sentence >>> to the end of the section would suffice: >>>=20 >>> PITRs, PETRs and LISP-NAT support incremental deployment of LISP >>> by providing significant flexibility in location of the boundaries >>> between the LISP and non-LISP portions of the network, and making >>> it reasonable to change those boundaries over time. >>=20 >> Yes. >>=20 >>> - 3.3.1. LISP Encapsulation >>>>>>=20 >>>>>> the source port is selected by >>>>>> the ITR and ignored on reception. >>>>>>=20 >>>>>> Please mention multipathing (e.g., ECMP and LAG) as possible = influences >>>>>> on how source ports are selected, as this imposes some limits on = what an >>>>>> ITR can reasonably do. >>>>=20 >>>> ECMP/LAG don't influence which source port is selected. It is a = 5-tuple >> hash >>>> of the inner header that selects a source port that influences how = an >> underlay >>>> router would load-split traffic. >>>=20 >>> Please state that a 5-tuple hash is used. ECMP/LAG is among the = important >>=20 >> Well there can be other ways to hash and that is detail not needed at = this >> level IMO. We suggest a 5-tuple hash in RFC6830. >>=20 >>> reasons why, but that doesn't need to be stated if you prefer not = to. An >>> example of something that needs to be excluded is that using a = random >>> number generator to set the source port would be wrong - I could = suggest >>> citing draft-ietf-dart-dscp-rtp for related discussion (and lots = more >>> details), but I don't think that's necessary. >>=20 >> How about stating the source-port should not change for a flow or it = causes an >> underlay router to resequence packets over lags? >>=20 >>> -- IPv6 zero UDP checksum >>>=20 >>>> My head spins every time I hear about this subject. This subject = has been >>>> talked about from 100s of people for a decade. We have CRC on = links, we >> have >>>> apps that use TCP and UDP checksums. Nuf said. >>>=20 >>> Understood - there's more than one set of scars on this one :-(. = Let's come >> back >>> to this topic after we've resolved everything else, and please keep = in mind >>> that I tagged this as a minor issue, not a major one (e.g., the = above >> changes >>> for [A] and [B] are far more important, IMHO). >>=20 >> Ack. Thanks again. >>=20 >> Dino >>=20 >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Wednesday, February 11, 2015 2:19 PM >>>> To: Joel M. Halpern >>>> Cc: Black, David; Albert Cabellos; Damien Saucez; ops-dir@ietf.org; >>>> ietf@ietf.org; lisp@ietf.org >>>> Subject: Re: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11 >>>>=20 >>>>> I will leave most of these for the authors to comment on. >>>>=20 >>>> See my comments inline. Thanks David for your detailed review and >> commentary. >>>>=20 >>>>> With regard to your question about incremental deployment, that is = the >>>> domain of the LISP Deployment document, and was deliberately only = lightly >>>> covered here. I am not sure what we can do to address your comment = without >>>> duplicating the entirety of that document. >>>>=20 >>>> That is the risk we may have with many of your comments. We have a = lot of >>>> detail in the already 9 published RFCs and this document really is = to take >>>> all that detail and summarize as an easily understandable = description of a >>>> cohesive design. >>>>=20 >>>>> With regard to UDP Zero, this was approved by the IESG and = published as an >>>> RFC. It is part of the way the protocol is defined. If there are = specific >>>> changes you would like to see in the explanatory text, I am sure >>>>=20 >>>> Definitely agreed. In fact we instigated UDP zero. And I = continually talk >> to >>>> hardware engineers and they all believe we made the right decision. = So hats >>>> off to the IETF for being practical. >>>>=20 >>>>> we could include them. If you are looking for a change in the = behavior, >>>> this document can not make changes to the LISP behavior. >>>>=20 >>>> Yes, an important point. >>>>=20 >>>>>> I found a couple of major issues that I hope arise from the >>>>>> summarization of LISP in this draft, as opposed to being problems = in >>>>>> the actual LISP protocols. I also found a few minor issues, the = most >>>>>> important of which is the need for additional security = considerations >>>>>> discussion on misdelivery, with particular attention to VPNs. >>>>=20 >>>> Thanks a ton. >>>>=20 >>>>>> -- Major issues -- >>>>>>=20 >>>>>> [A] EID mobility vs. EID prefixes >>>>>>=20 >>>>>> - 5. Mobility >>>>>>=20 >>>>>> I understand how this works when mapping is per-EID, but how does = this >> work >>>>>> when the EID of the system that moves is part of an EID prefix, = as >>>> discussed >>>>>> in Section 3.4.1? Even if the answer is a long version of "Don't = do >> that!" >>>>>> it should be explained. >>>>=20 >>>> No, from the start of the LISP design (circa 2007), an prefix is = what >> moves. >>>> And a specific EID is simply a /32 or /128 prefix. Here is a = practical >>>> example: >>>>=20 >>>> You have a cluster of servers that communicate together for a = particular >>>> application. They application cluster is running in a set of VMs. = Those VMs >>>> are assigned EIDs from a common power-of-2 EID-prefix. Those VMs = are >> currently >>>> running in a brick-and-mortar data center. Now there is a desire to = move >> the >>>> VM cluster to a cloud provider. What is moved is the EID-prefix of = the >>>> cluster. The mapping system is told that the EID-prefix is changing = its >> RLOC- >>>> set from the brick-and-mortar xTRs to the cloud providers xTRs. >>>>=20 >>>>>>=20 >>>>>> - 7.4. LISP for Virtual Machine Mobility in Data Centers >>>>>>=20 >>>>>> I don't understand how this works when EID prefixes are used, as = each VM >>>>>> has its own EID or EIDs, hence the entire prefix range does not = move when >>>>>> the VM moves. >>>>>>=20 >>>>>> For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in = Appendix A >>>>>> of RFC 5706: Has deployment been discussed? and specifically = under: >>>>>>=20 >>>>>> * Is the proposed specification deployable? If not, how = could >>>>>> it be improved? >>>>>>=20 >>>>>> as EID prefixes appear to be undeployable for Mobility and VM = Mobility >>>> usage. >>>>=20 >>>> See above example. >>>>=20 >>>>>> [B] LISP Multicast vs. EID/RLOC separate >>>>>>=20 >>>>>> - 6. Multicast >>>>>>=20 >>>>>> This is interesting, multicast addresses (G) look like they're an >> exception >>>>=20 >>>> They are really not. Since multicast addresses *identify* a group = of >>>> receivers, it is very much an EID and aheres to the definition of = an EID. >>>> Multicast addresses never had topological signficance but the state >>>> representing a distribution tree does tell you were the members are = (but >> the >>>> identity of the members are not know in multicast). >>>>=20 >>>> So it makes perfect sense to register multicast addresses to the = mapping >>>> system as EIDs and they can map to RLOCs of sites that have joined = the >> group. >>>> See draft-farinacci-signal-free-multicast as just one example. = RFC6831 and >>>> draft-farinacci-lisp-mr-signaling are other examples. >>>>=20 >>>>>> to the EID/RLOC separation as the same destination IP multicast = address >>>>>> is used for both purposes. This could use some more discussion, = as it's >>>>>> unexpected based on the contents of the draft up to this point. >>>>=20 >>>> I believe the level of detail we have in the introduction document = is at >> the >>>> right level or we'll err on having way too many details crop in. >>>>=20 >>>>>> - 7.2. LISP for IPv6 Co-existence >>>>>>=20 >>>>>> LISP encapsulations allows to transport packets using EIDs from = a >>>>>> given address family (e.g., IPv6) with packets from other = address >>>>>> families (e.g., IPv4). >>>>>>=20 >>>>>> How does that work for multicast traffic, where the destination = address >>>>>> (G) has to be the same in both the inner and outer headers? Are = ETRs >>>>>> and ITRs expected to map IPv6 multicast addresses to IPv4 and = v.v.? >>>>=20 >>>> The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a = RLOC >> set >>>> that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR = that >>>> receives the packet from S-EID-ipv6 would replicate the packet and >> multicast >>>> encapsulate to ipv4-multicast and unicast encapsualte to = ipv4-unicast. >>>>=20 >>>>>> - 7.3. LISP for Virtual Private Networks >>>>>>=20 >>>>>> This also has multicast problems, as there is only one instance = of each >>>>>> multicast address (G) in the underlay network. I think I can = figure out >>>> how >>>>=20 >>>> You can map from EID-G to RLOC-G one to one. But we have seen over = the last >>>> decade in a half that with general multicast deployment that = many-to-1 is >>>> desirable. Hence, now that we have a way to map with a = network-based >> database, >>>> we can map multiple EID-Gs to a single (or multiple) RLOC-Gs. >>>>=20 >>>>>> to make multicast work for this use case, but it's not = immediately >> obvious, >>>>>> and the result when the same underlay multicast address is used = by more >>>>>> than one VPN could well deliver some traffic to ETRs that have to = discard >>>>=20 >>>> This is a necessary evil when the underlay is state challenged. But = it is a >>>> state/bandwidth tradeoff. We have found with MVPN deployment that = the >> network >>>> admin configures the underly or simply unicasts. >>>>=20 >>>>>> it because the Instance ID is wrong (and that excessive delivery = is a >>>>>> security consideration, see minor issue on Section 8 below). I = think an >>>>>> explanation is in order. >>>>=20 >>>> There are just too many combinations to make a high-level = description >> simple >>>> to understand. The current introduction text does a find job = providing >>>> references for someone to go off and get the details. >>>>=20 >>>>>> -- Minor Issues -- >>>>>>=20 >>>>>> There seems to be an implicit assumption that the end host and = its >>>>>> ITR (xTR) are in the same domain or Autonomous System. For = incremental >>>>=20 >>>> This is true when you call the domain a "LISP site". But if the = site is >>>> unchanged and one uses PITRs, maybe even close to the site, like in = a PE >>>> router, then the PITR is definitely in another AS. But note I said = PITR and >>>> not ITR. The reason being is because an ITR is configured with = database- >>>> mapping prefixes that is uses to encapsulate packets from such = addresses. >>>> Versus the PITR being an ITR with *no database-mappings* providing = a much >> more >>>> larger/or more aggregtable service. >>>>=20 >>>>>> deployment, I don't think that's always the case, but I think = that only >>>>>> has editorial impact on this document, as I don't think any of = the >>>>>> fundamental LISP mechanisms are affected. The authors should = look for >>>>>> use of "domain" and "Autonomous System" and ensure that the text = is >>>>>> generalized to the case where the end host and ITR are more = widely >>>>>> separated. >>>>=20 >>>> We are overloaded with terms that create topological or = organization >> boundary. >>>> Hence why we created "LISP site" which is also the same as a "LISP = VPN >> site". >>>> Where a "LISP site" that has multiple tennants would be multiple = "LISP VPN >>>> sites". >>>>=20 >>>>>> Despite multiple mentions of incremental deployment, I did not >>>>>> see a discussion of how that might be accomplished. There is = some >>>>=20 >>>> There are PxTRs and NATs. And references to the LISP interworking = RFC. >>>>=20 >>>>>> useful content in Section 3.5, but that's at best an incomplete >>>>>> explanation. This is an OPS-Dir review concern - it falls under >>>>>> A.1.3 in Appendix A of RFC 5706: Has the migration path been = discussed? >>>>>>=20 >>>>>> - 3.3.1. LISP Encapsulation >>>>>>=20 >>>>>> the source port is selected by >>>>>> the ITR and ignored on reception. >>>>>>=20 >>>>>> Please mention multipathing (e.g., ECMP and LAG) as possible = influences >>>>>> on how source ports are selected, as this imposes some limits on = what an >>>>>> ITR can reasonably do. >>>>=20 >>>> ECMP/LAG don't influence which source port is selected. It is a = 5-tuple >> hash >>>> of the inner header that selects a source port that influences how = an >> underlay >>>> router would load-split traffic. >>>>=20 >>>>>> For OPS-Dir, this multipathing concern falls under A.1.4 in = Appendix A of >>>>>> RFC 5706: Have the Requirements on other protocols and functional >>>>>> components been discussed? >>>>>>=20 >>>>>> This decision was made because the >>>>>> typical transport protocols used by the applications already = include >>>>>> a checksum, by neglecting the additional UDP encapsulation = checksum >>>>>> xTRs can forward packets more efficiently. >>>>>>=20 >>>>>> Groan! I have an exquisite set of scars on UDP zero checksums = for IPv6 >>>>>> from working on the MPLS in UDP draft, so I may be overly = sensitive to >>>>>> this concern. The downside of this efficiency is that there is = no >>>>>> checksum coverage of the IPv6 header when zero UDP checksums are = used. >>>>>> That should at least be mentioned here, with a summary of why = that's ok >>>>>> - the detailed justification for why that's ok can be left to = other >>>>>> documents. >>>>=20 >>>> My head spins every time I hear about this subject. This subject = has been >>>> talked about from 100s of people for a decade. We have CRC on = links, we >> have >>>> apps that use TCP and UDP checksums. Nuf said. >>>>=20 >>>>>>=20 >>>>>> -- Nits/Editorial Comments -- >>>>>>=20 >>>>>> - Top of p.4: >>>>>>=20 >>>>>> The initial motivation in the LISP effort is to be find in the >>>>>>=20 >>>>>> "find" -> "found" >>>>>>=20 >>>>>> - Section 3.1, first bullet item >>>>=20 >>>> We will certainly fixe these. Thanks. >>>>=20 >>>>>>=20 >>>>>> Devices are assigned with relatively opaque identity >>>>>> meaningful addresses that are independent of their = topological >>>>>> location. >>>>>>=20 >>>>>> I don't understand "relatively opaque identity meaningful" and >>>>>> suggest rewriting the sentence. In particular - opaque to what? >>>>>> meaningful to what in what manner? >>>>=20 >>>> Well beacuse it is as accurate as it can be. If automobiles are = going to be >>>> assigned EIDs from a VIN number allocation from a manufacture, the = address >> is >>>> relatively opaque. If a VM in a data-center is going to be assigned = an EID >>>> from the set of prefixes already being used and allocated to that = data- >> center, >>>> then there is a good chance that address is in a power-of-2 block = that is >>>> summarizable in the IGP. >>>>=20 >>>>>>=20 >>>>>> - Section 3.2, second paragraph >>>>>>=20 >>>>>> Judging from the figure, xTRs are the common case, with single- >>>>>> function ITRs and ETRs being rare. It might be good to say that >>>>>> and discuss when ITRs and ETRs that are not xTRs are appropriate >>>>>> to use. >>>>=20 >>>> When you want egress path selection to happen further out in the = toplogical >>>> from the source location, then you put an ITR-only system there. = Where >> ingress >>>> to the same source (destination in this direction), the ETR can be = closer >> to >>>> the destination. >>>>=20 >>>>>>=20 >>>>>> - 3rd paragraph on p.7: >>>>>>=20 >>>>>>=20 >>>>>> Finally, the LISP architecture emphasizes a cost effective >>>>>> incremental deployment. >>>>>>=20 >>>>>> I'd delete "cost effective" here and look for other occurrences >>>>>> of "cost" as candidates for deletion. This is supposed to be >>>>>> a technical document, so discussion of costs is a bit off-target. >>>>=20 >>>> Fair enough. >>>>=20 >>>>>> - First item after Figure 2: >>>>>>=20 >>>>>> 1. HostA retrieves the EID_B of HostB, typically querying the = DNS >>>>>> and obtaining and A or AAAA record. >>>>>>=20 >>>>>> "and A" -> "an A" (spelling checkers don't catch everything). >>>>=20 >>>> Already noted and will be fixed. >>>>=20 >>>>>>=20 >>>>>> - 3.3.1. LISP Encapsulation >>>>>>=20 >>>>>> On the other hand, Recursive >>>>>> tunnels are nested tunnels and are implemented by using multiple = LISP >>>>>> encapsulations on a packet. >>>>>>=20 >>>>>> The above sentence seems out of place in the middle of a = paragraph about >>>>>> Re-encapsulating tunnels and routers - I suggest moving it down = into its >>>>>> own paragraph and perhaps adding a sentence about where/how = Recursive >>>>>> tunnels may be useful. >>>>=20 >>>> Good suggestion and makes sense. >>>>=20 >>>>>> - 3.3.2. LISP Forwarding State >>>>>>=20 >>>>>> In the LISP architecture, ITRs keep just enough information to = route >>>>>> traffic flowing through it. >>>>>>=20 >>>>>> "it." -> "them." >>>>>>=20 >>>>>> Meaning that, ITRs retrieve from the >>>>>> LISP Mapping System mappings between EID prefixes and RLOCs that = are >>>>>> used to encapsulate packets. >>>>>>=20 >>>>>> This is the first use of the notion of EID prefixes. That = concept should >>>>>> be explained before it is used, although a forward reference to = section >>>>>> 3.4.1 may suffice. It might be better to rewrite this paragraph = in terms >>>>>> of EIDs and leave the notion of EID prefixes to section 3.4.1. >>>>=20 >>>> Hmm, I'll let Albert and Damien decide if we should state = "EID-prefixes" >>>> everywhere instead of just "EID". >>>>=20 >>>>>>=20 >>>>>> - 4.4. MTU Handling >>>>>>=20 >>>>>> Additionally, LISP also recommends inferring reachability of = locators >>>>>> by using information provided by the underlay, in particular: >>>>>>=20 >>>>>> It'd be useful to add a sentence or two about how LISP and the = techniques >>>>>> in this section interact with host use of PMTUD and PLPMTUD. >>>>=20 >>>> This is a lot of detail because in RFC6830 we have 3 positions or = options >> on >>>> the subject. And we did provide a reference to RFC6830 for this = topic. >>>>=20 >>>>>> - Next to last paragraph on p.17: >>>>>>=20 >>>>>> Additionally, LISP also recommends inferring reachability of = locators >>>>>> by using information provided by the underlay, in particular: >>>>>>=20 >>>>>> This looks like it's a paragraph early and needs to be moved down = to >>>>>> after the paragraph that follows it. >>>>=20 >>>> Agree. >>>>=20 >>>>>> idnits 2.13.01 didn't find any nits. >>>>>>=20 >>>>>> Thanks, >>>>>> --David >>>>=20 >>>> Thanks again David. >>>>=20 >>>> Dino >>>=20 >=20 From nobody Fri Feb 13 00:37:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397991A1B89 for ; Fri, 13 Feb 2015 00:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 72mP6hQQ5uxD for ; Fri, 13 Feb 2015 00:37:41 -0800 (PST) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (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 7E1571A1A9E for ; Fri, 13 Feb 2015 00:37:39 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id p10so15157694wes.2 for ; Fri, 13 Feb 2015 00:37:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=559kFsmL8iABEJOithuqgK66SQJcU92pqtFbmSxT/iM=; b=EfWftH9eIYfCeJqU4s4r2PNpv8lVf3f7UyqAsVhFOKZVr5IdiiB8deEFpBiXoofu8U EFCUXF4Hs68AWylibwHRfquaH/nz1crMuAdaC0djF2kzdda7YtVfL0yM8RFFBpgjolk6 LzMaPJrVPb6KW6+X3YS6xDWB3ht3ighYtVqwWSS91IMUW+LzIkNYj2nLw7XwQmqui+ky REJ4qeS+LhoYFdRJTerUY5ivQsUUH2euVah4WnQ9fmGwZ1NTfL8K+hWY3tj0cDa9rUAg v2KpAibpZkwg/4BLz/5hjZ4S+Ko3r6KXPqQYu7kMdYnu8yUGSpsBqMXBuVcqKoPbDXLz 9rZw== X-Gm-Message-State: ALoCoQnLZB5JWoSVCb1QQPveoos8cp4+dKOGnrsjVgiONb+Jnqc1YDlwkkjkCiCcS7YDFQVokg1+ X-Received: by 10.195.12.71 with SMTP id eo7mr1746090wjd.3.1423816656867; Fri, 13 Feb 2015 00:37:36 -0800 (PST) Received: from ?IPv6:2001:660:330f:38:89fb:2200:b17c:be6f? ([2001:660:330f:38:89fb:2200:b17c:be6f]) by mx.google.com with ESMTPSA id hv5sm9101556wjb.16.2015.02.13.00.37.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Feb 2015 00:37:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Fri, 13 Feb 2015 09:37:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3AD27C2D-FFBF-44C8-8EC2-5FCFF9EB541F@gigix.net> References: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> To: "Black, David" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 08:37:42 -0000 > On 12 Feb 2015, at 15:58, Black, David wrote: >=20 > "can be the same" is fine (i.e., if the mapping produces the same = output as its input, that's ok, but mapping is involved). > The current draft text (as I read it) implies "are always the same" = and that needs to be corrected. >=20 Excellent progress thanks. So, no new terminology, just clarification that inner and outer = multicast groups are in general different (unless specific cases where = the underlay provider wants to introduce some tighter control on the = overlay. Did I get it right? L.=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Thursday, February 12, 2015 9:57 AM >> To: Black, David >> Cc: Luigi Iannone; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; = Damien >> Saucez; ietf@ietf.org >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 = [B] >>=20 >> They can be the same if the underlay provider wants to control = overlay's group >> address allocation. >>=20 >> Dino >>=20 >>=20 >>> On Feb 12, 2015, at 6:50 AM, Black, David = wrote: >>>=20 >>> I don't care what terms are used - it just needs to be absolutely = clear that >>> the inner and outer multicast addresses are not the same and that = mapping >>> between them (which could take a number of forms) is involved. >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Thursday, February 12, 2015 8:15 AM >>>> To: Luigi Iannone >>>> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; = Damien >>>> Saucez; ietf@ietf.org >>>> Subject: Re: [lisp] OPS-Dir review of = draft-ietf-lisp-introduction-11 >>>>=20 >>>>> G-EID =3D> the EID multicast group G >>>>> G-RLOC =3D> the RLOC multicast group G >>>>=20 >>>> "inner and outer group addresses" have been used in various LISP = multicast >>>> documents. >>>>=20 >>>> Dino From nobody Fri Feb 13 05:51:37 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFFD1A702C; Fri, 13 Feb 2015 05:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAic8xwFRyVA; Fri, 13 Feb 2015 05:51:32 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733811A701C; Fri, 13 Feb 2015 05:51:32 -0800 (PST) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1DDpRAL008474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 08:51:27 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t1DDpRAL008474 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423835488; bh=8hgI1GnkGrh31ijt7voJCkO3ih4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YhgHr37BIyib02Gl6g7pc9QwUg8YAyW92zotzr2LEsToOdodzhuNWWKsnGyLhAhuI kwMLRaBHAYWvi1ngK5FgscdT5sBTIRVBrQ8SocnFW+6JLVRX0McZW0JQS8PZ9M3Hwk j4RBz0Ka3VmjgoXTHyTJBcJ6nvY3A8/YbyosT9Y8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t1DDpRAL008474 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 13 Feb 2015 08:51:03 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1DDp7sx019056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 08:51:07 -0500 Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub08.corp.emc.com (128.222.70.205) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 13 Feb 2015 08:51:07 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB207.corp.emc.com ([10.253.68.33]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 08:51:06 -0500 From: "Black, David" To: Luigi Iannone Thread-Topic: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] Thread-Index: AdBG00B2C5gGCfkjSoSGM0r5AEMtyQAKst+AAAp1mJAAGpWoAAAAbJ9w Date: Fri, 13 Feb 2015 13:51:06 +0000 Message-ID: References: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> <3AD27C2D-FFBF-44C8-8EC2-5FCFF9EB541F@gigix.net> In-Reply-To: <3AD27C2D-FFBF-44C8-8EC2-5FCFF9EB541F@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 13:51:35 -0000 Yes. I think we've discussed and reached conclusions on everything except = whether to add text on the IPv6 UDP zero checksum topic. Could I suggest submissio= n of a -12 version of the draft that captures everything that's been discussed/r= esolved? Thanks, --David > -----Original Message----- > From: Luigi Iannone [mailto:ggx@gigix.net] > Sent: Friday, February 13, 2015 3:38 AM > To: Black, David > Cc: Dino Farinacci; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; Dam= ien > Saucez; ietf@ietf.org > Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] >=20 >=20 > > On 12 Feb 2015, at 15:58, Black, David wrote: > > > > "can be the same" is fine (i.e., if the mapping produces the same outpu= t as > its input, that's ok, but mapping is involved). > > The current draft text (as I read it) implies "are always the same" and= that > needs to be corrected. > > >=20 > Excellent progress thanks. >=20 > So, no new terminology, just clarification that inner and outer multicast > groups are in general different (unless specific cases where the underlay > provider wants to introduce some tighter control on the overlay. >=20 > Did I get it right? >=20 > L. >=20 >=20 > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farinacci@gmail.com] > >> Sent: Thursday, February 12, 2015 9:57 AM > >> To: Black, David > >> Cc: Luigi Iannone; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; D= amien > >> Saucez; ietf@ietf.org > >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 = [B] > >> > >> They can be the same if the underlay provider wants to control overlay= 's > group > >> address allocation. > >> > >> Dino > >> > >> > >>> On Feb 12, 2015, at 6:50 AM, Black, David wrote= : > >>> > >>> I don't care what terms are used - it just needs to be absolutely cle= ar > that > >>> the inner and outer multicast addresses are not the same and that map= ping > >>> between them (which could take a number of forms) is involved. > >>> > >>> Thanks, > >>> --David > >>> > >>>> -----Original Message----- > >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>> Sent: Thursday, February 12, 2015 8:15 AM > >>>> To: Luigi Iannone > >>>> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; > Damien > >>>> Saucez; ietf@ietf.org > >>>> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-1= 1 > >>>> > >>>>> G-EID =3D> the EID multicast group G > >>>>> G-RLOC =3D> the RLOC multicast group G > >>>> > >>>> "inner and outer group addresses" have been used in various LISP > multicast > >>>> documents. > >>>> > >>>> Dino From nobody Fri Feb 13 09:06:52 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDC91A8779; Fri, 13 Feb 2015 09:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Qd2zxp9Du1; Fri, 13 Feb 2015 09:06:44 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A571A876A; Fri, 13 Feb 2015 09:06:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 319C31C0896; Fri, 13 Feb 2015 09:06:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CB194280C8D; Fri, 13 Feb 2015 09:06:42 -0800 (PST) Message-ID: <54DE2F0F.20903@joelhalpern.com> Date: Fri, 13 Feb 2015 12:06:23 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Black, David" , Luigi Iannone References: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> <3AD27C2D-FFBF-44C8-8EC2-5FCFF9EB541F@gigix.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ops-dir@ietf.org" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:06:46 -0000 Given that Brian has signed off on the current version, and that this is explicitly on the IESG agenda, I would like Brian's confirmation that posting a new version is acceptable (it seems like a good idea to me.) Yours, Joel On 2/13/15 8:51 AM, Black, David wrote: > Yes. I think we've discussed and reached conclusions on everything except whether > to add text on the IPv6 UDP zero checksum topic. Could I suggest submission of > a -12 version of the draft that captures everything that's been discussed/resolved? > > Thanks, > --David > >> -----Original Message----- >> From: Luigi Iannone [mailto:ggx@gigix.net] >> Sent: Friday, February 13, 2015 3:38 AM >> To: Black, David >> Cc: Dino Farinacci; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; Damien >> Saucez; ietf@ietf.org >> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] >> >> >>> On 12 Feb 2015, at 15:58, Black, David wrote: >>> >>> "can be the same" is fine (i.e., if the mapping produces the same output as >> its input, that's ok, but mapping is involved). >>> The current draft text (as I read it) implies "are always the same" and that >> needs to be corrected. >>> >> >> Excellent progress thanks. >> >> So, no new terminology, just clarification that inner and outer multicast >> groups are in general different (unless specific cases where the underlay >> provider wants to introduce some tighter control on the overlay. >> >> Did I get it right? >> >> L. >> >> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Thursday, February 12, 2015 9:57 AM >>>> To: Black, David >>>> Cc: Luigi Iannone; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; Damien >>>> Saucez; ietf@ietf.org >>>> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] >>>> >>>> They can be the same if the underlay provider wants to control overlay's >> group >>>> address allocation. >>>> >>>> Dino >>>> >>>> >>>>> On Feb 12, 2015, at 6:50 AM, Black, David wrote: >>>>> >>>>> I don't care what terms are used - it just needs to be absolutely clear >> that >>>>> the inner and outer multicast addresses are not the same and that mapping >>>>> between them (which could take a number of forms) is involved. >>>>> >>>>> Thanks, >>>>> --David >>>>> >>>>>> -----Original Message----- >>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Sent: Thursday, February 12, 2015 8:15 AM >>>>>> To: Luigi Iannone >>>>>> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; >> Damien >>>>>> Saucez; ietf@ietf.org >>>>>> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >>>>>> >>>>>>> G-EID => the EID multicast group G >>>>>>> G-RLOC => the RLOC multicast group G >>>>>> >>>>>> "inner and outer group addresses" have been used in various LISP >> multicast >>>>>> documents. >>>>>> >>>>>> Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Fri Feb 13 10:09:22 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2B71A6EE9; Fri, 13 Feb 2015 10:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET3fiJTPAzQD; Fri, 13 Feb 2015 10:09:09 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CBC1A0273; Fri, 13 Feb 2015 10:09:09 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 16C94880ED; Fri, 13 Feb 2015 10:09:09 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2747071B0001; Fri, 13 Feb 2015 10:09:07 -0800 (PST) Message-ID: <54DE3DBD.90808@innovationslab.net> Date: Fri, 13 Feb 2015 13:09:01 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Joel M. Halpern" , "Black, David" , Luigi Iannone References: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> <3AD27C2D-FFBF-44C8-8EC2-5FCFF9EB541F@gigix.net> <54DE2F0F.20903@joelhalpern.com> In-Reply-To: <54DE2F0F.20903@joelhalpern.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iLPbOJeAKmcqWqxjwrpehiE2okUqaKSBf" Archived-At: Cc: "ops-dir@ietf.org" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 18:09:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iLPbOJeAKmcqWqxjwrpehiE2okUqaKSBf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, a new version can be posted. Brian On 2/13/15 12:06 PM, Joel M. Halpern wrote: > Given that Brian has signed off on the current version, and that this i= s > explicitly on the IESG agenda, I would like Brian's confirmation that > posting a new version is acceptable (it seems like a good idea to me.) >=20 > Yours, > Joel >=20 > On 2/13/15 8:51 AM, Black, David wrote: >> Yes. I think we've discussed and reached conclusions on everything >> except whether >> to add text on the IPv6 UDP zero checksum topic. Could I suggest >> submission of >> a -12 version of the draft that captures everything that's been >> discussed/resolved? >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Luigi Iannone [mailto:ggx@gigix.net] >>> Sent: Friday, February 13, 2015 3:38 AM >>> To: Black, David >>> Cc: Dino Farinacci; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos;= >>> Damien >>> Saucez; ietf@ietf.org >>> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11= >>> [B] >>> >>> >>>> On 12 Feb 2015, at 15:58, Black, David wrote: >>>> >>>> "can be the same" is fine (i.e., if the mapping produces the same >>>> output as >>> its input, that's ok, but mapping is involved). >>>> The current draft text (as I read it) implies "are always the same" >>>> and that >>> needs to be corrected. >>>> >>> >>> Excellent progress thanks. >>> >>> So, no new terminology, just clarification that inner and outer >>> multicast >>> groups are in general different (unless specific cases where the >>> underlay >>> provider wants to introduce some tighter control on the overlay. >>> >>> Did I get it right? >>> >>> L. >>> >>> >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Sent: Thursday, February 12, 2015 9:57 AM >>>>> To: Black, David >>>>> Cc: Luigi Iannone; ops-dir@ietf.org; lisp@ietf.org; Albert >>>>> Cabellos; Damien >>>>> Saucez; ietf@ietf.org >>>>> Subject: Re: [lisp] OPS-Dir review of >>>>> draft-ietf-lisp-introduction-11 [B] >>>>> >>>>> They can be the same if the underlay provider wants to control >>>>> overlay's >>> group >>>>> address allocation. >>>>> >>>>> Dino >>>>> >>>>> >>>>>> On Feb 12, 2015, at 6:50 AM, Black, David >>>>>> wrote: >>>>>> >>>>>> I don't care what terms are used - it just needs to be absolutely >>>>>> clear >>> that >>>>>> the inner and outer multicast addresses are not the same and that >>>>>> mapping >>>>>> between them (which could take a number of forms) is involved. >>>>>> >>>>>> Thanks, >>>>>> --David >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>> Sent: Thursday, February 12, 2015 8:15 AM >>>>>>> To: Luigi Iannone >>>>>>> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabello= s; >>> Damien >>>>>>> Saucez; ietf@ietf.org >>>>>>> Subject: Re: [lisp] OPS-Dir review of >>>>>>> draft-ietf-lisp-introduction-11 >>>>>>> >>>>>>>> G-EID =3D> the EID multicast group G >>>>>>>> G-RLOC =3D> the RLOC multicast group G >>>>>>> >>>>>>> "inner and outer group addresses" have been used in various LISP >>> multicast >>>>>>> documents. >>>>>>> >>>>>>> Dino >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> --iLPbOJeAKmcqWqxjwrpehiE2okUqaKSBf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU3j3CAAoJEBOZRqCi7goqmxMH/0Se6wSM80fIIAgSNaS34JLH QzCgzDH9ONxBkH1JWXdzMyDxpWRUHYLTCpa3P7X6zTRiJaY84K8myFixHm9h2JO3 vhIVn/z6n7JjOgCLN7xhAsUiYczcEAFPgUJrh446iAS2sw8lvYaoPovxWIAcXdaX Y0EWtIKT2OFac1Fb8XBaU5vkxlSrGssSC6gpG+xYu9pS9NqE6t+o5eZf8y+a3TCE g8iOFEbyWABDQ5DA+ClGfAsIpCANIm7YRaD7HAu7UCPNWYZsD8Zt8ZVojaM7yhm9 A9U+IEBpjkBzof9D68dntz+KkMBY3t198OiFA5zuFLbegUpyW4SkzREX2ip6O7w= =CKgV -----END PGP SIGNATURE----- --iLPbOJeAKmcqWqxjwrpehiE2okUqaKSBf-- From nobody Fri Feb 13 11:48:40 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C51A0263; Fri, 13 Feb 2015 11:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW4Kg62EGMdI; Fri, 13 Feb 2015 11:48:35 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46DDA1A0118; Fri, 13 Feb 2015 11:48:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0B106280C98; Fri, 13 Feb 2015 11:48:35 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 77A5628075C; Fri, 13 Feb 2015 11:48:33 -0800 (PST) Message-ID: <54DE54FD.7080601@joelhalpern.com> Date: Fri, 13 Feb 2015 14:48:13 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian Haberman , "Black, David" , Luigi Iannone References: <806176DC-81B7-4CB7-A2B5-84CE065BCCAB@gmail.com> <3AD27C2D-FFBF-44C8-8EC2-5FCFF9EB541F@gigix.net> <54DE2F0F.20903@joelhalpern.com> <54DE3DBD.90808@innovationslab.net> In-Reply-To: <54DE3DBD.90808@innovationslab.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ops-dir@ietf.org" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 [B] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 19:48:37 -0000 Thanks Brian. Authors, please do so. Yours, Joel On 2/13/15 1:09 PM, Brian Haberman wrote: > Yes, a new version can be posted. > > Brian > > On 2/13/15 12:06 PM, Joel M. Halpern wrote: >> Given that Brian has signed off on the current version, and that this is >> explicitly on the IESG agenda, I would like Brian's confirmation that >> posting a new version is acceptable (it seems like a good idea to me.) >> >> Yours, >> Joel >> >> On 2/13/15 8:51 AM, Black, David wrote: >>> Yes. I think we've discussed and reached conclusions on everything >>> except whether >>> to add text on the IPv6 UDP zero checksum topic. Could I suggest >>> submission of >>> a -12 version of the draft that captures everything that's been >>> discussed/resolved? >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: Luigi Iannone [mailto:ggx@gigix.net] >>>> Sent: Friday, February 13, 2015 3:38 AM >>>> To: Black, David >>>> Cc: Dino Farinacci; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; >>>> Damien >>>> Saucez; ietf@ietf.org >>>> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11 >>>> [B] >>>> >>>> >>>>> On 12 Feb 2015, at 15:58, Black, David wrote: >>>>> >>>>> "can be the same" is fine (i.e., if the mapping produces the same >>>>> output as >>>> its input, that's ok, but mapping is involved). >>>>> The current draft text (as I read it) implies "are always the same" >>>>> and that >>>> needs to be corrected. >>>>> >>>> >>>> Excellent progress thanks. >>>> >>>> So, no new terminology, just clarification that inner and outer >>>> multicast >>>> groups are in general different (unless specific cases where the >>>> underlay >>>> provider wants to introduce some tighter control on the overlay. >>>> >>>> Did I get it right? >>>> >>>> L. >>>> >>>> >>>>> Thanks, >>>>> --David >>>>> >>>>>> -----Original Message----- >>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Sent: Thursday, February 12, 2015 9:57 AM >>>>>> To: Black, David >>>>>> Cc: Luigi Iannone; ops-dir@ietf.org; lisp@ietf.org; Albert >>>>>> Cabellos; Damien >>>>>> Saucez; ietf@ietf.org >>>>>> Subject: Re: [lisp] OPS-Dir review of >>>>>> draft-ietf-lisp-introduction-11 [B] >>>>>> >>>>>> They can be the same if the underlay provider wants to control >>>>>> overlay's >>>> group >>>>>> address allocation. >>>>>> >>>>>> Dino >>>>>> >>>>>> >>>>>>> On Feb 12, 2015, at 6:50 AM, Black, David >>>>>>> wrote: >>>>>>> >>>>>>> I don't care what terms are used - it just needs to be absolutely >>>>>>> clear >>>> that >>>>>>> the inner and outer multicast addresses are not the same and that >>>>>>> mapping >>>>>>> between them (which could take a number of forms) is involved. >>>>>>> >>>>>>> Thanks, >>>>>>> --David >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>> Sent: Thursday, February 12, 2015 8:15 AM >>>>>>>> To: Luigi Iannone >>>>>>>> Cc: Black, David; ops-dir@ietf.org; lisp@ietf.org; Albert Cabellos; >>>> Damien >>>>>>>> Saucez; ietf@ietf.org >>>>>>>> Subject: Re: [lisp] OPS-Dir review of >>>>>>>> draft-ietf-lisp-introduction-11 >>>>>>>> >>>>>>>>> G-EID => the EID multicast group G >>>>>>>>> G-RLOC => the RLOC multicast group G >>>>>>>> >>>>>>>> "inner and outer group addresses" have been used in various LISP >>>> multicast >>>>>>>> documents. >>>>>>>> >>>>>>>> Dino >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> > From nobody Fri Feb 13 19:02:27 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED2A1A0371 for ; Fri, 13 Feb 2015 19:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy866cpZDs0h for ; Fri, 13 Feb 2015 19:02:21 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28A61A00AE for ; Fri, 13 Feb 2015 19:02:21 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) with Microsoft SMTP Server (TLS) id 15.1.87.18; Sat, 14 Feb 2015 03:02:20 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0087.013; Sat, 14 Feb 2015 03:02:20 +0000 From: Ross Callon To: Luigi Iannone , LISP mailing list list Thread-Topic: [lisp] Progress on threats document Thread-Index: AQHQLnbAifHrWK3PZEqRlsLEylMghpzvp1Fw Date: Sat, 14 Feb 2015 03:02:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] authentication-results: gigix.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1430; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; x-forefront-prvs: 0487C0DB7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(377454003)(13464003)(164054003)(51444003)(51914003)(2656002)(87936001)(19580395003)(33656002)(19580405001)(40100003)(122556002)(50986999)(54356999)(76176999)(86362001)(46102003)(99286002)(77156002)(62966003)(76576001)(106116001)(92566002)(2950100001)(2900100001)(74316001)(66066001)(15975445007)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1430; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2015 03:02:19.5608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1430 Archived-At: Cc: Damien Saucez , Olivier Bonaventure Subject: Re: [lisp] Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 03:02:26 -0000 As requested, here are my comments on the current threats document. General= ly thanks for the work, I think that this is much improved from the previou= s versions. However, there is still IMHO some work needed.=20 First a couple of minor grammatical issues: Section 1, second paragraph, th= e grammatical construction is not parallel. In listing the three parts, "th= e first defines...", "the second describing...", "The third discussing...".= I think that this should be either "the first defining...", "the second de= scribing..", etc. Alternately this could "the first defines...", "the secon= d describes...".=20 Second minor grammatical issue, in many places the documents starts sentenc= es with "To succeed their attacks, attackers...". I think that = on the most part this should read something more like "In order for their a= ttacks to succeed, attackers...".=20 Section 2.1.4: This section correctly mentions that it is possible for an a= ttacker to operate in the data plane to mount attacks targeting the control= plane (or vice versa). However, the implication of this, in terms of the d= ifference in speeds of the two planes, is not discussed anywhere. I am not = sure where this should be discussed, but this is a sufficiently important i= ssue that it should be discussed somewhere. I have wondered whether this sh= ould be mentioned here, or in section 2.2.9 (since this could be thought of= as a form of amplification attack). Perhaps the most straightforward way t= o fix this would to be append to the second paragraph of section 2.1.4 a co= uple of additional sentences that state: "In some cases, particularly in ve= ry high performance routers, the data plane may operate faster, and potenti= ally several orders of magnitude faster, relative to the control plane. Lau= nching an attack in the data plane that is targeted at the control plane ma= y therefore greatly amplify the affect of the attack (ie serve a function s= imilar to an amplification attack)."=20 Section 3.8 first paragraph, second sentence. This currently reads "If an E= TR does not accept Map-Reply messages with an invalid nonce, the risk of at= tack is limited given the size of the nonce (64 bits)". This is true for of= f-path attackers. However, an on-path attacker can see the nonce (and notin= g that the document is already clear that where gleaning allows a formerly = off-path attacker to insert themselves into the data path then they have be= come by definition an on-path attacker). I think that this sentence should = read "If an ETR does not accept Map-Reply messages with an invalid nonce, t= he risk of an off-path attack is limited given the size of the nonce (64 bi= ts)". Section 3.9, fourth paragraph. This currently reads: A compromised ETR can also de-aggregate its EID prefix in order to register more EID prefixes than necessary to its Map Servers (see Section 3.7 for the impact of de-aggregation of prefixes by an attacker). I think that it might be worth mentioning: De-aggregation could occur as pa= rt of an intentional attack, but could also occur as an unintended side eff= ect of normal operation if over time too many LISP sites advertise relative= ly de-aggregated or very fine grained mappings.=20 Section 4, "Note on privacy". Second paragraph. This currently reads:=20 Note, however, that like public deployments of any other control plane protocol, in an Internet deployment mappings are public and hence provide information about the infrastructure and reachability of LISP sites (i.e., the addresses of the edge routers). The amount of information made available with LISP, particularly in map rep= lies, is finer grained than what is available with current routing protocol= s. Certainly with current protocols ping could in principle give fine grain= ed information (if I trace route across my ISP, and if they let me do it, t= hen I would find out the IP addresses of routers), but it is largely turned= off just for this reason. I think that it would be more accurate to say:=20 Like public deployments of any other control plane protocols, in an Internet deployment mappings are public and hence provide information about the infrastructure and reachability of LISP sites (i.e., the addresses of the edge routers). LISP map=20 replies may however provide finer grained and more detailed information to a wider set of Internet sites than is available with=20 currently control protocols.=20 Section 6 (security considerations), second paragraph:=20 The purpose of this document is not to provide recommendations to protect against attacks, however most of threats can be prevented with careful deployment and configuration (e.g., filter) and also by applying the general rules in security that consist in activating only features that are necessary in the deployment and verifying the validity of the information obtained from third parties. More detailed recommendations are given in [Saucez13]. Given that this document does not provide recommendations to protect agains= t attacks, it seems premature to conclude that "most of the attacks can be = prevented with careful deployment and configuration". If detailed recommend= ations are in a different document, then that other document might be the r= ight place to conclude whether or not "most of the threats can be prevented= ". Also, of course protecting against most of the threats is very different= from protecting against all of the threats. I would therefore shorten thi= s paragraph to just:=20 The purpose of this document is not to provide recommendations to protect against attacks. More detailed recommendations for preventing=20 or mitigating these threats are given in [Saucez13]. Thanks, Ross -----Original Message----- From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone Sent: Monday, January 12, 2015 9:48 AM To: LISP mailing list list Cc: Damien Saucez; Olivier Bonaventure Subject: [lisp] Progress on threats document Hi All, back in Toronto the WG agreed to organise the threats document in two main = parts:=20 1- threat analysis=20 2- threats mitigation there was also agreement to try to finalise the first part before tackling = the second one. To this end, this would be the right time to review the current document an= d send any comment/feedback to the authors. Having such review by the end of February at latest would give sufficient t= ime to have a new document with the first part done and a newly proposed se= cond part before the meeting in Dallas. Please speak up before the end of February if you have any comment, otherwi= se authors will consider the first part as done. ciao Luigi _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Feb 17 01:03:57 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DCD1A037C for ; Tue, 17 Feb 2015 01:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOx-BQw6lI8s for ; Tue, 17 Feb 2015 01:03:54 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (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 5A9611A0023 for ; Tue, 17 Feb 2015 01:03:54 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id m14so27804190wev.13 for ; Tue, 17 Feb 2015 01:03:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FR1Z0qoxE0PIUYGpY8pi9O6PdAIHdm3VNOrFMOpUU90=; b=NQrXmvBBCBvC1Si3ftqTGeJdakoHRdHRtx6TWwYL5dfR5quJ73In1aaf/tvZ35hFWh ctGtJc+sqHpwW8mWh0bKM3w3AbwWo+3pgxMvsJFbqT8pbdENKY/OPCawIK2Qh71LVjrL groC8Rj39o5TeEK6y6yRvjqwiPFLI+kO2AARVMxJzfRkJ/fMxVRyErrOnPmmxNBhHsUk Y2K1dmsjp+zYYoteo/CH/rEGGej3Bzl13I00I+B1omW35S1pPje323G602r6QD7sZlCc oqxZjpD5+7Av9TIPqBZJDDT3YE9VU76GHfnsfdgEYBu4Djr6rImOZrn+xi++EcE8UNm6 Ag8w== X-Gm-Message-State: ALoCoQlq/cf5bLUP2y+HAOsVje+9zg/6NfPwLKBVt4T8BJSzn+lvjFVNEdWGPwu944YiVv42d9IT X-Received: by 10.194.3.40 with SMTP id 8mr57776558wjz.98.1424163832658; Tue, 17 Feb 2015 01:03:52 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:a1db:2d69:d4a9:163e? ([2001:660:330f:a4:a1db:2d69:d4a9:163e]) by mx.google.com with ESMTPSA id gi3sm23206271wic.15.2015.02.17.01.03.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 01:03:51 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F3BDF6F1-9089-42BB-8EB0-50D28F0ED085" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> Date: Tue, 17 Feb 2015 10:04:00 +0100 Message-Id: References: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> To: LISP mailing list list X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Joel Halpern Direct , Damien Saucez Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-ddt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 09:03:56 -0000 --Apple-Mail=_F3BDF6F1-9089-42BB-8EB0-50D28F0ED085 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, the WG LC for draft-ietf-lisp-ddt-02 is now closed. =46rom the activity in the mailing list it seems that there is consensus = to move the document forward. The shepherd=E2=80=99s write up will be provided soon, so to move the = document forward to the AD. Thanks all for the work done. Luigi & Joel=20 > On 29 Jan 2015, at 16:36, Luigi Iannone wrote: >=20 > Hi All, >=20 > The authors of draft-ietf-lisp-ddt-02=20 > [http://tools.ietf.org/html/draft-ietf-lisp-ddt-02 = ], > as well as several active WG participants, > requested the WG Last Call for this document. >=20 > This email starts a 14 days WG Last Call, to end February 13th, 2015. >=20 > Please review this WG document and let the WG know if you agree that = it is ready for handing to the AD. > If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >=20 > Thanks >=20 > Luigi & Joel --Apple-Mail=_F3BDF6F1-9089-42BB-8EB0-50D28F0ED085 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

the= WG LC for draft-ietf-lisp-ddt-02 is now closed.

=46rom the activity in the mailing list = it seems that there is consensus to move the document forward.

The shepherd=E2=80=99s = write up will be provided soon, so to move the document forward to the = AD.

Thanks all = for the work done.

Luigi & Joel 

On 29 Jan 2015, at 16:36, Luigi Iannone <ggx@gigix.net> = wrote:

Hi All,

The authors of = draft-ietf-lisp-ddt-02 
[http://tools.ietf.org/html/draft-ietf-lisp-ddt-02],
as well as several active WG participants,
requested the WG Last Call for this = document.

This email = starts a 14 days WG Last Call, to end February 13th, 2015.

Please review this WG document and let the WG = know if you agree that it is ready for handing to the AD.
If you have objections, please state your reasons why, and = explain what it would take to address your concerns.

Thanks

Luigi & = Joel

= --Apple-Mail=_F3BDF6F1-9089-42BB-8EB0-50D28F0ED085-- From nobody Tue Feb 17 16:17:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99841A9110; Tue, 17 Feb 2015 16:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlVHtaFrpBZW; Tue, 17 Feb 2015 16:17:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 791641A8840; Tue, 17 Feb 2015 16:17:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218001713.9711.58687.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 16:17:13 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:17:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : An Architectural Introduction to the Locator/ID Separation Protocol (LISP) Authors : Albert Cabellos Damien Saucez Filename : draft-ietf-lisp-introduction-12.txt Pages : 28 Date : 2015-02-17 Abstract: This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-introduction-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-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 Tue Feb 17 16:17:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6881E1A8840; Tue, 17 Feb 2015 16:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyNVEo7Yw24W; Tue, 17 Feb 2015 16:17:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AABF01A89A6; Tue, 17 Feb 2015 16:17:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218001713.9711.20731.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 16:17:13 -0800 Archived-At: Subject: [lisp] New Version Notification - draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:17:16 -0000 A new version (-12) has been submitted for draft-ietf-lisp-introduction: http://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-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. IETF Secretariat. From nobody Tue Feb 17 16:17:25 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8A8761A9114; Tue, 17 Feb 2015 16:17:16 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6881E1A8840; Tue, 17 Feb 2015 16:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyNVEo7Yw24W; Tue, 17 Feb 2015 16:17:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AABF01A89A6; Tue, 17 Feb 2015 16:17:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218001713.9711.20731.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 16:17:13 -0800 Archived-At: Subject: [lisp] New Version Notification - draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:17:16 -0000 A new version (-12) has been submitted for draft-ietf-lisp-introduction: http://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-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. IETF Secretariat. From nobody Tue Feb 17 16:28:01 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21A51A8791; Tue, 17 Feb 2015 16:27: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxebIM6fp1YA; Tue, 17 Feb 2015 16:27:55 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20121A1EEE; Tue, 17 Feb 2015 16:27:54 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id l13so33607180iga.0; Tue, 17 Feb 2015 16:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Zf8Tt2EceM2Jjv0JdMiuHAVq8ZnF9ixS6zrbimSgKBo=; b=aLBLqEszKZhV7F4wWDuw7xB26l+npr4Zzz6AHezUHxnpQqUG0Lxm6xw/PKQXLwx5D3 ohM5U7q7rxwKkImrjSMBc/M3jo5Ql+z6eEpd59A1KaenQiqiwIxchsvYHMT+CuBsInKj UPvBE8Q1w7VMmRJpIi9AkJBCuBQ0puXfP2VU9FWeYsHIKnsjEnH0AGD9PUN7LAEMjbRl tJmxuDIl+7nIeeHOVF4cwtyMA43Q3mA/cWq1VsXZC1pv0PSL00itCZ/ExC4Qj3hrVXZp a8unXGuaZcS2lep9rF5V6sZdaBfl40QeZ61iU9T70g99tPEaE2hLj+w0+FI6lvUKHNSj 8j4w== MIME-Version: 1.0 X-Received: by 10.42.64.197 with SMTP id h5mr2332828ici.12.1424219274092; Tue, 17 Feb 2015 16:27:54 -0800 (PST) Received: by 10.107.8.36 with HTTP; Tue, 17 Feb 2015 16:27:54 -0800 (PST) In-Reply-To: <20150218001713.9711.29769.idtracker@ietfa.amsl.com> References: <20150218001713.9711.29769.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 01:27:54 +0100 Message-ID: From: Albert Cabellos To: "ops-dir@ietf.org" , David Black , "lisp@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba3fd06dea27ac050f51e36c Archived-At: Cc: Damien Saucez Subject: [lisp] Fwd: New Version Notification for draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:27:58 -0000 --90e6ba3fd06dea27ac050f51e36c Content-Type: text/plain; charset=UTF-8 Hi all We have posted an updated version of draft-lisp-introduction hopefully addressing all the comments besides UDP Zero. Please let us know if this is not the case. Kind Regards Albert ---------- Forwarded message ---------- From: Date: Wed, Feb 18, 2015 at 1:17 AM Subject: New Version Notification for draft-ietf-lisp-introduction-12.txt To: Damien Saucez , Albert Cabellos-Aparicio < acabello@ac.upc.edu> A new version of I-D, draft-ietf-lisp-introduction-12.txt has been successfully submitted by Albert Cabellos and posted to the IETF repository. Name: draft-ietf-lisp-introduction Revision: 12 Title: An Architectural Introduction to the Locator/ID Separation Protocol (LISP) Document date: 2015-02-17 Group: lisp Pages: 28 URL: http://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-12.txt Status: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ Htmlized: http://tools.ietf.org/html/draft-ietf-lisp-introduction-12 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-12 Abstract: This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --90e6ba3fd06dea27ac050f51e36c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all

We have posted an updated versio= n of draft-lisp-introduction hopefully addressing all the comments besides = UDP Zero.

Please let us know if this is not the ca= se.

Kind Regards

Albert

---------- Forwarded mes= sage ----------
From: <internet-drafts@ietf.org= >
Date: Wed, Feb 18, 2015 at 1:17 AM
Subject: New Versi= on Notification for draft-ietf-lisp-introduction-12.txt
To: Damien Sauce= z <damien.saucez@inria.fr&= gt;, Albert Cabellos-Aparicio <ac= abello@ac.upc.edu>



A new version of I-D, draft-ietf-lisp-introduction-12.txt
has been successfully submitted by Albert Cabellos and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-lisp-introduction<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A012
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An Architectural Introduction to t= he Locator/ID Separation Protocol (LISP)
Document date:=C2=A0 2015-02-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lisp
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 28
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tp://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-12.txt Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatrac= ker.ietf.org/doc/draft-ietf-lisp-introduction/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/htm= l/draft-ietf-lisp-introduction-12
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://= www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-introduction-12

Abstract:
=C2=A0 =C2=A0This document describes the architecture of the Locator/ID Sep= aration
=C2=A0 =C2=A0Protocol (LISP), making it easier to read the rest of the LISP=
=C2=A0 =C2=A0specifications and providing a basis for discussion about the = details
=C2=A0 =C2=A0of the LISP protocols.=C2=A0 This document is used for introdu= ctory
=C2=A0 =C2=A0purposes, more details can be found in RFC6830, the protocol =C2=A0 =C2=A0specification.




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

The IETF Secretariat


--90e6ba3fd06dea27ac050f51e36c-- From nobody Tue Feb 17 16:39:48 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6441A8846; Tue, 17 Feb 2015 16:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZl02METLkUV; Tue, 17 Feb 2015 16:39:42 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EC91A882E; Tue, 17 Feb 2015 16:39:41 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1I0daZ0017851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2015 19:39:38 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t1I0daZ0017851 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1424219978; bh=nqhrAfAXWdzkHuDnzcBL6nq/Oho=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=fEbDDOkiG7AnkXtmAgsIxTY1JbvYFZUvlROVp+N7r4m47TVe/BWyLDl6U4qwk6oI0 NE36CSjY5XgE7nUofpeNT2LKDfGXLDt/tyUabKgDVZFx3JnT+9/OW0OVBPky2/9uyQ oZpyWRI23IL8SE3Lmvm/O5tUHi8VnrP1SClTD6P0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t1I0daZ0017851 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 17 Feb 2015 19:39:14 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1I0dH3l012664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 19:39:19 -0500 Received: from MXHUB210.corp.emc.com (10.253.68.36) by mxhub30.corp.emc.com (128.222.70.170) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 17 Feb 2015 19:39:18 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.172]) by MXHUB210.corp.emc.com ([10.253.68.36]) with mapi id 14.03.0224.002; Tue, 17 Feb 2015 19:39:17 -0500 From: "Black, David" To: "acabello@ac.upc.edu" , "ops-dir@ietf.org" , "lisp@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-lisp-introduction-12.txt Thread-Index: AdBLE1NhQt61aC4XQi6h7cxwJA02Nw== Date: Wed, 18 Feb 2015 00:39:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.62] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493638F620MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "ietf@ietf.org" , "Black, David" , Damien Saucez Subject: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:39:45 -0000 --_000_CE03DB3D7B45C245BCA0D2432779493638F620MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxiZXJ0LA0KDQo+IFdlIGhhdmUgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFm dC1saXNwLWludHJvZHVjdGlvbiBob3BlZnVsbHkgYWRkcmVzc2luZyBhbGwgdGhlIGNvbW1lbnRz IGJlc2lkZXMgVURQIFplcm8uDQoNCknigJl2ZSBzY2FubmVkIHRoZSBkaWZmIHdydCB0aGUgLTEx IHZlcnNpb24sIGFuZCBpdCBkb2VzIGxvb2sgbGlrZSBhbGwgdGhlIGNvbW1lbnRzIGhhdmUgYmVl biBhZGRyZXNzZWQgYmVzaWRlcyB0aGUgb25lIG9uIFVEUCB6ZXJvIGNoZWNrc3VtcyBmb3IgSVB2 Ni4gIEnigJltIGdvaW5nIHRvIHdhbGsgYXdheSBmcm9tIHRoYXQgY29tbWVudCwgYXMgdGhlcmUg aXMgc29tZSByYXRpb25hbGUgZm9yIHRoYXQgZGVzaWduIGRlY2lzaW9uIGluIHRoZSBleGlzdGlu ZyBkcmFmdCB0ZXh0LCBhbmQgbW9yZW92ZXIsIHRoZSBwcmltYXJ5IHJlc3BvbnNpYmlsaXR5IGZv ciB0aGF0IGV4cGxhbmF0aW9uIGZhbGxzIG9uIHRoZSBMSVNQIHByb3RvY29sIFJGQ3MgdGhhdCBo YXZlIGFscmVhZHkgYmVlbiBhcHByb3ZlZCBieSB0aGUgSUVTRy4NCg0KSGVuY2UsIEkgdGhpbmsg dGhpcyAtMTIgdmVyc2lvbiBvZiB0aGUgaW50cm9kdWN0aW9uIGRyYWZ0IGlzIGdvb2QgdG8gZ28u IFRoYW5rIHlvdSB0byB5b3UgYW5kIHRoZSBvdGhlciBhdXRob3JzIGZvciBhZGRyZXNzaW5nIHRo ZSBjb21tZW50cyBpbiBhIHRob3JvdWdoIGZhc2hpb24gYW5kIGZvciBkb2luZyBzbyBldmVuIHRo b3VnaCB0aGV5IGFycml2ZWQgYWZ0ZXIgdGhlIGNvbmNsdXNpb24gb2YgSUVURiBMYXN0IENhbGwg b24gdGhpcyBkcmFmdC4NCg0KUmVnYXJkcywNCi0tRGF2aWQNCg0KRnJvbTogQWxiZXJ0IENhYmVs bG9zIFttYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEZl YnJ1YXJ5IDE3LCAyMDE1IDc6MjggUE0NClRvOiBvcHMtZGlyQGlldGYub3JnOyBCbGFjaywgRGF2 aWQ7IGxpc3BAaWV0Zi5vcmcNCkNjOiBEYW1pZW4gU2F1Y2V6OyBMdWlnaSBJYW5ub25lOyBKb2Vs IEhhbHBlcm47IEJyaWFuIEhhYmVybWFuDQpTdWJqZWN0OiBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0xMi50eHQNCg0KSGkgYWxs DQoNCldlIGhhdmUgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1saXNwLWludHJv ZHVjdGlvbiBob3BlZnVsbHkgYWRkcmVzc2luZyBhbGwgdGhlIGNvbW1lbnRzIGJlc2lkZXMgVURQ IFplcm8uDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGlzIGlzIG5vdCB0aGUgY2FzZS4NCg0K S2luZCBSZWdhcmRzDQoNCkFsYmVydA0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0t LS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBXZWQsIEZlYiAxOCwgMjAxNSBhdCAxOjE3IEFNDQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbGlzcC1pbnRy b2R1Y3Rpb24tMTIudHh0DQpUbzogRGFtaWVuIFNhdWNleiA8ZGFtaWVuLnNhdWNlekBpbnJpYS5m cjxtYWlsdG86ZGFtaWVuLnNhdWNlekBpbnJpYS5mcj4+LCBBbGJlcnQgQ2FiZWxsb3MtQXBhcmlj aW8gPGFjYWJlbGxvQGFjLnVwYy5lZHU8bWFpbHRvOmFjYWJlbGxvQGFjLnVwYy5lZHU+Pg0KDQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTIu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFsYmVydCBDYWJlbGxvcyBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJh ZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbg0KUmV2aXNpb246ICAgICAgIDEyDQpUaXRsZTogICAg ICAgICAgQW4gQXJjaGl0ZWN0dXJhbCBJbnRyb2R1Y3Rpb24gdG8gdGhlIExvY2F0b3IvSUQgU2Vw YXJhdGlvbiBQcm90b2NvbCAoTElTUCkNCkRvY3VtZW50IGRhdGU6ICAyMDE1LTAyLTE3DQpHcm91 cDogICAgICAgICAgbGlzcA0KUGFnZXM6ICAgICAgICAgIDI4DQpVUkw6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1saXNwLWludHJvZHVj dGlvbi0xMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTINCkRp ZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LWxpc3AtaW50cm9kdWN0aW9uLTEyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgdGhlIGFyY2hpdGVjdHVyZSBvZiB0aGUgTG9jYXRvci9JRCBTZXBhcmF0aW9uDQogICBQ cm90b2NvbCAoTElTUCksIG1ha2luZyBpdCBlYXNpZXIgdG8gcmVhZCB0aGUgcmVzdCBvZiB0aGUg TElTUA0KICAgc3BlY2lmaWNhdGlvbnMgYW5kIHByb3ZpZGluZyBhIGJhc2lzIGZvciBkaXNjdXNz aW9uIGFib3V0IHRoZSBkZXRhaWxzDQogICBvZiB0aGUgTElTUCBwcm90b2NvbHMuICBUaGlzIGRv Y3VtZW50IGlzIHVzZWQgZm9yIGludHJvZHVjdG9yeQ0KICAgcHVycG9zZXMsIG1vcmUgZGV0YWls cyBjYW4gYmUgZm91bmQgaW4gUkZDNjgzMCwgdGhlIHByb3RvY29sDQogICBzcGVjaWZpY2F0aW9u Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5p ZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== --_000_CE03DB3D7B45C245BCA0D2432779493638F620MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgQWxiZXJ0LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jmd0Ow0KPC9zcGFuPldlIGhhdmUgcG9zdGVkIGFuIHVw ZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1saXNwLWludHJvZHVjdGlvbiBob3BlZnVsbHkgYWRkcmVz c2luZyBhbGwgdGhlIGNvbW1lbnRzIGJlc2lkZXMgVURQIFplcm8uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PknigJl2ZSBzY2FubmVkIHRoZSBkaWZmIHdydCB0aGUgLTExIHZlcnNpb24sIGFuZCBpdCBkb2Vz IGxvb2sgbGlrZSBhbGwgdGhlIGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgYmVzaWRlcyB0 aGUgb25lIG9uIFVEUCB6ZXJvIGNoZWNrc3VtcyBmb3IgSVB2Ni4mbmJzcDsgSeKAmW0gZ29pbmcg dG8gd2Fsaw0KIGF3YXkgZnJvbSB0aGF0IGNvbW1lbnQsIGFzIHRoZXJlIGlzIHNvbWUgcmF0aW9u YWxlIGZvciB0aGF0IGRlc2lnbiBkZWNpc2lvbiBpbiB0aGUgZXhpc3RpbmcgZHJhZnQgdGV4dCwg YW5kIG1vcmVvdmVyLCB0aGUgcHJpbWFyeSByZXNwb25zaWJpbGl0eSBmb3IgdGhhdCBleHBsYW5h dGlvbiBmYWxscyBvbiB0aGUgTElTUCBwcm90b2NvbCBSRkNzIHRoYXQgaGF2ZSBhbHJlYWR5IGJl ZW4gYXBwcm92ZWQgYnkgdGhlIElFU0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IZW5jZSwg SSB0aGluayB0aGlzIC0xMiB2ZXJzaW9uIG9mIHRoZSBpbnRyb2R1Y3Rpb24gZHJhZnQgaXMgZ29v ZCB0byBnby4gVGhhbmsgeW91IHRvIHlvdSBhbmQgdGhlIG90aGVyIGF1dGhvcnMgZm9yIGFkZHJl c3NpbmcgdGhlIGNvbW1lbnRzIGluIGEgdGhvcm91Z2ggZmFzaGlvbiBhbmQgZm9yDQogZG9pbmcg c28gZXZlbiB0aG91Z2ggdGhleSBhcnJpdmVkIGFmdGVyIHRoZSBjb25jbHVzaW9uIG9mIElFVEYg TGFzdCBDYWxsIG9uIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ UmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCi0tRGF2aWQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFs YmVydCBDYWJlbGxvcyBbbWFpbHRvOmFsYmVydC5jYWJlbGxvc0BnbWFpbC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMTcsIDIwMTUgNzoyOCBQTTxicj4NCjxiPlRv OjwvYj4gb3BzLWRpckBpZXRmLm9yZzsgQmxhY2ssIERhdmlkOyBsaXNwQGlldGYub3JnPGJyPg0K PGI+Q2M6PC9iPiBEYW1pZW4gU2F1Y2V6OyBMdWlnaSBJYW5ub25lOyBKb2VsIEhhbHBlcm47IEJy aWFuIEhhYmVybWFuPGJyPg0KPGI+U3ViamVjdDo8L2I+IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTEyLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhdmUgcG9zdGVkIGFu IHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1saXNwLWludHJvZHVjdGlvbiBob3BlZnVsbHkgYWRk cmVzc2luZyBhbGwgdGhlIGNvbW1lbnRzIGJlc2lkZXMgVURQIFplcm8uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBsZXQgdXMga25v dyBpZiB0aGlzIGlzIG5vdCB0aGUgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCBSZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsYmVydDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08 YnI+DQpGcm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiBXZWQsIEZlYiAxOCwg MjAxNSBhdCAxOjE3IEFNPGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTEyLnR4dDxicj4NClRvOiBEYW1pZW4gU2F1 Y2V6ICZsdDs8YSBocmVmPSJtYWlsdG86ZGFtaWVuLnNhdWNlekBpbnJpYS5mciI+ZGFtaWVuLnNh dWNlekBpbnJpYS5mcjwvYT4mZ3Q7LCBBbGJlcnQgQ2FiZWxsb3MtQXBhcmljaW8gJmx0OzxhIGhy ZWY9Im1haWx0bzphY2FiZWxsb0BhYy51cGMuZWR1Ij5hY2FiZWxsb0BhYy51cGMuZWR1PC9hPiZn dDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0 Zi1saXNwLWludHJvZHVjdGlvbi0xMi50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEFsYmVydCBDYWJlbGxvcyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVw b3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbjxicj4NClJldmlzaW9uOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEyPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBBbiBBcmNoaXRlY3R1cmFsIEludHJvZHVjdGlvbiB0byB0aGUgTG9jYXRv ci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKTxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7 IDIwMTUtMDItMTc8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGxpc3A8YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDI4PGJy Pg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbGlzcC1pbnRy b2R1Y3Rpb24tMTIudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTEyLnR4dDwvYT48YnI+ DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24v IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1saXNwLWludHJvZHVjdGlvbi88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1saXNwLWludHJvZHVjdGlvbi0xMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTI8L2E+PGJyPg0KRGlmZjom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbGlzcC1pbnRyb2R1Y3Rpb24tMTIi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWxpc3AtaW50cm9kdWN0aW9uLTEyPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZu YnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgYXJjaGl0ZWN0dXJlIG9mIHRo ZSBMb2NhdG9yL0lEIFNlcGFyYXRpb248YnI+DQombmJzcDsgJm5ic3A7UHJvdG9jb2wgKExJU1Ap LCBtYWtpbmcgaXQgZWFzaWVyIHRvIHJlYWQgdGhlIHJlc3Qgb2YgdGhlIExJU1A8YnI+DQombmJz cDsgJm5ic3A7c3BlY2lmaWNhdGlvbnMgYW5kIHByb3ZpZGluZyBhIGJhc2lzIGZvciBkaXNjdXNz aW9uIGFib3V0IHRoZSBkZXRhaWxzPGJyPg0KJm5ic3A7ICZuYnNwO29mIHRoZSBMSVNQIHByb3Rv Y29scy4mbmJzcDsgVGhpcyBkb2N1bWVudCBpcyB1c2VkIGZvciBpbnRyb2R1Y3Rvcnk8YnI+DQom bmJzcDsgJm5ic3A7cHVycG9zZXMsIG1vcmUgZGV0YWlscyBjYW4gYmUgZm91bmQgaW4gUkZDNjgz MCwgdGhlIHByb3RvY29sPGJyPg0KJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb24uPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJy Pg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D2432779493638F620MX104CL02corpemcc_-- From nobody Tue Feb 17 16:56:15 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9AE1A911D; Tue, 17 Feb 2015 16:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzFWuktok8NN; Tue, 17 Feb 2015 16:56:08 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A401A9117; Tue, 17 Feb 2015 16:55:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8DB521C0878; Tue, 17 Feb 2015 16:55:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id AECA11C06A0; Tue, 17 Feb 2015 16:55:53 -0800 (PST) Message-ID: <54E3E2E9.1000001@joelhalpern.com> Date: Tue, 17 Feb 2015 19:55:05 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Black, David" , "acabello@ac.upc.edu" , "ops-dir@ietf.org" , "lisp@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Damien Saucez , "ietf@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:56:11 -0000 Thank you David. Yours, Joel On 2/17/15 7:39 PM, Black, David wrote: > Hi Albert, > >> We have posted an updated version of draft-lisp-introduction hopefully > addressing all the comments besides UDP Zero. > > I’ve scanned the diff wrt the -11 version, and it does look like all the > comments have been addressed besides the one on UDP zero checksums for > IPv6. I’m going to walk away from that comment, as there is some > rationale for that design decision in the existing draft text, and > moreover, the primary responsibility for that explanation falls on the > LISP protocol RFCs that have already been approved by the IESG. > > Hence, I think this -12 version of the introduction draft is good to go. > Thank you to you and the other authors for addressing the comments in a > thorough fashion and for doing so even though they arrived after the > conclusion of IETF Last Call on this draft. > > Regards, > --David > > *From:*Albert Cabellos [mailto:albert.cabellos@gmail.com] > *Sent:* Tuesday, February 17, 2015 7:28 PM > *To:* ops-dir@ietf.org; Black, David; lisp@ietf.org > *Cc:* Damien Saucez; Luigi Iannone; Joel Halpern; Brian Haberman > *Subject:* Fwd: New Version Notification for > draft-ietf-lisp-introduction-12.txt > > Hi all > > We have posted an updated version of draft-lisp-introduction hopefully > addressing all the comments besides UDP Zero. > > Please let us know if this is not the case. > > Kind Regards > > Albert > > ---------- Forwarded message ---------- > From: > > Date: Wed, Feb 18, 2015 at 1:17 AM > Subject: New Version Notification for draft-ietf-lisp-introduction-12.txt > To: Damien Saucez >, Albert Cabellos-Aparicio > > > > > > A new version of I-D, draft-ietf-lisp-introduction-12.txt > has been successfully submitted by Albert Cabellos and posted to the > IETF repository. > > Name: draft-ietf-lisp-introduction > Revision: 12 > Title: An Architectural Introduction to the Locator/ID > Separation Protocol (LISP) > Document date: 2015-02-17 > Group: lisp > Pages: 28 > URL: http://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-12.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > Htmlized: http://tools.ietf.org/html/draft-ietf-lisp-introduction-12 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-12 > > Abstract: > This document describes the architecture of the Locator/ID Separation > Protocol (LISP), making it easier to read the rest of the LISP > specifications and providing a basis for discussion about the details > of the LISP protocols. This document is used for introductory > purposes, more details can be found in RFC6830, the protocol > specification. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > From nobody Tue Feb 17 17:07:27 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12A61A8AEA; Tue, 17 Feb 2015 17:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeRidwGWhxy7; Tue, 17 Feb 2015 17:07:23 -0800 (PST) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (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 484021A9120; Tue, 17 Feb 2015 17:07:19 -0800 (PST) Received: by pdbnh10 with SMTP id nh10so43392784pdb.11; Tue, 17 Feb 2015 17:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c0DWOctjVBqNITNRmDRedFydbtCxskzpf6/+mqST3AY=; b=ms+sYmboQa0rr4UiaTG/aPSSkqyNhrzQG1B8wvcbdHB7ByTu4QURbbYA6hkKJDut4x CPPtlyGkJkCvFN3AQeHP06zwXNvpu0CmN0yUtRAs6XQ3uxxXPOue7cuS8wK5ukjh5mQM THMUZlSOa/L+gjw7MI6TpkI3pVQlpldpOCJ0gunzDVn3xqMoVNmCdwSZxTCk+/vAnvQa Rgp2Rssh9TxfuK3+It4t5IpNmgZBK7p1H67dZw2zGCpQODz4ukEZbbqsBtS21SE+hI0d ITfMOf9OliV6RkG4cbEORFHKC/XIEZYK/icypbSB7Zhea6omwyhG/dPWhNIbdjgplF1S ORqQ== X-Received: by 10.70.37.238 with SMTP id b14mr27418836pdk.50.1424221639020; Tue, 17 Feb 2015 17:07:19 -0800 (PST) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id ut3sm18789106pbc.25.2015.02.17.17.07.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 17:07:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: <54E3E2E9.1000001@joelhalpern.com> Date: Tue, 17 Feb 2015 17:07:15 -0800 Content-Transfer-Encoding: 7bit Message-Id: <08CEF2F6-64FE-415B-867D-A9825AC34EFB@gmail.com> References: <54E3E2E9.1000001@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 01:07:24 -0000 > Thank you David. > Yours, > Joel I second the motion. Dino From nobody Wed Feb 18 01:06:46 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77951A6FFF for ; Wed, 18 Feb 2015 01:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.26 X-Spam-Level: X-Spam-Status: No, score=-4.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MANGLED_AMPLFY=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrZDrCigZoVZ for ; Wed, 18 Feb 2015 01:06:40 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDE01A702C for ; Wed, 18 Feb 2015 01:06:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,595,1418079600"; d="scan'208";a="100447327" Received: from saehrimnir.inria.fr ([138.96.206.202]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 18 Feb 2015 10:06:23 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Wed, 18 Feb 2015 10:06:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ross Callon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Olivier Bonaventure , LISP mailing list list Subject: Re: [lisp] Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 09:06:44 -0000 Hello Ross, Thank you for the feedback. Answers and propositions inline. On 14 Feb 2015, at 04:02, Ross Callon wrote: > As requested, here are my comments on the current threats document. = Generally thanks for the work, I think that this is much improved from = the previous versions. However, there is still IMHO some work needed.=20 >=20 > First a couple of minor grammatical issues: Section 1, second = paragraph, the grammatical construction is not parallel. In listing the = three parts, "the first defines...", "the second describing...", "The = third discussing...". I think that this should be either "the first = defining...", "the second describing..", etc. Alternately this could = "the first defines...", "the second describes...=94.=20 Good point, thanks, we will fix this in the new version. > Second minor grammatical issue, in many places the documents starts = sentences with "To succeed their attacks, attackers...". I = think that on the most part this should read something more like "In = order for their attacks to succeed, attackers...=94.=20 >=20 Indeed it sounds better, thanks, we will fix this in the new version. > Section 2.1.4: This section correctly mentions that it is possible for = an attacker to operate in the data plane to mount attacks targeting the = control plane (or vice versa). However, the implication of this, in = terms of the difference in speeds of the two planes, is not discussed = anywhere. I am not sure where this should be discussed, but this is a = sufficiently important issue that it should be discussed somewhere. I = have wondered whether this should be mentioned here, or in section 2.2.9 = (since this could be thought of as a form of amplification attack). = Perhaps the most straightforward way to fix this would to be append to = the second paragraph of section 2.1.4 a couple of additional sentences = that state: "In some cases, particularly in very high performance = routers, the data plane may operate faster, and potentially several = orders of magnitude faster, relative to the control plane. Launching an = attack in the data plane that is targeted at the control plane may = therefore greatly amp > lify the affect of the attack (ie serve a function similar to an = amplification attack).=94=20 What about adding this to the end of section 2.2.9? In some cases, the data-plane can be several order of magnitude faster = than the control-plane at processing packets. This difference can be = exploited to overload the control-plane via the data-plane without = overloading the data-plane. > Section 3.8 first paragraph, second sentence. This currently reads "If = an ETR does not accept Map-Reply messages with an invalid nonce, the = risk of attack is limited given the size of the nonce (64 bits)". This = is true for off-path attackers. However, an on-path attacker can see the = nonce (and noting that the document is already clear that where gleaning = allows a formerly off-path attacker to insert themselves into the data = path then they have become by definition an on-path attacker). I think = that this sentence should read "If an ETR does not accept Map-Reply = messages with an invalid nonce, the risk of an off-path attack is = limited given the size of the nonce (64 bits)=94. >=20 Thanks we will replace the sentence with your suggestion. > Section 3.9, fourth paragraph. This currently reads: >=20 > A compromised ETR can also de-aggregate its EID prefix in order to > register more EID prefixes than necessary to its Map Servers (see > Section 3.7 for the impact of de-aggregation of prefixes by an > attacker). >=20 > I think that it might be worth mentioning: De-aggregation could occur = as part of an intentional attack, but could also occur as an unintended = side effect of normal operation if over time too many LISP sites = advertise relatively de-aggregated or very fine grained mappings.=20 >=20 While technically the point you are making is correct, this document is = only about security and is therefore preferable to focus on attacks. > Section 4, "Note on privacy". Second paragraph. This currently reads:=20= >=20 > Note, however, that like public deployments of any other control > plane protocol, in an Internet deployment mappings are public and > hence provide information about the infrastructure and reachability > of LISP sites (i.e., the addresses of the edge routers). >=20 > The amount of information made available with LISP, particularly in = map replies, is finer grained than what is available with current = routing protocols. Certainly with current protocols ping could in = principle give fine grained information (if I trace route across my ISP, = and if they let me do it, then I would find out the IP addresses of = routers), but it is largely turned off just for this reason. I think = that it would be more accurate to say:=20 >=20 > Like public deployments of any other control > plane protocols, in an Internet deployment mappings are public and > hence provide information about the infrastructure and reachability > of LISP sites (i.e., the addresses of the edge routers). LISP map=20 > replies may however provide finer grained and more detailed > information to a wider set of Internet sites than is available with=20= > currently control protocols.=20 >=20 The sentence you are proposing is not completely correct.=20 LISP does not provide fine grained information about the infrastructure.=20= LISP only allows to clearly identify ASBRs that are running LISP = functions. Furthermore, being smart with BGP already allows you to infer business=20= relationship between ASes, this is a kind of very precise information=20 that can be retrieved with current control protocol. =20 > Section 6 (security considerations), second paragraph:=20 >=20 > The purpose of this document is not to provide recommendations to > protect against attacks, however most of threats can be prevented > with careful deployment and configuration (e.g., filter) and also by > applying the general rules in security that consist in activating > only features that are necessary in the deployment and verifying the > validity of the information obtained from third parties. More > detailed recommendations are given in [Saucez13]. >=20 > Given that this document does not provide recommendations to protect = against attacks, it seems premature to conclude that "most of the = attacks can be prevented with careful deployment and configuration". If = detailed recommendations are in a different document, then that other = document might be the right place to conclude whether or not "most of = the threats can be prevented". Also, of course protecting against most = of the threats is very different from protecting against all of the = threats. I would therefore shorten this paragraph to just:=20 >=20 > The purpose of this document is not to provide recommendations to > protect against attacks. More detailed recommendations for = preventing=20 > or mitigating these threats are given in [Saucez13]. >=20 Actually this is part of the next steps (after end of February), to = write the mitigation part of the document. This text will hence be = changed accordingly. Thank you, Damien Saucez=20 > Thanks, Ross >=20 >=20 > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone > Sent: Monday, January 12, 2015 9:48 AM > To: LISP mailing list list > Cc: Damien Saucez; Olivier Bonaventure > Subject: [lisp] Progress on threats document >=20 > Hi All, >=20 > back in Toronto the WG agreed to organise the threats document in two = main parts:=20 >=20 > 1- threat analysis=20 > 2- threats mitigation >=20 > there was also agreement to try to finalise the first part before = tackling the second one. >=20 > To this end, this would be the right time to review the current = document and send any comment/feedback to the authors. >=20 > Having such review by the end of February at latest would give = sufficient time to have a new document with the first part done and a = newly proposed second part before the meeting in Dallas. >=20 > Please speak up before the end of February if you have any comment, = otherwise authors will consider the first part as done. >=20 > ciao >=20 > Luigi > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Feb 18 01:10:47 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55F1A00A9 for ; Wed, 18 Feb 2015 01:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 oygBJ37P_FKl for ; Wed, 18 Feb 2015 01:10:43 -0800 (PST) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 4D2A51A9129 for ; Wed, 18 Feb 2015 01:10:42 -0800 (PST) Received: by wevm14 with SMTP id m14so3358971wev.13 for ; Wed, 18 Feb 2015 01:10:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xqtR8kzmGol0ItSQTwbI4vDznyHnoH/TYIz+QwpuwFs=; b=GL1ffsvsE5GxO29/sui5MxR04SIhwJPH7+kQeeA1hUenU3YxQgIJc362DumIGX99zH j5CAd+OLwZFuJB9MkBTlhvV6sNBzSwRB57gRV3a8xCIS/huNl+9bv3PIEeZLeGg0k7gm xmTrne3NAqe9W6Fe8U4v89a2cZhaCVkXP0DBIN/xJKqLUSqY53bRnfm99VaPAi2CCZ7U A6AxIjTvA3h71LZ0vFQOiOTlvWL8z9GgdC+2qCIOVvOiZ1vZV3/EH6W7h8e0+Q/T85RC RK076XwCYW9afyhWnP2R9n3hcK4v+rXUZRs7EMx50eVN0q2R/ls7oy+iJe91dVy0ihnI +aZA== X-Gm-Message-State: ALoCoQlnRfAXI9OnmOefRNN59qCXEnljoxhHiw0W5s4jiFlSgXWKX+QukEfe59rwH8fiWrvOGyaO X-Received: by 10.194.108.9 with SMTP id hg9mr71758914wjb.68.1424250639313; Wed, 18 Feb 2015 01:10:39 -0800 (PST) Received: from dhcp164-107.enst.fr (dhcp164-107.enst.fr. [137.194.165.107]) by mx.google.com with ESMTPSA id ch6sm31564919wjc.3.2015.02.18.01.10.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Feb 2015 01:10:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: <08CEF2F6-64FE-415B-867D-A9825AC34EFB@gmail.com> Date: Wed, 18 Feb 2015 10:10:48 +0100 Content-Transfer-Encoding: 7bit Message-Id: <3F902F9D-7856-4E1F-AE56-08430161E09D@gigix.net> References: <54E3E2E9.1000001@joelhalpern.com> <08CEF2F6-64FE-415B-867D-A9825AC34EFB@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , Damien Saucez , "lisp@ietf.org" Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 09:10:44 -0000 Thanks David. L. > On 18 Feb 2015, at 02:07, Dino Farinacci wrote: > >> Thank you David. >> Yours, >> Joel > > I second the motion. > > Dino > From nobody Wed Feb 25 17:19:58 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567871A90DD for ; Wed, 25 Feb 2015 17:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaS-w70Aq1-E for ; Wed, 25 Feb 2015 17:19:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4AA11A007A for ; Wed, 25 Feb 2015 17:19:54 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1429.namprd05.prod.outlook.com (25.160.107.151) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 01:19:32 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0093.004; Thu, 26 Feb 2015 01:19:32 +0000 From: Ross Callon To: Damien Saucez Thread-Topic: [lisp] Progress on threats document Thread-Index: AQHQLnbAifHrWK3PZEqRlsLEylMghpzvp1FwgAawFQCAC/6xIA== Date: Thu, 26 Feb 2015 01:19:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1429; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1429; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(51444003)(164054003)(13464003)(199003)(189002)(86362001)(74316001)(64706001)(122556002)(76176999)(50986999)(2656002)(40100003)(87936001)(33656002)(54356999)(101416001)(66066001)(97736003)(110136001)(99286002)(105586002)(106356001)(68736005)(102836002)(106116001)(2950100001)(2900100001)(92566002)(62966003)(77156002)(76576001)(46102003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1429; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2015 01:19:31.3821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1429 Archived-At: Cc: Olivier Bonaventure , LISP mailing list list Subject: Re: [lisp] Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 01:19:57 -0000 > Hello Ross, >=20 > Thank you for the feedback. > > Answers and propositions inline. I have deleted items on which we have already reached agreement. Otherwise = comments in-line. Also, I thought of a few other issues, but for readabilit= y I will mention them in a separate email which I will send a few minutes a= fter this one.=20 -----Original Message----- >> Section 2.1.4: This section correctly mentions that it is possible for a= n attacker to operate=20 >> in the data plane to mount attacks targeting the control plane (or vice = versa). However, the >> implication of this, in terms of the difference in speeds of the two pla= nes, is not discussed >> anywhere. I am not sure where this should be discussed, but this is a su= fficiently important >> issue that it should be discussed somewhere. I have wondered whether thi= s should be mentioned >> here, or in section 2.2.9 (since this could be thought of as a form of a= mplification attack). >> Perhaps the most straightforward way to fix this would to be append to t= he second paragraph of >> section 2.1.4 a couple of additional sentences that state: "In some case= s, particularly in very >> high performance routers, the data plane may operate faster, and potenti= ally several orders of >> magnitude faster, relative to the control plane. Launching an attack in = the data plane that is >> targeted at the control plane may therefore greatly amplify the affect o= f the attack (ie serve >> a function similar to an amplification attack)."=20 > > What about adding this to the end of section 2.2.9? > > In some cases, the data-plane can be several order of magnitude faster th= an the control-plane > at processing packets. This difference can be exploited to overload the c= ontrol-plane via the > data-plane without overloading the data-plane. I think that this reads well and makes the point.=20 >> Section 3.9, fourth paragraph. This currently reads: >>=20 >> A compromised ETR can also de-aggregate its EID prefix in order to >> register more EID prefixes than necessary to its Map Servers (see >> Section 3.7 for the impact of de-aggregation of prefixes by an >> attacker). >>=20 >> I think that it might be worth mentioning: De-aggregation could occur as= part of an >> intentional attack, but could also occur as an unintended side effect of= normal >> operation if over time too many LISP sites advertise relatively de-aggre= gated or >> very fine grained mappings.=20 > While technically the point you are making is correct, this document is o= nly about security and is therefore preferable to focus on attacks. Okay.=20 >> Section 4, "Note on privacy". Second paragraph. This currently reads:=20 >>=20 >> Note, however, that like public deployments of any other control >> plane protocol, in an Internet deployment mappings are public and >> hence provide information about the infrastructure and reachability >> of LISP sites (i.e., the addresses of the edge routers). >>=20 >> The amount of information made available with LISP, particularly in map = replies, is >> finer grained than what is available with current routing protocols. Cer= tainly with >> current protocols ping could in principle give fine grained information = (if I trace >> route across my ISP, and if they let me do it, then I would find out the= IP addresses >> of routers), but it is largely turned off just for this reason. I think = that it would >> be more accurate to say:=20 >>=20 >> Like public deployments of any other control >> plane protocols, in an Internet deployment mappings are public and >> hence provide information about the infrastructure and reachability >> of LISP sites (i.e., the addresses of the edge routers). LISP map=20 >> replies may however provide finer grained and more detailed >> information to a wider set of Internet sites than is available with=20 >> currently control protocols. =20 > The sentence you are proposing is not completely correct.=20 > LISP does not provide fine grained information about the infrastructure.= =20 > LISP only allows to clearly identify ASBRs that are running LISP function= s. > Furthermore, being smart with BGP already allows you to infer business=20 > relationship between ASes, this is a kind of very precise information=20 > that can be retrieved with current control protocol.=20 Yes, LISP does allow / cause identification of routers on borders (either C= E or PE routers, which I think are correctly termed "ASBRs"). It does not, = as far as I know, allow identification of other routers (such as provider c= ore P routers, or routers that do not choose to implement/deploy LISP). BGP= does already reveal the identification of some border routers. There is co= mmonly abbreviation of some of the BGP information and not all of the borde= r routers will be BGP speaking. My understanding is that there are many CE = routers who might or might not run BGP with PE routers, but even if they do= their identity does not get sent out in the broad Internet-wide routing up= dates (eg, because the CE router is advertising an address block that is in= the Provider's PA space, so that it gets summarized before being spread wi= dely). How about if we "adjust" the text that I proposed to read as follows= (and noting that the first sentence here is from the current threats docum= ent):=20 Like public deployments of any other control plane protocols, in an Internet deployment mappings are public and hence provide information about the infrastructure and reachability of LISP sites (i.e., the addresses of the edge routers). Depending upon deployment details, LISP map replies might or might not provide finer grained and more detailed information than is available with=20 currently deployed routing and control protocols. =20 Thanks, Ross From nobody Wed Feb 25 17:27:10 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81181A92E6 for ; Wed, 25 Feb 2015 17:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_AMPLFY=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIQPIrD1Hgko for ; Wed, 25 Feb 2015 17:27:07 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC0F1A92E2 for ; Wed, 25 Feb 2015 17:27:06 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 01:27:04 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0093.004; Thu, 26 Feb 2015 01:27:04 +0000 From: Ross Callon To: Damien Saucez Thread-Topic: Additional Points, RE: [lisp] Progress on threats document Thread-Index: AQHQLnbAifHrWK3PZEqRlsLEylMghpzvp1FwgAawFQCADAmEoA== Date: Thu, 26 Feb 2015 01:27:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1430; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(51914003)(53754006)(51444003)(164054003)(13464003)(199003)(60444003)(377454003)(189002)(86362001)(74316001)(50986999)(2656002)(101416001)(87936001)(40100003)(19580395003)(64706001)(19580405001)(33656002)(76176999)(54356999)(122556002)(97736003)(110136001)(99286002)(229853001)(106356001)(105586002)(77156002)(2900100001)(106116001)(66066001)(2950100001)(102836002)(62966003)(76576001)(15975445007)(68736005)(92566002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1430; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2015 01:27:04.1767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1430 Archived-At: Cc: Olivier Bonaventure , LISP mailing list list Subject: [lisp] Additional Points, RE: Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 01:27:10 -0000 As promised in my last email, here are a few other comments on the threats = document: In section 3.1 (gleaning), the first four paragraphs talk about threats tha= t can be defeated by simply turning off gleaning (if you don't glean, you d= on't accept incorrect information from spoofed incoming packets). However, = the fifth paragraph talks about the impact on the control plane from the fa= ct that a map request needs to be sent in response to incoming packets from= unknown EIDs. This of course applies whether or not you are gleaning. Perh= aps we should append to the fifth paragraph of 3.1 (the paragraph that star= ts "A gleaning attack does not only impact..."):=20 This issue occurs even if gleaning is turned off, since whether or not g= leaning is used the xTR still needs to send a map request in response to incoming packet= s whose EID is not currently in the cache.=20 Section 3.3, fourth paragraph (counting the bullet points as paragraphs, th= us the paragraph starting "A cross-mode attacker..."), second sentence. Thi= s currently reads:=20 For instance if the mapping cached at the xTR is outdated, the xTR will send a Map-Request to retrieve the new mapping which can yield to a DoS attack (by excess of signalling traffic) or an amplification attack if the data-plane packet sent by the attacker is smaller than the control-plane packets sent in response to the attacker's packet. Strictly speaking an amplification attack can occur if the data-plane packe= t sent by the attacker uses less resources than the control plane packets s= ent in response, regardless of the type of resource. Thus bandwidth is one = form of resource (for which the current text is correct), and processing is= another type of resource. I suppose that the bandwidth internal to a route= r between the data and control planes is another resource (which might not = be used at all by most data plane packets). Thus it might be more correct t= o change this sentence slightly to read:=20 For instance if the mapping cached at the xTR is outdated, the xTR will send a Map-Request to retrieve the new mapping which can yield to a DoS attack (by excess of signalling traffic) or an amplification attack if the data-plane packet sent by the attacker is smaller, or otherwise uses fewer resources, than the control-plane packets sent in response to the attacker's packet. Finally, this afternoon I was re-reading section 6.3 ("Routing Locator Reac= hability") of RFC 6830 (the LISP spec). Quite a bit of what might go wrong = if this is attacked is already in the threats document. However, a thought = occurred to me: If an attacker uses spoofed packets to fill up the xTR's ca= che, will the xTR subsequently use one of the techniques from section 6.3 t= o periodically check the liveness of the entries that have been added to it= s cache? If so, this would seem to amplify the effect of a cache-filling at= tack. I am wondering whether section 3.1 should have a paragraph (one sent= ence long) added to the end which states something along the lines of:=20 If an xTR chooses to periodically check the liveness of entries in its c= ache=20 (as described in section 6.3 of [RFC6830]), then this may amplify the wo= rk=20 needed to deal with extra entries that an attacker has inserted into the= =20 xTR's cache.=20 Thanks, Ross -----Original Message----- From: Damien Saucez [mailto:damien.saucez@inria.fr]=20 Sent: Wednesday, February 18, 2015 4:06 AM To: Ross Callon Cc: Luigi Iannone; LISP mailing list list; Olivier Bonaventure Subject: Re: [lisp] Progress on threats document Hello Ross, Thank you for the feedback. Answers and propositions inline. On 14 Feb 2015, at 04:02, Ross Callon wrote: > As requested, here are my comments on the current threats document. Gener= ally thanks for the work, I think that this is much improved from the previ= ous versions. However, there is still IMHO some work needed.=20 >=20 > First a couple of minor grammatical issues: Section 1, second paragraph, = the grammatical construction is not parallel. In listing the three parts, "= the first defines...", "the second describing...", "The third discussing...= ". I think that this should be either "the first defining...", "the second = describing..", etc. Alternately this could "the first defines...", "the sec= ond describes...".=20 Good point, thanks, we will fix this in the new version. > Second minor grammatical issue, in many places the documents starts sente= nces with "To succeed their attacks, attackers...". I think tha= t on the most part this should read something more like "In order for their= attacks to succeed, attackers...".=20 >=20 Indeed it sounds better, thanks, we will fix this in the new version. > Section 2.1.4: This section correctly mentions that it is possible for an= attacker to operate in the data plane to mount attacks targeting the contr= ol plane (or vice versa). However, the implication of this, in terms of the= difference in speeds of the two planes, is not discussed anywhere. I am no= t sure where this should be discussed, but this is a sufficiently important= issue that it should be discussed somewhere. I have wondered whether this = should be mentioned here, or in section 2.2.9 (since this could be thought = of as a form of amplification attack). Perhaps the most straightforward way= to fix this would to be append to the second paragraph of section 2.1.4 a = couple of additional sentences that state: "In some cases, particularly in = very high performance routers, the data plane may operate faster, and poten= tially several orders of magnitude faster, relative to the control plane. L= aunching an attack in the data plane that is targeted at the control plane = may therefore greatly amp > lify the affect of the attack (ie serve a function similar to an amplific= ation attack)."=20 What about adding this to the end of section 2.2.9? In some cases, the data-plane can be several order of magnitude faster than= the control-plane at processing packets. This difference can be exploited = to overload the control-plane via the data-plane without overloading the da= ta-plane. > Section 3.8 first paragraph, second sentence. This currently reads "If an= ETR does not accept Map-Reply messages with an invalid nonce, the risk of = attack is limited given the size of the nonce (64 bits)". This is true for = off-path attackers. However, an on-path attacker can see the nonce (and not= ing that the document is already clear that where gleaning allows a formerl= y off-path attacker to insert themselves into the data path then they have = become by definition an on-path attacker). I think that this sentence shoul= d read "If an ETR does not accept Map-Reply messages with an invalid nonce,= the risk of an off-path attack is limited given the size of the nonce (64 = bits)". >=20 Thanks we will replace the sentence with your suggestion. > Section 3.9, fourth paragraph. This currently reads: >=20 > A compromised ETR can also de-aggregate its EID prefix in order to > register more EID prefixes than necessary to its Map Servers (see > Section 3.7 for the impact of de-aggregation of prefixes by an > attacker). >=20 > I think that it might be worth mentioning: De-aggregation could occur as = part of an intentional attack, but could also occur as an unintended side e= ffect of normal operation if over time too many LISP sites advertise relati= vely de-aggregated or very fine grained mappings.=20 >=20 While technically the point you are making is correct, this document is onl= y about security and is therefore preferable to focus on attacks. > Section 4, "Note on privacy". Second paragraph. This currently reads:=20 >=20 > Note, however, that like public deployments of any other control > plane protocol, in an Internet deployment mappings are public and > hence provide information about the infrastructure and reachability > of LISP sites (i.e., the addresses of the edge routers). >=20 > The amount of information made available with LISP, particularly in map r= eplies, is finer grained than what is available with current routing protoc= ols. Certainly with current protocols ping could in principle give fine gra= ined information (if I trace route across my ISP, and if they let me do it,= then I would find out the IP addresses of routers), but it is largely turn= ed off just for this reason. I think that it would be more accurate to say:= =20 >=20 > Like public deployments of any other control > plane protocols, in an Internet deployment mappings are public and > hence provide information about the infrastructure and reachability > of LISP sites (i.e., the addresses of the edge routers). LISP map=20 > replies may however provide finer grained and more detailed > information to a wider set of Internet sites than is available with=20 > currently control protocols.=20 >=20 The sentence you are proposing is not completely correct.=20 LISP does not provide fine grained information about the infrastructure.=20 LISP only allows to clearly identify ASBRs that are running LISP functions. Furthermore, being smart with BGP already allows you to infer business=20 relationship between ASes, this is a kind of very precise information=20 that can be retrieved with current control protocol. =20 > Section 6 (security considerations), second paragraph:=20 >=20 > The purpose of this document is not to provide recommendations to > protect against attacks, however most of threats can be prevented > with careful deployment and configuration (e.g., filter) and also by > applying the general rules in security that consist in activating > only features that are necessary in the deployment and verifying the > validity of the information obtained from third parties. More > detailed recommendations are given in [Saucez13]. >=20 > Given that this document does not provide recommendations to protect agai= nst attacks, it seems premature to conclude that "most of the attacks can b= e prevented with careful deployment and configuration". If detailed recomme= ndations are in a different document, then that other document might be the= right place to conclude whether or not "most of the threats can be prevent= ed". Also, of course protecting against most of the threats is very differe= nt from protecting against all of the threats. I would therefore shorten t= his paragraph to just:=20 >=20 > The purpose of this document is not to provide recommendations to > protect against attacks. More detailed recommendations for preventing=20 > or mitigating these threats are given in [Saucez13]. >=20 Actually this is part of the next steps (after end of February), to write t= he mitigation part of the document. This text will hence be changed accordi= ngly. Thank you, Damien Saucez=20 > Thanks, Ross >=20 >=20 > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone > Sent: Monday, January 12, 2015 9:48 AM > To: LISP mailing list list > Cc: Damien Saucez; Olivier Bonaventure > Subject: [lisp] Progress on threats document >=20 > Hi All, >=20 > back in Toronto the WG agreed to organise the threats document in two mai= n parts:=20 >=20 > 1- threat analysis=20 > 2- threats mitigation >=20 > there was also agreement to try to finalise the first part before tacklin= g the second one. >=20 > To this end, this would be the right time to review the current document = and send any comment/feedback to the authors. >=20 > Having such review by the end of February at latest would give sufficient= time to have a new document with the first part done and a newly proposed = second part before the meeting in Dallas. >=20 > Please speak up before the end of February if you have any comment, other= wise authors will consider the first part as done. >=20 > ciao >=20 > Luigi > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Feb 26 05:57:05 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E691A0119 for ; Thu, 26 Feb 2015 05:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aofXOzdIlPZp for ; Thu, 26 Feb 2015 05:57:02 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EEB1A0120 for ; Thu, 26 Feb 2015 05:57:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,652,1418079600"; d="scan'208";a="101420850" Received: from saehrimnir.inria.fr ([138.96.206.202]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 26 Feb 2015 14:56:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Thu, 26 Feb 2015 14:56:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <317679C1-960C-494D-990A-62652E17C27B@inria.fr> References: To: Ross Callon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Olivier Bonaventure , LISP mailing list list Subject: Re: [lisp] Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 13:57:05 -0000 Hello, On 26 Feb 2015, at 02:19, Ross Callon wrote: >> Hello Ross, >>=20 >> Thank you for the feedback. >>=20 >> Answers and propositions inline. >=20 > I have deleted items on which we have already reached agreement. = Otherwise comments in-line. Also, I thought of a few other issues, but = for readability I will mention them in a separate email which I will = send a few minutes after this one.=20 >=20 > -----Original Message----- > >=20 >>> Section 2.1.4: This section correctly mentions that it is possible = for an attacker to operate=20 >>> in the data plane to mount attacks targeting the control plane (or = vice versa). However, the >>> implication of this, in terms of the difference in speeds of the two = planes, is not discussed >>> anywhere. I am not sure where this should be discussed, but this is = a sufficiently important >>> issue that it should be discussed somewhere. I have wondered whether = this should be mentioned >>> here, or in section 2.2.9 (since this could be thought of as a form = of amplification attack). >>> Perhaps the most straightforward way to fix this would to be append = to the second paragraph of >>> section 2.1.4 a couple of additional sentences that state: "In some = cases, particularly in very >>> high performance routers, the data plane may operate faster, and = potentially several orders of >>> magnitude faster, relative to the control plane. Launching an attack = in the data plane that is >>> targeted at the control plane may therefore greatly amplify the = affect of the attack (ie serve >>> a function similar to an amplification attack)."=20 >=20 >>=20 >> What about adding this to the end of section 2.2.9? >>=20 >> In some cases, the data-plane can be several order of magnitude = faster than the control-plane >> at processing packets. This difference can be exploited to overload = the control-plane via the >> data-plane without overloading the data-plane. >=20 > I think that this reads well and makes the point.=20 >=20 > >=20 >>> Section 3.9, fourth paragraph. This currently reads: >>>=20 >>> A compromised ETR can also de-aggregate its EID prefix in order to >>> register more EID prefixes than necessary to its Map Servers (see >>> Section 3.7 for the impact of de-aggregation of prefixes by an >>> attacker). >>>=20 >>> I think that it might be worth mentioning: De-aggregation could = occur as part of an >>> intentional attack, but could also occur as an unintended side = effect of normal >>> operation if over time too many LISP sites advertise relatively = de-aggregated or >>> very fine grained mappings.=20 >=20 >> While technically the point you are making is correct, this document = is only about security and is therefore preferable to focus on attacks. >=20 > Okay.=20 >=20 >>> Section 4, "Note on privacy". Second paragraph. This currently = reads:=20 >>>=20 >>> Note, however, that like public deployments of any other control >>> plane protocol, in an Internet deployment mappings are public and >>> hence provide information about the infrastructure and reachability >>> of LISP sites (i.e., the addresses of the edge routers). >>>=20 >>> The amount of information made available with LISP, particularly in = map replies, is >>> finer grained than what is available with current routing protocols. = Certainly with >>> current protocols ping could in principle give fine grained = information (if I trace >>> route across my ISP, and if they let me do it, then I would find out = the IP addresses >>> of routers), but it is largely turned off just for this reason. I = think that it would >>> be more accurate to say:=20 >>>=20 >>> Like public deployments of any other control >>> plane protocols, in an Internet deployment mappings are public and >>> hence provide information about the infrastructure and reachability >>> of LISP sites (i.e., the addresses of the edge routers). LISP map=20= >>> replies may however provide finer grained and more detailed >>> information to a wider set of Internet sites than is available with=20= >>> currently control protocols. =20 >=20 >> The sentence you are proposing is not completely correct.=20 >> LISP does not provide fine grained information about the = infrastructure.=20 >> LISP only allows to clearly identify ASBRs that are running LISP = functions. >> Furthermore, being smart with BGP already allows you to infer = business=20 >> relationship between ASes, this is a kind of very precise information=20= >> that can be retrieved with current control protocol.=20 >=20 > Yes, LISP does allow / cause identification of routers on borders = (either CE or PE routers, which I think are correctly termed "ASBRs"). = It does not, as far as I know, allow identification of other routers = (such as provider core P routers, or routers that do not choose to = implement/deploy LISP). BGP does already reveal the identification of = some border routers. There is commonly abbreviation of some of the BGP = information and not all of the border routers will be BGP speaking. My = understanding is that there are many CE routers who might or might not = run BGP with PE routers, but even if they do their identity does not get = sent out in the broad Internet-wide routing updates (eg, because the CE = router is advertising an address block that is in the Provider's PA = space, so that it gets summarized before being spread widely). How about = if we "adjust" the text that I proposed to read as follows (and noting = that the first sentence here is from the current threats document):=20 >=20 > Like public deployments of any other control > plane protocols, in an Internet deployment mappings are public and > hence provide information about the infrastructure and reachability > of LISP sites (i.e., the addresses of the edge routers). Depending = upon > deployment details, LISP map replies might or might not provide = finer > grained and more detailed information than is available with=20 > currently deployed routing and control protocols. =20 >=20 ok, we will integrate that. Thank you for all your efforts! Damien Saucez=20 > Thanks, Ross >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Feb 26 10:39:12 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ED21AC3B8 for ; Thu, 26 Feb 2015 10:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.26 X-Spam-Level: X-Spam-Status: No, score=-4.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MANGLED_AMPLFY=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbkKwWJD0y_W for ; Thu, 26 Feb 2015 10:39:07 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F40C1AC3CC for ; Thu, 26 Feb 2015 10:39:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,654,1418079600"; d="scan'208";a="101458053" Received: from saehrimnir.inria.fr ([138.96.206.202]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 26 Feb 2015 19:39:05 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Thu, 26 Feb 2015 19:38:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD1ECC1-29F6-4A91-970E-EA05593C219A@inria.fr> References: To: Ross Callon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Olivier Bonaventure , LISP mailing list list Subject: Re: [lisp] Additional Points, RE: Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 18:39:10 -0000 Hello, On 26 Feb 2015, at 02:27, Ross Callon wrote: > As promised in my last email, here are a few other comments on the = threats document: >=20 > In section 3.1 (gleaning), the first four paragraphs talk about = threats that can be defeated by simply turning off gleaning (if you = don't glean, you don't accept incorrect information from spoofed = incoming packets). However, the fifth paragraph talks about the impact = on the control plane from the fact that a map request needs to be sent = in response to incoming packets from unknown EIDs. This of course = applies whether or not you are gleaning. Perhaps we should append to the = fifth paragraph of 3.1 (the paragraph that starts "A gleaning attack = does not only impact..."):=20 >=20 > This issue occurs even if gleaning is turned off, since whether or = not gleaning is used > the xTR still needs to send a map request in response to incoming = packets whose EID is > not currently in the cache.=20 >=20 added with the following sentence: This issue can occur even if=20 gleaning is turned off since whether or not gleaning is used the = ITR=20 may need to send a Map-Request in response to incoming packets = whose EID is not currently in the cache. >=20 > Section 3.3, fourth paragraph (counting the bullet points as = paragraphs, thus the paragraph starting "A cross-mode attacker..."), = second sentence. This currently reads:=20 >=20 > For instance > if the mapping cached at the xTR is outdated, the xTR will send a > Map-Request to retrieve the new mapping which can yield to a DoS > attack (by excess of signalling traffic) or an amplification attack > if the data-plane packet sent by the attacker is smaller than the > control-plane packets sent in response to the attacker's packet. >=20 > Strictly speaking an amplification attack can occur if the data-plane = packet sent by the attacker uses less resources than the control plane = packets sent in response, regardless of the type of resource. Thus = bandwidth is one form of resource (for which the current text is = correct), and processing is another type of resource. I suppose that the = bandwidth internal to a router between the data and control planes is = another resource (which might not be used at all by most data plane = packets). Thus it might be more correct to change this sentence slightly = to read:=20 >=20 > For instance > if the mapping cached at the xTR is outdated, the xTR will send a > Map-Request to retrieve the new mapping which can yield to a DoS > attack (by excess of signalling traffic) or an amplification attack > if the data-plane packet sent by the attacker is smaller, or = otherwise > uses fewer resources, than the > control-plane packets sent in response to the attacker's packet. >=20 >=20 ok > Finally, this afternoon I was re-reading section 6.3 ("Routing Locator = Reachability") of RFC 6830 (the LISP spec). Quite a bit of what might go = wrong if this is attacked is already in the threats document. However, a = thought occurred to me: If an attacker uses spoofed packets to fill up = the xTR's cache, will the xTR subsequently use one of the techniques = from section 6.3 to periodically check the liveness of the entries that = have been added to its cache? If so, this would seem to amplify the = effect of a cache-filling attack. I am wondering whether section 3.1 = should have a paragraph (one sentence long) added to the end which = states something along the lines of:=20 >=20 > If an xTR chooses to periodically check the liveness of entries in = its cache=20 > (as described in section 6.3 of [RFC6830]), then this may amplify = the work=20 > needed to deal with extra entries that an attacker has inserted into = the=20 > xTR's cache.=20 >=20 >=20 Good point, I renamed the section to "Routing Locator Reachability=94 = and appended the following sentence: If an xTR chooses to periodically check with active probes the = liveness of entries in its EID-to-RLOC cache (as described in section 6.3 = of [RFC6830]), then this may amplify the attack that caused the insertion of entries being checked. = =20 Thanks Damien Saucez=20 > Thanks, Ross >=20 > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@inria.fr]=20 > Sent: Wednesday, February 18, 2015 4:06 AM > To: Ross Callon > Cc: Luigi Iannone; LISP mailing list list; Olivier Bonaventure > Subject: Re: [lisp] Progress on threats document >=20 > Hello Ross, >=20 > Thank you for the feedback. >=20 > Answers and propositions inline. >=20 > On 14 Feb 2015, at 04:02, Ross Callon wrote: >=20 >> As requested, here are my comments on the current threats document. = Generally thanks for the work, I think that this is much improved from = the previous versions. However, there is still IMHO some work needed.=20 >>=20 >> First a couple of minor grammatical issues: Section 1, second = paragraph, the grammatical construction is not parallel. In listing the = three parts, "the first defines...", "the second describing...", "The = third discussing...". I think that this should be either "the first = defining...", "the second describing..", etc. Alternately this could = "the first defines...", "the second describes...".=20 >=20 > Good point, thanks, we will fix this in the new version. >=20 >> Second minor grammatical issue, in many places the documents starts = sentences with "To succeed their attacks, attackers...". I = think that on the most part this should read something more like "In = order for their attacks to succeed, attackers...".=20 >>=20 > Indeed it sounds better, thanks, we will fix this in the new version. >=20 >> Section 2.1.4: This section correctly mentions that it is possible = for an attacker to operate in the data plane to mount attacks targeting = the control plane (or vice versa). However, the implication of this, in = terms of the difference in speeds of the two planes, is not discussed = anywhere. I am not sure where this should be discussed, but this is a = sufficiently important issue that it should be discussed somewhere. I = have wondered whether this should be mentioned here, or in section 2.2.9 = (since this could be thought of as a form of amplification attack). = Perhaps the most straightforward way to fix this would to be append to = the second paragraph of section 2.1.4 a couple of additional sentences = that state: "In some cases, particularly in very high performance = routers, the data plane may operate faster, and potentially several = orders of magnitude faster, relative to the control plane. Launching an = attack in the data plane that is targeted at the control plane may = therefore greatly a > mp >> lify the affect of the attack (ie serve a function similar to an = amplification attack)."=20 >=20 >=20 > What about adding this to the end of section 2.2.9? >=20 > In some cases, the data-plane can be several order of magnitude faster = than the control-plane at processing packets. This difference can be = exploited to overload the control-plane via the data-plane without = overloading the data-plane. >=20 >> Section 3.8 first paragraph, second sentence. This currently reads = "If an ETR does not accept Map-Reply messages with an invalid nonce, the = risk of attack is limited given the size of the nonce (64 bits)". This = is true for off-path attackers. However, an on-path attacker can see the = nonce (and noting that the document is already clear that where gleaning = allows a formerly off-path attacker to insert themselves into the data = path then they have become by definition an on-path attacker). I think = that this sentence should read "If an ETR does not accept Map-Reply = messages with an invalid nonce, the risk of an off-path attack is = limited given the size of the nonce (64 bits)". >>=20 >=20 > Thanks we will replace the sentence with your suggestion. >=20 >> Section 3.9, fourth paragraph. This currently reads: >>=20 >> A compromised ETR can also de-aggregate its EID prefix in order to >> register more EID prefixes than necessary to its Map Servers (see >> Section 3.7 for the impact of de-aggregation of prefixes by an >> attacker). >>=20 >> I think that it might be worth mentioning: De-aggregation could occur = as part of an intentional attack, but could also occur as an unintended = side effect of normal operation if over time too many LISP sites = advertise relatively de-aggregated or very fine grained mappings.=20 >>=20 >=20 > While technically the point you are making is correct, this document = is only about security and is therefore preferable to focus on attacks. >=20 >=20 >> Section 4, "Note on privacy". Second paragraph. This currently reads:=20= >>=20 >> Note, however, that like public deployments of any other control >> plane protocol, in an Internet deployment mappings are public and >> hence provide information about the infrastructure and reachability >> of LISP sites (i.e., the addresses of the edge routers). >>=20 >> The amount of information made available with LISP, particularly in = map replies, is finer grained than what is available with current = routing protocols. Certainly with current protocols ping could in = principle give fine grained information (if I trace route across my ISP, = and if they let me do it, then I would find out the IP addresses of = routers), but it is largely turned off just for this reason. I think = that it would be more accurate to say:=20 >>=20 >> Like public deployments of any other control >> plane protocols, in an Internet deployment mappings are public and >> hence provide information about the infrastructure and reachability >> of LISP sites (i.e., the addresses of the edge routers). LISP map=20 >> replies may however provide finer grained and more detailed >> information to a wider set of Internet sites than is available with=20= >> currently control protocols.=20 >>=20 >=20 > The sentence you are proposing is not completely correct.=20 > LISP does not provide fine grained information about the = infrastructure.=20 > LISP only allows to clearly identify ASBRs that are running LISP = functions. > Furthermore, being smart with BGP already allows you to infer business=20= > relationship between ASes, this is a kind of very precise information=20= > that can be retrieved with current control protocol. =20 >=20 >=20 >> Section 6 (security considerations), second paragraph:=20 >>=20 >> The purpose of this document is not to provide recommendations to >> protect against attacks, however most of threats can be prevented >> with careful deployment and configuration (e.g., filter) and also by >> applying the general rules in security that consist in activating >> only features that are necessary in the deployment and verifying the >> validity of the information obtained from third parties. More >> detailed recommendations are given in [Saucez13]. >>=20 >> Given that this document does not provide recommendations to protect = against attacks, it seems premature to conclude that "most of the = attacks can be prevented with careful deployment and configuration". If = detailed recommendations are in a different document, then that other = document might be the right place to conclude whether or not "most of = the threats can be prevented". Also, of course protecting against most = of the threats is very different from protecting against all of the = threats. I would therefore shorten this paragraph to just:=20 >>=20 >> The purpose of this document is not to provide recommendations to >> protect against attacks. More detailed recommendations for = preventing=20 >> or mitigating these threats are given in [Saucez13]. >>=20 >=20 > Actually this is part of the next steps (after end of February), to = write the mitigation part of the document. This text will hence be = changed accordingly. >=20 > Thank you, >=20 > Damien Saucez=20 >=20 >=20 >> Thanks, Ross >>=20 >>=20 >> -----Original Message----- >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone >> Sent: Monday, January 12, 2015 9:48 AM >> To: LISP mailing list list >> Cc: Damien Saucez; Olivier Bonaventure >> Subject: [lisp] Progress on threats document >>=20 >> Hi All, >>=20 >> back in Toronto the WG agreed to organise the threats document in two = main parts:=20 >>=20 >> 1- threat analysis=20 >> 2- threats mitigation >>=20 >> there was also agreement to try to finalise the first part before = tackling the second one. >>=20 >> To this end, this would be the right time to review the current = document and send any comment/feedback to the authors. >>=20 >> Having such review by the end of February at latest would give = sufficient time to have a new document with the first part done and a = newly proposed second part before the meeting in Dallas. >>=20 >> Please speak up before the end of February if you have any comment, = otherwise authors will consider the first part as done. >>=20 >> ciao >>=20 >> Luigi >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Feb 26 11:58:41 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8042E1A03A2 for ; Thu, 26 Feb 2015 11:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_AMPLFY=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dY4JuhDs3Rx for ; Thu, 26 Feb 2015 11:58:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2991A1B82 for ; Thu, 26 Feb 2015 11:58:36 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 19:58:17 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0093.004; Thu, 26 Feb 2015 19:58:17 +0000 From: Ross Callon To: Damien Saucez Thread-Topic: [lisp] Additional Points, RE: Progress on threats document Thread-Index: AQHQUfOI5bTxVbjKmkGeaUIOtinzvZ0DWSwA Date: Thu, 26 Feb 2015 19:58:16 +0000 Message-ID: References: <2CD1ECC1-29F6-4A91-970E-EA05593C219A@inria.fr> In-Reply-To: <2CD1ECC1-29F6-4A91-970E-EA05593C219A@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1430; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(51914003)(53754006)(51444003)(164054003)(13464003)(199003)(60444003)(377454003)(41574002)(189002)(86362001)(76176999)(74316001)(50986999)(2656002)(40100003)(19580395003)(33656002)(19580405001)(64706001)(101416001)(54356999)(87936001)(122556002)(97736003)(110136001)(99286002)(106356001)(105586002)(2900100001)(77156002)(102836002)(62966003)(66066001)(2950100001)(76576001)(68736005)(92566002)(46102003)(15975445007)(93886004)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1430; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2015 19:58:16.4657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1430 Archived-At: Cc: Olivier Bonaventure , LISP mailing list list Subject: Re: [lisp] Additional Points, RE: Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 19:58:40 -0000 Thanks! Ross -----Original Message----- From: Damien Saucez [mailto:damien.saucez@inria.fr]=20 Sent: Thursday, February 26, 2015 1:39 PM To: Ross Callon Cc: Olivier Bonaventure; LISP mailing list list Subject: Re: [lisp] Additional Points, RE: Progress on threats document Hello, On 26 Feb 2015, at 02:27, Ross Callon wrote: > As promised in my last email, here are a few other comments on the threat= s document: >=20 > In section 3.1 (gleaning), the first four paragraphs talk about threats t= hat can be defeated by simply turning off gleaning (if you don't glean, you= don't accept incorrect information from spoofed incoming packets). However= , the fifth paragraph talks about the impact on the control plane from the = fact that a map request needs to be sent in response to incoming packets fr= om unknown EIDs. This of course applies whether or not you are gleaning. Pe= rhaps we should append to the fifth paragraph of 3.1 (the paragraph that st= arts "A gleaning attack does not only impact..."):=20 >=20 > This issue occurs even if gleaning is turned off, since whether or not = gleaning is used > the xTR still needs to send a map request in response to incoming packe= ts whose EID is > not currently in the cache.=20 >=20 added with the following sentence: This issue can occur even if=20 gleaning is turned off since whether or not gleaning is used the IT= R=20 may need to send a Map-Request in response to incoming packets whos= e EID is not currently in the cache. >=20 > Section 3.3, fourth paragraph (counting the bullet points as paragraphs, = thus the paragraph starting "A cross-mode attacker..."), second sentence. T= his currently reads:=20 >=20 > For instance > if the mapping cached at the xTR is outdated, the xTR will send a > Map-Request to retrieve the new mapping which can yield to a DoS > attack (by excess of signalling traffic) or an amplification attack > if the data-plane packet sent by the attacker is smaller than the > control-plane packets sent in response to the attacker's packet. >=20 > Strictly speaking an amplification attack can occur if the data-plane pac= ket sent by the attacker uses less resources than the control plane packets= sent in response, regardless of the type of resource. Thus bandwidth is on= e form of resource (for which the current text is correct), and processing = is another type of resource. I suppose that the bandwidth internal to a rou= ter between the data and control planes is another resource (which might no= t be used at all by most data plane packets). Thus it might be more correct= to change this sentence slightly to read:=20 >=20 > For instance > if the mapping cached at the xTR is outdated, the xTR will send a > Map-Request to retrieve the new mapping which can yield to a DoS > attack (by excess of signalling traffic) or an amplification attack > if the data-plane packet sent by the attacker is smaller, or otherwise > uses fewer resources, than the > control-plane packets sent in response to the attacker's packet. >=20 >=20 ok > Finally, this afternoon I was re-reading section 6.3 ("Routing Locator Re= achability") of RFC 6830 (the LISP spec). Quite a bit of what might go wron= g if this is attacked is already in the threats document. However, a though= t occurred to me: If an attacker uses spoofed packets to fill up the xTR's = cache, will the xTR subsequently use one of the techniques from section 6.3= to periodically check the liveness of the entries that have been added to = its cache? If so, this would seem to amplify the effect of a cache-filling = attack. I am wondering whether section 3.1 should have a paragraph (one se= ntence long) added to the end which states something along the lines of:=20 >=20 > If an xTR chooses to periodically check the liveness of entries in its = cache=20 > (as described in section 6.3 of [RFC6830]), then this may amplify the w= ork=20 > needed to deal with extra entries that an attacker has inserted into th= e=20 > xTR's cache.=20 >=20 >=20 Good point, I renamed the section to "Routing Locator Reachability" and app= ended the following sentence: If an xTR chooses to periodically check with active probes the live= ness of entries in its EID-to-RLOC cache (as described in section 6.3 of [RFC6830]), then this may amplify the attack that caused the insertion of entries being checked. = =20 Thanks Damien Saucez=20 > Thanks, Ross >=20 > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@inria.fr]=20 > Sent: Wednesday, February 18, 2015 4:06 AM > To: Ross Callon > Cc: Luigi Iannone; LISP mailing list list; Olivier Bonaventure > Subject: Re: [lisp] Progress on threats document >=20 > Hello Ross, >=20 > Thank you for the feedback. >=20 > Answers and propositions inline. >=20 > On 14 Feb 2015, at 04:02, Ross Callon wrote: >=20 >> As requested, here are my comments on the current threats document. Gene= rally thanks for the work, I think that this is much improved from the prev= ious versions. However, there is still IMHO some work needed.=20 >>=20 >> First a couple of minor grammatical issues: Section 1, second paragraph,= the grammatical construction is not parallel. In listing the three parts, = "the first defines...", "the second describing...", "The third discussing..= .". I think that this should be either "the first defining...", "the second= describing..", etc. Alternately this could "the first defines...", "the se= cond describes...".=20 >=20 > Good point, thanks, we will fix this in the new version. >=20 >> Second minor grammatical issue, in many places the documents starts sent= ences with "To succeed their attacks, attackers...". I think th= at on the most part this should read something more like "In order for thei= r attacks to succeed, attackers...".=20 >>=20 > Indeed it sounds better, thanks, we will fix this in the new version. >=20 >> Section 2.1.4: This section correctly mentions that it is possible for a= n attacker to operate in the data plane to mount attacks targeting the cont= rol plane (or vice versa). However, the implication of this, in terms of th= e difference in speeds of the two planes, is not discussed anywhere. I am n= ot sure where this should be discussed, but this is a sufficiently importan= t issue that it should be discussed somewhere. I have wondered whether this= should be mentioned here, or in section 2.2.9 (since this could be thought= of as a form of amplification attack). Perhaps the most straightforward wa= y to fix this would to be append to the second paragraph of section 2.1.4 a= couple of additional sentences that state: "In some cases, particularly in= very high performance routers, the data plane may operate faster, and pote= ntially several orders of magnitude faster, relative to the control plane. = Launching an attack in the data plane that is targeted at the control plane= may therefore greatly a > mp >> lify the affect of the attack (ie serve a function similar to an amplifi= cation attack)."=20 >=20 >=20 > What about adding this to the end of section 2.2.9? >=20 > In some cases, the data-plane can be several order of magnitude faster th= an the control-plane at processing packets. This difference can be exploite= d to overload the control-plane via the data-plane without overloading the = data-plane. >=20 >> Section 3.8 first paragraph, second sentence. This currently reads "If a= n ETR does not accept Map-Reply messages with an invalid nonce, the risk of= attack is limited given the size of the nonce (64 bits)". This is true for= off-path attackers. However, an on-path attacker can see the nonce (and no= ting that the document is already clear that where gleaning allows a former= ly off-path attacker to insert themselves into the data path then they have= become by definition an on-path attacker). I think that this sentence shou= ld read "If an ETR does not accept Map-Reply messages with an invalid nonce= , the risk of an off-path attack is limited given the size of the nonce (64= bits)". >>=20 >=20 > Thanks we will replace the sentence with your suggestion. >=20 >> Section 3.9, fourth paragraph. This currently reads: >>=20 >> A compromised ETR can also de-aggregate its EID prefix in order to >> register more EID prefixes than necessary to its Map Servers (see >> Section 3.7 for the impact of de-aggregation of prefixes by an >> attacker). >>=20 >> I think that it might be worth mentioning: De-aggregation could occur as= part of an intentional attack, but could also occur as an unintended side = effect of normal operation if over time too many LISP sites advertise relat= ively de-aggregated or very fine grained mappings.=20 >>=20 >=20 > While technically the point you are making is correct, this document is o= nly about security and is therefore preferable to focus on attacks. >=20 >=20 >> Section 4, "Note on privacy". Second paragraph. This currently reads:=20 >>=20 >> Note, however, that like public deployments of any other control >> plane protocol, in an Internet deployment mappings are public and >> hence provide information about the infrastructure and reachability >> of LISP sites (i.e., the addresses of the edge routers). >>=20 >> The amount of information made available with LISP, particularly in map = replies, is finer grained than what is available with current routing proto= cols. Certainly with current protocols ping could in principle give fine gr= ained information (if I trace route across my ISP, and if they let me do it= , then I would find out the IP addresses of routers), but it is largely tur= ned off just for this reason. I think that it would be more accurate to say= :=20 >>=20 >> Like public deployments of any other control >> plane protocols, in an Internet deployment mappings are public and >> hence provide information about the infrastructure and reachability >> of LISP sites (i.e., the addresses of the edge routers). LISP map=20 >> replies may however provide finer grained and more detailed >> information to a wider set of Internet sites than is available with=20 >> currently control protocols.=20 >>=20 >=20 > The sentence you are proposing is not completely correct.=20 > LISP does not provide fine grained information about the infrastructure.= =20 > LISP only allows to clearly identify ASBRs that are running LISP function= s. > Furthermore, being smart with BGP already allows you to infer business=20 > relationship between ASes, this is a kind of very precise information=20 > that can be retrieved with current control protocol. =20 >=20 >=20 >> Section 6 (security considerations), second paragraph:=20 >>=20 >> The purpose of this document is not to provide recommendations to >> protect against attacks, however most of threats can be prevented >> with careful deployment and configuration (e.g., filter) and also by >> applying the general rules in security that consist in activating >> only features that are necessary in the deployment and verifying the >> validity of the information obtained from third parties. More >> detailed recommendations are given in [Saucez13]. >>=20 >> Given that this document does not provide recommendations to protect aga= inst attacks, it seems premature to conclude that "most of the attacks can = be prevented with careful deployment and configuration". If detailed recomm= endations are in a different document, then that other document might be th= e right place to conclude whether or not "most of the threats can be preven= ted". Also, of course protecting against most of the threats is very differ= ent from protecting against all of the threats. I would therefore shorten = this paragraph to just:=20 >>=20 >> The purpose of this document is not to provide recommendations to >> protect against attacks. More detailed recommendations for preventing=20 >> or mitigating these threats are given in [Saucez13]. >>=20 >=20 > Actually this is part of the next steps (after end of February), to write= the mitigation part of the document. This text will hence be changed accor= dingly. >=20 > Thank you, >=20 > Damien Saucez=20 >=20 >=20 >> Thanks, Ross >>=20 >>=20 >> -----Original Message----- >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone >> Sent: Monday, January 12, 2015 9:48 AM >> To: LISP mailing list list >> Cc: Damien Saucez; Olivier Bonaventure >> Subject: [lisp] Progress on threats document >>=20 >> Hi All, >>=20 >> back in Toronto the WG agreed to organise the threats document in two ma= in parts:=20 >>=20 >> 1- threat analysis=20 >> 2- threats mitigation >>=20 >> there was also agreement to try to finalise the first part before tackli= ng the second one. >>=20 >> To this end, this would be the right time to review the current document= and send any comment/feedback to the authors. >>=20 >> Having such review by the end of February at latest would give sufficien= t time to have a new document with the first part done and a newly proposed= second part before the meeting in Dallas. >>=20 >> Please speak up before the end of February if you have any comment, othe= rwise authors will consider the first part as done. >>=20 >> ciao >>=20 >> Luigi >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp