From nobody Sat Jul 1 13:16:22 2017 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 4A962126BFD; Sat, 1 Jul 2017 13:16:21 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149894018127.371.17773462389234301741@ietfa.amsl.com> Date: Sat, 01 Jul 2017 13:16:21 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-14.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:16:21 -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 of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-14.txt Pages : 79 Date : 2017-07-01 Abstract: This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-14 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-14 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 Sat Jul 1 13:19:03 2017 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 B87ED1275AB for ; Sat, 1 Jul 2017 13:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Cj2yIuUAQ_tz for ; Sat, 1 Jul 2017 13:19:00 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 E0D5E127078 for ; Sat, 1 Jul 2017 13:18:59 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id k14so2162871pgr.0 for ; Sat, 01 Jul 2017 13:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XowtMDo8lqObU6c+EMs3s9xBAhrkvVZFi/O5or3bmJ0=; b=C5B+IGXG5vkcQ8sFlJLYII6wyEg+LQyhwPKwboF3E/+5M0Vot4v7eCyROANbfj3POr OYCe0EHIFe3Ey0JVYhvbIQg0EzV58WCys+eMp2I7e5jKtJBuXi7A4HvkwtDh1IxcPD4/ t0+uowuJSo//htB91tOIuCU1Vp9hlQSDBx1Sd+eZzgOpsL1lb8gPi1mIHPgCXydCIhwZ N7MdCJ9sMhKh9HOLKz1k73U22zUozGgRqqskjtBCgpoWSrG5vkBT5ix6GVt3/+MHLaXb VnUjePwSNRP/YD7DQpqHJ7TIKf3NHTWeg/K/WWnU3H9as6FMaPdtNNFqyKvs5zNYGfiR pGdw== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XowtMDo8lqObU6c+EMs3s9xBAhrkvVZFi/O5or3bmJ0=; b=duywWyvp0ZIdrEYCh5FE2LgvGSmN32qk5HxI+OFOrOebT8vw5uYS9GHKt8jH94vbhH lKvKZ4bgtN7oZa1XBmPqoBzpSBANxCUdzBzy9KAbnEaPSZPlQC74ENPOdzHmrsnzN+9s I3gGh0/xH2QCl+KqP7qKd14SPbBeHEeGyjG0htgamooBDxVnAmtq5+NZbczbwvMgFskp IrAKWOLNhxbzZueYrnmnETsH0btKlnIYWSZqaLzlOj6eR42yLGXppnCBvgqzEonaveV8 ZBrYiUmvdGXMMgvFI7kcldFqjMCmPGke/bJL5Db3gn084hzHBw2UlgkuMfowYV8u7XYU 9qLg== X-Gm-Message-State: AIVw110xLiq345uo1J8sFmibipC+ViIARsbbAYmnYItKdvlHxudZlhPA aP+6zDbnJH4JdLJg X-Received: by 10.84.169.227 with SMTP id h90mr2235215plb.224.1498940339296; Sat, 01 Jul 2017 13:18:59 -0700 (PDT) Received: from [192.168.178.21] ([118.149.105.228]) by smtp.gmail.com with ESMTPSA id a125sm7293963pgc.37.2017.07.01.13.18.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 13:18:58 -0700 (PDT) To: Anima WG References: <149894018127.371.17773462389234301741@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <30e027b1-d48e-6588-0c7e-37bee9e3eec4@gmail.com> Date: Sun, 2 Jul 2017 08:18:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149894018127.371.17773462389234301741@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-grasp-14.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 20:19:02 -0000 Hi, This update has two changes in response to the remaining IESG DISCUSS comments: Updated 2.5.1 and 2.5.2 based on IESG security feedback (specify dependency against security substrate). Strengthened requirement for reliable transport protocol. Comments welcome. Regards Brian On 02/07/2017 08: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 of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-14.txt > Pages : 79 > Date : 2017-07-01 > > Abstract: > This document specifies the GeneRic Autonomic Signaling Protocol > (GRASP), which enables autonomic nodes and autonomic service agents > to dynamically discover peers, to synchronize state with each other, > and to negotiate parameter settings with each other. GRASP depends > on an external security environment that is described elsewhere. The > technical objectives and parameters for specific application > scenarios are to be described in separate documents. Appendices > briefly discuss requirements for the protocol and existing protocols > with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-14 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-14 > > > 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 Sat Jul 1 13:24:09 2017 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 71004129AD7 for ; Sat, 1 Jul 2017 13:24:08 -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 M-L4Z_FJcjPf for ; Sat, 1 Jul 2017 13:24:04 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 7A238129AD3 for ; Sat, 1 Jul 2017 13:24:04 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id k14so2188481pgr.0 for ; Sat, 01 Jul 2017 13:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=psYXpeqXXpSFS8kR7cackA8AD2EXkQjk/odHrR4SM0U=; b=SwfjQ5WnWN7tuxlUhOus0uPmcHszfCHhIkFTCs0pi3nyHXpjMpa39ManM+YfJOcHWC mqw0I/3B2w3IXBMrc7USNThqNAK3Q6hEib3xaeBkSzWulaPMSK/2uZWdcv1DUgBa6XI6 ZYam/YxrKHaHEdQUvqEPHkVf1gNDmKRDzjvssi+EPKWKTcifhO32fd8AZ7qa1HYOruYB qhl51Hf+kLmZJI+yN1Rw0/UpbTK07oPXAp1RQolpJE72sc0rZkJVwSrtXYowzoAEL7F5 XjKFALUNC+E+ACdpksCvIGa6SVJJxVtTJ74ihT+shjVI2AycoscmgX4mNNq0SCzQh0O1 IAPw== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=psYXpeqXXpSFS8kR7cackA8AD2EXkQjk/odHrR4SM0U=; b=W5t3Co/otZRMzm2DUz6ryK2YH30t3Z8fm/vFvhIt5RHQSEU+mnHwXfNUROmxmfNh56 ZjNgtQMuviNpVOZ5ZnP0IlvzX8KuyVxiTtBokYOMSAa+08UMiQ19Qxcxudp/953vetLg TjhfC0NcDM2/RAwpQZkDDf9wblpBVCWbXqoddNuei+lWu+ZhDyHPICXIvUiTu+1Zk2qw 63BX1pqeoSm3fwk6sx5tsPShnD0jH8Ibes6ONBRUaDs1zUYmFBqAbaU3TS8LZiq0BkwU PT2PFRq3jXWiP2rzk0Cf2VVzYROe1eWVo+prJIm6s8472iE2aKwdl6/dIFidGd4IZlE+ LBCQ== X-Gm-Message-State: AIVw113pwn4D9Uc+bc9BrQhkfMsVV9ZaT/hwlXvoAxtVzo0hXR/9u3Ou C3xRQTHu1GHcDHJO X-Received: by 10.99.95.147 with SMTP id t141mr2180693pgb.263.1498940643902; Sat, 01 Jul 2017 13:24:03 -0700 (PDT) Received: from [192.168.178.21] ([118.149.105.228]) by smtp.gmail.com with ESMTPSA id m11sm25246302pfg.85.2017.07.01.13.24.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 13:24:03 -0700 (PDT) To: Anima WG References: <149894048750.471.17377760070750633057@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1671ad78-6b21-fc79-7473-180ffeabfaaa@gmail.com> Date: Sun, 2 Jul 2017 08:23:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149894048750.471.17377760070750633057@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-carpenter-anima-asa-guidelines-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 20:24:08 -0000 This is a minor update: Expanded description of event-loop case. Added note about 'dry run' mode. Comments welcome. Regards Brian On 02/07/2017 08:21, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Guidelines for Autonomic Service Agents > Authors : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-anima-asa-guidelines-02.txt > Pages : 10 > Date : 2017-07-01 > > Abstract: > This document proposes guidelines for the design of Autonomic Service > Agents for autonomic networks. It is based on the Autonomic Network > Infrastructure outlined in the ANIMA reference model, making use of > the Autonomic Control Plane and the Generic Autonomic Signaling > Protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-asa-guidelines/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-anima-asa-guidelines-02 > https://datatracker.ietf.org/doc/html/draft-carpenter-anima-asa-guidelines-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-asa-guidelines-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 Sat Jul 1 16:42:16 2017 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 E447C129AB7 for ; Sat, 1 Jul 2017 16:42:14 -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 1PvpeiReo6-G for ; Sat, 1 Jul 2017 16:42:13 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 0E0F71200E5 for ; Sat, 1 Jul 2017 16:42:13 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id e7so83430659pfk.0 for ; Sat, 01 Jul 2017 16:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=aPCYEKeRGpmDIWERU24ZOqWYdBP+Y7c90EK2qpEkseE=; b=XLPg1kLcUZIW35nFhlSBPQFYXkWYyFNbkgqIBUcC2fuCOZOv0pYgo0LLy/yFObopEk W/dzjcx2fcIjGwhpgMwfXRKhnaNq1sFRnwLhmzhJvqw1tiRhN59Z9S/MxyK3uFxErQPJ uiK22xkkVlZ0T0RpQgHHiENQvyzDGSZmAUVMJzF8Dj/WUhc9/mdXSLktWNP7gcH8S+Ud lAWgV2cyB2jMWID3UfGbmTLWX9atBSh6YcbuR/eoNu7nGDiswPfhix1sDNeu/e6FzSg7 SThB09fc4Ry5/+H5Mm0DrWy1jPo81XG6QXS9TBkMLi15NHJ3HnBCEjmSRs3oxEfgsdsd 9w1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=aPCYEKeRGpmDIWERU24ZOqWYdBP+Y7c90EK2qpEkseE=; b=RVA7oZv9H22FweLvOr0UZbikDb/brt97CoH+HbiNx1UjLh4rupIEq24K23H4nTRD+K OYR2mwPlDStizelUgJZWnbyQ/zWgFvcqNv2tqUuQoC8AIeMrCq4pmzfMRiq2arRLwiY3 njeMz9QEFBOUZvucdZOQyHKK6nrMb7otaxknKEcXD0VNKpphzAHWIbZPVtL8Y0ULpkKb ykoavT+FgiWLL3VHDWnPgluw/ZyAs1s2ZluLepYLjNaO8wnPhW6Y8Jm6IrJnQYf2HxDh 5Hhx5hTk4RthQAPyZGuGAYX5AUfhwCql2+RwfEkJ/4pjk/2MxJwdbwIL2ryICxT7FnoL vjIg== X-Gm-Message-State: AIVw110oKA1ijAywtw5HvRXwoLm04fO8zlpCgEm86FJXM90vxWJUoQfu 7xXdMEyfmo7JD2hd X-Received: by 10.84.194.228 with SMTP id h91mr2710161pld.46.1498952532445; Sat, 01 Jul 2017 16:42:12 -0700 (PDT) Received: from [192.168.178.21] ([118.149.105.228]) by smtp.gmail.com with ESMTPSA id 28sm29284919pfq.125.2017.07.01.16.42.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 16:42:11 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <7ba1c7fb-0041-a740-4e76-c0e56cd32b98@gmail.com> Date: Sun, 2 Jul 2017 11:42:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP Python code moved to GitHub X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 23:42:15 -0000 I have moved the current prototype code for GRASP to GitHub. Please don't use the old URL any more. It will stop working soon. https://github.com/becarpenter/graspy Regards Brian Carpenter From nobody Mon Jul 3 07:57:07 2017 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 A9203127873; Mon, 3 Jul 2017 07:57:00 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909382065.22853.13437328328292666073@ietfa.amsl.com> Date: Mon, 03 Jul 2017 07:57:00 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-voucher-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 14:57:01 -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 of the IETF. Title : Voucher Profile for Bootstrapping Protocols Authors : Kent Watsen Michael C. Richardson Max Pritikin Toerless Eckert Filename : draft-ietf-anima-voucher-04.txt Pages : 19 Date : 2017-07-03 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". The voucher artifact is a YANG-defined JSON document that has (by default) been signed using a PKCS#7 structure. The voucher artifact is normally generated by the pledge's manufacturer or delegate (i.e. the Manufacturer Authorized Signing Authority). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-voucher-04 https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 09:43:12 2017 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 4EB50129B15; Mon, 3 Jul 2017 09:43:10 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910019029.22795.16749127178795000248@ietfa.amsl.com> Date: Mon, 03 Jul 2017 09:43:10 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:43:10 -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 of the IETF. Title : A Reference Model for Autonomic Networking Authors : Michael H. Behringer Brian Carpenter Toerless Eckert Laurent Ciavaglia Peloso Pierre Bing Liu Jeferson Campos Nobre John Strassner Filename : draft-ietf-anima-reference-model-04.txt Pages : 28 Date : 2017-07-03 Abstract: This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG. 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 15:46:08 2017 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 DD22113167E; Mon, 3 Jul 2017 15:46:06 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912196687.16184.16670430515675541832@ietfa.amsl.com> Date: Mon, 03 Jul 2017 15:46:06 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:46:07 -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 of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-07.txt Pages : 61 Date : 2017-07-03 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed X.509 certificate, in combination with a vendor's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-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 Mon Jul 3 16:17:29 2017 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 AC448131785; Mon, 3 Jul 2017 16:17:22 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912384267.16210.471335636315661212@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:17:22 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:17:23 -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 of the IETF. Title : An Autonomic Control Plane Authors : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-07.txt Pages : 43 Date : 2017-07-03 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "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 OAM communications over a network that is not configured, or mis-configured. 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-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 Mon Jul 3 16:29:14 2017 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 406E913171F; Mon, 3 Jul 2017 16:29:07 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912454722.16031.3218252799356696853@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:29:07 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:29:07 -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 of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-03.txt Pages : 18 Date : 2017-07-03 Abstract: OAM (Operations, Administration and Management) processes for data networks are often subject to the problem of circular dependencies when relying on network connectivity of the network to be managed for the OAM operations itself. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability can not be automated either because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN). to provide stable and secure connectivity for those OAM processes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-03 https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 16:39:08 2017 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 082781300E8 for ; Mon, 3 Jul 2017 16:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 BWFxxnZ6nxdc for ; Mon, 3 Jul 2017 16:39:04 -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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C02131451 for ; Mon, 3 Jul 2017 16:39:04 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1FEF558C4C0 for ; Tue, 4 Jul 2017 01:39:00 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 04952B0C49D; Tue, 4 Jul 2017 01:38:59 +0200 (CEST) Date: Tue, 4 Jul 2017 01:38:59 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20170703233859.GA12926@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:39:07 -0000 https://github.com/anima-wg/autonomic-control-plane/issues/1 Diff to -06: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-07.txt 13.13. draft-ietf-anima-autonomic-control-plane-07 o Changed author association. o Improved ACP connect setion (after confusion about term came up in the stable connectivity draft review). Added picture, defined complete terminology. o Moved ACP channel negotiation from normative section to appendix because it can in the timeline of this document not be fully specified to be implementable. Aka: work for future document. That work would also need to include analysing IKEv2 and describin the difference of a proposed GRASP/TLS solution to it. o Removed IANA request to allocate registry for GRASP/TLS. This would come with future draft (see above). o Gave the name "ACP information" to the field in the certificate carrying the ACP address and domain name. o Changed the rules for mutual authentication of certificates to rely on the domain in the ACP information of the certificate instead of the OU in the certificate. Also renewed the text pointing out that the ACP information in the certificate is meant to be in a form that it does not disturb other uses of the certificate. As long as the ACP expected to rely on a common OU across all certificates in a domain, this was not really true: Other uses of the certificates might require different OUs for different areas/type of devices. With the rules in this draft version, the ACP authentication does not rely on any other fields in the certificate. o Added an extension field to the ACP information so that in the future additional fields like a subdomain could be inserted. An example using such a subdomain field was added to the pre-existing text suggesting sub-domains. This approach is necessary so that there can be a single (main) domain in the ACP information, because that is used for mutual authentication of the certificate. Also clarified that only the register(s) SHOULD/MUST use that the ACP address was generated from the domain name - so that we can easier extend change this in extensions. o Took the text for the GRASP discovery of ACP neighbors from Brians grasp-ani-objectives draft. Alas, that draft was behind the latest GRASP draft, so i had to overhaul. The mayor change is to describe in the ACP draft the whole format of the M_FLOOD message (and not only the actual objective). This should make it a lot easier to read (without having to go back and forth to the GRASP RFC/draft). It was also necessary because the locator in the M_FLOOD messages has an important role and its not coded inside the objective. The specification of how to format the M_FLOOD message shuold now be complete, the text may be some duplicate with the DULL specificateion in GRASP, but no contradiction. o One of the main outcomes of reworking the GRASP section was the notion that GRASP announces both the candidate peers IPv6 link local address but also the support ACP security protocol including the port it is running on. In the past we shied away from using this information because it is not secured, but i think the additional attack vectors possible by using this information are negligible: If an attacker on an L2 subnet can fake another devices GRASP message then it can already provide a similar amount of attack by purely faking the link-local address. o Removed the section on discovery and BRSKI. This can be revived in the BRSKI document, but it seems mood given how we did remove mDNS from the latest BRSKI document (aka: this section discussed discrepancies between GRASP and mDNS discovery which should not exist anymore with latest BRSKI. o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we do not specify which one is to be used but that the ACP should be used to reach the URL included in the certificate to get to the CRL storage or OCSP server. o Changed ACP via IPsec to ACP via IKEv2 and restructured the sections to make IPsec native and IPsec via GRE subsections. o No need for any assigned dTLS port if ACP is run across dTLS because it is signalled via GRASP. From nobody Mon Jul 3 16:46:04 2017 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 1DD8E1317E4 for ; Mon, 3 Jul 2017 16:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Kkj2XQLOze7Y for ; Mon, 3 Jul 2017 16:46:01 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BD01317D7 for ; Mon, 3 Jul 2017 16:46:01 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 70D7F58C4C0 for ; Tue, 4 Jul 2017 01:45:57 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 59B24B0C49D; Tue, 4 Jul 2017 01:45:57 +0200 (CEST) Date: Tue, 4 Jul 2017 01:45:57 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20170703234557.GB12926@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:46:03 -0000 https://github.com/anima-wg/autonomic-control-plane/issues/2 http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-03.txt Diffs explained in reply email to shepherd review by Sheng Jiang: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/02-shepherd-review-sheng-reply.txt Cheers Toerless From nobody Mon Jul 3 16:52:10 2017 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 EDAFB1317A0 for ; Mon, 3 Jul 2017 16:52:08 -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, RP_MATCHES_RCVD=-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 j56nOii3l5VV for ; Mon, 3 Jul 2017 16:52:06 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539F513176E for ; Mon, 3 Jul 2017 16:52:06 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B206158C4C0; Tue, 4 Jul 2017 01:52:02 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8FA54B0C49D; Tue, 4 Jul 2017 01:52:02 +0200 (CEST) Date: Tue, 4 Jul 2017 01:52:02 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170703235202.GC12926@faui40p.informatik.uni-erlangen.de> References: <7ba1c7fb-0041-a740-4e76-c0e56cd32b98@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ba1c7fb-0041-a740-4e76-c0e56cd32b98@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] GRASP Python code moved to GitHub X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:52:09 -0000 I am still not good with scatter/gather cloud storage, so i created a stub repository to point to yours: https://github.com/anima-wg/grasp Cheers Toerless On Sun, Jul 02, 2017 at 11:42:07AM +1200, Brian E Carpenter wrote: > I have moved the current prototype code for GRASP to GitHub. > Please don't use the old URL any more. It will stop working soon. > > https://github.com/becarpenter/graspy > > Regards > Brian Carpenter > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jul 3 17:00:49 2017 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 59863131843 for ; Mon, 3 Jul 2017 17:00:27 -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, RP_MATCHES_RCVD=-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 zZwQDw0VkggI for ; Mon, 3 Jul 2017 17:00:24 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902D2131832 for ; Mon, 3 Jul 2017 16:59:49 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 48C7B58C4C0; Tue, 4 Jul 2017 01:59:45 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 33E57B0C49D; Tue, 4 Jul 2017 01:59:45 +0200 (CEST) Date: Tue, 4 Jul 2017 01:59:45 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org Message-ID: <20170703235944.GD12926@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jul 2017 00:00:27 -0000 On Thu, Jun 29, 2017 at 02:44:14PM +1200, Brian E Carpenter wrote: > I had a look at both sets of changes and they seem good to me. Thanks. The reviewed document was just pushed as -03 to datatracker, see other emails. > I find myself wondering, after seeing the slightly confused text > about GRASP objectives in the latest BRSKI, and noting the absence > of such objectives in the ACP and stable-connectivity drafts, whether > we should accept that we need a specialised draft for all the > GRASP objectives needed by the ANI. I am still working through the last two IETFs agreement that we need to update BRSKI and ACP drafts to allow dissolving of the ani-objectives (and use it as the starting point). The BRSKI changes for this are still in a github branch we have not gotten through to merge into the main branch due to prioritizing voucher work first (get thast through last call). The ACP draft changes to introduce the ani-objectives proposed GRASP objective details are included in the -07 ACP draft that i also just submitted. I actually expanded on the text to represent the whole M_FLOOD message format because i always found it highly irritating having to switch between the taget draft (ACP etc.) and the GRASP draft to really see whats in the whole message. Wrt to GRASP in stable connectivity, i think we should try to also finish up this draft, the ideas how else NOC and ANI can be integrated is for both time and other reasons better done in a followup draft: Another such reason could be to introduce those GRASP objectives/functions as a standards strack document (stable connectivity is just informational target). Cheers Toerless > Strangely enough, we have such a draft already: > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01 > My idea was for this to be a temporary draft, with its contents > being moved into BSRKI, ACP and stable-connectivity. But would it > be more practical to keep it as a separate draft? It makes the other > three drafts a bit more self-contained, and allows for a consistent > definition of the infrastructure objectives. > > What to do people think? > > (Disregard the current details in draft-carpenter-anima-ani-objectives, > which has not been updated recently.) > > Regards > Brian > > On 27/06/2017 16:21, Toerless Eckert wrote: > > Thanks a lot, Sheng! > > > > Integrated fixes for all comments (see inline discuss below). Pushed stable connectivity draft > > into www.github.com/anima-wg/autonomic-control-plane together with ACP draft because i ended up > > having to do a fix for the ACP draft as a result of your comments. > > > > Diff between -02 and fixed up stable connectivity draft here: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt > > > > If you are fine with the fixes let me know, and i'll push it to datatracker as -03. > > > > If not ok. feel free to use email or now also add issue to the git. > > > > Raw txt/git files of fixed stable connectivity text: > > > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml > > > > Diff for change done in ACP (explaining ACP connect better): > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt > > > > Cheers > > Toerless > > > > On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: > >> Hi, authors of draft-ietf-anima-stable-connectivity, > >> > >> I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. > >> > >> First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It would be an unlike scenario to manage an IPv6 network (all managed devices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the NAT64 setup in this scenario is complex, and connectivity between IPv4 only NOC application devices and NAT is unsecure. I would suggest to reduce the whole section or add a clear statement that it is a not-recommended scenario at the end of this section. > > > > Yes, it is a mess. But it is documenting an actual deployment experience with an enterprise > > customer. TAnd my understanding is tht it would be a quite common scenario for enterprises. There > > was just recently a very nice RTG area WG chair tutorial that to me reconfirmed the ongoing > > challenges with IPv6 only management planes. > > > > I have added paragraphs to justify the need for this section and that its all undesirable workarounds > > Please check. To me, this messy section is the price we have to pay so that the ACP > > can simply be IPv6 only. Its a price i am happy to pay. > > > >> Secondly, the description and category in section 2.1.2, "Limitations and enhancement overview". For me, only the point 1 & 3 are really limitation of ACP itself. > > > > I have improved the text and categorization in this chapter to make it hopefully clearer to read and to be more precise in terminology. > > > >> Point 2 is a precondition (it is actually conflicted with section 2.1.4.) > > > > Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that is a challenge for which there is a workaround. Those workarounds are described in section 2.1.4. I've tried to improve all that text. I do not understand why point 2 would be a conflict with section 2.1.4 instead of rather pointing to 2.1.4. > > > >> I don't understand point 4. What does "exposing the ACP natively" mean? > > > > That is the term that was defined in ACP CP draft, section 6.1. Reading through that section, i improved it in the ACP section, and i updated the text about it in stable connectivity. > > > > Oh, and this change had me change the term "NOC application device" to "NMS host" throughout the document because that is the term used in the ACP draft. > > > >> Thirdly, I have issues to use names to distinguish the path selection policies. > >> This is a chicken&egg issue in the autonomic scenario. > >> Who and how the DNS names are setup, by human administrator? > > > > IMHO, considerations for names are one of the most crucial part of > > operationalizing the ACP. The little text we have about the ACP is IMHO > > a good compromise between overlooking the problem and writing a lot more > > text. > > > > The concept of using different addresses for a device for different actions > > is not novel to ACP. Think of using a loopback to "reliably" talk to a router > > vs. ping'ing specific interface addresses of a router to discover whether > > an peer (reachable via that interface) is up/down. If you look at service > > providers name setups (often in DNS), then they will have different names > > for those different addresses and use those different names in the different > > tools. The text in this draft simply explains the same concept for > > ACP vs. other addresses. > > > > DNS names can be setup by various locally built automation scripting or templates. > > Same think for DNS names for ACP. Operators will likely point out that automating > > the DNS name creation is more difficult because we do not use topology/semantic > > ACP addresses, but in principle it's the same automation task. > > > >> If there is a mechanism to distinguish the IP addresses of ACP and data-plane without human intelligence, why does it bore to use DNS? > > > > ALl the existing "actions" that you want to do for a device are just too stupid: > > They do not include the logic of knowing which address is best for them to > > use. That's why you use names for subsets of the possible addresses to allow > > you to specify exatly those address(es) that will reach the device via the > > network connection matching the intent of the action you're taking. > > > >> DNS registration & lookup by itself is a very complex and time-consumption procedure. > > > > Depends on your automation. Its certainly an interesting aspect especially moving > > from IPv4 to IPv6 where embedding logic into adresses becomes a whole different > > ballgame. > > > >> If we don't want to show the semantic of these addresses to any human, names are meaningless. > > > > But you need new NOC tools where each action would need to know what type > > of connection is best for it. > > > > I have added one paragraph to 2.1.5 to outline this logic and justification for why > > to describe DNS. Look for "Ideally, a NOC system would learn and keep track of all addresses of a device" > > > > > >> In section 2.2, "The ACP can provide common direct-neighbor discovery and capability negotiation". This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP. > > > > Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP protocol common direct-neighbor > > discovery and capability negotiation (GRASP via ACP and/or data-plane) and stable and secure > > connectivity for functions running distributed in network devices (GRASP via ACP). > > > >> At the end of section 2.1.3, "A simple short-term workaround could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. Personally, I believe this could be done by a virtual loopback interface. > > > > Ack. Changed text to: A workaround without additional software functionality could be a physical external loopback > > cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture. A (virtual) > > software loopback between the ACP and data plane VRF would of course be the better solution. > > > > The key notion why the "gross" physcial loopback may be appreciated is because it doesn't require software work. Or specification of the behavior of such a software loopback in the roting behavior in the ACP draft. I would love to have that software loopback, but i think we (ACP doc authors) felt that we wanted to keep the ACP spec lightweight enough to be implementable without all possible enhancements. But i hope its fine to mention the option here in this document as you suggested. > > > >> Section 3, "Security considerations" is more like a deployment considerations. Both ULA-C and reverse DNS are additional deployment > > > > Yes, but i think if you look through various IETF documents you will see that it is quite common for security consideration sections to outline additional steps to secure the documents work goal especially when those steps are otherwise orthogonal to the documents spec (eg: leverage existing components). > > > > Whats the process for informational documents. It will get SEC AD review, right ? Maybe hold that thought for that review ? Or else i can proactively ask, because right now i am a bit at a loss whats the right limit of what to put into sec considerations vs. what to extract into a separate chapter. > > > >> Minor comments, > >> > >> Section 2.1.6, "Autonomic NOC device/applications" should be moved to early part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess. > > > > The text unfortunately builds up in the order it is written, so it would be a lot of rewrite to make sure it would still read after such a reordering. Instead i have added the following as the first paragraph: > > > > This section describes stable connectibity for centralized OAM operations via ACP/ANI > > starting by what we expect to be the most likely easiest short-term deployment option. It > > then describes limitation/challenges of that approach and their solutions/workarounds to finish > > with the preferred target option of autonomic NOC devices in . > > > > This order was choosen because it helps to explain how simple one can start using the ACP, > > how difficult workarounds can become (and therefore what to avoid), and finally because one very > > promising long-term solution alternative is exactly like the most easy short-term solution only virtualized > > and automated. > > > > The last sentence is that punchline: The likely easiest/best atonomic NOC device solution is one where you do everything you do in the short-term approach, just virtualized and integrated into the NOC device. WHich means you'd need to explain all that stuff anyhow... > > > >> It is worth of mentioning even the ACP provides only IPv6 connectivity, through it, IPv4 configuration or even non-IP configuration could be managed. > > > > Good point. Added the following sentence: > > > > Note that even though the ACP only uses IPv6, it can and should be used to providestable connectivity for management of any network: IPv4 only, dual-stack or IPv6 only. > > > >> The document does not properly quota references in the text. The references defined are mostly not used. > > > > Ack. Removed unnecessary references, introduced terms/references in the beginning of the document. All references now used at least once ;-) > > > >> The document separate sections for Informative/Normative References > > > > Hmm. It DOES NOT distinguish between normative and informational documents because i thought that an informational document like this could not have normative references. If it can and should have them let me know, then i'll make Bootstrap/Grasp/ACP normative and reference/definitions informational. > > > >> The empty section 5 "Further considerations", should be removed. > > > > Done. > > > >> Most of references are out of date. behringer-anima-reference-model > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-network-definitions > RFC 7575. > > > > Fixed. > > > >> In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the infrastructure design." What is the mean for "other mayor"? > > > > added: Examples include change of IGP protocols or areas, PD (Provider > > Dependent) to PI (Provider Independent) addressing, systematic topology changes. > > > >> In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may be better to presented as "the Autonomic Control plane (ACP) in Autonomic Networks" > > > > Done > > > >> There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section 2.1.5, "KARP" in section 2.2, even the first appearances. > > > > Done, added RFC references for those TLAs that have them as well. > > > >> Last sentence of section 2.2 should be removed. > > > > Done. > > > >> In section 3, first sentence, add "In this section," > > > > Done. > > > >> There are typos, needed to be fixed too: > >> > >> Two "the the" in the end of section 2.1.2 and end of section 4; > > > > Done > >> > >> A couple of "randomn" -> "random"; > > > > Done > >> > >> "networ" in section 2.1.5; > > > > Done > >> > >> "jut" -> "just" at the end of section 2.1.6, I guess. > >> > >> "The most simple" -> "the simplest" in section 2.17. > > > > Done. > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jul 3 17:13:40 2017 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 A13E21317AE for ; Mon, 3 Jul 2017 17:13:38 -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 H6rH5m7betf6 for ; Mon, 3 Jul 2017 17:13:35 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E3D1317F9 for ; Mon, 3 Jul 2017 17:13:28 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id j186so101485858pge.2 for ; Mon, 03 Jul 2017 17:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UWvPmlYFRfJZMVyl2VsliOOcpYdk2T3xL1xh09bIBmc=; b=jwKM3LD3a+EFZGqcDiWMhBU9KcyYq6FD1FQg6hnzLH92uCNwPXmnbVuo2wDq5btdgW 0VtXTX8ylh9cE70xFsEjUGnGDX7jipddJcCpTM4jAO/1qVy3Fpd5bVtfEiikxgQaahQg wBkilLzV8uUkXsiS/NutOX5pGTWmnHhOBl/VD2Om5bD7kUiO2An9loiiHkGecz1Xiof1 BmZeRqGgo5fujI5X6AEWDTb8EhtdCJCD9FrL/SkFv6q5zxRl+QiIjUZQM+mLlBFOaQ7z ObB/uJT8iru9JSKZ0kBwBggnY6KrRJn6TSwpJ4dUEgO4KjcgyStrAkRHmvCjipG0lyZR prFA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UWvPmlYFRfJZMVyl2VsliOOcpYdk2T3xL1xh09bIBmc=; b=fv3UwX6CtgH6u0+T7DKmP4Jhh3dAoAIj5UFgTS91nUWHeQbnn76sR7l2WsTncL07EN CwrexNxfznvFBddq3WJE7p3v0fWOSajeK2p3iKMl9hCMYQI5gmg6JTN2964qBS9xE6O8 a7Km7JbgyF0vv8eRdECXRRXQ9r873EDoGtBcjkWHU3LU0N/g3nMuRpLHZdI8Do5zpysL OXLGIfU8oxOk5h1O+uVTqmO2JcZ0+HaYCmi3Y0wOssWRBz31ZVC6mT7h8HEr71ZWbeaD 5gynujEVJ9x3pqmM1kANwH5S+OYhFATVx9h4V2ebEqxUg8EVFI8UAOtKT4cX1iY+gN5E S0Xg== X-Gm-Message-State: AIVw111ZkMkMU5wGhnjHb4rsjwCCoW1+4kK7PxvnpCYOmRlaXDp6w3tL uM0UBznijvBCUrCL X-Received: by 10.84.143.195 with SMTP id 61mr13301442plz.47.1499127207378; Mon, 03 Jul 2017 17:13:27 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id o13sm40288291pfa.120.2017.07.03.17.13.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 17:13:26 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <7ba1c7fb-0041-a740-4e76-c0e56cd32b98@gmail.com> <20170703235202.GC12926@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5c491c76-1762-03eb-f3ab-1517a447d880@gmail.com> Date: Tue, 4 Jul 2017 12:13:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170703235202.GC12926@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP Python code moved to GitHub X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jul 2017 00:13:39 -0000 On 04/07/2017 11:52, Toerless Eckert wrote: > I am still not good with scatter/gather cloud storage, so i created a stub repository to > point to yours: > > https://github.com/anima-wg/grasp Th code is not IETF work. It SHOULD NOT be under a repo for the WG. I had to move it in a hurry due to a mess made by my university's IT "service". Also, is there or isn't there a WG policy on repos for WG drafts? I'm quite willing to join if there is, but there's never been an announcement about that and there's nothing about it on https://datatracker.ietf.org/wg/anima/about/ under Additional URLs If there's a GitHub organization for the WG, it should be listed there, I think. Brian > > Cheers > Toerless > > On Sun, Jul 02, 2017 at 11:42:07AM +1200, Brian E Carpenter wrote: >> I have moved the current prototype code for GRASP to GitHub. >> Please don't use the old URL any more. It will stop working soon. >> >> https://github.com/becarpenter/graspy >> >> Regards >> Brian Carpenter >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 3 17:23:48 2017 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 E8A401317F8 for ; Mon, 3 Jul 2017 17:23:47 -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 S_p3blEs30s5 for ; Mon, 3 Jul 2017 17:23:43 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471DF131815 for ; Mon, 3 Jul 2017 17:23:38 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id q86so106677411pfl.3 for ; Mon, 03 Jul 2017 17:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/oXddbQHOgha5inge/7QxnUKMAGvTloJXlXNcQirp8I=; b=E9RJAMA05891TrCpoSRLcjkR9pltl+q0E6ZBahwqEpNMiLA83voxhzPAdlenly81tX 7BpTl1t/cTVyavPAATnEo/gAefPubCwXsLAWakKNrfVLmaAAwkauSMFOV/mc4pN4oy/c FN6zjF30LrkqQEW3lk2H2kXZ3yLmCpJ5j2o5izt7/wccjXfgQl4Lql/TEY3xOIMqc5o0 Hdpdlsxv9yEvB56nqeVFGgah5oCkvIuv/+Wi3ZnzSLkYcwPjmaVsGffmS95/K/UGDMjV o4IjAUkKspn992++wA+jBvuFKERvw7yLqqSVU0OlANuy5qoY7IA6OpDa72LCLAMjWYuv 22iA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/oXddbQHOgha5inge/7QxnUKMAGvTloJXlXNcQirp8I=; b=dN9ZhzYGsMQdFLOgj41Y2VuIM09xIM4P8SZbjdRrzijpS0pb2/sZ+z8SEQVierZY3s rj7mOc1OiH82hdJ4w0RUWjkhivX571ihh9vlXLhG3Dk+XqVos45PWg1ti44+Q1V2xtie +yHBJFRb9f2ORBttxUzhgyf322YtCJ2cz0EOBNAqOVtpKKCAGzdwLE+7cmufv4D3a9mV EPVCKm8f3Hd8eqRUy3f+JtRssgT4umgos5Z9qADt1MkaISTxZJOa3xs622X/aM+Qk9hg TEEDu3REmH88j5bLpH9sgER6/nSvaJUatTtSH2YRADUIy6tJpru5Lt44ARAWhs5OuXJR 2FdQ== X-Gm-Message-State: AIVw110UrMkG4PHNd6zdhquqPJt9y7aMI84Mpjudu7Ve4XOaskJiz0z+ 5IqMqU60ZuwJqf7b X-Received: by 10.98.89.129 with SMTP id k1mr12572357pfj.28.1499127817246; Mon, 03 Jul 2017 17:23:37 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id x5sm15906482pgq.18.2017.07.03.17.23.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 17:23:36 -0700 (PDT) To: Toerless Eckert Cc: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> <20170703235944.GD12926@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 4 Jul 2017 12:23:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170703235944.GD12926@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jul 2017 00:23:48 -0000 Toerless, > I actually expanded on the text to represent the whole M_FLOOD message format > because i always found it highly irritating having to switch between the > taget draft (ACP etc.) and the GRASP draft to really see whats in the whole > message. I have mixed feelings about that, because of the obvious scope for error, and the general risk of duplicating material between documents. In any case, we need to check it in great detail. (The best check would be to make and debug a demo implementation, dump the actual packets, and check that they correspond.) This is actually why we also need consensus on the GRASP API. It's much easier to verify a use case against the API than to work out message details. Regards Brian On 04/07/2017 11:59, Toerless Eckert wrote: > On Thu, Jun 29, 2017 at 02:44:14PM +1200, Brian E Carpenter wrote: >> I had a look at both sets of changes and they seem good to me. > > Thanks. The reviewed document was just pushed as -03 to datatracker, see other emails. > >> I find myself wondering, after seeing the slightly confused text >> about GRASP objectives in the latest BRSKI, and noting the absence >> of such objectives in the ACP and stable-connectivity drafts, whether >> we should accept that we need a specialised draft for all the >> GRASP objectives needed by the ANI. > > I am still working through the last two IETFs agreement that we need to update > BRSKI and ACP drafts to allow dissolving of the ani-objectives (and use it as > the starting point). > > The BRSKI changes for this are still in a github branch we have not gotten through > to merge into the main branch due to prioritizing voucher work first (get thast > through last call). > > The ACP draft changes to introduce the ani-objectives proposed GRASP objective > details are included in the -07 ACP draft that i also just submitted. > > I actually expanded on the text to represent the whole M_FLOOD message format > because i always found it highly irritating having to switch between the > taget draft (ACP etc.) and the GRASP draft to really see whats in the whole > message. > > Wrt to GRASP in stable connectivity, i think we should try to also finish up this > draft, the ideas how else NOC and ANI can be integrated is for both time and > other reasons better done in a followup draft: Another such reason could be > to introduce those GRASP objectives/functions as a standards strack document > (stable connectivity is just informational target). > > Cheers > Toerless > >> Strangely enough, we have such a draft already: >> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01 >> My idea was for this to be a temporary draft, with its contents >> being moved into BSRKI, ACP and stable-connectivity. But would it >> be more practical to keep it as a separate draft? It makes the other >> three drafts a bit more self-contained, and allows for a consistent >> definition of the infrastructure objectives. >> >> What to do people think? >> >> (Disregard the current details in draft-carpenter-anima-ani-objectives, >> which has not been updated recently.) >> >> Regards >> Brian >> >> On 27/06/2017 16:21, Toerless Eckert wrote: >>> Thanks a lot, Sheng! >>> >>> Integrated fixes for all comments (see inline discuss below). Pushed stable connectivity draft >>> into www.github.com/anima-wg/autonomic-control-plane together with ACP draft because i ended up >>> having to do a fix for the ACP draft as a result of your comments. >>> >>> Diff between -02 and fixed up stable connectivity draft here: >>> >>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt >>> >>> If you are fine with the fixes let me know, and i'll push it to datatracker as -03. >>> >>> If not ok. feel free to use email or now also add issue to the git. >>> >>> Raw txt/git files of fixed stable connectivity text: >>> >>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt >>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml >>> >>> Diff for change done in ACP (explaining ACP connect better): >>> >>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt >>> >>> Cheers >>> Toerless >>> >>> On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: >>>> Hi, authors of draft-ietf-anima-stable-connectivity, >>>> >>>> I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. >>>> >>>> First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It would be an unlike scenario to manage an IPv6 network (all managed devices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the NAT64 setup in this scenario is complex, and connectivity between IPv4 only NOC application devices and NAT is unsecure. I would suggest to reduce the whole section or add a clear statement that it is a not-recommended scenario at the end of this section. >>> >>> Yes, it is a mess. But it is documenting an actual deployment experience with an enterprise >>> customer. TAnd my understanding is tht it would be a quite common scenario for enterprises. There >>> was just recently a very nice RTG area WG chair tutorial that to me reconfirmed the ongoing >>> challenges with IPv6 only management planes. >>> >>> I have added paragraphs to justify the need for this section and that its all undesirable workarounds >>> Please check. To me, this messy section is the price we have to pay so that the ACP >>> can simply be IPv6 only. Its a price i am happy to pay. >>> >>>> Secondly, the description and category in section 2.1.2, "Limitations and enhancement overview". For me, only the point 1 & 3 are really limitation of ACP itself. >>> >>> I have improved the text and categorization in this chapter to make it hopefully clearer to read and to be more precise in terminology. >>> >>>> Point 2 is a precondition (it is actually conflicted with section 2.1.4.) >>> >>> Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that is a challenge for which there is a workaround. Those workarounds are described in section 2.1.4. I've tried to improve all that text. I do not understand why point 2 would be a conflict with section 2.1.4 instead of rather pointing to 2.1.4. >>> >>>> I don't understand point 4. What does "exposing the ACP natively" mean? >>> >>> That is the term that was defined in ACP CP draft, section 6.1. Reading through that section, i improved it in the ACP section, and i updated the text about it in stable connectivity. >>> >>> Oh, and this change had me change the term "NOC application device" to "NMS host" throughout the document because that is the term used in the ACP draft. >>> >>>> Thirdly, I have issues to use names to distinguish the path selection policies. >>>> This is a chicken&egg issue in the autonomic scenario. >>>> Who and how the DNS names are setup, by human administrator? >>> >>> IMHO, considerations for names are one of the most crucial part of >>> operationalizing the ACP. The little text we have about the ACP is IMHO >>> a good compromise between overlooking the problem and writing a lot more >>> text. >>> >>> The concept of using different addresses for a device for different actions >>> is not novel to ACP. Think of using a loopback to "reliably" talk to a router >>> vs. ping'ing specific interface addresses of a router to discover whether >>> an peer (reachable via that interface) is up/down. If you look at service >>> providers name setups (often in DNS), then they will have different names >>> for those different addresses and use those different names in the different >>> tools. The text in this draft simply explains the same concept for >>> ACP vs. other addresses. >>> >>> DNS names can be setup by various locally built automation scripting or templates. >>> Same think for DNS names for ACP. Operators will likely point out that automating >>> the DNS name creation is more difficult because we do not use topology/semantic >>> ACP addresses, but in principle it's the same automation task. >>> >>>> If there is a mechanism to distinguish the IP addresses of ACP and data-plane without human intelligence, why does it bore to use DNS? >>> >>> ALl the existing "actions" that you want to do for a device are just too stupid: >>> They do not include the logic of knowing which address is best for them to >>> use. That's why you use names for subsets of the possible addresses to allow >>> you to specify exatly those address(es) that will reach the device via the >>> network connection matching the intent of the action you're taking. >>> >>>> DNS registration & lookup by itself is a very complex and time-consumption procedure. >>> >>> Depends on your automation. Its certainly an interesting aspect especially moving >>> from IPv4 to IPv6 where embedding logic into adresses becomes a whole different >>> ballgame. >>> >>>> If we don't want to show the semantic of these addresses to any human, names are meaningless. >>> >>> But you need new NOC tools where each action would need to know what type >>> of connection is best for it. >>> >>> I have added one paragraph to 2.1.5 to outline this logic and justification for why >>> to describe DNS. Look for "Ideally, a NOC system would learn and keep track of all addresses of a device" >>> >>> >>>> In section 2.2, "The ACP can provide common direct-neighbor discovery and capability negotiation". This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP. >>> >>> Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP protocol common direct-neighbor >>> discovery and capability negotiation (GRASP via ACP and/or data-plane) and stable and secure >>> connectivity for functions running distributed in network devices (GRASP via ACP). >>> >>>> At the end of section 2.1.3, "A simple short-term workaround could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. Personally, I believe this could be done by a virtual loopback interface. >>> >>> Ack. Changed text to: A workaround without additional software functionality could be a physical external loopback >>> cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture. A (virtual) >>> software loopback between the ACP and data plane VRF would of course be the better solution. >>> >>> The key notion why the "gross" physcial loopback may be appreciated is because it doesn't require software work. Or specification of the behavior of such a software loopback in the roting behavior in the ACP draft. I would love to have that software loopback, but i think we (ACP doc authors) felt that we wanted to keep the ACP spec lightweight enough to be implementable without all possible enhancements. But i hope its fine to mention the option here in this document as you suggested. >>> >>>> Section 3, "Security considerations" is more like a deployment considerations. Both ULA-C and reverse DNS are additional deployment >>> >>> Yes, but i think if you look through various IETF documents you will see that it is quite common for security consideration sections to outline additional steps to secure the documents work goal especially when those steps are otherwise orthogonal to the documents spec (eg: leverage existing components). >>> >>> Whats the process for informational documents. It will get SEC AD review, right ? Maybe hold that thought for that review ? Or else i can proactively ask, because right now i am a bit at a loss whats the right limit of what to put into sec considerations vs. what to extract into a separate chapter. >>> >>>> Minor comments, >>>> >>>> Section 2.1.6, "Autonomic NOC device/applications" should be moved to early part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess. >>> >>> The text unfortunately builds up in the order it is written, so it would be a lot of rewrite to make sure it would still read after such a reordering. Instead i have added the following as the first paragraph: >>> >>> This section describes stable connectibity for centralized OAM operations via ACP/ANI >>> starting by what we expect to be the most likely easiest short-term deployment option. It >>> then describes limitation/challenges of that approach and their solutions/workarounds to finish >>> with the preferred target option of autonomic NOC devices in . >>> >>> This order was choosen because it helps to explain how simple one can start using the ACP, >>> how difficult workarounds can become (and therefore what to avoid), and finally because one very >>> promising long-term solution alternative is exactly like the most easy short-term solution only virtualized >>> and automated. >>> >>> The last sentence is that punchline: The likely easiest/best atonomic NOC device solution is one where you do everything you do in the short-term approach, just virtualized and integrated into the NOC device. WHich means you'd need to explain all that stuff anyhow... >>> >>>> It is worth of mentioning even the ACP provides only IPv6 connectivity, through it, IPv4 configuration or even non-IP configuration could be managed. >>> >>> Good point. Added the following sentence: >>> >>> Note that even though the ACP only uses IPv6, it can and should be used to providestable connectivity for management of any network: IPv4 only, dual-stack or IPv6 only. >>> >>>> The document does not properly quota references in the text. The references defined are mostly not used. >>> >>> Ack. Removed unnecessary references, introduced terms/references in the beginning of the document. All references now used at least once ;-) >>> >>>> The document separate sections for Informative/Normative References >>> >>> Hmm. It DOES NOT distinguish between normative and informational documents because i thought that an informational document like this could not have normative references. If it can and should have them let me know, then i'll make Bootstrap/Grasp/ACP normative and reference/definitions informational. >>> >>>> The empty section 5 "Further considerations", should be removed. >>> >>> Done. >>> >>>> Most of references are out of date. behringer-anima-reference-model > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-network-definitions > RFC 7575. >>> >>> Fixed. >>> >>>> In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the infrastructure design." What is the mean for "other mayor"? >>> >>> added: Examples include change of IGP protocols or areas, PD (Provider >>> Dependent) to PI (Provider Independent) addressing, systematic topology changes. >>> >>>> In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may be better to presented as "the Autonomic Control plane (ACP) in Autonomic Networks" >>> >>> Done >>> >>>> There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section 2.1.5, "KARP" in section 2.2, even the first appearances. >>> >>> Done, added RFC references for those TLAs that have them as well. >>> >>>> Last sentence of section 2.2 should be removed. >>> >>> Done. >>> >>>> In section 3, first sentence, add "In this section," >>> >>> Done. >>> >>>> There are typos, needed to be fixed too: >>>> >>>> Two "the the" in the end of section 2.1.2 and end of section 4; >>> >>> Done >>>> >>>> A couple of "randomn" -> "random"; >>> >>> Done >>>> >>>> "networ" in section 2.1.5; >>> >>> Done >>>> >>>> "jut" -> "just" at the end of section 2.1.6, I guess. >>>> >>>> "The most simple" -> "the simplest" in section 2.17. >>> >>> Done. >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 3 18:00:38 2017 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 3A2D71317FD for ; Mon, 3 Jul 2017 18:00: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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 s6-3kXsRC2G1 for ; Mon, 3 Jul 2017 18:00:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E8D1316A4 for ; Mon, 3 Jul 2017 18:00:33 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 470FD58C4B6; Tue, 4 Jul 2017 03:00:29 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 17F24B0C498; Tue, 4 Jul 2017 03:00:28 +0200 (CEST) Date: Tue, 4 Jul 2017 03:00:28 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170704010028.GE12926@faui40p.informatik.uni-erlangen.de> References: <7ba1c7fb-0041-a740-4e76-c0e56cd32b98@gmail.com> <20170703235202.GC12926@faui40p.informatik.uni-erlangen.de> <5c491c76-1762-03eb-f3ab-1517a447d880@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c491c76-1762-03eb-f3ab-1517a447d880@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] GRASP Python code moved to GitHub X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jul 2017 01:00:36 -0000 Fascinating point. I don't know if the IETF has any arguments to claim anything on any github repository to be IETF work unless it does claim by itself to be IETF work. I would be surprised if it could. Given how i just created a pointer to the work, it definitely could not cause any automatic implication of being IETF work. Cheers Toerless On Tue, Jul 04, 2017 at 12:13:25PM +1200, Brian E Carpenter wrote: > On 04/07/2017 11:52, Toerless Eckert wrote: > > I am still not good with scatter/gather cloud storage, so i created a stub repository to > > point to yours: > > > > https://github.com/anima-wg/grasp > > Th code is not IETF work. It SHOULD NOT be under a repo for the WG. > I had to move it in a hurry due to a mess made by my university's > IT "service". > > Also, is there or isn't there a WG policy on repos for WG drafts? > I'm quite willing to join if there is, but there's never been an > announcement about that and there's nothing about it on > https://datatracker.ietf.org/wg/anima/about/ under Additional URLs > If there's a GitHub organization for the WG, it should be listed > there, I think. > > Brian > > > > > Cheers > > Toerless > > > > On Sun, Jul 02, 2017 at 11:42:07AM +1200, Brian E Carpenter wrote: > >> I have moved the current prototype code for GRASP to GitHub. > >> Please don't use the old URL any more. It will stop working soon. > >> > >> https://github.com/becarpenter/graspy > >> > >> Regards > >> Brian Carpenter > >> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de From nobody Mon Jul 3 22:32:12 2017 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 30EDB124D68 for ; Mon, 3 Jul 2017 22:32:11 -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 4tWf5xArg86c for ; Mon, 3 Jul 2017 22:32:09 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 ED2351200C5 for ; Mon, 3 Jul 2017 22:32:08 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id j186so104654440pge.2 for ; Mon, 03 Jul 2017 22:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:organization:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=B0wmXtDkyQ0EpJIvFtYXNG4yxyHeI9OKoFJCubL0KVs=; b=fTGG/p2O0ntb230pFxwI/XIHuleU4SQ+XmovOb6cb1lSXpOb1yeURHfMYKwg38y2bV b247diU7IiUr3QdSWbKQu9/AT/DeYdk/cupbS+NY2pJcncx5pbZpsu4H9OULGgDf3YmF BaSqbaCx5YmJSHcS7F25gT9Xjy16bJCWswE7Sr8xqxJk5eNXGZUtlKcEG2Xm/SRSddEN rQHHVJ4r57+7mcO23q6SvIHARhBJM/AtDTHiCFwwTdtcYIfzZ6y0tNtNIolXnZRwWIhE I3prQVIZIkgrIQHfDMuPKPWKjRHS88I1h4FyQMzO/DDAUIHt7V2EXoUO16n06/Xuqkhi YNYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:organization:to:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=B0wmXtDkyQ0EpJIvFtYXNG4yxyHeI9OKoFJCubL0KVs=; b=Ofgka+lY6DL75Sy5+iEP1RI43a+QA8N8C2v8eSQEW+L8zJBipluVHLDesWrnWgA3S7 4JueU6IOn5u4u5BINll/zVOOC3jSzWa7JI68GSGNaqtUwB6x+yk2afI7EhYa3SSwyLHo vcpGcBZ0ms/zgQooRE2CD+2RdaWC9lm4ZCq0DovCu/FaWzopXlq++hrzQLMs81e3EVnI m0+KDlheoTw+THSiqEHxbMtAvxNQqWPXT6zEPJg9ZkvwRLzrtACSqkHeUR05sJ2V33fG 1ys+V4mm2rfEaUamqkwjX/K0+KC7M/uvdnLSIO8VdA2hXEdREJVYn9tpMLPJxirvjoFX FTfA== X-Gm-Message-State: AIVw112rkqj26JFmdmawMrMXWdpBnBjvuQ6g+2zssXCKSNXKPl1EyCpq 1qByNnr+L4F//ep1 X-Received: by 10.84.241.4 with SMTP id a4mr14590101pll.160.1499146328368; Mon, 03 Jul 2017 22:32:08 -0700 (PDT) Received: from ?IPv6:2406:e007:4f03:1:28cc:dc4c:9703:6781? ([2406:e007:4f03:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o8sm32172683pgn.52.2017.07.03.22.32.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 22:32:07 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: Date: Tue, 4 Jul 2017 17:32:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jul 2017 05:32:11 -0000 Hi, I am still trying to figure out what you really want to say in sections 3.1.1. Proxy Discovery Protocol Details and 3.1.2. Registrar Discovery Protocol Details. 1. Why doesn't section 3.1.1 mention IP-in-IP (protocol 41)? Surely the pledge needs to know about it? 2. The description is wrong anyway; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.3 for something that can work. 3. In section 3.1.2, as I already pointed out, the proposal is really a misuse of the GRASP discovery response message. Not a problem, we simply replace it with a synchronization response; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.2. But regardless of that, I am confused by the example locators: locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] The first two are OK. The ports announced by the proxy to the pledges may be different. If the registrar sends [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443], the proxy might announce [O_IPv6_LOCATOR, fe80::4321, 6, 9999] - the proxy's link-local address and a different port chosen by the proxy. But the third locator sent by the Registrar indicates a meaningless link-local address, because it could come from many hops away. At first I thought this was a confusion with the previous (proxy-to-pledge) case, where all addresses must be link-local. But no: this text is just confused, I think: A protocol of 41 indicates that packets may be IPIP proxy'ed. In the case of that IPIP proxying is used, then the provided link-local address MUST be advertised on the local link using proxy neighbour discovery. The Join Proxy MAY limit forwarded traffic to the protocol (6 and 17) and port numbers indicated by locator1 and locator2. The address to which the IPIP traffic should be sent is the initiator address (an ACP address of the Registrar), not the address given in the locator. A link local address provided by the Registrar is completely invalid except on the relevant link connected directly to the Registrar. So it definitely must not be given to anybody off that link. At the moment I have no idea how the IP-in-IP is supposed to work. Appendix C doesn't help much. Apart from anything else, it mentions a non-existent GRASP message type. I can sort of see what you want to do, but it isn't a codable spec at the moment. Maybe you can provide a complete example of the packet flow, where the pledge has link-local address Lp, the proxy has link-local address Lx and ACP address Ax, and the registrar has ACP address Ar. And to make my concern clear, the registrar has the link-local address Lp, by chance the same as the pledge, although on a different LAN. Regards Brian From nobody Tue Jul 4 04:31:47 2017 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 A8982131F37 for ; Tue, 4 Jul 2017 04:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 qRI6T5UxOxTw for ; Tue, 4 Jul 2017 04:31:40 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 1AA2C131F36 for ; Tue, 4 Jul 2017 04:31:40 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id i127so135340547wma.0 for ; Tue, 04 Jul 2017 04:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language; bh=9zocPF73myD7JMdZBSV7AEIBBC/sbRS2lRwVl/gj3Uw=; b=OOO1AxOZRfg02OSQrAK02uE60SINNL4S593mAzoTCt6XUhsH9WNqzLXEC1VmXVlZ+g 9mHj6pDiQ/CqRSBp90wiHzea2djXyhCpOBCdoS5d5BekLQfnNpxW9sMcIoAEaRoTG6w9 QJrnmjryEWlvNSNDl5rZrfpbntaECmWooOTiW70FLRRZQ/c5LRA2jDGexZbesSo554Wz 9FvRD8cmcmQ6Y2FyL4NDah13YNLpWukHSdD6SXiKiwp30g/voEOOfrsBHe/GG205sSGe 96yjFobFhm0Q1x5OG+oVmzH39pqVIyz7ZuehH6KUGgCXdYnNo3H842dN/GJrqU7dOTbQ aQww== 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:message-id:date:user-agent :mime-version:content-language; bh=9zocPF73myD7JMdZBSV7AEIBBC/sbRS2lRwVl/gj3Uw=; b=IXJQLVoQC5IX2KdflQcLv357a0wkNiYyBa5Y0bhuFYkzM1R9ODfvKThDuQ9smjByLh hHhvmGsJX3oDzWUw00qyipr/0J1c/qmFnkiXGxL4hMDHdLRh428PS5zxbyt+WwP1FEpg G5RJQ/fFSqua1VwCaLu2w2zU4MJEs+wrAmDsW00BN10WeUSlxM1etLhGmtvlgdX2L5SM FFEWoxD7RZUmneN604TWuk0g3oCua3oAB23YWHUJLEixrnm1M7omGfaDHJHEi9IZxle2 2TOTDu/WspdcE7jpD9KlAtWY9rGzmAgbxCdqaOgv6Oq2WkVJk+WzJ4Pwk+6P691jx83+ Xdng== X-Gm-Message-State: AIVw1120tBe3BSYUrYWHDpr9ThsVKd73VaGKIQmkkmtnec2O5NEudbiB YocUbAI2zKgG965pqWY= X-Received: by 10.28.0.6 with SMTP id 6mr9338771wma.37.1499167898396; Tue, 04 Jul 2017 04:31:38 -0700 (PDT) Received: from [192.168.1.25] (ANice-652-1-72-84.w86-205.abo.wanadoo.fr. [86.205.71.84]) by smtp.gmail.com with ESMTPSA id 185sm6804921wmn.33.2017.07.04.04.31.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 04:31:36 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: "anima@ietf.org" Message-ID: Date: Tue, 4 Jul 2017 13:31:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------195FB27FA2CF5D1A5A8257E2" Content-Language: en-GB Archived-At: Subject: [Anima] draft-ietf-anima-reference-model-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jul 2017 11:31:46 -0000 This is a multi-part message in MIME format. --------------195FB27FA2CF5D1A5A8257E2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As promised, here the new version of the reference model draft. I'll be submitting in a minute, the github repo already has it: https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model-04.txt. The diff is attached for easy consumption. As suggested by Brian, I re-read the draft, and changed the general wording in some places regarding "work in progress", etc. I now call this AN phase 1, and explain that there may be more phases. Changed the security section almost completely, taking into account the comments received. Specifically, pointing out the threats on the ACP. I was about to add a comparison to the security of the routing system, but in the end decided against. Folks - please review and let me know how this reads. In the security section we had the phrase: "AN messages are liable to be exposed to third parties on any unprotected Layer 2 link." I think this is only true for specific discovery-like messages like GRASP M_FLOOD, but by default most AN messages are inside the ACP and thus encrypted. So I suggest to change this rather scary sounding sentence, and point out that only specific messages are unprotected, and point to section 2.5.2 of the GRASP draft. Updated a few references, editorial stuff, etc. I suggest the draft is ready for WGLC, and would request the chairs to issue that call. Michael --------------195FB27FA2CF5D1A5A8257E2 Content-Type: text/html; charset=UTF-8; name="Diff: draft-ietf-anima-reference-model-03.txt - draft-ietf-anima-reference-model-04.txt.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="Diff: draft-ietf-anima-reference-model-03.txt - draft-ietf-a"; filename*1="nima-reference-model-04.txt.html" CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRp b25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFu c2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NTogcmZjZGlm ZiAgLS0+IAo8IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0 LjAxIFRyYW5zaXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGR1cmlmIDMuMi4w LTQtYW1kNjQgIzEgU01QIERlYmlhbiAzLjIuODQtMSB4ODZfNjQgR05VL0xpbnV4IC0tPiAK PCEtLSBVc2luZyBhd2s6IC91c3IvYmluL2dhd2s6IEdOVSBBd2sgNC4wLjEgLS0+IAo8IS0t IFVzaW5nIGRpZmY6IC91c3IvYmluL2RpZmY6IGRpZmYgKEdOVSBkaWZmdXRpbHMpIDMuMiAt LT4gCjwhLS0gVXNpbmcgd2RpZmY6IC91c3IvYmluL3dkaWZmOiB3ZGlmZiAoR05VIHdkaWZm KSAxLjEuMiAtLT4gCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1s Ij4gCjxoZWFkPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCIgLz4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyIgLz4gCiAgPHRpdGxlPkRpZmY6 IGRyYWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTAzLnR4dCAtIGRyYWZ0LWlldGYt YW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0LnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0 ZXh0L2NzcyI+IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDog YXV0bzsgfSAKICAgIHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBw cmU7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQt c2l6ZTogMC44NmVtO30gCiAgICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAg ICAuc21hbGwgIHsgZm9udC1zaXplOiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250 LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQg ICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3Vu ZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NG OyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gCiAgICAucmJs b2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAgIC5pbnNlcnQgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNB Q0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGQjsgfSAKICAgIC5j b250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmViciB7IGJhY2tn cm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsgYmFja2dy b3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmlnaHQ7 IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAg ICAucmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9j ayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250 IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQt Y29sb3I6ICM4QUQ7IH0gCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFj a2dyb3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUg eyBkaXNwbGF5OiBub25lOyBjb2xvcjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3Bs YXk6IGlubGluZTsgfSAgICB0ci5jaGFuZ2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9 IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFj ayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+CnZhciBjaHVua19pbmRleCA9IDA7CnZh ciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9ybWF0X2NodW5rKGluZGV4KSB7CiAg ICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9IGluZGV4LnRvU3RyaW5nKCk7 CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7CiAgICAgICAgcHJlZml4 Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9CgpmdW5jdGlvbiBmaW5k X2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3IoJ3RyW2lkJD0i JyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkgewogICAg dmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsKICAg IHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmsp IHsKICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAg b2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5l d19jaHVuazsKICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQi OwogICAgd2luZG93LmxvY2F0aW9uLmhhc2ggPSAiIyIgKyBuZXdfc3RyOwogICAgd2luZG93 LnNjcm9sbEJ5KDAsLTEwMCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9Cgpkb2N1bWVu dC5vbmtleWRvd24gPSBmdW5jdGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5Q29kZSkgewog ICAgY2FzZSA3ODoKICAgICAgICBjaGFuZ2VfY2h1bmsoMSk7CiAgICAgICAgYnJlYWs7CiAg ICBjYXNlIDgwOgogICAgICAgIGNoYW5nZV9jaHVuaygtMSk7CiAgICAgICAgYnJlYWs7CiAg ICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFkPiAKPGJvZHkgPiAKICA8dGFibGUgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dHIgaWQ9InBhcnQt MSIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMy50eHQiIHN0eWxlPSJjb2xv cjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZsdDs8L2E+Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNl LW1vZGVsLTAzLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtYW5pbWEtcmVm ZXJlbmNlLW1vZGVsLTAzLnR4dDwvYT4mbmJzcDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEt cmVmZXJlbmNlLW1vZGVsLTA0LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYt YW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0LnR4dDwvYT4mbmJzcDs8YSBocmVmPSIvcmZjZGlm Zj91cmwxPWRyYWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0LnR4dCIgc3R5bGU9 ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3RoPjx0aD48 L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPkFOSU1BICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNLiBCZWhyaW5nZXIsIEVkLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPkFOSU1BICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNLiBCZWhyaW5nZXIsIEVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJhZnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50 ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQi4gQ2FycGVudGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZW5k ZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Qi4gQ2FycGVudGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJk ZWxldGUiPlNlcHRlbWJlciAxNCwgMjAxNzwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgVW5pdi4gb2YgQXVja2xhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+RXhwaXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+SmFudWFyeSA0LCAyMDE4ICAgPC9z cGFuPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2LiBvZiBBdWNrbGFuZDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gRWNrZXJ0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gRWNrZXJ0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGdXR1cmV3ZWkgVGVjaG5vbG9naWVzIEluYy48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGdXR1cmV3ZWkgVGVjaG5vbG9naWVzIEluYy48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEwuIENpYXZhZ2xpYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEwuIENpYXZhZ2xpYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUC4gUGVsb3NvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUC4gUGVsb3NvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTm9raWE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEIuIExpdTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEIuIExpdTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIdWF3ZWkgVGVjaG5vbG9n aWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIdWF3ZWkgVGVjaG5vbG9naWVz PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gTm9icmU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gTm9icmU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZlZGVyYWwgVW5pdmVyc2l0eSBvZiBSaW8gR3JhbmRlIGRvIFN1bDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEZlZGVyYWwgVW5pdmVyc2l0eSBvZiBSaW8gR3JhbmRlIGRvIFN1bDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gU3RyYXNzbmVyPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSi4gU3RyYXNzbmVyPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEh1YXdlaSBUZWNobm9sb2dpZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEh1YXdlaSBUZWNobm9sb2dpZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPk1hcmNoIDE8L3NwYW4+MywgMjAxNzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ICBKdWx5IDwvc3Bh bj4zLCAyMDE3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgIEEgUmVmZXJlbmNlIE1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2lu ZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgIEEgUmVm ZXJlbmNlIE1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0w PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2Ut bW9kZWwtMDxzcGFuIGNsYXNzPSJpbnNlcnQiPjQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSByZWZlcmVuY2UgbW9kZWwg Zm9yIEF1dG9ub21pYyBOZXR3b3JraW5nLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcmVmZXJlbmNlIG1vZGVsIGZvciBB dXRvbm9taWMgTmV0d29ya2luZy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFRoZSBnb2FsIGlzIHRvIGRlZmluZSBob3cgdGhlIHZhcmlvdXMgZWxlbWVudHMgaW4gYW4g YXV0b25vbWljPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGdvYWwg aXMgdG8gZGVmaW5lIGhvdyB0aGUgdmFyaW91cyBlbGVtZW50cyBpbiBhbiBhdXRvbm9taWM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbnRleHQgd29yayB0b2dldGhl ciwgdG8gZGVzY3JpYmUgdGhlaXIgaW50ZXJmYWNlcyBhbmQgcmVsYXRpb25zLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRleHQgd29yayB0b2dldGhlciwgdG8g ZGVzY3JpYmUgdGhlaXIgaW50ZXJmYWNlcyBhbmQgcmVsYXRpb25zLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2hpbGUgdGhlIGRvY3VtZW50IGlzIHdyaXR0ZW4gYXMg Z2VuZXJhbGx5IGFzIHBvc3NpYmxlLCB0aGUgaW5pdGlhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFdoaWxlIHRoZSBkb2N1bWVudCBpcyB3cml0dGVuIGFzIGdlbmVy YWxseSBhcyBwb3NzaWJsZSwgdGhlIGluaXRpYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHNvbHV0aW9ucyBhcmUgbGltaXRlZCB0byB0aGUgY2hhcnRlcmVkIHNjb3Bl IG9mIHRoZSBXRy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzb2x1dGlv bnMgYXJlIGxpbWl0ZWQgdG8gdGhlIGNoYXJ0ZXJlZCBzY29wZSBvZiB0aGUgV0cuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlN0YXR1cyBvZiBUaGlzIE1l bW88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5TdGF0dXMgb2YgVGhpcyBNZW1v PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSAx LCBsaW5lIDQ2PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90 aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxh IGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBsaW5lIDQ2PHNwYW4gY2xhc3M9ImhpZGUi PiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1E cmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu ZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUg dGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBE cmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50 Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0 ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g PHNwYW4gY2xhc3M9ImRlbGV0ZSI+U2VwdGVtYmVyIDE0LCAyMDE3PC9zcGFuPi48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5KYW51YXJ5IDQsIDIwMTg8L3NwYW4+ LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQg Tm90aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGlj ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb3B5cmln aHQgKGMpIDIwMTcgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb3B5cmlnaHQgKGMpIDIw MTcgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmln aHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3Vt ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g QkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChodHRwOi8vdHJ1c3Rl ZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9y Zy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBs ZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0zIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+ PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0 LTMiPjxlbT4gcGFnZSAzLCBsaW5lIDE1PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3Nw YW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTMiPjxlbT4gcGFnZSAzLCBsaW5lIDE1PHNw YW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgIDcuMi4gIEludGVudCAoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgIDcuMi4gIEludGVudCAoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg Ny4zLiAgQWdncmVnYXRlZCBSZXBvcnRpbmcgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNy4z LiAgQWdncmVnYXRlZCBSZXBvcnRpbmcgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxOTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjQuICBG ZWVkYmFjayBMb29wcyB0byBOT0MoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDIwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjQuICBGZWVk YmFjayBMb29wcyB0byBOT0MoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDIwPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDcuNS4gIENvbnRyb2wg TG9vcHMgKCopIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjA8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDcuNS4gIENvbnRyb2wgTG9v cHMgKCopIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjA8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNy42LiAgQVBJcyAoKikgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNy42LiAgQVBJcyAoKikgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjcuICBEYXRhIE1vZGVsICgqKSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIxPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjcuICBEYXRhIE1vZGVsICgqKSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIxPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICA4LiAgQ29vcmRpbmF0aW9uIEJldHdlZW4gQXV0b25vbWljIEZ1 bmN0aW9ucyAoKikgIC4gLiAuIC4gLiAuIC4gLiAgMjI8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICA4LiAgQ29vcmRpbmF0aW9uIEJldHdlZW4gQXV0b25vbWljIEZ1bmN0 aW9ucyAoKikgIC4gLiAuIC4gLiAuIC4gLiAgMjI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgOC4xLiAgVGhlIENvb3JkaW5hdGlvbiBQcm9ibGVtICgqKSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgOC4xLiAgVGhlIENvb3JkaW5hdGlvbiBQcm9ibGVtICgqKSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAyMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICA4LjIuICBBIENvb3JkaW5hdGlvbiBGdW5jdGlvbmFsIEJsb2NrICgqKSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDIzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICA4LjIuICBBIENvb3JkaW5hdGlvbiBGdW5jdGlvbmFsIEJsb2NrICgqKSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDIzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA5LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA5LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMjQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA5LjEuICA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5UaHJlYXQgQW5hbHlzaXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuPC9zcGFuPiAuIC4g LiAuIC4gLiAuIC4gLiAuICAyNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgIDkuMS4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkNvbnNlcXVlbmNlcyBvZiBhIERpc3Ry aWJ1dGVkIFN5c3RlbSA8L3NwYW4+IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDkuMi4gIFNlY3VyaXR5IE1lY2hhbmlzbXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDkuMi4gIFNlY3VyaXR5IE1lY2hhbmlzbXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgMTEuIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgMTEuIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAxMi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAxMi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1 dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAyNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dGhv cnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAyNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4x LiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4gIElu dHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBUaGUgZG9jdW1lbnQgIkF1dG9ub21pYyBOZXR3b3JraW5nIC0gRGVmaW5pdGlvbnMgYW5k IERlc2lnbiBHb2FscyI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUg ZG9jdW1lbnQgIkF1dG9ub21pYyBOZXR3b3JraW5nIC0gRGVmaW5pdGlvbnMgYW5kIERlc2ln biBHb2FscyI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3NTc1XSBl eHBsYWlucyB0aGUgZnVuZGFtZW50YWwgY29uY2VwdHMgYmVoaW5kIEF1dG9ub21pYzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM3NTc1XSBleHBsYWlucyB0aGUg ZnVuZGFtZW50YWwgY29uY2VwdHMgYmVoaW5kIEF1dG9ub21pYzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNCIgY2xh c3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0 PC9zbWFsbD48YSBocmVmPSIjcGFydC00Ij48ZW0+IHBhZ2UgMywgbGluZSA0MjxzcGFuIGNs YXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC00Ij48 ZW0+IHBhZ2UgMywgbGluZSA0MjxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwv ZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXJjaGl0ZWN0dXJhbGx5IGNvbnNpc3RlbnQs IG5vbi1vdmVybGFwcGluZyBtYW5uZXIuICBXaGlsZSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBhcmNoaXRlY3R1cmFsbHkgY29uc2lzdGVudCwgbm9uLW92ZXJs YXBwaW5nIG1hbm5lci4gIFdoaWxlIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgZG9jdW1lbnQgaXMgd3JpdHRlbiBhcyBnZW5lcmFsbHkgYXMgcG9zc2libGUsIHRo ZSBpbml0aWFsIHNvbHV0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGRvY3VtZW50IGlzIHdyaXR0ZW4gYXMgZ2VuZXJhbGx5IGFzIHBvc3NpYmxlLCB0aGUgaW5p dGlhbCBzb2x1dGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFyZSBs aW1pdGVkIHRvIHRoZSBjaGFydGVyZWQgc2NvcGUgb2YgdGhlIFdHLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFyZSBsaW1pdGVkIHRvIHRoZSBjaGFydGVyZWQgc2Nv cGUgb2YgdGhlIFdHLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBBcyBkaXNjdXNzZWQgaW4gW1JGQzc1NzVdLCB0aGUgZ29hbCBvZiB0aGlzIHdvcmsg aXMgbm90IHRvIGZvY3VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXMg ZGlzY3Vzc2VkIGluIFtSRkM3NTc1XSwgdGhlIGdvYWwgb2YgdGhpcyB3b3JrIGlzIG5vdCB0 byBmb2N1czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZXhjbHVzaXZlbHkg b24gZnVsbHkgYXV0b25vbWljIG5vZGVzIG9yIG5ldHdvcmtzLiAgSW4gcmVhbGl0eSwgbW9z dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4Y2x1c2l2ZWx5IG9uIGZ1 bGx5IGF1dG9ub21pYyBub2RlcyBvciBuZXR3b3Jrcy4gIEluIHJlYWxpdHksIG1vc3Q8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5ldHdvcmtzIHdpbGwgcnVuIHdpdGgg c29tZSBhdXRvbm9taWMgZnVuY3Rpb25zLCB3aGlsZSB0aGUgcmVzdCBvZjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5ldHdvcmtzIHdpbGwgcnVuIHdpdGggc29tZSBh dXRvbm9taWMgZnVuY3Rpb25zLCB3aGlsZSB0aGUgcmVzdCBvZjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIG5ldHdvcmsgaXMgdHJhZGl0aW9uYWxseSBtYW5hZ2Vk LiAgVGhpcyByZWZlcmVuY2UgbW9kZWwgYWxsb3dzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgdGhlIG5ldHdvcmsgaXMgdHJhZGl0aW9uYWxseSBtYW5hZ2VkLiAgVGhp cyByZWZlcmVuY2UgbW9kZWwgYWxsb3dzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBmb3IgdGhpcyBoeWJyaWQgYXBwcm9hY2guPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgZm9yIHRoaXMgaHlicmlkIGFwcHJvYWNoLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIFRoaXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aXMgYSBsaXZpbmc8 L3NwYW4+IGRvY3VtZW50IGFuZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj53aWxsIGV2b2x2ZSB3 aXRoPC9zcGFuPiB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGVjaG5pY2FsPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIGRvY3VtZW50IDxzcGFu IGNsYXNzPSJpbnNlcnQiPmRlc2NyaWJlcyBwaGFzZSAxIG9mIGFuIEF1dG9ub21pYyBOZXR3 b3JraW5nIHNvbHV0aW9uLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgc29sdXRpb25zIGRldmVsb3BlZCBpbjwvc3Bh bj4gdGhlIEFOSU1BIDxzcGFuIGNsYXNzPSJkZWxldGUiPldHLjwvc3Bhbj4gIFNlY3Rpb25z IG1hcmtlZCB3aXRoICgqKSBkbyBub3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNvdmVycyBwcmltYXJpbHk8L3NwYW4+ IHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5XRyBpdGVtcyBvZjwvc3Bhbj4gdGhlIEFOSU1B IDxzcGFuIGNsYXNzPSJpbnNlcnQiPldHIGFzIG9mIEp1bHkgMjAxNy48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlcHJlc2VudCA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5jdXJyZW50IGNoYXJ0ZXIgaXRlbXMuICBXaGlsZSB0aGlzIGRvY3VtZW50IG11 c3QgZ2l2ZSBhPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBT ZWN0aW9ucyBtYXJrZWQgd2l0aCAoKikgZG8gbm90IHJlcHJlc2VudCA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5jaGFydGVyZWQgaXRlbXM8L3NwYW4+IGF0IDxzcGFuIGNsYXNzPSJpbnNlcnQi PnRoaXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgIGxvbmcgdGVybSBhcmNoaXRlY3R1cmFsIHZpZXcsIG5vdCBhbGwg ZnVuY3Rpb25zIHdpbGwgYmUgc3RhbmRhcmRpemVkPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICB0aW1lLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+TmV3IFdH IGl0ZW1zIHdpbGwgcmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCwgb3I8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGF0IDxzcGFuIGNsYXNz PSJkZWxldGUiPnRoZSBzYW1lPC9zcGFuPiB0aW1lLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBwb3RlbnRpYWxseSBhIG5ldyBk b2N1bWVudC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjIuICBUaGUgTmV0d29yayBWaWV3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+Mi4gIFRoZSBOZXR3b3JrIFZpZXc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgdmFyaW91cyBlbGVt ZW50cyBpbiBhIG5ldHdvcmsgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHZhcmlvdXMgZWxlbWVudHMgaW4gYSBu ZXR3b3JrIHdpdGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dG9ub21p YyBmdW5jdGlvbnMsIGFuZCBob3cgdGhlc2UgZW50aXRpZXMgd29yayB0b2dldGhlciwgb24g YSBoaWdoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXV0b25vbWljIGZ1 bmN0aW9ucywgYW5kIGhvdyB0aGVzZSBlbnRpdGllcyB3b3JrIHRvZ2V0aGVyLCBvbiBhIGhp Z2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxldmVsLiAgU3Vic2VxdWVu dCBzZWN0aW9ucyBleHBsYWluIHRoZSBkZXRhaWxlZCBpbnNpZGUgdmlldyBmb3IgZWFjaDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxldmVsLiAgU3Vic2VxdWVudCBz ZWN0aW9ucyBleHBsYWluIHRoZSBkZXRhaWxlZCBpbnNpZGUgdmlldyBmb3IgZWFjaDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIGF1dG9ub21pYyBuZXR3b3Jr IGVsZW1lbnRzLCBhcyB3ZWxsIGFzIHRoZSBuZXR3b3JrIGZ1bmN0aW9uczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIHRoZSBhdXRvbm9taWMgbmV0d29yayBlbGVt ZW50cywgYXMgd2VsbCBhcyB0aGUgbmV0d29yayBmdW5jdGlvbnM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIChvciBpbnRlcmZhY2VzKSBiZXR3ZWVuIHRob3NlIGVsZW1l bnRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChvciBpbnRlcmZhY2Vz KSBiZXR3ZWVuIHRob3NlIGVsZW1lbnRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBGaWd1cmUgMSBzaG93cyB0aGUgaGlnaCBsZXZlbCB2aWV3IG9m IGFuIEF1dG9ub21pYyBOZXR3b3JrLiAgSXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBGaWd1cmUgMSBzaG93cyB0aGUgaGlnaCBsZXZlbCB2aWV3IG9mIGFuIEF1dG9u b21pYyBOZXR3b3JrLiAgSXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTUiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90 ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3Bh cnQtNSI+PGVtPiBwYWdlIDcsIGxpbmUgMTA8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNSI+PGVtPiBwYWdlIDcsIGxpbmUgMTA8 c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIG8gIFZlbmRvciByZS1kaXJlY3Q6IEEgbmV3IGRldmljZSBtYXkgcmVjZWl2ZSBp bmZvcm1hdGlvbiBvbiB3aGVyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG8gIFZlbmRvciByZS1kaXJlY3Q6IEEgbmV3IGRldmljZSBtYXkgcmVjZWl2ZSBpbmZvcm1h dGlvbiBvbiB3aGVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgaXRz IGhvbWUgbmV0d29yayBpcyB0aHJvdWdoIGEgdmVuZG9yIGJhc2VkIE1BU0EgcmUtZGlyZWN0 OyB0aGlzIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgaXRzIGhv bWUgbmV0d29yayBpcyB0aHJvdWdoIGEgdmVuZG9yIGJhc2VkIE1BU0EgcmUtZGlyZWN0OyB0 aGlzIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0eXBpY2FsbHkg YSByb3V0YWJsZSBhZGRyZXNzLiAgU2VlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgdHlwaWNhbGx5IGEgcm91dGFibGUgYWRkcmVzcy4gIFNlZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJhcHBp bmcta2V5aW5mcmFdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFtJ LUQuaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhXS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgTm9uLWF1dG9ub21pYyBpbnB1dDog QSBub2RlIG1heSBiZSBjb25maWd1cmVkIG1hbnVhbGx5IHdpdGggYW48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBOb24tYXV0b25vbWljIGlucHV0OiBBIG5vZGUg bWF5IGJlIGNvbmZpZ3VyZWQgbWFudWFsbHkgd2l0aCBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgYXV0b25vbWljIHBlZXI7IGl0IGNvdWxkIGxlYXJuIGFib3V0 IGF1dG9ub21pYyBub2RlcyB0aHJvdWdoIERIQ1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBhdXRvbm9taWMgcGVlcjsgaXQgY291bGQgbGVhcm4gYWJvdXQgYXV0 b25vbWljIG5vZGVzIHRocm91Z2ggREhDUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgb3B0aW9ucywgRE5TLCBhbmQgb3RoZXIgbm9uLWF1dG9ub21pYyBtZWNoYW5p c21zLiAgR2VuZXJhbGx5IHN1Y2g8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICBvcHRpb25zLCBETlMsIGFuZCBvdGhlciBub24tYXV0b25vbWljIG1lY2hhbmlzbXMu ICBHZW5lcmFsbHkgc3VjaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg bm9uLWF1dG9ub21pYyBtZWNoYW5zaW1zIHJlcXVpcmUgc29tZSBhZG1pbmlzdHJhdG9yIGlu dGVydmVudGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBub24t YXV0b25vbWljIG1lY2hhbnNpbXMgcmVxdWlyZSBzb21lIGFkbWluaXN0cmF0b3IgaW50ZXJ2 ZW50aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgVGhlIGtleSBw dXJwb3NlIGlzIHRvIGJ5LXBhc3MgYSBub24tYXV0b25vbWljIGRldmljZSBvciBuZXR3b3Jr LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoZSBrZXkgcHVycG9z ZSBpcyB0byBieS1wYXNzIGEgbm9uLWF1dG9ub21pYyBkZXZpY2Ugb3IgbmV0d29yay48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDci Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgQXMgdGhpcyBwZXJ0YWlucyB0byBuZXcgZGV2aWNlcywg aXQgaXMgY292ZXJlZCBpbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5TZWN0aW9uIDUuMzwvc3Bh bj4gb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgQXMgdGhpcyBw ZXJ0YWlucyB0byBuZXcgZGV2aWNlcywgaXQgaXMgY292ZXJlZCBpbiA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5BcHBlbmRpeCBBIGFuZCBCPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZy YV0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIG9mIFtJLUQuaWV0 Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhXS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGFkamFjZW5jeSB0YWJsZSBpcyBkZWZpbmlu ZyB0aGUgYmVoYXZpb3VyIG9mIGFuIGF1dG9ub21pYyBub2RlOjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBhZGphY2VuY3kgdGFibGUgaXMgZGVmaW5pbmcgdGhl IGJlaGF2aW91ciBvZiBhbiBhdXRvbm9taWMgbm9kZTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgSWYgdGhlIG5vZGUgaGFzIG5vdCBib290c3Ry YXBwZWQgaW50byBhIGRvbWFpbiAoaS5lLiwgZG9lc24ndCBoYXZlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgSWYgdGhlIG5vZGUgaGFzIG5vdCBib290c3RyYXBw ZWQgaW50byBhIGRvbWFpbiAoaS5lLiwgZG9lc24ndCBoYXZlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICBhIGRvbWFpbiBjZXJ0aWZpY2F0ZSksIGl0IHJvdGF0ZXMg dGhyb3VnaCBhbGwgbm9kZXMgaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgYSBkb21haW4gY2VydGlmaWNhdGUpLCBpdCByb3RhdGVzIHRocm91Z2ggYWxs IG5vZGVzIGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYWRq YWNlbmN5IHRhYmxlIHRoYXQgY2xhaW0gdG8gaGF2ZSBhIGRvbWFpbiwgYW5kIHdpbGwgYXR0 ZW1wdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGFkamFjZW5jeSB0 YWJsZSB0aGF0IGNsYWltIHRvIGhhdmUgYSBkb21haW4sIGFuZCB3aWxsIGF0dGVtcHQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGJvb3RzdHJhcHBpbmcgdGhyb3Vn aCB0aGVtLCBvbmUgYnkgb25lLiAgT25lIHBvc3NpYmxlIHJlc3BvbnNlIGlzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYm9vdHN0cmFwcGluZyB0aHJvdWdoIHRo ZW0sIG9uZSBieSBvbmUuICBPbmUgcG9zc2libGUgcmVzcG9uc2UgaXM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGEgdmVuZG9yIE1BU0EgcmUtZGlyZWN0LCB3aGlj aCB3aWxsIGJlIGVudGVyZWQgaW50byB0aGUgYWRqYWNlbmN5PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgYSB2ZW5kb3IgTUFTQSByZS1kaXJlY3QsIHdoaWNoIHdp bGwgYmUgZW50ZXJlZCBpbnRvIHRoZSBhZGphY2VuY3k8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgIHRhYmxlIChzZWUgc2Vjb25kIGJ1bGxldCBhYm92ZSkuICBTZWU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0YWJsZSAoc2VlIHNlY29u ZCBidWxsZXQgYWJvdmUpLiAgU2VlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV0uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJh cHBpbmcta2V5aW5mcmFdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNiIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3Rk Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFy dC02Ij48ZW0+IHBhZ2UgMTEsIGxpbmUgNDk8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNiI+PGVtPiBwYWdlIDExLCBsaW5lIDQ5 PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRodXMgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc20gY291bGQg ZWl0aGVyIGJlIGZ1bGx5IGludGVncmF0ZWQgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFRodXMgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc20gY291bGQgZWl0aGVy IGJlIGZ1bGx5IGludGVncmF0ZWQgd2l0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgYXV0b25vbWljIHNpZ25hbGluZyAobmV4dCBzZWN0aW9uKSBvciBjb3VsZCB1c2Ug YW4gaW5kZXBlbmRlbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdXRv bm9taWMgc2lnbmFsaW5nIChuZXh0IHNlY3Rpb24pIG9yIGNvdWxkIHVzZSBhbiBpbmRlcGVu ZGVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGlzY292ZXJ5IG1lY2hh bmlzbSBzdWNoIGFzIEROUyBTZXJ2aWNlIERpc2NvdmVyeSBvciBTZXJ2aWNlIExvY2F0aW9u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGlzY292ZXJ5IG1lY2hhbmlz bSBzdWNoIGFzIEROUyBTZXJ2aWNlIERpc2NvdmVyeSBvciBTZXJ2aWNlIExvY2F0aW9uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm90b2NvbC4gIFRoaXMgY2hvaWNl IGNvdWxkIGJlIG1hZGUgaW5kZXBlbmRlbnRseSBmb3IgZWFjaCBBdXRvbm9taWM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm90b2NvbC4gIFRoaXMgY2hvaWNlIGNv dWxkIGJlIG1hZGUgaW5kZXBlbmRlbnRseSBmb3IgZWFjaCBBdXRvbm9taWM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlcnZpY2UgQWdlbnQsIGFsdGhvdWdoIHRoZSBp bmZyYXN0cnVjdHVyZSBtaWdodCByZXF1aXJlIHNvbWUgbWluaW1hbDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNlcnZpY2UgQWdlbnQsIGFsdGhvdWdoIHRoZSBpbmZy YXN0cnVjdHVyZSBtaWdodCByZXF1aXJlIHNvbWUgbWluaW1hbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciAoZS5nLiwgZm9y IGRpc2NvdmVyaW5nIHRoZSBzZWN1cml0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IgKGUuZy4sIGZvciBkaXNjb3Zlcmlu ZyB0aGUgc2VjdXJpdHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJvb3Rz dHJhcCBtZWNoYW5pc20sIG9yIHRoZSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gZGlzdHJpYnV0 aW9uLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJvb3RzdHJhcCBtZWNo YW5pc20sIG9yIHRoZSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uLDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2VjdGlvbiA0LjcpLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNlY3Rpb24gNC43KS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGUgY3VycmVudGx5IHBy b3Bvc2VkIHByb3RvY29sPC9zcGFuPiBmb3IgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bm9kZSBk aXNjb3ZlcnkgaXMgR1JBU1AsPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5QaGFzZSAxIG9mIEF1dG9ub21pYyBOZXR3 b3JraW5nIHVzZXMgR1JBU1A8L3NwYW4+IGZvciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kaXNj b3ZlcnksPC9zcGFuPiBkZXNjcmliZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1hbmltYS1ncmFzcF0uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGluIFtJLUQuaWV0Zi1hbmltYS1ncmFzcF0uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuNC4gIFNpZ25hbGlu ZyBCZXR3ZWVuIEF1dG9ub21pYyBOb2RlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjQuNC4gIFNpZ25hbGluZyBCZXR3ZWVuIEF1dG9ub21pYyBOb2RlczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRvbm9taWMgbm9kZXMgbXVz dCBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIsIGZvciBleGFtcGxlIHRvPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXV0b25vbWljIG5vZGVzIG11c3QgY29tbXVu aWNhdGUgd2l0aCBlYWNoIG90aGVyLCBmb3IgZXhhbXBsZSB0bzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgbmVnb3RpYXRlIGFuZC9vciBzeW5jaHJvbml6ZSB0ZWNobmlj YWwgb2JqZWN0aXZlcyAoaS5lLiwgbmV0d29yazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG5lZ290aWF0ZSBhbmQvb3Igc3luY2hyb25pemUgdGVjaG5pY2FsIG9iamVj dGl2ZXMgKGkuZS4sIG5ldHdvcms8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHBhcmFtZXRlcnMpIG9mIGFueSBraW5kIGFuZCBjb21wbGV4aXR5LiAgVGhpcyByZXF1aXJl cyBzb21lIGZvcm0gb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwYXJh bWV0ZXJzKSBvZiBhbnkga2luZCBhbmQgY29tcGxleGl0eS4gIFRoaXMgcmVxdWlyZXMgc29t ZSBmb3JtIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzaWduYWxpbmcg YmV0d2VlbiBhdXRvbm9taWMgbm9kZXMuICBBdXRvbm9taWMgbm9kZXMgaW1wbGVtZW50aW5n IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzaWduYWxpbmcgYmV0d2Vl biBhdXRvbm9taWMgbm9kZXMuICBBdXRvbm9taWMgbm9kZXMgaW1wbGVtZW50aW5nIGE8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpZmljIHVzZSBjYXNlIG1pZ2h0 IGNob29zZSB0aGVpciBvd24gc2lnbmFsaW5nIHByb3RvY29sLCBhcyBsb25nPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWMgdXNlIGNhc2UgbWlnaHQgY2hv b3NlIHRoZWlyIG93biBzaWduYWxpbmcgcHJvdG9jb2wsIGFzIGxvbmc8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFzIGl0IGZpdHMgdGhlIG92ZXJhbGwgc2VjdXJpdHkg bW9kZWwuICBIb3dldmVyLCBpbiB0aGUgZ2VuZXJhbCBjYXNlLDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGFzIGl0IGZpdHMgdGhlIG92ZXJhbGwgc2VjdXJpdHkgbW9k ZWwuICBIb3dldmVyLCBpbiB0aGUgZ2VuZXJhbCBjYXNlLDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgYW55IHBhaXIgb2YgYXV0b25vbWljIG5vZGVzIG1pZ2h0IG5lZWQg dG8gY29tbXVuaWNhdGUsIHNvIHRoZXJlIG5lZWRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYW55IHBhaXIgb2YgYXV0b25vbWljIG5vZGVzIG1pZ2h0IG5lZWQgdG8g Y29tbXVuaWNhdGUsIHNvIHRoZXJlIG5lZWRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC03IiBjbGFzcz0iY2hhbmdl IiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxh IGhyZWY9IiNwYXJ0LTciPjxlbT4gcGFnZSAxMiwgbGluZSAyNTxzcGFuIGNsYXNzPSJoaWRl Ij4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC03Ij48ZW0+IHBhZ2Ug MTIsIGxpbmUgMjU8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGF1dG9ub21pYyBub2RlcyBjYW4gZGlzY292ZXIgZWFjaCBv dGhlciB3aXRob3V0IGFueSBwcmVjb25maWd1cmF0aW9uLDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGF1dG9ub21pYyBub2RlcyBjYW4gZGlzY292ZXIgZWFjaCBvdGhl ciB3aXRob3V0IGFueSBwcmVjb25maWd1cmF0aW9uLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYXMgbWVudGlvbmVkIGFib3ZlLiAgVG8gYmUgZ2VuZXJpYywgZGlzY292 ZXJ5IGFuZCBzaWduYWxpbmcgbXVzdCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGFzIG1lbnRpb25lZCBhYm92ZS4gIFRvIGJlIGdlbmVyaWMsIGRpc2NvdmVyeSBh bmQgc2lnbmFsaW5nIG11c3QgYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGFibGUgdG8gaGFuZGxlIGFueSBzb3J0IG9mIHRlY2huaWNhbCBvYmplY3RpdmUsIGluY2x1 ZGluZyBvbmVzIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhYmxl IHRvIGhhbmRsZSBhbnkgc29ydCBvZiB0ZWNobmljYWwgb2JqZWN0aXZlLCBpbmNsdWRpbmcg b25lcyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXF1aXJlIGNv bXBsZXggZGF0YSBzdHJ1Y3R1cmVzLiAgVGhlIGRvY3VtZW50ICJBIEdlbmVyaWMgQXV0b25v bWljPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVxdWlyZSBjb21wbGV4 IGRhdGEgc3RydWN0dXJlcy4gIFRoZSBkb2N1bWVudCAiQSBHZW5lcmljIEF1dG9ub21pYzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2lnbmFsaW5nIFByb3RvY29sIChH UkFTUCkiIFtJLUQuaWV0Zi1hbmltYS1ncmFzcF0gZGVzY3JpYmVzIG1vcmU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTaWduYWxpbmcgUHJvdG9jb2wgKEdSQVNQKSIg W0ktRC5pZXRmLWFuaW1hLWdyYXNwXSBkZXNjcmliZXMgbW9yZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIGZvciBkaXNjb3Zlcnks IG5lZ290aWF0aW9uIGFuZCBzeW5jaHJvbml6YXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBkZXRhaWxlZCByZXF1aXJlbWVudHMgZm9yIGRpc2NvdmVyeSwgbmVn b3RpYXRpb24gYW5kIHN5bmNocm9uaXphdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgaW4gYW4gYXV0b25vbWljIG5ldHdvcmsuICBJdCBhbHNvIGRlZmluZXMgYSBw cm90b2NvbCwgR1JBU1AsIGZvciB0aGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgaW4gYW4gYXV0b25vbWljIG5ldHdvcmsuICBJdCBhbHNvIGRlZmluZXMgYSBwcm90 b2NvbCwgR1JBU1AsIGZvciB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBwdXJwb3NlLCBpbmNsdWRpbmcgYW4gaW50ZWdyYXRlZCBidXQgb3B0aW9uYWwgZGlzY292 ZXJ5IHByb3RvY29sLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1cnBv c2UsIGluY2x1ZGluZyBhbiBpbnRlZ3JhdGVkIGJ1dCBvcHRpb25hbCBkaXNjb3ZlcnkgcHJv dG9jb2wuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEdS QVNQIGlzIG5vcm1hbGx5IGV4cGVjdGVkIHRvIHJ1biBpbnNpZGUgdGhlIEF1dG9ub21pYyBD b250cm9sIFBsYW5lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgR1JBU1Ag aXMgbm9ybWFsbHkgZXhwZWN0ZWQgdG8gcnVuIGluc2lkZSB0aGUgQXV0b25vbWljIENvbnRy b2wgUGxhbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMDkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgKEFDUDsgc2VlIFNlY3Rpb24gNC42KSBh bmQgdG8gZGVwZW5kIG9uIHRoZSBBQ1AgZm9yIHNlY3VyaXR5LiAgSXQgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+aXM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IChBQ1A7IHNlZSBTZWN0aW9uIDQuNikgYW5kIHRvIGRlcGVuZCBvbiB0aGUgQUNQIGZvciBz ZWN1cml0eS4gIEl0IG1heTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBhbHNvIGNhcGFibGUgb2YgdXNpbmcgVExTIHNlY3VyaXR5 IGluIHRoZSBhYnNlbmNlIG9mIGFuIEFDUCwgYW5kIGl0PC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBydW4gaW5zZWN1cmVseSBmb3IgYSBzaG9ydCB0aW1l IGR1cmluZyBib290c3RyYXBwaW5nLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBtYXkgcnVuIGluc2VjdXJlbHkgZm9yIGEgc2hvcnQgdGltZSBkdXJpbmcgYm9vdHN0 cmFwcGluZy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFuIGF1dG9ub21pYyBub2RlIHdp bGwgbm9ybWFsbHkgcnVuIGEgc2luZ2xlIGluc3RhbmNlIG9mIEdSQVNQLCB1c2VkPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQW4gYXV0b25vbWljIG5vZGUgd2lsbCBu b3JtYWxseSBydW4gYSBzaW5nbGUgaW5zdGFuY2Ugb2YgR1JBU1AsIHVzZWQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJ5IG11bHRpcGxlIEFTQXMuICBIb3dldmVyLCBz Y2VuYXJpb3Mgd2hlcmUgbXVsdGlwbGUgaW5zdGFuY2VzIG9mPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgYnkgbXVsdGlwbGUgQVNBcy4gIEhvd2V2ZXIsIHNjZW5hcmlv cyB3aGVyZSBtdWx0aXBsZSBpbnN0YW5jZXMgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEdSQVNQIHJ1biBpbiBhIHNpbmdsZSBub2RlLCBwZXJoYXBzIHdpdGggZGlm ZmVyZW50IHNlY3VyaXR5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgR1JB U1AgcnVuIGluIGEgc2luZ2xlIG5vZGUsIHBlcmhhcHMgd2l0aCBkaWZmZXJlbnQgc2VjdXJp dHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3BlcnRpZXMsIGFyZSBu b3QgZXhjbHVkZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvcGVy dGllcywgYXJlIG5vdCBleGNsdWRlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+NC41LiAgUm91dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjQuNS4gIFJvdXRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgQWxsIGF1dG9ub21pYyBub2RlcyBpbiBhIGRvbWFpbiBtdXN0IGJlIGFibGUg dG8gY29tbXVuaWNhdGUgd2l0aCBlYWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgQWxsIGF1dG9ub21pYyBub2RlcyBpbiBhIGRvbWFpbiBtdXN0IGJlIGFibGUgdG8g Y29tbXVuaWNhdGUgd2l0aCBlYWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvdGhlciwgYW5kIHdpdGggYXV0b25vbWljIG5vZGVzIG91dHNpZGUgdGhlaXIgb3duIGRv bWFpbi4gIFRoZXJlZm9yZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBv dGhlciwgYW5kIHdpdGggYXV0b25vbWljIG5vZGVzIG91dHNpZGUgdGhlaXIgb3duIGRvbWFp bi4gIFRoZXJlZm9yZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTgiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48 dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQt OCI+PGVtPiBwYWdlIDEzLCBsaW5lIDE5PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3Nw YW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTgiPjxlbT4gcGFnZSAxMywgbGluZSAxOTxz cGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgYSBmdW5jdGlvbiBvZiB0aGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUuICBPbmUg Zm9ybSBvZiBzdWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYSBmdW5j dGlvbiBvZiB0aGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUuICBPbmUgZm9ybSBvZiBzdWNo PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmZvcm1hdGlvbiBpcyBJbnRl bnQuICBJbnRlbnQgaXMgdGhlIHBvbGljeSBsYW5ndWFnZSBvZiBhbiBBdXRvbm9taWM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmZvcm1hdGlvbiBpcyBJbnRlbnQu ICBJbnRlbnQgaXMgdGhlIHBvbGljeSBsYW5ndWFnZSBvZiBhbiBBdXRvbm9taWM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5ldHdvcms7IHNlZSBTZWN0aW9uIDcuMiBm b3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiBvbiBJbnRlbnQuICBJdCBpcyBhPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTmV0d29yazsgc2VlIFNlY3Rpb24gNy4yIGZvciBn ZW5lcmFsIGluZm9ybWF0aW9uIG9uIEludGVudC4gIEl0IGlzIGE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGhpZ2ggbGV2ZWwgcG9saWN5LCBhbmQgc2hvdWxkIGNoYW5n ZSBvbmx5IGluZnJlcXVlbnRseSAob3JkZXIgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBoaWdoIGxldmVsIHBvbGljeSwgYW5kIHNob3VsZCBjaGFuZ2Ugb25seSBp bmZyZXF1ZW50bHkgKG9yZGVyIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBkYXlzKS4gIFRoZXJlZm9yZSwgaW5mb3JtYXRpb24gc3VjaCBhcyBJbnRlbnQgc2hvdWxk IGJlIHNpbXBseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRheXMpLiAg VGhlcmVmb3JlLCBpbmZvcm1hdGlvbiBzdWNoIGFzIEludGVudCBzaG91bGQgYmUgc2ltcGx5 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmbG9vZGVkIHRvIGFsbCBub2Rl cyBpbiBhbiBhdXRvbm9taWMgZG9tYWluLCBhbmQgdGhlcmUgaXMgY3VycmVudGx5PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmxvb2RlZCB0byBhbGwgbm9kZXMgaW4g YW4gYXV0b25vbWljIGRvbWFpbiwgYW5kIHRoZXJlIGlzIGN1cnJlbnRseTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm8gcGVyY2VpdmVkIG5lZWQgdG8gaGF2ZSBtb3Jl IHRhcmdldGVkIGRpc3RyaWJ1dGlvbiBtZXRob2RzLiAgSW50ZW50PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbm8gcGVyY2VpdmVkIG5lZWQgdG8gaGF2ZSBtb3JlIHRh cmdldGVkIGRpc3RyaWJ1dGlvbiBtZXRob2RzLiAgSW50ZW50PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBpcyBhbHNvIGV4cGVjdGVkIHRvIGJlIG1vbm9saXRoaWMsIGFu ZCBmbG9vZGVkIGFzIGEgd2hvbGUuICBPbmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBpcyBhbHNvIGV4cGVjdGVkIHRvIGJlIG1vbm9saXRoaWMsIGFuZCBmbG9vZGVk IGFzIGEgd2hvbGUuICBPbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBv c3NpYmxlIG1ldGhvZCBmb3IgZGlzdHJpYnV0aW5nIEludGVudCwgYXMgd2VsbCBhcyBvdGhl ciBmb3JtcyBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBvc3NpYmxl IG1ldGhvZCBmb3IgZGlzdHJpYnV0aW5nIEludGVudCwgYXMgd2VsbCBhcyBvdGhlciBmb3Jt cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGF0YSwgaXMgZGlzY3Vz c2VkIGluIFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl0uICBJbnRlbnQgYW5k PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGF0YSwgaXMgZGlzY3Vzc2Vk IGluIFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl0uICBJbnRlbnQgYW5kPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEw Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbiBhcmUgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+Y3VycmVudGx5IG91dCBvZiBzY29wZSBmb3I8L3NwYW4+IEFOSU1B LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbmZvcm1hdGlvbiBkaXN0 cmlidXRpb24gYXJlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm5vdCBwYXJ0IG9mIHBoYXNlIDEg b2Y8L3NwYW4+IEFOSU1BLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij41LiAgU2VjdXJpdHkgYW5kIFRydXN0IEluZnJhc3RydWN0dXJlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+NS4gIFNlY3VyaXR5IGFuZCBUcnVzdCBJbmZyYXN0cnVj dHVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBbiBB dXRvbm9taWMgTmV0d29yayBpcyBzZWxmLXByb3RlY3RpbmcuICBBbGwgcHJvdG9jb2xzIGFy ZSBzZWN1cmUgYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBbiBBdXRv bm9taWMgTmV0d29yayBpcyBzZWxmLXByb3RlY3RpbmcuICBBbGwgcHJvdG9jb2xzIGFyZSBz ZWN1cmUgYnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlZmF1bHQsIHdp dGhvdXQgdGhlIHJlcXVpcmVtZW50IGZvciB0aGUgYWRtaW5pc3RyYXRvciB0byBleHBsaWNp dGx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVmYXVsdCwgd2l0aG91 dCB0aGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGV4cGxpY2l0bHk8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbmZpZ3VyZSBzZWN1cml0eS48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb25maWd1cmUgc2VjdXJpdHku PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1dG9ub21p YyBub2RlcyBoYXZlIGRpcmVjdCBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVtc2VsdmVzLCB3 aGljaDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dG9ub21pYyBub2Rl cyBoYXZlIGRpcmVjdCBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVtc2VsdmVzLCB3aGljaDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbXVzdCBiZSBzZWN1cmVkLiAgU2lu Y2UgYW4gYXV0b25vbWljIG5ldHdvcmsgZG9lcyBub3QgcmVseSBvbjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG11c3QgYmUgc2VjdXJlZC4gIFNpbmNlIGFuIGF1dG9u b21pYyBuZXR3b3JrIGRvZXMgbm90IHJlbHkgb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGNvbmZpZ3VyYXRpb24sIGl0IGlzIG5vdCBhbiBvcHRpb24gdG8gY29uZmln dXJlIGZvciBleGFtcGxlIHByZS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBjb25maWd1cmF0aW9uLCBpdCBpcyBub3QgYW4gb3B0aW9uIHRvIGNvbmZpZ3VyZSBmb3Ig ZXhhbXBsZSBwcmUtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC05IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRo PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTki PjxlbT4gcGFnZSAxNCwgbGluZSAzMjxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFu PjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC05Ij48ZW0+IHBhZ2UgMTQsIGxpbmUgMzI8c3Bh biBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtJLUQuaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhXS48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGlu Zy1rZXlpbmZyYV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjUuNC4gIFN1Yi1Eb21haW5zICgqKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjUuNC4gIFN1Yi1Eb21haW5zICgqKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBCeSBkZWZhdWx0LCBzdWItZG9tYWlucyBhcmUgdHJlYXRlZCBhcyBk aWZmZXJlbnQgZG9tYWlucy4gIFRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBCeSBkZWZhdWx0LCBzdWItZG9tYWlucyBhcmUgdHJlYXRlZCBhcyBkaWZmZXJlbnQg ZG9tYWlucy4gIFRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGltcGxp ZXMgbm8gdHJ1c3QgYmV0d2VlbiBhIGRvbWFpbiBhbmQgaXRzIHN1Yi1kb21haW5zLCBhbmQg bm8gdHJ1c3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbXBsaWVzIG5v IHRydXN0IGJldHdlZW4gYSBkb21haW4gYW5kIGl0cyBzdWItZG9tYWlucywgYW5kIG5vIHRy dXN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZXR3ZWVuIHN1Yi1kb21h aW5zIG9mIHRoZSBzYW1lIGRvbWFpbi4gIFNwZWNpZmljYWxseSwgbm8gQUNQIGlzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmV0d2VlbiBzdWItZG9tYWlucyBvZiB0 aGUgc2FtZSBkb21haW4uICBTcGVjaWZpY2FsbHksIG5vIEFDUCBpczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgYnVpbHQsIGFuZCBJbnRlbnQgaXMgdmFsaWQgb25seSBm b3IgdGhlIGRvbWFpbiBpdCBpcyBkZWZpbmVkIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGJ1aWx0LCBhbmQgSW50ZW50IGlzIHZhbGlkIG9ubHkgZm9yIHRoZSBk b21haW4gaXQgaXMgZGVmaW5lZCBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGV4cGxpY2l0bHkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhw bGljaXRseS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAxMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJbiA8c3BhbiBjbGFz cz0iZGVsZXRlIj50aGUgZnV0dXJlLDwvc3Bhbj4gYWx0ZXJuYXRpdmUgdHJ1c3QgbW9kZWxz IDxzcGFuIGNsYXNzPSJkZWxldGUiPmNhbjwvc3Bhbj4gYmUgZGVmaW5lZCwgZm9yIGV4YW1w bGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgSW4gPHNwYW4gY2xhc3M9 Imluc2VydCI+cGhhc2UgMiBvZiBBTklNQSw8L3NwYW4+IGFsdGVybmF0aXZlIHRydXN0IG1v ZGVscyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zaG91bGQ8L3NwYW4+IGJlIGRlZmluZWQsIGZv cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0byBhbGxvdyBmdWxsIG9y IGxpbWl0ZWQgdHJ1c3QgYmV0d2VlbiBkb21haW4gYW5kIHN1Yi1kb21haW4uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGV4YW1wbGUgdG8gYWxsb3cgZnVsbCBvciBs aW1pdGVkIHRydXN0IGJldHdlZW4gZG9tYWluIGFuZCBzdWItZG9tYWluLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LjUuICBDcm9zcy1Eb21haW4gRnVu Y3Rpb25hbGl0eSAoKik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij41LjUuICBD cm9zcy1Eb21haW4gRnVuY3Rpb25hbGl0eSAoKik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgQnkgZGVmYXVsdCwgZGlmZmVyZW50IGRvbWFpbnMgZG8g bm90IGludGVyb3BlcmF0ZSwgbm8gQUNQIGlzIGJ1aWx0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgQnkgZGVmYXVsdCwgZGlmZmVyZW50IGRvbWFpbnMgZG8gbm90IGlu dGVyb3BlcmF0ZSwgbm8gQUNQIGlzIGJ1aWx0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbmQgbm8gdHJ1c3QgaXMgaW1wbGllZCBiZXR3ZWVuIHRoZW0uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5kIG5vIHRydXN0IGlzIGltcGxpZWQgYmV0 d2VlbiB0aGVtLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBJbiB0aGUgZnV0dXJlLCBtb2RlbHMgY2FuIGJlIGVzdGFibGlzaGVkIHdoZXJlIG90aGVy IGRvbWFpbnMgY2FuIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4g dGhlIGZ1dHVyZSwgbW9kZWxzIGNhbiBiZSBlc3RhYmxpc2hlZCB3aGVyZSBvdGhlciBkb21h aW5zIGNhbiBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJ1c3RlZCBp biBmdWxsIG9yIGZvciBsaW1pdGVkIG9wZXJhdGlvbnMgYmV0d2VlbiB0aGUgZG9tYWlucy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0cnVzdGVkIGluIGZ1bGwgb3Ig Zm9yIGxpbWl0ZWQgb3BlcmF0aW9ucyBiZXR3ZWVuIHRoZSBkb21haW5zLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAgQXV0b25vbWljIFNlcnZpY2Ug QWdlbnRzIChBU0EpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4gIEF1dG9u b21pYyBTZXJ2aWNlIEFnZW50cyAoQVNBKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMTAiIGNsYXNzPSJjaGFuZ2Ui ID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEg aHJlZj0iI3BhcnQtMTAiPjxlbT4gcGFnZSAxOSwgbGluZSA3PHNwYW4gY2xhc3M9ImhpZGUi PiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTEwIj48ZW0+IHBhZ2Ug MTksIGxpbmUgNzxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwv dGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgYWNoaWV2ZWQgaW4gYXV0b25vbWljIG1hbmFnZW1lbnQgdGhy b3VnaCBwcmlvcml0aXphdGlvbiBbUkZDNzU3NV0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYWNoaWV2ZWQgaW4gYXV0b25vbWljIG1hbmFnZW1lbnQgdGhyb3VnaCBw cmlvcml0aXphdGlvbiBbUkZDNzU3NV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGUgcmF0aW9uYWxlIGlzIHRoYXQgbWFudWFsIGFuZCBub2RlLWJhc2VkIG1hbmFn ZW1lbnQgaGF2ZSBhIGhpZ2hlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoZSByYXRpb25hbGUgaXMgdGhhdCBtYW51YWwgYW5kIG5vZGUtYmFzZWQgbWFuYWdlbWVu dCBoYXZlIGEgaGlnaGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcmlv cml0eSBvdmVyIGF1dG9ub21pYyBtYW5hZ2VtZW50LiAgVGh1cywgdGhlIGF1dG9ub21pYyBk ZWZhdWx0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJpb3JpdHkgb3Zl ciBhdXRvbm9taWMgbWFuYWdlbWVudC4gIFRodXMsIHRoZSBhdXRvbm9taWMgZGVmYXVsdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmVoYXZpb3IgaGFzIHRoZSBsb3dl c3QgcHJpb3JpdHksIHRoZW4gY29tZXMgdGhlIGF1dG9ub21pYyBJbnRlbnQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBiZWhhdmlvciBoYXMgdGhlIGxvd2VzdCBwcmlv cml0eSwgdGhlbiBjb21lcyB0aGUgYXV0b25vbWljIEludGVudDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgKG1lZGl1bSBwcmlvcml0eSksIGFuZCwgZmluYWxseSwgdGhl IGhpZ2hlc3QgcHJpb3JpdHkgaXMgdGFrZW4gYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAobWVkaXVtIHByaW9yaXR5KSwgYW5kLCBmaW5hbGx5LCB0aGUgaGlnaGVz dCBwcmlvcml0eSBpcyB0YWtlbiBieTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgbm9kZS1zcGVjaWZpYyBuZXR3b3JrIG1hbmFnZW1lbnQgbWV0aG9kcywgc3VjaCBhcyB0 aGUgdXNlIG9mIGNvbW1hbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBu b2RlLXNwZWNpZmljIG5ldHdvcmsgbWFuYWdlbWVudCBtZXRob2RzLCBzdWNoIGFzIHRoZSB1 c2Ugb2YgY29tbWFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbGluZSBp bnRlcmZhY2VzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxpbmUgaW50 ZXJmYWNlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ny4y LiAgSW50ZW50ICgqKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjcuMi4gIElu dGVudCAoKik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAxMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJbnRlbnQgaXMgbm90 IGNvdmVyZWQgYnkgdGhlIEFOSU1BIGNoYXJ0ZXIgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YXM8 L3NwYW4+IG9mIDxzcGFuIGNsYXNzPSJkZWxldGUiPk1hcmNoIDIwMTcuPC9zcGFuPiAgVGhp czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJbnRlbnQgaXMgbm90IGNv dmVyZWQgYnkgdGhlIEFOSU1BIGNoYXJ0ZXIgPHNwYW4gY2xhc3M9Imluc2VydCI+YXQgdGhl IHRpbWU8L3NwYW4+IG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoaXM8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHNlY3Rpb24gaXMgZm9yIGluZm9ybWF0 aW9uYWwgcHVycG9zZXMgb25seS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgd3JpdGluZy48L3NwYW4+ICBUaGlzIHNlY3Rpb24g aXMgZm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMgb25seS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGdpdmVzIGFuIG92ZXJ2 aWV3IG9mIEludGVudCwgYW5kIGhvdyBpdCBpcyBtYW5hZ2VkLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgc2VjdGlvbiBnaXZlcyBhbiBvdmVydmlldyBvZiBJ bnRlbnQsIGFuZCBob3cgaXQgaXMgbWFuYWdlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEludGVudCBhbmQgUG9saWN5LUJhc2VkIE5ldHdvcmsgTWFuYWdlbWVudCAo UEJOTSkgaXMgYWxyZWFkeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElu dGVudCBhbmQgUG9saWN5LUJhc2VkIE5ldHdvcmsgTWFuYWdlbWVudCAoUEJOTSkgaXMgYWxy ZWFkeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVzY3JpYmVkIGluc2lk ZSB0aGUgSUVURiAoZS5nLiwgUENJTSBhbmQgU1VQQSkgYW5kIGluIG90aGVyIFNET3M8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQgaW5zaWRlIHRoZSBJ RVRGIChlLmcuLCBQQ0lNIGFuZCBTVVBBKSBhbmQgaW4gb3RoZXIgU0RPczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGUuZy4sIERNVEYgYW5kIFRNRiBaT09NKS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoZS5nLiwgRE1URiBhbmQgVE1GIFpP T00pLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRl bnQgY2FuIGJlIGRlc2NyaWJlZCBhcyBhbiBhYnN0cmFjdCwgZGVjbGFyYXRpdmUsIGhpZ2gt bGV2ZWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlbnQgY2FuIGJl IGRlc2NyaWJlZCBhcyBhbiBhYnN0cmFjdCwgZGVjbGFyYXRpdmUsIGhpZ2gtbGV2ZWw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBvbGljeSB1c2VkIHRvIG9wZXJhdGUg YW4gYXV0b25vbWljIGRvbWFpbiwgc3VjaCBhcyBhbiBlbnRlcnByaXNlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcG9saWN5IHVzZWQgdG8gb3BlcmF0ZSBhbiBhdXRv bm9taWMgZG9tYWluLCBzdWNoIGFzIGFuIGVudGVycHJpc2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG5ldHdvcmsgW1JGQzc1NzVdLiAgSW50ZW50IHNob3VsZCBiZSBs aW1pdGVkIHRvIGhpZ2ggbGV2ZWwgZ3VpZGFuY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBuZXR3b3JrIFtSRkM3NTc1XS4gIEludGVudCBzaG91bGQgYmUgbGltaXRl ZCB0byBoaWdoIGxldmVsIGd1aWRhbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBvbmx5LCB0aHVzIGl0IGRvZXMgbm90IGRpcmVjdGx5IGRlZmluZSBhIHBvbGljeSBm b3IgZXZlcnkgbmV0d29yazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9u bHksIHRodXMgaXQgZG9lcyBub3QgZGlyZWN0bHkgZGVmaW5lIGEgcG9saWN5IGZvciBldmVy eSBuZXR3b3JrPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0icGFydC0xMSIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0xMSI+ PGVtPiBwYWdlIDE5LCBsaW5lIDQwPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+ PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTExIj48ZW0+IHBhZ2UgMTksIGxpbmUgNDA8c3Bh biBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGFyZSB1c3VhbGx5IHByb3ZpZGVkIGJ5IHRoZSBodW1hbiBvcGVyYXRvci4gIFNvbWUg b2YgdGhlc2UgcGFyYW1ldGVyczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGFyZSB1c3VhbGx5IHByb3ZpZGVkIGJ5IHRoZSBodW1hbiBvcGVyYXRvci4gIFNvbWUgb2Yg dGhlc2UgcGFyYW1ldGVyczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2Fu IGluZmx1ZW5jZSB0aGUgYmVoYXZpb3Igb2Ygc3BlY2lmaWMgYXV0b25vbWljIGZ1bmN0aW9u cyBhcyB3ZWxsIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FuIGlu Zmx1ZW5jZSB0aGUgYmVoYXZpb3Igb2Ygc3BlY2lmaWMgYXV0b25vbWljIGZ1bmN0aW9ucyBh cyB3ZWxsIGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgd2F5IHRo ZSBJbnRlbnQgaXMgdXNlZCB0byBtYW5hZ2UgdGhlIGF1dG9ub21pYyBkb21haW4uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHdheSB0aGUgSW50ZW50IGlzIHVz ZWQgdG8gbWFuYWdlIHRoZSBhdXRvbm9taWMgZG9tYWluLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlbnQgaXMgZGlzY3Vzc2VkIGluIG1vcmUg ZGV0YWlsIGluIFtJLUQuZHUtYW5pbWEtYW4taW50ZW50XS48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBJbnRlbnQgaXMgZGlzY3Vzc2VkIGluIG1vcmUgZGV0YWlsIGlu IFtJLUQuZHUtYW5pbWEtYW4taW50ZW50XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEludGVudCBhcyB3ZWxsIGFzIG90aGVyIHR5cGVzIG9mIGluZm9ybWF0aW9uIGFy ZSBkaXN0cmlidXRlZCB2aWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJ bnRlbnQgYXMgd2VsbCBhcyBvdGhlciB0eXBlcyBvZiBpbmZvcm1hdGlvbiBhcmUgZGlzdHJp YnV0ZWQgdmlhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBHUkFTUCwgc2Vl IFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl0uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgR1JBU1AsIHNlZSBbSS1ELmxpdS1hbmltYS1ncmFzcC1kaXN0 cmlidXRpb25dLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij43 LjMuICBBZ2dyZWdhdGVkIFJlcG9ydGluZyAoKik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij43LjMuICBBZ2dyZWdhdGVkIFJlcG9ydGluZyAoKik8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMyI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Bczwvc3Bhbj4gb2YgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+TWFyY2ggMjAxNyw8L3NwYW4+IGFnZ3JlZ2F0ZWQgcmVwb3J0 aW5nIGlzIG5vdCBpbiB0aGUgQU5JTUEgY2hhcnRlci48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+QXQgdGhlIHRpbWU8L3NwYW4+ IG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoaXMgd3JpdGluZyw8L3NwYW4+IGFnZ3JlZ2F0 ZWQgcmVwb3J0aW5nIGlzIG5vdCBpbiB0aGUgQU5JTUE8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgVGhpcyBzZWN0aW9uIGlzIHByb3ZpZGVkIGZvciBpbmZvcm1hdGlv biBvbmx5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBjaGFydGVyLiAg VGhpcyBzZWN0aW9uIGlzIHByb3ZpZGVkIGZvciBpbmZvcm1hdGlvbiBvbmx5LjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRvbm9taWMgTmV0d29y ayBzaG91bGQgbWluaW1pemUgdGhlIG5lZWQgZm9yIGh1bWFuIGludGVydmVudGlvbi48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRvbm9taWMgTmV0d29yayBzaG91 bGQgbWluaW1pemUgdGhlIG5lZWQgZm9yIGh1bWFuIGludGVydmVudGlvbi48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluIHRlcm1zIG9mIGhvdyB0aGUgbmV0d29yayBz aG91bGQgYmVoYXZlLCB0aGlzIGlzIGRvbmUgdGhyb3VnaCBhbjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIEluIHRlcm1zIG9mIGhvdyB0aGUgbmV0d29yayBzaG91bGQg YmVoYXZlLCB0aGlzIGlzIGRvbmUgdGhyb3VnaCBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYXV0b25vbWljIEludGVudCBwcm92aWRlZCBieSB0aGUgaHVtYW4gYWRt aW5pc3RyYXRvci4gIEluIGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg YXV0b25vbWljIEludGVudCBwcm92aWRlZCBieSB0aGUgaHVtYW4gYWRtaW5pc3RyYXRvci4g IEluIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmFsb2dvdXMgbWFu bmVyLCB0aGUgcmVwb3J0cyB3aGljaCBkZXNjcmliZSB0aGUgb3BlcmF0aW9uYWwgc3RhdHVz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5hbG9nb3VzIG1hbm5lciwg dGhlIHJlcG9ydHMgd2hpY2ggZGVzY3JpYmUgdGhlIG9wZXJhdGlvbmFsIHN0YXR1czwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIG5ldHdvcmsgc2hvdWxkIGFn Z3JlZ2F0ZSB0aGUgaW5mb3JtYXRpb24gcHJvZHVjZWQgaW4gZGlmZmVyZW50PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgdGhlIG5ldHdvcmsgc2hvdWxkIGFnZ3Jl Z2F0ZSB0aGUgaW5mb3JtYXRpb24gcHJvZHVjZWQgaW4gZGlmZmVyZW50PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBuZXR3b3JrIGVsZW1lbnRzIGluIG9yZGVyIHRvIHBy ZXNlbnQgdGhlIGVmZmVjdGl2ZW5lc3Mgb2YgYXV0b25vbWljPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgbmV0d29yayBlbGVtZW50cyBpbiBvcmRlciB0byBwcmVzZW50 IHRoZSBlZmZlY3RpdmVuZXNzIG9mIGF1dG9ub21pYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgSW50ZW50IGVuZm9yY2VtZW50LiAgVGhlcmVmb3JlLCByZXBvcnRpbmcg aW4gYW4gYXV0b25vbWljIG5ldHdvcms8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJbnRlbnQgZW5mb3JjZW1lbnQuICBUaGVyZWZvcmUsIHJlcG9ydGluZyBpbiBhbiBh dXRvbm9taWMgbmV0d29yazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2hv dWxkIGhhcHBlbiBvbiBhIG5ldHdvcmstd2lkZSBiYXNpcyBbUkZDNzU3NV0uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2hvdWxkIGhhcHBlbiBvbiBhIG5ldHdvcmst d2lkZSBiYXNpcyBbUkZDNzU3NV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTEyIiBjbGFzcz0i Y2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxhIGhyZWY9IiNwYXJ0LTEyIj48ZW0+IHBhZ2UgMjQsIGxpbmUgMTA8c3BhbiBjbGFz cz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMTIiPjxl bT4gcGFnZSAyNCwgbGluZSAxMDxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwv ZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgaW50ZXJhY3Rpb24gbWFwcykuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgaW50ZXJhY3Rpb24gbWFwcykuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEEgY29tbW9u ICJjb250cm9sL2NvbW1hbmQiIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBjb29yZGluYXRpb248 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBBIGNvbW1vbiAiY29udHJv bC9jb21tYW5kIiBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgY29vcmRpbmF0aW9uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAiYWdlbnQiIGFuZCB0aGUgYXV0b25vbWlj IGZ1bmN0aW9ucy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAiYWdl bnQiIGFuZCB0aGUgYXV0b25vbWljIGZ1bmN0aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgR3VpZGVsaW5lcywgcmVjb21tZW5kYXRpb25zIG9y IEJDUHMgY2FuIGFsc28gYmUgcHJvdmlkZWQgZm9yIGFzcGVjdHM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBHdWlkZWxpbmVzLCByZWNvbW1lbmRhdGlvbnMgb3IgQkNQ cyBjYW4gYWxzbyBiZSBwcm92aWRlZCBmb3IgYXNwZWN0czwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgcGVydGFpbmluZyB0byB0aGUgY29vcmRpbmF0aW9uIHN0cmF0ZWdp ZXMgYW5kIG1lY2hhbmlzbXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg cGVydGFpbmluZyB0byB0aGUgY29vcmRpbmF0aW9uIHN0cmF0ZWdpZXMgYW5kIG1lY2hhbmlz bXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjkuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjku ICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE0Ij48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjkuMS4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRocmVhdCBBbmFseXNpczwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+OS4xLiAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+Q29uc2VxdWVuY2VzIG9mIGEgRGlzdHJpYnV0ZWQgU3lzdGVtPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDE1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRoaXMgaXMg YSBwcmVsaW1pbmFyeSBvdXRsaW5lPC9zcGFuPiBvZiBhIDxzcGFuIGNsYXNzPSJkZWxldGUi PnRocmVhdCBhbmFseXNpcywgdG8gYmUgZXhwYW5kZWQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkFuIGF1dG9ub21p YyBuZXR3b3JrIGNvbnNpc3RzPC9zcGFuPiBvZiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hdXRv bm9taWMgZGV2aWNlcyB0aGF0IGZvcm0gYTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPm1hZGUgbW9yZSBzcGVj aWZpYyBhczwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPnZhcmlvdXMgQXV0b25v bWljIE5ldHdvcmtpbmc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGRpc3RyaWJ1dGVkIHNlbGYtbWFuYWdpbmcgc3lz dGVtLiAgRGV2aWNlcyB3aXRoaW4gYSBkb21haW4gc2hhcmU8L3NwYW4+IGE8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgc3BlY2lm aWNhdGlvbnMgZXZvbHZlLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Y29tbW9uIHRydXN0IGFuY2hvcjwvc3Bhbj4g YW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRodXMgaW1wbGljaXRseSB0cnVzdCBlYWNoIG90 aGVyLiAgVGhpcyBtZWFuczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIHRoYXQgYW55IGRldmljZSBpbnNpZGUgYSB0cnVzdCBkb21haW4gY2FuIGJ5IGRl ZmF1bHQgdXNlIGFsbDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIGRpc3RyaWJ1dGVkIGZ1bmN0aW9ucyBpbjwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJp bnNlcnQiPmVudGlyZSBhdXRvbm9taWMgZG9tYWluIGluIGEgbWFsaWNpb3VzPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgd2F5Ljwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAxNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5TaW5jZSBB TiB3aWxsIGhhbmQgb3ZlciByZXNwb25zaWJpbGl0eSBmb3IgbmV0d29yayBjb25maWd1cmF0 aW9uIGZyb208L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxz cGFuIGNsYXNzPSJpbnNlcnQiPkFuIG91dHNpZGUgYXR0YWNrZXIgaGFzPC9zcGFuPiB0aGUg PHNwYW4gY2xhc3M9Imluc2VydCI+Zm9sbG93aW5nIGdlbmVyaWMgd2F5czwvc3Bhbj4gdG8g PHNwYW4gY2xhc3M9Imluc2VydCI+dGFrZSBjb250cm9sPC9zcGFuPiBvZjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBodW1hbnMg b3IgY2VudHJhbGx5IGVzdGFibGlzaGVkIG1hbmFnZW1lbnQgc3lzdGVtcyB0byBmdWxseTwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9 Imluc2VydCI+YW48L3NwYW4+IGF1dG9ub21pYyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5uZXR3 b3JrOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+ICAgZGlzdHJpYnV0ZWQgZGV2aWNlcywgdGhlIHRocmVhdCBlbnZpcm9u bWVudCBpcyBhbHNvIGZ1bGx5PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgZGlzdHJpYnV0ZWQuICBPbjwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJkZWxl dGUiPm9uZSBoYW5kLCB0aGF0IG1lYW5zIHRoZXJlIGlzIG5vIHNpbmdsZSBwb2ludCBvZjwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGZhaWx1cmU8L3Nw YW4+IHRvIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFjdCBhcyBhbiBhdHRyYWN0aXZlIHRhcmdl dCBmb3IgYmFkIGFjdG9ycy4gIE9uIHRoZSBvdGhlcjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxz cGFuIGNsYXNzPSJkZWxldGUiPiAgIGhhbmQsIGl0IG1lYW5zIHRoYXQgcG90ZW50aWFsbHkg YSBzaW5nbGUgbWlzYmVoYXZpbmcgYXV0b25vbWljIGRldmljZTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGNvdWxkIGxhdW5jaCBhIHdpZGVzcHJlYWQg YXR0YWNrLCBieSBtaXN1c2luZyB0aGUgZGlzdHJpYnV0ZWQgQU48L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBtZWNoYW5pc21zLiAgRm9yIGV4YW1wbGUs IGEgcmVzb3VyY2UgZXhoYXVzdGlvbiBhdHRhY2sgY291bGQgYmU8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBsYXVuY2hlZCBieSBhIHNpbmdsZSBkZXZp Y2UgcmVxdWVzdGluZyBsYXJnZSBhbW91bnRzPC9zcGFuPiBvZiA8c3BhbiBjbGFzcz0iZGVs ZXRlIj50aGF0IHJlc291cmNlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgZnJvbSBhbGwgaXRzIHBlZXJzLCBvbiBiZWhhbGYgb2YgYSBub24tZXhpc3Rl bnQgdHJhZmZpYyBsb2FkLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIEFsdGVybmF0aXZlbHkgaXQgY291bGQgc2ltcGx5IHNlbmQgZmFsc2UgaW5mb3Jt YXRpb24gdG8gaXRzIHBlZXJzLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgIGZvciBleGFtcGxlIGJ5IGFubm91bmNpbmcgcmVzb3VyY2UgZXhoYXVzdGlv biB3aGVuIHRoaXMgd2FzIG5vdCB0aGU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj4gICBjYXNlLiAgSWYgc2VjdXJpdHkgcHJvcGVydGllcyBhcmUgbWFuYWdl ZCBhdXRvbm9taWNhbGx5LCBhPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgbWlzYmVoYXZpbmcgZGV2aWNlIGNvdWxkIGF0dGVtcHQgYSBkaXN0cmlidXRl ZCBhdHRhY2sgYnkgcmVxdWVzdGluZzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgIGFsbCBpdHMgcGVlcnMgdG8gcmVkdWNlIHNlY3VyaXR5IHByb3RlY3Rp b25zIGluIHNvbWUgd2F5LiAgSW48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICBnZW5lcmFsLCBzaW5jZTwvc3Bhbj4gYXV0b25vbWljIDxzcGFuIGNsYXNz PSJkZWxldGUiPmRldmljZXMgcnVuIHdpdGhvdXQgc3VwZXJ2aXNpb24sIGFsbW9zdCBhbnk8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBraW5kIG9mIHVu ZGVzaXJhYmxlIG1hbmFnZW1lbnQgYWN0aW9uIGNvdWxkIGluIHRoZW9yeSBiZSBhdHRlbXB0 ZWQgYnk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBhIG1p c2JlaGF2aW5nIGRldmljZS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDE3Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxl dGUiPklmIGl0IGlzIHBvc3NpYmxlIGZvciBhbiB1bmF1dGhvcmlzZWQgZGV2aWNlIHRvIGFj dCBhcyBhbiBhdXRvbm9taWM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm8gIEludHJvZHVjaW5nPC9zcGFuPiBhIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmZha2UgZGV2aWNlIGludG8gdGhlIHRydXN0IGRvbWFpbiwg Ynkgc3VidmVydGluZyB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGRldmljZSwgb3IgZm9yPC9zcGFuPiBhIDxz cGFuIGNsYXNzPSJkZWxldGUiPm1hbGljaW91cyB0aGlyZCBwYXJ0eSB0byBpbmplY3QgbWVz c2FnZXMgYXBwZWFyaW5nPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiAg VGhpcyBpcyBjb3ZlcmVkIGluIGRldGFpbCBpbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgdG8gY29tZSBmcm9tIGFu IGF1dG9ub21pYyBkZXZpY2UsIGFsbCB0aGVzZSBzYW1lIHJpc2tzIHdvdWxkIGFwcGx5Ljwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmFdLjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAxOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJZiBBTiBtZXNzYWdlcyBj YW4gYmUgb2JzZXJ2ZWQgYnkgYSB0aGlyZCBwYXJ0eSwgdGhleSBtaWdodCByZXZlYWw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ byAgU3VidmVydGluZyBhIGRldmljZSB3aGljaCBpcyBhbHJlYWR5IHBhcnQgb2YgYSB0cnVz dCBkb21haW4sIGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgdmFsdWFibGUgaW5mb3JtYXRpb24gYWJvdXQgbmV0d29yayBjb25maWd1cmF0aW9uLCBz ZWN1cml0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgICBtb2RpZnlpbmcgaXRzIGJlaGF2aW9yLiAgVGhpcyB0aHJlYXQgaXMg bm90IHNwZWNpZmljIHRvIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgcHJlY2F1dGlvbnMgaW4gdXNlLCBpbmRpdmlkdWFsIHVzZXJzLCBhbmQgdGhl aXIgdHJhZmZpYyBwYXR0ZXJucy4gIElmPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIHNvbHV0aW9uIGRpc2N1c3NlZCBpbiB0 aGlzIGRvY3VtZW50LCBhbmQgYXBwbGllcyB0byBhbGwgbmV0d29yazwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZW5jcnlwdGVkLCBBTiBtZXNzYWdlcyBt aWdodCBzdGlsbCByZXZlYWwgc29tZSBpbmZvcm1hdGlvbiB2aWE8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgc29sdXRpb25z Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdHJhZmZpYyBh bmFseXNpcywgYnV0IHRoaXMgd291bGQgYmUgcXVpdGUgbGltaXRlZCAoZm9yIGV4YW1wbGUs IHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB3b3Vs ZCBiZSBoaWdobHkgdW5saWtlbHkgdG8gcmV2ZWFsIGFueSBzcGVjaWZpYyBpbmZvcm1hdGlv biBhYm91dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBvICBFeHBsb2l0aW5nIHBvdGVudGlhbGx5IHlldCB1bmtub3duIHByb3Rv Y29sIHZ1bG5lcmFiaWxpdGllcyBpbiB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIHVzZXIgdHJhZmZpYykuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5B TiBtZXNzYWdlcyBhcmUgbGlhYmxlIHRvIGJlIGV4cG9zZWQgdG8gdGhpcmQgcGFydGllczwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgICAgQU4gb3Igb3RoZXIgcHJvdG9jb2xzLiAgQWxzbyB0aGlzIGlzIGEgZ2Vu ZXJpYyB0aHJlYXQgdGhhdCBhcHBsaWVzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBvbiBhbnkgdW5wcm90ZWN0ZWQg TGF5ZXIgMiBsaW5rLCBhbmQgdG8gaW5zaWRlciBhdHRhY2tzIGV2ZW4gb248L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg ICAgIHRvIGFsbCBuZXR3b3JrIHNvbHV0aW9ucy48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHByb3RlY3RlZCBMYXll ciAyIGxpbmtzLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgVGhlIGFib3ZlIHRocmVhdHMgYXJlIGluIHByaW5jaXBsZSBjb21wYXJhYmxl IHRvIG90aGVyIHNvbHV0aW9ucy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBIb3dldmVyLCB0aGUgZGlzdHJpYnV0ZWQgbmF0dXJlIG9mIEFOLCBzcGVj aWZpY2FsbHkgdGhlIEF1dG9ub21pYzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIENvbnRyb2wgUGxhbmUsIGluY3JlYXNlcyB0aGUgdGhyZWF0IHN1cmZh Y2UuICBGb3IgZXhhbXBsZSwgYTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIGNvbXByb21pc2VkIGRldmljZSBtYXkgaGF2ZSBmdWxsIElQIHJlYWNoYWJp bGl0eSB0byBhbGwgb3RoZXIgZGV2aWNlczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIGluc2lkZSB0aGUgQUNQLCBhbmQgY2FuIHVzZSBhbGwgQU4gbWV0 aG9kcyBhbmQgcHJvdG9jb2xzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEZv ciB0aGUgbmV4dCBwaGFzZSBvZiB0aGUgQU5JTUEgd29yayBpdCBpcyB0aGVyZWZvcmUgcmVj b21tZW5kZWQgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBpbnRyb2R1Y2UgYSBzdWItZG9tYWluIHNlY3VyaXR5IG1vZGVsLCB0byByZWR1Y2UgdGhl IGF0dGFjayBzdXJmYWNlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgYW5kIG5vdCBleHBvc2UgYSBmdWxsIGRvbWFpbiB0byBhIHBvdGVudGlhbCBpbnRy dWRlci4gIEZ1cnRoZXJtb3JlLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIGFkZGl0aW9uYWwgc2VjdXJpdHkgbWVjaGFuaXNtcyBvbiB0aGUgQVNBIGxl dmVsIHNob3VsZCBiZSBjb25zaWRlcmVkPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgZm9yIGhpZ2gtcmlzayBhdXRvbm9taWMgZnVuY3Rpb25zLjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIE1vc3QgQU4gbWVzc2FnZXMgcnVuIGluc2lk ZSB0aGUgZW5jcnlwdGVkIEFDUC4gIFRoZSBub3QgcHJvdGVjdGVkIEFOPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbWVzc2FnZXMgb3V0c2lkZSB0aGUg QUNQIGFyZSBsaW1pdGVkIHRvIHNpbXBsZSBkaXNjb3ZlcnkgbWV0aG9kcy48L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBTZWUgU2VjdGlvbiAyLjUuMiBv ZiBbSS1ELmlldGYtYW5pbWEtZ3Jhc3BdIGZvciBhIGxpc3Qgb2Ygc3VjaDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG1lc3NhZ2VzLjwvc3Bhbj4gIElm IEFOIG1lc3NhZ2VzIGNhbiBiZSBvYnNlcnZlZCBieSBhIHRoaXJkIHBhcnR5LCB0aGV5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBtaWdodCByZXZlYWwgdmFsdWFibGUgaW5mb3JtYXRpb24gYWJvdXQg bmV0d29yayBjb25maWd1cmF0aW9uLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgc2VjdXJpdHkgcHJlY2F1 dGlvbnMgaW4gdXNlLCBpbmRpdmlkdWFsIHVzZXJzLCBhbmQgdGhlaXIgdHJhZmZpYzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgcGF0dGVybnMuICBJZiBlbmNyeXB0ZWQsIEFOIG1lc3NhZ2VzIG1pZ2h0 IHN0aWxsIHJldmVhbCBzb21lPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbmZvcm1hdGlvbiB2aWEgdHJh ZmZpYyBhbmFseXNpcywgYnV0IHRoaXMgd291bGQgYmUgcXVpdGUgbGltaXRlZDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgKGZvciBleGFtcGxlLCB0aGlzIHdvdWxkIGJlIGhpZ2hseSB1bmxpa2VseSB0 byByZXZlYWwgYW55IHNwZWNpZmljPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbmZvcm1hdGlvbiBhYm91 dCB1c2VyIHRyYWZmaWMpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij45LjIuICBTZWN1cml0eSBNZWNoYW5pc21zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+OS4yLiAgU2VjdXJpdHkgTWVjaGFuaXNtczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgY29tcG9uZW50cyBvZiB0aGUgQU5JIG11 c3QgZWFjaCBpbmNsdWRlIGFwcHJvcHJpYXRlIHNlY3VyaXR5PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgVGhlIGNvbXBvbmVudHMgb2YgdGhlIEFOSSBtdXN0IGVhY2gg aW5jbHVkZSBhcHByb3ByaWF0ZSBzZWN1cml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgbWVjaGFuaXNtcy4gIEluIHBhcnRpY3VsYXIsIHRoZSBBQ1AgbXVzdCBwcm92 aWRlIHNlY3VyaXR5IGFnYWluc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBtZWNoYW5pc21zLiAgSW4gcGFydGljdWxhciwgdGhlIEFDUCBtdXN0IHByb3ZpZGUgc2Vj dXJpdHkgYWdhaW5zdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW50ZXJj ZXB0aW9uLCBmb3JnZXJ5LCBhbmQgcmVwbGF5IG9mIGFueSBtZXNzYWdlcyBzZW50IG92ZXIg dGhlIEFDUC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnRlcmNlcHRp b24sIGZvcmdlcnksIGFuZCByZXBsYXkgb2YgYW55IG1lc3NhZ2VzIHNlbnQgb3ZlciB0aGUg QUNQLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNpZ25hbGluZyBw cm90b2NvbCBtYXkgcmVseSBvbiB0aGlzIHByb3RlY3Rpb24sIGJ1dCBtdXN0IGFsc288L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgc2lnbmFsaW5nIHByb3RvY29s IG1heSByZWx5IG9uIHRoaXMgcHJvdGVjdGlvbiwgYnV0IG11c3QgYWxzbzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdmlkZSBmb3Igc2VjdXJpdHkgd2hlbiBydW5u aW5nIHdpdGhvdXQgYW4gQUNQLiAgQWxsIGNvbXBvbmVudHMgb2Y8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm92aWRlIGZvciBzZWN1cml0eSB3aGVuIHJ1bm5pbmcg d2l0aG91dCBhbiBBQ1AuICBBbGwgY29tcG9uZW50cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgdGhlIHNlY3VyaXR5IGJvb3RzdHJhcCBwcm9jZXNzIG11c3Qgb2Yg Y291cnNlIHRoZW1zZWx2ZXMgYmUgc2VjdXJlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0aGUgc2VjdXJpdHkgYm9vdHN0cmFwIHByb2Nlc3MgbXVzdCBvZiBjb3Vy c2UgdGhlbXNlbHZlcyBiZSBzZWN1cmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgQWxsIEFTQXMgbXVzdCBtYWtlIHVzZSBvZiB0aGUgQU5JJ3Mgc2VjdXJpdHksIGFu ZCBtdXN0IGJlIGNhcmVmdWxseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEFsbCBBU0FzIG11c3QgbWFrZSB1c2Ugb2YgdGhlIEFOSSdzIHNlY3VyaXR5LCBhbmQgbXVz dCBiZSBjYXJlZnVsbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlc2ln bmVkIHNvIHRoYXQgdGhleSBkbyBub3QgY3JlYXRlIHNlY3VyaXR5ICJob2xlcyIgaW4gdGhl IGJvdW5kYXJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzaWduZWQg c28gdGhhdCB0aGV5IGRvIG5vdCBjcmVhdGUgc2VjdXJpdHkgImhvbGVzIiBpbiB0aGUgYm91 bmRhcnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIHRoZSB3aG9sZSBB TiBzeXN0ZW0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgdGhlIHdo b2xlIEFOIHN5c3RlbS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+MTAuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+MTAuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgcmVxdWVzdHMgbm8gYWN0aW9u IGJ5IElBTkEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1 bWVudCByZXF1ZXN0cyBubyBhY3Rpb24gYnkgSUFOQS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MTEuICBBY2tub3dsZWRnZW1lbnRzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+MTEuICBBY2tub3dsZWRnZW1lbnRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1hbnkgcGVvcGxlIGhhdmUgcHJv dmlkZWQgZmVlZGJhY2sgYW5kIGlucHV0IHRvIHRoaXMgZG9jdW1lbnQ6IFNoZW5nPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWFueSBwZW9wbGUgaGF2ZSBwcm92aWRl ZCBmZWVkYmFjayBhbmQgaW5wdXQgdG8gdGhpcyBkb2N1bWVudDogU2hlbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTkiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgSmlhbmcsIFJvYmVydGEgTWFnbGlvbmUsIEpvbmF0aGFuIEhhbnNmb3Jk LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBKaWFuZywgUm9iZXJ0YSBN YWdsaW9uZSwgSm9uYXRoYW4gSGFuc2ZvcmQ8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4sIEphc29u IENvbGVtYW48L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4xMi4gIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4x Mi4gIFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgW0ktRC5kdS1hbmltYS1hbi1pbnRlbnRdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgW0ktRC5kdS1hbmltYS1hbi1pbnRlbnRdPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIwIj48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgICAgICAgICAgRHUsIFouLCBKaWFuZywgUy4sIE5vYnJlLCBKLiwgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+YW5kIEwuPC9zcGFuPiBDaWF2YWdsaWEsICJBTklNQTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIER1LCBaLiwgSmlhbmcsIFMu LCBOb2JyZSwgSi4sIENpYXZhZ2xpYSwgPHNwYW4gY2xhc3M9Imluc2VydCI+TC4sIGFuZCBN Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAg ICBJbnRlbnQgUG9saWN5IGFuZCBGb3JtYXQiLCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5kcmFm dC1kdS1hbmltYS1hbi1pbnRlbnQtMDM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgQmVocmluZ2Vy LDwvc3Bhbj4gIkFOSU1BIEludGVudCBQb2xpY3kgYW5kIEZvcm1hdCIsIDxzcGFuIGNsYXNz PSJpbnNlcnQiPmRyYWZ0LWR1LTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJk ZWxldGUiPk1hcmNoIDIwMTYuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIGFuaW1hLWFuLWludGVu dC0wNTwvc3Bhbj4gKHdvcmsgaW4gcHJvZ3Jlc3MpLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5G ZWJydWFyeSAyMDE3Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgW0ktRC5pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lXTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1hbmltYS1hdXRv bm9taWMtY29udHJvbC1wbGFuZV08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0iZGlmZjAwMjEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBC ZWhyaW5nZXIsIE0uLCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5CamFybmFzb24sIFMuLCBCTCwg Qi4sIGFuZCBULjwvc3Bhbj4gRWNrZXJ0LCAiQW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICBCZWhyaW5nZXIsIE0uLCBFY2tlcnQsIDxzcGFuIGNs YXNzPSJpbnNlcnQiPlQuLCBhbmQgUy4gQmphcm5hc29uLDwvc3Bhbj4gIkFuIEF1dG9ub21p YzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIEF1dG9u b21pYyBDb250cm9sIFBsYW5lIiwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQtaWV0Zi1h bmltYS1hdXRvbm9taWMtPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgICAgICAgIENvbnRyb2wgUGxhbmUiLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5k cmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLTwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAg ICBjb250cm9sLXBsYW5lLTAyPC9zcGFuPiAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDxz cGFuIGNsYXNzPSJkZWxldGUiPjIwMTYuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIHBsYW5lLTA2 PC9zcGFuPiAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDxzcGFuIGNsYXNzPSJpbnNlcnQi PjIwMTcuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGlu Zy1rZXlpbmZyYV08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwMjIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBQcml0aWtpbiwg TS4sIFJpY2hhcmRzb24sIE0uLCBCZWhyaW5nZXIsIE0uLCA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5hbmQgUy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAgICAgICAgUHJpdGlraW4sIE0uLCBSaWNoYXJkc29uLCBNLiwgQmVocmluZ2VyLCBNLiwg Qmphcm5hc29uLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgIEJqYXJuYXNvbiwgIkJvb3RzdHJhcHBpbmcgUmVtb3RlIFNlY3VyZSBLZXk8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5TLiwgYW5kIEsuIFdhdHNlbiw8L3NwYW4+ICJCb290c3RyYXBwaW5nIFJlbW90 ZSBTZWN1cmUgS2V5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgIEluZnJhc3RydWN0dXJlcyAoQlJTS0kpIiwgZHJhZnQtaWV0Zi1hbmltYS1ib290c3Ry YXBwaW5nLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg SW5mcmFzdHJ1Y3R1cmVzIChCUlNLSSkiLCBkcmFmdC1pZXRmLWFuaW1hLWJvb3RzdHJhcHBp bmctPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDIzIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAga2V5aW5mcmEtMDxzcGFuIGNs YXNzPSJkZWxldGUiPjMgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMTY8L3NwYW4+Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIGtleWluZnJh LTA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTc8 L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBb SS1ELmlldGYtYW5pbWEtZ3Jhc3BdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgW0ktRC5pZXRmLWFuaW1hLWdyYXNwXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgIEJvcm1hbm4sIDxzcGFuIGNsYXNzPSJkZWxldGUiPkQ8L3NwYW4+LiwgQ2FycGVudGVy LCBCLiwgYW5kIEIuIExpdSwgIkEgR2VuZXJpYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgIEJvcm1hbm4sIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkM8 L3NwYW4+LiwgQ2FycGVudGVyLCBCLiwgYW5kIEIuIExpdSwgIkEgR2VuZXJpYzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBBdXRvbm9taWMgU2lnbmFs aW5nIFByb3RvY29sIChHUkFTUCkiLCBkcmFmdC1pZXRmLWFuaW1hLTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQXV0b25vbWljIFNpZ25hbGluZyBQ cm90b2NvbCAoR1JBU1ApIiwgZHJhZnQtaWV0Zi1hbmltYS08L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjUiPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgICAgICAgICBncmFzcC08c3BhbiBjbGFzcz0iZGVsZXRlIj4wNiAod29yayBpbiBw cm9ncmVzcyksIEp1bmUgMjAxNjwvc3Bhbj4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgICAgICAgICAgZ3Jhc3AtPHNwYW4gY2xhc3M9Imluc2VydCI+MTQgKHdv cmsgaW4gcHJvZ3Jlc3MpLCBKdWx5IDIwMTc8L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtYW5pbWEtcHJlZml4LW1hbmFn ZW1lbnRdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWFu aW1hLXByZWZpeC1tYW5hZ2VtZW50XTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICBKaWFuZywgUy4sIER1LCBaLiwgQ2FycGVudGVyLCBCLiwgYW5kIFEu IFN1biwgIkF1dG9ub21pYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgSmlhbmcsIFMuLCBEdSwgWi4sIENhcnBlbnRlciwgQi4sIGFuZCBRLiBTdW4s ICJBdXRvbm9taWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgSVB2NiBFZGdlIFByZWZpeCBNYW5hZ2VtZW50IGluIExhcmdlLXNjYWxlIE5ldHdvcmtz Iiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIElQdjYg RWRnZSBQcmVmaXggTWFuYWdlbWVudCBpbiBMYXJnZS1zY2FsZSBOZXR3b3JrcyIsPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDI2Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQt aWV0Zi1hbmltYS1wcmVmaXgtbWFuYWdlbWVudC0wMDwvc3Bhbj4gKHdvcmsgaW4gcHJvZ3Jl c3MpLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWlldGYtYW5pbWEtcHJlZml4LW1hbmFnZW1lbnQt MDQ8L3NwYW4+ICh3b3JrIGluIHByb2dyZXNzKSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5KYW51YXJ5IDIw MTYuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAg ICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkp1bmUgMjAxNy48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQubGl1LWFuaW1hLWdyYXNw LWFwaV08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmxpdS1hbmlt YS1ncmFzcC1hcGldPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgIENhcnBlbnRlciwgQi4sIExpdSwgQi4sIFdhbmcsIFcuLCBhbmQgWC4gR29uZywgIkdl bmVyaWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIENh cnBlbnRlciwgQi4sIExpdSwgQi4sIFdhbmcsIFcuLCBhbmQgWC4gR29uZywgIkdlbmVyaWM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgQXV0b25vbWlj IFNpZ25hbGluZyBQcm90b2NvbCBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQXV0b25vbWljIFNp Z25hbGluZyBQcm90b2NvbCBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyNyI+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAgICAgICAgIChHUkFTUCBBUEkpIiwgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS0wMTwvc3Bhbj4gKHdvcmsgaW48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAoR1JBU1AgQVBJ KSIsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGktMDQ8 L3NwYW4+ICh3b3JrIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg ICAgICAgICAgcHJvZ3Jlc3MpLCBKdW5lIDxzcGFuIGNsYXNzPSJkZWxldGUiPjIwMTYuPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIHBy b2dyZXNzKSwgSnVuZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yMDE3Ljwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5saXUtYW5pbWEt Z3Jhc3AtZGlzdHJpYnV0aW9uXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl08L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgTGl1LCBCLiBhbmQgUy4gSmlhbmcsICJJbmZv cm1hdGlvbiBEaXN0cmlidXRpb24gb3ZlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgTGl1LCBCLiBhbmQgUy4gSmlhbmcsICJJbmZvcm1hdGlvbiBE aXN0cmlidXRpb24gb3ZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAyOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIEdSQVNQ IiwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1 dGlvbi0wMTwvc3Bhbj4gKHdvcmsgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICAgICAgICAgICBHUkFTUCIsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWxp dS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24tMDQ8L3NwYW4+ICh3b3JrIGluPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCA8c3Bh biBjbGFzcz0iZGVsZXRlIj5NYXJjaCAyMDE2Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJp bnNlcnQiPk1heSAyMDE3Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgW0ktRC5zdHJhc3NuZXItYW5pbWEtY29udHJvbC1sb29wc108L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELnN0cmFzc25lci1hbmltYS1j b250cm9sLWxvb3BzXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICBTdHJhc3NuZXIsIEouLCBIYWxwZXJuLCBKLiwgYW5kIE0uIEJlaHJpbmdlciwgIlRo ZSBVc2Ugb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg IFN0cmFzc25lciwgSi4sIEhhbHBlcm4sIEouLCBhbmQgTS4gQmVocmluZ2VyLCAiVGhlIFVz ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBDb250 cm9sIExvb3BzIGluIEF1dG9ub21pYyBOZXR3b3JraW5nIiwgZHJhZnQtc3RyYXNzbmVyLTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQ29udHJvbCBM b29wcyBpbiBBdXRvbm9taWMgTmV0d29ya2luZyIsIGRyYWZ0LXN0cmFzc25lci08L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgYW5pbWEtY29udHJvbC1s b29wcy0wMSAod29yayBpbiBwcm9ncmVzcyksIEFwcmlsIDIwMTYuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBhbmltYS1jb250cm9sLWxvb3BzLTAx ICh3b3JrIGluIHByb2dyZXNzKSwgQXByaWwgMjAxNi48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0lEZXZJRF0gICBJRUVFIFN0YW5kYXJkLCAsICJJ RUVFIDgwMi4xQVIgU2VjdXJlIERldmljZSBJZGVudGlmaWVyIiw8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBbSURldklEXSAgIElFRUUgU3RhbmRhcmQsICwgIklFRUUg ODAyLjFBUiBTZWN1cmUgRGV2aWNlIElkZW50aWZpZXIiLDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBEZWNlbWJlciAyMDA5LCAmbHQ7aHR0cDovL3N0 YW5kYXJkcy5pZWVlLm9yZy9maW5kc3Rkcy88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMDksICZsdDtodHRwOi8vc3RhbmRhcmRz LmllZWUub3JnL2ZpbmRzdGRzLzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICBzdGFuZGFyZC84MDIuMUFSLTIwMDkuaHRtbCZndDsuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBzdGFuZGFyZC84MDIuMUFSLTIw MDkuaHRtbCZndDsuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+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+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjkiPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICAgICAgICAgICBOZXR3b3JraW5nOiBEZWZpbml0aW9ucyBhbmQg RGVzaWduIEdvYWxzIiwgUkZDIDc1NzUsIERPSTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgIE5ldHdvcmtpbmc6IERlZmluaXRpb25zIGFuZCBEZXNp Z24gR29hbHMiLCBSRkMgNzU3NSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgICAgICAgICAxMC4xNzQ4Ny9SRkM3NTc1LCBKdW5lIDIwMTUsPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzc1 NzUsIEp1bmUgMjAxNSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgJmx0O2h0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NTc1Jmd0Oy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICZsdDtodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzU3NSZndDsuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3NTc2XSAgSmlhbmcsIFMuLCBD YXJwZW50ZXIsIEIuLCBhbmQgTS4gQmVocmluZ2VyLCAiR2VuZXJhbCBHYXA8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDNzU3Nl0gIEppYW5nLCBTLiwgQ2FycGVu dGVyLCBCLiwgYW5kIE0uIEJlaHJpbmdlciwgIkdlbmVyYWwgR2FwPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDMwIj48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgICAgICAgICAgQW5hbHlzaXMgZm9yIEF1dG9ub21pYyBOZXR3b3JraW5nIiwg UkZDIDc1NzYsIERPSTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgIEFuYWx5c2lzIGZvciBBdXRvbm9taWMgTmV0d29ya2luZyIsIFJGQyA3NTc2LDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIDEwLjE3NDg3 L1JGQzc1NzYsIEp1bmUgMjAxNSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNzU3NiwgSnVuZSAyMDE1LDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc1NzYmZ3Q7LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgJmx0O2h0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcv aW5mby9yZmM3NTc2Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIE1pY2hhZWwgSC4gQmVocmluZ2VyIChlZGl0b3IpPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWljaGFlbCBILiBCZWhyaW5nZXIgKGVkaXRvcik8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRW1haWw6IE1p Y2hhZWwuSC5CZWhyaW5nZXJAZ21haWwuY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgRW1haWw6IE1pY2hhZWwuSC5CZWhyaW5nZXJAZ21haWwuY29tPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCcmlhbiBDYXJwZW50ZXI8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBCcmlhbiBDYXJwZW50ZXI8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERlcGFydG1lbnQgb2YgQ29tcHV0ZXIg U2NpZW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVW5pdmVyc2l0eSBv ZiBBdWNrbGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFVuaXZlcnNp dHkgb2YgQXVja2xhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CgogICAg IDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgaWQ9ImVuZCIgYmdjb2xv cj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPiZuYnNwO0VuZCBvZiBj aGFuZ2VzLiAzMCBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvdGg+PC90cj4KICAgICA8dHIgY2xh c3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+ODAgbGluZXMgY2hhbmdlZCBvciBkZWxldGVk PC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+ODggbGluZXMgY2hhbmdlZCBvciBh ZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBh bGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxici8+VGhpcyBodG1sIGRpZmYgd2FzIHBy b2R1Y2VkIGJ5IHJmY2RpZmYgMS40NS4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlm Zi8iID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90 cj4KICAgPC90YWJsZT4KICAgPC9ib2R5PgogICA8L2h0bWw+Cg== --------------195FB27FA2CF5D1A5A8257E2-- From nobody Tue Jul 4 04:35:02 2017 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 2B089131F56 for ; Tue, 4 Jul 2017 04:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 QhjGVCwq4HvL for ; Tue, 4 Jul 2017 04:34:55 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 62332131F53 for ; Tue, 4 Jul 2017 04:34:54 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id 77so247640734wrb.1 for ; Tue, 04 Jul 2017 04:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language; bh=zVPDP2GlbTvXlXM2djKDLWmiujb2IxrKpTGiAK4gsI4=; b=qydmNHQBZFdFtGKouZxDpM7bOwSha6XJC4ztlsWnXyWycrizhazEt41HlOJM/JAKZx 3Swum7F/xkGTICvtOD+iDQJxYyDlrfSAZHxt+9AxQuE5x52+Fh1I3XX/uHAuKAKu3aZ5 PmxkXmSCN6HEcgGW9/HvXFklygLedMzuMHwtmSqYLHabOmUK2K9+bMR+TTN6enBlEKgZ QC6PRoJgDam7h1+odzTeSNtVwLkQvK1NfFWoLCDFxKMXnCI+shn0JD68bbH/pq1edkWY 8RUuM5Ar3+EmdwUaNzjgsYFC4P1FDrmw2qGrANwPfFOrciCiwQhdZRNQ+pR48JaIpREF 5GYw== 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:message-id:date:user-agent :mime-version:content-language; bh=zVPDP2GlbTvXlXM2djKDLWmiujb2IxrKpTGiAK4gsI4=; b=YDFdo1GqmhPVDU7QOaiY3SdviKR/8FoTAD7waOJwaVP1Kiz0pQsJUDxg53xB4mcu7n f/vYnhFIitPtidbmKxq5yGpvM1O/O7O6lAt2IDWkEigOWmQAqBBv2TklX+UbKy3bnbBq EZT5RnpFJFRJhqRV0YNdwwymRKJHl9zNPfFQaY5+stc3pNofEC0NN4ptw980RfvvYZLF MyhlOCzlsbPnTRhxqO/oh4C1ZZSA0lndSErRMZQNDk8nZuucAZbCNoT1khQE37XwQHm5 Dyho5YFZweCcuunMnTZ9FXB3FDpQy284MEmr7iBzDyO+4bcHu1dXZ4goktoZKzb9FQKI Bj1A== X-Gm-Message-State: AKS2vOzqTjMBuYygqo2xYInTHIcNbrl+ldBP7NFEk8Tr3GpeqoCgodtw frthHfpnghrihw8eBP0= X-Received: by 10.223.135.68 with SMTP id 4mr28600624wrz.141.1499168092684; Tue, 04 Jul 2017 04:34:52 -0700 (PDT) Received: from [192.168.1.25] (ANice-652-1-72-84.w86-205.abo.wanadoo.fr. [86.205.71.84]) by smtp.gmail.com with ESMTPSA id w30sm22573338wrb.49.2017.07.04.04.34.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 04:34:51 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: "anima@ietf.org" Message-ID: <73809544-b043-1834-f572-09dbf8b82983@gmail.com> Date: Tue, 4 Jul 2017 13:34:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------F5D4D8D8A03D99C96331B8CA" Content-Language: en-GB Archived-At: Subject: [Anima] draft-ietf-anima-reference-model-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jul 2017 11:35:00 -0000 This is a multi-part message in MIME format. --------------F5D4D8D8A03D99C96331B8CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As promised, here the new version of the reference model draft. I'll be submitting in a minute, the github repo already has it: https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model-04.txt. The diff is attached for easy consumption. As suggested by Brian, I re-read the draft, and changed the general wording in some places regarding "work in progress", etc. I now call this AN phase 1, and explain that there may be more phases. Changed the security section almost completely, taking into account the comments received. Specifically, pointing out the threats on the ACP. I was about to add a comparison to the security of the routing system, but in the end decided against. Folks - please review and let me know how this reads. In the security section we had the phrase: "AN messages are liable to be exposed to third parties on any unprotected Layer 2 link." I think this is only true for specific discovery-like messages like GRASP M_FLOOD, but by default most AN messages are inside the ACP and thus encrypted. So I suggest to change this rather scary sounding sentence, and point out that only specific messages are unprotected, and point to section 2.5.2 of the GRASP draft. Updated a few references, editorial stuff, etc. I suggest the draft is ready for WGLC, and would request the chairs to issue that call. Michael --------------F5D4D8D8A03D99C96331B8CA Content-Type: text/html; charset=UTF-8; name="Diff: draft-ietf-anima-reference-model-03.txt - draft-ietf-anima-reference-model-04.txt.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="Diff: draft-ietf-anima-reference-model-03.txt - draft-ietf-a"; filename*1="nima-reference-model-04.txt.html" CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRp b25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFu c2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NTogcmZjZGlm ZiAgLS0+IAo8IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0 LjAxIFRyYW5zaXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGR1cmlmIDMuMi4w LTQtYW1kNjQgIzEgU01QIERlYmlhbiAzLjIuODQtMSB4ODZfNjQgR05VL0xpbnV4IC0tPiAK PCEtLSBVc2luZyBhd2s6IC91c3IvYmluL2dhd2s6IEdOVSBBd2sgNC4wLjEgLS0+IAo8IS0t IFVzaW5nIGRpZmY6IC91c3IvYmluL2RpZmY6IGRpZmYgKEdOVSBkaWZmdXRpbHMpIDMuMiAt LT4gCjwhLS0gVXNpbmcgd2RpZmY6IC91c3IvYmluL3dkaWZmOiB3ZGlmZiAoR05VIHdkaWZm KSAxLjEuMiAtLT4gCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1s Ij4gCjxoZWFkPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCIgLz4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyIgLz4gCiAgPHRpdGxlPkRpZmY6 IGRyYWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTAzLnR4dCAtIGRyYWZ0LWlldGYt YW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0LnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0 ZXh0L2NzcyI+IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDog YXV0bzsgfSAKICAgIHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBw cmU7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQt c2l6ZTogMC44NmVtO30gCiAgICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAg ICAuc21hbGwgIHsgZm9udC1zaXplOiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250 LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQg ICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3Vu ZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NG OyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gCiAgICAucmJs b2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAgIC5pbnNlcnQgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNB Q0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGQjsgfSAKICAgIC5j b250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmViciB7IGJhY2tn cm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsgYmFja2dy b3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmlnaHQ7 IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAg ICAucmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9j ayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250 IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQt Y29sb3I6ICM4QUQ7IH0gCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFj a2dyb3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUg eyBkaXNwbGF5OiBub25lOyBjb2xvcjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3Bs YXk6IGlubGluZTsgfSAgICB0ci5jaGFuZ2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9 IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFj ayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+CnZhciBjaHVua19pbmRleCA9IDA7CnZh ciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9ybWF0X2NodW5rKGluZGV4KSB7CiAg ICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9IGluZGV4LnRvU3RyaW5nKCk7 CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7CiAgICAgICAgcHJlZml4 Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9CgpmdW5jdGlvbiBmaW5k X2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3IoJ3RyW2lkJD0i JyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkgewogICAg dmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsKICAg IHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmsp IHsKICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAg b2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5l d19jaHVuazsKICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQi OwogICAgd2luZG93LmxvY2F0aW9uLmhhc2ggPSAiIyIgKyBuZXdfc3RyOwogICAgd2luZG93 LnNjcm9sbEJ5KDAsLTEwMCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9Cgpkb2N1bWVu dC5vbmtleWRvd24gPSBmdW5jdGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5Q29kZSkgewog ICAgY2FzZSA3ODoKICAgICAgICBjaGFuZ2VfY2h1bmsoMSk7CiAgICAgICAgYnJlYWs7CiAg ICBjYXNlIDgwOgogICAgICAgIGNoYW5nZV9jaHVuaygtMSk7CiAgICAgICAgYnJlYWs7CiAg ICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFkPiAKPGJvZHkgPiAKICA8dGFibGUgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dHIgaWQ9InBhcnQt MSIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMy50eHQiIHN0eWxlPSJjb2xv cjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZsdDs8L2E+Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNl LW1vZGVsLTAzLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtYW5pbWEtcmVm ZXJlbmNlLW1vZGVsLTAzLnR4dDwvYT4mbmJzcDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEt cmVmZXJlbmNlLW1vZGVsLTA0LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYt YW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0LnR4dDwvYT4mbmJzcDs8YSBocmVmPSIvcmZjZGlm Zj91cmwxPWRyYWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0LnR4dCIgc3R5bGU9 ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3RoPjx0aD48 L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPkFOSU1BICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNLiBCZWhyaW5nZXIsIEVkLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPkFOSU1BICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNLiBCZWhyaW5nZXIsIEVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJhZnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50 ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQi4gQ2FycGVudGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZW5k ZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Qi4gQ2FycGVudGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJk ZWxldGUiPlNlcHRlbWJlciAxNCwgMjAxNzwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgVW5pdi4gb2YgQXVja2xhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+RXhwaXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+SmFudWFyeSA0LCAyMDE4ICAgPC9z cGFuPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2LiBvZiBBdWNrbGFuZDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gRWNrZXJ0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gRWNrZXJ0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGdXR1cmV3ZWkgVGVjaG5vbG9naWVzIEluYy48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGdXR1cmV3ZWkgVGVjaG5vbG9naWVzIEluYy48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEwuIENpYXZhZ2xpYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEwuIENpYXZhZ2xpYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUC4gUGVsb3NvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUC4gUGVsb3NvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTm9raWE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEIuIExpdTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEIuIExpdTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIdWF3ZWkgVGVjaG5vbG9n aWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIdWF3ZWkgVGVjaG5vbG9naWVz PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gTm9icmU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gTm9icmU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZlZGVyYWwgVW5pdmVyc2l0eSBvZiBSaW8gR3JhbmRlIGRvIFN1bDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEZlZGVyYWwgVW5pdmVyc2l0eSBvZiBSaW8gR3JhbmRlIGRvIFN1bDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gU3RyYXNzbmVyPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSi4gU3RyYXNzbmVyPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEh1YXdlaSBUZWNobm9sb2dpZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEh1YXdlaSBUZWNobm9sb2dpZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPk1hcmNoIDE8L3NwYW4+MywgMjAxNzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ICBKdWx5IDwvc3Bh bj4zLCAyMDE3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgIEEgUmVmZXJlbmNlIE1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2lu ZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgIEEgUmVm ZXJlbmNlIE1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0w PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2Ut bW9kZWwtMDxzcGFuIGNsYXNzPSJpbnNlcnQiPjQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSByZWZlcmVuY2UgbW9kZWwg Zm9yIEF1dG9ub21pYyBOZXR3b3JraW5nLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcmVmZXJlbmNlIG1vZGVsIGZvciBB dXRvbm9taWMgTmV0d29ya2luZy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFRoZSBnb2FsIGlzIHRvIGRlZmluZSBob3cgdGhlIHZhcmlvdXMgZWxlbWVudHMgaW4gYW4g YXV0b25vbWljPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGdvYWwg aXMgdG8gZGVmaW5lIGhvdyB0aGUgdmFyaW91cyBlbGVtZW50cyBpbiBhbiBhdXRvbm9taWM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbnRleHQgd29yayB0b2dldGhl ciwgdG8gZGVzY3JpYmUgdGhlaXIgaW50ZXJmYWNlcyBhbmQgcmVsYXRpb25zLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRleHQgd29yayB0b2dldGhlciwgdG8g ZGVzY3JpYmUgdGhlaXIgaW50ZXJmYWNlcyBhbmQgcmVsYXRpb25zLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2hpbGUgdGhlIGRvY3VtZW50IGlzIHdyaXR0ZW4gYXMg Z2VuZXJhbGx5IGFzIHBvc3NpYmxlLCB0aGUgaW5pdGlhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFdoaWxlIHRoZSBkb2N1bWVudCBpcyB3cml0dGVuIGFzIGdlbmVy YWxseSBhcyBwb3NzaWJsZSwgdGhlIGluaXRpYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHNvbHV0aW9ucyBhcmUgbGltaXRlZCB0byB0aGUgY2hhcnRlcmVkIHNjb3Bl IG9mIHRoZSBXRy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzb2x1dGlv bnMgYXJlIGxpbWl0ZWQgdG8gdGhlIGNoYXJ0ZXJlZCBzY29wZSBvZiB0aGUgV0cuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlN0YXR1cyBvZiBUaGlzIE1l bW88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5TdGF0dXMgb2YgVGhpcyBNZW1v PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSAx LCBsaW5lIDQ2PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90 aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxh IGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBsaW5lIDQ2PHNwYW4gY2xhc3M9ImhpZGUi PiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1E cmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu ZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUg dGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBE cmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50 Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0 ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g PHNwYW4gY2xhc3M9ImRlbGV0ZSI+U2VwdGVtYmVyIDE0LCAyMDE3PC9zcGFuPi48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5KYW51YXJ5IDQsIDIwMTg8L3NwYW4+ LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQg Tm90aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGlj ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb3B5cmln aHQgKGMpIDIwMTcgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb3B5cmlnaHQgKGMpIDIw MTcgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmln aHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3Vt ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g QkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChodHRwOi8vdHJ1c3Rl ZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9y Zy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBs ZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0zIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+ PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0 LTMiPjxlbT4gcGFnZSAzLCBsaW5lIDE1PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3Nw YW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTMiPjxlbT4gcGFnZSAzLCBsaW5lIDE1PHNw YW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgIDcuMi4gIEludGVudCAoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgIDcuMi4gIEludGVudCAoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg Ny4zLiAgQWdncmVnYXRlZCBSZXBvcnRpbmcgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNy4z LiAgQWdncmVnYXRlZCBSZXBvcnRpbmcgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxOTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjQuICBG ZWVkYmFjayBMb29wcyB0byBOT0MoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDIwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjQuICBGZWVk YmFjayBMb29wcyB0byBOT0MoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDIwPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDcuNS4gIENvbnRyb2wg TG9vcHMgKCopIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjA8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDcuNS4gIENvbnRyb2wgTG9v cHMgKCopIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjA8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNy42LiAgQVBJcyAoKikgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNy42LiAgQVBJcyAoKikgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjcuICBEYXRhIE1vZGVsICgqKSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIxPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjcuICBEYXRhIE1vZGVsICgqKSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIxPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICA4LiAgQ29vcmRpbmF0aW9uIEJldHdlZW4gQXV0b25vbWljIEZ1 bmN0aW9ucyAoKikgIC4gLiAuIC4gLiAuIC4gLiAgMjI8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICA4LiAgQ29vcmRpbmF0aW9uIEJldHdlZW4gQXV0b25vbWljIEZ1bmN0 aW9ucyAoKikgIC4gLiAuIC4gLiAuIC4gLiAgMjI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgOC4xLiAgVGhlIENvb3JkaW5hdGlvbiBQcm9ibGVtICgqKSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgOC4xLiAgVGhlIENvb3JkaW5hdGlvbiBQcm9ibGVtICgqKSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAyMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICA4LjIuICBBIENvb3JkaW5hdGlvbiBGdW5jdGlvbmFsIEJsb2NrICgqKSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDIzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICA4LjIuICBBIENvb3JkaW5hdGlvbiBGdW5jdGlvbmFsIEJsb2NrICgqKSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDIzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA5LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA5LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMjQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA5LjEuICA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5UaHJlYXQgQW5hbHlzaXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuPC9zcGFuPiAuIC4g LiAuIC4gLiAuIC4gLiAuICAyNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgIDkuMS4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkNvbnNlcXVlbmNlcyBvZiBhIERpc3Ry aWJ1dGVkIFN5c3RlbSA8L3NwYW4+IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDkuMi4gIFNlY3VyaXR5IE1lY2hhbmlzbXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDkuMi4gIFNlY3VyaXR5IE1lY2hhbmlzbXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgMTEuIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgMTEuIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAxMi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAxMi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMjU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1 dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAyNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dGhv cnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAyNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4x LiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4gIElu dHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBUaGUgZG9jdW1lbnQgIkF1dG9ub21pYyBOZXR3b3JraW5nIC0gRGVmaW5pdGlvbnMgYW5k IERlc2lnbiBHb2FscyI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUg ZG9jdW1lbnQgIkF1dG9ub21pYyBOZXR3b3JraW5nIC0gRGVmaW5pdGlvbnMgYW5kIERlc2ln biBHb2FscyI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3NTc1XSBl eHBsYWlucyB0aGUgZnVuZGFtZW50YWwgY29uY2VwdHMgYmVoaW5kIEF1dG9ub21pYzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM3NTc1XSBleHBsYWlucyB0aGUg ZnVuZGFtZW50YWwgY29uY2VwdHMgYmVoaW5kIEF1dG9ub21pYzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNCIgY2xh c3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0 PC9zbWFsbD48YSBocmVmPSIjcGFydC00Ij48ZW0+IHBhZ2UgMywgbGluZSA0MjxzcGFuIGNs YXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC00Ij48 ZW0+IHBhZ2UgMywgbGluZSA0MjxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwv ZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXJjaGl0ZWN0dXJhbGx5IGNvbnNpc3RlbnQs IG5vbi1vdmVybGFwcGluZyBtYW5uZXIuICBXaGlsZSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBhcmNoaXRlY3R1cmFsbHkgY29uc2lzdGVudCwgbm9uLW92ZXJs YXBwaW5nIG1hbm5lci4gIFdoaWxlIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgZG9jdW1lbnQgaXMgd3JpdHRlbiBhcyBnZW5lcmFsbHkgYXMgcG9zc2libGUsIHRo ZSBpbml0aWFsIHNvbHV0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGRvY3VtZW50IGlzIHdyaXR0ZW4gYXMgZ2VuZXJhbGx5IGFzIHBvc3NpYmxlLCB0aGUgaW5p dGlhbCBzb2x1dGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFyZSBs aW1pdGVkIHRvIHRoZSBjaGFydGVyZWQgc2NvcGUgb2YgdGhlIFdHLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFyZSBsaW1pdGVkIHRvIHRoZSBjaGFydGVyZWQgc2Nv cGUgb2YgdGhlIFdHLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBBcyBkaXNjdXNzZWQgaW4gW1JGQzc1NzVdLCB0aGUgZ29hbCBvZiB0aGlzIHdvcmsg aXMgbm90IHRvIGZvY3VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXMg ZGlzY3Vzc2VkIGluIFtSRkM3NTc1XSwgdGhlIGdvYWwgb2YgdGhpcyB3b3JrIGlzIG5vdCB0 byBmb2N1czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZXhjbHVzaXZlbHkg b24gZnVsbHkgYXV0b25vbWljIG5vZGVzIG9yIG5ldHdvcmtzLiAgSW4gcmVhbGl0eSwgbW9z dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4Y2x1c2l2ZWx5IG9uIGZ1 bGx5IGF1dG9ub21pYyBub2RlcyBvciBuZXR3b3Jrcy4gIEluIHJlYWxpdHksIG1vc3Q8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5ldHdvcmtzIHdpbGwgcnVuIHdpdGgg c29tZSBhdXRvbm9taWMgZnVuY3Rpb25zLCB3aGlsZSB0aGUgcmVzdCBvZjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5ldHdvcmtzIHdpbGwgcnVuIHdpdGggc29tZSBh dXRvbm9taWMgZnVuY3Rpb25zLCB3aGlsZSB0aGUgcmVzdCBvZjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIG5ldHdvcmsgaXMgdHJhZGl0aW9uYWxseSBtYW5hZ2Vk LiAgVGhpcyByZWZlcmVuY2UgbW9kZWwgYWxsb3dzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgdGhlIG5ldHdvcmsgaXMgdHJhZGl0aW9uYWxseSBtYW5hZ2VkLiAgVGhp cyByZWZlcmVuY2UgbW9kZWwgYWxsb3dzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBmb3IgdGhpcyBoeWJyaWQgYXBwcm9hY2guPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgZm9yIHRoaXMgaHlicmlkIGFwcHJvYWNoLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIFRoaXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aXMgYSBsaXZpbmc8 L3NwYW4+IGRvY3VtZW50IGFuZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj53aWxsIGV2b2x2ZSB3 aXRoPC9zcGFuPiB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGVjaG5pY2FsPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIGRvY3VtZW50IDxzcGFu IGNsYXNzPSJpbnNlcnQiPmRlc2NyaWJlcyBwaGFzZSAxIG9mIGFuIEF1dG9ub21pYyBOZXR3 b3JraW5nIHNvbHV0aW9uLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgc29sdXRpb25zIGRldmVsb3BlZCBpbjwvc3Bh bj4gdGhlIEFOSU1BIDxzcGFuIGNsYXNzPSJkZWxldGUiPldHLjwvc3Bhbj4gIFNlY3Rpb25z IG1hcmtlZCB3aXRoICgqKSBkbyBub3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNvdmVycyBwcmltYXJpbHk8L3NwYW4+ IHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5XRyBpdGVtcyBvZjwvc3Bhbj4gdGhlIEFOSU1B IDxzcGFuIGNsYXNzPSJpbnNlcnQiPldHIGFzIG9mIEp1bHkgMjAxNy48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlcHJlc2VudCA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5jdXJyZW50IGNoYXJ0ZXIgaXRlbXMuICBXaGlsZSB0aGlzIGRvY3VtZW50IG11 c3QgZ2l2ZSBhPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBT ZWN0aW9ucyBtYXJrZWQgd2l0aCAoKikgZG8gbm90IHJlcHJlc2VudCA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5jaGFydGVyZWQgaXRlbXM8L3NwYW4+IGF0IDxzcGFuIGNsYXNzPSJpbnNlcnQi PnRoaXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgIGxvbmcgdGVybSBhcmNoaXRlY3R1cmFsIHZpZXcsIG5vdCBhbGwg ZnVuY3Rpb25zIHdpbGwgYmUgc3RhbmRhcmRpemVkPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICB0aW1lLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+TmV3IFdH IGl0ZW1zIHdpbGwgcmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCwgb3I8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGF0IDxzcGFuIGNsYXNz PSJkZWxldGUiPnRoZSBzYW1lPC9zcGFuPiB0aW1lLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBwb3RlbnRpYWxseSBhIG5ldyBk b2N1bWVudC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjIuICBUaGUgTmV0d29yayBWaWV3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+Mi4gIFRoZSBOZXR3b3JrIFZpZXc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgdmFyaW91cyBlbGVt ZW50cyBpbiBhIG5ldHdvcmsgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHZhcmlvdXMgZWxlbWVudHMgaW4gYSBu ZXR3b3JrIHdpdGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dG9ub21p YyBmdW5jdGlvbnMsIGFuZCBob3cgdGhlc2UgZW50aXRpZXMgd29yayB0b2dldGhlciwgb24g YSBoaWdoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXV0b25vbWljIGZ1 bmN0aW9ucywgYW5kIGhvdyB0aGVzZSBlbnRpdGllcyB3b3JrIHRvZ2V0aGVyLCBvbiBhIGhp Z2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxldmVsLiAgU3Vic2VxdWVu dCBzZWN0aW9ucyBleHBsYWluIHRoZSBkZXRhaWxlZCBpbnNpZGUgdmlldyBmb3IgZWFjaDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxldmVsLiAgU3Vic2VxdWVudCBz ZWN0aW9ucyBleHBsYWluIHRoZSBkZXRhaWxlZCBpbnNpZGUgdmlldyBmb3IgZWFjaDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIGF1dG9ub21pYyBuZXR3b3Jr IGVsZW1lbnRzLCBhcyB3ZWxsIGFzIHRoZSBuZXR3b3JrIGZ1bmN0aW9uczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIHRoZSBhdXRvbm9taWMgbmV0d29yayBlbGVt ZW50cywgYXMgd2VsbCBhcyB0aGUgbmV0d29yayBmdW5jdGlvbnM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIChvciBpbnRlcmZhY2VzKSBiZXR3ZWVuIHRob3NlIGVsZW1l bnRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChvciBpbnRlcmZhY2Vz KSBiZXR3ZWVuIHRob3NlIGVsZW1lbnRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBGaWd1cmUgMSBzaG93cyB0aGUgaGlnaCBsZXZlbCB2aWV3IG9m IGFuIEF1dG9ub21pYyBOZXR3b3JrLiAgSXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBGaWd1cmUgMSBzaG93cyB0aGUgaGlnaCBsZXZlbCB2aWV3IG9mIGFuIEF1dG9u b21pYyBOZXR3b3JrLiAgSXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTUiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90 ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3Bh cnQtNSI+PGVtPiBwYWdlIDcsIGxpbmUgMTA8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNSI+PGVtPiBwYWdlIDcsIGxpbmUgMTA8 c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIG8gIFZlbmRvciByZS1kaXJlY3Q6IEEgbmV3IGRldmljZSBtYXkgcmVjZWl2ZSBp bmZvcm1hdGlvbiBvbiB3aGVyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG8gIFZlbmRvciByZS1kaXJlY3Q6IEEgbmV3IGRldmljZSBtYXkgcmVjZWl2ZSBpbmZvcm1h dGlvbiBvbiB3aGVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgaXRz IGhvbWUgbmV0d29yayBpcyB0aHJvdWdoIGEgdmVuZG9yIGJhc2VkIE1BU0EgcmUtZGlyZWN0 OyB0aGlzIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgaXRzIGhv bWUgbmV0d29yayBpcyB0aHJvdWdoIGEgdmVuZG9yIGJhc2VkIE1BU0EgcmUtZGlyZWN0OyB0 aGlzIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0eXBpY2FsbHkg YSByb3V0YWJsZSBhZGRyZXNzLiAgU2VlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgdHlwaWNhbGx5IGEgcm91dGFibGUgYWRkcmVzcy4gIFNlZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJhcHBp bmcta2V5aW5mcmFdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFtJ LUQuaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhXS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgTm9uLWF1dG9ub21pYyBpbnB1dDog QSBub2RlIG1heSBiZSBjb25maWd1cmVkIG1hbnVhbGx5IHdpdGggYW48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBOb24tYXV0b25vbWljIGlucHV0OiBBIG5vZGUg bWF5IGJlIGNvbmZpZ3VyZWQgbWFudWFsbHkgd2l0aCBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgYXV0b25vbWljIHBlZXI7IGl0IGNvdWxkIGxlYXJuIGFib3V0 IGF1dG9ub21pYyBub2RlcyB0aHJvdWdoIERIQ1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBhdXRvbm9taWMgcGVlcjsgaXQgY291bGQgbGVhcm4gYWJvdXQgYXV0 b25vbWljIG5vZGVzIHRocm91Z2ggREhDUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgb3B0aW9ucywgRE5TLCBhbmQgb3RoZXIgbm9uLWF1dG9ub21pYyBtZWNoYW5p c21zLiAgR2VuZXJhbGx5IHN1Y2g8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICBvcHRpb25zLCBETlMsIGFuZCBvdGhlciBub24tYXV0b25vbWljIG1lY2hhbmlzbXMu ICBHZW5lcmFsbHkgc3VjaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg bm9uLWF1dG9ub21pYyBtZWNoYW5zaW1zIHJlcXVpcmUgc29tZSBhZG1pbmlzdHJhdG9yIGlu dGVydmVudGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBub24t YXV0b25vbWljIG1lY2hhbnNpbXMgcmVxdWlyZSBzb21lIGFkbWluaXN0cmF0b3IgaW50ZXJ2 ZW50aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgVGhlIGtleSBw dXJwb3NlIGlzIHRvIGJ5LXBhc3MgYSBub24tYXV0b25vbWljIGRldmljZSBvciBuZXR3b3Jr LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoZSBrZXkgcHVycG9z ZSBpcyB0byBieS1wYXNzIGEgbm9uLWF1dG9ub21pYyBkZXZpY2Ugb3IgbmV0d29yay48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDci Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgQXMgdGhpcyBwZXJ0YWlucyB0byBuZXcgZGV2aWNlcywg aXQgaXMgY292ZXJlZCBpbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5TZWN0aW9uIDUuMzwvc3Bh bj4gb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgQXMgdGhpcyBw ZXJ0YWlucyB0byBuZXcgZGV2aWNlcywgaXQgaXMgY292ZXJlZCBpbiA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5BcHBlbmRpeCBBIGFuZCBCPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZy YV0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIG9mIFtJLUQuaWV0 Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhXS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGFkamFjZW5jeSB0YWJsZSBpcyBkZWZpbmlu ZyB0aGUgYmVoYXZpb3VyIG9mIGFuIGF1dG9ub21pYyBub2RlOjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBhZGphY2VuY3kgdGFibGUgaXMgZGVmaW5pbmcgdGhl IGJlaGF2aW91ciBvZiBhbiBhdXRvbm9taWMgbm9kZTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgSWYgdGhlIG5vZGUgaGFzIG5vdCBib290c3Ry YXBwZWQgaW50byBhIGRvbWFpbiAoaS5lLiwgZG9lc24ndCBoYXZlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgSWYgdGhlIG5vZGUgaGFzIG5vdCBib290c3RyYXBw ZWQgaW50byBhIGRvbWFpbiAoaS5lLiwgZG9lc24ndCBoYXZlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICBhIGRvbWFpbiBjZXJ0aWZpY2F0ZSksIGl0IHJvdGF0ZXMg dGhyb3VnaCBhbGwgbm9kZXMgaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgYSBkb21haW4gY2VydGlmaWNhdGUpLCBpdCByb3RhdGVzIHRocm91Z2ggYWxs IG5vZGVzIGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYWRq YWNlbmN5IHRhYmxlIHRoYXQgY2xhaW0gdG8gaGF2ZSBhIGRvbWFpbiwgYW5kIHdpbGwgYXR0 ZW1wdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGFkamFjZW5jeSB0 YWJsZSB0aGF0IGNsYWltIHRvIGhhdmUgYSBkb21haW4sIGFuZCB3aWxsIGF0dGVtcHQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGJvb3RzdHJhcHBpbmcgdGhyb3Vn aCB0aGVtLCBvbmUgYnkgb25lLiAgT25lIHBvc3NpYmxlIHJlc3BvbnNlIGlzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYm9vdHN0cmFwcGluZyB0aHJvdWdoIHRo ZW0sIG9uZSBieSBvbmUuICBPbmUgcG9zc2libGUgcmVzcG9uc2UgaXM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGEgdmVuZG9yIE1BU0EgcmUtZGlyZWN0LCB3aGlj aCB3aWxsIGJlIGVudGVyZWQgaW50byB0aGUgYWRqYWNlbmN5PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgYSB2ZW5kb3IgTUFTQSByZS1kaXJlY3QsIHdoaWNoIHdp bGwgYmUgZW50ZXJlZCBpbnRvIHRoZSBhZGphY2VuY3k8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgIHRhYmxlIChzZWUgc2Vjb25kIGJ1bGxldCBhYm92ZSkuICBTZWU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0YWJsZSAoc2VlIHNlY29u ZCBidWxsZXQgYWJvdmUpLiAgU2VlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV0uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJh cHBpbmcta2V5aW5mcmFdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNiIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3Rk Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFy dC02Ij48ZW0+IHBhZ2UgMTEsIGxpbmUgNDk8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtNiI+PGVtPiBwYWdlIDExLCBsaW5lIDQ5 PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRodXMgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc20gY291bGQg ZWl0aGVyIGJlIGZ1bGx5IGludGVncmF0ZWQgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFRodXMgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc20gY291bGQgZWl0aGVy IGJlIGZ1bGx5IGludGVncmF0ZWQgd2l0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgYXV0b25vbWljIHNpZ25hbGluZyAobmV4dCBzZWN0aW9uKSBvciBjb3VsZCB1c2Ug YW4gaW5kZXBlbmRlbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdXRv bm9taWMgc2lnbmFsaW5nIChuZXh0IHNlY3Rpb24pIG9yIGNvdWxkIHVzZSBhbiBpbmRlcGVu ZGVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGlzY292ZXJ5IG1lY2hh bmlzbSBzdWNoIGFzIEROUyBTZXJ2aWNlIERpc2NvdmVyeSBvciBTZXJ2aWNlIExvY2F0aW9u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGlzY292ZXJ5IG1lY2hhbmlz bSBzdWNoIGFzIEROUyBTZXJ2aWNlIERpc2NvdmVyeSBvciBTZXJ2aWNlIExvY2F0aW9uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm90b2NvbC4gIFRoaXMgY2hvaWNl IGNvdWxkIGJlIG1hZGUgaW5kZXBlbmRlbnRseSBmb3IgZWFjaCBBdXRvbm9taWM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm90b2NvbC4gIFRoaXMgY2hvaWNlIGNv dWxkIGJlIG1hZGUgaW5kZXBlbmRlbnRseSBmb3IgZWFjaCBBdXRvbm9taWM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlcnZpY2UgQWdlbnQsIGFsdGhvdWdoIHRoZSBp bmZyYXN0cnVjdHVyZSBtaWdodCByZXF1aXJlIHNvbWUgbWluaW1hbDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNlcnZpY2UgQWdlbnQsIGFsdGhvdWdoIHRoZSBpbmZy YXN0cnVjdHVyZSBtaWdodCByZXF1aXJlIHNvbWUgbWluaW1hbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciAoZS5nLiwgZm9y IGRpc2NvdmVyaW5nIHRoZSBzZWN1cml0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IgKGUuZy4sIGZvciBkaXNjb3Zlcmlu ZyB0aGUgc2VjdXJpdHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJvb3Rz dHJhcCBtZWNoYW5pc20sIG9yIHRoZSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gZGlzdHJpYnV0 aW9uLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJvb3RzdHJhcCBtZWNo YW5pc20sIG9yIHRoZSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uLDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2VjdGlvbiA0LjcpLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNlY3Rpb24gNC43KS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGUgY3VycmVudGx5IHBy b3Bvc2VkIHByb3RvY29sPC9zcGFuPiBmb3IgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bm9kZSBk aXNjb3ZlcnkgaXMgR1JBU1AsPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5QaGFzZSAxIG9mIEF1dG9ub21pYyBOZXR3 b3JraW5nIHVzZXMgR1JBU1A8L3NwYW4+IGZvciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kaXNj b3ZlcnksPC9zcGFuPiBkZXNjcmliZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1hbmltYS1ncmFzcF0uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGluIFtJLUQuaWV0Zi1hbmltYS1ncmFzcF0uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuNC4gIFNpZ25hbGlu ZyBCZXR3ZWVuIEF1dG9ub21pYyBOb2RlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjQuNC4gIFNpZ25hbGluZyBCZXR3ZWVuIEF1dG9ub21pYyBOb2RlczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRvbm9taWMgbm9kZXMgbXVz dCBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIsIGZvciBleGFtcGxlIHRvPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXV0b25vbWljIG5vZGVzIG11c3QgY29tbXVu aWNhdGUgd2l0aCBlYWNoIG90aGVyLCBmb3IgZXhhbXBsZSB0bzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgbmVnb3RpYXRlIGFuZC9vciBzeW5jaHJvbml6ZSB0ZWNobmlj YWwgb2JqZWN0aXZlcyAoaS5lLiwgbmV0d29yazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG5lZ290aWF0ZSBhbmQvb3Igc3luY2hyb25pemUgdGVjaG5pY2FsIG9iamVj dGl2ZXMgKGkuZS4sIG5ldHdvcms8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHBhcmFtZXRlcnMpIG9mIGFueSBraW5kIGFuZCBjb21wbGV4aXR5LiAgVGhpcyByZXF1aXJl cyBzb21lIGZvcm0gb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwYXJh bWV0ZXJzKSBvZiBhbnkga2luZCBhbmQgY29tcGxleGl0eS4gIFRoaXMgcmVxdWlyZXMgc29t ZSBmb3JtIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzaWduYWxpbmcg YmV0d2VlbiBhdXRvbm9taWMgbm9kZXMuICBBdXRvbm9taWMgbm9kZXMgaW1wbGVtZW50aW5n IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzaWduYWxpbmcgYmV0d2Vl biBhdXRvbm9taWMgbm9kZXMuICBBdXRvbm9taWMgbm9kZXMgaW1wbGVtZW50aW5nIGE8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpZmljIHVzZSBjYXNlIG1pZ2h0 IGNob29zZSB0aGVpciBvd24gc2lnbmFsaW5nIHByb3RvY29sLCBhcyBsb25nPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWMgdXNlIGNhc2UgbWlnaHQgY2hv b3NlIHRoZWlyIG93biBzaWduYWxpbmcgcHJvdG9jb2wsIGFzIGxvbmc8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFzIGl0IGZpdHMgdGhlIG92ZXJhbGwgc2VjdXJpdHkg bW9kZWwuICBIb3dldmVyLCBpbiB0aGUgZ2VuZXJhbCBjYXNlLDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGFzIGl0IGZpdHMgdGhlIG92ZXJhbGwgc2VjdXJpdHkgbW9k ZWwuICBIb3dldmVyLCBpbiB0aGUgZ2VuZXJhbCBjYXNlLDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgYW55IHBhaXIgb2YgYXV0b25vbWljIG5vZGVzIG1pZ2h0IG5lZWQg dG8gY29tbXVuaWNhdGUsIHNvIHRoZXJlIG5lZWRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYW55IHBhaXIgb2YgYXV0b25vbWljIG5vZGVzIG1pZ2h0IG5lZWQgdG8g Y29tbXVuaWNhdGUsIHNvIHRoZXJlIG5lZWRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC03IiBjbGFzcz0iY2hhbmdl IiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxh IGhyZWY9IiNwYXJ0LTciPjxlbT4gcGFnZSAxMiwgbGluZSAyNTxzcGFuIGNsYXNzPSJoaWRl Ij4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC03Ij48ZW0+IHBhZ2Ug MTIsIGxpbmUgMjU8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGF1dG9ub21pYyBub2RlcyBjYW4gZGlzY292ZXIgZWFjaCBv dGhlciB3aXRob3V0IGFueSBwcmVjb25maWd1cmF0aW9uLDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGF1dG9ub21pYyBub2RlcyBjYW4gZGlzY292ZXIgZWFjaCBvdGhl ciB3aXRob3V0IGFueSBwcmVjb25maWd1cmF0aW9uLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYXMgbWVudGlvbmVkIGFib3ZlLiAgVG8gYmUgZ2VuZXJpYywgZGlzY292 ZXJ5IGFuZCBzaWduYWxpbmcgbXVzdCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGFzIG1lbnRpb25lZCBhYm92ZS4gIFRvIGJlIGdlbmVyaWMsIGRpc2NvdmVyeSBh bmQgc2lnbmFsaW5nIG11c3QgYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGFibGUgdG8gaGFuZGxlIGFueSBzb3J0IG9mIHRlY2huaWNhbCBvYmplY3RpdmUsIGluY2x1 ZGluZyBvbmVzIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhYmxl IHRvIGhhbmRsZSBhbnkgc29ydCBvZiB0ZWNobmljYWwgb2JqZWN0aXZlLCBpbmNsdWRpbmcg b25lcyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXF1aXJlIGNv bXBsZXggZGF0YSBzdHJ1Y3R1cmVzLiAgVGhlIGRvY3VtZW50ICJBIEdlbmVyaWMgQXV0b25v bWljPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVxdWlyZSBjb21wbGV4 IGRhdGEgc3RydWN0dXJlcy4gIFRoZSBkb2N1bWVudCAiQSBHZW5lcmljIEF1dG9ub21pYzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2lnbmFsaW5nIFByb3RvY29sIChH UkFTUCkiIFtJLUQuaWV0Zi1hbmltYS1ncmFzcF0gZGVzY3JpYmVzIG1vcmU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTaWduYWxpbmcgUHJvdG9jb2wgKEdSQVNQKSIg W0ktRC5pZXRmLWFuaW1hLWdyYXNwXSBkZXNjcmliZXMgbW9yZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIGZvciBkaXNjb3Zlcnks IG5lZ290aWF0aW9uIGFuZCBzeW5jaHJvbml6YXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBkZXRhaWxlZCByZXF1aXJlbWVudHMgZm9yIGRpc2NvdmVyeSwgbmVn b3RpYXRpb24gYW5kIHN5bmNocm9uaXphdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgaW4gYW4gYXV0b25vbWljIG5ldHdvcmsuICBJdCBhbHNvIGRlZmluZXMgYSBw cm90b2NvbCwgR1JBU1AsIGZvciB0aGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgaW4gYW4gYXV0b25vbWljIG5ldHdvcmsuICBJdCBhbHNvIGRlZmluZXMgYSBwcm90 b2NvbCwgR1JBU1AsIGZvciB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBwdXJwb3NlLCBpbmNsdWRpbmcgYW4gaW50ZWdyYXRlZCBidXQgb3B0aW9uYWwgZGlzY292 ZXJ5IHByb3RvY29sLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1cnBv c2UsIGluY2x1ZGluZyBhbiBpbnRlZ3JhdGVkIGJ1dCBvcHRpb25hbCBkaXNjb3ZlcnkgcHJv dG9jb2wuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEdS QVNQIGlzIG5vcm1hbGx5IGV4cGVjdGVkIHRvIHJ1biBpbnNpZGUgdGhlIEF1dG9ub21pYyBD b250cm9sIFBsYW5lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgR1JBU1Ag aXMgbm9ybWFsbHkgZXhwZWN0ZWQgdG8gcnVuIGluc2lkZSB0aGUgQXV0b25vbWljIENvbnRy b2wgUGxhbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMDkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgKEFDUDsgc2VlIFNlY3Rpb24gNC42KSBh bmQgdG8gZGVwZW5kIG9uIHRoZSBBQ1AgZm9yIHNlY3VyaXR5LiAgSXQgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+aXM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IChBQ1A7IHNlZSBTZWN0aW9uIDQuNikgYW5kIHRvIGRlcGVuZCBvbiB0aGUgQUNQIGZvciBz ZWN1cml0eS4gIEl0IG1heTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBhbHNvIGNhcGFibGUgb2YgdXNpbmcgVExTIHNlY3VyaXR5 IGluIHRoZSBhYnNlbmNlIG9mIGFuIEFDUCwgYW5kIGl0PC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBydW4gaW5zZWN1cmVseSBmb3IgYSBzaG9ydCB0aW1l IGR1cmluZyBib290c3RyYXBwaW5nLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBtYXkgcnVuIGluc2VjdXJlbHkgZm9yIGEgc2hvcnQgdGltZSBkdXJpbmcgYm9vdHN0 cmFwcGluZy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFuIGF1dG9ub21pYyBub2RlIHdp bGwgbm9ybWFsbHkgcnVuIGEgc2luZ2xlIGluc3RhbmNlIG9mIEdSQVNQLCB1c2VkPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQW4gYXV0b25vbWljIG5vZGUgd2lsbCBu b3JtYWxseSBydW4gYSBzaW5nbGUgaW5zdGFuY2Ugb2YgR1JBU1AsIHVzZWQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJ5IG11bHRpcGxlIEFTQXMuICBIb3dldmVyLCBz Y2VuYXJpb3Mgd2hlcmUgbXVsdGlwbGUgaW5zdGFuY2VzIG9mPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgYnkgbXVsdGlwbGUgQVNBcy4gIEhvd2V2ZXIsIHNjZW5hcmlv cyB3aGVyZSBtdWx0aXBsZSBpbnN0YW5jZXMgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEdSQVNQIHJ1biBpbiBhIHNpbmdsZSBub2RlLCBwZXJoYXBzIHdpdGggZGlm ZmVyZW50IHNlY3VyaXR5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgR1JB U1AgcnVuIGluIGEgc2luZ2xlIG5vZGUsIHBlcmhhcHMgd2l0aCBkaWZmZXJlbnQgc2VjdXJp dHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3BlcnRpZXMsIGFyZSBu b3QgZXhjbHVkZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvcGVy dGllcywgYXJlIG5vdCBleGNsdWRlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+NC41LiAgUm91dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjQuNS4gIFJvdXRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgQWxsIGF1dG9ub21pYyBub2RlcyBpbiBhIGRvbWFpbiBtdXN0IGJlIGFibGUg dG8gY29tbXVuaWNhdGUgd2l0aCBlYWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgQWxsIGF1dG9ub21pYyBub2RlcyBpbiBhIGRvbWFpbiBtdXN0IGJlIGFibGUgdG8g Y29tbXVuaWNhdGUgd2l0aCBlYWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvdGhlciwgYW5kIHdpdGggYXV0b25vbWljIG5vZGVzIG91dHNpZGUgdGhlaXIgb3duIGRv bWFpbi4gIFRoZXJlZm9yZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBv dGhlciwgYW5kIHdpdGggYXV0b25vbWljIG5vZGVzIG91dHNpZGUgdGhlaXIgb3duIGRvbWFp bi4gIFRoZXJlZm9yZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTgiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48 dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQt OCI+PGVtPiBwYWdlIDEzLCBsaW5lIDE5PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3Nw YW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTgiPjxlbT4gcGFnZSAxMywgbGluZSAxOTxz cGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgYSBmdW5jdGlvbiBvZiB0aGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUuICBPbmUg Zm9ybSBvZiBzdWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYSBmdW5j dGlvbiBvZiB0aGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUuICBPbmUgZm9ybSBvZiBzdWNo PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmZvcm1hdGlvbiBpcyBJbnRl bnQuICBJbnRlbnQgaXMgdGhlIHBvbGljeSBsYW5ndWFnZSBvZiBhbiBBdXRvbm9taWM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmZvcm1hdGlvbiBpcyBJbnRlbnQu ICBJbnRlbnQgaXMgdGhlIHBvbGljeSBsYW5ndWFnZSBvZiBhbiBBdXRvbm9taWM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5ldHdvcms7IHNlZSBTZWN0aW9uIDcuMiBm b3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiBvbiBJbnRlbnQuICBJdCBpcyBhPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTmV0d29yazsgc2VlIFNlY3Rpb24gNy4yIGZvciBn ZW5lcmFsIGluZm9ybWF0aW9uIG9uIEludGVudC4gIEl0IGlzIGE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGhpZ2ggbGV2ZWwgcG9saWN5LCBhbmQgc2hvdWxkIGNoYW5n ZSBvbmx5IGluZnJlcXVlbnRseSAob3JkZXIgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBoaWdoIGxldmVsIHBvbGljeSwgYW5kIHNob3VsZCBjaGFuZ2Ugb25seSBp bmZyZXF1ZW50bHkgKG9yZGVyIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBkYXlzKS4gIFRoZXJlZm9yZSwgaW5mb3JtYXRpb24gc3VjaCBhcyBJbnRlbnQgc2hvdWxk IGJlIHNpbXBseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRheXMpLiAg VGhlcmVmb3JlLCBpbmZvcm1hdGlvbiBzdWNoIGFzIEludGVudCBzaG91bGQgYmUgc2ltcGx5 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmbG9vZGVkIHRvIGFsbCBub2Rl cyBpbiBhbiBhdXRvbm9taWMgZG9tYWluLCBhbmQgdGhlcmUgaXMgY3VycmVudGx5PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmxvb2RlZCB0byBhbGwgbm9kZXMgaW4g YW4gYXV0b25vbWljIGRvbWFpbiwgYW5kIHRoZXJlIGlzIGN1cnJlbnRseTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm8gcGVyY2VpdmVkIG5lZWQgdG8gaGF2ZSBtb3Jl IHRhcmdldGVkIGRpc3RyaWJ1dGlvbiBtZXRob2RzLiAgSW50ZW50PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbm8gcGVyY2VpdmVkIG5lZWQgdG8gaGF2ZSBtb3JlIHRh cmdldGVkIGRpc3RyaWJ1dGlvbiBtZXRob2RzLiAgSW50ZW50PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBpcyBhbHNvIGV4cGVjdGVkIHRvIGJlIG1vbm9saXRoaWMsIGFu ZCBmbG9vZGVkIGFzIGEgd2hvbGUuICBPbmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBpcyBhbHNvIGV4cGVjdGVkIHRvIGJlIG1vbm9saXRoaWMsIGFuZCBmbG9vZGVk IGFzIGEgd2hvbGUuICBPbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBv c3NpYmxlIG1ldGhvZCBmb3IgZGlzdHJpYnV0aW5nIEludGVudCwgYXMgd2VsbCBhcyBvdGhl ciBmb3JtcyBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBvc3NpYmxl IG1ldGhvZCBmb3IgZGlzdHJpYnV0aW5nIEludGVudCwgYXMgd2VsbCBhcyBvdGhlciBmb3Jt cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGF0YSwgaXMgZGlzY3Vz c2VkIGluIFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl0uICBJbnRlbnQgYW5k PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGF0YSwgaXMgZGlzY3Vzc2Vk IGluIFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl0uICBJbnRlbnQgYW5kPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEw Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbiBhcmUgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+Y3VycmVudGx5IG91dCBvZiBzY29wZSBmb3I8L3NwYW4+IEFOSU1B LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbmZvcm1hdGlvbiBkaXN0 cmlidXRpb24gYXJlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm5vdCBwYXJ0IG9mIHBoYXNlIDEg b2Y8L3NwYW4+IEFOSU1BLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij41LiAgU2VjdXJpdHkgYW5kIFRydXN0IEluZnJhc3RydWN0dXJlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+NS4gIFNlY3VyaXR5IGFuZCBUcnVzdCBJbmZyYXN0cnVj dHVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBbiBB dXRvbm9taWMgTmV0d29yayBpcyBzZWxmLXByb3RlY3RpbmcuICBBbGwgcHJvdG9jb2xzIGFy ZSBzZWN1cmUgYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBbiBBdXRv bm9taWMgTmV0d29yayBpcyBzZWxmLXByb3RlY3RpbmcuICBBbGwgcHJvdG9jb2xzIGFyZSBz ZWN1cmUgYnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlZmF1bHQsIHdp dGhvdXQgdGhlIHJlcXVpcmVtZW50IGZvciB0aGUgYWRtaW5pc3RyYXRvciB0byBleHBsaWNp dGx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVmYXVsdCwgd2l0aG91 dCB0aGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGV4cGxpY2l0bHk8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbmZpZ3VyZSBzZWN1cml0eS48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb25maWd1cmUgc2VjdXJpdHku PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1dG9ub21p YyBub2RlcyBoYXZlIGRpcmVjdCBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVtc2VsdmVzLCB3 aGljaDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dG9ub21pYyBub2Rl cyBoYXZlIGRpcmVjdCBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVtc2VsdmVzLCB3aGljaDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbXVzdCBiZSBzZWN1cmVkLiAgU2lu Y2UgYW4gYXV0b25vbWljIG5ldHdvcmsgZG9lcyBub3QgcmVseSBvbjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG11c3QgYmUgc2VjdXJlZC4gIFNpbmNlIGFuIGF1dG9u b21pYyBuZXR3b3JrIGRvZXMgbm90IHJlbHkgb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGNvbmZpZ3VyYXRpb24sIGl0IGlzIG5vdCBhbiBvcHRpb24gdG8gY29uZmln dXJlIGZvciBleGFtcGxlIHByZS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBjb25maWd1cmF0aW9uLCBpdCBpcyBub3QgYW4gb3B0aW9uIHRvIGNvbmZpZ3VyZSBmb3Ig ZXhhbXBsZSBwcmUtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC05IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRo PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTki PjxlbT4gcGFnZSAxNCwgbGluZSAzMjxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFu PjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC05Ij48ZW0+IHBhZ2UgMTQsIGxpbmUgMzI8c3Bh biBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtJLUQuaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhXS48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGlu Zy1rZXlpbmZyYV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjUuNC4gIFN1Yi1Eb21haW5zICgqKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjUuNC4gIFN1Yi1Eb21haW5zICgqKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBCeSBkZWZhdWx0LCBzdWItZG9tYWlucyBhcmUgdHJlYXRlZCBhcyBk aWZmZXJlbnQgZG9tYWlucy4gIFRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBCeSBkZWZhdWx0LCBzdWItZG9tYWlucyBhcmUgdHJlYXRlZCBhcyBkaWZmZXJlbnQg ZG9tYWlucy4gIFRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGltcGxp ZXMgbm8gdHJ1c3QgYmV0d2VlbiBhIGRvbWFpbiBhbmQgaXRzIHN1Yi1kb21haW5zLCBhbmQg bm8gdHJ1c3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbXBsaWVzIG5v IHRydXN0IGJldHdlZW4gYSBkb21haW4gYW5kIGl0cyBzdWItZG9tYWlucywgYW5kIG5vIHRy dXN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZXR3ZWVuIHN1Yi1kb21h aW5zIG9mIHRoZSBzYW1lIGRvbWFpbi4gIFNwZWNpZmljYWxseSwgbm8gQUNQIGlzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmV0d2VlbiBzdWItZG9tYWlucyBvZiB0 aGUgc2FtZSBkb21haW4uICBTcGVjaWZpY2FsbHksIG5vIEFDUCBpczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgYnVpbHQsIGFuZCBJbnRlbnQgaXMgdmFsaWQgb25seSBm b3IgdGhlIGRvbWFpbiBpdCBpcyBkZWZpbmVkIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGJ1aWx0LCBhbmQgSW50ZW50IGlzIHZhbGlkIG9ubHkgZm9yIHRoZSBk b21haW4gaXQgaXMgZGVmaW5lZCBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGV4cGxpY2l0bHkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhw bGljaXRseS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAxMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJbiA8c3BhbiBjbGFz cz0iZGVsZXRlIj50aGUgZnV0dXJlLDwvc3Bhbj4gYWx0ZXJuYXRpdmUgdHJ1c3QgbW9kZWxz IDxzcGFuIGNsYXNzPSJkZWxldGUiPmNhbjwvc3Bhbj4gYmUgZGVmaW5lZCwgZm9yIGV4YW1w bGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgSW4gPHNwYW4gY2xhc3M9 Imluc2VydCI+cGhhc2UgMiBvZiBBTklNQSw8L3NwYW4+IGFsdGVybmF0aXZlIHRydXN0IG1v ZGVscyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zaG91bGQ8L3NwYW4+IGJlIGRlZmluZWQsIGZv cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0byBhbGxvdyBmdWxsIG9y IGxpbWl0ZWQgdHJ1c3QgYmV0d2VlbiBkb21haW4gYW5kIHN1Yi1kb21haW4uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGV4YW1wbGUgdG8gYWxsb3cgZnVsbCBvciBs aW1pdGVkIHRydXN0IGJldHdlZW4gZG9tYWluIGFuZCBzdWItZG9tYWluLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LjUuICBDcm9zcy1Eb21haW4gRnVu Y3Rpb25hbGl0eSAoKik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij41LjUuICBD cm9zcy1Eb21haW4gRnVuY3Rpb25hbGl0eSAoKik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgQnkgZGVmYXVsdCwgZGlmZmVyZW50IGRvbWFpbnMgZG8g bm90IGludGVyb3BlcmF0ZSwgbm8gQUNQIGlzIGJ1aWx0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgQnkgZGVmYXVsdCwgZGlmZmVyZW50IGRvbWFpbnMgZG8gbm90IGlu dGVyb3BlcmF0ZSwgbm8gQUNQIGlzIGJ1aWx0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbmQgbm8gdHJ1c3QgaXMgaW1wbGllZCBiZXR3ZWVuIHRoZW0uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5kIG5vIHRydXN0IGlzIGltcGxpZWQgYmV0 d2VlbiB0aGVtLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBJbiB0aGUgZnV0dXJlLCBtb2RlbHMgY2FuIGJlIGVzdGFibGlzaGVkIHdoZXJlIG90aGVy IGRvbWFpbnMgY2FuIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4g dGhlIGZ1dHVyZSwgbW9kZWxzIGNhbiBiZSBlc3RhYmxpc2hlZCB3aGVyZSBvdGhlciBkb21h aW5zIGNhbiBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJ1c3RlZCBp biBmdWxsIG9yIGZvciBsaW1pdGVkIG9wZXJhdGlvbnMgYmV0d2VlbiB0aGUgZG9tYWlucy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0cnVzdGVkIGluIGZ1bGwgb3Ig Zm9yIGxpbWl0ZWQgb3BlcmF0aW9ucyBiZXR3ZWVuIHRoZSBkb21haW5zLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAgQXV0b25vbWljIFNlcnZpY2Ug QWdlbnRzIChBU0EpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4gIEF1dG9u b21pYyBTZXJ2aWNlIEFnZW50cyAoQVNBKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMTAiIGNsYXNzPSJjaGFuZ2Ui ID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEg aHJlZj0iI3BhcnQtMTAiPjxlbT4gcGFnZSAxOSwgbGluZSA3PHNwYW4gY2xhc3M9ImhpZGUi PiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTEwIj48ZW0+IHBhZ2Ug MTksIGxpbmUgNzxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwv dGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgYWNoaWV2ZWQgaW4gYXV0b25vbWljIG1hbmFnZW1lbnQgdGhy b3VnaCBwcmlvcml0aXphdGlvbiBbUkZDNzU3NV0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYWNoaWV2ZWQgaW4gYXV0b25vbWljIG1hbmFnZW1lbnQgdGhyb3VnaCBw cmlvcml0aXphdGlvbiBbUkZDNzU3NV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGUgcmF0aW9uYWxlIGlzIHRoYXQgbWFudWFsIGFuZCBub2RlLWJhc2VkIG1hbmFn ZW1lbnQgaGF2ZSBhIGhpZ2hlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoZSByYXRpb25hbGUgaXMgdGhhdCBtYW51YWwgYW5kIG5vZGUtYmFzZWQgbWFuYWdlbWVu dCBoYXZlIGEgaGlnaGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcmlv cml0eSBvdmVyIGF1dG9ub21pYyBtYW5hZ2VtZW50LiAgVGh1cywgdGhlIGF1dG9ub21pYyBk ZWZhdWx0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJpb3JpdHkgb3Zl ciBhdXRvbm9taWMgbWFuYWdlbWVudC4gIFRodXMsIHRoZSBhdXRvbm9taWMgZGVmYXVsdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmVoYXZpb3IgaGFzIHRoZSBsb3dl c3QgcHJpb3JpdHksIHRoZW4gY29tZXMgdGhlIGF1dG9ub21pYyBJbnRlbnQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBiZWhhdmlvciBoYXMgdGhlIGxvd2VzdCBwcmlv cml0eSwgdGhlbiBjb21lcyB0aGUgYXV0b25vbWljIEludGVudDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgKG1lZGl1bSBwcmlvcml0eSksIGFuZCwgZmluYWxseSwgdGhl IGhpZ2hlc3QgcHJpb3JpdHkgaXMgdGFrZW4gYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAobWVkaXVtIHByaW9yaXR5KSwgYW5kLCBmaW5hbGx5LCB0aGUgaGlnaGVz dCBwcmlvcml0eSBpcyB0YWtlbiBieTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgbm9kZS1zcGVjaWZpYyBuZXR3b3JrIG1hbmFnZW1lbnQgbWV0aG9kcywgc3VjaCBhcyB0 aGUgdXNlIG9mIGNvbW1hbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBu b2RlLXNwZWNpZmljIG5ldHdvcmsgbWFuYWdlbWVudCBtZXRob2RzLCBzdWNoIGFzIHRoZSB1 c2Ugb2YgY29tbWFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbGluZSBp bnRlcmZhY2VzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxpbmUgaW50 ZXJmYWNlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ny4y LiAgSW50ZW50ICgqKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjcuMi4gIElu dGVudCAoKik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAxMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJbnRlbnQgaXMgbm90 IGNvdmVyZWQgYnkgdGhlIEFOSU1BIGNoYXJ0ZXIgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YXM8 L3NwYW4+IG9mIDxzcGFuIGNsYXNzPSJkZWxldGUiPk1hcmNoIDIwMTcuPC9zcGFuPiAgVGhp czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJbnRlbnQgaXMgbm90IGNv dmVyZWQgYnkgdGhlIEFOSU1BIGNoYXJ0ZXIgPHNwYW4gY2xhc3M9Imluc2VydCI+YXQgdGhl IHRpbWU8L3NwYW4+IG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoaXM8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHNlY3Rpb24gaXMgZm9yIGluZm9ybWF0 aW9uYWwgcHVycG9zZXMgb25seS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgd3JpdGluZy48L3NwYW4+ICBUaGlzIHNlY3Rpb24g aXMgZm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMgb25seS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGdpdmVzIGFuIG92ZXJ2 aWV3IG9mIEludGVudCwgYW5kIGhvdyBpdCBpcyBtYW5hZ2VkLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgc2VjdGlvbiBnaXZlcyBhbiBvdmVydmlldyBvZiBJ bnRlbnQsIGFuZCBob3cgaXQgaXMgbWFuYWdlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEludGVudCBhbmQgUG9saWN5LUJhc2VkIE5ldHdvcmsgTWFuYWdlbWVudCAo UEJOTSkgaXMgYWxyZWFkeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElu dGVudCBhbmQgUG9saWN5LUJhc2VkIE5ldHdvcmsgTWFuYWdlbWVudCAoUEJOTSkgaXMgYWxy ZWFkeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVzY3JpYmVkIGluc2lk ZSB0aGUgSUVURiAoZS5nLiwgUENJTSBhbmQgU1VQQSkgYW5kIGluIG90aGVyIFNET3M8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQgaW5zaWRlIHRoZSBJ RVRGIChlLmcuLCBQQ0lNIGFuZCBTVVBBKSBhbmQgaW4gb3RoZXIgU0RPczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGUuZy4sIERNVEYgYW5kIFRNRiBaT09NKS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoZS5nLiwgRE1URiBhbmQgVE1GIFpP T00pLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRl bnQgY2FuIGJlIGRlc2NyaWJlZCBhcyBhbiBhYnN0cmFjdCwgZGVjbGFyYXRpdmUsIGhpZ2gt bGV2ZWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlbnQgY2FuIGJl IGRlc2NyaWJlZCBhcyBhbiBhYnN0cmFjdCwgZGVjbGFyYXRpdmUsIGhpZ2gtbGV2ZWw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBvbGljeSB1c2VkIHRvIG9wZXJhdGUg YW4gYXV0b25vbWljIGRvbWFpbiwgc3VjaCBhcyBhbiBlbnRlcnByaXNlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcG9saWN5IHVzZWQgdG8gb3BlcmF0ZSBhbiBhdXRv bm9taWMgZG9tYWluLCBzdWNoIGFzIGFuIGVudGVycHJpc2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG5ldHdvcmsgW1JGQzc1NzVdLiAgSW50ZW50IHNob3VsZCBiZSBs aW1pdGVkIHRvIGhpZ2ggbGV2ZWwgZ3VpZGFuY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBuZXR3b3JrIFtSRkM3NTc1XS4gIEludGVudCBzaG91bGQgYmUgbGltaXRl ZCB0byBoaWdoIGxldmVsIGd1aWRhbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBvbmx5LCB0aHVzIGl0IGRvZXMgbm90IGRpcmVjdGx5IGRlZmluZSBhIHBvbGljeSBm b3IgZXZlcnkgbmV0d29yazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9u bHksIHRodXMgaXQgZG9lcyBub3QgZGlyZWN0bHkgZGVmaW5lIGEgcG9saWN5IGZvciBldmVy eSBuZXR3b3JrPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0icGFydC0xMSIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0xMSI+ PGVtPiBwYWdlIDE5LCBsaW5lIDQwPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+ PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTExIj48ZW0+IHBhZ2UgMTksIGxpbmUgNDA8c3Bh biBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGFyZSB1c3VhbGx5IHByb3ZpZGVkIGJ5IHRoZSBodW1hbiBvcGVyYXRvci4gIFNvbWUg b2YgdGhlc2UgcGFyYW1ldGVyczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGFyZSB1c3VhbGx5IHByb3ZpZGVkIGJ5IHRoZSBodW1hbiBvcGVyYXRvci4gIFNvbWUgb2Yg dGhlc2UgcGFyYW1ldGVyczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2Fu IGluZmx1ZW5jZSB0aGUgYmVoYXZpb3Igb2Ygc3BlY2lmaWMgYXV0b25vbWljIGZ1bmN0aW9u cyBhcyB3ZWxsIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FuIGlu Zmx1ZW5jZSB0aGUgYmVoYXZpb3Igb2Ygc3BlY2lmaWMgYXV0b25vbWljIGZ1bmN0aW9ucyBh cyB3ZWxsIGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgd2F5IHRo ZSBJbnRlbnQgaXMgdXNlZCB0byBtYW5hZ2UgdGhlIGF1dG9ub21pYyBkb21haW4uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHdheSB0aGUgSW50ZW50IGlzIHVz ZWQgdG8gbWFuYWdlIHRoZSBhdXRvbm9taWMgZG9tYWluLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlbnQgaXMgZGlzY3Vzc2VkIGluIG1vcmUg ZGV0YWlsIGluIFtJLUQuZHUtYW5pbWEtYW4taW50ZW50XS48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBJbnRlbnQgaXMgZGlzY3Vzc2VkIGluIG1vcmUgZGV0YWlsIGlu IFtJLUQuZHUtYW5pbWEtYW4taW50ZW50XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEludGVudCBhcyB3ZWxsIGFzIG90aGVyIHR5cGVzIG9mIGluZm9ybWF0aW9uIGFy ZSBkaXN0cmlidXRlZCB2aWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJ bnRlbnQgYXMgd2VsbCBhcyBvdGhlciB0eXBlcyBvZiBpbmZvcm1hdGlvbiBhcmUgZGlzdHJp YnV0ZWQgdmlhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBHUkFTUCwgc2Vl IFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl0uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgR1JBU1AsIHNlZSBbSS1ELmxpdS1hbmltYS1ncmFzcC1kaXN0 cmlidXRpb25dLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij43 LjMuICBBZ2dyZWdhdGVkIFJlcG9ydGluZyAoKik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij43LjMuICBBZ2dyZWdhdGVkIFJlcG9ydGluZyAoKik8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMyI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Bczwvc3Bhbj4gb2YgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+TWFyY2ggMjAxNyw8L3NwYW4+IGFnZ3JlZ2F0ZWQgcmVwb3J0 aW5nIGlzIG5vdCBpbiB0aGUgQU5JTUEgY2hhcnRlci48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+QXQgdGhlIHRpbWU8L3NwYW4+ IG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoaXMgd3JpdGluZyw8L3NwYW4+IGFnZ3JlZ2F0 ZWQgcmVwb3J0aW5nIGlzIG5vdCBpbiB0aGUgQU5JTUE8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgVGhpcyBzZWN0aW9uIGlzIHByb3ZpZGVkIGZvciBpbmZvcm1hdGlv biBvbmx5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBjaGFydGVyLiAg VGhpcyBzZWN0aW9uIGlzIHByb3ZpZGVkIGZvciBpbmZvcm1hdGlvbiBvbmx5LjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRvbm9taWMgTmV0d29y ayBzaG91bGQgbWluaW1pemUgdGhlIG5lZWQgZm9yIGh1bWFuIGludGVydmVudGlvbi48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRvbm9taWMgTmV0d29yayBzaG91 bGQgbWluaW1pemUgdGhlIG5lZWQgZm9yIGh1bWFuIGludGVydmVudGlvbi48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluIHRlcm1zIG9mIGhvdyB0aGUgbmV0d29yayBz aG91bGQgYmVoYXZlLCB0aGlzIGlzIGRvbmUgdGhyb3VnaCBhbjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIEluIHRlcm1zIG9mIGhvdyB0aGUgbmV0d29yayBzaG91bGQg YmVoYXZlLCB0aGlzIGlzIGRvbmUgdGhyb3VnaCBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYXV0b25vbWljIEludGVudCBwcm92aWRlZCBieSB0aGUgaHVtYW4gYWRt aW5pc3RyYXRvci4gIEluIGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg YXV0b25vbWljIEludGVudCBwcm92aWRlZCBieSB0aGUgaHVtYW4gYWRtaW5pc3RyYXRvci4g IEluIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmFsb2dvdXMgbWFu bmVyLCB0aGUgcmVwb3J0cyB3aGljaCBkZXNjcmliZSB0aGUgb3BlcmF0aW9uYWwgc3RhdHVz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5hbG9nb3VzIG1hbm5lciwg dGhlIHJlcG9ydHMgd2hpY2ggZGVzY3JpYmUgdGhlIG9wZXJhdGlvbmFsIHN0YXR1czwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIG5ldHdvcmsgc2hvdWxkIGFn Z3JlZ2F0ZSB0aGUgaW5mb3JtYXRpb24gcHJvZHVjZWQgaW4gZGlmZmVyZW50PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgdGhlIG5ldHdvcmsgc2hvdWxkIGFnZ3Jl Z2F0ZSB0aGUgaW5mb3JtYXRpb24gcHJvZHVjZWQgaW4gZGlmZmVyZW50PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBuZXR3b3JrIGVsZW1lbnRzIGluIG9yZGVyIHRvIHBy ZXNlbnQgdGhlIGVmZmVjdGl2ZW5lc3Mgb2YgYXV0b25vbWljPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgbmV0d29yayBlbGVtZW50cyBpbiBvcmRlciB0byBwcmVzZW50 IHRoZSBlZmZlY3RpdmVuZXNzIG9mIGF1dG9ub21pYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgSW50ZW50IGVuZm9yY2VtZW50LiAgVGhlcmVmb3JlLCByZXBvcnRpbmcg aW4gYW4gYXV0b25vbWljIG5ldHdvcms8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJbnRlbnQgZW5mb3JjZW1lbnQuICBUaGVyZWZvcmUsIHJlcG9ydGluZyBpbiBhbiBh dXRvbm9taWMgbmV0d29yazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2hv dWxkIGhhcHBlbiBvbiBhIG5ldHdvcmstd2lkZSBiYXNpcyBbUkZDNzU3NV0uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2hvdWxkIGhhcHBlbiBvbiBhIG5ldHdvcmst d2lkZSBiYXNpcyBbUkZDNzU3NV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTEyIiBjbGFzcz0i Y2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxhIGhyZWY9IiNwYXJ0LTEyIj48ZW0+IHBhZ2UgMjQsIGxpbmUgMTA8c3BhbiBjbGFz cz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMTIiPjxl bT4gcGFnZSAyNCwgbGluZSAxMDxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwv ZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgaW50ZXJhY3Rpb24gbWFwcykuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgaW50ZXJhY3Rpb24gbWFwcykuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEEgY29tbW9u ICJjb250cm9sL2NvbW1hbmQiIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBjb29yZGluYXRpb248 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBBIGNvbW1vbiAiY29udHJv bC9jb21tYW5kIiBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgY29vcmRpbmF0aW9uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAiYWdlbnQiIGFuZCB0aGUgYXV0b25vbWlj IGZ1bmN0aW9ucy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAiYWdl bnQiIGFuZCB0aGUgYXV0b25vbWljIGZ1bmN0aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgR3VpZGVsaW5lcywgcmVjb21tZW5kYXRpb25zIG9y IEJDUHMgY2FuIGFsc28gYmUgcHJvdmlkZWQgZm9yIGFzcGVjdHM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBHdWlkZWxpbmVzLCByZWNvbW1lbmRhdGlvbnMgb3IgQkNQ cyBjYW4gYWxzbyBiZSBwcm92aWRlZCBmb3IgYXNwZWN0czwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgcGVydGFpbmluZyB0byB0aGUgY29vcmRpbmF0aW9uIHN0cmF0ZWdp ZXMgYW5kIG1lY2hhbmlzbXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg cGVydGFpbmluZyB0byB0aGUgY29vcmRpbmF0aW9uIHN0cmF0ZWdpZXMgYW5kIG1lY2hhbmlz bXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjkuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjku ICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE0Ij48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjkuMS4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRocmVhdCBBbmFseXNpczwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+OS4xLiAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+Q29uc2VxdWVuY2VzIG9mIGEgRGlzdHJpYnV0ZWQgU3lzdGVtPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDE1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRoaXMgaXMg YSBwcmVsaW1pbmFyeSBvdXRsaW5lPC9zcGFuPiBvZiBhIDxzcGFuIGNsYXNzPSJkZWxldGUi PnRocmVhdCBhbmFseXNpcywgdG8gYmUgZXhwYW5kZWQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkFuIGF1dG9ub21p YyBuZXR3b3JrIGNvbnNpc3RzPC9zcGFuPiBvZiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hdXRv bm9taWMgZGV2aWNlcyB0aGF0IGZvcm0gYTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPm1hZGUgbW9yZSBzcGVj aWZpYyBhczwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPnZhcmlvdXMgQXV0b25v bWljIE5ldHdvcmtpbmc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGRpc3RyaWJ1dGVkIHNlbGYtbWFuYWdpbmcgc3lz dGVtLiAgRGV2aWNlcyB3aXRoaW4gYSBkb21haW4gc2hhcmU8L3NwYW4+IGE8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgc3BlY2lm aWNhdGlvbnMgZXZvbHZlLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Y29tbW9uIHRydXN0IGFuY2hvcjwvc3Bhbj4g YW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRodXMgaW1wbGljaXRseSB0cnVzdCBlYWNoIG90 aGVyLiAgVGhpcyBtZWFuczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIHRoYXQgYW55IGRldmljZSBpbnNpZGUgYSB0cnVzdCBkb21haW4gY2FuIGJ5IGRl ZmF1bHQgdXNlIGFsbDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIGRpc3RyaWJ1dGVkIGZ1bmN0aW9ucyBpbjwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJp bnNlcnQiPmVudGlyZSBhdXRvbm9taWMgZG9tYWluIGluIGEgbWFsaWNpb3VzPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgd2F5Ljwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAxNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5TaW5jZSBB TiB3aWxsIGhhbmQgb3ZlciByZXNwb25zaWJpbGl0eSBmb3IgbmV0d29yayBjb25maWd1cmF0 aW9uIGZyb208L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxz cGFuIGNsYXNzPSJpbnNlcnQiPkFuIG91dHNpZGUgYXR0YWNrZXIgaGFzPC9zcGFuPiB0aGUg PHNwYW4gY2xhc3M9Imluc2VydCI+Zm9sbG93aW5nIGdlbmVyaWMgd2F5czwvc3Bhbj4gdG8g PHNwYW4gY2xhc3M9Imluc2VydCI+dGFrZSBjb250cm9sPC9zcGFuPiBvZjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBodW1hbnMg b3IgY2VudHJhbGx5IGVzdGFibGlzaGVkIG1hbmFnZW1lbnQgc3lzdGVtcyB0byBmdWxseTwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9 Imluc2VydCI+YW48L3NwYW4+IGF1dG9ub21pYyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5uZXR3 b3JrOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+ICAgZGlzdHJpYnV0ZWQgZGV2aWNlcywgdGhlIHRocmVhdCBlbnZpcm9u bWVudCBpcyBhbHNvIGZ1bGx5PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgZGlzdHJpYnV0ZWQuICBPbjwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJkZWxl dGUiPm9uZSBoYW5kLCB0aGF0IG1lYW5zIHRoZXJlIGlzIG5vIHNpbmdsZSBwb2ludCBvZjwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGZhaWx1cmU8L3Nw YW4+IHRvIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFjdCBhcyBhbiBhdHRyYWN0aXZlIHRhcmdl dCBmb3IgYmFkIGFjdG9ycy4gIE9uIHRoZSBvdGhlcjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxz cGFuIGNsYXNzPSJkZWxldGUiPiAgIGhhbmQsIGl0IG1lYW5zIHRoYXQgcG90ZW50aWFsbHkg YSBzaW5nbGUgbWlzYmVoYXZpbmcgYXV0b25vbWljIGRldmljZTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGNvdWxkIGxhdW5jaCBhIHdpZGVzcHJlYWQg YXR0YWNrLCBieSBtaXN1c2luZyB0aGUgZGlzdHJpYnV0ZWQgQU48L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBtZWNoYW5pc21zLiAgRm9yIGV4YW1wbGUs IGEgcmVzb3VyY2UgZXhoYXVzdGlvbiBhdHRhY2sgY291bGQgYmU8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBsYXVuY2hlZCBieSBhIHNpbmdsZSBkZXZp Y2UgcmVxdWVzdGluZyBsYXJnZSBhbW91bnRzPC9zcGFuPiBvZiA8c3BhbiBjbGFzcz0iZGVs ZXRlIj50aGF0IHJlc291cmNlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgZnJvbSBhbGwgaXRzIHBlZXJzLCBvbiBiZWhhbGYgb2YgYSBub24tZXhpc3Rl bnQgdHJhZmZpYyBsb2FkLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIEFsdGVybmF0aXZlbHkgaXQgY291bGQgc2ltcGx5IHNlbmQgZmFsc2UgaW5mb3Jt YXRpb24gdG8gaXRzIHBlZXJzLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgIGZvciBleGFtcGxlIGJ5IGFubm91bmNpbmcgcmVzb3VyY2UgZXhoYXVzdGlv biB3aGVuIHRoaXMgd2FzIG5vdCB0aGU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj4gICBjYXNlLiAgSWYgc2VjdXJpdHkgcHJvcGVydGllcyBhcmUgbWFuYWdl ZCBhdXRvbm9taWNhbGx5LCBhPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgbWlzYmVoYXZpbmcgZGV2aWNlIGNvdWxkIGF0dGVtcHQgYSBkaXN0cmlidXRl ZCBhdHRhY2sgYnkgcmVxdWVzdGluZzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgIGFsbCBpdHMgcGVlcnMgdG8gcmVkdWNlIHNlY3VyaXR5IHByb3RlY3Rp b25zIGluIHNvbWUgd2F5LiAgSW48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICBnZW5lcmFsLCBzaW5jZTwvc3Bhbj4gYXV0b25vbWljIDxzcGFuIGNsYXNz PSJkZWxldGUiPmRldmljZXMgcnVuIHdpdGhvdXQgc3VwZXJ2aXNpb24sIGFsbW9zdCBhbnk8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBraW5kIG9mIHVu ZGVzaXJhYmxlIG1hbmFnZW1lbnQgYWN0aW9uIGNvdWxkIGluIHRoZW9yeSBiZSBhdHRlbXB0 ZWQgYnk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBhIG1p c2JlaGF2aW5nIGRldmljZS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDE3Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxl dGUiPklmIGl0IGlzIHBvc3NpYmxlIGZvciBhbiB1bmF1dGhvcmlzZWQgZGV2aWNlIHRvIGFj dCBhcyBhbiBhdXRvbm9taWM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm8gIEludHJvZHVjaW5nPC9zcGFuPiBhIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmZha2UgZGV2aWNlIGludG8gdGhlIHRydXN0IGRvbWFpbiwg Ynkgc3VidmVydGluZyB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGRldmljZSwgb3IgZm9yPC9zcGFuPiBhIDxz cGFuIGNsYXNzPSJkZWxldGUiPm1hbGljaW91cyB0aGlyZCBwYXJ0eSB0byBpbmplY3QgbWVz c2FnZXMgYXBwZWFyaW5nPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiAg VGhpcyBpcyBjb3ZlcmVkIGluIGRldGFpbCBpbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgdG8gY29tZSBmcm9tIGFu IGF1dG9ub21pYyBkZXZpY2UsIGFsbCB0aGVzZSBzYW1lIHJpc2tzIHdvdWxkIGFwcGx5Ljwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgICAgW0ktRC5pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmFdLjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAxOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJZiBBTiBtZXNzYWdlcyBj YW4gYmUgb2JzZXJ2ZWQgYnkgYSB0aGlyZCBwYXJ0eSwgdGhleSBtaWdodCByZXZlYWw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ byAgU3VidmVydGluZyBhIGRldmljZSB3aGljaCBpcyBhbHJlYWR5IHBhcnQgb2YgYSB0cnVz dCBkb21haW4sIGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgdmFsdWFibGUgaW5mb3JtYXRpb24gYWJvdXQgbmV0d29yayBjb25maWd1cmF0aW9uLCBz ZWN1cml0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgICBtb2RpZnlpbmcgaXRzIGJlaGF2aW9yLiAgVGhpcyB0aHJlYXQgaXMg bm90IHNwZWNpZmljIHRvIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgcHJlY2F1dGlvbnMgaW4gdXNlLCBpbmRpdmlkdWFsIHVzZXJzLCBhbmQgdGhl aXIgdHJhZmZpYyBwYXR0ZXJucy4gIElmPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIHNvbHV0aW9uIGRpc2N1c3NlZCBpbiB0 aGlzIGRvY3VtZW50LCBhbmQgYXBwbGllcyB0byBhbGwgbmV0d29yazwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZW5jcnlwdGVkLCBBTiBtZXNzYWdlcyBt aWdodCBzdGlsbCByZXZlYWwgc29tZSBpbmZvcm1hdGlvbiB2aWE8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgc29sdXRpb25z Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdHJhZmZpYyBh bmFseXNpcywgYnV0IHRoaXMgd291bGQgYmUgcXVpdGUgbGltaXRlZCAoZm9yIGV4YW1wbGUs IHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB3b3Vs ZCBiZSBoaWdobHkgdW5saWtlbHkgdG8gcmV2ZWFsIGFueSBzcGVjaWZpYyBpbmZvcm1hdGlv biBhYm91dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBvICBFeHBsb2l0aW5nIHBvdGVudGlhbGx5IHlldCB1bmtub3duIHByb3Rv Y29sIHZ1bG5lcmFiaWxpdGllcyBpbiB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIHVzZXIgdHJhZmZpYykuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5B TiBtZXNzYWdlcyBhcmUgbGlhYmxlIHRvIGJlIGV4cG9zZWQgdG8gdGhpcmQgcGFydGllczwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgICAgQU4gb3Igb3RoZXIgcHJvdG9jb2xzLiAgQWxzbyB0aGlzIGlzIGEgZ2Vu ZXJpYyB0aHJlYXQgdGhhdCBhcHBsaWVzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBvbiBhbnkgdW5wcm90ZWN0ZWQg TGF5ZXIgMiBsaW5rLCBhbmQgdG8gaW5zaWRlciBhdHRhY2tzIGV2ZW4gb248L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg ICAgIHRvIGFsbCBuZXR3b3JrIHNvbHV0aW9ucy48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHByb3RlY3RlZCBMYXll ciAyIGxpbmtzLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgVGhlIGFib3ZlIHRocmVhdHMgYXJlIGluIHByaW5jaXBsZSBjb21wYXJhYmxl IHRvIG90aGVyIHNvbHV0aW9ucy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBIb3dldmVyLCB0aGUgZGlzdHJpYnV0ZWQgbmF0dXJlIG9mIEFOLCBzcGVj aWZpY2FsbHkgdGhlIEF1dG9ub21pYzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIENvbnRyb2wgUGxhbmUsIGluY3JlYXNlcyB0aGUgdGhyZWF0IHN1cmZh Y2UuICBGb3IgZXhhbXBsZSwgYTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIGNvbXByb21pc2VkIGRldmljZSBtYXkgaGF2ZSBmdWxsIElQIHJlYWNoYWJp bGl0eSB0byBhbGwgb3RoZXIgZGV2aWNlczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIGluc2lkZSB0aGUgQUNQLCBhbmQgY2FuIHVzZSBhbGwgQU4gbWV0 aG9kcyBhbmQgcHJvdG9jb2xzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEZv ciB0aGUgbmV4dCBwaGFzZSBvZiB0aGUgQU5JTUEgd29yayBpdCBpcyB0aGVyZWZvcmUgcmVj b21tZW5kZWQgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBpbnRyb2R1Y2UgYSBzdWItZG9tYWluIHNlY3VyaXR5IG1vZGVsLCB0byByZWR1Y2UgdGhl IGF0dGFjayBzdXJmYWNlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgYW5kIG5vdCBleHBvc2UgYSBmdWxsIGRvbWFpbiB0byBhIHBvdGVudGlhbCBpbnRy dWRlci4gIEZ1cnRoZXJtb3JlLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIGFkZGl0aW9uYWwgc2VjdXJpdHkgbWVjaGFuaXNtcyBvbiB0aGUgQVNBIGxl dmVsIHNob3VsZCBiZSBjb25zaWRlcmVkPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgZm9yIGhpZ2gtcmlzayBhdXRvbm9taWMgZnVuY3Rpb25zLjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIE1vc3QgQU4gbWVzc2FnZXMgcnVuIGluc2lk ZSB0aGUgZW5jcnlwdGVkIEFDUC4gIFRoZSBub3QgcHJvdGVjdGVkIEFOPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbWVzc2FnZXMgb3V0c2lkZSB0aGUg QUNQIGFyZSBsaW1pdGVkIHRvIHNpbXBsZSBkaXNjb3ZlcnkgbWV0aG9kcy48L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBTZWUgU2VjdGlvbiAyLjUuMiBv ZiBbSS1ELmlldGYtYW5pbWEtZ3Jhc3BdIGZvciBhIGxpc3Qgb2Ygc3VjaDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG1lc3NhZ2VzLjwvc3Bhbj4gIElm IEFOIG1lc3NhZ2VzIGNhbiBiZSBvYnNlcnZlZCBieSBhIHRoaXJkIHBhcnR5LCB0aGV5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBtaWdodCByZXZlYWwgdmFsdWFibGUgaW5mb3JtYXRpb24gYWJvdXQg bmV0d29yayBjb25maWd1cmF0aW9uLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgc2VjdXJpdHkgcHJlY2F1 dGlvbnMgaW4gdXNlLCBpbmRpdmlkdWFsIHVzZXJzLCBhbmQgdGhlaXIgdHJhZmZpYzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgcGF0dGVybnMuICBJZiBlbmNyeXB0ZWQsIEFOIG1lc3NhZ2VzIG1pZ2h0 IHN0aWxsIHJldmVhbCBzb21lPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbmZvcm1hdGlvbiB2aWEgdHJh ZmZpYyBhbmFseXNpcywgYnV0IHRoaXMgd291bGQgYmUgcXVpdGUgbGltaXRlZDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgKGZvciBleGFtcGxlLCB0aGlzIHdvdWxkIGJlIGhpZ2hseSB1bmxpa2VseSB0 byByZXZlYWwgYW55IHNwZWNpZmljPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbmZvcm1hdGlvbiBhYm91 dCB1c2VyIHRyYWZmaWMpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij45LjIuICBTZWN1cml0eSBNZWNoYW5pc21zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+OS4yLiAgU2VjdXJpdHkgTWVjaGFuaXNtczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgY29tcG9uZW50cyBvZiB0aGUgQU5JIG11 c3QgZWFjaCBpbmNsdWRlIGFwcHJvcHJpYXRlIHNlY3VyaXR5PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgVGhlIGNvbXBvbmVudHMgb2YgdGhlIEFOSSBtdXN0IGVhY2gg aW5jbHVkZSBhcHByb3ByaWF0ZSBzZWN1cml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgbWVjaGFuaXNtcy4gIEluIHBhcnRpY3VsYXIsIHRoZSBBQ1AgbXVzdCBwcm92 aWRlIHNlY3VyaXR5IGFnYWluc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBtZWNoYW5pc21zLiAgSW4gcGFydGljdWxhciwgdGhlIEFDUCBtdXN0IHByb3ZpZGUgc2Vj dXJpdHkgYWdhaW5zdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW50ZXJj ZXB0aW9uLCBmb3JnZXJ5LCBhbmQgcmVwbGF5IG9mIGFueSBtZXNzYWdlcyBzZW50IG92ZXIg dGhlIEFDUC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnRlcmNlcHRp b24sIGZvcmdlcnksIGFuZCByZXBsYXkgb2YgYW55IG1lc3NhZ2VzIHNlbnQgb3ZlciB0aGUg QUNQLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNpZ25hbGluZyBw cm90b2NvbCBtYXkgcmVseSBvbiB0aGlzIHByb3RlY3Rpb24sIGJ1dCBtdXN0IGFsc288L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgc2lnbmFsaW5nIHByb3RvY29s IG1heSByZWx5IG9uIHRoaXMgcHJvdGVjdGlvbiwgYnV0IG11c3QgYWxzbzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdmlkZSBmb3Igc2VjdXJpdHkgd2hlbiBydW5u aW5nIHdpdGhvdXQgYW4gQUNQLiAgQWxsIGNvbXBvbmVudHMgb2Y8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm92aWRlIGZvciBzZWN1cml0eSB3aGVuIHJ1bm5pbmcg d2l0aG91dCBhbiBBQ1AuICBBbGwgY29tcG9uZW50cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgdGhlIHNlY3VyaXR5IGJvb3RzdHJhcCBwcm9jZXNzIG11c3Qgb2Yg Y291cnNlIHRoZW1zZWx2ZXMgYmUgc2VjdXJlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0aGUgc2VjdXJpdHkgYm9vdHN0cmFwIHByb2Nlc3MgbXVzdCBvZiBjb3Vy c2UgdGhlbXNlbHZlcyBiZSBzZWN1cmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgQWxsIEFTQXMgbXVzdCBtYWtlIHVzZSBvZiB0aGUgQU5JJ3Mgc2VjdXJpdHksIGFu ZCBtdXN0IGJlIGNhcmVmdWxseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEFsbCBBU0FzIG11c3QgbWFrZSB1c2Ugb2YgdGhlIEFOSSdzIHNlY3VyaXR5LCBhbmQgbXVz dCBiZSBjYXJlZnVsbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlc2ln bmVkIHNvIHRoYXQgdGhleSBkbyBub3QgY3JlYXRlIHNlY3VyaXR5ICJob2xlcyIgaW4gdGhl IGJvdW5kYXJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzaWduZWQg c28gdGhhdCB0aGV5IGRvIG5vdCBjcmVhdGUgc2VjdXJpdHkgImhvbGVzIiBpbiB0aGUgYm91 bmRhcnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIHRoZSB3aG9sZSBB TiBzeXN0ZW0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgdGhlIHdo b2xlIEFOIHN5c3RlbS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+MTAuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+MTAuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgcmVxdWVzdHMgbm8gYWN0aW9u IGJ5IElBTkEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1 bWVudCByZXF1ZXN0cyBubyBhY3Rpb24gYnkgSUFOQS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MTEuICBBY2tub3dsZWRnZW1lbnRzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+MTEuICBBY2tub3dsZWRnZW1lbnRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1hbnkgcGVvcGxlIGhhdmUgcHJv dmlkZWQgZmVlZGJhY2sgYW5kIGlucHV0IHRvIHRoaXMgZG9jdW1lbnQ6IFNoZW5nPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWFueSBwZW9wbGUgaGF2ZSBwcm92aWRl ZCBmZWVkYmFjayBhbmQgaW5wdXQgdG8gdGhpcyBkb2N1bWVudDogU2hlbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTkiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgSmlhbmcsIFJvYmVydGEgTWFnbGlvbmUsIEpvbmF0aGFuIEhhbnNmb3Jk LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBKaWFuZywgUm9iZXJ0YSBN YWdsaW9uZSwgSm9uYXRoYW4gSGFuc2ZvcmQ8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4sIEphc29u IENvbGVtYW48L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4xMi4gIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4x Mi4gIFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgW0ktRC5kdS1hbmltYS1hbi1pbnRlbnRdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgW0ktRC5kdS1hbmltYS1hbi1pbnRlbnRdPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIwIj48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgICAgICAgICAgRHUsIFouLCBKaWFuZywgUy4sIE5vYnJlLCBKLiwgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+YW5kIEwuPC9zcGFuPiBDaWF2YWdsaWEsICJBTklNQTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIER1LCBaLiwgSmlhbmcsIFMu LCBOb2JyZSwgSi4sIENpYXZhZ2xpYSwgPHNwYW4gY2xhc3M9Imluc2VydCI+TC4sIGFuZCBN Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAg ICBJbnRlbnQgUG9saWN5IGFuZCBGb3JtYXQiLCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5kcmFm dC1kdS1hbmltYS1hbi1pbnRlbnQtMDM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgQmVocmluZ2Vy LDwvc3Bhbj4gIkFOSU1BIEludGVudCBQb2xpY3kgYW5kIEZvcm1hdCIsIDxzcGFuIGNsYXNz PSJpbnNlcnQiPmRyYWZ0LWR1LTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJk ZWxldGUiPk1hcmNoIDIwMTYuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIGFuaW1hLWFuLWludGVu dC0wNTwvc3Bhbj4gKHdvcmsgaW4gcHJvZ3Jlc3MpLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5G ZWJydWFyeSAyMDE3Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgW0ktRC5pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lXTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1hbmltYS1hdXRv bm9taWMtY29udHJvbC1wbGFuZV08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0iZGlmZjAwMjEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBC ZWhyaW5nZXIsIE0uLCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5CamFybmFzb24sIFMuLCBCTCwg Qi4sIGFuZCBULjwvc3Bhbj4gRWNrZXJ0LCAiQW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICBCZWhyaW5nZXIsIE0uLCBFY2tlcnQsIDxzcGFuIGNs YXNzPSJpbnNlcnQiPlQuLCBhbmQgUy4gQmphcm5hc29uLDwvc3Bhbj4gIkFuIEF1dG9ub21p YzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIEF1dG9u b21pYyBDb250cm9sIFBsYW5lIiwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQtaWV0Zi1h bmltYS1hdXRvbm9taWMtPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgICAgICAgIENvbnRyb2wgUGxhbmUiLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5k cmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLTwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAg ICBjb250cm9sLXBsYW5lLTAyPC9zcGFuPiAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDxz cGFuIGNsYXNzPSJkZWxldGUiPjIwMTYuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIHBsYW5lLTA2 PC9zcGFuPiAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDxzcGFuIGNsYXNzPSJpbnNlcnQi PjIwMTcuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGlu Zy1rZXlpbmZyYV08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwMjIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBQcml0aWtpbiwg TS4sIFJpY2hhcmRzb24sIE0uLCBCZWhyaW5nZXIsIE0uLCA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5hbmQgUy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAgICAgICAgUHJpdGlraW4sIE0uLCBSaWNoYXJkc29uLCBNLiwgQmVocmluZ2VyLCBNLiwg Qmphcm5hc29uLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgIEJqYXJuYXNvbiwgIkJvb3RzdHJhcHBpbmcgUmVtb3RlIFNlY3VyZSBLZXk8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5TLiwgYW5kIEsuIFdhdHNlbiw8L3NwYW4+ICJCb290c3RyYXBwaW5nIFJlbW90 ZSBTZWN1cmUgS2V5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgIEluZnJhc3RydWN0dXJlcyAoQlJTS0kpIiwgZHJhZnQtaWV0Zi1hbmltYS1ib290c3Ry YXBwaW5nLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg SW5mcmFzdHJ1Y3R1cmVzIChCUlNLSSkiLCBkcmFmdC1pZXRmLWFuaW1hLWJvb3RzdHJhcHBp bmctPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDIzIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAga2V5aW5mcmEtMDxzcGFuIGNs YXNzPSJkZWxldGUiPjMgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMTY8L3NwYW4+Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIGtleWluZnJh LTA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTc8 L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBb SS1ELmlldGYtYW5pbWEtZ3Jhc3BdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgW0ktRC5pZXRmLWFuaW1hLWdyYXNwXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgIEJvcm1hbm4sIDxzcGFuIGNsYXNzPSJkZWxldGUiPkQ8L3NwYW4+LiwgQ2FycGVudGVy LCBCLiwgYW5kIEIuIExpdSwgIkEgR2VuZXJpYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgIEJvcm1hbm4sIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkM8 L3NwYW4+LiwgQ2FycGVudGVyLCBCLiwgYW5kIEIuIExpdSwgIkEgR2VuZXJpYzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBBdXRvbm9taWMgU2lnbmFs aW5nIFByb3RvY29sIChHUkFTUCkiLCBkcmFmdC1pZXRmLWFuaW1hLTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQXV0b25vbWljIFNpZ25hbGluZyBQ cm90b2NvbCAoR1JBU1ApIiwgZHJhZnQtaWV0Zi1hbmltYS08L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjUiPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgICAgICAgICBncmFzcC08c3BhbiBjbGFzcz0iZGVsZXRlIj4wNiAod29yayBpbiBw cm9ncmVzcyksIEp1bmUgMjAxNjwvc3Bhbj4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgICAgICAgICAgZ3Jhc3AtPHNwYW4gY2xhc3M9Imluc2VydCI+MTQgKHdv cmsgaW4gcHJvZ3Jlc3MpLCBKdWx5IDIwMTc8L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtYW5pbWEtcHJlZml4LW1hbmFn ZW1lbnRdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWFu aW1hLXByZWZpeC1tYW5hZ2VtZW50XTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICBKaWFuZywgUy4sIER1LCBaLiwgQ2FycGVudGVyLCBCLiwgYW5kIFEu IFN1biwgIkF1dG9ub21pYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgSmlhbmcsIFMuLCBEdSwgWi4sIENhcnBlbnRlciwgQi4sIGFuZCBRLiBTdW4s ICJBdXRvbm9taWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgSVB2NiBFZGdlIFByZWZpeCBNYW5hZ2VtZW50IGluIExhcmdlLXNjYWxlIE5ldHdvcmtz Iiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIElQdjYg RWRnZSBQcmVmaXggTWFuYWdlbWVudCBpbiBMYXJnZS1zY2FsZSBOZXR3b3JrcyIsPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDI2Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQt aWV0Zi1hbmltYS1wcmVmaXgtbWFuYWdlbWVudC0wMDwvc3Bhbj4gKHdvcmsgaW4gcHJvZ3Jl c3MpLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWlldGYtYW5pbWEtcHJlZml4LW1hbmFnZW1lbnQt MDQ8L3NwYW4+ICh3b3JrIGluIHByb2dyZXNzKSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5KYW51YXJ5IDIw MTYuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAg ICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkp1bmUgMjAxNy48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQubGl1LWFuaW1hLWdyYXNw LWFwaV08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELmxpdS1hbmlt YS1ncmFzcC1hcGldPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgIENhcnBlbnRlciwgQi4sIExpdSwgQi4sIFdhbmcsIFcuLCBhbmQgWC4gR29uZywgIkdl bmVyaWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIENh cnBlbnRlciwgQi4sIExpdSwgQi4sIFdhbmcsIFcuLCBhbmQgWC4gR29uZywgIkdlbmVyaWM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgQXV0b25vbWlj IFNpZ25hbGluZyBQcm90b2NvbCBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQXV0b25vbWljIFNp Z25hbGluZyBQcm90b2NvbCBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyNyI+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAgICAgICAgIChHUkFTUCBBUEkpIiwgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS0wMTwvc3Bhbj4gKHdvcmsgaW48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAoR1JBU1AgQVBJ KSIsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGktMDQ8 L3NwYW4+ICh3b3JrIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg ICAgICAgICAgcHJvZ3Jlc3MpLCBKdW5lIDxzcGFuIGNsYXNzPSJkZWxldGUiPjIwMTYuPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIHBy b2dyZXNzKSwgSnVuZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yMDE3Ljwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5saXUtYW5pbWEt Z3Jhc3AtZGlzdHJpYnV0aW9uXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFtJLUQubGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbl08L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgTGl1LCBCLiBhbmQgUy4gSmlhbmcsICJJbmZv cm1hdGlvbiBEaXN0cmlidXRpb24gb3ZlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgTGl1LCBCLiBhbmQgUy4gSmlhbmcsICJJbmZvcm1hdGlvbiBE aXN0cmlidXRpb24gb3ZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAyOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIEdSQVNQ IiwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1 dGlvbi0wMTwvc3Bhbj4gKHdvcmsgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICAgICAgICAgICBHUkFTUCIsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWxp dS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24tMDQ8L3NwYW4+ICh3b3JrIGluPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCA8c3Bh biBjbGFzcz0iZGVsZXRlIj5NYXJjaCAyMDE2Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJp bnNlcnQiPk1heSAyMDE3Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgW0ktRC5zdHJhc3NuZXItYW5pbWEtY29udHJvbC1sb29wc108L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1ELnN0cmFzc25lci1hbmltYS1j b250cm9sLWxvb3BzXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICBTdHJhc3NuZXIsIEouLCBIYWxwZXJuLCBKLiwgYW5kIE0uIEJlaHJpbmdlciwgIlRo ZSBVc2Ugb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg IFN0cmFzc25lciwgSi4sIEhhbHBlcm4sIEouLCBhbmQgTS4gQmVocmluZ2VyLCAiVGhlIFVz ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBDb250 cm9sIExvb3BzIGluIEF1dG9ub21pYyBOZXR3b3JraW5nIiwgZHJhZnQtc3RyYXNzbmVyLTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQ29udHJvbCBM b29wcyBpbiBBdXRvbm9taWMgTmV0d29ya2luZyIsIGRyYWZ0LXN0cmFzc25lci08L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgYW5pbWEtY29udHJvbC1s b29wcy0wMSAod29yayBpbiBwcm9ncmVzcyksIEFwcmlsIDIwMTYuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBhbmltYS1jb250cm9sLWxvb3BzLTAx ICh3b3JrIGluIHByb2dyZXNzKSwgQXByaWwgMjAxNi48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0lEZXZJRF0gICBJRUVFIFN0YW5kYXJkLCAsICJJ RUVFIDgwMi4xQVIgU2VjdXJlIERldmljZSBJZGVudGlmaWVyIiw8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBbSURldklEXSAgIElFRUUgU3RhbmRhcmQsICwgIklFRUUg ODAyLjFBUiBTZWN1cmUgRGV2aWNlIElkZW50aWZpZXIiLDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBEZWNlbWJlciAyMDA5LCAmbHQ7aHR0cDovL3N0 YW5kYXJkcy5pZWVlLm9yZy9maW5kc3Rkcy88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMDksICZsdDtodHRwOi8vc3RhbmRhcmRz LmllZWUub3JnL2ZpbmRzdGRzLzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICBzdGFuZGFyZC84MDIuMUFSLTIwMDkuaHRtbCZndDsuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBzdGFuZGFyZC84MDIuMUFSLTIw MDkuaHRtbCZndDsuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+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+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjkiPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICAgICAgICAgICBOZXR3b3JraW5nOiBEZWZpbml0aW9ucyBhbmQg RGVzaWduIEdvYWxzIiwgUkZDIDc1NzUsIERPSTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgIE5ldHdvcmtpbmc6IERlZmluaXRpb25zIGFuZCBEZXNp Z24gR29hbHMiLCBSRkMgNzU3NSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgICAgICAgICAxMC4xNzQ4Ny9SRkM3NTc1LCBKdW5lIDIwMTUsPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzc1 NzUsIEp1bmUgMjAxNSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgJmx0O2h0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NTc1Jmd0Oy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICZsdDtodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzU3NSZndDsuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3NTc2XSAgSmlhbmcsIFMuLCBD YXJwZW50ZXIsIEIuLCBhbmQgTS4gQmVocmluZ2VyLCAiR2VuZXJhbCBHYXA8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDNzU3Nl0gIEppYW5nLCBTLiwgQ2FycGVu dGVyLCBCLiwgYW5kIE0uIEJlaHJpbmdlciwgIkdlbmVyYWwgR2FwPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDMwIj48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgICAgICAgICAgQW5hbHlzaXMgZm9yIEF1dG9ub21pYyBOZXR3b3JraW5nIiwg UkZDIDc1NzYsIERPSTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgIEFuYWx5c2lzIGZvciBBdXRvbm9taWMgTmV0d29ya2luZyIsIFJGQyA3NTc2LDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIDEwLjE3NDg3 L1JGQzc1NzYsIEp1bmUgMjAxNSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNzU3NiwgSnVuZSAyMDE1LDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc1NzYmZ3Q7LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgJmx0O2h0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcv aW5mby9yZmM3NTc2Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIE1pY2hhZWwgSC4gQmVocmluZ2VyIChlZGl0b3IpPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWljaGFlbCBILiBCZWhyaW5nZXIgKGVkaXRvcik8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRW1haWw6IE1p Y2hhZWwuSC5CZWhyaW5nZXJAZ21haWwuY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgRW1haWw6IE1pY2hhZWwuSC5CZWhyaW5nZXJAZ21haWwuY29tPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCcmlhbiBDYXJwZW50ZXI8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBCcmlhbiBDYXJwZW50ZXI8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERlcGFydG1lbnQgb2YgQ29tcHV0ZXIg U2NpZW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVW5pdmVyc2l0eSBv ZiBBdWNrbGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFVuaXZlcnNp dHkgb2YgQXVja2xhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CgogICAg IDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgaWQ9ImVuZCIgYmdjb2xv cj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPiZuYnNwO0VuZCBvZiBj aGFuZ2VzLiAzMCBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvdGg+PC90cj4KICAgICA8dHIgY2xh c3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+ODAgbGluZXMgY2hhbmdlZCBvciBkZWxldGVk PC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+ODggbGluZXMgY2hhbmdlZCBvciBh ZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBh bGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxici8+VGhpcyBodG1sIGRpZmYgd2FzIHBy b2R1Y2VkIGJ5IHJmY2RpZmYgMS40NS4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlm Zi8iID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90 cj4KICAgPC90YWJsZT4KICAgPC9ib2R5PgogICA8L2h0bWw+Cg== --------------F5D4D8D8A03D99C96331B8CA-- From nobody Wed Jul 5 07:43:07 2017 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 37706132A44 for ; Wed, 5 Jul 2017 07:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5hcUB6Jb3un for ; Wed, 5 Jul 2017 07:43:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5ED7131D45 for ; Wed, 5 Jul 2017 07:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4772; q=dns/txt; s=iport; t=1499265781; x=1500475381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0SiRIIGMV+ItF7XRa/mn+T5OkWisF+eH7ACY9sqsCbU=; b=GzSrDkzuH9RdqkbUKmiG09/zgnEMNUUShqjlsRTqST6XUZdjsVlphZDc f4V3B+v2A9+EHI6+VezFkiy271LoEQBcgz7c3haNTSj7DHXiE072YKjOy 5y32xK8tQ020qvxg/qEWfQ9ayGaRVfgWSNwKPxpYpKVscKz7H9LCDzl7u 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADp+VxZ/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1ljgRAHjgKRZ4gsjVSCESENhW4CGoJ+PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhEToLBQsCAQgYAgImAgICHwYLFRACBAENBYoXAw0IEK4dgiaHM?= =?us-ascii?q?A2EBQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuCHIUtK4J5gleBcCMXgnwwgjE?= =?us-ascii?q?Fnks7AodFh1SEapIei3SJPgEfOIEKdRVJEgGHAnYBhkSBMYENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,312,1496102400"; d="scan'208";a="264310848" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2017 14:43:00 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v65Eh0f2029590 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Jul 2017 14:43:00 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 09:42:59 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 09:42:59 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter , Michael Richardson CC: Anima WG Thread-Topic: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07 Thread-Index: AQHS9IboiBWJ8wdODkKDyZBFI49YPaJFpMGA Date: Wed, 5 Jul 2017 14:42:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.7] Content-Type: text/plain; charset="utf-8" Content-ID: <62F6E25740A01F4B9515A3D8F538BEC0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 14:43:06 -0000 QnJpYW4sIEnigJltIG91dCBmb3IgYSBjb3VwbGUgb2Ygd2Vla3MgYnV0IHdhbnRlZCB0byB0aGFu ayB5b3UgZm9yIHRoaXMgbm90ZS4gDQoNCk1pY2hhZWwgUmljaGFyZHNvbiB3aWxsIGxpa2VseSBo YXZlIGdvb2QgY29tbWVudHMgYnV0IGZvciBub3cgSeKAmXZlIHNldCBhIGNhbGVuZGFyIGV2ZW50 IHRvIGNhdGNoIHVwIHdoZW4gSSByZXR1cm4gYW5kIGFsc28gaGF2ZSBjcmVhdGVkIGEgZ2l0aHVi IGlzc3VlIHRvIHRyYWNrIHRoaXMuIA0KCWh0dHBzOi8vZ2l0aHViLmNvbS9hbmltYS13Zy9hbmlt YS1ib290c3RyYXAvaXNzdWVzLzIyDQoNCi0gbWF4DQoNCj4gT24gSnVsIDMsIDIwMTcsIGF0IDEx OjMyIFBNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3 cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gSSBhbSBzdGlsbCB0cnlpbmcgdG8gZmlndXJlIG91dCB3 aGF0IHlvdSByZWFsbHkgd2FudCB0byBzYXkgaW4gc2VjdGlvbnMgMy4xLjEuIFByb3h5IERpc2Nv dmVyeSBQcm90b2NvbCBEZXRhaWxzIGFuZCAzLjEuMi4gUmVnaXN0cmFyIERpc2NvdmVyeSBQcm90 b2NvbCBEZXRhaWxzLg0KPiANCj4gMS4gV2h5IGRvZXNuJ3Qgc2VjdGlvbiAzLjEuMSBtZW50aW9u IElQLWluLUlQIChwcm90b2NvbCA0MSk/IFN1cmVseSB0aGUgcGxlZGdlIG5lZWRzIHRvIGtub3cg YWJvdXQgaXQ/DQo+IA0KPiAyLiBUaGUgZGVzY3JpcHRpb24gaXMgd3JvbmcgYW55d2F5OyBzZWUg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhcnBlbnRlci1hbmltYS1hbmktb2Jq ZWN0aXZlcy0wMiNzZWN0aW9uLTIuMyBmb3Igc29tZXRoaW5nIHRoYXQgY2FuIHdvcmsuDQo+IA0K PiAzLiBJbiBzZWN0aW9uIDMuMS4yLCBhcyBJIGFscmVhZHkgcG9pbnRlZCBvdXQsIHRoZSBwcm9w b3NhbCBpcyByZWFsbHkgYSBtaXN1c2Ugb2YgdGhlIEdSQVNQIGRpc2NvdmVyeSByZXNwb25zZSBt ZXNzYWdlLiBOb3QgYSBwcm9ibGVtLCB3ZSBzaW1wbHkgcmVwbGFjZSBpdCB3aXRoIGEgc3luY2hy b25pemF0aW9uIHJlc3BvbnNlOyBzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWNhcnBlbnRlci1hbmltYS1hbmktb2JqZWN0aXZlcy0wMiNzZWN0aW9uLTIuMi4gDQo+IEJ1dCBy ZWdhcmRsZXNzIG9mIHRoYXQsIEkgYW0gY29uZnVzZWQgYnkgdGhlIGV4YW1wbGUgbG9jYXRvcnM6 DQo+ICAgIGxvY2F0b3IxICA9IFtPX0lQdjZfTE9DQVRPUiwgZmQ0NToxMzQ1Ojo2Nzg5LCA2LCAg NDQzXQ0KPiAgICBsb2NhdG9yMiAgPSBbT19JUHY2X0xPQ0FUT1IsIGZkNDU6MTM0NTo6Njc4OSwg MTcsIDU2ODNdDQo+ICAgIGxvY2F0b3IzICA9IFtPX0lQdjZfTE9DQVRPUiwgZmU4MDo6MTIzNCwg NDEsIG5pbF0NCj4gDQo+IFRoZSBmaXJzdCB0d28gYXJlIE9LLiBUaGUgcG9ydHMgYW5ub3VuY2Vk IGJ5IHRoZSBwcm94eSB0byB0aGUgcGxlZGdlcyBtYXkgYmUgZGlmZmVyZW50LiBJZiB0aGUgcmVn aXN0cmFyIHNlbmRzICBbT19JUHY2X0xPQ0FUT1IsIGZkNDU6MTM0NTo6Njc4OSwgNiwgIDQ0M10s IHRoZSBwcm94eSBtaWdodCBhbm5vdW5jZSBbT19JUHY2X0xPQ0FUT1IsIGZlODA6OjQzMjEsIDYs IDk5OTldIC0gdGhlIHByb3h5J3MgbGluay1sb2NhbCBhZGRyZXNzIGFuZCBhIGRpZmZlcmVudCBw b3J0IGNob3NlbiBieSB0aGUgcHJveHkuDQo+IA0KPiBCdXQgdGhlIHRoaXJkIGxvY2F0b3Igc2Vu dCBieSB0aGUgUmVnaXN0cmFyIGluZGljYXRlcyBhIG1lYW5pbmdsZXNzIGxpbmstbG9jYWwgYWRk cmVzcywgYmVjYXVzZSBpdCBjb3VsZCBjb21lIGZyb20gbWFueSBob3BzIGF3YXkuIEF0IGZpcnN0 IEkgdGhvdWdodCB0aGlzIHdhcyBhIGNvbmZ1c2lvbiB3aXRoIHRoZSBwcmV2aW91cyAocHJveHkt dG8tcGxlZGdlKSBjYXNlLCB3aGVyZSBhbGwgYWRkcmVzc2VzIG11c3QgYmUgbGluay1sb2NhbC4g QnV0IG5vOiB0aGlzIHRleHQgaXMganVzdCBjb25mdXNlZCwgSSB0aGluazoNCj4gDQo+ICAgQSBw cm90b2NvbCBvZiA0MSBpbmRpY2F0ZXMgdGhhdCBwYWNrZXRzIG1heSBiZSBJUElQIHByb3h5J2Vk LiAgSW4gdGhlDQo+ICAgY2FzZSBvZiB0aGF0IElQSVAgcHJveHlpbmcgaXMgdXNlZCwgdGhlbiB0 aGUgcHJvdmlkZWQgbGluay1sb2NhbA0KPiAgIGFkZHJlc3MgTVVTVCBiZSBhZHZlcnRpc2VkIG9u IHRoZSBsb2NhbCBsaW5rIHVzaW5nIHByb3h5IG5laWdoYm91cg0KPiAgIGRpc2NvdmVyeS4gIFRo ZSBKb2luIFByb3h5IE1BWSBsaW1pdCBmb3J3YXJkZWQgdHJhZmZpYyB0byB0aGUNCj4gICBwcm90 b2NvbCAoNiBhbmQgMTcpIGFuZCBwb3J0IG51bWJlcnMgaW5kaWNhdGVkIGJ5IGxvY2F0b3IxIGFu ZA0KPiAgIGxvY2F0b3IyLiAgVGhlIGFkZHJlc3MgdG8gd2hpY2ggdGhlIElQSVAgdHJhZmZpYyBz aG91bGQgYmUgc2VudCBpcw0KPiAgIHRoZSBpbml0aWF0b3IgYWRkcmVzcyAoYW4gQUNQIGFkZHJl c3Mgb2YgdGhlIFJlZ2lzdHJhciksIG5vdCB0aGUNCj4gICBhZGRyZXNzIGdpdmVuIGluIHRoZSBs b2NhdG9yLg0KPiANCj4gQSBsaW5rIGxvY2FsIGFkZHJlc3MgcHJvdmlkZWQgYnkgdGhlIFJlZ2lz dHJhciBpcyBjb21wbGV0ZWx5IGludmFsaWQgZXhjZXB0IG9uIHRoZSByZWxldmFudCBsaW5rIGNv bm5lY3RlZCBkaXJlY3RseSB0byB0aGUgUmVnaXN0cmFyLiBTbyBpdCBkZWZpbml0ZWx5IG11c3Qg bm90IGJlIGdpdmVuIHRvIGFueWJvZHkgb2ZmIHRoYXQgbGluay4gQXQgdGhlIG1vbWVudCBJIGhh dmUgbm8gaWRlYSBob3cgdGhlIElQLWluLUlQIGlzIHN1cHBvc2VkIHRvIHdvcmsuIEFwcGVuZGl4 IEMgZG9lc24ndCBoZWxwIG11Y2guIEFwYXJ0IGZyb20gYW55dGhpbmcgZWxzZSwgaXQgbWVudGlv bnMgYSBub24tZXhpc3RlbnQgR1JBU1AgbWVzc2FnZSB0eXBlLiBJIGNhbiBzb3J0IG9mIHNlZSB3 aGF0IHlvdSB3YW50IHRvIGRvLCBidXQgaXQgaXNuJ3QgYSBjb2RhYmxlIHNwZWMgYXQgdGhlIG1v bWVudC4NCj4gDQo+IE1heWJlIHlvdSBjYW4gcHJvdmlkZSBhIGNvbXBsZXRlIGV4YW1wbGUgb2Yg dGhlIHBhY2tldCBmbG93LCB3aGVyZSB0aGUgcGxlZGdlIGhhcyBsaW5rLWxvY2FsIGFkZHJlc3Mg THAsIHRoZSBwcm94eSBoYXMgbGluay1sb2NhbCBhZGRyZXNzIEx4IGFuZCBBQ1AgYWRkcmVzcyBB eCwgYW5kIHRoZSByZWdpc3RyYXIgaGFzIEFDUCBhZGRyZXNzIEFyLiBBbmQgdG8gbWFrZSBteSBj b25jZXJuIGNsZWFyLCB0aGUgcmVnaXN0cmFyIGhhcyB0aGUgbGluay1sb2NhbCBhZGRyZXNzIExw LCBieSBjaGFuY2UgdGhlIHNhbWUgYXMgdGhlIHBsZWRnZSwgYWx0aG91Z2ggb24gYSBkaWZmZXJl bnQgTEFOLg0KPiANCj4gUmVnYXJkcw0KPiAgIEJyaWFuDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4g QW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h bmltYQ0KDQo= From nobody Wed Jul 5 15:45:27 2017 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 2056F127201 for ; Wed, 5 Jul 2017 15:45: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, RP_MATCHES_RCVD=-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 GdVu__pQy1vz for ; Wed, 5 Jul 2017 15:45: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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8560126B72 for ; Wed, 5 Jul 2017 15:45:23 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B201958C4C5 for ; Thu, 6 Jul 2017 00:45:19 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9CAE1B0C4CC; Thu, 6 Jul 2017 00:45:19 +0200 (CEST) Date: Thu, 6 Jul 2017 00:45:19 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20170705224519.GA14122@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] draft-ietf-anima-bootstrapping-keyinfra shepherd review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 22:45:26 -0000 Just FYI: I started with the authors a shepherd review for subject draft, shortly before -06 was finished. Alas, we've not been able to merge all the work of reviewing that back into the latest pusblished version -07 primarily because that one primarily focussed on getting inline with the voucher draft specs and terminology as well as spending cycles on that voucher draft. Lets see how quickly we can make progress with the remaining items. Details see: https://raw.githubusercontent.com/anima-wg/anima-bootstrap/master/1706-shepherd-review/README.txt Cheers Toerless From nobody Wed Jul 5 16:06:01 2017 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 9F407120227 for ; Wed, 5 Jul 2017 16:05:59 -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, RP_MATCHES_RCVD=-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 5qTA0dNgonlA for ; Wed, 5 Jul 2017 16:05:58 -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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E529F126B6E for ; Wed, 5 Jul 2017 16:05:57 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D986058C4C5; Thu, 6 Jul 2017 01:05:53 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C26EBB0C4CD; Thu, 6 Jul 2017 01:05:53 +0200 (CEST) Date: Thu, 6 Jul 2017 01:05:53 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170705230553.GB14122@faui40p.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 23:05:59 -0000 Brian, 1. I think the conclusions about IP-in-IP where that it should be in an appendix because it would not be MTI (Mandatory to implement). 2./3. This was addressed in my shepherd review BRSKI where i folded in the information from your ani-objectives draft. See my other mail about the status of that review. You can find the last integrated version of the ani objective text for BRSKI in section 3.4 of: https://raw.githubusercontent.com/anima-wg/anima-bootstrap/toerless_review_section3_20160606/dtbootstrap-anima-keyinfra.txt This was done in may/june. Like for acp-07, i would like to improve this though: -> I did very much like what the original BRSKI text had, eg: showing also the addresses in an example (independent of the fact that as you explain below the examples are not correct). - Because the addresses are not in the objective field but in the locator-option, your proposed text in ani-objectives does not show it. In result i could only understand ani-objectives going back and forth with the grasp draft. I think that makes it quite unreadable. Thats why the text i put into acp-07 does show the whole M_FLOOD format including the location-option and objective. - I think your concern was a bit about consistency and duplication. I am not worried about consistency given how GRASP is out the door (i hope ;-), and i am happy to invest the time for the few additional lines in BRSKI and ACP to make the GRASP explanations in BRSKI and ACP be readable (and verifyable for functionality) standalone. Especially because of this IMHO confusing bit of scatter-gather encoding that we ended up with in GRASP: The name of the service is a parameter to the objective, but the address information of the service is in the locator-option field outside of the objective... -> in ani-objectives, the service is called "method", but in grasp-14 it's called now objective-value. Cheers Toerless On Tue, Jul 04, 2017 at 05:32:06PM +1200, Brian E Carpenter wrote: > Hi, > > I am still trying to figure out what you really want to say in sections 3.1.1. Proxy Discovery Protocol Details and 3.1.2. Registrar Discovery Protocol Details. > > 1. Why doesn't section 3.1.1 mention IP-in-IP (protocol 41)? Surely the pledge needs to know about it? > > 2. The description is wrong anyway; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.3 for something that can work. > > 3. In section 3.1.2, as I already pointed out, the proposal is really a misuse of the GRASP discovery response message. Not a problem, we simply replace it with a synchronization response; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.2. > But regardless of that, I am confused by the example locators: > locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] > locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] > locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] > > The first two are OK. The ports announced by the proxy to the pledges may be different. If the registrar sends [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443], the proxy might announce [O_IPv6_LOCATOR, fe80::4321, 6, 9999] - the proxy's link-local address and a different port chosen by the proxy. > > But the third locator sent by the Registrar indicates a meaningless link-local address, because it could come from many hops away. At first I thought this was a confusion with the previous (proxy-to-pledge) case, where all addresses must be link-local. But no: this text is just confused, I think: > > A protocol of 41 indicates that packets may be IPIP proxy'ed. In the > case of that IPIP proxying is used, then the provided link-local > address MUST be advertised on the local link using proxy neighbour > discovery. The Join Proxy MAY limit forwarded traffic to the > protocol (6 and 17) and port numbers indicated by locator1 and > locator2. The address to which the IPIP traffic should be sent is > the initiator address (an ACP address of the Registrar), not the > address given in the locator. > > A link local address provided by the Registrar is completely invalid except on the relevant link connected directly to the Registrar. So it definitely must not be given to anybody off that link. At the moment I have no idea how the IP-in-IP is supposed to work. Appendix C doesn't help much. Apart from anything else, it mentions a non-existent GRASP message type. I can sort of see what you want to do, but it isn't a codable spec at the moment. > > Maybe you can provide a complete example of the packet flow, where the pledge has link-local address Lp, the proxy has link-local address Lx and ACP address Ax, and the registrar has ACP address Ar. And to make my concern clear, the registrar has the link-local address Lp, by chance the same as the pledge, although on a different LAN. > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 5 16:14:05 2017 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 B0AFC12EA95 for ; Wed, 5 Jul 2017 16:14:03 -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, RP_MATCHES_RCVD=-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 y1NJu2ZeXTxq for ; Wed, 5 Jul 2017 16:14:01 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286C0120227 for ; Wed, 5 Jul 2017 16:14:01 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B77B358C4C5; Thu, 6 Jul 2017 01:13:56 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A4909B0C4CD; Thu, 6 Jul 2017 01:13:56 +0200 (CEST) Date: Thu, 6 Jul 2017 01:13:56 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org Message-ID: <20170705231356.GC14122@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> <20170703235944.GD12926@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 23:14:04 -0000 On Tue, Jul 04, 2017 at 12:23:13PM +1200, Brian E Carpenter wrote: > Toerless, > > > I actually expanded on the text to represent the whole M_FLOOD message format > > because i always found it highly irritating having to switch between the > > taget draft (ACP etc.) and the GRASP draft to really see whats in the whole > > message. > > I have mixed feelings about that, because of the obvious scope > for error, and the general risk of duplicating material between > documents. In any case, we need to check it in great detail. > (The best check would be to make and debug a demo implementation, > dump the actual packets, and check that they correspond.) See other mail thread about BRSKI. > This is actually why we also need consensus on the GRASP API. > It's much easier to verify a use case against the API than to > work out message details. Moving from protocol descriptions to API ? A small step for Brian but a giant leap of faith for IETF ? Aka: 1. right now i didn't want BRSKI/ACP to refer to an API thats further out from RFC than the protocol spec. 2. I am not aware of BCP in the IETF to refer to APIs given how little APIs the IETF has standardized, so i am a bit reluctant at this stage in ANIMA to explore even more long term good things as scouts. If you have pointers to other docs referring to other APIs defined by IETF in a normative fashion, that would help aleviate that anxiety quite a bit. 3. Given how GRASP itself is not widely deployed, i do like the additional cross-checking/validation we get by looking at the whole packet right now. We already figured out the need to carry ports in GRASP IMHO because of exactly this view - instead of just trusing APIs. Aka: I'd be happy to ask authors (including myself) to refer to only GRASP APIs for any drafts that would have the same (or slower_ timeline as GRASP API. And to put GRASP API on fast-track (as much as we can). Cheers Toerless > Regards > Brian > > On 04/07/2017 11:59, Toerless Eckert wrote: > > On Thu, Jun 29, 2017 at 02:44:14PM +1200, Brian E Carpenter wrote: > >> I had a look at both sets of changes and they seem good to me. > > > > Thanks. The reviewed document was just pushed as -03 to datatracker, see other emails. > > > >> I find myself wondering, after seeing the slightly confused text > >> about GRASP objectives in the latest BRSKI, and noting the absence > >> of such objectives in the ACP and stable-connectivity drafts, whether > >> we should accept that we need a specialised draft for all the > >> GRASP objectives needed by the ANI. > > > > I am still working through the last two IETFs agreement that we need to update > > BRSKI and ACP drafts to allow dissolving of the ani-objectives (and use it as > > the starting point). > > > > The BRSKI changes for this are still in a github branch we have not gotten through > > to merge into the main branch due to prioritizing voucher work first (get thast > > through last call). > > > > The ACP draft changes to introduce the ani-objectives proposed GRASP objective > > details are included in the -07 ACP draft that i also just submitted. > > > > I actually expanded on the text to represent the whole M_FLOOD message format > > because i always found it highly irritating having to switch between the > > taget draft (ACP etc.) and the GRASP draft to really see whats in the whole > > message. > > > > Wrt to GRASP in stable connectivity, i think we should try to also finish up this > > draft, the ideas how else NOC and ANI can be integrated is for both time and > > other reasons better done in a followup draft: Another such reason could be > > to introduce those GRASP objectives/functions as a standards strack document > > (stable connectivity is just informational target). > > > > Cheers > > Toerless > > > >> Strangely enough, we have such a draft already: > >> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01 > >> My idea was for this to be a temporary draft, with its contents > >> being moved into BSRKI, ACP and stable-connectivity. But would it > >> be more practical to keep it as a separate draft? It makes the other > >> three drafts a bit more self-contained, and allows for a consistent > >> definition of the infrastructure objectives. > >> > >> What to do people think? > >> > >> (Disregard the current details in draft-carpenter-anima-ani-objectives, > >> which has not been updated recently.) > >> > >> Regards > >> Brian > >> > >> On 27/06/2017 16:21, Toerless Eckert wrote: > >>> Thanks a lot, Sheng! > >>> > >>> Integrated fixes for all comments (see inline discuss below). Pushed stable connectivity draft > >>> into www.github.com/anima-wg/autonomic-control-plane together with ACP draft because i ended up > >>> having to do a fix for the ACP draft as a result of your comments. > >>> > >>> Diff between -02 and fixed up stable connectivity draft here: > >>> > >>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt > >>> > >>> If you are fine with the fixes let me know, and i'll push it to datatracker as -03. > >>> > >>> If not ok. feel free to use email or now also add issue to the git. > >>> > >>> Raw txt/git files of fixed stable connectivity text: > >>> > >>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt > >>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml > >>> > >>> Diff for change done in ACP (explaining ACP connect better): > >>> > >>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt > >>> > >>> Cheers > >>> Toerless > >>> > >>> On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: > >>>> Hi, authors of draft-ietf-anima-stable-connectivity, > >>>> > >>>> I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. > >>>> > >>>> First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It would be an unlike scenario to manage an IPv6 network (all managed devices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the NAT64 setup in this scenario is complex, and connectivity between IPv4 only NOC application devices and NAT is unsecure. I would suggest to reduce the whole section or add a clear statement that it is a not-recommended scenario at the end of this section. > >>> > >>> Yes, it is a mess. But it is documenting an actual deployment experience with an enterprise > >>> customer. TAnd my understanding is tht it would be a quite common scenario for enterprises. There > >>> was just recently a very nice RTG area WG chair tutorial that to me reconfirmed the ongoing > >>> challenges with IPv6 only management planes. > >>> > >>> I have added paragraphs to justify the need for this section and that its all undesirable workarounds > >>> Please check. To me, this messy section is the price we have to pay so that the ACP > >>> can simply be IPv6 only. Its a price i am happy to pay. > >>> > >>>> Secondly, the description and category in section 2.1.2, "Limitations and enhancement overview". For me, only the point 1 & 3 are really limitation of ACP itself. > >>> > >>> I have improved the text and categorization in this chapter to make it hopefully clearer to read and to be more precise in terminology. > >>> > >>>> Point 2 is a precondition (it is actually conflicted with section 2.1.4.) > >>> > >>> Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that is a challenge for which there is a workaround. Those workarounds are described in section 2.1.4. I've tried to improve all that text. I do not understand why point 2 would be a conflict with section 2.1.4 instead of rather pointing to 2.1.4. > >>> > >>>> I don't understand point 4. What does "exposing the ACP natively" mean? > >>> > >>> That is the term that was defined in ACP CP draft, section 6.1. Reading through that section, i improved it in the ACP section, and i updated the text about it in stable connectivity. > >>> > >>> Oh, and this change had me change the term "NOC application device" to "NMS host" throughout the document because that is the term used in the ACP draft. > >>> > >>>> Thirdly, I have issues to use names to distinguish the path selection policies. > >>>> This is a chicken&egg issue in the autonomic scenario. > >>>> Who and how the DNS names are setup, by human administrator? > >>> > >>> IMHO, considerations for names are one of the most crucial part of > >>> operationalizing the ACP. The little text we have about the ACP is IMHO > >>> a good compromise between overlooking the problem and writing a lot more > >>> text. > >>> > >>> The concept of using different addresses for a device for different actions > >>> is not novel to ACP. Think of using a loopback to "reliably" talk to a router > >>> vs. ping'ing specific interface addresses of a router to discover whether > >>> an peer (reachable via that interface) is up/down. If you look at service > >>> providers name setups (often in DNS), then they will have different names > >>> for those different addresses and use those different names in the different > >>> tools. The text in this draft simply explains the same concept for > >>> ACP vs. other addresses. > >>> > >>> DNS names can be setup by various locally built automation scripting or templates. > >>> Same think for DNS names for ACP. Operators will likely point out that automating > >>> the DNS name creation is more difficult because we do not use topology/semantic > >>> ACP addresses, but in principle it's the same automation task. > >>> > >>>> If there is a mechanism to distinguish the IP addresses of ACP and data-plane without human intelligence, why does it bore to use DNS? > >>> > >>> ALl the existing "actions" that you want to do for a device are just too stupid: > >>> They do not include the logic of knowing which address is best for them to > >>> use. That's why you use names for subsets of the possible addresses to allow > >>> you to specify exatly those address(es) that will reach the device via the > >>> network connection matching the intent of the action you're taking. > >>> > >>>> DNS registration & lookup by itself is a very complex and time-consumption procedure. > >>> > >>> Depends on your automation. Its certainly an interesting aspect especially moving > >>> from IPv4 to IPv6 where embedding logic into adresses becomes a whole different > >>> ballgame. > >>> > >>>> If we don't want to show the semantic of these addresses to any human, names are meaningless. > >>> > >>> But you need new NOC tools where each action would need to know what type > >>> of connection is best for it. > >>> > >>> I have added one paragraph to 2.1.5 to outline this logic and justification for why > >>> to describe DNS. Look for "Ideally, a NOC system would learn and keep track of all addresses of a device" > >>> > >>> > >>>> In section 2.2, "The ACP can provide common direct-neighbor discovery and capability negotiation". This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP. > >>> > >>> Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP protocol common direct-neighbor > >>> discovery and capability negotiation (GRASP via ACP and/or data-plane) and stable and secure > >>> connectivity for functions running distributed in network devices (GRASP via ACP). > >>> > >>>> At the end of section 2.1.3, "A simple short-term workaround could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. Personally, I believe this could be done by a virtual loopback interface. > >>> > >>> Ack. Changed text to: A workaround without additional software functionality could be a physical external loopback > >>> cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture. A (virtual) > >>> software loopback between the ACP and data plane VRF would of course be the better solution. > >>> > >>> The key notion why the "gross" physcial loopback may be appreciated is because it doesn't require software work. Or specification of the behavior of such a software loopback in the roting behavior in the ACP draft. I would love to have that software loopback, but i think we (ACP doc authors) felt that we wanted to keep the ACP spec lightweight enough to be implementable without all possible enhancements. But i hope its fine to mention the option here in this document as you suggested. > >>> > >>>> Section 3, "Security considerations" is more like a deployment considerations. Both ULA-C and reverse DNS are additional deployment > >>> > >>> Yes, but i think if you look through various IETF documents you will see that it is quite common for security consideration sections to outline additional steps to secure the documents work goal especially when those steps are otherwise orthogonal to the documents spec (eg: leverage existing components). > >>> > >>> Whats the process for informational documents. It will get SEC AD review, right ? Maybe hold that thought for that review ? Or else i can proactively ask, because right now i am a bit at a loss whats the right limit of what to put into sec considerations vs. what to extract into a separate chapter. > >>> > >>>> Minor comments, > >>>> > >>>> Section 2.1.6, "Autonomic NOC device/applications" should be moved to early part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess. > >>> > >>> The text unfortunately builds up in the order it is written, so it would be a lot of rewrite to make sure it would still read after such a reordering. Instead i have added the following as the first paragraph: > >>> > >>> This section describes stable connectibity for centralized OAM operations via ACP/ANI > >>> starting by what we expect to be the most likely easiest short-term deployment option. It > >>> then describes limitation/challenges of that approach and their solutions/workarounds to finish > >>> with the preferred target option of autonomic NOC devices in . > >>> > >>> This order was choosen because it helps to explain how simple one can start using the ACP, > >>> how difficult workarounds can become (and therefore what to avoid), and finally because one very > >>> promising long-term solution alternative is exactly like the most easy short-term solution only virtualized > >>> and automated. > >>> > >>> The last sentence is that punchline: The likely easiest/best atonomic NOC device solution is one where you do everything you do in the short-term approach, just virtualized and integrated into the NOC device. WHich means you'd need to explain all that stuff anyhow... > >>> > >>>> It is worth of mentioning even the ACP provides only IPv6 connectivity, through it, IPv4 configuration or even non-IP configuration could be managed. > >>> > >>> Good point. Added the following sentence: > >>> > >>> Note that even though the ACP only uses IPv6, it can and should be used to providestable connectivity for management of any network: IPv4 only, dual-stack or IPv6 only. > >>> > >>>> The document does not properly quota references in the text. The references defined are mostly not used. > >>> > >>> Ack. Removed unnecessary references, introduced terms/references in the beginning of the document. All references now used at least once ;-) > >>> > >>>> The document separate sections for Informative/Normative References > >>> > >>> Hmm. It DOES NOT distinguish between normative and informational documents because i thought that an informational document like this could not have normative references. If it can and should have them let me know, then i'll make Bootstrap/Grasp/ACP normative and reference/definitions informational. > >>> > >>>> The empty section 5 "Further considerations", should be removed. > >>> > >>> Done. > >>> > >>>> Most of references are out of date. behringer-anima-reference-model > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-network-definitions > RFC 7575. > >>> > >>> Fixed. > >>> > >>>> In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the infrastructure design." What is the mean for "other mayor"? > >>> > >>> added: Examples include change of IGP protocols or areas, PD (Provider > >>> Dependent) to PI (Provider Independent) addressing, systematic topology changes. > >>> > >>>> In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may be better to presented as "the Autonomic Control plane (ACP) in Autonomic Networks" > >>> > >>> Done > >>> > >>>> There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section 2.1.5, "KARP" in section 2.2, even the first appearances. > >>> > >>> Done, added RFC references for those TLAs that have them as well. > >>> > >>>> Last sentence of section 2.2 should be removed. > >>> > >>> Done. > >>> > >>>> In section 3, first sentence, add "In this section," > >>> > >>> Done. > >>> > >>>> There are typos, needed to be fixed too: > >>>> > >>>> Two "the the" in the end of section 2.1.2 and end of section 4; > >>> > >>> Done > >>>> > >>>> A couple of "randomn" -> "random"; > >>> > >>> Done > >>>> > >>>> "networ" in section 2.1.5; > >>> > >>> Done > >>>> > >>>> "jut" -> "just" at the end of section 2.1.6, I guess. > >>>> > >>>> "The most simple" -> "the simplest" in section 2.17. > >>> > >>> Done. > >>> > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de From nobody Wed Jul 5 16:48:01 2017 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 B3EF81274D2 for ; Wed, 5 Jul 2017 16:47:59 -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, RP_MATCHES_RCVD=-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 9f-40t7lVT0K for ; Wed, 5 Jul 2017 16:47:56 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB90127286 for ; Wed, 5 Jul 2017 16:47:56 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5AC5958C4C5; Thu, 6 Jul 2017 01:47:52 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 42234B0C4CD; Thu, 6 Jul 2017 01:47:52 +0200 (CEST) Date: Thu, 6 Jul 2017 01:47:52 +0200 From: Toerless Eckert To: Artur Hecker Cc: "anima@ietf.org" Message-ID: <20170705234750.GD14122@faui40p.informatik.uni-erlangen.de> References: <8DA547FB1280754AAC43A3E56DCB7AD20AE9BF3C@lhreml501-mbx> <5b4d5e34-e904-e2e6-18b1-06978b62bf95@gmail.com> <8DA547FB1280754AAC43A3E56DCB7AD20AE9D029@lhreml501-mbx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AE9D029@lhreml501-mbx> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Object store and PubSub model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 23:47:59 -0000 Artur: pubsub and object store seem to be (to me) two hot buzzwords, but i am not aware (ENOCYCLES) what the IETF is currently doing about those. It would certainly be interesting for the ANIMA-WG to see proposals of work in the area with good motivation why this work would be particularily be suited to ANIMA. [this does not mean that we'd have time in the WG slot in Prague though, Sheng is managing the time there ;-)] I think its overall a very wide field, and i'd primarily look for precise use case examples and specific justifications why something is best done in ANIMA. Example: a) Justification: existing requirement in ANIMA, pubsub/object-store to the rescue: We need in ANIMA intent distribution, that would be a use-case. If there is anything existing from IETF or other bodies that would allow to do this, (whether or not that is some pubsub bus or object store), then that would be highly worth to bring up in ANIMA. Main issue is that we have no clear agreement on what intent is. IMHO it could be along what the current (not WG item) intent draft says, but maybe we need to even call it differently (not intent). See of course also grasp-information-distribution (which is more a cateogrization of requirements than a solution). b) Justification: build it autonomously: There are a lot of pubsub buses today, but i am not aware of any bus where the distribution infra of those buses is autonomously set up. Except when they simple flooding buseses. All the other buses i know seem to have some manually provisioned infra like brokers or the like. So IMHO any proposal to autonmously create a bus that is better than flooding would IMHO a great idea for ANIMA. But i am also not sure if there is a realistic option to autonomously create a good distributed bus infra. In between "everything is centralized" and "flooding&storage everywhere" there are so many aspects of optimiation that its IMHO almost impossible to figure out a generic solution that almost automatically adopts itself to the best shape pending on a particular use-case. And i am saying this with just boring information distribution background called multicast. Not to mention CCN/ICN. Cheers Toerless On Thu, Jun 29, 2017 at 03:28:08PM +0000, Artur Hecker wrote: > Dear Brian, all > > > Thanks a lot for the explanations. Please find my answers below: > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 28 June 2017 22:35 > To: Artur Hecker; anima@ietf.org > Subject: Re: [Anima] Object store and PubSub model > > > So far, I don't believe we've discussed distributed storage as such. It would be a natural part of the discussion of > > intent. We have tended to assume that intent originates centrally, so it needs a replication model rather than > > distributed storage in the general sense. The simplest replication model is of course flooding, which we > > already have for relatively small data objects. For example, GRASP as it exists today could flood an objective whose > > value is the URL of the latest intent for the whole network. > > [[AH] ] Ok, very clear, thanks. Would you welcome such a discussion e.g. for the re-chartering of ANIMA? > > We believe that network-wide storage could be of high value for autonomous networking, just as routing is. The reasons for this are, among others: > > c) given the existing ANIMA descriptions, I believe that limited storage is presumed available on all nodes (i.e. at least to store that URL in your example); > b) the APIs for data object storage are well-established and compact (put(), get()); > a) the information a node might need to store is not necessarily limited to the scope of that single node. Therefore, an efficient capability to access network-wide information (e.g. configuration data, network-wide intents, network-wide averages or aggregates of data) would really be of a value. If every application has to redo it, we run the risk of repetitive wheel reinventions - or flooding. Essentially, as you just hinted, if we do not provide these means (either by a mandatory ASA or over the ANIMA API), then every developer will have to revert to flooding at least for the first message. While this might be assumed rare for intents, I am not sure we can claim this for every individual application scenario. > > > > I would not advocate developing a distributed storage model specific to Anima. Rather, if we decided it was > > necessary, IMHO we should adopt an existing solution, since this is not a trivial problem. > > [[AH] ] Agreed, and it was not intended. If there is a perceived consensus of the value of this, we would rather see how to integrate/adopt a suitable solution. > > > >> 2. In a similar vein, does a publish/subscribe information distribution model, built upon an underlying storage, > >> look promising and relevant to the group? Can GRASP support that or will it require extensions? The pub/sub is, > >> in our opinion, a more general information distribution model than what we saw in the current work stream. Yet, > >> before submitting a draft that details such a model, we wanted to kindly ask for your opinion on that. > > > Have you studied draft-liu-anima-grasp-distribution? > [[AH] ] Yes, that was where our motivation came from. It seems to be based on the flooding/replication model. Which is fine for some scenarios, but which also has known limitations. The idea was to allow for a more general model, considered to be better for scalability, etc. > > > But first, what sort of autonomic use cases would require distributed storage or a pub/sub solution? > > [[AH] ] Any example under a) above or our original example of ECA type of intent, which would require to "ripen" before being executed. The exact condition could be something that an individual node might not know, e.g. "close the blinds when the temperature in the building exceeds 25 C (=77F)". > > > > Regards > artur > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 5 16:56:33 2017 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 DDA6E131475 for ; Wed, 5 Jul 2017 16:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 daffGV4146FG for ; Wed, 5 Jul 2017 16:56:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EE1127286 for ; Wed, 5 Jul 2017 16:56:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJV06078; Wed, 05 Jul 2017 23:56:27 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Jul 2017 00:56:26 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Wed, 5 Jul 2017 16:56:17 -0700 From: Alexander Clemm To: Toerless Eckert , Artur Hecker CC: "anima@ietf.org" Thread-Topic: [Anima] Object store and PubSub model Thread-Index: AdLwIHL21vHVoA6MR0+KzxxjTjov+wAaEIKAACeRqQABPzOVAAAOhc7w Date: Wed, 5 Jul 2017 23:56:17 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0C0786@SJCEML702-CHM.china.huawei.com> References: <8DA547FB1280754AAC43A3E56DCB7AD20AE9BF3C@lhreml501-mbx> <5b4d5e34-e904-e2e6-18b1-06978b62bf95@gmail.com> <8DA547FB1280754AAC43A3E56DCB7AD20AE9D029@lhreml501-mbx> <20170705234750.GD14122@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170705234750.GD14122@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.595D7CAB.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4aa315bfbac9491ef4d0f98b77fe9ca5 Archived-At: Subject: Re: [Anima] Object store and PubSub model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 23:56:32 -0000 I can think of several use cases where such a capability would be useful. = =20 One such use case is documented in https://tools.ietf.org/html/draft-irtf-n= mrg-autonomic-sla-violation-detection-10. This concerns a use case to coor= dinate service level measurements among nodes in a network. To come to bet= ter autonomic decisions, nodes need more information, specifically data of = observations (in that case) made by other nodes. I would expect this to be = a very common design pattern for many distributed autonomic applications, r= unning in Autonomic Services Agents that are not "isolated" to their contai= ning node, but that share information in order to each individually be able= to make better decisions. =20 Having pub-sub infrastructure will facilitate the development of such appli= cations. =20 --- Alex -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert Sent: Wednesday, July 05, 2017 4:48 PM To: Artur Hecker Cc: anima@ietf.org Subject: Re: [Anima] Object store and PubSub model Artur: pubsub and object store seem to be (to me) two hot buzzwords, but i = am not aware (ENOCYCLES) what the IETF is currently doing about those. It w= ould certainly be interesting for the ANIMA-WG to see proposals of work in = the area with good motivation why this work would be particularily be suite= d to ANIMA. [this does not mean that we'd have time in the WG slot in Pragu= e though, Sheng is managing the time there ;-)] I think its overall a very wide field, and i'd primarily look for precise u= se case examples and specific justifications why something is best done in = ANIMA.=20 Example: a) Justification: existing requirement in ANIMA, pubsub/object-store to the= rescue: We need in ANIMA intent distribution, that would be a use-case. If there= is anything existing from IETF or other bodies that would allow to do this, (whether= or not that is some pubsub bus or object store), then that would be highly wort= h to bring up in ANIMA. Main issue is that we have no clear agreement on what intent i= s. IMHO it could be along what the current (not WG item) intent draft says, but may= be we need to even call it differently (not intent). See of course also grasp-informat= ion-distribution (which is more a cateogrization of requirements than a solution). b) Justification: build it autonomously: There are a lot of pubsub buses today, but i am not aware of any bus whe= re the distribution infra of those buses is autonomously set up. Except when they simple flo= oding buseses. All the other buses i know seem to have some manually provisioned infra = like brokers or the like. So IMHO any proposal to autonmously create a bus that is bette= r than flooding would IMHO a great idea for ANIMA. =20 But i am also not sure if there is a realistic option to autonomously cr= eate a good distributed bus infra. In between "everything is centralized" and "flood= ing&storage everywhere" there are so many aspects of optimiation that its IMHO almos= t impossible to figure out a generic solution that almost automatically adopts itself= to the best shape pending on a particular use-case. And i am saying this with just b= oring information distribution background called multicast. Not to mention CCN= /ICN. Cheers Toerless On Thu, Jun 29, 2017 at 03:28:08PM +0000, Artur Hecker wrote: > Dear Brian, all >=20 >=20 > Thanks a lot for the explanations. Please find my answers below: >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 28 June 2017 22:35 > To: Artur Hecker; anima@ietf.org > Subject: Re: [Anima] Object store and PubSub model >=20 > > So far, I don't believe we've discussed distributed storage as such.=20 > > It would be a natural part of the discussion of intent. We have=20 > > tended to assume that intent originates centrally, so it needs a=20 > > replication model rather than distributed storage in the general=20 > > sense. The simplest replication model is of course flooding, which we a= lready have for relatively small data objects. For example, GRASP as it exi= sts today could flood an objective whose value is the URL of the latest int= ent for the whole network. >=20 > [[AH] ] Ok, very clear, thanks. Would you welcome such a discussion e.g. = for the re-chartering of ANIMA? >=20 > We believe that network-wide storage could be of high value for autonomou= s networking, just as routing is. The reasons for this are, among others: >=20 > c) given the existing ANIMA descriptions, I believe that limited=20 > storage is presumed available on all nodes (i.e. at least to store=20 > that URL in your example); > b) the APIs for data object storage are well-established and compact=20 > (put(), get()); > a) the information a node might need to store is not necessarily limited = to the scope of that single node. Therefore, an efficient capability to acc= ess network-wide information (e.g. configuration data, network-wide intents= , network-wide averages or aggregates of data) would really be of a value. = If every application has to redo it, we run the risk of repetitive wheel re= inventions - or flooding. Essentially, as you just hinted, if we do not pro= vide these means (either by a mandatory ASA or over the ANIMA API), then ev= ery developer will have to revert to flooding at least for the first messag= e. While this might be assumed rare for intents, I am not sure we can claim= this for every individual application scenario. >=20 >=20 > > I would not advocate developing a distributed storage model specific=20 > > to Anima. Rather, if we decided it was > > necessary, IMHO we should adopt an existing solution, since this is no= t a trivial problem. >=20 > [[AH] ] Agreed, and it was not intended. If there is a perceived consensu= s of the value of this, we would rather see how to integrate/adopt a suitab= le solution. >=20 > =20 > >> 2. In a similar vein, does a publish/subscribe information=20 > >> distribution model, built upon an underlying storage, look=20 > >> promising and relevant to the group? Can GRASP support that or will=20 > >> it require extensions? The pub/sub is, in our opinion, a more general = information distribution model than what we saw in the current work stream.= Yet, before submitting a draft that details such a model, we wanted to kin= dly ask for your opinion on that. >=20 > > Have you studied draft-liu-anima-grasp-distribution? > [[AH] ] Yes, that was where our motivation came from. It seems to be base= d on the flooding/replication model. Which is fine for some scenarios, but = which also has known limitations. The idea was to allow for a more general = model, considered to be better for scalability, etc. >=20 > > But first, what sort of autonomic use cases would require distributed s= torage or a pub/sub solution? >=20 > [[AH] ] Any example under a) above or our original example of ECA type of= intent, which would require to "ripen" before being executed. The exact co= ndition could be something that an individual node might not know, e.g. "cl= ose the blinds when the temperature in the building exceeds 25 C (=3D77F)". >=20 >=20 >=20 > Regards > artur >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 5 18:27:31 2017 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 65B58129AC1 for ; Wed, 5 Jul 2017 18:27:28 -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 Ac9XLHOE48fG for ; Wed, 5 Jul 2017 18:27:25 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 E9E3512EC3D for ; Wed, 5 Jul 2017 18:27:24 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id u62so2990915pgb.3 for ; Wed, 05 Jul 2017 18:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NPJqyhNz80NYnZxXVaCKoyCkTgvpQ8XDFGtXmSmTf58=; b=csjg1xuL7eG12neQLzlYHpB5q+LrrD/bynI8MLB71AOYiKz9j652/QoffBiQA7aNlb 0FYcnwOt0invk5YZni6Yx3skmVhDKOEQE9ZeJlsGxJeq0ZCyYNqdAilU9ojkjUGxq0rE l1Te6gOk/8fAe4zpxd1GnuYsGCPv+SkU7/CiB8sOhHJ6ROzwwjEEzI3h+Yg17mubQmZP rA8iVAK7VwHA8snheiY+gk5OgvgzxVvxHjmXSU2ovilxUMVLTdmjKpEopeoRkdncMQUc 2GrXtCJcx63dLWu40Fo0arRpfERdLBQZCB8ZTxTmatGy+ZMAzVg4gGMp7rUcOvjR+yvx +LNg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=NPJqyhNz80NYnZxXVaCKoyCkTgvpQ8XDFGtXmSmTf58=; b=ZBJFseLbue7Sgl3Z6tgSO7Q4++RFaQOMSFkv7q858YuS8KwznUn6Rq6PGWqrFqoqTh LNtjBAtVzYM6czrEuSKsagUhVBB/5rF6NQBXQtvOBt9hudZNvW1E2p1z4Z5msdS+uaNc xA78mpSeyVs043i3Vf1OT3vDROkyUAq+6IgtxrvnbmkIweakeFzMil42fwl2sObAvmgY ld2n4wTTB6rZMyBUqP3z13k0XcIip4W7x4lLjYSo61bIjIzBNoA7+e9gyGVU+Gq3oaGg 2RBpCCyveBoOBjJctWmR14l1Igkgpyrs6X9HC7vFSbl4JvgACKMPAmwYOQ7GxdwhqUBG nhmw== X-Gm-Message-State: AIVw113xta5yo+mFl4rHEFb/4k/DODXucEp4zF58iqFOjCvpNE9lzoSL VZJBAYo5mdjJix1e X-Received: by 10.84.132.106 with SMTP id 97mr9556493ple.105.1499304444093; Wed, 05 Jul 2017 18:27:24 -0700 (PDT) Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k18sm583404pgf.5.2017.07.05.18.27.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 18:27:23 -0700 (PDT) To: Toerless Eckert Cc: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> <20170703235944.GD12926@faui40p.informatik.uni-erlangen.de> <20170705231356.GC14122@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <21594b53-38ac-8bcc-1ff6-530bf0d0f677@gmail.com> Date: Thu, 6 Jul 2017 13:27:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170705231356.GC14122@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 01:27:28 -0000 On 06/07/2017 11:13, Toerless Eckert wrote: > On Tue, Jul 04, 2017 at 12:23:13PM +1200, Brian E Carpenter wrote: >> Toerless, >> >>> I actually expanded on the text to represent the whole M_FLOOD message format >>> because i always found it highly irritating having to switch between the >>> taget draft (ACP etc.) and the GRASP draft to really see whats in the whole >>> message. >> >> I have mixed feelings about that, because of the obvious scope >> for error, and the general risk of duplicating material between >> documents. In any case, we need to check it in great detail. >> (The best check would be to make and debug a demo implementation, >> dump the actual packets, and check that they correspond.) > > See other mail thread about BRSKI. > >> This is actually why we also need consensus on the GRASP API. >> It's much easier to verify a use case against the API than to >> work out message details. > > Moving from protocol descriptions to API ? A small step for Brian > but a giant leap of faith for IETF ? Indeed. It sometimes seems that the IETF wants to pretend that there are no operating systems or programming languages. > Aka: > 1. right now i didn't want BRSKI/ACP to refer to an API thats further out > from RFC than the protocol spec. I agree, I don't want that to be normative, it's just a very useful tool. > 2. I am not aware of BCP in the IETF to refer to APIs given how little > APIs the IETF has standardized, so i am a bit reluctant at this stage > in ANIMA to explore even more long term good things as scouts. If you > have pointers to other docs referring to other APIs defined by IETF > in a normative fashion, that would help aleviate that anxiety quite a bit. > > 3. Given how GRASP itself is not widely deployed, i do like the additional > cross-checking/validation we get by looking at the whole packet right now. > We already figured out the need to carry ports in GRASP IMHO because of > exactly this view - instead of just trusing APIs. Yes. But the quickest way I have to generate packets is to run my code with grasp.test_mode = True ;-) Brian > > Aka: I'd be happy to ask authors (including myself) to refer to only GRASP > APIs for any drafts that would have the same (or slower_ timeline as > GRASP API. And to put GRASP API on fast-track (as much as we can). > > Cheers > Toerless > >> Regards >> Brian >> >> On 04/07/2017 11:59, Toerless Eckert wrote: >>> On Thu, Jun 29, 2017 at 02:44:14PM +1200, Brian E Carpenter wrote: >>>> I had a look at both sets of changes and they seem good to me. >>> >>> Thanks. The reviewed document was just pushed as -03 to datatracker, see other emails. >>> >>>> I find myself wondering, after seeing the slightly confused text >>>> about GRASP objectives in the latest BRSKI, and noting the absence >>>> of such objectives in the ACP and stable-connectivity drafts, whether >>>> we should accept that we need a specialised draft for all the >>>> GRASP objectives needed by the ANI. >>> >>> I am still working through the last two IETFs agreement that we need to update >>> BRSKI and ACP drafts to allow dissolving of the ani-objectives (and use it as >>> the starting point). >>> >>> The BRSKI changes for this are still in a github branch we have not gotten through >>> to merge into the main branch due to prioritizing voucher work first (get thast >>> through last call). >>> >>> The ACP draft changes to introduce the ani-objectives proposed GRASP objective >>> details are included in the -07 ACP draft that i also just submitted. >>> >>> I actually expanded on the text to represent the whole M_FLOOD message format >>> because i always found it highly irritating having to switch between the >>> taget draft (ACP etc.) and the GRASP draft to really see whats in the whole >>> message. >>> >>> Wrt to GRASP in stable connectivity, i think we should try to also finish up this >>> draft, the ideas how else NOC and ANI can be integrated is for both time and >>> other reasons better done in a followup draft: Another such reason could be >>> to introduce those GRASP objectives/functions as a standards strack document >>> (stable connectivity is just informational target). >>> >>> Cheers >>> Toerless >>> >>>> Strangely enough, we have such a draft already: >>>> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01 >>>> My idea was for this to be a temporary draft, with its contents >>>> being moved into BSRKI, ACP and stable-connectivity. But would it >>>> be more practical to keep it as a separate draft? It makes the other >>>> three drafts a bit more self-contained, and allows for a consistent >>>> definition of the infrastructure objectives. >>>> >>>> What to do people think? >>>> >>>> (Disregard the current details in draft-carpenter-anima-ani-objectives, >>>> which has not been updated recently.) >>>> >>>> Regards >>>> Brian >>>> >>>> On 27/06/2017 16:21, Toerless Eckert wrote: >>>>> Thanks a lot, Sheng! >>>>> >>>>> Integrated fixes for all comments (see inline discuss below). Pushed stable connectivity draft >>>>> into www.github.com/anima-wg/autonomic-control-plane together with ACP draft because i ended up >>>>> having to do a fix for the ACP draft as a result of your comments. >>>>> >>>>> Diff between -02 and fixed up stable connectivity draft here: >>>>> >>>>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt >>>>> >>>>> If you are fine with the fixes let me know, and i'll push it to datatracker as -03. >>>>> >>>>> If not ok. feel free to use email or now also add issue to the git. >>>>> >>>>> Raw txt/git files of fixed stable connectivity text: >>>>> >>>>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt >>>>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml >>>>> >>>>> Diff for change done in ACP (explaining ACP connect better): >>>>> >>>>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt >>>>> >>>>> Cheers >>>>> Toerless >>>>> >>>>> On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: >>>>>> Hi, authors of draft-ietf-anima-stable-connectivity, >>>>>> >>>>>> I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. >>>>>> >>>>>> First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It would be an unlike scenario to manage an IPv6 network (all managed devices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the NAT64 setup in this scenario is complex, and connectivity between IPv4 only NOC application devices and NAT is unsecure. I would suggest to reduce the whole section or add a clear statement that it is a not-recommended scenario at the end of this section. >>>>> >>>>> Yes, it is a mess. But it is documenting an actual deployment experience with an enterprise >>>>> customer. TAnd my understanding is tht it would be a quite common scenario for enterprises. There >>>>> was just recently a very nice RTG area WG chair tutorial that to me reconfirmed the ongoing >>>>> challenges with IPv6 only management planes. >>>>> >>>>> I have added paragraphs to justify the need for this section and that its all undesirable workarounds >>>>> Please check. To me, this messy section is the price we have to pay so that the ACP >>>>> can simply be IPv6 only. Its a price i am happy to pay. >>>>> >>>>>> Secondly, the description and category in section 2.1.2, "Limitations and enhancement overview". For me, only the point 1 & 3 are really limitation of ACP itself. >>>>> >>>>> I have improved the text and categorization in this chapter to make it hopefully clearer to read and to be more precise in terminology. >>>>> >>>>>> Point 2 is a precondition (it is actually conflicted with section 2.1.4.) >>>>> >>>>> Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that is a challenge for which there is a workaround. Those workarounds are described in section 2.1.4. I've tried to improve all that text. I do not understand why point 2 would be a conflict with section 2.1.4 instead of rather pointing to 2.1.4. >>>>> >>>>>> I don't understand point 4. What does "exposing the ACP natively" mean? >>>>> >>>>> That is the term that was defined in ACP CP draft, section 6.1. Reading through that section, i improved it in the ACP section, and i updated the text about it in stable connectivity. >>>>> >>>>> Oh, and this change had me change the term "NOC application device" to "NMS host" throughout the document because that is the term used in the ACP draft. >>>>> >>>>>> Thirdly, I have issues to use names to distinguish the path selection policies. >>>>>> This is a chicken&egg issue in the autonomic scenario. >>>>>> Who and how the DNS names are setup, by human administrator? >>>>> >>>>> IMHO, considerations for names are one of the most crucial part of >>>>> operationalizing the ACP. The little text we have about the ACP is IMHO >>>>> a good compromise between overlooking the problem and writing a lot more >>>>> text. >>>>> >>>>> The concept of using different addresses for a device for different actions >>>>> is not novel to ACP. Think of using a loopback to "reliably" talk to a router >>>>> vs. ping'ing specific interface addresses of a router to discover whether >>>>> an peer (reachable via that interface) is up/down. If you look at service >>>>> providers name setups (often in DNS), then they will have different names >>>>> for those different addresses and use those different names in the different >>>>> tools. The text in this draft simply explains the same concept for >>>>> ACP vs. other addresses. >>>>> >>>>> DNS names can be setup by various locally built automation scripting or templates. >>>>> Same think for DNS names for ACP. Operators will likely point out that automating >>>>> the DNS name creation is more difficult because we do not use topology/semantic >>>>> ACP addresses, but in principle it's the same automation task. >>>>> >>>>>> If there is a mechanism to distinguish the IP addresses of ACP and data-plane without human intelligence, why does it bore to use DNS? >>>>> >>>>> ALl the existing "actions" that you want to do for a device are just too stupid: >>>>> They do not include the logic of knowing which address is best for them to >>>>> use. That's why you use names for subsets of the possible addresses to allow >>>>> you to specify exatly those address(es) that will reach the device via the >>>>> network connection matching the intent of the action you're taking. >>>>> >>>>>> DNS registration & lookup by itself is a very complex and time-consumption procedure. >>>>> >>>>> Depends on your automation. Its certainly an interesting aspect especially moving >>>>> from IPv4 to IPv6 where embedding logic into adresses becomes a whole different >>>>> ballgame. >>>>> >>>>>> If we don't want to show the semantic of these addresses to any human, names are meaningless. >>>>> >>>>> But you need new NOC tools where each action would need to know what type >>>>> of connection is best for it. >>>>> >>>>> I have added one paragraph to 2.1.5 to outline this logic and justification for why >>>>> to describe DNS. Look for "Ideally, a NOC system would learn and keep track of all addresses of a device" >>>>> >>>>> >>>>>> In section 2.2, "The ACP can provide common direct-neighbor discovery and capability negotiation". This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP. >>>>> >>>>> Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP protocol common direct-neighbor >>>>> discovery and capability negotiation (GRASP via ACP and/or data-plane) and stable and secure >>>>> connectivity for functions running distributed in network devices (GRASP via ACP). >>>>> >>>>>> At the end of section 2.1.3, "A simple short-term workaround could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. Personally, I believe this could be done by a virtual loopback interface. >>>>> >>>>> Ack. Changed text to: A workaround without additional software functionality could be a physical external loopback >>>>> cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture. A (virtual) >>>>> software loopback between the ACP and data plane VRF would of course be the better solution. >>>>> >>>>> The key notion why the "gross" physcial loopback may be appreciated is because it doesn't require software work. Or specification of the behavior of such a software loopback in the roting behavior in the ACP draft. I would love to have that software loopback, but i think we (ACP doc authors) felt that we wanted to keep the ACP spec lightweight enough to be implementable without all possible enhancements. But i hope its fine to mention the option here in this document as you suggested. >>>>> >>>>>> Section 3, "Security considerations" is more like a deployment considerations. Both ULA-C and reverse DNS are additional deployment >>>>> >>>>> Yes, but i think if you look through various IETF documents you will see that it is quite common for security consideration sections to outline additional steps to secure the documents work goal especially when those steps are otherwise orthogonal to the documents spec (eg: leverage existing components). >>>>> >>>>> Whats the process for informational documents. It will get SEC AD review, right ? Maybe hold that thought for that review ? Or else i can proactively ask, because right now i am a bit at a loss whats the right limit of what to put into sec considerations vs. what to extract into a separate chapter. >>>>> >>>>>> Minor comments, >>>>>> >>>>>> Section 2.1.6, "Autonomic NOC device/applications" should be moved to early part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess. >>>>> >>>>> The text unfortunately builds up in the order it is written, so it would be a lot of rewrite to make sure it would still read after such a reordering. Instead i have added the following as the first paragraph: >>>>> >>>>> This section describes stable connectibity for centralized OAM operations via ACP/ANI >>>>> starting by what we expect to be the most likely easiest short-term deployment option. It >>>>> then describes limitation/challenges of that approach and their solutions/workarounds to finish >>>>> with the preferred target option of autonomic NOC devices in . >>>>> >>>>> This order was choosen because it helps to explain how simple one can start using the ACP, >>>>> how difficult workarounds can become (and therefore what to avoid), and finally because one very >>>>> promising long-term solution alternative is exactly like the most easy short-term solution only virtualized >>>>> and automated. >>>>> >>>>> The last sentence is that punchline: The likely easiest/best atonomic NOC device solution is one where you do everything you do in the short-term approach, just virtualized and integrated into the NOC device. WHich means you'd need to explain all that stuff anyhow... >>>>> >>>>>> It is worth of mentioning even the ACP provides only IPv6 connectivity, through it, IPv4 configuration or even non-IP configuration could be managed. >>>>> >>>>> Good point. Added the following sentence: >>>>> >>>>> Note that even though the ACP only uses IPv6, it can and should be used to providestable connectivity for management of any network: IPv4 only, dual-stack or IPv6 only. >>>>> >>>>>> The document does not properly quota references in the text. The references defined are mostly not used. >>>>> >>>>> Ack. Removed unnecessary references, introduced terms/references in the beginning of the document. All references now used at least once ;-) >>>>> >>>>>> The document separate sections for Informative/Normative References >>>>> >>>>> Hmm. It DOES NOT distinguish between normative and informational documents because i thought that an informational document like this could not have normative references. If it can and should have them let me know, then i'll make Bootstrap/Grasp/ACP normative and reference/definitions informational. >>>>> >>>>>> The empty section 5 "Further considerations", should be removed. >>>>> >>>>> Done. >>>>> >>>>>> Most of references are out of date. behringer-anima-reference-model > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-network-definitions > RFC 7575. >>>>> >>>>> Fixed. >>>>> >>>>>> In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the infrastructure design." What is the mean for "other mayor"? >>>>> >>>>> added: Examples include change of IGP protocols or areas, PD (Provider >>>>> Dependent) to PI (Provider Independent) addressing, systematic topology changes. >>>>> >>>>>> In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may be better to presented as "the Autonomic Control plane (ACP) in Autonomic Networks" >>>>> >>>>> Done >>>>> >>>>>> There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section 2.1.5, "KARP" in section 2.2, even the first appearances. >>>>> >>>>> Done, added RFC references for those TLAs that have them as well. >>>>> >>>>>> Last sentence of section 2.2 should be removed. >>>>> >>>>> Done. >>>>> >>>>>> In section 3, first sentence, add "In this section," >>>>> >>>>> Done. >>>>> >>>>>> There are typos, needed to be fixed too: >>>>>> >>>>>> Two "the the" in the end of section 2.1.2 and end of section 4; >>>>> >>>>> Done >>>>>> >>>>>> A couple of "randomn" -> "random"; >>>>> >>>>> Done >>>>>> >>>>>> "networ" in section 2.1.5; >>>>> >>>>> Done >>>>>> >>>>>> "jut" -> "just" at the end of section 2.1.6, I guess. >>>>>> >>>>>> "The most simple" -> "the simplest" in section 2.17. >>>>> >>>>> Done. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> > From nobody Wed Jul 5 18:43:37 2017 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 BDED112EBFF for ; Wed, 5 Jul 2017 18:43:35 -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 OIyer_CJ-5pp for ; Wed, 5 Jul 2017 18:43:33 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 3649A129B49 for ; Wed, 5 Jul 2017 18:43:33 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id q86so3146814pfl.3 for ; Wed, 05 Jul 2017 18:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iPjzDwi465hea4JsKIZB9yyAqtPSzm17apRgEyhKyu0=; b=Hoyf7FZ/Z9m7IOZvgxgwXaleOzrBNiqs4++D27F8FJ/woqrB3l1TxUOlBibfuCW03p 54OHEi6XZKd8LJV/I0uwjdmpjbbFelpTzfutao4ViogyPQoPYPrV27JFLkPSOmPgIKGE vb/9ZH0wF3VdoL3zoIVyvxR30l/+aR7fvtK1AD2Uvv2e1D6NdvAUucEYYxt4AyOHx64W jNIc8D+pprQ/a7nDN9tMjjotL87BrdawJZYuKFY3yUj9hi48eTv3MWYUpiXAfJ2fEdKy cgOz/Dj5hoinw+VSTE6mwQPKfUoGSWEcZd+kWbC3/tu6y4VCVpdiOaj1yPMJ+9C0BNND pOxA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=iPjzDwi465hea4JsKIZB9yyAqtPSzm17apRgEyhKyu0=; b=CVJqcYdiutVTQ0gJ106Gwlww3yCO1ixb240cMqmJHdkiNcGKioa+sjivRY0xHFefDY V7YEmDWygFK2q3awo7PBjtFcwUJdWMPNhkS+eJNudwRls0WUpzuW5h07GQLFQCTscjn2 bZ4/kL+dBWrrNWvawOxChMKdrDKBf2T+eO5PE4buGLlIT12H1LjUrjHw8JJTMd7VrX6z 9H8YpL5XnDFHj+nV290vAOmrHtt1AzhmR+9z3n4XFnxfeZtcTdXWpIwOeeZubWGsDieZ 2nrhtNJP76TFRUh6oLVv3Wn8yN9kDsgoEXcripahwxUXfxCA9WzhYYmw/J/osjWZHjcy AV3w== X-Gm-Message-State: AIVw113j0/wnisBJsOc8NHZoNYKOYP0Mh6Thbf6VCnEfDhPHA30933vL xu/dZWiJyD8efrDn X-Received: by 10.84.238.206 with SMTP id l14mr25181195pln.280.1499305412440; Wed, 05 Jul 2017 18:43:32 -0700 (PDT) Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j14sm626701pgt.7.2017.07.05.18.43.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 18:43:31 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <20170705230553.GB14122@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 6 Jul 2017 13:42:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170705230553.GB14122@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 01:43:36 -0000 On 06/07/2017 11:05, Toerless Eckert wrote: > Brian, > > 1. I think the conclusions about IP-in-IP where that it should be in an appendix > because it would not be MTI (Mandatory to implement). That makes sense. But the text is still a bit confusing because it doesn't make that clear in the main text. However, before we resolve that, I need to understand how it's really supposed to work. > > 2./3. This was addressed in my shepherd review BRSKI where i folded in the information from > your ani-objectives draft. See my other mail about the status of that review. > > You can find the last integrated version of the ani objective text for BRSKI > in section 3.4 of: > > https://raw.githubusercontent.com/anima-wg/anima-bootstrap/toerless_review_section3_20160606/dtbootstrap-anima-keyinfra.txt > > This was done in may/june. Like for acp-07, i would like to improve this though: > > -> I did very much like what the original BRSKI text had, eg: showing also the addresses > in an example (independent of the fact that as you explain below the examples are not > correct). > > - Because the addresses are not in the objective field but in the locator-option, > your proposed text in ani-objectives does not show it. In result i could only > understand ani-objectives going back and forth with the grasp draft. I think that > makes it quite unreadable. Thats why the text i put into acp-07 does show the > whole M_FLOOD format including the location-option and objective. I understand that; showing example packets is an excellent idea. (But the reader must understand GRASP anyway.) The reason I'm trying to figure out exactly what happens in IPIP is exactly so that I can generate example packets from code; if they don't agree with what you expect, we would then have a real problem to solve. > > - I think your concern was a bit about consistency and duplication. I am not worried > about consistency given how GRASP is out the door (i hope ;-), and i am happy > to invest the time for the few additional lines in BRSKI and ACP to make the GRASP explanations > in BRSKI and ACP be readable (and verifyable for functionality) standalone. > Especially because of this IMHO confusing bit of scatter-gather encoding that we ended > up with in GRASP: The name of the service is a parameter to the > objective, but the address information of the service is in the locator-option field > outside of the objective... > > -> in ani-objectives, the service is called "method", but in grasp-14 it's called > now objective-value. Right. It's the value of the objective, which is a generic concept in GRASP. But what the value actually is depends on the syntax and semantic of the individual objective. That's actually your fault ;-) because it's the flexibility of CBOR that allows it. So what's confusing is that every objective has a value, and (the way I wrote it) the value of the "AN__join_proxy" is simply named "method". Perhaps I should not use a short cut in the CDDL; would this be clearer: proxy-objective = ["AN_join_proxy", objective-flags, loop-count, objective-value] objective-flags = ; as in the GRASP specification loop-count = 1 ; limit to link-local operation objective-value = method method = "BRSKI-TCP" / "BRSKI-UDP" I'll come back separately with my musings about how I understand IPIP to work. Regards Brian > > Cheers > Toerless > > On Tue, Jul 04, 2017 at 05:32:06PM +1200, Brian E Carpenter wrote: >> Hi, >> >> I am still trying to figure out what you really want to say in sections 3.1.1. Proxy Discovery Protocol Details and 3.1.2. Registrar Discovery Protocol Details. >> >> 1. Why doesn't section 3.1.1 mention IP-in-IP (protocol 41)? Surely the pledge needs to know about it? >> >> 2. The description is wrong anyway; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.3 for something that can work. >> >> 3. In section 3.1.2, as I already pointed out, the proposal is really a misuse of the GRASP discovery response message. Not a problem, we simply replace it with a synchronization response; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.2. >> But regardless of that, I am confused by the example locators: >> locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] >> locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] >> locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] >> >> The first two are OK. The ports announced by the proxy to the pledges may be different. If the registrar sends [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443], the proxy might announce [O_IPv6_LOCATOR, fe80::4321, 6, 9999] - the proxy's link-local address and a different port chosen by the proxy. >> >> But the third locator sent by the Registrar indicates a meaningless link-local address, because it could come from many hops away. At first I thought this was a confusion with the previous (proxy-to-pledge) case, where all addresses must be link-local. But no: this text is just confused, I think: >> >> A protocol of 41 indicates that packets may be IPIP proxy'ed. In the >> case of that IPIP proxying is used, then the provided link-local >> address MUST be advertised on the local link using proxy neighbour >> discovery. The Join Proxy MAY limit forwarded traffic to the >> protocol (6 and 17) and port numbers indicated by locator1 and >> locator2. The address to which the IPIP traffic should be sent is >> the initiator address (an ACP address of the Registrar), not the >> address given in the locator. >> >> A link local address provided by the Registrar is completely invalid except on the relevant link connected directly to the Registrar. So it definitely must not be given to anybody off that link. At the moment I have no idea how the IP-in-IP is supposed to work. Appendix C doesn't help much. Apart from anything else, it mentions a non-existent GRASP message type. I can sort of see what you want to do, but it isn't a codable spec at the moment. >> >> Maybe you can provide a complete example of the packet flow, where the pledge has link-local address Lp, the proxy has link-local address Lx and ACP address Ax, and the registrar has ACP address Ar. And to make my concern clear, the registrar has the link-local address Lp, by chance the same as the pledge, although on a different LAN. >> >> Regards >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Jul 5 19:19:25 2017 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 084DF12F29A for ; Wed, 5 Jul 2017 19:19:23 -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 8PPaplndhV80 for ; Wed, 5 Jul 2017 19:19:21 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 3ABA812EBFF for ; Wed, 5 Jul 2017 19:19:21 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id q85so3563395pfq.1 for ; Wed, 05 Jul 2017 19:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=i8ocZFfDI1zxYErjA04ISBeDmEzzJlvQwPDQImF/PuA=; b=NGfgGEW7UKi70wnIwRkqthP7kTNqxkHO96IPOvZku4dnc669z5NSirv/Lzy4/+IxYb L7W1NkbnGt9DZpVdhYdQYR1HXei6aef11C0Khrf03xo8cQp61rKxMebxKCftu4Sj9WNd aetHAusO1zHHxDADfwiYg5Xt4w4ar35aOAWa5OylapK1B2d068hlPJ0cWqjryCuQMff+ L2mrvq2uGxFLCrBeBmcNx3dwjFOrFWARZGCOh8Db2aZ83FlMSlJ7K6w4cDnN6W9S3/MX 8rgBRux/Hh1SNHqfjv9w/IJb+KYHIjPdP5LAFh8OKu+YR1ZKnRZpS+FyqKjfcbFQZG3t S8qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=i8ocZFfDI1zxYErjA04ISBeDmEzzJlvQwPDQImF/PuA=; b=gQk3cZsvL337TCcMxv8bvB3OqJ9HemPKoN9l5cAuvjhxESGaLMHzkeopvqjcHXVwQC GUJrsdEy8dLBRnNkQqWNAQcgzU6Wu9ano/vGSNMKU8xwl4ECHh9QCRGeN7WuRMYU27L9 c1ghjN5QhFMLaz6m/uY0MRQLkANopGOmHPme/JkQNoUyHiOnjMt0B0s8j5ewsUd0IxrW gGP+TRbYuLdliC7yv1DQq4jEUTMNGPL5D2XKl+maUuNxGp3zUzgddKS2+zDk+nWSrbqg VXSZ/42iSXBq/UDs9rEziHGwFsgZ3AjTZBBadVJL9lsihEOXcFGgaLJEd6ZzyiADYxD3 MmlA== X-Gm-Message-State: AIVw110oRHqNZm6+mM4ZcGLqUBEymDcsBE9OOdauJ5uDI58dYGPcPMr6 ouxAgKJNtia8A/bP X-Received: by 10.84.191.165 with SMTP id a34mr25152283pld.243.1499307560526; Wed, 05 Jul 2017 19:19:20 -0700 (PDT) Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q88sm821351pfa.10.2017.07.05.19.19.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 19:19:19 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> Date: Thu, 6 Jul 2017 14:19:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 02:19:23 -0000 Hi BRSKI authors, Is the following correct? Topology (ASCII art): ___________ | REGISTRAR | |___________| |Ar | ........... ( ACP ) ( routing ) ( cloud ) ........... | |Ax _____|_____ | PROXY | |___________| |Lx1 |Lx2 | | | | -------LAN1--------- -------LAN2---------- | | |Lp |Lp ____|____ ___|_____ | PLEDGE1 | | PLEDGE2 | |_________| |_________| Assumptions: Pledges have link-local address Lp. By chance, they are equal. (Nothing in the standards prevents them from being equal. Even pseudo-random numbers can be equal, so this case must work.) Proxy has link-local addresses Lx1, Lx2 and ACP address Ax. We can require that Lx1 != Lx2. Registrar has ACP address Ar. Packets for a UDP example: (somewhat simplified IPv6 packets!) Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1] Proxy sends to Registrar [Ax, Ar, 41, [Lp, Lx1, 17, UDP-PAYLOAD1]] Registrar replies to proxy [Ar, Ax, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]] Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2] Note that the registrar echoes back the addresses Lp and Lx but they mean nothing to it. The registrar simply borrows the proxy's LL address Lx for the purpose of replying. Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. Since the proxy will have at least two interfaces, the address Lp might exist on multiple LANs. However, the proxy will have different link-local addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} will be unique. Hence the registrar can distinguish the transactions. So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. Nothing else - no port number, no link-local address. What the proxy needs to tell the pledge is: I accept BRSKI/TCP or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact the registrar, it simply forwards the packets as-is in both directions, encapsulating and decapsulating accordingly. The pledge knows nothing about IPIP. Regards Brian From nobody Wed Jul 5 20:37:27 2017 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 9FE5212EC4D for ; Wed, 5 Jul 2017 20:37:26 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 sLdZmO0yCFPy for ; Wed, 5 Jul 2017 20:37:24 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB2812EAFF for ; Wed, 5 Jul 2017 20:37:23 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5021E58C4C5; Thu, 6 Jul 2017 05:37:19 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 38BBCB0C4CF; Thu, 6 Jul 2017 05:37:19 +0200 (CEST) Date: Thu, 6 Jul 2017 05:37:19 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 03:37:26 -0000 On Thu, Jul 06, 2017 at 02:19:23PM +1200, Brian E Carpenter wrote: > Hi BRSKI authors, Can i still answer ? Inline. I only have an ACP author, WG chair and general bloviator hat though... > Is the following correct? > > Topology (ASCII art): > ___________ > | REGISTRAR | > |___________| > |Ar > | > ........... > ( ACP ) > ( routing ) > ( cloud ) > ........... > | > |Ax > _____|_____ > | PROXY | > |___________| > |Lx1 |Lx2 > | | > | | > -------LAN1--------- -------LAN2---------- > | | > |Lp |Lp > ____|____ ___|_____ > | PLEDGE1 | | PLEDGE2 | > |_________| |_________| > > Assumptions: > > Pledges have link-local address Lp. By chance, they are equal. (Nothing in > the standards prevents them from being equal. Even pseudo-random numbers can > be equal, so this case must work.) > > Proxy has link-local addresses Lx1, Lx2 and ACP address Ax. We can require > that Lx1 != Lx2. No, i think we can not. AFAIK, it is common practice to put your MAC address as the host part into link-local addresses and only high-margin network equipment vendors afford ranges of in my experience at most up to 8 MAC addresses to a single device. And you do not want to make a protocol that changes any current possible and likely practices. I have not found evidence of being able to have multiple link-local addresses on an interface. But even if that was architecturally permitted, it too would likely not something you could easily do through a non-privileged app via UDP socket API (i fear). This concern may be bogus because the registrar would already need to deal with IPinIP, which is no fun for a non-privileged app without OS support. > Registrar has ACP address Ar. > > Packets for a UDP example: > > (somewhat simplified IPv6 packets!) > > Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1] > > Proxy sends to Registrar [Ax, Ar, 41, [Lp, Lx1, 17, UDP-PAYLOAD1]] > > Registrar replies to proxy [Ar, Ax, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]] > > Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2] > > Note that the registrar echoes back the addresses Lp and Lx but they mean > nothing to it. The registrar simply borrows the proxy's LL address Lx > for the purpose of replying. Not quite "means nothing to it". The registar will have to build connection state and the connection key is [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] Given how my claim is that multiple Lxi may be the same AND that as you already said, Lp may be the same, we need another field to distinguish those connections. C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi. But given how ACP addresses are backed by certificate, its not as easy to get more ACP addresses as it would be in less secured transport substrates. Solutions: I would change the encap from IPinIP to some UDP header variation: I want to be able to implement pledge, proxy and registar as simple apps using just UDP sockets. Thats something i can implement anywhere i want. Unless someone comes up with some pre-existing encap that makes life easy, i would just make the proxy insert a link-local pseudo header between the UDP header and the original pledges UDP payload. pseudo header would need to contain (Lp). Then in addition, the proxy would need to open a separate UDP socket for each local interface it has. That would make all UDP packet from proxy use a separate RemotPort on the registrar. The benefit of this approach is that i could start separate ASA, one for each interface, and if one interfaces proxy is attacked by pledges, it will not have an impact on other interfaces. And i minimize unnecessary headers. Relevant connection key is then: [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] Aka: Lxi is irrelevant and can be ignored by registrar. Given how this is not a throughput relevant proxy function i do not care avbout the fact that i must recalculate UDP checksums over the packet (something that has bothered UDP tunneling solutions in the IETF for years now). Cheers Toerless > Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. > Since the proxy will have at least two interfaces, the address Lp might > exist on multiple LANs. However, the proxy will have different link-local > addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} > will be unique. Hence the registrar can distinguish the transactions. > > So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. > Nothing else - no port number, no link-local address. > > What the proxy needs to tell the pledge is: I accept BRSKI/TCP > or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact > the registrar, it simply forwards the packets as-is in both directions, > encapsulating and decapsulating accordingly. The pledge knows nothing about > IPIP. > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 5 21:34:08 2017 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 959B21243FE for ; Wed, 5 Jul 2017 21:34:06 -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 urBojgNd3Wae for ; Wed, 5 Jul 2017 21:34:03 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 770F812FB9A for ; Wed, 5 Jul 2017 21:34:03 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q85so5017368pfq.1 for ; Wed, 05 Jul 2017 21:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rxRB8aglw8PAqNON/lEdn0ptyOTvD01wD34D8Wvw87I=; b=pXn9U6wN1E5jsB/hWFTcrD7pHfLaHTPt89RgyCDOPAkkEdgoucWMkdMTtK5DUzfVZF hs+Of4aa/+Y75yLyAu33o+1I0D47qFwkhbyv2tTcVmRCIKuoAH9ggjS+toV9nQQca9WR CSYAFZdh06aWgpRvc+TNuViyr6LF0Cctd5/jPcYvZrw5t3aaJ8+OX+/tgPwSPg5EqCpX DWzvUwaQaL1McOuB+QoAFixPVViDF0daQFWki6vPNaGw8Or2I5r+m78uckGZ92U413nh 4iZGCHjA3Bv5LEaG9kwf1lFn5dPsLI+5/+gtD7JreAMGYYV4ejkScuFNblcJ3aaXOy06 UVLQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=rxRB8aglw8PAqNON/lEdn0ptyOTvD01wD34D8Wvw87I=; b=OKP7WDELMwLwx5Ksqt2yZ+OKz47eT2kZfIUjnmjxXudorKamsbqWqcSP7hp4CdnoPc D5ZyOg+ZUJt11bZ0it9KSGd28NAQIw0oZpTljXt9ez0bD5slOaw2Ryp15/Uidm9QvGxN IPuW8Ooy6CSva/PgRvSUsODbKQTtmilJZKOGJY94BNWb1KRlND7bBQY9hB82waroaGUs af+uaBAHQb7gVVKRYA6bxHB1cfhkVjldqN5VYRspn7kcRwW6RPk39xfh5Ro5sl09eoOM ZHzE1SS8kygF4+46ngWxuaF4QF+A0/9FNSljAQTfAL25ZGInzCBf5G7Lr9ZQt2B1OZU2 Gi/Q== X-Gm-Message-State: AIVw113/aj9K7UwruNtQTrlvwFzB/04dNJ39CfHIty4R0el1LPn2eZxo y85ljjpTvky53hCu X-Received: by 10.99.158.18 with SMTP id s18mr24437934pgd.113.1499315642739; Wed, 05 Jul 2017 21:34:02 -0700 (PDT) Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s62sm1343178pfi.36.2017.07.05.21.34.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 21:34:02 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> Date: Thu, 6 Jul 2017 16:34:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 04:34:06 -0000 On 06/07/2017 15:37, Toerless Eckert wrote: > On Thu, Jul 06, 2017 at 02:19:23PM +1200, Brian E Carpenter wrote: >> Hi BRSKI authors, > > Can i still answer ? > > Inline. I only have an ACP author, WG chair and general bloviator hat though... > >> Is the following correct? >> >> Topology (ASCII art): >> ___________ >> | REGISTRAR | >> |___________| >> |Ar >> | >> ........... >> ( ACP ) >> ( routing ) >> ( cloud ) >> ........... >> | >> |Ax >> _____|_____ >> | PROXY | >> |___________| >> |Lx1 |Lx2 >> | | >> | | >> -------LAN1--------- -------LAN2---------- >> | | >> |Lp |Lp >> ____|____ ___|_____ >> | PLEDGE1 | | PLEDGE2 | >> |_________| |_________| >> >> Assumptions: >> >> Pledges have link-local address Lp. By chance, they are equal. (Nothing in >> the standards prevents them from being equal. Even pseudo-random numbers can >> be equal, so this case must work.) >> >> Proxy has link-local addresses Lx1, Lx2 and ACP address Ax. We can require >> that Lx1 != Lx2. > > No, i think we can not. AFAIK, it is common practice to put > your MAC address as the host part into link-local addresses It used to be, but the recommendation today is a pseudo-random value (RFC7217). In any case it's a software choice. > and only high-margin network equipment vendors > afford ranges of in my experience at most up to 8 MAC > addresses to a single device. And you do not want to > make a protocol that changes any current possible > and likely practices. We're talking about different physical interfaces. Normally they will have different MAC addresses, if they still use the old-fashioned method, or different pseudo-randoms if they follow RFC7217. In fact, the only way they could have the same LL address is by manual configuration. So I stand by what I said: we can require them to be different, and in practice they will be different anyway, on all conforming IPv6 stacks. > > I have not found evidence of being able to have multiple link-local > addresses on an interface. No, but that is not the scenario. My diagram shows two different interfaces. > But even if that was architecturally permitted, > it too would likely not something you could easily do through > a non-privileged app via UDP socket API (i fear). This concern may be > bogus because the registrar would already need to deal with IPinIP, > which is no fun for a non-privileged app without OS support. > >> Registrar has ACP address Ar. >> >> Packets for a UDP example: >> >> (somewhat simplified IPv6 packets!) >> >> Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1] >> >> Proxy sends to Registrar [Ax, Ar, 41, [Lp, Lx1, 17, UDP-PAYLOAD1]] >> >> Registrar replies to proxy [Ar, Ax, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]] >> >> Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2] >> >> Note that the registrar echoes back the addresses Lp and Lx but they mean >> nothing to it. The registrar simply borrows the proxy's LL address Lx >> for the purpose of replying. > > Not quite "means nothing to it". > The registar will have to build connection state and the connection key is > > [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] Right, but it isn't used as an IP address on a real interface. > Given how my claim is that multiple Lxi may be the same AND that as > you already said, Lp may be the same, we need another field to > distinguish those connections. If that was a real problem, which I don't think it is, we would have to include the relevant interface number as used inside the proxy's stack. (There's a horrible trick used only in the FreeBSD stack to do this, by using some of the spare bits in a link local address for this purpose. https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index ) > C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi. > But given how ACP addresses are backed by certificate, its not as > easy to get more ACP addresses as it would be in less secured > transport substrates. > > Solutions: > > I would change the encap from IPinIP to some UDP header variation: Yes, while I was studying this I wondered why not just use IP-in-UDP. It still allows the proxy to be dumb. I'd like to hear from Michael Richardson on all this. Again, my goal is to understand enough that we can get the representation in the GRASP objectives right. Brian > I want to be able to implement pledge, proxy and registar as > simple apps using just UDP sockets. Thats something i can implement > anywhere i want. > > Unless someone comes up with some pre-existing encap that makes > life easy, i would just make the proxy insert a link-local > pseudo header between the UDP header and the original pledges UDP payload. > pseudo header would need to contain (Lp). Then in addition, > the proxy would need to open a separate UDP socket for each local > interface it has. That would make all UDP packet from proxy use a separate > RemotPort on the registrar. The benefit of this approach is that i could > start separate ASA, one for each interface, and if one interfaces proxy > is attacked by pledges, it will not have an impact on other interfaces. > And i minimize unnecessary headers. > > Relevant connection key is then: > > [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] > > Aka: Lxi is irrelevant and can be ignored by registrar. > > Given how this is not a throughput relevant proxy function i do not > care avbout the fact that i must recalculate UDP checksums over the > packet (something that has bothered UDP tunneling solutions in the IETF > for years now). > > Cheers > Toerless > >> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. >> Since the proxy will have at least two interfaces, the address Lp might >> exist on multiple LANs. However, the proxy will have different link-local >> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} >> will be unique. Hence the registrar can distinguish the transactions. >> >> So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. >> Nothing else - no port number, no link-local address. >> >> What the proxy needs to tell the pledge is: I accept BRSKI/TCP >> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact >> the registrar, it simply forwards the packets as-is in both directions, >> encapsulating and decapsulating accordingly. The pledge knows nothing about >> IPIP. >> >> Regards >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Jul 6 00:09:47 2017 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 1905F1315EA for ; Thu, 6 Jul 2017 00:09:46 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ctHOrEEcBoWt for ; Thu, 6 Jul 2017 00:09: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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3373B1315DB for ; Thu, 6 Jul 2017 00:09:43 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E9B9758C4C5; Thu, 6 Jul 2017 09:09:38 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D5D96B0C4D5; Thu, 6 Jul 2017 09:09:38 +0200 (CEST) Date: Thu, 6 Jul 2017 09:09:38 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 07:09:46 -0000 On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: > It used to be, but the recommendation today is a pseudo-random > value (RFC7217). In any case it's a software choice. brand new recommendations do not equate to be expected standard practice in products. Would be very good to have folks with practical insight into various products to provide more information. > > and only high-margin network equipment vendors > > afford ranges of in my experience at most up to 8 MAC > > addresses to a single device. And you do not want to > > make a protocol that changes any current possible > > and likely practices. > > We're talking about different physical interfaces. Normally they > will have different MAC addresses, if they still use the old-fashioned > method, or different pseudo-randoms if they follow RFC7217. If you have an L3 switch with 48 ports, likelyhood that it will not have 48 different MAC addresses is very high. > In fact, the only way they could have the same LL address is > by manual configuration. I do not believe that to be true from past product experience. > So I stand by what I said: we can require > them to be different, and in practice they will be different anyway, > on all conforming IPv6 stacks. > > I have not found evidence of being able to have multiple link-local > > addresses on an interface. > > No, but that is not the scenario. My diagram shows two different interfaces. I just meant that a second link-local address could solve the problem if multiple interfaces have the same link-local address. We should move this discussion to v6ops to get feedback from folks with more insight - once we get a better understanding why some UDP encap would not be the more logical option. Just because i may not have link-local address issues does not mean that IPinIP gives me the degree of lightweight impleemntation options i would like to have (at app level). Cheers Toerless > > Not quite "means nothing to it". > > The registar will have to build connection state and the connection key is > > > > [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] > > Right, but it isn't used as an IP address on a real interface. > > > Given how my claim is that multiple Lxi may be the same AND that as > > you already said, Lp may be the same, we need another field to > > distinguish those connections. > > If that was a real problem, which I don't think it is, we would have to > include the relevant interface number as used inside the proxy's stack. > (There's a horrible trick used only in the FreeBSD stack to do this, by using > some of the spare bits in a link local address for this purpose. > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index ) > > > C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi. > > But given how ACP addresses are backed by certificate, its not as > > easy to get more ACP addresses as it would be in less secured > > transport substrates. > > > > Solutions: > > > > I would change the encap from IPinIP to some UDP header variation: > > Yes, while I was studying this I wondered why not just use IP-in-UDP. > It still allows the proxy to be dumb. > > I'd like to hear from Michael Richardson on all this. Again, my goal > is to understand enough that we can get the representation in the GRASP > objectives right. > > Brian > > > I want to be able to implement pledge, proxy and registar as > > simple apps using just UDP sockets. Thats something i can implement > > anywhere i want. > > > > Unless someone comes up with some pre-existing encap that makes > > life easy, i would just make the proxy insert a link-local > > pseudo header between the UDP header and the original pledges UDP payload. > > pseudo header would need to contain (Lp). Then in addition, > > the proxy would need to open a separate UDP socket for each local > > interface it has. That would make all UDP packet from proxy use a separate > > RemotPort on the registrar. The benefit of this approach is that i could > > start separate ASA, one for each interface, and if one interfaces proxy > > is attacked by pledges, it will not have an impact on other interfaces. > > And i minimize unnecessary headers. > > > > Relevant connection key is then: > > > > [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] > > > > Aka: Lxi is irrelevant and can be ignored by registrar. > > > > Given how this is not a throughput relevant proxy function i do not > > care avbout the fact that i must recalculate UDP checksums over the > > packet (something that has bothered UDP tunneling solutions in the IETF > > for years now). > > > > Cheers > > Toerless > > > >> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. > >> Since the proxy will have at least two interfaces, the address Lp might > >> exist on multiple LANs. However, the proxy will have different link-local > >> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} > >> will be unique. Hence the registrar can distinguish the transactions. > >> > >> So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. > >> Nothing else - no port number, no link-local address. > >> > >> What the proxy needs to tell the pledge is: I accept BRSKI/TCP > >> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact > >> the registrar, it simply forwards the packets as-is in both directions, > >> encapsulating and decapsulating accordingly. The pledge knows nothing about > >> IPIP. > >> > >> Regards > >> Brian > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de From nobody Thu Jul 6 10:03:20 2017 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 7298E13182B; Thu, 6 Jul 2017 10:03:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149936059846.2246.7164610490585047575@ietfa.amsl.com> Date: Thu, 06 Jul 2017 10:03:18 -0700 Archived-At: Subject: [Anima] IPR Disclosure Orange's Statement about IPR related to draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 17:03:18 -0000 Dear Sheng Jiang, Zongpeng Du, Brian E. Carpenter, Qiong Sun: An IPR disclosure that pertains to your Internet-Draft entitled "Autonomic IPv6 Edge Prefix Management in Large-scale Networks" (draft-ietf-anima-prefix-management) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3027/). The title of the IPR disclosure is "Orange's Statement about IPR related to draft-ietf-anima-prefix-management" Thank you IETF Secretariat From nobody Thu Jul 6 13:32:03 2017 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 A8DC312EC1E for ; Thu, 6 Jul 2017 13:32:01 -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 Tx30OpVHRReW for ; Thu, 6 Jul 2017 13:31:59 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1334126DC2 for ; Thu, 6 Jul 2017 13:31:59 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id e7so6300873pfk.0 for ; Thu, 06 Jul 2017 13:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZuZEr5fVZfL2gMpYorDp0WyvzRBYK/nPE6hy6oUoLi8=; b=HuavleEm46aJUC2Pt4fbz3vgMHyw5BNJ2G1BzHKE2FhVIq8Pq/uhlekpjEAVZjPNs2 P0/rHvybDoDSX/MFIjuytF3xLiD5q13sUWVHXN0OZWyoIsmRA5SjVdw5p/Roo1VzsHP6 gJyvMGjDD4iHNAU/5sirKW5wCpUP6sZORceRHKhTfM7r+AO3ID1UIRaItJiFhp5OIPeN UiEsWulQdU4w22rvd5laJv9q2Mkp8FNUtFbnywQwtJHQhWFqS0EdShRciadHOpOgori3 ctKsp93oKpkGf4D5Nq9D0OzZQFWfjvtTrx9OcoEuhSF8/WxEfXSfP6wLoA+VmlWAoYRA RCrg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZuZEr5fVZfL2gMpYorDp0WyvzRBYK/nPE6hy6oUoLi8=; b=IuNS1Dn14NNx5suFLNBP7MWS/fB8ZOnDXABKh2u2fOpipYRphlDx6PGolTPfub6iT2 QXmqDjrwVIniB1WxzJmXGsTH8bkKLrlbx7pOuDx3iFOjRd1+ZUsMzuXys2be28KiUOgb X84mSxxNP6BsQXcIw6dOCruhPMKas/RwpK0d41uPump7yrLQW/+BtLuINO3JWhIo0/VK SPp5hRuojA4c+34nDw5iMecVgo6SiKneP4w7jvMYwfWsGsL9F/DDc+uknGR4yjSEpzot +DWfzFICd/I0ds3Ps04A5nuS9bhw1A+PhKfiJTigHsSpn9E8YTvHztPx5dABYtJdcaZl Jhqg== X-Gm-Message-State: AIVw113lOAV8nnvWLPTdSj3jIT68bwd6DadBgKb7Wtb/BYzmJCOeEKgu nWka+iQzstPWuu1h X-Received: by 10.99.121.77 with SMTP id u74mr27533805pgc.107.1499373119016; Thu, 06 Jul 2017 13:31:59 -0700 (PDT) Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s88sm2173065pfk.16.2017.07.06.13.31.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 13:31:57 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 7 Jul 2017 08:32:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 20:32:02 -0000 On 06/07/2017 19:09, Toerless Eckert wrote: > On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: >> It used to be, but the recommendation today is a pseudo-random >> value (RFC7217). In any case it's a software choice. > > brand new recommendations do not equate to be expected > standard practice in products. Would be very good to have > folks with practical insight into various products to > provide more information. Indeed. But the general-purpose o/s stacks (I mean Linux, MacOS and Windows) have been using pseudo-random interface IDs for several years, since long before RFC7217. If you're talking about L2/L3 switches, I have no idea. > >>> and only high-margin network equipment vendors >>> afford ranges of in my experience at most up to 8 MAC >>> addresses to a single device. And you do not want to >>> make a protocol that changes any current possible >>> and likely practices. >> >> We're talking about different physical interfaces. Normally they >> will have different MAC addresses, if they still use the old-fashioned >> method, or different pseudo-randoms if they follow RFC7217. > > If you have an L3 switch with 48 ports, likelyhood that it will > not have 48 different MAC addresses is very high. Yes, because it is *also* an L2 switch, a.k.a. a bridge, so naturally it appears as a single L2 device. So this depends on its internal systems model. This is the kind of complexity you get with layer violations, and an L2/L3 switch is the king of all layer violations. >> In fact, the only way they could have the same LL address is >> by manual configuration. > > I do not believe that to be true from past product experience. I think the confusion is that because of the L2 bridge function, all those 48 interfaces behave as a single interface viewed from L3, and therefore naturally have the same L3 address. So if the L3 code in the switch itself also sees them as a single interface, we have no problem. If the L3 code can see 48 separate interfaces, we do have a problem. (There is a complication in the switch caused by optimisation for multicast, because MLD snooping has to look at both L2 and L3 headers. But BRSKI proxying only has to look at L3.) (There is more complication potentially caused by VLANs.) > >> So I stand by what I said: we can require >> them to be different, and in practice they will be different anyway, >> on all conforming IPv6 stacks. > >>> I have not found evidence of being able to have multiple link-local >>> addresses on an interface. >> >> No, but that is not the scenario. My diagram shows two different interfaces. > > I just meant that a second link-local address could solve the > problem if multiple interfaces have the same link-local address. s/multiple interfaces/multiple L3 interfaces/ > We should move this discussion to v6ops to get feedback from folks > with more insight - once we get a better understanding why some > UDP encap would not be the more logical option. Just because i may > not have link-local address issues does not mean that IPinIP gives > me the degree of lightweight impleemntation options i would like to > have (at app level). Agreed. IMNSHO this is not cooked yet and should not be mentioned in a standards-track draft unless we want a very long discussion with the IESG. Brian > > Cheers > Toerless > >>> Not quite "means nothing to it". >>> The registar will have to build connection state and the connection key is >>> >>> [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] >> >> Right, but it isn't used as an IP address on a real interface. >> >>> Given how my claim is that multiple Lxi may be the same AND that as >>> you already said, Lp may be the same, we need another field to >>> distinguish those connections. >> >> If that was a real problem, which I don't think it is, we would have to >> include the relevant interface number as used inside the proxy's stack. >> (There's a horrible trick used only in the FreeBSD stack to do this, by using >> some of the spare bits in a link local address for this purpose. >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index ) >> >>> C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi. >>> But given how ACP addresses are backed by certificate, its not as >>> easy to get more ACP addresses as it would be in less secured >>> transport substrates. >>> >>> Solutions: >>> >>> I would change the encap from IPinIP to some UDP header variation: >> >> Yes, while I was studying this I wondered why not just use IP-in-UDP. >> It still allows the proxy to be dumb. >> >> I'd like to hear from Michael Richardson on all this. Again, my goal >> is to understand enough that we can get the representation in the GRASP >> objectives right. >> >> Brian >> >>> I want to be able to implement pledge, proxy and registar as >>> simple apps using just UDP sockets. Thats something i can implement >>> anywhere i want. >>> >>> Unless someone comes up with some pre-existing encap that makes >>> life easy, i would just make the proxy insert a link-local >>> pseudo header between the UDP header and the original pledges UDP payload. >>> pseudo header would need to contain (Lp). Then in addition, >>> the proxy would need to open a separate UDP socket for each local >>> interface it has. That would make all UDP packet from proxy use a separate >>> RemotPort on the registrar. The benefit of this approach is that i could >>> start separate ASA, one for each interface, and if one interfaces proxy >>> is attacked by pledges, it will not have an impact on other interfaces. >>> And i minimize unnecessary headers. >>> >>> Relevant connection key is then: >>> >>> [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] >>> >>> Aka: Lxi is irrelevant and can be ignored by registrar. >>> >>> Given how this is not a throughput relevant proxy function i do not >>> care avbout the fact that i must recalculate UDP checksums over the >>> packet (something that has bothered UDP tunneling solutions in the IETF >>> for years now). >>> >>> Cheers >>> Toerless >>> >>>> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. >>>> Since the proxy will have at least two interfaces, the address Lp might >>>> exist on multiple LANs. However, the proxy will have different link-local >>>> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} >>>> will be unique. Hence the registrar can distinguish the transactions. >>>> >>>> So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. >>>> Nothing else - no port number, no link-local address. >>>> >>>> What the proxy needs to tell the pledge is: I accept BRSKI/TCP >>>> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact >>>> the registrar, it simply forwards the packets as-is in both directions, >>>> encapsulating and decapsulating accordingly. The pledge knows nothing about >>>> IPIP. >>>> >>>> Regards >>>> Brian >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> > From nobody Thu Jul 6 16:14:08 2017 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 AD112131841 for ; Thu, 6 Jul 2017 16:14:07 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Yve6pZa4T3Jp for ; Thu, 6 Jul 2017 16:14:06 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0CE131774 for ; Thu, 6 Jul 2017 16:14:06 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EE4B458C4B9; Fri, 7 Jul 2017 01:14:00 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id CC7F3B0C4E5; Fri, 7 Jul 2017 01:14:00 +0200 (CEST) Date: Fri, 7 Jul 2017 01:14:00 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170706231400.GB24940@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 23:14:07 -0000 Ok, sent mail to v6ops, not cc'ed to anima (though shall not group-cross-post IETF policy *sigh*). More inline. On Fri, Jul 07, 2017 at 08:32:03AM +1200, Brian E Carpenter wrote: > Indeed. But the general-purpose o/s stacks (I mean Linux, > MacOS and Windows) have been using pseudo-random interface > IDs for several years, since long before RFC7217. If you're > talking about L2/L3 switches, I have no idea. Yeah. Especially MacOS and Windows are widely deployed router OSs ;-)) > Yes, because it is *also* an L2 switch, a.k.a. a bridge, so naturally > it appears as a single L2 device. So this depends on its internal systems > model. This is the kind of complexity you get with layer violations, > and an L2/L3 switch is the king of all layer violations. Its got less to do with layer violation and L2 switches but rather with the cost of a large number of MAC addresses. Those have to be paid for. Primarily so that people do not exhaust them too quickly. Like when you would uhmm... assign a separate MAC address to every bloody L3 network devices subnet ;-) > (There is a complication in the switch caused by optimisation for > multicast, because MLD snooping has to look at both L2 and L3 > headers. But BRSKI proxying only has to look at L3.) Only stupid MLD snooping needs to look at L2, but most MLD snooping is stupid ;-) > (There is more complication potentially caused by VLANs.) Indeed, i forgot. By default, multiple L3 subnets on a single physcial ethernet will very often get the same MAC address. And it's quite common for a router to just have such a trunk L3 interface. > > I just meant that a second link-local address could solve the > > problem if multiple interfaces have the same link-local address. > > s/multiple interfaces/multiple L3 interfaces/ "subnets" in IETF lingo ;-) or "read what i mean" ;-) > > We should move this discussion to v6ops to get feedback from folks > > with more insight - once we get a better understanding why some > > UDP encap would not be the more logical option. Just because i may > > not have link-local address issues does not mean that IPinIP gives > > me the degree of lightweight impleemntation options i would like to > > have (at app level). > > Agreed. IMNSHO this is not cooked yet and should not be mentioned > in a standards-track draft unless we want a very long discussion > with the IESG. Yes Toerless > Brian > > > > > Cheers > > Toerless > > > >>> Not quite "means nothing to it". > >>> The registar will have to build connection state and the connection key is > >>> > >>> [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] > >> > >> Right, but it isn't used as an IP address on a real interface. > >> > >>> Given how my claim is that multiple Lxi may be the same AND that as > >>> you already said, Lp may be the same, we need another field to > >>> distinguish those connections. > >> > >> If that was a real problem, which I don't think it is, we would have to > >> include the relevant interface number as used inside the proxy's stack. > >> (There's a horrible trick used only in the FreeBSD stack to do this, by using > >> some of the spare bits in a link local address for this purpose. > >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index ) > >> > >>> C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi. > >>> But given how ACP addresses are backed by certificate, its not as > >>> easy to get more ACP addresses as it would be in less secured > >>> transport substrates. > >>> > >>> Solutions: > >>> > >>> I would change the encap from IPinIP to some UDP header variation: > >> > >> Yes, while I was studying this I wondered why not just use IP-in-UDP. > >> It still allows the proxy to be dumb. > >> > >> I'd like to hear from Michael Richardson on all this. Again, my goal > >> is to understand enough that we can get the representation in the GRASP > >> objectives right. > >> > >> Brian > >> > >>> I want to be able to implement pledge, proxy and registar as > >>> simple apps using just UDP sockets. Thats something i can implement > >>> anywhere i want. > >>> > >>> Unless someone comes up with some pre-existing encap that makes > >>> life easy, i would just make the proxy insert a link-local > >>> pseudo header between the UDP header and the original pledges UDP payload. > >>> pseudo header would need to contain (Lp). Then in addition, > >>> the proxy would need to open a separate UDP socket for each local > >>> interface it has. That would make all UDP packet from proxy use a separate > >>> RemotPort on the registrar. The benefit of this approach is that i could > >>> start separate ASA, one for each interface, and if one interfaces proxy > >>> is attacked by pledges, it will not have an impact on other interfaces. > >>> And i minimize unnecessary headers. > >>> > >>> Relevant connection key is then: > >>> > >>> [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] > >>> > >>> Aka: Lxi is irrelevant and can be ignored by registrar. > >>> > >>> Given how this is not a throughput relevant proxy function i do not > >>> care avbout the fact that i must recalculate UDP checksums over the > >>> packet (something that has bothered UDP tunneling solutions in the IETF > >>> for years now). > >>> > >>> Cheers > >>> Toerless > >>> > >>>> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. > >>>> Since the proxy will have at least two interfaces, the address Lp might > >>>> exist on multiple LANs. However, the proxy will have different link-local > >>>> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} > >>>> will be unique. Hence the registrar can distinguish the transactions. > >>>> > >>>> So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. > >>>> Nothing else - no port number, no link-local address. > >>>> > >>>> What the proxy needs to tell the pledge is: I accept BRSKI/TCP > >>>> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact > >>>> the registrar, it simply forwards the packets as-is in both directions, > >>>> encapsulating and decapsulating accordingly. The pledge knows nothing about > >>>> IPIP. > >>>> > >>>> Regards > >>>> Brian > >>>> > >>>> _______________________________________________ > >>>> Anima mailing list > >>>> Anima@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/anima > >>> > > -- --- tte@cs.fau.de From nobody Fri Jul 7 04:30:43 2017 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 7453D129B29; Fri, 7 Jul 2017 04:30:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149942704146.8308.3636312708980863036.idtracker@ietfa.amsl.com> Date: Fri, 07 Jul 2017 04:30:41 -0700 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-anima-grasp-14=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 11:30:41 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-anima-grasp-14: 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-grasp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss in the upcoming version -15! ----- Old comments for the record (I didn't check these): Other mostly editorial comments: - ASA needs to be spelled out in the intro. - I would recommend to move section 2 and 3.3 into the appendix - section 3.5.4.2: "A neighbor with multiple interfaces will respond with a cached discovery response if any." "cached response" is explained in the next section and not clear in this paragraph. - section 3.5.4.3: "After a GRASP device successfully discovers a locator for a Discovery Responder supporting a specific objective, it MUST cache this information, including the interface index via which it was discovered. This cache record MAY be used for future negotiation or synchronization, and the locator SHOULD be passed on when appropriate as a Divert option to another Discovery Initiator." Not sure why the first is a MUST and the later is a SHOULD. I guess a SHOULD for caching would be sufficient. - section 3.8.6 "If a node receives a Request message for an objective for which no ASA is currently listening, it MUST immediately close the relevant socket to indicate this to the initiator." How is that indicated? Should really be further clarified - Also section 3.8.6: "In case of a clash, it MUST discard the Request message, in which case the initiator will detect a timeout." Why don't you send an error message instead? How does the initiator know that is should retry (assuming there is a TCP connection underneath that provides reliable transport)? - Also section 3.8.9: "If not, the initiator MUST abandon or restart the negotiation procedure, to avoid an indefinite wait." How does the initiator decide for abandoning or restarting instead? Needs clarification! - Could be useful to include an optional reasoning field in the Invalid Message and make copying the received message up to the maximum message size of this message a SHOULD (section 3.8.12.). - Not sure I fully understand the purpose of the No Operation Message (section 3.8.13.). If you just want to open a socket for probing, you perform a TCP handshake and send a RST right after. No need for further application layer interactions. And should there also be an optional reasoning phrase? - Not sure why the objectives flag is needed. I assume that unknown objectives are ignored anyway and if a objective is known the receiver should know if that objective is valid for the respective message type (section 3.10.2). - section 3.10.4: "An issue requiring particular attention is that GRASP itself is a stateless protocol." It's not. It caches information and needs to remember previous messages sent to reply correctly. - section 5: "Generally speaking, no personal information is expected to be involved in the signaling protocol, so there should be no direct impact on personal privacy." I don't think this is true because the protocol is so generic that you cannot say anything about the services it is used for. Please see also further comments from Martin's tsv-art review (Thanks again!)! From nobody Fri Jul 7 17:39:18 2017 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 E0245129503 for ; Fri, 7 Jul 2017 17:39:16 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 jN32B9VXbzsy for ; Fri, 7 Jul 2017 17:39:14 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A7D12762F for ; Fri, 7 Jul 2017 17:39:14 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6462E58C4AE; Sat, 8 Jul 2017 02:39:10 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4B434B0C502; Sat, 8 Jul 2017 02:39:10 +0200 (CEST) Date: Sat, 8 Jul 2017 02:39:10 +0200 From: Toerless Eckert To: Michael Richardson Cc: Brian E Carpenter , anima@ietf.org Message-ID: <20170708003910.GA28540@faui40p.informatik.uni-erlangen.de> References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> <28650.1497805133@obiwan.sandelman.ca> <1dc4daff-5e31-c918-0db4-071f43f3ef9d@gmail.com> <24980.1497879364@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24980.1497879364@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jul 2017 00:39:17 -0000 Seems i dropped the ball on these: I am not sure i see the crucial need to be able to optimize the number of packets of periodic ACP and BRSKI announcements. Assume BRSKI, ACP and GRASP are diferent ASAs. We'd need a GRASP API feature to request coalescion of announcement. How would you define that API feature... The idea was to use M_FLOOD for BRSKI because that would allow the pledge to be quiet. Which is more secure because pledge is potentially easy to attack. For ACP i also have M_FLOOD in the text because thats the solution with just one message. No need for two-way handshake. Check out brians ani-objective. The alternative to M_FLOOD he lines out are more complicated. Cheers Toerless On Mon, Jun 19, 2017 at 09:36:04AM -0400, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> If a node doesn't want to announce itself as a proxy, it would omit that > >> objective. > >> > >> As for implementation, I've done it. It's a question of about a page > >> of C > >> code (given a cbor library), or about ten lines of ruby. Probably a > >> similar > >> number of lines of python. > > > I'm thinking that if we want to make a tiny extension to GRASP syntax for > > this special purpose, we can do so in the BRSKI document. That's yet > > another benefit of using CBOR. > > flood-message = [M_FLOOD, session-id, initiator, ttl, > +[objective, (locator-option / [])]] > > You added the +[] there so that we can announce multiple objectives. > I don't think that there is anything more to do in GRASP. > > All we need to do is define the AN_Proxy objective, and ACP has to > define the AN_ACP objective. I just don't see any problem here. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > From nobody Fri Jul 7 18:48:12 2017 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 B9A5C131466 for ; Fri, 7 Jul 2017 18:48:11 -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 AvnSRuoJRU_b for ; Fri, 7 Jul 2017 18:48:09 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 D7A3E129B16 for ; Fri, 7 Jul 2017 18:48:09 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id u36so5818520pgn.3 for ; Fri, 07 Jul 2017 18:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H02bN+ZMLzjyvpEaiBeNMdTDPXSQzJI1cztn+Zd9mCg=; b=J7NR1j7XVqD+h1T7ndsQL8Z4hmXr4xMe5wHcsV9mTLDaBF3NVn09O8EvfhnymdwMHz oF8H5TWhbD0vm+iB0xTdVMN/1+GdE8qJXZ64ggMHVciqox5n36HkBzbDXH6HNQxoA2kq sadaT1H1RtmduuIv6prE8aQpKUOL5KK65j1U74L5yWO9VyiptdKi1ThWdqAfCP96y9gu cqLNWF+/NtDYb9lAX2UTH/vtwMN4n0gT4JZl6K0A17WbKcxIyWqoiWwsbBxVOVxo5Sbm EinE4unShvPr9uBlYXuVBJCoWCG10aOWYJhxy15kBzISpCcEws/jbUmVP1M29nL7Wns/ phhg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=H02bN+ZMLzjyvpEaiBeNMdTDPXSQzJI1cztn+Zd9mCg=; b=bdO+aJzaYQKNSiMdOqCz54jqeHY7v0qL61V3GNleaEH6zfhhO+eT/bqPjfw1lAY+nM 9QP2e+Wj3roZzHyXeWDrt4TVhMjVMUo/HxZs4pQmz9PxL8Eisl1Tbc2fNCcn55XesWcs 5x6dcI0Sp9mJ6LFK44uyk65MyX7IY3L9rjrAQyMzbByXgSK93XkGHK6uSM8616zVcT21 vvTd8RLVFrRJs22uoE3WjE4sGnc5CvHWAFTC3hE6PXnOqgaIlzxQJGI/wmr/jAPC9SJa BlqdLeNTWlHGFjQVyr56o2/zehZ4Vr8msrQIKOYAnP8kGkLqcWOreKi+Q8GHG7D1suIq KM3g== X-Gm-Message-State: AIVw113hDOXZsza8JjX08qpXaUQxBUe4QlGyZPVhf+TpnrEQY1zd7rFq P18VqYqaFoJRN4wq X-Received: by 10.84.128.74 with SMTP id 68mr6057497pla.236.1499478489191; Fri, 07 Jul 2017 18:48:09 -0700 (PDT) Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q3sm2754322pfk.8.2017.07.07.18.48.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 18:48:08 -0700 (PDT) To: Toerless Eckert , Michael Richardson Cc: anima@ietf.org References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> <28650.1497805133@obiwan.sandelman.ca> <1dc4daff-5e31-c918-0db4-071f43f3ef9d@gmail.com> <24980.1497879364@obiwan.sandelman.ca> <20170708003910.GA28540@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0198fd68-84d4-e5b6-bd98-29441d2e9dd0@gmail.com> Date: Sat, 8 Jul 2017 13:48:16 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170708003910.GA28540@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jul 2017 01:48:11 -0000 On 08/07/2017 12:39, Toerless Eckert wrote: > Seems i dropped the ball on these: > > I am not sure i see the crucial need to be able to optimize the number of packets of periodic ACP and BRSKI announcements. Sure, unless we plan to flood these at a high rate, it isn't important; but it's an option that GRASP provides. > > Assume BRSKI, ACP and GRASP are diferent ASAs. We'd need a GRASP API feature to request coalescion of announcement. How would you define that API feature... If you had a monolithic implementation, it wouldn't be using the API. I think that was Michael R's model. (Or you could roll up the proxy and the acp logic in a single ASA, I guess. But I don't think it is a particularly good idea.) > > The idea was to use M_FLOOD for BRSKI because that would allow the pledge to be quiet. Which is more secure because pledge is potentially easy to attack. > > For ACP i also have M_FLOOD in the text because thats the solution with just one message. No need for two-way handshake. > > Check out brians ani-objective. The alternative to M_FLOOD he lines out are more complicated. Actually I took them out of the latest (02) version, I think. Just flooding for ACP and Proxy, and Synchronization for the Registrar. If you want the Registrar to flood as well, that's easy too. Just tell me. I'm updating my demo code too, but I was hoping to get the IPIP stuff clarified first. Brian > > Cheers > Toerless > > On Mon, Jun 19, 2017 at 09:36:04AM -0400, Michael Richardson wrote: >> >> Brian E Carpenter wrote: >> >> If a node doesn't want to announce itself as a proxy, it would omit that >> >> objective. >> >> >> >> As for implementation, I've done it. It's a question of about a page >> >> of C >> >> code (given a cbor library), or about ten lines of ruby. Probably a >> >> similar >> >> number of lines of python. >> >> > I'm thinking that if we want to make a tiny extension to GRASP syntax for >> > this special purpose, we can do so in the BRSKI document. That's yet >> > another benefit of using CBOR. >> >> flood-message = [M_FLOOD, session-id, initiator, ttl, >> +[objective, (locator-option / [])]] >> >> You added the +[] there so that we can announce multiple objectives. >> I don't think that there is anything more to do in GRASP. >> >> All we need to do is define the AN_Proxy objective, and ACP has to >> define the AN_ACP objective. I just don't see any problem here. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> > From nobody Fri Jul 7 19:00:26 2017 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 01021131472 for ; Fri, 7 Jul 2017 19:00:26 -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 h5TAZUxOoQm1 for ; Fri, 7 Jul 2017 19:00:23 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E3A129B16 for ; Fri, 7 Jul 2017 19:00:23 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id j186so24721751pge.2 for ; Fri, 07 Jul 2017 19:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Zn1+ETFb9PxXVwSmcRTBiqRoX1Vi13rA00h1YMwVWok=; b=o11XUHbUY8e7cCHjmO2/l7FjbmZJzoIy5RRFfvenYQeo0zSIhQgLvd2osLuNqj7eGT QjcXv3SvZddA3VLcFfK0JcfGseHIfTPNRxdOcUG3F8lDyMCsmwGKHdp7zHU844Cb7WxQ mgqTpUkxYhpnw3CaQ8MlGahgyq+g5j1/1AwFBnwq3La1PVFTqVyuWsLeeR2b4lE9I3NY e3krIy3MNCsQ4NfeVcML/zq/ia6rFXVjcRF9YGUGFEVbMMeTn63hsLs6d4I1W69bLVlZ 8yy3cjIOFRku4KMkaYLRNS8PAUz+YzxMlYx5oqMtZc/+aEy8jD+/FNf16tVWhpB2Cicd mv0g== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Zn1+ETFb9PxXVwSmcRTBiqRoX1Vi13rA00h1YMwVWok=; b=qcef/2p1PFi7ERQ1/oU7SDJCzVyVuuqeoMPoHJMTDNO47SlNRm6T9JrL0e4YBB2SAR f6tBrOOdIlvWVKpGNZMioJ9mnZsEZkvzGmSmB8u8oUjUp4t++8z4eo5eZEmxbeavQ/z1 +g0P3znhv9r7Ljz2uMeR3trSNvgWtRXB0Xk048bnK/8RzH6TuU0KO+nS7nAZqV0BsRfx PwwUHQAwhDPnnaDxEZDqI6Vr0W6F3PAYk8apk2P3WWckULEd4AeoH4R+m1KsZY0iJscs kyH13geqoe1Qf4zsh9L2+PKj9K6u3tyBhaX5tLcA2rnM827Wg7xcjmrOTJCLofFNho7v G5SQ== X-Gm-Message-State: AIVw113swxQHA10ivmZ73NJycqE5rjvXgTFSIfyncm/Fi+GxXhqJfonH 6wbypQJ0ayZPlU7C X-Received: by 10.99.53.129 with SMTP id c123mr4155798pga.87.1499479222109; Fri, 07 Jul 2017 19:00:22 -0700 (PDT) Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n71sm9969162pfi.95.2017.07.07.19.00.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 19:00:21 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <20170706231400.GB24940@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 8 Jul 2017 14:00:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170706231400.GB24940@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jul 2017 02:00:26 -0000 And for those who aren't on v6ops, the answer is clear: Although for classical host o/s I'm correct, and the norm is to have a different link-local address on each interface, a) this is not required by the IPv6 standards, and b) on L2/L3 switches from major manfacturers, it is common that many interfaces have the same link-local addresses. Which means that my diagram should be: ___________ | REGISTRAR | |___________| |Ar | ........... ( ACP ) ( routing ) ( cloud ) ........... | |Ax _____|_____ | PROXY | |___________| |Lx |Lx | | | | -------LAN1--------- -------LAN2---------- | | |Lp |Lp ____|____ ___|_____ | PLEDGE1 | | PLEDGE2 | |_________| |_________| That means that packets from PLEDGE1 and PLEDGE2 to the proxy could have 100% identical addresses. So straightforward IP-in-IP to the registrar will not work, because the registrar would have no way to distinguish them, and the proxy would have no way to distinguish the replies. Maybe the port numbers offer a solution but they are in the embedded payload. Michael R, help! Regards Brian On 07/07/2017 11:14, Toerless Eckert wrote: > Ok, sent mail to v6ops, not cc'ed to anima (though shall not group-cross-post IETF policy *sigh*). > > More inline. > > On Fri, Jul 07, 2017 at 08:32:03AM +1200, Brian E Carpenter wrote: >> Indeed. But the general-purpose o/s stacks (I mean Linux, >> MacOS and Windows) have been using pseudo-random interface >> IDs for several years, since long before RFC7217. If you're >> talking about L2/L3 switches, I have no idea. > > Yeah. Especially MacOS and Windows are widely deployed router OSs ;-)) > >> Yes, because it is *also* an L2 switch, a.k.a. a bridge, so naturally >> it appears as a single L2 device. So this depends on its internal systems >> model. This is the kind of complexity you get with layer violations, >> and an L2/L3 switch is the king of all layer violations. > > Its got less to do with layer violation and L2 switches but rather with > the cost of a large number of MAC addresses. Those have to be paid for. > Primarily so that people do not exhaust them too quickly. Like when > you would uhmm... assign a separate MAC address to every bloody L3 > network devices subnet ;-) > >> (There is a complication in the switch caused by optimisation for >> multicast, because MLD snooping has to look at both L2 and L3 >> headers. But BRSKI proxying only has to look at L3.) > > Only stupid MLD snooping needs to look at L2, but most MLD snooping is stupid ;-) > >> (There is more complication potentially caused by VLANs.) > > Indeed, i forgot. By default, multiple L3 subnets on a single physcial > ethernet will very often get the same MAC address. And it's quite > common for a router to just have such a trunk L3 interface. > >>> I just meant that a second link-local address could solve the >>> problem if multiple interfaces have the same link-local address. >> >> s/multiple interfaces/multiple L3 interfaces/ > > "subnets" in IETF lingo ;-) or "read what i mean" ;-) > >>> We should move this discussion to v6ops to get feedback from folks >>> with more insight - once we get a better understanding why some >>> UDP encap would not be the more logical option. Just because i may >>> not have link-local address issues does not mean that IPinIP gives >>> me the degree of lightweight impleemntation options i would like to >>> have (at app level). >> >> Agreed. IMNSHO this is not cooked yet and should not be mentioned >> in a standards-track draft unless we want a very long discussion >> with the IESG. > > Yes > > Toerless > >> Brian >> >>> >>> Cheers >>> Toerless >>> >>>>> Not quite "means nothing to it". >>>>> The registar will have to build connection state and the connection key is >>>>> >>>>> [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] >>>> >>>> Right, but it isn't used as an IP address on a real interface. >>>> >>>>> Given how my claim is that multiple Lxi may be the same AND that as >>>>> you already said, Lp may be the same, we need another field to >>>>> distinguish those connections. >>>> >>>> If that was a real problem, which I don't think it is, we would have to >>>> include the relevant interface number as used inside the proxy's stack. >>>> (There's a horrible trick used only in the FreeBSD stack to do this, by using >>>> some of the spare bits in a link local address for this purpose. >>>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index ) >>>> >>>>> C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi. >>>>> But given how ACP addresses are backed by certificate, its not as >>>>> easy to get more ACP addresses as it would be in less secured >>>>> transport substrates. >>>>> >>>>> Solutions: >>>>> >>>>> I would change the encap from IPinIP to some UDP header variation: >>>> >>>> Yes, while I was studying this I wondered why not just use IP-in-UDP. >>>> It still allows the proxy to be dumb. >>>> >>>> I'd like to hear from Michael Richardson on all this. Again, my goal >>>> is to understand enough that we can get the representation in the GRASP >>>> objectives right. >>>> >>>> Brian >>>> >>>>> I want to be able to implement pledge, proxy and registar as >>>>> simple apps using just UDP sockets. Thats something i can implement >>>>> anywhere i want. >>>>> >>>>> Unless someone comes up with some pre-existing encap that makes >>>>> life easy, i would just make the proxy insert a link-local >>>>> pseudo header between the UDP header and the original pledges UDP payload. >>>>> pseudo header would need to contain (Lp). Then in addition, >>>>> the proxy would need to open a separate UDP socket for each local >>>>> interface it has. That would make all UDP packet from proxy use a separate >>>>> RemotPort on the registrar. The benefit of this approach is that i could >>>>> start separate ASA, one for each interface, and if one interfaces proxy >>>>> is attacked by pledges, it will not have an impact on other interfaces. >>>>> And i minimize unnecessary headers. >>>>> >>>>> Relevant connection key is then: >>>>> >>>>> [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] >>>>> >>>>> Aka: Lxi is irrelevant and can be ignored by registrar. >>>>> >>>>> Given how this is not a throughput relevant proxy function i do not >>>>> care avbout the fact that i must recalculate UDP checksums over the >>>>> packet (something that has bothered UDP tunneling solutions in the IETF >>>>> for years now). >>>>> >>>>> Cheers >>>>> Toerless >>>>> >>>>>> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. >>>>>> Since the proxy will have at least two interfaces, the address Lp might >>>>>> exist on multiple LANs. However, the proxy will have different link-local >>>>>> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} >>>>>> will be unique. Hence the registrar can distinguish the transactions. >>>>>> >>>>>> So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. >>>>>> Nothing else - no port number, no link-local address. >>>>>> >>>>>> What the proxy needs to tell the pledge is: I accept BRSKI/TCP >>>>>> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact >>>>>> the registrar, it simply forwards the packets as-is in both directions, >>>>>> encapsulating and decapsulating accordingly. The pledge knows nothing about >>>>>> IPIP. >>>>>> >>>>>> Regards >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Anima mailing list >>>>>> Anima@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>> > From nobody Fri Jul 7 19:43:11 2017 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 10AE2129B38 for ; Fri, 7 Jul 2017 19:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kjpKWHesGgNn for ; Fri, 7 Jul 2017 19:43:06 -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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB6112F3D5 for ; Fri, 7 Jul 2017 19:43:05 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 999BA58C4AF; Sat, 8 Jul 2017 04:42:59 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7892AB0C501; Sat, 8 Jul 2017 04:42:59 +0200 (CEST) Date: Sat, 8 Jul 2017 04:42:59 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170708024259.GB28540@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <20170706231400.GB24940@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jul 2017 02:43:09 -0000 Just in case someone missed my first 10 opinions: UDP encap. Also allows to build pledge,proxy.registrar as normal socket apps. On Sat, Jul 08, 2017 at 02:00:29PM +1200, Brian E Carpenter wrote: > And for those who aren't on v6ops, the answer is clear: > > Although for classical host o/s I'm correct, and the norm is > to have a different link-local address on each interface, > a) this is not required by the IPv6 standards, and > b) on L2/L3 switches from major manfacturers, it is common > that many interfaces have the same link-local addresses. > > Which means that my diagram should be: > > ___________ > | REGISTRAR | > |___________| > |Ar > | > ........... > ( ACP ) > ( routing ) > ( cloud ) > ........... > | > |Ax > _____|_____ > | PROXY | > |___________| > |Lx |Lx > | | > | | > -------LAN1--------- -------LAN2---------- > | | > |Lp |Lp > ____|____ ___|_____ > | PLEDGE1 | | PLEDGE2 | > |_________| |_________| > > That means that packets from PLEDGE1 and PLEDGE2 to the proxy > could have 100% identical addresses. So straightforward IP-in-IP > to the registrar will not work, because the registrar would > have no way to distinguish them, and the proxy would have > no way to distinguish the replies. Maybe the port numbers > offer a solution but they are in the embedded payload. > > Michael R, help! > > Regards > Brian > > On 07/07/2017 11:14, Toerless Eckert wrote: > > Ok, sent mail to v6ops, not cc'ed to anima (though shall not group-cross-post IETF policy *sigh*). > > > > More inline. > > > > On Fri, Jul 07, 2017 at 08:32:03AM +1200, Brian E Carpenter wrote: > >> Indeed. But the general-purpose o/s stacks (I mean Linux, > >> MacOS and Windows) have been using pseudo-random interface > >> IDs for several years, since long before RFC7217. If you're > >> talking about L2/L3 switches, I have no idea. > > > > Yeah. Especially MacOS and Windows are widely deployed router OSs ;-)) > > > >> Yes, because it is *also* an L2 switch, a.k.a. a bridge, so naturally > >> it appears as a single L2 device. So this depends on its internal systems > >> model. This is the kind of complexity you get with layer violations, > >> and an L2/L3 switch is the king of all layer violations. > > > > Its got less to do with layer violation and L2 switches but rather with > > the cost of a large number of MAC addresses. Those have to be paid for. > > Primarily so that people do not exhaust them too quickly. Like when > > you would uhmm... assign a separate MAC address to every bloody L3 > > network devices subnet ;-) > > > >> (There is a complication in the switch caused by optimisation for > >> multicast, because MLD snooping has to look at both L2 and L3 > >> headers. But BRSKI proxying only has to look at L3.) > > > > Only stupid MLD snooping needs to look at L2, but most MLD snooping is stupid ;-) > > > >> (There is more complication potentially caused by VLANs.) > > > > Indeed, i forgot. By default, multiple L3 subnets on a single physcial > > ethernet will very often get the same MAC address. And it's quite > > common for a router to just have such a trunk L3 interface. > > > >>> I just meant that a second link-local address could solve the > >>> problem if multiple interfaces have the same link-local address. > >> > >> s/multiple interfaces/multiple L3 interfaces/ > > > > "subnets" in IETF lingo ;-) or "read what i mean" ;-) > > > >>> We should move this discussion to v6ops to get feedback from folks > >>> with more insight - once we get a better understanding why some > >>> UDP encap would not be the more logical option. Just because i may > >>> not have link-local address issues does not mean that IPinIP gives > >>> me the degree of lightweight impleemntation options i would like to > >>> have (at app level). > >> > >> Agreed. IMNSHO this is not cooked yet and should not be mentioned > >> in a standards-track draft unless we want a very long discussion > >> with the IESG. > > > > Yes > > > > Toerless > > > >> Brian > >> > >>> > >>> Cheers > >>> Toerless > >>> > >>>>> Not quite "means nothing to it". > >>>>> The registar will have to build connection state and the connection key is > >>>>> > >>>>> [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] > >>>> > >>>> Right, but it isn't used as an IP address on a real interface. > >>>> > >>>>> Given how my claim is that multiple Lxi may be the same AND that as > >>>>> you already said, Lp may be the same, we need another field to > >>>>> distinguish those connections. > >>>> > >>>> If that was a real problem, which I don't think it is, we would have to > >>>> include the relevant interface number as used inside the proxy's stack. > >>>> (There's a horrible trick used only in the FreeBSD stack to do this, by using > >>>> some of the spare bits in a link local address for this purpose. > >>>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index ) > >>>> > >>>>> C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi. > >>>>> But given how ACP addresses are backed by certificate, its not as > >>>>> easy to get more ACP addresses as it would be in less secured > >>>>> transport substrates. > >>>>> > >>>>> Solutions: > >>>>> > >>>>> I would change the encap from IPinIP to some UDP header variation: > >>>> > >>>> Yes, while I was studying this I wondered why not just use IP-in-UDP. > >>>> It still allows the proxy to be dumb. > >>>> > >>>> I'd like to hear from Michael Richardson on all this. Again, my goal > >>>> is to understand enough that we can get the representation in the GRASP > >>>> objectives right. > >>>> > >>>> Brian > >>>> > >>>>> I want to be able to implement pledge, proxy and registar as > >>>>> simple apps using just UDP sockets. Thats something i can implement > >>>>> anywhere i want. > >>>>> > >>>>> Unless someone comes up with some pre-existing encap that makes > >>>>> life easy, i would just make the proxy insert a link-local > >>>>> pseudo header between the UDP header and the original pledges UDP payload. > >>>>> pseudo header would need to contain (Lp). Then in addition, > >>>>> the proxy would need to open a separate UDP socket for each local > >>>>> interface it has. That would make all UDP packet from proxy use a separate > >>>>> RemotPort on the registrar. The benefit of this approach is that i could > >>>>> start separate ASA, one for each interface, and if one interfaces proxy > >>>>> is attacked by pledges, it will not have an impact on other interfaces. > >>>>> And i minimize unnecessary headers. > >>>>> > >>>>> Relevant connection key is then: > >>>>> > >>>>> [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ] > >>>>> > >>>>> Aka: Lxi is irrelevant and can be ignored by registrar. > >>>>> > >>>>> Given how this is not a throughput relevant proxy function i do not > >>>>> care avbout the fact that i must recalculate UDP checksums over the > >>>>> packet (something that has bothered UDP tunneling solutions in the IETF > >>>>> for years now). > >>>>> > >>>>> Cheers > >>>>> Toerless > >>>>> > >>>>>> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge. > >>>>>> Since the proxy will have at least two interfaces, the address Lp might > >>>>>> exist on multiple LANs. However, the proxy will have different link-local > >>>>>> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2} > >>>>>> will be unique. Hence the registrar can distinguish the transactions. > >>>>>> > >>>>>> So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar. > >>>>>> Nothing else - no port number, no link-local address. > >>>>>> > >>>>>> What the proxy needs to tell the pledge is: I accept BRSKI/TCP > >>>>>> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact > >>>>>> the registrar, it simply forwards the packets as-is in both directions, > >>>>>> encapsulating and decapsulating accordingly. The pledge knows nothing about > >>>>>> IPIP. > >>>>>> > >>>>>> Regards > >>>>>> Brian > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Anima mailing list > >>>>>> Anima@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>> > >>> > > -- --- tte@cs.fau.de From nobody Sat Jul 8 22:23:47 2017 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 EFD1C126D85 for ; Sat, 8 Jul 2017 22:23:45 -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 43xxUeDlGOIU for ; Sat, 8 Jul 2017 22:23:44 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 6E1441200B9 for ; Sat, 8 Jul 2017 22:23:44 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q86so34712295pfl.3 for ; Sat, 08 Jul 2017 22:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=8Df4QbvBOxyM01xB44hxaO73L+/22lReFaetOLGpLWk=; b=iyDvV2IWlIddLNAQuNKkHFm+6bmURdziNXnaSzwxUPBe9c+HIMyopkEAQxQ9acqTd8 pdiBUUWvDbl0pDYpPmttICWReJQpgJ0ul3HwYNT02OENAgpwVe2C5dsbayGX0sgLBb7N 4UQdvLSHFNfk7pAE6DMk9OKrdvYaS5WFceQjVXwMoBBFCiwzpkp5x32dICZgBxTOwoDO HH/XBkXV1c1GUlQFHiudvobHLD4U4c8l8WYcR0Jem4eCgjFJRyPF4fyR0pkD0A2ih4FD 9BYzOAXEhKTkshl9j4zUVaZy2ach3YpN2Sm4gwOauYRI6CY7xv3VAvfvir4ddC9bSXCd ihRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=8Df4QbvBOxyM01xB44hxaO73L+/22lReFaetOLGpLWk=; b=FCkirklf31u5ROiy2ryiu+tCBSxELhIu1eVA5OI6Q/wuE9o31H/ZQ9w6zdFxdShrB/ t68od1vOWg+oRQpUNtFqr4l9QOQp/kA0YW8VRSg5KlOgjY3khaE5255oLq8cB3MB7jdi rrlsZm/P2QXQIoH3gUNZ+KJX2df/q81fHvy8soCkPzNF3nQJGVfBFN2Fy9tLAIAKu6PZ zSj48UFWTBwNTX83HPm1gxgdTLTDp2MjljzffSQnBKLfv94VuPThfJqn2KVeoMt7X8k/ nRCoP2pUEcPfOKSElixL6MVhyHPFlkjeLBSlCh0SFlnLFL7WpEZ6JXrGME7VA+XA5M/G pBGQ== X-Gm-Message-State: AIVw1100YDmhVIlztd41nmdA2J+1LEbRykUGa2ohkxr+AqcG3YVIsM1D BXCG0Hm/jLk+QiAM X-Received: by 10.84.232.198 with SMTP id x6mr11425162plm.139.1499577823852; Sat, 08 Jul 2017 22:23:43 -0700 (PDT) Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j14sm14165939pgt.7.2017.07.08.22.23.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 22:23:43 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <9195a300-186a-7e13-8ae3-ee20ffecdcb1@gmail.com> Date: Sun, 9 Jul 2017 17:23:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Demo code for BRSKI objectives X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jul 2017 05:23:46 -0000 Hi, fwiw I have uploaded a new version of my demo code for the BRSKI-related GRASP objectives. The purpose is not to write code, but to clarify what we really want... so comments and criticisms are welcome. Anybody can read Python, even if they can't write it yet. The objectives are not as described in the latest BRSKI draft, but roughly as described in https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02 Start with the documentation: https://github.com/becarpenter/graspy/blob/master/brski-demo.pdf Brian From nobody Mon Jul 10 13:21:54 2017 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 4DFF412F258 for ; Mon, 10 Jul 2017 13:21: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 T_h8koOFGO1q for ; Mon, 10 Jul 2017 13:21:50 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586461318A4 for ; Mon, 10 Jul 2017 13:21:49 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id t186so55114743pgb.1 for ; Mon, 10 Jul 2017 13:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=meWiZB0aBtVChD7+5jWZeUEspawaTgylTPBWq4MD1RQ=; b=E6UdHc0iCtrukUYZcYxgz79LxO4UZPiyDCQTHkp5GKSUUyeHkw6MebfiQygzETW/JT qvvxabU+Fh8NajfIVU9zdrhkYub1pagUksVSOfzffbqBbN1UUov3gnlM0YKSzHb3JvY2 exU3mn2/LrKY2Y+5bRI/AI9lHY5cpijM1mAIJ1VfYkR36XubLSBenM2fSt/dwKxJrgmu 2Udq17XAK+eD1VVsgPr3DY5fizqI1/NlA78uAUwY0Po7de9TfyxIsYgzLlVy6lbAzB6W gdBjDBHV+9U749DtNgoC9o/cguyg0MAz34p6zo/pWMcP7HdsgIf4mY3yyKTvx4k4AGkH QaJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=meWiZB0aBtVChD7+5jWZeUEspawaTgylTPBWq4MD1RQ=; b=S1O3D+5Eh/NSUAGl3U+XUFDctrFiOWd02f4q8h5/z71i7TeUGs6nFjGf3PIU6jbHDa MOMglhzvl23WbbpXA1xZ9Z64CNpGt58cp/1v5WBYWIEmi5WsYotAx6BLaCuv9IoeNL/4 aJixdNzDM/fQ9IRAdsM59xmSohLRFylCpZtubJzxBRylLarGbp5jBSkJO87E1zIV+/gZ 13LD7WLFM7nVFwxQbncCSqD9hW/UZfIBAShBBIKOXwjoE0nJi3zzm5TESFveQz92RXX9 aMf+3jPqatATrXflquwiEqiItOFLqx5UEknc9G1t27fmIXZwbMMZFf/+MsVJmn7J3GV1 f41Q== X-Gm-Message-State: AIVw1132bcQITvYTiF+lI4QQjHYoLnepY1WLcdrOocwQ0SZrHqxeY1bX hQ+wzRgVmgiNAvKQ X-Received: by 10.99.115.85 with SMTP id d21mr16717208pgn.8.1499718108772; Mon, 10 Jul 2017 13:21:48 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id i19sm27323286pfj.78.2017.07.10.13.21.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 13:21:48 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 11 Jul 2017 08:21:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] draft-ietf-anima-grasp-15 OK X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 20:21:53 -0000 Hi, This version of GRASP hasn't been posted yet due to the pre-IETF posting cutoff, but it has allowed both IESG DISCUSS ballots to be cleared. The main difference is that the text about the security and transport substrate provided by the ACP has been rewritten (by Toerless, thanks!). There is no change in the intentions. We expect this version to be formally approved by the IESG when it's posted officially. https://raw.githubusercontent.com/becarpenter/animaproto/master/draft-ietf-anima-grasp-15.txt Diffs at: https://www.cs.auckland.ac.nz/~brian/Diff-draft-ietf-anima-grasp-14-15.htm Regards Brian, Bing, Carsten From nobody Mon Jul 10 19:47:28 2017 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 57480129503 for ; Mon, 10 Jul 2017 19:47:27 -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 5vyBvv63Dykc for ; Mon, 10 Jul 2017 19:47:25 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16415127136 for ; Mon, 10 Jul 2017 19:47:23 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id k14so59057447pgr.0 for ; Mon, 10 Jul 2017 19:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fTCos5VRikJILfYh1aPRVPBW7/JNKQblPiYSpDrjExQ=; b=nCgncuPSQ3MQqePrInSdGkWpIqHK9pMImlH6UDw4OpTjb/mlfOeFTf15w1f4aa+f78 2hVfQRm+YfPhZMcA0v4kLJmJiCFNfTCRef5lgvXCqzdZ+UTjwnopwPFYcyZfsXNjNWNr ZHsxXWei/bxmLk0FalkyAD2QNCXNOCs7hD4SCiyKdGzULIDPAc6it3mLyMQXyZEB8009 GeEWa5ej/NeyebgjfbDq5tLeRhonYa2FFc1t8bng6p9rTY8saRypa7ttRT5Hq2kVdUUa l7KNfzgoyZjHTgaeJqMwV16bzw+FFMJSssqa+QBslMHBgrcxHueIjxD7WDHbN+dA7Eto WegQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fTCos5VRikJILfYh1aPRVPBW7/JNKQblPiYSpDrjExQ=; b=Us2HxsHvt0qcRdgUFjZZ/rNqJk/IXgDR0qi27XvOfQXvxyhOn5H3ovlHWKFIAdPQh9 S3IofFbFUGUWu3h6X3mfJ6F7xotFOrZvQJ2B6PrbcYHkNq6eulit65JghhTcbd8J/4BF y8vJRv02tZM1cenbBOmpy9IuWW7dAIHIXMgMdB05GEl5ILWNDVL1PqfB0ZUejFuOSgSb MHCXJkjvmgIjuGRHm6TAt33IO8jIE01qkJ5PLoM9JK2zljUuEaOE3GsB2jZ9G7FvWusn JbetMddHnuP3Pnnhr0Kr5tieZ0ApGa0pUEvQubCpgqjuPuCjenGVrVBSnb5dJaFro1UT A57Q== X-Gm-Message-State: AIVw113Vz1lMivDH+7cqJxmusSLqWmhBHXDurzGT70sYh+cyApmJsMOz ngSNuYRjm2hEhTDJ X-Received: by 10.84.218.71 with SMTP id f7mr21312326plm.282.1499741242404; Mon, 10 Jul 2017 19:47:22 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id q3sm20858667pfk.8.2017.07.10.19.47.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 19:47:21 -0700 (PDT) To: Anima WG References: <149879102820.4634.18247017002883901441@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 11 Jul 2017 14:47:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jul 2017 02:47:27 -0000 Hi again, There are various bugs in that version, due to the hurry. We will try to get a better version out as soon as draft posting is possible next week. The code described at https://github.com/becarpenter/graspy/blob/master/brski-demo.pdf is more correct than the -02 draft. Regards Brian On 30/06/2017 15:01, Brian E Carpenter wrote: > Hi, > > As Sheng suggested, this is a complete update of the GRASP > objectives for BRSKI, the ACP and the stable-connectivity draft. > I apologise to Bing, my co-author, for not checking with > him, but time was rather short. > > As far as BRSKI goes, this is intended to simply replace all > the GRASP-related details in sections 3.1.1 and 3.1.2 of > draft-ietf-anima-bootstrapping-keyinfra-06. > > Please don't waste time on the diffs from the -01 version, > there are too many changes and deletions. > > I haven't had time to update my demo code for this new version; > if I manage to do that before the IETF I will let you know. > > Regards > Brian > > On 30/06/2017 14:50, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Technical Objective Formats for the Autonomic Network Infrastructure >> Authors : Brian Carpenter >> Bing Liu >> Filename : draft-carpenter-anima-ani-objectives-02.txt >> Pages : 9 >> Date : 2017-06-29 >> >> Abstract: >> This document defines the formats of several technical objectives for >> the Generic Autonomic Signaling Protocol (GRASP) used by components >> of the Autonomic Networking Infrastructure outlined in the ANIMA >> reference model. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-anima-ani-objectives/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02 >> https://datatracker.ietf.org/doc/html/draft-carpenter-anima-ani-objectives-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-ani-objectives-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 Tue Jul 11 17:44:41 2017 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 28C3613181E for ; Tue, 11 Jul 2017 17:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5npL4VkId613 for ; Tue, 11 Jul 2017 17:44:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71033131705 for ; Tue, 11 Jul 2017 17:44:36 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:b:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 9FE161F906; Wed, 12 Jul 2017 00:44:33 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id E1F1AE43; Tue, 11 Jul 2017 20:44:31 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-reply-to: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 06 Jul 2017 14:19:23 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Jul 2017 20:44:31 -0400 Message-ID: <14885.1499820271@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 00:44:39 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Is the following correct? > Topology (ASCII art): Topology is essentially correct. As you point out, RFC7217 is the recommendation going forward, so having a a big IEEE OUI allocation isn't necessary anymore. But, the problem is you have a single Ax for the device. The ACP needs to allocate Ax1 for LAN1, and Ax2 for LAN2, etc. That's why I wanted a /96 or so provided by the ACP to each device. So it becomes: > Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1] > Proxy sends to Registrar [Ax1, Ar, 41, [Lp, Lx1, 17, UDP-PAYLOAD1]] > Registrar replies to proxy [Ar, Ax1, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]] > Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2] Toerless says that a non-priveledged process (the proxy) can't easily configure additional LL addresses. That's true. It also can't configure the addresses for the ACP. The ACP needs to do that. The Lx1 and Lx2 could be identical, although I'd not want to design my device that way. I looked at the CDP/LLDP spec, and both are unclear what the source L2 address is. > So, what the registrar needs to tell the proxy is: I accept IP in IP on > address Ar. Nothing else - no port number, no link-local address. There is a small problems with this. With a UDP transport, we simply have to arrange for the registrar to accept traffic to any LxX IP address. That's not stock POSIX, but it's not that hard. LxX state can be handled by the application. With TCP the kernel has be rather flexible, being able to keep duplicate Lp<->Lx1 connections seperate in the kernel, and at the same time, permitting any LxX on the Registrar's side. Instead, I have two suggestions, not entirely mutually exclusive: 1) the Registrar says, "I accept IPIP on Address Ar, use Lr for connections" 2) we make Lr = well known Link-Local anycast address In my implementation, I dynamically set up an IPIP interface for each Lx on each proxy that appears. The kernel assigns a new ifindex to each of these interfaces, and the normal LL-requires-ifindex rules apply to distinguish things. This requires a retransmission since the first time there is a packet from a new Ax1/LAN1, the packet does not match any current IPIP tunnel, and is dropped by the kernel. A process watches for these and configures them LRU. > What the proxy needs to tell the pledge is: I accept BRSKI/TCP or > BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact the > registrar, it simply forwards the packets as-is in both directions, > encapsulating and decapsulating accordingly. The pledge knows nothing > about IPIP. It needs to know it's IPIP, but I think you mean, it knows nothing about what's inside the inner IP header. There is some work (which I've yet to complete) to arrange to forward LL-IP packets coming out of the IPIP interface to the physical interface, since LL packets are normally never forwarded. Really, this is a kind of bridge (that's what I'll tell the v6-police). As for Toerless' notion that we should invent a new UDP-based encapsulation rather than use the well defined IPIP encapsulation, I have really no comment. I'm pretty sure that many will want to leverage existing v6-extension header chasing hardware for the purpose of auditing, which is why I prefer not to invent new on-the-wire formats just to so that some software engineer can avoid having to learn a new API call. -- ] 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----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZXDvAAoJEJVM4Vb9/EKQUscIAKTLl10+TOH1zbolzxLYOAs/ 8lYUwcUTdbNAaQaO00pOJOEeVlm+A2PrEFb+X3RO+garrf35H6BPo+XTrQKkwpX8 t7QnTkXShL4OdxhinKg0y73q/EZ0Wk36cHRaVCa+2vy+Pbkl2dxZIsF3yGapyon/ 1hqZoKj2IYVLYtk+NDXovzIBlfRx0xvTLc0gmKGLSQfZvuYN4quih7Wz/2uXewb4 o52dhUVInvfVmhvCsePyiCyoKvjqDuv+IL1ICRAjm6QtxH2sRq/npuGz9A/Iv6bB rOHx05mMbS1PH1tEKAP+yjo3UTS7wGyFZyJYDd5pcQ1mkJObQOVEgNyK7mlBqUg= =gyvw -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 11 17:47:40 2017 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 E4F2C12EB69 for ; Tue, 11 Jul 2017 17:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrk0MREQ3qOm for ; Tue, 11 Jul 2017 17:47:38 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E8B129A96 for ; Tue, 11 Jul 2017 17:47:38 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id CB80A1F906; Wed, 12 Jul 2017 00:47:36 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 17209E43; Tue, 11 Jul 2017 20:47:35 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-reply-to: References: Comments: In-reply-to Brian E Carpenter message dated "Tue, 04 Jul 2017 17:32:06 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Jul 2017 20:47:35 -0400 Message-ID: <15780.1499820455@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 00:47:39 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > But the third locator sent by the Registrar indicates a meaningless > link-local address, because it could come from many hops away. At first > I thought this was a confusion with the previous (proxy-to-pledge) > case, where all addresses must be link-local. But no: this text is just > confused, I think: This LL address is the Lr from my email of three minutes ago: mcr> Instead, I have two suggestions, not entirely mutually exclusive: mcr> 1) the Registrar says, "I accept IPIP on Address Ar, use Lr for mcr> connections" mcr> 2) we make Lr = well known Link-Local anycast address I included Lr in the protocol, even if we might decide that we want to make it well-known. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZXGmAAoJEJVM4Vb9/EKQ0qwH/3BYSmxCU6WpNWk1zrU2DkXx dsU33eHMMYs7ZFtoTvFSIfaV/XuOneCvsSrAHSEUK11XoAAUzQO0/soyPyigSbWd Tq3zGC5QgZfKbk41D+6sM+Ll/DvNcK1SBGXZI5TP4D/XP4Ppk+9Da3Fh9NkDwgvu P9tUcqW+eEChRdOixBgvAvonUYxOMNf5RBMIfpIYON1kjoWxhnI9uZRlmkWMVlSL hDhvlg2+WFs+w2pgLMHHEi/X7AJTFy0t/4o+EaLu1zZJeZ5BCut1ik9i8REDrJzV w943trnPYb+jJlyDMq8WAzPf3rZg39EfI3xJXvFskYrqsFxLmZ/XXOXva5e0FNw= =76hd -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 11 19:02:49 2017 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 304E7126D46 for ; Tue, 11 Jul 2017 19:02:48 -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 9IJchmcaovaU for ; Tue, 11 Jul 2017 19:02:46 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 3E1231241FC for ; Tue, 11 Jul 2017 19:02:46 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u62so4918643pgb.3 for ; Tue, 11 Jul 2017 19:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vwq+ocrUeLttGObJmKyDx5/rgheqMWnJJ6Wj31DGHBc=; b=iQu76tGtthGNIm6pQ5JKlO6b74Y6+ORV7YuXaFXyslxQjm9R7OquCJNiGBxjiNH/he MGnSS5UptjWfHzm0QjFog7JZJZtIOxud3TgogzgteeuC3asAm6RYe6WBFYakkR2ddgWP rYgWZPjH4eaLJ8Yh9h1UatGv7NYTRdH7m9aF5kUuVMReDyH0A4omk+abPTLvow8FZFjh E3etgSy6tV3/Pca9ggnW5WbAabG5kkHpNti9v9JPCTFkfMdipDSl3rlGGBoZEfbYljkB ZCHmVGxkeeCYK3uPWGjUpXNmwGPH1wVixY8uocLgTDCgvtaR/3tR0nvxcZJXO/hBUn3/ bw9w== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vwq+ocrUeLttGObJmKyDx5/rgheqMWnJJ6Wj31DGHBc=; b=dRx3/pC6i17lWLHry1xTz0nPL5Sl6/gb/3bBWgfnSaFx4xCGdhe1oAaqW8IW5GBgev OlCXI39JC86fOc2fXO4u9zMo2tkAmvgQ4UAWFQTx/3Vx9F2ESIlH6w8T4KptGmHEV3mU F7aEC+kcKCNSFFz5qyyV/8mwBdURaql1OuQcGolEMGek+dDEM6LGcuwgnQrdp4pA5Chj PeoXGKiS+4XQDStPjrP73u1PRiP++eehJhzPNr1mYZlPFs04AS+4Y+5PhfF11Jvfi28s hjLg73/NB+uLwVAPvW66p+Iq8iNZV/goZTMT7BwOOcy+auXjNQ7CH71/AHBIUsfEmD3V VeLw== X-Gm-Message-State: AIVw110/7+cCOAOJ2W8HJEobO4zUPasETh4sWED/mdtM3TgGtUHNdwFG wkzbM6p57cmdlc7n X-Received: by 10.99.60.68 with SMTP id i4mr1436432pgn.250.1499824965098; Tue, 11 Jul 2017 19:02:45 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id q67sm1136359pfi.81.2017.07.11.19.02.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 19:02:44 -0700 (PDT) To: Michael Richardson Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> Date: Wed, 12 Jul 2017 14:02:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <14885.1499820271@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 02:02:48 -0000 On 12/07/2017 12:44, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Is the following correct? > > > Topology (ASCII art): > > Topology is essentially correct. > As you point out, RFC7217 is the recommendation going forward, so having > a a big IEEE OUI allocation isn't necessary anymore. > > But, the problem is you have a single Ax for the device. > The ACP needs to allocate Ax1 for LAN1, and Ax2 for LAN2, etc. Yes, that would disambiguate it. But in general it isn't necessary for a node to have multiple ACP addresses just because it has multiple interfaces, is it? > That's why I > wanted a /96 or so provided by the ACP to each device. That would be one way, but it will create noise in 6man. In any case if the requirement is one address per proxy+interface I'm sure it can be done somehow; IPv6 addresses are cheap. > So it becomes: > >> Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1] >> Proxy sends to Registrar [Ax1, Ar, 41, [Lp, Lx1, 17, UDP-PAYLOAD1]] >> Registrar replies to proxy [Ar, Ax1, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]] >> Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2] > > Toerless says that a non-priveledged process (the proxy) can't easily > configure additional LL addresses. That's true. It also can't configure the > addresses for the ACP. The ACP needs to do that. > > The Lx1 and Lx2 could be identical, although I'd not want to design my device > that way. I looked at the CDP/LLDP spec, and both are unclear what the > source L2 address is. > > > So, what the registrar needs to tell the proxy is: I accept IP in IP on > > address Ar. Nothing else - no port number, no link-local address. > > There is a small problems with this. With a UDP transport, we simply > have to arrange for the registrar to accept traffic to any LxX IP address. > That's not stock POSIX, but it's not that hard. LxX state can be handled > by the application. With TCP the kernel has be rather flexible, being > able to keep duplicate Lp<->Lx1 connections seperate in the kernel, and > at the same time, permitting any LxX on the Registrar's side. > > Instead, I have two suggestions, not entirely mutually exclusive: > 1) the Registrar says, "I accept IPIP on Address Ar, use Lr for connections" I don't understand where Lr would be used. The LL messages are all between the pledge and the proxy, which have perfectly fine LL addresses of their own. > 2) we make Lr = well known Link-Local anycast address > > In my implementation, I dynamically set up an IPIP interface for each Lx > on each proxy that appears. The kernel assigns a new ifindex to each of > these interfaces, and the normal LL-requires-ifindex rules apply to > distinguish things. This requires a retransmission since the first time > there is a packet from a new Ax1/LAN1, the packet does not match any current > IPIP tunnel, and is dropped by the kernel. A process watches for these > and configures them LRU. > > > What the proxy needs to tell the pledge is: I accept BRSKI/TCP or > > BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact the > > registrar, it simply forwards the packets as-is in both directions, > > encapsulating and decapsulating accordingly. The pledge knows nothing > > about IPIP. > > It needs to know it's IPIP, Why? The IPIP encapsulation and decapsulation can happen inside the proxy (and the registrar). Why does the pledge care? > but I think you mean, it knows nothing about > what's inside the inner IP header. There is some work (which I've yet to > complete) to arrange to forward LL-IP packets coming out of the IPIP > interface to the physical interface, since LL packets are normally never > forwarded. Really, this is a kind of bridge (that's what I'll tell the > v6-police). > > As for Toerless' notion that we should invent a new UDP-based encapsulation IPv6-over-UDP isn't exactly a new invention. It's been used in Teredo, TSP (RFC5572) and SixXs (https://tools.ietf.org/html/draft-massar-v6ops-ayiya-02). More to the point, draft-ietf-intarea-gue is in progress. All the same, if straight IPIP works, so much the better. Brian > rather than use the well defined IPIP encapsulation, I have really no comment. > I'm pretty sure that many will want to leverage existing v6-extension header > chasing hardware for the purpose of auditing, which is why I prefer not > to invent new on-the-wire formats just to so that some software engineer can > avoid having to learn a new API call. > > -- > ] 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 =- > > > From nobody Tue Jul 11 19:04:05 2017 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 979BB1241FC for ; Tue, 11 Jul 2017 19:04:04 -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 dE9LvfzQ_iMf for ; Tue, 11 Jul 2017 19:04:03 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B1712EC0E for ; Tue, 11 Jul 2017 19:04:03 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u62so4933282pgb.3 for ; Tue, 11 Jul 2017 19:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x/1qJNURolxKPqcernwR1JZwGSE8JFYTpKN4mW7PifM=; b=CkveRBqUdrJQToTRohbNmaW8HuOdZ/OcSZi6pq5oOQ1MdabXKRgzwjRACnFW+sL/7L syEE/lbQVXClFB8xhe+b8uhuODohjMTm18wuGzRpa9V4UAi9yXRexK67xejLhA0ZcvB4 SGCaWI1pbpCJRloLv0jWfvDQI2fflQn/X7pHjC9w+4BIQ0UtQykLr1S0Eab/UetXHDHh gpIDxvw8iN/Qd+cO6zE6oPsNMBfXVGMlOhDI5lPkUeQHI3/BTqnICbdHPASB5zVLidCv EarNQvS4zWV3lpdqnP8bbUzTQCV0/w73h76ObhsTsnDNlnK6ureZQe9E0VpymN9jiDgI Tpyw== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=x/1qJNURolxKPqcernwR1JZwGSE8JFYTpKN4mW7PifM=; b=T6RAlTHOkrisCpXFfRQzzTPgRfyebhga2FiJ95uxiADpptwov3ziZ4q4Wj6Mqz8rt+ +4nY7IYnbAbGrWyYdhiQ24/iwyvZfqW+z5fDLTy2ijvKDKmKBCyq4soTQbZiuaH+JXwa dO/E2PIFLaArLTupysXk+vrbfAXZ679Lb6amMbnkoztjhM7b17BwZPp/pdeassrMsZL5 PaK2Af6H1vX+sJ1evlQdosaQzdQe8D9ttnGN4t55PlrhZcshLOxDNE/Ewyuz+OftvAIw ecAgymq5sHGs4+aQPhwMO5Iv1A0Lkadj9pYsn35dloAIA10UlxUJ8ZafRmqISa8R8/hR FuJg== X-Gm-Message-State: AIVw111j09BA+9JdMB+ZNORjfHBnaQliTOLKZJg3xPM66atBbYjx359O SwMR0x0i9yeEyS2q X-Received: by 10.99.119.198 with SMTP id s189mr1486874pgc.32.1499825042691; Tue, 11 Jul 2017 19:04:02 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id x85sm1106299pff.92.2017.07.11.19.04.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 19:04:02 -0700 (PDT) To: Michael Richardson Cc: Anima WG References: <15780.1499820455@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 12 Jul 2017 14:04:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <15780.1499820455@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 02:04:05 -0000 On 12/07/2017 12:47, Michael Richardson wrote: > > Brian E Carpenter wrote: > > But the third locator sent by the Registrar indicates a meaningless > > link-local address, because it could come from many hops away. At first > > I thought this was a confusion with the previous (proxy-to-pledge) > > case, where all addresses must be link-local. But no: this text is just > > confused, I think: > > This LL address is the Lr from my email of three minutes ago: > > mcr> Instead, I have two suggestions, not entirely mutually exclusive: > mcr> 1) the Registrar says, "I accept IPIP on Address Ar, use Lr for > mcr> connections" > mcr> 2) we make Lr = well known Link-Local anycast address > > I included Lr in the protocol, even if we might decide that we want to make > it well-known. As I just said, I don't understand why this address is even needed. Brian From nobody Tue Jul 11 19:57:13 2017 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 E088312EC02 for ; Tue, 11 Jul 2017 19:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe0fgbd1Zf2P for ; Tue, 11 Jul 2017 19:57:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC25812955F for ; Tue, 11 Jul 2017 19:57:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQX89837; Wed, 12 Jul 2017 02:57:08 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Jul 2017 03:57:07 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 12 Jul 2017 10:57:03 +0800 From: Sheng Jiang To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] draft-ietf-anima-grasp-15 OK Thread-Index: AQHS+bo2DPJp9exJJ0qPeTbqSn3hZqJPgRKA Date: Wed, 12 Jul 2017 02:57:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDFBBFD@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59659004.006B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a8c76fa0975fea1784b93a8ebcacaa14 Archived-At: Subject: Re: [Anima] draft-ietf-anima-grasp-15 OK X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 02:57:12 -0000 Thanks Brian and coauthors for their great and fruitful work. This would be= the first RFC from ANIMA WG. Best regards, Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Tuesday, July 11, 2017 4:22 AM > To: Anima WG > Subject: [Anima] draft-ietf-anima-grasp-15 OK >=20 > Hi, >=20 > This version of GRASP hasn't been posted yet due to the pre-IETF posting = cutoff, > but it has allowed both IESG DISCUSS ballots to be cleared. The main diff= erence > is that the text about the security and transport substrate provided by t= he ACP > has been rewritten (by Toerless, thanks!). There is no change in the inte= ntions. > We expect this version to be formally approved by the IESG when it's post= ed > officially. >=20 > https://raw.githubusercontent.com/becarpenter/animaproto/master/draft-iet > f-anima-grasp-15.txt >=20 > Diffs at: >=20 > https://www.cs.auckland.ac.nz/~brian/Diff-draft-ietf-anima-grasp-14-15.ht= m >=20 > Regards > Brian, Bing, Carsten >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jul 11 23:09:56 2017 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 52604127369; Tue, 11 Jul 2017 23:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZHxbckIJoGB; Tue, 11 Jul 2017 23:09:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232EF1201F2; Tue, 11 Jul 2017 23:09:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKF04221; Wed, 12 Jul 2017 06:09:51 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Jul 2017 07:09:50 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 12 Jul 2017 14:09:45 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: Primary ANIMA agenda @ IETF 99, Prague, Czech Thread-Index: AdL61XM/W5mgkAHCQIWU+BP9FNSAog== Date: Wed, 12 Jul 2017 06:09:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDFC094@NKGEML515-MBX.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_5D36713D8A4E7348A7E10DF7437A4B927CDFC094NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5965BD2F.007C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 50f04af41738ab434167d88e1ab44d06 Archived-At: Subject: [Anima] Primary ANIMA agenda @ IETF 99, Prague, Czech X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 06:09:55 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CDFC094NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, ANIMA all, The chairs have uploaded a primary meeting agenda for our ANIMA WG sessions= in Prague, Czech. Wednesday, 9:30-12:00, Congress Hall III, Morning session I https://datatracker.ietf.org/meeting/99/agenda/anima/ If there is any question or request on the agenda, please let the chairs kn= ow. The speakers please send your slides to the chair in advance, so that we co= uld upload them before the meeting. The slides are due before midnight on M= onday, July 17th. Best regards, Sheng + Toerless --_000_5D36713D8A4E7348A7E10DF7437A4B927CDFC094NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, ANIMA all,
 =

The chairs have u=
ploaded a primary meeting agenda for our ANIMA WG sessions in Prague, Czech=
.
 =

Wednesday, 9:30-1=
2:00, Congress Hall III, Morning session I
 =

https://datatracker.ietf.o=
rg/meeting/99/agenda/anima/
 =

If there is any q=
uestion or request on the agenda, please let the chairs know.
 =

The speakers plea=
se send your slides to the chair in advance, so that we could upload them b=
efore the meeting. The slides are due before midnight on Monday, July 17th.=

 =

Best regards,
 =

Sheng + Toerl=
ess

 

--_000_5D36713D8A4E7348A7E10DF7437A4B927CDFC094NKGEML515MBXchi_-- From nobody Tue Jul 11 23:16:23 2017 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 8698C12EC19; Tue, 11 Jul 2017 23:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Fazp8GhOwzB; Tue, 11 Jul 2017 23:16:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC621201F2; Tue, 11 Jul 2017 23:16:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQY12552; Wed, 12 Jul 2017 06:16:18 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Jul 2017 07:16:17 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 12 Jul 2017 14:16:05 +0800 From: "Liubing (Leo)" To: Sheng Jiang , Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: Primary ANIMA agenda @ IETF 99, Prague, Czech Thread-Index: AdL61XM/W5mgkAHCQIWU+BP9FNSAogAAIQsg Date: Wed, 12 Jul 2017 06:16:05 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F80626@nkgeml514-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFC094@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CDFC094@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2F80626nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5965BEB2.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: eb1bb80e495732438087ea3ef858d31e Archived-At: Subject: Re: [Anima] Primary ANIMA agenda @ IETF 99, Prague, Czech X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 06:16:23 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2F80626nkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sheng and all, The agenda seems incomplete in the link below. But it is interesting that in another link it is complete: https://www.ietf= .org/proceedings/99/agenda/agenda-99-anima-00 . I guess it's a bug of the ietf site? B.R. Bing From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Wednesday, July 12, 2017 2:10 PM To: Anima WG Cc: anima-chairs@ietf.org Subject: [Anima] Primary ANIMA agenda @ IETF 99, Prague, Czech Hi, ANIMA all, The chairs have uploaded a primary meeting agenda for our ANIMA WG sessions= in Prague, Czech. Wednesday, 9:30-12:00, Congress Hall III, Morning session I https://datatracker.ietf.org/meeting/99/agenda/anima/ If there is any question or request on the agenda, please let the chairs kn= ow. The speakers please send your slides to the chair in advance, so that we co= uld upload them before the meeting. The slides are due before midnight on M= onday, July 17th. Best regards, Sheng + Toerless --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2F80626nkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shen= g and all,

&n= bsp;

The age= nda seems incomplete in the link below.

But it = is interesting that in another link it is complete: h= ttps://www.ietf.org/proceedings/99/agenda/agenda-99-anima-00 .

&n= bsp;

I guess= it’s a bug of the ietf site?

&n= bsp;

B.R.

Bing

&n= bsp;

From: Anima [mailt= o:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Wednesday, July 12, 2017 2:10 PM
To: Anima WG
Cc: anima-chairs@ietf.org
Subject: [Anima] Primary ANIMA agenda @ IETF 99, Prague, Czech<= /o:p>

 

Hi, ANIMA all,
 =

The chairs have u=
ploaded a primary meeting agenda for our ANIMA WG sessions in Prague, Czech=
.
 =

Wednesday, 9:30-1=
2:00, Congress Hall III, Morning session I
 =

https://datatracker.ietf.o=
rg/meeting/99/agenda/anima/
 =

If there is any q=
uestion or request on the agenda, please let the chairs know.
 =

The speakers plea=
se send your slides to the chair in advance, so that we could upload them b=
efore the meeting. The slides are due before midnight on Monday, July 17th.=

 =

Best regards,
 =

Sheng + Toerl=
ess

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2F80626nkgeml514mbxchi_-- From nobody Wed Jul 12 08:57:29 2017 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 910CD1316FF for ; Wed, 12 Jul 2017 08:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0W_qhhDII86 for ; Wed, 12 Jul 2017 08:57:23 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CFD1316DA for ; Wed, 12 Jul 2017 08:57:22 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:b:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 370971F8FB; Wed, 12 Jul 2017 15:57:21 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5222CEBA; Wed, 12 Jul 2017 11:57:19 -0400 (EDT) From: Michael Richardson To: Anima WG In-reply-to: <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Wed, 12 Jul 2017 14:02:44 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 12 Jul 2017 11:57:19 -0400 Message-ID: <25643.1499875039@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 15:57:28 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Brian E Carpenter wrote: > Is the >> following correct? >> >> > Topology (ASCII art): >> >> Topology is essentially correct. As you point out, RFC7217 is the >> recommendation going forward, so having a a big IEEE OUI allocation >> isn't necessary anymore. >> >> But, the problem is you have a single Ax for the device. The ACP >> needs to allocate Ax1 for LAN1, and Ax2 for LAN2, etc. > Yes, that would disambiguate it. But in general it isn't necessary for > a node to have multiple ACP addresses just because it has multiple > interfaces, is it? We need a way to distinguish the different links (and scoope of the LL address) in a way that can be communicated easily and cheaply to the Registrar. I've asked for the "V"irtualization bit to be bigger, and I see no purpose for the Zone-ID myself. >> That's why I wanted a /96 or so provided by the ACP to each device. > That would be one way, but it will create noise in 6man. In any case > if the requirement is one address per proxy+interface I'm sure it can > be done somehow; IPv6 addresses are cheap. It's not a subnet for the device to announce, it's a large bag of /128s. >> Instead, I have two suggestions, not entirely mutually exclusive: 1) >> the Registrar says, "I accept IPIP on Address Ar, use Lr for >> connections" > I don't understand where Lr would be used. The LL messages are all > between the pledge and the proxy, which have perfectly fine LL > addresses of their own. Assume a TCP connection from the Pledge to the Registrar. It looks like, as you wrote: Pledge sends to proxy [Lp, Lx1, 17, TCP-PAYLOAD1] On the registrar, when it emerges from the IPIP tunnel, this is what the registrar sees. If we do nothing, the Registrar says, "Lx1"? What's that it's not me. Drop. So we have to do something. Options are: 1) Registrar accepts any Lx1 as local. 2) We pick a well-known Lx value (a LL anycast). 3) We have the Registrar tell the proxy an Lx value to use. 1) Registrar accepts any Lx1 as local. There is no precedent in v6 APIs to open such a socket, but this actually supported on many platforms. It's used for nasty stuff like transparent application layer proxies, forced HTTP proxying, and the like. 2) We pick a well-known Lx value (a LL anycast). The pledge has to do something slightly funky where it forces a particular L2 address for the anycast LL, because if there are multiple proxies on the network, straight ND will get one at random, and the Pledge actually wants to be specific about which one it uses. (since it wants to try them all) 3) We have the Registrar tell the proxy an Lx value to use. I chose to put this option into the protocol, because we can always set Lx= Lanycast in the future, and perhaps we can set it to :: if we want case (1). >> > registrar, it simply forwards the packets as-is in both directions, >> > encapsulating and decapsulating accordingly. The pledge knows >> nothing > about IPIP. >> >> It needs to know it's IPIP, > Why? The IPIP encapsulation and decapsulation can happen inside the > proxy (and the registrar). Why does the pledge care? Sorry. "Proxy" vs "Pledge" "IT" above referred to Proxy, but in fact it says "pledge". Typo. >> As for Toerless' notion that we should invent a new UDP-based >> encapsulation > IPv6-over-UDP isn't exactly a new invention. It's been used in Teredo, > TSP (RFC5572) and SixXs > (https://tools.ietf.org/html/draft-massar-v6ops-ayiya-02). More to the > point, draft-ietf-intarea-gue is in progress. > All the same, if straight IPIP works, so much the better. I resorted to using Ar as an additional signaling mechanism to "store" the ifindex where the request was coming from rather than try to find some bits in some other protocol like one you mention above. TSP is too complex for our needs. Teredo has some space for additional stuff. It should be straight forward to define it over IPv6 rather than v4. Seems a bit weird to me though. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZkbcAAoJEJVM4Vb9/EKQbvAH/2SS1bT26HyL5cYtemFTiBfp t8BMgZmwrD0O6cFdntJClwyv9dDkA+6i9xnKHMo0+rr4zK2JTB9JMoRnv0I3Ajs4 cu7PTsuPb+ceiqCliOcq9lOSiULArQ9BgxFZizEeZxOyD6/wTWI5YvbQM5c6F4FS Pd46XZnW0313Pk+vmMS+02i9gDGaMGx0V0KGOmkf7GVVxpBO5YBNTwkekuWF93IA 8+NXn1mDpaozRpqSKhwf8KysoWgJN3xIqXW5aCCW0L7JUVKMwF/R3KFj0jYlvHRN uBbboGtdKYOZfy98plbIii4e3SNuTGqJom3aVAqase7IZAPinKsFsSjGEZDIq14= =PQ7T -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 12 13:55:05 2017 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 A1C8412ECED for ; Wed, 12 Jul 2017 13:55:03 -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 KdpBsAuc242e for ; Wed, 12 Jul 2017 13:55:01 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 636FF126B6D for ; Wed, 12 Jul 2017 13:55:01 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id q85so18518087pfq.1 for ; Wed, 12 Jul 2017 13:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z0LW9kb22fgJrXTM0o17zUXVt5Ltr/GYsGYQxqGV2AU=; b=eNwZtnnq+NsStvTpb6BZSoY4Vr1Iww/GqTMb9PkPVF3nLdixxEPEBGvR2ky9ts4RJy P+ur8Jo2i8sbUTIYiCBzlDfvuyvyXYYkqzU/4qcqRE+ctjquCB1kMW7HAEE6P9QqmuDl YgtYoqW7ICeMqJ1f3xWzSNHkQAl/W7Y9c6BJxrHSo+aM9xbPurZFO2UfL+pgO/ZXVZc0 9M1R+aZXUesCG2/kMcyw7d9cIb/cuMwxUCIMob51B2BXywa0HZ1lols21TVaVhs07nTE Z+1GLBmpxsKETibFDjTFFa/1x1feaDm2D2x8JkKHqW4/9ICfQyFr0WsvZ3Fl2BcW+UNu WbVA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=z0LW9kb22fgJrXTM0o17zUXVt5Ltr/GYsGYQxqGV2AU=; b=MYTsZDusRM023SP40/zpqJwA0qUB4ggp04mf41bYAv9sMEisnXt6jfeDCXG4QqKgFQ b7VnwhiZtlBy3t40e1FLxTf0HtA117jwShrXf5DWUt4q08zZzD6OvRh27f3orAcDCh4A bUgfUst9Y770yCHwohYAOr4QHTvxoQcNf89PoflOm+I+vGKK7mQQLXhiMV49jCqkc/al xafRheCmxwdTEiJR50ZrhBnivyzrL4ct1ruvWyE6omymYGJy+7FbciQLR0wecwy44vzk rfeNilLpk1l6VMEU7Q2m+5LsKIpsIiJ1nko29zIiZY2KlLMPguJcRTegHxsSfz08rlpr Jqtg== X-Gm-Message-State: AIVw110Gs6Ff8X/Ecqs/pnIDrRjDGIEgM23sv7ADkdDZ0iNEFRauEKJL J3uhB5pw1EYPeNTH X-Received: by 10.98.70.86 with SMTP id t83mr56877410pfa.219.1499892900606; Wed, 12 Jul 2017 13:55:00 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id 70sm6911119pft.104.2017.07.12.13.54.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 13:54:59 -0700 (PDT) To: Michael Richardson , Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> <25643.1499875039@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com> Date: Thu, 13 Jul 2017 08:55:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <25643.1499875039@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 20:55:04 -0000 OK, I'm getting there. More in line: On 13/07/2017 03:57, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> Brian E Carpenter wrote: > Is the > >> following correct? > >> > >> > Topology (ASCII art): > >> > >> Topology is essentially correct. As you point out, RFC7217 is the > >> recommendation going forward, so having a a big IEEE OUI allocation > >> isn't necessary anymore. > >> > >> But, the problem is you have a single Ax for the device. The ACP > >> needs to allocate Ax1 for LAN1, and Ax2 for LAN2, etc. > > > Yes, that would disambiguate it. But in general it isn't necessary for > > a node to have multiple ACP addresses just because it has multiple > > interfaces, is it? > > We need a way to distinguish the different links (and scoope of the LL > address) in a way that can be communicated easily and cheaply to the > Registrar. I've asked for the "V"irtualization bit to be bigger, and I see > no purpose for the Zone-ID myself. > > >> That's why I wanted a /96 or so provided by the ACP to each device. > > > That would be one way, but it will create noise in 6man. In any case > > if the requirement is one address per proxy+interface I'm sure it can > > be done somehow; IPv6 addresses are cheap. > > It's not a subnet for the device to announce, it's a large bag of /128s. > > >> Instead, I have two suggestions, not entirely mutually exclusive: 1) > >> the Registrar says, "I accept IPIP on Address Ar, use Lr for > >> connections" > > > I don't understand where Lr would be used. The LL messages are all > > between the pledge and the proxy, which have perfectly fine LL > > addresses of their own. > > Assume a TCP connection from the Pledge to the Registrar. > It looks like, as you wrote: > > Pledge sends to proxy [Lp, Lx1, 17, TCP-PAYLOAD1] > > On the registrar, when it emerges from the IPIP tunnel, this is what the > registrar sees. If we do nothing, the Registrar says, "Lx1"? What's that > it's not me. Drop. So we have to do something. Options are: > > 1) Registrar accepts any Lx1 as local. > 2) We pick a well-known Lx value (a LL anycast). > 3) We have the Registrar tell the proxy an Lx value to use. > > > 1) Registrar accepts any Lx1 as local. > There is no precedent in v6 APIs to open such a socket, but this actually > supported on many platforms. It's used for nasty stuff like transparent > application layer proxies, forced HTTP proxying, and the like. I think there's a more subtle way to look at it. When the registrar receives a protocol 41 packet from a new ACP address, it conceptually synthesises a new virtual interface and assigns Lx1 as its link local address. On that interface, things would look normal. Thus RFC2473: >> The tunnel link-layer input and output can be implemented similar >> to the input and output of other link-layer protocols, for >> instance, associating an interface or pseudo-interface with the >> IPv6 tunnel. I really think this is a clean approach. In any case, what happens to a protocol 41 packet is always a bit strange and is not covered by the traditional socket model. > 2) We pick a well-known Lx value (a LL anycast). > The pledge has to do something slightly funky where it forces a particular > L2 address for the anycast LL, because if there are multiple proxies on > the network, straight ND will get one at random, and the Pledge actually > wants to be specific about which one it uses. (since it wants to try them all) How can it work as anycast if is more than one proxy on the LAN? I'm not at all clear that anycast under fe80::/10 makes much sense. > 3) We have the Registrar tell the proxy an Lx value to use. > I chose to put this option into the protocol, because we can always > set Lx= Lanycast in the future, and perhaps we can set it to :: > if we want case (1). I like this least of all. What happens if there are multiple registrars? And when a proxy node comes up as a pledge, it must give itself a LL address on each interface before it even tries to perform its own BRSKI, and before it looks for its own proxy and joins the ACP. Is it supposed to change its own LL address after it discovers the registrar? Or is it supposed to have two simultaneous LL addresses? Is that even possible? > >> > registrar, it simply forwards the packets as-is in both directions, > >> > encapsulating and decapsulating accordingly. The pledge knows > >> nothing > about IPIP. > >> > >> It needs to know it's IPIP, > > > Why? The IPIP encapsulation and decapsulation can happen inside the > > proxy (and the registrar). Why does the pledge care? > > Sorry. "Proxy" vs "Pledge" > "IT" above referred to Proxy, but in fact it says "pledge". Typo. OK! > > >> As for Toerless' notion that we should invent a new UDP-based > >> encapsulation > > > IPv6-over-UDP isn't exactly a new invention. It's been used in Teredo, > > TSP (RFC5572) and SixXs > > (https://tools.ietf.org/html/draft-massar-v6ops-ayiya-02). More to the > > point, draft-ietf-intarea-gue is in progress. > > > All the same, if straight IPIP works, so much the better. > > I resorted to using Ar as an additional signaling mechanism to "store" the > ifindex where the request was coming from rather than try to find some bits > in some other protocol like one you mention above. > TSP is too complex for our needs. > > Teredo has some space for additional stuff. It should be straight forward to > define it over IPv6 rather than v4. Seems a bit weird to me though. Yes. My point was only that this isn't uncharted territory. Brian From nobody Wed Jul 12 21:18:58 2017 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 D29C212714F for ; Wed, 12 Jul 2017 21:18:56 -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 KEz2TJCJCD_x for ; Wed, 12 Jul 2017 21:18:54 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E6E126B6D for ; Wed, 12 Jul 2017 21:18:54 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id j186so23073549pge.2 for ; Wed, 12 Jul 2017 21:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LVHzwzW9m4HUWxbViM6bDOLo6MJ4ZNzGgHbAGjdn5RA=; b=gDJe8oO0pjOoEGKtQt7QV3bzaqCaT5tV3gennSf7+lc2+PDdOMOsM81WoM30PcXKcE JvuQwHcxV/RpRYFgVZtDzpXYVt6d+ASTjpqGewNozKQemKEKcNWmwtg68mh03ixExTYe xxlydR7ji1QzmfzmAfetEYAXp+l/4J4CD0W5GueRu+l4WimJ8w3tMbDI2Qk4TtLgpwlb aQfs5AS1Too4LeEegRUkjiTaWawmsZcZxLZgRf2t+iIRwd3E5UbVPtDQbsCsmNBhwv4r kGlXr+OsTPlbUeRiQEp+TGFegKaTkAG8rbZHrWfpz2FDtJFCFuwzcUeHhGqXa7Jlt0mq HCFg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LVHzwzW9m4HUWxbViM6bDOLo6MJ4ZNzGgHbAGjdn5RA=; b=oG5g+RRyHljO7EWkRpGXe59sVN9ZSTKhn6nfHLfcGQu6whCSu8+d66Ba5UzGrLhzlL UCFYgcvIv4cq/x2fRScguVeILQw12NxwKVMyZt7XGoKjMidg5W7sBFdMhPDdJkAWO2Mg DXjbUrr+XzNazojqgExJ60Oxcju3iUplx6LnTgAFRKecHUMgww/G6giz4lu/pWxXhcv/ g2WPSj80inp31+Xn0zvOCb99dFpmV6L+e3veq3daAP2ZAvYUeWRdY4sJREhUh7dEDFtW tH4YVq5D1nh+Y2274o14+/s5pZy02zQOp2zvHcF5Jc1ncKNBwSeW57nlL0KHlEyOJMH4 uBbQ== X-Gm-Message-State: AIVw111J1Rmh3CsZ4cuCL8XgCbpLL1eUvb0kr+eOeOPkSHKpWd2xrKWr NOnKkxteieJpn6Wx X-Received: by 10.98.89.13 with SMTP id n13mr59877174pfb.184.1499919534140; Wed, 12 Jul 2017 21:18:54 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id n19sm8333943pfa.64.2017.07.12.21.18.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 21:18:53 -0700 (PDT) To: Anima WG References: <149909541115.22803.10008787894534867046@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 13 Jul 2017 16:18:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149909541115.22803.10008787894534867046@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-rfmesh-anima-iot-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 04:18:57 -0000 Hi, A quick comment since I will not be in Prague. This draft opens an important topic. At least we should explore it in more depth. One comment is that specifying how GRASP unicast messages would work over UDP is not quite simple - that's why it isn't covered in the main GRASP spec. Ensuring that the chosen solution really does save radio resource compared to TCP handshakes is perhaps tricky, since there are complicated implementation issues, not just a protocol design. There are probably a few things we can do to make GRASP messages shorter, although CBOR already does a pretty good job. However, I just ran a test, and gzip can compress the example messages in draft-ietf-anima-grasp to about 60% of the raw CBOR size. Regards Brian On 04/07/2017 03:23, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : ANI Applied in IoT Network Management > Authors : Bing Liu > Yuefeng Wu > Filename : draft-rfmesh-anima-iot-management-00.txt > Pages : 10 > Date : 2017-07-03 > > Abstract: > This document describes an IoT scenario where ACP and GRASP is > suitable to act as a network management channel and a lightweight and > extensible network management protocol. Relevent GRASP extention and > options are also specified to fulfill the requirements of the > scenario. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-rfmesh-anima-iot-management/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-rfmesh-anima-iot-management-00 > https://datatracker.ietf.org/doc/html/draft-rfmesh-anima-iot-management-00 > > > 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 Wed Jul 12 21:24:13 2017 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 CDB4212EB4A for ; Wed, 12 Jul 2017 21:24:11 -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 x3v84VhlAdyU for ; Wed, 12 Jul 2017 21:24:09 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 5C39912714F for ; Wed, 12 Jul 2017 21:24:09 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id t186so23250360pgb.1 for ; Wed, 12 Jul 2017 21:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tf0nN7cx9MJwklrVjjJjgWNTsRg1cq/MzhE1CVmtXAE=; b=Q7+GB4ezo29IwPiplrsZoMKEVwEGXBeZWipVYzi3Tlk4KW18+l+L5UW4kLSPSCXJ3q VqLguQkckyBkIGfJqT8PfGjwnf8o3ZCg8LeRaH1bTLRwljdKXtGXnfdYMfNxI5+Uli52 NClvIMPzswAlhib7zBl0Yh1nP7/xhz38y3CigSz79MDcArjr6/Euzq+iOs3PgqrM3R8G sJGuH0FZVbjmvnGwl+K7SlkdGPlrhd33fAdCk2I8RGZFN0sy9Bu8/TOpw9sj3+roj9JG MBtQ8zPOKsUPQ8CG7vDmd5Pwb6bj/yUjwK1ATixi0TwE3IkIoc3DsujBswUDXKgXVyKr mfIA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=tf0nN7cx9MJwklrVjjJjgWNTsRg1cq/MzhE1CVmtXAE=; b=Zsi3m9mYj6jB0oYGVSwvV/LYw0o/TIo12dhW28+cyC3wfqd/ZQ4CkQ6NG+mRrZvvuy VFa2htYbSEoiv5MQXCZpREStgVpP7rMZ4FE31Rv4Jpkx0yDhamsrrZ2BfpxB/e/81MS6 kpB6PgCUGt9z4eIX+A3HOdzjhDXrP2JU9OPXX0cndtU1CKANAiCNfswGI4GDjO4rYriB bISCD9px329Ae7aKSovh4bNYk9aJqwybw0WlwiDVqz8BjFKUl3IqnjfyM5TKxRlKtdvQ DlzoYbW20fmBWwDczB5bDRuhhLgweWq714u/hub6avy4bv3CBPkzbnIiv7GLDoPVEIuA k+7g== X-Gm-Message-State: AIVw111QehpYjjVgXU3zeL4yjQ7SvxLbsxlLkrtoc/dQkZ1kWyo0bSOa wjxOrJyAhunMHz12 X-Received: by 10.99.18.65 with SMTP id 1mr7178464pgs.132.1499919848777; Wed, 12 Jul 2017 21:24:08 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id s15sm6983845pgo.48.2017.07.12.21.24.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 21:24:08 -0700 (PDT) To: Anima WG References: <149909548258.22816.8100863022218009240@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <84e073b1-74c5-7024-ea15-d61f1eca2fd1@gmail.com> Date: Thu, 13 Jul 2017 16:24:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149909548258.22816.8100863022218009240@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-nmdt-anima-management-bootstrap-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 04:24:12 -0000 Hi, A few comments on this too. Again, it is a good topic to explore. 1. What's the relationship to draft-ietf-anima-stable-connectivity? 2. I am a bit confused by section 5.1. There is no such GRASP message as M_NEG_SYN. Are you proposing a negotiation objective or a synchronization objective? My suggestion for draft-ietf-anima-stable-connectivity is a negotiation objective, since it allows one to pass data in both directions. Regards Brian Carpenter On 04/07/2017 03:24, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Anima Bootstrapping for Network Management > Authors : Fanghong Duan > Bing Liu > Yongkang Zhang > Filename : draft-nmdt-anima-management-bootstrap-00.txt > Pages : 11 > Date : 2017-07-03 > > Abstract: > This document points out the gaps of utilizing current Anima > technologies into a traditional centralized management network. It > raises some problems and requirments, based on which, as set of > solutions are proposed. (These solutions are called Anima > Bootstrapping for Network Management.) > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nmdt-anima-management-bootstrap/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-nmdt-anima-management-bootstrap-00 > https://datatracker.ietf.org/doc/html/draft-nmdt-anima-management-bootstrap-00 > > > 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 Thu Jul 13 01:08:25 2017 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 C6F6E12F3CB for ; Thu, 13 Jul 2017 01:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v1WbGTe8_pdY for ; Thu, 13 Jul 2017 01:08:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D87126C83 for ; Thu, 13 Jul 2017 01:08:21 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [89.248.140.19]) by relay.sandelman.ca (Postfix) with ESMTPS id 761F71F906 for ; Thu, 13 Jul 2017 08:08:19 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 08A74694; Thu, 13 Jul 2017 04:08:18 -0400 (EDT) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 13 Jul 2017 10:08:18 +0200 Message-ID: <9183.1499933298@dooku.sandelman.ca> Archived-At: Subject: [Anima] pinned-domain-certificate and other BRSKI comments X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 08:08:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Max, some comments as I catch up with your changes. (maybe I should raise these in github, but I'm writing on airplanes, etc) In brski-07 section 3.2 we give the example as: An example JSON payload of a voucher request from a Pledge: { "ietf-voucher:voucher": { "nonce": "62a2e7693d82fcda2624de58fb6722e5", "created-on": "2017-01-01T00:00:00.000Z", "assertion": "proximity" "pinned-domain-cert": "" } } 1) Would you object if I filled in an actual encoded certificate value? (I'd like to also put the throw-away private key in an appendix so that any examples we have can be repeated by others and also validated.) 2) as ietf-voucher.yang leaves the encoding to BRSKI, can we write, instead of base64 encoded certificate, can we write instead: RFC-urlsafe base64 encoded DER. that makes it clear that it is not PEM with "-----BEGIN"... etc. I also suggest we write base64url just because I think it's more ubiquitous and many people aren't even aware that they are using producing it. (see: https://tools.ietf.org/html/rfc4648#section-5 ) (I'm all for implementations accepting both base64url, and base64 kind, but we have say something about which one one should produce) 3) In the case that the voucher request is unsigned, the serial number for the pledge, and the pointer to the MASA will have to come from the IDevID certificate used in the TLS client connection. I think that we should have authoritative language that says that it always comes from the TLS ClientCertificate, and never from a signed voucher request. Otherwise, implementers might do different things and when the results are different, it will be hard to figure out what went on. While I think that the cert info is optional in the PKCS7 signed wrappin= g, I think that we should say SHOULD NOT add it. 4) >application/voucherrequest The request is a "YANG-defined JSON< Is it reasonable that this is "format=3Dpkcs7" (the default), and that we will grow/migrate via format=3Djwt or format=3Dcwt? 5) I think we still haven't gotten prior-signed-voucher described right. While it makes sense to provide the pledge's voucher request, I thought that if the Registrar already had a voucher (probably expired) then it ought to provide that in prior-signed-voucher. After all, that's what the field *IS* called. 6) section 3.3: If a nonce is not provided the MASA server MUST authenticate the Registr= ar as described in EST section 3.3.2. =20=20=20 I take it that we reference 3.3.2 specifically because do not want to do HTTP-based authentication. I would guess the sales channel integrati= on basically means to have the MASA pin the Registrar's cert in some fashio= n. I think that we should be leaving the door open here to other ways of getting authorization, such as OAUTH2 based things. I don't know if we actually need to say anything here. 7) id-kp-cmcRA. I found it rather hard to get this bit set. This is a software (openssl) plumbing problem, and not a reason to throw this requirement under the bus. However in the case of an nonceful audit log policy, it seems that many non-enterprise Registrars will be operated using self-signed single certificates. I'd like to make this as easy as possible. 8) Response media type: application/voucher+cms. I think I'drather register application/voucher; format=3Dcms. Let me stop here and start a new email about this. =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----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZypxAAoJEJVM4Vb9/EKQrQoH/Ar++0S0bVEc+fSryul3kEzH JaO5S4rt0SOWJBVtMMLgcY7VCT4T0yf4Cs8CWiwR4dWvYIfuyEZXRfoBLWRAW539 SYFpvVRI13DzQEptvF68INnl1h1ECo0C6A+/H6XWPxj22J/kr7ffUmB7IWi4F7sQ /EfCi/sFvg7gxl0fFlmRh3SXPn4iYypYx8ta9Esw72/Yub1ZVBtv2A3ardf51TMe 8P1u0FpcEIrd6nJpe23VXWOOl4Eb2w2vWh1JtmNkdQNtTYsHvcU/k1rlUZTW0LBN e5VNld8JBmviEfOoeYL1WEKcCAQhA2NiZ4XEbIp77KD+kofa99YOZN7KpQSjg+0= =2zHz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 13 06:01:49 2017 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 87464131A74; Thu, 13 Jul 2017 06:01:47 -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.55.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149995090748.17825.8953421521702685580@ietfa.amsl.com> Date: Thu, 13 Jul 2017 06:01:47 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-15.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 13:01:47 -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 of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-15.txt Pages : 81 Date : 2017-07-13 Abstract: This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-15 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 13 06:53:19 2017 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 22ACE131A7A for ; Thu, 13 Jul 2017 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkhDXAyw7JdE for ; Thu, 13 Jul 2017 06:53:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D760131A86 for ; Thu, 13 Jul 2017 06:53:12 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 6E12C1F906; Thu, 13 Jul 2017 13:53:10 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 805F31626; Thu, 13 Jul 2017 05:40:11 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-reply-to: <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> <25643.1499875039@dooku.sandelman.ca> <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 13 Jul 2017 08:55:02 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 13 Jul 2017 11:40:11 +0200 Message-ID: <17795.1499938811@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 13:53:15 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > OK, I'm getting there. More in line: >> 1) Registrar accepts any Lx1 as local. There is no precedent in v6 >> APIs to open such a socket, but this actually supported on many >> platforms. It's used for nasty stuff like transparent application >> layer proxies, forced HTTP proxying, and the like. > I think there's a more subtle way to look at it. When the registrar > receives a protocol 41 packet from a new ACP address, it conceptually > synthesises a new virtual interface and assigns Lx1 as its link local > address. On that interface, things would look normal. Thus RFC2473: I can buy this. It argues that the Proxy should send a gratuitous packet to the Registrar to prime that virtual interface. An ICMP echo request perhaps. How can we document this well? >> 3) We have the Registrar tell the proxy an Lx value to use. I chose >> to put this option into the protocol, because we can always set Lx=3D >> Lanycast in the future, and perhaps we can set it to :: if we want >> case (1). > I like this least of all. What happens if there are multiple > registrars? And when a proxy node comes up as a pledge, it must give > itself a LL address on each interface before it even tries to perform > its own BRSKI, and before it looks for its own proxy and joins the Yeah, you are right, this doesn't work if there are multiple registrars. =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----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZz/7AAoJEJVM4Vb9/EKQ00UIAIhy+JjPvoy7aslh1YdHjNaU RYgAaJOpKLS5nvoe7iWvLu8/p8Jn9Kwva3igq8QSJURxViBjUpWNdUEjPYToYMwx K06Ag0YUwZwLKoQ91Sb1CmJqBZtoVvRcTREoLk0vyQPak/rMSb3NzX9Ug20u3X2H YR1YMbRA2Z7FCbOQg9zg+344WdP2tL10YpuYqORg6uzjpZxKCm3rBPmui8Cf1Gwe aBHF8Qck3IbRBbzlHyl2+pjTAVb/z1p+hOPy90JHYO+1nVJscBG3IbpFbreI6/hM mEZQlx5bxsJsq0UbWUmGtWKuK4ls2Qymj1zdbGrjnR7YLy7bN4XdB/jSSgTk0Sk= =9oN2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 13 06:53:27 2017 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 2B624131A70 for ; Thu, 13 Jul 2017 06:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fq6c2SbvzEL for ; Thu, 13 Jul 2017 06:53:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B84131A88 for ; Thu, 13 Jul 2017 06:53:12 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 6F68C1F91C for ; Thu, 13 Jul 2017 13:53:10 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8D028694; Thu, 13 Jul 2017 05:21:38 -0400 (EDT) From: Michael Richardson to: anima In-reply-to: <9183.1499933298@dooku.sandelman.ca> References: <9183.1499933298@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Thu, 13 Jul 2017 10:08:18 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 13 Jul 2017 11:21:38 +0200 Message-ID: <16456.1499937698@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] pinned-domain-certificate and other BRSKI comments X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 13:53:16 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > The 'pinned-domain-cert' element of the voucher contains the domain > CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust > anchor to immediately complete authentication of the provisional TLS > connection. At some point we have the option of having just the public key that we wanted to pin, without any need for a certificate. This was in voucher-0= 3, as: "domain-certificate-identifier": { "subject": "base64-encoded Subject DER" }, because, I think that the "Subject DER" was a SubjectPublicKeyInfo object. We have lost this along the way. I really wanted this. The usage scenario is a constrained pledge. It sends it's IDevID as an opaque blob for it's TLS ClientCertificate, and the Registrar uses a raw public key to authenticate. Once the Pledge gets the voucher, it finds the same public k= ey in the voucher, and it's good. SubjectPublicKeyInfo is pretty the smallest structure that can contain a public key. You may ask, but, what's the point of doing EST at all if you can't speak enough certificate to actually do an enrollment? Well, there are three things that appeal: 1) if no ACP, an LDevID may not be a goal, the secured EST channel might be used for other things. (Such as RESTCONF like session reversal) It could be used as an ACE RS/AS connection, and there might be symmetric key bound assertions returned and/or evaluated. =20=20=20=20=20 2) it could be that IDevID and the MASA/Registrar identies are in RSA, (DSA?), or uses bigger/safer ECDSA or EdDSA keys that the Pledge doesn= 't understand, but enrollment will use some simpler subset. =20=20=20=20=20 3) the "LDevID" might not be in a PKIX format at all. CWT can do it all. Am I off the ANIMA scope? Yes. Can we deal with putting enough ASN1 parsing to pull a public key out of a self-signed certificate? Probably... but it will have a cost. Can we add another field that contains just the public key? Yes. I'm not sure we can remove the pinned-domain-certificate though, so we'll be burning those bytes across the link. =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----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZzuiAAoJEJVM4Vb9/EKQsLAH/iM6Q4b5D1tjBgGlqLUmAOzU TMXlX6uEIM0dVm9mIqgDLfIfM7TuHSDuwyI18fpyObe7ZJO7yEWy4pyljpXSceAv p8MN13lpMxuNKQtBkGf6Snt/kEBHgWN6yA8GcDqZKO0nYdQ0+sWbxC4AfCLeZRNs 3Z4oD0TanX8iGOmomEJ3zUb2HPjmfhleMKGclib/7kV5xwWa5E8n/cGj166VJXEQ IzMZGxJJ6nREqKdmnebjIBQ3HVEdwGYGntk9PtGri3gL7NqCj0TIoKOV8FPFzWlb Y74HXMNvfYJ3b9KG5MMJQbrDtVhiqdip5ew7mf8niaTijjslpCdVxbxDVYOvIIU= =Ydx0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 13 10:15:30 2017 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 0BC6E131938 for ; Thu, 13 Jul 2017 10:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KB-jeqyOcD5N for ; Thu, 13 Jul 2017 10:15:27 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96287129AFF for ; Thu, 13 Jul 2017 10:15:27 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id AAD0D1F906 for ; Thu, 13 Jul 2017 17:15:25 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id AE2F1694; Thu, 13 Jul 2017 13:15:24 -0400 (EDT) From: Michael Richardson to: anima In-reply-to: <16456.1499937698@dooku.sandelman.ca> References: <9183.1499933298@dooku.sandelman.ca> <16456.1499937698@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Thu, 13 Jul 2017 11:21:38 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 13 Jul 2017 19:15:24 +0200 Message-ID: <3103.1499966124@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] pinned-domain-certificate and other BRSKI comments X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 17:15:29 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > The Registrar MUST use a certificate that chains to the pinned- > domain-cert as its TLS server certificate. I wonder if it should say: + The Registrar MUST use a certificate that chains from the pinned- + domain-cert as its TLS server certificate. Or maybe we want "descends"? Perhaps "server certificate" should be ServerCertificate, which is the name of the actual payload. next paragraph: > The Pledge's PKIX path validation of a Registrar certificate's > validity period information is as described in Section 2.4. > Once the > PKIX path validation is successful the TLS connection is no longer > provisional. Is there some way we can call the the last sentence out louder? UPPERCASE it all? I dunno. I think people might really need to be hit over the head here. section 3.5, I changed: =2D To indicate Pledge status regarding the Voucher the client + To indicate Pledge status regarding the Voucher, the pledge I think this is clear. I'm not certain about the comma :-) section 3.6: > The registrar MUST HTTP POSTs the same Voucher Request as when > requesting a Voucher. It is posted to the /requestauditlog URI > instead. The "idevid-issuer" and "serial-number" informs the MASA It seems to me that a Registrar should also be able to post any voucher. Even an expired one. So not just a voucher request. (The distinction being who signed it). While generally a Registrar is going to consult the audit log before asking for a voucher, it could well do so afterwards. I think this has value in the Pledge is offline case: a Registrar on the Internet side of the air-gap firewall (with the USB drive...) could take responsability to consult the audit log periodically. [StatsCanada's airgap firewall used UUCP via 9-track tapes to move email cross their airgap firewall] I think section 3.7 should be 3.6.1, as it's the reply to 3.6. (I'm gonna do that in the XML) Section 3.7 needs to say what to do if version!=3D1. Could we remove the version from the response and change the URL to /requestauditlog/v1 ? (I read to the end of the diffs, and found nothing else that stirred me) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZ6qsAAoJEJVM4Vb9/EKQbvgH/06znQK5kLd8OphpAT4dBGsP bfN27L0p/RHcnlvj3S68XScFCj9Lb+gbyMk8inM1H67+1gTi5thftrfSqKFzW2XJ 0jmedLZoIhCF44C30wWwvMBVweqbSvnGkiLEsYFxdEDdxDKcp2h8lbQZ8XlO70Ki pD4K2Cf2V647fxYlNqv2nMBO4R0g3VpGK5koMKF09gJ/vkIl23o/qdU19bTeep8i S/eG1k1YENJbAw1VCDWtmkiPASpSgUAB6kqAESnJX7qpKADCThVVYc6/OZMombqC YB2ZySP8Nx5vdbrRrYmDDtTVKsxfjehAk4Wzkewr6zwQOoQnQXPvjVeeC8QvbX8= =Vx+m -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 13 11:41:19 2017 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 C8A05131942 for ; Thu, 13 Jul 2017 11:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8PV63IjekZ1K for ; Thu, 13 Jul 2017 11:41:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B3A131935 for ; Thu, 13 Jul 2017 11:41:16 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id DB2F21F906 for ; Thu, 13 Jul 2017 18:41:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 40E6C694; Thu, 13 Jul 2017 14:41:13 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-reply-to: <149995090748.17825.8953421521702685580@ietfa.amsl.com> References: <149995090748.17825.8953421521702685580@ietfa.amsl.com> Comments: In-reply-to internet-drafts@ietf.org message dated "Thu, 13 Jul 2017 06:01:47 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 13 Jul 2017 20:41:13 +0200 Message-ID: <10244.1499971273@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-15.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 18:41:18 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable internet-drafts@ietf.org wrote: > Title : A Generic Autonomic Signaling Protocol (GRASP) Authors > : Carsten Bormann Brian Carpenter Bing Liu Filename : > draft-ietf-anima-grasp-15.txt Pages : 81 Date : 2017-07-13 =20=20=20=20 I've read the diffs from 13->14, and now from 14->15, and they all look good to me. (In case anyone cares about WG consensus...) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZZ77JAAoJEJVM4Vb9/EKQaIoH/i6dQ2gxhBVDYSara6rVeUqb jztad932eQ48+UrJJT6AiU67/9nt0kOJbV+Su+oojZx2K5joxFayJSsvwE+BBCQt ftQwUxQG2aEFzP7bQV3j76FbbFEqhf/qvezDV7ZBIuS0ek/rcWXY57S2D1rRthH7 OZSJ1dL0Y0f2WPcA39ij8bD9Nr3CbthI0a4Ziq9LvrIDRN8LMlF1nBFDQVjNWli7 ae4J7XqbOPJtYRkmiNetX3cOj4Igjsy2zYE7pss2QRzarct2/N9eR4eyaUY5aI4y M6PrP/kEjqZFzEOtizFgy+oeIL5PuhOxFbKD04teK5409FJTE4XMdQu+uEij0NI= =fNcC -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 13 13:01:48 2017 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 9DEF1131781 for ; Thu, 13 Jul 2017 13:01:47 -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 K0IE2Fcw8AZV for ; Thu, 13 Jul 2017 13:01:46 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 3C954131779 for ; Thu, 13 Jul 2017 13:01:46 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id k14so34726253pgr.0 for ; Thu, 13 Jul 2017 13:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uMj9ww96J8oNJg/xW8C9xXRUnl09bgi+b8YY+RRSIXg=; b=oweYIcbQ/j1twywEfXQ+rZ5htviFR8+bmQoOewBz+GmtMRk7o8f95Glj1Z6BI08u2i WEoOPcpaa6qwNJRsT1ZH6tsMk4lg9oa6uWR1Kc5VmhJaeDA07VUdTUlLohDMy997GrIA CdqqFmqk+nTAPsPatnfAIS0+RH5yDLQGMpJMp/zHAWnt/4/9R8t40WetOrbZf2m/J6lx ncCifz8x0JrumoZmsDpupKXNF72rKwj7dXPrK196eIuGBv9k648uPJfKMmlS8TVQoTzb NqyEM+mOB0ENGvwc1AiU8+syRN7fQhMKZPG9zYstqgZnuIPFT49XzLEbvJhuvfeynGPN qZyQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uMj9ww96J8oNJg/xW8C9xXRUnl09bgi+b8YY+RRSIXg=; b=WHU26S7CepWzycA4m/hvJ5fnHElH4bpwJinpYojPmQn0tCOPIoa0Y5JeCR4rfkWWqC WxWBhaLx44UHbtwLFFoyjIo2HePQW7yhw15BaElZAu53KPseDg0QoFDv8A71HX0MWGw7 dw9+asvFre6Ql7dx9l2ImEKdOsE/3CX/NT2WBVxSFHkIo9N9rSLme6Sy1lrlT9UeD1BG 8gHtkuZ1eq9KDw+G63Rt7X8o3t2bScYmh4FclWSzRjmNbinVXgxvahaXAXY/jwMhnHSp Elp+awLJU+4DasnhtoIK05WFcC6D7r8T49XY0EbqEVx2edtB0XeSWvdyS0dce2I/2xxV BKnQ== X-Gm-Message-State: AIVw110IYn+VcZqnq9X4eIilABMp+9lm7UjhVx9XsCu18DyiufdzMrm5 K4PnZjUKsuhy7gQ8 X-Received: by 10.99.54.205 with SMTP id d196mr10957553pga.79.1499976105383; Thu, 13 Jul 2017 13:01:45 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id x85sm13882925pff.92.2017.07.13.13.01.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 13:01:44 -0700 (PDT) To: Michael Richardson , anima@ietf.org References: <149995090748.17825.8953421521702685580@ietfa.amsl.com> <10244.1499971273@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9c2cd52c-12c6-f3cd-b165-5b1aaedda060@gmail.com> Date: Fri, 14 Jul 2017 08:01:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <10244.1499971273@dooku.sandelman.ca> 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-grasp-15.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 20:01:48 -0000 Thanks Michael. It's always a bit tricky to navigate between too much and too little re-discussion while resolving IESG DISCUSS comments. Onwards to more running code, which is the real test. Regards Brian On 14/07/2017 06:41, Michael Richardson wrote: > > internet-drafts@ietf.org wrote: > > Title : A Generic Autonomic Signaling Protocol (GRASP) Authors > > : Carsten Bormann Brian Carpenter Bing Liu Filename : > > draft-ietf-anima-grasp-15.txt Pages : 81 Date : 2017-07-13 > > I've read the diffs from 13->14, and now from 14->15, and they all look good > to me. (In case anyone cares about WG consensus...) > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Jul 13 13:36:41 2017 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 8DE3B131566 for ; Thu, 13 Jul 2017 13:36:39 -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 jLqhHvV9LAYI for ; Thu, 13 Jul 2017 13:36:38 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 091D612EC44 for ; Thu, 13 Jul 2017 13:36:38 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c73so34782819pfk.2 for ; Thu, 13 Jul 2017 13:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=662mzEaWnczg6YOF8MP6/8WxS4uSpjDRfkiNxr3BzmI=; b=FPmv9t/5zoqldKVpTFYLHqBt98sueku1JbH7NKbfAWKRt0/laOeIYcsCU35vvWq3Jg bhn5Wi58g1mY6DSB+f8EnA2JrkC9c+mkM4DTNuouKdIP0gJ7WFfR7WykT2C6O4OhAiLG fZZDZyOQ5NX5yCvyuCB3rzppoilpOTeqcgC582X6p3XDmxdG2LHmwosDm8KK7IbLh50j 2vHEMzMszsgoko5qLYx4sWnwhGgw8/lKcHQyUEivNKoB+YYd/EPejwqEU8EhcgfY2uXm mytHKhfyGznM7sgtE0SmOfXhT4P+U6rJZYbTFKyzQZNrKgpqL/dPHLsrt0Yo1jk5NuOy efLQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=662mzEaWnczg6YOF8MP6/8WxS4uSpjDRfkiNxr3BzmI=; b=F6O9/CIuTjd6hxG2BvI+ORfq1+fP90ENkqvAZG72IUhTMD+63MLUM4nM2g1IF3fh85 Kw6hP0z7lI14ac2CqCSRov9TUZZ9ZZSr3PEJNryNbxCiOTWVXOcmApi8mcDWot0A8dAe feLEjQPVzD5APUnMzfT+/Gs+y2gGUmfLLeSZfAD1UibsfL0FpRQT3WUVI3Kx+ovn4CXV vbnuUCyfxBdDYPPTDzTHg17Fpg4SFCQgq+D93CBEDSfQ33nkBDuCWwlR0UzVBDxPvsle AZ1i4+mlUcjXtjiY5KRA1vnlkomHbHBzfCDj8NyplQ27tz02RlRzA45DIyQzloPvE/qS yeqQ== X-Gm-Message-State: AIVw112/622hbSxWEHCquxYt15YkpsP4EY8QA5DNzmyeE/IJTmTPkbC+ MNbmzvqKJwwON6Pq X-Received: by 10.84.225.18 with SMTP id t18mr12071850plj.273.1499978197397; Thu, 13 Jul 2017 13:36:37 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id x65sm15220509pfa.107.2017.07.13.13.36.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 13:36:36 -0700 (PDT) To: Michael Richardson Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> <25643.1499875039@dooku.sandelman.ca> <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com> <17795.1499938811@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 14 Jul 2017 08:36:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <17795.1499938811@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 20:36:39 -0000 On 13/07/2017 21:40, Michael Richardson wrote: > > Brian E Carpenter wrote: > > OK, I'm getting there. More in line: > > >> 1) Registrar accepts any Lx1 as local. There is no precedent in v6 > >> APIs to open such a socket, but this actually supported on many > >> platforms. It's used for nasty stuff like transparent application > >> layer proxies, forced HTTP proxying, and the like. > > > I think there's a more subtle way to look at it. When the registrar > > receives a protocol 41 packet from a new ACP address, it conceptually > > synthesises a new virtual interface and assigns Lx1 as its link local > > address. On that interface, things would look normal. Thus RFC2473: > > I can buy this. > It argues that the Proxy should send a gratuitous packet to the Registrar to > prime that virtual interface. An ICMP echo request perhaps. Or a GRASP M_NOOP, designed for such purposes! > How can we document this well? I think it has to be spelled out almost at the pseudocode level. We had to spell out the encap/decap behaviour for 6to4 in some detail, and that was just about the only bit of 6to4 that never created trouble ;-). There are various encap/decap specs of that kind, and the NAT64 stuff also goes into horrible detail... Brian > > >> 3) We have the Registrar tell the proxy an Lx value to use. I chose > >> to put this option into the protocol, because we can always set Lx= > >> Lanycast in the future, and perhaps we can set it to :: if we want > >> case (1). > > > I like this least of all. What happens if there are multiple > > registrars? And when a proxy node comes up as a pledge, it must give > > itself a LL address on each interface before it even tries to perform > > its own BRSKI, and before it looks for its own proxy and joins the > > Yeah, you are right, this doesn't work if there are multiple registrars. > From nobody Thu Jul 13 13:58:51 2017 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 4311C12EC14 for ; Thu, 13 Jul 2017 13:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5JA9SYRx818 for ; Thu, 13 Jul 2017 13:58:49 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D261267BB for ; Thu, 13 Jul 2017 13:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2770; q=dns/txt; s=iport; t=1499979528; x=1501189128; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9XcJQvD2/+//QZgalfha1ht4eS6+RUseKZ9OMq5O2g8=; b=GI0cQEfoIpZspk0TfMk5H8imI7qnu8XAbYAgO5RG2uj64b9kRrnD7WXa Q2P7HO8j/ko/JZ/mf8wSlhU6GOJ2GOGatj6RITqBHagL+7wzJnaTEx+fV OAaikoQNafohCnDKeCGnZKbCOs9w8SvQTxp/dhxYkJhg/ROeN+IVBPkYo o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAAC43WdZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBk1tzkQOWA4IRB4I0gzsChCgYAQIBAQEBAQEBayiFGQEFI1YQCw4?= =?us-ascii?q?KKgICVwYBDAgBAYorrWh+giaLJAEBAQEBAQEBAQEBAQEBAQEBAREPgyiFLiuCe?= =?us-ascii?q?Yd9gmEBBJ8whCyCHY1LiymHAJVVHziBCjEhCBsVh2E+iUMBAQE?= X-IronPort-AV: E=Sophos;i="5.40,355,1496102400"; d="asc'?scan'208";a="653226186" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2017 20:58:46 +0000 Received: from [10.61.242.235] ([10.61.242.235]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6DKwkBk021032; Thu, 13 Jul 2017 20:58:46 GMT To: Toerless Eckert , Brian E Carpenter Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: Date: Thu, 13 Jul 2017 22:58:45 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vMRSWKslnwsTnf91DJTsIRwhb1dQRDmIn" Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 20:58:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vMRSWKslnwsTnf91DJTsIRwhb1dQRDmIn Content-Type: multipart/mixed; boundary="XO9eAxcgJx0JjKpxUEUgsNqVW3o45c4uR"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert , Brian E Carpenter Cc: Anima WG Message-ID: Subject: Re: [Anima] Is this how BRSKI/IPIP works? References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> --XO9eAxcgJx0JjKpxUEUgsNqVW3o45c4uR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Toerless, On 7/6/17 9:09 AM, Toerless Eckert wrote: > On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: >> It used to be, but the recommendation today is a pseudo-random >> value (RFC7217). In any case it's a software choice. > brand new recommendations do not equate to be expected > standard practice in products. Would be very good to have > folks with practical insight into various products to=20 > provide more information. On this point, I think it's quite likely that we will see a good number of devices fielded that will do a lousy job of PRNG, and so it would be inadvisable for them to implement RFC7217, lest they test their DAD code in ways not really intended. I'm not thinking about iPhones here, but energy harvesting devices like some light switches, and a bunch of, well,... crap. The question is whether you should design for these devices. IMHO "no" is a perfectly valid answer, but I'm still a bit skeptical about the value of 7217 for these class of devices in any event. Eliot --XO9eAxcgJx0JjKpxUEUgsNqVW3o45c4uR-- --vMRSWKslnwsTnf91DJTsIRwhb1dQRDmIn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZZ98GAAoJEIe2a0bZ0noz0mAIAKUil+JEFjWq6yf1hjIbpNrE 003q0lV+QU6kO4kn0heXmCynll2RLnjgJjJXYbkmgqit4KT8fTPGAsBKB6gf4pNM fVQJIfr/CsHoWotf+QwQ8XN3fm+5QVCs35iy7bmnYP0BYaFMdnfF+Onk1Ma6Ft5B nLnDucWMidKWn5u+OIOxq1/XkgWYl2AIrunupfsY5Q/z6rIpEHN1kd/VSLdRlri9 M2LC+uT7w+DfJdILenaURprcJFuAPzsk8GTpc5RuUUKpwzx7EtcmgoRlhg287JYC zwxONady0QA/7FefvEBegzvgXJbYS0KKPlMhJKhiVg188IGo4cmpOgBfa1hkhuI= =hAl0 -----END PGP SIGNATURE----- --vMRSWKslnwsTnf91DJTsIRwhb1dQRDmIn-- From nobody Thu Jul 13 15:41:35 2017 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 24179127869 for ; Thu, 13 Jul 2017 15:41:34 -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 vta6EIPGJcBv for ; Thu, 13 Jul 2017 15:41:32 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 AA22E12717E for ; Thu, 13 Jul 2017 15:41:32 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id d193so8371552pgc.2 for ; Thu, 13 Jul 2017 15:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3tfYYMfTUejmtsA6EjSSEYqsl/FkJh1v9MknI6mcQfs=; b=fJYs40GLkYDSioIWMUv+I+eFK4vrmmSBYgBjOCzqYwC7AvJOCmj+67sCW8064FyM3Y +bIcwQqEcU97SpZxOF4MK5N51lR0WTGQuD1jBiSgFJSGD2DIklM9sL3Pg3ud0sjsWkCu Zr+cMtBXQ9yjlFMhFwzS4GiYXD4pAjjp3vJSGWpVFkrJTa0B1XF5pCq4BrD+vI7rzHcD 6o6Y8Qqdmk/WyAEM6IbAo0dpjzcexi454n7ot9DEOSrzkv16q1ADpWGjs7+eW1OQY0kc jRI2KtNZSyLkf7ONACy1Sr6D5v4K63TBOuvDoa01DeqU3D7N1mDuXGYgmHuMR6WnTmlv iy3w== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3tfYYMfTUejmtsA6EjSSEYqsl/FkJh1v9MknI6mcQfs=; b=umeIBF00bGJt8WwWf+mcYEO8DLVy8/6hi71zyEIBVUo8mxCs80rmLUXcypBwtEn/9d 62bqtCp/YqEUIzvRa6JUEVNGtan5XY1q78mZSCZmhwZs3eSCCMtdUXr33RrLvZx1ffGZ pa1CRt23IVTIU27Xw9CYuRr/kETif9oQqzyfmqGliBfyZkBjN6xJqmzx0+g5k5zYC/ST 8QAjm1OA5GOHPrDLspN5wfT0p/xx4pz2qGjvqq6sE0nU61epcdrgN80+Q+4oL1qa8x5k BlTW/ZggWX4tuvaS0uCTRyUOTt3YeVifn4sM83YlQv/n+s84KjHuHd8zLLAM1Sk1x9g2 Q+jw== X-Gm-Message-State: AIVw110xawhZ3o8U/Z+ztx1DtyKPMrdUycutacDHb4vE9frwXZis2Uo4 vaazUXaVekhHJqSd X-Received: by 10.84.135.101 with SMTP id 92mr12406382pli.56.1499985692034; Thu, 13 Jul 2017 15:41:32 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id x14sm14282993pfe.83.2017.07.13.15.41.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 15:41:31 -0700 (PDT) To: Eliot Lear , Toerless Eckert Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 14 Jul 2017 10:41:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 22:41:34 -0000 On 14/07/2017 08:58, Eliot Lear wrote: > Hi Toerless, > > > On 7/6/17 9:09 AM, Toerless Eckert wrote: >> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: >>> It used to be, but the recommendation today is a pseudo-random >>> value (RFC7217). In any case it's a software choice. >> brand new recommendations do not equate to be expected >> standard practice in products. Would be very good to have >> folks with practical insight into various products to >> provide more information. > On this point, I think it's quite likely that we will see a good number > of devices fielded that will do a lousy job of PRNG, and so it would be > inadvisable for them to implement RFC7217, lest they test their DAD code > in ways not really intended. I'm not thinking about iPhones here, but > energy harvesting devices like some light switches, and a bunch of, > well,... crap. > > The question is whether you should design for these devices. IMHO "no" > is a perfectly valid answer, but I'm still a bit skeptical about the > value of 7217 for these class of devices in any event. That may be true, but for BRSKI as such, the only hard requirement is an address that is unique on a given link, which is a requirement anyway. IPIP is more of an issue for the node providing the proxy, which is hopefully a bit upscale from a light switch. Brian From nobody Thu Jul 13 23:13:34 2017 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 ECF921317DF for ; Thu, 13 Jul 2017 23:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjpL_vHnJTRu for ; Thu, 13 Jul 2017 23:13:32 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0AF12EC02 for ; Thu, 13 Jul 2017 23:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2625; q=dns/txt; s=iport; t=1500012811; x=1501222411; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=pVuulkKHdJfh3KThOZP/aMqPiXbYiYwCYAWqihgzuC8=; b=MA+p/Tc2PaTIDt+LKUbHnjHH69Lfjci2PvOHpdc+DnmWzHnfz7K+LK7r KZISZ2hdBJd/PLPnDey3iKaiBPGRsmOuAsjwoWCjRj1iv/dFduTnGXF9U SnkpB/ZgMF4F4Ti6VP+ZEVdtTklC7zx857K1WWlxHYCA5BVY6a9kMK0Wy I=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAABNYGhZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBk11zkGUilgSCEQeFbwKEKxgBAgEBAQEBAQFrKIUZAQUjVhALGCoCAlc?= =?us-ascii?q?GAQwIAQGKK68jgiaLHwEBAQEBAQEBAQEBAQEBAQEBAREPgyiFLisLgm6HfYJhB?= =?us-ascii?q?Z8xhCyCHY1LiyyHAJVVHziBCjEhCBsVh2E+iQYBAQE?= X-IronPort-AV: E=Sophos;i="5.40,357,1496102400"; d="asc'?scan'208";a="653234756" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2017 06:13:27 +0000 Received: from [10.61.242.235] ([10.61.242.235]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6E6DRUf002265; Fri, 14 Jul 2017 06:13:27 GMT To: Brian E Carpenter , Toerless Eckert Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: <0a15cb9d-b1a8-9627-1426-78999ea2456c@cisco.com> Date: Fri, 14 Jul 2017 08:13:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nco6g47WKwSf0KbLBncOmHJpD7MDqrFQ1" Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 06:13:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nco6g47WKwSf0KbLBncOmHJpD7MDqrFQ1 Content-Type: multipart/mixed; boundary="CxtuNbDVCEoxwh7559nRNS1g3Cjdp62sV"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , Toerless Eckert Cc: Anima WG Message-ID: <0a15cb9d-b1a8-9627-1426-78999ea2456c@cisco.com> Subject: Re: [Anima] Is this how BRSKI/IPIP works? References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> In-Reply-To: --CxtuNbDVCEoxwh7559nRNS1g3Cjdp62sV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Brian, On 7/14/17 12:41 AM, Brian E Carpenter wrote: > > That may be true, but for BRSKI as such, the only hard requirement is > an address that is unique on a given link, which is a requirement anywa= y. > IPIP is more of an issue for the node providing the proxy, which is > hopefully a bit upscale from a light switch. > I made my comment in the context of a possible interface collision in your diagram. Those had to do with the autonomic nodes, not the proxies, as I understand things. To avoid those sorts of collisions, it seems like using the h/w address remains sensible. A collision in those circumstances would be extremely unlikely, whereas relying on poor PRNG almost assures it of happening. These devices are likely to have very little entropy available to them. Eliot --CxtuNbDVCEoxwh7559nRNS1g3Cjdp62sV-- --nco6g47WKwSf0KbLBncOmHJpD7MDqrFQ1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZaGEHAAoJEIe2a0bZ0nozFcgH/2FyHrwBi3ee90rkNa25O1kA DKcRCj1WfxTVn/dp2+pduxUwtdj6lkmaJRSnzsJWDFyzn2B9b/FqJEMnGftVDZd1 sOz1yBkEb9ugoxH0J1p8ODjBkthgx5WZ4faKJ22tI0WTMGAymMDWjBJTt3qSJOYH 5NdN3tTwyjN58H4EXhY34GUskwLTjC7KmPlnR3vV/i7WzqN2H1IDEhH8IMhsZ3Py RPFou5uFmSkLEwYkPcqa8eJUYNJO9REFCi212eFiyKYc+3P030Jy+5hQlJJ0v3Ib FseW7WQbTWbHO5zDSmxjhzX5UPMvjwcd8YfjEg7J8WjEAhsnS++ieMrbcJVDCOI= =i98F -----END PGP SIGNATURE----- --nco6g47WKwSf0KbLBncOmHJpD7MDqrFQ1-- From nobody Fri Jul 14 00:21:59 2017 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 23B8C131B04 for ; Fri, 14 Jul 2017 00:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eyZzd5SUdeR for ; Fri, 14 Jul 2017 00:21:55 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF4E131B01 for ; Fri, 14 Jul 2017 00:21:53 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud3.xs4all.net with ESMTP id kXMp1v0014ydcfa01XMpp6; Fri, 14 Jul 2017 09:21:51 +0200 Received: from 2001:983:a264:1:20b1:41dd:45ca:1387 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 14 Jul 2017 09:21:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Jul 2017 09:21:49 +0200 From: peter van der Stok To: Michael Richardson Cc: anima Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <9183.1499933298@dooku.sandelman.ca> References: <9183.1499933298@dooku.sandelman.ca> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Anima] pinned-domain-certificate and other BRSKI comments X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 07:21:57 -0000 > > 4) >application/voucherrequest The request is a "YANG-defined JSON< > > Is it reasonable that this is "format=pkcs7" (the default), and that > we will grow/migrate via format=jwt or format=cwt? > What does "grow" mean? Peter From nobody Fri Jul 14 00:52:07 2017 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 65DE9131AF1; Fri, 14 Jul 2017 00:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyyVFh-KvnUN; Fri, 14 Jul 2017 00:52:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEA212ECAD; Fri, 14 Jul 2017 00:52:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKI90249; Fri, 14 Jul 2017 07:52:01 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 14 Jul 2017 08:52:00 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 14 Jul 2017 15:51:49 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 Thread-Index: AdL8dgeGeqrzdF3AS+G8GeTmlBANqw== Date: Fri, 14 Jul 2017 07:51:48 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.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_5D36713D8A4E7348A7E10DF7437A4B927CDFE66FNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.59687821.00F3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6ef12476b10f6ad57b8732b890cf802e Archived-At: Subject: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 07:52:05 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CDFE66FNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This message starts the two-week ANIMA Working Group Last Call to advance d= raft-ietf-anima-stable-connectivity-03, Using Autonomic Control Plane for S= table Connectivity of Network OAM. This document's intended status is Infor= mational. At present, there is no IPR file against this document. Please send your comments by July 28, 2017. If you do not feel this docume= nt should advance, please state your reasons why. Sheng JIANG is the assigned document shepherd. Regards, Sheng & Toerless --_000_5D36713D8A4E7348A7E10DF7437A4B927CDFE66FNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This message starts the two-week ANIMA Working Group Last Call to advanc= e draft-ietf-anima-stable-connectivity-03, Using Autonomic Control Plane for Stable Connectivity of Network OAM. This= document's intended status is Informational. At present, there is no IPR f= ile against this document.

 

Please send your comments by July 28, 2017. If you do not feel this = ; document should advance, please state your reasons why.

 

Sheng JIANG is the assigned document shepherd.=

 

Regards,

 

Sheng & Toerless

--_000_5D36713D8A4E7348A7E10DF7437A4B927CDFE66FNKGEML515MBXchi_-- From nobody Fri Jul 14 06:09:24 2017 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 3ACB813170E for ; Fri, 14 Jul 2017 06:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpPwwe2PdU48 for ; Fri, 14 Jul 2017 06:09:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58B91296C9 for ; Fri, 14 Jul 2017 06:09:21 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [62.168.35.69]) by relay.sandelman.ca (Postfix) with ESMTPS id C41DA1F8FB; Fri, 14 Jul 2017 13:09:20 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1145159F; Fri, 14 Jul 2017 09:09:18 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: Toerless Eckert , Brian E Carpenter , Anima WG In-reply-to: References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Eliot Lear message dated "Thu, 13 Jul 2017 22:58:45 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 14 Jul 2017 15:09:18 +0200 Message-ID: <9854.1500037758@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 13:09:23 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: > On 7/6/17 9:09 AM, Toerless Eckert wrote: >> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: >>> It used to be, but the recommendation today is a pseudo-random >>> value (RFC7217). In any case it's a software choice. >> brand new recommendations do not equate to be expected >> standard practice in products. Would be very good to have >> folks with practical insight into various products to >> provide more information. > On this point, I think it's quite likely that we will see a good number > of devices fielded that will do a lousy job of PRNG, and so it would be > inadvisable for them to implement RFC7217, lest they test their DAD code > in ways not really intended. I'm not thinking about iPhones here, but > energy harvesting devices like some light switches, and a bunch of, > well,... crap. > The question is whether you should design for these devices. IMHO "no" > is a perfectly valid answer, but I'm still a bit skeptical about the > value of 7217 for these class of devices in any event. 1) Constrained devices are out of scope for ANIMA. 2) even if they were in scope, kinetic powered light switches are not good candidates for join proxies. Light bulbs, however. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZaMJ9AAoJEJVM4Vb9/EKQN6EH/iTsG9QUyxFOSNztcx6TJn97 75pMVX8v7no6Vtu2SCsMzgv+hY0JGeKSPhTIgMWnNeJzkZRQ2tNvdiHipXiXTnQJ pFGZAFTrJVa9sWYd+WEOu1PlqF1/F+InFBHrfvFv1O/gQohfV2uvoHnLAgim5fN9 ONRNKFj7CFfMWmKVjIzGORpi2OiL2yzaagzw2EQg6a6ZzzitgAteacDhkmQ7VDDh d75FSHLBHO2raBVwoEhE/lbTazzEFx85OJIOhH9J1f0WqdhgXIPJG0iT8DiWFoRg A4pvRO+hx9YRgyqHe73iJcZUfMAYktX/4FclUyU48+FJLGmCwanz6cTNcbSbsrs= =8yEO -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 14 06:16:48 2017 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 7AD07131B75 for ; Fri, 14 Jul 2017 06:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQQ00WRwp8PF for ; Fri, 14 Jul 2017 06:16:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ACC131B74 for ; Fri, 14 Jul 2017 06:16:45 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [62.168.35.69]) by relay.sandelman.ca (Postfix) with ESMTPS id 5AADF1F8FB; Fri, 14 Jul 2017 13:16:44 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id A4EEF59F; Fri, 14 Jul 2017 09:16:41 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org cc: anima In-reply-to: References: <9183.1499933298@dooku.sandelman.ca> Comments: In-reply-to peter van der Stok message dated "Fri, 14 Jul 2017 09:21:49 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 14 Jul 2017 15:16:41 +0200 Message-ID: <10708.1500038201@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] pinned-domain-certificate and other BRSKI comments X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 13:16:46 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> 4) >application/voucherrequest The request is a "YANG-defined JSON< >> >> Is it reasonable that this is "format=pkcs7" (the default), and that >> we will grow/migrate via format=jwt or format=cwt? > What does "grow" mean? I mean, extend the protocol through additional RFCs. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZaMQ5AAoJEJVM4Vb9/EKQefYH/2ixeHNbqGBU82eCJEKsgMAx oG88xR+2e4QY/0rrA9m+u5Gk+drijXCj5KGdBfbJYfdpyWbMZXoO1E8gMK8vzeW6 LQDLx/zvmQu3bRoyQpntsJun6vPUY0aMfQaThCsEdp61pcE95WB8uMlnfQ/ETAZ+ ypXjMYLfkjdqfDN3NvfLFHLwZGBG/BIzBSBcHpB3y7CtRglycBTWeZQKL6Fyojey e2CJpCi4dR8/tTB7YdRGT7TRDSYTMbJVI3IwBojTEOZjpYyT6kXSC5WOSrA50bjD P/OGEaoD77jV6oiZlW5XXNaLzFB2wDdFuaKu3m0JDP5WvarOc4HBDPp6sx+FxIE= =ZV8T -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 14 13:14:03 2017 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 CC6EF131940 for ; Fri, 14 Jul 2017 13:14:01 -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 tFsBg463Rl1v for ; Fri, 14 Jul 2017 13:14:00 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1975E1319B4 for ; Fri, 14 Jul 2017 13:13:59 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id e7so50185301pfk.0 for ; Fri, 14 Jul 2017 13:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8z2UqDfy2TZ1/IFPbBPwYG/bEyCkTvfRW8rNIdgRuiM=; b=EuEPkmsPv404Kq82OAQKT93NfHyGPDjRFA44Su837dmFotxSB6naXJlTx+JDZEscyG t20N5GGfnCcTe7qP+Ir1D0qQvv7wFcptwrJEcAd9dR/EbwfM2LMnoUhtXwOnUXlyE4T4 K+/kFcNTef/2LFVksMZxHRFvmao/a8sqzezVALO99VYVks6ukDGhg1LwFZ7GGyY+pyxU HiA1lwj06jrQ6kc69aprKCwi0IsJz2ekJM5AIqX70SH8yFp5wlmbud8bA96U/qGQxrVi KNVZ7WkI9LhqxHhwEm74tbIsa69qkg0Hva2cOp01sBFlTegi7vGUIEjpFLgB5QgQv0+9 BT8w== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8z2UqDfy2TZ1/IFPbBPwYG/bEyCkTvfRW8rNIdgRuiM=; b=VixGDoP9WiwPjzfxEtFWsONkh5lDEM/w1kdQyiGLHgxUeA8HHUsRdt3wDNmOxncsdI BYJl480p3U6zR/rfNgdMs4MPre9W4d2xxxxtmWyfYTe1G/PEXOLW3pGRON++YYw+0aDP DlM766leh3a6x/e9qIBNhngAVINGKiWbZjO9pF/QA8JPMwqQEaEYSAzrgNgo7tIO+uAt cSogydbNi4lmBeL02JLnz2rHAl1d4bX3JrqVPTycB/eh75zbus4sDMa90HMiEO/LYm6J lFlbt90j7hP/8PA6E6pT+4iBnSLdgdF2VonkcTHuv49LBI7k5QFekKJZ7K7s7ptP0C2m YcGw== X-Gm-Message-State: AIVw110Dz6oZNvLxHc3BK+Miv/KYt0VQSNMEotges2EFKoZ4+nYMxktW emOg8rNdD3U1Yw1a X-Received: by 10.84.178.129 with SMTP id z1mr17624189plb.260.1500063239395; Fri, 14 Jul 2017 13:13:59 -0700 (PDT) Received: from ?IPv6:2406:e001:55f4:1:28cc:dc4c:9703:6781? ([2406:e001:55f4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p5sm17123208pgf.50.2017.07.14.13.13.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 13:13:58 -0700 (PDT) To: Michael Richardson , Eliot Lear Cc: Toerless Eckert , Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <9854.1500037758@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 15 Jul 2017 08:14:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9854.1500037758@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 20:14:02 -0000 On 15/07/2017 01:09, Michael Richardson wrote: > > Eliot Lear wrote: > > On 7/6/17 9:09 AM, Toerless Eckert wrote: > >> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: > >>> It used to be, but the recommendation today is a pseudo-random > >>> value (RFC7217). In any case it's a software choice. > > >> brand new recommendations do not equate to be expected > >> standard practice in products. Would be very good to have > >> folks with practical insight into various products to > >> provide more information. > > > On this point, I think it's quite likely that we will see a good number > > of devices fielded that will do a lousy job of PRNG, and so it would be > > inadvisable for them to implement RFC7217, lest they test their DAD code > > in ways not really intended. I'm not thinking about iPhones here, but > > energy harvesting devices like some light switches, and a bunch of, > > well,... crap. > > > The question is whether you should design for these devices. IMHO "no" > > is a perfectly valid answer, but I'm still a bit skeptical about the > > value of 7217 for these class of devices in any event. > > 1) Constrained devices are out of scope for ANIMA. True, but let's not use that as an excuse, because our stuff might just get used more widely. > 2) even if they were in scope, kinetic powered light switches are not > good candidates for join proxies. Light bulbs, however. But On 14/07/2017 18:13, Eliot Lear wrote: ... > I made my comment in the context of a possible interface collision in > your diagram. Those had to do with the autonomic nodes, not the > proxies, as I understand things. To avoid those sorts of collisions, it > seems like using the h/w address remains sensible. A collision in those > circumstances would be extremely unlikely, whereas relying on poor PRNG > almost assures it of happening. These devices are likely to have very > little entropy available to them. And they may well be BRSKI pledges, just not using GRASP for discovery. So Eliot's point seems valid (but not an issue for ANIMA alone). Brian From nobody Fri Jul 14 14:44:54 2017 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 E209213145A for ; Fri, 14 Jul 2017 14:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUJmvGy0b9_r for ; Fri, 14 Jul 2017 14:44:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2CD1205F0 for ; Fri, 14 Jul 2017 14:44:49 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 232361F8FB; Fri, 14 Jul 2017 21:44:48 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 005602854; Fri, 14 Jul 2017 23:44:42 +0200 (CEST) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-reply-to: References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> <25643.1499875039@dooku.sandelman.ca> <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com> <17795.1499938811@dooku.sandelman.ca> Comments: In-reply-to Brian E Carpenter message dated "Fri, 14 Jul 2017 08:36:41 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 14 Jul 2017 23:44:42 +0200 Message-ID: <7355.1500068682@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 21:44:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> Brian E Carpenter wrote: > OK, I'm >> getting there. More in line: >>=20 >> >> 1) Registrar accepts any Lx1 as local. There is no precedent in = v6 >> >> APIs to open such a socket, but this actually supported on many >> >> platforms. It's used for nasty stuff like transparent application >> >> layer proxies, forced HTTP proxying, and the like. >>=20 >> > I think there's a more subtle way to look at it. When the registrar >> > receives a protocol 41 packet from a new ACP address, it >> conceptually > synthesises a new virtual interface and assigns Lx1 as >> its link local > address. On that interface, things would look >> normal. Thus RFC2473: >>=20 >> I can buy this. It argues that the Proxy should send a gratuitous >> packet to the Registrar to prime that virtual interface. An ICMP ec= ho >> request perhaps. > Or a GRASP M_NOOP, designed for such purposes! I think that's also reasonable.=20=20 =20 >> How can we document this well? > I think it has to be spelled out almost at the pseudocode level. We h= ad > to spell out the encap/decap behaviour for 6to4 in some detail, and > that was just about the only bit of 6to4 that never created trouble > ;-). There are various encap/decap specs of that kind, and the NAT64 > stuff also goes into horrible detail... okay. Are you suggesting the 6to4 document should be looked at for style? =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----- Version: GnuPG v1 iQEcBAEBAgAGBQJZaTtKAAoJEJVM4Vb9/EKQASEH/3Zp+ypS/oe13WcBKZU9CqXD ZlhdzIduXDYUK8PWFeUCzxYfjfTPY57pKn7Ki3KiKaLCNtw1m2Hyy9FWjr0xxsQ3 D/Q/VTEJ5BCyaTcnW/ajeo8RqlX+5POscmx+hZWc62k+zU3HHwDxA0WjMiogaTVL zK3qzG/8j/R2Sx4GR1VgCfUVfnYW25OiNCCVY7EpUwbV2DKuhftQhvNzNsdHxGsx IX8noipuwqMTxJMsGD3KgUsvn7/pk24E2Be1FL3Nu2u3BoCXw8sdRvqMfsBRpDCb EmmGx13+AYaY+Hxtlgm3z4QMZlqUyRecGWznhAkWCU5g7Qk6yyASbmvvZEDg3BM= =aAHL -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 14 16:01:54 2017 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 B1630127444 for ; Fri, 14 Jul 2017 16:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo1nkBbQooBl for ; Fri, 14 Jul 2017 16:01:51 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC2F126DD9 for ; Fri, 14 Jul 2017 16:01:51 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 0C59A1F8FB; Fri, 14 Jul 2017 23:01:50 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3EA4B27F8; Sat, 15 Jul 2017 01:01:47 +0200 (CEST) From: Michael Richardson To: Brian E Carpenter cc: Eliot Lear , Toerless Eckert , Anima WG In-reply-to: References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <9854.1500037758@dooku.sandelman.ca> Comments: In-reply-to Brian E Carpenter message dated "Sat, 15 Jul 2017 08:14:04 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 15 Jul 2017 01:01:47 +0200 Message-ID: <15646.1500073307@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 23:01:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > But On 14/07/2017 18:13, Eliot Lear wrote: ... >> I made my comment in the context of a possible interface collision in >> your diagram. Those had to do with the autonomic nodes, not the >> proxies, as I understand things. To avoid those sorts of collisions, >> it seems like using the h/w address remains sensible. A collision in >> those circumstances would be extremely unlikely, whereas relying on >> poor PRNG almost assures it of happening. These devices are likely = to >> have very little entropy available to them. > And they may well be BRSKI pledges, just not using GRASP for discover= y. > So Eliot's point seems valid (but not an issue for ANIMA alone). 7217 says: RID =3D F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) only the secret_key is really unique, and perhaps that's what you are worrying about? secret_key: A secret key that is not known by the attacker. The secret key SHOULD be of at least 128 bits. It MUST be initialized to a pseudo-random number (see [RFC4086] for randomness requirements for security) when the operating system is installed or when the IPv6 protocol stack is "bootstrapped" for the first time. As the secret_key should be generated when the system is "installed" or "first bootstrapped", I'm not sure the PRNG quality at runtime. It seems to me like the secret_key should be set at manufacturer time on the "bed-of-nails" or other JTAG point, at the same time when the BRSKI IDevID and (perhaps) MASA anchors are loaded. If those things are in a TPM, then the secret_key could be there too. =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----- Version: GnuPG v1 iQEcBAEBAgAGBQJZaU1bAAoJEJVM4Vb9/EKQNcYH/jNBuO1f9dPv/mviQMmzxJHt 5tt4mub+tJHwET8TW9Qp/57aWIOzzn2W4+QheF9+sj4oTYWQq/F27x2higWK/b3R sWP9hEzSAVcveXE/XIoGamG/9o/WfFGmtYxqamGodQvHWCyI2dU9iKHq+FPU1wca H5m8OecaGBR1jV2pKMR5veYD0kcU7lQ24a+EyKx00xnIt22XlQNxiXd7qr+M7D8L TTYorKiV5CYV7enqykrBO9VPG94SMDobKJOUgPBhCIkudXdwD2aDQbuziwEQ1ArR rZeN3vl8JqJKwmhBsohcba0+l3wFY7+lVVAUUukgMcIyzYEdeVwZAI5jwygUQio= =ECA+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 14 19:08:24 2017 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 5674F12F299 for ; Fri, 14 Jul 2017 19:08:22 -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 RFQwsBMBNToI for ; Fri, 14 Jul 2017 19:08:21 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 E173F12EB4E for ; Fri, 14 Jul 2017 19:08:20 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id k14so53405467pgr.0 for ; Fri, 14 Jul 2017 19:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1MdYbt6aPZQMxbbyC/BMMjnw0pebsSeDQHLwRnidW4g=; b=JgXCdTXDlnE6UqjOem3YLW5XaoaEamFBjyocsHWBnNQYuabMVvmBfsdLPzPnSBG3Gt NCpVIQ66kw06batN60E97Dg1HR6lWsa5VimQEcwGV7pnSF5Kw4q1hc24Q3iJv04m0+cb bWGS1Tz7A94XmODj+6eWHr1WFWNsNBLBVzs3Egp7RcAju8NGk9YM8jVkSCgSFEQ7ByJ5 mAMiZvlbAYxXvgfewr7w0bf5VZOFB+wEEEE2Vq7/McMEy9RgRraoX+Jhnqqy0M9mVedq jAcbVQXtiMJAiYi8lDP+ZiCRB0Kefa0ghqG7Y/nktD8KJiRfATNRfRY+jcy6GcKYoTWm 4VUQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1MdYbt6aPZQMxbbyC/BMMjnw0pebsSeDQHLwRnidW4g=; b=qgmZ1rlLDdzl631SiXffL+1IrIPBlRbs1Z29rOqf8zO+RIMo0o1AzY8CKR2ZMNaPio v8MPzaIHCLJL1USEE+TVT2PSSwFIf7/tyHNiv8RLpyt0zI6fCkE2ptH/DJpPOE/Da85e HKlH6pwt/Pz1ru7y6uqveXrbZPSaqtTsPwW7FhguHn5mfb7CMxLTu4MsyQjaFZ4jEwYC 4HEV086yzoF+lTPMEKszSChKzltI/04PcAR0B26e8rARQU2nAdEeNG1tdQGoza2mXR6r 0/fSEhCNUTTuWkzC5WGr3GUDDcbafDJNux+hR7sW9RHmTe0IMNLlK/p9awVc6uubo/z0 4gkg== X-Gm-Message-State: AIVw111V4tGlCgQM5x605KshhwPieA/Ur2mZT1J8LjAFsuVBC+AN+qKx 6y1sYZxXdlb52bjN X-Received: by 10.84.130.42 with SMTP id 39mr18746060plc.60.1500084500150; Fri, 14 Jul 2017 19:08:20 -0700 (PDT) Received: from ?IPv6:2406:e001:55f4:1:28cc:dc4c:9703:6781? ([2406:e001:55f4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n3sm17333415pfb.87.2017.07.14.19.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 19:08:19 -0700 (PDT) To: Michael Richardson Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> <25643.1499875039@dooku.sandelman.ca> <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com> <17795.1499938811@dooku.sandelman.ca> <7355.1500068682@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0fba3423-b41b-7338-dc87-b851b0634d38@gmail.com> Date: Sat, 15 Jul 2017 14:08:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7355.1500068682@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jul 2017 02:08:22 -0000 On 15/07/2017 09:44, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> Brian E Carpenter wrote: > OK, I'm > >> getting there. More in line: > >> > >> >> 1) Registrar accepts any Lx1 as local. There is no precedent in v6 > >> >> APIs to open such a socket, but this actually supported on many >> > >> platforms. It's used for nasty stuff like transparent application >> > >> layer proxies, forced HTTP proxying, and the like. > >> > >> > I think there's a more subtle way to look at it. When the registrar > >> > receives a protocol 41 packet from a new ACP address, it > >> conceptually > synthesises a new virtual interface and assigns Lx1 as > >> its link local > address. On that interface, things would look > >> normal. Thus RFC2473: > >> > >> I can buy this. It argues that the Proxy should send a gratuitous > >> packet to the Registrar to prime that virtual interface. An ICMP echo > >> request perhaps. > > > Or a GRASP M_NOOP, designed for such purposes! > > I think that's also reasonable. > > >> How can we document this well? > > > I think it has to be spelled out almost at the pseudocode level. We had > > to spell out the encap/decap behaviour for 6to4 in some detail, and > > that was just about the only bit of 6to4 that never created trouble > > ;-). There are various encap/decap specs of that kind, and the NAT64 > > stuff also goes into horrible detail... > > okay. Are you suggesting the 6to4 document should be looked at for style? Not especially. I'm more saying: if you can't write the equivalent of pseudocode, you can't expect other programmers to get it right. Maybe a really good example of a painstaking encap description is in IPsec: RFC4301 section 5.1.2 and its subsections. I don't think we need to go that far, but we need to be 100% unambiguous. All IMHO of course. Brian From nobody Sun Jul 16 10:24:57 2017 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 7CC00126DC2 for ; Sun, 16 Jul 2017 10:24:56 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 BZrznPj0fQHN for ; Sun, 16 Jul 2017 10:24:54 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757FD124D68 for ; Sun, 16 Jul 2017 10:24:54 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0E4BC58C4B0; Sun, 16 Jul 2017 19:24:50 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D1AD7B0C5DA; Sun, 16 Jul 2017 19:24:49 +0200 (CEST) Date: Sun, 16 Jul 2017 19:24:49 +0200 From: Toerless Eckert To: Eliot Lear Cc: Brian E Carpenter , Anima WG Message-ID: <20170716172448.GA23525@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 17:24:56 -0000 Sorry, cathing up late with the thread. Thanks, Eliot. Thats good information. The MAC address based limited link-local address space is a problem for devices running a proxy. Do you have an idea about some class of devices that has the issue that you describe and that could be proxies ? I know about these crazy LED lightbulbs that actually build a mesh network. Is that what you where alluding to ? But would those type of devices really be able to do all the security stuff of ANIM/BRSKI ? Cheers Toerless On Thu, Jul 13, 2017 at 10:58:45PM +0200, Eliot Lear wrote: > Hi Toerless, > > > On 7/6/17 9:09 AM, Toerless Eckert wrote: > > On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: > >> It used to be, but the recommendation today is a pseudo-random > >> value (RFC7217). In any case it's a software choice. > > brand new recommendations do not equate to be expected > > standard practice in products. Would be very good to have > > folks with practical insight into various products to > > provide more information. > On this point, I think it's quite likely that we will see a good number > of devices fielded that will do a lousy job of PRNG, and so it would be > inadvisable for them to implement RFC7217, lest they test their DAD code > in ways not really intended. I'm not thinking about iPhones here, but > energy harvesting devices like some light switches, and a bunch of, > well,... crap. > > The question is whether you should design for these devices. IMHO "no" > is a perfectly valid answer, but I'm still a bit skeptical about the > value of 7217 for these class of devices in any event. > > Eliot From nobody Sun Jul 16 10:50:22 2017 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 D5A0C124C27 for ; Sun, 16 Jul 2017 10:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWOoGSP8xC6B for ; Sun, 16 Jul 2017 10:50:16 -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 5086D120724 for ; Sun, 16 Jul 2017 10:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3269; q=dns/txt; s=iport; t=1500227416; x=1501437016; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=2ZROXsMvipIbE+ELPBJWhHdGoS3sKO9paOT1rVXJgsA=; b=It21Pkbv0zTXNRG/hOb2DhnKHWB1uV2eMSnMEMoVQ2a3DDVNsiIc7GBa TWURDjxBikHX/UWfXNu0OAo97DdGaJPxtdlp6n5c1PONCO950fLMjOYMx gt1enfMvixC5xyPGXaRmNQKBbp88EZ5V58zoGynoVvhBsuVTNP+WSur4u E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAgB+pmtZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBlFCQSSKYFQeFQAKENBQBAgEBAQEBAQFrKIUYAQEBAQIBI1YQCw4KFRU?= =?us-ascii?q?CAlcGDQgBAYojCK1qgiaLEgEBAQEBAQEBAgEBAQEBAQESD4MohS4rC4JuhEZjg?= =?us-ascii?q?lSCYQEEnzSELIIdjU2LLocBlVc2IYEKMSEIGxWHYT6GTYI/AQEB?= X-IronPort-AV: E=Sophos;i="5.40,370,1496102400"; d="asc'?scan'208";a="656125567" 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; 16 Jul 2017 17:50:12 +0000 Received: from [10.61.216.24] ([10.61.216.24]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6GHoB6e026037; Sun, 16 Jul 2017 17:50:11 GMT To: Toerless Eckert Cc: Brian E Carpenter , Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <20170716172448.GA23525@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: Date: Sun, 16 Jul 2017 19:50:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170716172448.GA23525@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dvSrEd9ErugwvbsO28PsrwgwJOFwOBJd9" Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 17:50:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dvSrEd9ErugwvbsO28PsrwgwJOFwOBJd9 Content-Type: multipart/mixed; boundary="CmUPlrb3Eo92CLQxHxee3N5O1TL9KUvSO"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert Cc: Brian E Carpenter , Anima WG Message-ID: Subject: Re: [Anima] Is this how BRSKI/IPIP works? References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <20170716172448.GA23525@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170716172448.GA23525@faui40p.informatik.uni-erlangen.de> --CmUPlrb3Eo92CLQxHxee3N5O1TL9KUvSO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 7/16/17 7:24 PM, Toerless Eckert wrote: > Sorry, cathing up late with the thread. > > Thanks, Eliot. Thats good information. The MAC address based limited > link-local address space is a problem for devices running a proxy. > Do you have an idea about some class of devices that has the issue > that you describe and that could be proxies ? Sure. Just about any device that does a poor job of randomization or have a low amount of entropy. And that, I'm afraid, is a very large swathe of stuff. But again, I think the diagram Brian drew out indicates the problem to be with autonomic node, not the border device, and there the problem will be assuredly more pronounced. > > I know about these crazy LED lightbulbs that actually build a mesh > network. Is that what you where alluding to ?=20 > > But would those type of devices really be able to do all the > security stuff of ANIM/BRSKI ? Good question. I do think that lightbulbs are likely to do okay with this stuff, but smaller devices will probably not, simply as a matter of COGS. There are different forms of sensor networks in which the devices are highly constrained. It may be possible to pre-store a certain amount of entropy, which can ease some of this, but in those cases developers will need to be economical. The use of different forms of interface addresses, including CGAs needs to take into account this parameter. Eliot --CmUPlrb3Eo92CLQxHxee3N5O1TL9KUvSO-- --dvSrEd9ErugwvbsO28PsrwgwJOFwOBJd9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZa6dTAAoJEIe2a0bZ0nozRtkH/iW15hdhFDSnJBhgCCRT3stv d21q1l8OH+QzkKMUBrxg2LACZjZ69x4KnA9EN9Q6Xc1A6//VXkR0KZLGmdGCZuoJ KHIktC8eMlEDoqXUij043zuRu0C+sAy10Fm1b3VwtgkY3hXtMvUEoei6Puyc0/Se sZq3JM58V/R/nUjYAps7YJmSr6NhxTni9tdU6Ps+HGok/MKGqnvrs1a+j9VZCHEB 643HuLtFQ+k1IEOoUjqOVEVslaDeJ9ZXtnvaUCLvufGHDQ/pHfOBV2mRZWergMh/ xZ/Z+MgXlfXyrY1aS+w7DVSRK50CbfXstTyf90w7Svu3nGTsidUWokHKWECa5xs= =qdfA -----END PGP SIGNATURE----- --dvSrEd9ErugwvbsO28PsrwgwJOFwOBJd9-- From nobody Sun Jul 16 11:27:58 2017 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 5D197128961 for ; Sun, 16 Jul 2017 11:27:56 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 P0zo8KirlAgY for ; Sun, 16 Jul 2017 11:27: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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0660912702E for ; Sun, 16 Jul 2017 11:27:53 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1B9BD58C4B0; Sun, 16 Jul 2017 20:27:50 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E24B4B0C5DA; Sun, 16 Jul 2017 20:27:49 +0200 (CEST) Date: Sun, 16 Jul 2017 20:27:49 +0200 From: Toerless Eckert To: Michael Richardson Cc: Brian E Carpenter , Anima WG Message-ID: <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14885.1499820271@dooku.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 18:27:56 -0000 I thought i had asked that question already but not sure, and not seen an answer: - I have never seen that a device has more than one link-local addr on an interface. Is this permitted by IPv6 arck ? Can you configure this in eg: Linux. I thought i tried on linux/cisco-ios in the past and i do not quite remember, but i think it failed (only one address). - Do we have another address assignment scheme other than a) MAC address based, or b) RFC7217 or c) non-randomn manual config. Could we get some scope relative address range for this purpose ? More inline: On Tue, Jul 11, 2017 at 08:44:31PM -0400, Michael Richardson wrote: > There is a small problems with this. With a UDP transport, we simply > have to arrange for the registrar to accept traffic to any LxX IP address. > That's not stock POSIX, but it's not that hard. LxX state can be handled > by the application. With TCP the kernel has be rather flexible, being > able to keep duplicate Lp<->Lx1 connections seperate in the kernel, and > at the same time, permitting any LxX on the Registrar's side. How would this work, can you elaborate a bit ? Btw: Off the top of my head i think its a lot easier to forget kernel stuff and use a registrar that maps received eg: UDP (or IPinIP) packets with encapsulated UDP/CoAP payloads than trying to persuade to build a virtual interface for each association. When the payload becomes TCP/TLS/BRSKI, i do see more value in trying to have the registrar app NOT have to deal with TCP. > In my implementation, I dynamically set up an IPIP interface for each Lx > on each proxy that appears. The kernel assigns a new ifindex to each of > these interfaces, and the normal LL-requires-ifindex rules apply to > distinguish things. This requires a retransmission since the first time > there is a packet from a new Ax1/LAN1, the packet does not match any current > IPIP tunnel, and is dropped by the kernel. A process watches for these > and configures them LRU. > > > As for Toerless' notion that we should invent a new UDP-based encapsulation > rather than use the well defined IPIP encapsulation, I have really no comment. That easy to make you speech-less ? How bout writing a registrar on anything else than Linux. Do you feel confident you can get what you need into any OS kernel ? Cheers Toerless > I'm pretty sure that many will want to leverage existing v6-extension header > chasing hardware for the purpose of auditing, which is why I prefer not > to invent new on-the-wire formats just to so that some software engineer can > avoid having to learn a new API call. > > -- > ] 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 -- --- tte@cs.fau.de From nobody Sun Jul 16 13:42:14 2017 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 689B11270A7; Sun, 16 Jul 2017 13:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1IiUXOB5yjF; Sun, 16 Jul 2017 13:41:57 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB539128BA2; Sun, 16 Jul 2017 13:41:57 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 8D9881F8EE; Sun, 16 Jul 2017 20:41:56 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7BFF02C72; Sun, 16 Jul 2017 22:41:51 +0200 (CEST) From: Michael Richardson To: 6tisch@ietf.org, netconf@ietf.org cc: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 16 Jul 2017 22:41:51 +0200 Message-ID: <25931.1500237711@dooku.sandelman.ca> Archived-At: Subject: [Anima] BRSKI voucher document passed WGLC X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 20:41:59 -0000 --=-=-= Content-Type: text/plain It had been agreed when it was decided to put draft-ietf-anima-voucher into ANIMA rather than NETCONF or 6tisch, that the WGLC would be cross posted. Unfortunately, this was forgotten. (I'm reposting since I'm a member of all the lists) The WGLC is at: https://www.ietf.org/mail-archive/web/anima/current/msg02755.html The results of the WGLC is at: https://www.ietf.org/mail-archive/web/anima/current/msg02788.html At this point, the authors are still processing some small comments, so if you have more comments they would be very welcome. (Or pigeon hole me at IETF99 with bigger comments) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZa8+PAAoJEJVM4Vb9/EKQI3AH/jhKT4xSWafPwhuy3qlzQCYc 1D0OWtdzMH3wynbM/nDddZ7RqX48ajiA3XmbAJ5+qV/l3jO0q0V8g+XgE/PynLt1 s2Mv/K2eMf2wisRdYC7tX0cZi98r2QewT8VfA4kIvosML2h/Z+BaxncVF4PzKtH+ lQQAxB5GVGgk0WTnRfvoClyumVi8ykwQggeUPIT/52BFZA98FT8fPALWKXcluIvj NAxXVMzd1ZOKDhXbQaxpfcujLHTyhDnMF7DBTAgzka3NpUFHA/V5Om+mchWjmImP lNFUMMFu+wQLjOBU/7U4TPdA51mhDgJPojuUUea0lgviRdhfa3Z1FBb6eh8WMh8= =wWX4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 16 21:20:18 2017 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 4898A129B19 for ; Sun, 16 Jul 2017 21:20:16 -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 l2qorWHNg-Ym for ; Sun, 16 Jul 2017 21:20:12 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486B2129459 for ; Sun, 16 Jul 2017 21:20:12 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id e199so9174668pfh.2 for ; Sun, 16 Jul 2017 21:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Muxijk4e6z/V3nzJUUlb6bsEtNvjqjGzorGDq5OSi/4=; b=ITLyC+wZecTuhSiSjUDDQFJ1Qx7ndR3qoRrd+7PZk7Rz6Agd6AQEmzE2hYl4vsodNv 91SIcL8J6Gqmr/r+y+0ngr0rN8A4MtyVMFVObEi3X2wBtteVuSG231xQo1XJ9TgpX5r4 tM/YOAxYELNp5KSYBRm7S/BHINYkbb/I04JmvOXOBK68DbkMF42BgqhAv8AvZyCbA7Fe MwtXG0+yadCguA7ZJv4+GXqOdc+evCvM0dqMU7POTTmqmtcZaklqQPFGnyVL/2k7V/uq 0TAQPVk9eW9OwsN1c4QzMDPsycil5zphSxy6kQ28ZBsGIMM+oIN6TIGEuAYALOthyipw y4+A== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Muxijk4e6z/V3nzJUUlb6bsEtNvjqjGzorGDq5OSi/4=; b=r+XEphWEa2rzeFHbccZi+e1O+iA3QFhDoBWuVqffPyaSoIF3HG9lGzszIHyTnNmVq7 DFYHJGTm8LGbMSqizSfALTEVW5r3WG1qvOxPKxBzTNAZT0nhAOrl7Sz0cThuodX7hP9B L/ZvMfGGZiLcUvzn1LGKXeyn+L/xXIVddIbwRklsDF8UWIapglJs7ey+5uTFpw0bhIYW IOZSQNgB4sU70bRgascV6UzSkpyQ+cyvQW5rPnenocYOIuxPvEMvSfQogGg5D7EnkOTH PpucLc679t87SmEikh6/NU5d1jVRcNLKM2waie4N4jF3ZUpg8DFIpETGjxxii/qTA3bp 4OJA== X-Gm-Message-State: AIVw111/FBzwuabGXAPlXJ+h4703sq8gQiS0YDpBR3ODYw0/dSI5m7dK BVpn0jIzefCaBqy9 X-Received: by 10.84.217.132 with SMTP id p4mr1303928pli.217.1500265211414; Sun, 16 Jul 2017 21:20:11 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j193sm12253526pfc.95.2017.07.16.21.20.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 21:20:10 -0700 (PDT) To: anima@ietf.org References: <150026481446.32641.6276768016964215224@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <39693b29-cb82-9657-e4ba-e9992870855b@gmail.com> Date: Mon, 17 Jul 2017 16:20:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150026481446.32641.6276768016964215224@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-carpenter-anima-ani-objectives-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 04:20:16 -0000 Updated to match latest versions of other drafts and fix some mistakes. This is the version that will be discussed on Wednesday. Sorry about the short notice. Regards Brian Carpenter On 17/07/2017 16:13, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Technical Objective Formats for the Autonomic Network Infrastructure > Authors : Brian Carpenter > Bing Liu > Filename : draft-carpenter-anima-ani-objectives-03.txt > Pages : 10 > Date : 2017-07-16 > > Abstract: > This document defines the formats of several technical objectives for > the Generic Autonomic Signaling Protocol (GRASP) used by components > of the Autonomic Networking Infrastructure outlined in the ANIMA > reference model. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-ani-objectives/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-03 > https://datatracker.ietf.org/doc/html/draft-carpenter-anima-ani-objectives-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-ani-objectives-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 Sun Jul 16 23:34:12 2017 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 E83D8130154 for ; Sun, 16 Jul 2017 23:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A9Xu1iinm3nY for ; Sun, 16 Jul 2017 23:34:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617DF12ECF0 for ; Sun, 16 Jul 2017 23:34:09 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-8110.meeting.ietf.org [31.133.129.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 8BBEA1F8F5; Mon, 17 Jul 2017 06:34:07 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 9F45C2C0D; Mon, 17 Jul 2017 08:34:01 +0200 (CEST) From: Michael Richardson To: Toerless Eckert cc: Brian E Carpenter , Anima WG In-reply-to: <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Sun, 16 Jul 2017 20:27:49 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 17 Jul 2017 08:34:01 +0200 Message-ID: <23694.1500273241@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 06:34:11 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I thought i had asked that question already but not sure, and not seen > an answer: - I have never seen that a device has more than one > link-local addr on an interface. Is this permitted by IPv6 arck ? Can > you configure this in eg: Linux. I thought i tried on linux/cisco-ios > in the past and i do not quite remember, but i think it failed (only > one address). dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0 dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 08:11:96:01:81:e0 inet addr:31.133.129.16 Bcast:31.133.143.255 Mask:255.255.240.0 inet6 addr: fe80::1234/64 Scope:Link inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0 3: wlan0: mtu 1500 state UP qlen 1000 inet6 fe80::1234/64 scope link valid_lft forever preferred_lft forever inet6 fe80::a11:96ff:fe01:81e0/64 scope link valid_lft forever preferred_lft forever -- ] 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----- Version: GnuPG v1 iQEcBAEBAgAGBQJZbFpZAAoJEJVM4Vb9/EKQhI4H+wanB3XdFEqurpoufvYnf7nj rfHTUFiQg+NT/JdzomHQVZvo11Awg403qkkOtR+yZq6Wvu9RM/5xw9mTUKm5Byba V3KBWq1NOM9kZHpmwLB8PGqO+eInMJGXwTkqUI//QNO1/GKkcVDrPoEcA1gDrwVs uY1hxhz7reQiEbECgj2Vu8qHDKj3bjy/SqJMSG0RH7xctRq6Sw0mza6X0qepkLwU 62w7o7WDyUX1x267RPhU7UH6jjPmnkYs0GHzPFqjB8ERtdrqJb9jJP3/TNC6E7T/ prGBdd8M4g/S+OifywIkdGSdCZok+LPVb2oshCtOzJ6dR9kt0sdRK589M9auZA8= =fKY/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 16 23:54:54 2017 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 43297131690 for ; Sun, 16 Jul 2017 23:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe41POm2psNT for ; Sun, 16 Jul 2017 23:54:51 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB781315FE for ; Sun, 16 Jul 2017 23:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6918; q=dns/txt; s=iport; t=1500274491; x=1501484091; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=8Q44rTXbGn5mHCkMfe+60gkqZ2uIoot5XAx1DRKBFpg=; b=WHvCJVBdF86VObAlDHQEkYxLGBhmyHRKc+afBHOV/e83/sWKY9i7Tosw s1853CKX4DmOezFB9B9Myj5swYYMkulrgXq6PGFKkPUTD+hVq0kqxUiAq zuVGnFJw6rcwxszKTpfGcKJtPwiR+EbhZJVcdUU7+ZrdFfZcC0JfhKUvm U=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAADDXWxZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD6BFI4Lc5BskFiFLIIRBxoBCoFggzsChDMYAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?BAQMBASFLCxALBA4GKgICJyIOBgEMBgIBAYorEK5YgiYnimwBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEOD4MohS4rgnmHfYJhBYlViGGMfoQsgh2NTYsuhwGVVx84gQo?= =?us-ascii?q?xIQgbFUmHGD42iQwBAQE?= X-IronPort-AV: E=Sophos;i="5.40,373,1496102400"; d="asc'?scan'208,217";a="654315208" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 06:54:46 +0000 Received: from [10.61.216.24] ([10.61.216.24]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6H6sjal026587; Mon, 17 Jul 2017 06:54:46 GMT To: Michael Richardson , Toerless Eckert Cc: Anima WG References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> From: Eliot Lear Message-ID: Date: Mon, 17 Jul 2017 08:54:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <23694.1500273241@dooku.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i3jtx3pCXnX4FlMPbDB3IECbopiIrWlau" Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 06:54:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i3jtx3pCXnX4FlMPbDB3IECbopiIrWlau Content-Type: multipart/mixed; boundary="jHB6qs9H8cvl7ecSD8cMX50KtDqlnW6DE"; protected-headers="v1" From: Eliot Lear To: Michael Richardson , Toerless Eckert Cc: Anima WG Message-ID: Subject: Re: [Anima] Is this how BRSKI/IPIP works? References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> In-Reply-To: <23694.1500273241@dooku.sandelman.ca> --jHB6qs9H8cvl7ecSD8cMX50KtDqlnW6DE Content-Type: multipart/alternative; boundary="------------12F9ABF546E65B29456A31D9" Content-Language: en-US This is a multi-part message in MIME format. --------------12F9ABF546E65B29456A31D9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the other hand, maybe it's fundamental, but is relying on LL in this architecture to go beyond LL boundaries the right thing to do? On 7/17/17 8:34 AM, Michael Richardson wrote: > Toerless Eckert wrote: > > I thought i had asked that question already but not sure, and not= seen > > an answer: - I have never seen that a device has more than one > > link-local addr on an interface. Is this permitted by IPv6 arck = ? Can > > you configure this in eg: Linux. I thought i tried on linux/cisco= -ios > > in the past and i do not quite remember, but i think it failed (o= nly > > one address). > > dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0= > > dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0 > wlan0 Link encap:Ethernet HWaddr 08:11:96:01:81:e0 > inet addr:31.133.129.16 Bcast:31.133.143.255 Mask:255.255.2= 40.0 > inet6 addr: fe80::1234/64 Scope:Link > inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0 > 3: wlan0: mtu 1500 state UP qlen 1000= > inet6 fe80::1234/64 scope link > valid_lft forever preferred_lft forever > inet6 fe80::a11:96ff:fe01:81e0/64 scope link > valid_lft forever preferred_lft forever > > > -- > ] Never tell me the odds! | ipv6 mesh net= works [ > ] Michael Richardson, Sandelman Software Works | network archi= tect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ > > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------12F9ABF546E65B29456A31D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On the other hand, maybe it's fundamental, but is relying on LL in this architecture to go beyond LL boundaries the right thing to do?


On 7/17/17 8:34 AM, Michael Richardson= wrote:
Toerless Eckert <tte@cs.fau.de> wrote:
    > I thought i had asked that question already but not sure, and no=
t seen
    > an answer: - I have never seen that a device has more than one
    > link-local addr on an interface.  Is this permitted by IPv6 arck=
 ? Can
    > you configure this in eg: Linux. I thought i tried on linux/cisc=
o-ios
    > in the past and i do not quite remember, but i think it failed (=
only
    > one address).

dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0

dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 08:11:96:01:81:e0
          inet addr:31.133.129.16  Bcast:31.133.143.255  Mask:255.255.240=
=2E0
          inet6 addr: fe80::1234/64 Scope:Link
          inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen =
1000
    inet6 fe80::1234/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::a11:96ff:fe01:81e0/64 scope link
       valid_lft forever preferred_lft forever


--
]               Never tell me the odds!                 | ipv6 mesh netwo=
rks [
]   Michael Richardson, Sandelman Software Works        | network archite=
ct  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rai=
ls    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software =
Works
 -=3D IPv6 IoT consulting =3D-






_______________________________________________
Anima mailing list
Anim=
a@ietf.org
https://www.ietf.org/mailman/listinfo/anima

--------------12F9ABF546E65B29456A31D9-- --jHB6qs9H8cvl7ecSD8cMX50KtDqlnW6DE-- --i3jtx3pCXnX4FlMPbDB3IECbopiIrWlau Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZbF82AAoJEIe2a0bZ0nozvhQH/1M0rad702AZJFY8pUIiV69J Aoh1xNNZ4ds9n18EiZ3GIzHznXa1Q86jYJmJKUJnLSq40S5U+ldvcHghyZlECxv4 2k3PfclZ/1jzoFhNNNB2LNsjSfxgWuWlo8VrJiJ54GYWiNPXKhVk6DgytoNKF5qg 6dtFJKAmUxoqULODLg72wpBjsN+jfatzD08foRVJHQp5aXyYDLMWsuRX5kjRy2Cw 9gCnsdtjEHl3/ukoQ6SrTPy1O8P7UyYhEkM05fHlt4Xcby5pT7HwQDVcsVjvd+Py JJhCAGCYkQttWRx8bTRjLZuIPyLuf8LIV+F1Q2SJ3IgrwY6fkKYXCuOrCUH6nu0= =AT4t -----END PGP SIGNATURE----- --i3jtx3pCXnX4FlMPbDB3IECbopiIrWlau-- From nobody Mon Jul 17 00:28:13 2017 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 7C629131950 for ; Mon, 17 Jul 2017 00:28:11 -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 MPUC_tXjdMDo for ; Mon, 17 Jul 2017 00:28:09 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 91B40131945 for ; Mon, 17 Jul 2017 00:28:09 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id z1so3420583pgs.0 for ; Mon, 17 Jul 2017 00:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+2UMIHiFmxZhrCJAPMUjLe+Yz3qTFtaWzUmhwyv1g1g=; b=VDUtsVeWmmU7h3SfBqfh3QpmpWeCZVd7i4HfQScSntviS1Zwf/FB058uUh/TjxWizK JPu9Nc1cGCJ3rM79oJbTE9cfZhmPHHPZ3uUo8co/17BNPuTdaDMwEM7U35p0oijWHPY4 dH0uMkGnT3ukl9LbjaxkCVZH1hmGS9el2P39xokpiYO0YTUTj77MgqAwOX7FYqaTxo0f Y9crQYmu0uJO3MDUXN3MxhRkpaZBct/R3hnnek+JSRUX2FGFU3s0e9oCh/3BKE6YpFcd t6DiOl+5xdNVG731d+5jOsNSV3PTIns2Rsozt3rCoj5A5AgX6pO1mDA5d9p90obo7ZK7 T9Ug== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+2UMIHiFmxZhrCJAPMUjLe+Yz3qTFtaWzUmhwyv1g1g=; b=DWX7jweCK6KkE2b2xt/w6v7xjrHvAGT6B8eKgYfch511/xASQ/Ot0ULK9OgD7KsuRX PcY4QxvO47WMIpEE+w0Qoiyid8AzR1wIOZiTesDLtrFz+N1Ak+Dh4H35GRI5hf77fmSN bVJ2D47dOhxSATfFLpAoOtEfaK4XMgTUgVCNPCy0Xbkf/zxZk5A1Qm5xtveOImuMyUL8 Y7d7wCf8kSEY2mvHp1aNDdRTpaoC2MqxHmzAlKTk0LgNWsbO4l9nPspSyQk7tZ/L6ggh tH7VlwFMQ5NGdvVXbj9ZZXuuJej11ANpPlsIQpkwgAEg6RvRPRap2lSICAF6m1vBJsRg vBIA== X-Gm-Message-State: AIVw111nHHRmBld/YKia7agdQ65ThSUotR8KBRWCGzS90/iMaPknLjTY JMZEwMZaHR1d/grs X-Received: by 10.99.127.76 with SMTP id p12mr28159664pgn.258.1500276488945; Mon, 17 Jul 2017 00:28:08 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t70sm34695788pfk.111.2017.07.17.00.28.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 00:28:08 -0700 (PDT) To: anima@ietf.org References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <740964ef-82ec-fc37-bd6f-fc98920deedf@gmail.com> Date: Mon, 17 Jul 2017 19:28:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:28:11 -0000 On 17/07/2017 18:54, Eliot Lear wrote: > On the other hand, maybe it's fundamental, but is relying on LL in this > architecture to go beyond LL boundaries the right thing to do? What it would do is prolong the link, virtually, up to a dedicated virtual interface in the registrar. So I think it's safe, if unconventional. Brian > > > On 7/17/17 8:34 AM, Michael Richardson wrote: >> Toerless Eckert wrote: >> > I thought i had asked that question already but not sure, and not seen >> > an answer: - I have never seen that a device has more than one >> > link-local addr on an interface. Is this permitted by IPv6 arck ? Can >> > you configure this in eg: Linux. I thought i tried on linux/cisco-ios >> > in the past and i do not quite remember, but i think it failed (only >> > one address). >> >> dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0 >> >> dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0 >> wlan0 Link encap:Ethernet HWaddr 08:11:96:01:81:e0 >> inet addr:31.133.129.16 Bcast:31.133.143.255 Mask:255.255.240.0 >> inet6 addr: fe80::1234/64 Scope:Link >> inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> >> dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0 >> 3: wlan0: mtu 1500 state UP qlen 1000 >> inet6 fe80::1234/64 scope link >> valid_lft forever preferred_lft forever >> inet6 fe80::a11:96ff:fe01:81e0/64 scope link >> valid_lft forever preferred_lft forever >> >> >> -- >> ] 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 > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 17 00:39:07 2017 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 DEF68131A63 for ; Mon, 17 Jul 2017 00:39:05 -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, RP_MATCHES_RCVD=-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 WDh6pPTqRpqU for ; Mon, 17 Jul 2017 00:39:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911E6131945 for ; Mon, 17 Jul 2017 00:39:03 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7AEF758C4B5; Mon, 17 Jul 2017 09:38:59 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 42A92B0C5E9; Mon, 17 Jul 2017 09:38:59 +0200 (CEST) Date: Mon, 17 Jul 2017 09:38:59 +0200 From: Toerless Eckert To: Eliot Lear Cc: Michael Richardson , Anima WG Message-ID: <20170717073859.GD23525@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:39:06 -0000 Can you propose a stateless proxy model that would not pass the link-local addresses on to the registrar and that uses Michaels beloved IPinIP encap ? Alas i have fallen in love with UDP encap because i like to see more networking software now be build like any othrer application on top of UDP/TCP APIs and not mess around with OS kernel features, so all my answers would be "the proxy is an app that either statefully proxies TCP or stateless proxies UDP". If you want to statelessly proxy TCP and on the registrar use some existing TCP stack, then i would begrudgingly agree with Michael, that i also need some kerne level handling of the encap so that i get kernel level TCP. I am still waiting for some better explanation from Michael about the "Linux kernel and overlapping TCP" to fully understand his proposal. So, here is one proposal for IPinIP using the current -07 draft ULA addressing: A) We assign one of the 8 (3 bit) "T"ype codes to "Subnet Identifier for Encap". B) The proxy allocates a separate "Zone" number for every subnet. Zone = Subnet. In result it now has for every subnet a separate ULA address for the IPinIP encap. C) The registrar announces its ability to support IPinIP BRSKI via GRASP D) Each ACP device need to use its ACP DeviceID also as the host-part of its link-local address. E) The proxy as part of its tunnel functionality also assigns itself the Registrar link local address on every subnet. At least logically. Whether it really needs to do this physcially is implementation specific. F) The proxy announces via GRASP BRSKI-IPIP with the Registrar Link-Local address (which it can do because according to E) it owns it on its subnets - GRASP DULL does not permit third-party announcements, so E) is to make it legal for the proxy to announce this in GRASP). G) Any packets sent by pledges to the Registrar link-local address are IPinIP encapsulated using the "Subnet Identifier for Encap" as the source IP address and the Registrar ULA as the destination address. H) The registrar can create a separate IPinIP tunnel per remote proxy, per-subnet-on-proxy. It does not need further addresses. Some more details might be needed, eg: - If a proxy has more than 2^13 interfaces it needs to dynamically allocate subnet encap addresses. - A proxy might want to map different subnets to differen registrars for load balancing. Cheers Toerless On Mon, Jul 17, 2017 at 08:54:46AM +0200, Eliot Lear wrote: > On the other hand, maybe it's fundamental, but is relying on LL in this > architecture to go beyond LL boundaries the right thing to do? > > > On 7/17/17 8:34 AM, Michael Richardson wrote: > > Toerless Eckert wrote: > > > I thought i had asked that question already but not sure, and not seen > > > an answer: - I have never seen that a device has more than one > > > link-local addr on an interface. Is this permitted by IPv6 arck ? Can > > > you configure this in eg: Linux. I thought i tried on linux/cisco-ios > > > in the past and i do not quite remember, but i think it failed (only > > > one address). > > > > dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0 > > > > dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0 > > wlan0 Link encap:Ethernet HWaddr 08:11:96:01:81:e0 > > inet addr:31.133.129.16 Bcast:31.133.143.255 Mask:255.255.240.0 > > inet6 addr: fe80::1234/64 Scope:Link > > inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > > > dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0 > > 3: wlan0: mtu 1500 state UP qlen 1000 > > inet6 fe80::1234/64 scope link > > valid_lft forever preferred_lft forever > > inet6 fe80::a11:96ff:fe01:81e0/64 scope link > > valid_lft forever preferred_lft forever > > > > > > -- > > ] 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 > -- --- tte@cs.fau.de From nobody Mon Jul 17 00:41:48 2017 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 34A1A131A81 for ; Mon, 17 Jul 2017 00:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiWTcAfRexbC for ; Mon, 17 Jul 2017 00:41:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5ECD131945 for ; Mon, 17 Jul 2017 00:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5017; q=dns/txt; s=iport; t=1500277302; x=1501486902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KWQxxIpngaMD5/nsQsJljmhO+iZCEfJS7IcJvF5qxec=; b=ZS/1uvXX+Qay4kIqEDpPqChQDuR+3cYehf/xQ030VQQz55SRaKUw8hOR 8x6iYM4l3TYFuOWcnX87BFmnEeAsNSdP1/0MQLMOutU+ziH6ChwSC9IIP pMc/4w89Y77GzLqA9mf0h+vBQ75xGyvBneponIeBInDqF5A3o4nwExbyI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAQB/aWxZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg0EIEWSBFI4LkV+QU4UxghEhC4FggzsCg3Y/GAECAQEBAQEBAWs?= =?us-ascii?q?ohREHAQEBAQIBAQE4NAsFCwIBCA4EBh4QJwsXDgIEDgWFSQeEVwgQsH+LEwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DKINNgWErgnmEaoNDgjEFiF14iGGMfgKUFJI?= =?us-ascii?q?vlVYBHziBCnUVSRIBhwN2iQwBAQE?= X-IronPort-AV: E=Sophos;i="5.40,374,1496102400"; d="scan'208";a="273876194" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 07:41:41 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6H7ffss022432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2017 07:41:41 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 02:41:40 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Mon, 17 Jul 2017 02:41:41 -0500 From: "Eliot Lear (elear)" To: Toerless Eckert CC: Eliot Lear , Michael Richardson , Anima WG Thread-Topic: [Anima] Is this how BRSKI/IPIP works? Thread-Index: AQHS/sa3hXYPyKDfSk2Y9mtBFL5KYKJX6WoAgAAMW4D//6zvZw== Date: Mon, 17 Jul 2017 07:41:40 +0000 Message-ID: <7B3FD2E7-D0B8-4F7F-A583-D125ECA2F70E@cisco.com> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> , <20170717073859.GD23525@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170717073859.GD23525@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:41:47 -0000 Sure. Use normal unicast addresses (ULA or other) if available.=20 Eliot > On Jul 17, 2017, at 9:39 AM, Toerless Eckert wrote: >=20 > Can you propose a stateless proxy model that would not pass the link-loca= l > addresses on to the registrar and that uses Michaels beloved IPinIP encap= ? >=20 > Alas i have fallen in love with UDP encap because i like to see more > networking software now be build like any othrer application on top of > UDP/TCP APIs and not mess around with OS kernel features, so all > my answers would be "the proxy is an app that either statefully proxies T= CP > or stateless proxies UDP". >=20 > If you want to statelessly proxy TCP and on the registrar use some existi= ng=20 > TCP stack, then i would begrudgingly agree with Michael, that i also need= some > kerne level handling of the encap so that i get kernel level TCP. >=20 > I am still waiting for some better explanation from Michael about the > "Linux kernel and overlapping TCP" to fully understand his proposal. >=20 > So, here is one proposal for IPinIP using the current -07 draft ULA addre= ssing: >=20 > A) We assign one of the 8 (3 bit) "T"ype codes to "Subnet Identifier for = Encap". >=20 > B) The proxy allocates a separate "Zone" number for every subnet. Zone = =3D Subnet. > In result it now has for every subnet a separate ULA address for the I= PinIP encap. >=20 > C) The registrar announces its ability to support IPinIP BRSKI via GRASP >=20 > D) Each ACP device need to use its ACP DeviceID also as the host-part of = its > link-local address. >=20 > E) The proxy as part of its tunnel functionality also assigns itself the = Registrar > link local address on every subnet. At least logically. Whether it rea= lly needs > to do this physcially is implementation specific. >=20 > F) The proxy announces via GRASP BRSKI-IPIP with the Registrar Link-Local= address > (which it can do because according to E) it owns it on its subnets - G= RASP > DULL does not permit third-party announcements, so E) is to make it l= egal for > the proxy to announce this in GRASP). >=20 > G) Any packets sent by pledges to the Registrar link-local address are IP= inIP > encapsulated using the "Subnet Identifier for Encap" as the source IP = address and > the Registrar ULA as the destination address. >=20 > H) The registrar can create a separate IPinIP tunnel per remote proxy, pe= r-subnet-on-proxy. > It does not need further addresses. >=20 > Some more details might be needed, eg: > - If a proxy has more than 2^13 interfaces it needs to dynamically alloca= te > subnet encap addresses. > - A proxy might want to map different subnets to differen registrars for = load balancing. >=20 > Cheers > Toerless >=20 >> On Mon, Jul 17, 2017 at 08:54:46AM +0200, Eliot Lear wrote: >> On the other hand, maybe it's fundamental, but is relying on LL in this >> architecture to go beyond LL boundaries the right thing to do? >>=20 >>=20 >>> On 7/17/17 8:34 AM, Michael Richardson wrote: >>> Toerless Eckert wrote: >>>> I thought i had asked that question already but not sure, and not seen >>>> an answer: - I have never seen that a device has more than one >>>> link-local addr on an interface. Is this permitted by IPv6 arck ? Can >>>> you configure this in eg: Linux. I thought i tried on linux/cisco-ios >>>> in the past and i do not quite remember, but i think it failed (only >>>> one address). >>>=20 >>> dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0 >>>=20 >>> dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0 >>> wlan0 Link encap:Ethernet HWaddr 08:11:96:01:81:e0 >>> inet addr:31.133.129.16 Bcast:31.133.143.255 Mask:255.255.24= 0.0 >>> inet6 addr: fe80::1234/64 Scope:Link >>> inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>=20 >>> dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0 >>> 3: wlan0: mtu 1500 state UP qlen 1000 >>> inet6 fe80::1234/64 scope link >>> valid_lft forever preferred_lft forever >>> inet6 fe80::a11:96ff:fe01:81e0/64 scope link >>> valid_lft forever preferred_lft forever >>>=20 >>>=20 >>> -- >>> ] Never tell me the odds! | ipv6 mesh net= works [ >>> ] Michael Richardson, Sandelman Software Works | network archi= tect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ >>>=20 >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 >=20 >=20 >=20 > --=20 > --- > tte@cs.fau.de From nobody Mon Jul 17 01:02:21 2017 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 D9DEE131A63 for ; Mon, 17 Jul 2017 01:02:19 -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, RP_MATCHES_RCVD=-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 jziu0hNsaP3g for ; Mon, 17 Jul 2017 01:02:18 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12348131A55 for ; Mon, 17 Jul 2017 01:02:18 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1174F58C4B5; Mon, 17 Jul 2017 10:02:14 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D0C4AB0C5EA; Mon, 17 Jul 2017 10:02:13 +0200 (CEST) Date: Mon, 17 Jul 2017 10:02:13 +0200 From: Toerless Eckert To: "Eliot Lear (elear)" Cc: Eliot Lear , Michael Richardson , Anima WG Message-ID: <20170717080213.GE23525@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> <20170717073859.GD23525@faui40p.informatik.uni-erlangen.de> <7B3FD2E7-D0B8-4F7F-A583-D125ECA2F70E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7B3FD2E7-D0B8-4F7F-A583-D125ECA2F70E@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:02:20 -0000 Remember that the pledge can only have a link-local address during bootstrap, so i would not know how to interpret your comment. Cheers Toerless On Mon, Jul 17, 2017 at 07:41:40AM +0000, Eliot Lear (elear) wrote: > Sure. Use normal unicast addresses (ULA or other) if available. > > Eliot > > > On Jul 17, 2017, at 9:39 AM, Toerless Eckert wrote: > > > > Can you propose a stateless proxy model that would not pass the link-local > > addresses on to the registrar and that uses Michaels beloved IPinIP encap ? > > > > Alas i have fallen in love with UDP encap because i like to see more > > networking software now be build like any othrer application on top of > > UDP/TCP APIs and not mess around with OS kernel features, so all > > my answers would be "the proxy is an app that either statefully proxies TCP > > or stateless proxies UDP". > > > > If you want to statelessly proxy TCP and on the registrar use some existing > > TCP stack, then i would begrudgingly agree with Michael, that i also need some > > kerne level handling of the encap so that i get kernel level TCP. > > > > I am still waiting for some better explanation from Michael about the > > "Linux kernel and overlapping TCP" to fully understand his proposal. > > > > So, here is one proposal for IPinIP using the current -07 draft ULA addressing: > > > > A) We assign one of the 8 (3 bit) "T"ype codes to "Subnet Identifier for Encap". > > > > B) The proxy allocates a separate "Zone" number for every subnet. Zone = Subnet. > > In result it now has for every subnet a separate ULA address for the IPinIP encap. > > > > C) The registrar announces its ability to support IPinIP BRSKI via GRASP > > > > D) Each ACP device need to use its ACP DeviceID also as the host-part of its > > link-local address. > > > > E) The proxy as part of its tunnel functionality also assigns itself the Registrar > > link local address on every subnet. At least logically. Whether it really needs > > to do this physcially is implementation specific. > > > > F) The proxy announces via GRASP BRSKI-IPIP with the Registrar Link-Local address > > (which it can do because according to E) it owns it on its subnets - GRASP > > DULL does not permit third-party announcements, so E) is to make it legal for > > the proxy to announce this in GRASP). > > > > G) Any packets sent by pledges to the Registrar link-local address are IPinIP > > encapsulated using the "Subnet Identifier for Encap" as the source IP address and > > the Registrar ULA as the destination address. > > > > H) The registrar can create a separate IPinIP tunnel per remote proxy, per-subnet-on-proxy. > > It does not need further addresses. > > > > Some more details might be needed, eg: > > - If a proxy has more than 2^13 interfaces it needs to dynamically allocate > > subnet encap addresses. > > - A proxy might want to map different subnets to differen registrars for load balancing. > > > > Cheers > > Toerless > > > >> On Mon, Jul 17, 2017 at 08:54:46AM +0200, Eliot Lear wrote: > >> On the other hand, maybe it's fundamental, but is relying on LL in this > >> architecture to go beyond LL boundaries the right thing to do? > >> > >> > >>> On 7/17/17 8:34 AM, Michael Richardson wrote: > >>> Toerless Eckert wrote: > >>>> I thought i had asked that question already but not sure, and not seen > >>>> an answer: - I have never seen that a device has more than one > >>>> link-local addr on an interface. Is this permitted by IPv6 arck ? Can > >>>> you configure this in eg: Linux. I thought i tried on linux/cisco-ios > >>>> in the past and i do not quite remember, but i think it failed (only > >>>> one address). > >>> > >>> dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0 > >>> > >>> dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0 > >>> wlan0 Link encap:Ethernet HWaddr 08:11:96:01:81:e0 > >>> inet addr:31.133.129.16 Bcast:31.133.143.255 Mask:255.255.240.0 > >>> inet6 addr: fe80::1234/64 Scope:Link > >>> inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link > >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >>> > >>> dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0 > >>> 3: wlan0: mtu 1500 state UP qlen 1000 > >>> inet6 fe80::1234/64 scope link > >>> valid_lft forever preferred_lft forever > >>> inet6 fe80::a11:96ff:fe01:81e0/64 scope link > >>> valid_lft forever preferred_lft forever > >>> > >>> > >>> -- > >>> ] 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 > >> > > > > > > > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Mon Jul 17 01:55:52 2017 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 25B2712EC36 for ; Mon, 17 Jul 2017 01:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yab5cxUjL7S7 for ; Mon, 17 Jul 2017 01:55:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5167812EA7C for ; Mon, 17 Jul 2017 01:55:47 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-8110.meeting.ietf.org [31.133.129.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 28E911F8F5; Mon, 17 Jul 2017 08:55:46 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 56245598; Mon, 17 Jul 2017 10:55:40 +0200 (CEST) From: Michael Richardson To: Eliot Lear cc: Toerless Eckert , Anima WG In-reply-to: References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> Comments: In-reply-to Eliot Lear message dated "Mon, 17 Jul 2017 08:54:46 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 17 Jul 2017 10:55:40 +0200 Message-ID: <11013.1500281740@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:55:48 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: > On the other hand, maybe it's fundamental, but is relying on LL in this > architecture to go beyond LL boundaries the right thing to do? We've already established a way around the concern that made me think that we needed multiple LL for the proxy, and also that we needed multiple Ar for the proxy connection. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZbHuMAAoJEJVM4Vb9/EKQeTsH/i0BA0XLdilMYismAxKnyZAi jNqLdMlhif1FGX7YqyvC4uaI+BCzzr3n79bSYf6ekr5kIazxInXiEyf0AkJ1Lfc7 ch3dMXNxNQ2hnn1kGx3VC7S8STNqy8h1aDqOxBvVY8edzLEoqZhpg+DRV7qFuw/f ntz4+9GCnRyyPYEbn8G6LzSit7M/aI+JrCSRH6tXXCndDTaD6eJqaeVjyZg/oNJe ry41U9Jj01RpSrCHO69PCB0Ba65JSDcMN32Q0NJTBDShdM0yIY8CqIktj4ZrHPpD gvUWGQGjtemGkgopLE/tkW9Qb699ogfv0RYcmxpn4LylyeY8ZGnoNblec9TdxOc= =e6fh -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 17 09:32:45 2017 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 DD831131CAC for ; Mon, 17 Jul 2017 09:32:42 -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, RP_MATCHES_RCVD=-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 CF-aTSI4JrWJ for ; Mon, 17 Jul 2017 09:32:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5B2131CAA for ; Mon, 17 Jul 2017 09:32:40 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C222258C4CB; Mon, 17 Jul 2017 18:32:36 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 91251B0C5EF; Mon, 17 Jul 2017 18:32:36 +0200 (CEST) Date: Mon, 17 Jul 2017 18:32:36 +0200 From: Toerless Eckert To: Michael Richardson Cc: Eliot Lear , Anima WG Message-ID: <20170717163236.GA30196@faui40p.informatik.uni-erlangen.de> References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> <11013.1500281740@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11013.1500281740@dooku.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:32:43 -0000 I think.... *righ*... eg: The only clean way with IPinIP is that every proxies subnet can be distinguished on a registrar by the encapsulation header of IPinIP and that only has source and destination ACP ULA addresses, yada yada: we need either more ULA on the proxy and/or the registrar. I guess we do not want any on-demand actions on the proxy because that would be a dynamic state establishment that we try to avoid, so the proxy would need to set up all the state needed upfront which means it needs one IPinIP tunnel per subinterface, just at the off-chance that some pledges have the same address. So then we look at the total address waste and obviously we may have 1000 pledges but 1 or few registrars, so it definitely would make most sense to get these addresses on the registrar, announce via GRASP and let pleges build tunnels with them. And the registrars would dynamically build these tunnels based on (Src,Dst) encap headers received, and hopefully somebody comes up with a better way for linux to do this than loosing the first packet which seems to be what Michael is running into. And given how the tunnels ultimately are built only on a (per-proxy,interface) basis there is also not a direct attack vector against dynamic creation based on nasty pledges. So, i am warming up more to this ;-) Cheers Toerless On Mon, Jul 17, 2017 at 10:55:40AM +0200, Michael Richardson wrote: > > Eliot Lear wrote: > > On the other hand, maybe it's fundamental, but is relying on LL in this > > architecture to go beyond LL boundaries the right thing to do? > > We've already established a way around the concern that made me think > that we needed multiple LL for the proxy, and also that we needed multiple > Ar for the proxy connection. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- tte@cs.fau.de From nobody Tue Jul 18 05:31:17 2017 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 34C0F131748; Tue, 18 Jul 2017 05:31:16 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 1F_t7IobeliM; Tue, 18 Jul 2017 05:31:11 -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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85189131DE3; Tue, 18 Jul 2017 05:31:10 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 99F3458C4AF; Tue, 18 Jul 2017 14:31:06 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5494BB0C5F6; Tue, 18 Jul 2017 14:31:06 +0200 (CEST) Date: Tue, 18 Jul 2017 14:31:06 +0200 From: Toerless Eckert To: anima@ietf.org Cc: draft-ietf-anima-prefix-management@ietf.org Message-ID: <20170718123106.GA30100@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] Result of WGLC on WG Last Call on draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 12:31:16 -0000 We received no negative response to the WGLC on draft-ietf-anima-prefix-management. We had good reviews through the WG document stage, and IMHO good final changes through the shepherd review process, where also contentuous elements where removed. This resulted in the current draft-ietf-anima-prefix-management-04. Mohamed informed us about possible IPR and he gratiously got IPR disclosure for it which i reviewed and found to be not prohibiting us to proceed with the document, but if you have not seen this in before, please also check this: https://datatracker.ietf.org/ipr/3027/ Note that this disclosure would also apply for non-standard implementation of this work (which IMHO is good), and note that draft-ietf-anima-prefix-management is intended to be informational (not standards track), primarily because it is according to our charter meant as a concept validation of the core ANIMA charter items of the ANI (ACP, BRSKI, GRASP) but not a complete interoperable protocol specification. In other word i think actual IPR related concerns would rather come into any followup work that would try to refine the work towards such a standards track specification. With this all said, i think that the document has passed WGLC and should advance. I will finalize the shepherd document and send the document on. Best regards, Toerless (with great administrative help by Sheng who as a co-author stayed totally neutral on the content side ;-) On Tue, Jun 27, 2017 at 06:44:13AM +0200, Toerless Eckert wrote: > Dear ANIMA WG, > > After thorough review and discussions on the mailing list leading to the -04 > version posted last week i think the draft is now mature enough for working > group last call. > > This e-mail starts a two-weeks period for evaluation of this document by the WG. > > Please provide your feedback on the ANIMA mailing list by end of July 10th, 2017. > > Thanks, best regards > > Toerless (as ANIMA WG co-chair). > > P.S.: > > +1 -> i support the publishing of this document. From nobody Tue Jul 18 22:16:31 2017 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 9EBCC1274D0; Tue, 18 Jul 2017 22:16:22 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150044138257.25233.12391471568614147773@ietfa.amsl.com> Date: Tue, 18 Jul 2017 22:16:22 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 05:16:23 -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 of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-08.txt Pages : 64 Date : 2017-07-18 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "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 OAM communications over a network that is not configured, or mis-configured. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 19 02:29:16 2017 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 6A5EC131C62; Wed, 19 Jul 2017 02:29:00 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, rfc-editor@rfc-editor.org, Sheng Jiang , terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150045654042.25387.16319321856721426945.idtracker@ietfa.amsl.com> Date: Wed, 19 Jul 2017 02:29:00 -0700 Archived-At: Subject: [Anima] Protocol Action: 'A Generic Autonomic Signaling Protocol (GRASP)' to Proposed Standard (draft-ietf-anima-grasp-15.txt) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:29:01 -0000 The IESG has approved the following document: - 'A Generic Autonomic Signaling Protocol (GRASP)' (draft-ietf-anima-grasp-15.txt) as Proposed Standard This document is the product of the Autonomic Networking Integrated Model and Approach Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ Technical Summary This document describes the requirements for a signaling protocol that enables autonomic devices and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings mutually with them. The document then defines a general protocol for discovery, synchronization and negotiation, which can be suitable for variable technical objectives. The technical objectives for specific scenarios out of scope. Working Group Summary This document was called draft-carpenter-anima-gdn-protocol prior to its adoption. There was unanimous support for it in favor of adoption and none against), so this document was adopted in August 2015. There was interest in this work posts since its adoption. There was never any opposition for this work. This document went through a relevant long document development period (10 months for individual document period, 17 month for WG document period). It has been reviewed well. Document Quality This document went through multiple reviews by multiple WG participants. There are at least two existing implementations. Both Cisco and Huawei showed interests to implement the specification Personnel Sheng Jiang is the document shepherd. Terry Manderson is the responsible AD. IANA Note IANA is asked to assign 2 multicast addresses for ALL_GRASP_NEIGHBOR multicast address (IPv6) and ALL_GRASP_NEIGHBOR multicast address (IPv4); 1 port for both UDP and TCP: GRASP_LISTEN_PORT. IANA is requested to create a GRASP Parameter Registry including two registry tables: the GRASP Messages and Options Table and the GRASP Objective Names Table. In the the GRASP Messages and Options Table, 18 intial values are assigned for M_NOOP, M_DISCOVERY, M_RESPONSE, M_REQ_NEG, M_REQ_SYN, M_NEGOTIATE, M_END, M_WAIT, M_SYNCH, M_FLOOD, M_INVALID, O_DIVERT, O_ACCEPT, O_DECLINE, O_IPv6_LOCATOR, O_IPv4_LOCATOR, O_FQDN_LOCATOR and O_URI_LOCATO. There is no initial value assigned in the GRASP Objective Names Table. From nobody Thu Jul 20 20:57:09 2017 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 6B604129ABE for ; Thu, 20 Jul 2017 20:57:07 -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 J5UFyNJrsruN for ; Thu, 20 Jul 2017 20:57:05 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 BF519129A9C for ; Thu, 20 Jul 2017 20:57:05 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id y129so23110641pgy.4 for ; Thu, 20 Jul 2017 20:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=bmVnrZOd0tX2V72HuzihwUosI39QRrLtMF3DPv8ExVY=; b=qX7QO1skhBx/Mw7aUAj62a7CK2EzY2SiQEkO9dmo5Q7wi4Rfkll/S73IGYSk2dpUAM MZp6nf8GPUL1FtR3RYeh9/wU9qqgSxNTEb0z6M5KsqPK0175s38uDNM+nD9cj4E8gRgr 8AuftYAATU7djKzQKsFQYFdh3CUD9CUr9gt4Lwdiz5NFWTbYpyGqQliRBT1gitUt7REo TG+SlWclgyK5a51vZ+P+hOpIDOZq63HJuIHu7JBka0aMSqdFGK9IpK/s5SU5DcU1qN8C iNLgq9Ad/MHV2HR/zUDyswNU6bd/L129ISvtfCAT9IkV7Vbj5nuznpPbqy3OidSu2Zng m0Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=bmVnrZOd0tX2V72HuzihwUosI39QRrLtMF3DPv8ExVY=; b=CFlWzmOpi7JC/+7/GeGT1e7qd8l6LKC3zWhvXgqbt1pwPlTAZSH/lB8sygxYCv1Ahc M6Du2ov9y6BhdXlbSASPWp09gD53yoQQTaJRAS9sIkeFSQfGZk2ynnD9DtGYyC/WbQMX YmkIpXDRGr+D+F7PAU7XCcYs1DDT1Yr1atJt4aGtV/ctw8Cwh6uchYFBwi9X9lxAnmRq Z6wd1HIzc6urDwW5/xynRLpFUmVfg5+uv1P3A+aV+h9CPB0JjihGOq4Gj0hfj1s4eE03 MsrikXyuRh7oQYP7W5tl0ZglqYVlBsoSznH3Svts2nGWE/lZ9421ZirgNEKJHTHvbJbA nY7A== X-Gm-Message-State: AIVw112lOYFzqp73tQ4Hm0jcHgUfYipKirgB0Co6KEQqe9I2amJOgHsk 6TxtQQJE23slwXzj X-Received: by 10.99.226.83 with SMTP id y19mr5912754pgj.257.1500609425176; Thu, 20 Jul 2017 20:57:05 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.166]) by smtp.gmail.com with ESMTPSA id d24sm6961175pfk.43.2017.07.20.20.57.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 20:57:04 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <0e3ea96b-39f4-e14a-8a3a-6eff2aeb70fb@gmail.com> Date: Fri, 21 Jul 2017 15:57:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP IANA assignments are complete X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 03:57:07 -0000 As usual the IANA people are super efficient. The new registries for GRASP are up at https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml Also the following are now assigned to GRASP: UDP and TCP Port 7107 IPv6 Link-Local multicast ff02::13 IPv6 Link-Local multicast 224.0.0.119 (Before you ask: no, we don't expect GRASP to be much used over an IPv4 substrate, but we didn't want to exclude it, so the address is assigned.) I will shortly push a version of the prototype code with these assignments embedded to https://github.com/becarpenter/graspy Regards Brian From nobody Thu Jul 20 22:17:20 2017 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 D451A12EAAA for ; Thu, 20 Jul 2017 22:17:18 -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 1Qfzbz9jxpum for ; Thu, 20 Jul 2017 22:17:17 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 21C07126C23 for ; Thu, 20 Jul 2017 22:17:17 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id v190so23918435pgv.2 for ; Thu, 20 Jul 2017 22:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=yz+AIHZUEZ/1XsSlqxTLGrXf8FOijONTDOHbQRteSxY=; b=Bwm3jltPyW/M8clfUi62AsbbogtcIDFkFtR41TIREOn6VOR2O6Zpg3vo9hGSkooeRL b2V1nYn9K9IiKRiOoG/HWxGEaSfUWi+Xi27dAKTl4q67mQ2RtDnS9Ovjqigb+0jNoh/I hF/l5yQ3XTNDdT03K+tdz30QagGylswCc8DhMdkKX+0P7zzsAA6angGKTRqHVPXG9wgP zul0r0v6Ilf+Rk9zKCQE57wGpEppRqFpN2lmTwn3DG/nZSoyVipAYxt2J84avhPLKqLu BH+Knd+XPEkFrVEc+6TtnBDYUhOMwN04yIF5N7goJrVgpTL5MSnNy0Kpzfyk0IqaIaUD Ui6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=yz+AIHZUEZ/1XsSlqxTLGrXf8FOijONTDOHbQRteSxY=; b=jKUnTnM8NXKXu+IW15wP21fZZdDisDvwPeZqYj9t8zp/L0NTP6zvjHqmpmo68E6f/J Eu8a4IKBSxrvDl17TPVlUB9kHZzyoIV7kBm3TNg+/Ja7KijoEElSXbyiz7fWh/cI7jZA zDIrDWaGEGRTAIIPn7V7A3bVRwz/lqNPq1/5ABJwDUsW8lWbPYvHZKWuquGOnD+t7Mun 24tZ5JlhvLTQi0D0Vl9YIDoKcyt+zSSlD2CWJcDFvdssI1zjwLTe4Y5wMsQJlBoTBvJx DixEXugAaLf6Jj18dhiL/iGvYsAazacnDv1lvRz89S0t6lgZiTMhZ8hAJ2WPJ5154hgq CLrQ== X-Gm-Message-State: AIVw110LI+QzwWFQjRh4ak6Swj5TbYUFMhmeuRG3hSUO7pqtEYrBK462 uRiW707t8GvhxFze X-Received: by 10.98.31.201 with SMTP id l70mr6406046pfj.128.1500614236530; Thu, 20 Jul 2017 22:17:16 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.166]) by smtp.gmail.com with ESMTPSA id u198sm4426639pgb.3.2017.07.20.22.17.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 22:17:15 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <9fa5abbe-368d-1433-2ea8-f6622fd22573@gmail.com> Date: Fri, 21 Jul 2017 17:17:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] The open issue in draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 05:17:19 -0000 As a reminder, we have two options in the draft for adding support of IPv4 prefix management: 1. Add a version number flag to the objective 2. Add a second objective specific to IPv4 So far the preferences I have heard (including my own) are for option 1, because it's simpler to implement. I think the authors will go that way for the next version, but of course it's a WG choice. Comments please! Quick link: https://tools.ietf.org/html/draft-ietf-anima-prefix-management-04#section-5.2 Regards Brian From nobody Sat Jul 22 17:50:37 2017 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 C60A7131559 for ; Sat, 22 Jul 2017 17:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UXir6egGAtpH for ; Sat, 22 Jul 2017 17:50:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6891201F2 for ; Sat, 22 Jul 2017 17:50:34 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:b:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 49EE81F8F5 for ; Sun, 23 Jul 2017 00:50:32 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8E2DC1B8C; Sun, 23 Jul 2017 02:50:22 +0200 (CEST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 23 Jul 2017 02:50:22 +0200 Message-ID: <32649.1500771022@dooku.sandelman.ca> Archived-At: Subject: [Anima] ACP document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jul 2017 00:50:37 -0000 --=-=-= Content-Type: text/plain I'm reading the -07 version of ACP (because it's been open in a tab all week as I have written this email slowly. I guess that there is an -08 version that I will look at when I've got network again) 5.1.1 says: domain certificate can automatically and securely be derived from a I think the word "derived" is wrong. That implies that there is some kind of mathematical relationship between the certificates. BRSKI permits these ACP certificates to be automatically and securely *deployed*. I think it is reasonable to say that BRSKI is not the only way to deploy those certificates, it's just a zero-touch way. For some reason, I find the uppercase hex in the ULA unpleasant. I'd have made it lower case, but I'm not going to argue this point... There are a wide range of pre-existing protocols/services where authentication with LDevID is desirable. Enrolling and maintaining separate LDevIDs for each of these protocols/services is often undesirable overhead. Therefore it is beneficial if the BRSKI enrolled LDevID can also be used for other protocols/ services beside the ACP. A sec-review is going to ask us to name them. We had better do that. The thing is that many of those protocols will expect to see subjectAltNames with useful things in them: for instance an ipv6Address extension with at least the ula-acp...:1 address is probably a good thing. I'll bet we can point to a few things where this would help directly: 1) SNMP. 2) https:// access [server lights out managers: iDrac, iLO...] 3) ssh (although it's uncommon to use PKIX, it's not unknown. Further, the registrar could populate SSHFP RR into the reverse zone) 4) NETCONF/RESTCONF. 5) some other SDN north interface, (i2rs, etc.) paragraph: Using an IP address format encoding could result in non-benign misinterpretation of the ACP information. protocol/services unaware of the ACP could try to do something with the ACP address that would fail to work correctly (because it is in a different VRF than what they expect), or that could cause security issues. I really think that this is an unsupportable statement. Chickens *could* also fall from the sky, but outside of certain animated movies, that doesn't happen. I'm still unconvinced of the mailbox argument. NOTE: I am *NOT* arguing against rfc822Name, just that the arguments need to make sense. Max: the rfc822Name will need to be included in the CSR. That means that the JRC essentially has to do the ULA assignments! I think that this needs to be captured into BRSKI. 5.2.3: ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"], [O_IPv6_LOCATOR, h'fe80000000000000c0011001FEEF0000, UDP, 15000] In this example, you used port 15000.. "(for the sake of creating the example)" Is there a reason you did not use 500? *IF* we are going to run IKEv2 on a non-standard port (but constant across all ACP nodes), we probably should have a good reason for it. If it was your desire to just announce some random port, the issue that can come up is what happens when a one needs to initiate in the other direction. Does one store the port number from the previous announcements? Does one have to wait for announcement? I'd rather just run on port-500. Bob becomes passive, he does not attempt to further initiate ACP secure channel protocols with Alice and does not consider it to be an error when Alice closes secure channels. Alice becomes the active party, continues to attempt setting up secure channel protocols with Bob until she arrives at the best one (from her view) that also works with Bob. Perhaps this matters to TCP based or DTLS based protocols, but IKEv2 doesn't care about this. assume that neighbors with the same L2 or link-local IPv6 addresses on different L2 interfaces are the ame devices. This can only be determined after examining the certificate after a successful security association attempt. I thought I'd find strong language saying exactly that in https://tools.ietf.org/html/rfc4291#section-2.5.6 that we could reference, but, I don't see such a statement. Maybe it's somewhere else? I think that section 5.5 should include a final paragraph to the effect of: While the rfc822name includes the ACP ULA address, the actual negotiation in each of the protocols will usually be from a Link-Local address of the autonomic node. (Or, in the case of MACsec, from the L2 address) As such, it is not possible to match the rfc822name to the device negotiating in any meaningful way. 5.6.1.1: change: AES256 encryption and SHA256 hash. to: and MUST support the current MUST and SHOULD+ modes specified in draft-ietf-ipsecme-rfc7321bis and draft-ietf-ipsecme-rfc4307bis Signature modes for IKEv2 PARENTs are determined by the algorithms used in the certificates. We haven't said anything about certificate algorithms. I'd like to make EdDSA Curve25519 a SHOULD+. I suspect will have to make ECDSA secp256p1 a MUST, which makes me unhappy. I am okay with having RSA >= 2048 be a MAY. (RSA < 2048 is a SOULD NOT) 6.1 ACP connect ACP connect has *ADDRESSING* issues not covered! It will likely need to issue RAs on the ACP connect interface, so it must be given a /64. In the -07 address plan, I would propose that each ACP connect interface will adopt a zoneID. In some newer plan, we just need to make sure that we can agree on whatever the upper-(64-x) bits are which are not the "base scheme" I propose that we should have a GRASP ANI to allocate zoneIDs (if we keep them) that would be built into any ACP nodes that intend to have ACP connect interfaces. There may well be *two* (or more) ACP nodes on the same ACP connect LAN! That is, two routers on the same subnet. Hardly unusual, it occurs on many networks, including the IETF conference network. For IPv4, you have to run VRRP to make it work, but with IPv6, it just works out of the box. This would typically be architected using IPv4-centric L2-tricks such that NMS equipement that needs to be resilient would have master/slave or load balancing setups in data centers connected via L2 circuits. There would be an ACP connect router at each data center. While we *could* have each of these ACP connect routers allocate their own zoneID (and thus /64), I suspect that we should be recognizing when the two ACP connect routers are on the same LAN (an ACP tunnel will be naturally configured across that L2 fabric). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZc/LOAAoJEJVM4Vb9/EKQGfEIAKQUkmAzVdINaOsqgdeu/qbn JE7ofOKoaV2jRWE5YyPZ57CCyQZkHBNfNJWwODyuMOzufko4VjHI0DH4V5s7wADl CTaMew3eJFmvdJjDOmL0ynBw17APsz0CGk21iNRI5evjgWC9XKD6kSNYuNemv11z PkVD4iZesWZsXp9dSkLsLXxFRZd0lFr0+szczdIwKrqiVT4uBi/Rr6PZeEbVuRbU DgFNkVp3RNmC5deuYgUG5Q14wW9NdggDLnbhYJznn7MCrsOwXbV97wS5nlRA8AHT 4JOGUMLyPzXqz6zVeEKcP1fTtTJTN6rcAY8GaJ95f9lf3sHtEYoTk7sCbQXcPCA= =BmrQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 23 20:00:29 2017 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 E76F61318A2 for ; Sun, 23 Jul 2017 20:00: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 rOlRG7qehM1d for ; Sun, 23 Jul 2017 20:00:25 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF01126B71 for ; Sun, 23 Jul 2017 20:00:25 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id z129so1831736pfb.3 for ; Sun, 23 Jul 2017 20:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:organization:to:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EOHDSY4Y/WsH4iS546ECUqcN6xjxUscRyXDouvqW/So=; b=azA2s9zMuYqQ+jzAWEm/vKLYQubZ751VarLNqh0g+DJicBsPmo4PRkw035GHI62x8N B8318QWIdNTwuBSopBOobjR9LBoYbggshtjPVG4KylOUeuT0no8Oq5UvSwVt5Wxbt0Cx onxwB0HD8NbqdaJyRf9TbV4Sc7MARqHDEOY4PpqtLXRU5x864FNrDYv1tgYCnw/6YkZY 4PfmXoARTF5IRVOteDIsrUYMyp1E6584qj9AJjzffnfHqpO5oTpZDHTMdZx1gAhcNc1q E8InYY3cQ7NDDUN65gl9eh77h0ixP4B+9eGUBHBZmBzSD+ZK7OE9woUQqJjPWRYuZyQL 7DZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:organization:to :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=EOHDSY4Y/WsH4iS546ECUqcN6xjxUscRyXDouvqW/So=; b=qh+4fUfEXOxCpK/JHmobedHFlyT78UuBa5I0e7juDQnYSzZDWArvpZ9s/BG7TA6vXM lQ2YZAJM6S4mBofhQ1jzqgy/CNsM2evtRzZKjit2liTcROVZNO5iip7Nwj5rHHojG+kA dcv5JxhCUaa12tmvTUonZUyUFJwGptGsMFloeTOl4oqsmU7sfVsXsbmQ8Fm96KRTR+Qn 1WaecjtmEGT0+i413x9IwFYKedLrXsqMDm5wK4Xlx2E4RbrwYa8jvI0JXwmrz/g6CyOV 9WhDR0RzncztRnI5A4GC1OFTFo8TyZCQFcv2Bui0qck5TykVNAMJS971N/Y6LGob7wlV F9RA== X-Gm-Message-State: AIVw110rjxVYehIiFFf003gfuqfhJpP6GwefPoXKELJXzPNde/0aHoIX NlFgyUJ3C9N6bj3J X-Received: by 10.84.167.2 with SMTP id c2mr16721038plb.365.1500865224858; Sun, 23 Jul 2017 20:00:24 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n13sm17197576pgs.0.2017.07.23.20.00.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jul 2017 20:00:24 -0700 (PDT) References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> Date: Mon, 24 Jul 2017 15:00:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 03:00:28 -0000 Hi, Here are my comments on this draft. In general it seems to be ready, but there are some issues that IMHO need fixing. Here they are, followed by a few nits that I noticed. Technical issues: ----------------- > 2.1.3. Simultaneous ACP and data plane connectivity ...> If the data-plane of the network is also supporting IPv6, then the > NOC devices that need access to the ACP should have a dual-homing > IPv6 setup. One option is to make the NOC devices multi-homed with > one logical or physical IPv6 interface connecting to the data-plane, > and another into the ACP. I don't understand the need to call this "dual-homing". That generally implies a physical topology with multiple links and/or routers. I think all you mean is that the nodes happen to have at least two addresses in different IPv6 prefixes (one for the data plane and one for the ACP). Having multiple addresses is a standard feature of IPv6. It might be done with multiple (virtual or real) interfaces, but it doesn't need to be. So I suggest: If the data-plane of the network also supports IPv6, then the NOC devices that need access to the ACP should have both data-plane and ACP IPv6 addresses. One option is to set up the NOC devices with one logical or physical IPv6 interface connecting to the data-plane, and another into the ACP. > The LAN that provides access to the ACP > should then be given an IPv6 prefix that shares a common prefix with > the IPv6 ULA... 1) It is surely a virtual interface, not a LAN. 2) I think it is better to say "should then be given an IPv6 prefix that lies within the ULA prefix..." (In fact, it doesn't matter that it's a ULA - what matters is that it's the prefix that covers the whole ACP. That really goes for the whole document; a ULA prefix is just another prefix, after all. It might be clearer to just say "ACP prefix" everywhere.) > ... so that the standard IPv6 > interface selection rules on the NOC host Cite [RFC6724] for complete clarity. > If this can not be achieved > automatically, then it needs to be done via simple IPv6 static routes > in the NOC host. But it can. That's why RFC6724 exists. Do we really need to say this? ... > Providing two virtual (eg: dot1q subnet) connections into NOC hosts > may be seen as undesired complexity. Either you have to explain 'dot1q' and give a reference, or delete it. I'd delete it. ... > In that case the routing policy > to provide access to both ACP and data-plane via IPv6 needs to happen > in the NOC network itself: The NMS host gets a single attachment > interface but still with the same two IPv6 addresses as in before - > one for use towards the ACP, one towards the data-plane. The first- > hop router connecting to the NMS host would then have separate > interfaces: one towards the data-plane, one towards the ACP. Routing > of traffic from NMS hosts would then have to be based on the source > IPv6 address of the host: Traffic from the address designated for ACP > use would get routed towards the ACP, traffic from the designated > data-plane address towards the data-plane. That seems like an explanation of very basic routing - does it need to be said? > In the most simple case, we get the following topology:... This part isn't very clear to follow. The ASCII art of Fig. 1 and Fig. 2 is a bit scrappy, and the explanation is a bit short. It would be better to start with an explanation of the terms like 'NOClan' and 'Rtr1'. And you suddenly start discssing VRFs without any definition. > 2.1.4. IPv4 only NMS hosts ... > The downside of this architectural decision is the potential need for > short-term workarounds when the operational practices in a network > that can not meet these target expectations. This section motivates > when and why these workarounds may be necessary and describes them. > All the workarounds described in this section are HIGHLY UNDESIRABLE. > The only long term solution is to enable IPv6 on NMS hosts. I full agree with the message but I think the wording has the wrong tone. The goal should be to welcome NOCs to the new world of IPv6, not to tell them they are dinosaurs. Something like: The implication of this architectural decision is the potential need for short-term workarounds when the operational practices in a network do not yet meet these target expectations. This section explains when and why these workarounds may be operationally necessary and describes them. However, the long term goal is to upgrade all NMS hosts to native IPv6, so the workarounds described in this section should not be considered permanent. ... > To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 > NAT can be used. This NAT setup could for example be done in Rt1r1 > in above picture to also support IPv4 only NMS hots connected to > NOClan. I think this (and the following paragraph) is underspecified. It isn't clear to me whether this would be described as a NAT64 or a NAT46 scenario (which side is the client and which side is the server, in other words). There's a lot more to specify to make this work - maybe the details are out of scope, which should be stated if so. Also, it would be better to say 'IP/ICMP translation' not 'NAT' and cite RFC7915. Make that clearly separate from the issue of how addresses are mapped. (Incidentally, recall that (a) IPv4 addresses are only 32 bits and (b) we own the ACP address plan. So algorithmic mapping of IPv4 addresses into a special /96 in the ACP address plan is possible. Of course that would be an insecure zone in ACP terms.) > 2.1.5. Path selection policies A lot of this section comes across almost as hand-waving. I did wonder whether it would have been enough just to state the problem. ... > MP-TCP (Multipath TCP -see [RFC6824]) is a very attractive candidate > to automate the use of both data-plane and ACP... I'm not sure... you seem to be asking for new intelligence in MPTCP's choice of candidate addresses, not just a policy but a whole mechanism in support of that policy. And will you really benefit from MPTCP's main point, which is automatic load management between alternative paths. Wouldn't SCTP be a better match? > 2.1.8. Long term direction of the solution ...> 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the > network to enable use of ACP is long term undesirable. Having > IPv4 only applications automatically leverage IPv6 connectivity > via host-stack options is likely non-feasible (NOTE: this has > still to be vetted more). That NOTE needs to be cleared up. Something like 464XLAT (RFC6877) might be a good compromise. > 3. Security Considerations ... > ULA addressing as proposed in this document is preferred over... Was this pasted from the ACP draft? Surely that is where ULA is proposed. > Randomn ULA addressing provides more than sufficient protection > against address collision even though there is no central assignment > authority. I don't like that phrase: it isn't the *address* that's random, it's the /48 prefix. Also, somebody is always ready to complain about the collision risk. Suggest: The random nature of a ULA prefix provides strong protection against address collision even though there is no central assignment authority. > If packets with unexpected ULA addresses are seen and one expects > them to be from another networks ACP from which they leaked, then > some form of ULA prefix registrastion (not allocation) can be > beneficial. Some voluntary registries exist, for example > https://www.sixxs.net/tools/grh/ula/, although none of them is > preferrable because of being operated by some recognized authority. > If an operator would want to make its ULA prefix known, it might need > to register it with multiple existing registries. > > ULA Centrally assigned ULA addresses (ULA-C) was an attempt to > introduce centralized registration of randomly assigned addresses and > potentially even carve out a different ULA prefix for such addresses. > This proposal is currently not proceeding, and it is questionable > whether the stable connectivity use case provides sufficient > motivation to revive this effort. I think all that is a red herring. I suggest replacing it by a simple statement: If packets with unexpected ULA addresses are seen they should be discarded. (Even that is not really needed, since all border routers should discard such packets anyway.) > Using current registration options implies that there will not be > reverse DNS mapping for ACP addresses. Really? I assume we're talking about two-faced DNS, and afaik nothing stops an operator providing reverse mapping in the private DNS. That seems to be implied by the following paragraphs, so the text seems inconsistent anyway. > 4. No IPv4 for ACP This section seems out of place stuck between Security Considerations and IANA Considerations. Maybe it should be an Appendix, referenced in section 2.1.4. "IPv4 only NMS hosts". Nits/English: ------------- (There are probably other nits as well as these, which the RFC Editor will fix...) > Abstract ... > ... Provisioning during device/network bring > up tends to be far less easy to automate than service provisioning > later on, changes in core network functions impacting reachability > can not be automated either because of ongoing connectivity > requirements for the OAM equipment itself, and widely used OAM > protocols are not secure enough to be carried across the network > without security concerns. Suggested: Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. > This document describes how to integrate OAM processes with the > autonomic control plane (ACP) in Autonomic Networks (AN). to provide > stable and secure connectivity for those OAM processes. Suggested: This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. > 1.2. Data Communication Networks (DCNs) > > In the late 1990'th and early 2000, IP networks became the method of > choice to build separate OAM networks for the communications > infrastructure in service providers. This concept was standardized > in G.7712/Y.1703 This needs a complete informational reference. Also, according to https://www.itu.int/rec/T-REC-G.7712-200303-S/en it is a superseded reference, so maybe there is a better one? > 2.1.1. Simple connectivity for non-autonomic NMS hosts ... > For example, if DNS in the network was set up with > names for network devices as devicename.noc.example.com, then the ACP > address of that device could be mapped to devicename- > acp.noc.exmaple.com. ... acp.noc.example.com > 2.1.2. Challenges and limitation of simple connectivity ...> Note that these challenges and limitations exist because the ACP is > primarily designed to support distributed ASA ... Define "ASA" when first used. Regards, Brian From nobody Mon Jul 24 08:28:08 2017 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 2AB79131CA1 for ; Mon, 24 Jul 2017 08:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQQf9m78W4US for ; Mon, 24 Jul 2017 08:28:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C436129A9F for ; Mon, 24 Jul 2017 08:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5432; q=dns/txt; s=iport; t=1500910084; x=1502119684; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2Q5X1f5kh1QvTUXt4/ZxiFIAQa/eSuW7L4ClmvctrwI=; b=FqCBFNkPjvV//AXByu7lumFSx5zdAfqvOmwNLxLbOHGnvaZbbAapXCT4 y+vHsyDL+ygWZ9LyCgOU7EUqqHp0vW+jQMhvkvyRIFursewSpXD6JIiv1 trCRcUrKmpgZJ/WHl0FqeBw7nBxhnJxW6fKkbd0ut0/hXmEl1nLXoN5mo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAADQEHZZ/5hdJa1SChoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNaZIEUB44FkWeIL41WghIhC4UbAhqDXD8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBIRE6CwULAgEIGAICJgICAh8GCxUQAgQOBYoXAw0IEK89giaHMQ2Dd?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuCHYUuK4J5gleBbIM7MIIxBYlelTQ?= =?us-ascii?q?8AosWhBaEcJI3jBCJUwEfOIEKdRVJEgGHA3YBiFSBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,407,1496102400"; d="scan'208";a="55912881" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2017 15:28:03 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6OFS3v2029553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jul 2017 15:28:03 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Jul 2017 10:28:02 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Mon, 24 Jul 2017 10:28:02 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter CC: Anima WG Thread-Topic: [Anima] Is this how BRSKI/IPIP works? Thread-Index: AQHS9f5MyS/kiRRNrkebsTDV06vTe6JjirkA Date: Mon, 24 Jul 2017 15:28:02 +0000 Message-ID: References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> In-Reply-To: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.7] Content-Type: text/plain; charset="utf-8" Content-ID: <1CD68CFFA012854790C718B0EF0269D9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Is this how BRSKI/IPIP works? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 15:28:06 -0000 DQpyZTogInRoaXMgY2FzZSBtdXN0IHdvcmvigJ0NClRoZXJlIHN1cmUgaXMgYSBsb3Qgb2YgY29t cGxleGl0eSBpbiB0aGlzIHRocmVhZCB0byBlbnN1cmUgdGhhdCBsaW5rIGxvY2FsIGFkZHJlc3Nl cyBjYW4gYmUgdXNlZCBvdXRzaWRlIG9mIHRoZSBsb2NhbCBzY29wZS4gDQoNClNvbWUgc2ltcGxl ciBzdWdnZXN0aW9ucywNCg0KMSkgYSBzdGF0ZWZ1bCBwcm94eS4gSSBrbm93LCBJIGtub3cuIEJ1 dCBob3cgbWFueSBkZXZpY2VzIGFyZSBhY3R1YWxseSBnb2luZyB0byBuZWVkIHRvIHBlcmZvcm0g QlJTS0kgYXQgdGhlIHNhbWUgdGltZT8gQW5kIGlmIHRoYXQgbWFueSBkZXZpY2VzIGFyZSBiZWlu ZyBib290c3RyYXBwZWQgdGhlbiBjYW7igJl0IHRoZXkgd2FpdCBmb3IgdGhlIHByb3h5IHRvIHdv cmsgdGhyb3VnaCB0aGVtIGluIG9yZGVyPyANCg0KMikgUmVxdWlyZSBwbGVkZ2VzIHRvIGNvbXBs ZXRlIFJGQzQ4NjIg4oCYQ3JlYXRpb24gb2YgR2xvYmFsIEFkZHJlc3Nlc+KAmS4gUGxlZGdlcyB0 aGVuIHBlcmZvcm0gR1JBU1AgYW5kIHRoZW4gY29tbXVuaWNhdGUgd2l0aCB0aGUgUmVnaXN0cmFy IGRpcmVjdGx5LiAoQ2FuIFJGQzQxOTMg4oCYVW5pcXVlIExvY2FsIElQdjYgVW5pY2FzdCBBZGRy ZXNzZXPigJkgYmUgYXNzaWduZWQ/IEkgdGhpbmsgc2/igKYpDQoNCm9yIA0KDQozKSBJZiBpdCAq ZG9lc27igJl0IHdvcmsqIHdoYXQgaGFwcGVucz8gQ3VycmVudGx5IEJSU0tJIHN0YXJ0cyBvdmVy IHcvbyBzdGF0aW5nIGFueXRoaW5nIGFib3V0IG9idGFpbmluZyBhIG5ldyBMcC4gV291bGQgaXQg aGVscCB0byByZXN0YXJ0IHRoZSBzdGFjayBhbmQgbG9vayBmb3IgYSB1bmlxdWUgTHAgYXQgdGhh dCBwb2ludD8gQWxsIHdl4oCZcmUgbG9va2luZyBmb3IgaXMgbm9uLWNvbGxpc2lvbiBkdXJpbmcg Ym9vdHN0cmFwcGluZy4gSSBkb27igJl0IGxpa2UgdGhpcyBhcHByb2FjaCBhcyBtdWNoIGFzIHRo ZSBhYm92ZSBvcHRpb25zLiANCg0KLSBtYXgNCg0KDQoNCj4gT24gSnVsIDUsIDIwMTcsIGF0IDg6 MTkgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdy b3RlOg0KPiANCj4gSGkgQlJTS0kgYXV0aG9ycywNCj4gDQo+IElzIHRoZSBmb2xsb3dpbmcgY29y cmVjdD8NCj4gDQo+IFRvcG9sb2d5IChBU0NJSSBhcnQpOg0KPiAgICAgICAgICAgICAgICAgICBf X19fX19fX19fXw0KPiAgICAgICAgICAgICAgICAgIHwgUkVHSVNUUkFSIHwNCj4gICAgICAgICAg ICAgICAgICB8X19fX19fX19fX198DQo+ICAgICAgICAgICAgICAgICAgICAgICAgfEFyDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgfCANCj4gICAgICAgICAgICAgICAgICAgLi4uLi4uLi4uLi4N Cj4gICAgICAgICAgICAgICAgICAoICAgIEFDUCAgICApDQo+ICAgICAgICAgICAgICAgICAoICAg cm91dGluZyAgICkNCj4gICAgICAgICAgICAgICAgICAoICAgY2xvdWQgICApDQo+ICAgICAgICAg ICAgICAgICAgIC4uLi4uLi4uLi4uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAg ICAgICAgICAgICAgICAgICAgIHxBeA0KPiAgICAgICAgICAgICAgICAgICBfX19fX3xfX19fXw0K PiAgICAgICAgICAgICAgICAgIHwgICBQUk9YWSAgIHwNCj4gICAgICAgICAgICAgICAgICB8X19f X19fX19fX198DQo+ICAgICAgICAgICAgICAgICAgIHxMeDEgICAgICB8THgyIA0KPiAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfA0K PiAgLS0tLS0tLUxBTjEtLS0tLS0tLS0gICAgICAtLS0tLS0tTEFOMi0tLS0tLS0tLS0NCj4gICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICB8THAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxMcA0KPiAgX19fX3xfX19fICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgX19ffF9fX19fIA0KPiB8IFBMRURHRTEgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8IFBMRURHRTIgfA0KPiB8X19fX19fX19ffCAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8X19fX19fX19ffCANCj4gDQo+IEFzc3VtcHRpb25zOg0KPiANCj4gUGxl ZGdlcyBoYXZlIGxpbmstbG9jYWwgYWRkcmVzcyBMcC4gQnkgY2hhbmNlLCB0aGV5IGFyZSBlcXVh bC4gKE5vdGhpbmcgaW4NCj4gdGhlIHN0YW5kYXJkcyBwcmV2ZW50cyB0aGVtIGZyb20gYmVpbmcg ZXF1YWwuIEV2ZW4gcHNldWRvLXJhbmRvbSBudW1iZXJzIGNhbg0KPiBiZSBlcXVhbCwgc28gdGhp cyBjYXNlIG11c3Qgd29yay4pDQo+IA0KPiBQcm94eSBoYXMgbGluay1sb2NhbCBhZGRyZXNzZXMg THgxLCBMeDIgYW5kIEFDUCBhZGRyZXNzIEF4LiBXZSBjYW4gcmVxdWlyZQ0KPiB0aGF0IEx4MSAh PSBMeDIuDQo+IA0KPiBSZWdpc3RyYXIgaGFzIEFDUCBhZGRyZXNzIEFyLg0KPiANCj4gUGFja2V0 cyBmb3IgYSBVRFAgZXhhbXBsZToNCj4gDQo+IChzb21ld2hhdCBzaW1wbGlmaWVkIElQdjYgcGFj a2V0cyEpDQo+IA0KPiBQbGVkZ2Ugc2VuZHMgdG8gcHJveHkgW0xwLCBMeDEsIDE3LCBVRFAtUEFZ TE9BRDFdDQo+IA0KPiBQcm94eSBzZW5kcyB0byBSZWdpc3RyYXIgW0F4LCBBciwgNDEsIFtMcCwg THgxLCAxNywgVURQLVBBWUxPQUQxXV0NCj4gDQo+IFJlZ2lzdHJhciByZXBsaWVzIHRvIHByb3h5 IFtBciwgQXgsIDQxLCBbTHgxLCBMcCwgMTcsIFVEUC1QQVlMT0FEMl1dDQo+IA0KPiBQcm94eSBy ZXBsaWVzIHRvIHBsZWRnZSBbTHgxLCBMcCwgMTcsIFVEUC1QQVlMT0FEMl0NCj4gDQo+IE5vdGUg dGhhdCB0aGUgcmVnaXN0cmFyIGVjaG9lcyBiYWNrIHRoZSBhZGRyZXNzZXMgTHAgYW5kIEx4IGJ1 dCB0aGV5IG1lYW4NCj4gbm90aGluZyB0byBpdC4gVGhlIHJlZ2lzdHJhciBzaW1wbHkgYm9ycm93 cyB0aGUgcHJveHkncyBMTCBhZGRyZXNzIEx4DQo+IGZvciB0aGUgcHVycG9zZSBvZiByZXBseWlu Zy4NCj4gDQo+IE5vdGUgdGhhdCBldmVuIHRoZSAydXBsZSB7QXgsIExwfSBtaWdodCBub3QgdW5p cXVlbHkgaWRlbnRpZnkgdGhlIHBsZWRnZS4NCj4gU2luY2UgdGhlIHByb3h5IHdpbGwgaGF2ZSBh dCBsZWFzdCB0d28gaW50ZXJmYWNlcywgdGhlIGFkZHJlc3MgTHAgbWlnaHQNCj4gZXhpc3Qgb24g bXVsdGlwbGUgTEFOcy4gSG93ZXZlciwgdGhlIHByb3h5IHdpbGwgaGF2ZSBkaWZmZXJlbnQgbGlu ay1sb2NhbA0KPiBhZGRyZXNzZXMgb24gdGhlIHR3byBMQU5zLCBzbyB0aGUgM3VwbGVzIHtBeCwg THAsIEx4MX0ge0F4LCBMcCwgTHgyfQ0KPiB3aWxsIGJlIHVuaXF1ZS4gSGVuY2UgdGhlIHJlZ2lz dHJhciBjYW4gZGlzdGluZ3Vpc2ggdGhlIHRyYW5zYWN0aW9ucy4NCj4gDQo+IFNvLCB3aGF0IHRo ZSByZWdpc3RyYXIgbmVlZHMgdG8gdGVsbCB0aGUgcHJveHkgaXM6IEkgYWNjZXB0IElQIGluIElQ IG9uIGFkZHJlc3MgQXIuDQo+IE5vdGhpbmcgZWxzZSAtIG5vIHBvcnQgbnVtYmVyLCBubyBsaW5r LWxvY2FsIGFkZHJlc3MuDQo+IA0KPiBXaGF0IHRoZSBwcm94eSBuZWVkcyB0byB0ZWxsIHRoZSBw bGVkZ2UgaXM6IEkgYWNjZXB0IEJSU0tJL1RDUA0KPiBvciBCUlNLSS9VRFAgb24gYWRkcmVzcyBM eC4gQW5kIGlmIGl0IGNob29zZXMgdG8gdXNlIElQSVAgdG8gY29udGFjdA0KPiB0aGUgcmVnaXN0 cmFyLCBpdCBzaW1wbHkgZm9yd2FyZHMgdGhlIHBhY2tldHMgYXMtaXMgaW4gYm90aCBkaXJlY3Rp b25zLA0KPiBlbmNhcHN1bGF0aW5nIGFuZCBkZWNhcHN1bGF0aW5nIGFjY29yZGluZ2x5LiBUaGUg cGxlZGdlIGtub3dzIG5vdGhpbmcgYWJvdXQNCj4gSVBJUC4NCj4gDQo+IFJlZ2FyZHMNCj4gICBC cmlhbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+IEFuaW1hQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0K From nobody Tue Jul 25 13:35:01 2017 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 8637C1317C1 for ; Tue, 25 Jul 2017 13:35:00 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 zMllurJf-icA for ; Tue, 25 Jul 2017 13:34:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE103131461 for ; Tue, 25 Jul 2017 13:34:58 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3C91758C4D8; Tue, 25 Jul 2017 22:34:55 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 25FD4B0C6BF; Tue, 25 Jul 2017 22:34:55 +0200 (CEST) Date: Tue, 25 Jul 2017 22:34:55 +0200 From: Toerless Eckert To: anima@ietf.org, nmrg@ietf.org Message-ID: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 20:35:00 -0000 I have an autonomic network, and i want for another customer another L3VPN service instance in it. How would i tell the network that i want this ? Via intent or via something else ? If it is something else, what is it ? I do not see any other information flow from operator to network beside intent in RFC7575 or draft-ietf-anima-reference-model. Maybe i am missing something. If it is intent, how would it look like ? Could it simply be a definition of an L3VPN service instance in the model defined in rfc8049 ? If not, why not ? IMHO: Intent in ANIMA includes service definitions such as what rfc8049 is, except that we would reserve the right to eliminate all parameters of rfc8049 for which we figure out autonomic ways to determine them. Which alas seems to be quite difficult for most parameters. Other folks in the IETF clearly think that a service definition is NOT intent, but intent can only be some yet unclear high level policy. If thats the prevailing opinion/wisdom in the IETF, then IMHO we need to be more explicit about the fact that Intent is not the only input into the network but that there is also other input. Such as services. And anything else that people do not want to call Intent. Lets assume service and other necessary data operator->network should not be called intent. But lets say the superset of intent + services + everything else is called eg: "information". I think that draft-du-anima-an-intent would equally apply to all information we would want to distribute into an autonomic network. Cheers Toerless From nobody Tue Jul 25 16:04:47 2017 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 B9488132023 for ; Tue, 25 Jul 2017 16:04:45 -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 re5WGcNxsyWT for ; Tue, 25 Jul 2017 16:04:43 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD0E132019 for ; Tue, 25 Jul 2017 16:04:43 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id k190so10528599pgk.5 for ; Tue, 25 Jul 2017 16:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=w68P+A1tXllc2eeSahfSf1O3W6l412u7l7eJxkuU1Nw=; b=KUavS/JdwUk8hzbAFpes8Xaz/lOrqYO8KuG2hssuVZ4YK/C0uRgQAXFca6cYZVVWsS RXbcCuFFw2MP/ju7UPxvi11FvqgK2ZbPtmz03YGgw29n/gEQqrXJMz0X0dAuMTT/iCFy xAm4fSTKfvvOofX7i/nWmGIVy8np7MJebUBIaun7Ou+xoW8luan0JUfS3By/sGtaa/ua oX55cyMbVOJ0er592+B33MOl51ca8eKrwhSmdPgPf/ufAIhZKP3Mv075mnKaNfPtYr/5 FXDopU78J/Cp1LP3/6HDoGY/DqWYEeVm0kXGsR7m559bJMUYijIqkmYorRmfSBZrYEo2 tQyA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=w68P+A1tXllc2eeSahfSf1O3W6l412u7l7eJxkuU1Nw=; b=uGcjo+P8LdPNWG1Y3mqp7gqfGVyTVdPlN3us8fLAUZ5MmOJciF9URczCfd31AIOkkh d+TCX8OgALXCsQDY2UNb36bQXRtAPZiuHPeIaWWifw8KZcUTQrTCBHRxQQLVnoRMORaM ONUs4H8bbE3o53qjfT9XKuUHeuCpYvEJ3D36rn2hd3N/wjLWiOXqeyaKk8T7xs/m9tfT yA+pESB+0UMoBru63k9vfNaNsj2PI4h772iZlG2CkYDy62g6ecN/hSEAQAVY6gm4aJUs kJfLh53EwCu0mzax1HJZwfINO6zlQvWrHyOvtJhUOgpJ2b8uz0JP5dfo+iqlFw+63zaA AL3A== X-Gm-Message-State: AIVw113snLq8m/CUrMTJsPgxYstMazyQQ/0L20Ek7Vvd37x927veO2E0 Qll9h2GwyXX7grNF X-Received: by 10.101.90.197 with SMTP id d5mr20471297pgt.223.1501023882978; Tue, 25 Jul 2017 16:04:42 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b13sm26863085pfj.141.2017.07.25.16.04.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 16:04:41 -0700 (PDT) To: Toerless Eckert , anima@ietf.org References: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 26 Jul 2017 11:04:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 23:04:46 -0000 Distribution trimmed to Anima: Whenever I've asked "Is X Intent?", I've usually been told "No" except for cases where X is too abstract to interpret algorithmically. But in practice, I believe that many ASAs will need instructions from the NOC to modify their default behaviour. I don't care what we call those instructions; for the prefix management use case we just called them "parameters". So maybe Anima should focus on parameter distribution more than on Intent. I think that's the point of draft-liu-anima-grasp-distribution. A fairly simple change to the wording of draft-du-anima-an-intent would adapt it to generic parameter distribution. Converting abstract Intent to concrete parameters can be completely separate from this, and could well be a centralised operation. Or we could spend another 6 months discussing how to know Intent when we see it. But I would prefer that to happen in NMRG. Regards Brian On 26/07/2017 08:34, Toerless Eckert wrote: > I have an autonomic network, and i want for another customer another > L3VPN service instance in it. How would i tell the network that i want > this ? Via intent or via something else ? > > If it is something else, what is it ? I do not see any other information flow from > operator to network beside intent in RFC7575 or draft-ietf-anima-reference-model. > Maybe i am missing something. > > If it is intent, how would it look like ? Could it simply be a definition > of an L3VPN service instance in the model defined in rfc8049 ? If not, why not ? > > IMHO: Intent in ANIMA includes service definitions such as what rfc8049 is, > except that we would reserve the right to eliminate all parameters of rfc8049 > for which we figure out autonomic ways to determine them. Which alas seems to > be quite difficult for most parameters. > > Other folks in the IETF clearly think that a service definition is NOT intent, > but intent can only be some yet unclear high level policy. If thats the > prevailing opinion/wisdom in the IETF, then IMHO we need to be more explicit about the > fact that Intent is not the only input into the network but that there is > also other input. Such as services. And anything else that people do not want to > call Intent. > > Lets assume service and other necessary data operator->network should not > be called intent. But lets say the superset of intent + services + everything > else is called eg: "information". I think that draft-du-anima-an-intent > would equally apply to all information we would want to distribute into > an autonomic network. > > Cheers > Toerless > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jul 25 17:06:11 2017 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 3F042132127 for ; Tue, 25 Jul 2017 17:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_39Nk1XLgOE for ; Tue, 25 Jul 2017 17:05:52 -0700 (PDT) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345CA132132 for ; Tue, 25 Jul 2017 17:05:50 -0700 (PDT) Received: by mail-qt0-f179.google.com with SMTP id r14so63344315qte.4 for ; Tue, 25 Jul 2017 17:05:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pqCLjVBtlWGJQC6LZgDCIvkFzrsyy+AF+3RyUrt+AAk=; b=dANpv8qxyVP5wsyeApu0vBP4+PHeeQ5fzNgxSua1I//yIOvMsVCyOtH/rm4szMVKqp n0icRBTrcfTO62fSaXjS/QRzaxuOISuXGwdiinRnOol8xE1Fp3FFqHOplLDfNijAl8wj 0WRvfXJ+qfedPEyiI3alJT8039+QMzi7QLjF36t1X6Ix4dx/Q2fUdFyrqkTahVZMWr7S Yxq5rbzCymZjcmC9Lr6lrVwZsGM5tnVC7+P7OQWV5tZkSpXvjRTjuMz11c1CHx3VLtZm k2uy8mfCuTbltmiH01uz1m0C7HK3NRxm13vbxKBmWNLGoprFjdry87MkqP/DI+9si1E3 aluw== X-Gm-Message-State: AIVw111LGMqS6zrTyMsnpEnekbL7RRi+FK/q9ZLKcqQrPI8CTFXeqzQK XV7I6vZmXroz5MZDg7jWesh/sj63Ww== X-Received: by 10.237.43.194 with SMTP id e60mr12673354qtd.25.1501027549155; Tue, 25 Jul 2017 17:05:49 -0700 (PDT) MIME-Version: 1.0 References: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> In-Reply-To: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Wed, 26 Jul 2017 00:05:37 +0000 Message-ID: To: Brian E Carpenter , Toerless Eckert , anima@ietf.org Content-Type: multipart/alternative; boundary="001a11485f26ddc78e05552d35d8" Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 00:06:04 -0000 --001a11485f26ddc78e05552d35d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi. The current wording in draft-du-anima-an-intent is "ANIMA Intent Policy". This sounds a little repetitive, but it highlights the problematic nature of intent in ANIMA. I'm not sure if only parameters can be enough, but it is also depends on the definition of "parameters"... Maybe some form of policies (for example, ECA rules) can be included in the discussion. In any case, I believe this could be addressed in draft-du-anima-an-intent. I agree with Brian, the intent "philosophical" discussion fits better the NMRG. BTW, there is a discussion about it in Prague and this could lead to a new NMRG workshop (like the autonomic ones). Best. J=C3=A9ferson Em ter, 25 de jul de 2017 =C3=A0s 20:04, Brian E Carpenter < brian.e.carpenter@gmail.com> escreveu: > Distribution trimmed to Anima: > > Whenever I've asked "Is X Intent?", I've usually been told "No" except fo= r > cases where X is too abstract to interpret algorithmically. > > But in practice, I believe that many ASAs will need instructions from > the NOC to modify their default behaviour. I don't care what we call > those instructions; for the prefix management use case we just called > them "parameters". > > So maybe Anima should focus on parameter distribution more than on > Intent. I think that's the point of draft-liu-anima-grasp-distribution. > A fairly simple change to the wording of draft-du-anima-an-intent > would adapt it to generic parameter distribution. > > Converting abstract Intent to concrete parameters can be completely > separate from this, and could well be a centralised operation. > > Or we could spend another 6 months discussing how to know Intent > when we see it. But I would prefer that to happen in NMRG. > > Regards > Brian > > On 26/07/2017 08:34, Toerless Eckert wrote: > > I have an autonomic network, and i want for another customer another > > L3VPN service instance in it. How would i tell the network that i want > > this ? Via intent or via something else ? > > > > If it is something else, what is it ? I do not see any other informatio= n > flow from > > operator to network beside intent in RFC7575 or > draft-ietf-anima-reference-model. > > Maybe i am missing something. > > > > If it is intent, how would it look like ? Could it simply be a definiti= on > > of an L3VPN service instance in the model defined in rfc8049 ? If not, > why not ? > > > > IMHO: Intent in ANIMA includes service definitions such as what rfc8049 > is, > > except that we would reserve the right to eliminate all parameters of > rfc8049 > > for which we figure out autonomic ways to determine them. Which alas > seems to > > be quite difficult for most parameters. > > > > Other folks in the IETF clearly think that a service definition is NOT > intent, > > but intent can only be some yet unclear high level policy. If thats the > > prevailing opinion/wisdom in the IETF, then IMHO we need to be more > explicit about the > > fact that Intent is not the only input into the network but that there = is > > also other input. Such as services. And anything else that people do no= t > want to > > call Intent. > > > > Lets assume service and other necessary data operator->network should n= ot > > be called intent. But lets say the superset of intent + services + > everything > > else is called eg: "information". I think that draft-du-anima-an-intent > > would equally apply to all information we would want to distribute into > > an autonomic network. > > > > Cheers > > Toerless > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a11485f26ddc78e05552d35d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi.
The current wording in=C2=A0draft-du-anima-an-inte= nt is "ANIMA Intent Policy". This sounds a little repetitive, but= it highlights the problematic nature of intent in ANIMA.
I'm= not sure if only parameters can be enough, but it is also depends on the d= efinition of "parameters"... Maybe some form of policies (for exa= mple, ECA rules) can be included in the discussion. In any case, I believe = this could be addressed in draft-du-anima-an-intent.
I agree with= Brian, the intent "philosophical" discussion fits better the NMR= G. BTW, there is a discussion about it in Prague and this could lead to a n= ew NMRG workshop (like the autonomic ones).
Best.
J=C3= =A9ferson

Em ter, 25 de = jul de 2017 =C3=A0s 20:04, Brian E Carpenter <brian.e.carpenter@gmail.com> escreveu:
Distribution trimmed to Anima:

Whenever I've asked "Is X Intent?", I've usually been tol= d "No" except for
cases where X is too abstract to interpret algorithmically.

But in practice, I believe that many ASAs will need instructions from
the NOC to modify their default behaviour. I don't care what we call those instructions; for the prefix management use case we just called
them "parameters".

So maybe Anima should focus on parameter distribution more than on
Intent. I think that's the point of draft-liu-anima-grasp-distribution.=
A fairly simple change to the wording of draft-du-anima-an-intent
would adapt it to generic parameter distribution.

Converting abstract Intent to concrete parameters can be completely
separate from this, and could well be a centralised operation.

Or we could spend another 6 months discussing how to know Intent
when we see it. But I would prefer that to happen in NMRG.

Regards
=C2=A0 =C2=A0Brian

On 26/07/2017 08:34, Toerless Eckert wrote:
> I have an autonomic network, and i want for another customer another > L3VPN service instance in it.=C2=A0 How would i tell the network that = i want
> this ? Via intent or via something else ?
>
> If it is something else, what is it ? I do not see any other informati= on flow from
> operator to network beside intent in RFC7575 or draft-ietf-anima-refer= ence-model.
> Maybe i am missing something.
>
> If it is intent, how would it look like ? Could it simply be a definit= ion
> of an L3VPN service instance in the model defined in rfc8049 ? If not,= why not ?
>
> IMHO: Intent in ANIMA includes service definitions such as what rfc804= 9 is,
> except that we would reserve the right to eliminate all parameters of = rfc8049
> for which we figure out autonomic ways to determine them. Which alas s= eems to
> be quite difficult for most parameters.
>
> Other folks in the IETF clearly think that a service definition is NOT= intent,
> but intent can only be some yet unclear high level policy. If thats th= e
> prevailing opinion/wisdom in the IETF, then IMHO we need to be more ex= plicit about the
> fact that Intent is not the only input into the network but that there= is
> also other input. Such as services. And anything else that people do n= ot want to
> call Intent.
>
> Lets assume service and other necessary data operator->network shou= ld not
> be called intent. But lets say the superset of intent + services + eve= rything
> else is called eg: "information". I think that draft-du-anim= a-an-intent
> would equally apply to all information we would want to distribute int= o
> an autonomic network.
>
> Cheers
>=C2=A0 =C2=A0 =C2=A0Toerless
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org=
> https://www.ietf.org/mailman/listinfo/anima
>

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a11485f26ddc78e05552d35d8-- From nobody Wed Jul 26 00:30:21 2017 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 721EB126B7E for ; Wed, 26 Jul 2017 00:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUPe8msYwzux for ; Wed, 26 Jul 2017 00:30:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAE31200FC for ; Wed, 26 Jul 2017 00:30:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLH96576; Wed, 26 Jul 2017 07:30:14 +0000 (GMT) Received: from LHREML502-MBX.china.huawei.com ([10.201.109.54]) by lhreml703-cah.china.huawei.com ([10.201.108.44]) with mapi id 14.03.0301.000; Wed, 26 Jul 2017 08:29:40 +0100 From: Zoran Despotovic To: "anima@ietf.org" Thread-Topic: [Anima] What is intent ? Thread-Index: AQHTBYWK22bsT2APAkm2LAxFoDd0RKJlGP0AgACaTSA= Date: Wed, 26 Jul 2017 07:29:41 +0000 Message-ID: References: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59784507.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7acec8c1cda2de4e088df28a45357277 Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 07:30:19 -0000 Hi, A little bit off the thread started by Toerless, I believe that the develop= ment of the infrastructure on which intents are distributed should not be t= ightly bound to our understanding of and consensus on what intents are (and= what they are not). This, at least, as long as there are other parameters = to be distributed over that infrastructure. In that sense, I do agree with = Brian's mail.=20 Regards,=20 Zoran -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, July 26, 2017 1:05 AM To: Toerless Eckert; anima@ietf.org Subject: Re: [Anima] What is intent ? Distribution trimmed to Anima: Whenever I've asked "Is X Intent?", I've usually been told "No" except for = cases where X is too abstract to interpret algorithmically. But in practice, I believe that many ASAs will need instructions from the N= OC to modify their default behaviour. I don't care what we call those instr= uctions; for the prefix management use case we just called them "parameters= ". So maybe Anima should focus on parameter distribution more than on Intent. = I think that's the point of draft-liu-anima-grasp-distribution. A fairly simple change to the wording of draft-du-anima-an-intent would ada= pt it to generic parameter distribution. Converting abstract Intent to concrete parameters can be completely separat= e from this, and could well be a centralised operation. Or we could spend another 6 months discussing how to know Intent when we se= e it. But I would prefer that to happen in NMRG. Regards Brian On 26/07/2017 08:34, Toerless Eckert wrote: > I have an autonomic network, and i want for another customer another=20 > L3VPN service instance in it. How would i tell the network that i=20 > want this ? Via intent or via something else ? >=20 > If it is something else, what is it ? I do not see any other=20 > information flow from operator to network beside intent in RFC7575 or dra= ft-ietf-anima-reference-model. > Maybe i am missing something. >=20 > If it is intent, how would it look like ? Could it simply be a=20 > definition of an L3VPN service instance in the model defined in rfc8049 ?= If not, why not ? >=20 > IMHO: Intent in ANIMA includes service definitions such as what=20 > rfc8049 is, except that we would reserve the right to eliminate all=20 > parameters of rfc8049 for which we figure out autonomic ways to=20 > determine them. Which alas seems to be quite difficult for most parameter= s. >=20 > Other folks in the IETF clearly think that a service definition is NOT=20 > intent, but intent can only be some yet unclear high level policy. If=20 > thats the prevailing opinion/wisdom in the IETF, then IMHO we need to=20 > be more explicit about the fact that Intent is not the only input into=20 > the network but that there is also other input. Such as services. And=20 > anything else that people do not want to call Intent. >=20 > Lets assume service and other necessary data operator->network should=20 > not be called intent. But lets say the superset of intent + services +=20 > everything else is called eg: "information". I think that=20 > draft-du-anima-an-intent would equally apply to all information we=20 > would want to distribute into an autonomic network. >=20 > Cheers > Toerless >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 26 01:44:49 2017 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 47ED8131FBE for ; Wed, 26 Jul 2017 01:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpeoMZKHSbPq for ; Wed, 26 Jul 2017 01:44:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03D4131F93 for ; Wed, 26 Jul 2017 01:44:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSB44802; Wed, 26 Jul 2017 08:44:30 +0000 (GMT) Received: from LHREML501-MBX.china.huawei.com ([10.201.109.49]) by lhreml707-cah.china.huawei.com ([10.201.108.48]) with mapi id 14.03.0301.000; Wed, 26 Jul 2017 09:44:29 +0100 From: Artur Hecker To: "anima@ietf.org" Thread-Topic: [Anima] What is intent ? Thread-Index: AQHTBYWKKkYDumdN6kC8l1//bw3LDKJlGP0AgACNF4CAACDGkA== Date: Wed, 26 Jul 2017 08:44:28 +0000 Message-ID: <8DA547FB1280754AAC43A3E56DCB7AD20AEC2D57@lhreml501-mbx> References: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59785677.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9c81066add5a6909d9481e161fb13769 Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 08:44:46 -0000 Hi Aren't intents something related to the actual autonomics of the ANI, while= the use case described by Toerless would be more from an operated context? RFC7575 in particular does not exclude operated environments, and the latte= r might or might not use intents or policy-based management principles. So,= what is autonomic is the establishment and maintenance of the ACP, I,.e. t= he means to manage the environment (in any way you like). So, from my under= standing, solely the autonomic part related to the self-* properties of the= ACP and the autonomic domain (AD) as such would be driven by intents, and = not more than that. Corroborating this interpretation, the scope of the int= ent is intrinsically bound to the very notion of AD by the definition of th= e latter, cf. RFC7575. Therefore, we could try to agree on something like this: - Within the scope of the ANIMA WG, we could interpret intents as solely re= lated to the ANIMA itself, not to its usage. In other words, the existence,= constraints, form, shapes and parameters of the AD per se (=3Dthe enabling= substrate, the mandatory ASAs, the implementation of the ANI) are ruled by= and derived from intents. [What is meant here is a form of policy based ma= nagement, where instead of precise actions (do this), the expected conditio= ns (pre- and post-) are formulated for and within the limits of the AD (pre= -condition =3D> post-condition). The only interesting property of this is t= hat it is implementation agnostic, i.e. you are not prescribing how the pos= t-condition is to be achieved. In my interpretation, this means that in par= ticular the standardization effort is minimized (since we do not prescribe = how to arrive at a particular situation, we do not have to worry about spec= ific mechanisms within the ANIMA itself; a conforming implementation has di= fferent ways how to achieve it)]. - How the AD is used, e.g. by an operator, or by some end-user ASA, should = rather be outside of the scope of ANIMA WG and is solely constrained by the= API that ANIMA would propose and the imagination of the respective owners/= developers. Note that this does not preclude any kind of "recursive" definitions, where= an AF implemented on top of an ANI would constitute another AD, where the = same would apply (ASAs would become "nodes"), etc. Does that make any sense? Regards artur -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Zoran Despotovic Sent: 26 July 2017 09:30 To: anima@ietf.org Subject: Re: [Anima] What is intent ? Hi, A little bit off the thread started by Toerless, I believe that the develop= ment of the infrastructure on which intents are distributed should not be t= ightly bound to our understanding of and consensus on what intents are (and= what they are not). This, at least, as long as there are other parameters = to be distributed over that infrastructure. In that sense, I do agree with = Brian's mail.=20 Regards, Zoran -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, July 26, 2017 1:05 AM To: Toerless Eckert; anima@ietf.org Subject: Re: [Anima] What is intent ? Distribution trimmed to Anima: Whenever I've asked "Is X Intent?", I've usually been told "No" except for = cases where X is too abstract to interpret algorithmically. But in practice, I believe that many ASAs will need instructions from the N= OC to modify their default behaviour. I don't care what we call those instr= uctions; for the prefix management use case we just called them "parameters= ". So maybe Anima should focus on parameter distribution more than on Intent. = I think that's the point of draft-liu-anima-grasp-distribution. A fairly simple change to the wording of draft-du-anima-an-intent would ada= pt it to generic parameter distribution. Converting abstract Intent to concrete parameters can be completely separat= e from this, and could well be a centralised operation. Or we could spend another 6 months discussing how to know Intent when we se= e it. But I would prefer that to happen in NMRG. Regards Brian On 26/07/2017 08:34, Toerless Eckert wrote: > I have an autonomic network, and i want for another customer another=20 > L3VPN service instance in it. How would i tell the network that i=20 > want this ? Via intent or via something else ? >=20 > If it is something else, what is it ? I do not see any other=20 > information flow from operator to network beside intent in RFC7575 or dra= ft-ietf-anima-reference-model. > Maybe i am missing something. >=20 > If it is intent, how would it look like ? Could it simply be a=20 > definition of an L3VPN service instance in the model defined in rfc8049 ?= If not, why not ? >=20 > IMHO: Intent in ANIMA includes service definitions such as what > rfc8049 is, except that we would reserve the right to eliminate all=20 > parameters of rfc8049 for which we figure out autonomic ways to=20 > determine them. Which alas seems to be quite difficult for most parameter= s. >=20 > Other folks in the IETF clearly think that a service definition is NOT=20 > intent, but intent can only be some yet unclear high level policy. If=20 > thats the prevailing opinion/wisdom in the IETF, then IMHO we need to=20 > be more explicit about the fact that Intent is not the only input into=20 > the network but that there is also other input. Such as services. And=20 > anything else that people do not want to call Intent. >=20 > Lets assume service and other necessary data operator->network should=20 > not be called intent. But lets say the superset of intent + services +=20 > everything else is called eg: "information". I think that=20 > draft-du-anima-an-intent would equally apply to all information we=20 > would want to distribute into an autonomic network. >=20 > Cheers > Toerless >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 26 03:56:24 2017 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 1698D131FED for ; Wed, 26 Jul 2017 03:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBgp3xEqcjiI for ; Wed, 26 Jul 2017 03:56:21 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB46B131FEF for ; Wed, 26 Jul 2017 03:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4018; q=dns/txt; s=iport; t=1501066578; x=1502276178; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=5iVhE6aVDtHswstAUk5uXXQnJ3SEQ6rJOdt1jvwaipE=; b=aO2t3cvy9+K822hfD2OWbd00EMaHY57hAlwJlMOJWj9qPUV7yjebQDtA mGYGs5qt0M4JVJzhkIrTigCSjXBvowbc7fwMqFuoxwHicx1fZLhPgbCpg DMQ5Q6rKjP4ZObe2btZ02HnPEXBtYD+xnLfZM38TwoXPQXBG0MWUlNkmw A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AADmdHhZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD6BFI4Mc5B4lgmCEgcaC4UbAoQCGAECAQEBAQEBAWsohRkBAQEDAQE?= =?us-ascii?q?hBEcbCw4KKgICJzAGAQwGAgEBiisQsgiBbDqLRgEBAQEBAQEBAgEBAQEBAQEBE?= =?us-ascii?q?QoFgyiFLiuCeYgGgmEBBIltlW6EMIIejVOLMYcJlXAfOIEKMiEIHBVJhRsXgWk?= =?us-ascii?q?+Nok1AQEB?= X-IronPort-AV: E=Sophos;i="5.40,414,1496102400"; d="asc'?scan'208";a="696075073" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2017 10:56:13 +0000 Received: from [10.61.194.70] ([10.61.194.70]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6QAuDDx031450; Wed, 26 Jul 2017 10:56:13 GMT To: Toerless Eckert , anima@ietf.org, nmrg@ietf.org References: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: Date: Wed, 26 Jul 2017 12:56:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vUJAuc5IGEW1haqP6begkt87ap4FoixBD" Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 10:56:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vUJAuc5IGEW1haqP6begkt87ap4FoixBD Content-Type: multipart/mixed; boundary="nwRdb1H8BBDgTJqnD1WX084hmaHudS34O"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert , anima@ietf.org, nmrg@ietf.org Message-ID: Subject: Re: [Anima] What is intent ? References: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> --nwRdb1H8BBDgTJqnD1WX084hmaHudS34O Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Toerless, I've heard MUD called a form of intent, but it's not a perfect fit. MUD expresses needs rather than intent. That is- "I need the network to allow X." One could *infer* an intent, but but such inferences get riskier the higher up the stack one goes. In your case, though, one could extend the MUD file to describe the need for a VPN, so long as the parameters of that VPN are well understood in the terms of the MUD abstractions at the time of manufacturer ("my-controller", "same-manufacturer", etc). As a formalism between ANIs, MUD is not the droid you're looking for, as currently scoped. Eliot On 7/25/17 10:34 PM, Toerless Eckert wrote: > I have an autonomic network, and i want for another customer another > L3VPN service instance in it. How would i tell the network that i want= > this ? Via intent or via something else ? > > If it is something else, what is it ? I do not see any other informatio= n flow from > operator to network beside intent in RFC7575 or draft-ietf-anima-refere= nce-model.=20 > Maybe i am missing something. > > If it is intent, how would it look like ? Could it simply be a definiti= on > of an L3VPN service instance in the model defined in rfc8049 ? If not, = why not ? > > IMHO: Intent in ANIMA includes service definitions such as what rfc8049= is, > except that we would reserve the right to eliminate all parameters of r= fc8049 > for which we figure out autonomic ways to determine them. Which alas se= ems to > be quite difficult for most parameters.=20 > > Other folks in the IETF clearly think that a service definition is NOT = intent, > but intent can only be some yet unclear high level policy. If thats the= > prevailing opinion/wisdom in the IETF, then IMHO we need to be more exp= licit about the > fact that Intent is not the only input into the network but that there = is > also other input. Such as services. And anything else that people do no= t want to > call Intent. > > Lets assume service and other necessary data operator->network should n= ot > be called intent. But lets say the superset of intent + services + ever= ything > else is called eg: "information". I think that draft-du-anima-an-intent= > would equally apply to all information we would want to distribute into= > an autonomic network.=20 > > Cheers > Toerless > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --nwRdb1H8BBDgTJqnD1WX084hmaHudS34O-- --vUJAuc5IGEW1haqP6begkt87ap4FoixBD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZeHVMAAoJEIe2a0bZ0nozsy0H/icoVSYobLe0dIGrdEs36YMY 1QsFrVgjQ2eJxggowxYf3Dbor1GyykJIIuZn+1mBD6OnO0MTCYlJixfMvVbGcQ/8 mtM9rFym01fnzcL4KCtpsBIaChBT3fmX/tfRQWNZPodeePOwi4N5ZPwIV2nyYpcC BAILV0bJKbs2gWW9tzM+pFdqstl+KlCfGmWskJCKlpG43NT4B38jdY5hQRpjNrHy KYmcr0bpsbm8PMZrp3kYBNN/WxaMjvrhGOkeSyURncT8xwUJXrfW/q0plDFwS3qD CUILpqn+MgALjmPwKxQNtNC/bk/qHQ9Tf4Ru6CYt0yck3dAqgo47fKbJ/8uvTCA= =eX6K -----END PGP SIGNATURE----- --vUJAuc5IGEW1haqP6begkt87ap4FoixBD-- From nobody Wed Jul 26 03:59:16 2017 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 5176B131FE9; Wed, 26 Jul 2017 03:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l-j1OnTT4LH; Wed, 26 Jul 2017 03:59:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634EA131FE8; Wed, 26 Jul 2017 03:59:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLI35353; Wed, 26 Jul 2017 10:59:10 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Jul 2017 11:58:11 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 26 Jul 2017 18:58:06 +0800 From: Sheng Jiang To: Brian E Carpenter , Toerless Eckert , "anima@ietf.org" , =?iso-8859-1?Q?J=E9ferson_Campos_Nobre?= CC: "draft-du-anima-an-intent.authors@ietf.org" Thread-Topic: [Anima] What is intent ? Thread-Index: AQHTBYWIrt9EjncNH0q7YmIuWDuhaaJko6QAgACeH7A= Date: Wed, 26 Jul 2017 10:58:06 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CE3A55E@NKGEML515-MBX.china.huawei.com> References: <20170725203454.GA7884@faui40p.informatik.uni-erlangen.de> In-Reply-To: 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.597875FE.020C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7acec8c1cda2de4e088df28a45357277 Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 10:59:15 -0000 Hi, Toerless, Brian & Jeferson, Please see my replies in line with quotas from you. Toerless> Other folks in the IETF clearly think that a service definition i= s NOT intent, but > intent can only be some yet unclear high level policy. If thats the preva= iling > opinion/wisdom in the IETF, then IMHO we need to be more explicit about t= he > fact that Intent is not the only input into the network but that there is= also > other input. Such as services. And anything else that people do not want = to call > Intent. I prefer such distinguish definitions. Intent itself does not have a clear = definition. It does not a clear role in Autonomic network either. This word= has been abused a lot. If we cannot reach consensus on its semantics. It m= ay be wise to give up it and choose more precise terminologies. Toerless>I think that draft-du-anima-an-intent would equally > apply to all information we would want to distribute into an autonomic > network. Jeferson>I believe this could be addressed in draft-du-anima-an-intent. As a co-author of this draft, I also think we have a very good base already= . However, we may need to rename the document in order to avoid the too-hot= term "intent". Brian>we could spend another 6 months discussing how to know Intent when we= see it. But I would prefer that to happen in NMRG. Jeferson>I agree with Brian, the intent "philosophical" discussion fits bet= ter the NMRG. This suggestion is actually very pragmatic. Let's focus on these concrete a= nd generic solutions first. Regards, Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Wednesday, July 26, 2017 7:05 AM > To: Toerless Eckert; anima@ietf.org > Subject: Re: [Anima] What is intent ? >=20 > Distribution trimmed to Anima: >=20 > Whenever I've asked "Is X Intent?", I've usually been told "No" except fo= r cases > where X is too abstract to interpret algorithmically. >=20 > But in practice, I believe that many ASAs will need instructions from the= NOC to > modify their default behaviour. I don't care what we call those instructi= ons; for > the prefix management use case we just called them "parameters". >=20 > So maybe Anima should focus on parameter distribution more than on Intent= . I > think that's the point of draft-liu-anima-grasp-distribution. > A fairly simple change to the wording of draft-du-anima-an-intent would a= dapt > it to generic parameter distribution. >=20 > Converting abstract Intent to concrete parameters can be completely separ= ate > from this, and could well be a centralised operation. >=20 > Or we could spend another 6 months discussing how to know Intent when we > see it. But I would prefer that to happen in NMRG. >=20 > Regards > Brian >=20 > On 26/07/2017 08:34, Toerless Eckert wrote: > > I have an autonomic network, and i want for another customer another > > L3VPN service instance in it. How would i tell the network that i > > want this ? Via intent or via something else ? > > > > If it is something else, what is it ? I do not see any other > > information flow from operator to network beside intent in RFC7575 or > draft-ietf-anima-reference-model. > > Maybe i am missing something. > > > > If it is intent, how would it look like ? Could it simply be a > > definition of an L3VPN service instance in the model defined in rfc8049= ? If not, > why not ? > > > > IMHO: Intent in ANIMA includes service definitions such as what > > rfc8049 is, except that we would reserve the right to eliminate all > > parameters of rfc8049 for which we figure out autonomic ways to > > determine them. Which alas seems to be quite difficult for most paramet= ers. > > > > Other folks in the IETF clearly think that a service definition is NOT > > intent, but intent can only be some yet unclear high level policy. If > > thats the prevailing opinion/wisdom in the IETF, then IMHO we need to > > be more explicit about the fact that Intent is not the only input into > > the network but that there is also other input. Such as services. And > > anything else that people do not want to call Intent. > > > > Lets assume service and other necessary data operator->network should > > not be called intent. But lets say the superset of intent + services + > > everything else is called eg: "information". I think that > > draft-du-anima-an-intent would equally apply to all information we > > would want to distribute into an autonomic network. > > > > Cheers > > Toerless > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 26 10:39:19 2017 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 91B301320C8; Wed, 26 Jul 2017 10:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DSVN_Odv9TKs; Wed, 26 Jul 2017 10:39:07 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1B9131D2E; Wed, 26 Jul 2017 10:39:06 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C67A058C4E5; Wed, 26 Jul 2017 19:39:00 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A8995B0C6D4; Wed, 26 Jul 2017 19:39:00 +0200 (CEST) Date: Wed, 26 Jul 2017 19:39:00 +0200 From: Toerless Eckert To: Sheng Jiang Cc: Brian E Carpenter , "anima@ietf.org" , J?ferson Campos Nobre , "draft-du-anima-an-intent.authors@ietf.org" Message-ID: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 17:39:18 -0000 Another aspect to consider: IMHO, industry player/marketeers use the term "intent" not to describe a particular subset of instructions into the network but as a term to describe the overall systems operation. Eg: Google: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45687.pdf Intent driven operations, from slide 22 on. IMHO Cisco also jumped onto this terminology in its latest intent based networking pitch. In this context, intent based networking is simply that the operator specifies a target ("intended") state of the network and some "rendering engine(s)" try to continuously modify the network to match that intended state. Including changes to the network due to failures. Eg: re-establish services such as BGP speakers on other nodes when current instances fail. IMHO: with this notion of intent, it would be perfectly valid to enter any type of high or low level declarative and even instructive data into the network - including my favourite instance of an rfc8049 L3VPN service. The input into the network has no name in these models. It is whatever operators put into SDN controllers or workflow engines, or whatever the tool of the day is called. My vision for ANIMA and intent is something like this: We come up with a term for everything operators would want to send into a network. Lets say we call it "directives". And we can keep the term for everything the operator gets out of a network "reporting". We structure and define some taxonomy for "directives", eg: "service definitions", "service instances", {user, topology, reliability, performance, acc-control,...}-policies, workflows, ... We describe an architecture how directives are rendered, eg: how the network is made to match the directives. Different type of directives may require different rendering. The key difference between existing systems (google, cisco, ..) is that we define a hybrid central + distributed rendering architecture: draft-du-anima-intent IMHO would be the basis for the distributed rendering: This is used whenever there are self-rendering autonomic functions (aka: a group of ASA that know how to render directives). Even for central rendering there are no well established standards. That too IMHO would be worth looking at. Maybe some other IETF WG would like to do this as well, which would be fine too, as long as we allow this option in ANIMA as well. The word intent does not happen in these definitions, and we are totally free to decide later if we call the whole system "intent based", or iwf we call all of the directives or just a subset of the directives "intent". I am not sure if we would still want to take this step for the reference model. For me it would be fine not to change reference model at all, and take the step above afterwards. Its afer all not really a functional change to what we describe in the reference model, but really only a refinemenet and then renaming to match evolving industry terminologies. Cheers Toerless P.S.: I would have gone for "Objectives" instead of "Directives", but that word is already occupied by GRASP and reuse would IMHO be confusing... In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE3A55E@NKGEML515-MBX.china.huawei.com> On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote: > Hi, Toerless, Brian & Jeferson, > > Please see my replies in line with quotas from you. > > Toerless> Other folks in the IETF clearly think that a service definition is NOT intent, but > > intent can only be some yet unclear high level policy. If thats the prevailing > > opinion/wisdom in the IETF, then IMHO we need to be more explicit about the > > fact that Intent is not the only input into the network but that there is also > > other input. Such as services. And anything else that people do not want to call > > Intent. > > I prefer such distinguish definitions. Intent itself does not have a clear definition. It does not a clear role in Autonomic network either. This word has been abused a lot. If we cannot reach consensus on its semantics. It may be wise to give up it and choose more precise terminologies. > > Toerless>I think that draft-du-anima-an-intent would equally > > apply to all information we would want to distribute into an autonomic > > network. > Jeferson>I believe this could be addressed in draft-du-anima-an-intent. > > As a co-author of this draft, I also think we have a very good base already. However, we may need to rename the document in order to avoid the too-hot term "intent". > > Brian>we could spend another 6 months discussing how to know Intent when we see it. But I would prefer that to happen in NMRG. > Jeferson>I agree with Brian, the intent "philosophical" discussion fits better the NMRG. > > This suggestion is actually very pragmatic. Let's focus on these concrete and generic solutions first. > > Regards, > > Sheng > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter > > Sent: Wednesday, July 26, 2017 7:05 AM > > To: Toerless Eckert; anima@ietf.org > > Subject: Re: [Anima] What is intent ? > > > > Distribution trimmed to Anima: > > > > Whenever I've asked "Is X Intent?", I've usually been told "No" except for cases > > where X is too abstract to interpret algorithmically. > > > > But in practice, I believe that many ASAs will need instructions from the NOC to > > modify their default behaviour. I don't care what we call those instructions; for > > the prefix management use case we just called them "parameters". > > > > So maybe Anima should focus on parameter distribution more than on Intent. I > > think that's the point of draft-liu-anima-grasp-distribution. > > A fairly simple change to the wording of draft-du-anima-an-intent would adapt > > it to generic parameter distribution. > > > > Converting abstract Intent to concrete parameters can be completely separate > > from this, and could well be a centralised operation. > > > > Or we could spend another 6 months discussing how to know Intent when we > > see it. But I would prefer that to happen in NMRG. > > > > Regards > > Brian > > > > On 26/07/2017 08:34, Toerless Eckert wrote: > > > I have an autonomic network, and i want for another customer another > > > L3VPN service instance in it. How would i tell the network that i > > > want this ? Via intent or via something else ? > > > > > > If it is something else, what is it ? I do not see any other > > > information flow from operator to network beside intent in RFC7575 or > > draft-ietf-anima-reference-model. > > > Maybe i am missing something. > > > > > > If it is intent, how would it look like ? Could it simply be a > > > definition of an L3VPN service instance in the model defined in rfc8049 ? If not, > > why not ? > > > > > > IMHO: Intent in ANIMA includes service definitions such as what > > > rfc8049 is, except that we would reserve the right to eliminate all > > > parameters of rfc8049 for which we figure out autonomic ways to > > > determine them. Which alas seems to be quite difficult for most parameters. > > > > > > Other folks in the IETF clearly think that a service definition is NOT > > > intent, but intent can only be some yet unclear high level policy. If > > > thats the prevailing opinion/wisdom in the IETF, then IMHO we need to > > > be more explicit about the fact that Intent is not the only input into > > > the network but that there is also other input. Such as services. And > > > anything else that people do not want to call Intent. > > > > > > Lets assume service and other necessary data operator->network should > > > not be called intent. But lets say the superset of intent + services + > > > everything else is called eg: "information". I think that > > > draft-du-anima-an-intent would equally apply to all information we > > > would want to distribute into an autonomic network. > > > > > > Cheers > > > Toerless > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 26 10:55:24 2017 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 5082C131DB6 for ; Wed, 26 Jul 2017 10:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuH4QpoOLfNb for ; Wed, 26 Jul 2017 10:55:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBE5131E05 for ; Wed, 26 Jul 2017 10:55:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLI96981; Wed, 26 Jul 2017 17:55:18 +0000 (GMT) Received: from LHREML501-MBX.china.huawei.com ([10.201.109.49]) by lhreml707-cah.china.huawei.com ([10.201.108.48]) with mapi id 14.03.0301.000; Wed, 26 Jul 2017 18:55:14 +0100 From: Artur Hecker To: "anima@ietf.org" Thread-Topic: Review draft-ietf-anima-reference-model-04 Thread-Index: AdL8rftkcbJTFE6DSF+ugNLuguLV7A== Date: Wed, 26 Jul 2017 17:55:13 +0000 Message-ID: <8DA547FB1280754AAC43A3E56DCB7AD20AEC33E8@lhreml501-mbx> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5978D786.0175, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 75d95c7978b42fb94ef890893a43ce71 Archived-At: Subject: [Anima] Review draft-ietf-anima-reference-model-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 17:55:23 -0000 Dear community, dear Authors, I reread the draft-ietf-anima-reference-model-04. I hope it's not arriving = at an inappropriate moment, but please find some notes and remarks below: 1. Page 6: s/potentiall/potential 2. Page 8: Section 4. The text mentions "must implement" and "other" functi= ons, but fails to correctly guide the reader as to the MUST or not MUST of = the functions in the following subsections. It is partly not even clear fro= m the semantics of the subsections. Suggestion: clearly group MUST, SHOULD and MAY IMPLEMENT functions in the s= ubsections. 3. Page 12: Information Distribution - consider rewriting parts of this sec= tion entirely. Several problems: a) Remove repetitive text in the beginning: "Certain forms of information, such as Intent, must be distributed across a= n autonomic domain. The distribution of information is also a function of t= he Autonomic Control Plane. One form of such information is Intent." Suggestion: Either remove the first inclusion, or the entire last sentence.= I would rewrite these three, see next point: b) There seems to be a problem with the statement above, as the "must" is s= omehow misleading in a potentially normative text. What is meant here is th= at some information requires dissemination, while other might not require t= hat.=20 Suggestion - please REWRITE e.g. as follows: "Certain forms of information require per its nature distribution across a = (part of) autonomic domain. Such information distribution is a function of = the Autonomic Control Plane. As an example, Intents require distribution ac= ross the whole autonomic domain as per definitions from RFC7575." c) Later, the text in this section somehow confuses the high level requirem= ents (=3Dinformation distribution) with a specific implementation, notably = flooding. Note that there is a subtle difference between the requirement to= reach all recipients (indeed, the current text seems to equal flooding to = that) and flooding, which technically usually means "unconstrained broadcas= t". [E.g. Wikipedia: "Flooding is a simple computer network routing algorit= hm in which every incoming packet is sent through every outgoing link excep= t the one it arrived on"]. This will lead to explosive message number growt= h, as the ACP uses routing - which does not guarantee a tree structure - wh= ile the scale of an autonomic domain is, by definitions of RFC7575, only co= nstrained by the Intent as such ("the autonomic domain is the set of nodes,= to which the intent needs to be sent"). At the same time, there are better= known algorithms for routing, which achieve "distribution to all recipient= s" without "sending on all links except the one it arrived on" (e.g. struct= ured broadcast, etc). Suggestion: stay at the requirements level in the Reference text, which thi= s draft represents. In other words, remove suggestions of implementations, = or reword if the requirement to reach all nodes is meant. 4. Page 17, Section 6.3.3. The Information Distribution ASA (*). While the text above (on page 12: Information Distribution) says that Infor= mation Distribution is function of ACP, somehow there is a distinct section= in this draft, talking about an Information Distribution ASA, which is NOT= ACP ASA, and which is not obligatory. How to read this correctly? 5. Page 17, Section 7.1: "How an AN Network Is Managed" a) Please consider changing the title. AN is "autonomic network" network ne= twork :-) b) The first paragraph says that the co-existence is twofold. However, I ca= n think of at least one other way: the ACP could be used as a transport cha= nnel for "traditional" management. E.g. ACP could be used to transport NETC= ONF messages, instead of SSH or BEEP in NETCONF. Not clear, what twofold me= ans here (just an example, limitation, strong statement, etc). 6. Page 18, Section 7.2: "Intent" Please reread and correct this phrase: "It is expected Intent definitions f= rom autonomic function(s) and even from traditional network management elem= ents". (missing verb) Later in the text, the section references I-D.liu-anima-grasp-distribution,= which is odd, given that the actual Information Distribution section (see = above) does not. Yet, information distribution in I-D.liu-anima-grasp-distr= ibution is not limited to intents. 7. Page 19, Section 7.5: "Control loops" The section talks about an "Autonomic System". Unless I am mistaken, an aut= onomic system is not defined (e.g. in RFC7575). This is a minor issue, as w= e all can imagine what a "system" is. 8. Page 20, Section 7.6: "APIs" There is a strong "MUST" requirement in this section (express and preserve = semantics across different domains), which is not as clear as a MUST should= be. First, it's not clear what "express and preserve semantics" means (sem= antics of what? Of objects? Of object methods? Of the results delivered by = object methods? Of all of them?). Second, the "domain" is not defined: is a= n autonomic domain meant? Note that this notion is dynamic, as per intent s= cope, so probably not a very good reference. Third, the requirement is not = corroborated clearly. Instead, an example is given, which we might discuss = in its relevance to the ANIMA WG and work scope. Is ANIMA implementing soft= ware contracts? Is it a MUST requirement? Probably not. Note that web-based= systems today have no such formal specifications, as mentioned in this sec= tion. Example: invariants; these are nice to have, but hard to determine fo= r any complex piece of software (like a web service, etc). 9. Page 20, Section 7.7: "Data Model" Question: why do we need this section? This looks like some text book. Do w= e have a specification of data model in ANIMA? Information model? Anything = like that? If not, I guess this can be shortened, as it is "for reference" = only. (What is MRACL? Used without explanation in text). 10. Page 22, Section 8.1: s/mechanisms exists/mechanisms exist. 11. Page 23, Section 9: "Security Considerations" Please rephrase "run inside the encrypted ACP". I hope that it's not simply= "encrypted" but actually features the full range of cryptographic data pro= tection methods. Rationale: I would argue that integrity is more important than confidential= ity in the ANIMA scope. As encryption alone does not provide any protection= against modification, and since hopefully the used mechanisms (see Section= 9.2) go beyond encryption, I would recommend to use a more correct wording= , something like "protected" or "cryptographically protected ACP". Generally, the section does not sufficiently presents the threat of message= modification and replay, including the discovery messages. Also, authentic= ation is not sufficiently covered, even though a reference to I-D.ietf-anim= a-bootstrapping-keyinfra is made. Not sure it's the best approach, as boots= trapping refers to how to enroll the node, and the authentication is probab= ly using standard mechanisms? Normally, the threats should be described ind= ependently of the specific mechanisms. Regards artur From nobody Wed Jul 26 10:57:10 2017 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 A4636131DB6; Wed, 26 Jul 2017 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kssLbKbYHfoy; Wed, 26 Jul 2017 10:57:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACDE131E05; Wed, 26 Jul 2017 10:57:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSC34602; Wed, 26 Jul 2017 17:57:03 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Jul 2017 18:57:02 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.240]) by SJCEML701-CHM.china.huawei.com ([169.254.3.13]) with mapi id 14.03.0301.000; Wed, 26 Jul 2017 10:56:49 -0700 From: Alexander Clemm To: Toerless Eckert , Sheng Jiang CC: J?ferson Campos Nobre , "draft-du-anima-an-intent.authors@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] What is intent ? Thread-Index: AQHTBjYQylyYxOBGoEGyUCvBKTvJ36JmYFRA Date: Wed, 26 Jul 2017 17:56:49 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com> References: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5978D7EF.014E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.240, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9c81066add5a6909d9481e161fb13769 Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 17:57:10 -0000 Maybe "directives" is a good term because less overloaded. Of course, now = there is one more term that needs to be differentiated from the others that= came before.=20 In my view, "intent" as it is used today really is not much more than a hig= her-level policy. From this perspective, no new term would be needed. =20 One distinction that one could perhaps make is that a policy is very specif= ic concerning what needs to happen, typically expressed using some kind of = rule sets based on event/condition/action, containing a well-defined set of= events, conditions, as well as actions that need to occur. So, a policy, = like a directive, is very specific not just about what the network needs to= do but how to do it. =20 "Intent", on the other hand, would be less specific in terms of what needs = to occur, e.g. the types of actions that need to be taken. Those might be = determined non-deterministically, potentially through collaborating systems= ; really the intent providing more of a desired "range of state" without tr= ying to "program" how to reach or maintain it. So, in that sense it would = be very different from a directive. Yes, more of a goal. =20 When we first started using the term intent, my view at the time is that "i= ntent" would be something that the network would have to infer from the ope= rator's actions and utterances - an important aspect would be for the netwo= rk to speak the language of the operator, as opposed to the other way aroun= d (forcing the operator to speak the network's language). The discussion o= f intent languages put that viewpoint to rest, of course. =20 --- Alex -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert Sent: Wednesday, July 26, 2017 10:39 AM To: Sheng Jiang Cc: J?ferson Campos Nobre ; draft-du-anima-an-intent.= authors@ietf.org; anima@ietf.org Subject: Re: [Anima] What is intent ? Another aspect to consider: IMHO, industry player/marketeers use the term "= intent" not to describe a particular subset of instructions into the networ= k but as a term to describe the overall systems operation. Eg: Google: https://static.googleusercontent.com/media/research.google.com/= en//pubs/archive/45687.pdf Intent driven operations, from slide 22 on. IMHO Cisco also jumped onto this terminology in its latest intent based net= working pitch. In this context, intent based networking is simply that the operator specif= ies a target ("intended") state of the network and some "rendering engine(s)" try to con= tinuously modify the network to match that intended state. Including change= s to the network due to failures. Eg: re-establish services such as BGP speakers on other nodes when current = instances fail. IMHO: with this notion of intent, it would be perfectly valid to enter any = type of high or low level declarative and even instructive data into the ne= twork - including my favourite instance of an rfc8049 L3VPN service. The in= put into the network has no name in these models. It is whatever operators put into SDN controllers or workflow engines, or w= hatever the tool of the day is called. My vision for ANIMA and intent is something like this: We come up with a term for everything operators would want to send into a= network. Lets say we call it "directives". And we can keep the term for everything= the operator gets out of a network "reporting". We structure and define some taxonomy for "directives", eg: "service defi= nitions", "service instances", {user, topology, reliability, performance, acc-contr= ol,...}-policies, workflows, ... We describe an architecture how directives are rendered, eg: how the netw= ork is made to match the directives. Different type of directives may require different= rendering. The key difference between existing systems (google, cisco, ..) is that w= e define a hybrid central + distributed rendering architecture: draft-du-anima-intent IMHO would be the basis for the distributed renderi= ng: This is used whenever there are self-rendering autonomic functions (aka: a group = of ASA that know how to render directives). Even for central rendering there are no well established standards. That = too IMHO would be worth looking at. Maybe some other IETF WG would like to do this as well,= which would be fine too, as long as we allow this option in ANIMA as well. The word intent does not happen in these definitions, and we are totally fr= ee to decide later if we call the whole system "intent based", or iwf we ca= ll all of the directives or just a subset of the directives "intent". I am not sure if we would still want to take this step for the reference mo= del. For me it would be fine not to change reference model at all, and take= the step above afterwards. Its afer all not really a functional change to what we describe in the refe= rence model, but really only a refinemenet and then renaming to match evolv= ing industry terminologies. Cheers Toerless P.S.: I would have gone for "Objectives" instead of "Directives", but that= word is already occupied by GRASP and reuse would IMHO be confusing... In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE3A55E@NKGEML515-MBX.china.= huawei.com> On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote: > Hi, Toerless, Brian & Jeferson, >=20 > Please see my replies in line with quotas from you. >=20 > Toerless> Other folks in the IETF clearly think that a service=20 > Toerless> definition is NOT intent, but > > intent can only be some yet unclear high level policy. If thats the=20 > > prevailing opinion/wisdom in the IETF, then IMHO we need to be more=20 > > explicit about the fact that Intent is not the only input into the=20 > > network but that there is also other input. Such as services. And=20 > > anything else that people do not want to call Intent. >=20 > I prefer such distinguish definitions. Intent itself does not have a clea= r definition. It does not a clear role in Autonomic network either. This wo= rd has been abused a lot. If we cannot reach consensus on its semantics. It= may be wise to give up it and choose more precise terminologies. >=20 > Toerless>I think that draft-du-anima-an-intent would equally > > apply to all information we would want to distribute into an=20 > > autonomic network. > Jeferson>I believe this could be addressed in draft-du-anima-an-intent. >=20 > As a co-author of this draft, I also think we have a very good base alrea= dy. However, we may need to rename the document in order to avoid the too-h= ot term "intent". >=20 > Brian>we could spend another 6 months discussing how to know Intent when = we see it. But I would prefer that to happen in NMRG. > Jeferson>I agree with Brian, the intent "philosophical" discussion fits b= etter the NMRG. >=20 > This suggestion is actually very pragmatic. Let's focus on these concrete= and generic solutions first. >=20 > Regards, >=20 > Sheng >=20 > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E=20 > > Carpenter > > Sent: Wednesday, July 26, 2017 7:05 AM > > To: Toerless Eckert; anima@ietf.org > > Subject: Re: [Anima] What is intent ? > >=20 > > Distribution trimmed to Anima: > >=20 > > Whenever I've asked "Is X Intent?", I've usually been told "No"=20 > > except for cases where X is too abstract to interpret algorithmically. > >=20 > > But in practice, I believe that many ASAs will need instructions=20 > > from the NOC to modify their default behaviour. I don't care what we=20 > > call those instructions; for the prefix management use case we just cal= led them "parameters". > >=20 > > So maybe Anima should focus on parameter distribution more than on=20 > > Intent. I think that's the point of draft-liu-anima-grasp-distribution. > > A fairly simple change to the wording of draft-du-anima-an-intent=20 > > would adapt it to generic parameter distribution. > >=20 > > Converting abstract Intent to concrete parameters can be completely=20 > > separate from this, and could well be a centralised operation. > >=20 > > Or we could spend another 6 months discussing how to know Intent=20 > > when we see it. But I would prefer that to happen in NMRG. > >=20 > > Regards > > Brian > >=20 > > On 26/07/2017 08:34, Toerless Eckert wrote: > > > I have an autonomic network, and i want for another customer=20 > > > another L3VPN service instance in it. How would i tell the=20 > > > network that i want this ? Via intent or via something else ? > > > > > > If it is something else, what is it ? I do not see any other=20 > > > information flow from operator to network beside intent in RFC7575=20 > > > or > > draft-ietf-anima-reference-model. > > > Maybe i am missing something. > > > > > > If it is intent, how would it look like ? Could it simply be a=20 > > > definition of an L3VPN service instance in the model defined in=20 > > > rfc8049 ? If not, > > why not ? > > > > > > IMHO: Intent in ANIMA includes service definitions such as what > > > rfc8049 is, except that we would reserve the right to eliminate=20 > > > all parameters of rfc8049 for which we figure out autonomic ways=20 > > > to determine them. Which alas seems to be quite difficult for most pa= rameters. > > > > > > Other folks in the IETF clearly think that a service definition is=20 > > > NOT intent, but intent can only be some yet unclear high level=20 > > > policy. If thats the prevailing opinion/wisdom in the IETF, then=20 > > > IMHO we need to be more explicit about the fact that Intent is not=20 > > > the only input into the network but that there is also other=20 > > > input. Such as services. And anything else that people do not want to= call Intent. > > > > > > Lets assume service and other necessary data operator->network=20 > > > should not be called intent. But lets say the superset of intent +=20 > > > services + everything else is called eg: "information". I think=20 > > > that draft-du-anima-an-intent would equally apply to all=20 > > > information we would want to distribute into an autonomic network. > > > > > > Cheers > > > Toerless > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > >=20 > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 26 11:42:59 2017 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 B490D131C95; Wed, 26 Jul 2017 11:42:58 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 an9fjxs_XS22; Wed, 26 Jul 2017 11:42: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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C181A126CD8; Wed, 26 Jul 2017 11:42:55 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 23B2858C4C3; Wed, 26 Jul 2017 20:42:51 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0C209B0C6D4; Wed, 26 Jul 2017 20:42:50 +0200 (CEST) Date: Wed, 26 Jul 2017 20:42:50 +0200 From: Toerless Eckert To: Alexander Clemm Cc: Sheng Jiang , J?ferson Campos Nobre , "draft-du-anima-an-intent.authors@ietf.org" , "anima@ietf.org" Message-ID: <20170726184250.GC5750@faui40p.informatik.uni-erlangen.de> References: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 18:42:58 -0000 On Wed, Jul 26, 2017 at 05:56:49PM +0000, Alexander Clemm wrote: > Maybe "directives" is a good term because less overloaded. Of course, now there is one more term that needs to be differentiated from the others that came before. > > In my view, "intent" as it is used today really is not much more than a higher-level policy. From this perspective, no new term would be needed. But thats not how its used in google/cisco for intent based networking. And if more industry player catch on to how these compnies use intent very vaguely, any more specific but contradictory definition we come up with would just be confusing. Just tell me what in Googles definition is the intent. You saw my interpretation in my prior mail. Cheers Toerless > One distinction that one could perhaps make is that a policy is very specific concerning what needs to happen, typically expressed using some kind of rule sets based on event/condition/action, containing a well-defined set of events, conditions, as well as actions that need to occur. So, a policy, like a directive, is very specific not just about what the network needs to do but how to do it. > "Intent", on the other hand, would be less specific in terms of what needs to occur, e.g. the types of actions that need to be taken. Those might be determined non-deterministically, potentially through collaborating systems; really the intent providing more of a desired "range of state" without trying to "program" how to reach or maintain it. So, in that sense it would be very different from a directive. Yes, more of a goal. > > When we first started using the term intent, my view at the time is that "intent" would be something that the network would have to infer from the operator's actions and utterances - an important aspect would be for the network to speak the language of the operator, as opposed to the other way around (forcing the operator to speak the network's language). The discussion of intent languages put that viewpoint to rest, of course. > > --- Alex > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: Wednesday, July 26, 2017 10:39 AM > To: Sheng Jiang > Cc: J?ferson Campos Nobre ; draft-du-anima-an-intent.authors@ietf.org; anima@ietf.org > Subject: Re: [Anima] What is intent ? > > Another aspect to consider: IMHO, industry player/marketeers use the term "intent" not to describe a particular subset of instructions into the network but as a term to describe the overall systems operation. > > Eg: Google: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45687.pdf > Intent driven operations, from slide 22 on. > > IMHO Cisco also jumped onto this terminology in its latest intent based networking pitch. > > In this context, intent based networking is simply that the operator specifies a target > ("intended") state of the network and some "rendering engine(s)" try to continuously modify the network to match that intended state. Including changes to the network due to failures. > Eg: re-establish services such as BGP speakers on other nodes when current instances fail. > > IMHO: with this notion of intent, it would be perfectly valid to enter any type of high or low level declarative and even instructive data into the network - including my favourite instance of an rfc8049 L3VPN service. The input into the network has no name in these models. > It is whatever operators put into SDN controllers or workflow engines, or whatever the tool of the day is called. > > My vision for ANIMA and intent is something like this: > > We come up with a term for everything operators would want to send into a network. > Lets say we call it "directives". And we can keep the term for everything the operator > gets out of a network "reporting". > > We structure and define some taxonomy for "directives", eg: "service definitions", > "service instances", {user, topology, reliability, performance, acc-control,...}-policies, workflows, > ... > > We describe an architecture how directives are rendered, eg: how the network is made to > match the directives. Different type of directives may require different rendering. > > The key difference between existing systems (google, cisco, ..) is that we define a > hybrid central + distributed rendering architecture: > > draft-du-anima-intent IMHO would be the basis for the distributed rendering: This is > used whenever there are self-rendering autonomic functions (aka: a group of ASA > that know how to render directives). > > Even for central rendering there are no well established standards. That too IMHO would be > worth looking at. Maybe some other IETF WG would like to do this as well, which would be fine > too, as long as we allow this option in ANIMA as well. > > The word intent does not happen in these definitions, and we are totally free to decide later if we call the whole system "intent based", or iwf we call all of the directives or just a subset of the directives "intent". > > I am not sure if we would still want to take this step for the reference model. For me it would be fine not to change reference model at all, and take the step above afterwards. > Its afer all not really a functional change to what we describe in the reference model, but really only a refinemenet and then renaming to match evolving industry terminologies. > > Cheers > Toerless > > P.S.: I would have gone for "Objectives" instead of "Directives", but that word is already occupied by GRASP and reuse would IMHO be confusing... > > In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE3A55E@NKGEML515-MBX.china.huawei.com> > > On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote: > > Hi, Toerless, Brian & Jeferson, > > > > Please see my replies in line with quotas from you. > > > > Toerless> Other folks in the IETF clearly think that a service > > Toerless> definition is NOT intent, but > > > intent can only be some yet unclear high level policy. If thats the > > > prevailing opinion/wisdom in the IETF, then IMHO we need to be more > > > explicit about the fact that Intent is not the only input into the > > > network but that there is also other input. Such as services. And > > > anything else that people do not want to call Intent. > > > > I prefer such distinguish definitions. Intent itself does not have a clear definition. It does not a clear role in Autonomic network either. This word has been abused a lot. If we cannot reach consensus on its semantics. It may be wise to give up it and choose more precise terminologies. > > > > Toerless>I think that draft-du-anima-an-intent would equally > > > apply to all information we would want to distribute into an > > > autonomic network. > > Jeferson>I believe this could be addressed in draft-du-anima-an-intent. > > > > As a co-author of this draft, I also think we have a very good base already. However, we may need to rename the document in order to avoid the too-hot term "intent". > > > > Brian>we could spend another 6 months discussing how to know Intent when we see it. But I would prefer that to happen in NMRG. > > Jeferson>I agree with Brian, the intent "philosophical" discussion fits better the NMRG. > > > > This suggestion is actually very pragmatic. Let's focus on these concrete and generic solutions first. > > > > Regards, > > > > Sheng > > > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > > > Carpenter > > > Sent: Wednesday, July 26, 2017 7:05 AM > > > To: Toerless Eckert; anima@ietf.org > > > Subject: Re: [Anima] What is intent ? > > > > > > Distribution trimmed to Anima: > > > > > > Whenever I've asked "Is X Intent?", I've usually been told "No" > > > except for cases where X is too abstract to interpret algorithmically. > > > > > > But in practice, I believe that many ASAs will need instructions > > > from the NOC to modify their default behaviour. I don't care what we > > > call those instructions; for the prefix management use case we just called them "parameters". > > > > > > So maybe Anima should focus on parameter distribution more than on > > > Intent. I think that's the point of draft-liu-anima-grasp-distribution. > > > A fairly simple change to the wording of draft-du-anima-an-intent > > > would adapt it to generic parameter distribution. > > > > > > Converting abstract Intent to concrete parameters can be completely > > > separate from this, and could well be a centralised operation. > > > > > > Or we could spend another 6 months discussing how to know Intent > > > when we see it. But I would prefer that to happen in NMRG. > > > > > > Regards > > > Brian > > > > > > On 26/07/2017 08:34, Toerless Eckert wrote: > > > > I have an autonomic network, and i want for another customer > > > > another L3VPN service instance in it. How would i tell the > > > > network that i want this ? Via intent or via something else ? > > > > > > > > If it is something else, what is it ? I do not see any other > > > > information flow from operator to network beside intent in RFC7575 > > > > or > > > draft-ietf-anima-reference-model. > > > > Maybe i am missing something. > > > > > > > > If it is intent, how would it look like ? Could it simply be a > > > > definition of an L3VPN service instance in the model defined in > > > > rfc8049 ? If not, > > > why not ? > > > > > > > > IMHO: Intent in ANIMA includes service definitions such as what > > > > rfc8049 is, except that we would reserve the right to eliminate > > > > all parameters of rfc8049 for which we figure out autonomic ways > > > > to determine them. Which alas seems to be quite difficult for most parameters. > > > > > > > > Other folks in the IETF clearly think that a service definition is > > > > NOT intent, but intent can only be some yet unclear high level > > > > policy. If thats the prevailing opinion/wisdom in the IETF, then > > > > IMHO we need to be more explicit about the fact that Intent is not > > > > the only input into the network but that there is also other > > > > input. Such as services. And anything else that people do not want to call Intent. > > > > > > > > Lets assume service and other necessary data operator->network > > > > should not be called intent. But lets say the superset of intent + > > > > services + everything else is called eg: "information". I think > > > > that draft-du-anima-an-intent would equally apply to all > > > > information we would want to distribute into an autonomic network. > > > > > > > > Cheers > > > > Toerless > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 26 13:14:15 2017 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 92A36129B10 for ; Wed, 26 Jul 2017 13:14:14 -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 bYCKvWJWNxeE for ; Wed, 26 Jul 2017 13:14:13 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 E3A7912942F for ; Wed, 26 Jul 2017 13:14:12 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id 125so88590897pgi.3 for ; Wed, 26 Jul 2017 13:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=O8bfQf0clvJ9G2lY2z8ox+7OHo57elXJEdIcnfIvmk0=; b=kM0TBudtTy0u/Xe5fP87/ihxmAQAZ5ICfK05hgKpTsk/096G3LBeyOK49nhZLvEyd/ gexl/GX6lBRVuSk0d43mav4yB3maudPfikcDhgmrdelY4UWOWsijLfQ4f5Xaad/olPo4 hEgXbFVeaVso0qCD6/QMLrw37Jk1ntM1VEs5/pNtGkn+VEvGQ3tomvQiVLKb5+u4ql/8 ZwxFCuG/MlYNJqwmG/fiwf8cV41OCQV/wKGWWVCcm9gMYoeuVQVDy++1Rip6YIjNL3i9 GjNsiBne6RC2j0IZtq5S9XsXU+9ewTYrcQ1N9QyUhkZe/+dh43/Z2sd9+RjjO3FXXbzO HwUw== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=O8bfQf0clvJ9G2lY2z8ox+7OHo57elXJEdIcnfIvmk0=; b=Jer+xJyHeAf9SA/VixSQSFm3gd5rfbfK2j+4tjL4XV1i77/aSUyyfcHBUAMER+Sjqe psbBszSdFzt5t/gGko71yC2X1u5hYnsa00zRdEy5UtXoQghanWRYElZZ4cAbUzmDwuBH tDoMQe/OR2+F/jeG8xrKBDmcMHQFkejSTDrktmktJp12q7FvOpAD8+S/Oe8MeGr0r1kU q4jqZ38wHqPLKiaOgOTBBJf0SJU5oBfqoS/QL65ZConXeK1XfkOB2bX+NVJ3dmnRuFMW zAX5gAAK4VPxsDDF+1z2S7FNzF5ArfbzROpyE0w4Pjcn+qAdM6z1CkWKwAlQcqexLg+5 BgRQ== X-Gm-Message-State: AIVw110pqx8qNRsn+Xws7Mfe7fCI8ESsK76PCFiHBGUhZilWRWhdhByo Slx0EuLIz4XYmXdr X-Received: by 10.84.139.36 with SMTP id 33mr2061441plq.20.1501100052282; Wed, 26 Jul 2017 13:14:12 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p27sm12654930pfl.23.2017.07.26.13.14.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 13:14:11 -0700 (PDT) To: Artur Hecker , "anima@ietf.org" References: <8DA547FB1280754AAC43A3E56DCB7AD20AEC33E8@lhreml501-mbx> From: Brian E Carpenter Organization: University of Auckland Message-ID: <97e783a6-f738-79e9-1f3f-657bdfa6e33d@gmail.com> Date: Thu, 27 Jul 2017 08:14:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AEC33E8@lhreml501-mbx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Anima] Review draft-ietf-anima-reference-model-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 20:14:15 -0000 QXJ0dXIsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFdob2V2ZXIgdGFrZXMgdXAgdGhl IGVkaXRpbmcgcGVuIG5leHQgd2lsbCBjZXJ0YWlubHkgdXNlIHlvdXIgY29tbWVudHMuDQoN Ck9uIG9uZSBzcGVjaWZpYyBwb2ludDoNCg0KPiBjKSBMYXRlciwgdGhlIHRleHQgaW4gdGhp cyBzZWN0aW9uIHNvbWVob3cgY29uZnVzZXMgdGhlIGhpZ2ggbGV2ZWwgcmVxdWlyZW1lbnRz ICg9aW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uKSB3aXRoIGEgc3BlY2lmaWMgaW1wbGVtZW50 YXRpb24sIG5vdGFibHkgZmxvb2RpbmcuIE5vdGUgdGhhdCB0aGVyZSBpcyBhIHN1YnRsZSBk aWZmZXJlbmNlIGJldHdlZW4gdGhlIHJlcXVpcmVtZW50IHRvIHJlYWNoIGFsbCByZWNpcGll bnRzIChpbmRlZWQsIHRoZSBjdXJyZW50IHRleHQgc2VlbXMgdG8gZXF1YWwgZmxvb2Rpbmcg dG8gdGhhdCkgYW5kIGZsb29kaW5nLCB3aGljaCB0ZWNobmljYWxseSB1c3VhbGx5IG1lYW5z ICJ1bmNvbnN0cmFpbmVkIGJyb2FkY2FzdCIuIFtFLmcuIFdpa2lwZWRpYTogIkZsb29kaW5n IGlzIGEgc2ltcGxlIGNvbXB1dGVyIG5ldHdvcmsgcm91dGluZyBhbGdvcml0aG0gaW4gd2hp Y2ggZXZlcnkgaW5jb21pbmcgcGFja2V0IGlzIHNlbnQgdGhyb3VnaCBldmVyeSBvdXRnb2lu ZyBsaW5rIGV4Y2VwdCB0aGUgb25lIGl0IGFycml2ZWQgb24iXS4gVGhpcyB3aWxsIGxlYWQg dG8gZXhwbG9zaXZlIG1lc3NhZ2UgbnVtYmVyIGdyb3d0aCwgYXMgdGhlIEFDUCB1c2VzIHJv dXRpbmcgLSB3aGljaCBkb2VzIG5vdCBndWFyYW50ZWUgYSB0cmVlIHN0cnVjdHVyZSAtIHdo aWxlIHRoZSBzY2FsZSBvZiBhbiBhdXRvbm9taWMgZG9tYWluIGlzLCBieSBkZWZpbml0aW9u cyBvZiBSRkM3NTc1LCBvbmx5IGNvbnN0cmFpbmVkIGJ5IHRoZSBJbnRlbnQgYXMgc3VjaCAo InRoZSBhdXRvbm9taWMgZG9tYWluIGlzIHRoZSBzZXQgb2Ygbm9kZXMsIHRvIHdoaWNoIHRo ZSBpbnRlbnQgbmVlZHMgdG8gYmUgc2VudCIpLiBBdCB0aGUgc2FtZSB0aW1lLCB0aGVyZSBh cmUgYmV0dGVyIGtub3duIGFsZ29yaXRobXMgZm9yIHJvdXRpbmcsIHdoaWNoIGFjaGlldmUg ImRpc3RyaWJ1dGlvbiB0byBhbGwgcmVjaXBpZW50cyIgd2l0aG91dCAic2VuZGluZyBvbiBh bGwgbGlua3MgZXhjZXB0IHRoZSBvbmUgaXQgYXJyaXZlZCBvbiIgKGUuZy4gc3RydWN0dXJl ZCBicm9hZGNhc3QsIGV0YykuDQoNCkkgYWdyZWUgaW4gZ2VuZXJhbDsgdGhlIHdheSB0aGUg dGV4dCB1c2VzICJmbG9vZCIgaXMgY2FyZWxlc3MuIEhvd2V2ZXIsIHRoZSBHUkFTUCBmbG9v ZGluZyBtZWNoYW5pc20gaXMgKGEpIG9mIGNvdXJzZSBsaW1pdGVkIHRvIEdSQVNQIG5vZGVz IGFuZCAoYikgY29udGFpbnMgc3BlY2lmaWMgbWVhc3VyZXMgdG8gcHJ1bmUgdGhlIGRpc3Ry aWJ1dGlvbiBhbmQgcHJldmVudCBsb29wcy4gV2hpbGUNCnRoYXQgZG9lcyBub3QgZ3VhcmFu dGVlIGEgc3RyaWN0IHRyZWUgc3RydWN0dXJlLCBpLmUuIGlzIG5vdCBhbiBpZGVhbGlzZWQg bXVsdGljYXN0IHJvdXRpbmcgYWxnb3JpdGhtLCBpdCBkb2Vzbid0IHJlcXVpcmUgdGhlIEFD UCB0byBzdXBwb3J0IG11bHRpY2FzdCByb3V0aW5nIGFuZCBpdCBpcyB3ZWxsIGFkYXB0ZWQg dG8gbG93LWZyZXF1ZW5jeSBpbmZvcm1hdGlvbiBkaXN0cmlidXRpb24gYXMgd2UgZXhwZWN0 IGluIGFuIEFOLiANCg0KUmVnYXJkcw0KICAgQnJpYW4NCg== From nobody Wed Jul 26 13:16:13 2017 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 AFC3512942F; Wed, 26 Jul 2017 13:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga4b9UdbmlAF; Wed, 26 Jul 2017 13:16:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96CC124234; Wed, 26 Jul 2017 13:16:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSC47033; Wed, 26 Jul 2017 20:16:04 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Jul 2017 21:16:02 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.240]) by SJCEML701-CHM.china.huawei.com ([169.254.3.13]) with mapi id 14.03.0301.000; Wed, 26 Jul 2017 13:15:45 -0700 From: Alexander Clemm To: Toerless Eckert CC: Sheng Jiang , J?ferson Campos Nobre , "draft-du-anima-an-intent.authors@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] What is intent ? Thread-Index: AQHTBjYQylyYxOBGoEGyUCvBKTvJ36JmYFRAgACGjwD//6LikA== Date: Wed, 26 Jul 2017 20:15:44 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAB5C@SJCEML703-CHM.china.huawei.com> References: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com> <20170726184250.GC5750@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170726184250.GC5750@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5978F886.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.240, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9c81066add5a6909d9481e161fb13769 Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 20:16:12 -0000 OK, so it *is* used like in the subsequent paragraph. ["Intent", on the ot= her hand, would be less specific in terms of what needs to occur, e.g. the = types of actions that need to be taken. Those might be determined non-dete= rministically, potentially through collaborating systems; really the intent= providing more of a desired "range of state" without trying to "program" h= ow to reach or maintain it.] This is then a way to distinguish it. Specify a desired objective, or "ran= ge of state" (whatever state means), without needing to program how that wo= uld actually be accomplished. This is different from a directive, or polic= y defined using E/C/A. Which raises another question in the Anima context= , namely whether it is just "intent" that is needed, or "intent + something= else" (such as policy, directives, etc) Cheers --- Alex -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de]=20 Sent: Wednesday, July 26, 2017 11:43 AM To: Alexander Clemm Cc: Sheng Jiang ; J?ferson Campos Nobre ; draft-du-anima-an-intent.authors@ietf.org; anima@ietf.org Subject: Re: [Anima] What is intent ? On Wed, Jul 26, 2017 at 05:56:49PM +0000, Alexander Clemm wrote: > Maybe "directives" is a good term because less overloaded. Of course, no= w there is one more term that needs to be differentiated from the others th= at came before.=20 >=20 > In my view, "intent" as it is used today really is not much more than a h= igher-level policy. From this perspective, no new term would be needed. =20 But thats not how its used in google/cisco for intent based networking. And= if more industry player catch on to how these compnies use intent very vag= uely, any more specific but contradictory definition we come up with would = just be confusing. Just tell me what in Googles definition is the intent. You saw my interpret= ation in my prior mail. Cheers Toerless > One distinction that one could perhaps make is that a policy is very spec= ific concerning what needs to happen, typically expressed using some kind o= f rule sets based on event/condition/action, containing a well-defined set = of events, conditions, as well as actions that need to occur. So, a policy= , like a directive, is very specific not just about what the network needs = to do but how to do it. =20 > "Intent", on the other hand, would be less specific in terms of what need= s to occur, e.g. the types of actions that need to be taken. Those might b= e determined non-deterministically, potentially through collaborating syste= ms; really the intent providing more of a desired "range of state" without = trying to "program" how to reach or maintain it. So, in that sense it woul= d be very different from a directive. Yes, more of a goal. =20 >=20 > When we first started using the term intent, my view at the time is that = "intent" would be something that the network would have to infer from the o= perator's actions and utterances - an important aspect would be for the net= work to speak the language of the operator, as opposed to the other way aro= und (forcing the operator to speak the network's language). The discussion= of intent languages put that viewpoint to rest, of course. =20 >=20 > --- Alex >=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless=20 > Eckert > Sent: Wednesday, July 26, 2017 10:39 AM > To: Sheng Jiang > Cc: J?ferson Campos Nobre ;=20 > draft-du-anima-an-intent.authors@ietf.org; anima@ietf.org > Subject: Re: [Anima] What is intent ? >=20 > Another aspect to consider: IMHO, industry player/marketeers use the term= "intent" not to describe a particular subset of instructions into the netw= ork but as a term to describe the overall systems operation. >=20 > Eg: Google:=20 > https://static.googleusercontent.com/media/research.google.com/en//pub > s/archive/45687.pdf Intent driven operations, from slide 22 on. >=20 > IMHO Cisco also jumped onto this terminology in its latest intent based n= etworking pitch. >=20 > In this context, intent based networking is simply that the operator=20 > specifies a target > ("intended") state of the network and some "rendering engine(s)" try to c= ontinuously modify the network to match that intended state. Including chan= ges to the network due to failures. > Eg: re-establish services such as BGP speakers on other nodes when curren= t instances fail. >=20 > IMHO: with this notion of intent, it would be perfectly valid to enter an= y type of high or low level declarative and even instructive data into the = network - including my favourite instance of an rfc8049 L3VPN service. The = input into the network has no name in these models. > It is whatever operators put into SDN controllers or workflow engines, or= whatever the tool of the day is called. >=20 > My vision for ANIMA and intent is something like this: >=20 > We come up with a term for everything operators would want to send into= a network. > Lets say we call it "directives". And we can keep the term for everythi= ng the operator > gets out of a network "reporting". >=20 > We structure and define some taxonomy for "directives", eg: "service de= finitions", > "service instances", {user, topology, reliability, performance, acc-con= trol,...}-policies, workflows, > ... >=20 > We describe an architecture how directives are rendered, eg: how the ne= twork is made to > match the directives. Different type of directives may require differe= nt rendering. >=20 > The key difference between existing systems (google, cisco, ..) is that= we define a > hybrid central + distributed rendering architecture: >=20 > draft-du-anima-intent IMHO would be the basis for the distributed rende= ring: This is > used whenever there are self-rendering autonomic functions (aka: a grou= p of ASA > that know how to render directives). >=20 > Even for central rendering there are no well established standards. Tha= t too IMHO would be > worth looking at. Maybe some other IETF WG would like to do this as wel= l, which would be fine > too, as long as we allow this option in ANIMA as well. >=20 > The word intent does not happen in these definitions, and we are totally = free to decide later if we call the whole system "intent based", or iwf we = call all of the directives or just a subset of the directives "intent". >=20 > I am not sure if we would still want to take this step for the reference = model. For me it would be fine not to change reference model at all, and ta= ke the step above afterwards. > Its afer all not really a functional change to what we describe in the re= ference model, but really only a refinemenet and then renaming to match evo= lving industry terminologies. >=20 > Cheers > Toerless >=20 > P.S.: I would have gone for "Objectives" instead of "Directives", but th= at word is already occupied by GRASP and reuse would IMHO be confusing... >=20 > In-Reply-To:=20 > <5D36713D8A4E7348A7E10DF7437A4B927CE3A55E@NKGEML515-MBX.china.huawei.c > om> >=20 > On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote: > > Hi, Toerless, Brian & Jeferson, > >=20 > > Please see my replies in line with quotas from you. > >=20 > > Toerless> Other folks in the IETF clearly think that a service=20 > > Toerless> definition is NOT intent, but > > > intent can only be some yet unclear high level policy. If thats=20 > > > the prevailing opinion/wisdom in the IETF, then IMHO we need to be=20 > > > more explicit about the fact that Intent is not the only input=20 > > > into the network but that there is also other input. Such as=20 > > > services. And anything else that people do not want to call Intent. > >=20 > > I prefer such distinguish definitions. Intent itself does not have a cl= ear definition. It does not a clear role in Autonomic network either. This = word has been abused a lot. If we cannot reach consensus on its semantics. = It may be wise to give up it and choose more precise terminologies. > >=20 > > Toerless>I think that draft-du-anima-an-intent would equally > > > apply to all information we would want to distribute into an=20 > > > autonomic network. > > Jeferson>I believe this could be addressed in draft-du-anima-an-intent. > >=20 > > As a co-author of this draft, I also think we have a very good base alr= eady. However, we may need to rename the document in order to avoid the too= -hot term "intent". > >=20 > > Brian>we could spend another 6 months discussing how to know Intent whe= n we see it. But I would prefer that to happen in NMRG. > > Jeferson>I agree with Brian, the intent "philosophical" discussion fits= better the NMRG. > >=20 > > This suggestion is actually very pragmatic. Let's focus on these concre= te and generic solutions first. > >=20 > > Regards, > >=20 > > Sheng > >=20 > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E=20 > > > Carpenter > > > Sent: Wednesday, July 26, 2017 7:05 AM > > > To: Toerless Eckert; anima@ietf.org > > > Subject: Re: [Anima] What is intent ? > > >=20 > > > Distribution trimmed to Anima: > > >=20 > > > Whenever I've asked "Is X Intent?", I've usually been told "No"=20 > > > except for cases where X is too abstract to interpret algorithmically= . > > >=20 > > > But in practice, I believe that many ASAs will need instructions=20 > > > from the NOC to modify their default behaviour. I don't care what=20 > > > we call those instructions; for the prefix management use case we jus= t called them "parameters". > > >=20 > > > So maybe Anima should focus on parameter distribution more than on=20 > > > Intent. I think that's the point of draft-liu-anima-grasp-distributio= n. > > > A fairly simple change to the wording of draft-du-anima-an-intent=20 > > > would adapt it to generic parameter distribution. > > >=20 > > > Converting abstract Intent to concrete parameters can be=20 > > > completely separate from this, and could well be a centralised operat= ion. > > >=20 > > > Or we could spend another 6 months discussing how to know Intent=20 > > > when we see it. But I would prefer that to happen in NMRG. > > >=20 > > > Regards > > > Brian > > >=20 > > > On 26/07/2017 08:34, Toerless Eckert wrote: > > > > I have an autonomic network, and i want for another customer=20 > > > > another L3VPN service instance in it. How would i tell the=20 > > > > network that i want this ? Via intent or via something else ? > > > > > > > > If it is something else, what is it ? I do not see any other=20 > > > > information flow from operator to network beside intent in=20 > > > > RFC7575 or > > > draft-ietf-anima-reference-model. > > > > Maybe i am missing something. > > > > > > > > If it is intent, how would it look like ? Could it simply be a=20 > > > > definition of an L3VPN service instance in the model defined in > > > > rfc8049 ? If not, > > > why not ? > > > > > > > > IMHO: Intent in ANIMA includes service definitions such as what > > > > rfc8049 is, except that we would reserve the right to eliminate=20 > > > > all parameters of rfc8049 for which we figure out autonomic ways=20 > > > > to determine them. Which alas seems to be quite difficult for most = parameters. > > > > > > > > Other folks in the IETF clearly think that a service definition=20 > > > > is NOT intent, but intent can only be some yet unclear high=20 > > > > level policy. If thats the prevailing opinion/wisdom in the=20 > > > > IETF, then IMHO we need to be more explicit about the fact that=20 > > > > Intent is not the only input into the network but that there is=20 > > > > also other input. Such as services. And anything else that people d= o not want to call Intent. > > > > > > > > Lets assume service and other necessary data operator->network=20 > > > > should not be called intent. But lets say the superset of intent=20 > > > > + services + everything else is called eg: "information". I=20 > > > > think that draft-du-anima-an-intent would equally apply to all=20 > > > > information we would want to distribute into an autonomic network. > > > > > > > > Cheers > > > > Toerless > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > >=20 > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima >=20 > -- > --- > tte@cs.fau.de >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 26 13:17:24 2017 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 BA23412942F for ; Wed, 26 Jul 2017 13:17:22 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNb3AwSsrYJl for ; Wed, 26 Jul 2017 13:17:20 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94565124234 for ; Wed, 26 Jul 2017 13:17:20 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id c184so88188160wmd.0 for ; Wed, 26 Jul 2017 13:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=UnOCX7VeDdY8i6ucYsFonkRvPCW3UiJLdkZtxpIMJGs=; b=PoOkna9Yo52xazd2BrYsdiJ29qvAHlgMyy6qF40w6Dr3gVfFXD1FhfAhSaAG0t2d0e vzWOLzG350vfWFrmrcI8Io44o9IS68r0l0d1dXsQTTgipFpRsU5aBCF2nTsoxx8wEf/z sau60ZmoYWNADcpqbh66UnqY5k+usJCsoYqxaNiVwGceJzdwfVV5eqRsieCb4UwW2fGu TMs2k1A6T7Fc4fIO+qHdnVo0Qkl16Neg48etWeCQdzVwF0LPB6eWzi7o0dnMXoPr6LhO betamwgo8+yhS9Wmz7fq5josGeQphoIL7RsG2TJ9iaZoa7uXzB0E0I2brjd6fSTkjyOl DZQQ== 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:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UnOCX7VeDdY8i6ucYsFonkRvPCW3UiJLdkZtxpIMJGs=; b=CAUffr81byWrg+N3CmCC8uKyXikfs4RVDR8Xuign1Zh4cwJvqT6U5kqTLf3XpVyYOa hLwV/wn9pmvAvEKMHckJM31glLqnhBt/9WLSPHqbKsQ2ivBDfZUZgyYt6beUjyzzH14x 9KMq22cgoxCumVTnrdxS2xCuIS6LxL2UIMa36dqJjTCosxGZ3iC4d6KltfSi4QyW7tMc iPO3QURi/32v8Tcugif9gSz1QVCwm5gJrpqARN+X+ob7lHz3zckc2Qe7OOtyJE2qfawW tNBSqt0wJCfcvrMOkWVmGBwueQX9FCbeELXs1vJyuu4IqrC3DkfFrECPPaCuYc18L0Jw i+Fw== X-Gm-Message-State: AIVw110BzVkjrOrbtU0rjjt28sKg+4E49APxOsofi/6IK0kaK6c3DBrY KMd0EU16GRg0kIT6ec0= X-Received: by 10.28.148.148 with SMTP id w142mr1688363wmd.55.1501100238778; Wed, 26 Jul 2017 13:17:18 -0700 (PDT) Received: from [192.168.1.25] (ANice-652-1-131-208.w83-201.abo.wanadoo.fr. [83.201.82.208]) by smtp.gmail.com with ESMTPSA id j29sm2443138wrb.9.2017.07.26.13.17.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 13:17:18 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: <8DA547FB1280754AAC43A3E56DCB7AD20AEC33E8@lhreml501-mbx> Message-ID: Date: Wed, 26 Jul 2017 22:17:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AEC33E8@lhreml501-mbx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Archived-At: Subject: Re: [Anima] Review draft-ietf-anima-reference-model-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 20:17:23 -0000 Thanks for your comments, Artur. I'm in the middle of vacations, but=20 will incorporate your comments when back, in the next version! Brian, seen your response, too. Will catch up... Michael On 26/07/17 19:55, Artur Hecker wrote: > Dear community, dear Authors, > > > I reread the draft-ietf-anima-reference-model-04. I hope it's not arriv= ing at an inappropriate moment, but please find some notes and remarks be= low: > > > 1. Page 6: s/potentiall/potential > > 2. Page 8: Section 4. The text mentions "must implement" and "other" fu= nctions, but fails to correctly guide the reader as to the MUST or not MU= ST of the functions in the following subsections. It is partly not even c= lear from the semantics of the subsections. > > Suggestion: clearly group MUST, SHOULD and MAY IMPLEMENT functions in t= he subsections. > > 3. Page 12: Information Distribution - consider rewriting parts of this= section entirely. Several problems: > > a) Remove repetitive text in the beginning: > "Certain forms of information, such as Intent, must be distributed acro= ss an autonomic domain. The distribution of information is also a functio= n of the Autonomic Control Plane. One form of such information is Intent= =2E" > > Suggestion: Either remove the first inclusion, or the entire last sente= nce. I would rewrite these three, see next point: > > b) There seems to be a problem with the statement above, as the "must" = is somehow misleading in a potentially normative text. What is meant here= is that some information requires dissemination, while other might not r= equire that. > > Suggestion - please REWRITE e.g. as follows: > "Certain forms of information require per its nature distribution acros= s a (part of) autonomic domain. Such information distribution is a functi= on of the Autonomic Control Plane. As an example, Intents require distrib= ution across the whole autonomic domain as per definitions from RFC7575."= > > c) Later, the text in this section somehow confuses the high level requ= irements (=3Dinformation distribution) with a specific implementation, no= tably flooding. Note that there is a subtle difference between the requir= ement to reach all recipients (indeed, the current text seems to equal fl= ooding to that) and flooding, which technically usually means "unconstrai= ned broadcast". [E.g. Wikipedia: "Flooding is a simple computer network r= outing algorithm in which every incoming packet is sent through every out= going link except the one it arrived on"]. This will lead to explosive me= ssage number growth, as the ACP uses routing - which does not guarantee a= tree structure - while the scale of an autonomic domain is, by definitio= ns of RFC7575, only constrained by the Intent as such ("the autonomic dom= ain is the set of nodes, to which the intent needs to be sent"). At the s= ame time, there are better known algorithms for routing, which achieve "d= istribution to all recipients" without "sending on al > l links except the one it arrived on" (e.g. structured broadcast, etc= ). > > Suggestion: stay at the requirements level in the Reference text, which= this draft represents. In other words, remove suggestions of implementat= ions, or reword if the requirement to reach all nodes is meant. > > 4. Page 17, Section 6.3.3. The Information Distribution ASA (*). > While the text above (on page 12: Information Distribution) says that I= nformation Distribution is function of ACP, somehow there is a distinct s= ection in this draft, talking about an Information Distribution ASA, whic= h is NOT ACP ASA, and which is not obligatory. > > How to read this correctly? > > 5. Page 17, Section 7.1: "How an AN Network Is Managed" > a) Please consider changing the title. AN is "autonomic network" networ= k network :-) > b) The first paragraph says that the co-existence is twofold. However, = I can think of at least one other way: the ACP could be used as a transpo= rt channel for "traditional" management. E.g. ACP could be used to transp= ort NETCONF messages, instead of SSH or BEEP in NETCONF. Not clear, what = twofold means here (just an example, limitation, strong statement, etc). > > 6. Page 18, Section 7.2: "Intent" > Please reread and correct this phrase: "It is expected Intent definitio= ns from autonomic function(s) and even from traditional network managemen= t elements". (missing verb) > > Later in the text, the section references I-D.liu-anima-grasp-distribut= ion, which is odd, given that the actual Information Distribution section= (see above) does not. Yet, information distribution in I-D.liu-anima-gra= sp-distribution is not limited to intents. > > 7. Page 19, Section 7.5: "Control loops" > The section talks about an "Autonomic System". Unless I am mistaken, an= autonomic system is not defined (e.g. in RFC7575). This is a minor issue= , as we all can imagine what a "system" is. > > 8. Page 20, Section 7.6: "APIs" > There is a strong "MUST" requirement in this section (express and prese= rve semantics across different domains), which is not as clear as a MUST = should be. First, it's not clear what "express and preserve semantics" me= ans (semantics of what? Of objects? Of object methods? Of the results del= ivered by object methods? Of all of them?). Second, the "domain" is not d= efined: is an autonomic domain meant? Note that this notion is dynamic, a= s per intent scope, so probably not a very good reference. Third, the req= uirement is not corroborated clearly. Instead, an example is given, which= we might discuss in its relevance to the ANIMA WG and work scope. Is ANI= MA implementing software contracts? Is it a MUST requirement? Probably no= t. Note that web-based systems today have no such formal specifications, = as mentioned in this section. Example: invariants; these are nice to have= , but hard to determine for any complex piece of software (like a web ser= vice, etc). > > 9. Page 20, Section 7.7: "Data Model" > Question: why do we need this section? This looks like some text book. = Do we have a specification of data model in ANIMA? Information model? Any= thing like that? If not, I guess this can be shortened, as it is "for ref= erence" only. (What is MRACL? Used without explanation in text). > > 10. Page 22, Section 8.1: > s/mechanisms exists/mechanisms exist. > > 11. Page 23, Section 9: "Security Considerations" > Please rephrase "run inside the encrypted ACP". I hope that it's not si= mply "encrypted" but actually features the full range of cryptographic da= ta protection methods. > > Rationale: I would argue that integrity is more important than confiden= tiality in the ANIMA scope. As encryption alone does not provide any prot= ection against modification, and since hopefully the used mechanisms (see= Section 9.2) go beyond encryption, I would recommend to use a more corre= ct wording, something like "protected" or "cryptographically protected AC= P". > > Generally, the section does not sufficiently presents the threat of mes= sage modification and replay, including the discovery messages. Also, aut= hentication is not sufficiently covered, even though a reference to I-D.i= etf-anima-bootstrapping-keyinfra is made. Not sure it's the best approach= , as bootstrapping refers to how to enroll the node, and the authenticati= on is probably using standard mechanisms? Normally, the threats should be= described independently of the specific mechanisms. > > > > Regards > artur > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 26 13:27:59 2017 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 D4278129B7F; Wed, 26 Jul 2017 13:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.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 C5vV4-r7-BiV; Wed, 26 Jul 2017 13:27:54 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 4C32E12942F; Wed, 26 Jul 2017 13:27:54 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 83C4E6C0A05; Wed, 26 Jul 2017 16:27:53 -0400 (EDT) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 70B296C0940; Wed, 26 Jul 2017 16:27:53 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 16:27:53 -0400 Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Wed, 26 Jul 2017 16:27:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WDarWxpRS8AsnuoPYgl39IJ1qIFC2dLvj4w/srXwB9g=; b=WowLVNLXESn0rdMIhc9KHFgr8zy8NYSGZ+N+/sngtzTfATTUloLqJW3yifpHguLNXyVoZZRAVo3COLUDMiNJ5YP16AGiGWbWT+6buMCB30Wtnj9av8mfkfgz+4vOgpM2EczCJK6J3UuxiJTkYxerE/t8a8TFNAB6bbHjMT5jAK0= Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0921.namprd09.prod.outlook.com (10.163.89.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.14; Wed, 26 Jul 2017 20:27:51 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.1304.014; Wed, 26 Jul 2017 20:27:51 +0000 From: "Natale, Bob" To: Alexander Clemm , Toerless Eckert CC: J?ferson Campos Nobre , "anima@ietf.org" , "draft-du-anima-an-intent.authors@ietf.org" , Sheng Jiang Thread-Topic: [Anima] What is intent ? Thread-Index: AQHTBjYQNUmj713ia0SIjHx2HSToP6JmZK+AgAAM2wCAABn1AIAAAT+w Importance: low X-Priority: 5 Date: Wed, 26 Jul 2017 20:27:51 +0000 Message-ID: References: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com> <20170726184250.GC5750@faui40p.informatik.uni-erlangen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAB5C@SJCEML703-CHM.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAB5C@SJCEML703-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org; x-originating-ip: [192.80.55.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0921; 7:r1llfLTJcWtX4d3BWzM5Fe+78CXj8+r1aDd4S8Ohhr0UNI2PxsRs74FuNAGLWHaPfD6v3poJisE4NsPiklay3KjRaMR0uB6g91wD98149dvVisuKxtnH0nVKxOud8jQERUSfLdpt6UZ2xEFh/K94A+A+3ojupzhy0auE2jfJPG+tXTPAPfad+WhkWzaVK/KPKPOMQeAiB4NE6r0u1g94CPdvl0YmV4f2m7S5y/f1FR72EBrl+3u7mSItG8Fz47yrzuGj19NGw6IDuBk6MMN/qKyt97RfCH6uLZnCcJfaUQUZbieG3J8+ohwIZU0nEYW0rNIFPPUVp/NWWU6uJMf2AAd2kokx7ZGz24xZPAS/EqCvtz93UHUabD0veUmMzSHZaT3bLhLwapZxI7927pCGWT0ZuCMRVqRxu0Ufc24eYhgI7dOZiXlaO295NbxIZk4l0SbhH531p4T1Qd4CnFOG04o9o1kKXpK+v/0p6H01DR4HgMTY2vXLmn3STfmbuYHGZRi/64Yf1VFkp/gSRuxTzlvpaSA3FAZh3fqsxvk3EpELrozjooM7yuE+2mzri3xz56a7IWXav1fdSOmaTySXY8pAfnA0/XUBFjDJGhZoO05XzRuhqNwh4aDfSbc9ptVI9s+hvADVtX+12P7rUxFJLhgJAQ9ths/4XJar5hVUvuovuw/GL7L9eQTwicmdzxRQL9CA5IKCIfYh64eUM6NHjGGFWXBjzEXIGONq7zMdI/MArzpeItFL0nulHC+41xbOafdc3AtEw0poSsMCLMrsSxegoIRvBAoH4y8LwxLEP94= x-ms-office365-filtering-correlation-id: 1b814ec0-dd7c-44de-3b5f-08d4d464c9d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0921; x-ms-traffictypediagnostic: CY1PR09MB0921: x-exchange-antispam-report-test: UriScan:(271806183753584)(131327999870524)(50582790962513)(211936372134217)(100405760836317)(179696456005106)(211171220733660)(68840517438536); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(920511095)(920507026)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0921; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0921; x-forefront-prvs: 038002787A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(39400400002)(377454003)(13464003)(24454002)(51444003)(189002)(199003)(7736002)(7696004)(305945005)(8936002)(2900100001)(966005)(74316002)(86362001)(72206003)(53546010)(478600001)(34040400001)(6116002)(102836003)(25786009)(105586002)(106356001)(3846002)(14454004)(77096006)(2906002)(229853002)(6436002)(2950100002)(50986999)(3660700001)(81686999)(54356999)(81156014)(3280700002)(54906002)(53936002)(99286003)(6306002)(68736007)(66066001)(8676002)(101416001)(9686003)(5660300001)(6246003)(76176999)(93886004)(38730400002)(6506006)(4326008)(97736004)(55016002)(81166006)(33656002)(189998001)(156664002)(17260700006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0921; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2017 20:27:51.2517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0921 X-OriginatorOrg: mitre.org X-MITRE: 8GQsMWxq66rxk57w Archived-At: Subject: Re: [Anima] What is intent ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 20:27:58 -0000 I have been a real lurker on this and other ietf work for some time now (da= y job imperatives), so calibrate accordingly ... but I have long been an ad= vocate of intent-based management (by whatever name) and find it easier to = think of it as "mirroring" E/C/A with "G/C/M" ... "Goal / Constraints / Met= rics". That "logical" symmetry helps me understand the standardization prob= lem better, whether private, de facto, or de jure ... just like with events= , conditions, and actions for ECA, we need to agree on the set, expression,= etc., for goals, constraints, and metrics for intent-based management. ("Metrics" would include something like "Min / Max" or "Threshold / Objecti= ve" as applied to the "Goal" element. "Constraints" might often be metrics-= based elements in their own right.) Avanti, BobN -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Alexander Clemm Sent: Wednesday, July 26, 2017 4:16 PM To: Toerless Eckert Cc: J?ferson Campos Nobre ; anima@ietf.org; draft-du-= anima-an-intent.authors@ietf.org; Sheng Jiang Subject: Re: [Anima] What is intent ? OK, so it *is* used like in the subsequent paragraph. ["Intent", on the ot= her hand, would be less specific in terms of what needs to occur, e.g. the = types of actions that need to be taken. Those might be determined non-dete= rministically, potentially through collaborating systems; really the intent= providing more of a desired "range of state" without trying to "program" h= ow to reach or maintain it.] This is then a way to distinguish it. Specify a desired objective, or "ran= ge of state" (whatever state means), without needing to program how that wo= uld actually be accomplished. This is different from a directive, or polic= y defined using E/C/A. Which raises another question in the Anima context= , namely whether it is just "intent" that is needed, or "intent + something= else" (such as policy, directives, etc) Cheers --- Alex -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de] Sent: Wednesday, July 26, 2017 11:43 AM To: Alexander Clemm Cc: Sheng Jiang ; J?ferson Campos Nobre ; draft-du-anima-an-intent.authors@ietf.org; anima@ietf.org Subject: Re: [Anima] What is intent ? On Wed, Jul 26, 2017 at 05:56:49PM +0000, Alexander Clemm wrote: > Maybe "directives" is a good term because less overloaded. Of course, no= w there is one more term that needs to be differentiated from the others th= at came before.=20 >=20 > In my view, "intent" as it is used today really is not much more than a h= igher-level policy. From this perspective, no new term would be needed. =20 But thats not how its used in google/cisco for intent based networking. And= if more industry player catch on to how these compnies use intent very vag= uely, any more specific but contradictory definition we come up with would = just be confusing. Just tell me what in Googles definition is the intent. You saw my interpret= ation in my prior mail. Cheers Toerless > One distinction that one could perhaps make is that a policy is very spec= ific concerning what needs to happen, typically expressed using some kind o= f rule sets based on event/condition/action, containing a well-defined set = of events, conditions, as well as actions that need to occur. So, a policy= , like a directive, is very specific not just about what the network needs = to do but how to do it. =20 > "Intent", on the other hand, would be less specific in terms of what need= s to occur, e.g. the types of actions that need to be taken. Those might b= e determined non-deterministically, potentially through collaborating syste= ms; really the intent providing more of a desired "range of state" without = trying to "program" how to reach or maintain it. So, in that sense it woul= d be very different from a directive. Yes, more of a goal. =20 >=20 > When we first started using the term intent, my view at the time is that = "intent" would be something that the network would have to infer from the o= perator's actions and utterances - an important aspect would be for the net= work to speak the language of the operator, as opposed to the other way aro= und (forcing the operator to speak the network's language). The discussion= of intent languages put that viewpoint to rest, of course. =20 >=20 > --- Alex >=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless=20 > Eckert > Sent: Wednesday, July 26, 2017 10:39 AM > To: Sheng Jiang > Cc: J?ferson Campos Nobre ;=20 > draft-du-anima-an-intent.authors@ietf.org; anima@ietf.org > Subject: Re: [Anima] What is intent ? >=20 > Another aspect to consider: IMHO, industry player/marketeers use the term= "intent" not to describe a particular subset of instructions into the netw= ork but as a term to describe the overall systems operation. >=20 > Eg: Google:=20 > https://static.googleusercontent.com/media/research.google.com/en//pub > s/archive/45687.pdf Intent driven operations, from slide 22 on. >=20 > IMHO Cisco also jumped onto this terminology in its latest intent based n= etworking pitch. >=20 > In this context, intent based networking is simply that the operator=20 > specifies a target > ("intended") state of the network and some "rendering engine(s)" try to c= ontinuously modify the network to match that intended state. Including chan= ges to the network due to failures. > Eg: re-establish services such as BGP speakers on other nodes when curren= t instances fail. >=20 > IMHO: with this notion of intent, it would be perfectly valid to enter an= y type of high or low level declarative and even instructive data into the = network - including my favourite instance of an rfc8049 L3VPN service. The = input into the network has no name in these models. > It is whatever operators put into SDN controllers or workflow engines, or= whatever the tool of the day is called. >=20 > My vision for ANIMA and intent is something like this: >=20 > We come up with a term for everything operators would want to send into= a network. > Lets say we call it "directives". And we can keep the term for everythi= ng the operator > gets out of a network "reporting". >=20 > We structure and define some taxonomy for "directives", eg: "service de= finitions", > "service instances", {user, topology, reliability, performance, acc-con= trol,...}-policies, workflows, > ... >=20 > We describe an architecture how directives are rendered, eg: how the ne= twork is made to > match the directives. Different type of directives may require differe= nt rendering. >=20 > The key difference between existing systems (google, cisco, ..) is that= we define a > hybrid central + distributed rendering architecture: >=20 > draft-du-anima-intent IMHO would be the basis for the distributed rende= ring: This is > used whenever there are self-rendering autonomic functions (aka: a grou= p of ASA > that know how to render directives). >=20 > Even for central rendering there are no well established standards. Tha= t too IMHO would be > worth looking at. Maybe some other IETF WG would like to do this as wel= l, which would be fine > too, as long as we allow this option in ANIMA as well. >=20 > The word intent does not happen in these definitions, and we are totally = free to decide later if we call the whole system "intent based", or iwf we = call all of the directives or just a subset of the directives "intent". >=20 > I am not sure if we would still want to take this step for the reference = model. For me it would be fine not to change reference model at all, and ta= ke the step above afterwards. > Its afer all not really a functional change to what we describe in the re= ference model, but really only a refinemenet and then renaming to match evo= lving industry terminologies. >=20 > Cheers > Toerless >=20 > P.S.: I would have gone for "Objectives" instead of "Directives", but th= at word is already occupied by GRASP and reuse would IMHO be confusing... >=20 > In-Reply-To:=20 > <5D36713D8A4E7348A7E10DF7437A4B927CE3A55E@NKGEML515-MBX.china.huawei.c > om> >=20 > On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote: > > Hi, Toerless, Brian & Jeferson, > >=20 > > Please see my replies in line with quotas from you. > >=20 > > Toerless> Other folks in the IETF clearly think that a service=20 > > Toerless> definition is NOT intent, but > > > intent can only be some yet unclear high level policy. If thats=20 > > > the prevailing opinion/wisdom in the IETF, then IMHO we need to be=20 > > > more explicit about the fact that Intent is not the only input=20 > > > into the network but that there is also other input. Such as=20 > > > services. And anything else that people do not want to call Intent. > >=20 > > I prefer such distinguish definitions. Intent itself does not have a cl= ear definition. It does not a clear role in Autonomic network either. This = word has been abused a lot. If we cannot reach consensus on its semantics. = It may be wise to give up it and choose more precise terminologies. > >=20 > > Toerless>I think that draft-du-anima-an-intent would equally > > > apply to all information we would want to distribute into an=20 > > > autonomic network. > > Jeferson>I believe this could be addressed in draft-du-anima-an-intent. > >=20 > > As a co-author of this draft, I also think we have a very good base alr= eady. However, we may need to rename the document in order to avoid the too= -hot term "intent". > >=20 > > Brian>we could spend another 6 months discussing how to know Intent whe= n we see it. But I would prefer that to happen in NMRG. > > Jeferson>I agree with Brian, the intent "philosophical" discussion fits= better the NMRG. > >=20 > > This suggestion is actually very pragmatic. Let's focus on these concre= te and generic solutions first. > >=20 > > Regards, > >=20 > > Sheng > >=20 > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E=20 > > > Carpenter > > > Sent: Wednesday, July 26, 2017 7:05 AM > > > To: Toerless Eckert; anima@ietf.org > > > Subject: Re: [Anima] What is intent ? > > >=20 > > > Distribution trimmed to Anima: > > >=20 > > > Whenever I've asked "Is X Intent?", I've usually been told "No"=20 > > > except for cases where X is too abstract to interpret algorithmically= . > > >=20 > > > But in practice, I believe that many ASAs will need instructions=20 > > > from the NOC to modify their default behaviour. I don't care what=20 > > > we call those instructions; for the prefix management use case we jus= t called them "parameters". > > >=20 > > > So maybe Anima should focus on parameter distribution more than on=20 > > > Intent. I think that's the point of draft-liu-anima-grasp-distributio= n. > > > A fairly simple change to the wording of draft-du-anima-an-intent=20 > > > would adapt it to generic parameter distribution. > > >=20 > > > Converting abstract Intent to concrete parameters can be=20 > > > completely separate from this, and could well be a centralised operat= ion. > > >=20 > > > Or we could spend another 6 months discussing how to know Intent=20 > > > when we see it. But I would prefer that to happen in NMRG. > > >=20 > > > Regards > > > Brian > > >=20 > > > On 26/07/2017 08:34, Toerless Eckert wrote: > > > > I have an autonomic network, and i want for another customer=20 > > > > another L3VPN service instance in it. How would i tell the=20 > > > > network that i want this ? Via intent or via something else ? > > > > > > > > If it is something else, what is it ? I do not see any other=20 > > > > information flow from operator to network beside intent in > > > > RFC7575 or > > > draft-ietf-anima-reference-model. > > > > Maybe i am missing something. > > > > > > > > If it is intent, how would it look like ? Could it simply be a=20 > > > > definition of an L3VPN service instance in the model defined in > > > > rfc8049 ? If not, > > > why not ? > > > > > > > > IMHO: Intent in ANIMA includes service definitions such as what > > > > rfc8049 is, except that we would reserve the right to eliminate=20 > > > > all parameters of rfc8049 for which we figure out autonomic ways=20 > > > > to determine them. Which alas seems to be quite difficult for most = parameters. > > > > > > > > Other folks in the IETF clearly think that a service definition=20 > > > > is NOT intent, but intent can only be some yet unclear high=20 > > > > level policy. If thats the prevailing opinion/wisdom in the=20 > > > > IETF, then IMHO we need to be more explicit about the fact that=20 > > > > Intent is not the only input into the network but that there is=20 > > > > also other input. Such as services. And anything else that people d= o not want to call Intent. > > > > > > > > Lets assume service and other necessary data operator->network=20 > > > > should not be called intent. But lets say the superset of intent > > > > + services + everything else is called eg: "information". I > > > > think that draft-du-anima-an-intent would equally apply to all=20 > > > > information we would want to distribute into an autonomic network. > > > > > > > > Cheers > > > > Toerless > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > >=20 > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima >=20 > -- > --- > tte@cs.fau.de >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 26 23:54:44 2017 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 E544113204E; Wed, 26 Jul 2017 23:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Hk5pW0RabpUm; Wed, 26 Jul 2017 23:54:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD8F132032; Wed, 26 Jul 2017 23:54:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLJ70142; Thu, 27 Jul 2017 06:54:38 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Jul 2017 07:54:37 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 27 Jul 2017 14:54:24 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Abstracted summary of ANIMA in IETF 99 Thread-Index: AdMGpRPchh/gLJopQTKJtWQEpRiwbQ== Date: Thu, 27 Jul 2017 06:54:23 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CE3AF0A@NKGEML515-MBX.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_5D36713D8A4E7348A7E10DF7437A4B927CE3AF0ANKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59798E2F.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 60e6619722e5d1b5c602921d95d24ca3 Archived-At: Subject: [Anima] Abstracted summary of ANIMA in IETF 99 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 06:54:43 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3AF0ANKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, While the ANIMA minutes is still on the way, the co-chairs do provide a abs= tracted summary of ANIMA session in IETF99. It can be find using the below = link: https://trac.ietf.org/trac/ops/wiki/IETF99summary#ANIMA Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3AF0ANKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

While the ANIMA minutes is stil= l on the way, the co-chairs do provide a abstracted summary of ANIMA sessio= n in IETF99. It can be find using the below link:

 

https://trac.ietf.org/trac/ops/wiki/IE= TF99summary#ANIMA

 

Regards,

 

Sheng

--_000_5D36713D8A4E7348A7E10DF7437A4B927CE3AF0ANKGEML515MBXchi_-- From nobody Thu Jul 27 01:24:16 2017 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 E7CD8131FB7 for ; Thu, 27 Jul 2017 01:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 T8WwqpIuXUsH for ; Thu, 27 Jul 2017 01:24:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8860D131D30 for ; Thu, 27 Jul 2017 01:24:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLJ85927; Thu, 27 Jul 2017 08:24:10 +0000 (GMT) Received: from LHREML501-MBX.china.huawei.com ([10.201.109.49]) by lhreml701-cah.china.huawei.com ([10.201.108.42]) with mapi id 14.03.0301.000; Thu, 27 Jul 2017 09:23:23 +0100 From: Artur Hecker To: "anima@ietf.org" Thread-Topic: [Anima] Review draft-ietf-anima-reference-model-04 Thread-Index: AdL8rftkcbJTFE6DSF+ugNLuguLV7AJlWL8AABtvurA= Date: Thu, 27 Jul 2017 08:23:23 +0000 Message-ID: <8DA547FB1280754AAC43A3E56DCB7AD20AEC35E2@lhreml501-mbx> References: <8DA547FB1280754AAC43A3E56DCB7AD20AEC33E8@lhreml501-mbx> <97e783a6-f738-79e9-1f3f-657bdfa6e33d@gmail.com> In-Reply-To: <97e783a6-f738-79e9-1f3f-657bdfa6e33d@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.211] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5979A32A.00C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0cd535d178612bff049893864ef749d4 Archived-At: Subject: Re: [Anima] Review draft-ietf-anima-reference-model-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 08:24:15 -0000 QnJpYW4sDQoNCg0KVGhhbmtzIGZvciB5b3VyIGFuc3dlci4gR29vZCB0byBrbm93IHRoYXQgR1JB U1AgdGFrZXMgdGhvc2UgcHJlY2F1dGlvbnMsIHZlcnkgZ29vZC4gSXQgd291bGQgYmUgaW50ZXJl c3RpbmcgdG8ga25vdyBob3cgaXQgZG9lcyBpdCAtIHdlIHdpbGwgcHJvYmFibHkgZ2V0IHRvIHRl c3RpbmcgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gYXQgb25lIHBvaW50LCBwbGVhc2UgYmVh ciB3aXRoIHVzIDotKQ0KDQpTdGlsbCwgcmVmZXJyaW5nIHRvIHRoZSBkcmFmdCBpbiB0aGUgZW1h aWwgc3ViamVjdCwgYXMgaXQgaXMgYSByZWZlcmVuY2UgbW9kZWwgd2l0aCByZXF1aXJlbWVudHMg b25seSwgaWYgSSByZWFkIGl0IHN0dXBpZGx5IChsZXR0ZXIgYnkgbGV0dGVyKSB0aGVuIEdSQVNQ IGlzIG5vdCBmbG9vZGluZywgc28gaXQncyBub3QgY29uZm9ybWluZyB0byB0aGUgcmVmZXJlbmNl IG1vZGVsIDotKSAoZGVwZW5kaW5nIG9uIHRoZSBpbnRlcnByZXRhdGlvbiBvZiAiZmxvb2Rpbmci IGluIHRoZSB0ZXh0KS4NCg0KTXkgYWN0dWFsIHBvaW50IGlzIHRoYXQgd2Ugc2hvdWxkIG5vdCBn ZXQgaW50byBpbXBsZW1lbnRhdGlvbnMgaW4gdGhpcyBkcmFmdC4gTWF5YmUgSSBhbSB3cm9uZy4g SSB0aGluayBzb21lIHJld29yZGluZyB3aWxsIGRvIHRoZSB0cmljay4NCg0KDQpSZWdhcmRzDQpB cnR1cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBl bnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0gDQpTZW50OiAyNiBKdWx5 IDIwMTcgMjI6MTQNClRvOiBBcnR1ciBIZWNrZXI7IGFuaW1hQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW0FuaW1hXSBSZXZpZXcgZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwtMDQNCg0K QXJ0dXIsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFdob2V2ZXIgdGFrZXMgdXAgdGhlIGVk aXRpbmcgcGVuIG5leHQgd2lsbCBjZXJ0YWlubHkgdXNlIHlvdXIgY29tbWVudHMuDQoNCk9uIG9u ZSBzcGVjaWZpYyBwb2ludDoNCg0KPiBjKSBMYXRlciwgdGhlIHRleHQgaW4gdGhpcyBzZWN0aW9u IHNvbWVob3cgY29uZnVzZXMgdGhlIGhpZ2ggbGV2ZWwgcmVxdWlyZW1lbnRzICg9aW5mb3JtYXRp b24gZGlzdHJpYnV0aW9uKSB3aXRoIGEgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24sIG5vdGFibHkg Zmxvb2RpbmcuIE5vdGUgdGhhdCB0aGVyZSBpcyBhIHN1YnRsZSBkaWZmZXJlbmNlIGJldHdlZW4g dGhlIHJlcXVpcmVtZW50IHRvIHJlYWNoIGFsbCByZWNpcGllbnRzIChpbmRlZWQsIHRoZSBjdXJy ZW50IHRleHQgc2VlbXMgdG8gZXF1YWwgZmxvb2RpbmcgdG8gdGhhdCkgYW5kIGZsb29kaW5nLCB3 aGljaCB0ZWNobmljYWxseSB1c3VhbGx5IG1lYW5zICJ1bmNvbnN0cmFpbmVkIGJyb2FkY2FzdCIu IFtFLmcuIFdpa2lwZWRpYTogIkZsb29kaW5nIGlzIGEgc2ltcGxlIGNvbXB1dGVyIG5ldHdvcmsg cm91dGluZyBhbGdvcml0aG0gaW4gd2hpY2ggZXZlcnkgaW5jb21pbmcgcGFja2V0IGlzIHNlbnQg dGhyb3VnaCBldmVyeSBvdXRnb2luZyBsaW5rIGV4Y2VwdCB0aGUgb25lIGl0IGFycml2ZWQgb24i XS4gVGhpcyB3aWxsIGxlYWQgdG8gZXhwbG9zaXZlIG1lc3NhZ2UgbnVtYmVyIGdyb3d0aCwgYXMg dGhlIEFDUCB1c2VzIHJvdXRpbmcgLSB3aGljaCBkb2VzIG5vdCBndWFyYW50ZWUgYSB0cmVlIHN0 cnVjdHVyZSAtIHdoaWxlIHRoZSBzY2FsZSBvZiBhbiBhdXRvbm9taWMgZG9tYWluIGlzLCBieSBk ZWZpbml0aW9ucyBvZiBSRkM3NTc1LCBvbmx5IGNvbnN0cmFpbmVkIGJ5IHRoZSBJbnRlbnQgYXMg c3VjaCAoInRoZSBhdXRvbm9taWMgZG9tYWluIGlzIHRoZSBzZXQgb2Ygbm9kZXMsIHRvIHdoaWNo IHRoZSBpbnRlbnQgbmVlZHMgdG8gYmUgc2VudCIpLiBBdCB0aGUgc2FtZSB0aW1lLCB0aGVyZSBh cmUgYmV0dGVyIGtub3duIGFsZ29yaXRobXMgZm9yIHJvdXRpbmcsIHdoaWNoIGFjaGlldmUgImRp c3RyaWJ1dGlvbiB0byBhbGwgcmVjaXBpZW50cyIgd2l0aG91dCAic2VuZGluZyBvbiBhbGwgbGlu a3MgZXhjZXB0IHRoZSBvbmUgaXQgYXJyaXZlZCBvbiIgKGUuZy4gc3RydWN0dXJlZCBicm9hZGNh c3QsIGV0YykuDQoNCkkgYWdyZWUgaW4gZ2VuZXJhbDsgdGhlIHdheSB0aGUgdGV4dCB1c2VzICJm bG9vZCIgaXMgY2FyZWxlc3MuIEhvd2V2ZXIsIHRoZSBHUkFTUCBmbG9vZGluZyBtZWNoYW5pc20g aXMgKGEpIG9mIGNvdXJzZSBsaW1pdGVkIHRvIEdSQVNQIG5vZGVzIGFuZCAoYikgY29udGFpbnMg c3BlY2lmaWMgbWVhc3VyZXMgdG8gcHJ1bmUgdGhlIGRpc3RyaWJ1dGlvbiBhbmQgcHJldmVudCBs b29wcy4gV2hpbGUgdGhhdCBkb2VzIG5vdCBndWFyYW50ZWUgYSBzdHJpY3QgdHJlZSBzdHJ1Y3R1 cmUsIGkuZS4gaXMgbm90IGFuIGlkZWFsaXNlZCBtdWx0aWNhc3Qgcm91dGluZyBhbGdvcml0aG0s IGl0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgQUNQIHRvIHN1cHBvcnQgbXVsdGljYXN0IHJvdXRpbmcg YW5kIGl0IGlzIHdlbGwgYWRhcHRlZCB0byBsb3ctZnJlcXVlbmN5IGluZm9ybWF0aW9uIGRpc3Ry aWJ1dGlvbiBhcyB3ZSBleHBlY3QgaW4gYW4gQU4uIA0KDQpSZWdhcmRzDQogICBCcmlhbg0K From nobody Thu Jul 27 11:31:19 2017 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 956841320B5; Thu, 27 Jul 2017 11:31:17 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150118027755.11607.1131889235559055046@ietfa.amsl.com> Date: Thu, 27 Jul 2017 11:31:17 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 18:31:18 -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 : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-04.txt Pages : 19 Date : 2017-07-27 Abstract: OAM (Operations, Administration and Maintenance - as per BCP161, [RFC6291]) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability may not be easy to be automated either because of ongoing connectivity requirements for the OAM, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM with the autonomic control plane (ACP) in Autonomic Networks (AN) to provide stable and secure connectivity for conducting OAM. This connectivity is not subject to aforementioned circular dependencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-04 https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 27 11:52:01 2017 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 6C22E129AC4; Thu, 27 Jul 2017 11:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 4erzCDiiGpBm; Thu, 27 Jul 2017 11:51:58 -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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B791320D9; Thu, 27 Jul 2017 11:51:54 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A146D58C4BC; Thu, 27 Jul 2017 20:51:50 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8D586B0C6ED; Thu, 27 Jul 2017 20:51:50 +0200 (CEST) Date: Thu, 27 Jul 2017 20:51:50 +0200 From: Toerless Eckert To: mohamed.boucadair@orange.com Cc: anima@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org Message-ID: <20170727185150.GZ3889@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] review comments draft-ietf-anima-stable-connectivity-03-rev Med.doc X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 18:52:00 -0000 Thanks a lot, Mohamed for the thorough review! I pushed -04 of the draft out with your changes incorporated. IMHO it's all great textual improvements but no logical changes, aka: should be fine for prior reviewers. Diff: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-03.txt&url2=https://www.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt Your original review doc: https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-ietf-anima-stable-connectivity/03-review-mohamed.boucadair.doc My reply comments: https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-ietf-anima-stable-connectivity/03-review-mohamed.boucadair-reply.txt While incorporating your review, i also figured that it would be good if ACP connect would allow auto-configuration of NMS hosts, so i added a paragraph to mandate RFC4191, but i didn't rev ACP draft just for that yet, so here's just diff on github for that; http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/af74117400b6a5a7fca1acf2ab910d64a580a5c9/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Cheers Toerless On Mon, Jul 24, 2017 at 05:49:07AM +0000, mohamed.boucadair@orange.com wrote: > Dear Toreless, > > I'm resending this document as I didn't receive an ACK from your side. > > Please consider those as part of the WGLC comments. > > Cheers, > Med > > > -----Message d'origine----- > > De : BOUCADAIR Mohamed IMT/OLN > > Envoyé : vendredi 7 juillet 2017 14:58 > > À : 'tte+ietf@cs.fau.de' > > Objet : Envoi d?un message : draft-ietf-anima-stable-connectivity-03-rev > > Med.doc > > > > Dear Toreless, > > > > Please find some comments about this draft. > > > > Cheers, > > Med From nobody Thu Jul 27 11:52:20 2017 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 4BD671320D9 for ; Thu, 27 Jul 2017 11:52:19 -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, RP_MATCHES_RCVD=-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 saDp3uvOqV3V for ; Thu, 27 Jul 2017 11:52:17 -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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC3B1320E6 for ; Thu, 27 Jul 2017 11:52:11 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 780F758C4F5 for ; Thu, 27 Jul 2017 20:52:07 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 66BEBB0C6ED; Thu, 27 Jul 2017 20:52:07 +0200 (CEST) Resent-From: Toerless Eckert Resent-Date: Thu, 27 Jul 2017 20:52:07 +0200 Resent-Message-ID: <20170727185207.GA3889@faui40p.informatik.uni-erlangen.de> Resent-To: anima@ietf.org X-Original-To: eckert+anima@i4.informatik.uni-erlangen.de Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 08F8058C4F7 for ; Thu, 27 Jul 2017 20:31:22 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 5359774D06C for ; Thu, 27 Jul 2017 20:31:19 +0200 (CEST) Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1665D1320C9; Thu, 27 Jul 2017 11:31:18 -0700 (PDT) X-Original-To: anima-chairs@ietf.org Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C800C1320C5; Thu, 27 Jul 2017 11:31:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Toerless Eckert" , "Michael H. Behringer" , "Michael Behringer" , X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150118027781.11607.18196133757405981636.idtracker@ietfa.amsl.com> Date: Thu, 27 Jul 2017 11:31:17 -0700 Resent-From: Resent-To: tte+anima@cs.fau.de, jiangsheng@huawei.com Resent-Message-Id: <20170727183118.1665D1320C9@ietfa.amsl.com> Resent-Date: Thu, 27 Jul 2017 11:31:18 -0700 (PDT) X-Virus-Scanned: clamav-milter 0.99.2 at faui45 X-Virus-Status: Clean Archived-At: Subject: [Anima] New Version Notification for draft-ietf-anima-stable-connectivity-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 18:52:19 -0000 A new version of I-D, draft-ietf-anima-stable-connectivity-04.txt has been successfully submitted by Toerless Eckert and posted to the IETF repository. Name: draft-ietf-anima-stable-connectivity Revision: 04 Title: Using Autonomic Control Plane for Stable Connectivity of Network OAM Document date: 2017-07-27 Group: anima Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-stable-connectivity-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ Htmlized: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-04 Abstract: OAM (Operations, Administration and Maintenance - as per BCP161, [RFC6291]) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability may not be easy to be automated either because of ongoing connectivity requirements for the OAM, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM with the autonomic control plane (ACP) in Autonomic Networks (AN) to provide stable and secure connectivity for conducting OAM. This connectivity is not subject to aforementioned circular dependencies. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 27 15:34:24 2017 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 8EBC81321E0 for ; Thu, 27 Jul 2017 15:34:22 -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 AdbRYKLcUrGh for ; Thu, 27 Jul 2017 15:34:20 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A611321D2 for ; Thu, 27 Jul 2017 15:34:20 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e75so10340553pfj.2 for ; Thu, 27 Jul 2017 15:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uWzUicyPXbwbRfcMXPWeHIDhcHcv1ey8TR1Al/Ot8MU=; b=Iy+orPt0C4pMQHH6FrcoeJ3aZuRBQkTSNHcByHrR75lnMeUGfZS3xFcBifIT2K0yzB +EY7YN5Y2/D9zXfYFUFXqoi2XEowHlnwN75awh5PBSpl5t12gm7X4F8CDkuOBQOTq4Bp YH3bD/N+7p2QHtjpQwcZUDfpP7D4B1LuSDDgW8WFvmPMWufCSTlpVwvFf7OUdllLBRZv 9nggyye9cw3SLWsaHHF/Lp7rblxtJ6ZHZJTuP/cWtUDRsSRbYCpm2lKeKbuKUvrteyv+ 2Nmh6UiQ/lPxfzItWi+ldJfj/Q+nXWRcdpkyQ6+rGGGy4QQYMs37ZwcLzTNPH7Rw5FXF 9hTg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uWzUicyPXbwbRfcMXPWeHIDhcHcv1ey8TR1Al/Ot8MU=; b=Oc90vXnV6//Tyiv41j+Z3DRxC3BldJaWRERi6vuz/8+67/MX/Xf9YwJiUpEv8dv4eX ekOTkcF35lpzJ1ttSOGMcmA00OxhwE5aJDc+KzpCpPuzDX1xNwMicUG5drECgp9410o0 KT3ggnnF75TXpjONKUeYi8xvfFzsbSo84iS70k8FGdUf1te6OVcWOvGGRa96HkLx+18n 6xgEM5UYQDkknyMdclIuxd3ST7es9Tg/Z1fOA7WkdThCKbaHvhxp9j9qSRrq5nove+PA WdrPoCOAgyh02zn/rmUeXm0KqAv1i3bGsq8JW1zDW0Z+g4+HWHOB34eTn+lFv5iUQrER p3bw== X-Gm-Message-State: AIVw111LMo9NFE+A2d/pe4mdcEkaVgg04MTmrpsCOtDf4vjD8BQ7PeMn KdF16d9v9IyHX8Ge X-Received: by 10.98.7.204 with SMTP id 73mr5497212pfh.110.1501194859443; Thu, 27 Jul 2017 15:34:19 -0700 (PDT) Received: from ?IPv6:2406:e007:4beb:1:28cc:dc4c:9703:6781? ([2406:e007:4beb:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n129sm31957897pfn.27.2017.07.27.15.34.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 15:34:18 -0700 (PDT) To: anima@ietf.org References: <8DA547FB1280754AAC43A3E56DCB7AD20AEC33E8@lhreml501-mbx> <97e783a6-f738-79e9-1f3f-657bdfa6e33d@gmail.com> <8DA547FB1280754AAC43A3E56DCB7AD20AEC35E2@lhreml501-mbx> From: Brian E Carpenter Organization: University of Auckland Message-ID: <196be55a-4a69-8b00-91e6-c36069b8781d@gmail.com> Date: Fri, 28 Jul 2017 08:44:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AEC35E2@lhreml501-mbx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Anima] Review draft-ietf-anima-reference-model-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 22:34:23 -0000 T24gMjcvMDcvMjAxNyAyMDoyMywgQXJ0dXIgSGVja2VyIHdyb3RlOg0KPiBCcmlhbiwNCj4g DQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgYW5zd2VyLiBHb29kIHRvIGtub3cgdGhhdCBHUkFT UCB0YWtlcyB0aG9zZSBwcmVjYXV0aW9ucywgdmVyeSBnb29kLiBJdCB3b3VsZCBiZSBpbnRl cmVzdGluZyB0byBrbm93IGhvdyBpdCBkb2VzIGl0IC0gd2Ugd2lsbCBwcm9iYWJseSBnZXQg dG8gdGVzdGluZyB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBhdCBvbmUgcG9pbnQsIHBs ZWFzZSBiZWFyIHdpdGggdXMgOi0pDQo+IA0KPiBTdGlsbCwgcmVmZXJyaW5nIHRvIHRoZSBk cmFmdCBpbiB0aGUgZW1haWwgc3ViamVjdCwgYXMgaXQgaXMgYSByZWZlcmVuY2UgbW9kZWwg d2l0aCByZXF1aXJlbWVudHMgb25seSwgaWYgSSByZWFkIGl0IHN0dXBpZGx5IChsZXR0ZXIg YnkgbGV0dGVyKSB0aGVuIEdSQVNQIGlzIG5vdCBmbG9vZGluZywgc28gaXQncyBub3QgY29u Zm9ybWluZyB0byB0aGUgcmVmZXJlbmNlIG1vZGVsIDotKSAoZGVwZW5kaW5nIG9uIHRoZSBp bnRlcnByZXRhdGlvbiBvZiAiZmxvb2RpbmciIGluIHRoZSB0ZXh0KS4NCg0KMSkgVGhlIG9i amVjdGl2ZXMgaW4gR1JBU1AgTV9GTE9PRCAob3IgTV9ESVNDT1ZFUlkpIG1lc3NhZ2VzIGNh cnJ5IGEgbG9vcCBjb3VudCB0aGF0DQpkZWNyZWFzZXMgYXQgZWFjaCBob3AsIHdpdGggYSBz dWdnZXN0ZWQgZGVmYXVsdCBpbml0aWFsIHZhbHVlIG9mIDYsIGJ1dCBvZiBjb3Vyc2UgdGhh dA0KbWlnaHQgYmUgbGFyZ2VyIGluIGEgbGFyZ2UgbmV0d29yay4NCg0KMikgTm9kZXMgdGhh dCByZWxheSBNX0ZMT09EIG9yIChNX0RJU0NPVkVSWSkgbXVzdCBjYWNoZSB0aGUgc2Vzc2lv biBJRCBhbmQgbXVzdA0Kbm90IHJlbGF5IG1lc3NhZ2VzIHdpdGggdGhlIHNhbWUgY2FjaGVk IHNlc3Npb24gSUQgYWdhaW4gKHdpdGhpbiB0aGUgY2FjaGUgbGlmZXRpbWUsDQpvYnZpb3Vz bHkpLg0KDQozKSBOb2RlcyBtdXN0IGxpbWl0IHRoZSByYXRlIG9mIHJlbGF5aW5nLiAoVGhp cyBpcyBub3QgaW1wbGVtZW50ZWQgaW4gbXkNCnByb3RvdHlwZSwgZHVlIHRvIGxhemluZXNz LiBCdXQgdGhlIHR3byBwcmV2aW91cyBwb2ludHMgYXJlIGVub3VnaCB0byBwcmV2ZW50DQps b29wcyBpbiBhbnkgdG9wb2xvZ3kuKQ0KIA0KPiBNeSBhY3R1YWwgcG9pbnQgaXMgdGhhdCB3 ZSBzaG91bGQgbm90IGdldCBpbnRvIGltcGxlbWVudGF0aW9ucyBpbiB0aGlzIGRyYWZ0LiBN YXliZSBJIGFtIHdyb25nLiBJIHRoaW5rIHNvbWUgcmV3b3JkaW5nIHdpbGwgZG8gdGhlIHRy aWNrLg0KDQpBZ3JlZWQuDQoNCiAgICBCcmlhbg0KDQo+IA0KPiANCj4gUmVnYXJkcw0KPiBB cnR1cg0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJy aWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSAN Cj4gU2VudDogMjYgSnVseSAyMDE3IDIyOjE0DQo+IFRvOiBBcnR1ciBIZWNrZXI7IGFuaW1h QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIFJldmlldyBkcmFmdC1pZXRmLWFu aW1hLXJlZmVyZW5jZS1tb2RlbC0wNA0KPiANCj4gQXJ0dXIsDQo+IA0KPiBUaGFua3MgZm9y IHlvdXIgcmV2aWV3LiBXaG9ldmVyIHRha2VzIHVwIHRoZSBlZGl0aW5nIHBlbiBuZXh0IHdp bGwgY2VydGFpbmx5IHVzZSB5b3VyIGNvbW1lbnRzLg0KPiANCj4gT24gb25lIHNwZWNpZmlj IHBvaW50Og0KPiANCj4+IGMpIExhdGVyLCB0aGUgdGV4dCBpbiB0aGlzIHNlY3Rpb24gc29t ZWhvdyBjb25mdXNlcyB0aGUgaGlnaCBsZXZlbCByZXF1aXJlbWVudHMgKD1pbmZvcm1hdGlv biBkaXN0cmlidXRpb24pIHdpdGggYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiwgbm90YWJs eSBmbG9vZGluZy4gTm90ZSB0aGF0IHRoZXJlIGlzIGEgc3VidGxlIGRpZmZlcmVuY2UgYmV0 d2VlbiB0aGUgcmVxdWlyZW1lbnQgdG8gcmVhY2ggYWxsIHJlY2lwaWVudHMgKGluZGVlZCwg dGhlIGN1cnJlbnQgdGV4dCBzZWVtcyB0byBlcXVhbCBmbG9vZGluZyB0byB0aGF0KSBhbmQg Zmxvb2RpbmcsIHdoaWNoIHRlY2huaWNhbGx5IHVzdWFsbHkgbWVhbnMgInVuY29uc3RyYWlu ZWQgYnJvYWRjYXN0Ii4gW0UuZy4gV2lraXBlZGlhOiAiRmxvb2RpbmcgaXMgYSBzaW1wbGUg Y29tcHV0ZXIgbmV0d29yayByb3V0aW5nIGFsZ29yaXRobSBpbiB3aGljaCBldmVyeSBpbmNv bWluZyBwYWNrZXQgaXMgc2VudCB0aHJvdWdoIGV2ZXJ5IG91dGdvaW5nIGxpbmsgZXhjZXB0 IHRoZSBvbmUgaXQgYXJyaXZlZCBvbiJdLiBUaGlzIHdpbGwgbGVhZCB0byBleHBsb3NpdmUg bWVzc2FnZSBudW1iZXIgZ3Jvd3RoLCBhcyB0aGUgQUNQIHVzZXMgcm91dGluZyAtIHdoaWNo IGRvZXMgbm90IGd1YXJhbnRlZSBhIHRyZWUgc3RydWN0dXJlIC0gd2hpbGUgdGhlIHNjYWxl IG9mIGFuIGF1dG9ub21pYyBkb21haW4gaXMsIGJ5IGRlZmluaXRpb25zIG9mIFJGQzc1NzUs IG9ubHkgY29uc3RyYWluZWQgYnkgdGhlIEludGVudCBhcyBzdWNoICgidGhlIGF1dG9ub21p YyBkb21haW4gaXMgdGhlIHNldCBvZiBub2RlcywgdG8gd2hpY2ggdGhlIGludGVudCBuZWVk cyB0byBiZSBzZW50IikuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXJlIGFyZSBiZXR0ZXIga25v d24gYWxnb3JpdGhtcyBmb3Igcm91dGluZywgd2hpY2ggYWNoaWV2ZSAiZGlzdHJpYnV0aW9u IHRvIGFsbCByZWNpcGllbnRzIiB3aXRob3V0ICJzZW5kaW5nIG9uIA0KPiAgYWxsIGxpbmtz IGV4Y2VwdCB0aGUgb25lIGl0IGFycml2ZWQgb24iIChlLmcuIHN0cnVjdHVyZWQgYnJvYWRj YXN0LCBldGMpLg0KPiANCj4gSSBhZ3JlZSBpbiBnZW5lcmFsOyB0aGUgd2F5IHRoZSB0ZXh0 IHVzZXMgImZsb29kIiBpcyBjYXJlbGVzcy4gSG93ZXZlciwgdGhlIEdSQVNQIGZsb29kaW5n IG1lY2hhbmlzbSBpcyAoYSkgb2YgY291cnNlIGxpbWl0ZWQgdG8gR1JBU1Agbm9kZXMgYW5k IChiKSBjb250YWlucyBzcGVjaWZpYyBtZWFzdXJlcyB0byBwcnVuZSB0aGUgZGlzdHJpYnV0 aW9uIGFuZCBwcmV2ZW50IGxvb3BzLiBXaGlsZSB0aGF0IGRvZXMgbm90IGd1YXJhbnRlZSBh IHN0cmljdCB0cmVlIHN0cnVjdHVyZSwgaS5lLiBpcyBub3QgYW4gaWRlYWxpc2VkIG11bHRp Y2FzdCByb3V0aW5nIGFsZ29yaXRobSwgaXQgZG9lc24ndCByZXF1aXJlIHRoZSBBQ1AgdG8g c3VwcG9ydCBtdWx0aWNhc3Qgcm91dGluZyBhbmQgaXQgaXMgd2VsbCBhZGFwdGVkIHRvIGxv dy1mcmVxdWVuY3kgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uIGFzIHdlIGV4cGVjdCBpbiBh biBBTi4gDQo+IA0KPiBSZWdhcmRzDQo+ICAgIEJyaWFuDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFuaW1hIG1haWxpbmcgbGlzdA0K PiBBbmltYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FuaW1hDQo+IA0K From nobody Fri Jul 28 05:02:32 2017 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 2F2CD131FC8; Fri, 28 Jul 2017 05:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwZt56heiS83; Fri, 28 Jul 2017 05:02:28 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CDE12783A; Fri, 28 Jul 2017 05:02:28 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 98335C04E7; Fri, 28 Jul 2017 14:02:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 66347120055; Fri, 28 Jul 2017 14:02:26 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0352.000; Fri, 28 Jul 2017 14:02:26 +0200 From: To: Toerless Eckert CC: "anima@ietf.org" , "draft-ietf-anima-stable-connectivity@ietf.org" Thread-Topic: review comments draft-ietf-anima-stable-connectivity-03-rev Med.doc Thread-Index: AQHTBwlq4p6dbunGJUaeYa4krab8d6JpH4XA Date: Fri, 28 Jul 2017 12:02:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A014351@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20170727185150.GZ3889@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170727185150.GZ3889@faui40p.informatik.uni-erlangen.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] review comments draft-ietf-anima-stable-connectivity-03-rev Med.doc X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jul 2017 12:02:30 -0000 Hi Toerless,=20 The new version looks much more better. Thanks.=20 Some comments about these two minor point: - "IPv4 to IPv6 NAT can be used." - Do you mean RFC7915 I intentionally did not want to elaborate on the details of which of the = 15? different NAT options can be used best. When i worked on this, i got a working setu= p with NAT-PT and i think also NAT64 statefull (RFC6146). This was mostly driven by whatever old ro= uter OS versions where available.Also your note re. rfc7757. The main issue is that the st= ateless translations would require matching address structures in he ACP, and i certainly would not = want to fudge the ACP design to support NAT better. Rather use some horrific NAT option. That should e= ven accelerate pushing IPv6 into NOC/OAM equipment.=20 So, i didn't add any pointers to those RFCs you mentioned. I think its go= od if this is left as an exercise to the reader ;-) Med: Fair. Please change "IPv4 to IPv6 NAT can be used" to "IPv4 to IPv6 tr= anslation can be used" because it is more than "Address" translation.=20 - "I'm afraid NoO " - i did not get that. Med: This was related to this part of your text:=20 =3D=3D Overall, the use of NAT is especially subject to the RoI (Return of Investment) considerations, =20 =3D=3D=3D=3D=3D=3D=3D=3D The reasoning about NAT and RoI may seem to be intuitive, but I'm afraid it= does not reflect the deployment reality. The use of NAT may even come for = free or be a function of the traffic and so on. I would delete the mention of RoI.=20 Cheers, Med > -----Message d'origine----- > De=A0: Toerless Eckert [mailto:tte@cs.fau.de] > Envoy=E9=A0: jeudi 27 juillet 2017 20:52 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: anima@ietf.org; draft-ietf-anima-stable-connectivity@ietf.org > Objet=A0: Re: review comments draft-ietf-anima-stable-connectivity-03-rev > Med.doc >=20 > Thanks a lot, Mohamed for the thorough review! >=20 > I pushed -04 of the draft out with your changes incorporated. IMHO it's > all great textual improvements but no logical changes, aka: should be fin= e > for prior reviewers. >=20 > Diff: >=20 > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.iet= f.o > rg/id/draft-ietf-anima-stable-connectivity- > 03.txt&url2=3Dhttps://www.ietf.org/id/draft-ietf-anima-stable-connectivit= y- > 04.txt >=20 > Your original review doc: >=20 > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft- > ietf-anima-stable-connectivity/03-review-mohamed.boucadair.doc >=20 > My reply comments: >=20 > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft- > ietf-anima-stable-connectivity/03-review-mohamed.boucadair-reply.txt >=20 > While incorporating your review, i also figured that it would be good if > ACP connect > would allow auto-configuration of NMS hosts, so i added a paragraph to > mandate RFC4191, > but i didn't rev ACP draft just for that yet, so here's just diff on > github for that; >=20 > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.iet= f.o > rg/id/draft-ietf-anima-autonomic-control-plane- > 08.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/autonomic-contro= l- > plane/af74117400b6a5a7fca1acf2ab910d64a580a5c9/draft-ietf-anima-autonomic= - > control-plane/draft-ietf-anima-autonomic-control-plane.txt >=20 > Cheers > Toerless >=20 > On Mon, Jul 24, 2017 at 05:49:07AM +0000, mohamed.boucadair@orange.com > wrote: > > Dear Toreless, > > > > I'm resending this document as I didn't receive an ACK from your side. > > > > Please consider those as part of the WGLC comments. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: BOUCADAIR Mohamed IMT/OLN > > > Envoy=E9=A0: vendredi 7 juillet 2017 14:58 > > > =C0=A0: 'tte+ietf@cs.fau.de' > > > Objet=A0: Envoi d?un message=A0: draft-ietf-anima-stable-connectivity= -03- > rev > > > Med.doc > > > > > > Dear Toreless, > > > > > > Please find some comments about this draft. > > > > > > Cheers, > > > Med >=20 From nobody Mon Jul 31 17:12:56 2017 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 7F2D5131C81 for ; Mon, 31 Jul 2017 17:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 zIQpRuW-dyVK for ; Mon, 31 Jul 2017 17:12:52 -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 33543131C3A for ; Mon, 31 Jul 2017 17:12:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6FB792009E; Mon, 31 Jul 2017 20:14:37 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3DA6E80243; Mon, 31 Jul 2017 20:12:51 -0400 (EDT) From: Michael Richardson to: anima@ietf.org CC: Pascal Thubert In-Reply-To: <32649.1500771022@dooku.sandelman.ca> References: <32649.1500771022@dooku.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+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] ACP document --- 07 to 08 changes X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 01 Aug 2017 00:12:54 -0000 --=-=-= Content-Type: text/plain All of my minor edits and a few smallish friendly amendments are at: https://github.com/anima-wg/autonomic-control-plane/pull/3 Michael Richardson wrote: > I'm reading the -07 version of ACP (because it's been open in a tab Now to the changes in -08: AN "Autonomic Network". A network according to [I-D.ietf-anima-reference-model]. Its main components are Intent, Autonomic Functions and ANI. So, I had an initial problem with this, that it referes to something we have no idea about, "Intent". Then I wondered if this was well defined in the reference, and I find that actually the reference model has no terminology section.... maybe one could consider the entire document a terminology section. But, it seems strange to be definining this way in *this* document. I think that it should end at the first period. If the second sentence is needed, it should go into the reference. On this topic (which is not "ACP document"), I'm concerned about the amount of (*) text in the reference model document! AN Domain Name A string name (typically in a format of a DNS domain name) identifying an Autonomic Network. It is stored in the ACP information field of an ANI devices LDevID. re (typically..) either it's an FQDN (with all the QNAME restrictions and a reference), or it's just a string. Let's decide one way or the other, rather than "typically". I think that there are a number of other terms which should not be introduced definitatively in this document.... 5. Inside the ACP VRF, each node sets up a virtual (loopback) interface with its ULA IPv6 address. I think we should say that it's a /128. section 6.1.2 says "Maintenance" but, it's about AN_join_registrar. I don't think that the AN_join_registrar definition belongs in this document. I agree that some minor bit of text should exist, but I don't think this belongs here. This belongs in BRSKI. Perhaps it got clipped out in editing, but that's a bug. section 6.6: If our devices certificate indicates a CDP or OCSP then the peers certificate must be valid occrding to those (eg: OCSP check across the ACP or not listed in the CRL). {see git for a grammar fix to above} Somewhere, I think that we should be saying that Certificate Distribution Points (CDPs) or OCSP servers (whichever is used) SHOULD be available via the connections inside the ACP. BUT, as those things are usually referenced with names there are some MIF-like isues that I think the ACP document should address: 1) DNS. 2) address preferences. (Homenet's naming architecture is dealing with the same questions, but I think the answers may be different) 6.8.1. GRASP as a core service of the ACP I think that this section is really important. Too important to belong buried in a document about to build secure tunnels for IP traffic. At the least, this belongs prominently in the reference model document. At the largest, it needs a new document with a title like: "The ACP profile of GRASP as a core service" along with 6.8.2. re 6.10.2: -> 8+40+2 = 50 bits. so why in 6.10.3 says, "51 bits" for subscheme. I don't find the rational for the V bit very convincing. I don't think you need any real justification for it. 6.10.4. ACP V8 Addressing Sub-Scheme The sub-scheme defined here is defined by the Type value 1 (one) in the base scheme. I think you mean, "Type value 01 (one)", since there are two type bits. I find the use of 1 confusing, given that we also have the Z bit. You've made me happy with the address definition. I sent some text via pull request to clarify some of the no-artifact choice in RPL. most of the rest of the text looks great to me... (I just learnt that "artefact" was british spelling for artifact.. I guess we just need to pick one or the other.) I'll have to ask Pascal why he suggested: Trickle: Not used. 7.1 --- a pretty important section. One consideration that might be worth doing in a future document is registering a TLV for LLDP (CDP) that could carry GRASP M_FLOOD ACP messages. That would please switch fabric vendors because then making the topologies follow physical would be very easy. LLDP does not get forwarded. I wonder who knows the right IEEE incantations to do this. section 10.1: it seems like it's all been said already. section 10.2 ---> move to an appendix. section 10.3 ---> appendix or cut. I see that it all *WAS* in an appendix. I don't know why you moved it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAll/x4IACgkQgItw+93Q 3WUHHAf8DaK0NyEuwABezjeCImCTkIrGAxl8qUwXK4cE9wCj3SKrXtE8etvUmIQX QKNFhRFA/+WWaDED6XAUZr/x0vFGCwZLUXlmoap8xgrOTYMOtpCeVUe0k0V2JIuS ZNccO+Vhnoy3gF9J3+UkDNfWoWP68AQ52TKc+IjeXKZWHhT5en/RMfmqPb/PpsPH ckUaem80Ae1jpXIsnTfKMwYvyDEiI+ZzweExrNEC/oV+WI8z9OeFHIZMsUpCHHX7 xY0sUcwRWY6SunOj5lS4TC7YHpFQN6VeuKYYra25v07uTYQasTAD7yqbyVprY5KQ 07JoDwwil+T+j2yslwYTk8T5NQ1qHQ== =K/rm -----END PGP SIGNATURE----- --=-=-=--