From nobody Tue Jan 3 14:03:31 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DCA127076; Tue, 3 Jan 2017 14:03:26 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148348100651.27933.6327222003850044550.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 14:03:26 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-type-iana@ietf.org, lisp@ietf.org Subject: [lisp] Last Call: (LISP Shared Extension Message & IANA Registry for LISP Packet Type Allocations) to Proposed Standard X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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 Jan 2017 22:03:26 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Shared Extension Message & IANA Registry for LISP Packet Type Allocations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a registry for LISP Packet Type allocations. It also specifies a LISP shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6830: The Locator/ID Separation Protocol (LISP) (Experimental - IETF stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Sat Jan 7 18:05:32 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE8C1296F2; Sat, 7 Jan 2017 18:05:30 -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: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148384113096.2849.8278502698032383623.idtracker@ietfa.amsl.com> Date: Sat, 07 Jan 2017 18:05:30 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-yang-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 08 Jan 2017 02:05:31 -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 of the IETF. Title : LISP Configuration YANG Model Authors : Vina Ermagan Alberto Rodriguez-Natal Florin Coras Carl Moberg Albert Cabellos-Aparicio Fabio Maino Filename : draft-ietf-lisp-yang-04.txt Pages : 81 Date : 2017-01-07 Abstract: This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-yang-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 11 09:51:12 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14024129D26 for ; Wed, 11 Jan 2017 09:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXqCVxkbhxRp for ; Wed, 11 Jan 2017 09:51:06 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 4EC83129624 for ; Wed, 11 Jan 2017 09:51:05 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 194so22633457pgd.2 for ; Wed, 11 Jan 2017 09:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1IWBB8fBwYfXYQE8LduTqrCdWFsk49cPAQSfd3pWOc=; b=MWELo+6iE04d4vrMZYmNMv1bHsIEuB3cp7mNe73Q1JRC0sQAN5wssof035AJkSvg++ VUX8fh1W6gQSRZbJFU837e9r+RbwI5KZb0D+zCoaCZagtN2kHhPrPyJ1Op+we0q+dhj6 LRgLljPR7igpt9OJXh8VNS2FTj9llnnpkmLNBpSrKgMgMwySpL8+0vg6HbVk4FxB4p2j Mn6uMGvJH2/E1MxJAnKcZg7h/iu2/ivQpVSXT8VwwxdvQg4rcfQ6fBDKPj5IwYOcexMp MmUbUyEn7syVat8yXJNgSrhiJx744omnAO5UI7iISvS/gFp7ZQKqF6v7jYOiTDrslZ/u yK4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1IWBB8fBwYfXYQE8LduTqrCdWFsk49cPAQSfd3pWOc=; b=mtfyPvc+IeaVi1FOSEeJsoa8QCj8w2lNVoUvgk0zlVLocXMPXh6QY2I/otSJGcjh9l b+T7kuIK67Ld3aEkUPFDE9R+8vOZe8JL7/BtAvXwqm5WgCf8BK/Wtyuy6GRpRJmFWYfz 3dFjBRtlf8OInvfiPNpOSqzR6cZnR339gPBsYO4fgZe4AmX3cX9n4V/rq83DfisPAIOg B4U72sLZwGiTeafjc/W04raI9n2Dq7nctZYkFqX4VnOqVkJozRZFzO9kIDiYb6NkQjk0 nCKVmThote1nNSRU7i48sknjCXAVglAhqzetEChMnwRwx5cuKq0Zw4gBuCRSz1on5Sk7 TLIQ== X-Gm-Message-State: AIkVDXL9ASwL+pi8RAa0qFquRz0UpuuSX5FfiPSGIuDGC8+VYmcZ0wGnDp3/iHvk40609w== X-Received: by 10.99.228.5 with SMTP id a5mr12402975pgi.1.1484157063420; Wed, 11 Jan 2017 09:51:03 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id p25sm15394774pfd.0.2017.01.11.09.51.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 09:51:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <7F5BC459-2446-4DF9-8D22-53389476C620@gmail.com> Date: Wed, 11 Jan 2017 09:50:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87bmym4cyp.fsf@hobgoblin.ariadne.com> <50795FAC-6560-4F02-937B-F6343F1E6CF7@gmail.com> <0099C88F-59F0-4201-9518-214D525342C4@gmail.com> <73e5e11d-be94-7496-b2f9-e3c45445def0@cisco.com> <7F5BC459-2446-4DF9-8D22-53389476C620@gmail.com> To: Anton Smirnov X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "Dale R. Worley" , LISP mailing list list Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 17:51:10 -0000 Is there any status on the draft-ietf-lisp-ddt? This document is = blocking many other documents in the RFC editor queue. Dino > On Nov 4, 2016, at 10:24 AM, Dino Farinacci = wrote: >=20 > Okay, thanks for the effort. >=20 > Dino >=20 >> On Nov 4, 2016, at 9:15 AM, Anton Smirnov wrote: >>=20 >> Hi Dino, >>=20 >> given the scope of comments and need for review between authors it = may be difficult. We will make an effort to achieve this date but right = now I can't guarantee this. >>=20 >> Anton >>=20 >> On Tuesday 01 November 2016 22:55, Dino Farinacci wrote: >>> Great to hear. Is the goal to publish the new draft on Monday of = IETF week? >>>=20 >>> Dino >>>=20 >>>> On Nov 1, 2016, at 11:47 AM, Anton Smirnov = wrote: >>>>=20 >>>> Hello Dino, >>>>=20 >>>> thanks for taking time to answer these concerns. Authors will work = on the revised text to incorporate those points. >>>>=20 >>>> Anton >>>>=20 >>>> On Sunday 16 October 2016 22:43, Dino Farinacci wrote: >>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>>> like any other last call comments. >>>>>>=20 >>>>>> For more information, please see the FAQ at >>>>>> . >>>>>>=20 >>>>>> Document: draft-ietf-lisp-ddt-08 >>>>>> Reviewer: Dale R. Worley >>>>>> Review Date: 2016-10-09 >>>>>> IETF LC End Date: 2016-10-17 >>>>>> IESG Telechat date: 2016-10-27 >>>>>>=20 >>>>>> Summary: This draft is on the right track but has open issues, >>>>>> described in the review. >>>>> Thanks for the review Dale. Your comments are outstanding! And = your suggestions even better. ;-) >>>>>=20 >>>>> I am not an author but was involved in the LISP-DDT design early = on so I would like to respond to some of your comments. Where I think = text should change, I will suggest that to help the authors. To clarify = understanding, I will comment inline. >>>>>=20 >>>>> One of the authors will make the changes. >>>>>=20 >>>>>> * In regard to XEIDs: The concept of XEID unifies the treatment = of >>>>>> DBID, IID, AFI, and EID. Essentially all of the processing in = the >>>>>> draft is simplified by expressing processing in terms of XEIDs. = For >>>>>> instance, delegation based on DBID, IID, or AF becomes just a = special >>>>>> case of delegation based on XEID-prefix. However, it's not clear = to >>>>>> me whether this concept is followed in the text. For example: >>>>> Yes, you interpreted the defintion of an extended-EID correctly. = It is a multi-tuple entity that has hierarchy so we can delegate any = tuple, as well as the tuple itself, downward on the tree. >>>>>=20 >>>>>> In section 3, definition "XEID-prefix" seems to assume that an >>>>>> XEID-prefix will always contain a complete DBID, IID, and AFI. >>>>> For a lookup yes. For a delegation, it can be any part of it as I = explained above. >>>>>=20 >>>>>> In section 4.2.1: >>>>>>=20 >>>>>> The root DDT node is the logical "top" of the database = hierarchy: >>>>>> DBID=3D0, IID=3D0, AFI=3D0, EID-prefix=3D0/0. >>>>>>=20 >>>>>> But really, the condition of a root node is that it's = authoritative >>>>>> for the *empty* XEID-prefix. >>>>> Well it is authoriative for everything, by default, but a = Map-Referral return code will tell you exactly what it is authoritative = for if configured for specficy XEIDs. >>>>>=20 >>>>>> There is also the suggestion here that an AFI of 0 is somehow a >>>>>> wildcard match for any AFI value. That is a special case that = can be >>>>>> eliminated by considering the entire XEID to be prefixable. >>>>> Right, if a delegation is configured with solely the 2-tuple = (DBID=3D0, IID=3D0), it would be the delegation represents all prefixes = in all address families. >>>>>=20 >>>>> We should clarify that in the text. >>>>>=20 >>>>>> On the other hand, this text in 7.3.1 suggests that there is a = "null >>>>>> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits: >>>>>>=20 >>>>>> the "referral XEID-prefix" is also initialized to the null value >>>>>> since no referral has yet been received. >>>>> I think we don=E2=80=99t need to say how its initialized IMO. We = should change text here. >>>>>=20 >>>>>> * In regard to the special fields in XEID, viz., DBID, IID, and = AFI, >>>>>> those need to be described in a way that doesn't leave loose = ends, by >>>>>> either describing how they are expected to be used or referring = to a >>>>>> document that does so. In this document, a lot of that = information is >>>>>> bundled into the definitions of "Extended EID (XEID)" and >>>>>> "XEID-prefix" in section 3. It would be best if this information >>>>>> appeared in its own paragraphs. >>>>> Agree. We should make this change. >>>>>=20 >>>>>> It appears to me that it is expected that DBID will always be = zero >>>>>> (see definition "XEID-prefix"), but the machinery is defined so = that >>>>>> other values can be used. >>>>> Experience has showed us that running parallel mapping databases = will be useful. They really don=E2=80=99t need to be numbered or = identified because there will be distinct roots and xTRs can connect to = one or multiple of them. >>>>>=20 >>>>> And right now, we do not have an encoding for a DBID that can be = sent in a Map-Register or Map-Request. So I am agreeing with you. >>>>>=20 >>>>>> IID is presumably expected to be zero except when VPNs are used. = (see >>>>>> definition "Extended EID (XEID)") >>>>>>=20 >>>>>> Note that definition "Extended EID (XEID)" says "optionally = extended >>>>>> with a non-zero Instance ID". Read literally, that means that = zero >>>>>> IIDs aren't included in the XEID, which would be insanity. The = text >>>>>> needs to clarify that IID is always present in the XEID, but is >>>>>> normally zero. >>>>> Well no, not insane, if we required IID for every register and = request, then the XEID would have the same set of tuples for all = lookups. Supplying an IID=3D0 is not wrong or bad semantically and just = cost 32-bits in message space. >>>>>=20 >>>>>> AFI is taken from http://www.iana.org/numbers.html, but you have = to go >>>>>> through the link to draft-ietf-lisp-lcaf to discover that; it = should >>>>>> be stated in this draft. >>>>> True. Authors use the reference I put in the latest LCAF draft. = That was an IESG comment. So we should get it right. >>>>>=20 >>>>>> * For any given delegated prefix, there can be more than one = "peer" >>>>>> DDT nodes that contain duplicated information about the prefix. = But >>>>>> the term "peer" isn't defined in the lexicon, and there is no = explicit >>>>>> statement that the peers (for a prefix) must contain the same >>>>>> information. >>>>> Should be fixed in the text. Thanks. >>>>>=20 >>>>>> * It appears that "Map Server" has been defined elsewhere (RFC = 6833), >>>>>> and that Map Servers can automatically be DDT nodes. Or is it = that >>>>>> some Map Servers are also equipped with DDT node functionality? = If >>>>>> this draft places further requirements on Map Server DDT nodes, = then >>>>>> this draft should be noted as updating RFC 6833. >>>>> Well RFC6833 defines the "bottom-half=E2=80=9D of the map-server. = That is the interface for Map-Registration. A Map-Server is also a = DDT-node when there are map-server-peer configuration so a set of = map-servers that are authoritative and have registeration state for the = same prefix can include themselves as referrals in Map-Referral = messages. >>>>>=20 >>>>>> * There seems to be two meanings of "DDT node". One is a broad = sense, >>>>>> and is any server that responds to Map-Request. The other is a = narrow >>>>>> sense, and means any DDT node in the broad sense that is not a = Map >>>>>> Server, and thus is allowed to contain prefix delegations. These >>>>>> terms need to be separated, and the uses of "DDT node" in the = draft >>>>>> need to be revised to the correct term. >>>>> The name =E2=80=9CMap-Server=E2=80=9D in context to LISP-DDT means = that it is a DDT-node at the bottom of the tree with no DDT-node = children. It is a DDT-node but one with more functionality, Map-Server = functionality according to RFC6833. >>>>>=20 >>>>>> However, the preceding paragraph assumes that a DDT node is not >>>>>> allowed to contain both prefix delegations and ETR registrations. >>>>> Correct. >>>>>=20 >>>>>> That seems to be the case because in many places, those classes = of >>>>>> nodes are required to behave differently (e.g., return different = error >>>>>> codes for nonexistent prefixes) and be treated differently by = other >>>>>> DDT nodes (e.g., referrals to them are given with different = action >>>>>> codes). But there are a few places where the text suggests that = a DDT >>>>>> node could contain both prefix delegations and ETR registrations. >>>>> All correct. You interpreted the idea exactly. >>>>>=20 >>>>>> * Is it really true that two Map Servers that are authoritative = for >>>>>> the same XEID prefix can contain different sets of ETR = registrations? >>>>> Typically no. The set of ETRs at a LISP site will register all the = ETRs RLOCs for the same EID-prefix. Therefore, each map-server, that all = ETRs for that site register to, will have the same = EID-prefix-to-RLOC-set mapping. >>>>>=20 >>>>>> That is, the DDT client (the Map Resolver) may be required to = query >>>>>> the entire set of peer Map Servers to find the right ETR = registration? >>>>> No, it doens=E2=80=99t have to do that. And it SHOULDN=E2=80=99T = that. I can query each referral from a Map-Referral serially or in = parallel, only for reachability and robustness reasons. >>>>>=20 >>>>>> Perhaps the answer is defined in the RFC describing Map Servers, = but >>>>>> it affects one's understanding of this draft enough that it = should be >>>>>> stated in the overview. >>>>> It is a bit. But leaves out specifics to LISP-DDT because = Map-Servers can use any =E2=80=9Cmapping database transport=E2=80=9D = system. >>>>>=20 >>>>>> * The role of hints is not clear. Clearly, a DDT node can be >>>>>> configured with hints regarding some XEID-prefix, but what are = the >>>>>> limitations on what RLOCs must be provided in a hint? This seems >>>>> We should have new text to make this more clear. >>>>>=20 >>>>>> especially important because it seems in practice that the >>>>>> authoritative nodes for a prefix might be reconfigured without = anyone >>>>>> realizing that the hints in nodes farther down the tree need to = be >>>>>> updated. In particular, when should the DDT client follow a = hint? >>>>>> Hints seem to provide the possibility of circular references. = Given >>>>>> that this is an Experimental draft, perhaps the best use of hints = is >>>>>> an "open issue and consideration", and by listing it in section = 11, >>>>>> these questions need not be answered now. >>>>> All good points. Agree. >>>>>=20 >>>>>> 1. Introduction >>>>>>=20 >>>>>> LISP offers a general-purpose mechanism for mapping between EIDs = and >>>>>> RLOCs. In organizing a database of EID to RLOC mappings, this >>>>>> specification extends the definition of the EID numbering space = by >>>>>> logically prepending and appending several fields for purposes = of >>>>>> defining the database index key: Database-ID (DBID, 16 bits), >>>>>> Instance identifier (IID, 32-bits), Address Family Identifier = (16 >>>>>> bits), and EID-prefix (variable, according to AFI value). The >>>>>> resulting concatenation of these fields is termed an "Extended = EID >>>>>> prefix" or XEID-prefix. >>>>>>=20 >>>>>> This paragraph is undecided whether it is defining XEID or >>>>>> XEID-prefix. Better, I think is to define XEID first and then = define >>>>>> XEID-prefix based on that: >>>>>>=20 >>>>>> this >>>>>> specification extends the definition of the EID numbering space = by >>>>>> logically concatenating several fields for purposes of >>>>>> defining the database index key: Database-ID (DBID, 16 bits), >>>>>> Instance identifier (IID, 32-bits), Address Family Identifier = (16 >>>>>> bits), and EID (variable length, according to AFI value). The >>>>>> resulting concatenation of these fields is termed an "Extended = EID" >>>>>> or XEID. Prefixes within the XEID space are thus "Extended EID >>>>>> prefixes" or XEID-prefixes. >>>>>>=20 >>>>>> =E2=80=94 >>>>> Agree. >>>>>=20 >>>>>> It >>>>>> also provides delegation information to Map Resolvers, which use = the >>>>>> information to locate EID-to-RLOC mappings. >>>>>>=20 >>>>>> There needs to be clarification regarding the relationship = between >>>>>> "Map Resolver" and "DDT client". As far as I can tell, in all = places >>>>>> in this document, "DDT client" is the correct term, though it is >>>>>> expected that most (but not all) DDT clients will be Map = Resolvers. >>>>>> So this text should be something like >>>>>>=20 >>>>>> It >>>>>> also provides delegation information to DDT clients (which are >>>>>> usually Map Resolvers, but may be ITRs), which use the >>>>>> information to locate EID-to-RLOC mappings. >>>>>>=20 >>>>>> and approximately all uses of "Map Resolver" should be changed to = "DDT >>>>>> client". >>>>>>=20 >>>>>> LISP-DDT defines a new device type, the DDT node, that is = configured >>>>>> as authoritative for one or more XEID-prefixes. >>>>>>=20 >>>>>> Here would be a good place to lay out clearly the relationship = between >>>>>> DDT node and Map Server: whether nodes that do delegation are >>>>>> disjoint from Map Server nodes, etc. >>>>> Agree. >>>>>=20 >>>>>> 3. Definition of Terms >>>>>>=20 >>>>>> Extended EID (XEID): a LISP EID, optionally extended with a = non- >>>>>> zero Instance ID (IID) if the EID is intended for use in a = context >>>>>> where it may not be a unique value, such as on a Virtual = Private >>>>>> Network where [RFC1918] address space is used. See "Using >>>>>> Virtualization and Segmentation with LISP" in [RFC6830] for = more >>>>>> discussion of Instance IDs. >>>>>>=20 >>>>>> XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID = (provided >>>>>> to allow the definition of multiple databases; currently = always >>>>>> zero in this version of DDT, with other values reserved for = future >>>>>> use), 32-bit IID and 16-bit AFI prepended. Encoding of the >>>>>> prefix, its AFI and the instance ID (IID) are specified by >>>>>> [I-D.ietf-lisp-lcaf]. An XEID-prefix is used as a key index = into >>>>>> the database. >>>>>>=20 >>>>>> These can be simplified by moving the details of the XEID format = and >>>>>> the values of the fields into separate paragraphs (as discussed >>>>>> above). >>>>>>=20 >>>>>> DDT node: a network infrastructure component responsible for >>>>>> specific XEID-prefix and for delegation of more-specific sub- >>>>>> prefixes to other DDT nodes. >>>>>>=20 >>>>>> A DDT node can be authoritative for more than one prefix (see = section >>>>>> 4.2 and section 10, paragraph 2), so "specific XEID-prefix" = should be >>>>>> "specific XEID-prefix(es)". >>>>>>=20 >>>>>> DDT Map Resolver: a network infrastructure element that accepts = a >>>>>> Map-Request, adds the XEID to its pending request list, then >>>>>> queries one or more DDT nodes for the requested EID, = following >>>>>> returned referrals until it receives one with action code = MS-ACK >>>>>> (or an error indication). MS-ACK indicates that the = Map-Request >>>>>> has been sent to a Map Server that will forward it to an ETR = that, >>>>>> in turn, will provide a Map-Reply to the original sender. A = DDT >>>>>> Map Resolver maintains both a cache of Map-Referral message >>>>>> results containing RLOCs for DDT nodes responsible for XEID- >>>>>> prefixes of interest (termed the "referral cache") and a = pending >>>>>> request list of XEIDs that are being resolved through = iterative >>>>>> querying of DDT nodes. >>>>>>=20 >>>>>> This isn't really a definition of what how Map Resolver fits into = the >>>>>> overall scheme, but an outline of Map Resolver processing. The >>>>>> description of processing should be moved somewhere else. Also, = any >>>>>> DDT client that is not a Map Resolver must do the same = processing, so >>>>>> "DDT client" and "DDT Map Resolver" should be merged. >>>>> I think we should have both. >>>>>=20 >>>>>> DDT Map-Request: an Encapsulated Map-Request sent by a DDT = client to >>>>>> a DDT node. The "DDT-originated" flag is set in the = encapsulation >>>>>> header ... >>>>>>=20 >>>>>> Given the importance of Map-Request messages, it might be worth >>>>>> mentioning that they are defined in RFC 6830. >>>>> Agree. >>>>>=20 >>>>>> What is the need for the DDT-originated flag? It seems from the >>>>>> definition "Encapsulated Map-Request" that EMRs from ITRs to Map >>>>>> Resolvers never have the flag set, EMRs from Map Resolvers to DDT >>>>>> nodes (including Map Servers) always have the flag set, and EMRs = from >>>>>> Map Servers to ETRs never have the flag set. But if that is so, = no >>>>>> type of device can receive EMRs that both have the flag set and = not. >>>>> The flag is to tell the difference between a Map-Request that is = originated by a LISP-site (ITR or PITR) and one that is sent by a = Map-Resolver. One generates a Map-Reply and the other generates a = Map-Referral. >>>>>=20 >>>>>> Hmmm, the exception is if an ITR acts as a DDT client sends a >>>>>> Map-Request directly to DDT nodes. But in that case, the DDT = nodes >>>>>> would process the Map-Request in exactly the same way as a Map >>>>>> Resolver, so there is no need for a "D" flag. >>>>> That is that the typical case though. Look at it as a Map-Request, = with DDT-flag set, as a solitication for a Map-Referral. >>>>>=20 >>>>>> Also, the definition of the flag in section 5 is awkward: >>>>>>=20 >>>>>> D: The "DDT-originated" flag. It is set by a DDT client to = indicate >>>>>> that the receiver SHOULD return Map-Referral messages as >>>>>> appropriate. Use of the flag is further described in >>>>>> Section 7.3.1. This bit is allocated from LISP message = header >>>>>> bits marked as Reserved in [RFC6830]. >>>>>>=20 >>>>>> If the flag *means* "DDT-originated", then the message must have = come >>>>>> from a DDT client, and the receiver MUST return Map-Referral = messages >>>>>> -- that's what this draft is specifying! >>>>> Correct. >>>>>=20 >>>>>> I get the feeling that the D flat is (or was) intended to work = like >>>>>> the DNS "recursion" flag, it tells whether the client is willing = to >>>>>> accept and follow Map-Referral messages, or whether the client = wants >>>>>> to put that work of following referrals on the server. But as = the >>>>> It can work that way. Do you think calling the bit = =E2=80=9CRequest-for-Map-Referral=E2=80=9D would be better? >>>>>=20 >>>>>> lexicon makes clear, *any* DDT client must be willing to follow >>>>>> Map-Referral messages, and DDT nodes are *never* required to = follow >>>>>> referrals on behalf of the DDT client. >>>>> Or we could call the bit =E2=80=9CDDT-client-flag=E2=80=9D. And = still keep the reference to the bit called =E2=80=9CD=E2=80=9D. >>>>>=20 >>>>>> Map-Referral: a LISP message sent by a DDT node in response to = a DDT >>>>>> Map-Request for an XEID that matches a configured XEID-prefix >>>>>> delegation. A non-negative Map-Referral includes a = "referral", a >>>>>> set of RLOCs for DDT nodes that have more information about = the >>>>>> sub-prefix; >>>>>>=20 >>>>>> The phrase "more information" is used in various places, but it = is not >>>>>> really informative. As far as I can tell, all uses of "DDT nodes = that >>>>> We should say =E2=80=9Cmore specific information=E2=80=9D. Where = =E2=80=9Cmore-specific=E2=80=9D is relative to the xEID-prefix. >>>>>=20 >>>>>> have more information" mean "DDT nodes to which that XEID has = been >>>>>> delegated". Unless perhaps hints are also considered to point to = "DDT >>>>>> nodes that have more information", in which case the term "more >>>>>> information" needs to be defined specifically, as it doesn't = always >>>>>> mean a delegation relationship. >>>>>>=20 >>>>>> Negative Map-Referral: a Map-Referral sent in response to a DDT = Map- >>>>>> Request that matches an authoritative XEID-prefix but for = which >>>>>> there is no delegation configured (or no ETR registration if = sent >>>>>> by a DDT Map-Server). >>>>>>=20 >>>>>> I'd describe a negative Map-Referral as an answer from an >>>>>> authoritative DDT node that there is no mapping for the requested >>>>>> XEID. That happens because the request is sent to an = authoritative >>>>>> DDT node "but for which there is no delegation configured (or no = ETR >>>>>> registration if sent by a DDT Map-Server)", but the core = semantics is >>>>>> an authoritative denial of a mapping. >>>>> True. We should have new text to make this more clear. >>>>>=20 >>>>>> Pending Request List: the set of outstanding requests for which = a >>>>>> DDT Map Resolver has received encapsulated Map-Requests from = a DDT >>>>>> client for an XEID. >>>>>>=20 >>>>>> Is it correct that a DDT Map Resolver can receive Map-Requests = from >>>>>> DDT clients? I thought a Map Resolver could only receive them = from >>>>> No, not architecturally. It receives only Map-Requests with the = DDT-bit set to 0. I say no architecturelly because if the map-resolver = is also a map-server, then it could receive DDT Map-Requests. But it is = acting as a map-server. >>>>>=20 >>>>> DDT-nodes could also be map-resolvers. Which mean they are part of = the delegarion hierarchy but also are configured with DDT-roots to send = requests. It all comes down to how a network adminstrator would want to = co-locate such functions. >>>>>=20 >>>>> With the popularity of VMs and containers, the same piece of = bare-metal could be both a map-resolver and DDT-node, but from a LISP = architecture point of view, they are separate nodes (with separate IP = addresses). >>>>>=20 >>>>>> ITRs, and a DDT client could only send them to DDT nodes. If a = Map >>>>>> Resolver can receive requests from other Map Resolvers, there are >>>>>> complexities of behavior that don't seem to be described in this >>>>>> draft. >>>>> DDT-Map-Requests to not get sent to Map-Resolvers and we should = make that crystal clear. >>>>>=20 >>>>>> In any case, does this need an entry in the lexicon? It seems = that a >>>>>> pending request list is an implementation detail and should be >>>>>> described in the algorithm description sections. >>>>>>=20 >>>>>> It is important to note that LISP-DDT does not store actual = EID-to- >>>>>> RLOC mappings; it is, rather, a distributed index that can be = used to >>>>>> find the devices (Map Servers and their registered EIDs) that = can be >>>>>> queried with LISP to obtain those mappings. >>>>>>=20 >>>>>> This text defines that Map Servers are not part of DDT, but the >>>>>> lexicon refers to DDT Map Servers. And actually, its the ETRs = that >>>>>> store the EID-to-RLOC mappings, not the Map Servers (except when = the >>>>>> Map Server is proxying for the ETR). >>>>> Map-Servers configured as a DDT-node is definitely part of DDT = because they must send MS-ACK based Map-Referrals. Because if this does = not happen, then Map-Resolvers will retransmit and think they have not = got to the bottom of the referral tree. >>>>>=20 >>>>>> 6.1. Action codes >>>>>>=20 >>>>>> MS-ACK (2): indicates that a replying DDT Map Server received a = DDT >>>>>>=20 >>>>>> s/a replying/the replying/ >>>>> Agree. >>>>>=20 >>>>>> NOT-AUTHORITATIVE (5): indicates that the replying DDT node = received >>>>>> a Map-Request for an XEID-request for which it is not >>>>>> authoritative. This can occur if a cached referral has = become >>>>>> invalid due to a change in the database hierarchy. >>>>>>=20 >>>>>> There's a treacherous case of how hints are returned by a DDT = node. >>>>>> Reading the above definition, it's clear that a hint should be >>>>>> returned with a NON-AUTHORITATIVE action code, because the node = isn't >>>>>> authoritative for the XEID. Then again, section 6.1 suggests = that >>>>>> hints are returned as NODE-REFERRAL or MS-REFERRAL. If so, = things get >>>>>> messy -- How is the DDT client to know that the referral set is a = hint >>>>>> rather than an authoritative delegation? And that distinction is >>>>>> necessary because the client can't fully trust hints. >>>>> To be honest, I am questioning the value of =E2=80=9Chint=E2=80=9D = as a reference. Hmm. Let=E2=80=99s see what the authors think about = this. >>>>>=20 >>>>>> 6.3. Incomplete flag >>>>>>=20 >>>>>> o If it is setting action code MS-ACK or MS-NOT-REGISTERED but = does >>>>>> not have configuration for other "peer" DDT nodes that are = also >>>>>> authoritative for the matched XEID-prefix. >>>>>>=20 >>>>>> Is this situation equivalent to the referral set being a hint = rather >>>>>> than a delegation? Or rather, a hint which the DDT node doesn't >>>>>> believe is the complete peer set for the prefix? (Is there any = way >>>>>> for a DDT node to know that it has the complete peer set?) In = any >>>>>> case, it seems to me that this might be usefully changed to "hint >>>>>> flag". >>>>>>=20 >>>>>> 6.4. Map-Referral Message Format >>>>>>=20 >>>>>> Is it intended that the "record" and "ref" sections can be = repeated? >>>>>> That is a different usage of bracketing than in the figure in = section >>>>>> 5, and if so, should be described in the text. >>>>> Agree. >>>>>=20 >>>>>> I note that this section lists all the action codes, as does = section >>>>>> 6.1. It seems like these should be consolidated into section = 6.1. >>>>>>=20 >>>>>> The handling of the "Incomplete" column of the table cannot be >>>>>> correct. There is no way for a node to send hints and mark them >>>>>> Incomplete, and the description at the top of page 12 is = incompatible >>>>>> with the contents of the table. >>>>> We don=E2=80=99t want to add an additional set of comabinations = for hints and non-hints. Authors, we should discuss this. >>>>>=20 >>>>>> Loc/LCAF-AFI: If this is a Loc AFI, keys SHOULD NOT be included = in >>>>>> the record. If this is a LCAF AFI, the contents of the LCAF = depend >>>>>> on the Type field of the LCAF. Security material are stored in = LCAF >>>>>> Type 11. DDT nodes and Map Servers can use this LCAF Type to = include >>>>>> public keys associated with their Child DDT nodes for a = XEID-prefix >>>>>> referral record. LCAF types and formats are defined in >>>>>> [I-D.ietf-lisp-lcaf]. >>>>>>=20 >>>>>> This paragraph doesn't make sense in this context. The terms = "Loc", >>>>>> "keys", "LCAF", "Security material" are all undefined in this = context. >>>>>>=20 >>>>>> Note, though, >>>>>> that the set of RLOCs correspond to the DDT node to be queried = as a >>>>>> result of the referral not the RLOCs for an actual EID-to-RLOC >>>>>> mapping. >>>>>>=20 >>>>>> I take it that the "Ref" sections is counted by the "Referral = Count" >>>>>> field, and that the "Loc/LCAF-AFI" and "Locator" fields contain = the >>>>>> RLOCs of the set of DDT nodes that are the referral set. It = might >>>>>> help the reader to rephrase this sentence in those terms. >>>>> All this is trying to say (and with too many words), is that the = referral-set is stored in a Map-Referral as RLOC-records. That is all. >>>>>=20 >>>>>> 6.4.1. SIG section >>>>>>=20 >>>>>> Sig Length: The length of the Signature field. >>>>>>=20 >>>>>> Is this measured in bytes? >>>>>>=20 >>>>>> Signature: Contains the cryptographic signature that covers the >>>>>> entire record. The Record TTL and the sig fields are set to = zero for >>>>>> the purpose of computing the Signature. >>>>> Needs to be fixed in the text. >>>>>=20 >>>>>> It's not clear to me why the Record TTL should be set to zero for >>>>>> computing the signature, given that you'd want to protect the TTL = from >>>>>> modification. Also, what is the relationship between Record TTL = and >>>>>> Original Record TTL? As far as I can tell, no DDT element can = receive >>>>>> a Map-Referral Record from another element and pass it on to a = third >>>>>> element, so there need never be TTL skew between when a record = was >>>>>> signed and when it was sent. >>>>> The signature covers the complete Map-Referral message. If that is = not clear, we will make it clear. >>>>>=20 >>>>>> It seems awkward to compute the signature by first laying out the = Sig >>>>>> section and filling it with zeros when the same benefit could be >>>>>> obtained by omitting the Sig section from the part of the record = whose >>>>>> signature is calculated. >>>>> It allows the implementation to be more efficient. You build the = message once with the correct length include the signature records, run = the hash over it. And then fill in the zero bit fields. That way you can = then include the referral addresses that are part of the LCAF. >>>>>=20 >>>>>> Is it a problem that Original Record TTL, Signature Expiration, = and >>>>>> Signature Inception aren't protected by the signature? >>>>> The entire Map-Referral should be covered by the signature. >>>>>=20 >>>>>> 7.1.1. Match of a delegated prefix (or sub-prefix) >>>>>>=20 >>>>>> If the delegation is known to be a DDT Map Server, >>>>>>=20 >>>>>> This seems to assume that either all delegatees are Map Servers = or >>>>>> none are. All of the processing algorithms seem to presuppose = that a >>>>>> set of peers either are all Map Servers or all are not, but there >>>>>> doesn't seem to be an explicit requirement of that. >>>>> See my explanations above. >>>>>=20 >>>>>> 7.1.2. Missing delegation from an authoritative prefix >>>>>>=20 >>>>>> If the requested XEID did not match a configured delegation but = does >>>>>> match an authoritative XEID-prefix, then the DDT node MUST = return a >>>>>> negative Map-Referral that uses the least-specific XEID-prefix = that >>>>>> does not match any XEID-prefix delegated by the DDT node. >>>>>>=20 >>>>>> It would be a bit clearer if "the least-specific XEID-prefix" was >>>>>> changed to "the least-specific prefix of the XEID". >>>>>>=20 >>>>>> If the requested XEID did not match either a configured = delegation or >>>>>> an authoritative XEID-prefix, then negative Map-Referral with = action >>>>>> code NOT-AUTHORITATIVE MUST be returned. >>>>>>=20 >>>>>> I understand what you mean, but this isn't phrased quite right in >>>>>> regard to hints, because the DDT node may have a hint for an >>>>>> XEID-prefix that is neither a configured delegation nor within = one of >>>>>> its authoritative XEID-prefixes, but hints are returned with >>>>>> NODE-REFERRAL. >>>>> Agree. >>>>>=20 >>>>>> 7.3. DDT Map Resolver >>>>>> 7.3.1. Queuing and sending DDT Map-Requests >>>>>>=20 >>>>>> I think there is an issue around the cache. Usually (IMHO) when >>>>>> discussing "resolvers", the "cache" is entirely transient = information >>>>>> that the resolver has acquired from other devices, it doesn't = contain >>>>>> configured information. But in some places, the draft reads as = if the >>>>> True, in the DDT case as well. >>>>>=20 >>>>>> configured information is permanently present in the cache. If = that >>>>>> is so, it would help the reader (i.e., this reader!) if when the = cache >>>>>> is introduced that it was stated that the configured delegations = (and >>>>>> hints) are permanently resident in the cache. >>>>> But that isn=E2=80=99t precisely true. Delegations ARE = configuration items, in DDT-nodes, all of roots, ddt-nodes, and = map-servers. And the cache is dynamically created entries from = Map-Referrals from those node=E2=80=99s configuration information. >>>>>=20 >>>>>> That is, this should be promoted from section 7.3.1 to 7.3 where = the >>>>>> structure (rather than the detailed behavior) of a Map Resolver = is >>>>>> discussed: >>>>>>=20 >>>>>> The referral cache is initially populated with one or more >>>>>> statically-configured entries; >>>>>>=20 >>>>>> Similarly this is a structural statement about the cache: >>>>>>=20 >>>>>> A DDT Map Resolver is not absolutely required to cache = referrals, >>>>>> but it doing so decreases latency and reduces lookup delays. >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> Note that in normal use on the public Internet, the statically- >>>>>> configured initial referral cache for a DDT Map Resolver should >>>>>> include a "default" entry with RLOCs for one or more DDT nodes = that >>>>>> can reach the DDT root node. >>>>>>=20 >>>>>> This suggests that it will be common that a Map Resolver won't be >>>>>> configured with the RLOCs of the root nodes (which is different = from >>>>> No, they would be. >>>>>=20 >>>>>> the common DNS usage), but rather configured with the RLOCs of = nodes >>>>>> that contain a hint for the null prefix and the root nodes. = (Also, >>>>>> "can reach" should be changed to "containing hints for".) If = this is >>>>>> so, then the operation of hints is a central part of the DDT = protocol >>>>>> and (IMO) it would greatly help if the role and processing of = hints >>>>>> was outlined in some location. In particular, it suggests that = all >>>>>> nodes that are expected to be the initial node for an extensible >>>>>> population of Map Resolvers SHOULD be configured with a hint for = the >>>>>> root nodes. >>>>> We have to simplify this wording. It is more complex than it needs = to be. >>>>>=20 >>>>>> There is also a possible conflict with section 10 -- the Map = Resolver >>>>>> isn't expected to be configured with the RLOCs of the root = servers, >>>>>> but it is expected to be configured with the public keys of the = root >>>>>> servers. Indeed, given the language in section 10, the keys can >>>>> No, both. Because map-resolvers need to know where to send = DDT-Map-Requests and when they get signed Map-Referrals, then need a = public key to verify the signature. And the reason is beacuse there is = no parent of the root that can give the map-resolver the public-key like = the rest of the hierarchy can do. >>>>>=20 >>>>>> differ between the various root DDT nodes, which means that in = order >>>>>> to configure the Map Resolver with the public keys of the root >>>>>> servers, it must be configured with their RLOCs. >>>>> Yes, yes, yes. >>>>>=20 >>>>>> 7.3.2. Receiving and following referrals >>>>>>=20 >>>>>> If the maximum number of retransmissions has occurred and all = RLOCs >>>>>> have been tried, then the pending request list entry is = dequeued. >>>>>>=20 >>>>>> This isn't phrased quite right, because it requires a further >>>>>> retransmission if "the maximum number of retransmissions has = occurred" >>>>>> but not "all RLOCs have been tried" -- and that would mean = sending >>>>>> more retransmissions than the "maximum number". >>>>>>=20 >>>>>> I believe that the intention is that the Map Resolver must = attempt to >>>>>> contact all relevant RLOCs, but that it must also send at least >>>>>> "number of retransmissions", meaning that if there are fewer = RLOCs >>>>>> than that number, some RLOCs will be attempted more than once. = If >>>>>> that is so, then "maximum number" should be "minimum number=E2=80=9D= . >>>>> Really good point. >>>>>=20 >>>>>> OTOH, if "maximum number" is intended, then the text should be = "If the >>>>>> maximum number of retransmissions has occurred or all RLOCs have = been >>>>>> tried=E2=80=9D. >>>>> Right. >>>>>=20 >>>>>> Also, this paragraph should specify what response the Map = Resolver >>>>>> should send if processing is terminated due to response time-out. = As >>>>>> written, the text doesn't require the Map Resolver to send *any* >>>>>> response, which seems like a bad design. >>>>> Agree. The Map-Resolver does send a response. If its not = documented, we missed it and will add. >>>>>=20 >>>>>> MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the = same >>>>>> manner >>>>>>=20 >>>>>> It might be better to say "processes" than "follows=E2=80=9D. >>>>> Agree. >>>>>=20 >>>>>> MS-ACK: This is returned by a DDT Map Server to indicate that = it has >>>>>> one or more registered ETRs that can answer a Map-Request for = the >>>>>> XEID and the request has been forwarded to one of them >>>>>>=20 >>>>>> It's not clear to me how the Map Server or ETR knows the address = of >>>>>> the DDT client to which to send the Map-Reply. It seems that the >>>>>> address must be in the Map-Request message, but reading that = section >>>>>> of RFC 6830 doesn't make it clear to me how that is done. >>>>>>=20 >>>>>> The processing regarding MS-ACK is not clear to me. It would = help if >>>>>> there was an overview discussion of the four-way dance between = the DDT >>>>>> client, the Map Resolver, the Map Server, and the ETR. (Some = times >>>>>> the Map Server also does the ETR's job.) Since one step of it is = for >>>>>> the ETR to send Map-Replay to the DDT client, this processing = doesn't >>>>>> break down into separate client/Map Resolver, Map Resolver/Map = Server, >>>>>> and Map Server/ETR components, there's a specific overall = structure. >>>>> You are absolutely right. There needs to be a complete example of = the =E2=80=9Cday in the life of a Map-Request=E2=80=9D when the = Map-Resolver has nothing cached and the ITR and ETR are not DDT-clients. = That is the typical use-case that has been and will continue to be = deployed. >>>>>=20 >>>>>> In particular, what happens when a Map Resolver sends a = Map-Request to >>>>>> a Map Server without LISP-SEC information? It appears that = processing >>>>>> goes through two cycles, with a second cycle when the Map = Resolver >>>>>> re-sends the Map-Request to the Map Server with LISP-SEC = information. >>>>>> The Map Server seems to return MS-ACK messages to the Map = Resolver in >>>>>> both cycles, and there is no special marking in the first MS-ACK >>>>>> message to indicate that resending must be done (the Map Resolver = can >>>>>> determine that itself). But presumably, the Map Server forwards = the >>>>>> Map-Request to the ETR in both cycles, and the ETR sends = Map-Replys to >>>>>> the client in both cycles. Presumably the first Map-Reply is = useless >>>>>> to the client (otherwise there wouldn't need to be two cycles), = but >>>>>> it's not clear how the client deals with two replies. >>>>> LISP-SEC information is in the Map-Request from the ITR, = transported in the DDT-Map-Request so an ETR can get the LISP-SEC = information in the Map-Request to then return LISP-SEC in the = *Map-Reply*. >>>>>=20 >>>>> The Map-Server only sends Map-Replies when it is configured to = proxy-reply and the ETR is not in the loop here. And it would fill in = the same LISP-SEC information the ETR would because the registration = information is the same as the database entry info the ETR has stored. >>>>>=20 >>>>>> MS-NOT-REGISTERED: ... >>>>>> The DDT Map Resolver MUST return a negative >>>>>> Map-Reply to the original Map-Request sender; this Map-Reply >>>>>> contains the non-registered XEID-prefix whose TTL value = SHOULD be >>>>>> set to one minute. >>>>>>=20 >>>>>> I think "non-registered XEID-prefix" is meant to mean = "least-specific >>>>>> prefix of the XEID for which no registrations exist=E2=80=9D. >>>>> It means the DDT-Map-Request went all the way to the map-server, = it has a a configure LISP site entry and the ETRs have not registered = (yet). >>>>>=20 >>>>>> NOT-AUTHORITATIVE: ... >>>>>> The pending request is silently discarded, i.e. all state >>>>>> for the request that caused this answer is removed and no = answer >>>>>> is returned to the original requester. >>>>>>=20 >>>>>> It seems like a poor design to return no response. Is there not = some >>>>> A response is ALWAYs returned in LISP-DDT. The only time it = can=E2=80=99t is when a Map-Request cannot get to where its going or the = Map-Referral cannot get back to the DDT-client source. And that is the = only case we call a =E2=80=9Ctimeout=E2=80=9D. >>>>>=20 >>>>>> sort of "server failure" response that can be returned to the DDT >>>>>> client? >>>>>>=20 >>>>>> 8. Pseudo Code and Decision Tree diagrams >>>>>>=20 >>>>>> Care needs to be taken here as to whether the pseudo-code and = decision >>>>>> trees are normative or not. Generally, algorithms enunciated in = RFCs >>>>>> are marked as non-normative, as the implementation is usually = allowed >>>>>> to deviate from the stated algorithm as long as it satisfies the >>>>>> constraints written in the text. >>>>> Agree. We should have new text to make this more clear. >>>>>=20 >>>>>> 9. Example topology and request/referral following >>>>>>=20 >>>>>> The same principle >>>>>> of hierarchical delegation and pinpointing referrals is equally >>>>>> applicable to any AF whose address hierarchy can be expressed as = a >>>>>> bitstring with associated length. >>>>>>=20 >>>>>> This sentence seems to be redundant because we've been assuming = all >>>>>> along that in any address family used by DDT the address = hierarchy is >>>>>> expressed as bistrings with lengths. >>>>>>=20 >>>>>> Are lines in the diagram intended to cross? If so, they could be >>>>>> clarified as: >>>>> Yes, because each parent points to 2 children. >>>>>=20 >>>>>> +---------------------+ +---------------------+ >>>>>> | root1: 192.0.2.1 | | root2: 192.0.2.2 | >>>>>> | authoritative: ::/0 | | authoritative: ::/0 | >>>>>> +---------------------+ +---------------------+ >>>>>> | \ / | >>>>>> | \ / | >>>>>> | X | >>>>>> | / \ | >>>>>> | / \ | >>>>>> | | | | >>>>>> V V V V >>>>>> +-------------------------+ +--------------------------+ >>>>>> | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | >>>>>> | authoritative: | | authoritative: | >>>>>> | 2001:db8::/32 | | 2001:db8::/32 | >>>>>> +-------------------------+ +--------------------------+ >>>>>> | \ / | >>>>>> | \ / | >>>>>> | X | >>>>>> | / \ | >>>>>> | / \ | >>>>>> | | | | >>>>>> V V V V >>>>>> +--------------------------+ +---------------------------+ >>>>>> | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | >>>>>> | authoritative: | | authoritative: | >>>>>> | 2001:db8:0100::/40 | | 2001:db8:0500::/40 | >>>>>> | site1: 2001:db8:0103::/48| +---------------------------+ >>>>>> | site2: 2001:db8:0104::/48| | | >>>>>> +--------------------------+ | | >>>>>> | | >>>>>> | | >>>>>> V V >>>>>> +---------------------------+ = +---------------------------+ >>>>>> | Map-Server2: 192.0.2.211 | | Map-Server3: = 192.0.2.221 | >>>>>> | authoritative: | | authoritative: = | >>>>>> | 2001:db8:0500::/48 | | 2001:db8:0501::/48 = | >>>>>> |site3: 2001:db8:0500:1::/64| |site5: = 2001:db8:0501:8::/64| >>>>>> |site4: 2001:db8:0500:2::/64| |site6: = 2001:db8:0501:9::/64| >>>>>> +---------------------------+ = +---------------------------+ >>>>>>=20 >>>>>>=20 >>>>>> 10. Securing the database and message exchanges >>>>>>=20 >>>>>> Each DDT node is configured with one or more public/private key >>>>>> pair(s) that are used to digitally sign referral records for = XEID- >>>>>> prefix(es) that the DDT node is authoritative for. In other = words, >>>>>> each public/private key pair is associated with the combination = of a >>>>>> DDT node and the XEID-prefix that it is authoritative for. >>>>>>=20 >>>>>> s/the XEID-prefix/an XEID-prefix/ >>>>> Agree. >>>>>=20 >>>>>> But the first sentence doesn't say the same thing as the second >>>>>> sentence. Better would be >>>>>>=20 >>>>>> Each DDT node is configured with one or more public/private key >>>>>> pairs for each XEID-prefix that it is authoritative for, and = those >>>>>> keys are used to sign referral records for XEID-prefixes within = the >>>>>> authoritative XEID-prefix. >>>>> Agree. >>>>>=20 >>>>>> Also, there should be some text as to whether a node is required = to >>>>>> sign a referral record with *all* of its keys. And in general, = there >>>>>> should be some discussion of the significance and use of multiple = keys >>>>>> for a single DDT node/authoritative prefix. >>>>> Really good point. I definitely agree. >>>>>=20 >>>>>> Every DDT >>>>>> node is also configured with the public keys of its children DDT >>>>>> nodes. By including public keys of target child DDT nodes in = the >>>>>> Map-Referral records, and signing each record with the DDT = node's >>>>>> private key, a DDT node can securely delegate sub-prefixes of = its >>>>>> authoritative XEID-prefixes to its children DDT nodes. >>>>>>=20 >>>>>> Does a DDT node have the public keys of the DDT nodes that its = hints >>>>>> point to? If not, hints can't be trusted and followed in the = same way as >>>>>> "downward" Map-Referrals, which breaks the trust sequence if the = DDT >>>>>> client is not configured with the keys of the RLOCs in the hint. >>>>> It should yes. >>>>>=20 >>>>>> Also, how does the DDT node return public keys to the Map = Resolver? I >>>>>> don't see any field for it in the Map-Referral message. >>>>> An RLOC record contains LCAF type 11 with the RLOC/address of the = referral and key material. >>>>>=20 >>>>>> 11. Open Issues and Considerations >>>>>>=20 >>>>>> o Management of the DDT Map Resolver referral cache, in = particular, >>>>>> detecting and removing outdated entries. >>>>>>=20 >>>>>> I assume that this means "the definition and use of TTL values", >>>>>> because the use of TTL values does not seem to be completely = described >>>>>> in this document. Perhaps this item could be rephrased to = mention TTL >>>>>> explicitly. >>>>> Agree. >>>>>=20 >>>>>> 13. Security Considerations >>>>>>=20 >>>>>> For this reason, when >>>>>> LISP-SEC is deployed in conjunction with a LISP-DDT mapping = database >>>>>> and the path between Map-Resolver and Map-Server needs to be >>>>>> protected, DDT security should be enabled as well. >>>>>>=20 >>>>>> This sentence is obscure, because "DDT security" is not defined >>>>>> anywhere, and there seems to be no optional security mechanism >>>>>> described in the draft. >>>>> We have referred to LISP-DDT-SEC to mean the public/private key = signing of Map-Referral messages. That is what the reference to DDT = security could mean. But this section could be confidentiality support = as well. >>>>>=20 >>>>>> 14.2. Informative References >>>>>>=20 >>>>>> [I-D.ietf-lisp-lcaf] >>>>>> Farinacci, D., Meyer, D., and J. Snijders, "LISP = Canonical >>>>>> Address Format (LCAF)", draft-ietf-lisp-lcaf-13 (work = in >>>>>> progress), May 2016. >>>>>>=20 >>>>>> The reference to ietf-lisp-lcaf in the definition "XEID-prefix" = in >>>>>> section 3 seems to be normative (unless the text in this draft is >>>>>> adjusted to consider XEIDs as undifferentiated bit strings). >>>>> Should be normative since we are about to publish the LCAF RFC. >>>>>=20 >>>>>> [LISP-TREE] >>>>>> Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, = D., >>>>>> and O. Bonaventure, "LISP-TREE: a DNS hierarchy to = support >>>>>> the lisp mapping system", Selected Areas in >>>>>> Communications, IEEE Journal , 2010, >>>>>> >>>>> abs_all.jsp?arnumber=3D5586446>. >>>>>>=20 >>>>>> This reference is not referenced. >>>>>>=20 >>>>>> [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography >>>>>> Standards (PKCS) #1: RSA Cryptography Specifications >>>>>> Version 2.1", RFC 3447, DOI 10.17487/RFC3447, = February >>>>>> 2003, . >>>>>>=20 >>>>>> The reference to RFC 3447 in section 6.4.1 seems to be normative, = as >>>>>> the specifics of RSA-SHA1 signatures come from this RFC. >>>>> Agree. >>>>>=20 >>>>>> Dale >>>>> Thanks again for the really detailed comments. >>>>>=20 >>>>> Dino >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 From nobody Tue Jan 17 10:56:16 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD59E129424 for ; Tue, 17 Jan 2017 10:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKVP0GbO4Acy for ; Tue, 17 Jan 2017 10:56:13 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0369E126CD8 for ; Tue, 17 Jan 2017 10:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8123; q=dns/txt; s=iport; t=1484679373; x=1485888973; h=from:to:subject:date:message-id:references:mime-version; bh=O7wqiHnoTlVdIBLtBTOpvW11vDFegFNSBCDlsYgdjYw=; b=aEMC3J+r7p5JEWJqRzdMXLYmu32rW2w2UAQwqg2GWn3HXuGyR/i/RgO6 eheaBS1cV2Qtcu7PUcMaxHQH+22kZFxv+HYUv9mXAkHKR+PLr4BNyTEE+ 5cEUcDMq3RbjviHt/nk0q2M07439wIcUjXrCh63MOnun0mkk/AFf/IvoR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQB5Z35Y/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR9fgQkHjVGSGIgEh32FK4ILKoQegVoCghU/GAECAQE?= =?us-ascii?q?BAQEBAWMohGkBBncSAgEZAwECKAchERQHAggCBBOIaAMYDrFmhzoNgmEBAQEBA?= =?us-ascii?q?QEBAwEBAQEBAQEBAR+GRYICgmWCUIIYFoJ9gjEFjyOGDIVTOAGGXIZ+hASBd1G?= =?us-ascii?q?EPYloihiIUwEPEDiBRBUYMgGEKxeBX3MBh0qBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208,217";a="196129180" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jan 2017 18:56:12 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0HIuB7h011137 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Jan 2017 18:56:11 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 12:56:11 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 12:56:11 -0600 From: "Victor Moreno (vimoreno)" To: LISP mailing list list Thread-Topic: New Version Notification for draft-moreno-lisp-vpn-00.txt Thread-Index: AQHScPDxbtNhZIqlSU2lwTl/ovcyXA== Date: Tue, 17 Jan 2017 18:56:11 +0000 Message-ID: <53AAAB49-4DB0-42BF-A71A-C392C6505282@cisco.com> References: <148467832460.31979.2279009828186502106.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.157.244] Content-Type: multipart/alternative; boundary="_000_53AAAB494DB042BFA71AC392C6505282ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lisp] Fwd: New Version Notification for draft-moreno-lisp-vpn-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 18:56:14 -0000 --_000_53AAAB494DB042BFA71AC392C6505282ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI team. Looking for your insight and comments. Regards, -v Begin forwarded message: From: > Subject: New Version Notification for draft-moreno-lisp-vpn-00.txt Date: January 17, 2017 at 10:38:44 AM PST To: Victor Moreno >, Dino Far= inacci > A new version of I-D, draft-moreno-lisp-vpn-00.txt has been successfully submitted by Victor Moreno and posted to the IETF repository. Name: draft-moreno-lisp-vpn Revision: 00 Title: LISP Virtual Private Networks (VPNs) Document date: 2017-01-17 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-moreno-lisp-vpn-= 00.txt Status: https://datatracker.ietf.org/doc/draft-moreno-lisp-vpn/ Htmlized: https://tools.ietf.org/html/draft-moreno-lisp-vpn-00 Abstract: This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. 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 --_000_53AAAB494DB042BFA71AC392C6505282ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8DF4969AEBCB4247ADC77874E0D77165@emea.cisco.com> Content-Transfer-Encoding: quoted-printable FYI team.

Looking for your insight and comments.

Regards,

-v


Begin forwarded message:

From: <internet-drafts@ietf.org>
Subject: New Version Notification = for draft-moreno-lisp-vpn-00.txt
Date: January 17, 2017 at 10:38:44 AM PST
To: Victor Moreno <vimoreno@cisco.com>, Dino Farinacci <= farinacci@gmail.com&g= t;


A new version of I-D, draft-moreno-lisp-vpn-00.txt
has been successfully submitted by Victor Moreno and posted to the
IETF repository.

Name: draft-moreno-lis= p-vpn
Revision: 0= 0
Title: LISP Virtual Pr= ivate Networks (VPNs)
Document date: 2017-01-17
Group: Individual Subm= ission
Pages: 16
URL:            https://www.ietf.org/internet-drafts/draft-moreno-lisp-vpn-00.txt=
Status:         https://datatra= cker.ietf.org/doc/draft-moreno-lisp-vpn/
Htmlized:       https://tools.ietf.org/html/= draft-moreno-lisp-vpn-00


Abstract:
  This document describes the use of the Locator/ID Separation Pr= otocol
  (LISP) to create Virtual Private Networks (VPNs).  LISP is= used to
  provide segmentation in both the LISP data plane and control pl= ane.
  These VPNs can be created over the top of the Internet or over<= br class=3D"">   private transport networks, and can be implemented by Enterpris= es or
  Service Providers.  The goal of these VPNs is to leverage = the
  characteristics of LISP - routing scalability, simply expressed=
  Ingress site TE Policy, IP Address Family traversal, and mobili= ty, in
  ways that provide value to network operators.





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


--_000_53AAAB494DB042BFA71AC392C6505282ciscocom_-- From nobody Tue Jan 17 13:32:59 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC12F1295BF for ; Tue, 17 Jan 2017 13:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieYVLUn_02TC for ; Tue, 17 Jan 2017 13:32:56 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7CD1295BC for ; Tue, 17 Jan 2017 13:32:53 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-07v.sys.comcast.net with SMTP id TbN7cwnIfj8tqTbN7cQF6Z; Tue, 17 Jan 2017 21:32:53 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with SMTP id TbN5cYT3Jaq1HTbN6caoQM; Tue, 17 Jan 2017 21:32:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v0HLWpKg009600; Tue, 17 Jan 2017 16:32:51 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0HLWonQ009597; Tue, 17 Jan 2017 16:32:50 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Dino Farinacci In-Reply-To: (farinacci@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 17 Jan 2017 16:32:50 -0500 Message-ID: <87inpdpe2l.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJsb4xnKUVjv+wiZsAMve8wJ3RrlaZshaYG9PPDmK4MwJ/bhQji4inVBhqOYDbCNowaaIoTgSl8zasVr5qcVQpgnhm+asBGjGVcBizgEexenM1cfnh1o RwS2mruCL7ohXI/MhCUG31qAqhJJaQ4SrJgRYUSLcY1n3mfP1GNR1diwqU0e/xfsEoGXVN0ovk1cWemTPxjFj+6FV5pX48TGRnA= Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 21:32:57 -0000 I reviewed draft-ietf-lisp-ddt-08, and my memory is that the only significant technical question was regarding the "D" bit in Map-Request messages. Thinking back on it, I believe that the difficulty I was having was with the explanation of the D bit, not its functionality. In particular, a DDT server can share a node and a listening port with a Map-Server. Both of these servers process Map-Request messages, albeit with different semantics. Hence the D bit in Map-Request messages is needed to differentiate which server is to process a given Map-Request message. My suggestion is that the document define the D bit in this way. Once that is done, it's obvious for a particular client sending a particular message whether the D bit should be set. Compare with the current description, which speaks of the D bit as if it is a classification of the sender of the Map-Request, which leads to conceptual problems because it requires the document to define the classification and ensure that all possible clients are properly classified. (Ideally, I would advocate that a DDT Map-Request should have a different type code than a Map-Server Map-Request. But I'm sure that it is too late to put that fix into existing deployments.) Dale From nobody Tue Jan 17 15:30:48 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F42001295E9 for ; Tue, 17 Jan 2017 15:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EelE5r9aCY-8 for ; Tue, 17 Jan 2017 15:30:45 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 C24A4129516 for ; Tue, 17 Jan 2017 15:30:45 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id 194so9094011pgd.0 for ; Tue, 17 Jan 2017 15:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IJB8gQ1LHMFLEffCrmS9ofWbEHXLl5mmHZNlF5f7m+s=; b=NuSbxFzUp3elK7sAR/HP5q76KfkgyIAoAvtCKHyBTiN6I0MlHkNSnRuXX8AM5ONx/l zA0kWd/5rzAJDJFwR/J0A+tFN8WJKG8Y1FZ95oX3cmVS46k+w5sglw6wE7LdWqyvrOc6 cHh+/J8UqIg+u1q3PwuoWZpGqqvoHtjkttGiRcYR3mYFnF+dwBZV3ogVUySbsHUDI6n3 3el9xkNiEaWYy1J0xxa4zqM8OKo83b2qUP1Gf2ed4EqMnj/l6/zYaR53UcDiEgcks5/Q /t6DhQHRDv4Umjv0iNLEFLLQ2kmXekqdAapgXZ2imeOO3E/YYh6yU0ZfFrzBoSdNInzx ZhAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IJB8gQ1LHMFLEffCrmS9ofWbEHXLl5mmHZNlF5f7m+s=; b=Uu6jqOv99h3qfFQVFU0e/MF6AgAt4gjZeW76/Up5OKAgEQB3scX/xy8KNyZoyo51qj FTyf3BV6kyO849mhm8rfTt3vW2MLb22vAQxAPoouVG6bHwpEEhc5GXrtJxSQTXVspzjY v4FTyhnLUooB4XGaTJWjZnBnnbm62pq1LoXTIBLBk4HSNO3KuI2WNdgBxVSgTdv3xQ04 vAFjxhFrDfXohXeY9sEysF/B5Lwy7uH11lCnb4CeScm+IwsPAlK9FjGQZCy3flLmn4H9 n7JBUB15ZtweYjua4eSjkNb/I7Zay0zhoENfenYB4fJfDfEosUtagMaVCtSSfcVt1MS7 lZpg== X-Gm-Message-State: AIkVDXIB61ayLS0pMzTVkCZrFRgGpli4F/Cqyv9yuKzOA3gpjDikZyS4ZrwKMas/a6D43Q== X-Received: by 10.84.139.36 with SMTP id 33mr313413plq.61.1484695845274; Tue, 17 Jan 2017 15:30:45 -0800 (PST) Received: from dino-macbook.attlocal.net (adsl-76-254-33-163.dsl.pltn13.sbcglobal.net. [76.254.33.163]) by smtp.gmail.com with ESMTPSA id z77sm58274232pfk.47.2017.01.17.15.30.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 15:30:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <87inpdpe2l.fsf@hobgoblin.ariadne.com> Date: Tue, 17 Jan 2017 15:30:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <80A31E3B-78BC-44B7-9618-2D35CB63C557@gmail.com> References: <87inpdpe2l.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 23:30:47 -0000 > I reviewed draft-ietf-lisp-ddt-08, and my memory is that the only > significant technical question was regarding the "D" bit in = Map-Request > messages. Let me try to make this more clear for you Dale. Thanks for the comment. > Thinking back on it, I believe that the difficulty I was having was = with > the explanation of the D bit, not its functionality. In particular, a > DDT server can share a node and a listening port with a Map-Server. Yes, every Map-Server that is part of a child referral from a DDT-node = is also a DDT-node. But the DDT-node does not process D=3D0 Map-Requests = but does D=3D1 Map-Requests by responding with Map-Referral messages. A = Map-Server sends Map-Referrals too. And usually a D=3D0 Map-Request is = forwarded by Map-Servers to ETRs so they send Map-Replies. > Both of these servers process Map-Request messages, albeit with > different semantics. Hence the D bit in Map-Request messages is = needed > to differentiate which server is to process a given Map-Request = message. The reason I explained the above was that the D-bit tells the receiver = of a Map-Request what type of message to return regardless of the = colocation status of the servers. > My suggestion is that the document define the D bit in this way. Once > that is done, it's obvious for a particular client sending a = particular > message whether the D bit should be set. Compare with the current Well depending on what type of device you are referring to as a = =E2=80=9Cclient=E2=80=9D. Map-Resolvers are part of infrastructure and = they are typically the only devices that send D=3D1 Map-Requests. And = they are sending them because they know the Map-Request is going to a = DDT node and that they want a Map-Referral as a response. > description, which speaks of the D bit as if it is a classification of > the sender of the Map-Request, which leads to conceptual problems It is not the classification of the sender. > because it requires the document to define the classification and = ensure > that all possible clients are properly classified. >=20 > (Ideally, I would advocate that a DDT Map-Request should have a > different type code than a Map-Server Map-Request. But I'm sure that = it > is too late to put that fix into existing deployments.) They both have the exact same information, one just solicits a = Map-Referral and D=3D0 doesn=E2=80=99t. Dino From nobody Tue Jan 17 19:07:00 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8F41293E8 for ; Tue, 17 Jan 2017 19:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55k3sRwmOqzL for ; Tue, 17 Jan 2017 19:06:58 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4B1129438 for ; Tue, 17 Jan 2017 19:06:57 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-02v.sys.comcast.net with SMTP id TgaCcFBWvoFDdTgaOct13V; Wed, 18 Jan 2017 03:06:56 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-14v.sys.comcast.net with SMTP id TgaNcdnsNAV09TgaOc9o52; Wed, 18 Jan 2017 03:06:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v0I36n4I027095; Tue, 17 Jan 2017 22:06:49 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0I36nWj027092; Tue, 17 Jan 2017 22:06:49 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Dino Farinacci In-Reply-To: <80A31E3B-78BC-44B7-9618-2D35CB63C557@gmail.com> (farinacci@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 17 Jan 2017 22:06:49 -0500 Message-ID: <878tq9oyly.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHiSDUvMxIZxIbvei3ihHFEm1dIGZJeO947CqLa8Rc11Es7vruA26EqwOVmkfxzVQcmWXXxyQPmpjjy8dNWxkBuciPPD+8tWypqg+IImc7EgBUEprsz9 9m1MBzhhOA3Vao6HIAR8WgBfrak1c2mecVILOADr4Z4mVVKoDWn4mSjJQnM3bFgPQkEYykdzS41rx5MIOtPNbNGj7qhE86KpBns= Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 03:06:59 -0000 Dino Farinacci writes: >> Both of these servers process Map-Request messages, albeit with >> different semantics. Hence the D bit in Map-Request messages is needed >> to differentiate which server is to process a given Map-Request message. > > The reason I explained the above was that the D-bit tells the receiver > of a Map-Request what type of message to return regardless of the > colocation status of the servers. OK, that's close to the distinction I was making. The defining text is probably from section 5: D: The "DDT-originated" flag. It is set by a DDT client to indicate that the receiver SHOULD return Map-Referral messages as appropriate. Use of the flag is further described in Section 7.3.1. This bit is allocated from LISP message header bits marked as Reserved in [RFC6830]. But when I read it, the phrase "the receiver SHOULD return Map-Referral messages as appropriate" wasn't at all clear. I assume now that what it means is, "should return Map-Referral messages *as described in this document*, whereas D=0 means it should be processed as described in RFC 6833". The defining characteristic isn't the type of messages to be returned but which processing to apply, as a DDT server and a Map-Server are very different things (defined in different RFCs!). Dale From nobody Wed Jan 18 00:07:55 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42DE12960D for ; Wed, 18 Jan 2017 00:07:53 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdhJ1Sd74P_3 for ; Wed, 18 Jan 2017 00:07:52 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 57CAD1294EA for ; Wed, 18 Jan 2017 00:07:52 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id e4so2558273pfg.1 for ; Wed, 18 Jan 2017 00:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4VuNYKVX90rItlookX01uRA63B9nXu01TfcocPteBZc=; b=a/1bpITUi8RfYP/4FGk7/HjwIj0GGvIF7iG57yf62/94WrZ1YDM4CnkM51KLy9fFqu Uxwu/JRmAlYOzbxtSiRHgVdA8wWYEcHmbUd06AwO+tvA+XAJVH3ks2FOlCWZn4JODKtK C4/W19ESXshsNnbQGt3I7F+vk5MU4qqZPEWa9FEMwOwy53uSq5Jfg/jIKtlvWCbqYWnF uWceb5pf8wnZupMP/C0JkdEnCbYVo+X3f/RHoiAZlJ5/5OA39nLIaQi52EaOKGa6RdOs d/FktjsUCMFn8qZ1cgJWv53Su5g6mQlajP/pgVIpSPby8JwUETmHwJQqG6VrVUEbijdd aVlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4VuNYKVX90rItlookX01uRA63B9nXu01TfcocPteBZc=; b=MjxwCL6DQLYlHuOAAcQV9b7YMzUllUDgLLRRmjToQN2gwEES8DxR96lvuhWPcLqE59 Z6qr5O6pzs/9UjVtAzbs9IcUmBlILlqmdqTpfesAWvUy8IKVgHbyjrpQnyO6N/fVwjov g8niSIYvQNYRXkDqDYa9/oLEPp2atP5NJps5M5zKRoIzYfpej0aowQs5hRt10B6BIUU/ 1lRiTB4UetGxySGPXQuTi46VT0n0LeK09WtGAz26POXs9M1Ng0LkmA6PbuMTTf7i5l+j 1iYcIatrE/2pvbnIE73+/9IXpB6qWA5OLLB+/TmtIbFzcTOclto5Hlqi6tI9oQgTwr1a AnYA== X-Gm-Message-State: AIkVDXLIFSib7U9NxqKzW1gMUCXPrGKMNjvCTFJYNPUhwmifLaKsof4gSv4/DQj/IQ7YTg== X-Received: by 10.98.160.140 with SMTP id p12mr2267865pfl.97.1484726871914; Wed, 18 Jan 2017 00:07:51 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:682e:3edf:c8bf:e018? ([2603:3024:151c:55f0:682e:3edf:c8bf:e018]) by smtp.gmail.com with ESMTPSA id b10sm9827132pga.21.2017.01.18.00.07.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 00:07:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14C92) In-Reply-To: <878tq9oyly.fsf@hobgoblin.ariadne.com> Date: Wed, 18 Jan 2017 00:07:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <554FB940-686C-4894-9213-EB5F283CA674@gmail.com> References: <878tq9oyly.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 08:07:53 -0000 Right. Agree with your interpretation. I hope authors can make this clear ba= sed on your suggestions.=20 Thanks, Dino > On Jan 17, 2017, at 7:06 PM, Dale R. Worley wrote: >=20 > Dino Farinacci writes: >>> Both of these servers process Map-Request messages, albeit with >>> different semantics. Hence the D bit in Map-Request messages is needed >>> to differentiate which server is to process a given Map-Request message.= >>=20 >> The reason I explained the above was that the D-bit tells the receiver >> of a Map-Request what type of message to return regardless of the >> colocation status of the servers. >=20 > OK, that's close to the distinction I was making. The defining text is > probably from section 5: >=20 > D: The "DDT-originated" flag. It is set by a DDT client to indicate > that the receiver SHOULD return Map-Referral messages as > appropriate. Use of the flag is further described in > Section 7.3.1. This bit is allocated from LISP message header > bits marked as Reserved in [RFC6830]. >=20 > But when I read it, the phrase "the receiver SHOULD return Map-Referral > messages as appropriate" wasn't at all clear. I assume now that what it > means is, "should return Map-Referral messages *as described in this > document*, whereas D=3D0 means it should be processed as described in RFC > 6833". The defining characteristic isn't the type of messages to be > returned but which processing to apply, as a DDT server and a Map-Server > are very different things (defined in different RFCs!). >=20 > Dale From nobody Wed Jan 18 14:04:17 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E851294A3; Wed, 18 Jan 2017 14:04:16 -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: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148477705629.1935.15191519841850024270.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 14:04:16 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ddt-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 22:04:16 -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 of the IETF. Title : LISP Delegated Database Tree Authors : Vince Fuller Darrel Lewis Vina Ermagan Amit Jain Anton Smirnov Filename : draft-ietf-lisp-ddt-09.txt Pages : 40 Date : 2017-01-18 Abstract: This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-ddt-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-ddt-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 18 14:34:35 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE49129485; Wed, 18 Jan 2017 14:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf_pvG5jPKu7; Wed, 18 Jan 2017 14:34:33 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7451294B2; Wed, 18 Jan 2017 14:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1577; q=dns/txt; s=iport; t=1484778872; x=1485988472; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EISMu4cq4yLmv/HlYTSn+p82Zo38DxtMAH9cwtXoDpM=; b=SSFkIW18GsvSKi6+TXghWm3+INjg6EeG83jZefhrm3QpW4g7Xz+eKZdh HTUxRBtdrQmc6XVTgMx/LRKhBRrazuaZXqMztH9IA0KIc/W1gRJPv/f4t 81oTUU+6+ooRQMtmrwK/d8Wl+gB4IS7gKh6wk40jD06PRGVkCouW0lOd6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAQCC7H9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAX8qX4NRighykHEfkx2CD4ILKoV4AoJDGAECAQEBAQE?= =?us-ascii?q?BAWMohGoBBSMVQRALGAICJgICVwYBDAgBAYh/DrAXgiWKPwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGQWBC4VAggUIgmGEGxEBgyKCXgWIfpJDhl+LA4F3hQ6DKoY+jly?= =?us-ascii?q?EEx84cSQSCBUVhSWBST01AYZFDRcHghABAQE?= X-IronPort-AV: E=Sophos;i="5.33,250,1477958400"; d="scan'208";a="649939660" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 22:34:30 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0IMYTCI004779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Jan 2017 22:34:30 GMT To: Stephen Farrell , The IESG References: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> From: Anton Smirnov Organization: Cisco Systems Message-ID: Date: Wed, 18 Jan 2017 23:34:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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 Jan 2017 22:34:34 -0000 Hello Stephen, authors of the draft have just published -09 revision. In the new text we addressed comments you raised, in particular we deprecated RSA-SHA1 and made RSA-SHA256 as mandatory implementation algorithm. --- Anton On Thursday 27 October 2016 14:44, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-lisp-ddt-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > 6.4.1: RSA-SHA1 is not the right choice today, shouldn't > this be RSA-SHA256? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 6.4.1: Can you clarify what bits are signed? I'm not > quite sure from the description given - you can have > more than one signature but you say the the "entire > record" is covered. > > - Section 8: Where's signature validation in the > pseudo-code? > > From nobody Wed Jan 18 17:33:38 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46772129453 for ; Wed, 18 Jan 2017 17:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcwcXUu5drOS for ; Wed, 18 Jan 2017 17:33:35 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 0C1441204D9 for ; Wed, 18 Jan 2017 17:33:35 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id t6so9098125pgt.3 for ; Wed, 18 Jan 2017 17:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:message-id:date:to:content-transfer-encoding :mime-version; bh=PBfnjaqblRBGBWplxByatY49A3vBXl65ZDQwHlgk7uU=; b=dGsbYKbIUjNQzavsj2JWEO2jaYduhsKhzm7lTzUXMc7B2IcyAcM4mYB0PvoDpFYFRC EH53vnwyhi0Uw9xBo04SU83dA8YhLztSv8o4/I6wRUcYCNc4lsm0fA27PDRrorUVaZlG 8dWEtMto08UZdmawDL6f7j4piG0EURvdcpoXbcDUhErM7wtIQzlSodICXQSURFTFDe21 8njRMy+8nEKo47JPt+CNu1d39IsAH+5J4qcoBsdMgtwqljXNc4J2a90XtmN4/T8uRZRO 5g6sv8+O37VJ6LKEG3xhfZtDWDeIF1NMvdtcmMxb/onEHV9oKpwwRQ7Isfw+eBvODsHq K56Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:message-id:date:to :content-transfer-encoding:mime-version; bh=PBfnjaqblRBGBWplxByatY49A3vBXl65ZDQwHlgk7uU=; b=REnT4UMsCA9mv4hci8FwOQ5h1OWybGhL1lNHu/FTFSS94nnF7tCYwIK8vZtoxkm0f4 Hp93Q4DQsm0EP/28zeGPfn7g6+jJBcl0Zh+yIjoEtDBtHYGw4C+eUjD5ft+bN+yBJEAG 5f5BMt6Gk0ZBGgRBzJ06lPyTg+oa8msRVsbHG1I5dDxvz/nj9sPuumceAQn78RVC4fmr sgJbWKELm5RZ2m0LLvswwgDw9GDmWDsHvEAxvZG7ANoHncondWP8fGWaU+qmaEdtd0I2 1BBEJW+2ujirFvxtzb7Ts7wmZ1i8uAXfMJmsGkGdpErDEt7koQefe1v0ArV4cqGuHfIt vwAg== X-Gm-Message-State: AIkVDXLTsyTEIIwzmB33xkfCszhNiNpBupX4H3PFrYfvNBdRvZMJljRXBDIpzEEfI2OT0Q== X-Received: by 10.98.95.70 with SMTP id t67mr4387758pfb.37.1484789614362; Wed, 18 Jan 2017 17:33:34 -0800 (PST) Received: from [10.152.49.62] ([166.170.43.130]) by smtp.gmail.com with ESMTPSA id q2sm3609492pga.8.2017.01.18.17.33.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 17:33:33 -0800 (PST) From: Bill Chastain Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (14B100) Message-Id: <1F7A39E0-3A71-43CC-932E-9889728BAFAF@gmail.com> Date: Wed, 18 Jan 2017 17:33:25 -0800 To: LISP mailing list list Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: [lisp] Proposed Use Case (draft-farinacci-lisp-te) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jan 2017 01:33:36 -0000 All, I wish to propose a use case pertaining to: "draft-farinacci-lisp-te". Spec= ifically, there is a need to accurately synchronize endpoint addresses with c= ontinuous audio sources supplied by NIST (as time & frequency standards-"WWV= ") to within 1 second. I understand this functionality may by provisioned u= sing specific routes and RLOC-probing mechanisms (ELP delay minimization). T= hank you. Sincerely, Bill Chastain, President Metropolitan Area Networks, Inc. 774 Mays Blvd., #10-465 Incline Village, NV 89451 Sent from my iPhone= From nobody Fri Jan 20 03:48:59 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14013129B39; Fri, 20 Jan 2017 03:48:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148491293407.13355.16380856116760932257.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2017 03:48:54 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-ddt-09: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 11:48:54 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-lisp-ddt-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling the sig alg issue. From nobody Mon Jan 30 13:46:15 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD421295BA; Mon, 30 Jan 2017 13:46:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 13:46:09 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-type-iana@ietf.org, lisp@ietf.org Subject: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 21:46:09 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lisp-type-iana-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of points I think we should DISCUSS before moving this document forward: the intended status and the definition of the registry. (1) Intended Status: The Datatracker indicates that the Intended RFC status for this document is Proposed Standard (as does the Shepherd WriteUp and the IETF LC), but the header on the document says Experimental. I note that the document header was changed after a discussion on the WG list resulting from the RTG Directorate review [1], but that happened after the WGLC. Which is the right status? (2) LISP Packet Types Registry Definition: It seems very odd to me that the LISP Packet Types Registry uses Standard Action as the registration policy given that the LISP work is currently Experimental -- and that the other references in it would in fact be from an Experimental RFC (rfc6380). I know there's work on rfc6830bis (in the Standards Track), but I think it would be better to have this registry defined in the base specification (rfc6833bis, in this case)...or to wait for the publication of that document to progress this one. I think there's nothing procedurally wrong with having an Experimental RFC define a Standard Action Registry and populate part of it with references to Experimental RFC. However, the solution just doesn't seem clean to me -- so I would like to hear the justification for the rush (and not waiting for rfc6380bis/rfc6388bis). I have no issue with a document making use of the Code Point to describe the new LISP Shared Extension Message Type (without creating the Registry). But given that the base LISP specification is still Experimental, then this document should be too. There shouldn't be an issue with changing the Status of this document (in-place) once rfc6380bis/rfc6388bis progress. There's also the issue that RFC6830 (and rfc6833bis) contain the following text: "This section will be the authoritative source for allocating LISP Type values..." Which means that (if the registry is to be defined here), this document should at least Update RFC6830... In summary, I think that the correct Status for this document is Experimental. I also think that it would be better to wait for rfc6833bis to define the Registry. [1] https://mailarchive.ietf.org/arch/msg/lisp/m1EicCexdX1GI183pba-mcHJM7g/?qid=ada479dce3c434bfaf948b0ee8240996 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- a. The Introduction justifies the extension as being used for experiments: "Because of the limited type space [RFC6830] and the need to conduct experiments to assess new LISP extensions, this document specifies a shared LISP extension message type". It seems clear later in the text that the intent of the new message type is not just for experimentation, but that in fact the intent is for new functionality to be deployed using it. Is that correct? If it is, then please make it clear -- if not, then I would like to see how the authors propose a transition to happen between the experimental space and the production one. b. The IANA Considerations Section says that "The value 15 is reserved for Experimental Use [RFC5226]." But it is being assigned to the new LISP Shared Extension Message. From nobody Mon Jan 30 13:52:38 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069C1129BE7; Mon, 30 Jan 2017 13:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCiTA2lm6e6A; Mon, 30 Jan 2017 13:52:35 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DA4129BE4; Mon, 30 Jan 2017 13:52:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 365075E00BE; Mon, 30 Jan 2017 13:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1485813152; bh=Y1ikhLLeBdyOh+ig1ozh4OLBjmsNGuImf7tR4ajJxDU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eSXlQB4hJZlvYEgkhEzjfUIUe5TuGArzdR4b+yNtpRCQhCsGMn66X5btXGvhFERWV FwPld4sifdiEUc7SNiEdGnRgXtdqQBoKRTEquchZhADjmo/v9nD7qsmeA65TstSdlV 3EFApZwBsOn16ugP+kNn0xK/MQdteWwpWoomxshg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 599775E00C9; Mon, 30 Jan 2017 13:52:31 -0800 (PST) To: Alvaro Retana , The IESG References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Mon, 30 Jan 2017 16:52:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-type-iana@ietf.org, lisp@ietf.org Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 30 Jan 2017 21:52:37 -0000 With regard to status, I think we can work with you. But we really want to establish the registry now. We already have proposals for code points beyond the experimental RFCs, and requests for room to experiment without writing an RFC. As far as I can tell, the Working Group intent is that the registry allow reservation by experimental and informational RFCs, not just standards track RFCs. We can fix that. With regard to the revision to the base documents, to get them on the standards track, one of the important fixes is to stop claiming that the RFC defines all the values, and just update the registry entries where appropriate to reference the new RFC (once we have it.) The rush is simply that it is already getting hard to keep track. We should have established a registry in the first place. So we are doing so now. On 1/30/17 4:46 PM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-lisp-type-iana-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have a couple of points I think we should DISCUSS before moving this > document forward: the intended status and the definition of the > registry. > > (1) Intended Status: The Datatracker indicates that the Intended RFC > status for this document is Proposed Standard (as does the Shepherd > WriteUp and the IETF LC), but the header on the document says > Experimental. I note that the document header was changed after a > discussion on the WG list resulting from the RTG Directorate review [1], > but that happened after the WGLC. Which is the right status? > > (2) LISP Packet Types Registry Definition: It seems very odd to me that > the LISP Packet Types Registry uses Standard Action as the registration > policy given that the LISP work is currently Experimental -- and that the > other references in it would in fact be from an Experimental RFC > (rfc6380). I know there's work on rfc6830bis (in the Standards Track), > but I think it would be better to have this registry defined in the base > specification (rfc6833bis, in this case)...or to wait for the publication > of that document to progress this one. > > > I think there's nothing procedurally wrong with having an Experimental > RFC define a Standard Action Registry and populate part of it with > references to Experimental RFC. However, the solution just doesn't seem > clean to me -- so I would like to hear the justification for the rush > (and not waiting for rfc6380bis/rfc6388bis). > > I have no issue with a document making use of the Code Point to describe > the new LISP Shared Extension Message Type (without creating the > Registry). But given that the base LISP specification is still > Experimental, then this document should be too. There shouldn't be an > issue with changing the Status of this document (in-place) once > rfc6380bis/rfc6388bis progress. > > > There's also the issue that RFC6830 (and rfc6833bis) contain the > following text: "This section will be the authoritative source for > allocating LISP Type values..." Which means that (if the registry is to > be defined here), this document should at least Update RFC6830... > > In summary, I think that the correct Status for this document is > Experimental. I also think that it would be better to wait for > rfc6833bis to define the Registry. > > > [1] > https://mailarchive.ietf.org/arch/msg/lisp/m1EicCexdX1GI183pba-mcHJM7g/?qid=ada479dce3c434bfaf948b0ee8240996 > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > a. The Introduction justifies the extension as being used for > experiments: "Because of the limited type space [RFC6830] and the need to > conduct experiments to assess new LISP extensions, this document > specifies a shared LISP extension message type". It seems clear later in > the text that the intent of the new message type is not just for > experimentation, but that in fact the intent is for new functionality to > be deployed using it. Is that correct? If it is, then please make it > clear -- if not, then I would like to see how the authors propose a > transition to happen between the experimental space and the production > one. > > b. The IANA Considerations Section says that "The value 15 is reserved > for Experimental Use [RFC5226]." But it is being assigned to the new > LISP Shared Extension Message. > > > From nobody Mon Jan 30 14:11:07 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407AE129BFB; Mon, 30 Jan 2017 14:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0eMgOIYswhC; Mon, 30 Jan 2017 14:10:58 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76F8129642; Mon, 30 Jan 2017 14:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30340; q=dns/txt; s=iport; t=1485814252; x=1487023852; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GVhZgkTZTbX+VAzJnEqaomTZq5ucMmjtA2nBjLpXzIQ=; b=YcAfJ4FTtfvZMG88Vpai4bpTXdgYiouJclMeXWlsfTaQ5NPSOQ/kKIFc UuXoqjCEyuzCko2MVUsBHXmDqJki2GYhYrxFhVIuW7oIoMWc8UjZfxphU PfBsukNJqDIiLiNDxYQoDaPJat8T4OG525joo3AyvGURSzf0Jg3HgsRE+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAQCcuY9Y/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnBkYYEJB4NOigmlJ4IPggwuhXQCGoIMPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?qBiNWEAIBCDgHAwICAjAUEQIEAQ0FG4lGDqsygiUrim8BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZLggWBYYEJgwyBDwoHAYMiLoIxBYkCjD6GFAGGZosUgXmFFYl?= =?us-ascii?q?piCaKWAEfOHZVFTsQAYQrHBmBSHUBBIYFDxeBCoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,312,1477958400"; d="scan'208,217";a="202347445" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2017 22:10:24 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0UMAN83028746 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Jan 2017 22:10:24 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 16:10:23 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 16:10:23 -0600 From: "Alvaro Retana (aretana)" To: "Joel M. Halpern" , The IESG Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) Thread-Index: AQHSe0JHF3IUDVpxIkSQ7eReJZcjSqFR9F8A//+xLAA= Date: Mon, 30 Jan 2017 22:10:23 +0000 Message-ID: References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_F41F55E71A014CE8A627007848C39618ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-type-iana@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 30 Jan 2017 22:11:00 -0000 --_000_F41F55E71A014CE8A627007848C39618ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lbDoNCg0KSGkhDQoNClRvIGNsYXJpZnksIHRoZXJlIGFyZSB0d28gUmVnaXN0cmllcyBiZWlu ZyBkZWZpbmVkOiBMSVNQIFBhY2tldCBUeXBlcyBhbmQgU3ViLVR5cGVzLg0KDQpJIGRvbuKAmXQg aGF2ZSBhbiBpc3N1ZSB3aXRoIHRoZSBTdWItVHlwZXMgcmVnaXN0cnksIHdoaWNoIGlzIHRoZSBv bmUgdGhhdCBhbGxvd3MgeW91IHRvIGdldCBuZXcgZnVuY3Rpb25hbGl0eSB1cCBhbmQgZ29pbmcs IHdpdGggb3Igd2l0aG91dCBhbiBSRkMg4oCTIGl0IGN1cnJlbnRseSBoYXMgYSBGQ0ZTIHJlZ2lz dHJhdGlvbiBwb2xpY3kuICBNYXliZSBhIGxpdHRsZSB0b28gb3BlbiwgYnV0IGlmIHRoaXMgaXMg d2hhdCB0aGUgV0cgd2FudHMsIHRoZW4gSeKAmW0gb2sgd2l0aCBpdC4NCg0KVGhlIExJU1AgUGFj a2V0IFR5cGVzIFJlZ2lzdHJ5IGlzIHRoZSBvbmUgSSBoYXZlIGFuIGlzc3VlIHdpdGggYmVpbmcg ZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgSXQgc2VlbXMgbGlrZSB0aGUgbWFpbiBtb3RpdmF0 aW9uIG9mIHRoZSBkb2N1bWVudCBpcyB0aGUgbmV3IExJU1AgU2hhcmVkIEV4dGVuc2lvbiBNZXNz YWdlIFR5cGUsIGFuZCB0aGF0IGNyZWF0aW5nIHRoZSByZWdpc3RyeSBvbmx5IHNlcnZlcyB0byBh c3NpZ24gdHlwZSAxNSB0byBpdC4gIEJ1dCBhbnkgb3RoZXIgZXh0ZW5zaW9ucyB3b3VsZCBtYWtl IHVzZSBvZiB0aGUgU3ViLVR5cGVzIHJlZ2lzdHJ5LCBhbmQgbm90IHRoaXMgb25lLg0KDQpNYXli ZSBJ4oCZbSBtaXNzaW5nIHRoZSBzdWJ0bGV0aWVzIG9mIHdoaWNoIHNwYWNlIGlzIHVzZWQgZm9y IHdoYXQuLi4NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg0KT24gMS8zMC8xNywgNDo1MiBQTSwg IkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+PiB3cm90ZToNCg0KV2l0aCByZWdhcmQgdG8gc3RhdHVzLCBJIHRoaW5rIHdlIGNh biB3b3JrIHdpdGggeW91Lg0KQnV0IHdlIHJlYWxseSB3YW50IHRvIGVzdGFibGlzaCB0aGUgcmVn aXN0cnkgbm93Lg0KV2UgYWxyZWFkeSBoYXZlIHByb3Bvc2FscyBmb3IgY29kZSBwb2ludHMgYmV5 b25kIHRoZSBleHBlcmltZW50YWwgUkZDcywNCmFuZCByZXF1ZXN0cyBmb3Igcm9vbSB0byBleHBl cmltZW50IHdpdGhvdXQgd3JpdGluZyBhbiBSRkMuDQoNCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0 aGUgV29ya2luZyBHcm91cCBpbnRlbnQgaXMgdGhhdCB0aGUgcmVnaXN0cnkNCmFsbG93IHJlc2Vy dmF0aW9uIGJ5IGV4cGVyaW1lbnRhbCBhbmQgaW5mb3JtYXRpb25hbCBSRkNzLCBub3QganVzdA0K c3RhbmRhcmRzIHRyYWNrIFJGQ3MuICBXZSBjYW4gZml4IHRoYXQuDQoNCldpdGggcmVnYXJkIHRv IHRoZSByZXZpc2lvbiB0byB0aGUgYmFzZSBkb2N1bWVudHMsIHRvIGdldCB0aGVtIG9uIHRoZQ0K c3RhbmRhcmRzIHRyYWNrLCBvbmUgb2YgdGhlIGltcG9ydGFudCBmaXhlcyBpcyB0byBzdG9wIGNs YWltaW5nIHRoYXQgdGhlDQpSRkMgZGVmaW5lcyBhbGwgdGhlIHZhbHVlcywgYW5kIGp1c3QgdXBk YXRlIHRoZSByZWdpc3RyeSBlbnRyaWVzIHdoZXJlDQphcHByb3ByaWF0ZSB0byByZWZlcmVuY2Ug dGhlIG5ldyBSRkMgKG9uY2Ugd2UgaGF2ZSBpdC4pDQoNClRoZSBydXNoIGlzIHNpbXBseSB0aGF0 IGl0IGlzIGFscmVhZHkgZ2V0dGluZyBoYXJkIHRvIGtlZXAgdHJhY2suICBXZQ0Kc2hvdWxkIGhh dmUgZXN0YWJsaXNoZWQgYSByZWdpc3RyeSBpbiB0aGUgZmlyc3QgcGxhY2UuICBTbyB3ZSBhcmUg ZG9pbmcNCnNvIG5vdy4NCg0KDQpPbiAxLzMwLzE3IDQ6NDYgUE0sIEFsdmFybyBSZXRhbmEgd3Jv dGU6DQpBbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wNDogRGlzY3Vzcw0KDQpXaGVuIHJl c3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0 byBhbGwNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikN Cg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0 aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEvDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJIGhhdmUgYSBjb3VwbGUg b2YgcG9pbnRzIEkgdGhpbmsgd2Ugc2hvdWxkIERJU0NVU1MgYmVmb3JlIG1vdmluZyB0aGlzDQpk b2N1bWVudCBmb3J3YXJkOiB0aGUgaW50ZW5kZWQgc3RhdHVzIGFuZCB0aGUgZGVmaW5pdGlvbiBv ZiB0aGUNCnJlZ2lzdHJ5Lg0KDQooMSkgSW50ZW5kZWQgU3RhdHVzOiBUaGUgRGF0YXRyYWNrZXIg aW5kaWNhdGVzIHRoYXQgdGhlIEludGVuZGVkIFJGQw0Kc3RhdHVzIGZvciB0aGlzIGRvY3VtZW50 IGlzIFByb3Bvc2VkIFN0YW5kYXJkIChhcyBkb2VzIHRoZSBTaGVwaGVyZA0KV3JpdGVVcCBhbmQg dGhlIElFVEYgTEMpLCBidXQgdGhlIGhlYWRlciBvbiB0aGUgZG9jdW1lbnQgc2F5cw0KRXhwZXJp bWVudGFsLiAgSSBub3RlIHRoYXQgdGhlIGRvY3VtZW50IGhlYWRlciB3YXMgY2hhbmdlZCBhZnRl ciBhDQpkaXNjdXNzaW9uIG9uIHRoZSBXRyBsaXN0IHJlc3VsdGluZyBmcm9tIHRoZSBSVEcgRGly ZWN0b3JhdGUgcmV2aWV3IFsxXSwNCmJ1dCB0aGF0IGhhcHBlbmVkIGFmdGVyIHRoZSBXR0xDLiAg V2hpY2ggaXMgdGhlIHJpZ2h0IHN0YXR1cz8NCg0KKDIpIExJU1AgUGFja2V0IFR5cGVzIFJlZ2lz dHJ5IERlZmluaXRpb246IEl0IHNlZW1zIHZlcnkgb2RkIHRvIG1lIHRoYXQNCnRoZSBMSVNQIFBh Y2tldCBUeXBlcyBSZWdpc3RyeSB1c2VzIFN0YW5kYXJkIEFjdGlvbiBhcyB0aGUgcmVnaXN0cmF0 aW9uDQpwb2xpY3kgZ2l2ZW4gdGhhdCB0aGUgTElTUCB3b3JrIGlzIGN1cnJlbnRseSBFeHBlcmlt ZW50YWwgLS0gYW5kIHRoYXQgdGhlDQpvdGhlciByZWZlcmVuY2VzIGluIGl0IHdvdWxkIGluIGZh Y3QgYmUgZnJvbSBhbiBFeHBlcmltZW50YWwgUkZDDQoocmZjNjM4MCkuICBJIGtub3cgdGhlcmUn cyB3b3JrIG9uIHJmYzY4MzBiaXMgKGluIHRoZSBTdGFuZGFyZHMgVHJhY2spLA0KYnV0IEkgdGhp bmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgdGhpcyByZWdpc3RyeSBkZWZpbmVkIGluIHRo ZSBiYXNlDQpzcGVjaWZpY2F0aW9uIChyZmM2ODMzYmlzLCBpbiB0aGlzIGNhc2UpLi4ub3IgdG8g d2FpdCBmb3IgdGhlIHB1YmxpY2F0aW9uDQpvZiB0aGF0IGRvY3VtZW50IHRvIHByb2dyZXNzIHRo aXMgb25lLg0KDQoNCkkgdGhpbmsgdGhlcmUncyBub3RoaW5nIHByb2NlZHVyYWxseSB3cm9uZyB3 aXRoIGhhdmluZyBhbiBFeHBlcmltZW50YWwNClJGQyBkZWZpbmUgYSBTdGFuZGFyZCBBY3Rpb24g UmVnaXN0cnkgYW5kIHBvcHVsYXRlIHBhcnQgb2YgaXQgd2l0aA0KcmVmZXJlbmNlcyB0byBFeHBl cmltZW50YWwgUkZDLiAgSG93ZXZlciwgdGhlIHNvbHV0aW9uIGp1c3QgZG9lc24ndCBzZWVtDQpj bGVhbiB0byBtZSAtLSBzbyBJIHdvdWxkIGxpa2UgdG8gaGVhciB0aGUganVzdGlmaWNhdGlvbiBm b3IgdGhlIHJ1c2gNCihhbmQgbm90IHdhaXRpbmcgZm9yIHJmYzYzODBiaXMvcmZjNjM4OGJpcyku DQoNCkkgaGF2ZSBubyBpc3N1ZSB3aXRoIGEgZG9jdW1lbnQgbWFraW5nIHVzZSBvZiB0aGUgQ29k ZSBQb2ludCB0byBkZXNjcmliZQ0KdGhlIG5ldyBMSVNQIFNoYXJlZCBFeHRlbnNpb24gTWVzc2Fn ZSBUeXBlICh3aXRob3V0IGNyZWF0aW5nIHRoZQ0KUmVnaXN0cnkpLiAgQnV0IGdpdmVuIHRoYXQg dGhlIGJhc2UgTElTUCBzcGVjaWZpY2F0aW9uIGlzIHN0aWxsDQpFeHBlcmltZW50YWwsIHRoZW4g dGhpcyBkb2N1bWVudCBzaG91bGQgYmUgdG9vLiAgVGhlcmUgc2hvdWxkbid0IGJlIGFuDQppc3N1 ZSB3aXRoIGNoYW5naW5nIHRoZSBTdGF0dXMgb2YgdGhpcyBkb2N1bWVudCAoaW4tcGxhY2UpIG9u Y2UNCnJmYzYzODBiaXMvcmZjNjM4OGJpcyBwcm9ncmVzcy4NCg0KDQpUaGVyZSdzIGFsc28gdGhl IGlzc3VlIHRoYXQgUkZDNjgzMCAoYW5kIHJmYzY4MzNiaXMpIGNvbnRhaW4gdGhlDQpmb2xsb3dp bmcgdGV4dDogIlRoaXMgc2VjdGlvbiB3aWxsIGJlIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSBm b3INCmFsbG9jYXRpbmcgTElTUCBUeXBlIHZhbHVlcy4uLiIgICBXaGljaCBtZWFucyB0aGF0IChp ZiB0aGUgcmVnaXN0cnkgaXMgdG8NCmJlIGRlZmluZWQgaGVyZSksIHRoaXMgZG9jdW1lbnQgc2hv dWxkIGF0IGxlYXN0IFVwZGF0ZSBSRkM2ODMwLi4uDQoNCkluIHN1bW1hcnksIEkgdGhpbmsgdGhh dCB0aGUgY29ycmVjdCBTdGF0dXMgZm9yIHRoaXMgZG9jdW1lbnQgaXMNCkV4cGVyaW1lbnRhbC4g IEkgYWxzbyB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGJldHRlciB0byB3YWl0IGZvcg0KcmZjNjgz M2JpcyB0byBkZWZpbmUgdGhlIFJlZ2lzdHJ5Lg0KDQoNClsxXQ0KaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9saXNwL20xRWljQ2V4ZFgxR0kxODNwYmEtbWNISk03Zy8/cWlk PWFkYTQ3OWRjZTNjNDM0YmZhZjk0OGIwZWU4MjQwOTk2DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09N TUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KYS4gVGhlIEludHJvZHVjdGlvbiBqdXN0aWZpZXMgdGhl IGV4dGVuc2lvbiBhcyBiZWluZyB1c2VkIGZvcg0KZXhwZXJpbWVudHM6ICJCZWNhdXNlIG9mIHRo ZSBsaW1pdGVkIHR5cGUgc3BhY2UgW1JGQzY4MzBdIGFuZCB0aGUgbmVlZCB0bw0KY29uZHVjdCBl eHBlcmltZW50cyB0byBhc3Nlc3MgbmV3IExJU1AgZXh0ZW5zaW9ucywgdGhpcyBkb2N1bWVudA0K c3BlY2lmaWVzIGEgc2hhcmVkIExJU1AgZXh0ZW5zaW9uIG1lc3NhZ2UgdHlwZSIuICBJdCBzZWVt cyBjbGVhciBsYXRlciBpbg0KdGhlIHRleHQgdGhhdCB0aGUgaW50ZW50IG9mIHRoZSBuZXcgbWVz c2FnZSB0eXBlIGlzIG5vdCBqdXN0IGZvcg0KZXhwZXJpbWVudGF0aW9uLCBidXQgdGhhdCBpbiBm YWN0IHRoZSBpbnRlbnQgaXMgZm9yIG5ldyBmdW5jdGlvbmFsaXR5IHRvDQpiZSBkZXBsb3llZCB1 c2luZyBpdC4gIElzIHRoYXQgY29ycmVjdD8gIElmIGl0IGlzLCB0aGVuIHBsZWFzZSBtYWtlIGl0 DQpjbGVhciAtLSBpZiBub3QsIHRoZW4gSSB3b3VsZCBsaWtlIHRvIHNlZSBob3cgdGhlIGF1dGhv cnMgcHJvcG9zZSBhDQp0cmFuc2l0aW9uIHRvIGhhcHBlbiBiZXR3ZWVuIHRoZSBleHBlcmltZW50 YWwgc3BhY2UgYW5kIHRoZSBwcm9kdWN0aW9uDQpvbmUuDQoNCmIuIFRoZSBJQU5BIENvbnNpZGVy YXRpb25zIFNlY3Rpb24gc2F5cyB0aGF0ICJUaGUgdmFsdWUgMTUgaXMgcmVzZXJ2ZWQNCmZvciBF eHBlcmltZW50YWwgVXNlIFtSRkM1MjI2XS4iICBCdXQgaXQgaXMgYmVpbmcgYXNzaWduZWQgdG8g dGhlIG5ldw0KTElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UuDQoNCg0KDQoNCg== --_000_F41F55E71A014CE8A627007848C39618ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Kb2Vs OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PlRvIGNsYXJpZnksIHRoZXJlIGFyZSB0d28gUmVnaXN0cmllcyBiZWluZyBkZWZpbmVkOiBMSVNQ IFBhY2tldCBUeXBlcyBhbmQgU3ViLVR5cGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkg ZG9u4oCZdCBoYXZlIGFuIGlzc3VlIHdpdGggdGhlIFN1Yi1UeXBlcyByZWdpc3RyeSwgd2hpY2gg aXMgdGhlIG9uZSB0aGF0IGFsbG93cyB5b3UgdG8gZ2V0IG5ldyBmdW5jdGlvbmFsaXR5IHVwIGFu ZCBnb2luZywgd2l0aCBvciB3aXRob3V0IGFuIFJGQyDigJMgaXQgY3VycmVudGx5IGhhcyBhIEZD RlMgcmVnaXN0cmF0aW9uDQogcG9saWN5LiZuYnNwOyBNYXliZSBhIGxpdHRsZSB0b28gb3Blbiwg YnV0IGlmIHRoaXMgaXMgd2hhdCB0aGUgV0cgd2FudHMsIHRoZW4gSeKAmW0gb2sgd2l0aCBpdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGUgTElTUCBQYWNrZXQgVHlwZXMgUmVnaXN0cnkg aXMgdGhlIG9uZSBJIGhhdmUgYW4gaXNzdWUgd2l0aCBiZWluZyBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQuJm5ic3A7IEl0IHNlZW1zIGxpa2UgdGhlIG1haW4gbW90aXZhdGlvbiBvZiB0aGUgZG9j dW1lbnQgaXMgdGhlIG5ldyBMSVNQIFNoYXJlZCBFeHRlbnNpb24gTWVzc2FnZQ0KIFR5cGUsIGFu ZCB0aGF0IGNyZWF0aW5nIHRoZSByZWdpc3RyeSBvbmx5IHNlcnZlcyB0byBhc3NpZ24gdHlwZSAx NSB0byBpdC4mbmJzcDsgQnV0IGFueSBvdGhlciBleHRlbnNpb25zIHdvdWxkIG1ha2UgdXNlIG9m IHRoZSBTdWItVHlwZXMgcmVnaXN0cnksIGFuZCBub3QgdGhpcyBvbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+TWF5YmUgSeKAmW0gbWlzc2luZyB0aGUgc3VidGxldGllcyBvZiB3aGljaCBz cGFjZSBpcyB1c2VkIGZvciB3aGF0Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtz ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8zMC8xNywgNDo1MiBQTSwgJnF1b3Q7Sm9l bCBNLiBIYWxwZXJuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggcmVnYXJkIHRv IHN0YXR1cywgSSB0aGluayB3ZSBjYW4gd29yayB3aXRoIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB3ZSByZWFsbHkgd2FudCB0byBl c3RhYmxpc2ggdGhlIHJlZ2lzdHJ5IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFscmVhZHkgaGF2ZSBwcm9wb3NhbHMgZm9yIGNvZGUg cG9pbnRzIGJleW9uZCB0aGUgZXhwZXJpbWVudGFsIFJGQ3MsDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCByZXF1ZXN0cyBmb3Igcm9vbSB0 byBleHBlcmltZW50IHdpdGhvdXQgd3JpdGluZyBhbiBSRkMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0 aGUgV29ya2luZyBHcm91cCBpbnRlbnQgaXMgdGhhdCB0aGUgcmVnaXN0cnkNCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxsb3cgcmVzZXJ2YXRp b24gYnkgZXhwZXJpbWVudGFsIGFuZCBpbmZvcm1hdGlvbmFsIFJGQ3MsIG5vdCBqdXN0DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0YW5kYXJk cyB0cmFjayBSRkNzLiZuYnNwOyZuYnNwO1dlIGNhbiBmaXggdGhhdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCByZWdhcmQgdG8gdGhl IHJldmlzaW9uIHRvIHRoZSBiYXNlIGRvY3VtZW50cywgdG8gZ2V0IHRoZW0gb24gdGhlDQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0YW5kYXJk cyB0cmFjaywgb25lIG9mIHRoZSBpbXBvcnRhbnQgZml4ZXMgaXMgdG8gc3RvcCBjbGFpbWluZyB0 aGF0IHRoZQ0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SRkMgZGVmaW5lcyBhbGwgdGhlIHZhbHVlcywgYW5kIGp1c3QgdXBkYXRlIHRoZSByZWdp c3RyeSBlbnRyaWVzIHdoZXJlDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmFwcHJvcHJpYXRlIHRvIHJlZmVyZW5jZSB0aGUgbmV3IFJGQyAob25j ZSB3ZSBoYXZlIGl0Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHJ1c2ggaXMgc2ltcGx5IHRoYXQgaXQgaXMgYWxyZWFkeSBnZXR0aW5n IGhhcmQgdG8ga2VlcCB0cmFjay4mbmJzcDsmbmJzcDtXZQ0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zaG91bGQgaGF2ZSBlc3RhYmxpc2hlZCBh IHJlZ2lzdHJ5IGluIHRoZSBmaXJzdCBwbGFjZS4mbmJzcDsmbmJzcDtTbyB3ZSBhcmUgZG9pbmcN CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c28g bm93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMzAvMTcg NDo0NiBQTSwgQWx2YXJvIFJldGFuYSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJp Z2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdmFybyBSZXRhbmEgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hLTA0OiBEaXNjdXNz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldo ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl cGx5IHRvIGFsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG ZWVsIGZyZWUgdG8gY3V0IHRoaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBy ZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIg YmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hLyI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS88L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ESVNDVVNTOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBjb3VwbGUgb2YgcG9pbnRzIEkgdGhpbmsgd2Ug c2hvdWxkIERJU0NVU1MgYmVmb3JlIG1vdmluZyB0aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kb2N1bWVudCBmb3J3YXJkOiB0aGUgaW50ZW5k ZWQgc3RhdHVzIGFuZCB0aGUgZGVmaW5pdGlvbiBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMSkgSW50ZW5kZWQgU3RhdHVz OiBUaGUgRGF0YXRyYWNrZXIgaW5kaWNhdGVzIHRoYXQgdGhlIEludGVuZGVkIFJGQzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3RhdHVzIGZvciB0 aGlzIGRvY3VtZW50IGlzIFByb3Bvc2VkIFN0YW5kYXJkIChhcyBkb2VzIHRoZSBTaGVwaGVyZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V3JpdGVV cCBhbmQgdGhlIElFVEYgTEMpLCBidXQgdGhlIGhlYWRlciBvbiB0aGUgZG9jdW1lbnQgc2F5czxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhwZXJp bWVudGFsLiZuYnNwOyZuYnNwO0kgbm90ZSB0aGF0IHRoZSBkb2N1bWVudCBoZWFkZXIgd2FzIGNo YW5nZWQgYWZ0ZXIgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+ZGlzY3Vzc2lvbiBvbiB0aGUgV0cgbGlzdCByZXN1bHRpbmcgZnJvbSB0aGUgUlRH IERpcmVjdG9yYXRlIHJldmlldyBbMV0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgdGhhdCBoYXBwZW5lZCBhZnRlciB0aGUgV0dMQy4mbmJz cDsmbmJzcDtXaGljaCBpcyB0aGUgcmlnaHQgc3RhdHVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMikgTElTUCBQYWNrZXQgVHlwZXMgUmVn aXN0cnkgRGVmaW5pdGlvbjogSXQgc2VlbXMgdmVyeSBvZGQgdG8gbWUgdGhhdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIExJU1AgUGFja2V0 IFR5cGVzIFJlZ2lzdHJ5IHVzZXMgU3RhbmRhcmQgQWN0aW9uIGFzIHRoZSByZWdpc3RyYXRpb248 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBvbGlj eSBnaXZlbiB0aGF0IHRoZSBMSVNQIHdvcmsgaXMgY3VycmVudGx5IEV4cGVyaW1lbnRhbCAtLSBh bmQgdGhhdCB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPm90aGVyIHJlZmVyZW5jZXMgaW4gaXQgd291bGQgaW4gZmFjdCBiZSBmcm9tIGFuIEV4 cGVyaW1lbnRhbCBSRkM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPihyZmM2MzgwKS4mbmJzcDsmbmJzcDtJIGtub3cgdGhlcmUncyB3b3JrIG9uIHJm YzY4MzBiaXMgKGluIHRoZSBTdGFuZGFyZHMgVHJhY2spLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YnV0IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0 dGVyIHRvIGhhdmUgdGhpcyByZWdpc3RyeSBkZWZpbmVkIGluIHRoZSBiYXNlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zcGVjaWZpY2F0aW9uIChy ZmM2ODMzYmlzLCBpbiB0aGlzIGNhc2UpLi4ub3IgdG8gd2FpdCBmb3IgdGhlIHB1YmxpY2F0aW9u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiB0 aGF0IGRvY3VtZW50IHRvIHByb2dyZXNzIHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlcmUncyBub3RoaW5n IHByb2NlZHVyYWxseSB3cm9uZyB3aXRoIGhhdmluZyBhbiBFeHBlcmltZW50YWw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyBkZWZpbmUgYSBT dGFuZGFyZCBBY3Rpb24gUmVnaXN0cnkgYW5kIHBvcHVsYXRlIHBhcnQgb2YgaXQgd2l0aDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVmZXJlbmNl cyB0byBFeHBlcmltZW50YWwgUkZDLiZuYnNwOyZuYnNwO0hvd2V2ZXIsIHRoZSBzb2x1dGlvbiBq dXN0IGRvZXNuJ3Qgc2VlbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Y2xlYW4gdG8gbWUgLS0gc28gSSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIGp1 c3RpZmljYXRpb24gZm9yIHRoZSBydXNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4oYW5kIG5vdCB3YWl0aW5nIGZvciByZmM2MzgwYmlzL3JmYzYz ODhiaXMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGhhdmUgbm8gaXNzdWUgd2l0aCBhIGRvY3VtZW50IG1ha2luZyB1c2Ugb2YgdGhlIENv ZGUgUG9pbnQgdG8gZGVzY3JpYmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoZSBuZXcgTElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgVHlw ZSAod2l0aG91dCBjcmVhdGluZyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2lzdHJ5KS4mbmJzcDsmbmJzcDtCdXQgZ2l2ZW4gdGhhdCB0 aGUgYmFzZSBMSVNQIHNwZWNpZmljYXRpb24gaXMgc3RpbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4cGVyaW1lbnRhbCwgdGhlbiB0aGlzIGRv Y3VtZW50IHNob3VsZCBiZSB0b28uJm5ic3A7Jm5ic3A7VGhlcmUgc2hvdWxkbid0IGJlIGFuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pc3N1ZSB3 aXRoIGNoYW5naW5nIHRoZSBTdGF0dXMgb2YgdGhpcyBkb2N1bWVudCAoaW4tcGxhY2UpIG9uY2U8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJmYzYz ODBiaXMvcmZjNjM4OGJpcyBwcm9ncmVzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSdzIGFsc28gdGhlIGlzc3VlIHRoYXQgUkZD NjgzMCAoYW5kIHJmYzY4MzNiaXMpIGNvbnRhaW4gdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb2xsb3dpbmcgdGV4dDogJnF1b3Q7VGhpcyBz ZWN0aW9uIHdpbGwgYmUgdGhlIGF1dGhvcml0YXRpdmUgc291cmNlIGZvcjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxsb2NhdGluZyBMSVNQIFR5 cGUgdmFsdWVzLi4uJnF1b3Q7Jm5ic3A7Jm5ic3A7IFdoaWNoIG1lYW5zIHRoYXQgKGlmIHRoZSBy ZWdpc3RyeSBpcyB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YmUgZGVmaW5lZCBoZXJlKSwgdGhpcyBkb2N1bWVudCBzaG91bGQgYXQgbGVhc3Qg VXBkYXRlIFJGQzY4MzAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gc3VtbWFyeSwgSSB0aGluayB0aGF0IHRoZSBjb3JyZWN0IFN0YXR1 cyBmb3IgdGhpcyBkb2N1bWVudCBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RXhwZXJpbWVudGFsLiZuYnNwOyZuYnNwO0kgYWxzbyB0aGluayB0 aGF0IGl0IHdvdWxkIGJlIGJldHRlciB0byB3YWl0IGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmZjNjgzM2JpcyB0byBkZWZpbmUgdGhlIFJl Z2lzdHJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlsxXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9saXNw L20xRWljQ2V4ZFgxR0kxODNwYmEtbWNISk03Zy8/cWlkPWFkYTQ3OWRjZTNjNDM0YmZhZjk0OGIw ZWU4MjQwOTk2Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2xpc3AvbTFF aWNDZXhkWDFHSTE4M3BiYS1tY0hKTTdnLz9xaWQ9YWRhNDc5ZGNlM2M0MzRiZmFmOTQ4YjBlZTgy NDA5OTY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q09NTUVOVDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YS4gVGhlIEludHJvZHVjdGlvbiBqdXN0 aWZpZXMgdGhlIGV4dGVuc2lvbiBhcyBiZWluZyB1c2VkIGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZXhwZXJpbWVudHM6ICZxdW90O0JlY2F1 c2Ugb2YgdGhlIGxpbWl0ZWQgdHlwZSBzcGFjZSBbUkZDNjgzMF0gYW5kIHRoZSBuZWVkIHRvPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb25kdWN0 IGV4cGVyaW1lbnRzIHRvIGFzc2VzcyBuZXcgTElTUCBleHRlbnNpb25zLCB0aGlzIGRvY3VtZW50 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zcGVj aWZpZXMgYSBzaGFyZWQgTElTUCBleHRlbnNpb24gbWVzc2FnZSB0eXBlJnF1b3Q7LiZuYnNwOyZu YnNwO0l0IHNlZW1zIGNsZWFyIGxhdGVyIGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgdGV4dCB0aGF0IHRoZSBpbnRlbnQgb2YgdGhlIG5l dyBtZXNzYWdlIHR5cGUgaXMgbm90IGp1c3QgZm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5leHBlcmltZW50YXRpb24sIGJ1dCB0aGF0IGluIGZh Y3QgdGhlIGludGVudCBpcyBmb3IgbmV3IGZ1bmN0aW9uYWxpdHkgdG88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlIGRlcGxveWVkIHVzaW5nIGl0 LiZuYnNwOyZuYnNwO0lzIHRoYXQgY29ycmVjdD8mbmJzcDsmbmJzcDtJZiBpdCBpcywgdGhlbiBw bGVhc2UgbWFrZSBpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Y2xlYXIgLS0gaWYgbm90LCB0aGVuIEkgd291bGQgbGlrZSB0byBzZWUgaG93IHRo ZSBhdXRob3JzIHByb3Bvc2UgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+dHJhbnNpdGlvbiB0byBoYXBwZW4gYmV0d2VlbiB0aGUgZXhwZXJpbWVu dGFsIHNwYWNlIGFuZCB0aGUgcHJvZHVjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iLiBUaGUgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0 aW9uIHNheXMgdGhhdCAmcXVvdDtUaGUgdmFsdWUgMTUgaXMgcmVzZXJ2ZWQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciBFeHBlcmltZW50YWwg VXNlIFtSRkM1MjI2XS4mcXVvdDsmbmJzcDsmbmJzcDtCdXQgaXQgaXMgYmVpbmcgYXNzaWduZWQg dG8gdGhlIG5ldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_F41F55E71A014CE8A627007848C39618ciscocom_-- From nobody Mon Jan 30 14:19:32 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8092E129C13; Mon, 30 Jan 2017 14:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdRXuchrU_Ho; Mon, 30 Jan 2017 14:19:23 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3970129C11; Mon, 30 Jan 2017 14:19:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C38F3240663; Mon, 30 Jan 2017 14:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1485814741; bh=E2ggjWcYA2uprrzfDmftZ2t72IL8iP7coHZ5BRrFmEc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kgXvw8AVmP1cWeOqtrxZY+nZz03EcwFdnkGbSILiaJ2JRvs8k2YxLprfXEX4H3TWT uoO3goXdY+Z0kJs1vj2AYQb2uqbvpQepFQ2F1CuYIC5BhiD2dzq24mRkbJgx2UNBc8 qIU+3Nej03Pw0DHzhaWdIj9MBMb/oD8yDO2ughfE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 E4DED24053B; Mon, 30 Jan 2017 14:19:00 -0800 (PST) To: "Alvaro Retana (aretana)" , The IESG References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <3e081563-56ca-9747-c12a-d8c6ee874521@joelhalpern.com> Date: Mon, 30 Jan 2017 17:18:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-type-iana@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 30 Jan 2017 22:19:25 -0000 Yes, 15 is the only new type at the moment. But the existence of a request for new types raises the point that there may well be others. So creating a registry seems the right thing to do. Since the registry needs to allow experimental entries (the current protocol), it seems that we are better served getting it established now. Yours, Joel On 1/30/17 5:10 PM, Alvaro Retana (aretana) wrote: > Joel: > > > > Hi! > > > > To clarify, there are two Registries being defined: LISP Packet Types > and Sub-Types. > > > > I don’t have an issue with the Sub-Types registry, which is the one that > allows you to get new functionality up and going, with or without an RFC > – it currently has a FCFS registration policy. Maybe a little too open, > but if this is what the WG wants, then I’m ok with it. > > > > The LISP Packet Types Registry is the one I have an issue with being > defined in this document. It seems like the main motivation of the > document is the new LISP Shared Extension Message Type, and that > creating the registry only serves to assign type 15 to it. But any > other extensions would make use of the Sub-Types registry, and not this one. > > > > Maybe I’m missing the subtleties of which space is used for what... > > > > Thanks! > > > > Alvaro. > > > > > > On 1/30/17, 4:52 PM, "Joel M. Halpern" > wrote: > > > > With regard to status, I think we can work with you. > > But we really want to establish the registry now. > > We already have proposals for code points beyond the experimental RFCs, > > and requests for room to experiment without writing an RFC. > > > > As far as I can tell, the Working Group intent is that the registry > > allow reservation by experimental and informational RFCs, not just > > standards track RFCs. We can fix that. > > > > With regard to the revision to the base documents, to get them on the > > standards track, one of the important fixes is to stop claiming that > the > > RFC defines all the values, and just update the registry entries where > > appropriate to reference the new RFC (once we have it.) > > > > The rush is simply that it is already getting hard to keep track. We > > should have established a registry in the first place. So we are doing > > so now. > > > > > > On 1/30/17 4:46 PM, Alvaro Retana wrote: > > Alvaro Retana has entered the following ballot position for > > draft-ietf-lisp-type-iana-04: Discuss > > > > When responding, please keep the subject line intact and reply > to all > > email addresses included in the To and CC lines. (Feel free to > cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have a couple of points I think we should DISCUSS before > moving this > > document forward: the intended status and the definition of the > > registry. > > > > (1) Intended Status: The Datatracker indicates that the Intended RFC > > status for this document is Proposed Standard (as does the Shepherd > > WriteUp and the IETF LC), but the header on the document says > > Experimental. I note that the document header was changed after a > > discussion on the WG list resulting from the RTG Directorate > review [1], > > but that happened after the WGLC. Which is the right status? > > > > (2) LISP Packet Types Registry Definition: It seems very odd to > me that > > the LISP Packet Types Registry uses Standard Action as the > registration > > policy given that the LISP work is currently Experimental -- and > that the > > other references in it would in fact be from an Experimental RFC > > (rfc6380). I know there's work on rfc6830bis (in the Standards > Track), > > but I think it would be better to have this registry defined in > the base > > specification (rfc6833bis, in this case)...or to wait for the > publication > > of that document to progress this one. > > > > > > I think there's nothing procedurally wrong with having an > Experimental > > RFC define a Standard Action Registry and populate part of it with > > references to Experimental RFC. However, the solution just > doesn't seem > > clean to me -- so I would like to hear the justification for the > rush > > (and not waiting for rfc6380bis/rfc6388bis). > > > > I have no issue with a document making use of the Code Point to > describe > > the new LISP Shared Extension Message Type (without creating the > > Registry). But given that the base LISP specification is still > > Experimental, then this document should be too. There shouldn't > be an > > issue with changing the Status of this document (in-place) once > > rfc6380bis/rfc6388bis progress. > > > > > > There's also the issue that RFC6830 (and rfc6833bis) contain the > > following text: "This section will be the authoritative source for > > allocating LISP Type values..." Which means that (if the > registry is to > > be defined here), this document should at least Update RFC6830... > > > > In summary, I think that the correct Status for this document is > > Experimental. I also think that it would be better to wait for > > rfc6833bis to define the Registry. > > > > > > [1] > > https://mailarchive.ietf.org/arch/msg/lisp/m1EicCexdX1GI183pba-mcHJM7g/?qid=ada479dce3c434bfaf948b0ee8240996 > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > a. The Introduction justifies the extension as being used for > > experiments: "Because of the limited type space [RFC6830] and > the need to > > conduct experiments to assess new LISP extensions, this document > > specifies a shared LISP extension message type". It seems clear > later in > > the text that the intent of the new message type is not just for > > experimentation, but that in fact the intent is for new > functionality to > > be deployed using it. Is that correct? If it is, then please > make it > > clear -- if not, then I would like to see how the authors propose a > > transition to happen between the experimental space and the > production > > one. > > > > b. The IANA Considerations Section says that "The value 15 is > reserved > > for Experimental Use [RFC5226]." But it is being assigned to > the new > > LISP Shared Extension Message. > > > > > > > > > From nobody Tue Jan 31 00:12:34 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE312941C; Tue, 31 Jan 2017 00:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro-V1k8R_rMu; Tue, 31 Jan 2017 00:12:31 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585D1120726; Tue, 31 Jan 2017 00:12:31 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 93AEFA0B39; Tue, 31 Jan 2017 09:12:29 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 3A6871A007A; Tue, 31 Jan 2017 09:12:29 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Tue, 31 Jan 2017 09:12:28 +0100 From: To: "Joel M. Halpern" , Alvaro Retana , The IESG Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) Thread-Index: AQHSe0JG5ob8Pa3wVEiqCGQJZUoVcaFRfwYAgACmHiA= Date: Tue, 31 Jan 2017 08:12:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DEB012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-type-iana@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 08:12:33 -0000 SGkgQWx2YXJvLCBhbGwsDQoNCkkgY29uZmlybSB0aGF0IHRoZSBpbnRlbmRlZCBzdGF0dXMgaXMg RXhwZXJpbWVudGFsLiBKb2VsIGFscmVhZHkgZXhwbGFpbmVkIHdoeSB0aGUgV0cgd2FudGVkIHRv IGNyZWF0ZSB0aGlzIHJlZ2lzdHJ5IG5vdy4gDQoNClNlZSBtb3JlIGlubGluZS4NCg0KQ2hlZXJz LA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvZWwgTS4g SGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IEVudm95w6nCoDogbHVuZGkg MzAgamFudmllciAyMDE3IDIyOjUzDQo+IMOAwqA6IEFsdmFybyBSZXRhbmE7IFRoZSBJRVNHDQo+ IENjwqA6IGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmFAaWV0Zi5vcmc7IEx1aWdpIElhbm5vbmU7 IGxpc3AtDQo+IGNoYWlyc0BpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTog QWx2YXJvIFJldGFuYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wNDog KHdpdGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IFdpdGggcmVnYXJkIHRvIHN0YXR1 cywgSSB0aGluayB3ZSBjYW4gd29yayB3aXRoIHlvdS4NCj4gQnV0IHdlIHJlYWxseSB3YW50IHRv IGVzdGFibGlzaCB0aGUgcmVnaXN0cnkgbm93Lg0KPiBXZSBhbHJlYWR5IGhhdmUgcHJvcG9zYWxz IGZvciBjb2RlIHBvaW50cyBiZXlvbmQgdGhlIGV4cGVyaW1lbnRhbCBSRkNzLA0KPiBhbmQgcmVx dWVzdHMgZm9yIHJvb20gdG8gZXhwZXJpbWVudCB3aXRob3V0IHdyaXRpbmcgYW4gUkZDLg0KPiAN Cj4gQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoZSBXb3JraW5nIEdyb3VwIGludGVudCBpcyB0aGF0 IHRoZSByZWdpc3RyeQ0KPiBhbGxvdyByZXNlcnZhdGlvbiBieSBleHBlcmltZW50YWwgYW5kIGlu Zm9ybWF0aW9uYWwgUkZDcywgbm90IGp1c3QNCj4gc3RhbmRhcmRzIHRyYWNrIFJGQ3MuICBXZSBj YW4gZml4IHRoYXQuDQo+IA0KPiBXaXRoIHJlZ2FyZCB0byB0aGUgcmV2aXNpb24gdG8gdGhlIGJh c2UgZG9jdW1lbnRzLCB0byBnZXQgdGhlbSBvbiB0aGUNCj4gc3RhbmRhcmRzIHRyYWNrLCBvbmUg b2YgdGhlIGltcG9ydGFudCBmaXhlcyBpcyB0byBzdG9wIGNsYWltaW5nIHRoYXQgdGhlDQo+IFJG QyBkZWZpbmVzIGFsbCB0aGUgdmFsdWVzLCBhbmQganVzdCB1cGRhdGUgdGhlIHJlZ2lzdHJ5IGVu dHJpZXMgd2hlcmUNCj4gYXBwcm9wcmlhdGUgdG8gcmVmZXJlbmNlIHRoZSBuZXcgUkZDIChvbmNl IHdlIGhhdmUgaXQuKQ0KPiANCj4gVGhlIHJ1c2ggaXMgc2ltcGx5IHRoYXQgaXQgaXMgYWxyZWFk eSBnZXR0aW5nIGhhcmQgdG8ga2VlcCB0cmFjay4gIFdlDQo+IHNob3VsZCBoYXZlIGVzdGFibGlz aGVkIGEgcmVnaXN0cnkgaW4gdGhlIGZpcnN0IHBsYWNlLiAgU28gd2UgYXJlIGRvaW5nDQo+IHNv IG5vdy4NCj4gDQo+IE9uIDEvMzAvMTcgNDo0NiBQTSwgQWx2YXJvIFJldGFuYSB3cm90ZToNCj4g PiBBbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KPiA+IGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEtMDQ6IERpc2N1c3MNCj4gPg0KPiA+ IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbA0KPiA+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+ID4gaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+ID4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4gPg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEvDQo+ID4NCj4gPg0KPiA+DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+IERJU0NVU1M6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ ID4gSSBoYXZlIGEgY291cGxlIG9mIHBvaW50cyBJIHRoaW5rIHdlIHNob3VsZCBESVNDVVNTIGJl Zm9yZSBtb3ZpbmcgdGhpcw0KPiA+IGRvY3VtZW50IGZvcndhcmQ6IHRoZSBpbnRlbmRlZCBzdGF0 dXMgYW5kIHRoZSBkZWZpbml0aW9uIG9mIHRoZQ0KPiA+IHJlZ2lzdHJ5Lg0KPiA+DQo+ID4gKDEp IEludGVuZGVkIFN0YXR1czogVGhlIERhdGF0cmFja2VyIGluZGljYXRlcyB0aGF0IHRoZSBJbnRl bmRlZCBSRkMNCj4gPiBzdGF0dXMgZm9yIHRoaXMgZG9jdW1lbnQgaXMgUHJvcG9zZWQgU3RhbmRh cmQgKGFzIGRvZXMgdGhlIFNoZXBoZXJkDQo+ID4gV3JpdGVVcCBhbmQgdGhlIElFVEYgTEMpLCBi dXQgdGhlIGhlYWRlciBvbiB0aGUgZG9jdW1lbnQgc2F5cw0KPiA+IEV4cGVyaW1lbnRhbC4gIEkg bm90ZSB0aGF0IHRoZSBkb2N1bWVudCBoZWFkZXIgd2FzIGNoYW5nZWQgYWZ0ZXIgYQ0KPiA+IGRp c2N1c3Npb24gb24gdGhlIFdHIGxpc3QgcmVzdWx0aW5nIGZyb20gdGhlIFJURyBEaXJlY3RvcmF0 ZSByZXZpZXcgWzFdLA0KPiA+IGJ1dCB0aGF0IGhhcHBlbmVkIGFmdGVyIHRoZSBXR0xDLiAgV2hp Y2ggaXMgdGhlIHJpZ2h0IHN0YXR1cz8NCj4gPg0KPiA+ICgyKSBMSVNQIFBhY2tldCBUeXBlcyBS ZWdpc3RyeSBEZWZpbml0aW9uOiBJdCBzZWVtcyB2ZXJ5IG9kZCB0byBtZSB0aGF0DQo+ID4gdGhl IExJU1AgUGFja2V0IFR5cGVzIFJlZ2lzdHJ5IHVzZXMgU3RhbmRhcmQgQWN0aW9uIGFzIHRoZSBy ZWdpc3RyYXRpb24NCj4gPiBwb2xpY3kgZ2l2ZW4gdGhhdCB0aGUgTElTUCB3b3JrIGlzIGN1cnJl bnRseSBFeHBlcmltZW50YWwgLS0gYW5kIHRoYXQNCj4gdGhlDQo+ID4gb3RoZXIgcmVmZXJlbmNl cyBpbiBpdCB3b3VsZCBpbiBmYWN0IGJlIGZyb20gYW4gRXhwZXJpbWVudGFsIFJGQw0KPiA+IChy ZmM2MzgwKS4gIEkga25vdyB0aGVyZSdzIHdvcmsgb24gcmZjNjgzMGJpcyAoaW4gdGhlIFN0YW5k YXJkcyBUcmFjayksDQo+ID4gYnV0IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUg dGhpcyByZWdpc3RyeSBkZWZpbmVkIGluIHRoZSBiYXNlDQo+ID4gc3BlY2lmaWNhdGlvbiAocmZj NjgzM2JpcywgaW4gdGhpcyBjYXNlKS4uLm9yIHRvIHdhaXQgZm9yIHRoZQ0KPiBwdWJsaWNhdGlv bg0KPiA+IG9mIHRoYXQgZG9jdW1lbnQgdG8gcHJvZ3Jlc3MgdGhpcyBvbmUuDQo+ID4NCj4gPg0K PiA+IEkgdGhpbmsgdGhlcmUncyBub3RoaW5nIHByb2NlZHVyYWxseSB3cm9uZyB3aXRoIGhhdmlu ZyBhbiBFeHBlcmltZW50YWwNCj4gPiBSRkMgZGVmaW5lIGEgU3RhbmRhcmQgQWN0aW9uIFJlZ2lz dHJ5IGFuZCBwb3B1bGF0ZSBwYXJ0IG9mIGl0IHdpdGgNCj4gPiByZWZlcmVuY2VzIHRvIEV4cGVy aW1lbnRhbCBSRkMuICBIb3dldmVyLCB0aGUgc29sdXRpb24ganVzdCBkb2Vzbid0IHNlZW0NCj4g PiBjbGVhbiB0byBtZSAtLSBzbyBJIHdvdWxkIGxpa2UgdG8gaGVhciB0aGUganVzdGlmaWNhdGlv biBmb3IgdGhlIHJ1c2gNCj4gPiAoYW5kIG5vdCB3YWl0aW5nIGZvciByZmM2MzgwYmlzL3JmYzYz ODhiaXMpLg0KPiA+DQo+ID4gSSBoYXZlIG5vIGlzc3VlIHdpdGggYSBkb2N1bWVudCBtYWtpbmcg dXNlIG9mIHRoZSBDb2RlIFBvaW50IHRvIGRlc2NyaWJlDQo+ID4gdGhlIG5ldyBMSVNQIFNoYXJl ZCBFeHRlbnNpb24gTWVzc2FnZSBUeXBlICh3aXRob3V0IGNyZWF0aW5nIHRoZQ0KPiA+IFJlZ2lz dHJ5KS4gIEJ1dCBnaXZlbiB0aGF0IHRoZSBiYXNlIExJU1Agc3BlY2lmaWNhdGlvbiBpcyBzdGls bA0KPiA+IEV4cGVyaW1lbnRhbCwgdGhlbiB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSB0b28uICBU aGVyZSBzaG91bGRuJ3QgYmUgYW4NCj4gPiBpc3N1ZSB3aXRoIGNoYW5naW5nIHRoZSBTdGF0dXMg b2YgdGhpcyBkb2N1bWVudCAoaW4tcGxhY2UpIG9uY2UNCj4gPiByZmM2MzgwYmlzL3JmYzYzODhi aXMgcHJvZ3Jlc3MuDQo+ID4NCj4gPg0KPiA+IFRoZXJlJ3MgYWxzbyB0aGUgaXNzdWUgdGhhdCBS RkM2ODMwIChhbmQgcmZjNjgzM2JpcykgY29udGFpbiB0aGUNCj4gPiBmb2xsb3dpbmcgdGV4dDog IlRoaXMgc2VjdGlvbiB3aWxsIGJlIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSBmb3INCj4gPiBh bGxvY2F0aW5nIExJU1AgVHlwZSB2YWx1ZXMuLi4iICAgV2hpY2ggbWVhbnMgdGhhdCAoaWYgdGhl IHJlZ2lzdHJ5IGlzDQo+IHRvDQo+ID4gYmUgZGVmaW5lZCBoZXJlKSwgdGhpcyBkb2N1bWVudCBz aG91bGQgYXQgbGVhc3QgVXBkYXRlIFJGQzY4MzAuLi4NCj4gPg0KPiA+IEluIHN1bW1hcnksIEkg dGhpbmsgdGhhdCB0aGUgY29ycmVjdCBTdGF0dXMgZm9yIHRoaXMgZG9jdW1lbnQgaXMNCj4gPiBF eHBlcmltZW50YWwuICBJIGFsc28gdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gd2Fp dCBmb3INCj4gPiByZmM2ODMzYmlzIHRvIGRlZmluZSB0aGUgUmVnaXN0cnkuDQo+ID4NCj4gPg0K PiA+IFsxXQ0KPiA+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbGlzcC9t MUVpY0NleGRYMUdJMTgzcGJhLQ0KPiBtY0hKTTdnLz9xaWQ9YWRhNDc5ZGNlM2M0MzRiZmFmOTQ4 YjBlZTgyNDA5OTYNCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENPTU1FTlQ6DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gYS4gVGhlIEludHJvZHVjdGlvbiBqdXN0aWZpZXMg dGhlIGV4dGVuc2lvbiBhcyBiZWluZyB1c2VkIGZvcg0KPiA+IGV4cGVyaW1lbnRzOiAiQmVjYXVz ZSBvZiB0aGUgbGltaXRlZCB0eXBlIHNwYWNlIFtSRkM2ODMwXSBhbmQgdGhlIG5lZWQNCj4gdG8N Cj4gPiBjb25kdWN0IGV4cGVyaW1lbnRzIHRvIGFzc2VzcyBuZXcgTElTUCBleHRlbnNpb25zLCB0 aGlzIGRvY3VtZW50DQo+ID4gc3BlY2lmaWVzIGEgc2hhcmVkIExJU1AgZXh0ZW5zaW9uIG1lc3Nh Z2UgdHlwZSIuICBJdCBzZWVtcyBjbGVhciBsYXRlcg0KPiBpbg0KPiA+IHRoZSB0ZXh0IHRoYXQg dGhlIGludGVudCBvZiB0aGUgbmV3IG1lc3NhZ2UgdHlwZSBpcyBub3QganVzdCBmb3INCj4gPiBl eHBlcmltZW50YXRpb24sIGJ1dCB0aGF0IGluIGZhY3QgdGhlIGludGVudCBpcyBmb3IgbmV3IGZ1 bmN0aW9uYWxpdHkgdG8NCj4gPiBiZSBkZXBsb3llZCB1c2luZyBpdC4gIElzIHRoYXQgY29ycmVj dD8gIElmIGl0IGlzLCB0aGVuIHBsZWFzZSBtYWtlIGl0DQo+ID4gY2xlYXIgLS0gaWYgbm90LCB0 aGVuIEkgd291bGQgbGlrZSB0byBzZWUgaG93IHRoZSBhdXRob3JzIHByb3Bvc2UgYQ0KPiA+IHRy YW5zaXRpb24gdG8gaGFwcGVuIGJldHdlZW4gdGhlIGV4cGVyaW1lbnRhbCBzcGFjZSBhbmQgdGhl IHByb2R1Y3Rpb24NCj4gPiBvbmUuDQoNCltNZWRdIFdoYXQgYWJvdXQgYWRkaW5nIHRoaXMgTkVX IHRleHQ6IA0KDQogICBTb21lIExJU1AgZXh0ZW5zaW9ucyB0aGF0IG1ha2UgdXNlIG9mIHRoZSBM SVNQIHNoYXJlZCBleHRlbnNpb24NCiAgIG1lc3NhZ2UgdHlwZSBtYXkgYmVjb21lIGVsaWdpYmxl IGZvciBhbiBhc3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlDQogICAoU2VjdGlvbiA1LjEpLiAgT25j ZSBhIExJU1AgcGFja2V0IHR5cGUgaXMgYXNzaWduZWQgdG8gc3VjaCBMSVNQDQogICBleHRlbnNp b24sIGFuIGltcGxlbWVudGF0aW9uIFNIT1VMRCBOT1QgdXNlIHRoZSBMSVNQIHNoYXJlZA0KICAg ZXh0ZW5zaW9uIG1lc3NhZ2UgdHlwZS4NCg0KICAgVG8gZW5zdXJlIGJhY2t3YXJkIGNvbXBhdGli aWxpdHkgZHVyaW5nIGEgdHJhbnNpdGlvbiBwZXJpb2QsIGFuDQogICBpbXBsZW1lbnRhdGlvbiBN QVkgc3VwcG9ydCBhIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyIHRvIGluc3RydWN0DQogICB3aGV0 aGVyIHRoZSBMSVNQIGV4dGVuc2lvbiB1c2luZyB0aGUgc2hhcmVkIGV4dGVuc2lvbiBtZXNzYWdl IGlzIHRvDQogICBiZSBzZW50IHNpbXVsdGFuZW91c2x5IHdpdGggdGhlIExJU1AgZXh0ZW5zaW9u IG1lc3NhZ2UgdXNpbmcgdGhlDQogICBhc3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlLiAgVGhlIGRl ZmF1bHQgdmFsdWUgb2YgdGhhdCBjb25maWd1cmF0aW9uDQogICBwYXJhbWV0ZXIgaXMgdG8gZGlz YWJsZSBzZW5kaW5nIGJvdGggbWVzc2FnZXMuICBUaGUgdXNlIG9mIHRoZSB0d28NCiAgIG1lc3Nh Z2UgZm9ybWF0cyBpbmNyZWFzZXMgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgYnV0IGl0IGhhcyBz b21lDQogICBpbXBsaWNhdGlvbnMgb24gdGhlIExJU1AgY29udHJvbCBsb2FkLiAgU3VjaCBpbXBs aWNhdGlvbnMgYXJlDQogICBleHBlY3RlZCB0byBiZSBsaW1pdGVkIGluIHRpbWUgYW5kIGFyZSBm dWxseSB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUNCiAgIGVudGl0eSBvcGVyYXRpbmcgYSBMSVNQ IGRvbWFpbi4NCg0KPiA+DQo+ID4gYi4gVGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBz YXlzIHRoYXQgIlRoZSB2YWx1ZSAxNSBpcyByZXNlcnZlZA0KPiA+IGZvciBFeHBlcmltZW50YWwg VXNlIFtSRkM1MjI2XS4iICBCdXQgaXQgaXMgYmVpbmcgYXNzaWduZWQgdG8gdGhlIG5ldw0KPiA+ IExJU1AgU2hhcmVkIEV4dGVuc2lvbiBNZXNzYWdlLg0KPiA+DQoNCltNZWRdIEkgZGVsZXRlZCB0 aGF0IHNlbnRlbmNlLiANCg== From nobody Tue Jan 31 06:28:56 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043E0129F6D; Tue, 31 Jan 2017 06:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E-lark4PNfd; Tue, 31 Jan 2017 06:28:50 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CEA129F68; Tue, 31 Jan 2017 06:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26186; q=dns/txt; s=iport; t=1485872930; x=1487082530; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n3bjPWqvG8f7GiPmSp0W6KPkGf4YkRkMLTuYtEh07mI=; b=QbN7mYPlo9VyrQJnEQn9vgHJN+zTrbAbCYUz1P+iYUbzlxfUQta6yCjg Ys+GgpIxJjX4o6IaAjw+nIPmeG35jzwCs4AiHVHLRCdNWw9jptZ4Xe5f3 fuor0qcrHDzopN+il08J9gz4sBIpeQ7FAsRbmLryN7XyRvtLX9DuMrZN2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgBPnpBY/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm85K2GBCQeDT4oJkWcfkySCD4INKoV4AhqCEj8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEagEEASNIDgULAgEIJBsDAgICMBQRAgQBDQWJZggOq2aCJSuKcgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhkuCBQiCYoQoBwEBgyEugjEFiQOMQIYUAZF9gXm?= =?us-ascii?q?FFYlqiCaKWAEfOIFLFTsQAYRggUh1AYVtDxeBCoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208,217";a="200533944" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jan 2017 14:28:49 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0VESnUi020400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 14:28:49 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 08:28:48 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 31 Jan 2017 08:28:48 -0600 From: "Alvaro Retana (aretana)" To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , The IESG Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) Thread-Index: AQHSe0JHF3IUDVpxIkSQ7eReJZcjSqFRfwYAgACmHiCAAJG4AA== Date: Tue, 31 Jan 2017 14:28:48 +0000 Message-ID: <497B4C1B-CAB6-469B-8467-F7A7A08847FF@cisco.com> References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DEB012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DEB012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_497B4C1BCAB6469B8467F7A7A08847FFciscocom_" MIME-Version: 1.0 Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-type-iana@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 14:28:52 -0000 --_000_497B4C1BCAB6469B8467F7A7A08847FFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWVkOg0KDQpIaSENCg0KSeKAmWxsIGNsZWFyIG15IERJU0NVU1Mgb25jZSB0aGUgcmVzcG9uc2li bGUgQUQgY29uZmlybXMgdGhlIHN0YXR1cyBhbmQgY2hhbmdlcyB0aGUgZGF0YXRyYWNrZXIuICBK dXN0IG9uZSBtb3JlIHRoaW5nLCBJIHN0aWxsIHRoaW5rIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91 bGQgVXBkYXRlIHJmYzY4MzAgYmVjYXVzZSBldmVuIHRob3VnaCBpdCBkaWRu4oCZdCBkZWZpbmUg YSByZWdpc3RyeSwgaXQgZG9lcyBzYXkgdGhhdCBpdCBpcyDigJx0aGUgYXV0aG9yaXRhdGl2ZSBz b3VyY2UgZm9yIGFsbG9jYXRpbmcgTElTUCBUeXBlIHZhbHVlc+KAnS4gW1RoaXMgaXMgYSBtaW5v ciBwb2ludCBrbm93aW5nIHRoYXQgcmZjNjgzMGJpcy9yZmM2ODMzYmlzIHNob3VsZCBzb29uIHJl bmRlciByZmM2ODMwIE9ic29sZXRlLg0KDQpGV0lXLCBldmVuIHRob3VnaCB0aGUgSUVURiBMYXN0 IENhbGwgd2FzIG1hZGUgYXNzdW1pbmcgYSBQcm9wb3NlZCBTdGFuZGFyZCwgSSBkb27igJl0IHNl ZSB0aGUgbmVlZCB0byByZXJ1biBpdC4gIEJ1dCB0aGF0IGlzIHVwIHRvIHRoZSByZXNwb25zaWJs ZSBBRC4NCg0KDQpBYm91dCB0aGUgdGV4dCB5b3UgcHJvcG9zZWQgYmVsb3figKYgIFRoZSBMSVNQ IFBhY2tldCBUeXBlIFJlZ2lzdHJ5ICg0LjEsIG5vdCA1LjEpIGhhcyBvbmx5IDE1IHBvc3NpYmxl IHZhbHVlcywgNyBvZiB3aGljaCBhcmUgYXNzaWduZWQvcmVzZXJ2ZWQgYnkgdGhpcyBkb2N1bWVu dCwgcmZjNjgzM2JpcyBhc3NpZ25zIDMgbW9yZSB2YWx1ZXMsIGFuZCB0aGlzIGRvY3VtZW50IG1l bnRpb25zIDUgcG90ZW50aWFsIGV4dGVuc2lvbnMgKOKAnG5ldyBtZXNzYWdlIHR5cGVzIGFyZSBw cm9wb3NlZCBpbiBbSS1ELmlldGYtbGlzcC1kZHRdLCBbSS1ELnpoYW8tbGlzcC1tbi1leHRlbnNp b25dLCBbSS1ELmJvdWNhZGFpci1saXNwLWJ1bGtdLCBbSS1ELmVybWFnYW4tbGlzcC1uYXQtdHJh dmVyc2FsXSwgb3IgW0ktRC5ib3VjYWRhaXItbGlzcC1zdWJzY3JpYmVd4oCdIFsqXSnigKZicmlu Z2luZyB0aGUgdG90YWwgdXAgdG8gMTUuICBFdmVuIGlmIG5vdCBhbGwgdGhlc2UgbmV3IGRyYWZ0 cyBtYWtlIGl0LCB0aGUgTElTUCBQYWNrZXQgVHlwZSBSZWdpc3RyeSB3aWxsIHNvb24gaGF2ZSBu byBtb3JlIHZhbHVlcyB0byBhc3NpZ24uICBUaGUgcmVzdWx0IHdpbGwgYmUgdGhhdCB0aGUgU3Vi LVR5cGVzIChpbiB0aGUgTElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgVHlwZSkgd2lsbCBi ZSB1c2VkIGZvciBwcm9kdWN0aW9uIFsxXS4NCg0KSU9XLCBJIGRvbuKAmXQgdGhpbmsgeW91IG5l ZWQgYSB0cmFuc2l0aW9uIG1lY2hhbmlzbS4gIEluc3RlYWQsIEkgdGhpbmsgeW91IG5lZWQgdG8g cmVjb2duaXplIHRoYXQgdGhlIFN1Yi1UeXBlcyB3aWxsIGJlIHVzZWQgZm9yIHByb2R1Y3Rpb24g ZGVwbG95bWVudHMuICBTdWdnZXN0aW9uOiAgY29uc2lkZXIgY2hhbmdpbmcgdGhlIHJlZ2lzdHJh dGlvbiBwb2xpY3kgZnJvbSBGQ0ZTIHRvIHNvbWV0aGluZyB3aGVyZSBwYXJ0IG9mIHRoZSBzcGFj ZSByZXF1aXJlcyBTdGFuZGFyZHMgQWN0aW9uLCBvciBtYXliZSBSRkMgUmVxdWlyZWQgb3IgZXZl biBFeHBlcnQgUmV2aWV3LiAgVGhlIHJlc3VsdCBvZiBGQ0ZTIGlzIHRoYXQgYW55b25lIGNhbiBy ZXF1ZXN0IGEgdmFsdWUgYW5kIGdldCBpdDog4oCcVGhlcmUgaXMgbm8gc3Vic3RhbnRpdmUgcmV2 aWV3IG9mIHRoZSByZXF1ZXN0LCBvdGhlciB0aGFuIHRvIGVuc3VyZSB0aGF0IGl0IGlzIHdlbGwt Zm9ybWVkIGFuZCBkb2Vzbid0IGR1cGxpY2F0ZSBhbiBleGlzdGluZyBhc3NpZ25tZW50LuKAnSBb cmZjNTIyNl0NCg0KSSBkaWRu4oCZdCBtYWtlIHRoaXMgbGFzdCBwb2ludCBhIERJU0NVU1MgYmVj YXVzZSB0aGUgZG9jdW1lbnQgd2FzIGFscmVhZHkgZGlzY3Vzc2VkIGluIHRoZSBXRyBhbmQgd2Vu dCB0aHJvdWdoIElFVEYgTEMsIGJ1dCBJIHRoaW5rIGl0IGlzIG5vdCBhIGdvb2QgaWRlYSB0byBs ZWF2ZSB0aGUgU3ViLVR5cGVzIHJlZ2lzdHJ5IGFzIGlzLg0KDQpUaGFua3MhDQoNCkFsdmFyby4N Cg0KDQpbKl0gQlRXLCBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IGZvciB5b3UgdG8g bGlzdCB0aGVzZSBkcmFmdHMgc2luY2Ugc29tZSBvZiB0aGVtIG1heSBjaGFuZ2Ugb3Igbm90IG1h a2UgaXQgYWxsIHRoZSB3YXkgdG8gcHVibGljYXRpb24uICBUaGUganVzdGlmaWNhdGlvbiBvZiBn ZW5lcmljIG5ldyB3b3JrIHNob3VsZCBiZSBlbm91Z2guDQoNClsxXSBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2xpc3AvY3VycmVudC9tc2cwNjQ1OS5odG1sDQoNCk9uIDEv MzEvMTcsIDM6MTIgQU0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCg0KDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBhLiBUaGUgSW50cm9k dWN0aW9uIGp1c3RpZmllcyB0aGUgZXh0ZW5zaW9uIGFzIGJlaW5nIHVzZWQgZm9yDQo+IGV4cGVy aW1lbnRzOiAiQmVjYXVzZSBvZiB0aGUgbGltaXRlZCB0eXBlIHNwYWNlIFtSRkM2ODMwXSBhbmQg dGhlIG5lZWQNCnRvDQo+IGNvbmR1Y3QgZXhwZXJpbWVudHMgdG8gYXNzZXNzIG5ldyBMSVNQIGV4 dGVuc2lvbnMsIHRoaXMgZG9jdW1lbnQNCj4gc3BlY2lmaWVzIGEgc2hhcmVkIExJU1AgZXh0ZW5z aW9uIG1lc3NhZ2UgdHlwZSIuICBJdCBzZWVtcyBjbGVhciBsYXRlcg0KaW4NCj4gdGhlIHRleHQg dGhhdCB0aGUgaW50ZW50IG9mIHRoZSBuZXcgbWVzc2FnZSB0eXBlIGlzIG5vdCBqdXN0IGZvcg0K PiBleHBlcmltZW50YXRpb24sIGJ1dCB0aGF0IGluIGZhY3QgdGhlIGludGVudCBpcyBmb3IgbmV3 IGZ1bmN0aW9uYWxpdHkgdG8NCj4gYmUgZGVwbG95ZWQgdXNpbmcgaXQuICBJcyB0aGF0IGNvcnJl Y3Q/ICBJZiBpdCBpcywgdGhlbiBwbGVhc2UgbWFrZSBpdA0KPiBjbGVhciAtLSBpZiBub3QsIHRo ZW4gSSB3b3VsZCBsaWtlIHRvIHNlZSBob3cgdGhlIGF1dGhvcnMgcHJvcG9zZSBhDQo+IHRyYW5z aXRpb24gdG8gaGFwcGVuIGJldHdlZW4gdGhlIGV4cGVyaW1lbnRhbCBzcGFjZSBhbmQgdGhlIHBy b2R1Y3Rpb24NCj4gb25lLg0KDQpbTWVkXSBXaGF0IGFib3V0IGFkZGluZyB0aGlzIE5FVyB0ZXh0 Og0KDQogICBTb21lIExJU1AgZXh0ZW5zaW9ucyB0aGF0IG1ha2UgdXNlIG9mIHRoZSBMSVNQIHNo YXJlZCBleHRlbnNpb24NCiAgIG1lc3NhZ2UgdHlwZSBtYXkgYmVjb21lIGVsaWdpYmxlIGZvciBh biBhc3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlDQogICAoU2VjdGlvbiA1LjEpLiAgT25jZSBhIExJ U1AgcGFja2V0IHR5cGUgaXMgYXNzaWduZWQgdG8gc3VjaCBMSVNQDQogICBleHRlbnNpb24sIGFu IGltcGxlbWVudGF0aW9uIFNIT1VMRCBOT1QgdXNlIHRoZSBMSVNQIHNoYXJlZA0KICAgZXh0ZW5z aW9uIG1lc3NhZ2UgdHlwZS4NCg0KICAgVG8gZW5zdXJlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg ZHVyaW5nIGEgdHJhbnNpdGlvbiBwZXJpb2QsIGFuDQogICBpbXBsZW1lbnRhdGlvbiBNQVkgc3Vw cG9ydCBhIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyIHRvIGluc3RydWN0DQogICB3aGV0aGVyIHRo ZSBMSVNQIGV4dGVuc2lvbiB1c2luZyB0aGUgc2hhcmVkIGV4dGVuc2lvbiBtZXNzYWdlIGlzIHRv DQogICBiZSBzZW50IHNpbXVsdGFuZW91c2x5IHdpdGggdGhlIExJU1AgZXh0ZW5zaW9uIG1lc3Nh Z2UgdXNpbmcgdGhlDQogICBhc3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlLiAgVGhlIGRlZmF1bHQg dmFsdWUgb2YgdGhhdCBjb25maWd1cmF0aW9uDQogICBwYXJhbWV0ZXIgaXMgdG8gZGlzYWJsZSBz ZW5kaW5nIGJvdGggbWVzc2FnZXMuICBUaGUgdXNlIG9mIHRoZSB0d28NCiAgIG1lc3NhZ2UgZm9y bWF0cyBpbmNyZWFzZXMgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgYnV0IGl0IGhhcyBzb21lDQog ICBpbXBsaWNhdGlvbnMgb24gdGhlIExJU1AgY29udHJvbCBsb2FkLiAgU3VjaCBpbXBsaWNhdGlv bnMgYXJlDQogICBleHBlY3RlZCB0byBiZSBsaW1pdGVkIGluIHRpbWUgYW5kIGFyZSBmdWxseSB1 bmRlciB0aGUgY29udHJvbCBvZiB0aGUNCiAgIGVudGl0eSBvcGVyYXRpbmcgYSBMSVNQIGRvbWFp bi4NCg0K --_000_497B4C1BCAB6469B8467F7A7A08847FFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TWVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPknigJlsbCBjbGVhciBteSBESVNDVVNT IG9uY2UgdGhlIHJlc3BvbnNpYmxlIEFEIGNvbmZpcm1zIHRoZSBzdGF0dXMgYW5kIGNoYW5nZXMg dGhlIGRhdGF0cmFja2VyLiZuYnNwOyBKdXN0IG9uZSBtb3JlIHRoaW5nLCBJIHN0aWxsIHRoaW5r IHRoYXQgdGhpcyBkb2N1bWVudCBzaG91bGQgVXBkYXRlIHJmYzY4MzAgYmVjYXVzZSBldmVuDQog dGhvdWdoIGl0IGRpZG7igJl0IGRlZmluZSBhIHJlZ2lzdHJ5LCBpdCBkb2VzIHNheSB0aGF0IGl0 IGlzIOKAnHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSBmb3IgYWxsb2NhdGluZyBMSVNQIFR5cGUg dmFsdWVz4oCdLiBbVGhpcyBpcyBhIG1pbm9yIHBvaW50IGtub3dpbmcgdGhhdCByZmM2ODMwYmlz L3JmYzY4MzNiaXMgc2hvdWxkIHNvb24gcmVuZGVyIHJmYzY4MzAgT2Jzb2xldGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+RldJVywgZXZlbiB0aG91Z2ggdGhlIElFVEYgTGFzdCBDYWxsIHdh cyBtYWRlIGFzc3VtaW5nIGEgUHJvcG9zZWQgU3RhbmRhcmQsIEkgZG9u4oCZdCBzZWUgdGhlIG5l ZWQgdG8gcmVydW4gaXQuJm5ic3A7IEJ1dCB0aGF0IGlzIHVwIHRvIHRoZSByZXNwb25zaWJsZSBB RC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5BYm91dCB0aGUgdGV4dCB5b3UgcHJvcG9zZWQgYmVsb3figKYmbmJz cDsgVGhlIExJU1AgUGFja2V0IFR5cGUgUmVnaXN0cnkgKDQuMSwgbm90IDUuMSkgaGFzIG9ubHkg MTUgcG9zc2libGUgdmFsdWVzLCA3IG9mIHdoaWNoIGFyZSBhc3NpZ25lZC9yZXNlcnZlZCBieSB0 aGlzIGRvY3VtZW50LCByZmM2ODMzYmlzIGFzc2lnbnMgMyBtb3JlDQogdmFsdWVzLCBhbmQgdGhp cyBkb2N1bWVudCBtZW50aW9ucyA1IHBvdGVudGlhbCBleHRlbnNpb25zICjigJxuZXcgbWVzc2Fn ZSB0eXBlcyBhcmUgcHJvcG9zZWQgaW4gW0ktRC5pZXRmLWxpc3AtZGR0XSwgW0ktRC56aGFvLWxp c3AtbW4tZXh0ZW5zaW9uXSwgW0ktRC5ib3VjYWRhaXItbGlzcC1idWxrXSwgW0ktRC5lcm1hZ2Fu LWxpc3AtbmF0LXRyYXZlcnNhbF0sIG9yIFtJLUQuYm91Y2FkYWlyLWxpc3Atc3Vic2NyaWJlXeKA nSBbKl0p4oCmYnJpbmdpbmcgdGhlDQogdG90YWwgdXAgdG8gMTUuJm5ic3A7IEV2ZW4gaWYgbm90 IGFsbCB0aGVzZSBuZXcgZHJhZnRzIG1ha2UgaXQsIHRoZSBMSVNQIFBhY2tldCBUeXBlIFJlZ2lz dHJ5IHdpbGwgc29vbiBoYXZlIG5vIG1vcmUgdmFsdWVzIHRvIGFzc2lnbi4mbmJzcDsgVGhlIHJl c3VsdCB3aWxsIGJlIHRoYXQgdGhlIFN1Yi1UeXBlcyAoaW4gdGhlIExJU1AgU2hhcmVkIEV4dGVu c2lvbiBNZXNzYWdlIFR5cGUpIHdpbGwgYmUgdXNlZCBmb3IgcHJvZHVjdGlvbiBbMV0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SU9XLCBJIGRvbuKAmXQgdGhpbmsgeW91IG5lZWQgYSB0cmFu c2l0aW9uIG1lY2hhbmlzbS4mbmJzcDsgSW5zdGVhZCwgSSB0aGluayB5b3UgbmVlZCB0byByZWNv Z25pemUgdGhhdCB0aGUgU3ViLVR5cGVzIHdpbGwgYmUgdXNlZCBmb3IgcHJvZHVjdGlvbiBkZXBs b3ltZW50cy4mbmJzcDsgU3VnZ2VzdGlvbjombmJzcDsgY29uc2lkZXIgY2hhbmdpbmcgdGhlDQog cmVnaXN0cmF0aW9uIHBvbGljeSBmcm9tIEZDRlMgdG8gc29tZXRoaW5nIHdoZXJlIHBhcnQgb2Yg dGhlIHNwYWNlIHJlcXVpcmVzIFN0YW5kYXJkcyBBY3Rpb24sIG9yIG1heWJlIFJGQyBSZXF1aXJl ZCBvciBldmVuIEV4cGVydCBSZXZpZXcuJm5ic3A7IFRoZSByZXN1bHQgb2YgRkNGUyBpcyB0aGF0 IGFueW9uZSBjYW4gcmVxdWVzdCBhIHZhbHVlIGFuZCBnZXQgaXQ6IOKAnFRoZXJlIGlzIG5vIHN1 YnN0YW50aXZlIHJldmlldyBvZiB0aGUgcmVxdWVzdCwgb3RoZXINCiB0aGFuIHRvIGVuc3VyZSB0 aGF0IGl0IGlzIHdlbGwtZm9ybWVkIGFuZCBkb2Vzbid0IGR1cGxpY2F0ZSBhbiBleGlzdGluZyBh c3NpZ25tZW50LuKAnSBbcmZjNTIyNl0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgZGlk buKAmXQgbWFrZSB0aGlzIGxhc3QgcG9pbnQgYSBESVNDVVNTIGJlY2F1c2UgdGhlIGRvY3VtZW50 IHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgV0cgYW5kIHdlbnQgdGhyb3VnaCBJRVRGIExD LCBidXQgSSB0aGluayBpdCBpcyBub3QgYSBnb29kIGlkZWEgdG8gbGVhdmUgdGhlIFN1Yi1UeXBl cyByZWdpc3RyeQ0KIGFzIGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+WypdIEJUVywgSSBk b27igJl0IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSBmb3IgeW91IHRvIGxpc3QgdGhlc2UgZHJhZnRz IHNpbmNlIHNvbWUgb2YgdGhlbSBtYXkgY2hhbmdlIG9yIG5vdCBtYWtlIGl0IGFsbCB0aGUgd2F5 IHRvIHB1YmxpY2F0aW9uLiZuYnNwOyBUaGUganVzdGlmaWNhdGlvbiBvZiBnZW5lcmljIG5ldyB3 b3JrIHNob3VsZA0KIGJlIGVub3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bMV0gPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9saXNwL2N1cnJlbnQv bXNnMDY0NTkuaHRtbCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2xp c3AvY3VycmVudC9tc2cwNjQ1OS5odG1sPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8zMS8xNywgMzoxMiBBTSwgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbjtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KJmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgQ09NTUVOVDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jmd0OyBhLiBUaGUgSW50cm9kdWN0aW9uIGp1c3RpZmllcyB0aGUgZXh0ZW5zaW9uIGFz IGJlaW5nIHVzZWQgZm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgZXhwZXJp bWVudHM6ICZxdW90O0JlY2F1c2Ugb2YgdGhlIGxpbWl0ZWQgdHlwZSBzcGFjZSBbUkZDNjgzMF0g YW5kIHRoZSBuZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnRvPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZndDsgY29uZHVjdCBleHBlcmltZW50cyB0byBhc3Nlc3MgbmV3 IExJU1AgZXh0ZW5zaW9ucywgdGhpcyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mZ3Q7IHNwZWNpZmllcyBhIHNoYXJlZCBMSVNQIGV4dGVuc2lvbiBtZXNzYWdlIHR5cGUm cXVvdDsuJm5ic3A7Jm5ic3A7SXQgc2VlbXMgY2xlYXIgbGF0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyB0aGUgdGV4 dCB0aGF0IHRoZSBpbnRlbnQgb2YgdGhlIG5ldyBtZXNzYWdlIHR5cGUgaXMgbm90IGp1c3QgZm9y PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgZXhwZXJpbWVudGF0aW9uLCBidXQg dGhhdCBpbiBmYWN0IHRoZSBpbnRlbnQgaXMgZm9yIG5ldyBmdW5jdGlvbmFsaXR5IHRvPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgYmUgZGVwbG95ZWQgdXNpbmcgaXQuJm5ic3A7 Jm5ic3A7SXMgdGhhdCBjb3JyZWN0PyZuYnNwOyZuYnNwO0lmIGl0IGlzLCB0aGVuIHBsZWFzZSBt YWtlIGl0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgY2xlYXIgLS0gaWYgbm90 LCB0aGVuIEkgd291bGQgbGlrZSB0byBzZWUgaG93IHRoZSBhdXRob3JzIHByb3Bvc2UgYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IHRyYW5zaXRpb24gdG8gaGFwcGVuIGJldHdl ZW4gdGhlIGV4cGVyaW1lbnRhbCBzcGFjZSBhbmQgdGhlIHByb2R1Y3Rpb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jmd0OyBvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDst d2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVk XSBXaGF0IGFib3V0IGFkZGluZyB0aGlzIE5FVyB0ZXh0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBTb21lIExJ U1AgZXh0ZW5zaW9ucyB0aGF0IG1ha2UgdXNlIG9mIHRoZSBMSVNQIHNoYXJlZCBleHRlbnNpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UgdHlwZSBt YXkgYmVjb21lIGVsaWdpYmxlIGZvciBhbiBhc3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoU2VjdGlvbiA1LjEpLiZuYnNw OyZuYnNwO09uY2UgYSBMSVNQIHBhY2tldCB0eXBlIGlzIGFzc2lnbmVkIHRvIHN1Y2ggTElTUDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZXh0ZW5zaW9uLCBhbiBp bXBsZW1lbnRhdGlvbiBTSE9VTEQgTk9UIHVzZSB0aGUgTElTUCBzaGFyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV4dGVuc2lvbiBtZXNzYWdlIHR5cGUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgVG8gZW5zdXJlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgZHVy aW5nIGEgdHJhbnNpdGlvbiBwZXJpb2QsIGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbiBNQVkgc3VwcG9ydCBhIGNvbmZpZ3VyYXRpb24g cGFyYW1ldGVyIHRvIGluc3RydWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyB3aGV0aGVyIHRoZSBMSVNQIGV4dGVuc2lvbiB1c2luZyB0aGUgc2hhcmVkIGV4dGVu c2lvbiBtZXNzYWdlIGlzIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBiZSBzZW50IHNpbXVsdGFuZW91c2x5IHdpdGggdGhlIExJU1AgZXh0ZW5zaW9uIG1lc3Nh Z2UgdXNpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBh c3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlLiZuYnNwOyZuYnNwO1RoZSBkZWZhdWx0IHZhbHVlIG9m IHRoYXQgY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgcGFyYW1ldGVyIGlzIHRvIGRpc2FibGUgc2VuZGluZyBib3RoIG1lc3NhZ2VzLiZuYnNw OyZuYnNwO1RoZSB1c2Ugb2YgdGhlIHR3bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgbWVzc2FnZSBmb3JtYXRzIGluY3JlYXNlcyBiYWNrd2FyZCBjb21wYXRpYmls aXR5LCBidXQgaXQgaGFzIHNvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGltcGxpY2F0aW9ucyBvbiB0aGUgTElTUCBjb250cm9sIGxvYWQuJm5ic3A7Jm5ic3A7 U3VjaCBpbXBsaWNhdGlvbnMgYXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBleHBlY3RlZCB0byBiZSBsaW1pdGVkIGluIHRpbWUgYW5kIGFyZSBmdWxseSB1bmRl ciB0aGUgY29udHJvbCBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGVudGl0eSBvcGVyYXRpbmcgYSBMSVNQIGRvbWFpbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_497B4C1BCAB6469B8467F7A7A08847FFciscocom_-- From nobody Tue Jan 31 06:54:38 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796CF129452; Tue, 31 Jan 2017 06:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.953 X-Spam-Level: X-Spam-Status: No, score=-6.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEHAaWPPqdrp; Tue, 31 Jan 2017 06:54:34 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5871289C4; Tue, 31 Jan 2017 06:54:34 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 8C48620246; Tue, 31 Jan 2017 15:54:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 2F3AD2006D; Tue, 31 Jan 2017 15:54:32 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Tue, 31 Jan 2017 15:54:31 +0100 From: To: "Alvaro Retana (aretana)" , "Joel M. Halpern" , The IESG Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) Thread-Index: AQHSe0JH5ob8Pa3wVEiqCGQJZUoVcaFRfwYAgACmHiCAAJG4AP//8AyA Date: Tue, 31 Jan 2017 14:54:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DEB2F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DEB012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <497B4C1B-CAB6-469B-8467-F7A7A08847FF@cisco.com> In-Reply-To: <497B4C1B-CAB6-469B-8467-F7A7A08847FF@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DEB2F4OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-type-iana@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 14:54:36 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DEB2F4OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDog QWx2YXJvIFJldGFuYSAoYXJldGFuYSkgW21haWx0bzphcmV0YW5hQGNpc2NvLmNvbV0NCkVudm95 w6kgOiBtYXJkaSAzMSBqYW52aWVyIDIwMTcgMTU6MjkNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQg SU1UL09MTjsgSm9lbCBNLiBIYWxwZXJuOyBUaGUgSUVTRw0KQ2MgOiBkcmFmdC1pZXRmLWxpc3At dHlwZS1pYW5hQGlldGYub3JnOyBMdWlnaSBJYW5ub25lOyBsaXNwLWNoYWlyc0BpZXRmLm9yZzsg bGlzcEBpZXRmLm9yZw0KT2JqZXQgOiBSZTogQWx2YXJvIFJldGFuYSdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wNDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0K TWVkOg0KDQpIaSENCg0KSeKAmWxsIGNsZWFyIG15IERJU0NVU1Mgb25jZSB0aGUgcmVzcG9uc2li bGUgQUQgY29uZmlybXMgdGhlIHN0YXR1cyBhbmQgY2hhbmdlcyB0aGUgZGF0YXRyYWNrZXIuICBK dXN0IG9uZSBtb3JlIHRoaW5nLCBJIHN0aWxsIHRoaW5rIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91 bGQgVXBkYXRlIHJmYzY4MzAgYmVjYXVzZSBldmVuIHRob3VnaCBpdCBkaWRu4oCZdCBkZWZpbmUg YSByZWdpc3RyeSwgaXQgZG9lcyBzYXkgdGhhdCBpdCBpcyDigJx0aGUgYXV0aG9yaXRhdGl2ZSBz b3VyY2UgZm9yIGFsbG9jYXRpbmcgTElTUCBUeXBlIHZhbHVlc+KAnS4gW1RoaXMgaXMgYSBtaW5v ciBwb2ludCBrbm93aW5nIHRoYXQgcmZjNjgzMGJpcy9yZmM2ODMzYmlzIHNob3VsZCBzb29uIHJl bmRlciByZmM2ODMwIE9ic29sZXRlLg0KDQpbTWVkXSBJdCBtYWtlcyBzZW5zZSB0byBhZGQgYW4g 4oCcVXBkYXRl4oCdIGhlYWRlciB0byB0aGlzIGRvY3VtZW50LiBVbmxlc3MgdGhlcmUgaXMgb2Jq ZWN0aW9uLCBJIHdpbGwgYWRkIHRoaXMgY2hhbmdlLg0KDQpGV0lXLCBldmVuIHRob3VnaCB0aGUg SUVURiBMYXN0IENhbGwgd2FzIG1hZGUgYXNzdW1pbmcgYSBQcm9wb3NlZCBTdGFuZGFyZCwgSSBk b27igJl0IHNlZSB0aGUgbmVlZCB0byByZXJ1biBpdC4gIEJ1dCB0aGF0IGlzIHVwIHRvIHRoZSBy ZXNwb25zaWJsZSBBRC4NCg0KDQpBYm91dCB0aGUgdGV4dCB5b3UgcHJvcG9zZWQgYmVsb3figKYg IFRoZSBMSVNQIFBhY2tldCBUeXBlIFJlZ2lzdHJ5ICg0LjEsIG5vdCA1LjEpIGhhcyBvbmx5IDE1 IHBvc3NpYmxlIHZhbHVlcywgNyBvZiB3aGljaCBhcmUgYXNzaWduZWQvcmVzZXJ2ZWQgYnkgdGhp cyBkb2N1bWVudCwgcmZjNjgzM2JpcyBhc3NpZ25zIDMgbW9yZSB2YWx1ZXMsIGFuZCB0aGlzIGRv Y3VtZW50IG1lbnRpb25zIDUgcG90ZW50aWFsIGV4dGVuc2lvbnMgKOKAnG5ldyBtZXNzYWdlIHR5 cGVzIGFyZSBwcm9wb3NlZCBpbiBbSS1ELmlldGYtbGlzcC1kZHRdLCBbSS1ELnpoYW8tbGlzcC1t bi1leHRlbnNpb25dLCBbSS1ELmJvdWNhZGFpci1saXNwLWJ1bGtdLCBbSS1ELmVybWFnYW4tbGlz cC1uYXQtdHJhdmVyc2FsXSwgb3IgW0ktRC5ib3VjYWRhaXItbGlzcC1zdWJzY3JpYmVd4oCdIFsq XSnigKZicmluZ2luZyB0aGUgdG90YWwgdXAgdG8gMTUuICBFdmVuIGlmIG5vdCBhbGwgdGhlc2Ug bmV3IGRyYWZ0cyBtYWtlIGl0LCB0aGUgTElTUCBQYWNrZXQgVHlwZSBSZWdpc3RyeSB3aWxsIHNv b24gaGF2ZSBubyBtb3JlIHZhbHVlcyB0byBhc3NpZ24uICBUaGUgcmVzdWx0IHdpbGwgYmUgdGhh dCB0aGUgU3ViLVR5cGVzIChpbiB0aGUgTElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgVHlw ZSkgd2lsbCBiZSB1c2VkIGZvciBwcm9kdWN0aW9uIFsxXS4NCg0KW01lZF0gQWdyZWUuDQoNCklP VywgSSBkb27igJl0IHRoaW5rIHlvdSBuZWVkIGEgdHJhbnNpdGlvbiBtZWNoYW5pc20uICBJbnN0 ZWFkLCBJIHRoaW5rIHlvdSBuZWVkIHRvIHJlY29nbml6ZSB0aGF0IHRoZSBTdWItVHlwZXMgd2ls bCBiZSB1c2VkIGZvciBwcm9kdWN0aW9uIGRlcGxveW1lbnRzLiAgU3VnZ2VzdGlvbjogIGNvbnNp ZGVyIGNoYW5naW5nIHRoZSByZWdpc3RyYXRpb24gcG9saWN5IGZyb20gRkNGUyB0byBzb21ldGhp bmcgd2hlcmUgcGFydCBvZiB0aGUgc3BhY2UgcmVxdWlyZXMgU3RhbmRhcmRzIEFjdGlvbiwgb3Ig bWF5YmUgUkZDIFJlcXVpcmVkIG9yIGV2ZW4gRXhwZXJ0IFJldmlldy4gIFRoZSByZXN1bHQgb2Yg RkNGUyBpcyB0aGF0IGFueW9uZSBjYW4gcmVxdWVzdCBhIHZhbHVlIGFuZCBnZXQgaXQ6IOKAnFRo ZXJlIGlzIG5vIHN1YnN0YW50aXZlIHJldmlldyBvZiB0aGUgcmVxdWVzdCwgb3RoZXIgdGhhbiB0 byBlbnN1cmUgdGhhdCBpdCBpcyB3ZWxsLWZvcm1lZCBhbmQgZG9lc24ndCBkdXBsaWNhdGUgYW4g ZXhpc3RpbmcgYXNzaWdubWVudC7igJ0gW3JmYzUyMjZdDQoNCltNZWRdIFRoZSBtb3RpdmF0aW9u IGZvciB1c2luZyBGQ0ZTIGlzIHRvIGF2b2lkIGltcG9zaW5nIGhlYXZ5IGNvbnN0cmFpbnRzIG9u IGRlc2lnbmVycyB0byByZWdpc3RlciB0aGVpciBleHRlbnNpb25zLiBBbHNvLCBnaXZlbiB0aGF0 IHdlIGhhdmUgNDA5NiBzdWItdHlwZSB2YWx1ZXMsIHRoZSBmdWxsIHJhbmdlIGNhbm5vdCBiZSBj b25zdW1lZCBjb21wbGV0ZWx5IGV2ZW4gd2l0aCBhIEZDRlMgcG9saWN5LiBUaGF04oCZcyBzYWlk LCBJIGFncmVlIHdpdGggeW91IGl0IG1pZ2h0IGJlIG1vcmUgc2FmZSB0byBzZWN1cmUgYSByYW5n ZSBmb3IgYXNzaWdubWVudHMgdmlhIFN0YW5kYXJkcyBBY3Rpb24gKGUuZy4sIDAtMTAyMykgYW5k IGxlYXZlIHRoZSAxMDI0LTQwOTUgZm9yIEZDRlMuIEkgY2FuIG1ha2Ugc3VjaCBjaGFuZ2UuDQoN CkkgZGlkbuKAmXQgbWFrZSB0aGlzIGxhc3QgcG9pbnQgYSBESVNDVVNTIGJlY2F1c2UgdGhlIGRv Y3VtZW50IHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgV0cgYW5kIHdlbnQgdGhyb3VnaCBJ RVRGIExDLCBidXQgSSB0aGluayBpdCBpcyBub3QgYSBnb29kIGlkZWEgdG8gbGVhdmUgdGhlIFN1 Yi1UeXBlcyByZWdpc3RyeSBhcyBpcy4NCg0KVGhhbmtzIQ0KQWx2YXJvLg0KDQoNClsqXSBCVFcs IEkgZG9u4oCZdCB0aGluayBpdCBpcyBuZWNlc3NhcnkgZm9yIHlvdSB0byBsaXN0IHRoZXNlIGRy YWZ0cyBzaW5jZSBzb21lIG9mIHRoZW0gbWF5IGNoYW5nZSBvciBub3QgbWFrZSBpdCBhbGwgdGhl IHdheSB0byBwdWJsaWNhdGlvbi4gIFRoZSBqdXN0aWZpY2F0aW9uIG9mIGdlbmVyaWMgbmV3IHdv cmsgc2hvdWxkIGJlIGVub3VnaC4NCg0KWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvbGlzcC9jdXJyZW50L21zZzA2NDU5Lmh0bWwNCg0KT24gMS8zMS8xNywgMzoxMiBB TSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBD T01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IGEuIFRoZSBJbnRyb2R1Y3Rpb24ganVzdGlm aWVzIHRoZSBleHRlbnNpb24gYXMgYmVpbmcgdXNlZCBmb3INCj4gZXhwZXJpbWVudHM6ICJCZWNh dXNlIG9mIHRoZSBsaW1pdGVkIHR5cGUgc3BhY2UgW1JGQzY4MzBdIGFuZCB0aGUgbmVlZA0KdG8N Cj4gY29uZHVjdCBleHBlcmltZW50cyB0byBhc3Nlc3MgbmV3IExJU1AgZXh0ZW5zaW9ucywgdGhp cyBkb2N1bWVudA0KPiBzcGVjaWZpZXMgYSBzaGFyZWQgTElTUCBleHRlbnNpb24gbWVzc2FnZSB0 eXBlIi4gIEl0IHNlZW1zIGNsZWFyIGxhdGVyDQppbg0KPiB0aGUgdGV4dCB0aGF0IHRoZSBpbnRl bnQgb2YgdGhlIG5ldyBtZXNzYWdlIHR5cGUgaXMgbm90IGp1c3QgZm9yDQo+IGV4cGVyaW1lbnRh dGlvbiwgYnV0IHRoYXQgaW4gZmFjdCB0aGUgaW50ZW50IGlzIGZvciBuZXcgZnVuY3Rpb25hbGl0 eSB0bw0KPiBiZSBkZXBsb3llZCB1c2luZyBpdC4gIElzIHRoYXQgY29ycmVjdD8gIElmIGl0IGlz LCB0aGVuIHBsZWFzZSBtYWtlIGl0DQo+IGNsZWFyIC0tIGlmIG5vdCwgdGhlbiBJIHdvdWxkIGxp a2UgdG8gc2VlIGhvdyB0aGUgYXV0aG9ycyBwcm9wb3NlIGENCj4gdHJhbnNpdGlvbiB0byBoYXBw ZW4gYmV0d2VlbiB0aGUgZXhwZXJpbWVudGFsIHNwYWNlIGFuZCB0aGUgcHJvZHVjdGlvbg0KPiBv bmUuDQoNCltNZWRdIFdoYXQgYWJvdXQgYWRkaW5nIHRoaXMgTkVXIHRleHQ6DQoNCiAgIFNvbWUg TElTUCBleHRlbnNpb25zIHRoYXQgbWFrZSB1c2Ugb2YgdGhlIExJU1Agc2hhcmVkIGV4dGVuc2lv bg0KICAgbWVzc2FnZSB0eXBlIG1heSBiZWNvbWUgZWxpZ2libGUgZm9yIGFuIGFzc2lnbmVkIExJ U1AgcGFja2V0IHR5cGUNCiAgIChTZWN0aW9uIDUuMSkuICBPbmNlIGEgTElTUCBwYWNrZXQgdHlw ZSBpcyBhc3NpZ25lZCB0byBzdWNoIExJU1ANCiAgIGV4dGVuc2lvbiwgYW4gaW1wbGVtZW50YXRp b24gU0hPVUxEIE5PVCB1c2UgdGhlIExJU1Agc2hhcmVkDQogICBleHRlbnNpb24gbWVzc2FnZSB0 eXBlLg0KDQogICBUbyBlbnN1cmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBkdXJpbmcgYSB0cmFu c2l0aW9uIHBlcmlvZCwgYW4NCiAgIGltcGxlbWVudGF0aW9uIE1BWSBzdXBwb3J0IGEgY29uZmln dXJhdGlvbiBwYXJhbWV0ZXIgdG8gaW5zdHJ1Y3QNCiAgIHdoZXRoZXIgdGhlIExJU1AgZXh0ZW5z aW9uIHVzaW5nIHRoZSBzaGFyZWQgZXh0ZW5zaW9uIG1lc3NhZ2UgaXMgdG8NCiAgIGJlIHNlbnQg c2ltdWx0YW5lb3VzbHkgd2l0aCB0aGUgTElTUCBleHRlbnNpb24gbWVzc2FnZSB1c2luZyB0aGUN CiAgIGFzc2lnbmVkIExJU1AgcGFja2V0IHR5cGUuICBUaGUgZGVmYXVsdCB2YWx1ZSBvZiB0aGF0 IGNvbmZpZ3VyYXRpb24NCiAgIHBhcmFtZXRlciBpcyB0byBkaXNhYmxlIHNlbmRpbmcgYm90aCBt ZXNzYWdlcy4gIFRoZSB1c2Ugb2YgdGhlIHR3bw0KICAgbWVzc2FnZSBmb3JtYXRzIGluY3JlYXNl cyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBidXQgaXQgaGFzIHNvbWUNCiAgIGltcGxpY2F0aW9u cyBvbiB0aGUgTElTUCBjb250cm9sIGxvYWQuICBTdWNoIGltcGxpY2F0aW9ucyBhcmUNCiAgIGV4 cGVjdGVkIHRvIGJlIGxpbWl0ZWQgaW4gdGltZSBhbmQgYXJlIGZ1bGx5IHVuZGVyIHRoZSBjb250 cm9sIG9mIHRoZQ0KICAgZW50aXR5IG9wZXJhdGluZyBhIExJU1AgZG9tYWluLg0KDQo= --_000_787AE7BB302AE849A7480A190F8B933009DEB2F4OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9u dC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgQWx2YXJv LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBs ZWFzZSBzZWUgaW5saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIFtt YWlsdG86YXJldGFuYUBjaXNjby5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFy ZGkgMzEgamFudmllciAyMDE3IDE1OjI5PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIg TW9oYW1lZCBJTVQvT0xOOyBKb2VsIE0uIEhhbHBlcm47IFRoZSBJRVNHPGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBkcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hQGlldGYub3JnOyBMdWlnaSBJYW5ub25l OyBsaXNwLWNoYWlyc0BpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7 OjwvYj4gUmU6IEFsdmFybyBSZXRhbmEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbGlzcC10eXBl LWlhbmEtMDQ6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+TWVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPknigJlsbCBjbGVhciBteSBESVND VVNTIG9uY2UgdGhlIHJlc3BvbnNpYmxlIEFEIGNvbmZpcm1zIHRoZSBzdGF0dXMgYW5kIGNoYW5n ZXMgdGhlIGRhdGF0cmFja2VyLiZuYnNwOyBKdXN0IG9uZSBtb3JlIHRoaW5nLCBJIHN0aWxsIHRo aW5rIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91bGQNCiBVcGRhdGUgcmZjNjgzMCBiZWNhdXNlIGV2 ZW4gdGhvdWdoIGl0IGRpZG7igJl0IGRlZmluZSBhIHJlZ2lzdHJ5LCBpdCBkb2VzIHNheSB0aGF0 IGl0IGlzIOKAnHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSBmb3IgYWxsb2NhdGluZyBMSVNQIFR5 cGUgdmFsdWVz4oCdLiBbVGhpcyBpcyBhIG1pbm9yIHBvaW50IGtub3dpbmcgdGhhdCByZmM2ODMw YmlzL3JmYzY4MzNiaXMgc2hvdWxkIHNvb24gcmVuZGVyIHJmYzY4MzAgT2Jzb2xldGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEl0IG1h a2VzIHNlbnNlIHRvIGFkZCBhbiDigJxVcGRhdGXigJ0gaGVhZGVyIHRvIHRoaXMgZG9jdW1lbnQu IFVubGVzcyB0aGVyZSBpcyBvYmplY3Rpb24sIEkgd2lsbCBhZGQgdGhpcyBjaGFuZ2UuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5GV0lXLCBldmVuIHRob3VnaCB0aGUgSUVURiBMYXN0IENhbGwgd2FzIG1hZGUgYXNzdW1p bmcgYSBQcm9wb3NlZCBTdGFuZGFyZCwgSSBkb27igJl0IHNlZSB0aGUgbmVlZCB0byByZXJ1biBp dC4mbmJzcDsgQnV0IHRoYXQgaXMgdXAgdG8gdGhlIHJlc3BvbnNpYmxlIEFELjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFib3V0IHRoZSB0ZXh0IHlvdSBwcm9w b3NlZCBiZWxvd+KApiZuYnNwOyBUaGUgTElTUCBQYWNrZXQgVHlwZSBSZWdpc3RyeSAoNC4xLCBu b3QgNS4xKSBoYXMgb25seSAxNSBwb3NzaWJsZSB2YWx1ZXMsIDcgb2Ygd2hpY2ggYXJlIGFzc2ln bmVkL3Jlc2VydmVkIGJ5IHRoaXMgZG9jdW1lbnQsDQogcmZjNjgzM2JpcyBhc3NpZ25zIDMgbW9y ZSB2YWx1ZXMsIGFuZCB0aGlzIGRvY3VtZW50IG1lbnRpb25zIDUgcG90ZW50aWFsIGV4dGVuc2lv bnMgKOKAnG5ldyBtZXNzYWdlIHR5cGVzIGFyZSBwcm9wb3NlZCBpbiBbSS1ELmlldGYtbGlzcC1k ZHRdLCBbSS1ELnpoYW8tbGlzcC1tbi1leHRlbnNpb25dLCBbSS1ELmJvdWNhZGFpci1saXNwLWJ1 bGtdLCBbSS1ELmVybWFnYW4tbGlzcC1uYXQtdHJhdmVyc2FsXSwgb3IgW0ktRC5ib3VjYWRhaXIt bGlzcC1zdWJzY3JpYmVd4oCdDQogWypdKeKApmJyaW5naW5nIHRoZSB0b3RhbCB1cCB0byAxNS4m bmJzcDsgRXZlbiBpZiBub3QgYWxsIHRoZXNlIG5ldyBkcmFmdHMgbWFrZSBpdCwgdGhlIExJU1Ag UGFja2V0IFR5cGUgUmVnaXN0cnkgd2lsbCBzb29uIGhhdmUgbm8gbW9yZSB2YWx1ZXMgdG8gYXNz aWduLiZuYnNwOyBUaGUgcmVzdWx0IHdpbGwgYmUgdGhhdCB0aGUgU3ViLVR5cGVzIChpbiB0aGUg TElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgVHlwZSkgd2lsbCBiZSB1c2VkIGZvciBwcm9k dWN0aW9uDQogWzFdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5bTWVkXSBBZ3JlZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklPVywgSSBkb27igJl0IHRoaW5rIHlvdSBu ZWVkIGEgdHJhbnNpdGlvbiBtZWNoYW5pc20uJm5ic3A7IEluc3RlYWQsIEkgdGhpbmsgeW91IG5l ZWQgdG8gcmVjb2duaXplIHRoYXQgdGhlIFN1Yi1UeXBlcyB3aWxsIGJlIHVzZWQgZm9yIHByb2R1 Y3Rpb24gZGVwbG95bWVudHMuJm5ic3A7IFN1Z2dlc3Rpb246Jm5ic3A7DQogY29uc2lkZXIgY2hh bmdpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwb2xpY3kgZnJvbSBGQ0ZTIHRvIHNvbWV0aGluZyB3aGVy ZSBwYXJ0IG9mIHRoZSBzcGFjZSByZXF1aXJlcyBTdGFuZGFyZHMgQWN0aW9uLCBvciBtYXliZSBS RkMgUmVxdWlyZWQgb3IgZXZlbiBFeHBlcnQgUmV2aWV3LiZuYnNwOyBUaGUgcmVzdWx0IG9mIEZD RlMgaXMgdGhhdCBhbnlvbmUgY2FuIHJlcXVlc3QgYSB2YWx1ZSBhbmQgZ2V0IGl0OiDigJxUaGVy ZSBpcyBubyBzdWJzdGFudGl2ZSByZXZpZXcNCiBvZiB0aGUgcmVxdWVzdCwgb3RoZXIgdGhhbiB0 byBlbnN1cmUgdGhhdCBpdCBpcyB3ZWxsLWZvcm1lZCBhbmQgZG9lc24ndCBkdXBsaWNhdGUgYW4g ZXhpc3RpbmcgYXNzaWdubWVudC7igJ0gW3JmYzUyMjZdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhlIG1vdGl2YXRpb24gZm9yIHVz aW5nIEZDRlMgaXMgdG8gYXZvaWQgaW1wb3NpbmcgaGVhdnkgY29uc3RyYWludHMgb24gZGVzaWdu ZXJzIHRvIHJlZ2lzdGVyIHRoZWlyIGV4dGVuc2lvbnMuIEFsc28sIGdpdmVuIHRoYXQgd2UgaGF2 ZSA0MDk2IHN1Yi10eXBlDQogdmFsdWVzLCB0aGUgZnVsbCByYW5nZSBjYW5ub3QgYmUgY29uc3Vt ZWQgY29tcGxldGVseSBldmVuIHdpdGggYSBGQ0ZTIHBvbGljeS4gVGhhdOKAmXMgc2FpZCwgSSBh Z3JlZSB3aXRoIHlvdSBpdCBtaWdodCBiZSBtb3JlIHNhZmUgdG8gc2VjdXJlIGEgcmFuZ2UgZm9y IGFzc2lnbm1lbnRzIHZpYSBTdGFuZGFyZHMgQWN0aW9uIChlLmcuLCAwLTEwMjMpIGFuZCBsZWF2 ZSB0aGUgMTAyNC00MDk1IGZvciBGQ0ZTLiBJIGNhbiBtYWtlIHN1Y2ggY2hhbmdlLg0KICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkkgZGlkbuKAmXQgbWFrZSB0aGlzIGxhc3QgcG9pbnQgYSBESVNDVVNTIGJlY2F1 c2UgdGhlIGRvY3VtZW50IHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgV0cgYW5kIHdlbnQg dGhyb3VnaCBJRVRGIExDLCBidXQgSSB0aGluayBpdCBpcyBub3QgYSBnb29kIGlkZWEgdG8gbGVh dmUNCiB0aGUgU3ViLVR5cGVzIHJlZ2lzdHJ5IGFzIGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+WypdIEJUVywgSSBkb27igJl0IHRoaW5rIGl0IGlzIG5lY2Vzc2Fy eSBmb3IgeW91IHRvIGxpc3QgdGhlc2UgZHJhZnRzIHNpbmNlIHNvbWUgb2YgdGhlbSBtYXkgY2hh bmdlIG9yIG5vdCBtYWtlIGl0IGFsbCB0aGUgd2F5IHRvIHB1YmxpY2F0aW9uLiZuYnNwOyBUaGUg anVzdGlmaWNhdGlvbg0KIG9mIGdlbmVyaWMgbmV3IHdvcmsgc2hvdWxkIGJlIGVub3VnaC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5bMV0NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bGlzcC9jdXJyZW50L21zZzA2NDU5Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvbGlzcC9jdXJyZW50L21zZzA2NDU5Lmh0bWw8L2E+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAxLzMxLzE3LCAzOjEyIEFNLCAm cXVvdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21h cmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4 dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxicj4NCiZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtp dC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jmd0OyBDT01NRU5UOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTotd2Vi a2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7IGEu IFRoZSBJbnRyb2R1Y3Rpb24ganVzdGlmaWVzIHRoZSBleHRlbnNpb24gYXMgYmVpbmcgdXNlZCBm b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRh cmQ7Y29sb3I6YmxhY2siPiZndDsgZXhwZXJpbWVudHM6ICZxdW90O0JlY2F1c2Ugb2YgdGhlIGxp bWl0ZWQgdHlwZSBzcGFjZSBbUkZDNjgzMF0gYW5kIHRoZSBuZWVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj50bzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+Jmd0OyBjb25kdWN0IGV4cGVyaW1lbnRzIHRvIGFzc2VzcyBuZXcgTElTUCBl eHRlbnNpb25zLCB0aGlzIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7IHNwZWNpZmllcyBhIHNo YXJlZCBMSVNQIGV4dGVuc2lvbiBtZXNzYWdlIHR5cGUmcXVvdDsuJm5ic3A7Jm5ic3A7SXQgc2Vl bXMgY2xlYXIgbGF0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Oi13 ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPmluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7IHRoZSB0ZXh0 IHRoYXQgdGhlIGludGVudCBvZiB0aGUgbmV3IG1lc3NhZ2UgdHlwZSBpcyBub3QganVzdCBmb3I8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7 Y29sb3I6YmxhY2siPiZndDsgZXhwZXJpbWVudGF0aW9uLCBidXQgdGhhdCBpbiBmYWN0IHRoZSBp bnRlbnQgaXMgZm9yIG5ldyBmdW5jdGlvbmFsaXR5IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7IGJlIGRl cGxveWVkIHVzaW5nIGl0LiZuYnNwOyZuYnNwO0lzIHRoYXQgY29ycmVjdD8mbmJzcDsmbmJzcDtJ ZiBpdCBpcywgdGhlbiBwbGVhc2UgbWFrZSBpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jmd0OyBjbGVhciAtLSBp ZiBub3QsIHRoZW4gSSB3b3VsZCBsaWtlIHRvIHNlZSBob3cgdGhlIGF1dGhvcnMgcHJvcG9zZSBh PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJk O2NvbG9yOmJsYWNrIj4mZ3Q7IHRyYW5zaXRpb24gdG8gaGFwcGVuIGJldHdlZW4gdGhlIGV4cGVy aW1lbnRhbCBzcGFjZSBhbmQgdGhlIHByb2R1Y3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZndDsgb25lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5bTWVkXSBXaGF0 IGFib3V0IGFkZGluZyB0aGlzIE5FVyB0ZXh0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IFNvbWUgTElTUCBleHRlbnNpb25zIHRoYXQgbWFrZSB1c2Ugb2YgdGhlIExJU1Ag c2hhcmVkIGV4dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UgdHlwZSBt YXkgYmVjb21lIGVsaWdpYmxlIGZvciBhbiBhc3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgKFNlY3Rpb24gNS4xKS4mbmJzcDsmbmJzcDtPbmNlIGEgTElT UCBwYWNrZXQgdHlwZSBpcyBhc3NpZ25lZCB0byBzdWNoIExJU1A8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBleHRlbnNpb24sIGFuIGltcGxlbWVudGF0aW9uIFNIT1VMRCBOT1QgdXNlIHRoZSBM SVNQIHNoYXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtp dC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV4dGVuc2lvbiBtZXNzYWdlIHR5 cGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUbyBlbnN1 cmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBkdXJpbmcgYSB0cmFuc2l0aW9uIHBlcmlvZCwgYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbiBNQVkgc3VwcG9ydCBhIGNv bmZpZ3VyYXRpb24gcGFyYW1ldGVyIHRvIGluc3RydWN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgd2hldGhlciB0aGUgTElTUCBleHRlbnNpb24gdXNpbmcgdGhlIHNoYXJlZCBleHRlbnNpb24g bWVzc2FnZSBpcyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGJlIHNlbnQgc2ltdWx0YW5l b3VzbHkgd2l0aCB0aGUgTElTUCBleHRlbnNpb24gbWVzc2FnZSB1c2luZyB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBhc3NpZ25lZCBMSVNQIHBhY2tldCB0eXBlLiZuYnNwOyZuYnNwO1Ro ZSBkZWZhdWx0IHZhbHVlIG9mIHRoYXQgY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IHBhcmFtZXRlciBpcyB0byBkaXNhYmxlIHNlbmRpbmcgYm90aCBtZXNzYWdlcy4mbmJz cDsmbmJzcDtUaGUgdXNlIG9mIHRoZSB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtZXNz YWdlIGZvcm1hdHMgaW5jcmVhc2VzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGJ1dCBpdCBoYXMg c29tZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFu ZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGltcGxpY2F0aW9ucyBvbiB0aGUgTElTUCBj b250cm9sIGxvYWQuJm5ic3A7Jm5ic3A7U3VjaCBpbXBsaWNhdGlvbnMgYXJlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgZXhwZWN0ZWQgdG8gYmUgbGltaXRlZCBpbiB0aW1lIGFuZCBhcmUgZnVs bHkgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZW50 aXR5IG9wZXJhdGluZyBhIExJU1AgZG9tYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933009DEB2F4OPEXCLILMA3corp_-- From nobody Tue Jan 31 10:20:19 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF612948D; Tue, 31 Jan 2017 10:20:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148588681781.5931.5789753426219165597.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 10:20:17 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-type-iana@ietf.org, lisp@ietf.org Subject: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-type-iana-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 18:20:18 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-lisp-type-iana-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am watching for resolution of Alvaro's Discuss points. I'm also really curious about point a in his Comments. That would be good to unravel. From nobody Tue Jan 31 14:48:46 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04476129BF1; Tue, 31 Jan 2017 14:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NrGvuyKG9fG; Tue, 31 Jan 2017 14:48:38 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21646129602; Tue, 31 Jan 2017 14:48:38 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v0VMPPuP029048; Tue, 31 Jan 2017 17:32:27 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 28b273jg3y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Jan 2017 17:32:26 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0VMWPBh018373; Tue, 31 Jan 2017 17:32:26 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0VMWE3H018126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jan 2017 17:32:18 -0500 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 31 Jan 2017 22:31:54 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.162]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0319.002; Tue, 31 Jan 2017 17:31:54 -0500 From: "BRUNGARD, DEBORAH A" To: "Alvaro Retana (aretana)" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , The IESG Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) Thread-Index: AQHSe0JJ7WytcF1RiUGa51VGz/FcdKFR45sAgACtOACAAGklAIAAL2bw Date: Tue, 31 Jan 2017 22:31:53 +0000 Message-ID: References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DEB012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <497B4C1B-CAB6-469B-8467-F7A7A08847FF@cisco.com> In-Reply-To: <497B4C1B-CAB6-469B-8467-F7A7A08847FF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.228.242] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C85DE6278CMISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-31_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701310179 Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-type-iana@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 22:48:40 -0000 --_000_F64C10EAA68C8044B33656FA214632C85DE6278CMISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpBcyB5b3Ugbm90ZWQsIHRoZSBkb2N1bWVudOKAmXMgc3RhdHVzIHdhcyBj aGFuZ2VkIGZyb20gUFMgdG8gRXhwZXJpbWVudGFsIGJhc2VkIG9uIHRoZSBSVEcgRGlyZWN0b3Jh dGUgUmV2aWV3LiBJ4oCZdmUgY2hhbmdlZCBpdCBvbiBkYXRhdHJhY2tlciAobWlzc2VkIGl0KS4g QWdyZWUsIG5vIG5lZWQgdG8gcmVydW4gTGFzdCBDYWxsIGZvciB0aGlzLg0KDQpUaGFua3MsDQpE ZWJvcmFoDQoNCg0KRnJvbTogaWVzZyBbbWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5 IDMxLCAyMDE3IDk6MjkgQU0NClRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBKb2Vs IE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz4NCkNjOiBMdWlnaSBJYW5ub25lIDxnZ3hAZ2lnaXgubmV0PjsgbGlzcC1jaGFpcnNAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmFAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBBbHZhcm8gUmV0YW5hJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWxpc3AtdHlw ZS1pYW5hLTA0OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpNZWQ6DQoNCkhpIQ0KDQpJ 4oCZbGwgY2xlYXIgbXkgRElTQ1VTUyBvbmNlIHRoZSByZXNwb25zaWJsZSBBRCBjb25maXJtcyB0 aGUgc3RhdHVzIGFuZCBjaGFuZ2VzIHRoZSBkYXRhdHJhY2tlci4gIEp1c3Qgb25lIG1vcmUgdGhp bmcsIEkgc3RpbGwgdGhpbmsgdGhhdCB0aGlzIGRvY3VtZW50IHNob3VsZCBVcGRhdGUgcmZjNjgz MCBiZWNhdXNlIGV2ZW4gdGhvdWdoIGl0IGRpZG7igJl0IGRlZmluZSBhIHJlZ2lzdHJ5LCBpdCBk b2VzIHNheSB0aGF0IGl0IGlzIOKAnHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSBmb3IgYWxsb2Nh dGluZyBMSVNQIFR5cGUgdmFsdWVz4oCdLiBbVGhpcyBpcyBhIG1pbm9yIHBvaW50IGtub3dpbmcg dGhhdCByZmM2ODMwYmlzL3JmYzY4MzNiaXMgc2hvdWxkIHNvb24gcmVuZGVyIHJmYzY4MzAgT2Jz b2xldGUuDQoNCkZXSVcsIGV2ZW4gdGhvdWdoIHRoZSBJRVRGIExhc3QgQ2FsbCB3YXMgbWFkZSBh c3N1bWluZyBhIFByb3Bvc2VkIFN0YW5kYXJkLCBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIHRvIHJl cnVuIGl0LiAgQnV0IHRoYXQgaXMgdXAgdG8gdGhlIHJlc3BvbnNpYmxlIEFELg0KDQoNCkFib3V0 IHRoZSB0ZXh0IHlvdSBwcm9wb3NlZCBiZWxvd+KApiAgVGhlIExJU1AgUGFja2V0IFR5cGUgUmVn aXN0cnkgKDQuMSwgbm90IDUuMSkgaGFzIG9ubHkgMTUgcG9zc2libGUgdmFsdWVzLCA3IG9mIHdo aWNoIGFyZSBhc3NpZ25lZC9yZXNlcnZlZCBieSB0aGlzIGRvY3VtZW50LCByZmM2ODMzYmlzIGFz c2lnbnMgMyBtb3JlIHZhbHVlcywgYW5kIHRoaXMgZG9jdW1lbnQgbWVudGlvbnMgNSBwb3RlbnRp YWwgZXh0ZW5zaW9ucyAo4oCcbmV3IG1lc3NhZ2UgdHlwZXMgYXJlIHByb3Bvc2VkIGluIFtJLUQu aWV0Zi1saXNwLWRkdF0sIFtJLUQuemhhby1saXNwLW1uLWV4dGVuc2lvbl0sIFtJLUQuYm91Y2Fk YWlyLWxpc3AtYnVsa10sIFtJLUQuZXJtYWdhbi1saXNwLW5hdC10cmF2ZXJzYWxdLCBvciBbSS1E LmJvdWNhZGFpci1saXNwLXN1YnNjcmliZV3igJ0gWypdKeKApmJyaW5naW5nIHRoZSB0b3RhbCB1 cCB0byAxNS4gIEV2ZW4gaWYgbm90IGFsbCB0aGVzZSBuZXcgZHJhZnRzIG1ha2UgaXQsIHRoZSBM SVNQIFBhY2tldCBUeXBlIFJlZ2lzdHJ5IHdpbGwgc29vbiBoYXZlIG5vIG1vcmUgdmFsdWVzIHRv IGFzc2lnbi4gIFRoZSByZXN1bHQgd2lsbCBiZSB0aGF0IHRoZSBTdWItVHlwZXMgKGluIHRoZSBM SVNQIFNoYXJlZCBFeHRlbnNpb24gTWVzc2FnZSBUeXBlKSB3aWxsIGJlIHVzZWQgZm9yIHByb2R1 Y3Rpb24gWzFdLg0KDQpJT1csIEkgZG9u4oCZdCB0aGluayB5b3UgbmVlZCBhIHRyYW5zaXRpb24g bWVjaGFuaXNtLiAgSW5zdGVhZCwgSSB0aGluayB5b3UgbmVlZCB0byByZWNvZ25pemUgdGhhdCB0 aGUgU3ViLVR5cGVzIHdpbGwgYmUgdXNlZCBmb3IgcHJvZHVjdGlvbiBkZXBsb3ltZW50cy4gIFN1 Z2dlc3Rpb246ICBjb25zaWRlciBjaGFuZ2luZyB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSBmcm9t IEZDRlMgdG8gc29tZXRoaW5nIHdoZXJlIHBhcnQgb2YgdGhlIHNwYWNlIHJlcXVpcmVzIFN0YW5k YXJkcyBBY3Rpb24sIG9yIG1heWJlIFJGQyBSZXF1aXJlZCBvciBldmVuIEV4cGVydCBSZXZpZXcu ICBUaGUgcmVzdWx0IG9mIEZDRlMgaXMgdGhhdCBhbnlvbmUgY2FuIHJlcXVlc3QgYSB2YWx1ZSBh bmQgZ2V0IGl0OiDigJxUaGVyZSBpcyBubyBzdWJzdGFudGl2ZSByZXZpZXcgb2YgdGhlIHJlcXVl c3QsIG90aGVyIHRoYW4gdG8gZW5zdXJlIHRoYXQgaXQgaXMgd2VsbC1mb3JtZWQgYW5kIGRvZXNu J3QgZHVwbGljYXRlIGFuIGV4aXN0aW5nIGFzc2lnbm1lbnQu4oCdIFtyZmM1MjI2XQ0KDQpJIGRp ZG7igJl0IG1ha2UgdGhpcyBsYXN0IHBvaW50IGEgRElTQ1VTUyBiZWNhdXNlIHRoZSBkb2N1bWVu dCB3YXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gdGhlIFdHIGFuZCB3ZW50IHRocm91Z2ggSUVURiBM QywgYnV0IEkgdGhpbmsgaXQgaXMgbm90IGEgZ29vZCBpZGVhIHRvIGxlYXZlIHRoZSBTdWItVHlw ZXMgcmVnaXN0cnkgYXMgaXMuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNClsqXSBCVFcsIEkg ZG9u4oCZdCB0aGluayBpdCBpcyBuZWNlc3NhcnkgZm9yIHlvdSB0byBsaXN0IHRoZXNlIGRyYWZ0 cyBzaW5jZSBzb21lIG9mIHRoZW0gbWF5IGNoYW5nZSBvciBub3QgbWFrZSBpdCBhbGwgdGhlIHdh eSB0byBwdWJsaWNhdGlvbi4gIFRoZSBqdXN0aWZpY2F0aW9uIG9mIGdlbmVyaWMgbmV3IHdvcmsg c2hvdWxkIGJlIGVub3VnaC4NCg0KWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbGlzcC9jdXJyZW50L21zZzA2NDU5Lmh0bWwNCg0KT24gMS8zMS8xNywgMzoxMiBBTSwg Im1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01N RU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IGEuIFRoZSBJbnRyb2R1Y3Rpb24ganVzdGlmaWVz IHRoZSBleHRlbnNpb24gYXMgYmVpbmcgdXNlZCBmb3INCj4gZXhwZXJpbWVudHM6ICJCZWNhdXNl IG9mIHRoZSBsaW1pdGVkIHR5cGUgc3BhY2UgW1JGQzY4MzBdIGFuZCB0aGUgbmVlZA0KdG8NCj4g Y29uZHVjdCBleHBlcmltZW50cyB0byBhc3Nlc3MgbmV3IExJU1AgZXh0ZW5zaW9ucywgdGhpcyBk b2N1bWVudA0KPiBzcGVjaWZpZXMgYSBzaGFyZWQgTElTUCBleHRlbnNpb24gbWVzc2FnZSB0eXBl Ii4gIEl0IHNlZW1zIGNsZWFyIGxhdGVyDQppbg0KPiB0aGUgdGV4dCB0aGF0IHRoZSBpbnRlbnQg b2YgdGhlIG5ldyBtZXNzYWdlIHR5cGUgaXMgbm90IGp1c3QgZm9yDQo+IGV4cGVyaW1lbnRhdGlv biwgYnV0IHRoYXQgaW4gZmFjdCB0aGUgaW50ZW50IGlzIGZvciBuZXcgZnVuY3Rpb25hbGl0eSB0 bw0KPiBiZSBkZXBsb3llZCB1c2luZyBpdC4gIElzIHRoYXQgY29ycmVjdD8gIElmIGl0IGlzLCB0 aGVuIHBsZWFzZSBtYWtlIGl0DQo+IGNsZWFyIC0tIGlmIG5vdCwgdGhlbiBJIHdvdWxkIGxpa2Ug dG8gc2VlIGhvdyB0aGUgYXV0aG9ycyBwcm9wb3NlIGENCj4gdHJhbnNpdGlvbiB0byBoYXBwZW4g YmV0d2VlbiB0aGUgZXhwZXJpbWVudGFsIHNwYWNlIGFuZCB0aGUgcHJvZHVjdGlvbg0KPiBvbmUu DQoNCltNZWRdIFdoYXQgYWJvdXQgYWRkaW5nIHRoaXMgTkVXIHRleHQ6DQoNCiAgIFNvbWUgTElT UCBleHRlbnNpb25zIHRoYXQgbWFrZSB1c2Ugb2YgdGhlIExJU1Agc2hhcmVkIGV4dGVuc2lvbg0K ICAgbWVzc2FnZSB0eXBlIG1heSBiZWNvbWUgZWxpZ2libGUgZm9yIGFuIGFzc2lnbmVkIExJU1Ag cGFja2V0IHR5cGUNCiAgIChTZWN0aW9uIDUuMSkuICBPbmNlIGEgTElTUCBwYWNrZXQgdHlwZSBp cyBhc3NpZ25lZCB0byBzdWNoIExJU1ANCiAgIGV4dGVuc2lvbiwgYW4gaW1wbGVtZW50YXRpb24g U0hPVUxEIE5PVCB1c2UgdGhlIExJU1Agc2hhcmVkDQogICBleHRlbnNpb24gbWVzc2FnZSB0eXBl Lg0KDQogICBUbyBlbnN1cmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBkdXJpbmcgYSB0cmFuc2l0 aW9uIHBlcmlvZCwgYW4NCiAgIGltcGxlbWVudGF0aW9uIE1BWSBzdXBwb3J0IGEgY29uZmlndXJh dGlvbiBwYXJhbWV0ZXIgdG8gaW5zdHJ1Y3QNCiAgIHdoZXRoZXIgdGhlIExJU1AgZXh0ZW5zaW9u IHVzaW5nIHRoZSBzaGFyZWQgZXh0ZW5zaW9uIG1lc3NhZ2UgaXMgdG8NCiAgIGJlIHNlbnQgc2lt dWx0YW5lb3VzbHkgd2l0aCB0aGUgTElTUCBleHRlbnNpb24gbWVzc2FnZSB1c2luZyB0aGUNCiAg IGFzc2lnbmVkIExJU1AgcGFja2V0IHR5cGUuICBUaGUgZGVmYXVsdCB2YWx1ZSBvZiB0aGF0IGNv bmZpZ3VyYXRpb24NCiAgIHBhcmFtZXRlciBpcyB0byBkaXNhYmxlIHNlbmRpbmcgYm90aCBtZXNz YWdlcy4gIFRoZSB1c2Ugb2YgdGhlIHR3bw0KICAgbWVzc2FnZSBmb3JtYXRzIGluY3JlYXNlcyBi YWNrd2FyZCBjb21wYXRpYmlsaXR5LCBidXQgaXQgaGFzIHNvbWUNCiAgIGltcGxpY2F0aW9ucyBv biB0aGUgTElTUCBjb250cm9sIGxvYWQuICBTdWNoIGltcGxpY2F0aW9ucyBhcmUNCiAgIGV4cGVj dGVkIHRvIGJlIGxpbWl0ZWQgaW4gdGltZSBhbmQgYXJlIGZ1bGx5IHVuZGVyIHRoZSBjb250cm9s IG9mIHRoZQ0KICAgZW50aXR5IG9wZXJhdGluZyBhIExJU1AgZG9tYWluLg0KDQo= --_000_F64C10EAA68C8044B33656FA214632C85DE6278CMISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGkgQWx2YXJvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QXMgeW91IG5vdGVkLCB0aGUgZG9jdW1lbnTigJlzIHN0YXR1cyB3YXMgY2hhbmdlZCBm cm9tIFBTIHRvIEV4cGVyaW1lbnRhbCBiYXNlZCBvbiB0aGUgUlRHIERpcmVjdG9yYXRlIFJldmll dy4gSeKAmXZlIGNoYW5nZWQgaXQgb24gZGF0YXRyYWNrZXIgKG1pc3NlZCBpdCkuIEFncmVlLA0K IG5vIG5lZWQgdG8gcmVydW4gTGFzdCBDYWxsIGZvciB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EZWJvcmFo PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGllc2cgW21haWx0bzppZXNnLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsdmFybyBSZXRhbmEgKGFyZXRh bmEpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTcgOToyOSBBTTxi cj4NCjxiPlRvOjwvYj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSm9lbCBNLiBIYWxw ZXJuICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OzsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWlnaSBJYW5ub25lICZsdDtnZ3hAZ2lnaXgubmV0Jmd0 OzsgbGlzcC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmFAaWV0Zi5v cmc7IGxpc3BAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEFsdmFybyBSZXRhbmEn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEtMDQ6ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5NZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5J4oCZbGwgY2xlYXIgbXkgRElTQ1VTUyBvbmNlIHRoZSByZXNwb25zaWJsZSBBRCBjb25maXJt cyB0aGUgc3RhdHVzIGFuZCBjaGFuZ2VzIHRoZSBkYXRhdHJhY2tlci4mbmJzcDsgSnVzdCBvbmUg bW9yZSB0aGluZywgSSBzdGlsbCB0aGluayB0aGF0IHRoaXMgZG9jdW1lbnQgc2hvdWxkIFVwZGF0 ZSByZmM2ODMwDQogYmVjYXVzZSBldmVuIHRob3VnaCBpdCBkaWRu4oCZdCBkZWZpbmUgYSByZWdp c3RyeSwgaXQgZG9lcyBzYXkgdGhhdCBpdCBpcyDigJx0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2Ug Zm9yIGFsbG9jYXRpbmcgTElTUCBUeXBlIHZhbHVlc+KAnS4gW1RoaXMgaXMgYSBtaW5vciBwb2lu dCBrbm93aW5nIHRoYXQgcmZjNjgzMGJpcy9yZmM2ODMzYmlzIHNob3VsZCBzb29uIHJlbmRlciBy ZmM2ODMwIE9ic29sZXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GV0lXLCBldmVuIHRob3VnaCB0aGUgSUVU RiBMYXN0IENhbGwgd2FzIG1hZGUgYXNzdW1pbmcgYSBQcm9wb3NlZCBTdGFuZGFyZCwgSSBkb27i gJl0IHNlZSB0aGUgbmVlZCB0byByZXJ1biBpdC4mbmJzcDsgQnV0IHRoYXQgaXMgdXAgdG8gdGhl IHJlc3BvbnNpYmxlIEFELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFib3V0IHRoZSB0ZXh0 IHlvdSBwcm9wb3NlZCBiZWxvd+KApiZuYnNwOyBUaGUgTElTUCBQYWNrZXQgVHlwZSBSZWdpc3Ry eSAoNC4xLCBub3QgNS4xKSBoYXMgb25seSAxNSBwb3NzaWJsZSB2YWx1ZXMsIDcgb2Ygd2hpY2gg YXJlIGFzc2lnbmVkL3Jlc2VydmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHJmYzY4MzNiaXMNCiBhc3Np Z25zIDMgbW9yZSB2YWx1ZXMsIGFuZCB0aGlzIGRvY3VtZW50IG1lbnRpb25zIDUgcG90ZW50aWFs IGV4dGVuc2lvbnMgKOKAnG5ldyBtZXNzYWdlIHR5cGVzIGFyZSBwcm9wb3NlZCBpbiBbSS1ELmll dGYtbGlzcC1kZHRdLCBbSS1ELnpoYW8tbGlzcC1tbi1leHRlbnNpb25dLCBbSS1ELmJvdWNhZGFp ci1saXNwLWJ1bGtdLCBbSS1ELmVybWFnYW4tbGlzcC1uYXQtdHJhdmVyc2FsXSwgb3IgW0ktRC5i b3VjYWRhaXItbGlzcC1zdWJzY3JpYmVd4oCdDQogWypdKeKApmJyaW5naW5nIHRoZSB0b3RhbCB1 cCB0byAxNS4mbmJzcDsgRXZlbiBpZiBub3QgYWxsIHRoZXNlIG5ldyBkcmFmdHMgbWFrZSBpdCwg dGhlIExJU1AgUGFja2V0IFR5cGUgUmVnaXN0cnkgd2lsbCBzb29uIGhhdmUgbm8gbW9yZSB2YWx1 ZXMgdG8gYXNzaWduLiZuYnNwOyBUaGUgcmVzdWx0IHdpbGwgYmUgdGhhdCB0aGUgU3ViLVR5cGVz IChpbiB0aGUgTElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgVHlwZSkgd2lsbCBiZSB1c2Vk IGZvciBwcm9kdWN0aW9uDQogWzFdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JT1csIEkgZG9u4oCZdCB0aGlu ayB5b3UgbmVlZCBhIHRyYW5zaXRpb24gbWVjaGFuaXNtLiZuYnNwOyBJbnN0ZWFkLCBJIHRoaW5r IHlvdSBuZWVkIHRvIHJlY29nbml6ZSB0aGF0IHRoZSBTdWItVHlwZXMgd2lsbCBiZSB1c2VkIGZv ciBwcm9kdWN0aW9uIGRlcGxveW1lbnRzLiZuYnNwOyBTdWdnZXN0aW9uOiZuYnNwOyBjb25zaWRl cg0KIGNoYW5naW5nIHRoZSByZWdpc3RyYXRpb24gcG9saWN5IGZyb20gRkNGUyB0byBzb21ldGhp bmcgd2hlcmUgcGFydCBvZiB0aGUgc3BhY2UgcmVxdWlyZXMgU3RhbmRhcmRzIEFjdGlvbiwgb3Ig bWF5YmUgUkZDIFJlcXVpcmVkIG9yIGV2ZW4gRXhwZXJ0IFJldmlldy4mbmJzcDsgVGhlIHJlc3Vs dCBvZiBGQ0ZTIGlzIHRoYXQgYW55b25lIGNhbiByZXF1ZXN0IGEgdmFsdWUgYW5kIGdldCBpdDog 4oCcVGhlcmUgaXMgbm8gc3Vic3RhbnRpdmUgcmV2aWV3IG9mIHRoZQ0KIHJlcXVlc3QsIG90aGVy IHRoYW4gdG8gZW5zdXJlIHRoYXQgaXQgaXMgd2VsbC1mb3JtZWQgYW5kIGRvZXNuJ3QgZHVwbGlj YXRlIGFuIGV4aXN0aW5nIGFzc2lnbm1lbnQu4oCdIFtyZmM1MjI2XQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkkgZGlkbuKAmXQgbWFrZSB0aGlzIGxhc3QgcG9pbnQgYSBESVNDVVNTIGJlY2F1c2UgdGhlIGRv Y3VtZW50IHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgV0cgYW5kIHdlbnQgdGhyb3VnaCBJ RVRGIExDLCBidXQgSSB0aGluayBpdCBpcyBub3QgYSBnb29kIGlkZWEgdG8gbGVhdmUgdGhlIFN1 Yi1UeXBlcw0KIHJlZ2lzdHJ5IGFzIGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bKl0gQlRXLCBJIGRvbuKA mXQgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IGZvciB5b3UgdG8gbGlzdCB0aGVzZSBkcmFmdHMgc2lu Y2Ugc29tZSBvZiB0aGVtIG1heSBjaGFuZ2Ugb3Igbm90IG1ha2UgaXQgYWxsIHRoZSB3YXkgdG8g cHVibGljYXRpb24uJm5ic3A7IFRoZSBqdXN0aWZpY2F0aW9uIG9mIGdlbmVyaWMgbmV3DQogd29y ayBzaG91bGQgYmUgZW5vdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bMV0NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbGlzcC9jdXJyZW50L21zZzA2NDU5Lmh0bWwi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbGlzcC9jdXJyZW50L21zZzA2 NDU5Lmh0bWw8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8zMS8xNywgMzoxMiBBTSwgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5z OiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxicj4NCiZndDsgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9y OmJsYWNrIj4mZ3Q7IENPTU1FTlQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZndDsg YS4gVGhlIEludHJvZHVjdGlvbiBqdXN0aWZpZXMgdGhlIGV4dGVuc2lvbiBhcyBiZWluZyB1c2Vk IGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj4mZ3Q7IGV4cGVyaW1lbnRzOiAmcXVvdDtCZWNhdXNlIG9mIHRoZSBsaW1pdGVkIHR5cGUg c3BhY2UgW1JGQzY4MzBdIGFuZCB0aGUgbmVlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj50bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7IGNvbmR1Y3QgZXhwZXJpbWVudHMg dG8gYXNzZXNzIG5ldyBMSVNQIGV4dGVuc2lvbnMsIHRoaXMgZG9jdW1lbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jmd0OyBzcGVjaWZp ZXMgYSBzaGFyZWQgTElTUCBleHRlbnNpb24gbWVzc2FnZSB0eXBlJnF1b3Q7LiZuYnNwOyZuYnNw O0l0IHNlZW1zIGNsZWFyIGxhdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7Y29sb3I6YmxhY2siPmluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJr aXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZndDsgdGhlIHRleHQgdGhhdCB0aGUgaW50ZW50IG9m IHRoZSBuZXcgbWVzc2FnZSB0eXBlIGlzIG5vdCBqdXN0IGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7IGV4cGVyaW1lbnRhdGlv biwgYnV0IHRoYXQgaW4gZmFjdCB0aGUgaW50ZW50IGlzIGZvciBuZXcgZnVuY3Rpb25hbGl0eSB0 bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNr Ij4mZ3Q7IGJlIGRlcGxveWVkIHVzaW5nIGl0LiZuYnNwOyZuYnNwO0lzIHRoYXQgY29ycmVjdD8m bmJzcDsmbmJzcDtJZiBpdCBpcywgdGhlbiBwbGVhc2UgbWFrZSBpdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mZ3Q7IGNsZWFyIC0tIGlm IG5vdCwgdGhlbiBJIHdvdWxkIGxpa2UgdG8gc2VlIGhvdyB0aGUgYXV0aG9ycyBwcm9wb3NlIGE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+ Jmd0OyB0cmFuc2l0aW9uIHRvIGhhcHBlbiBiZXR3ZWVuIHRoZSBleHBlcmltZW50YWwgc3BhY2Ug YW5kIHRoZSBwcm9kdWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3Rh bmRhcmQ7Y29sb3I6YmxhY2siPiZndDsgb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+W01lZF0g V2hhdCBhYm91dCBhZGRpbmcgdGhpcyBORVcgdGV4dDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJr aXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU29tZSBMSVNQIGV4 dGVuc2lvbnMgdGhhdCBtYWtlIHVzZSBvZiB0aGUgTElTUCBzaGFyZWQgZXh0ZW5zaW9uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBtZXNzYWdlIHR5cGUgbWF5IGJlY29tZSBlbGlnaWJsZSBmb3IgYW4gYXNzaWduZWQg TElTUCBwYWNrZXQgdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgKFNlY3Rpb24gNS4xKS4mbmJzcDsmbmJzcDtP bmNlIGEgTElTUCBwYWNrZXQgdHlwZSBpcyBhc3NpZ25lZCB0byBzdWNoIExJU1A8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGV4dGVuc2lvbiwgYW4gaW1wbGVtZW50YXRpb24gU0hPVUxEIE5PVCB1c2UgdGhlIExJU1Ag c2hhcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBleHRlbnNpb24gbWVzc2FnZSB0eXBlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IFRvIGVuc3VyZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGR1cmluZyBhIHRyYW5zaXRp b24gcGVyaW9kLCBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJk O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gTUFZIHN1cHBvcnQgYSBj b25maWd1cmF0aW9uIHBhcmFtZXRlciB0byBpbnN0cnVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgd2hldGhlciB0 aGUgTElTUCBleHRlbnNpb24gdXNpbmcgdGhlIHNoYXJlZCBleHRlbnNpb24gbWVzc2FnZSBpcyB0 bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgYmUgc2VudCBzaW11bHRhbmVvdXNseSB3aXRoIHRoZSBMSVNQIGV4dGVu c2lvbiBtZXNzYWdlIHVzaW5nIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0 LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYXNzaWduZWQgTElTUCBwYWNrZXQg dHlwZS4mbmJzcDsmbmJzcDtUaGUgZGVmYXVsdCB2YWx1ZSBvZiB0aGF0IGNvbmZpZ3VyYXRpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IHBhcmFtZXRlciBpcyB0byBkaXNhYmxlIHNlbmRpbmcgYm90aCBtZXNzYWdl cy4mbmJzcDsmbmJzcDtUaGUgdXNlIG9mIHRoZSB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UgZm9y bWF0cyBpbmNyZWFzZXMgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgYnV0IGl0IGhhcyBzb21lPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBpbXBsaWNhdGlvbnMgb24gdGhlIExJU1AgY29udHJvbCBsb2FkLiZuYnNwOyZu YnNwO1N1Y2ggaW1wbGljYXRpb25zIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Vi a2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZXhwZWN0ZWQgdG8gYmUgbGlt aXRlZCBpbiB0aW1lIGFuZCBhcmUgZnVsbHkgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBlbnRpdHkgb3BlcmF0aW5nIGEgTElTUCBkb21haW4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F64C10EAA68C8044B33656FA214632C85DE6278CMISOUT7MSGUSRDE_-- From nobody Tue Jan 31 15:06:28 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEE7129631; Tue, 31 Jan 2017 15:06:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148590398407.5919.13527961652406614746.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 15:06:24 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-type-iana@ietf.org, lisp@ietf.org Subject: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-type-iana-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 23:06:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lisp-type-iana-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 4.1, last paragraph: I'm confused by the statement that "15" is reserved for experimental use. The table says it's reserved for the LISP Shared Extension Message. I recognize that that message is in fact experimental, but I would interpret "reserved for experimental use" to indicate things that people can use for other experimental purpose. - (nit) Abstract: Please expand LISP on first use in the abstract (in addition to the existing expansion in the introduction.)