From nobody Tue May 1 10:05:53 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28D212E8C8; Tue, 1 May 2018 10:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 h0xU9zVCPfuj; Tue, 1 May 2018 10:05:49 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1152312E8C4; Tue, 1 May 2018 10:05:48 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud7.xs4all.net with ESMTPA id DYinfzb448U07DYinfMwVz; Tue, 01 May 2018 19:05:47 +0200 Received: from [178.18.63.249] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 01 May 2018 19:05:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 May 2018 19:05:45 +0200 From: peter van der Stok To: Jim Schaad Cc: 'Michael Richardson' , anima@ietf.org, draft-richardson-anima-ace-constrained-voucher@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <042701d3e0bc$c42d4150$4c87c3f0$@augustcellars.com> References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> <24823.1525115896@obiwan.sandelman.ca> <042701d3e0bc$c42d4150$4c87c3f0$@augustcellars.com> Message-ID: <50727c584139a458cc3fc322879dca1c@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfNi1T2gHJ1xtb0icw7+TfFL1fyhFJnULfdPHvZnDJ3ISyoltLpi2isvjKpCIex/GfvdqB2fRfz96iWebQZwesxIkEOXpD2mMSJ4J8QdknDW/rX3tS9oi o7EhImJk6l9MDZshrxnY9g07ssMfEpIJY7Tq6qYYl/kdzYEMdKungWh6uGIelW4OI4Qb2B07UvdT2Wbyto3S+0BL0dTUvhgmDlsgPdQY9DEBLVCFSbV/Bk0d uhvRea27TfyLduUlmuNAoPZ+Q7nX9YpSH1YdkKaXsE1gxmBqCrvLZ2KrORqProGeQbNt4bsYPU//9y6J6kny+Lg1pmI83Ss7ns95y/bpyo+SB5wO+Fg3joTX HZQUVg6in2WDlpZ5OJ4FXzFZcV78FPofkgBFjpYHgGuI8Xm+igeKwhOZr6WXXekWhiNAMEXnwTVBoQSMb5B9Yo0czcB0RP4Oa6gsMsLnqdmwfzb9gBpw8/5A kdPuSQ5YK+ITxdnOjTU8KRaq6qRkzJsfH2RTHw== Archived-At: Subject: Re: [Anima] draft-richardson-anima-ace-constrained-voucher 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 May 2018 17:05:52 -0000 > There are a couple of questions that I would put here that I think > guides > things. > > * Is there any expectation that the path components would ever change > for > some implementation or are they always going to be the same? Would a > request voucher always be posted to /rv or could an implementation > change it > to be /rvr? No path components are immutable. > * Is there a reason for an endpoint to want to get what services are > supported as a general rule rather than just assuming that if the root > exists then all of the services are also going to exist. > > If the answer to the first question is no, then I don't know that they > even > need to have resource types. You get the root and go from there. Agree. I will change the example and return the rt= with the first line and no rt= for the following lines. The text will mention that the first line MUST be returned, and the 4 following lines MAY be returned to show the ct= values that are supported. Greetings and thanks, Peter From nobody Tue May 1 10:07:27 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564C112E8C8; Tue, 1 May 2018 10:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 LLxF1oUOPcmy; Tue, 1 May 2018 10:07:24 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AADD12E8C4; Tue, 1 May 2018 10:07:24 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud7.xs4all.net with ESMTPA id DYkMfzcAn8U07DYkMfMwu8; Tue, 01 May 2018 19:07:23 +0200 Received: from [178.18.63.249] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 01 May 2018 19:07:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 May 2018 19:07:22 +0200 From: peter van der Stok To: Jim Schaad Cc: 'Michael Richardson' , anima@ietf.org, draft-richardson-anima-ace-constrained-voucher@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <50727c584139a458cc3fc322879dca1c@xs4all.nl> References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> <24823.1525115896@obiwan.sandelman.ca> <042701d3e0bc$c42d4150$4c87c3f0$@augustcellars.com> <50727c584139a458cc3fc322879dca1c@xs4all.nl> Message-ID: <0a258d71d91d7b3e03409e5678ae0210@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfISuUJor5DNGr7upFNNw4ua70FrrRTtB5s2qNHU0+XfH+6eQ9eeoQY80n8Il9QBZWSuWItG01ilPP9zdXA3opvUCXZ0PB0Z7EaZdztlaGk5jVbdGUUwa yF/+cV5Ogw++gXOVkn8sz4JrDhAP/9cmqnnW3HlZyRnMz4RieOep2I1fnkdH853O6zYbxixJhCk3AfdcP0ht3UFdP35caBmYVLzhB8XOg2yd9CN7QaCIpakz Hynfq2FT3dgGs2/KvzPslUgCHa4jLF6tZ8/6tbH8PPB+CTgjqkGaIkp1+gvUijVrp0GetE3Frw/miSkQIUNtbRiODaQOOjsYHDS9U+89FLW9ztg0RdnfCcaO zivstjQwp7QETlnQbqk7ArhoOIM3hLa3Ol07sA5WfW+vxgJ/5ENQ4AgVivvdpwjlDtAupeTuTlX8I/kKB+DYzSN26V8EUytFYd4NCGTelbZjCr/giHbTD1wd veXgP2uYZ9N3yMCLtve/jWfIUB0D1Q6Ulge6Cw== Archived-At: Subject: Re: [Anima] draft-richardson-anima-ace-constrained-voucher 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 May 2018 17:07:26 -0000 sorry, ambiguous answer. > No! The path components are immutable. Peter From nobody Sun May 6 17:57:06 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 849A112D886; Sun, 6 May 2018 17:57:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang To: X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Toerless Eckert , anima-chairs@ietf.org, iesg-secretary@ietf.org, Sheng Jiang , anima@ietf.org, jiangsheng@huawei.com Message-ID: <152565462553.1312.5596903904518881375.idtracker@ietfa.amsl.com> Date: Sun, 06 May 2018 17:57:05 -0700 Archived-At: Subject: [Anima] Publication has been requested for draft-ietf-anima-reference-model-06 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, 07 May 2018 00:57:05 -0000 Sheng Jiang has requested publication of draft-ietf-anima-reference-model-06 as None on behalf of the ANIMA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ From nobody Sun May 6 19:08:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3D412D7E4 for ; Sun, 6 May 2018 19:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 0Kqd_A-rFFd4 for ; Sun, 6 May 2018 19:08:25 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 081BF120047 for ; Sun, 6 May 2018 19:08:24 -0700 (PDT) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.217] port 59058) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id w4728MKm013788 for ; Sun, 6 May 2018 22:08:22 -0400 To: anima@ietf.org References: <152565462553.1312.5596903904518881375.idtracker@ietfa.amsl.com> From: William Atwood Openpgp: preference=signencrypt Organization: Concordia University, Montreal Message-ID: <88332bf4-4b87-693f-73eb-7fa941b082f2@concordia.ca> Date: Sun, 6 May 2018 22:08:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152565462553.1312.5596903904518881375.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2018-05-06 22:08:22 EDT Archived-At: Subject: Re: [Anima] Publication has been requested for draft-ietf-anima-reference-model-06 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, 07 May 2018 02:08:27 -0000 As "None"??? On 06/05/2018 8:57 PM, Sheng Jiang wrote: > Sheng Jiang has requested publication of draft-ietf-anima-reference-model-06 as None on behalf of the ANIMA working group. ^^^^ > > Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Sun May 6 19:33:58 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE15127058 for ; Sun, 6 May 2018 19:33:56 -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, RCVD_IN_DNSWL_MED=-2.3, 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 11g0pFYjabDb for ; Sun, 6 May 2018 19:33:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE141200E5 for ; Sun, 6 May 2018 19:33:54 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 13B571712DE9 for ; Mon, 7 May 2018 03:33:51 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 7 May 2018 03:33:52 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.29]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Mon, 7 May 2018 10:33:45 +0800 From: Sheng Jiang To: William Atwood , "anima@ietf.org" Thread-Topic: [Anima] Publication has been requested for draft-ietf-anima-reference-model-06 Thread-Index: AQHT5Z5aSBr3vSjAuU+XYboQKK67NqQi/zmAgACM/GA= Date: Mon, 7 May 2018 02:33:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9281873D51@NKGEML515-MBS.china.huawei.com> References: <152565462553.1312.5596903904518881375.idtracker@ietfa.amsl.com> <88332bf4-4b87-693f-73eb-7fa941b082f2@concordia.ca> In-Reply-To: <88332bf4-4b87-693f-73eb-7fa941b082f2@concordia.ca> 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 Archived-At: Subject: Re: [Anima] Publication has been requested for draft-ietf-anima-reference-model-06 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, 07 May 2018 02:33:56 -0000 It has been fixed, as Informational document. Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of William Atwood > Sent: Monday, May 07, 2018 10:08 AM > To: anima@ietf.org > Subject: Re: [Anima] Publication has been requested for > draft-ietf-anima-reference-model-06 >=20 > As "None"??? >=20 > On 06/05/2018 8:57 PM, Sheng Jiang wrote: > > Sheng Jiang has requested publication of draft-ietf-anima-reference-mod= el-06 > as None on behalf of the ANIMA working group. >=20 > ^^^^ >=20 > > > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > -- >=20 > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email:william.atwood@concordia.ca > 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill > Montreal, Quebec Canada H3G 1M8 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon May 7 12:30:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B033012783A; Mon, 7 May 2018 12:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_PpEQonpIXW; Mon, 7 May 2018 12:30:25 -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 331DE126FDC; Mon, 7 May 2018 12:30:25 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B836A58C4AE; Mon, 7 May 2018 21:30:19 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A8936440218; Mon, 7 May 2018 21:30:19 +0200 (CEST) Date: Mon, 7 May 2018 21:30:19 +0200 From: Toerless Eckert To: Joel Halpern Cc: rtg-dir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> References: <151995712572.15727.501156104518975926@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151995712572.15727.501156104518975926@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 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, 07 May 2018 19:30:30 -0000 Joel, Sorry for the late reply. Bufferbloat. Thank you very much for the review. Uploaded first round fixes for your review to github, will push out -14 when i am through with the other reviews. Version: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Diff to -13: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-anima-autonomic-control-plane-13.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Comments inline below. (n) additional explanations at end of mail. Cheers Toerless On Thu, Mar 01, 2018 at 06:18:45PM -0800, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing ADs. > For more information about the Routing Directorate, please see > ???http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-anima-autonomic-control-plane-13 > Reviewer: Joel Halpern > Review Date: 1-March-2018 > IETF LC End Date: N/A > Intended Status: Proposed Standard > > Summary: I have some minor concerns about this document that I think should be > resolved before publication. > > Major: N/A (Note that three comment is marked *** as they may be more > significant.) > > Minor: > The description of the ACP In the introduction should probably note that > the addition of Management capability is beyond the definition provided in > section 5 of RFC 7575, and is included to complete the needed set of > functionality. Added this to the end of introduction before discussion of stable connectivity, seems to fit best there: The ACP provides secure IPv6 connectivity, therefore it can not only be used as the secure connectivity for self-management as required for the ACP in , but it can also be used as the secure connectivity for traditional (centralized) management. The ACP can be implemented and operated without any other components of autonomic networks, except for the GRASP protocol which it leverages. > The definition of data-plane seems to assume that all forwarding (and > control?) in all nodes is structured in terms of VRFs. That seems to > overly constrain implementation architecture. Using VRF to to describe the > ACP functionality is a little odd, but likely defnesible. Declaring that > all other functionality is in VRFs seems a step too far. Oh... rathole ;-) I spent a lot of time pondering this problem. Given how i think the classical way VRFs are implemented in routers is actually NOT a good way to implement the ACP, i tried long to figure out better terminology. But: VRF is actually the most logical way to specify the interoperability, routing and forwarding aspects of the ACP without really implying a specific implementation approach. For example: If we would have used a term like "virtual router", we would have run the risk of excluding the option to implement ACP as a "classical router OS VRF". On the other hand, by using the term VRF (including our definitions what we mean with it), i can perfectly implement the ACP as a virtual router, as a function in a hypervisor or as a classical router OS VRF. VRF only says separate routing and forwarding (see section 6.9). Note too that we have explicitly specified in the terminology section that we're NOT implying any of the MPLS/VPN-PE specific functions of a VRF. Like othrer RFCs as well that use the term VRF without having anything to do with MPLS/VPN. In response to you bringing up the naming issue, i went through the doc and removed "VRF" where it was used for the data-plane, so as not to imply the use of VRF other than for the ACP itself. There is still some amount of VRF in the "VRF selection" section, thats really too hard to describe without VRF - would just make it too convoluted. > The definition of Intent in the terminology section seems to be different > from the cited definition in the anima reference model. "Intent" there > seems to refer to a policy language, not an interface. Thanks. Good catch. Fixed. > It is unclear how the flexible policy defined in section 5 bullet 2 (about > which nodes are ACP peer candidates) is consistent with autonomic > operation. It seems that the flexibility is important, so there should be > some explanation here about how this is consonant with the stated goals. I > understand that the bootstrap comes from BRSKI, but I do not think that is > where the policy comes from? Would rather not like to add more suggestive text, and thats at best what i could add. The default policy is the best "autonomic" behavior we know how to make work: aka: try to connect ACP to all neighbors you can discover. And we have only defined with DULL GRASP how to find subnet adjacent neighbors. The main reason to mention policy is so that there is some leeway to do more or even (sigh) less than all direct neighbors. See also (1) at end. > The BNF is section 6.1.1 seems to have some oddities. It may be that none > of these can happen for reasons that are described elsewhere, but as > written: > If the local-info is empty, the localpart will be "rfcxxxx." and thus the > domain info will be "rfcxxxx.@domain". Is the period really required in the > absence of the local-info. modified local-part = key "." local-info to local-part = key [ "." local-info ] > If the rsub is empty, but the extensions are not > empty, it looks like there will be two plus signs (following the optional > acp-address) before the first extension. Is that intended as the way to > indicate the absence of the rsub? Yes. Otherwise it would be ambiguous to parse. Haven't written something about this because i think readers eithrer don't care or the can figure it out easily. > It also seems odd that the rsub (which is a > domain extension) appears in the local-part of the domain information, not in > the domain name. Even though for hashing purposes it is concatenated, with a > period, with the domain name. > If these oddities are intentional, then there ought to be explanations so the > reader is not confused. The difference between domain and routing-subdomain are explained directly after the BNF: "domain" is used to indicate the ACP Domain across which all ACP nodes trust each other and are willing to build ACP channel to each other. See . "routing-subdomain" is the autonomic subdomain that is used to calculate the hash for the ULA prefix of the ACP address of the node. ... Added: "rsub" needs to be in the "local-part"; it could not syntactically be separated from "domain-name" if "domain" is just a domain name. It also makes it easier for domain name to be a valid e-mail target. > I presume there is not an assumption that all ULA addressed communicating > with a node which supports the ACP will be over the ACP. As I understand > it, ULAs may well have other uses outside of ANIMA / the ACP. Which leads > to a question about how the text in 6.1.3 "If the CDP URL uses an IPv6 ULA, > the ACP node will try to reach it via the ACP." is expected to be supported? The reason is that the ACP certificate maintenance runs across the ACP so that we have a simple security model for the ACP certificate lifecycle. We do not want to have to figure out the impact of attacks against connectivity to the CDP when it runs across the data plane. After all, these are ACP certificates are also renewed via EST across the ACP. I added the following explanation sentence: Reaching the CDP across the ACP implies that the CDPs need to be reachable via the ACP, for example by running CDPs on registrars or on devices connected to the ACP via ACP connect (see ). See also (2) at end. > The discovery text in section6.3 states that discovery should be run in > every physical interface. Is this intended to be restricted by policy, as > described in section 5, bullet 2? As said above for 5 bullet 2, it is permissible to be modified, the ACP draft does not suggest or recommends any modifications other than those in 6.3, aka: physical interfaces. > *** The explanation in section 6.5 on channel selection (and security > protocol selection) is worded as if the described behavior will lead to > reliable interoperation. The text on why there are limitations (reasonable) > doe not explain why mandating dTLS support would not be a reasonable step. (I > hope I missing something, as otherwise this is a major problem rather than > being minor.) It is also hard to align this with the requirements in section > 6.7.3. I think there is no issue. Let me explain: We beat ourselves up for quite a long time about MTI channel options (Mandatory To Implement) and figured there is no one-size-fits-all. The first challenge for dTLS was that there is no RFC specifying how to run IPv6 over dTLS. There are widely supported / deployed variations like OpenConnect etc. running IP/IPv6 over dTLS, but they all havesome home-brewed complex session maintenance mechanisms because they where built for hub&spoke user VPN solutions. We do not only not need that additional complexity, there is also no RFC for them (only expired individual drafts). In the absence of a simple standardized specification and deployment experience in non-constrained equipment with simple IPv6 over dTLS, we did not want to make it MTI for devices that had a better alternative. I then tried to figure out what would need to be written to specify how to run IPv6 over dTLS, and that became 6.7.2. Many type of constrained devices want to run everything over dTLS because they already got that code for CoAP etc. pp, and they do often not have IPsec code in their software. Therefore dTLS is the better MTI for those devices. I have modified the dTLS MUST sentence to make it clearer: A constrained ACP node that can not support IPsec MUST support dTLS. ^^^^^^^^^^^^^^^^^^^^^^^^^^ > 6.8.2.1 has text about "hop-by-hop reliable retransmission as provided for > by TCP". I am unable to determine what this is saying. Changed sentence to: Such shorter periodic retransmission of datagrams would result in more traffic and processing overhead in the ACP than the hop-by-hop reliable retransmission mechanism by TCP and duplicate elimination by GRASP. > If I have used section 6.10.3 properly, when the Zone-ID is 0, all nodes > within the ULA are within a flat address space. that does turn the address > into an identifier. It is, as far as I can tell from the description, > still a locator in that packets will be routed to the node using the > address including the node identifier. It just means that routing has to > work in /127 addresses. (There is also a reference to "identifier" in > 6.10.3.1. From the usage there, I think that the intention is that this is > the generic "name" for the node. Given that it is routable, it is simply > an addresses, not an identifier or a locator.) My driver license number is (intended to be) an identifier. It stays an indentifier even if someone starts building a network with a routing table for driver license numbers. Likewise, the intent of zone=0 numbers is to be identifiers. And yes, they do double a locators when you have a flat routing table which is what we do in this doc. We just didn't describe options where zone=0 would not double as a locator, that is meant to be left for future work if we see sufficient use cases for it. We just tried to make the definitions extensible and define the intent of the format to be that of identifiers. > The description in section 6.10 / 6.10.1 / 6.10.2 is about the schema > identification is very confusing, and arguably a bad design. I guess you mean 6.10.2 / 6.10.3 and 6.10.4 ? > The two schemas use the same schema identifier. ^^^^^^^^^^ Type ? The difference in interpretation > is actually provided by the last bit in the upper 64. If these are the > same schema, then it should not need a bit to differentiate them. They > should be explained as a single schema. Which would presumably result in > the Z bit being part of the zone / subnet field. If they are two > different schemas, then move the differentiation to part of the schema > identifier (making it 3 bits). We did not want to make Z part of the base schemas 6.10.2 "Type" code because that would also make the Vlong scheme one bit shorter and that would reduce virtualization space in Vlong by a factor of 2. So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO textually correct to have them in different subsections. Carving out bits like Z isn't ideal, but in between the ULA prefix, the 64 bit local part we must have for external interfaces and best utilization of bits, we tried to rather optimize address space utilization and not beauty of encoding. Having at the end allows (as written) use of /63 instead of 2 * /64 routes. I am not sure how important this would be in the future. If you feel strongly about more beauty in encoding, i can move Z to the left and remove the notion of the possible /63 route optimization possible through the placement of Z. > This sort-of different but sort-of the same > makes implementation "interesting". Even if this is extra bit is only > needed for schema 00b, it should be in front of the Zone / subnet, not > after it. This leads to the obvious observation that either we need two > bits, of which we will have 3 settings, and we will use the fourth setting > as an extension mechanism if we ever need more formats, or we need at least > three bits all the time because we seriously think there will be more > formats. I very much hope there is no "interesting" implementation aspect; nothing in the current scheme that makes implemenation harder. If you have an example that you fear, i would like to hear it. To me, we are just defining address space allocation schemes. > In section 6.10.5, after stating that it is not even known what the needed > usage is for more V values Which sentence are you referring to when you say "not even known what the needed usage is" ? I can't find it, but i would like to rectify it if it actually is still there. The two addressing space Zone and Vlong do certainly address two very different network and node design considerations. In the Zone addressing format, we wanted to have a scheme for potentialy very large networks. Enterprises plus their attached IoT networks with hundreds of thousands of nodes. Worldwide enterprise WN/campus/branches. Or massive DCs. The one V bit in this space is just to solve the single most likely problematic implementation consideration of ANI: Allowing ANI to have a complete port number space of itself, therefore not conflicting with traditional management port number usage (if needed). Or similar. The Vlong addressing space goes the other way, allowing to build out management plane or ASA more easily as containers or other lightweight component models where each such component has its own address. We also had brainstormed some network layer functions (proxies) that had to eat up address space, so would use V bits. Both approaches are IMHO very valid and important options that we wanted to be able to support and let developers and deployments choose which one fits them best. > the document goes on to introduce the > complexity of classful nodes numbers, with the leading bit indicating how > long the node-number is. Yes, the rest of the text in that bullet tries to > explain why you need both sizes. It seems like needless complexity that > begs for mistakes in implementation. I was taking the example use cases we brainstormed into account, and some of them would require a lot more addresses in the node than others, therefore these two choices. Ultimately, we need to break through the chicken and egg problem of how to build more self-managing networks. These will require a different number of addresses inside nodes. Anything more intelligent than address space allocations would become a complex dependency making implementation/adoption even slower. I don't think that offering 2, 256, 64k addresses per node is too much flexibility. It IMHO necessary and sufficient to explore and we'll see what sticks. > In section 6.11.1.11 in describing the prefix lengths, I thought that the > point of zone addressing was to allow the use of /64 prefixes. But it > seems here that we will not do so ? As mentioned above: This document does not describe the routing setup for /64 (or /63 with Z-bit) routing aggregation. There are multiple options, but we could not conclude on a single solution that we felt to be appropriate for this document. Instead it was only very important to carve out addressing space to support this. See also (3) at end. > Section 6.12.5 says "ACP nodes MUST NOT derive their ACP virtual interface > IPv6 link local address from their IPv6 link local address used on the > underlying interface". But it does not then seem to provide any advice on > what is expected to be used. Is the loopback ACP supposed to be used > somehow? Or? Changed paragraph to following: The ACP virtual interface IPv6 link local address can be derived from any appropriate local mechanism such as or . It MUST NOT depend on something that is attackable from the data-plane such as the IPv6 link-local address of the underlying physcial interface, which can be attacked by SLAAC, or parameters of the secure channel encapsulation header that may not be protected by the secure channel mechanism. > The "configuration" description in 8.2.1 provides a nice description of > what information is needed, and what choices are allowed. It does NOT > describe a method for configuring the information. Please tune the > introductory material. Hope i am guessing correctly what you're alluding to. Fixed text: On the ACP node, remote ACP neighbors are configured explicitly. The parameters of such a "connection" are described in the following ABNF. ... Explicit configuration of a remote-peer according to this ABNF ^^^^^^^^^^^^^^^^^^^^^ provides all the information to build a secure channel > *** Section 10.3.2 paragraph 2 says that devices should change the meaning > of "admin down" to mean "down for everything except ACP / Anima". I can > understand why, in an autonomic network, such a state is desirable. However, > that really should be a different state from "admin down". Operators already > understand "admin down" as meaning that this interface will not be used for any > traffic. Changing that is fairly drastic. "admin limited" or "admin ACP-Only" > would seem much better than changing the meaning of "admin down". The > justification in the text seems to be a desire to prevent an operator from > doing what he intends. that seems backwards. (Note that the distinction > between administrative state vs operational state, aka failed, is already well > understood.) Well, this is in an informative section, so hopefully something we can agree to disagree. I strongly believe that the most easy way to operationalize the ACP and achieve its goals is what we have written. The historic equivalence of "down" = "admin down" = "physical down" is one of the the most fundamental problem of remote management in networks. We really need to start thinking of separate layers of (remote) management. Network services on one hand and physical infra on the other. The first thing to do this is to separate operations such as "down" into "admin down" that affects networks services and "phy down" that affects the physcial infra. If you have existing commands like "shutdown" that today do both, the safe mapping is to let them do the safe thing in the future, e.g: only "admin down", and introduce new commands for the phy operations, e.g.: "phy shutdown" or the like. And then protect those dangerous commands even further against unintentional or intentional misuse. Think of ACP/ANI also as a seamless inband version of a DCN. As an operator of the actual data network, you also didn't have any access to bring down the DCN and cut yourself off from the network you manage. YOu could only screw up that network you're meant to manage. And if your network consists of VMs in a DC, a "shutdown" on their interfaces will also not bring down physical interfaces necessary to reach the VM. In optical networks you often have an inband physcial ethernet management channel. Making/breaking that one is completely different from making/breaking your data-plane, aka: data fiber colors. > *** The notion in 10.3.6 that the device should refuse to disable > functionality when an authorized administrator directs such seems flatly wrong. The authorization to break your own remote management connectivity would be a property of the certificate. clearly whoever enrolled the device with a certificate denying that capaility to the operator did NOT authorize the administrator to break connectivity. > Editorial / Nits: > Section 6.3, in talking about DULL GRASP refers to the grasp internet > draft. It refers to section 3.5.2.2. there is no 3.5.2.2 in the grasp > I-D. As best I can guess the reference should be 2.5.2. Thanks > In the various formats in section 6.10, the lowest bit of the upper 64 bits > is mandated to be 0. Presumably, there is some reason for doing this. It > would be nice to explain it. Sorry, not clear what you're referring to. Can you give me an explicit reference ? > In section 6.10.5, in the text about how many V values are allowed, the > text reads: "2^16 - 65536" which would be 0. I believe that the intention > is "2^16 (i.e. 65536)" Thanks. Meant to say "2^16 = 65536", but now its your i.e. > Section 9.2.2 paragraph 2 begins "Group members must overall the secured". > While I can guess what is intended, I would prefer that were in grammatical > English so as to avoid guessing. Hmm.. not sure i catched the grammatical error i did, but i figured that the text was missing some better explanation what it meant. Added the following: Group members must be protected against attackers so that there is no easy way to compromise them, or use them as a proxy for attacking other devices across the ACP. For example, management plane functions (transport ports) should only be reachable from the ACP but not the data-plane. Especially for those management plane functions that have no good protection by themselves because they do not have secure end-to-end transport and to whom ACP does not only provides automatic reliable connectivity but also protection against attacks. > Section 10.5 provides the requirements that were met by choosing RPL for > the routing protocol. Likely RPL is a reasonable choice. Since this > section does not provide comparison or list any alternatives, I would > suggest changing "explanation" to "motivation". Done. -------------------------------------------------------------------------- (1) Examples of good additional discovery would be methods to do it via L3 or where additional parameters ae needed, we discussed some options to help bring up interfaces like PPP requiring credentials or the like. On the "challenged product" side, we have seen products unwilling to bring up interfaces during bootstrap because those interfaces require additional license keys for activation *sigh*. (2)side note: We started from classical PKI model with CDP/OCSP but didn't bother much about it, so this is a bit of a step-child: Most of the ANI authors are fans of short lived certificates to eliminate CRL/CDP because through ACP and BRSKI, we can make lifetimes shorter than typical CDP validity intervals: ACP adds reliability, EST automation, BRSKI can provides re-enrollment even when certificate has expired so ACP can not be vbuilt. Therefore we didn't bother much in making CDPs as easy to use as we could, e.g.: no GRASP objective to auto-announce/discover CDP like we did for EST renewal. but i didn't want to blackhole the text with these considerations even further. ] (3) The most simple option we have seen asked for in actual deployments was for manual config of such zone edges, not IMHO really appropriate for this document. More like something for informational docs. Even in that case you could explore the traditional method where you actually hand out zone != 0 address via the domain cert, set up RPL roots for each zone and connect the roots. Or you do simply rely on zone 0 addresses, rely only on the default route in each zone and use something like lisp between zone roots to map from zone=0 as identifier to remote root locator. Aka: everything worth describing in other documents. From nobody Mon May 7 15:20:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2383126C19; Mon, 7 May 2018 15:20:54 -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 eL_7SDhGR3u5; Mon, 7 May 2018 15:20:53 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::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 2B4CE124239; Mon, 7 May 2018 15:20:50 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id u6-v6so960979pls.9; Mon, 07 May 2018 15:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FTc7mELFtn1Vw58Dhg7fbmFf1XOZtT4fyUt3ECQgQzY=; b=VvTD9aTSseTESTCZZfufY6RXWklUazxDNw3YdmuTTuM4xYK1cLYs0j2Z4ffgJG2JUZ CTyiu4WHvfiycSX6EypNdcXKoVRt3244CfaeFUxyr+WSFP+M1dpsa6KQmOR7a/egHGck GSC1nWP9flfuF3Z77pFJVhyHXki4eALoJx9J3bxIITrnqEj7Mpv6CoOp341Io++k3NJc B590/XD7JTC2hUpoVpdXpTbWYFhrDJ55yHzj484BtXm5uYOWqh5z3+K50YLk9VjrDDnP YmvQ7nFcGXSV6VjxKbGEw007ZnOkHXsD7xYmRgdXKratcU0SyCHYzrlksK+dkfkD2lsj 4uRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FTc7mELFtn1Vw58Dhg7fbmFf1XOZtT4fyUt3ECQgQzY=; b=Tvph2uDcSzPH5SqjYi++uRfN7B3NAfPiHZ5W3wH+iDrQDSSM+2UJDNYNeun/ivHtGE roP3KaInJ98P7me6LBTGrtUxk7onWYwkQR7AqnoFRiEwpitEmGYr/AMUm2QOkuAoXU+f BgsSqpk3qhu1HLTwd2lYN+2iIn0/0iyBBlkX7LzMk8ID9dgzVOPkCLnRP1yMQOa9xMbp q7bnxnnNUjR+qz+kICGi65JQGjqG/abztCOt989SsGSQ1z6UHNllovRxfYsdqs7Xu6d8 u8zVGUva2oxJM8cT2PwG4FINeV9Gv0G9doFiLE9AVG/AzbvNHZyCz8dh0VHL5joOBHNt jnZA== X-Gm-Message-State: ALQs6tBN8bFoTFekfEDAGROKIrpuQFmqKyAmKAoZxAjyNwo/tPTQVMm4 8JRcLDF+h+VMp0t8z2HN3+sPTYES X-Google-Smtp-Source: AB8JxZrDpQcBdTUhX6DPxif0Wg4eLGbDZZT+GcZfBMwcglHXUEgfFLrDRZe78YmoJkHmVRj5RXllVQ== X-Received: by 2002:a17:902:ac96:: with SMTP id h22-v6mr39117272plr.338.1525731649330; Mon, 07 May 2018 15:20:49 -0700 (PDT) Received: from [192.168.22.38] ([131.203.241.238]) by smtp.gmail.com with ESMTPSA id 68sm13659471pfk.46.2018.05.07.15.20.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 15:20:48 -0700 (PDT) Sender: Brian Carpenter To: Toerless Eckert , Joel Halpern Cc: draft-ietf-anima-autonomic-control-plane.all@ietf.org, draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Tue, 8 May 2018 10:20:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Editorial note [Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13] 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, 07 May 2018 22:20:55 -0000 >> Editorial / Nits: >> Section 6.3, in talking about DULL GRASP refers to the grasp internet >> draft. It refers to section 3.5.2.2. there is no 3.5.2.2 in the grasp >> I-D. As best I can guess the reference should be 2.5.2. Since GRASP and ACP are bound together by normative references, we'd better make sure that this cross-reference is correct at the AUTH48 stage. Maybe insert a comment for the the RFC Editor in the XML? Regards Brian From nobody Mon May 7 16:05:20 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5BE12D7F5; Mon, 7 May 2018 16:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ap7eJ7SN2_g; Mon, 7 May 2018 16:05:13 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1717412D7F2; Mon, 7 May 2018 16:05:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C4E8926B78A; Mon, 7 May 2018 16:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1525734312; bh=rTQfK1iB5UEdoBGG4HyOIaGrGuc/ntXPDTdQ+E/HEtI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=G7vAYm5+R/dO1es1YNa7nAYgvoSQMj6ydsExWZ01Vi1U9SWOPmt6xQmlbtxtqXWrN T5HlEVYPFL67eTFg0GEEpCKVbCKiuB4RJvqFX1rEY7OhzlozLt8hogrq5yKp4iC3G4 vho7YYYqesYcddh73wyHJk4NaNH3Beb3g5YBbRis= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E9A2226B77B; Mon, 7 May 2018 16:05:10 -0700 (PDT) To: Toerless Eckert Cc: rtg-dir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: Date: Mon, 7 May 2018 19:05:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 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, 07 May 2018 23:05:16 -0000 Comments in line. Areas of clear agreement elided. On 5/7/18 3:30 PM, Toerless Eckert wrote: > Joel, > > Sorry for the late reply. Bufferbloat. Okay. Thank you for addressing a number of the points effectively. Let's see if we can solve the remaining items. >> The definition of data-plane seems to assume that all forwarding (and >> control?) in all nodes is structured in terms of VRFs. That seems to >> overly constrain implementation architecture. Using VRF to to describe the >> ACP functionality is a little odd, but likely defnesible. Declaring that >> all other functionality is in VRFs seems a step too far. > > Oh... rathole ;-) > I spent a lot of time pondering this problem. ... > > In response to you bringing up the naming issue, i went through the > doc and removed "VRF" where it was used for the data-plane, so as not > to imply the use of VRF other than for the ACP itself. > > There is still some amount of VRF in the "VRF selection" section, thats > really too hard to describe without VRF - would just make it too convoluted. Good enough. Thank you. >> It is unclear how the flexible policy defined in section 5 bullet 2 (about >> which nodes are ACP peer candidates) is consistent with autonomic >> operation. It seems that the flexibility is important, so there should be >> some explanation here about how this is consonant with the stated goals. I >> understand that the bootstrap comes from BRSKI, but I do not think that is >> where the policy comes from? > > Would rather not like to add more suggestive text, and thats at best what > i could add. The default policy is the best "autonomic" behavior we know how > to make work: aka: try to connect ACP to all neighbors you can discover. And > we have only defined with DULL GRASP how to find subnet adjacent neighbors. > > The main reason to mention policy is so that there is some leeway to do > more or even (sigh) less than all direct neighbors. After looking at this, I think I can live with what you already have. I think there are some issues, but let it be. >> If the rsub is empty, but the extensions are not >> empty, it looks like there will be two plus signs (following the optional >> acp-address) before the first extension. Is that intended as the way to >> indicate the absence of the rsub? > > Yes. Otherwise it would be ambiguous to parse. Haven't > written something about this because i think readers eithrer > don't care or the can figure it out easily. I think it would help to state it explicitly. (section 6.1.1) >> It also seems odd that the rsub (which is a >> domain extension) appears in the local-part of the domain information, not in >> the domain name. Even though for hashing purposes it is concatenated, with a >> period, with the domain name. >> If these oddities are intentional, then there ought to be explanations so the >> reader is not confused. > > The difference between domain and routing-subdomain are explained directly after > the BNF: > > "domain" is used to indicate the ACP Domain across which all ACP nodes trust each other and are willing to build ACP channel to each other. See . > > "routing-subdomain" is the autonomic subdomain that is used to calculate the hash for the ULA prefix of the ACP address of the node. ... > > Added: > > "rsub" needs to be in the "local-part"; it could not syntactically be separated from "domain-name" if "domain" is just a domain name. It also makes it easier for domain name to be a valid e-mail target. Okay. It is odd, but works. > >> I presume there is not an assumption that all ULA addressed communicating >> with a node which supports the ACP will be over the ACP. As I understand >> it, ULAs may well have other uses outside of ANIMA / the ACP. Which leads >> to a question about how the text in 6.1.3 "If the CDP URL uses an IPv6 ULA, >> the ACP node will try to reach it via the ACP." is expected to be supported? > > The reason is that the ACP certificate maintenance runs across the ACP so that > we have a simple security model for the ACP certificate lifecycle. We do not > want to have to figure out the impact of attacks against connectivity to the CDP > when it runs across the data plane. After all, these are ACP certificates are > also renewed via EST across the ACP. > > I added the following explanation sentence: > > Reaching the CDP across the ACP implies that the CDPs > need to be reachable via the ACP, for example by running CDPs on > registrars or on devices connected to the ACP via ACP connect (see ). While a useful addition, that is not what I was asking about. The text as written seems to say that simply because the RDP uses an IPv6 ULA, the node will know to use ACP for the communication. I understand why we awant the communication to use ACP. I don't understand how that is achieved. The way the text is written, it seems to imply that it is a property of IPv6 ULAs. Which I don't think is your intention. So I would like to see clarification. > > See also (2) at end. > >> The discovery text in section6.3 states that discovery should be run in >> every physical interface. Is this intended to be restricted by policy, as >> described in section 5, bullet 2? > > As said above for 5 bullet 2, it is permissible to be modified, the ACP > draft does not suggest or recommends any modifications other than those in 6.3, > aka: physical interfaces. I think you simply need to say "Unless modified by policy as noted earlier, ..." As currently written, the text prohibits the policy over-reide you want. > >> *** The explanation in section 6.5 on channel selection (and security >> protocol selection) is worded as if the described behavior will lead to >> reliable interoperation. The text on why there are limitations (reasonable) >> doe not explain why mandating dTLS support would not be a reasonable step. (I >> hope I missing something, as otherwise this is a major problem rather than >> being minor.) It is also hard to align this with the requirements in section >> 6.7.3. > > I think there is no issue. Let me explain: I think I understand your reasoning, and the various constraints that you face. However, when all is said and done, you seem to have two mechanisms, and no requirement that all devices must support one of them. Which seems to mean that two independent devices may not have an implementation of the channel / security selection that leads to interoperability. That seems a major issue. Saying "we couldn't find a good answer" is not usually an acceptable IETF answer for interoperability. (text retained for future discussion) > > We beat ourselves up for quite a long time about MTI channel options > (Mandatory To Implement) and figured there is no one-size-fits-all. > > The first challenge for dTLS was that there is no RFC specifying how to run > IPv6 over dTLS. There are widely supported / deployed variations > like OpenConnect etc. running IP/IPv6 over dTLS, but they all > havesome home-brewed complex session maintenance mechanisms because > they where built for hub&spoke user VPN solutions. We do not only not > need that additional complexity, there is also no RFC for them (only > expired individual drafts). > > In the absence of a simple standardized specification and deployment > experience in non-constrained equipment with simple IPv6 over dTLS, we > did not want to make it MTI for devices that had a better alternative. > > I then tried to figure out what would need to be written to specify > how to run IPv6 over dTLS, and that became 6.7.2. > > Many type of constrained devices want to run everything over > dTLS because they already got that code for CoAP etc. pp, and > they do often not have IPsec code in their software. Therefore > dTLS is the better MTI for those devices. > > I have modified the dTLS MUST sentence to make it clearer: > > A constrained ACP node that can not support IPsec MUST support dTLS. The change helps, but as noted above does not seem sufficient. ... > >> If I have used section 6.10.3 properly, when the Zone-ID is 0, all nodes >> within the ULA are within a flat address space. that does turn the address >> into an identifier. It is, as far as I can tell from the description, >> still a locator in that packets will be routed to the node using the >> address including the node identifier. It just means that routing has to >> work in /127 addresses. (There is also a reference to "identifier" in >> 6.10.3.1. From the usage there, I think that the intention is that this is >> the generic "name" for the node. Given that it is routable, it is simply >> an addresses, not an identifier or a locator.) > > My driver license number is (intended to be) an identifier. It stays an indentifier > even if someone starts building a network with a routing table for driver license > numbers. Likewise, the intent of zone=0 numbers is to be identifiers. And > yes, they do double a locators when you have a flat routing table which is > what we do in this doc. > > We just didn't describe options where zone=0 would not double as a locator, > that is meant to be left for future work if we see sufficient use cases for it. > We just tried to make the definitions extensible and define the intent of the > format to be that of identifiers. Since the design specifically uses the same field as both the identifier and the locator, I do not think it is fair or appropriate to describe it as being purely an identifier. The fact that you could possibly use it as an identifier later doesn't make it so. > >> The description in section 6.10 / 6.10.1 / 6.10.2 is about the schema >> identification is very confusing, and arguably a bad design. > > I guess you mean 6.10.2 / 6.10.3 and 6.10.4 ? Yes. > >> The two schemas use the same schema identifier. > ^^^^^^^^^^ > > Type ? Yes. Part of my reaction to this whole section is that it looks much like the mistake we made originally in defining classful IP addresses. You are trying to guess the correct use cases, and defining specific address structures with specific encodings for each one. With only a few encodings available. This seems to be a recipe for being wrong later in ways that hurt. > > The difference in interpretation >> is actually provided by the last bit in the upper 64. If these are the >> same schema, then it should not need a bit to differentiate them. They >> should be explained as a single schema. Which would presumably result in >> the Z bit being part of the zone / subnet field. If they are two >> different schemas, then move the differentiation to part of the schema >> identifier (making it 3 bits). > > We did not want to make Z part of the base schemas 6.10.2 "Type" code because > that would also make the Vlong scheme one bit shorter and that would reduce > virtualization space in Vlong by a factor of 2. > > So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out > of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. > > Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO > textually correct to have them in different subsections. > > Carving out bits like Z isn't ideal, but in between the ULA prefix, > the 64 bit local part we must have for external interfaces and > best utilization of bits, we tried to rather optimize address space > utilization and not beauty of encoding. > > Having at the end allows (as written) use of /63 instead of 2 * /64 > routes. I am not sure how important this would be in the future. > > If you feel strongly about more beauty in encoding, > i can move Z to the left and remove the notion of the possible /63 route > optimization possible through the placement of Z. Since the two different uses of the Z bit with type 00b are quite distinct, trying to enable aggregation seems counter-productive. While I hate to push on a point you describe as aesthetics, having the Z bit, occuring after the Zone / subnet-ID field, but defining whether the field is a zone or a subnet, seems awkward for insufficient reason. I would recommend moving the Z bit up so it is after the type, and at the front of each of the two sections reiterate that this subscheme is indicated by the Z bit being { 0 | 1 }. > >> This sort-of different but sort-of the same >> makes implementation "interesting". Even if this is extra bit is only >> needed for schema 00b, it should be in front of the Zone / subnet, not >> after it. This leads to the obvious observation that either we need two >> bits, of which we will have 3 settings, and we will use the fourth setting >> as an extension mechanism if we ever need more formats, or we need at least >> three bits all the time because we seriously think there will be more >> formats. > > I very much hope there is no "interesting" implementation aspect; > nothing in the current scheme that makes implemenation harder. If you > have an example that you fear, i would like to hear it. > > To me, we are just defining address space allocation schemes. I suppose likely implementations will use mask definitions that will make it work. I pity the code reviewer. > >> In section 6.10.5, after stating that it is not even known what the needed >> usage is for more V values > > Which sentence are you referring to when you say "not even known what the > needed usage is" ? I can't find it, but i would like to rectify it > if it actually is still there. The text reads "further values use via definition in future work." In the zone-id scheme, it is one bit. For some reason, it is 8 or 16 bits here. > > The two addressing space Zone and Vlong do certainly address two very different > network and node design considerations. In the Zone addressing format, we > wanted to have a scheme for potentialy very large networks. Enterprises > plus their attached IoT networks with hundreds of thousands of nodes. > Worldwide enterprise WN/campus/branches. Or massive DCs. The one V bit > in this space is just to solve the single most likely problematic implementation > consideration of ANI: Allowing ANI to have a complete port number space of > itself, therefore not conflicting with traditional management port number > usage (if needed). Or similar. > > The Vlong addressing space goes the other way, allowing to build out > management plane or ASA more easily as containers or other lightweight > component models where each such component has its own address. We > also had brainstormed some network layer functions (proxies) that had to > eat up address space, so would use V bits. > > Both approaches are IMHO very valid and important options that we wanted to be able to > support and let developers and deployments choose which one fits > them best. > >> the document goes on to introduce the >> complexity of classful nodes numbers, with the leading bit indicating how >> long the node-number is. Yes, the rest of the text in that bullet tries to >> explain why you need both sizes. It seems like needless complexity that >> begs for mistakes in implementation. > > I was taking the example use cases we brainstormed into account, and > some of them would require a lot more addresses in the node than others, > therefore these two choices. See my comments above. Trying to encode specific use cases into the address format seems a problematic answer to an admittedly difficult question. What would break if you didn't define any of this? > > Ultimately, we need to break through the chicken and egg problem > of how to build more self-managing networks. These will require > a different number of addresses inside nodes. Anything more intelligent > than address space allocations would become a complex dependency > making implementation/adoption even slower. I don't think that > offering 2, 256, 64k addresses per node is too much flexibility. > It IMHO necessary and sufficient to explore and we'll see what sticks. Variation is needed. That was true of allocations in IP. encoding the variations proved a bad choice. > >> In section 6.11.1.11 in describing the prefix lengths, I thought that the >> point of zone addressing was to allow the use of /64 prefixes. But it >> seems here that we will not do so ? > > As mentioned above: This document does not describe the routing setup for /64 > (or /63 with Z-bit) routing aggregation. There are multiple options, > but we could not conclude on a single solution that we felt to be > appropriate for this document. Instead it was only very important > to carve out addressing space to support this. The net effect seems to be to prohibt the very things that you went to a lot of trouble to enable in your addressing design. ... >> *** Section 10.3.2 paragraph 2 says that devices should change the meaning >> of "admin down" to mean "down for everything except ACP / Anima". I can >> understand why, in an autonomic network, such a state is desirable. However, >> that really should be a different state from "admin down". Operators already >> understand "admin down" as meaning that this interface will not be used for any >> traffic. Changing that is fairly drastic. "admin limited" or "admin ACP-Only" >> would seem much better than changing the meaning of "admin down". The >> justification in the text seems to be a desire to prevent an operator from >> doing what he intends. that seems backwards. (Note that the distinction >> between administrative state vs operational state, aka failed, is already well >> understood.) > > Well, this is in an informative section, so hopefully something we can agree to disagree. If this were truly informative, it would not belong in this document at all. Changing the behavior of widely understood configuration behaviors is NOT a small thing. Changing the permissions models for widely understood configuration operations is also NOT a small thing. My suggestion is that you remove all of this material. If you feel it is important, write an I-D for standards track on evolving the configuration model for robust ANIMA. While I think the change is a mistake, you clearly have the right to cause the discussion. Hiding the topic in an "informational" note in the ACP document seems VERY wrong. Also note that in your discussion below, you talk about the equivalence of admin down and physical down. Most management models I know of treat these as quite distinct. SO that is at best a red herring. (text retained for context of further discussions.) > > I strongly believe that the most easy way to operationalize the ACP and > achieve its goals is what we have written. > > The historic equivalence of "down" = "admin down" = "physical down" is one of > the the most fundamental problem of remote management in networks. > > We really need to start thinking of separate layers of (remote) management. > Network services on one hand and physical infra on the other. > > The first thing to do this is to separate operations such as "down" > into "admin down" that affects networks services and "phy down" that > affects the physcial infra. > > If you have existing commands like "shutdown" that today do both, > the safe mapping is to let them do the safe thing in the future, e.g: > only "admin down", and introduce new commands for the phy operations, > e.g.: "phy shutdown" or the like. > And then protect those dangerous commands even further against unintentional or > intentional misuse. > > Think of ACP/ANI also as a seamless inband version of a DCN. As an operator > of the actual data network, you also didn't have any access to bring down the DCN > and cut yourself off from the network you manage. YOu could only screw > up that network you're meant to manage. > > And if your network consists of VMs in a DC, a "shutdown" on their > interfaces will also not bring down physical interfaces necessary > to reach the VM. > > In optical networks you often have an inband physcial ethernet management > channel. Making/breaking that one is completely different from making/breaking > your data-plane, aka: data fiber colors. > >> *** The notion in 10.3.6 that the device should refuse to disable >> functionality when an authorized administrator directs such seems flatly wrong. > > The authorization to break your own remote management connectivity > would be a property of the certificate. clearly whoever enrolled > the device with a certificate denying that capaility to the operator > did NOT authorize the administrator to break connectivity. The security model change seems as problematic as the above configuration change. > >> Editorial / Nits: . >> In the various formats in section 6.10, the lowest bit of the upper 64 bits >> is mandated to be 0. Presumably, there is some reason for doing this. It >> would be nice to explain it. > > Sorry, not clear what you're referring to. Can you give me an > explicit reference ? I should ahve removed this note. It was a side-effect of the presentation and ordering, not a problem on its own. Sorry. From nobody Mon May 7 20:00:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D418612D875; Mon, 7 May 2018 20:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SyrDSVejYXa; Mon, 7 May 2018 19:59:59 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::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 2CDE012D876; Mon, 7 May 2018 19:59:58 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id v24-v6so1318806plo.3; Mon, 07 May 2018 19:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2hNFjazk6jGxYg6/MTd8DyczMntpHlm92ZyIZ45PVUM=; b=T4sUEc8m5OJTIcluCVPGS8RhqEC09ldWDWfTcs3uCnBp5Secr8GDeqlGkomljbTpv/ zMVVAyIDj3GMlCFAD4z6RDVcMOLvepzN5W9urZpjFBunptb6YoCktIzHRwJcgZZcsfk+ VGcGbx+1gjcnIS8pa4mtBXBPXv/1kvnX0/He/9HezM9Ogd/mUmzvnPKCofuVYFMGGcOu yotzH9oOiIOU2GQbRXQJoKmf9PoK4zpdaZTTm/R1e8CFZUPIyAfHkG6tSfrJ1mfK8EdY 8VmvafPz/3MB4tRU8g1bblbcjohtjfTEMBywNPyg6DCjMNCCy52Ur4fbfLC7S4RrLl6f uqMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2hNFjazk6jGxYg6/MTd8DyczMntpHlm92ZyIZ45PVUM=; b=n7PqaXKVuQh5gStpO1OrzB7DP0WOjOHqb5pqn3g9PQ253xzrKan+cE1A7KCAl1rDMS SwPFJmcWrlyvmZRyVKtk8CqjASOPXrF9IJo8rAaKPm0gcUYtGcZsDUDHzfMkP/K8c3cA rhKSg0PXMSg+3qdYCYZKkE5e1sTwhm2WZTmTzYo4HWg8RQx3UZFtSlY1kPCpxXID1Z7O PZzwp0JE5D1zk0KcDfK90YJ7yuPmfn5uyMQucL1IwiMP5YW9v1T1AIOX7H1WSqaWvBhZ qa67LBznURDMCSv7w5Kpf97XE50F2YB86BC0oWjeXdtmHvEjT6gEEn705XwBHXJnqAq3 cd1Q== X-Gm-Message-State: ALQs6tD9XLlcrretNZCzYjWITC+vNmCDjGzq8dT5Oolyv7R3wTz3Tfc8 Tr1u4bIbf5wdInhZhaWLrHbVmkp0 X-Google-Smtp-Source: AB8JxZrReU4oL8jj6C40fxdJ5A6Z9ZpiUKE7Bxc6MSNb8Y3Axr3wv+fmag0SOejwJ+0MzGz57UhKhA== X-Received: by 2002:a17:902:c81:: with SMTP id 1-v6mr39100545plt.126.1525748398221; Mon, 07 May 2018 19:59:58 -0700 (PDT) Received: from [192.168.178.26] (65.21.255.123.dynamic.snap.net.nz. [123.255.21.65]) by smtp.gmail.com with ESMTPSA id 204-v6sm36929343pgf.61.2018.05.07.19.59.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 19:59:57 -0700 (PDT) Sender: Brian Carpenter To: "Joel M. Halpern" , Toerless Eckert Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <04e810ae-1233-f3ea-2773-d818abdedfe2@gmail.com> Date: Tue, 8 May 2018 14:59:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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: [Anima] ULA issue [Re: Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13] 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, 08 May 2018 03:00:01 -0000 CCs trimmed: On 08/05/2018 11:05, Joel M. Halpern wrote: ... >> >>> I presume there is not an assumption that all ULA addressed communicating >>> with a node which supports the ACP will be over the ACP. As I understand >>> it, ULAs may well have other uses outside of ANIMA / the ACP. Which leads >>> to a question about how the text in 6.1.3 "If the CDP URL uses an IPv6 ULA, >>> the ACP node will try to reach it via the ACP." is expected to be supported? I guess I read that sentence as simply meaning: "If the CDP URL uses an IPv6 ULA within the ACP's ULA prefix, the ACP node will try to reach it via the ACP." which is a trivial statement. If that's not what it means, I am confused too. Brian From nobody Wed May 9 17:19:46 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6776A12D7EF; Wed, 9 May 2018 17:19:44 -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, RCVD_IN_DNSWL_MED=-2.3, 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 t2Re_tVGtdgB; Wed, 9 May 2018 17:19:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978A11200A0; Wed, 9 May 2018 17:19:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EF1AAB80DF1; Wed, 9 May 2018 17:19:41 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, anima@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180510001941.EF1AAB80DF1@rfc-editor.org> Date: Wed, 9 May 2018 17:19:41 -0700 (PDT) Archived-At: Subject: [Anima] =?utf-8?q?RFC_8366_on_A_Voucher_Artifact_for_Bootstrappin?= =?utf-8?q?g_Protocols?= 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, 10 May 2018 00:19:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8366 Title: A Voucher Artifact for Bootstrapping Protocols Author: K. Watsen, M. Richardson, M. Pritikin, T. Eckert Status: Standards Track Stream: IETF Date: May 2018 Mailbox: kwatsen@juniper.net, mcr+ietf@sandelman.ca, pritikin@cisco.com, tte+ietf@cs.fau.de Pages: 23 Characters: 47891 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-anima-voucher-07.txt URL: https://www.rfc-editor.org/info/rfc8366 DOI: 10.17487/RFC8366 This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. This document is a product of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 9 23:06:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94A126CE8; Wed, 9 May 2018 23:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNt98Nij4SDs; Wed, 9 May 2018 23:06:45 -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 773DC127078; Wed, 9 May 2018 23:06:42 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EF53058C4E5; Thu, 10 May 2018 08:06:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DF1BE440218; Thu, 10 May 2018 08:06:36 +0200 (CEST) Date: Thu, 10 May 2018 08:06:36 +0200 From: Toerless Eckert To: "Pascal Thubert (pthubert)" Cc: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Message-ID: <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.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, 10 May 2018 06:06:50 -0000 Thanks, Pascal, sorry for the delay, Comments inline. Version: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Diff to prior version (-14 for Joel Halpern) http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/8b4436edaa720eadb5839120400fd1e89d3289b0/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Will commit as -14 when i am through with the other -13 feedback. Cheers Toerless On Mon, Feb 26, 2018 at 05:25:58PM +0000, Pascal Thubert (pthubert) wrote: > Reviewer: Pascal Thubert on behalf of IOT-DIR; > > I am an assigned IoT directorate reviewer for draft-ietf-anima-autonomic-control-plane-13. > > These comments were written primarily for the benefit of the INT and OPS Areas Directors from the IoT perspective. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the IoT Directorate, please see https://datatracker.ietf.org/group/iotdir/about/ and for Directorates in general please see https://www.ietf.org/about/groups/directorates/. > > > I'll be away for the next 2 weeks and could not finish the review in time for this heavy document, but at least I made it through till the RPL section. In the interest of time, let me share what I already have. > > > > Summary > > ------------- > > The summary of the review is that the document is Ready for Publication, with comments. > > > > > > Major comments > > ------------------------ > > > > - " in-band" and "out of band network " > > should be defined since it is fundamental to understand that the ACP takes place in the same physical links as the data plane, as opposed to dedicated management ports (correct?); Good point, done. (got a bit too long to paste here, so pls. check diff). > > - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; Not sure i understand the "point on Michaels enrollment draft". I am happy to add pointers to variations of ACP design aspects for informational purposes to show that/how it can be modified, but Michaels drafts i think are all variation of the BRSKI design, so the ACP would be completly unaffected by them, right ? Wrt. constrained devices and L2. I didn't want to touch section 3 for what you suggested because that really a very formulistic section going back to the charter 1 justifications of ANIMA and matched with the three numbered use case explanations in the introduction. Instead i wrote text at the end of the introduction, now section 1.1, This got longer than i hoped, but it was really a big missing piece to pitch the ACP and give early on context for implementers and reminding of the charter goal of reusing the best available existing protocols/function. The text got longer specifically also because i did not want to fall into the trap of making claims whether or not ACP is applicable to specific IOT networks or (even worse) assuming IOT is always constrained. Therefore mentioning of OT networks (IMHO big part of IOT, and often totally non-constrained), explanation of why RPL, and at the end a statement about constrained environments. There is also a new paragraph in 10.8 about TCP/TLS vs. CoAP/DTLS as a possible constained environment variant in the future. > - " Inside the ACP VRF, each node sets up a loopback interface with its ULA IPv6 address" > This is the first time, IPv6 is discussed; would have been nice to introduce that the Node has IPv6, that it needs a ULA and that ACP assigns it. This discussion could be done in conjunction with the comment above; Actually, section 1. introduction already mentions that the ACP provides IPv6 and that the stable-connectivity document describes how to interoperate with IPv4 only OAM. I added to the new 1.1 section (see above) the following paragraph, which i hope is a useful context setting and pitch: The ACP uses only IPv6 to avoid complexity of dual-stack ACP operations (IPv6/IPv4). Nevertheless, it can without any changes be integrated into even otherwise IPv4-only network devices. The data-plane itself would not need to change, it could continue to be IPv4 only. For such IPv4 only devices, the IPv6 protocol itself would be additional implementation footprint only used for the ACP. > - About "The ttl > parameter SHOULD be 3.5 times the period so that up to three > consecutive messages can be dropped before considering an > - announcement expired. " > > This is the only discussion on the ttl field of the M_FLOOD. Though its meaning is quite obvious, the behavior associated to it should be defined. Added: When a service announcer using these parameters unexpectely dies immediately after sending the M_FLOOD, receivers would consider it expired 210 seconds later. When a receiver tries to connect this dead service earlier, it will experience a failing connection and use that as an indication the service is dead and select another instance of the same service instead. > - "In the above (recommended) example the period of sending of the" > Is this RECOMMENDED IOW normative?? Hmmm... Sure, why not. Less guessing/experiementation for this. Modified to RECOMMENDED. > - Text P 25 says "At this time in the lifecycle of ACP nodes, it is unclear whether it > is feasible to even decide on a single MTI (mandatory to implement) > security association protocol across all ACP nodes" > but then P27 "It MUST support ESP > with AES256 for encryption and SHA256 hash and MUST NOT permit weaker > crypto options." > > and then " A baseline ACP node MUST support IPsec natively and MAY support IPsec > via GRE. A constrained ACP node MUST support dTLS. ACP nodes > connecting constrained areas with baseline areas MUST therefore > > support IPsec and dTLS." > > Seems that text P25 should go? P27: An ACP node supporting native IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for encapsulation. It MUST support ESP... (parameters). clarified to: P27: An ACP node that is supporting native IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for encapsulation. It MUST then support ESP... (parameters). Also: ACP nodes supporting ACP via GRE/IPsec MUST support IPsec security setup.. clarified to: An ACP node that is supporting ACP via GRE/IPsec MUST then support IPsec security setup.. Aka: P25 is correct, there is no single MTI. 6.7.3 defines the actual requirement for two different profiles: "baseline ACP node" and "constrainted ACP node". The two requirements in P27 are only conditional MUSTs defining the details of the IPsec profiles assuming a node does support IPsec or IPsec/GRE. Let me know if this is still unclear, and if so, how you would suggest to make it better readable. > - "Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local > > Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] > > with L=1]." > > This needs to be more crisp. ULA is defined in RFC 4193 but the term ULA-Random is not. I think you mean that 3.2.2. of RFC 4193 is the way addresses are formed, if so please say so. The best practice RFC 8064 recommends use of RFC 7217. I understand that privacy is not a concern but does it hurt? Anyway please point at section 6.10 and 6.11.1.11 The term "ULA-Random" was used in the discussions on ANIMA mailing list re. ULA, so admittedly i didn't check that the term as it stands is actually not defined/used in rfc4193 - but its just meant to imply ULA with L=1, nothing more. I've removed the use of ULA-Random from the text and just refer now to 4193 with L=1 (also pointing to 3.1. of rfc4193 defining L). I have also added a note that the hash uses our own ACP definition instead of rfc4193 3.2.2. Paragraph is now: Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local Addresses (ULA), as defined in with L=1 (as defined in section 3.1 of ). Note that the random hash for ACP loopback addresses uses the definition in and not the one of section 3.2.2. 8064/7217 are irrelevant here if i understand it correctly because we define the addressing scheme for anything following the ULA prefix ourselves for ACP addresses. Let me know if i do misunderstad what you where trying to suggest re. 8064/7217. > - " > RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with multicast support". Implementations should support also other modes. > > Note: Root indicates mode in DIO flow" > > Why "should" ? there is no much point supporting the other modes is there? Section 6.11.1.13 says that SRH is not used so this is inconsistent. You only need MOP 2 or 3, 3 is you do multicast which at the moment does not appear to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 which is a superset of MOP 2, and that's it (see 6.3.1 of RFC 6550). Probably a transcription error on my side when i took your RPL summary and wrote it down. Fixed according to above. > - "The lack of a RPI (the header defined by [RFC6553]), means that the > data-plane will have no rank value that can be used to detect loops. > As a result, traffic may loop until the TTL of the packet reaches > zero. " > > Since we have reliable links and no stretch (section 6.11.1.7), loops should be exceedingly rare. It could be recommended to send the DIOs 2-3 times to inform children when losing the last parent. Note that the technique in section "8.2.2.6. Detaching" of RFC 6550 should be favored over that in section "8.2.2.5. Poisoning" because it allows local connectivity. Also, It should be said that a node should select more than one parent, at least 3 if possible, and send DAOs to all of then in parallel. This provides multi Not sure why your paragraph ends apruptly, buts its also in the archive, so its not a mistake on my email end. Hopefully nothing significant missing. I have replaced the suggestive text that followed your above quoted text in the draft: There are a variety of heuristics that can be used to signal from the data-plane to the RPL control plane that a new route is needed. With a hopefuly correct transcription of your suggestion: Since links in the ACP are assumed to be mostly reliable (or have link layer protection against loss) and because there is no stretch according to , loops should be exceedingly rare though. There are a variety of mechanisms possible in RPL to further avoid temporary loops: DIOs SHOULD be sent 2...3 times to inform children when losing the last parent. The technique in section 8.2.2.6. (Detaching) SHOULD be favored over that in section 8.2.2.5. (Poisoning) because it allows local connectivity. Also, nodes SHOULD select more than one parent, at least 3 if possible, and send DAOs to all of then in parallel. > - "ACP nodes MUST perform standard IPv6 operations across ACP virtual > interfaces including SLAAC (Stateless Address Auto-Configuration - > RFC4862])" > > They may actually prefer Optimistic DAD RFC 4429 since address duplication is highly improbable as long as you . Added: "Optimistic Duplicate Address Detection (DAD)" according to is RECOMMENDED because the likelyhood for duplicates between ACP nodes is highly improbable as long as the address can be formed from a globally unique local assigned identifier (e.g.: EUI-48/EUI-64, see below). > Minor comments > > ------------------------ > > > > > > - About "[RFC7575] defines the fundamental ... " > > for readability, it may be nicer to indicate the title of an RFC when it is referenced first; e.g. the text above would become > > " Autonomic Networking: Definitions and Design Goals" [RFC7575] defines the fundamental ... Ok, i am punting this one for now to RFC editor after playing around a bit with the XML options - and not being satisfied... and having references for 50 RFCs in the doc: [RFC Editor: Question: Is it possible to change the first occurrances of [RFCxxxx] references to "" [RFCxxxx] ? the XML2RFC format does not seem to offer such a format, but i did not want to duplicate 50 first references to be duplicate - one reference for title mentioning and one for RFC number.] If RFC editor comes back and can't do this easier than i can in XML, i'll try to go through the chores when doc is in RFC editor queue. > - about "or network plane (there is no well-established name for this)" > > The term network plane is not used again in the document. This text may go away. Done. > You may consider using "security and transport substrate" instead, since it is used elsewhere in the document. "autonomic communications fabric" = ACP including ACP GRASP (ACP GRASP provides discovery etc..). "security and transport substrate" == the parts of ACP used by "ACP GRASP" (aka: The secure IPv6 forwarding of ACP). Subtle difference. > Also, please be consistent on whether you use hyphen or not and use that globally, e.g. for the above, and pane like in "forwarding plane" or "out of band network "; Fixed up "out of band" (no hyphens) and "in-band" (with hyphen). Not sure why but this is what MS word spelling checker suggested to me. RFC editor will override if these are not the best choices. > - "data-plen" > Typo? Done > - "OAM applications ("Operations Administration and Management)" > > Consider using "Operations Administration and Management (OAM) applications " instead; same goes for SDN, ASA, VRF, etc... Ok. Tried to fix up all the instances i could find. > - " MIC: "Manufacturer Installed Certificate". Another word not used in this document to describe an IDevID." > > MIC is not used in the document, maybe inform of this equivalence in the IDevID definition instead; same goes for SUDI. Note that UDI is use just once and may not need an entry here. The definitions of those non-necessary terms are there to help others who like me start out not being security experts and are confused about those equivalent or related terms. I specifically didn't want to include discussions about these terms in the definitions that are relevant (eg: IDevID) so as not to clobber up that text. Instead, readers would just look up those redundant terms when they are like me initially confused about them. > - "RPL: \"IPv6 Routing Protocol for Low-Power and Lossy Networks\". The routing protocol used in the ACP." > > Maybe point on [RFC6550]? Done > - "Connecting over non-ACP Layer-3 clouds initially requires a tunnel between ACP nodes." > > I understands that it is one tunnel between each pair of adjacent ACP nodes, correct? I read "a tunnel" as an end-to-end tunnel, which sounds different Changed to: Connecting over non-ACP Layer-3 clouds requires explicit configuration. See . This may be automated in in the future through autodiscovery mechanisms across L3. > - "ACP relies on group security" > > Add "The" Done > - "An ACP node MUST have keying > material consisting of a certificate (LDevID), with which it can > cryptographically assert its membership in the ACP domain and trust > anchor(s) associated with that certificate with which it can verify > the membership of other nodes (see Section 6.1.2)." > > This is convoluted. Could you make it 2 sentences? Fixed to: The ACP relies on group security. An ACP domain is a group of nodes that trust each other to participate in ACP operations. To establish trust, each ACP member requires keying material: An ACP node MUST have a certificate (LDevID) and a trust anchor (TA) consisting of a certificate (chain) used to sign the LDevID of all domain members. The LDevID is used to cryptographically assert membership in the ACP domain, the TA to verify the membership of other nodes in the ACP domain (see ). > - " Note: LDevID ("Local Device IDentification") is the term used to > indicate a certificate that was provisioned by the owner of a node as > opposed to IDevID ("Initial Device IDentifier") that may has been > loaded on the node during manufacturing time. Those IDevID do not > include owner and deployment specific information to allows autonomic > establishment of trust for the operations of an ACP domain (e.g.: > between two ACP nodes without relying on any third party)." > LDevID was already defined in the terminology. This text may move there or go away. Gone. I added the note that LDevID can not be used directly for ACP to the terminology definition of IDevID. > - " This document uses the term ACP in many places where its reference > document use the word autonomic." > > Add [RFC7575] after "reference document" Done. > - " "routing-subdomain" is the autonomic subdomain that is used to > calculate the hash for the ULA prefix of the ACP address of the node." > > Do you mean ULA suffix? No, the Global ID. Fixed. Actually, i also sumbled across this: RFC4193 uses "Prefix" for the first 7 bits of a ULA address, but we have used use the term ULA prefix to refer to the first 48 bits of a ULA address, so i've clarified this more in the terminology. > - " o If the node certificates indicate a CDP (or OCSP) then the peer's > certificate must be valid according to those criteria. e.g.: OCSP > check across the ACP or not listed in the CRL retrieved from the > CDP." > > Please define CDP and OSCP, and/or reference a RFC is possible. Done. Using RFC5280. Hope thats correct, otherwise IESG SEC review should help. > - "enrolment" > Typo Fixed. > - "This can > use a single GRASP M_FLOOD message as shown in above example." > Actually the example is now below. Please reference the figure. Done. Actually its still "above", or i am heavily confused. > > - "The protocol could for example could have been" > > Typo Fixed. > - "if the IPsec connecting" > > Typo? More like sentence structure was strange. Fixed to: "Even if the IPsec connection from Bob succeeded, Alice might prefer another secure protocol over IPsec" > - "ACP wide service discovery" > ACP-wide Fixed. > - "if the IPsec connecting In most other solution > designs such distributed discovery does not exist at all or was added > as an afterthought and relied upon inconsistently" > > Consider removing or rephrasing : ) Removed: Sentence wasn't that bad, but easier removed instead of trying to justify negative observations about reality without being called out to provide even more proof. > > - Maybe consider moving the discussion on multicast P29 -30 to annex? Why Multicast is not used is an interesting discussion but not critical for the protocol operation. Done. > - "it is not quite clear yet what exactly the implications are > to make GRASP flooding depend on RPL DODAG convergence and how > difficult it would be to let GRASP flooding access the DODAG > information" > > Let's chat then. There's work on reliable multicast for RPL using BIER. Yeah if i would just get around to that ;-) For now moved together into informative section together with te multicast discus. > - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the > security and transport substrate for the GRASP instance run inside > the ACP ("ACP GRASP"). " > > "running" inside the ACP? Maybe rephrase more globally? > This instance of GRASP runs across the ACP secure channels.. > - "OAM protocols no not require IPv4: The ACP may carry OAM " > Typo no->do Fixed. > - "Consider a network that has multiple NOCs in different locations. > Only one NOC will become the DODAG root. Other NOCs will have to > send traffic through the DODAG (tree) rooted in the primary NOC." > A figure would help. I remember all the discussions we had about setting the prf bits in remote NOCs Sorry. A bit low on cycles right now. Hopefully i'll get around to it later. Created a wish list entry in changelog. > - "RPPL." > Typo Fixed. > - "Administrative Preference ([RFC6552], 3.2.6 " > > The section is correct but that is RFC 6550. Done > > - "This is a standard issue > with tunneling, not specific to running the ACP across it." > Do you really mean Standard or would Classical work better? This is an issue of tunnels, not an issue of running the ACP across a tunnel. > - "Even though loopback interfaces where originally d" > Typo Where -> were Done. > - Section 3, 4, 9 and 10 may move to Annex (by moving the section after the tag) since they are not normative and do not contribute to the understanding of the protocol. This way there should not be a need to indicate normative in other sections. Sections 3, 4 and 9 are fairly short and the flow of the document depends on them being in their particular location. Section 10 could go into an appendix, but it makes not a lot of difference, but past experience has shown that Annex text is a lot less likely to be read given how the RFCs are structured. We had 10 in Annex and moved it up for exactly that reason. > - Well Noted that Section 14 Will be removed/. > Sorry for being interrupted here, Thanks you so much! Toerless From nobody Wed May 9 23:08:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644C112711A; Wed, 9 May 2018 23:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOElW4qxECqi; Wed, 9 May 2018 23:08:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5222127078; Wed, 9 May 2018 23:08:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 16959B8469D; Wed, 9 May 2018 23:08:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, anima@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180510060806.16959B8469D@rfc-editor.org> Date: Wed, 9 May 2018 23:08:06 -0700 (PDT) Archived-At: Subject: [Anima] =?utf-8?q?RFC_8368_on_Using_an_Autonomic_Control_Plane_fo?= =?utf-8?q?r_Stable_Connectivity_of_Network_Operations=2C_Administration?= =?utf-8?q?=2C_and_Maintenance_=28OAM=29?= 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, 10 May 2018 06:08:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8368 Title: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) Author: T. Eckert, Ed., M. Behringer Status: Informational Stream: IETF Date: May 2018 Mailbox: tte+ietf@cs.fau.de, michael.h.behringer@gmail.com Pages: 24 Characters: 59777 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-anima-stable-connectivity-10.txt URL: https://www.rfc-editor.org/info/rfc8368 DOI: 10.17487/RFC8368 Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. 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 an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies. This document is a product of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 9 23:14:24 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6E9126DC2; Wed, 9 May 2018 23:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ5j95A76ZVb; Wed, 9 May 2018 23:14:22 -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 E99A0126CE8; Wed, 9 May 2018 23:14:21 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DF69F58C4D8; Thu, 10 May 2018 08:14:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C8C36440218; Thu, 10 May 2018 08:14:17 +0200 (CEST) Date: Thu, 10 May 2018 08:14:17 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: "Pascal Thubert (pthubert)" , iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" Message-ID: <20180510061417.qptyeweyhr3x7it5@faui48f.informatik.uni-erlangen.de> References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.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, 10 May 2018 06:14:23 -0000 Brian: as part of the fixes for Pascals review, i added a section 1.1, applicability & scope that mentions the "professionally managed" and also has one small paragraph at the end re. constrained devices/ networks. I hope this provides qukc/useful scoping of what the ACP does. Cheers Toerless On Tue, Feb 27, 2018 at 10:17:01AM +1300, Brian E Carpenter wrote: > Pascal, > > Great review! > > > - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; > > Perhaps this point belongs in draft-ietf-anima-reference-model. ANIMA is chartered for "professionally managed" networks, and the reference model says: "At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI [autonomic infrastructure] and well-defined minimal functionality. They are currently out of scope." So while your point is very valid, it's been considered out of scope so far. > > I'll leave the rest of your excellent comments to the ACP authors. > > Thanks > Brian -- --- tte@cs.fau.de From nobody Thu May 10 07:17:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE836124E15; Thu, 10 May 2018 07:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2ohsvcn5MGI; Thu, 10 May 2018 07:17:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125E412E049; Thu, 10 May 2018 07:17:36 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DFCCB58C4CC; Thu, 10 May 2018 16:17:32 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CE893440218; Thu, 10 May 2018 16:17:32 +0200 (CEST) Date: Thu, 10 May 2018 16:17:32 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Joel Halpern , draft-ietf-anima-autonomic-control-plane.all@ietf.org, draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org Message-ID: <20180510141732.o6ccutritu5zel2v@faui48f.informatik.uni-erlangen.de> References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Editorial note [Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13] 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, 10 May 2018 14:17:39 -0000 [RFC Editor: GRASP draft is in RFC editor queue, waiting for dependencies, including ACP. Please ensure that this section reference to 2.5.2 in GRASP draft will be updated in case any last-minute changes in GRASP would make this number change. On Tue, May 08, 2018 at 10:20:41AM +1200, Brian E Carpenter wrote: > > >> Editorial / Nits: > >> Section 6.3, in talking about DULL GRASP refers to the grasp internet > >> draft. It refers to section 3.5.2.2. there is no 3.5.2.2 in the grasp > >> I-D. As best I can guess the reference should be 2.5.2. > > Since GRASP and ACP are bound together by normative references, we'd better > make sure that this cross-reference is correct at the AUTH48 stage. > Maybe insert a comment for the the RFC Editor in the XML? > > Regards > Brian -- --- tte@cs.fau.de From nobody Fri May 11 19:10:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B6412DA22; Fri, 11 May 2018 19:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejbIJll6yrOQ; Fri, 11 May 2018 19:09:50 -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 DC5FC12426E; Fri, 11 May 2018 19:09:49 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6539E58C4BC; Sat, 12 May 2018 04:09:44 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4F753440218; Sat, 12 May 2018 04:09:44 +0200 (CEST) Date: Sat, 12 May 2018 04:09:44 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180512020944.kg5mehv2bfc2ydle@faui48f.informatik.uni-erlangen.de> References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 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, 12 May 2018 02:09:54 -0000 Diff: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Latest version: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt On Mon, May 07, 2018 at 07:05:10PM -0400, Joel M. Halpern wrote: > Comments in line. Areas of clear agreement elided. Comments in line. Removed sections closed by you. > On 5/7/18 3:30 PM, Toerless Eckert wrote: > > > If the rsub is empty, but the extensions are not > > > empty, it looks like there will be two plus signs (following the optional > > > acp-address) before the first extension. Is that intended as the way to > > > indicate the absence of the rsub? > > > > Yes. Otherwise it would be ambiguous to parse. Haven't > > written something about this because i think readers eithrer > > don't care or the can figure it out easily. > > I think it would help to state it explicitly. In this specification, the "acp-address" field is REQUIRED, but future variations (see may use local information to derive the ACP address. In this case, "acp-address" could be empty. Such a variation would be indicated by an appropriate "extension". If "acp-address" is empty, and "rsub" is empty too, the "local-part" will have the format "rfcSELF + + extension(s)". The two plus characters are necessary so the node can unambiguously parse that both "acp-address" and "rsub" are empty. > (section 6.1.1) > > > It also seems odd that the rsub (which is a > > > domain extension) appears in the local-part of the domain information, not in > > > the domain name. Even though for hashing purposes it is concatenated, with a > > > period, with the domain name. > > > If these oddities are intentional, then there ought to be explanations so the > > > reader is not confused. > > > > The difference between domain and routing-subdomain are explained directly after > > the BNF: > > > > "domain" is used to indicate the ACP Domain across which all ACP nodes trust each other and are willing to build ACP channel to each other. See . > > > > "routing-subdomain" is the autonomic subdomain that is used to calculate the hash for the ULA prefix of the ACP address of the node. ... > > > > Added: > > > > "rsub" needs to be in the "local-part"; it could not syntactically be separated from "domain-name" if "domain" is just a domain name. It also makes it easier for domain name to be a valid e-mail target. > > Okay. It is odd, but works. Any easier choice coming to mind ? I wouldn't know how. > > > I presume there is not an assumption that all ULA addressed communicating > > > with a node which supports the ACP will be over the ACP. As I understand > > > it, ULAs may well have other uses outside of ANIMA / the ACP. Which leads > > > to a question about how the text in 6.1.3 "If the CDP URL uses an IPv6 ULA, > > > the ACP node will try to reach it via the ACP." is expected to be supported? > > > > The reason is that the ACP certificate maintenance runs across the ACP so that > > we have a simple security model for the ACP certificate lifecycle. We do not > > want to have to figure out the impact of attacks against connectivity to the CDP > > when it runs across the data plane. After all, these are ACP certificates are > > also renewed via EST across the ACP. > > > > I added the following explanation sentence: > > > > Reaching the CDP across the ACP implies that the CDPs > > need to be reachable via the ACP, for example by running CDPs on > > registrars or on devices connected to the ACP via ACP connect (see ). > > While a useful addition, that is not what I was asking about. The text as > written seems to say that simply because the RDP uses an IPv6 ULA, the node > will know to use ACP for the communication. I understand why we awant the > communication to use ACP. I don't understand how that is achieved. The way > the text is written, it seems to imply that it is a property of IPv6 ULAs. > Which I don't think is your intention. Originally it was meant to be indicated by ULA address, yes, but i think its better/simpler just to decide based on DNS being used. > So I would like to see clarification. Ok, refined the text as follows: If the CDP URL uses an IPv6 address (ULA address when using the addressing rules specified in this document), the ACP node will connect to the CDP via the ACP. If the CDP uses a domain name, the ACP node will connect to the CDP via the data-plane. It is common to use domains name for CDP(s), but there is no requirement for the ACP to support DNS. Any DNS lookup in the data-plane is not only a possible security issue, but it would also not indicate whether the resolved address is meant to be reachable across the ACP. Therefore, the use of an IPv6 address versus the use of a DNS name doubles as an indicator whether or not to reach the CDP via the ACP. A CDP can be reachable across the ACP either by running it on a node with ACP or by connecting its node via ACP connect (see ). The CDP SHOULD use an ACP domain certificate for its HTTPs connections. The connecting ACP node SHOULD verify that the CDP certificate used during the HTTPs connection has the same ACP address as indicated in the CDP URL of the nodes ACP domain certificate > > > The discovery text in section6.3 states that discovery should be run in > > > every physical interface. Is this intended to be restricted by policy, as > > > described in section 5, bullet 2? > > > > As said above for 5 bullet 2, it is permissible to be modified, the ACP > > draft does not suggest or recommends any modifications other than those in 6.3, > > aka: physical interfaces. > > I think you simply need to say "Unless modified by policy as noted earlier, > ..." As currently written, the text prohibits the policy over-reide you > want. changed to: Unless modified by policy as noted earlier ( bullet point 2.), native interfaces (e.g.: physical interfaces on physical nodes) SHOULD be initialized ... > > > *** The explanation in section 6.5 on channel selection (and security > > > protocol selection) is worded as if the described behavior will lead to > > > reliable interoperation. The text on why there are limitations (reasonable) > > > doe not explain why mandating dTLS support would not be a reasonable step. (I > > > hope I missing something, as otherwise this is a major problem rather than > > > being minor.) It is also hard to align this with the requirements in section > > > 6.7.3. > > > > I think there is no issue. Let me explain: > > I think I understand your reasoning, and the various constraints that you > face. However, when all is said and done, you seem to have two mechanisms, > and no requirement that all devices must support one of them. Which seems > to mean that two independent devices may not have an implementation of the > channel / security selection that leads to interoperability. That seems a > major issue. Saying "we couldn't find a good answer" is not usually an > acceptable IETF answer for interoperability. > (text retained for future discussion) Think of channel protocols like interface types. We also do not have a requirement that all nodes MUST have WiFI or 100 Mbps ethernet or 40 Gbps fiber. And yet we manage to build an Internet across all those device interconnecting them all. Same thing with channel security protocols. The requirement right now describes two profiles (6.7.3): "baseline ACP node" - MUST support IPsec "constrained ACP node" - node that can not support IPsec, MUST support dTLS. In the same way you use a WiFi access point connecting your ethernet with your WiFi equipment, you would use a baseline ACP node that also supports dTLS to interconnect constrained and unconstrained nodes. This also well matches how constrained node networks are built: Some gateway node that is not constrained, but also supports whatever (mostly constrained) network/radio the constrained nodes use. If you think this should be explained more in more detail in the doc, let me know. I could simply add above example as text. > > A constrained ACP node that can not support IPsec MUST support dTLS. > The change helps, but as noted above does not seem sufficient. See above, the "can not support IPsec" was only meant as a definition of what a constrained node is, but not to change the basic property of ACP networks that different links / nodes can have different protocol options and that there is no "one-fits-all" MTI necessary. > > > If I have used section 6.10.3 properly, when the Zone-ID is 0, all nodes > > > within the ULA are within a flat address space. that does turn the address > > > into an identifier. It is, as far as I can tell from the description, > > > still a locator in that packets will be routed to the node using the > > > address including the node identifier. It just means that routing has to > > > work in /127 addresses. (There is also a reference to "identifier" in > > > 6.10.3.1. From the usage there, I think that the intention is that this is > > > the generic "name" for the node. Given that it is routable, it is simply > > > an addresses, not an identifier or a locator.) > > > > My driver license number is (intended to be) an identifier. It stays an indentifier > > even if someone starts building a network with a routing table for driver license > > numbers. Likewise, the intent of zone=0 numbers is to be identifiers. And > > yes, they do double a locators when you have a flat routing table which is > > what we do in this doc. > > > > We just didn't describe options where zone=0 would not double as a locator, > > that is meant to be left for future work if we see sufficient use cases for it. > > We just tried to make the definitions extensible and define the intent of the > > format to be that of identifiers. > > Since the design specifically uses the same field as both the identifier and > the locator, I do not think it is fair or appropriate to describe it as > being purely an identifier. The fact that you could possibly use it as an > identifier later doesn't make it so. Do we (IETF) have any normative or otherwise uncontested definition for the criteria required to call an address an identifier ? Here are the things that make the ACP address an identifier to me: - It is assigned once to the device and not meant to change over the lifetime of the device. - It does not change when i move the node to a different location and re-connect the device. - It is the unique part of the ACP domain certificate (other than the private key) and used to identify the device (privat key is used to authenticate it, but the private key may change over time, for example when renewing the certificate). Would be happy to elaborate this in the doc more explicitly, e.g.: like written above. > Part of my reaction to this whole section is that it looks much like the > mistake we made originally in defining classful IP addresses. You are > trying to guess the correct use cases, and defining specific address > structures with specific encodings for each one. With only a few encodings > available. This seems to be a recipe for being wrong later in ways that > hurt. The only equivalent to classfull addressing i see is for the fixed prefix-length handed out to each node, 1 bit (2 addresses) with zone addresses, 8/16 bits (256/64k address) for Vlong, but its NOT assignment to network segments as in IPv4 A/B/C but to nodes. We didn't introduce choices lightly. There are compromises to be made when you want some lightweight address allocation scheme, not expecting to have complex address registry or management system in the backend but simple registrars. see below for more > > The difference in interpretation > > > is actually provided by the last bit in the upper 64. If these are the > > > same schema, then it should not need a bit to differentiate them. They > > > should be explained as a single schema. Which would presumably result in > > > the Z bit being part of the zone / subnet field. If they are two > > > different schemas, then move the differentiation to part of the schema > > > identifier (making it 3 bits). > > > > We did not want to make Z part of the base schemas 6.10.2 "Type" code because > > that would also make the Vlong scheme one bit shorter and that would reduce > > virtualization space in Vlong by a factor of 2. > > > > So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out > > of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. > > > > Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO > > textually correct to have them in different subsections. > > > > Carving out bits like Z isn't ideal, but in between the ULA prefix, > > the 64 bit local part we must have for external interfaces and > > best utilization of bits, we tried to rather optimize address space > > utilization and not beauty of encoding. > > > > Having at the end allows (as written) use of /63 instead of 2 * /64 > > routes. I am not sure how important this would be in the future. > > > > If you feel strongly about more beauty in encoding, > > i can move Z to the left and remove the notion of the possible /63 route > > optimization possible through the placement of Z. > > Since the two different uses of the Z bit with type 00b are quite distinct, > trying to enable aggregation seems counter-productive. > > While I hate to push on a point you describe as aesthetics, having the Z > bit, occuring after the Zone / subnet-ID field, but defining whether the > field is a zone or a subnet, seems awkward for insufficient reason. > > I would recommend moving the Z bit up so it is after the type, and at the > front of each of the two sections reiterate that this subscheme is indicated > by the Z bit being { 0 | 1 }. Done. (see diff). > > I very much hope there is no "interesting" implementation aspect; > > nothing in the current scheme that makes implemenation harder. If you > > have an example that you fear, i would like to hear it. > > > > To me, we are just defining address space allocation schemes. > > I suppose likely implementations will use mask definitions that will make it > work. I pity the code reviewer. I have read the code and tested in the lab IPv6 embedded RP adressing and didn't feel pityfull about the job. But i weigh the overall system complexity. Embedded-RP simplified a lot of other parts of the multicast system at the cost of introducing an addressing scheme. I think similarily, the ACP addressing scheme simplifies the overall system complexity, especially registrars. > > > In section 6.10.5, after stating that it is not even known what the needed > > > usage is for more V values > > > > Which sentence are you referring to when you say "not even known what the > > needed usage is" ? I can't find it, but i would like to rectify it > > if it actually is still there. > > The text reads "further values use via definition in future work." In the > zone-id scheme, it is one bit. For some reason, it is 8 or 16 bits here. Thanks, changed sentence to: V: Virtualization bit: Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme. The existing text, now directly after the list, explains examples when a device would likely need 256 or 64k addresses: existing text: ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge nodes ... > > > the document goes on to introduce the > > > complexity of classful nodes numbers, with the leading bit indicating how > > > long the node-number is. Yes, the rest of the text in that bullet tries to > > > explain why you need both sizes. It seems like needless complexity that > > > begs for mistakes in implementation. > > > > I was taking the example use cases we brainstormed into account, and > > some of them would require a lot more addresses in the node than others, > > therefore these two choices. > > See my comments above. Trying to encode specific use cases into the address > format seems a problematic answer to an admittedly difficult question. > > What would break if you didn't define any of this? One could save the 2.5 bits (Type, Z) indicating the structure of the address inside the address by encoding the designated format of the address instead in an extension field of the ACP address information in the certificate. We would certainly still want to have the same type of addresses, e.g.: 2,256,64k local addresses, option for zones and address to assign to ACP connect interfaces (manual addressing scheme) IMHO. So, at best we could save the 2.5 bits if we wanted to keep the functionality, which i think is all required. I would be quite afraid of doing such a drastic change this late in the process because i think it will take a long time to foresee the resulting complexity introduced for registars and any other place that now can deduct the semantic from the address and would then have to access to what the certificate indicates in a different way (e.g.: access to the certificate). Note that the length of the ACP information field in the cert is also limited, so this type of extension might end up looking even uglier to be short *sigh*. I was always thinking that this type of more flexible option would be a good next-step, but not a safe first step. It would make a lot more sense after hearing implementation/deployment experiences, especially to correctly support important options we may have overlooked in the current schemes. Just redoing what we have differently to save 2.5 bits isn't worth it IMHO. > > Ultimately, we need to break through the chicken and egg problem > > of how to build more self-managing networks. These will require > > a different number of addresses inside nodes. Anything more intelligent > > than address space allocations would become a complex dependency > > making implementation/adoption even slower. I don't think that > > offering 2, 256, 64k addresses per node is too much flexibility. > > It IMHO necessary and sufficient to explore and we'll see what sticks. > > Variation is needed. That was true of allocations in IP. encoding the > variations proved a bad choice. Let me repeat that we are not doing any network/subnet prefix encoding which is what IPv4 A/B/C was. And there are IMHO good examples how encoding in IPv6 did save the day from complexity (at least all the stuff done for IPv6 multicast, ASM/SSM, zones, Embedded-RP) was highly useful. > > > In section 6.11.1.11 in describing the prefix lengths, I thought that the > > > point of zone addressing was to allow the use of /64 prefixes. But it > > > seems here that we will not do so ? > > > > As mentioned above: This document does not describe the routing setup for /64 > > (or /63 with Z-bit) routing aggregation. There are multiple options, > > but we could not conclude on a single solution that we felt to be > > appropriate for this document. Instead it was only very important > > to carve out addressing space to support this. > The net effect seems to be to prohibt the very things that you went to a lot > of trouble to enable in your addressing design. Maybe i do not understand your comment correctly, but i do not think it is correct. We just have not defined recommended mechanisms how to set up routing to use /64 zone routes. That is something IMHO better done in a followup document because all the cases where we did see a need for znes where really very specific to particular deployment styles and would not be applicable to the mayority of ACPs. Nevertheless, we felt those cases where important enough to reserve bits for them through the zone field. > ... > > > *** Section 10.3.2 paragraph 2 says that devices should change the meaning > > > of "admin down" to mean "down for everything except ACP / Anima". I can > > > understand why, in an autonomic network, such a state is desirable. However, > > > that really should be a different state from "admin down". Operators already > > > understand "admin down" as meaning that this interface will not be used for any > > > traffic. Changing that is fairly drastic. "admin limited" or "admin ACP-Only" > > > would seem much better than changing the meaning of "admin down". The > > > justification in the text seems to be a desire to prevent an operator from > > > doing what he intends. that seems backwards. (Note that the distinction > > > between administrative state vs operational state, aka failed, is already well > > > understood.) > > > > Well, this is in an informative section, so hopefully something we can agree to disagree. > > If this were truly informative, it would not belong in this document at all. > Changing the behavior of widely understood configuration behaviors is NOT a > small thing. Changing the permissions models for widely understood > configuration operations is also NOT a small thing. > > My suggestion is that you remove all of this material. If you feel it is > important, write an I-D for standards track on evolving the configuration > model for robust ANIMA. While I think the change is a mistake, you clearly > have the right to cause the discussion. > > Hiding the topic in an "informational" note in the ACP document seems VERY > wrong. > > Also note that in your discussion below, you talk about the equivalence of > admin down and physical down. Most management models I know of treat these > as quite distinct. SO that is at best a red herring. Hmm. I really only CLI derived from Cisco IOS, and there the interface level "shutdown" command doubles IMHO both as admin down and as phy down, so i would contend that this is a red herring. It actually does show up in diagnostic CLI as "admin down", but is also bringing down phy state. Therefore it is also used to diagnose phy, .e.g: shutting down one side of a supposed direct p2p link to verify the phy change on the other side. That practical experience is what the text and direction is based on. Whats an example where admin/phy down are separate in your experience ? I don't know how you define "truly informative". I simply meant informational as compared to standards track wrt. to not impacting interoperability, but also as a precursor work to give opportunity for gaining more experience before attempting to go standard. If/when i find time i definitely would like to investigate how this could be formalized through a YANG model for ACP so that it can become standard, but i definitely agree that especially this part of the YANG model would be highly difficult to get to before any experience is gained with this. I therefore would very much hesitate removing this text from the document, it was specifically asked for several times in the working group to understand how the promised reliability of the ACP against operator/contoller operation could be achieved. Having this in a first round (this document) as "informational" is IMHO a good and important thing. > (text retained for context of further discussions.) > > > > > I strongly believe that the most easy way to operationalize the ACP and > > achieve its goals is what we have written. > > > > The historic equivalence of "down" = "admin down" = "physical down" is one of > > the the most fundamental problem of remote management in networks. > > > > We really need to start thinking of separate layers of (remote) management. > > Network services on one hand and physical infra on the other. > > > > The first thing to do this is to separate operations such as "down" > > into "admin down" that affects networks services and "phy down" that > > affects the physcial infra. > > > > If you have existing commands like "shutdown" that today do both, > > the safe mapping is to let them do the safe thing in the future, e.g: > > only "admin down", and introduce new commands for the phy operations, > > e.g.: "phy shutdown" or the like. > > And then protect those dangerous commands even further against unintentional or > > intentional misuse. > > > > Think of ACP/ANI also as a seamless inband version of a DCN. As an operator > > of the actual data network, you also didn't have any access to bring down the DCN > > and cut yourself off from the network you manage. YOu could only screw > > up that network you're meant to manage. > > > > And if your network consists of VMs in a DC, a "shutdown" on their > > interfaces will also not bring down physical interfaces necessary > > to reach the VM. > > > > In optical networks you often have an inband physcial ethernet management > > channel. Making/breaking that one is completely different from making/breaking > > your data-plane, aka: data fiber colors. > > > > > *** The notion in 10.3.6 that the device should refuse to disable > > > functionality when an authorized administrator directs such seems flatly wrong. > > > > The authorization to break your own remote management connectivity > > would be a property of the certificate. clearly whoever enrolled > > the device with a certificate denying that capaility to the operator > > did NOT authorize the administrator to break connectivity. > > The security model change seems as problematic as the above configuration > change. We have recurringly heard from customers that mistakes in managing remote equipment and loosing connectivity is a mayor pain point. Creating an operational option that limits/disables operators ability to impact phy level connectivity that remote management depends upon and therefore reducing this risk and cost factor seems to me like a very logical pah forward. Whether or not this should be indicated in the certificate or differently is definitely wide open. I agree that none of these operational interface level changes are a piece of cake given how we have in the IETF not tried to define different access levels to configuration so far, at least not between some phy/infra access level and network-services access level. As said above in my first reply that you didn't comment on, i think a good part of what i am looking for may happen through other means already, such as when a router is just a VM running on an OS. At least in early versions of this that i'd seen, this implicitly disabled the ability to modify phy state from the router VM, and of course complaints where raised that phy mods where necessary, but at least this evolution could give raise to pause and rethink HOW to permit doing this. So i would at least like to pledge with you that it is a good thing to have this type of discussion in an informational way in this RFC instead of doing nothing or trying to go standard YANG directly as a first step. It did get into the spec because of the desire of the working group. > > > Editorial / Nits: > . > > > In the various formats in section 6.10, the lowest bit of the upper 64 bits > > > is mandated to be 0. Presumably, there is some reason for doing this. It > > > would be nice to explain it. > > > > Sorry, not clear what you're referring to. Can you give me an > > explicit reference ? > > I should ahve removed this note. It was a side-effect of the presentation > and ordering, not a problem on its own. Sorry. Cheers Toerless From nobody Fri May 11 19:21:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8840012DA22; Fri, 11 May 2018 19:21: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 eG2N7AeHsB6d; Fri, 11 May 2018 19:21:13 -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 07E1212DA19; Fri, 11 May 2018 19:21:13 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id w3-v6so3140215pgv.12; Fri, 11 May 2018 19:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4/cmppu1HKN3hEv8Agxjmzz4jGI4RvFffKosg/WSYZc=; b=Y6hT8twFRNwXOZDtrEaYayx/aZg0R2cv6+ygUdXEmra/34cQiFnjnT30DBOKDcBdrV /syLKD9CmttKvfs1ROstLhzIVlet3bR7k1v6hoAzWLiFXTWZ11bA/jUQdjFNMr1aaP9d YV9e2/rsrDBSxe9em1t5Oev/vbdxYC3+OdYbJ96sys98LTUEyoaF56cVx5V+3cCVzJOs KkZgcxQGVkRacENYTX+ajjiv1bxZxUVyQOdaarTSUV+9OEMWPCgUk0CscOQYLZlyJeZv YZD0Cxmri0lxae/AdK27oPww4pw5e85rzgiMTiT9i0NEgN9vlcHGs6n29+YqSWPTBlIK p2Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4/cmppu1HKN3hEv8Agxjmzz4jGI4RvFffKosg/WSYZc=; b=kj12ZuRMb0iRO/5AkVyc1Z9/fhDI4hOUmk07wBRZZxSskUg0PHkFZCWe46CrPktUjr 1exKbh3Dp98aIkelAcQYcRV8NWxkhHjc1sBXl5tMiQs9oDpN0e4tXTkfoXHFhKLZiuca EFfxIgHlYvVrPhCc+Rd3I2HBn4eKNLXUGfNv+pY0Ds+W8afAHYI9f/w/hjUJ0Px0lU4j GTgctBl1s0OAUocxEYyKWapwqd0CG6s2ZWeNdjdAeCf81DWu0LodHNFjfcQowqpz/aSg 5HNqPe/RsXxVNTxjgXlvISLi4wIIla7iNJXjkNR8J8GTynC1gpZmndA29QG3oak5oXzB oIGQ== X-Gm-Message-State: ALKqPwfRWtwdLrGDLOPgi9hgP9CzN/XuQWGd7lG6EiBNO3k/oIN8Ddig ezDFwfV4lm/MWHwnpSUER440eQ== X-Google-Smtp-Source: AB8JxZoQaSsjMub5jwsgkbB0gBKzfyHpA8TSmt0p/7SzG7fXVUU3nu3sSpNfeGBGCV7HBMqZtGz+kg== X-Received: by 2002:a62:469b:: with SMTP id o27-v6mr1263962pfi.124.1526091672243; Fri, 11 May 2018 19:21:12 -0700 (PDT) Received: from [192.168.178.26] (211.245.69.111.dynamic.snap.net.nz. [111.69.245.211]) by smtp.gmail.com with ESMTPSA id b28-v6sm5609388pfl.168.2018.05.11.19.21.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 19:21:11 -0700 (PDT) Sender: Brian Carpenter To: Toerless Eckert Cc: "Pascal Thubert (pthubert)" , iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510061417.qptyeweyhr3x7it5@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <6730013f-49e4-97c5-4872-a75c8ca5ab41@gmail.com> Date: Sat, 12 May 2018 14:21:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180510061417.qptyeweyhr3x7it5@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane 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, 12 May 2018 02:21:15 -0000 Hi Toerless, Yes, section 1.1 works for me. Personally I hope that some of what we do here can later become self-deploying in unmanaged networks, but that is out of WG charter at the moment and purely a dream. Regards Brian On 10/05/2018 18:14, Toerless Eckert wrote: > > Brian: as part of the fixes for Pascals review, i added a section 1.1, > applicability & scope that mentions the "professionally managed" > and also has one small paragraph at the end re. constrained devices/ > networks. I hope this provides qukc/useful scoping of what the ACP > does. > > Cheers > Toerless > > On Tue, Feb 27, 2018 at 10:17:01AM +1300, Brian E Carpenter wrote: >> Pascal, >> >> Great review! >> >>> - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; >> >> Perhaps this point belongs in draft-ietf-anima-reference-model. ANIMA is chartered for "professionally managed" networks, and the reference model says: "At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI [autonomic infrastructure] and well-defined minimal functionality. They are currently out of scope." So while your point is very valid, it's been considered out of scope so far. >> >> I'll leave the rest of your excellent comments to the ACP authors. >> >> Thanks >> Brian > From nobody Sun May 13 16:38:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31652126CC7; Sun, 13 May 2018 16:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_DBL_ABUSE_MALW=2.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNmUrPj3MzfT; Sun, 13 May 2018 16:38:37 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D635C124B18; Sun, 13 May 2018 16:38:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B361D3E4531; Sun, 13 May 2018 16:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1526254717; bh=+OtFLVCTAJV9KaKoJghReEmaXVZRevC9GgDYN//NDis=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=V2AjbvMfHyv97NkOgRurpUo2OyqQ+mXqaPOfGFefLG0bF9iHEilIjLxzGwqzbWkdl 73cc64UyTM1Lm5I2vOUA5XinpPQCxgQ5aoGHp+8I1fZVE/Dt05wo1/0iNeb5zdCxZm G6tL0aB3BOOe62fotcecTTUMKbdFir5zrl2mmh1o= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 599543E4530; Sun, 13 May 2018 16:38:36 -0700 (PDT) To: Toerless Eckert Cc: rtg-dir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> <20180512020944.kg5mehv2bfc2ydle@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: <10178dd0-e0d2-784e-e2a6-0cb91c3bc952@joelhalpern.com> Date: Sun, 13 May 2018 19:38:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180512020944.kg5mehv2bfc2ydle@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 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, 13 May 2018 23:38:40 -0000 Trimmed. Top posting for clarity. Mostly, agreement. On the MTI Security, I will leave it to the relevant ADs to decide if they find what is in there sufficient. On the identifier vs locator, I think the way you are using the terms is confusing. But it is not worth continued argumentation.Some text elaborating along the lines you provide (retained below) would help. I have tried reading the section on addressing inside the ACP more carefully. Thank you for moving the Z bit. I have retained the earlier discussion on this topic below, in case we still need it. Reading the section, I think that the problem is more basic. I agree that the document needs to define that we are using a ULA. And because of the certificate behaviors, there is significant advantage in defining what ULA prefix is used. Given that, I do not see what use there is in all the other format definition. I suspect I am missing something very basic. Why not leave this to the deploying operator? It is not like it can be autonomic, since something has to tell the devices what format to use, and what numbers within some of the formats to use. I could imagine something that said "in the absence of configuration, construct device addresses according to one specific algorithm, so as to simplify bootstrap. But it would be a simple scheme. Yours, Joel On 5/11/18 10:09 PM, Toerless Eckert wrote: > > Diff: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt > > Latest version: > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt > ... > Here are the things that make the ACP address an identifier to me: > > - It is assigned once to the device and not meant to change over the lifetime > of the device. > - It does not change when i move the node to a different location > and re-connect the device. > - It is the unique part of the ACP domain certificate (other than the private key) > and used to identify the device (privat key is used to authenticate it, > but the private key may change over time, for example when renewing the certificate). > > Would be happy to elaborate this in the doc more explicitly, e.g.: like written > above. (Context: Addressing inside the ACP.) >> Part of my reaction to this whole section is that it looks much like the >> mistake we made originally in defining classful IP addresses. You are >> trying to guess the correct use cases, and defining specific address >> structures with specific encodings for each one. With only a few encodings >> available. This seems to be a recipe for being wrong later in ways that >> hurt. > > The only equivalent to classfull addressing i see is for the fixed prefix-length > handed out to each node, 1 bit (2 addresses) with zone addresses, 8/16 bits > (256/64k address) for Vlong, but its NOT assignment to network segments > as in IPv4 A/B/C but to nodes. > > We didn't introduce choices lightly. There are compromises to be made when you > want some lightweight address allocation scheme, not expecting to have complex > address registry or management system in the backend but simple registrars. > > see below for more > >>> The difference in interpretation >>>> is actually provided by the last bit in the upper 64. If these are the >>>> same schema, then it should not need a bit to differentiate them. They >>>> should be explained as a single schema. Which would presumably result in >>>> the Z bit being part of the zone / subnet field. If they are two >>>> different schemas, then move the differentiation to part of the schema >>>> identifier (making it 3 bits). >>> >>> We did not want to make Z part of the base schemas 6.10.2 "Type" code because >>> that would also make the Vlong scheme one bit shorter and that would reduce >>> virtualization space in Vlong by a factor of 2. >>> >>> So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out >>> of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. >>> >>> Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO >>> textually correct to have them in different subsections. >>> >>> Carving out bits like Z isn't ideal, but in between the ULA prefix, >>> the 64 bit local part we must have for external interfaces and >>> best utilization of bits, we tried to rather optimize address space >>> utilization and not beauty of encoding. >>> >>> Having at the end allows (as written) use of /63 instead of 2 * /64 >>> routes. I am not sure how important this would be in the future. >>> >>> If you feel strongly about more beauty in encoding, >>> i can move Z to the left and remove the notion of the possible /63 route >>> optimization possible through the placement of Z. >> >> Since the two different uses of the Z bit with type 00b are quite distinct, >> trying to enable aggregation seems counter-productive. >> >> While I hate to push on a point you describe as aesthetics, having the Z >> bit, occuring after the Zone / subnet-ID field, but defining whether the >> field is a zone or a subnet, seems awkward for insufficient reason. >> >> I would recommend moving the Z bit up so it is after the type, and at the >> front of each of the two sections reiterate that this subscheme is indicated >> by the Z bit being { 0 | 1 }. > > Done. (see diff). > >>> I very much hope there is no "interesting" implementation aspect; >>> nothing in the current scheme that makes implemenation harder. If you >>> have an example that you fear, i would like to hear it. >>> >>> To me, we are just defining address space allocation schemes. >> >> I suppose likely implementations will use mask definitions that will make it >> work. I pity the code reviewer. > > I have read the code and tested in the lab IPv6 embedded RP adressing > and didn't feel pityfull about the job. But i weigh the overall system > complexity. Embedded-RP simplified a lot of other parts of the > multicast system at the cost of introducing an addressing scheme. > I think similarily, the ACP addressing scheme simplifies the overall system > complexity, especially registrars. > >>>> In section 6.10.5, after stating that it is not even known what the needed >>>> usage is for more V values >>> >>> Which sentence are you referring to when you say "not even known what the >>> needed usage is" ? I can't find it, but i would like to rectify it >>> if it actually is still there. >> >> The text reads "further values use via definition in future work." In the >> zone-id scheme, it is one bit. For some reason, it is 8 or 16 bits here. > > Thanks, changed sentence to: > > V: Virtualization bit: Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme. > > The existing text, now directly after the list, explains examples > when a device would likely need 256 or 64k addresses: > > existing text: > ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge nodes ... > >>>> the document goes on to introduce the >>>> complexity of classful nodes numbers, with the leading bit indicating how >>>> long the node-number is. Yes, the rest of the text in that bullet tries to >>>> explain why you need both sizes. It seems like needless complexity that >>>> begs for mistakes in implementation. >>> >>> I was taking the example use cases we brainstormed into account, and >>> some of them would require a lot more addresses in the node than others, >>> therefore these two choices. >> >> See my comments above. Trying to encode specific use cases into the address >> format seems a problematic answer to an admittedly difficult question. >> >> What would break if you didn't define any of this? > > One could save the 2.5 bits (Type, Z) indicating the structure of the > address inside the address by encoding the designated format of the > address instead in an extension field of the ACP address information in > the certificate. We would certainly still want to have the same type > of addresses, e.g.: 2,256,64k local addresses, option for zones and > address to assign to ACP connect interfaces (manual addressing scheme) > IMHO. So, at best we could save the 2.5 bits if we wanted to keep the > functionality, which i think is all required. > > I would be quite afraid of doing such a drastic change this late in > the process because i think it will take a long time to foresee the > resulting complexity introduced for registars and any other place > that now can deduct the semantic from the address and would then have > to access to what the certificate indicates in a different way (e.g.: > access to the certificate). Note that the length of the ACP information > field in the cert is also limited, so this type of extension might end > up looking even uglier to be short *sigh*. > > I was always thinking that this type of more flexible option would > be a good next-step, but not a safe first step. It would make a lot > more sense after hearing implementation/deployment experiences, > especially to correctly support important options we may have > overlooked in the current schemes. Just redoing what we have differently > to save 2.5 bits isn't worth it IMHO. > >>> Ultimately, we need to break through the chicken and egg problem >>> of how to build more self-managing networks. These will require >>> a different number of addresses inside nodes. Anything more intelligent >>> than address space allocations would become a complex dependency >>> making implementation/adoption even slower. I don't think that >>> offering 2, 256, 64k addresses per node is too much flexibility. >>> It IMHO necessary and sufficient to explore and we'll see what sticks. >> >> Variation is needed. That was true of allocations in IP. encoding the >> variations proved a bad choice. > > Let me repeat that we are not doing any network/subnet prefix encoding which is > what IPv4 A/B/C was. And there are IMHO good examples how encoding in IPv6 > did save the day from complexity (at least all the stuff done for IPv6 > multicast, ASM/SSM, zones, Embedded-RP) was highly useful. > >>>> In section 6.11.1.11 in describing the prefix lengths, I thought that the >>>> point of zone addressing was to allow the use of /64 prefixes. But it >>>> seems here that we will not do so ? >>> >>> As mentioned above: This document does not describe the routing setup for /64 >>> (or /63 with Z-bit) routing aggregation. There are multiple options, >>> but we could not conclude on a single solution that we felt to be >>> appropriate for this document. Instead it was only very important >>> to carve out addressing space to support this. >> The net effect seems to be to prohibt the very things that you went to a lot >> of trouble to enable in your addressing design. > > Maybe i do not understand your comment correctly, but i do not > think it is correct. We just have not defined recommended mechanisms > how to set up routing to use /64 zone routes. That is something IMHO > better done in a followup document because all the cases where we > did see a need for znes where really very specific to particular > deployment styles and would not be applicable to the mayority of ACPs. > Nevertheless, we felt those cases where important enough to reserve > bits for them through the zone field. > >> ... >>>> *** Section 10.3.2 paragraph 2 says that devices should change the meaning >>>> of "admin down" to mean "down for everything except ACP / Anima". I can >>>> understand why, in an autonomic network, such a state is desirable. However, >>>> that really should be a different state from "admin down". Operators already >>>> understand "admin down" as meaning that this interface will not be used for any >>>> traffic. Changing that is fairly drastic. "admin limited" or "admin ACP-Only" >>>> would seem much better than changing the meaning of "admin down". The >>>> justification in the text seems to be a desire to prevent an operator from >>>> doing what he intends. that seems backwards. (Note that the distinction >>>> between administrative state vs operational state, aka failed, is already well >>>> understood.) >>> >>> Well, this is in an informative section, so hopefully something we can agree to disagree. >> >> If this were truly informative, it would not belong in this document at all. >> Changing the behavior of widely understood configuration behaviors is NOT a >> small thing. Changing the permissions models for widely understood >> configuration operations is also NOT a small thing. >> >> My suggestion is that you remove all of this material. If you feel it is >> important, write an I-D for standards track on evolving the configuration >> model for robust ANIMA. While I think the change is a mistake, you clearly >> have the right to cause the discussion. >> >> Hiding the topic in an "informational" note in the ACP document seems VERY >> wrong. >> >> Also note that in your discussion below, you talk about the equivalence of >> admin down and physical down. Most management models I know of treat these >> as quite distinct. SO that is at best a red herring. > > Hmm. I really only CLI derived from Cisco IOS, and there the > interface level "shutdown" command doubles IMHO both as admin down and > as phy down, so i would contend that this is a red herring. It actually > does show up in diagnostic CLI as "admin down", but is also bringing down > phy state. Therefore it is also used to diagnose phy, .e.g: shutting down > one side of a supposed direct p2p link to verify the phy change on the > other side. That practical experience is what the text and direction is > based on. > > Whats an example where admin/phy down are separate in your experience ? > > I don't know how you define "truly informative". I simply meant > informational as compared to standards track wrt. to not impacting > interoperability, but also as a precursor work to give opportunity > for gaining more experience before attempting to go standard. > > If/when i find time i definitely would like to investigate how this > could be formalized through a YANG model for ACP so that it can become standard, > but i definitely agree that especially this part of the YANG model would > be highly difficult to get to before any experience is gained with > this. > > I therefore would very much hesitate removing this text from the document, it was > specifically asked for several times in the working group to understand > how the promised reliability of the ACP against operator/contoller > operation could be achieved. Having this in a first round (this document) > as "informational" is IMHO a good and important thing. > >> (text retained for context of further discussions.) >> >>> >>> I strongly believe that the most easy way to operationalize the ACP and >>> achieve its goals is what we have written. >>> >>> The historic equivalence of "down" = "admin down" = "physical down" is one of >>> the the most fundamental problem of remote management in networks. >>> >>> We really need to start thinking of separate layers of (remote) management. >>> Network services on one hand and physical infra on the other. >>> >>> The first thing to do this is to separate operations such as "down" >>> into "admin down" that affects networks services and "phy down" that >>> affects the physcial infra. >>> >>> If you have existing commands like "shutdown" that today do both, >>> the safe mapping is to let them do the safe thing in the future, e.g: >>> only "admin down", and introduce new commands for the phy operations, >>> e.g.: "phy shutdown" or the like. >>> And then protect those dangerous commands even further against unintentional or >>> intentional misuse. >>> >>> Think of ACP/ANI also as a seamless inband version of a DCN. As an operator >>> of the actual data network, you also didn't have any access to bring down the DCN >>> and cut yourself off from the network you manage. YOu could only screw >>> up that network you're meant to manage. >>> >>> And if your network consists of VMs in a DC, a "shutdown" on their >>> interfaces will also not bring down physical interfaces necessary >>> to reach the VM. >>> >>> In optical networks you often have an inband physcial ethernet management >>> channel. Making/breaking that one is completely different from making/breaking >>> your data-plane, aka: data fiber colors. >>> >>>> *** The notion in 10.3.6 that the device should refuse to disable >>>> functionality when an authorized administrator directs such seems flatly wrong. >>> >>> The authorization to break your own remote management connectivity >>> would be a property of the certificate. clearly whoever enrolled >>> the device with a certificate denying that capaility to the operator >>> did NOT authorize the administrator to break connectivity. >> >> The security model change seems as problematic as the above configuration >> change. > > We have recurringly heard from customers that mistakes in managing remote > equipment and loosing connectivity is a mayor pain point. Creating > an operational option that limits/disables operators ability to > impact phy level connectivity that remote management depends upon and therefore > reducing this risk and cost factor seems to me like a very logical pah > forward. Whether or not this should be indicated in the certificate > or differently is definitely wide open. > > I agree that none of these operational interface level changes are > a piece of cake given how we have in the IETF not tried to define > different access levels to configuration so far, at least not > between some phy/infra access level and network-services access level. > > As said above in my first reply that you didn't comment on, i think a > good part of what i am looking for may happen through other means > already, such as when a router is just a VM running on an OS. At least > in early versions of this that i'd seen, this implicitly disabled > the ability to modify phy state from the router VM, and of course > complaints where raised that phy mods where necessary, but at least this > evolution could give raise to pause and rethink HOW to permit doing this. > > So i would at least like to pledge with you that it is a good thing to > have this type of discussion in an informational way in this RFC instead > of doing nothing or trying to go standard YANG directly as a first step. > It did get into the spec because of the desire of the working group. > >>>> Editorial / Nits: >> . >>>> In the various formats in section 6.10, the lowest bit of the upper 64 bits >>>> is mandated to be 0. Presumably, there is some reason for doing this. It >>>> would be nice to explain it. >>> >>> Sorry, not clear what you're referring to. Can you give me an >>> explicit reference ? >> >> I should ahve removed this note. It was a side-effect of the presentation >> and ordering, not a problem on its own. Sorry. > > Cheers > Toerless > From nobody Sun May 13 22:24:24 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72081201FA; Sun, 13 May 2018 22:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 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_DBL_ABUSE_MALW=2.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8lqKNFSgQ_t; Sun, 13 May 2018 22:24:00 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 14DDD1200A0; Sun, 13 May 2018 22:23:59 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id n1-v6so4969444pgs.2; Sun, 13 May 2018 22:23: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=L8diKEN28Zg03EopN6vNRhrg3syv+VfCeSdx491qtNA=; b=YtssvYYxWWKibeZWgD2cqq88MsWvNF3Hv/jedxu+ndbn3ACsw1goT61adzd9+hkexj Ip0eeUJszqoSkdAD3rX2kUDLeteHo0dUywRk4OMQ9EH1+tGdq/zi5JnR5mGmteP8HqA2 skd3Ve7spJs/LARjKCEJhznVgf+m0G6gQFSTEyDovfzJ0fCrbwVSgQWKbjBn3jcQ0X9j kKs4ta4eHz6dG78oY3wkGd9YjgiAqKzStldKcfVctqn67bhgaMDI07HJYrIz0Flv/txf vJYjBwe4NP8K/AGnkLgVs7IsWKzhF9ANMtRrbyu/rcssT/kmpol7znJRxrcXhmH487z/ 2sNg== 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=L8diKEN28Zg03EopN6vNRhrg3syv+VfCeSdx491qtNA=; b=hFLBgTSY0jByQMcMJHnP0sjfFclfel1UYzeNS1XrX88aznubgoIk1K5Kc1fYTCZdaq 2DkKmNSUFo2pTutWNYB5knDQKeQd743Z6DJAVecAK1XT0xi5cdvJJq0IaZGv5hoUn3ku TWxE9UTjoc/RO7703oRcspKSw36H54UXlbEUNCIwJAQcJBnFQoiGziCXPqL20hnJfdf2 V9ZIW8MRIj/ckMe0JUg6pgNREN1CJi5gDcFylqTvRYHiZlpibv3MwE9x2LXJi3f1zzms R/2YdqJat9DS/77ykU/4zUHKDx7QlEZTJUFgol55hYPChfX+kyQMfp8OlE1/wGv3b8HC gwOw== X-Gm-Message-State: ALKqPwdPzItWvjHV7zdh1GQfSJrSZThxns+UMwXNN7VByJZ63s1rOWDt 2zzD+8H8kv7At146ZLgD9CPYJw== X-Google-Smtp-Source: AB8JxZpFk6GrqROLBapWx+I7HK7i1TZcHj11FPwQrbvk4H98qi1NV5dSHDaUMIqrzHYj2vskEcZCpw== X-Received: by 2002:a63:7807:: with SMTP id t7-v6mr79323pgc.125.1526275438554; Sun, 13 May 2018 22:23:58 -0700 (PDT) Received: from [192.168.178.27] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id r90-v6sm20948254pfg.122.2018.05.13.22.23.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 May 2018 22:23:57 -0700 (PDT) To: "Joel M. Halpern" , Toerless Eckert Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> <20180512020944.kg5mehv2bfc2ydle@faui48f.informatik.uni-erlangen.de> <10178dd0-e0d2-784e-e2a6-0cb91c3bc952@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <40cb597e-4513-cebf-5aa4-ee6a54a8367d@gmail.com> Date: Mon, 14 May 2018 17:23:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <10178dd0-e0d2-784e-e2a6-0cb91c3bc952@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 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, 14 May 2018 05:24:03 -0000 Joel, Consider this: > The 64 bit Node-ID is derived and composed as follows: > > o Registrar-ID (48 bit): A number unique inside the domain that > identifies the registrar which assigned the Node-ID to the node. > A MAC address of the registrar can be used for this purpose. > > o Node-Number: A number which is unique for a given registrar, to > identify the node. This can be a sequentially assigned number. plus > If a node learns through a future autonomic method or through > configuration that it is part of a zone, it MUST also respond to its > ACP address with that Zone-ID. Basically it's a scheme for all autonomic nodes to get a unique address in a potentially flat address space, with the help of a registrar node, and without the help of a human. My understanding is that the nodes know the format because it's built into the code that each node runs to join the ACP. It's certainly not the only possible scheme. Maybe that should be stated? Regards Brian On 14/05/2018 11:38, Joel M. Halpern wrote: > Trimmed. > Top posting for clarity. Mostly, agreement. > On the MTI Security, I will leave it to the relevant ADs to decide if > they find what is in there sufficient. > > On the identifier vs locator, I think the way you are using the terms is > confusing. But it is not worth continued argumentation.Some text > elaborating along the lines you provide (retained below) would help. > > I have tried reading the section on addressing inside the ACP more > carefully. Thank you for moving the Z bit. > I have retained the earlier discussion on this topic below, in case we > still need it. > Reading the section, I think that the problem is more basic. > > I agree that the document needs to define that we are using a ULA. And > because of the certificate behaviors, there is significant advantage in > defining what ULA prefix is used. > > Given that, I do not see what use there is in all the other format > definition. I suspect I am missing something very basic. Why not leave > this to the deploying operator? It is not like it can be autonomic, > since something has to tell the devices what format to use, and what > numbers within some of the formats to use. I could imagine something > that said "in the absence of configuration, construct device addresses > according to one specific algorithm, so as to simplify bootstrap. > But it would be a simple scheme. > > Yours, > Joel > > On 5/11/18 10:09 PM, Toerless Eckert wrote: >> >> Diff: >> >> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt >> >> Latest version: >> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt >> > .... >> Here are the things that make the ACP address an identifier to me: >> >> - It is assigned once to the device and not meant to change over the lifetime >> of the device. >> - It does not change when i move the node to a different location >> and re-connect the device. >> - It is the unique part of the ACP domain certificate (other than the private key) >> and used to identify the device (privat key is used to authenticate it, >> but the private key may change over time, for example when renewing the certificate). >> >> Would be happy to elaborate this in the doc more explicitly, e.g.: like written >> above. > > (Context: Addressing inside the ACP.) >>> Part of my reaction to this whole section is that it looks much like the >>> mistake we made originally in defining classful IP addresses. You are >>> trying to guess the correct use cases, and defining specific address >>> structures with specific encodings for each one. With only a few encodings >>> available. This seems to be a recipe for being wrong later in ways that >>> hurt. >> >> The only equivalent to classfull addressing i see is for the fixed prefix-length >> handed out to each node, 1 bit (2 addresses) with zone addresses, 8/16 bits >> (256/64k address) for Vlong, but its NOT assignment to network segments >> as in IPv4 A/B/C but to nodes. >> >> We didn't introduce choices lightly. There are compromises to be made when you >> want some lightweight address allocation scheme, not expecting to have complex >> address registry or management system in the backend but simple registrars. >> >> see below for more >> >>>> The difference in interpretation >>>>> is actually provided by the last bit in the upper 64. If these are the >>>>> same schema, then it should not need a bit to differentiate them. They >>>>> should be explained as a single schema. Which would presumably result in >>>>> the Z bit being part of the zone / subnet field. If they are two >>>>> different schemas, then move the differentiation to part of the schema >>>>> identifier (making it 3 bits). >>>> >>>> We did not want to make Z part of the base schemas 6.10.2 "Type" code because >>>> that would also make the Vlong scheme one bit shorter and that would reduce >>>> virtualization space in Vlong by a factor of 2. >>>> >>>> So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out >>>> of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. >>>> >>>> Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO >>>> textually correct to have them in different subsections. >>>> >>>> Carving out bits like Z isn't ideal, but in between the ULA prefix, >>>> the 64 bit local part we must have for external interfaces and >>>> best utilization of bits, we tried to rather optimize address space >>>> utilization and not beauty of encoding. >>>> >>>> Having at the end allows (as written) use of /63 instead of 2 * /64 >>>> routes. I am not sure how important this would be in the future. >>>> >>>> If you feel strongly about more beauty in encoding, >>>> i can move Z to the left and remove the notion of the possible /63 route >>>> optimization possible through the placement of Z. >>> >>> Since the two different uses of the Z bit with type 00b are quite distinct, >>> trying to enable aggregation seems counter-productive. >>> >>> While I hate to push on a point you describe as aesthetics, having the Z >>> bit, occuring after the Zone / subnet-ID field, but defining whether the >>> field is a zone or a subnet, seems awkward for insufficient reason. >>> >>> I would recommend moving the Z bit up so it is after the type, and at the >>> front of each of the two sections reiterate that this subscheme is indicated >>> by the Z bit being { 0 | 1 }. >> >> Done. (see diff). >> >>>> I very much hope there is no "interesting" implementation aspect; >>>> nothing in the current scheme that makes implemenation harder. If you >>>> have an example that you fear, i would like to hear it. >>>> >>>> To me, we are just defining address space allocation schemes. >>> >>> I suppose likely implementations will use mask definitions that will make it >>> work. I pity the code reviewer. >> >> I have read the code and tested in the lab IPv6 embedded RP adressing >> and didn't feel pityfull about the job. But i weigh the overall system >> complexity. Embedded-RP simplified a lot of other parts of the >> multicast system at the cost of introducing an addressing scheme. >> I think similarily, the ACP addressing scheme simplifies the overall system >> complexity, especially registrars. >> >>>>> In section 6.10.5, after stating that it is not even known what the needed >>>>> usage is for more V values >>>> >>>> Which sentence are you referring to when you say "not even known what the >>>> needed usage is" ? I can't find it, but i would like to rectify it >>>> if it actually is still there. >>> >>> The text reads "further values use via definition in future work." In the >>> zone-id scheme, it is one bit. For some reason, it is 8 or 16 bits here. >> >> Thanks, changed sentence to: >> >> V: Virtualization bit: Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme. >> >> The existing text, now directly after the list, explains examples >> when a device would likely need 256 or 64k addresses: >> >> existing text: >> ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge nodes ... >> >>>>> the document goes on to introduce the >>>>> complexity of classful nodes numbers, with the leading bit indicating how >>>>> long the node-number is. Yes, the rest of the text in that bullet tries to >>>>> explain why you need both sizes. It seems like needless complexity that >>>>> begs for mistakes in implementation. >>>> >>>> I was taking the example use cases we brainstormed into account, and >>>> some of them would require a lot more addresses in the node than others, >>>> therefore these two choices. >>> >>> See my comments above. Trying to encode specific use cases into the address >>> format seems a problematic answer to an admittedly difficult question. >>> >>> What would break if you didn't define any of this? >> >> One could save the 2.5 bits (Type, Z) indicating the structure of the >> address inside the address by encoding the designated format of the >> address instead in an extension field of the ACP address information in >> the certificate. We would certainly still want to have the same type >> of addresses, e.g.: 2,256,64k local addresses, option for zones and >> address to assign to ACP connect interfaces (manual addressing scheme) >> IMHO. So, at best we could save the 2.5 bits if we wanted to keep the >> functionality, which i think is all required. >> >> I would be quite afraid of doing such a drastic change this late in >> the process because i think it will take a long time to foresee the >> resulting complexity introduced for registars and any other place >> that now can deduct the semantic from the address and would then have >> to access to what the certificate indicates in a different way (e.g.: >> access to the certificate). Note that the length of the ACP information >> field in the cert is also limited, so this type of extension might end >> up looking even uglier to be short *sigh*. >> >> I was always thinking that this type of more flexible option would >> be a good next-step, but not a safe first step. It would make a lot >> more sense after hearing implementation/deployment experiences, >> especially to correctly support important options we may have >> overlooked in the current schemes. Just redoing what we have differently >> to save 2.5 bits isn't worth it IMHO. >> >>>> Ultimately, we need to break through the chicken and egg problem >>>> of how to build more self-managing networks. These will require >>>> a different number of addresses inside nodes. Anything more intelligent >>>> than address space allocations would become a complex dependency >>>> making implementation/adoption even slower. I don't think that >>>> offering 2, 256, 64k addresses per node is too much flexibility. >>>> It IMHO necessary and sufficient to explore and we'll see what sticks. >>> >>> Variation is needed. That was true of allocations in IP. encoding the >>> variations proved a bad choice. >> >> Let me repeat that we are not doing any network/subnet prefix encoding which is >> what IPv4 A/B/C was. And there are IMHO good examples how encoding in IPv6 >> did save the day from complexity (at least all the stuff done for IPv6 >> multicast, ASM/SSM, zones, Embedded-RP) was highly useful. >> >>>>> In section 6.11.1.11 in describing the prefix lengths, I thought that the >>>>> point of zone addressing was to allow the use of /64 prefixes. But it >>>>> seems here that we will not do so ? >>>> >>>> As mentioned above: This document does not describe the routing setup for /64 >>>> (or /63 with Z-bit) routing aggregation. There are multiple options, >>>> but we could not conclude on a single solution that we felt to be >>>> appropriate for this document. Instead it was only very important >>>> to carve out addressing space to support this. >>> The net effect seems to be to prohibt the very things that you went to a lot >>> of trouble to enable in your addressing design. >> >> Maybe i do not understand your comment correctly, but i do not >> think it is correct. We just have not defined recommended mechanisms >> how to set up routing to use /64 zone routes. That is something IMHO >> better done in a followup document because all the cases where we >> did see a need for znes where really very specific to particular >> deployment styles and would not be applicable to the mayority of ACPs. >> Nevertheless, we felt those cases where important enough to reserve >> bits for them through the zone field. >> >>> ... >>>>> *** Section 10.3.2 paragraph 2 says that devices should change the meaning >>>>> of "admin down" to mean "down for everything except ACP / Anima". I can >>>>> understand why, in an autonomic network, such a state is desirable. However, >>>>> that really should be a different state from "admin down". Operators already >>>>> understand "admin down" as meaning that this interface will not be used for any >>>>> traffic. Changing that is fairly drastic. "admin limited" or "admin ACP-Only" >>>>> would seem much better than changing the meaning of "admin down". The >>>>> justification in the text seems to be a desire to prevent an operator from >>>>> doing what he intends. that seems backwards. (Note that the distinction >>>>> between administrative state vs operational state, aka failed, is already well >>>>> understood.) >>>> >>>> Well, this is in an informative section, so hopefully something we can agree to disagree. >>> >>> If this were truly informative, it would not belong in this document at all. >>> Changing the behavior of widely understood configuration behaviors is NOT a >>> small thing. Changing the permissions models for widely understood >>> configuration operations is also NOT a small thing. >>> >>> My suggestion is that you remove all of this material. If you feel it is >>> important, write an I-D for standards track on evolving the configuration >>> model for robust ANIMA. While I think the change is a mistake, you clearly >>> have the right to cause the discussion. >>> >>> Hiding the topic in an "informational" note in the ACP document seems VERY >>> wrong. >>> >>> Also note that in your discussion below, you talk about the equivalence of >>> admin down and physical down. Most management models I know of treat these >>> as quite distinct. SO that is at best a red herring. >> >> Hmm. I really only CLI derived from Cisco IOS, and there the >> interface level "shutdown" command doubles IMHO both as admin down and >> as phy down, so i would contend that this is a red herring. It actually >> does show up in diagnostic CLI as "admin down", but is also bringing down >> phy state. Therefore it is also used to diagnose phy, .e.g: shutting down >> one side of a supposed direct p2p link to verify the phy change on the >> other side. That practical experience is what the text and direction is >> based on. >> >> Whats an example where admin/phy down are separate in your experience ? >> >> I don't know how you define "truly informative". I simply meant >> informational as compared to standards track wrt. to not impacting >> interoperability, but also as a precursor work to give opportunity >> for gaining more experience before attempting to go standard. >> >> If/when i find time i definitely would like to investigate how this >> could be formalized through a YANG model for ACP so that it can become standard, >> but i definitely agree that especially this part of the YANG model would >> be highly difficult to get to before any experience is gained with >> this. >> >> I therefore would very much hesitate removing this text from the document, it was >> specifically asked for several times in the working group to understand >> how the promised reliability of the ACP against operator/contoller >> operation could be achieved. Having this in a first round (this document) >> as "informational" is IMHO a good and important thing. >> >>> (text retained for context of further discussions.) >>> >>>> >>>> I strongly believe that the most easy way to operationalize the ACP and >>>> achieve its goals is what we have written. >>>> >>>> The historic equivalence of "down" = "admin down" = "physical down" is one of >>>> the the most fundamental problem of remote management in networks. >>>> >>>> We really need to start thinking of separate layers of (remote) management. >>>> Network services on one hand and physical infra on the other. >>>> >>>> The first thing to do this is to separate operations such as "down" >>>> into "admin down" that affects networks services and "phy down" that >>>> affects the physcial infra. >>>> >>>> If you have existing commands like "shutdown" that today do both, >>>> the safe mapping is to let them do the safe thing in the future, e.g: >>>> only "admin down", and introduce new commands for the phy operations, >>>> e.g.: "phy shutdown" or the like. >>>> And then protect those dangerous commands even further against unintentional or >>>> intentional misuse. >>>> >>>> Think of ACP/ANI also as a seamless inband version of a DCN. As an operator >>>> of the actual data network, you also didn't have any access to bring down the DCN >>>> and cut yourself off from the network you manage. YOu could only screw >>>> up that network you're meant to manage. >>>> >>>> And if your network consists of VMs in a DC, a "shutdown" on their >>>> interfaces will also not bring down physical interfaces necessary >>>> to reach the VM. >>>> >>>> In optical networks you often have an inband physcial ethernet management >>>> channel. Making/breaking that one is completely different from making/breaking >>>> your data-plane, aka: data fiber colors. >>>> >>>>> *** The notion in 10.3.6 that the device should refuse to disable >>>>> functionality when an authorized administrator directs such seems flatly wrong. >>>> >>>> The authorization to break your own remote management connectivity >>>> would be a property of the certificate. clearly whoever enrolled >>>> the device with a certificate denying that capaility to the operator >>>> did NOT authorize the administrator to break connectivity. >>> >>> The security model change seems as problematic as the above configuration >>> change. >> >> We have recurringly heard from customers that mistakes in managing remote >> equipment and loosing connectivity is a mayor pain point. Creating >> an operational option that limits/disables operators ability to >> impact phy level connectivity that remote management depends upon and therefore >> reducing this risk and cost factor seems to me like a very logical pah >> forward. Whether or not this should be indicated in the certificate >> or differently is definitely wide open. >> >> I agree that none of these operational interface level changes are >> a piece of cake given how we have in the IETF not tried to define >> different access levels to configuration so far, at least not >> between some phy/infra access level and network-services access level. >> >> As said above in my first reply that you didn't comment on, i think a >> good part of what i am looking for may happen through other means >> already, such as when a router is just a VM running on an OS. At least >> in early versions of this that i'd seen, this implicitly disabled >> the ability to modify phy state from the router VM, and of course >> complaints where raised that phy mods where necessary, but at least this >> evolution could give raise to pause and rethink HOW to permit doing this. >> >> So i would at least like to pledge with you that it is a good thing to >> have this type of discussion in an informational way in this RFC instead >> of doing nothing or trying to go standard YANG directly as a first step. >> It did get into the spec because of the desire of the working group. >> >>>>> Editorial / Nits: >>> . >>>>> In the various formats in section 6.10, the lowest bit of the upper 64 bits >>>>> is mandated to be 0. Presumably, there is some reason for doing this. It >>>>> would be nice to explain it. >>>> >>>> Sorry, not clear what you're referring to. Can you give me an >>>> explicit reference ? >>> >>> I should ahve removed this note. It was a side-effect of the presentation >>> and ordering, not a problem on its own. Sorry. >> >> Cheers >> Toerless >> > > From nobody Mon May 14 02:04:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FDC12D87C; Mon, 14 May 2018 02:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_DBL_ABUSE_MALW=2.5] 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 v_Qx6yL6vyTH; Mon, 14 May 2018 02:04:34 -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 5EBC312D7F0; Mon, 14 May 2018 02:04:34 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9652658C4DD; Mon, 14 May 2018 11:04:25 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8AF84440218; Mon, 14 May 2018 11:04:25 +0200 (CEST) Date: Mon, 14 May 2018 11:04:25 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org Message-ID: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> References: <151995712572.15727.501156104518975926@ietfa.amsl.com> <20180507193019.nebavxqhv2jxkngt@faui48f.informatik.uni-erlangen.de> <20180512020944.kg5mehv2bfc2ydle@faui48f.informatik.uni-erlangen.de> <10178dd0-e0d2-784e-e2a6-0cb91c3bc952@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10178dd0-e0d2-784e-e2a6-0cb91c3bc952@joelhalpern.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 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, 14 May 2018 09:04:39 -0000 a) Will try to do better explanation of identifier nature of addresses in next commit. b) what do we loose if get rid of the choices. I kinda thought i had answered this already, but i really don't know where your concern starts... 1. We use ULA because we want to be able to bring up ACP networks without requiring a registry allocation of a prefix, and ULA is the correct private address space. And deriving ULA Global ID from hash of domain name is nice. Sounds as if you agree with this. 2. We want to be able to allocate addresses to ACP/ANI devices without any additional configuration from multiple independently running registrars. Thats why the global unique ID of the registrar is part of the address in both zone and Vlong format. Thats very fundamental to the ease of deployment of ACP/ANI nodes (i say ANI, because its really ACP+BRSKI required here to get a simple standard solution to create the cert, otherwise youre down to a vendor specific cert provisioning solution extended with ACP info support) i hope this is uncontentuous 3. a) We wanted to be able to support in the future "zone" = area/region-level route aggregation, thats why the zone scheme reserves those 13 bits. b) We also know use cases where nodes need more than 2 addresses, thats why we have have the 8/16 bit Vlong option. c) We can not do everything autonomically (== addresses assigned from registrars), so we also reserve address space for traditional config (manual address space). Are these three sub-spaces zone,manual,vlong contenuous ? As mentioned in prior email if i wanted to avoid those ca. 3 bits of format indication, i would need to indicate the semantic of addresses somehow differently to the nodes, e.g: via some extension to the ACP format, but i would want to be able to signal the same information. So for example: because we have a standardized addressing scheme, a node that allows configuration of "ACP connect" can make sure that the address configured on an ACP cnnect interface can never be a ULA address that would conflict with an automatic ACP address assignment done by a registrar. So i protect my autonomic address space from misconfiguration. Which is IMHO extremely important. So this is the key justification for the manual address space allocation. Distinguishing between zone and Vlong address spaces is necessary because we just can't fit zone, registrar-ID and node-number and 16 bit of per-node bits into a single addressing scheme. E voila, three (IMHO: simpler) simple options. Likely networks will use all three. Cheers Toerless On Sun, May 13, 2018 at 07:38:35PM -0400, Joel M. Halpern wrote: > Trimmed. > Top posting for clarity. Mostly, agreement. > > On the identifier vs locator, I think the way you are using the terms is > confusing. But it is not worth continued argumentation.Some text > elaborating along the lines you provide (retained below) would help. > > I have tried reading the section on addressing inside the ACP more > carefully. Thank you for moving the Z bit. > I have retained the earlier discussion on this topic below, in case we still > need it. > Reading the section, I think that the problem is more basic. > > I agree that the document needs to define that we are using a ULA. And > because of the certificate behaviors, there is significant advantage in > defining what ULA prefix is used. > > Given that, I do not see what use there is in all the other format > definition. I suspect I am missing something very basic. Why not leave > this to the deploying operator? It is not like it can be autonomic, since > something has to tell the devices what format to use, and what numbers > within some of the formats to use. I could imagine something that said "in > the absence of configuration, construct device addresses according to one > specific algorithm, so as to simplify bootstrap. > But it would be a simple scheme. > > > On 5/11/18 10:09 PM, Toerless Eckert wrote: > > > > Diff: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt > > > > Latest version: > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt > > > .... > > Here are the things that make the ACP address an identifier to me: > > > > - It is assigned once to the device and not meant to change over the lifetime > > of the device. > > - It does not change when i move the node to a different location > > and re-connect the device. > > - It is the unique part of the ACP domain certificate (other than the private key) > > and used to identify the device (privat key is used to authenticate it, > > but the private key may change over time, for example when renewing the certificate). > > > > Would be happy to elaborate this in the doc more explicitly, e.g.: like written > > above. > > (Context: Addressing inside the ACP.) > > > Part of my reaction to this whole section is that it looks much like the > > > mistake we made originally in defining classful IP addresses. You are > > > trying to guess the correct use cases, and defining specific address > > > structures with specific encodings for each one. With only a few encodings > > > available. This seems to be a recipe for being wrong later in ways that > > > hurt. > > > > The only equivalent to classfull addressing i see is for the fixed prefix-length > > handed out to each node, 1 bit (2 addresses) with zone addresses, 8/16 bits > > (256/64k address) for Vlong, but its NOT assignment to network segments > > as in IPv4 A/B/C but to nodes. > > > > We didn't introduce choices lightly. There are compromises to be made when you > > want some lightweight address allocation scheme, not expecting to have complex > > address registry or management system in the backend but simple registrars. > > > > see below for more > > > > > > The difference in interpretation > > > > > is actually provided by the last bit in the upper 64. If these are the > > > > > same schema, then it should not need a bit to differentiate them. They > > > > > should be explained as a single schema. Which would presumably result in > > > > > the Z bit being part of the zone / subnet field. If they are two > > > > > different schemas, then move the differentiation to part of the schema > > > > > identifier (making it 3 bits). > > > > > > > > We did not want to make Z part of the base schemas 6.10.2 "Type" code because > > > > that would also make the Vlong scheme one bit shorter and that would reduce > > > > virtualization space in Vlong by a factor of 2. > > > > > > > > So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out > > > > of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. > > > > > > > > Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO > > > > textually correct to have them in different subsections. > > > > > > > > Carving out bits like Z isn't ideal, but in between the ULA prefix, > > > > the 64 bit local part we must have for external interfaces and > > > > best utilization of bits, we tried to rather optimize address space > > > > utilization and not beauty of encoding. > > > > > > > > Having at the end allows (as written) use of /63 instead of 2 * /64 > > > > routes. I am not sure how important this would be in the future. > > > > > > > > If you feel strongly about more beauty in encoding, > > > > i can move Z to the left and remove the notion of the possible /63 route > > > > optimization possible through the placement of Z. > > > > > > Since the two different uses of the Z bit with type 00b are quite distinct, > > > trying to enable aggregation seems counter-productive. > > > > > > While I hate to push on a point you describe as aesthetics, having the Z > > > bit, occuring after the Zone / subnet-ID field, but defining whether the > > > field is a zone or a subnet, seems awkward for insufficient reason. > > > > > > I would recommend moving the Z bit up so it is after the type, and at the > > > front of each of the two sections reiterate that this subscheme is indicated > > > by the Z bit being { 0 | 1 }. > > > > Done. (see diff). > > > > > > I very much hope there is no "interesting" implementation aspect; > > > > nothing in the current scheme that makes implemenation harder. If you > > > > have an example that you fear, i would like to hear it. > > > > > > > > To me, we are just defining address space allocation schemes. > > > > > > I suppose likely implementations will use mask definitions that will make it > > > work. I pity the code reviewer. > > > > I have read the code and tested in the lab IPv6 embedded RP adressing > > and didn't feel pityfull about the job. But i weigh the overall system > > complexity. Embedded-RP simplified a lot of other parts of the > > multicast system at the cost of introducing an addressing scheme. > > I think similarily, the ACP addressing scheme simplifies the overall system > > complexity, especially registrars. > > > > > > > In section 6.10.5, after stating that it is not even known what the needed > > > > > usage is for more V values > > > > > > > > Which sentence are you referring to when you say "not even known what the > > > > needed usage is" ? I can't find it, but i would like to rectify it > > > > if it actually is still there. > > > > > > The text reads "further values use via definition in future work." In the > > > zone-id scheme, it is one bit. For some reason, it is 8 or 16 bits here. > > > > Thanks, changed sentence to: > > > > V: Virtualization bit: Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme. > > > > The existing text, now directly after the list, explains examples > > when a device would likely need 256 or 64k addresses: > > > > existing text: > > ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge nodes ... > > > > > > > the document goes on to introduce the > > > > > complexity of classful nodes numbers, with the leading bit indicating how > > > > > long the node-number is. Yes, the rest of the text in that bullet tries to > > > > > explain why you need both sizes. It seems like needless complexity that > > > > > begs for mistakes in implementation. > > > > > > > > I was taking the example use cases we brainstormed into account, and > > > > some of them would require a lot more addresses in the node than others, > > > > therefore these two choices. > > > > > > See my comments above. Trying to encode specific use cases into the address > > > format seems a problematic answer to an admittedly difficult question. > > > > > > What would break if you didn't define any of this? > > > > One could save the 2.5 bits (Type, Z) indicating the structure of the > > address inside the address by encoding the designated format of the > > address instead in an extension field of the ACP address information in > > the certificate. We would certainly still want to have the same type > > of addresses, e.g.: 2,256,64k local addresses, option for zones and > > address to assign to ACP connect interfaces (manual addressing scheme) > > IMHO. So, at best we could save the 2.5 bits if we wanted to keep the > > functionality, which i think is all required. > > > > I would be quite afraid of doing such a drastic change this late in > > the process because i think it will take a long time to foresee the > > resulting complexity introduced for registars and any other place > > that now can deduct the semantic from the address and would then have > > to access to what the certificate indicates in a different way (e.g.: > > access to the certificate). Note that the length of the ACP information > > field in the cert is also limited, so this type of extension might end > > up looking even uglier to be short *sigh*. > > > > I was always thinking that this type of more flexible option would > > be a good next-step, but not a safe first step. It would make a lot > > more sense after hearing implementation/deployment experiences, > > especially to correctly support important options we may have > > overlooked in the current schemes. Just redoing what we have differently > > to save 2.5 bits isn't worth it IMHO. > > > > > > Ultimately, we need to break through the chicken and egg problem > > > > of how to build more self-managing networks. These will require > > > > a different number of addresses inside nodes. Anything more intelligent > > > > than address space allocations would become a complex dependency > > > > making implementation/adoption even slower. I don't think that > > > > offering 2, 256, 64k addresses per node is too much flexibility. > > > > It IMHO necessary and sufficient to explore and we'll see what sticks. > > > > > > Variation is needed. That was true of allocations in IP. encoding the > > > variations proved a bad choice. > > > > Let me repeat that we are not doing any network/subnet prefix encoding which is > > what IPv4 A/B/C was. And there are IMHO good examples how encoding in IPv6 > > did save the day from complexity (at least all the stuff done for IPv6 > > multicast, ASM/SSM, zones, Embedded-RP) was highly useful. > > > > > > > In section 6.11.1.11 in describing the prefix lengths, I thought that the > > > > > point of zone addressing was to allow the use of /64 prefixes. But it > > > > > seems here that we will not do so ? > > > > > > > > As mentioned above: This document does not describe the routing setup for /64 > > > > (or /63 with Z-bit) routing aggregation. There are multiple options, > > > > but we could not conclude on a single solution that we felt to be > > > > appropriate for this document. Instead it was only very important > > > > to carve out addressing space to support this. > > > The net effect seems to be to prohibt the very things that you went to a lot > > > of trouble to enable in your addressing design. > > > > Maybe i do not understand your comment correctly, but i do not > > think it is correct. We just have not defined recommended mechanisms > > how to set up routing to use /64 zone routes. That is something IMHO > > better done in a followup document because all the cases where we > > did see a need for znes where really very specific to particular > > deployment styles and would not be applicable to the mayority of ACPs. > > Nevertheless, we felt those cases where important enough to reserve > > bits for them through the zone field. > > > > > ... > > > > > *** Section 10.3.2 paragraph 2 says that devices should change the meaning > > > > > of "admin down" to mean "down for everything except ACP / Anima". I can > > > > > understand why, in an autonomic network, such a state is desirable. However, > > > > > that really should be a different state from "admin down". Operators already > > > > > understand "admin down" as meaning that this interface will not be used for any > > > > > traffic. Changing that is fairly drastic. "admin limited" or "admin ACP-Only" > > > > > would seem much better than changing the meaning of "admin down". The > > > > > justification in the text seems to be a desire to prevent an operator from > > > > > doing what he intends. that seems backwards. (Note that the distinction > > > > > between administrative state vs operational state, aka failed, is already well > > > > > understood.) > > > > > > > > Well, this is in an informative section, so hopefully something we can agree to disagree. > > > > > > If this were truly informative, it would not belong in this document at all. > > > Changing the behavior of widely understood configuration behaviors is NOT a > > > small thing. Changing the permissions models for widely understood > > > configuration operations is also NOT a small thing. > > > > > > My suggestion is that you remove all of this material. If you feel it is > > > important, write an I-D for standards track on evolving the configuration > > > model for robust ANIMA. While I think the change is a mistake, you clearly > > > have the right to cause the discussion. > > > > > > Hiding the topic in an "informational" note in the ACP document seems VERY > > > wrong. > > > > > > Also note that in your discussion below, you talk about the equivalence of > > > admin down and physical down. Most management models I know of treat these > > > as quite distinct. SO that is at best a red herring. > > > > Hmm. I really only CLI derived from Cisco IOS, and there the > > interface level "shutdown" command doubles IMHO both as admin down and > > as phy down, so i would contend that this is a red herring. It actually > > does show up in diagnostic CLI as "admin down", but is also bringing down > > phy state. Therefore it is also used to diagnose phy, .e.g: shutting down > > one side of a supposed direct p2p link to verify the phy change on the > > other side. That practical experience is what the text and direction is > > based on. > > > > Whats an example where admin/phy down are separate in your experience ? > > > > I don't know how you define "truly informative". I simply meant > > informational as compared to standards track wrt. to not impacting > > interoperability, but also as a precursor work to give opportunity > > for gaining more experience before attempting to go standard. > > > > If/when i find time i definitely would like to investigate how this > > could be formalized through a YANG model for ACP so that it can become standard, > > but i definitely agree that especially this part of the YANG model would > > be highly difficult to get to before any experience is gained with > > this. > > > > I therefore would very much hesitate removing this text from the document, it was > > specifically asked for several times in the working group to understand > > how the promised reliability of the ACP against operator/contoller > > operation could be achieved. Having this in a first round (this document) > > as "informational" is IMHO a good and important thing. > > > > > (text retained for context of further discussions.) > > > > > > > > > > > I strongly believe that the most easy way to operationalize the ACP and > > > > achieve its goals is what we have written. > > > > > > > > The historic equivalence of "down" = "admin down" = "physical down" is one of > > > > the the most fundamental problem of remote management in networks. > > > > > > > > We really need to start thinking of separate layers of (remote) management. > > > > Network services on one hand and physical infra on the other. > > > > > > > > The first thing to do this is to separate operations such as "down" > > > > into "admin down" that affects networks services and "phy down" that > > > > affects the physcial infra. > > > > > > > > If you have existing commands like "shutdown" that today do both, > > > > the safe mapping is to let them do the safe thing in the future, e.g: > > > > only "admin down", and introduce new commands for the phy operations, > > > > e.g.: "phy shutdown" or the like. > > > > And then protect those dangerous commands even further against unintentional or > > > > intentional misuse. > > > > > > > > Think of ACP/ANI also as a seamless inband version of a DCN. As an operator > > > > of the actual data network, you also didn't have any access to bring down the DCN > > > > and cut yourself off from the network you manage. YOu could only screw > > > > up that network you're meant to manage. > > > > > > > > And if your network consists of VMs in a DC, a "shutdown" on their > > > > interfaces will also not bring down physical interfaces necessary > > > > to reach the VM. > > > > > > > > In optical networks you often have an inband physcial ethernet management > > > > channel. Making/breaking that one is completely different from making/breaking > > > > your data-plane, aka: data fiber colors. > > > > > > > > > *** The notion in 10.3.6 that the device should refuse to disable > > > > > functionality when an authorized administrator directs such seems flatly wrong. > > > > > > > > The authorization to break your own remote management connectivity > > > > would be a property of the certificate. clearly whoever enrolled > > > > the device with a certificate denying that capaility to the operator > > > > did NOT authorize the administrator to break connectivity. > > > > > > The security model change seems as problematic as the above configuration > > > change. > > > > We have recurringly heard from customers that mistakes in managing remote > > equipment and loosing connectivity is a mayor pain point. Creating > > an operational option that limits/disables operators ability to > > impact phy level connectivity that remote management depends upon and therefore > > reducing this risk and cost factor seems to me like a very logical pah > > forward. Whether or not this should be indicated in the certificate > > or differently is definitely wide open. > > > > I agree that none of these operational interface level changes are > > a piece of cake given how we have in the IETF not tried to define > > different access levels to configuration so far, at least not > > between some phy/infra access level and network-services access level. > > > > As said above in my first reply that you didn't comment on, i think a > > good part of what i am looking for may happen through other means > > already, such as when a router is just a VM running on an OS. At least > > in early versions of this that i'd seen, this implicitly disabled > > the ability to modify phy state from the router VM, and of course > > complaints where raised that phy mods where necessary, but at least this > > evolution could give raise to pause and rethink HOW to permit doing this. > > > > So i would at least like to pledge with you that it is a good thing to > > have this type of discussion in an informational way in this RFC instead > > of doing nothing or trying to go standard YANG directly as a first step. > > It did get into the spec because of the desire of the working group. > > > > > > > Editorial / Nits: > > > . > > > > > In the various formats in section 6.10, the lowest bit of the upper 64 bits > > > > > is mandated to be 0. Presumably, there is some reason for doing this. It > > > > > would be nice to explain it. > > > > > > > > Sorry, not clear what you're referring to. Can you give me an > > > > explicit reference ? > > > > > > I should ahve removed this note. It was a side-effect of the presentation > > > and ordering, not a problem on its own. Sorry. > > > > Cheers > > Toerless > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon May 14 05:50:17 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B49712DB6C; Mon, 14 May 2018 05:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_DBL_ABUSE_MALW=2.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAdRfTM19ivT; Mon, 14 May 2018 05:50:01 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23695124239; Mon, 14 May 2018 05:50:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F1CCD3E5F01; Mon, 14 May 2018 05:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1526302201; bh=nBb9TRSXARXKW0J0tMogFRo74c4XR6fBb3Q9wtOywHQ=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=VNeSa0rMk+L8QFuiUv4M0dmYCHU1bc1cOjfgp56AEnwYp4d8Rz6v58wUjaf2MOLOZ Hcxa467Z4LBVaDm26MLQ/+tfB5/za4SlwQGgE8MFawubjokERvfWeXRt3BPjK3gCRb /7ZZJgg0imVxPzkzb5mqPMOJb7nPhaYMmXwywRSk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.100.20] (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 055342402CE; Mon, 14 May 2018 05:49:59 -0700 (PDT) SavedFromEmail: jmh.direct@joelhalpern.com Date: Mon, 14 May 2018 08:49:56 -0400 In-Reply-To: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> Importance: normal From: "jmh.direct" To: Toerless Eckert , "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_10172749362835710" Message-Id: <20180514125001.23695124239@ietfa.amsl.com> Archived-At: Subject: Re: [Anima] Rtgdir telechat review of draft-ietf-anima-autonomic-control-plane-13 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, 14 May 2018 12:50:05 -0000 ----_com.samsung.android.email_10172749362835710 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgSSB1bmRlcnN0YW5kIHdoYXQgeW91IGRlc2NyaWJlLsKgIEFzIGZhciBhcyBJ IGNhbiB0ZWxsLCB0aGUgQUNQIERPRVMgTk9UIEFORCBTSE9ZTEQgTk9UIE1BTkRBVEUgVGhlIGFk ZHJlc3MgYXNzaWdubWVudCBtZWNoYW5pc20uwqAgQnV0IGl0IGlzIHRoZSBhZGRyZXNzIGFzc2ln bm1lbnQgbWVjaGFuaXNtIHRoYXQgZHJpdmVzIHRoZSBhZGRyZXNzIGFsbG9jYXRpb24uCkFzIHN1 Y2gsIGl0IHNlZW1zIGxpa2UgdGhlIEFDUCBpdHNlbGYgZG9lcyBub3QgY2FyZSBhYm91dCB0aGlz LsKgIFRoYXQgaXMsd2h5IHRoZSByb3V0aW5nIHNjaGVtZSBzZWVtZWQgY29uZnVzaW5nIGFmdGVy IHRoZSBhZGRyZXNzIGFsbG9jYXRpb24gc2NoZW1lLgpJIHdvdWxkIGV4cGVjdCB0byBmaW5kIHRo ZSBhZGRyZXNzIHN0cnVjdHVyZSBmb3IgYXV0b25vbWljIGFkZHJlc3NlZCBpbiB0aGUgc2FtZSBk b2N1bWVudCBhcyB0aGUgbWVjaGFuaXNtcyBmb3IgYXV0b25vbWljIGFkZHJlc3MgYXNzaWdubWVu dC4KWW91cnMsSm9lbAoKClNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQm VCA0RyBMVEUgc21hcnRwaG9uZQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJv bTogVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPiBEYXRlOiA1LzE0LzE4ICAwNTowNCAg KEdNVC0wNTowMCkgVG86ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiBD YzogcnRnLWRpckBpZXRmLm9yZywgZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1w bGFuZS5hbGxAaWV0Zi5vcmcsIGlldGZAaWV0Zi5vcmcsIGFuaW1hQGlldGYub3JnIFN1YmplY3Q6 IFJlOiBbQW5pbWFdIFJ0Z2RpciB0ZWxlY2hhdCByZXZpZXcgb2YKwqAgZHJhZnQtaWV0Zi1hbmlt YS1hdXRvbm9taWMtY29udHJvbC1wbGFuZS0xMyAKYSkgV2lsbCB0cnkgdG8gZG8gYmV0dGVyIGV4 cGxhbmF0aW9uIG9mIGlkZW50aWZpZXIgbmF0dXJlIG9mIGFkZHJlc3NlcyBpbgrCoMKgIG5leHQg Y29tbWl0LgoKYikgd2hhdCBkbyB3ZSBsb29zZSBpZiBnZXQgcmlkIG9mIHRoZSBjaG9pY2VzLiBJ IGtpbmRhIHRob3VnaHQgaSBoYWQgYW5zd2VyZWQKwqDCoCB0aGlzIGFscmVhZHksIGJ1dCBpIHJl YWxseSBkb24ndCBrbm93IHdoZXJlIHlvdXIgY29uY2VybiBzdGFydHMuLi4KCsKgwqAgMS4gV2Ug dXNlIFVMQSBiZWNhdXNlIHdlIHdhbnQgdG8gYmUgYWJsZSB0byBicmluZyB1cCBBQ1AgbmV0d29y a3Mgd2l0aG91dArCoMKgwqDCoMKgIHJlcXVpcmluZyBhIHJlZ2lzdHJ5IGFsbG9jYXRpb24gb2Yg YSBwcmVmaXgsIGFuZCBVTEEgaXMgdGhlIGNvcnJlY3QKwqDCoMKgwqDCoCBwcml2YXRlIGFkZHJl c3Mgc3BhY2UuIEFuZCBkZXJpdmluZyBVTEEgR2xvYmFsIElEIGZyb20gaGFzaCBvZiBkb21haW4K wqDCoMKgwqDCoCBuYW1lIGlzIG5pY2UuCgrCoMKgwqDCoMKgIFNvdW5kcyBhcyBpZiB5b3UgYWdy ZWUgd2l0aCB0aGlzLgrCoMKgwqAgCsKgwqAgMi4gV2Ugd2FudCB0byBiZSBhYmxlIHRvIGFsbG9j YXRlIGFkZHJlc3NlcyB0byBBQ1AvQU5JIGRldmljZXMKwqDCoMKgwqDCoCB3aXRob3V0IGFueSBh ZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24gZnJvbSBtdWx0aXBsZSBpbmRlcGVuZGVudGx5CsKgwqDC oMKgwqAgcnVubmluZyByZWdpc3RyYXJzLiBUaGF0cyB3aHkgdGhlIGdsb2JhbCB1bmlxdWUgSUQg b2YgdGhlIHJlZ2lzdHJhcgrCoMKgwqDCoMKgIGlzIHBhcnQgb2YgdGhlIGFkZHJlc3MgaW4gYm90 aCB6b25lIGFuZCBWbG9uZyBmb3JtYXQuCgrCoMKgwqDCoMKgIFRoYXRzIHZlcnkgZnVuZGFtZW50 YWwgdG8gdGhlIGVhc2Ugb2YgZGVwbG95bWVudCBvZiBBQ1AvQU5JIG5vZGVzCsKgwqDCoMKgwqAg KGkgc2F5IEFOSSwgYmVjYXVzZSBpdHMgcmVhbGx5IEFDUCtCUlNLSSByZXF1aXJlZCBoZXJlIHRv IGdldCBhIHNpbXBsZSBzdGFuZGFyZArCoMKgwqDCoMKgwqAgc29sdXRpb24gdG8gY3JlYXRlIHRo ZSBjZXJ0LCBvdGhlcndpc2UgeW91cmUgZG93biB0byBhIHZlbmRvciBzcGVjaWZpYwrCoMKgwqDC oMKgwqAgY2VydCBwcm92aXNpb25pbmcgc29sdXRpb24gZXh0ZW5kZWQgd2l0aCBBQ1AgaW5mbyBz dXBwb3J0KQoKwqDCoMKgwqDCoCBpIGhvcGUgdGhpcyBpcyB1bmNvbnRlbnR1b3VzCsKgwqAgCsKg wqAgMy4gYSkgV2Ugd2FudGVkIHRvIGJlIGFibGUgdG8gc3VwcG9ydCBpbiB0aGUgZnV0dXJlICJ6 b25lIiA9IGFyZWEvcmVnaW9uLWxldmVsCsKgwqDCoMKgwqAgcm91dGUgYWdncmVnYXRpb24sIHRo YXRzIHdoeSB0aGUgem9uZSBzY2hlbWUgcmVzZXJ2ZXMgdGhvc2UgMTMgYml0cy4KCsKgwqDCoMKg wqAgYikgV2UgYWxzbyBrbm93IHVzZSBjYXNlcyB3aGVyZSBub2RlcyBuZWVkIG1vcmUgdGhhbiAy IGFkZHJlc3NlcywKwqDCoMKgwqDCoCB0aGF0cyB3aHkgd2UgaGF2ZSBoYXZlIHRoZSA4LzE2IGJp dCBWbG9uZyBvcHRpb24uIAoKwqDCoMKgwqDCoCBjKSBXZSBjYW4gbm90IGRvIGV2ZXJ5dGhpbmcg YXV0b25vbWljYWxseSAoPT0gYWRkcmVzc2VzIGFzc2lnbmVkIGZyb20gcmVnaXN0cmFycyksCsKg wqDCoMKgwqAgc28gd2UgYWxzbyByZXNlcnZlIGFkZHJlc3Mgc3BhY2UgZm9yIHRyYWRpdGlvbmFs IGNvbmZpZyAobWFudWFsIGFkZHJlc3Mgc3BhY2UpLgoKwqDCoMKgwqDCoCBBcmUgdGhlc2UgdGhy ZWUgc3ViLXNwYWNlcyB6b25lLG1hbnVhbCx2bG9uZyBjb250ZW51b3VzID8KwqDCoCAKwqDCoCBB cyBtZW50aW9uZWQgaW4gcHJpb3IgZW1haWwgaWYgaSB3YW50ZWQgdG8gYXZvaWQgdGhvc2UgY2Eu IDMgYml0cyBvZgrCoMKgIGZvcm1hdCBpbmRpY2F0aW9uLCBpIHdvdWxkIG5lZWQgdG8gaW5kaWNh dGUgdGhlIHNlbWFudGljIG9mIGFkZHJlc3NlcwrCoMKgIHNvbWVob3cgZGlmZmVyZW50bHkgdG8g dGhlIG5vZGVzLCBlLmc6IHZpYSBzb21lIGV4dGVuc2lvbiB0byB0aGUgQUNQIGZvcm1hdCwKwqDC oCBidXQgaSB3b3VsZCB3YW50IHRvIGJlIGFibGUgdG8gc2lnbmFsIHRoZSBzYW1lIGluZm9ybWF0 aW9uLgoKwqDCoCBTbyBmb3IgZXhhbXBsZTogYmVjYXVzZSB3ZSBoYXZlIGEgc3RhbmRhcmRpemVk IGFkZHJlc3Npbmcgc2NoZW1lLArCoMKgIGEgbm9kZSB0aGF0IGFsbG93cyBjb25maWd1cmF0aW9u IG9mICJBQ1AgY29ubmVjdCIgY2FuIG1ha2Ugc3VyZQrCoMKgIHRoYXQgdGhlIGFkZHJlc3MgY29u ZmlndXJlZCBvbiBhbiBBQ1AgY25uZWN0IGludGVyZmFjZSBjYW4gbmV2ZXIgYmUgYSBVTEEKwqDC oCBhZGRyZXNzIHRoYXQgd291bGQgY29uZmxpY3Qgd2l0aCBhbiBhdXRvbWF0aWMgQUNQIGFkZHJl c3MgYXNzaWdubWVudCBkb25lCsKgwqAgYnkgYSByZWdpc3RyYXIuIFNvIGkgcHJvdGVjdCBteSBh dXRvbm9taWMgYWRkcmVzcyBzcGFjZSBmcm9tIG1pc2NvbmZpZ3VyYXRpb24uCsKgwqAgV2hpY2gg aXMgSU1ITyBleHRyZW1lbHkgaW1wb3J0YW50LiBTbyB0aGlzIGlzIHRoZSBrZXkganVzdGlmaWNh dGlvbiBmb3IKwqDCoCB0aGUgbWFudWFsIGFkZHJlc3Mgc3BhY2UgYWxsb2NhdGlvbi4gCgrCoMKg IERpc3Rpbmd1aXNoaW5nIGJldHdlZW4gem9uZSBhbmQgVmxvbmcgYWRkcmVzcyBzcGFjZXMgaXMg bmVjZXNzYXJ5IGJlY2F1c2UKwqDCoCB3ZSBqdXN0IGNhbid0IGZpdCB6b25lLCByZWdpc3RyYXIt SUQgYW5kIG5vZGUtbnVtYmVyIGFuZCAxNiBiaXQgb2YgcGVyLW5vZGUgYml0cwrCoMKgIGludG8g YSBzaW5nbGUgYWRkcmVzc2luZyBzY2hlbWUuCgrCoMKgIEUgdm9pbGEsIHRocmVlIChJTUhPOiBz aW1wbGVyKSBzaW1wbGUgb3B0aW9ucy4gTGlrZWx5IG5ldHdvcmtzIHdpbGwgdXNlIGFsbCB0aHJl ZS4KIApDaGVlcnMKwqDCoMKgIFRvZXJsZXNzCgpPbiBTdW4sIE1heSAxMywgMjAxOCBhdCAwNzoz ODozNVBNIC0wNDAwLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6Cj4gVHJpbW1lZC4KPiBUb3AgcG9z dGluZyBmb3IgY2xhcml0eS7CoCBNb3N0bHksIGFncmVlbWVudC4KPiAKPiBPbiB0aGUgaWRlbnRp ZmllciB2cyBsb2NhdG9yLCBJIHRoaW5rIHRoZSB3YXkgeW91IGFyZSB1c2luZyB0aGUgdGVybXMg aXMKPiBjb25mdXNpbmcuwqAgQnV0IGl0IGlzIG5vdCB3b3J0aCBjb250aW51ZWQgYXJndW1lbnRh dGlvbi5Tb21lIHRleHQKPiBlbGFib3JhdGluZyBhbG9uZyB0aGUgbGluZXMgeW91IHByb3ZpZGUg KHJldGFpbmVkIGJlbG93KSB3b3VsZCBoZWxwLgo+Cj4gSSBoYXZlIHRyaWVkIHJlYWRpbmcgdGhl IHNlY3Rpb24gb24gYWRkcmVzc2luZyBpbnNpZGUgdGhlIEFDUCBtb3JlCj4gY2FyZWZ1bGx5LsKg IFRoYW5rIHlvdSBmb3IgbW92aW5nIHRoZSBaIGJpdC4KPiBJIGhhdmUgcmV0YWluZWQgdGhlIGVh cmxpZXIgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGJlbG93LCBpbiBjYXNlIHdlIHN0aWxsCj4g bmVlZCBpdC4KPiBSZWFkaW5nIHRoZSBzZWN0aW9uLCBJIHRoaW5rIHRoYXQgdGhlIHByb2JsZW0g aXMgbW9yZSBiYXNpYy4KPiAKPiBJIGFncmVlIHRoYXQgdGhlIGRvY3VtZW50IG5lZWRzIHRvIGRl ZmluZSB0aGF0IHdlIGFyZSB1c2luZyBhIFVMQS7CoCBBbmQKPiBiZWNhdXNlIG9mIHRoZSBjZXJ0 aWZpY2F0ZSBiZWhhdmlvcnMsIHRoZXJlIGlzIHNpZ25pZmljYW50IGFkdmFudGFnZSBpbgo+IGRl ZmluaW5nIHdoYXQgVUxBIHByZWZpeCBpcyB1c2VkLgo+IAo+IEdpdmVuIHRoYXQsIEkgZG8gbm90 IHNlZSB3aGF0IHVzZSB0aGVyZSBpcyBpbiBhbGwgdGhlIG90aGVyIGZvcm1hdAo+IGRlZmluaXRp b24uwqAgSSBzdXNwZWN0IEkgYW0gbWlzc2luZyBzb21ldGhpbmcgdmVyeSBiYXNpYy7CoCBXaHkg bm90IGxlYXZlCj4gdGhpcyB0byB0aGUgZGVwbG95aW5nIG9wZXJhdG9yP8KgIEl0IGlzIG5vdCBs aWtlIGl0IGNhbiBiZSBhdXRvbm9taWMsIHNpbmNlCj4gc29tZXRoaW5nIGhhcyB0byB0ZWxsIHRo ZSBkZXZpY2VzIHdoYXQgZm9ybWF0IHRvIHVzZSwgYW5kIHdoYXQgbnVtYmVycwo+IHdpdGhpbiBz b21lIG9mIHRoZSBmb3JtYXRzIHRvIHVzZS7CoCBJIGNvdWxkIGltYWdpbmUgc29tZXRoaW5nIHRo YXQgc2FpZCAiaW4KPiB0aGUgYWJzZW5jZSBvZiBjb25maWd1cmF0aW9uLCBjb25zdHJ1Y3QgZGV2 aWNlIGFkZHJlc3NlcyBhY2NvcmRpbmcgdG8gb25lCj4gc3BlY2lmaWMgYWxnb3JpdGhtLCBzbyBh cyB0byBzaW1wbGlmeSBib290c3RyYXAuCj4gQnV0IGl0IHdvdWxkIGJlIGEgc2ltcGxlIHNjaGVt ZS4KPgo+IAo+IE9uIDUvMTEvMTggMTA6MDkgUE0sIFRvZXJsZXNzIEVja2VydCB3cm90ZToKPiA+ IAo+ID4gRGlmZjoKPiA+IAo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYv cmZjZGlmZi5weWh0P3VybDE9aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL2FuaW1h LXdnL2F1dG9ub21pYy1jb250cm9sLXBsYW5lLzJhZThmNDczOTlhZTBkMDgxMWNiNDUyMDkxODZk MDFmOWUwZDMwNzcvZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZS9kcmFm dC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTE0LnR4dCZ1cmwyPWh0dHBzOi8v cmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9hbmltYS13Zy9hdXRvbm9taWMtY29udHJvbC1wbGFu ZS81NGM5YzE2ZjM0NDRiMWRiMTNjN2NiMDU3NDRlNTQzZGZjZGZiNjNiL2RyYWZ0LWlldGYtYW5p bWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUvZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29u dHJvbC1wbGFuZS0xNC50eHQKPiA+IAo+ID4gTGF0ZXN0IHZlcnNpb246Cj4gPiBodHRwczovL3Jh dy5naXRodWJ1c2VyY29udGVudC5jb20vYW5pbWEtd2cvYXV0b25vbWljLWNvbnRyb2wtcGxhbmUv NTRjOWMxNmYzNDQ0YjFkYjEzYzdjYjA1NzQ0ZTU0M2RmY2RmYjYzYi9kcmFmdC1pZXRmLWFuaW1h LWF1dG9ub21pYy1jb250cm9sLXBsYW5lL2RyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRy b2wtcGxhbmUtMTQudHh0Cj4gPiAKPiAuLi4uCj4gPiBIZXJlIGFyZSB0aGUgdGhpbmdzIHRoYXQg bWFrZSB0aGUgQUNQIGFkZHJlc3MgYW4gaWRlbnRpZmllciB0byBtZToKPiA+IAo+ID4gLSBJdCBp cyBhc3NpZ25lZCBvbmNlIHRvIHRoZSBkZXZpY2UgYW5kIG5vdCBtZWFudCB0byBjaGFuZ2Ugb3Zl ciB0aGUgbGlmZXRpbWUKPiA+wqDCoMKgIG9mIHRoZSBkZXZpY2UuCj4gPiAtIEl0IGRvZXMgbm90 IGNoYW5nZSB3aGVuIGkgbW92ZSB0aGUgbm9kZSB0byBhIGRpZmZlcmVudCBsb2NhdGlvbgo+ID7C oMKgwqAgYW5kIHJlLWNvbm5lY3QgdGhlIGRldmljZS4KPiA+IC0gSXQgaXMgdGhlIHVuaXF1ZSBw YXJ0IG9mIHRoZSBBQ1AgZG9tYWluIGNlcnRpZmljYXRlIChvdGhlciB0aGFuIHRoZSBwcml2YXRl IGtleSkKPiA+wqDCoMKgIGFuZCB1c2VkIHRvIGlkZW50aWZ5IHRoZSBkZXZpY2UgKHByaXZhdCBr ZXkgaXMgdXNlZCB0byBhdXRoZW50aWNhdGUgaXQsCj4gPsKgwqDCoCBidXQgdGhlIHByaXZhdGUg a2V5IG1heSBjaGFuZ2Ugb3ZlciB0aW1lLCBmb3IgZXhhbXBsZSB3aGVuIHJlbmV3aW5nIHRoZSBj ZXJ0aWZpY2F0ZSkuCj4gPiAKPiA+IFdvdWxkIGJlIGhhcHB5IHRvIGVsYWJvcmF0ZSB0aGlzIGlu IHRoZSBkb2MgbW9yZSBleHBsaWNpdGx5LCBlLmcuOiBsaWtlIHdyaXR0ZW4KPiA+IGFib3ZlLgo+ IAo+IChDb250ZXh0OiBBZGRyZXNzaW5nIGluc2lkZSB0aGUgQUNQLikKPiA+ID4gUGFydCBvZiBt eSByZWFjdGlvbiB0byB0aGlzIHdob2xlIHNlY3Rpb24gaXMgdGhhdCBpdCBsb29rcyBtdWNoIGxp a2UgdGhlCj4gPiA+IG1pc3Rha2Ugd2UgbWFkZSBvcmlnaW5hbGx5IGluIGRlZmluaW5nIGNsYXNz ZnVsIElQIGFkZHJlc3Nlcy7CoCBZb3UgYXJlCj4gPiA+IHRyeWluZyB0byBndWVzcyB0aGUgY29y cmVjdCB1c2UgY2FzZXMsIGFuZCBkZWZpbmluZyBzcGVjaWZpYyBhZGRyZXNzCj4gPiA+IHN0cnVj dHVyZXMgd2l0aCBzcGVjaWZpYyBlbmNvZGluZ3MgZm9yIGVhY2ggb25lLsKgIFdpdGggb25seSBh IGZldyBlbmNvZGluZ3MKPiA+ID4gYXZhaWxhYmxlLsKgIFRoaXMgc2VlbXMgdG8gYmUgYSByZWNp cGUgZm9yIGJlaW5nIHdyb25nIGxhdGVyIGluIHdheXMgdGhhdAo+ID4gPiBodXJ0Lgo+ID4gCj4g PiBUaGUgb25seSBlcXVpdmFsZW50IHRvIGNsYXNzZnVsbCBhZGRyZXNzaW5nIGkgc2VlIGlzIGZv ciB0aGUgZml4ZWQgcHJlZml4LWxlbmd0aAo+ID4gaGFuZGVkIG91dCB0byBlYWNoIG5vZGUsIDEg Yml0ICgyIGFkZHJlc3Nlcykgd2l0aCB6b25lIGFkZHJlc3NlcywgOC8xNiBiaXRzCj4gPiAoMjU2 LzY0ayBhZGRyZXNzKSBmb3IgVmxvbmcsIGJ1dCBpdHMgTk9UIGFzc2lnbm1lbnQgdG8gbmV0d29y ayBzZWdtZW50cwo+ID4gYXMgaW4gSVB2NCBBL0IvQyBidXQgdG8gbm9kZXMuCj4gPiAKPiA+IFdl IGRpZG4ndCBpbnRyb2R1Y2UgY2hvaWNlcyBsaWdodGx5LiBUaGVyZSBhcmUgY29tcHJvbWlzZXMg dG8gYmUgbWFkZSB3aGVuIHlvdQo+ID4gd2FudCBzb21lIGxpZ2h0d2VpZ2h0IGFkZHJlc3MgYWxs b2NhdGlvbiBzY2hlbWUsIG5vdCBleHBlY3RpbmcgdG8gaGF2ZSBjb21wbGV4Cj4gPiBhZGRyZXNz IHJlZ2lzdHJ5IG9yIG1hbmFnZW1lbnQgc3lzdGVtIGluIHRoZSBiYWNrZW5kIGJ1dCBzaW1wbGUg cmVnaXN0cmFycy4KPiA+IAo+ID4gc2VlIGJlbG93IGZvciBtb3JlCj4gPiAKPiA+ID4gPsKgwqDC oMKgwqDCoMKgwqAgVGhlIGRpZmZlcmVuY2UgaW4gaW50ZXJwcmV0YXRpb24KPiA+ID4gPiA+wqDC oMKgwqDCoMKgIGlzIGFjdHVhbGx5IHByb3ZpZGVkIGJ5IHRoZSBsYXN0IGJpdCBpbiB0aGUgdXBw ZXIgNjQuwqAgSWYgdGhlc2UgYXJlIHRoZQo+ID4gPiA+ID7CoMKgwqDCoMKgwqAgc2FtZSBzY2hl bWEsIHRoZW4gaXQgc2hvdWxkIG5vdCBuZWVkIGEgYml0IHRvIGRpZmZlcmVudGlhdGUgdGhlbS7C oCBUaGV5Cj4gPiA+ID4gPsKgwqDCoMKgwqDCoCBzaG91bGQgYmUgZXhwbGFpbmVkIGFzIGEgc2lu Z2xlIHNjaGVtYS7CoCBXaGljaCB3b3VsZCBwcmVzdW1hYmx5IHJlc3VsdCBpbgo+ID4gPiA+ID7C oMKgwqDCoMKgwqAgdGhlIFogYml0IGJlaW5nIHBhcnQgb2YgdGhlIHpvbmUgLyBzdWJuZXQgZmll bGQuwqDCoCBJZiB0aGV5IGFyZSB0d28KPiA+ID4gPiA+wqDCoMKgwqDCoMKgIGRpZmZlcmVudCBz Y2hlbWFzLCB0aGVuIG1vdmUgdGhlIGRpZmZlcmVudGlhdGlvbiB0byBwYXJ0IG9mIHRoZSBzY2hl bWEKPiA+ID4gPiA+wqDCoMKgwqDCoMKgIGlkZW50aWZpZXIgKG1ha2luZyBpdCAzIGJpdHMpLgo+ ID4gPiA+IAo+ID4gPiA+IFdlIGRpZCBub3Qgd2FudCB0byBtYWtlIFogcGFydCBvZiB0aGUgYmFz ZSBzY2hlbWFzIDYuMTAuMiAiVHlwZSIgY29kZSBiZWNhdXNlCj4gPiA+ID4gdGhhdCB3b3VsZCBh bHNvIG1ha2UgdGhlIFZsb25nIHNjaGVtZSBvbmUgYml0IHNob3J0ZXIgYW5kIHRoYXQgd291bGQg cmVkdWNlCj4gPiA+ID4gdmlydHVhbGl6YXRpb24gc3BhY2UgaW4gVmxvbmcgYnkgYSBmYWN0b3Ig b2YgMi4KPiA+ID4gPiAKPiA+ID4gPiBTbywgeWVzLCBlbmNvZGluZyB3aXNlLCA2LjEwLjQgbWFu dWFsIHN1YiBhZGRyZXNzaW5nIHNwYWNlIHdhcyBjYXJ2ZWQgb3V0Cj4gPiA+ID4gb2YgdGhlIDYu MTAuMyB6b25lIGFkZHJlc3Mgc3BhY2UgdmlhIHRoZSBaIGJpdCwgYnV0IHRoYXRzIGp1c3QgYW4g ZW5jb2RpbmcgYXNwZWN0Lgo+ID4gPiA+IAo+ID4gPiA+IEZ1bmN0aW9uYWxseSwgNi4xMC4zLzYu MTAuNCBhcmUgcXVpdGUgZGlmZmVyZW50LCBhbmQgdGhlcmVmb3JlIGl0IGlzIElNSE8KPiA+ID4g PiB0ZXh0dWFsbHkgY29ycmVjdCB0byBoYXZlIHRoZW0gaW4gZGlmZmVyZW50IHN1YnNlY3Rpb25z Lgo+ID4gPiA+IAo+ID4gPiA+IENhcnZpbmcgb3V0IGJpdHMgbGlrZSBaIGlzbid0IGlkZWFsLCBi dXQgaW4gYmV0d2VlbiB0aGUgVUxBIHByZWZpeCwKPiA+ID4gPiB0aGUgNjQgYml0IGxvY2FsIHBh cnQgd2UgbXVzdCBoYXZlIGZvciBleHRlcm5hbCBpbnRlcmZhY2VzIGFuZAo+ID4gPiA+IGJlc3Qg dXRpbGl6YXRpb24gb2YgYml0cywgd2UgdHJpZWQgdG8gcmF0aGVyIG9wdGltaXplIGFkZHJlc3Mg c3BhY2UKPiA+ID4gPiB1dGlsaXphdGlvbiBhbmQgbm90IGJlYXV0eSBvZiBlbmNvZGluZy4KPiA+ ID4gPiAKPiA+ID4gPiBIYXZpbmfCoCBhdCB0aGUgZW5kIGFsbG93cyAoYXMgd3JpdHRlbikgdXNl IG9mIC82MyBpbnN0ZWFkIG9mwqAgMiAqIC82NAo+ID4gPiA+IHJvdXRlcy4gSSBhbSBub3Qgc3Vy ZSBob3cgaW1wb3J0YW50IHRoaXMgd291bGQgYmUgaW4gdGhlIGZ1dHVyZS4KPiA+ID4gPiAKPiA+ ID4gPiBJZiB5b3UgZmVlbCBzdHJvbmdseSBhYm91dCBtb3JlIGJlYXV0eSBpbiBlbmNvZGluZywK PiA+ID4gPiBpIGNhbiBtb3ZlIFogdG8gdGhlIGxlZnQgYW5kIHJlbW92ZSB0aGUgbm90aW9uIG9m IHRoZSBwb3NzaWJsZSAvNjMgcm91dGUKPiA+ID4gPiBvcHRpbWl6YXRpb24gcG9zc2libGUgdGhy b3VnaCB0aGUgcGxhY2VtZW50IG9mIFouCj4gPiA+IAo+ID4gPiBTaW5jZSB0aGUgdHdvIGRpZmZl cmVudCB1c2VzIG9mIHRoZSBaIGJpdCB3aXRoIHR5cGUgMDBiIGFyZSBxdWl0ZSBkaXN0aW5jdCwK PiA+ID4gdHJ5aW5nIHRvIGVuYWJsZSBhZ2dyZWdhdGlvbiBzZWVtcyBjb3VudGVyLXByb2R1Y3Rp dmUuCj4gPiA+IAo+ID4gPiBXaGlsZSBJIGhhdGUgdG8gcHVzaCBvbiBhIHBvaW50IHlvdSBkZXNj cmliZSBhcyBhZXN0aGV0aWNzLCBoYXZpbmcgdGhlIFoKPiA+ID4gYml0LCBvY2N1cmluZyBhZnRl ciB0aGUgWm9uZSAvIHN1Ym5ldC1JRCBmaWVsZCwgYnV0IGRlZmluaW5nIHdoZXRoZXIgdGhlCj4g PiA+IGZpZWxkIGlzIGEgem9uZSBvciBhIHN1Ym5ldCwgc2VlbXMgYXdrd2FyZCBmb3IgaW5zdWZm aWNpZW50IHJlYXNvbi4KPiA+ID4gCj4gPiA+IEkgd291bGQgcmVjb21tZW5kIG1vdmluZyB0aGUg WiBiaXQgdXAgc28gaXQgaXMgYWZ0ZXIgdGhlIHR5cGUsIGFuZCBhdCB0aGUKPiA+ID4gZnJvbnQg b2YgZWFjaCBvZiB0aGUgdHdvIHNlY3Rpb25zIHJlaXRlcmF0ZSB0aGF0IHRoaXMgc3Vic2NoZW1l IGlzIGluZGljYXRlZAo+ID4gPiBieSB0aGUgWiBiaXQgYmVpbmcgeyAwIHwgMSB9Lgo+ID4gCj4g PiBEb25lLiAoc2VlIGRpZmYpLgo+ID4gCj4gPiA+ID4gSSB2ZXJ5IG11Y2ggaG9wZSB0aGVyZSBp cyBubyAiaW50ZXJlc3RpbmciIGltcGxlbWVudGF0aW9uIGFzcGVjdDsKPiA+ID4gPiBub3RoaW5n IGluIHRoZSBjdXJyZW50IHNjaGVtZSB0aGF0IG1ha2VzIGltcGxlbWVuYXRpb24gaGFyZGVyLiBJ ZiB5b3UKPiA+ID4gPiBoYXZlIGFuIGV4YW1wbGUgdGhhdCB5b3UgZmVhciwgaSB3b3VsZCBsaWtl IHRvIGhlYXIgaXQuCj4gPiA+ID4gCj4gPiA+ID4gVG8gbWUsIHdlIGFyZSBqdXN0IGRlZmluaW5n IGFkZHJlc3Mgc3BhY2UgYWxsb2NhdGlvbiBzY2hlbWVzLgo+ID4gPiAKPiA+ID4gSSBzdXBwb3Nl IGxpa2VseSBpbXBsZW1lbnRhdGlvbnMgd2lsbCB1c2UgbWFzayBkZWZpbml0aW9ucyB0aGF0IHdp bGwgbWFrZSBpdAo+ID4gPiB3b3JrLsKgIEkgcGl0eSB0aGUgY29kZSByZXZpZXdlci4KPiA+IAo+ ID4gSSBoYXZlIHJlYWQgdGhlIGNvZGUgYW5kIHRlc3RlZCBpbiB0aGUgbGFiIElQdjYgZW1iZWRk ZWQgUlAgYWRyZXNzaW5nCj4gPiBhbmQgZGlkbid0IGZlZWwgcGl0eWZ1bGwgYWJvdXQgdGhlIGpv Yi4gQnV0IGkgd2VpZ2ggdGhlIG92ZXJhbGwgc3lzdGVtCj4gPiBjb21wbGV4aXR5LiBFbWJlZGRl ZC1SUCBzaW1wbGlmaWVkIGEgbG90IG9mIG90aGVyIHBhcnRzIG9mIHRoZQo+ID4gbXVsdGljYXN0 IHN5c3RlbSBhdCB0aGUgY29zdCBvZiBpbnRyb2R1Y2luZyBhbiBhZGRyZXNzaW5nIHNjaGVtZS4K PiA+IEkgdGhpbmsgc2ltaWxhcmlseSwgdGhlIEFDUCBhZGRyZXNzaW5nIHNjaGVtZSBzaW1wbGlm aWVzIHRoZSBvdmVyYWxsIHN5c3RlbQo+ID4gY29tcGxleGl0eSwgZXNwZWNpYWxseSByZWdpc3Ry YXJzLgo+ID4gCj4gPiA+ID4gPsKgwqDCoMKgwqDCoCBJbiBzZWN0aW9uIDYuMTAuNSwgYWZ0ZXIg c3RhdGluZyB0aGF0IGl0IGlzIG5vdCBldmVuIGtub3duIHdoYXQgdGhlIG5lZWRlZAo+ID4gPiA+ ID7CoMKgwqDCoMKgwqAgdXNhZ2UgaXMgZm9yIG1vcmUgViB2YWx1ZXMKPiA+ID4gPiAKPiA+ID4g PiBXaGljaCBzZW50ZW5jZSBhcmUgeW91IHJlZmVycmluZyB0byB3aGVuIHlvdSBzYXkgIm5vdCBl dmVuIGtub3duIHdoYXQgdGhlCj4gPiA+ID4gbmVlZGVkIHVzYWdlIGlzIiA/IEkgY2FuJ3QgZmlu ZCBpdCwgYnV0IGkgd291bGQgbGlrZSB0byByZWN0aWZ5IGl0Cj4gPiA+ID4gaWYgaXQgYWN0dWFs bHkgaXMgc3RpbGwgdGhlcmUuCj4gPiA+IAo+ID4gPiBUaGUgdGV4dCByZWFkcyAiZnVydGhlciB2 YWx1ZXMgdXNlIHZpYSBkZWZpbml0aW9uIGluIGZ1dHVyZSB3b3JrLiLCoCBJbiB0aGUKPiA+ID4g em9uZS1pZCBzY2hlbWUsIGl0IGlzIG9uZSBiaXQuwqAgRm9yIHNvbWUgcmVhc29uLCBpdCBpcyA4 IG9yIDE2IGJpdHMgaGVyZS4KPiA+IAo+ID4gVGhhbmtzLCBjaGFuZ2VkIHNlbnRlbmNlIHRvOgo+ ID4gCj4gPiBWOiBWaXJ0dWFsaXphdGlvbiBiaXQ6IFZhbHVlcyAwIGFuZCAxIGFyZSBhc3NpZ25l ZCBpbiB0aGUgc2FtZSB3YXkgYXMgaW4gdGhlIFpvbmUtSUQgc3ViLXNjaGVtZS4KPiA+IAo+ID4g VGhlIGV4aXN0aW5nIHRleHQsIG5vdyBkaXJlY3RseSBhZnRlciB0aGUgbGlzdCwgZXhwbGFpbnMg ZXhhbXBsZXMKPiA+IHdoZW4gYSBkZXZpY2Ugd291bGQgbGlrZWx5IG5lZWQgMjU2IG9yIDY0ayBh ZGRyZXNzZXM6Cj4gPiAKPiA+IGV4aXN0aW5nIHRleHQ6Cj4gPiAuLi4iMSIgYml0IE5vZGUtTnVt YmVycyBhcmUgaW50ZW5kZWQgZm9yIEFDUCBub2RlcyB0aGF0IGFyZSBBQ1AgZWRnZSBub2RlcyAu Li4KPiA+IAo+ID4gPiA+ID7CoMKgwqDCoMKgwqAgdGhlIGRvY3VtZW50IGdvZXMgb24gdG8gaW50 cm9kdWNlIHRoZQo+ID4gPiA+ID7CoMKgwqDCoMKgwqAgY29tcGxleGl0eSBvZiBjbGFzc2Z1bCBu b2RlcyBudW1iZXJzLCB3aXRoIHRoZSBsZWFkaW5nIGJpdCBpbmRpY2F0aW5nIGhvdwo+ID4gPiA+ ID7CoMKgwqDCoMKgwqAgbG9uZyB0aGUgbm9kZS1udW1iZXIgaXMuwqAgWWVzLCB0aGUgcmVzdCBv ZiB0aGUgdGV4dCBpbiB0aGF0IGJ1bGxldCB0cmllcyB0bwo+ID4gPiA+ID7CoMKgwqDCoMKgwqAg ZXhwbGFpbiB3aHkgeW91IG5lZWQgYm90aCBzaXplcy7CoCBJdCBzZWVtcyBsaWtlIG5lZWRsZXNz IGNvbXBsZXhpdHkgdGhhdAo+ID4gPiA+ID7CoMKgwqDCoMKgwqAgYmVncyBmb3IgbWlzdGFrZXMg aW4gaW1wbGVtZW50YXRpb24uCj4gPiA+ID4gCj4gPiA+ID4gSSB3YXMgdGFraW5nIHRoZSBleGFt cGxlIHVzZSBjYXNlcyB3ZSBicmFpbnN0b3JtZWQgaW50byBhY2NvdW50LCBhbmQKPiA+ID4gPiBz b21lIG9mIHRoZW3CoCB3b3VsZCByZXF1aXJlIGEgbG90IG1vcmUgYWRkcmVzc2VzIGluIHRoZSBu b2RlIHRoYW4gb3RoZXJzLAo+ID4gPiA+IHRoZXJlZm9yZSB0aGVzZSB0d28gY2hvaWNlcy4KPiA+ ID4gCj4gPiA+IFNlZSBteSBjb21tZW50cyBhYm92ZS7CoCBUcnlpbmcgdG8gZW5jb2RlIHNwZWNp ZmljIHVzZSBjYXNlcyBpbnRvIHRoZSBhZGRyZXNzCj4gPiA+IGZvcm1hdCBzZWVtcyBhIHByb2Js ZW1hdGljIGFuc3dlciB0byBhbiBhZG1pdHRlZGx5IGRpZmZpY3VsdCBxdWVzdGlvbi4KPiA+ID4g Cj4gPiA+IFdoYXQgd291bGQgYnJlYWsgaWYgeW91IGRpZG4ndCBkZWZpbmUgYW55IG9mIHRoaXM/ Cj4gPiAKPiA+IE9uZSBjb3VsZCBzYXZlIHRoZSAyLjUgYml0cyAoVHlwZSwgWikgaW5kaWNhdGlu ZyB0aGUgc3RydWN0dXJlIG9mIHRoZQo+ID4gYWRkcmVzcyBpbnNpZGUgdGhlIGFkZHJlc3MgYnkg ZW5jb2RpbmcgdGhlIGRlc2lnbmF0ZWQgZm9ybWF0IG9mIHRoZQo+ID4gYWRkcmVzcyBpbnN0ZWFk IGluIGFuIGV4dGVuc2lvbiBmaWVsZCBvZiB0aGUgQUNQIGFkZHJlc3MgaW5mb3JtYXRpb24gaW4K PiA+IHRoZSBjZXJ0aWZpY2F0ZS4gV2Ugd291bGQgY2VydGFpbmx5IHN0aWxsIHdhbnQgdG8gaGF2 ZSB0aGUgc2FtZSB0eXBlCj4gPiBvZiBhZGRyZXNzZXMsIGUuZy46IDIsMjU2LDY0ayBsb2NhbCBh ZGRyZXNzZXMsIG9wdGlvbiBmb3Igem9uZXMgYW5kCj4gPiBhZGRyZXNzIHRvIGFzc2lnbiB0byBB Q1AgY29ubmVjdCBpbnRlcmZhY2VzIChtYW51YWwgYWRkcmVzc2luZyBzY2hlbWUpCj4gPiBJTUhP LiBTbywgYXQgYmVzdCB3ZSBjb3VsZCBzYXZlIHRoZSAyLjUgYml0cyBpZiB3ZSB3YW50ZWQgdG8g a2VlcCB0aGUKPiA+IGZ1bmN0aW9uYWxpdHksIHdoaWNoIGkgdGhpbmsgaXMgYWxsIHJlcXVpcmVk Lgo+ID4gCj4gPiBJIHdvdWxkIGJlIHF1aXRlIGFmcmFpZCBvZiBkb2luZyBzdWNoIGEgZHJhc3Rp YyBjaGFuZ2UgdGhpcyBsYXRlIGluCj4gPiB0aGUgcHJvY2VzcyBiZWNhdXNlIGkgdGhpbmsgaXQg d2lsbCB0YWtlIGEgbG9uZyB0aW1lIHRvIGZvcmVzZWUgdGhlCj4gPiByZXN1bHRpbmcgY29tcGxl eGl0eSBpbnRyb2R1Y2VkIGZvciByZWdpc3RhcnMgYW5kIGFueSBvdGhlciBwbGFjZQo+ID4gdGhh dCBub3cgY2FuIGRlZHVjdCB0aGUgc2VtYW50aWMgZnJvbSB0aGUgYWRkcmVzcyBhbmQgd291bGQg dGhlbiBoYXZlCj4gPiB0byBhY2Nlc3MgdG8gd2hhdCB0aGUgY2VydGlmaWNhdGUgaW5kaWNhdGVz IGluIGEgZGlmZmVyZW50IHdheSAoZS5nLjoKPiA+IGFjY2VzcyB0byB0aGUgY2VydGlmaWNhdGUp LiBOb3RlIHRoYXQgdGhlIGxlbmd0aCBvZiB0aGUgQUNQIGluZm9ybWF0aW9uCj4gPiBmaWVsZCBp biB0aGUgY2VydCBpcyBhbHNvIGxpbWl0ZWQsIHNvIHRoaXMgdHlwZSBvZiBleHRlbnNpb24gbWln aHQgZW5kCj4gPiB1cCBsb29raW5nIGV2ZW4gdWdsaWVyIHRvIGJlIHNob3J0ICpzaWdoKi4KPiA+ IAo+ID4gSSB3YXMgYWx3YXlzIHRoaW5raW5nIHRoYXQgdGhpcyB0eXBlIG9mIG1vcmUgZmxleGli bGUgb3B0aW9uIHdvdWxkCj4gPiBiZSBhIGdvb2QgbmV4dC1zdGVwLCBidXQgbm90IGEgc2FmZSBm aXJzdCBzdGVwLiBJdCB3b3VsZCBtYWtlIGEgbG90Cj4gPiBtb3JlIHNlbnNlIGFmdGVyIGhlYXJp bmcgaW1wbGVtZW50YXRpb24vZGVwbG95bWVudCBleHBlcmllbmNlcywKPiA+IGVzcGVjaWFsbHkg dG8gY29ycmVjdGx5IHN1cHBvcnQgaW1wb3J0YW50IG9wdGlvbnMgd2UgbWF5IGhhdmUKPiA+IG92 ZXJsb29rZWQgaW4gdGhlIGN1cnJlbnQgc2NoZW1lcy4gSnVzdCByZWRvaW5nIHdoYXQgd2UgaGF2 ZSBkaWZmZXJlbnRseQo+ID4gdG8gc2F2ZSAyLjUgYml0cyBpc24ndCB3b3J0aCBpdCBJTUhPLgo+ ID4gCj4gPiA+ID4gVWx0aW1hdGVseSwgd2UgbmVlZCB0byBicmVhayB0aHJvdWdoIHRoZSBjaGlj a2VuIGFuZCBlZ2cgcHJvYmxlbQo+ID4gPiA+IG9mIGhvdyB0byBidWlsZCBtb3JlIHNlbGYtbWFu YWdpbmcgbmV0d29ya3MuIFRoZXNlIHdpbGwgcmVxdWlyZQo+ID4gPiA+IGEgZGlmZmVyZW50IG51 bWJlciBvZiBhZGRyZXNzZXMgaW5zaWRlIG5vZGVzLiBBbnl0aGluZyBtb3JlIGludGVsbGlnZW50 Cj4gPiA+ID4gdGhhbiBhZGRyZXNzIHNwYWNlIGFsbG9jYXRpb25zIHdvdWxkIGJlY29tZSBhIGNv bXBsZXggZGVwZW5kZW5jeQo+ID4gPiA+IG1ha2luZyBpbXBsZW1lbnRhdGlvbi9hZG9wdGlvbiBl dmVuIHNsb3dlci4gSSBkb24ndCB0aGluayB0aGF0Cj4gPiA+ID4gb2ZmZXJpbmcgMiwgMjU2LCA2 NGsgYWRkcmVzc2VzIHBlciBub2RlIGlzIHRvbyBtdWNoIGZsZXhpYmlsaXR5Lgo+ID4gPiA+IEl0 IElNSE8gbmVjZXNzYXJ5IGFuZCBzdWZmaWNpZW50IHRvIGV4cGxvcmUgYW5kIHdlJ2xsIHNlZSB3 aGF0IHN0aWNrcy4KPiA+ID4gCj4gPiA+IFZhcmlhdGlvbiBpcyBuZWVkZWQuwqAgVGhhdCB3YXMg dHJ1ZSBvZiBhbGxvY2F0aW9ucyBpbiBJUC7CoCBlbmNvZGluZyB0aGUKPiA+ID4gdmFyaWF0aW9u cyBwcm92ZWQgYSBiYWQgY2hvaWNlLgo+ID4gCj4gPiBMZXQgbWUgcmVwZWF0IHRoYXQgd2UgYXJl IG5vdCBkb2luZyBhbnkgbmV0d29yay9zdWJuZXQgcHJlZml4IGVuY29kaW5nIHdoaWNoIGlzCj4g PiB3aGF0IElQdjQgQS9CL0Mgd2FzLiBBbmQgdGhlcmUgYXJlIElNSE8gZ29vZCBleGFtcGxlcyBo b3cgZW5jb2RpbmcgaW4gSVB2Ngo+ID4gZGlkIHNhdmUgdGhlIGRheSBmcm9tIGNvbXBsZXhpdHkg KGF0IGxlYXN0IGFsbCB0aGUgc3R1ZmYgZG9uZSBmb3IgSVB2Ngo+ID4gbXVsdGljYXN0LCBBU00v U1NNLCB6b25lcywgRW1iZWRkZWQtUlApIHdhcyBoaWdobHkgdXNlZnVsLgo+ID4gCj4gPiA+ID4g PsKgwqDCoMKgwqDCoCBJbiBzZWN0aW9uIDYuMTEuMS4xMSBpbiBkZXNjcmliaW5nIHRoZSBwcmVm aXggbGVuZ3RocywgSSB0aG91Z2h0IHRoYXQgdGhlCj4gPiA+ID4gPsKgwqDCoMKgwqDCoCBwb2lu dCBvZiB6b25lIGFkZHJlc3Npbmcgd2FzIHRvIGFsbG93IHRoZSB1c2Ugb2YgLzY0IHByZWZpeGVz LsKgIEJ1dCBpdAo+ID4gPiA+ID7CoMKgwqDCoMKgwqAgc2VlbXMgaGVyZSB0aGF0IHdlIHdpbGwg bm90IGRvIHNvID8KPiA+ID4gPiAKPiA+ID4gPiBBcyBtZW50aW9uZWQgYWJvdmU6IFRoaXMgZG9j dW1lbnQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHJvdXRpbmcgc2V0dXAgZm9yIC82NAo+ID4gPiA+ IChvciAvNjMgd2l0aCBaLWJpdCkgcm91dGluZyBhZ2dyZWdhdGlvbi4gVGhlcmUgYXJlIG11bHRp cGxlIG9wdGlvbnMsCj4gPiA+ID4gYnV0IHdlIGNvdWxkIG5vdCBjb25jbHVkZSBvbiBhIHNpbmds ZSBzb2x1dGlvbiB0aGF0IHdlIGZlbHQgdG8gYmUKPiA+ID4gPiBhcHByb3ByaWF0ZSBmb3IgdGhp cyBkb2N1bWVudC4gSW5zdGVhZCBpdCB3YXMgb25seSB2ZXJ5IGltcG9ydGFudAo+ID4gPiA+IHRv IGNhcnZlIG91dCBhZGRyZXNzaW5nIHNwYWNlIHRvIHN1cHBvcnQgdGhpcy4KPiA+ID4gVGhlIG5l dCBlZmZlY3Qgc2VlbXMgdG8gYmUgdG8gcHJvaGlidCB0aGUgdmVyeSB0aGluZ3MgdGhhdCB5b3Ug d2VudCB0byBhIGxvdAo+ID4gPiBvZiB0cm91YmxlIHRvIGVuYWJsZSBpbiB5b3VyIGFkZHJlc3Np bmcgZGVzaWduLgo+ID4gCj4gPiBNYXliZSBpIGRvIG5vdCB1bmRlcnN0YW5kIHlvdXIgY29tbWVu dCBjb3JyZWN0bHksIGJ1dCBpIGRvIG5vdAo+ID4gdGhpbmsgaXQgaXMgY29ycmVjdC4gV2UganVz dCBoYXZlIG5vdCBkZWZpbmVkIHJlY29tbWVuZGVkIG1lY2hhbmlzbXMKPiA+IGhvdyB0byBzZXQg dXAgcm91dGluZyB0byB1c2UgLzY0IHpvbmUgcm91dGVzLiBUaGF0IGlzIHNvbWV0aGluZyBJTUhP Cj4gPiBiZXR0ZXIgZG9uZSBpbiBhIGZvbGxvd3VwIGRvY3VtZW50IGJlY2F1c2UgYWxsIHRoZSBj YXNlcyB3aGVyZSB3ZQo+ID4gZGlkIHNlZSBhIG5lZWQgZm9yIHpuZXMgd2hlcmUgcmVhbGx5IHZl cnkgc3BlY2lmaWMgdG8gcGFydGljdWxhcgo+ID4gZGVwbG95bWVudCBzdHlsZXMgYW5kIHdvdWxk IG5vdCBiZSBhcHBsaWNhYmxlIHRvIHRoZSBtYXlvcml0eSBvZiBBQ1BzLgo+ID4gTmV2ZXJ0aGVs ZXNzLCB3ZSBmZWx0IHRob3NlIGNhc2VzIHdoZXJlIGltcG9ydGFudCBlbm91Z2ggdG8gcmVzZXJ2 ZQo+ID4gYml0cyBmb3IgdGhlbSB0aHJvdWdoIHRoZSB6b25lIGZpZWxkLgo+ID4gCj4gPiA+IC4u Lgo+ID4gPiA+ID4gKioqwqDCoMKgIFNlY3Rpb24gMTAuMy4yIHBhcmFncmFwaCAyIHNheXMgdGhh dCBkZXZpY2VzIHNob3VsZCBjaGFuZ2UgdGhlIG1lYW5pbmcKPiA+ID4gPiA+IG9mICJhZG1pbiBk b3duIiB0byBtZWFuICJkb3duIGZvciBldmVyeXRoaW5nIGV4Y2VwdCBBQ1AgLyBBbmltYSIuwqDC oMKgIEkgY2FuCj4gPiA+ID4gPiB1bmRlcnN0YW5kIHdoeSwgaW4gYW4gYXV0b25vbWljIG5ldHdv cmssIHN1Y2ggYSBzdGF0ZSBpcyBkZXNpcmFibGUuwqAgSG93ZXZlciwKPiA+ID4gPiA+IHRoYXQg cmVhbGx5IHNob3VsZCBiZSBhIGRpZmZlcmVudCBzdGF0ZSBmcm9tICJhZG1pbiBkb3duIi7CoCBP cGVyYXRvcnMgYWxyZWFkeQo+ID4gPiA+ID4gdW5kZXJzdGFuZCAiYWRtaW4gZG93biIgYXMgbWVh bmluZyB0aGF0IHRoaXMgaW50ZXJmYWNlIHdpbGwgbm90IGJlIHVzZWQgZm9yIGFueQo+ID4gPiA+ ID4gdHJhZmZpYy7CoCBDaGFuZ2luZyB0aGF0IGlzIGZhaXJseSBkcmFzdGljLsKgICJhZG1pbiBs aW1pdGVkIiBvciAiYWRtaW4gQUNQLU9ubHkiCj4gPiA+ID4gPiB3b3VsZCBzZWVtIG11Y2ggYmV0 dGVyIHRoYW4gY2hhbmdpbmcgdGhlIG1lYW5pbmcgb2YgImFkbWluIGRvd24iLsKgIFRoZQo+ID4g PiA+ID4ganVzdGlmaWNhdGlvbiBpbiB0aGUgdGV4dCBzZWVtcyB0byBiZSBhIGRlc2lyZSB0byBw cmV2ZW50IGFuIG9wZXJhdG9yIGZyb20KPiA+ID4gPiA+IGRvaW5nIHdoYXQgaGUgaW50ZW5kcy7C oCB0aGF0IHNlZW1zIGJhY2t3YXJkcy7CoCAoTm90ZSB0aGF0IHRoZSBkaXN0aW5jdGlvbgo+ID4g PiA+ID4gYmV0d2VlbiBhZG1pbmlzdHJhdGl2ZSBzdGF0ZSB2cyBvcGVyYXRpb25hbCBzdGF0ZSwg YWthIGZhaWxlZCwgaXMgYWxyZWFkeSB3ZWxsCj4gPiA+ID4gPiB1bmRlcnN0b29kLikKPiA+ID4g PiAKPiA+ID4gPiBXZWxsLCB0aGlzIGlzIGluIGFuIGluZm9ybWF0aXZlIHNlY3Rpb24sIHNvIGhv cGVmdWxseSBzb21ldGhpbmcgd2UgY2FuIGFncmVlIHRvIGRpc2FncmVlLgo+ID4gPiAKPiA+ID4g SWYgdGhpcyB3ZXJlIHRydWx5IGluZm9ybWF0aXZlLCBpdCB3b3VsZCBub3QgYmVsb25nIGluIHRo aXMgZG9jdW1lbnQgYXQgYWxsLgo+ID4gPiBDaGFuZ2luZyB0aGUgYmVoYXZpb3Igb2Ygd2lkZWx5 IHVuZGVyc3Rvb2QgY29uZmlndXJhdGlvbiBiZWhhdmlvcnMgaXMgTk9UIGEKPiA+ID4gc21hbGwg dGhpbmcuwqAgQ2hhbmdpbmcgdGhlIHBlcm1pc3Npb25zIG1vZGVscyBmb3Igd2lkZWx5IHVuZGVy c3Rvb2QKPiA+ID4gY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIGlzIGFsc28gTk9UIGEgc21hbGwg dGhpbmcuCj4gPiA+IAo+ID4gPiBNeSBzdWdnZXN0aW9uIGlzIHRoYXQgeW91IHJlbW92ZSBhbGwg b2YgdGhpcyBtYXRlcmlhbC7CoCBJZiB5b3UgZmVlbCBpdCBpcwo+ID4gPiBpbXBvcnRhbnQsIHdy aXRlIGFuIEktRCBmb3Igc3RhbmRhcmRzIHRyYWNrIG9uIGV2b2x2aW5nIHRoZSBjb25maWd1cmF0 aW9uCj4gPiA+IG1vZGVsIGZvciByb2J1c3QgQU5JTUEuwqAgV2hpbGUgSSB0aGluayB0aGUgY2hh bmdlIGlzIGEgbWlzdGFrZSwgeW91IGNsZWFybHkKPiA+ID4gaGF2ZSB0aGUgcmlnaHQgdG8gY2F1 c2UgdGhlIGRpc2N1c3Npb24uCj4gPiA+IAo+ID4gPiBIaWRpbmcgdGhlIHRvcGljIGluIGFuICJp bmZvcm1hdGlvbmFsIiBub3RlIGluIHRoZSBBQ1AgZG9jdW1lbnQgc2VlbXMgVkVSWQo+ID4gPiB3 cm9uZy4KPiA+ID4gCj4gPiA+IEFsc28gbm90ZSB0aGF0IGluIHlvdXIgZGlzY3Vzc2lvbiBiZWxv dywgeW91IHRhbGsgYWJvdXQgdGhlIGVxdWl2YWxlbmNlIG9mCj4gPiA+IGFkbWluIGRvd24gYW5k IHBoeXNpY2FsIGRvd24uwqAgTW9zdCBtYW5hZ2VtZW50IG1vZGVscyBJIGtub3cgb2YgdHJlYXQg dGhlc2UKPiA+ID4gYXMgcXVpdGUgZGlzdGluY3QuwqAgU08gdGhhdCBpcyBhdCBiZXN0IGEgcmVk IGhlcnJpbmcuCj4gPiAKPiA+IEhtbS4gSSByZWFsbHkgb25seSBDTEkgZGVyaXZlZCBmcm9tIENp c2NvIElPUywgYW5kIHRoZXJlIHRoZQo+ID4gaW50ZXJmYWNlIGxldmVsICJzaHV0ZG93biIgY29t bWFuZCBkb3VibGVzIElNSE8gYm90aCBhcyBhZG1pbiBkb3duIGFuZAo+ID4gYXMgcGh5IGRvd24s IHNvIGkgd291bGQgY29udGVuZCB0aGF0IHRoaXMgaXMgYSByZWQgaGVycmluZy4gSXQgYWN0dWFs bHkKPiA+IGRvZXMgc2hvdyB1cCBpbiBkaWFnbm9zdGljIENMSSBhcyAiYWRtaW4gZG93biIsIGJ1 dCBpcyBhbHNvIGJyaW5naW5nIGRvd24KPiA+IHBoeSBzdGF0ZS4gVGhlcmVmb3JlIGl0IGlzIGFs c28gdXNlZCB0byBkaWFnbm9zZSBwaHksIC5lLmc6IHNodXR0aW5nIGRvd24KPiA+IG9uZSBzaWRl IG9mIGEgc3VwcG9zZWQgZGlyZWN0IHAycCBsaW5rIHRvIHZlcmlmeSB0aGUgcGh5IGNoYW5nZSBv biB0aGUKPiA+IG90aGVyIHNpZGUuIFRoYXQgcHJhY3RpY2FsIGV4cGVyaWVuY2UgaXMgd2hhdCB0 aGUgdGV4dCBhbmQgZGlyZWN0aW9uIGlzCj4gPiBiYXNlZCBvbi4KPiA+IAo+ID4gV2hhdHMgYW4g ZXhhbXBsZSB3aGVyZSBhZG1pbi9waHkgZG93biBhcmUgc2VwYXJhdGUgaW4geW91ciBleHBlcmll bmNlID8KPiA+IAo+ID4gSSBkb24ndCBrbm93IGhvdyB5b3UgZGVmaW5lICJ0cnVseSBpbmZvcm1h dGl2ZSIuIEkgc2ltcGx5IG1lYW50Cj4gPiBpbmZvcm1hdGlvbmFsIGFzIGNvbXBhcmVkIHRvIHN0 YW5kYXJkcyB0cmFjayB3cnQuIHRvIG5vdCBpbXBhY3RpbmcKPiA+IGludGVyb3BlcmFiaWxpdHks IGJ1dCBhbHNvIGFzIGEgcHJlY3Vyc29yIHdvcmsgdG8gZ2l2ZSBvcHBvcnR1bml0eQo+ID4gZm9y IGdhaW5pbmcgbW9yZSBleHBlcmllbmNlIGJlZm9yZSBhdHRlbXB0aW5nIHRvIGdvIHN0YW5kYXJk Lgo+ID4gCj4gPiBJZi93aGVuIGkgZmluZCB0aW1lIGkgZGVmaW5pdGVseSB3b3VsZCBsaWtlIHRv IGludmVzdGlnYXRlIGhvdyB0aGlzCj4gPiBjb3VsZCBiZSBmb3JtYWxpemVkIHRocm91Z2ggYSBZ QU5HIG1vZGVsIGZvciBBQ1Agc28gdGhhdCBpdCBjYW4gYmVjb21lIHN0YW5kYXJkLAo+ID4gYnV0 IGkgZGVmaW5pdGVseSBhZ3JlZSB0aGF0IGVzcGVjaWFsbHkgdGhpcyBwYXJ0IG9mIHRoZSBZQU5H IG1vZGVsIHdvdWxkCj4gPiBiZSBoaWdobHkgZGlmZmljdWx0IHRvIGdldCB0byBiZWZvcmUgYW55 IGV4cGVyaWVuY2UgaXMgZ2FpbmVkIHdpdGgKPiA+IHRoaXMuCj4gPiAKPiA+IEkgdGhlcmVmb3Jl IHdvdWxkIHZlcnkgbXVjaCBoZXNpdGF0ZSByZW1vdmluZyB0aGlzIHRleHQgZnJvbSB0aGUgZG9j dW1lbnQsIGl0IHdhcwo+ID4gc3BlY2lmaWNhbGx5IGFza2VkIGZvciBzZXZlcmFsIHRpbWVzIGlu IHRoZSB3b3JraW5nIGdyb3VwIHRvIHVuZGVyc3RhbmQKPiA+IGhvdyB0aGUgcHJvbWlzZWQgcmVs aWFiaWxpdHkgb2YgdGhlIEFDUCBhZ2FpbnN0IG9wZXJhdG9yL2NvbnRvbGxlcgo+ID4gb3BlcmF0 aW9uIGNvdWxkIGJlIGFjaGlldmVkLiBIYXZpbmcgdGhpcyBpbiBhIGZpcnN0IHJvdW5kICh0aGlz IGRvY3VtZW50KQo+ID4gYXMgImluZm9ybWF0aW9uYWwiIGlzIElNSE8gYSBnb29kIGFuZCBpbXBv cnRhbnQgdGhpbmcuCj4gPiAKPiA+ID4gKHRleHQgcmV0YWluZWQgZm9yIGNvbnRleHQgb2YgZnVy dGhlciBkaXNjdXNzaW9ucy4pCj4gPiA+IAo+ID4gPiA+IAo+ID4gPiA+IEkgc3Ryb25nbHkgYmVs aWV2ZSB0aGF0IHRoZSBtb3N0IGVhc3kgd2F5IHRvIG9wZXJhdGlvbmFsaXplIHRoZSBBQ1AgYW5k Cj4gPiA+ID4gYWNoaWV2ZSBpdHMgZ29hbHMgaXMgd2hhdCB3ZSBoYXZlIHdyaXR0ZW4uCj4gPiA+ ID4gCj4gPiA+ID4gVGhlIGhpc3RvcmljIGVxdWl2YWxlbmNlIG9mICJkb3duIiA9ICJhZG1pbiBk b3duIiA9ICJwaHlzaWNhbCBkb3duIiBpcyBvbmUgb2YKPiA+ID4gPiB0aGUgdGhlIG1vc3QgZnVu ZGFtZW50YWwgcHJvYmxlbSBvZiByZW1vdGUgbWFuYWdlbWVudCBpbiBuZXR3b3Jrcy4KPiA+ID4g PiAKPiA+ID4gPiBXZSByZWFsbHkgbmVlZCB0byBzdGFydCB0aGlua2luZyBvZiBzZXBhcmF0ZSBs YXllcnMgb2YgKHJlbW90ZSkgbWFuYWdlbWVudC4KPiA+ID4gPiBOZXR3b3JrIHNlcnZpY2VzIG9u IG9uZSBoYW5kIGFuZCBwaHlzaWNhbCBpbmZyYSBvbiB0aGUgb3RoZXIuCj4gPiA+ID4gCj4gPiA+ ID4gVGhlIGZpcnN0IHRoaW5nIHRvIGRvIHRoaXMgaXMgdG8gc2VwYXJhdGUgb3BlcmF0aW9ucyBz dWNoIGFzICJkb3duIgo+ID4gPiA+IGludG8gImFkbWluIGRvd24iIHRoYXQgYWZmZWN0cyBuZXR3 b3JrcyBzZXJ2aWNlcyBhbmQgInBoeSBkb3duIiB0aGF0Cj4gPiA+ID4gYWZmZWN0cyB0aGUgcGh5 c2NpYWwgaW5mcmEuCj4gPiA+ID4gCj4gPiA+ID4gSWYgeW91IGhhdmUgZXhpc3RpbmcgY29tbWFu ZHMgbGlrZSAic2h1dGRvd24iIHRoYXQgdG9kYXkgZG8gYm90aCwKPiA+ID4gPiB0aGUgc2FmZSBt YXBwaW5nIGlzIHRvIGxldCB0aGVtIGRvIHRoZSBzYWZlIHRoaW5nIGluIHRoZSBmdXR1cmUsIGUu ZzoKPiA+ID4gPiBvbmx5ICJhZG1pbiBkb3duIiwgYW5kIGludHJvZHVjZSBuZXcgY29tbWFuZHMg Zm9yIHRoZSBwaHkgb3BlcmF0aW9ucywKPiA+ID4gPiBlLmcuOiAicGh5IHNodXRkb3duIiBvciB0 aGUgbGlrZS4KPiA+ID4gPiBBbmQgdGhlbiBwcm90ZWN0IHRob3NlIGRhbmdlcm91cyBjb21tYW5k cyBldmVuIGZ1cnRoZXIgYWdhaW5zdCB1bmludGVudGlvbmFsIG9yCj4gPiA+ID4gaW50ZW50aW9u YWwgbWlzdXNlLgo+ID4gPiA+IAo+ID4gPiA+IFRoaW5rIG9mIEFDUC9BTkkgYWxzbyBhcyBhIHNl YW1sZXNzIGluYmFuZCB2ZXJzaW9uIG9mIGEgRENOLiBBcyBhbiBvcGVyYXRvcgo+ID4gPiA+IG9m IHRoZSBhY3R1YWwgZGF0YSBuZXR3b3JrLCB5b3UgYWxzbyBkaWRuJ3QgaGF2ZSBhbnkgYWNjZXNz IHRvIGJyaW5nIGRvd24gdGhlIERDTgo+ID4gPiA+IGFuZCBjdXQgeW91cnNlbGYgb2ZmIGZyb20g dGhlIG5ldHdvcmsgeW91IG1hbmFnZS4gWU91IGNvdWxkIG9ubHkgc2NyZXcKPiA+ID4gPiB1cCB0 aGF0IG5ldHdvcmsgeW91J3JlIG1lYW50IHRvIG1hbmFnZS4KPiA+ID4gPiAKPiA+ID4gPiBBbmQg aWYgeW91ciBuZXR3b3JrIGNvbnNpc3RzIG9mIFZNcyBpbiBhIERDLCBhICJzaHV0ZG93biIgb24g dGhlaXIKPiA+ID4gPiBpbnRlcmZhY2VzIHdpbGwgYWxzbyBub3QgYnJpbmcgZG93biBwaHlzaWNh bCBpbnRlcmZhY2VzIG5lY2Vzc2FyeQo+ID4gPiA+IHRvIHJlYWNoIHRoZSBWTS4KPiA+ID4gPiAK PiA+ID4gPiBJbiBvcHRpY2FsIG5ldHdvcmtzIHlvdSBvZnRlbiBoYXZlIGFuIGluYmFuZCBwaHlz Y2lhbCBldGhlcm5ldCBtYW5hZ2VtZW50Cj4gPiA+ID4gY2hhbm5lbC4gTWFraW5nL2JyZWFraW5n IHRoYXQgb25lIGlzIGNvbXBsZXRlbHkgZGlmZmVyZW50IGZyb20gbWFraW5nL2JyZWFraW5nCj4g PiA+ID4geW91ciBkYXRhLXBsYW5lLCBha2E6IGRhdGEgZmliZXIgY29sb3JzLgo+ID4gPiA+IAo+ ID4gPiA+ID4gKioqwqDCoMKgIFRoZSBub3Rpb24gaW4gMTAuMy42IHRoYXQgdGhlIGRldmljZSBz aG91bGQgcmVmdXNlIHRvIGRpc2FibGUKPiA+ID4gPiA+IGZ1bmN0aW9uYWxpdHkgd2hlbiBhbiBh dXRob3JpemVkIGFkbWluaXN0cmF0b3IgZGlyZWN0cyBzdWNoIHNlZW1zIGZsYXRseSB3cm9uZy4K PiA+ID4gPiAKPiA+ID4gPiBUaGUgYXV0aG9yaXphdGlvbiB0byBicmVhayB5b3VyIG93biByZW1v dGUgbWFuYWdlbWVudCBjb25uZWN0aXZpdHkKPiA+ID4gPiB3b3VsZCBiZSBhIHByb3BlcnR5IG9m IHRoZSBjZXJ0aWZpY2F0ZS4gY2xlYXJseSB3aG9ldmVyIGVucm9sbGVkCj4gPiA+ID4gdGhlIGRl dmljZSB3aXRoIGEgY2VydGlmaWNhdGUgZGVueWluZyB0aGF0IGNhcGFpbGl0eSB0byB0aGUgb3Bl cmF0b3IKPiA+ID4gPiBkaWQgTk9UIGF1dGhvcml6ZSB0aGUgYWRtaW5pc3RyYXRvciB0byBicmVh ayBjb25uZWN0aXZpdHkuCj4gPiA+IAo+ID4gPiBUaGUgc2VjdXJpdHkgbW9kZWwgY2hhbmdlIHNl ZW1zIGFzIHByb2JsZW1hdGljIGFzIHRoZSBhYm92ZSBjb25maWd1cmF0aW9uCj4gPiA+IGNoYW5n ZS4KPiA+IAo+ID4gV2UgaGF2ZSByZWN1cnJpbmdseSBoZWFyZCBmcm9tIGN1c3RvbWVycyB0aGF0 IG1pc3Rha2VzIGluIG1hbmFnaW5nIHJlbW90ZQo+ID4gZXF1aXBtZW50IGFuZCBsb29zaW5nIGNv bm5lY3Rpdml0eSBpcyBhIG1heW9yIHBhaW4gcG9pbnQuIENyZWF0aW5nCj4gPiBhbiBvcGVyYXRp b25hbCBvcHRpb24gdGhhdCBsaW1pdHMvZGlzYWJsZXMgb3BlcmF0b3JzIGFiaWxpdHkgdG8KPiA+ IGltcGFjdCBwaHkgbGV2ZWwgY29ubmVjdGl2aXR5IHRoYXQgcmVtb3RlIG1hbmFnZW1lbnQgZGVw ZW5kcyB1cG9uIGFuZCB0aGVyZWZvcmUKPiA+IHJlZHVjaW5nIHRoaXMgcmlzayBhbmQgY29zdCBm YWN0b3Igc2VlbXMgdG8gbWUgbGlrZSBhIHZlcnkgbG9naWNhbCBwYWgKPiA+IGZvcndhcmQuIFdo ZXRoZXIgb3Igbm90IHRoaXMgc2hvdWxkIGJlIGluZGljYXRlZCBpbiB0aGUgY2VydGlmaWNhdGUK PiA+IG9yIGRpZmZlcmVudGx5IGlzIGRlZmluaXRlbHkgd2lkZSBvcGVuLgo+ID4gCj4gPiBJIGFn cmVlIHRoYXQgbm9uZSBvZiB0aGVzZSBvcGVyYXRpb25hbCBpbnRlcmZhY2UgbGV2ZWwgY2hhbmdl cyBhcmUKPiA+IGEgcGllY2Ugb2YgY2FrZSBnaXZlbiBob3cgd2UgaGF2ZSBpbiB0aGUgSUVURiBu b3QgdHJpZWQgdG8gZGVmaW5lCj4gPiBkaWZmZXJlbnQgYWNjZXNzIGxldmVscyB0byBjb25maWd1 cmF0aW9uIHNvIGZhciwgYXQgbGVhc3Qgbm90Cj4gPiBiZXR3ZWVuIHNvbWUgcGh5L2luZnJhIGFj Y2VzcyBsZXZlbCBhbmQgbmV0d29yay1zZXJ2aWNlcyBhY2Nlc3MgbGV2ZWwuCj4gPiAKPiA+IEFz IHNhaWQgYWJvdmUgaW4gbXkgZmlyc3QgcmVwbHkgdGhhdCB5b3UgZGlkbid0IGNvbW1lbnQgb24s IGkgdGhpbmsgYQo+ID4gZ29vZCBwYXJ0IG9mIHdoYXQgaSBhbSBsb29raW5nIGZvciBtYXkgaGFw cGVuIHRocm91Z2ggb3RoZXIgbWVhbnMKPiA+IGFscmVhZHksIHN1Y2ggYXMgd2hlbiBhIHJvdXRl ciBpcyBqdXN0IGEgVk0gcnVubmluZyBvbiBhbiBPUy4gQXQgbGVhc3QKPiA+IGluIGVhcmx5IHZl cnNpb25zIG9mIHRoaXMgdGhhdCBpJ2Qgc2VlbiwgdGhpcyBpbXBsaWNpdGx5IGRpc2FibGVkCj4g PiB0aGUgYWJpbGl0eSB0byBtb2RpZnkgcGh5IHN0YXRlIGZyb20gdGhlIHJvdXRlciBWTSwgYW5k IG9mIGNvdXJzZQo+ID4gY29tcGxhaW50cyB3aGVyZSByYWlzZWQgdGhhdCBwaHkgbW9kcyB3aGVy ZSBuZWNlc3NhcnksIGJ1dCBhdCBsZWFzdCB0aGlzCj4gPiBldm9sdXRpb24gY291bGQgZ2l2ZSBy YWlzZSB0byBwYXVzZSBhbmQgcmV0aGluayBIT1cgdG8gcGVybWl0IGRvaW5nIHRoaXMuCj4gPiAK PiA+IFNvIGkgd291bGQgYXQgbGVhc3QgbGlrZSB0byBwbGVkZ2Ugd2l0aCB5b3UgdGhhdCBpdCBp cyBhIGdvb2QgdGhpbmcgdG8KPiA+IGhhdmUgdGhpcyB0eXBlIG9mIGRpc2N1c3Npb24gaW4gYW4g aW5mb3JtYXRpb25hbCB3YXkgaW4gdGhpcyBSRkMgaW5zdGVhZAo+ID4gb2YgZG9pbmcgbm90aGlu ZyBvciB0cnlpbmcgdG8gZ28gc3RhbmRhcmQgWUFORyBkaXJlY3RseSBhcyBhIGZpcnN0IHN0ZXAu Cj4gPiBJdCBkaWQgZ2V0IGludG8gdGhlIHNwZWMgYmVjYXVzZSBvZiB0aGUgZGVzaXJlIG9mIHRo ZSB3b3JraW5nIGdyb3VwLgo+ID4gCj4gPiA+ID4gPiBFZGl0b3JpYWwgLyBOaXRzOgo+ID4gPiAu Cj4gPiA+ID4gPsKgwqDCoMKgwqDCoCBJbiB0aGUgdmFyaW91cyBmb3JtYXRzIGluIHNlY3Rpb24g Ni4xMCwgdGhlIGxvd2VzdCBiaXQgb2YgdGhlIHVwcGVyIDY0IGJpdHMKPiA+ID4gPiA+wqDCoMKg wqDCoMKgIGlzIG1hbmRhdGVkIHRvIGJlIDAuwqAgUHJlc3VtYWJseSwgdGhlcmUgaXMgc29tZSBy ZWFzb24gZm9yIGRvaW5nIHRoaXMuwqAgSXQKPiA+ID4gPiA+wqDCoMKgwqDCoMKgIHdvdWxkIGJl IG5pY2UgdG8gZXhwbGFpbiBpdC4KPiA+ID4gPiAKPiA+ID4gPiBTb3JyeSwgbm90IGNsZWFyIHdo YXQgeW91J3JlIHJlZmVycmluZyB0by4gQ2FuIHlvdSBnaXZlIG1lIGFuCj4gPiA+ID4gZXhwbGlj aXQgcmVmZXJlbmNlID8KPiA+ID4gCj4gPiA+IEkgc2hvdWxkIGFodmUgcmVtb3ZlZCB0aGlzIG5v dGUuwqAgSXQgd2FzIGEgc2lkZS1lZmZlY3Qgb2YgdGhlIHByZXNlbnRhdGlvbgo+ID4gPiBhbmQg b3JkZXJpbmcsIG5vdCBhIHByb2JsZW0gb24gaXRzIG93bi7CoCBTb3JyeS4KPiA+IAo+ID4gQ2hl ZXJzCj4gPsKgwqDCoMKgwqAgVG9lcmxlc3MKPiA+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gQW5pbWEgbWFpbGluZyBsaXN0Cj4gQW5pbWFA aWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hCgot LSAKLS0tCnR0ZUBjcy5mYXUuZGUK ----_com.samsung.android.email_10172749362835710 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgdGhpbmsgdGhlIEkgdW5k ZXJzdGFuZCB3aGF0IHlvdSBkZXNjcmliZS4mbmJzcDsgQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRo ZSBBQ1AgRE9FUyBOT1QgQU5EIFNIT1lMRCBOT1QgTUFOREFURSBUaGUgYWRkcmVzcyBhc3NpZ25t ZW50IG1lY2hhbmlzbS4mbmJzcDsgQnV0IGl0IGlzIHRoZSBhZGRyZXNzIGFzc2lnbm1lbnQgbWVj aGFuaXNtIHRoYXQgZHJpdmVzIHRoZSBhZGRyZXNzIGFsbG9jYXRpb24uPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5BcyBzdWNoLCBpdCBzZWVtcyBsaWtlIHRoZSBBQ1AgaXRzZWxmIGRvZXMgbm90 IGNhcmUgYWJvdXQgdGhpcy4mbmJzcDsgVGhhdCBpcyx3aHkgdGhlIHJvdXRpbmcgc2NoZW1lIHNl ZW1lZCBjb25mdXNpbmcgYWZ0ZXIgdGhlIGFkZHJlc3MgYWxsb2NhdGlvbiBzY2hlbWUuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5JIHdvdWxkIGV4cGVjdCB0byBmaW5kIHRoZSBhZGRyZXNzIHN0 cnVjdHVyZSBmb3IgYXV0b25vbWljIGFkZHJlc3NlZCBpbiB0aGUgc2FtZSBkb2N1bWVudCBhcyB0 aGUgbWVjaGFuaXNtcyBmb3IgYXV0b25vbWljIGFkZHJlc3MgYXNzaWdubWVudC48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PllvdXJzLDwvZGl2PjxkaXY+Sm9lbDwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVy ZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9ImF1dG8iPlNl bnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0 cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAw JTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9y aWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFRvZXJsZXNzIEVja2VydCAm bHQ7dHRlQGNzLmZhdS5kZSZndDsgPC9kaXY+PGRpdj5EYXRlOiA1LzE0LzE4ICAwNTowNCAgKEdN VC0wNTowMCkgPC9kaXY+PGRpdj5UbzogIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBqb2VsaGFs cGVybi5jb20mZ3Q7IDwvZGl2PjxkaXY+Q2M6IHJ0Zy1kaXJAaWV0Zi5vcmcsIGRyYWZ0LWlldGYt YW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUuYWxsQGlldGYub3JnLCBpZXRmQGlldGYub3Jn LCBhbmltYUBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbQW5pbWFdIFJ0Z2RpciB0 ZWxlY2hhdCByZXZpZXcgb2YKJm5ic3A7IGRyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRy b2wtcGxhbmUtMTMgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+YSkgV2lsbCB0cnkgdG8gZG8g YmV0dGVyIGV4cGxhbmF0aW9uIG9mIGlkZW50aWZpZXIgbmF0dXJlIG9mIGFkZHJlc3NlcyBpbjxi cj4mbmJzcDsmbmJzcDsgbmV4dCBjb21taXQuPGJyPjxicj5iKSB3aGF0IGRvIHdlIGxvb3NlIGlm IGdldCByaWQgb2YgdGhlIGNob2ljZXMuIEkga2luZGEgdGhvdWdodCBpIGhhZCBhbnN3ZXJlZDxi cj4mbmJzcDsmbmJzcDsgdGhpcyBhbHJlYWR5LCBidXQgaSByZWFsbHkgZG9uJ3Qga25vdyB3aGVy ZSB5b3VyIGNvbmNlcm4gc3RhcnRzLi4uPGJyPjxicj4mbmJzcDsmbmJzcDsgMS4gV2UgdXNlIFVM QSBiZWNhdXNlIHdlIHdhbnQgdG8gYmUgYWJsZSB0byBicmluZyB1cCBBQ1AgbmV0d29ya3Mgd2l0 aG91dDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyaW5nIGEgcmVnaXN0 cnkgYWxsb2NhdGlvbiBvZiBhIHByZWZpeCwgYW5kIFVMQSBpcyB0aGUgY29ycmVjdDxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJpdmF0ZSBhZGRyZXNzIHNwYWNlLiBBbmQgZGVy aXZpbmcgVUxBIEdsb2JhbCBJRCBmcm9tIGhhc2ggb2YgZG9tYWluPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBuYW1lIGlzIG5pY2UuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU291bmRzIGFzIGlmIHlvdSBhZ3JlZSB3aXRoIHRoaXMuPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyA8YnI+Jm5ic3A7Jm5ic3A7IDIuIFdlIHdhbnQgdG8gYmUgYWJsZSB0byBhbGxv Y2F0ZSBhZGRyZXNzZXMgdG8gQUNQL0FOSSBkZXZpY2VzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB3aXRob3V0IGFueSBhZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24gZnJvbSBtdWx0 aXBsZSBpbmRlcGVuZGVudGx5PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBydW5u aW5nIHJlZ2lzdHJhcnMuIFRoYXRzIHdoeSB0aGUgZ2xvYmFsIHVuaXF1ZSBJRCBvZiB0aGUgcmVn aXN0cmFyPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyBwYXJ0IG9mIHRoZSBh ZGRyZXNzIGluIGJvdGggem9uZSBhbmQgVmxvbmcgZm9ybWF0Ljxicj48YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYXRzIHZlcnkgZnVuZGFtZW50YWwgdG8gdGhlIGVhc2Ugb2Yg ZGVwbG95bWVudCBvZiBBQ1AvQU5JIG5vZGVzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAoaSBzYXkgQU5JLCBiZWNhdXNlIGl0cyByZWFsbHkgQUNQK0JSU0tJIHJlcXVpcmVkIGhl cmUgdG8gZ2V0IGEgc2ltcGxlIHN0YW5kYXJkPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzb2x1dGlvbiB0byBjcmVhdGUgdGhlIGNlcnQsIG90aGVyd2lzZSB5b3VyZSBk b3duIHRvIGEgdmVuZG9yIHNwZWNpZmljPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBjZXJ0IHByb3Zpc2lvbmluZyBzb2x1dGlvbiBleHRlbmRlZCB3aXRoIEFDUCBpbmZv IHN1cHBvcnQpPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaSBob3BlIHRo aXMgaXMgdW5jb250ZW50dW91czxicj4mbmJzcDsmbmJzcDsgPGJyPiZuYnNwOyZuYnNwOyAzLiBh KSBXZSB3YW50ZWQgdG8gYmUgYWJsZSB0byBzdXBwb3J0IGluIHRoZSBmdXR1cmUgInpvbmUiID0g YXJlYS9yZWdpb24tbGV2ZWw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvdXRl IGFnZ3JlZ2F0aW9uLCB0aGF0cyB3aHkgdGhlIHpvbmUgc2NoZW1lIHJlc2VydmVzIHRob3NlIDEz IGJpdHMuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYikgV2UgYWxzbyBr bm93IHVzZSBjYXNlcyB3aGVyZSBub2RlcyBuZWVkIG1vcmUgdGhhbiAyIGFkZHJlc3Nlcyw8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXRzIHdoeSB3ZSBoYXZlIGhhdmUgdGhl IDgvMTYgYml0IFZsb25nIG9wdGlvbi4gPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYykgV2UgY2FuIG5vdCBkbyBldmVyeXRoaW5nIGF1dG9ub21pY2FsbHkgKD09IGFkZHJl c3NlcyBhc3NpZ25lZCBmcm9tIHJlZ2lzdHJhcnMpLDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc28gd2UgYWxzbyByZXNlcnZlIGFkZHJlc3Mgc3BhY2UgZm9yIHRyYWRpdGlvbmFs IGNvbmZpZyAobWFudWFsIGFkZHJlc3Mgc3BhY2UpLjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFyZSB0aGVzZSB0aHJlZSBzdWItc3BhY2VzIHpvbmUsbWFudWFsLHZsb25n IGNvbnRlbnVvdXMgPzxicj4mbmJzcDsmbmJzcDsgPGJyPiZuYnNwOyZuYnNwOyBBcyBtZW50aW9u ZWQgaW4gcHJpb3IgZW1haWwgaWYgaSB3YW50ZWQgdG8gYXZvaWQgdGhvc2UgY2EuIDMgYml0cyBv Zjxicj4mbmJzcDsmbmJzcDsgZm9ybWF0IGluZGljYXRpb24sIGkgd291bGQgbmVlZCB0byBpbmRp Y2F0ZSB0aGUgc2VtYW50aWMgb2YgYWRkcmVzc2VzPGJyPiZuYnNwOyZuYnNwOyBzb21laG93IGRp ZmZlcmVudGx5IHRvIHRoZSBub2RlcywgZS5nOiB2aWEgc29tZSBleHRlbnNpb24gdG8gdGhlIEFD UCBmb3JtYXQsPGJyPiZuYnNwOyZuYnNwOyBidXQgaSB3b3VsZCB3YW50IHRvIGJlIGFibGUgdG8g c2lnbmFsIHRoZSBzYW1lIGluZm9ybWF0aW9uLjxicj48YnI+Jm5ic3A7Jm5ic3A7IFNvIGZvciBl eGFtcGxlOiBiZWNhdXNlIHdlIGhhdmUgYSBzdGFuZGFyZGl6ZWQgYWRkcmVzc2luZyBzY2hlbWUs PGJyPiZuYnNwOyZuYnNwOyBhIG5vZGUgdGhhdCBhbGxvd3MgY29uZmlndXJhdGlvbiBvZiAiQUNQ IGNvbm5lY3QiIGNhbiBtYWtlIHN1cmU8YnI+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIGFkZHJlc3Mg Y29uZmlndXJlZCBvbiBhbiBBQ1AgY25uZWN0IGludGVyZmFjZSBjYW4gbmV2ZXIgYmUgYSBVTEE8 YnI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgdGhhdCB3b3VsZCBjb25mbGljdCB3aXRoIGFuIGF1dG9t YXRpYyBBQ1AgYWRkcmVzcyBhc3NpZ25tZW50IGRvbmU8YnI+Jm5ic3A7Jm5ic3A7IGJ5IGEgcmVn aXN0cmFyLiBTbyBpIHByb3RlY3QgbXkgYXV0b25vbWljIGFkZHJlc3Mgc3BhY2UgZnJvbSBtaXNj b25maWd1cmF0aW9uLjxicj4mbmJzcDsmbmJzcDsgV2hpY2ggaXMgSU1ITyBleHRyZW1lbHkgaW1w b3J0YW50LiBTbyB0aGlzIGlzIHRoZSBrZXkganVzdGlmaWNhdGlvbiBmb3I8YnI+Jm5ic3A7Jm5i c3A7IHRoZSBtYW51YWwgYWRkcmVzcyBzcGFjZSBhbGxvY2F0aW9uLiA8YnI+PGJyPiZuYnNwOyZu YnNwOyBEaXN0aW5ndWlzaGluZyBiZXR3ZWVuIHpvbmUgYW5kIFZsb25nIGFkZHJlc3Mgc3BhY2Vz IGlzIG5lY2Vzc2FyeSBiZWNhdXNlPGJyPiZuYnNwOyZuYnNwOyB3ZSBqdXN0IGNhbid0IGZpdCB6 b25lLCByZWdpc3RyYXItSUQgYW5kIG5vZGUtbnVtYmVyIGFuZCAxNiBiaXQgb2YgcGVyLW5vZGUg Yml0czxicj4mbmJzcDsmbmJzcDsgaW50byBhIHNpbmdsZSBhZGRyZXNzaW5nIHNjaGVtZS48YnI+ PGJyPiZuYnNwOyZuYnNwOyBFIHZvaWxhLCB0aHJlZSAoSU1ITzogc2ltcGxlcikgc2ltcGxlIG9w dGlvbnMuIExpa2VseSBuZXR3b3JrcyB3aWxsIHVzZSBhbGwgdGhyZWUuPGJyPiA8YnI+Q2hlZXJz PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBUb2VybGVzczxicj48YnI+T24gU3VuLCBNYXkgMTMsIDIw MTggYXQgMDc6Mzg6MzVQTSAtMDQwMCwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOjxicj4mZ3Q7IFRy aW1tZWQuPGJyPiZndDsgVG9wIHBvc3RpbmcgZm9yIGNsYXJpdHkuJm5ic3A7IE1vc3RseSwgYWdy ZWVtZW50Ljxicj4mZ3Q7IDxicj4mZ3Q7IE9uIHRoZSBpZGVudGlmaWVyIHZzIGxvY2F0b3IsIEkg dGhpbmsgdGhlIHdheSB5b3UgYXJlIHVzaW5nIHRoZSB0ZXJtcyBpczxicj4mZ3Q7IGNvbmZ1c2lu Zy4mbmJzcDsgQnV0IGl0IGlzIG5vdCB3b3J0aCBjb250aW51ZWQgYXJndW1lbnRhdGlvbi5Tb21l IHRleHQ8YnI+Jmd0OyBlbGFib3JhdGluZyBhbG9uZyB0aGUgbGluZXMgeW91IHByb3ZpZGUgKHJl dGFpbmVkIGJlbG93KSB3b3VsZCBoZWxwLjxicj4mZ3Q7PGJyPiZndDsgSSBoYXZlIHRyaWVkIHJl YWRpbmcgdGhlIHNlY3Rpb24gb24gYWRkcmVzc2luZyBpbnNpZGUgdGhlIEFDUCBtb3JlPGJyPiZn dDsgY2FyZWZ1bGx5LiZuYnNwOyBUaGFuayB5b3UgZm9yIG1vdmluZyB0aGUgWiBiaXQuPGJyPiZn dDsgSSBoYXZlIHJldGFpbmVkIHRoZSBlYXJsaWVyIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyBi ZWxvdywgaW4gY2FzZSB3ZSBzdGlsbDxicj4mZ3Q7IG5lZWQgaXQuPGJyPiZndDsgUmVhZGluZyB0 aGUgc2VjdGlvbiwgSSB0aGluayB0aGF0IHRoZSBwcm9ibGVtIGlzIG1vcmUgYmFzaWMuPGJyPiZn dDsgPGJyPiZndDsgSSBhZ3JlZSB0aGF0IHRoZSBkb2N1bWVudCBuZWVkcyB0byBkZWZpbmUgdGhh dCB3ZSBhcmUgdXNpbmcgYSBVTEEuJm5ic3A7IEFuZDxicj4mZ3Q7IGJlY2F1c2Ugb2YgdGhlIGNl cnRpZmljYXRlIGJlaGF2aW9ycywgdGhlcmUgaXMgc2lnbmlmaWNhbnQgYWR2YW50YWdlIGluPGJy PiZndDsgZGVmaW5pbmcgd2hhdCBVTEEgcHJlZml4IGlzIHVzZWQuPGJyPiZndDsgPGJyPiZndDsg R2l2ZW4gdGhhdCwgSSBkbyBub3Qgc2VlIHdoYXQgdXNlIHRoZXJlIGlzIGluIGFsbCB0aGUgb3Ro ZXIgZm9ybWF0PGJyPiZndDsgZGVmaW5pdGlvbi4mbmJzcDsgSSBzdXNwZWN0IEkgYW0gbWlzc2lu ZyBzb21ldGhpbmcgdmVyeSBiYXNpYy4mbmJzcDsgV2h5IG5vdCBsZWF2ZTxicj4mZ3Q7IHRoaXMg dG8gdGhlIGRlcGxveWluZyBvcGVyYXRvcj8mbmJzcDsgSXQgaXMgbm90IGxpa2UgaXQgY2FuIGJl IGF1dG9ub21pYywgc2luY2U8YnI+Jmd0OyBzb21ldGhpbmcgaGFzIHRvIHRlbGwgdGhlIGRldmlj ZXMgd2hhdCBmb3JtYXQgdG8gdXNlLCBhbmQgd2hhdCBudW1iZXJzPGJyPiZndDsgd2l0aGluIHNv bWUgb2YgdGhlIGZvcm1hdHMgdG8gdXNlLiZuYnNwOyBJIGNvdWxkIGltYWdpbmUgc29tZXRoaW5n IHRoYXQgc2FpZCAiaW48YnI+Jmd0OyB0aGUgYWJzZW5jZSBvZiBjb25maWd1cmF0aW9uLCBjb25z dHJ1Y3QgZGV2aWNlIGFkZHJlc3NlcyBhY2NvcmRpbmcgdG8gb25lPGJyPiZndDsgc3BlY2lmaWMg YWxnb3JpdGhtLCBzbyBhcyB0byBzaW1wbGlmeSBib290c3RyYXAuPGJyPiZndDsgQnV0IGl0IHdv dWxkIGJlIGEgc2ltcGxlIHNjaGVtZS48YnI+Jmd0Ozxicj4mZ3Q7IDxicj4mZ3Q7IE9uIDUvMTEv MTggMTA6MDkgUE0sIFRvZXJsZXNzIEVja2VydCB3cm90ZTo8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgRGlmZjo8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgaHR0cDovL3Rvb2xzLmlldGYu b3JnL3Rvb2xzL3JmY2RpZmYvcmZjZGlmZi5weWh0P3VybDE9aHR0cHM6Ly9yYXcuZ2l0aHVidXNl cmNvbnRlbnQuY29tL2FuaW1hLXdnL2F1dG9ub21pYy1jb250cm9sLXBsYW5lLzJhZThmNDczOTlh ZTBkMDgxMWNiNDUyMDkxODZkMDFmOWUwZDMwNzcvZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMt Y29udHJvbC1wbGFuZS9kcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTE0 LnR4dCZhbXA7dXJsMj1odHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vYW5pbWEtd2cv YXV0b25vbWljLWNvbnRyb2wtcGxhbmUvNTRjOWMxNmYzNDQ0YjFkYjEzYzdjYjA1NzQ0ZTU0M2Rm Y2RmYjYzYi9kcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lL2RyYWZ0LWll dGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMTQudHh0PGJyPiZndDsgJmd0OyA8YnI+ Jmd0OyAmZ3Q7IExhdGVzdCB2ZXJzaW9uOjxicj4mZ3Q7ICZndDsgaHR0cHM6Ly9yYXcuZ2l0aHVi dXNlcmNvbnRlbnQuY29tL2FuaW1hLXdnL2F1dG9ub21pYy1jb250cm9sLXBsYW5lLzU0YzljMTZm MzQ0NGIxZGIxM2M3Y2IwNTc0NGU1NDNkZmNkZmI2M2IvZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9t aWMtY29udHJvbC1wbGFuZS9kcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5l LTE0LnR4dDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgLi4uLjxicj4mZ3Q7ICZndDsgSGVyZSBhcmUg dGhlIHRoaW5ncyB0aGF0IG1ha2UgdGhlIEFDUCBhZGRyZXNzIGFuIGlkZW50aWZpZXIgdG8gbWU6 PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IC0gSXQgaXMgYXNzaWduZWQgb25jZSB0byB0aGUg ZGV2aWNlIGFuZCBub3QgbWVhbnQgdG8gY2hhbmdlIG92ZXIgdGhlIGxpZmV0aW1lPGJyPiZndDsg Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvZiB0aGUgZGV2aWNlLjxicj4mZ3Q7ICZndDsgLSBJdCBk b2VzIG5vdCBjaGFuZ2Ugd2hlbiBpIG1vdmUgdGhlIG5vZGUgdG8gYSBkaWZmZXJlbnQgbG9jYXRp b248YnI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCByZS1jb25uZWN0IHRoZSBkZXZp Y2UuPGJyPiZndDsgJmd0OyAtIEl0IGlzIHRoZSB1bmlxdWUgcGFydCBvZiB0aGUgQUNQIGRvbWFp biBjZXJ0aWZpY2F0ZSAob3RoZXIgdGhhbiB0aGUgcHJpdmF0ZSBrZXkpPGJyPiZndDsgJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBhbmQgdXNlZCB0byBpZGVudGlmeSB0aGUgZGV2aWNlIChwcml2YXQg a2V5IGlzIHVzZWQgdG8gYXV0aGVudGljYXRlIGl0LDxicj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsgYnV0IHRoZSBwcml2YXRlIGtleSBtYXkgY2hhbmdlIG92ZXIgdGltZSwgZm9yIGV4YW1w bGUgd2hlbiByZW5ld2luZyB0aGUgY2VydGlmaWNhdGUpLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsg Jmd0OyBXb3VsZCBiZSBoYXBweSB0byBlbGFib3JhdGUgdGhpcyBpbiB0aGUgZG9jIG1vcmUgZXhw bGljaXRseSwgZS5nLjogbGlrZSB3cml0dGVuPGJyPiZndDsgJmd0OyBhYm92ZS48YnI+Jmd0OyA8 YnI+Jmd0OyAoQ29udGV4dDogQWRkcmVzc2luZyBpbnNpZGUgdGhlIEFDUC4pPGJyPiZndDsgJmd0 OyAmZ3Q7IFBhcnQgb2YgbXkgcmVhY3Rpb24gdG8gdGhpcyB3aG9sZSBzZWN0aW9uIGlzIHRoYXQg aXQgbG9va3MgbXVjaCBsaWtlIHRoZTxicj4mZ3Q7ICZndDsgJmd0OyBtaXN0YWtlIHdlIG1hZGUg b3JpZ2luYWxseSBpbiBkZWZpbmluZyBjbGFzc2Z1bCBJUCBhZGRyZXNzZXMuJm5ic3A7IFlvdSBh cmU8YnI+Jmd0OyAmZ3Q7ICZndDsgdHJ5aW5nIHRvIGd1ZXNzIHRoZSBjb3JyZWN0IHVzZSBjYXNl cywgYW5kIGRlZmluaW5nIHNwZWNpZmljIGFkZHJlc3M8YnI+Jmd0OyAmZ3Q7ICZndDsgc3RydWN0 dXJlcyB3aXRoIHNwZWNpZmljIGVuY29kaW5ncyBmb3IgZWFjaCBvbmUuJm5ic3A7IFdpdGggb25s eSBhIGZldyBlbmNvZGluZ3M8YnI+Jmd0OyAmZ3Q7ICZndDsgYXZhaWxhYmxlLiZuYnNwOyBUaGlz IHNlZW1zIHRvIGJlIGEgcmVjaXBlIGZvciBiZWluZyB3cm9uZyBsYXRlciBpbiB3YXlzIHRoYXQ8 YnI+Jmd0OyAmZ3Q7ICZndDsgaHVydC48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgVGhlIG9u bHkgZXF1aXZhbGVudCB0byBjbGFzc2Z1bGwgYWRkcmVzc2luZyBpIHNlZSBpcyBmb3IgdGhlIGZp eGVkIHByZWZpeC1sZW5ndGg8YnI+Jmd0OyAmZ3Q7IGhhbmRlZCBvdXQgdG8gZWFjaCBub2RlLCAx IGJpdCAoMiBhZGRyZXNzZXMpIHdpdGggem9uZSBhZGRyZXNzZXMsIDgvMTYgYml0czxicj4mZ3Q7 ICZndDsgKDI1Ni82NGsgYWRkcmVzcykgZm9yIFZsb25nLCBidXQgaXRzIE5PVCBhc3NpZ25tZW50 IHRvIG5ldHdvcmsgc2VnbWVudHM8YnI+Jmd0OyAmZ3Q7IGFzIGluIElQdjQgQS9CL0MgYnV0IHRv IG5vZGVzLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBXZSBkaWRuJ3QgaW50cm9kdWNlIGNo b2ljZXMgbGlnaHRseS4gVGhlcmUgYXJlIGNvbXByb21pc2VzIHRvIGJlIG1hZGUgd2hlbiB5b3U8 YnI+Jmd0OyAmZ3Q7IHdhbnQgc29tZSBsaWdodHdlaWdodCBhZGRyZXNzIGFsbG9jYXRpb24gc2No ZW1lLCBub3QgZXhwZWN0aW5nIHRvIGhhdmUgY29tcGxleDxicj4mZ3Q7ICZndDsgYWRkcmVzcyBy ZWdpc3RyeSBvciBtYW5hZ2VtZW50IHN5c3RlbSBpbiB0aGUgYmFja2VuZCBidXQgc2ltcGxlIHJl Z2lzdHJhcnMuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IHNlZSBiZWxvdyBmb3IgbW9yZTxi cj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGRpZmZlcmVuY2UgaW4gaW50ZXJwcmV0YXRp b248YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGlzIGFjdHVhbGx5IHByb3ZpZGVkIGJ5IHRoZSBsYXN0IGJpdCBpbiB0aGUgdXBw ZXIgNjQuJm5ic3A7IElmIHRoZXNlIGFyZSB0aGU8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNhbWUgc2NoZW1hLCB0aGVuIGl0 IHNob3VsZCBub3QgbmVlZCBhIGJpdCB0byBkaWZmZXJlbnRpYXRlIHRoZW0uJm5ic3A7IFRoZXk8 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNob3VsZCBiZSBleHBsYWluZWQgYXMgYSBzaW5nbGUgc2NoZW1hLiZuYnNwOyBXaGlj aCB3b3VsZCBwcmVzdW1hYmx5IHJlc3VsdCBpbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIFogYml0IGJlaW5nIHBhcnQg b2YgdGhlIHpvbmUgLyBzdWJuZXQgZmllbGQuJm5ic3A7Jm5ic3A7IElmIHRoZXkgYXJlIHR3bzxi cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGlmZmVyZW50IHNjaGVtYXMsIHRoZW4gbW92ZSB0aGUgZGlmZmVyZW50aWF0aW9uIHRv IHBhcnQgb2YgdGhlIHNjaGVtYTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpZmllciAobWFraW5nIGl0IDMgYml0cyku PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgV2UgZGlkIG5v dCB3YW50IHRvIG1ha2UgWiBwYXJ0IG9mIHRoZSBiYXNlIHNjaGVtYXMgNi4xMC4yICJUeXBlIiBj b2RlIGJlY2F1c2U8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGF0IHdvdWxkIGFsc28gbWFrZSB0 aGUgVmxvbmcgc2NoZW1lIG9uZSBiaXQgc2hvcnRlciBhbmQgdGhhdCB3b3VsZCByZWR1Y2U8YnI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyB2aXJ0dWFsaXphdGlvbiBzcGFjZSBpbiBWbG9uZyBieSBhIGZh Y3RvciBvZiAyLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFNvLCB5ZXMsIGVuY29kaW5nIHdpc2UsIDYuMTAuNCBtYW51YWwgc3ViIGFkZHJlc3Npbmcgc3Bh Y2Ugd2FzIGNhcnZlZCBvdXQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBvZiB0aGUgNi4xMC4zIHpv bmUgYWRkcmVzcyBzcGFjZSB2aWEgdGhlIFogYml0LCBidXQgdGhhdHMganVzdCBhbiBlbmNvZGlu ZyBhc3BlY3QuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg RnVuY3Rpb25hbGx5LCA2LjEwLjMvNi4xMC40IGFyZSBxdWl0ZSBkaWZmZXJlbnQsIGFuZCB0aGVy ZWZvcmUgaXQgaXMgSU1ITzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRleHR1YWxseSBjb3JyZWN0 IHRvIGhhdmUgdGhlbSBpbiBkaWZmZXJlbnQgc3Vic2VjdGlvbnMuPGJyPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2FydmluZyBvdXQgYml0cyBsaWtlIFogaXNu J3QgaWRlYWwsIGJ1dCBpbiBiZXR3ZWVuIHRoZSBVTEEgcHJlZml4LDxicj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IHRoZSA2NCBiaXQgbG9jYWwgcGFydCB3ZSBtdXN0IGhhdmUgZm9yIGV4dGVybmFsIGlu dGVyZmFjZXMgYW5kPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgYmVzdCB1dGlsaXphdGlvbiBvZiBi aXRzLCB3ZSB0cmllZCB0byByYXRoZXIgb3B0aW1pemUgYWRkcmVzcyBzcGFjZTxicj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHV0aWxpemF0aW9uIGFuZCBub3QgYmVhdXR5IG9mIGVuY29kaW5nLjxicj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhhdmluZyZuYnNwOyBh dCB0aGUgZW5kIGFsbG93cyAoYXMgd3JpdHRlbikgdXNlIG9mIC82MyBpbnN0ZWFkIG9mJm5ic3A7 IDIgKiAvNjQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyByb3V0ZXMuIEkgYW0gbm90IHN1cmUgaG93 IGltcG9ydGFudCB0aGlzIHdvdWxkIGJlIGluIHRoZSBmdXR1cmUuPGJyPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYgeW91IGZlZWwgc3Ryb25nbHkgYWJvdXQg bW9yZSBiZWF1dHkgaW4gZW5jb2RpbmcsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgaSBjYW4gbW92 ZSBaIHRvIHRoZSBsZWZ0IGFuZCByZW1vdmUgdGhlIG5vdGlvbiBvZiB0aGUgcG9zc2libGUgLzYz IHJvdXRlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgb3B0aW1pemF0aW9uIHBvc3NpYmxlIHRocm91 Z2ggdGhlIHBsYWNlbWVudCBvZiBaLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZn dDsgU2luY2UgdGhlIHR3byBkaWZmZXJlbnQgdXNlcyBvZiB0aGUgWiBiaXQgd2l0aCB0eXBlIDAw YiBhcmUgcXVpdGUgZGlzdGluY3QsPGJyPiZndDsgJmd0OyAmZ3Q7IHRyeWluZyB0byBlbmFibGUg YWdncmVnYXRpb24gc2VlbXMgY291bnRlci1wcm9kdWN0aXZlLjxicj4mZ3Q7ICZndDsgJmd0OyA8 YnI+Jmd0OyAmZ3Q7ICZndDsgV2hpbGUgSSBoYXRlIHRvIHB1c2ggb24gYSBwb2ludCB5b3UgZGVz Y3JpYmUgYXMgYWVzdGhldGljcywgaGF2aW5nIHRoZSBaPGJyPiZndDsgJmd0OyAmZ3Q7IGJpdCwg b2NjdXJpbmcgYWZ0ZXIgdGhlIFpvbmUgLyBzdWJuZXQtSUQgZmllbGQsIGJ1dCBkZWZpbmluZyB3 aGV0aGVyIHRoZTxicj4mZ3Q7ICZndDsgJmd0OyBmaWVsZCBpcyBhIHpvbmUgb3IgYSBzdWJuZXQs IHNlZW1zIGF3a3dhcmQgZm9yIGluc3VmZmljaWVudCByZWFzb24uPGJyPiZndDsgJmd0OyAmZ3Q7 IDxicj4mZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIHJlY29tbWVuZCBtb3ZpbmcgdGhlIFogYml0IHVw IHNvIGl0IGlzIGFmdGVyIHRoZSB0eXBlLCBhbmQgYXQgdGhlPGJyPiZndDsgJmd0OyAmZ3Q7IGZy b250IG9mIGVhY2ggb2YgdGhlIHR3byBzZWN0aW9ucyByZWl0ZXJhdGUgdGhhdCB0aGlzIHN1YnNj aGVtZSBpcyBpbmRpY2F0ZWQ8YnI+Jmd0OyAmZ3Q7ICZndDsgYnkgdGhlIFogYml0IGJlaW5nIHsg MCB8IDEgfS48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgRG9uZS4gKHNlZSBkaWZmKS48YnI+ Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgdmVyeSBtdWNoIGhvcGUgdGhlcmUg aXMgbm8gImludGVyZXN0aW5nIiBpbXBsZW1lbnRhdGlvbiBhc3BlY3Q7PGJyPiZndDsgJmd0OyAm Z3Q7ICZndDsgbm90aGluZyBpbiB0aGUgY3VycmVudCBzY2hlbWUgdGhhdCBtYWtlcyBpbXBsZW1l bmF0aW9uIGhhcmRlci4gSWYgeW91PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgaGF2ZSBhbiBleGFt cGxlIHRoYXQgeW91IGZlYXIsIGkgd291bGQgbGlrZSB0byBoZWFyIGl0Ljxicj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvIG1lLCB3ZSBhcmUganVzdCBkZWZp bmluZyBhZGRyZXNzIHNwYWNlIGFsbG9jYXRpb24gc2NoZW1lcy48YnI+Jmd0OyAmZ3Q7ICZndDsg PGJyPiZndDsgJmd0OyAmZ3Q7IEkgc3VwcG9zZSBsaWtlbHkgaW1wbGVtZW50YXRpb25zIHdpbGwg dXNlIG1hc2sgZGVmaW5pdGlvbnMgdGhhdCB3aWxsIG1ha2UgaXQ8YnI+Jmd0OyAmZ3Q7ICZndDsg d29yay4mbmJzcDsgSSBwaXR5IHRoZSBjb2RlIHJldmlld2VyLjxicj4mZ3Q7ICZndDsgPGJyPiZn dDsgJmd0OyBJIGhhdmUgcmVhZCB0aGUgY29kZSBhbmQgdGVzdGVkIGluIHRoZSBsYWIgSVB2NiBl bWJlZGRlZCBSUCBhZHJlc3Npbmc8YnI+Jmd0OyAmZ3Q7IGFuZCBkaWRuJ3QgZmVlbCBwaXR5ZnVs bCBhYm91dCB0aGUgam9iLiBCdXQgaSB3ZWlnaCB0aGUgb3ZlcmFsbCBzeXN0ZW08YnI+Jmd0OyAm Z3Q7IGNvbXBsZXhpdHkuIEVtYmVkZGVkLVJQIHNpbXBsaWZpZWQgYSBsb3Qgb2Ygb3RoZXIgcGFy dHMgb2YgdGhlPGJyPiZndDsgJmd0OyBtdWx0aWNhc3Qgc3lzdGVtIGF0IHRoZSBjb3N0IG9mIGlu dHJvZHVjaW5nIGFuIGFkZHJlc3Npbmcgc2NoZW1lLjxicj4mZ3Q7ICZndDsgSSB0aGluayBzaW1p bGFyaWx5LCB0aGUgQUNQIGFkZHJlc3Npbmcgc2NoZW1lIHNpbXBsaWZpZXMgdGhlIG92ZXJhbGwg c3lzdGVtPGJyPiZndDsgJmd0OyBjb21wbGV4aXR5LCBlc3BlY2lhbGx5IHJlZ2lzdHJhcnMuPGJy PiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIHNlY3Rpb24gNi4xMC41LCBhZnRlciBzdGF0aW5nIHRoYXQg aXQgaXMgbm90IGV2ZW4ga25vd24gd2hhdCB0aGUgbmVlZGVkPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2FnZSBpcyBmb3Ig bW9yZSBWIHZhbHVlczxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IFdoaWNoIHNlbnRlbmNlIGFyZSB5b3UgcmVmZXJyaW5nIHRvIHdoZW4geW91IHNheSAibm90 IGV2ZW4ga25vd24gd2hhdCB0aGU8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBuZWVkZWQgdXNhZ2Ug aXMiID8gSSBjYW4ndCBmaW5kIGl0LCBidXQgaSB3b3VsZCBsaWtlIHRvIHJlY3RpZnkgaXQ8YnI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpZiBpdCBhY3R1YWxseSBpcyBzdGlsbCB0aGVyZS48YnI+Jmd0 OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFRoZSB0ZXh0IHJlYWRzICJmdXJ0aGVyIHZh bHVlcyB1c2UgdmlhIGRlZmluaXRpb24gaW4gZnV0dXJlIHdvcmsuIiZuYnNwOyBJbiB0aGU8YnI+ Jmd0OyAmZ3Q7ICZndDsgem9uZS1pZCBzY2hlbWUsIGl0IGlzIG9uZSBiaXQuJm5ic3A7IEZvciBz b21lIHJlYXNvbiwgaXQgaXMgOCBvciAxNiBiaXRzIGhlcmUuPGJyPiZndDsgJmd0OyA8YnI+Jmd0 OyAmZ3Q7IFRoYW5rcywgY2hhbmdlZCBzZW50ZW5jZSB0bzo8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgVjogVmlydHVhbGl6YXRpb24gYml0OiBWYWx1ZXMgMCBhbmQgMSBhcmUgYXNzaWduZWQg aW4gdGhlIHNhbWUgd2F5IGFzIGluIHRoZSBab25lLUlEIHN1Yi1zY2hlbWUuPGJyPiZndDsgJmd0 OyA8YnI+Jmd0OyAmZ3Q7IFRoZSBleGlzdGluZyB0ZXh0LCBub3cgZGlyZWN0bHkgYWZ0ZXIgdGhl IGxpc3QsIGV4cGxhaW5zIGV4YW1wbGVzPGJyPiZndDsgJmd0OyB3aGVuIGEgZGV2aWNlIHdvdWxk IGxpa2VseSBuZWVkIDI1NiBvciA2NGsgYWRkcmVzc2VzOjxicj4mZ3Q7ICZndDsgPGJyPiZndDsg Jmd0OyBleGlzdGluZyB0ZXh0Ojxicj4mZ3Q7ICZndDsgLi4uIjEiIGJpdCBOb2RlLU51bWJlcnMg YXJlIGludGVuZGVkIGZvciBBQ1Agbm9kZXMgdGhhdCBhcmUgQUNQIGVkZ2Ugbm9kZXMgLi4uPGJy PiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBkb2N1bWVudCBnb2VzIG9uIHRvIGludHJvZHVjZSB0aGU8 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGNvbXBsZXhpdHkgb2YgY2xhc3NmdWwgbm9kZXMgbnVtYmVycywgd2l0aCB0aGUgbGVh ZGluZyBiaXQgaW5kaWNhdGluZyBob3c8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxvbmcgdGhlIG5vZGUtbnVtYmVyIGlzLiZu YnNwOyBZZXMsIHRoZSByZXN0IG9mIHRoZSB0ZXh0IGluIHRoYXQgYnVsbGV0IHRyaWVzIHRvPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBleHBsYWluIHdoeSB5b3UgbmVlZCBib3RoIHNpemVzLiZuYnNwOyBJdCBzZWVtcyBsaWtl IG5lZWRsZXNzIGNvbXBsZXhpdHkgdGhhdDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmVncyBmb3IgbWlzdGFrZXMgaW4gaW1w bGVtZW50YXRpb24uPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgSSB3YXMgdGFraW5nIHRoZSBleGFtcGxlIHVzZSBjYXNlcyB3ZSBicmFpbnN0b3JtZWQgaW50 byBhY2NvdW50LCBhbmQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBzb21lIG9mIHRoZW0mbmJzcDsg d291bGQgcmVxdWlyZSBhIGxvdCBtb3JlIGFkZHJlc3NlcyBpbiB0aGUgbm9kZSB0aGFuIG90aGVy cyw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGVyZWZvcmUgdGhlc2UgdHdvIGNob2ljZXMuPGJy PiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBTZWUgbXkgY29tbWVudHMgYWJvdmUu Jm5ic3A7IFRyeWluZyB0byBlbmNvZGUgc3BlY2lmaWMgdXNlIGNhc2VzIGludG8gdGhlIGFkZHJl c3M8YnI+Jmd0OyAmZ3Q7ICZndDsgZm9ybWF0IHNlZW1zIGEgcHJvYmxlbWF0aWMgYW5zd2VyIHRv IGFuIGFkbWl0dGVkbHkgZGlmZmljdWx0IHF1ZXN0aW9uLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+ Jmd0OyAmZ3Q7ICZndDsgV2hhdCB3b3VsZCBicmVhayBpZiB5b3UgZGlkbid0IGRlZmluZSBhbnkg b2YgdGhpcz88YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgT25lIGNvdWxkIHNhdmUgdGhlIDIu NSBiaXRzIChUeXBlLCBaKSBpbmRpY2F0aW5nIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlPGJyPiZndDsg Jmd0OyBhZGRyZXNzIGluc2lkZSB0aGUgYWRkcmVzcyBieSBlbmNvZGluZyB0aGUgZGVzaWduYXRl ZCBmb3JtYXQgb2YgdGhlPGJyPiZndDsgJmd0OyBhZGRyZXNzIGluc3RlYWQgaW4gYW4gZXh0ZW5z aW9uIGZpZWxkIG9mIHRoZSBBQ1AgYWRkcmVzcyBpbmZvcm1hdGlvbiBpbjxicj4mZ3Q7ICZndDsg dGhlIGNlcnRpZmljYXRlLiBXZSB3b3VsZCBjZXJ0YWlubHkgc3RpbGwgd2FudCB0byBoYXZlIHRo ZSBzYW1lIHR5cGU8YnI+Jmd0OyAmZ3Q7IG9mIGFkZHJlc3NlcywgZS5nLjogMiwyNTYsNjRrIGxv Y2FsIGFkZHJlc3Nlcywgb3B0aW9uIGZvciB6b25lcyBhbmQ8YnI+Jmd0OyAmZ3Q7IGFkZHJlc3Mg dG8gYXNzaWduIHRvIEFDUCBjb25uZWN0IGludGVyZmFjZXMgKG1hbnVhbCBhZGRyZXNzaW5nIHNj aGVtZSk8YnI+Jmd0OyAmZ3Q7IElNSE8uIFNvLCBhdCBiZXN0IHdlIGNvdWxkIHNhdmUgdGhlIDIu NSBiaXRzIGlmIHdlIHdhbnRlZCB0byBrZWVwIHRoZTxicj4mZ3Q7ICZndDsgZnVuY3Rpb25hbGl0 eSwgd2hpY2ggaSB0aGluayBpcyBhbGwgcmVxdWlyZWQuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAm Z3Q7IEkgd291bGQgYmUgcXVpdGUgYWZyYWlkIG9mIGRvaW5nIHN1Y2ggYSBkcmFzdGljIGNoYW5n ZSB0aGlzIGxhdGUgaW48YnI+Jmd0OyAmZ3Q7IHRoZSBwcm9jZXNzIGJlY2F1c2UgaSB0aGluayBp dCB3aWxsIHRha2UgYSBsb25nIHRpbWUgdG8gZm9yZXNlZSB0aGU8YnI+Jmd0OyAmZ3Q7IHJlc3Vs dGluZyBjb21wbGV4aXR5IGludHJvZHVjZWQgZm9yIHJlZ2lzdGFycyBhbmQgYW55IG90aGVyIHBs YWNlPGJyPiZndDsgJmd0OyB0aGF0IG5vdyBjYW4gZGVkdWN0IHRoZSBzZW1hbnRpYyBmcm9tIHRo ZSBhZGRyZXNzIGFuZCB3b3VsZCB0aGVuIGhhdmU8YnI+Jmd0OyAmZ3Q7IHRvIGFjY2VzcyB0byB3 aGF0IHRoZSBjZXJ0aWZpY2F0ZSBpbmRpY2F0ZXMgaW4gYSBkaWZmZXJlbnQgd2F5IChlLmcuOjxi cj4mZ3Q7ICZndDsgYWNjZXNzIHRvIHRoZSBjZXJ0aWZpY2F0ZSkuIE5vdGUgdGhhdCB0aGUgbGVu Z3RoIG9mIHRoZSBBQ1AgaW5mb3JtYXRpb248YnI+Jmd0OyAmZ3Q7IGZpZWxkIGluIHRoZSBjZXJ0 IGlzIGFsc28gbGltaXRlZCwgc28gdGhpcyB0eXBlIG9mIGV4dGVuc2lvbiBtaWdodCBlbmQ8YnI+ Jmd0OyAmZ3Q7IHVwIGxvb2tpbmcgZXZlbiB1Z2xpZXIgdG8gYmUgc2hvcnQgKnNpZ2gqLjxicj4m Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyBJIHdhcyBhbHdheXMgdGhpbmtpbmcgdGhhdCB0aGlzIHR5 cGUgb2YgbW9yZSBmbGV4aWJsZSBvcHRpb24gd291bGQ8YnI+Jmd0OyAmZ3Q7IGJlIGEgZ29vZCBu ZXh0LXN0ZXAsIGJ1dCBub3QgYSBzYWZlIGZpcnN0IHN0ZXAuIEl0IHdvdWxkIG1ha2UgYSBsb3Q8 YnI+Jmd0OyAmZ3Q7IG1vcmUgc2Vuc2UgYWZ0ZXIgaGVhcmluZyBpbXBsZW1lbnRhdGlvbi9kZXBs b3ltZW50IGV4cGVyaWVuY2VzLDxicj4mZ3Q7ICZndDsgZXNwZWNpYWxseSB0byBjb3JyZWN0bHkg c3VwcG9ydCBpbXBvcnRhbnQgb3B0aW9ucyB3ZSBtYXkgaGF2ZTxicj4mZ3Q7ICZndDsgb3Zlcmxv b2tlZCBpbiB0aGUgY3VycmVudCBzY2hlbWVzLiBKdXN0IHJlZG9pbmcgd2hhdCB3ZSBoYXZlIGRp ZmZlcmVudGx5PGJyPiZndDsgJmd0OyB0byBzYXZlIDIuNSBiaXRzIGlzbid0IHdvcnRoIGl0IElN SE8uPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBVbHRpbWF0ZWx5LCB3ZSBu ZWVkIHRvIGJyZWFrIHRocm91Z2ggdGhlIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVtPGJyPiZndDsg Jmd0OyAmZ3Q7ICZndDsgb2YgaG93IHRvIGJ1aWxkIG1vcmUgc2VsZi1tYW5hZ2luZyBuZXR3b3Jr cy4gVGhlc2Ugd2lsbCByZXF1aXJlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgYSBkaWZmZXJlbnQg bnVtYmVyIG9mIGFkZHJlc3NlcyBpbnNpZGUgbm9kZXMuIEFueXRoaW5nIG1vcmUgaW50ZWxsaWdl bnQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGFuIGFkZHJlc3Mgc3BhY2UgYWxsb2NhdGlvbnMg d291bGQgYmVjb21lIGEgY29tcGxleCBkZXBlbmRlbmN5PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg bWFraW5nIGltcGxlbWVudGF0aW9uL2Fkb3B0aW9uIGV2ZW4gc2xvd2VyLiBJIGRvbid0IHRoaW5r IHRoYXQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBvZmZlcmluZyAyLCAyNTYsIDY0ayBhZGRyZXNz ZXMgcGVyIG5vZGUgaXMgdG9vIG11Y2ggZmxleGliaWxpdHkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgSXQgSU1ITyBuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQgdG8gZXhwbG9yZSBhbmQgd2UnbGwg c2VlIHdoYXQgc3RpY2tzLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgVmFy aWF0aW9uIGlzIG5lZWRlZC4mbmJzcDsgVGhhdCB3YXMgdHJ1ZSBvZiBhbGxvY2F0aW9ucyBpbiBJ UC4mbmJzcDsgZW5jb2RpbmcgdGhlPGJyPiZndDsgJmd0OyAmZ3Q7IHZhcmlhdGlvbnMgcHJvdmVk IGEgYmFkIGNob2ljZS48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgTGV0IG1lIHJlcGVhdCB0 aGF0IHdlIGFyZSBub3QgZG9pbmcgYW55IG5ldHdvcmsvc3VibmV0IHByZWZpeCBlbmNvZGluZyB3 aGljaCBpczxicj4mZ3Q7ICZndDsgd2hhdCBJUHY0IEEvQi9DIHdhcy4gQW5kIHRoZXJlIGFyZSBJ TUhPIGdvb2QgZXhhbXBsZXMgaG93IGVuY29kaW5nIGluIElQdjY8YnI+Jmd0OyAmZ3Q7IGRpZCBz YXZlIHRoZSBkYXkgZnJvbSBjb21wbGV4aXR5IChhdCBsZWFzdCBhbGwgdGhlIHN0dWZmIGRvbmUg Zm9yIElQdjY8YnI+Jmd0OyAmZ3Q7IG11bHRpY2FzdCwgQVNNL1NTTSwgem9uZXMsIEVtYmVkZGVk LVJQKSB3YXMgaGlnaGx5IHVzZWZ1bC48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gc2VjdGlvbiA2 LjExLjEuMTEgaW4gZGVzY3JpYmluZyB0aGUgcHJlZml4IGxlbmd0aHMsIEkgdGhvdWdodCB0aGF0 IHRoZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcG9pbnQgb2Ygem9uZSBhZGRyZXNzaW5nIHdhcyB0byBhbGxvdyB0aGUgdXNl IG9mIC82NCBwcmVmaXhlcy4mbmJzcDsgQnV0IGl0PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZWVtcyBoZXJlIHRoYXQgd2Ug d2lsbCBub3QgZG8gc28gPzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEFzIG1lbnRpb25lZCBhYm92ZTogVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZXNjcmli ZSB0aGUgcm91dGluZyBzZXR1cCBmb3IgLzY0PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgKG9yIC82 MyB3aXRoIFotYml0KSByb3V0aW5nIGFnZ3JlZ2F0aW9uLiBUaGVyZSBhcmUgbXVsdGlwbGUgb3B0 aW9ucyw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBidXQgd2UgY291bGQgbm90IGNvbmNsdWRlIG9u IGEgc2luZ2xlIHNvbHV0aW9uIHRoYXQgd2UgZmVsdCB0byBiZTxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IGFwcHJvcHJpYXRlIGZvciB0aGlzIGRvY3VtZW50LiBJbnN0ZWFkIGl0IHdhcyBvbmx5IHZl cnkgaW1wb3J0YW50PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgdG8gY2FydmUgb3V0IGFkZHJlc3Np bmcgc3BhY2UgdG8gc3VwcG9ydCB0aGlzLjxicj4mZ3Q7ICZndDsgJmd0OyBUaGUgbmV0IGVmZmVj dCBzZWVtcyB0byBiZSB0byBwcm9oaWJ0IHRoZSB2ZXJ5IHRoaW5ncyB0aGF0IHlvdSB3ZW50IHRv IGEgbG90PGJyPiZndDsgJmd0OyAmZ3Q7IG9mIHRyb3VibGUgdG8gZW5hYmxlIGluIHlvdXIgYWRk cmVzc2luZyBkZXNpZ24uPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IE1heWJlIGkgZG8gbm90 IHVuZGVyc3RhbmQgeW91ciBjb21tZW50IGNvcnJlY3RseSwgYnV0IGkgZG8gbm90PGJyPiZndDsg Jmd0OyB0aGluayBpdCBpcyBjb3JyZWN0LiBXZSBqdXN0IGhhdmUgbm90IGRlZmluZWQgcmVjb21t ZW5kZWQgbWVjaGFuaXNtczxicj4mZ3Q7ICZndDsgaG93IHRvIHNldCB1cCByb3V0aW5nIHRvIHVz ZSAvNjQgem9uZSByb3V0ZXMuIFRoYXQgaXMgc29tZXRoaW5nIElNSE88YnI+Jmd0OyAmZ3Q7IGJl dHRlciBkb25lIGluIGEgZm9sbG93dXAgZG9jdW1lbnQgYmVjYXVzZSBhbGwgdGhlIGNhc2VzIHdo ZXJlIHdlPGJyPiZndDsgJmd0OyBkaWQgc2VlIGEgbmVlZCBmb3Igem5lcyB3aGVyZSByZWFsbHkg dmVyeSBzcGVjaWZpYyB0byBwYXJ0aWN1bGFyPGJyPiZndDsgJmd0OyBkZXBsb3ltZW50IHN0eWxl cyBhbmQgd291bGQgbm90IGJlIGFwcGxpY2FibGUgdG8gdGhlIG1heW9yaXR5IG9mIEFDUHMuPGJy PiZndDsgJmd0OyBOZXZlcnRoZWxlc3MsIHdlIGZlbHQgdGhvc2UgY2FzZXMgd2hlcmUgaW1wb3J0 YW50IGVub3VnaCB0byByZXNlcnZlPGJyPiZndDsgJmd0OyBiaXRzIGZvciB0aGVtIHRocm91Z2gg dGhlIHpvbmUgZmllbGQuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgLi4uPGJyPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqKiombmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiAxMC4z LjIgcGFyYWdyYXBoIDIgc2F5cyB0aGF0IGRldmljZXMgc2hvdWxkIGNoYW5nZSB0aGUgbWVhbmlu Zzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgb2YgImFkbWluIGRvd24iIHRvIG1lYW4gImRv d24gZm9yIGV2ZXJ5dGhpbmcgZXhjZXB0IEFDUCAvIEFuaW1hIi4mbmJzcDsmbmJzcDsmbmJzcDsg SSBjYW48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHVuZGVyc3RhbmQgd2h5LCBpbiBhbiBh dXRvbm9taWMgbmV0d29yaywgc3VjaCBhIHN0YXRlIGlzIGRlc2lyYWJsZS4mbmJzcDsgSG93ZXZl ciw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoYXQgcmVhbGx5IHNob3VsZCBiZSBhIGRp ZmZlcmVudCBzdGF0ZSBmcm9tICJhZG1pbiBkb3duIi4mbmJzcDsgT3BlcmF0b3JzIGFscmVhZHk8 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHVuZGVyc3RhbmQgImFkbWluIGRvd24iIGFzIG1l YW5pbmcgdGhhdCB0aGlzIGludGVyZmFjZSB3aWxsIG5vdCBiZSB1c2VkIGZvciBhbnk8YnI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRyYWZmaWMuJm5ic3A7IENoYW5naW5nIHRoYXQgaXMgZmFp cmx5IGRyYXN0aWMuJm5ic3A7ICJhZG1pbiBsaW1pdGVkIiBvciAiYWRtaW4gQUNQLU9ubHkiPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB3b3VsZCBzZWVtIG11Y2ggYmV0dGVyIHRoYW4gY2hh bmdpbmcgdGhlIG1lYW5pbmcgb2YgImFkbWluIGRvd24iLiZuYnNwOyBUaGU8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGp1c3RpZmljYXRpb24gaW4gdGhlIHRleHQgc2VlbXMgdG8gYmUgYSBk ZXNpcmUgdG8gcHJldmVudCBhbiBvcGVyYXRvciBmcm9tPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBkb2luZyB3aGF0IGhlIGludGVuZHMuJm5ic3A7IHRoYXQgc2VlbXMgYmFja3dhcmRzLiZu YnNwOyAoTm90ZSB0aGF0IHRoZSBkaXN0aW5jdGlvbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgYmV0d2VlbiBhZG1pbmlzdHJhdGl2ZSBzdGF0ZSB2cyBvcGVyYXRpb25hbCBzdGF0ZSwgYWth IGZhaWxlZCwgaXMgYWxyZWFkeSB3ZWxsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB1bmRl cnN0b29kLik8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBX ZWxsLCB0aGlzIGlzIGluIGFuIGluZm9ybWF0aXZlIHNlY3Rpb24sIHNvIGhvcGVmdWxseSBzb21l dGhpbmcgd2UgY2FuIGFncmVlIHRvIGRpc2FncmVlLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0 OyAmZ3Q7ICZndDsgSWYgdGhpcyB3ZXJlIHRydWx5IGluZm9ybWF0aXZlLCBpdCB3b3VsZCBub3Qg YmVsb25nIGluIHRoaXMgZG9jdW1lbnQgYXQgYWxsLjxicj4mZ3Q7ICZndDsgJmd0OyBDaGFuZ2lu ZyB0aGUgYmVoYXZpb3Igb2Ygd2lkZWx5IHVuZGVyc3Rvb2QgY29uZmlndXJhdGlvbiBiZWhhdmlv cnMgaXMgTk9UIGE8YnI+Jmd0OyAmZ3Q7ICZndDsgc21hbGwgdGhpbmcuJm5ic3A7IENoYW5naW5n IHRoZSBwZXJtaXNzaW9ucyBtb2RlbHMgZm9yIHdpZGVseSB1bmRlcnN0b29kPGJyPiZndDsgJmd0 OyAmZ3Q7IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBpcyBhbHNvIE5PVCBhIHNtYWxsIHRoaW5n Ljxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgTXkgc3VnZ2VzdGlvbiBpcyB0 aGF0IHlvdSByZW1vdmUgYWxsIG9mIHRoaXMgbWF0ZXJpYWwuJm5ic3A7IElmIHlvdSBmZWVsIGl0 IGlzPGJyPiZndDsgJmd0OyAmZ3Q7IGltcG9ydGFudCwgd3JpdGUgYW4gSS1EIGZvciBzdGFuZGFy ZHMgdHJhY2sgb24gZXZvbHZpbmcgdGhlIGNvbmZpZ3VyYXRpb248YnI+Jmd0OyAmZ3Q7ICZndDsg bW9kZWwgZm9yIHJvYnVzdCBBTklNQS4mbmJzcDsgV2hpbGUgSSB0aGluayB0aGUgY2hhbmdlIGlz IGEgbWlzdGFrZSwgeW91IGNsZWFybHk8YnI+Jmd0OyAmZ3Q7ICZndDsgaGF2ZSB0aGUgcmlnaHQg dG8gY2F1c2UgdGhlIGRpc2N1c3Npb24uPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsg Jmd0OyBIaWRpbmcgdGhlIHRvcGljIGluIGFuICJpbmZvcm1hdGlvbmFsIiBub3RlIGluIHRoZSBB Q1AgZG9jdW1lbnQgc2VlbXMgVkVSWTxicj4mZ3Q7ICZndDsgJmd0OyB3cm9uZy48YnI+Jmd0OyAm Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IEFsc28gbm90ZSB0aGF0IGluIHlvdXIgZGlzY3Vz c2lvbiBiZWxvdywgeW91IHRhbGsgYWJvdXQgdGhlIGVxdWl2YWxlbmNlIG9mPGJyPiZndDsgJmd0 OyAmZ3Q7IGFkbWluIGRvd24gYW5kIHBoeXNpY2FsIGRvd24uJm5ic3A7IE1vc3QgbWFuYWdlbWVu dCBtb2RlbHMgSSBrbm93IG9mIHRyZWF0IHRoZXNlPGJyPiZndDsgJmd0OyAmZ3Q7IGFzIHF1aXRl IGRpc3RpbmN0LiZuYnNwOyBTTyB0aGF0IGlzIGF0IGJlc3QgYSByZWQgaGVycmluZy48YnI+Jmd0 OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSG1tLiBJIHJlYWxseSBvbmx5IENMSSBkZXJpdmVkIGZyb20g Q2lzY28gSU9TLCBhbmQgdGhlcmUgdGhlPGJyPiZndDsgJmd0OyBpbnRlcmZhY2UgbGV2ZWwgInNo dXRkb3duIiBjb21tYW5kIGRvdWJsZXMgSU1ITyBib3RoIGFzIGFkbWluIGRvd24gYW5kPGJyPiZn dDsgJmd0OyBhcyBwaHkgZG93biwgc28gaSB3b3VsZCBjb250ZW5kIHRoYXQgdGhpcyBpcyBhIHJl ZCBoZXJyaW5nLiBJdCBhY3R1YWxseTxicj4mZ3Q7ICZndDsgZG9lcyBzaG93IHVwIGluIGRpYWdu b3N0aWMgQ0xJIGFzICJhZG1pbiBkb3duIiwgYnV0IGlzIGFsc28gYnJpbmdpbmcgZG93bjxicj4m Z3Q7ICZndDsgcGh5IHN0YXRlLiBUaGVyZWZvcmUgaXQgaXMgYWxzbyB1c2VkIHRvIGRpYWdub3Nl IHBoeSwgLmUuZzogc2h1dHRpbmcgZG93bjxicj4mZ3Q7ICZndDsgb25lIHNpZGUgb2YgYSBzdXBw b3NlZCBkaXJlY3QgcDJwIGxpbmsgdG8gdmVyaWZ5IHRoZSBwaHkgY2hhbmdlIG9uIHRoZTxicj4m Z3Q7ICZndDsgb3RoZXIgc2lkZS4gVGhhdCBwcmFjdGljYWwgZXhwZXJpZW5jZSBpcyB3aGF0IHRo ZSB0ZXh0IGFuZCBkaXJlY3Rpb24gaXM8YnI+Jmd0OyAmZ3Q7IGJhc2VkIG9uLjxicj4mZ3Q7ICZn dDsgPGJyPiZndDsgJmd0OyBXaGF0cyBhbiBleGFtcGxlIHdoZXJlIGFkbWluL3BoeSBkb3duIGFy ZSBzZXBhcmF0ZSBpbiB5b3VyIGV4cGVyaWVuY2UgPzxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0 OyBJIGRvbid0IGtub3cgaG93IHlvdSBkZWZpbmUgInRydWx5IGluZm9ybWF0aXZlIi4gSSBzaW1w bHkgbWVhbnQ8YnI+Jmd0OyAmZ3Q7IGluZm9ybWF0aW9uYWwgYXMgY29tcGFyZWQgdG8gc3RhbmRh cmRzIHRyYWNrIHdydC4gdG8gbm90IGltcGFjdGluZzxicj4mZ3Q7ICZndDsgaW50ZXJvcGVyYWJp bGl0eSwgYnV0IGFsc28gYXMgYSBwcmVjdXJzb3Igd29yayB0byBnaXZlIG9wcG9ydHVuaXR5PGJy PiZndDsgJmd0OyBmb3IgZ2FpbmluZyBtb3JlIGV4cGVyaWVuY2UgYmVmb3JlIGF0dGVtcHRpbmcg dG8gZ28gc3RhbmRhcmQuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IElmL3doZW4gaSBmaW5k IHRpbWUgaSBkZWZpbml0ZWx5IHdvdWxkIGxpa2UgdG8gaW52ZXN0aWdhdGUgaG93IHRoaXM8YnI+ Jmd0OyAmZ3Q7IGNvdWxkIGJlIGZvcm1hbGl6ZWQgdGhyb3VnaCBhIFlBTkcgbW9kZWwgZm9yIEFD UCBzbyB0aGF0IGl0IGNhbiBiZWNvbWUgc3RhbmRhcmQsPGJyPiZndDsgJmd0OyBidXQgaSBkZWZp bml0ZWx5IGFncmVlIHRoYXQgZXNwZWNpYWxseSB0aGlzIHBhcnQgb2YgdGhlIFlBTkcgbW9kZWwg d291bGQ8YnI+Jmd0OyAmZ3Q7IGJlIGhpZ2hseSBkaWZmaWN1bHQgdG8gZ2V0IHRvIGJlZm9yZSBh bnkgZXhwZXJpZW5jZSBpcyBnYWluZWQgd2l0aDxicj4mZ3Q7ICZndDsgdGhpcy48YnI+Jmd0OyAm Z3Q7IDxicj4mZ3Q7ICZndDsgSSB0aGVyZWZvcmUgd291bGQgdmVyeSBtdWNoIGhlc2l0YXRlIHJl bW92aW5nIHRoaXMgdGV4dCBmcm9tIHRoZSBkb2N1bWVudCwgaXQgd2FzPGJyPiZndDsgJmd0OyBz cGVjaWZpY2FsbHkgYXNrZWQgZm9yIHNldmVyYWwgdGltZXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAg dG8gdW5kZXJzdGFuZDxicj4mZ3Q7ICZndDsgaG93IHRoZSBwcm9taXNlZCByZWxpYWJpbGl0eSBv ZiB0aGUgQUNQIGFnYWluc3Qgb3BlcmF0b3IvY29udG9sbGVyPGJyPiZndDsgJmd0OyBvcGVyYXRp b24gY291bGQgYmUgYWNoaWV2ZWQuIEhhdmluZyB0aGlzIGluIGEgZmlyc3Qgcm91bmQgKHRoaXMg ZG9jdW1lbnQpPGJyPiZndDsgJmd0OyBhcyAiaW5mb3JtYXRpb25hbCIgaXMgSU1ITyBhIGdvb2Qg YW5kIGltcG9ydGFudCB0aGluZy48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAodGV4 dCByZXRhaW5lZCBmb3IgY29udGV4dCBvZiBmdXJ0aGVyIGRpc2N1c3Npb25zLik8YnI+Jmd0OyAm Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg SSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgdGhlIG1vc3QgZWFzeSB3YXkgdG8gb3BlcmF0aW9uYWxp emUgdGhlIEFDUCBhbmQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhY2hpZXZlIGl0cyBnb2FscyBp cyB3aGF0IHdlIGhhdmUgd3JpdHRlbi48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBUaGUgaGlzdG9yaWMgZXF1aXZhbGVuY2Ugb2YgImRvd24iID0gImFkbWlu IGRvd24iID0gInBoeXNpY2FsIGRvd24iIGlzIG9uZSBvZjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHRoZSB0aGUgbW9zdCBmdW5kYW1lbnRhbCBwcm9ibGVtIG9mIHJlbW90ZSBtYW5hZ2VtZW50IGlu IG5ldHdvcmtzLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFdlIHJlYWxseSBuZWVkIHRvIHN0YXJ0IHRoaW5raW5nIG9mIHNlcGFyYXRlIGxheWVycyBvZiAo cmVtb3RlKSBtYW5hZ2VtZW50Ljxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5ldHdvcmsgc2Vydmlj ZXMgb24gb25lIGhhbmQgYW5kIHBoeXNpY2FsIGluZnJhIG9uIHRoZSBvdGhlci48YnI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZmlyc3QgdGhpbmcgdG8g ZG8gdGhpcyBpcyB0byBzZXBhcmF0ZSBvcGVyYXRpb25zIHN1Y2ggYXMgImRvd24iPGJyPiZndDsg Jmd0OyAmZ3Q7ICZndDsgaW50byAiYWRtaW4gZG93biIgdGhhdCBhZmZlY3RzIG5ldHdvcmtzIHNl cnZpY2VzIGFuZCAicGh5IGRvd24iIHRoYXQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhZmZlY3Rz IHRoZSBwaHlzY2lhbCBpbmZyYS48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyBJZiB5b3UgaGF2ZSBleGlzdGluZyBjb21tYW5kcyBsaWtlICJzaHV0ZG93biIg dGhhdCB0b2RheSBkbyBib3RoLDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBzYWZlIG1hcHBp bmcgaXMgdG8gbGV0IHRoZW0gZG8gdGhlIHNhZmUgdGhpbmcgaW4gdGhlIGZ1dHVyZSwgZS5nOjxi cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9ubHkgImFkbWluIGRvd24iLCBhbmQgaW50cm9kdWNlIG5l dyBjb21tYW5kcyBmb3IgdGhlIHBoeSBvcGVyYXRpb25zLDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGUuZy46ICJwaHkgc2h1dGRvd24iIG9yIHRoZSBsaWtlLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IEFuZCB0aGVuIHByb3RlY3QgdGhvc2UgZGFuZ2Vyb3VzIGNvbW1hbmRzIGV2ZW4gZnVydGhlciBh Z2FpbnN0IHVuaW50ZW50aW9uYWwgb3I8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRlbnRpb25h bCBtaXN1c2UuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg VGhpbmsgb2YgQUNQL0FOSSBhbHNvIGFzIGEgc2VhbWxlc3MgaW5iYW5kIHZlcnNpb24gb2YgYSBE Q04uIEFzIGFuIG9wZXJhdG9yPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgb2YgdGhlIGFjdHVhbCBk YXRhIG5ldHdvcmssIHlvdSBhbHNvIGRpZG4ndCBoYXZlIGFueSBhY2Nlc3MgdG8gYnJpbmcgZG93 biB0aGUgRENOPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgYW5kIGN1dCB5b3Vyc2VsZiBvZmYgZnJv bSB0aGUgbmV0d29yayB5b3UgbWFuYWdlLiBZT3UgY291bGQgb25seSBzY3Jldzxicj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHVwIHRoYXQgbmV0d29yayB5b3UncmUgbWVhbnQgdG8gbWFuYWdlLjxicj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZCBpZiB5b3VyIG5l dHdvcmsgY29uc2lzdHMgb2YgVk1zIGluIGEgREMsIGEgInNodXRkb3duIiBvbiB0aGVpcjxicj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IGludGVyZmFjZXMgd2lsbCBhbHNvIG5vdCBicmluZyBkb3duIHBo eXNpY2FsIGludGVyZmFjZXMgbmVjZXNzYXJ5PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgdG8gcmVh Y2ggdGhlIFZNLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IEluIG9wdGljYWwgbmV0d29ya3MgeW91IG9mdGVuIGhhdmUgYW4gaW5iYW5kIHBoeXNjaWFsIGV0 aGVybmV0IG1hbmFnZW1lbnQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBjaGFubmVsLiBNYWtpbmcv YnJlYWtpbmcgdGhhdCBvbmUgaXMgY29tcGxldGVseSBkaWZmZXJlbnQgZnJvbSBtYWtpbmcvYnJl YWtpbmc8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB5b3VyIGRhdGEtcGxhbmUsIGFrYTogZGF0YSBm aWJlciBjb2xvcnMuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAqKiombmJzcDsmbmJzcDsmbmJzcDsgVGhlIG5vdGlvbiBpbiAxMC4zLjYgdGhhdCB0 aGUgZGV2aWNlIHNob3VsZCByZWZ1c2UgdG8gZGlzYWJsZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgZnVuY3Rpb25hbGl0eSB3aGVuIGFuIGF1dGhvcml6ZWQgYWRtaW5pc3RyYXRvciBkaXJl Y3RzIHN1Y2ggc2VlbXMgZmxhdGx5IHdyb25nLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBhdXRob3JpemF0aW9uIHRvIGJyZWFrIHlvdXIgb3duIHJl bW90ZSBtYW5hZ2VtZW50IGNvbm5lY3Rpdml0eTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdvdWxk IGJlIGEgcHJvcGVydHkgb2YgdGhlIGNlcnRpZmljYXRlLiBjbGVhcmx5IHdob2V2ZXIgZW5yb2xs ZWQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZGV2aWNlIHdpdGggYSBjZXJ0aWZpY2F0ZSBk ZW55aW5nIHRoYXQgY2FwYWlsaXR5IHRvIHRoZSBvcGVyYXRvcjxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IGRpZCBOT1QgYXV0aG9yaXplIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGJyZWFrIGNvbm5lY3Rp dml0eS48YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFRoZSBzZWN1cml0eSBt b2RlbCBjaGFuZ2Ugc2VlbXMgYXMgcHJvYmxlbWF0aWMgYXMgdGhlIGFib3ZlIGNvbmZpZ3VyYXRp b248YnI+Jmd0OyAmZ3Q7ICZndDsgY2hhbmdlLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBX ZSBoYXZlIHJlY3VycmluZ2x5IGhlYXJkIGZyb20gY3VzdG9tZXJzIHRoYXQgbWlzdGFrZXMgaW4g bWFuYWdpbmcgcmVtb3RlPGJyPiZndDsgJmd0OyBlcXVpcG1lbnQgYW5kIGxvb3NpbmcgY29ubmVj dGl2aXR5IGlzIGEgbWF5b3IgcGFpbiBwb2ludC4gQ3JlYXRpbmc8YnI+Jmd0OyAmZ3Q7IGFuIG9w ZXJhdGlvbmFsIG9wdGlvbiB0aGF0IGxpbWl0cy9kaXNhYmxlcyBvcGVyYXRvcnMgYWJpbGl0eSB0 bzxicj4mZ3Q7ICZndDsgaW1wYWN0IHBoeSBsZXZlbCBjb25uZWN0aXZpdHkgdGhhdCByZW1vdGUg bWFuYWdlbWVudCBkZXBlbmRzIHVwb24gYW5kIHRoZXJlZm9yZTxicj4mZ3Q7ICZndDsgcmVkdWNp bmcgdGhpcyByaXNrIGFuZCBjb3N0IGZhY3RvciBzZWVtcyB0byBtZSBsaWtlIGEgdmVyeSBsb2dp Y2FsIHBhaDxicj4mZ3Q7ICZndDsgZm9yd2FyZC4gV2hldGhlciBvciBub3QgdGhpcyBzaG91bGQg YmUgaW5kaWNhdGVkIGluIHRoZSBjZXJ0aWZpY2F0ZTxicj4mZ3Q7ICZndDsgb3IgZGlmZmVyZW50 bHkgaXMgZGVmaW5pdGVseSB3aWRlIG9wZW4uPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IEkg YWdyZWUgdGhhdCBub25lIG9mIHRoZXNlIG9wZXJhdGlvbmFsIGludGVyZmFjZSBsZXZlbCBjaGFu Z2VzIGFyZTxicj4mZ3Q7ICZndDsgYSBwaWVjZSBvZiBjYWtlIGdpdmVuIGhvdyB3ZSBoYXZlIGlu IHRoZSBJRVRGIG5vdCB0cmllZCB0byBkZWZpbmU8YnI+Jmd0OyAmZ3Q7IGRpZmZlcmVudCBhY2Nl c3MgbGV2ZWxzIHRvIGNvbmZpZ3VyYXRpb24gc28gZmFyLCBhdCBsZWFzdCBub3Q8YnI+Jmd0OyAm Z3Q7IGJldHdlZW4gc29tZSBwaHkvaW5mcmEgYWNjZXNzIGxldmVsIGFuZCBuZXR3b3JrLXNlcnZp Y2VzIGFjY2VzcyBsZXZlbC48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgQXMgc2FpZCBhYm92 ZSBpbiBteSBmaXJzdCByZXBseSB0aGF0IHlvdSBkaWRuJ3QgY29tbWVudCBvbiwgaSB0aGluayBh PGJyPiZndDsgJmd0OyBnb29kIHBhcnQgb2Ygd2hhdCBpIGFtIGxvb2tpbmcgZm9yIG1heSBoYXBw ZW4gdGhyb3VnaCBvdGhlciBtZWFuczxicj4mZ3Q7ICZndDsgYWxyZWFkeSwgc3VjaCBhcyB3aGVu IGEgcm91dGVyIGlzIGp1c3QgYSBWTSBydW5uaW5nIG9uIGFuIE9TLiBBdCBsZWFzdDxicj4mZ3Q7 ICZndDsgaW4gZWFybHkgdmVyc2lvbnMgb2YgdGhpcyB0aGF0IGknZCBzZWVuLCB0aGlzIGltcGxp Y2l0bHkgZGlzYWJsZWQ8YnI+Jmd0OyAmZ3Q7IHRoZSBhYmlsaXR5IHRvIG1vZGlmeSBwaHkgc3Rh dGUgZnJvbSB0aGUgcm91dGVyIFZNLCBhbmQgb2YgY291cnNlPGJyPiZndDsgJmd0OyBjb21wbGFp bnRzIHdoZXJlIHJhaXNlZCB0aGF0IHBoeSBtb2RzIHdoZXJlIG5lY2Vzc2FyeSwgYnV0IGF0IGxl YXN0IHRoaXM8YnI+Jmd0OyAmZ3Q7IGV2b2x1dGlvbiBjb3VsZCBnaXZlIHJhaXNlIHRvIHBhdXNl IGFuZCByZXRoaW5rIEhPVyB0byBwZXJtaXQgZG9pbmcgdGhpcy48YnI+Jmd0OyAmZ3Q7IDxicj4m Z3Q7ICZndDsgU28gaSB3b3VsZCBhdCBsZWFzdCBsaWtlIHRvIHBsZWRnZSB3aXRoIHlvdSB0aGF0 IGl0IGlzIGEgZ29vZCB0aGluZyB0bzxicj4mZ3Q7ICZndDsgaGF2ZSB0aGlzIHR5cGUgb2YgZGlz Y3Vzc2lvbiBpbiBhbiBpbmZvcm1hdGlvbmFsIHdheSBpbiB0aGlzIFJGQyBpbnN0ZWFkPGJyPiZn dDsgJmd0OyBvZiBkb2luZyBub3RoaW5nIG9yIHRyeWluZyB0byBnbyBzdGFuZGFyZCBZQU5HIGRp cmVjdGx5IGFzIGEgZmlyc3Qgc3RlcC48YnI+Jmd0OyAmZ3Q7IEl0IGRpZCBnZXQgaW50byB0aGUg c3BlYyBiZWNhdXNlIG9mIHRoZSBkZXNpcmUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuPGJyPiZndDsg Jmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEVkaXRvcmlhbCAvIE5pdHM6PGJyPiZn dDsgJmd0OyAmZ3Q7IC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIHRoZSB2YXJpb3VzIGZvcm1hdHMgaW4gc2VjdGlvbiA2 LjEwLCB0aGUgbG93ZXN0IGJpdCBvZiB0aGUgdXBwZXIgNjQgYml0czxicj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgbWFuZGF0 ZWQgdG8gYmUgMC4mbmJzcDsgUHJlc3VtYWJseSwgdGhlcmUgaXMgc29tZSByZWFzb24gZm9yIGRv aW5nIHRoaXMuJm5ic3A7IEl0PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3b3VsZCBiZSBuaWNlIHRvIGV4cGxhaW4gaXQuPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgU29ycnksIG5vdCBj bGVhciB3aGF0IHlvdSdyZSByZWZlcnJpbmcgdG8uIENhbiB5b3UgZ2l2ZSBtZSBhbjxicj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGV4cGxpY2l0IHJlZmVyZW5jZSA/PGJyPiZndDsgJmd0OyAmZ3Q7IDxi cj4mZ3Q7ICZndDsgJmd0OyBJIHNob3VsZCBhaHZlIHJlbW92ZWQgdGhpcyBub3RlLiZuYnNwOyBJ dCB3YXMgYSBzaWRlLWVmZmVjdCBvZiB0aGUgcHJlc2VudGF0aW9uPGJyPiZndDsgJmd0OyAmZ3Q7 IGFuZCBvcmRlcmluZywgbm90IGEgcHJvYmxlbSBvbiBpdHMgb3duLiZuYnNwOyBTb3JyeS48YnI+ Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgQ2hlZXJzPGJyPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBUb2VybGVzczxicj4mZ3Q7ICZndDsgPGJyPiZndDsgPGJyPiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBB bmltYSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBBbmltYUBpZXRmLm9yZzxicj4mZ3Q7IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8YnI+PGJyPi0tIDxicj4tLS08YnI+ dHRlQGNzLmZhdS5kZTxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_10172749362835710-- From nobody Mon May 14 19:58:26 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5912E127909; Mon, 14 May 2018 19:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001, URIBL_DBL_ABUSE_MALW=2.5] 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 wCCCBpbFfZ8m; Mon, 14 May 2018 19:58:13 -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 662F6127863; Mon, 14 May 2018 19:58:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9035C58C4F8; Tue, 15 May 2018 04:58:07 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 752DE440218; Tue, 15 May 2018 04:58:07 +0200 (CEST) Date: Tue, 15 May 2018 04:58:07 +0200 From: Toerless Eckert To: "jmh.direct" Cc: "Joel M. Halpern" , rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org Message-ID: <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> References: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 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, 15 May 2018 02:58:18 -0000 On Mon, May 14, 2018 at 08:49:56AM -0400, jmh.direct wrote: > I think the I understand what you describe. > As far as I can tell, the ACP DOES NOT AND SHOYLD NOT MANDATE > the address assignment mechanism.  But it is the address assignment > mechanism that drives the address allocation. But that exactly is the conclusion of the multi-year ACP work in ANIMA WG. The ACP of an unconfigured, but only certificate enrolled device needs to be able to bring up routing and addressing for the ACP autonomically, aka: without any other dependencies. This ACP draft as it stands only depends on BRSKI and some unmodified CA to be implemented and deployed. There is no NOC with any address management functions required. At minimum, addressing is solely done from th registrar, and you can have many registrars in a network and there is no chance for inconsistent address configuration. Please propose any other solution that you are thinking of in enough detail to discuss it, and i think we can show it has more, and often future/undefined problems to be resolved. > I would expect to find the address structure for autonomic addressed > in the same document as the mechanisms for autonomic address assignment. The ANIMA autonomic address asignment draft is relying on the ACP to be operational end-to-end to signal amongst its components via ACP GRASP the address/prefix assignments. It can by definition not be used to bring up routing and addressing of the ACP itself. It likely also required more centralized functionality. For what it tries to do, it is elegant, flexible and all that because it does not have to bother about bootstrap addressing and routing for itself as the ACP has to do. https://en.wikipedia.org/wiki/Bootstrapping#/media/File:Zentralbibliothek_Solothurn_-_M%C3%BCnchhausen_zieht_sich_am_Zopf_aus_dem_Sumpf_-_a0400.tif BRSKI+ACP are doing what poor Muenchhausen is trying to do in what i think is a quite lightweight, very secure, scalable and for the job at hand (ugly) quite elegant way. > That is, why the routing scheme seemed confusing after the address allocation scheme. If you can be more explicit about what you think is confusing, i am happy to make any confusing text better. Note that routing protocol/profile and addressing scheme are all subject to future enhancements easily. But in the design of anima, we would like to have operator defined address policy to be part of intent, and that would not only requir a lot more future work, it would also make addressing assigned this way less reliable and would not allow to use addresses managed dyanmically be used by components that are used to implement the Intent infrastructure or any future ANI components (ASA etc.) that intent or address management depends on. Cheers Toerless > Yours,Joel > > > Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone > -------- Original message --------From: Toerless Eckert Date: 5/14/18 05:04 (GMT-05:00) To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org Subject: Re: [Anima] Rtgdir telechat review of >   draft-ietf-anima-autonomic-control-plane-13 > a) Will try to do better explanation of identifier nature of addresses in >    next commit. > > b) what do we loose if get rid of the choices. I kinda thought i had answered >    this already, but i really don't know where your concern starts... > >    1. We use ULA because we want to be able to bring up ACP networks without >       requiring a registry allocation of a prefix, and ULA is the correct >       private address space. And deriving ULA Global ID from hash of domain >       name is nice. > >       Sounds as if you agree with this. >     >    2. We want to be able to allocate addresses to ACP/ANI devices >       without any additional configuration from multiple independently >       running registrars. Thats why the global unique ID of the registrar >       is part of the address in both zone and Vlong format. > >       Thats very fundamental to the ease of deployment of ACP/ANI nodes >       (i say ANI, because its really ACP+BRSKI required here to get a simple standard >        solution to create the cert, otherwise youre down to a vendor specific >        cert provisioning solution extended with ACP info support) > >       i hope this is uncontentuous >    >    3. a) We wanted to be able to support in the future "zone" = area/region-level >       route aggregation, thats why the zone scheme reserves those 13 bits. > >       b) We also know use cases where nodes need more than 2 addresses, >       thats why we have have the 8/16 bit Vlong option. > >       c) We can not do everything autonomically (== addresses assigned from registrars), >       so we also reserve address space for traditional config (manual address space). > >       Are these three sub-spaces zone,manual,vlong contenuous ? >    >    As mentioned in prior email if i wanted to avoid those ca. 3 bits of >    format indication, i would need to indicate the semantic of addresses >    somehow differently to the nodes, e.g: via some extension to the ACP format, >    but i would want to be able to signal the same information. > >    So for example: because we have a standardized addressing scheme, >    a node that allows configuration of "ACP connect" can make sure >    that the address configured on an ACP cnnect interface can never be a ULA >    address that would conflict with an automatic ACP address assignment done >    by a registrar. So i protect my autonomic address space from misconfiguration. >    Which is IMHO extremely important. So this is the key justification for >    the manual address space allocation. > >    Distinguishing between zone and Vlong address spaces is necessary because >    we just can't fit zone, registrar-ID and node-number and 16 bit of per-node bits >    into a single addressing scheme. > >    E voila, three (IMHO: simpler) simple options. Likely networks will use all three. > > Cheers >     Toerless > > On Sun, May 13, 2018 at 07:38:35PM -0400, Joel M. Halpern wrote: > > Trimmed. > > Top posting for clarity.  Mostly, agreement. > > > > On the identifier vs locator, I think the way you are using the terms is > > confusing.  But it is not worth continued argumentation.Some text > > elaborating along the lines you provide (retained below) would help. > > > > I have tried reading the section on addressing inside the ACP more > > carefully.  Thank you for moving the Z bit. > > I have retained the earlier discussion on this topic below, in case we still > > need it. > > Reading the section, I think that the problem is more basic. > > > > I agree that the document needs to define that we are using a ULA.  And > > because of the certificate behaviors, there is significant advantage in > > defining what ULA prefix is used. > > > > Given that, I do not see what use there is in all the other format > > definition.  I suspect I am missing something very basic.  Why not leave > > this to the deploying operator?  It is not like it can be autonomic, since > > something has to tell the devices what format to use, and what numbers > > within some of the formats to use.  I could imagine something that said "in > > the absence of configuration, construct device addresses according to one > > specific algorithm, so as to simplify bootstrap. > > But it would be a simple scheme. > > > > > > On 5/11/18 10:09 PM, Toerless Eckert wrote: > > > > > > Diff: > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt > > > > > > Latest version: > > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt > > > > > .... > > > Here are the things that make the ACP address an identifier to me: > > > > > > - It is assigned once to the device and not meant to change over the lifetime > > >    of the device. > > > - It does not change when i move the node to a different location > > >    and re-connect the device. > > > - It is the unique part of the ACP domain certificate (other than the private key) > > >    and used to identify the device (privat key is used to authenticate it, > > >    but the private key may change over time, for example when renewing the certificate). > > > > > > Would be happy to elaborate this in the doc more explicitly, e.g.: like written > > > above. > > > > (Context: Addressing inside the ACP.) > > > > Part of my reaction to this whole section is that it looks much like the > > > > mistake we made originally in defining classful IP addresses.  You are > > > > trying to guess the correct use cases, and defining specific address > > > > structures with specific encodings for each one.  With only a few encodings > > > > available.  This seems to be a recipe for being wrong later in ways that > > > > hurt. > > > > > > The only equivalent to classfull addressing i see is for the fixed prefix-length > > > handed out to each node, 1 bit (2 addresses) with zone addresses, 8/16 bits > > > (256/64k address) for Vlong, but its NOT assignment to network segments > > > as in IPv4 A/B/C but to nodes. > > > > > > We didn't introduce choices lightly. There are compromises to be made when you > > > want some lightweight address allocation scheme, not expecting to have complex > > > address registry or management system in the backend but simple registrars. > > > > > > see below for more > > > > > > > >         The difference in interpretation > > > > > >       is actually provided by the last bit in the upper 64.  If these are the > > > > > >       same schema, then it should not need a bit to differentiate them.  They > > > > > >       should be explained as a single schema.  Which would presumably result in > > > > > >       the Z bit being part of the zone / subnet field.   If they are two > > > > > >       different schemas, then move the differentiation to part of the schema > > > > > >       identifier (making it 3 bits). > > > > > > > > > > We did not want to make Z part of the base schemas 6.10.2 "Type" code because > > > > > that would also make the Vlong scheme one bit shorter and that would reduce > > > > > virtualization space in Vlong by a factor of 2. > > > > > > > > > > So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out > > > > > of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. > > > > > > > > > > Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO > > > > > textually correct to have them in different subsections. > > > > > > > > > > Carving out bits like Z isn't ideal, but in between the ULA prefix, > > > > > the 64 bit local part we must have for external interfaces and > > > > > best utilization of bits, we tried to rather optimize address space > > > > > utilization and not beauty of encoding. > > > > > > > > > > Having  at the end allows (as written) use of /63 instead of  2 * /64 > > > > > routes. I am not sure how important this would be in the future. > > > > > > > > > > If you feel strongly about more beauty in encoding, > > > > > i can move Z to the left and remove the notion of the possible /63 route > > > > > optimization possible through the placement of Z. > > > > > > > > Since the two different uses of the Z bit with type 00b are quite distinct, > > > > trying to enable aggregation seems counter-productive. > > > > > > > > While I hate to push on a point you describe as aesthetics, having the Z > > > > bit, occuring after the Zone / subnet-ID field, but defining whether the > > > > field is a zone or a subnet, seems awkward for insufficient reason. > > > > > > > > I would recommend moving the Z bit up so it is after the type, and at the > > > > front of each of the two sections reiterate that this subscheme is indicated > > > > by the Z bit being { 0 | 1 }. > > > > > > Done. (see diff). > > > > > > > > I very much hope there is no "interesting" implementation aspect; > > > > > nothing in the current scheme that makes implemenation harder. If you > > > > > have an example that you fear, i would like to hear it. > > > > > > > > > > To me, we are just defining address space allocation schemes. > > > > > > > > I suppose likely implementations will use mask definitions that will make it > > > > work.  I pity the code reviewer. > > > > > > I have read the code and tested in the lab IPv6 embedded RP adressing > > > and didn't feel pityfull about the job. But i weigh the overall system > > > complexity. Embedded-RP simplified a lot of other parts of the > > > multicast system at the cost of introducing an addressing scheme. > > > I think similarily, the ACP addressing scheme simplifies the overall system > > > complexity, especially registrars. > > > > > > > > >       In section 6.10.5, after stating that it is not even known what the needed > > > > > >       usage is for more V values > > > > > > > > > > Which sentence are you referring to when you say "not even known what the > > > > > needed usage is" ? I can't find it, but i would like to rectify it > > > > > if it actually is still there. > > > > > > > > The text reads "further values use via definition in future work."  In the > > > > zone-id scheme, it is one bit.  For some reason, it is 8 or 16 bits here. > > > > > > Thanks, changed sentence to: > > > > > > V: Virtualization bit: Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme. > > > > > > The existing text, now directly after the list, explains examples > > > when a device would likely need 256 or 64k addresses: > > > > > > existing text: > > > ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge nodes ... > > > > > > > > >       the document goes on to introduce the > > > > > >       complexity of classful nodes numbers, with the leading bit indicating how > > > > > >       long the node-number is.  Yes, the rest of the text in that bullet tries to > > > > > >       explain why you need both sizes.  It seems like needless complexity that > > > > > >       begs for mistakes in implementation. > > > > > > > > > > I was taking the example use cases we brainstormed into account, and > > > > > some of them  would require a lot more addresses in the node than others, > > > > > therefore these two choices. > > > > > > > > See my comments above.  Trying to encode specific use cases into the address > > > > format seems a problematic answer to an admittedly difficult question. > > > > > > > > What would break if you didn't define any of this? > > > > > > One could save the 2.5 bits (Type, Z) indicating the structure of the > > > address inside the address by encoding the designated format of the > > > address instead in an extension field of the ACP address information in > > > the certificate. We would certainly still want to have the same type > > > of addresses, e.g.: 2,256,64k local addresses, option for zones and > > > address to assign to ACP connect interfaces (manual addressing scheme) > > > IMHO. So, at best we could save the 2.5 bits if we wanted to keep the > > > functionality, which i think is all required. > > > > > > I would be quite afraid of doing such a drastic change this late in > > > the process because i think it will take a long time to foresee the > > > resulting complexity introduced for registars and any other place > > > that now can deduct the semantic from the address and would then have > > > to access to what the certificate indicates in a different way (e.g.: > > > access to the certificate). Note that the length of the ACP information > > > field in the cert is also limited, so this type of extension might end > > > up looking even uglier to be short *sigh*. > > > > > > I was always thinking that this type of more flexible option would > > > be a good next-step, but not a safe first step. It would make a lot > > > more sense after hearing implementation/deployment experiences, > > > especially to correctly support important options we may have > > > overlooked in the current schemes. Just redoing what we have differently > > > to save 2.5 bits isn't worth it IMHO. > > > > > > > > Ultimately, we need to break through the chicken and egg problem > > > > > of how to build more self-managing networks. These will require > > > > > a different number of addresses inside nodes. Anything more intelligent > > > > > than address space allocations would become a complex dependency > > > > > making implementation/adoption even slower. I don't think that > > > > > offering 2, 256, 64k addresses per node is too much flexibility. > > > > > It IMHO necessary and sufficient to explore and we'll see what sticks. > > > > > > > > Variation is needed.  That was true of allocations in IP.  encoding the > > > > variations proved a bad choice. > > > > > > Let me repeat that we are not doing any network/subnet prefix encoding which is > > > what IPv4 A/B/C was. And there are IMHO good examples how encoding in IPv6 > > > did save the day from complexity (at least all the stuff done for IPv6 > > > multicast, ASM/SSM, zones, Embedded-RP) was highly useful. > > > > > > > > >       In section 6.11.1.11 in describing the prefix lengths, I thought that the > > > > > >       point of zone addressing was to allow the use of /64 prefixes.  But it > > > > > >       seems here that we will not do so ? > > > > > > > > > > As mentioned above: This document does not describe the routing setup for /64 > > > > > (or /63 with Z-bit) routing aggregation. There are multiple options, > > > > > but we could not conclude on a single solution that we felt to be > > > > > appropriate for this document. Instead it was only very important > > > > > to carve out addressing space to support this. > > > > The net effect seems to be to prohibt the very things that you went to a lot > > > > of trouble to enable in your addressing design. > > > > > > Maybe i do not understand your comment correctly, but i do not > > > think it is correct. We just have not defined recommended mechanisms > > > how to set up routing to use /64 zone routes. That is something IMHO > > > better done in a followup document because all the cases where we > > > did see a need for znes where really very specific to particular > > > deployment styles and would not be applicable to the mayority of ACPs. > > > Nevertheless, we felt those cases where important enough to reserve > > > bits for them through the zone field. > > > > > > > ... > > > > > > ***    Section 10.3.2 paragraph 2 says that devices should change the meaning > > > > > > of "admin down" to mean "down for everything except ACP / Anima".    I can > > > > > > understand why, in an autonomic network, such a state is desirable.  However, > > > > > > that really should be a different state from "admin down".  Operators already > > > > > > understand "admin down" as meaning that this interface will not be used for any > > > > > > traffic.  Changing that is fairly drastic.  "admin limited" or "admin ACP-Only" > > > > > > would seem much better than changing the meaning of "admin down".  The > > > > > > justification in the text seems to be a desire to prevent an operator from > > > > > > doing what he intends.  that seems backwards.  (Note that the distinction > > > > > > between administrative state vs operational state, aka failed, is already well > > > > > > understood.) > > > > > > > > > > Well, this is in an informative section, so hopefully something we can agree to disagree. > > > > > > > > If this were truly informative, it would not belong in this document at all. > > > > Changing the behavior of widely understood configuration behaviors is NOT a > > > > small thing.  Changing the permissions models for widely understood > > > > configuration operations is also NOT a small thing. > > > > > > > > My suggestion is that you remove all of this material.  If you feel it is > > > > important, write an I-D for standards track on evolving the configuration > > > > model for robust ANIMA.  While I think the change is a mistake, you clearly > > > > have the right to cause the discussion. > > > > > > > > Hiding the topic in an "informational" note in the ACP document seems VERY > > > > wrong. > > > > > > > > Also note that in your discussion below, you talk about the equivalence of > > > > admin down and physical down.  Most management models I know of treat these > > > > as quite distinct.  SO that is at best a red herring. > > > > > > Hmm. I really only CLI derived from Cisco IOS, and there the > > > interface level "shutdown" command doubles IMHO both as admin down and > > > as phy down, so i would contend that this is a red herring. It actually > > > does show up in diagnostic CLI as "admin down", but is also bringing down > > > phy state. Therefore it is also used to diagnose phy, .e.g: shutting down > > > one side of a supposed direct p2p link to verify the phy change on the > > > other side. That practical experience is what the text and direction is > > > based on. > > > > > > Whats an example where admin/phy down are separate in your experience ? > > > > > > I don't know how you define "truly informative". I simply meant > > > informational as compared to standards track wrt. to not impacting > > > interoperability, but also as a precursor work to give opportunity > > > for gaining more experience before attempting to go standard. > > > > > > If/when i find time i definitely would like to investigate how this > > > could be formalized through a YANG model for ACP so that it can become standard, > > > but i definitely agree that especially this part of the YANG model would > > > be highly difficult to get to before any experience is gained with > > > this. > > > > > > I therefore would very much hesitate removing this text from the document, it was > > > specifically asked for several times in the working group to understand > > > how the promised reliability of the ACP against operator/contoller > > > operation could be achieved. Having this in a first round (this document) > > > as "informational" is IMHO a good and important thing. > > > > > > > (text retained for context of further discussions.) > > > > > > > > > > > > > > I strongly believe that the most easy way to operationalize the ACP and > > > > > achieve its goals is what we have written. > > > > > > > > > > The historic equivalence of "down" = "admin down" = "physical down" is one of > > > > > the the most fundamental problem of remote management in networks. > > > > > > > > > > We really need to start thinking of separate layers of (remote) management. > > > > > Network services on one hand and physical infra on the other. > > > > > > > > > > The first thing to do this is to separate operations such as "down" > > > > > into "admin down" that affects networks services and "phy down" that > > > > > affects the physcial infra. > > > > > > > > > > If you have existing commands like "shutdown" that today do both, > > > > > the safe mapping is to let them do the safe thing in the future, e.g: > > > > > only "admin down", and introduce new commands for the phy operations, > > > > > e.g.: "phy shutdown" or the like. > > > > > And then protect those dangerous commands even further against unintentional or > > > > > intentional misuse. > > > > > > > > > > Think of ACP/ANI also as a seamless inband version of a DCN. As an operator > > > > > of the actual data network, you also didn't have any access to bring down the DCN > > > > > and cut yourself off from the network you manage. YOu could only screw > > > > > up that network you're meant to manage. > > > > > > > > > > And if your network consists of VMs in a DC, a "shutdown" on their > > > > > interfaces will also not bring down physical interfaces necessary > > > > > to reach the VM. > > > > > > > > > > In optical networks you often have an inband physcial ethernet management > > > > > channel. Making/breaking that one is completely different from making/breaking > > > > > your data-plane, aka: data fiber colors. > > > > > > > > > > > ***    The notion in 10.3.6 that the device should refuse to disable > > > > > > functionality when an authorized administrator directs such seems flatly wrong. > > > > > > > > > > The authorization to break your own remote management connectivity > > > > > would be a property of the certificate. clearly whoever enrolled > > > > > the device with a certificate denying that capaility to the operator > > > > > did NOT authorize the administrator to break connectivity. > > > > > > > > The security model change seems as problematic as the above configuration > > > > change. > > > > > > We have recurringly heard from customers that mistakes in managing remote > > > equipment and loosing connectivity is a mayor pain point. Creating > > > an operational option that limits/disables operators ability to > > > impact phy level connectivity that remote management depends upon and therefore > > > reducing this risk and cost factor seems to me like a very logical pah > > > forward. Whether or not this should be indicated in the certificate > > > or differently is definitely wide open. > > > > > > I agree that none of these operational interface level changes are > > > a piece of cake given how we have in the IETF not tried to define > > > different access levels to configuration so far, at least not > > > between some phy/infra access level and network-services access level. > > > > > > As said above in my first reply that you didn't comment on, i think a > > > good part of what i am looking for may happen through other means > > > already, such as when a router is just a VM running on an OS. At least > > > in early versions of this that i'd seen, this implicitly disabled > > > the ability to modify phy state from the router VM, and of course > > > complaints where raised that phy mods where necessary, but at least this > > > evolution could give raise to pause and rethink HOW to permit doing this. > > > > > > So i would at least like to pledge with you that it is a good thing to > > > have this type of discussion in an informational way in this RFC instead > > > of doing nothing or trying to go standard YANG directly as a first step. > > > It did get into the spec because of the desire of the working group. > > > > > > > > > Editorial / Nits: > > > > . > > > > > >       In the various formats in section 6.10, the lowest bit of the upper 64 bits > > > > > >       is mandated to be 0.  Presumably, there is some reason for doing this.  It > > > > > >       would be nice to explain it. > > > > > > > > > > Sorry, not clear what you're referring to. Can you give me an > > > > > explicit reference ? > > > > > > > > I should ahve removed this note.  It was a side-effect of the presentation > > > > and ordering, not a problem on its own.  Sorry. > > > > > > Cheers > > >      Toerless > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Mon May 14 20:16:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E52127863; Mon, 14 May 2018 20:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_ABUSE_MALW=2.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9-x9OjXtFZW; Mon, 14 May 2018 20:16:00 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A77312778D; Mon, 14 May 2018 20:16:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 61B469A09C7; Mon, 14 May 2018 20:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1526354160; bh=7WID3Q0xb14cwWhrd8WhYebrfaCV0Oo3knqVvMgm2Sc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nObegbt8ElFl+2mGyfF0biAXb4OeoKaOH1fY85XtysYBYdhSuvfoxfFy+QuSW6Z86 KTFZhigTUUMk7HaNIpSJmbbhIstV/ctFrL0hzG6lm61gWVBnS4OXbpdC9WoG0DNr1G d+j3F1Ztnsp/3y8jeCMZ/HzNrwR+8/BVBeemAP1A= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 24E459A09BF; Mon, 14 May 2018 20:15:59 -0700 (PDT) To: Toerless Eckert Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org References: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: <6c4f9527-1b96-9c14-ffe0-186a24eb9793@joelhalpern.com> Date: Mon, 14 May 2018 23:15:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 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, 15 May 2018 03:16:04 -0000 (Sorry about the excess caps. Did not intentd to shout.) From some off-line disucssions, I understand that the actual address allocation is tied to the registration process. The registration process is not described in this document. As far as I can tell, the ACP does not depend upon the address allocation strategy. The address allocation strategy does require the ACP. And it requires and is closely coupled to the registration process. If that is true, the address allocation seems to be better described with the registration process. Which I presume is in the BRSKI document. All I would put in here is the basic ULA allocation (hash based generation) mechanism. Yours, Joel On 5/14/18 10:58 PM, Toerless Eckert wrote: > On Mon, May 14, 2018 at 08:49:56AM -0400, jmh.direct wrote: >> I think the I understand what you describe. >> As far as I can tell, the ACP DOES NOT AND SHOYLD NOT MANDATE >> the address assignment mechanism.  But it is the address assignment >> mechanism that drives the address allocation. > > But that exactly is the conclusion of the multi-year ACP work in ANIMA WG. > The ACP of an unconfigured, but only certificate enrolled device needs to > be able to bring up routing and addressing for the ACP autonomically, > aka: without any other dependencies. > > This ACP draft as it stands only depends on BRSKI and some unmodified CA > to be implemented and deployed. There is no NOC with any address management > functions required. At minimum, addressing is solely done from th registrar, > and you can have many registrars in a network and there is no chance > for inconsistent address configuration. > > Please propose any other solution that you are thinking of in enough detail > to discuss it, and i think we can show it has more, and often future/undefined > problems to be resolved. > >> I would expect to find the address structure for autonomic addressed >> in the same document as the mechanisms for autonomic address assignment. > > The ANIMA autonomic address asignment draft is relying on the ACP to be > operational end-to-end to signal amongst its components via ACP GRASP the > address/prefix assignments. It can by definition not be used to bring up > routing and addressing of the ACP itself. It likely also required more > centralized functionality. For what it tries to do, it is elegant, flexible and > all that because it does not have to bother about bootstrap addressing and > routing for itself as the ACP has to do. > > https://en.wikipedia.org/wiki/Bootstrapping#/media/File:Zentralbibliothek_Solothurn_-_M%C3%BCnchhausen_zieht_sich_am_Zopf_aus_dem_Sumpf_-_a0400.tif > > BRSKI+ACP are doing what poor Muenchhausen is trying to do in > what i think is a quite lightweight, very secure, scalable and > for the job at hand (ugly) quite elegant way. > >> That is, why the routing scheme seemed confusing after the address allocation scheme. > > If you can be more explicit about what you think is confusing, i am > happy to make any confusing text better. > > Note that routing protocol/profile and addressing scheme are all subject > to future enhancements easily. But in the design of anima, we would like > to have operator defined address policy to be part of intent, and > that would not only requir a lot more future work, it would also make > addressing assigned this way less reliable and would not allow to use > addresses managed dyanmically be used by components that are used to implement > the Intent infrastructure or any future ANI components (ASA etc.) that > intent or address management depends on. > > Cheers > Toerless > >> Yours,Joel >> >> >> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone >> -------- Original message --------From: Toerless Eckert Date: 5/14/18 05:04 (GMT-05:00) To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org Subject: Re: [Anima] Rtgdir telechat review of >>   draft-ietf-anima-autonomic-control-plane-13 >> a) Will try to do better explanation of identifier nature of addresses in >>    next commit. >> >> b) what do we loose if get rid of the choices. I kinda thought i had answered >>    this already, but i really don't know where your concern starts... >> >>    1. We use ULA because we want to be able to bring up ACP networks without >>       requiring a registry allocation of a prefix, and ULA is the correct >>       private address space. And deriving ULA Global ID from hash of domain >>       name is nice. >> >>       Sounds as if you agree with this. >> >>    2. We want to be able to allocate addresses to ACP/ANI devices >>       without any additional configuration from multiple independently >>       running registrars. Thats why the global unique ID of the registrar >>       is part of the address in both zone and Vlong format. >> >>       Thats very fundamental to the ease of deployment of ACP/ANI nodes >>       (i say ANI, because its really ACP+BRSKI required here to get a simple standard >>        solution to create the cert, otherwise youre down to a vendor specific >>        cert provisioning solution extended with ACP info support) >> >>       i hope this is uncontentuous >> >>    3. a) We wanted to be able to support in the future "zone" = area/region-level >>       route aggregation, thats why the zone scheme reserves those 13 bits. >> >>       b) We also know use cases where nodes need more than 2 addresses, >>       thats why we have have the 8/16 bit Vlong option. >> >>       c) We can not do everything autonomically (== addresses assigned from registrars), >>       so we also reserve address space for traditional config (manual address space). >> >>       Are these three sub-spaces zone,manual,vlong contenuous ? >> >>    As mentioned in prior email if i wanted to avoid those ca. 3 bits of >>    format indication, i would need to indicate the semantic of addresses >>    somehow differently to the nodes, e.g: via some extension to the ACP format, >>    but i would want to be able to signal the same information. >> >>    So for example: because we have a standardized addressing scheme, >>    a node that allows configuration of "ACP connect" can make sure >>    that the address configured on an ACP cnnect interface can never be a ULA >>    address that would conflict with an automatic ACP address assignment done >>    by a registrar. So i protect my autonomic address space from misconfiguration. >>    Which is IMHO extremely important. So this is the key justification for >>    the manual address space allocation. >> >>    Distinguishing between zone and Vlong address spaces is necessary because >>    we just can't fit zone, registrar-ID and node-number and 16 bit of per-node bits >>    into a single addressing scheme. >> >>    E voila, three (IMHO: simpler) simple options. Likely networks will use all three. >> >> Cheers >>     Toerless >> >> On Sun, May 13, 2018 at 07:38:35PM -0400, Joel M. Halpern wrote: >>> Trimmed. >>> Top posting for clarity.  Mostly, agreement. >>> >>> On the identifier vs locator, I think the way you are using the terms is >>> confusing.  But it is not worth continued argumentation.Some text >>> elaborating along the lines you provide (retained below) would help. >>> >>> I have tried reading the section on addressing inside the ACP more >>> carefully.  Thank you for moving the Z bit. >>> I have retained the earlier discussion on this topic below, in case we still >>> need it. >>> Reading the section, I think that the problem is more basic. >>> >>> I agree that the document needs to define that we are using a ULA.  And >>> because of the certificate behaviors, there is significant advantage in >>> defining what ULA prefix is used. >>> >>> Given that, I do not see what use there is in all the other format >>> definition.  I suspect I am missing something very basic.  Why not leave >>> this to the deploying operator?  It is not like it can be autonomic, since >>> something has to tell the devices what format to use, and what numbers >>> within some of the formats to use.  I could imagine something that said "in >>> the absence of configuration, construct device addresses according to one >>> specific algorithm, so as to simplify bootstrap. >>> But it would be a simple scheme. >>> >>> >>> On 5/11/18 10:09 PM, Toerless Eckert wrote: >>>> >>>> Diff: >>>> >>>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt >>>> >>>> Latest version: >>>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt >>>> >>> .... >>>> Here are the things that make the ACP address an identifier to me: >>>> >>>> - It is assigned once to the device and not meant to change over the lifetime >>>>     of the device. >>>> - It does not change when i move the node to a different location >>>>     and re-connect the device. >>>> - It is the unique part of the ACP domain certificate (other than the private key) >>>>     and used to identify the device (privat key is used to authenticate it, >>>>     but the private key may change over time, for example when renewing the certificate). >>>> >>>> Would be happy to elaborate this in the doc more explicitly, e.g.: like written >>>> above. >>> >>> (Context: Addressing inside the ACP.) >>>>> Part of my reaction to this whole section is that it looks much like the >>>>> mistake we made originally in defining classful IP addresses.  You are >>>>> trying to guess the correct use cases, and defining specific address >>>>> structures with specific encodings for each one.  With only a few encodings >>>>> available.  This seems to be a recipe for being wrong later in ways that >>>>> hurt. >>>> >>>> The only equivalent to classfull addressing i see is for the fixed prefix-length >>>> handed out to each node, 1 bit (2 addresses) with zone addresses, 8/16 bits >>>> (256/64k address) for Vlong, but its NOT assignment to network segments >>>> as in IPv4 A/B/C but to nodes. >>>> >>>> We didn't introduce choices lightly. There are compromises to be made when you >>>> want some lightweight address allocation scheme, not expecting to have complex >>>> address registry or management system in the backend but simple registrars. >>>> >>>> see below for more >>>> >>>>>>          The difference in interpretation >>>>>>>        is actually provided by the last bit in the upper 64.  If these are the >>>>>>>        same schema, then it should not need a bit to differentiate them.  They >>>>>>>        should be explained as a single schema.  Which would presumably result in >>>>>>>        the Z bit being part of the zone / subnet field.   If they are two >>>>>>>        different schemas, then move the differentiation to part of the schema >>>>>>>        identifier (making it 3 bits). >>>>>> >>>>>> We did not want to make Z part of the base schemas 6.10.2 "Type" code because >>>>>> that would also make the Vlong scheme one bit shorter and that would reduce >>>>>> virtualization space in Vlong by a factor of 2. >>>>>> >>>>>> So, yes, encoding wise, 6.10.4 manual sub addressing space was carved out >>>>>> of the 6.10.3 zone address space via the Z bit, but thats just an encoding aspect. >>>>>> >>>>>> Functionally, 6.10.3/6.10.4 are quite different, and therefore it is IMHO >>>>>> textually correct to have them in different subsections. >>>>>> >>>>>> Carving out bits like Z isn't ideal, but in between the ULA prefix, >>>>>> the 64 bit local part we must have for external interfaces and >>>>>> best utilization of bits, we tried to rather optimize address space >>>>>> utilization and not beauty of encoding. >>>>>> >>>>>> Having  at the end allows (as written) use of /63 instead of  2 * /64 >>>>>> routes. I am not sure how important this would be in the future. >>>>>> >>>>>> If you feel strongly about more beauty in encoding, >>>>>> i can move Z to the left and remove the notion of the possible /63 route >>>>>> optimization possible through the placement of Z. >>>>> >>>>> Since the two different uses of the Z bit with type 00b are quite distinct, >>>>> trying to enable aggregation seems counter-productive. >>>>> >>>>> While I hate to push on a point you describe as aesthetics, having the Z >>>>> bit, occuring after the Zone / subnet-ID field, but defining whether the >>>>> field is a zone or a subnet, seems awkward for insufficient reason. >>>>> >>>>> I would recommend moving the Z bit up so it is after the type, and at the >>>>> front of each of the two sections reiterate that this subscheme is indicated >>>>> by the Z bit being { 0 | 1 }. >>>> >>>> Done. (see diff). >>>> >>>>>> I very much hope there is no "interesting" implementation aspect; >>>>>> nothing in the current scheme that makes implemenation harder. If you >>>>>> have an example that you fear, i would like to hear it. >>>>>> >>>>>> To me, we are just defining address space allocation schemes. >>>>> >>>>> I suppose likely implementations will use mask definitions that will make it >>>>> work.  I pity the code reviewer. >>>> >>>> I have read the code and tested in the lab IPv6 embedded RP adressing >>>> and didn't feel pityfull about the job. But i weigh the overall system >>>> complexity. Embedded-RP simplified a lot of other parts of the >>>> multicast system at the cost of introducing an addressing scheme. >>>> I think similarily, the ACP addressing scheme simplifies the overall system >>>> complexity, especially registrars. >>>> >>>>>>>        In section 6.10.5, after stating that it is not even known what the needed >>>>>>>        usage is for more V values >>>>>> >>>>>> Which sentence are you referring to when you say "not even known what the >>>>>> needed usage is" ? I can't find it, but i would like to rectify it >>>>>> if it actually is still there. >>>>> >>>>> The text reads "further values use via definition in future work."  In the >>>>> zone-id scheme, it is one bit.  For some reason, it is 8 or 16 bits here. >>>> >>>> Thanks, changed sentence to: >>>> >>>> V: Virtualization bit: Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme. >>>> >>>> The existing text, now directly after the list, explains examples >>>> when a device would likely need 256 or 64k addresses: >>>> >>>> existing text: >>>> ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge nodes ... >>>> >>>>>>>        the document goes on to introduce the >>>>>>>        complexity of classful nodes numbers, with the leading bit indicating how >>>>>>>        long the node-number is.  Yes, the rest of the text in that bullet tries to >>>>>>>        explain why you need both sizes.  It seems like needless complexity that >>>>>>>        begs for mistakes in implementation. >>>>>> >>>>>> I was taking the example use cases we brainstormed into account, and >>>>>> some of them  would require a lot more addresses in the node than others, >>>>>> therefore these two choices. >>>>> >>>>> See my comments above.  Trying to encode specific use cases into the address >>>>> format seems a problematic answer to an admittedly difficult question. >>>>> >>>>> What would break if you didn't define any of this? >>>> >>>> One could save the 2.5 bits (Type, Z) indicating the structure of the >>>> address inside the address by encoding the designated format of the >>>> address instead in an extension field of the ACP address information in >>>> the certificate. We would certainly still want to have the same type >>>> of addresses, e.g.: 2,256,64k local addresses, option for zones and >>>> address to assign to ACP connect interfaces (manual addressing scheme) >>>> IMHO. So, at best we could save the 2.5 bits if we wanted to keep the >>>> functionality, which i think is all required. >>>> >>>> I would be quite afraid of doing such a drastic change this late in >>>> the process because i think it will take a long time to foresee the >>>> resulting complexity introduced for registars and any other place >>>> that now can deduct the semantic from the address and would then have >>>> to access to what the certificate indicates in a different way (e.g.: >>>> access to the certificate). Note that the length of the ACP information >>>> field in the cert is also limited, so this type of extension might end >>>> up looking even uglier to be short *sigh*. >>>> >>>> I was always thinking that this type of more flexible option would >>>> be a good next-step, but not a safe first step. It would make a lot >>>> more sense after hearing implementation/deployment experiences, >>>> especially to correctly support important options we may have >>>> overlooked in the current schemes. Just redoing what we have differently >>>> to save 2.5 bits isn't worth it IMHO. >>>> >>>>>> Ultimately, we need to break through the chicken and egg problem >>>>>> of how to build more self-managing networks. These will require >>>>>> a different number of addresses inside nodes. Anything more intelligent >>>>>> than address space allocations would become a complex dependency >>>>>> making implementation/adoption even slower. I don't think that >>>>>> offering 2, 256, 64k addresses per node is too much flexibility. >>>>>> It IMHO necessary and sufficient to explore and we'll see what sticks. >>>>> >>>>> Variation is needed.  That was true of allocations in IP.  encoding the >>>>> variations proved a bad choice. >>>> >>>> Let me repeat that we are not doing any network/subnet prefix encoding which is >>>> what IPv4 A/B/C was. And there are IMHO good examples how encoding in IPv6 >>>> did save the day from complexity (at least all the stuff done for IPv6 >>>> multicast, ASM/SSM, zones, Embedded-RP) was highly useful. >>>> >>>>>>>        In section 6.11.1.11 in describing the prefix lengths, I thought that the >>>>>>>        point of zone addressing was to allow the use of /64 prefixes.  But it >>>>>>>        seems here that we will not do so ? >>>>>> >>>>>> As mentioned above: This document does not describe the routing setup for /64 >>>>>> (or /63 with Z-bit) routing aggregation. There are multiple options, >>>>>> but we could not conclude on a single solution that we felt to be >>>>>> appropriate for this document. Instead it was only very important >>>>>> to carve out addressing space to support this. >>>>> The net effect seems to be to prohibt the very things that you went to a lot >>>>> of trouble to enable in your addressing design. >>>> >>>> Maybe i do not understand your comment correctly, but i do not >>>> think it is correct. We just have not defined recommended mechanisms >>>> how to set up routing to use /64 zone routes. That is something IMHO >>>> better done in a followup document because all the cases where we >>>> did see a need for znes where really very specific to particular >>>> deployment styles and would not be applicable to the mayority of ACPs. >>>> Nevertheless, we felt those cases where important enough to reserve >>>> bits for them through the zone field. >>>> >>>>> ... >>>>>>> ***    Section 10.3.2 paragraph 2 says that devices should change the meaning >>>>>>> of "admin down" to mean "down for everything except ACP / Anima".    I can >>>>>>> understand why, in an autonomic network, such a state is desirable.  However, >>>>>>> that really should be a different state from "admin down".  Operators already >>>>>>> understand "admin down" as meaning that this interface will not be used for any >>>>>>> traffic.  Changing that is fairly drastic.  "admin limited" or "admin ACP-Only" >>>>>>> would seem much better than changing the meaning of "admin down".  The >>>>>>> justification in the text seems to be a desire to prevent an operator from >>>>>>> doing what he intends.  that seems backwards.  (Note that the distinction >>>>>>> between administrative state vs operational state, aka failed, is already well >>>>>>> understood.) >>>>>> >>>>>> Well, this is in an informative section, so hopefully something we can agree to disagree. >>>>> >>>>> If this were truly informative, it would not belong in this document at all. >>>>> Changing the behavior of widely understood configuration behaviors is NOT a >>>>> small thing.  Changing the permissions models for widely understood >>>>> configuration operations is also NOT a small thing. >>>>> >>>>> My suggestion is that you remove all of this material.  If you feel it is >>>>> important, write an I-D for standards track on evolving the configuration >>>>> model for robust ANIMA.  While I think the change is a mistake, you clearly >>>>> have the right to cause the discussion. >>>>> >>>>> Hiding the topic in an "informational" note in the ACP document seems VERY >>>>> wrong. >>>>> >>>>> Also note that in your discussion below, you talk about the equivalence of >>>>> admin down and physical down.  Most management models I know of treat these >>>>> as quite distinct.  SO that is at best a red herring. >>>> >>>> Hmm. I really only CLI derived from Cisco IOS, and there the >>>> interface level "shutdown" command doubles IMHO both as admin down and >>>> as phy down, so i would contend that this is a red herring. It actually >>>> does show up in diagnostic CLI as "admin down", but is also bringing down >>>> phy state. Therefore it is also used to diagnose phy, .e.g: shutting down >>>> one side of a supposed direct p2p link to verify the phy change on the >>>> other side. That practical experience is what the text and direction is >>>> based on. >>>> >>>> Whats an example where admin/phy down are separate in your experience ? >>>> >>>> I don't know how you define "truly informative". I simply meant >>>> informational as compared to standards track wrt. to not impacting >>>> interoperability, but also as a precursor work to give opportunity >>>> for gaining more experience before attempting to go standard. >>>> >>>> If/when i find time i definitely would like to investigate how this >>>> could be formalized through a YANG model for ACP so that it can become standard, >>>> but i definitely agree that especially this part of the YANG model would >>>> be highly difficult to get to before any experience is gained with >>>> this. >>>> >>>> I therefore would very much hesitate removing this text from the document, it was >>>> specifically asked for several times in the working group to understand >>>> how the promised reliability of the ACP against operator/contoller >>>> operation could be achieved. Having this in a first round (this document) >>>> as "informational" is IMHO a good and important thing. >>>> >>>>> (text retained for context of further discussions.) >>>>> >>>>>> >>>>>> I strongly believe that the most easy way to operationalize the ACP and >>>>>> achieve its goals is what we have written. >>>>>> >>>>>> The historic equivalence of "down" = "admin down" = "physical down" is one of >>>>>> the the most fundamental problem of remote management in networks. >>>>>> >>>>>> We really need to start thinking of separate layers of (remote) management. >>>>>> Network services on one hand and physical infra on the other. >>>>>> >>>>>> The first thing to do this is to separate operations such as "down" >>>>>> into "admin down" that affects networks services and "phy down" that >>>>>> affects the physcial infra. >>>>>> >>>>>> If you have existing commands like "shutdown" that today do both, >>>>>> the safe mapping is to let them do the safe thing in the future, e.g: >>>>>> only "admin down", and introduce new commands for the phy operations, >>>>>> e.g.: "phy shutdown" or the like. >>>>>> And then protect those dangerous commands even further against unintentional or >>>>>> intentional misuse. >>>>>> >>>>>> Think of ACP/ANI also as a seamless inband version of a DCN. As an operator >>>>>> of the actual data network, you also didn't have any access to bring down the DCN >>>>>> and cut yourself off from the network you manage. YOu could only screw >>>>>> up that network you're meant to manage. >>>>>> >>>>>> And if your network consists of VMs in a DC, a "shutdown" on their >>>>>> interfaces will also not bring down physical interfaces necessary >>>>>> to reach the VM. >>>>>> >>>>>> In optical networks you often have an inband physcial ethernet management >>>>>> channel. Making/breaking that one is completely different from making/breaking >>>>>> your data-plane, aka: data fiber colors. >>>>>> >>>>>>> ***    The notion in 10.3.6 that the device should refuse to disable >>>>>>> functionality when an authorized administrator directs such seems flatly wrong. >>>>>> >>>>>> The authorization to break your own remote management connectivity >>>>>> would be a property of the certificate. clearly whoever enrolled >>>>>> the device with a certificate denying that capaility to the operator >>>>>> did NOT authorize the administrator to break connectivity. >>>>> >>>>> The security model change seems as problematic as the above configuration >>>>> change. >>>> >>>> We have recurringly heard from customers that mistakes in managing remote >>>> equipment and loosing connectivity is a mayor pain point. Creating >>>> an operational option that limits/disables operators ability to >>>> impact phy level connectivity that remote management depends upon and therefore >>>> reducing this risk and cost factor seems to me like a very logical pah >>>> forward. Whether or not this should be indicated in the certificate >>>> or differently is definitely wide open. >>>> >>>> I agree that none of these operational interface level changes are >>>> a piece of cake given how we have in the IETF not tried to define >>>> different access levels to configuration so far, at least not >>>> between some phy/infra access level and network-services access level. >>>> >>>> As said above in my first reply that you didn't comment on, i think a >>>> good part of what i am looking for may happen through other means >>>> already, such as when a router is just a VM running on an OS. At least >>>> in early versions of this that i'd seen, this implicitly disabled >>>> the ability to modify phy state from the router VM, and of course >>>> complaints where raised that phy mods where necessary, but at least this >>>> evolution could give raise to pause and rethink HOW to permit doing this. >>>> >>>> So i would at least like to pledge with you that it is a good thing to >>>> have this type of discussion in an informational way in this RFC instead >>>> of doing nothing or trying to go standard YANG directly as a first step. >>>> It did get into the spec because of the desire of the working group. >>>> >>>>>>> Editorial / Nits: >>>>> . >>>>>>>        In the various formats in section 6.10, the lowest bit of the upper 64 bits >>>>>>>        is mandated to be 0.  Presumably, there is some reason for doing this.  It >>>>>>>        would be nice to explain it. >>>>>> >>>>>> Sorry, not clear what you're referring to. Can you give me an >>>>>> explicit reference ? >>>>> >>>>> I should ahve removed this note.  It was a side-effect of the presentation >>>>> and ordering, not a problem on its own.  Sorry. >>>> >>>> Cheers >>>>       Toerless >>>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> -- >> --- >> tte@cs.fau.de > From nobody Wed May 16 05:52:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2BE12D86F for ; Wed, 16 May 2018 05:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ietf.org header.b=CP7QBcw3; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ietf.org header.b=e700I7Tq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZeirv4s-l5p for ; Wed, 16 May 2018 05:52:03 -0700 (PDT) Received: from eu-smtp-delivery-152.mimecast.com (eu-smtp-delivery-152.mimecast.com [146.101.78.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC39412946D for ; Wed, 16 May 2018 05:52:02 -0700 (PDT) Received: from GLLDCSVPHYB01.gd.didata.local (185.3.28.51 [185.3.28.51]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-122-0eLZ2WbWMjyEDAog00OR2w-7; Wed, 16 May 2018 13:50:24 +0100 Received: from Pickup by GLLDCSVPHYB01.gd.didata.local with Microsoft SMTP Server id 14.3.319.2; Wed, 16 May 2018 00:20:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1526353117; bh=pA4Mxj0pSu3VkQcmz26CdXCx3TvwYg8Ok5XlpM7y32g=; h=Date:From:To:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=CP7QBcw37/tTVeTwMNITKB18O87czXDL1T+DTY9TYEr5cMIvCXEQeF3PVeg6IJiMn SAVntRsMuLFfA5AoU1l7muIVmhnMrS6v2VVfOWVAl2hrO/gInE5ZgqKH9fwXVXJDay CAiTCyilUieCzGjDgxKV1QBcTfd5nF/whc2wotzE= X-Mailbox-Line: From ietf-bounces@ietf.org Mon May 14 19:58:35 2018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1526353102; bh=pA4Mxj0pSu3VkQcmz26CdXCx3TvwYg8Ok5XlpM7y32g=; h=Date:From:To:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=e700I7Tq7sZCNIgEkMJR58Ousw6/o2i/knkCyCcC9OdhhP6nuENWUSA0QlCKUvcNQ zZiosn7qWm8nSI7JJ7xknimkbd6NlDILnfcf0KlvM7jR4zAiieKelFimH5GyJmkFE1 33vC4VpqtQzyiAydbYaRGb7lI7+5ampAhfTNi8I8= X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com Date: Tue, 15 May 2018 04:58:07 +0200 From: Toerless Eckert To: jmh.direct Message-ID: <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> References: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> MIME-Version: 1.0 In-Reply-To: <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list CC: , , , Errors-To: ietf-bounces@ietf.org Sender: ietf X-MC-Unique: WMkoXXmkNeu-GAey_eF8Qg-1 X-MC-Unique: 0eLZ2WbWMjyEDAog00OR2w-7 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 12:52:06 -0000 On Mon, May 14, 2018 at 08:49:56AM -0400, jmh.direct wrote: > I think the I understand what you describe. > As far as I can tell, the ACP DOES NOT AND SHOYLD NOT MANDATE > the address assignment mechanism.=A0 But it is the address assignment > mechanism that drives the address allocation. But that exactly is the conclusion of the multi-year ACP work in ANIMA WG. The ACP of an unconfigured, but only certificate enrolled device needs to be able to bring up routing and addressing for the ACP autonomically, aka: without any other dependencies. This ACP draft as it stands only depends on BRSKI and some unmodified CA to be implemented and deployed. There is no NOC with any address management functions required. At minimum, addressing is solely done from th registrar= , and you can have many registrars in a network and there is no chance for inconsistent address configuration. Please propose any other solution that you are thinking of in enough detail to discuss it, and i think we can show it has more, and often future/undefi= ned problems to be resolved.=20 > I would expect to find the address structure for autonomic addressed > in the same document as the mechanisms for autonomic address assignment. The ANIMA autonomic address asignment draft is relying on the ACP to be operational end-to-end to signal amongst its components via ACP GRASP the address/prefix assignments. It can by definition not be used to bring up=20 routing and addressing of the ACP itself. It likely also required more centralized functionality. For what it tries to do, it is elegant, flexible= and all that because it does not have to bother about bootstrap addressing and routing for itself as the ACP has to do. https://en.wikipedia.org/wiki/Bootstrapping#/media/File:Zentralbibliothek_S= olothurn_-_M%C3%BCnchhausen_zieht_sich_am_Zopf_aus_dem_Sumpf_-_a0400.tif BRSKI+ACP are doing what poor Muenchhausen is trying to do in what i think is a quite lightweight, very secure, scalable and for the job at hand (ugly) quite elegant way. > That is, why the routing scheme seemed confusing after the address alloca= tion scheme. If you can be more explicit about what you think is confusing, i am happy to make any confusing text better. Note that routing protocol/profile and addressing scheme are all subject to future enhancements easily. But in the design of anima, we would like to have operator defined address policy to be part of intent, and that would not only requir a lot more future work, it would also make addressing assigned this way less reliable and would not allow to use addresses managed dyanmically be used by components that are used to implem= ent the Intent infrastructure or any future ANI components (ASA etc.) that intent or address management depends on. Cheers Toerless > Yours,Joel >=20 >=20 > Sent via the Samsung Galaxy S=AE 6, an AT&T 4G LTE smartphone > -------- Original message --------From: Toerless Eckert D= ate: 5/14/18 05:04 (GMT-05:00) To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.o= rg, ietf@ietf.org, anima@ietf.org Subject: Re: [Anima] Rtgdir telechat revi= ew of > =A0 draft-ietf-anima-autonomic-control-plane-13=20 > a) Will try to do better explanation of identifier nature of addresses in > =A0=A0 next commit. >=20 > b) what do we loose if get rid of the choices. I kinda thought i had answ= ered > =A0=A0 this already, but i really don't know where your concern starts... >=20 > =A0=A0 1. We use ULA because we want to be able to bring up ACP networks = without > =A0=A0=A0=A0=A0 requiring a registry allocation of a prefix, and ULA is t= he correct > =A0=A0=A0=A0=A0 private address space. And deriving ULA Global ID from ha= sh of domain > =A0=A0=A0=A0=A0 name is nice. >=20 > =A0=A0=A0=A0=A0 Sounds as if you agree with this. > =A0=A0=A0=20 > =A0=A0 2. We want to be able to allocate addresses to ACP/ANI devices > =A0=A0=A0=A0=A0 without any additional configuration from multiple indepe= ndently > =A0=A0=A0=A0=A0 running registrars. Thats why the global unique ID of the= registrar > =A0=A0=A0=A0=A0 is part of the address in both zone and Vlong format. >=20 > =A0=A0=A0=A0=A0 Thats very fundamental to the ease of deployment of ACP/A= NI nodes > =A0=A0=A0=A0=A0 (i say ANI, because its really ACP+BRSKI required here to= get a simple standard > =A0=A0=A0=A0=A0=A0 solution to create the cert, otherwise youre down to a= vendor specific > =A0=A0=A0=A0=A0=A0 cert provisioning solution extended with ACP info supp= ort) >=20 > =A0=A0=A0=A0=A0 i hope this is uncontentuous > =A0=A0=20 > =A0=A0 3. a) We wanted to be able to support in the future "zone" =3D are= a/region-level > =A0=A0=A0=A0=A0 route aggregation, thats why the zone scheme reserves tho= se 13 bits. >=20 > =A0=A0=A0=A0=A0 b) We also know use cases where nodes need more than 2 ad= dresses, > =A0=A0=A0=A0=A0 thats why we have have the 8/16 bit Vlong option.=20 >=20 > =A0=A0=A0=A0=A0 c) We can not do everything autonomically (=3D=3D address= es assigned from registrars), > =A0=A0=A0=A0=A0 so we also reserve address space for traditional config (= manual address space). >=20 > =A0=A0=A0=A0=A0 Are these three sub-spaces zone,manual,vlong contenuous ? > =A0=A0=20 > =A0=A0 As mentioned in prior email if i wanted to avoid those ca. 3 bits = of > =A0=A0 format indication, i would need to indicate the semantic of addres= ses > =A0=A0 somehow differently to the nodes, e.g: via some extension to the A= CP format, > =A0=A0 but i would want to be able to signal the same information. >=20 > =A0=A0 So for example: because we have a standardized addressing scheme, > =A0=A0 a node that allows configuration of "ACP connect" can make sure > =A0=A0 that the address configured on an ACP cnnect interface can never b= e a ULA > =A0=A0 address that would conflict with an automatic ACP address assignme= nt done > =A0=A0 by a registrar. So i protect my autonomic address space from misco= nfiguration. > =A0=A0 Which is IMHO extremely important. So this is the key justificatio= n for > =A0=A0 the manual address space allocation.=20 >=20 > =A0=A0 Distinguishing between zone and Vlong address spaces is necessary = because > =A0=A0 we just can't fit zone, registrar-ID and node-number and 16 bit of= per-node bits > =A0=A0 into a single addressing scheme. >=20 > =A0=A0 E voila, three (IMHO: simpler) simple options. Likely networks wil= l use all three. > =20 > Cheers > =A0=A0=A0 Toerless >=20 > On Sun, May 13, 2018 at 07:38:35PM -0400, Joel M. Halpern wrote: > > Trimmed. > > Top posting for clarity.=A0 Mostly, agreement. > >=20 > > On the identifier vs locator, I think the way you are using the terms i= s > > confusing.=A0 But it is not worth continued argumentation.Some text > > elaborating along the lines you provide (retained below) would help. > > > > I have tried reading the section on addressing inside the ACP more > > carefully.=A0 Thank you for moving the Z bit. > > I have retained the earlier discussion on this topic below, in case we = still > > need it. > > Reading the section, I think that the problem is more basic. > >=20 > > I agree that the document needs to define that we are using a ULA.=A0 A= nd > > because of the certificate behaviors, there is significant advantage in > > defining what ULA prefix is used. > >=20 > > Given that, I do not see what use there is in all the other format > > definition.=A0 I suspect I am missing something very basic.=A0 Why not = leave > > this to the deploying operator?=A0 It is not like it can be autonomic, = since > > something has to tell the devices what format to use, and what numbers > > within some of the formats to use.=A0 I could imagine something that sa= id "in > > the absence of configuration, construct device addresses according to o= ne > > specific algorithm, so as to simplify bootstrap. > > But it would be a simple scheme. > > > >=20 > > On 5/11/18 10:09 PM, Toerless Eckert wrote: > > >=20 > > > Diff: > > >=20 > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.g= ithubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb4= 5209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-ani= ma-autonomic-control-plane-14.txt&url2=3Dhttps://raw.githubusercontent.com/= anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/d= raft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-= plane-14.txt > > >=20 > > > Latest version: > > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54= c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-p= lane/draft-ietf-anima-autonomic-control-plane-14.txt > > >=20 > > .... > > > Here are the things that make the ACP address an identifier to me: > > >=20 > > > - It is assigned once to the device and not meant to change over the = lifetime > > >=A0=A0=A0 of the device. > > > - It does not change when i move the node to a different location > > >=A0=A0=A0 and re-connect the device. > > > - It is the unique part of the ACP domain certificate (other than the= private key) > > >=A0=A0=A0 and used to identify the device (privat key is used to authe= nticate it, > > >=A0=A0=A0 but the private key may change over time, for example when r= enewing the certificate). > > >=20 > > > Would be happy to elaborate this in the doc more explicitly, e.g.: li= ke written > > > above. > >=20 > > (Context: Addressing inside the ACP.) > > > > Part of my reaction to this whole section is that it looks much lik= e the > > > > mistake we made originally in defining classful IP addresses.=A0 Yo= u are > > > > trying to guess the correct use cases, and defining specific addres= s > > > > structures with specific encodings for each one.=A0 With only a few= encodings > > > > available.=A0 This seems to be a recipe for being wrong later in wa= ys that > > > > hurt. > > >=20 > > > The only equivalent to classfull addressing i see is for the fixed pr= efix-length > > > handed out to each node, 1 bit (2 addresses) with zone addresses, 8/1= 6 bits > > > (256/64k address) for Vlong, but its NOT assignment to network segmen= ts > > > as in IPv4 A/B/C but to nodes. > > >=20 > > > We didn't introduce choices lightly. There are compromises to be made= when you > > > want some lightweight address allocation scheme, not expecting to hav= e complex > > > address registry or management system in the backend but simple regis= trars. > > >=20 > > > see below for more > > >=20 > > > > >=A0=A0=A0=A0=A0=A0=A0=A0 The difference in interpretation > > > > > >=A0=A0=A0=A0=A0=A0 is actually provided by the last bit in the u= pper 64.=A0 If these are the > > > > > >=A0=A0=A0=A0=A0=A0 same schema, then it should not need a bit to= differentiate them.=A0 They > > > > > >=A0=A0=A0=A0=A0=A0 should be explained as a single schema.=A0 Wh= ich would presumably result in > > > > > >=A0=A0=A0=A0=A0=A0 the Z bit being part of the zone / subnet fie= ld.=A0=A0 If they are two > > > > > >=A0=A0=A0=A0=A0=A0 different schemas, then move the differentiat= ion to part of the schema > > > > > >=A0=A0=A0=A0=A0=A0 identifier (making it 3 bits). > > > > >=20 > > > > > We did not want to make Z part of the base schemas 6.10.2 "Type" = code because > > > > > that would also make the Vlong scheme one bit shorter and that wo= uld reduce > > > > > virtualization space in Vlong by a factor of 2. > > > > >=20 > > > > > So, yes, encoding wise, 6.10.4 manual sub addressing space was ca= rved out > > > > > of the 6.10.3 zone address space via the Z bit, but thats just an= encoding aspect. > > > > >=20 > > > > > Functionally, 6.10.3/6.10.4 are quite different, and therefore it= is IMHO > > > > > textually correct to have them in different subsections. > > > > >=20 > > > > > Carving out bits like Z isn't ideal, but in between the ULA prefi= x, > > > > > the 64 bit local part we must have for external interfaces and > > > > > best utilization of bits, we tried to rather optimize address spa= ce > > > > > utilization and not beauty of encoding. > > > > >=20 > > > > > Having=A0 at the end allows (as written) use of /63 instead of=A0= 2 * /64 > > > > > routes. I am not sure how important this would be in the future. > > > > >=20 > > > > > If you feel strongly about more beauty in encoding, > > > > > i can move Z to the left and remove the notion of the possible /6= 3 route > > > > > optimization possible through the placement of Z. > > > >=20 > > > > Since the two different uses of the Z bit with type 00b are quite d= istinct, > > > > trying to enable aggregation seems counter-productive. > > > >=20 > > > > While I hate to push on a point you describe as aesthetics, having = the Z > > > > bit, occuring after the Zone / subnet-ID field, but defining whethe= r the > > > > field is a zone or a subnet, seems awkward for insufficient reason. > > > >=20 > > > > I would recommend moving the Z bit up so it is after the type, and = at the > > > > front of each of the two sections reiterate that this subscheme is = indicated > > > > by the Z bit being { 0 | 1 }. > > >=20 > > > Done. (see diff). > > >=20 > > > > > I very much hope there is no "interesting" implementation aspect; > > > > > nothing in the current scheme that makes implemenation harder. If= you > > > > > have an example that you fear, i would like to hear it. > > > > >=20 > > > > > To me, we are just defining address space allocation schemes. > > > >=20 > > > > I suppose likely implementations will use mask definitions that wil= l make it > > > > work.=A0 I pity the code reviewer. > > >=20 > > > I have read the code and tested in the lab IPv6 embedded RP adressing > > > and didn't feel pityfull about the job. But i weigh the overall syste= m > > > complexity. Embedded-RP simplified a lot of other parts of the > > > multicast system at the cost of introducing an addressing scheme. > > > I think similarily, the ACP addressing scheme simplifies the overall = system > > > complexity, especially registrars. > > >=20 > > > > > >=A0=A0=A0=A0=A0=A0 In section 6.10.5, after stating that it is n= ot even known what the needed > > > > > >=A0=A0=A0=A0=A0=A0 usage is for more V values > > > > >=20 > > > > > Which sentence are you referring to when you say "not even known = what the > > > > > needed usage is" ? I can't find it, but i would like to rectify i= t > > > > > if it actually is still there. > > > >=20 > > > > The text reads "further values use via definition in future work."= =A0 In the > > > > zone-id scheme, it is one bit.=A0 For some reason, it is 8 or 16 bi= ts here. > > >=20 > > > Thanks, changed sentence to: > > >=20 > > > V: Virtualization bit: Values 0 and 1 are assigned in the same way as= in the Zone-ID sub-scheme. > > >=20 > > > The existing text, now directly after the list, explains examples > > > when a device would likely need 256 or 64k addresses: > > >=20 > > > existing text: > > > ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge = nodes ... > > >=20 > > > > > >=A0=A0=A0=A0=A0=A0 the document goes on to introduce the > > > > > >=A0=A0=A0=A0=A0=A0 complexity of classful nodes numbers, with th= e leading bit indicating how > > > > > >=A0=A0=A0=A0=A0=A0 long the node-number is.=A0 Yes, the rest of = the text in that bullet tries to > > > > > >=A0=A0=A0=A0=A0=A0 explain why you need both sizes.=A0 It seems = like needless complexity that > > > > > >=A0=A0=A0=A0=A0=A0 begs for mistakes in implementation. > > > > >=20 > > > > > I was taking the example use cases we brainstormed into account, = and > > > > > some of them=A0 would require a lot more addresses in the node th= an others, > > > > > therefore these two choices. > > > >=20 > > > > See my comments above.=A0 Trying to encode specific use cases into = the address > > > > format seems a problematic answer to an admittedly difficult questi= on. > > > >=20 > > > > What would break if you didn't define any of this? > > >=20 > > > One could save the 2.5 bits (Type, Z) indicating the structure of the > > > address inside the address by encoding the designated format of the > > > address instead in an extension field of the ACP address information = in > > > the certificate. We would certainly still want to have the same type > > > of addresses, e.g.: 2,256,64k local addresses, option for zones and > > > address to assign to ACP connect interfaces (manual addressing scheme= ) > > > IMHO. So, at best we could save the 2.5 bits if we wanted to keep the > > > functionality, which i think is all required. > > >=20 > > > I would be quite afraid of doing such a drastic change this late in > > > the process because i think it will take a long time to foresee the > > > resulting complexity introduced for registars and any other place > > > that now can deduct the semantic from the address and would then have > > > to access to what the certificate indicates in a different way (e.g.: > > > access to the certificate). Note that the length of the ACP informati= on > > > field in the cert is also limited, so this type of extension might en= d > > > up looking even uglier to be short *sigh*. > > >=20 > > > I was always thinking that this type of more flexible option would > > > be a good next-step, but not a safe first step. It would make a lot > > > more sense after hearing implementation/deployment experiences, > > > especially to correctly support important options we may have > > > overlooked in the current schemes. Just redoing what we have differen= tly > > > to save 2.5 bits isn't worth it IMHO. > > >=20 > > > > > Ultimately, we need to break through the chicken and egg problem > > > > > of how to build more self-managing networks. These will require > > > > > a different number of addresses inside nodes. Anything more intel= ligent > > > > > than address space allocations would become a complex dependency > > > > > making implementation/adoption even slower. I don't think that > > > > > offering 2, 256, 64k addresses per node is too much flexibility. > > > > > It IMHO necessary and sufficient to explore and we'll see what st= icks. > > > >=20 > > > > Variation is needed.=A0 That was true of allocations in IP.=A0 enco= ding the > > > > variations proved a bad choice. > > >=20 > > > Let me repeat that we are not doing any network/subnet prefix encodin= g which is > > > what IPv4 A/B/C was. And there are IMHO good examples how encoding in= IPv6 > > > did save the day from complexity (at least all the stuff done for IPv= 6 > > > multicast, ASM/SSM, zones, Embedded-RP) was highly useful. > > >=20 > > > > > >=A0=A0=A0=A0=A0=A0 In section 6.11.1.11 in describing the prefix= lengths, I thought that the > > > > > >=A0=A0=A0=A0=A0=A0 point of zone addressing was to allow the use= of /64 prefixes.=A0 But it > > > > > >=A0=A0=A0=A0=A0=A0 seems here that we will not do so ? > > > > >=20 > > > > > As mentioned above: This document does not describe the routing s= etup for /64 > > > > > (or /63 with Z-bit) routing aggregation. There are multiple optio= ns, > > > > > but we could not conclude on a single solution that we felt to be > > > > > appropriate for this document. Instead it was only very important > > > > > to carve out addressing space to support this. > > > > The net effect seems to be to prohibt the very things that you went= to a lot > > > > of trouble to enable in your addressing design. > > >=20 > > > Maybe i do not understand your comment correctly, but i do not > > > think it is correct. We just have not defined recommended mechanisms > > > how to set up routing to use /64 zone routes. That is something IMHO > > > better done in a followup document because all the cases where we > > > did see a need for znes where really very specific to particular > > > deployment styles and would not be applicable to the mayority of ACPs= . > > > Nevertheless, we felt those cases where important enough to reserve > > > bits for them through the zone field. > > >=20 > > > > ... > > > > > > ***=A0=A0=A0 Section 10.3.2 paragraph 2 says that devices shoul= d change the meaning > > > > > > of "admin down" to mean "down for everything except ACP / Anima= ".=A0=A0=A0 I can > > > > > > understand why, in an autonomic network, such a state is desira= ble.=A0 However, > > > > > > that really should be a different state from "admin down".=A0 O= perators already > > > > > > understand "admin down" as meaning that this interface will not= be used for any > > > > > > traffic.=A0 Changing that is fairly drastic.=A0 "admin limited"= or "admin ACP-Only" > > > > > > would seem much better than changing the meaning of "admin down= ".=A0 The > > > > > > justification in the text seems to be a desire to prevent an op= erator from > > > > > > doing what he intends.=A0 that seems backwards.=A0 (Note that t= he distinction > > > > > > between administrative state vs operational state, aka failed, = is already well > > > > > > understood.) > > > > >=20 > > > > > Well, this is in an informative section, so hopefully something w= e can agree to disagree. > > > >=20 > > > > If this were truly informative, it would not belong in this documen= t at all. > > > > Changing the behavior of widely understood configuration behaviors = is NOT a > > > > small thing.=A0 Changing the permissions models for widely understo= od > > > > configuration operations is also NOT a small thing. > > > >=20 > > > > My suggestion is that you remove all of this material.=A0 If you fe= el it is > > > > important, write an I-D for standards track on evolving the configu= ration > > > > model for robust ANIMA.=A0 While I think the change is a mistake, y= ou clearly > > > > have the right to cause the discussion. > > > >=20 > > > > Hiding the topic in an "informational" note in the ACP document see= ms VERY > > > > wrong. > > > >=20 > > > > Also note that in your discussion below, you talk about the equival= ence of > > > > admin down and physical down.=A0 Most management models I know of t= reat these > > > > as quite distinct.=A0 SO that is at best a red herring. > > >=20 > > > Hmm. I really only CLI derived from Cisco IOS, and there the > > > interface level "shutdown" command doubles IMHO both as admin down an= d > > > as phy down, so i would contend that this is a red herring. It actual= ly > > > does show up in diagnostic CLI as "admin down", but is also bringing = down > > > phy state. Therefore it is also used to diagnose phy, .e.g: shutting = down > > > one side of a supposed direct p2p link to verify the phy change on th= e > > > other side. That practical experience is what the text and direction = is > > > based on. > > >=20 > > > Whats an example where admin/phy down are separate in your experience= ? > > >=20 > > > I don't know how you define "truly informative". I simply meant > > > informational as compared to standards track wrt. to not impacting > > > interoperability, but also as a precursor work to give opportunity > > > for gaining more experience before attempting to go standard. > > >=20 > > > If/when i find time i definitely would like to investigate how this > > > could be formalized through a YANG model for ACP so that it can becom= e standard, > > > but i definitely agree that especially this part of the YANG model wo= uld > > > be highly difficult to get to before any experience is gained with > > > this. > > >=20 > > > I therefore would very much hesitate removing this text from the docu= ment, it was > > > specifically asked for several times in the working group to understa= nd > > > how the promised reliability of the ACP against operator/contoller > > > operation could be achieved. Having this in a first round (this docum= ent) > > > as "informational" is IMHO a good and important thing. > > >=20 > > > > (text retained for context of further discussions.) > > > >=20 > > > > >=20 > > > > > I strongly believe that the most easy way to operationalize the A= CP and > > > > > achieve its goals is what we have written. > > > > >=20 > > > > > The historic equivalence of "down" =3D "admin down" =3D "physical= down" is one of > > > > > the the most fundamental problem of remote management in networks= . > > > > >=20 > > > > > We really need to start thinking of separate layers of (remote) m= anagement. > > > > > Network services on one hand and physical infra on the other. > > > > >=20 > > > > > The first thing to do this is to separate operations such as "dow= n" > > > > > into "admin down" that affects networks services and "phy down" t= hat > > > > > affects the physcial infra. > > > > >=20 > > > > > If you have existing commands like "shutdown" that today do both, > > > > > the safe mapping is to let them do the safe thing in the future, = e.g: > > > > > only "admin down", and introduce new commands for the phy operati= ons, > > > > > e.g.: "phy shutdown" or the like. > > > > > And then protect those dangerous commands even further against un= intentional or > > > > > intentional misuse. > > > > >=20 > > > > > Think of ACP/ANI also as a seamless inband version of a DCN. As a= n operator > > > > > of the actual data network, you also didn't have any access to br= ing down the DCN > > > > > and cut yourself off from the network you manage. YOu could only = screw > > > > > up that network you're meant to manage. > > > > >=20 > > > > > And if your network consists of VMs in a DC, a "shutdown" on thei= r > > > > > interfaces will also not bring down physical interfaces necessary > > > > > to reach the VM. > > > > >=20 > > > > > In optical networks you often have an inband physcial ethernet ma= nagement > > > > > channel. Making/breaking that one is completely different from ma= king/breaking > > > > > your data-plane, aka: data fiber colors. > > > > >=20 > > > > > > ***=A0=A0=A0 The notion in 10.3.6 that the device should refuse= to disable > > > > > > functionality when an authorized administrator directs such see= ms flatly wrong. > > > > >=20 > > > > > The authorization to break your own remote management connectivit= y > > > > > would be a property of the certificate. clearly whoever enrolled > > > > > the device with a certificate denying that capaility to the opera= tor > > > > > did NOT authorize the administrator to break connectivity. > > > >=20 > > > > The security model change seems as problematic as the above configu= ration > > > > change. > > >=20 > > > We have recurringly heard from customers that mistakes in managing re= mote > > > equipment and loosing connectivity is a mayor pain point. Creating > > > an operational option that limits/disables operators ability to > > > impact phy level connectivity that remote management depends upon and= therefore > > > reducing this risk and cost factor seems to me like a very logical pa= h > > > forward. Whether or not this should be indicated in the certificate > > > or differently is definitely wide open. > > >=20 > > > I agree that none of these operational interface level changes are > > > a piece of cake given how we have in the IETF not tried to define > > > different access levels to configuration so far, at least not > > > between some phy/infra access level and network-services access level= . > > >=20 > > > As said above in my first reply that you didn't comment on, i think a > > > good part of what i am looking for may happen through other means > > > already, such as when a router is just a VM running on an OS. At leas= t > > > in early versions of this that i'd seen, this implicitly disabled > > > the ability to modify phy state from the router VM, and of course > > > complaints where raised that phy mods where necessary, but at least t= his > > > evolution could give raise to pause and rethink HOW to permit doing t= his. > > >=20 > > > So i would at least like to pledge with you that it is a good thing t= o > > > have this type of discussion in an informational way in this RFC inst= ead > > > of doing nothing or trying to go standard YANG directly as a first st= ep. > > > It did get into the spec because of the desire of the working group. > > >=20 > > > > > > Editorial / Nits: > > > > . > > > > > >=A0=A0=A0=A0=A0=A0 In the various formats in section 6.10, the l= owest bit of the upper 64 bits > > > > > >=A0=A0=A0=A0=A0=A0 is mandated to be 0.=A0 Presumably, there is = some reason for doing this.=A0 It > > > > > >=A0=A0=A0=A0=A0=A0 would be nice to explain it. > > > > >=20 > > > > > Sorry, not clear what you're referring to. Can you give me an > > > > > explicit reference ? > > > >=20 > > > > I should ahve removed this note.=A0 It was a side-effect of the pre= sentation > > > > and ordering, not a problem on its own.=A0 Sorry. > > >=20 > > > Cheers > > >=A0=A0=A0=A0=A0 Toerless > > >=20 > >=20 > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima >=20 > --=20 > --- > tte@cs.fau.de --=20 --- tte@cs.fau.de From nobody Wed May 16 07:22:21 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B63127078 for ; Wed, 16 May 2018 07:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ietf.org header.b=o6BVN0ze; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ietf.org header.b=cPhU11Wt; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=joelhalpern.com header.b=nObegbt8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFRhMbDTz1vl for ; Wed, 16 May 2018 07:22:15 -0700 (PDT) Received: from eu-smtp-delivery-152.mimecast.com (eu-smtp-delivery-152.mimecast.com [207.82.80.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C156D12D7E6 for ; Wed, 16 May 2018 07:22:14 -0700 (PDT) Received: from GLLDCSVPHYB01.gd.didata.local (185.3.28.51 [185.3.28.51]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-9-pSRqiSRTOnKVRpaPJqpo-g-2; Wed, 16 May 2018 15:21:02 +0100 Received: from Pickup by GLLDCSVPHYB01.gd.didata.local with Microsoft SMTP Server id 14.3.319.2; Wed, 16 May 2018 02:03:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1526354184; bh=zN2plqlCH+U1sFWmrZZrt+/W5h0J1+dMszZOCqwI7eU=; h=Subject:To:References:From:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=o6BVN0zetDCH031B+rhb6X2pFTGzMnZYZ9+k1RJkjg62/8hJKzykqqxuxxdVcFYir +4IVtvFyrsgjKHU+7VfKVAFwGZXgoVyG7L0Aqf8CjhgtT4QBrkh2Pn5aoE5Y1j3COk nPmoAIzMlD0KUNSsVT4Axqfh2RlAsPyytj8pBCcE= X-Mailbox-Line: From ietf-bounces@ietf.org Mon May 14 20:16:22 2018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1526354169; bh=zN2plqlCH+U1sFWmrZZrt+/W5h0J1+dMszZOCqwI7eU=; h=Subject:To:References:From:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=cPhU11WtV9Dri5MKRkyatJL5uJ2wWyotXJpyLlahtF086s2BIMiJW0D0K4+Vcwtrk ujrCCkhPopXbx6mlKBkBfqdxqR1EZcBkw5BZz8qELnbBM1RHjenmZjRAR3gFAFXstk 8PuxAvwYzNi8ra0n2rC3sHxNx2D6WPfo+9SwwlI8= X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1526354160; bh=7WID3Q0xb14cwWhrd8WhYebrfaCV0Oo3knqVvMgm2Sc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nObegbt8ElFl+2mGyfF0biAXb4OeoKaOH1fY85XtysYBYdhSuvfoxfFy+QuSW6Z86 KTFZhigTUUMk7HaNIpSJmbbhIstV/ctFrL0hzG6lm61gWVBnS4OXbpdC9WoG0DNr1G d+j3F1Ztnsp/3y8jeCMZ/HzNrwR+8/BVBeemAP1A= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net To: Toerless Eckert References: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: <6c4f9527-1b96-9c14-ffe0-186a24eb9793@joelhalpern.com> Date: Mon, 14 May 2018 23:15:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list CC: , , , Errors-To: ietf-bounces@ietf.org Sender: ietf X-MC-Unique: 0YCXMNlIM3usYiii_H7rKQ-1 X-MC-Unique: pSRqiSRTOnKVRpaPJqpo-g-2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 14:22:20 -0000 (Sorry about the excess caps. Did not intentd to shout.) From some off-line disucssions, I understand that the actual address=20 allocation is tied to the registration process. The registration=20 process is not described in this document. As far as I can tell, the ACP does not depend upon the address=20 allocation strategy. The address allocation strategy does require the=20 ACP. And it requires and is closely coupled to the registration process. If that is true, the address allocation seems to be better described=20 with the registration process. Which I presume is in the BRSKI document. All I would put in here is the basic ULA allocation (hash based=20 generation) mechanism. Yours, Joel On 5/14/18 10:58 PM, Toerless Eckert wrote: > On Mon, May 14, 2018 at 08:49:56AM -0400, jmh.direct wrote: >> I think the I understand what you describe. >> As far as I can tell, the ACP DOES NOT AND SHOYLD NOT MANDATE >> the address assignment mechanism.=C2=A0 But it is the address assignment >> mechanism that drives the address allocation. >=20 > But that exactly is the conclusion of the multi-year ACP work in ANIMA WG= . > The ACP of an unconfigured, but only certificate enrolled device needs to > be able to bring up routing and addressing for the ACP autonomically, > aka: without any other dependencies. >=20 > This ACP draft as it stands only depends on BRSKI and some unmodified CA > to be implemented and deployed. There is no NOC with any address manageme= nt > functions required. At minimum, addressing is solely done from th registr= ar, > and you can have many registrars in a network and there is no chance > for inconsistent address configuration. >=20 > Please propose any other solution that you are thinking of in enough deta= il > to discuss it, and i think we can show it has more, and often future/unde= fined > problems to be resolved. >=20 >> I would expect to find the address structure for autonomic addressed >> in the same document as the mechanisms for autonomic address assignment. >=20 > The ANIMA autonomic address asignment draft is relying on the ACP to be > operational end-to-end to signal amongst its components via ACP GRASP the > address/prefix assignments. It can by definition not be used to bring up > routing and addressing of the ACP itself. It likely also required more > centralized functionality. For what it tries to do, it is elegant, flexib= le and > all that because it does not have to bother about bootstrap addressing an= d > routing for itself as the ACP has to do. >=20 > https://en.wikipedia.org/wiki/Bootstrapping#/media/File:Zentralbibliothek= _Solothurn_-_M%C3%BCnchhausen_zieht_sich_am_Zopf_aus_dem_Sumpf_-_a0400.tif >=20 > BRSKI+ACP are doing what poor Muenchhausen is trying to do in > what i think is a quite lightweight, very secure, scalable and > for the job at hand (ugly) quite elegant way. >=20 >> That is, why the routing scheme seemed confusing after the address alloc= ation scheme. >=20 > If you can be more explicit about what you think is confusing, i am > happy to make any confusing text better. >=20 > Note that routing protocol/profile and addressing scheme are all subject > to future enhancements easily. But in the design of anima, we would like > to have operator defined address policy to be part of intent, and > that would not only requir a lot more future work, it would also make > addressing assigned this way less reliable and would not allow to use > addresses managed dyanmically be used by components that are used to impl= ement > the Intent infrastructure or any future ANI components (ASA etc.) that > intent or address management depends on. >=20 > Cheers > Toerless >=20 >> Yours,Joel >> >> >> Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone >> -------- Original message --------From: Toerless Eckert = Date: 5/14/18 05:04 (GMT-05:00) To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.= org, ietf@ietf.org, anima@ietf.org Subject: Re: [Anima] Rtgdir telechat rev= iew of >> =C2=A0 draft-ietf-anima-autonomic-control-plane-13 >> a) Will try to do better explanation of identifier nature of addresses i= n >> =C2=A0=C2=A0 next commit. >> >> b) what do we loose if get rid of the choices. I kinda thought i had ans= wered >> =C2=A0=C2=A0 this already, but i really don't know where your concern s= tarts... >> >> =C2=A0=C2=A0 1. We use ULA because we want to be able to bring up ACP n= etworks without >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 requiring a registry allocation of a pre= fix, and ULA is the correct >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 private address space. And deriving ULA = Global ID from hash of domain >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name is nice. >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sounds as if you agree with this. >> =20 >> =C2=A0=C2=A0 2. We want to be able to allocate addresses to ACP/ANI dev= ices >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 without any additional configuration fro= m multiple independently >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 running registrars. Thats why the global= unique ID of the registrar >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is part of the address in both zone and = Vlong format. >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thats very fundamental to the ease of de= ployment of ACP/ANI nodes >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (i say ANI, because its really ACP+BRSKI= required here to get a simple standard >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 solution to create the cert, other= wise youre down to a vendor specific >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cert provisioning solution extende= d with ACP info support) >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i hope this is uncontentuous >> =20 >> =C2=A0=C2=A0 3. a) We wanted to be able to support in the future "zone"= =3D area/region-level >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 route aggregation, thats why the zone sc= heme reserves those 13 bits. >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b) We also know use cases where nodes ne= ed more than 2 addresses, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 thats why we have have the 8/16 bit Vlon= g option. >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c) We can not do everything autonomicall= y (=3D=3D addresses assigned from registrars), >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so we also reserve address space for tra= ditional config (manual address space). >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Are these three sub-spaces zone,manual,v= long contenuous ? >> =20 >> =C2=A0=C2=A0 As mentioned in prior email if i wanted to avoid those ca.= 3 bits of >> =C2=A0=C2=A0 format indication, i would need to indicate the semantic o= f addresses >> =C2=A0=C2=A0 somehow differently to the nodes, e.g: via some extension = to the ACP format, >> =C2=A0=C2=A0 but i would want to be able to signal the same information= . >> >> =C2=A0=C2=A0 So for example: because we have a standardized addressing = scheme, >> =C2=A0=C2=A0 a node that allows configuration of "ACP connect" can make= sure >> =C2=A0=C2=A0 that the address configured on an ACP cnnect interface can= never be a ULA >> =C2=A0=C2=A0 address that would conflict with an automatic ACP address = assignment done >> =C2=A0=C2=A0 by a registrar. So i protect my autonomic address space fr= om misconfiguration. >> =C2=A0=C2=A0 Which is IMHO extremely important. So this is the key just= ification for >> =C2=A0=C2=A0 the manual address space allocation. >> >> =C2=A0=C2=A0 Distinguishing between zone and Vlong address spaces is ne= cessary because >> =C2=A0=C2=A0 we just can't fit zone, registrar-ID and node-number and 1= 6 bit of per-node bits >> =C2=A0=C2=A0 into a single addressing scheme. >> >> =C2=A0=C2=A0 E voila, three (IMHO: simpler) simple options. Likely netw= orks will use all three. >> =20 >> Cheers >> =C2=A0=C2=A0=C2=A0 Toerless >> >> On Sun, May 13, 2018 at 07:38:35PM -0400, Joel M. Halpern wrote: >>> Trimmed. >>> Top posting for clarity.=C2=A0 Mostly, agreement. >>> >>> On the identifier vs locator, I think the way you are using the terms i= s >>> confusing.=C2=A0 But it is not worth continued argumentation.Some text >>> elaborating along the lines you provide (retained below) would help. >>> >>> I have tried reading the section on addressing inside the ACP more >>> carefully.=C2=A0 Thank you for moving the Z bit. >>> I have retained the earlier discussion on this topic below, in case we = still >>> need it. >>> Reading the section, I think that the problem is more basic. >>> >>> I agree that the document needs to define that we are using a ULA.=C2= =A0 And >>> because of the certificate behaviors, there is significant advantage in >>> defining what ULA prefix is used. >>> >>> Given that, I do not see what use there is in all the other format >>> definition.=C2=A0 I suspect I am missing something very basic.=C2=A0 Wh= y not leave >>> this to the deploying operator?=C2=A0 It is not like it can be autonomi= c, since >>> something has to tell the devices what format to use, and what numbers >>> within some of the formats to use.=C2=A0 I could imagine something that= said "in >>> the absence of configuration, construct device addresses according to o= ne >>> specific algorithm, so as to simplify bootstrap. >>> But it would be a simple scheme. >>> >>> >>> On 5/11/18 10:09 PM, Toerless Eckert wrote: >>>> >>>> Diff: >>>> >>>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.gi= thubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45= 209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anim= a-autonomic-control-plane-14.txt&url2=3Dhttps://raw.githubusercontent.com/a= nima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/dr= aft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-p= lane-14.txt >>>> >>>> Latest version: >>>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c= 9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-pl= ane/draft-ietf-anima-autonomic-control-plane-14.txt >>>> >>> .... >>>> Here are the things that make the ACP address an identifier to me: >>>> >>>> - It is assigned once to the device and not meant to change over the l= ifetime >>>> =C2=A0=C2=A0=C2=A0 of the device. >>>> - It does not change when i move the node to a different location >>>> =C2=A0=C2=A0=C2=A0 and re-connect the device. >>>> - It is the unique part of the ACP domain certificate (other than the = private key) >>>> =C2=A0=C2=A0=C2=A0 and used to identify the device (privat key is use= d to authenticate it, >>>> =C2=A0=C2=A0=C2=A0 but the private key may change over time, for exam= ple when renewing the certificate). >>>> >>>> Would be happy to elaborate this in the doc more explicitly, e.g.: lik= e written >>>> above. >>> >>> (Context: Addressing inside the ACP.) >>>>> Part of my reaction to this whole section is that it looks much like = the >>>>> mistake we made originally in defining classful IP addresses.=C2=A0 Y= ou are >>>>> trying to guess the correct use cases, and defining specific address >>>>> structures with specific encodings for each one.=C2=A0 With only a fe= w encodings >>>>> available.=C2=A0 This seems to be a recipe for being wrong later in w= ays that >>>>> hurt. >>>> >>>> The only equivalent to classfull addressing i see is for the fixed pre= fix-length >>>> handed out to each node, 1 bit (2 addresses) with zone addresses, 8/16= bits >>>> (256/64k address) for Vlong, but its NOT assignment to network segment= s >>>> as in IPv4 A/B/C but to nodes. >>>> >>>> We didn't introduce choices lightly. There are compromises to be made = when you >>>> want some lightweight address allocation scheme, not expecting to have= complex >>>> address registry or management system in the backend but simple regist= rars. >>>> >>>> see below for more >>>> >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The difference in = interpretation >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is actually provided by the l= ast bit in the upper 64.=C2=A0 If these are the >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 same schema, then it should n= ot need a bit to differentiate them.=C2=A0 They >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 should be explained as a sing= le schema.=C2=A0 Which would presumably result in >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Z bit being part of the z= one / subnet field.=C2=A0=C2=A0 If they are two >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different schemas, then move = the differentiation to part of the schema >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identifier (making it 3 bits)= . >>>>>> >>>>>> We did not want to make Z part of the base schemas 6.10.2 "Type" cod= e because >>>>>> that would also make the Vlong scheme one bit shorter and that would= reduce >>>>>> virtualization space in Vlong by a factor of 2. >>>>>> >>>>>> So, yes, encoding wise, 6.10.4 manual sub addressing space was carve= d out >>>>>> of the 6.10.3 zone address space via the Z bit, but thats just an en= coding aspect. >>>>>> >>>>>> Functionally, 6.10.3/6.10.4 are quite different, and therefore it is= IMHO >>>>>> textually correct to have them in different subsections. >>>>>> >>>>>> Carving out bits like Z isn't ideal, but in between the ULA prefix, >>>>>> the 64 bit local part we must have for external interfaces and >>>>>> best utilization of bits, we tried to rather optimize address space >>>>>> utilization and not beauty of encoding. >>>>>> >>>>>> Having=C2=A0 at the end allows (as written) use of /63 instead of=C2= =A0 2 * /64 >>>>>> routes. I am not sure how important this would be in the future. >>>>>> >>>>>> If you feel strongly about more beauty in encoding, >>>>>> i can move Z to the left and remove the notion of the possible /63 r= oute >>>>>> optimization possible through the placement of Z. >>>>> >>>>> Since the two different uses of the Z bit with type 00b are quite dis= tinct, >>>>> trying to enable aggregation seems counter-productive. >>>>> >>>>> While I hate to push on a point you describe as aesthetics, having th= e Z >>>>> bit, occuring after the Zone / subnet-ID field, but defining whether = the >>>>> field is a zone or a subnet, seems awkward for insufficient reason. >>>>> >>>>> I would recommend moving the Z bit up so it is after the type, and at= the >>>>> front of each of the two sections reiterate that this subscheme is in= dicated >>>>> by the Z bit being { 0 | 1 }. >>>> >>>> Done. (see diff). >>>> >>>>>> I very much hope there is no "interesting" implementation aspect; >>>>>> nothing in the current scheme that makes implemenation harder. If yo= u >>>>>> have an example that you fear, i would like to hear it. >>>>>> >>>>>> To me, we are just defining address space allocation schemes. >>>>> >>>>> I suppose likely implementations will use mask definitions that will = make it >>>>> work.=C2=A0 I pity the code reviewer. >>>> >>>> I have read the code and tested in the lab IPv6 embedded RP adressing >>>> and didn't feel pityfull about the job. But i weigh the overall system >>>> complexity. Embedded-RP simplified a lot of other parts of the >>>> multicast system at the cost of introducing an addressing scheme. >>>> I think similarily, the ACP addressing scheme simplifies the overall s= ystem >>>> complexity, especially registrars. >>>> >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In section 6.10.5, after stat= ing that it is not even known what the needed >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 usage is for more V values >>>>>> >>>>>> Which sentence are you referring to when you say "not even known wha= t the >>>>>> needed usage is" ? I can't find it, but i would like to rectify it >>>>>> if it actually is still there. >>>>> >>>>> The text reads "further values use via definition in future work."=C2= =A0 In the >>>>> zone-id scheme, it is one bit.=C2=A0 For some reason, it is 8 or 16 b= its here. >>>> >>>> Thanks, changed sentence to: >>>> >>>> V: Virtualization bit: Values 0 and 1 are assigned in the same way as = in the Zone-ID sub-scheme. >>>> >>>> The existing text, now directly after the list, explains examples >>>> when a device would likely need 256 or 64k addresses: >>>> >>>> existing text: >>>> ..."1" bit Node-Numbers are intended for ACP nodes that are ACP edge n= odes ... >>>> >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the document goes on to intro= duce the >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 complexity of classful nodes = numbers, with the leading bit indicating how >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 long the node-number is.=C2= =A0 Yes, the rest of the text in that bullet tries to >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 explain why you need both siz= es.=C2=A0 It seems like needless complexity that >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 begs for mistakes in implemen= tation. >>>>>> >>>>>> I was taking the example use cases we brainstormed into account, and >>>>>> some of them=C2=A0 would require a lot more addresses in the node th= an others, >>>>>> therefore these two choices. >>>>> >>>>> See my comments above.=C2=A0 Trying to encode specific use cases into= the address >>>>> format seems a problematic answer to an admittedly difficult question= . >>>>> >>>>> What would break if you didn't define any of this? >>>> >>>> One could save the 2.5 bits (Type, Z) indicating the structure of the >>>> address inside the address by encoding the designated format of the >>>> address instead in an extension field of the ACP address information i= n >>>> the certificate. We would certainly still want to have the same type >>>> of addresses, e.g.: 2,256,64k local addresses, option for zones and >>>> address to assign to ACP connect interfaces (manual addressing scheme) >>>> IMHO. So, at best we could save the 2.5 bits if we wanted to keep the >>>> functionality, which i think is all required. >>>> >>>> I would be quite afraid of doing such a drastic change this late in >>>> the process because i think it will take a long time to foresee the >>>> resulting complexity introduced for registars and any other place >>>> that now can deduct the semantic from the address and would then have >>>> to access to what the certificate indicates in a different way (e.g.: >>>> access to the certificate). Note that the length of the ACP informatio= n >>>> field in the cert is also limited, so this type of extension might end >>>> up looking even uglier to be short *sigh*. >>>> >>>> I was always thinking that this type of more flexible option would >>>> be a good next-step, but not a safe first step. It would make a lot >>>> more sense after hearing implementation/deployment experiences, >>>> especially to correctly support important options we may have >>>> overlooked in the current schemes. Just redoing what we have different= ly >>>> to save 2.5 bits isn't worth it IMHO. >>>> >>>>>> Ultimately, we need to break through the chicken and egg problem >>>>>> of how to build more self-managing networks. These will require >>>>>> a different number of addresses inside nodes. Anything more intellig= ent >>>>>> than address space allocations would become a complex dependency >>>>>> making implementation/adoption even slower. I don't think that >>>>>> offering 2, 256, 64k addresses per node is too much flexibility. >>>>>> It IMHO necessary and sufficient to explore and we'll see what stick= s. >>>>> >>>>> Variation is needed.=C2=A0 That was true of allocations in IP.=C2=A0 = encoding the >>>>> variations proved a bad choice. >>>> >>>> Let me repeat that we are not doing any network/subnet prefix encoding= which is >>>> what IPv4 A/B/C was. And there are IMHO good examples how encoding in = IPv6 >>>> did save the day from complexity (at least all the stuff done for IPv6 >>>> multicast, ASM/SSM, zones, Embedded-RP) was highly useful. >>>> >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In section 6.11.1.11 in descr= ibing the prefix lengths, I thought that the >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 point of zone addressing was = to allow the use of /64 prefixes.=C2=A0 But it >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 seems here that we will not d= o so ? >>>>>> >>>>>> As mentioned above: This document does not describe the routing setu= p for /64 >>>>>> (or /63 with Z-bit) routing aggregation. There are multiple options, >>>>>> but we could not conclude on a single solution that we felt to be >>>>>> appropriate for this document. Instead it was only very important >>>>>> to carve out addressing space to support this. >>>>> The net effect seems to be to prohibt the very things that you went t= o a lot >>>>> of trouble to enable in your addressing design. >>>> >>>> Maybe i do not understand your comment correctly, but i do not >>>> think it is correct. We just have not defined recommended mechanisms >>>> how to set up routing to use /64 zone routes. That is something IMHO >>>> better done in a followup document because all the cases where we >>>> did see a need for znes where really very specific to particular >>>> deployment styles and would not be applicable to the mayority of ACPs. >>>> Nevertheless, we felt those cases where important enough to reserve >>>> bits for them through the zone field. >>>> >>>>> ... >>>>>>> ***=C2=A0=C2=A0=C2=A0 Section 10.3.2 paragraph 2 says that devices = should change the meaning >>>>>>> of "admin down" to mean "down for everything except ACP / Anima".= =C2=A0=C2=A0=C2=A0 I can >>>>>>> understand why, in an autonomic network, such a state is desirable.= =C2=A0 However, >>>>>>> that really should be a different state from "admin down".=C2=A0 Op= erators already >>>>>>> understand "admin down" as meaning that this interface will not be = used for any >>>>>>> traffic.=C2=A0 Changing that is fairly drastic.=C2=A0 "admin limite= d" or "admin ACP-Only" >>>>>>> would seem much better than changing the meaning of "admin down".= =C2=A0 The >>>>>>> justification in the text seems to be a desire to prevent an operat= or from >>>>>>> doing what he intends.=C2=A0 that seems backwards.=C2=A0 (Note that= the distinction >>>>>>> between administrative state vs operational state, aka failed, is a= lready well >>>>>>> understood.) >>>>>> >>>>>> Well, this is in an informative section, so hopefully something we c= an agree to disagree. >>>>> >>>>> If this were truly informative, it would not belong in this document = at all. >>>>> Changing the behavior of widely understood configuration behaviors is= NOT a >>>>> small thing.=C2=A0 Changing the permissions models for widely underst= ood >>>>> configuration operations is also NOT a small thing. >>>>> >>>>> My suggestion is that you remove all of this material.=C2=A0 If you f= eel it is >>>>> important, write an I-D for standards track on evolving the configura= tion >>>>> model for robust ANIMA.=C2=A0 While I think the change is a mistake, = you clearly >>>>> have the right to cause the discussion. >>>>> >>>>> Hiding the topic in an "informational" note in the ACP document seems= VERY >>>>> wrong. >>>>> >>>>> Also note that in your discussion below, you talk about the equivalen= ce of >>>>> admin down and physical down.=C2=A0 Most management models I know of = treat these >>>>> as quite distinct.=C2=A0 SO that is at best a red herring. >>>> >>>> Hmm. I really only CLI derived from Cisco IOS, and there the >>>> interface level "shutdown" command doubles IMHO both as admin down and >>>> as phy down, so i would contend that this is a red herring. It actuall= y >>>> does show up in diagnostic CLI as "admin down", but is also bringing d= own >>>> phy state. Therefore it is also used to diagnose phy, .e.g: shutting d= own >>>> one side of a supposed direct p2p link to verify the phy change on the >>>> other side. That practical experience is what the text and direction i= s >>>> based on. >>>> >>>> Whats an example where admin/phy down are separate in your experience = ? >>>> >>>> I don't know how you define "truly informative". I simply meant >>>> informational as compared to standards track wrt. to not impacting >>>> interoperability, but also as a precursor work to give opportunity >>>> for gaining more experience before attempting to go standard. >>>> >>>> If/when i find time i definitely would like to investigate how this >>>> could be formalized through a YANG model for ACP so that it can become= standard, >>>> but i definitely agree that especially this part of the YANG model wou= ld >>>> be highly difficult to get to before any experience is gained with >>>> this. >>>> >>>> I therefore would very much hesitate removing this text from the docum= ent, it was >>>> specifically asked for several times in the working group to understan= d >>>> how the promised reliability of the ACP against operator/contoller >>>> operation could be achieved. Having this in a first round (this docume= nt) >>>> as "informational" is IMHO a good and important thing. >>>> >>>>> (text retained for context of further discussions.) >>>>> >>>>>> >>>>>> I strongly believe that the most easy way to operationalize the ACP = and >>>>>> achieve its goals is what we have written. >>>>>> >>>>>> The historic equivalence of "down" =3D "admin down" =3D "physical do= wn" is one of >>>>>> the the most fundamental problem of remote management in networks. >>>>>> >>>>>> We really need to start thinking of separate layers of (remote) mana= gement. >>>>>> Network services on one hand and physical infra on the other. >>>>>> >>>>>> The first thing to do this is to separate operations such as "down" >>>>>> into "admin down" that affects networks services and "phy down" that >>>>>> affects the physcial infra. >>>>>> >>>>>> If you have existing commands like "shutdown" that today do both, >>>>>> the safe mapping is to let them do the safe thing in the future, e.g= : >>>>>> only "admin down", and introduce new commands for the phy operations= , >>>>>> e.g.: "phy shutdown" or the like. >>>>>> And then protect those dangerous commands even further against unint= entional or >>>>>> intentional misuse. >>>>>> >>>>>> Think of ACP/ANI also as a seamless inband version of a DCN. As an o= perator >>>>>> of the actual data network, you also didn't have any access to bring= down the DCN >>>>>> and cut yourself off from the network you manage. YOu could only scr= ew >>>>>> up that network you're meant to manage. >>>>>> >>>>>> And if your network consists of VMs in a DC, a "shutdown" on their >>>>>> interfaces will also not bring down physical interfaces necessary >>>>>> to reach the VM. >>>>>> >>>>>> In optical networks you often have an inband physcial ethernet manag= ement >>>>>> channel. Making/breaking that one is completely different from makin= g/breaking >>>>>> your data-plane, aka: data fiber colors. >>>>>> >>>>>>> ***=C2=A0=C2=A0=C2=A0 The notion in 10.3.6 that the device should r= efuse to disable >>>>>>> functionality when an authorized administrator directs such seems f= latly wrong. >>>>>> >>>>>> The authorization to break your own remote management connectivity >>>>>> would be a property of the certificate. clearly whoever enrolled >>>>>> the device with a certificate denying that capaility to the operator >>>>>> did NOT authorize the administrator to break connectivity. >>>>> >>>>> The security model change seems as problematic as the above configura= tion >>>>> change. >>>> >>>> We have recurringly heard from customers that mistakes in managing rem= ote >>>> equipment and loosing connectivity is a mayor pain point. Creating >>>> an operational option that limits/disables operators ability to >>>> impact phy level connectivity that remote management depends upon and = therefore >>>> reducing this risk and cost factor seems to me like a very logical pah >>>> forward. Whether or not this should be indicated in the certificate >>>> or differently is definitely wide open. >>>> >>>> I agree that none of these operational interface level changes are >>>> a piece of cake given how we have in the IETF not tried to define >>>> different access levels to configuration so far, at least not >>>> between some phy/infra access level and network-services access level. >>>> >>>> As said above in my first reply that you didn't comment on, i think a >>>> good part of what i am looking for may happen through other means >>>> already, such as when a router is just a VM running on an OS. At least >>>> in early versions of this that i'd seen, this implicitly disabled >>>> the ability to modify phy state from the router VM, and of course >>>> complaints where raised that phy mods where necessary, but at least th= is >>>> evolution could give raise to pause and rethink HOW to permit doing th= is. >>>> >>>> So i would at least like to pledge with you that it is a good thing to >>>> have this type of discussion in an informational way in this RFC inste= ad >>>> of doing nothing or trying to go standard YANG directly as a first ste= p. >>>> It did get into the spec because of the desire of the working group. >>>> >>>>>>> Editorial / Nits: >>>>> . >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the various formats in sec= tion 6.10, the lowest bit of the upper 64 bits >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is mandated to be 0.=C2=A0 Pr= esumably, there is some reason for doing this.=C2=A0 It >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 would be nice to explain it. >>>>>> >>>>>> Sorry, not clear what you're referring to. Can you give me an >>>>>> explicit reference ? >>>>> >>>>> I should ahve removed this note.=C2=A0 It was a side-effect of the pr= esentation >>>>> and ordering, not a problem on its own.=C2=A0 Sorry. >>>> >>>> Cheers >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Toerless >>>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> --=20 >> --- >> tte@cs.fau.de >=20 From nobody Wed May 16 20:23:54 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE35212E895 for ; Wed, 16 May 2018 20:23:52 -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 iGVVaVrR1UHy for ; Wed, 16 May 2018 20:23:51 -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 396781270AC for ; Wed, 16 May 2018 20:23:51 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e9-v6so1365827pfi.4 for ; Wed, 16 May 2018 20:23:51 -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=wA8wpyg2ZFEjFue83pJ08nCSGlWo13TqF5+z+0wGsNo=; b=R7Y+5qgLD4NDLhM1LNICwyHkqoQXNwY5JtZfLzPXKRhyh7szGQyzGUTCS1aYeSI+X0 I9smY6QFQnsZ8xLsDBvkwzg+WlrHIPkPJ0T8llhp5fpaONbl98JXDc1cm6dOeVgT3EQ5 SO+LJeIbhEC2ArIFk4ItkwGKYIhSZvtYUrBPEJOJYfZD1Mzm9G9BNqmm20ZHa5iKZAHo hKRgKhJBT5APSbE2owYNjtAAnVwKZL5ET932Ak96TmwAI4e2TUAUnk74/YiGs48gPioe ZyRQcOMyCFgIVMhXD4yUoA3a9U62yzcfAc5Vp7bo1FpoPWc18Dgeb6PCZ693fWGV2WD0 Gepg== 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=wA8wpyg2ZFEjFue83pJ08nCSGlWo13TqF5+z+0wGsNo=; b=K/300rThaUHQ91p1zonWn4PjAX/UBxGUhTU0aSJNEUu8PP41puO4W8lw8PINvm7xpC 7RLWpts23MZUCD65DKAU5VjP6fv92tIt10TACO+Yn2dyHI6JU+zluJO0zBNpGAIBhE8r zjBRV+CKvo7MicsU3M2Dh4JQCZI6jzaM6Q+4rhymHNQk3bq5EkMWVXrnrkNovq0lRUCA mxhWsQPUMULpqBiEuuHX06M4KTnkqdPlkpgoHzosPGvSN8a3UlnMluYzvaReOJVf5c7Z xlvI6Ey2/PcrVnjiB3LPiTR8DbHG+qnXF0XwUpX7aV7qAlutujvioqKq0Fb7aO0K2QCH cqwA== X-Gm-Message-State: ALKqPwfLw5GNch7Ctc39me5bEfA7VBzQPMi9UVkNQBrlI5F6J1JX2CGG /1QTDfn/ShIhycYQJ5gaXjUNkw== X-Google-Smtp-Source: AB8JxZpypBVwwbCZRI2tl5CKsXK3ykB1dzt3vBHP7loxgXSe058NAje8tisoAAtP4GAAtZRX6AL06A== X-Received: by 2002:a63:6e88:: with SMTP id j130-v6mr2781836pgc.321.1526527430390; Wed, 16 May 2018 20:23:50 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id k14-v6sm6245629pgr.15.2018.05.16.20.23.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 20:23:49 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <0d409bb3-463d-7011-ced7-a5f99847c9ed@gmail.com> Date: Thu, 17 May 2018 15:23:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adoption call for draft-richardson-anima-ace-constrained-voucher (ends 05/12/2018) 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, 17 May 2018 03:23:53 -0000 I'm a bit late, but this does seem in scope for the WG and potentially valuable. I don't have the expertise to review it in detail, but adoption seems appropriate. Regards Brian Carpenter From nobody Thu May 17 17:05:35 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A9E124D6C for ; Thu, 17 May 2018 17:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLmdj_iriWfp for ; Thu, 17 May 2018 17:05:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47358124C27 for ; Thu, 17 May 2018 17:05:32 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EA3A52627A7EA for ; Fri, 18 May 2018 01:05:26 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 18 May 2018 01:05:28 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.29]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0382.000; Fri, 18 May 2018 08:05:21 +0800 From: Sheng Jiang To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Adoption call for draft-richardson-anima-ace-constrained-voucher (ends 05/12/2018) Thread-Index: AQHT7Y6KnRell2/A0UKgrYfxw4+AAqQ0m43g Date: Fri, 18 May 2018 00:05:20 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B928187AC1D@NKGEML515-MBS.china.huawei.com> References: <0d409bb3-463d-7011-ced7-a5f99847c9ed@gmail.com> In-Reply-To: <0d409bb3-463d-7011-ced7-a5f99847c9ed@gmail.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.45.111.156] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Adoption call for draft-richardson-anima-ace-constrained-voucher (ends 05/12/2018) 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, 18 May 2018 00:05:34 -0000 SSBhbHNvIHN1cHBvcnQgdGhlIGFkb3B0aW9uIGFzIGFuIEFOSU1BIHBhcnRpY2lwYW50LiBJdCBp cyBzdHJvbmcgbGlua2VkIGJhY2sgdG8gQU5JTUEgdm91Y2hlciBkcmFmdCwgd2hpY2ggaGFzIGp1 c3QgcHVibGlzaGVkIGFzIFJGQyA4MzY2LiBTbywgd2l0aCBteSBXRyBjaGFpciBoYXQgb24sIHRo aXMgZG9jdW1lbnQgaXMgaW4gdGhlIFdHIHNjb3BlLg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSBDYXJwZW50ZXINClNlbnQ6IFRodXJz ZGF5LCBNYXkgMTcsIDIwMTggMTE6MjQgQU0NClRvOiBBbmltYSBXRyA8YW5pbWFAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW0FuaW1hXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1yaWNoYXJkc29u LWFuaW1hLWFjZS1jb25zdHJhaW5lZC12b3VjaGVyIChlbmRzIDA1LzEyLzIwMTgpDQoNCkknbSBh IGJpdCBsYXRlLCBidXQgdGhpcyBkb2VzIHNlZW0gaW4gc2NvcGUgZm9yIHRoZSBXRyBhbmQgcG90 ZW50aWFsbHkgdmFsdWFibGUuDQpJIGRvbid0IGhhdmUgdGhlIGV4cGVydGlzZSB0byByZXZpZXcg aXQgaW4gZGV0YWlsLCBidXQgYWRvcHRpb24gc2VlbXMgYXBwcm9wcmlhdGUuDQoNClJlZ2FyZHMN CiAgIEJyaWFuIENhcnBlbnRlcg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Fri May 18 09:04:10 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DADC12DA4D; Fri, 18 May 2018 09:04:08 -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-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152665944850.1663.17974282102092824462.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2018 09:04:08 -0700 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-anima-autonomic-control-plane-13=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, 18 May 2018 16:04:09 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I would like to see a slightly stronger statement here in section 6.1.3: "The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds, the value SHOULD be operator configurable." Maybe the following instead: "The M_FLOOD message MUST be sent periodically. The default MUST be 60 seconds, the value SHOULD be operator configurable but SHOULD be not smaller than 60 seconds." Or even a MUST for the minimum value is that acceptable for the desired use cases. 2) Also in section 6.5, I would like to seem some rate limiting/pacing: "An ACP node may choose to attempt initiate the different feasible ACP secure channel protocols it supports according to its local policies sequentially or in parallel,..." 3) Sec 6.7.3: How are baseline ACP and constrained ACP nodes defined? 4) sec 6.10.6: "With the current allocations, only 2 more schemes are possible, so the last addressing scheme should consider to be extensible in itself (e.g.: by reserving bits from it for further extensions." Maybe use a normative MUST here: "With the current allocations, only 2 more schemes are possible, so the last addressing scheme MUST be extensible in itself (e.g.: by reserving bits from it for further extensions." 5) I guess section 10 could be moved to the appendix. From nobody Fri May 18 10:09:01 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8D12D86B; Fri, 18 May 2018 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=wbiqkh46; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CsTjavFH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbK9Hi2JiFdT; Fri, 18 May 2018 10:08:57 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7F912D7F6; Fri, 18 May 2018 10:08:57 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C652C22577; Fri, 18 May 2018 13:08:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 18 May 2018 13:08:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=hjbMiTf4lEOzfAEbF77AkJFXKtvn9 PxjPQIz7j89JQk=; b=wbiqkh46sti2FkeN5A+t0Vguf65xHxfRA8NabkCl6QLuv Moqc17+R+u68EavaY80uQhc31PhE62Puv7vjK/qegCTBfhm4TNljjfSG+sqUh9GU ElAnVQKxUIHfleVegEdlyRpbhLLwfG2bTS0qNh4gkZ6BcHcpQsuHjsp3mEpNMBa9 DJtJSutNhK/KC26grs/R7ov3MK5gESmRhCACFcH5FjLwvsCuODtk5S/zWbLRg+sY VvUW3WS1XJCgOMGwNlCctoFPlG9SgzC/EBDufki9pR06FFpFKFKzzdd2xCf0FU5z UvwSOGqyYQA/I3uzsJdFp6kAJ4cloakNG97Rpupyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hjbMiT f4lEOzfAEbF77AkJFXKtvn9PxjPQIz7j89JQk=; b=CsTjavFHX4h8nO75miQwEm D+cGMSmF2RYiuOEd1EVQ95XD/tuJPvUR2OjnaZA1pJe3aJnmy95mk2bS0ql13+lL 2M0dZgJCz0HLp0Il2YWBXQFgGryV/pddddd6TwTWCkOTkajPKlF3wZnncSWm3t9c 6om9fW08n9RP4BJtz9KQd8BRtBUrrnLQ7bYO7fK/SnC1nU/O6O0F5Tj+WOrvF3A3 7PthyTezzZL/C8aU1zeqkOExdmeQZvXtz5HaQgC/+fJESNrDnvO59okyHctr75JE nU1lL9Adtk+qzlVoET7zUWz1+e60PK/wbsxzDPKac703AD7o6uLxCesq1MRM0rVg == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 3235010265; Fri, 18 May 2018 13:08:56 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20180419005041.qotqshfc7vkht45o@faui48f.informatik.uni-erlangen.de> Date: Fri, 18 May 2018 13:08:55 -0400 Cc: Elwyn Davies , "gen-art@ietf.org" , draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <83000761-CA05-4DAC-92E3-27C8C06DDDDC@cooperw.in> References: <2vnnj4bct7mlx8ulb604r9tc.1524096293973@email.android.com> <20180419005041.qotqshfc7vkht45o@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Anima] [Gen-art] Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13 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, 18 May 2018 17:09:00 -0000 Hi, I was wondering if any response to Elwyn=E2=80=99s review besides = Brian=E2=80=99s is forthcoming and if so when the authors or shepherd = expect to send it. Thanks, Alissa > On Apr 18, 2018, at 8:50 PM, Toerless Eckert wrote: >=20 > Sorry, trying to get through backlog. Took longer than expected... >=20 > On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote: >> Hi. >> It has been about 6 weeks since responses to the review were = postponed till after IETF 101.... any thoughts yet? >> Regards,Elwyn >>=20 >>=20 >> Sent from Samsung tablet. >> -------- Original message --------From: Elwyn Davies = Date: 02/03/2018 12:04 (GMT+00:00) To: Brian E = Carpenter , gen-art@ietf.org Cc: = draft-ietf-anima-autonomic-control-plane.all@ietf.org Subject: Re: = [Gen-art] Gen-art LC Review of >> draft-ietf-anima-autonomic-control-plane-13=20 >> Just taking up one point for the time being.... =20 >> Even if the reference model is informational, I was relying on RFC = 8067, s1, para 3: >> Section 2 of [RFC3967] lists some conditions under which downrefs = may >> make sense. In addition to those, it has become common for = working >> groups to produce foundational documents (which contain important >> information such as terminology definitions and architectural = design >> and considerations) at Informational status, and those documents = are >> often needed as normative references in the Standards Track = protocol >> documents that follow.=20 >> I would say that sombody implementing ACP really needs to have read = and understood the reference model and so I would argue:1. That it needs = to be normative,and2. The downref is sanctioned by the language in RFC = 8067.=20 >> I am on holiday for a week and others are fighting the draft deadline = so perhaps we can postpone discussion of the other points until the = draft panic has subsided. >> Cheers,Elwyn >> Sent from Samsung tablet. >=20 > --=20 > --- > tte@cs.fau.de >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Fri May 18 13:24:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DC912E03F; Fri, 18 May 2018 13:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbPlfmbYOsve; Fri, 18 May 2018 13:24:29 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 09DEC12DA6C; Fri, 18 May 2018 13:24:29 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id a22-v6so4263537pfn.6; Fri, 18 May 2018 13:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k9BEZOtawu3/0YgT1ETWWfQW00DBKtGQlJuImo5Zs50=; b=OpcSC6oYGxEVu1CQ9y4GEvEn18OA8zfrTD5h6wNzOikXQB8nK6iuFQLd1Q5uTcyed/ mSws2sy3zcUaJUkS72oyvSx+mzE+yp82eHR335kHJRZ+6lRuxOvZjPYUM3HgOL9uJLIb YnEwXhMx4IPiSIC97Ua3DaNxnNIeOaovGCHwhO/S/LE/dRKp3dfgaAIaLsSMBXra603h 8/9ImN8I5f+4TcVhHrZGVExYWQJd30Qi3qkAxl3yfm5HK4By+Nd1ExymXzS8VRvuyMuR MggW6p3Bhk3Ko0ZojzR3qTfpwwwzPtmRMr2o5nA3x4hGPDNj333ndAxt8Rsr+vgZSI+B jYvA== 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=k9BEZOtawu3/0YgT1ETWWfQW00DBKtGQlJuImo5Zs50=; b=fHtGfoDc4+Mgn2LSDaimGxT6+QNk5J3pN1jc9ZaFXy8829mRhztXz4+Zk0xOx5CgRQ gYXrCI9qfn3RDv+Vd2BsbR0m4OrTgU0IYBLCMJee6TR133Itsm9XDjdl+Qv8UtBTe+sh Ah5hRsYk6HvMdzPmsYizSuXpH0d4pen1PcMah98DCv4cX0EH6dGQm04hzxat6rcwuwwj 3Ekr4TCODdMGvSvSDotQsa51ZTUvNr5iWYfS2M191J5FdFcmZDFJTRC6MEGd/DOCG77t zpU3nxUcdEhKZTN2Vv27YOp0Z/NT2pIVSoqLTM1qG6p8O0AolG3uphBiinPbl84TzkSG e/BQ== X-Gm-Message-State: ALKqPwetznBI6Gjj1xlIBG0CWqvEpG/VUpw0IvXmIs85gtj5gYRWyQ/G B2il2yL2F8voWMTilEZmZ9CFGg== X-Google-Smtp-Source: AB8JxZpj7ZF0qrLRxNWDWp5mLi4zwGUISGdRjUxQ4sk8Tlk4YaltqG5DAmt3CTKCBdTBNrF9IOM6VA== X-Received: by 2002:a63:8348:: with SMTP id h69-v6mr8459981pge.378.1526675068207; Fri, 18 May 2018 13:24:28 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id x2-v6sm21440455pfk.113.2018.05.18.13.24.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 13:24:26 -0700 (PDT) To: Alissa Cooper , Toerless Eckert Cc: "gen-art@ietf.org" , Elwyn Davies , anima@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org References: <2vnnj4bct7mlx8ulb604r9tc.1524096293973@email.android.com> <20180419005041.qotqshfc7vkht45o@faui48f.informatik.uni-erlangen.de> <83000761-CA05-4DAC-92E3-27C8C06DDDDC@cooperw.in> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1286e4b6-3551-1fbd-b189-67c5d9ec096e@gmail.com> Date: Sat, 19 May 2018 08:24:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <83000761-CA05-4DAC-92E3-27C8C06DDDDC@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] [Gen-art] Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13 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, 18 May 2018 20:24:32 -0000 Alissa, "On agenda of 2018-05-24 IESG telechat" surprises me. I thought a -14 version was the next step. I'll repeat my opinion on the reference issue, being a co-author of the reference model (draft-ietf-anima-reference-model). We never expected that to be treated as a normative reference. While it definitely provides useful background for the ACP draft, I don't see it as being required reading for a correct implementation. Regards Brian On 19/05/2018 05:08, Alissa Cooper wrote: > Hi, >=20 > I was wondering if any response to Elwyn=E2=80=99s review besides Brian= =E2=80=99s is forthcoming and if so when the authors or shepherd expect t= o send it. >=20 > Thanks, > Alissa >=20 >> On Apr 18, 2018, at 8:50 PM, Toerless Eckert wrote: >> >> Sorry, trying to get through backlog. Took longer than expected... >> >> On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote: >>> Hi. >>> It has been about 6 weeks since responses to the review were postpone= d till after IETF 101.... any thoughts yet? >>> Regards,Elwyn >>> >>> >>> Sent from Samsung tablet. >>> -------- Original message --------From: Elwyn Davies Date: 02/03/2018 12:04 (GMT+00:00) To: Brian E Carpenter , gen-art@ietf.org Cc: draft-ietf-anima-autonomi= c-control-plane.all@ietf.org Subject: Re: [Gen-art] Gen-art LC Review of >>> draft-ietf-anima-autonomic-control-plane-13=20 >>> Just taking up one point for the time being.... =20 >>> Even if the reference model is informational, I was relying on RFC 80= 67, s1, para 3: >>> Section 2 of [RFC3967] lists some conditions under which downrefs = may >>> make sense. In addition to those, it has become common for workin= g >>> groups to produce foundational documents (which contain important >>> information such as terminology definitions and architectural desi= gn >>> and considerations) at Informational status, and those documents a= re >>> often needed as normative references in the Standards Track protoc= ol >>> documents that follow.=20 >>> I would say that sombody implementing ACP really needs to have read a= nd understood the reference model and so I would argue:1. That it needs t= o be normative,and2. The downref is sanctioned by the language in RFC 806= 7.=20 >>> I am on holiday for a week and others are fighting the draft deadline= so perhaps we can postpone discussion of the other points until the draf= t panic has subsided. >>> Cheers,Elwyn >>> Sent from Samsung tablet. >> >> --=20 >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Fri May 18 13:53:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64212E041; Fri, 18 May 2018 13:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hpZE0P-awgt; Fri, 18 May 2018 13:53:15 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CCB12E03C; Fri, 18 May 2018 13:53:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 0927036102D; Fri, 18 May 2018 13:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1526676795; bh=PxTp79GPhGWkGwIUlTh8msy4CpZx2Ll4ubTHvbAIjRg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JV60Xrexz7+UgyK/Is8Towh6Iw582vnCteSbqGPams+1q0AQf+ZxaT+8SPjHpIVjO eIx9gjFSFBENzZUK3KWrNwmbFO7Bh7jm8H7PpIjJxgsQqhR7men0Bn35k38v5BIeFe h6JTgeD2AYlTTXPLYH4PnUN40r85Y2sywbQ/zfho= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id DDA543610F3; Fri, 18 May 2018 13:53:13 -0700 (PDT) To: Brian E Carpenter , Alissa Cooper , Alvaro Retana Cc: draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org References: <2vnnj4bct7mlx8ulb604r9tc.1524096293973@email.android.com> <20180419005041.qotqshfc7vkht45o@faui48f.informatik.uni-erlangen.de> <83000761-CA05-4DAC-92E3-27C8C06DDDDC@cooperw.in> <1286e4b6-3551-1fbd-b189-67c5d9ec096e@gmail.com> From: "Joel M. Halpern" Message-ID: <4d9ef5a7-face-4d19-fad7-e6fc1d9c201b@joelhalpern.com> Date: Fri, 18 May 2018 16:53:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1286e4b6-3551-1fbd-b189-67c5d9ec096e@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] [Gen-art] Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13 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, 18 May 2018 20:53:17 -0000 Even if the WG concluded it did not want to address some of the issues from by Routing Directorate review, I would have expected a revision to address the lesser issues that had been agreed to, before the IESG could vote on the document. Yours, Joel On 5/18/18 4:24 PM, Brian E Carpenter wrote: > Alissa, > > "On agenda of 2018-05-24 IESG telechat" surprises me. I thought > a -14 version was the next step. > > I'll repeat my opinion on the reference issue, being a co-author > of the reference model (draft-ietf-anima-reference-model). We > never expected that to be treated as a normative reference. While > it definitely provides useful background for the ACP draft, I > don't see it as being required reading for a correct implementation. > > Regards > Brian > > On 19/05/2018 05:08, Alissa Cooper wrote: >> Hi, >> >> I was wondering if any response to Elwyn’s review besides Brian’s is forthcoming and if so when the authors or shepherd expect to send it. >> >> Thanks, >> Alissa >> >>> On Apr 18, 2018, at 8:50 PM, Toerless Eckert wrote: >>> >>> Sorry, trying to get through backlog. Took longer than expected... >>> >>> On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote: >>>> Hi. >>>> It has been about 6 weeks since responses to the review were postponed till after IETF 101.... any thoughts yet? >>>> Regards,Elwyn >>>> >>>> >>>> Sent from Samsung tablet. >>>> -------- Original message --------From: Elwyn Davies Date: 02/03/2018 12:04 (GMT+00:00) To: Brian E Carpenter , gen-art@ietf.org Cc: draft-ietf-anima-autonomic-control-plane.all@ietf.org Subject: Re: [Gen-art] Gen-art LC Review of >>>> draft-ietf-anima-autonomic-control-plane-13 >>>> Just taking up one point for the time being.... >>>> Even if the reference model is informational, I was relying on RFC 8067, s1, para 3: >>>> Section 2 of [RFC3967] lists some conditions under which downrefs may >>>> make sense. In addition to those, it has become common for working >>>> groups to produce foundational documents (which contain important >>>> information such as terminology definitions and architectural design >>>> and considerations) at Informational status, and those documents are >>>> often needed as normative references in the Standards Track protocol >>>> documents that follow. >>>> I would say that sombody implementing ACP really needs to have read and understood the reference model and so I would argue:1. That it needs to be normative,and2. The downref is sanctioned by the language in RFC 8067. >>>> I am on holiday for a week and others are fighting the draft deadline so perhaps we can postpone discussion of the other points until the draft panic has subsided. >>>> Cheers,Elwyn >>>> Sent from Samsung tablet. >>> >>> -- >>> --- >>> tte@cs.fau.de >>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > From nobody Fri May 18 13:54:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE8212E041; Fri, 18 May 2018 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43iiWyvyIdeL; Fri, 18 May 2018 13:54:06 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68AA12E03C; Fri, 18 May 2018 13:54:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 90F4A361106; Fri, 18 May 2018 13:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1526676846; bh=Al429Qddg3oMrZmnLjK/QEupn2HY7hl7iG6JPvR7kjg=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=n473OtAU+BLK8g5gQ87BVj2kKzIYgrtNcufkpRLPmOzWkoZAzKKHFDS+3pccOxBTX l7uNezE79wvseHUR/dPRyN6GDMA5HPizohm5RlhswIKxXiZt7XohKNcGFr5TaZ8vNx dNMi9p0nhC7i0ncNn5vZWFWc/Wc6TmlVzX9FpAVc= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id D3A7D361103; Fri, 18 May 2018 13:54:05 -0700 (PDT) From: Joel Halpern To: Brian E Carpenter , Alissa Cooper , Alvaro Retana Cc: draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org References: <2vnnj4bct7mlx8ulb604r9tc.1524096293973@email.android.com> <20180419005041.qotqshfc7vkht45o@faui48f.informatik.uni-erlangen.de> <83000761-CA05-4DAC-92E3-27C8C06DDDDC@cooperw.in> <1286e4b6-3551-1fbd-b189-67c5d9ec096e@gmail.com> Message-ID: <81c5230a-1a20-74ea-db77-1ec401cbee86@joelhalpern.com> Date: Fri, 18 May 2018 16:54:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1286e4b6-3551-1fbd-b189-67c5d9ec096e@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] [Gen-art] Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13 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, 18 May 2018 20:54:09 -0000 (Resend with the right address for Alvaro.) Even if the WG concluded it did not want to address some of the issues from by Routing Directorate review, I would have expected a revision to address the lesser issues that had been agreed to, before the IESG could vote on the document. Yours, Joel On 5/18/18 4:24 PM, Brian E Carpenter wrote: > Alissa, > > "On agenda of 2018-05-24 IESG telechat" surprises me. I thought > a -14 version was the next step. > > I'll repeat my opinion on the reference issue, being a co-author > of the reference model (draft-ietf-anima-reference-model). We > never expected that to be treated as a normative reference. While > it definitely provides useful background for the ACP draft, I > don't see it as being required reading for a correct implementation. > > Regards > Brian > > On 19/05/2018 05:08, Alissa Cooper wrote: >> Hi, >> >> I was wondering if any response to Elwyn’s review besides Brian’s is forthcoming and if so when the authors or shepherd expect to send it. >> >> Thanks, >> Alissa >> >>> On Apr 18, 2018, at 8:50 PM, Toerless Eckert wrote: >>> >>> Sorry, trying to get through backlog. Took longer than expected... >>> >>> On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote: >>>> Hi. >>>> It has been about 6 weeks since responses to the review were postponed till after IETF 101.... any thoughts yet? >>>> Regards,Elwyn >>>> >>>> >>>> Sent from Samsung tablet. >>>> -------- Original message --------From: Elwyn Davies Date: 02/03/2018 12:04 (GMT+00:00) To: Brian E Carpenter , gen-art@ietf.org Cc: draft-ietf-anima-autonomic-control-plane.all@ietf.org Subject: Re: [Gen-art] Gen-art LC Review of >>>> draft-ietf-anima-autonomic-control-plane-13 >>>> Just taking up one point for the time being.... >>>> Even if the reference model is informational, I was relying on RFC 8067, s1, para 3: >>>> Section 2 of [RFC3967] lists some conditions under which downrefs may >>>> make sense. In addition to those, it has become common for working >>>> groups to produce foundational documents (which contain important >>>> information such as terminology definitions and architectural design >>>> and considerations) at Informational status, and those documents are >>>> often needed as normative references in the Standards Track protocol >>>> documents that follow. >>>> I would say that sombody implementing ACP really needs to have read and understood the reference model and so I would argue:1. That it needs to be normative,and2. The downref is sanctioned by the language in RFC 8067. >>>> I am on holiday for a week and others are fighting the draft deadline so perhaps we can postpone discussion of the other points until the draft panic has subsided. >>>> Cheers,Elwyn >>>> Sent from Samsung tablet. >>> >>> -- >>> --- >>> tte@cs.fau.de >>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > From nobody Fri May 18 19:32:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6777126CD8; Fri, 18 May 2018 19:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9YFEfQQ-JVv; Fri, 18 May 2018 19:32:40 -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 1D3E2126C19; Fri, 18 May 2018 19:32:39 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5BA5658C4AF; Sat, 19 May 2018 04:30:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4AB08440218; Sat, 19 May 2018 04:30:17 +0200 (CEST) Date: Sat, 19 May 2018 04:30:17 +0200 From: Toerless Eckert To: Alissa Cooper Cc: "gen-art@ietf.org" , Elwyn Davies , anima@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180519023017.nvffx4whxxag4kyk@faui48f.informatik.uni-erlangen.de> References: <2vnnj4bct7mlx8ulb604r9tc.1524096293973@email.android.com> <20180419005041.qotqshfc7vkht45o@faui48f.informatik.uni-erlangen.de> <83000761-CA05-4DAC-92E3-27C8C06DDDDC@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83000761-CA05-4DAC-92E3-27C8C06DDDDC@cooperw.in> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] [Gen-art] Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13 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, 19 May 2018 02:32:43 -0000 Definitely, just works better for me when not having to multi-thread, and still trying to finalize feedback for Joel Halperns excellent feedback Cheers Toerless On Fri, May 18, 2018 at 01:08:55PM -0400, Alissa Cooper wrote: > Hi, > > I was wondering if any response to Elwyn???s review besides Brian???s is forthcoming and if so when the authors or shepherd expect to send it. > > Thanks, > Alissa > > > On Apr 18, 2018, at 8:50 PM, Toerless Eckert wrote: > > > > Sorry, trying to get through backlog. Took longer than expected... > > > > On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote: > >> Hi. > >> It has been about 6 weeks since responses to the review were postponed till after IETF 101.... any thoughts yet? > >> Regards,Elwyn > >> > >> > >> Sent from Samsung tablet. > >> -------- Original message --------From: Elwyn Davies Date: 02/03/2018 12:04 (GMT+00:00) To: Brian E Carpenter , gen-art@ietf.org Cc: draft-ietf-anima-autonomic-control-plane.all@ietf.org Subject: Re: [Gen-art] Gen-art LC Review of > >> draft-ietf-anima-autonomic-control-plane-13 > >> Just taking up one point for the time being.... > >> Even if the reference model is informational, I was relying on RFC 8067, s1, para 3: > >> Section 2 of [RFC3967] lists some conditions under which downrefs may > >> make sense. In addition to those, it has become common for working > >> groups to produce foundational documents (which contain important > >> information such as terminology definitions and architectural design > >> and considerations) at Informational status, and those documents are > >> often needed as normative references in the Standards Track protocol > >> documents that follow. > >> I would say that sombody implementing ACP really needs to have read and understood the reference model and so I would argue:1. That it needs to be normative,and2. The downref is sanctioned by the language in RFC 8067. > >> I am on holiday for a week and others are fighting the draft deadline so perhaps we can postpone discussion of the other points until the draft panic has subsided. > >> Cheers,Elwyn > >> Sent from Samsung tablet. > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue May 22 07:06:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1EF1270A7; Tue, 22 May 2018 07:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmNTd0FrF3iN; Tue, 22 May 2018 07:06:49 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF9512EB46; Tue, 22 May 2018 07:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25843; q=dns/txt; s=iport; t=1526998008; x=1528207608; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wCmjHlFr1AmP1O6FCdQ8WWC6BoihPpNLTo03APTNfYc=; b=mapjxUykSeW/tY5N8Jn0bzOFIS3itumi3BTpBJUkUZtpHXsqGskAxI4u vE2YgfyC5XfxNQtQPJb1JAdO5hrntWJgYzQsNYzrY4yIE8o2g/MPu2ZAv z2yyR2T0P09QGUlEzXc2bvke/FXfDgCfWebYuH+U4/MTGpFtUVEZygvse I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AABjIwRb/5ldJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMYK2J9KAqLb4x3gXl1GpM2FIFkCyWERwKCISE0GAECAQE?= =?us-ascii?q?BAQEBAmwcDIUoAQEBAQIBGg0TMQMLBQsCAQgOCh4QMiUBAQQODRODCYF3CA+?= =?us-ascii?q?qOjOIRYIPhxKBI4FUP4EPgRF9SjWDEQEBAgEXgRMXBIVsAoccFwoRhFOBIos?= =?us-ascii?q?MCQKFaG+HdoE/PoMwgl+EeolghnMCERMBgSQBHDhhcXAVGiGCMwEPCYIWARd?= =?us-ascii?q?6AQKCSIUUhT5vAQGMFiqBBIEYAQE?= X-IronPort-AV: E=Sophos;i="5.49,430,1520899200"; d="scan'208";a="118217003" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2018 14:06:47 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w4ME6k5l001878 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 May 2018 14:06:47 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 22 May 2018 09:06:46 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 22 May 2018 09:06:45 -0500 From: "Pascal Thubert (pthubert)" To: Toerless Eckert CC: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Thread-Topic: An IOT DIR review of draft-ietf-anima-autonomic-control-plane Thread-Index: AdOnCBzSJMKw+zXyQYGzXbZB1JtadhBRtloAAmD3rMA= Date: Tue, 22 May 2018 14:06:17 +0000 Deferred-Delivery: Tue, 22 May 2018 14:06:12 +0000 Message-ID: References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.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, 22 May 2018 14:06:54 -0000 Hello Toerless: >=20 > Thanks, Pascal, sorry for the delay, >=20 > Comments inline. >=20 > Version: >=20 > https://raw.githubusercontent.com/anima-wg/autonomic-control- > plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima- > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt >=20 >=20 > Diff to prior version (-14 for Joel Halpern) >=20 > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.githu= busercon > tent.com/anima-wg/autonomic-control- > plane/8b4436edaa720eadb5839120400fd1e89d3289b0/draft-ietf-anima- > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > 14.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/autonomic- > control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf- > anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > 14.txt >=20 > Will commit as -14 when i am through with the other -13 feedback. >=20 > Cheers > Toerless >=20 >=20 > On Mon, Feb 26, 2018 at 05:25:58PM +0000, Pascal Thubert (pthubert) > wrote: > > Reviewer: Pascal Thubert on behalf of IOT-DIR; > > > > I am an assigned IoT directorate reviewer for draft-ietf-anima-autonomi= c- > control-plane-13. > > > > These comments were written primarily for the benefit of the INT and OP= S > Areas Directors from the IoT perspective. Document editors and shepherd(s= ) > should treat these comments just like they would treat comments from any > other IETF contributors and resolve them along with any other Last Call > comments that have been received. For more details on the IoT Directorate= , > please see https://datatracker.ietf.org/group/iotdir/about/ and for > Directorates in general please see > https://www.ietf.org/about/groups/directorates/. > > > > > > I'll be away for the next 2 weeks and could not finish the review in t= ime for > this heavy document, but at least I made it through till the RPL section.= In the > interest of time, let me share what I already have. > > > > > > > > Summary > > > > ------------- > > > > The summary of the review is that the document is Ready for Publication= , > with comments. > > > > > > > > > > > > Major comments > > > > ------------------------ > > > > > > > > - " in-band" and "out of band network " > > > > should be defined since it is fundamental to understand that the ACP > > takes place in the same physical links as the data plane, as opposed > > to dedicated management ports (correct?); >=20 > Good point, done. (got a bit too long to paste here, so pls. check diff). >=20 > > > > - Section 3; the IOT certainly could use an ACP. It would be u= seful to > scope the feature that is proposed in this document, whether it is compat= ible > of not with constrained environments, whether it needs adaptations, point= on > Michael's enrollment draft. It would also be useful to indicate whether t= he > ACP works between L3 bridges, IOW whether ACP operates the same (over IP) > regardless of the packet forwarding layer in the data plane; >=20 > Not sure i understand the "point on Michaels enrollment draft". >=20 > I am happy to add pointers to variations of ACP design aspects for > informational purposes to show that/how it can be modified, but Michaels > drafts i think are all variation of the BRSKI design, so the ACP would be > completly unaffected by them, right ? >=20 [PT>] I guess you're right there > Wrt. constrained devices and L2. I didn't want to touch section 3 for wha= t you > suggested because that really a very formulistic section going back to th= e > charter 1 justifications of ANIMA and matched with the three numbered us= e > case explanations in the introduction. >=20 [PT>] OK > Instead i wrote text at the end of the introduction, now section 1.1, Thi= s got > longer than i hoped, but it was really a big missing piece to pitch the A= CP and > give early on context for implementers and reminding of the charter goal = of > reusing the best available existing protocols/function. [PT>]=20 [PT>] I read it, very cool. >=20 > The text got longer specifically also because i did not want to fall into= the trap > of making claims whether or not ACP is applicable to specific IOT network= s or > (even worse) assuming IOT is always constrained. Therefore mentioning of = OT > networks (IMHO big part of IOT, and often totally non-constrained), > explanation of why RPL, and at the end a statement about constrained > environments. There is also a new paragraph in 10.8 about TCP/TLS vs. > CoAP/DTLS as a possible constained environment variant in the future. >=20 > > - " Inside the ACP VRF, each node sets up a loopback interface = with its > ULA IPv6 address" > > This is the first time, IPv6 is discussed; would have been nice to > > introduce that the Node has IPv6, that it needs a ULA and that ACP > > assigns it. This discussion could be done in conjunction with the > > comment above; >=20 > Actually, section 1. introduction already mentions that the ACP provides > IPv6 and that the stable-connectivity document describes how to interoper= ate > with IPv4 only OAM. >=20 > I added to the new 1.1 section (see above) the following paragraph, which= i > hope is a useful context setting and pitch: >=20 > The ACP uses only IPv6 to avoid complexity of dual-stack ACP operation= s > (IPv6/IPv4). Nevertheless, it can without any changes be integrated into = even > otherwise IPv4-only network devices. The data-plane itself would not need= to > change, it could continue to be IPv4 only. For such IPv4 only devices, th= e IPv6 > protocol itself would be additional implementation footprint only used fo= r the > ACP. [PT>] OK >=20 > > - About "The ttl > > parameter SHOULD be 3.5 times the period so that up to three > > consecutive messages can be dropped before considering an > > - announcement expired. " > > > > This is the only discussion on the ttl field of the M_FLOOD. Though its > meaning is quite obvious, the behavior associated to it should be defined= . >=20 > Added: >=20 > When a service announcer > using these parameters unexpectely dies immediately after sending the > M_FLOOD, receivers would consider it expired 210 seconds later. When a > receiver tries to connect this dead service earlier, it will experience a= failing > connection and use that as an indication the service is dead and select > another instance of the same service instead. >=20 [PT>] OK > > - "In the above (recommended) example the period of sending of = the" > > Is this RECOMMENDED IOW normative?? >=20 > Hmmm... Sure, why not. Less guessing/experiementation for this. > Modified to RECOMMENDED. [PT>] OK >=20 > > - Text P 25 says "At this time in the lifecycle of ACP nodes, i= t is unclear > whether it > > is feasible to even decide on a single MTI (mandatory to implement) > > security association protocol across all ACP nodes" > > but then P27 "It MUST support ESP > > with AES256 for encryption and SHA256 hash and MUST NOT permit > weaker > > crypto options." > > > > and then " A baseline ACP node MUST support IPsec natively and MAY > support IPsec > > via GRE. A constrained ACP node MUST support dTLS. ACP nodes > > connecting constrained areas with baseline areas MUST therefore > > > > support IPsec and dTLS." > > > > Seems that text P25 should go? >=20 > P27: An ACP node supporting native IPsec MUST use IPsec security setup vi= a > IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for > encapsulation. It MUST support ESP... (parameters). >=20 > clarified to: >=20 > P27: An ACP node that is supporting native IPsec MUST use IPsec security > setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses us= ed for > encapsulation. It MUST then support ESP... (parameters). >=20 > Also: >=20 > ACP nodes supporting ACP via GRE/IPsec MUST support IPsec security setup.= . >=20 > clarified to: >=20 > An ACP node that is supporting ACP via GRE/IPsec MUST then support IPsec > security setup.. >=20 [PT>] OK > Aka: P25 is correct, there is no single MTI. 6.7.3 defines the actual > requirement for two different profiles: "baseline ACP node" and "constrai= nted > ACP node". > The two requirements in P27 are only conditional MUSTs defining the detai= ls > of the IPsec profiles assuming a node does support IPsec or IPsec/GRE. >=20 > Let me know if this is still unclear, and if so, how you would suggest to= make it > better readable. [PT>] Someone else need to do it now I'm biased >=20 > > - "Use-ULA: For loopback interfaces of ACP nodes, we use Uniq= ue > Local > > > > Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] > > > > with L=3D1]." > > > > This needs to be more crisp. ULA is defined in RFC 4193 but the term > > ULA-Random is not. I think you mean that 3.2.2. of RFC 4193 is the > > way addresses are formed, if so please say so. The best practice RFC > > 8064 recommends use of RFC 7217. I understand that privacy is not a > > concern but does it hurt? Anyway please point at section 6.10 and > > 6.11.1.11 >=20 > The term "ULA-Random" was used in the discussions on ANIMA mailing list r= e. > ULA, so admittedly i didn't check that the term as it stands is actually = not > defined/used in rfc4193 - but its just meant to imply ULA with L=3D1, not= hing > more. I've removed the use of ULA-Random from the text and just refer now > to 4193 with L=3D1 (also pointing to 3.1. of rfc4193 defining L). >=20 [PT>] cool; > I have also added a note that the hash uses our own ACP definition instea= d of > rfc4193 3.2.2. >=20 > Paragraph is now: >=20 > Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local > Addresses (ULA), as defined in with L=3D1 (as = defined > in section 3.1 of ). Note that the random hash = for > ACP loopback addresses uses the definition in a= nd > not the one of section 3.2.2. >=20 > 8064/7217 are irrelevant here if i understand it correctly because we def= ine > the addressing scheme for anything following the ULA prefix ourselves for > ACP addresses. Let me know if i do misunderstad what you where trying to > suggest re. 8064/7217. [PT>]=20 [PT>] I guess I missed that you defined the IID. >=20 > > - " > > RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with > multicast support". Implementations should support also other modes. > > > > Note: Root indicates mode in DIO flow" > > > > Why "should" ? there is no much point supporting the other modes is > there? Section 6.11.1.13 says that SRH is not used so this is inconsisten= t. You > only need MOP 2 or 3, 3 is you do multicast which at the moment does not > appear to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 > which is a superset of MOP 2, and that's it (see 6.3.1 of RFC 6550). >=20 > Probably a transcription error on my side when i took your RPL summary an= d > wrote it down. Fixed according to above. >=20 [PT>] cool >=20 > > - "The lack of a RPI (the header defined by [RFC6553]), means= that the > > data-plane will have no rank value that can be used to detect loops. > > As a result, traffic may loop until the TTL of the packet reaches > > zero. " > > > > Since we have reliable links and no stretch (section 6.11.1.7), loops > > should be exceedingly rare. It could be recommended to send the DIOs > > 2-3 times to inform children when losing the last parent. Note that > > the technique in section "8.2.2.6. Detaching" of RFC 6550 should be > > favored over that in section "8.2.2.5. Poisoning" because it allows > > local connectivity. Also, It should be said that a node should select > > more than one parent, at least 3 if possible, and send DAOs to all of > > then in parallel. This provides multi >=20 > Not sure why your paragraph ends apruptly, buts its also in the archive, = so its > not a mistake on my email end. Hopefully nothing significant missing. [PT>]=20 [PT>] Dunno what happened. Selecting multiple parents enables NECM back. Co= uld be useful. >=20 > I have replaced the suggestive text that followed your above quoted text = in > the draft: >=20 > There are a variety of heuristics that can be used to signal from the > data-plane to the RPL control plane that a new route is needed. >=20 > With a hopefuly correct transcription of your suggestion: >=20 > > Since links in the ACP are assumed to be mostly reliable (or have link > layer protection against loss) and because there is no stretch > according to , loops should be > exceedingly rare though. > > There are a variety of mechanisms possible in RPL to further > avoid temporary loops: DIOs SHOULD be sent 2...3 times to inform childr= en > when losing the last parent. The technique in > section 8.2.2.6. (Detaching) SHOULD be favored over that in section 8.2= .2.5. > (Poisoning) because it allows local connectivity. Also, nodes SHOULD se= lect > more than one parent, at least 3 if possible, and send DAOs to all > of then in parallel. >=20 [PT>] Yes, I'm good with all this. > > - "ACP nodes MUST perform standard IPv6 operations across ACP > virtual > > interfaces including SLAAC (Stateless Address Auto-Configuration - > > RFC4862])" > > > > They may actually prefer Optimistic DAD RFC 4429 since address duplicat= ion > is highly improbable as long as you . >=20 > Added: >=20 > "Optimistic Duplicate Address Detection (DAD)" according to > is RECOMMENDED because the likelyhood = for > duplicates between ACP nodes is highly improbable as long as > the address can be formed from a globally unique local assigned > identifier > (e.g.: EUI-48/EUI-64, see below). >=20 [PT>]=20 [PT>] I'm unsure what your recommendation for the interface ID is thus the = discussion on RFC 7217. Note: I have only one slight comment left below: > > Minor comments > > > > ------------------------ > > > > > > > > > > > > - About "[RFC7575] defines the fundamental ... " > > > > for readability, it may be nicer to indicate the title of an RFC when > > it is referenced first; e.g. the text above would become > > > > " Autonomic Networking: Definitions and Design Goals" [RFC7575] defines > the fundamental ... >=20 > Ok, i am punting this one for now to RFC editor after playing around a bi= t with > the XML options - and not being satisfied... and having references for 50= RFCs > in the doc: >=20 > [RFC Editor: Question: Is it possible to change the first occurrances = of > [RFCxxxx] references to "" [RFCxxxx] ? the XML2RFC format d= oes > not seem to offer such a format, but i did not want to duplicate 50 first > references to be duplicate - one reference for title mentioning and one f= or > RFC number.] >=20 > If RFC editor comes back and can't do this easier than i can in XML, i'll= try to > go through the chores when doc is in RFC editor queue. >=20 > > - about "or network plane (there is no well-established name f= or this)" > > > > The term network plane is not used again in the document. This text may= go > away. >=20 > Done. >=20 > > You may consider using "security and transport substrate" instead, sinc= e it is > used elsewhere in the document. >=20 > "autonomic communications fabric" =3D ACP including ACP GRASP (ACP GRASP > provides discovery etc..). "security and transport substrate" =3D=3D the = parts of > ACP used by "ACP GRASP" (aka: The secure IPv6 forwarding of ACP). >=20 > Subtle difference. >=20 > > Also, please be consistent on whether you use hyphen or not and use > > that globally, e.g. for the above, and pane like in "forwarding plane" > > or "out of band network "; >=20 > Fixed up "out of band" (no hyphens) and "in-band" (with hyphen). > Not sure why but this is what MS word spelling checker suggested to me. R= FC > editor will override if these are not the best choices. >=20 >=20 >=20 > > - "data-plen" > > Typo? >=20 > Done >=20 >=20 > > - "OAM applications ("Operations Administration and Management)= " > > > > Consider using "Operations Administration and Management (OAM) > applications " instead; same goes for SDN, ASA, VRF, etc... >=20 > Ok. Tried to fix up all the instances i could find. >=20 > > - " MIC: "Manufacturer Installed Certificate". Another wor= d not used > in this document to describe an IDevID." > > > > MIC is not used in the document, maybe inform of this equivalence in th= e > IDevID definition instead; same goes for SUDI. Note that UDI is use just = once > and may not need an entry here. >=20 > The definitions of those non-necessary terms are there to help others who > like me start out not being security experts and are confused about those > equivalent or related terms. >=20 > I specifically didn't want to include discussions about these terms in th= e > definitions that are relevant (eg: IDevID) so as not to clobber up that t= ext. > Instead, readers would just look up those redundant terms when they are l= ike > me initially confused about them. >=20 > > - "RPL: \"IPv6 Routing Protocol for Low-Power and Lossy > Networks\". The routing protocol used in the ACP." > > > > Maybe point on [RFC6550]? >=20 > Done >=20 > > - "Connecting over non-ACP Layer-3 clouds initially requires a = tunnel > between ACP nodes." > > > > I understands that it is one tunnel between each pair of adjacent ACP > > nodes, correct? I read "a tunnel" as an end-to-end tunnel, which > > sounds different >=20 > Changed to: >=20 > Connecting over non-ACP Layer-3 clouds requires explicit configuration= . > See . This may be automated in in = the > future through autodiscovery mechanisms across L3. >=20 >=20 > > - "ACP relies on group security" > > > > Add "The" >=20 >=20 > Done >=20 > > - "An ACP node MUST have keying > > material consisting of a certificate (LDevID), with which it can > > cryptographically assert its membership in the ACP domain and trus= t > > anchor(s) associated with that certificate with which it can verif= y > > the membership of other nodes (see Section 6.1.2)." > > > > This is convoluted. Could you make it 2 sentences? >=20 > Fixed to: >=20 > The ACP relies on group security. An ACP domain is a group of nodes t= hat > trust each other to participate in ACP operations. To establish trust, e= ach ACP > member requires keying material: An ACP node MUST have a certificate > (LDevID) and a trust anchor (TA) consisting of a certificate (chain) used= to sign > the LDevID of all domain members. The LDevID is used to cryptographically > assert membership in the ACP domain, the TA to verify the membership of > other nodes in the ACP domain (see ). >=20 > > - " Note: LDevID ("Local Device IDentification") is the term u= sed to > > indicate a certificate that was provisioned by the owner of a > > node as opposed to IDevID ("Initial Device IDentifier") that may has > > been loaded on the node during manufacturing time. Those IDevID do > > not include owner and deployment specific information to allows > > autonomic establishment of trust for the operations of an ACP domain (e= .g.: > > between two ACP nodes without relying on any third party)." >=20 > > LDevID was already defined in the terminology. This text may move there= or > go away. >=20 > Gone. I added the note that LDevID can not be used directly for ACP to th= e > terminology definition of IDevID. >=20 > > - " This document uses the term ACP in many places where its > reference > > document use the word autonomic." > > > > Add [RFC7575] after "reference document" >=20 > Done. >=20 > > - " "routing-subdomain" is the autonomic subdomain that is u= sed to > > calculate the hash for the ULA prefix of the ACP address of the node." > > > > Do you mean ULA suffix? >=20 > No, the Global ID. Fixed. >=20 > Actually, i also sumbled across this: >=20 > RFC4193 uses "Prefix" for the first 7 bits of a ULA address, but we have= used > use the term ULA prefix to refer to the first 48 bits of a ULA address, s= o i've > clarified this more in the terminology. >=20 > > - " o If the node certificates indicate a CDP (or OCSP) the= n the peer's > > certificate must be valid according to those criteria. e.g.: OCSP > > check across the ACP or not listed in the CRL retrieved from the CDP." > > > > Please define CDP and OSCP, and/or reference a RFC is possible. >=20 > Done. Using RFC5280. Hope thats correct, otherwise IESG SEC review should > help. >=20 > > - "enrolment" > > Typo >=20 > Fixed. >=20 > > - "This can > > use a single GRASP M_FLOOD message as shown in above example." > > Actually the example is now below. Please reference the figure. >=20 > Done. Actually its still "above", or i am heavily confused. >=20 > > > > - "The protocol could for example could have been" > > > > Typo >=20 > Fixed. >=20 > > - "if the IPsec connecting" > > > > Typo? >=20 > More like sentence structure was strange. >=20 > Fixed to: >=20 > "Even if the IPsec connection from Bob succeeded, Alice might prefer ano= ther > secure protocol over IPsec" >=20 > > - "ACP wide service discovery" > > ACP-wide >=20 > Fixed. >=20 > > - "if the IPsec connecting In most other solution > > designs such distributed discovery does not exist at all or was added > > as an afterthought and relied upon inconsistently" > > > > Consider removing or rephrasing : ) >=20 > Removed: >=20 > Sentence wasn't that bad, but easier removed instead of trying to justify > negative observations about reality without being called out to provide e= ven > more proof. >=20 > > > > - Maybe consider moving the discussion on multicast P29 -30 to = annex? > Why Multicast is not used is an interesting discussion but not critical f= or the > protocol operation. >=20 > Done. >=20 > > - "it is not quite clear yet what exactly the implications ar= e > > to make GRASP flooding depend on RPL DODAG convergence and how > > difficult it would be to let GRASP flooding access the DODAG > > information" > > > > Let's chat then. There's work on reliable multicast for RPL using BIER. >=20 > Yeah if i would just get around to that ;-) >=20 > For now moved together into informative section together with te multicas= t > discus. >=20 > > - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the AC= P is the > > security and transport substrate for the GRASP instance run inside the > > ACP ("ACP GRASP"). " > > > > "running" inside the ACP? Maybe rephrase more globally? > > >=20 > This instance of GRASP runs across the ACP secure channels.. >=20 > > - "OAM protocols no not require IPv4: The ACP may carry OAM " > > Typo no->do >=20 > Fixed. >=20 > > - "Consider a network that has multiple NOCs in different loc= ations. > > Only one NOC will become the DODAG root. Other NOCs will have to send > > traffic through the DODAG (tree) rooted in the primary NOC." >=20 > > A figure would help. I remember all the discussions we had about > > setting the prf bits in remote NOCs >=20 > Sorry. A bit low on cycles right now. Hopefully i'll get around to it lat= er. > Created a wish list entry in changelog. >=20 > > - "RPPL." > > Typo >=20 > Fixed. >=20 > > - "Administrative Preference ([RFC6552], 3.2.6 " > > > > The section is correct but that is RFC 6550. >=20 > Done >=20 > > > > - "This is a standard issue > > with tunneling, not specific to running the ACP across it." > > Do you really mean Standard or would Classical work better? >=20 > This is an issue of tunnels, not an issue of running the ACP across a tun= nel. [PT>]=20 [PT>] Sure but I was pointing at the word "standard", probably ill-chosen i= n a standard doc... >=20 > > - "Even though loopback interfaces where originally d" > > Typo Where -> were >=20 > Done. >=20 > > - Section 3, 4, 9 and 10 may move to Annex (by moving the secti= on after > the tag) since they are not normative and do not contribute= to > the understanding of the protocol. This way there should not be a need to > indicate normative in other sections. >=20 > Sections 3, 4 and 9 are fairly short and the flow of the document depends= on > them being in their particular location. >=20 > Section 10 could go into an appendix, but it makes not a lot of differenc= e, but > past experience has shown that Annex text is a lot less likely to be read= given > how the RFCs are structured. > We had 10 in Annex and moved it up for exactly that reason. >=20 > > - Well Noted that Section 14 Will be removed/. >=20 > > Sorry for being interrupted here, >=20 >=20 > Thanks you so much! >=20 [PT>] My pleasure, Take care; Pascal From nobody Tue May 22 13:55:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756C12D886; Tue, 22 May 2018 13:55:51 -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 ksFhaGrQFFQL; Tue, 22 May 2018 13:55:49 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 48D80124D37; Tue, 22 May 2018 13:55:49 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id f189-v6so9359217pfa.7; Tue, 22 May 2018 13:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YlS7QW+n6C5qCDKyh7VWOujrZ9Js1Ysx3XsdyJWvmo8=; b=Qc8eEzxL/SJ/ReBHGGFm9/J4vOySEhox4uYYUQU0696YLFjWmzpJtnOh3htSVj+62a gpKDAmpORD9ROQdS6EnRMip6LKgtG4vhDNmuXvfvq+cV3fwLStu3llTsiYkE/ysGJeh0 uNQidPHQkWJv6yMyC9glIbrT/Q8XY2+EJ+m4wR/7nWCbZauW8pnbYyh5dF7CGPwo+4RC Pj6B6EeKVz0uqF/urD6mo6GdUm51uIlhlJVYsZMt6GZ6cJtUnGw/N+D0DXqFdleUkQOC BBU59i5FzSve/8PhOcqfGo6IEE+OgvjKS44nEnuVgNkT+k2ljICej1ogXZoi9WyD9A3l S0/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YlS7QW+n6C5qCDKyh7VWOujrZ9Js1Ysx3XsdyJWvmo8=; b=jLOJoTfOLPBd1JRbtcbUYSnnkRAYf6ZjdvYR+wIN7qeDCn3LH8ChBDK7zrBBlVmp+F 8vmilUsWAWcwK4hUl14BnXjUAtDJTYCwXhVHZ326lCe3XUapGCNkIzqVhcI/CJUIe9yL gTp+NNGolel18K67CO0BbPTMZvuhkEMgxiqbtOC32DiVhyIC7e0VE8HQEsVyKHhm9j85 5iNriZqoPJIwiFNLr5C0JAfzA9azctCdtppvM5mh9XRucnfgiwkaR/o/zTg0QtM+PZYH fIZR32oGYkZ1wXxeuI4Xe7vL4PVb62+ZLTArG4YNxoA4kU+JGKUzqN6E/KySf5pMClNt ba0Q== X-Gm-Message-State: ALKqPwfNQXUKls7KDeCqFI0km1n7/oRFvqDrfMZ5Uw/+HWBo9ExW5Pc3 nPgoYrpmz5AC8pt5ht3dfQ19Bw== X-Google-Smtp-Source: AB8JxZrv14ZI3C/oh+zA4w6c0VZ0TzOvCm243FK5lkoWOjPBt7LJmU1bwFUHsR+0c9Ma9aIyEsXixw== X-Received: by 2002:a62:b509:: with SMTP id y9-v6mr34367pfe.121.1527022548495; Tue, 22 May 2018 13:55:48 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id 131-v6sm28768795pfa.128.2018.05.22.13.55.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 May 2018 13:55:47 -0700 (PDT) To: "Pascal Thubert (pthubert)" , Toerless Eckert Cc: "ops-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" , iot-dir , "int-dir@ietf.org" References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <4823a9d3-9ea9-4403-3db8-8e34bb159fd6@gmail.com> Date: Wed, 23 May 2018 08:55:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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: [Anima] RFC7217 [was An IOT DIR review of draft-ietf-anima-autonomic-control-plane] 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, 22 May 2018 20:55:51 -0000 On 23/05/2018 02:06, Pascal Thubert (pthubert) wrote: > Hello Toerless: ... > >>> - "ACP nodes MUST perform standard IPv6 operations across ACP >> virtual >>> interfaces including SLAAC (Stateless Address Auto-Configuration - >>> RFC4862])" >>> >>> They may actually prefer Optimistic DAD RFC 4429 since address duplication >> is highly improbable as long as you . >> > >> Added: >> >> "Optimistic Duplicate Address Detection (DAD)" according to >> is RECOMMENDED because the likelyhood for >> duplicates between ACP nodes is highly improbable as long as >> the address can be formed from a globally unique local assigned >> identifier >> (e.g.: EUI-48/EUI-64, see below). >> > [PT>] > [PT>] I'm unsure what your recommendation for the interface ID is thus the discussion on RFC 7217. Privacy is not really an issue here. Firstly we're talking about devices, not people. More important, we're talking about ULA addresses that will not be visible outside the domain covered by the ACP. So the old-fashioned technique of using modified EUI-64 would be safe, and there is no real need to use RFC7217. However, since RFC8064 recommends RFC7217 for all SLAAC nodes, and the ACP uses SLAAC, RFC7217 is automatically recommended by the existing standards. I don't think we should mention EUI-64. Brian From nobody Tue May 22 22:39:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27428124235; Tue, 22 May 2018 22:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpJQdUU5J_OA; Tue, 22 May 2018 22:39:39 -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 7E1CE1241F8; Tue, 22 May 2018 22:39:39 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3B1EA58C4B8; Wed, 23 May 2018 07:39:34 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1A998440218; Wed, 23 May 2018 07:39:34 +0200 (CEST) Date: Wed, 23 May 2018 07:39:34 +0200 From: Toerless Eckert To: anima@ietf.org Cc: draft-richardson-anima-ace-constrained-voucher@ietf.org Message-ID: <20180523053933.ns6po2p7qgwgbfr3@faui48f.informatik.uni-erlangen.de> References: <20180427153303.22ldck5segkmlxwp@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180427153303.22ldck5segkmlxwp@faui48f.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Adoption call for draft-richardson-anima-ace-constrained-voucher (ends 05/12/2018) 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, 23 May 2018 05:39:42 -0000 Good support in the WG, no dissenting replies. Authors: Please submit name changed version, and chairs will adopt as working group document. Thanks, Toerless On Fri, Apr 27, 2018 at 05:33:03PM +0200, Toerless Eckert wrote: > draft-richardson-anima-ace-constrained-voucher was presented at IETF101 > and received good interest. The authors asked for adoption. As far > as the chairs heard, there was no objection in the room. As new > work, we discussed this with the new AD for ANIMA Ignas Bagdonas and > also concluded that this work would be in scope of our current chater. > > We hereby are officially asking the working group to confirm adoption > of this work: This message starts a two-week adoption call on: > > Title: Constrained Voucher Profile for Bootstrapping Protocols > Name: draft-richardson-anima-ace-constrained-voucher > Authors: M. Richardson, P. van der Stok, P. Kampanakis > URL: https://datatracker.ietf.org/doc/draft-richardson-anima-ace-constrained-voucher/ > > Please express your support or rejection. If you think this document > should _not_ be adopted, please also explicitly indicate the reasons. > This adoption call will end on May 12, 2018. > > More information as follows: > > This document is intended to become standards track ANIMA WG document > (-03 has a format mistake indicating informational, this would be fixed). > > Standard track is desired because it is meant to become the required > voucher format for solutions with (low-end) devices with existing or > future signaling protocols. > > One of the candidate future signaling to use this voucher is > draft-ietf-ace-coap-est. Another one is BRSKI with DTLS > using the CBOR encoding proposed in the document for use cases > of the FairHair association which includes members from ZigBEE, KNX > and Bacnet. It would also be needed to by other 6tisch > documents such as draft-ietf-6tisch-dtsecurity-zerotouch-join > (from which this voucher draft was actually extracted, similarily to > how voucher was extracted from BRSKI). > > The choice for bringing this to anima was done because of the experience > with the first voucher draft, comparing possible working groups and > concluding that ANIMA was best the best WG for it. > > Regards > ANIMA chairs (Sheng & Toerless) From nobody Wed May 23 06:14:14 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19DE12DA6D; Wed, 23 May 2018 06:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 XHHbm0fcyoXm; Wed, 23 May 2018 06:14:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CCA124D6C; Wed, 23 May 2018 06:14:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 71DD520091; Wed, 23 May 2018 09:26:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EEE49262F; Wed, 23 May 2018 09:13:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EA5466C; Wed, 23 May 2018 09:13:42 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org, draft-richardson-anima-ace-constrained-voucher@ietf.org In-Reply-To: <20180523053933.ns6po2p7qgwgbfr3@faui48f.informatik.uni-erlangen.de> References: <20180427153303.22ldck5segkmlxwp@faui48f.informatik.uni-erlangen.de> <20180523053933.ns6po2p7qgwgbfr3@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adoption call for draft-richardson-anima-ace-constrained-voucher (ends 05/12/2018) 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, 23 May 2018 13:14:12 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > Good support in the WG, no dissenting replies. > Authors: Please submit name changed version, and chairs will adopt as > working group document. Posted. =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 iQEVAwUBWwVpAICLcPvd0N1lAQKF/Qf/YtbJfLkwUQ9iGlXJvPVYTW+/7wJGy1d2 pZBHEo/Yaq1ns4Hd90KC0OSehww/XDTOIZANELZAWWNDM0etDzQfCn2r7oN4lsji c/Rz9zidZDJiUK9msvExTR94k3+T4Km7khDZ/EfSX6EXrkBnJB74jxmWlFM3tsFv AFRUE9AcBO6/7/DMTnO9vgTczopwG9ivDehzZxf2a4MkxaY0bFQmvSkq55emkpQN KrZSw5CNLflGF9n2pMMC5Zfwo6EkY4Y69kgs4itbaUmc02G2sE8SkduPaADNnyBe +tGjSgrdvyi0cgqF6RNWOMJFlESDEecxsZyw5WUAQ3r0+EMm0pLjuQ== =Peuy -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 23 15:40:58 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E97BA12D7F6; Wed, 23 May 2018 15:40:50 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152711525090.29911.11435746111124511660@ietfa.amsl.com> Date: Wed, 23 May 2018 15:40:50 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-00.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, 23 May 2018 22:40:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Constrained Voucher Artifacts for Bootstrapping Protocols Authors : Michael Richardson Peter van der Stok Panos Kamapanakis Filename : draft-ietf-anima-constrained-voucher-00.txt Pages : 22 Date : 2018-05-23 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported in the [I-D.ietf-ace-coap-est] protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-00 https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-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/ From nobody Tue May 29 11:44:17 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC2612EB34 for ; Tue, 29 May 2018 11:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4oCx13d6qhJ for ; Tue, 29 May 2018 11:44:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2949129C70 for ; Tue, 29 May 2018 11:44:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C522D20091 for ; Tue, 29 May 2018 14:57:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A64362642; Tue, 29 May 2018 14:43:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A3EE0263F for ; Tue, 29 May 2018 14:43:41 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] recording the need for a document on Operational security for ACP 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, 29 May 2018 18:44:16 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Some private discussion has suggested that there is a need for a document on operational issues (specifically security and PKI) for managing an ACP. While in theory everything should be autonomous, the exceptional situations and the multitude of options of how to deal with them will eventually need some clarification, if only so that they are automated correctly. This is just a note for later on; I think we need some operating ACPs before we can describe issues with them. =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 iQEVAwUBWw2fWoCLcPvd0N1lAQJmcAgAkWiuyC8uWjCJYdq/6ncJbZKXNM6Mivjh o4M9P61ikBolNYp80hULW7s38TAWm2esOG8n5gspGtN3kcuy+/0KSsiq1F3bBAuJ 1zOoWYg4xdGqcNZ1ZlCjQar34a7XBLN9L9Ih+zTjC6jJygalEm+PALjR5+9BA89s 3iCQvPMjQlitQPeGLEmX8D0lu0ZI8XLwWkU6KGL9shWnr2uqofB8712aeXTLmFiP VxP03anjzF8tTs+NUVEhWiUW3vxnVJzKLwn+luXpJh3hXNhhKiVRmT2p9g9p+sGO u+9+V2Gd3v9P4Ibqvu4ilLcOJo6dsHHpcLK1WW6OlXAvoy7VcxPX1g== =2C82 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 29 13:00:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BAB12EC87 for ; Tue, 29 May 2018 13:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANA8pLPtwouA for ; Tue, 29 May 2018 13:00:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3157812EC5C for ; Tue, 29 May 2018 13:00:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 26DFF20091 for ; Tue, 29 May 2018 16:13:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C12262642; Tue, 29 May 2018 16:00:10 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BE1BF263F for ; Tue, 29 May 2018 16:00:10 -0400 (EDT) From: Michael Richardson to: anima@ietf.org In-Reply-To: <1787.1526523912@dooku.sandelman.ca> References: <1c1b65c5ff117f7a092471c366ee93ef@xs4all.nl> <7803.1525733701@localhost> <9834a534d66d57dc1bdb8d106f6a453f@xs4all.nl> <1787.1526523912@dooku.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] getting the constrained MASA voucher signing public key to JRC 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, 29 May 2018 20:00:46 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In BRSKI and the constrained version described in draft-ietf-6tisch-dtsecurity-zerotouch-join, the voucher is signed by the MASA using a key that has been pre-installed into the pledge by the manufacturer. The pledge can validate the voucher because the MASA knows (by constructin) which keys the pledge knows about. The Registrar (JRC) that mediates the operation, and which is vouched for by the voucher using the pinned-domain-cert. The Registrar does not *NEED* to validate the voucher, implementations might want to do this because it's useful to know whether the voucher validates as part of the audit-trail. In the CMS case, there isn't any great constraint on the signed CMS structure, and one can easily include any needed public keys for the MASA as part of the unprotected SignedData.certificates. When the signature mechanism is COSE however in the constrained-voucher situation. In such a situation, the RFC8152 provides four buckets: protected unprotected payload signature We are using the CBOR SID mechanism to provide a keys for the mapping of the YANG voucher model into the protected bucket. It's unclear to me if we should be including "alg" into that bucket as well.=20=20 The question that arises is how (and if!!) to convey the MASA's public key = to the Registrar. Secondary to this is in what format(s). Options are: 1) use the COSE(8152, section 3.1) kid parameter. 2) actually say we are using CWT, and make use of the claims in RFC8392, and the x5c is listed in some other document I can't find right now. =20=20=20 3) use our own SID value(s) for some set of Raw-Public-Key or PKIX format k= ey which would be placed in the unprotected bucket. The Registrar would be encouraged to *remove* those keys from the unprotected bucket to reduce space. 4) provide an entirely new BRSKI-MASA API call by which the Registrar can retrieve the right set of public keys to validate the voucher with. 5) use the existing /voucherrequest, but define the result (when an application/cbor+cose voucher request is presented) to be a multipart result, with the second piece being the public key "bag". 6) like (5), but instead of MIME multipart, return a CBOR array with the voucher as the first item, and the extra keys as additional entries. =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 iQEVAwUBWw2xSoCLcPvd0N1lAQIdXgf+NV+0+Yv3TnfdZaaLVWc+RLOnZzVsDAeA FeyVUtOuzIOqvk2Cd+Or2LnyO0f0GvRxTAjJSR0twcbYBnpUft66ZhNV5eR6jgmW hv2075Kj6v9teARRl0BCn9OlhmA4reFY0aK+kLFKaxJ3OGAgUCYIG3/ccD5JLkX/ 1TDMnGTdgufH9jcA00ZlQwnnZkeaWa+CCd8uFo9Xrt+Z/vAoxOYh0rnJXzEPmr3d 4hvkUDR8lfhdxaY3A++rIOgI9O+PAzSRvWWw7utHvzvcMARMA0oijVocSYjUwm5T ZMmyW2VC+8VepJvjx8+oOblLOxPUtWOXmQJA9F6Wpdpy3hSvbEEl4g== =Qy4i -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 30 18:53:31 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200E61274D2; Wed, 30 May 2018 18:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBZeiRhXKHTZ; Wed, 30 May 2018 18:53:26 -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 7506B12D871; Wed, 30 May 2018 18:53:26 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A9CCA58C560; Thu, 31 May 2018 03:53:21 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 99BC34401A4; Thu, 31 May 2018 03:53:21 +0200 (CEST) Date: Thu, 31 May 2018 03:53:21 +0200 From: Toerless Eckert To: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org Message-ID: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8048.1522092969@obiwan.sandelman.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 01:53:29 -0000 Thanks a lot, BRSKI authors (i think primarily Michael had the pain of working through my feedback holding the editor pen.) I have examined the mailing list feedback for all the incremental work done since -09 including calls we had discussing/resolving several of the issues. I like most of the work/fixes done towards -14 and agree or at least accept the rest. Just few tiny bits leftover (see below). For brevity i am not going to walk through the other points, but thanks a lot for the discussion replies, especially when proving me wrong (;-). [ Pls. let me know if i overlooked responding to any open issue you wanted to get an answer from me to, i hope/think, there is none. ] I am pretty happy with the BRSKI document now (-15). Obviously the last versions also had a lot of other important fixes/improvements made, not only those from the shepherd review. The authors asserted that the document is ready for WG last call, and i agree. Cheers Toerless --- > > f) IMPORTANT: Please add/define the term "ANI" > > > ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and > > Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI > > systems (pledges, proxies, registrar) have specific requirements detailled in > > the document. > > The Autonomic Network Infrastructure as > defined by />. This document details specific requirements for pledges, > proxies and registrars when they are part of an ANI. > > Does this work for you? I would prefer to have the simple definition "ANI == systems that support both BRSKI and ACP" in the doc itself. Threre is really no single authoritative normative document for ANI, so it should simply be stated equally in BRSKI and ACP. Rest of text is fine. --- > > Without this term we can not nail down the explicit requirements against > > ANI Pledges, Proxies, Registrars that we need from the document (and distinguish > > from requirements against any non-ANI adaptation of BRSKI). I added according > > comments into other parts of the doc. > > > g) Please replace "MASA server" with "MASA service" everywhere. > > I prefer to just say "MASA" actually. > Are you okay with that? Yes. There are a few leftovers of "MASA server" in -14 though. Pls fix. --- > There is no requirement that the Join Registrar is also the EST for the > purposes of ongoing certificate renewal. I don't know if you are speaking > about certificate lifetime management (renewal, etc.) when you say > "EST Enrollment service". I'll assume that you mean that for the moment. > > In a big network I would want the roles (bootstrap and initial certificate, > vs certificate renewal) split up. Lets in any case consider this issue closed or BRSKI, because it loooks now like scope creep to me to discuss it for this draft. I'll probably have this discussion on my hand for ACP anyhow, because (only) ACP needs to be concerned about initial bootstrap and renewal (just working through that in ACP doc because of the ongoing review of it). --- 4.1.1: > transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 The way i see it, the normative approach with TCP circuit proxy would always only have TCP, right, e.g.: the line should say transport-proto = IPPROTO_TCP ; Not considering non-normative ; options like Appendix C. From nobody Wed May 30 18:56:16 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF412EBB9 for ; Wed, 30 May 2018 18:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-PY8D2hpn-C for ; Wed, 30 May 2018 18:56:12 -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 45EF312EBAD for ; Wed, 30 May 2018 18:56:12 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6A63058C560; Thu, 31 May 2018 03:56:08 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5C5D64401A4; Thu, 31 May 2018 03:56:08 +0200 (CEST) Date: Thu, 31 May 2018 03:56:08 +0200 From: Toerless Eckert To: anima@ietf.org Cc: draft-ietf-anima-bootstrapping-keyinfra-all@ietf.org Message-ID: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 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, 31 May 2018 01:56:14 -0000 Dear ANIMA WG, After thorough review and discussions on the mailing list and in bootstrap meetings, leading to the -15 version the authors and WG chairs 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 June 14th, 2018. Thanks and best regards Toerless (for the ANIMA chairs). From nobody Wed May 30 19:45:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E53112EB57; Wed, 30 May 2018 19:45: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 8cGYqCJ0D5Ve; Wed, 30 May 2018 19:45:33 -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 492F812EBC5; Wed, 30 May 2018 19:45:29 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id w12-v6so7797945pgc.6; Wed, 30 May 2018 19:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ntOVE/yVnKiob8Hcw3FXaA+FpwJ0KbGx+BkeMwIDDWc=; b=QhCYKbRrHah/EGlrQk5Xl4P6wbtwTDM0HaBoXs3hthmG05epscjSg07c9fiaO+WYOo o/sEAm/soVKGLDIOTBWg8bNn5sIJntHXGzEDJT58Py5U3TXMznBEYH7W0KBZs9CrDMnv i56yjC/jSqFAbinfl5QFfpj/mGDUeppll/NxqjMoia5prbdN/Lbxd/svBzLGzrK1n6TY Sfv1kHKgmhroc6MgUcHDvRkqaosXJ9zD/0fHLSKCvAE8XrJco4Oxq1b/y/nkvQXUII1L NEd37D2nE4ot/Hg3oE+YolPKs890+5JewI4k0NIHUn03VZ4zIjFYGOLJFdk6wdPdFgmR UumA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ntOVE/yVnKiob8Hcw3FXaA+FpwJ0KbGx+BkeMwIDDWc=; b=FFExGP03Tj22XjcYlY1imAeiT7Xsq7CI40bvHOznIcKgcGgI9ueIHpRq5OjYEJO8cL /uBH+ecn0HrXHOrc4RKyv+pwXpBP81dlFXcN7EPcfhsZkjcBxoj5S3W+eH+xeMQggtZe +QsCnrk6XgF0O4QF1qSwmB4IBlw9dRw5GcT+J3HBIeLDq7sMcpym4fxnnXQfE+84Znpg yonOs2eYXVcfT02EDZKOVaNCBQQSB7HtlGQjMXPlqq5i8PLncNIaph9YmeOJheqxyo2h vlORmbyPFf6+9TBDNmqGvzXwxH2ZBpszducaeNMsprqhrkN8IxS9ftkBpSM8ptVPAoLb moEw== X-Gm-Message-State: ALKqPwdtFvuHnkiSkDnvqaKimcP2IjSkkbBc9educy8Zh69o6Xf+Rzxb WjqHDM3PDkTIcKl8VMdTQp7kJw== X-Google-Smtp-Source: ADUXVKJ6Q8LHc9cM/orc+sSp/SkXfEkQjECh+OEoriH/s9DDNGD37JlIoIhCBBLG2scPWXlaCQlaKQ== X-Received: by 2002:a62:2281:: with SMTP id p1-v6mr5122106pfj.53.1527734727417; Wed, 30 May 2018 19:45:27 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z82-v6sm803862pfk.30.2018.05.30.19.45.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 19:45:26 -0700 (PDT) To: Toerless Eckert , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> Date: Thu, 31 May 2018 14:45:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 02:45:35 -0000 On 31/05/2018 13:53, Toerless Eckert wrote: ... > 4.1.1: > >> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 > > The way i see it, the normative approach with TCP circuit proxy would > always only have TCP, right, e.g.: the line should say > > transport-proto = IPPROTO_TCP ; Not considering non-normative > ; options like Appendix C. There's kind of a general point about extensibility here. We're using CDDL as a normative notation (which may well become slightly awkward unless the CDDL draft advances soon), but are we intending to interpret it formally? In other words, if we later want to add " / IPPROTO_UDP / IPPROTO_IPV6" to implementations, do we have to circle back and update the BRSKI RFC? (And so on for any other documents that cite intrinsically extensible items like transport-proto.) One option in this case is to include "/ IPPROTO_UDP / IPPROTO_IPV6" in the syntax with a specific note that they are not currently defined and MUST be treated as errors if received. Brian From nobody Wed May 30 20:01:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FE012EC74 for ; Wed, 30 May 2018 20:01:46 -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 ZxXwQoKUmmp3 for ; Wed, 30 May 2018 20:01:44 -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 678F91314D7 for ; Wed, 30 May 2018 20:01:44 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id a14-v6so10015831pfi.1; Wed, 30 May 2018 20:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FPriHUIA7hKc+F6jRfj9mB+vasnYXgZcJWTHAeG+KC4=; b=g9cPXPs+3M9kpzHD45/rg6eBAJshN7UXnaG8nWYSLOcZvyr36KRBO16WXFJIRzDd8n 5eYiXcenY2ZRlHPRNJ/yVvk3CSmTaifHJq4k2PowVWJLZkVD9Q72aev0Xgh3/nnuhW2i eEaVkV5uByZl/2AZs+uLkjdaPnoTeps7uK7grVkkDJfD67CuHByq0l0r4rM4nmCN0O+Y OKmQLW5YLzG2n1YZ2Z5FfIVQFHK+b/D03ZobSXGTCdY5cMLATQgrf+TSohSN2Cg0DwS/ dJElwuP0N6+Jai/XbVk1QYaACaQMzrquA+gfGWlaawMpJyeasp1dM3GN1qLTVrYC4rWJ qgCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FPriHUIA7hKc+F6jRfj9mB+vasnYXgZcJWTHAeG+KC4=; b=mTRIU7CuyAyi2chqtf1R8LOY45Uyr7Ec+iaSnySWjkC7UsVmUb+8WMM/0W/gvJqMj4 Bf0sbwDNoIVXkb5sZZy2Vn1P+VoF802t1a5VwftrUk5gcZZfsrIbwnMm75b+SaR1W8Ur UjiZdMtvM/a+nqk9mHmTuzEskVCI9jOlJxUnUaiKAz9msmnW0wekEqjJBEEZNJ2JR+aE 7i9xovIE8mqFx+xaHUX+xWP/dyutFE9VPme7dMr1UI4asRz9fle7L+pnRvH7pIfAP+r/ yQ935HPTzLB2Dn2P5P2D4Cb0XHx05Jgu6SBggTyelGx6xL4koOWf0khpY6csNCt0o+3X DB6g== X-Gm-Message-State: ALKqPweZaaQuWkX71T56ifLHmG1tzoVmdkWeQdJqbIQ49rboT1WDSlc3 ps8OHCiO3ZBlgo4Spqx8PC7evQ== X-Google-Smtp-Source: ADUXVKKSa1p3tUyHDVAjN+SKyrRK0RFT/5iX1jHPuVBP568xey0CbnT3TuWES721d76tIxjEbqaeRg== X-Received: by 2002:a65:5a88:: with SMTP id c8-v6mr3977744pgt.287.1527735175254; Wed, 30 May 2018 19:52:55 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id l23-v6sm35641475pgc.61.2018.05.30.19.52.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 19:52:54 -0700 (PDT) To: Toerless Eckert , anima@ietf.org Cc: draft-ietf-anima-bootstrapping-keyinfra-all@ietf.org References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Thu, 31 May 2018 14:52:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 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, 31 May 2018 03:01:47 -0000 I can answer quickly. Apart from the minor point in my previous message, I believe that the GRASP part of this is correct, and I have exercised it in the latest versions of my demo code (Reggie.py, Procksy.py and Pledji.py at https://github.com/becarpenter/graspy). (They were created for the -12 draft but I believe they still apply to -15.) I have no issues with the rest of the draft, but I'm not a security expert. Regards Brian On 31/05/2018 13:56, Toerless Eckert wrote: > Dear ANIMA WG, > > After thorough review and discussions on the mailing list and in bootstrap > meetings, leading to the -15 version the authors and WG chairs 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 June 14th, 2018. > > Thanks and best regards > > Toerless (for the ANIMA chairs). > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed May 30 23:56:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25AD12EB56 for ; Wed, 30 May 2018 23:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNNMsSBH_PFR for ; Wed, 30 May 2018 23:56:22 -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 76E6B12EB48 for ; Wed, 30 May 2018 23:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2437; q=dns/txt; s=iport; t=1527749781; x=1528959381; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=5r4NySmSl+UFou5wCK37Gujl2m6Zv92D7wW3tBipHCA=; b=PL2EmAjNOMY2hl87mycC3o5mZj5ltrCwzPtWSPNuWHupP1HP95kIEc6o H3m+sUJyxhhMRd8hD0pxpbFQ/zPupF0PcNugD1J3pec8hcgrt5Rzgx172 ait8Xowddmyvrm2nFhAcV0Chj9g/gm5/1BwfeSGI18kV54Yum8dfU3rEj M=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQBAmw9b/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQmbRIog3eIY41SKYEPk1CBZAgDGAuESQKCQDcVAQIBAQE?= =?us-ascii?q?BAQECbBwMhSkBAQQBASFLCxALGCoCAicwBgEMBgIBAYMeAoF/D6YrghyIRoF?= =?us-ascii?q?ZCgWKUIEzgmmDEQEBgSiDOIJUAphmCYNHgVWJPgaBO4Nwgj+FIpEVgVcigVI?= =?us-ascii?q?zGggbFTuCQ4sQhUA9MI8uAQE?= X-IronPort-AV: E=Sophos; i="5.49,463,1520899200"; d="asc'?scan'208"; a="4153775" 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; 31 May 2018 06:56:19 +0000 Received: from [10.61.98.166] (dhcp-10-61-98-166.cisco.com [10.61.98.166]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w4V6uJMQ011950; Thu, 31 May 2018 06:56:19 GMT To: Toerless Eckert , anima@ietf.org Cc: draft-ietf-anima-bootstrapping-keyinfra-all@ietf.org References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF Message-ID: <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> Date: Thu, 31 May 2018 08:56:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vgxpXyjHNdnOWqX0QL0adh4JfhHlQEgyj" Archived-At: Subject: Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 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, 31 May 2018 06:56:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vgxpXyjHNdnOWqX0QL0adh4JfhHlQEgyj Content-Type: multipart/mixed; boundary="6xnv2OPZZXLqzE5jl1DgQh4Xdjrig2uzX"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert , anima@ietf.org Cc: draft-ietf-anima-bootstrapping-keyinfra-all@ietf.org Message-ID: <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> Subject: Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> --6xnv2OPZZXLqzE5jl1DgQh4Xdjrig2uzX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US I have reviewed the document and we have a PoC.=C2=A0 I am also aware of others that have done PoC code. I am not aware of any issues. Eliot On 31.05.18 03:56, Toerless Eckert wrote: > Dear ANIMA WG, > > After thorough review and discussions on the mailing list and in bootst= rap > meetings, leading to the -15 version the authors and WG chairs think th= e draft > is now mature enough for working group last call. > > This e-mail starts a two-weeks period for evaluation of this document b= y the WG. > > Please provide your feedback on the ANIMA mailing list by end of June 1= 4th, 2018. > > Thanks and best regards > > Toerless (for the ANIMA chairs). > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --6xnv2OPZZXLqzE5jl1DgQh4Xdjrig2uzX-- --vgxpXyjHNdnOWqX0QL0adh4JfhHlQEgyj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlsPnJIACgkQh7ZrRtnS ejORQgf/Z39KlrBOVN6ET+z/InYLGidR5RQniGAq1tlaALvbhoOvxo+cENpMi0+0 E7voF7sTMa3G00Tw2a2J0tfzS2Vcz6KGsQh+4jeCljnC/xsoqMbZdJSOCMXVF98q TTbFZPNYr3BQUdqo3gEiLDKrWgNV5ExNvmvlQ9giWm396Z6oWFR7UHZjZQDTDdP9 EwD6RLMAH+PIgg6uwTCnkE8MggyDYH8CiElsxkcoYCZ82KlRG/GTn+2bkESfWndR tg+JDpbk7fRN74asuySDj12bviEfsfQD11GuRYw8K2lsOGYuuuKLqfA3Fe2MUuEg 4F2sOe2K8nHWFV1SUC4NL/HStz6nPw== =Ew8K -----END PGP SIGNATURE----- --vgxpXyjHNdnOWqX0QL0adh4JfhHlQEgyj-- From nobody Thu May 31 11:44:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5193812F4E1; Thu, 31 May 2018 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWW-FL6RrkEp; Thu, 31 May 2018 11:43:55 -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 0BD3312EB87; Thu, 31 May 2018 11:43:51 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id AB88558C4AE; Thu, 31 May 2018 20:43:47 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9DC0F4401A4; Thu, 31 May 2018 20:43:47 +0200 (CEST) Date: Thu, 31 May 2018 20:43:47 +0200 From: Toerless Eckert To: Eliot Lear Cc: Toerless Eckert , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org Message-ID: <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] references to code ? (was: Re: WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15) 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, 31 May 2018 18:44:02 -0000 Thanks, Eliot Good point, forgot to ask/mention this point in my previous emails. As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to mention known existing implementations, especially open source, even if just PoC. But i have no idea if and/or how thats seen to be appropriate by IETF standards. Traditionally i think it was not done, but then again, with the amount of focus (not to say hype ;-) the IETF does around open source and hackathons, it almost sounds absurd to me not to mention such code. I am only aware of github.com/cisco/libest, but would love to see any known code be mentioned. Single sentence with references to appropriate URLs to those implementations would suffice IMHO. What do others think/know about BCP in IETF protocol RFC re such mentioned of known code ? (i know, there can be implementation experience drafts/RFC later on as well, but i think that's an independent, more in-depth effort.) Cheers Toerless On Thu, May 31, 2018 at 08:56:17AM +0200, Eliot Lear wrote: > I have reviewed the document and we have a PoC.  I am also aware of > others that have done PoC code. I am not aware of any issues. > > Eliot > > > On 31.05.18 03:56, Toerless Eckert wrote: > > Dear ANIMA WG, > > > > After thorough review and discussions on the mailing list and in bootstrap > > meetings, leading to the -15 version the authors and WG chairs 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 June 14th, 2018. > > > > Thanks and best regards > > > > Toerless (for the ANIMA chairs). > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > -- --- tte@cs.fau.de From nobody Thu May 31 11:48:26 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3487A12EB8D; Thu, 31 May 2018 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGiYwp0cP14L; Thu, 31 May 2018 11:48:22 -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 9E25912E891; Thu, 31 May 2018 11:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5092; q=dns/txt; s=iport; t=1527792501; x=1529002101; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=LLViRLR4gJQTnV1DUl8fxV13fgaWwiIHIrW8GpcOHTQ=; b=LFSa46qnIx3ROgDIZntNVCUyUHuEUm5cK1rMndlao6yKLePY7OktLb69 D4sf0vWggBIjfLrZQ88f41RDllpIbPI4SKoOPe5iI9FKsD3TXCKIoyJ5S J0jAsKn+72webNNXSQQpfy0JFhXqjSt4NCHt1wsWjWmgATV6x2VWHfLRc c=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQB9QhBb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQmbRIog3eIY41UCCGBD45Fhm8IAxuEUQKCJTcVAQIBAQE?= =?us-ascii?q?BAQECbBwMhSkBBSMEUhALBAoKIwcCAlcGDQgBAYMeAoF/p22BaTMfiCCBWQ+?= =?us-ascii?q?KVIEPJAyCXYMRAoRgglQCmGkJg0eBVVCIbwaBeoV3hSKRFYFXIoFSMxoIGxW?= =?us-ascii?q?CfgmCP4M0ilQ9MI9hAQE?= X-IronPort-AV: E=Sophos;i="5.49,463,1520899200"; d="asc'?scan'208,217";a="4229890" 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; 31 May 2018 18:48:19 +0000 Received: from [10.61.85.178] (ams3-vpn-dhcp5555.cisco.com [10.61.85.178]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w4VImI99003304; Thu, 31 May 2018 18:48:19 GMT To: Toerless Eckert Cc: Toerless Eckert , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF Message-ID: Date: Thu, 31 May 2018 20:48:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="flhyEKndDLovxpxNMIwmF2rgMWTxI7HPq" Archived-At: Subject: Re: [Anima] references to code ? (was: Re: WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15) 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, 31 May 2018 18:48:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --flhyEKndDLovxpxNMIwmF2rgMWTxI7HPq Content-Type: multipart/mixed; boundary="OlU3EDpXk1mecNuHnaTcWmXSRZR0TGp8U"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert Cc: Toerless Eckert , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org Message-ID: Subject: Re: [Anima] references to code ? (was: Re: WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15) References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> --OlU3EDpXk1mecNuHnaTcWmXSRZR0TGp8U Content-Type: multipart/alternative; boundary="------------D4DF082022018A92E15CD030" Content-Language: en-US This is a multi-part message in MIME format. --------------D4DF082022018A92E15CD030 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 31.05.18 20:43, Toerless Eckert wrote: > Thanks, Eliot > > Good point, forgot to ask/mention this point in my previous emails. > > As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to > mention known existing implementations, especially open source, even if= just PoC.=20 > > But i have no idea if and/or how thats seen to be appropriate by IETF > standards. Traditionally i think it was not done, but then again, > with the amount of focus (not to say hype ;-) the IETF does around > open source and hackathons, it almost sounds absurd to me not to mentio= n such code. > > I am only aware of github.com/cisco/libest, but would love to see > any known code be mentioned. Single sentence with references to > appropriate URLs to those implementations would suffice IMHO. > What do others think/know about BCP in IETF protocol RFC re such mentio= ned of known code ? I don't mind that pointer being listed, though we should *always* check with the code developers before doing so.=C2=A0 In this case we can check= with them to be sure. The 2nd piece of code is not open source and not by Cisco. Eliot --------------D4DF082022018A92E15CD030 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 31.05.18 20:43, Toerless Eckert wrote:
Thanks, Eliot

Good point, forgot to ask/mention this point in my previous emails.

As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to
mention known existing implementations, especially open source, even if j=
ust PoC.=20

But i have no idea if and/or how thats seen to be appropriate by IETF
standards. Traditionally i think it was not done, but then again,
with the amount of focus (not to say hype ;-) the IETF does around
open source and hackathons, it almost sounds absurd to me not to mention =
such code.

I am only aware of github.com/cisco/libest, but would love to see
any known code be mentioned. Single sentence with references to
appropriate URLs to those implementations would suffice IMHO.

What do others think/know about BCP in IETF protocol RFC re such mentione=
d of known code ?

I don't mind that pointer being listed, though we should always check with the code developers before doing so.=C2=A0 In this case we= can check with them to be sure.

The 2nd piece of code is not open source and not by Cisco.

Eliot
--------------D4DF082022018A92E15CD030-- --OlU3EDpXk1mecNuHnaTcWmXSRZR0TGp8U-- --flhyEKndDLovxpxNMIwmF2rgMWTxI7HPq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlsQQ3IACgkQh7ZrRtnS ejPVcgf/VtI774FavcLfNCQDMJmn6/wE9OsP09KagahoUjDkPY1f77jWaZdfMj7t URqDFl0YXgJ6oGDkWwhJVDUnosqtUytT5JF2ua/F9EWy3/R/hxFA21kBi3pkX2Fd +76TAikp723AxY/FrCLStjq8x95Kvts3cKz5LFauHvnJhNrDJAt7FG8hXfq8Xn5J 9KzXB9+yu1ZOXRfyrp+5CbuhqET1pUN9+1rBj1TYo13esgmISrFqXqgYhQYt4yjK P7wTSMVKj6RV2XG8HTvigqScz3FROYAsojf3hwIVOzzSA+JQRoQu72vocdq8Nxb7 Nh3+VRkWrh1pedF8vPwM3VhE6BXRbQ== =5Wut -----END PGP SIGNATURE----- --flhyEKndDLovxpxNMIwmF2rgMWTxI7HPq-- From nobody Thu May 31 12:07:53 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32375131465; Thu, 31 May 2018 12:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX-0FDAEv46y; Thu, 31 May 2018 12:07:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AD7126D3F; Thu, 31 May 2018 12:07:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F3AC20093; Thu, 31 May 2018 15:20:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 747012DA9; Thu, 31 May 2018 15:07:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 70F8A2DA1; Thu, 31 May 2018 15:07:15 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org In-Reply-To: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 19:07:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: >> > f) IMPORTANT: Please add/define the term "ANI" >>=20 >> > ANI - "Autonomic Network Infrastructure". Systems that support bot= h BRSKI and >> > Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-p= lane]). ANI >> > systems (pledges, proxies, registrar) have specific requirements d= etailled in >> > the document. >>=20 >> The Autonomic Network Infrastructure as >> defined by > />. This document details specific requirements for pledges, >> proxies and registrars when they are part of an ANI. >>=20 >> Does this work for you? > I would prefer to have the simple definition "ANI =3D=3D systems that= support > both BRSKI and ACP" in the doc itself. Threre is really no single aut= horitative > normative document for ANI, so it should simply be stated equally in = BRSKI and > ACP. Rest of text is fine. I'm not getting what you are suggesting. I think you are saying that we shouldn't point at ACP for the ANI term, but rather define it ourselves? >> > Without this term we can not nail down the explicit requirements a= gainst >> > ANI Pledges, Proxies, Registrars that we need from the document (a= nd distinguish >> > from requirements against any non-ANI adaptation of BRSKI). I adde= d according >> > comments into other parts of the doc. >>=20 >> > g) Please replace "MASA server" with "MASA service" everywhere. >>=20 >> I prefer to just say "MASA" actually. >> Are you okay with that? > Yes. There are a few leftovers of "MASA server" in -14 though. Pls fi= x. fixed them all, I hope. >> There is no requirement that the Join Registrar is also the EST for = the >> purposes of ongoing certificate renewal. I don't know if you are sp= eaking >> about certificate lifetime management (renewal, etc.) when you say >> "EST Enrollment service". I'll assume that you mean that for the mo= ment. >>=20 >> In a big network I would want the roles (bootstrap and initial certi= ficate, >> vs certificate renewal) split up.=20=20=20=20 > Lets in any case consider this issue closed or BRSKI, because it looo= ks now like > scope creep to me to discuss it for this draft. I'll probably have th= is discussion > on my hand for ACP anyhow, because (only) ACP needs to be concerned a= bout > initial bootstrap and renewal (just working through that in ACP doc b= ecause > of the ongoing review of it). okay. > 4.1.1: >> transport-proto =3D IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 > The way i see it, the normative approach with TCP circuit proxy would > always only have TCP, right, e.g.: the line should say > transport-proto =3D IPPROTO_TCP ; Not considering non-normative > ; options like Appendix C. I'll reply to Brian. =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 iQEVAwUBWxBH4ICLcPvd0N1lAQLquAgAmRqI+HwAgNa5P8vdt9BUMearT1TAnMa7 DUz151uM0XZjuWJOjLKFURL3v1wqFYCWBCzQvZCHaddy+oYb1dG8Nqmk2a4grXA/ Fsor3kPfaQAdews5XUmJJ6FFMca4L1TCysNLrrWjLC7n/gq63nvVo3sboDTkYdoR Roe0gPjDJytP0LSubxImOBl1eUiZThXv+V5Y+8e6hSJBkvc6s+CL/wURFFuWMtp9 YOP6nXtc1wVxBo0Q5D/JWo3nkkzAZyyjswcEUDiNQSmnCWBbSQYpMlTaxhQkG4ex cyH+Eh4HnkCWBCXfsRphZcZORTgWqu73oRZ39p+u/FJqylftaD0wOA== =9PwF -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 12:09:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9B812EC93; Thu, 31 May 2018 12:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPNYCnNbNfkj; Thu, 31 May 2018 12:09:15 -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 DC6FD12F2A2; Thu, 31 May 2018 12:09:14 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A872F58C4AE; Thu, 31 May 2018 21:09:10 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9874E4401A4; Thu, 31 May 2018 21:09:10 +0200 (CEST) Date: Thu, 31 May 2018 21:09:10 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org Message-ID: <20180531190910.osegs5jnxpxkobft@faui48f.informatik.uni-erlangen.de> References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 19:09:18 -0000 Brian: 1. The GRASP specification of 4.1.1 should only describe what is required and valid for the standard of GRASP objective, which is the TCP proxy. Appendix C proxy option is not full/formally worked out, thats why its in an appendix. If the authors want to propose a formal GRASP option for appendix C proxy, then that should better go into appendix C as well. Rather a bit more duplicated text then confusing what objective details are used for what type of proxy. Therefore only "IPPROTO_TCP" IMHO. Also nitpick: locator = [ O_IPv6_LOCATOR, ipv6-address, .. should be: locator-option = [ O_IPv6_LOCATOR, ipv6-address, .. (because prior definition of "flood-message" does say "locator-option"] 2. A value of IPPROTO_IPV6 which i guess would be desired for an appendix C proxy would IMHO be an extension to whats defined in GRASP. An RFC specifying that would therefore have to declare itself to be an update of GRASP. I don't think this is a big deal. It would become somewhat frustrating when we have to figure out multiple extensions to GRASP header options across multiple future RFCs. But the GRASP headers are not that complex, so there is not that much to do. A simple option could be to make a simple rev of GRASP RFC that accumulates all extensions - after a while, e.g.: after three RFCs that extend GRASP. Btw: The specific issue of extening transport options could have been avoided by permitting 0..255 in GRASP. Cheers Toerless On Thu, May 31, 2018 at 02:45:29PM +1200, Brian E Carpenter wrote: > On 31/05/2018 13:53, Toerless Eckert wrote: > .... > > 4.1.1: > > > >> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 > > > > The way i see it, the normative approach with TCP circuit proxy would > > always only have TCP, right, e.g.: the line should say > > > > transport-proto = IPPROTO_TCP ; Not considering non-normative > > ; options like Appendix C. > > There's kind of a general point about extensibility here. > We're using CDDL as a normative notation (which may well become > slightly awkward unless the CDDL draft advances soon), but are > we intending to interpret it formally? In other words, > if we later want to add " / IPPROTO_UDP / IPPROTO_IPV6" > to implementations, do we have to circle back and update the BRSKI > RFC? (And so on for any other documents that cite intrinsically > extensible items like transport-proto.) > > One option in this case is to include "/ IPPROTO_UDP / IPPROTO_IPV6" > in the syntax with a specific note that they are not currently > defined and MUST be treated as errors if received. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu May 31 12:09:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188B812FA77; Thu, 31 May 2018 12:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_5IgDdiIMRu; Thu, 31 May 2018 12:09:42 -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 E374E12F29A; Thu, 31 May 2018 12:09:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F72A20093; Thu, 31 May 2018 15:22:44 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 443D02DA9; Thu, 31 May 2018 15:09:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 40DB02DA1; Thu, 31 May 2018 15:09:06 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Toerless Eckert , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org In-Reply-To: <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 19:09:44 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > On 31/05/2018 13:53, Toerless Eckert wrote: > ... >> 4.1.1: >>=20 >>> transport-proto =3D IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 >>=20 >> The way i see it, the normative approach with TCP circuit proxy would >> always only have TCP, right, e.g.: the line should say >>=20 >> transport-proto =3D IPPROTO_TCP ; Not considering non-normative >> ; options like Appendix C. > There's kind of a general point about extensibility here. > We're using CDDL as a normative notation (which may well become > slightly awkward unless the CDDL draft advances soon), but are > we intending to interpret it formally? =20=20=20=20 > In other words, > if we later want to add " / IPPROTO_UDP / IPPROTO_IPV6" > to implementations, do we have to circle back and update the BRSKI > RFC? (And so on for any other documents that cite intrinsically > extensible items like transport-proto.) I don't mind saying that only IPPROTO_TCP is normative in the CDDL, but I think that the point of listing a few options here is so that implementations actually check the value. > One option in this case is to include "/ IPPROTO_UDP / IPPROTO_IPV6" > in the syntax with a specific note that they are not currently > defined and MUST be treated as errors if received. I prefer this to the not listing them. =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 iQEVAwUBWxBIT4CLcPvd0N1lAQL7UQgAq47eWXZPMIh1GCnlP7Mrg/6FSd+nsZ0l wRVRIO8SnH0lXOQ4VX/5EgDn7lhUg0PulwlxQ2QW6Y5dUPBTcjo1LhQ796jf72FV WdQDqEDSVCeRTU02lsiblT/o4ti2+gEoy5oPIozNI88ZaUyRFPUB5P38ipbQs9LA tTA6FgMEw1hUZN2s6La7I1jvT6oVvbzYJnUvQLbhWV7Pou06lpIshTte9/sVDGvy bKcqvDtqoh+Wt/7TWLOuT1/zPpQDdnvPDl58NvksvPHTjiD4s2KPjFTVhq8f02qD s16avEI5zOh3DAmVggEU6JDjB1bcDVN7oX9AmIMxHLwdB8AqrOmP6w== =vVYQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 12:10:01 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DAF13155F; Thu, 31 May 2018 12:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFpkCCorqX14; Thu, 31 May 2018 12:09:48 -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 E98D712F29A; Thu, 31 May 2018 12:09:47 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E9F9E58C4C9; Thu, 31 May 2018 21:09:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E352C4401A4; Thu, 31 May 2018 21:09:43 +0200 (CEST) Date: Thu, 31 May 2018 21:09:43 +0200 From: Toerless Eckert To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org Message-ID: <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <26062.1527793635@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26062.1527793635@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 19:09:59 -0000 On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: > > I would prefer to have the simple definition "ANI == systems that support > > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative > > normative document for ANI, so it should simply be stated equally in BRSKI and > > ACP. Rest of text is fine. > > I'm not getting what you are suggesting. > I think you are saying that we shouldn't point at ACP for the ANI term, but > rather define it ourselves? Yes. Thanks Toerless > >> > Without this term we can not nail down the explicit requirements against > >> > ANI Pledges, Proxies, Registrars that we need from the document (and distinguish > >> > from requirements against any non-ANI adaptation of BRSKI). I added according > >> > comments into other parts of the doc. > >> > >> > g) Please replace "MASA server" with "MASA service" everywhere. > >> > >> I prefer to just say "MASA" actually. > >> Are you okay with that? > > > Yes. There are a few leftovers of "MASA server" in -14 though. Pls fix. > > fixed them all, I hope. > > >> There is no requirement that the Join Registrar is also the EST for the > >> purposes of ongoing certificate renewal. I don't know if you are speaking > >> about certificate lifetime management (renewal, etc.) when you say > >> "EST Enrollment service". I'll assume that you mean that for the moment. > >> > >> In a big network I would want the roles (bootstrap and initial certificate, > >> vs certificate renewal) split up. > > > Lets in any case consider this issue closed or BRSKI, because it loooks now like > > scope creep to me to discuss it for this draft. I'll probably have this discussion > > on my hand for ACP anyhow, because (only) ACP needs to be concerned about > > initial bootstrap and renewal (just working through that in ACP doc because > > of the ongoing review of it). > > okay. > > > 4.1.1: > > >> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 > > > The way i see it, the normative approach with TCP circuit proxy would > > always only have TCP, right, e.g.: the line should say > > > transport-proto = IPPROTO_TCP ; Not considering non-normative > > ; options like Appendix C. > > I'll reply to Brian. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu May 31 12:13:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E4612FAE9; Thu, 31 May 2018 12:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0N5RnaQPZeJ; Thu, 31 May 2018 12:13:52 -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 14CC413147A; Thu, 31 May 2018 12:13:52 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5714A58C4AE; Thu, 31 May 2018 21:13:48 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 44F1D4401A4; Thu, 31 May 2018 21:13:48 +0200 (CEST) Date: Thu, 31 May 2018 21:13:48 +0200 From: Toerless Eckert To: Eliot Lear Cc: Toerless Eckert , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org Message-ID: <20180531191348.gqp6ns2qtow5rvf7@faui48f.informatik.uni-erlangen.de> References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] references to code ? (was: Re: WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15) 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, 31 May 2018 19:13:54 -0000 On Thu, May 31, 2018 at 08:48:18PM +0200, Eliot Lear wrote: > > I am only aware of github.com/cisco/libest, but would love to see > > any known code be mentioned. Single sentence with references to > > appropriate URLs to those implementations would suffice IMHO. > > What do others think/know about BCP in IETF protocol RFC re such mentioned of known code ? > > I don't mind that pointer being listed, though we should *always* check > with the code developers before doing so.  In this case we can check > with them to be sure. > > The 2nd piece of code is not open source and not by Cisco. If you can propose text/reference (as necessary after contacting authors) for either, that would be lovely! Cheer toerless From nobody Thu May 31 12:32:12 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67851131661; Thu, 31 May 2018 12:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_2DQpuErrw3; Thu, 31 May 2018 12:31:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1F013164F; Thu, 31 May 2018 12:31:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A85EE20090; Thu, 31 May 2018 15:45:04 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4E51A2DA9; Thu, 31 May 2018 15:31:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4AAA62DA1; Thu, 31 May 2018 15:31:26 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org In-Reply-To: <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <26062.1527793635@localhost> <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 19:32:11 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: >> > I would prefer to have the simple definition "ANI =3D=3D systems t= hat support >> > both BRSKI and ACP" in the doc itself. Threre is really no single = authoritative >> > normative document for ANI, so it should simply be stated equally = in BRSKI and >> > ACP. Rest of text is fine. >>=20 >> I'm not getting what you are suggesting. >> I think you are saying that we shouldn't point at ACP for the ANI te= rm, but >> rather define it ourselves? > Yes. okay, I've copied text: ANI: "Autonomic Network Infrastructure". The ANI is the infrastructure to enable Autonomic Networks. It includes ACP, BRSKI and GRASP. Every Autonomic Network includes the ANI, but not every ANI network needs to include autonomic functions beyond the ANI (nor intent). An ANI network without further autonomic functions can for example support secure zero touch boot= strap and stable connectivity for SDN networks - see [I-D.ietf-anima-stable-connectivity] =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 iQEVAwUBWxBNhoCLcPvd0N1lAQKlFggAhnQWoEFTVicMEypxe39YDRNj+ucAkc+0 hrA2MuD4cfYyH210vT+mouBNHYNRMW35T23Pad48nq7aoOIVzPyQDuHgyoPw8lo3 al+rzzrXkWn+0vdZVtRBruRRDH8MH1rsIdelG9GfCvuyy4IvMlYLQkfhJxI1KK8f 9zv1wJzQWZfCl0SW3UTJ6KbN7IVJynVJm/3drGuFah3ikUiWvxwy2H9Ys1/VYYf8 oxtUlLmywp7d9vgeRTUx4xsjn8ce3V+JzCVsGjkqIrKvRHSn8IsGI1E3jmwWdCRe STcMMp0hULGWTZu7tJnryc33N8xVg92GYbK+e0Ll6ahMO8L+sElTfw== =zFxY -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 12:36:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A963F131672; Thu, 31 May 2018 12:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoAjW1sSavSn; Thu, 31 May 2018 12:36:03 -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 A79011314C5; Thu, 31 May 2018 12:36:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 917E720090; Thu, 31 May 2018 15:49:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2F8312DA9; Thu, 31 May 2018 15:35:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2A67E2DA1; Thu, 31 May 2018 15:35:31 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: Brian E Carpenter , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert In-Reply-To: <20180531190910.osegs5jnxpxkobft@faui48f.informatik.uni-erlangen.de> References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> <20180531190910.osegs5jnxpxkobft@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 19:36:06 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > 1. The GRASP specification of 4.1.1 should only describe what is requ= ired > and valid for the standard of GRASP objective, which is the TCP proxy. > Appendix C proxy option is not full/formally worked out, thats why > its in an appendix. If the authors want to propose a formal GRASP It's not mandatory to implement, which is why it got pushed to the appendix. If it wasn't worked out, then it would be removed. > 2. A value of IPPROTO_IPV6 which i guess would be desired for an > appendix C proxy would IMHO be an extension to whats defined in GRASP. I think you mean, "defined in the GRASP object defined in CDDL", here. > An RFC specifying that would therefore have to declare itself to be > an update of GRASP. I don't think this is a big deal. It would become I think that you mean, update of BRSKI rather than "update of GRASP". =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 iQEVAwUBWxBOgICLcPvd0N1lAQI6wgf/bMM9gYSIqiFFBA+59/MBBOxaKofjkpL7 NvGfkKgD+l/pSL/lZ12ePnyEt+6UiXBIM4XxTc5/zyxSlwcMQhi3r4zPQug4stqb 9aO1XdbeBejpCXci2m87xpgDsGs7J273oVsBVswLMYSbbZ6lsPfgrmCgU1SOl//X uTIA6GsNzvT65Huq7CC8qRYUnFvD73hkXUg5VT06V76ptNOKk4kGGS5kMjlLdd9E oKYGaPn2qfVbTclpkIh0Du0/Z2GgT9f7H3JarX0nySulAJWt3cPUwDL9VsMN4OLb RCnch17ZdtCkdSLhc4wWT7rDUevKx1If3IDRMFKVy1P0Ev9nMYR63g== =XB41 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 13:23:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3196D131BC3; Thu, 31 May 2018 13:23:32 -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 TGg_MdBXWWQc; Thu, 31 May 2018 13:23:30 -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 1C3E4131B97; Thu, 31 May 2018 13:23:30 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id e9-v6so11323876pfi.4; Thu, 31 May 2018 13:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iBbeFwCkPwPaaD5nSewdg0fTa7HP82fs7nZgxZ+zJxU=; b=U86rizhgDO+NXNSDAIrIfH3JhOrGl9+XmrcoJ6yAKFvbF9AXl8G5AH3G62IV7DCvVx Kpzvpel98vo52/DLNHJhd6GzIKBKX2E/GcC5cXt0EWb9rVNqLu0YQXy/QiKOLRlRed5F YdK1rgtkBwjEJSnYO1RXjjv8IHdWOCYAKnm0fTS/6s7ILM3Wm1kAYmtAu+84N4DFbMIE nx9hT4qB2/tYNfAd3hrYhD/+zq7uKrvCuHqLGjvxIiCmNlS/5KkJqkXLz9mRdBCAA1Ks x4YJDQd22YupzF0YUqTOGyTvPywuEyMpiqBjMxtVwC9c+SSuAcg4uA0NKpow0bF1Rslj DV+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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iBbeFwCkPwPaaD5nSewdg0fTa7HP82fs7nZgxZ+zJxU=; b=RL3d0Bx618mauZ1bXeYY59a5Vgl2fiO2ZS419mBA+YNZL7+7o26Orl+CkJmlrG8oZK prKdYpFGWIi6IWHCGfRpqW/qE6vNbqrPHHTvgxuYGsO392BfFKlGkolIVg73+ij+K7uf slU1Bt/E3ZgqKjbryzAJpw+lI7gFt1gzjqA/wDAdInD+Y3Kec2azj8z+QHmBBbSxVv0z hO4grOLT12tWW6wImLt/Xkx+XTUeB8shcl2jMPc4//TpkGP5w/in57OZc9q4xHAuWs+t purn04lLhbvPExVC0S9kwAac2vnLcQeAMR5EmmscakjKlhJMiPF1CSf4Yx3Z97ic6gy4 /txg== X-Gm-Message-State: ALKqPwd06bhRmStMRth/JpL33VuG3Oi1y9z+lQyzljbuPLiwLpBDpFFr QovQLDYq8kTI2Y3CbBBnV4fFEw== X-Google-Smtp-Source: ADUXVKKoqGmB/bNv8H7Ei2chHUFVpE4ynF58ri+dFMEre38ii/UNF0Sa1sODpHquXEecwv83K6TwQg== X-Received: by 2002:a62:9513:: with SMTP id p19-v6mr8115671pfd.239.1527798209388; Thu, 31 May 2018 13:23:29 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id j14-v6sm59349747pfn.151.2018.05.31.13.23.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 13:23:28 -0700 (PDT) To: Michael Richardson , Toerless Eckert Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <26062.1527793635@localhost> <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> <32127.1527795086@localhost> From: Brian E Carpenter Message-ID: <30241f79-8b8e-d98a-1f00-0a1f2e13cbca@gmail.com> Date: Fri, 1 Jun 2018 08:23:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <32127.1527795086@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 20:23:33 -0000 On 01/06/2018 07:31, Michael Richardson wrote: > > Toerless Eckert wrote: > > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: > >> > I would prefer to have the simple definition "ANI == systems that support > >> > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative > >> > normative document for ANI, so it should simply be stated equally in BRSKI and > >> > ACP. Rest of text is fine. > >> > >> I'm not getting what you are suggesting. > >> I think you are saying that we shouldn't point at ACP for the ANI term, but > >> rather define it ourselves? > > > Yes. > > okay, I've copied text: > > ANI: "Autonomic Network Infrastructure". The ANI is the > infrastructure to enable Autonomic Networks. It includes ACP, > BRSKI and GRASP. Every Autonomic Network includes the ANI, > but not every ANI network needs to include autonomic functions > beyond the ANI (nor intent). An ANI network without further > autonomic functions can for example support secure zero touch bootstrap > and stable connectivity for SDN networks - see > [I-D.ietf-anima-stable-connectivity] > Wrong answer, IMHO. draft-ietf-anima-reference-model defines the ANI at some length. That should be the (informative) reference for basic terminology. Brian From nobody Thu May 31 13:40:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4853313217B; Thu, 31 May 2018 13:40:42 -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 Pg98aeA2mVNj; Thu, 31 May 2018 13:40:40 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::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 5F60713156C; Thu, 31 May 2018 13:40:40 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id 30-v6so13895982pld.13; Thu, 31 May 2018 13:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3LRjEBe4rpFsiO/W/6Ujfjc7fK77k4bkrlMJT500OUk=; b=dtJsdb9LIZdUMu4xs6XL6vmxPbKUVGNZM3JDLO6BqPl2cGLV5fsZq2b1kSHP7LuyTh Pkf5776t1I8OBGatWlWZrHh8YQ7Qn8ZggwQddueNI5YMnmT2b6pYLvLcg3fGwZN9xGaE 8ffKmOAUcOs2pqqV6umXq+b+V5+8mGKSgU5NQUrQFRSfmK0I9DV1vp/WP2qKBZU1vJID o+WX1lBWmDoGwNOOeGAdguHS7XUSRqesZhAxuXui52Xc7AE9My501b8NzuoWme17ic83 zgdseIDuYRjvSgGjt5urRlQKHpjsz/3KDN27pMQX0rO+T5/QWRDcTcqcQ81nYoKjVyUM IcRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3LRjEBe4rpFsiO/W/6Ujfjc7fK77k4bkrlMJT500OUk=; b=ktSicwqv6wumO7sGv+mEPMz/NFMGvCpOX5UurfpAsrJDsCDhlFgYXzuzZKSfmCW8XW T61Vcnx3Bw0I5sSzjVgiVHhZHGAIbjEw03SG7n9/PzeP8k4yeaWNhslSJFICkTNdjMFg CFeCElCkcFtqrqMdbweSlLbkiL+5vTZOP7r1LqkD4/qS9ChGESt1nMJ0ZkOhIbc8a3xB dRJpVVHFD/s39T8vb/8VqK05q0lgbtk7PRB3pA1fIvgrZ3UuAY6/MuMqCkDzPHzbmIOh 4UIiWz15Ahub/7pTSRPiruVQXCIe7j754flp4s+e0ScvyzeuYc5Let8uEki+nW1/SDHa UTMw== X-Gm-Message-State: ALKqPwes/JDO4np0FEuIplkXYdtH/AsEMlhZyBe2bCLfzTfimHIc59to IpHMgEitAbtBamemKKP2nWM= X-Google-Smtp-Source: ADUXVKJbSKEzETwsyAxK+AvazrBMX2XqfjFXAzLrKYazqie4YaVeVTEZZOWxOSOE50PZXtyJM0B9rg== X-Received: by 2002:a17:902:9004:: with SMTP id a4-v6mr8245283plp.143.1527799239885; Thu, 31 May 2018 13:40:39 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id c17-v6sm32605264pgw.11.2018.05.31.13.40.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 13:40:38 -0700 (PDT) To: Michael Richardson , anima@ietf.org Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> <20180531190910.osegs5jnxpxkobft@faui48f.informatik.uni-erlangen.de> <610.1527795331@localhost> From: Brian E Carpenter Message-ID: Date: Fri, 1 Jun 2018 08:40:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <610.1527795331@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 31 May 2018 20:40:42 -0000 On 01/06/2018 07:35, Michael Richardson wrote: > > Toerless Eckert wrote: > > 1. The GRASP specification of 4.1.1 should only describe what is required > > and valid for the standard of GRASP objective, which is the TCP proxy. > > > Appendix C proxy option is not full/formally worked out, thats why > > its in an appendix. If the authors want to propose a formal GRASP > > It's not mandatory to implement, which is why it got pushed to the appendix. > If it wasn't worked out, then it would be removed. > > > 2. A value of IPPROTO_IPV6 which i guess would be desired for an > > appendix C proxy would IMHO be an extension to whats defined in GRASP. > > I think you mean, "defined in the GRASP object defined in CDDL", here. > > > An RFC specifying that would therefore have to declare itself to be > > an update of GRASP. I don't think this is a big deal. It would become > > I think that you mean, update of BRSKI rather than "update of GRASP". Possibly both, because GRASP already defines transport-proto = IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 On 01/06/2018 07:09, Toerless Eckert wrote: > Btw: The specific issue of extening transport options could have been > avoided by permitting 0..255 in GRASP. Except that it would implicitly lock us into to a particular IANA registry, allowing strange things like transport-proto = IPPROTO_TP and who's to say that we might not also want things like transport-proto = HTTPS I agree that we might want to revisit this in a GRASP update. Brian > From nobody Thu May 31 13:48:17 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C428012FB0A for ; Thu, 31 May 2018 13:48:15 -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 AX8Y1owdfazI for ; Thu, 31 May 2018 13:48:14 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::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 0C2ED1315A2 for ; Thu, 31 May 2018 13:48:14 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id z9-v6so10582775plk.11 for ; Thu, 31 May 2018 13:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fcmIyAGH6eoE1T+52crxJftPZfc/D+VWVryk+TkbVOI=; b=Qohu0VZbWKnl9bCuvm/VLvpvqJr35DHYVl5foBD+mFeH3T6hQSSi8rzw1PbjZJ3+nr FcZ9ZB+3qVXjRzMeeBiD6J8aWzH4/pch6yEdOpwt4k7D+Uxvf+PrXV4vFnWn25ezq/Uj DgPbSMRzmg1awTw2qjdFhGyMvNUjI9quKw2ORuzwXk/u+hIm9ihyMNQp+zdy7eQaeKWe +UGG8fW37v6zqV0lLMr8INmLLUEdujzqI2rSXoKXLL1UPM5x2W8F/7jIBPlUrhpmUv9n aAUtKklhHNOeCQCmz5SE49KUpHeDFZGIDISn/peCVup5mmO6tYgT4KPQUjVtIDIjDnUr HLgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fcmIyAGH6eoE1T+52crxJftPZfc/D+VWVryk+TkbVOI=; b=UI1pmVT2f2HsTe/v4ub/JHrQqXWav3K7ZkHIAh4S+DrtZV/cqoVsJLAwxEoU1DMjwM 5OlK0ZM9Whvrd/Ob1Ny723Pgd0AWnPyzR+zPO6Wdim/30FMEC8f4kochtXLYEA1ikGIk PK4LyVNGpUHoJyJunjGF5hZbRlfPo+flUQXUaaEOS8YhZO17qrg4VDVce6h20Ym/sonv 7By3lPvhhh7Oq3qm6RDOqHItsL1xyvYomH6v5AQdwRDAbx/Ogy0r3aoBb+aaBE4FzPC0 NgCdRuQTMko4SrPdu1veUgoEpCw/2sZPwT0r8j6PbXBVx2xqD11wLznp2xPXSUNwgOec xVTA== X-Gm-Message-State: ALKqPwdHSAaragIUDRzmscpPG2jvUtsUyaQkOqtWAJVQBTRYMG7tu6fm U3VsqOogsoxMlVJCVY4TlU9Yxw== X-Google-Smtp-Source: ADUXVKLa+JtVROlY0KlRCn8LIQeYSPahzXpjHvKI+EvTkC6FLB+grUQtzOWrEdd3yLM+gzEOPeuhRA== X-Received: by 2002:a17:902:b94a:: with SMTP id h10-v6mr8573588pls.321.1527799693391; Thu, 31 May 2018 13:48:13 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id h8-v6sm49959148pgq.56.2018.05.31.13.48.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 13:48:12 -0700 (PDT) To: anima@ietf.org References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> <20180531191348.gqp6ns2qtow5rvf7@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Fri, 1 Jun 2018 08:48:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180531191348.gqp6ns2qtow5rvf7@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] references to code ? 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, 31 May 2018 20:48:16 -0000 This should be in a special section "Implementation Status [RFC Editor: p= lease remove]" according to RFC7942/BCP0205. We have such a section in dr= aft-ietf-anima-grasp-15. Regards Brian On 01/06/2018 07:13, Toerless Eckert wrote: > On Thu, May 31, 2018 at 08:48:18PM +0200, Eliot Lear wrote: >>> I am only aware of github.com/cisco/libest, but would love to see >>> any known code be mentioned. Single sentence with references to >>> appropriate URLs to those implementations would suffice IMHO. >>> What do others think/know about BCP in IETF protocol RFC re such ment= ioned of known code ? >> >> I don't mind that pointer being listed, though we should *always* chec= k >> with the code developers before doing so.=C2=A0 In this case we can ch= eck >> with them to be sure. >> >> The 2nd piece of code is not open source and not by Cisco. >=20 > If you can propose text/reference (as necessary after contacting author= s) for > either, that would be lovely! >=20 > Cheer > toerless >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Thu May 31 14:51:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B20B1315E1 for ; Thu, 31 May 2018 14:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb2ceOQm30Bt for ; Thu, 31 May 2018 14:51:44 -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 1C7E3133144 for ; Thu, 31 May 2018 14:51:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 29E5220090; Thu, 31 May 2018 18:04:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 63D172DA9; Thu, 31 May 2018 17:51:10 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5FF6B2DA1; Thu, 31 May 2018 17:51:10 -0400 (EDT) From: Michael Richardson To: Toerless Eckert , anima@ietf.org cc: Eliot Lear In-Reply-To: <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] references to code ? (was: Re: WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15) 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, 31 May 2018 21:51:47 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > Good point, forgot to ask/mention this point in my previous emails. > As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to > mention known existing implementations, especially open source, even = if just PoC.=20 IDs have included Implementation Reports during ID phase. That section has usually been removed prior to publication, but perhaps not always. Why not ask a friendly AD? {My feeling is that including an implementation reports in a Draft Standard is confusing DS with Internet Standard, and results in the bar being informally raised. } > But i have no idea if and/or how thats seen to be appropriate by IETF > standards. Traditionally i think it was not done, but then again, > with the amount of focus (not to say hype ;-) the IETF does around > open source and hackathons, it almost sounds absurd to me not to ment= ion such code. > I am only aware of github.com/cisco/libest, but would love to see > any known code be mentioned. Single sentence with references to > appropriate URLs to those implementations would suffice IMHO. https://minerva.sandelman.ca/ https://github.com/AnimaGUS-minerva Contains a MASA called "highway" (in Ruby on Rails), a JRC called "fountain" (also in Ruby in Rails), a Pledge simulator called "reach". They all use a library called Chariwt, which started it's life being about CWT signing vouchers, but now does COSE, JOSE and CMS signing of JSON and CBOR format vouchers. In addition to be able to download the code, there are two MASA "live" on t= he Internet, see: https://minerva.sandelman.ca/metasite/2017/10/25/jokeshop-setup.html The idea is that you can "purchase" a unit by downloading a public/private keypair, embedding that into your "product", and when it enrolls to your JRC, there will be a MASA (in nonce audit mode) that will answer. Once the unit has become owned, then the MASA removes if from the available inventor= y, and cons' up another keypair. The libest folks have set all of them up and tried to interoperate, but last I heard, they were a few IDs behind in the code, and I hadn't heard a more recent statement of the situation. In addition. the JRC devel branch currently has DTLS+CoAP code being added. The change to move the existing CoAP code to have DTLS underneath it was not easy, as the OpenSSL DTLS code has some problems in it's DTLS API. (At least, I say it does, and I did patches for it. I can't get my patches upstream until I find a VAX to test compile them on though...) =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 iQEVAwUBWxBuS4CLcPvd0N1lAQKxCwf+LWB8Pd7OTpfJJC0tBBQPmzLqEnU6uDGL 1fSzJxTL+D6WTq62wY1xPZxMbcMsGJY+x5vs5cSdkKLnDI9b0LSlphMXtItLKoWc kiYF31XLHcgHNHTVzol0Eb+l86BK0mdsKWn08KInLBcLHKRnGRXOIocDueCWo17E ludi3K+pN4fjdmEGX+XcB0Sa3lnbSQHgaeHDjyowyRZBurl5yzkhW7Aj3QqUy+nF qZiKD07VDeneLyWM2XOJd59k9/fNmW+kkxLAIOc6tF5jfsQhixrNimcpwVWwUsKB 640QuXDPuCk2BOA1VkDxup5txF8EYD1vg3SZyg5C8sXwkGp5kngMQg== =dbw7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 14:58:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF444133315 for ; Thu, 31 May 2018 14:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM4aVDOg8NyV for ; Thu, 31 May 2018 14:58:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C04131EDF for ; Thu, 31 May 2018 14:58:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B3B2420093; Thu, 31 May 2018 18:11:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E9AA32DA9; Thu, 31 May 2018 17:58:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E608F2DA1; Thu, 31 May 2018 17:58:13 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> <20180531191348.gqp6ns2qtow5rvf7@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] references to code ? 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, 31 May 2018 21:58:50 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > This should be in a special section "Implementation Status [RFC Editor: > please remove]" according to RFC7942/BCP0205. We have such a section in > draft-ietf-anima-grasp-15. I question the value of adding that section during WGLC. okay, it might sit in mis-ref for a few more months, which might help someone. Is it that useful to the IESG? Having said that, I don't have any problem adding it, I just don't want to = do much work on it :-) =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 iQEVAwUBWxBv84CLcPvd0N1lAQLmVQf+KeLHN9JtVaOZ4G/TDpzSOsPU+XVpJ1ft +6rpo6dYONrj3028sAvym/V5+mY9tAhwOfCiqDAqL59rS1//7XxaIss+ryqLiFSl IB6jbIa3MAjQW+5deJetv97Q45fhJgFY5jiiofAG/3lSwke4v3uQtm/DFCtLf0D6 g+fIeBvz++BZpr8eRTA7r4q1DRsp6aa6g58+8EACiHxBoYp/a/noCYxcfDiPxaO2 2u/cFoFDQZluMt0O6qwe1GLUsM4/t3N3iIyFE4ia1yeGqpv2Sz8X146eDWm4M+Jd XjSkiBaxstCD3W3E6Nj1wPFKdRaBTUvCbaH0cnnrnmVyGB26/yxbGw== =JGdX -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 18:14:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C6D124205 for ; Thu, 31 May 2018 18:14:05 -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 swczjA6J8Vag for ; Thu, 31 May 2018 18:14:04 -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 E77581241F5 for ; Thu, 31 May 2018 18:14:03 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id h12-v6so1704673pfk.11 for ; Thu, 31 May 2018 18:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ByARE7yZgzhnhS7yz3eu3FNMw0hjYkPD3vS84qLticU=; b=lCliVIakK7iO9wS4H9LgFKPnvPbw1o/h057Z2VLsi58mfrk2C+TgVzm40sKIuVpB8o fxByfSQeUclu8IDVXx96YBM8m+wwTzgpHMXyPeV982/f3J9Bvsls94bHXRmK7MNDsro5 90QlFjUTvrwSJgbxlgToM/xBAMGTJMXvJqhWRQLZXW/WJPVcSkgOUx5sXef53F2CJpgF KsTI9EyhCgKVkNw9HMhoflFnSYxU1aWHkDEfK4UtNYyb5peaYPiFdrfInOqQ7H792yvb EFIMBvgzCtQvWu+6IdxKj2eTUDTflleYWunDnUUQ/TDjj9aAXuPvImzIPqe7X9/NIJDV 0nsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ByARE7yZgzhnhS7yz3eu3FNMw0hjYkPD3vS84qLticU=; b=CzxnCtOqm/65Qz5kOJu17HA1jnjY4U2Xwomw5CkfhUNTXvdjNDpHaQ8hFl+faM6hfv 8yScSpIau8xfUDd6JXvhnfV4fgTUWLRZC1SNgvNa5UENy9zjluluSJ0FqcfNpuzMnyCW dovcoXBoH7zHv3XGg754TB4s6MoySDO2BI6fTktVuEQz2rcYqYTr0rLeKYAcvfY2qTu7 9bawZgpi+m+rLUzeK6mrP1V2lImJBePRxLASDTzODMRqclvZFSnvtR90ps9t7ZQcJg7O 8DRWKECplegrzjiMa/sZp7wASlsdPTJqjSeRkZDw0iu2m5+XQiMFetRpwMKubI4edqei dE7Q== X-Gm-Message-State: ALKqPweawup1S/z2WJOXLvU20GXBhlbvjO816UH0vreG07jYKvvLWjyt O7w5Wn+L15/WR7E6FwA2xSr26g== X-Google-Smtp-Source: ADUXVKI9ccBo3lX9PhOcABsje5bnQLw3uK4m2sKy4Aiqd3iQpkLySIMaGgIBvpKOgXBLI8Ms/7Ai9A== X-Received: by 2002:a62:c00e:: with SMTP id x14-v6mr8855888pff.67.1527815643109; Thu, 31 May 2018 18:14:03 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id q24-v6sm8184669pfh.26.2018.05.31.18.14.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 18:14:02 -0700 (PDT) To: Michael Richardson Cc: anima@ietf.org References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> <20180531191348.gqp6ns2qtow5rvf7@faui48f.informatik.uni-erlangen.de> <3186.1527803893@localhost> From: Brian E Carpenter Message-ID: <0641b985-d8f8-f0f4-2881-25f346bc08da@gmail.com> Date: Fri, 1 Jun 2018 13:14:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3186.1527803893@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] references to code ? 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, 01 Jun 2018 01:14:06 -0000 On 01/06/2018 09:58, Michael Richardson wrote: > > Brian E Carpenter wrote: > > This should be in a special section "Implementation Status [RFC Editor: > > please remove]" according to RFC7942/BCP0205. We have such a section in > > draft-ietf-anima-grasp-15. > > I question the value of adding that section during WGLC. Supposedly, it helps the IETF as a whole and the IESG evaluate the document, which is the stage after WGLC. Brian > okay, it might sit in mis-ref for a few more months, which might help > someone. Is it that useful to the IESG? > > Having said that, I don't have any problem adding it, I just don't want to do > much work on it :-) > > From nobody Thu May 31 18:58:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEC4126FDC for ; Thu, 31 May 2018 18:58:16 -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, RCVD_IN_DNSWL_MED=-2.3, 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 cLWMvzYPc6a9 for ; Thu, 31 May 2018 18:58:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32310126B72 for ; Thu, 31 May 2018 18:58:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D3FBC20093; Thu, 31 May 2018 22:11:18 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 633152DA9; Thu, 31 May 2018 21:57:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5FE322DA1; Thu, 31 May 2018 21:57:39 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, Kent Watsen X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] question about ietf-voucher.yang 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, 01 Jun 2018 01:58:17 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Now that RFC8366 is published, BRSKI should be importing the module from an official source, rather than from ../voucher as I do now on my computer. As far as I can understand, includes seem to come from the pyang source tre= e, in modules/ietf, and if you want new modules, you have to get a new pyang, and so we should send a pull request against the pyang source. However, we also have the yangcatalog.org, and maybe the makefile in BRSKI should wget something, but I'm unclear what exactly I should wget! Also, https://datatracker.ietf.org/doc/rfc8366/ has a link for: Yang catalog entry for ietf-voucher@2017-10-25.yang pointing at the entry for 2017-10-25, while the RFC has 2018-05-09, and in fact, there is an entry at: https://www.yangcatalog.org/yang-search/module_details.php?module=3Dietf-= voucher@2018-05-09.yang I feel that I'm missing a place to wget the modules from. =3D=3D=3D=3D Also, a related question is whether ietf-cwt-voucher-request to inherit fro= m BRSKI's ietf-voucher-request, or from ietf-voucher... It's not clear to me that it's a 100% subclass yet. =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 iQEVAwUBWxCoDYCLcPvd0N1lAQK2lAgAjiJq+DP2+iZrxqZKJ9xJf9Emq18/phUv dcgz9lbOxCrnDdEEA3aQHYwgkmkiaDlblLnIz+i90unGPXif46H35gFg4MxPoqc3 au7cNt0ZRb2lA8E1SQsooX2q6EbATj8e2I2G1HglfjwMBn2XqZ8SwMGLT4zOQ9Xe jHonZdhxmSB5Zly5/uf69nWRlVSCaa1oA7w8ZpVEnv7q5p5MeTH89Z9Iv810LCdt jddeZHkbQsljVI1CKY3COps2LST/6+sI/YEXFmXPVbQYg8pFQo//ob4wkeeWrcOy lWKPSm6b9Aj7GGxkx4tJumxUA/mwuhu0Rt/hniO8cWMegLPemaB00Q== =icff -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 19:00:26 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C6E124B18; Thu, 31 May 2018 19:00:24 -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, RCVD_IN_DNSWL_MED=-2.3, 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 k2NJ3HXRIkhE; Thu, 31 May 2018 19:00:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C55012426E; Thu, 31 May 2018 19:00:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F58C20093; Thu, 31 May 2018 22:13:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 92DE92DA9; Thu, 31 May 2018 21:59:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8ED152DA1; Thu, 31 May 2018 21:59:48 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert In-Reply-To: References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <0b840bc1-b147-929a-a09d-a72ea3113796@gmail.com> <20180531190910.osegs5jnxpxkobft@faui48f.informatik.uni-erlangen.de> <610.1527795331@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 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, 01 Jun 2018 02:00:25 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> > An RFC specifying that would therefore have to declare itself to be >> > an update of GRASP. I don't think this is a big deal. It would bec= ome >>=20 >> I think that you mean, update of BRSKI rather than "update of GRASP". > Possibly both, because GRASP already defines > transport-proto =3D IPPROTO_TCP / IPPROTO_UDP > IPPROTO_TCP =3D 6 > IPPROTO_UDP =3D 17 Ah right. I just don't care... someone else decide and tell me what. =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 iQEVAwUBWxCokYCLcPvd0N1lAQLQ0wf6AuzZVr+z3uIkI3PIKIN89pKEOiGS77jp qTgV/lfmUocUxHS7nMJ1OU5P+xiUmlXaeRG7Vwq9azXEFKepK8/SlV0b41N0y+r2 K/zRySdO6jpt4OI/lSnrcJv8Lyi8sHGiYDBOxlWzkGE8EMpi3BfgvNglQcGDyif1 M2O2T9We4TEN/RdeWO5p7OUpRwMiKqcb+fIPOCID8ZRim5xOGweavXsqnEGmG62i dtQLN0LninUTun3LkXNW8BjIUcmtixXcLZIfoboTNFwi+4OAjM/gkANc7n01PxN9 zv+U4rdboovKIM0NE3X5tI+YF1gsZD7ePy8xgKZcQGRM16p0ZVQbnA== =7gsN -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 31 23:23:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69A4127010; Thu, 31 May 2018 23:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NjuTfsUxC5m; Thu, 31 May 2018 23:23:48 -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 D7A011205F0; Thu, 31 May 2018 23:23:47 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3254B58C4C9; Fri, 1 Jun 2018 08:23:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2165C4401A4; Fri, 1 Jun 2018 08:23:43 +0200 (CEST) Date: Fri, 1 Jun 2018 08:23:43 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra@ietf.org Message-ID: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 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, 01 Jun 2018 06:23:51 -0000 Ok, lets separate out the threads here. On Thu, May 31, 2018 at 03:35:31PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > 1. The GRASP specification of 4.1.1 should only describe what is required > > and valid for the standard of GRASP objective, which is the TCP proxy. > > > Appendix C proxy option is not full/formally worked out, thats why > > its in an appendix. If the authors want to propose a formal GRASP > > It's not mandatory to implement, which is why it got pushed to the appendix. > If it wasn't worked out, then it would be removed. Ok. *sigh*. I guess i didn't quite get that. So, if we want to make GRASP in BRSKI fwork correctly for IPinIP instead of just making it sugestive, there are a bunch of fixes necessary. Some of them where part of the shepherd review suggestion you dismissed as bikeshed. You didn't like the idea of using objective-value strings to identify the proxy method. But the fix i suggested also fixed other GRASP details. Anyhow. let me just list what i think is necessary to fi up the GRASP so it works for both TLS and IPinIP. let me know if/how i can best help to get this done,I'd be happy to write up a diff if we can finally get through this. Proposed changes to 4.1.1: Note: This 4.1.1 text fixes are not complete wrt. to the IPinIP port constraints you seem to want to have according to the 4.2 text. See below for the 4.2 text discus, and if thats fine with you, then of course, we would also need to incude the locator-options for permitted TCP/UDP ports of the IPinIP proxy into the 4.1.1 AN_Proxy objective, because otherwise the Pledge wouldn't know which TCP or UDP (address)/port numbers to use across the IPinIP proxy (i think). a) Insert after: | A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. | This announcement can be within the same message as the ACP | announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. The optional IPinIP proxy as described in Appendix C requires the following extension to the syntax of [GRASP]: transport-proto /= IPPROTO_IPINIP IPPROTO_IPV6 = 41 ; [RFC2473] Figure xx: GRASP syntax extensions for BRSKI Note: Process wise we might need to declare BRSKI RFC to be an update to GRASP RFC because of these two lines, but i would just wait until this gets discussed with IANA and then suggest that we change instead GRASP before it becomes RFC to: transport-proto = 0..255 Aka: that way we can define IPPROTO_IPV6 perfectly in BRSKI without extending GRASP (IMHO). We can still later on expend it beyond 255 when we need to, but thats not a BRSKI RFC problem then anymore. b) Change: | The M_FLOOD is formatted as follows: To: An example of M_FLOOD (without ACP) is as follows: (aka: "is formatted as" is not the correct lead in for an example). c) Fix up example picture: [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, [ ["AN_Proxy", 4, 1 ], [O_IPv6_LOCATOR, h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]], [ ["AN_Proxy", 4, 1 ], [O_IPv6_LOCATOR, h'fe800000000000000000000000000001', IPPROTO_IPV6, 0]] ] Figure 6b: AN_Proxy Example This is actually multiple fixes - Better title for picture (match AN_Proxy with following CDDL picture title and 'example') - the objective-value is not used, so "" for objective-value is not really correct IMHO, the field is just not encoded: ["AN_Proxy", 4, 1, "" ] -> ["AN_Proxy", 4, 1 ] - I think it helps a lot to understand how to announce multiple proxy options, so i highly suggest to have the above example include the TCP circuit proxy and IPinIP options. - Whether or not you use one or two objective announcements, you always need one more structure level around objective and locator-option according to GRASP syntax, aka: changed: ["AN_Proxy", 4, 1 ], ... 4443] to: [ ["AN_Proxy", 4, 1 ], ... 4443] ] c) Fix syntax: from: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] to: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, locator-option ]] Aka: for this objective, locator-option is not optional, but mandatory, because it indicates the proxy-type via the transport-type which is part of the locator-option. d) from: locator = [ O_IPv6_LOCATOR, ipv6-address, to: locator-option = [ O_IPv6_LOCATOR, ipv6-address, textual consistency with prior use of locator-option and GRASP RFC. e) Add at end of 4.1.1 suggested text: The transport-proto of the locator-option indicates the mechanism(s) supported by the proxy to the pledge. IPPROTO_TCP indicates the mandatory ANI TLS circuit proxy. IPPROTO_IPV6 indicates the optional IPinIP proxy, see Appendix C. IPPROTO_UDP would indicate a future CoAP mechanism, see Section 4.2. For IPPROTO_IPV6, proto-number MUST be 0. The above example shows a proxy supporting both ANI TLS circuit proxy and IP in IP proxy. Notes: I hope i understand the IP in IP proxy correctly, but given that there is no port number in IPinIP, and given that port-number is mandatory in GRASP syntax in this case, 0 seems to be the logical number to use for port-number in this case. I am just guessing you want IPPROTO_UDP to indicate CoAP in the future. If so, then it would be prudent to notice this here, otherwise describe what IPPROTO_UDP should mean, and if there is no predefined meaning, just remove it from the CDDL syntax. f) If you do not fancy to include the IP in IP example and text in 4.1.1, then i would strongly suggest to remove ALL indications of IP in IP, including the mentioning of IPPROTO_IPv6 from 4.1.1 (also the extension to the GRASP syntax) - and instead put that all into appendix C. Your choice. I think the text is more succinct if all the grasp stuff is clearly in 4.1.1. 2) Changes for 4.3 a) The objective-value "EST-TLS" serves no purpose and is wrong. Please remove it from the syntax, ak: no objective-value, like also no objective-value in 4.1.1 - Its unnecessary, because if its used for all possible methods (TLS, IPinIP, ..) then it doesn't provide additional information and is redundant. - It is wrong, because the protocol would not just be EST, but BRSKI. - It is wrong, because for CoAP there would be no TLS. b) Please consider improving the example as above for 4.1.1: - lead in text for example - example title - [ [ objective, locator-option ] ] structure fix - Ideally also include both TLS and IPinIP options in example Also: - I find the use of port 80 in the example highly confusing given how the TCP connection MUST use TLS. Please change to AB80 (anything but 80). c) The CDDL syntax should be more consistent with 4.1.1: - locator-option not optional - locator, ipv6-address, transport-proto, port-number could be included in syntax. d) "network administrator policy (EST server configuration)" You where making during ACP review the point that BRSKI Registrar (for enrollment) would not necessarily be the same as the EST server for cert renewal, therefore the mentioning of "EST server" is confusing. would be less confusing if the term (BRSKI) Registrar was used everywhere, and "EST server" only when there is a real reason. e) "A protocol of 41 indicates that packets may be IPIP proxy'ed" So, unless we get back to my shepherd review "bikeshed" of introducing different objective value strings for different proxy methods, the "transport-proto" is the only way for the proxy to identify the method, so this sentence needs to say "will be" instead of "may be". Also: Delete following "In the case of that IPIP proxying is used, then". Also: "MUST be advertised on the" -> "MUST be advertised by the Proxy on the". f) the mechanism you are describing with locator1, locator2 and locator3 would be highly obfuscated: In GRASP, every objective can have only one locator as seen from the syntax. What you are proposing would mean that you are announcing three separate AN_join_registrar objectives (of course, they can all be together in a single M_Flood), but then effectively you're saying that those three objectives do really describe a single IPinIP mechanism. So, your full example locators with objectives would be: [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]] ] [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] ] [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fe80::1234, 41, 0] ] Is this join registrar supporting ANI TLS proxy ? Aka: i can't distinguish for the TCP locator whether it just indicates a permitted TCP port for the IPinIP proxy or whether it indicates the TCP port supported for IPinIP. And even if the proxy supports both, its not clear to me that the TCP ports for "native" would be the same as for IPinIP. Maybe its different code-paths == different ports. Likewise UDP port could be CoAP proxy or again a parameter for IPinIP. I would suggest to only use a single objective for IPinIP, aka: the line with 41, 0, and encode the TCP/UDP locators to use inside of the IPinIP proxy mechanisms as the objective-value when using the IPinIPi method: objective-value = *( [ ipv6-locator-option ] ) ; only for IPinIP proxy Then we could show an example like this: [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, [ ["AN_join_registrar", 4, 255 ], [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 443] ], [ ["AN_join_registrar", 4, 255, [[O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 4443], [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001',17, 5683]] ], [O_IPv6_LOCATOR, fe80::1234, 41, 0] ] ] That would include your two constraining locators for the IPinIP proxy and separately the "native" circuit proxy. And as mentioned in the intro for 4.1.1, the same structure of information for the IPinIP proxy would be necessary for AN_Proxy. I'll stop here. Let me know what you think. I'll be happy to help apply the fixes / send diff if this is ok. with you. Cheers Toerless > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima