From nobody Wed Aug 1 08:52:21 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E2129C6B; Wed, 1 Aug 2018 08:52:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 08:52:14 -0700 Archived-At: Subject: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 15:52:15 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-16: 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-anima-autonomic-control-plane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 6.10.4: "The value of the Interface Identifier is left for future definitions." I don't understand how this is usable without some definition. I.e., if I assign every interface ID in my ACP to be 0, it's not going to work. Could you elaborate about what is expected in this field? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General: Please address the Gen-ART reviewer's latest round of comments. There are a bunch of places in this document where it seems like there is a tension between specifying a limited set of functionality here and being able to support a wider variety of deployment scenarios. This is noted in Section 1 but I think in general it would be clearer if uses of the term "future" throughout the document could be more surgical as well as more specific about whether they mean "people might deploy this differently in the future" or "standards would need to be developed in the future." I've made a few suggestions about some of these turns of phrase below but would suggest someone do a full edit pass with this in mind because there are a large number of mentions of "future work." Of course there is always more work to do, but every bit of "future work" need not be mentioned in this document, and in cases where it is mentioned I think there should be a specific reason for doing so that bears on people implementing this specification. I don't think this fits in the DISCUSS criteria but for a document that intends to be published on the standards track I would expect it to be crisper about the dividing line between the normative behavior being specified here versus changes or extensions that may or may not be made in the future. "Intent" is used both capitalized and in lower case throughout the document and I'm unclear if this is meant to signify a distinction or not. Section 2: Please remove the -->"..."() notation. Please use the exact boilerplate from RFC 8174, not a variation. It seems like RFC citations should appear for IKEv2 and DTLS upon first use in this section. Otherwise, it seems they are first cited at different future points in the document (Section 6.3 and 6.7, respectively). Section 3.3: "The ACP provides reachability that is independent of the Data-Plane (except for the dependency discussed in Section 6.12.2 which can be removed through future work)," Isn't this kind of a big exception, given that there is meant to be a secure channel between pairs of nodes in the ACP and that developing future encapsulations is non-trivial? It seems like phrasing this the other way around (the ACP is dependent on the Data-Plane for but is otherwise independent of it) would be more accurate. Section 6: "Indestructible" seems like an overstatement. Maybe "resilient" would be more accurate? Section 6.1.1: s/Such methods are subject to future work though./No such methods have been defined at the time of publication of this document./ s/to build ACP channel/to build ACP channels/ s/that intends to be equally unique/that it intends to be equally unique/ ""rsub" is optional; its syntax is defined in this document, but its semantics are for further study. Understanding the benefits of using rsub may depend on the results of future work on enhancing routing for the ACP." What is the point of defining this now when it is unclear if or how it will be used? There are already means for nodes to do error handling, so it seems like defining a new field in the future if/when it is needed would work fine and be cleaner. Appendix A.7 seems to assume some semantics for this field, which makes the way it is specified here even more confusing IMO. "In this specification, the "acp-address" field is REQUIRED, but future variations (see Appendix A.8) may use local information to derive the ACP address. In this case, "acp-address" could be empty. Such a variation would be indicated by an appropriate "extension". If "acp-address" is empty, and "rsub" is empty too, the "local-part" will have the format "rfcSELF + + extension(s)". The two plus characters are necessary so the node can unambiguously parse that both "acp-address" and "rsub" are empty." This seems contradictory. Either "acp-address" is REQUIRED in which case there are no exceptions, or it's not; if it's not, then the expected syntax for cases when it's not present should be specified. Section 6.1.2: s/If the node certificates indicates/If the node certificate indicates/ Section 6.3: It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. Section 6.4: This is a good example of a section where the blurring between the specified behavior and expectations for the future is unhelpful IMO. Why specify the current default and then spend a lot of words (including Appendix A.7) talking about how it will be different in the future? Section 6.10.3.1: s/We do not think this is required at this point/This is not currently required/ Section 6.12.2: s/may specify additional layer 2 or layer encapsulations/may specify additional layer 2 or layer 3 encapsulations/ (I think?) Section 8.2.1: This seems extraneous: "Future work could transform this into a YANG ([RFC7950]) data model." Appendix A.8: "Secure channels may even be replaced by simple neighbor authentication to create simplified ACP variations for environments where no real security is required but just protection against non-malicious misconfiguration." I think experience has shown that even environments where it is assumed that security is not required prove to need it. I would suggest removing this text or changing this implication. From nobody Wed Aug 1 08:55:14 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59DF130DD2; Wed, 1 Aug 2018 08:55:11 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=XBgiRqTM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KHGiC8Mk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kRbzLHXvbeb; Wed, 1 Aug 2018 08:55:09 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426C1129C6B; Wed, 1 Aug 2018 08:55:09 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 7A9D02A8; Wed, 1 Aug 2018 11:55:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 01 Aug 2018 11:55:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=fbcn86PEoBELKHHad1zlmzDNnGdH9 fw3oLWMBRH1ttY=; b=XBgiRqTMG/1eRrb/mYNOrJutKDtUA0tZ5m9mYNlOxNJ3O ZOKkT4yAenWWGdLWcd6S2Y4qFu46eccf2RcJ3PzCMJZdFfUJmxp2IhfquTkCK4IM mNm2THA/ZS2f5JVtnejTT1hj4zsr61Xtk4PS9OiZqUtyRvUyNGU7EvOrcmkYz5dj cUIPcfBJMjzEl09YMoKMoFwZtq8NDadjP9IkbZnhAZqi9RM0WhUfbUkbs+NEDTup KZsMMQucHhxs+EHIvnZFoPoYMT6lNA7+Yq05tkzfUghRIH/7qQULkhgIn3bRHNgM XRzEtdeH9R+85tXjy4wxZ9lJfFjyjw7iTtj0ZIaVw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=fbcn86 PEoBELKHHad1zlmzDNnGdH9fw3oLWMBRH1ttY=; b=KHGiC8Mkx+0QbZYhkkmMBc BFPzHso/j86Pk8p5OkCxptYhBpl2qvi01gUgm6Ub/i0Cy1og/VXQbg3PfgRfkQ2S +Zgtq9BJMbSHni7uRkg9wkGpVcn/LA2IHQqv1gBsqpLERGJ/iBpNMp/Bwul9sDKD D/3ZbtmW87NzgR34juqXH0wvTs6xYUemoaSUhIRnK+/Qja8VyRe88WxnrRX7bzm/ MBf/xlAWlFUNsQmXs9CGhJw+EPB6xAbCfkA4nRdTO9VurxHassHyoqjZ2KPwTPZi mRi5aZf9iCx6Hr5fNNypejcuSVt9loJ9jEPzmVVIoIyJB8lwmAPkEiew1mI9P4pg == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 3902FE4519; Wed, 1 Aug 2018 11:55:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <153308194697.3384.1689302422182872423@ietfa.amsl.com> Date: Wed, 1 Aug 2018 11:55:04 -0400 Cc: General Area Review Team , draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <49D2BE17-A2E1-486A-BA72-9F85603858A2@cooperw.in> References: <153308194697.3384.1689302422182872423@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-autonomic-control-plane-16 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 15:55:12 -0000 Elwyn, thanks for your reviews. Authors/editors, thanks for addressing = Elwyn=E2=80=99s previous comments. I have pointed to his latest round in = my ballot. I balloted DISCUSS based on one point in Section 6.10.4. Alissa > On Jul 31, 2018, at 8:05 PM, Elwyn Davies = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Ready with Nits >=20 > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-anima-autonomic-control-plane-16 > Reviewer: Elwyn Davies > Review Date: 2018-07-31 > IETF LC End Date: 2018-02-26 > IESG Telechat date: 2018-08-02 >=20 > Summary: > This document is ready but has a fair number of nits still to fix, = particularly > in the earlier part of the document. There are also some language = issues to > address which the RFC Editor will deal with. My issues from the Last = Call > review have been addressed. >=20 > Major issues: > None >=20 > Minor issues: > None >=20 > Nits/editorial comments: > General: There are three remaining examples of "intent" rather than = "Intent". >=20 > General: There are five instances of the construction -> "quoted text" = () in > s2. Need to remove -> and () in each case. This may be down to tool = problems - > there is a comment in the revisions list. >=20 > S1, para 5: s/The ACP is designed to remains/The ACP is designed to = remain/ >=20 > s1, para 5: s/The details how this achieved are defined in Section = 6./The > details of how this achieved are described in Section 6./ >=20 > s1, bullet point #1: s/supports directly/directly supports/ >=20 > s1, bullet point #3: s/network/(Data-Plane) network/ > S1, last para: s/Defined Networking (SDN) (see [RFC7426]), style > automation/Defined Networking- (SDN-)style (see [RFC7426]) automation/ >=20 > S1.1, para 2: Operational Technology is a term that is not very = well-known - a > reference would help. Unfortunately it seems that the text of ISA99 = that > defines the term is not freely available. Suggestions of a freely = available > alternative? >=20 > s1.1, para 3: Although RPL is in the glossary in s2, this instance = occurs > before s2 is announced, so it would be worth adding RPL (Routing = Protocol for > Low-power and Lossy Networks - RFC6550) >=20 > s2, "ACP address": s/the ->"ACP domain certificate" ()./the "ACP = domain > certificate". >=20 > S2, "ACP Domain": 'of nodes with ->"ACP domain' . Remove "->" and ()? >=20 > s2. "ACP Loopback interface": Need to expand VRF on first use. >=20 > s2, "ACP secure channel": As wrtten this equates a security = association with a > secure channel. Suggest: NEW: ACP secure channel: A sequence of links > established hop-by-hop between adjacent ACP nodes with a security = association > established for each link using the ACP secure channel protocol and = the ACP > Domain Certificate. The channel is used to carry traffic of the ACP = VRF > separated from Data-Plane traffic in-band over the same links as the > Data-Plane. ENDS >=20 > s2, "Data-Plane": s/non-autonomic/by means other than autonomically/ >=20 > s2, "GRASP": s/required/REQUIRED/ >=20 > s2, "in-band (management)": fix up two instances of -> ... (). >=20 > s2, "Node-ID": s/bit/bits/; Due to a missing XML introducer, the = reference to > s6.10.5 hasn't been translated. >=20 > s2, "(virtual) out-of-band network": fix up one instance of -> ... (); = s/where > historically/were historically/; In next to last sentence s/out of > band/out-of-band/ >=20 > s2, "ULA": s/are the first 48 bit/is the first 48 bits/ >=20 > s2, "(ACP) Zone": s/protocols details/protocol's details/ >=20 > s3.1: s/This way/In this way/; possibly s/other processes/single = instamces of > other processes/??? >=20 > s3.2, last para: s/like/such as/ [like: Yuck!] >=20 > s3.3, para 1: s/managment/management/ >=20 > s3.3, first bullet: s/out of Band/out-of-Band/ >=20 > s4, ACP2: The phrase "(can block easily at edge)" needs additional = explanation. >=20 > s4, ACP4: s/generic. Usable/generic, that is it MUST/ >=20 > s4, last para: Need to expand eACP. >=20 > s5, 2nd 'Note' bullet: s/auto discovery/auto-discovery/ >=20 > s5, lata para: s/This way/In this way/ >=20 > s6.1, para 4: Trailing colon s/b period. >=20 > s6.1.1, last para on page 20: s/":" are not/The character ":" is not/ >=20 > s6.1.1, last but 2 para: s/information element it,/information > element,/(probably) >=20 > s6.1.2. next to last bullet: s/peers certificate/peer's certificate/; = s/peers > domain/peer's domain/ >=20 > s6.1.3.1, last para: Expand ttl on first use. >=20 > s6.1.3.5, para 4: s/ACP nodes domain certificate/ACP node's domain > certificate/; s/nodes ACP/node's ACP/ >=20 > s6.3, para 2: s/State Less/Stateless/ >=20 > s6.11.1.1, para 1: s/reliable network reasonably fast/reliable network = with > reasonably fast/ >=20 > s6.12: s/hop by hop/hop-by-hop/ >=20 > s8.2.1, bullets 2 and 3: s/vrf/VRF/ >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Aug 1 13:44:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD27130DC6; Wed, 1 Aug 2018 13:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX5-FvAV7pgY; Wed, 1 Aug 2018 13:44:52 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 30992130E6C; Wed, 1 Aug 2018 13:44:52 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id r5-v6so11396430pgv.0; Wed, 01 Aug 2018 13:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MxkVnUh9iuHgcM9f2z4/T/aTVmqGp/z4c4LRW9lfzyA=; b=LfqSVuysVmEwvo5KcMeRXdXKaIxznmB2aUpI9N+QB+HWUfNL1D3OeowqkOrXkT3lF4 wMoHCK4vUtUF8fMA3+NpcAxmOhMOLJjv/Bw9vzwc1OjI5T2v7jZ1+zN7AYIscmNpPVA6 pkDmQIM9laOgeDis7Hxz9/PWh2u9nTmlu17vmJpcMo4Rrikm2eeH10/us0ZFWN1VzyO7 vppQWGngBPoq23zfNSS3XecmFDlfD8lnSTBP6ffOkM1YeaJBYt3SQZFgKiSjdd/sRJlA 68FI2pCf84VNDisO8t9GZLIfHbE4v8AfzQBFGXU1JznO5Vxagr1p8GX+qZy+CX7z9fZd NxDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MxkVnUh9iuHgcM9f2z4/T/aTVmqGp/z4c4LRW9lfzyA=; b=VDRuwFMPhTU9vYEtkhuJcxztrdGFENkx7l3FuM0bGTDV5JNiafVN4kxiZ1dURgCqFv sJjdFl6INOgHFbNgiMfEFGvzSJyzZxCKBeBEqGUWmD33Dgl91FU8psLDngNwaBZ/br+n Kx094c4vzdutl1NSi4Clm7EEtBkOvwjjgrup3DM7VpNbnMVm1+4Bnt+IA/VMUf75ZiqV 72rQLXrrSa7nY11OZ7a8+3DbE+vhkYRN7dJMjIUStjtZ1RtTjpX6CS4ccbrD5SY0nl4g /f+RTQCO0YdEsoBqFAeNKumSGHoEVd9mD7kVEDe+E/WIPO1l18kZtl4m51tvxVcIzd0Q 22+g== X-Gm-Message-State: AOUpUlGwNziQiv5pAf+GSM/fNBpEqajWxcyr0B9lJLugvKRfkHmwtVRu CE0bLeNB4XXm27tUyeqaKfg= X-Google-Smtp-Source: AAOMgpf8nqjvk88e2rwt31YTXCu2mlyeyzGlfdsINyeOimOR4L/R/BxnIaYV6R+Wnajono4GXd5zBg== X-Received: by 2002:a62:e218:: with SMTP id a24-v6mr9601610pfi.75.1533156291782; Wed, 01 Aug 2018 13:44:51 -0700 (PDT) Received: from [192.168.178.30] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id s85-v6sm32531638pfa.116.2018.08.01.13.44.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 13:44:50 -0700 (PDT) To: Alissa Cooper , The IESG Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> Date: Thu, 2 Aug 2018 08:44:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 20:44:54 -0000 On 02/08/2018 03:52, Alissa Cooper wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 6.10.4: > > "The value of the Interface Identifier is left for future definitions." > > I don't understand how this is usable without some definition. I.e., if I > assign every interface ID in my ACP to be 0, it's not going to work. Could you > elaborate about what is expected in this field? > Why not: The value of the Interface Identifier SHOULD follow [RFC8064]. That would work fine and is a SHOULD to allow for alternatives if there's a good reason. Brian From nobody Wed Aug 1 15:17:12 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7CF130DF6; Wed, 1 Aug 2018 15:17:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153316182938.21806.17771248317633190020.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 15:17:09 -0700 Archived-At: Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-autonomic-control-plane-16: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 22:17:09 -0000 Ben Campbell has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-16: 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-anima-autonomic-control-plane/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: - I agree with Alissa's comment about "future" things. §4: What do the normative keywords in this section apply to? If this document fulfills the requirements, it seems odd to continue to state them normatively. Normally such keywords are intended for implementors and sometimes administrators; protocol requirements don't really fit the RFC 2119/8174 definitions. If you need to use them in a non 2119/8174 sense, please mention that somewhere. §4, ACP5: SHOULD is SHOULD. If it needs to be stronger than a normal SHOULD, consider a MUST. (But see my previous comment.) §6.1.1: I'm a bit surprised to see the syntax burn 7 characters on the literal RFC name. In §6.1.1, the statement "If the operator does not own any FQDN, it should choose a string (in FQDN format) that intends to be equally unique." seems problematic without further guidance about how to actuall make them "equally unique" For example, how does one ensure this does not collide with real FQDNs? §6.1.2: Please describe how one actually checks for cert validity (e.g. explicit field comparisons) In the second bullet, how does one check for private key ownership. If the answer is "PKI", then how does that requirement differ from the following one?) §6.1.3, first paragraph: The 2nd MUST seems like a statement of fact in light of the first MUST. §6.10.1, first bullet: Does this mean the address spaces can overlap? -- last bullet: "not expected to be an end-user device" and "stay within a domain (of trust)" are both tricky assumptions. Is there a mechanism to ensure the assumptions are not violated? Editorial Comments: - IDNits reports several outdated or unused references--please check. - General: Some sections are marked as "Normative", but there are unmarked sections with normative keywords in them. Please be consistent in such labeling. (Personally, I suggest not labeling sections this way unless you think they are more likely to be misunderstood than normal.) §1.1: Please expand "RPL" on first mention. §2, definition of MIC: Why include a definition to say you don't use it in the doc? Also, please use the boilerplate from 8174 rather than rolling your own. §3 and §4: Are these sections useful to the average reader not involved in the standards process? It seems like they might be better off in an appendix or even a wg wiki, especially considering the document length. §4: This section contains a lot of sentence fragments, which I suspect were intentional. Please use complete sentences when writing in paragraph form. §6.1: Paragraphs 2 and 3 contain comma splices. §6.1.3.4: "Certificate lifetime may be set to shorter lifetimes than customary (1 year) because certificate renewal is fully automated via ACP and EST. " Are you proposing setting it to one year, or are you suggesting one year is customary? §6.1.3.4, 2nd paragraph: "allowing to simplify" is grammatically incorrect. Consider "allowing [something] to simplify" or "allowing the simplification" §6.1.3.6: The first paragraph is hard to parse. Please do not use "/" as a shortcut for a conjunction. From nobody Wed Aug 1 16:12:54 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F4E130DC3; Wed, 1 Aug 2018 16:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnIh8x12ISzG; Wed, 1 Aug 2018 16:12:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF25126DBF; Wed, 1 Aug 2018 16:12:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B7D7820090; Wed, 1 Aug 2018 19:29:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0E75E201; Wed, 1 Aug 2018 19:12:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 09A781DA; Wed, 1 Aug 2018 19:12:42 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter , Alissa Cooper , The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com In-Reply-To: <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> References: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 23:12:45 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> --------------------------------------------------------------------= -- >> DISCUSS: >> --------------------------------------------------------------------= -- >>=20 >> Section 6.10.4: >>=20 >> "The value of the Interface Identifier is left for future definition= s." >>=20 >> I don't understand how this is usable without some definition. I.e.,= if I >> assign every interface ID in my ACP to be 0, it's not going to work.= Could you >> elaborate about what is expected in this field? >>=20 > Why not: > The value of the Interface Identifier SHOULD follow [RFC8064]. > That would work fine and is a SHOULD to allow for alternatives > if there's a good reason. The ACP addresses (including interface identifiers) are assigned by the ANI Registrar, and are embedded in certificates issued by the Registrar. Schemes 6.10.2 and 6.10.3 support this mechanism. Section 6.10.4 is about very much MANUAL allocation, which is basically a non-zero-touch backdoor which nobody is supposed to use, unless they aren= 't doing ANI stuff. Really, it's about the Registrar doing it's work (section 6.10.7), and the only reason to have any statements about addressing schemes is so that we c= an paint off some areas for manual allocation. (I didn't want any of these sch= emes here, I don't think it helps, but maybe it causes no harm). The explanation in 6.10.7.2 further allows for multiple Registrars to opera= te without coordinating via a centralized database (or blockchain). So, by all means, suggest an RFC8064 IID in the UI when configuring a manual address, but if the admin is even close to that part of the configuration, then they probably meant to do something very specific. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAltiPmkACgkQgItw+93Q 3WXJIAgArFG6bOiGModFeaE7IBnQRlZBoP/m74vXuR8TzOkb9heFr/GEO6Ttro9a OCsJoNrUDg1eezDlMY66SlZ63KpQNEDWTte4EpESxHDucFB9f4mUVBY+OTGx/M5u 408dhb5HgUko91eaQ+WS8uqh/saZZyzD4A+D0UVf4gE2o5hQC/M/K/q3tZTkaLk6 WPyV1EWIwKKiXsGxAz+r/DVD4kllUBpS56RRAA1ZDyjznMpL2dUGNLyz7dKoPJ/l Z2K0LMc0oOzjsyFqgE55nUZ9Nb+fHEyXAPa24EvLIc2FVX9zZRAgTBsDxsAuwAV0 TN7R4grH7KS98j09geXh7Fy2/U0bmw== =QPwk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 1 16:56:46 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF061310AF; Wed, 1 Aug 2018 16:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153316779818.21822.14156274165395996235.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 16:56:38 -0700 Archived-At: Subject: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 23:56:42 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-16: 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-anima-autonomic-control-plane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D9959 I found this document extremely hard to follow due to a large number of grammar errors. It really needs a very thorough copy-edit pass, which I believe is beyond the RFC-editor's usual process. Ideally, the WG would do this. DETAIL S 6.1.1. > each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN > of a DNS domain owned by the operator assigning the certificate. > This is a simple method to ensure that the domain is globally unique > and collision of ACP addresses would therefore only happen due to ULA > hash collisions. If the operator does not own any FQDN, it should > choose a string (in FQDN format) that intends to be equally unique. These rules do not seem to be strong enough. Unless you have disjoint trust anchors, there is a potential for cross-domain attac. S 6.1.2. > See section 4.2.1.6 of [RFC5280] for details on the subjectAltName > field. > > 6.1.2. ACP domain membership check > > The following points constitute the ACP domain membership check of a What is the relationship of these rules to the existing 5280 rules? S 6.1.2. > > o The peer has proved ownership of the private key associated with > the certifictes public key. > > o The peer's certificate is signed by one of the trust anchors > associated with the ACP domain certificate. So you don't allow chaining? It seems later that you say you do, but this language prohibits it. S 6.1.3.1. > The objective value "SRV.est" indicates that the objective is an > [RFC7030] compliant EST server because "est" is an [RFC6335] > registered service name for [RFC7030]. Future backward compatible > extensions/alternatives to [RFC7030] may be indicated through > objective-value. Future non-backward compatible certificate renewal > options must use a different objective-name. EST runs over HTTPS. What is the certificate that the server presents? S 6.4. > information in the ACP Adjacency table. > > The ACP is by default established exclusively between nodes in the > same domain. This includes all routing subdomains. Appendix A.7 > explains how ACP connections across multiple routing subdomains are > special. I must be missing something, but how do you know what the routing domain is of an ACP node? I don't see it in the message above. Is it in some common header? S 6.5. > > o Once the first secure channel protocol succeeds, the two peers > know each other's certificates because they must be used by all > secure channel protocols for mutual authentication. The node with > the lower Node-ID in the ACP address becomes Bob, the one with the > higher Node-ID in the certificate Alice. A ladder diagram would really help me here, because I'm confused about the order of events. As I understand it, Alice and Bob are both flooding their AN_ACP objectives. So, Alice sees Bob's and starts trying to connect to Bob. But Bob may not have Alice's objective, right? So, in the case you describe below, she just has to wait for it before she can try the remaining security protocols? I note that you have no downgrade defense on the meta-negotiation between the protocols, so an attacker could potentially force you down to the weakest joint protocol. Why did you not provide a defense here? S 6.7.1.1. > To run ACP via IPsec natively, no further IANA assignments/ > definitions are required. An ACP node that is supporting native > IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and > peer link-local IPv6 addresses used for encapsulation. It MUST then > support ESP with AES256 for encryption and SHA256 hash and MUST NOT > permit weaker crypto options. This is not sufficient to guarantee interop. Also, this is an odd cipher suite chioice. Why are you requiring AES-256 rather than AES-128? Why aren't you requiring AES-GCM? Why aren't you requiring specific key establishment methods (e.g., ECDHE with P-256...) S 6.7.2. > > To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP > port is used that is announced as a parameter in the GRASP AN_ACP > objective to candidate neighbors. All ACP nodes supporting DTLS as a > secure channel protocol MUST support AES256 encryption and MUST NOT > permit weaker crypto options. This is not sufficiently specific to guarantee interoperability. Which cipher suites? Also, why are you requiring AES-256 and not AES-128? S 6.7.3. > > A baseline ACP node MUST support IPsec natively and MAY support IPsec > via GRE. A constrained ACP node that can not support IPsec MUST > support DTLS. An ACP node connecting an area of constrained ACP > nodes with an area of baseline ACP nodes MUST therefore support IPsec > and DTLS and supports threefore the baseline and constrained profile. These MTIs do not provide interop between constrained and baseline nodes, because a baseline node might do IPsec and the constrained node DTLS. S 6.10.2. > hash of the routing subdomain SHOULD NOT be assumed by any ACP > node during normal operations. The hash function is only executed > during the creation of the certificate. If BRSKI is used then the > BRSKI registrar will create the domain information field in > response to the EST Certificate Signing Request (CSR) Attribute > Request message by the pledge. you need to lay out the security assumptions here. It's not difficult to create a new domain with the same 40bit hash. If you have a private CA, this probably isn't an issue, but if you are sharing a public CA, it would allow me to produce a domain with other people's addresses. S 8.1.1. > configured to be put into the ACP VRF. The ACP is then accessible to > other (NOC) systems on such an interface without those systems having > to support any ACP discovery or ACP channel setup. This is also > called "native" access to the ACP because to those (NOC) systems the > interface looks like a normal network interface (without any > encryption/novel-signaling). This seems pretty unclear. Is the idea that you connect natively to the ACP Connect node and then it forwards your packets over the ACP? Does that mean they need to be GRASP or whatever? I think that's what you are saying below. S 8.1.5. > interface is physically protected from attacks and that the connected > Software or NMS Hosts are equally trusted as that on other ACP nodes. > ACP edge nodes SHOULD have options to filter GRASP messages in and > out of ACP connect interfaces (permit/deny) and MAY have more fine- > grained filtering (e.g., based on IPv6 address of originator or > objective). Given that this is an important security requirement, it seems like it should be a normative requirement that it be filtered. S 9.1. > same trust anchor, a re-merge will be smooth. > > Merging two networks with different trust anchors requires the trust > anchors to mutually trust each other (for example, by cross-signing). > As long as the domain names are different, the addressing will not > overlap (see Section 6.10). Why does it require the *trust anchors* to trust each other? Can't the endpoints just have the union of the trust anchors. This is way underspecified for actual implementation. S 10.2.1. > registrar can rely on the ACP and use Proxies to reach the candidate > ACP node, therefore allowing minimum pre-existing (auto-)configured > network services on the candidate ACP node. BRSKI defines the BRSKI > proxy, a design that can be adopted for various protocols that > Pledges/candidate ACP nodes could want to use, for example BRSKI over > CoAP (Constrained Application Protocol), or proxying of Netconf. I am finding it very difficult to work out the security properties of this mechanism and the security considerations do not help. What can a malicious registrar do? For that matter, you say "uncoordinated", so does that mean anyone in the ACP can just decide to be a registrar? S 11. > > 11. Security Considerations > > An ACP is self-protecting and there is no need to apply configuration > to make it secure. Its security therefore does not depend on > configuration. This is not true. You need to configure the trust anchor and the domain name. S 11. > all products. > > There is no prevention of source-address spoofing inside the ACP. > This implies that if an attacker gains access to the ACP, it can > spoof all addresses inside the ACP and fake messages from any other > node. You need to be clear that the security is just group security and that any compromised ACP node compromises the entire system. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 1. > possibilities that where considered not to be appropriate for > standardization in this document but were considered important to > document. > > The ACP provides secure IPv6 connectivity, therefore it can not only > be used as the secure connectivity for self-management as required Nit: this would be clearer as "can be used not only" S 2. > equally be used in simple ANI networks (with no other Autonomic > Functions) or completely by itself. > > ACP address: An IPv6 address assigned to the ACP node. It is stored > in the domain information field of the ->"ACP domain certificate" > (). Something wrong here. S 2. > > domain information (field): An rfc822Name information element (e.g., > field) in the domain certificate in which the ACP relevant > information is encoded: the domain name and the ACP address. > > ACP Loopback interface: The Loopback interface in the ACP VRF that Please expand VRF on first use. S 2. > routing and forwarding in the node other than the ACP VRF. In a > simple ACP or ANI node, the Data-Plane is typically provisioned > non-autonomic, for example manually (including across the ACP) or > via SDN controllers. In a fully Autonomic Network node, the Data- > Plane is managed autonomically via Autonomic Functions and Intent. > Note that other (non-ANIMA) RFC use the Data-Plane to refer to Nit: RFCs S 4. > protocols of the ANI. Clients of the ACP MUST NOT be tied to > a particular application or transport protocol. > > ACP5: The ACP MUST provide security: Messages coming through the ACP > MUST be authenticated to be from a trusted node, and SHOULD > (very strong SHOULD) be encrypted. Why isn't this a MUST? Once you have done the key setup, the encryption is very cheap. S 4. > between nodes, but only GRASP connectivity. Nevertheless, because > ACP also intends to support non-AN networks, it it is crucial to > support IPv6 layer connectivity across the ACP to support any > transport and application layer protocols. > > Th eACP operates hop-by-hop, because this interaction can be built on Nit: The ACP S 6.1.1. > hash collisions. If the operator does not own any FQDN, it should > choose a string (in FQDN format) that intends to be equally unique. > > "routing-subdomain" is the autonomic subdomain that is used to > calculate the hash for the ULA Global ID of the ACP address of the > node. "rsub" is optional; its syntax is defined in this document, This section about the hash isn't clear without referencing some future section. S 6.1.1. > In this specification, the "acp-address" field is REQUIRED, but > future variations (see Appendix A.8) may use local information to > derive the ACP address. In this case, "acp-address" could be empty. > Such a variation would be indicated by an appropriate "extension". > If "acp-address" is empty, and "rsub" is empty too, the "local-part" > will have the format "rfcSELF + + extension(s)". The two plus Are these spaces part of local-part? They appear to be forbidden by the ABNF S 6.1.1. > The subjectAltName / rfc822Name encoding of the ACP domain name and > ACP address is used for the following reasons: > > o It should be possible to share the LDevID with other uses beside > the ACP. Therefore, the information element required for the ACP > should be encoded so that it minimizes the possibility of creating Is this really not normative? S 6.1.3.5. > protocols used by the ACP registrars. > > Please refer to Section 6.10.7 for explanations about ACP registrars > and vouchers as used in the following text. > > When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re- I think you mean "i.e.", not "aka". S 6.1.3.5. > certificate or the IDevID, the re-enrolling candidate ACP node SHOULD > authenticate the BRSKI registrar during TLS connection setup based on > its existing trust anchor/certificate chain information associated > with its old ACP certificate. The re-enrolling candidate ACP node > SHOULD only request a voucher from the BRSKI registrar when this > authentication fails during TLS connection setup. This is all pretty hard to understand without having read BRSKI S 6.1.3.6. > > An ACP domain certificate is called failing in this document, if/when > the ACP node can determine that it was revoked (or explicitly not > renewed), or in the absence of such explicit local diagnostics, when > the ACP node fails to connect to other ACP nodes in the same ACP > domain using its ACP certificate. For connection failures to I don't understand the thing on the other side of this "or". I'm supposed to conclude based on some remote diagnostic that my cert is bad> S 6.1.3.6. > or any of its signing certificates could have been revoked or may > have expired, but the ACP node can not self-diagnose this condition > directly. Revocation information or clock synchronization may only > be available across the ACP, but the ACP node can not build ACP > secure channels because ACP peers reject the ACP node's domain > certificate. Is the idea here that I'm supposed to inspect the TLS alerts? S 6.3. > dependencies, including ACP. Please ensure that references to I- > D.ietf-anima-grasp that include section number references (throughout > this document) will be updated in case any last-minute changes in > GRASP would make those section references change. > > DULL GRASP is a limited subset of GRASP intended to operate across an Please expand DULL S 6.4. > > o ACP connections across domains with different Certificate > Authorities (CA) could establish a common ACP by installing the > alternate domains' CA into the trusted anchor store. This is an > executive management action that could easily be accomplished > through the control channel created by the ACP. How would you know if other domains had a given CA? S 6.5. > version 1.2", see [RFC6347]) because that code exists already on them > for end-to-end security, but low-end in-ceiling L2 switches may only > want to support Media Access Control Security (MacSec, see 802.1AE > ([MACSEC]) because that is also supported in their chips. Only a > flexible gateway device may need to support both of these mechanisms > and potentially more. Why are you mentioning MACSEC? Your negotiation syntax doesn't support it. S 6.5. > version 2", see [RFC7296]. It is now up to Alice to decide how to > proceed. Even if the IPsec connection from Bob succeeded, Alice > might prefer another secure protocol over IPsec (e.g., FOOBAR), and > try to set that up with Bob. If that preference of Alice succeeds, > she would close the IPsec connection. If no better protocol attempt > succeeds, she would keep the IPsec connection. When would you get partial failrues? S 6.7.1.2. > support IPsec transport mode with next protocol equal to GRE (47) > followed by the offer for native IPsec as described above (because > that option is mandatory to support). > > If IKEv2 initiator and responder support GRE, it will be selected. > The version of GRE to be used must the according to [RFC7676]. See above interop comments. S 6.7.3. > An ACP secure channel MUST immediately be terminated when the > lifetime of any certificate in the chain used to authenticate the > neighbor expires or becomes revoked. Note that this is not standard > behavior in secure channel protocols such as IPsec because the > certificate authentication only influences the setup of the secure > channel in these protocols. How does this interact with reissue? I am supposed to reconnect? S 6.8.2. > Figure 7: ACP as security and transport substrate for GRASP > > GRASP unicast messages inside the ACP always use the ACP address. > Link-local ACP addresses must not be used inside objectives. GRASP > unicast messages inside the ACP are transported via TLS 1.2 > ([RFC5246]) connections with AES256 encryption and SHA256. Mutual Again, why AES256/SHA256? S 6.8.2.1. > original objective in GRASP when it is a MITM and act as an > application level proxy. This of course requires that the > compromised ACP node understand the semantics of the GRASP > negotiation to an extent that allows it to proxy it without being > detected, but in an ACP environment this is quite likely public > knowledge or even standardized. Just to make sure I'm clear: you would know you were talking to A and not B (because the certificate) so that would be of some use, right? S 6.8.2.1. > encryption. Future work optimizations could avoid this but it is > unclear how beneficial/feasible this is: > > o The security considerations for GRASP change against attacks from > non-ACP (e.g., "outside") nodes: TLS is subject to reset attacks > while secure channel protocols may be not (e.g., IPsec is not). I don't think the distinction here is between "secure channel" and "TLS"; usually I would call TLS a secure channel protocol. Maybe "secure transport" or "L3"? Note that QUIC would not have this problem. S 6.12.5. > the same. The difference happens when Bob and Carol receive their > packet. If they use ACP point-to-point virtual interfaces, their > GRASP instance would forward the packet from Alice to each other as > part of the GRASP flooding procedure. These packets are unnecessary > and would be discarded by GRASP on receipt as duplicates (by use of > the GRASP Session ID). If Bob and Charly's ACP would emulate a Charly? Do you mean Carol? S 7.1. > create ACP point-to-point virtual interfaces for these secure > channels. > > 7. ACP support on L2 switches/ports (Normative) > > 7.1. Why This hed could be better. S 8.1.1. > explicit configuration. To support connections to adjacent non-ACP > nodes, an ACP node must support "ACP connect" (sometimes also called > "autonomic connect"): > > "ACP connect" is a function on an autonomic node that is called an > "ACP edge node". With "ACP connect", interfaces on the node can be This sentence is confusing. Perhaps first explain what an edge node is and then say ACP connect is a function of it. S 8.1.2. > only even more trusted software components will get access to both > the ACP virtual subnet and the Data-Plane (because those ACP users > could leak traffic between ACP and Data-Plane). This trust could be > established for example through cryptographic means such signed > software packages. The specification of these mechanisms is subject > to future work. This all seems pretty handwavingly speculative. I would remove it S 8.1.4. > legacy NMS Hosts that support only one IP interface. > > To provide a single subnet into both ACP and Data-Plane, the ACP Edge > node needs to de-multiplex packets from NMS hosts into ACP VRF and > Data-Plane. This is sometimes called "VRF select". If the ACP VRF > has no overlapping IPv6 addresses with the Data-Plane (as it should), Does this mean it should have no overlapping addresses or it should have overlapping addresses? The text here is kind of unclear though I believe from context it is "should have no" S 9.2.2. > under attack. > > 9.2.2. From the inside > > The security model of the ACP is based on trusting all members of the > group of nodes that do receive an ACP domain certificate for the same Nit: "receive", not "do receive" S 10.2.3. > Even when such a malicious ACP registrar is detected, resolving the > problem may be difficult because it would require identifying all the > wrong ACP domain certificates assigned via the ACP registrar after it > was was compromised. And without additional centralized tracking of > assigned certificates there is no way to do this - assuming one can > not retrieve this information from the . from the .? S 10.2.4. > In situations, where either of the above two limitations are an > issue, ACP registrars could also be sub-CAs. This removes the need > for connectivity to a root-CA whenever an ACP node is enrolled, and > reduces the need for connectivity of such an ACP registrar to a root- > CA to only those times when it needs to renew its own certificate. > The ACP registrar would also now use its own (sub-CA) certificate to When you say "sub CA" do you mean "intermediate"? S 10.3.2.1. > provides also a high level of security because it only permits ACP/ > ANI operations which are both well secured. Ultimately, it is > subject to security review for the deployment whether "admin down" is > a feasible replacement for "physical down". > > The need to trust into the security of ACP/ANI operations need to be "trust into" is not grammatical S 10.3.4. > whether or not to set "ACP/ANI enable". > > The goal of automatically setting "ACP/ANI enable" on interfaces > (native or not) is to eliminate unnecessary "touches" to the node to > make its operation as much as possible "zero-touch" with respect to > ACP/ANI. If there are "unavoidable touches" such a creating/ such as S 10.3.5. > parameters on SIM card shipped to remote location), then the default > should be to enable ACP/ANI. > > 10.3.5. Node Level ACP/ANI enable > > A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI I got lost here. In what context does this command exist? S 10.3.5.1. > > Automatically setting "ANI enable" on brownfield nodes where the > operator is unaware of it could also be a critical security issue > depending on the vouchers used by BRKSI on these nodes. An attacker > could claim to be the owner of these devices and create an ACP that > the attacker has access/control over. In network where the operator "In networks" S 10.3.6. > > Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the > reliable operations of the ACP if it can be executed by mistake or > unauthorized. This behavior could be influenced through some > additional property in the certificate (e.g., in the domain > information extension field) subject to future work: In an ANI This also seems handwavy. S 15.2. > because it is not quite clear yet what exactly the implications are > to make GRASP flooding depend on RPL DODAG convergence and how > difficult it would be to let GRASP flooding access the DODAG > information. > > A.6. Extending ACP channel negotiation (via GRASP) This section seems like it's entirely speculative. I recommend removing it. That said, I don't really understand the rationale for multiple concurrent security protocols. If you have clear UDP on the network (and you must or none of this works), then you can do DTLS and IKEv2, so you should be able to have one side decide which to negotiate and negotiate that. Why does this not work? S 15.2. > > If multiple independent networks choose the same domain name but had > their own CA, these would not form a single ACP domain because of CA > mismatch. Therefore there is no problem in choosing domain names > that are potentially also used by others. Nevertheless it is highly > recommended to use domain names that one can have high probability to Are these normative? S 15.2. > If different domains have different CAs, they should start to trust > each other by intent injected into both domains that would add the > other domains CA as a trust point during the ACP connection setup - > and then following up with the previous point of inter-domain > connections across domains with the same CA (e.g., GRASP > negotiation). This all seems speculative (and hard to analyze at this state of handwaving). I suggest removal. S 15.2. > other domains CA as a trust point during the ACP connection setup - > and then following up with the previous point of inter-domain > connections across domains with the same CA (e.g., GRASP > negotiation). > > A.8. Adopting ACP concepts for other environments I would also remove this appendix. From nobody Wed Aug 1 17:30:16 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5119A130EF2; Wed, 1 Aug 2018 17:30:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 17:30:10 -0700 Archived-At: Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 00:30:10 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-16: 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-anima-autonomic-control-plane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a really exciting protocol to read about -- the prospect of dropping a bunch of just-manufactured devices in place, spinning up a registrar (and maybe a MASA), and getting a control plane like magic is pretty impressive. That said, I don't believe that this document is ready to publish as-is. I have a list of specific points below for discussion, but it may be more effective to strip down the document a lot (providing a well-defined core protocol and leaving out speculative future work, along the lines of Alissa's comments) and only then start to work on specific rough spots. In particular, in its current form, it's not clear to me why this document is targeting the standards-track -- there are lots of places where determinations of what works best or how to do some things is left for future work. Are there lots of implementations or consumers clamoring for this stuff that it makes sense to go for PS as opposed to Experimental (so as to figure out what works and nail down a slimmer protocol for the standards track)? I see in A.4 that the choice of RPL was motivated by experience with a pre-standard version of ACP; it would have been great to hear more about those deployments in an Implementation Status section (per RFC 7942) or the Shepherd writeup. I also think the document needs to be more clear about what security properties it does or does not intend to provide: we hear in the abstract and introduction that ACP will be "secure" (and similar platitudes are repeated throughout), but we don't really get a sense of the specifics until Section 4, with ACP5. This has a MUST for authenticated and "SHOULD (very strong SHOULD)" be encrypted. But text elsewhere in the document seems to be using "secure" to also mean encrypted, and there is even one place that flatly asserts that "ACP mandates the use of encryption". This internal inconsistency needs to be resolved, at a minimum, and ideally the intended posture more clearly conveyed. (It's also not really stated under what cases encryption would not be used, so that the "very strong SHOULD" could not be a MUST.) Section 3.2 claims that the ACP provides "additional security" for bootstrap mechanisms due to the hop-by-hop encryption. But in what sense is actual additional security gained? Against an attacker with what capabilities? If there is security gain from such hop-by-hop encryption, doesn't that point to a weakness in the bootstrap scheme? I think there needs to be some justification of why rfc822Name is chosen over a more conventional structure in the otherName portion of the subjectAltName, which is explicitly designed to be extensible. The requirement in Section 6.1.2 for CRL and OCSP checks seem impossible to satisfy for a greenfield node without non-ACP connectivity, as it must join the ACP domain (and supposedly validate the CRL and OCSP validity before doing so) before establishing an ACP link with its peer, but cannot validate anything with no connectivity. Throughout, the document seems to implicitly conflate authentication with authorization. I understand that the main authorization check is just the domain membership test in Section 6.1.2; nonetheless, as a pedagogical matter I cannot support propagating their conflation. In a few places, the MTI cryptographic mechanisms are under-specified, whether the cipher mode for IKE or the TLS ciphersuites. I have attempted to note these locations in my section-by-section comments. Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL root, but if I understand correctly the RPL root is automatically determined within the ACP, and thus the operator does not a priori know which node will become the RPL root. Am I misunderstanding, or is this effectively placing this requirement on all ACP nodes? The IANA considerations specifically do register SRV.est in the GRASP Objective Names Table, and then follows up with a paragraph that this is only a "proposed update". I don't know if there's actually anything problematic here, but the document does need clarity on what is proposed for future work and what is to be done now. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some high-level comments that do not quite meet DISCUSS criteria appear below, followed by section-by-section inline comments. My apologies for not splitting them between substantive and editorial, but I don't think I have enough time left before the telechat to do that and finish the other reviews I have remaining. The whole premise of the ACP is for it to be almost entirely autonomic and not require external configuration. But some pieces/functionality do require explicit configuration (e.g., manual ACP addresses, configured remote ACP neighbors, etc.), so I would have liked to see a section discussing what sort of interface might be used to inject manual configuration into the otherwise autonomic system. Would this be done using ACP control messages from an NMS using an ACP connect node, or an out-of-band (serial) management port, or something else? I think the document needs to be more clear about its stance towards constrained nodes: DTLS is supported (along with IKEv2+IPSEC), supposedly for the benefit of constrained nodes, but then the more heavyweight TLS is required for several operations within the ACP itself. Section 1 of the ACP (after all the details have been defined), Section 10 provides operational recommendations, Appendix A provides additional explanations and describes additional details or future work possibilities that where considered not to be appropriate for nit: s/where/were/ [...] The ACP can be implemented and operated without any other components of autonomic networks, except for the GRASP protocol which it leverages. This could probably benefit from being disambiguated between the single ACP-wide GRASP instance and the DULL GRASP used for link-local flooding/discovery. Section 1.1 [...] The ACP can operate equally on layer 3 equipment and on layer 2 equipment such a bridges (see Section 7). The encryption mechanism used by the ACP is defined to nit: such as be negotiable, therefore it can be extended to environments with different encryption protocol preferences. The minimum implementation requirements in this document attempt to achieve maximum interoperability by requiring support for few options: IPsec, DTLS - depending on type of device. nit: This last sentence could be reworded for clarity, "[...] requiring support for multiple options (IPsec and DTLS), depending on the type of device." Section 2 ACP address: An IPv6 address assigned to the ACP node. It is stored in the domain information field of the ->"ACP domain certificate" (). nit: The "->" and "()" seem like artifacts from an editor also usable for source code? ("->" also appears in "ACP domain"'s definition, and both appear in the "in band (managemnet) definition and the "(virtual) out-of-band network" definition.) EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard protocol for enrollment of a node with an LDevID. BRSKI is based on EST. RFC 7030 is only Proposed Standard, so "standards-track protocol" seems more appropriate. (virtual) out-of-band network: An out-of-band network is a secondary network used to manage a primary network. The equipment of the primary network is connected to the out-of-band network via dedicated management ports on the primary network equipment. Serial (console) management ports where historically most common, nit: s/where/were/ Please use the actual RFC 8174 instead of attempting to reproduce (but not exactly) its updated boilerplate. Section 4 ACP4: The ACP MUST be generic. Usable by all the functions and protocols of the ANI. Clients of the ACP MUST NOT be tied to a particular application or transport protocol. nit: The second sentence is only a sentence fragment. ACP5: The ACP MUST provide security: Messages coming through the ACP MUST be authenticated to be from a trusted node, and SHOULD (very strong SHOULD) be encrypted. authenticated as coming from a trusted node, or authenticated to be from a specific node, which is known to be trusted? Also, maybe "MUST, except for [...]" is better than "very strong SHOULD". (What are the execptional cases where plaintext is allowed?) Integrity protection of authenticated traffic may be worth mentioning explicitly. Th eACP operates hop-by-hop, because this interaction can be built on nit: s/Th eACP/The ACP/ Section 5 3. For each node in the candidate peer list, it authenticates that node and negotiates a mutually acceptable channel type. There seems to be an implicit step in here, "confirms that the node is authorized to be a part of the same ACP domain". Presumably this is usally the "ACP domain membership check" of Section 6.1.2; a forward reference seems in order. Section 6.1.1 It's slightly jarring to use ABNF to specify the contents of an ASN.1 field. hex-dig is case-insensitive; is that intended? "acp-address" seems under-specified and maybe over-constrained, in that it does not say how to get what digits to put there, and in that limiting to 32 hex digits may prevent the use of alternative ACP address schemes in the future, as is suggested as a possibility in the body text. [...] If the operator does not own any FQDN, it should choose a string (in FQDN format) that intends to be equally unique I don't know if it's worth cautioning against making up fake TLD-equivalents, given how this has bitten people as new TLDs come online. I'm not sure that "people implementing our stuff have an easier time" is a great reason to stuff randomly-shaped stuff into an existing hole, especially when there's this nice otherName-shaped hole available right next to it. o The format of the rfc822Name is chosen so that an operator can set up a mailbox called rfcSELF@ that would receive emails sent towards the rfc822Name of any node inside a domain. This is possible because in many modern mail systems, components behind a "+" character are considered part of a single mailbox. In other words, it is not necessary to set up a separate mailbox for every ACP node, but only one for the whole domain. This is effectively codifying that foo+bar@baz === foo@baz in email addresses, which perhaps merits some broader discussion (especially in the context of security issues when different providers disagree about whether local components of email addresses differing after a '+' are the same or not!). Section 6.1.2 o The peer's certificate is signed by one of the trust anchors associated with the ACP domain certificate. This seems to preclude having a PKI structure that is common in the web world, of a highly secure, offline trust anchor that only certifies intermediate CA certificates, with the intermediates certifying end-entity certificates. Perhaps the intention is that the peer's certificate chains to such a trust anchor? o The peers certificate has a syntactically valid domain information field (subjectAltName / rfc822Name) and the domain name in that peers domain information field is the same as in this ACP node certificate. Is this supposed to be an exact byte-for-byte match, or is some form of insensivity allowed that would require normalization/canonicalization prior to comparison? Section 6.1.3 I had noted (in my local notes) on the -13 that using the ACP address and only storing one EST server makes for a single point of failure; the situation seems somewhat improved in the -16 in that the remebmered value is used as the first attempt for renewal, but presumably with GRASP announcement as a fallback there is less of a single point of failure. Section 6.1.3.1 Does the example need a comma after 255 to indicate the absent objective-value? (Also, putting the example after the CDDL might help the reader know what they're looking at.) The "formal CDDL definition" of flood-message seems somewhat informal at times, e.g,. for loop-count. Using both "[t]he objective value" and an "objective-value" field for different things is needlessly confusing; can the body text be clarified somewhat about the value "SRV.est"? Can "negligbile traffic" be quantified? Section 6.1.3.3 [...] If the CDP URL uses an IPv6 address (ULA address when using the addressing rules specified in this document), the ACP node will connect to the CDP via the ACP. Seems to be duplicated? HTTPs connections. The connecting ACP node SHOULD verify that the CDP certificate used during the HTTPs connection has the same ACP address as indicated in the CDP URL of the nodes ACP domain certificate Presumably only if the CDP URL listed an IPv6 address. (Also, nit: full stop at end of sentence.) Section 6.1.3.4 A reference to draft-ietf-acme-star and/or draft-nir-saag-star might be useful to inform the reader of related work. (Note that the latter was not adopted by the LAMPS WG yet, with the indication that some changes were needed before it would be appropriate for adoption.) Section 6.2 [...] An ACP node MUST maintain this adjacency table up to date. Up to date on what timescale? The adjacency table MAY contain information about the validity and trust of the adjacent ACP node's certificate. However, subsequent steps MUST always start with authenticating the peer. Also verifying that it is authorized for the operation in question? Section 6.3 The result of the discovery is the IPv6 link-local address of the neighbor as well as its supported secure channel protocols (and non- standard port they are running on). It is stored in the ACP Adjacency Table, see Section 6.2 which then drives the further building of the ACP to that neighbor. nit: "see section 6.2" is probably better in parentheses, but if commas are used, they need to be both before and after it. Section 6.4 o Build the ACP across all domains that have a common parent domain. For example ACP nodes with domain "example.com", nodes of "example.com", "access.example.com", "core.example.com" and "city.core.example.com" could all establish one single ACP. If this wasn't an example it sounds like it'd need to reference the public suffix list? Section 6.5 o An ACP node may choose to attempt initiate the different feasible nit: to attempt to initiate Section 6.6 "Exponential backoff" requires the base of the exponent to be specified in order to be well-defined. (An base of, e.g., 1.0000001 is hardly any backoff at all, over our normal timescales.) Section 6.7.1.1 [...] It MUST then support ESP with AES256 for encryption and SHA256 hash and MUST NOT permit weaker crypto options. That does not fully specify cryptographic parameters for communication security, e.g., CTR vs. CBC vs. GCM mode of AES. (Similarly in Section 6.7.1.2.) In terms of IKEv2, this means the initiator will offer to support IPsec tunnel mode with next protocol equal 41 (IPv6). nit: "equal to" ESP is used because ACP mandates the use of encryption for ACP secure channels. I thought this was only a "very strong SHOULD", not mandatory. (Similarly in Section 6.7.1.2.) Section 6.7.1.2 (Lots of this section duplicates 6.7.1.1 and could be consolidated into the toplevel 6.7.1.) If IKEv2 initiator and responder support GRE, it will be selected. The version of GRE to be used must the according to [RFC7676]. nit: the grammar in the last sentence is weird; maybe "must be determined according to"? Section 6.7.2 To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP port is used that is announced as a parameter in the GRASP AN_ACP objective to candidate neighbors. All ACP nodes supporting DTLS as a secure channel protocol MUST support AES256 encryption and MUST NOT permit weaker crypto options. You should specify actual ciphersuite, signature, and hash algorithms. Section 6.7.3 I would recommend calling out the "terminate channel when certificate expires" behavior again in the security considerations, as it would be surpirsing to readers expecting the "standard" behavior. nodes with an area of baseline ACP nodes MUST therefore support IPsec and DTLS and supports threefore the baseline and constrained profile. nit: s/threefore/therefore/ Section 6.8.2 The figure does not really aid my understanding absent some additional explanation. GRASP unicast messages inside the ACP always use the ACP address. Link-local ACP addresses must not be used inside objectives. GRASP Link-local *ACP* addresses, or IPv6 ones? [...] GRASP unicast messages inside the ACP are transported via TLS 1.2 ([RFC5246]) connections with AES256 encryption and SHA256. Same comment as before about ciphersuite/etc. Also, TLS or DTLS (noting that constrained devices are assumed to only implement DTLS)? Also, TLS 1.3 is in the RFC Editor's queue; is there work underway to adapt to it? [...] TLS and TLS connections for GRASP in the ACP use the IANA assigned TCP port for GRASP (7107). Is one of those supposed to be DTLS? Is the IANA-assigned port assigned for both TCP and UDP? Section 6.8.2.1 As a side note, I don't mind seeing discussion about potential future work to avoid the double authentication/encryption, but my intuition is that it's not really worth pursuing. Section 6.10.1 o Addresses in the ACP are not considered sensitive on privacy grounds because ACP nodes are not expected to be end-user devices. I feel like this claim requires additional justification. Section 6.10.3.1 A node knowing it is in a zone MUST also use that Zone-ID != 0 address in GRASP locator fields. [...] What does "also" mean here? Is this another requiment being placed on a node that knows it is in a zone, or must this node use both the zone-id==0 and the zone-id!=0 addresses in GRASP locator fields (i.e., duplicating all such)? Section 6.10.5 o V: Virtualization bit: Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme. There is not a single 'V bit' -- the V field is either 8 or 16 bits long -- so saying "in the same way" is confusing. I believe that the intent is to distinguish between "zero" and "not-zero", with the zero value meaning the same as the zero bit in the Zone-ID sub-scheme. That is, the final bit need not be 1 to indicate a "virtual" usage. Or do I misunderstand? Section 6.10.7.3 In a simple allocation scheme, an ACP registrar remembers persistently across reboots for its currently used Registrar-ID and for each addressing scheme (zone with Subnet-ID 0, Vlong with /112, Vlong with /120), the next Node-Number available for allocation and increases it after successful enrollment to an ACP node. In this simple allocation scheme, the ACP registrar would not recycle ACP address prefixes from no longer used ACP nodes. It's probably better to say "increments it during successful enrollment" since if the registrar crashed right after issuing a certificate but before incrementing the next available node-number, it would issue a duplicate when it came back up. Section 6.10.7.4 [...] Even when the renewing/rekeying ACP registrar is not the same as the one that enrolled the prior ACP certificate. See Section 10.2.4 for an example. ACP address information SHOULD also be maintained even after an ACP certificate did expire or failed. See Section 6.1.3.5 and Section 6.1.3.6. Both the first and the last sentence quoted have grammar nits; the former is a sentence fragment (perhaps "This holds even when [...]"), and the second has inconsistent verb tense (perhapse "expired or failed"). Section 6.11 All routing updates are automatically secured in transit as the channels of the autonomic control plane are by default secured, and this routing runs only inside the ACP. Again, I thought encryption was only "very strong SHOULD". If this "secured" only was intended to refer to authentication (and presumably implicitly integrity protection), then "by default" is not needed, since the latter protection is mandatory. Section 6.11.1.1 In summary, the profile chosen for RPL is one that expects a fairly reliable network reasonably fast links so that RPL convergence will be triggered immediately upon recognition of link failure/recovery. Is there a missing "with" in here, or something else in order to get it to parse? [...] This the same behavior as that of other IGPs that do not have the Data-Plane options as RPL. Is this suppposed to be ", as is the case for RPL"? (Also, "This is"?) In general, this section has an unclear overall structure/organization and several instances of strange grammar/wording. The RFC Editor will be of some help with the latter, but generally is unwilling to take the initiative to make the sorts of changes needed to address the former. Section 6.11.1.7 Local Repair: As soon as link breakage is detected, send No-Path DAO for all the targets that where reachable only via this link. As soon nit: s/where/were Section 6.11.1.9 Please don't treat "security" as some single black-box concept; there are gradiations within it and different attributes that can be relevant. For example, here we would probably say something like "Because the ACP links already include provisions for confidentiality and integrity protection, their usage at the RPL layer would be redundant, and so RPL security is not used". I guess the RPL security bits needed for per-participant authentication (as opposed to a group key) are not entirely in place yet, so it's hard to claim that RPL security would do much better than even hop-by-hop ACP security measures. Section 6.11.1.12-14 These sections do not match up with the template entries I see in draft-ietf-roll-applicability-template-09; can you explain the discrepancy? Section 6.12.5 I'm confused about the "ACP multi-access virtual interface" -- is this only for the initial "link-local" flooding/discovery? Otherwise, aren't the ACP secure channels inherently two-party? I don't think I understand what the multi-access benefit is, since my understanding was that RPL was running on top of these link-local secure channels. Section 6.12.5 The ACP virtual interface IPv6 link local address can be derived from any appropriate local mechanism such as node local EUI-48 or EUI-64 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend on something that is attackable from the Data-Plane such as the IPv6 link-local address of the underlying physical interface, which can be attacked by SLAAC, or parameters of the secure channel encapsulation header that may not be protected by the secure channel mechanism. Is this the same EUI that might be used on the Data-Plane like the MAC address of the physical interface? nit: s/Charly/Carol/ Section 7.2 The description in the previous paragraph was specifically meant to illustrate that on hybrid L3/L2 devices that are common in enterprise, IoT and broadband aggregation, there is only the GRASP packet extraction (by Ethernet address) and GRASP link-local multicast per L2-port packet injection that has to consider L2 ports at the hardware forwarding level. The remaining operations are purely ACP control plane and setup of secure channels across the L3 interface. This hopefully makes support for per-L2 port ACP on those hybrid devices easy. Have you talked to any hardware manufacturers that would be able to remove the "hopefully" from this statement? A generic issue with ACP in L2 switched networks is the interaction with the Spanning Tree Protocol. Ideally, the ACP should be built also across ports that are blocked in STP so that the ACP does not depend on STP and can continue to run unaffected across STP topology changes (where re-convergence can be quite slow). The above described simple implementation options are not sufficient for this. Instead they would simply have the ACP run across the active STP topology and the ACP would equally be interrupted and re-converge with STP changes. This "Instead" is a little unclear, perhaps "They fail because the ACP simply runs across the active STP topology [...]"? Section 8.1.1 The ACP connect interface must be (auto-)configured with an IPv6 address prefix. Is prefix SHOULD be covered by one of the (ULA) prefix(es) used in the ACP. If using non-autonomic configuration, it SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). I'm confused in what case ACP connect would be used with autonomic configuration (and thus why the qualification is needed on the SHOULD). I thought the whole thing was premised on the presence of a NMS that does not implement ACP. In the simple case where the ACP uses only one ULA prefix and all ACP connect subnets have prefixes covered by that ULA prefix, NMS hosts can rely on [RFC6724] Please include some exposition on the property being provided instead of just citing the RFC. ACP Edge Nodes MUST only forward IPv6 packets received from an ACP connect interface into the ACP that has an IPv6 address from the ACP prefix assigned to this interface (sometimes called "RPF filtering"). This sentence is hard to parse as to what the "that has" restriction applies to. I think it's supposed to be that you only forward (IPv6 packets with a source address from the ACP prefix) into the ACP, right? To limit the security impact of ACP connect, nodes supporting it SHOULD implement a security mechanism to allow configuration/use of ACP connect interfaces only on nodes explicitly targeted to be deployed with it (such as those physically secure locations like a NOC). For example, the certificate of such node could include an extension required to permit configuration of ACP connect interfaces. I think this would be better as "[...] could include a specific extension, and that extension would be required to be present in order to permit configuration [...]". But who would enforce this requirement -- the ACP implementation on the node that is compromised? That does not seem to provide the desired security property. This also falls into Alissa's comment about "future work". Section 8.2.1 I think you need to include a reference for ABNF. Section 9.1 [...] Since the revocation check is only done at the establishment of a new security association, existing ones are not automatically torn down. If an immediate disconnect is required, existing sessions to a freshly revoked node can be re-set. How would the revoked node's peers know to perform such a re-set? This would seem to require some signaling protocol at revocation time. After a network partition, a re-merge will just establish the previous status, certificates can be renewed, the CRL is available, and new nodes can be enrolled everywhere. Since all nodes use the same trust anchor, a re-merge will be smooth. I believe this document has described schemes where not all nodes use the same trust anchor [for signing their LDevID], so maybe this should be "trust anchor(s)" plural? Merging two networks with different trust anchors requires the trust anchors to mutually trust each other (for example, by cross-signing). As long as the domain names are different, the addressing will not overlap (see Section 6.10). Subject to the risk of a 40-bit collision in SHA256! While not necessarily a critical flaw at this time, the limitation should probably be mentioned. Section 9.2.1 I think you need informative references to all the listed protocols that the ACP could serve as protection for. % remote attacks are impossible Remote attacks to DoS by resource consumption the nodes involved would still work fine, so "impossible" is probably overstating it. Section 9.2.2 I expected to see something about the importance of being able to detect a compromised node and revoke its certificate. Ideally this could be automated (with the detecting node providing proof of compromise in some fashion), though the details of that would probably be hard to get right. Section 9.3 "independent of configuration" is in conflict with the discussion of configuring ACP connect, configured remote ACP neighbors, etc. Section 10.2.2 For BRSKI or other mechanisms using vouchers: Parameters to determine how to retrieve vouchers for specific type of secure bootstrap candidate ACP nodes (such as MASA URLs), unless this information is automatically learned such as from the LDevID of candidate ACP nodes (as defined in BRSKI). I thought the LDevID was essentially synonymous with "ACP domain certificate" in this document, so I can't understand what this means (unless IDevID was intended). Section 10.2.3 [...] And without additional centralized tracking of assigned certificates there is no way to do this - assuming one can not retrieve this information from the . Missing the end of the sentence? Section 10.2.4 Or let it expire and not renew it, when the certificate of the sub-CA is appropriately short-lived. This sort of sentiment has been highly controversial in other contexts (e.g., draft-nir-saag-star). (Also, that's a sentence fragment.) Therefore ACP domain membership for an ACP node enrolled from a compromised ACP registrar will fail. >From a compromised *and detected* registrar. Section 10.3.x This whole section feels more like a sketch of an idea than a well-specified model or protocol. It might be better if spun off into a separate document, with time spent to produce (e.g.) a YANG module or state machines for devices in various states. Section 10.3.5.1 [...] Automatic enablement of ACP/ANI in networks where the operator does not only not want ACP/ANI but where he likely never even heard of it could be quite irritating to him. Especially when "down" behavior is changed to "admin down". The behavior mentioned in this last sentence really ought to be called out more clearly in the previous section as changing the semantics of existing administrative controls. Section 10.3.7 The control names indicated within double quotes are mostly incomplete references; it seems better to say, e.g., """the "up-if-only" option for node-level ACP/ANI enablement""". Section 11 An ACP is self-protecting and there is no need to apply configuration to make it secure. Its security therefore does not depend on configuration. It seems like there are some higher-level/potentially "external" configurations needed, including but not limited to: setting up the registrar, definng the Intent, assigning a ULA to use for the domain, policy for the CA issuing domain certificates, and any interaction with external systems that is needed. (That is, a fully autonomous system would be totally self-contained, and thereby not of much use to the humans involved!) "correct operation" to me usually means "this system is behaving as expected", but I think the intended usage here is more like "being operated and managed correctly". I don't know if I'm enough of an outlier to make it not worth changing the text. I would like to see more text about the scope of damage that a compromised ACP node can do, and suggesting detection/remediation measures. Section 12 Note that the objective format "SRV." is intended to be used for any that is an [RFC6335] registered service name. This is a proposed update to the GRASP registry subject to future work and only mentioned here for informational purposed to explain the unique format of the objective name. I'm confused about what this is actually trying to say. It sounds like it is actually registering SRV.est (in the previous paragraph), but following that up by saying that this isn't actually a real registered service name yet, and we're just registering the objective name proactively for future work? If so, that does not seem like the correct thing to do. Section A.2 [...] This requires only that the BRSKI registrar honors expired domain certificates and that the pledge first attempts to perform TLS authentication for BRSKI bootstrap with its expired domain certificate - and only reverts to its IDevID when this fails. The "first" is unclear -- perhaps "that the pledge attempts to perform TLS authentication for BRSKI bootstrap using its expired domain certificate before falling back to attempting to use its IDevID for BRSKI"? Section A.4 [...] RPL also has other scalability improvements, such as selecting only a subset of peers instead of all possible ones, and trickle support for information synchronization. (But trickle support is not used in the ACP profile of RPL.) Section A.8 This discussion of reusing preexisting MAC addresses violates the claim that the ACP-internal addresses are not guessable from the data plane. From nobody Wed Aug 1 18:21:38 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252F5130E10; Wed, 1 Aug 2018 18:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHeU8Z_eqYSa; Wed, 1 Aug 2018 18:21:25 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 4D8C1130DD1; Wed, 1 Aug 2018 18:21:25 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id p23-v6so264082pgv.13; Wed, 01 Aug 2018 18:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=lFyrLTSUtgy0O4SKhWMTKG7GsgFtqmfGtjsgRBp3Ltg=; b=kIfFVbGTRmiuzvKX+s3FPJc6rWySFL/bcqC9ZjF8Tupa9Z+awRY9EYWuHVmldjcn/n dmpHeRVZ3z9woZh6A9GmWkFrEyj2MBPTNV6oZKIIYq/wgoFg6uPtSLlfYP00S7fNZ4sw 1vtDCUsjxKWFaYxDBDp4qolCU3WL1jV81K+6yZw1tFtNOxDaCLm/pxf37MZsKE8oQ1HI HWuyKup8Xvqd34oyODwB9Dcc4PAB86w0gPxKA80iJp+LmQTvPe8f8xV32fWmwUkJetjy UP1TBUqrgIEvLjhV8h+N+6MgT+aApaEs9lNbTG94AFkfEI0e6EEzff4qJFfAUwgX/rUY X+LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lFyrLTSUtgy0O4SKhWMTKG7GsgFtqmfGtjsgRBp3Ltg=; b=TsOlWpY9gsUHfrvy32qcQaLxviabrGsYple2qzdK2oCZq/kpvf7bxKLzM0HdFujiOS r9Bldzok2qEoz7xkt5taJMJcvy1PWnQG6AmK8TIu8RZhR1VxCgDoT4tKzYUIRNbNaxpM etFKDwG67SnhAEuun2HKweUTOtFer8dlIeS0zHAnZhjVioEPd2BGONh4uIhlR/9eA3aZ OzWd7RbhNHqtcq0YaFvfyYcu9Ng131YuwV270reu7+e66FhwiGfzakb6JlmDg4W4OisB /+satM/ro59WJQUp3RpMV5yrlKKSNxif0+2E8REa5VH9lYN2mqphqhfz4R4LTqDOvnnL xzLQ== X-Gm-Message-State: AOUpUlHQVIjEkm8Xcg0D32nBD+Mu6ImDbveLD9HZ9rgrdAWrACB0Uoqn TkKJTeVFzMnovw8kToINJbI= X-Google-Smtp-Source: AAOMgpemHZZSRZz5PDdls+kpluz1Yxt1K9kzsK4IZm3N7yQWfHixb2Bel2IU9Z9cizPTm1/ExSAj+A== X-Received: by 2002:a62:225d:: with SMTP id i90-v6mr691176pfi.246.1533172884725; Wed, 01 Aug 2018 18:21:24 -0700 (PDT) Received: from [192.168.178.30] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id x66-v6sm456022pff.123.2018.08.01.18.21.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 18:21:23 -0700 (PDT) To: Michael Richardson , Alissa Cooper , The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> <14725.1533165162@localhost> From: Brian E Carpenter Message-ID: <1d6ac2f7-291d-c33c-d4e6-0ea30ed44b5f@gmail.com> Date: Thu, 2 Aug 2018 13:21:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <14725.1533165162@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 01:21:27 -0000 On 02/08/2018 11:12, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Section 6.10.4: > >> > >> "The value of the Interface Identifier is left for future definitions." > >> > >> I don't understand how this is usable without some definition. I.e., if I > >> assign every interface ID in my ACP to be 0, it's not going to work. Could you > >> elaborate about what is expected in this field? > >> > > > Why not: > > > The value of the Interface Identifier SHOULD follow [RFC8064]. > > > That would work fine and is a SHOULD to allow for alternatives > > if there's a good reason. > > The ACP addresses (including interface identifiers) are assigned by the ANI > Registrar, and are embedded in certificates issued by the Registrar. > Schemes 6.10.2 and 6.10.3 support this mechanism. > > Section 6.10.4 is about very much MANUAL allocation, which is basically > a non-zero-touch backdoor which nobody is supposed to use, unless they aren't > doing ANI stuff. > > Really, it's about the Registrar doing it's work (section 6.10.7), and the > only reason to have any statements about addressing schemes is so that we can > paint off some areas for manual allocation. (I didn't want any of these schemes here, > I don't think it helps, but maybe it causes no harm). > > The explanation in 6.10.7.2 further allows for multiple Registrars to operate > without coordinating via a centralized database (or blockchain). > > So, by all means, suggest an RFC8064 IID in the UI when configuring a manual > address, but if the admin is even close to that part of the configuration, > then they probably meant to do something very specific. Absolutely, but Alissa is correct, we need to say *something*. Brian From nobody Wed Aug 1 18:55:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C556130DCA; Wed, 1 Aug 2018 18:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duO59c1hRzME; Wed, 1 Aug 2018 18:55:06 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 5AC32124D68; Wed, 1 Aug 2018 18:55:06 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id j8-v6so350632pff.6; Wed, 01 Aug 2018 18:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FzNq4n7nOFTJ9+x/pfm4Zqq1Z8NMXZwfl+bMvV7PpEQ=; b=pIsKZP1/WZJm8cTJwnZb1dmzm24VQ53IUL1r4aebgHDDtjCSvDi+eoOmk9fyXYlrYh t4RjUDq6g1vEgBTnWy7xA/CO1eioPTKPk8tacivIKsmx98i2JvAfgh6Uhcivfhf2SFk2 owzxwYkzkr8qPTFfw7XINHm9cmWHb24DbI30nGPufZgDcpcmh7hnedPsRX0J/U5XTHuN Ts+W7M0vrxPDS7hAgRsLG/tSY77mJ8m9n5ZTxtfV26kejhZPmOq90n4xhsiGirH7WeRS kh4VjtTwBxyg4oweCHEb6shfcb8KqD4qyO941YX0e4Y/AVsitVUz3dA/H3jSIVOwd9Ql GFdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FzNq4n7nOFTJ9+x/pfm4Zqq1Z8NMXZwfl+bMvV7PpEQ=; b=IULdW0OEkCh07aF0r92GVMqKQTlQnasfVX8kV2pZtzhcL3GLu83Ea7zL/zwy/4unXw NcFYGu/L4N+o5qMuna/dTl0jvoG1ad6FiIP6KlIZVWL+AwsU568zJ4BqGLeW4i4Rtl9E hIipEO34MObtQcO1euN3fGwPCn+6fiSRhWTDLPl2UOaqD51+p5F/9zK/RNx2vZRCvPL9 mAfLFdQzlGU7xWfWGsuQGl9MzbaFVFM2YyWNVu2qAieIa72TBLcFeLIBxlRpgm9VkBop KntTcbOxEQlUIaaVtJX8tikJg3aUWeNIEid7pgmyIaRR/XQltmTyBauebj5V8k+Kculn RoGg== X-Gm-Message-State: AOUpUlElfFxV6Ty1VZPmopvRoEcexnrMqeqlOdZerJFCtuK9RIUYRqtk al7PdOeKsKy58D2KZexE+GzJX/yE X-Google-Smtp-Source: AAOMgpeLTR0PDF7EnUL+IMpKFVmZZMWebBTJ4l9By8ebzTS474TH/Bnfw3Ol10oT1o9/qQQIXd/NXg== X-Received: by 2002:a63:da56:: with SMTP id l22-v6mr316002pgj.179.1533174905835; Wed, 01 Aug 2018 18:55:05 -0700 (PDT) Received: from [192.168.178.30] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id s3-v6sm688543pfg.2.2018.08.01.18.55.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 18:55:04 -0700 (PDT) To: Eric Rescorla , The IESG Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153316779818.21822.14156274165395996235.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Thu, 2 Aug 2018 13:55:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153316779818.21822.14156274165395996235.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 01:55:08 -0000 Just on one point (the rest is definitely for the authors): On 02/08/2018 11:56, Eric Rescorla wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- ... > S 6.5. >> >> o Once the first secure channel protocol succeeds, the two peers >> know each other's certificates because they must be used by all >> secure channel protocols for mutual authentication. The node with >> the lower Node-ID in the ACP address becomes Bob, the one with the >> higher Node-ID in the certificate Alice. > > A ladder diagram would really help me here, because I'm confused about > the order of events. > > As I understand it, Alice and Bob are both flooding their AN_ACP > objectives. So, Alice sees Bob's and starts trying to connect to Bob. > But Bob may not have Alice's objective, right? So, in the case you > describe below, she just has to wait for it before she can try the > remaining security protocols? Let's call them X and Y for a moment. If X receives Y's AN_ACP, it includes Y's Node-ID as part of the address. If that is lower than X's own Node-ID, X knows that she is Alice, and can start the dialogue. She doesn't need to care whether Bob has received her own AN_ACP. Otherwise, X knows that he is Bob, so he just waits for the dialogue to start. It certainly seems to be true that if Eve gives herself the lowest possible Node-ID and only offers the weakest possible protocol, she could get in. That's assuming she has managed to enrol in the domain in the first place. Brian From nobody Wed Aug 1 19:09:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9657D130E46; Wed, 1 Aug 2018 19:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0za163U6gLc; Wed, 1 Aug 2018 19:09:05 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58A6130DCA; Wed, 1 Aug 2018 19:09:05 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id s17-v6so284841plp.7; Wed, 01 Aug 2018 19:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gNEZ+to78lVYtenHoDCf1YM8UoBPgzgxFt2hvz0W6AE=; b=R9LwyZ8UoWJlq/ie0QSSY8BHBl5QeqvIbC6DRC+nhYE7pk0TX76owi7WyrmwrNJZZl RVz02q1RGB1X1uxC1JdlSYsXMDfVv0L+AeeQw/8evZnKT2O361wjBNef/QYZF+2dIhS+ tHprDOPUfKPUrkGnekLi0e56T60RnKc+hA/PdG8ctutNKVmc7qfkKaC2Z6u2DuQc32mo UFKNSePl8Q2JNvQfH08yln2v9VT9Pkexm+Y2En8EP0r0qeM3DoCTu95AnN/JX4FKlaFE YohpglyrRv5luhNAmt+CoxgVWtSlkqq2VEp6MZ1WRdDlqIRQXMlDImY91BAZaBEIh7fm z3ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gNEZ+to78lVYtenHoDCf1YM8UoBPgzgxFt2hvz0W6AE=; b=lAfiVhhVjFd+wCmnlWNVpVfg+c4Nu65zLGICoZy6c76OuF3FvluJh2XjegQRHz55l9 EFrG0F6NJzr6hBF6p/1Rxf9AO6I2/SMpV8OwOhCs52lI16UyagrH/ynLniYfAGkmioku /Q+XPeJRgMoyouvXIigkmhLo0ViNKBv5pPn5GELQsty0GwwqJmgEkY/+5Etjc4UXzMxt Z5ODqTS8k5jWPrEIA5EFEPM0+i+Y4o/qFOPlVbns+UqYJp3FcGbBZS1Wd5KdvMU3clga B+pjpzfdxEgDKIv0b4AdIVW0XfELtZRavA48IPMtNtDQfpJKhhlk+VUx9+ytS6615dTP NYag== X-Gm-Message-State: AOUpUlG4CWzhU9raeHDLvb3duiDqvL8QIYmqKJaX2MJPniXH2BwfHsNg rKxPMFLKLjfK1qvyxMB08g4= X-Google-Smtp-Source: AAOMgpfPogoWP3uXRDNdGAvtPW0rUaxuO9XCaiotcgpE2t/4foPp65SBRsVBfSwyzn5d5nlLSbc03w== X-Received: by 2002:a17:902:8601:: with SMTP id f1-v6mr657194plo.196.1533175745217; Wed, 01 Aug 2018 19:09:05 -0700 (PDT) Received: from [192.168.178.30] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id e82-v6sm689757pfd.40.2018.08.01.19.09.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 19:09:04 -0700 (PDT) To: Benjamin Kaduk , The IESG Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <0ee7b107-26ac-f7a7-9856-e91bb0c70c04@gmail.com> Date: Thu, 2 Aug 2018 14:09:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 02:09:08 -0000 On 02/08/2018 12:30, Benjamin Kaduk wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- ... > In particular, in its current form, it's not clear to me why this document > is targeting the standards-track -- there are lots of places where > determinations of what works best or how to do some things is left for > future work. We had no choice, because this is a normative reference for GRASP, since GRASP requires at least one secure transport substrate. It's true, I think, that the draft could do a better job of separating the well-defined normative requirements from the issues that are to a considerable extent implementation-dependent. But I don't agree that it's at the Experimental stage, because it has a pedigree in proprietary code. Please consider that it is only asking for *Proposed* Standard status. > I also think the document needs to be more clear about what security > properties it does or does not intend to provide: I agree that this could be more clearly stated. By implication, it's this: https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.5.1 Brian From nobody Thu Aug 2 05:40:02 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B911130E52; Thu, 2 Aug 2018 05:40:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153321360049.22286.9920591084620858542.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2018 05:40:00 -0700 Archived-At: Subject: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-autonomic-control-plane-16: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 12:40:01 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-16: 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-anima-autonomic-control-plane/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I haven't finished reading the whole document. I agree with Benjamin and Ekr that some security aspects are underspecified. A few extra comments/questions of my own: 1) Where is locator-option formally defined? 2) 6.10.2. The ACP Addressing Base Scheme o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP addresses carried in the domain information field of domain certificates are the first 40 bits of the SHA256 hash of the routing subdomain from the same domain information field. I think you need to make clear that one needs to canonicalize (e.g. to lowercase) the routing subdomain before applying hash. You don't want some nodes using "example.com" and other "EXAMPLE.com". In the example of Section 6.1.1, the routing subdomain is "area51.research.acp.example.com" and the 40 bits ULA "global ID" 89b714f3db. 3) A.6: When Alice and Bob successfully establish the GRASP/TSL session, they typo: TSL --> TLS will negotiate the channel mechanism to use using objectives such as performance and perceived quality of the security. After agreeing on a channel mechanism, Alice and Bob start the selected Channel protocol. Once the secure channel protocol is successfully running, the GRASP/TLS connection can be kept alive or timed out as long as the selected channel protocol has a secure association between Alice and Bob. When it terminates, it needs to be re-negotiated via GRASP/ TLS. From nobody Thu Aug 2 13:42:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43FA130E04; Thu, 2 Aug 2018 13:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktMIn6NPaX36; Thu, 2 Aug 2018 13:42:08 -0700 (PDT) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 149A5130E01; Thu, 2 Aug 2018 13:42:08 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id a26-v6so1979586pfo.4; Thu, 02 Aug 2018 13:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LkP9OsS+FlCiHO8W5ptJXuUYEAJSYUUu+QhyfJOPkRY=; b=FSqGzPevybWpMQCuYieAGaB65N/7o51M3C19iJ7oW9mJb1WWb2J2YlMdIATHAl8iP9 i9U63/18t1qQ8N9UORbrH08cHXNuLJykuCFXIDkz/1rkyJXyA8WHSMgxqcm3H3SGc6fV 9OCCMx7Zm3N7iyoMaUk34MHTIcdawCvXvwdGg7OHZqONY4F7TnIcQZeiX4F+RWqAtVkJ 73cClH7YV3hXnvfIYMEBLog8TfDV2ARh6k0tqPabncAnSk9q5uzgz325uBTrpnnq6unj NA/tkNwjHWGXeq6fQUFN4e05XSSirJPGqoTBnlNuUVenGb2XbkAa9GTp2gQy5DVRqWXi gziQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LkP9OsS+FlCiHO8W5ptJXuUYEAJSYUUu+QhyfJOPkRY=; b=bRYH/vgHTdB/OIyLqwPcKXJlzpiOTpnAeqyAp3dlh2LPn/+svTqHkFcsF9HMpYBHO8 TlFtTwA0SwFaqYKQC5yUhKK1+WmwROgCfxiJfl5u/TDiU26t8g876VeJfB28yRGqk//V 349JIH6CZEDScaDorWcmTcMTV0FNEeO/bwT8Fysc50rTKlIGz/xlgBeriTvgMy2+S4A3 /gQRbOdmTRxEgdhR24nTWFmdBWJmPGCv4pMHD5I/YvXulmicXyAssLvkrKn7fK/Tjczb 98dGj/H61yphxQsDuNQj1oJij/58DssgoIOKkKBJAXpgrpqdFUmYZercPbaaliec1ghI ueLA== X-Gm-Message-State: AOUpUlHCHZWjZJVi8cB+lHqnmu3OAwvfTmuWDVCYj/zasU8vKk3VGlqQ fvX7QyYisFmncXShv6uMxVVx4V+0 X-Google-Smtp-Source: AAOMgpc/TWQM9WsSTG/qWSQsD+YlpocJ5FuYIU+WP8XLK1FNCbuH27Jn1/7TocyuQiSkYj4U/N+cVA== X-Received: by 2002:a63:e457:: with SMTP id i23-v6mr921798pgk.127.1533242527713; Thu, 02 Aug 2018 13:42:07 -0700 (PDT) Received: from [192.168.178.30] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id x80-v6sm8394327pfe.129.2018.08.02.13.42.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Aug 2018 13:42:06 -0700 (PDT) To: Alexey Melnikov , The IESG Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153321360049.22286.9920591084620858542.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Fri, 3 Aug 2018 08:42:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153321360049.22286.9920591084620858542.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-autonomic-control-plane-16: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 20:42:10 -0000 On 03/08/2018 00:40, Alexey Melnikov wrote: ... > 1) Where is locator-option formally defined? Good catch. That needs a reference to [I-D.ietf-anima-grasp]. https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-5 Brian From nobody Thu Aug 2 17:37:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D77130F36; Thu, 2 Aug 2018 17:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPzL9NYzxPqm; Thu, 2 Aug 2018 17:37:33 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 661BA130F35; Thu, 2 Aug 2018 17:37:33 -0700 (PDT) X-AuditID: 1209190e-d0fff70000007735-2d-5b63a3cb1fc7 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 60.F1.30517.BC3A36B5; Thu, 2 Aug 2018 20:37:32 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w730bQbr010869; Thu, 2 Aug 2018 20:37:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w730bM7m024576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Aug 2018 20:37:24 -0400 Date: Thu, 2 Aug 2018 19:37:22 -0500 From: Benjamin Kaduk To: Brian E Carpenter Cc: The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180803003719.GF68224@kduck.kaduk.org> References: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> <0ee7b107-26ac-f7a7-9856-e91bb0c70c04@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ee7b107-26ac-f7a7-9856-e91bb0c70c04@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nontmcXK0wbebghb9J86xWzxcdJ3J ou3iPiaLxYd3sFnM+DOR2WLh+rXMDmweO2fdZfdoOfKW1WPJkp9MAcxRXDYpqTmZZalF+nYJ XBnzPs9kKdgpUPH593KmBsYNvF2MnBwSAiYSV3ZfZOti5OIQEljMJLF64hooZwOjxNXva9kh nCtMEg8ObWUHaWERUJGY9GQZC4jNBmQ3dF9mBrFFBIwlGrtOs4I0MAvMZ5TYOvMKUAMHh7BA lUTfLA6QGl6gdd2Nm6E2NDBK9K/sZIJICEqcnPkEbCizgJbEjX8vmUB6mQWkJZb/A+vlFLCV mDj5AVi5qICyxN6+Q+wTGAVmIemehaR7FkL3AkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbrG ermZJXqpKaWbGEGhzSnJt4NxUoP3IUYBDkYlHt4LqsnRQqyJZcWVuYcYJTmYlER5+cuBQnxJ +SmVGYnFGfFFpTmpxYcYJTiYlUR433YC5XhTEiurUovyYVLSHCxK4rz3asKjhQTSE0tSs1NT C1KLYLIyHBxKErzPFwE1ChalpqdWpGXmlCCkmTg4QYbzAA2/DlLDW1yQmFucmQ6RP8Woy/Hn /dRJzEIsefl5qVLivAdAigRAijJK8+DmgFKSRPb+mleM4kBvCfMuAKniAaYzuEmvgJYwAS3J dkwEWVKSiJCSamBcpRC3/O+2DTF3LUP7tr89vqrvpg3fJz71jw+e7Xi9cMfL037qAhZH3t0S bn9+/1zl7bCLk5pfW89mMeLevtH6+tzUmatFj/BnsZWKT1m9bW1jlUbhujszVZNuXNjyg/EV q31x3vS4QmunM00CS3/FlCgsWWQlsJzB9Kbwm3N/a40V5+/+5Simp8RSnJFoqMVcVJwIADtg 2gEkAwAA Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:37:43 -0000 On Thu, Aug 02, 2018 at 02:09:08PM +1200, Brian E Carpenter wrote: > On 02/08/2018 12:30, Benjamin Kaduk wrote: > .... > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > .... > > In particular, in its current form, it's not clear to me why this document > > is targeting the standards-track -- there are lots of places where > > determinations of what works best or how to do some things is left for > > future work. > > We had no choice, because this is a normative reference for GRASP, since > GRASP requires at least one secure transport substrate. That seems like a pretty specious argument -- it assumes as a prior that GRASP also must be standards-track, and ignores the well-established downref process. On the other hand, the ANIMA milestones do say to "submit autonomic control plane solution to the IESG (Standards Track)". (The charter itself does not say anything about document status.) On the gripping hand, the IESG does have the authority to determine the track on which a document is published. > It's true, I think, that the draft could do a better job of > separating the well-defined normative requirements from the issues > that are to a considerable extent implementation-dependent. But I But I'd prefer to see these improvements made than debate the above. > don't agree that it's at the Experimental stage, because it has a > pedigree in proprietary code. Please consider that it is only > asking for *Proposed* Standard status. Could you enlighten me about this pedigree? Is it just the Autonomic Networking project from Cisco, or is there more (or even indepnedent implementations)? > > I also think the document needs to be more clear about what security > > properties it does or does not intend to provide: > > I agree that this could be more clearly stated. By implication, > it's this: > https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.5.1 Thanks, that's a great start. -Benjamin From nobody Thu Aug 2 17:45:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6595C130E51; Thu, 2 Aug 2018 17:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je769_INmWKY; Thu, 2 Aug 2018 17:45:53 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D06E130DE3; Thu, 2 Aug 2018 17:45:53 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id b90-v6so991815plb.0; Thu, 02 Aug 2018 17:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2k026SJbXwZK4vN7IQJe1DRqOx8wU54hCsB0aufUoHQ=; b=UBJdlwthGz0HHXP7a9XiSCJEkyWALRAeqjLQRkVTFOothA4KZqRPoTXP9RA6uXk/DN iqp1I3qWp45pFhSCMqMBKPUl9PzsjLd7C4oeHeHLMYnY6sgVN6nLlT19B8+4geydP5ZV NMoZ+MCcrMMDiEgKcNzlxUQ5n5r07MgYbAFJ3uzoERZQSbDD0ctI/sCp/f/hojhCdMcc fm45Mxm+kOeXfiIbOqGP/E5PkdjLVMrJblHlxq0vxBjznabzmuDTORB0UjlXY9ZvkM+3 MuR/QXaL/JWsiK0ex+sXvtqzbaSvj1lvslWDoeA3pg7JtvqmrHWnXH92MDnfZTu18nnn HmsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2k026SJbXwZK4vN7IQJe1DRqOx8wU54hCsB0aufUoHQ=; b=tHIOOtIbz/clfFpAqXiwK77NiAwJfk7cXRJ6APLBX4819mltWdWM2MmPnPcMuMXz/U Q7/3D/HTBOc3WbeYhL7NKKptnEyKBYIValtO5VgAnYqMwpDU+t2LQHtgvcRfV+Ou4hIg Ldf6z/Jgui5SC/RTFaHHXXXHLqMRqomohz8pgV9Q4tR8PSe+YEkEOKpr74PuVe7nPNFd lQ4Us1q1kNJDDZjGwmrd8SMgAOu/e0gqLKmwn5oKUTHxAKiEwt8kYNhAsOewWT3Zit0i u+9piu3ovGEoF/csGI8IkMdYxDKT6z5iuLa0Sl2EPTvv56WccV+UlhfzOkQcUwf7dBmT 7+lA== X-Gm-Message-State: AOUpUlGI8wHkJykHQu2Vsm8PESob95AG0D9IcHqwGFibY+OBaTmHE8CA ksOh0V7pr78CHIItfGc8MWw= X-Google-Smtp-Source: AAOMgpewiOwVBbaBOLWv8faacT/PF1ZlM51K4Ntcm4xgzIMjrHxSjCzty8zvlL13V1O8A+iq4AC4GA== X-Received: by 2002:a17:902:4d45:: with SMTP id o5-v6mr1441510plh.78.1533257152838; Thu, 02 Aug 2018 17:45:52 -0700 (PDT) Received: from [192.168.178.30] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id b67-v6sm5457480pfd.74.2018.08.02.17.45.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Aug 2018 17:45:51 -0700 (PDT) To: Benjamin Kaduk Cc: The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> <0ee7b107-26ac-f7a7-9856-e91bb0c70c04@gmail.com> <20180803003719.GF68224@kduck.kaduk.org> From: Brian E Carpenter Message-ID: <76217de0-c18a-bad2-deb1-ce954ff58230@gmail.com> Date: Fri, 3 Aug 2018 12:45:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180803003719.GF68224@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:45:56 -0000 On 03/08/2018 12:37, Benjamin Kaduk wrote: > On Thu, Aug 02, 2018 at 02:09:08PM +1200, Brian E Carpenter wrote: >> On 02/08/2018 12:30, Benjamin Kaduk wrote: >> .... >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >> .... >>> In particular, in its current form, it's not clear to me why this document >>> is targeting the standards-track -- there are lots of places where >>> determinations of what works best or how to do some things is left for >>> future work. >> >> We had no choice, because this is a normative reference for GRASP, since >> GRASP requires at least one secure transport substrate. > > That seems like a pretty specious argument -- it assumes as a prior that > GRASP also must be standards-track, and ignores the well-established > downref process. Sorry, I should indeed have said that this was always the working group model, that the three infrastructure documents (GRASP, ACP and BRSKI) should be standards track. That's why GRASP is in MISSREF state; naturally I wouldn't (as GRASP editor) object to a downref instead, but it's not ideal. > On the other hand, the ANIMA milestones do say to "submit autonomic > control plane solution to the IESG (Standards Track)". (The charter itself > does not say anything about document status.) On the gripping hand, the > IESG does have the authority to determine the track on which a document is > published. > >> It's true, I think, that the draft could do a better job of >> separating the well-defined normative requirements from the issues >> that are to a considerable extent implementation-dependent. But I > > But I'd prefer to see these improvements made than debate the above. Certainly. But not being a co-author, that's not my choice to make. >> don't agree that it's at the Experimental stage, because it has a >> pedigree in proprietary code. Please consider that it is only >> asking for *Proposed* Standard status. > > Could you enlighten me about this pedigree? Is it just the Autonomic > Networking project from Cisco, or is there more (or even indepnedent > implementations)? I think the authors should answer that one. >>> I also think the document needs to be more clear about what security >>> properties it does or does not intend to provide: >> >> I agree that this could be more clearly stated. By implication, >> it's this: >> https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.5.1 > > Thanks, that's a great start. The authors are of course most welcome to borrow it ;-) Brian From nobody Fri Aug 3 02:26:20 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB51D130EC4; Fri, 3 Aug 2018 02:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 9mQhPwET9rUF; Fri, 3 Aug 2018 02:26:10 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12817130EC1; Fri, 3 Aug 2018 02:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8726; q=dns/txt; s=iport; t=1533288369; x=1534497969; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=as2YIzBuMUblr/OdgUxJww4npwqzjPfuGFcIR/z79pw=; b=TbjG8rJ83UbNiLB9B2sQ5CiUsQpCxnKl+7gngU6m8QXJG0r5Fhstnt+d VP8zdC1QNL/YmnV1nmMg31TPugcEAxUodibUeIVd1E92DsQROAxFfc2I0 mdDoDYuBTxbCWKYszWvSrZG9QQ3n2N88/MemIxbIcMANVO/i08DFbCf4w Q=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAgCwHmRb/xbLJq1dDgwBAQEBAQI?= =?us-ascii?q?BAQEBCAEBAQGEMW0ShCaIaI1FLZBEhxUIAyOESQKDKDgUAQIBAQIBAQJtHAy?= =?us-ascii?q?FNwEFI1YQCxIGIwcCAkkOBgEMCAEBgxwBgX8PsmyBLh+KJwoFiR+CAIE5gW1?= =?us-ascii?q?+gxsBAQOEX4JVApotCYNpgVlXiSUGiDaFY4pkh3KBWCGBUjMaCBsVgyWCTIh?= =?us-ascii?q?IhQQ8PZAsAQE?= X-IronPort-AV: E=Sophos;i="5.51,438,1526342400"; d="asc'?scan'208,217";a="5540343" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2018 09:26:07 +0000 Received: from [10.61.67.85] (ams3-vpn-dhcp853.cisco.com [10.61.67.85]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w739Q7oP001742; Fri, 3 Aug 2018 09:26:07 GMT To: Benjamin Kaduk , The IESG Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Fri, 3 Aug 2018 11:26:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uiFcmCfbB2zLgO6AA6mr0X9TmtLv7vnEB" X-Outbound-SMTP-Client: 10.61.67.85, ams3-vpn-dhcp853.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 09:26:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uiFcmCfbB2zLgO6AA6mr0X9TmtLv7vnEB Content-Type: multipart/mixed; boundary="VannswLelwRzkyn0kN1JxCDhOfUMYxZSg"; protected-headers="v1" From: Eliot Lear To: Benjamin Kaduk , The IESG Cc: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) References: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> In-Reply-To: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> --VannswLelwRzkyn0kN1JxCDhOfUMYxZSg Content-Type: multipart/alternative; boundary="------------C500EF5BE144AF7C3449290E" Content-Language: en-US This is a multi-part message in MIME format. --------------C500EF5BE144AF7C3449290E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, With apologies to the WG for adding a late comment.=C2=A0 On 02.08.18 02:30, Benjamin Kaduk wrote: > In particular, in its current form, it's not clear to me why this docum= ent > is targeting the standards-track -- there are lots of places where > determinations of what works best or how to do some things is left for > future work. Are there lots of implementations or consumers clamoring = for > this stuff that it makes sense to go for PS as opposed to Experimental = (so > as to figure out what works and nail down a slimmer protocol for the > standards track)? I see in A.4 that the choice of RPL was motivated by= > experience with a pre-standard version of ACP; it would have been great= to > hear more about those deployments in an Implementation Status section (= per > RFC 7942) or the Shepherd writeup. FWIW I do not think experimental is appropriate.=C2=A0 Experiments have beginnings and endings, and exit conditions.=C2=A0 Nor for PS should an implementation report be required (quite the opposite).=C2=A0 I think PS = is more appropriate.=C2=A0 This is a pretty big document, and it is architectural in nature, and there are multiple building blocks in this document.=C2=A0 How they fit together may change based on operational experience, and to me that means that a future revised PS of this document would be considerably firmer.=C2=A0 To require that everything b= e spelled out for this PS would be a bit much. On the other hand, there are no fewer than *44* uses of the word "future" prior to the appendices.=C2=A0 Some of this is a certain writing= style for a general architecture, but at the end of the day I was left wondering whether https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-01 should be taken to heart in this instance.=C2=A0 In particular, the following stand= s out to me: > "rsub" is optional; its syntax is defined in this document, > but its semantics are for further study. Understanding the benefits= > of using rsub may depend on the results of future work on enhancing > routing for the ACP. Why define rsub now if it has no semantic value?=C2=A0 Is that the garnis= h that nobody eats? I see three different things going on in this document: * Some real future proofing with extension mechanisms. * Some implicit and explicit forward references to work that is a bit behind this work.=C2=A0 I think the purpose of this text is to justif= y particular functionality as fulfilling some envisioned dependency. * Stuff like the above that doesn't seem well justified. The big concern with all of this is when an extension is used on one system and no by another, will there be interoperability problems?=C2=A0 Especially as relates to ACP domain membership.=C2=A0 I don't have a good= feel for that in a few of these cases. Eliot --------------C500EF5BE144AF7C3449290E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ben,

With apologies to the WG for adding a late comment.=C2=A0

On 02.08.18 02:30, Benjamin Kaduk wrote:
In particular, in its current form, it's not clear t=
o me why this document
is targeting the standards-track -- there are lots of places where
determinations of what works best or how to do some things is left for
future work.  Are there lots of implementations or consumers clamoring fo=
r
this stuff that it makes sense to go for PS as opposed to Experimental (s=
o
as to figure out what works and nail down a slimmer protocol for the
standards track)?  I see in A.4 that the choice of RPL was motivated by
experience with a pre-standard version of ACP; it would have been great t=
o
hear more about those deployments in an Implementation Status section (pe=
r
RFC 7942) or the Shepherd writeup.

FWIW I do not think experimental is appropriate.=C2=A0 Experiments ha= ve beginnings and endings, and exit conditions.=C2=A0 Nor for PS should = an implementation report be required (quite the opposite).=C2=A0 I think= PS is more appropriate.=C2=A0 This is a pretty big document, and it is architectural in nature, and there are multiple building blocks in this document.=C2=A0 How they fit together may change based on operational experience, and to me that means that a future revised PS of this document would be considerably firmer.=C2=A0 To require th= at everything be spelled out for this PS would be a bit much.

On the other hand, there are no fewer than *44* uses of the word "future" prior to the appendices.=C2=A0 Some of this is a certain wri= ting style for a general architecture, but at the end of the day
I was left wondering whether https://tools.ietf.org/html/draft-t= homson-use-it-or-lose-it-01 should be taken to heart in this instance.=C2=A0 In particular, the following stands out to me:

  "rsub" is optional; its syntax is defined in this document,
   but its semantics are for further study.  Understanding the benefits
   of using rsub may depend on the results of future work on enhancing
   routing for the ACP.

Why define rsub now if it has no semantic value?=C2=A0 Is that the garnish that nobody eats?

I see three different things going on in this document:
  • Some real future proofing with extension mechanisms.
  • Some implicit and explicit forward references to work that is a bit behind this work.=C2=A0 I think the purpose of this text is= to justify particular functionality as fulfilling some envisioned dependency.
  • Stuff like the above that doesn't seem well justified.

The big concern with all of this is when an extension is used on one system and no by another, will there be interoperability problems?=C2=A0 Especially as relates to ACP domain membership.=C2=A0= I don't have a good feel for that in a few of these cases.

Eliot


--------------C500EF5BE144AF7C3449290E-- --VannswLelwRzkyn0kN1JxCDhOfUMYxZSg-- --uiFcmCfbB2zLgO6AA6mr0X9TmtLv7vnEB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltkH7AACgkQh7ZrRtnS ejPggggAk4f55qk3geSY4oqemQLHY3Q0FWdJ2u48M1Xb1FRUluIVNtymHZKMa9Nv Wu07/hF2b9EMqiLJvyaweTglOgUIqYHgm6/W5zh7MPkFL8DNS4mNchUNcW8o0Zck vENTyWVuPq7x4zz2a4RJemX4bkSgObzCfbqC08cpgWLBQcy62E55+KMdvGNFLXN4 UX6edtTYEbsectcarV0mZTbA3xcjr5YpJ1DsVqep2riUFtt9R2jBWV7ASSG8Bypu 9MVM3yaDIT4Qe6kmK0KYmptLMfzIFjqQPJe5OsYp8qkqV/AMINOwcST2odQR7RLH ZTiWJzeekPKqyGHHUX1DHACOdVWNKQ== =IknZ -----END PGP SIGNATURE----- --uiFcmCfbB2zLgO6AA6mr0X9TmtLv7vnEB-- From nobody Fri Aug 3 15:55:42 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F02C130DD3; Fri, 3 Aug 2018 15:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQghziRz9r1F; Fri, 3 Aug 2018 15:55:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE381271FF; Fri, 3 Aug 2018 15:55:36 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8A97F58C4C4; Sat, 4 Aug 2018 00:55:32 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7CF444E0721; Sat, 4 Aug 2018 00:55:32 +0200 (CEST) Date: Sat, 4 Aug 2018 00:55:32 +0200 From: Toerless Eckert To: Eliot Lear Cc: Benjamin Kaduk , The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180803225532.r6d4oiwyio6zdzll@faui48e.informatik.uni-erlangen.de> References: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 22:55:40 -0000 On Fri, Aug 03, 2018 at 11:26:08AM +0200, Eliot Lear wrote: > On the other hand, there are no fewer than *44* uses of the word > "future" prior to the appendices. Yepp. But you're too late, Alissa was already complaining about it, so i am just trying to improve the situation for -17. Just taking a break to answer to your email... Actually, the consistent use of the word "future" is the most helpful part of this problem, because it allows me to find all those places easily. ;-) > Some of this is a certain writing style for a general architecture, Nah, don't say this, our charter explicitly disallows archtiecture work, we pulled the permission to do the reference-model draft against a lot of resistance. All the "future" mentions where really derived from cutting ambitions 2? years ago to not try to boil the ocean but stick the normative part to what we where able to work out from practical experience with implementation or suficient confidence of experience, and highlight the rest as futures. I'll probably want to create a summary of "futures" at the end of the doc, so we do not forget the bits we want to do, but didn't get around But yets, will definitely want to clean up primarily the normative part of the doc, not the informative parts so much. > but at the end of the day > I was left wondering whether > https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-01 should be > taken to heart in this instance. Definitely. I think ACP does actually do that. Which WG is this proposed to be adopted by (or IAB ?). >   In particular, the following stands out to me: > > > "rsub" is optional; its syntax is defined in this document, > > but its semantics are for further study. Understanding the benefits > > of using rsub may depend on the results of future work on enhancing > > routing for the ACP. > > Why define rsub now if it has no semantic value?  Is that the garnish > that nobody eats? In japanese cuisine, all garnish is edible and delicious. Yes, that text was the worst example offender in -16. There actually is a great current use-case for rsub today that can be solved by the ACP normative functions and existing router configuration, which is what will be used as justification in -17: Using different rsub for separated ACP areas connected via non-ACP capable "core", because .e.gg: core routers don't support ACP (yet) - and when later on core nodes do support ACP, no change is necessary, just removal of the manual configs to interconnect those areas. > I see three different things going on in this document: > > * Some real future proofing with extension mechanisms. Right. The example of that is the ability to not include an ACP address in the certificate because ACP peers might have a different way to derive their ACP address (which is a future as we have not defined such a mechanism). For a node compliant with this ACP doc, the acp-address MUST be present in the cert, but it must also recognize a peer (during IKE/TLS authentication) as a valid peer that does NOT have an acp-address in the certificate. This was the second big issue not well described that i had to figured out in the text from Alissas review. > * Some implicit and explicit forward references to work that is a bit > behind this work.  I think the purpose of this text is to justify > particular functionality as fulfilling some envisioned dependency. Yeah, how do we call this class better: "Stuff that contributors to the WG wanted to have ACP do, but that didn't make the cut to be defined in this spec - for various reasons. So i think i'll move breadcrumps for those points out of the normative part, but i do not want to loose them. > * Stuff like the above that doesn't seem well justified. I hope the doc has none of that but only (as above example) * Useful intentions with bad writing. > The big concern with all of this is when an extension is used on one > system and no by another, will there be interoperability problems?  > Especially as relates to ACP domain membership.  I don't have a good > feel for that in a few of these cases. Right now i feel quite confident that this is all ok, but i think i will learn the real solution once i am through with Ekrs review. Right now, domain membership is really meant to be just normal Internet PKI certificte validation plus use of the same trust anchors plus the check that the local acp-domain-name is the same as that of the peer. But i think Eric has a bunch of issues with the way we wrote that. > Eliot > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Aug 7 12:40:12 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F110130F82; Tue, 7 Aug 2018 12:40:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk CC: ibagdona@gmail.com, draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , anima-chairs@ietf.org, Sheng Jiang , anima@ietf.org, jiangsheng@huawei.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153367080860.2502.9826863456005441042.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2018 12:40:08 -0700 Archived-At: Subject: [Anima] Last Call: (A Reference Model for Autonomic Networking) to Informational RFC X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 19:40:08 -0000 The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'A Reference Model for Autonomic Networking' as Informational RFC 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 2018-08-21. 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 describes a reference model for Autonomic Networking. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Aug 7 16:16:10 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FFF12426A; Tue, 7 Aug 2018 16:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <153368376189.2278.4443603469664734659@ietfa.amsl.com> Date: Tue, 07 Aug 2018 16:16:01 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-17.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 23:16:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-17.txt Pages : 138 Date : 2018-08-07 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-17 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 7 16:19:05 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3154F131118; Tue, 7 Aug 2018 16:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDJu9Q0rS2mD; Tue, 7 Aug 2018 16:19:02 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8C21310DD; Tue, 7 Aug 2018 16:19:01 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0D95758C507; Wed, 8 Aug 2018 01:18:56 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8A37F4E0C64; Wed, 8 Aug 2018 01:18:56 +0200 (CEST) Date: Wed, 8 Aug 2018 01:18:56 +0200 From: Toerless Eckert To: Liang Xia Cc: secdir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180807231856.mtngivnzifh5uj2j@faui48e.informatik.uni-erlangen.de> References: <151944288538.13853.12008661353663855742@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151944288538.13853.12008661353663855742@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Secdir early review of draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 23:19:04 -0000 Liang: Just posted draft version -17 does include the fix from your review i missed to put into -16. Thanks! Toerless On Fri, Feb 23, 2018 at 07:28:05PM -0800, Liang Xia wrote: > Reviewer: Liang Xia > Review result: Has Issues > > In general, this document is well-written and considers security issues > carefully throughout the whole architecture. > > nits: > Abstract: /or not misconfigured/or misconfigured/ > > the fifth paragraph of section 6.1: the last ")" is redundant, therefore can be > deleted > > some section titles don't comply the rule of starting from a capital letter > > section 6.5 > /("IP security", see [RFC4301] and "Internet Key Exchange protocol version 2", > see [RFC7296]/("IP security", see [RFC4301] and "Internet Key Exchange protocol > version 2", see [RFC7296])/ > > suggestion: > all the Figures (e.g., Figure 1,2...) should have a title for explanation > > section 2, please update the last paragraph to reference RFC8174 to indicate > that lowercase versions of the keywords are not normative > > Section 11 (Security Considerations) Since section 9.2 has described the > self-protection properties of ACP well, it may be useful in this section to > mention them as a whole. -- --- tte@cs.fau.de From nobody Tue Aug 7 16:26:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDE5130E87; Tue, 7 Aug 2018 16:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaaZuLNJS-bH; Tue, 7 Aug 2018 16:26:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1D212DD85; Tue, 7 Aug 2018 16:26:49 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DCC1758C507; Wed, 8 Aug 2018 01:26:44 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id CCC9C4E0C64; Wed, 8 Aug 2018 01:26:44 +0200 (CEST) Date: Wed, 8 Aug 2018 01:26:44 +0200 From: Toerless Eckert To: Elwyn Davies Cc: gen-art@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180807232644.5avcaxrnrt2phz3o@faui48e.informatik.uni-erlangen.de> References: <153308194697.3384.1689302422182872423@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153308194697.3384.1689302422182872423@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Genart telechat review of draft-ietf-anima-autonomic-control-plane-16 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 23:26:52 -0000 Thanks a lot Elwyn Changes for your review have been committed together with changes for Alissa's review into just posted -17 rev of the doc. rfcdiff here: http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-17.txt I hope all the issues you raised ahve been resolved. Point by point replies inline. Cheers toerless On Tue, Jul 31, 2018 at 05:05:47PM -0700, Elwyn Davies wrote: > Reviewer: Elwyn Davies > Review result: Ready with Nits > > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-anima-autonomic-control-plane-16 > Reviewer: Elwyn Davies > Review Date: 2018-07-31 > IETF LC End Date: 2018-02-26 > IESG Telechat date: 2018-08-02 > > Summary: > This document is ready but has a fair number of nits still to fix, particularly > in the earlier part of the document. There are also some language issues to > address which the RFC Editor will deal with. My issues from the Last Call > review have been addressed. > > Major issues: > None > > Minor issues: > None > > Nits/editorial comments: > General: There are three remaining examples of "intent" rather than "Intent". ACK > General: There are five instances of the construction -> "quoted text" () in > s2. Need to remove -> and () in each case. This may be down to tool problems - > there is a comment in the revisions list. DEFERRED, added instruction to text: [RFC Editor: WG/IETF/IESG review of the terms below asked for references betwen these terms when they refer to each other. The only option in RFC/XML i found to point to a hanging text acronym definition that also displays the actual term is the format="title" version, which leads to references like '->"ACP domain certificate" ()'. I found no reasonable way to eliminate the trailing '()' generated by this type of cross references. Can you please take care of removing these artefacts during editing (after conversion to nroff ?). Also created ticket to ask for xml2rfc enhancement to avoid this in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. > S1, para 5: s/The ACP is designed to remains/The ACP is designed to remain/ ACK > s1, para 5: s/The details how this achieved are defined in Section 6./The > details of how this achieved are described in Section 6./ ACK (also added "is" after "this". > s1, bullet point #1: s/supports directly/directly supports/ ACK > s1, bullet point #3: s/network/(Data-Plane) network/ > S1, last para: s/Defined Networking (SDN) (see [RFC7426]), style > automation/Defined Networking- (SDN-)style (see [RFC7426]) automation/ ACK > S1.1, para 2: Operational Technology is a term that is not very well-known - a > reference would help. Unfortunately it seems that the text of ISA99 that > defines the term is not freely available. Suggestions of a freely available > alternative? Added xref to terminology section, added term to terminology section, used Wikipedia URL and first line description from it : "The hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as valves, pumps, etc". OT networks are today in most cases well separated from Informationn Technology (IT) networks. > s1.1, para 3: Although RPL is in the glossary in s2, this instance occurs > before s2 is announced, so it would be worth adding RPL (Routing Protocol for > Low-power and Lossy Networks - RFC6550) ACK > s2, "ACP address": s/the ->"ACP domain certificate" ()./the "ACP domain > certificate". See above. I specifically added "->" because thats whats typically done in other terminologies when there is a reference to another term. > S2, "ACP Domain": 'of nodes with ->"ACP domain' . Remove "->" and ()? Likewise. I have tried to find some better examples of cross-references between words in a terminology section of an RFC, but couldn't find any. Aka: lets RFC editor figure it out and/or Hendrik via tooling and trac case. > s2. "ACP Loopback interface": Need to expand VRF on first use. ACK > s2, "ACP secure channel": As wrtten this equates a security association with a > secure channel. Suggest: NEW: ACP secure channel: A sequence of links > established hop-by-hop between adjacent ACP nodes with a security association > established for each link using the ACP secure channel protocol and the ACP > Domain Certificate. The channel is used to carry traffic of the ACP VRF > separated from Data-Plane traffic in-band over the same links as the > Data-Plane. ENDS Ok, got the point that the channel is not just an association but the actual data channel, but your suggestion was binding the term to a sequence of links, which i think is wrong too. Replaced now with: A cryptographically authenticated and encrypted data connection established between (normally) adjacent ACP nodes to carry traffic of the ACP VRF secure and isolated from Data-Plane traffic in-band over the same link/path as the Data-Plane. > s2, "Data-Plane": s/non-autonomic/by means other than autonomically/ ACK > s2, "GRASP": s/required/REQUIRED/ I have refrained from considering the terminology section to be normative so far because i don't think i have ever seen this being done in other RFCs, so i am only using those uppercase words in the normative sections. Let me know if you disagree. > s2, "in-band (management)": fix up two instances of -> ... (). see above. > s2, "Node-ID": s/bit/bits/; Due to a missing XML introducer, the reference to > s6.10.5 hasn't been translated. ACK > s2, "(virtual) out-of-band network": fix up one instance of -> ... (); see above > s/where historically/were historically/; In next to last sentence s/out of > band/out-of-band/ ACK > s2, "ULA": s/are the first 48 bit/is the first 48 bits/ changed to "are the first 48 bits" > s2, "(ACP) Zone": s/protocols details/protocol's details/ ACK > s3.1: s/This way/In this way/; possibly s/other processes/single instamces of > other processes/??? ACK > s3.2, last para: s/like/such as/ [like: Yuck!] ACK *yikes* several of these sneaked into the text, tried to eliminate all of them.. > s3.3, para 1: s/managment/management/ ACK > s3.3, first bullet: s/out of Band/out-of-Band/ Actually now using consistently out-of-band > s4, ACP2: The phrase "(can block easily at edge)" needs additional explanation. Changed to "infrastructure security (filtering based on known address space)". > s4, ACP4: s/generic. Usable/generic, that is it MUST/ ACK. > s4, last para: Need to expand eACP. s/Th eACP/The ACP/ ;-) > s5, 2nd 'Note' bullet: s/auto discovery/auto-discovery/ Text changed due to Alissas discuss. > s5, lata para: s/This way/In this way/ ACK > s6.1, para 4: Trailing colon s/b period. ACK > s6.1.1, last para on page 20: s/":" are not/The character ":" is not/ ACK > s6.1.1, last but 2 para: s/information element it,/information > element,/(probably) ACK > s6.1.2. next to last bullet: s/peers certificate/peer's certificate/; s/peers > domain/peer's domain/ ACK > s6.1.3.1, last para: Expand ttl on first use. ACK > s6.1.3.5, para 4: s/ACP nodes domain certificate/ACP node's domain > certificate/; s/nodes ACP/node's ACP/ ACK > s6.3, para 2: s/State Less/Stateless/ Actually StateLess as its used to expand SLAAC > s6.11.1.1, para 1: s/reliable network reasonably fast/reliable network with > reasonably fast/ ACK > s6.12: s/hop by hop/hop-by-hop/ ACK > s8.2.1, bullets 2 and 3: s/vrf/VRF/ ACK Many thanks again! From nobody Tue Aug 7 16:33:09 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31358130E87; Tue, 7 Aug 2018 16:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJRpm8UVBBEw; Tue, 7 Aug 2018 16:33:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239DF12DD85; Tue, 7 Aug 2018 16:33:00 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DA90E58C507; Wed, 8 Aug 2018 01:32:54 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id CC5434E0C64; Wed, 8 Aug 2018 01:32:54 +0200 (CEST) Date: Wed, 8 Aug 2018 01:32:54 +0200 From: Toerless Eckert To: "Pascal Thubert (pthubert)" Cc: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Message-ID: <20180807233254.ymhdkzmkyjntr4ys@faui48e.informatik.uni-erlangen.de> References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> <20180608231440.maxyvrcam5yt5ttm@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 23:33:03 -0000 Pascal: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-17 Just posted -17. I found the time to add the picture you where asking for re. multiple NOCs. Like any good small print, it is all the way at the bottom, A.10.4. Wrt to the formatting issue, can't remember if we discussed this already, but that should have been fixed through Hendrik fixing up the tooling. In any case, i can not see rendering issues anymore for neither the old -16 nor the just posted -17. Cheers Toerless On Mon, Jun 11, 2018 at 09:55:29AM +0000, Pascal Thubert (pthubert) wrote: > Dear Toerless and authors: > > I reviewed -16 and I'm happy with the changes made for my comments. All set on my side. > I noted that item 2 in the Introduction has a ref that opens a bracket that does not close; this creates a presentation issue on the htmlized version. > > > > -----Original Message----- > > From: Toerless Eckert > > Sent: samedi 9 juin 2018 01:15 > > To: Pascal Thubert (pthubert) > > Cc: iot-dir ; ops-dir@ietf.org; int-dir@ietf.org; > > anima@ietf.org; draft-ietf-anima-autonomic-control-plane@ietf.org > > Subject: Re: An IOT DIR review of draft-ietf-anima-autonomic-control-plane > > > > Thanks, pascal. the "standard (issue)" got fixed too in -14, forgot to include a > > specific note to you. > > > > Cheers > > Toerless > > > > On Tue, May 22, 2018 at 02:06:17PM +0000, Pascal Thubert (pthubert) wrote: > > > Hello Toerless: > > > > > > > > Thanks, Pascal, sorry for the delay, > > > > > > > > Comments inline. > > > > > > > > Version: > > > > > > > > https://raw.githubusercontent.com/anima-wg/autonomic-control- > > > > plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima- > > > > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14. > > > > txt > > > > > > > > > > > > Diff to prior version (-14 for Joel Halpern) > > > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.gi > > > > thubusercon > > > > tent.com/anima-wg/autonomic-control- > > > > plane/8b4436edaa720eadb5839120400fd1e89d3289b0/draft-ietf-anima- > > > > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > > > > 14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic- > > > > control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf- > > > > anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-pla > > > > ne- > > > > 14.txt > > > > > > > > Will commit as -14 when i am through with the other -13 feedback. > > > > > > > > Cheers > > > > Toerless > > > > > > > > > > > > On Mon, Feb 26, 2018 at 05:25:58PM +0000, Pascal Thubert (pthubert) > > > > wrote: > > > > > Reviewer: Pascal Thubert on behalf of IOT-DIR; > > > > > > > > > > I am an assigned IoT directorate reviewer for > > > > > draft-ietf-anima-autonomic- > > > > control-plane-13. > > > > > > > > > > These comments were written primarily for the benefit of the INT > > > > > and OPS > > > > Areas Directors from the IoT perspective. Document editors and > > > > shepherd(s) should treat these comments just like they would treat > > > > comments from any other IETF contributors and resolve them along > > > > with any other Last Call comments that have been received. For more > > > > details on the IoT Directorate, please see > > > > https://datatracker.ietf.org/group/iotdir/about/ and for > > > > Directorates in general please see > > https://www.ietf.org/about/groups/directorates/. > > > > > > > > > > > > > > > I'll be away for the next 2 weeks and could not finish the review > > > > > in time for > > > > this heavy document, but at least I made it through till the RPL > > > > section. In the interest of time, let me share what I already have. > > > > > > > > > > > > > > > > > > > > Summary > > > > > > > > > > ------------- > > > > > > > > > > The summary of the review is that the document is Ready for > > > > > Publication, > > > > with comments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Major comments > > > > > > > > > > ------------------------ > > > > > > > > > > > > > > > > > > > > - " in-band" and "out of band network " > > > > > > > > > > should be defined since it is fundamental to understand that the > > > > > ACP takes place in the same physical links as the data plane, as > > > > > opposed to dedicated management ports (correct?); > > > > > > > > Good point, done. (got a bit too long to paste here, so pls. check diff). > > > > > > > > > > > > > > - Section 3; the IOT certainly could use an ACP. It would be useful to > > > > scope the feature that is proposed in this document, whether it is > > > > compatible of not with constrained environments, whether it needs > > > > adaptations, point on Michael's enrollment draft. It would also be > > > > useful to indicate whether the ACP works between L3 bridges, IOW > > > > whether ACP operates the same (over IP) regardless of the packet > > > > forwarding layer in the data plane; > > > > > > > > Not sure i understand the "point on Michaels enrollment draft". > > > > > > > > I am happy to add pointers to variations of ACP design aspects for > > > > informational purposes to show that/how it can be modified, but > > > > Michaels drafts i think are all variation of the BRSKI design, so > > > > the ACP would be completly unaffected by them, right ? > > > > > > > [PT>] I guess you're right there > > > > > > > Wrt. constrained devices and L2. I didn't want to touch section 3 > > > > for what you suggested because that really a very formulistic > > > > section going back to the charter 1 justifications of ANIMA and > > > > matched with the three numbered use case explanations in the > > introduction. > > > > > > > [PT>] OK > > > > > > > Instead i wrote text at the end of the introduction, now section > > > > 1.1, This got longer than i hoped, but it was really a big missing > > > > piece to pitch the ACP and give early on context for implementers > > > > and reminding of the charter goal of reusing the best available existing > > protocols/function. > > > [PT>] > > > [PT>] I read it, very cool. > > > > > > > > The text got longer specifically also because i did not want to fall > > > > into the trap of making claims whether or not ACP is applicable to > > > > specific IOT networks or (even worse) assuming IOT is always > > > > constrained. Therefore mentioning of OT networks (IMHO big part of > > > > IOT, and often totally non-constrained), explanation of why RPL, and > > > > at the end a statement about constrained environments. There is also a > > new paragraph in 10.8 about TCP/TLS vs. > > > > CoAP/DTLS as a possible constained environment variant in the future. > > > > > > > > > - " Inside the ACP VRF, each node sets up a loopback interface with > > its > > > > ULA IPv6 address" > > > > > This is the first time, IPv6 is discussed; would have been nice to > > > > > introduce that the Node has IPv6, that it needs a ULA and that ACP > > > > > assigns it. This discussion could be done in conjunction with the > > > > > comment above; > > > > > > > > Actually, section 1. introduction already mentions that the ACP > > > > provides > > > > IPv6 and that the stable-connectivity document describes how to > > > > interoperate with IPv4 only OAM. > > > > > > > > I added to the new 1.1 section (see above) the following paragraph, > > > > which i hope is a useful context setting and pitch: > > > > > > > > The ACP uses only IPv6 to avoid complexity of dual-stack ACP > > > > operations (IPv6/IPv4). Nevertheless, it can without any changes be > > > > integrated into even otherwise IPv4-only network devices. The > > > > data-plane itself would not need to change, it could continue to be > > > > IPv4 only. For such IPv4 only devices, the IPv6 protocol itself > > > > would be additional implementation footprint only used for the > > > > ACP. > > > [PT>] OK > > > > > > > > > > > > - About "The ttl > > > > > parameter SHOULD be 3.5 times the period so that up to three > > > > > consecutive messages can be dropped before considering an > > > > > - announcement expired. " > > > > > > > > > > This is the only discussion on the ttl field of the M_FLOOD. > > > > > Though its > > > > meaning is quite obvious, the behavior associated to it should be defined. > > > > > > > > Added: > > > > > > > > When a service announcer > > > > using these parameters unexpectely dies immediately after sending > > > > the M_FLOOD, receivers would consider it expired 210 seconds later. > > > > When a receiver tries to connect this dead service earlier, it will > > > > experience a failing connection and use that as an indication the > > > > service is dead and select another instance of the same service instead. > > > > > > > [PT>] OK > > > > > > > > - "In the above (recommended) example the period of sending of > > the" > > > > > Is this RECOMMENDED IOW normative?? > > > > > > > > Hmmm... Sure, why not. Less guessing/experiementation for this. > > > > Modified to RECOMMENDED. > > > [PT>] OK > > > > > > > > > > > > - Text P 25 says "At this time in the lifecycle of ACP nodes, it is > > unclear > > > > whether it > > > > > is feasible to even decide on a single MTI (mandatory to > > > > > implement) security association protocol across all ACP nodes" > > > > > but then P27 "It MUST support ESP > > > > > with AES256 for encryption and SHA256 hash and MUST NOT permit > > > > weaker > > > > > crypto options." > > > > > > > > > > and then " A baseline ACP node MUST support IPsec natively and MAY > > > > support IPsec > > > > > via GRE. A constrained ACP node MUST support dTLS. ACP nodes > > > > > connecting constrained areas with baseline areas MUST therefore > > > > > > > > > > support IPsec and dTLS." > > > > > > > > > > Seems that text P25 should go? > > > > > > > > P27: An ACP node supporting native IPsec MUST use IPsec security > > > > setup via IKEv2, tunnel mode, local and peer link-local IPv6 > > > > addresses used for encapsulation. It MUST support ESP... (parameters). > > > > > > > > clarified to: > > > > > > > > P27: An ACP node that is supporting native IPsec MUST use IPsec > > > > security setup via IKEv2, tunnel mode, local and peer link-local > > > > IPv6 addresses used for encapsulation. It MUST then support ESP... > > (parameters). > > > > > > > > Also: > > > > > > > > ACP nodes supporting ACP via GRE/IPsec MUST support IPsec security > > setup.. > > > > > > > > clarified to: > > > > > > > > An ACP node that is supporting ACP via GRE/IPsec MUST then support > > > > IPsec security setup.. > > > > > > > [PT>] OK > > > > > > > Aka: P25 is correct, there is no single MTI. 6.7.3 defines the > > > > actual requirement for two different profiles: "baseline ACP node" > > > > and "constrainted ACP node". > > > > The two requirements in P27 are only conditional MUSTs defining the > > > > details of the IPsec profiles assuming a node does support IPsec or > > IPsec/GRE. > > > > > > > > Let me know if this is still unclear, and if so, how you would > > > > suggest to make it better readable. > > > [PT>] Someone else need to do it now I'm biased > > > > > > > > > > > > - "Use-ULA: For loopback interfaces of ACP nodes, we use Unique > > > > Local > > > > > > > > > > Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] > > > > > > > > > > with L=1]." > > > > > > > > > > This needs to be more crisp. ULA is defined in RFC 4193 but the > > > > > term ULA-Random is not. I think you mean that 3.2.2. of RFC 4193 > > > > > is the way addresses are formed, if so please say so. The best > > > > > practice RFC > > > > > 8064 recommends use of RFC 7217. I understand that privacy is not > > > > > a concern but does it hurt? Anyway please point at section 6.10 > > > > > and > > > > > 6.11.1.11 > > > > > > > > The term "ULA-Random" was used in the discussions on ANIMA mailing > > list re. > > > > ULA, so admittedly i didn't check that the term as it stands is > > > > actually not defined/used in rfc4193 - but its just meant to imply > > > > ULA with L=1, nothing more. I've removed the use of ULA-Random from > > > > the text and just refer now to 4193 with L=1 (also pointing to 3.1. of > > rfc4193 defining L). > > > > > > > [PT>] cool; > > > > > > > I have also added a note that the hash uses our own ACP definition > > > > instead of > > > > rfc4193 3.2.2. > > > > > > > > Paragraph is now: > > > > > > > > Use-ULA: For loopback interfaces of ACP nodes, we use Unique > > > > Local Addresses (ULA), as defined in with > > > > L=1 (as defined in section 3.1 of ). Note > > > > that the random hash for ACP loopback addresses uses the definition > > > > in and not the one of > > > target="RFC4193"/> section 3.2.2. > > > > > > > > 8064/7217 are irrelevant here if i understand it correctly because > > > > we define the addressing scheme for anything following the ULA > > > > prefix ourselves for ACP addresses. Let me know if i do misunderstad > > > > what you where trying to suggest re. 8064/7217. > > > [PT>] > > > [PT>] I guess I missed that you defined the IID. > > > > > > > > > > > > - " > > > > > RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations > > > > > with > > > > multicast support". Implementations should support also other modes. > > > > > > > > > > Note: Root indicates mode in DIO flow" > > > > > > > > > > Why "should" ? there is no much point supporting the other modes > > > > > is > > > > there? Section 6.11.1.13 says that SRH is not used so this is > > > > inconsistent. You only need MOP 2 or 3, 3 is you do multicast which > > > > at the moment does not appear to be the case. SO I would MUST a MOP > > > > of 2 and MAY a MOP of 3 which is a superset of MOP 2, and that's it (see > > 6.3.1 of RFC 6550). > > > > > > > > Probably a transcription error on my side when i took your RPL > > > > summary and wrote it down. Fixed according to above. > > > > > > > [PT>] cool > > > > > > > > > > > > - "The lack of a RPI (the header defined by [RFC6553]), means that > > the > > > > > data-plane will have no rank value that can be used to detect loops. > > > > > As a result, traffic may loop until the TTL of the packet reaches > > > > > zero. " > > > > > > > > > > Since we have reliable links and no stretch (section 6.11.1.7), > > > > > loops should be exceedingly rare. It could be recommended to send > > > > > the DIOs > > > > > 2-3 times to inform children when losing the last parent. Note > > > > > that the technique in section "8.2.2.6. Detaching" of RFC 6550 > > > > > should be favored over that in section "8.2.2.5. Poisoning" > > > > > because it allows local connectivity. Also, It should be said that > > > > > a node should select more than one parent, at least 3 if possible, > > > > > and send DAOs to all of then in parallel. This provides multi > > > > > > > > Not sure why your paragraph ends apruptly, buts its also in the > > > > archive, so its not a mistake on my email end. Hopefully nothing > > significant missing. > > > [PT>] > > > [PT>] Dunno what happened. Selecting multiple parents enables NECM > > back. Could be useful. > > > > > > > > > > > I have replaced the suggestive text that followed your above quoted > > > > text in the draft: > > > > > > > > There are a variety of heuristics that can be used to signal from the > > > > data-plane to the RPL control plane that a new route is needed. > > > > > > > > With a hopefuly correct transcription of your suggestion: > > > > > > > > > > > > Since links in the ACP are assumed to be mostly reliable (or have link > > > > layer protection against loss) and because there is no stretch > > > > according to , loops should be > > > > exceedingly rare though. > > > > > > > > There are a variety of mechanisms possible in RPL to further > > > > avoid temporary loops: DIOs SHOULD be sent 2...3 times to inform > > children > > > > when losing the last parent. The technique in > > > > section 8.2.2.6. (Detaching) SHOULD be favored over that in section > > 8.2.2.5. > > > > (Poisoning) because it allows local connectivity. Also, nodes SHOULD > > select > > > > more than one parent, at least 3 if possible, and send DAOs to all > > > > of then in parallel. > > > > > > > [PT>] Yes, I'm good with all this. > > > > > > > > - "ACP nodes MUST perform standard IPv6 operations across ACP > > > > virtual > > > > > interfaces including SLAAC (Stateless Address Auto-Configuration - > > > > > RFC4862])" > > > > > > > > > > They may actually prefer Optimistic DAD RFC 4429 since address > > > > > duplication > > > > is highly improbable as long as you . > > > > > > > > > > > Added: > > > > > > > > "Optimistic Duplicate Address Detection (DAD)" according to > > > > is RECOMMENDED because the likelyhood > > for > > > > duplicates between ACP nodes is highly improbable as long as > > > > the address can be formed from a globally unique local > > > > assigned identifier > > > > (e.g.: EUI-48/EUI-64, see below). > > > > > > > [PT>] > > > [PT>] I'm unsure what your recommendation for the interface ID is thus the > > discussion on RFC 7217. > > > > > > Note: I have only one slight comment left below: > > > > > > > > > > > Minor comments > > > > > > > > > > ------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - About "[RFC7575] defines the fundamental ... " > > > > > > > > > > for readability, it may be nicer to indicate the title of an RFC > > > > > when it is referenced first; e.g. the text above would become > > > > > > > > > > " Autonomic Networking: Definitions and Design Goals" [RFC7575] > > > > > defines > > > > the fundamental ... > > > > > > > > Ok, i am punting this one for now to RFC editor after playing around > > > > a bit with the XML options - and not being satisfied... and having > > > > references for 50 RFCs in the doc: > > > > > > > > [RFC Editor: Question: Is it possible to change the first > > > > occurrances of [RFCxxxx] references to "" [RFCxxxx] ? > > > > the XML2RFC format does not seem to offer such a format, but i did > > > > not want to duplicate 50 first references to be duplicate - one > > > > reference for title mentioning and one for RFC number.] > > > > > > > > If RFC editor comes back and can't do this easier than i can in XML, > > > > i'll try to go through the chores when doc is in RFC editor queue. > > > > > > > > > - about "or network plane (there is no well-established name for > > this)" > > > > > > > > > > The term network plane is not used again in the document. This > > > > > text may go > > > > away. > > > > > > > > Done. > > > > > > > > > You may consider using "security and transport substrate" instead, > > > > > since it is > > > > used elsewhere in the document. > > > > > > > > "autonomic communications fabric" = ACP including ACP GRASP (ACP > > > > GRASP provides discovery etc..). "security and transport substrate" > > > > == the parts of ACP used by "ACP GRASP" (aka: The secure IPv6 forwarding > > of ACP). > > > > > > > > Subtle difference. > > > > > > > > > Also, please be consistent on whether you use hyphen or not and > > > > > use that globally, e.g. for the above, and pane like in "forwarding plane" > > > > > or "out of band network "; > > > > > > > > Fixed up "out of band" (no hyphens) and "in-band" (with hyphen). > > > > Not sure why but this is what MS word spelling checker suggested to > > > > me. RFC editor will override if these are not the best choices. > > > > > > > > > > > > > > > > > - "data-plen" > > > > > Typo? > > > > > > > > Done > > > > > > > > > > > > > - "OAM applications ("Operations Administration and > > Management)" > > > > > > > > > > Consider using "Operations Administration and Management (OAM) > > > > applications " instead; same goes for SDN, ASA, VRF, etc... > > > > > > > > Ok. Tried to fix up all the instances i could find. > > > > > > > > > - " MIC: "Manufacturer Installed Certificate". Another word not > > used > > > > in this document to describe an IDevID." > > > > > > > > > > MIC is not used in the document, maybe inform of this equivalence > > > > > in the > > > > IDevID definition instead; same goes for SUDI. Note that UDI is use > > > > just once and may not need an entry here. > > > > > > > > The definitions of those non-necessary terms are there to help > > > > others who like me start out not being security experts and are > > > > confused about those equivalent or related terms. > > > > > > > > I specifically didn't want to include discussions about these terms > > > > in the definitions that are relevant (eg: IDevID) so as not to clobber up that > > text. > > > > Instead, readers would just look up those redundant terms when they > > > > are like me initially confused about them. > > > > > > > > > - "RPL: \"IPv6 Routing Protocol for Low-Power and Lossy > > > > Networks\". The routing protocol used in the ACP." > > > > > > > > > > Maybe point on [RFC6550]? > > > > > > > > Done > > > > > > > > > - "Connecting over non-ACP Layer-3 clouds initially requires a tunnel > > > > between ACP nodes." > > > > > > > > > > I understands that it is one tunnel between each pair of adjacent > > > > > ACP nodes, correct? I read "a tunnel" as an end-to-end tunnel, > > > > > which sounds different > > > > > > > > Changed to: > > > > > > > > Connecting over non-ACP Layer-3 clouds requires explicit > > configuration. > > > > See . This may be automated in > > > > in the future through autodiscovery mechanisms across L3. > > > > > > > > > > > > > - "ACP relies on group security" > > > > > > > > > > Add "The" > > > > > > > > > > > > Done > > > > > > > > > - "An ACP node MUST have keying > > > > > material consisting of a certificate (LDevID), with which it can > > > > > cryptographically assert its membership in the ACP domain and trust > > > > > anchor(s) associated with that certificate with which it can verify > > > > > the membership of other nodes (see Section 6.1.2)." > > > > > > > > > > This is convoluted. Could you make it 2 sentences? > > > > > > > > Fixed to: > > > > > > > > The ACP relies on group security. An ACP domain is a group of > > > > nodes that trust each other to participate in ACP operations. To > > > > establish trust, each ACP member requires keying material: An ACP > > > > node MUST have a certificate > > > > (LDevID) and a trust anchor (TA) consisting of a certificate (chain) > > > > used to sign the LDevID of all domain members. The LDevID is used to > > > > cryptographically assert membership in the ACP domain, the TA to > > > > verify the membership of other nodes in the ACP domain (see > > > target="certcheck"/>). > > > > > > > > > - " Note: LDevID ("Local Device IDentification") is the term used to > > > > > indicate a certificate that was provisioned by the owner of a > > > > > node as opposed to IDevID ("Initial Device IDentifier") that may > > > > > has been loaded on the node during manufacturing time. Those > > > > > IDevID do not include owner and deployment specific information to > > > > > allows autonomic establishment of trust for the operations of an ACP > > domain (e.g.: > > > > > between two ACP nodes without relying on any third party)." > > > > > > > > > LDevID was already defined in the terminology. This text may move > > > > > there or > > > > go away. > > > > > > > > Gone. I added the note that LDevID can not be used directly for ACP > > > > to the terminology definition of IDevID. > > > > > > > > > - " This document uses the term ACP in many places where its > > > > reference > > > > > document use the word autonomic." > > > > > > > > > > Add [RFC7575] after "reference document" > > > > > > > > Done. > > > > > > > > > - " "routing-subdomain" is the autonomic subdomain that is used > > to > > > > > calculate the hash for the ULA prefix of the ACP address of the node." > > > > > > > > > > Do you mean ULA suffix? > > > > > > > > No, the Global ID. Fixed. > > > > > > > > Actually, i also sumbled across this: > > > > > > > > RFC4193 uses "Prefix" for the first 7 bits of a ULA address, but we > > > > have used use the term ULA prefix to refer to the first 48 bits of a > > > > ULA address, so i've clarified this more in the terminology. > > > > > > > > > - " o If the node certificates indicate a CDP (or OCSP) then the > > peer's > > > > > certificate must be valid according to those criteria. e.g.: OCSP > > > > > check across the ACP or not listed in the CRL retrieved from the CDP." > > > > > > > > > > Please define CDP and OSCP, and/or reference a RFC is possible. > > > > > > > > Done. Using RFC5280. Hope thats correct, otherwise IESG SEC review > > > > should help. > > > > > > > > > - "enrolment" > > > > > Typo > > > > > > > > Fixed. > > > > > > > > > - "This can > > > > > use a single GRASP M_FLOOD message as shown in above example." > > > > > Actually the example is now below. Please reference the figure. > > > > > > > > Done. Actually its still "above", or i am heavily confused. > > > > > > > > > > > > > > - "The protocol could for example could have been" > > > > > > > > > > Typo > > > > > > > > Fixed. > > > > > > > > > - "if the IPsec connecting" > > > > > > > > > > Typo? > > > > > > > > More like sentence structure was strange. > > > > > > > > Fixed to: > > > > > > > > "Even if the IPsec connection from Bob succeeded, Alice might > > > > prefer another secure protocol over IPsec" > > > > > > > > > - "ACP wide service discovery" > > > > > ACP-wide > > > > > > > > Fixed. > > > > > > > > > - "if the IPsec connecting In most other solution > > > > > designs such distributed discovery does not exist at all or was > > > > > added as an afterthought and relied upon inconsistently" > > > > > > > > > > Consider removing or rephrasing : ) > > > > > > > > Removed: > > > > > > > > Sentence wasn't that bad, but easier removed instead of trying to > > > > justify negative observations about reality without being called out > > > > to provide even more proof. > > > > > > > > > > > > > > - Maybe consider moving the discussion on multicast P29 -30 to > > annex? > > > > Why Multicast is not used is an interesting discussion but not > > > > critical for the protocol operation. > > > > > > > > Done. > > > > > > > > > - "it is not quite clear yet what exactly the implications are > > > > > to make GRASP flooding depend on RPL DODAG convergence and how > > > > > difficult it would be to let GRASP flooding access the DODAG > > > > > information" > > > > > > > > > > Let's chat then. There's work on reliable multicast for RPL using BIER. > > > > > > > > Yeah if i would just get around to that ;-) > > > > > > > > For now moved together into informative section together with te > > > > multicast discus. > > > > > > > > > - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is > > the > > > > > security and transport substrate for the GRASP instance run inside > > > > > the ACP ("ACP GRASP"). " > > > > > > > > > > "running" inside the ACP? Maybe rephrase more globally? > > > > > > > > > > > > > This instance of GRASP runs across the ACP secure channels.. > > > > > > > > > - "OAM protocols no not require IPv4: The ACP may carry OAM " > > > > > Typo no->do > > > > > > > > Fixed. > > > > > > > > > - "Consider a network that has multiple NOCs in different > > locations. > > > > > Only one NOC will become the DODAG root. Other NOCs will have to > > > > > send traffic through the DODAG (tree) rooted in the primary NOC." > > > > > > > > > A figure would help. I remember all the discussions we had about > > > > > setting the prf bits in remote NOCs > > > > > > > > Sorry. A bit low on cycles right now. Hopefully i'll get around to it later. > > > > Created a wish list entry in changelog. > > > > > > > > > - "RPPL." > > > > > Typo > > > > > > > > Fixed. > > > > > > > > > - "Administrative Preference ([RFC6552], 3.2.6 " > > > > > > > > > > The section is correct but that is RFC 6550. > > > > > > > > Done > > > > > > > > > > > > > > - "This is a standard issue > > > > > with tunneling, not specific to running the ACP across it." > > > > > Do you really mean Standard or would Classical work better? > > > > > > > > This is an issue of tunnels, not an issue of running the ACP across a tunnel. > > > [PT>] > > > [PT>] Sure but I was pointing at the word "standard", probably ill-chosen in > > a standard doc... > > > > > > > > > > > > - "Even though loopback interfaces where originally d" > > > > > Typo Where -> were > > > > > > > > Done. > > > > > > > > > - Section 3, 4, 9 and 10 may move to Annex (by moving the section > > after > > > > the tag) since they are not normative and do not > > > > contribute to the understanding of the protocol. This way there > > > > should not be a need to indicate normative in other sections. > > > > > > > > Sections 3, 4 and 9 are fairly short and the flow of the document > > > > depends on them being in their particular location. > > > > > > > > Section 10 could go into an appendix, but it makes not a lot of > > > > difference, but past experience has shown that Annex text is a lot > > > > less likely to be read given how the RFCs are structured. > > > > We had 10 in Annex and moved it up for exactly that reason. > > > > > > > > > - Well Noted that Section 14 Will be removed/. > > > > > > > > > Sorry for being interrupted here, > > > > > > > > > > > > Thanks you so much! > > > > > > > > > > [PT>] My pleasure, > > > > > > Take care; > > > > > > Pascal > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Tue Aug 7 16:45:54 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB6D130E87; Tue, 7 Aug 2018 16:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRaO8xqfYHg3; Tue, 7 Aug 2018 16:45:43 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B816F130EC6; Tue, 7 Aug 2018 16:45:42 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B991E58C4B6; Wed, 8 Aug 2018 01:45:37 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id A82C94E0C64; Wed, 8 Aug 2018 01:45:37 +0200 (CEST) Date: Wed, 8 Aug 2018 01:45:37 +0200 From: Toerless Eckert To: Alissa Cooper Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20180807234537.vh7kf27daw64efgy@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 23:45:46 -0000 Thanks, Alissa Changes for your review have been committed together with changes for Elwin's review. into just posted -17 rev of the doc. rfcdiff here: http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-17.txt I hope this resolve all the issues you raised, give or take the postponed formatting asks i wanted to push off to RFC editor as they are tooling related). point by point replies inline below. Cheers Toerless (btw: however often i do reread and fix the english text/grammar, i always get errors back in. Don't comment on the ones that got into the new -17, i will fix them in -18 for a first round on Eric and other reviews. Its primarily because i had to go back a few times for the DISCUSS text fixes before i was happy with the spec result, because the text across 4? sections had to be fixed related to each other and then i forgot a final text check of the new text *sigh*). On Wed, Aug 01, 2018 at 08:52:14AM -0700, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-16: 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-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 6.10.4: > > "The value of the Interface Identifier is left for future definitions." > > I don't understand how this is usable without some definition. I.e., if I > assign every interface ID in my ACP to be 0, it's not going to work. Could you > elaborate about what is expected in this field? Thanks. This sentence was an overlooked leftover from before i added the whole section 8.1 (ACP connect), which is where the setup in which these addresses are used is defined/standardized. I replaced the sentence in question with: | Address management of ACP connect subnets is done using traditional assignment methods and existing IPv6 protocols. See for details. 8.1.3. says normal IPv6 manual or preferrably SLAAC autoconfiguration of the interface identifiers, but really focusses on the RFCs to automatically learn prefixes through IPv6 RD, because that is the most important part of a LAN connecting to the ACP. Nothing new. Just a hopefully good profile of the most popular IPv6 autoconfig options. [ I'll respond to Brians proposal for specific stable addressin separate on the thread he opened.] Note that i did fixed up other text in conjunction with this discuss and the discussion below about the requirement to have or not to have the ACP address in the ACP domain certificate. These changes have the following result: The ABNC syntax for acp-address in the certificate allows a full ACP addres (32hex digits), no acp-address at all, or a placeholder address "0". The text changes make this work and explain it: - ACP nodes get a 32bit hex-digit - Non ACP-channel capable nodes, like NOC equipment gets an empty acp-address field. they use the manual ACP addresses, but given how those use traditional assignment methods, those are not managed by the registrar. Those nodes can still use their ACP certificate for any end-to-end authenticartion, just not to build ACP channels. - (future) ACP nodes that have some other method to assign their ACP address beside getting it through the certificate use "0". Thats the indication from the registrar that those nodes are permitted to build ACP secure channels, but did not get their address from the Registrar(s). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > FIXED: > General: > > Please address the Gen-ART reviewer's latest round of comments. See separate reply. ------------------ > FIXED: > There are a bunch of places in this document where it seems like there is a > tension between specifying a limited set of functionality here and being able > to support a wider variety of deployment scenarios. This is noted in Section 1 > but I think in general it would be clearer if uses of the term "future" > throughout the document could be more surgical as well as more specific about > whether they mean "people might deploy this differently in the future" or > "standards would need to be developed in the future." > I've made a few > suggestions about some of these turns of phrase below but would suggest someone > do a full edit pass with this in mind because there are a large number of > mentions of "future work." Of course there is always more work to do, but every > bit of "future work" need not be mentioned in this document, and in cases where > it is mentioned I think there should be a specific reason for doing so that > bears on people implementing this specification. I don't think this fits in the > DISCUSS criteria but for a document that intends to be published on the > standards track I would expect it to be crisper about the dividing line between > the normative behavior being specified here versus changes or extensions that > may or may not be made in the future. Let me answer in 5 points: 1. All relevant sections have "Normative" vs. "Informative" in their title. added "Informative" to sections where it was missing. Modified section 4: Requirements": Informative - ask from AD was not to have separate use-case/requirements document in charter round 1, so the use-case/requirements sections here are really only the input to the specification. The words in 4./Requirements are now _MUST_, _SHOULD_ to set them apart from rfc2119 and text explains it (i can change to any other preferrable syntactic differentiation). 2. Normative MUST/SHOULD are only in the normative sections. 3. Introduction also summarizes which sections are normative and which informative. I fixed up the text in the intro to be more complete wrt. to that. | The normative part of this document starts with | where the ACP is defined in detail. | defines normative how to support ACP | on L2 switches. explains normative how | non-ACP nodes and networks can be integrated. | The remaining sections are non-normative:... Also added sentence to introduction: | There are no dependencies against Appendix A to build a complete working and interoperable | ACP according to this document. 4. Eliminating gratuitous future - primarily from normative text. I have tried as good as possible to eliminate "futures" from the normative section (6...8,10). Here is a list of the changes except for the mayor ones you inquired about separately be low: 1) | See for discussions about how variations | of the ACP could be defined in the future (standard or proprietary) | to better meet different expectations from those on which the current design is based In informative section (applicability statement), forward pointer to A. I added "(standard or proprietary)" to be clearer. I insered this sentence because there where over the course of the WG work a lot of discussion about how to do things differently, the gist of it is in appendix A, so this is just a forward pointer. 4) | Connecting over non-ACP Layer-3 clouds requires explicit configuration. | See . | This may be automated in the future through auto discovery mechanisms across L3. Ok, this "future" is pretty gratuitous without explanation. Removed. 5) | Other uses are subject to future work, but it is recommended that | it is the default security check for any end-to-end connections | between ASA. It is equally useable by other functions such as | legacy OAM functions. Removed, refined first sentence of paragraph to hopefully be well inclusive of any such future work: | The ACP domain certificate SHOULD be used for any authentication | between nodes with ACP domain certificates (ACP nodes and NOC nodes) | where the required condition is ACP domain membership, such as ACP | node to NOC/OAM end-to-en security and ASA to ASA end-to-end security. 6) | extension = ; future definition. This is in the ABNF of the certificte extension specification, and that spec needs a hook to support for future definitions. 9) DELETED: | Future work optimizations could avoid this but it is unclear how | beneficial/feasible this is replaced with: | which has the following benefits: 10) DELETED: | If a node learns through a future autonomic method or through configuration that it is part of a zone replaced with: | If a node learns (see ) that it is part of a zone (auto-aggregation subsection is one of two new A. sections created in rely to this DISCUSS, see below). 11) DELETED: | (subject to future work) (in zone-id explanationt ext) no replacement (gratuitous). 12) DELETED: | Future work may define mechanisms for auto-coordination between ACP nodes and auto-allocation of Subnet-IDs between them no replacement (gratuitous). 14) IMPROVED: Future is used to explain the semantic of the "objective-value" in the SRV.est GRASP objective. I fixed up the text to be more precise: | Objective-value MUST be ignored if present. Backward compatible | extensions to MAY be indicated through | objective-value. Non compatible certificate | renewal options MUST use a different objective-name. 15) 6.11.1.1- moved notion about future improved RPL option (for multiple NOC) into appendix A 16) 6.12.2 - remove "future" from wording of performance through rewording (this is really just a matter of impleemntation choice, applicable to both first-generation or future geneation implementations, so no need to talk about futures. 17) 6.12.5 "future protocols". Just refined wording, but kept it unchanged. The reason to use the word "future" here was solely to emphasize on the independence of the described mechanisms, but not to suggest future work: | Any type of ACP secure channels to another ACP node can | be mapped to ACP virtual interfaces in different ways. | This is independent of the choosen secure channel protocol (IPsec, DTLS | or other future protocol): 18) 8.1.1 "ACP connect security: removed notion of future work, but instead gave an example that could be impleemtned without future (work outside the scope of this spec), and moved the suggestion that would require future standards work (using ACP spec extension) into A.10. 19) 7.2 - removed senetence with notion of future (MacSec) - gratuitous. 20) 8.1.2 - removed sentence with future. This was just describing interla implementation options, so that work wold be in scope of implementations of this spec, no need to call it futures. 21) 9.2.2 (informative section). Removed notion of future role based security. This is not one paragraph in A.10 22) Removed notion that we need a YANG data model (future work) for ACP/ANI Obvious enough so we will not forget even without this note. Overall: In the few places where i have kept "futures" in the normative text, i did try tou be explicit about "standard vs. non-standard" futures. In summary: there should now be close to minimal possible instances of "futures" in the normative text. I hope for this document this will suffice. 5. Futures discussion in section A: Note: Half of A. is futures, the other half is explanations. The futures where the part of the WG time we spent but concluded it was too much work to put into the current spec, but we hink it is crucial not to loose this work. (I have seen so many IETF standards RFC where this actual WG work context isn't kept but thrown out, and 10 years later the few people left with institutional memory have to re-explain the stuff, but why doc made decisions, and also what was seen as next steps). ------------------ >FIXED: > "Intent" is used both capitalized and in lower case throughout the document and > I'm unclear if this is meant to signify a distinction or not. Thanks. 3 occurances of intent -> Intent. ------------------ > POSTPONED/RFC-editor: > Section 2: > > Please remove the -->"..."() notation. Discussed in prior review, but the outcome ended up only in changelog. I've now inserted the following note on top of section 2 to avoid further comments on this: [RFC Editor: WG/IETF/IESG review of the terms below asked for references betwen these terms when they refer to each other. The only option in RFC/XML i found to point to a hanging text acronym definition that also displays the actual term is the format="title" version, which leads to references like '->"ACP domain certificate" ()'. I found no reasonable way to eliminate the trailing '()' generated by this type of cross references. Can you please take care of removing these artefacts during editing (after conversion to nroff ?). Also created ticket to ask for xml2rfc enhancement to avoid this in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. ------------------ > FIXED: > Please use the exact boilerplate from RFC 8174, not a variation. Thanks. i copied the text from what an earlier reviewer suggested. Must have come from RFC8196. Only RFC with that mistake (says google). > It seems like RFC citations should appear for IKEv2 and DTLS upon first use in > this section. Otherwise, it seems they are first cited at different future > points in the document (Section 6.3 and 6.7, respectively). Yepp. applicability section was added late, forgot to fixup first references. ------------------ > FIXED/NEW TEXT: > Section 3.3: > > "The ACP provides reachability that is independent of the Data-Plane > (except for the dependency discussed in Section 6.12.2 which can be > removed through future work)," > > Isn't this kind of a big exception, given that there is meant to be a secure > channel between pairs of nodes in the ACP and that developing future > encapsulations is non-trivial? It seems like phrasing this the other way around > (the ACP is dependent on the Data-Plane for but is otherwise independent > of it) would be more accurate. Nice! Thanks a lot to have me reconsider this text. This text is wrong because it is elevating limitations of the implementation of ACP that i helped build and am familiar with to limitation of the spec standard. So sometimes, knowing too much code doesn't help writing a spec *sigh*. Text changed to: | Depending on the implementation (see | for more details), the ACP provides reachability that can be | independent of the Data-Plane. This allows the control plane and management | plane to operate more robustly. "general_addressing" 6.12.2 (informative) text is fixed up to explain the candidate implementation issues better than in -16: | To avoid that Data-Plane configuration can imact the operations of the | IPv6 (link-local) interface/address used for ACP channels, appropriate | implementation considerations are required. If the IPv6 interface/link-local | address is shared with the Data-Plane it needs to be impossible to unconfigure/disable | it through configuration. Instead of sharing the IPv6 interface/link-local | address, a separate (virtual) interface with a separate IPv6 link-local | addresss could be used. For example, the ACP interface could be run over a separate | MAC addres of the underlying Ethernet type interface. For more details and options, | see . I added "A.10.2. Removing IPv6 data plane dependency" to further detail implementation options, and also one possible future that would require additional specification (different ethertype). The reason for regurgitating on this point i that its really the most difficult part of an implemenation if you want to be independent of the data plane. ------------------ > UNCHANGED/EXPLAINED: > Section 6: > > "Indestructible" seems like an overstatement. Maybe "resilient" would be more > accurate? As written, the ACP is meant to be resilient and indestructible. We use resilient to describe the ability to recover (from errors/attacks). This applies mostly to the network side (common property of most our routing stuff), but also with the Cert security system (revoking membership after nodes become compromisedetc.). We use indestructible to indicate the absence or reduction of an "attack surface". For example that ACP is defined to use clearly separated infra that would have only ReadOnly YANG models - no way to misconfigure. Or just ~3 UDP ports you could attack from the network (GRASP and IKEv2/IPsec). Aka: minimied atck surface from the network. Unattackable was a choice, but the biggest concern is friendly fire from erroneous peers, operators or SDN controllers without malicious intent. Therefore we concluded on indestructible. ------------------ > FIXED: > Section 6.1.1: > s/Such methods are subject to future work though./No such methods have been > defined at the time of publication of this document./ I fixed this text also in response to a discus from you below to make it clear when the acp-address is optional (for peers, not for ourselves). | Nodes complying with this specification MUST receive their ACP address | through the domain certificate, so their own ACP domain certificate MUST | contain the "acp-address" field. Nodes complying with this specification | MUST also be able to authentice nodes as ACP peers that have determined | their ACP address differently and whose ACP domain certificate may therefore | NOT have the "acp-address" field. See for further discussions. ------------------ > s/to build ACP channel/to build ACP channels/ ACK ------------------ > s/that intends to be equally unique/that it intends to be equally unique/ ACK ------------------ >FIX/CHANGED TEXT: > ""rsub" is optional; its syntax is defined in this document, > but its semantics are for further study. Understanding the benefits > of using rsub may depend on the results of future work on enhancing > routing for the ACP." > > What is the point of defining this now when it is unclear if or how it will be > used? There are already means for nodes to do error handling, so it seems like > defining a new field in the future if/when it is needed would work fine and be > cleaner. Appendix A.7 seems to assume some semantics for this field, which > makes the way it is specified here even more confusing IMO. Yes, that text was unnecessarily alluding to unresolved future issues when there is no need to do so because there are perfectly good use-case reasons to have rsub now and how to benefit from them now - without extensions. Texts fixed to: | "routing-subdomain" is the autonomic subdomain composed of "rsub" | and "acp-domain-name". "rsub" is optional. When not present, | "routing-subdomain" is the same as "acp-domain-name". "routing-subdomain" | determines the /48 ULA prefix for ACP addresses. "rsub" therefore allows | to use multiple /48 ULA prefixes in an ACP domain. | See for example use-cases. And that A.7 example is improved to: | The rsub element in the domain information field permits the use of addresses | from different ULA prefixes. One use case is to create multiple physical | networks that initially may be separated with one ACP domain but different | routing subdomains, so that all nodes can mutual trust their ACP domain | certificates (not depending on rsub) and so that they could connect later | together into a contiguous ACP networks.One instance of such a use case is an ACP for regions interconnected | via a non-ACP enabled core, for example due to the absence of product | support for ACP on the core nodes. ACP connect configurations as defined | in this document can be used to extend and interconnect those ACP islands | to the NOC and merge them into a single ACP when later that product | support gap is closed. Auto-aggregation is now only discussed in new section A.10.8.2 ------------------ > FIXED/CHANGED-TEXT: > "In this specification, the "acp-address" field is REQUIRED, but > future variations (see Appendix A.8) may use local information to > derive the ACP address. In this case, "acp-address" could be empty. > Such a variation would be indicated by an appropriate "extension". > If "acp-address" is empty, and "rsub" is empty too, the "local-part" > will have the format "rfcSELF + + extension(s)". The two plus > characters are necessary so the node can unambiguously parse that > both "acp-address" and "rsub" are empty." > > This seems contradictory. Either "acp-address" is REQUIRED in which case there > are no exceptions, or it's not; if it's not, then the expected syntax for cases > when it's not present should be specified. Thanks. Took me a while to understand i was talking about semantics and you about syntax. Fixed text accordingly. NOdes in this spec MUST have acp-address in their own cert, but must also recognize peer certs as valid without acp-address in the peers cert: | Nodes complying with this specification MUST be able to receive | their ACP address through the domain certificate, in which case | their own ACP domain certificate MUST contain the "acp-address" field. | Nodes complying with this specification MUST also be able to authenticate | nodes as ACP peers that have determined their ACP address differently | and whose ACP domain certificate MAY NOT have the "acp-address" field. | See for further discussions. ------------------ > Section 6.1.2: > > s/If the node certificates indicates/If the node certificate indicates/ ACK ------------------ > FIXED/ADDED TEXT: > Section 6.3: > > It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. Yes. The reason is that for once IPsec/IKE is important and proven and intended to be the primary protocol, and for non-security folks the naming might be somewhat confusing (IKE vs IPsec), and the whole options with without GRE and IKE able to autoselect this etc. Hence the explanations. But i added a boring sence about DTLS for equal treatment: "DTLS" indicates datagram Transport Layer Security version 1.2. There is no default UDP port, it must always be locally assigned by the node. See . Note that there is already "6.7.2. ACP via DTLS". ------------------ > FIXED: > Section 6.4: > > This is a good example of a section where the blurring between the specified > behavior and expectations for the future is unhelpful IMO. Why specify the > current default and then spend a lot of words (including Appendix A.7) talking > about how it will be different in the future? I have moved all the 6.4 Intent stufff into new section A.8 and also moved the Intent stuff in A.7 into A.8 to clean up. We did spend a lot of time in the WG to discuss the Intent issues, and i think that the little whats now left in A.8 is relevant documentation for possible future work that would otherwise get easily lost, so do not want to delete it completely. ------------------ > Section 6.10.3.1: > > s/We do not think this is required at this point/This is not currently required/ ACK ------------------ > Section 6.12.2: > > s/may specify additional layer 2 or layer encapsulations/may specify additional > layer 2 or layer 3 encapsulations/ (I think?) ACK ------------------ > Section 8.2.1: > > This seems extraneous: "Future work could transform this into a YANG > ([RFC7950]) data > model." ACK. ------------------ > Appendix A.8: > > "Secure channels may > even be replaced by simple neighbor authentication to create > simplified ACP variations for environments where no real security is > required but just protection against non-malicious misconfiguration." > > I think experience has shown that even environments where it is assumed that > security is not required prove to need it. I would suggest removing this text > or changing this implication. Yes, and again this was badly written text, the future option in mind wasn't meant to be insecure anyhow *sigh*: Sentence left for that suggestion is: | ACP hop-by-hop network layer secure channels could also be replaced | by end-to-end security plus other means for infrastructure protection. Note again, that we have been trying to make sure that all the text in this section A is not unsolicited but really the result of repeated questions/ requests in the WG to do things like this (or explains reasons for decisions in ACP). That one sentence for example goes back to the fact that the hop-by-hop encryption has been the biggest challenge to product adoption of ACP. ------------------ Impressed that you got all the way down to A.8. Thanks a lot! From nobody Tue Aug 7 17:03:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8845130F6D; Tue, 7 Aug 2018 17:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEKHoo4F69Lu; Tue, 7 Aug 2018 17:03:21 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66831131131; Tue, 7 Aug 2018 17:02:57 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 41D4658C4B6; Wed, 8 Aug 2018 02:02:52 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id B4C714E0C64; Wed, 8 Aug 2018 02:02:52 +0200 (CEST) Date: Wed, 8 Aug 2018 02:02:52 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Alissa Cooper , The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180808000252.h2pl22xecdrfhisz@faui48e.informatik.uni-erlangen.de> References: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 00:03:26 -0000 Brian: As explained in reply to Alissa, this was leftover text, so i could simply remove it, except that i figured that it was wrong to allow these addresses into the Certs, which lead to the mayor fixes for Alissas discuss. The ACP connect LANs are just normal IPv6 subnets, managed via existing manual methods, SLAAC etc. This is written already for several revisions of the doc now into 8.1 and specifically 8.1.3. I did not fancy to bother about recommending any specific SLAAC enhancements in that section, because i wanted to concentrate on the important methods only, and thats primarily the route autoconfiguration (RFC4191) because those NOC nodes will be multi-homed, one interface on ACP connect subnet, one on Data-Plane, and then you want to make sure they correctly route the ACP destinations across the ACP interface only. I looked through RFC8064 and didn't find it particularily beneficial for the use-case. It seems to be very much focussed on user-devices with a browser connected to the Internet and the resulting security and privacy issues. Not really relevant IMHO for Network Management servers in a NOC that likely announce their addresses via GRASP into the ACP anyhow, so those addresses do not need to be stable, and they certainly can't be private/hidden, and i wouldn't see how any of the rfc8064/rfc7217 considerations would increase security for these servers. Besides, the rfc7217 algorithm recommended by rfc8064 is IMHO not very good to achieve stable addresses. A common issue i have with those servers is that ethernet HW fails, and then you have to reconnect your subnet to another physcial port (often servers have more than enough spare ports) and i bet that the Net_Iface parameter will cause the stable address to change. This whole disussion was important though, because it had me finally realize that i can not put normally managed addresses, even if they claim to be stable into certificates, because they never are stable, and a registrar can't determine them upfront when you want to leverage existing IPv6 protocols to manage them. Cheers Toerless On Thu, Aug 02, 2018 at 08:44:53AM +1200, Brian E Carpenter wrote: > On 02/08/2018 03:52, Alissa Cooper wrote: > .... > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Section 6.10.4: > > > > "The value of the Interface Identifier is left for future definitions." > > > > I don't understand how this is usable without some definition. I.e., if I > > assign every interface ID in my ACP to be 0, it's not going to work. Could you > > elaborate about what is expected in this field? > > > > Why not: > > The value of the Interface Identifier SHOULD follow [RFC8064]. > > That would work fine and is a SHOULD to allow for alternatives > if there's a good reason. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Aug 7 17:13:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8BD130EEC; Tue, 7 Aug 2018 17:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9VCxo4FCK4q; Tue, 7 Aug 2018 17:12:55 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E27128CB7; Tue, 7 Aug 2018 17:12:55 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 021E958C4B6; Wed, 8 Aug 2018 02:12:51 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id E89E74E0C64; Wed, 8 Aug 2018 02:12:50 +0200 (CEST) Date: Wed, 8 Aug 2018 02:12:50 +0200 From: Toerless Eckert To: Michael Richardson Cc: Brian E Carpenter , Alissa Cooper , The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180808001250.5dkfc3di3mvu2uhn@faui48e.informatik.uni-erlangen.de> References: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> <14725.1533165162@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14725.1533165162@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 00:13:00 -0000 On Wed, Aug 01, 2018 at 07:12:42PM -0400, Michael Richardson wrote: > The ACP addresses (including interface identifiers) are assigned by the ANI > Registrar, and are embedded in certificates issued by the Registrar. > Schemes 6.10.2 and 6.10.3 support this mechanism. Right. > Section 6.10.4 is about very much MANUAL allocation, which is basically > a non-zero-touch backdoor which nobody is supposed to use, unless they aren't > doing ANI stuff. "Nobody..." ;-) The ACP connect construct is short term the ACP version of the 20 IPv6 transition mechanisms, so given how we only need one scheme, and not 20, that's pretty good. Aka: not being able to put IPsec secure channel code into existing NMS servers. Long term this ACP-connect also makes sense when my nodes start to become virtualized, and the links between nodes are linux bridges or Veth configured by an orchestrator. Quie arguable if you want/need/benefit of running IPsec over those virtual links. This is discussed in 8.1.2. > Really, it's about the Registrar doing it's work (section 6.10.7), and the > only reason to have any statements about addressing schemes is so that we can > paint off some areas for manual allocation. (I didn't want any of these schemes here, > I don't think it helps, but maybe it causes no harm). Yes, long discussion with JoelH about this as well towards -16. I definitely wanted to carve out the manual space explicitly so that any better implementation can prohibit explicit configuration of the anon-manual prefixes, so routing for them can not be messed up through manual config or SDN controller. And i didn't want to leave the ACP connect addressing to random chance if as explained above we may have also strategic uses for it, and even short-term its nice for operators to have recommendations for an address plan to use. > The explanation in 6.10.7.2 further allows for multiple Registrars to operate > without coordinating via a centralized database (or blockchain). Yepp. Just need to add "without centralized ACP addressing coordination". Still need coordination for security via CAs (Ekr's comment). > So, by all means, suggest an RFC8064 IID in the UI when configuring a manual > address, but if the admin is even close to that part of the configuration, > then they probably meant to do something very specific. See reply to Brian. Cheers Toerless > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Aug 7 18:10:17 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB892127332 for ; Tue, 7 Aug 2018 18:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRhC-fAjrlXT for ; Tue, 7 Aug 2018 18:10:14 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 6A1FB126DBF for ; Tue, 7 Aug 2018 18:10:14 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id e13-v6so265400pff.7 for ; Tue, 07 Aug 2018 18:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4proCmmgZMRC8i0DJOq4cjkRx0PJ46r3Ft1VLTgZdG0=; b=fA8kZNMZCUwG2+2+cGXVMF6y2Gfb2/6vQTQgG/hXi57eyiypRzmOjLSDGIj6lPyQSF S4vns5QN6af4/O1kkvY+kWfUwxCw4Z45QGZt83Cfy7DAiEOv1RE2gp+6/CnJQs7HvaQa qc3p05LOD/XOnjLXwSI/1c0Jt6ONruGfxagB1H5Kzlyj8Pf0Og1ZHCbKgfM4K17InvKN 4su185KE6wxSluU71tZGCJu7SHXmqNjfRhCaQiMT3J7Hieh7Q2cPHvZBfdwqr0gczdYo IaluyIy36vcBFMliGVPEsnFm9FUzFKTz1Vl+RQ9s+JbB85JEDSoItJqFdURr+w7GvCMY Ms/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4proCmmgZMRC8i0DJOq4cjkRx0PJ46r3Ft1VLTgZdG0=; b=F75Ac8AMG99u+dkp7bMm/z3HbaATW4ju4XL957Z1WQe8MJxNw5m6WWlxrnnLn/6eYF RKAhStxvgzyTqz+Ek047l/HPOJZbPqoBTnPn5jRIaGKpatSDM5HlcaNMyKk0el55vpnb os/yMVgVkFOW5mnaZt2Iiq0PqehcwvcRA1ZmAuvnScBmDAUXwzK7U1yDlaIAowGlJ7ZX krUrDJhMdpEZJo+me2zP41M0embZSIDVer2FDf0+F+AM6qEVEe3rsfpRyT4icibTGHbY BkUcRZCDKmexbqiUIE1NU8GVq6FPk+gQE3BzQ+4WtlRmhjtKm6qiJiA+xY1xikpHtKDU US1g== X-Gm-Message-State: AOUpUlFU4eSJMOHG6Acj8VpfTUHMyq7KT0bLR4Kv15AOndizDJsLJ9ey y0E7pJHGEuLVAXVOFbpNpo6lA28W X-Google-Smtp-Source: AA+uWPyetlTL6R8aNoUMvPnEirjhQadwseTU7zLkjMspk5USnnRpfAPtXWRDTC+t6z+rEgM0OvtpKg== X-Received: by 2002:a62:b20c:: with SMTP id x12-v6mr674203pfe.64.1533690613517; Tue, 07 Aug 2018 18:10:13 -0700 (PDT) Received: from [130.216.38.29] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.29]) by smtp.gmail.com with ESMTPSA id p26-v6sm4225054pfi.183.2018.08.07.18.10.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 18:10:12 -0700 (PDT) To: anima@ietf.org References: <153368376189.2278.4443603469664734659@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Wed, 8 Aug 2018 13:10:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153368376189.2278.4443603469664734659@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-17.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 01:10:17 -0000 I've reviewed all the changes in this version and I am happy with them all. Regards Brian On 08/08/2018 11:16, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > > Title : An Autonomic Control Plane (ACP) > Authors : Toerless Eckert > Michael H. Behringer > Steinthor Bjarnason > Filename : draft-ietf-anima-autonomic-control-plane-17.txt > Pages : 138 > Date : 2018-08-07 > > Abstract: > Autonomic functions need a control plane to communicate, which > depends on some addressing and routing. This Autonomic Management > and Control Plane should ideally be self-managing, and as independent > as possible of configuration. This document defines such a plane and > calls it the "Autonomic Control Plane", with the primary use as a > control plane for autonomic functions. It also serves as a "virtual > out-of-band channel" for Operations Administration and Management > (OAM) communications over a network that is secure and reliable even > when the network is not configured, or misconfigured. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-17 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-17 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Tue Aug 7 18:20:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4254128CF2; Tue, 7 Aug 2018 18:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ8JZyInP7CI; Tue, 7 Aug 2018 18:20:47 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 AB4D21274D0; Tue, 7 Aug 2018 18:20:47 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id n7-v6so268513pgq.4; Tue, 07 Aug 2018 18:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ezyXCIuI2jyjxt2SZQxLa6hjV6BWvxygmYuQmidihU8=; b=irI+RYpzXsjSVl+9Ihseco+TLOQZioc52g7j6A0jHa0bMPoC8JOPsVeuYhS0RGulGj vcwZ4LFvlppWel7sDfjt65Tja/C5DJD+jnKoOIPYW/uJ1fvxv44An7FqJO6anuOP6hc6 K9BFQubtLeWkznxXL+hnU0G/ejXCLQlcHKTUHiq87w+sVTMSFNqerg9YA9Afl+oyOmhL zU1cWAJt24vXC+/OIowy6yll3IheDm31oiui/FwWlyIM0yaJiHvzZwKaIlekS/mtSNKt gia1gHVcRrmbjqZp19bKLXWg5tqkFqjpg5HEzst8pUIwy2L0BmspDyL79DvxIyXW5TSd xwtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ezyXCIuI2jyjxt2SZQxLa6hjV6BWvxygmYuQmidihU8=; b=Y4SRinpl3OcQIXFltvpfESRCnq/cHM3R0mttubmIuVeC4f83iV7yV64fPacxQlNM0v TNtHdztQQjpVt41XEPYv+QaXcnyNPwr1EhmuasyXX/xMbXyNhHJw9GCsYJ5Fv3apU/tG tLQ20bFuWZZX4sbNbFvqOZQMxWwidGyS8sQPv+cb/W0xP+YYO8V6hzZtgB8pxFcLlYXl 8Gv1RJFcuYOwG7ZIr3dqyhU3UJNUsfaRb9FNUfjxuxasHAS6hdlPi+8e2i6idUV6Ks3y 3ZHdFj0Da69bHHb1gaPc6hQAzMF6PwuhHCipITqq2OQYB+9dPXeaRnkDgKf+h/ln/cyD yc+g== X-Gm-Message-State: AOUpUlFDSsA8PiTZBNxLgEUGYR3dPRFv5XGA4EcWBzy/fzVQ9bmTru8L lDUpcGsoCp5bi61Ahp7b5/c= X-Google-Smtp-Source: AA+uWPzAWnJ12TnH7J+Sy12Zb4uF/FJ/IV3J1MJ0zolnRO6pHXWZRgRZMfC9RdKzSGkRM1B+d8mvhg== X-Received: by 2002:a63:24c:: with SMTP id 73-v6mr587386pgc.252.1533691247128; Tue, 07 Aug 2018 18:20:47 -0700 (PDT) Received: from [130.216.38.29] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.29]) by smtp.gmail.com with ESMTPSA id i20-v6sm4223180pfj.82.2018.08.07.18.20.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 18:20:46 -0700 (PDT) To: Toerless Eckert Cc: Alissa Cooper , The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com References: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> <0e5ddfe7-1270-209f-e3c1-5ccd8b5f0e1d@gmail.com> <20180808000252.h2pl22xecdrfhisz@faui48e.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Wed, 8 Aug 2018 13:20:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180808000252.h2pl22xecdrfhisz@faui48e.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 01:20:50 -0000 On 08/08/2018 12:02, Toerless Eckert wrote: > Brian: > > As explained in reply to Alissa, this was leftover text, so > i could simply remove it, except that i figured that it was wrong > to allow these addresses into the Certs, which lead to the mayor fixes > for Alissas discuss. > > The ACP connect LANs are just normal IPv6 subnets, managed via > existing manual methods, SLAAC etc. This is written already for > several revisions of the doc now into 8.1 and specifically 8.1.3. > > I did not fancy to bother about recommending any specific SLAAC > enhancements in that section, because i wanted to concentrate > on the important methods only, and thats primarily the route > autoconfiguration (RFC4191) because those NOC nodes will be multi-homed, > one interface on ACP connect subnet, one on Data-Plane, and then > you want to make sure they correctly route the ACP destinations > across the ACP interface only. > > I looked through RFC8064 and didn't find it particularily beneficial > for the use-case. It seems to be very much focussed on user-devices > with a browser connected to the Internet and the resulting security > and privacy issues. Not really relevant IMHO for Network Management > servers in a NOC that likely announce their addresses via GRASP > into the ACP anyhow, so those addresses do not need to be stable, > and they certainly can't be private/hidden, and i wouldn't see > how any of the rfc8064/rfc7217 considerations would increase security > for these servers. True. My thinking was more that since the current general-purpose recommendation is RFC8064, ACP implementers don't need to do anything different (e.g. continue using old-fashioned Modified EUI-64). But saying nothing is fine. > > Besides, the rfc7217 algorithm recommended by rfc8064 is IMHO > not very good to achieve stable addresses. A common issue > i have with those servers is that ethernet HW fails, and then > you have to reconnect your subnet to another physcial port > (often servers have more than enough spare ports) and i bet that > the Net_Iface parameter will cause the stable address to change. Yes, that has been noticed. But requiring a node to re-identify itself after a MAC address change seems like a good thing anyway. Brian > > This whole disussion was important though, because it had me finally > realize that i can not put normally managed addresses, even if > they claim to be stable into certificates, because they never > are stable, and a registrar can't determine them upfront > when you want to leverage existing IPv6 protocols to manage > them. > > Cheers > Toerless > > On Thu, Aug 02, 2018 at 08:44:53AM +1200, Brian E Carpenter wrote: >> On 02/08/2018 03:52, Alissa Cooper wrote: >> .... >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Section 6.10.4: >>> >>> "The value of the Interface Identifier is left for future definitions." >>> >>> I don't understand how this is usable without some definition. I.e., if I >>> assign every interface ID in my ACP to be 0, it's not going to work. Could you >>> elaborate about what is expected in this field? >>> >> >> Why not: >> >> The value of the Interface Identifier SHOULD follow [RFC8064]. >> >> That would work fine and is a SHOULD to allow for alternatives >> if there's a good reason. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Aug 7 19:32:05 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1959012426A; Tue, 7 Aug 2018 19:32:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <153369552408.2490.3814892405497577903@ietfa.amsl.com> Date: Tue, 07 Aug 2018 19:32:04 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-18.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 02:32:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-18.txt Pages : 138 Date : 2018-08-07 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 7 19:34:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CD4127332; Tue, 7 Aug 2018 19:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 qADm_Ry58a8y; Tue, 7 Aug 2018 19:33:54 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9811C12426A; Tue, 7 Aug 2018 19:33:53 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9A30F58C4B6; Wed, 8 Aug 2018 04:33:48 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 86DA94402CB; Wed, 8 Aug 2018 04:33:48 +0200 (CEST) Date: Wed, 8 Aug 2018 04:33:48 +0200 From: Toerless Eckert To: Alissa Cooper Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20180808023348.7j4k32dlt4cmzmna@faui48f.informatik.uni-erlangen.de> References: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> <20180807234537.vh7kf27daw64efgy@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180807234537.vh7kf27daw64efgy@faui48e.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 02:33:58 -0000 Sorry, too many typos in -17 to wait for next mayor fix version. had to rev to -18 *sigh* Thanks, Alissa Changes for your review have been committed together with changes for Elwin's review. into just posted -18 rev of the doc. rfcdiff here: http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-18.txt I hope this resolve all the issues you raised, give or take the postponed formatting asks i wanted to push off to RFC editor as they are tooling related). point by point replies inline below. Cheers Toerless On Wed, Aug 01, 2018 at 08:52:14AM -0700, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-16: 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-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 6.10.4: > > "The value of the Interface Identifier is left for future definitions." > > I don't understand how this is usable without some definition. I.e., if I > assign every interface ID in my ACP to be 0, it's not going to work. Could you > elaborate about what is expected in this field? Thanks. This sentence was an overlooked leftover from before i added the whole section 8.1 (ACP connect), which is where the setup in which these addresses are used is defined/standardized. I replaced the sentence in question with: | Address management of ACP connect subnets is done using traditional assignment methods and existing IPv6 protocols. See for details. 8.1.3. says normal IPv6 manual or preferrably SLAAC autoconfiguration of the interface identifiers, but really focusses on the RFCs to automatically learn prefixes through IPv6 RD, because that is the most important part of a LAN connecting to the ACP. Nothing new. Just a hopefully good profile of the most popular IPv6 autoconfig options. [ I'll respond to Brians proposal for specific stable addressin separate on the thread he opened.] Note that i did fixed up other text in conjunction with this discuss and the discussion below about the requirement to have or not to have the ACP address in the ACP domain certificate. These changes have the following result: The ABNC syntax for acp-address in the certificate allows a full ACP addres (32hex digits), no acp-address at all, or a placeholder address "0". The text changes make this work and explain it: - ACP nodes get a 32bit hex-digit - Non ACP-channel capable nodes, like NOC equipment gets an empty acp-address field. they use the manual ACP addresses, but given how those use traditional assignment methods, those are not managed by the registrar. Those nodes can still use their ACP certificate for any end-to-end authenticartion, just not to build ACP channels. - (future) ACP nodes that have some other method to assign their ACP address beside getting it through the certificate use "0". Thats the indication from the registrar that those nodes are permitted to build ACP secure channels, but did not get their address from the Registrar(s). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > FIXED: > General: > > Please address the Gen-ART reviewer's latest round of comments. See separate reply. ------------------ > FIXED: > There are a bunch of places in this document where it seems like there is a > tension between specifying a limited set of functionality here and being able > to support a wider variety of deployment scenarios. This is noted in Section 1 > but I think in general it would be clearer if uses of the term "future" > throughout the document could be more surgical as well as more specific about > whether they mean "people might deploy this differently in the future" or > "standards would need to be developed in the future." > I've made a few > suggestions about some of these turns of phrase below but would suggest someone > do a full edit pass with this in mind because there are a large number of > mentions of "future work." Of course there is always more work to do, but every > bit of "future work" need not be mentioned in this document, and in cases where > it is mentioned I think there should be a specific reason for doing so that > bears on people implementing this specification. I don't think this fits in the > DISCUSS criteria but for a document that intends to be published on the > standards track I would expect it to be crisper about the dividing line between > the normative behavior being specified here versus changes or extensions that > may or may not be made in the future. Let me answer in 5 points: 1. All relevant sections have "Normative" vs. "Informative" in their title. added "Informative" to sections where it was missing. Modified section 4: Requirements": Informative - ask from AD was not to have separate use-case/requirements document in charter round 1, so the use-case/requirements sections here are really only the input to the specification. The words in 4./Requirements are now _MUST_, _SHOULD_ to set them apart from rfc2119 and text explains it (i can change to any other preferrable syntactic differentiation). 2. Normative MUST/SHOULD are only in the normative sections. 3. Introduction also summarizes which sections are normative and which informative. I fixed up the text in the intro to be more complete wrt. to that. | The normative part of this document starts with | where the ACP is defined in detail. | defines normative how to support ACP | on L2 switches. explains normative how | non-ACP nodes and networks can be integrated. | The remaining sections are non-normative:... Also added sentence to introduction: | There are no dependencies against Appendix A to build a complete working and interoperable | ACP according to this document. 4. Eliminating gratuitous future - primarily from normative text. I have tried as good as possible to eliminate "futures" from the normative section (6...8,10). Here is a list of the changes except for the mayor ones you inquired about separately be low: 1) | See for discussions about how variations | of the ACP could be defined in the future (standard or proprietary) | to better meet different expectations from those on which the current design is based In informative section (applicability statement), forward pointer to A. I added "(standard or proprietary)" to be clearer. I insered this sentence because there where over the course of the WG work a lot of discussion about how to do things differently, the gist of it is in appendix A, so this is just a forward pointer. 4) | Connecting over non-ACP Layer-3 clouds requires explicit configuration. | See . | This may be automated in the future through auto discovery mechanisms across L3. Ok, this "future" is pretty gratuitous without explanation. Removed. 5) | Other uses are subject to future work, but it is recommended that | it is the default security check for any end-to-end connections | between ASA. It is equally useable by other functions such as | legacy OAM functions. Removed, refined first sentence of paragraph to hopefully be well inclusive of any such future work: | The ACP domain certificate SHOULD be used for any authentication | between nodes with ACP domain certificates (ACP nodes and NOC nodes) | where the required condition is ACP domain membership, such as ACP | node to NOC/OAM end-to-en security and ASA to ASA end-to-end security. 6) | extension = ; future definition. This is in the ABNF of the certificte extension specification, and that spec needs a hook to support for future definitions. 9) DELETED: | Future work optimizations could avoid this but it is unclear how | beneficial/feasible this is replaced with: | which has the following benefits: 10) DELETED: | If a node learns through a future autonomic method or through configuration that it is part of a zone replaced with: | If a node learns (see ) that it is part of a zone (auto-aggregation subsection is one of two new A. sections created in rely to this DISCUSS, see below). 11) DELETED: | (subject to future work) (in zone-id explanationt ext) no replacement (gratuitous). 12) DELETED: | Future work may define mechanisms for auto-coordination between ACP nodes and auto-allocation of Subnet-IDs between them no replacement (gratuitous). 14) IMPROVED: Future is used to explain the semantic of the "objective-value" in the SRV.est GRASP objective. I fixed up the text to be more precise: | Objective-value MUST be ignored if present. Backward compatible | extensions to MAY be indicated through | objective-value. Non compatible certificate | renewal options MUST use a different objective-name. 15) 6.11.1.1- moved notion about future improved RPL option (for multiple NOC) into appendix A 16) 6.12.2 - remove "future" from wording of performance through rewording (this is really just a matter of impleemntation choice, applicable to both first-generation or future geneation implementations, so no need to talk about futures. 17) 6.12.5 "future protocols". Just refined wording, but kept it unchanged. The reason to use the word "future" here was solely to emphasize on the independence of the described mechanisms, but not to suggest future work: | Any type of ACP secure channels to another ACP node can | be mapped to ACP virtual interfaces in different ways. | This is independent of the choosen secure channel protocol (IPsec, DTLS | or other future protocol): 18) 8.1.1 "ACP connect security: removed notion of future work, but instead gave an example that could be impleemtned without future (work outside the scope of this spec), and moved the suggestion that would require future standards work (using ACP spec extension) into A.10. 19) 7.2 - removed senetence with notion of future (MacSec) - gratuitous. 20) 8.1.2 - removed sentence with future. This was just describing interla implementation options, so that work wold be in scope of implementations of this spec, no need to call it futures. 21) 9.2.2 (informative section). Removed notion of future role based security. This is not one paragraph in A.10 22) Removed notion that we need a YANG data model (future work) for ACP/ANI Obvious enough so we will not forget even without this note. Overall: In the few places where i have kept "futures" in the normative text, i did try tou be explicit about "standard vs. non-standard" futures. In summary: there should now be close to minimal possible instances of "futures" in the normative text. I hope for this document this will suffice. 5. Futures discussion in section A: Note: Half of A. is futures, the other half is explanations. The futures where the part of the WG time we spent but concluded it was too much work to put into the current spec, but we hink it is crucial not to loose this work. (I have seen so many IETF standards RFC where this actual WG work context isn't kept but thrown out, and 10 years later the few people left with institutional memory have to re-explain the stuff, but why doc made decisions, and also what was seen as next steps). ------------------ >FIXED: > "Intent" is used both capitalized and in lower case throughout the document and > I'm unclear if this is meant to signify a distinction or not. Thanks. 3 occurances of intent -> Intent. ------------------ > POSTPONED/RFC-editor: > Section 2: > > Please remove the -->"..."() notation. Discussed in prior review, but the outcome ended up only in changelog. I've now inserted the following note on top of section 2 to avoid further comments on this: [RFC Editor: WG/IETF/IESG review of the terms below asked for references betwen these terms when they refer to each other. The only option in RFC/XML i found to point to a hanging text acronym definition that also displays the actual term is the format="title" version, which leads to references like '->"ACP domain certificate" ()'. I found no reasonable way to eliminate the trailing '()' generated by this type of cross references. Can you please take care of removing these artefacts during editing (after conversion to nroff ?). Also created ticket to ask for xml2rfc enhancement to avoid this in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. ------------------ > FIXED: > Please use the exact boilerplate from RFC 8174, not a variation. Thanks. i copied the text from what an earlier reviewer suggested. Must have come from RFC8196. Only RFC with that mistake (says google). > It seems like RFC citations should appear for IKEv2 and DTLS upon first use in > this section. Otherwise, it seems they are first cited at different future > points in the document (Section 6.3 and 6.7, respectively). Yepp. applicability section was added late, forgot to fixup first references. ------------------ > FIXED/NEW TEXT: > Section 3.3: > > "The ACP provides reachability that is independent of the Data-Plane > (except for the dependency discussed in Section 6.12.2 which can be > removed through future work)," > > Isn't this kind of a big exception, given that there is meant to be a secure > channel between pairs of nodes in the ACP and that developing future > encapsulations is non-trivial? It seems like phrasing this the other way around > (the ACP is dependent on the Data-Plane for but is otherwise independent > of it) would be more accurate. Nice! Thanks a lot to have me reconsider this text. This text is wrong because it is elevating limitations of the implementation of ACP that i helped build and am familiar with to limitation of the spec standard. So sometimes, knowing too much code doesn't help writing a spec *sigh*. Text changed to: | Depending on the implementation (see | for more details), the ACP provides reachability that can be | independent of the Data-Plane. This allows the control plane and management | plane to operate more robustly. "general_addressing" 6.12.2 (informative) text is fixed up to explain the candidate implementation issues better than in -16: | To avoid that Data-Plane configuration can imact the operations of the | IPv6 (link-local) interface/address used for ACP channels, appropriate | implementation considerations are required. If the IPv6 interface/link-local | address is shared with the Data-Plane it needs to be impossible to unconfigure/disable | it through configuration. Instead of sharing the IPv6 interface/link-local | address, a separate (virtual) interface with a separate IPv6 link-local | addresss could be used. For example, the ACP interface could be run over a separate | MAC addres of the underlying Ethernet type interface. For more details and options, | see . I added "A.10.2. Removing IPv6 data plane dependency" to further detail implementation options, and also one possible future that would require additional specification (different ethertype). The reason for regurgitating on this point i that its really the most difficult part of an implemenation if you want to be independent of the data plane. ------------------ > UNCHANGED/EXPLAINED: > Section 6: > > "Indestructible" seems like an overstatement. Maybe "resilient" would be more > accurate? As written, the ACP is meant to be resilient and indestructible. We use resilient to describe the ability to recover (from errors/attacks). This applies mostly to the network side (common property of most our routing stuff), but also with the Cert security system (revoking membership after nodes become compromisedetc.). We use indestructible to indicate the absence or reduction of an "attack surface". For example that ACP is defined to use clearly separated infra that would have only ReadOnly YANG models - no way to misconfigure. Or just ~3 UDP ports you could attack from the network (GRASP and IKEv2/IPsec). Aka: minimied atck surface from the network. Unattackable was a choice, but the biggest concern is friendly fire from erroneous peers, operators or SDN controllers without malicious intent. Therefore we concluded on indestructible. ------------------ > FIXED: > Section 6.1.1: > s/Such methods are subject to future work though./No such methods have been > defined at the time of publication of this document./ I fixed this text also in response to a discus from you below to make it clear when the acp-address is optional (for peers, not for ourselves). | Nodes complying with this specification MUST receive their ACP address | through the domain certificate, so their own ACP domain certificate MUST | contain the "acp-address" field. Nodes complying with this specification | MUST also be able to authentice nodes as ACP peers that have determined | their ACP address differently and whose ACP domain certificate may therefore | NOT have the "acp-address" field. See for further discussions. ------------------ > s/to build ACP channel/to build ACP channels/ ACK ------------------ > s/that intends to be equally unique/that it intends to be equally unique/ ACK ------------------ >FIX/CHANGED TEXT: > ""rsub" is optional; its syntax is defined in this document, > but its semantics are for further study. Understanding the benefits > of using rsub may depend on the results of future work on enhancing > routing for the ACP." > > What is the point of defining this now when it is unclear if or how it will be > used? There are already means for nodes to do error handling, so it seems like > defining a new field in the future if/when it is needed would work fine and be > cleaner. Appendix A.7 seems to assume some semantics for this field, which > makes the way it is specified here even more confusing IMO. Yes, that text was unnecessarily alluding to unresolved future issues when there is no need to do so because there are perfectly good use-case reasons to have rsub now and how to benefit from them now - without extensions. Texts fixed to: | "routing-subdomain" is the autonomic subdomain composed of "rsub" | and "acp-domain-name". "rsub" is optional. When not present, | "routing-subdomain" is the same as "acp-domain-name". "routing-subdomain" | determines the /48 ULA prefix for ACP addresses. "rsub" therefore allows | to use multiple /48 ULA prefixes in an ACP domain. | See for example use-cases. And that A.7 example is improved to: | The rsub element in the domain information field permits the use of addresses | from different ULA prefixes. One use case is to create multiple physical | networks that initially may be separated with one ACP domain but different | routing subdomains, so that all nodes can mutual trust their ACP domain | certificates (not depending on rsub) and so that they could connect later | together into a contiguous ACP networks.One instance of such a use case is an ACP for regions interconnected | via a non-ACP enabled core, for example due to the absence of product | support for ACP on the core nodes. ACP connect configurations as defined | in this document can be used to extend and interconnect those ACP islands | to the NOC and merge them into a single ACP when later that product | support gap is closed. Auto-aggregation is now only discussed in new section A.10.8.2 ------------------ > FIXED/CHANGED-TEXT: > "In this specification, the "acp-address" field is REQUIRED, but > future variations (see Appendix A.8) may use local information to > derive the ACP address. In this case, "acp-address" could be empty. > Such a variation would be indicated by an appropriate "extension". > If "acp-address" is empty, and "rsub" is empty too, the "local-part" > will have the format "rfcSELF + + extension(s)". The two plus > characters are necessary so the node can unambiguously parse that > both "acp-address" and "rsub" are empty." > > This seems contradictory. Either "acp-address" is REQUIRED in which case there > are no exceptions, or it's not; if it's not, then the expected syntax for cases > when it's not present should be specified. Thanks. Took me a while to understand i was talking about semantics and you about syntax. Fixed text accordingly. NOdes in this spec MUST have acp-address in their own cert, but must also recognize peer certs as valid without acp-address in the peers cert: | Nodes complying with this specification MUST be able to receive | their ACP address through the domain certificate, in which case | their own ACP domain certificate MUST contain the "acp-address" field. | Nodes complying with this specification MUST also be able to authenticate | nodes as ACP peers that have determined their ACP address differently | and whose ACP domain certificate MAY NOT have the "acp-address" field. | See for further discussions. ------------------ > Section 6.1.2: > > s/If the node certificates indicates/If the node certificate indicates/ ACK ------------------ > FIXED/ADDED TEXT: > Section 6.3: > > It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. Yes. The reason is that for once IPsec/IKE is important and proven and intended to be the primary protocol, and for non-security folks the naming might be somewhat confusing (IKE vs IPsec), and the whole options with without GRE and IKE able to autoselect this etc. Hence the explanations. But i added a boring sence about DTLS for equal treatment: "DTLS" indicates datagram Transport Layer Security version 1.2. There is no default UDP port, it must always be locally assigned by the node. See . Note that there is already "6.7.2. ACP via DTLS". ------------------ > FIXED: > Section 6.4: > > This is a good example of a section where the blurring between the specified > behavior and expectations for the future is unhelpful IMO. Why specify the > current default and then spend a lot of words (including Appendix A.7) talking > about how it will be different in the future? I have moved all the 6.4 Intent stufff into new section A.8 and also moved the Intent stuff in A.7 into A.8 to clean up. We did spend a lot of time in the WG to discuss the Intent issues, and i think that the little whats now left in A.8 is relevant documentation for possible future work that would otherwise get easily lost, so do not want to delete it completely. ------------------ > Section 6.10.3.1: > > s/We do not think this is required at this point/This is not currently required/ ACK ------------------ > Section 6.12.2: > > s/may specify additional layer 2 or layer encapsulations/may specify additional > layer 2 or layer 3 encapsulations/ (I think?) ACK ------------------ > Section 8.2.1: > > This seems extraneous: "Future work could transform this into a YANG > ([RFC7950]) data > model." ACK. ------------------ > Appendix A.8: > > "Secure channels may > even be replaced by simple neighbor authentication to create > simplified ACP variations for environments where no real security is > required but just protection against non-malicious misconfiguration." > > I think experience has shown that even environments where it is assumed that > security is not required prove to need it. I would suggest removing this text > or changing this implication. Yes, and again this was badly written text, the future option in mind wasn't meant to be insecure anyhow *sigh*: Sentence left for that suggestion is: | ACP hop-by-hop network layer secure channels could also be replaced | by end-to-end security plus other means for infrastructure protection. Note again, that we have been trying to make sure that all the text in this section A is not unsolicited but really the result of repeated questions/ requests in the WG to do things like this (or explains reasons for decisions in ACP). That one sentence for example goes back to the fact that the hop-by-hop encryption has been the biggest challenge to product adoption of ACP. ------------------ Impressed that you got all the way down to A.8. Thanks a lot! From nobody Thu Aug 9 18:00:47 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6A3130FFA; Thu, 9 Aug 2018 18:00:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153386283991.28744.9091243291268056328@ietfa.amsl.com> Date: Thu, 09 Aug 2018 18:00:39 -0700 Archived-At: Subject: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 01:00:41 -0000 Reviewer: Joel Halpern Review result: Ready with Issues 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. For more information, please see the FAQ at . Document: draft-ietf-anima-reference-model-06 Reviewer: Joel Halpern Review Date: 2018-08-09 IETF LC End Date: 2018-08-21 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as an Informational RFC. Clarity would be improved if the minor issues below were addressed. Major issues: N/A Minor issues: Section 2 includes "naming" in the list of services the ANI provides. Which surprised me. But then section 3 does not include "naming" in the list of services of the ANI in Figure 2 of section 3.1? In section 3.2, in the second paragraph on where adjacency information comes from, the text of the second bullet refers to vendor redirects. While I understand that those are an important part of the system information, they do not appear to create an adjacency? If they do, then the term adjacency needs to be better explained in this section. The first bullet in the next list says the same thing. My best guess is that adjacency sometime means actual topological adjacency, and sometimes means a more general form of adjacency. As written, I think it will confuse readers. IDevID (referenced in section 3.3.1 at least) appears to be a normative reference. Devices supporting the Anima Reference Model are required to support that, so understanding how to do so seems necessary for understanding this specification. Does section 3.3.2 intend to mandate that devices have persistent storage for the LDevID? Or is it trying to say that on power cycle it stays in Enrolled state if it retains its LDevID, but goes back to the Factory default state if not? (Given that folks have repeatedly said that these may be low power devices, I think we need to be clear about what we are requiring.) Section 5 starts by saying that the administrator does not have to configure security. In the very next paragraph it says that a PKI must be in place. That clearly requires configuring some security properties. Please reword. Section 6.2 says that all ASA must "follow the same operating principles". The general guideliens of what these must cover is then given. It is appropriate that this document does not specify the detailed behavior. That would go in a standards track document. But there is no reference to a draft covering that. So we have text saying that all ASA must follow "something", but no reference as to the content of that "something". Is this a real requirement? If so, it appears to be unmeetable. Nits/editorial comments: In section 3.2, why would / could an adjacency table track "validity and trust of the adjacent autonomic node's certificate" if all transactions have to verify that separately anyway? Why mention it here? In the next to last bullet of the second bulleted list of section 3.2, the text states that the node will start a "join assistant" ASA. Could we have a forward reference to 6.3.1.2 (which then has the necessary normative reference)? The first use of LDevID in section 3.3.1 should have a forward reference to the definition (which I think is section 5.2.) Section 3.3.2 in defining when a device is in the Enrolled state says that it in the Enrolled state if it has an LDevID. As far as I can tell, the added constraint is that it is not currently a member of an ACP. The text should include that. The third paragraph of section 6.1 refers to the Autonomic nodes and the ASAs as "self-aware". I do not know what meaning is being ascribed to that phrase. The usage does not seem to correspond to any meaning I can understood. Can we just remove the sentence? (I suspect that the intention is to lead to the fact that the functions can advertise their capabilities, and negotiate them. We don't need the sentence as grounding for that.) While I appreciate the reference to SUPA in section 7.2, the working group having been terminated by the AD makes this a difficult topic for people to find. Presumably, PCIM should be an actual reference to the relevant RFC. Personal opinion: Section 8 on coordination is too hypothetical to be useful to a reader of this document. I think it is better removed. From nobody Thu Aug 9 22:10:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63950130DCD; Thu, 9 Aug 2018 22:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 LBOsqcqB5J7q; Thu, 9 Aug 2018 22:10:23 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22271127148; Thu, 9 Aug 2018 22:10:22 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id AF09C58C5EB; Fri, 10 Aug 2018 07:10:18 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 927174402CB; Fri, 10 Aug 2018 07:10:18 +0200 (CEST) Date: Fri, 10 Aug 2018 07:10:18 +0200 From: Toerless Eckert To: Joel Halpern Cc: gen-art@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org Message-ID: <20180810051018.ovgyku7jk4dwvzy2@faui48f.informatik.uni-erlangen.de> References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153386283991.28744.9091243291268056328@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 05:10:27 -0000 Thanks a lot, Joel MichaelB has the editor pen, so just some quick thoughts as co-author/chair inline. On Thu, Aug 09, 2018 at 06:00:39PM -0700, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Issues > > 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. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-anima-reference-model-06 > Reviewer: Joel Halpern > Review Date: 2018-08-09 > IETF LC End Date: 2018-08-21 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is ready for publication as an Informational RFC. > Clarity would be improved if the minor issues below were addressed. > > Major issues: N/A > > Minor issues: > Section 2 includes "naming" in the list of services the ANI provides. > Which surprised me. But then section 3 does not include "naming" in the > list of services of the ANI in Figure 2 of section 3.1? 4.1 is explaining it. In the ACP document its called the Node-ID. > In section 3.2, in the second paragraph on where adjacency information > comes from, the text of the second bullet refers to vendor redirects. > While I understand that those are an important part of the system > information, they do not appear to create an adjacency? If they do, then > the term adjacency needs to be better explained in this section. The first Imho, the reference model text is correct. Just like in the non-autonomic input (third bullet item), this vendor-redirect/cloud-registrar would lead to an automatically set up remote ACP peer thats enterred into the adjacency table. > bullet in the next list says the same thing. My best guess is that > adjacency sometime means actual topological adjacency, and sometimes means > a more general form of adjacency. As written, I think it will confuse > readers. Hmm.. ACP is an overlay network that tries to match the underlay when it can (link-local-adjacencies) and that uses remote adjacencies when it needs to go over non-autonomic parts of the network. Not quite sure what text to most easily add to make this any clearer.. Any suggestions ? > IDevID (referenced in section 3.3.1 at least) appears to be a normative > reference. Devices supporting the Anima Reference Model are required to > support that, so understanding how to do so seems necessary for > understanding this specification. 802.1AR as already referenced by ACP > Does section 3.3.2 intend to mandate that devices have persistent storage > for the LDevID? Or is it trying to say that on power cycle it stays in > Enrolled state if it retains its LDevID, but goes back to the Factory > default state if not? (Given that folks have repeatedly said that these > may be low power devices, I think we need to be clear about what we are > requiring.) Both options are architecturally valid and the reference model does not take sides, even though we would expect that LDevID is persistent in most cases. I don't think low-power is the criteria for not to have a persistent LDevID, almost every tiny IoT device i've seen has some available flash cells. The security model of nodes without writable persistent storage comes to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash only, power-cycle recreates known "good" state on device). > Section 5 starts by saying that the administrator does not have to > configure security. In the very next paragraph it says that a PKI must be > in place. That clearly requires configuring some security properties. > Please reword. I had same comment on ACP. I was going to fix it in ACP by saying "does not need to configure security on any (ANI/ACP) nodes other than Registrars and other PKI components (CA, CRL-DP,...). Network can have 10,000 nodes and maybe just 2 registrar/CAs.. > Section 6.2 says that all ASA must "follow the same operating principles". > The general guideliens of what these must cover is then given. It is > appropriate that this document does not specify the detailed behavior. > That would go in a standards track document. But there is no reference to > a draft covering that. So we have text saying that all ASA must follow > "something", but no reference as to the content of that "something". Is > this a real requirement? If so, it appears to be unmeetable. chair hat on: There can not be a draft covering this yet, because the current ANIMA charter didn't allow us to do this. We've got individual drafts lined up for this topic, we just need to get through the rechartering, we have started the discuss with our AD and wanted to then bring this to the WG. Cheers Toerless > Nits/editorial comments: > In section 3.2, why would / could an adjacency table track "validity and > trust of the adjacent autonomic > node's certificate" if all transactions have to verify that separately > anyway? Why mention it here? > > In the next to last bullet of the second bulleted list of section 3.2, the > text states that the node will start a "join assistant" ASA. Could we have > a forward reference to 6.3.1.2 (which then has the necessary normative > reference)? > > The first use of LDevID in section 3.3.1 should have a forward reference to > the definition (which I think is section 5.2.) > > Section 3.3.2 in defining when a device is in the Enrolled state says that > it in the Enrolled state if it has an LDevID. As far as I can tell, the > added constraint is that it is not currently a member of an ACP. The text > should include that. > > The third paragraph of section 6.1 refers to the Autonomic nodes and the > ASAs as "self-aware". I do not know what meaning is being ascribed to that > phrase. The usage does not seem to correspond to any meaning I can > understood. Can we just remove the sentence? (I suspect that the > intention is to lead to the fact that the functions can advertise their > capabilities, and negotiate them. We don't need the sentence as grounding > for that.) > > While I appreciate the reference to SUPA in section 7.2, the working group > having been terminated by the AD makes this a difficult topic for people to > find. Presumably, PCIM should be an actual reference to the relevant RFC. > > Personal opinion: Section 8 on coordination is too hypothetical to be > useful to a reader of this document. I think it is better removed. From nobody Fri Aug 10 07:12:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACED130E02; Fri, 10 Aug 2018 07:12:41 -0700 (PDT) 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_PASS=-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 k9nBkK2z0P_W; Fri, 10 Aug 2018 07:12:39 -0700 (PDT) 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 AAA4B130DF7; Fri, 10 Aug 2018 07:12:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 986C89C0118; Fri, 10 Aug 2018 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1533910359; bh=XOwF1VWsnfSNqDojE3KuoNlM0bs4q4iMrTHlijv3dYw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WQGtdHqThwdC0ZgPrVzdDgeWX9VOJeqQGRjADNXnVGj97ibGZHWEnzCrNvxpTGPNc hvT1UFRpvEJV1fZR4fdA9uEMO+Y95mBEqQ01Xw0mttbR4/S11MYczDi08TsonVSa75 Zu6NGaAoWeUG9NXEFRc/IUdil9PKKph1HzgtIzdc= 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 810E19C018C; Fri, 10 Aug 2018 07:12:38 -0700 (PDT) To: Toerless Eckert Cc: gen-art@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> <20180810051018.ovgyku7jk4dwvzy2@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: Date: Fri, 10 Aug 2018 10:12:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180810051018.ovgyku7jk4dwvzy2@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 14:12:41 -0000 I await Michael's comments. A few in line responses (marked where I think I may have been misunderstood. I have trimmed the rest. As noted in the elided text, these are all concerned with clarity. Yours, Joel On 8/10/18 1:10 AM, Toerless Eckert wrote: ... > On Thu, Aug 09, 2018 at 06:00:39PM -0700, Joel Halpern wrote: >> Reviewer: Joel Halpern >> Review result: Ready with Issues ... >> >> Minor issues: >> Section 2 includes "naming" in the list of services the ANI provides. >> Which surprised me. But then section 3 does not include "naming" in the >> list of services of the ANI in Figure 2 of section 3.1? > > 4.1 is explaining it. In the ACP document its called the Node-ID. I saw 4.1. If naming is intended to be a service provided by the ACP, then figure 2 and the text in section 3.1 apparently should include it. > >> In section 3.2, in the second paragraph on where adjacency information >> comes from, the text of the second bullet refers to vendor redirects. >> While I understand that those are an important part of the system >> information, they do not appear to create an adjacency? If they do, then >> the term adjacency needs to be better explained in this section. The first > > Imho, the reference model text is correct. Just like in the non-autonomic > input (third bullet item), this vendor-redirect/cloud-registrar would > lead to an automatically set up remote ACP peer thats enterred into the > adjacency table. I can't find anything in the bootstrap document redirect section that suggests the behavior you indicate. > >> bullet in the next list says the same thing. My best guess is that >> adjacency sometime means actual topological adjacency, and sometimes means >> a more general form of adjacency. As written, I think it will confuse >> readers. > > Hmm.. ACP is an overlay network that tries to match the underlay when > it can (link-local-adjacencies) and that uses remote adjacencies when > it needs to go over non-autonomic parts of the network. > > Not quite sure what text to most easily add to make this any clearer.. > Any suggestions ? The text mixes both uses of adjacency without distinction. One could seaprate the usage. One could add explanatory text. Something to clarify the situation. > >> IDevID (referenced in section 3.3.1 at least) appears to be a normative >> reference. Devices supporting the Anima Reference Model are required to >> support that, so understanding how to do so seems necessary for >> understanding this specification. > > 802.1AR as already referenced by ACP My only concern is that it appears to need to be a normative reference here, as it seems to be needed for understanding this document. > >> Does section 3.3.2 intend to mandate that devices have persistent storage >> for the LDevID? Or is it trying to say that on power cycle it stays in >> Enrolled state if it retains its LDevID, but goes back to the Factory >> default state if not? (Given that folks have repeatedly said that these >> may be low power devices, I think we need to be clear about what we are >> requiring.) > > Both options are architecturally valid and the reference model > does not take sides, even though we would expect that LDevID is > persistent in most cases. > > I don't think low-power is the criteria for not to have a persistent LDevID, > almost every tiny IoT device i've seen has some available flash cells. > > The security model of nodes without writable persistent storage comes > to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash > only, power-cycle recreates known "good" state on device). The text as written implicitly requires persistent storage. If the intention is to allow both models (as I would hope) please tune the text in section 3.3.2. > >> Section 5 starts by saying that the administrator does not have to >> configure security. In the very next paragraph it says that a PKI must be >> in place. That clearly requires configuring some security properties. >> Please reword. > > I had same comment on ACP. I was going to fix it in ACP by saying > "does not need to configure security on any (ANI/ACP) nodes other > than Registrars and other PKI components (CA, CRL-DP,...). > > Network can have 10,000 nodes and maybe just 2 registrar/CAs.. > >> Section 6.2 says that all ASA must "follow the same operating principles". >> The general guideliens of what these must cover is then given. It is >> appropriate that this document does not specify the detailed behavior. >> That would go in a standards track document. But there is no reference to >> a draft covering that. So we have text saying that all ASA must follow >> "something", but no reference as to the content of that "something". Is >> this a real requirement? If so, it appears to be unmeetable. > > chair hat on: > There can not be a draft covering this yet, because the current > ANIMA charter didn't allow us to do this. We've got individual drafts > lined up for this topic, we just need to get through the rechartering, > we have started the discuss with our AD and wanted to then bring this to > the WG. How can this informational documents say "ASA must ..." if there is no definition of what they must do. If the WG has not addressed this topic, then reword this. Maybe "It is expected that wide deployment in the future will need ..." > > Cheers > Toerless > From nobody Fri Aug 10 09:12:50 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF16130E34; Fri, 10 Aug 2018 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 IGGNHP0ViQes; Fri, 10 Aug 2018 09:12:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDFA0130E26; Fri, 10 Aug 2018 09:12:32 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BE6D958C4C1; Fri, 10 Aug 2018 18:12:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id AF43C4402CB; Fri, 10 Aug 2018 18:12:28 +0200 (CEST) Date: Fri, 10 Aug 2018 18:12:28 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: gen-art@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org Message-ID: <20180810161228.kylkuaq4c3uddfc2@faui48f.informatik.uni-erlangen.de> References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> <20180810051018.ovgyku7jk4dwvzy2@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 16:12:35 -0000 On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote: > > Imho, the reference model text is correct. Just like in the non-autonomic > > input (third bullet item), this vendor-redirect/cloud-registrar would > > lead to an automatically set up remote ACP peer thats enterred into the > > adjacency table. > I can't find anything in the bootstrap document redirect section that > suggests the behavior you indicate. Thats true, the BRSKI documents defines key cryptographic aspects of a cloud registrar and there are a lot of options for a full solution, and the conclusion was to do these things as followup work from BRSKI / ACP. > > Hmm.. ACP is an overlay network that tries to match the underlay when > > it can (link-local-adjacencies) and that uses remote adjacencies when > > it needs to go over non-autonomic parts of the network. > > > > Not quite sure what text to most easily add to make this any clearer.. > > Any suggestions ? > The text mixes both uses of adjacency without distinction. One could > seaprate the usage. One could add explanatory text. Something to clarify > the situation. Hmm.. it does clearly distinguish the three cases through bullet points, each one describing one of the three cases. Maybe i'm just confused what you think is missing and Michael immediately sees it. > > 802.1AR as already referenced by ACP > My only concern is that it appears to need to be a normative reference > here, as it seems to be needed for understanding this document. I don't think its necessary to read 802.1AR to understand the security reason why its used. BRSKI does that explanation, and BRSKI is already normative. Personally, i dislike to have "pay-to-read" documents as normative references, as much as i do appreciate every SDOs need to finance itself. > > The security model of nodes without writable persistent storage comes > > to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash > > only, power-cycle recreates known "good" state on device). > > The text as written implicitly requires persistent storage. If the > intention is to allow both models (as I would hope) please tune the text in > section 3.3.2. Maybe a sentence at the end: On devices without persistent storage for the LDevID, a powercycle should behave like a factory reset. > > chair hat on: > > There can not be a draft covering this yet, because the current > > ANIMA charter didn't allow us to do this. We've got individual drafts > > lined up for this topic, we just need to get through the rechartering, > > we have started the discuss with our AD and wanted to then bring this to > > the WG. > How can this informational documents say "ASA must ..." if there is no > definition of what they must do. If the WG has not addressed this topic, > then reword this. Maybe "It is expected that wide deployment in the future > will need ..." I think 6.1 is just missing the (*). Cheers Toerless From nobody Fri Aug 10 09:16:58 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE82130E8F; Fri, 10 Aug 2018 09:16:57 -0700 (PDT) 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_PASS=-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 5eAJ8tlmsWPq; Fri, 10 Aug 2018 09:16:56 -0700 (PDT) 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 EE02F130E68; Fri, 10 Aug 2018 09:16:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DD3CB9C098A; Fri, 10 Aug 2018 09:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1533917815; bh=ZIffEPtutCYLsU/VRHcTY/Titykrngl8aF6ywDtN3ZM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iwliC1NJJSPlVzhj9eDX6mPSLPHE1/HT1E9Bse6P33qb/rCpfNEns+eZfT/vgx63Z u7k/wupA7YVCW8MrB1aT1rHnqfaNA4Xv+KJth22EaJT0QNDn79zrX1mHCCz/aeOqlj wGEK9PBP7FaSw+TthJ8X/I/Xc8+hhWAnTN92GWXk= 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 043629C06C5; Fri, 10 Aug 2018 09:16:54 -0700 (PDT) To: Toerless Eckert Cc: gen-art@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> <20180810051018.ovgyku7jk4dwvzy2@faui48f.informatik.uni-erlangen.de> <20180810161228.kylkuaq4c3uddfc2@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: <6ffee0e8-c06a-a3e7-8f67-44a5f6c31837@joelhalpern.com> Date: Fri, 10 Aug 2018 12:16:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180810161228.kylkuaq4c3uddfc2@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 16:16:58 -0000 At this point I think we understand each other's points, and I will wait for Michael to comment as pen-holder. Thank you for the prompt response and discussion. Yours, Joel PS: While I sympathize with your reaction to paying for standards from other SDOs, that is not what determines whether we reference them, or whether those references are normative. No mater how much we wish otherwise :-) On 8/10/18 12:12 PM, Toerless Eckert wrote: > On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote: >>> Imho, the reference model text is correct. Just like in the non-autonomic >>> input (third bullet item), this vendor-redirect/cloud-registrar would >>> lead to an automatically set up remote ACP peer thats enterred into the >>> adjacency table. >> I can't find anything in the bootstrap document redirect section that >> suggests the behavior you indicate. > > Thats true, the BRSKI documents defines key cryptographic aspects > of a cloud registrar and there are a lot of options for a full solution, > and the conclusion was to do these things as followup work from BRSKI / ACP. > >>> Hmm.. ACP is an overlay network that tries to match the underlay when >>> it can (link-local-adjacencies) and that uses remote adjacencies when >>> it needs to go over non-autonomic parts of the network. >>> >>> Not quite sure what text to most easily add to make this any clearer.. >>> Any suggestions ? >> The text mixes both uses of adjacency without distinction. One could >> seaprate the usage. One could add explanatory text. Something to clarify >> the situation. > > Hmm.. it does clearly distinguish the three cases through bullet > points, each one describing one of the three cases. Maybe i'm > just confused what you think is missing and Michael immediately sees it. > >>> 802.1AR as already referenced by ACP >> My only concern is that it appears to need to be a normative reference >> here, as it seems to be needed for understanding this document. > > I don't think its necessary to read 802.1AR to understand > the security reason why its used. BRSKI does that explanation, > and BRSKI is already normative. Personally, i dislike to have "pay-to-read" > documents as normative references, as much as i do appreciate > every SDOs need to finance itself. > >>> The security model of nodes without writable persistent storage comes >>> to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash >>> only, power-cycle recreates known "good" state on device). >> >> The text as written implicitly requires persistent storage. If the >> intention is to allow both models (as I would hope) please tune the text in >> section 3.3.2. > > Maybe a sentence at the end: > > On devices without persistent storage for the LDevID, a powercycle > should behave like a factory reset. > >>> chair hat on: >>> There can not be a draft covering this yet, because the current >>> ANIMA charter didn't allow us to do this. We've got individual drafts >>> lined up for this topic, we just need to get through the rechartering, >>> we have started the discuss with our AD and wanted to then bring this to >>> the WG. >> How can this informational documents say "ASA must ..." if there is no >> definition of what they must do. If the WG has not addressed this topic, >> then reword this. Maybe "It is expected that wide deployment in the future >> will need ..." > > I think 6.1 is just missing the (*). > > Cheers > Toerless > From nobody Fri Aug 10 13:24:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684AC130E9F; Fri, 10 Aug 2018 13:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QZrPN0ZW91m; Fri, 10 Aug 2018 13:24:28 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BF2130E2F; Fri, 10 Aug 2018 13:24:28 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id t17-v6so4467583ply.13; Fri, 10 Aug 2018 13:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qwIFY2K1oFUtQeOWdzJsHNcdSmFKRVOHw+BCAQPoC2A=; b=A0h+fmSd+WboTCZklodpcc2+7KHhHIEVq5E3nL7vaBOMZ8Ga1Wtn8Me267L+YfjSiG JpMKERvQUPVfPQROc/VhWlXkeTaz1sM1sUUfpeXwdlG8t4KCKDhuWs1gy81XgGv4/boT VWO9IDDxj9HGWK06DerH1kS1cgcnvtxM6CdIdOJiGhdX17L7iIa4gHTVrAwDeLVMNI6t +66HP0LVnVIYNaWMU7Ns1tbbakmmJGKMCTsV4DsY9zxcReSNK2Ygeb60qT38p01MycL9 8d1wrxD/v4vaZU38t2e1YRPkeXrHePeC7siOfAAcD38DRXZK/1oUCNF4stfI2DKACsIm lK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qwIFY2K1oFUtQeOWdzJsHNcdSmFKRVOHw+BCAQPoC2A=; b=ojryyk4ybc2qtl0p4MtosLTJVLj0tb+EaXFFAGOP04PfY7fm79PDRsEj7cYxtpvpYl B2R2qb3KcBqknWtsuG8cldGoLeWPP2QtGy8VihLB3+flADI1H2/WgUnqVWmymuKgG/hc ZUgw/Z4MSNeCnYDdmaiwhRTLxuoQryKCUYuzj4xeq9+gRqEvdL6udpgyBklLLQiA491x kEcIqODSkkb1t4HEa83ApDlY37W0LzRJRTTQ5Y0gBK3xMfj0FgEvWMvzlGGbWKle2KZl zzrBpD/BbtfVKwIzNlGDVQQlr6GCf5qhTjVJfC/pyukmfboBB2qFQECINx2F8EWRB77T zEXQ== X-Gm-Message-State: AOUpUlH/i/kkC4mCIFXemg8+bcrb3OBamRFk/VUP3MDgyHSy1Omy7cjB xkLcnJJlqvhejudSuNQNRYDHGaE0 X-Google-Smtp-Source: AA+uWPyGRP7eFBE+P7JpV/whSDF0YYIkcI7+MXIUgLLNSvPHUDzA2jZI134yEDcACuHYx8Dz+E5Vfg== X-Received: by 2002:a17:902:8e81:: with SMTP id bg1-v6mr7355563plb.129.1533932668196; Fri, 10 Aug 2018 13:24:28 -0700 (PDT) Received: from [192.168.178.30] (227.24.255.123.static.snap.net.nz. [123.255.24.227]) by smtp.gmail.com with ESMTPSA id q78-v6sm17869229pfi.185.2018.08.10.13.24.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Aug 2018 13:24:27 -0700 (PDT) To: Toerless Eckert , "Joel M. Halpern" Cc: gen-art@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> <20180810051018.ovgyku7jk4dwvzy2@faui48f.informatik.uni-erlangen.de> <20180810161228.kylkuaq4c3uddfc2@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Sat, 11 Aug 2018 08:24:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180810161228.kylkuaq4c3uddfc2@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 20:24:30 -0000 (CCs trimmed, since I doubt that ietf@ietf.org cares to see the details...) Just on a couple of points: >>> chair hat on: >>> There can not be a draft covering this yet, because the current >>> ANIMA charter didn't allow us to do this. We've got individual drafts >>> lined up for this topic, we just need to get through the rechartering, >>> we have started the discuss with our AD and wanted to then bring this to >>> the WG. >> How can this informational documents say "ASA must ..." if there is no >> definition of what they must do. If the WG has not addressed this topic, >> then reword this. Maybe "It is expected that wide deployment in the future >> will need ..." > > I think 6.1 is just missing the (*). I hadn't thought of draft-carpenter-anima-asa-guidelines ever going to the standards track. In any case we'd need a lot more implementation experience before we could consider that. So IMHO we should simply wordsmith section 6.2 to avoid any hint of a normative requirement. Similarly: > Personal opinion: Section 8 on coordination is too hypothetical to be > useful to a reader of this document. I think it is better removed. It's definitely a future work item, but as a minimum I think we should state the problem, so I would suggest editing it down rather than deleting it. Brian From nobody Sat Aug 11 02:51:11 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21943130FBF; Sat, 11 Aug 2018 02:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFKSSQ7LK21E; Sat, 11 Aug 2018 02:51:07 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF84A130FC1; Sat, 11 Aug 2018 02:51:06 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BD5B0C7AD3FC7; Sat, 11 Aug 2018 10:51:02 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 11 Aug 2018 10:51:04 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.206]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Sat, 11 Aug 2018 17:50:58 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: ANIMA minutes - IETF 102 Montreal, Canada Thread-Index: AdQxWK3cqOoHnlabSQus6ftKugbT0w== Date: Sat, 11 Aug 2018 09:50:58 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B929018C5C2@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B929018C5C2NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] ANIMA minutes - IETF 102 Montreal, Canada X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 09:51:09 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B929018C5C2NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, The minutes for the ANIMA sessions at IETF102 in Montrealcan be found at:: https://datatracker.ietf.org/doc/minutes-102-anima/ Many thanks to Bing Liu for taking minutes. Please send any corrections to the chairs. Best regards, Sheng + Toerless --_000_5D36713D8A4E7348A7E10DF7437A4B929018C5C2NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

The minutes for the ANIMA sessi= ons at IETF102 in Montrealcan be found at::

 

https://datatracker.ietf.org/doc/minutes-1= 02-anima/

 

Many thanks to Bing Liu for tak= ing minutes.

 

Please send any corrections to = the chairs.

 

Best regards,=

 

Sheng + Toerless=

--_000_5D36713D8A4E7348A7E10DF7437A4B929018C5C2NKGEML515MBSchi_-- From nobody Sat Aug 11 07:36:31 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FAB13103F; Sat, 11 Aug 2018 07:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_TVD_FUZZY_SECURITIES=0.01, URIBL_BLOCKED=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 OQ6qfFz-m-_p; Sat, 11 Aug 2018 07:36:07 -0700 (PDT) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 7873E13101B; Sat, 11 Aug 2018 07:36:06 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id r4-v6so6136772edp.9; Sat, 11 Aug 2018 07:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=v8pGrUtTe39oNYfoFS4t1q6OAF9M3a4SeFANzMAz6f0=; b=G7tm0+SC8yG9ZVOd723itnCMDpIWebcmWB2cc6SQPBEpFwpUXx8RRK87DR/njGxdVA rIYNfiDH5tkz1u3EOnWWp9of5+LVYZBvbRCXaiTDXAp+L/EHikDGAHO3gx51bRpYzYj2 HPWCFyTMvGcrCeRUV5L8D8QyU34gaybBJbwZNBqc6bWoFTSLMISNoFxd/9MCSgbhHQgB 0Of0wuZqRcPNtaJ42PZJSiuKNhtwrcvrpNp7byLoHdp6GF/Fedg0QOdYgplkkD8FhKBP OnDeiabkwl34rhfnReNFm92Bmtiwa331SOcw11mQKylEskH9lYnjzFmPc5m3x0z049Fl YPJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=v8pGrUtTe39oNYfoFS4t1q6OAF9M3a4SeFANzMAz6f0=; b=UbaS5Roas6peODBCIJuNkmDUw1+ZzNOiYt0adnDvR0SzlnPlnKLowMcShmvzsRnD1P a5nYt9I9rduHd1pqNMql/Prod4Xz1OJTLze66A8D0/PFF7t2+G/dSm9o6tF2vs4WcX2d GQtBNRa1Nr9gL0v/tn7wMDqrlSUrpEX/bXcng9sVuZ0VOY8nN1zicvLKPMVhXaRPtG+n 1+zXGoea8YGoOv0ZRXPOogcO/vJdAO0/uza0Hpja3UbFaea6AXCKUteIfC+nv5/ATpSV 4O402tE9LmaYjJc8TSr//mx0Q/eUSEwRKFzgyeorC/idA+pvDzJOSXQQB697FiA81hX9 O0mQ== X-Gm-Message-State: AOUpUlE3ZBSxS7Y84OGRHbmbSpvPBnJ375kQf9zlbazHhYfWzxWgNFjs 6RA8MDDC+LzzOOLWRfhnkIc= X-Google-Smtp-Source: AA+uWPyrb4ymoj7v597jRywC4nFAsVnc2pHbnSyk1ntGx+3P01Bs0uLQ0yC7mUm4d00oj33QoUBQug== X-Received: by 2002:a50:a105:: with SMTP id 5-v6mr13353877edj.186.1533998164975; Sat, 11 Aug 2018 07:36:04 -0700 (PDT) Received: from [10.226.92.40] (80-254-69-40.dynamic.monzoon.net. [80.254.69.40]) by smtp.gmail.com with ESMTPSA id i15-v6sm4679880edq.56.2018.08.11.07.36.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Aug 2018 07:36:03 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Joel Halpern , gen-art@ietf.org Cc: anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> Message-ID: <12e38af2-c0bd-d0da-92f2-34a520ffadcb@gmail.com> Date: Sat, 11 Aug 2018 16:36:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153386283991.28744.9091243291268056328@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------D99C84AA3FD38F97807EBC08" Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 14:36:19 -0000 This is a multi-part message in MIME format. --------------D99C84AA3FD38F97807EBC08 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Joel for the thorough review! Sorry for the delayed response, I was mostly offline on business travel. As Brian, I also took ietf@ietf.org off the cc, please let me know if this is inappropriate, in which case I repost with that list on. Inline... On 10/08/2018 10:00, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Issues > > 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. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-anima-reference-model-06 > Reviewer: Joel Halpern > Review Date: 2018-08-09 > IETF LC End Date: 2018-08-21 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is ready for publication as an Informational RFC. > Clarity would be improved if the minor issues below were addressed. > > Major issues: N/A > > Minor issues: > Section 2 includes "naming" in the list of services the ANI provides. > Which surprised me. But then section 3 does not include "naming" in the > list of services of the ANI in Figure 2 of section 3.1? Yes, naming is actually required for an autonomic solution. I understand your concern though, and added it to figure 2 and section 3.1. It's more consistent, you're right. > In section 3.2, in the second paragraph on where adjacency information > comes from, the text of the second bullet refers to vendor redirects. > While I understand that those are an important part of the system > information, they do not appear to create an adjacency? If they do, then > the term adjacency needs to be better explained in this section. The first > bullet in the next list says the same thing. My best guess is that > adjacency sometime means actual topological adjacency, and sometimes means > a more general form of adjacency. As written, I think it will confuse > readers. Hmmm... I re-read our text, and I think it describes exactly what we want to say. :-)  So there is clearly a problem. The original idea was that a new node with factory default settings needs to be able to find where it should connect. Since a factory default device cannot have specific information of its final network placement, the vendor MASA can be set up to provide information to the new node on where its home network is. I think we're probably in sync up to here. Now, our design decision was that this re-direct from the MASA should not require any other treatment than any other adjacency: It delivers an IP address to connect to, and to set up the ACP with. From this logic follows that the re-direct address is also entered into the adjacency table, and not treated in any "special" way. So, the real problem is probably the referernce to BRSKI, since this behaviour is not yet defined there. I suggest to simply remove the reference to BRSKI at this point. That seems to be the only confusing bit. And it allows potentially another document in the future to take up the details. I've taken it out for now. If anyone thinks that's a bad idea, shout! :-) > IDevID (referenced in section 3.3.1 at least) appears to be a normative > reference. Devices supporting the Anima Reference Model are required to > support that, so understanding how to do so seems necessary for > understanding this specification. I just read the entire discussion on this point, and am unsure what you would like us to do, or what the problem actually is. Can you be more specific? > Does section 3.3.2 intend to mandate that devices have persistent storage > for the LDevID? Or is it trying to say that on power cycle it stays in > Enrolled state if it retains its LDevID, but goes back to the Factory > default state if not? (Given that folks have repeatedly said that these > may be low power devices, I think we need to be clear about what we are > requiring.) Yes, your guess is absolutely right. I clarified that now by adding in the intro of section 3.3 (it affects the state machine in TWO points, actually):     A device is normally expected to store its LDevID in persistent storage, to be available after a powercycle event. For device types that cannot store the LDevID in persistent storage, a powercycle event is effectively equivalent to a factory reset. > Section 5 starts by saying that the administrator does not have to > configure security. In the very next paragraph it says that a PKI must be > in place. That clearly requires configuring some security properties. > Please reword. I added a little phrase at the end of the sentence which now reads:     An Autonomic Network is self-protecting. All protocols are secure by default, without the requirement for the administrator to explicitly configure security, with the exception of setting up a PKI infrastructure. > Section 6.2 says that all ASA must "follow the same operating principles". > The general guideliens of what these must cover is then given. It is > appropriate that this document does not specify the detailed behavior. > That would go in a standards track document. But there is no reference to > a draft covering that. So we have text saying that all ASA must follow > "something", but no reference as to the content of that "something". Is > this a real requirement? If so, it appears to be unmeetable. I think the "must" is misleading here. It's not meant to imply that we have something ready-to-go for this, it's saying: One day, when someone bites his teeth into this problem, make sure that all ASAs are managed in the same way. So, re-phrasing: "Management of ASAs and its interactions with the ANI should follow the same operating principles, hence comply to a generic life-cycle management model." This should be sufficiently clear what we mean, without implying that we already have a solution. OK? > Nits/editorial comments: > In section 3.2, why would / could an adjacency table track "validity and > trust of the adjacent autonomic > node's certificate" if all transactions have to verify that separately > anyway? Why mention it here? Yes, that doesn't read right. Simplified that to: "The adjacency table may contain information about the validity and trust level of the adjacent autonomic node."  (deleted the second sentence). Does that work? > In the next to last bullet of the second bulleted list of section 3.2, the > text states that the node will start a "join assistant" ASA. Could we have > a forward reference to 6.3.1.2 (which then has the necessary normative > reference)? Done. > The first use of LDevID in section 3.3.1 should have a forward reference to > the definition (which I think is section 5.2.) Done. > Section 3.3.2 in defining when a device is in the Enrolled state says that > it in the Enrolled state if it has an LDevID. As far as I can tell, the > added constraint is that it is not currently a member of an ACP. The text > should include that. Done. > The third paragraph of section 6.1 refers to the Autonomic nodes and the > ASAs as "self-aware". I do not know what meaning is being ascribed to that > phrase. The usage does not seem to correspond to any meaning I can > understood. Can we just remove the sentence? (I suspect that the > intention is to lead to the fact that the functions can advertise their > capabilities, and negotiate them. We don't need the sentence as grounding > for that.) We mean: In a traditional network, a big fat brain knows all the capabilities and hardware details of all platforms, and decides centrally which software bits and command lines and other bits and pieces should go to which node. In an autonomic network, it is the node itself that knows its own h/w features and capabilities, and decides how to implement the guidance of the central brain, which now only issues Intent. Modified that to: "Autonomic nodes, and therefore their ASAs, know their own capabilities and restrictions, derived from hardware, firmware or pre-installed software: They are "self-aware". The role of an autonomic node depends on Intent and on the surrounding network behaviors, which may include forwarding behaviors, aggregation properties, topology location, bandwidth, tunnel or translation properties, etc. For example, a node may decide to act as a backup node for a neighbor, if its capabilities allow it to do so. " (Laurent - please let me know if you are ok with this change) > While I appreciate the reference to SUPA in section 7.2, the working group > having been terminated by the AD makes this a difficult topic for people to > find. Presumably, PCIM should be an actual reference to the relevant RFC. Removed SUPA, and left PCIM. > Personal opinion: Section 8 on coordination is too hypothetical to be > useful to a reader of this document. I think it is better removed. I appreciate your opinion, but I would prefer to keep it, as background info. It's clearly labelled with an "*". This piece of the story was contributed by Laurent and Pierre, who had done a lot of work in this area, and I really learned a lot from it. Designers of ASAs should definitely read it. There is a lot of stuff in there that you might miss without this section. But, I'm looking at Laurent and Pierre to comment as well. Maybe the material is covered in the same way on another draft, and we could point to that? (On a plane right now, can't check). If not, I would not want to delete nor shorten it. Made all the changes in draft-ietf-anima-reference-model.xml on github, and created the corresponding txt file. I'm not going to submit a new version quite yet, more comments are likely to come :-) Co-authors: Please review and double-check. Let me know if you disagree with any change. See: https://github.com/mbehring/ANIMA-Reference-Model files draft-ietf-anima-reference-model.txt and .xml. Diff attached. Joel: Thanks for the detailed review! It made the document better! Michael --------------D99C84AA3FD38F97807EBC08 Content-Type: text/html; charset=UTF-8; name="Diff draft-ietf-anima-reference-model-06_txt - draft-ietf-anima-reference-model_txt_htm.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="Diff draft-ietf-anima-reference-model-06_txt - draft-ietf-an"; filename*1="ima-reference-model_txt_htm.htm" CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRp b25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFu c2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NzogcmZjZGlm ZiAgLS0+IAo8IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0 LjAxIFRyYW5zaXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGRlY2hhdW5hYyAz LjIuMC00LWFtZDY0ICMxIFNNUCBEZWJpYW4gMy4yLjY4LTErZGViN3U2IHg4Nl82NCBHTlUv TGludXggLS0+IAo8IS0tIFVzaW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjEu MSwgQVBJOiAxLjEgKEdOVSBNUEZSIDMuMS4zLCBHTlUgTVAgNi4wLjApIC0tPiAKPCEtLSBV c2luZyBkaWZmOiAvdXNyL2Jpbi9kaWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjMgLS0+ IAo8IS0tIFVzaW5nIHdkaWZmOiAvdXNyL2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikg MS4yLjIgLS0+IAo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+ IAo8aGVhZD4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIC8+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl bnQtU3R5bGUtVHlwZSIgY29udGVudD0idGV4dC9jc3MiIC8+IAogIDx0aXRsZT5EaWZmOiBk cmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wNi50eHQgLSBkcmFmdC1pZXRmLWFu aW1hLXJlZmVyZW5jZS1tb2RlbC50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0idGV4dC9j c3MiPiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1dG87 IH0gCiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1zcGFjZTogcHJlOyBm b250LWZhbWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXNpemU6 IDAuODZlbTt9IAogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNt YWxsICB7IGZvbnQtc2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1p bHk6IFZlcmRhbmEsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0ICAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29s b3I6ICNGRkY7IH0gCiAgICAuZGlmZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAK ICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQkZCOyB9IAogICAgLnJibG9jayB7 IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0gCiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1j b2xvcjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUNGOyB9 IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkI7IH0gCiAgICAuY29udCAg IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5saW5lYnIgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNvbG9yOiByZWQ7IGJhY2tncm91bmQt Y29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246IHJpZ2h0OyBwYWRk aW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9 IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREREOyB9IAogICAgLnJp Z2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5sYmxvY2sgLmNv bnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29udCB7IGJh Y2tncm91bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3Vu ZC1jb2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjOEFEOyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91 bmQtY29sb3I6ICNFRUU7IHBhZGRpbmc6IDJweCAwOyB9IAogICAgc3Bhbi5oaWRlIHsgZGlz cGxheTogbm9uZTsgY29sb3I6ICNhYWE7fSAgICBhOmhvdmVyIHNwYW4geyBkaXNwbGF5OiBp bmxpbmU7IH0gICAgdHIuY2hhbmdlIHsgYmFja2dyb3VuZC1jb2xvcjogZ3JheTsgfSAKICAg IHRyLmNoYW5nZSBhIHsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjb2xvcjogYmxhY2sgfSAK ICA8L3N0eWxlPiAKICAgICA8c2NyaXB0Pgp2YXIgY2h1bmtfaW5kZXggPSAwOwp2YXIgb2xk X2NodW5rID0gbnVsbDsKCmZ1bmN0aW9uIGZvcm1hdF9jaHVuayhpbmRleCkgewogICAgdmFy IHByZWZpeCA9ICJkaWZmIjsKICAgIHZhciBzdHIgPSBpbmRleC50b1N0cmluZygpOwogICAg Zm9yICh4PTA7IHg8KDQtc3RyLmxlbmd0aCk7ICsreCkgewogICAgICAgIHByZWZpeCs9JzAn OwogICAgfQogICAgcmV0dXJuIHByZWZpeCArIHN0cjsKfQoKZnVuY3Rpb24gZmluZF9jaHVu ayhuKXsKICAgIHJldHVybiBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCd0cltpZCQ9IicgKyBu ICsgJyJdJyk7Cn0KCmZ1bmN0aW9uIGNoYW5nZV9jaHVuayhvZmZzZXQpIHsKICAgIHZhciBp bmRleCA9IGNodW5rX2luZGV4ICsgb2Zmc2V0OwogICAgdmFyIG5ld19zdHI7CiAgICB2YXIg bmV3X2NodW5rOwoKICAgIG5ld19zdHIgPSBmb3JtYXRfY2h1bmsoaW5kZXgpOwogICAgbmV3 X2NodW5rID0gZmluZF9jaHVuayhuZXdfc3RyKTsKICAgIGlmICghbmV3X2NodW5rKSB7CiAg ICAgICAgcmV0dXJuOwogICAgfQogICAgaWYgKG9sZF9jaHVuaykgewogICAgICAgIG9sZF9j aHVuay5zdHlsZS5vdXRsaW5lID0gIiI7CiAgICB9CiAgICBvbGRfY2h1bmsgPSBuZXdfY2h1 bms7CiAgICBvbGRfY2h1bmsuc3R5bGUub3V0bGluZSA9ICIxcHggc29saWQgcmVkIjsKICAg IHdpbmRvdy5sb2NhdGlvbi5yZXBsYWNlKCIjIiArIG5ld19zdHIpCiAgICB3aW5kb3cuc2Ny b2xsQnkoMCwtMTAwKTsKICAgIGNodW5rX2luZGV4ID0gaW5kZXg7Cn0KCmRvY3VtZW50Lm9u a2V5ZG93biA9IGZ1bmN0aW9uKGUpIHsKICAgIHN3aXRjaCAoZS5rZXlDb2RlKSB7CiAgICBj YXNlIDc4OgogICAgICAgIGNoYW5nZV9jaHVuaygxKTsKICAgICAgICBicmVhazsKICAgIGNh c2UgODA6CiAgICAgICAgY2hhbmdlX2NodW5rKC0xKTsKICAgICAgICBicmVhazsKICAgIH0K fTsKICAgPC9zY3JpcHQ+IAo8L2hlYWQ+IAo8Ym9keSA+IAogIDx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0ciBpZD0icGFydC0xIiBi Z2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD48YSBocmVmPSIvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA2LnR4dCIgc3R5bGU9ImNvbG9yOiMw MDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmx0OzwvYT4mbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9k ZWwtMDYudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVu Y2UtbW9kZWwtMDYudHh0PC9hPiZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1yZWZl cmVuY2UtbW9kZWwudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1hbmltYS1y ZWZlcmVuY2UtbW9kZWwudHh0PC9hPiZuYnNwOzxhIGhyZWY9Ii9yZmNkaWZmP3VybDE9ZHJh ZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwudHh0IiBzdHlsZT0iY29sb3I6IzAwODsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mZ3Q7PC9hPjwvdGg+PHRoPjwvdGg+PC90cj4gCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+QU5JTUEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE0uIEJlaHJpbmdlciwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+QU5JTUEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE0uIEJlaHJpbmdlciwgRWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5J bnRlcm5ldC1EcmFmdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0 LURyYWZ0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6 IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCLiBDYXJwZW50 ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0dXM6IElu Zm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCLiBDYXJwZW50ZXI8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MDEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczogPHNwYW4gY2xhc3M9ImRlbGV0ZSI+QXVndXN0 IDI3LCAyMDE4ICA8L3NwYW4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2LiBv ZiBBdWNrbGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5FeHBpcmVzOiA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5GZWJydWFyeSAxNiwgMjAxOTwvc3Bhbj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFVuaXYuIG9mIEF1Y2tsYW5kPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBULiBFY2tlcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBULiBFY2tlcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZ1 dHVyZXdlaSBUZWNobm9sb2dpZXMgSW5jLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZ1dHVy ZXdlaSBUZWNobm9sb2dpZXMgSW5jLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTC4gQ2lhdmFnbGlhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTC4gQ2lhdmFnbGlhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTm9raWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTm9raWE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKLiBO b2JyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKLiBOb2Jy ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFVuaXZlcnNpdHkgb2YgVmFsZSBkbyBSaW8gZG9zIFNpbm9zPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFVuaXZlcnNpdHkgb2YgVmFsZSBkbyBSaW8gZG9zIFNpbm9zPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAyIj48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5GZWJydWFyeSAyMzwvc3Bhbj4s IDIwMTg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgQXVndXN0IDE1PC9zcGFuPiwgMjAxODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICBBIFJlZmVyZW5jZSBNb2RlbCBm b3IgQXV0b25vbWljIE5ldHdvcmtpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgICBBIFJlZmVyZW5jZSBNb2RlbCBmb3IgQXV0b25vbWljIE5ldHdv cmtpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i ZGlmZjAwMDMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1h bmltYS1yZWZlcmVuY2UtbW9kZWwtMDxzcGFuIGNsYXNzPSJkZWxldGUiPjY8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgIGRyYWZ0 LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0cmFj dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGEgcmVmZXJlbmNlIG1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZy48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IHJlZmVyZW5jZSBtb2RlbCBmb3IgQXV0b25vbWljIE5ldHdvcmtpbmcuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJdCBkZWZpbmVzIHRoZSBiZWhhdmlvdXIgb2YgYW4g YXV0b25vbWljIG5vZGUsIGhvdyB0aGUgdmFyaW91czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIEl0IGRlZmluZXMgdGhlIGJlaGF2aW91ciBvZiBhbiBhdXRvbm9taWMg bm9kZSwgaG93IHRoZSB2YXJpb3VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBlbGVtZW50cyBpbiBhbiBhdXRvbm9taWMgY29udGV4dCB3b3JrIHRvZ2V0aGVyLCBhbmQg aG93IGF1dG9ub21pYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGVsZW1l bnRzIGluIGFuIGF1dG9ub21pYyBjb250ZXh0IHdvcmsgdG9nZXRoZXIsIGFuZCBob3cgYXV0 b25vbWljPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZXJ2aWNlcyBjYW4g dXNlIHRoZSBpbmZyYXN0cnVjdHVyZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBzZXJ2aWNlcyBjYW4gdXNlIHRoZSBpbmZyYXN0cnVjdHVyZS48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlN0YXR1cyBvZiBUaGlzIE1lbW88L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3Vi bWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5k IEJDUCA3OS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQg RW5naW5lZXJpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGFzayBGb3JjZSAoSUVU RikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUg dGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz LiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNCI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBEcmFm dHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgRHJhZnRzIGlzIGF0IGh0dHA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPjovL2RhdGF0cmFja2VyLmlldGYub3JnL2Ry YWZ0cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIg dGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsg aW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50 ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+QXVndXN0 IDI3LCAyMDE4PC9zcGFuPi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5GZWJydWFyeSAxNiwgMjAxOTwvc3Bhbj4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIENvcHlyaWdodCAoYykgMjAxOCBJRVRGIFRydXN0IGFuZCB0 aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAxOCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29u cyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVz ZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50 IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElF VEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlz aW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNiI+PHRkPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAo aHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhl IGRhdGUgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgKGh0dHA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5zPC9zcGFuPjovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3 IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3Vt ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FyZWZ1bGx5LCBhcyB0 aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5 IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0byB0aGlzIGRvY3VtZW50LiAgQ29k ZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENv bXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2Ug dGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2Y8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQg d2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVzY3JpYmVk IGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+VGFibGUgb2YgQ29u dGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5UYWJsZSBvZiBDb250ZW50 czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxLiAgSW50 cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxLiAgSW50cm9k dWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxs PnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVtPiBw YWdlIDIsIGxpbmUgMzk8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwv YT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVtPiBwYWdlIDIsIGxpbmUgMzk8c3BhbiBjbGFzcz0i aGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNC43 LiAgSW5mb3JtYXRpb24gRGlzdHJpYnV0aW9uICgqKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNC43LiAg SW5mb3JtYXRpb24gRGlzdHJpYnV0aW9uICgqKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNS4gIFNlY3VyaXR5 IGFuZCBUcnVzdCBJbmZyYXN0cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNS4gIFNlY3VyaXR5IGFu ZCBUcnVzdCBJbmZyYXN0cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDUuMS4gIFB1YmxpYyBLZXkg SW5mcmFzdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDUuMS4gIFB1YmxpYyBLZXkgSW5m cmFzdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNS4yLiAgRG9tYWluIENlcnRpZmljYXRl ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNS4yLiAgRG9tYWluIENlcnRpZmljYXRlICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA1LjMuICBUaGUgTUFTQSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICA1LjMuICBUaGUgTUFTQSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgIDUuNC4gIFN1Yi1Eb21haW5zICgqKSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgIDUuNC4gIFN1Yi1Eb21haW5zICgqKSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgNS41LiAgQ3Jvc3MtRG9tYWluIEZ1bmN0aW9uYWxpdHkgKCopICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgNS41LiAgQ3Jvc3MtRG9tYWluIEZ1bmN0aW9uYWxpdHkgKCopICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg Ni4gIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cyAoQVNBKSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNi4g IEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cyAoQVNBKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDE1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDYuMS4g IEdlbmVyYWwgRGVzY3JpcHRpb24gb2YgYW4gQVNBIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDYuMS4gIEdl bmVyYWwgRGVzY3JpcHRpb24gb2YgYW4gQVNBIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNi4yLiAgQVNBIExp ZmUtQ3ljbGUgTWFuYWdlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx NzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNi4yLiAgQVNBIExpZmUt Q3ljbGUgTWFuYWdlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAw NyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDYuMy4gIFNwZWNpZmljIEFTQXMgZm9yIHRoZSBBdXRv bm9taWMgTmV0d29yayBJbmZyYXN0cnVjdHVyZSAgLiAgMTxzcGFuIGNsYXNzPSJkZWxldGUi Pjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgNi4zLiAg U3BlY2lmaWMgQVNBcyBmb3IgdGhlIEF1dG9ub21pYyBOZXR3b3JrIEluZnJhc3RydWN0dXJl ICAuICAxPHNwYW4gY2xhc3M9Imluc2VydCI+ODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICA2LjMuMS4gIFRoZSBlbnJvbGxtZW50IEFTQXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICA2LjMuMS4gIFRoZSBlbnJvbGxtZW50IEFTQXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgIDYuMy4yLiAgVGhlIEFDUCBBU0EgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgIDYuMy4yLiAgVGhlIEFDUCBBU0EgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9ImRpZmYwMDA4Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICA2LjMuMy4g IFRoZSBJbmZvcm1hdGlvbiBEaXN0cmlidXRpb24gQVNBICgqKSAgLiAuIC4gLiAuIC4gLiAu ICAxPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgICAgIDYuMy4zLiAgVGhlIEluZm9ybWF0aW9uIERpc3RyaWJ1dGlv biBBU0EgKCopICAuIC4gLiAuIC4gLiAuIC4gIDE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij45PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNy4gIE1hbmFnZW1lbnQg YW5kIFByb2dyYW1tYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNy4gIE1hbmFnZW1lbnQgYW5k IFByb2dyYW1tYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDcuMS4gIE1hbmFnaW5nIGEgKFBh cnRpYWxseSkgQXV0b25vbWljIE5ldHdvcmsgIC4gLiAuIC4gLiAuIC4gLiAgMTk8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDcuMS4gIE1hbmFnaW5nIGEgKFBhcnRp YWxseSkgQXV0b25vbWljIE5ldHdvcmsgIC4gLiAuIC4gLiAuIC4gLiAgMTk8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDkiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICA3LjIuICBJbnRlbnQgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjE5PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDcuMi4gIEludGVudCAo KikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNw YW4gY2xhc3M9Imluc2VydCI+MjA8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgIDcuMy4gIEFnZ3JlZ2F0ZWQgUmVwb3J0aW5nICgqKSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMjA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgIDcuMy4gIEFnZ3JlZ2F0ZWQgUmVwb3J0aW5nICgqKSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgNy40LiAgRmVlZGJhY2sgTG9vcHMgdG8gTk9DKCopICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAyMTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg Ny40LiAgRmVlZGJhY2sgTG9vcHMgdG8gTk9DKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAyMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjUu ICBDb250cm9sIExvb3BzICgqKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDIxPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjUuICBD b250cm9sIExvb3BzICgqKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDIxPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDcuNi4gIEFQSXMg KCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MjI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDcuNi4gIEFQSXMgKCop ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjI8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MTAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgICA3LjcuICBEYXRhIE1vZGVsICgqKSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI8c3BhbiBjbGFzcz0iZGVsZXRl Ij4yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDcuNy4g IERhdGEgTW9kZWwgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMjxzcGFuIGNsYXNzPSJpbnNlcnQiPjM8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICA4LiAgQ29vcmRpbmF0aW9uIEJldHdlZW4gQXV0b25vbWljIEZ1 bmN0aW9ucyAoKikgIC4gLiAuIC4gLiAuIC4gLiAgMjM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICA4LiAgQ29vcmRpbmF0aW9uIEJldHdlZW4gQXV0b25vbWljIEZ1bmN0 aW9ucyAoKikgIC4gLiAuIC4gLiAuIC4gLiAgMjM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgOC4xLiAgVGhlIENvb3JkaW5hdGlvbiBQcm9ibGVtICgqKSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgOC4xLiAgVGhlIENvb3JkaW5hdGlvbiBQcm9ibGVtICgqKSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAyMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDguMi4gIEEg Q29vcmRpbmF0aW9uIEZ1bmN0aW9uYWwgQmxvY2sgKCopIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgICAgOC4yLiAgQSBDb29yZGluYXRpb24gRnVuY3Rpb25hbCBCbG9j ayAoKikgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyPHNwYW4gY2xhc3M9Imluc2VydCI+NTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDkuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAy NTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDkuICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA5LjEuICBQcm90ZWN0aW9uIEFn YWluc3QgT3V0c2lkZXIgQXR0YWNrcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA5LjEuICBQcm90ZWN0aW9uIEFnYWlu c3QgT3V0c2lkZXIgQXR0YWNrcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDkuMi4gIFJpc2sgb2YgSW5zaWRlciBBdHRh Y2tzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjY8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDkuMi4gIFJpc2sgb2YgSW5zaWRlciBBdHRhY2tz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjY8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgMTEuIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgMTEuIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAxMi4gQ29udHJpYnV0b3JzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAxMi4gQ29udHJpYnV0b3JzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMjc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMTMuIFJlZmVyZW5jZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxz cGFuIGNsYXNzPSJkZWxldGUiPjI3PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAxMy4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+Mjg8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgMTMuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3Bh biBjbGFzcz0iZGVsZXRlIj4yNzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAxMy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjI4PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAxMy4yLiAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI4PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAxMy4yLiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI4PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjk8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGRvY3VtZW50ICJBdXRvbm9taWMg TmV0d29ya2luZyAtIERlZmluaXRpb25zIGFuZCBEZXNpZ24gR29hbHMiPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGRvY3VtZW50ICJBdXRvbm9taWMgTmV0d29y a2luZyAtIERlZmluaXRpb25zIGFuZCBEZXNpZ24gR29hbHMiPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBbUkZDNzU3NV0gZXhwbGFpbnMgdGhlIGZ1bmRhbWVudGFsIGNv bmNlcHRzIGJlaGluZCBBdXRvbm9taWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBbUkZDNzU3NV0gZXhwbGFpbnMgdGhlIGZ1bmRhbWVudGFsIGNvbmNlcHRzIGJlaGlu ZCBBdXRvbm9taWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5ldHdvcmtp bmcsIGFuZCBkZWZpbmVzIHRoZSByZWxldmFudCB0ZXJtcyBpbiB0aGlzIHNwYWNlLCBhcyB3 ZWxsIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTmV0d29ya2luZywg YW5kIGRlZmluZXMgdGhlIHJlbGV2YW50IHRlcm1zIGluIHRoaXMgc3BhY2UsIGFzIHdlbGwg YXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGEgaGlnaCBsZXZlbCByZWZl cmVuY2UgbW9kZWwuICBbUkZDNzU3Nl0gcHJvdmlkZXMgYSBnYXAgYW5hbHlzaXM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhIGhpZ2ggbGV2ZWwgcmVmZXJlbmNlIG1v ZGVsLiAgW1JGQzc1NzZdIHByb3ZpZGVzIGEgZ2FwIGFuYWx5c2lzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZXR3ZWVuIHRyYWRpdGlvbmFsIGFuZCBhdXRvbm9taWMg YXBwcm9hY2hlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBiZXR3ZWVu IHRyYWRpdGlvbmFsIGFuZCBhdXRvbm9taWMgYXBwcm9hY2hlcy48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTMiIGNs YXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMyI+PGVtPiBwYWdlIDUsIGxpbmUgMzk8c3BhbiBj bGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+ PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMyI+ PGVtPiBwYWdlIDUsIGxpbmUgMzk8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48 L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgfCBTZXJ2aWNlICAgfCAgICAgICAgfCBT ZXJ2aWNlICAgIHwgICAgICAgIHwgU2VydmljZSAgICB8ICB8PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgfCB8IFNlcnZpY2UgICB8ICAgICAgICB8IFNlcnZpY2UgICAg fCAgICAgICAgfCBTZXJ2aWNlICAgIHwgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHwgfCBBZ2VudCAxICAgfCAgICAgICAgfCBBZ2VudCAyICAgIHwgICAgICAgIHwg QWdlbnQgMyAgICB8ICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCB8 IEFnZW50IDEgICB8ICAgICAgICB8IEFnZW50IDIgICAgfCAgICAgICAgfCBBZ2VudCAzICAg IHwgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgKy0tLS0tLS0tLS0t KyAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgICstLS0tLS0tLS0tLS0rICB8PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCArLS0tLS0tLS0tLS0rICAgICAgICAr LS0tLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0tLSsgIHw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgXiAgICAgICAgICAgICAgICAgICAgXiAgICAg ICAgICAgICAgICAgICAgIF4gICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgfCAgICAgICBeICAgICAgICAgICAgICAgICAgICBeICAgICAgICAgICAgICAg ICAgICAgXiAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwg LSAgLSAgfCAtICAtIEFQSSBsZXZlbCAtICAtfCAtICAtICAtICAtICAtICAtICAtIHwtICAt ICAtICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAtICAtICB8IC0g IC0gQVBJIGxldmVsIC0gIC18IC0gIC0gIC0gIC0gIC0gIC0gIC0gfC0gIC0gIC0gIHw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgICAgViAgICAgICAgICAgICAg ICAgICAgViAgICAgICAgICAgICAgICAgICAgIFYgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAgICBWICAgICAgICAgICAgICAgICAgICBWICAg ICAgICAgICAgICAgICAgICAgViAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS18PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLXw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgQXV0b25vbWlj IE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgICAgICAgICAgICAgICAgICAgICAgICB8PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCBBdXRvbm9taWMgTmV0d29ya2lu ZyBJbmZyYXN0cnVjdHVyZSAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHwgICAgLSBEYXRhIHN0cnVjdHVyZXMgKGV4OiBjZXJ0 aWZpY2F0ZXMsIHBlZXIgaW5mb3JtYXRpb24pICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgfCAgICAtIERhdGEgc3RydWN0dXJlcyAoZXg6IGNlcnRpZmljYXRlcywg cGVlciBpbmZvcm1hdGlvbikgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHwgICAgLSBHZW5lcmFsaXplZCBBdXRvbm9taWMgQ29udHJvbCBQbGFuZSAoR0FDUCkgICAg ICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgfCAgICAtIEdl bmVyYWxpemVkIEF1dG9ub21pYyBDb250cm9sIFBsYW5lIChHQUNQKSAgICAgICAgICAgIHw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MTMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgfCAgICAtIEF1dG9ub21pYyBOb2RlIEFkZHJlc3Npbmcg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgIDwvc3Bhbj4gICAgICAgICAgICAgICAg ICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHwgICAgLSBBdXRvbm9t aWMgTm9kZSBBZGRyZXNzaW5nIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmFuZCBuYW1pbmc8L3Nw YW4+ICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgfCAgICAtIERpc2NvdmVyeSwgbmVnb3RpYXRpb24gYW5kIHN5bmNocm9uaXNhdGlvbiBm dW5jdGlvbnMgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgIC0g RGlzY292ZXJ5LCBuZWdvdGlhdGlvbiBhbmQgc3luY2hyb25pc2F0aW9uIGZ1bmN0aW9ucyAg fDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAtIERpc3RyaWJ1dGlv biBvZiBJbnRlbnQgYW5kIG90aGVyIGluZm9ybWF0aW9uICAgICAgICAgIHw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgIC0gRGlzdHJpYnV0aW9uIG9mIEludGVu dCBhbmQgb3RoZXIgaW5mb3JtYXRpb24gICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgfCAgICAtIEFnZ3JlZ2F0ZWQgcmVwb3J0aW5nIGFuZCBmZWVkYmFj ayBsb29wcyAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB8ICAgIC0gQWdncmVnYXRlZCByZXBvcnRpbmcgYW5kIGZlZWRiYWNrIGxvb3BzICAg ICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfCAgICAt IFJvdXRpbmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAgIC0gUm91dGluZyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgfCAgICAgICAgICAgICBCYXNpYyBPcGVyYXRpbmcgU3lzdGVtIEZ1bmN0aW9ucyAg ICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB8ICAg ICAgICAgICAgIEJhc2ljIE9wZXJhdGluZyBTeXN0ZW0gRnVuY3Rpb25zICAgICAgICAgICAg ICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgRmlndXJlIDI6 IE1vZGVsIG9mIGFuIGF1dG9ub21pYyBub2RlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBNb2RlbCBvZiBhbiBhdXRvbm9t aWMgbm9kZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU aGUgQXV0b25vbWljIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgKGxvd2VyIHBhcnQgb2Yg RmlndXJlIDIpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIEF1dG9u b21pYyBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIChsb3dlciBwYXJ0IG9mIEZpZ3VyZSAy KTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udGFpbnMgbm9kZSBzcGVj aWZpYyBkYXRhIHN0cnVjdHVyZXMsIGZvciBleGFtcGxlIHRydXN0IGluZm9ybWF0aW9uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29udGFpbnMgbm9kZSBzcGVjaWZp YyBkYXRhIHN0cnVjdHVyZXMsIGZvciBleGFtcGxlIHRydXN0IGluZm9ybWF0aW9uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhYm91dCBpdHNlbGYgYW5kIGl0cyBwZWVy cywgYXMgd2VsbCBhcyBhIGdlbmVyaWMgc2V0IG9mIGZ1bmN0aW9ucyw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhYm91dCBpdHNlbGYgYW5kIGl0cyBwZWVycywgYXMg d2VsbCBhcyBhIGdlbmVyaWMgc2V0IG9mIGZ1bmN0aW9ucyw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGluZGVwZW5kZW50IG9mIGEgcGFydGljdWxhciB1c2FnZS4gIFRo aXMgaW5mcmFzdHJ1Y3R1cmUgc2hvdWxkIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgaW5kZXBlbmRlbnQgb2YgYSBwYXJ0aWN1bGFyIHVzYWdlLiAgVGhpcyBpbmZy YXN0cnVjdHVyZSBzaG91bGQgYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGdlbmVyaWMsIGFuZCBzdXBwb3J0IGEgdmFyaWV0eSBvZiBBdXRvbm9taWMgU2VydmljZSBB Z2VudHMgKHVwcGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZ2VuZXJp YywgYW5kIHN1cHBvcnQgYSB2YXJpZXR5IG9mIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cyAo dXBwZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i ZGlmZjAwMTQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcGFydCBvZiBGaWd1cmUgMikuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHBhcnQgb2YgRmlndXJlIDIpLiAgPHNwYW4g Y2xhc3M9Imluc2VydCI+SXQgY29udGFpbnMgYWRkcmVzc2luZyBhbmQgbmFtaW5nIG9mIGF1 dG9ub21pYzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG5v ZGVzLCBkaXNjb3ZlcnksIG5lZ290aWF0aW9uIGFuZCBzeW5jaHJvbmlzYXRpb24gZnVuY3Rp b25zLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGRpc3Ry aWJ1dGlvbiBvZiBpbmZvcm1hdGlvbiwgcmVwb3J0aW5nIGFuZCBmZWVkYmFjayBsb29wcywg YXMgd2VsbCBhczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IHJvdXRpbmcgaW5zaWRlIHRoZSBBdXRvbm9taWMgQ29udHJvbCBQbGFuZS48L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBHZW5lcmFs aXplZCBBdXRvbm9taWMgQ29udHJvbCBQbGFuZSAoR0FDUCkgaXMgdGhlIHN1bW1hcnkgb2Yg YWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIEdlbmVyYWxpemVk IEF1dG9ub21pYyBDb250cm9sIFBsYW5lIChHQUNQKSBpcyB0aGUgc3VtbWFyeSBvZiBhbGw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGludGVyYWN0aW9ucyBvZiB0aGUg QXV0b25vbWljIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgd2l0aCBvdGhlcjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGludGVyYWN0aW9ucyBvZiB0aGUgQXV0b25v bWljIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgd2l0aCBvdGhlcjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm9kZXMgYW5kIHNlcnZpY2VzLiAgQSBzcGVjaWZpYyBp bXBsZW1lbnRhdGlvbiBvZiB0aGUgR0FDUCBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG5vZGVzIGFuZCBzZXJ2aWNlcy4gIEEgc3BlY2lmaWMgaW1wbGVtZW50YXRp b24gb2YgdGhlIEdBQ1AgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJl ZmVycmVkIHRvIGhlcmUgYXMgdGhlIEF1dG9ub21pYyBDb250cm9sIFBsYW5lIChBQ1ApLCBh bmQgZGVzY3JpYmVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVmZXJy ZWQgdG8gaGVyZSBhcyB0aGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUgKEFDUCksIGFuZCBk ZXNjcmliZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluIFtJLUQuaWV0 Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZV0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgaW4gW0ktRC5pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBs YW5lXS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IHVzZSBjYXNlcyBvZiAiQXV0b25vbWljcyIgc3VjaCBhcyBzZWxmLW1hbmFnZW1lbnQsIHNl bGYtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHVzZSBjYXNlcyBv ZiAiQXV0b25vbWljcyIgc3VjaCBhcyBzZWxmLW1hbmFnZW1lbnQsIHNlbGYtPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcHRpbWlzYXRpb24sIGV0YywgYXJlIGltcGxl bWVudGVkIGFzIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cy4gIFRoZXk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvcHRpbWlzYXRpb24sIGV0YywgYXJlIGltcGxlbWVu dGVkIGFzIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cy4gIFRoZXk8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHVzZSB0aGUgc2VydmljZXMgYW5kIGRhdGEgc3RydWN0dXJl cyBvZiB0aGUgdW5kZXJseWluZyBBdXRvbm9taWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB1c2UgdGhlIHNlcnZpY2VzIGFuZCBkYXRhIHN0cnVjdHVyZXMgb2YgdGhl IHVuZGVybHlpbmcgQXV0b25vbWljPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC00IiBjbGFzcz0iY2hhbmdlIiA+PHRk PjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9 IiNwYXJ0LTQiPjxlbT4gcGFnZSA2LCBsaW5lIDQ1PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFy YTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0 byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTQiPjxlbT4gcGFnZSA2LCBsaW5l IDQ4PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBBTkkgYWRqYWNlbmN5IHRhYmxlIGNvbnRhaW5z IGluZm9ybWF0aW9uIGFib3V0IGFkamFjZW50IGF1dG9ub21pYzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBBTkkgYWRqYWNlbmN5IHRhYmxlIGNvbnRhaW5zIGlu Zm9ybWF0aW9uIGFib3V0IGFkamFjZW50IGF1dG9ub21pYzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbm9kZXMsIGF0IGEgbWluaW11bTogbm9kZS1JRCwgSVAgYWRkcmVz cyBpbiBkYXRhIHBsYW5lLCBJUCBhZGRyZXNzIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgbm9kZXMsIGF0IGEgbWluaW11bTogbm9kZS1JRCwgSVAgYWRkcmVzcyBp biBkYXRhIHBsYW5lLCBJUCBhZGRyZXNzIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBBQ1AsIGRvbWFpbiwgY2VydGlmaWNhdGUuICBBbiBhdXRvbm9taWMgbm9kZSBt YWludGFpbnMgdGhpcyBhZGphY2VuY3k8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBBQ1AsIGRvbWFpbiwgY2VydGlmaWNhdGUuICBBbiBhdXRvbm9taWMgbm9kZSBtYWlu dGFpbnMgdGhpcyBhZGphY2VuY3k8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHRhYmxlIHVwIHRvIGRhdGUuICBUaGUgYWRqYWNlbmN5IHRhYmxlIG9ubHkgY29udGFpbnMg aW5mb3JtYXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0YWJsZSB1 cCB0byBkYXRlLiAgVGhlIGFkamFjZW5jeSB0YWJsZSBvbmx5IGNvbnRhaW5zIGluZm9ybWF0 aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhYm91dCBvdGhlciBub2Rl cyB0aGF0IGFyZSBjYXBhYmxlIG9mIEF1dG9ub21pYyBOZXR3b3JraW5nOyBub24tPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWJvdXQgb3RoZXIgbm9kZXMgdGhhdCBh cmUgY2FwYWJsZSBvZiBBdXRvbm9taWMgTmV0d29ya2luZzsgbm9uLTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXV0b25vbWljIG5vZGVzIGFyZSBub3JtYWxseSBub3Qg dHJhY2tlZCBoZXJlLiAgSG93ZXZlciwgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgYXV0b25vbWljIG5vZGVzIGFyZSBub3JtYWxseSBub3QgdHJhY2tlZCBoZXJl LiAgSG93ZXZlciwgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmZv cm1hdGlvbiBpcyB0cmFja2VkIGluZGVwZW5kZW50bHkgb2YgdGhlIHN0YXR1cyBvZiB0aGUg cGVlciBub2Rlczs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmZvcm1h dGlvbiBpcyB0cmFja2VkIGluZGVwZW5kZW50bHkgb2YgdGhlIHN0YXR1cyBvZiB0aGUgcGVl ciBub2Rlczs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpZmljYWxs eSwgaXQgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgbm9uLWVucm9sbGVkIG5vZGVzLCBu b2RlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNwZWNpZmljYWxseSwg aXQgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgbm9uLWVucm9sbGVkIG5vZGVzLCBub2Rl czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIHNhbWUgYW5kIG90 aGVyIGRvbWFpbnMuICBUaGUgYWRqYWNlbmN5IHRhYmxlIG1heSBjb250YWluPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgdGhlIHNhbWUgYW5kIG90aGVyIGRvbWFp bnMuICBUaGUgYWRqYWNlbmN5IHRhYmxlIG1heSBjb250YWluPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE1Ij48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSB2YWxpZGl0eSBhbmQgdHJ1c3Qgb2YgdGhlIGFk amFjZW50IGF1dG9ub21pYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBp bmZvcm1hdGlvbiBhYm91dCB0aGUgdmFsaWRpdHkgYW5kIHRydXN0IDxzcGFuIGNsYXNzPSJp bnNlcnQiPmxldmVsPC9zcGFuPiBvZiB0aGUgYWRqYWNlbnQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bm9kZSdzIGNlcnRpZmlj YXRlLCBhbHRob3VnaCBhbGwgYXV0b25vbWljIGludGVyYWN0aW9ucyBtdXN0IHZlcmlmeTwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYXV0b25vbWljIDxz cGFuIGNsYXNzPSJpbnNlcnQiPm5vZGVzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgdmFsaWRpdHkgYW5kIHRydXN0 IGluZGVwZW5kZW50bHkuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGFk amFjZW5jeSB0YWJsZSBpcyBmZWQgYnkgdGhlIGZvbGxvd2luZyBpbnB1dHM6PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGFkamFjZW5jeSB0YWJsZSBpcyBmZWQg YnkgdGhlIGZvbGxvd2luZyBpbnB1dHM6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG8gIExpbmsgbG9jYWwgZGlzY292ZXJ5OiBUaGlzIGludGVyYWN0 aW9uIGhhcHBlbnMgaW4gdGhlIGRhdGEgcGxhbmUsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgbyAgTGluayBsb2NhbCBkaXNjb3Zlcnk6IFRoaXMgaW50ZXJhY3Rpb24g aGFwcGVucyBpbiB0aGUgZGF0YSBwbGFuZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgIHVzaW5nIElQdjYgbGluayBsb2NhbCBhZGRyZXNzaW5nIG9ubHksIGJlY2F1 c2UgdGhpcyBhZGRyZXNzaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgdXNpbmcgSVB2NiBsaW5rIGxvY2FsIGFkZHJlc3Npbmcgb25seSwgYmVjYXVzZSB0aGlz IGFkZHJlc3Npbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHR5cGUg aXMgaXRzZWxmIGF1dG9ub21pYy4gIFRoaXMgd2F5IHRoZSBub2RlcyBsZWFybnMgYWJvdXQg YWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdHlwZSBpcyBpdHNl bGYgYXV0b25vbWljLiAgVGhpcyB3YXkgdGhlIG5vZGVzIGxlYXJucyBhYm91dCBhbGw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGF1dG9ub21pYyBub2RlcyBhcm91 bmQgaXRzZWxmLiAgVGhlIHJlbGF0ZWQgc3RhbmRhcmRzIHRyYWNrPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYXV0b25vbWljIG5vZGVzIGFyb3VuZCBpdHNlbGYu ICBUaGUgcmVsYXRlZCBzdGFuZGFyZHMgdHJhY2s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgIGRvY3VtZW50cyAoW0ktRC5pZXRmLWFuaW1hLWdyYXNwXSw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBkb2N1bWVudHMgKFtJLUQuaWV0Zi1h bmltYS1ncmFzcF0sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBbSS1E LmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV0sPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5 aW5mcmFdLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgW0ktRC5pZXRm LWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lXSkgZGVzY3JpYmUgaW4gZGV0YWlsIGhv dzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFtJLUQuaWV0Zi1hbmlt YS1hdXRvbm9taWMtY29udHJvbC1wbGFuZV0pIGRlc2NyaWJlIGluIGRldGFpbCBob3c8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGxpbmsgbG9jYWwgZGlzY292ZXJ5 IGlzIHVzZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgbGluayBs b2NhbCBkaXNjb3ZlcnkgaXMgdXNlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbyAgVmVuZG9yIHJlLWRpcmVjdDogQSBuZXcgZGV2aWNlIG1heSBy ZWNlaXZlIGluZm9ybWF0aW9uIG9uIHdoZXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgbyAgVmVuZG9yIHJlLWRpcmVjdDogQSBuZXcgZGV2aWNlIG1heSByZWNlaXZl IGluZm9ybWF0aW9uIG9uIHdoZXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBpdHMgaG9tZSBuZXR3b3JrIGlzIHRocm91Z2ggYSB2ZW5kb3IgYmFzZWQgTUFTQSBy ZS1kaXJlY3Q7IHRoaXMgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBpdHMgaG9tZSBuZXR3b3JrIGlzIHRocm91Z2ggYSB2ZW5kb3IgYmFzZWQgTUFTQSByZS1k aXJlY3Q7IHRoaXMgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0iZGlmZjAwMTYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgdHlwaWNhbGx5IGEgcm91 dGFibGUgYWRkcmVzcy4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPlNlZTwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgdHlwaWNhbGx5IGEgcm91dGFibGUg YWRkcmVzcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmFd Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIE5vbi1hdXRvbm9taWMgaW5w dXQ6IEEgbm9kZSBtYXkgYmUgY29uZmlndXJlZCBtYW51YWxseSB3aXRoIGFuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgTm9uLWF1dG9ub21pYyBpbnB1dDogQSBu b2RlIG1heSBiZSBjb25maWd1cmVkIG1hbnVhbGx5IHdpdGggYW48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgIGF1dG9ub21pYyBwZWVyOyBpdCBjb3VsZCBsZWFybiBh Ym91dCBhdXRvbm9taWMgbm9kZXMgdGhyb3VnaCBESENQPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgYXV0b25vbWljIHBlZXI7IGl0IGNvdWxkIGxlYXJuIGFib3V0 IGF1dG9ub21pYyBub2RlcyB0aHJvdWdoIERIQ1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgIG9wdGlvbnMsIEROUywgYW5kIG90aGVyIG5vbi1hdXRvbm9taWMgbWVj aGFuaXNtcy4gIEdlbmVyYWxseSBzdWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgb3B0aW9ucywgRE5TLCBhbmQgb3RoZXIgbm9uLWF1dG9ub21pYyBtZWNoYW5p c21zLiAgR2VuZXJhbGx5IHN1Y2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIG5vbi1hdXRvbm9taWMgbWVjaGFuc2ltcyByZXF1aXJlIHNvbWUgYWRtaW5pc3RyYXRv ciBpbnRlcnZlbnRpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg bm9uLWF1dG9ub21pYyBtZWNoYW5zaW1zIHJlcXVpcmUgc29tZSBhZG1pbmlzdHJhdG9yIGlu dGVydmVudGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFRoZSBr ZXkgcHVycG9zZSBpcyB0byBieS1wYXNzIGEgbm9uLWF1dG9ub21pYyBkZXZpY2Ugb3IgbmV0 d29yay48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBUaGUga2V5IHB1 cnBvc2UgaXMgdG8gYnktcGFzcyBhIG5vbi1hdXRvbm9taWMgZGV2aWNlIG9yIG5ldHdvcmsu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBBcyB0aGlzIHBlcnRhaW5z IHRvIG5ldyBkZXZpY2VzLCBpdCBpcyBjb3ZlcmVkIGluIGFwcGVuZGl4IEEgYW5kIEI8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBBcyB0aGlzIHBlcnRhaW5zIHRv IG5ldyBkZXZpY2VzLCBpdCBpcyBjb3ZlcmVkIGluIGFwcGVuZGl4IEEgYW5kIEI8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIG9mIFtJLUQuaWV0Zi1hbmltYS1ib290 c3RyYXBwaW5nLWtleWluZnJhXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICBvZiBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV0uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBhZGphY2VuY3kg dGFibGUgaXMgZGVmaW5pbmcgdGhlIGJlaGF2aW91ciBvZiBhbiBhdXRvbm9taWMgbm9kZTo8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgYWRqYWNlbmN5IHRhYmxl IGlzIGRlZmluaW5nIHRoZSBiZWhhdmlvdXIgb2YgYW4gYXV0b25vbWljIG5vZGU6PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i cGFydC01IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0 byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTUiPjxlbT4gcGFnZSA3LCBsaW5l IDQ5PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+ IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9 IiNwYXJ0LTUiPjxlbT4gcGFnZSA3LCBsaW5lIDQ4PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFy YTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBDb250cm9sIFBsYW5l IChBQ1ApLiAgU2VlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgQ29u dHJvbCBQbGFuZSAoQUNQKS4gIFNlZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgW0ktRC5pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lXS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBbSS1ELmlldGYtYW5pbWEtYXV0b25v bWljLWNvbnRyb2wtcGxhbmVdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvICBPbmNlIHRoZSBub2RlIGlzIHBhcnQgb2YgdGhlIEFDUCBvZiBhIGRv bWFpbiwgaXQgd2lsbCB1c2UgR1JBU1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBvICBPbmNlIHRoZSBub2RlIGlzIHBhcnQgb2YgdGhlIEFDUCBvZiBhIGRvbWFpbiwg aXQgd2lsbCB1c2UgR1JBU1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IFtJLUQuaWV0Zi1hbmltYS1ncmFzcF0gdG8gZmluZCBSZWdpc3RyYXIocykgb2YgaXRzIGRv bWFpbiBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBbSS1ELmll dGYtYW5pbWEtZ3Jhc3BdIHRvIGZpbmQgUmVnaXN0cmFyKHMpIG9mIGl0cyBkb21haW4gYW5k PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBwb3RlbnRpYWxseSBvdGhl ciBzZXJ2aWNlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBwb3Rl bnRpYWxseSBvdGhlciBzZXJ2aWNlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbyAgSWYgdGhlIG5vZGUgaXMgcGFydCBvZiBhbiBBQ1AgYW5kIGhh cyBkaXNjb3ZlcmVkIHZpYSBHUkFTUCBhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIG8gIElmIHRoZSBub2RlIGlzIHBhcnQgb2YgYW4gQUNQIGFuZCBoYXMgZGlzY292 ZXJlZCB2aWEgR1JBU1AgYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IGxlYXN0IG9uZSBSZWdpc3RyYXIgaW4gaXRzIGRvbWFpbiwgaXQgd2lsbCBzdGFydCB0aGUg ImpvaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBsZWFzdCBvbmUg UmVnaXN0cmFyIGluIGl0cyBkb21haW4sIGl0IHdpbGwgc3RhcnQgdGhlICJqb2luPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBhc3Npc3RhbnQiIEFTQSwgYW5kIGFj dCBhcyBhIGpvaW4gYXNzaXN0YW50IGZvciBuZWlnaGJvcmluZyBub2RlczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGFzc2lzdGFudCIgQVNBLCBhbmQgYWN0IGFz IGEgam9pbiBhc3Npc3RhbnQgZm9yIG5laWdoYm9yaW5nIG5vZGVzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE3Ij48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgIHRoYXQgbmVlZCB0byBiZSBib290c3RyYXBwZWQuICBTZWU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgdGhhdCBuZWVkIHRvIGJlIGJvb3RzdHJh cHBlZC4gIFNlZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TZWN0aW9uIDYuMy4xLjIgZm9yIGRl dGFpbHMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5bSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlp bmZyYV0uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgT3RoZXIgYmVoYXZp b3VycyBhcmUgcG9zc2libGUsIGZvciBleGFtcGxlIGVzdGFibGlzaGluZyB0aGUgQUNQPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgT3RoZXIgYmVoYXZpb3VycyBh cmUgcG9zc2libGUsIGZvciBleGFtcGxlIGVzdGFibGlzaGluZyB0aGUgQUNQPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBhbHNvIHdpdGggZGV2aWNlcyBvZiBhIHN1 Yi1kb21haW4sIHRvIG90aGVyIGRvbWFpbnMsIGV0Yy4gIFRob3NlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYWxzbyB3aXRoIGRldmljZXMgb2YgYSBzdWItZG9t YWluLCB0byBvdGhlciBkb21haW5zLCBldGMuICBUaG9zZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgd2lsbCBsaWtlbHkgYmUgY29udHJvbGxlZCBieSBJbnRlbnQu ICBUaGV5IGFyZSBvdXRzaWRlIHNjb3BlIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgIHdpbGwgbGlrZWx5IGJlIGNvbnRyb2xsZWQgYnkgSW50ZW50LiAgVGhl eSBhcmUgb3V0c2lkZSBzY29wZSBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIHRoZSBtb21lbnQuICBOb3RlIHRoYXQgSW50ZW50IGlzIGRpc3RyaWJ1dGVkIHRo cm91Z2ggdGhlIEFDUDs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0 aGUgbW9tZW50LiAgTm90ZSB0aGF0IEludGVudCBpcyBkaXN0cmlidXRlZCB0aHJvdWdoIHRo ZSBBQ1A7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0aGVyZWZvcmUs IGEgbm9kZSBjYW4gb25seSBhZGFwdCBJbnRlbnQgZHJpdmVuIGJlaGF2aW91ciBvbmNlIGl0 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdGhlcmVmb3JlLCBhIG5v ZGUgY2FuIG9ubHkgYWRhcHQgSW50ZW50IGRyaXZlbiBiZWhhdmlvdXIgb25jZSBpdDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgaGFzIGpvaW5lZCB0aGUgQUNQLiAg QXQgdGhlIG1vbWVudCwgQU5JTUEgZG9lcyBub3QgY29uc2lkZXI8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBoYXMgam9pbmVkIHRoZSBBQ1AuICBBdCB0aGUgbW9t ZW50LCBBTklNQSBkb2VzIG5vdCBjb25zaWRlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgcHJvdmlkaW5nIEludGVudCBvdXRzaWRlIHRoZSBBQ1A7IHRoaXMgY2Fu IGJlIGNvbnNpZGVyZWQgbGF0ZXIuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgcHJvdmlkaW5nIEludGVudCBvdXRzaWRlIHRoZSBBQ1A7IHRoaXMgY2FuIGJlIGNv bnNpZGVyZWQgbGF0ZXIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIE9uY2UgYSBub2RlIGhhcyBqb2luZWQgdGhlIEFDUCwgaXQgd2lsbCBhbHNvIGxl YXJuIHRoZSBBQ1AgYWRkcmVzc2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgT25jZSBhIG5vZGUgaGFzIGpvaW5lZCB0aGUgQUNQLCBpdCB3aWxsIGFsc28gbGVhcm4g dGhlIEFDUCBhZGRyZXNzZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTYiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90 ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3Bh cnQtNiI+PGVtPiBwYWdlIDgsIGxpbmUgMzU8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNiI+PGVtPiBwYWdlIDgsIGxpbmUgMzE8 c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHByb3ZpZGVzIGF1dG9ub21pYyBpbnRlcmFjdGlvbnMgd2l0aGluIGEgZG9tYWlu LCBhdXRvbm9taWMgZnVuY3Rpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgcHJvdmlkZXMgYXV0b25vbWljIGludGVyYWN0aW9ucyB3aXRoaW4gYSBkb21haW4sIGF1 dG9ub21pYyBmdW5jdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNh biBhbHNvIHVzZSBhbnkgb3RoZXIgY29udGV4dCBvbiBhIG5vZGUsIHNwZWNpZmljYWxseSB0 aGUgZ2xvYmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FuIGFsc28g dXNlIGFueSBvdGhlciBjb250ZXh0IG9uIGEgbm9kZSwgc3BlY2lmaWNhbGx5IHRoZSBnbG9i YWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRhdGEgcGxhbmUuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGF0YSBwbGFuZS48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+My4zLiAgU3RhdGUgTWFjaGluZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuMy4gIFN0YXRlIE1hY2hpbmU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQXV0b25vbWljIE5ldHdv cmtpbmcgYXBwbGllcyBkdXJpbmcgdGhlIGZ1bGwgbGlmZS1jeWNsZSBvZiBhIG5vZGUuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXV0b25vbWljIE5ldHdvcmtpbmcg YXBwbGllcyBkdXJpbmcgdGhlIGZ1bGwgbGlmZS1jeWNsZSBvZiBhIG5vZGUuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGEgc3Rh dGUgbWFjaGluZSBvZiBhbiBhdXRvbm9taWMgbm9kZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGEgc3RhdGUgbWFjaGluZSBv ZiBhbiBhdXRvbm9taWMgbm9kZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHRocm91Z2hvdXQgaXRzIGxpZmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgdGhyb3VnaG91dCBpdHMgbGlmZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxOCI+PHRkPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+QSBkZXZpY2UgaXMgbm9ybWFsbHkgZXhwZWN0ZWQgdG8gc3RvcmUgaXRzIGRvbWFpbiBz cGVjaWZpYyBpZGVudGl0eSw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICB0aGUgTERldklEIChzZWUgU2VjdGlvbiA1LjIpLCBpbiBwZXJzaXN0ZW50IHN0 b3JhZ2UsIHRvIGJlIGF2YWlsYWJsZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIGFmdGVyIGEgcG93ZXJjeWNsZSBldmVudC4gIEZvciBkZXZpY2UgdHlw ZXMgdGhhdCBjYW5ub3Qgc3RvcmUgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgTERldklEIGluIHBlcnNpc3RlbnQgc3RvcmFnZSwgYSBwb3dlcmN5 Y2xlIGV2ZW50IGlzIGVmZmVjdGl2ZWx5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgZXF1aXZhbGVudCB0byBhIGZhY3RvcnkgcmVzZXQuPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+My4zLjEuICBTdGF0ZSAxOiBGYWN0b3J5IERlZmF1bHQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLjMuMS4gIFN0YXRlIDE6IEZhY3RvcnkgRGVmYXVsdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBbiBhdXRvbm9t aWMgbm9kZSBpcyBsZWF2aW5nIHRoZSBmYWN0b3J5IGluIHRoaXMgc3RhdGUuICBJbiB0aGlz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQW4gYXV0b25vbWljIG5vZGUg aXMgbGVhdmluZyB0aGUgZmFjdG9yeSBpbiB0aGlzIHN0YXRlLiAgSW4gdGhpczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3RhdGUsIHRoZSBub2RlIGhhcyBubyBkb21h aW4gc3BlY2lmaWMgY29uZmlndXJhdGlvbiwgc3BlY2lmaWNhbGx5IG5vPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3RhdGUsIHRoZSBub2RlIGhhcyBubyBkb21haW4g c3BlY2lmaWMgY29uZmlndXJhdGlvbiwgc3BlY2lmaWNhbGx5IG5vPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBMRGV2SUQsIGFuZCBjb3VsZCBiZSB1c2VkIGluIGFueSBw YXJ0aWN1bGFyIHRhcmdldCBuZXR3b3JrLiAgSXQgZG9lczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIExEZXZJRCwgYW5kIGNvdWxkIGJlIHVzZWQgaW4gYW55IHBhcnRp Y3VsYXIgdGFyZ2V0IG5ldHdvcmsuICBJdCBkb2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBob3dldmVyIGhhdmUgYSB2ZW5kb3IvbWFudWZhY3R1cmVyIHNwZWNpZmlj IElELCB0aGUgSURldklEIFtJRGV2SURdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGhvd2V2ZXIgaGF2ZSBhIHZlbmRvci9tYW51ZmFjdHVyZXIgc3BlY2lmaWMgSUQs IHRoZSBJRGV2SUQgW0lEZXZJRF0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBOb2RlcyB3aXRob3V0IElEZXZJRCBjYW5ub3QgYmUgYXV0b25vbWljYWxseSBhbmQgc2Vj dXJlbHkgZW5yb2xsZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBOb2Rl cyB3aXRob3V0IElEZXZJRCBjYW5ub3QgYmUgYXV0b25vbWljYWxseSBhbmQgc2VjdXJlbHkg ZW5yb2xsZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGludG8gYSBkb21h aW47IHRoZXkgcmVxdWlyZSBtYW51YWwgcHJlLXN0YWdpbmcsIGluIHdoaWNoIGNhc2UgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW50byBhIGRvbWFpbjsgdGhl eSByZXF1aXJlIG1hbnVhbCBwcmUtc3RhZ2luZywgaW4gd2hpY2ggY2FzZSB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByZS1zdGFnaW5nIHRha2VzIHRoZW0gZGly ZWN0bHkgdG8gc3RhdGUgMi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBw cmUtc3RhZ2luZyB0YWtlcyB0aGVtIGRpcmVjdGx5IHRvIHN0YXRlIDIuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJwYXJ0LTciIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBw aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNyI+PGVtPiBwYWdlIDgs IGxpbmUgNTA8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3Ro Pjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEg aHJlZj0iI3BhcnQtNyI+PGVtPiBwYWdlIDksIGxpbmUgNDxzcGFuIGNsYXNzPSJoaWRlIj4g JnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaG93ZXZlciBoYXZl IGEgdmVuZG9yL21hbnVmYWN0dXJlciBzcGVjaWZpYyBJRCwgdGhlIElEZXZJRCBbSURldklE XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBob3dldmVyIGhhdmUgYSB2 ZW5kb3IvbWFudWZhY3R1cmVyIHNwZWNpZmljIElELCB0aGUgSURldklEIFtJRGV2SURdLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTm9kZXMgd2l0aG91dCBJRGV2SUQg Y2Fubm90IGJlIGF1dG9ub21pY2FsbHkgYW5kIHNlY3VyZWx5IGVucm9sbGVkPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTm9kZXMgd2l0aG91dCBJRGV2SUQgY2Fubm90 IGJlIGF1dG9ub21pY2FsbHkgYW5kIHNlY3VyZWx5IGVucm9sbGVkPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbnRvIGEgZG9tYWluOyB0aGV5IHJlcXVpcmUgbWFudWFs IHByZS1zdGFnaW5nLCBpbiB3aGljaCBjYXNlIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGludG8gYSBkb21haW47IHRoZXkgcmVxdWlyZSBtYW51YWwgcHJlLXN0 YWdpbmcsIGluIHdoaWNoIGNhc2UgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBwcmUtc3RhZ2luZyB0YWtlcyB0aGVtIGRpcmVjdGx5IHRvIHN0YXRlIDIuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJlLXN0YWdpbmcgdGFrZXMgdGhlbSBk aXJlY3RseSB0byBzdGF0ZSAyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUcmFuc2l0aW9uczo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBUcmFuc2l0aW9uczo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgbyAgQm9vdHN0cmFwIGV2ZW50OiBUaGUgZGV2aWNlIGVucm9scyBpbnRvIGEg ZG9tYWluOyBhcyBwYXJ0IG9mIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBvICBCb290c3RyYXAgZXZlbnQ6IFRoZSBkZXZpY2UgZW5yb2xzIGludG8gYSBkb21h aW47IGFzIHBhcnQgb2YgdGhpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgcHJvY2VzcyBpdCByZWNlaXZlcyBhIGRvbWFpbiBpZGVudGl0eSAoTERldklEKS4gIElm IGVucm9sbG1lbnQgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBw cm9jZXNzIGl0IHJlY2VpdmVzIGEgZG9tYWluIGlkZW50aXR5IChMRGV2SUQpLiAgSWYgZW5y b2xsbWVudCBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgc3VjY2Vz c2Z1bCwgdGhlIG5leHQgc3RhdGUgaXMgc3RhdGUgMi4gIFNlZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIHN1Y2Nlc3NmdWwsIHRoZSBuZXh0IHN0YXRlIGlzIHN0 YXRlIDIuICBTZWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwMTkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBbSS1ELmlldGYtYW5p bWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV0gU2VjdGlvbiAzIGZvciBkZXRhaWxzIG9uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJv b3RzdHJhcHBpbmcta2V5aW5mcmFdIFNlY3Rpb24gMyBmb3IgZGV0YWlscyBvbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZW5yb2xsbWVudC48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBlbnJvbGxtZW50LjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBQb3dlcmN5Y2xlIGV2ZW50OiBUaGUg ZGV2aWNlIGxvc2VzIGFsbCBzdGF0ZSB0YWJsZXMuICBJdCByZW1haW5zPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgUG93ZXJjeWNsZSBldmVudDogVGhlIGRldmlj ZSBsb3NlcyBhbGwgc3RhdGUgdGFibGVzLiAgSXQgcmVtYWluczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgaW4gc3RhdGU6IDEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgaW4gc3RhdGU6IDEuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjMuMy4yLiAgU3RhdGUgMjogRW5yb2xsZWQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLjMuMi4gIFN0YXRlIDI6IEVucm9sbGVkPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFuIGF1dG9ub21pYyBu b2RlIGlzIGluIHRoZSBzdGF0ZSAiZW5yb2xsZWQiIGlmIGl0IGhhcyBhIGRvbWFpbjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFuIGF1dG9ub21pYyBub2RlIGlzIGlu IHRoZSBzdGF0ZSAiZW5yb2xsZWQiIGlmIGl0IGhhcyBhIGRvbWFpbjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMCI+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBpZGVudGl0eSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4oTERldklEKS48L3NwYW4+ ICBJdCBtYXkgaGF2ZSBmdXJ0aGVyIGNvbmZpZ3VyYXRpb24gb3Igc3RhdGUsIGZvcjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpZGVudGl0eSA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij4oTERldklEKSwgYW5kIGhhcyBjdXJyZW50bHkgbm8gQUNQIGNoYW5uZWwgdXAu PC9zcGFuPiAgSXQgbWF5IGhhdmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgZXhhbXBsZSBpZiBpdCBoYWQgYmVlbiBpbiBzdGF0ZSAzIGJlZm9yZSwgYnV0IGxvc3Qg YWxsIGl0cyBBQ1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZnVydGhl ciBjb25maWd1cmF0aW9uIG9yIHN0YXRlLCBmb3IgZXhhbXBsZSBpZiBpdCBoYWQgYmVlbiBp biBzdGF0ZSAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGNoYW5uZWxz LiAgVGhlIExEZXZJRCBjYW4gb25seSBiZSByZW1vdmVkIGZyb20gYSBkZXZpY2UgdGhyb3Vn aCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGJlZm9yZSwgYnV0IGxv c3QgYWxsIGl0cyBBQ1AgY2hhbm5lbHMuICBUaGUgTERldklEIGNhbiBvbmx5IGJlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGZhY3RvcnkgcmVzZXQsIHdoaWNoIGFs c28gcmVtb3ZlcyBhbGwgb3RoZXIgc3RhdGUgZnJvbSB0aGUgZGV2aWNlLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICByZW1vdmVkIGZyb20gYSBkZXZpY2UgdGhyb3Vn aCBhIGZhY3RvcnkgcmVzZXQsIHdoaWNoIGFsc28gcmVtb3ZlcyBhbGw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBlbnN1cmVzIHRoYXQgYSBkZXZpY2UgaGFz IG5vIHN0YWxlIGRvbWFpbiBzcGVjaWZpYyBzdGF0ZSB3aGVuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIG90aGVyIHN0YXRlIGZyb20gdGhlIGRldmljZS4gIFRoaXMg ZW5zdXJlcyB0aGF0IGEgZGV2aWNlIGhhcyBubyBzdGFsZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBlbnRlcmluZyB0aGUgImVucm9sbGVkIiBzdGF0ZSBmcm9tIHN0 YXRlIDEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGRvbWFpbiBzcGVj aWZpYyBzdGF0ZSB3aGVuIGVudGVyaW5nIHRoZSAiZW5yb2xsZWQiIHN0YXRlIGZyb20gc3Rh dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIDEuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFRyYW5zaXRpb25zOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRyYW5zaXRpb25zOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvICBKb2luaW5nIEFDUDogVGhlIGRldmljZSBlc3RhYmxpc2hlcyBhbiBB Q1AgY2hhbm5lbCB0byBhbiBhZGphY2VudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIG8gIEpvaW5pbmcgQUNQOiBUaGUgZGV2aWNlIGVzdGFibGlzaGVzIGFuIEFDUCBj aGFubmVsIHRvIGFuIGFkamFjZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBkZXZpY2UuICBTZWUgW0ktRC5pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBs YW5lXSBmb3IgZGV0YWlscy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBkZXZpY2UuICBTZWUgW0ktRC5pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5l XSBmb3IgZGV0YWlscy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE5l eHQgc3RhdGU6IDMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgTmV4 dCBzdGF0ZTogMy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgbyAgRmFjdG9yeSByZXNldDogQSBmYWN0b3J5IHJlc2V0IHJlbW92ZXMgYWxsIGNvbmZp Z3VyYXRpb24gYW5kIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8g IEZhY3RvcnkgcmVzZXQ6IEEgZmFjdG9yeSByZXNldCByZW1vdmVzIGFsbCBjb25maWd1cmF0 aW9uIGFuZCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGRvbWFp biBpZGVudGl0eSAoTERldklEKSBmcm9tIHRoZSBkZXZpY2UuICBOZXh0IHN0YXRlOiAxLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGRvbWFpbiBpZGVudGl0eSAo TERldklEKSBmcm9tIHRoZSBkZXZpY2UuICBOZXh0IHN0YXRlOiAxLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0icGFydC04IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTgiPjxlbT4gcGFnZSAxNCwg bGluZSA5PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48 dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhy ZWY9IiNwYXJ0LTgiPjxlbT4gcGFnZSAxNCwgbGluZSA5PHNwYW4gY2xhc3M9ImhpZGUiPiAm cGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkaXN0cmlidXRpb24g bWV0aG9kcy4gIEludGVudCBpcyBhbHNvIGV4cGVjdGVkIHRvIGJlIG1vbm9saXRoaWMsIGFu ZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRpc3RyaWJ1dGlvbiBtZXRo b2RzLiAgSW50ZW50IGlzIGFsc28gZXhwZWN0ZWQgdG8gYmUgbW9ub2xpdGhpYywgYW5kPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmbG9vZGVkIGFzIGEgd2hvbGUuICBP bmUgcG9zc2libGUgbWV0aG9kIGZvciBkaXN0cmlidXRpbmcgSW50ZW50LCBhczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZsb29kZWQgYXMgYSB3aG9sZS4gIE9uZSBw b3NzaWJsZSBtZXRob2QgZm9yIGRpc3RyaWJ1dGluZyBJbnRlbnQsIGFzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3ZWxsIGFzIG90aGVyIGZvcm1zIG9mIGRhdGEsIGlz IGRpc2N1c3NlZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdlbGwg YXMgb3RoZXIgZm9ybXMgb2YgZGF0YSwgaXMgZGlzY3Vzc2VkIGluPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb25d LiAgSW50ZW50IGFuZCBpbmZvcm1hdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl0uICBJbnRlbnQgYW5k IGluZm9ybWF0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkaXN0cmli dXRpb24gYXJlIG5vdCBwYXJ0IG9mIHBoYXNlIDEgb2YgQU5JTUEuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgZGlzdHJpYnV0aW9uIGFyZSBub3QgcGFydCBvZiBwaGFz ZSAxIG9mIEFOSU1BLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij41LiAgU2VjdXJpdHkgYW5kIFRydXN0IEluZnJhc3RydWN0dXJlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+NS4gIFNlY3VyaXR5IGFuZCBUcnVzdCBJbmZyYXN0cnVjdHVy ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBbiBBdXRv bm9taWMgTmV0d29yayBpcyBzZWxmLXByb3RlY3RpbmcuICBBbGwgcHJvdG9jb2xzIGFyZSBz ZWN1cmUgYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBbiBBdXRvbm9t aWMgTmV0d29yayBpcyBzZWxmLXByb3RlY3RpbmcuICBBbGwgcHJvdG9jb2xzIGFyZSBzZWN1 cmUgYnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlZmF1bHQsIHdpdGhv dXQgdGhlIHJlcXVpcmVtZW50IGZvciB0aGUgYWRtaW5pc3RyYXRvciB0byBleHBsaWNpdGx5 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVmYXVsdCwgd2l0aG91dCB0 aGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGV4cGxpY2l0bHk8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjEi Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgY29uZmlndXJlIDxzcGFuIGNsYXNzPSJkZWxldGUiPnNlY3Vy aXR5Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgY29uZmln dXJlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnNlY3VyaXR5LCB3aXRoIHRoZSBleGNlcHRpb24g b2Ygc2V0dGluZyB1cCBhIFBLSTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIGluZnJhc3RydWN0dXJlLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQXV0b25vbWljIG5vZGVzIGhhdmUgZGlyZWN0IGlu dGVyYWN0aW9ucyBiZXR3ZWVuIHRoZW1zZWx2ZXMsIHdoaWNoPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgQXV0b25vbWljIG5vZGVzIGhhdmUgZGlyZWN0IGludGVyYWN0 aW9ucyBiZXR3ZWVuIHRoZW1zZWx2ZXMsIHdoaWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBtdXN0IGJlIHNlY3VyZWQuICBTaW5jZSBhbiBhdXRvbm9taWMgbmV0d29y ayBkb2VzIG5vdCByZWx5IG9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg bXVzdCBiZSBzZWN1cmVkLiAgU2luY2UgYW4gYXV0b25vbWljIG5ldHdvcmsgZG9lcyBub3Qg cmVseSBvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29uZmlndXJhdGlv biwgaXQgaXMgbm90IGFuIG9wdGlvbiB0byBjb25maWd1cmUgZm9yIGV4YW1wbGUgcHJlLTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbmZpZ3VyYXRpb24sIGl0IGlz IG5vdCBhbiBvcHRpb24gdG8gY29uZmlndXJlIGZvciBleGFtcGxlIHByZS08L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNoYXJlZCBrZXlzLiAgQSB0cnVzdCBpbmZyYXN0 cnVjdHVyZSBzdWNoIGFzIGEgUEtJIGluZnJhc3RydWN0dXJlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgc2hhcmVkIGtleXMuICBBIHRydXN0IGluZnJhc3RydWN0dXJl IHN1Y2ggYXMgYSBQS0kgaW5mcmFzdHJ1Y3R1cmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG11c3QgYmUgaW4gcGxhY2UuICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRo ZSBwcmluY2lwbGVzIG9mIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBtdXN0IGJlIGluIHBsYWNlLiAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcHJpbmNp cGxlcyBvZiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cnVzdCBp bmZyYXN0cnVjdHVyZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0cnVz dCBpbmZyYXN0cnVjdHVyZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgVGhlIGRlZmF1bHQgbWV0aG9kIHRvIGF1dG9tYXRpY2FsbHkgYnJpbmcgdXAg YSB0cnVzdCBpbmZyYXN0cnVjdHVyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoZSBkZWZhdWx0IG1ldGhvZCB0byBhdXRvbWF0aWNhbGx5IGJyaW5nIHVwIGEgdHJ1 c3QgaW5mcmFzdHJ1Y3R1cmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlz IGRlZmluZWQgaW4gdGhlIGRvY3VtZW50ICJCb290c3RyYXBwaW5nIEtleSBJbmZyYXN0cnVj dHVyZXMiPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaXMgZGVmaW5lZCBp biB0aGUgZG9jdW1lbnQgIkJvb3RzdHJhcHBpbmcgS2V5IEluZnJhc3RydWN0dXJlcyI8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJwYXJ0LTkiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5n IHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtOSI+PGVtPiBwYWdlIDE2LCBs aW5lIDk8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJl Zj0iI3BhcnQtOSI+PGVtPiBwYWdlIDE2LCBsaW5lIDEyPHNwYW4gY2xhc3M9ImhpZGUiPiAm cGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8g IFNpbXBsZSBBU0FzIHdpdGggYSBzbWFsbCBmb290cHJpbnQgdGhhdCBjb3VsZCBydW4gYW55 d2hlcmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgU2ltcGxlIEFT QXMgd2l0aCBhIHNtYWxsIGZvb3RwcmludCB0aGF0IGNvdWxkIHJ1biBhbnl3aGVyZS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgQ29tcGxleCwg cG9zc2libHkgbXVsdGktdGhyZWFkZWQgQVNBcyB0aGF0IGhhdmUgYSBzaWduaWZpY2FudDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIENvbXBsZXgsIHBvc3NpYmx5 IG11bHRpLXRocmVhZGVkIEFTQXMgdGhhdCBoYXZlIGEgc2lnbmlmaWNhbnQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHJlc291cmNlIHJlcXVpcmVtZW50IGFuZCB3 aWxsIG9ubHkgcnVuIG9uIHNlbGVjdGVkIG5vZGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIHJlc291cmNlIHJlcXVpcmVtZW50IGFuZCB3aWxsIG9ubHkgcnVu IG9uIHNlbGVjdGVkIG5vZGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvICBBIGZldyAnaW5mcmFzdHJ1Y3R1cmUgQVNBcycgdGhhdCB1c2UgYmFz aWMgQU5JIGZlYXR1cmVzIGluIHN1cHBvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBvICBBIGZldyAnaW5mcmFzdHJ1Y3R1cmUgQVNBcycgdGhhdCB1c2UgYmFzaWMg QU5JIGZlYXR1cmVzIGluIHN1cHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIG9mIHRoZSBBTkkgaXRzZWxmLCB3aGljaCBtdXN0IHJ1biBpbiBhbGwgYXV0b25v bWljIG5vZGVzLiAgVGhlc2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBvZiB0aGUgQU5JIGl0c2VsZiwgd2hpY2ggbXVzdCBydW4gaW4gYWxsIGF1dG9ub21pYyBu b2Rlcy4gIFRoZXNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBhcmUg b3V0bGluZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICBhcmUgb3V0bGluZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0 aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAyMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBdXRvbm9taWMgbm9kZXMs IGFuZCB0aGVyZWZvcmUgdGhlaXIgQVNBcywgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+d2lsbCBi ZSBzZWxmLWF3YXJlLiAgRXZlcnk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIEF1dG9ub21pYyBub2RlcywgYW5kIHRoZXJlZm9yZSB0aGVpciBBU0FzLCA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5rbm93IHRoZWlyPC9zcGFuPiBvd248L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgYXV0b25vbWlj IG5vZGUgd2lsbCBiZSBsb2FkZWQgd2l0aCB2YXJpb3VzIGZ1bmN0aW9ucyBhbmQgQVNBcyBh bmQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNs YXNzPSJpbnNlcnQiPmNhcGFiaWxpdGllcyBhbmQgcmVzdHJpY3Rpb25zLCBkZXJpdmVkIGZy b208L3NwYW4+IGhhcmR3YXJlLCBmaXJtd2FyZSBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICB3aWxsIGJlIGF3YXJlIG9mIGl0 czwvc3Bhbj4gb3duIDxzcGFuIGNsYXNzPSJkZWxldGUiPmNhcGFiaWxpdGllcywgdHlwaWNh bGx5IGRlY2lkZWQgYnkgdGhlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBwcmUtaW5zdGFsbGVkIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnNvZnR3YXJlOiBU aGV5IGFyZSAic2VsZi1hd2FyZSIuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBoYXJkd2FyZSwgZmlybXdhcmUgb3IgcHJlLWluc3RhbGxlZCA8c3BhbiBj bGFzcz0iZGVsZXRlIj5zb2Z0d2FyZS4gIEl0cyBleGFjdDwvc3Bhbj4gcm9sZSA8c3BhbiBj bGFzcz0iZGVsZXRlIj5tYXk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgZGVwZW5kPC9zcGFuPiBvbiBJ bnRlbnQgYW5kIG9uIHRoZSBzdXJyb3VuZGluZyBuZXR3b3JrIGJlaGF2aW9ycywgd2hpY2gg bWF5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIFRoZTwvc3Bhbj4gcm9sZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5vZiBhbiBhdXRv bm9taWMgbm9kZSBkZXBlbmRzPC9zcGFuPiBvbiBJbnRlbnQgYW5kIG9uIHRoZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpbmNsdWRlIGZvcndhcmRpbmcgYmVoYXZp b3JzLCBhZ2dyZWdhdGlvbiBwcm9wZXJ0aWVzLCB0b3BvbG9neTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBzdXJyb3VuZGluZyBuZXR3b3JrIGJlaGF2aW9ycywgd2hp Y2ggbWF5IGluY2x1ZGUgZm9yd2FyZGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBsb2NhdGlvbiwgYmFuZHdpZHRoLCB0dW5uZWwgb3IgdHJhbnNsYXRpb24gcHJv cGVydGllcywgZXRjLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+VGhlPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBiZWhhdmlvcnMsIGFnZ3JlZ2F0aW9uIHBy b3BlcnRpZXMsIHRvcG9sb2d5IGxvY2F0aW9uLCBiYW5kd2lkdGgsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHN1cnJvdW5kaW5n IHRvcG9sb2d5IHdpbGwgZGVwZW5kIG9uIHRoZSBuZXR3b3JrIHBsYW5uaW5nLjwvc3Bhbj4g IEZvbGxvd2luZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0dW5uZWwg b3IgdHJhbnNsYXRpb24gcHJvcGVydGllcywgZXRjLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+ Rm9yIGV4YW1wbGUsIGEgbm9kZSBtYXk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIGFuIGluaXRpYWwgZGlzY292ZXJ5IHBoYXNlLCB0aGUgZGV2aWNlIHBy b3BlcnRpZXMgYW5kIHRob3NlIG9mIGl0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBkZWNpZGUgdG8gYWN0IGFzIGEgYmFja3Vw IG5vZGUgZm9yIGEgbmVpZ2hib3IsIGlmIGl0cyBjYXBhYmlsaXRpZXM8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG5laWdoYm9ycyBhcmUgdGhlIGZvdW5k YXRpb24gb2YgdGhlIGJlaGF2aW9yIG9mIGEgc3BlY2lmaWMgZGV2aWNlLiAgQTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhbGxv dyBpdCB0byBkbyBzby48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIGRldmljZSBhbmQgaXRzIEFTQXMgaGF2ZSBubyBwcmUtY29uZmlndXJhdGlvbiBmb3Ig dGhlIHBhcnRpY3VsYXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBuZXR3 b3JrIGluIHdoaWNoIHRoZXkgYXJlIGluc3RhbGxlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgRm9sbG93aW5nIGFuIGluaXRpYWwgZGlzY292ZXJ5IHBoYXNlLCB0 aGUgZGV2aWNlIHByb3BlcnRpZXMgYW5kIHRob3NlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBvZiBpdHMg bmVpZ2hib3JzIGFyZSB0aGUgZm91bmRhdGlvbiBvZiB0aGUgYmVoYXZpb3Igb2YgYSBzcGVj aWZpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgZGV2aWNlLiAgQSBkZXZpY2UgYW5kIGl0cyBBU0FzIGhh dmUgbm8gcHJlLWNvbmZpZ3VyYXRpb24gZm9yIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcGFydGlj dWxhciBuZXR3b3JrIGluIHdoaWNoIHRoZXkgYXJlIGluc3RhbGxlZC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2luY2UgYWxsIEFTQXMgd2lsbCBp bnRlcmFjdCB3aXRoIHRoZSBBTkksIHRoZXkgd2lsbCBkZXBlbmQgb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTaW5jZSBhbGwgQVNBcyB3aWxsIGludGVyYWN0IHdp dGggdGhlIEFOSSwgdGhleSB3aWxsIGRlcGVuZCBvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYXBwcm9wcmlhdGUgYXBwbGljYXRpb24gcHJvZ3JhbW1pbmcgaW50ZXJm YWNlcyAoQVBJcykuICBJdCBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGFwcHJvcHJpYXRlIGFwcGxpY2F0aW9uIHByb2dyYW1taW5nIGludGVyZmFjZXMgKEFQSXMp LiAgSXQgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlc2lyYWJsZSB0 aGF0IEFTQXMgYXJlIHBvcnRhYmxlIGJldHdlZW4gb3BlcmF0aW5nIHN5c3RlbXMsIHNvIHRo ZXNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzaXJhYmxlIHRoYXQg QVNBcyBhcmUgcG9ydGFibGUgYmV0d2VlbiBvcGVyYXRpbmcgc3lzdGVtcywgc28gdGhlc2U8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFQSXMgbmVlZCB0byBiZSB1bml2 ZXJzYWwuICBBbiBBUEkgZm9yIEdSQVNQIGlzIGRlc2NyaWJlZCBpbjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFQSXMgbmVlZCB0byBiZSB1bml2ZXJzYWwuICBBbiBB UEkgZm9yIEdSQVNQIGlzIGRlc2NyaWJlZCBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgW0ktRC5pZXRmLWFuaW1hLWdyYXNwLWFwaV0uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWFuaW1hLWdyYXNwLWFwaV0uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFTQXMgd2lsbCBpbiBnZW5l cmFsIGJlIGRlc2lnbmVkIGFuZCBjb2RlZCBieSBleHBlcnRzIGluIGEgcGFydGljdWxhcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFTQXMgd2lsbCBpbiBnZW5lcmFs IGJlIGRlc2lnbmVkIGFuZCBjb2RlZCBieSBleHBlcnRzIGluIGEgcGFydGljdWxhcjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGVjaG5vbG9neSBhbmQgdXNlIGNhc2Us IG5vdCBieSBleHBlcnRzIGluIHRoZSBBTkkgYW5kIGl0czwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHRlY2hub2xvZ3kgYW5kIHVzZSBjYXNlLCBub3QgYnkgZXhwZXJ0 cyBpbiB0aGUgQU5JIGFuZCBpdHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGNvbXBvbmVudHMuICBBbHNvLCB0aGV5IG1heSBiZSBjb2RlZCBpbiBhIHZhcmlldHkgb2Yg cHJvZ3JhbW1pbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb21wb25l bnRzLiAgQWxzbywgdGhleSBtYXkgYmUgY29kZWQgaW4gYSB2YXJpZXR5IG9mIHByb2dyYW1t aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0icGFydC0xMCIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0xMCI+PGVtPiBw YWdlIDE3LCBsaW5lIDE1PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48 L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxhIGhyZWY9IiNwYXJ0LTEwIj48ZW0+IHBhZ2UgMTcsIGxpbmUgMjE8c3BhbiBjbGFz cz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFT QXMgd2lsbCBhdXRvbWF0aWNhbGx5IGJlbmVmaXQgZnJvbSB0aGUgc2VjdXJpdHkgcHJvdmlk ZWQgYnkgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQVNBcyB3aWxs IGF1dG9tYXRpY2FsbHkgYmVuZWZpdCBmcm9tIHRoZSBzZWN1cml0eSBwcm92aWRlZCBieSB0 aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFOSSwgYW5kIHNwZWNpZmlj YWxseSBieSB0aGUgQUNQIGFuZCBieSBHUkFTUC4gIEhvd2V2ZXIsIGJleW9uZCB0aGF0LDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFOSSwgYW5kIHNwZWNpZmljYWxs eSBieSB0aGUgQUNQIGFuZCBieSBHUkFTUC4gIEhvd2V2ZXIsIGJleW9uZCB0aGF0LDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhleSBhcmUgcmVzcG9uc2libGUgZm9y IHRoZWlyIG93biBzZWN1cml0eSwgZXNwZWNpYWxseSB3aGVuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdGhleSBhcmUgcmVzcG9uc2libGUgZm9yIHRoZWlyIG93biBz ZWN1cml0eSwgZXNwZWNpYWxseSB3aGVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBjb21tdW5pY2F0aW5nIHdpdGggdGhlIHNwZWNpZmljIHRhcmdldHMgb2YgdGhlaXIg ZnVuY3Rpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29tbXVuaWNh dGluZyB3aXRoIHRoZSBzcGVjaWZpYyB0YXJnZXRzIG9mIHRoZWlyIGZ1bmN0aW9uLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlcmVmb3JlLCB0aGUgZGVzaWduIG9m IGFuIEFTQSBtdXN0IGluY2x1ZGUgYSBzZWN1cml0eSBhbmFseXNpczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZXJlZm9yZSwgdGhlIGRlc2lnbiBvZiBhbiBBU0Eg bXVzdCBpbmNsdWRlIGEgc2VjdXJpdHkgYW5hbHlzaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGJleW9uZCAndXNlIEFOSSBzZWN1cml0eS4nPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgYmV5b25kICd1c2UgQU5JIHNlY3VyaXR5Lic8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4yLiAgQVNBIExpZmUtQ3lj bGUgTWFuYWdlbWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjYuMi4gIEFT QSBMaWZlLUN5Y2xlIE1hbmFnZW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgQVNBcyBvcGVyYXRpbmcgb24gYSBnaXZlbiBBTkkgbWF5IGNvbWUg ZnJvbSBkaWZmZXJlbnQgcHJvdmlkZXJzIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEFTQXMgb3BlcmF0aW5nIG9uIGEgZ2l2ZW4gQU5JIG1heSBjb21lIGZyb20g ZGlmZmVyZW50IHByb3ZpZGVycyBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcHVyc3VlIGRp ZmZlcmVudCBvYmplY3RpdmVzLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+V2hpY2hldmVyIHRo ZSBBU0EsIGl0cyBtYW5hZ2VtZW50PC9zcGFuPiBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgcHVyc3VlIGRpZmZlcmVudCBvYmplY3RpdmVzLiAgPHNwYW4gY2xh c3M9Imluc2VydCI+TWFuYWdlbWVudCBvZiBBU0FzPC9zcGFuPiBhbmQgaXRzIGludGVyYWN0 aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpdHMgaW50ZXJhY3Rp b25zIHdpdGggdGhlIEFOSSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5tdXN0PC9zcGFuPiBmb2xs b3cgdGhlIHNhbWUgb3BlcmF0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIHdpdGggdGhlIEFOSSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zaG91bGQ8L3NwYW4+IGZv bGxvdyB0aGUgc2FtZSBvcGVyYXRpbmcgcHJpbmNpcGxlcywgaGVuY2U8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcHJpbmNpcGxlcywgaGVuY2UgY29tcGx5IHRvIGEg Z2VuZXJpYyBsaWZlLWN5Y2xlIG1hbmFnZW1lbnQgbW9kZWwuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIGNvbXBseSB0byBhIGdlbmVyaWMgbGlmZS1jeWNsZSBtYW5h Z2VtZW50IG1vZGVsLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGUgQVNBIGxpZmUtY3ljbGUgcHJvdmlkZXMgc3RhbmRhcmQgcHJvY2Vzc2VzIHRv OjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBBU0EgbGlmZS1jeWNs ZSBwcm92aWRlcyBzdGFuZGFyZCBwcm9jZXNzZXMgdG86PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIGluc3RhbGwgQVNBOiBjb3B5IHRoZSBBU0Eg Y29kZSBvbnRvIHRoZSBob3N0IGFuZCBzdGFydCBpdCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBvICBpbnN0YWxsIEFTQTogY29weSB0aGUgQVNBIGNvZGUgb250byB0 aGUgaG9zdCBhbmQgc3RhcnQgaXQsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIG8gIGRlcGxveSBBU0E6IGFzc29jaWF0ZSB0aGUgQVNBIGluc3RhbmNl IHdpdGggYSAoc29tZSkgbWFuYWdlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIG8gIGRlcGxveSBBU0E6IGFzc29jaWF0ZSB0aGUgQVNBIGluc3RhbmNlIHdpdGggYSAo c29tZSkgbWFuYWdlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgbmV0 d29yayBkZXZpY2UocykgKG9yIG5ldHdvcmsgZnVuY3Rpb24pLDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIG5ldHdvcmsgZGV2aWNlKHMpIChvciBuZXR3b3JrIGZ1 bmN0aW9uKSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg byAgY29udHJvbCBBU0EgZXhlY3V0aW9uOiB3aGVuIGFuZCBob3cgYW4gQVNBIGV4ZWN1dGVz IGl0cyBjb250cm9sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgY29u dHJvbCBBU0EgZXhlY3V0aW9uOiB3aGVuIGFuZCBob3cgYW4gQVNBIGV4ZWN1dGVzIGl0cyBj b250cm9sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBsb29wLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGxvb3AuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0xMSIg Y2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0xMSI+PGVtPiBwYWdlIDE4LCBsaW5lIDIwPHNw YW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+ PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0 LTExIj48ZW0+IHBhZ2UgMTgsIGxpbmUgMzI8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwv c3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGludG8gdGhlIGRvbWFpbiB3aXRo IHRoZSBoZWxwIG9mIGFuIGpvaW4gYXNzaXRhbnQgQVNBIChzZWUgYmVsb3cpLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGludG8gdGhlIGRvbWFpbiB3aXRoIHRoZSBo ZWxwIG9mIGFuIGpvaW4gYXNzaXRhbnQgQVNBIChzZWUgYmVsb3cpLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgU3VjaCBhIG5vZGUgaXMga25vd24gYXMgYSBQbGVkZ2Ug ZHVyaW5nIHRoZSBlbnJvbGxtZW50IHByb2Nlc3MuICBUaGlzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgU3VjaCBhIG5vZGUgaXMga25vd24gYXMgYSBQbGVkZ2UgZHVy aW5nIHRoZSBlbnJvbGxtZW50IHByb2Nlc3MuICBUaGlzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBBU0EgbXVzdCBiZSBpbnN0YWxsZWQgYnkgZGVmYXVsdCBvbiBhbGwg bm9kZXMgdGhhdCByZXF1aXJlIGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgQVNBIG11c3QgYmUgaW5zdGFsbGVkIGJ5IGRlZmF1bHQgb24gYWxsIG5vZGVzIHRoYXQg cmVxdWlyZSBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXV0b25vbWlj IHplcm8tdG91Y2ggYm9vdHN0cmFwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGF1dG9ub21pYyB6ZXJvLXRvdWNoIGJvb3RzdHJhcC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4zLjEuMi4gIFRoZSBKb2luIEFzc2lzdGFudCBB U0E8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij42LjMuMS4yLiAgVGhlIEpvaW4g QXNzaXN0YW50IEFTQTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGlzIEFTQSBpbmNsdWRlcyB0aGUgZnVuY3Rpb24gb2YgYW4gYXV0b25vbWljIG5v ZGUgdGhhdCBoZWxwcyBhIG5vbi08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUaGlzIEFTQSBpbmNsdWRlcyB0aGUgZnVuY3Rpb24gb2YgYW4gYXV0b25vbWljIG5vZGUg dGhhdCBoZWxwcyBhIG5vbi08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGVu cm9sbGVkLCBhZGphY2VudCBkZXZpY2VzIHRvIGVucm9sbCBpbnRvIHRoZSBkb21haW4uICBU aGlzIEFTQSBtdXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZW5yb2xs ZWQsIGFkamFjZW50IGRldmljZXMgdG8gZW5yb2xsIGludG8gdGhlIGRvbWFpbi4gIFRoaXMg QVNBIG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJlIGluc3RhbGxl ZCBvbiBhbGwgbm9kZXMsIGFsdGhvdWdoIG9ubHkgb25lIGpvaW4gYXNzaXN0YW50IG5lZWRz IHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmUgaW5zdGFsbGVkIG9u IGFsbCBub2RlcywgYWx0aG91Z2ggb25seSBvbmUgam9pbiBhc3Npc3RhbnQgbmVlZHMgdG88 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MjQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgYmUgYWN0aXZlIG9uIGEgZ2l2ZW4gTEFOLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBiZSBhY3RpdmUgb24gYSBnaXZlbiBMQU4u ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TZWUgYWxzbzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIFtJLUQuaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtl eWluZnJhXS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjYuMy4xLjMuICBUaGUgSm9pbiBSZWdpc3RyYXIgQVNBPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+Ni4zLjEuMy4gIFRoZSBKb2luIFJlZ2lzdHJhciBBU0E8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBBU0EgaW5jbHVk ZXMgdGhlIGpvaW4gcmVnaXN0cmFyIGZ1bmN0aW9uIGluIGFuIGF1dG9ub21pYzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgQVNBIGluY2x1ZGVzIHRoZSBqb2lu IHJlZ2lzdHJhciBmdW5jdGlvbiBpbiBhbiBhdXRvbm9taWM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG5ldHdvcmsuICBUaGlzIEFTQSBkb2VzIG5vdCBuZWVkIHRvIGJl IGluc3RhbGxlZCBvbiBhbGwgbm9kZXMsIGJ1dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG5ldHdvcmsuICBUaGlzIEFTQSBkb2VzIG5vdCBuZWVkIHRvIGJlIGluc3Rh bGxlZCBvbiBhbGwgbm9kZXMsIGJ1dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgb25seSBvbiBub2RlcyB0aGF0IGltcGxlbWVudCB0aGUgSm9pbiBSZWdpc3RyYXIgZnVu Y3Rpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb25seSBvbiBub2Rl cyB0aGF0IGltcGxlbWVudCB0aGUgSm9pbiBSZWdpc3RyYXIgZnVuY3Rpb24uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjYuMy4yLiAgVGhlIEFDUCBBU0E8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij42LjMuMi4gIFRoZSBBQ1AgQVNBPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgQVNBIGlu Y2x1ZGVzIHRoZSBBQ1AgZnVuY3Rpb24gaW4gYW4gYXV0b25vbWljIG5ldHdvcmsuICBJbjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgQVNBIGluY2x1ZGVzIHRo ZSBBQ1AgZnVuY3Rpb24gaW4gYW4gYXV0b25vbWljIG5ldHdvcmsuICBJbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQt MTIiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMTIiPjxlbT4gcGFnZSAyMCwgbGluZSA0 PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwv dGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNw YXJ0LTEyIj48ZW0+IHBhZ2UgMjAsIGxpbmUgMjA8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJh Ozwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxpbmUgaW50ZXJmYWNlcy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBsaW5lIGludGVyZmFjZXMuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjcuMi4gIEludGVudCAo Kik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij43LjIuICBJbnRlbnQgKCopPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVudCBpcyBu b3QgY292ZXJlZCBpbiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpY2F0aW9u cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlbnQgaXMgbm90IGNv dmVyZWQgaW4gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gc3BlY2lmaWNhdGlvbnMuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHNlY3Rpb24gaXMgZm9yIGlu Zm9ybWF0aW9uYWwgcHVycG9zZXMsIGZvciBmb2xsb3dpbmcgcGhhc2VzIG9mPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBzZWN0aW9uIGlzIGZvciBpbmZvcm1h dGlvbmFsIHB1cnBvc2VzLCBmb3IgZm9sbG93aW5nIHBoYXNlcyBvZjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3RhbmRhcmRpemF0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHN0YW5kYXJkaXphdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGdpdmVzIGFuIG92ZXJ2 aWV3IG9mIEludGVudCwgYW5kIGhvdyBpdCBpcyBtYW5hZ2VkLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgc2VjdGlvbiBnaXZlcyBhbiBvdmVydmlldyBvZiBJ bnRlbnQsIGFuZCBob3cgaXQgaXMgbWFuYWdlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEludGVudCBhbmQgUG9saWN5LUJhc2VkIE5ldHdvcmsgTWFuYWdlbWVudCAo UEJOTSkgaXMgYWxyZWFkeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElu dGVudCBhbmQgUG9saWN5LUJhc2VkIE5ldHdvcmsgTWFuYWdlbWVudCAoUEJOTSkgaXMgYWxy ZWFkeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAyNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBkZXNjcmliZWQgaW5zaWRlIHRoZSBJRVRGIChl LmcuLCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5QQ0lNIGFuZCBTVVBBKTwvc3Bhbj4gYW5kIGlu IG90aGVyIFNET3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZGVzY3Jp YmVkIGluc2lkZSB0aGUgSUVURiAoZS5nLiwgPHNwYW4gY2xhc3M9Imluc2VydCI+UENJTSk8 L3NwYW4+IGFuZCBpbiBvdGhlciBTRE9zIChlLmcuLCBETVRGPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIChlLmcuLCBETVRGIGFuZCBUTUYgWk9PTSkuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFuZCBUTUYgWk9PTSkuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVudCBjYW4gYmUgZGVzY3Jp YmVkIGFzIGFuIGFic3RyYWN0LCBkZWNsYXJhdGl2ZSwgaGlnaC1sZXZlbDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVudCBjYW4gYmUgZGVzY3JpYmVkIGFzIGFu IGFic3RyYWN0LCBkZWNsYXJhdGl2ZSwgaGlnaC1sZXZlbDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgcG9saWN5IHVzZWQgdG8gb3BlcmF0ZSBhbiBhdXRvbm9taWMgZG9t YWluLCBzdWNoIGFzIGFuIGVudGVycHJpc2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBwb2xpY3kgdXNlZCB0byBvcGVyYXRlIGFuIGF1dG9ub21pYyBkb21haW4sIHN1 Y2ggYXMgYW4gZW50ZXJwcmlzZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg bmV0d29yayBbUkZDNzU3NV0uICBJbnRlbnQgc2hvdWxkIGJlIGxpbWl0ZWQgdG8gaGlnaCBs ZXZlbCBndWlkYW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5ldHdv cmsgW1JGQzc1NzVdLiAgSW50ZW50IHNob3VsZCBiZSBsaW1pdGVkIHRvIGhpZ2ggbGV2ZWwg Z3VpZGFuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9ubHksIHRodXMg aXQgZG9lcyBub3QgZGlyZWN0bHkgZGVmaW5lIGEgcG9saWN5IGZvciBldmVyeSBuZXR3b3Jr PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb25seSwgdGh1cyBpdCBkb2Vz IG5vdCBkaXJlY3RseSBkZWZpbmUgYSBwb2xpY3kgZm9yIGV2ZXJ5IG5ldHdvcms8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGVsZW1lbnQgc2VwYXJhdGVseS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBlbGVtZW50IHNlcGFyYXRlbHkuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVudCBjYW4gYmUg cmVmaW5lZCB0byBsb3dlciBsZXZlbCBwb2xpY2llcyB1c2luZyBkaWZmZXJlbnQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlbnQgY2FuIGJlIHJlZmluZWQgdG8g bG93ZXIgbGV2ZWwgcG9saWNpZXMgdXNpbmcgZGlmZmVyZW50PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBhcHByb2FjaGVzLiAgVGhpcyBpcyBleHBlY3RlZCBpbiBvcmRl ciB0byBhZGFwdCB0aGUgSW50ZW50IHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGFwcHJvYWNoZXMuICBUaGlzIGlzIGV4cGVjdGVkIGluIG9yZGVyIHRvIGFk YXB0IHRoZSBJbnRlbnQgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBjYXBhYmlsaXRpZXMgb2YgbWFuYWdlZCBkZXZpY2VzLiAgSW50ZW50IG1heSBjb250YWlu IHJvbGUgb3IgZnVuY3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBj YXBhYmlsaXRpZXMgb2YgbWFuYWdlZCBkZXZpY2VzLiAgSW50ZW50IG1heSBjb250YWluIHJv bGUgb3IgZnVuY3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTEzIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+ PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0 LTEzIj48ZW0+IHBhZ2UgMjcsIGxpbmUgNDE8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMTMiPjxlbT4gcGFnZSAyOCwgbGluZSAx MjxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgU2lnbmlmaWNhbnQgY29udHJpYnV0aW9ucyB0byB0aGlzIGRvY3VtZW50IGhh dmUgYmVlbiBtYWRlIGJ5IEpvaG48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBTaWduaWZpY2FudCBjb250cmlidXRpb25zIHRvIHRoaXMgZG9jdW1lbnQgaGF2ZSBiZWVu IG1hZGUgYnkgSm9objwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU3RyYXNz bmVyIGFuZCBCaW5nIExpdSBmcm9tIEh1YXdlaSwgYW5kIFBpZXJyZSBQZWxvc28gZnJvbSBO b2tpYS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTdHJhc3NuZXIgYW5k IEJpbmcgTGl1IGZyb20gSHVhd2VpLCBhbmQgUGllcnJlIFBlbG9zbyBmcm9tIE5va2lhLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMy4gIFJlZmVyZW5j ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMy4gIFJlZmVyZW5jZXM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MTMuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MTMuMS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFtJLUQuaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZV08L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmlldGYtYW5pbWEtYXV0b25v bWljLWNvbnRyb2wtcGxhbmVdPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIEVja2VydCwgVC4sIEJlaHJpbmdlciwgTS4sIGFuZCBTLiBCamFybmFzb24s ICJBbiBBdXRvbm9taWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgIEVja2VydCwgVC4sIEJlaHJpbmdlciwgTS4sIGFuZCBTLiBCamFybmFzb24sICJB biBBdXRvbm9taWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgQ29udHJvbCBQbGFuZSAoQUNQKSIsIGRyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNv bnRyb2wtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBD b250cm9sIFBsYW5lIChBQ1ApIiwgZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJv bC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwMjYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBwbGFuZS0xPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+MyAod29yayBpbiBwcm9ncmVzcyksIERlY2VtYmVyIDIwMTc8L3NwYW4+Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIHBsYW5lLTE8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij44ICh3b3JrIGluIHByb2dyZXNzKSwgQXVndXN0IDIwMTg8 L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBb SS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV08L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlp bmZyYV08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgUHJp dGlraW4sIE0uLCBSaWNoYXJkc29uLCBNLiwgQmVocmluZ2VyLCBNLiwgQmphcm5hc29uLDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUHJpdGlraW4s IE0uLCBSaWNoYXJkc29uLCBNLiwgQmVocmluZ2VyLCBNLiwgQmphcm5hc29uLDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBTLiwgYW5kIEsuIFdhdHNl biwgIkJvb3RzdHJhcHBpbmcgUmVtb3RlIFNlY3VyZSBLZXk8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIFMuLCBhbmQgSy4gV2F0c2VuLCAiQm9vdHN0 cmFwcGluZyBSZW1vdGUgU2VjdXJlIEtleTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICBJbmZyYXN0cnVjdHVyZXMgKEJSU0tJKSIsIGRyYWZ0LWlldGYt YW5pbWEtYm9vdHN0cmFwcGluZy08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgIEluZnJhc3RydWN0dXJlcyAoQlJTS0kpIiwgZHJhZnQtaWV0Zi1hbmlt YS1ib290c3RyYXBwaW5nLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAyNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIGtleWlu ZnJhLTE8c3BhbiBjbGFzcz0iZGVsZXRlIj4xICh3b3JrIGluIHByb2dyZXNzKSwgRmVicnVh cnk8L3NwYW4+IDIwMTguPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAgICAgICAga2V5aW5mcmEtMTxzcGFuIGNsYXNzPSJpbnNlcnQiPjYgKHdvcmsgaW4gcHJv Z3Jlc3MpLCBKdW5lPC9zcGFuPiAyMDE4LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtYW5pbWEtZ3Jhc3BdPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWFuaW1hLWdyYXNwXTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBCb3JtYW5uLCBDLiwgQ2FycGVu dGVyLCBCLiwgYW5kIEIuIExpdSwgIkEgR2VuZXJpYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgQm9ybWFubiwgQy4sIENhcnBlbnRlciwgQi4sIGFu ZCBCLiBMaXUsICJBIEdlbmVyaWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgQXV0b25vbWljIFNpZ25hbGluZyBQcm90b2NvbCAoR1JBU1ApIiwgZHJh ZnQtaWV0Zi1hbmltYS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgIEF1dG9ub21pYyBTaWduYWxpbmcgUHJvdG9jb2wgKEdSQVNQKSIsIGRyYWZ0LWll dGYtYW5pbWEtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAg IGdyYXNwLTE1ICh3b3JrIGluIHByb2dyZXNzKSwgSnVseSAyMDE3LjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgZ3Jhc3AtMTUgKHdvcmsgaW4gcHJv Z3Jlc3MpLCBKdWx5IDIwMTcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjEzLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+MTMuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5jYXJwZW50ZXItYW5p bWEtYXNhLWd1aWRlbGluZXNdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg W0ktRC5jYXJwZW50ZXItYW5pbWEtYXNhLWd1aWRlbGluZXNdPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIENhcnBlbnRlciwgQi4sIENpYXZhZ2xpYSwg TC4sIEppYW5nLCBTLiwgYW5kIFAuIFBpZXJyZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgIENhcnBlbnRlciwgQi4sIENpYXZhZ2xpYSwgTC4sIEpp YW5nLCBTLiwgYW5kIFAuIFBpZXJyZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgIkd1aWRlbGluZXMgZm9yIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50 cyIsIGRyYWZ0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgIkd1aWRlbGluZXMgZm9yIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cyIsIGRyYWZ0LTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAy OCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPmNh cnBlbnRlci1hbmltYS1hc2EtZ3VpZGVsaW5lcy0wMzwvc3Bhbj4gKHdvcmsgaW4gcHJvZ3Jl c3MpLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmNhcnBlbnRlci1hbmltYS1hc2EtZ3VpZGVsaW5lcy0wNTwv c3Bhbj4gKHdvcmsgaW4gcHJvZ3Jlc3MpLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5KdW5lPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJkZWxldGUiPk9jdG9iZXIgMjAxNy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAg MjAxOC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtJLUQuZHUtYW5pbWEtYW4taW50ZW50XTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFtJLUQuZHUtYW5pbWEtYW4taW50ZW50XTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBEdSwgWi4sIEppYW5nLCBTLiwgTm9icmUsIEou LCBDaWF2YWdsaWEsIEwuLCBhbmQgTS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgIER1LCBaLiwgSmlhbmcsIFMuLCBOb2JyZSwgSi4sIENpYXZhZ2xp YSwgTC4sIGFuZCBNLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICBCZWhyaW5nZXIsICJBTklNQSBJbnRlbnQgUG9saWN5IGFuZCBGb3JtYXQiLCBkcmFm dC1kdS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEJl aHJpbmdlciwgIkFOSU1BIEludGVudCBQb2xpY3kgYW5kIEZvcm1hdCIsIGRyYWZ0LWR1LTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBhbmltYS1hbi1p bnRlbnQtMDUgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBGZWJydWFyeSAyMDE3LjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgYW5pbWEtYW4taW50ZW50LTA1 ICh3b3JrIGluIHByb2dyZXNzKSwgRmVicnVhcnkgMjAxNy48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5pZXRmLWFuaW1hLWdyYXNwLWFwaV08 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmlldGYtYW5pbWEtZ3Jh c3AtYXBpXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBD YXJwZW50ZXIsIEIuLCBMaXUsIEIuLCBXYW5nLCBXLiwgYW5kIFguIEdvbmcsICJHZW5lcmlj PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBDYXJwZW50 ZXIsIEIuLCBMaXUsIEIuLCBXYW5nLCBXLiwgYW5kIFguIEdvbmcsICJHZW5lcmljPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIEF1dG9ub21pYyBTaWdu YWxpbmcgUHJvdG9jb2wgQXBwbGljYXRpb24gUHJvZ3JhbSBJbnRlcmZhY2U8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEF1dG9ub21pYyBTaWduYWxp bmcgUHJvdG9jb2wgQXBwbGljYXRpb24gUHJvZ3JhbSBJbnRlcmZhY2U8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjkiPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAgICAoR1JBU1AgQVBJKSIsIDxzcGFuIGNsYXNzPSJkZWxldGUi PmRyYWZ0LWlldGYtYW5pbWEtZ3Jhc3AtYXBpLTAwPC9zcGFuPiAod29yayBpbjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIChHUkFTUCBBUEkpIiwg PHNwYW4gY2xhc3M9Imluc2VydCI+ZHJhZnQtaWV0Zi1hbmltYS1ncmFzcC1hcGktMDI8L3Nw YW4+ICh3b3JrIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAg ICAgICAgcHJvZ3Jlc3MpLCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5EZWNlbWJlciAyMDE3Ljwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICBw cm9ncmVzcyksIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkp1bmUgMjAxOC48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQuaWV0Zi1hbmlt YS1wcmVmaXgtbWFuYWdlbWVudF08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBbSS1ELmlldGYtYW5pbWEtcHJlZml4LW1hbmFnZW1lbnRdPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIEppYW5nLCBTLiwgRHUsIFouLCBDYXJwZW50 ZXIsIEIuLCBhbmQgUS4gU3VuLCAiQXV0b25vbWljPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgICBKaWFuZywgUy4sIER1LCBaLiwgQ2FycGVudGVyLCBC LiwgYW5kIFEuIFN1biwgIkF1dG9ub21pYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICBJUHY2IEVkZ2UgUHJlZml4IE1hbmFnZW1lbnQgaW4gTGFyZ2Ut c2NhbGUgTmV0d29ya3MiLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgSVB2NiBFZGdlIFByZWZpeCBNYW5hZ2VtZW50IGluIExhcmdlLXNjYWxlIE5l dHdvcmtzIiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1hbmltYS1wcmVmaXgtbWFuYWdlbWVudC0wNyAod29yayBpbiBwcm9ncmVz cyksPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBkcmFm dC1pZXRmLWFuaW1hLXByZWZpeC1tYW5hZ2VtZW50LTA3ICh3b3JrIGluIHByb2dyZXNzKSw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgRGVjZW1iZXIg MjAxNy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIERl Y2VtYmVyIDIwMTcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtJLUQuaWV0Zi1hbmltYS1zdGFibGUtY29ubmVjdGl2aXR5XTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1hbmltYS1zdGFibGUtY29ubmVjdGl2 aXR5XTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBFY2tl cnQsIFQuIGFuZCBNLiBCZWhyaW5nZXIsICJVc2luZyBBdXRvbm9taWMgQ29udHJvbDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgRWNrZXJ0LCBULiBh bmQgTS4gQmVocmluZ2VyLCAiVXNpbmcgQXV0b25vbWljIENvbnRyb2w8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgUGxhbmUgZm9yIFN0YWJsZSBDb25u ZWN0aXZpdHkgb2YgTmV0d29yayBPQU0iLCBkcmFmdC1pZXRmLTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUGxhbmUgZm9yIFN0YWJsZSBDb25uZWN0 aXZpdHkgb2YgTmV0d29yayBPQU0iLCBkcmFmdC1pZXRmLTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMTQiIGNsYXNz PSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGEgaHJlZj0iI3BhcnQtMTQiPjxlbT4gcGFnZSAyOCwgbGluZSA0NTxzcGFuIGNs YXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0xNCI+ PGVtPiBwYWdlIDI5LCBsaW5lIDIwPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+ PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQuaWV0Zi1zdXBh LWdlbmVyaWMtcG9saWN5LWRhdGEtbW9kZWxdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgW0ktRC5pZXRmLXN1cGEtZ2VuZXJpYy1wb2xpY3ktZGF0YS1tb2RlbF08L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgSGFscGVybiwgSi4g YW5kIEouIFN0cmFzc25lciwgIkdlbmVyaWMgUG9saWN5IERhdGEgTW9kZWw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEhhbHBlcm4sIEouIGFuZCBK LiBTdHJhc3NuZXIsICJHZW5lcmljIFBvbGljeSBEYXRhIE1vZGVsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIGZvciBTaW1wbGlmaWVkIFVzZSBvZiBQ b2xpY3kgQWJzdHJhY3Rpb25zIChTVVBBKSIsIGRyYWZ0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgZm9yIFNpbXBsaWZpZWQgVXNlIG9mIFBvbGlj eSBBYnN0cmFjdGlvbnMgKFNVUEEpIiwgZHJhZnQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgIGlldGYtc3VwYS1nZW5lcmljLXBvbGljeS1kYXRhLW1v ZGVsLTA0ICh3b3JrIGluIHByb2dyZXNzKSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgIGlldGYtc3VwYS1nZW5lcmljLXBvbGljeS1kYXRhLW1vZGVs LTA0ICh3b3JrIGluIHByb2dyZXNzKSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgSnVuZSAyMDE3LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgSnVuZSAyMDE3LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb25d PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5saXUtYW5pbWEtZ3Jh c3AtZGlzdHJpYnV0aW9uXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICBMaXUsIEIuLCBKaWFuZywgUy4sIFhpYW8sIFguLCBIZWNrZXIsIEEuLCBhbmQg Wi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIExpdSwg Qi4sIEppYW5nLCBTLiwgWGlhbywgWC4sIEhlY2tlciwgQS4sIGFuZCBaLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBEZXNwb3RvdmljLCAiSW5mb3Jt YXRpb24gRGlzdHJpYnV0aW9uIGluIEF1dG9ub21pYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgRGVzcG90b3ZpYywgIkluZm9ybWF0aW9uIERpc3Ry aWJ1dGlvbiBpbiBBdXRvbm9taWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0iZGlmZjAwMzAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBO ZXR3b3JraW5nIiwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQtbGl1LWFuaW1hLWdyYXNw LWRpc3RyaWJ1dGlvbi0wNTwvc3Bhbj4gKHdvcms8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICBOZXR3b3JraW5nIiwgPHNwYW4gY2xhc3M9Imluc2Vy dCI+ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbi0wNjwvc3Bhbj4gKHdvcms8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBpbiBwcm9n cmVzcyksIDxzcGFuIGNsYXNzPSJkZWxldGUiPkZlYnJ1YXJ5PC9zcGFuPiAyMDE4LjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIGluIHByb2dyZXNz KSwgPHNwYW4gY2xhc3M9Imluc2VydCI+SnVseTwvc3Bhbj4gMjAxOC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAz MSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBbSURldklEXSAgIElFRUUgU3RhbmRhcmQsIDxzcGFuIGNs YXNzPSJkZWxldGUiPiwgPC9zcGFuPiJJRUVFIDgwMi4xQVIgU2VjdXJlIERldmljZSBJZGVu dGlmaWVyIiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgW0lEZXZJRF0g ICBJRUVFIFN0YW5kYXJkLCAiSUVFRSA4MDIuMUFSIFNlY3VyZSBEZXZpY2UgSWRlbnRpZmll ciIsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIERlY2Vt YmVyIDIwMDksICZsdDtodHRwOi8vc3RhbmRhcmRzLmllZWUub3JnL2ZpbmRzdGRzLzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAw OSwgJmx0O2h0dHA6Ly9zdGFuZGFyZHMuaWVlZS5vcmcvZmluZHN0ZHMvPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIHN0YW5kYXJkLzgwMi4xQVItMjAw OS5odG1sJmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgIHN0YW5kYXJkLzgwMi4xQVItMjAwOS5odG1sJmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW01leWVyOTddICBNZXllciwgQi4sICJPYmpl Y3QtT3JpZW50ZWQgU29mdHdhcmUgQ29uc3RydWN0aW9uICgybmQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBbTWV5ZXI5N10gIE1leWVyLCBCLiwgIk9iamVjdC1Pcmll bnRlZCBTb2Z0d2FyZSBDb25zdHJ1Y3Rpb24gKDJuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgICAgICAgICBlZGl0aW9uKSIsIFByZW50aWNlLUhhbGwsIElTQk4g OTc4LTAxMzYyOTE1NTgsIDE5OTcuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICBlZGl0aW9uKSIsIFByZW50aWNlLUhhbGwsIElTQk4gOTc4LTAxMzYy OTE1NTgsIDE5OTcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtSRkM3NTc1XSAgQmVocmluZ2VyLCBNLiwgUHJpdGlraW4sIE0uLCBCamFybmFzb24s IFMuLCBDbGVtbSwgQS4sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JG Qzc1NzVdICBCZWhyaW5nZXIsIE0uLCBQcml0aWtpbiwgTS4sIEJqYXJuYXNvbiwgUy4sIENs ZW1tLCBBLiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg Q2FycGVudGVyLCBCLiwgSmlhbmcsIFMuLCBhbmQgTC4gQ2lhdmFnbGlhLCAiQXV0b25vbWlj PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBDYXJwZW50 ZXIsIEIuLCBKaWFuZywgUy4sIGFuZCBMLiBDaWF2YWdsaWEsICJBdXRvbm9taWM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgTmV0d29ya2luZzogRGVm aW5pdGlvbnMgYW5kIERlc2lnbiBHb2FscyIsIFJGQyA3NTc1LDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgTmV0d29ya2luZzogRGVmaW5pdGlvbnMg YW5kIERlc2lnbiBHb2FscyIsIFJGQyA3NTc1LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAzMiI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAg ICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3NTc1LCBKdW5lIDIwMTUsIDxzcGFuIGNsYXNzPSJk ZWxldGUiPiZsdDtodHRwczovL3d3dy5yZmMtPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3NTc1LCBKdW5l IDIwMTUsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgICAgICAgICAgICAgZWRpdG9yLm9yZy9pbmZvL3JmYzc1NzUmZ3Q7Ljwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij4mbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmM3NTc1Jmd0Oy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFtSRkM3NTc2XSAgSmlhbmcsIFMuLCBDYXJwZW50ZXIsIEIuLCBhbmQgTS4g QmVocmluZ2VyLCAiR2VuZXJhbCBHYXA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBbUkZDNzU3Nl0gIEppYW5nLCBTLiwgQ2FycGVudGVyLCBCLiwgYW5kIE0uIEJlaHJp bmdlciwgIkdlbmVyYWwgR2FwPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIEFuYWx5c2lzIGZvciBBdXRvbm9taWMgTmV0d29ya2luZyIsIFJGQyA3NTc2 LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQW5hbHlz aXMgZm9yIEF1dG9ub21pYyBOZXR3b3JraW5nIiwgUkZDIDc1NzYsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDMzIj48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzc1NzYsIEp1bmUgMjAxNSwgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+Jmx0O2h0dHBzOi8vd3d3LnJmYy08L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JG Qzc1NzYsIEp1bmUgMjAxNSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICBlZGl0b3Iub3JnL2luZm8vcmZjNzU3 NiZndDsuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPiZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmYzc1NzYmZ3Q7Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1pY2hhZWwgSC4gQmVocmluZ2VyIChlZGl0b3Ip PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWljaGFlbCBILiBCZWhyaW5n ZXIgKGVkaXRvcik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgRW1haWw6IE1pY2hhZWwuSC5CZWhyaW5nZXJAZ21haWwuY29tPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgRW1haWw6IE1pY2hhZWwuSC5CZWhyaW5nZXJAZ21haWwu Y29tPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDM0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQnJpYW4gQ2FycGVudGVyPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQnJpYW4gQ2FycGVudGVyPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVuY2U8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEZXBhcnRtZW50IG9mIENvbXB1 dGVyIFNjaWVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFVuaXZlcnNp dHkgb2YgQXVja2xhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBVbml2 ZXJzaXR5IG9mIEF1Y2tsYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQ QiA5MjAxOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBCIDkyMDE5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdWNrbGFuZCAgMTE0MjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1Y2tsYW5kICAxMTQyPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBOZXcgWmVhbGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIE5ldyBaZWFsYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIEVtYWlsOiBicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFbWFpbDogYnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFRvZXJsZXNzIEVja2VydDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRvZXJsZXNzIEVja2VydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K CiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBi Z2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5k IG9mIGNoYW5nZXMuIDM0IGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0 ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT42MSBsaW5lcyBjaGFuZ2VkIG9yIGRl bGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0aD48aT43MyBsaW5lcyBjaGFuZ2Vk IG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49 IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJzbWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3 YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQ3LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZh aWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9y ZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90 ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2JvZHk+CiAgIDwvaHRtbD4K --------------D99C84AA3FD38F97807EBC08-- From nobody Sat Aug 11 08:31:16 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1887130E72; Sat, 11 Aug 2018 08:31:09 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NgbtwqNvgIvb; Sat, 11 Aug 2018 08:31:06 -0700 (PDT) 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 9259C130EA5; Sat, 11 Aug 2018 08:31:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7DF602CA91C; Sat, 11 Aug 2018 08:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1534001466; bh=B1AHCUooxQ06eobhF9PtEx8FegV2KpxVyTvUUN5wAng=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FerjoYceE2y/W09yb9hdsV+KeKH+W05WVwiVAoctkEm1xOKhoiFqsJZv5pYHs9uPP WPpmXAvqiUsbUPYqTefMi/3NoNCi0KNtzegOZ63ywL9m5j1uSvuZ9GXoDEs52sRbr3 rpR/9ihqrWkg2/eHdtFAXow0wcCWxZJqmRSgbBr4= 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 AC61C2CA91A; Sat, 11 Aug 2018 08:31:04 -0700 (PDT) To: "Michael H. Behringer" , gen-art@ietf.org Cc: anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> <12e38af2-c0bd-d0da-92f2-34a520ffadcb@gmail.com> From: Joel Halpern Direct Message-ID: Date: Sat, 11 Aug 2018 11:31:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <12e38af2-c0bd-d0da-92f2-34a520ffadcb@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 15:31:10 -0000 Thanks Michael. That sounds like you are covering my concerns quite effectively. On the IDevID reference, all I think is needed is to change the IEEE reference to be normative instead of informative. (Or if Toerless' suggestion is effective in your view, change the text to say that IDevID is defined in a normatively referenced I-D instead of in the IEEE document.) Yours, Joel PS: Regarding copying ietf@ietf.org, I think it is okay to have removed them now. Anyone outside the WG who wants to know about the conversation is aware that it is occurring. Because these are IETF LC comments, the initial comments need to go to the ietf list. On 8/11/18 10:36 AM, Michael H. Behringer wrote: > Thanks Joel for the thorough review! Sorry for the delayed response, I > was mostly offline on business travel. As Brian, I also took > ietf@ietf.org off the cc, please let me know if this is inappropriate, > in which case I repost with that list on. > > Inline... > > On 10/08/2018 10:00, Joel Halpern wrote: >> Reviewer: Joel Halpern >> Review result: Ready with Issues >> >> 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. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-anima-reference-model-06 >> Reviewer: Joel Halpern >> Review Date: 2018-08-09 >> IETF LC End Date: 2018-08-21 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: The document is ready for publication as an Informational RFC. >> Clarity would be improved if the minor issues below were addressed. >> >> Major issues: N/A >> >> Minor issues: >>      Section 2 includes "naming" in the list of services the ANI >> provides. >>      Which surprised me.  But then section 3 does not include "naming" >> in the >>      list of services of the ANI in Figure 2 of section 3.1? > Yes, naming is actually required for an autonomic solution. I understand > your concern though, and added it to figure 2 and section 3.1. It's more > consistent, you're right. > >>      In section 3.2, in the second paragraph on where adjacency >> information >>      comes from, the text of the second bullet refers to vendor >> redirects. >>      While I understand that those are an important part of the system >>      information, they do not appear to create an adjacency?  If they >> do, then >>      the term adjacency needs to be better explained in this section. >> The first >>      bullet in the next list says the same thing.  My best guess is that >>      adjacency sometime means actual topological adjacency, and >> sometimes means >>      a more general form of adjacency.  As written, I think it will >> confuse >>      readers. > Hmmm... I re-read our text, and I think it describes exactly what we > want to say. :-)  So there is clearly a problem. > > The original idea was that a new node with factory default settings > needs to be able to find where it should connect. Since a factory > default device cannot have specific information of its final network > placement, the vendor MASA can be set up to provide information to the > new node on where its home network is. I think we're probably in sync up > to here. > > Now, our design decision was that this re-direct from the MASA should > not require any other treatment than any other adjacency: It delivers an > IP address to connect to, and to set up the ACP with. From this logic > follows that the re-direct address is also entered into the adjacency > table, and not treated in any "special" way. > > So, the real problem is probably the referernce to BRSKI, since this > behaviour is not yet defined there. I suggest to simply remove the > reference to BRSKI at this point. That seems to be the only confusing > bit. And it allows potentially another document in the future to take up > the details. I've taken it out for now. If anyone thinks that's a bad > idea, shout! :-) > >>      IDevID (referenced in section 3.3.1 at least) appears to be a >> normative >>      reference.  Devices supporting the Anima Reference Model are >> required to >>      support that, so understanding how to do so seems necessary for >>      understanding this specification. > > I just read the entire discussion on this point, and am unsure what you > would like us to do, or what the problem actually is. Can you be more > specific? >>      Does section 3.3.2 intend to mandate that devices have persistent >> storage >>      for the LDevID?  Or is it trying to say that on power cycle it >> stays in >>      Enrolled state if it retains its LDevID, but goes back to the >> Factory >>      default state if not?  (Given that folks have repeatedly said >> that these >>      may be low power devices, I think we need to be clear about what >> we are >>      requiring.) > Yes, your guess is absolutely right. I clarified that now by adding in > the intro of section 3.3 (it affects the state machine in TWO points, > actually): > >     A device is normally expected to store its LDevID in persistent > storage, to be available after a powercycle event. For device types that > cannot store the LDevID in persistent storage, a powercycle event is > effectively equivalent to a factory reset. > >>      Section 5 starts by saying that the administrator does not have to >>      configure security.  In the very next paragraph it says that a >> PKI must be >>      in place.  That clearly requires configuring some security >> properties. >>      Please reword. > > I added a little phrase at the end of the sentence which now reads: >     An Autonomic Network is self-protecting. All protocols are > secure by default, without the requirement for the administrator to > explicitly configure security, with the exception of setting up a PKI > infrastructure. > >>      Section 6.2 says that all ASA must "follow the same operating >> principles". >>      The general guideliens of what these must cover is then given. >> It is >>      appropriate that this document does not specify the detailed >> behavior. >>      That would go in a standards track document.  But there is no >> reference to >>      a draft covering that.  So we have text saying that all ASA must >> follow >>      "something", but no reference as to the content of that >> "something".  Is >>      this a real requirement?  If so, it appears to be unmeetable. > > I think the "must" is misleading here. It's not meant to imply that we > have something ready-to-go for this, it's saying: One day, when someone > bites his teeth into this problem, make sure that all ASAs are managed > in the same way. > > So, re-phrasing: "Management of ASAs and its interactions with the ANI > should follow the same operating principles, hence comply to a generic > life-cycle management model." > > This should be sufficiently clear what we mean, without implying that we > already have a solution. OK? > >> Nits/editorial comments: >>      In section 3.2, why would / could an adjacency table track >> "validity and >>      trust of the adjacent autonomic >>     node's certificate" if all transactions have to verify that >> separately >>     anyway?  Why mention it here? > > Yes, that doesn't read right. Simplified that to: "The adjacency table > may contain information about the validity and trust level of the > adjacent autonomic node."  (deleted the second sentence). Does that work? > >>     In the next to last bullet of the second bulleted list of section >> 3.2, the >>     text states that the node will start a "join assistant" ASA. >> Could we have >>     a forward reference to 6.3.1.2 (which then has the necessary >> normative >>     reference)? > Done. >>      The first use of LDevID in section 3.3.1 should have a forward >> reference to >>      the definition (which I think is section 5.2.) > Done. >>      Section 3.3.2 in defining when a device is in the Enrolled state >> says that >>      it in the Enrolled state if it has an LDevID.  As far as I can >> tell, the >>      added constraint is that it is not currently a member of an ACP. >> The text >>      should include that. > Done. >>      The third paragraph of section 6.1 refers to the Autonomic nodes >> and the >>      ASAs as "self-aware".  I do not know what meaning is being >> ascribed to that >>      phrase.  The usage does not seem to correspond to any meaning I can >>      understood.  Can we just remove the sentence?  (I suspect that the >>      intention is to lead to the fact that the functions can advertise >> their >>      capabilities, and negotiate them.  We don't need the sentence as >> grounding >>      for that.) > We mean: In a traditional network, a big fat brain knows all the > capabilities and hardware details of all platforms, and decides > centrally which software bits and command lines and other bits and > pieces should go to which node. > > In an autonomic network, it is the node itself that knows its own h/w > features and capabilities, and decides how to implement the guidance of > the central brain, which now only issues Intent. > > Modified that to: > "Autonomic nodes, and therefore their ASAs, know their own > capabilities and restrictions, derived from hardware, firmware or > pre-installed software: They are "self-aware". > The role of an autonomic node depends on Intent and on the > surrounding network behaviors, which may include forwarding behaviors, > aggregation properties, topology location, bandwidth, tunnel or > translation properties, etc. For example, a node may decide to act as a > backup node for a neighbor, if its capabilities allow it to do so. " > > (Laurent - please let me know if you are ok with this change) > >>      While I appreciate the reference to SUPA in section 7.2, the >> working group >>      having been terminated by the AD makes this a difficult topic for >> people to >>      find.  Presumably, PCIM should be an actual reference to the >> relevant RFC. > Removed SUPA, and left PCIM. >>      Personal opinion: Section 8 on coordination is too hypothetical >> to be >>      useful to a reader of this document.  I think it is better removed. > I appreciate your opinion, but I would prefer to keep it, as background > info. It's clearly labelled with an "*". This piece of the story was > contributed by Laurent and Pierre, who had done a lot of work in this > area, and I really learned a lot from it. Designers of ASAs should > definitely read it. There is a lot of stuff in there that you might miss > without this section. > > But, I'm looking at Laurent and Pierre to comment as well. Maybe the > material is covered in the same way on another draft, and we could point > to that? (On a plane right now, can't check). If not, I would not want > to delete nor shorten it. > > Made all the changes in draft-ietf-anima-reference-model.xml on github, > and created the corresponding txt file. I'm not going to submit a new > version quite yet, more comments are likely to come :-) > > Co-authors: Please review and double-check. Let me know if you disagree > with any change. > See: https://github.com/mbehring/ANIMA-Reference-Model > files draft-ietf-anima-reference-model.txt and .xml. > Diff attached. > > Joel: Thanks for the detailed review! It made the document better! > Michael > From nobody Mon Aug 13 19:05:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D1F130F65 for ; Mon, 13 Aug 2018 19:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0S6eKzIb-h7 for ; Mon, 13 Aug 2018 19:05:40 -0700 (PDT) Received: from mail-pl0-x243.google.com (mail-pl0-x243.google.com [IPv6:2607:f8b0:400e:c01::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 52D4B130E90 for ; Mon, 13 Aug 2018 19:05:40 -0700 (PDT) Received: by mail-pl0-x243.google.com with SMTP id ba4-v6so7661343plb.11 for ; Mon, 13 Aug 2018 19:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=r7Rsfj8YFpFMw8i4pg3ex00bFMrooK/CUBJfKojsyhs=; b=DN5eD27bHFpnW2F1hJ5RZaVQgr8jSStgF6fBI+qCHhzmc48bJTURzagIjWOc8DqYsR T5p0YI4Vz/iI30l7ujHDi/rSXddW45s54m1V2uifMv8zeH4mb81hGU1GMJSLm8Yuf7ZR IZ16fCM0lMh9GpZCDAi07qP+RbyAOVG0ZWcvRAcDLgSEQA4/YEJjeVfRimAXzzdtOqZw kCAgElVzKYjgkyc6QNLXlrlzllxNNFyNsom6jGYjTUYIOiOMo11AxzoSQSXPgpUILkpi 2vol9DstQRv68NuVOQpEQDmT5s/DksGFs8elfpf1Zp6JjIZxaGFAd5gHr9E6Psu1kNpT mmgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=r7Rsfj8YFpFMw8i4pg3ex00bFMrooK/CUBJfKojsyhs=; b=moJKJxSLp9l7sKZTQrQPVo7nqPEIlou3dGl7FyUvfdOkBAW8OvVe5QtobKQyxxq6cH pRqcszQNq6U9qNNv5P9E9iFE/qrOtqDCLqzw6VnwKG+gXQbWgGX9WOxUmALC0N8yRZjZ E2abzzfkGN6a1OGgTCib5KTYSQf5t0+SlDmIAosDZeO0EYO20ts4KRGImGAUdkhV6f45 6vuv5yU3yjhiXsQ01IdStolQ2aLQJa3m/87acFcFBG7oMWALUXRHal6ljA9Z5SVop/vf VtQ+cwkISh/JdN44Q37dbJCIO2GK1ntGUWH50ZGloVu6mZ7H0vWgps0rycUDfnf9djtH D6pQ== X-Gm-Message-State: AOUpUlEiXVXUbgkAfcAqP4BWLqOoRVtONTwMhu41gW8KPHqwMhgKzZqH QOzKMXYb7B1KEkDo+Lh4VbsInnS9 X-Google-Smtp-Source: AA+uWPxWb6US5h4qDcQgZWELqZhalSMphAcgzNXAt04VrcFWBWMNQp9kkmZQ2ZNRXDk889lWEiLfxA== X-Received: by 2002:a17:902:864b:: with SMTP id y11-v6mr18926131plt.335.1534212339671; Mon, 13 Aug 2018 19:05:39 -0700 (PDT) Received: from [172.24.16.218] ([202.36.244.180]) by smtp.gmail.com with ESMTPSA id r81-v6sm27167652pfa.18.2018.08.13.19.05.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 19:05:38 -0700 (PDT) References: <153421094737.25008.8682280615922133385@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <153421094737.25008.8682280615922133385@ietfa.amsl.com> Message-ID: <5dcd9d7e-2f9e-f6ce-820d-c4f786986de9@gmail.com> Date: Tue, 14 Aug 2018 14:05:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153421094737.25008.8682280615922133385@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 02:05:43 -0000 Updated following comments received at IETF102. -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-limited-domains-02.txt Date: Mon, 13 Aug 2018 18:42:27 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limited Domains and Internet Protocols Authors : Brian Carpenter Bing Liu Filename : draft-carpenter-limited-domains-02.txt Pages : 15 Date : 2018-08-13 Abstract: There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions. It shows the needs for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-limited-domains-02 https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-02 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Aug 17 07:36:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E82130E67; Fri, 17 Aug 2018 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcboB3R4qFK2; Fri, 17 Aug 2018 07:36:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BBE130E8E; Fri, 17 Aug 2018 07:36:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8396C20497; Fri, 17 Aug 2018 10:53:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 98936194A; Fri, 17 Aug 2018 10:36:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 95B3E193D; Fri, 17 Aug 2018 10:36:09 -0400 (EDT) From: Michael Richardson To: Joel Halpern cc: gen-art@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org In-Reply-To: <153386283991.28744.9091243291268056328@ietfa.amsl.com> References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 14:36:15 -0000 --=-=-= Content-Type: text/plain Joel Halpern wrote: > Does section 3.3.2 intend to mandate that devices have persistent > storage for the LDevID? Or is it trying to say that on power cycle it > stays in Enrolled state if it retains its LDevID, but goes back to the > Factory default state if not? (Given that folks have repeatedly said > that these may be low power devices, I think we need to be clear about > what we are requiring.) *) Constrained devices are not, in general, in scope for the WG *) Regardless, the LDevID needs to be persisted, and I agree we should say that. > Section 5 starts by saying that the administrator does not have to > configure security. In the very next paragraph it says that a PKI must > be in place. That clearly requires configuring some security > properties. Please reword. The administrator has to have a PKI. We considered making the PKI auto-configuring, but we backed out of that as a hard requirement. I agree that this text need to be clarified. > Section 3.3.2 in defining when a device is in the Enrolled state > says that it in the Enrolled state if it has an LDevID. As far as I > can tell, the added constraint is that it is not currently a member of > an ACP. The text should include that. Agreed. > The third paragraph of section 6.1 refers to the Autonomic nodes > and the ASAs as "self-aware". I do not know what meaning is being > ascribed to that phrase. The usage does not seem to correspond to any > meaning I can understood. Can we just remove the sentence? (I suspect > that the intention is to lead to the fact that the functions can > advertise their capabilities, and negotiate them. We don't need the > sentence as grounding for that.) I think that the intent is to say that the ASA will have a model of itself. I think that it would be better to say that. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlt23VkACgkQgItw+93Q 3WWVygf/dGL8k2EiG0yBv8UF4Se36whVimf8xng2k3NFFHg8yU/pHquE9NfYUS44 c2I3o962cA19U6SJgDdN/+hSLRAkVEV0plL4OkI+c4G8IsDqp0twsQDCnUGM5a93 XvzxhMBWeS7anf2KHLGt+jaPJD2dMc6b9MAy/Sb/YbhjYtW2YpcJ5uY/5lqdQWJ2 qOX/BCmfutv7ijRQWjycHDLrK+EfWjMq2+GCk4NQmTeaydysd5xWXVCScIBspf/g YINzedjDx/pTTJucyU0DCYM4yAg0pT7jy5wQ92q+dPehIfs52KlQSAXs6KJr+/ZK YnJSiwx1xG3aBekEDp8tSbarnU9GnQ== =r8jx -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 17 08:14:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA1E130FC2; Fri, 17 Aug 2018 08:14:36 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pnXpZrURxNY4; Fri, 17 Aug 2018 08:14:34 -0700 (PDT) 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 1EEDA130FE8; Fri, 17 Aug 2018 08:14:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0DC475E1247; Fri, 17 Aug 2018 08:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1534518874; bh=GdeG/lV8Pd7T+r6tWZa7iWKhv24MaiJSUm9GhejYUiw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=K3dQ914m+Y3IgA26eoYsUy94PewpJAl3AJG4AY8gXXPdO93vnrnvXwPlS8qgvclf9 r5VIlGv8+So010qU0x1dihSdV8tRXIRp2Tuz27ZRStCJOKKMfirELQ4rGQaJPk0nWG VA+IDPv3eU6qYXP1U1bgc6+wal28a5OXL8rKcDms= 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 936CF5E1245; Fri, 17 Aug 2018 08:14:31 -0700 (PDT) To: Michael Richardson Cc: gen-art@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> <17752.1534516569@localhost> From: "Joel M. Halpern" Message-ID: Date: Fri, 17 Aug 2018 11:14:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <17752.1534516569@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 15:14:38 -0000 Thank you Michael. Seems that we are good. Yours, Joel On 8/17/18 10:36 AM, Michael Richardson wrote: > Joel Halpern wrote: > > Does section 3.3.2 intend to mandate that devices have persistent > > storage for the LDevID? Or is it trying to say that on power cycle it > > stays in Enrolled state if it retains its LDevID, but goes back to the > > Factory default state if not? (Given that folks have repeatedly said > > that these may be low power devices, I think we need to be clear about > > what we are requiring.) > > *) Constrained devices are not, in general, in scope for the WG > *) Regardless, the LDevID needs to be persisted, and I agree we should say that. > > > Section 5 starts by saying that the administrator does not have to > > configure security. In the very next paragraph it says that a PKI must > > be in place. That clearly requires configuring some security > > properties. Please reword. > > The administrator has to have a PKI. We considered making the PKI > auto-configuring, but we backed out of that as a hard requirement. > I agree that this text need to be clarified. > > > Section 3.3.2 in defining when a device is in the Enrolled state > > says that it in the Enrolled state if it has an LDevID. As far as I > > can tell, the added constraint is that it is not currently a member of > > an ACP. The text should include that. > > Agreed. > > > The third paragraph of section 6.1 refers to the Autonomic nodes > > and the ASAs as "self-aware". I do not know what meaning is being > > ascribed to that phrase. The usage does not seem to correspond to any > > meaning I can understood. Can we just remove the sentence? (I suspect > > that the intention is to lead to the fact that the functions can > > advertise their capabilities, and negotiate them. We don't need the > > sentence as grounding for that.) > > I think that the intent is to say that the ASA will have a model of itself. > I think that it would be better to say that. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Aug 19 19:11:05 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 131A1130E9B; Sun, 19 Aug 2018 19:10:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tianran Zhou To: Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153473105603.21205.6247870191811433257@ietfa.amsl.com> Date: Sun, 19 Aug 2018 19:10:56 -0700 Archived-At: Subject: [Anima] Opsdir last call review of draft-ietf-anima-reference-model-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 02:10:56 -0000 Reviewer: Tianran Zhou Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I did not see any special operational or network management related issue. This document is clear to me and is ready for publication. By the way, do you think "MRACL" in this document need a reference or expansion? Cheers, Tianran From nobody Wed Aug 22 00:08:06 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 167E9120049; Wed, 22 Aug 2018 00:08:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, ibagdona@gmail.com, anima@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153492168400.15971.15261624408880781534.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2018 00:08:04 -0700 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 103 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 07:08:04 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf detnet Third Priority: cfrg saag intarea opsarea dinrg panrg People who must be present: Toerless T. Eckert Sheng Jiang Terry Manderson Ignas Bagdonas Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Wed Aug 22 21:30:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D893128C65; Wed, 22 Aug 2018 21:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 R19R8mKyxlBj; Wed, 22 Aug 2018 21:30:30 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C99D127332; Wed, 22 Aug 2018 21:30:30 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 71CD558C4B3; Thu, 23 Aug 2018 06:30:25 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5C0E14402CB; Thu, 23 Aug 2018 06:30:25 +0200 (CEST) Date: Thu, 23 Aug 2018 06:30:25 +0200 From: Toerless Eckert To: IETF Meeting Session Request Tool Cc: anima-chairs@ietf.org, ibagdona@gmail.com, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180823043025.o45qsr6ivpblwniq@faui48f.informatik.uni-erlangen.de> References: <153492168400.15971.15261624408880781534.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153492168400.15971.15261624408880781534.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] anima - New Meeting Session Request for IETF 103 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 04:30:33 -0000 Updated with my conflicts A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man detnet pim Second Priority: roll v6ops dhc homenet netconf bier mboned Third Priority: cfrg saag intarea opsarea dinrg panrg People who must be present: Toerless T. Eckert Sheng Jiang Terry Manderson Ignas Bagdonas Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. From nobody Thu Aug 23 07:29:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB0B130E0C for ; Thu, 23 Aug 2018 07:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF5IPsKamYLs for ; Thu, 23 Aug 2018 07:29:02 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10099.outbound.protection.outlook.com [40.107.1.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D55126CB6 for ; Thu, 23 Aug 2018 07:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TwhTyMco6tmt7nlVwVf261aqxBK25NCj40tZ88BVoZM=; b=YmferhH3ufeKTgBylgmvaqJr2cHZiETcBd/CJ9PtcqHpgD0XXCeebGVcyTq8bJSYXC6Od1SPnTcOpabM4tIQoEisIqWau9mcPDEV3Ta7qLGTh91HJu7l9+QkfRSa5/D6z3D+bJLuWDsjlsKpMkyfo/7yPmwBIwnbCWHrXKjOtPw= Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0021.EURP190.PROD.OUTLOOK.COM (10.172.228.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.13; Thu, 23 Aug 2018 14:28:58 +0000 Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::3dc6:a81a:4eea:5c97]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::3dc6:a81a:4eea:5c97%5]) with mapi id 15.20.1059.023; Thu, 23 Aug 2018 14:28:58 +0000 From: Esko Dijk To: "anima@ietf.org" Thread-Topic: draft-ietf-anima-bootstrapping-keyinfra: assertions other than "proximity"? Thread-Index: AdQ669G4+knlKAlER/yMYZjt5EKhnQ== Date: Thu, 23 Aug 2018 14:28:58 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3100:b700:6001:5eda:6fce:8276] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6P190MB0021; 6:mER7H+ZAlI0eFNeMfYCOXkaoa2vOcwSDEUu9ZSnNo8TmtSZdHfz1A1ZGRuHUdmUDJ9auH2LRNnIV7rgKW2M4MzfJiZ2V/dHV7C39xZf0KZxSyFSpEEaxVySgh6eN6icgCDucgzILlNzKwMxz2+fYBo9EMbGwzszyfvo1xgmALloxfADZqXKLNBGArM/DweB0SZ7L8RCrZqq1XW2b1kehWCIwZ7DO683kgT/S/bBwYpOqRnSHdYeBTrNMSleSddGoLoFfUWqIJR9VNHkdWV9GHrtsjx4uwsr5aiU02J03VmyqIdiFgOC/wMp8+JfU8sPxddVsVZI8ad7HuaGslyY06psvlcgrnApycipr+rXfDuvUgCdCb+eFlWt6gxXCqt7z2jWkucilcjeHHtXgJzDz2PbX7fvPyUydgkvGvx3fi6baXz1btC/LnWMFQnsWTjDb/DOCos+E3TUbBb0YZ0qAtQ==; 5:1IrAdAeqPPU1hi3zM3ephO//T5oAc3cvT0XpPjI30OLc4kMhF0ziCiHJNCKm1wioXQhIHfPfu8ktkAOYoWE6f790sMP6ZDQh0Wf/CBR00kTCJy9dWc6Q0EqkTyxID2NYl2V8otMaxUD7OgeSy2cYJDUTbzx/+ORtEwIXzGHbFdE=; 7:wDTyajmJKyuZbfEd1AV1C56G6Xt5LMjHfsB4HJsqi7ka8H1sXgOTiYaMFY2NYzBBdRHAAelgSnoOgPbynVCocamlzJu7z9NO75koT776/thbB7rKwwTjqDdRiwX1Pg/3fgjR1ogDEaLSo1vFXkSi3mdHdQPj4FfyfIARST1rd62S/pO6+Pn/cQJPmYd5zLBZdMrc5HKcmbq+y0oP+gsr8oB6kYmWvrIVuzdhxXK692nP3GBkxidPhcUP3DN6y7nJ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 929e6b2a-b1f8-4a0c-27be-08d60904c358 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989137)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0021; x-ms-traffictypediagnostic: DB6P190MB0021: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123564045)(2016111802025)(20161123562045)(20161123558120)(6043046)(201708071742011)(7699016); SRVR:DB6P190MB0021; BCL:0; PCL:0; RULEID:; SRVR:DB6P190MB0021; x-forefront-prvs: 0773BB46AC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(396003)(376002)(39830400003)(189003)(199004)(44832011)(25786009)(14454004)(74316002)(53936002)(2351001)(5640700003)(74482002)(8936002)(6436002)(55016002)(6306002)(6916009)(54896002)(9686003)(97736004)(5630700001)(478600001)(33656002)(7736002)(106356001)(68736007)(1730700003)(81166006)(8676002)(81156014)(86362001)(105586002)(413944005)(5660300001)(14444005)(102836004)(2906002)(256004)(7696005)(5250100002)(2501003)(6506007)(46003)(186003)(476003)(99286004)(316002)(6116002)(790700001)(2900100001)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0021; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-microsoft-antispam-message-info: JuvjKcqr4sCLGLXuept85FBS8LPVsYpIq6YPPeNP0D8kO+4S37JQUHTk7NPfjjadCSEdST2u6bE8QWTP5EpWpuBtI9yY/FvFr16jxqv39nbIbB0HQyD7ARjlKb+PXF+RkMXCm1vXBGE7XvTnw3r9+cBQQkwX6WG0Kz5tX6XzUY+RyhiktLuxH/DhQufMdtqq5MUKy7SzsHPRawLuyYixQsNWHZnUwVGR+weYcpmz9hcWTy4MvZAHCt99FSQJzRjz/Ww3C584i7q1Fs/tei1Yb95wWTJ+w39nSC3t1MgByKf2JUwsvhq8dEwNcEQ0zZ7kX6QVZaDYo8+hmazuZQ7cGyc0vL7LyLnALP0ntO5mxbs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6P190MB0054BB4FAEEA9295A3A45C09FD370DB6P190MB0054EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 929e6b2a-b1f8-4a0c-27be-08d60904c358 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2018 14:28:58.0406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0021 Archived-At: Subject: [Anima] draft-ietf-anima-bootstrapping-keyinfra: assertions other than "proximity"? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 14:29:05 -0000 --_000_DB6P190MB0054BB4FAEEA9295A3A45C09FD370DB6P190MB0054EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, In draft-ietf-anima-bootstrapping-keyinfra-16 the "assertion" field seems m= andatory in a voucher request by the Pledge, looking at Section 3.1 and the= YANG definition. But one example of a possible value in the voucher reques= t is "TBD" in Section 3.2. This doesn't appear in the allowed assertion st= rings by RFC 8366, so should this be fixed in the text? Maybe "logged" is = intended there? In general what types of assertions could a Pledge use if not "proximity"? = The RFC 8366 descriptions are all written with a voucher in mind, not a vo= ucher request. Perhaps the BRSKI document could detail this aspect more - if not described= elsewhere at least. Best regards Esko Dijk --_000_DB6P190MB0054BB4FAEEA9295A3A45C09FD370DB6P190MB0054EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

In draft-ietf-anima-bootstrapping-keyinfra-16 the &#= 8220;assertion” field seems mandatory in a voucher request by the Ple= dge, looking at Section 3.1 and the YANG definition. But one example of a p= ossible value in the voucher request is “TBD” in Section 3.2.  This doesn’t appear in the allowed assertion s= trings by RFC 8366, so should this be fixed in the text?  Maybe “= ;logged” is intended there?

 

In general what types of assertions could a Pledge u= se if not “proximity”?  The RFC 8366 descriptions are all = written with a voucher in mind, not a voucher request.

Perhaps the BRSKI document could detail this aspect = more – if not described elsewhere at least.

 

Best regards

Esko Dijk

 

--_000_DB6P190MB0054BB4FAEEA9295A3A45C09FD370DB6P190MB0054EURP_-- From nobody Thu Aug 23 08:24:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ACB130E39 for ; Thu, 23 Aug 2018 08:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlX54HH8Beih for ; Thu, 23 Aug 2018 08:24:20 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0107.outbound.protection.outlook.com [104.47.0.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2685128CFD for ; Thu, 23 Aug 2018 08:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ehZETqi4TlpoNl68Y/wv7lj53hH0g0KsCTZ12E70ERI=; b=HPKUs0E2MfGQlk5XSsGAdPrxRDbrWij1RCmOHH+6ydP3x04rg5LjexV1yWkPj3dNGabBGXAVvYPTGIqvTiT3UnGJR4CpXF9N7Nc/Ktl66onFLK+5HdHU9c85hEAhBdqQO+d5aUYkOJsHJbnpXK/xe9ExqRrcGZh6Q4ybgCKzYt0= Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0310.EURP190.PROD.OUTLOOK.COM (10.175.242.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.13; Thu, 23 Aug 2018 15:24:13 +0000 Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::3dc6:a81a:4eea:5c97]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::3dc6:a81a:4eea:5c97%5]) with mapi id 15.20.1059.023; Thu, 23 Aug 2018 15:24:13 +0000 From: Esko Dijk To: "anima@ietf.org" Thread-Topic: draft-ietf-anima-bootstrapping-keyinfra-16: example uses "prior-signed-voucher" Thread-Index: AdQ69NgRMRQJb/8eT426+MhknFpbwQ== Date: Thu, 23 Aug 2018 15:24:13 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3100:b700:6001:5eda:6fce:8276] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6P190MB0310; 6:auCFCJ4LYB9pD9kRS2fBcKIUl/PbdnXEqjt+9PfXYAoINTDnqFqxG+Hjr3asTGSA+6YdybociVWjA0qD4m/+G3wjH1vVcY9itegTnALJ/r/s7cTcbE07mCXkhOuUtwNIMSP4wNRqIfVMSaYOG5LdgKQkIwdljD6qwajsHPU4CFOh9WIj4yEbasNf13WZmue7+/wh+j+MS9m/3DpVTkE+vViSNiZ2WCoGrXvlS4Ktclq6GM8Auq7udhsImlrXxONgH4Ejc3/xFEG2ov/umE6hqHN/W0V8iZwpI8mYbApcTCBZVwUBzubzyjl7H8Nb5IKM549W2srxrX2sJ5USBjAjvPENN7A/g7glk2OLBOiBkY/L7CLHTVP8YY6YQpP8HEGplQJttfRGnJcdQT7nLJ0EFESmWIKohNyyES084mEkxPM7dh9Qeew8QtJtdykMTJrueeD2jNkrE7wIjF0KUZC8hA==; 5:e96YUlrzjgyvVmDhlxL/u0dGwSdoSzTM5SOseRJs20xT/2bXQaYBFFEJilyJ9MkTDVxqKcWZoRggCoLZQgZaLIwhKbTiz34T0SDP8MhQSixrRws88oNT+tx4C4Su1u6Tfi0nHG0ILq1FtHisZaV4HgrHv0o3TMXjfFLZYbm3/pc=; 7:L/6vnBKPctOC8yEoc7wp1cS+34OV4GK1ALDI2qZ8Xtx7Qn74CqJnJLE366noYpNGloUOHdPzcg5kRP8Fd4bSy3COSxf3zziFny7G5zxfeXaeWA8YGbOp3Hnrnild3EAgQLXgzj2g33e37P39hjLGlIq2KDnYjQapiYrv0cWZpz9RltnuWk0kXn0vPPMe7iLBMS5inBjMlF0WcDSCvMXbqDRHJxFOtFodMoaboSTcHfi8eUwU70v5JAXfyADRbfbc x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1371cc86-3ed1-4746-8b70-08d6090c7b77 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989137)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0310; x-ms-traffictypediagnostic: DB6P190MB0310: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6043046)(201708071742011)(7699016); SRVR:DB6P190MB0310; BCL:0; PCL:0; RULEID:; SRVR:DB6P190MB0310; x-forefront-prvs: 0773BB46AC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(376002)(39830400003)(366004)(199004)(189003)(7736002)(5250100002)(2501003)(2906002)(53936002)(81166006)(44832011)(1730700003)(81156014)(6916009)(8676002)(5660300001)(97736004)(74316002)(6116002)(790700001)(7696005)(99286004)(105586002)(5640700003)(2351001)(6436002)(55016002)(106356001)(33656002)(54896002)(9686003)(316002)(476003)(6306002)(478600001)(256004)(14444005)(68736007)(8936002)(486006)(186003)(6506007)(46003)(558084003)(14454004)(102836004)(2900100001)(25786009)(74482002)(86362001)(5630700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0310; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-microsoft-antispam-message-info: MrfC5OUjNeu0wp9v4IFG5muetxdWveErEJJQaSa2JndKJXtVt3KowtrOu/dYqjUyXBRun662UNAdqH8e+yDMSAWimt2ex2MJ/i1n5KZLwxVmOx5JtEqoPD7tRHivQWCqbZz9Aq/kHpMxKXNKWvyOw+YVujZ6VbtBhwwKtjYCZAox6vP1wMyuM7SdhRNPDDKp7noBVbKD23hmPElV9FX0PMUShddc9noBFJmVXZJzg7yxAxksPeNTfOD53FBCH5iv4QVgvU06f4UOpLBY/wTaTL7ZcQwynYkZSUG7SP7GbtgLI+BAASPuMZsrswT30vythN+CNHSwhIPu/TQCM1SteF/WLNjupifPFgUy6Ocg7pU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6P190MB00545AB5BBD1B251F38EC06DFD370DB6P190MB0054EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 1371cc86-3ed1-4746-8b70-08d6090c7b77 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2018 15:24:13.4562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0310 Archived-At: Subject: [Anima] draft-ietf-anima-bootstrapping-keyinfra-16: example uses "prior-signed-voucher" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 15:24:22 -0000 --_000_DB6P190MB00545AB5BBD1B251F38EC06DFD370DB6P190MB0054EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minor review remark: example 2 uses "prior-signed-voucher" which should be = "prior-signed-voucher-request". (I didn't find a ticket system active for this draft; so submitting this on= e directly to the list. I can collect further remarks in an email and send = at some later time.) Esko --_000_DB6P190MB00545AB5BBD1B251F38EC06DFD370DB6P190MB0054EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Minor review remark: example 2 = uses "prior-signed-voucher" which should be "prior-signed-vo= ucher-request".

 

(I didn’t find a ticket system active for this= draft; so submitting this one directly to the list. I can collect further = remarks in an email and send at some later time.)

 

Esko

--_000_DB6P190MB00545AB5BBD1B251F38EC06DFD370DB6P190MB0054EURP_-- From nobody Thu Aug 23 09:49:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5908130E35 for ; Thu, 23 Aug 2018 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuttnXvz4Qro for ; Thu, 23 Aug 2018 09:49:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A53130DE4 for ; Thu, 23 Aug 2018 09:49:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E773720090 for ; Thu, 23 Aug 2018 13:07:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 78E4F1448; Thu, 23 Aug 2018 12:49:51 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7692A335 for ; Thu, 23 Aug 2018 12:49:51 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] draft-ietf-anima-bootstrapping-keyinfra: assertions other than "proximity"? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 16:49:55 -0000 --=-=-= Content-Type: text/plain Thanks for careful read that revealed this point. I've popped your email into an issue: https://github.com/anima-wg/anima-bootstrap/issues/71 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlt+5a8ACgkQgItw+93Q 3WWEbAgAsBkaicldJ4+c5TKSLVy8QkZQko3aDAWxN7YUK6DlbGoR78UhfBMfHYEN fKgc+9MmmsBOfV8AUULSgpSd+a1kqJrk9Tgdg4qt69USdiydrpb7QW6UjKhHOQn/ Cz0PmWkMijd/PP0cLXu5uiBSlfqBpozKZXRdntKUlS2VWR+iED5qV+T4/dyxk56j /D+WUuKGFCBTlhv83J3xUkMy50sMaf2Itt5ffpJNfBhPLc2n92W3ZAqFIYJcXf2q fgUSj9fGyYvtj+5zVrXKbXWUjz8MB3OV4q0mz1RErBSSx7qfqSrcHKELCEOjOKPp G59ayeTdoJJmkCiWh/gpBgp5hAlp8Q== =skf6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 23 09:58:14 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5560130DE4 for ; Thu, 23 Aug 2018 09:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPUrKzlZdkCq for ; Thu, 23 Aug 2018 09:58:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C36130E1F for ; Thu, 23 Aug 2018 09:58:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 17E4C20090; Thu, 23 Aug 2018 13:15:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 97BE81448; Thu, 23 Aug 2018 12:58:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 95BBB335; Thu, 23 Aug 2018 12:58:07 -0400 (EDT) From: Michael Richardson To: Esko Dijk cc: "anima\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] draft-ietf-anima-bootstrapping-keyinfra-16: example uses "prior-signed-voucher" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 16:58:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Esko Dijk wrote: > Minor review remark: example 2 uses "prior-signed-voucher" which shou= ld > be "prior-signed-voucher-request". Thanks, now at: https://github.com/anima-wg/anima-bootstrap/issues/72 In general, we will regenerate all examples during AUTH48 after all IANA actions. (I think some of them are already done in 8366 actually) > (I didn=E2=80=99t find a ticket system active for this draft; so subm= itting > this one directly to the list. I can collect further remarks in an > email and send at some later time.) it's on github, see above. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlt+558ACgkQgItw+93Q 3WWp7Af+LJWPduJQzbCClkKOQpUlLILEN2IUl8uyNNIqUxmzGdb8cP2QtxmQNr80 WYALUCMYuWJXKs/rnOkTgwEj+NrcNP3u8HwKrlYcZv4A8u3tkYcnXTfCCYmv9BIk AcmjuPyalO62pQC66qCBLLolWrfP8vhwK0K9ekNkN4PjqMwDKLb2+/8qFa2J/bNe FxiClJFToQ+HIufYLBymPCREbKeB3Sg84OpbJO5Qsdd7YFRB5l9LNwqop8yEtpR0 GsUvou8vG+zAqzd8aedDIB/GDi6x9+Zakh44ZCZqQf+SxOsbjLNKYsVEzfnZBwBT ZboVN3dIyryBYkMF/VfUVzeJPafMKQ== =foSb -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 24 07:57:37 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7D4130DC9; Fri, 24 Aug 2018 07:57:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <153512265053.23023.15070675941189274421@ietfa.amsl.com> Date: Fri, 24 Aug 2018 07:57:30 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 14:57:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : A Reference Model for Autonomic Networking Authors : Michael H. Behringer Brian Carpenter Toerless Eckert Laurent Ciavaglia Jeferson Campos Nobre Filename : draft-ietf-anima-reference-model-07.txt Pages : 30 Date : 2018-08-24 Abstract: This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-reference-model-07 https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 24 08:02:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59805130DC5 for ; Fri, 24 Aug 2018 08:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 3Gg8K_rgVZwj for ; Fri, 24 Aug 2018 08:02:04 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 C8A1B128CE4 for ; Fri, 24 Aug 2018 08:02:03 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id g33-v6so7750551wrd.1 for ; Fri, 24 Aug 2018 08:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=CN1f+nXx0j3OVjdITePZPh2WfmHfmYIYkbC6CRtxDXY=; b=QNn68XRISc4dJbXmJ7eh+jGySw1aJKb1vl2U21hDU/q00YiBCFwy1o8NwSJ866a6k2 6n7zxJ8gZ37zAloMOBTb2JJXc5Y1c0RF6Tyv6QYENVjsFBxqt6VZoIEwYLJ+tr0KiZwi XqQ+RbOwzi093X9MqMSs1FT6JucNwiOeNxMFy+WB0EylIiau9HIpw+BDQW+UqGPQ5xs2 RONOL2vZDoyS6XN4KvRQpXSE3HNBCWZpDrZLuDCFHKX1/ZLFx/jKc1bKU7ffVAyT6RgI s1AzDI+dIxyIVZZjfBt+YlMeKlfunXEEv8YPPVE/MBVSf4kCJwtE9ob8Es+qIKCqlYEw xT9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CN1f+nXx0j3OVjdITePZPh2WfmHfmYIYkbC6CRtxDXY=; b=aI2IsikaLapoLXqr0JuGAzVSnVqBfdSawluICQ+3HrIJRBHCKkn88lJWSR7fmf7sHf ywkfnlcK3jfEUJbQCPgr11+XRoL/RsTTT3l5H+2SqmDCRSGfEQDZU3Z9qgRFrxGngrFK SnvqpDN91rknfMeNThkqi2oFenileDuv5Xw2Q6tMoROgCXWxEsxmqdKJh/bYnmcu309I X8vKMHp1dAwJVRoZ/B7FaMAuzZ6PDX5SraxNVCU+MMr4IpqpPvjiM9/t6MFcumdCjVzV WaiXo6Y/4xsD36lh1OkIok31rfF0HiHvts72ixkkfnhTAaUSSNLm1KwlFT5zbROLBU93 aLGQ== X-Gm-Message-State: APzg51AnQ6Vr7v2w4bNn/wzPCmSjFfQJbIG2QYe9T2ctzIuHDvZEZo+S l9mgj22XOxlRxYRhJpx35Hp7GlVV X-Google-Smtp-Source: ANB0VdZuXig31NKrVISzwKBeD6S0VpIL+1hXthMbVKrYvBx/ZZKgyG+ChrsTrML9nC+HpY9bNkTHww== X-Received: by 2002:adf:f749:: with SMTP id z9-v6mr1478600wrp.85.1535122920523; Fri, 24 Aug 2018 08:02:00 -0700 (PDT) Received: from [192.168.1.21] (ANice-652-1-35-150.w90-57.abo.wanadoo.fr. [90.57.60.150]) by smtp.gmail.com with ESMTPSA id w204-v6sm1974931wmw.5.2018.08.24.08.01.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 08:01:59 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" References: <153512265053.23023.15070675941189274421@ietfa.amsl.com> To: "anima@ietf.org" X-Forwarded-Message-Id: <153512265053.23023.15070675941189274421@ietfa.amsl.com> Message-ID: <6135b773-009f-0a7d-1fda-d0c0edf8463e@gmail.com> Date: Fri, 24 Aug 2018 17:02:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153512265053.23023.15070675941189274421@ietfa.amsl.com> Content-Type: text/html; charset=windows-1252 Content-Language: fr-classic Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-ietf-anima-reference-model-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:02:05 -0000 This new version addresses all the comments received since the last call. It includes the SECDIR, GENART and OPSDIR reviews, but we're still awaiting the RTGDIR review.

Michael

-------- Forwarded Message --------
Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-07.txt
Date: Fri, 24 Aug 2018 07:57:30 -0700
From: internet-drafts@ietf.org
Reply-To: anima@ietf.org
To: i-d-announce@ietf.org
CC: anima@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.

        Title           : A Reference Model for Autonomic Networking
        Authors         : Michael H. Behringer
                          Brian Carpenter
                          Toerless Eckert
                          Laurent Ciavaglia
                          Jeferson Campos Nobre
	Filename        : draft-ietf-anima-reference-model-07.txt
	Pages           : 30
	Date            : 2018-08-24

Abstract:
   This document describes a reference model for Autonomic Networking
   for managed networks.  It defines the behaviour of an autonomic node,
   how the various elements in an autonomic context work together, and
   how autonomic services can use the infrastructure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-reference-model-07
https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
From nobody Sun Aug 26 09:03:38 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ECB130E33; Sun, 26 Aug 2018 09:03:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Christian Hopps To: Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153529941582.11902.1347468414499836311@ietfa.amsl.com> Date: Sun, 26 Aug 2018 09:03:35 -0700 Archived-At: Subject: [Anima] Rtgdir telechat review of draft-ietf-anima-reference-model-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 16:03:36 -0000 Reviewer: Christian Hopps Review result: Has Issues Subject: RtgDir review: draft-ietf-anima-reference-model-07.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-anima-reference-model-07.txt Reviewer: Christian E. Hopps Review Date: 2018-08-26 Intended Status: Informational Summary: I have a couple minor major concerns, and a couple minor concerns about this document that I think should be resolved before publication. I found the document very well written. Minor Major Issues: - Virtualization is mentioned once in "4.2 addressing" section. To quote: TEXT: "Support for virtualization: Autonomic Nodes may support Autonomic Service Agents in different virtual machines or containers. The addressing scheme should support this architecture." The special casing of VM/containers here seems to indicate that virtual devices are not "1st class citizens" in an autonomic network. In particular I could easily imagine virtual machines being full blown autonomic nodes themselves. Assuming the intent is not to restrict virtual devices in this manor something needs to be said (somewhere) to make that clear. - Robust programming techniques. I think the intention here is to say that the design of ASAs must have robustness as a top design principle. I think in doing that it should talk about what being robust means; however, it should not be talking about how to accomplish that as there are multiple ways to achieve this goal. In particular I feel saying that restarting is the *last* thing an ASA should do is way overreaching into engineering the solution rather than specifying the requirement. Indeed plenty of people think that overly complex recovery mechanisms that try everything under the sun to *not* restart often have more bugs and are less robust than KISS solutions that "fail" simply but recover quickly with minimal or no disruption. I feel this section reads a bit more like someones idea of how to design a robust system instead of talking about what robust means which is the intent I believe. Perhaps better is just to focus on robust design ideas (some are already stated in the text): - must deal with discovery and negotiation failure as routine. - recovering from failures should be minimally disruptive. - must not leak resources. - must monitor for and deal with hung code. - must include security analysis - 7.4: When text talks about feedback loop, it mentions "allow the intervention" of human admin or control system; however, it then describes the feedback loop as presenting default actions and allowing for override. This is fine, but it seems to leave out the common case where something is misbehaving and would not be presenting any choices to the administrator (using the feedback loop), so the admin must forcefully intervene. Minor Issues: - 6.1 TEXT: "It must be possible to run ASAs as non-privileged (user space) processes except for those (such as the infrastructure ASAs) that necessarily require kernel privilege. Also, it is highly desirable that ASAs can be dynamically loaded on a running node." ISSUE: Discussing implementation details like user-space, kernel privilege and dynamic loading seems unnecessary and outside the scope of this document. Does this document care if I implement my ASA on a real-time architecture with no "user space" etc..? - 4.6 Why call out global routing and overlay networks in particular? Is the real intention to just say that the ACP implementation is not restricted to any specific type of networking? - TEXT: 6.3.1.2 "on a given LAN" NIT: Everyone knows what a LAN is; however, I wonder if the text should be more generic and actually describe what it really requires here which is a broadcast or multicast network? Questions/Comments: - QUESTION: IoT and node requirements. There a couple node ASA requirements. I found myself wondering if a very simple IoT things like thermostats might ever be an AN and if so did they all really need to have joining assistent ASAs? It could be that the answer is "Yes, they do or they can't be nodes". I was just curious. - COMMENT: For the types of ASAs: simple (run anywhere), complex (resource restricted), and infra (run everywhere), I was reminded of Kubernetes/cloud orchestration, and the concept of DaemonSets (pods that run everywhere) and Deployments (pods that can run anywhere, possibly be scaled replicated, and may also have requirements that restrict where they can run). I imagine that folks in Anima have also looked at this, but if not it would be good to as they seem to be solving very similar problems. Nits: - TEXT: 3.2 "However, the information is tracked independently of the status of the peer nodes; specifically, it contains information about non-enrolled nodes, nodes of the same and other domains. " QUESTION: What are peer nodes? Is this another name for adjacent nodes? If so "s/peer/adjacent/". - TEXT: 3.3.1 "enrols" CHANGE: "enrolls" - TEXT: 3.3.3 "In this state, the autonomic node has at least one ACP channel to another device. It can participate in further autonomic transactions, such as starting autonomic service agents. For example it must now enable the join assistant ASA, to help other devices to join the domain. NIT: "For example foo" is not a sentence on it's own, also "It" is not a good subject as there are multiple nouns in the previous sentence that could serve as antecedents. SUGGEST: 3.3.3 "In this state, the autonomic node has at least one ACP channel to another device. The node can now participate in further autonomic transactions, such as starting autonomic service agents (e.g., it must now enable the join assistant ASA, to help other devices to join the domain). - TEXT: 4.1 "Names are typically assigned by a Registrar at bootstrap time and persistent over the lifetime of the device." NIT: s/persistent/and persist/ - TEXT: "Out of scope are addressing approaches for the data plane of the network, which may be configured and managed in the traditional way, or negotiated as a service of an ASA. One use case for such an autonomic function is described in [I-D.ietf-anima-prefix-management]." - NIT: Sounds sort of Yoda-like, and the compounding makes things less clear. SUGGEST: "Addressing approaches for the data plane of the network are outside the scope of this document. These addressing approaches may be configured and managed in the traditional way, or negotiated as a service of an ASA. One use case for such an autonomic function is described in [I-D.ietf-anima-prefix-management]." - TEXT: 6.1: "Following an initial discovery phase, the device properties and those of its neighbors are the foundation of the behavior of a specific device. A device and its ASAs have no pre-configuration for the particular network in which they are installed." NIT: Why suddenly lose the "node" abstraction and start talking about devices here? I think it continues to work well to say "node" (e.g., "node properties", "specific node" and "A node and its ASAs..."). - TEXT: 6.2 "install ASA: copy the ASA code onto the host and start it," NIT: "s/host/node/" From nobody Sun Aug 26 13:58:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0FE130E0C; Sun, 26 Aug 2018 13:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SepqsZ4bNfeT; Sun, 26 Aug 2018 13:57:58 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 18058130E26; Sun, 26 Aug 2018 13:57:58 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id e11-v6so3215657plb.3; Sun, 26 Aug 2018 13:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NpJsZU7Le1DGtoo9J1qscuLqNiygT8ZCEuvq6POmosg=; b=rOSDileS+sNywBNPQOqHC2+RbtVnMA0VJuFklQjbUB7AE1+SvgOOc1Pn3r8hafb4BQ KhCOkWR907XUdIl4gWD4Heq8zfDbfhg5fCZV/hLCqsbTkR9VkFMj0iZhzugRG6yvN1OX X/fUYyGJojlAwuCSdmEqd3/YmBDF71UpPlk7tpZIjzox2jWlueatPuDDROxzEQRZ+QPL ybeYxL+pJmVXXIhiBYkqVuBgnU9z2ui7iTQOt9eh6mulf8/aXLxu18qfs5qzA0ykRdrZ 8Hamnj5IBTfaFR4im7giCMMMoOY+0wemAogQpbET95JPv38AZVDZDCxy/d3jf+/ZM/8g EMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NpJsZU7Le1DGtoo9J1qscuLqNiygT8ZCEuvq6POmosg=; b=jqzqKSRQJ+PDwqLFTzhfPO4vuIdmSux2mjKzGm7857mlXzKlZsJn4vnFlXBJyqYoAM c0kgr/YWa2RgQ2DccCBeHnmx0n8RYN9cJFAGwDviwKeThPbRJLDy5z3RIeuE/jpLKaT+ Vzhl+cPrXDORXFkYjhKqfUNCmAt2sJLU9Gd5cqGkCZpKo6EknFh1NwJpCOwea7FLgtxM KJBYDjGoyCNC8N9eQusBYNzQ12TkcjxvkE+E/8rP4PccmHCU/CVSjj3HfzfRNZHYLkSi uhBAxuamlYIt+N7DiA6dOWJEOPCEJflquPiku70rETm4VPLDC80GyR5aXTKAoCAQTiuA R+GQ== X-Gm-Message-State: APzg51Dr4EhViV6y8/WehFWlnJDu+RaOb2UTVGdhkkaQkIJZ+DyobFBs ZPzETGRC/j+0C5vLK0+c2AZvUMW6 X-Google-Smtp-Source: ANB0VdY9EM1IYdNOEzJ9ETdv3xFR/taKwPdXE2id9fPQZCUoxZoMcVbXkr7h0BRxuuhi7IwgtHTEng== X-Received: by 2002:a17:902:b20d:: with SMTP id t13-v6mr10611328plr.107.1535317077334; Sun, 26 Aug 2018 13:57:57 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id r81-v6sm18581523pfa.18.2018.08.26.13.57.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Aug 2018 13:57:56 -0700 (PDT) To: Christian Hopps , rtg-dir@ietf.org Cc: anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153529941582.11902.1347468414499836311@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <6288ec99-fbf6-e2e0-32c3-e402c19fdecd@gmail.com> Date: Mon, 27 Aug 2018 08:57:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153529941582.11902.1347468414499836311@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-reference-model-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 20:58:01 -0000 (Ccs trimmed) Christian, Thanks for this careful review. I'll comment here on the larger issues: On 2018-08-27 04:03, Christian Hopps wrote: ... > Minor Major Issues: > > - Virtualization is mentioned once in "4.2 addressing" section. To quote: > > TEXT: "Support for virtualization: Autonomic Nodes may support Autonomic > Service Agents in different virtual machines or containers. The addressing > scheme should support this architecture." > > The special casing of VM/containers here seems to indicate that virtual > devices are not "1st class citizens" in an autonomic network. In particular I > could easily imagine virtual machines being full blown autonomic nodes > themselves. Assuming the intent is not to restrict virtual devices in this > manor something needs to be said (somewhere) to make that clear. I don't think that was the intention. We haven't really explored this in detail, but I can certainly imagine a deployment (for example) where each tenant in a data centre has its own virtual autonomic network, and the underlying physical network is also autonomic. Since the ACP is expected to be implemented as a VRF, you could even argue that every autonomic network is virtual. So, yes, we can reword this. > > - Robust programming techniques. I think the intention here is to say that the > design of ASAs must have robustness as a top design principle. I think in > doing that it should talk about what being robust means; however, it should > not be talking about how to accomplish that as there are multiple ways to > achieve this goal. > > In particular I feel saying that restarting is the *last* thing an ASA should > do is way overreaching into engineering the solution rather than specifying > the requirement. Indeed plenty of people think that overly complex recovery > mechanisms that try everything under the sun to *not* restart often have more > bugs and are less robust than KISS solutions that "fail" simply but recover > quickly with minimal or no disruption. > > I feel this section reads a bit more like someones idea of how to design a > robust system instead of talking about what robust means which is the intent I > believe. > > Perhaps better is just to focus on robust design ideas (some are already > stated in the text): > > - must deal with discovery and negotiation failure as routine. > - recovering from failures should be minimally disruptive. > - must not leak resources. > - must monitor for and deal with hung code. > - must include security analysis OK. Since I drafted that text, I will leave the document editor to fix it. (Some of the detail probably belongs in another draft specifically about ASAs, which I am editing.) > > - 7.4: When text talks about feedback loop, it mentions "allow the intervention" > of human admin or control system; however, it then describes the feedback loop > as presenting default actions and allowing for override. This is fine, but it > seems to leave out the common case where something is misbehaving and would > not be presenting any choices to the administrator (using the feedback loop), > so the admin must forcefully intervene. Yes. I think the word "feedback" is a bad choice. For engineers raised on Nyquist diagrams it is part of a closed loop; for other people it means feedback to humans. The text needs clarifying. > > Minor Issues: > > - 6.1 TEXT: "It must be possible to run ASAs as non-privileged (user space) > processes except for those (such as the infrastructure ASAs) that necessarily > require kernel privilege. Also, it is highly desirable that ASAs can be > dynamically loaded on a running node." > > ISSUE: Discussing implementation details like user-space, kernel privilege and > dynamic loading seems unnecessary and outside the scope of this document. Does > this document care if I implement my ASA on a real-time architecture with no > "user space" etc..? Fair enough. See my above comment re robustness. I'll leave the rest of your comments to the document editor. Regards Brian > > - 4.6 Why call out global routing and overlay networks in particular? Is the > real intention to just say that the ACP implementation is not restricted to > any specific type of networking? > > - TEXT: 6.3.1.2 "on a given LAN" > > NIT: Everyone knows what a LAN is; however, I wonder if the text should be > more generic and actually describe what it really requires here which is a > broadcast or multicast network? > > Questions/Comments: > > - QUESTION: IoT and node requirements. There a couple node ASA requirements. I > found myself wondering if a very simple IoT things like thermostats might ever > be an AN and if so did they all really need to have joining assistent ASAs? It > could be that the answer is "Yes, they do or they can't be nodes". I was just > curious. > > - COMMENT: For the types of ASAs: simple (run anywhere), complex (resource > restricted), and infra (run everywhere), I was reminded of Kubernetes/cloud > orchestration, and the concept of DaemonSets (pods that run everywhere) and > Deployments (pods that can run anywhere, possibly be scaled replicated, and > may also have requirements that restrict where they can run). I imagine that > folks in Anima have also looked at this, but if not it would be good to as > they seem to be solving very similar problems. > > Nits: > > - TEXT: 3.2 "However, the information is tracked independently of the status of > the peer nodes; specifically, it contains information about non-enrolled > nodes, nodes of the same and other domains. " > > QUESTION: What are peer nodes? Is this another name for adjacent nodes? If so > "s/peer/adjacent/". > > - TEXT: 3.3.1 "enrols" > CHANGE: "enrolls" > > - TEXT: 3.3.3 "In this state, the autonomic node has at least one ACP channel to > another device. It can participate in further autonomic transactions, such as > starting autonomic service agents. For example it must now enable the join > assistant ASA, to help other devices to join the domain. > > NIT: "For example foo" is not a sentence on it's own, also "It" is not a good > subject as there are multiple nouns in the previous sentence that could serve > as antecedents. > > SUGGEST: 3.3.3 "In this state, the autonomic node has at least one ACP channel > to another device. The node can now participate in further autonomic > transactions, such as starting autonomic service agents (e.g., it must now > enable the join assistant ASA, to help other devices to join the domain). > > - TEXT: 4.1 "Names are typically assigned by a Registrar at bootstrap time and > persistent over the lifetime of the device." > > NIT: s/persistent/and persist/ > > - TEXT: "Out of scope are addressing approaches for the data plane of the > network, which may be configured and managed in the traditional way, or > negotiated as a service of an ASA. One use case for such an autonomic function > is described in [I-D.ietf-anima-prefix-management]." > > - NIT: Sounds sort of Yoda-like, and the compounding makes things less clear. > > SUGGEST: "Addressing approaches for the data plane of the network are outside > the scope of this document. These addressing approaches may be configured and > managed in the traditional way, or negotiated as a service of an ASA. One use > case for such an autonomic function is described in > [I-D.ietf-anima-prefix-management]." > > - TEXT: 6.1: "Following an initial discovery phase, the device properties and > those of its neighbors are the foundation of the behavior of a specific > device. A device and its ASAs have no pre-configuration for the particular > network in which they are installed." > > NIT: Why suddenly lose the "node" abstraction and start talking about devices > here? I think it continues to work well to say "node" (e.g., "node > properties", "specific node" and "A node and its ASAs..."). > > - TEXT: 6.2 "install ASA: copy the ASA code onto the host and start it," > NIT: "s/host/node/" > > > From nobody Tue Aug 28 08:43:30 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68924130DE7; Tue, 28 Aug 2018 08:43:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <153547100836.23688.13227492495790994622@ietfa.amsl.com> Date: Tue, 28 Aug 2018 08:43:28 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 15:43:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Constrained Voucher Artifacts for Bootstrapping Protocols Authors : Michael Richardson Peter van der Stok Panos Kampanakis Filename : draft-ietf-anima-constrained-voucher-01.txt Pages : 24 Date : 2018-08-28 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported in the [I-D.ietf-ace-coap-est] protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-01 https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 28 08:51:24 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F51130DF7 for ; Tue, 28 Aug 2018 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPJZW2boVQpi for ; Tue, 28 Aug 2018 08:51:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF033130DE6 for ; Tue, 28 Aug 2018 08:51:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EE6120491 for ; Tue, 28 Aug 2018 12:09:25 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5A2E91A49; Tue, 28 Aug 2018 11:51:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 56D94B37 for ; Tue, 28 Aug 2018 11:51:18 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <153547100859.23688.7359339053163149840.idtracker@ietfa.amsl.com> References: <153547100859.23688.7359339053163149840.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] New Version Notification for draft-ietf-anima-constrained-voucher-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 15:51:22 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-anima-constrained-voucher-01.txt > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-01 We have some issues with the .sid generation in this version, but we will be fixing them. We also have an issue with the YANG file, we need to mark the pinned-domain-cert as optional in our augment. It's not clear if we can do that legally when 8366 marks it mandatory. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluFb3YACgkQgItw+93Q 3WXQbQf/TIC7CyhOqDhyC0/0O6cu87WAtXGfQ4IQvqPC+6ivgToVXy9xuXm75nfX xypTYkv5jsfHUzuHY3XYaua1/upQ6wLSwCnU5dzhhsPfDAI1gLUpAShxGtIMh8P8 xlPCf2qiApwRdOcxoCMNRWZaOim1H8k+8u8eEUVninjongovpztS5biH6QKw8Ko2 XN8ci/0gznEMsVcc3tYC9c/+0vKNdoZa/Aiw7D3T9ZtKutnXk1+OG7SLzoLTiA9s uGEFilbMI3z3KVAxudXhA64P2TG6iI4ClpyYgSxPm+qHXJ0A0YVtVjXwE0UuDn+a dud7eZ8QkLUzuQcex4re2uaGnELXbQ== =wdKc -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 29 03:39:39 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EEA12F1A5; Wed, 29 Aug 2018 03:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r92li7yI7sMx; Wed, 29 Aug 2018 03:39:29 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 A507712F18C; Wed, 29 Aug 2018 03:39:28 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id u12-v6so4323978wrr.4; Wed, 29 Aug 2018 03:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=umVV9hR63tMODfuD9bb4DLVDxWXt/z9fS6ohNZRBI0E=; b=BeP31g5VVp5Vi7VqarkKp6omSBWXGMoGQh1lXlvL9UxUR1JkA4lnerLx0adCPl43w3 cNPy+H0PtOTX+DpEKdhes5MreRHKSn8CGKP2vzMG3515p8lkxJX+g5vS6MCM5XEqroiH aY9q92uTQFAD4xFpIhjqN0fICEYSGyY6a/GyASjL7L4TBcIGjLouWRKs9CjiOPUoqbJ/ q+r34skMNZ3v5D1mQ1FEzN/rPe9lrKOc39Dy8my1bd+/SlSS0FTFwsgkBqqoF7aPtmf1 eNOHYWhYKLdPdz5ldM9SCMQzCcNVzwXz9G74Z1em1mnIj5PGJy8vwh+yfS/08Sw224i8 YrLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=umVV9hR63tMODfuD9bb4DLVDxWXt/z9fS6ohNZRBI0E=; b=kazOFVjt4M7KsNP04OHHvYXlbEMubQGFFsMDFylUtdPH7cKA75TdYT5zp2PyX/F7yW CU9qoU1fJLbBMuPG0XbazZYDsyjKHXzg7m9eTRYES8ohRrXeqqma107wFZD7FTb3VijU mQ5BDp9DwwLq/E+msgnTWpYeJmPlZinEypCS5CBe2dvXPHzbgjulvoeDdz9UTbDWaQPM 0lKba4Dj8txpHiioiY+rMyGx2C2ppQ282d/BZ8huIe/2YvcINP8kGGGRifLqsGUWcjyP eXrCyoNzWLp2O08W/w8Zt0RWjJQxNB8zVjUfkJddpsSXLOQRC06n/kF74rwBEhT2PtqS dy4g== X-Gm-Message-State: APzg51DaX+20HoULlJmx++mmdRiEjd55hUW5mlIg455/oVerG3xzfSxn o8e6gccOWg2HBY8BhirKr5mkxmbB X-Google-Smtp-Source: ANB0VdbgEGEEIP/Ye9cgTbHQ6A5ftACfbA+JuefsewoVvynMn2IQy/UQPVvh129gOmwQSMiBi76keg== X-Received: by 2002:a5d:4e8b:: with SMTP id e11-v6mr4126104wru.32.1535539166822; Wed, 29 Aug 2018 03:39:26 -0700 (PDT) Received: from [192.168.1.21] (ANice-652-1-20-67.w83-201.abo.wanadoo.fr. [83.201.31.67]) by smtp.gmail.com with ESMTPSA id f17-v6sm2968651wrs.1.2018.08.29.03.39.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 03:39:26 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Brian E Carpenter , Christian Hopps , rtg-dir@ietf.org Cc: anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153529941582.11902.1347468414499836311@ietfa.amsl.com> <6288ec99-fbf6-e2e0-32c3-e402c19fdecd@gmail.com> Message-ID: <82183cb3-eefc-a22c-dcfa-d412733d933b@gmail.com> Date: Wed, 29 Aug 2018 12:39:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6288ec99-fbf6-e2e0-32c3-e402c19fdecd@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-reference-model-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 10:39:31 -0000 Christian, thanks for the review, my comments inline... On 26/08/2018 22:57, Brian E Carpenter wrote: > (Ccs trimmed) > > Christian, > > Thanks for this careful review. I'll comment here on the larger issues: > > On 2018-08-27 04:03, Christian Hopps wrote: > ... >> Minor Major Issues: >> >> - Virtualization is mentioned once in "4.2 addressing" section. To quote: >> >> TEXT: "Support for virtualization: Autonomic Nodes may support Autonomic >> Service Agents in different virtual machines or containers. The addressing >> scheme should support this architecture." >> >> The special casing of VM/containers here seems to indicate that virtual >> devices are not "1st class citizens" in an autonomic network. In particular I >> could easily imagine virtual machines being full blown autonomic nodes >> themselves. Assuming the intent is not to restrict virtual devices in this >> manor something needs to be said (somewhere) to make that clear. > I don't think that was the intention. We haven't really explored this in detail, > but I can certainly imagine a deployment (for example) where each tenant in > a data centre has its own virtual autonomic network, and the underlying physical > network is also autonomic. Since the ACP is expected to be implemented as > a VRF, you could even argue that every autonomic network is virtual. > > So, yes, we can reword this. To add to Brian: I agree there was no intention to "downgrade" virtualization. Nor am I aware of any text that indicates that, also not what you quote above. We didn't mean this to say "this is not recommended", only "we haven't explored / documented that further". I am convinced that the Autonomic architecture will be all over data centers one day, so OBVIOUSLY virtualization is important. Happy to re-word, but: What do you suggest we change / add? I'm really not clear... > >> - Robust programming techniques. I think the intention here is to say that the >> design of ASAs must have robustness as a top design principle. I think in >> doing that it should talk about what being robust means; however, it should >> not be talking about how to accomplish that as there are multiple ways to >> achieve this goal. >> >> In particular I feel saying that restarting is the *last* thing an ASA should >> do is way overreaching into engineering the solution rather than specifying >> the requirement. Indeed plenty of people think that overly complex recovery >> mechanisms that try everything under the sun to *not* restart often have more >> bugs and are less robust than KISS solutions that "fail" simply but recover >> quickly with minimal or no disruption. >> >> I feel this section reads a bit more like someones idea of how to design a >> robust system instead of talking about what robust means which is the intent I >> believe. >> >> Perhaps better is just to focus on robust design ideas (some are already >> stated in the text): >> >> - must deal with discovery and negotiation failure as routine. >> - recovering from failures should be minimally disruptive. >> - must not leak resources. >> - must monitor for and deal with hung code. >> - must include security analysis > OK. Since I drafted that text, I will leave the document editor to fix > it. (Some of the detail probably belongs in another draft specifically > about ASAs, which I am editing.) Brian: Haha, that's called "passing on the ball" I believe... :-) Christian: With your input above, I suggest to reword that paragraph to: Since autonomic systems must be self-repairing, it is of great importance that ASAs are coded using robust programming techniques. All run-time error conditions must be caught, leading to suitable >>> minimally disruptive <<< recovery actions, >>> also considering a complete restart of the ASA.<<< The other bullets are covered in the text. > >> - 7.4: When text talks about feedback loop, it mentions "allow the intervention" >> of human admin or control system; however, it then describes the feedback loop >> as presenting default actions and allowing for override. This is fine, but it >> seems to leave out the common case where something is misbehaving and would >> not be presenting any choices to the administrator (using the feedback loop), >> so the admin must forcefully intervene. > Yes. I think the word "feedback" is a bad choice. For engineers raised on > Nyquist diagrams it is part of a closed loop; for other people it means > feedback to humans. The text needs clarifying. Christian: Right. I think this may be clearer when we distinguish (more explicitly than is the case now) that there are two different systems involving the NOC: 1 - a closed loop, called feedback loop at the moment. 2 - a unidirectional error message. 1 works like this: Node detects abnormal condition, informs NOC "here is what I see, I will take recovery X at time Y to resolve this". The NOC can then do nothing, or override this action. 2 is a simple report, with no suggestion what to do, and no default recovery action. It's the NOC engineer's job to figure out what to do. I think this is the "common case" you refer to. Put differently: A loop as in (1) REQUIRES some form of reaction by the node, otherwise it doesn't belong here. Secion 7.4 intents to cover case 1 only. In my mind, case 2 is like current notification mechanisms (syslog etc), part of "traditional management", thus not covered in this draft. So maybe the solution is to point out what I say above: If there is no autonomic recovery option ("not presenting any choices" in your text), it falls into the traditional, non-autonomic scenario. And the draft is clear that such traditional mechanisms will co-exist for a long time still. Proposal: "    Feedback loops are required in an autonomic network to allow the    intervention of a human administrator or central control systems,    while maintaining a default behaviour.  Through a feedback loop an    administrator ***must*** be prompted with a default action, and has the    possibility to acknowledge or override the proposed default action.    *** Uni-directional notifications to the NOC, that do not propose    any default action, and do not allow an override as part of the transaction    are considered like traditional notification services, such as syslog. They    are expected to co-exist with autonomic methods, but are not covered in    this draft. " Would that be clear? > >> Minor Issues: >> >> - 6.1 TEXT: "It must be possible to run ASAs as non-privileged (user space) >> processes except for those (such as the infrastructure ASAs) that necessarily >> require kernel privilege. Also, it is highly desirable that ASAs can be >> dynamically loaded on a running node." >> >> ISSUE: Discussing implementation details like user-space, kernel privilege and >> dynamic loading seems unnecessary and outside the scope of this document. Does >> this document care if I implement my ASA on a real-time architecture with no >> "user space" etc..? > Fair enough. See my above comment re robustness. I see where you're coming from, and sort of agree, and don't :-) Formally you're absolutely right, implementation details don't belong here. However, we had a large number of exchanges on user vs kernel space, which had design consequences. I feel it would be useful to leave this point in the document. > > I'll leave the rest of your comments to the document editor. > > Regards > Brian > >> - 4.6 Why call out global routing and overlay networks in particular? Is the >> real intention to just say that the ACP implementation is not restricted to >> any specific type of networking? I see that this can cause confusion. It also dates back to a looong discussion on what the ACP should look like. Frankly, I think we have all converged on the overlay model. So while the global routing table model is theoretically an option, we should probably drop it here. Suggestion: "    The "Autonomic Control Plane" carries the control protocols in an    autonomic network.  In the architecture described here, it is implemented    as an overlay network.  The document "An    Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane])    describes the implementation details suggested here.  See    [I-D.ietf-anima-stable-connectivity] for uses cases for the ACP. " >> >> - TEXT: 6.3.1.2 "on a given LAN" >> >> NIT: Everyone knows what a LAN is; however, I wonder if the text should be >> more generic and actually describe what it really requires here which is a >> broadcast or multicast network? replace with "... on a given broadcast or multicast network." OK? >> >> Questions/Comments: >> >> - QUESTION: IoT and node requirements. There a couple node ASA requirements. I >> found myself wondering if a very simple IoT things like thermostats might ever >> be an AN and if so did they all really need to have joining assistent ASAs? It >> could be that the answer is "Yes, they do or they can't be nodes". I was just >> curious. We had that discussion a lot. 3.1 states that "At a later stage    ANIMA may define a scope for constrained nodes with a reduced ANI and    well-defined minimal functionality.  They are currently out of scope." All sorts of things may happen: You may have devices that are hard-coded to run in a domain, so they don't need to join (very specific cases only, IMO). Or they have a SIM card (or similar), and don't need enrolment (much more likely to happen). Many more... :-) >> >> - COMMENT: For the types of ASAs: simple (run anywhere), complex (resource >> restricted), and infra (run everywhere), I was reminded of Kubernetes/cloud >> orchestration, and the concept of DaemonSets (pods that run everywhere) and >> Deployments (pods that can run anywhere, possibly be scaled replicated, and >> may also have requirements that restrict where they can run). I imagine that >> folks in Anima have also looked at this, but if not it would be good to as >> they seem to be solving very similar problems. Will do! Good point! >> Nits: >> >> - TEXT: 3.2 "However, the information is tracked independently of the status of >> the peer nodes; specifically, it contains information about non-enrolled >> nodes, nodes of the same and other domains. " >> >> QUESTION: What are peer nodes? Is this another name for adjacent nodes? If so >> "s/peer/adjacent/". We need to keep "peer" here. The adjacency table may have peers that are not adjacent. >> >> - TEXT: 3.3.1 "enrols" >> CHANGE: "enrolls" Being a non-native English speaker, I believe this is US vs GB English, and I leave others to sort that :-) >> - TEXT: 3.3.3 "In this state, the autonomic node has at least one ACP channel to >> another device. It can participate in further autonomic transactions, such as >> starting autonomic service agents. For example it must now enable the join >> assistant ASA, to help other devices to join the domain. >> >> NIT: "For example foo" is not a sentence on it's own, also "It" is not a good >> subject as there are multiple nouns in the previous sentence that could serve >> as antecedents. >> >> SUGGEST: 3.3.3 "In this state, the autonomic node has at least one ACP channel >> to another device. The node can now participate in further autonomic >> transactions, such as starting autonomic service agents (e.g., it must now >> enable the join assistant ASA, to help other devices to join the domain). Will do, thanks. >> >> - TEXT: 4.1 "Names are typically assigned by a Registrar at bootstrap time and >> persistent over the lifetime of the device." >> >> NIT: s/persistent/and persist/ I leave that to the RFC Editor to decide. To me our version is not wrong... Again, not native .... >> >> - TEXT: "Out of scope are addressing approaches for the data plane of the >> network, which may be configured and managed in the traditional way, or >> negotiated as a service of an ASA. One use case for such an autonomic function >> is described in [I-D.ietf-anima-prefix-management]." >> >> - NIT: Sounds sort of Yoda-like, and the compounding makes things less clear. Yoda I like! :-) >> SUGGEST: "Addressing approaches for the data plane of the network are outside >> the scope of this document. These addressing approaches may be configured and >> managed in the traditional way, or negotiated as a service of an ASA. One use >> case for such an autonomic function is described in >> [I-D.ietf-anima-prefix-management]." Will change. >> >> - TEXT: 6.1: "Following an initial discovery phase, the device properties and >> those of its neighbors are the foundation of the behavior of a specific >> device. A device and its ASAs have no pre-configuration for the particular >> network in which they are installed." >> >> NIT: Why suddenly lose the "node" abstraction and start talking about devices >> here? I think it continues to work well to say "node" (e.g., "node >> properties", "specific node" and "A node and its ASAs..."). OK, will change to "node" - you're right. >> >> - TEXT: 6.2 "install ASA: copy the ASA code onto the host and start it," >> NIT: "s/host/node/" >> OK. Thanks for the thorough review Christian! I wait if anyone has an issue with thos suggestions, and if not, edit the draft accordingly. thanks! Michael From nobody Wed Aug 29 19:06:17 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB75712DD85; Wed, 29 Aug 2018 19:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-Qw24M94rVg; Wed, 29 Aug 2018 19:06:13 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 6595A12426A; Wed, 29 Aug 2018 19:06:13 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id r1-v6so3146960pgp.11; Wed, 29 Aug 2018 19:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G+Xvozs8dBqcn3K3nLfZncelPChsNWMHiPW5Ua0tc/E=; b=aRW8yijknBJEwsrK540KpDoJGWbyNFIc5D+X+UjaDxaV8sCE+ML70JFF8tc47+FkS2 k2VzwksVEaDbWK9/I3kCLUzAu4FGG2awBgDHRfa9Q7rZ9k/ZCoIysoc0pZ/Fc3p0OB74 KALmDcdbKOciGn0qoy+c1IDBRr03axsbuwy93vr+pauCUxS4sVJVVBR8vW+iCcNNbsrU elAukCHEd0LuOxDcjffsm5rGBNmJmhlcFphoEdIdDiuLZcYw/YMU5vtLV2o1W+KzdxcQ rKfWW1BVvhipaXaKqLWN1vL5L46qWAbXHQyVW4KHZ6yqRwwA4VE3e56QTjjry7pAXkrR S8OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G+Xvozs8dBqcn3K3nLfZncelPChsNWMHiPW5Ua0tc/E=; b=HcwcAsi9PYAorkA+DSTdWJlCUfXxAf6ACFP36k0KX61F3Y9olHoATmt7aEt9BinbVK UhRe9eFNHK0m9iqq/27OCTA89Td5nOF17USq8vIr06YphUbV6LPpAl1I02OF9XclD1hf RGxv6BlgEjbKCwsYi8B4BoNJb6ASPSiVvBcXNHh8fXzEzmrhBOo9WG24SDk95PPAQB7k +ZarCLTYz1uP2ACPV+Q9DCygTVbAdQFjW6kfoRVdHqzCi7DpfyCRaRkZcilK7E6Pf5Eq FNkdwKfOOZeE8WA6/7EAxw6PfUpSZi9dxuF+hBwDtSChFNigPlpV4LjubX91szVv+uIF assA== X-Gm-Message-State: APzg51C4uZ5UI4WAlUvUhfpaqojkYIRcyy9vJlJ2ynt5bbrHDm6OkMFd 5Umc+It9DB0Gz+isPoI0RKfT/zLV X-Google-Smtp-Source: ANB0VdaFmCuJC+0Q9yQ5tW3pLVcS++Ola5BHk24KGSy4WedMr/e3C/qY1kSRsgGkoQCOkSg0AfA+eQ== X-Received: by 2002:a63:2a0b:: with SMTP id q11-v6mr7630305pgq.36.1535594772585; Wed, 29 Aug 2018 19:06:12 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id u43-v6sm10362361pgn.81.2018.08.29.19.06.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 19:06:11 -0700 (PDT) To: "Michael H. Behringer" , Christian Hopps , rtg-dir@ietf.org Cc: anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153529941582.11902.1347468414499836311@ietfa.amsl.com> <6288ec99-fbf6-e2e0-32c3-e402c19fdecd@gmail.com> <82183cb3-eefc-a22c-dcfa-d412733d933b@gmail.com> From: Brian E Carpenter Message-ID: <0bb46db0-24f4-5396-9180-2adf20186233@gmail.com> Date: Thu, 30 Aug 2018 14:06:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <82183cb3-eefc-a22c-dcfa-d412733d933b@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-reference-model-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 02:06:16 -0000 On 2018-08-29 22:39, Michael H. Behringer wrote: > Christian, thanks for the review, my comments inline... >=20 > On 26/08/2018 22:57, Brian E Carpenter wrote: >> (Ccs trimmed) >> >> Christian, >> >> Thanks for this careful review. I'll comment here on the larger issues= : >> >> On 2018-08-27 04:03, Christian Hopps wrote: >> ... >>> Minor Major Issues: >>> >>> - Virtualization is mentioned once in "4.2 addressing" section. To qu= ote: >>> >>> TEXT: "Support for virtualization: Autonomic Nodes may support Aut= onomic >>> Service Agents in different virtual machines or containers. The ad= dressing >>> scheme should support this architecture." >>> >>> The special casing of VM/containers here seems to indicate that vi= rtual >>> devices are not "1st class citizens" in an autonomic network. In p= articular I >>> could easily imagine virtual machines being full blown autonomic n= odes >>> themselves. Assuming the intent is not to restrict virtual devices= in this >>> manor something needs to be said (somewhere) to make that clear. >> I don't think that was the intention. We haven't really explored this = in detail, >> but I can certainly imagine a deployment (for example) where each tena= nt in >> a data centre has its own virtual autonomic network, and the underlyin= g physical >> network is also autonomic. Since the ACP is expected to be implemented= as >> a VRF, you could even argue that every autonomic network is virtual. >> >> So, yes, we can reword this. >=20 > To add to Brian: I agree there was no intention to "downgrade"=20 > virtualization. Nor am I aware of any text that indicates that, also no= t=20 > what you quote above. We didn't mean this to say "this is not=20 > recommended", only "we haven't explored / documented that further". I a= m=20 > convinced that the Autonomic architecture will be all over data centers= =20 > one day, so OBVIOUSLY virtualization is important. >=20 > Happy to re-word, but: What do you suggest we change / add? I'm really = > not clear... A modest suggestion, on the basis that if Christian read the text differe= ntly from the authors' intentions, other people might do so as well. Support for virtualization: Autonomic functions can exist either at the level of the physical network and physical devices, or at the level of virtual machines, containers and networks. In particular, Autonomic Nodes may support Autonomic Service Agents in virtual entities. The infrastructure, including the addressing scheme, should be able to support this architecture. (Comment: it isn't just addressing. There are software design implications too, but that is out of scope here, I think.) >>> - Robust programming techniques. I think the intention here is to say= that the >>> design of ASAs must have robustness as a top design principle. I t= hink in >>> doing that it should talk about what being robust means; however, = it should >>> not be talking about how to accomplish that as there are multiple = ways to >>> achieve this goal. >>> >>> In particular I feel saying that restarting is the *last* thing an= ASA should >>> do is way overreaching into engineering the solution rather than s= pecifying >>> the requirement. Indeed plenty of people think that overly complex= recovery >>> mechanisms that try everything under the sun to *not* restart ofte= n have more >>> bugs and are less robust than KISS solutions that "fail" simply bu= t recover >>> quickly with minimal or no disruption. >>> >>> I feel this section reads a bit more like someones idea of how to = design a >>> robust system instead of talking about what robust means which is = the intent I >>> believe. >>> >>> Perhaps better is just to focus on robust design ideas (some are a= lready >>> stated in the text): >>> >>> - must deal with discovery and negotiation failure as routine. >>> - recovering from failures should be minimally disruptive. >>> - must not leak resources. >>> - must monitor for and deal with hung code. >>> - must include security analysis >> OK. Since I drafted that text, I will leave the document editor to fix= >> it. (Some of the detail probably belongs in another draft specifically= >> about ASAs, which I am editing.) >=20 > Brian: Haha, that's called "passing on the ball" I believe... :-) Good catch! > Christian: With your input above, I suggest to reword that paragraph to= : >=20 > Since autonomic systems must be self-repairing, it is of great=20 > importance that ASAs are > coded using robust programming techniques. All run-time error condition= s=20 > must be caught, > leading to suitable >>> minimally disruptive <<< recovery actions, >>> = > also considering a complete restart of the ASA.<<< >=20 > The other bullets are covered in the text. OK for me. >>> - 7.4: When text talks about feedback loop, it mentions "allow the in= tervention" >>> of human admin or control system; however, it then describes the f= eedback loop >>> as presenting default actions and allowing for override. This is f= ine, but it >>> seems to leave out the common case where something is misbehaving = and would >>> not be presenting any choices to the administrator (using the feed= back loop), >>> so the admin must forcefully intervene. >> Yes. I think the word "feedback" is a bad choice. For engineers raised= on >> Nyquist diagrams it is part of a closed loop; for other people it mean= s >> feedback to humans. The text needs clarifying. > Christian: Right. I think this may be clearer when we distinguish (more= =20 > explicitly than is the case now) that there are two different systems=20 > involving the NOC: >=20 > 1 - a closed loop, called feedback loop at the moment. > 2 - a unidirectional error message. >=20 > 1 works like this: Node detects abnormal condition, informs NOC "here i= s=20 > what I see, I will take recovery X at time Y to resolve this". The NOC = > can then do nothing, or override this action. >=20 > 2 is a simple report, with no suggestion what to do, and no default=20 > recovery action. It's the NOC engineer's job to figure out what to do. = I=20 > think this is the "common case" you refer to. Put differently: A loop a= s=20 > in (1) REQUIRES some form of reaction by the node, otherwise it doesn't= =20 > belong here. >=20 > Secion 7.4 intents to cover case 1 only. > In my mind, case 2 is like current notification mechanisms (syslog etc)= ,=20 > part of "traditional management", thus not covered in this draft. >=20 > So maybe the solution is to point out what I say above: If there is no = > autonomic recovery option ("not presenting any choices" in your text), = > it falls into the traditional, non-autonomic scenario. And the draft is= =20 > clear that such traditional mechanisms will co-exist for a long time st= ill. >=20 > Proposal: > " > =C2=A0=C2=A0 Feedback loops are required in an autonomic network to al= low the > =C2=A0=C2=A0 intervention of a human administrator or central control = systems, > =C2=A0=C2=A0 while maintaining a default behaviour.=C2=A0 Through a fe= edback loop an > =C2=A0=C2=A0 administrator ***must*** be prompted with a default actio= n, and has the > =C2=A0=C2=A0 possibility to acknowledge or override the proposed defau= lt action. > =C2=A0=C2=A0 *** Uni-directional notifications to the NOC, that do not= propose > =C2=A0=C2=A0 any default action, and do not allow an override as part = of the=20 > transaction > =C2=A0=C2=A0 are considered like traditional notification services, su= ch as=20 > syslog. They > =C2=A0=C2=A0 are expected to co-exist with autonomic methods, but are = not covered in > =C2=A0=C2=A0 this draft. > " >=20 > Would that be clear? Again, OK for me. >>> Minor Issues: >>> >>> - 6.1 TEXT: "It must be possible to run ASAs as non-privileged (user = space) >>> processes except for those (such as the infrastructure ASAs) that = necessarily >>> require kernel privilege. Also, it is highly desirable that ASAs c= an be >>> dynamically loaded on a running node." >>> >>> ISSUE: Discussing implementation details like user-space, kernel p= rivilege and >>> dynamic loading seems unnecessary and outside the scope of this do= cument. Does >>> this document care if I implement my ASA on a real-time architectu= re with no >>> "user space" etc..? >> Fair enough. See my above comment re robustness. >=20 > I see where you're coming from, and sort of agree, and don't :-)=20 > Formally you're absolutely right, implementation details don't belong=20 > here. However, we had a large number of exchanges on user vs kernel=20 > space, which had design consequences. I feel it would be useful to leav= e=20 > this point in the document. Yes, because we want to insist that ASAs will be written not by kernel programmers but ordinary humans ;-). Whatever happens to the text here, the idea is that the complete discussion of ASAs will be in draft-carpenter-anima-asa-guidelines, assuming that the WG adopts it. Regards Brian >> I'll leave the rest of your comments to the document editor. >> >> Regards >> Brian >> >>> - 4.6 Why call out global routing and overlay networks in particular?= Is the >>> real intention to just say that the ACP implementation is not rest= ricted to >>> any specific type of networking? > I see that this can cause confusion. It also dates back to a looong=20 > discussion on what the ACP should look like. Frankly, I think we have=20 > all converged on the overlay model. So while the global routing table=20 > model is theoretically an option, we should probably drop it here.=20 > Suggestion: >=20 > " > =C2=A0=C2=A0 The "Autonomic Control Plane" carries the control protoco= ls in an > =C2=A0=C2=A0 autonomic network.=C2=A0 In the architecture described he= re, it is=20 > implemented > =C2=A0=C2=A0 as an overlay network.=C2=A0 The document "An > =C2=A0=C2=A0 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-contr= ol-plane]) > =C2=A0=C2=A0 describes the implementation details suggested here.=C2=A0= See > =C2=A0=C2=A0 [I-D.ietf-anima-stable-connectivity] for uses cases for t= he ACP. > " >>> >>> - TEXT: 6.3.1.2 "on a given LAN" >>> >>> NIT: Everyone knows what a LAN is; however, I wonder if the text s= hould be >>> more generic and actually describe what it really requires here wh= ich is a >>> broadcast or multicast network? > replace with "... on a given broadcast or multicast network." OK? >>> >>> Questions/Comments: >>> >>> - QUESTION: IoT and node requirements. There a couple node ASA requir= ements. I >>> found myself wondering if a very simple IoT things like thermostat= s might ever >>> be an AN and if so did they all really need to have joining assist= ent ASAs? It >>> could be that the answer is "Yes, they do or they can't be nodes".= I was just >>> curious. > We had that discussion a lot. 3.1 states that "At a later stage > =C2=A0=C2=A0 ANIMA may define a scope for constrained nodes with a red= uced ANI and > =C2=A0=C2=A0 well-defined minimal functionality.=C2=A0 They are curren= tly out of scope." >=20 > All sorts of things may happen: You may have devices that are hard-code= d=20 > to run in a domain, so they don't need to join (very specific cases=20 > only, IMO). Or they have a SIM card (or similar), and don't need=20 > enrolment (much more likely to happen). Many more... :-) >>> >>> - COMMENT: For the types of ASAs: simple (run anywhere), complex (res= ource >>> restricted), and infra (run everywhere), I was reminded of Kuberne= tes/cloud >>> orchestration, and the concept of DaemonSets (pods that run everyw= here) and >>> Deployments (pods that can run anywhere, possibly be scaled replic= ated, and >>> may also have requirements that restrict where they can run). I im= agine that >>> folks in Anima have also looked at this, but if not it would be go= od to as >>> they seem to be solving very similar problems. > Will do! Good point! >>> Nits: >>> >>> - TEXT: 3.2 "However, the information is tracked independently of the= status of >>> the peer nodes; specifically, it contains information about non-en= rolled >>> nodes, nodes of the same and other domains. " >>> >>> QUESTION: What are peer nodes? Is this another name for adjacent n= odes? If so >>> "s/peer/adjacent/". > We need to keep "peer" here. The adjacency table may have peers that ar= e=20 > not adjacent. >>> >>> - TEXT: 3.3.1 "enrols" >>> CHANGE: "enrolls" > Being a non-native English speaker, I believe this is US vs GB English,= =20 > and I leave others to sort that :-) >>> - TEXT: 3.3.3 "In this state, the autonomic node has at least one ACP= channel to >>> another device. It can participate in further autonomic transactio= ns, such as >>> starting autonomic service agents. For example it must now enable = the join >>> assistant ASA, to help other devices to join the domain. >>> >>> NIT: "For example foo" is not a sentence on it's own, also "It" is= not a good >>> subject as there are multiple nouns in the previous sentence that = could serve >>> as antecedents. >>> >>> SUGGEST: 3.3.3 "In this state, the autonomic node has at least one= ACP channel >>> to another device. The node can now participate in further autonom= ic >>> transactions, such as starting autonomic service agents (e.g., it = must now >>> enable the join assistant ASA, to help other devices to join the d= omain). > Will do, thanks. >>> >>> - TEXT: 4.1 "Names are typically assigned by a Registrar at bootstrap= time and >>> persistent over the lifetime of the device." >>> >>> NIT: s/persistent/and persist/ > I leave that to the RFC Editor to decide. To me our version is not=20 > wrong... Again, not native .... >>> >>> - TEXT: "Out of scope are addressing approaches for the data plane of= the >>> network, which may be configured and managed in the traditional wa= y, or >>> negotiated as a service of an ASA. One use case for such an autono= mic function >>> is described in [I-D.ietf-anima-prefix-management]." >>> >>> - NIT: Sounds sort of Yoda-like, and the compounding makes things les= s clear. > Yoda I like! :-) >>> SUGGEST: "Addressing approaches for the data plane of the network = are outside >>> the scope of this document. These addressing approaches may be con= figured and >>> managed in the traditional way, or negotiated as a service of an A= SA. One use >>> case for such an autonomic function is described in >>> [I-D.ietf-anima-prefix-management]." > Will change. >>> >>> - TEXT: 6.1: "Following an initial discovery phase, the device proper= ties and >>> those of its neighbors are the foundation of the behavior of a spe= cific >>> device. A device and its ASAs have no pre-configuration for the pa= rticular >>> network in which they are installed." >>> >>> NIT: Why suddenly lose the "node" abstraction and start talking ab= out devices >>> here? I think it continues to work well to say "node" (e.g., "node= >>> properties", "specific node" and "A node and its ASAs..."). > OK, will change to "node" - you're right. >>> >>> - TEXT: 6.2 "install ASA: copy the ASA code onto the host and start i= t," >>> NIT: "s/host/node/" >>> > OK. >=20 > Thanks for the thorough review Christian! I wait if anyone has an issue= =20 > with thos suggestions, and if not, edit the draft accordingly. >=20 > thanks! > Michael >=20 >=20 From nobody Thu Aug 30 01:11:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBC1130DC3; Thu, 30 Aug 2018 01:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHl7ycVwVak5; Thu, 30 Aug 2018 01:11:30 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 77A3E130DC0; Thu, 30 Aug 2018 01:11:30 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id m27-v6so7181401wrf.3; Thu, 30 Aug 2018 01:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=1U72f3jyjow+2lIvyQ9tdiEEipPwO9MJvfs8MS8b2KI=; b=ujs/R50IOakGpLMS1Y5LzkNvrF9KLVv75hyislsCPswZJbRFaCUofbAM06nXBNO0B7 YqUcyZIqxtTwJttHxufHIECAKSgcLF51/2NVs+8Csjt/WjPFNr2CVIrIxeG+CVV4+skb 0KwCTCAXAOiI1HMg5Hotdh0iRTa93IQOIucAK2ThCanfD76547Dnd8pjOiAZld0n/R47 99QDEVgM3fgKEDS7mzdE776ptwJI0zoNMcibtVNz3XIAEazH0UG99FmziVLRd9xCqU9m 388tmYHtZuOzKm181D85N/T1O8i6rq52HuYWQXhdiSvGlS/3hJ8WzRHMhhuExmZHvmhk ceLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1U72f3jyjow+2lIvyQ9tdiEEipPwO9MJvfs8MS8b2KI=; b=LOChGeWF7NYgVDCX8Y63eqf9wi9cP5mK6NU5GOpwdQOUZX7Vy48PW5lrcL6oh21oSK 8haK6bG7im26ZxnBxnih8WXTBvBQ38IlCm6s+rqvIJrAjVZ+fvIb5iHMcoMMMRLA/mAx IyKzSv//mwRndtt1OjlKsRhzjy1JoWrGzXsvdo8hJZ7BDPoG2Od4+AZl3UtGT1rkb7Ik zScbhiSSy5IvT0Ogd+2c+Kclwb5M7GQHZqnvo5tb5cLC6TnP3NirX6TkWVgJOGnG6ukK T3qDFn+c93F+KYa1I0fEU8xvvFnxNWi4e8UreIAOLJlIv3ibsnCuAPqK79DP71IEKfns IDEA== X-Gm-Message-State: APzg51ASR2NfqYxe+7W1Lwq1TvjlS64eRU31kpJkVL6kCcC8j0o2sbgT 4VXoaVOjmy1DTkFn6L+u3NTfQlQi X-Google-Smtp-Source: ANB0VdbxbLE0jrcI7iAJ/AVuFNUWUt/TukGpUbOopViGO0qcpGXIq+6pF1FCKncaoSuUIEmNFSGb5A== X-Received: by 2002:adf:8385:: with SMTP id 5-v6mr6734128wre.13.1535616688487; Thu, 30 Aug 2018 01:11:28 -0700 (PDT) Received: from [192.168.1.21] (ANice-652-1-20-67.w83-201.abo.wanadoo.fr. [83.201.31.67]) by smtp.gmail.com with ESMTPSA id 75-v6sm2277590wml.21.2018.08.30.01.11.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 01:11:27 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Brian E Carpenter , Christian Hopps , rtg-dir@ietf.org Cc: anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153529941582.11902.1347468414499836311@ietfa.amsl.com> <6288ec99-fbf6-e2e0-32c3-e402c19fdecd@gmail.com> <82183cb3-eefc-a22c-dcfa-d412733d933b@gmail.com> <0bb46db0-24f4-5396-9180-2adf20186233@gmail.com> Message-ID: <5b8b6635-d5ab-e9ca-fdba-61c99722c68a@gmail.com> Date: Thu, 30 Aug 2018 10:11:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0bb46db0-24f4-5396-9180-2adf20186233@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-reference-model-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 08:11:33 -0000 On 30/08/2018 04:06, Brian E Carpenter wrote: > On 2018-08-29 22:39, Michael H. Behringer wrote: >> Christian, thanks for the review, my comments inline... >> >> On 26/08/2018 22:57, Brian E Carpenter wrote: >>> (Ccs trimmed) >>> >>> Christian, >>> >>> Thanks for this careful review. I'll comment here on the larger issues: >>> >>> On 2018-08-27 04:03, Christian Hopps wrote: >>> ... >>>> Minor Major Issues: >>>> >>>> - Virtualization is mentioned once in "4.2 addressing" section. To quote: >>>> >>>> TEXT: "Support for virtualization: Autonomic Nodes may support Autonomic >>>> Service Agents in different virtual machines or containers. The addressing >>>> scheme should support this architecture." >>>> >>>> The special casing of VM/containers here seems to indicate that virtual >>>> devices are not "1st class citizens" in an autonomic network. In particular I >>>> could easily imagine virtual machines being full blown autonomic nodes >>>> themselves. Assuming the intent is not to restrict virtual devices in this >>>> manor something needs to be said (somewhere) to make that clear. >>> I don't think that was the intention. We haven't really explored this in detail, >>> but I can certainly imagine a deployment (for example) where each tenant in >>> a data centre has its own virtual autonomic network, and the underlying physical >>> network is also autonomic. Since the ACP is expected to be implemented as >>> a VRF, you could even argue that every autonomic network is virtual. >>> >>> So, yes, we can reword this. >> To add to Brian: I agree there was no intention to "downgrade" >> virtualization. Nor am I aware of any text that indicates that, also not >> what you quote above. We didn't mean this to say "this is not >> recommended", only "we haven't explored / documented that further". I am >> convinced that the Autonomic architecture will be all over data centers >> one day, so OBVIOUSLY virtualization is important. >> >> Happy to re-word, but: What do you suggest we change / add? I'm really >> not clear... > A modest suggestion, on the basis that if Christian read the text differently > from the authors' intentions, other people might do so as well. > > Support for virtualization: Autonomic functions can exist either at the > level of the physical network and physical devices, or at the level > of virtual machines, containers and networks. In particular, Autonomic > Nodes may support Autonomic Service Agents in virtual entities. The > infrastructure, including the addressing scheme, should be able to > support this architecture. > > (Comment: it isn't just addressing. There are software design > implications too, but that is out of scope here, I think.) OK, sounds good. I'll change that. I wait for potential further last call comments before making the changes and publishing a new version. Michael [rest deleted]