From nobody Fri Dec 1 11:44:10 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3E126CB6 for ; Fri, 1 Dec 2017 11:44:09 -0800 (PST) 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 ag4-9Kjz3ae7 for ; Fri, 1 Dec 2017 11:44:08 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id D1C7C124D85 for ; Fri, 1 Dec 2017 11:44:07 -0800 (PST) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.217]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id vB1Ji7cG002614 for ; Fri, 1 Dec 2017 14:44:07 -0500 To: anima@ietf.org From: William Atwood Organization: Concordia University, Montreal Message-ID: <6c090fd1-dd91-ff50-3982-e1f93ecaff62@concordia.ca> Date: Fri, 1 Dec 2017 14:44:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 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 2017-12-01 14:44:07 EST Archived-At: Subject: [Anima] BRSKI - Pledge Rejection 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 Dec 2017 19:44:09 -0000 I have been reading the BRSKI I-D. While the I-D is pretty clear as to what happens when everything goes as planned, I am finding it very difficult to understand what will happen when a Pledge contacts a Registrar for a different domain. Consider the following scenario: Domain A Domain B .............................. ............................... . --------- . . --------- . . | Reg A | . . | Reg B | . . --------- . . --------- . . . . . . . . . . ----------- . . ----------- . . | Proxy A | . . | Proxy B | . . ----------- . . ----------- . .............................. ............................... ---------- | Pledge | ---------- A Pledge is at the edge of Domain A (which it should join) and has discovered Proxy A. It is also at the edge of Domain B, and has discovered Proxy B. It then begins the steps outlined in Figure 2, and by chance chooses to contact the Registrar offered by Proxy B. While I understand that this attempt to register will fail, it is not clear at what point the Pledge will realize that this is the wrong Registrar, and move on to the next discovered Proxy. Clearly the Proxy does not know; it is only a conduit. Does the Registrar have enough information, or is it only after the voucher is issued (or not issued) by the MASA that the decision can be made? Would someone please help me to clarify this issue? Bill -- 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 Dec 3 08:26:12 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D1F126CF6 for ; Sun, 3 Dec 2017 08:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 BtKrZCXhyIKR for ; Sun, 3 Dec 2017 08:26:08 -0800 (PST) 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 13C5112009C for ; Sun, 3 Dec 2017 08:26:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 00A2B20072; Sun, 3 Dec 2017 11:28:51 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BD55E83C5D; Sun, 3 Dec 2017 11:26:06 -0500 (EST) From: Michael Richardson To: William Atwood cc: anima@ietf.org In-Reply-To: <6c090fd1-dd91-ff50-3982-e1f93ecaff62@concordia.ca> References: <6c090fd1-dd91-ff50-3982-e1f93ecaff62@concordia.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] BRSKI - Pledge Rejection 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, 03 Dec 2017 16:26:10 -0000 --=-=-= Content-Type: text/plain William Atwood wrote: > I have been reading the BRSKI I-D. While the I-D is pretty clear as to > what happens when everything goes as planned, I am finding it very > difficult to understand what will happen when a Pledge contacts a > Registrar for a different domain. By definition, the pledge hasn't joined a domain yet, so question doesn't make sense actually. There isn't a "different domain" yet. > Consider the following scenario: > Domain A Domain B > .............................. ............................... > . --------- . . --------- . > . | Reg A | . . | Reg B | . > . --------- . . --------- . > . . . . > . . . . > . ----------- . . ----------- . > . | Proxy A | . . | Proxy B | . > . ----------- . . ----------- . > .............................. ............................... > ---------- > | Pledge | > ---------- > A Pledge is at the edge of Domain A (which it should join) and has > discovered Proxy A. It is also at the edge of Domain B, and has > discovered Proxy B. It then begins the steps outlined in Figure 2, and > by chance chooses to contact the Registrar offered by Proxy B. > While I understand that this attempt to register will fail, it is not > clear at what point the Pledge will realize that this is the wrong > Registrar, and move on to the next discovered Proxy. Clearly the Proxy > does not know; it is only a conduit. Does the Registrar have enough > information, or is it only after the voucher is issued (or not issued) > by the MASA that the decision can be made? It is only after the voucher has been issued that the pledge knows if it can join a particular domain. In the case of nonce-ful logged proximity (no sales channel integration), the MASA will assign the pledge to whichever domain the pledge talks to. If there is a "correct" domain, and the MASA knows about it, then it will only issue a voucher that way. An attempt by the "wrong" domain to register the pledge will result in no voucher. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlokJZwACgkQgItw+93Q 3WXdOQf/V8YNJuyfb3Eq1sEMHRSK+mf2mWnFnJ1c5JRT1hSKRRJE46fvmTlnLGW9 5cZ6ng9T72OaJxWhv2H0p4rGOoIaiuvAur+PsNfnNfcOgRehyJV5J7QlEaMKa4rf PRyM+dA17hQMXONKreB6UDD2gwLpx9YAl0ceTLBgZjcItRZXt+wZba2QHj4RHLlp slhUW5b6blJXrQ6OSdH+D9Yca7Z9ZaBl97NyKCRpyjSOoVOOdaoFzvLUXpIq42vP L6MKPBk+GwBNsZTvDcrkYD+hmkv1DOMCXWHgstWr7cOIzcvohJ7EzitwVW66Zv1c uFBlUD16+zBPkNC+xWYQ5nCd0D5Bqw== =kVdj -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 3 12:02:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D01112711B for ; Sun, 3 Dec 2017 12:02:20 -0800 (PST) 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 rSjXccgLffTO for ; Sun, 3 Dec 2017 12:02:18 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4D61201F8 for ; Sun, 3 Dec 2017 12:02:17 -0800 (PST) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.217]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id vB3K2Gr7030646; Sun, 3 Dec 2017 15:02:17 -0500 To: Michael Richardson , anima@ietf.org References: <6c090fd1-dd91-ff50-3982-e1f93ecaff62@concordia.ca> <11411.1512318366@obiwan.sandelman.ca> From: William Atwood Organization: Concordia University, Montreal Message-ID: <38324b69-0387-001a-d3e8-61f49bcbfa2f@concordia.ca> Date: Sun, 3 Dec 2017 15:02:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <11411.1512318366@obiwan.sandelman.ca> 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 2017-12-03 15:02:17 EST Archived-At: Subject: Re: [Anima] BRSKI - Pledge Rejection 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, 03 Dec 2017 20:02:20 -0000 Michael, My assumption was that (outside BRSKI) the Pledge was sold to the owner of Domain A, and the MASA knew this (and the identity of the Registrar for A). One of the students that I presented ANIMA concepts to asked the question, "What happens if the Pledge chooses the "wrong" Proxy?" I believe that I now have enough information (from the discussion that you added at the bottom) to answer his question. After exploring this a bit more, I may have a suggestion for an addition to the text, to forestall such questions in the future. Thank you for your response. Bill On 03/12/2017 11:26 AM, Michael Richardson wrote: > > William Atwood wrote: > > I have been reading the BRSKI I-D. While the I-D is pretty clear as to > > what happens when everything goes as planned, I am finding it very > > difficult to understand what will happen when a Pledge contacts a > > Registrar for a different domain. > > By definition, the pledge hasn't joined a domain yet, so question doesn't > make sense actually. There isn't a "different domain" yet. > > > Consider the following scenario: > > > Domain A Domain B > > .............................. ............................... > > . --------- . . --------- . > > . | Reg A | . . | Reg B | . > > . --------- . . --------- . > > . . . . > > . . . . > > . ----------- . . ----------- . > > . | Proxy A | . . | Proxy B | . > > . ----------- . . ----------- . > > .............................. ............................... > > > ---------- > > | Pledge | > > ---------- > > > A Pledge is at the edge of Domain A (which it should join) and has > > discovered Proxy A. It is also at the edge of Domain B, and has > > discovered Proxy B. It then begins the steps outlined in Figure 2, and > > by chance chooses to contact the Registrar offered by Proxy B. > > > While I understand that this attempt to register will fail, it is not > > clear at what point the Pledge will realize that this is the wrong > > Registrar, and move on to the next discovered Proxy. Clearly the Proxy > > does not know; it is only a conduit. Does the Registrar have enough > > information, or is it only after the voucher is issued (or not issued) > > by the MASA that the decision can be made? > > It is only after the voucher has been issued that the pledge knows if it can > join a particular domain. In the case of nonce-ful logged proximity (no > sales channel integration), the MASA will assign the pledge to whichever > domain the pledge talks to. > > If there is a "correct" domain, and the MASA knows about it, then it will > only issue a voucher that way. An attempt by the "wrong" domain to register > the pledge will result in no voucher. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- 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 Dec 3 16:03:40 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5FB126CD6 for ; Sun, 3 Dec 2017 16:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lctgYNQT0VFb for ; Sun, 3 Dec 2017 16:03:36 -0800 (PST) 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 AE9311242F5 for ; Sun, 3 Dec 2017 16:03:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0201220072; Sun, 3 Dec 2017 19:06:19 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A4D0B829D1; Sun, 3 Dec 2017 19:03:34 -0500 (EST) From: Michael Richardson To: William Atwood cc: anima@ietf.org In-Reply-To: <38324b69-0387-001a-d3e8-61f49bcbfa2f@concordia.ca> References: <6c090fd1-dd91-ff50-3982-e1f93ecaff62@concordia.ca> <11411.1512318366@obiwan.sandelman.ca> <38324b69-0387-001a-d3e8-61f49bcbfa2f@concordia.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] BRSKI - Pledge Rejection 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, 04 Dec 2017 00:03:39 -0000 --=-=-= Content-Type: text/plain William Atwood wrote: > My assumption was that (outside BRSKI) the Pledge was sold to the owner > of Domain A, and the MASA knew this (and the identity of the Registrar That's called "sales channel integration". It's "channel", because you could imagine a series of OEMs, distributors, retails, etc. Years ago, I wrote this: https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00# to explain how a different concept of vouchers could work. I'm including this because I think it explains the sales channel integration concept well. > for A). One of the students that I presented ANIMA concepts to asked > the question, "What happens if the Pledge chooses the "wrong" Proxy?" I > believe that I now have enough information (from the discussion that you > added at the bottom) to answer his question. After exploring this a bit > more, I may have a suggestion for an addition to the text, to forestall > such questions in the future. okay, thank you! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlokkNYACgkQgItw+93Q 3WW1pQgAm8C9BSYOR/fI4/ieHfQAjXA+M97H/go2xaSxNmlKCQvSbZq0GyuFzi4Z pacbPbxVgdqgvg06wkAhs5mkHLgLPoc1GNR9hXaOfUSPTHMuIPyHoLXTlGHcSWJM d8crS301pG07Y7qETspqHCXZn/6fH+RMI9GyaEesaEgnwW0rqTQuyCm8VR+klUXt zKC7bP2xTbYcEFwVHImSvX8jlxS9hGv+lf7k2lZLC4Kf8RlDQPMpIu2z7Mv3pg3U 6kUrPOG4Sw3crs2vVd65VkIUVDdSyOU9EtPxOWajyjcNi7Qy/f5Gh6LmRCJIzdiQ Q8wA+oBKkxsw8dajf2sKbI1XyKjplg== =3mkF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 4 02:17:37 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A39127076; Mon, 4 Dec 2017 02:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Uy_ZOErj7Cff; Mon, 4 Dec 2017 02:17:33 -0800 (PST) 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 76AC6126FDC; Mon, 4 Dec 2017 02:17:33 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7E7E296C2E804; Mon, 4 Dec 2017 10:17:29 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 10:17:30 +0000 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.248]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 18:17:19 +0800 From: "Liubing (Leo)" To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 Thread-Index: AdNpBcnuhzuf3eYUTIigJEFJrvIuMAD4kThg Date: Mon, 4 Dec 2017 10:17:18 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C790F9F2@nkgeml514-mbs.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C790F9F2nkgeml514mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 10:17:36 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C790F9F2nkgeml514mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHN1cHBvcnQgaXQgYXMgYSBjby1hdXRob3IuDQoNClNpbmNlIEdSQVNQIGlz IGV2ZW50dWFsbHkgdXNlZCBieSBhcHBsaWNhdGlvbnMgKEFTQXMpLCB0aGUgQVBJIGlzIGVzc2Vu dGlhbCBmb3IgQVNBIGRldmVsb3BlcnMuIEp1c3QgbGlrZSB0aGUgc29ja2V0IGludGVyZmFjZSwg dGhlIEdSQVNQIEFQSSBjYW4gcHJvdmlkZSBzb21lIHNlcnZpY2VzIHRvIGFwcCBsYXllci4gVGhl IHNlcnZpY2VzIGFyZSBkaXNjb3ZlcnkvU3luYy9OZWdvdGlhdGlvbiB3aGljaCB3b3VsZCBhbGxv dyBkZXZlbG9wZXJzIHRvIGZvY3VzIG9uIG5ldHdvcmsgbWFuYWdlbWVudCBmdW5jdGlvbnMgYW5k IGVsaW1pbmF0ZSByZWludmVudGluZyBiYXNpYyBuZXR3b3JrIHByb3RvY29sIOKAnHdoZWVsc+KA nS4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQpGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGVuZyBKaWFuZw0KU2VudDogV2VkbmVzZGF5 LCBOb3ZlbWJlciAyOSwgMjAxNyA3OjM2IFBNDQpUbzogYW5pbWFAaWV0Zi5vcmcNCkNjOiBhbmlt YS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFtBbmltYV0gQWRvcHRpb24gY2FsbCBmb3IgZHJh ZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS0wNiwgZW5kcyBEZWMuIDEyLCAyMDE3DQoNCg0KRHVyaW5n IHRoZSBJRVRGMTAwLCB0aGVyZSB3YXMgYSBjb25zZW5zdXMgdGhhdCBkcmFmdC1saXUtYW5pbWEt Z3Jhc3AtYXBpIGlzIGZ1bGx5IGNvbnNpc3RlbnQgd2l0aCB0aGUgY3VycmVudCBBTklNQSBjaGFy dGVyLCB1bmRlciB0aGUgY29uZGl0aW9uIGl0IGludGVuZHMgdG8gYmUgYW4gSW5mb3JtYXRpb25h bCBkb2N1bWVudC4gQWZ0ZXIgdGhlIG1lZXRpbmcsIHRoZSBhdXRob3JzIGhhdmUgdXBkYXRlZCB0 aGUgZG9jdW1lbnQuIFRoZSBjdXJyZW50IGludGVuZGVkIHN0YXR1cyBpcyBJbmZvcm1hdGlvbmFs LiBUaGVyZSB3YXMgYW4gYWRvcHRpb24gY2FsbCBvbiB0aGlzIGRvY3VtZW50IGFzIGEgQU5JTUEg d29ya2luZyBncm91cCBkb2N1bWVudCBpbiB0aGUgQU5JTUEgc2Vzc2lvbiwgSUVURjEwMC4gVGhl cmUgd2VyZSBzdXBwb3J0cyBhbmQgbm8gb2JqZWN0aW9uIGFzIGZhciBhcyBjaGFpcnMgaGVhcmQu IEFzIGFuIG9mZmljaWFsIHByb2NlZHVyZSwgd2Ugbm93IGNvbmZpcm0gdGhlIGFkb3B0aW9uIGlu IHRoZSBBTklNQSBtYWlsaW5nIGxpc3QuIFRoaXMgbWVzc2FnZSBzdGFydHMgYSB0d28td2VlayBh ZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGkuDQoNCg0KDQogIFRpdGxl OiAgICAgIEdlbmVyaWMgQXV0b25vbWljIFNpZ25hbGluZyBQcm90b2NvbCBBcHBsaWNhdGlvbiBQ cm9ncmFtIEludGVyZmFjZSAoR1JBU1AgQVBJKQ0KDQogIEF1dGhvcnMgOiAgIExpdSwgZXQgYWwu DQoNCiAgRmlsZW5hbWU6ICAgZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaQ0KDQogIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtYW5pbWEtZ3Jhc3AtYXBpLTA2DQoNCg0KDQpQ bGVhc2UgZXhwcmVzcyB5b3VyIHN1cHBvcnQgb3IgcmVqZWN0aW9uLiBJZiB5b3UgdGhpbmsgdGhp cyBkb2N1bWVudCBzaG91bGQgX25vdF8gYmUgYWRvcHRlZCwgcGxlYXNlIGFsc28gZXhwbGljaXRs eSBpbmRpY2F0ZSB0aGUgcmVhc29ucy4NCg0KDQoNClRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGVu ZCBvbiBEZWNlbWJlciAxMiwgMjAxNy4NCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpTaGVuZyArIFRv ZXJsZXNzDQoNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C790F9F2nkgeml514mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXpl OjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0Mx Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBz dHlsZT0idGV4dC1qdXN0aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5JIHN1cHBvcnQgaXQgYXMg YSBjby1hdXRob3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+U2luY2UgR1JBU1AgaXMgZXZlbnR1YWxseSB1c2Vk IGJ5IGFwcGxpY2F0aW9ucyAoQVNBcyksIHRoZSBBUEkgaXMgZXNzZW50aWFsIGZvciBBU0EgZGV2 ZWxvcGVycy4gSnVzdCBsaWtlIHRoZSBzb2NrZXQgaW50ZXJmYWNlLCB0aGUgR1JBU1AgQVBJIGNh biBwcm92aWRlIHNvbWUgc2VydmljZXMgdG8gYXBwIGxheWVyLiBUaGUgc2VydmljZXMNCiBhcmUg ZGlzY292ZXJ5L1N5bmMvTmVnb3RpYXRpb24gd2hpY2ggd291bGQgYWxsb3cgZGV2ZWxvcGVycyB0 byBmb2N1cyBvbiBuZXR3b3JrIG1hbmFnZW1lbnQgZnVuY3Rpb25zIGFuZCBlbGltaW5hdGUgcmVp bnZlbnRpbmcgYmFzaWMgbmV0d29yayBwcm90b2NvbCDigJx3aGVlbHPigJ0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkJpbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjps ZWZ0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TaGVuZyBKaWFuZzxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDI5LCAyMDE3IDc6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+ IGFuaW1hQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBhbmltYS1jaGFpcnNAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW0FuaW1hXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1saXUtYW5p bWEtZ3Jhc3AtYXBpLTA2LCBlbmRzIERlYy4gMTIsIDIwMTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkR1cmluZyB0aGUgSUVURjEwMCwgdGhlcmUgd2FzIGEgY29uc2Vuc3Vz IHRoYXQgZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaSBpcyBmdWxseSBjb25zaXN0ZW50IHdpdGgg dGhlIGN1cnJlbnQgQU5JTUEgY2hhcnRlciwgdW5kZXIgdGhlIGNvbmRpdGlvbiBpdCBpbnRlbmRz IHRvIGJlIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQuIEFmdGVyIHRoZSBtZWV0aW5nLCB0aGUg YXV0aG9ycyBoYXZlIHVwZGF0ZWQgdGhlIGRvY3VtZW50LiBUaGUgY3VycmVudCBpbnRlbmRlZCBz dGF0dXMgaXMgSW5mb3JtYXRpb25hbC4gVGhlcmUgd2FzIGFuIGFkb3B0aW9uIGNhbGwgb24gdGhp cyBkb2N1bWVudCBhcyBhIEFOSU1BIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgaW4gdGhlIEFOSU1B IHNlc3Npb24sIElFVEYxMDAuIFRoZXJlIHdlcmUgc3VwcG9ydHMgYW5kIG5vIG9iamVjdGlvbiBh cyBmYXIgYXMgY2hhaXJzIGhlYXJkLiBBcyBhbiBvZmZpY2lhbCBwcm9jZWR1cmUsIHdlIG5vdyBj b25maXJtIHRoZSBhZG9wdGlvbiBpbiB0aGUgQU5JTUEgbWFpbGluZyBsaXN0LiBUaGlzIG1lc3Nh Z2Ugc3RhcnRzIGEgdHdvLXdlZWsgYWRvcHRpb24gY2FsbCBvbiBkcmFmdC1saXUtYW5pbWEtZ3Jh c3AtYXBpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyBUaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg R2VuZXJpYyBBdXRvbm9taWMgU2lnbmFsaW5nIFByb3RvY29sIEFwcGxpY2F0aW9uIFByb2dyYW0g SW50ZXJmYWNlIChHUkFTUCBBUEkpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IEF1dGhvcnMgOiZuYnNwOyZuYnNwOyBMaXUsIGV0 IGFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyBGaWxlbmFtZTombmJzcDsgJm5ic3A7ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFw aTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWFu aW1hLWdyYXNwLWFwaS0wNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1h bmltYS1ncmFzcC1hcGktMDY8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBsZWFzZSBleHByZXNzIHlvdXIgc3VwcG9ydCBv ciByZWplY3Rpb24uIElmIHlvdSB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBfbm90XyBiZSBh ZG9wdGVkLCBwbGVhc2UgYWxzbyBleHBsaWNpdGx5IGluZGljYXRlIHRoZSByZWFzb25zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGVuZCBvbiBEZWNlbWJlciAxMiwgMjAxNy48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlNoZW5nICYjNDM7IFRvZXJsZXNzPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C790F9F2nkgeml514mbschi_-- From nobody Mon Dec 4 15:08:09 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF93C128D44 for ; Mon, 4 Dec 2017 15:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ubN9tuzTqZ1G for ; Mon, 4 Dec 2017 15:08:04 -0800 (PST) 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 9A90E128D40 for ; Mon, 4 Dec 2017 15:08:04 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 182E620072 for ; Mon, 4 Dec 2017 18:10:52 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6EBF283C61 for ; Mon, 4 Dec 2017 18:08:03 -0500 (EST) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] BRSKI/voucher design team meetings 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, 04 Dec 2017 23:08:07 -0000 --=-=-= Content-Type: text/plain The doodle poll resulted in two popular times: Tuesday at 10am and Friday at 10am. I've picked 10am Tuesday, which was our time before. conference at: https://appear.in/anima-boostrap etherpad at: https://etherpad.tools.ietf.org/p/anima-boostrapping?useMonospaceFont=true (note persistent typo: boostrap, not bootstrap) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlol1VIACgkQgItw+93Q 3WUEDAgAiEtlCl5YVfKwAkvXSRh8j8v8+Sl42OZT539I8BDr3oVv09AawM5nuuzh ZSsC+BDAFtlE+Dl1Et2qhp1vZHrhIA0POx90vQhl0ATXCX8GNEVyTpvwvkJsbfeF kIWPjAYK/lOwUfnVEw0z+qf895/gTZIe8A0qyKDDyshWMRPU80MZJNDM7fJLM0Te GgPCQ1IeoX+Muby6tvQEbufOfCDu5irxJCVuhjZx3oWhqcUz+h9U2ekBjV90uzm0 DOgfZhnw13+oDhcjMfoj2zEaMW3rWqoLBbVwsp4CLxhgTeZYj7wBEOfG2Wk3x1x+ 8uji2ZeqSnZAjmOwTqHgZoyt5guQBw== =6TTr -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 5 07:15:39 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC6127333 for ; Tue, 5 Dec 2017 07:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 d-p-QN5M-tAQ for ; Tue, 5 Dec 2017 07:15:36 -0800 (PST) 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 07308127369 for ; Tue, 5 Dec 2017 07:15:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DDE3820072; Tue, 5 Dec 2017 10:18:25 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9DA582C46; Tue, 5 Dec 2017 10:15:34 -0500 (EST) From: Michael Richardson To: Russ Housley , anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] GENART review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 15:15:37 -0000 --=-=-= Content-Type: text/plain WRT: https://datatracker.ietf.org/doc/review-ietf-anima-voucher-05-genart-lc-housley-2017-10-03/ We believe that we have responded to all of your issues. Do you agree? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlomuBYACgkQgItw+93Q 3WVXMggAgZLTNM6upJPaZFlLSJltGBu0ISNNXwX8dA9W2Y3MSnT0a6pjw7XGw7NX m64z8fJM7wSn2p3dTKzU/gXFtP1tVJEL59+znAYAxx0InzfXkoBHME0BPS54lpcx SYp3sTLpECCqZgYwswFTYW54yiCYanuyZolvLb2jCUYOUmL2i/l8zVI8YdNeRWcd FQyOdIGNkpJ3LmsTTvzZWSv5JA/CmcyNO2wNETT8w+rVt3qJHrpbUJfj/VfZIgda c45m+4GfY1qbyQPM7JDkh+pl/BttIIL7noo0gBUkxXY6EMGFPuZG/9r2A1qz3mRo ZSa4nDk7oj0P/psOYKCpJ356X739HA== =MDqg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 5 07:30:02 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816CD129537 for ; Tue, 5 Dec 2017 07:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dY1cdtpnj2IY for ; Tue, 5 Dec 2017 07:29:58 -0800 (PST) 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 8F46E129536 for ; Tue, 5 Dec 2017 07:29:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B056A20072; Tue, 5 Dec 2017 10:32:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B51AB82C46; Tue, 5 Dec 2017 10:29:57 -0500 (EST) From: Michael Richardson To: Benoit Claise cc: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] early allocation for draft-ietf-anima-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, 05 Dec 2017 15:30:00 -0000 --=-=-= Content-Type: text/plain Benoit, draft-ietf-anima-voucher asks for an OID arc: 8.3. The SMI Security for S/MIME CMS Content Type Registry We'd like to do an early allocation for this OID value so that we can update our examples earlier rather than later. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlomu3UACgkQgItw+93Q 3WWZnwf9EwMIj7K5f/nK2jVjOaNePR32zWNkqS5liiW0QPIGTkVXXSqvhCsG2K7p krpDHwSptp1p7LP/FrTMxxixWcpC5gF+VW7fcvws8bO3gOSbj0InIOgoew+N4wMA 9VHvrw5neoOR/93gOc9/TzNmMbfwdkReGjWhZKcMNaSzmpS3iUZbaEa6FcE48NdW qzdbjZt/Jnh7ZC6TuOLpX3rN2C4x4L56XZNBBE4BuqZdIlDCZDdqx92YQtCUH19N /gZrzcP5eSfT5es6sBDl5MIXNPUnGq0AVsh3iQhDLhienMirIx2C/g41r4bYHHbH 0iYrAvWVFxa98AMtZMaX9ARaIaJF0A== =R8A/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 5 07:31:09 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DE512751F for ; Tue, 5 Dec 2017 07:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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 8NK71VHFjpvI for ; Tue, 5 Dec 2017 07:31:02 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A24126C19 for ; Tue, 5 Dec 2017 07:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3780; q=dns/txt; s=iport; t=1512487862; x=1513697462; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Pwq/Zb6sk/jOtprmND9aBer9VrG6P8tmZr2b51stdIE=; b=hy5FSdF/qWEiiDzHM5/RHGKiG8agRzlh6b188fUUpHcBy5DpA+RDQviL wg1p6CTfsnkf8WcwWGx05DZnzH+CQSpKgtdJsvxOhXkDiq3Gz0+Or0wKF NuhTrkyqxJJP3CGJEziS1vDm1BAUjBS6DSSk7tRTd8rhj5503J+0ZjbJy c=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="asc'?scan'208,217";a="662547" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 15:31:00 +0000 Received: from [10.61.92.65] (ams3-vpn-dhcp7234.cisco.com [10.61.92.65]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB5FUxHK019285; Tue, 5 Dec 2017 15:31:00 GMT To: Michael Richardson , Benoit Claise Cc: anima@ietf.org References: <29399.1512487797@obiwan.sandelman.ca> From: Eliot Lear Message-ID: Date: Tue, 5 Dec 2017 16:30:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <29399.1512487797@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nok31dDtTDgISO1QmSHRwWqXbJFwlmoev" Archived-At: Subject: Re: [Anima] early allocation for draft-ietf-anima-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, 05 Dec 2017 15:31:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Nok31dDtTDgISO1QmSHRwWqXbJFwlmoev Content-Type: multipart/mixed; boundary="tOjEKcTBvcsP4xq0QtBQaBDhjChXNwT1x"; protected-headers="v1" From: Eliot Lear To: Michael Richardson , Benoit Claise Cc: anima@ietf.org Message-ID: Subject: Re: [Anima] early allocation for draft-ietf-anima-voucher References: <29399.1512487797@obiwan.sandelman.ca> In-Reply-To: <29399.1512487797@obiwan.sandelman.ca> --tOjEKcTBvcsP4xq0QtBQaBDhjChXNwT1x Content-Type: multipart/alternative; boundary="------------D6A5CE9F57DB437BDE2E0389" Content-Language: en-US This is a multi-part message in MIME format. --------------D6A5CE9F57DB437BDE2E0389 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. On 12/5/17 4:29 PM, Michael Richardson wrote: > Benoit, draft-ietf-anima-voucher asks for an OID arc: > 8.3. The SMI Security for S/MIME CMS Content Type Registry > > We'd like to do an early allocation for this OID value so that we can u= pdate > our examples earlier rather than later. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------D6A5CE9F57DB437BDE2E0389 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

+1.


On 12/5/17 4:29 PM, Michael Richardson= wrote:
Benoit, draft-ietf-anima-voucher asks for an OID arc:
        8.3.  The SMI Security for S/MIME CMS Content Type Registry

We'd like to do an early allocation for this OID value so that we can upd=
ate
our examples earlier rather than later.

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






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

--------------D6A5CE9F57DB437BDE2E0389-- --tOjEKcTBvcsP4xq0QtBQaBDhjChXNwT1x-- --Nok31dDtTDgISO1QmSHRwWqXbJFwlmoev Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJaJru0AAoJEIe2a0bZ0nozYOoH/jN1KeoWUEzgKJbVKABa1vDN 4svfc0cyseBhFeeaofVYwNT0W03emNq/ZlxwqWQaRNdCFW4LtOG2hN+Mxzf3o6/7 RMPJPhg/TyT/LE9Tn8SM6uux5FAHt9R9YeLtzmEf6PKU5i3pM8iLhZoqR+ZRt3Cq oKzZcU74BZBBlJTjzPGiOqRy/O52VWnk7GICAsWJ5ppt2qMfkebp0Ced3NF5Zccv D+x9zHkPYzM1Ar8sC1z5kgq1ZvDkl3qBMHJsJidjXFO/yLp51HFsK/CTUMUT9yc0 d4Sck5/aOmnFzJ2rrkKZJWmsPokfebxKl4MQpqb81xK5shWk0Ayek5k1qE83RK0= =sEz8 -----END PGP SIGNATURE----- --Nok31dDtTDgISO1QmSHRwWqXbJFwlmoev-- From nobody Tue Dec 5 07:57:18 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1181252BA; Tue, 5 Dec 2017 07:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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 St869tKi4Ppv; Tue, 5 Dec 2017 07:57:10 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FDF12944E; Tue, 5 Dec 2017 07:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2391; q=dns/txt; s=iport; t=1512489429; x=1513699029; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=HVgR6mb4QFTEQ6aAQ8iILewa48zJFkbtwWtaKDgVBcA=; b=lADQDyxbRBALLkPgGgh/A8hcbL6I37Kz+7lpR9Z6SWq+Wp0Hs8x39mnc WHrRIoTzYk1fmcvLith7y5l4sAFIEkzGhy+h+r3UhcKQoIv74LhwqkjTE 5y/bUNgtevye38PgSD2xuRmNu1qswug8OUXsqPj8CwCRG30BKBnbgUX/q U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AAAnwSZa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOgRVuJ4QAiiB0j1UJkV2FS4IVChgBCoFegzoChgcYAQEBAQE?= =?us-ascii?q?BAQEBayiFIwIBAwEBIUsLEAsEAT0CAicwBg0GAgEBGIoHEKk7gicmijYBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGgWDSINggWkpC4J3iDaCYwWZPIk6lROCFol1h02KPoQ?= =?us-ascii?q?Xh3yBOh85gU0yGggbFTqCKYJSHIFoQDeKKQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208,217";a="662942" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 15:57:07 +0000 Received: from [10.61.175.124] ([10.61.175.124]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vB5Fv7R5023188; Tue, 5 Dec 2017 15:57:07 GMT To: Michael Richardson Cc: anima@ietf.org, "anima-chairs@ietf.org" References: <29399.1512487797@obiwan.sandelman.ca> From: Benoit Claise Message-ID: <7d06517e-6729-beae-2c7a-917ef09c7f64@cisco.com> Date: Tue, 5 Dec 2017 16:57:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <29399.1512487797@obiwan.sandelman.ca> Content-Type: multipart/alternative; boundary="------------5A0B963554C0D4091C55DC81" Content-Language: en-US Archived-At: Subject: Re: [Anima] early allocation for draft-ietf-anima-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, 05 Dec 2017 15:57:16 -0000 This is a multi-part message in MIME format. --------------5A0B963554C0D4091C55DC81 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Approved. From here, the WG chairs can follow up with IANA (as they learned during the WG lunch training at the IETF 100). Regards, Benoit. > Benoit, draft-ietf-anima-voucher asks for an OID arc: > 8.3. The SMI Security for S/MIME CMS Content Type Registry > > We'd like to do an early allocation for this OID value so that we can update > our examples earlier rather than later. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------5A0B963554C0D4091C55DC81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Approved.

From here, the WG chairs can follow up with IANA (as they learned during the WG lunch training at the IETF 100).

Regards, Benoit.
Benoit, draft-ietf-anima-voucher asks for an OID arc:
        8.3.  The SMI Security for S/MIME CMS Content Type Registry

We'd like to do an early allocation for this OID value so that we can update
our examples earlier rather than later.

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






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

--------------5A0B963554C0D4091C55DC81-- From nobody Tue Dec 5 09:00:56 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 132A1129649; Tue, 5 Dec 2017 09:00:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: draft-ietf-anima-prefix-management.all@ietf.org, ietf@ietf.org, anima@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151249325604.23096.2883693122116292747@ietfa.amsl.com> Date: Tue, 05 Dec 2017 09:00:56 -0800 Archived-At: Subject: [Anima] Genart telechat review of draft-ietf-anima-prefix-management-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: Tue, 05 Dec 2017 17:00:56 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-anima-prefix-management-06 Reviewer: Dan Romascanu Review Date: 2017-12-05 IETF LC End Date: 2017-10-12 IESG Telechat date: 2017-12-14 Summary: Ready This document describes an ANIMA solution for IPv6 prefix management at the edge of large-scale ISP networks sketches an IPv4 solution extension to support IPv4 prefixes. It is well written, targeting the operators of ISP networks, describes the solution in a manner very clear for people familiar with the ANI framework, with useful deployment examples. A few minor issues and nits that were raised in my initial reviews were clarified, the majority of them by text changes. Major issues: Minor issues: Nits/editorial comments: From nobody Tue Dec 5 11:36:52 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DA1126C2F for ; Tue, 5 Dec 2017 11:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9-DOnCWYhi07 for ; Tue, 5 Dec 2017 11:36:49 -0800 (PST) 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 5D0F5126DCA for ; Tue, 5 Dec 2017 11:36:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 20B7720072; Tue, 5 Dec 2017 14:39:40 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 846D483C61; Tue, 5 Dec 2017 14:36:48 -0500 (EST) From: Michael Richardson To: Eliot Lear cc: Benoit Claise , anima@ietf.org In-Reply-To: References: <29399.1512487797@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] early allocation for draft-ietf-anima-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, 05 Dec 2017 19:36:51 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: > +1. I'd also like to get an early allocation for MUD's OID arc, but at this point the MUD document seems like it meant lap BRSKI. I guess that's also Benoit's call too, right? > On 12/5/17 4:29 PM, Michael Richardson wrote: > Benoit, draft-ietf-anima-voucher asks for an OID arc: > 8.3. The SMI Security for S/MIME CMS Content Type Registry > We'd like to do an early allocation for this OID value so that we can update > our examples earlier rather than later. > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlom9VAACgkQgItw+93Q 3WVwrggAg0fUWZC7y5LZVCBfjCzT+nCPTnm38jSDa7Mvp49ljaC3XgP8Q3Sr2O9B OlgoaivItaOpmQMJaWGzF97AT8Vv10fNmZJ0y2aOORxAp2in1nJPAbWeJ8mScJxL yiYwU3lvE/CVzMxTozxyUa9x32yfrRC2pTviPu6UBRJOpA92X7lwTxCxxHSJQXYP cIXHrZG0Y9vved6dq7Nrqb4Tp7ZWQ3FMav6bSL7HsYBmGxI48ReKPhr7e8Uo6gYk uSZOQBffiS4Nu4g601h5/RAXFL/xRPld1rHsQSj/Iuqy8W6kHh7qeFUXc5NJuwIC TtQW8dfnnJLLlZobY8Jc+rbMPI/AnQ== =J+Te -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 5 12:49:31 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1524F12869B for ; Tue, 5 Dec 2017 12:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 vZAIjNwJi8KC for ; Tue, 5 Dec 2017 12:49:28 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15105127978 for ; Tue, 5 Dec 2017 12:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2738; q=dns/txt; s=iport; t=1512506968; x=1513716568; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=eSezjNePwzPINRsU04PsWSxh4UEKOsH6+SYLd9FyZ9w=; b=N6Hh8FvhT9BvQjCPWcLXO4LrIeX/ECLjSl3/JcF7vGjrKa6tDDLFY2Om JJ3AkQeOg/CN67pYNoEexXZxBOkHqSVSXbqdbD7VWbE00orlCIQI/Ylxh ZB81/lgDQM1kBpaFL9Mt46DExieKBXMCWsQxMjvomEdYvpwaHNW/GiEOO E=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.45,365,1508803200"; d="asc'?scan'208";a="711614" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 20:49:26 +0000 Received: from [10.61.96.8] (dhcp-10-61-96-8.cisco.com [10.61.96.8]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB5KnP2O011547; Tue, 5 Dec 2017 20:49:25 GMT To: Michael Richardson Cc: Benoit Claise , anima@ietf.org References: <29399.1512487797@obiwan.sandelman.ca> <22285.1512502608@obiwan.sandelman.ca> From: Eliot Lear Message-ID: <79ae5af0-7aae-720e-4ec5-c2c489d90ee9@cisco.com> Date: Tue, 5 Dec 2017 21:49:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <22285.1512502608@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Mrm7B9bEetKepAgaDu12B7khqPin8f4hv" Archived-At: Subject: Re: [Anima] early allocation for draft-ietf-anima-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, 05 Dec 2017 20:49:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mrm7B9bEetKepAgaDu12B7khqPin8f4hv Content-Type: multipart/mixed; boundary="R2SDPPudr1NIf3MKQRhEqOhv6wAmKwov5"; protected-headers="v1" From: Eliot Lear To: Michael Richardson Cc: Benoit Claise , anima@ietf.org Message-ID: <79ae5af0-7aae-720e-4ec5-c2c489d90ee9@cisco.com> Subject: Re: [Anima] early allocation for draft-ietf-anima-voucher References: <29399.1512487797@obiwan.sandelman.ca> <22285.1512502608@obiwan.sandelman.ca> In-Reply-To: <22285.1512502608@obiwan.sandelman.ca> --R2SDPPudr1NIf3MKQRhEqOhv6wAmKwov5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 12/5/17 8:36 PM, Michael Richardson wrote: > Eliot Lear wrote: > > +1. > > I'd also like to get an early allocation for MUD's OID arc, but at this= point > the MUD document seems like it meant lap BRSKI. I guess that's also Be= noit's call > too, right? I think so.=C2=A0 Let's go through the exercise, tho. Eliot > > > On 12/5/17 4:29 PM, Michael Richardson wrote: > > > > Benoit, draft-ietf-anima-voucher asks for an OID arc: > > 8.3. The SMI Security for S/MIME CMS Content Type Registry > > > We'd like to do an early allocation for this OID value so that we= can update > > our examples earlier rather than later. > > > -- > > Michael Richardson , Sandelman Software Wo= rks > > -=3D IPv6 IoT consulting =3D- > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > --R2SDPPudr1NIf3MKQRhEqOhv6wAmKwov5-- --Mrm7B9bEetKepAgaDu12B7khqPin8f4hv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJaJwZVAAoJEIe2a0bZ0noz3VcIANZ6w1qwU+Y/D5FU39vgQtWX SC1ARK75s3JL6oaZx1FysJGeeM/j8H1zfsTUOs1DGZpBDXyr3kiCLojS2gE+dfPF i6nnNtR5WDzr8FxqNRCzMy1qFJAnOFSc/4OoZ57uDWw+PwOmztzBXe307WF3VLjr 5WO+lSsHbJfJ1f93dZMvmBnnk3PuxATRM+TLm1qjZFbfwXTuTIFH2sa9yQ2C+LzW eOEDkX+F7jijx6QqXRYEX+SGSD2iy8/a/YvH9+cpjexiPqXbwO/xIDq01cMdp7i3 iepnGhECEJBO+rbrNFSzavIDNgpwi783gA1saIEkB2S35VmeazT53pxgHezHOMU= =tIgl -----END PGP SIGNATURE----- --Mrm7B9bEetKepAgaDu12B7khqPin8f4hv-- From nobody Thu Dec 7 01:07:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE48120454 for ; Thu, 7 Dec 2017 01:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 3Ljs9UMcm-gp for ; Thu, 7 Dec 2017 01:07:48 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 177A91200C1 for ; Thu, 7 Dec 2017 01:07:48 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id y21so6660717wrc.1 for ; Thu, 07 Dec 2017 01:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=+C5588XNI1PA2FrPHBwy6pQsDrDyTEf0jWhnff8ZJ4k=; b=KRELNWYb42mcpk658GCunD52iEi9Ygg+TffQGLlUr0105XiSH0bWf01Jf2MmU3a5dO +PrwUNnVqor3wTc5HCRYRMG+/DEOBMDntwwwkPNaf62YqA9iHgk4FUzD3H6VWLw/nmz5 IWNl7ovhgOF+h5aB66JYPjrGKsrmZSnrfEkxXHx7avFlowaBBFLqD1KtF0e2YS7zMcCt vG87RcPtKSub2fAOxihYtjKSCqsILy5ENn2hEUpcjm287qHi9Azo8jjdrEq4rcGLYdw6 HX5/adBlIf1seB8dATg3oWH71qo/1E0vOFJMKPX9+NVaf4mQPzbI5PVj4a/biqG3Hq1K xUPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=+C5588XNI1PA2FrPHBwy6pQsDrDyTEf0jWhnff8ZJ4k=; b=bg7Zv+/myXnBBzQUJbfMu9+ny8/MMmDZMe2f10fosBgQbQlUsECy/MkEmJkKEqInw5 TFxSM4zYRjvv9MjQMClSamCHM1z6vj8XMOhB4zzOSsPc8mtVT0fpfPgshUsHAxc83LbS ZJRqOwkUdkGx5O31emd/aKZGZwUaWYQwnMVfQwL2E7QXfiDwT+tx6IomXYjldoFHH9Pa 9EHAjEBFUhs9FmH7TjdCmR26yTvvkGqki1LJJkZvER2p2wKbuB5b3uGIOf3BW6G8vaRC 2HWqYSgn1HM0Oy8Q4ua59ea9dbmIFiHuh+nJdRpmZHrm/qLlbuEsnWiFAA/voEsDfKMf py1w== X-Gm-Message-State: AJaThX5YI6JoYXNRpYHpBdLGpiYtcWYirgrNDnebDeJB/cBW3HRzMR3o TC326ZOha2bz9XAVXrZwN1FYbmXY X-Google-Smtp-Source: AGs4zMa21/DoYfDiE8GFJKdLS0tHZPXa6PwSI62AIu9KTl5qW/296TpAe7HV9MYG+E1HZPK6LSoMkw== X-Received: by 10.223.160.217 with SMTP id n25mr21758459wrn.27.1512637665228; Thu, 07 Dec 2017 01:07:45 -0800 (PST) Received: from [192.168.1.25] (ANice-652-1-128-39.w83-201.abo.wanadoo.fr. [83.201.151.39]) by smtp.gmail.com with ESMTPSA id o10sm5183451wrg.5.2017.12.07.01.07.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 01:07:44 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: "anima@ietf.org" Message-ID: Date: Thu, 7 Dec 2017 10:07:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 09:07:50 -0000 I also support the adoption of this document. Michael On 29/11/2017 6:35 AM, Sheng Jiang wrote: > During the IETF100, there was a consensus that draft-liu-anima-grasp-api > is fully consistent with the current ANIMA charter, under the condition > it intends to be an Informational document. After the meeting, the > authors have updated the document. The current intended status is > Informational. There was an adoption call on this document as a ANIMA > working group document in the ANIMA session, IETF100. There were > supports and no objection as far as chairs heard. As an official > procedure, we now confirm the adoption in the ANIMA mailing list. This > message starts a two-week adoption call on draft-liu-anima-grasp-api. > > > >   Title:      Generic Autonomic Signaling Protocol Application Program > Interface (GRASP API) > >   Authors :   Liu, et al. > >   Filename:   draft-liu-anima-grasp-api > > https://tools.ietf.org/html/draft-liu-anima-grasp-api-06 > > > > 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 December 12, 2017. > > > > Regards, > > > > Sheng + Toerless > > > > > > _______________________________________________ > 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. Westhttp://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 References: * [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 Sheng Jiang From nobody Thu Dec 7 08:44:52 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDABF129488 for ; Thu, 7 Dec 2017 08:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 iICgaWyH3Azh for ; Thu, 7 Dec 2017 08:44:49 -0800 (PST) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (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 2CC60127522 for ; Thu, 7 Dec 2017 08:44:49 -0800 (PST) Received: by mail-lf0-f54.google.com with SMTP id j124so8889980lfg.2 for ; Thu, 07 Dec 2017 08:44:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rafeGrdZEzpQP6IspSA4x0uXZcpj3ZUtCsbi/Jx0WPc=; b=ktAzs9U9k16O6PFiaLRBjEc3TLkTJXMSNweYEY1CamB/LJnzkn55HRpuUFpIuMN9Dy rEQYytnrKVg/KWG+6oUysRxxF8X14wmJimEWTB+Ymoj0AdEq6PoEd6ohfPuywttvQG9S Gr5ieXq55hL9ng/mifwj120NDMcgZscgPnypIXFqAOt+8DZqZHlLm9svy9k5MxfefEN4 QP17ZOgXvdEYlKUx1VgvmxT77xCVwqaZtDMYxFkKHsKisAXV5zcyirt0LGEMN+LkKq8Y xnCy3P+Y9CVnfz1g8Xt/gAvcfnEPks3K4zWOfWzKZEwbLo6j9sesUPSgyx7NjjOxJYy6 408Q== X-Gm-Message-State: AJaThX4PWxaOCQWtdhwxS8ByXeUx2ajF2eSd0DDoZ/Is3f3eVuH3NSHY 6HDYR6baQ92LMLjyz8NZs4wuC7kg0NPoVxDLuQR6 X-Google-Smtp-Source: AGs4zMZXASS7XDl+d0DYvC3EbXD+Jw3g3GOGA7wtq7RiWd9GkRvnwCCZf3Eo9AeXT0Bs446osusxQ3BFV9DRwQzlo0s= X-Received: by 10.25.41.194 with SMTP id p185mr11854386lfp.125.1512665086666; Thu, 07 Dec 2017 08:44:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Thu, 07 Dec 2017 16:44:35 +0000 Message-ID: To: anima@ietf.org Content-Type: multipart/alternative; boundary="001a11410a8027acfc055fc2c929" Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 16:44:52 -0000 --001a11410a8027acfc055fc2c929 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear ANIMA. I read and support the adoption of this document. Best. J=C3=A9ferson Em qui, 7 de dez de 2017 07:07, Michael H. Behringer < michael.h.behringer@gmail.com> escreveu: > I also support the adoption of this document. > > Michael > > On 29/11/2017 6:35 AM, Sheng Jiang wrote: > > During the IETF100, there was a consensus that draft-liu-anima-grasp-ap= i > > is fully consistent with the current ANIMA charter, under the condition > > it intends to be an Informational document. After the meeting, the > > authors have updated the document. The current intended status is > > Informational. There was an adoption call on this document as a ANIMA > > working group document in the ANIMA session, IETF100. There were > > supports and no objection as far as chairs heard. As an official > > procedure, we now confirm the adoption in the ANIMA mailing list. This > > message starts a two-week adoption call on draft-liu-anima-grasp-api. > > > > > > > > Title: Generic Autonomic Signaling Protocol Application Program > > Interface (GRASP API) > > > > Authors : Liu, et al. > > > > Filename: draft-liu-anima-grasp-api > > > > https://tools.ietf.org/html/draft-liu-anima-grasp-api-06 > > > > > > > > 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 December 12, 2017. > > > > > > > > Regards, > > > > > > > > Sheng + Toerless > > > > > > > > > > > > _______________________________________________ > > 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. Westhttp://users.encs.concordia.ca/~bill > > Montreal, Quebec Canada H3G 1M8 > > > References: > > * [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. > 12, 2017 > < > https://mailarchive.ietf.org/arch/msg/anima/zjl6w5PUysz-ZtZKQFU_Lu3dzDA> > Sheng Jiang > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a11410a8027acfc055fc2c929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear ANIMA.
I read and support the adoption of this document.
Best.
J=C3=A9ferson

Em qui, 7 de dez de 2017 07:07, Michael H. Beh= ringer <michael.h.behri= nger@gmail.com> escreveu:
I = also support the adoption of this document.

Michael

On 29/11/2017 6:35 AM, Sheng Jiang wrote:
> During the IETF100, there was a consensus that draft-liu-anima-grasp-a= pi
> is fully consistent with the current ANIMA charter, under the conditio= n
> it intends to be an Informational document. After the meeting, the
> authors have updated the document. The current intended status is
> Informational. There was an adoption call on this document as a ANIMA<= br> > working group document in the ANIMA session, IETF100. There were
> supports and no objection as far as chairs heard. As an official
> procedure, we now confirm the adoption in the ANIMA mailing list. This=
> message starts a two-week adoption call on draft-liu-anima-grasp-api.<= br> >
>
>
> =C2=A0 Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Generic Autonomic Signalin= g Protocol Application Program
> Interface (GRASP API)
>
> =C2=A0 Authors :=C2=A0=C2=A0 Liu, et al.
>
> =C2=A0 Filename:=C2=A0 =C2=A0draft-liu-anima-grasp-api
>
>=C2=A0 =C2=A0https://tools.ietf.org/html= /draft-liu-anima-grasp-api-06
>
>
>
> Please express your support or rejection. If you think this document > should _not_ be adopted, please also explicitly indicate the reasons.<= br> >
>
>
> This adoption call will end on December 12, 2017.
>
>
>
> Regards,
>
>
>
> Sheng + Toerless
>
>
>
>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org= <mailto:Anima@ietf.= org>
> https://www.ietf.org/mailman/listinfo/anima
>

--

Dr. J.W. Atwood, Eng.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tel:= =C2=A0 =C2=A0+1 (514) 848-2424 x3046
Distinguished Professor Emeritus=C2=A0 fax:=C2=A0 =C2=A0+1 (514) 848-2830 Department of Computer Science
=C2=A0 =C2=A0 and Software Engineering
Concordia University EV 3.185=C2=A0 =C2=A0 =C2=A0email:william.atwood@concord= ia.ca
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bi= ll
<http://users.encs.concordia.ca/%7Ebill>
Montreal, Quebec Canada H3G 1M8


=C2=A0 =C2=A0 =C2=A0 =C2=A0 References:

=C2=A0 * [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec.<= br> =C2=A0 =C2=A0 12, 2017
=C2=A0 =C2=A0 <https://mai= larchive.ietf.org/arch/msg/anima/zjl6w5PUysz-ZtZKQFU_Lu3dzDA>
=C2=A0 =C2=A0 Sheng Jiang <jiangsheng@huawei.com>

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a11410a8027acfc055fc2c929-- From nobody Fri Dec 8 00:46:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE65126B6E; Fri, 8 Dec 2017 00:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vNwWy56tj7YJ; Fri, 8 Dec 2017 00:46:47 -0800 (PST) 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 AEB541201F8; Fri, 8 Dec 2017 00:46:46 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 67D074AFB8E71; Fri, 8 Dec 2017 08:46:42 +0000 (GMT) Received: from lhreml507-mbb.china.huawei.com ([10.201.109.48]) by lhreml706-cah.china.huawei.com ([10.201.108.47]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 08:46:42 +0000 From: Xun Xiao To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 Thread-Index: AdNpBcnuhzuf3eYUTIigJEFJrvIuMAG+wj9w Date: Fri, 8 Dec 2017 08:46:41 +0000 Message-ID: <67C6AE5A0CF6AD45A8571ED3F6E802E41376C10B@lhreml507-mbb> References: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.218] Content-Type: multipart/alternative; boundary="_000_67C6AE5A0CF6AD45A8571ED3F6E802E41376C10Blhreml507mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 08:46:49 -0000 --_000_67C6AE5A0CF6AD45A8571ED3F6E802E41376C10Blhreml507mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbmltYSBhbmQgY2hhaXJzLA0KDQpJIHN1cHBvcnQgdG8gYWRvcHQgdGhpcyBkb2N1bWVu dCwgd2hpY2ggd2lsbCBzdGFuZGFyZGl6ZSB0aGUgaW50ZXJmYWNlIHRvIHRoZSBhbmltYSBzeXN0 ZW0uIFRoYW5rcy4NCg0KQlIuDQoNCi1YdW4gWGlhbw0KDQpGcm9tOiBBbmltYSBbbWFpbHRvOmFu aW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGVuZyBKaWFuZw0KU2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAxMjozNiBQTQ0KVG86IGFuaW1hQGlldGYub3JnDQpD YzogYW5pbWEtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBbQW5pbWFdIEFkb3B0aW9uIGNhbGwg Zm9yIGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGktMDYsIGVuZHMgRGVjLiAxMiwgMjAxNw0KDQoN CkR1cmluZyB0aGUgSUVURjEwMCwgdGhlcmUgd2FzIGEgY29uc2Vuc3VzIHRoYXQgZHJhZnQtbGl1 LWFuaW1hLWdyYXNwLWFwaSBpcyBmdWxseSBjb25zaXN0ZW50IHdpdGggdGhlIGN1cnJlbnQgQU5J TUEgY2hhcnRlciwgdW5kZXIgdGhlIGNvbmRpdGlvbiBpdCBpbnRlbmRzIHRvIGJlIGFuIEluZm9y bWF0aW9uYWwgZG9jdW1lbnQuIEFmdGVyIHRoZSBtZWV0aW5nLCB0aGUgYXV0aG9ycyBoYXZlIHVw ZGF0ZWQgdGhlIGRvY3VtZW50LiBUaGUgY3VycmVudCBpbnRlbmRlZCBzdGF0dXMgaXMgSW5mb3Jt YXRpb25hbC4gVGhlcmUgd2FzIGFuIGFkb3B0aW9uIGNhbGwgb24gdGhpcyBkb2N1bWVudCBhcyBh IEFOSU1BIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgaW4gdGhlIEFOSU1BIHNlc3Npb24sIElFVEYx MDAuIFRoZXJlIHdlcmUgc3VwcG9ydHMgYW5kIG5vIG9iamVjdGlvbiBhcyBmYXIgYXMgY2hhaXJz IGhlYXJkLiBBcyBhbiBvZmZpY2lhbCBwcm9jZWR1cmUsIHdlIG5vdyBjb25maXJtIHRoZSBhZG9w dGlvbiBpbiB0aGUgQU5JTUEgbWFpbGluZyBsaXN0LiBUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgdHdv LXdlZWsgYWRvcHRpb24gY2FsbCBvbiBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtYXBpLg0KDQoNCg0K ICBUaXRsZTogICAgICBHZW5lcmljIEF1dG9ub21pYyBTaWduYWxpbmcgUHJvdG9jb2wgQXBwbGlj YXRpb24gUHJvZ3JhbSBJbnRlcmZhY2UgKEdSQVNQIEFQSSkNCg0KICBBdXRob3JzIDogICBMaXUs IGV0IGFsLg0KDQogIEZpbGVuYW1lOiAgIGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGkNCg0KICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS0wNg0K DQoNCg0KUGxlYXNlIGV4cHJlc3MgeW91ciBzdXBwb3J0IG9yIHJlamVjdGlvbi4gSWYgeW91IHRo aW5rIHRoaXMgZG9jdW1lbnQgc2hvdWxkIF9ub3RfIGJlIGFkb3B0ZWQsIHBsZWFzZSBhbHNvIGV4 cGxpY2l0bHkgaW5kaWNhdGUgdGhlIHJlYXNvbnMuDQoNCg0KDQpUaGlzIGFkb3B0aW9uIGNhbGwg d2lsbCBlbmQgb24gRGVjZW1iZXIgMTIsIDIwMTcuDQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KU2hl bmcgKyBUb2VybGVzcw0KDQo= --_000_67C6AE5A0CF6AD45A8571ED3F6E802E41376C10Blhreml507mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5IVE1MLCBsaS5IVE1MLCBkaXYuSFRNTA0K CXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8iOw0KCW1zby1zdHlsZS1saW5rOiJI VE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTo rr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0 eWxlPSJ0ZXh0LWp1c3RpZnktdHJpbTpwdW5jdHVhdGlvbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5EZWFyIEFuaW1hIGFuZCBjaGFpcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgc3VwcG9ydCB0byBh ZG9wdCB0aGlzIGRvY3VtZW50LCB3aGljaCB3aWxsIHN0YW5kYXJkaXplIHRoZSBpbnRlcmZhY2Ug dG8gdGhlIGFuaW1hIHN5c3RlbS4gVGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QlIuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi1YdW4g WGlhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEFuaW1hIFttYWlsdG86 YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2hlbmcgSmlhbmc8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAxMjozNiBQTTxi cj4NCjxiPlRvOjwvYj4gYW5pbWFAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGFuaW1hLWNoYWly c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbQW5pbWFdIEFkb3B0aW9uIGNhbGwgZm9y IGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGktMDYsIGVuZHMgRGVjLiAxMiwgMjAxNzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+RHVyaW5nIHRoZSBJRVRGMTAwLCB0aGVyZSB3YXMgYSBjb25zZW5zdXMgdGhh dCBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtYXBpIGlzIGZ1bGx5IGNvbnNpc3RlbnQgd2l0aCB0aGUg Y3VycmVudCBBTklNQSBjaGFydGVyLCB1bmRlciB0aGUgY29uZGl0aW9uIGl0IGludGVuZHMgdG8g YmUgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudC4gQWZ0ZXIgdGhlIG1lZXRpbmcsIHRoZSBhdXRo b3JzIGhhdmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQuIFRoZSBjdXJyZW50IGludGVuZGVkIHN0YXR1 cyBpcyBJbmZvcm1hdGlvbmFsLiBUaGVyZSB3YXMgYW4gYWRvcHRpb24gY2FsbCBvbiB0aGlzIGRv Y3VtZW50IGFzIGEgQU5JTUEgd29ya2luZyBncm91cCBkb2N1bWVudCBpbiB0aGUgQU5JTUEgc2Vz c2lvbiwgSUVURjEwMC4gVGhlcmUgd2VyZSBzdXBwb3J0cyBhbmQgbm8gb2JqZWN0aW9uIGFzIGZh ciBhcyBjaGFpcnMgaGVhcmQuIEFzIGFuIG9mZmljaWFsIHByb2NlZHVyZSwgd2Ugbm93IGNvbmZp cm0gdGhlIGFkb3B0aW9uIGluIHRoZSBBTklNQSBtYWlsaW5nIGxpc3QuIFRoaXMgbWVzc2FnZSBz dGFydHMgYSB0d28td2VlayBhZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1h cGkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgVGl0bGU6Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdlbmVyaWMgQXV0b25vbWljIFNpZ25hbGluZyBQcm90b2Nv bCBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZSAoR1JBU1AgQVBJKTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsgQXV0aG9ycyA6Jm5ic3A7Jm5ic3A7IExpdSwgZXQgYWwuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyBGaWxlbmFtZTombmJzcDsgJm5ic3A7ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxp dS1hbmltYS1ncmFzcC1hcGktMDYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s aXUtYW5pbWEtZ3Jhc3AtYXBpLTA2PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PlBsZWFzZSBleHByZXNzIHlvdXIgc3VwcG9ydCBvciByZWplY3Rpb24uIElmIHlvdSB0aGluayB0 aGlzIGRvY3VtZW50IHNob3VsZCBfbm90XyBiZSBhZG9wdGVkLCBwbGVhc2UgYWxzbyBleHBsaWNp dGx5IGluZGljYXRlIHRoZSByZWFzb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgZW5kIG9uIERlY2VtYmVyIDEyLCAyMDE3LjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPlNoZW5nICYjNDM7IFRvZXJsZXNzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_67C6AE5A0CF6AD45A8571ED3F6E802E41376C10Blhreml507mbb_-- From nobody Fri Dec 8 09:03:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715C61288A9 for ; Fri, 8 Dec 2017 09:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 4fLUWO24Yy_x for ; Fri, 8 Dec 2017 09:03:42 -0800 (PST) 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 A8585127522 for ; Fri, 8 Dec 2017 09:03:42 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B4AC02008D for ; Fri, 8 Dec 2017 12:06:42 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 151678067D for ; Fri, 8 Dec 2017 12:03:41 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 17:03:44 -0000 --=-=-= Content-Type: text/plain I have no objection to the API document being adopted. I generally believe that the IETF should do more API documents rather than less. I do find some of the ways that the IEEE tries to define protocols via APIs (such as 802.15.4) unreasonably obtuse, and I don't propose to go that route. The way we do APIs is just fine for me. Having said that, I would like the WG to either: 1) progress this document very quickly with the intention of doing a -bis in two or three years. 2) progress this document very slowly such that it won't be done until two or three years. I am saying this because I believe that there are simply unknown unknowns here, which we will only discover once people attempt attempt to build non-trivial ASAs. I point to PFKEY as an example of an API that was standardized too soon, never revised, and turned out to be inadequate for real use. It was never revised because each vendor had already made their own extensions and deployed them, and did not want to change, and the people who did those extensions were not part of the IETF process, so there was no energy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloqxewACgkQgItw+93Q 3WUDqggAsgaBLCGYAiYH65TQl8MTyIzsXXFsCjamQYhQlxGX38qzVBAhTLVCZBEc sNfAw8v677iFe3N527R3FksjuUKSoJbod9PTmO78qNlsnV+HiDVo7MC7A0annhNk RK4Shj1L4jNxWpkDvoEkZ35YOsLO+wPHtY28YsYYEohTZK83+M5yBanGALq52J17 YIvM5T1JqFJe5kXgwQV++cc2uhEPVkexWRxLbn9393CjRd0RVSJguJKpO5kFU7Dg NnnGl1r+/PUDdnIrzm+4+nQf2HOg/Kuw57dzwrKBaRnwKF1Ra8mmC8WEzTVAoYHS +tfNbtqZxNuLG50dfcnTdB1yf2HbVg== =hFm+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 8 11:02:06 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DD11289B0 for ; Fri, 8 Dec 2017 11:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfCzH5luVgjc for ; Fri, 8 Dec 2017 11:01:53 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 97EE3126D85 for ; Fri, 8 Dec 2017 11:01:53 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id v26so7895513pfl.7 for ; Fri, 08 Dec 2017 11:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=t1u5U7ANf98zQJVTcsmzO2T3nItVH69G8HqgGWXRlzE=; b=ilrAH4smATE/pDfrQXtitAk+FUjIkYC0oTsAXvvfk/OA5+xKUpVnNpsPas3cr/jM3u xUO3kmJ6FiOY6fiJ7pP+iXXYGWgsKKfYMRQJor1uhLeANANyMdFbfjOEeLAM5ILdII/7 vC0oA27J2LJ7b/uXjRhxvjMiIeP4Ebm99DbgsNK73Rd9h+ziHhC6t2leZXEv74XcPlUs UP3pC4/AAuXFAbXAAp+09zQzd4nZbsXwB8BgLPkH4MtehZ73gANXP3W0aVlvun42uw65 3KrogxGTo2HfZO4caNy2bJLvEdDFv0IipPyQQl87irtnJ86+i8YB3r8TEu+bGAr8AXYo ZHAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=t1u5U7ANf98zQJVTcsmzO2T3nItVH69G8HqgGWXRlzE=; b=ehHAtxIKQRWiuVuK+22yC7ed6jfkc8DF50r7MN73EO3rHhQBVli+Cs/Nmz8G+Le7wI o3KI6/UwORH31CCCVLzTLa82wkFaKS+RDqOxq/7f8k2ukx/kRMQKTNj5tLOnIvfp/9hK P1ExpCh5fNv1CbjYdYYrwXR6Wn/8Oeq3ivb0jOazryEqWKROshrtMLYEctDfzOa7LXr6 ZtcjlOs9cAEqCx/t7TY4qcHFGvhIS2PLilGnRurSWk6IfKts48Q86FCASlTOKVrWioNJ UjsKZ4Cxhf/5kXH+DncuJlV9qYtYgoFgEdSb6FPPXE7JrvtlTLq+PdztLiGnakykxf0R LuRg== X-Gm-Message-State: AJaThX6yLguD3P4CGo4jMEJeOqBgFytsvxDVAsfnGgMyGHPxad2C7B8q 2XYcnr8onB6Ip5L/jFzFNQbljw== X-Google-Smtp-Source: AGs4zMZ60H4Kwd9US0ocJoBjOGi+9HLeOQurLdubTCxp8fhErkDY5WeLrpaR/i06A0ke6mPDgBmzYg== X-Received: by 10.99.138.194 with SMTP id y185mr30326153pgd.290.1512759712665; Fri, 08 Dec 2017 11:01:52 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j6sm16456081pfk.152.2017.12.08.11.01.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 11:01:51 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <13611.1512752621@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 9 Dec 2017 08:01:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <13611.1512752621@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 19:01:55 -0000 On 09/12/2017 06:03, Michael Richardson wrote: .. > I am saying this because I believe that there are simply unknown unknowns > here, which we will only discover once people attempt attempt to build > non-trivial ASAs. I completely agree. (In fact, the same is true of GRASP itself, which can quite easily be extended if we discover that new message types are needed.) In particular, there's the question of exactly how much of the protocol state machine is hidden behind the API, and how much can be controlled by the ASA itself. Only experience will tell us the correct answer. > 1) progress this document very quickly with the intention of doing > a -bis in two or three years. I'd prefer that approach, to encourage ASA prototyping as soon as possible. (Well, that's what I've already done, and everyone is invited to join in: https://github.com/becarpenter/graspy/blob/master/graspy.pdf) Brian From nobody Sat Dec 9 06:41:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B812922E for ; Sat, 9 Dec 2017 06:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mTsMNFyjLDf0 for ; Sat, 9 Dec 2017 06:41:46 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203EA124B17 for ; Sat, 9 Dec 2017 06:41:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3E24930066E for ; Sat, 9 Dec 2017 09:41:45 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UKH3XcVpfNQV for ; Sat, 9 Dec 2017 09:41:44 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BC038300440; Sat, 9 Dec 2017 09:41:43 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <25934.1512486934@obiwan.sandelman.ca> Date: Sat, 9 Dec 2017 09:41:42 -0500 Cc: anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02233B6C-75D1-4E8D-A024-2A08AFD197FC@vigilsec.com> References: <25934.1512486934@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] GENART review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 14:41:48 -0000 Yes, then major and minor concerns have been addressed. Russ > On Dec 5, 2017, at 10:15 AM, Michael Richardson = wrote: >=20 >=20 > WRT: > = https://datatracker.ietf.org/doc/review-ietf-anima-voucher-05-genart-lc-ho= usley-2017-10-03/ >=20 > We believe that we have responded to all of your issues. > Do you agree? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Sat Dec 9 08:58:08 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F49126CE8; Sat, 9 Dec 2017 08:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 T2J5wJTwdhnt; Sat, 9 Dec 2017 08:58:04 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 270D71200B9; Sat, 9 Dec 2017 08:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vB9Gvngn015339; Sat, 9 Dec 2017 17:57:51 +0100 (CET) Received: from [192.168.217.119] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yvFlK0zzPzDWMq; Sat, 9 Dec 2017 17:57:49 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> Date: Sat, 9 Dec 2017 17:57:48 +0100 Cc: "anima@ietf.org" , "anima-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 534531468.154607-e3f054116e6b1fcd2901861a3ac4be85 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 16:58:06 -0000 On Nov 29, 2017, at 12:35, Sheng Jiang wrote: >=20 > During the IETF100, there was a consensus that = draft-liu-anima-grasp-api is fully consistent with the current ANIMA = charter, under the condition it intends to be an Informational document. = After the meeting, the authors have updated the document. The current = intended status is Informational. There was an adoption call on this = document as a ANIMA working group document in the ANIMA session, = IETF100. There were supports and no objection as far as chairs heard. As = an official procedure, we now confirm the adoption in the ANIMA mailing = list.=20 I wasn=E2=80=99t in the room when this was discussed. I believe it is a good thing that the IETF is not in the habit of = automatically creating an API for each protocol that it defines (=E2=80=9C= IETF doesn=E2=80=99t do APIs=E2=80=9D). However, there are specific = situations when creating APIs is useful: =E2=80=94 adoption of a new technology may benefit from a common API = being available. E.g., RFC 2292/3542 has helped IPv6 adoption a lot by = making applications possible that would have had to use IPv4 otherwise. = Similar, RFC 6458 for SCTP. =E2=80=94 the API may clarify the =E2=80=9Cnorthbound interface=E2=80=9D = of the protocol implementation. Sometimes it is not clear from a = protocol what the actual meaning of running the protocol is supposed to = be. While we probably don=E2=80=99t want to automatically define a = =E2=80=9Cservice interface=E2=80=9D like in the OSI model for each = protocol, a more innovative protocol may be hard to understand without = the image of such an API in the mind of the reader. I believe both of these effects can be had here, so it is good that the = authors have written up the API. I also agree that there should be an intent of finishing this quickly to = aid adoption, and of revisiting the API again after a few years of = getting experience =E2=80=94 after all, this is not intended as a = =E2=80=9CStandard". This probably does not justify going for = =E2=80=9CExperimental=E2=80=9D: First, this isn=E2=80=99t really a = protocol, and second, there is no formal experiment being run here that = will be done at some point: This API is supposed to last unless we learn = that it can be improved. So I completely agree with (what I understand was) the in-room consensus = at IETF 100 and the sentiments that were expressed here. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 12 00:36:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496A91292F5; Tue, 12 Dec 2017 00:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Stjo9vjR_yVM; Tue, 12 Dec 2017 00:36:53 -0800 (PST) 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 8C6F31201F8; Tue, 12 Dec 2017 00:36:53 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 09A2A58C4BF; Tue, 12 Dec 2017 09:36:49 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E8D52B0D432; Tue, 12 Dec 2017 09:36:48 +0100 (CET) Date: Tue, 12 Dec 2017 09:36:48 +0100 From: Toerless Eckert To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" , Carsten Bormann Message-ID: <20171212083648.GA4071@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 08:36:56 -0000 +1 supporting adoption of this document. Also interested to contribute to the effort. +1 on Mcr/Carstens suggestion to be fast & furios (don't drag this out for long). Wrt. to APIs and IETF: I expect that we may need to refine terminology to pass IESG review, such as maybe requiring us to more often emphasize how this is an "abstract API", or definition of "northbound service features" or the like (even in the title). [ Any time we use the term "API" without further atribute, there are folks wanting to misinterpret it as a "concrete API" (for specific programming language). Which is what the IETF does not like (and has no real expertise in), and which the draft also not attempts to specify. ] Cheers Toerless On Sat, Dec 09, 2017 at 05:57:48PM +0100, Carsten Bormann wrote: > On Nov 29, 2017, at 12:35, Sheng Jiang wrote: > > > > During the IETF100, there was a consensus that draft-liu-anima-grasp-api is fully consistent with the current ANIMA charter, under the condition it intends to be an Informational document. After the meeting, the authors have updated the document. The current intended status is Informational. There was an adoption call on this document as a ANIMA working group document in the ANIMA session, IETF100. There were supports and no objection as far as chairs heard. As an official procedure, we now confirm the adoption in the ANIMA mailing list. > > I wasn???t in the room when this was discussed. > > I believe it is a good thing that the IETF is not in the habit of automatically creating an API for each protocol that it defines (???IETF doesn???t do APIs???). However, there are specific situations when creating APIs is useful: > > ??? adoption of a new technology may benefit from a common API being available. E.g., RFC 2292/3542 has helped IPv6 adoption a lot by making applications possible that would have had to use IPv4 otherwise. Similar, RFC 6458 for SCTP. > ??? the API may clarify the ???northbound interface??? of the protocol implementation. Sometimes it is not clear from a protocol what the actual meaning of running the protocol is supposed to be. While we probably don???t want to automatically define a ???service interface??? like in the OSI model for each protocol, a more innovative protocol may be hard to understand without the image of such an API in the mind of the reader. > > I believe both of these effects can be had here, so it is good that the authors have written up the API. > > I also agree that there should be an intent of finishing this quickly to aid adoption, and of revisiting the API again after a few years of getting experience ??? after all, this is not intended as a ???Standard". This probably does not justify going for ???Experimental???: First, this isn???t really a protocol, and second, there is no formal experiment being run here that will be done at some point: This API is supposed to last unless we learn that it can be improved. > > So I completely agree with (what I understand was) the in-room consensus at IETF 100 and the sentiments that were expressed here. > > Grüße, Carsten From nobody Tue Dec 12 01:36:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F541286B1; Tue, 12 Dec 2017 01:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RthlRPpSoezp; Tue, 12 Dec 2017 01:35:59 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40091.outbound.protection.outlook.com [40.107.4.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA1E127978; Tue, 12 Dec 2017 01:35:58 -0800 (PST) Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com (10.167.170.156) by AM5PR0602MB3250.eurprd06.prod.outlook.com (10.167.170.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 12 Dec 2017 09:35:56 +0000 Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::5e9:e441:e61f:7696]) by AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::5e9:e441:e61f:7696%13]) with mapi id 15.20.0302.014; Tue, 12 Dec 2017 09:35:56 +0000 From: "Diego R. Lopez" To: Toerless Eckert , Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" , Carsten Bormann Thread-Topic: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 Thread-Index: AQHTcyRifD0H7nlut0WH3EQORKSzQaM/g7GA Date: Tue, 12 Dec 2017 09:35:55 +0000 Message-ID: <8A72C264-180E-425A-8B86-CC8DF6E96F69@telefonica.com> References: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> <20171212083648.GA4071@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20171212083648.GA4071@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.8.0.171205 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [163.117.91.69] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0602MB3250; 6:r47AVwt0P3Hqd49f2QoDLQvuXYnjpiKcBQ63GDVOx6Hb9KKS+l61+HwL5JF4au5zagAzkpuzZDY2teprfdLo9yEmuStf0AstMW8YDpaJZmUQfv0jeW1yh5m1m/WNCPxn3UrtUBXDJ/vuiM2DRkEArLN784ybi6fnuE+qCCWm08sLa6h+iZ8aTJT72InftUDuzrep23Y2Ian4Uc9oLWqKm9oOIbk4AZ4RQFPKKKajlaN1szP3DdufFRPe3wzl3tMOpspuId5lPCwRQGn+0Srpq6Y1ch1IpnCiL8kmioIrcMlGEHjhMeLiBtpit8PhI0PUVNDomHbfQL1ijH8lNWsYcrSGofUlbvJRvMM8u1cdaxM=; 5:MNsdWh6jqshW4o7LGrrWr1IBEfaX1o2uPXmXkLThKoaMCGby39aKodYiNK/u0tGRfB+oq9pEApdOheRK5Oe4iZjYTZFptHe0kobb9Aap3I20NwLid/5up/g2i16LO5RztfB7vfmc2rmrGwqfAX1s9WrbD9s/tLMSaUWsoGDS/TQ=; 24:oarck16LbzbqOxiKEiX9eCQnOOBb2ai4CvlSY7N6+WKavpwsWT16MD1FSmtZqGF0Im/Y4BSnBi0iCYSaRwOEp18dl/Cz9LYUk6MRSyrMBBU=; 7:YqnxTPvkv9XW7uMvfHySbinYhODxtCKfIiOhg+5NB/g1hrRXUFmtEQVTqTlX/TxyS9ycF72hgprmU/YMVN5kB2X6UaKR+xRMNZ2tyAuOiOdZEy9iI+iQ4D/HSuEL+trrusT9JgZeF3j1Z9uCk8r96rk3aYgVwY36t/Z74cOBTiHP1e8kWRkYPbxgiRFUwO1kD6sWHxpxYFoCSkF5UaQFkXPRm5FwPggX6rFoPRjYSUXnukBCrtYJ1H1aD3CoUdTj x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7691ac3c-c609-43f8-6493-08d54143bea9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(48565401081)(2017052603307); SRVR:AM5PR0602MB3250; x-ms-traffictypediagnostic: AM5PR0602MB3250: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(278428928389397)(50582790962513)(128460861657000)(100405760836317)(81160342030619); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231023)(6055026)(6041248)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:AM5PR0602MB3250; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0602MB3250; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(199004)(189003)(252514010)(40134004)(25724002)(24454002)(4326008)(6506006)(14454004)(6246003)(106356001)(76176011)(230783001)(6436002)(99286004)(83716003)(25786009)(105586002)(53936002)(110136005)(86362001)(97736004)(54906003)(6306002)(6486002)(5250100002)(81156014)(2501003)(81166006)(3660700001)(5660300001)(2906002)(3280700002)(66066001)(6512007)(83506002)(58126008)(7736002)(305945005)(68736007)(82746002)(316002)(786003)(59450400001)(53546010)(45080400002)(229853002)(8936002)(2900100001)(478600001)(8676002)(966005)(6116002)(102836003)(36756003)(3846002)(33656002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0602MB3250; H:AM5PR0602MB3251.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <56C97FDC20239143910FACE8A202D6D0@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7691ac3c-c609-43f8-6493-08d54143bea9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 09:35:55.9086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0602MB3250 Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 09:36:04 -0000 SGksDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24uIEFzIHNhaWQgYXQgdGhlIG1lZXRpbmcsIEkg dGhpbmsgaXQgaXMgYWJvdXQgdGltZSB0aGUgSUVURiBzdGFydHMgY29uc2lkZXJpbmcgQVBJcywg b3IgYXQgbGVhc3QgZ2VuZXJhbCBpbnRlcmZhY2VzIChhcyBpdCBpcyBkb2luZyBpbiBvdGhlciBX R3MsIGxpa2UgVEFQUyksIGVzcGVjaWFsbHkgd2hlbiB3ZSB0aGluayBvZiB0aGUgaW5jcmVhc2lu ZyBtb21lbnR1bSBzb2Z0d2FyZS1lbmFibGVkIHNvbHV0aW9ucyBhcmUgZ2FpbmluZy4gQW5kIHRo ZSBjYXNlIG9mIEdSQVNQIGlzIGVzcGVjaWFsbHkgcmVsZXZhbnQgZm9yIHRoaXMsIHNvIHRoZXJl IGlzIGEgY2xlYXIgaW50ZXJmYWNlIGZvciBleHRlbnNpb24gbW9kdWxlcy4gQW5kIHllcywgbGV0 J3MgbWFrZSBpdCBGJkYNCg0KUmVnYXJkaW5nIFRvZXJsZXNzJyBjb21tZW50cywgSSdkIGhhdmUg bm8gcHJvYmxlbSBpbiBsb29raW5nIGZvciBhIHdvcmRpbmcgdGhhdCBiZWNvbWVzIG1vcmUgcGFs YXRhYmxlIHRvIHRoZSBub24tQVBJIHB1cmlzdHMuIFdlIGNvdWxkIGV2ZW4gbWFrZSB0aGlzIGEg Z2VuZXJhbCBhcHByb2FjaCB0byB0aGUgcHJvYmxlbS4uLg0KDQpCZSBnb29kZSwNCg0KLS0NCiJF c3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExv cGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL2RyMmxvcGV6 Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20NClRlbDogICAgICAgICAr MzQgOTEzIDEyOSAwNDENCk1vYmlsZTogICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0K77u/T24gMTIvMTIvMjAxNywgMDk6MzcsICJBbmltYSBvbiBi ZWhhbGYgb2YgVG9lcmxlc3MgRWNrZXJ0IiA8YW5pbWEtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgdHRlQGNzLmZhdS5kZT4gd3JvdGU6DQoNCiAgICArMSBzdXBwb3J0aW5nIGFkb3B0aW9u IG9mIHRoaXMgZG9jdW1lbnQuDQogICAgQWxzbyBpbnRlcmVzdGVkIHRvIGNvbnRyaWJ1dGUgdG8g dGhlIGVmZm9ydC4NCg0KICAgICsxIG9uIE1jci9DYXJzdGVucyBzdWdnZXN0aW9uIHRvIGJlIGZh c3QgJiBmdXJpb3MgKGRvbid0IGRyYWcgdGhpcyBvdXQgZm9yIGxvbmcpLg0KDQogICAgV3J0LiB0 byBBUElzIGFuZCBJRVRGOiBJIGV4cGVjdCB0aGF0IHdlIG1heSBuZWVkIHRvIHJlZmluZSB0ZXJt aW5vbG9neQ0KICAgIHRvIHBhc3MgSUVTRyByZXZpZXcsIHN1Y2ggYXMgbWF5YmUgcmVxdWlyaW5n IHVzIHRvIG1vcmUgb2Z0ZW4gZW1waGFzaXplIGhvdw0KICAgIHRoaXMgaXMgYW4gImFic3RyYWN0 IEFQSSIsIG9yIGRlZmluaXRpb24gb2YgIm5vcnRoYm91bmQgc2VydmljZSBmZWF0dXJlcyINCiAg ICBvciB0aGUgbGlrZSAoZXZlbiBpbiB0aGUgdGl0bGUpLg0KDQogICAgWyBBbnkgdGltZSB3ZSB1 c2UgdGhlIHRlcm0gIkFQSSIgd2l0aG91dCBmdXJ0aGVyDQogICAgYXRyaWJ1dGUsIHRoZXJlIGFy ZSBmb2xrcyB3YW50aW5nIHRvIG1pc2ludGVycHJldCBpdCBhcyBhICJjb25jcmV0ZSBBUEkiDQog ICAgKGZvciAgc3BlY2lmaWMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UpLiBXaGljaCBpcyB3aGF0IHRo ZSBJRVRGIGRvZXMgbm90IGxpa2UNCiAgICAoYW5kIGhhcyBubyByZWFsIGV4cGVydGlzZSBpbiks IGFuZCB3aGljaCB0aGUgZHJhZnQgYWxzbyBub3QgYXR0ZW1wdHMgdG8gc3BlY2lmeS4gXQ0KDQog ICAgQ2hlZXJzDQogICAgICAgIFRvZXJsZXNzDQoNCiAgICBPbiBTYXQsIERlYyAwOSwgMjAxNyBh dCAwNTo1Nzo0OFBNICswMTAwLCBDYXJzdGVuIEJvcm1hbm4gd3JvdGU6DQogICAgPiBPbiBOb3Yg MjksIDIwMTcsIGF0IDEyOjM1LCBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPiB3 cm90ZToNCiAgICA+ID4NCiAgICA+ID4gRHVyaW5nIHRoZSBJRVRGMTAwLCB0aGVyZSB3YXMgYSBj b25zZW5zdXMgdGhhdCBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtYXBpIGlzIGZ1bGx5IGNvbnNpc3Rl bnQgd2l0aCB0aGUgY3VycmVudCBBTklNQSBjaGFydGVyLCB1bmRlciB0aGUgY29uZGl0aW9uIGl0 IGludGVuZHMgdG8gYmUgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudC4gQWZ0ZXIgdGhlIG1lZXRp bmcsIHRoZSBhdXRob3JzIGhhdmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQuIFRoZSBjdXJyZW50IGlu dGVuZGVkIHN0YXR1cyBpcyBJbmZvcm1hdGlvbmFsLiBUaGVyZSB3YXMgYW4gYWRvcHRpb24gY2Fs bCBvbiB0aGlzIGRvY3VtZW50IGFzIGEgQU5JTUEgd29ya2luZyBncm91cCBkb2N1bWVudCBpbiB0 aGUgQU5JTUEgc2Vzc2lvbiwgSUVURjEwMC4gVGhlcmUgd2VyZSBzdXBwb3J0cyBhbmQgbm8gb2Jq ZWN0aW9uIGFzIGZhciBhcyBjaGFpcnMgaGVhcmQuIEFzIGFuIG9mZmljaWFsIHByb2NlZHVyZSwg d2Ugbm93IGNvbmZpcm0gdGhlIGFkb3B0aW9uIGluIHRoZSBBTklNQSBtYWlsaW5nIGxpc3QuDQog ICAgPg0KICAgID4gSSB3YXNuPz8/dCBpbiB0aGUgcm9vbSB3aGVuIHRoaXMgd2FzIGRpc2N1c3Nl ZC4NCiAgICA+DQogICAgPiBJIGJlbGlldmUgaXQgaXMgYSBnb29kIHRoaW5nIHRoYXQgdGhlIElF VEYgaXMgbm90IGluIHRoZSBoYWJpdCBvZiBhdXRvbWF0aWNhbGx5IGNyZWF0aW5nIGFuIEFQSSBm b3IgZWFjaCBwcm90b2NvbCB0aGF0IGl0IGRlZmluZXMgKD8/P0lFVEYgZG9lc24/Pz90IGRvIEFQ SXM/Pz8pLiAgSG93ZXZlciwgdGhlcmUgYXJlIHNwZWNpZmljIHNpdHVhdGlvbnMgd2hlbiBjcmVh dGluZyBBUElzIGlzIHVzZWZ1bDoNCiAgICA+DQogICAgPiA/Pz8gYWRvcHRpb24gb2YgYSBuZXcg dGVjaG5vbG9neSBtYXkgYmVuZWZpdCBmcm9tIGEgY29tbW9uIEFQSSBiZWluZyBhdmFpbGFibGUu ICBFLmcuLCBSRkMgMjI5Mi8zNTQyIGhhcyBoZWxwZWQgSVB2NiBhZG9wdGlvbiBhIGxvdCBieSBt YWtpbmcgYXBwbGljYXRpb25zIHBvc3NpYmxlIHRoYXQgd291bGQgaGF2ZSBoYWQgdG8gdXNlIElQ djQgb3RoZXJ3aXNlLiAgU2ltaWxhciwgUkZDIDY0NTggZm9yIFNDVFAuDQogICAgPiA/Pz8gdGhl IEFQSSBtYXkgY2xhcmlmeSB0aGUgPz8/bm9ydGhib3VuZCBpbnRlcmZhY2U/Pz8gb2YgdGhlIHBy b3RvY29sIGltcGxlbWVudGF0aW9uLiAgU29tZXRpbWVzIGl0IGlzIG5vdCBjbGVhciBmcm9tIGEg cHJvdG9jb2wgd2hhdCB0aGUgYWN0dWFsIG1lYW5pbmcgb2YgcnVubmluZyB0aGUgcHJvdG9jb2wg aXMgc3VwcG9zZWQgdG8gYmUuICBXaGlsZSB3ZSBwcm9iYWJseSBkb24/Pz90IHdhbnQgdG8gYXV0 b21hdGljYWxseSBkZWZpbmUgYSA/Pz9zZXJ2aWNlIGludGVyZmFjZT8/PyBsaWtlIGluIHRoZSBP U0kgbW9kZWwgZm9yIGVhY2ggcHJvdG9jb2wsIGEgbW9yZSBpbm5vdmF0aXZlIHByb3RvY29sIG1h eSBiZSBoYXJkIHRvIHVuZGVyc3RhbmQgd2l0aG91dCB0aGUgaW1hZ2Ugb2Ygc3VjaCBhbiBBUEkg aW4gdGhlIG1pbmQgb2YgdGhlIHJlYWRlci4NCiAgICA+DQogICAgPiBJIGJlbGlldmUgYm90aCBv ZiB0aGVzZSBlZmZlY3RzIGNhbiBiZSBoYWQgaGVyZSwgc28gaXQgaXMgZ29vZCB0aGF0IHRoZSBh dXRob3JzIGhhdmUgd3JpdHRlbiB1cCB0aGUgQVBJLg0KICAgID4NCiAgICA+IEkgYWxzbyBhZ3Jl ZSB0aGF0IHRoZXJlIHNob3VsZCBiZSBhbiBpbnRlbnQgb2YgZmluaXNoaW5nIHRoaXMgcXVpY2ts eSB0byBhaWQgYWRvcHRpb24sIGFuZCBvZiByZXZpc2l0aW5nIHRoZSBBUEkgYWdhaW4gYWZ0ZXIg YSBmZXcgeWVhcnMgb2YgZ2V0dGluZyBleHBlcmllbmNlID8/PyBhZnRlciBhbGwsIHRoaXMgaXMg bm90IGludGVuZGVkIGFzIGEgPz8/U3RhbmRhcmQiLiAgVGhpcyBwcm9iYWJseSBkb2VzIG5vdCBq dXN0aWZ5IGdvaW5nIGZvciA/Pz9FeHBlcmltZW50YWw/Pz86IEZpcnN0LCB0aGlzIGlzbj8/P3Qg cmVhbGx5IGEgcHJvdG9jb2wsIGFuZCBzZWNvbmQsIHRoZXJlIGlzIG5vIGZvcm1hbCBleHBlcmlt ZW50IGJlaW5nIHJ1biBoZXJlIHRoYXQgd2lsbCBiZSBkb25lIGF0IHNvbWUgcG9pbnQ6IFRoaXMg QVBJIGlzIHN1cHBvc2VkIHRvIGxhc3QgdW5sZXNzIHdlIGxlYXJuIHRoYXQgaXQgY2FuIGJlIGlt cHJvdmVkLg0KICAgID4NCiAgICA+IFNvIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoICh3aGF0IEkg dW5kZXJzdGFuZCB3YXMpIHRoZSBpbi1yb29tIGNvbnNlbnN1cyBhdCBJRVRGIDEwMCBhbmQgdGhl IHNlbnRpbWVudHMgdGhhdCB3ZXJlIGV4cHJlc3NlZCBoZXJlLg0KICAgID4NCiAgICA+IEdyw7zD n2UsIENhcnN0ZW4NCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgQW5pbWEgbWFpbGluZyBsaXN0DQogICAgQW5pbWFAaWV0Zi5vcmcNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50 b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29u dGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEg dXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBl cyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1 ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1 dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xh Y2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUg cm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNt YSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlz IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11 bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRl bHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBz ZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlv LCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBl IMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4g U2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Eg bm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBl L291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1 ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3Ig ZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBl c3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= From nobody Tue Dec 12 08:03:27 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8381294A8; Tue, 12 Dec 2017 08:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqS8rIfMCy97; Tue, 12 Dec 2017 08:03:18 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0098.outbound.protection.outlook.com [104.47.0.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF5B127078; Tue, 12 Dec 2017 08:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IR9SeyelToqr8tc3Gze4Okce7cHUK8uPXX3NeIDcJSo=; b=dTX1AkYPkku3oFSJLKYBGxUrHRMdtNOgORR3YMTFG4pg3S1mqh7cDdqC5PA2+gBL66OYu3VKvEhc2fVy5TBdo21gd5c+yavTyvDQPgmBbR/2LMRM9Jw0uqbpAFsupZsd/ekIYceyvIhP3yR7w3VXt2NzBrrM/Plk0g9E9rJrO7w= Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com (10.168.36.134) by HE1PR0701MB2202.eurprd07.prod.outlook.com (10.168.36.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Tue, 12 Dec 2017 16:03:14 +0000 Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::e4ad:9659:31f:658f]) by HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::e4ad:9659:31f:658f%15]) with mapi id 15.20.0323.011; Tue, 12 Dec 2017 16:03:14 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: "Diego R. Lopez" , Toerless Eckert , Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" , Carsten Bormann Thread-Topic: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 Thread-Index: AdNpBcnuhzuf3eYUTIigJEFJrvIuMAICQ1kAAIVghQAAAhCMgAANbo0A Date: Tue, 12 Dec 2017 16:03:13 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com> <20171212083648.GA4071@faui40p.informatik.uni-erlangen.de> <8A72C264-180E-425A-8B86-CC8DF6E96F69@telefonica.com> In-Reply-To: <8A72C264-180E-425A-8B86-CC8DF6E96F69@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia-bell-labs.com; x-originating-ip: [135.245.212.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2202; 6:D+7tdLY6jgJMJ7iDFWZpIO1onUKYTD5dVvZy645CnZ7B1CoMDFen8bqQX6vi6NguKPHGh1PTATMxofvJfqXkh3odIGMB7A5DyaTGuyyfuNByzqFG9EvVuc/SH55ROcF4ecRqiRmWRBOM97wiSP4ZOEeZb0mrVEW71+gvu5yeipE/ly8rLw77SvKPYC8o6Msfwc7NTMiHE0acWvW7G9VKK3+wVKFGx5XA52gMKJ9gy61RoLIU5IOAXwTMnJCUJGEfosboEkRU4R0HzeDxlTqEomTqi6CNAxodd2uu5iMZqZ6GPPPAt23z4pACCEPXIL4ArQIA8rA8dtuuKWOaCWhs3RG0fC8B8jzi+FvxIFwWNZM=; 5:O4f5DHoH5T5gA7PlOJFDMRbrZJRdBAEs99MrC2tnSY8KFozQNSMbitPX3m2DhoeJqUbgnwZVe4hnwC4dkyLTy4N/B2ruILkNZZh2bXAYR/fdoloyBFMKdR3WTaLU87979xMpEKkTL++pI5ykw/voVXRstbdDTzuMghzmkwoXb6s=; 24:S86tGO6teZuogCXHuhSiyh6yaMgMMEgdCUJ68MJ4PoRXVT2RFfFMAQ7F9ccfPD0cMmFn7EqMCVSco/kEqjNeW4S61JQbbMFzc0JZ2n2cgMI=; 7:BNwT5YVromr09KEt9hLnkQKzYcfndn2+OfyrbJp/QGkMTEHbQ14ExZtSSb6Nvx6dMOXzLPvI6l4pIjQ3PidERe8hJVPfe16O9FmNGPUKAUNT/kABGFpiM16iRGyKghPZ04O2ea8CgjrEhGUai7jH0OW9HgkX+/0dMmlgqUngEhabu/PscJKVHVQRdSnq1enBAbeIXlj29C2Bq1Y+wTPxEAc92wLaiS+j02yoAqOkoaWjCrL9NbLO9h4CPX1bA1kK x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 03937352-0d70-440c-73c6-08d54179d994 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(48565401081)(2017052603307); SRVR:HE1PR0701MB2202; x-ms-traffictypediagnostic: HE1PR0701MB2202: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(278428928389397)(50582790962513)(128460861657000)(100405760836317)(81160342030619); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(11241501184)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:HE1PR0701MB2202; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2202; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(24454002)(252514010)(40134004)(25724002)(13464003)(199004)(189003)(81156014)(5250100002)(6246003)(6116002)(102836003)(76176011)(81166006)(3846002)(8676002)(6436002)(33656002)(45080400002)(110136005)(54906003)(316002)(478600001)(6506006)(53936002)(97736004)(74316002)(2900100001)(68736007)(229853002)(2950100002)(5660300001)(7696005)(59450400001)(7736002)(2906002)(305945005)(8936002)(230783001)(14454004)(93886005)(966005)(6306002)(55016002)(9686003)(4326008)(105586002)(3660700001)(53546010)(106356001)(25786009)(2501003)(3280700002)(86362001)(99286004)(66066001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2202; H:HE1PR0701MB2203.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03937352-0d70-440c-73c6-08d54179d994 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 16:03:13.8620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2202 Archived-At: Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 16:03:26 -0000 SGVsbG8sDQoNCkkgdGhpbmsgdGhpcyB3b3JrIGlzIG9mIGludGVyZXN0IGFuZCBzaG91bGQgY29u dGludWUsIGVpdGhlciBhcyBhbiBpbmRpdmlkdWFsIG9yIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQu DQoNCkxhdXJlbnQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbmltYSBb bWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaWVnbyBSLiBMb3Bl eg0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTIsIDIwMTcgMTA6MzYgQU0NClRvOiBUb2VybGVz cyBFY2tlcnQgPHR0ZUBjcy5mYXUuZGU+OyBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWku Y29tPjsgYW5pbWFAaWV0Zi5vcmcNCkNjOiBhbmltYS1jaGFpcnNAaWV0Zi5vcmc7IENhcnN0ZW4g Qm9ybWFubiA8Y2Fib0B0emkub3JnPg0KU3ViamVjdDogUmU6IFtBbmltYV0gQWRvcHRpb24gY2Fs bCBmb3IgZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS0wNiwgZW5kcyBEZWMuIDEyLCAyMDE3DQoN CkhpLA0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uLiBBcyBzYWlkIGF0IHRoZSBtZWV0aW5nLCBJ IHRoaW5rIGl0IGlzIGFib3V0IHRpbWUgdGhlIElFVEYgc3RhcnRzIGNvbnNpZGVyaW5nIEFQSXMs IG9yIGF0IGxlYXN0IGdlbmVyYWwgaW50ZXJmYWNlcyAoYXMgaXQgaXMgZG9pbmcgaW4gb3RoZXIg V0dzLCBsaWtlIFRBUFMpLCBlc3BlY2lhbGx5IHdoZW4gd2UgdGhpbmsgb2YgdGhlIGluY3JlYXNp bmcgbW9tZW50dW0gc29mdHdhcmUtZW5hYmxlZCBzb2x1dGlvbnMgYXJlIGdhaW5pbmcuIEFuZCB0 aGUgY2FzZSBvZiBHUkFTUCBpcyBlc3BlY2lhbGx5IHJlbGV2YW50IGZvciB0aGlzLCBzbyB0aGVy ZSBpcyBhIGNsZWFyIGludGVyZmFjZSBmb3IgZXh0ZW5zaW9uIG1vZHVsZXMuIEFuZCB5ZXMsIGxl dCdzIG1ha2UgaXQgRiZGDQoNClJlZ2FyZGluZyBUb2VybGVzcycgY29tbWVudHMsIEknZCBoYXZl IG5vIHByb2JsZW0gaW4gbG9va2luZyBmb3IgYSB3b3JkaW5nIHRoYXQgYmVjb21lcyBtb3JlIHBh bGF0YWJsZSB0byB0aGUgbm9uLUFQSSBwdXJpc3RzLiBXZSBjb3VsZCBldmVuIG1ha2UgdGhpcyBh IGdlbmVyYWwgYXBwcm9hY2ggdG8gdGhlIHByb2JsZW0uLi4NCg0KQmUgZ29vZGUsDQoNCi0tDQoi RXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBM b3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9kcjJsb3Bl ei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tDQpUZWw6ICAgICAgICAg KzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCu+7v09uIDEyLzEyLzIwMTcsIDA5OjM3LCAiQW5pbWEgb24g YmVoYWxmIG9mIFRvZXJsZXNzIEVja2VydCIgPGFuaW1hLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIHR0ZUBjcy5mYXUuZGU+IHdyb3RlOg0KDQogICAgKzEgc3VwcG9ydGluZyBhZG9wdGlv biBvZiB0aGlzIGRvY3VtZW50Lg0KICAgIEFsc28gaW50ZXJlc3RlZCB0byBjb250cmlidXRlIHRv IHRoZSBlZmZvcnQuDQoNCiAgICArMSBvbiBNY3IvQ2Fyc3RlbnMgc3VnZ2VzdGlvbiB0byBiZSBm YXN0ICYgZnVyaW9zIChkb24ndCBkcmFnIHRoaXMgb3V0IGZvciBsb25nKS4NCg0KICAgIFdydC4g dG8gQVBJcyBhbmQgSUVURjogSSBleHBlY3QgdGhhdCB3ZSBtYXkgbmVlZCB0byByZWZpbmUgdGVy bWlub2xvZ3kNCiAgICB0byBwYXNzIElFU0cgcmV2aWV3LCBzdWNoIGFzIG1heWJlIHJlcXVpcmlu ZyB1cyB0byBtb3JlIG9mdGVuIGVtcGhhc2l6ZSBob3cNCiAgICB0aGlzIGlzIGFuICJhYnN0cmFj dCBBUEkiLCBvciBkZWZpbml0aW9uIG9mICJub3J0aGJvdW5kIHNlcnZpY2UgZmVhdHVyZXMiDQog ICAgb3IgdGhlIGxpa2UgKGV2ZW4gaW4gdGhlIHRpdGxlKS4NCg0KICAgIFsgQW55IHRpbWUgd2Ug dXNlIHRoZSB0ZXJtICJBUEkiIHdpdGhvdXQgZnVydGhlcg0KICAgIGF0cmlidXRlLCB0aGVyZSBh cmUgZm9sa3Mgd2FudGluZyB0byBtaXNpbnRlcnByZXQgaXQgYXMgYSAiY29uY3JldGUgQVBJIg0K ICAgIChmb3IgIHNwZWNpZmljIHByb2dyYW1taW5nIGxhbmd1YWdlKS4gV2hpY2ggaXMgd2hhdCB0 aGUgSUVURiBkb2VzIG5vdCBsaWtlDQogICAgKGFuZCBoYXMgbm8gcmVhbCBleHBlcnRpc2UgaW4p LCBhbmQgd2hpY2ggdGhlIGRyYWZ0IGFsc28gbm90IGF0dGVtcHRzIHRvIHNwZWNpZnkuIF0NCg0K ICAgIENoZWVycw0KICAgICAgICBUb2VybGVzcw0KDQogICAgT24gU2F0LCBEZWMgMDksIDIwMTcg YXQgMDU6NTc6NDhQTSArMDEwMCwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KICAgID4gT24gTm92 IDI5LCAyMDE3LCBhdCAxMjozNSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbT4g d3JvdGU6DQogICAgPiA+DQogICAgPiA+IER1cmluZyB0aGUgSUVURjEwMCwgdGhlcmUgd2FzIGEg Y29uc2Vuc3VzIHRoYXQgZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaSBpcyBmdWxseSBjb25zaXN0 ZW50IHdpdGggdGhlIGN1cnJlbnQgQU5JTUEgY2hhcnRlciwgdW5kZXIgdGhlIGNvbmRpdGlvbiBp dCBpbnRlbmRzIHRvIGJlIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQuIEFmdGVyIHRoZSBtZWV0 aW5nLCB0aGUgYXV0aG9ycyBoYXZlIHVwZGF0ZWQgdGhlIGRvY3VtZW50LiBUaGUgY3VycmVudCBp bnRlbmRlZCBzdGF0dXMgaXMgSW5mb3JtYXRpb25hbC4gVGhlcmUgd2FzIGFuIGFkb3B0aW9uIGNh bGwgb24gdGhpcyBkb2N1bWVudCBhcyBhIEFOSU1BIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgaW4g dGhlIEFOSU1BIHNlc3Npb24sIElFVEYxMDAuIFRoZXJlIHdlcmUgc3VwcG9ydHMgYW5kIG5vIG9i amVjdGlvbiBhcyBmYXIgYXMgY2hhaXJzIGhlYXJkLiBBcyBhbiBvZmZpY2lhbCBwcm9jZWR1cmUs IHdlIG5vdyBjb25maXJtIHRoZSBhZG9wdGlvbiBpbiB0aGUgQU5JTUEgbWFpbGluZyBsaXN0Lg0K ICAgID4NCiAgICA+IEkgd2Fzbj8/P3QgaW4gdGhlIHJvb20gd2hlbiB0aGlzIHdhcyBkaXNjdXNz ZWQuDQogICAgPg0KICAgID4gSSBiZWxpZXZlIGl0IGlzIGEgZ29vZCB0aGluZyB0aGF0IHRoZSBJ RVRGIGlzIG5vdCBpbiB0aGUgaGFiaXQgb2YgYXV0b21hdGljYWxseSBjcmVhdGluZyBhbiBBUEkg Zm9yIGVhY2ggcHJvdG9jb2wgdGhhdCBpdCBkZWZpbmVzICg/Pz9JRVRGIGRvZXNuPz8/dCBkbyBB UElzPz8/KS4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBzcGVjaWZpYyBzaXR1YXRpb25zIHdoZW4gY3Jl YXRpbmcgQVBJcyBpcyB1c2VmdWw6DQogICAgPg0KICAgID4gPz8/IGFkb3B0aW9uIG9mIGEgbmV3 IHRlY2hub2xvZ3kgbWF5IGJlbmVmaXQgZnJvbSBhIGNvbW1vbiBBUEkgYmVpbmcgYXZhaWxhYmxl LiAgRS5nLiwgUkZDIDIyOTIvMzU0MiBoYXMgaGVscGVkIElQdjYgYWRvcHRpb24gYSBsb3QgYnkg bWFraW5nIGFwcGxpY2F0aW9ucyBwb3NzaWJsZSB0aGF0IHdvdWxkIGhhdmUgaGFkIHRvIHVzZSBJ UHY0IG90aGVyd2lzZS4gIFNpbWlsYXIsIFJGQyA2NDU4IGZvciBTQ1RQLg0KICAgID4gPz8/IHRo ZSBBUEkgbWF5IGNsYXJpZnkgdGhlID8/P25vcnRoYm91bmQgaW50ZXJmYWNlPz8/IG9mIHRoZSBw cm90b2NvbCBpbXBsZW1lbnRhdGlvbi4gIFNvbWV0aW1lcyBpdCBpcyBub3QgY2xlYXIgZnJvbSBh IHByb3RvY29sIHdoYXQgdGhlIGFjdHVhbCBtZWFuaW5nIG9mIHJ1bm5pbmcgdGhlIHByb3RvY29s IGlzIHN1cHBvc2VkIHRvIGJlLiAgV2hpbGUgd2UgcHJvYmFibHkgZG9uPz8/dCB3YW50IHRvIGF1 dG9tYXRpY2FsbHkgZGVmaW5lIGEgPz8/c2VydmljZSBpbnRlcmZhY2U/Pz8gbGlrZSBpbiB0aGUg T1NJIG1vZGVsIGZvciBlYWNoIHByb3RvY29sLCBhIG1vcmUgaW5ub3ZhdGl2ZSBwcm90b2NvbCBt YXkgYmUgaGFyZCB0byB1bmRlcnN0YW5kIHdpdGhvdXQgdGhlIGltYWdlIG9mIHN1Y2ggYW4gQVBJ IGluIHRoZSBtaW5kIG9mIHRoZSByZWFkZXIuDQogICAgPg0KICAgID4gSSBiZWxpZXZlIGJvdGgg b2YgdGhlc2UgZWZmZWN0cyBjYW4gYmUgaGFkIGhlcmUsIHNvIGl0IGlzIGdvb2QgdGhhdCB0aGUg YXV0aG9ycyBoYXZlIHdyaXR0ZW4gdXAgdGhlIEFQSS4NCiAgICA+DQogICAgPiBJIGFsc28gYWdy ZWUgdGhhdCB0aGVyZSBzaG91bGQgYmUgYW4gaW50ZW50IG9mIGZpbmlzaGluZyB0aGlzIHF1aWNr bHkgdG8gYWlkIGFkb3B0aW9uLCBhbmQgb2YgcmV2aXNpdGluZyB0aGUgQVBJIGFnYWluIGFmdGVy IGEgZmV3IHllYXJzIG9mIGdldHRpbmcgZXhwZXJpZW5jZSA/Pz8gYWZ0ZXIgYWxsLCB0aGlzIGlz IG5vdCBpbnRlbmRlZCBhcyBhID8/P1N0YW5kYXJkIi4gIFRoaXMgcHJvYmFibHkgZG9lcyBub3Qg anVzdGlmeSBnb2luZyBmb3IgPz8/RXhwZXJpbWVudGFsPz8/OiBGaXJzdCwgdGhpcyBpc24/Pz90 IHJlYWxseSBhIHByb3RvY29sLCBhbmQgc2Vjb25kLCB0aGVyZSBpcyBubyBmb3JtYWwgZXhwZXJp bWVudCBiZWluZyBydW4gaGVyZSB0aGF0IHdpbGwgYmUgZG9uZSBhdCBzb21lIHBvaW50OiBUaGlz IEFQSSBpcyBzdXBwb3NlZCB0byBsYXN0IHVubGVzcyB3ZSBsZWFybiB0aGF0IGl0IGNhbiBiZSBp bXByb3ZlZC4NCiAgICA+DQogICAgPiBTbyBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCAod2hhdCBJ IHVuZGVyc3RhbmQgd2FzKSB0aGUgaW4tcm9vbSBjb25zZW5zdXMgYXQgSUVURiAxMDAgYW5kIHRo ZSBzZW50aW1lbnRzIHRoYXQgd2VyZSBleHByZXNzZWQgaGVyZS4NCiAgICA+DQogICAgPiBHcsO8 w59lLCBDYXJzdGVuDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIEFuaW1hIG1haWxpbmcgbGlzdA0KICAgIEFuaW1hQGlldGYub3JnDQog ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVu dG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNv bnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJh IHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8g ZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBx dWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBh dXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNs YWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxl IHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlz bWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBp cyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhh dCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21t dW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0 ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUg c2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJp bywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwg ZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8u IFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNh IG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28g ZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0 dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9y IGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3Ig ZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8OjbyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0DQpB bmltYUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmlt YQ0K From nobody Tue Dec 12 13:38:24 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7F129577; Tue, 12 Dec 2017 13:38:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: draft-ietf-anima-voucher.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151311469282.14196.13351180696847859225@ietfa.amsl.com> Date: Tue, 12 Dec 2017 13:38:12 -0800 Archived-At: Subject: [Anima] Opsdir telechat review of draft-ietf-anima-voucher-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: Tue, 12 Dec 2017 21:38:13 -0000 Reviewer: Joe Clarke Review result: Has Nits I have been assigned draft-ietf-anima-voucher to review for the ops directorate. I have read over -06, and I feel that this document is ready. My comments from -05 have been discussed and addressed. There were a couple of nits I have in -06, however. Please find them below: Section 2: Old Text: The MAS concept is explained in more detail in... New Text: The MASA concept is explained in more detail in... (Note: MAS => MASA) Old Text: Registrar See Join Registrar New Text: Registrar: See Join Registrar (Note: colon added) From nobody Tue Dec 12 14:26:39 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88777129571; Tue, 12 Dec 2017 14:26:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-anima-voucher@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151311758355.30209.8632916184450950592.idtracker@ietfa.amsl.com> Date: Tue, 12 Dec 2017 14:26:23 -0800 Archived-At: Subject: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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: Tue, 12 Dec 2017 22:26:23 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-anima-voucher-06: 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-voucher/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The document is generally fine, but first references to CN-ID and DNS-ID need a reference to RFC 6125, as these terms are not defined anywhere in the document. X.690 also needs a reference. Nit In 7.1, first sentence: has no understand ==> has no understanding From nobody Wed Dec 13 07:48:06 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A5312422F for ; Wed, 13 Dec 2017 07:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zec9bYuCAyXh for ; Wed, 13 Dec 2017 07:48:02 -0800 (PST) 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 9A47C12009C for ; Wed, 13 Dec 2017 07:48:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E87C820090 for ; Wed, 13 Dec 2017 10:51:19 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3E906814AD for ; Wed, 13 Dec 2017 10:48:01 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Question on draft-ietf-anima-voucher-06 (fwd) Michael Richardson: Re: Question on draft-ietf-anima-voucher-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: Wed, 13 Dec 2017 15:48:05 -0000 --===-=-= Content-Type: multipart/mixed; boundary="==-=-=" --==-=-= Content-Type: text/plain Forwarded with permission. --==-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=156 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.26) for (single-drop); Wed, 13 Dec 2017 10:14:01 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus git2.4.17+0-Debian-2.4.17+nocaldav-0+deb8u2) with LMTPA; Wed, 13 Dec 2017 10:16:50 -0500 X-Sieve: CMU Sieve 2.4 Received: from colo19.roaringpenguin.com (unknown [IPv6:2604:1f80:1:478::19]) by tuna.sandelman.ca (Postfix) with ESMTPS id ECC2720090 for ; Wed, 13 Dec 2017 10:16:49 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by colo19.roaringpenguin.com (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vBDFDRDN021796 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 13 Dec 2017 10:13:28 -0500 Received: by ietfa.amsl.com (Postfix, from userid 65534) id 613A7127869; Wed, 13 Dec 2017 07:13:27 -0800 (PST) X-Original-To: xfilter-draft-ietf-anima-voucher@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-anima-voucher@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD461288B8 for ; Wed, 13 Dec 2017 07:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: undef - 4.31.198.44 is allowed always. X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WEGSkLn80Aj for ; Wed, 13 Dec 2017 07:13:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6449F127869 for ; Wed, 13 Dec 2017 07:13:17 -0800 (PST) Received: from tuna.sandelman.ca ([209.87.249.19]:48615 ident=postfix) by zinfandel.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eP8ii-0000YX-0d for draft-ietf-anima-voucher@tools.ietf.org; Wed, 13 Dec 2017 07:13:17 -0800 Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E13FE20090; Wed, 13 Dec 2017 10:16:23 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 430F0814AD; Wed, 13 Dec 2017 10:13:05 -0500 (EST) From: Michael Richardson To: Eric Rescorla cc: draft-ietf-anima-voucher@tools.ietf.org, IESG In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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 X-SA-Exim-Connect-IP: 209.87.249.19 X-SA-Exim-Rcpt-To: draft-ietf-anima-voucher@tools.ietf.org X-SA-Exim-Mail-From: mcr+ietf@sandelman.ca Subject: Re: Question on draft-ietf-anima-voucher-06 X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Resent-From: Resent-To: kwatsen@juniper.net, mcr+ietf@sandelman.ca, pritikin@cisco.com, tte+ietf@cs.fau.de Resent-To: draft-ietf-anima-voucher@ietf.org List-ID: Resent-Message-Id: <20171213151317.6449F127869@ietfa.amsl.com> Resent-Date: Wed, 13 Dec 2017 07:13:17 -0800 (PST) Resent-From: mcr+ietf@sandelman.ca X-CanIt-Geo: ip=4.31.198.44; country=US; latitude=37.7510; longitude=-97.8220; http://maps.google.com/maps?q=37.7510,-97.8220&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-01:default,base:default) X-Canit-Stats-ID: 0gUJrds8g - 0bcd9ed9e188 - 20171213 X-Antispam-Training-Forget: https://emailfilteringservice.net/canit/b.php?c=f&i=0gUJrds8g&m=0bcd9ed9e188&rlm=sandelman-ca&t=20171213 X-Antispam-Training-Nonspam: https://emailfilteringservice.net/canit/b.php?c=n&i=0gUJrds8g&m=0bcd9ed9e188&rlm=sandelman-ca&t=20171213 X-Antispam-Training-Phish: https://emailfilteringservice.net/canit/b.php?c=p&i=0gUJrds8g&m=0bcd9ed9e188&rlm=sandelman-ca&t=20171213 X-Antispam-Training-Spam: https://emailfilteringservice.net/canit/b.php?c=s&i=0gUJrds8g&m=0bcd9ed9e188&rlm=sandelman-ca&t=20171213 X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg Received-SPF: softfail (colo19.roaringpenguin.com: domain of mcr+ietf@sandelman.ca does not designate 4.31.198.44 as permitted sender) receiver=colo19.roaringpenguin.com; client-ip=4.31.198.44; envelope-from=; helo=mail.ietf.org; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) --=-=-= Content-Type: text/plain Let me answer this in two emails, because I want to make sure that we are on the same page before continuing. I also want to note that some of these remarks are specific to how BRSKI uses audit-vouchers. There are other uses of vouchers (including NETCONF), and some of them do not need audit-vouchers or would accept audit-vouchers. Eric Rescorla wrote: draft> Audit Voucher: An Audit Voucher is named after the logging draft> assertion mechanisms that the Registrar then "audits" to enforce draft> local policy. The Registrar mitigates a MiTM Registrar by auditing draft> that an unknown MiTM registrar does not appear in the log draft> entries. This does not directly prevent the MiTM but provides a draft> response mechanism that ensures the MiTM is unsuccessful. This draft> advantage is that actual ownership knowledge is not required on draft> the MASA service. > Can you walk me through the attack in question and how > auditing/logging > detects it, because I'm really not following from this document. > I'm > sure I'll have more questions later but I think I need to > understand > this one first. You will recall the light-bulb attack you postulated at the 2012 IoT Security Workshop. The threat was that an attacker that could control millions of smart light bulbs, would be able to turn them all on and off at the same time, causing stress and possibly damage to the electrical grid. The postulated situation was that attacker wanders through DIY store (Home Depot, etc.) or better yet, works there. They remove light bulbs from packages (carefully), go through the official imprint situation and then as the official owner, replace the firmware with one that they have control over, and then they "factory" reset the device (and put it back in the package) such that the end purchaser is unaware that the firmware is trojan'ed. For the purposes of this discussion, let's assume that the IDevID certificate and private key is secure in a tamper-proof TPM. I'll stop here because I want to make sure that we agree on the attack. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloxQ38ACgkQgItw+93Q 3WVlwwf+PK1tn/Eo53FJt6leeG0t7PYqXmDabhNKh1anrVjzvcNBAAZB/ffXW4u8 k1N2E/iHXLDsqvGEa8XMN5LppclBl+FbOq0sWtv7vVtRbjYuRyEd5hT6gQdlyIPo T1Zs7HG9vIzuQKfZzIED9VLtON5GZLkvOixIeLVNCZA8oVbWI/t3/ER7M+7tQjEw 4cw9uIVCMj1Dq802zkNGn04D6wpvpWeZR8HI8q8zA6EvuRQc8ckD1QOsYbi1KE2/ XjLnLMOgKxfUFp3wUFkJCBAYGOA5OinaynICAZJtVHA4Juz3fYhwAuz9tVz+ja1t 65tBmOzTastQmdQtxKvh8NwhumGcZA== =RLTi -----END PGP SIGNATURE----- --=-=-=-- --==-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --==-=-=-- --===-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloxS7AACgkQgItw+93Q 3WWyMAgAuLaVp44tulBcUQM2G88RD9LWKv4Vp52XvaQ9YF4hLan0FzpNrHpUm2km Y1KdeDdLNZqa1qmJCMMEQ76BMa0iRQqb2WIUjpyDeGrhU4c4UnSja41iHGs+4xF6 JnLAXqH8aXNp0AkHrs6Li6tG+vPJ0Im07B67Zg09bcqTZFa6EAMDaT5iWvOewzg8 e3lTBXpKzXjBIdyKoptlK8nt+H6Z/Imm0Z/n7odphgNaHopq36V9oh7I23se87nR eVtOiIyHmdOLnbQbm03TLQHFBgqqkQ8lXZ/kiMpQ9uS/8qtjV6NDgXiKp8h2SlMB jX+zqGSaRLRqF+zI7vaVr6T1SjsmJg== =gVvL -----END PGP SIGNATURE----- --===-=-=-- From nobody Wed Dec 13 09:01:08 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9839B1270B4; Wed, 13 Dec 2017 09:01:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-anima-voucher@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151318446761.30150.6931236674223703279.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 09:01:07 -0800 Archived-At: Subject: [Anima] Kathleen Moriarty's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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, 13 Dec 2017 17:01:07 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-anima-voucher-06: 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-voucher/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing Russ' Gen Art comments. With that, I'm wondering if a recommended signature algorithm should be specified. This change had the work go from just supporting RSA to including other (and better) choices. Thanks, Kathleen From nobody Wed Dec 13 11:53:27 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813A6126FDC; Wed, 13 Dec 2017 11:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZGKigYk-RCNP; Wed, 13 Dec 2017 11:53:20 -0800 (PST) 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 D8AD7128CF0; Wed, 13 Dec 2017 11:53:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F17D20090; Wed, 13 Dec 2017 14:56:25 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E6057814AD; Wed, 13 Dec 2017 14:53:05 -0500 (EST) From: Michael Richardson To: Kathleen Moriarty cc: "The IESG" , anima-chairs@ietf.org, draft-ietf-anima-voucher@ietf.org, anima@ietf.org, jiangsheng@huawei.com In-Reply-To: <151318446761.30150.6931236674223703279.idtracker@ietfa.amsl.com> References: <151318446761.30150.6931236674223703279.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Kathleen Moriarty's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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, 13 Dec 2017 19:53:26 -0000 --=-=-= Content-Type: text/plain Kathleen Moriarty wrote: > Thank you for addressing Russ' Gen Art comments. With that, I'm wondering if a > recommended signature algorithm should be specified. This change had the work > go from just supporting RSA to including other (and better) choices. I don't think we should recommend anything, or really need to. There is only a small interoperability issue with algorithm selection here. The manufacturer (in the form of the MASA) must generate a signature that their product (the pledge) is able to verify. So the selection of signature algorithm is essentially driven by the capabilities of the pledge. The manufacturer knows what that is, and so can select appropriately. There are tradeoffs of bandwidth, power consumption, code size, and longevity of algorithm, and I think that specific recommendations should be left to those closer to the specific kind of deployment. A choice for a home NAS device intended to be sold immediately and deployed (with a ~5 year lifespan) might have significant differences than for a 50-port 10GE switch to be deployed in a secured data center after being warehoused for 10 years as a spare. The voucher contains a pointer to the owner (the Registrar) within it, and I think that algorithm will be subject to a different set of constraints. The intermediate system (JRC, or Registrar) is given the opportunity to audit the resulting voucher. As such, it needs to be able to verify the voucher, and it is here that we have some interoperability issue if the manufacturer picks an unusual algorithm. The Registrar could deny the new device, consult with a human for an exception, or something more complex. Finally an additional constraint is that the MASA's signing infrastructure may need to have the private key available, and so some kind of HSM might be appropriate, and those do not unfortunately track the bleeding edge of cryptography. Personally, I'd like to recommend edwards25519 (RFC8032), but tooling is not up to that today. That leaves one debating between size of RSA >2048bit, vs security of secp256k1... depending upon code space and hardware acceleration available in target device. One would want to pick the same algorithm as for SUIT and other stuff. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloxhSEACgkQgItw+93Q 3WVYHgf/QyJT1NVe1l/7waJrRY5hZlM9Lyz/xim3BJkFa6XXeobEd+n7x9uGhTcc HotmYTJc9N0ywDnwnB9crhPEzWvp093gbKVfZ0Ovb4HZlQr+PaBrlO9wE0xl+f7m b2GR3/q6tRgrObwx80uG1V4drlDv7pS2CkaaBcAxuAAoW8HQQyliP7zyr8pez43c lHHqM8EE9dk2HsS3G1u1ycAAJPTd6ajL7worFpNnLc65uSoE3KyWzB7fildmN4ah PbpnKv4nU8RlT8CsWGsrIH37lePrYqXi/6at+Bo5EqUnqkz/vfg+Bklw6sTJxpzi mkX6+j9PLXz4eVlJ84HJhinKmPwBjg== =ism0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 13 12:13:18 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B40128768 for ; Wed, 13 Dec 2017 12:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 b2_nVoaDWbu5 for ; Wed, 13 Dec 2017 12:13:11 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 4AC7912878D for ; Wed, 13 Dec 2017 12:13:09 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id x83so1759836ybg.8 for ; Wed, 13 Dec 2017 12:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7nxSJrE3O8UFx83SaKmF/F9L2tF5vKJBsbK8vpQKVWg=; b=f09koPQKqs8vWZhh8kAGabddlMSvpp1dojthLFHPK5dH2hbtGeakgjKCP7UKIB6OpE lz1OqVaxucNX4GmS5r9O8gjNH3bnaLCEK42tj40oLLGRCZuydYALmiOYrjF8rcU/IH8l XEsQFL3YuVcJEw720k9t0aQjDGD5euNLnWxSeYkgPvFn/5ylJyYGkjkxCIlTq6b0T5aM nvEf+mRDyporXe3BbyZDhC/EFnmfF4L+HLt92mOR6XBIjYxz3ifRX8hdPYvuJWYKdg/f +b6Z+YqaGOMXuZyRY2PMeRxPgYum+IqU5gV5bgtARyDbKjE/b0uVHhOS4BUt5cZ2utir fvvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7nxSJrE3O8UFx83SaKmF/F9L2tF5vKJBsbK8vpQKVWg=; b=WVssCA9ntyrJMgUKfxMZNT8UMAgdkmXVN1JlpPn2m2KcXhLxr198C/fQl3rkWNbVhp 8mMlmEODm+QenldRk+RtCEC/9y1sy+y2O86btv+O/l2xvNHKOyFhJrrgkNzpLcffV38V 7NcbzAz5rQXAX4C4fWtBG+IkHSUPwi3O3MINaJ2VBlgugt8iplGYhb55b/I45iJLr7nj n71rd6jzNy2c0DkU9sFr8qxN8ShKQ3Kt0bZ6/zx6ODUELB9kppTcrzdrQB0wEqAG82bL Ff86iVZbUdTghzACat2Cd5m45fsnHGqXDcPZ5piIfEwuzbuHOgyBd4ZeXzsze0uEFHEL LNbA== X-Gm-Message-State: AKGB3mLLml1fO9lUjO4nTFCNHBWABhdvjd6k4fNUDwoVM3r++Ba6wIC1 CM1km6CFBL4izPH5252NcNEFoKgBertJwH8djHxq9Q== X-Google-Smtp-Source: ACJfBos5MGP7JUNg53RWba3zPX3pP8T1ppNdU17qAblFbttfrAUYzukU984EJ5HDVWnxD4imhElL+2YR1HkDYUY4M5k= X-Received: by 10.129.222.9 with SMTP id k9mr2722807ywj.47.1513195988413; Wed, 13 Dec 2017 12:13:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 13 Dec 2017 12:12:27 -0800 (PST) In-Reply-To: <8119.1513194785@obiwan.sandelman.ca> References: <151318446761.30150.6931236674223703279.idtracker@ietfa.amsl.com> <8119.1513194785@obiwan.sandelman.ca> From: Eric Rescorla Date: Wed, 13 Dec 2017 12:12:27 -0800 Message-ID: To: Michael Richardson Cc: Kathleen Moriarty , anima-chairs@ietf.org, draft-ietf-anima-voucher@ietf.org, The IESG , Anima WG , Sheng Jiang Content-Type: multipart/alternative; boundary="f403043d04885d893305603e65fa" Archived-At: Subject: Re: [Anima] Kathleen Moriarty's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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, 13 Dec 2017 20:13:13 -0000 --f403043d04885d893305603e65fa Content-Type: text/plain; charset="UTF-8" On Wed, Dec 13, 2017 at 11:53 AM, Michael Richardson wrote: > > Kathleen Moriarty wrote: > > Thank you for addressing Russ' Gen Art comments. With that, I'm > wondering if a > > recommended signature algorithm should be specified. This change > had the work > > go from just supporting RSA to including other (and better) choices. > > I don't think we should recommend anything, or really need to. > There is only a small interoperability issue with algorithm selection here. > > The manufacturer (in the form of the MASA) must generate a signature that > their product (the pledge) is able to verify. > > So the selection of signature algorithm is essentially driven by the > capabilities of the pledge. The manufacturer knows what that is, and so > can > select appropriately. > > There are tradeoffs of bandwidth, power consumption, code size, and > longevity > of algorithm, and I think that specific recommendations should be left to > those closer to the specific kind of deployment. A choice for a home NAS > device intended to be sold immediately and deployed (with a ~5 year > lifespan) > might have significant differences than for a 50-port 10GE switch to be > deployed in a secured data center after being warehoused for 10 years as a > spare. > > The voucher contains a pointer to the owner (the Registrar) within it, and > I > think that algorithm will be subject to a different set of constraints. > > The intermediate system (JRC, or Registrar) is given the opportunity to > audit > the resulting voucher. As such, it needs to be able to verify the voucher, > and it is here that we have some interoperability issue if the manufacturer > picks an unusual algorithm. The Registrar could deny the new device, > consult with a human for an exception, or something more complex. > > Finally an additional constraint is that the MASA's signing infrastructure > may need to have the private key available, and so some kind of HSM might > be > appropriate, and those do not unfortunately track the bleeding edge of > cryptography. > > Personally, I'd like to recommend edwards25519 (RFC8032), but tooling is > not up to that today. That leaves one debating between size of RSA > >2048bit, > vs security of secp256k1 Nit: you mean secp256r1, i.e., P-256. Typically we don't use k1, though bitcoin does... -Ekr ... depending upon code space and hardware > acceleration available in target device. One would want to pick the same > algorithm as for SUIT and other stuff. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --f403043d04885d893305603e65fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 13, 2017 at 11:53 AM, Michael Richardson = <mcr+ietf@san= delman.ca> wrote:

Kathleen Moriarty <K= athleen.Moriarty.ietf@gmail.com> wrote:
=C2=A0 =C2=A0 > Thank you for addressing Russ' Gen Art comments.=C2= =A0 With that, I'm wondering if a
=C2=A0 =C2=A0 > recommended signature algorithm should be specified.=C2= =A0 This change had the work
=C2=A0 =C2=A0 > go from just supporting RSA to including other (and bett= er) choices.

I don't think we should recommend anything, or really need to. There is only a small interoperability issue with algorithm selection here.=

The manufacturer (in the form of the MASA) must generate a signature that their product (the pledge) is able to verify.

So the selection of signature algorithm is essentially driven by the
capabilities of the pledge.=C2=A0 The manufacturer knows what that is, and = so can
select appropriately.

There are tradeoffs of bandwidth, power consumption, code size, and longevi= ty
of algorithm, and I think that specific recommendations should be left to those closer to the specific kind of deployment.=C2=A0 =C2=A0A choice for a= home NAS
device intended to be sold immediately and deployed (with a ~5 year lifespa= n)
might have significant differences than for a 50-port 10GE switch to be
deployed in a secured data center after being warehoused for 10 years as a<= br> spare.

The voucher contains a pointer to the owner (the Registrar) within it, and = I
think that algorithm will be subject to a different set of constraints.

The intermediate system (JRC, or Registrar) is given the opportunity to aud= it
the resulting voucher.=C2=A0 As such, it needs to be able to verify the vou= cher,
and it is here that we have some interoperability issue if the manufacturer=
picks an unusual algorithm.=C2=A0 =C2=A0The Registrar could deny the new de= vice,
consult with a human for an exception, or something more complex.

Finally an additional constraint is that the MASA's signing infrastruct= ure
may need to have the private key available, and so some kind of HSM might b= e
appropriate, and those do not unfortunately track the bleeding edge of
cryptography.

Personally, I'd like to recommend edwards25519 (RFC8032), but tooling i= s
not up to that today.=C2=A0 That leaves one debating between size of RSA &g= t;2048bit,
vs security of secp256k1

Nit: you mean secp= 256r1, i.e., P-256. Typically we don't use k1, though bitcoin
does...

-Ekr

... depending upon code space and hardware
acceleration available in target device.=C2=A0 =C2=A0One would want to pick= the same
algorithm as for SUIT and other stuff.

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




--f403043d04885d893305603e65fa-- From nobody Wed Dec 13 12:21:18 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28E81242F5; Wed, 13 Dec 2017 12:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ_DGpY166Yj; Wed, 13 Dec 2017 12:21:15 -0800 (PST) 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 F303312009C; Wed, 13 Dec 2017 12:21:14 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id p84so1934896pfd.3; Wed, 13 Dec 2017 12:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FUa7hwB1rq2urKOdV1XhQLcNT2YwLWmGRaiSCMDryP8=; b=dQuxQfF23Wov45atJQ96BTNjyih8qcGUBftPZrd5OxYMFcJN8o0I6gZZNDaNBJHs2k 61CCEbe95ivchi1eoNKhLn5rT20WFMrGzQUt2203QVy9+BnOyEtYQgbo18J6U48tG3sa EVk63FqtlSeyA4nb/jZLjLr8ZAEZVPtpOz4rvSjP4k+ZBNfLvrAk6VAcJXSnQeYIh6ij 2rwi6pwBJm4WUm3Li9dLawF0LY0oeXps0d0o5MEBMYjxCOYKTkeVht5StcZ8TRkdkJVO 0FFuhiol7H/6bwKzjGDfd5Xos3agEbTTbJaT6kVHi2y7N7gC6O7rkOfTo/s74jbP+kcL DzMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FUa7hwB1rq2urKOdV1XhQLcNT2YwLWmGRaiSCMDryP8=; b=e4TLVGIyyyiLVqc0sgoAaBx0Cs+x0c3v08PcjQUJOBh0VyUAoD9G7oR0DhV1Rb9830 Sj4KhSPMxOVuMXPfWfRIOJEdLXTrtV+AebkfxP7GRih2z0Lsw8c1Z03xKO3gKKXkLY8r 3YrBJCLyg99+jbDS4t7Ncl2sTTZJdrrLibVTyn+6tUHMv1j7pnMmBZhk449JlpZJy21/ BgFR34bjjcOzKXLIL10ObDEoIw9uDOpH52vS0IN2N7K2hQZTFSyQ8ZpettmayKsmLAzv r+uJ5UPdMqswwrlHEp9MzQfTxNQFtkwIO7Duun3xM3sn2A1EOhKKi63XcBr5INPhxOf/ h9CA== X-Gm-Message-State: AKGB3mLhl3580xtoaJ+s2AVxjKdRHMxf7HFNbuJefRm2gv3yV4HS2UmC g6V1+sMPS61/dziS3IJEaGZSUHu2OXez3oLJtYg= X-Google-Smtp-Source: ACJfBovpe2KofFkdchgTNPbgcIkAZToKSM1FTu8em65iAOcyftdobTomuA7wRyNtNOSg18C2M7qqfHsIQqqT4+Abyew= X-Received: by 10.99.145.199 with SMTP id l190mr6347463pge.132.1513196474366; Wed, 13 Dec 2017 12:21:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Wed, 13 Dec 2017 12:20:33 -0800 (PST) In-Reply-To: References: <151318446761.30150.6931236674223703279.idtracker@ietfa.amsl.com> <8119.1513194785@obiwan.sandelman.ca> From: Kathleen Moriarty Date: Wed, 13 Dec 2017 15:20:33 -0500 Message-ID: To: Eric Rescorla Cc: Michael Richardson , anima-chairs@ietf.org, draft-ietf-anima-voucher@ietf.org, The IESG , Anima WG , Sheng Jiang Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Anima] Kathleen Moriarty's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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, 13 Dec 2017 20:21:17 -0000 On Wed, Dec 13, 2017 at 3:12 PM, Eric Rescorla wrote: > > > On Wed, Dec 13, 2017 at 11:53 AM, Michael Richardson > wrote: >> >> >> Kathleen Moriarty wrote: >> > Thank you for addressing Russ' Gen Art comments. With that, I'm >> wondering if a >> > recommended signature algorithm should be specified. This change >> had the work >> > go from just supporting RSA to including other (and better) choices. >> >> I don't think we should recommend anything, or really need to. >> There is only a small interoperability issue with algorithm selection >> here. >> >> The manufacturer (in the form of the MASA) must generate a signature that >> their product (the pledge) is able to verify. >> >> So the selection of signature algorithm is essentially driven by the >> capabilities of the pledge. The manufacturer knows what that is, and so >> can >> select appropriately. >> >> There are tradeoffs of bandwidth, power consumption, code size, and >> longevity >> of algorithm, and I think that specific recommendations should be left to >> those closer to the specific kind of deployment. A choice for a home NAS >> device intended to be sold immediately and deployed (with a ~5 year >> lifespan) >> might have significant differences than for a 50-port 10GE switch to be >> deployed in a secured data center after being warehoused for 10 years as a >> spare. >> >> The voucher contains a pointer to the owner (the Registrar) within it, and >> I >> think that algorithm will be subject to a different set of constraints. >> >> The intermediate system (JRC, or Registrar) is given the opportunity to >> audit >> the resulting voucher. As such, it needs to be able to verify the >> voucher, >> and it is here that we have some interoperability issue if the >> manufacturer >> picks an unusual algorithm. The Registrar could deny the new device, >> consult with a human for an exception, or something more complex. >> >> Finally an additional constraint is that the MASA's signing infrastructure >> may need to have the private key available, and so some kind of HSM might >> be >> appropriate, and those do not unfortunately track the bleeding edge of >> cryptography. Thanks for the explanation, this makes sense and it was a non-blocking question. I'm fine with this response and leaving the document as-is. Kathleen >> >> Personally, I'd like to recommend edwards25519 (RFC8032), but tooling is >> not up to that today. That leaves one debating between size of RSA >> >2048bit, >> vs security of secp256k1 > > > Nit: you mean secp256r1, i.e., P-256. Typically we don't use k1, though > bitcoin > does... > > -Ekr > >> ... depending upon code space and hardware >> acceleration available in target device. One would want to pick the same >> algorithm as for SUIT and other stuff. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > -- Best regards, Kathleen From nobody Wed Dec 13 12:21:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FFA12009C; Wed, 13 Dec 2017 12:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=TP7PxlN9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jqm7EqS3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nc8XvR90ull3; Wed, 13 Dec 2017 12:21:43 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F837126FDC; Wed, 13 Dec 2017 12:21:37 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AA12D20BB9; Wed, 13 Dec 2017 15:21:36 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 13 Dec 2017 15:21:36 -0500 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=fm1; bh=gHscJTDDRMtC3UVQWI+aEqmF6y7wP K/pjUsiwvM6r9E=; b=TP7PxlN94+yXYmcKabEGIdfymZ9BmoBDg8nBnd2ikIAMm ZL7ePyg47IPbMFzYVM2XzoEc7YPXI7DBj/cXXp6rf1f4GiMw2TudTe24+AFX273w p6vXrFG1KvPKSEr07EtCmPrSdGmhzDcA21YG+H+H1cz4XrIIr/ettgT+Q7iOJJhB CVAW2pRLNpmX8gVrVfhOS96aVMpW6K+VzgbEc6GRp/LLATuV5zYul7poLR6mfVbu 2wX0dpNE4yeoPkcanIvKsnCBEhYk2gqMsIYi8C3XjJwHVm1ISzm7HtPEXxkmInqP gwjk/UOHqz56JL6HVkw7ukZm5Q+PNee8NvsGul6Zg== 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=fm1; bh=gHscJT DDRMtC3UVQWI+aEqmF6y7wPK/pjUsiwvM6r9E=; b=jqm7EqS32ewkrDovuAsG0D musOnj8Ks4/y4uahovcL1T25xSw1cXjSPn+ATQ0B9pOAocfBRCCsMY8L86hdeBP3 6/2kYx3R5N9WxnmEag0OvQ9s6MeMGnE18cpDd4IjjxOJJ+PHwWzWR6iL9LzgLzWj x6ZvO4QimzwGGbNNM/SmvETW6sM5XL6w+bjbmmTTa8skQSvS8d+UcM0IXNWEMLJd awz4vKfVrYnw6bcTz41Bzw0gG/27ZJujDn41IW89CiVfaRmKw6JIQgqIyE6RfM0H y3rfQ8JWypbO2HA93Qwc4aXNMZvWn2XBkmn9aI+/QYnWYROuGygVypU6sS9TSPXA == X-ME-Sender: Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.187]) by mail.messagingengine.com (Postfix) with ESMTPA id 9600324009; Wed, 13 Dec 2017 15:21:35 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <150704985762.30710.15389510349503177651@ietfa.amsl.com> Date: Wed, 13 Dec 2017 15:21:34 -0500 Cc: gen-art , draft-ietf-anima-voucher.all@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150704985762.30710.15389510349503177651@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Anima] [Gen-art] Genart last call review of draft-ietf-anima-voucher-05 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, 13 Dec 2017 20:21:45 -0000 Russ, thanks for your review. Michael, thanks for addressing Russ=E2=80=99= s comments. I have entered a No Objection ballot. Alissa > On Oct 3, 2017, at 12:57 PM, Russ Housley = wrote: >=20 > Reviewer: Russ Housley > Review result: Not Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-anima-voucher-05 > Reviewer: Russ Housley > Review Date: 2017-10-03 > IETF LC End Date: 2017-10-112 > IESG Telechat date: unknown >=20 > Summary: Not Ready >=20 > Major Concerns: >=20 > Please do not reference RFC 2315. The is a full Internet Standard = that > should be used instead. Please reference RFC 5652, which goes back to > PKCS#7 as follows: >=20 > PKCS#7 --> RFC 2315 --> RFC 2630 --> RFC 3369 --> RFC 3852 --> RFC = 5652 >=20 > RFC 2315 only support signatures with the RSA algorithm. The = signature > value is the "result of encrypting the message digest and associated > information with the signer's private key." RFC 5652 will support any > known digital signature algorithm. Please reference it. >=20 > In Section 6, the document says: >=20 > The PKCS#7 structure SHOULD also contain all the certificates = leading > up to and including the signer's trust anchor certificate known to > the recipient. >=20 > Normally, the signer does not include the trust anchor certificate, so > a bit of rationale is needed here. There are clearly situations where > the trust anchor will not be known in advance, so that the the reason = to > include it. >=20 > In Section 6, the document also says: >=20 > The PKCS#7 structure MAY also contain revocation objects for any > intermediate certificate authorities (CAs) between the = voucher-issuer > and the trust anchor known to the recipient. >=20 > This is another place where RFC 5256 offers an improvement over = PKCS#7. > See Section 10.2.1 in RFC 5652, and see RFC 5940 for the information = on > OCSP responses. You might want to include CRLs or OCSP responses in a > short-lived voucher so that the recipient does not need to fetch any > revocation information to process the voucher. >=20 > Section 6 needs to specify the content type that will be carried in > SignedData. I believe that a new object identifier (OID) needs to be > assigned. I'm not sure whether you want to assign an OID for JSON > object or YANG structure. I can see where either one would work. >=20 > Section 9 should be expanded to assign the OID for the content type: > = www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1. >=20 >=20 > Minor Concerns: >=20 > I think it would be very helpful to include a diagram something like > this in Section 6. Perhaps all of the CMS discussion belongs in a > separate subsection. I did this to see if everything that is needed > was specified, and I learned that the eContentType was not defined. >=20 > ContentInfo { > contentType id-signedData, -- (1.2.840.113549.1.7.2) > content SignedData > } >=20 > SignedData { > version CMSVersion, -- always set to 3 > digestAlgorithms DigestAlgorithmIdentifiers, -- Only one > encapContentInfo EncapsulatedContentInfo, > certificates CertificateSet, -- Signer cert. path > crls CertificateRevocationLists, -- Optional > signerInfos SET OF SignerInfo -- Only one > } >=20 > SignerInfo { > version CMSVersion, -- always set to 3 > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs SignedAttributes, -- Required > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs UnsignedAttributes -- Optional > } >=20 > EncapsulatedContentInfo { > eContentType !!! NOT SPECIFIED YET !!! > eContent OCTET STRING -- the ietf-voucher > } >=20 > It would be very helpful to the implementer to say how each CMS field > is used. You can copy that vast bulk of the information that you need > from RFC 4108. In particular: >=20 > - See RFC 4180, Section 2.1.1 for ContentInfo. > - See RFC 4180, Section 2.1.2 for SignedData. > - See RFC 4180, Section 2.1.2.1 for SignerInfo. > - See RFC 4180, Section 2.1.2.2 for EncapsulatedContentInfo. >=20 >=20 > Nits: >=20 > In section 2: > s/autonomically/automatically/ > s/Registrar See/Registrar: See/ > s/entity it is contacted by/entity to make contact/ >=20 > In Section 6.1: > s/in Section 4)./in Section 4./ >=20 > In Section 8.1: > s/no understand of time/no understanding of clock time/ > s/clock accuracy then vouchers/clock accuracy, then vouchers/ >=20 > I think the table in Section 5 could be more readable. I suggest: >=20 > = +-------------------+-------------------+-------------+ > | Assertion | Registrar ID | Validity = | > = +--------+----------+--------+----------+-----+-------+ > Voucher | | | Trust | CN-ID or | | = | > Type | Logged | Verified | Anchor | DNS-ID | RTC | Nonce = | > = +-------------+--------+----------+--------+----------+-----+-------+ > |Audit | X | | X | | | X = | > = +-------------+--------+----------+--------+----------+-----+-------+ > |Nonceless | X | | X | | X | = | > |Audit | | | | | | = | > = +-------------+--------+----------+--------+----------+-----+-------+ > |Owner Audit | X | X | X | | X | X = | > = +-------------+--------+----------+--------+----------+-----+-------+ > |Owner ID | | X | X | X | X | = | > = +-------------+--------+----------+--------+----------+-----+-------+ > |Bearer | X | | wildcard | optional = | > |out-of-scope | | | | = | > = +-------------+--------+----------+--------+----------+-----+-------+ >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Dec 13 12:48:29 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFBE126CE8; Wed, 13 Dec 2017 12:48:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-anima-prefix-management@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+anima@cs.fau.de, anima@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151319810418.30121.10020770638906816886.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 12:48:24 -0800 Archived-At: Subject: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) 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, 13 Dec 2017 20:48:24 -0000 Warren Kumari has entered the following ballot position for draft-ietf-anima-prefix-management-06: 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-prefix-management/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you. I did have some comments / questions. I'd also like to draw both the authors, and AD's attention to Fred Bakers excellent thoughts in his OpsDir review - https://datatracker.ietf.org/doc/review-ietf-anima-prefix-management-06-opsdir-lc-baker-2017-10-23/ Firstly, a global concern: This technique (and I suspect many automated prefix allocations where a device uses space, and then requests more) is likely (I think) to result in fragmentation of the address space - this will lead to more routing entries in the IGP, which may be an issue for smaller routers or "L3 switches". I think that it would be useful to note this. I also wanted to make sure that the author of this document were aware of the CASM BoF from IETF98 - I've just checked, and see that at least Qiong Sun was associated with the work (draft-xie-ps-centralized-address-management). I had a question -- I don't really understand what: [Page 9] "A gateway router in a hierarchical network topology normally provides prefixes for routers within its subnet, ..." is trying to say. I've seen many "hierarchical network topologies" and don't believe this to be true, nor do I really understand what "its subnet" means. In some cases a router will announce an aggregate for customers behind it, but I don't really view that as a general case. I'm guessing I'm just not understanding - can you please educate me? From nobody Wed Dec 13 13:52:18 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E88A126D73; Wed, 13 Dec 2017 13:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Tm-ccHLdEY6F; Wed, 13 Dec 2017 13:52:11 -0800 (PST) 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 5537F1201F8; Wed, 13 Dec 2017 13:52:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E3F2620090; Wed, 13 Dec 2017 16:55:29 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4942081D85; Wed, 13 Dec 2017 16:52:10 -0500 (EST) From: Michael Richardson To: Eric Rescorla cc: Kathleen Moriarty , anima-chairs@ietf.org, draft-ietf-anima-voucher@ietf.org, The IESG , Anima WG , Sheng Jiang In-Reply-To: References: <151318446761.30150.6931236674223703279.idtracker@ietfa.amsl.com> <8119.1513194785@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Kathleen Moriarty's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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, 13 Dec 2017 21:52:13 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > Nit: you mean secp256r1, i.e., P-256. Typically we don't use k1, > though bitcoin > does... yeah, I was going to lookup which was which again, because I never remember. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloxoQkACgkQgItw+93Q 3WVQLgf+IO5jUCscjWWhEOhlkKRVxAWBUy5N4gvkHuGA+P1jpPeCbNVzuZZbHeTn WBBZMg4WKUSaZ82xPiODiQetlGiyhk+9XQrJWZLw+C+uoJkqTpkF6akGIy92O288 OHRN1o0dBp4OZu76RlnVW88zuNwuwHHwjynsNU6gPrS0vdHVUgdAVv3W+cekFwCR eSOfRXF+1RiWVshpom5N7qMmqOTqq37iS+B4IFRxpbdbcdL0Ld6i/9hqtSDQJBXr JHhuG5LySMsgHNfKVZ9n+qA0peIMQZ0RJ435ZqgxBvIF8QFDsIJmtz15uw2H/W6X +CUjSYP9Q5h2qAviWgtXYYO9XpLMig== =CF9n -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 13 14:14:19 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C56651205F0; Wed, 13 Dec 2017 14:14:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini To: Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-stable-connectivity.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151320325573.6218.13648540667060147075@ietfa.amsl.com> Date: Wed, 13 Dec 2017 14:14:15 -0800 Archived-At: Subject: [Anima] Iotdir last call review of draft-ietf-anima-stable-connectivity-07 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, 13 Dec 2017 22:14:16 -0000 Reviewer: Francesca Palombini Review result: Ready with Nits Hi, I am the assigned reviewer from the IoT directorate for this document. Please treat these comments just like any other last call comments. Document: draft-ietf-anima-stable-connectivity-07 Reviewer: Francesca Palombini Review Date: 2017-12-13 Overall comment: I think this document is ready for publication as informational, with some nits (mostly typos and editorial), listed below. Note that I did not include nits that were already underlined by other reviewers ( https://mailarchive.ietf.org/arch/msg/secdir/SJGDKh34-J9gU8P7KJjEnryAUMM and https://mailarchive.ietf.org/arch/msg/gen-art/ouSMdOa3t_tq6xqYGDivdkyyZlQ) * Abstract: "OAM (Operations, Administration and Maintenance - as per BCP161, (RFC6291) processes for data networks are often subject" should be "OAM (Operations, Administration and Maintenance - as per BCP161, [RFC6291]) for data networks is often subject" * Abstract: "This document describes how to integrate OAM processes with the autonomic control plane (ACP)" should be "This document describes how to integrate OAM processes with the Autonomic Control Plane (ACP)" * Section 1.1 (suggestion): it would have been good to have a "Terminology" section, that would expand on the most used terms, such as "autonomic", as well as reference the list of documents listed in section 2.1, first paragraph. * Section 2, second bullet: "The are" should be "There are" * Section 2, third bullet: "autonomic network" should be "Autonomic Network (AN)", as the abbreviation is used in section 2.1.6 too. * Section 2.1.1 (question): "as defined in section 6.1 of [I-D.ietf-anima-autonomic-control-plane]" is this the right section referenced? Could not see what is mentioned there. * Section 2.1.1: "NMS hosts" NMS should be expanded (1st time used) * Section 2.1.1: "spearate" should be "separate" * Section 2.1.1 (suggestion): "NMS that performs SNMP read operations for status checking," should be "performing SNMP read operations for status checking by NMS," * Section 2.1.1: "for network devices as" should be "for network devices such as" * Section 2.1.2: "that is, operator cannot achieve desired goals with this setup" should be "that is, operators cannot achieve desired goals with this setup" * Section 2.1.2: "candiate" should be "candidate" * Section 2.1.3 (question): is "ACP connect section of [I-D.ietf-anima-autonomic-control-plane]" section 8.1 of [I-D.ietf-anima-autonomic-control-plane]? It would be good to have the reference for easier reading. * Section 2.1.3 (suggestion): please expand on the doc used before referencing the RFC; for example: "That document also specifies how the NOC devices can receive autoconfigured addressing and routes towards the ACP connect subnet if it supports [RFC6724] and [RFC4191]" could be something like "That document also specifies how the NOC devices can receive autoconfigured addressing and routes towards the ACP connect subnet if it supports Default Address Selection for IPv6 [RFC6724] and Default Router Preferences [RFC4191]" * Section 2.1.3: "See the ACP document text for more details." a direct reference would help the reader here. * Section 2.1.4 (question): "Independent of whether the data plane is dual-stack, has IPv4 as a service or is single stack IPv6." This sentence is unclear to me, is it missing words maybe? * Section 2.1.4: "IPv4 only management" should be "IPv4-only management" (2 occurences) * Section 2.1.4 (question): "This means that stateless SIIT based solutions are sufficient and preferred." If I understand correctly, SIIT is the only method mentioned here that solves the requirements; in this case, using the term preferred is maybe not necessary (since we are not comparing to others). If that's correct, I suggest removing "and preferred". * Section 2.1.4 (suggestion): again, please expand on the names of the RFC before referencing them: RFC1918 and RFC7757 * Section 2.1.4: "Assume the ACP uses the Zone Addressing Sub-Scheme and there are 3 registrars." missing a word? * Section 2.1.4 (suggestion): "In the Zone Addressing Sub-Scheme, there is for each registrar a constant /112 prefix for which in RFC7757 an EAM (Explicit Address Mapping) into a /16 (eg: RFC1918) prefix into IPv4 can be configured." is unclear. Does rephrasing to "In the Zone Addressing Sub-Scheme, for each registrar there is a constant /112 prefix that can be configured through an EAM (Explicit Address Mapping) into a /16 prefix in IPv4 (e.g. RFC1918)" keep the original meaning? * Section 2.1.4: "it is unlikely that one wants or need to translate" should be "it is unlikely that one wants or needs to translate" * Section 2.1.4: "Eg: that IPv4 only NMS hosts" should be "E.g.: that IPv4-only NMS hosts" * Section 2.1.5: "but the data-plane connectivity is only present under normal operations but will not be present during e.g. early stages of device bootstrap," should be "but the data-plane connectivity is only present under normal operations and will not be present during e.g. early stages of device bootstrap," * Section 2.1.5: "caries" should be "carries" * Section 2.1.5: expand the first occurrence of "VRF" * Section 2.1.6: expand the first occurrence of "AN" * Section 2.1.8: "IPv4 only applications" should be "IPv4-only applications" * Section 3.1: "IPv4 only NOC solutions" should be "IPv4-only NOC solutions" * Section 4: "to voluntarily list your own the ULA ACP prefixes" should be "to voluntarily list your own ULA ACP prefixes" * Section 4: expand ULA on first use Francesca From nobody Wed Dec 13 16:48:45 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB221243FE; Wed, 13 Dec 2017 16:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lxgLrxcE3QyP; Wed, 13 Dec 2017 16:48:38 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DD41200F1; Wed, 13 Dec 2017 16:48:35 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id g7so2281047pgs.0; Wed, 13 Dec 2017 16:48:35 -0800 (PST) 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=ItAqLYNiFlZMIP/fPxuuCAgXfMxVFW9huVYgrfkWdyA=; b=Lg/AgmxRB8wDvKuhiHXwAhU9QNWag/5oquvQdaeotgQ+E9OudCb2Qph6AMpwJ0SSUy mtT12AiqJEEKCqlBNtXSuaWGExvdQOyLBjj55Kd/A9TBRh8FJDjm0muNsBf4/8o6j+Y0 30d7UB12v7R6Jhpy2FGUwLRoHxnTrfbRYfiDIZ2ZEctDWhqU8QCM39f6EV2F7lgtEGxY IZXv62ySuDZk45MXQMrw/oA/37CZv7+aK5vGpPyUG+UOSMFIfHUafsbKPs6ACSD16wIE +2c4hMxOKhvG/6uIu3/JXVmPzJrhv8CvnxHoHqzqbubqAB/q+HzJGI5zjDtGOUABN4cK cF+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ItAqLYNiFlZMIP/fPxuuCAgXfMxVFW9huVYgrfkWdyA=; b=bR+CAf3gWVivks1D9YrMiPnEo4BTSKr4RdGXAVkIJrB3UmL6Rk1/cv1wJaWIX1/71y MN1U+Ts0NbTUDjwYHdlLsHzZhhErKKjcoNHomWNx8fuWuogEs32laDvG7ku92JYJlBJ5 IdrRom0+op6w8SmTLWAdjfBpWjJESqnigP96TK3a4S1afFKWlgidkea52UTdA8eri/sj XCvD71ZDhaang19Omj1s8rK0LHyltjmujChAlgr5dRCPvHpn0i6WBZWafIWYHi5ywFHl us6HqNq96FKaY7LpV2jXLtiB7vHPZDT2tvcxauCCpUWJ0f+3wrpBtAvsiZXHf+4yYXvD ja0w== X-Gm-Message-State: AKGB3mKuadLnVvqYCaTCuEjbVNrlNUQIarkqePo3mSgCgtkUsCVvz4M4 NUuq2ZGeoKX5UkT+UWxumh8= X-Google-Smtp-Source: ACJfBosRHT+XaWktAKv+8Iv7cT9T3qg0YiwtYLBO+s1kxt+QG9RG+y6NUyJp2xPA9TRxKBGESov5xQ== X-Received: by 10.98.246.18 with SMTP id x18mr7847985pfh.219.1513212514596; Wed, 13 Dec 2017 16:48:34 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s81sm5572229pfg.60.2017.12.13.16.48.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 16:48:33 -0800 (PST) To: Warren Kumari , The IESG Cc: draft-ietf-anima-prefix-management@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+anima@cs.fau.de, anima@ietf.org, fredbaker.ietf@gmail.com References: <151319810418.30121.10020770638906816886.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1fceefc8-e874-33f5-705c-268db9314aed@gmail.com> Date: Thu, 14 Dec 2017 13:48:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151319810418.30121.10020770638906816886.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) 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, 14 Dec 2017 00:48:40 -0000 On 14/12/2017 09:48, Warren Kumari wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you. > > I did have some comments / questions. > I'd also like to draw both the authors, and AD's attention to Fred Bakers > excellent thoughts in his OpsDir review - > https://datatracker.ietf.org/doc/review-ietf-anima-prefix-management-06-opsdir-lc-baker-2017-10-23/ > > Firstly, a global concern: > This technique (and I suspect many automated prefix allocations where a device > uses space, and then requests more) is likely (I think) to result in > fragmentation of the address space - this will lead to more routing entries in > the IGP, which may be an issue for smaller routers or "L3 switches". I think > that it would be useful to note this. That devil is in the details, but you're correct, that is a risk. How big a risk depends on the algorithms and policies used. If we get to update the draft, this would be a good point to add. > > I also wanted to make sure that the author of this document were aware of the > CASM BoF from IETF98 - I've just checked, and see that at least Qiong Sun was > associated with the work (draft-xie-ps-centralized-address-management). Yes, in fact it would mesh quite nicely with CASM. That's the main reason I pushed to have the C in CASM mean "coordinated" instead of "centralized". > I had a question -- I don't really understand what: [Page 9] "A gateway router > in a hierarchical network topology normally provides prefixes for routers > within its subnet, ..." is trying to say. I've seen many "hierarchical network > topologies" and don't believe this to be true, nor do I really understand what > "its subnet" means. In some cases a router will announce an aggregate for > customers behind it, but I don't really view that as a general case. I'm > guessing I'm just not understanding - can you please educate me? Hmm. In a manually designed network (especially with v6) I'd expect the initial design would be done in something close to a binary tree, but in the real world things tend to drift from that starting point over the lifetime of the network. But I think the phrasing is probably trying to say too much in too few words. All it's really trying to say is that the ability to negotiate with an arbitrary peer is more powerful than only being able to ask your upstream for more prefixes. Again, happy to clarify the wording if we update the draft again. Brian From nobody Wed Dec 13 17:59:30 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D34128799 for ; Wed, 13 Dec 2017 17:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 A_9rwrPFOl6P for ; Wed, 13 Dec 2017 17:59:27 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0AC127B52 for ; Wed, 13 Dec 2017 17:59:25 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id v22so3838832wrb.0 for ; Wed, 13 Dec 2017 17:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9Tcsogh2jRkd5hWxihEdHrX3pVbXnAI0Ch8TWmi4R+A=; b=rwV6w2Vt6nTblby7Idb/OPrrrkA/8X2DDb1fx1sfivNIOjyDbfbR6iVlA12gXCl9ym RkzAkxvS6e9/5NMjQfULonvFjTpEZY3FmtGhSRTQm+xtPKPBLxjY+N1rdZ0BnwqlMiaH MtjkKKw2yd5fMvaNEghVX0LdtUOLpRRix2BBlzX3bc6znUH2oBE9ecP77/q8qZvfCo3H GN0eBx1MYJ8slmMa4f8qLAYRrP9kMX6f2LWiGxzc3xeHB/1KpYSrUOawT5CZNutDhJ7O 4KfUoSEjFaFPF0g03BnfxzXMhDL4v9dfcl6AvxK1Pt0eanHK3B3fzpenq+4bSn5R8fOW U8kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Tcsogh2jRkd5hWxihEdHrX3pVbXnAI0Ch8TWmi4R+A=; b=UwL0RCcA1a/w95yrcOy1CZkSjmJYqsSY6CywKHcCutMx/QoDaFF94oj2BdIjS6waof vF7qrcX2e6OpZ9e9zZcDitUJ/YK8NHNFK0tuXaXkgdf3vZQDvMIO8F8virU/gCKpOXVG OZyxeX5ID/hbLCEa6seaaKpeL7UocKlQSHwWT8tapsg8Lou6OBbg+H1mf5sWC5jDEiTY jUO19MnhL5RC9ECOHPLhExnzzRBbV/SpFtymEsyXqG4+KS7HZNG8l8NCJsGQda816+GV Oo/RUCzudtrq+4nd//yu1KnQmfo1Zs1gTy+9tWzZ38IIZPryem8kMIYE0tjpN/wjYnBm xWxg== X-Gm-Message-State: AKGB3mJmdu3/Mb8tP9cvW+BT6EwM9PmnwFqirUgFW+dPQZyHSBWzo+BR tmNKeJnMtJMZof50liEeBQXYqQQ6Pbps2Ca4e4ZQIg== X-Google-Smtp-Source: ACJfBotScZMbbPCYIjopKmg9bARGotf7QD2GBQoak3tejH9ISBFSGu6gAnkiqW/c16qwfvnS4ZqPnoGSUq5nVbMEdZ4= X-Received: by 10.223.201.139 with SMTP id f11mr1899154wrh.283.1513216763623; Wed, 13 Dec 2017 17:59:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.149 with HTTP; Wed, 13 Dec 2017 17:58:43 -0800 (PST) In-Reply-To: <1fceefc8-e874-33f5-705c-268db9314aed@gmail.com> References: <151319810418.30121.10020770638906816886.idtracker@ietfa.amsl.com> <1fceefc8-e874-33f5-705c-268db9314aed@gmail.com> From: Warren Kumari Date: Wed, 13 Dec 2017 20:58:43 -0500 Message-ID: To: Brian E Carpenter Cc: The IESG , draft-ietf-anima-prefix-management@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+anima@cs.fau.de, anima@ietf.org, Fred Baker Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) 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, 14 Dec 2017 01:59:29 -0000 Ok, I'm happy. If you do update, I think that the last point is the most confusing, and needs the most work, but I'm as I said, I'm a happy camper. W On Wed, Dec 13, 2017 at 7:48 PM, Brian E Carpenter wrote: > On 14/12/2017 09:48, Warren Kumari wrote: > ... >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thank you. >> >> I did have some comments / questions. >> I'd also like to draw both the authors, and AD's attention to Fred Bakers >> excellent thoughts in his OpsDir review - >> https://datatracker.ietf.org/doc/review-ietf-anima-prefix-management-06-opsdir-lc-baker-2017-10-23/ >> >> Firstly, a global concern: >> This technique (and I suspect many automated prefix allocations where a device >> uses space, and then requests more) is likely (I think) to result in >> fragmentation of the address space - this will lead to more routing entries in >> the IGP, which may be an issue for smaller routers or "L3 switches". I think >> that it would be useful to note this. > > That devil is in the details, but you're correct, that is a risk. How big a risk > depends on the algorithms and policies used. If we get to update the draft, > this would be a good point to add. > >> >> I also wanted to make sure that the author of this document were aware of the >> CASM BoF from IETF98 - I've just checked, and see that at least Qiong Sun was >> associated with the work (draft-xie-ps-centralized-address-management). > > Yes, in fact it would mesh quite nicely with CASM. That's the main reason > I pushed to have the C in CASM mean "coordinated" instead of "centralized". > >> I had a question -- I don't really understand what: [Page 9] "A gateway router >> in a hierarchical network topology normally provides prefixes for routers >> within its subnet, ..." is trying to say. I've seen many "hierarchical network >> topologies" and don't believe this to be true, nor do I really understand what >> "its subnet" means. In some cases a router will announce an aggregate for >> customers behind it, but I don't really view that as a general case. I'm >> guessing I'm just not understanding - can you please educate me? > > Hmm. In a manually designed network (especially with v6) I'd expect > the initial design would be done in something close to a binary tree, > but in the real world things tend to drift from that starting point > over the lifetime of the network. But I think the phrasing is probably > trying to say too much in too few words. All it's really trying to say > is that the ability to negotiate with an arbitrary peer is more powerful > than only being able to ask your upstream for more prefixes. > > Again, happy to clarify the wording if we update the draft again. > > Brian > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Dec 13 19:07:28 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3FA127078; Wed, 13 Dec 2017 19:07:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-anima-voucher@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151322084669.6095.9407517789857951491.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 19:07:26 -0800 Archived-At: Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 03:07:26 -0000 Ben Campbell has entered the following ballot position for draft-ietf-anima-voucher-06: 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-voucher/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just some editorial comments: - Abstract: I suspect readers will not understand the meaning of "pledge". The abstract should be understandable without referencing the terminology section. -4, definition of Assertion Basis" : is "secure root of trust of measurement" a term of art, or a typo? -7.1, first paragraph: s/understand/understanding From nobody Wed Dec 13 20:20:11 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B0F127275; Wed, 13 Dec 2017 20:20:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-anima-prefix-management@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+anima@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151322520961.6124.6728640618034204081.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 20:20:09 -0800 Archived-At: Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 04:20:09 -0000 Ben Campbell has entered the following ballot position for draft-ietf-anima-prefix-management-06: 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-prefix-management/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - On my first reading, I wondered why this was informational. It seems to seek to standardize protocol elements. The explanation in the shepherd report clarifies that; it would be helpful to include (a perhaps shortened version of) that in the draft. -2: RFC 8174 has boilerplate to address the "only in upper case" part. Please consider using it rather than modifying the 2119 boilerplate. -4.4: "It is therefore important to record all the prefix assignment history." Isn’t this a local policy choice? Perhaps some operator believes in extreme log minimization, does this mean to argue they are mistaken? From nobody Wed Dec 13 22:28:41 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0B112702E; Wed, 13 Dec 2017 22:28:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-anima-voucher@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151323291963.6071.13432030924018362994.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 22:28:39 -0800 Archived-At: Subject: [Anima] Adam Roach's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 06:28:39 -0000 Adam Roach has entered the following ballot position for draft-ietf-anima-voucher-06: 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-voucher/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and working group participants for their work on this document. I have a somewhat major and handful of minor suggestions for improvement. The larger comment is: section 5 talks about a variety of potential alternate formats and mentions a couple of techniques that might be used to differentiate among them. I'll note that these techniques relate to MIME types and related data (filename extensions). The fact that *this* document doesn't define a MIME type for the CMS-signed-JSON variant will make it difficult and/or awkward for these future formats to employ these techniques. For example, if I were to define a COSE-signed-CBOR format and say "use HTTP Content-Type header fields to tell this apart from CMS-signed-JSON", I would be in the somewhat odd position of having to define the MIME-type for CMS-signed-JSON in *that* document, or of coming up with a very short update to the anima-voucher document that does nothing other than define its MIME type. It seems that adding a single sentence to section 5 ("To facilitate these techniques, this document registers a MIME type for CMS-signed JSON in section 8.4") plus a registration of a new MIME type along with its filename extension (e.g., "application/voucher-cms+json" and ".vcj") in that new section 8.4 would make life much easier for anyone who wants to define the alternate formats envisioned by section 5. Section 2: Securely imprinting is a primary focus of this document [imprinting]. This is a pretty awkward citation. Suggest maybe changing it to: Securely imprinting is a primary focus of [imprinting]. (It's also not entirely clear that the cited article covers *securely* imprinting, so you may consider rephrasing the sentence entirely) Section 2: Authentication of Join Registrar: Indicates how the Pledge can authenticate the Join Registrar. This might include an indication of the private PKIX (Public Key Infrastructure using X.509) trust anchor used by the Registrar, or an indication of a public PKIX trust anchor and additional CN-ID or DNS-ID information to complete authentication. I think a citation here to RFC6125 would be helpful to the user in understanding the meaning of CN-ID and DNS-ID. Section 7.1: I think it would be useful to explicitly point out that a device that might have a MITM registrar could also have an MITM attack against any attempts to use an unauthenticated network protocol (such as NTP) to retrieve a time; and that such network-retreived times cannot be trusted for voucher verification purposes. From nobody Thu Dec 14 06:15:27 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076CE128E00; Thu, 14 Dec 2017 06:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_nJoxjKI9GQ; Thu, 14 Dec 2017 06:15:18 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00138.outbound.protection.outlook.com [40.107.0.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449A0128DE5; Thu, 14 Dec 2017 06:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZPTv1UBt/bWnxsuiS+PbPvGpR/HjsZQDx1WMo0nK3sc=; b=H70goE2saipWjHvC2tGl1XZyJUFW08wVeanXNH3fG52Q8IL+wnJ61qwCHnBuT22a4vinqO7niaYGXnNas5pM8261H8jYJWyrwXXDYjcMe4o1lmjdqZcS7AKO/+ltv6rLtyW454L1l3eJAtLJ5DkYh6sdYj9G7c1z3eWdTQCdASs= Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com (10.168.36.134) by HE1PR0701MB2202.eurprd07.prod.outlook.com (10.168.36.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Thu, 14 Dec 2017 14:15:13 +0000 Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::e4ad:9659:31f:658f]) by HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::e4ad:9659:31f:658f%15]) with mapi id 15.20.0323.011; Thu, 14 Dec 2017 14:15:12 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: Brian E Carpenter , Warren Kumari , The IESG CC: "tte+anima@cs.fau.de" , "fredbaker.ietf@gmail.com" , "anima-chairs@ietf.org" , Toerless Eckert , "draft-ietf-anima-prefix-management@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) Thread-Index: AQHTdFO7whdyuxUoKESuigSWAo/55KNCAeIAgADfYfA= Date: Thu, 14 Dec 2017 14:15:12 +0000 Message-ID: References: <151319810418.30121.10020770638906816886.idtracker@ietfa.amsl.com> <1fceefc8-e874-33f5-705c-268db9314aed@gmail.com> In-Reply-To: <1fceefc8-e874-33f5-705c-268db9314aed@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia-bell-labs.com; x-originating-ip: [131.228.2.23] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2202; 6:GNBaVzqsliOVpTHcaL/9pKgyIGSGOl163DL8DW11S8q0vpPYhI5XLaCA0SeNUv+J95Ygwt6j/7dve0Q0TEDAkWvU7Q8L+lPOKALQ4S7wa9rPmlYe4M59DYVAl/N3iQzMqVpZz+ObHAbH/iGPVWWFmH8FCYPUwIxJUiM1V2pv2F47a8Sv2Y8VniRXU/QkjTvqMGezcBinb3CVdt5hZNHoeGU1U1eUnypBIrSAQXiM5L5Toz2r2OSICWz4nuHZ749VgwUULUzQ0GcpO8gZAw4HU3SEeDK6lcCvA0fwVqt09JmVmUSOKTIY04dVl/JQTy5wMs1w6EjbbitsskeHNBC/iCeeJL9noQJACIzhjdXAS3M=; 5:FDPK9GJDCuayJ6N2GHJS+liVcLlEo6Fvaix75L1FnbwDhIS+g/PvLVzy+d6cjX1JvUEQPzbgo4hSECjpiHvRDOSzhE/2U/RxXv9ox038s2An07CeFuYgcDV5a2j6ECFGGZoLX7jBEObp5OermGgEpIo4pl8HbK9iwdA2MSQ8BPA=; 24:lSwHrPeiIbJGHRJZS6yXfcKfW5W9Df0WQt0mh0ZAV8A0G3Qr3G3Xzo31fMekjW5ZlOuIFjkHXG4on5hSP9a5YXEnY0+SquQm5wnv3YwZcQU=; 7:EP/YXuQygHUJca02+25oLbQm8C/udPX21mc4ANex+y8d5EcJf+zMBWtwAfLOt/drFfXUHZC1vqgmsuwCB0uQpCbqo5qsWSjbGML5kmDJh1a+qtp9Au48jJ8TKIUi65RbQPlbsYWwHOJw2h453Xtb4GqL5NmXN4yxf+9cW3Vr25U4Zh1+RNbgZSMyOWqdvQE2ff16RONRJEgP1IFpzOwp8cs9YAnYeI1dIKC6CPKXj7g3ZOW6JUK4anUrbEnIiOtq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f7539062-6773-40ee-693f-08d542fd1758 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:HE1PR0701MB2202; x-ms-traffictypediagnostic: HE1PR0701MB2202: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(11241501184)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:HE1PR0701MB2202; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2202; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(366004)(51444003)(189003)(24454002)(199004)(13464003)(68736007)(76176011)(6116002)(102836003)(7736002)(3846002)(305945005)(2950100002)(53936002)(74316002)(5660300001)(25786009)(39060400002)(66066001)(4326008)(99286004)(6246003)(33656002)(6436002)(7696005)(8936002)(5250100002)(229853002)(4001150100001)(97736004)(55016002)(9686003)(316002)(6306002)(2900100001)(966005)(53546011)(3660700001)(3280700002)(2906002)(6506007)(8676002)(86362001)(81166006)(14454004)(81156014)(54906003)(59450400001)(230783001)(110136005)(106356001)(105586002)(478600001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2202; H:HE1PR0701MB2203.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7539062-6773-40ee-693f-08d542fd1758 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 14:15:12.8153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2202 Archived-At: Subject: Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) 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, 14 Dec 2017 14:15:26 -0000 Hello, >=20 > Firstly, a global concern: > This technique (and I suspect many automated prefix allocations where=20 > a device uses space, and then requests more) is likely (I think) to=20 > result in fragmentation of the address space - this will lead to more=20 > routing entries in the IGP, which may be an issue for smaller routers=20 > or "L3 switches". I think that it would be useful to note this. That devil is in the details, but you're correct, that is a risk. How big a= risk depends on the algorithms and policies used. If we get to update the = draft, this would be a good point to add. >>Laurent: not providing a definitive answer / solution, but if we see more= deployment of autonomic functions (such as automatic/autonomic prefix mana= gement), we can imagine to also have functions taking care of the fragmenta= tion and re-aggregation in an automatic/autonomic way. Thus, the risk _coul= d_ _eventually_ be minimized. >>Laurent: if the issue for small(er) routers / L3 switches is on performan= ce, then there is usually Moore's law that can help address it in a few yea= rs span (even with degraded Moore's law). If the issue is complexity, then = this is an additional case to have more autonomic (read: intelligent) funct= ions running simultaneously in the network / in the devices. Best regards, Laurent. -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, December 14, 2017 1:49 AM To: Warren Kumari ; The IESG Cc: tte+anima@cs.fau.de; fredbaker.ietf@gmail.com; anima-chairs@ietf.org; T= oerless Eckert ; draft-ietf-anima-prefix-management@ietf.org= ; anima@ietf.org Subject: Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefi= x-management-06: (with COMMENT) On 14/12/2017 09:48, Warren Kumari wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you. >=20 > I did have some comments / questions. > I'd also like to draw both the authors, and AD's attention to Fred=20 > Bakers excellent thoughts in his OpsDir review -=20 > https://datatracker.ietf.org/doc/review-ietf-anima-prefix-management-0 > 6-opsdir-lc-baker-2017-10-23/ >=20 > Firstly, a global concern: > This technique (and I suspect many automated prefix allocations where=20 > a device uses space, and then requests more) is likely (I think) to=20 > result in fragmentation of the address space - this will lead to more=20 > routing entries in the IGP, which may be an issue for smaller routers=20 > or "L3 switches". I think that it would be useful to note this. That devil is in the details, but you're correct, that is a risk. How big a= risk depends on the algorithms and policies used. If we get to update the = draft, this would be a good point to add. =20 >=20 > I also wanted to make sure that the author of this document were aware=20 > of the CASM BoF from IETF98 - I've just checked, and see that at least=20 > Qiong Sun was associated with the work (draft-xie-ps-centralized-address-= management). Yes, in fact it would mesh quite nicely with CASM. That's the main reason I= pushed to have the C in CASM mean "coordinated" instead of "centralized". =20 > I had a question -- I don't really understand what: [Page 9] "A=20 > gateway router in a hierarchical network topology normally provides=20 > prefixes for routers within its subnet, ..." is trying to say. I've=20 > seen many "hierarchical network topologies" and don't believe this to=20 > be true, nor do I really understand what "its subnet" means. In some=20 > cases a router will announce an aggregate for customers behind it, but=20 > I don't really view that as a general case. I'm guessing I'm just not und= erstanding - can you please educate me? Hmm. In a manually designed network (especially with v6) I'd expect the ini= tial design would be done in something close to a binary tree, but in the r= eal world things tend to drift from that starting point over the lifetime o= f the network. But I think the phrasing is probably trying to say too much = in too few words. All it's really trying to say is that the ability to nego= tiate with an arbitrary peer is more powerful than only being able to ask y= our upstream for more prefixes. Again, happy to clarify the wording if we update the draft again. Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Thu Dec 14 06:39:41 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3C126C89; Thu, 14 Dec 2017 06:39:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-anima-voucher@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org, jclarke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151326238022.6116.14475954177249959809.idtracker@ietfa.amsl.com> Date: Thu, 14 Dec 2017 06:39:40 -0800 Archived-At: Subject: [Anima] Benoit Claise's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 14:39:40 -0000 Benoit Claise has entered the following ballot position for draft-ietf-anima-voucher-06: 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-voucher/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some nits, coming from Joe Clarke as OPS DIR reviewer. Section 2: Old Text: The MAS concept is explained in more detail in... New Text: The MASA concept is explained in more detail in... (Note: MAS => MASA) Old Text: Registrar See Join Registrar New Text: Registrar: See Join Registrar (Note: colon added) From nobody Thu Dec 14 07:21:22 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2EF126D3F; Thu, 14 Dec 2017 07:21:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-anima-voucher@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151326487516.6071.987243946129618389.idtracker@ietfa.amsl.com> Date: Thu, 14 Dec 2017 07:21:15 -0800 Archived-At: Subject: [Anima] Eric Rescorla's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:21:15 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-anima-voucher-06: 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-voucher/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- We are discussing some comments in email, but they seem to be about writing, not technology. From nobody Thu Dec 14 07:40:26 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4E01293EB; Thu, 14 Dec 2017 07:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 I-uIAWT29TYg; Thu, 14 Dec 2017 07:40:19 -0800 (PST) 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 9B9F1126DED; Thu, 14 Dec 2017 07:40:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 12CDE20090; Thu, 14 Dec 2017 10:43:41 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B809080678; Thu, 14 Dec 2017 10:40:18 -0500 (EST) From: Michael Richardson To: Eric Rescorla cc: Toerless Eckert , anima@ietf.org, "Max Pritikin \(pritikin\)" , "draft-ietf-anima-voucher\@tools.ietf.org" , IESG In-Reply-To: References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 15:40:21 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > The case I am concerned with right now is the case where the attacker > just imprints the device and then operates it even though it's in the > victim's network. How can they join the victim's network, if the point of the enrollment is to provide the device with keys to be able to join the victim's network? (The exact nature of the keys depends upon how the voucher is used. In BRSKI it's to bootstrap an EST connection, while in some versions of the 6tisch, actual 802.15.4 keys are return. NETCONF uses this new trust to permit the owner to reach in and do configuration with RESTCONF) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloym2IACgkQgItw+93Q 3WUxhQf+L6qG78JzWWArO99Thyuzx/pAEgTd19fqI2Fo9iWDADzHQEJABbTOyeka K2gGQbISkjpwV0O202sWzW5jMrvl6cVZRZggSQ/PVxJK/VCCY5I+QNvrmBA/PIR6 8Hs28Y0sKSOxD1CrpfYuQzcdUJF0q6wFcdJXJQVp1/3GeLg93n47NBO0I5YQ8uKJ phVEeVaWC3xYwXnwZw91JuScrybbvnGxiDaI2l+A9WWhKD5+Rwp/ksepd2oSYvWX Y5RNsmyjOjyGjjH6dQGvzRgKcx3wWgN46neOX/wvR2x8EL7Is6qPHHZBXvCUqJRk do/6fJcIEesztmO4fQJKRuMkI9C7/Q== =Dp7M -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 14 07:44:26 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63583126DED for ; Thu, 14 Dec 2017 07:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 pAVGc1ycJejE for ; Thu, 14 Dec 2017 07:44:23 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 921861293F4 for ; Thu, 14 Dec 2017 07:44:23 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id b15so151196ybn.0 for ; Thu, 14 Dec 2017 07:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/m4LGbltvjsfJ0KlDh8LhSe1wsSUKLEN6OaxTWR+wFM=; b=DRcxeBTQbVu0SkQAbt7oOZarWwJqLcQB2hcif2m9nnqEqqNMpy3pba/7j3a59l0v8W 5cUOCbSNUaPBkqauAqYA+5EUubPC89+G9jhvHBMo2wLk0rLSRigGQHx3RPMbwAZbgbV+ tyGkS3+6w7lijVgh+CuIzhwCkK218sniFN8FoPyp9Kw8SsCGVjhBAM0ILxd2EMzI1iJc xTxbSZENByIfWg9fIkDemnP1Ln7rJWWFShYhGpOj5EzqRm4XGCqZBTDcVB93dludB1+R XTD8/YVmF4vuX7xP2gDgGfDwzCFlZH8tEjpd0yX98NWxhXvGOBc4JjlYJq04+K5Do9Tx GxcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/m4LGbltvjsfJ0KlDh8LhSe1wsSUKLEN6OaxTWR+wFM=; b=HZqJoxX6F1T4rRsnZMetqcd9iQ/8Kl/rO5wPdl4vdgdegciqlOlzxIzvJCZPiMeZqa llXu0JBE97ZBE66Z6SPpy+Q7GJkzOxC7gn1Fx/MAI1ztUL1VhVLgIn7Y8RLc4Q7fDs1J b2d55BvOL/Tr9hpMbuxOIhDCLj+LP/WVuyfaHB7/4gOOcwSXkYEsfrm9jkgWnS4YPjz6 mNOrsHHLMwBPx9It5+cb3zLauhUdVgspU18AkksekLuuLG4vrKDQzmS/q3a9SuKDhzLL XUntueDEtPErgt8pOWMC+04Sq/N8cbCPIoKuvtP8U4P0DPjqufCb/ClA5A3BOLLG74Fe juSA== X-Gm-Message-State: AKGB3mK0QWUoWsgTgGXxNIAVi5qXK1I8Qh3YB6RwHM1V+8ChB7ev8tsZ mcWJlIjr8XCsERuj1bb0hIi+mG7Oe+f+Wgsm+i1fsA== X-Google-Smtp-Source: ACJfBotdbIIMGit4jwD/Meqp7wTxJHsXL1sI3OkZdWthT8kyUMks4COkO3MOIkZOnxTgz2i5TcbW0luple/Hmz1PDNs= X-Received: by 10.37.178.26 with SMTP id i26mr4460232ybj.208.1513266262835; Thu, 14 Dec 2017 07:44:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 14 Dec 2017 07:43:41 -0800 (PST) In-Reply-To: <3100.1513266018@obiwan.sandelman.ca> References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> From: Eric Rescorla Date: Thu, 14 Dec 2017 07:43:41 -0800 Message-ID: To: Michael Richardson Cc: Toerless Eckert , Anima WG , "Max Pritikin (pritikin)" , "draft-ietf-anima-voucher@tools.ietf.org" , IESG Content-Type: multipart/alternative; boundary="f403045f3f060c1dee05604ec2c4" Archived-At: Subject: Re: [Anima] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 15:44:25 -0000 --f403045f3f060c1dee05604ec2c4 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson wrote: > > Eric Rescorla wrote: > > The case I am concerned with right now is the case where the attacker > > just imprints the device and then operates it even though it's in the > > victim's network. > > How can they join the victim's network, if the point of the enrollment is > to > provide the device with keys to be able to join the victim's network? > Ah, now I think we're getting somewhere. I had understood the point of the enrollment in this context to be to get it to join the ANIMA fabric, not necessarily the physical network (hence why we have ACP, etc.) Am I just totally missing the point here? -Ekr > > (The exact nature of the keys depends upon how the voucher is used. > In BRSKI it's to bootstrap an EST connection, while in some versions of the > 6tisch, actual 802.15.4 keys are return. NETCONF uses this new trust to > permit the owner to reach in and do configuration with RESTCONF) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --f403045f3f060c1dee05604ec2c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson &= lt;mcr+ietf@sand= elman.ca> wrote:

Eric Rescorla <ekr@rtfm.com> wrot= e:
=C2=A0 =C2=A0 > The case I am concerned with right now is the case where= the attacker
=C2=A0 =C2=A0 > just imprints the device and then operates it even thoug= h it's in the
=C2=A0 =C2=A0 > victim's network.

How can they join the victim's network, if the point of the enro= llment is to
provide the device with keys to be able to join the victim's network?

Ah, now I think we're getting somewh= ere. I had understood the point of the enrollment in this context to be to = get it to join the ANIMA fabric, not necessarily the physical network (henc= e why we have ACP, etc.)

Am I just totally missing= the point here?

-Ekr
=C2=A0

(The exact nature of the keys depends upon how the voucher is used.
In BRSKI it's to bootstrap an EST connection, while in some versions of= the
6tisch, actual 802.15.4 keys are return.=C2=A0 NETCONF uses this new trust = to
permit the owner to reach in and do configuration with RESTCONF)

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




--f403045f3f060c1dee05604ec2c4-- From nobody Thu Dec 14 07:56:14 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA1126CF9 for ; Thu, 14 Dec 2017 07:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3JuR9Crtnf6y for ; Thu, 14 Dec 2017 07:56:11 -0800 (PST) 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 C987E124B0A for ; Thu, 14 Dec 2017 07:56:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A5DF20090; Thu, 14 Dec 2017 10:59:31 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EFE4B80678; Thu, 14 Dec 2017 10:56:08 -0500 (EST) From: Michael Richardson to: draft-ietf-anima-voucher@tools.ietf.org, anima@ietf.org In-Reply-To: <2509.1513177984@obiwan.sandelman.ca> References: <2509.1513177984@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] telechat comments X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:56:13 -0000 --=-=-= Content-Type: text/plain I was trolling the comments during the IESG call. I was distracted and arrived after the telechat for our document :-( I found this in the datatracker just now. As I recall, we moved the specification of the MIME types to BRSKI. Comments from Adam Roach: > Thanks to the authors and working group participants for their work on this > document. I have a somewhat major and handful of minor suggestions for > improvement. > The larger comment is: section 5 talks about a variety of potential > alternate formats and mentions a couple of techniques that might be used to > differentiate among them. I'll note that these techniques relate to MIME > types and related data (filename extensions). The fact that *this* document > doesn't define a MIME type for the CMS-signed-JSON variant will make it > difficult and/or awkward for these future formats to employ these > techniques. For example, if I were to define a COSE-signed-CBOR format and > say "use HTTP Content-Type header fields to tell this apart from > CMS-signed-JSON", I would be in the somewhat odd position of having to > define the MIME-type for CMS-signed-JSON in *that* document, or of coming > up with a very short update to the anima-voucher document that does nothing > other than define its MIME type. > It seems that adding a single sentence to section 5 ("To facilitate these > techniques, this document registers a MIME type for CMS-signed JSON in > section 8.4") plus a registration of a new MIME type along with its > filename extension (e.g., "application/voucher-cms+json" and ".vcj") in > that new section 8.4 would make life much easier for anyone who wants to > define the alternate formats envisioned by section 5. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloynxgACgkQgItw+93Q 3WXcwQf+Myf7MR7R74RGG3sPuS1rPijlNKUtm6jcaiuhBEoJdr0hD7Hs/9zH0/rm 0zLjks9YWa6v37ISf/9rpL0q8ckyUAas/X9L8pNA9Bn8gGxVUxyCkiu2TOMAJ8Je juT+olnt0iQUBjzxYR3NnNYqT2UCoYTE+UK/rd0bjEgRglEr4ku0Ipz+JSwqBkWj zgJHp3kc74A/miL7OxxoC4wXy3LAO3vm3mRH39/09NSemy7fUlVw1IlmpI9WYnPv dYlEaBIf1tuL7vtQs/V51w+0PgFx4geHGirz0AFVYIhV3qDEigsE2NnUgmQe3zia y5zf0mUegy926yaknIhEb4+ExF9qwA== =OR9b -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 14 08:29:17 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868212940B; Thu, 14 Dec 2017 08:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZKirnjIVQ10; Thu, 14 Dec 2017 08:29:12 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5C91273B1; Thu, 14 Dec 2017 08:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14658; q=dns/txt; s=iport; t=1513268952; x=1514478552; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cnZ4kTtOpFBHTKYLOEhNdQHWVx/sYIVw8O2mikUOuHc=; b=XtAqAzzOtb1b+JMCJTEkKCFpMv+Fsb/NVWa7G2mFoRpCn48w5GD1HsX4 q4+EedIO9V1lbA7N+giU76IMILckpYRhSVXsPrxFan58Vlg6uwIbd/oto B+Nf+EA1DIaOWXRR9G94Y4c+gE+zkMZxqRIEh+En1WQQJ+84TlFvCGkjg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAQAMpjJa/5RdJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnRmdCcHg3uKIY8GgX2RSIVOFIIBChgBDIFcgzoCGoRdPxg?= =?us-ascii?q?BAQEBAQEBAQFrKIUkAQEBAwEBIUkCCAMQAgEIDgonAwICAiULFBECBA4FiUZkE?= =?us-ascii?q?KkHgieKXgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg2EEgg6DPymDAoMuAYFEEoM?= =?us-ascii?q?tMYIyBZk8iWkCh3uNLY1thX+NFYkrAhEZAYE6AR85gU5vFToqAYF+hFZ4iUGBF?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208,217";a="330573476" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 16:29:11 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBEGTBO7003156 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 16:29:11 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 10:29:10 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 10:29:10 -0600 From: "Max Pritikin (pritikin)" To: Eric Rescorla CC: Michael Richardson , Toerless Eckert , "draft-ietf-anima-voucher@tools.ietf.org" , Anima WG , IESG Thread-Topic: [Anima] Question on draft-ietf-anima-voucher-06 Thread-Index: AQHTc6KGm0POfqcvzkuEpIsc5mkS+6NAwxOAgAED/ACAAF7MAIAALYYAgAACtgCAAIVCgIAAXMyAgAAo2gCAAADygIAADK2A Date: Thu, 14 Dec 2017 16:29:10 +0000 Message-ID: References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: multipart/alternative; boundary="_000_BB1A60BBF5C64A42A46E72642B5F1434ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 16:29:16 -0000 --_000_BB1A60BBF5C64A42A46E72642B5F1434ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBEZWMgMTQsIDIwMTcsIGF0IDg6NDMgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNv bTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoNCg0KDQpPbiBUaHUsIERlYyAxNCwgMjAx NyBhdCA3OjQwIEFNLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYTxt YWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj4gd3JvdGU6DQoNCkVyaWMgUmVzY29ybGEgPGVr ckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQogICAgPiBUaGUgY2FzZSBJ IGFtIGNvbmNlcm5lZCB3aXRoIHJpZ2h0IG5vdyBpcyB0aGUgY2FzZSB3aGVyZSB0aGUgYXR0YWNr ZXINCiAgICA+IGp1c3QgaW1wcmludHMgdGhlIGRldmljZSBhbmQgdGhlbiBvcGVyYXRlcyBpdCBl dmVuIHRob3VnaCBpdCdzIGluIHRoZQ0KICAgID4gdmljdGltJ3MgbmV0d29yay4NCg0KSG93IGNh biB0aGV5IGpvaW4gdGhlIHZpY3RpbSdzIG5ldHdvcmssIGlmIHRoZSBwb2ludCBvZiB0aGUgZW5y b2xsbWVudCBpcyB0bw0KcHJvdmlkZSB0aGUgZGV2aWNlIHdpdGgga2V5cyB0byBiZSBhYmxlIHRv IGpvaW4gdGhlIHZpY3RpbSdzIG5ldHdvcms/DQoNCkFoLCBub3cgSSB0aGluayB3ZSdyZSBnZXR0 aW5nIHNvbWV3aGVyZS4gSSBoYWQgdW5kZXJzdG9vZCB0aGUgcG9pbnQgb2YgdGhlIGVucm9sbG1l bnQgaW4gdGhpcyBjb250ZXh0IHRvIGJlIHRvIGdldCBpdCB0byBqb2luIHRoZSBBTklNQSBmYWJy aWMsIG5vdCBuZWNlc3NhcmlseSB0aGUgcGh5c2ljYWwgbmV0d29yayAoaGVuY2Ugd2h5IHdlIGhh dmUgQUNQLCBldGMuKQ0KDQpBbSBJIGp1c3QgdG90YWxseSBtaXNzaW5nIHRoZSBwb2ludCBoZXJl Pw0KDQpTbywgbW9yZSBkaXJlY3RseSByZXNwb25kaW5nIHRvIHlvdXIgY29uY2VybjogV2hhdCBo YXBwZW5zIGlmIHRoZSBhdHRhY2tlciDigJxqdXN0IGltcHJpbnRzIHRoZSBkZXZpY2UgYW5kIHRo ZW4gb3BlcmF0ZXMgaXQgZXZlbiB0aG91Z2ggaXRzIGluIHRoZSB2aWN0aW3igJlzIG5ldHdvcmvi gJ0/DQpBbnN3ZXI6DQoNCklmIHRoZSB2ZW5kb3Igc3lzdGVtIGhhcyBzYWxlcyBjaGFubmVsIGlu dGVncmF0aW9uIHRoZW4gdGhlIHZvdWNoZXIgc2lnbmF0dXJlcyBwcm92aWRlIGFuIG9wdGlvbmFs IG1ldGhvZCBvZiBibG9ja2luZyDigJxhdHRhY2tlciBpbXByaW504oCdIChiZWNhdXNlIGl0IGlz IG5vIGxvbmdlciB0cnVzdC1vbi1maXJzdC11c2UpLiBUaGlzIFBSRVZFTlRTIHRoZSBhdHRhY2sg eW914oCZcmUgYXNraW5nIGFib3V0Lg0KSWYgdGhlIHZpY3RpbSBuZXR3b3JrIG9wZXJhdG9yIGhh cyBhcHByb3ByaWF0ZSBpbnZlbnRvcnkgbWFuYWdlbWVudCB0aGVuIEJSU0tJL01BU0EgaW50ZWdy YXRpb24gcHJvdmlkZXMgbG9nZ2luZyBpbnB1dHMgaW50byB0aGF0IHN5c3RlbSB0byBERVRFQ1Qg dGhlIHNjZW5hcmlvIHlvdSBkZXNjcmliZSwgZXZlbiB3aXRob3V0IHNhbGVzIGNoYW5uZWwgaW50 ZWdyYXRpb24uDQoNCk9uY2UgZGV0ZWN0ZWQsIHRoZW4gd2hhdD8gVGhlIEJSU0tJIGRyYWZ0IGhh cyB0aGlzIHRvIHNheSBhYm91dCBpdHMgcHJvdG9jb2wgZmxvdyBhbmQgbmV0d29yayBhY2Nlc3Mg Y29udHJvbDoNCg0KZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhLTA5Og0K DQogICBUaGlzIGRvY3VtZW50IHByZXN1bWVzIHRoYXQgbmV0d29yayBhY2Nlc3MgY29udHJvbCBo YXMgZWl0aGVyIGFscmVhZHkNCiAgIG9jY3VycmVkLCBpcyBub3QgcmVxdWlyZWQsIG9yIGlzIGlu dGVncmF0ZWQgYnkgdGhlIHByb3h5IGFuZA0KICAgcmVnaXN0cmFyIGluIHN1Y2ggYSB3YXkgdGhh dCB0aGUgZGV2aWNlIGl0c2VsZiBkb2VzIG5vdCBuZWVkIHRvIGJlDQogICBhd2FyZSBvZiB0aGUg ZGV0YWlscy4gIEFsdGhvdWdoIHRoZSB1c2Ugb2YgYW4gWC41MDkgSW5pdGlhbCBEZXZpY2UNCiAg IElkZW50aXR5IGlzIGNvbnNpc3RhbnQgd2l0aCBJRUVFIDgwMi4xQVIgW0lEZXZJRDxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWlu ZnJhLTA5I3JlZi1JRGV2SUQ+XSwgYW5kIGFsbG93cyBmb3INCiAgIGFsaWdubWVudCB3aXRoIDgw Mi4xWCBuZXR3b3JrIGFjY2VzcyBjb250cm9sIG1ldGhvZHMsIGl0cyB1c2UgaGVyZSBpcw0KICAg Zm9yIFBsZWRnZSBhdXRoZW50aWNhdGlvbiByYXRoZXIgdGhhbiBuZXR3b3JrIGFjY2VzcyBjb250 cm9sLg0KICAgSW50ZWdyYXRpbmcgdGhpcyBwcm90b2NvbCB3aXRoIG5ldHdvcmsgYWNjZXNzIGNv bnRyb2wsIHBlcmhhcHMgYXMgYW4NCiAgIEV4dGVuc2libGUgQXV0aGVudGljYXRpb24gUHJvdG9j b2wgKEVBUCkgbWV0aG9kIChzZWUgW1JGQzM3NDg8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzM3NDg+XSksIGlzDQogICBvdXQtb2Ytc2NvcGUuDQoNCkl0cyBldmVuIG1vcmUgb3V0IG9m IHNjb3BlIGZvciB0aGUgdm91Y2hlciBpdHNlbGYgc2luY2UgdGhhdCBpcyBhIG1zZyBmb3JtYXQg Zm9yIOKAnHdobyBzaG91bGQgdGhlIGRldmljZSB0cnVzdOKAnSBhbmQgdG8gdHJpZ2dlciBlbnJv bGxtZW50IGJ1dCBpcyBldmVuIGZ1cnRoZXIgcmVtb3ZlZCBmcm9tIG5ldHdvcmsgYWNjZXNzIGNv bnRyb2wuDQoNCkEgcG90ZW50aWFsIGludGVncmF0aW9uIGlzIHRvIHVzZSBBTklNQSBvciBCUlNL SSB0byBtYW5hZ2UgZGV2aWNlIGVucm9sbG1lbnQgYW5kIGNyZWRlbnRpYWwgZnJvbSBhIHF1YXJh bnRpbmUgbmV0d29yay4gVGhlIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2wgY291bGQgYmUgY29uZmln dXJlZCB0byBzZWdyZWdhdGUgYWxsIGRldmljZXMgdGhhdCBhcmUgbm90IGVucm9sbGVkIChwZXJo YXBzIGludG8gYSB0cnVlIHF1YXJhbnRpbmUgbmV0d29yayBvciBtYXliZSBqdXN0IHBhc3MgdGhl bSBhbGwgdGhyb3VnaCB0byBhIGNhcmVmdWxseSBtYW5hZ2VkIGRteiBvciDigKYgd2hhdGV2ZXIp LiBJZiB0aGUgZGV2aWNlIGVucm9sbHMgc3VjY2Vzc2Z1bGx5IHRoZW4geW91IGdldCBvbiB0aGUg 4oCccmVhbOKAnSBuZXR3b3JrLiBJbiB5b3VyIHNjZW5hcmlvIHRoZW4gdGhlIGF0dGFja2VyIGdh aW4gY29udHJvbCBvdmVyIGEgZGV2aWNlIHRoYXQgaXMgdW50cnVzdGVkIGFuZCBwbGFjZWQgYXBw cm9wcmlhdGVseSBieSB0aGUgbmV0d29yayBhY2Nlc3MgY29udHJvbCBzeXN0ZW0uIEJ1dCBhcyBu b3RlZCwgcHJvdmlkaW5nIHRoZSB0b29scyBmb3IgdGhpcyBpcyBkaWZmZXJlbnQgdGhhbiBhY3R1 YWxseSBkZWZpbmluZyB0aGF0IGludGVncmF0aW9uLiBJIGVuY291cmFnZSB0aGUgbmV0d29yayBh Y2Nlc3MgY29udHJvbCBmb2xrcyB0byBhZGRyZXNzIHRoZXNlIHR5cGVzIG9mIGNvbmNlcm5zLg0K DQotIG1heA0KDQoNCi1Fa3INCg0KDQooVGhlIGV4YWN0IG5hdHVyZSBvZiB0aGUga2V5cyBkZXBl bmRzIHVwb24gaG93IHRoZSB2b3VjaGVyIGlzIHVzZWQuDQpJbiBCUlNLSSBpdCdzIHRvIGJvb3Rz dHJhcCBhbiBFU1QgY29ubmVjdGlvbiwgd2hpbGUgaW4gc29tZSB2ZXJzaW9ucyBvZiB0aGUNCjZ0 aXNjaCwgYWN0dWFsIDgwMi4xNS40IGtleXMgYXJlIHJldHVybi4gIE5FVENPTkYgdXNlcyB0aGlz IG5ldyB0cnVzdCB0bw0KcGVybWl0IHRoZSBvd25lciB0byByZWFjaCBpbiBhbmQgZG8gY29uZmln dXJhdGlvbiB3aXRoIFJFU1RDT05GKQ0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVU RkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jciUyQklFVEZAc2FuZGVsbWFuLmNhPj4sIFNhbmRlbG1h biBTb2Z0d2FyZSBXb3Jrcw0KIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFuaW1hIG1haWxp bmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1hQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= --_000_BB1A60BBF5C64A42A46E72642B5F1434ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMg MTQsIDIwMTcsIGF0IDg6NDMgQU0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpl a3JAcnRmbS5jb20iIGNsYXNzPSIiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgRGVj IDE0LCAyMDE3IGF0IDc6NDAgQU0sIE1pY2hhZWwgUmljaGFyZHNvbiA8c3BhbiBkaXI9Imx0ciIg Y2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2Ei IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPHNwYW4gY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KRXJpYyBS ZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgY2xhc3M9IiI+ZWtyQHJ0 Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRo ZSBjYXNlIEkgYW0gY29uY2VybmVkIHdpdGggcmlnaHQgbm93IGlzIHRoZSBjYXNlIHdoZXJlIHRo ZSBhdHRhY2tlcjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBqdXN0IGltcHJpbnRz IHRoZSBkZXZpY2UgYW5kIHRoZW4gb3BlcmF0ZXMgaXQgZXZlbiB0aG91Z2ggaXQncyBpbiB0aGU8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZndDsgdmljdGltJ3MgbmV0d29yay48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L3NwYW4+SG93IGNhbiB0aGV5IGpvaW4gdGhlIHZpY3Rp bSdzIG5ldHdvcmssIGlmIHRoZSBwb2ludCBvZiB0aGUgZW5yb2xsbWVudCBpcyB0bzxiciBjbGFz cz0iIj4NCnByb3ZpZGUgdGhlIGRldmljZSB3aXRoIGtleXMgdG8gYmUgYWJsZSB0byBqb2luIHRo ZSB2aWN0aW0ncyBuZXR3b3JrPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFoLCBub3cgSSB0aGlu ayB3ZSdyZSBnZXR0aW5nIHNvbWV3aGVyZS4gSSBoYWQgdW5kZXJzdG9vZCB0aGUgcG9pbnQgb2Yg dGhlIGVucm9sbG1lbnQgaW4gdGhpcyBjb250ZXh0IHRvIGJlIHRvIGdldCBpdCB0byBqb2luIHRo ZSBBTklNQSBmYWJyaWMsIG5vdCBuZWNlc3NhcmlseSB0aGUgcGh5c2ljYWwgbmV0d29yayAoaGVu Y2Ugd2h5IHdlIGhhdmUgQUNQLCBldGMuKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW0gSSBqdXN0IHRvdGFsbHkgbWlzc2luZyB0aGUg cG9pbnQgaGVyZT88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+U28sIG1vcmUgZGlyZWN0 bHkgcmVzcG9uZGluZyB0byB5b3VyIGNvbmNlcm46IFdoYXQgaGFwcGVucyBpZiB0aGUgYXR0YWNr ZXIg4oCcanVzdCBpbXByaW50cyB0aGUgZGV2aWNlIGFuZCB0aGVuIG9wZXJhdGVzIGl0IGV2ZW4g dGhvdWdoIGl0cyBpbiB0aGUgdmljdGlt4oCZcyBuZXR3b3Jr4oCdPzwvZGl2Pg0KPGRpdj5BbnN3 ZXI6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JZiB0aGUgdmVuZG9y IHN5c3RlbSBoYXMgc2FsZXMgY2hhbm5lbCBpbnRlZ3JhdGlvbiB0aGVuIHRoZSB2b3VjaGVyIHNp Z25hdHVyZXMgcHJvdmlkZSBhbiBvcHRpb25hbCBtZXRob2Qgb2YgYmxvY2tpbmcg4oCcYXR0YWNr ZXIgaW1wcmludOKAnSAoYmVjYXVzZSBpdCBpcyBubyBsb25nZXIgdHJ1c3Qtb24tZmlyc3QtdXNl KS4gVGhpcyBQUkVWRU5UUyB0aGUgYXR0YWNrIHlvdeKAmXJlIGFza2luZyBhYm91dC4mbmJzcDs8 L2Rpdj4NCjxkaXY+SWYgdGhlIHZpY3RpbSBuZXR3b3JrIG9wZXJhdG9yIGhhcyBhcHByb3ByaWF0 ZSBpbnZlbnRvcnkgbWFuYWdlbWVudCB0aGVuIEJSU0tJL01BU0EgaW50ZWdyYXRpb24gcHJvdmlk ZXMgbG9nZ2luZyBpbnB1dHMgaW50byB0aGF0IHN5c3RlbSB0byBERVRFQ1QgdGhlIHNjZW5hcmlv IHlvdSBkZXNjcmliZSwgZXZlbiB3aXRob3V0IHNhbGVzIGNoYW5uZWwgaW50ZWdyYXRpb24uJm5i c3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5PbmNlIGRldGVjdGVk LCB0aGVuIHdoYXQ/IFRoZSBCUlNLSSBkcmFmdCBoYXMgdGhpcyB0byBzYXkgYWJvdXQgaXRzIHBy b3RvY29sIGZsb3cgYW5kIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2w6PC9kaXY+DQo8ZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBw aW5nLWtleWluZnJhLTA5OjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4 OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdl OyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsi PiAgIFRoaXMgZG9jdW1lbnQgcHJlc3VtZXMgdGhhdCBuZXR3b3JrIGFjY2VzcyBjb250cm9sIGhh cyBlaXRoZXIgYWxyZWFkeQ0KICAgb2NjdXJyZWQsIGlzIG5vdCByZXF1aXJlZCwgb3IgaXMgaW50 ZWdyYXRlZCBieSB0aGUgcHJveHkgYW5kDQogICByZWdpc3RyYXIgaW4gc3VjaCBhIHdheSB0aGF0 IHRoZSBkZXZpY2UgaXRzZWxmIGRvZXMgbm90IG5lZWQgdG8gYmUNCiAgIGF3YXJlIG9mIHRoZSBk ZXRhaWxzLiAgQWx0aG91Z2ggdGhlIHVzZSBvZiBhbiBYLjUwOSBJbml0aWFsIERldmljZQ0KICAg SWRlbnRpdHkgaXMgY29uc2lzdGFudCB3aXRoIElFRUUgODAyLjFBUiBbPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlp bmZyYS0wOSNyZWYtSURldklEIiB0aXRsZT0iJnF1b3Q7SUVFRSA4MDIuMUFSIFNlY3VyZSBEZXZp Y2UgSWRlbnRpZmllciZxdW90OyIgY2xhc3M9IiI+SURldklEPC9hPl0sIGFuZCBhbGxvd3MgZm9y DQogICBhbGlnbm1lbnQgd2l0aCA4MDIuMVggbmV0d29yayBhY2Nlc3MgY29udHJvbCBtZXRob2Rz LCBpdHMgdXNlIGhlcmUgaXMNCiAgIGZvciBQbGVkZ2UgYXV0aGVudGljYXRpb24gcmF0aGVyIHRo YW4gbmV0d29yayBhY2Nlc3MgY29udHJvbC4NCiAgIEludGVncmF0aW5nIHRoaXMgcHJvdG9jb2wg d2l0aCBuZXR3b3JrIGFjY2VzcyBjb250cm9sLCBwZXJoYXBzIGFzIGFuDQogICBFeHRlbnNpYmxl IEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIChFQVApIG1ldGhvZCAoc2VlIFs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzc0OCIgdGl0bGU9IiZxdW90O0V4dGVuc2libGUg QXV0aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkmcXVvdDsiIGNsYXNzPSIiPlJGQzM3NDg8L2E+ XSksIGlzDQogICBvdXQtb2Ytc2NvcGUuPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxk aXY+SXRzIGV2ZW4gbW9yZSBvdXQgb2Ygc2NvcGUgZm9yIHRoZSB2b3VjaGVyIGl0c2VsZiBzaW5j ZSB0aGF0IGlzIGEgbXNnIGZvcm1hdCBmb3Ig4oCcd2hvIHNob3VsZCB0aGUgZGV2aWNlIHRydXN0 4oCdIGFuZCB0byB0cmlnZ2VyIGVucm9sbG1lbnQgYnV0IGlzIGV2ZW4gZnVydGhlciByZW1vdmVk IGZyb20gbmV0d29yayBhY2Nlc3MgY29udHJvbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+QSBwb3RlbnRpYWwgaW50ZWdyYXRpb24gaXMg dG8gdXNlIEFOSU1BIG9yIEJSU0tJIHRvIG1hbmFnZSBkZXZpY2UgZW5yb2xsbWVudCBhbmQgY3Jl ZGVudGlhbCBmcm9tIGEgcXVhcmFudGluZSBuZXR3b3JrLiBUaGUgbmV0d29yayBhY2Nlc3MgY29u dHJvbCBjb3VsZCBiZSBjb25maWd1cmVkIHRvIHNlZ3JlZ2F0ZSBhbGwgZGV2aWNlcyB0aGF0IGFy ZSBub3QgZW5yb2xsZWQgKHBlcmhhcHMgaW50byBhIHRydWUgcXVhcmFudGluZSBuZXR3b3JrDQog b3IgbWF5YmUganVzdCBwYXNzIHRoZW0gYWxsIHRocm91Z2ggdG8gYSBjYXJlZnVsbHkgbWFuYWdl ZCBkbXogb3Ig4oCmIHdoYXRldmVyKS4gSWYgdGhlIGRldmljZSBlbnJvbGxzIHN1Y2Nlc3NmdWxs eSB0aGVuIHlvdSBnZXQgb24gdGhlIOKAnHJlYWzigJ0gbmV0d29yay4gSW4geW91ciBzY2VuYXJp byB0aGVuIHRoZSBhdHRhY2tlciBnYWluIGNvbnRyb2wgb3ZlciBhIGRldmljZSB0aGF0IGlzIHVu dHJ1c3RlZCBhbmQgcGxhY2VkIGFwcHJvcHJpYXRlbHkgYnkNCiB0aGUgbmV0d29yayBhY2Nlc3Mg Y29udHJvbCBzeXN0ZW0uIEJ1dCBhcyBub3RlZCwgcHJvdmlkaW5nIHRoZSB0b29scyBmb3IgdGhp cyBpcyBkaWZmZXJlbnQgdGhhbiBhY3R1YWxseSBkZWZpbmluZyB0aGF0IGludGVncmF0aW9uLiBJ IGVuY291cmFnZSB0aGUgbmV0d29yayBhY2Nlc3MgY29udHJvbCBmb2xrcyB0byBhZGRyZXNzIHRo ZXNlIHR5cGVzIG9mIGNvbmNlcm5zLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+LSBtYXg8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LUVrcjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPg0KPGJyIGNsYXNzPSIiPg0KKFRoZSBleGFjdCBuYXR1cmUgb2YgdGhl IGtleXMgZGVwZW5kcyB1cG9uIGhvdyB0aGUgdm91Y2hlciBpcyB1c2VkLjxiciBjbGFzcz0iIj4N CkluIEJSU0tJIGl0J3MgdG8gYm9vdHN0cmFwIGFuIEVTVCBjb25uZWN0aW9uLCB3aGlsZSBpbiBz b21lIHZlcnNpb25zIG9mIHRoZTxiciBjbGFzcz0iIj4NCjZ0aXNjaCwgYWN0dWFsIDgwMi4xNS40 IGtleXMgYXJlIHJldHVybi4mbmJzcDsgTkVUQ09ORiB1c2VzIHRoaXMgbmV3IHRydXN0IHRvPGJy IGNsYXNzPSIiPg0KcGVybWl0IHRoZSBvd25lciB0byByZWFjaCBpbiBhbmQgZG8gY29uZmlndXJh dGlvbiB3aXRoIFJFU1RDT05GKTxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8 ZGl2IGNsYXNzPSJoNSI+PGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQpNaWNoYWVsIFJp Y2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3IlMkJJRVRGQHNhbmRlbG1hbi5jYSIgY2xh c3M9IiI+bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4gU29mdHdh cmUgV29ya3M8YnIgY2xhc3M9IiI+DQombmJzcDstPSBJUHY2IElvVCBjb25zdWx0aW5nID0tPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyIGNsYXNzPSIiPg0KQW5pbWEgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0ibWFpbHRvOkFuaW1hQGlldGYub3JnIiBjbGFzcz0iIj5BbmltYUBpZXRmLm9yZzwvYT48YnIg Y2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BB1A60BBF5C64A42A46E72642B5F1434ciscocom_-- From nobody Thu Dec 14 08:33:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57542129439 for ; Thu, 14 Dec 2017 08:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 NZjj1RbX8Rhk for ; Thu, 14 Dec 2017 08:33:35 -0800 (PST) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 9A37C12943B for ; Thu, 14 Dec 2017 08:33:34 -0800 (PST) Received: by mail-yb0-x22f.google.com with SMTP id h28so3905987ybj.5 for ; Thu, 14 Dec 2017 08:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JmVQTDXiLtTGJL+wQPvb1GraepskPTfQI8rTUItPVTc=; b=TRQ9kueyntQ7i9Bcsmiv2osIYeQRQZbnaYmIh7uNB8NDXrUfj+pLku/kzXutwZgy8q hY7qIl+CnXqcT2Ag2X06XCmd7R7aqTYO03DUUlvDgsVunM1TT6D1zURCKX/obttUYPwe 11xgwXeaNzVC1P8wQ/3MVn0zq1w1H0x0KKJDPT7NB+1jdlHcqyIJsuxZNJz2WN1GKsUU SXCLRNV4ddO8rtMVOR3PBLYtZ7k5X849AiJnRLHkNN5BWgcQ0T0Ysrk5C/KP2qD8DGVS +USG2SNgGGLIoI7muRwNraQE93A75XX7KSIKBHOSz83ixHLolGZ2CYhQxnNEyZCcQ0WM ZpJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JmVQTDXiLtTGJL+wQPvb1GraepskPTfQI8rTUItPVTc=; b=JFkYsOxj3XvAUi5poXfFGAdmsK92R1ZAnQadfpWCM5cIAiCTS6oMq3X7vCLloOs9g5 SyHZ0NNPUkzNfYymquIsgHmxY00yGYX5uy65MClsjcSO+TUdyWtGkLOixWQaLdoRTBvE Har7eqsZrFuUBK2ARFdD1UHRiD5YVjkH3i9c2Rq7yVGafICOx8Wbrdv8OCftFSUqJ4iM bDVUj9Rxvx3SSPzi1PFh1nYRgnRrTTd68pjOEeepFSJkcxFUx5KFGCwHuPJeqgEl0Dus y/L3UlEE4T91WERZppGdg0/Q+K8EuIaxNAaRRdrdQNWNq8NxIeA2eaETG1ZMyzwCGDqR 9igA== X-Gm-Message-State: AKGB3mKO43aqXMUOs1r7ce+KoD/kIL5KylY6EvzYlHzPSBNjGRb5Qjc3 vuukkUp4OTYPySSzbOAV88cTiNg8Mhbf57jUNbeK2w== X-Google-Smtp-Source: ACJfBovAmutBDwGnl1SLTWcm3FFOXhtoOe+PqzKcQIXQmFeCEy5fBGNAPfuoj3T1NdfN807sdKYLCPe41f9blIjZMm0= X-Received: by 10.129.48.202 with SMTP id w193mr4787795yww.378.1513269213790; Thu, 14 Dec 2017 08:33:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 14 Dec 2017 08:32:53 -0800 (PST) In-Reply-To: References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> From: Eric Rescorla Date: Thu, 14 Dec 2017 08:32:53 -0800 Message-ID: To: "Max Pritikin (pritikin)" Cc: Michael Richardson , Toerless Eckert , "draft-ietf-anima-voucher@tools.ietf.org" , Anima WG , IESG Content-Type: multipart/alternative; boundary="001a11409cfaf02ad105604f7136" Archived-At: Subject: Re: [Anima] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 16:33:38 -0000 --001a11409cfaf02ad105604f7136 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) wrote: > > On Dec 14, 2017, at 8:43 AM, Eric Rescorla wrote: > > > > On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson > wrote: > >> >> Eric Rescorla wrote: >> > The case I am concerned with right now is the case where the >> attacker >> > just imprints the device and then operates it even though it's in >> the >> > victim's network. >> >> How can they join the victim's network, if the point of the enrollment i= s >> to >> provide the device with keys to be able to join the victim's network? >> > > Ah, now I think we're getting somewhere. I had understood the point of th= e > enrollment in this context to be to get it to join the ANIMA fabric, not > necessarily the physical network (hence why we have ACP, etc.) > > Am I just totally missing the point here? > > > So, more directly responding to your concern: What happens if the attacke= r > =E2=80=9Cjust imprints the device and then operates it even though its in= the > victim=E2=80=99s network=E2=80=9D? > Answer: > > If the vendor system has sales channel integration then the voucher > signatures provide an optional method of blocking =E2=80=9Cattacker impri= nt=E2=80=9D > (because it is no longer trust-on-first-use). This PREVENTS the attack > you=E2=80=99re asking about. > If the victim network operator has appropriate inventory management then > BRSKI/MASA integration provides logging inputs into that system to DETECT > the scenario you describe, even without sales channel integration. > So if neither of these cases applies, then the attack succeeds? To be clear, I'm not saying this is a defect in the protocol. I don't know how to fix it. I'm just trying to get clear. -Ekr > > Once detected, then what? The BRSKI draft has this to say about its > protocol flow and network access control: > > draft-ietf-anima-bootstrapping-keyinfra-09: > > This document presumes that network access control has either already > occurred, is not required, or is integrated by the proxy and > registrar in such a way that the device itself does not need to be > aware of the details. Although the use of an X.509 Initial Device > Identity is consistant with IEEE 802.1AR [IDevID ], and allows= for > alignment with 802.1X network access control methods, its use here is > for Pledge authentication rather than network access control. > Integrating this protocol with network access control, perhaps as an > Extensible Authentication Protocol (EAP) method (see [RFC3748 ]), is > out-of-scope. > > Its even more out of scope for the voucher itself since that is a msg > format for =E2=80=9Cwho should the device trust=E2=80=9D and to trigger e= nrollment but is > even further removed from network access control. > > A potential integration is to use ANIMA or BRSKI to manage device > enrollment and credential from a quarantine network. The network access > control could be configured to segregate all devices that are not enrolle= d > (perhaps into a true quarantine network or maybe just pass them all throu= gh > to a carefully managed dmz or =E2=80=A6 whatever). If the device enrolls > successfully then you get on the =E2=80=9Creal=E2=80=9D network. In your = scenario then the > attacker gain control over a device that is untrusted and placed > appropriately by the network access control system. But as noted, providi= ng > the tools for this is different than actually defining that integration. = I > encourage the network access control folks to address these types of > concerns. > > - max > > > -Ekr > > >> >> (The exact nature of the keys depends upon how the voucher is used. >> In BRSKI it's to bootstrap an EST connection, while in some versions of >> the >> 6tisch, actual 802.15.4 keys are return. NETCONF uses this new trust to >> permit the owner to reach in and do configuration with RESTCONF) >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> >> > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > > --001a11409cfaf02ad105604f7136 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) <pritikin@ci= sco.com> wrote:

On Dec 14, 2017, at 8:43 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Dec 14, 2017 at 7:40 AM, Michael Richard= son <mcr+ietf@san= delman.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 > The case I am concerned with right now is the case where= the attacker
=C2=A0 =C2=A0 > just imprints the device and then operates it even thoug= h it's in the
=C2=A0 =C2=A0 > victim's network.

How can they join the victim's network, if the point of the enro= llment is to
provide the device with keys to be able to join the victim's network?

Ah, now I think we're getting somewhere. I had understood the poin= t of the enrollment in this context to be to get it to join the ANIMA fabri= c, not necessarily the physical network (hence why we have ACP, etc.)

Am I just totally missing the point here?

So, more directly responding to your concern: What happens if t= he attacker =E2=80=9Cjust imprints the device and then operates it even tho= ugh its in the victim=E2=80=99s network=E2=80=9D?
Answer:

If the vendor system has sales channel integration then the voucher si= gnatures provide an optional method of blocking =E2=80=9Cattacker imprint= =E2=80=9D (because it is no longer trust-on-first-use). This PREVENTS the a= ttack you=E2=80=99re asking about.=C2=A0
If the victim network operator has appropriate inventory management th= en BRSKI/MASA integration provides logging inputs into that system to DETEC= T the scenario you describe, even without sales channel integration.=C2=A0<= /div>

So if neither of these ca= ses applies, then the attack succeeds?

To be clear= , I'm not saying this is a defect in the protocol. I don't know how= to fix it. I'm just trying to get clear.

-Ekr=
=C2=A0

Once detected, then what? The BRSKI draft has this to say about its pr= otocol flow and network access control:

draft-ietf-anima-bootstrapping-keyinfra-09:
   This docum=
ent presumes that network access control has either already
   occurred, is not required, or is integrated by the proxy and
   registrar in such a way that the device itself does not need to be
   aware of the details.  Although the use of an X.509 Initial Device
   Identity is consistant with IEEE 802.1AR [IDevID], and allows for
   alignment with 802.1X network access control methods, its use here is
   for Pledge authentication rather than network access control.
   Integrating this protocol with network access control, perhaps as an
   Extensible Authentication Protocol (EAP) method (see [RFC3748]), is
   out-of-scope.
Its even more out of scope for the voucher itself since that is a msg = format for =E2=80=9Cwho should the device trust=E2=80=9D and to trigger enr= ollment but is even further removed from network access control.

A potential integration is to use ANIMA or BRSKI to manage device enro= llment and credential from a quarantine network. The network access control= could be configured to segregate all devices that are not enrolled (perhap= s into a true quarantine network or maybe just pass them all through to a carefully managed dmz or =E2=80= =A6 whatever). If the device enrolls successfully then you get on the =E2= =80=9Creal=E2=80=9D network. In your scenario then the attacker gain contro= l over a device that is untrusted and placed appropriately by the network access control system. But as noted, providing the tools for t= his is different than actually defining that integration. I encourage the n= etwork access control folks to address these types of concerns.

- max


-Ekr
=C2=A0

(The exact nature of the keys depends upon how the voucher is used.
In BRSKI it's to bootstrap an EST connection, while in some versions of= the
6tisch, actual 802.15.4 keys are return.=C2=A0 NETCONF uses this new trust = to
permit the owner to reach in and do configuration with RESTCONF)

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




 _______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima


--001a11409cfaf02ad105604f7136-- From nobody Thu Dec 14 08:36:24 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6001273B1; Thu, 14 Dec 2017 08:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 K5mkoXetg2av; Thu, 14 Dec 2017 08:36:15 -0800 (PST) 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 2213C127337; Thu, 14 Dec 2017 08:36:15 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7D47D20090; Thu, 14 Dec 2017 11:39:36 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2A42A81D85; Thu, 14 Dec 2017 11:36:14 -0500 (EST) From: Michael Richardson To: Eric Rescorla cc: Toerless Eckert , Anima WG , "Max Pritikin \(pritikin\)" , "draft-ietf-anima-voucher\@tools.ietf.org" , IESG In-Reply-To: References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 16:36:18 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: mcr> How can they join the victim's network, if the point of the mcr> enrollment is to provide the device with keys to be able to join the mcr> victim's network? > Ah, now I think we're getting somewhere. I had understood the point of > the enrollment in this context to be to get it to join the ANIMA > fabric, not necessarily the physical network (hence why we have ACP, > etc.) > Am I just totally missing the point here? Yes, in the BRSKI context of ISP provisioned autonomic networks, it's to join the ACP fabric. If it's a BFR/etc. then it joined the physical network by being physically plugging in. The port that it is physically plugged into might have some protection. We also imagine that there are only two devices on that piece of (dark?) fiber. We don't think that audit-vouchers will be used for larger value equipment. In other contexts, (6tisch, light bulbs) which are wireless, then there has to be some "join" network on which the device connects. The details of that are not in the voucher document, because it has to be in the specifics of the network. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloyqH0ACgkQgItw+93Q 3WWkBAf2OhU3CTscFlQEzIRygIttyI3l3ehlfuQHPgvicEMWdODR+bpjPCIMblAo znnGho1h3//17gIcCRirXO8w2xIfBt9G9A8lmrWLJhdZKj5NMNfxT3und4F5EJxh zVUMAphu6ZPpCHvNS3pL2APPOHIOeZwJLt109A10u9U88LUFV/3tCfmyvQV8RFh6 Zdug12sCksrNdCV2CBRnxf2oX5u+9tVZ2zNr4Yy90gA6KbbXH5TOgtNidnFK5H7l qgd9BjP8NC1dE9xgaA30lbYwb8JLgFY8bfFf8L7MpDBqw8+mB5gGmB1AXHNAC5cC qV8u2mUJ5irzbubT1hj4tug3IgkJ =0mr4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 14 09:15:45 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD2128961; Thu, 14 Dec 2017 09:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNLK4kXlLz_Y; Thu, 14 Dec 2017 09:15:35 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C68127871; Thu, 14 Dec 2017 09:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20334; q=dns/txt; s=iport; t=1513271735; x=1514481335; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FcvJAWkq0D7rs3ET3E2BVLS+XnRBMof4JvzM4u80eTY=; b=Ywa+ZF/mVSiYk7nxoG5P4Cnee4Y2PvQKfQEFx9GEMl139FHajqqWv60D XJT5dTZHcWC6Rc0fHGH9/VtxcKJKSfyieIgj+K64LB+KQgL5GCG8+GqIp F0OTovGZspovEmpFeAwmXSIYzicOmr/uDAy3k00rJh7tThvTz0MaZt/H1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAQAssTJa/49dJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnRmdCcHg3uKIY8GgX2RSIVOFIIBChgBDIFcgzoCGoRdPxg?= =?us-ascii?q?BAQEBAQEBAQFrKIUkAQEBAwEBIUkCCAMQAgEIDgonAwICAiULFBECBA4FH4knZ?= =?us-ascii?q?BCpDoInil4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNhBIIOgz8pgwKDLgGBRAQ?= =?us-ascii?q?Ogy0xgjIFmTyJaQKHe40tjW2Ff40ViSsCERkBgToBHzmBTm8VOioBgX6CGoI8e?= =?us-ascii?q?IgPgTKBFQEBAQ?= X-IronPort-AV: E=Sophos; i="5.45,400,1508803200"; d="scan'208,217"; a="44685103" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 17:15:34 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vBEHFXSd011592 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 17:15:33 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 11:15:33 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 11:15:33 -0600 From: "Max Pritikin (pritikin)" To: Eric Rescorla CC: Michael Richardson , Toerless Eckert , "draft-ietf-anima-voucher@tools.ietf.org" , Anima WG , IESG Thread-Topic: [Anima] Question on draft-ietf-anima-voucher-06 Thread-Index: AQHTc6KGm0POfqcvzkuEpIsc5mkS+6NAwxOAgAED/ACAAF7MAIAALYYAgAACtgCAAIVCgIAAXMyAgAAo2gCAAADygIAADK2AgAABEoCAAAvkAA== Date: Thu, 14 Dec 2017 17:15:33 +0000 Message-ID: <29D1A62E-B717-4E62-85FF-BA194AB2DEDB@cisco.com> References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: multipart/alternative; boundary="_000_29D1A62EB7174E6285FFBA194AB2DEDBciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 17:15:38 -0000 --_000_29D1A62EB7174E6285FFBA194AB2DEDBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBEZWMgMTQsIDIwMTcsIGF0IDk6MzIgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNv bTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoNCg0KDQpPbiBUaHUsIERlYyAxNCwgMjAx NyBhdCA4OjI5IEFNLCBNYXggUHJpdGlraW4gKHByaXRpa2luKSA8cHJpdGlraW5AY2lzY28uY29t PG1haWx0bzpwcml0aWtpbkBjaXNjby5jb20+PiB3cm90ZToNCg0KT24gRGVjIDE0LCAyMDE3LCBh dCA4OjQzIEFNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNv bT4+IHdyb3RlOg0KDQoNCg0KT24gVGh1LCBEZWMgMTQsIDIwMTcgYXQgNzo0MCBBTSwgTWljaGFl bCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitpZXRmQHNhbmRl bG1hbi5jYT4+IHdyb3RlOg0KDQpFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVr ckBydGZtLmNvbT4+IHdyb3RlOg0KICAgID4gVGhlIGNhc2UgSSBhbSBjb25jZXJuZWQgd2l0aCBy aWdodCBub3cgaXMgdGhlIGNhc2Ugd2hlcmUgdGhlIGF0dGFja2VyDQogICAgPiBqdXN0IGltcHJp bnRzIHRoZSBkZXZpY2UgYW5kIHRoZW4gb3BlcmF0ZXMgaXQgZXZlbiB0aG91Z2ggaXQncyBpbiB0 aGUNCiAgICA+IHZpY3RpbSdzIG5ldHdvcmsuDQoNCkhvdyBjYW4gdGhleSBqb2luIHRoZSB2aWN0 aW0ncyBuZXR3b3JrLCBpZiB0aGUgcG9pbnQgb2YgdGhlIGVucm9sbG1lbnQgaXMgdG8NCnByb3Zp ZGUgdGhlIGRldmljZSB3aXRoIGtleXMgdG8gYmUgYWJsZSB0byBqb2luIHRoZSB2aWN0aW0ncyBu ZXR3b3JrPw0KDQpBaCwgbm93IEkgdGhpbmsgd2UncmUgZ2V0dGluZyBzb21ld2hlcmUuIEkgaGFk IHVuZGVyc3Rvb2QgdGhlIHBvaW50IG9mIHRoZSBlbnJvbGxtZW50IGluIHRoaXMgY29udGV4dCB0 byBiZSB0byBnZXQgaXQgdG8gam9pbiB0aGUgQU5JTUEgZmFicmljLCBub3QgbmVjZXNzYXJpbHkg dGhlIHBoeXNpY2FsIG5ldHdvcmsgKGhlbmNlIHdoeSB3ZSBoYXZlIEFDUCwgZXRjLikNCg0KQW0g SSBqdXN0IHRvdGFsbHkgbWlzc2luZyB0aGUgcG9pbnQgaGVyZT8NCg0KU28sIG1vcmUgZGlyZWN0 bHkgcmVzcG9uZGluZyB0byB5b3VyIGNvbmNlcm46IFdoYXQgaGFwcGVucyBpZiB0aGUgYXR0YWNr ZXIg4oCcanVzdCBpbXByaW50cyB0aGUgZGV2aWNlIGFuZCB0aGVuIG9wZXJhdGVzIGl0IGV2ZW4g dGhvdWdoIGl0cyBpbiB0aGUgdmljdGlt4oCZcyBuZXR3b3Jr4oCdPw0KQW5zd2VyOg0KDQpJZiB0 aGUgdmVuZG9yIHN5c3RlbSBoYXMgc2FsZXMgY2hhbm5lbCBpbnRlZ3JhdGlvbiB0aGVuIHRoZSB2 b3VjaGVyIHNpZ25hdHVyZXMgcHJvdmlkZSBhbiBvcHRpb25hbCBtZXRob2Qgb2YgYmxvY2tpbmcg 4oCcYXR0YWNrZXIgaW1wcmludOKAnSAoYmVjYXVzZSBpdCBpcyBubyBsb25nZXIgdHJ1c3Qtb24t Zmlyc3QtdXNlKS4gVGhpcyBQUkVWRU5UUyB0aGUgYXR0YWNrIHlvdeKAmXJlIGFza2luZyBhYm91 dC4NCklmIHRoZSB2aWN0aW0gbmV0d29yayBvcGVyYXRvciBoYXMgYXBwcm9wcmlhdGUgaW52ZW50 b3J5IG1hbmFnZW1lbnQgdGhlbiBCUlNLSS9NQVNBIGludGVncmF0aW9uIHByb3ZpZGVzIGxvZ2dp bmcgaW5wdXRzIGludG8gdGhhdCBzeXN0ZW0gdG8gREVURUNUIHRoZSBzY2VuYXJpbyB5b3UgZGVz Y3JpYmUsIGV2ZW4gd2l0aG91dCBzYWxlcyBjaGFubmVsIGludGVncmF0aW9uLg0KDQpTbyBpZiBu ZWl0aGVyIG9mIHRoZXNlIGNhc2VzIGFwcGxpZXMsIHRoZW4gdGhlIGF0dGFjayBzdWNjZWVkcz8N Cg0KQ29ycmVjdC4gTXkgcHJlZmVyZW5jZSBpcyB0aGUgbm9uLXNhbGVzIGNoYW5uZWwgYXBwcm9h Y2ggd2hlcmUgdGhlIG5ldHdvcmsgb3BlcmF0b3IgaGFzIGNvbXBsZXRlIGNvbnRyb2wuDQoNClRv IGJlIGNsZWFyLCBJJ20gbm90IHNheWluZyB0aGlzIGlzIGEgZGVmZWN0IGluIHRoZSBwcm90b2Nv bC4gSSBkb24ndCBrbm93IGhvdyB0byBmaXggaXQuIEknbSBqdXN0IHRyeWluZyB0byBnZXQgY2xl YXIuDQoNCkFncmVlZC4gSSBkb27igJl0IHNlZSB0aGlzIGFzIGEg4oCcZGVmZWN04oCdIG15c2Vs ZiwgaXRzIGEgY29uc2Npb3VzIGRlY2lzaW9uIHRvIGFsbG93IGZsZXhpYmlsaXR5IGluIGRlcGxv eW1lbnQgbW9kZWxzLg0KDQpUaGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIHNlY3VyZSBib290c3Ry YXBwaW5nIHJlcXVpcmVzIGRldmljZXMgdG8gZW5nYWdlIGluIHNlY3VyaXR5IG9wZXJhdGlvbnMu IERvaW5nIHNvIHJ1bnMgdGhlIHJpc2sgdGhhdCBzb21ldGhpbmcgd29u4oCZdCB3b3JrIHdoZW4g bmVlZGVkLiBPdXIgZGVzaWduIGNob2ljZSBpcyB0byBsaW1pdCB0aGUgZGV2aWNlIHNlY3VyaXR5 IG9wZXJhdGlvbnMgdG8gdGhlIG1pbmltYWwgYW1vdW50OiBqdXN0IHN1ZmZpY2llbnQgZm9yIG5l dHdvcmsgb3BlcmF0b3IgYXVkaXQgb3IgdmVuZG9yIGNvbnRyb2wuIFRoaXMgc2hvdWxkIGJlIG1v cmUgcmVsaWFibHkgd2hpbGUgYWxsb3dpbmcgdGhlIHRoZSB2ZW5kb3Igb3IgdGhlIG5ldHdvcmsg b3BlcmF0b3IgY2FuIHByb3ZpZGUgc3Vic3RhbnRpYWwgc2VjdXJpdHkgKmlmIHRoZXkgd2FudCou DQoNCi0gbWF4DQoNCg0KLUVrcg0KDQoNCk9uY2UgZGV0ZWN0ZWQsIHRoZW4gd2hhdD8gVGhlIEJS U0tJIGRyYWZ0IGhhcyB0aGlzIHRvIHNheSBhYm91dCBpdHMgcHJvdG9jb2wgZmxvdyBhbmQgbmV0 d29yayBhY2Nlc3MgY29udHJvbDoNCg0KZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtl eWluZnJhLTA5Og0KDQogICBUaGlzIGRvY3VtZW50IHByZXN1bWVzIHRoYXQgbmV0d29yayBhY2Nl c3MgY29udHJvbCBoYXMgZWl0aGVyIGFscmVhZHkNCiAgIG9jY3VycmVkLCBpcyBub3QgcmVxdWly ZWQsIG9yIGlzIGludGVncmF0ZWQgYnkgdGhlIHByb3h5IGFuZA0KICAgcmVnaXN0cmFyIGluIHN1 Y2ggYSB3YXkgdGhhdCB0aGUgZGV2aWNlIGl0c2VsZiBkb2VzIG5vdCBuZWVkIHRvIGJlDQogICBh d2FyZSBvZiB0aGUgZGV0YWlscy4gIEFsdGhvdWdoIHRoZSB1c2Ugb2YgYW4gWC41MDkgSW5pdGlh bCBEZXZpY2UNCiAgIElkZW50aXR5IGlzIGNvbnNpc3RhbnQgd2l0aCBJRUVFIDgwMi4xQVIgW0lE ZXZJRDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1ib290c3Ry YXBwaW5nLWtleWluZnJhLTA5I3JlZi1JRGV2SUQ+XSwgYW5kIGFsbG93cyBmb3INCiAgIGFsaWdu bWVudCB3aXRoIDgwMi4xWCBuZXR3b3JrIGFjY2VzcyBjb250cm9sIG1ldGhvZHMsIGl0cyB1c2Ug aGVyZSBpcw0KICAgZm9yIFBsZWRnZSBhdXRoZW50aWNhdGlvbiByYXRoZXIgdGhhbiBuZXR3b3Jr IGFjY2VzcyBjb250cm9sLg0KICAgSW50ZWdyYXRpbmcgdGhpcyBwcm90b2NvbCB3aXRoIG5ldHdv cmsgYWNjZXNzIGNvbnRyb2wsIHBlcmhhcHMgYXMgYW4NCiAgIEV4dGVuc2libGUgQXV0aGVudGlj YXRpb24gUHJvdG9jb2wgKEVBUCkgbWV0aG9kIChzZWUgW1JGQzM3NDg8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzM3NDg+XSksIGlzDQogICBvdXQtb2Ytc2NvcGUuDQoNCkl0cyBldmVu IG1vcmUgb3V0IG9mIHNjb3BlIGZvciB0aGUgdm91Y2hlciBpdHNlbGYgc2luY2UgdGhhdCBpcyBh IG1zZyBmb3JtYXQgZm9yIOKAnHdobyBzaG91bGQgdGhlIGRldmljZSB0cnVzdOKAnSBhbmQgdG8g dHJpZ2dlciBlbnJvbGxtZW50IGJ1dCBpcyBldmVuIGZ1cnRoZXIgcmVtb3ZlZCBmcm9tIG5ldHdv cmsgYWNjZXNzIGNvbnRyb2wuDQoNCkEgcG90ZW50aWFsIGludGVncmF0aW9uIGlzIHRvIHVzZSBB TklNQSBvciBCUlNLSSB0byBtYW5hZ2UgZGV2aWNlIGVucm9sbG1lbnQgYW5kIGNyZWRlbnRpYWwg ZnJvbSBhIHF1YXJhbnRpbmUgbmV0d29yay4gVGhlIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2wgY291 bGQgYmUgY29uZmlndXJlZCB0byBzZWdyZWdhdGUgYWxsIGRldmljZXMgdGhhdCBhcmUgbm90IGVu cm9sbGVkIChwZXJoYXBzIGludG8gYSB0cnVlIHF1YXJhbnRpbmUgbmV0d29yayBvciBtYXliZSBq dXN0IHBhc3MgdGhlbSBhbGwgdGhyb3VnaCB0byBhIGNhcmVmdWxseSBtYW5hZ2VkIGRteiBvciDi gKYgd2hhdGV2ZXIpLiBJZiB0aGUgZGV2aWNlIGVucm9sbHMgc3VjY2Vzc2Z1bGx5IHRoZW4geW91 IGdldCBvbiB0aGUg4oCccmVhbOKAnSBuZXR3b3JrLiBJbiB5b3VyIHNjZW5hcmlvIHRoZW4gdGhl IGF0dGFja2VyIGdhaW4gY29udHJvbCBvdmVyIGEgZGV2aWNlIHRoYXQgaXMgdW50cnVzdGVkIGFu ZCBwbGFjZWQgYXBwcm9wcmlhdGVseSBieSB0aGUgbmV0d29yayBhY2Nlc3MgY29udHJvbCBzeXN0 ZW0uIEJ1dCBhcyBub3RlZCwgcHJvdmlkaW5nIHRoZSB0b29scyBmb3IgdGhpcyBpcyBkaWZmZXJl bnQgdGhhbiBhY3R1YWxseSBkZWZpbmluZyB0aGF0IGludGVncmF0aW9uLiBJIGVuY291cmFnZSB0 aGUgbmV0d29yayBhY2Nlc3MgY29udHJvbCBmb2xrcyB0byBhZGRyZXNzIHRoZXNlIHR5cGVzIG9m IGNvbmNlcm5zLg0KDQotIG1heA0KDQoNCi1Fa3INCg0KDQooVGhlIGV4YWN0IG5hdHVyZSBvZiB0 aGUga2V5cyBkZXBlbmRzIHVwb24gaG93IHRoZSB2b3VjaGVyIGlzIHVzZWQuDQpJbiBCUlNLSSBp dCdzIHRvIGJvb3RzdHJhcCBhbiBFU1QgY29ubmVjdGlvbiwgd2hpbGUgaW4gc29tZSB2ZXJzaW9u cyBvZiB0aGUNCjZ0aXNjaCwgYWN0dWFsIDgwMi4xNS40IGtleXMgYXJlIHJldHVybi4gIE5FVENP TkYgdXNlcyB0aGlzIG5ldyB0cnVzdCB0bw0KcGVybWl0IHRoZSBvd25lciB0byByZWFjaCBpbiBh bmQgZG8gY29uZmlndXJhdGlvbiB3aXRoIFJFU1RDT05GKQ0KDQotLQ0KTWljaGFlbCBSaWNoYXJk c29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jciUyQklFVEZAc2FuZGVsbWFuLmNh Pj4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0N Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkFuaW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1hQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQoNCg0K --_000_29D1A62EB7174E6285FFBA194AB2DEDBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4FC8F9F8880CF544BBEEDC9DFEDC55DE@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMg MTQsIDIwMTcsIGF0IDk6MzIgQU0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpl a3JAcnRmbS5jb20iIGNsYXNzPSIiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgRGVj IDE0LCAyMDE3IGF0IDg6MjkgQU0sIE1heCBQcml0aWtpbiAocHJpdGlraW4pDQo8c3BhbiBkaXI9 Imx0ciIgY2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzpwcml0aWtpbkBjaXNjby5jb20iIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5wcml0aWtpbkBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMgMTQsIDIwMTcsIGF0IDg6 NDMgQU0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N CjxiciBjbGFzcz0ibV80NzQ0ODcyODIxMzczNjkyMTc5QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBUaHUsIERlYyAxNCwgMjAxNyBhdCA3OjQwIEFNLCBNaWNoYWVsIFJpY2hh cmRzb24gPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzptY3Im IzQzO2lldGZAc2FuZGVsbWFuLmNhIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bWNyJiM0Mztp ZXRmQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCkVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRm bS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90 ZTo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhlIGNhc2UgSSBhbSBjb25jZXJu ZWQgd2l0aCByaWdodCBub3cgaXMgdGhlIGNhc2Ugd2hlcmUgdGhlIGF0dGFja2VyPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGp1c3QgaW1wcmludHMgdGhlIGRldmljZSBhbmQgdGhl biBvcGVyYXRlcyBpdCBldmVuIHRob3VnaCBpdCdzIGluIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJmd0OyB2aWN0aW0ncyBuZXR3b3JrLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvc3Bhbj5Ib3cgY2FuIHRoZXkgam9pbiB0aGUgdmljdGltJ3MgbmV0d29yaywgaWYgdGhl IHBvaW50IG9mIHRoZSBlbnJvbGxtZW50IGlzIHRvPGJyIGNsYXNzPSIiPg0KcHJvdmlkZSB0aGUg ZGV2aWNlIHdpdGgga2V5cyB0byBiZSBhYmxlIHRvIGpvaW4gdGhlIHZpY3RpbSdzIG5ldHdvcms/ PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWgsIG5vdyBJIHRoaW5rIHdlJ3JlIGdldHRpbmcgc29t ZXdoZXJlLiBJIGhhZCB1bmRlcnN0b29kIHRoZSBwb2ludCBvZiB0aGUgZW5yb2xsbWVudCBpbiB0 aGlzIGNvbnRleHQgdG8gYmUgdG8gZ2V0IGl0IHRvIGpvaW4gdGhlIEFOSU1BIGZhYnJpYywgbm90 IG5lY2Vzc2FyaWx5IHRoZSBwaHlzaWNhbCBuZXR3b3JrIChoZW5jZSB3aHkgd2UgaGF2ZSBBQ1As IGV0Yy4pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5BbSBJIGp1c3QgdG90YWxseSBtaXNzaW5nIHRoZSBwb2ludCBoZXJlPzwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBjbGFzcz0iIj5TbywgbW9y ZSBkaXJlY3RseSByZXNwb25kaW5nIHRvIHlvdXIgY29uY2VybjogV2hhdCBoYXBwZW5zIGlmIHRo ZSBhdHRhY2tlciDigJxqdXN0IGltcHJpbnRzIHRoZSBkZXZpY2UgYW5kIHRoZW4gb3BlcmF0ZXMg aXQgZXZlbiB0aG91Z2ggaXRzIGluIHRoZSB2aWN0aW3igJlzIG5ldHdvcmvigJ0/PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkFuc3dlcjo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHRoZSB2ZW5kb3Igc3lzdGVtIGhhcyBzYWxlcyBjaGFu bmVsIGludGVncmF0aW9uIHRoZW4gdGhlIHZvdWNoZXIgc2lnbmF0dXJlcyBwcm92aWRlIGFuIG9w dGlvbmFsIG1ldGhvZCBvZiBibG9ja2luZyDigJxhdHRhY2tlciBpbXByaW504oCdIChiZWNhdXNl IGl0IGlzIG5vIGxvbmdlciB0cnVzdC1vbi1maXJzdC11c2UpLiBUaGlzIFBSRVZFTlRTIHRoZSBh dHRhY2sgeW914oCZcmUgYXNraW5nIGFib3V0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J ZiB0aGUgdmljdGltIG5ldHdvcmsgb3BlcmF0b3IgaGFzIGFwcHJvcHJpYXRlIGludmVudG9yeSBt YW5hZ2VtZW50IHRoZW4gQlJTS0kvTUFTQSBpbnRlZ3JhdGlvbiBwcm92aWRlcyBsb2dnaW5nIGlu cHV0cyBpbnRvIHRoYXQgc3lzdGVtIHRvIERFVEVDVCB0aGUgc2NlbmFyaW8geW91IGRlc2NyaWJl LCBldmVuIHdpdGhvdXQgc2FsZXMgY2hhbm5lbCBpbnRlZ3JhdGlvbi4mbmJzcDs8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TbyBpZiBuZWl0aGVyIG9mIHRoZXNlIGNhc2VzIGFwcGxp ZXMsIHRoZW4gdGhlIGF0dGFjayBzdWNjZWVkcz88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+Q29ycmVjdC4gTXkgcHJlZmVyZW5jZSBpcyB0aGUgbm9uLXNhbGVzIGNoYW5uZWwgYXBwcm9h Y2ggd2hlcmUgdGhlIG5ldHdvcmsgb3BlcmF0b3IgaGFzIGNvbXBsZXRlIGNvbnRyb2wuJm5ic3A7 PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+VG8g YmUgY2xlYXIsIEknbSBub3Qgc2F5aW5nIHRoaXMgaXMgYSBkZWZlY3QgaW4gdGhlIHByb3RvY29s LiBJIGRvbid0IGtub3cgaG93IHRvIGZpeCBpdC4gSSdtIGp1c3QgdHJ5aW5nIHRvIGdldCBjbGVh ci48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+QWdyZWVkLiBJIGRvbuKAmXQgc2VlIHRo aXMgYXMgYSDigJxkZWZlY3TigJ0gbXlzZWxmLCBpdHMgYSBjb25zY2lvdXMgZGVjaXNpb24gdG8g YWxsb3cgZmxleGliaWxpdHkgaW4gZGVwbG95bWVudCBtb2RlbHMuICZuYnNwOzwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyBpbXBvcnRhbnQgYmVjYXVzZSBz ZWN1cmUgYm9vdHN0cmFwcGluZyByZXF1aXJlcyBkZXZpY2VzIHRvIGVuZ2FnZSBpbiBzZWN1cml0 eSBvcGVyYXRpb25zLiBEb2luZyBzbyBydW5zIHRoZSByaXNrIHRoYXQgc29tZXRoaW5nIHdvbuKA mXQgd29yayB3aGVuIG5lZWRlZC4gT3VyIGRlc2lnbiBjaG9pY2UgaXMgdG8gbGltaXQgdGhlIGRl dmljZSBzZWN1cml0eSBvcGVyYXRpb25zIHRvIHRoZSBtaW5pbWFsIGFtb3VudDoganVzdCBzdWZm aWNpZW50DQogZm9yIG5ldHdvcmsgb3BlcmF0b3IgYXVkaXQgb3IgdmVuZG9yIGNvbnRyb2wuIFRo aXMgc2hvdWxkIGJlIG1vcmUgcmVsaWFibHkgd2hpbGUgYWxsb3dpbmcgdGhlIHRoZSB2ZW5kb3Ig b3IgdGhlIG5ldHdvcmsgb3BlcmF0b3IgY2FuIHByb3ZpZGUgc3Vic3RhbnRpYWwgc2VjdXJpdHkg KmlmIHRoZXkgd2FudCouJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdj4tIG1heDwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tRWtyPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+T25jZSBkZXRlY3RlZCwgdGhlbiB3aGF0PyBUaGUgQlJTS0kgZHJhZnQg aGFzIHRoaXMgdG8gc2F5IGFib3V0IGl0cyBwcm90b2NvbCBmbG93IGFuZCBuZXR3b3JrIGFjY2Vz cyBjb250cm9sOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmRyYWZ0LWlldGYtYW5pbWEtPHdiciBjbGFzcz0i Ij5ib290c3RyYXBwaW5nLWtleWluZnJhLTA5OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibV80NzQ0ODcyODIxMzcz NjkyMTc5bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7 bWFyZ2luLWJvdHRvbTowcHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPiAgIFRoaXMg ZG9jdW1lbnQgcHJlc3VtZXMgdGhhdCBuZXR3b3JrIGFjY2VzcyBjb250cm9sIGhhcyBlaXRoZXIg YWxyZWFkeQ0KICAgb2NjdXJyZWQsIGlzIG5vdCByZXF1aXJlZCwgb3IgaXMgaW50ZWdyYXRlZCBi eSB0aGUgcHJveHkgYW5kDQogICByZWdpc3RyYXIgaW4gc3VjaCBhIHdheSB0aGF0IHRoZSBkZXZp Y2UgaXRzZWxmIGRvZXMgbm90IG5lZWQgdG8gYmUNCiAgIGF3YXJlIG9mIHRoZSBkZXRhaWxzLiAg QWx0aG91Z2ggdGhlIHVzZSBvZiBhbiBYLjUwOSBJbml0aWFsIERldmljZQ0KICAgSWRlbnRpdHkg aXMgY29uc2lzdGFudCB3aXRoIElFRUUgODAyLjFBUiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0wOSNy ZWYtSURldklEIiB0aXRsZT0iJnF1b3Q7SUVFRSA4MDIuMUFSIFNlY3VyZSBEZXZpY2UgSWRlbnRp ZmllciZxdW90OyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPklEZXZJRDwvYT5dLCBhbmQgYWxs b3dzIGZvcg0KICAgYWxpZ25tZW50IHdpdGggODAyLjFYIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2wg bWV0aG9kcywgaXRzIHVzZSBoZXJlIGlzDQogICBmb3IgUGxlZGdlIGF1dGhlbnRpY2F0aW9uIHJh dGhlciB0aGFuIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2wuDQogICBJbnRlZ3JhdGluZyB0aGlzIHBy b3RvY29sIHdpdGggbmV0d29yayBhY2Nlc3MgY29udHJvbCwgcGVyaGFwcyBhcyBhbg0KICAgRXh0 ZW5zaWJsZSBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAoRUFQKSBtZXRob2QgKHNlZSBbPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM3NDgiIHRpdGxlPSImcXVvdDtFeHRl bnNpYmxlIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIChFQVApJnF1b3Q7IiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+UkZDMzc0ODwvYT5dKSwgaXMNCiAgIG91dC1vZi1zY29wZS48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdHMgZXZlbiBtb3JlIG91dCBvZiBz Y29wZSBmb3IgdGhlIHZvdWNoZXIgaXRzZWxmIHNpbmNlIHRoYXQgaXMgYSBtc2cgZm9ybWF0IGZv ciDigJx3aG8gc2hvdWxkIHRoZSBkZXZpY2UgdHJ1c3TigJ0gYW5kIHRvIHRyaWdnZXIgZW5yb2xs bWVudCBidXQgaXMgZXZlbiBmdXJ0aGVyIHJlbW92ZWQgZnJvbSBuZXR3b3JrIGFjY2VzcyBjb250 cm9sLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5BIHBvdGVudGlhbCBpbnRlZ3JhdGlvbiBpcyB0byB1c2UgQU5JTUEgb3Ig QlJTS0kgdG8gbWFuYWdlIGRldmljZSBlbnJvbGxtZW50IGFuZCBjcmVkZW50aWFsIGZyb20gYSBx dWFyYW50aW5lIG5ldHdvcmsuIFRoZSBuZXR3b3JrIGFjY2VzcyBjb250cm9sIGNvdWxkIGJlIGNv bmZpZ3VyZWQgdG8gc2VncmVnYXRlIGFsbCBkZXZpY2VzIHRoYXQgYXJlIG5vdCBlbnJvbGxlZCAo cGVyaGFwcyBpbnRvIGEgdHJ1ZSBxdWFyYW50aW5lDQogbmV0d29yayBvciBtYXliZSBqdXN0IHBh c3MgdGhlbSBhbGwgdGhyb3VnaCB0byBhIGNhcmVmdWxseSBtYW5hZ2VkIGRteiBvciDigKYgd2hh dGV2ZXIpLiBJZiB0aGUgZGV2aWNlIGVucm9sbHMgc3VjY2Vzc2Z1bGx5IHRoZW4geW91IGdldCBv biB0aGUg4oCccmVhbOKAnSBuZXR3b3JrLiBJbiB5b3VyIHNjZW5hcmlvIHRoZW4gdGhlIGF0dGFj a2VyIGdhaW4gY29udHJvbCBvdmVyIGEgZGV2aWNlIHRoYXQgaXMgdW50cnVzdGVkIGFuZCBwbGFj ZWQgYXBwcm9wcmlhdGVseQ0KIGJ5IHRoZSBuZXR3b3JrIGFjY2VzcyBjb250cm9sIHN5c3RlbS4g QnV0IGFzIG5vdGVkLCBwcm92aWRpbmcgdGhlIHRvb2xzIGZvciB0aGlzIGlzIGRpZmZlcmVudCB0 aGFuIGFjdHVhbGx5IGRlZmluaW5nIHRoYXQgaW50ZWdyYXRpb24uIEkgZW5jb3VyYWdlIHRoZSBu ZXR3b3JrIGFjY2VzcyBjb250cm9sIGZvbGtzIHRvIGFkZHJlc3MgdGhlc2UgdHlwZXMgb2YgY29u Y2VybnMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4tIG1heDwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4tRWtyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnIgY2xhc3M9IiI+DQooVGhlIGV4 YWN0IG5hdHVyZSBvZiB0aGUga2V5cyBkZXBlbmRzIHVwb24gaG93IHRoZSB2b3VjaGVyIGlzIHVz ZWQuPGJyIGNsYXNzPSIiPg0KSW4gQlJTS0kgaXQncyB0byBib290c3RyYXAgYW4gRVNUIGNvbm5l Y3Rpb24sIHdoaWxlIGluIHNvbWUgdmVyc2lvbnMgb2YgdGhlPGJyIGNsYXNzPSIiPg0KNnRpc2No LCBhY3R1YWwgODAyLjE1LjQga2V5cyBhcmUgcmV0dXJuLiZuYnNwOyBORVRDT05GIHVzZXMgdGhp cyBuZXcgdHJ1c3QgdG88YnIgY2xhc3M9IiI+DQpwZXJtaXQgdGhlIG93bmVyIHRvIHJlYWNoIGlu IGFuZCBkbyBjb25maWd1cmF0aW9uIHdpdGggUkVTVENPTkYpPGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0ibV80NzQ0ODcyODIxMzczNjkyMTc5SE9FblpiIj4NCjxkaXYgY2xhc3M9Im1fNDc0NDg3 MjgyMTM3MzY5MjE3OWg1Ij48YnIgY2xhc3M9IiI+DQotLTxiciBjbGFzcz0iIj4NCk1pY2hhZWwg UmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciUyQklFVEZAc2FuZGVsbWFuLmNhIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7 LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3M8YnIgY2xhc3M9IiI+DQombmJzcDstPSBJUHY2IElv VCBjb25zdWx0aW5nID0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188d2JyIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K QW5pbWEgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOkFuaW1hQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+QW5pbWFAaWV0Zi5vcmc8L2E+PGJyIGNs YXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h bmltYSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9hbmltYTwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_29D1A62EB7174E6285FFBA194AB2DEDBciscocom_-- From nobody Thu Dec 14 09:26:44 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43769129436 for ; Thu, 14 Dec 2017 09:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 x5F0QFJXCv-m for ; Thu, 14 Dec 2017 09:26:39 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::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 0AB3412940A for ; Thu, 14 Dec 2017 09:26:29 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id t127so4038117ybf.9 for ; Thu, 14 Dec 2017 09:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x9O/rcFi63AmUXnVguzXENhGZx/XmhWlOAPuxu0bH+M=; b=0BtF7/0hW/V+YNwvLiqTFJWhun5mTJdg2cWI4REXDlDVaZF3YMKPEuDYcfgQ3RwDHs kQJstYqGJ13LJ1cbfuDeSzicfeZruf/1gAwSNSUgW2S1rp2s+IEbuftAy4WYeO0MXiuY X27F49YN5Zh6qXdRoxcusb5N5pzHvQk7uxIyRMroi68JTeq0B1OkVfcAaPEG86qOhvua 3exrI1NdP1jfNZlWL1oNDGe9ul0WJvzMaXltYIaGGNBu/G5K/RK9/qDZV+BW5X6yUuTl gWb3iJem8hb0wqJNjvv3AENdfLN9HpoFJRKVHoppQLa6wCrHellc4CoTVKnJfdp1UeL+ yoEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x9O/rcFi63AmUXnVguzXENhGZx/XmhWlOAPuxu0bH+M=; b=Dryj9KT2pJiLaLQ090KBNIoR9OCh9LuCPgJdO979DFd8MsyzP4v7rpAKGRXyqYsOQ1 ZZdGJkMGUjvE0faQzHN2FXnnI0pw4MfjAMZaToPaIDEMbOIxvRAZxkRTbQyaYvCk9Fei M9Cwh5IHit3w3BTKhT9A1KgUz0ofHNErtjh6uNPx2LvIXALqBjs5Ky5IYxn2Vn/AbTBB +mm5wTnC4Co87RSE5ACDFrM1MzCE3yvg85DsuAE7PI3B9HQVUlt4VDYF199tHCDo9Ucm 45VdUqXra8uk8zm0/+jWEVjiBc7mzSd2B9cywKkxESMcijwQdb0KJSx6rYTeVje4BxYM iv5w== X-Gm-Message-State: AKGB3mIJ3RJ19NMBwnTKVSeCqTrRv87hmWa6NJzTSysYAcsl74WqRDGq s5TIg0H2GMLMWfaTfriHXXT18/NsFDk2VIpY5qZkcg== X-Google-Smtp-Source: ACJfBovIvt9YGLZrUATVC4S++orioc1/MoEQDa7Si8PJ/fDRp5+CyjUQmv7R9+9/o8ubUJGE7bLvkCeIlclmUaubhYQ= X-Received: by 10.37.178.26 with SMTP id i26mr4741683ybj.208.1513272388128; Thu, 14 Dec 2017 09:26:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 14 Dec 2017 09:25:47 -0800 (PST) In-Reply-To: <29D1A62E-B717-4E62-85FF-BA194AB2DEDB@cisco.com> References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> <29D1A62E-B717-4E62-85FF-BA194AB2DEDB@cisco.com> From: Eric Rescorla Date: Thu, 14 Dec 2017 09:25:47 -0800 Message-ID: To: "Max Pritikin (pritikin)" Cc: Michael Richardson , Toerless Eckert , "draft-ietf-anima-voucher@tools.ietf.org" , Anima WG , IESG Content-Type: multipart/alternative; boundary="f403045f3f0624a7440560502f24" Archived-At: Subject: Re: [Anima] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 17:26:42 -0000 --f403045f3f0624a7440560502f24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This all seems reasonable. I think I understand this better and I really appreciate people being willing to talk it through. >From my perspective it would be nice if we added a bit more text to the document to explain this stuff. Would people be interested in that? Would they want me to produce text? -Ekr On Thu, Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) wrote: > > On Dec 14, 2017, at 9:32 AM, Eric Rescorla wrote: > > > > On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) < > pritikin@cisco.com> wrote: > >> >> On Dec 14, 2017, at 8:43 AM, Eric Rescorla wrote: >> >> >> >> On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson < >> mcr+ietf@sandelman.ca> wrote: >> >>> >>> Eric Rescorla wrote: >>> > The case I am concerned with right now is the case where the >>> attacker >>> > just imprints the device and then operates it even though it's in >>> the >>> > victim's network. >>> >>> How can they join the victim's network, if the point of the enrollment >>> is to >>> provide the device with keys to be able to join the victim's network? >>> >> >> Ah, now I think we're getting somewhere. I had understood the point of >> the enrollment in this context to be to get it to join the ANIMA fabric, >> not necessarily the physical network (hence why we have ACP, etc.) >> >> Am I just totally missing the point here? >> >> >> So, more directly responding to your concern: What happens if the >> attacker =E2=80=9Cjust imprints the device and then operates it even tho= ugh its in >> the victim=E2=80=99s network=E2=80=9D? >> Answer: >> >> If the vendor system has sales channel integration then the voucher >> signatures provide an optional method of blocking =E2=80=9Cattacker impr= int=E2=80=9D >> (because it is no longer trust-on-first-use). This PREVENTS the attack >> you=E2=80=99re asking about. >> If the victim network operator has appropriate inventory management then >> BRSKI/MASA integration provides logging inputs into that system to DETEC= T >> the scenario you describe, even without sales channel integration. >> > > So if neither of these cases applies, then the attack succeeds? > > > Correct. My preference is the non-sales channel approach where the networ= k > operator has complete control. > > To be clear, I'm not saying this is a defect in the protocol. I don't kno= w > how to fix it. I'm just trying to get clear. > > > Agreed. I don=E2=80=99t see this as a =E2=80=9Cdefect=E2=80=9D myself, it= s a conscious decision to > allow flexibility in deployment models. > > This is important because secure bootstrapping requires devices to engage > in security operations. Doing so runs the risk that something won=E2=80= =99t work > when needed. Our design choice is to limit the device security operations > to the minimal amount: just sufficient for network operator audit or vend= or > control. This should be more reliably while allowing the the vendor or th= e > network operator can provide substantial security *if they want*. > > - max > > > -Ekr > > >> >> Once detected, then what? The BRSKI draft has this to say about its >> protocol flow and network access control: >> >> draft-ietf-anima-bootstrapping-keyinfra-09: >> >> This document presumes that network access control has either already >> occurred, is not required, or is integrated by the proxy and >> registrar in such a way that the device itself does not need to be >> aware of the details. Although the use of an X.509 Initial Device >> Identity is consistant with IEEE 802.1AR [IDevID ], and allow= s for >> alignment with 802.1X network access control methods, its use here is >> for Pledge authentication rather than network access control. >> Integrating this protocol with network access control, perhaps as an >> Extensible Authentication Protocol (EAP) method (see [RFC3748 ]), is >> out-of-scope. >> >> Its even more out of scope for the voucher itself since that is a msg >> format for =E2=80=9Cwho should the device trust=E2=80=9D and to trigger = enrollment but is >> even further removed from network access control. >> >> A potential integration is to use ANIMA or BRSKI to manage device >> enrollment and credential from a quarantine network. The network access >> control could be configured to segregate all devices that are not enroll= ed >> (perhaps into a true quarantine network or maybe just pass them all thro= ugh >> to a carefully managed dmz or =E2=80=A6 whatever). If the device enrolls >> successfully then you get on the =E2=80=9Creal=E2=80=9D network. In your= scenario then the >> attacker gain control over a device that is untrusted and placed >> appropriately by the network access control system. But as noted, provid= ing >> the tools for this is different than actually defining that integration.= I >> encourage the network access control folks to address these types of >> concerns. >> >> - max >> >> >> -Ekr >> >> >>> >>> (The exact nature of the keys depends upon how the voucher is used. >>> In BRSKI it's to bootstrap an EST connection, while in some versions of >>> the >>> 6tisch, actual 802.15.4 keys are return. NETCONF uses this new trust t= o >>> permit the owner to reach in and do configuration with RESTCONF) >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>> >>> >>> >>> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >> >> > > --f403045f3f0624a7440560502f24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This all seems reasonable. I think I understand this bette= r and I really appreciate people being willing to talk it through.

=
From my perspective it would be nice if we added a bit more text= to the document to explain this stuff. Would people be interested in that?= Would they want me to produce text?

-Ekr


On Thu, Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) <pritikin@c= isco.com> wrote:

On Dec 14, 2017, at 9:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (p= ritikin) <pritikin@cisco.com> wrote:

On Dec 14, 2017, at 8:43 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Dec 14, 2017 at 7:40 AM, Michael Richard= son <mcr+ietf@san= delman.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 > The case I am concerned with right now is the case where= the attacker
=C2=A0 =C2=A0 > just imprints the device and then operates it even thoug= h it's in the
=C2=A0 =C2=A0 > victim's network.

How can they join the victim's network, if the point of the enro= llment is to
provide the device with keys to be able to join the victim's network?

Ah, now I think we're getting somewhere. I had understood the poin= t of the enrollment in this context to be to get it to join the ANIMA fabri= c, not necessarily the physical network (hence why we have ACP, etc.)

Am I just totally missing the point here?
So, more directly responding to your concern: What happens if the atta= cker =E2=80=9Cjust imprints the device and then operates it even though its= in the victim=E2=80=99s network=E2=80=9D?
Answer:

If the vendor system has sales channel integration then the voucher si= gnatures provide an optional method of blocking =E2=80=9Cattacker imprint= =E2=80=9D (because it is no longer trust-on-first-use). This PREVENTS the a= ttack you=E2=80=99re asking about.=C2=A0
If the victim network operator has appropriate inventory management th= en BRSKI/MASA integration provides logging inputs into that system to DETEC= T the scenario you describe, even without sales channel integration.=C2=A0<= /div>

So if neither of these cases applies, then the attack succeeds?

Correct. My preference is the non-sales channel approach where = the network operator has complete control.=C2=A0

To be clear, I'm not saying this is a defect in the protocol. I do= n't know how to fix it. I'm just trying to get clear.

Agreed. I don=E2=80=99t see this as a =E2=80=9Cdefect=E2=80=9D = myself, its a conscious decision to allow flexibility in deployment models.= =C2=A0

This is important because secure bootstrapping requires devices to eng= age in security operations. Doing so runs the risk that something won=E2=80= =99t work when needed. Our design choice is to limit the device security op= erations to the minimal amount: just sufficient for network operator audit or vendor control. This should be more reliably= while allowing the the vendor or the network operator can provide substant= ial security *if they want*.=C2=A0

- max


-Ekr
=C2=A0

Once detected, then what? The BRSKI draft has this to say about its pr= otocol flow and network access control:

draft-ietf-anima-bootstrapping-keyinfra-09:
   This document presumes that network access control has either al=
ready
   occurred, is not required, or is integrated by the proxy and
   registrar in such a way that the device itself does not need to be
   aware of the details.  Although the use of an X.509 Initial Device
   Identity is consistant with IEEE 802.1AR [IDevID], and allows for
   alignment with 802.1X network access control methods, its use here is
   for Pledge authentication rather than network access control.
   Integrating this protocol with network access control, perhaps as an
   Extensible Authentication Protocol (EAP) method (see [RFC3748]), is
   out-of-scope.
Its even more out of scope for the voucher itself since that is a msg = format for =E2=80=9Cwho should the device trust=E2=80=9D and to trigger enr= ollment but is even further removed from network access control.

A potential integration is to use ANIMA or BRSKI to manage device enro= llment and credential from a quarantine network. The network access control= could be configured to segregate all devices that are not enrolled (perhap= s into a true quarantine network or maybe just pass them all through to a carefully managed dmz or = =E2=80=A6 whatever). If the device enrolls successfully then you get on the= =E2=80=9Creal=E2=80=9D network. In your scenario then the attacker gain co= ntrol over a device that is untrusted and placed appropriately by the network access control system. But as noted, providing the tools fo= r this is different than actually defining that integration. I encourage th= e network access control folks to address these types of concerns.

- max


-Ekr
=C2=A0

(The exact nature of the keys depends upon how the voucher is used.
In BRSKI it's to bootstrap an EST connection, while in some versions of= the
6tisch, actual 802.15.4 keys are return.=C2=A0 NETCONF uses this new trust = to
permit the owner to reach in and do configuration with RESTCONF)

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




_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima




--f403045f3f0624a7440560502f24-- From nobody Thu Dec 14 10:06:41 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0505E124BAC; Thu, 14 Dec 2017 10:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 6dHyFL-IW8ey; Thu, 14 Dec 2017 10:06:26 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.193]) (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 0C1C012704A; Thu, 14 Dec 2017 10:06:25 -0800 (PST) Received: from [216.82.242.46] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta-8.messagelabs.com id D4/10-05333-1ADB23A5; Thu, 14 Dec 2017 18:06:25 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VTbUxTVxjuuff23ivS5bR8vTY4RxOn4CjoJKl xX/FX92OGLYsmYDZv9UqrbSG9ZbIfui6rxsk+RBgCkSGOVQMl0UadGMBYYTBIcOgmk65kHciE qkhgY9r6cT+qm39OnvM8z/u+zzk5hyV1AUbP8hVu3uXk7AY6ibpi/C49t6lrTVF+7C5rihwfI UxfReKM6WR0iDHVxatI0xfBrxlTrONPxjQ0EiPfYsw1sdNqc/3pO8jc0nKfMFeP7yfN3qOdpH n+2hxdSBepbU5LacVWtfVobV7ZvZuo4tvJPuRB/T+jgyiJpfAMAfNfRilpo8PVBNR/1pHY9CB oHJ0hD6JFLI3z4XpXHyHhVPwudIc+lctJ/BsCf4eXkoQU/BrcvOVVK6bX4Y/rIbGYFfEmqG3j JZrCy+F+eEq2a/AWaB68TSvDQjTs7x+SaxeJA6aqLsjDEE6HhQG/jEmcAaMTTTIGnAqR4UFaw WkwNf5Irfi3QONcMMEbINT+L1LwUrjaVCmHBhxkYCTSRiqCEc5W3UmY3oHe6CFaMfkQVE8Nqx UhB44vdMmnAbwLTgRBoYvB/4OHVPyXSWiP/U0pQib83tydEB6r4WRPQJ6mw9uhplWJl4L1EP7 lc3QIZTf873QN8rU2Ifj1cAvTIN+TFn6qn6AUUxEs3L7IKDgHvmmfTvCrwNccJRvEgCTOhh+v GZ6nJbwe6h5cohWcBTWVkUSbAoj2zqJjaHErWinwro94V+6r+UaLy1ZidTs4mz13db7J6OAFg Svh7ZxFMG4rdQSQ+Fo/UanQeTTjKw6iJSxhSNO4A2uKdC9YSrd/bOUE64eucjsvBFEmyxpAE+ 4UNa2LL+Erdtjs4pN/KgObbEjVOCRZI5RxDsFWokgD6E023jkaJ9hTN8Li2i2vk/VRD6mjnKV OXp+hOSeVYanMWu581vTpV7qKlupTNEilUumSy3iXw+Z+Xp9GGSwypGiWiz9Ol2xzup/NnhZj EWKsv7x5Uiw395+k9yBP4VwWtax28ED/xIr0cN/wrcuegvMDb7f/c8///W4L5X1vz7rZPZbNj dkbssonC3bl3X2QldanxX5a+/DcKW7Dzk0v6irn08hlG9NfycwL1XV6C18+fOYl4oL9oqp17E aAOKI9kumb3rd3djc43wivPdtSeGwjTh3fafFdGYvHPnjfQAlWbnUO6RK4J42doX1FBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-9.tower-96.messagelabs.com!1513274782!115742011!1 X-Originating-IP: [207.46.163.22] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23209 invoked from network); 14 Dec 2017 18:06:23 -0000 Received: from mail-dm3nam03lp0022.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.22) by server-9.tower-96.messagelabs.com with AES256-SHA256 encrypted SMTP; 14 Dec 2017 18:06:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HggRLNqjS1p0y7phi4rotL5sSuLMNgxq3Q3Xj4/5auU=; b=eRcel+UTSQNWIeDxzP1q9cuUXl+5ZjUdKoHDJOJHNv7u1EY2WgZPOpaRSqAOGbn2Sje8lUWDYB1+Hz2VXxA0t/mdL7IKp1VeE59LDrhB5wPcs0hcgXWVK4p5VtIWFEqvom3IJcQkAknwPLrhyluMZ0LQb3CQFIJVWnMSk+TXpyQ= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1291.namprd14.prod.outlook.com (10.173.132.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 18:06:21 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0302.012; Thu, 14 Dec 2017 18:06:21 +0000 From: Tim Hollebeek To: Eric Rescorla , "Max Pritikin (pritikin)" CC: Michael Richardson , Toerless Eckert , Anima WG , "draft-ietf-anima-voucher@tools.ietf.org" , IESG Thread-Topic: [Anima] Question on draft-ietf-anima-voucher-06 Thread-Index: AQHTdPHeLFxE39YuOk67WeIMXx8thaNC+r2AgAAMtgCAAAEJgIAAC+yAgAAC3ICAAAqLIA== Date: Thu, 14 Dec 2017 18:06:20 +0000 Message-ID: References: <2509.1513177984@obiwan.sandelman.ca> <7AD8BD94-46B6-4C11-9632-85720C2B7305@cisco.com> <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> <29D1A62E-B717-4E62-85FF-BA194AB2DEDB@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1291; 6:yauultsAmsuTPspcXjeg5bJdpDy5LmPhpgkZMKRqVRdMm5p84mRqlz+1g5HSzj7jaDon6tSKv3Mz+2M9b47SdJ+amESeUVw6J2OJ7/UQauM4I9lHvrn0DD0z0/Dy61R4p14sE/DkG+LiVLxNEztyxuj8wW8yLB67a4BSXBfuA4OwhICOmcfAZ8jiAyUH+ho+zAVPtUjQiJ4C0nbXx+wGAleNnIbmuUBkYpxEt+C2nXcOQO/LZF8mpNOEQR03OgdsS1kT+3/GfRe+uBYHruirzg17OD8pjHY2/MWfCtJH0aW3hjVA9ECGACVVZ8nlvAbD4+Qh5/gvoheuv2CXcOpCpnLBj2plD0Lt1mU7Igg3DK4=; 5:sirJz1ZVBmJyAiZugGY74mNivnmxIuYB6uuMgNJvd7A7p81QVQYewYG8DK+3SR3bDr37ZGgvYVWMITuwfBeKBr+GU5Kr1EuRawrgKBmzy1ellYPZrHYqHWK8a9FBWL+ZQ3HaZvDRuI2KEzaU+zAtTsRHU+7FSVrta/byOHQ+K40=; 24:KDkO3QOAD6v+sUuZKqqMh+PIzg7yB00CV0lR9aQErmpVI+NC+sBiC+leLZHp71rz7P5qQL0B8irGQPT0TOPIPDZvbEg9E2wi60/MzU0EfaE=; 7:lYe75cMtmmxxJU7buplGXp5WKAO++JcPpMo2QrKf4/ieQDQAa3Pae0nYUmxbQ2wsBtnYUDX09wUudvoN6xMDzQI7Rw1pCw05Q6MXJkCjM71z2ewJH6bkuXMyzO5gIlqrz1/M5kP0VMlhyu2YwSIA+P7Y8S2qBL+qVwVfPbdyDCp5T+KIXaRgvKaIJoQuOjQH0QR5mDNe6dNOicYvSBkUziV4GSv1KfJoHQdRnJn6Ja026c8MvwCmMnyw05Gi8mHD x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f1f7740e-0a8c-4c26-a4f5-08d5431d6166 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603307)(49563074); SRVR:DM5PR14MB1291; x-ms-traffictypediagnostic: DM5PR14MB1291: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231023)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(2016111802025)(20161123564025)(20161123555025)(6072148)(6043046)(201708071742011); SRVR:DM5PR14MB1291; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1291; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39860400002)(346002)(24454002)(199004)(189003)(7736002)(5660300001)(316002)(8936002)(74316002)(236005)(76176011)(86362001)(110136005)(2906002)(99936001)(93886005)(33656002)(97736004)(54906003)(7696005)(99286004)(66066001)(230783001)(8676002)(2900100001)(3660700001)(25786009)(6116002)(81166006)(3280700002)(77096006)(106356001)(68736007)(81156014)(55016002)(54896002)(14454004)(9686003)(2950100002)(3846002)(6306002)(790700001)(6436002)(105586002)(4326008)(6246003)(53936002)(606006)(966005)(478600001)(229853002)(102836003)(59450400001)(53546011)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1291; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_03D6_01D374CB.8EE03DC0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1f7740e-0a8c-4c26-a4f5-08d5431d6166 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 18:06:20.8460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1291 Archived-At: Subject: Re: [Anima] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 18:06:30 -0000 ------=_NextPart_000_03D6_01D374CB.8EE03DC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03D7_01D374CB.8EE03DC0" ------=_NextPart_001_03D7_01D374CB.8EE03DC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think it would be useful as I had many of the same concerns myself. = The standard is intended to support multiple different levels of = security, and a wide variety of use cases. And while this is noted in = the document, there isn=E2=80=99t much guidance about what the various = tradeoffs are, and what you gain or lose by making certain deployment = choices. =20 I would be willing to help draft language to address this. =20 -Tim =20 From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Thursday, December 14, 2017 10:26 AM To: Max Pritikin (pritikin) Cc: Michael Richardson ; Toerless Eckert = ; Anima WG ; = draft-ietf-anima-voucher@tools.ietf.org; IESG Subject: Re: [Anima] Question on draft-ietf-anima-voucher-06 =20 This all seems reasonable. I think I understand this better and I really = appreciate people being willing to talk it through. =20 >From my perspective it would be nice if we added a bit more text to the = document to explain this stuff. Would people be interested in that? = Would they want me to produce text? =20 -Ekr =20 =20 On Thu, Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) = > wrote: =20 On Dec 14, 2017, at 9:32 AM, Eric Rescorla > wrote: =20 =20 =20 On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) = > wrote: =20 On Dec 14, 2017, at 8:43 AM, Eric Rescorla > wrote: =20 =20 =20 On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson = > wrote: Eric Rescorla > wrote: > The case I am concerned with right now is the case where the = attacker > just imprints the device and then operates it even though it's in = the > victim's network. How can they join the victim's network, if the point of the enrollment = is to provide the device with keys to be able to join the victim's network? =20 Ah, now I think we're getting somewhere. I had understood the point of = the enrollment in this context to be to get it to join the ANIMA fabric, = not necessarily the physical network (hence why we have ACP, etc.) =20 Am I just totally missing the point here? =20 So, more directly responding to your concern: What happens if the = attacker =E2=80=9Cjust imprints the device and then operates it even = though its in the victim=E2=80=99s network=E2=80=9D? Answer: =20 If the vendor system has sales channel integration then the voucher = signatures provide an optional method of blocking =E2=80=9Cattacker = imprint=E2=80=9D (because it is no longer trust-on-first-use). This = PREVENTS the attack you=E2=80=99re asking about.=20 If the victim network operator has appropriate inventory management then = BRSKI/MASA integration provides logging inputs into that system to = DETECT the scenario you describe, even without sales channel = integration.=20 =20 So if neither of these cases applies, then the attack succeeds? =20 Correct. My preference is the non-sales channel approach where the = network operator has complete control.=20 To be clear, I'm not saying this is a defect in the protocol. I don't = know how to fix it. I'm just trying to get clear. =20 Agreed. I don=E2=80=99t see this as a =E2=80=9Cdefect=E2=80=9D myself, = its a conscious decision to allow flexibility in deployment models. =20 =20 This is important because secure bootstrapping requires devices to = engage in security operations. Doing so runs the risk that something = won=E2=80=99t work when needed. Our design choice is to limit the device = security operations to the minimal amount: just sufficient for network = operator audit or vendor control. This should be more reliably while = allowing the the vendor or the network operator can provide substantial = security *if they want*.=20 =20 - max =20 -Ekr =20 =20 Once detected, then what? The BRSKI draft has this to say about its = protocol flow and network access control: =20 draft-ietf-anima-bootstrapping-keyinfra-09: This document presumes that network access control has either already occurred, is not required, or is integrated by the proxy and registrar in such a way that the device itself does not need to be aware of the details. Although the use of an X.509 Initial Device Identity is consistant with IEEE 802.1AR [IDevID = ], and allows for alignment with 802.1X network access control methods, its use here is for Pledge authentication rather than network access control. Integrating this protocol with network access control, perhaps as an Extensible Authentication Protocol (EAP) method (see [RFC3748 = ]), is out-of-scope. Its even more out of scope for the voucher itself since that is a msg = format for =E2=80=9Cwho should the device trust=E2=80=9D and to trigger = enrollment but is even further removed from network access control. =20 A potential integration is to use ANIMA or BRSKI to manage device = enrollment and credential from a quarantine network. The network access = control could be configured to segregate all devices that are not = enrolled (perhaps into a true quarantine network or maybe just pass them = all through to a carefully managed dmz or =E2=80=A6 whatever). If the = device enrolls successfully then you get on the =E2=80=9Creal=E2=80=9D = network. In your scenario then the attacker gain control over a device = that is untrusted and placed appropriately by the network access control = system. But as noted, providing the tools for this is different than = actually defining that integration. I encourage the network access = control folks to address these types of concerns. =20 - max =20 -Ekr =20 (The exact nature of the keys depends upon how the voucher is used. In BRSKI it's to bootstrap an EST connection, while in some versions of = the 6tisch, actual 802.15.4 keys are return. NETCONF uses this new trust to permit the owner to reach in and do configuration with RESTCONF) -- Michael Richardson >, Sandelman Software Works -=3D IPv6 IoT consulting =3D- =20 _______________________________________________ Anima mailing list Anima@ietf.org =20 https://www.ietf.org/mailman/listinfo/anima =20 =20 =20 =20 ------=_NextPart_001_03D7_01D374CB.8EE03DC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I think it = would be useful as I had many of the same concerns myself.=C2=A0 The = standard is intended to support multiple different levels of security, = and a wide variety of use cases.=C2=A0 And while this is noted in the = document, there isn=E2=80=99t much guidance about what the various = tradeoffs are, and what you gain or lose by making certain deployment = choices.

 

I would be willing to help draft language to address = this.

 

-Tim

 

From: Anima = [mailto:anima-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Thursday, December 14, 2017 10:26 = AM
To: Max Pritikin (pritikin) = <pritikin@cisco.com>
Cc: Michael Richardson = <mcr+ietf@sandelman.ca>; Toerless Eckert <tte@cs.fau.de>; = Anima WG <anima@ietf.org>; = draft-ietf-anima-voucher@tools.ietf.org; IESG = <iesg@ietf.org>
Subject: Re: [Anima] Question on = draft-ietf-anima-voucher-06

 

This = all seems reasonable. I think I understand this better and I really = appreciate people being willing to talk it = through.

 

From my perspective it would be nice if we added a bit = more text to the document to explain this stuff. Would people be = interested in that? Would they want me to produce = text?

 

-Ekr

 

 

On Thu, = Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) <pritikin@cisco.com> = wrote:

 

On Dec 14, 2017, at 9:32 AM, Eric Rescorla <ekr@rtfm.com> = wrote:

 

 

 

On Thu, = Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) <pritikin@cisco.com> = wrote:

 

On Dec 14, 2017, at 8:43 AM, Eric Rescorla <ekr@rtfm.com> = wrote:

 

 

 

On Thu, = Dec 14, 2017 at 7:40 AM, Michael Richardson <mcr+ietf@sandelman.ca> = wrote:


Eric = Rescorla <ekr@rtfm.com> wrote:
    > The = case I am concerned with right now is the case where the = attacker
    > just imprints the device and then = operates it even though it's in the
    > victim's = network.

How can they join the victim's network, if the point of = the enrollment is to
provide the device with keys to be able to join = the victim's network?

 

Ah, now I think we're getting somewhere. I had = understood the point of the enrollment in this context to be to get it = to join the ANIMA fabric, not necessarily the physical network (hence = why we have ACP, etc.)

 

Am I just totally missing the point = here?

 

So, more directly responding to your concern: What = happens if the attacker =E2=80=9Cjust imprints the device and then = operates it even though its in the victim=E2=80=99s = network=E2=80=9D?

Answer:

 

If the vendor system has sales channel integration = then the voucher signatures provide an optional method of blocking = =E2=80=9Cattacker imprint=E2=80=9D (because it is no longer = trust-on-first-use). This PREVENTS the attack you=E2=80=99re asking = about. 

If the victim = network operator has appropriate inventory management then BRSKI/MASA = integration provides logging inputs into that system to DETECT the = scenario you describe, even without sales channel = integration. 

 

So if neither of these cases applies, then the attack = succeeds?

<= p class=3DMsoNormal> 

Correct. My preference is the non-sales channel = approach where the network operator has complete = control. 



<= p class=3DMsoNormal>To be clear, I'm not saying this is a defect in the = protocol. I don't know how to fix it. I'm just trying to get = clear.

 

Agreed. I don=E2=80=99t see this as a = =E2=80=9Cdefect=E2=80=9D myself, its a conscious decision to allow = flexibility in deployment models.  

 

This is important because secure bootstrapping = requires devices to engage in security operations. Doing so runs the = risk that something won=E2=80=99t work when needed. Our design choice is = to limit the device security operations to the minimal amount: just = sufficient for network operator audit or vendor control. This should be = more reliably while allowing the the vendor or the network operator can = provide substantial security *if they = want*. 

 

- = max



<= p class=3DMsoNormal> 

-Ekr

 

 

Once detected, then what? The BRSKI draft has this to = say about its protocol flow and network access = control:

 

draft-ietf-anima-bootstrapping-keyinfra-09:<= /p>

=C2=A0=C2=A0 This document =
presumes that network access control has either =
already
=C2=A0=C2=A0 occurred, is not required, or =
is integrated by the proxy and
=C2=A0=C2=A0 =
registrar in such a way that the device itself does not need to =
be
=C2=A0=C2=A0 aware of the details.=C2=A0 =
Although the use of an X.509 Initial =
Device
=C2=A0=C2=A0 Identity is consistant with =
IEEE 802.1AR [IDevID], and allows =
for
=C2=A0=C2=A0 alignment with 802.1X network =
access control methods, its use here =
is
=C2=A0=C2=A0 for Pledge authentication rather =
than network access control.
=C2=A0=C2=A0 =
Integrating this protocol with network access control, perhaps as =
an
=C2=A0=C2=A0 Extensible Authentication Protocol =
(EAP) method (see [RFC3748]), is
=C2=A0=C2=A0 =
out-of-scope.

Its even more out of scope for the voucher itself = since that is a msg format for =E2=80=9Cwho should the device = trust=E2=80=9D and to trigger enrollment but is even further removed = from network access control.

 

A potential integration is to use ANIMA or BRSKI to = manage device enrollment and credential from a quarantine network. The = network access control could be configured to segregate all devices that = are not enrolled (perhaps into a true quarantine network or maybe just = pass them all through to a carefully managed dmz or =E2=80=A6 whatever). = If the device enrolls successfully then you get on the = =E2=80=9Creal=E2=80=9D network. In your scenario then the attacker gain = control over a device that is untrusted and placed appropriately by the = network access control system. But as noted, providing the tools for = this is different than actually defining that integration. I encourage = the network access control folks to address these types of = concerns.

 

- = max



<= p class=3DMsoNormal> 

-Ekr

 


(The = exact nature of the keys depends upon how the voucher is used.
In = BRSKI it's to bootstrap an EST connection, while in some versions of = the
6tisch, actual 802.15.4 keys are return.  NETCONF uses this = new trust to
permit the owner to reach in and do configuration with = RESTCONF)


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


 

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

 

 

 

 

------=_NextPart_001_03D7_01D374CB.8EE03DC0-- ------=_NextPart_000_03D6_01D374CB.8EE03DC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjE0MTgwNjE0WjAvBgkqhkiG9w0BCQQxIgQgyNXWJaN+zlgjdSB4divmqC/MZVbM +vm7DMvf6zPcmgMwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMDkpk+hBWgP23kZd97vdjnHtgjwYniZ3J71rCZcV380LQrpVAuaWvxCjM4XbtKgfI3NMKbB YhwjHhC0RemVsg7D9qxJpMryx2O0yEErAFS+1Cazn36jSY9eU1fQPMWA5b7819seGbSuExuhzGX4 KHh8GqfgQTDHT2EQmgBKs4q1Czx4+LM4s/68pDj0ohk4EzjAGeAIZGXZIAKopnQ33P+raXtAarjX eXVqcroO+9BtR3XPcFfZD/eNbzFBDhsUZi65i59bk8tFK5HsyQ9q3fPLEbvTrn7nFTgpnLBWldxt k2DYJ9SeiquItDj1hHNDULaY/CXpgPXBN3aWKMl6uKoAAAAAAAA= ------=_NextPart_000_03D6_01D374CB.8EE03DC0-- From nobody Thu Dec 14 10:21:04 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CB012704A; Thu, 14 Dec 2017 10:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkABXKa3vF_4; Thu, 14 Dec 2017 10:20:59 -0800 (PST) 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 5C833127010; Thu, 14 Dec 2017 10:20:59 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E03FC58C4F9; Thu, 14 Dec 2017 19:20:54 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id CADE6B0D46C; Thu, 14 Dec 2017 19:20:54 +0100 (CET) Date: Thu, 14 Dec 2017 19:20:54 +0100 From: Toerless Eckert To: Tim Hollebeek Cc: Eric Rescorla , "Max Pritikin (pritikin)" , Michael Richardson , "draft-ietf-anima-voucher@tools.ietf.org" , Anima WG , IESG Message-ID: <20171214182054.GA30012@faui40p.informatik.uni-erlangen.de> References: <20171214074157.GC19390@faui40p.informatik.uni-erlangen.de> <3100.1513266018@obiwan.sandelman.ca> <29D1A62E-B717-4E62-85FF-BA194AB2DEDB@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 18:21:02 -0000 Tim, Eric: As a co-author: I think it would be great to get proposed explanatory text about context from you. Especially because authors are often so engulfed into the problem space that they overlook to address what they think is obvious (and actually is not). As WG-chair: of the explanations discussed in this thread where specific to ANIMA/BRKSI, but the voucher mechanism itself is meant to applicable beyond it, specifically draft-ietf-netconf-zerotouch, so it would be good if explanations stay as independent of BRSKI specific aspects as possible. Explanations specific to BRSKI hsould be welcome as well (i can not speak for the authors there ;-), but probably should go into BRSKI (as well as of course netconf specific explanations go into netconf). Cheers Toerless On Thu, Dec 14, 2017 at 06:06:20PM +0000, Tim Hollebeek wrote: > I think it would be useful as I had many of the same concerns myself. The standard is intended to support multiple different levels of security, and a wide variety of use cases. And while this is noted in the document, there isn???t much guidance about what the various tradeoffs are, and what you gain or lose by making certain deployment choices. > > > > I would be willing to help draft language to address this. > > > > -Tim > > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Eric Rescorla > Sent: Thursday, December 14, 2017 10:26 AM > To: Max Pritikin (pritikin) > Cc: Michael Richardson ; Toerless Eckert ; Anima WG ; draft-ietf-anima-voucher@tools.ietf.org; IESG > Subject: Re: [Anima] Question on draft-ietf-anima-voucher-06 > > > > This all seems reasonable. I think I understand this better and I really appreciate people being willing to talk it through. > > > > >From my perspective it would be nice if we added a bit more text to the document to explain this stuff. Would people be interested in that? Would they want me to produce text? > > > > -Ekr > > > > > > On Thu, Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) > wrote: > > > > On Dec 14, 2017, at 9:32 AM, Eric Rescorla > wrote: > > > > > > > > On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) > wrote: > > > > On Dec 14, 2017, at 8:43 AM, Eric Rescorla > wrote: > > > > > > > > On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson > wrote: > > > Eric Rescorla > wrote: > > The case I am concerned with right now is the case where the attacker > > just imprints the device and then operates it even though it's in the > > victim's network. > > How can they join the victim's network, if the point of the enrollment is to > provide the device with keys to be able to join the victim's network? > > > > Ah, now I think we're getting somewhere. I had understood the point of the enrollment in this context to be to get it to join the ANIMA fabric, not necessarily the physical network (hence why we have ACP, etc.) > > > > Am I just totally missing the point here? > > > > So, more directly responding to your concern: What happens if the attacker ???just imprints the device and then operates it even though its in the victim???s network???? > > Answer: > > > > If the vendor system has sales channel integration then the voucher signatures provide an optional method of blocking ???attacker imprint??? (because it is no longer trust-on-first-use). This PREVENTS the attack you???re asking about. > > If the victim network operator has appropriate inventory management then BRSKI/MASA integration provides logging inputs into that system to DETECT the scenario you describe, even without sales channel integration. > > > > So if neither of these cases applies, then the attack succeeds? > > > > Correct. My preference is the non-sales channel approach where the network operator has complete control. > > > > > > To be clear, I'm not saying this is a defect in the protocol. I don't know how to fix it. I'm just trying to get clear. > > > > Agreed. I don???t see this as a ???defect??? myself, its a conscious decision to allow flexibility in deployment models. > > > > This is important because secure bootstrapping requires devices to engage in security operations. Doing so runs the risk that something won???t work when needed. Our design choice is to limit the device security operations to the minimal amount: just sufficient for network operator audit or vendor control. This should be more reliably while allowing the the vendor or the network operator can provide substantial security *if they want*. > > > > - max > > > > > > > > -Ekr > > > > > > Once detected, then what? The BRSKI draft has this to say about its protocol flow and network access control: > > > > draft-ietf-anima-bootstrapping-keyinfra-09: > > This document presumes that network access control has either already > occurred, is not required, or is integrated by the proxy and > registrar in such a way that the device itself does not need to be > aware of the details. Although the use of an X.509 Initial Device > Identity is consistant with IEEE 802.1AR [IDevID ], and allows for > alignment with 802.1X network access control methods, its use here is > for Pledge authentication rather than network access control. > Integrating this protocol with network access control, perhaps as an > Extensible Authentication Protocol (EAP) method (see [RFC3748 ]), is > out-of-scope. > > Its even more out of scope for the voucher itself since that is a msg format for ???who should the device trust??? and to trigger enrollment but is even further removed from network access control. > > > > A potential integration is to use ANIMA or BRSKI to manage device enrollment and credential from a quarantine network. The network access control could be configured to segregate all devices that are not enrolled (perhaps into a true quarantine network or maybe just pass them all through to a carefully managed dmz or ??? whatever). If the device enrolls successfully then you get on the ???real??? network. In your scenario then the attacker gain control over a device that is untrusted and placed appropriately by the network access control system. But as noted, providing the tools for this is different than actually defining that integration. I encourage the network access control folks to address these types of concerns. > > > > - max > > > > > > > > -Ekr > > > > > (The exact nature of the keys depends upon how the voucher is used. > In BRSKI it's to bootstrap an EST connection, while in some versions of the > 6tisch, actual 802.15.4 keys are return. NETCONF uses this new trust to > permit the owner to reach in and do configuration with RESTCONF) > > > -- > Michael Richardson >, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu Dec 14 10:42:13 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC24129454; Thu, 14 Dec 2017 10:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg2mxSNP4fLm; Thu, 14 Dec 2017 10:42:10 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A57D128616; Thu, 14 Dec 2017 10:42:10 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id p84so4245846pfd.3; Thu, 14 Dec 2017 10:42:10 -0800 (PST) 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=VqrTjtcvGKuUs97z+N5Cnp3Re/sKvmdD8KHnu3dfhq4=; b=N96I9Mj1pT+qvzjhs9Ogr5do3taXEoa4KoyQtGt2LGMhgngPMxKf+xm2I+oDbmHF6n NzAYCjR6x7ByJwHGHM7Ud803R0KFRlhzS1cqSI8kedUx/cJkgntxqsni0Zsln8fmSugJ Z4R6XgopADjh/nb4PCyQNKaMWC4pFfxZJaNEdeXmTEJvN9Hsm8eHLxna3ijCOiIxu4lG rSzg2odSyb7mdYjzE3O2NchEN8euLdha4gzsc5p7qSDRl2zoXgo0pwNJ5Y1dricynN/O sFAJeiZOediUizfd2X3V7TcMG2RqeEETRlX6CxPkvcyQaJG/W4irg7uugDOQewS3dBSr uD+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VqrTjtcvGKuUs97z+N5Cnp3Re/sKvmdD8KHnu3dfhq4=; b=RXVFC5W5iuGCMsRHMxMe83qj7/yP7cGG0Oj4r9UNXC1/hapJ4i1Vr07PNdCJkoctIo GBvJ17aNtHvoBPiRvPwHFvEwNYcLegzfT7xIri0mea7XUfuzSkAGOMJVoMEA9X8z6veZ VmGpyDDYgWkH0lK2HYn98BUWEZSB54Uaybcoc5w6D/kYh+XqutREtL9TZXTy0cufVNUq Tx4Vo5w3NN06gwKxn6ywmKXvyfPNrml7vVlJuNyGu4ZkAeAm8Yn9I3q95EyWMqmer5HH Gx5I47hjeEV2e7u1Q1d0Nj1yx7cH4BdDWKYmG+1MYbJWmwXVosjKUL1cpL9u6paV8FSO exQg== X-Gm-Message-State: AKGB3mIR/u2FvaF/jN7eRnPRjPUt1lhfrdtmrUofHD1xUaDkRx/gWggK 1o2jo/So1MS/oWR86EDlo2id3w== X-Google-Smtp-Source: ACJfBot4+AyXgDdri5JZQzRmw6nXOHZuKIFL+V6I89IRqlOxYgAcCtskNEty1dY43rStOxWZwFiFGg== X-Received: by 10.99.117.67 with SMTP id f3mr9319601pgn.27.1513276929319; Thu, 14 Dec 2017 10:42:09 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p77sm10054050pfd.132.2017.12.14.10.42.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 10:42:08 -0800 (PST) To: Ben Campbell , The IESG Cc: draft-ietf-anima-prefix-management@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+anima@cs.fau.de, anima@ietf.org References: <151322520961.6124.6728640618034204081.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <407128de-3e9d-cace-82ec-71716c4b583d@gmail.com> Date: Fri, 15 Dec 2017 07:42:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151322520961.6124.6728640618034204081.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) 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, 14 Dec 2017 18:42:12 -0000 On 14/12/2017 17:20, Ben Campbell wrote: =2E..> - On my first reading, I wondered why this was informational. It s= eems to seek > to standardize protocol elements. The explanation in the shepherd repor= t > clarifies that; it would be helpful to include (a perhaps shortened ver= sion of) > that in the draft. Awaiting instructions, but we can certainly do that if there's to be a new version of the draft. >=20 > -2: RFC 8174 has boilerplate to address the "only in upper case" part. = Please > consider using it rather than modifying the 2119 boilerplate. Ack, the RFC Editor could do that too. >=20 > -4.4: "It is therefore important to record all the prefix assignment hi= story." > Isn=E2=80=99t this a local policy choice? Perhaps some operator believe= s in extreme log > minimization, does this mean to argue they are mistaken? I'd say it is a requirement in order to detect or trace lost prefixes after outages, and probably a legal requirement in many countries (once jurisdictions realise that IPv6 prefixes are needed for tracing, not just addresses). But I agree that it isn't a requirement on the protocol defined in this draft, so it should be rephrased. Thanks Brian From nobody Thu Dec 14 11:24:54 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69C212714F; Thu, 14 Dec 2017 11:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QO1Pm1JAt-bI; Thu, 14 Dec 2017 11:24:50 -0800 (PST) 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 6423F124D6C; Thu, 14 Dec 2017 11:24:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E3B8620090; Thu, 14 Dec 2017 14:28:11 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 308AF80678; Thu, 14 Dec 2017 14:24:49 -0500 (EST) From: Michael Richardson To: Eric Rescorla cc: draft-ietf-anima-voucher@tools.ietf.org, IESG , anima@ietf.org In-Reply-To: References: <2509.1513177984@obiwan.sandelman.ca> <1253.1513265567@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Question on draft-ietf-anima-voucher-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: Thu, 14 Dec 2017 19:24:52 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > OK, I think I see where we're starting to talk past each other. I'm > not assuming that the device ever tries to connect to the device > owner. > Let me walk through the first attack I'm talking about here and you > can tell me what I'm missing. > 1. I compromise a device before it enters your network. Maybe I load > new firmware, but let's assume I don't for now. okay, so you have a device you have administrative control over, and you put it back in the package. > 2. You buy the device and install it, but for some reason don't > explicitly try to imprint it (perhaps because you have a lot of them > and so expect them to auto-imprint). I buy 100 of these devices and I get one of yours, and I don't notice that they did not all auto-imprint. How do I install it? > 3. The device doesn't ever try to connect, so it's still being managed > by me, even thought it's in your house. If it's wired, I can see that I can plug the wire in, and it calls home to you or UPnP's or something, and you have access to it. I agree: my network is toast at that point if it's wired. If it's wifi or 802.15.4, it doesn't have a network key, so it sits there dead. If I have an open wifi (I used to, but my neighbour found it hard to discipline her teenager, so I turned it off), and the device does a scan to find a network and picks it, then I'm toast. But, I had an open wifi, so you didn't need to trojan me. > I assume you either think that (a) this can't happen for some reason I > don't understand or (b) it's just out of scope. Can you help? I think that it's out of scope for the *voucher* document. I think it's out of scope for many uses of BRSKI, but not all. So let's continue for a bit. Let's go back to 2012's workshop discussion: We assumed that it really is the case that the price difference between smart light bulbs and light bulbs has become negligible such that all light bulbs are smart. Smart bulbs, when in "legacy" mode (either because they are not imprinted, or because you put them back into that mode) do the obvious thing: turn on when there is AC, and turn off when there is no power. So the attacker has thousands (millions!) of smart light bulbs being bought and "installed" by home owners who simply don't know or care that they are smart. The light bulbs work in the way they always have. We already know that many of these bulbs will form a mesh, and since the attacker has initialized them all with his mesh key, if they find any bulbs nearby, they will link up. If one of them can find open wifi, or can find an exploit in a wifi chipset/security stack, then the entire mesh gets online and calls home. We have seen these situations in the wild already. Will the attacker ever have enough bulbs to damage the grid? Could happen. A better use of the access to free (stolen) electricity might be to mine for bitcoin whenever the bulbs are on, but I doubt there is ram space to do that in the bulbs. Audit vouchers don't prevent this; by allowing the attacker to imprint the bulbs without sales channel integration they enable this attack. I'd be happy to put this into a Security Considerations, but I'd rather put it into the BRSKI document (draft-ietf-anima-bootstrapping-keyinfra) than in vouchers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloy0AAACgkQgItw+93Q 3WVcMAf+IX7WCknNXUH2Y6te2zmYYd8a57gqWbvgtIYcIUbP6NhrgvoiC0w2B8Bs WlLRodWFRK2oXoNcBnd+Cfp7U1xhZ0sKHin54z04PHXVp8/DA5Pv7xCPC9AGSuMZ xmkHdQJYXWxHPbnpd1PuIszsFz0Mnio8K37ebSsScQ/n3FwnyfcujNb0C/YrxK+9 BtOekkoJyUQ534G24gttL3BUdi0S/3HdrWoE1p7GOpfS7CI+c6lvAn1SWxgXx/HV R0fFxetpq/uKxZC6ah7uvqpWFPEixxyaPS8DuEbsQk5TKb4WGTvEZ8oKsRh+wDpr ue9qsVTcKF9+1Tb0Qmb74kcjT3RTog== =lwnc -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 14 15:16:11 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD8127775; Thu, 14 Dec 2017 15:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 ndqn8Ez9yXfu; Thu, 14 Dec 2017 15:16:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8145A12714F; Thu, 14 Dec 2017 15:16:05 -0800 (PST) Received: from [10.0.1.99] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vBENFr9i048024 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Dec 2017 17:15:53 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.99] From: Ben Campbell Message-Id: <218EBB0B-FEAF-4AA9-90BE-268E613F0686@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3A246D62-3DF2-4F94-85CA-3921D9A77826"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 14 Dec 2017 17:15:52 -0600 In-Reply-To: <407128de-3e9d-cace-82ec-71716c4b583d@gmail.com> Cc: The IESG , anima-chairs@ietf.org, draft-ietf-anima-prefix-management@ietf.org, Toerless Eckert , tte+anima@cs.fau.de, anima@ietf.org To: Brian E Carpenter References: <151322520961.6124.6728640618034204081.idtracker@ietfa.amsl.com> <407128de-3e9d-cace-82ec-71716c4b583d@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT) 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, 14 Dec 2017 23:16:09 -0000 --Apple-Mail=_3A246D62-3DF2-4F94-85CA-3921D9A77826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just to close the loop: All of Brian=E2=80=99s responses look fine to = me. Thanks! Ben. > On Dec 14, 2017, at 12:42 PM, Brian E Carpenter = wrote: >=20 > On 14/12/2017 17:20, Ben Campbell wrote: > ...> - On my first reading, I wondered why this was informational. It = seems to seek >> to standardize protocol elements. The explanation in the shepherd = report >> clarifies that; it would be helpful to include (a perhaps shortened = version of) >> that in the draft. >=20 > Awaiting instructions, but we can certainly do that if there's to be > a new version of the draft. >=20 >>=20 >> -2: RFC 8174 has boilerplate to address the "only in upper case" = part. Please >> consider using it rather than modifying the 2119 boilerplate. >=20 > Ack, the RFC Editor could do that too. >=20 >>=20 >> -4.4: "It is therefore important to record all the prefix assignment = history." >> Isn=E2=80=99t this a local policy choice? Perhaps some operator = believes in extreme log >> minimization, does this mean to argue they are mistaken? >=20 > I'd say it is a requirement in order to detect or trace lost prefixes > after outages, and probably a legal requirement in many countries > (once jurisdictions realise that IPv6 prefixes are needed for tracing, > not just addresses). But I agree that it isn't a requirement on the > protocol defined in this draft, so it should be rephrased. >=20 > Thanks > Brian >=20 >=20 >=20 --Apple-Mail=_3A246D62-3DF2-4F94-85CA-3921D9A77826 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlozBigACgkQgFZKbJXz 1A3gYBAAvhNJF3gHrzPT6LSxlc3B81dv8gzzYYeWnKCXmxzR0ppnU+UwCzjPXFES TT82aRwv8g2yF+wBdFevaKW3e3CCS/2VajJIGFf/GJdFrsjYQwftlpSwaHTo8vRP GR+tvAFvPIHQKFX4y1dirNkVWhXFCxhNC/N17bmHWi0+KzyxS9oTx6oqP4EuZaI9 ePbXC7Jidj/54Wot+AhOoQdNTrE6keSwuc/NQxM2mJfrsxkoV2t5ImeO0E3FlYAR 0Qmwqc0kE9FKyV202Qo4Ro4xotwTAU86lwFG/7sWuFsX+XQ4zSknoGbh73pc4VZB xXJGD8qTlDEAN3RY3liWkGbxXYX0rvTbiJ4zrrhjgq5CSedGePDqz/BWm7FLxcwZ VfytqecC/6QP/DK5MUz+riv74F1cc+ppmjlO9MnUDFR0giTvZ7ar0rCHuhqmEJLm 42u6vGJeJVvquTXeWTKV6DRf605JUsHtuiaurtn8Y5L09glsVQQ/8FLQNPKyc2Q/ +z4IY2Cm9qRmyyOTqBGLgX4sFrpE0ltxIfT1hbmdHbdSEZdqYFGmXRx7LuUeYOvj ETDk+wR4g8HKClVvJ4US2NYPiNbYNnV8iKZMmnZbpECFKNXApIUx467BBfysO0ZU 6fwt2M5CVwQuCA2jSN5OV/jjwz3cmvk1mrYSS2YKLUIt6CaA3VI= =9Rms -----END PGP SIGNATURE----- --Apple-Mail=_3A246D62-3DF2-4F94-85CA-3921D9A77826-- From nobody Fri Dec 15 06:24:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A5B1252BA; Fri, 15 Dec 2017 06:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 agBivf6a_I3G; Fri, 15 Dec 2017 06:24:34 -0800 (PST) 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 D31F6124205; Fri, 15 Dec 2017 06:24:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B3E920090; Fri, 15 Dec 2017 09:27:59 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 17883814B3; Fri, 15 Dec 2017 09:24:34 -0500 (EST) From: Michael Richardson To: Adam Roach cc: "The IESG" , anima-chairs@ietf.org, draft-ietf-anima-voucher@ietf.org, anima@ietf.org, jiangsheng@huawei.com In-Reply-To: <151323291963.6071.13432030924018362994.idtracker@ietfa.amsl.com> References: <151323291963.6071.13432030924018362994.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Adam Roach's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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, 15 Dec 2017 14:24:37 -0000 --=-=-= Content-Type: text/plain Adam Roach wrote: > among them. I'll note that these techniques relate to MIME types and > related > data (filename extensions). The fact that *this* document doesn't > define a MIME > type for the CMS-signed-JSON variant will make it difficult and/or > awkward for > these future formats to employ these techniques. For example, if I were In the first use of this format over HTTPS, which is "BRSKI", We register parameters for the application/smime-type. Since that we written we changed the "primary" signing type from PKCS7 to CMS, so I think that these will become application/cms registrations instead. https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-09#section-7 > This document requests the following Parameter Values for the "smime- > type" Parameters: > > o voucher-request > > o voucher As for .vcj extension, that's a good idea. I think that NETCONF could register something. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloz2yEACgkQgItw+93Q 3WVfaggAtlQP3p6djcNQwKNQ2dpxfMrmnoo0fxrIFSD0NGkVdOwBBlplMm6AA9Ta 0/5XQiZ9YbYatskjg3lVgo89cqKu7KvHM2F7wpI2dh25APgGfS1FHVATYSjV1kNz M/L3LZnmuf4+0NCzEITJM4xHHoVBtRcupFcdyFOfjwTz1Xd5P0EqTWD0uMUDdBxC 7ru1/FI59D9Ff3supYiIxmNT3xXroSrhj6cStc7dyS5QF9cqQhnMIoUWdVm8ENIT iw8gfF74DbNeEKGrbYlP8dEsVcmhzde1II9dz53RUYmBvBipI80Ef8Q8CphX7fZe 2sC31hpPS6JSEVt15tGZq4pp6VgS7g== =t02V -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 17 04:11:20 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A817120727; Sun, 17 Dec 2017 04:11:14 -0800 (PST) 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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151351267406.6794.7618603434173760376@ietfa.amsl.com> Date: Sun, 17 Dec 2017 04:11:14 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-13.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: Sun, 17 Dec 2017 12:11:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-13.txt Pages : 109 Date : 2017-12-17 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM (Operations Administration and Management) communications over a network that is secure and reliable even when the network is not configured, or not misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-13 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-13 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 Sun Dec 17 04:14:37 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2EB12895E for ; Sun, 17 Dec 2017 04:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOwFOkrCp_8N for ; Sun, 17 Dec 2017 04:14:30 -0800 (PST) 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 0771D12785F for ; Sun, 17 Dec 2017 04:14:29 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3A39258C4C0 for ; Sun, 17 Dec 2017 13:14:24 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1F903B0D4A8; Sun, 17 Dec 2017 13:14:24 +0100 (CET) Date: Sun, 17 Dec 2017 13:14:24 +0100 From: tte+ietf@cs.fau.de To: anima@ietf.org Message-ID: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] Review reply: Re: WGLC on draft-ietf-anima-autonomic-control-plane-12 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, 17 Dec 2017 12:14:36 -0000 This email is coalescing the replies to the comments received from ANIMA WG last call against version -12. Comments where received from: Bill Atwood, Brian Carpenter, Michael Richardson, Yongkang Zhang Thank you very much! -13 was just posted and hopefully answers all the concerns raised. Changes include mostly non-semantic changes such as additional terminology, additional/refined explanations, bugfixes (ULA calculation, addressing bitlengths), formatting and clarification of "must/not" to "MUST/NOT" (security profiles for secure channels). Main semantic refinements where done for - 6.3, AN_ACP GRASP objectives (simplified, only one secure channel method/objective permitted) - 8.2.1, manual config of remote ACP neighbors - removed "patterns" and simplified/fixed CDDL model and rewrote the explanations. - Use of Zone-ID != 0 in grasp locators to achieve desired goal of smaller routing tables (when those zones are used in future). For diff, see: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-12.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-13.txt List of change usual in changelog. Replies to each pointed raised below, coalesced by reviewer. Thanks! Toerless ------------------------------------------------------------------------------ From: Brian Carpenter: ------------------------------------------------------------------------------ > Here's my first comment on this draft. However, it is very long and I hope you can allow some > +extra delay. > > As far as the two GRASP objectives are concerned, both "AN_ACP" and "SRV.est" > look mainly OK and I have made a demonstration implementation of both of them. > [...] > I do have a question about the value field of each of these objectives. > They are both defined as "name of the (list of) of supported protocols" > but the examples show a simple string. That needs to be more precise. > Is it a string, a list of strings ["abc", "def"] or something else? Good question. Had to revisit format and text before being able to satisfactory answer. Luckily it simplified things: SRV.est - Only empty objective-value required/beneficial now: Modified text: The objective value "SRV.est" indicates that the objective is an compliant EST server because "est" is an registered service name for . Future backward compatible extensions/alternatives to my be indicated through objective-value information. Future non-backward compatible certificate renewal options must use a different objective-name. Explanation: Because the objective-name indicates RFC7030, we do not need "EST-TLS", and can not really have incompatible options indicate in it: If we would use DNS-SD/mDNS instead of GRASP, the same would be true (IANA registration for "est" shows no TXT assignments!). For example, some CoAP based cert renewal would require a new service name for DNS-SD because it wouldn't be compatible with rfc7030 (at transport level). A BRSKI server instead is compatible, so it could be announced via SRV.est for cert renewal. If there would be future extensions to 7030 that are backward compatible, we would indicate that in DNS-SD TXT and in GRASP objective-value. At that time i would prefer the encoding i am suggesting in the GRASP DNS-SD draft. AN_ACP - No arrays of strings required now, just a single method string per objective! Explanations: Different methods may require their own locators. In that case they most easily go into their own objective. So it is sufficient that objective-value = string = single method. I don't really see a need to add more on-off alternatives like multiple strings in an array right now. ANd if one of those new methods would require some more parameter, it would get even more complex. So i removed that option. And i hope we're having those discussions when looking at the extensible format proposed in GRASP-DNSSD (which is applicable even without being DNS-SD compatible. Changed: I changed the example to show two objectives, one for "IKEv2", one for "dTLS" together in the same message. That is along the lines of above explanations. (Keep It Simple Stupid). Also removed paragraph indicating that we could have multiple methods per objective. > And do the names need to be registered? I guess we could, but i would rather go the lazy route and do it when we really see that we need to add more options. Registries that never get used are a waste of effort for IANA. I think to remember that we did the same on some IP multicast protocol parameters as well (late registration when we saw extensions popping up). > Here are my comments from a superficial re-read of the whole document. I only > spent about an hour on this, so document shepherd and AD please note: > this document really needs multiple reviewers. > > Nits and substantive points are mixed together. > > Introduction, page 5: > > > The following sections are non-normative: Section 7 reviews benefits > > of the ACP > > Actually that should be Section 9. I really hope you are using > for all internal references. Otherwise there will be a disaster when > this goes to the RFC Editor. Fixed. Yes, all xref'ed, but somehow overlooked fixing this one in some edit. Not sure how this happened. > Introduction, page 6: > > > The ACP as defined in this document can be implemented and operated > > without dependency against other components of autonomous networks > > Please don't use "autonomous". It doesn't mean exactly the same as > "autonomic". This occurs in 4 places in the draft. (Autonomous cars drive > themselves. An autonomic car would also decide for itself where to go.) Done. > Acronyms and Terminology, page 7: > > > domain information (field): An rfc822Name information element (e.g.: > > field) in the domain certificate in which the ACP relevant > > information is encoded: the domain name and the ACP address. > > You need to define "domain certificate" too, even just a forward > reference since it is well explained later in the draft. Hmm... The first instance of referring to domain certificate is actually in the "ACP address" definition. I have now tried to put a forward reference to the definition of domain certificate in section 2 into it, but its kinda quirky: An IPv6 address assigned to the ACP node. It is stored in the domain information field of the ACP domain certificate. A provisioned certificate (LDevID) carrying the domain information field which is used by the ACP to learn its address in the ACP and to derive and cryptographically assert its membership in the ACP domain. xml2rfc turns this reference into: ACP address: An IPv6 address assigned to the ACP node. It is stored in the domain information field of the ACP domain certificate (Paragraph 21). ^^^^^^^^^^^^^^^ I would imagine that the xref works better for any format that can insert xrefs as metadata (HTML/PDF), but for text its really ugly. My idea was to NOT have references in the terminology section because of this -> xrefs to other terms (see above) are ugly in text. -> refs to other sections defy the purpose of quickly just getting definitions. (i think i added a few just to reply to feedback from reviewers, even though i didn't like it). Maybe we let this one instance ("Paragraph 21") in and get back to this later when the doc is in the RFC editor queue. Those folks may have better ideas for this formatting problem. > Also, somewhere in the terminology section, can you give a relevant > definition of "loopback interface", since we have established via > the 6man list and even the internet-history list that it is a > slippery concept. Something like: > > loopback interface: The conventional name for a neutral virtual > IP interface to which addresses may be assigned, but which > transmits no external traffic. The conventional name for an internal IP interface to which addresses may be assigned, but which transmits no external traffic. > In Overview, page 13: > > > Note: > > > > o Non-autonomic NMS ("Network Management Systems") or SDN > > controllers have to be manually connected into the ACP. > > The phrase "manually connnected" bugs me a little. I agree there > needs to be a human decision but that will be a configuration > decision; the actual connection process will be automated. > How about "manually configured for connection into the ACP"? changed to: "explicitly configured for connection into the ACP" > > o Connecting over non-ACP Layer-3 clouds initially requires a tunnel > > between ACP nodes. > > > > o None of the above operations (except manual ones) is reflected in ^^^^^^^^^^^^^^^^^^ > > the configuration of the node. > > That sentence illustrates exactly why "manually connected" is wrong. changed to: "except explicit configured ones" Also removed a few more instances of "manual" and replaced with "explicit". Really just left it in for the 'Manual Addressing Sub-Scheme" because i am not sure another name would better ("Traditional EUID64 addressing sub-scheme" ??). > In ACP Adjacency Table, page 20: > > > To know to which nodes to establish an ACP channel, every ACP node > > maintains an adjacency table. The adjacency table contains > > information about adjacent ACP nodes, at a minimum: node-ID, Link- > > local IPv6 address (discovered by GRASP as explained below), domain, > > certificate. > > You must also include the interface index (the number, not the name) > with the LL address. Without that, the address is useless. (Discussed > with Michael B a long time ago, but somehow it didn't make it into > the reference model text.) See after your next comments... > (I write as one who has coded the process of discovering a node's > link local addresses and interface indexes, because GRASP can't run > without them.) > > [insert Brians comment from another thread] > > I commented elsewhere that the ACP adjacency table needs to include > the interface index for link-local addresses**, and that is in fact > exactly what RFC 4007 calls the "zone index". So unless we make > this excessively clear, we can be certain that some readers will > get the two things mixed up. > > ** How you determine the interface index is o/s dependent, so > it's important to put this in the adjacency table, for maximum > portability of code. Fixed adjacency table text to indicate that "interface" where neighbor was learned from must be included. This is likely the interface index, but i wanted to be as generic as possible. Some implementations may use e.g.: some interface name/number, which would be sufficient as well. I added some text about zone_id intot he terminology section. The relationship between zone_id and interface index is kinda quaint: In the figure 1 example in rfc4007, there is a link-local zone with two interfaces. Theoretically we really would need to track those link-scope zone_id's instead of interfaes (whether its interface-id or name/number). But practially speaking, i have never seen a product that supports this example model directly. Instead, i have only seen the approach where you would have to create a virtual interface, such as an "etherchannel interface" and bind tht to interface2/interface3 in figure 1, and "e voila", that new virtual interfaces interface-id is equivalent to a quirky link scope zone_id. I also asked this on ipv6@ietf.org. Lets see if anybody comes up with evidence that there is really in reality a different namespace for link scope zone_ids vs. interface IDs. I'd be surprised. > Also - this text duplicates the reference model. We'd perhaps better > agree where it belongs and delete it from one draft or the other. > Duplicated text always causes problems later. The standards track documents (GRASP, ACP, BRSKI) are meant to not depend on the reference model for their normative definitions, and this is a normative text of ACP, so we can not get it from reference model. If you think the text in reference model is redundant, that must therefore be a discus against reference model. I wouldn't change reference model here either: I think this is benign duplication because you also want to be able to read through the reference model without unnecessarily having to dig into BRSKI, ACP or the like. > In GRASP as a core service of the ACP, page 28: > > > The ACP does not use IP multicast routing nor does it provide generic > > IP multicast services. > > However, GRASP sends multicasts to the GRASP multicast address on each > ACP interface, sent as unicast inside the ACP tunnels. This is fully explained > later, but the reader might be confused. I suggest adding: I guess i am too much of a multicast geek that i am not confused: "no IP multicast routing" means "does not use any multicast other than maybe link-local ip multicast". > The handling of GRASP multicast messages is explained in the following section. Added: (the handling of GRASP link-local multicast messages is explained in the following section). > In Addressing inside the ACP, page 33: > > > Links inside the ACP only use link-local IPv6 addressing, such that > > each node only requires one routable virtual address. > > Does the really mean each *node*? Can we have more than one ACP instance in > a node? And didn't we discuss some use cases for multiple addresses recently? Fixed to "each nodes ACP only requires..." ^^^^^^^^^ We did not really conclude on defining how to use multiple ACPs within a node. Too late for this RFC IMHO. COuld be interesting followup work, we discussed it in 2015/2015 for VMs. > A related but more general question: > > If there are multiple GRASP instances in a node (ignoring the DULL case), > does each instance require its own ACP unicast address and its own ACP > security associations? (I hope the answer is "No".) If you had multiple ACPs, i am sure each ACP would have its separate loopback address. These are different addressing domains anyhow, so really no way to avoid this. Even if it would be the same addresses (like having multiple times the same rfc1918 address in different VRFs - counts as different addresses). > In Combined ACP/Data-Plane Interface (VRF Select), page 57: > > > In result, RFC6724 source address selection Rule 5.5 may result in > > the same correct source address selection behavior of NMS hosts > > without further configuration on it as the separate ACP connect and > > data-plane interfaces. As described in the text for Rule 5.5, this > > is only a may, because IPv6 hosts are not required to track next-hop > > information. > > Well, you can change this by requiring RFC8028. Added to end of paragraph: Hosts implementing should (insead of may) implement Rule 5.5, so it is preferred for hosts to support Too bad 8028 did make this only a SHOULD but not MUST. I can not see a reason why not supporting it would ever be beneficial. > In Configured Remote ACP neighbor, page 58: > > > remote-peer = [ local-address, method, remote-address ] > > local-address = ip-address > > remote-address = transport-address > > transport-address = > > [ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ] > > ip-address = (ipv4-address | ipv6-address ) > > method = "IKEv2" / "dTLS" / .. > > pattern = some IP address set > > Hmm. This seems a bit loose for normative text. What's ".." > and what's the format of "pattern"? Hmm... I am not going to come up with some pattern definition because its not really important and too much work and CLI's are different. So, i rewrote this text to just indicate "any" as an option. I ended up rewriting this section because there was more loose text and confusing CDDL definition (needed to get "any" in, "protocol" not needed, pmtu in a strange place, port not necessary for every method,....). >Subject: Re: [Anima] Fwd: Section 6.10.2 of draft-ietf-anima-autonomic-control-plane > > from Brian Carpenter: > > This is particularly important since "zone" and "zone index" and > "zone_id" are used in a completely different sense in RFC 4007 and > other RFCs that depend on RFC 4007. In fact, it might be worth > a note that this is different from that. Added to the zone addressing section: Note: Zones and Zone-ID as defined here are not related to zones or zone_id. ACP zone addresses are not scoped (reachable only from within an RFC4007 zone) but reachable across the whole ACP. An RFC4007 zone_id is a zone index that has only local significance on a node, whereas an ACP Zone-ID is an identifier for an ACP zone that is unique across that ACP. Also added to section 2 (terminology): An ACP zone is a connected region of the ACP where nodes derive from their non-aggregatable ACP address (identifier address) an aggregateable ACP zone address (locator address). See the definition of the ACP Zone Addressing Sub-Scheme (). The complete definition of zones is subject to future work because this document does not describe the routing protocols details for aggregation of ACP zone addresses, but only their addressing scheme. ------------------------------------------------------------------------------ From: William Atwood ------------------------------------------------------------------------------ Subject: Re: Technical comments on draft-ietf-anima-autonomic-control-plane-12 (part 1) > Bill Atwood, part 1: > > Hi Bill, > > > > Thanks for the review. Let me comment quickly. Will do the fixups > > after Sheng has made determinations. > > > > > > Inline... > > > > On Tue, Oct 24, 2017 at 10:35:56PM -0400, William Atwood wrote: > >> Hello, > >> > >> These are my technical comments on this draft, for the first 32 pages. > >> Given the length of the document, I do not expect to be able to finish > >> it by October 28, so I second Brian's request for additional time. > >> > >> Bill > >> > >> 1) The definition of "ANI" in Section 2 says that it includes ACP, BRSKI > >> and GRASP. The statement of Requirements in Section 4 says: > >> > >> "ACP4: The ACP MUST be generic. ... It MUST NOT be tied to a particular > >> application or transport protocol." > >> > >> These two statements are in conflict, because the ANI as defined in this > >> document clearly depends on GRASP. > > > > Actually, the ACP does depend on GRASP too (eg: to find neighbors, > > and also because it defines ACP-GRasp to be core part of ACP services). So > > no need to bring in ANI ;-) > > > > I did respond to this point somewhere deep inside of one of the long reviews > > from Brian or Sheng i think, so let me repeat: > > > > AFAIK, the origin of ACP4 was in the early history of ANIMA: We first > > brainstormed how we could build out ASA solely using one standardized > > transport/session layer protocol and in result, we could make the > > underlying infrastructure (ANI) very simple. In technical terms, think > > how we could have NOT built the ACP as a virtualized IP inband network > > but if we would have simply built out GRASP and then ANI was just GRASP, > > In the extreme, there would be no IP hop-by-hop forwarding in ACP, > > but every unicast communication between two ASA would be hop-by-hop > > forwarded by GRASP. No need to build a whole VRF around ACP etc. pp. > > > > In the end we concluded that this was too bold to gain short term > > attaction, and i also was worried about performance even for GRASP > > unicast if we didn't rely on existing forwarding plane mechanisms such > > as end-to-end IP/TCP/TLS. Now if we do get a lot of adoption of ASA > > with only GRASP then we can of course bring "ANI-lite" that would potentially > > do this.. But first we got to kill a huge lot of legacy. > > > > So thats how ACP4 requirement came along. > > > > I changed in to "application or transport" through the last review, > > but i agree that this still does not well explain. > > > > How about "Clients of the ACP MUST NOT be tied..." > > ^^^^^^^^^^^^^^^ > > (instead of "It") > > Works for me. Done. > >> 2) As a specification, Step 4 in Section 5 is terrible. Step 3 > >> explicitly includes the "for-loop". Step 4 then shifts to the > >> perspective of an individual peer relationship, and uses the singular in > >> the first sentence. It then shifts again to the plural for the second > >> sentence. Suggested text: > >> > >> "4. For each node in the candidate peer list, it then establishes a > >> secure tunnel of the negotiated type. The resulting tunnels are then > >> placed into the previously set up VRF. This creates an overlay network > >> with hop-by-hop tunnels." > > > > Thanks. Unless there are counterproposals, i will put that into 13. Done. > >> 3) In Section 6.1.1, in the comment on "routing-subdomain", it says, > >> <<"rsub" is optional and should only be used when its impacts are > >> understood.>> Who must do the understanding? What is the test for > >> "understanding"? Is this a statement that "rsub" should not be used > >> until the WG has done more work, or until the reader has read this > >> document 42 times, or ?? For a normative section of this document, this > >> is remarkably ambiguous. > > > > In my university in 1988?, every student had to sign the following > > statement before he/she got an account: "i hereby declare that i > > will not execute commands whose impact i do not understand". The more > > i learned of unix then, the more hilarious that statement beame > > over time. Every decade i now flip between "that was terrible" and > > "we really need to reintroduce this". > > > > Practically speaking: > > > > Before introducing rsub, older versions of ACP had a lot of hand waiving about > > subdomains, and open questions how they would tie in with mutual authentication, > > addressing and so on. All sounding harmless by using the word > > "intent" in many places. So i sat down and tried to figure out how i would > > make it work. I think its now implementable. But the primary benefit > > i see is only in being able to reduce routing tables, because rsub gives > > you multiple ULA prefixes, and you could auto-aggregate those. Only tht > > we have not sat down trying to specify a standard auto-aggregation. And > > i don't know how difficult that would be. So with that uncertainty in > > mind, using rsub now is a bit like starting to use IPv6 when you > > have all the IPv4 address space in the world. You are investing > > in an uncertain future (don't think 20/20 hindsight ;-) > > > > So... given those more detailled insights, how do you think > > we could better warn the user of this option ? > > > > "Benefits of using rsub may depend on future work in enhancing routing > > for the ACP" ? > > How about this little expansion: > > "rsub" is optional; its syntax is defined in this document, but its > semantics are for further study. Understanding the benefits of using > rsub may depend on the results of future work on enhancing routing for > the ACP. Done. > > But maybe i am overlooking other possible benefits. > > > >> 4) In Section 6.2.3, para 1, line 3, "must" -> "MUST" (I believe that > >> this requirement should be normative.) > > > > There is no 6.2.3 in acp-12 ;-( > > sorry, this should be 6.1.3. Done. > >> 5) In Section 6.7.2, para 2, line 4, "and not permit" -> "and MUST NOT > >> permit" (The implied dependence on the previous "MUST" should be made > >> explicit.) > > > > Ok. Done. Also added an equivalent "MUST NOT permit weaker crypto options" to IKEv2 section. I bet Eric (sec AD) will have further refinement wishes.. ;-) > >> 6) In Section 6.8.2, para 2, I was puzzled by the statement that the ACP > >> could exist in the absence of any active ACP neighbors, since the ACP is > >> only created with the help of a neighbor that is already a member of the > >> domain. I then realized that domain membership (and its accompanying > >> domain certificate) could be established while a neighbor was active, > >> and then the neighbor could vanish. I suggest adding some text to make > >> this sequence of events clear. Suggestion: "It is created when the node > >> has a domain certificate, and continues to exist even if all of its > >> neighbors cease operation." > > > > Ok. Done. From: william.atwood@concordia.ca Cc: anima@ietf.org Subject: Technical comments on draft-ietf-anima-autonomic-control-plane-12 (part 2) > Subject to correction of the points below, and some non-technical > suggestions sent to the document authors, I believe that this document > is ready to publish. > > Bill > > Technical issues > > 1) Somewhere, the document needs to have a definitive reference to the > definition of a VRF. If no such reference exists, then a definition of > Virtual Referencing and Forwarding must be given inside this document. > This could be included in the explanation of VRF in Section 2, or > inserted at an appropriate place in the subsequent text. Updated the section 2 definition as follows: The ACP is modelled in this document as a "Virtual Routing and Forwarding" instance (VRF). This means that it is based on a "virtual router" consisting of a separate IPv6 forwarding table to which the ACP virtual interfaces are attached and an associated separate IPv6 routing table. Unlike the VRFs on MPLS/VPN-PE () or LISP XTR (), the ACP VRF does not have any special "core facing" functionality or routing/mapping protocols shared across multiple VRFs. In vendor products a VRF such as the ACP-VRF may also be referred to as a so called VRF-lite. So yes: There really is IMHO no good definition in RFCs for the type of VRF we want even though it is quite common in deployments: VRF to build VRF lite like solution , aka: not requring any specific "core-facing" encapsulation technology support like MPLS-VPN, LISP or the like. The only reference to VRF-lite i could find was RFC8151, and no - i am not going to use that reference because that vendors web server URLs have a pretty low t1/2. > 2) The ACP is defined in various ways in the ANIMA documents. I don't > like any of the ones that I have seen in published documents; I find the > one in Section 3.1 of draft-ietf-anima-reference-model-05 to be > particularly opaque. It is very important that all definitions of the > ACP (in the reference model, in the ACP document, etc.) say the same > thing. The one that I like best was suggested by Brian Carpenter in a > discussion with me and some others: > > "The ACP is the secure transport substrate that is *used by* the ANI > for its interactions with other *autonomic* nodes and services." > > I hope that a good definition can be agreed to by all document writers; > the important thing is that we not be seen as saying different things in > different documents. -> The ACP as we define it here is primarily a secure and resilient network (layer) substrate, not a transport substrate. Only for ACP GRASP did we make it also go up all the way to transport layer. The decision to do so came late in the process as part of GRASP IESG security review. We wanted to give solutions that use GRASP the freedom to define and IESG-defend the security and congestion-control/reliability used for GRASP. -> The terminology we use in various documents necessarily is evolving the more we learn. For example, RFC7575 does not mention the term ANI, but it does mention ACP. The reason is that ANI was the IETF political term we did only introduce after 7575 when forming ANIMA WG to describe the subset of an AN network that ANIMA wold be chartered to work on. -> In the ANIMA charter, ACP is part of ANI and not as Brians definition from above may make it look like only "used by ANI". -> In draft-ietf-anima-reference-model, a lot of terms are using the ANI prefix, and i did change those in the ACP draft to an ACP prefix because ANI also mandates use of BRSKI and one goal of the standards track RFCs of ANIMA (GRASP, BRSKI, ACP) was that they should all be reuseable by themselves, so any use of ANI-* in ACP RFC would impley a need to support BRSKI (which we'd love, but which would make reuseability without BRSKI difficult). So, in light of these terminology explanations, i would like to claim that the definition of ACP in section 2 of the ACP draft is actually not too shabby: "Autonomic Control Plane". The Autonomic Function as defined in this document. It provides secure zero-touch transitive (network wide) IPv6 connectivity for all nodes in the same ACP domain as well as a GRASP instance running across this ACP IPv6 connectivity. The ACP is primarily meant to be used as a component of the ANI to enable Autonomic Networks but it can equally be used in simple ANI networks (with no other Autonomic Functions) or completely by itself. I did add the detail about the ACP GRASP instance in response to this discus, so i hope that makes the definition maybe not as elegant as Brians, but more complete, explanatory and correct. > 3) Section 6, para 2, line 3. "following ACP specific information field > in its domain certificate" -> "ACP specific information in the xxx field > of its domain certificate, as specified in Section 6.1.1," (The word > "following" refers to something that is 5 paragraphs away, and so is > ambiguous. It is important to be specific here. Fixed to: The ACP does not mandate specific mechanisms by which this keying material is provisioned into the ACP node, it only requires the Domain information field as specified in in its domain certificate as well as those of candidate ACP peers.... > Note: I cannot tell > from the text what field of the domain certificate must contain this > information, so I have written "xxx". Please make the appropriate > substitution.) The whole Domain information field is about the ACP. All pieces of it are required for ACP operation. > 4) In Section 6.8.2, para 6, line 3. "equally built" (What does > "equally" mean here? I cannot puzzle out what is intended.) I removed "equally built". I thought it would make it easier to understand how the ACP GRASP virtual interface duplicates what the ACP virtual interface does - but seemingly it doesn't for you, and i now also think the sentence is fine without these redundant words: On a physcial link you discover 3 ACP neigbhors. You build an IPsec secure channel to each of them. You form an ACP virtual interface from these three secure channels. Now you build 3 TCP connections for ACP GRASP to those three neighbors across that ACP virtual interface because for GRASP we also want to have TCP reliability and message fragmentation. Thats what i thought could be described by "equally build". > 5) In Section 6.10.1, bullet 4, this bullet appears to be talking about > three types of addresses, "ULA", "ULA-Random", and "assigned ULA", when > in fact there are only two. I suggest the following text for the first > sentence: > "Use-ULA: For loopback interfaces of ACP nodes, we use > Unique Local Addresses (ULA), specifically ULA-Random, as > specified in [RFC4193]." Done. Hope the following changelog comment i added captures this: Removed comment about assigned ULA addressing. Decision not to use it now ancient history of WG decision making process, not worth nothing anymore in the RFC. > > 6) In Section 6.10.3 and Section 6.10.3.1, the phrases "zone", "Zone > ID", "zone-ID", and "Zone-ID" are used interchangeably. This is > ambiguous. Since almost all of the discussion is about the "Zone-ID" > field, the two sections should be reviewed carefully, with the goal of > using a single phrase throughout these two sections. If "zone", Zone > ID, "zone-ID", or "Zone-ID" is used elsewhere in the document, it should > be examined. When discussing the concept of a zone, "zone" should be > used; when discussing the Zone-ID field, "Zone-ID" should be used. Ok, i tried to clean up the use of the various terms: "ACP Zone Addressing Sub-Scheme" - name, always capitalized "Zone-ID" - name, always capitalized "zone" - term, not capitalized "ACP zone address" - term, not capitalized. > -- > 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: Michael Richardson ------------------------------------------------------------------------------ On Mon, Nov 06, 2017 at 10:57:32AM -0500, Michael Richardson wrote: > > William Atwood wrote: > > For two different on-line generators, I get the following results: > > > > > http://www.xorbin.com/tools/sha256-hash-calculator > > area51.research.acp.example.com > > 89b714f3db8e41558cfb49d4d763ee7cc5ae53a3ffe8a17039679d06dc9bb0e3 > > Sometimes the difference is whether or not a CR and/or LF is included in the > hash. I see that your result is without the line feed. > > dooku-[~](2.3.0) mcr 14553 %echo area51.research.acp.example.com | sha256sum > 60b1547f399cb8354010e0bd5853f0bcd393590e44efa2cb47c233615e9ce766 - > dooku-[~](2.3.0) mcr 14554 %echo -n area51.research.acp.example.com | sha256sum > 89b714f3db8e41558cfb49d4d763ee7cc5ae53a3ffe8a17039679d06dc9bb0e3 - ^^^^^^^^^^ Thanks. Fixed in all occurances of the draft. Somehow we missed to update the example when we moved from MD5 in -05 to SHA256. Wrt. why SHA256 and is it an update to the spec: There was also the question whether using SHA256 would indicate we're doing something different from RFC4193, but that text in 4193 was just an example, even hashing different data. > But, the only device that needs to create the ULA prefix is the registrar > during it's bootstrap, and once created it is to be stored. I would expect > that if there was an administrator interface that it would ask for some > domain details, and then pre-populate a "ACP prefix" field with the result, > but let the admin type in their own. "let administrator type their own" == allow ULA prefix to be inconsistant with the domain name ?! Sure, but that would be non-compliant with the ACP definition, but should perfectly well work. Aka: If someone would like to run an ACP without ULA address, even that should work as long as you hack up the registrar to allow non-ULA prefixes. The ACP text was explicitly written to make such slightly modified versions of ACP easy to implement (just config interface on registrar needs to support it as you said). ------------------------------------------------------------------------------ From: Yonghang Zhang ------------------------------------------------------------------------------ From: Toerless Eckert To: Cc: "anima@ietf.org" , Zengweizhi , Yangang Bcc: Subject: Re: [Anima] ????: A question about draft-ietf-anima-autonomic-control-plane-12 Reply-To: In-Reply-To: Thank you so much, Yongkang I have fixed the length of the node-number in ACP draft -13. Toerless On Mon, Nov 20, 2017 at 07:11:43AM +0000, zhangyongkang 00210452 wrote: > Sorry, there is a mistake: > (2) When the first bit of Node-Number is 0, 33(Node-Number) + 8(V) + 46(Registrar-ID) = 41 + 46 = 87 > > > ??????: Anima [mailto:anima-bounces@ietf.org] ???? zhangyongkang 00210452 > ????????: 2017??11??20?? 15:09 > ??????: michael.h.behringer@gmail.com; anima@ietf.org > ????: Zengweizhi; Yangang > ????: [Anima] A question about draft-ietf-anima-autonomic-control-plane-12 > > Hi Behringer, > When I read the section 6.10.5 ACP Vlong Addressing Sub-Scheme??I was confused about the following content: > 50 78 > +---------------------++-----------------------------+----------+ > | (base scheme) || Node-ID | > | || Registrar-ID | Node-Number| V | > +---------------------++--------------+--------------+----------+ > 46 33/17 8/16 > > Figure 6: ACP Vlong Addressing Sub-Scheme > ?? > o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is > reduced to 46 bits. This still allows to use the MAC address of a > registrar by removing the V and U bits from the 48 bits of a MAC > address (those two bits are never unique, so they cannot be used > to distinguish MAC addresses). > o If the first bit of the "Node-Number" is "1", then the Node-Number > is 17 bit long and the V field is 16 bit long. Otherwise the > Node-Number is 33 bit long and the V field is 8 bit long. "0" bit > Node-Numbers are intended to be used for "general purpose" ACP > nodes that would potentially have a limited number (< 256) of > clients (ASA/Autonomic Functions or legacy services) nof the ACP > that require separate V(irtual) addresses. "1" bit Node-Numbers > are intended for ACP nodes that are ACP edge nodes (see > > > Section 8.1.1) or that have a large number of clients requiring > separate V(irtual) addresses. For example large SDN controllers > with container modular software architecture (see Section 8.1.2). > > According the above content, Node-ID(78bits) is composed of Registrar-ID, Node-Number and V fields. But: > (1) When the first bit of Node-Number is 1, 17(Node-Number) + 16(V) + 46(Registrar-ID) = 33 + 46 = 79 > (2) When the first bit of Node-Number is 0, 33(Node-Number) + 8(V) + 46(Registrar-ID) = 41 + 46 = 97 > > So the result confused me! > Please check the above section again when you pleasure. > From nobody Sun Dec 17 11:25:29 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BF1126C23 for ; Sun, 17 Dec 2017 11:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmVDtKFUSFc4 for ; Sun, 17 Dec 2017 11:25:26 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1BE126C0F for ; Sun, 17 Dec 2017 11:25:26 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id j28so8784110pfk.8 for ; Sun, 17 Dec 2017 11:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aDt3SsnSuSU0EXwuGLbAs0zeHWfCrHX7tqRnj6rrwOs=; b=iqfBR7/m04JQ+QhQHM4tz+XH195S7OBqiwVnmKKBjJDl+BqfvxLRObPxqmhxckXKdV 5mK/o7eGyj8OT9MyVfff0ugCH5q66oBBktQev3NkiD12cQfh89F2g1zkbUOTZjtSeufY pA9OQ5FU2mAOyoGEQttA4/kDp1/RYEW0czxkOoLdabyl3C6GdnoL7ClVjCEsNsh+1ezn tnVYVhLY8IXR0vTbJxLQyn/GNLRa1KLCYPGjx451yCUlGNiuG3xY5GHBcPiWQNIx77Kz xHrfHPO3OTm6w6aHJ39ZsZzS5QxafhLMxbinJScqXGp+hTflUaATt7YpnjsOVWz6XXEv 1lfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=aDt3SsnSuSU0EXwuGLbAs0zeHWfCrHX7tqRnj6rrwOs=; b=nth8gbek4cEKwV8o1tkFkrc1IO0Tet7Twr4oE6k1my5KmHa4Al7fE24D2O6yrbCsL3 dp/iCoiXD2GC0mfW8x9L3gfnuSInm/FbEi0a59N9oiX/QofTavpGMZ9FINl0v+WUMDx3 Nuzr70QJXnX3hivCjmSh/kgp2ZEQWvO8TUjAwKVrC7DcLADgbvpdaxIX+O+/DMrI0sT5 wsLA7+0m43kokcDBTp0hXDnnuGrZ4s4lRVLDtI5L0EXfgWnzQ5YTfhCEa3r0WlJK72J4 TEoSMbmoyciE7QLZHto8at3u+t8qGH2NGMV8JuSb+qUykJZz0Th5XzjKyDqodgw+zayW wx3w== X-Gm-Message-State: AKGB3mLcVY1Et6vkb0Hh9jCZ/gOk2soWjA+HSZf/WBHhsY7xQ6uCufXs PikY3NKH/2auvNxtVqt88/bLdg== X-Google-Smtp-Source: ACJfBotd4iO9CZlh58FAuxNaELY6mUXtVgGg5eeny8MutZ8Ut5BSDHD4pw8ITMp/6WJF+Hj/uo0KGA== X-Received: by 10.101.69.2 with SMTP id n2mr17850960pgq.79.1513538725269; Sun, 17 Dec 2017 11:25:25 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u19sm5566271pgv.6.2017.12.17.11.25.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Dec 2017 11:25:24 -0800 (PST) To: tte+ietf@cs.fau.de, anima@ietf.org References: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 18 Dec 2017 08:25:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review reply: Re: WGLC on draft-ietf-anima-autonomic-control-plane-12 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, 17 Dec 2017 19:25:28 -0000 Hi Toerless, I think all my comments have been well handled, so just a few comments below: > xml2rfc turns this reference into: > > ACP address: An IPv6 address assigned to the ACP node. It is stored > in the domain information field of the ACP domain certificate > (Paragraph 21). > ^^^^^^^^^^^^^^^ Yuck. Maybe you can refer to Section 6.1.1 instead, that should work. > In the figure 1 example in rfc4007, there is a link-local zone with > two interfaces. Yes. Let's see what people have to say over on 6man. (The loop prevention in GRASP will actually work for this case, as far as I can tell; it's just a special case of a physical topology loop. I can probably simulate it by plugging my Ethernet interface to the back of my wireless hub.) > >> A related but more general question: >> >> If there are multiple GRASP instances in a node (ignoring the DULL case), >> does each instance require its own ACP unicast address and its own ACP >> security associations? (I hope the answer is "No".) > > If you had multiple ACPs, i am sure each ACP would have its separate loopback > address. These are different addressing domains anyhow, so really no way > to avoid this. Even if it would be the same addresses (like having multiple > times the same rfc1918 address in different VRFs - counts as different addresses). Agreed. The case that was bothering me was *one* ACP instance and multiple GRASP instances. Thanks for all the work on this. Brian From nobody Sun Dec 17 16:53:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492221201FA for ; Sun, 17 Dec 2017 16:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRVpFR9bF4NI for ; Sun, 17 Dec 2017 16:53:35 -0800 (PST) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626891200C5 for ; Sun, 17 Dec 2017 16:53:35 -0800 (PST) Received: by mail-pl0-x235.google.com with SMTP id bd8so3835729plb.9 for ; Sun, 17 Dec 2017 16:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/5NVyPoR6zPSdnoCV1oG8zznryT2ZSUG1MZy2338tX8=; b=M4fer7NZjvbty5Hlt4I51dg9aOld2/RssiZLKMAE21oCPsqqi6gec0NVyetin1x4Ib hEX+tNWWnwa4O+eRa2A4t0sRfiGvKefPx2uAJJbJ2GM2yrqSiU/rlIrapmoAcGnzWX3x VQfOC+L752nQSnNFcttLvj/fEvyLNKyzFDpjSna22/QhxJf5hG4Bl1Yc0yFx0OOTIV7X WPnzRd/uLnDXuZp7ZropfD7OGh5mHeYhA0ah8j8Bi76R8afn6LJxn02lBp+C0/qTaV0r KDcBpIWC+RmQjtL4EXozcqeC5t30oRT1erVliCFDd/es80dAr/VWaebfuVK1FHuxT99A PQIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/5NVyPoR6zPSdnoCV1oG8zznryT2ZSUG1MZy2338tX8=; b=dD0uvysnDJOuGFH1Z0jX1yrmt5plNNJbQmlOeAXG14ixOeFOVa96QK81jtocKKQEvx YUQfRILvjmhqvFC3RCretiEnOmtaP646ETb0BkEbu05GqTymw06wb3Z71/jxvEXGrFoz SyF8D2PrE9OxGba5TTungvfGY1nL4JUhC1wIfsXa6wBbXOGm4Oin6QkCUb870+d8WkPV XVqQ9TohYunzV29mln72wuLl62Xmw0TxvbTqQPUe0NmXhltPaCYLvrWBoXZukrL9RIo1 HMWz26lXB+vntn65fEkIwYCc4geoU5V4U7snri6s7cf+dc53JcvKwISoJpE04YtTawCy Fs/w== X-Gm-Message-State: AKGB3mLIPDzLUNd47vvTZ17ptPQ4ODvPAp9bdsvczk/jwCvZqP0bKsms zfvjRdWDT8R0A2rQ+UOaEvoYbw== X-Google-Smtp-Source: ACJfBosFx+deGIy2VuXuXdZaOlszgX9aCq+OYwkJx6PFBGrH70rgyRUL/n7IE1IFmgI1QH6Sb+fWvQ== X-Received: by 10.84.176.65 with SMTP id u59mr20481150plb.419.1513558414419; Sun, 17 Dec 2017 16:53:34 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q74sm21663572pfd.134.2017.12.17.16.53.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Dec 2017 16:53:33 -0800 (PST) To: tte+ietf@cs.fau.de, anima@ietf.org References: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 18 Dec 2017 13:53:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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] Link with 2 interfaces [Review reply: Re: WGLC on draft-ietf-anima-autonomic-control-plane-12] 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, 18 Dec 2017 00:53:37 -0000 On 18/12/2017 08:25, Brian E Carpenter wrote: ... >> In the figure 1 example in rfc4007, there is a link-local zone with >> two interfaces. > > Yes. Let's see what people have to say over on 6man. (The loop prevention > in GRASP will actually work for this case, as far as I can tell; it's > just a special case of a physical topology loop. I can probably simulate it > by plugging my Ethernet interface to the back of my wireless hub.) I tested it. Indeed, the Windows stack sees this as two completely separate interfaces, with their own IPv6 addresses. There's nothing else it could do. (I didn't test it on Linux.) When I run GRASP, everything works as normal except that each Discovery and Flood message generates a diagnostic: "Dropping a looping relayed multicast." That's specified for Discovery at the top of this page: https://tools.ietf.org/html/draft-ietf-anima-grasp-15#page-19 ("To prevent loops,...") and for Flood in the middle of: https://tools.ietf.org/html/draft-ietf-anima-grasp-15#page-22 Brian From nobody Sun Dec 17 18:27:33 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E59127275; Sun, 17 Dec 2017 18:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EpICRDzykmrB; Sun, 17 Dec 2017 18:27:30 -0800 (PST) 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 5D5701205F0; Sun, 17 Dec 2017 18:27:30 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0A51C70E5FC73; Mon, 18 Dec 2017 02:27:26 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 18 Dec 2017 02:27:27 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 10:27:21 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: =?gb2312?B?QU5JTUEgbWludXRlcyAtIElFVEYgMTAwo6wgU2luZ2Fwb3Jl?= Thread-Index: AdN3p5JdrZERlgJpRNqFBvGkcXJ4cQ== Date: Mon, 18 Dec 2017 02:27:21 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92817E2D9C@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92817E2D9CNKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] =?gb2312?b?QU5JTUEgbWludXRlcyAtIElFVEYgMTAwo6wgU2luZ2Fw?= =?gb2312?b?b3Jl?= 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, 18 Dec 2017 02:27:32 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92817E2D9CNKGEML515MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KDQoNClNvcnJ5IGZvciB0YWtpbmcgc28gbG9uZy4gSG93ZXZlciwgaXQgaXMg aGVyZSBmaW5hbGx5LiBUaGUgbWludXRlcyBmb3IgdGhlIEFOSU1BIHNlc3Npb25zIGF0IElFVEYg MTAwIGluIFNpbmdhcG9yZSBjYW4gYmUgZm91bmQgYXQ6DQoNCg0KDQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVyaWFscy9taW51dGVzLTEwMC1hbmltYS8NCg0K DQoNCk1hbnkgdGhhbmtzIHRvIEJpbmcgTGl1IGZvciB0YWtpbmcgbWludXRlcy4NCg0KDQoNClBs ZWFzZSBzZW5kIGFueSBjb3JyZWN0aW9ucyB0byB0aGUgY2hhaXJzLg0KDQoNCg0KQmVzdCByZWdh cmRzLA0KDQoNCg0KU2hlbmcgKyBUb2VybGVzcw0KDQoNCg0KDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B92817E2D9CNKGEML515MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable 
Hi, all,
 
Sorry for takin=
g so long. However, it is here finally. The minutes for the ANIMA sessions =
at IETF 100 in Singapore can be found at:
 
https://datatra=
cker.ietf.org/meeting/100/materials/minutes-100-anima/

 


Many thanks to =
Bing Liu for taking minutes.


 


Please send any=
 corrections to the chairs.


 


Best regards,


 


Sheng + Toe=
rless


 


 


 
--_000_5D36713D8A4E7348A7E10DF7437A4B92817E2D9CNKGEML515MBSchi_-- From nobody Sun Dec 17 21:09:45 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D80126DEE for ; Sun, 17 Dec 2017 21:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B-Ua8jgHniU for ; Sun, 17 Dec 2017 21:09:41 -0800 (PST) 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 A8251124D6C for ; Sun, 17 Dec 2017 21:09:41 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4970158C4C4; Mon, 18 Dec 2017 06:09:37 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 31759B0D4BE; Mon, 18 Dec 2017 06:09:37 +0100 (CET) Date: Mon, 18 Dec 2017 06:09:37 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: tte+ietf@cs.fau.de, anima@ietf.org Message-ID: <20171218050937.GA28741@faui40p.informatik.uni-erlangen.de> References: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Review reply: Re: WGLC on draft-ietf-anima-autonomic-control-plane-12 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, 18 Dec 2017 05:09:44 -0000 Inline On Mon, Dec 18, 2017 at 08:25:19AM +1300, Brian E Carpenter wrote: > Hi Toerless, > > I think all my comments have been well handled, so just a few comments > below: > > > xml2rfc turns this reference into: > > > > ACP address: An IPv6 address assigned to the ACP node. It is stored > > in the domain information field of the ACP domain certificate > > (Paragraph 21). > > ^^^^^^^^^^^^^^^ > > Yuck. Maybe you can refer to Section 6.1.1 instead, that should work. Yes, but that would be last resort, i am asking rfc-editor for format recommendations now. But given how this is really an RFC formatting issue that we can solve all the way into RFC editor queue/author review, i sugest we do not let this hold up progressing the doc now. > > In the figure 1 example in rfc4007, there is a link-local zone with > > two interfaces. > > Yes. Let's see what people have to say over on 6man. (The loop prevention > in GRASP will actually work for this case, as far as I can tell; it's > just a special case of a physical topology loop. I can probably simulate it > by plugging my Ethernet interface to the back of my wireless hub.) Well, you played around with it, so you have an idea why i am avoiding the topic and just wrote "interface" into the adjacency table requirements ;-) Even if we figure out some more useful details, i would like to punt those details to a yang model for ANI. That will be a good amount of work reading up on common yang practices and pre-existing object to use anyhow *sigh* > >> A related but more general question: > >> > >> If there are multiple GRASP instances in a node (ignoring the DULL case), > >> does each instance require its own ACP unicast address and its own ACP > >> security associations? (I hope the answer is "No".) > > > > If you had multiple ACPs, i am sure each ACP would have its separate loopback > > address. These are different addressing domains anyhow, so really no way > > to avoid this. Even if it would be the same addresses (like having multiple > > times the same rfc1918 address in different VRFs - counts as different addresses). > > Agreed. The case that was bothering me was *one* ACP instance and multiple > GRASP instances. No need. If there was anything in the text that would have raised that question, let me know because i am not sure why that question would come up. > Thanks for all the work on this. Thanks for all the review! Cheers Toerless > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Dec 18 07:33:36 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3B1289B0 for ; Mon, 18 Dec 2017 07:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lg43JRvTV9hx for ; Mon, 18 Dec 2017 07:33:32 -0800 (PST) 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 AE9D012708C for ; Mon, 18 Dec 2017 07:33:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 847B72008D; Mon, 18 Dec 2017 10:37:06 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5A6898167E; Mon, 18 Dec 2017 10:33:30 -0500 (EST) From: Michael Richardson To: tte+ietf@cs.fau.de cc: anima@ietf.org In-Reply-To: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> References: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Review reply: Re: WGLC on draft-ietf-anima-autonomic-control-plane-12 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, 18 Dec 2017 15:33:34 -0000 --=-=-= Content-Type: text/plain tte+ietf@cs.fau.de wrote: > Hmm... The first instance of referring to domain certificate is > actually in the "ACP address" definition. I have now tried to put a > forward reference to the definition of domain certificate in section 2 > into it, but its kinda quirky: > An IPv6 address assigned to the ACP node. It is stored in the domain information field of the ACP domain certificate. > > A provisioned certificate (LDevID) > carrying the domain information field which is used by the ACP to learn its address > in the ACP and to derive and cryptographically assert its membership in the ACP domain. > > xml2rfc turns this reference into: > ACP address: An IPv6 address assigned to the ACP node. It is stored > in the domain information field of the ACP domain certificate > (Paragraph 21). > ^^^^^^^^^^^^^^^ If you put the anchor in a paragraph, then it's gonna have to reference the paragraph. I didn't know it would count them like that. Put it in a numbered section. I think if it's worth pointing at like that, then it should have a section explaining what it is rather than just terminology. A provisioned certificate (LDevID) as exampled in section . And then create that new section. >> loopback interface: The conventional name for a neutral virtual >> IP interface to which addresses may be assigned, but which >> transmits no external traffic. I can live with that. >> But, the only device that needs to create the ULA prefix is the registrar >> during it's bootstrap, and once created it is to be stored. I would expect >> that if there was an administrator interface that it would ask for some >> domain details, and then pre-populate a "ACP prefix" field with the result, >> but let the admin type in their own. > "let administrator type their own" == allow ULA prefix to be inconsistant > with the domain name ?! Sure, but that would be non-compliant with the ACP > definition, but should perfectly well work. Aka: If someone would like to We have suggested how to come up with the ULA from the domain name, but that's not intended to be normative. There are many reasons to configure a different ULA, but the major one is merger/acquisition. We may want to write a draft on renumbering the ACP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlo338kACgkQgItw+93Q 3WU2JggAv3eKD1mZQpgmZWTWihcz5m651396duxuvkI3d8GBgptry6IX2GoJlCVb RVGEJrM/ZCjlgXa72Yya/vV82wZJ3KUQVatFkGfivx0/bHk8tjoC4vxQI4E6Yf4f ihq7e+uufsSVTkyHKedAgt+E+izcc+MF7VMx8lczHtAc8jp0vkd9L2Emlyy5jiMR LXom1Pj2sfWDB/BXKHCZe35J5blwpg77FUmYroPYCn5UjCEClrj6S15KY+tEXrW1 HV9dSG6Tct8Iwjqnw/3LI1VL7LdnpKVWDvk5COjtNXk1/4t2/pxkNOr/b/Zm3koy 9ApKUIURJwCl2m7BUFAiEwMDW55jnw== =4ldo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 18 10:34:01 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3812D82C for ; Mon, 18 Dec 2017 10:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 pf3fW9EJbtOy for ; Mon, 18 Dec 2017 10:33:58 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8E51277BB for ; Mon, 18 Dec 2017 10:33:58 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id m26so10014168pfj.11 for ; Mon, 18 Dec 2017 10:33:58 -0800 (PST) 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=lKdhayr3OcZzndhXegY9YjWdJugCk19KACKgy8aASew=; b=hi+fvISrxISMN9Tuy6pf/JWXUZqUGVAO3OlEzOJPVrle56pSVoQi+KDVnLHgVcPzlc 56CzE3pbkQRXT20E9kkmLVPP+3w/R1ZBMgCT8yRsq5i1R1hGenP8lAYkVPNXVF7xX/9/ Ab9F1CHQch8NSD4OeUlHSyW+58EW9xAgxplt+8BqIz0W/ASxfO9LfjbjIK3yzoSxkZgc nb3YActRj3YpdqhdhL56OpePt8fUf1nswT5LeKhj60tv90XUdl8KczKnSKj6ClIfgXSr iIvmk/Ae+X9ZEj7zyxSTGa9UJ4IMLx05zFq9nTaGrERlTdCUaSQuge/n1sht+yz3fhjs xhug== 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=lKdhayr3OcZzndhXegY9YjWdJugCk19KACKgy8aASew=; b=pQDD3hBEL+Dngms8TYVYNt45ZBM9gZGWqPJU6/h9RsaVEd6exbZshHbY5axbxlv4h+ lw4tButClqKzAyqXN/E+GafHFT7q/xBhhVE2fOJh3G5XzkJXA7GZQ/I1o4MuS8ZNe/fG ASxmZ+rB4ygwAEi8n9/sqhzGiFfkulOVvE325nqam5fxQz9Tp1pacK2be9kF6kF8hU+U 4indxZvuQSGJjXZXRe0x4dxFg/btNlKpATWp+wo5ZLKTALrlmrNXF0wkh2lR55w+4ibq aLJggQEfvnehbwu2LeI/uyC/zwjR/xYPyAi1S9GDQB09rHXD3tzz2kHCw75KmTQmylap bXpQ== X-Gm-Message-State: AKGB3mJZ49b6xo6DPgsSJiQU9HdZ2AG7K6Weg1TVtOAl652FaUVUUd+V pBEt1jgreSWus1JLItUg7qwF9Q== X-Google-Smtp-Source: ACJfBovcdG6E1YJVpOFrYvhG9b2KOJNZLKuRap61HVIG4ywgwAAVAzS9f825bqNY3JaRlR4eZlPBUA== X-Received: by 10.98.213.71 with SMTP id d68mr559042pfg.171.1513622037436; Mon, 18 Dec 2017 10:33:57 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i3sm23144688pgc.88.2017.12.18.10.33.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 10:33:56 -0800 (PST) To: Toerless Eckert Cc: tte+ietf@cs.fau.de, anima@ietf.org References: <20171217121423.GR19390@faui40p.informatik.uni-erlangen.de> <20171218050937.GA28741@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8af6f59a-af09-1530-e0f4-8e8ba7f600a1@gmail.com> Date: Tue, 19 Dec 2017 07:33:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171218050937.GA28741@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review reply: Re: WGLC on draft-ietf-anima-autonomic-control-plane-12 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, 18 Dec 2017 18:33:59 -0000 On 18/12/2017 18:09, Toerless Eckert wrote: ...>>>> A related but more general question: >>>> >>>> If there are multiple GRASP instances in a node (ignoring the DULL case), >>>> does each instance require its own ACP unicast address and its own ACP >>>> security associations? (I hope the answer is "No".) >>> >>> If you had multiple ACPs, i am sure each ACP would have its separate loopback >>> address. These are different addressing domains anyhow, so really no way >>> to avoid this. Even if it would be the same addresses (like having multiple >>> times the same rfc1918 address in different VRFs - counts as different addresses). >> >> Agreed. The case that was bothering me was *one* ACP instance and multiple >> GRASP instances. > > No need. If there was anything in the text that would have raised that question, > let me know because i am not sure why that question would come up. No, the text is fine. One GRASP instance per ACP VRF is the normal model. If that needs to be written, it probably belongs in the reference model. FYI: in my GRASP prototype, I did have to include a hack for this situation, so that several instances can run in the same node for testing. Basically it's a hack to avoiding an instance responding to its own discovery messages. That's why the question came up in my mind. Brian From nobody Mon Dec 18 11:01:40 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51878126D74 for ; Mon, 18 Dec 2017 11:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 XjTyg0O9wD-t for ; Mon, 18 Dec 2017 11:01:37 -0800 (PST) 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 0087B120454 for ; Mon, 18 Dec 2017 11:01:36 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id j124so10065520pfc.2 for ; Mon, 18 Dec 2017 11:01:36 -0800 (PST) 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=tDooEP1Smf5PQZxhcl8QZjDktZ4nj3QGPvwbQ8V3l1A=; b=Jg5ytS3ELNFlpo4tYUQ02rUCLsP3u0su2uRwzbrqegDMZizVzZugJU88/ZIvUOBigD 86kX4vq60oOca4y4USZdQqz2zgCDjHYMWYBpTNWIe59suhNyZ4ZFwu/B8qKEsc/p7Jvs Of40seB0B4pvPhuZOgAhff9FeRhmECEDrMTLTCgk209MajxLKCI6LZGcQQrRcWLsMkdn mgrdTF0dnvBORDRwic/Q4zNDLB6QP9YqcgptuuGo2T/ogSt0wEdS5bxkOxCj+PE7OE+r IyFDje3gP3+CZ5QkH+9x5u+oI4tgxtek8mm6IcX/g/ptb/oMoNxgfwxfOJcdLjQ/lVUA fZpg== 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=tDooEP1Smf5PQZxhcl8QZjDktZ4nj3QGPvwbQ8V3l1A=; b=lt70IkRvqfpt8StSKgDpWC+MoKGrfr2lWJwAlSFXPyQU1jqWznDdiVtF1TzdM6akza 7mZjYy96zzFU7rUgGXaxzQh5pk+g7oGntbl5LctUJbxKjI87zeviQCxrIe33KtfGzdws D3Nj9Si4gbFzG6aQKkZAAg9/+VM0DTaUQx2c64GEjfjSSz/1gysPhT5a5g4hnzZ2ajQv cpHrjjzTqhDyP2XQtNzuh4EbMsYXFCu1Dsg+8bDhmnSeI2uWnUZD/SVxI7Cte9Ltn1B7 q+nldNJlwoDsGiiaVuC4DiXOIxvmSQumJhsRB8iOyhQa8YE45CNMHUIaX6ZdFzGC0OP8 sWnQ== X-Gm-Message-State: AKGB3mK81oRmbMO65R2Hrjd93TVGHUgiNoMrjG1mbaeJEmBjpZDU2IAt rP6T7QtGbsTkH4Yhya3jQi1rfw== X-Google-Smtp-Source: ACJfBosMKCAnPhH8ZTZvuYs/UXE2p6AXktfwT0VU1WGQ/vhNT77wAGmEvu2CwiyXsGj8BAnBthLc+A== X-Received: by 10.101.74.8 with SMTP id s8mr562138pgq.259.1513623696335; Mon, 18 Dec 2017 11:01:36 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y7sm23992015pfe.8.2017.12.18.11.01.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 11:01:35 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <5aa09826-2f1a-d837-e120-c23141e579d5@gmail.com> Date: Tue, 19 Dec 2017 08:01:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Intended status of draft-ietf-anima-bootstrapping-keyinfra 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, 18 Dec 2017 19:01:38 -0000 I just noticed that draft-ietf-anima-bootstrapping-keyinfra has Intended status: Informational. Surely it should be Standards Track? Regards Brian From nobody Mon Dec 18 11:24:01 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAFE126DED for ; Mon, 18 Dec 2017 11:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 R1qTL8G7qYTK for ; Mon, 18 Dec 2017 11:23:58 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FA7126BF6 for ; Mon, 18 Dec 2017 11:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1917; q=dns/txt; s=iport; t=1513625038; x=1514834638; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=7YLRKaungo1+/hqnheboRJCMesI+kvyJkTIbNI2dT2g=; b=mfdQg3MSvCb2tzf4FGzP4UlPs+afPQvNwVfoI1W5UzbQOftT/9aJkXNj veCXRhJLjewYJ3qGV22plCN8pOMOYkKpLCfAcy5O1AJKJeX/3cZyY5rP4 CSQgbgWeMwlkbZ7rXcJ6sObdYQ0oDxRW+TdnhQ71NxmZ0UvIdy26OH4JT o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAgB8FTha/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCeEBosVj24mmTYHAxgLhRgChUoUAQEBAQEBAQEBayiFJAE?= =?us-ascii?q?BBAEBIUsbCxgqAgInMAYBDAYCAQGKJhCqToInimgBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERCgWDboV2DIJ3gy4BhQOCYwWZXYlfhE+CLY4wgX0BiheHXpZ4gTs2IoFPMho?= =?us-ascii?q?IGxU8gimEV0A3ihcBAQE?= X-IronPort-AV: E=Sophos;i="5.45,423,1508803200"; d="asc'?scan'208";a="996002" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2017 19:23:46 +0000 Received: from [10.61.162.193] ([10.61.162.193]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBIJNj6P028043; Mon, 18 Dec 2017 19:23:45 GMT To: Brian E Carpenter , Anima WG References: <5aa09826-2f1a-d837-e120-c23141e579d5@gmail.com> From: Eliot Lear Message-ID: <4d5f0683-fc3e-6936-39da-ac0a23f98b86@cisco.com> Date: Mon, 18 Dec 2017 20:23:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5aa09826-2f1a-d837-e120-c23141e579d5@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XTTes3KDPjhkjkFD2oQlDJHLfO07DqFQB" Archived-At: Subject: Re: [Anima] Intended status of draft-ietf-anima-bootstrapping-keyinfra 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, 18 Dec 2017 19:24:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XTTes3KDPjhkjkFD2oQlDJHLfO07DqFQB Content-Type: multipart/mixed; boundary="6GIJuHFlwTCh73er4uNcE1iwDE3eEJqAB"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , Anima WG Message-ID: <4d5f0683-fc3e-6936-39da-ac0a23f98b86@cisco.com> Subject: Re: [Anima] Intended status of draft-ietf-anima-bootstrapping-keyinfra References: <5aa09826-2f1a-d837-e120-c23141e579d5@gmail.com> In-Reply-To: <5aa09826-2f1a-d837-e120-c23141e579d5@gmail.com> --6GIJuHFlwTCh73er4uNcE1iwDE3eEJqAB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Absolutely! On 18.12.17 20:01, Brian E Carpenter wrote: > I just noticed that draft-ietf-anima-bootstrapping-keyinfra > has Intended status: Informational. > > Surely it should be Standards Track? > =20 > Regards > Brian > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --6GIJuHFlwTCh73er4uNcE1iwDE3eEJqAB-- --XTTes3KDPjhkjkFD2oQlDJHLfO07DqFQB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlo4FcEACgkQh7ZrRtnS ejP+ugf+NWDnuYdTTLUMJ2MUWxUsT4OOwaqgT/ZBbvcPhlwzfbItuD3LFCU8wT/+ gVnr0sbQMpqttf1wbiWMJbNFsK7v6vI29h5tEhFk+5QfYfq01nkUbn3qdjsAXg0+ u7lSihlSCPCdw8tVvPDendgifkJzk5s71sqwbC+ZpukYcP693M6u/0gLC9MAUP62 HVaXKXUIamkknpsiZrXORkDil0YKZiiNl+0wabzo1rc2/xv+96npgKFsvfx4QbaN 3AX+p9Iow42+IzexLqxk/yod2cXr4aeG95xaP9jbbSwD9LOPpTZiciPHCwze7fyo pxAxD14JDrNFiC3ZCAUUvo2c2QOFlw== =JNBf -----END PGP SIGNATURE----- --XTTes3KDPjhkjkFD2oQlDJHLfO07DqFQB-- From nobody Mon Dec 18 17:34:48 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AE1124F57; Mon, 18 Dec 2017 17:34:41 -0800 (PST) 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.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151364728187.7447.1789217750810347132@ietfa.amsl.com> Date: Mon, 18 Dec 2017 17:34:41 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 01:34:42 -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 : Autonomic IPv6 Edge Prefix Management in Large-scale Networks Authors : Sheng Jiang Zongpeng Du Brian Carpenter Qiong Sun Filename : draft-ietf-anima-prefix-management-07.txt Pages : 22 Date : 2017-12-18 Abstract: This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-prefix-management-07 https://datatracker.ietf.org/doc/html/draft-ietf-anima-prefix-management-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 18 17:41:19 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE41B12711D; Mon, 18 Dec 2017 17:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Xy88ax8we2tt; Mon, 18 Dec 2017 17:41:16 -0800 (PST) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (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 02FFE1201FA; Mon, 18 Dec 2017 17:41:16 -0800 (PST) Received: by mail-pl0-x22f.google.com with SMTP id bi12so6000578plb.6; Mon, 18 Dec 2017 17:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Dk+SHKqLQWmtBfQVGYpFB8NEIswsqMML1UsusnB7Rrs=; b=ES/Us8N8SU0n0vKRGp31dhPVaJw+EjPNFr2dDJQh0KWnLVNMQKPKVTVvD3fYFDbqOE D3vild8dGCmq8lXmoZ3h7tb5tpF/es/PoRTx9UN/dcLlnrJT7oanJfQ3zhbzLNzNUKJ2 /fNYiHBWD4rT0Y8eTN07BIbcIXhKKXWGjaS73Y+Oc7Z5neh3UfKnQsCxeoyNJz9+jOfy +Kp/UDlGARrQX34kvJLoVtj2iCWGRQn6aTAW4JNh25BLq41sLk1fkCju3gRJn5UBdshA l2b6xq3I62/oHDB41jyWpcHlXT8ftaFZijAJbJtandonv7EU+COI+dZZpZzsha+YgaH3 +ONQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Dk+SHKqLQWmtBfQVGYpFB8NEIswsqMML1UsusnB7Rrs=; b=jruZEK/88VdJ3DxI0l1QpK87wDVxOetitvZtRTDYjcgskTqyIMwgs2y8p2FFJZNmua BwUXhHXeog8aXHw1ynlYd2Xicqj4Of5bGqT9Mh9ZDgFfGPX8zTJclTyU02szjwrw8RbL CfEpO9ETqO+9xS8GRR54zE3b69ebeeHp2jq105PBnhRESwj0mOLSHyGoDb4Ju7ORI5cj 96OQoJvWGMhWldin3EoVCdGD2cHr9oIoBC1XSV559pWlTaD78z3u0EPj6cwXSeGtv3cJ UtZiQwdN2McnBXy4dB5ijilqszyvojG3aUw98r40cQJR8jqJPLkXQas7szo1GVSiMxaF fZ0w== X-Gm-Message-State: AKGB3mL/PxoeojJjQwRWPiaTuScEeL7rC1Wg8Ubq1OUCH/9tBVnb4hLo cmowLf+OBpRy+XcB8M2HtyT6Wg== X-Google-Smtp-Source: ACJfBov892bXdE3eOrRzJxkSLQ+bsD6Bafnra91mU9it5DPR3DFPnQqsbC3hf3Jc8ihvHWr/x81StQ== X-Received: by 10.84.133.71 with SMTP id 65mr1511839plf.309.1513647675293; Mon, 18 Dec 2017 17:41:15 -0800 (PST) Received: from [130.216.38.162] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.162]) by smtp.gmail.com with ESMTPSA id v88sm30214276pfk.31.2017.12.18.17.41.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 17:41:14 -0800 (PST) To: draft-ietf-anima-prefix-management.all@ietf.org, anima@ietf.org References: <151364728187.7447.1789217750810347132@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 19 Dec 2017 14:41:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151364728187.7447.1789217750810347132@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 01:41:18 -0000 This version fixes several IESG comments: - short explanation why this is Informational - updated RFC2119 boilerplate - noted risk of fragmentation of routing table - improved wording about hierarchical network topology Regards Brian Carpenter On 19/12/2017 14:34, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > > Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks > Authors : Sheng Jiang > Zongpeng Du > Brian Carpenter > Qiong Sun > Filename : draft-ietf-anima-prefix-management-07.txt > Pages : 22 > Date : 2017-12-18 > > Abstract: > This document defines two autonomic technical objectives for IPv6 > prefix management at the edge of large-scale ISP networks, with an > extension to support IPv4 prefixes. An important purpose of the > document is to use it for validation of the design of various > components of the autonomic networking infrastructure. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-prefix-management-07 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-prefix-management-07 > > A diff from the previous version is available at: > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Mon Dec 18 19:34:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D94127201; Mon, 18 Dec 2017 19:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 BPYmk-LgiNi8; Mon, 18 Dec 2017 19:34:41 -0800 (PST) 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 EBB5512DA16; Mon, 18 Dec 2017 19:34:39 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A419C82F04FCF; Tue, 19 Dec 2017 03:34:36 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Dec 2017 03:34:37 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 11:34:32 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Result//RE: Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 Thread-Index: AdN4eYEnN4W2HB/KTlCLsfN3LY4qSA== Date: Tue, 19 Dec 2017 03:34:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92817E399D@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92817E399DNKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Result//RE: Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 03:34:45 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92817E399DNKGEML515MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWZ0ZXIgd2UgaGFkIHJvdWdoIGNvbnNlbnN1cyBpbiB0aGUgbWVldGluZyByb29tIChJRVRGMTAw LCBTaW5nYXBvcmUpIGFuZCB0aGUgdHdvLXdlZWsgYWRvcHRpb24gY2FsbCBvbiB0aGUgV0cgbWFp bGluZyBsaXN0LCB3ZSByZWNlaXZlZCBtYW55IHN1cHBvcnRzIGluIGZhdm9yIG9mIGFkb3B0aW9u IGFuZCBkbyBOT1QgcmVjZWl2ZSBhbnkgb2JqZWN0aW9ucy4gVGhlIGNoYWlycyBjb25jbHVkZSB0 aGVyZSBpcyBhIGNvbnNlbnN1cyBpbiB0aGUgQU5JTUEgd29ya2luZyBncm91cCB0byBoYXZlIHRo aXMgSW5mb3JtYXRpb25hbCBkcmFmdCBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIGRyYWZ0IC0gaXQg aXMgZnVsbHkgY29uc2lzdGVudCB3aXRoIHRoZSBjdXJyZW50IEFOSU1BIGNoYXJ0ZXIuDQpjaGFy dGVyZWQgd29yayBpdGVtcy4gVGhlIGF1dGhvcnMgc2hvdWxkIHN1Ym1pdCB0aGUgbmV4dCB2ZXJz aW9uIGFzIGFuIEFOSU1BIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgKGRyYWZ0LWlldGYtYW5pbWEt Ki0wMCkuDQoNClRoZSBhdXRob3JzIHNob3VsZCBrZWVwIHdvcmtpbmcgb24gdGhpcyBkb2N1bWVu dCBhcyBlZGl0b3IgdG93YXJkcyBpdHMgbWF0dXJpdHkuIFRoZSBhdXRob3JzIHNob3VsZCByZXBv cnQgYW55IG1ham9yIG1vZGlmaWNhdGlvbnMgdG8gdGhlIFdHLCBlaXRoZXIgaW4gbWFpbCBsaXN0 IG9yIGluIHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZ3MsIGFuZCBhY3F1aXJlIGNvbnNlbnN1cyBp biBBTklNQSBXRy4NCg0KVGhhbmtzLA0KDQpTaGVuZw0KDQoNCkZyb206IEFuaW1hIFttYWlsdG86 YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNoZW5nIEppYW5nDQpTZW50OiBX ZWRuZXNkYXksIE5vdmVtYmVyIDI5LCAyMDE3IDc6MzYgUE0NClRvOiBhbmltYUBpZXRmLm9yZw0K Q2M6IGFuaW1hLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogW0FuaW1hXSBBZG9wdGlvbiBjYWxs IGZvciBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtYXBpLTA2LCBlbmRzIERlYy4gMTIsIDIwMTcNCg0K DQpEdXJpbmcgdGhlIElFVEYxMDAsIHRoZXJlIHdhcyBhIGNvbnNlbnN1cyB0aGF0IGRyYWZ0LWxp dS1hbmltYS1ncmFzcC1hcGkgaXMgZnVsbHkgY29uc2lzdGVudCB3aXRoIHRoZSBjdXJyZW50IEFO SU1BIGNoYXJ0ZXIsIHVuZGVyIHRoZSBjb25kaXRpb24gaXQgaW50ZW5kcyB0byBiZSBhbiBJbmZv cm1hdGlvbmFsIGRvY3VtZW50LiBBZnRlciB0aGUgbWVldGluZywgdGhlIGF1dGhvcnMgaGF2ZSB1 cGRhdGVkIHRoZSBkb2N1bWVudC4gVGhlIGN1cnJlbnQgaW50ZW5kZWQgc3RhdHVzIGlzIEluZm9y bWF0aW9uYWwuIFRoZXJlIHdhcyBhbiBhZG9wdGlvbiBjYWxsIG9uIHRoaXMgZG9jdW1lbnQgYXMg YSBBTklNQSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGluIHRoZSBBTklNQSBzZXNzaW9uLCBJRVRG MTAwLiBUaGVyZSB3ZXJlIHN1cHBvcnRzIGFuZCBubyBvYmplY3Rpb24gYXMgZmFyIGFzIGNoYWly cyBoZWFyZC4gQXMgYW4gb2ZmaWNpYWwgcHJvY2VkdXJlLCB3ZSBub3cgY29uZmlybSB0aGUgYWRv cHRpb24gaW4gdGhlIEFOSU1BIG1haWxpbmcgbGlzdC4gVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIHR3 by13ZWVrIGFkb3B0aW9uIGNhbGwgb24gZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS4NCg0KDQoN CiAgVGl0bGU6ICAgICAgR2VuZXJpYyBBdXRvbm9taWMgU2lnbmFsaW5nIFByb3RvY29sIEFwcGxp Y2F0aW9uIFByb2dyYW0gSW50ZXJmYWNlIChHUkFTUCBBUEkpDQoNCiAgQXV0aG9ycyA6ICAgTGl1 LCBldCBhbC4NCg0KICBGaWxlbmFtZTogICBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtYXBpDQoNCiAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGktMDYN Cg0KDQoNClBsZWFzZSBleHByZXNzIHlvdXIgc3VwcG9ydCBvciByZWplY3Rpb24uIElmIHlvdSB0 aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBfbm90XyBiZSBhZG9wdGVkLCBwbGVhc2UgYWxzbyBl eHBsaWNpdGx5IGluZGljYXRlIHRoZSByZWFzb25zLg0KDQoNCg0KVGhpcyBhZG9wdGlvbiBjYWxs IHdpbGwgZW5kIG9uIERlY2VtYmVyIDEyLCAyMDE3Lg0KDQoNCg0KUmVnYXJkcywNCg0KDQoNClNo ZW5nICsgVG9lcmxlc3MNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B92817E399DNKGEML515MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byP IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDp ooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9InRl eHQtanVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OuWui+S9kztjb2xvcjpibGFjayI+QWZ0ZXIgd2UgaGFkIHJvdWdoIGNvbnNlbnN1cyBpbiB0aGUg bWVldGluZyByb29tIChJRVRGMTAwLCBTaW5nYXBvcmUpIGFuZCB0aGUgdHdvLXdlZWsgYWRvcHRp b24gY2FsbCBvbiB0aGUgV0cgbWFpbGluZyBsaXN0LCB3ZQ0KIHJlY2VpdmVkIG1hbnkgc3VwcG9y dHMgaW4gZmF2b3Igb2YgYWRvcHRpb24gYW5kIGRvIE5PVCByZWNlaXZlIGFueSBvYmplY3Rpb25z LiBUaGUgY2hhaXJzIGNvbmNsdWRlIHRoZXJlIGlzIGEgY29uc2Vuc3VzIGluIHRoZSBBTklNQSB3 b3JraW5nIGdyb3VwIHRvIGhhdmUgdGhpcyBJbmZvcm1hdGlvbmFsIGRyYWZ0IGJlY29tZSBhIHdv cmtpbmcgZ3JvdXAgZHJhZnQgLSBpdCBpcyBmdWxseSBjb25zaXN0ZW50IHdpdGggdGhlIGN1cnJl bnQgQU5JTUENCiBjaGFydGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJs YWNrIj5jaGFydGVyZWQgd29yayBpdGVtcy4gVGhlIGF1dGhvcnMgc2hvdWxkIHN1Ym1pdCB0aGUg bmV4dCB2ZXJzaW9uIGFzIGFuIEFOSU1BIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgKGRyYWZ0LWll dGYtYW5pbWEtKi0wMCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj5UaGUgYXV0 aG9ycyBzaG91bGQga2VlcCB3b3JraW5nIG9uIHRoaXMgZG9jdW1lbnQgYXMgZWRpdG9yIHRvd2Fy ZHMgaXRzIG1hdHVyaXR5LiBUaGUgYXV0aG9ycyBzaG91bGQgcmVwb3J0IGFueSBtYWpvciBtb2Rp ZmljYXRpb25zDQogdG8gdGhlIFdHLCBlaXRoZXIgaW4gbWFpbCBsaXN0IG9yIGluIHRoZSBmYWNl LXRvLWZhY2UgbWVldGluZ3MsIGFuZCBhY3F1aXJlIGNvbnNlbnN1cyBpbiBBTklNQSBXRy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5 bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0 LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246 bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovk vZM7Y29sb3I6YmxhY2siPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEFu aW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ U2hlbmcgSmlhbmc8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAx NyA3OjM2IFBNPGJyPg0KPGI+VG86PC9iPiBhbmltYUBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4g YW5pbWEtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtBbmltYV0gQWRvcHRp b24gY2FsbCBmb3IgZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS0wNiwgZW5kcyBEZWMuIDEyLCAy MDE3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5EdXJpbmcgdGhlIElFVEYxMDAsIHRoZXJlIHdhcyBhIGNv bnNlbnN1cyB0aGF0IGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGkgaXMgZnVsbHkgY29uc2lzdGVu dCB3aXRoIHRoZSBjdXJyZW50IEFOSU1BIGNoYXJ0ZXIsIHVuZGVyIHRoZSBjb25kaXRpb24gaXQg aW50ZW5kcyB0byBiZSBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50LiBBZnRlciB0aGUgbWVldGlu ZywgdGhlIGF1dGhvcnMgaGF2ZSB1cGRhdGVkIHRoZSBkb2N1bWVudC4gVGhlIGN1cnJlbnQgaW50 ZW5kZWQgc3RhdHVzIGlzIEluZm9ybWF0aW9uYWwuIFRoZXJlIHdhcyBhbiBhZG9wdGlvbiBjYWxs IG9uIHRoaXMgZG9jdW1lbnQgYXMgYSBBTklNQSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGluIHRo ZSBBTklNQSBzZXNzaW9uLCBJRVRGMTAwLiBUaGVyZSB3ZXJlIHN1cHBvcnRzIGFuZCBubyBvYmpl Y3Rpb24gYXMgZmFyIGFzIGNoYWlycyBoZWFyZC4gQXMgYW4gb2ZmaWNpYWwgcHJvY2VkdXJlLCB3 ZSBub3cgY29uZmlybSB0aGUgYWRvcHRpb24gaW4gdGhlIEFOSU1BIG1haWxpbmcgbGlzdC4gVGhp cyBtZXNzYWdlIHN0YXJ0cyBhIHR3by13ZWVrIGFkb3B0aW9uIGNhbGwgb24gZHJhZnQtbGl1LWFu aW1hLWdyYXNwLWFwaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBUaXRs ZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR2VuZXJpYyBBdXRvbm9taWMgU2lnbmFs aW5nIFByb3RvY29sIEFwcGxpY2F0aW9uIFByb2dyYW0gSW50ZXJmYWNlIChHUkFTUCBBUEkpPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyBBdXRob3JzIDombmJzcDsmbmJzcDsgTGl1LCBldCBhbC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7IEZpbGVuYW1lOiZuYnNwOyAmbmJzcDtkcmFmdC1saXUtYW5pbWEtZ3Jhc3At YXBpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaS0wNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWxpdS1hbmltYS1ncmFzcC1hcGktMDY8L2E+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+UGxlYXNlIGV4cHJlc3MgeW91ciBzdXBwb3J0IG9yIHJlamVjdGlvbi4gSWYg eW91IHRoaW5rIHRoaXMgZG9jdW1lbnQgc2hvdWxkIF9ub3RfIGJlIGFkb3B0ZWQsIHBsZWFzZSBh bHNvIGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhlIHJlYXNvbnMuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBlbmQgb24gRGVjZW1iZXIgMTIsIDIw MTcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+U2hlbmcgJiM0MzsgVG9lcmxlc3M8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B92817E399DNKGEML515MBSchi_-- From nobody Tue Dec 19 00:00:22 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7395D12762F for ; Tue, 19 Dec 2017 00:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xED1pLwuBkm9 for ; Tue, 19 Dec 2017 00:00:19 -0800 (PST) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 CB971126DFE for ; Tue, 19 Dec 2017 00:00:18 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:199]) by smtp-cloud9.xs4all.net with ESMTPA id RCoxeP05tnIXbRCoxeQ3kt; Tue, 19 Dec 2017 09:00:17 +0100 Received: from 2001:983:a264:1:579:4c87:465e:bb2a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 19 Dec 2017 09:00:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 19 Dec 2017 09:00:15 +0100 From: peter van der Stok To: Eliot Lear Cc: Brian E Carpenter , Anima WG Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4d5f0683-fc3e-6936-39da-ac0a23f98b86@cisco.com> References: <5aa09826-2f1a-d837-e120-c23141e579d5@gmail.com> <4d5f0683-fc3e-6936-39da-ac0a23f98b86@cisco.com> Message-ID: <9c6b17432a1c9f379c76ce70b0aa91fb@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfDF/DfjJkVPTGcgIy3v00qNb5EsCS527S6OPFLsiw8KXDHpj8NO+gJbaPwtI/GW8ejwB3odwhhiRBjxzgThc5e8glRQ7pNQDVeOAwAoEx8VHPDSFgKbh lBNFfG6WlGU9FyQduasKTJHdCVRXaa4kXJXgN9lmOaX9ZlRwGD5qdB6CMpMph55cj7lkTxWSDaxF/7Hb0SSKBbdMYpKfvGCBOS72sNHTS1L40/Wi0LbbueZZ b+Q9n1nl/4uADtag/8EP6w== Archived-At: Subject: Re: [Anima] Intended status of draft-ietf-anima-bootstrapping-keyinfra 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, 19 Dec 2017 08:00:21 -0000 +1 Peter Eliot Lear schreef op 2017-12-18 20:23: > Absolutely! > > > On 18.12.17 20:01, Brian E Carpenter wrote: >> I just noticed that draft-ietf-anima-bootstrapping-keyinfra >> has Intended status: Informational. >> >> Surely it should be Standards Track? >> >> Regards >> Brian >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Dec 19 18:27:03 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3F31242EA; Tue, 19 Dec 2017 18:26:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tte+anima@cs.fau.de, The IESG , anima-chairs@ietf.org, Toerless Eckert , draft-ietf-anima-prefix-management@ietf.org, rfc-editor@rfc-editor.org, anima@ietf.org, terry.manderson@icann.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151373681344.2686.4716631905351826960.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 18:26:53 -0800 Archived-At: Subject: [Anima] Document Action: 'Autonomic IPv6 Edge Prefix Management in Large-scale Networks' to Informational RFC (draft-ietf-anima-prefix-management-07.txt) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 02:26:53 -0000 The IESG has approved the following document: - 'Autonomic IPv6 Edge Prefix Management in Large-scale Networks' (draft-ietf-anima-prefix-management-07.txt) as Informational RFC This document is the product of the Autonomic Networking Integrated Model and Approach Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ Technical Summary Relevant content can frequently be found in the abstract This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. Working Group Summary This document was called draft-jiang-anima-prefix-management prior to its adoption. There was consenus support for it in favor of adoption, so this document was adopted in January 2016. There was interest in this work posts since its adoption. There was no opposition to this work. This document went through a relevant long document development period (15 months for individual document period, 30 month for WG document period). It has been reviewed well. Document Quality Huawei has expressed interest in implementation. There is a prototype implementation at: https://github.com/becarpenter/graspy/blob/master/pfxm3.pdf https://github.com/becarpenter/graspy/blob/master/pfxm3.py Personnel Toerless Eckert is the document shepherd. Terry Manderson is the responsible AD. IANA Note The IANA is requested to add two names to GRASP Objective Names Table registry defined by [I-D.ietf-anima-grasp] (registry already crated). "PrefixManager" and "PrefixManager.Params". I did review/discuss these names during shepherd review. I think these allocations establish a useful precedent of making multiple objectives of one functional area use a common prefix. From nobody Tue Dec 19 18:42:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16B124234; Tue, 19 Dec 2017 18:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXThH69cBOwX; Tue, 19 Dec 2017 18:42:46 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0135.outbound.protection.outlook.com [104.47.92.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B3212D953; Tue, 19 Dec 2017 18:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cDWIy7PV/INjPj/s3wvyG9oeGI94/73SOFJlrI5BnUI=; b=GXTAxLu6uSEe/5kyj+VSRw3Kic0JDDnpe8dNaCoxZo1Dyro5zh+XUfNYH7IbouRHPZFJPjhO8+9XGgy1mjiaH6G/imNBkoIT0FFHSZeMZJaWc0PfbfCkgm9N7sEVwlRtMnLxyABjx872l64AM98j+qqbbTewusmldxzo1drqhTg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0249.jpnprd01.prod.outlook.com (10.161.78.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Wed, 20 Dec 2017 02:42:42 +0000 Cc: tte+anima@cs.fau.de, anima-chairs@ietf.org, Toerless Eckert , The IESG , draft-ietf-anima-prefix-management@ietf.org, terry.manderson@icann.org, anima@ietf.org References: <151373681344.2686.4716631905351826960.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <3bd8b043-2f55-c0bd-c66b-6c6dd85298d2@it.aoyama.ac.jp> Date: Wed, 20 Dec 2017 11:42:44 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151373681344.2686.4716631905351826960.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0091.jpnprd01.prod.outlook.com (10.165.51.179) To OS2PR01MB0249.jpnprd01.prod.outlook.com (10.161.78.16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a2668939-30b7-4486-6b48-08d5475357e1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:OS2PR01MB0249; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0249; 3:5rZRHlph62iTDbNx8OpG6dgaeWDBLqmFDQ1Dgjls9WMRmpBayKMjwUz8AdBy1yTKCorO6GqwC4AGOkkbnsSRQXIzz3ljloM/s3fZlWlo/4PslQYjp+ohUT2NNBtPwn5ZS+9CG2Wc0uFdVDPezdfMt6S54kR1em5uyLHs4qnCMHkwlc560Ur9nzzFos/8/kxcO/4f72mycPtikX1aXYvz3gro+DMUwfqVwaU2mouyCarqDIcWuXOMaR5/h7yMgvA8; 25:s8P4HFREYQ5ArIfi14Q8Lxr4IV4tDZH55G8vMpUHOdI4xBsuSirjQKZz0YKjavuyMV2ZIXgtDPclb6Grliogqa3gxtMkxAX2EdhmrPTrlpU2KLjFyFF7BacXvLrCsqJddT9QQYVd6oieMssiOOCQHZhApIGEsU6M7v7nXu2lGi5mvgEhsL54MktNJbAncelV1ngxac5Pf68I2+rVhkbxBc4xv5589vjqi/7c7d+h672RyVaD91OIZYCWeMJGvd6SUKH82K75DT9K2Ugwnc6fiEHnfq6iLeKen3J9cABBIxsKksiAOTWrlHdxBwvb4E/XO8CGm8iZBi4B4kbWj4d5NeZ6j3EuCM1M0WeTvrqrxV8=; 31:mJSd/v36CDJ7lVbYK3fH+wS6HMvQSsUq3MayGCWCvafoRbV6WAUdc6pMyEMgyQypQmBrHQHeK+VeDUp7iesjoquGvqWT9Ek2rXuD6NnOGZsIvubPMpPPC+CF001GKKPoehDagO1kfSCIIXBMB/4TFFnqpVJfz5w4KoCIAfwTh5lezivOEtCUdRWYgXbjVv7q/097nUgS1sGpnLnk1rcM/SfD4OV4IDUdq5hMA5Dpq+A= X-MS-TrafficTypeDiagnostic: OS2PR01MB0249: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(6041268)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:OS2PR01MB0249; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:OS2PR01MB0249; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0249; 4:z+shgOGIbnV3nbTVPSQsEq36Wwq6qSL4spO++aoPv1teCBjace+8SG5Mhkab6sUU9vTOgsySw5dYlodk+lijZLsMbIFlWYMkI2pE0BoLu3apCCzNUHfyMiBubukWqFbC5GzwnhPieQIRMrI2PgLslq1Xzhvk41JA4jAjDg86Lcvo0JtD5qgvCDCYT9W5RU5uda/H4Ici7Fl7CHflSM9qYhGMsOmLPYgEAQw+d+WNRVhq3l0YIFFD/ejYsuVgSQX0LzDOf5HffTScPUZgUiHJiecEH2zhDvTmzIbI+q0qWhkZ/+qxa0afoaZKaOHrLuL124kxtBOFOryKrJ7vW6WUJ9zfHjasjkcIblpXu4UsGiA= X-Forefront-PRVS: 0527DFA348 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(346002)(39840400004)(366004)(39380400002)(396003)(189003)(199004)(24454002)(377424004)(81156014)(31696002)(8676002)(59450400001)(36916002)(65956001)(2870700001)(52116002)(47776003)(2906002)(49976008)(81166006)(4326008)(52146003)(59246006)(966005)(23676004)(2486003)(76176011)(478600001)(305945005)(54906003)(74482002)(25786009)(7736002)(53936002)(229853002)(6116002)(42882006)(53546011)(386003)(3846002)(2950100002)(16526018)(65806001)(86362001)(66066001)(5660300001)(65826007)(6486002)(1671002)(50466002)(31686004)(90366009)(64126003)(97736004)(6306002)(106356001)(786003)(16576012)(6246003)(58126008)(230783001)(68736007)(316002)(109986005)(8936002)(105586002)(83506002)(67846002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0249; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMjQ5OzIzOloyWTdGUGZkMndCOGRVc21nMDdCRWtmanVG?= =?utf-8?B?OHRiM0tZSSsxU0Y1NXNnOWZTNzdvc29JN2JseGxXaStoR3M4SXE3clh6czhI?= =?utf-8?B?WWxwZmt1WWhpTDNhWW1yWDFqanFiYWU1OVFlNlkybi96U2Q4WldaZjJQWGwr?= =?utf-8?B?TkRFRm1CS3lrTEtkTzE5ZkF0VEFMTmlHekt0TWhqRjNDaThUOFhBZEJsNCtQ?= =?utf-8?B?U2x2N1UvN2Fob25Ddkk2Vld1TmdZdktMR3kyY200aXkyNXEwYmxEaEpZU0dn?= =?utf-8?B?WWlNQWVCeTR3VlIwR3JZS3N0WldqV2pUeVU0LzFuNmEweW44MmFGMStrZGdn?= =?utf-8?B?bU1RcnZUZE1ZKzZaVFdaTHNUQVFwVVVvaU55N1lta21ieHdWcVBBbk5jdSt3?= =?utf-8?B?TDVIVnVlQnQ4WDE3dXkxQ2l4VFN2K252VWZaeEJKTy9ucUg2K0VSODZlOHdC?= =?utf-8?B?RW5IQlRaL3dEQ3p4UlIxcTFRZnIybWQ3YThhWW43OUliWmdkejl2ZHBKV3pU?= =?utf-8?B?UmhhaU1MYlJmUWxMUWQrai9GWVZ6TnFlcXNsNG9NOFVPZjI1SjZ5NG1YWW9O?= =?utf-8?B?MWRVRWJPd3RlMVpFVFZDWWJGNUVEbXNQUk9xTTVSOElRR3BzR3QzZ084dU5q?= =?utf-8?B?QWdNYXlxODR5Snljb2hHcmxNMElLYytKZ0t6TWRNZHZ2Lzg5VVVUaDJvRDZY?= =?utf-8?B?S3BBSHkrVE14SzRabFJXV0xwQUpuVjA1aU1XWFRKMk80WFhFbTJuL05CaXRH?= =?utf-8?B?YTBUcXNPanhIQkkwdi85c09JYjdXNVJxdzlZdnZCb3RUYXBaMFNWZkE5dHlK?= =?utf-8?B?VVdpNWJsUjNsSktpZWNPQ3c2QWxhbFBVWE9KSW91dWQ4YSs2elU5emZUL3Q1?= =?utf-8?B?a2d1SUJ0QVo1SHAvQm9DZHJSZkVydlducFh1LzdhSXQ5aFNFdkF2UVA0ak8x?= =?utf-8?B?eW94Rk1CVHRBeFJsQW9lSnJxc3FBN0tCNkNUeENyU3VtT2phWjFISUJncWxO?= =?utf-8?B?Tys3dktkNlYyOGJYNU1ZUTJhR3I1ajNIdXpSaWFPUE05VDBkckdkNlhPK0U5?= =?utf-8?B?OWxjc1gvV25xd0ZqZVJBd05CZnBFK2pJOUg4RlB5SW9Fa0NUVitMT0ZKK09O?= =?utf-8?B?bFdCZTlFUC9nYjVXT3RFc1RRSkRSeEhwK1BLVTJkdmdzR3p2OXk1cGp0Zlk3?= =?utf-8?B?aGJGMmlHMlBldzJaRW1SVWdqNFB2U2lzMTk5ZzBxdzNNV2pGY1NPVVlRZW0r?= =?utf-8?B?L2pDVExxR0RldlBha0luTjR5ajZwckNaSjU0RmJlZWtnZ0xrcUptK3JNaDBP?= =?utf-8?B?UThlSFJKcE9iMDEwOUsvWlRmK0ZzUlpvamJOZGVycVhORkJTbUIzZHJwNmJJ?= =?utf-8?B?a2hudzFSVGw1ZDJqVm1PWXdrV1hkVTVqUFdFbHBCTGt1emV3YUhFaHpURWJh?= =?utf-8?B?c3J5elU3NUNDaDYzSjQ5MXljL2RlMGYwdHZLU2ZnNkFvVHBJdmo3SHFxaGFm?= =?utf-8?B?WWFlZnRoZTlkM2srS0dnYXdiSXNyRGdGdTMwaXZEN3Bkc25jTUFMSmp4N2Zv?= =?utf-8?B?OGdqMkt0SmVuU0dPUkN3RTE1aTE0SkFHc3VHc0g3WTE3WXBqU1R5aFJic3ZU?= =?utf-8?B?ckdtQklFT2tHbmJ4VkVHa0dtakJoMTBEMGN3UG50ZWhGT2lIcS9RSGxOdk5C?= =?utf-8?B?NFVGc0VuaG1NbkNmS1RCVE9ZUE5seXpXSnBNQTZaMGxmZlV1TUV2Q3NtWnJX?= =?utf-8?B?UzkwYU5NeGd1TkQveExubWJJNm5IM1hYUGcrZkZZU2N6SzduMFZUWlY3Q3BZ?= =?utf-8?B?MklVc2tURDAveGFwZEtSeDJ2bTNHSkhVSi9ZSUpoeDAzYkllbmhTeDdBTGF4?= =?utf-8?B?ZFBONHNTU2l5VGsvYzVNOGlDVk9SK1M2L09jMG1JNUU4QkxIRGdDVzFiN1BY?= =?utf-8?B?Ny9pU2VodzAvT0ZnMkRGS1JRc0VGU3QrUHhCMzRFVkhEenJHeGsxWUVkMVVu?= =?utf-8?B?enpUN0tTSkY1dWZ4aUVCLzlNKzl1dVVkQ2Y4c1ZMYzQvelNlZ2lnZngzUkV3?= =?utf-8?B?YW1UOVhNdkdlVDNDaGpoMVlmbUx0UVdtMzFYZlNMNkx2b0sxWUU0R0xTdDlX?= =?utf-8?B?M3NrUUJDdU05ellna25XanVPVVQ2S0lMV1JMck5HdXJ5V0VOUGZ6bjFwRkhS?= =?utf-8?Q?4EJbW1wVWZiVyk4G2SowPm/HvFU5uozsVNXH5W6Ouw=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0249; 6:Am5I7ws/LoPchc0VSnb+3Q/mVSioPKx+jUxbEgidIUlxlgGXkq5LkvP/766XrjEy0VNvLsQgUVGKI13huqQMdN4ZkirwrukoautRWWSlFC2g2LoXgcpq9yQBqmhnNvjhDT7UO/dSREzW0l3NGtXgYJrXe5h/WttJ/WR6W+JdQmL2vsVLfUkQ4TwgRZdWdbK5ReihhbmqMm8sxTkNI1wsFn1Hqurlb09VRPAnuMC8q3ncTlM+1xoJjlPy1rju80ZH7aCBvVn+fxX4hiHIhPLE29jDZqn+H4U6p1H+A+71Nay8ebVxDNpy59OoQTUzTMWtt9owNBSHNw4AjMMeFO5EuMYvwtLRaVw19WX6IWXWSC0=; 5:RIz5VuZholmFy7gOynclVQLSBCJpzk8qjc8H87g9SKUryegREruTDzCS48xlgCQi3MFgIDj9M1BIQ80YRXpB1f5Pifx3QSk2srnE5nIa58/ApWRMnipmQNzRpvM7/3mBY3Ym4fD67j3YSNGnhxdaV5x9J5wZml1TCNG2Fsgnp2g=; 24:x6Ws7Xcc7AAM5sP/gwneH9KTpFhTHv7VDucUgT9y1nSq97GnVcSRAS8xhQryV92uwJKGpLJrs8OmvBXQnfWxYXhzsJU8rE6dL+NPW3AEA40=; 7:nkDkjOkfevYOGuQyY7I9HpHofgBTf2a3r1rWN/ohBHn9RrLODizQaPDwDLYZMSXSiEwqY/Karmw9RKXpeuUMqNyw3HYjoU2XcfLGeF1nvygO1lMHDXYGokjsqvlLyPW0J2haG3tcEeLjxfpEpVv3TZ3EzV7n/EZtPBwIE+OuIwTCkyW0f4njCPbvRBCoYrr6zvv9JqARpAC1YezwbyoHN4JhxTM4N5dc53TCYGew+I92wCZAbgt4xVNFXdoEqxBT SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2017 02:42:42.0979 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a2668939-30b7-4486-6b48-08d5475357e1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0249 Archived-At: Subject: Re: [Anima] Document Action: 'Autonomic IPv6 Edge Prefix Management in Large-scale Networks' to Informational RFC (draft-ietf-anima-prefix-management-07.txt) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 02:42:48 -0000 I wonder how the first line of the Technical Summary got there :-). Regards, Martin. On 2017/12/20 11:26, The IESG wrote: > The IESG has approved the following document: > - 'Autonomic IPv6 Edge Prefix Management in Large-scale Networks' > (draft-ietf-anima-prefix-management-07.txt) as Informational RFC > > This document is the product of the Autonomic Networking Integrated Model and > Approach Working Group. > > The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ > > > > > > Technical Summary > > Relevant content can frequently be found in the abstract > This document describes an autonomic solution for IPv6 prefix > management at the edge of large-scale ISP networks, with an extension > to support IPv4 prefixes. An important purpose of the document is to > use it for validation of the design of various components of the > autonomic networking infrastructure. > > > Working Group Summary > > This document was called draft-jiang-anima-prefix-management > prior to its adoption. There was consenus support for it in favor of > adoption, so this document was adopted in January 2016. There was > interest in this work posts since its adoption. There was no opposition > to this work. > > This document went through a relevant long document development > period (15 months for individual document period, 30 month for WG > document period). It has been reviewed well. > > Document Quality > > Huawei has expressed interest in implementation. > There is a prototype implementation at: > https://github.com/becarpenter/graspy/blob/master/pfxm3.pdf > https://github.com/becarpenter/graspy/blob/master/pfxm3.py > > Personnel > > Toerless Eckert is the document shepherd. > Terry Manderson is the responsible AD. > > > IANA Note > > The IANA is requested to add two names to GRASP Objective Names Table > registry defined by [I-D.ietf-anima-grasp] (registry already crated). > "PrefixManager" and "PrefixManager.Params". I did review/discuss these > names during shepherd review. I think these allocations establish > a useful precedent of making multiple objectives of one functional area > use a common prefix. > > . > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Tue Dec 19 19:31:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1560126CB6; Tue, 19 Dec 2017 19:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Iec33n0Hf31; Tue, 19 Dec 2017 19:31:35 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3943F124D85; Tue, 19 Dec 2017 19:31:35 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id u25so12038206pfg.5; Tue, 19 Dec 2017 19:31:35 -0800 (PST) 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=UTJxBnOpIHJ47LwcRcLXbzzutqhxcuX7/9GaOmRE8js=; b=u2Ip4lItXNLOqIAiMl/NuRL+8p9kN8Jet8VwWpDHIs6hcoVSYd7u8r7O2esbNBTbul u8gFIz5HxnBW3F+dVsR3QjG455c0xjGPMV8fkIg6OdVpXt5/sonwo1qksRu71BUfWlVv C1IB6g27SNqPBT2WLGrOkQ7kc0KdYcpGiTAKthC04Vm94AjTaE/kkpGbOZ56XOYhp6ll XYngKdMcS9w/ufxXVRVZ1DVJh99JW0zzbbTvbAiDf1ascIqwn7krgbzrYqAWTNac8mbG 4hm3p5739xH1X2PHg0aOUUro45Sn5OVGTjzaJ1wf9RePsHRVkGRvvJhOPGz5loJBPu+x 8sWA== 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=UTJxBnOpIHJ47LwcRcLXbzzutqhxcuX7/9GaOmRE8js=; b=mZwTX1mK2OjxwCujUbJG1gSRY/0KloD2pJgGIgg9ZGm5EWG1kXr4CKTUCoDwxruvs6 zL69gQGJrCWJAgEb8KedDrrano+k2isxq27LmWf8a58Vd03ivS1H1VoLu+l4Y0C0fKYX MkV0E9PxLnysTRdK9yWfOzAJ7y7yp/k/ADGDsdA2q/4Ak5eKC0jb6rc/P8WbFIm5BTz6 c57zOwXpcuk/lCmK/KvYYws1f4r5pvdktpGiJO9/RNxjty3Dt5IokKBd6XBfGfSFLRBk NHMHjez2oFraJAhfdWCbv6KrSCBRh11dQ22XeCqWTZfoZF8stH/wre+HVblvHwYZtFr0 5Z5Q== X-Gm-Message-State: AKGB3mKsf817vbTqCI2AqXARNUq0o8Yn9lqg1HVKL54gWPIzncXBxZqW AXRqC310JJNvskrHwewmmgxi+w== X-Google-Smtp-Source: ACJfBosfQIH9I95r+9vVHnlbG4nRgZwjBXNeAU4fjb0GTcTQFdgsuBqqzRutA0k+aeWd+N6xJZcdbg== X-Received: by 10.101.77.210 with SMTP id q18mr4988573pgt.145.1513740694331; Tue, 19 Dec 2017 19:31:34 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o8sm9023641pgn.52.2017.12.19.19.31.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 19:31:33 -0800 (PST) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Cc: tte+anima@cs.fau.de, anima-chairs@ietf.org, Toerless Eckert , The IESG , draft-ietf-anima-prefix-management@ietf.org, terry.manderson@icann.org, anima@ietf.org References: <151373681344.2686.4716631905351826960.idtracker@ietfa.amsl.com> <3bd8b043-2f55-c0bd-c66b-6c6dd85298d2@it.aoyama.ac.jp> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 20 Dec 2017 16:31:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3bd8b043-2f55-c0bd-c66b-6c6dd85298d2@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Document Action: 'Autonomic IPv6 Edge Prefix Management in Large-scale Networks' to Informational RFC (draft-ietf-anima-prefix-management-07.txt) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 03:31:37 -0000 On 20/12/2017 15:42, Martin J. D=C3=BCrst wrote: > I wonder how the first line of the Technical Summary got there :-). Relevant content can frequently be found in the template ? Brian >=20 > Regards, Martin. >=20 > On 2017/12/20 11:26, The IESG wrote: >> The IESG has approved the following document: >> - 'Autonomic IPv6 Edge Prefix Management in Large-scale Networks' >> (draft-ietf-anima-prefix-management-07.txt) as Informational RFC >> >> This document is the product of the Autonomic Networking Integrated Mo= del and >> Approach Working Group. >> >> The IESG contact persons are Warren Kumari, Benoit Claise and Terry Ma= nderson. >> >> A URL of this Internet Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ >> >> >> >> >> >> Technical Summary >> >> Relevant content can frequently be found in the abstract >> This document describes an autonomic solution for IPv6 prefix >> management at the edge of large-scale ISP networks, with an extens= ion >> to support IPv4 prefixes. An important purpose of the document is= to >> use it for validation of the design of various components of the >> autonomic networking infrastructure. >> >> >> Working Group Summary >> >> This document was called draft-jiang-anima-prefix-management >> prior to its adoption. There was consenus support for it in favor of >> adoption, so this document was adopted in January 2016. There was >> interest in this work posts since its adoption. There was no oppositio= n >> to this work. >> =20 >> This document went through a relevant long document development >> period (15 months for individual document period, 30 month for WG >> document period). It has been reviewed well. >> >> Document Quality >> >> Huawei has expressed interest in implementation. >> There is a prototype implementation at: >> https://github.com/becarpenter/graspy/blob/master/pfxm3.pdf >> https://github.com/becarpenter/graspy/blob/master/pfxm3.py >> >> Personnel >> >> Toerless Eckert is the document shepherd. >> Terry Manderson is the responsible AD. >> >> >> IANA Note >> >> The IANA is requested to add two names to GRASP Objective Names Table >> registry defined by [I-D.ietf-anima-grasp] (registry already crated). >> "PrefixManager" and "PrefixManager.Params". I did review/discuss the= se >> names during shepherd review. I think these allocations establish >> a useful precedent of making multiple objectives of one functional are= a >> use a common prefix. >> >> . >> >=20 From nobody Tue Dec 19 21:05:55 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635912778D for ; Tue, 19 Dec 2017 21:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9F0EcPddcN6X for ; Tue, 19 Dec 2017 21:05:52 -0800 (PST) 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 3AF63120726 for ; Tue, 19 Dec 2017 21:05:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7374820092 for ; Wed, 20 Dec 2017 00:09:32 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ED40E81AFF for ; Wed, 20 Dec 2017 00:05:50 -0500 (EST) To: anima@ietf.org References: <151323291963.6071.13432030924018362994.idtracker@ietfa.amsl.com> <14447.1513347874@obiwan.sandelman.ca> From: Michael Richardson Message-ID: <5f1cd0c9-249b-049f-eff6-5f2d65ba41dd@sandelman.ca> Date: Wed, 20 Dec 2017 00:05:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <14447.1513347874@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lCTS2phnfDUU6BoHWkpd7agpWviDnL5eg" Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) 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, 20 Dec 2017 05:05:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lCTS2phnfDUU6BoHWkpd7agpWviDnL5eg Content-Type: multipart/mixed; boundary="0QGL9fK5LVTEnmUjCq0u2sjG3XauEBvBO"; protected-headers="v1" From: Michael Richardson To: anima@ietf.org Message-ID: <5f1cd0c9-249b-049f-eff6-5f2d65ba41dd@sandelman.ca> Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-voucher-06: (with COMMENT) References: <151323291963.6071.13432030924018362994.idtracker@ietfa.amsl.com> <14447.1513347874@obiwan.sandelman.ca> In-Reply-To: <14447.1513347874@obiwan.sandelman.ca> --0QGL9fK5LVTEnmUjCq0u2sjG3XauEBvBO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/15/17 09:24, Michael Richardson wrote: >=20 > Adam Roach wrote: > > among them. I'll note that these techniques relate to MIME types = and > > related > > data (filename extensions). The fact that *this* document doesn't= > > define a MIME > > type for the CMS-signed-JSON variant will make it difficult and/o= r > > awkward for > > these future formats to employ these techniques. For example, if = I were >=20 > In the first use of this format over HTTPS, which is "BRSKI", >=20 > We register parameters for the application/smime-type. > Since that we written we changed the "primary" signing type from PKCS7 = to > CMS, so I think that these will become application/cms registrations in= stead. After some discussion, Max and I (Kent is on PTO) decided that your way is best, and provided that Kent has no problem with your suggestion of application/voucher-cms+json, we will go with that. https://github.com/anima-wg/voucher/pull/14/commits/683d3c49037dcfe3e6571= 7856eaabb1e213fe4ca are the changes... does the MIME registration look right? --0QGL9fK5LVTEnmUjCq0u2sjG3XauEBvBO-- --lCTS2phnfDUU6BoHWkpd7agpWviDnL5eg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlo5764ACgkQgItw+93Q 3WUXBAf+LpZLtmP3fw8X2Zhv5wZ4wtvYaIc5J0+h5MD28XYTngkJZZ7/pOJcTHZ3 szpfK1X+znupy5jym37DExdIMycAwHO4PLjhxXNHmalXXHq5kfEJ3uKDysuoMV/+ Gborb0DJmFvL3LL/kpXH+SguCKzTo/h+fk6bZqV9UeGy21lBvvAuANkq4J7cD5/x EO2oLbUHmvADkUzInv0gOzrPAO2xp+bjZyzMqe3MTOKxDKYpN3kHIvsItDhHNFqY z8bq4hlxceHc73BekuweTOtcdL7Wt4BJZeCodpERF5s2Odsf5FtFifKs85Q6K1oU O4T0a//ck9qcdJEamIbwAgtUCRjI3A== =auYg -----END PGP SIGNATURE----- --lCTS2phnfDUU6BoHWkpd7agpWviDnL5eg-- From nobody Fri Dec 22 20:16:37 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B42126CF6; Fri, 22 Dec 2017 20:16:32 -0800 (PST) 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.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151400259278.30081.17549458114552088108@ietfa.amsl.com> Date: Fri, 22 Dec 2017 20:16:32 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-api-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: Sat, 23 Dec 2017 04:16:33 -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 : Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) Authors : Brian Carpenter Bing Liu Wendong Wang Xiangyang Gong Filename : draft-ietf-anima-grasp-api-00.txt Pages : 25 Date : 2017-12-22 Abstract: This document is a conceptual outline of an application programming interface (API) for the Generic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASA) calling the GRASP protocol module to exchange autonomic network messages with other ASAs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-api-00 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-api-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/