From nobody Fri Jun 1 08:11:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D4F12D95F for ; Fri, 1 Jun 2018 08:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GamRgMlVg_dp for ; Fri, 1 Jun 2018 08:11:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7DC12D957 for ; Fri, 1 Jun 2018 08:11:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E06BA20093 for ; Fri, 1 Jun 2018 11:24:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3FD381C6; Fri, 1 Jun 2018 11:10:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D7251C5 for ; Fri, 1 Jun 2018 11:10:57 -0400 (EDT) From: Michael Richardson to: anima@ietf.org In-Reply-To: <28209.1527818259@localhost> References: <28209.1527818259@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] naming of constrained voucher YANG model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 15:11:40 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > Also, a related question is whether ietf-cwt-voucher-request to inher= it > from BRSKI's ietf-voucher-request, or from ietf-voucher... It's not > clear to me that it's a 100% subclass yet. So, the name started at "cwt-voucher-request", because it was originally thought that it would use CWT directly (RFC8392), using the Claim keys from there. Then after some distraction, the process is now a COSE signed SID generated YANG, which isn't exactly CWT at all. The name "cwt-voucher"{,-request} is no longer appropriate. Some constraction of "constrained" is probably now appropriate, looking for suggestions.=20=20 It's also reasonable to say that we use CWT concepts when they map, and introduce new key ids via the YANG/SID mechanism. That's a significant design change, but it's not that huge. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxFh/oCLcPvd0N1lAQImeAgAqQUwGSXbuhBiJBu7utnD/1lPXHQ+q/eW +hdSZspYQALZc7eaSDI8rxoQMPsXwWUc9H0RxWxt4vF2iDjdBGK1EVOwBv/+ujEj NyjFE/9fUaKwIVdhzQZ+Do78uRdVbzVQA4ONOKzX1l7QBIRDr8ZNLSXfB1Ocxh+K 2SrVNQ5xs4Crzyk5vA3twnUg6A/zxfktASFlS03Xt4o64n6qWkEjB1Zv3SXebCtI k5EG6RW7IOs9qatyrDcrHibtUZmk4wnfhOGwxF8lKk6+0wa6oSry4c/jwNQmVV/0 koDnF4If1EPrSPLupYrDY5V/Kc6PCYq4ECMEtTARU9bHtZnADGhi0A== =Ic3B -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 1 09:00:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2612DA15 for ; Fri, 1 Jun 2018 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 rgDbqeGZ0ONu for ; Fri, 1 Jun 2018 09:00:18 -0700 (PDT) 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 83CB912DA08 for ; Fri, 1 Jun 2018 09:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2024; q=dns/txt; s=iport; t=1527868818; x=1529078418; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ARzySLQddXoIHL6sVcnKo6RBjr3Yy+IpV6EoVGQqw20=; b=AGu0hCTZvEN5IoEXE30NoX/0VX5nouYs/k/VD2l43JTE9aRH3c0QDeNw E2Wqd+8js9+joPsBiBs1YM/B9lUhbVwj/crd29+Xn2SxgVoji1Fj2iXMn CjMGM/AnS6bKccl2JCsmQJNPj29gN31iBsvRAiCaNM/lblV9dIuXBBAzZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQDLbBFb/5xdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYn8oCoNtiASMaIFYIZRMgXgLGAuBVIJ1AheBbiE0GAE?= =?us-ascii?q?CAQEBAQEBAmwcDIUoAQEBAwEBASEROgsFCwIBCBgCAiYCAgIlCxUQAgQOBYM?= =?us-ascii?q?iAoF3CA+nFIIchFiDaIFogQqHNYITgQ8kDIIvLoMRAQGBYIMAMIIkAowtjD8?= =?us-ascii?q?JAo5fjRWQcgIREwGBJB04gVJwFTsqAYIYCYIXF4JxhWiFPm+OUYEZAQE?= X-IronPort-AV: E=Sophos;i="5.49,467,1520899200"; d="scan'208";a="401111609" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 15:29:02 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w51FT155028679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2018 15:29:01 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Jun 2018 10:29:01 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Fri, 1 Jun 2018 10:29:01 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] naming of constrained voucher YANG model Thread-Index: AQHT+b0RPNaABYlNlEayjtkmudvvCKRL2t2A Date: Fri, 1 Jun 2018 15:29:01 +0000 Message-ID: References: <28209.1527818259@localhost> <22706.1527865857@localhost> In-Reply-To: <22706.1527865857@localhost> 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.4] Content-Type: text/plain; charset="utf-8" Content-ID: <6D17CBA244DF634B94E4743B807B678B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] naming of constrained voucher YANG model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 16:00:27 -0000 d2hhdCBpcyB3cm9uZyB3aXRoIGdvaW5nIHNpbXBsZTog4oCcY29uc3RyYWluZWQgdm91Y2hlciBy ZXF1ZXN04oCdID8gDQoNCi0gbWF4DQoNCj4gT24gSnVuIDEsIDIwMTgsIGF0IDk6MTAgQU0sIE1p Y2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gDQo+IA0K PiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+PiBB bHNvLCBhIHJlbGF0ZWQgcXVlc3Rpb24gaXMgd2hldGhlciBpZXRmLWN3dC12b3VjaGVyLXJlcXVl c3QgdG8gaW5oZXJpdA0KPj4gZnJvbSBCUlNLSSdzIGlldGYtdm91Y2hlci1yZXF1ZXN0LCBvciBm cm9tIGlldGYtdm91Y2hlci4uLiBJdCdzIG5vdA0KPj4gY2xlYXIgdG8gbWUgdGhhdCBpdCdzIGEg MTAwJSBzdWJjbGFzcyB5ZXQuDQo+IA0KPiBTbywgdGhlIG5hbWUgc3RhcnRlZCBhdCAiY3d0LXZv dWNoZXItcmVxdWVzdCIsIGJlY2F1c2UgaXQgd2FzIG9yaWdpbmFsbHkNCj4gdGhvdWdodCB0aGF0 IGl0IHdvdWxkIHVzZSBDV1QgZGlyZWN0bHkgKFJGQzgzOTIpLCB1c2luZyB0aGUgQ2xhaW0ga2V5 cyBmcm9tDQo+IHRoZXJlLg0KPiANCj4gVGhlbiBhZnRlciBzb21lIGRpc3RyYWN0aW9uLCB0aGUg cHJvY2VzcyBpcyBub3cgYSBDT1NFIHNpZ25lZCBTSUQgZ2VuZXJhdGVkDQo+IFlBTkcsIHdoaWNo IGlzbid0IGV4YWN0bHkgQ1dUIGF0IGFsbC4NCj4gDQo+IFRoZSBuYW1lICJjd3Qtdm91Y2hlciJ7 LC1yZXF1ZXN0fSBpcyBubyBsb25nZXIgYXBwcm9wcmlhdGUuDQo+IFNvbWUgY29uc3RyYWN0aW9u IG9mICJjb25zdHJhaW5lZCIgaXMgcHJvYmFibHkgbm93IGFwcHJvcHJpYXRlLCBsb29raW5nIGZv cg0KPiBzdWdnZXN0aW9ucy4gIA0KPiANCj4gSXQncyBhbHNvIHJlYXNvbmFibGUgdG8gc2F5IHRo YXQgd2UgdXNlIENXVCBjb25jZXB0cyB3aGVuIHRoZXkgbWFwLCBhbmQNCj4gaW50cm9kdWNlIG5l dyBrZXkgaWRzIHZpYSB0aGUgWUFORy9TSUQgbWVjaGFuaXNtLiAgVGhhdCdzIGEgc2lnbmlmaWNh bnQNCj4gZGVzaWduIGNoYW5nZSwgYnV0IGl0J3Mgbm90IHRoYXQgaHVnZS4NCj4gDQo+IC0tIA0K PiBdICAgICAgICAgICAgICAgTmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgICAgICAgICAgICAgICAg IHwgaXB2NiBtZXNoIG5ldHdvcmtzIFsgDQo+IF0gICBNaWNoYWVsIFJpY2hhcmRzb24sIFNhbmRl bG1hbiBTb2Z0d2FyZSBXb3JrcyAgICAgICAgfCBuZXR3b3JrIGFyY2hpdGVjdCAgWyANCj4gXSAg ICAgbWNyQHNhbmRlbG1hbi5jYSAgaHR0cDovL3d3dy5zYW5kZWxtYW4uY2EvICAgICAgICB8ICAg cnVieSBvbiByYWlscyAgICBbIA0KPiAJDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg== From nobody Fri Jun 1 11:11:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B29412DA42 for ; Fri, 1 Jun 2018 11:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzJ8M0xlrwpK for ; Fri, 1 Jun 2018 11:11:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E37012DA29 for ; Fri, 1 Jun 2018 11:11:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E4CED20093 for ; Fri, 1 Jun 2018 14:24:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BD6381C6; Fri, 1 Jun 2018 14:10:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BB5A11C5 for ; Fri, 1 Jun 2018 14:10:27 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 18:11:04 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > Anyhow. let me just list what i think is necessary to fi up the GRASP= so it works > for both TLS and IPinIP. You seem to write TLS in a few places where TCP is actually called for. To be more precise, it's static 1:1 destination NAT66, aka "port-forward" > e) Add at end of 4.1.1 suggested text: =20=20=20=20=20=20=20 > The transport-proto of the locator-option indicates the mechanism(s) > supported by the proxy to the pledge. IPPROTO_TCP indicates the > mandatory ANI TLS circuit proxy. IPPROTO_IPV6 indicates the optional > IPinIP proxy, see Appendix C. IPPROTO_UDP would indicate a future > CoAP mechanism, see Section 4.2. For IPPROTO_IPV6, proto-number > MUST be 0. =20=20=20=20=20=20 > The above example shows a proxy supporting both ANI TLS circuit proxy > and IP in IP proxy. This would seem to be the only needed text to me. > b) Please consider improving the example as above for 4.1.1: > - lead in text for example > - example title > - [ [ objective, locator-option ] ] structure fix > - Ideally also include both TLS and IPinIP options in example > Also: > - I find the use of port 80 in the example highly confusing given how > the TCP connection MUST use TLS. Please change to AB80 (anything but > 80). okay. > So, your full example locators with objectives would be: > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 6, = 443]] ] > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 17,= 5683] ] > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fe80::1234, 41, 0] ] > Is this join registrar supporting ANI TLS proxy ? > Aka: i can't distinguish for the TCP locator whether it just indicates > a permitted TCP port for the IPinIP proxy or whether it indicates > the TCP port supported for IPinIP. And even if the proxy supports bot= h, > its not clear to me that the TCP ports for "native" would be the same= as > for IPinIP. Maybe its different code-paths =3D=3D different ports. I'm sorry, I don't even understand the problem. Maybe someone else can translate for me. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxGMEICLcPvd0N1lAQL1KwgAgzlvajNBRVFh59u4Roz0e9ROt0TFXa5M Ar4xdLmEEd1hsOhB4s9jnqnrtpGqQml2fclbhPMt9t6poKIVbCvshpgsskHhSgGS BObpHtbVNrHzWWzdFtE4zU7/cF2ugDP3CXSe7USFK/A51nF1LMpZkR5aeWLbafpl JU9dAP03uDvTIyufMO4TU0DSe7nZ6H8s6oc9/ytZuCQDMo/VeJ+wmEgMlFptOT15 6O1p1NIWT+GqjDNi6BqM8rgbriUeQsJnQWJDMIRKVggi85UhYL4CxaPIORkDFj1R RcAkO/+EXUBzg1BEykWQ29aMV2mHNxXNuvrUerzl4hHRbAk9TfN+NA== =N91s -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 1 12:04:46 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7B5126BF3 for ; Fri, 1 Jun 2018 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_-_v-b6zwAo for ; Fri, 1 Jun 2018 12:04:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5547A126B6D for ; Fri, 1 Jun 2018 12:04:41 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7505A58C504; Fri, 1 Jun 2018 21:04:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 669604401A4; Fri, 1 Jun 2018 21:04:36 +0200 (CEST) Date: Fri, 1 Jun 2018 21:04:36 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20180601190436.6mfyk7udb3rybmei@faui48f.informatik.uni-erlangen.de> References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> <1176.1527876627@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176.1527876627@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 19:04:45 -0000 On Fri, Jun 01, 2018 at 02:10:27PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > Anyhow. let me just list what i think is necessary to fi up the GRASP so it works > > for both TLS and IPinIP. > > You seem to write TLS in a few places where TCP is actually called for. > To be more precise, it's static 1:1 destination NAT66, aka "port-forward" Hmm. I had only written TCP and then i saw your text using the term "ANI TLS circuit proxy", so then i was changing my proposed text to be compliant with that. > > e) Add at end of 4.1.1 suggested text: > > > The transport-proto of the locator-option indicates the mechanism(s) > > supported by the proxy to the pledge. IPPROTO_TCP indicates the > > mandatory ANI TLS circuit proxy. IPPROTO_IPV6 indicates the optional > > IPinIP proxy, see Appendix C. IPPROTO_UDP would indicate a future > > CoAP mechanism, see Section 4.2. For IPPROTO_IPV6, proto-number > > MUST be 0. > > > The above example shows a proxy supporting both ANI TLS circuit proxy > > and IP in IP proxy. > > This would seem to be the only needed text to me. > > > b) Please consider improving the example as above for 4.1.1: > > - lead in text for example > > - example title > > - [ [ objective, locator-option ] ] structure fix > > - Ideally also include both TLS and IPinIP options in example > > > Also: > > - I find the use of port 80 in the example highly confusing given how > > the TCP connection MUST use TLS. Please change to AB80 (anything but > > 80). > > okay. > > > So, your full example locators with objectives would be: > > > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]] ] > > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] ] > > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fe80::1234, 41, 0] ] > > > Is this join registrar supporting ANI TLS proxy ? > > Aka: i can't distinguish for the TCP locator whether it just indicates > > a permitted TCP port for the IPinIP proxy or whether it indicates > > the TCP port supported for IPinIP. And even if the proxy supports both, > > its not clear to me that the TCP ports for "native" would be the same as > > for IPinIP. Maybe its different code-paths == different ports. > > I'm sorry, I don't even understand the problem. > Maybe someone else can translate for me. Ok, i think was also confused yesterday, but thats all because of the bloody IPPROTO_IPV6 in 4.1.1. So, if i understand it correctly after a fresh coffee, we should completely eliminate IPPROTO_IPV6 from 4.1.1, but we still need it for 4.3: So, the Pledge would never need to know anything about IPinIP, it would always only see the same type of Proxy announcement for AN_Proxy with BRSKI-TLS, or in the future BRSKI with UDP for use with CoAP. the only distinguishable difference would be the LL address the proxy announces: So, this would be an example GRASP message from a circuit proxy. The LL address in the locator is typically its "own" native link-local address, ike the one from which it originates this DULL GRASP message: a) [M_FLOOD, 7234567, h'fe80::1', 180000, [ ["AN_Proxy", 4, 255 ], [O_IPv6_LOCATOR, fe80::1, 6, 443] ] ] Now instead, the proxy operates as an IPinIP proxy and the announcement might look like this: b) [M_FLOOD, 7234567, h'fe800::1', 180000, [ ["AN_Proxy", 4, 255 ], [O_IPv6_LOCATOR, fe80::1234, 41, 4443] ] ] For the Pledge, no difference in its own behavior. But: 4.1.1 says right now, that the port-number is allocated by the Proxy. And the same is actually true for the LL address in the locator. But: If the Proxy is operating as LL proxy, then it is not the proxy allocating the LL address and the port-number, but instead it is the Registrar, the Proxy is just taking the information from the registrar GRASP announcement and copies it into its b) announcement to the Pledge - and of course set up locally the appropriate state: listen to fe80::1234 and forward packets received for it including filtering for only TCP packets to port 4443. Which still begs the question how the Proxy learned about the registrar to be able to create both the b) announcement to the Pledge and its own state. 4.3 argues seemingly that IPinIP proxy would need to receive the following two locators to get this information: locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 4443] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] Locator3 would tell the eProxy that the registrar supports IPinIP, and locator1 tells the Proxy that the IPinIP registrar support TLS BRSKI over port 4443 across IPinIP. And i said that in the way BRSKI-14 is written, individual GRASP AN_Join_registrar objecties do not have a way to encode these two locators together into a single objective. And also that i think you can not simply announce these locators separately via two GRASP AN_Join_register objectives because that is not only bad style, but also ambiguous. A GASP objective with locator1 would by itself not allow for proxies to know whether it is meant to support curcit-proxy operations AND/OR IPinIP operations. And a Registrar might support both curcuit-proxy Pledges AND IPinIP pleges but not on the same TCP port, but potentially on different ports. So, threefore i concluded, that the AN_Join_registrar GRASP objective needs to have an encoding where all he necessary locators can be included in a way that it is unambiguously differentiated from an AN_Join_registrar announcement indicating support for circuit proxies. So, what i proposed was that the locator-option field indicates the primary locator for the supported proxy model. Aka: for "native" TCP/TLS or UDP, its the locators with proto 6 or 17. For IPinIP its proto 41. Then only the announcement for IPinIP will need to have one or more additional locators, which indicate the proxy method and ports supported inside of IPinIP. And the text proposed to encode those into the objective-value field of the GRASP objective: > [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, > [ ["AN_join_registrar", 4, 255 ], > [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 443] > ], > [ ["AN_join_registrar", 4, 255, > [[O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 4443], > [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001',17, 5683]] > ], > [O_IPv6_LOCATOR, fe80::1234, 41, 0] > ] > ] The first AN_join_registrar objective indicates this registrar supports circuit-proxies, aka: native TLS connections across the ACP on TCP port 443. The second AN_join objective indicates it support IPinIP. The two additional locators in this objective indicate that TCP/TLS on port 4443 is supported across IPinIP and the second one that probably CoAP/UDP is supported across port 5683 (i have seen no explanation in BRSKI-14 what/how UDP would be used, so i assume its for CoAP. Probably CoAP/dTLS/UDP ?). Does this explains it better ? Cheers Toerless > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Jun 1 12:43:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E59A12D886 for ; Fri, 1 Jun 2018 12:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6kXfjgm53XZ for ; Fri, 1 Jun 2018 12:43:09 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 1C12112D82F for ; Fri, 1 Jun 2018 12:43:09 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w51JcYSO027163; Fri, 1 Jun 2018 12:43:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=JGeBGCwl3sVjmorueq5mz/4I6+K5mhlk0Gi2HaR9gU4=; b=mRSEf2zwu8n8n0YBd01Q0FFuLV+lUfhEzzb1mTnpeHB1pfhAUyDsCW5eppybTRkha5sq Z3p/zplZAw9u6uafqG+AQuCDShwNr6EukNw0Bn8fhiBz610f/Pl6LTjRvD8yAiVSJP5p nV4AQgB9KdladKg9MFkUzSXdukFSiUPZmCmJMzLGPS432Gc1YN4yMX7up0MXl1BokGs9 qAyfrp6yco04vpiZiL94lj0iX2BOJvAltPF3z8/Bzum0nY/0y8WXqvOipydIyikRzL/B Hzj3u92jN4tSERskTHVHx3s83p04P6fFtIj3H7+kk4sN6zybuJUek7CatYnuwfc48kdi rw== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) by mx0a-00273201.pphosted.com with ESMTP id 2jbc3u01ht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Jun 2018 12:43:06 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4581.namprd05.prod.outlook.com (52.135.204.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.7; Fri, 1 Jun 2018 19:43:05 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c%2]) with mapi id 15.20.0820.010; Fri, 1 Jun 2018 19:43:05 +0000 From: Kent Watsen To: Michael Richardson , "anima@ietf.org" CC: Joe Clarke , Benoit Claise Thread-Topic: question about ietf-voucher.yang Thread-Index: AQHT+UwDSFyB1ibASUqPL6pbyRzGj6RLi90A Date: Fri, 1 Jun 2018 19:43:05 +0000 Message-ID: <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> References: <28209.1527818259@localhost> In-Reply-To: <28209.1527818259@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4581; 7:9/I6ZtivSpZHGVPTMElvF7Vdlo62dgW7KUdw49SuluF0o1SdPTbngU3vUFsUOIDEBzIFxDOP4sIPnea97vbtIDUo/+MCTXswZe832rKODFQGPUGkwXCyt/EhTDs3Rdm0H32XhzGBBo7ko8RWyAPNG1kG6sMfjYJ132DST/AKWzXobKFqZYnWeN/stOJ7bgTfjIDQF39m2Y4s35gfFhxXqcw3bKGeSomCvxxE+ANPPFJ63sENc/fqrrQSuVKMMYm3 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4581; x-ms-traffictypediagnostic: BYAPR05MB4581: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4581; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4581; x-forefront-prvs: 0690E5FF22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39380400002)(396003)(39860400002)(199004)(189003)(76176011)(14454004)(8676002)(486006)(8936002)(81166006)(81156014)(105586002)(229853002)(106356001)(316002)(110136005)(36756003)(305945005)(58126008)(6486002)(186003)(66066001)(7736002)(2501003)(6436002)(59450400001)(478600001)(6506007)(476003)(966005)(26005)(2616005)(11346002)(446003)(5660300001)(6306002)(4326008)(53936002)(5250100002)(99286004)(6512007)(6246003)(3280700002)(25786009)(3660700001)(82746002)(4001150100001)(86362001)(33656002)(102836004)(83716003)(6116002)(3846002)(97736004)(2900100001)(2906002)(68736007)(16799955002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4581; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: Aj4wM4mKArJF0PkNCDXzAXaTchkMPUEkrNcqW4avEhnKGrl68RtW4jHTccY7KueYTrBjlbsAZ2fR44sWsZpsaGJ8hv5agX4UBboBXx+Mi/SzstOaa0RKm41BKQwmWcvXAaaQ6yOoNTLN7eEkgbEH2ce6zl8ll0iffWOGHw2s0WIGDSE93yCVftmI+UhUQDqv spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <87D10E81A8086641AB458E8316838B6B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 890edc01-262d-4d11-ba18-08d5c7f7e4db X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 890edc01-262d-4d11-ba18-08d5c7f7e4db X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2018 19:43:05.2147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4581 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-01_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806010227 Archived-At: Subject: Re: [Anima] question about ietf-voucher.yang X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 19:43:12 -0000 W0NDLWluZyBKb2UgYW5kIEJlbm9pdCB3aG8gYXJlIGNsb3NlciB0byB0aGlzIHRoYW4gSSBhbV0N Cg0KDQpUaGUgb25seSBvZmZpY2lhbCBzb3VyY2UgaXMgdGhlIFJGQywgb24gd2hpY2ggZm9sa3Mg YXJlIGV4cGVjdGVkIHRvIHVzZSBhIG1vZHVsZSBleHRyYWN0aW9uIHRvb2wgWzFdLg0KDQpGb3Ig YSB3aGlsZSB0aGVyZSwgWWFuZ01vZGVscyBbMl0gaGFkIGEgZm9sbG93aW5nLCBidXQgaXQgZG9l c24ndCBzZWVtIHRvIGhhdmUgdGhlIGxhc3Qgdm91Y2hlciBtb2R1bGUgaW4gaXRzIERCLCBzbyBJ J20gZ3Vlc3NpbmcgaXRzIGBjcm9uYCBqb2IgaXMgc3R1Y2sgb3Igc29tZXRoaW5nLg0KDQpZYW5n Q2F0YWxvZyBpcyBhIG1vcmUgcmVjZW50IGVudHJhbnQuICBJdCBhY3R1YWxseSBkb2VzIGhhdmUg dGhlIGxhdGVzdCBtb2R1bGUgdmVyc2lvbiBpbiBpdHMgREIgWzNdLCBzbyB0aGVyZSBhcHBlYXJz IHRvIGJlIHNvbWUgb3RoZXIgaXNzdWUgY2F1c2luZyB0aGUgc3RhbGUgRGF0YVRyYWNrZXIgbGlu ay4NCg0KUmVnYXJkbGVzcyBob3cgdGhlIG1vZHVsZXMgYXJlIG9idGFpbmVkLCBJIGFsd2F5cyBm aW5kIG15c2VsZiBuZWVkaW5nIHRvIG1ha2UgbG9jYWwgY29waWVzIG9mIHRoZW0gdG8gc2F0aXNm eSB0b29saW5nLiAgSXMgeW91ciBpZGVhIHRvIHVzZSBgd2dldGAgaW4gdGhlIGRyYWZ0J3MgYnVp bGQgc2NyaXB0cyB0byBkbyBhIGp1c3QtaW4tdGltZSBmZXRjaD8NCg0KWzFdIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTIwI3NlY3Rpb24t My4xMQ0KWzJdIGh0dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzDQpbM10gaHR0cHM6Ly93d3cu eWFuZ2NhdGFsb2cub3JnL3lhbmctc2VhcmNoL21vZHVsZV9kZXRhaWxzLnBocD9tb2R1bGU9aWV0 Zi12b3VjaGVyDQoNCktlbnQNCg0KPT09PT0gb3JpZ2luYWwgbWVzc2FnZSA9PT09PQ0KDQpOb3cg dGhhdCBSRkM4MzY2IGlzIHB1Ymxpc2hlZCwgQlJTS0kgc2hvdWxkIGJlIGltcG9ydGluZyB0aGUg bW9kdWxlIGZyb20gYW4NCm9mZmljaWFsIHNvdXJjZSwgcmF0aGVyIHRoYW4gZnJvbSAuLi92b3Vj aGVyIGFzIEkgZG8gbm93IG9uIG15IGNvbXB1dGVyLg0KDQpBcyBmYXIgYXMgSSBjYW4gdW5kZXJz dGFuZCwgaW5jbHVkZXMgc2VlbSB0byBjb21lIGZyb20gdGhlIHB5YW5nIHNvdXJjZSB0cmVlLA0K aW4gbW9kdWxlcy9pZXRmLCBhbmQgaWYgeW91IHdhbnQgbmV3IG1vZHVsZXMsIHlvdSBoYXZlIHRv IGdldCBhIG5ldyBweWFuZywNCmFuZCBzbyB3ZSBzaG91bGQgc2VuZCBhIHB1bGwgcmVxdWVzdCBh Z2FpbnN0IHRoZSBweWFuZyBzb3VyY2UuDQoNCkhvd2V2ZXIsIHdlIGFsc28gaGF2ZSB0aGUgeWFu Z2NhdGFsb2cub3JnLCBhbmQgbWF5YmUgdGhlIG1ha2VmaWxlIGluDQpCUlNLSSBzaG91bGQgd2dl dCBzb21ldGhpbmcsIGJ1dCBJJ20gdW5jbGVhciB3aGF0IGV4YWN0bHkgSSBzaG91bGQgd2dldCEN Cg0KQWxzbywgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjODM2Ni8gaGFzIGEg bGluayBmb3I6DQogICAgICBZYW5nIGNhdGFsb2cgZW50cnkgZm9yIGlldGYtdm91Y2hlckAyMDE3 LTEwLTI1LnlhbmcNCnBvaW50aW5nIGF0IHRoZSBlbnRyeSBmb3IgMjAxNy0xMC0yNSwgd2hpbGUg dGhlIFJGQyBoYXMgMjAxOC0wNS0wOSwNCmFuZCBpbiBmYWN0LCB0aGVyZSBpcyBhbiBlbnRyeSBh dDoNCiAgaHR0cHM6Ly93d3cueWFuZ2NhdGFsb2cub3JnL3lhbmctc2VhcmNoL21vZHVsZV9kZXRh aWxzLnBocD9tb2R1bGU9aWV0Zi12b3VjaGVyQDIwMTgtMDUtMDkueWFuZw0KDQpJIGZlZWwgdGhh dCBJJ20gbWlzc2luZyBhIHBsYWNlIHRvIHdnZXQgdGhlIG1vZHVsZXMgZnJvbS4NCg0KPT09PQ0K DQpBbHNvLCBhIHJlbGF0ZWQgcXVlc3Rpb24gaXMgd2hldGhlciBpZXRmLWN3dC12b3VjaGVyLXJl cXVlc3QgdG8gaW5oZXJpdCBmcm9tIEJSU0tJJ3MNCmlldGYtdm91Y2hlci1yZXF1ZXN0LCBvciBm cm9tIGlldGYtdm91Y2hlci4uLiBJdCdzIG5vdCBjbGVhciB0byBtZSB0aGF0DQppdCdzIGEgMTAw JSBzdWJjbGFzcyB5ZXQuDQoNCi0tIA0KXSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhl IG9kZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaCBuZXR3b3JrcyBbIA0KXSAgIE1pY2hh ZWwgUmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzICAgICAgICB8IG5ldHdvcmsg YXJjaGl0ZWN0ICBbIA0KXSAgICAgbWNyQHNhbmRlbG1hbi5jYSAgaHR0cDovL3d3dy5zYW5kZWxt YW4uY2EvICAgICAgICB8ICAgcnVieSBvbiByYWlscyAgICBbIA0KCQ0KDQoNCg0KDQoNCg0KDQoN Cg== From nobody Fri Jun 1 14:46:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF4212DA54 for ; Fri, 1 Jun 2018 14:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpWKFcfjrqX9 for ; Fri, 1 Jun 2018 14:46:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B0C12DA4C for ; Fri, 1 Jun 2018 14:46:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CC51920093; Fri, 1 Jun 2018 17:59:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 156FB1C6; Fri, 1 Jun 2018 17:46:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 134FE1C5; Fri, 1 Jun 2018 17:46:16 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: "anima\@ietf.org" , Joe Clarke , Benoit Claise In-Reply-To: <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> References: <28209.1527818259@localhost> <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] question about ietf-voucher.yang X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 21:46:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: > Regardless how the modules are obtained, I always find myself needing > to make local copies of them to satisfy tooling. Is your idea to use > `wget` in the draft's build scripts to do a just-in-time fetch? yeah... just looking for some option to wget to grab if newer, but i see nothing that uses ETAG or something. I guess [ -f ietf-voucher@2017-12-11.yang ] || wget ... =20=20 would work. (but, obviously, with the correct version) For now, I've just commited the above file into BRSKI so that the travis-ci= works. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxG+pYCLcPvd0N1lAQIk8Af5AWuTwHDyWsCa2QLNxIfek0fz0Ic6bp5/ razObkIeb0PXNt5HKyIXcNa4/QMk8YDOvMNYe0zalh8eKIo6beIoIQ12RhoBJpO9 sBBqZsmK4+M9JmrCoOH3iLf/vhkG4TUbZOni57viDCdZ/gwfxxwq0Yw2KrIUI0RK wvuJQAb0j4VjKXcV7VWHKDYoG3M4H9e6K23z5ZkjQNaABF+Gn8ToteKlwRj2t0+m 4euEEpQGsv8n93S4JCrwefSfUC8rJeYARCGR/9LK+HPImtT/GpXyTMKtd9VllGQc /pT3ZWQaVgHySlkKmPjq7KryX0LQD7hJiFZFU19QK3RRFoofy59nIQ== =8VhV -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 1 14:54:54 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506AF12DA54; Fri, 1 Jun 2018 14:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1iYXf7Wy8Qi; Fri, 1 Jun 2018 14:54:48 -0700 (PDT) Received: from mail-pl0-x244.google.com (mail-pl0-x244.google.com [IPv6:2607:f8b0:400e:c01::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 742A512DA1C; Fri, 1 Jun 2018 14:54:48 -0700 (PDT) Received: by mail-pl0-x244.google.com with SMTP id z9-v6so12709507plk.11; Fri, 01 Jun 2018 14:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0hXLH1aQ3Q0KJ9EfEhphUchTqJ0NsLhIUMX0qSRjAv4=; b=YSwhEZsaUxcMv3VxOuHVMVawobNTZjBqU3KwdFSBgMkvlS9R0PtqM6bI4U9qXufxu5 6JB8uBVLfdIsFskDfhdBK/wbj4otI1BjEaXurKqXPIup0jQ0wTRo450l7YW7sVXsAmsP UiDNNHFtltBb5OOb6cz36IcLiKmNSl16YHcG6Yv4bhoQsNNfdxjxZK4IoTMoI/nLgUbP 1OH3NruDxMUKtZhJeh8FdHKomolsMb801hKt7NpEH/UajBWw0dnDtK76zJU4jUlVmerH 0HWqKHa1F26Wh1jNavPwMyFiD76Of2i7QOXT+MsCZIguK/u9oUVexhE6R93xyno4WxUb fssQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0hXLH1aQ3Q0KJ9EfEhphUchTqJ0NsLhIUMX0qSRjAv4=; b=ZjFny5T86Di1SeKXlq22MEx6ctvjtdePSfw/CD8hrsUi2cggUwQmWNeOQB6NB1ndKg 2YXL84gu8cCe9gQDaX6DHjbHykTdK+1qFnNePj0qlUdza0iHV9ytXjQGZekNOiaBXB+Z Y6Fx4KGpYRzkVQPnwv5+WimoJOGu+VU4bT//baBOl0qaQyHzGvDf44kjcshXlYKUuEni wMhRz9VZOXq0BvGAnz1S9eoxyQZGvb35uGEE34pIiyAQBvpLqupA560AlhBoW+C8sHz1 TxVtqyDyA5ea6HvGjBuzUuWBuEhzH+93WfKQWetLxTivC80qpdwL3V98j2Q2djFZ1OM/ uSOQ== X-Gm-Message-State: ALKqPwcu2EUMQzVQkk/XyJ03C+qlXTIMdWlnpNyar2HqYW5gOhLUYTBI RfOGDFA2i3LFF6TunoDUP4sdxg== X-Google-Smtp-Source: ADUXVKLk6BRyRJMuTLCp3pOdXM7Opf+iFOCXLTxcLx2snMVXt22Frba5VJKLzA1RBDG854lu0S7Ptg== X-Received: by 2002:a17:902:7c84:: with SMTP id y4-v6mr12914776pll.262.1527890087671; Fri, 01 Jun 2018 14:54:47 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id p12-v6sm55409786pgn.26.2018.06.01.14.54.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 14:54:46 -0700 (PDT) To: Toerless Eckert , Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Sat, 2 Jun 2018 09:54:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 21:54:52 -0000 Comments on three points in line: On 01/06/2018 18:23, Toerless Eckert wrote: > Ok, lets separate out the threads here. > > On Thu, May 31, 2018 at 03:35:31PM -0400, Michael Richardson wrote: >> >> Toerless Eckert wrote: >> > 1. The GRASP specification of 4.1.1 should only describe what is required >> > and valid for the standard of GRASP objective, which is the TCP proxy. >> >> > Appendix C proxy option is not full/formally worked out, thats why >> > its in an appendix. If the authors want to propose a formal GRASP >> >> It's not mandatory to implement, which is why it got pushed to the appendix. >> If it wasn't worked out, then it would be removed. > > Ok. *sigh*. I guess i didn't quite get that. So, if we want to make GRASP in BRSKI > fwork correctly for IPinIP instead of just making it sugestive, there are a bunch > of fixes necessary. Some of them where part of the shepherd review suggestion > you dismissed as bikeshed. You didn't like the idea of using objective-value strings > to identify the proxy method. But the fix i suggested also fixed other GRASP > details. > > Anyhow. let me just list what i think is necessary to fi up the GRASP so it works > for both TLS and IPinIP. > > let me know if/how i can best help to get this done,I'd be happy to write up a > diff if we can finally get through this. > > Proposed changes to 4.1.1: > > Note: This 4.1.1 text fixes are not complete wrt. to the IPinIP port > constraints you seem to want to have according to the 4.2 text. See below > for the 4.2 text discus, and if thats fine with you, then of course, we would > also need to incude the locator-options for permitted TCP/UDP ports of the IPinIP > proxy into the 4.1.1 AN_Proxy objective, because otherwise the Pledge wouldn't > know which TCP or UDP (address)/port numbers to use across the IPinIP proxy (i think). > > a) Insert after: > | A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. > | This announcement can be within the same message as the ACP > | announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. > > The optional IPinIP proxy as described in Appendix C requires > the following extension to the syntax of [GRASP]: > > transport-proto /= IPPROTO_IPINIP > IPPROTO_IPV6 = 41 ; [RFC2473] > > Figure xx: GRASP syntax extensions for BRSKI > > Note: Process wise we might need to declare BRSKI RFC to be an update to > GRASP RFC because of these two lines, but i would just wait until this gets > discussed with IANA and then suggest that we change instead GRASP before > it becomes RFC to: > > transport-proto = 0..255 I'm really reluctant to do that for the reason I gave yesterday (it allows rubbish values). I don't see why BRSKI can't just define the extra value that it needs. That doesn't really require an "Updates:" IMHO. I do want to revisit this later, very likely by adding an IANA registry, but I don't see the rush. > > Aka: that way we can define IPPROTO_IPV6 perfectly in BRSKI without > extending GRASP (IMHO). We can still later on expend it beyond 255 when we need to, > but thats not a BRSKI RFC problem then anymore. Yes, I think that's true in any case. Brian > > b) Change: > | The M_FLOOD is formatted as follows: > > To: > An example of M_FLOOD (without ACP) is as follows: > > (aka: "is formatted as" is not the correct lead in for an example). > > c) Fix up example picture: > > [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, > [ ["AN_Proxy", 4, 1 ], > [O_IPv6_LOCATOR, > h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]], > [ ["AN_Proxy", 4, 1 ], > [O_IPv6_LOCATOR, > h'fe800000000000000000000000000001', IPPROTO_IPV6, 0]] ] > > Figure 6b: AN_Proxy Example > > This is actually multiple fixes > - Better title for picture (match AN_Proxy with following > CDDL picture title and 'example') > - the objective-value is not used, so "" for objective-value > is not really correct IMHO, the field is just not encoded: > ["AN_Proxy", 4, 1, "" ] -> ["AN_Proxy", 4, 1 ] > - I think it helps a lot to understand how to announce > multiple proxy options, so i highly suggest to have the > above example include the TCP circuit proxy and IPinIP options. > - Whether or not you use one or two objective announcements, > you always need one more structure level around objective > and locator-option according to GRASP syntax, > aka: > changed: ["AN_Proxy", 4, 1 ], ... 4443] > to: [ ["AN_Proxy", 4, 1 ], ... 4443] ] Yes. I thought that had already been caught. > c) Fix syntax: > from: flood-message = [M_FLOOD, session-id, initiator, ttl, > +[objective, (locator-option / [])]] > > to: flood-message = [M_FLOOD, session-id, initiator, ttl, > +[objective, locator-option ]] > > Aka: for this objective, locator-option is not optional, > but mandatory, because it indicates the proxy-type via the > transport-type which is part of the locator-option. That isn't a fix to the GRASP syntax, it's a *restriction* of the syntax for this particular case. Which is fine, but just note it as a restriction. > > d) from: locator = [ O_IPv6_LOCATOR, ipv6-address, > to: locator-option = [ O_IPv6_LOCATOR, ipv6-address, > > textual consistency with prior use of locator-option and GRASP RFC. > > e) Add at end of 4.1.1 suggested text: > > The transport-proto of the locator-option indicates the mechanism(s) > supported by the proxy to the pledge. IPPROTO_TCP indicates the > mandatory ANI TLS circuit proxy. IPPROTO_IPV6 indicates the optional > IPinIP proxy, see Appendix C. IPPROTO_UDP would indicate a future > CoAP mechanism, see Section 4.2. For IPPROTO_IPV6, proto-number > MUST be 0. > > The above example shows a proxy supporting both ANI TLS circuit proxy > and IP in IP proxy. > > Notes: > > I hope i understand the IP in IP proxy correctly, but given that > there is no port number in IPinIP, and given that port-number is > mandatory in GRASP syntax in this case, 0 seems to be the logical > number to use for port-number in this case. > > I am just guessing you want IPPROTO_UDP to indicate CoAP in the > future. If so, then it would be prudent to notice this here, > otherwise describe what IPPROTO_UDP should mean, and if there is > no predefined meaning, just remove it from the CDDL syntax. > > f) If you do not fancy to include the IP in IP example and text in > 4.1.1, then i would strongly suggest to remove ALL indications of > IP in IP, including the mentioning of IPPROTO_IPv6 from 4.1.1 > (also the extension to the GRASP syntax) - and instead put that > all into appendix C. Your choice. I think the text is more succinct > if all the grasp stuff is clearly in 4.1.1. > > 2) Changes for 4.3 > > a) The objective-value "EST-TLS" serves no purpose and is wrong. > Please remove it from the syntax, ak: no objective-value, like > also no objective-value in 4.1.1 > - Its unnecessary, because if its used for all possible methods > (TLS, IPinIP, ..) then it doesn't provide additional information > and is redundant. > - It is wrong, because the protocol would not just be EST, but BRSKI. > - It is wrong, because for CoAP there would be no TLS. > > b) Please consider improving the example as above for 4.1.1: > - lead in text for example > - example title > - [ [ objective, locator-option ] ] structure fix > - Ideally also include both TLS and IPinIP options in example > > Also: > - I find the use of port 80 in the example highly confusing given how > the TCP connection MUST use TLS. Please change to AB80 (anything but 80). > > c) The CDDL syntax should be more consistent with 4.1.1: > - locator-option not optional > - locator, ipv6-address, transport-proto, port-number could > be included in syntax. > > d) "network administrator policy (EST server configuration)" > > You where making during ACP review the point that BRSKI Registrar (for enrollment) > would not necessarily be the same as the EST server for cert renewal, > therefore the mentioning of "EST server" is confusing. would be > less confusing if the term (BRSKI) Registrar was used everywhere, > and "EST server" only when there is a real reason. > > e) "A protocol of 41 indicates that packets may be IPIP proxy'ed" > > So, unless we get back to my shepherd review "bikeshed" of introducing > different objective value strings for different proxy methods, > the "transport-proto" is the only way for the proxy to identify the > method, so this sentence needs to say "will be" instead of "may be". > > Also: Delete following "In the case of that IPIP proxying is used, then". > > Also: "MUST be advertised on the" -> "MUST be advertised by the Proxy on the". > > f) the mechanism you are describing with locator1, locator2 and locator3 > would be highly obfuscated: > > In GRASP, every objective can have only one locator as seen from the syntax. > What you are proposing would mean that you are announcing three separate > AN_join_registrar objectives (of course, they can all be together in a single > M_Flood), but then effectively you're saying that those three objectives > do really describe a single IPinIP mechanism. > > So, your full example locators with objectives would be: > > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]] ] > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] ] > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fe80::1234, 41, 0] ] > > Is this join registrar supporting ANI TLS proxy ? > Aka: i can't distinguish for the TCP locator whether it just indicates > a permitted TCP port for the IPinIP proxy or whether it indicates > the TCP port supported for IPinIP. And even if the proxy supports both, > its not clear to me that the TCP ports for "native" would be the same as > for IPinIP. Maybe its different code-paths == different ports. > > Likewise UDP port could be CoAP proxy or again a parameter for IPinIP. > > I would suggest to only use a single objective for IPinIP, aka: the line with > 41, 0, and encode the TCP/UDP locators to use inside of the IPinIP proxy > mechanisms as the objective-value when using the IPinIPi method: > > objective-value = *( [ ipv6-locator-option ] ) ; only for IPinIP proxy > > Then we could show an example like this: > > [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, > [ ["AN_join_registrar", 4, 255 ], > [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 443] > ], > [ ["AN_join_registrar", 4, 255, > [[O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 4443], > [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001',17, 5683]] > ], > [O_IPv6_LOCATOR, fe80::1234, 41, 0] > ] > ] > > That would include your two constraining locators for the IPinIP proxy > and separately the "native" circuit proxy. And as mentioned in the > intro for 4.1.1, the same structure of information for the IPinIP proxy > would be necessary for AN_Proxy. > > > I'll stop here. Let me know what you think. I'll be happy to help apply the > fixes / send diff if this is ok. with you. > > Cheers > Toerless > >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works | network architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >> > > > >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Jun 1 15:13:09 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17A112DA6D; Fri, 1 Jun 2018 15:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqJbpqqODVft; Fri, 1 Jun 2018 15:13:04 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577E912DA6B; Fri, 1 Jun 2018 15:13:04 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5950258C506; Sat, 2 Jun 2018 00:13:00 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 47AC54401A4; Sat, 2 Jun 2018 00:13:00 +0200 (CEST) Date: Sat, 2 Jun 2018 00:13:00 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org Message-ID: <20180601221300.6adeojsaxouyt2no@faui48f.informatik.uni-erlangen.de> References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 22:13:07 -0000 On Sat, Jun 02, 2018 at 09:54:53AM +1200, Brian E Carpenter wrote: > > Note: Process wise we might need to declare BRSKI RFC to be an update to > > GRASP RFC because of these two lines, but i would just wait until this gets > > discussed with IANA and then suggest that we change instead GRASP before > > it becomes RFC to: > > > > transport-proto = 0..255 > > I'm really reluctant to do that for the reason I gave yesterday (it > allows rubbish values). Ok, but just permitting rubbish value does not mean anyone needs to use rubbish values. And the pro argument is that it gives you for free all the non-rubbish values that have been registered by IANA completely for free. The only thing this says is that if you want to allocate a new value thats not been registered by IANA and its ONLY needed for GRAASP locators and no other locators, then you can use e.g.: the range 256...1024, and we just need to find the right document to override the 0..255 sapce with 0..1024. > I don't see why BRSKI can't just define the extra > value that it needs. That doesn't really require an "Updates:" IMHO. Whats your logic for that conclusion ? My logic for thinking that it is an extension is that we're defining something which is not a subset of what GRASP did define. So for example even if i do define all possible crazy structures for "objective-value", i still define a subset, because GRASP defined it as "any". > I do want to revisit this later, very likely by adding an IANA registry, > but I don't see the rush. Right. > > Aka: that way we can define IPPROTO_IPV6 perfectly in BRSKI without > > extending GRASP (IMHO). We can still later on expend it beyond 255 when we need to, > > but thats not a BRSKI RFC problem then anymore. > > Yes, I think that's true in any case. [...] > > c) Fix syntax: > > from: flood-message = [M_FLOOD, session-id, initiator, ttl, > > +[objective, (locator-option / [])]] > > > > to: flood-message = [M_FLOOD, session-id, initiator, ttl, > > +[objective, locator-option ]] > > > > Aka: for this objective, locator-option is not optional, > > but mandatory, because it indicates the proxy-type via the > > transport-type which is part of the locator-option. > > That isn't a fix to the GRASP syntax, it's a *restriction* of the > syntax for this particular case. Which is fine, but just note it > as a restriction. Exactly. Of course not the only one. The whole syntax is full of restriction. "AN_Proxy" in the objective-name field is syntactically also a restriction. Cheers Toerless From nobody Fri Jun 1 16:15:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B5D12DB72; Fri, 1 Jun 2018 16:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x_Lyd8tdJU1; Fri, 1 Jun 2018 16:15:44 -0700 (PDT) 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 4FD0B12DB6C; Fri, 1 Jun 2018 16:15:44 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id v24-v6so16135826plo.3; Fri, 01 Jun 2018 16:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DqPGg4smy2/ORKbDHQj7ikFVPExeexrCFIwbgK4J65Q=; b=NmOQgkadK8ymHkvGFQhM8mGHoIPejemqRT/AhISggBYIPNqhefbEK8yLPVHnasQWxt BoaJWAqmItnOeKVq8iRaVFuCZT1f6n0khNV6hRqdnG9fZPvnuzz6Dn8oY+5jrH9wRbht r+HE8DykaW+nWcTcZQ7Pcm2Zxz2RPGLql8lO6s7VM4DbETbA1Mx26CSOyxf/lNUtESso KLk/jwYjQt69DxbcC7/O98E6egbcfQsa7YmexTVgD0nNmW6yLgIWSaKENws+xIOJrOBt 4z7WJ0txwdNNz3U11ohGOvue0MPP5gnqbx3mILcGPyFQw50rpEUscwSnjQYhTa2paEiH PPTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DqPGg4smy2/ORKbDHQj7ikFVPExeexrCFIwbgK4J65Q=; b=NXnrtVBnD4aesSNzaIwwuE1854Bgiv66bKoUhe1R8ASqtVSk1K6lYAuQACENeQkZM4 W9GBiueiim83FH9LjxBnnRcBoXHO1btQaiDG0bhiLbL5MEnnkScF2lgTsYYkmH4xMZTJ M6ANRSBEfFG8REETeDzGgwxWNAKVqT66v4O1kN73qKGBgW+23vtj2kL452Cg0rMG4I9W /J3Ug5SEIPkyN0yAhE6vymjAEtPp72cHTj6KyGm2+T9VgSP0u71HECBrBku9PFKr8cGB C8xssgWGiUU6SLqT9q4aPJX1ou9RdR1ukC9WXE1w0JkYJo5OVyFLkCGyKh9gDYfw+zQO Hr6w== X-Gm-Message-State: ALKqPwfvnFaa36/edz89suPcZ1ozJRQOKZnfnS/g4kqq5UbTgBVyxQta nbhh9EXkqjxnuwnpfa+VioXfEQ== X-Google-Smtp-Source: ADUXVKLAF4RSctK63hI4NmfOhx08do6xdrOo64snqHAzRt88up1aOMq5HD13ep503si4F2bI6mtCzA== X-Received: by 2002:a17:902:bd93:: with SMTP id q19-v6mr12711390pls.342.1527894943550; Fri, 01 Jun 2018 16:15:43 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id m23-v6sm21494540pgc.37.2018.06.01.16.15.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 16:15:42 -0700 (PDT) To: Toerless Eckert Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> <20180601221300.6adeojsaxouyt2no@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Sat, 2 Jun 2018 11:15:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180601221300.6adeojsaxouyt2no@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 23:15:47 -0000 On 02/06/2018 10:13, Toerless Eckert wrote: ... > I don't see why BRSKI can't just define the extra > value that it needs. That doesn't really require an "Updates:" IMHO. Whats your logic for that conclusion ? My logic for thinking that it is an extension is that we're defining something which is not a subset of what GRASP did define. Yes, it's an extension, but does a simple extension require "Updates:"? That is a question that is often asked and never definitively answered. I think the answer can be "no", because a GRASP implementer really shouldn't care about this. My GRASP code certainly doesn't; my toy BRSKI code does. Brian From nobody Fri Jun 1 16:17:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A00312DB72; Fri, 1 Jun 2018 16:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J0eE-R1gW20; Fri, 1 Jun 2018 16:17:34 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018E312DB6C; Fri, 1 Jun 2018 16:17:33 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id d2-v6so1264984pga.13; Fri, 01 Jun 2018 16:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=au8vuMJIxFWvKlO69ph6ZJrC9JURQ1LAUwjUmHNiYoM=; b=F+ruRKXL2VgXSZT5EcD/kD+zZvHC75dOzoo0NjD6Do8IFF6t4eEcjHbkM2MfMHLWSd OSlCzz6NY4pJLnZTydd5M9DcFRAPn2nX3z2c1i3lqJ9y5T4AnO7M/cTn+0UP5o2OGuYd FSeOG7dCWU6wY5zYtED6NUKdSFdQAPxRrw8Jez7BqHVz//D8t9brdVvsFmNpS3sbeylJ OwxJvJBPTJ39pQWBVeCP4M0cTZM8NAPjiZsFT2OPXG3SgNykk3/fmtGCL3akEHyjqBeP bVwY2vL4KdBMzu3+4223f9C16PQ/V+pBUaMf4aOc/3NnmGF/0iSHQ6uTe/YKQzqlqPRB nk6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=au8vuMJIxFWvKlO69ph6ZJrC9JURQ1LAUwjUmHNiYoM=; b=U54KKm/zxvby4pp/aHXTSH1D2k0PwUnLiRSsAyaOj5uGHHtUg3Fi8915CGfxBbnbJ8 BX/FuADl99YXulbanBJA8IPRh3GklhGRgkDYTl5sLzhHXZ9OboR/pFXMxicUNTDxK7bj x0jzble95QExqt7+H85pUt5DmshnwCJIduGbElSMIdxR++xG8WASaTqm/hhsTCoC5E/1 MI+NwQylraj/SC19oCSogkQoV2evGMcUBR04KL2woRseptjcgU0/BCJU9G9VDBugMRGk 8wnNTJZ9hvIQF0oMK/eV5dZT38C3LYBxx/aD+BL3tJGn2eOqLHTMjF3rS2pGKTK/scKK xR8w== X-Gm-Message-State: APt69E2Mu67eHnbVi6pWum8+oBYEAYvqECHA5Ec9EDEHMTfS2+6FEQdY dFYNZJElgv7j6j95dxCxMCYBog== X-Google-Smtp-Source: ADUXVKLRKAXjucSW1sqs0NSfevwDLdtN8KtleP4RSu0StbmTdugZl3TJVaG3bBNMcgNWhhTu4W7MqA== X-Received: by 2002:a63:7906:: with SMTP id u6-v6mr2014102pgc.284.1527895053099; Fri, 01 Jun 2018 16:17:33 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id k24-v6sm63078481pff.118.2018.06.01.16.17.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 16:17:32 -0700 (PDT) From: Brian E Carpenter To: Toerless Eckert Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> <20180601221300.6adeojsaxouyt2no@faui48f.informatik.uni-erlangen.de> Message-ID: <71874072-5397-856c-f985-90c9d8cdd38a@gmail.com> Date: Sat, 2 Jun 2018 11:17:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180601221300.6adeojsaxouyt2no@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 23:17:36 -0000 (Sorry, the quoting went wrong on the previous version of this message.) On 02/06/2018 10:13, Toerless Eckert wrote: ... >> I don't see why BRSKI can't just define the extra >> value that it needs. That doesn't really require an "Updates:" IMHO. > Whats your logic for that conclusion ? My logic for thinking that it is > an extension is that we're defining something which is not a subset of what > GRASP did define. Yes, it's an extension, but does a simple extension require "Updates:"? That is a question that is often asked and never definitively answered. I think the answer can be "no", because a GRASP implementer really shouldn't care about this. My GRASP code certainly doesn't; my toy BRSKI code does. Brian From nobody Sat Jun 2 08:53:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCD612D87B for ; Sat, 2 Jun 2018 08:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiwVaSWIRQ7P for ; Sat, 2 Jun 2018 08:53:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD14A12D877 for ; Sat, 2 Jun 2018 08:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2686; q=dns/txt; s=iport; t=1527954782; x=1529164382; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=pam/c6gw/SgneUoa9tgFKh7UuW93inDKoWp9tT+NLdI=; b=GcaRMVVXSV7t446okr7ijYyocsUzXyyvXoQu7VMFw2ptKJCrOltuDhNq 8dPr68t2WBsZ/6cVXqMUSw/r0RtLlHYk81cGkWXA49bA/zhXpV0u6yw4l kwoeJZYedwF8pvofoxWjBXu1wnGFp6g9GQEUtS1CAPV3xcMi8KiZVpnCm 8=; X-IronPort-AV: E=Sophos;i="5.49,470,1520899200"; d="scan'208";a="404747108" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2018 15:53:01 +0000 Received: from [10.118.87.87] (rtp-jclarke-nitro6.cisco.com [10.118.87.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w52FqwmQ003801; Sat, 2 Jun 2018 15:52:59 GMT To: Kent Watsen , Michael Richardson , "anima@ietf.org" Cc: Benoit Claise References: <28209.1527818259@localhost> <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA Organization: Cisco Message-ID: <60d2b926-129e-e0bd-1379-d1f709281468@cisco.com> Date: Sat, 2 Jun 2018 11:52:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] question about ietf-voucher.yang X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2018 15:53:06 -0000 On 6/1/18 15:43, Kent Watsen wrote: > [CC-ing Joe and Benoit who are closer to this than I am] > > > The only official source is the RFC, on which folks are expected to use a module extraction tool [1]. > > For a while there, YangModels [2] had a following, but it doesn't seem to have the last voucher module in its DB, so I'm guessing its `cron` job is stuck or something. > > YangCatalog is a more recent entrant. It actually does have the latest module version in its DB [3], so there appears to be some other issue causing the stale DataTracker link. > > Regardless how the modules are obtained, I always find myself needing to make local copies of them to satisfy tooling. Is your idea to use `wget` in the draft's build scripts to do a just-in-time fetch? > > [1] https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.11 > [2] https://github.com/YangModels > [3] https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-voucher Like you said, part of the Yang Catalog automation is to take the modules from RFCs (and drafts) and extract them to the YangModels GH repo. Unfortunately, there are some issues with that piece of the automation. We're in the process of getting support from ISOC to continue the development around Yang Catalog, so in near future, you should see YangModels more up to date. I think in the meantime, Benoit has been doing some point updates with extracted YANG modules. Joe > > Kent > > ===== original message ===== > > Now that RFC8366 is published, BRSKI should be importing the module from an > official source, rather than from ../voucher as I do now on my computer. > > As far as I can understand, includes seem to come from the pyang source tree, > in modules/ietf, and if you want new modules, you have to get a new pyang, > and so we should send a pull request against the pyang source. > > However, we also have the yangcatalog.org, and maybe the makefile in > BRSKI should wget something, but I'm unclear what exactly I should wget! > > Also, https://datatracker.ietf.org/doc/rfc8366/ has a link for: > Yang catalog entry for ietf-voucher@2017-10-25.yang > pointing at the entry for 2017-10-25, while the RFC has 2018-05-09, > and in fact, there is an entry at: > https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-voucher@2018-05-09.yang > > I feel that I'm missing a place to wget the modules from. > > ==== > > Also, a related question is whether ietf-cwt-voucher-request to inherit from BRSKI's > ietf-voucher-request, or from ietf-voucher... It's not clear to me that > it's a 100% subclass yet. > From nobody Sat Jun 2 15:43:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8558212D955 for ; Sat, 2 Jun 2018 15:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA-TYS8MYkY5 for ; Sat, 2 Jun 2018 15:42:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482C712D94D for ; Sat, 2 Jun 2018 15:42:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6454720093; Sat, 2 Jun 2018 18:56:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 69A96D36; Sat, 2 Jun 2018 18:42:23 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6736DB60; Sat, 2 Jun 2018 18:42:23 -0400 (EDT) From: Michael Richardson To: Joe Clarke , Kent Watsen cc: "anima\@ietf.org" , Benoit Claise In-Reply-To: <60d2b926-129e-e0bd-1379-d1f709281468@cisco.com> References: <28209.1527818259@localhost> <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> <60d2b926-129e-e0bd-1379-d1f709281468@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] question about ietf-voucher.yang X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2018 22:43:02 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > [2] https://github.com/YangModels okay, so at this point, my I think that pulls from YangModels github (directly, or wget'ing the rawusercontent file...) is the simplest. Kent, doeds 8366 replace: https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-= zerotouch-ownership-voucher.yang ?? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxMdTICLcPvd0N1lAQKvhQgAk2XLpnGup3W/Gf0JMasORoM8QW32kdjY 3uDKWuyxh97j1KilZC9LRtGCPh++e1CAfzxkkOwi2dWjNZQSHW3nbv80y7COZhCq rIj69IgQ3dTaX4GV05oI+sYwJbYqRF7pC14jl6k4yLMJSICz2BnfvA0fn5wVZ9JQ LtYUoGpfjM1S7aUCjwycOZtcpPhziIH4PmFwspIQDM562/+EmhUT2cpPRUEcbxHX LN9V7knJLOBDstAgNhmuIAeifrpZn8raIF0/rUu3rkEoCa6RPxz2Ep+ziTZ+nf6E Henm/TFBiguiXnt2yiyUL7MDjXdGfctQKKBgaySRwiO7HLNVpDu/LQ== =Uvx4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 2 21:24:18 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7B1201F8 for ; Sat, 2 Jun 2018 21:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 mVdSh7e0INOM for ; Sat, 2 Jun 2018 21:24:15 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C911243F3 for ; Sat, 2 Jun 2018 21:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2506; q=dns/txt; s=iport; t=1527999854; x=1529209454; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=B13KlOrDN2xUuM2jtPyX9Jy+i6GD2+QFU87XoEVbDC0=; b=dGqs8nAIm8nHXW2DYqRiKYKkJEhlQRymR3icJMVy3Y/wpZ4iQALls75B eKseJ7JIL0H66tkFQpRUHbjuNhvWGWk3ay6wwt/CYTJIei2cfu386lD/2 ANxF/U4fsZUcslzidgotxTP6oE3YE2Ne9vognrcnduSUoR3/WwXKMA/c9 Q=; X-IronPort-AV: E=Sophos;i="5.49,471,1520899200"; d="scan'208";a="4229590" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2018 04:24:13 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w534OCnW008332; Sun, 3 Jun 2018 04:24:12 GMT To: Kent Watsen , Michael Richardson , "anima@ietf.org" Cc: Joe Clarke , Benoit Claise References: <28209.1527818259@localhost> <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> From: Benoit Claise Message-ID: Date: Sun, 3 Jun 2018 06:24:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] question about ietf-voucher.yang X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 04:24:17 -0000 Hi, Yes, cron jobs inserted the YANG module (out of the RFC) in the yangcatalog. However, it's still a manual process to insert your YANG module (out of a fresh RFC) in https://github.com/YangModels/yang/tree/master/standard/ietf/RFC I'm (still) shooting for IANA to be the repository in the future. From there, it will be trivial. Regards, Benoit > [CC-ing Joe and Benoit who are closer to this than I am] > > > The only official source is the RFC, on which folks are expected to use a module extraction tool [1]. > > For a while there, YangModels [2] had a following, but it doesn't seem to have the last voucher module in its DB, so I'm guessing its `cron` job is stuck or something. > > YangCatalog is a more recent entrant. It actually does have the latest module version in its DB [3], so there appears to be some other issue causing the stale DataTracker link. > > Regardless how the modules are obtained, I always find myself needing to make local copies of them to satisfy tooling. Is your idea to use `wget` in the draft's build scripts to do a just-in-time fetch? > > [1] https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.11 > [2] https://github.com/YangModels > [3] https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-voucher > > Kent > > ===== original message ===== > > Now that RFC8366 is published, BRSKI should be importing the module from an > official source, rather than from ../voucher as I do now on my computer. > > As far as I can understand, includes seem to come from the pyang source tree, > in modules/ietf, and if you want new modules, you have to get a new pyang, > and so we should send a pull request against the pyang source. > > However, we also have the yangcatalog.org, and maybe the makefile in > BRSKI should wget something, but I'm unclear what exactly I should wget! > > Also, https://datatracker.ietf.org/doc/rfc8366/ has a link for: > Yang catalog entry for ietf-voucher@2017-10-25.yang > pointing at the entry for 2017-10-25, while the RFC has 2018-05-09, > and in fact, there is an entry at: > https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-voucher@2018-05-09.yang > > I feel that I'm missing a place to wget the modules from. > > ==== > > Also, a related question is whether ietf-cwt-voucher-request to inherit from BRSKI's > ietf-voucher-request, or from ietf-voucher... It's not clear to me that > it's a 100% subclass yet. > From nobody Sun Jun 3 07:15:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB585127078 for ; Sun, 3 Jun 2018 07:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 qcm4vQd1X_0Y for ; Sun, 3 Jun 2018 07:15:03 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6461F126CD8 for ; Sun, 3 Jun 2018 07:15:03 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id CB1B2181D397E; Sun, 3 Jun 2018 14:15:01 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1042:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2527:2528:2553:2561:2568:2627:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3352:3770:3865:3866:3867:3868:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4117:4250:4321:4605:4659:4860:5007:6117:6119:6261:6657:6659:6678:7875:7903:8603:8985:9010:9025:9040:9177:9388:10004:10400:10450:10455:10848:11232:11658:11914:12043:12291:12379:12438:12683:12740:12895:13139:13439:13846:13891:14093:14095:14181:14721:14822:14824:19904:19999:21080:21324:21433:21451:21627:21691:21740:30029:30041:30054:30060:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainC X-HE-Tag: sleet74_2bdd854c98117 X-Filterd-Recvd-Size: 6578 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf10.hostedemail.com (Postfix) with ESMTPA; Sun, 3 Jun 2018 14:15:01 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_bf981542f801c05d0cdfd2925c61c257" Date: Sun, 03 Jun 2018 16:15:00 +0200 From: Peter van der Stok To: "Max Pritikin (pritikin)" Cc: Michael Richardson , anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <28209.1527818259@localhost> <22706.1527865857@localhost> Message-ID: <7b1c3d88420b5cc738c8e384d30d7758@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.135.186] Archived-At: Subject: Re: [Anima] naming of constrained voucher YANG model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 14:15:06 -0000 --=_bf981542f801c05d0cdfd2925c61c257 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII constrained-voucher(-request) seems reasonable to me Peter Max Pritikin (pritikin) schreef op 2018-06-01 17:29: > what is wrong with going simple: "constrained voucher request" ? > > - max > > On Jun 1, 2018, at 9:10 AM, Michael Richardson wrote: > > Michael Richardson wrote: Also, a related question is whether ietf-cwt-voucher-request to inherit > from BRSKI's ietf-voucher-request, or from ietf-voucher... It's not > clear to me that it's a 100% subclass yet. > So, the name started at "cwt-voucher-request", because it was originally > thought that it would use CWT directly (RFC8392), using the Claim keys from > there. > > Then after some distraction, the process is now a COSE signed SID generated > YANG, which isn't exactly CWT at all. > > The name "cwt-voucher"{,-request} is no longer appropriate. > Some constraction of "constrained" is probably now appropriate, looking for > suggestions. > > It's also reasonable to say that we use CWT concepts when they map, and > introduce new key ids via the YANG/SID mechanism. That's a significant > design change, but it's not that huge. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima --=_bf981542f801c05d0cdfd2925c61c257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 constrained-voucher(-request) seems reasonable to me

Peter

Max Pritikin (pritikin) schreef op 2018-06-01 17:29:

= what is wrong with going simple: "constrained voucher request" ?

- max

On Jun 1, 2018, at 9:10 AM, Michael Richardson <mcr+ietf@sandelman.ca<= /a>> wrote:


Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Also, a related question is whether ietf-cwt-voucher-r= equest to inherit
from BRSKI's ietf-voucher-request, or from ietf-vou= cher... It's not
clear to me that it's a 100% subclass yet.
So, the name started at "cwt-voucher-request", because it was origin= ally
thought that it would use CWT directly (RFC8392), using the Clai= m keys from
there.

Then after some distraction, the proce= ss is now a COSE signed SID generated
YANG, which isn't exactly CWT a= t all.

The name "cwt-voucher"{,-request} is no longer appropria= te.
Some constraction of "constrained" is probably now appropriate, l= ooking for
suggestions.  

It's also reasonable to sa= y that we use CWT concepts when they map, and
introduce new key ids v= ia the YANG/SID mechanism.  That's a significant
design change, = but it's not that huge.

-- 
] &nb= sp;            =  Never tell me the odds!        &nb= sp;        | ipv6 mesh networks [ <= br /> ]   Michael Richardson, Sandelman Software Works  &nbs= p;     | network architect  [
> ] &= nbsp;   mcr@sandelman.ca  http://www.sandelman.ca/   &nb= sp;    |   ruby on rails    [ =

_______________________________________________
Anima ma= iling list
Anima@= ietf.org
https://www.ietf.org/mailman/listinfo/a= nima

_______________________________________________
Anima mailing = list
Anima@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/ani= ma
--=_bf981542f801c05d0cdfd2925c61c257-- From nobody Mon Jun 4 18:55:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5738127076 for ; Mon, 4 Jun 2018 07:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wJxEuG-SJst for ; Mon, 4 Jun 2018 07:11:19 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 4A7E2127058 for ; Mon, 4 Jun 2018 07:11:19 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w54E4Y4X006228 for ; Mon, 4 Jun 2018 07:11:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=+vNT3oXcr2RkNFrVY6j0LFJ6tHBIrtFOikip1lHOxTg=; b=IZqdK28XXybCaCIC72gKPGLBNfJmi+AkPimo+a7ZsiqcTtAzkrZTP9tELkQOCNmlJ6cf ETk23O4ajdCIL5u8lHi86k5TC4UNe4kJXNSCY+auccDSibvUE0g2lFSKYmYd/zmS2Wut vNaRzzapWhEVcQMoVM93A3NXfEavbLHDv1Qm9G9em6mjtq58Xww0aCPhxYm4hwwu+d56 xt9CvIznqEguUnalBwd/pZWEVXGI9tGbaZt+bg37Tv6vzyEFBgv1j/msSs0RhFZSC1p+ z9+GAGq1pkOTKG9avXUqRsXOqKRHv/I3tCuJ/dSSTZr1yspnJkU0GNJjppHpxLOAG9lx Tg== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0048.outbound.protection.outlook.com [216.32.180.48]) by mx0a-00273201.pphosted.com with ESMTP id 2jd3610fub-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 04 Jun 2018 07:11:18 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4184.namprd05.prod.outlook.com (52.135.200.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.11; Mon, 4 Jun 2018 14:11:17 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c%2]) with mapi id 15.20.0841.011; Mon, 4 Jun 2018 14:11:17 +0000 From: Kent Watsen To: Michael Richardson , Joe Clarke CC: Benoit Claise Thread-Topic: question about ietf-voucher.yang Thread-Index: AQHT+UwDSFyB1ibASUqPL6pbyRzGj6RLi90AgAGVGACAAHJkgIACUtUA Date: Mon, 4 Jun 2018 14:11:16 +0000 Message-ID: <80CECD15-F61D-4406-B539-D0D6AC18B0C0@juniper.net> References: <28209.1527818259@localhost> <83B707C8-D1A4-4040-B64E-B0C92D835BB6@juniper.net> <60d2b926-129e-e0bd-1379-d1f709281468@cisco.com> <12598.1527979343@localhost> In-Reply-To: <12598.1527979343@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4184; 7:8n8rGpR9hwZXz6vI2o8o0Fk+mktJ5lXC28ZAoJA/48dm/U583ckLKbStTRgZ7JcKjUDldAHOE1xPL5Gfyav9Qa5xEDJnl7LSgp2qhQYKSpazXVYu/E3pmAywb+yvMjxQuNiZ8Sw8QUOYi8SvaYqlp6n2GRUXFR/ZVaHyNBDMOsbSm/LeDtzNnKvQbzgDTkVdt0tme+OVuEbPOclAqGM/H9fVv0rPjUCkYnNUpPCel30uNAcXhWVOfTt4mdvZahqr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4184; x-ms-traffictypediagnostic: BYAPR05MB4184: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(788757137089); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4184; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4184; x-forefront-prvs: 069373DFB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39380400002)(346002)(39860400002)(376002)(51444003)(199004)(189003)(316002)(2900100001)(53936002)(11346002)(446003)(36756003)(59450400001)(76176011)(6506007)(6246003)(476003)(2616005)(102836004)(186003)(25786009)(486006)(5660300001)(6436002)(6512007)(229853002)(6306002)(93886005)(26005)(82746002)(6486002)(83716003)(86362001)(5250100002)(58126008)(110136005)(81156014)(81166006)(305945005)(68736007)(105586002)(106356001)(8936002)(3280700002)(3660700001)(2906002)(14454004)(8676002)(7736002)(966005)(66066001)(99286004)(6116002)(3846002)(97736004)(33656002)(478600001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4184; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2La+01rC+2tfVUgR/j3eKlZuU9gMPFAeXApvS8BZ5WQzlCaH2COFLt9Zga1e+D9d9kzuuyzy+2rJgnkcr4UdbNP9EJHmym7a9mn9qv9qNtcT6Wu0l189ibsD4JVxMUzIRQhthzWJVpgNJEE7b+BUxce+nhfoxXDL1U1EVfElFcZuBvotURQKk8DVMLuC3dkz spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <43125212DBBEA449A961B3F38245EF69@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8d5f69c4-a0ed-444a-23a8-08d5ca2509e3 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 8d5f69c4-a0ed-444a-23a8-08d5ca2509e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2018 14:11:17.0424 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4184 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-04_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=957 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806040167 Archived-At: X-Mailman-Approved-At: Mon, 04 Jun 2018 18:55:50 -0700 Subject: Re: [Anima] question about ietf-voucher.yang X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 14:11:21 -0000 W21vdmluZyBhbmltYSBsaXN0IHRvIEJDQ10NCg0KDQo+PiBbMl0gaHR0cHM6Ly9naXRodWIuY29t L1lhbmdNb2RlbHMNCj4NCj4gb2theSwgc28gYXQgdGhpcyBwb2ludCwgbXkgSSB0aGluayB0aGF0 IHB1bGxzIGZyb20gWWFuZ01vZGVscyBnaXRodWINCj4gKGRpcmVjdGx5LCBvciB3Z2V0J2luZyB0 aGUgcmF3dXNlcmNvbnRlbnQgZmlsZS4uLikgaXMgdGhlIHNpbXBsZXN0Lg0KDQpzZWVtcyBzZW5z aWJsZS4NCg0KDQo+IEtlbnQsIGRvZWRzIDgzNjYgcmVwbGFjZToNCj4gICBodHRwczovL2dpdGh1 Yi5jb20vWWFuZ01vZGVscy95YW5nL2Jsb2IvbWFzdGVyL3N0YW5kYXJkL2lldGYvRFJBRlRcDQo+ ICAgL2lldGYtemVyb3RvdWNoLW93bmVyc2hpcC12b3VjaGVyLnlhbmcNCj4gPz8NCg0KWWVzLiAg VGhhdCBtb2R1bGUgaXMgYSBzdGFsZSBob2xkb3ZlciBmcm9tIGJhY2sgYmVmb3JlIHdoZW4gd2Ug bW92ZWQgdGhlIHZvdWNoZXIgbW9kdWxlIGludG8gaXRzIG93biBkcmFmdCwgYW5kIG1vdmVkIHRo YXQgZHJhZnQgdG8gdGhlIEFOSU1BIFdHLg0KDQpKb2UvQmVub2l0LCBtYXliZSB0aGUgc2NyaXB0 cyBjb3VsZCBzb21laG93IHRyYWNrIG1vZHVsZXMgZXh0cmFjdGVkIGZyb20gSS1EcyAobm90IFJG Q3MpIHRvIHNlZSB3aGVuIG9sZCBtb2R1bGVzIGdvIGF3YXksIGFuZCB0aGVuIGRlbGV0ZSB0aG9z ZSBvbGQgbW9kdWxlcz8gICANCg0KQ29uc2lkZXIgdGhpcyBoaXN0b3J5Og0KICB6ZXJvdG91Y2gt MDggKEFwcmlsIDIwMTYpIGlzIHRoZSBsYXN0IGRyYWZ0IHRvIGRlZmluZSBpZXRmLXplcm90b3Vj aC1vd25lcnNoaXAtdm91Y2hlcg0KICB6ZXJvdG91Y2gtMDkgKEp1bHkgMjAxNikgcmVuYW1lZCB0 aGUgbW9kdWxlIHRvICJleGFtcGxlLXplcm90b3VjaC1vd25lcnNoaXAtdm91Y2hlciINCiAgemVy b3RvdWNoLTEwIChPY3RvYmVyIDIwMTYpIG5vIGxvbmdlciBoYWQgdGhlIG1vZHVsZSBhdCBhbGwN CiAgZHJhZnQta3dhdHNlbi1uZXRjb25mLXZvdWNoZXItMDAgKE9jdG9iZXIgMjAxNikgaXMgd2hl biAiaWV0Zi12b3VjaGVyIiBiZWdhbg0KICBkcmFmdC1rd2F0c2VuLWFuaW1hLXZvdWNoZXItMDAg KERlY2VtYmVyIDIwMTYpIHJlcGxhY2VkIGRyYWZ0LWt3YXRzZW4tbmV0Y29uZi12b3VjaGVyDQog IGRyYWZ0LWlldGYtYW5pbWEtdm91Y2hlci0wMCAoSmFudWFyeSAyMDE3KSByZXBsYWNlZCBkcmFm dC1rd2F0c2VuLWFuaW1hLXZvdWNoZXINCiAgUkZDIDgzNjYgKE1heSAyMDE4KSByZXBsYWNlZCBk cmFmdC1pZXRmLWFuaW1hLXZvdWNoZXINCg0KS2VudA0KDQoNCg== From nobody Tue Jun 5 10:59:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1522E128CF3 for ; Tue, 5 Jun 2018 10:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9NYN4HI-9db for ; Tue, 5 Jun 2018 10:59:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF731310F3 for ; Tue, 5 Jun 2018 10:59:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BB7620091; Tue, 5 Jun 2018 14:12:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D17202F8F; Tue, 5 Jun 2018 13:58:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CEAB22F86; Tue, 5 Jun 2018 13:58:25 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: consultancy@vanderstok.org, Toerless Eckert , "Max Pritikin \(pritikin\)" In-Reply-To: <20180604175201.6lo2exqsy4wi6koc@faui48f.informatik.uni-erlangen.de> References: <28209.1527818259@localhost> <22706.1527865857@localhost> <7b1c3d88420b5cc738c8e384d30d7758@bbhmail.nl> <20180604175201.6lo2exqsy4wi6koc@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] naming of constrained voucher YANG model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 17:59:04 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > I've always found reverse order naming better for browsing hierarchic= ally > related items. Not sure if there is any current common practice about > this in Yang models. Probably not... I've renamed it to ietf-constrained-voucher{,-request} a day or so ago. I hear your suggestion for ietf-voucher-constrained{,-request}, and unless there is a groundswell against that, another rename will occur. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxbPP4CLcPvd0N1lAQIUzAgAmA6flMHChJbjzBo0nN7XMZOyaILxAup/ jsLwpWpyMcLvSUCPSh96icL9Q8Tj8BGnyxJOSvzdHTi+yqEY/q6ErZh+IcCHuNi7 24Y2JhurPwiNTKaja46dGh+ywyyDZYIClOGgyxIXujWyD+1P5CjQxCjgj6fKL+rf FGveCFps+azMWh+o3llh7jyBWNXuPn6OnPn41Qp9sGSQboOE7JLSbjWaFyJWDLmy 9xsMgHJ/v2Z8MFQKCHEhHktbGggsSd8FtE/XK0UiCwMWjzEkXo3ClS0/2FMdT0hE 7w2nDRb01wMUX44DaKXnfCooIb7gYi3JHAUtD1hLV1zbyUi1vAdq2Q== =Hw/m -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 5 12:29:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9063E131145 for ; Tue, 5 Jun 2018 12:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 ezGekHFSRoVq for ; Tue, 5 Jun 2018 12:29:51 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB4713113F for ; Tue, 5 Jun 2018 12:29:50 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 54F1C58C4D8; Tue, 5 Jun 2018 21:29:46 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 51E954401A4; Tue, 5 Jun 2018 21:29:46 +0200 (CEST) Date: Tue, 5 Jun 2018 21:29:46 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, consultancy@vanderstok.org, "Max Pritikin (pritikin)" Message-ID: <20180605192946.n3oyjmntnm5ryg76@faui48f.informatik.uni-erlangen.de> References: <28209.1527818259@localhost> <22706.1527865857@localhost> <7b1c3d88420b5cc738c8e384d30d7758@bbhmail.nl> <20180604175201.6lo2exqsy4wi6koc@faui48f.informatik.uni-erlangen.de> <7878.1528221505@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7878.1528221505@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] naming of constrained voucher YANG model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 19:29:54 -0000 Thanks, Richardson, Michael. Just remembered we had early yang docotr review, so posted question of best current practices for naming on that thread. Cheers Toerless On Tue, Jun 05, 2018 at 01:58:25PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > I've always found reverse order naming better for browsing hierarchically > > related items. Not sure if there is any current common practice about > > this in Yang models. Probably not... > > I've renamed it to ietf-constrained-voucher{,-request} a day or so ago. > > I hear your suggestion for ietf-voucher-constrained{,-request}, and > unless there is a groundswell against that, another rename will occur. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > -- --- tte@cs.fau.de From nobody Wed Jun 6 10:35:54 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2553E12777C; Wed, 6 Jun 2018 10:35:48 -0700 (PDT) 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-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152830654814.6366.4951842776897034198.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 10:35:48 -0700 Archived-At: Subject: [Anima] Warren Kumari's Discuss on draft-ietf-anima-autonomic-control-plane-13: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 17:35:49 -0000 Warren Kumari has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm balloting DISCUSS, but I think that this should be relatively simple to address: The document says things like:"Today, the management and control plane of networks typically runs in the global routing table, which is dependent on correct configuration and routing." and "Context separation improves security, because the ACP is not reachable from the global routing table. " The term "global routing table" is widely used and understood to mean the global BGP routing table, or Internet global routing table. I understand that you are using it in the "default VRF" meaning, but I think that it is really important to clarify / disambiguate this the first time you use it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you very much for writing this document -- it is comprehensive... A rich text version of my review is here: https://mozphab-ietf.devsvcdev.mozaws.net/D3801#inline-4146 , and pasted below for tooling, email, etc. --- draft-ietf-anima-autonomic-control-plane.txt:212 network nodes that is not the ACP, and therefore considered to be dependent on (mis-)configuration. This data-plen includes both the traditional forwarding-plane, as well as any pre-existing control- Nit: data-plane draft-ietf-anima-autonomic-control-plane.txt:508 certificate. This does not require any configuration on intermediate nodes, because they can communicate zero-touch and securely through the ACP. I understand what you are trying to say, but "zero-touch" is not an adverb. draft-ietf-anima-autonomic-control-plane.txt:518 the data-plane is operational, will the other planes work as expected. This is *sometimes* an undesirable dependency, but is usually viewed as a feature (by operational people) -- having the control plane share fate with the dataplane is something that is usually a feature - this drives at least part of the reason that many organizations run OSPF and OSPFv3 - having V4 OSPF relying on v4 dataplane avoids blackholes if the v4 dataplane stops working. (This is sometimes, but less often used as an argument against ISIS). I understand why it is useful in this context, but it would be useful to clarify/make it clear that you understand the subtleties. Also, nit: "is operational, will the" -- the comma feel weird here. draft-ietf-anima-autonomic-control-plane.txt:526 management session is running can lock an admin irreversibly out of the device. Traditionally only console access can help recover from such issues. "only console access or OOB". You may be using "console access" to mean OOB, but much (most?) OOB is now not console based. draft-ietf-anima-autonomic-control-plane.txt:531 Operations Center") such as SDN controller applications: Certain network changes are today hard to operate, because the change itself may affect reachability of the devices. Examples are address or mask I think that this was an editing issue -- you don't "operate" changes. Perhaps "implement"? draft-ietf-anima-autonomic-control-plane.txt:858 o If the node certificates indicate a CDP (or OCSP) then the peer's certificate must be valid according to those criteria. e.g.: OCSP You expand CDP further in the document, but this is the first time it is used. draft-ietf-anima-autonomic-control-plane.txt:994 ACP neighbors. Native interfaces (e.g.: physical interfaces on physical nodes) SHOULD be brought up automatically enough so that ACP discovery can be performed and any native interfaces with ACP I don't have a suggestion, but "automatically enough" doesn't sound right - "automatically configured enough" ? draft-ietf-anima-autonomic-control-plane.txt:1067 In the above (recommended) example the period of sending of the objective could be 60 seconds the indicated ttl of 180000 msec means that the objective would be cached by ACP nodes even when two out of Editing fail -- missing some punctuation or words. draft-ietf-anima-autonomic-control-plane.txt:1933 for reachability. The use of the autonomic control plane specific context eliminates the probable clash with the global routing table and also secures the ACP from interference from the configuration IMPORTANT: The term "global routing table" has a well known meaning in operations -- it is the global BGP table. I strongly suggest using a different term, or having a very clear statement in the terminology section, AND the first time you use it in the document. This will help minimize confusion. draft-ietf-anima-autonomic-control-plane.txt:3081 10.2. ACP (and BRSKI) Diagnostics Just a note that I like / appreciate this section - having guidance on how to troubleshoot is very helpful. draft-ietf-anima-autonomic-control-plane.txt:3416 10.3.2.2. Fast state propagation and Diagnostics "Physical down" state propagates on many interface types (e.g.: When I saw the "physically brought down" I started composing a long soapbox rant on the fact that this will slow down state propagation -- I like that that document anticipates and addresses this. It might be useful to have a pointer in the previous section (like "(see below)" or similar.) draft-ietf-anima-autonomic-control-plane.txt:3482 for 5 seconds to probe if there is an ACP neighbor on the remote end every 500 seconds = 1% power consumption. I believe that this is sufficiently incorrect that you should remove the 1% result (or, better yet the whole last sentence). Various interfaces (especially long reach) take a significant amount of time (and additional power) when bringing up interfaces -- things like DWDM optics and amplifiers sometimes need significant power for heating elements to lock the frequency / wavelength, and so the power consumption is not linear with interface uptime. From nobody Wed Jun 6 13:37:12 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74579130F94; Wed, 6 Jun 2018 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 QL_ztJ7bQ5UK; Wed, 6 Jun 2018 13:37:05 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791B6130FDA; Wed, 6 Jun 2018 13:37:05 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 53D3058C4C4; Wed, 6 Jun 2018 22:37:00 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 479EE4401A4; Wed, 6 Jun 2018 22:37:00 +0200 (CEST) Date: Wed, 6 Jun 2018 22:37:00 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org Message-ID: <20180606203700.bewampnxs2vaevke@faui48f.informatik.uni-erlangen.de> References: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> <6c4f9527-1b96-9c14-ffe0-186a24eb9793@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c4f9527-1b96-9c14-ffe0-186a24eb9793@joelhalpern.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 20:37:11 -0000 On Mon, May 14, 2018 at 11:15:58PM -0400, Joel M. Halpern wrote: > (Sorry about the excess caps. Did not intentd to shout.) > > From some off-line disucssions, I understand that the actual address > allocation is tied to the registration process. The registration process is > not described in this document. > > As far as I can tell, the ACP does not depend upon the address allocation > strategy. The address allocation strategy does require the ACP. And it > requires and is closely coupled to the registration process. > > If that is true, the address allocation seems to be better described with > the registration process. Which I presume is in the BRSKI document. > > All I would put in here is the basic ULA allocation (hash based generation) > mechanism. Hi Joel (round 3) Here is the github version after the fixes discussed below https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt Here is the diff vs. the prior version (round 2) http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt Alas (but i think for the better), after all the questions from and discussion with you, i tried to figure out how to best document the answers to the questions you raised, and it started answering why we need multiple address range - because have to waste 48/46 bits on Registrar-IDs. Ok, Why ? Because we want multiple uncoordinated registrars. Ok, what is a registrar. Especially when ACP does not use BRSKI, which it claims it can. And how does certificate maintenance work when you have multiple registrars. Aka: once i started to write text to asnwer your questions i kinda got sucked into having the spec also answer other questions. So, with this rev., we now define and use the term "ACP Registrar", and define that thats a BRSKI Registrar in ANI nodes, but it can be anything in non-ANI ACP nodes. Does not have to be software. It could be you, if you want the job. Maybe Netconf or other protocols that want to compete with BRSKI. Actually, verified i can be a registrar a long time ago, using old crypto PKI CLI on ACP capable routers to manually hack in certificates with specific properties i wanted. And getting them via web interface from a CA. So, i think this is a very clean solution of documentation. The normative part of the spec now has what i think was the minimum to define the requirements for any ACP registrar including the most simple address allocation example. So, then there is an informative section explaining the need for the multiple address spaces because of those uncoordinated registrars. And an informative section about how you would need to set up such uncoordinated registrars, aka: each with their own sub-CA. All in section 10.3 now. Then of course the whole point you made about about ACP addresses being identifiers or not. So i wanted to document the point that they are, but that also meant to explain how the ACP address information will survive in the presence of renewal and re-enrollment with a different registrar (which may not know the nodes assigned ACP address unless its presented during re-enrollment/renewal). Then of course the case where a cert is revoked maybe indirectly, because the registrar was attacked, not the ACP node gets a new cert from another registrar but of course this is is the only case where you want it to get a certificate with new ACP address information (because the prior registrar became untrusted so you don't trust what ACP information it assigned). So, this ended up being two new normative subsections in 6.1.3 - re-enrollment and failing certificates, describing the requirements against ACP nodes during renewal or failure of their cert. The informative part of the doc also got a section about registrars documenting hopefully the key pieces: how it works in general (so folks get an idea how they would be built with or without BRSKI), what parameters they need, discussion about that multi-registrar renewal and sub-CA case, and finally a discussion about how registrars could integrate with centralized policy control. After all, the world is SDN, so if we'd only document the cool distributed registrar case, this wouldn't sell well in todays world *sigh*. The reasoning for this new text sections is all summarized/documented in the changelog for -14. I'd like to point out that even though this is a bunch of additional text, it is in no way changing the way the ACP or registrars are meant to operate. It is really just adding missing documentation about it. Hope this answers your questions and resolves your discuss. Cheers Toerless From nobody Wed Jun 6 13:44:11 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF6130F94; Wed, 6 Jun 2018 13:44:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152831784059.6224.14562891698766099916@ietfa.amsl.com> Date: Wed, 06 Jun 2018 13:44:00 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-14.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 20:44:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach 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-14.txt Pages : 130 Date : 2018-06-06 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-14 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 6 14:33:14 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF73130FB4; Wed, 6 Jun 2018 14:33:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152832078536.6116.12559457390047298236@ietfa.amsl.com> Date: Wed, 06 Jun 2018 14:33:05 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-15.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 21:33:06 -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-15.txt Pages : 132 Date : 2018-06-06 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-15 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 6 14:51:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2881130DE5; Wed, 6 Jun 2018 14:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 u5OjoRejIrr0; Wed, 6 Jun 2018 14:51:17 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE40B130DDC; Wed, 6 Jun 2018 14:51:17 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EE9EE58C4C4; Wed, 6 Jun 2018 23:51:12 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E2FB04401A4; Wed, 6 Jun 2018 23:51:12 +0200 (CEST) Date: Wed, 6 Jun 2018 23:51:12 +0200 From: Toerless Eckert To: anima@ietf.org Cc: draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180606215112.h7c36vpkwptfyoub@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Uploaded: draft-ietf-anima-autonomic-control-plane-14/15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 21:51:23 -0000 draft-ietf-anima-autonomic-control-plane-14 Includes the reply to the reviews (in no particular order) by Joel Halpern, Pascal Thubert, Elwyn Davies and notes from Brian Carpenter and Benjamin Kaduk. discuss replies where provided in prior emails. Thanks a lot to all reviewers and commenters. There is a lot of minor improvements. The mayor change are a couple of new sections of explanatory normative and informative text related to the last round of reviews from Joel Halpern. The text is defining and explaining ACP Registrar behavior, and its related ACP address allocation and ACP certificate maintenance. None of the new text does IMHO really introduce new functionality, it just documents what we discussed, and assumed all along (IMHO)... but never documented *sigh*. See the last email reply to Joel Halpern and/or the changelog summarizing the logic of introducing this text. If you're just interrested in browsing the new sections (as opposed to all the minor changes too), use the diff i provided: http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/57825aac69216fd01d388810ee804c7f25e8ab7d/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt (a few diffs in reply to Elwin also leaked in, sory, forgot to commit at the right time). ----- draft-ietf-anima-autonomic-control-plane-15 increases TOC depth to 4 and reshuffles informative sectin 10 into now 2 sections: one about the operational aspect of ACP that i do consider to be crucial and that should lead to the YANG models for the ACP, the other one the background explanations and possible futures discussions. No changed text except introductory paragraphs for both of these sections. Did not want to merge this into -14 or else it would have made it totally impossible to disect -13 to -14 diffs just from published (non-git) versions. Cheers Toerless From nobody Wed Jun 6 14:52:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15531130DDC; Wed, 6 Jun 2018 14:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 aPqvMKPPRlhA; Wed, 6 Jun 2018 14:51:50 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04F1130DD3; Wed, 6 Jun 2018 14:51:49 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 84D1A58C4C4; Wed, 6 Jun 2018 23:51:45 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 811324401A4; Wed, 6 Jun 2018 23:51:45 +0200 (CEST) Date: Wed, 6 Jun 2018 23:51:45 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org Message-ID: <20180606215145.dzqan4quh26njthg@faui48f.informatik.uni-erlangen.de> References: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> <6c4f9527-1b96-9c14-ffe0-186a24eb9793@joelhalpern.com> <20180606203700.bewampnxs2vaevke@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180606203700.bewampnxs2vaevke@faui48f.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 21:51:59 -0000 Ooopss.. diff was not pointing to absolute label for second URL, here is working one: http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/57825aac69216fd01d388810ee804c7f25e8ab7d/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt On Wed, Jun 06, 2018 at 10:37:00PM +0200, Toerless Eckert wrote: > On Mon, May 14, 2018 at 11:15:58PM -0400, Joel M. Halpern wrote: > > (Sorry about the excess caps. Did not intentd to shout.) > > > > From some off-line disucssions, I understand that the actual address > > allocation is tied to the registration process. The registration process is > > not described in this document. > > > > As far as I can tell, the ACP does not depend upon the address allocation > > strategy. The address allocation strategy does require the ACP. And it > > requires and is closely coupled to the registration process. > > > > If that is true, the address allocation seems to be better described with > > the registration process. Which I presume is in the BRSKI document. > > > > All I would put in here is the basic ULA allocation (hash based generation) > > mechanism. > > Hi Joel (round 3) > > Here is the github version after the fixes discussed below > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt > > Here is the diff vs. the prior version (round 2) > > http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt > > Alas (but i think for the better), after > all the questions from and discussion with you, i tried to figure out how > to best document the answers to the questions you raised, and it started > answering why we need multiple address range - because have to waste > 48/46 bits on Registrar-IDs. Ok, Why ? Because we want multiple uncoordinated > registrars. Ok, what is a registrar. Especially when ACP does not use > BRSKI, which it claims it can. And how does certificate maintenance work > when you have multiple registrars. Aka: once i started to write text to > asnwer your questions i kinda got sucked into having the spec also answer > other questions. > > So, with this rev., we now define and use the term "ACP Registrar", > and define that thats a BRSKI Registrar in ANI nodes, but it can be > anything in non-ANI ACP nodes. Does not have to be software. It could > be you, if you want the job. Maybe Netconf or other protocols that > want to compete with BRSKI. > > Actually, verified i can be a registrar a long time ago, using old > crypto PKI CLI on ACP capable routers to manually hack in certificates > with specific properties i wanted. And getting them via web interface from > a CA. > > So, i think this is a very clean solution of documentation. The normative > part of the spec now has what i think was the minimum to define the > requirements for any ACP registrar including the most simple address > allocation example. > > So, then there is an informative section explaining the need for the > multiple address spaces because of those uncoordinated registrars. > And an informative section about how you would need to set up > such uncoordinated registrars, aka: each with their own sub-CA. All > in section 10.3 now. > > Then of course the whole point you made about about ACP addresses > being identifiers or not. So i wanted to document the point that they > are, but that also meant to explain how the ACP address information > will survive in the presence of renewal and re-enrollment with a different registrar > (which may not know the nodes assigned ACP address unless its presented > during re-enrollment/renewal). Then of course the case where a cert > is revoked maybe indirectly, because the registrar was attacked, not > the ACP node gets a new cert from another registrar but of course this is > is the only case where you want it to get a certificate with new ACP > address information (because the prior registrar became untrusted so > you don't trust what ACP information it assigned). > > So, this ended up being two new normative subsections in 6.1.3 - > re-enrollment and failing certificates, describing the requirements against ACP nodes > during renewal or failure of their cert. > > The informative part of the doc also got a section about registrars documenting > hopefully the key pieces: how it works in general (so folks get > an idea how they would be built with or without BRSKI), what parameters > they need, discussion about that multi-registrar renewal and sub-CA > case, and finally a discussion about how registrars could integrate > with centralized policy control. After all, the world is SDN, so if > we'd only document the cool distributed registrar case, this wouldn't sell well > in todays world *sigh*. > > The reasoning for this new text sections is all summarized/documented in the changelog for -14. > > I'd like to point out that even though this is a bunch of additional text, > it is in no way changing the way the ACP or registrars are meant to > operate. It is really just adding missing documentation about it. > > Hope this answers your questions and resolves your discuss. > > Cheers > Toerless -- --- tte@cs.fau.de From nobody Wed Jun 6 15:10:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E3E130DE5 for ; Wed, 6 Jun 2018 15:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 sO8VXWMnR2-3 for ; Wed, 6 Jun 2018 15:10:05 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B05130DE0 for ; Wed, 6 Jun 2018 15:10:04 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D7BB858C4C4; Thu, 7 Jun 2018 00:09:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C8B2A4401A4; Thu, 7 Jun 2018 00:09:56 +0200 (CEST) Date: Thu, 7 Jun 2018 00:09:56 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20180606220956.2562uj22ebxy5lye@faui48f.informatik.uni-erlangen.de> References: <23896.1527619421@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23896.1527619421@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] recording the need for a document on Operational security for ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 22:10:09 -0000 Btw: As just posted, i restructured acp-15 so that section 10 is now only what i call operational aspects, mostly about registrar behavior. Which does apply to any type of registrar mostly. BRSKI or not. Based on review/discuss with Joel. Just small bits specific to BRSKI. The more difficult part is that some of this behavior needs to be standardized. Thats the pieces i added to the normative sections. Such as "registrars MUST NOT allocate conflicting ACP addresses" (*doh*, but about the single most important requirement for the ACP ). Likewise interop is affected by how ACP nodes signal when certs expire or fail. Added to certificate maintenance section. I would be happy if i could offload all the operational aspects of the ACP into a separate operational RFC for ACP, especially if it could help to speed up getting this ACP draft out as an RFC (and make it shorter ;-). Alas i fear that some @$$^%*& IETF reviewer will not allow us to make such a new operational draft be an informational-only reference in the current ACP draft, and that would just have us achieve the opposite of what we need right now: Get the current ACP draft out. So, and here i can not distinguish my ACP author and WG chair head: unless some AD tells me how an ACP ops draft could NOT become a normative reference to the current ACP draft, i will push back against opening up one now (unfortunately).o Cheers toerless On Tue, May 29, 2018 at 02:43:41PM -0400, Michael Richardson wrote: > > Some private discussion has suggested that there is a need for a document on > operational issues (specifically security and PKI) for managing an ACP. > While in theory everything should be autonomous, the exceptional situations > and the multitude of options of how to deal with them will eventually need > some clarification, if only so that they are automated correctly. > > This is just a note for later on; I think we need some operating ACPs before > we can describe issues with them. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jun 6 16:40:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4461A131021 for ; Wed, 6 Jun 2018 16:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6u3uBrXxp1b for ; Wed, 6 Jun 2018 16:40:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B53131011 for ; Wed, 6 Jun 2018 16:40:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 01E9620090; Wed, 6 Jun 2018 19:53:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6242974; Wed, 6 Jun 2018 19:39:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5E4FA3F; Wed, 6 Jun 2018 19:39:32 -0400 (EDT) From: Michael Richardson To: Toerless Eckert , anima@ietf.org In-Reply-To: <20180606220956.2562uj22ebxy5lye@faui48f.informatik.uni-erlangen.de> References: <23896.1527619421@localhost> <20180606220956.2562uj22ebxy5lye@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] recording the need for a document on Operational security for ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 23:40:13 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > So, and here i can not distinguish my ACP author and WG chair head: > unless some AD tells me how an ACP ops draft could NOT become a norma= tive > reference to the current ACP draft, i will push back against opening > up one now (unfortunately). A future BCP (not Informational) draft on ACP operation could certainly reference the ACP draft normatively. But, I think you are worrying about the opposite, but the from/to in your sentence is not clear: That some operational BCP would have to be referenc= ed by the ACP draft, which would delay it. My take it that the right answer is to just say less ;-) RFC793 didn't tell us how to do congestion control, just that we needed it. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxhwtICLcPvd0N1lAQLbNQf/bUcnNCGw3aukXclXgSWGNEVw3XKc2xB0 DPcoMhBRLyiL9qNEJIfJa/NgEMVdFhbxX3JRKzQktP7qPckQVio/mTHXiqKZGedk qinAlkoQ1X9pQ+yrsqjXtv7rexX6CMLIoyjg56mc7jF/DYTOXYW+Dt8awcbmAhNE fzghL9pZ22NVltbCRSywsEDqKF1qNJUlf3UpuyJKwr+aSkYwo7JTZMZ8nao3Bztl quJbV65tYTkBdIC2SMLvAt7e+uu6PCbxhcfulVqmyCbDGTsqrrcKE5OEmwnTrUmn 90dB4Mi+oHzLi2ppQGm47lxH1eCdjsLmAkSZAGeEVIMnRxeJrqOr2w== =uJKq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 14:09:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D704130F89; Thu, 7 Jun 2018 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xbt5AJbdo_z; Thu, 7 Jun 2018 14:09:39 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47E6130DC1; Thu, 7 Jun 2018 14:09:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 959C32C07C3; Thu, 7 Jun 2018 14:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1528405779; bh=jYDd9Q1hiixJwdzvsOH1rPdOoDxv4jA7pAAZ6GRQrKE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UYaa6ST6v5el8wOvRTwJcZXRDjvyDH79zqcakQyBR+fxCC7uKF7vxw5dxGldTd6FF BTM919BZysvhrtEFXBlw2pdwE7qBqIPFU8ZftJEuzXwBYa2FMqZhwZ6C/tBkopfxex CLR2C24eMO6mL2X6A6+QbNQ/7yu9TthAQwH8VBtI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8CDF62C0842; Thu, 7 Jun 2018 14:09:38 -0700 (PDT) To: Toerless Eckert Cc: rtg-dir@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, ietf@ietf.org, anima@ietf.org References: <20180514090425.o2yr33536jru53bu@faui48f.informatik.uni-erlangen.de> <20180514125003.60B4474D368@faui45.informatik.uni-erlangen.de> <20180515025807.zormnu7fqq5rq3uj@faui48f.informatik.uni-erlangen.de> <6c4f9527-1b96-9c14-ffe0-186a24eb9793@joelhalpern.com> <20180606203700.bewampnxs2vaevke@faui48f.informatik.uni-erlangen.de> <20180606215145.dzqan4quh26njthg@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: <0878db84-ab65-6262-ed8c-cd982760a89f@joelhalpern.com> Date: Thu, 7 Jun 2018 17:09:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180606215145.dzqan4quh26njthg@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 21:09:43 -0000 Thank you for all your work on this. While I still find the presence of the address allocation mechanism strange to find in this document, I can live with it. So with this complaint done, I will shut up about it already. Aside from some items noted below, this seems to be in good shape. Moderate: Section 10.3.4 has a helpful discussion of some of the complexities of determining where to auto-enable the ACP. I am a bit surprised not to see some discussion of which VLANs to enable for ACP in an Ethernet environment. For WDM< since wavelength usage is configured, I presume that ACP would never try to auto-enable a frequency band? Minor comments: In section 6.1.1 the text and the ABNF says that an rsub is a full domain (using the same domain-name construct as the "domain" which is an FQDN. However, the example shows a partial domain string which is concatenated with the "domain" to produce an FQDN. And the syntqx of "routing-subdomain" shows that concatenation. This suggests that the text needs to be clear as to what the syntactic content of the rsub field is. Might it be better not to define it as a "domain-name" but to define it as FFS, with a caveat that whatever usage is later defined needs to be suitable for combining with the "domain" for generating the hash for the ULA Global ID? (Just to be clear, as written the text seems to end up with where is from RFC 1034. Section 6.1.2 bullet one states that "The peer certificate is valid as proven by the security association protocol exchange." I may be overstepping my knowledge, but I think there are two different things. First is the certificate validity, which is an internal property of the certificate. The second is the certficate applicability which may be informed by the protocol exchange. Related to that, please put in a reference to which protocol exchange you mean? Either there is a document inconsistency, or there is a typo in the first paragraph of section 6.10.7.3, in that the address prefix length for the zone address sub-scheme is /127, not /126. Yours, Joel From nobody Fri Jun 8 15:02:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DC1130F49 for ; Fri, 8 Jun 2018 15:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8EJRL9r1hDK for ; Fri, 8 Jun 2018 15:02:55 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4D6130DC9 for ; Fri, 8 Jun 2018 15:02:55 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id l2-v6so6975515pgc.7 for ; Fri, 08 Jun 2018 15:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PGHYH3/JFnF53faRJgh/+oUg4ErG5RU5mJyZCoff7Bk=; b=NNvx5QlBzGrtyT2aNcuCUytk/dYJcuGSj9r0NAbzGcW26VPwNXCrChM41OSt8OWszM dw3MhTZ6m9g4GHC7XtSWIbzAvlnxdx1teAgm9/bicfPHT56Jkv2sVwYYJivX+RiOLnaZ tNbtORdLWJfkikTmwj0cD5WE8aknolX19qmsl9GJfE3YvTGqcG5hugt+QaHF0X3fYbpL V11qKv/EnZ1acMkAvzJe8fxLFFhCGPaxuOfDkZlvYPg5PEkrldf0U6HNGtmOR+ZZOBXY SbRUCiNRzvlK7YZlDzdsYjSjX/inPg5vt5Ps82kFPknBTVr9oeyr0Ch0hKs1RHXcm4th jwTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PGHYH3/JFnF53faRJgh/+oUg4ErG5RU5mJyZCoff7Bk=; b=engNQX9lTBIWgx7D7HH8sr/to1WukJaLMtKnLvrW+Uktc40Ww3+mbdlGIPnOsK63Z7 Blle8/8pbMuVhoeJyllmQcU3AQbasolwk3hzGCRrv8gAtLPuUyd+aeP3uyPlF3vepWKK OgoQfv6UtRBr2hW9z1E/j5x+vlmigm+3lzsFg6UGUTrAYB9sdO83Bo9CRYOVAAdNWlnI zL6gFo63rk7pwm9pQxXbHjEyOUE7TRCOrKb57NvwqHnfuQeCsSgZ6K2AjdwUfkNVEzH+ E4tb+YWDJRhWmLuGQgLoBq3q9K6vgyxW7bWMp5HejLUce//Rxln/rczwehlb157080I5 wpuA== X-Gm-Message-State: APt69E1vczVyPj3fn63y/uWOzfslXbBlaFsaEU8r4QonpRAkBPfY6x1p 6W2jM78oCMvvXNEhEi8BOqBdbg== X-Google-Smtp-Source: ADUXVKIX2kCm86a8XUw/sCKGsltAehWOUjjHxTvulxH5TcFFsuM4iT9RsuG94kpVwjTzZjrXWel9PQ== X-Received: by 2002:a65:4487:: with SMTP id l7-v6mr6753692pgq.357.1528495374524; Fri, 08 Jun 2018 15:02:54 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id s19-v6sm21562294pfe.97.2018.06.08.15.02.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 15:02:53 -0700 (PDT) To: Anima WG References: <152832078536.6116.12559457390047298236@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <02cdc6c7-2629-8e5c-7667-5d42ab85c141@gmail.com> Date: Sat, 9 Jun 2018 10:03:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152832078536.6116.12559457390047298236@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-15.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 22:02:58 -0000 Hi, I think the changes in this version are all good. I'm certain that this document will need a Version 2 in due course when we have more experience, but that's why it will be called a "proposed" standard. Regards Brian On 07/06/2018 09:33, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > > Title : An Autonomic Control Plane (ACP) > Authors : Toerless Eckert > Michael H. Behringer > Steinthor Bjarnason > Filename : draft-ietf-anima-autonomic-control-plane-15.txt > Pages : 132 > Date : 2018-06-06 > > Abstract: > Autonomic functions need a control plane to communicate, which > depends on some addressing and routing. This Autonomic Management > and Control Plane should ideally be self-managing, and as independent > as possible of configuration. This document defines such a plane and > calls it the "Autonomic Control Plane", with the primary use as a > control plane for autonomic functions. It also serves as a "virtual > out-of-band channel" for Operations Administration and Management > (OAM) communications over a network that is secure and reliable even > when the network is not configured, or misconfigured. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-15 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-15 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Jun 8 15:52:50 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA28F130DC1; Fri, 8 Jun 2018 15:52:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152849836177.23805.16726035200159417511@ietfa.amsl.com> Date: Fri, 08 Jun 2018 15:52:41 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-16.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 22:52: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 : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-16.txt Pages : 133 Date : 2018-06-08 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-16 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 8 16:03:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B76130DCF; Fri, 8 Jun 2018 16:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 UfcmJZ7BoAIH; Fri, 8 Jun 2018 16:02:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E85130DCC; Fri, 8 Jun 2018 16:02:58 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4F19A58C4B3; Sat, 9 Jun 2018 01:02:54 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3C0E84401A4; Sat, 9 Jun 2018 01:02:54 +0200 (CEST) Date: Sat, 9 Jun 2018 01:02:54 +0200 From: Toerless Eckert To: Mirja K?hlewind Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20180608230254.2nzurmnoyp42s6a3@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <152665944850.1663.17974282102092824462.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Mirja K?hlewind's No Objection on draft-ietf-anima-autonomic-control-plane-13: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:03:02 -0000 Thanks, Mirja Answers inline Changes for feedback from Mirja, Kumar and Joel committed to -16, didn't create separate diff for individual reviewers as diff is not large. (Just ignore whole section 11 moved to appendix in diff.) https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt Cheers Toerless On Fri, May 18, 2018 at 09:04:08AM -0700, Mirja K?hlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) I would like to see a slightly stronger statement here in section 6.1.3: > "The M_FLOOD message MUST be sent periodically. The default SHOULD be > 60 seconds, the value SHOULD be operator configurable." > Maybe the following instead: > "The M_FLOOD message MUST be sent periodically. The default MUST be > 60 seconds, the value SHOULD be operator configurable but SHOULD be > not smaller than 60 seconds." Done. > Or even a MUST for the minimum value is that acceptable for the desired use cases. Depends on network. 60 seconds is goo enough for most networks and should not create too much traffic for all current in-scope networks. May probably need to be higher when we look more into IoT network. But when i have some DC operator plugging in some spare switch into the DC fabric and it needs to renew its cert before being able to operate, and this guy has to wait in front of the switch until it runs before he can move on , 60 seconds is eternity, and DC fabric would be happy with 5 seconds too. Aka: can't say a good minimum for all use-cases. SHOULD is ok. (i hate periodic, but making this non-periodic is more work than fit this first round). > 2) Also in section 6.5, I would like to seem some rate limiting/pacing: > "An ACP node may choose to attempt initiate the different feasible ACP > secure channel protocols it supports according to its local policies > sequentially or in parallel,..." Right now we've defined only 2 channel mechanisms, IPsec and dTLS, so i don't think we can reasonably worry about rate limiting when attempting to do them in parallel. Especially because because the performance requirement is not when you initiate, but when you respond. Once there is more interest in other channel protocols, and we feel there are important situations where you can't try them in parallel (performance or othre reasons), i'd rather start standardizing whats currently only written informationally: "Extending ACP channel negotiation (via GRASP)" aka: you do only one secure GRASP connection, in it yo negotiate IPSec, dTLS, MacSec, AvianCarriers, and then you follow with the one choice mutually selected as the best from that list. Aka: there is already an exit strategy from too many parallel options should they happen to come into existance. > 3) Sec 6.7.3: How are baseline ACP and constrained ACP nodes defined? Elaborated text more to make it hopefully more self-explanatory: As explained in the beginning of , there is no single secure channel mechanism mandated for all ACP nodes. Instead, this section defines two ACP profiles for ACP nodes that do introduce such requirements. A baseline ACP node MUST support IPsec natively and MAY support IPsec via GRE. A constrained ACP node that can not support IPsec MUST support DTLS. An ACP node connecting an area of constrained ACP nodes with an area of baseline ACP nodes MUST therefore support IPsec and DTLS and supports threefore the baseline and constrained profile. > 4) sec 6.10.6: > "With the current allocations, only 2 more schemes are > possible, so the last addressing scheme should consider to be > extensible in itself (e.g.: by reserving bits from it for further > extensions." > Maybe use a normative MUST here: > "With the current allocations, only 2 more schemes are > possible, so the last addressing scheme MUST be > extensible in itself (e.g.: by reserving bits from it for further > extensions." fixed to: ...scheme MUST provide further extensions. > 5) I guess section 10 could be moved to the appendix. I did reorder section 10 subsection, so now section 10 is only what i consider to be the important operational aspects of ACP, aka what hopefully will become YANG model (config, diagnostics etc.) in the future. Section 11 is then explanations and futures. I am obnoxiously NOT a fan of appendices because there is good reason to believe that text in an appendix will be more often ignored by readers. So thats why i do not want 10. to be an appendix. But i now moved 11 into Appendix. Hope this is goo dcompromise. Cheers Toerless From nobody Fri Jun 8 16:03:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA79130DC1; Fri, 8 Jun 2018 16:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 p60aiVz711GD; Fri, 8 Jun 2018 16:03:28 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4949130DCC; Fri, 8 Jun 2018 16:03:27 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3D11258C4B3; Sat, 9 Jun 2018 01:03:23 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 320084401A4; Sat, 9 Jun 2018 01:03:23 +0200 (CEST) Date: Sat, 9 Jun 2018 01:03:23 +0200 From: Toerless Eckert To: Warren Kumari Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20180608230323.gkrqf56okfqrl5cl@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152830654814.6366.4951842776897034198.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Warren Kumari's Discuss on draft-ietf-anima-autonomic-control-plane-13: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:03:37 -0000 Thanks a lot Warren, great suggestions. Replies inline Changes for feedback from Mirja, Kumar and Joel committed to -16, didn't create separate diff for individual reviewers as diff is not large. (Just ignore whole section 11 moved to appendix in diff.) https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt Cheers Toerless On Wed, Jun 06, 2018 at 10:35:48AM -0700, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm balloting DISCUSS, but I think that this should be relatively simple to > address: The document says things like:"Today, the management and control plane > of networks typically runs in the global routing table, which is dependent on > correct configuration and routing." and "Context separation improves security, > because the ACP is not > reachable from the global routing table. " > > The term "global routing table" is widely used and understood to mean the > global BGP routing table, or Internet global routing table. I understand that > you are using it in the "default VRF" meaning, but I think that it is really > important to clarify / disambiguate this the first time you use it. Good catch. The use of "global routing table" seems to be almost a day 1 text issue of the doc ;-( We can't use VRF to explain it, because we are not referring to VRFs in the data-plane anymore for those devices that do not have VRFs. (reviewer request) Only ACP VRF is defined and used as a term. I removed all uses of "global routing" (table), and just refer to "Data-Plane routing (and forwarding, where appropriate) tables": | Today, the management and control plane of networks typically uses a routing and forwarding table which is dependent on correct configuration and routing | For management plane protocols, the ACP provides the functionality of a Virtual out of Band (VooB) channel, by providing connectivity to all nodes regardless of their Data-Plane configuration, routing and forwarding tables. | Context separation improves security, because the ACP is not reachable from the Data Plane routing or forwarding table(s). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you very much for writing this document -- it is comprehensive... > > A rich text version of my review is here: > https://mozphab-ietf.devsvcdev.mozaws.net/D3801#inline-4146 , and pasted below > for tooling, email, etc. > > --- > draft-ietf-anima-autonomic-control-plane.txt:212 > network nodes that is not the ACP, and therefore considered to be > dependent on (mis-)configuration. This data-plen includes both the > traditional forwarding-plane, as well as any pre-existing control- > Nit: data-plane Done. > draft-ietf-anima-autonomic-control-plane.txt:508 > certificate. This does not require any configuration on intermediate > nodes, because they can communicate zero-touch and securely through > the ACP. > I understand what you are trying to say, but "zero-touch" is not an adverb. Took the opportunity fix also some semantics of the paragraph. With the ACP, secure bootstrap of new devices and whole new networks can happen without requiring any configuration of unconfigured device along the path: As long as all devices along the path support ACP and a zero-touch bootstrap mechanism like BRSKI, the ACP across a whole network of unconfigured devices can be brought up without operator/provisioning intervention. The ACP also provides additional security for any bootstrap mechanism, because it encrypts the traffic along the path hop-by-hop. > > draft-ietf-anima-autonomic-control-plane.txt:518 > the data-plane is operational, will the other planes work as > expected. > This is *sometimes* an undesirable dependency, but is usually viewed as a > feature (by operational people) -- having the control plane share fate with the > dataplane is something that is usually a feature - this drives at least part of > the reason that many organizations run OSPF and OSPFv3 - having V4 OSPF relying > on v4 dataplane avoids blackholes if the v4 dataplane stops working. (This is > sometimes, but less often used as an argument against ISIS). > > I understand why it is useful in this context, but it would be useful to > clarify/make it clear that you understand the subtleties. Added paragraph: Note that specific control plane functions for the Data-Plane often want to depend on forwarding of their packets via the Data-Plane: Aliveness and routing protocol signaling packets across the Data-Plane to verify reachability across the Data-Plane, using IPv4 signaling packets for IPv4 routing vs. IPv6 signaling packets for IPv6 routing. > Also, nit: "is operational, will the" -- the comma feel weird here. Removed > draft-ietf-anima-autonomic-control-plane.txt:526 > management session is running can lock an admin irreversibly out of > the device. Traditionally only console access can help recover from > such issues. > "only console access or OOB". > > You may be using "console access" to mean OOB, but much (most?) OOB is now not > console based. Changed to: > Traditionally only out-of-band access can help recover from such issues (such as serial console or ethernet management port) Mileage for ethernet based OOB does vary i think. Probably on DC and core/distribution SP gear. Not the typical enterprise gear yet, i think. > draft-ietf-anima-autonomic-control-plane.txt:531 > Operations Center") such as SDN controller applications: Certain > network changes are today hard to operate, because the change itself > may affect reachability of the devices. Examples are address or mask > I think that this was an editing issue -- you don't "operate" changes. Perhaps > "implement"? Good suggestion. Fixed. > draft-ietf-anima-autonomic-control-plane.txt:858 > o If the node certificates indicate a CDP (or OCSP) then the peer's > certificate must be valid according to those criteria. e.g.: OCSP > You expand CDP further in the document, but this is the first time it is used. Expansion of terms was introduced in -14. > draft-ietf-anima-autonomic-control-plane.txt:994 > ACP neighbors. Native interfaces (e.g.: physical interfaces on > physical nodes) SHOULD be brought up automatically enough so that ACP > discovery can be performed and any native interfaces with ACP > I don't have a suggestion, but "automatically enough" doesn't sound right - > "automatically configured enough" ? Fixed to: SHOULD be initialized automatically to a state in which ACP discovery can be performed > draft-ietf-anima-autonomic-control-plane.txt:1067 > In the above (recommended) example the period of sending of the > objective could be 60 seconds the indicated ttl of 180000 msec means > that the objective would be cached by ACP nodes even when two out of > Editing fail -- missing some punctuation or words. Fixed in -14. > draft-ietf-anima-autonomic-control-plane.txt:1933 > for reachability. The use of the autonomic control plane specific > context eliminates the probable clash with the global routing table > and also secures the ACP from interference from the configuration > IMPORTANT: The term "global routing table" has a well known meaning in > operations -- it is the global BGP table. I strongly suggest using a different > term, or having a very clear statement in the terminology section, AND the > first time you use it in the document. This will help minimize confusion. Done. See Discuss section. > draft-ietf-anima-autonomic-control-plane.txt:3081 > 10.2. ACP (and BRSKI) Diagnostics > Just a note that I like / appreciate this section - having guidance on how to > troubleshoot is very helpful. Thanks. > draft-ietf-anima-autonomic-control-plane.txt:3416 > 10.3.2.2. Fast state propagation and Diagnostics > > "Physical down" state propagates on many interface types (e.g.: > When I saw the "physically brought down" I started composing a long soapbox > rant on the fact that this will slow down state propagation -- I like that that > document anticipates and addresses this. It might be useful to have a pointer > in the previous section (like "(see below)" or similar.) First paragraph of previous chapter (admin-down) had (see below), now addd xref: (see below, ) > draft-ietf-anima-autonomic-control-plane.txt:3482 > for 5 seconds to probe if there is an ACP neighbor on the remote end > every 500 seconds = 1% power consumption. > I believe that this is sufficiently incorrect that you should remove the 1% > result (or, better yet the whole last sentence). > > Various interfaces (especially long reach) take a significant amount of time > (and additional power) when bringing up interfaces -- things like DWDM optics > and amplifiers sometimes need significant power for heating elements to lock > the frequency / wavelength, and so the power consumption is not linear with > interface uptime. fixed to: Power consumption of "physical down" interfaces may be significantly lower than those in "admin down" state, for example on long range fiber interfaces. Bringing up interfaces, for example to probe reachabiliy, may also consume additional power. This can make these type of interfaces inappropriate to operate purely for the ACP when they are not currently needed for the Data-Plane. Joel Halpern also asked about DWDM. I'll refrain from trying to add more details here how this situation could othrewise be mitigated, i just wanted to highlight understood key aspects, not necessarily all solutions. From nobody Fri Jun 8 16:04:36 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA69130DCC; Fri, 8 Jun 2018 16:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 H2tWlRIhCSAT; Fri, 8 Jun 2018 16:04:21 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251F7130DC1; Fri, 8 Jun 2018 16:04:21 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BD7C058C4B3; Sat, 9 Jun 2018 01:04:16 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B3AFD4401A4; Sat, 9 Jun 2018 01:04:16 +0200 (CEST) Date: Sat, 9 Jun 2018 01:04:16 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180608230416.jy4xjp7smqm444tc@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0878db84-ab65-6262-ed8c-cd982760a89f@joelhalpern.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:04:28 -0000 Thanks, Joel Replies Inline Changes for feedback from Mirja, Kumar and Joel committed to -16, didn't create separate diff for individual reviewers as diff is not large. (Just ignore whole section 11 moved to appendix in diff.) https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt Cheers Toerless On Thu, Jun 07, 2018 at 05:09:37PM -0400, Joel M. Halpern wrote: > Thank you for all your work on this. > > While I still find the presence of the address allocation mechanism strange > to find in this document, I can live with it. > So with this complaint done, I will shut up about it already. Thanks. Lets take it offline. I am still interested to understand that point, especially after the text i added in the hope to clear this concern. Answers inline. Thanks Toerless > Aside from some items noted below, this seems to be in good shape. > > Moderate: > > Section 10.3.4 has a helpful discussion of some of the complexities of > determining where to auto-enable the ACP. I am a bit surprised not to see > some discussion of which VLANs to enable for ACP in an Ethernet environment. Thats a topic better to be discussed in followup work. Cisco IOS ACP implementation does support automatic VLAN discovery & selection. Lot of experience/insight from that. Trust me, it would be scope creep for the ACP document itself. > For WDM< since wavelength usage is configured, I presume that ACP would > never try to auto-enable a frequency band? Right. Given the experience with VLANs, the clean cut we could make for this basic ACP specification is to logically sit on top of IPv6 subnet interfaces, ignore all L2/L1 complexities and live with the dependency against IPv6 being able to bring up link-local-scope reachability to neighbors. [ And then write followup docs if/when we ever get this first doc out as an RFC ;-) ] The way i would imagine WDM is a bit more like ethernet switches in section 7 though: You'd want to get ACP connectivity across your optical equipment and also be able to reach through the ACP your optical equipment, but that would not use special colors, but more likely should be added to / leverage the existing in-band management channels of the optical equipment. Long discussion. Let me rather stop. > Minor comments: > In section 6.1.1 the text and the ABNF says that an rsub is a full domain > (using the same domain-name construct as the "domain" which is an FQDN. > However, the example shows a partial domain string which is concatenated > with the "domain" to produce an FQDN. And the syntqx of "routing-subdomain" > shows that concatenation. This suggests that the text needs to be clear as > to what the syntactic content of the rsub field is. Hmm... RFC1034 does not even mention the term "fully qualified (domain name)" / FQDN, You seem to read RFC1034 3.5 to mean that all domain are FQDN, but that is not clear to me. In the RR examples of RFC1034, FQDNs are identified by ending with a ".", which AFAIK is the standard for FQDN,but the 3.5 syntax doesn't even allow you to create such an FQDN, so i was thinking that 3.5 "domain" do not have to be FQDNs, and therefore i am assuming that is is also perfectly legal to use a syntax of domain3 = domain2 . domain1, as in routing-subdomain = rsub . domain-domain-name. > Might it be better not > to define it as a "domain-name" but to define it as FFS, with a caveat that > whatever usage is later defined needs to be suitable for combining with the > "domain" for generating the hash for the ULA Global ID? Well, it does have to be some RFC822-local-part-FFS, but i think its a lot better if its constrained to the domain name syntax, because it is quite normal operations to have for every actual routing subdomain in the network also some associated domain name, and that is what "routing-subdomain" is. So if i build a parser for configuring my segmented routing with the ACP, its a lot more logical to allow only longer domain names for routing-subdomain that all have the same parent domain (domain). > Just to be clear, as written the text seems to end up with > where is from RFC 1034. Right. See above. I tried to figure out how to unconfuse this. I changed "domain" to "acp-domain-name", so that its not confused with RFC1034 "domain", eliminated "domain-name", and also changed the definition of rsub to use RFC1034 "subdomain" instead of "domain", even though i can for the heck of it not figure out what the difference between domain and subdomain is, except that a domain can be " ", which seems to be the domain root, but its not really defined. But at least it should hopefully eliminate the misconception that rsub has to be an FQDN. > Section 6.1.2 bullet one states that "The peer certificate is valid as > proven by the security association protocol exchange." I may be > overstepping my knowledge, but I think there are two different things. First > is the certificate validity, which is an internal property of the > certificate. The second is the certficate applicability which may be > informed by the protocol exchange. Good catch. Fixed as follows: The following points constitute the ACP domain membership check of a possible peer certificate, independent of the protocol used: The peer certificate is valid (lifetime). The peer has proved ownership of the private key associated with the certifictes public key. > Related to that, please put in a reference to which protocol exchange > you mean? No, the goal is to define this independent of protocol. > Either there is a document inconsistency, or there is a typo in the > first paragraph of section 6.10.7.3, in that the address prefix length for > the zone address sub-scheme is /127, not /126. > > > Yours, > Joel From nobody Fri Jun 8 16:14:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297FB130DD1; Fri, 8 Jun 2018 16:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Wp7Y3tYa9ebM; Fri, 8 Jun 2018 16:14:46 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A03130DC1; Fri, 8 Jun 2018 16:14:46 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E295A58C4B3; Sat, 9 Jun 2018 01:14:40 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C06F04401A4; Sat, 9 Jun 2018 01:14:40 +0200 (CEST) Date: Sat, 9 Jun 2018 01:14:40 +0200 From: Toerless Eckert To: "Pascal Thubert (pthubert)" Cc: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Message-ID: <20180608231440.maxyvrcam5yt5ttm@faui48f.informatik.uni-erlangen.de> References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:14:51 -0000 Thanks, pascal. the "standard (issue)" got fixed too in -14, forgot to include a specific note to you. Cheers Toerless On Tue, May 22, 2018 at 02:06:17PM +0000, Pascal Thubert (pthubert) wrote: > Hello Toerless: > > > > Thanks, Pascal, sorry for the delay, > > > > Comments inline. > > > > Version: > > > > https://raw.githubusercontent.com/anima-wg/autonomic-control- > > plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima- > > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt > > > > > > Diff to prior version (-14 for Joel Halpern) > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercon > > tent.com/anima-wg/autonomic-control- > > plane/8b4436edaa720eadb5839120400fd1e89d3289b0/draft-ietf-anima- > > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > > 14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic- > > control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf- > > anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > > 14.txt > > > > Will commit as -14 when i am through with the other -13 feedback. > > > > Cheers > > Toerless > > > > > > On Mon, Feb 26, 2018 at 05:25:58PM +0000, Pascal Thubert (pthubert) > > wrote: > > > Reviewer: Pascal Thubert on behalf of IOT-DIR; > > > > > > I am an assigned IoT directorate reviewer for draft-ietf-anima-autonomic- > > control-plane-13. > > > > > > These comments were written primarily for the benefit of the INT and OPS > > Areas Directors from the IoT perspective. Document editors and shepherd(s) > > should treat these comments just like they would treat comments from any > > other IETF contributors and resolve them along with any other Last Call > > comments that have been received. For more details on the IoT Directorate, > > please see https://datatracker.ietf.org/group/iotdir/about/ and for > > Directorates in general please see > > https://www.ietf.org/about/groups/directorates/. > > > > > > > > > I'll be away for the next 2 weeks and could not finish the review in time for > > this heavy document, but at least I made it through till the RPL section. In the > > interest of time, let me share what I already have. > > > > > > > > > > > > Summary > > > > > > ------------- > > > > > > The summary of the review is that the document is Ready for Publication, > > with comments. > > > > > > > > > > > > > > > > > > Major comments > > > > > > ------------------------ > > > > > > > > > > > > - " in-band" and "out of band network " > > > > > > should be defined since it is fundamental to understand that the ACP > > > takes place in the same physical links as the data plane, as opposed > > > to dedicated management ports (correct?); > > > > Good point, done. (got a bit too long to paste here, so pls. check diff). > > > > > > > > - Section 3; the IOT certainly could use an ACP. It would be useful to > > scope the feature that is proposed in this document, whether it is compatible > > of not with constrained environments, whether it needs adaptations, point on > > Michael's enrollment draft. It would also be useful to indicate whether the > > ACP works between L3 bridges, IOW whether ACP operates the same (over IP) > > regardless of the packet forwarding layer in the data plane; > > > > Not sure i understand the "point on Michaels enrollment draft". > > > > I am happy to add pointers to variations of ACP design aspects for > > informational purposes to show that/how it can be modified, but Michaels > > drafts i think are all variation of the BRSKI design, so the ACP would be > > completly unaffected by them, right ? > > > [PT>] I guess you're right there > > > Wrt. constrained devices and L2. I didn't want to touch section 3 for what you > > suggested because that really a very formulistic section going back to the > > charter 1 justifications of ANIMA and matched with the three numbered use > > case explanations in the introduction. > > > [PT>] OK > > > Instead i wrote text at the end of the introduction, now section 1.1, This got > > longer than i hoped, but it was really a big missing piece to pitch the ACP and > > give early on context for implementers and reminding of the charter goal of > > reusing the best available existing protocols/function. > [PT>] > [PT>] I read it, very cool. > > > > The text got longer specifically also because i did not want to fall into the trap > > of making claims whether or not ACP is applicable to specific IOT networks or > > (even worse) assuming IOT is always constrained. Therefore mentioning of OT > > networks (IMHO big part of IOT, and often totally non-constrained), > > explanation of why RPL, and at the end a statement about constrained > > environments. There is also a new paragraph in 10.8 about TCP/TLS vs. > > CoAP/DTLS as a possible constained environment variant in the future. > > > > > - " Inside the ACP VRF, each node sets up a loopback interface with its > > ULA IPv6 address" > > > This is the first time, IPv6 is discussed; would have been nice to > > > introduce that the Node has IPv6, that it needs a ULA and that ACP > > > assigns it. This discussion could be done in conjunction with the > > > comment above; > > > > Actually, section 1. introduction already mentions that the ACP provides > > IPv6 and that the stable-connectivity document describes how to interoperate > > with IPv4 only OAM. > > > > I added to the new 1.1 section (see above) the following paragraph, which i > > hope is a useful context setting and pitch: > > > > The ACP uses only IPv6 to avoid complexity of dual-stack ACP operations > > (IPv6/IPv4). Nevertheless, it can without any changes be integrated into even > > otherwise IPv4-only network devices. The data-plane itself would not need to > > change, it could continue to be IPv4 only. For such IPv4 only devices, the IPv6 > > protocol itself would be additional implementation footprint only used for the > > ACP. > [PT>] OK > > > > > > - About "The ttl > > > parameter SHOULD be 3.5 times the period so that up to three > > > consecutive messages can be dropped before considering an > > > - announcement expired. " > > > > > > This is the only discussion on the ttl field of the M_FLOOD. Though its > > meaning is quite obvious, the behavior associated to it should be defined. > > > > Added: > > > > When a service announcer > > using these parameters unexpectely dies immediately after sending the > > M_FLOOD, receivers would consider it expired 210 seconds later. When a > > receiver tries to connect this dead service earlier, it will experience a failing > > connection and use that as an indication the service is dead and select > > another instance of the same service instead. > > > [PT>] OK > > > > - "In the above (recommended) example the period of sending of the" > > > Is this RECOMMENDED IOW normative?? > > > > Hmmm... Sure, why not. Less guessing/experiementation for this. > > Modified to RECOMMENDED. > [PT>] OK > > > > > > - Text P 25 says "At this time in the lifecycle of ACP nodes, it is unclear > > whether it > > > is feasible to even decide on a single MTI (mandatory to implement) > > > security association protocol across all ACP nodes" > > > but then P27 "It MUST support ESP > > > with AES256 for encryption and SHA256 hash and MUST NOT permit > > weaker > > > crypto options." > > > > > > and then " A baseline ACP node MUST support IPsec natively and MAY > > support IPsec > > > via GRE. A constrained ACP node MUST support dTLS. ACP nodes > > > connecting constrained areas with baseline areas MUST therefore > > > > > > support IPsec and dTLS." > > > > > > Seems that text P25 should go? > > > > P27: An ACP node supporting native IPsec MUST use IPsec security setup via > > IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for > > encapsulation. It MUST support ESP... (parameters). > > > > clarified to: > > > > P27: An ACP node that is supporting native IPsec MUST use IPsec security > > setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for > > encapsulation. It MUST then support ESP... (parameters). > > > > Also: > > > > ACP nodes supporting ACP via GRE/IPsec MUST support IPsec security setup.. > > > > clarified to: > > > > An ACP node that is supporting ACP via GRE/IPsec MUST then support IPsec > > security setup.. > > > [PT>] OK > > > Aka: P25 is correct, there is no single MTI. 6.7.3 defines the actual > > requirement for two different profiles: "baseline ACP node" and "constrainted > > ACP node". > > The two requirements in P27 are only conditional MUSTs defining the details > > of the IPsec profiles assuming a node does support IPsec or IPsec/GRE. > > > > Let me know if this is still unclear, and if so, how you would suggest to make it > > better readable. > [PT>] Someone else need to do it now I'm biased > > > > > > - "Use-ULA: For loopback interfaces of ACP nodes, we use Unique > > Local > > > > > > Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] > > > > > > with L=1]." > > > > > > This needs to be more crisp. ULA is defined in RFC 4193 but the term > > > ULA-Random is not. I think you mean that 3.2.2. of RFC 4193 is the > > > way addresses are formed, if so please say so. The best practice RFC > > > 8064 recommends use of RFC 7217. I understand that privacy is not a > > > concern but does it hurt? Anyway please point at section 6.10 and > > > 6.11.1.11 > > > > The term "ULA-Random" was used in the discussions on ANIMA mailing list re. > > ULA, so admittedly i didn't check that the term as it stands is actually not > > defined/used in rfc4193 - but its just meant to imply ULA with L=1, nothing > > more. I've removed the use of ULA-Random from the text and just refer now > > to 4193 with L=1 (also pointing to 3.1. of rfc4193 defining L). > > > [PT>] cool; > > > I have also added a note that the hash uses our own ACP definition instead of > > rfc4193 3.2.2. > > > > Paragraph is now: > > > > Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local > > Addresses (ULA), as defined in with L=1 (as defined > > in section 3.1 of ). Note that the random hash for > > ACP loopback addresses uses the definition in and > > not the one of section 3.2.2. > > > > 8064/7217 are irrelevant here if i understand it correctly because we define > > the addressing scheme for anything following the ULA prefix ourselves for > > ACP addresses. Let me know if i do misunderstad what you where trying to > > suggest re. 8064/7217. > [PT>] > [PT>] I guess I missed that you defined the IID. > > > > > > - " > > > RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with > > multicast support". Implementations should support also other modes. > > > > > > Note: Root indicates mode in DIO flow" > > > > > > Why "should" ? there is no much point supporting the other modes is > > there? Section 6.11.1.13 says that SRH is not used so this is inconsistent. You > > only need MOP 2 or 3, 3 is you do multicast which at the moment does not > > appear to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 > > which is a superset of MOP 2, and that's it (see 6.3.1 of RFC 6550). > > > > Probably a transcription error on my side when i took your RPL summary and > > wrote it down. Fixed according to above. > > > [PT>] cool > > > > > > - "The lack of a RPI (the header defined by [RFC6553]), means that the > > > data-plane will have no rank value that can be used to detect loops. > > > As a result, traffic may loop until the TTL of the packet reaches > > > zero. " > > > > > > Since we have reliable links and no stretch (section 6.11.1.7), loops > > > should be exceedingly rare. It could be recommended to send the DIOs > > > 2-3 times to inform children when losing the last parent. Note that > > > the technique in section "8.2.2.6. Detaching" of RFC 6550 should be > > > favored over that in section "8.2.2.5. Poisoning" because it allows > > > local connectivity. Also, It should be said that a node should select > > > more than one parent, at least 3 if possible, and send DAOs to all of > > > then in parallel. This provides multi > > > > Not sure why your paragraph ends apruptly, buts its also in the archive, so its > > not a mistake on my email end. Hopefully nothing significant missing. > [PT>] > [PT>] Dunno what happened. Selecting multiple parents enables NECM back. Could be useful. > > > > > I have replaced the suggestive text that followed your above quoted text in > > the draft: > > > > There are a variety of heuristics that can be used to signal from the > > data-plane to the RPL control plane that a new route is needed. > > > > With a hopefuly correct transcription of your suggestion: > > > > > > Since links in the ACP are assumed to be mostly reliable (or have link > > layer protection against loss) and because there is no stretch > > according to , loops should be > > exceedingly rare though. > > > > There are a variety of mechanisms possible in RPL to further > > avoid temporary loops: DIOs SHOULD be sent 2...3 times to inform children > > when losing the last parent. The technique in > > section 8.2.2.6. (Detaching) SHOULD be favored over that in section 8.2.2.5. > > (Poisoning) because it allows local connectivity. Also, nodes SHOULD select > > more than one parent, at least 3 if possible, and send DAOs to all > > of then in parallel. > > > [PT>] Yes, I'm good with all this. > > > > - "ACP nodes MUST perform standard IPv6 operations across ACP > > virtual > > > interfaces including SLAAC (Stateless Address Auto-Configuration - > > > RFC4862])" > > > > > > They may actually prefer Optimistic DAD RFC 4429 since address duplication > > is highly improbable as long as you . > > > > > Added: > > > > "Optimistic Duplicate Address Detection (DAD)" according to > > is RECOMMENDED because the likelyhood for > > duplicates between ACP nodes is highly improbable as long as > > the address can be formed from a globally unique local assigned > > identifier > > (e.g.: EUI-48/EUI-64, see below). > > > [PT>] > [PT>] I'm unsure what your recommendation for the interface ID is thus the discussion on RFC 7217. > > Note: I have only one slight comment left below: > > > > > Minor comments > > > > > > ------------------------ > > > > > > > > > > > > > > > > > > - About "[RFC7575] defines the fundamental ... " > > > > > > for readability, it may be nicer to indicate the title of an RFC when > > > it is referenced first; e.g. the text above would become > > > > > > " Autonomic Networking: Definitions and Design Goals" [RFC7575] defines > > the fundamental ... > > > > Ok, i am punting this one for now to RFC editor after playing around a bit with > > the XML options - and not being satisfied... and having references for 50 RFCs > > in the doc: > > > > [RFC Editor: Question: Is it possible to change the first occurrances of > > [RFCxxxx] references to "" [RFCxxxx] ? the XML2RFC format does > > not seem to offer such a format, but i did not want to duplicate 50 first > > references to be duplicate - one reference for title mentioning and one for > > RFC number.] > > > > If RFC editor comes back and can't do this easier than i can in XML, i'll try to > > go through the chores when doc is in RFC editor queue. > > > > > - about "or network plane (there is no well-established name for this)" > > > > > > The term network plane is not used again in the document. This text may go > > away. > > > > Done. > > > > > You may consider using "security and transport substrate" instead, since it is > > used elsewhere in the document. > > > > "autonomic communications fabric" = ACP including ACP GRASP (ACP GRASP > > provides discovery etc..). "security and transport substrate" == the parts of > > ACP used by "ACP GRASP" (aka: The secure IPv6 forwarding of ACP). > > > > Subtle difference. > > > > > Also, please be consistent on whether you use hyphen or not and use > > > that globally, e.g. for the above, and pane like in "forwarding plane" > > > or "out of band network "; > > > > Fixed up "out of band" (no hyphens) and "in-band" (with hyphen). > > Not sure why but this is what MS word spelling checker suggested to me. RFC > > editor will override if these are not the best choices. > > > > > > > > > - "data-plen" > > > Typo? > > > > Done > > > > > > > - "OAM applications ("Operations Administration and Management)" > > > > > > Consider using "Operations Administration and Management (OAM) > > applications " instead; same goes for SDN, ASA, VRF, etc... > > > > Ok. Tried to fix up all the instances i could find. > > > > > - " MIC: "Manufacturer Installed Certificate". Another word not used > > in this document to describe an IDevID." > > > > > > MIC is not used in the document, maybe inform of this equivalence in the > > IDevID definition instead; same goes for SUDI. Note that UDI is use just once > > and may not need an entry here. > > > > The definitions of those non-necessary terms are there to help others who > > like me start out not being security experts and are confused about those > > equivalent or related terms. > > > > I specifically didn't want to include discussions about these terms in the > > definitions that are relevant (eg: IDevID) so as not to clobber up that text. > > Instead, readers would just look up those redundant terms when they are like > > me initially confused about them. > > > > > - "RPL: \"IPv6 Routing Protocol for Low-Power and Lossy > > Networks\". The routing protocol used in the ACP." > > > > > > Maybe point on [RFC6550]? > > > > Done > > > > > - "Connecting over non-ACP Layer-3 clouds initially requires a tunnel > > between ACP nodes." > > > > > > I understands that it is one tunnel between each pair of adjacent ACP > > > nodes, correct? I read "a tunnel" as an end-to-end tunnel, which > > > sounds different > > > > Changed to: > > > > Connecting over non-ACP Layer-3 clouds requires explicit configuration. > > See . This may be automated in in the > > future through autodiscovery mechanisms across L3. > > > > > > > - "ACP relies on group security" > > > > > > Add "The" > > > > > > Done > > > > > - "An ACP node MUST have keying > > > material consisting of a certificate (LDevID), with which it can > > > cryptographically assert its membership in the ACP domain and trust > > > anchor(s) associated with that certificate with which it can verify > > > the membership of other nodes (see Section 6.1.2)." > > > > > > This is convoluted. Could you make it 2 sentences? > > > > Fixed to: > > > > The ACP relies on group security. An ACP domain is a group of nodes that > > trust each other to participate in ACP operations. To establish trust, each ACP > > member requires keying material: An ACP node MUST have a certificate > > (LDevID) and a trust anchor (TA) consisting of a certificate (chain) used to sign > > the LDevID of all domain members. The LDevID is used to cryptographically > > assert membership in the ACP domain, the TA to verify the membership of > > other nodes in the ACP domain (see ). > > > > > - " Note: LDevID ("Local Device IDentification") is the term used to > > > indicate a certificate that was provisioned by the owner of a > > > node as opposed to IDevID ("Initial Device IDentifier") that may has > > > been loaded on the node during manufacturing time. Those IDevID do > > > not include owner and deployment specific information to allows > > > autonomic establishment of trust for the operations of an ACP domain (e.g.: > > > between two ACP nodes without relying on any third party)." > > > > > LDevID was already defined in the terminology. This text may move there or > > go away. > > > > Gone. I added the note that LDevID can not be used directly for ACP to the > > terminology definition of IDevID. > > > > > - " This document uses the term ACP in many places where its > > reference > > > document use the word autonomic." > > > > > > Add [RFC7575] after "reference document" > > > > Done. > > > > > - " "routing-subdomain" is the autonomic subdomain that is used to > > > calculate the hash for the ULA prefix of the ACP address of the node." > > > > > > Do you mean ULA suffix? > > > > No, the Global ID. Fixed. > > > > Actually, i also sumbled across this: > > > > RFC4193 uses "Prefix" for the first 7 bits of a ULA address, but we have used > > use the term ULA prefix to refer to the first 48 bits of a ULA address, so i've > > clarified this more in the terminology. > > > > > - " o If the node certificates indicate a CDP (or OCSP) then the peer's > > > certificate must be valid according to those criteria. e.g.: OCSP > > > check across the ACP or not listed in the CRL retrieved from the CDP." > > > > > > Please define CDP and OSCP, and/or reference a RFC is possible. > > > > Done. Using RFC5280. Hope thats correct, otherwise IESG SEC review should > > help. > > > > > - "enrolment" > > > Typo > > > > Fixed. > > > > > - "This can > > > use a single GRASP M_FLOOD message as shown in above example." > > > Actually the example is now below. Please reference the figure. > > > > Done. Actually its still "above", or i am heavily confused. > > > > > > > > - "The protocol could for example could have been" > > > > > > Typo > > > > Fixed. > > > > > - "if the IPsec connecting" > > > > > > Typo? > > > > More like sentence structure was strange. > > > > Fixed to: > > > > "Even if the IPsec connection from Bob succeeded, Alice might prefer another > > secure protocol over IPsec" > > > > > - "ACP wide service discovery" > > > ACP-wide > > > > Fixed. > > > > > - "if the IPsec connecting In most other solution > > > designs such distributed discovery does not exist at all or was added > > > as an afterthought and relied upon inconsistently" > > > > > > Consider removing or rephrasing : ) > > > > Removed: > > > > Sentence wasn't that bad, but easier removed instead of trying to justify > > negative observations about reality without being called out to provide even > > more proof. > > > > > > > > - Maybe consider moving the discussion on multicast P29 -30 to annex? > > Why Multicast is not used is an interesting discussion but not critical for the > > protocol operation. > > > > Done. > > > > > - "it is not quite clear yet what exactly the implications are > > > to make GRASP flooding depend on RPL DODAG convergence and how > > > difficult it would be to let GRASP flooding access the DODAG > > > information" > > > > > > Let's chat then. There's work on reliable multicast for RPL using BIER. > > > > Yeah if i would just get around to that ;-) > > > > For now moved together into informative section together with te multicast > > discus. > > > > > - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the > > > security and transport substrate for the GRASP instance run inside the > > > ACP ("ACP GRASP"). " > > > > > > "running" inside the ACP? Maybe rephrase more globally? > > > > > > > This instance of GRASP runs across the ACP secure channels.. > > > > > - "OAM protocols no not require IPv4: The ACP may carry OAM " > > > Typo no->do > > > > Fixed. > > > > > - "Consider a network that has multiple NOCs in different locations. > > > Only one NOC will become the DODAG root. Other NOCs will have to send > > > traffic through the DODAG (tree) rooted in the primary NOC." > > > > > A figure would help. I remember all the discussions we had about > > > setting the prf bits in remote NOCs > > > > Sorry. A bit low on cycles right now. Hopefully i'll get around to it later. > > Created a wish list entry in changelog. > > > > > - "RPPL." > > > Typo > > > > Fixed. > > > > > - "Administrative Preference ([RFC6552], 3.2.6 " > > > > > > The section is correct but that is RFC 6550. > > > > Done > > > > > > > > - "This is a standard issue > > > with tunneling, not specific to running the ACP across it." > > > Do you really mean Standard or would Classical work better? > > > > This is an issue of tunnels, not an issue of running the ACP across a tunnel. > [PT>] > [PT>] Sure but I was pointing at the word "standard", probably ill-chosen in a standard doc... > > > > > > - "Even though loopback interfaces where originally d" > > > Typo Where -> were > > > > Done. > > > > > - Section 3, 4, 9 and 10 may move to Annex (by moving the section after > > the tag) since they are not normative and do not contribute to > > the understanding of the protocol. This way there should not be a need to > > indicate normative in other sections. > > > > Sections 3, 4 and 9 are fairly short and the flow of the document depends on > > them being in their particular location. > > > > Section 10 could go into an appendix, but it makes not a lot of difference, but > > past experience has shown that Annex text is a lot less likely to be read given > > how the RFCs are structured. > > We had 10 in Annex and moved it up for exactly that reason. > > > > > - Well Noted that Section 14 Will be removed/. > > > > > Sorry for being interrupted here, > > > > > > Thanks you so much! > > > > [PT>] My pleasure, > > Take care; > > Pascal -- --- tte@cs.fau.de From nobody Fri Jun 8 16:22:16 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E644C130DC1 for ; Fri, 8 Jun 2018 16:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PLING_QUERY=0.994, 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 8gPa7QMRQo93 for ; Fri, 8 Jun 2018 16:22:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284CC126F72 for ; Fri, 8 Jun 2018 16:22:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E0AF658C4B3; Sat, 9 Jun 2018 01:22:04 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CF4304401A4; Sat, 9 Jun 2018 01:22:04 +0200 (CEST) Date: Sat, 9 Jun 2018 01:22:04 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20180608232204.smrebigbgthk4s72@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Top of stack ?! draft-ietf-anima-autonomic-control-plane-16.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:22:15 -0000 I hope i have answered/incooperated all outstanding reviews with just posted -16 (and wednesdays revision -15). I could not find an email leading to Deborah Brungard's IESG comments (just saw them on datatracker), so i didn't respond to it directly, but her feedback just reiterated Mirjas and other reviewers suggestion to move stuff into appendix which was done for chapter 11 in revision -16. If there is any other feedback i overlooked, please let me know Thank you so much for all the great feedback. Cheers Toerless On Fri, Jun 08, 2018 at 03:52:42PM -0700, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-ietf-anima-autonomic-control-plane-16.txt > has been successfully submitted by Toerless Eckert and posted to the > IETF repository. > > Name: draft-ietf-anima-autonomic-control-plane > Revision: 16 > Title: An Autonomic Control Plane (ACP) > Document date: 2018-06-08 > Group: anima > Pages: 133 > URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-autonomic-control-plane-16.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > Htmlized: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-16 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-16 > > Abstract: > Autonomic functions need a control plane to communicate, which > depends on some addressing and routing. This Autonomic Management > and Control Plane should ideally be self-managing, and as independent > as possible of configuration. This document defines such a plane and > calls it the "Autonomic Control Plane", with the primary use as a > control plane for autonomic functions. It also serves as a "virtual > out-of-band channel" for Operations Administration and Management > (OAM) communications over a network that is secure and reliable even > when the network is not configured, or misconfigured. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Fri Jun 8 16:47:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E8130DE0; Fri, 8 Jun 2018 16:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZktgR7QUhUp8; Fri, 8 Jun 2018 16:47:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86EE130DC0; Fri, 8 Jun 2018 16:47:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C90BF400A74; Fri, 8 Jun 2018 16:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1528501640; bh=/e3WBU964clZ95x6CEoHV6vjjOg8OuFIkDJ+22Omvr8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TaZmqevDc+5GxEwYsH+36CpAI2jCBY1ONtQpitr5f5kDp8V+HI6uHH8HnfvuF/u5f d9p1SuPnKYLw8CjbUXZqxe46H0/8OdRG72KrcLf+gYfGp5wA/LrX7MymLoYacCgmOp kaLIt69ibaGmTohLAxVv7m0O9fiwwEqH4MLfyIgs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id AA27D400B49; Fri, 8 Jun 2018 16:47:19 -0700 (PDT) To: Toerless Eckert Cc: rtg-dir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org References: <20180608230416.jy4xjp7smqm444tc@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: Date: Fri, 8 Jun 2018 19:47:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180608230416.jy4xjp7smqm444tc@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:47:25 -0000 Thank you. Those fixes make sense. You might want to talk to a DNS expert about what the right terminology is for what youa re trying to achieve with the rsub content. I think I understand it, and I think it is reasonable. And I am insufficiently expert to tell what the right formalism is for it (thinks have evolved since 1034.) Net: good enough for me. Yours, Joel On 6/8/18 7:04 PM, Toerless Eckert wrote: > Thanks, Joel > > Replies Inline > > Changes for feedback from Mirja, Kumar and Joel committed to -16, > didn't create separate diff for individual reviewers as diff is not large. > (Just ignore whole section 11 moved to appendix in diff.) > > https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt > > http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt > > Cheers > Toerless > > On Thu, Jun 07, 2018 at 05:09:37PM -0400, Joel M. Halpern wrote: >> Thank you for all your work on this. >> >> While I still find the presence of the address allocation mechanism strange >> to find in this document, I can live with it. >> So with this complaint done, I will shut up about it already. > > Thanks. Lets take it offline. I am still interested to understand that > point, especially after the text i added in the hope to clear this concern. > > Answers inline. > > Thanks > Toerless > >> Aside from some items noted below, this seems to be in good shape. >> >> Moderate: >> >> Section 10.3.4 has a helpful discussion of some of the complexities of >> determining where to auto-enable the ACP. I am a bit surprised not to see >> some discussion of which VLANs to enable for ACP in an Ethernet environment. > > Thats a topic better to be discussed in followup work. Cisco IOS ACP > implementation does support automatic VLAN discovery & selection. > Lot of experience/insight from that. Trust me, it would be scope creep > for the ACP document itself. > >> For WDM< since wavelength usage is configured, I presume that ACP would >> never try to auto-enable a frequency band? > > Right. Given the experience with VLANs, the clean cut we could make > for this basic ACP specification is to logically sit on top of > IPv6 subnet interfaces, ignore all L2/L1 complexities > and live with the dependency against IPv6 being able to bring up > link-local-scope reachability to neighbors. [ And then write followup > docs if/when we ever get this first doc out as an RFC ;-) ] > > The way i would imagine WDM is a bit more like ethernet switches in section 7 > though: You'd want to get ACP connectivity across your optical equipment > and also be able to reach through the ACP your optical equipment, but > that would not use special colors, but more likely should be added > to / leverage the existing in-band management channels of the optical > equipment. Long discussion. Let me rather stop. > >> Minor comments: >> In section 6.1.1 the text and the ABNF says that an rsub is a full domain >> (using the same domain-name construct as the "domain" which is an FQDN. >> However, the example shows a partial domain string which is concatenated >> with the "domain" to produce an FQDN. And the syntqx of "routing-subdomain" >> shows that concatenation. This suggests that the text needs to be clear as >> to what the syntactic content of the rsub field is. > > Hmm... RFC1034 does not even mention the term "fully qualified (domain name)" / FQDN, > You seem to read RFC1034 3.5 to mean that all domain are FQDN, but that is > not clear to me. In the RR examples of RFC1034, FQDNs are identified by ending > with a ".", which AFAIK is the standard for FQDN,but the 3.5 syntax doesn't > even allow you to create such an FQDN, so i was thinking that 3.5 "domain" > do not have to be FQDNs, and therefore i am assuming that is is also perfectly > legal to use a syntax of domain3 = domain2 . domain1, > as in routing-subdomain = rsub . domain-domain-name. > >> Might it be better not >> to define it as a "domain-name" but to define it as FFS, with a caveat that >> whatever usage is later defined needs to be suitable for combining with the >> "domain" for generating the hash for the ULA Global ID? > > Well, it does have to be some RFC822-local-part-FFS, but i think its a > lot better if its constrained to the domain name syntax, because it is > quite normal operations to have for every actual routing subdomain in the > network also some associated domain name, and that is what "routing-subdomain" > is. > > So if i build a parser for configuring my segmented routing with the ACP, > its a lot more logical to allow only longer domain names for > routing-subdomain that all have the same parent domain (domain). > >> Just to be clear, as written the text seems to end up with >> where is from RFC 1034. > > Right. See above. > > I tried to figure out how to unconfuse this. > > I changed "domain" to "acp-domain-name", so that its not confused > with RFC1034 "domain", eliminated "domain-name", and also changed > the definition of rsub to use RFC1034 "subdomain" instead of "domain", > even though i can for the heck of it not figure out what the difference > between domain and subdomain is, except that a domain can be " ", > which seems to be the domain root, but its not really defined. > But at least it should hopefully eliminate the misconception that rsub > has to be an FQDN. > >> Section 6.1.2 bullet one states that "The peer certificate is valid as >> proven by the security association protocol exchange." I may be >> overstepping my knowledge, but I think there are two different things. First >> is the certificate validity, which is an internal property of the >> certificate. The second is the certficate applicability which may be >> informed by the protocol exchange. > > Good catch. Fixed as follows: > > The following points constitute the ACP domain membership check of a possible peer certificate, independent of the protocol used: > The peer certificate is valid (lifetime). > The peer has proved ownership of the private key associated with the certifictes public key. > >> Related to that, please put in a reference to which protocol exchange >> you mean? > > No, the goal is to define this independent of protocol. > > >> Either there is a document inconsistency, or there is a typo in the >> first paragraph of section 6.10.7.3, in that the address prefix length for >> the zone address sub-scheme is /127, not /126. >> >> >> Yours, >> Joel > From nobody Fri Jun 8 17:41:20 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D6D130FED for ; Fri, 8 Jun 2018 17:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 JeI3zsfo0RPa for ; Fri, 8 Jun 2018 17:41:12 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 92E581277C8 for ; Fri, 8 Jun 2018 17:41:08 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id d2-v6so14902317wrm.10 for ; Fri, 08 Jun 2018 17:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fzrb+HpjGYln5vVEpFryE08CQoyRTuW+XNabIicCqag=; b=j/RNkxlTsRgLwyR4eXibIyGB9ksXgUXxHI49zhRjFEBPeImgPlDxE3b4cJCPASWx1G XFb6Zz1PNJ5r7wQ4Ob3bgxsXI+U+bv0RR9Od/9LXLaNlcpVtDuPIQX+pQXQ7L9F+esBf IShXk2AotpcvMsPLiKFQQuEFxqeD4hoPAr+6LWWCtEnF4KZa9Tz9UhuMUHvwhqZ9RdPs TVi8XeWeT7Pp9OWX8M2yTVnf+9yxZ4ZSavSZAWnzD99O+h79Rc+zKNptq4C9+lvaNmTU ZF/EXnPKOlX9vpbXhv8/leTG8AtkK8b9uWSpFN3zmxtu/3/8ww75YJnJZnTs0LY2T52f bx/A== 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:cc; bh=fzrb+HpjGYln5vVEpFryE08CQoyRTuW+XNabIicCqag=; b=UwTB56FXZUf8x9d1pyvemuFQQPQoHbZZHxSZakFsnvdzyKCftHCvUvY9rVpt3rt5rE 83j2/ywNV1ahZUONUfSTOYWxubnzX+hmi0FF7VvfiBvj7xDnGIY8DERHmlok/kQ06AoU 3jQd4g/0Rs1DzxhlmCYDS1C9Z/1FmdWulyocOO4Imyy+vJ0jQXQBByFUeCVnp51QnZuQ aCsyVhGG3vF0mtv6gursTKpyJ6ih/EymqcvDlb5in/yDGQJEqvM1yMsmXdOIKnBnofq6 PhDgGvAWkrYF1JqLAmPfI1V1EFUUAWeg/sW69IpPr442RHKL36HHXYE3bjaAwhTIszox sXLA== X-Gm-Message-State: APt69E3UsPU2kZG8QlpL16CIZjcTGiB49fpp9LyaOFNcaPAj59L0gOzd i835c2jEJyV2OrdhBY8dYQooxLzv16anmrB8EAWCaw== X-Google-Smtp-Source: ADUXVKJ1AcCS5yuUKsSqsOWrOwjUxCIS4qlWxGb9MR8Fu37fow4DiJWsj3DEoVarV+Fmd1+UuoLEbI2vpgfCu+JsgM0= X-Received: by 2002:adf:ba01:: with SMTP id o1-v6mr6870691wrg.249.1528504866628; Fri, 08 Jun 2018 17:41:06 -0700 (PDT) MIME-Version: 1.0 References: <152830654814.6366.4951842776897034198.idtracker@ietfa.amsl.com> <20180608230323.gkrqf56okfqrl5cl@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180608230323.gkrqf56okfqrl5cl@faui48f.informatik.uni-erlangen.de> From: Warren Kumari Date: Fri, 8 Jun 2018 20:40:30 -0400 Message-ID: To: Toerless Eckert Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, jiangsheng@huawei.com, anima-chairs@ietf.org, anima@ietf.org Content-Type: multipart/alternative; boundary="0000000000009cfadf056e2ac597" Archived-At: Subject: Re: [Anima] Warren Kumari's Discuss on draft-ietf-anima-autonomic-control-plane-13: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 00:41:15 -0000 --0000000000009cfadf056e2ac597 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 8, 2018 at 7:03 PM Toerless Eckert wrote: > Thanks a lot Warren, great suggestions. > > =E2=80=8BAnd thanks for addressing -- I just cleared my DISCUSS. W=E2=80=8B > Replies inline > > Changes for feedback from Mirja, Kumar and Joel committed to -16, > didn't create separate diff for individual reviewers as diff is not large= . > (Just ignore whole section 11 moved to appendix in diff.) > > https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt > > > http://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-iet= f-anima-autonomic-control-plane-15.txt&url2=3Dhttps://tools.ietf.org/id/dra= ft-ietf-anima-autonomic-control-plane-16.txt > > Cheers > Toerless > > On Wed, Jun 06, 2018 at 10:35:48AM -0700, Warren Kumari wrote: > > Warren Kumari has entered the following ballot position for > > draft-ietf-anima-autonomic-control-plane-13: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane= / > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I'm balloting DISCUSS, but I think that this should be relatively simpl= e > to > > address: The document says things like:"Today, the management and > control plane > > of networks typically runs in the global routing table, which is > dependent on > > correct configuration and routing." and "Context separation improves > security, > > because the ACP is not > > reachable from the global routing table. " > > > > The term "global routing table" is widely used and understood to mean t= he > > global BGP routing table, or Internet global routing table. I understan= d > that > > you are using it in the "default VRF" meaning, but I think that it is > really > > important to clarify / disambiguate this the first time you use it. > > Good catch. The use of "global routing table" seems to be almost a day 1 > text issue of the doc ;-( > > We can't use VRF to explain it, because we are not referring to > VRFs in the data-plane anymore for those devices that do not have VRFs. > (reviewer request) Only ACP VRF is defined and used as a term. > > I removed all uses of "global routing" (table), and just refer to > "Data-Plane routing (and forwarding, where appropriate) tables": > > | Today, the management and control plane of networks typically uses a > routing and forwarding table which is dependent on correct configuration > and routing > > | For management plane protocols, the ACP provides the functionality of a > Virtual out of Band (VooB) channel, by providing connectivity to all node= s > regardless of their Data-Plane configuration, routing and forwarding tabl= es. > > | Context separation improves security, because the ACP is not reachable > from the Data Plane routing or forwarding table(s). > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you very much for writing this document -- it is comprehensive... > > > > A rich text version of my review is here: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3801#inline-4146 , and > pasted below > > for tooling, email, etc. > > > > --- > > draft-ietf-anima-autonomic-control-plane.txt:212 > > network nodes that is not the ACP, and therefore considered to be > > dependent on (mis-)configuration. This data-plen includes both the > > traditional forwarding-plane, as well as any pre-existing control- > > Nit: data-plane > > Done. > > > > draft-ietf-anima-autonomic-control-plane.txt:508 > > certificate. This does not require any configuration on intermediat= e > > nodes, because they can communicate zero-touch and securely through > > the ACP. > > I understand what you are trying to say, but "zero-touch" is not an > adverb. > > Took the opportunity fix also some semantics of the paragraph. > > With the ACP, secure bootstrap of new devices and whole new networks > can happen without requiring any configuration of unconfigured device alo= ng > the path: As long as all devices along the path support ACP and a > zero-touch bootstrap mechanism like BRSKI, the ACP across a whole network > of unconfigured devices can be brought up without operator/provisioning > intervention. The ACP also provides additional security for any bootstrap > mechanism, because it encrypts the traffic along the path hop-by-hop. > > > > > draft-ietf-anima-autonomic-control-plane.txt:518 > > the data-plane is operational, will the other planes work as > > expected. > > This is *sometimes* an undesirable dependency, but is usually viewed as= a > > feature (by operational people) -- having the control plane share fate > with the > > dataplane is something that is usually a feature - this drives at least > part of > > the reason that many organizations run OSPF and OSPFv3 - having V4 OSPF > relying > > on v4 dataplane avoids blackholes if the v4 dataplane stops working. > (This is > > sometimes, but less often used as an argument against ISIS). > > > > I understand why it is useful in this context, but it would be useful t= o > > clarify/make it clear that you understand the subtleties. > > Added paragraph: > > Note that specific control plane functions for the Data-Plane often > want to depend on forwarding of their packets via the Data-Plane: Alivene= ss > and routing protocol signaling packets across the Data-Plane to verify > reachability across the Data-Plane, using IPv4 signaling packets for IPv4 > routing vs. IPv6 signaling packets for IPv6 routing. > > > Also, nit: "is operational, will the" -- the comma feel weird here. > > Removed > > > draft-ietf-anima-autonomic-control-plane.txt:526 > > management session is running can lock an admin irreversibly out of > > the device. Traditionally only console access can help recover from > > such issues. > > "only console access or OOB". > > > > You may be using "console access" to mean OOB, but much (most?) OOB is > now not > > console based. > > Changed to: > > > Traditionally only out-of-band access can help recover from such issues > (such as serial console or ethernet management port) > > Mileage for ethernet based OOB does vary i think. Probably on DC and > core/distribution SP gear. Not the typical enterprise gear yet, i think. > > > draft-ietf-anima-autonomic-control-plane.txt:531 > > Operations Center") such as SDN controller applications: Certain > > network changes are today hard to operate, because the change itself > > may affect reachability of the devices. Examples are address or mas= k > > I think that this was an editing issue -- you don't "operate" changes. > Perhaps > > "implement"? > > Good suggestion. Fixed. > > > draft-ietf-anima-autonomic-control-plane.txt:858 > > o If the node certificates indicate a CDP (or OCSP) then the peer's > > certificate must be valid according to those criteria. e.g.: OCSP > > You expand CDP further in the document, but this is the first time it i= s > used. > > Expansion of terms was introduced in -14. > > > draft-ietf-anima-autonomic-control-plane.txt:994 > > ACP neighbors. Native interfaces (e.g.: physical interfaces on > > physical nodes) SHOULD be brought up automatically enough so that AC= P > > discovery can be performed and any native interfaces with ACP > > I don't have a suggestion, but "automatically enough" doesn't sound > right - > > "automatically configured enough" ? > > Fixed to: > SHOULD be initialized automatically to a state in which ACP discovery can > be performed > > > draft-ietf-anima-autonomic-control-plane.txt:1067 > > In the above (recommended) example the period of sending of the > > objective could be 60 seconds the indicated ttl of 180000 msec means > > that the objective would be cached by ACP nodes even when two out of > > Editing fail -- missing some punctuation or words. > > Fixed in -14. > > > draft-ietf-anima-autonomic-control-plane.txt:1933 > > for reachability. The use of the autonomic control plane specific > > context eliminates the probable clash with the global routing table > > and also secures the ACP from interference from the configuration > > IMPORTANT: The term "global routing table" has a well known meaning in > > operations -- it is the global BGP table. I strongly suggest using a > different > > term, or having a very clear statement in the terminology section, AND > the > > first time you use it in the document. This will help minimize confusio= n. > > Done. See Discuss section. > > > draft-ietf-anima-autonomic-control-plane.txt:3081 > > 10.2. ACP (and BRSKI) Diagnostics > > Just a note that I like / appreciate this section - having guidance on > how to > > troubleshoot is very helpful. > > Thanks. > > > draft-ietf-anima-autonomic-control-plane.txt:3416 > > 10.3.2.2. Fast state propagation and Diagnostics > > > > "Physical down" state propagates on many interface types (e.g.: > > When I saw the "physically brought down" I started composing a long > soapbox > > rant on the fact that this will slow down state propagation -- I like > that that > > document anticipates and addresses this. It might be useful to have a > pointer > > in the previous section (like "(see below)" or similar.) > > First paragraph of previous chapter (admin-down) had (see below), > now addd xref: (see below, = ) > > > draft-ietf-anima-autonomic-control-plane.txt:3482 > > for 5 seconds to probe if there is an ACP neighbor on the remote end > > every 500 seconds =3D 1% power consumption. > > I believe that this is sufficiently incorrect that you should remove th= e > 1% > > result (or, better yet the whole last sentence). > > > > Various interfaces (especially long reach) take a significant amount of > time > > (and additional power) when bringing up interfaces -- things like DWDM > optics > > and amplifiers sometimes need significant power for heating elements to > lock > > the frequency / wavelength, and so the power consumption is not linear > with > > interface uptime. > > fixed to: > > Power consumption of "physical down" interfaces may be significantly > lower than those in "admin down" state, for example on long range fiber > interfaces. Bringing up interfaces, for example to probe reachabiliy, may > also consume additional power. This can make these type of interfaces > inappropriate to operate purely for the ACP when > they are not currently needed for the Data-Plane. > > Joel Halpern also asked about DWDM. I'll refrain from trying to add more > details here how this situation could othrewise be mitigated, i just > wanted to highlight understood key aspects, not necessarily all solutions= . > > --=20 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 --0000000000009cfadf056e2ac597 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fr= i, Jun 8, 2018 at 7:03 PM Toerless Eckert <tte@cs.fau.de> wrote:
Th= anks a lot Warren, great suggestions.


=E2=80=8BAnd thanks for addressing -- I jus= t cleared my DISCUSS.
W=E2=80=8B

=C2=A0
Replies inline

Changes for feedback from Mirja, Kumar and Joel committed to -16,
didn't create separate diff for individual reviewers as diff is not lar= ge.
(Just ignore whole section 11 moved to appendix in diff.)

https://tools.ietf.org/id/d= raft-ietf-anima-autonomic-control-plane-16.txt

http://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ie= tf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt&url2=3Dhttps:= //tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt

Cheers
=C2=A0 =C2=A0 Toerless

On Wed, Jun 06, 2018 at 10:35:48AM -0700, Warren Kumari wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-anima-autonomic-control-plane-13: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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.i= etf.org/doc/draft-ietf-anima-autonomic-control-plane/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I'm balloting DISCUSS, but I think that this should be relatively = simple to
> address: The document says things like:"Today, the management and= control plane
> of networks typically runs in the global routing table, which is depen= dent on
> correct configuration and routing." and "Context separation = improves security,
> because the ACP is not
>=C2=A0 =C2=A0 reachable from the global routing table. "
>
> The term "global routing table" is widely used and understoo= d to mean the
> global BGP routing table, or Internet global routing table. I understa= nd that
> you are using it in the "default VRF" meaning, but I think t= hat it is really
> important to clarify / disambiguate this the first time you use it.
Good catch. The use of "global routing table" seems to be almost = a day 1
text issue of the doc ;-(

We can't use VRF to explain it, because we are not referring to
VRFs in the data-plane anymore for those devices that do not have VRFs.
(reviewer request) Only ACP VRF is defined and used as a term.

I removed all uses of "global routing" (table), and just refer to=
"Data-Plane routing (and forwarding, where appropriate) tables":<= br>
| Today, the management and control plane of networks typically uses a rout= ing and forwarding table which is dependent on correct configuration and ro= uting

| For management plane protocols, the ACP provides the functionality of a V= irtual out of Band (VooB) channel, by providing connectivity to all nodes r= egardless of their Data-Plane configuration, routing and forwarding tables.=

| Context separation improves security, because the ACP is not reachable fr= om the Data Plane routing or forwarding table(s).

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Thank you very much for writing this document -- it is comprehensive..= .
>
> A rich text version of my review is here:
> https://mozphab-ietf.devsvcdev.mozaw= s.net/D3801#inline-4146 , and pasted below
> for tooling, email, etc.
>
> ---
> draft-ietf-anima-autonomic-control-plane.txt:212
>=C2=A0 =C2=A0 network nodes that is not the ACP, and therefore consider= ed to be
>=C2=A0 =C2=A0 dependent on (mis-)configuration.=C2=A0 This data-plen in= cludes both the
>=C2=A0 =C2=A0 traditional forwarding-plane, as well as any pre-existing= control-
> Nit: data-plane

Done.


> draft-ietf-anima-autonomic-control-plane.txt:508
>=C2=A0 =C2=A0 certificate.=C2=A0 This does not require any configuratio= n on intermediate
>=C2=A0 =C2=A0 nodes, because they can communicate zero-touch and secure= ly through
>=C2=A0 =C2=A0 the ACP.
> I understand what you are trying to say, but "zero-touch" is= not an adverb.

Took the opportunity fix also some semantics of the paragraph.

=C2=A0<t>With the ACP, secure bootstrap of new devices and whole new = networks can happen without requiring any configuration of unconfigured dev= ice along the path: As long as all devices along the path support ACP and a= zero-touch bootstrap mechanism like BRSKI, the ACP across a whole network = of unconfigured devices can be brought up without operator/provisioning int= ervention. The ACP also provides additional security for any bootstrap mech= anism, because it encrypts the traffic along the path hop-by-hop.</t>=

>
> draft-ietf-anima-autonomic-control-plane.txt:518
>=C2=A0 =C2=A0 the data-plane is operational, will the other planes work= as
>=C2=A0 =C2=A0 expected.
> This is *sometimes* an undesirable dependency, but is usually viewed a= s a
> feature (by operational people) -- having the control plane share fate= with the
> dataplane is something that is usually a feature - this drives at leas= t part of
> the reason that many organizations run OSPF and OSPFv3 - having V4 OSP= F relying
> on v4 dataplane avoids blackholes if the v4 dataplane stops working. (= This is
> sometimes, but less often used as an argument against ISIS).
>
> I understand why it is useful in this context, but it would be useful = to
> clarify/make it clear that you understand the subtleties.

Added paragraph:

<t>Note that specific control plane functions for the Data-Plane ofte= n want to depend on forwarding of their packets via the Data-Plane: Alivene= ss and routing protocol signaling packets across the Data-Plane to verify r= eachability across the Data-Plane, using IPv4 signaling packets for IPv4 ro= uting vs. IPv6 signaling packets for IPv6 routing.</t>

> Also, nit: "is operational, will the" -- the comma feel weir= d here.

Removed

> draft-ietf-anima-autonomic-control-plane.txt:526
>=C2=A0 =C2=A0 management session is running can lock an admin irreversi= bly out of
>=C2=A0 =C2=A0 the device.=C2=A0 Traditionally only console access can h= elp recover from
>=C2=A0 =C2=A0 such issues.
> "only console access or OOB".
>
> You may be using "console access" to mean OOB, but much (mos= t?) OOB is now not
> console based.

Changed to:

> Traditionally only out-of-band access can help recover from such issue= s (such as serial console or ethernet management port)

Mileage for ethernet based OOB does vary i think. Probably on DC and
core/distribution SP gear. Not the typical enterprise gear yet, i think.
> draft-ietf-anima-autonomic-control-plane.txt:531
>=C2=A0 =C2=A0 Operations Center") such as SDN controller applicati= ons: Certain
>=C2=A0 =C2=A0 network changes are today hard to operate, because the ch= ange itself
>=C2=A0 =C2=A0 may affect reachability of the devices.=C2=A0 Examples ar= e address or mask
> I think that this was an editing issue -- you don't "operate&= quot; changes. Perhaps
> "implement"?

Good suggestion. Fixed.

> draft-ietf-anima-autonomic-control-plane.txt:858
>=C2=A0 =C2=A0 o=C2=A0 If the node certificates indicate a CDP (or OCSP)= then the peer's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0certificate must be valid according to those= criteria. e.g.: OCSP
> You expand CDP further in the document, but this is the first time it = is used.

Expansion of terms was introduced in -14.

> draft-ietf-anima-autonomic-control-plane.txt:994
>=C2=A0 =C2=A0 ACP neighbors.=C2=A0 Native interfaces (e.g.: physical in= terfaces on
>=C2=A0 =C2=A0 physical nodes) SHOULD be brought up automatically enough= so that ACP
>=C2=A0 =C2=A0 discovery can be performed and any native interfaces with= ACP
> I don't have a suggestion, but "automatically enough" do= esn't sound right -
> "automatically configured enough" ?

Fixed to:
SHOULD be initialized automatically to a state in which ACP discovery can b= e performed

> draft-ietf-anima-autonomic-control-plane.txt:1067
>=C2=A0 =C2=A0 In the above (recommended) example the period of sending = of the
>=C2=A0 =C2=A0 objective could be 60 seconds the indicated ttl of 180000= msec means
>=C2=A0 =C2=A0 that the objective would be cached by ACP nodes even when= two out of
> Editing fail -- missing some punctuation or words.

Fixed in -14.

> draft-ietf-anima-autonomic-control-plane.txt:1933
>=C2=A0 =C2=A0 for reachability.=C2=A0 The use of the autonomic control = plane specific
>=C2=A0 =C2=A0 context eliminates the probable clash with the global rou= ting table
>=C2=A0 =C2=A0 and also secures the ACP from interference from the confi= guration
> IMPORTANT: The term "global routing table" has a well known = meaning in
> operations -- it is the global BGP table. I strongly suggest using a d= ifferent
> term, or having a very clear statement in the terminology section, AND= the
> first time you use it in the document. This will help minimize confusi= on.

Done. See Discuss section.

> draft-ietf-anima-autonomic-control-plane.txt:3081
> 10.2.=C2=A0 ACP (and BRSKI) Diagnostics
> Just a note that I like / appreciate this section - having guidance on= how to
> troubleshoot is very helpful.

Thanks.

> draft-ietf-anima-autonomic-control-plane.txt:3416
> 10.3.2.2.=C2=A0 Fast state propagation and Diagnostics
>
>=C2=A0 =C2=A0 "Physical down" state propagates on many interf= ace types (e.g.:
> When I saw the "physically brought down" I started composing= a long soapbox
> rant on the fact that this will slow down state propagation -- I like = that that
> document anticipates and addresses this. It might be useful to have a = pointer
> in the previous section (like "(see below)" or similar.)

First paragraph of previous chapter (admin-down) had (see below),
now addd xref: (see below, <xref target=3D"down-fast-state-propagat= ion"/>)

> draft-ietf-anima-autonomic-control-plane.txt:3482
>=C2=A0 =C2=A0 for 5 seconds to probe if there is an ACP neighbor on the= remote end
>=C2=A0 =C2=A0 every 500 seconds =3D 1% power consumption.
> I believe that this is sufficiently incorrect that you should remove t= he 1%
> result (or, better yet the whole last sentence).
>
> Various interfaces (especially long reach) take a significant amount o= f time
> (and additional power) when bringing up interfaces -- things like DWDM= optics
> and amplifiers sometimes need significant power for heating elements t= o lock
> the frequency / wavelength, and so the power consumption is not linear= with
> interface uptime.

fixed to:

<t>Power consumption of "physical down" interfaces may be s= ignificantly lower than those in "admin down" state, for example = on long range fiber interfaces. Bringing up interfaces, for example to prob= e reachabiliy, may also consume additional power. This can make these type = of interfaces inappropriate to operate purely for the ACP when=C2=A0
they are not currently needed for the Data-Plane.</t>

Joel Halpern also asked about DWDM. I'll refrain from trying to add mor= e
details here how this situation could othrewise be mitigated, i just
wanted to highlight understood key aspects, not necessarily all solutions.<= br>


--
I don't t= hink the execution is relevant when it was obviously a bad idea in the firs= t place.
This is like putting rabid weasels in your pants, and later exp= ressing regret at having chosen those particular rabid weasels and that pai= r of pants.
=C2=A0 =C2=A0---maf
--0000000000009cfadf056e2ac597-- From nobody Sun Jun 10 22:56:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B39130F1D for ; Sun, 10 Jun 2018 22:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7E75LdUr4ll for ; Sun, 10 Jun 2018 22:56:21 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782FE130EE6 for ; Sun, 10 Jun 2018 22:56:21 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id m5-v6so9207559pgd.3 for ; Sun, 10 Jun 2018 22:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/P+O/1htoz7Z8zvTNKuN4ZjMnbo7h0gxIK3AIvmq7CY=; b=VaFqif8Qy5SdQSvxNxjfXLpZiYuGP0UzIKI7nRrWoUBPiOm13gswSWu8AweW8s4vos xXY+GbMF+rBuMAQrXVO9C5hao5W1vS9lOC+Yw1uRS+MGJNhziKizuuokIjzAxsL9qo2a Q/fQas/2MXhdOIxGihfc6BtyaTr3QBu7y4fwevV8TslEXYTtVWwxf4Zas1CsROrNIjiN FArF7DO1Y+qq/mZNVk5dV1FHWQQWtW1fvZPDgQIcLqrr6b76afrcxoNN9s4INhFPSRvB 0SK0iNQuD3bDBxEAeKmgGxHqv+RWVDKNWGOYklptgReMA1nk6RSUcDOihY1XwJP6jcgt 46JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/P+O/1htoz7Z8zvTNKuN4ZjMnbo7h0gxIK3AIvmq7CY=; b=mozyo3zjy/9D4wpy3F2hBMLHKbUVM1WiPKPfNJIAsy0ZuYrjJ5p+uHLOHwP8LvL+Ym qs74tAYpOUMGLmN3B/ItPHJ2C6IAorjRAIpdqlq9kDB28HTPPdRWN+Cw2h2j95Fplj81 IabkXRxllKzqr8OtpoVDPNnADBCWpST2EXfyTKMma3oo+gg7pKH8ExW15fWo//Dr4YuU pyg75Pb0WecbIVNdj4HRL24zHpjD+KYQWkLE4YnYCxpS1zoXjXkvoRIHhg5Hg+ESjNYz 1LyNRX4NScfmBrY3CqL2rfIDCisz7ixqvIKmh4GMDpOltz9BFgpdh6TCR+Ln0Xulr1X8 VKTg== X-Gm-Message-State: APt69E387LN3cptyJNG076oLFe7WPBAs47M4NUozrNoo5WkhnZY2wHQV smiYw8P3/zg3QyKRL507/wF7aA== X-Google-Smtp-Source: ADUXVKJueUfanculxkwwGvQzNekgzs1TXYojE6NglJjZuQlkOuBoXysfiwMcbaoZzhudG+8u7jEfaA== X-Received: by 2002:a63:8c10:: with SMTP id m16-v6mr13846405pgd.120.1528696581022; Sun, 10 Jun 2018 22:56:21 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id n72-v6sm20880553pfj.68.2018.06.10.22.56.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jun 2018 22:56:19 -0700 (PDT) References: <152869295982.31953.14788689794273532958@ietfa.amsl.com> To: Anima WG Cc: Sheng Jiang From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <152869295982.31953.14788689794273532958@ietfa.amsl.com> Message-ID: Date: Mon, 11 Jun 2018 17:24:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152869295982.31953.14788689794273532958@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] FYI: I-D Action: draft-carpenter-limited-domains-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 05:56:24 -0000 Hi, Sheng and I have posted this draft, which is *not* addressed to ANIMA in particular. However, it seems relevant here, because ANIMA does depend heavily on a badly defined concept - the autonomic domain and its boundary. All comments welcome; off-list is probably better. If there is enough interest, we will request a special mailing list. Regards Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-limited-domains-00.txt Date: Sun, 10 Jun 2018 21:55:59 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limited Domains and Internet Protocols Authors : Brian Carpenter Sheng Jiang Filename : draft-carpenter-limited-domains-00.txt Pages : 12 Date : 2018-06-10 Abstract: There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions. It shows the needs for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-limited-domains-00 https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jun 11 02:55:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBC2130E1C; Mon, 11 Jun 2018 02:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 0Si78scMG6WP; Mon, 11 Jun 2018 02:55:49 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B53130DCB; Mon, 11 Jun 2018 02:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29091; q=dns/txt; s=iport; t=1528710949; x=1529920549; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4GjARkb7/Yhqj23ylTSTeamwq2RAZ8Ax8ZvC2lOZyGs=; b=QMcKzLUV92TZS/7KOny0mqS1Dm/CF7zrM76GohgB5qq4noMzGI/0cgS6 kTSSLH1s1JrYfSGQP6Zn0Fgn18zvZUWDNr3MdXfSJeJWDOF9TlCCtDgs2 afB5p08HyPv0E3X0BEw+MXlT/5P1HDIF8am0E9SAWOX9ciuqosKyMJ1S1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAABoRh5b/4kNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMZKmJ/KAqLcYxkgX51k14UgWQLI4RJAoJeITQYAQIBAQE?= =?us-ascii?q?BAQECbRwMhSgBAQEDARoNEzEDCwwEAgEIDgMEAQEBHhAyHQgBAQQOBQgTgwm?= =?us-ascii?q?BdwgPqkEziD6BaIcYgSyBVD+BD4ERfUk1gxEBAQIBF4EOBRcEhW0ChysXChG?= =?us-ascii?q?EV4EjiyUJAoVtcIgHgUZBgzqCZYUKigeHAwIREwGBJB04YXFwFRohgjMBDwm?= =?us-ascii?q?CFwEXegECgkiBY4MxhT5vAQGOSSqBBIEaAQE?= X-IronPort-AV: E=Sophos;i="5.49,501,1520899200"; d="scan'208";a="127344269" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2018 09:55:47 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w5B9tl3O026551 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jun 2018 09:55:47 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Jun 2018 04:55:47 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 11 Jun 2018 04:55:46 -0500 From: "Pascal Thubert (pthubert)" To: Toerless Eckert CC: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Thread-Topic: An IOT DIR review of draft-ietf-anima-autonomic-control-plane Thread-Index: AdOnCBzSJMKw+zXyQYGzXbZB1JtadhBRtloAAmD3rMADdWN0AABv+pHw Date: Mon, 11 Jun 2018 09:55:29 +0000 Deferred-Delivery: Mon, 11 Jun 2018 09:54:44 +0000 Message-ID: References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> <20180608231440.maxyvrcam5yt5ttm@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180608231440.maxyvrcam5yt5ttm@faui48f.informatik.uni-erlangen.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 09:55:54 -0000 Dear Toerless and authors: I reviewed -16 and I'm happy with the changes made for my comments. All set= on my side. I noted that item 2 in the Introduction has a ref that opens a bracket that= does not close; this creates a presentation issue on the htmlized version. > -----Original Message----- > From: Toerless Eckert > Sent: samedi 9 juin 2018 01:15 > To: Pascal Thubert (pthubert) > Cc: iot-dir ; ops-dir@ietf.org; int-dir@ietf.org; > anima@ietf.org; draft-ietf-anima-autonomic-control-plane@ietf.org > Subject: Re: An IOT DIR review of draft-ietf-anima-autonomic-control-plan= e >=20 > Thanks, pascal. the "standard (issue)" got fixed too in -14, forgot to in= clude a > specific note to you. >=20 > Cheers > Toerless >=20 > On Tue, May 22, 2018 at 02:06:17PM +0000, Pascal Thubert (pthubert) wrote= : > > Hello Toerless: > > > > > > Thanks, Pascal, sorry for the delay, > > > > > > Comments inline. > > > > > > Version: > > > > > > https://raw.githubusercontent.com/anima-wg/autonomic-control- > > > plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima- > > > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14. > > > txt > > > > > > > > > Diff to prior version (-14 for Joel Halpern) > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.g= i > > > thubusercon > > > tent.com/anima-wg/autonomic-control- > > > plane/8b4436edaa720eadb5839120400fd1e89d3289b0/draft-ietf-anima- > > > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > > > 14.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/autonomic- > > > control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf- > > > anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-pla > > > ne- > > > 14.txt > > > > > > Will commit as -14 when i am through with the other -13 feedback. > > > > > > Cheers > > > Toerless > > > > > > > > > On Mon, Feb 26, 2018 at 05:25:58PM +0000, Pascal Thubert (pthubert) > > > wrote: > > > > Reviewer: Pascal Thubert on behalf of IOT-DIR; > > > > > > > > I am an assigned IoT directorate reviewer for > > > > draft-ietf-anima-autonomic- > > > control-plane-13. > > > > > > > > These comments were written primarily for the benefit of the INT > > > > and OPS > > > Areas Directors from the IoT perspective. Document editors and > > > shepherd(s) should treat these comments just like they would treat > > > comments from any other IETF contributors and resolve them along > > > with any other Last Call comments that have been received. For more > > > details on the IoT Directorate, please see > > > https://datatracker.ietf.org/group/iotdir/about/ and for > > > Directorates in general please see > https://www.ietf.org/about/groups/directorates/. > > > > > > > > > > > > I'll be away for the next 2 weeks and could not finish the review > > > > in time for > > > this heavy document, but at least I made it through till the RPL > > > section. In the interest of time, let me share what I already have. > > > > > > > > > > > > > > > > Summary > > > > > > > > ------------- > > > > > > > > The summary of the review is that the document is Ready for > > > > Publication, > > > with comments. > > > > > > > > > > > > > > > > > > > > > > > > Major comments > > > > > > > > ------------------------ > > > > > > > > > > > > > > > > - " in-band" and "out of band network " > > > > > > > > should be defined since it is fundamental to understand that the > > > > ACP takes place in the same physical links as the data plane, as > > > > opposed to dedicated management ports (correct?); > > > > > > Good point, done. (got a bit too long to paste here, so pls. check di= ff). > > > > > > > > > > > - Section 3; the IOT certainly could use an ACP. It would = be useful to > > > scope the feature that is proposed in this document, whether it is > > > compatible of not with constrained environments, whether it needs > > > adaptations, point on Michael's enrollment draft. It would also be > > > useful to indicate whether the ACP works between L3 bridges, IOW > > > whether ACP operates the same (over IP) regardless of the packet > > > forwarding layer in the data plane; > > > > > > Not sure i understand the "point on Michaels enrollment draft". > > > > > > I am happy to add pointers to variations of ACP design aspects for > > > informational purposes to show that/how it can be modified, but > > > Michaels drafts i think are all variation of the BRSKI design, so > > > the ACP would be completly unaffected by them, right ? > > > > > [PT>] I guess you're right there > > > > > Wrt. constrained devices and L2. I didn't want to touch section 3 > > > for what you suggested because that really a very formulistic > > > section going back to the charter 1 justifications of ANIMA and > > > matched with the three numbered use case explanations in the > introduction. > > > > > [PT>] OK > > > > > Instead i wrote text at the end of the introduction, now section > > > 1.1, This got longer than i hoped, but it was really a big missing > > > piece to pitch the ACP and give early on context for implementers > > > and reminding of the charter goal of reusing the best available exist= ing > protocols/function. > > [PT>] > > [PT>] I read it, very cool. > > > > > > The text got longer specifically also because i did not want to fall > > > into the trap of making claims whether or not ACP is applicable to > > > specific IOT networks or (even worse) assuming IOT is always > > > constrained. Therefore mentioning of OT networks (IMHO big part of > > > IOT, and often totally non-constrained), explanation of why RPL, and > > > at the end a statement about constrained environments. There is also = a > new paragraph in 10.8 about TCP/TLS vs. > > > CoAP/DTLS as a possible constained environment variant in the future. > > > > > > > - " Inside the ACP VRF, each node sets up a loopback interf= ace with > its > > > ULA IPv6 address" > > > > This is the first time, IPv6 is discussed; would have been nice to > > > > introduce that the Node has IPv6, that it needs a ULA and that ACP > > > > assigns it. This discussion could be done in conjunction with the > > > > comment above; > > > > > > Actually, section 1. introduction already mentions that the ACP > > > provides > > > IPv6 and that the stable-connectivity document describes how to > > > interoperate with IPv4 only OAM. > > > > > > I added to the new 1.1 section (see above) the following paragraph, > > > which i hope is a useful context setting and pitch: > > > > > > The ACP uses only IPv6 to avoid complexity of dual-stack ACP > > > operations (IPv6/IPv4). Nevertheless, it can without any changes be > > > integrated into even otherwise IPv4-only network devices. The > > > data-plane itself would not need to change, it could continue to be > > > IPv4 only. For such IPv4 only devices, the IPv6 protocol itself > > > would be additional implementation footprint only used for the > > > ACP. > > [PT>] OK > > > > > > > > > - About "The ttl > > > > parameter SHOULD be 3.5 times the period so that up to three > > > > consecutive messages can be dropped before considering an > > > > - announcement expired. " > > > > > > > > This is the only discussion on the ttl field of the M_FLOOD. > > > > Though its > > > meaning is quite obvious, the behavior associated to it should be def= ined. > > > > > > Added: > > > > > > When a service announcer > > > using these parameters unexpectely dies immediately after sending > > > the M_FLOOD, receivers would consider it expired 210 seconds later. > > > When a receiver tries to connect this dead service earlier, it will > > > experience a failing connection and use that as an indication the > > > service is dead and select another instance of the same service inste= ad. > > > > > [PT>] OK > > > > > > - "In the above (recommended) example the period of sending= of > the" > > > > Is this RECOMMENDED IOW normative?? > > > > > > Hmmm... Sure, why not. Less guessing/experiementation for this. > > > Modified to RECOMMENDED. > > [PT>] OK > > > > > > > > > - Text P 25 says "At this time in the lifecycle of ACP node= s, it is > unclear > > > whether it > > > > is feasible to even decide on a single MTI (mandatory to > > > > implement) security association protocol across all ACP nodes" > > > > but then P27 "It MUST support ESP > > > > with AES256 for encryption and SHA256 hash and MUST NOT permit > > > weaker > > > > crypto options." > > > > > > > > and then " A baseline ACP node MUST support IPsec natively and MA= Y > > > support IPsec > > > > via GRE. A constrained ACP node MUST support dTLS. ACP nodes > > > > connecting constrained areas with baseline areas MUST therefore > > > > > > > > support IPsec and dTLS." > > > > > > > > Seems that text P25 should go? > > > > > > P27: An ACP node supporting native IPsec MUST use IPsec security > > > setup via IKEv2, tunnel mode, local and peer link-local IPv6 > > > addresses used for encapsulation. It MUST support ESP... (parameters)= . > > > > > > clarified to: > > > > > > P27: An ACP node that is supporting native IPsec MUST use IPsec > > > security setup via IKEv2, tunnel mode, local and peer link-local > > > IPv6 addresses used for encapsulation. It MUST then support ESP... > (parameters). > > > > > > Also: > > > > > > ACP nodes supporting ACP via GRE/IPsec MUST support IPsec security > setup.. > > > > > > clarified to: > > > > > > An ACP node that is supporting ACP via GRE/IPsec MUST then support > > > IPsec security setup.. > > > > > [PT>] OK > > > > > Aka: P25 is correct, there is no single MTI. 6.7.3 defines the > > > actual requirement for two different profiles: "baseline ACP node" > > > and "constrainted ACP node". > > > The two requirements in P27 are only conditional MUSTs defining the > > > details of the IPsec profiles assuming a node does support IPsec or > IPsec/GRE. > > > > > > Let me know if this is still unclear, and if so, how you would > > > suggest to make it better readable. > > [PT>] Someone else need to do it now I'm biased > > > > > > > > > - "Use-ULA: For loopback interfaces of ACP nodes, we use = Unique > > > Local > > > > > > > > Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] > > > > > > > > with L=3D1]." > > > > > > > > This needs to be more crisp. ULA is defined in RFC 4193 but the > > > > term ULA-Random is not. I think you mean that 3.2.2. of RFC 4193 > > > > is the way addresses are formed, if so please say so. The best > > > > practice RFC > > > > 8064 recommends use of RFC 7217. I understand that privacy is not > > > > a concern but does it hurt? Anyway please point at section 6.10 > > > > and > > > > 6.11.1.11 > > > > > > The term "ULA-Random" was used in the discussions on ANIMA mailing > list re. > > > ULA, so admittedly i didn't check that the term as it stands is > > > actually not defined/used in rfc4193 - but its just meant to imply > > > ULA with L=3D1, nothing more. I've removed the use of ULA-Random from > > > the text and just refer now to 4193 with L=3D1 (also pointing to 3.1.= of > rfc4193 defining L). > > > > > [PT>] cool; > > > > > I have also added a note that the hash uses our own ACP definition > > > instead of > > > rfc4193 3.2.2. > > > > > > Paragraph is now: > > > > > > Use-ULA: For loopback interfaces of ACP nodes, we use Unique > > > Local Addresses (ULA), as defined in with > > > L=3D1 (as defined in section 3.1 of ). Note > > > that the random hash for ACP loopback addresses uses the definition > > > in and not the one of > > target=3D"RFC4193"/> section 3.2.2. > > > > > > 8064/7217 are irrelevant here if i understand it correctly because > > > we define the addressing scheme for anything following the ULA > > > prefix ourselves for ACP addresses. Let me know if i do misunderstad > > > what you where trying to suggest re. 8064/7217. > > [PT>] > > [PT>] I guess I missed that you defined the IID. > > > > > > > > > - " > > > > RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations > > > > with > > > multicast support". Implementations should support also other modes. > > > > > > > > Note: Root indicates mode in DIO flow" > > > > > > > > Why "should" ? there is no much point supporting the other modes > > > > is > > > there? Section 6.11.1.13 says that SRH is not used so this is > > > inconsistent. You only need MOP 2 or 3, 3 is you do multicast which > > > at the moment does not appear to be the case. SO I would MUST a MOP > > > of 2 and MAY a MOP of 3 which is a superset of MOP 2, and that's it (= see > 6.3.1 of RFC 6550). > > > > > > Probably a transcription error on my side when i took your RPL > > > summary and wrote it down. Fixed according to above. > > > > > [PT>] cool > > > > > > > > > - "The lack of a RPI (the header defined by [RFC6553]), m= eans that > the > > > > data-plane will have no rank value that can be used to detect loops= . > > > > As a result, traffic may loop until the TTL of the packet reaches > > > > zero. " > > > > > > > > Since we have reliable links and no stretch (section 6.11.1.7), > > > > loops should be exceedingly rare. It could be recommended to send > > > > the DIOs > > > > 2-3 times to inform children when losing the last parent. Note > > > > that the technique in section "8.2.2.6. Detaching" of RFC 6550 > > > > should be favored over that in section "8.2.2.5. Poisoning" > > > > because it allows local connectivity. Also, It should be said that > > > > a node should select more than one parent, at least 3 if possible, > > > > and send DAOs to all of then in parallel. This provides multi > > > > > > Not sure why your paragraph ends apruptly, buts its also in the > > > archive, so its not a mistake on my email end. Hopefully nothing > significant missing. > > [PT>] > > [PT>] Dunno what happened. Selecting multiple parents enables NECM > back. Could be useful. > > > > > > > > I have replaced the suggestive text that followed your above quoted > > > text in the draft: > > > > > > There are a variety of heuristics that can be used to signal from = the > > > data-plane to the RPL control plane that a new route is needed. > > > > > > With a hopefuly correct transcription of your suggestion: > > > > > > > > > Since links in the ACP are assumed to be mostly reliable (or have l= ink > > > layer protection against loss) and because there is no stretch > > > according to , loops should be > > > exceedingly rare though. > > > > > > There are a variety of mechanisms possible in RPL to further > > > avoid temporary loops: DIOs SHOULD be sent 2...3 times to inform > children > > > when losing the last parent. The technique in > > > section 8.2.2.6. (Detaching) SHOULD be favored over that in section > 8.2.2.5. > > > (Poisoning) because it allows local connectivity. Also, nodes SHOUL= D > select > > > more than one parent, at least 3 if possible, and send DAOs to all > > > of then in parallel. > > > > > [PT>] Yes, I'm good with all this. > > > > > > - "ACP nodes MUST perform standard IPv6 operations across= ACP > > > virtual > > > > interfaces including SLAAC (Stateless Address Auto-Configuration - > > > > RFC4862])" > > > > > > > > They may actually prefer Optimistic DAD RFC 4429 since address > > > > duplication > > > is highly improbable as long as you . > > > > > > > > Added: > > > > > > "Optimistic Duplicate Address Detection (DAD)" according t= o > > > is RECOMMENDED because the likelyh= ood > for > > > duplicates between ACP nodes is highly improbable as long as > > > the address can be formed from a globally unique local > > > assigned identifier > > > (e.g.: EUI-48/EUI-64, see below). > > > > > [PT>] > > [PT>] I'm unsure what your recommendation for the interface ID is thus = the > discussion on RFC 7217. > > > > Note: I have only one slight comment left below: > > > > > > > > Minor comments > > > > > > > > ------------------------ > > > > > > > > > > > > > > > > > > > > > > > > - About "[RFC7575] defines the fundamental ... " > > > > > > > > for readability, it may be nicer to indicate the title of an RFC > > > > when it is referenced first; e.g. the text above would become > > > > > > > > " Autonomic Networking: Definitions and Design Goals" [RFC7575] > > > > defines > > > the fundamental ... > > > > > > Ok, i am punting this one for now to RFC editor after playing around > > > a bit with the XML options - and not being satisfied... and having > > > references for 50 RFCs in the doc: > > > > > > [RFC Editor: Question: Is it possible to change the first > > > occurrances of [RFCxxxx] references to "" [RFCxxxx] ? > > > the XML2RFC format does not seem to offer such a format, but i did > > > not want to duplicate 50 first references to be duplicate - one > > > reference for title mentioning and one for RFC number.] > > > > > > If RFC editor comes back and can't do this easier than i can in XML, > > > i'll try to go through the chores when doc is in RFC editor queue. > > > > > > > - about "or network plane (there is no well-established nam= e for > this)" > > > > > > > > The term network plane is not used again in the document. This > > > > text may go > > > away. > > > > > > Done. > > > > > > > You may consider using "security and transport substrate" instead, > > > > since it is > > > used elsewhere in the document. > > > > > > "autonomic communications fabric" =3D ACP including ACP GRASP (ACP > > > GRASP provides discovery etc..). "security and transport substrate" > > > =3D=3D the parts of ACP used by "ACP GRASP" (aka: The secure IPv6 for= warding > of ACP). > > > > > > Subtle difference. > > > > > > > Also, please be consistent on whether you use hyphen or not and > > > > use that globally, e.g. for the above, and pane like in "forwarding= plane" > > > > or "out of band network "; > > > > > > Fixed up "out of band" (no hyphens) and "in-band" (with hyphen). > > > Not sure why but this is what MS word spelling checker suggested to > > > me. RFC editor will override if these are not the best choices. > > > > > > > > > > > > > - "data-plen" > > > > Typo? > > > > > > Done > > > > > > > > > > - "OAM applications ("Operations Administration and > Management)" > > > > > > > > Consider using "Operations Administration and Management (OAM) > > > applications " instead; same goes for SDN, ASA, VRF, etc... > > > > > > Ok. Tried to fix up all the instances i could find. > > > > > > > - " MIC: "Manufacturer Installed Certificate". Another= word not > used > > > in this document to describe an IDevID." > > > > > > > > MIC is not used in the document, maybe inform of this equivalence > > > > in the > > > IDevID definition instead; same goes for SUDI. Note that UDI is use > > > just once and may not need an entry here. > > > > > > The definitions of those non-necessary terms are there to help > > > others who like me start out not being security experts and are > > > confused about those equivalent or related terms. > > > > > > I specifically didn't want to include discussions about these terms > > > in the definitions that are relevant (eg: IDevID) so as not to clobbe= r up that > text. > > > Instead, readers would just look up those redundant terms when they > > > are like me initially confused about them. > > > > > > > - "RPL: \"IPv6 Routing Protocol for Low-Power and Lo= ssy > > > Networks\". The routing protocol used in the ACP." > > > > > > > > Maybe point on [RFC6550]? > > > > > > Done > > > > > > > - "Connecting over non-ACP Layer-3 clouds initially require= s a tunnel > > > between ACP nodes." > > > > > > > > I understands that it is one tunnel between each pair of adjacent > > > > ACP nodes, correct? I read "a tunnel" as an end-to-end tunnel, > > > > which sounds different > > > > > > Changed to: > > > > > > Connecting over non-ACP Layer-3 clouds requires explicit > configuration. > > > See . This may be automated in > > > in the future through autodiscovery mechanisms across L3. > > > > > > > > > > - "ACP relies on group security" > > > > > > > > Add "The" > > > > > > > > > Done > > > > > > > - "An ACP node MUST have keying > > > > material consisting of a certificate (LDevID), with which it can > > > > cryptographically assert its membership in the ACP domain and = trust > > > > anchor(s) associated with that certificate with which it can v= erify > > > > the membership of other nodes (see Section 6.1.2)." > > > > > > > > This is convoluted. Could you make it 2 sentences? > > > > > > Fixed to: > > > > > > The ACP relies on group security. An ACP domain is a group of > > > nodes that trust each other to participate in ACP operations. To > > > establish trust, each ACP member requires keying material: An ACP > > > node MUST have a certificate > > > (LDevID) and a trust anchor (TA) consisting of a certificate (chain) > > > used to sign the LDevID of all domain members. The LDevID is used to > > > cryptographically assert membership in the ACP domain, the TA to > > > verify the membership of other nodes in the ACP domain (see > > target=3D"certcheck"/>). > > > > > > > - " Note: LDevID ("Local Device IDentification") is the te= rm used to > > > > indicate a certificate that was provisioned by the owner of a > > > > node as opposed to IDevID ("Initial Device IDentifier") that may > > > > has been loaded on the node during manufacturing time. Those > > > > IDevID do not include owner and deployment specific information to > > > > allows autonomic establishment of trust for the operations of an AC= P > domain (e.g.: > > > > between two ACP nodes without relying on any third party)." > > > > > > > LDevID was already defined in the terminology. This text may move > > > > there or > > > go away. > > > > > > Gone. I added the note that LDevID can not be used directly for ACP > > > to the terminology definition of IDevID. > > > > > > > - " This document uses the term ACP in many places where= its > > > reference > > > > document use the word autonomic." > > > > > > > > Add [RFC7575] after "reference document" > > > > > > Done. > > > > > > > - " "routing-subdomain" is the autonomic subdomain that = is used > to > > > > calculate the hash for the ULA prefix of the ACP address of the nod= e." > > > > > > > > Do you mean ULA suffix? > > > > > > No, the Global ID. Fixed. > > > > > > Actually, i also sumbled across this: > > > > > > RFC4193 uses "Prefix" for the first 7 bits of a ULA address, but we > > > have used use the term ULA prefix to refer to the first 48 bits of a > > > ULA address, so i've clarified this more in the terminology. > > > > > > > - " o If the node certificates indicate a CDP (or OCSP)= then the > peer's > > > > certificate must be valid according to those criteria. e.g.: OCSP > > > > check across the ACP or not listed in the CRL retrieved from the CD= P." > > > > > > > > Please define CDP and OSCP, and/or reference a RFC is possible. > > > > > > Done. Using RFC5280. Hope thats correct, otherwise IESG SEC review > > > should help. > > > > > > > - "enrolment" > > > > Typo > > > > > > Fixed. > > > > > > > - "This can > > > > use a single GRASP M_FLOOD message as shown in above example." > > > > Actually the example is now below. Please reference the figure. > > > > > > Done. Actually its still "above", or i am heavily confused. > > > > > > > > > > > - "The protocol could for example could have been" > > > > > > > > Typo > > > > > > Fixed. > > > > > > > - "if the IPsec connecting" > > > > > > > > Typo? > > > > > > More like sentence structure was strange. > > > > > > Fixed to: > > > > > > "Even if the IPsec connection from Bob succeeded, Alice might > > > prefer another secure protocol over IPsec" > > > > > > > - "ACP wide service discovery" > > > > ACP-wide > > > > > > Fixed. > > > > > > > - "if the IPsec connecting In most other solution > > > > designs such distributed discovery does not exist at all or was > > > > added as an afterthought and relied upon inconsistently" > > > > > > > > Consider removing or rephrasing : ) > > > > > > Removed: > > > > > > Sentence wasn't that bad, but easier removed instead of trying to > > > justify negative observations about reality without being called out > > > to provide even more proof. > > > > > > > > > > > - Maybe consider moving the discussion on multicast P29 -30= to > annex? > > > Why Multicast is not used is an interesting discussion but not > > > critical for the protocol operation. > > > > > > Done. > > > > > > > - "it is not quite clear yet what exactly the implication= s are > > > > to make GRASP flooding depend on RPL DODAG convergence and how > > > > difficult it would be to let GRASP flooding access the DODAG > > > > information" > > > > > > > > Let's chat then. There's work on reliable multicast for RPL using B= IER. > > > > > > Yeah if i would just get around to that ;-) > > > > > > For now moved together into informative section together with te > > > multicast discus. > > > > > > > - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), th= e ACP is > the > > > > security and transport substrate for the GRASP instance run inside > > > > the ACP ("ACP GRASP"). " > > > > > > > > "running" inside the ACP? Maybe rephrase more globally? > > > > > > > > > > This instance of GRASP runs across the ACP secure channels.. > > > > > > > - "OAM protocols no not require IPv4: The ACP may carry O= AM " > > > > Typo no->do > > > > > > Fixed. > > > > > > > - "Consider a network that has multiple NOCs in different > locations. > > > > Only one NOC will become the DODAG root. Other NOCs will have to > > > > send traffic through the DODAG (tree) rooted in the primary NOC." > > > > > > > A figure would help. I remember all the discussions we had about > > > > setting the prf bits in remote NOCs > > > > > > Sorry. A bit low on cycles right now. Hopefully i'll get around to it= later. > > > Created a wish list entry in changelog. > > > > > > > - "RPPL." > > > > Typo > > > > > > Fixed. > > > > > > > - "Administrative Preference ([RFC6552], 3.2.6 " > > > > > > > > The section is correct but that is RFC 6550. > > > > > > Done > > > > > > > > > > > - "This is a standard issue > > > > with tunneling, not specific to running the ACP across it." > > > > Do you really mean Standard or would Classical work better? > > > > > > This is an issue of tunnels, not an issue of running the ACP across a= tunnel. > > [PT>] > > [PT>] Sure but I was pointing at the word "standard", probably ill-chos= en in > a standard doc... > > > > > > > > > - "Even though loopback interfaces where originally d" > > > > Typo Where -> were > > > > > > Done. > > > > > > > - Section 3, 4, 9 and 10 may move to Annex (by moving the s= ection > after > > > the tag) since they are not normative and do not > > > contribute to the understanding of the protocol. This way there > > > should not be a need to indicate normative in other sections. > > > > > > Sections 3, 4 and 9 are fairly short and the flow of the document > > > depends on them being in their particular location. > > > > > > Section 10 could go into an appendix, but it makes not a lot of > > > difference, but past experience has shown that Annex text is a lot > > > less likely to be read given how the RFCs are structured. > > > We had 10 in Annex and moved it up for exactly that reason. > > > > > > > - Well Noted that Section 14 Will be removed/. > > > > > > > Sorry for being interrupted here, > > > > > > > > > Thanks you so much! > > > > > > > [PT>] My pleasure, > > > > Take care; > > > > Pascal >=20 > -- > --- > tte@cs.fau.de From nobody Mon Jun 11 16:57:27 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC2D130D7A; Mon, 11 Jun 2018 16:57:17 -0700 (PDT) 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-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152876143783.2844.10271888733113116498.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2018 16:57:17 -0700 Archived-At: Subject: [Anima] Warren Kumari's No Objection on draft-ietf-anima-autonomic-control-plane-16: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 23:57:18 -0000 Warren Kumari has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS concerns so quickly and well. I've cleared. (Actually wrote this a few days back, but forgot to hit the confirm button :- ( ) -- Original DISCUSS for hysterical raisins -- I'm balloting DISCUSS, but I think that this should be relatively simple to address: The document says things like:"Today, the management and control plane of networks typically runs in the global routing table, which is dependent on correct configuration and routing." and "Context separation improves security, because the ACP is not reachable from the global routing table. " The term "global routing table" is widely used and understood to mean the global BGP routing table, or Internet global routing table. I understand that you are using it in the "default VRF" meaning, but I think that it is really important to clarify / disambiguate this the first time you use it. ---------- Thank you very much for writing this document -- it is comprehensive... A rich text version of my review is here: https://mozphab-ietf.devsvcdev.mozaws.net/D3801#inline-4146 , and pasted below for tooling, email, etc. --- draft-ietf-anima-autonomic-control-plane.txt:212 network nodes that is not the ACP, and therefore considered to be dependent on (mis-)configuration. This data-plen includes both the traditional forwarding-plane, as well as any pre-existing control- Nit: data-plane draft-ietf-anima-autonomic-control-plane.txt:508 certificate. This does not require any configuration on intermediate nodes, because they can communicate zero-touch and securely through the ACP. I understand what you are trying to say, but "zero-touch" is not an adverb. draft-ietf-anima-autonomic-control-plane.txt:518 the data-plane is operational, will the other planes work as expected. This is *sometimes* an undesirable dependency, but is usually viewed as a feature (by operational people) -- having the control plane share fate with the dataplane is something that is usually a feature - this drives at least part of the reason that many organizations run OSPF and OSPFv3 - having V4 OSPF relying on v4 dataplane avoids blackholes if the v4 dataplane stops working. (This is sometimes, but less often used as an argument against ISIS). I understand why it is useful in this context, but it would be useful to clarify/make it clear that you understand the subtleties. Also, nit: "is operational, will the" -- the comma feel weird here. draft-ietf-anima-autonomic-control-plane.txt:526 management session is running can lock an admin irreversibly out of the device. Traditionally only console access can help recover from such issues. "only console access or OOB". You may be using "console access" to mean OOB, but much (most?) OOB is now not console based. draft-ietf-anima-autonomic-control-plane.txt:531 Operations Center") such as SDN controller applications: Certain network changes are today hard to operate, because the change itself may affect reachability of the devices. Examples are address or mask I think that this was an editing issue -- you don't "operate" changes. Perhaps "implement"? draft-ietf-anima-autonomic-control-plane.txt:858 o If the node certificates indicate a CDP (or OCSP) then the peer's certificate must be valid according to those criteria. e.g.: OCSP You expand CDP further in the document, but this is the first time it is used. draft-ietf-anima-autonomic-control-plane.txt:994 ACP neighbors. Native interfaces (e.g.: physical interfaces on physical nodes) SHOULD be brought up automatically enough so that ACP discovery can be performed and any native interfaces with ACP I don't have a suggestion, but "automatically enough" doesn't sound right - "automatically configured enough" ? draft-ietf-anima-autonomic-control-plane.txt:1067 In the above (recommended) example the period of sending of the objective could be 60 seconds the indicated ttl of 180000 msec means that the objective would be cached by ACP nodes even when two out of Editing fail -- missing some punctuation or words. draft-ietf-anima-autonomic-control-plane.txt:1933 for reachability. The use of the autonomic control plane specific context eliminates the probable clash with the global routing table and also secures the ACP from interference from the configuration IMPORTANT: The term "global routing table" has a well known meaning in operations -- it is the global BGP table. I strongly suggest using a different term, or having a very clear statement in the terminology section, AND the first time you use it in the document. This will help minimize confusion. draft-ietf-anima-autonomic-control-plane.txt:3081 10.2. ACP (and BRSKI) Diagnostics Just a note that I like / appreciate this section - having guidance on how to troubleshoot is very helpful. draft-ietf-anima-autonomic-control-plane.txt:3416 10.3.2.2. Fast state propagation and Diagnostics "Physical down" state propagates on many interface types (e.g.: When I saw the "physically brought down" I started composing a long soapbox rant on the fact that this will slow down state propagation -- I like that that document anticipates and addresses this. It might be useful to have a pointer in the previous section (like "(see below)" or similar.) draft-ietf-anima-autonomic-control-plane.txt:3482 for 5 seconds to probe if there is an ACP neighbor on the remote end every 500 seconds = 1% power consumption. I believe that this is sufficiently incorrect that you should remove the 1% result (or, better yet the whole last sentence). Various interfaces (especially long reach) take a significant amount of time (and additional power) when bringing up interfaces -- things like DWDM optics and amplifiers sometimes need significant power for heating elements to lock the frequency / wavelength, and so the power consumption is not linear with interface uptime. From nobody Tue Jun 12 07:48:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF0130E46 for ; Tue, 12 Jun 2018 07:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g1JqHQUJMTw for ; Tue, 12 Jun 2018 07:48:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD15130E3D for ; Tue, 12 Jun 2018 07:48:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E6CD520090; Tue, 12 Jun 2018 11:02:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3129731C3; Tue, 12 Jun 2018 10:45:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2E62E31BA; Tue, 12 Jun 2018 10:45:27 -0400 (EDT) From: Michael Richardson To: media-types@iana.org cc: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] media types for ietf-anima-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 14:48:28 -0000 --=-=-= Content-Type: text/plain draft-ietf-anima-constrained-voucher-00 asks for two new media types, used within both the DTLS/COAP connection, and within an HTTPS connection. We would like to do an early application for these types, as we need the media type to be present before we can ask for the CoAP Content-Types associated with them. They are: ## Media-Type Registry This section registers the 'application/voucher-cms+cbor' media type and the 'application/voucher-cose+cbor'in the "Media Types" registry. These media types are used to indicate that the content is a CBOR voucher either signed with a cms structure or a COSE_Sign1 structure [RFC8152]. ### application/voucher-cms+cbor Type name: application Subtype name: voucher-cms+cbor Required parameters: none Optional parameters: none Encoding considerations: CMS-signed CBOR vouchers are CBOR encoded. Security considerations: See Security Considerations, Section Interoperability considerations: The format is designed to be broadly interoperable. Published specification: THIS RFC. Applications that use this media type: ANIMA, 6tisch, and other zero-touch imprinting systems Additional information: Magic number(s): None File extension(s): .vch Macintosh file type code(s): none Person & email address to contact for further information: IETF ANIMA WG Intended usage: LIMITED Restrictions on usage: NONE Author: ANIMA WG Change controller: IETF Provisional registration? (standards tree only): NO ### application/voucher-cose+cbor Type name: application Subtype name: voucher-cose+cbor Required parameters: none Optional parameters: cose-type Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects signed with one signer. Security considerations: See Security Considerations, Section Interoperability considerations: The format is designed to be broadly interoperable. Published specification: THIS RFC. Applications that use this media type: ANIMA, 6tisch, and other zero-touch imprinting systems Additional information: Magic number(s): None File extension(s): .vch Macintosh file type code(s): none Person & email address to contact for further information: IETF ANIMA WG Intended usage: LIMITED Restrictions on usage: NONE Author: ANIMA WG Change controller: IETF Provisional registration? (standards tree only): NO -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWx/chICLcPvd0N1lAQKrHgf5AaIwSXBB8H+zYMLrRoLiNI/fo8XLv9dM N5lkhEuVz0B69m9WwnV2x2DxlqUcvdQ/bxlxvDiE1ziRuL5GKXXoJCpMqyZNuJ25 rlbpWgiMduI3jdPpvO8GMgDfcRc7/R9DP6957xniwAHlXbSbS6V2P3uQauALSC+n 6Ax8zFsRXh787tdDyRsJjCTh8j0e39n2DW46TQyfEDzBOb8pOrBSqb6MeLfmUwwI Qr+vqfQLZxHlM5K0HTyxctf6wYnDr37VKPaZ9EBQ4tpV7nzcd8ElpGZ8rMBgiUeX wjAP2EP/JVRK1DskIEVlCZu05a2osSWoRMtk4Uu8qwhmrkcPnHUmEg== =XJgw -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 12 11:13:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF14B126CB6 for ; Tue, 12 Jun 2018 11:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 HHQb2c1UwDjE for ; Tue, 12 Jun 2018 11:12:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E3C130E70 for ; Tue, 12 Jun 2018 11:12:58 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A651D58C4BB; Tue, 12 Jun 2018 20:12:53 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 982A24401A4; Tue, 12 Jun 2018 20:12:53 +0200 (CEST) Date: Tue, 12 Jun 2018 20:12:53 +0200 From: Toerless Eckert To: media-types@iana.org Cc: Michael Richardson , anima@ietf.org, draft-ietf-anima-constrained-voucher-all@ietf.org Message-ID: <20180612181253.ca65fbfbqwlxht3d@faui48f.informatik.uni-erlangen.de> References: <16238.1528814727@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16238.1528814727@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] media types for ietf-anima-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 18:13:04 -0000 [adding author all email, because AFAIK, official review process for standards tree is IESG review, so wanting AD on this. ] a) Not sure about the process, but if it helps and/or is sufficient for an ANIMA WG chair to approve of this request. I hereby do. b) I do assume Michael did simply copy out the request details from ietf-anima-constrained-voucher-00 section 9.5, so please consider the request to be according to that draft versions section. c) Michael: please write into rev -01 section 9.5 the state of the request (early allocation was requested ...(approved) according to below...) Cheers Toerless On Tue, Jun 12, 2018 at 10:45:27AM -0400, Michael Richardson wrote: > > draft-ietf-anima-constrained-voucher-00 asks for two new media types, used > within both the DTLS/COAP connection, and within an HTTPS connection. > > We would like to do an early application for these types, as we need the > media type to be present before we can ask for the CoAP Content-Types > associated with them. > > They are: > > ## Media-Type Registry > > This section registers the 'application/voucher-cms+cbor' media type and the > 'application/voucher-cose+cbor'in the > "Media Types" registry. These media types are used to indicate that > the content is a CBOR voucher either signed with a cms structure or a > COSE_Sign1 structure [RFC8152]. > > ### application/voucher-cms+cbor > > Type name: application > Subtype name: voucher-cms+cbor > Required parameters: none > Optional parameters: none > Encoding considerations: CMS-signed CBOR vouchers are CBOR > encoded. > Security considerations: See Security Considerations, Section > Interoperability considerations: The format is designed to be > broadly interoperable. > Published specification: THIS RFC. > Applications that use this media type: ANIMA, 6tisch, and other > zero-touch imprinting systems > Additional information: > Magic number(s): None > File extension(s): .vch > Macintosh file type code(s): none > Person & email address to contact for further information: IETF > ANIMA WG > Intended usage: LIMITED > Restrictions on usage: NONE > Author: ANIMA WG > Change controller: IETF > Provisional registration? (standards tree only): NO > > ### application/voucher-cose+cbor > > Type name: application > Subtype name: voucher-cose+cbor > Required parameters: none > Optional parameters: cose-type > Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects > signed with one signer. > Security considerations: See Security Considerations, Section > Interoperability considerations: The format is designed to be > broadly interoperable. > Published specification: THIS RFC. > Applications that use this media type: ANIMA, 6tisch, and other > zero-touch imprinting systems > Additional information: > Magic number(s): None > File extension(s): .vch > Macintosh file type code(s): none > Person & email address to contact for further information: IETF > ANIMA WG > Intended usage: LIMITED > Restrictions on usage: NONE > Author: ANIMA WG > Change controller: IETF > Provisional registration? (standards tree only): NO > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 12 11:21:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C4130FA2; Tue, 12 Jun 2018 11:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 W-uJKMvn233d; Tue, 12 Jun 2018 11:21:01 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7392F130E7B; Tue, 12 Jun 2018 11:20:58 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5EBE858C4BB; Tue, 12 Jun 2018 20:20:54 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4F3014401A4; Tue, 12 Jun 2018 20:20:54 +0200 (CEST) Date: Tue, 12 Jun 2018 20:20:54 +0200 From: Toerless Eckert To: media-types@iana.org Cc: Michael Richardson , draft-ietf-anima-constrained-voucher.all@ietf.org, anima@ietf.org Message-ID: <20180612182054.vjqr6mckebdsb6ao@faui48f.informatik.uni-erlangen.de> References: <16238.1528814727@localhost> <20180612181253.ca65fbfbqwlxht3d@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180612181253.ca65fbfbqwlxht3d@faui48f.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] media types for ietf-anima-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 18:21:05 -0000 [again... adding author all email, because AFAIK, official review process for standards tree is IESG review, so wanting AD on this. ] a) Not sure about the process, but if it helps and/or is sufficient for an ANIMA WG chair to approve of this request. I hereby do. b) I do assume Michael did simply copy out the request details from ietf-anima-constrained-voucher-00 section 9.5, so please consider the request to be according to that draft versions section. c) Michael: please write into rev -01 section 9.5 the state of the request (early allocation was requested ...(approved) according to below...) Cheers Toerless On Tue, Jun 12, 2018 at 10:45:27AM -0400, Michael Richardson wrote: > > draft-ietf-anima-constrained-voucher-00 asks for two new media types, used > within both the DTLS/COAP connection, and within an HTTPS connection. > > We would like to do an early application for these types, as we need the > media type to be present before we can ask for the CoAP Content-Types > associated with them. > > They are: > > ## Media-Type Registry > > This section registers the 'application/voucher-cms+cbor' media type and the > 'application/voucher-cose+cbor'in the > "Media Types" registry. These media types are used to indicate that > the content is a CBOR voucher either signed with a cms structure or a > COSE_Sign1 structure [RFC8152]. > > ### application/voucher-cms+cbor > > Type name: application > Subtype name: voucher-cms+cbor > Required parameters: none > Optional parameters: none > Encoding considerations: CMS-signed CBOR vouchers are CBOR > encoded. > Security considerations: See Security Considerations, Section > Interoperability considerations: The format is designed to be > broadly interoperable. > Published specification: THIS RFC. > Applications that use this media type: ANIMA, 6tisch, and other > zero-touch imprinting systems > Additional information: > Magic number(s): None > File extension(s): .vch > Macintosh file type code(s): none > Person & email address to contact for further information: IETF > ANIMA WG > Intended usage: LIMITED > Restrictions on usage: NONE > Author: ANIMA WG > Change controller: IETF > Provisional registration? (standards tree only): NO > > ### application/voucher-cose+cbor > > Type name: application > Subtype name: voucher-cose+cbor > Required parameters: none > Optional parameters: cose-type > Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects > signed with one signer. > Security considerations: See Security Considerations, Section > Interoperability considerations: The format is designed to be > broadly interoperable. > Published specification: THIS RFC. > Applications that use this media type: ANIMA, 6tisch, and other > zero-touch imprinting systems > Additional information: > Magic number(s): None > File extension(s): .vch > Macintosh file type code(s): none > Person & email address to contact for further information: IETF > ANIMA WG > Intended usage: LIMITED > Restrictions on usage: NONE > Author: ANIMA WG > Change controller: IETF > Provisional registration? (standards tree only): NO > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Thu Jun 14 20:56:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E75131027; Mon, 11 Jun 2018 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 UOhIszgZp9aU; Mon, 11 Jun 2018 10:28:40 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50601310BB; Mon, 11 Jun 2018 10:28:40 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C693C58C4F0; Mon, 11 Jun 2018 19:28:35 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B5BE34401A4; Mon, 11 Jun 2018 19:28:35 +0200 (CEST) Date: Mon, 11 Jun 2018 19:28:35 +0200 From: Toerless Eckert To: "Pascal Thubert (pthubert)" , xml2rfc@ietf.org Cc: draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20180611172835.wrzls2yenhglfakg@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: X-Mailman-Approved-At: Thu, 14 Jun 2018 20:56:46 -0700 Subject: [Anima] XML2RFC PDF problem (was: Re: An IOT DIR review of draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 17:28:53 -0000 [ Moving to xml2rfc@ietf.org as this seems to be a tooling issue, Bcc dir/group mailing lists.] Thanks, Pascal I can not find a problem in the xml source i uploaded https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.xml (but of course other eyes may see more..) Note that i did not unload any conversions, just the XML to datatracker. The "normal" html looks fine in the Introduction section: https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.html I think you are referring to the PDF conversion: https://tools.ietf.org/pdf/draft-ietf-anima-autonomic-control-plane-16.pdf Page 6 and 7 are completely messed up in that file, starting maybe as you say from bullet point 2 in Section 1, Introduction. But for no clear reason to me. two Questions to xml2rfc gurus: a) How can i even try to create this PDF format with hyperlinks ? I tried all three PDF versions on https://xml2rfc.tools.ietf.org/ the first one creates perfect PDF without hyperlinks, the second one creates perfect PDF from the perrfect html vrsion (which looks not really good), and the third one creates some strange crap. Without being able to create this hyperlink PDF i'd have to troubleshoot by uploading a lot of versions to datatracker until i figure it out, so thats not going to happen. b) Anybody has a suggestion how to fix this formatting error ? Note that this PDF conversion does seem to be doing some pattern matching: In the introduction the XML source says: Section 5 of Which that PDF shows as a single hyperlink (the HTML of course not). Maybe this type of heuristic pattern matching fails somewhere. But, see question a), without being able to troubleshoot without creating useless draft versions on datatracker, i have no recourse to fix. Will open trac case if nobody has a clue. Thanks a lot! Toerless On Mon, Jun 11, 2018 at 09:55:29AM +0000, Pascal Thubert (pthubert) wrote: > Dear Toerless and authors: > > I reviewed -16 and I'm happy with the changes made for my comments. All set on my side. > I noted that item 2 in the Introduction has a ref that opens a bracket that does not close; this creates a presentation issue on the htmlized version. From nobody Fri Jun 15 08:58:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6ED130E29 for ; Fri, 15 Jun 2018 08:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcalomOqGsI7 for ; Fri, 15 Jun 2018 08:58:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E45C12F18C for ; Fri, 15 Jun 2018 08:58:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EDEA20090; Fri, 15 Jun 2018 12:12:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D6A44C73; Fri, 15 Jun 2018 11:55:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D411BB5A; Fri, 15 Jun 2018 11:55:05 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: anima@ietf.org In-Reply-To: <042701d3e0bc$c42d4150$4c87c3f0$@augustcellars.com> References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> <24823.1525115896@obiwan.sandelman.ca> <042701d3e0bc$c42d4150$4c87c3f0$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] draft-richardson-anima-ace-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 15:58:07 -0000 --=-=-= Content-Type: text/plain {clearing out old emails} Jim Schaad wrote: > There are a couple of questions that I would put here that I think guides > things. > * Is there any expectation that the path components would ever change for > some implementation or are they always going to be the same? Would a > request voucher always be posted to /rv or could an implementation change it > to be /rvr? To me, there is no reason. > * Is there a reason for an endpoint to want to get what services are > supported as a general rule rather than just assuming that if the root > exists then all of the services are also going to exist. I would tend to think that was the case. > If the answer to the first question is no, then I don't know that they even > need to have resource types. You get the root and go from there. > If the answer to both questions is yes, then a different rt for every > service would be needed so that they can be distinguished. > If the answer to the first question is no and the second is yes, then it > would make sense to define a generic rt='ace.est.service' so that the root > and the list of services can be queried for individually. I don't think it's justified. It might be useful to be able to inquire to an EST (CoAP) end point whether or not it supports the BRSKI extensions, but I can't come up with an operational situation where this would be used. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyPhV4CLcPvd0N1lAQL3Lgf/Q5g6pyzLlXFR5PmTv+JDw2/U5XiHuSQN Uy0/0MBQ1T+/vXU28rzr75zvUmWDeYsQJSF/LPk6wYFQL1uaD7iBsvTWeBDWeucd GdSoMiXOoiJQLAnPy8Mb77NhNwhbixvrJaKXCLK9UdtSPTlBT+rkxPty1h/oekcq U6RY6Sno5vsT41MuC70HbKPHpCmNfn3ouQj+JbCRl8eMBc4PA4rOk3xC3zg1VFdJ e+MhfosFWnAAe+6CE7gX+zzjcfq2fscVTToOQZVnmj4xTIC3jK57/ZtAaI0Qj87E yHh3CQAdZF0jjQ5L2oZuwHHSiQv1rU2Iho65VLdzwfVwahg3V+0gww== =FYqt -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 15 10:59:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60F3130E36 for ; Fri, 15 Jun 2018 10:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un6KMHPcmy4A for ; Fri, 15 Jun 2018 10:59:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF29312F18C for ; Fri, 15 Jun 2018 10:59:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 33B0A20090; Fri, 15 Jun 2018 14:13:20 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9281CDA8; Fri, 15 Jun 2018 13:56:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9089FD92; Fri, 15 Jun 2018 13:56:25 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: anima@ietf.org In-Reply-To: <042801d3e0c2$8ba4d8b0$a2ee8a10$@augustcellars.com> References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> <24823.1525115896@obiwan.sandelman.ca> <042801d3e0c2$8ba4d8b0$a2ee8a10$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] sending raw public key over the wire X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 17:59:27 -0000 --=-=-= Content-Type: text/plain Jim, in the situation where a COSE/CBOR voucher has been signed by a Raw Public Key (whether ECDSA or EdDSA), and the signing (public) key needs to be transfered, would you recommend: 1) use RFC8152, section 7.1 to describe the key. Same as you use in your Examples git tree. What MIME-TYPE would you use to transfer such a thing? 2) use (Subject-)Public-Key-Info encoded as specified in RFC7250, section 3. What MIME-TYPE would you use to transfer such a thing? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyP9xYCLcPvd0N1lAQLahQf/dtOFNP5fLxum5pJgMGFc+uf2ljl5a4IV QIq24GyRH1mQxg/bO/d2Wwk+TPg3yAaR0MULpeeHjVULhYtSw9WrOdrxG9AROWjA 7Xnh2t8v7Ldzqy/KzU4bMxY+GwU7AiCS+48X2lmy/ljS6wOUhxnHkMtBNNxJAFfh wVuTihp89C+BnehColhE37okunAwWPe/AGxAFyZ0nxzNaYPirgHYBdO89Wy///M4 fzI1oRaceeA4RsHqxMKVYxPDTt5h2YXmg/yYMf0a/K5MyxkGGofVm0iau+O/Ppfc J7EO4DH+NZUV55U5J2pyGC5w7Ovmp2L0juvmcxk3f15laWVaxAeSSA== =AnBr -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 15 11:21:12 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF8130E37 for ; Fri, 15 Jun 2018 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b-NBmjN5KFNz for ; Fri, 15 Jun 2018 11:21:08 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9031130E4A for ; Fri, 15 Jun 2018 11:21:07 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Jun 2018 11:18:05 -0700 From: Jim Schaad To: 'Michael Richardson' CC: References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> <24823.1525115896@obiwan.sandelman.ca> <042801d3e0c2$8ba4d8b0$a2ee8a10$@augustcellars.com> <25514.1529085385@localhost> In-Reply-To: <25514.1529085385@localhost> Date: Fri, 15 Jun 2018 11:21:00 -0700 Message-ID: <001901d404d5$9e7c2bf0$db7483d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLCkQGC20XMmbNAiHDKQUp73z+Q4wKjAcVIAh09EIYBmem3CKJRtrXw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Anima] sending raw public key over the wire X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 18:21:10 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Friday, June 15, 2018 10:56 AM > To: Jim Schaad > Cc: anima@ietf.org > Subject: sending raw public key over the wire > > > Jim, in the situation where a COSE/CBOR voucher has been signed by a Raw > Public Key (whether ECDSA or EdDSA), and the signing (public) key needs to > be transfered, would you recommend: > > 1) use RFC8152, section 7.1 to describe the key. > Same as you use in your Examples git tree. > What MIME-TYPE would you use to transfer such a thing? Per RFC8152 section 16.9.2 - application/cose-key or application/cose-key-set depending on which of the COSE key structure that are to be used. > > 2) use (Subject-)Public-Key-Info encoded > as specified in RFC7250, section 3. > What MIME-TYPE would you use to transfer such a thing? The RPK is transferred as part of the DTLS negotiation. As such it is transferred, but not trusted in DTLS. If you do FUD then that is sufficient. If it is not sufficient then you could use the answer to 1 as one of many different ways to transfer keys. Keys can be transferred as COSE_Keys, JOSE_keys, PEMs or Certificates each of which defines a Media-Type. Of course the PRK could also be baked into the device as well. Jim > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Fri Jun 15 19:41:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910C6130EBC for ; Fri, 15 Jun 2018 19:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t57lbW372pRS for ; Fri, 15 Jun 2018 19:41:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099DA12F1AB for ; Fri, 15 Jun 2018 19:41:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C5FC020090 for ; Fri, 15 Jun 2018 22:55:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9F193DE3; Fri, 15 Jun 2018 22:38:52 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9C7AEDA8 for ; Fri, 15 Jun 2018 22:38:52 -0400 (EDT) From: Michael Richardson to: anima@ietf.org In-Reply-To: <12358.1527624010@localhost> References: <1c1b65c5ff117f7a092471c366ee93ef@xs4all.nl> <7803.1525733701@localhost> <9834a534d66d57dc1bdb8d106f6a453f@xs4all.nl> <1787.1526523912@dooku.sandelman.ca> <12358.1527624010@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] getting the constrained MASA voucher signing public key to JRC X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 16 Jun 2018 02:41:55 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > 5) use the existing /voucherrequest, but define the result (when an > application/cbor+cose voucher request is presented) to be a multipart > result, with the second piece being the public key "bag". I've been convinced to return a multipart/related. (I think it's related I want). This is HTTP not CoAP, to be clear. The next 6tisch-dtsecurity-zerotouch-join will say; >In order to do this, the MASA MAY return a multipart/related return, within that >body, two items SHOULD be returned: > >1. An application/voucher-cose+cbor body. >2. An application/pkcs7-mime; smime-type=certs-only, or an >application/SOMETHING containing a Raw Public Key. (See other email wherein I ask for opinions) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyR4OYCLcPvd0N1lAQLi0ggAisxrKHBnhtVAlJDno4GvXy1ksuBcKgsV IIEzU9Lk7KAdh1DYR8PQhP1sMN/Dh+ABj6C5jazIla2tcqRe8tySi4Kb/U7tVOWs 6LZwWEAQJygqBhcjGsivW2/CNpV2/5BD4zvST18wr3Y281KG6N50PfZJ1HMzGXX1 ztPjS4jSojnNosjKYNqfonotpYEtiiC5OeoXZ97+erkn3TVkVmPuR+F+hFV5RAxe wYFhB60Sf6Odg15mgXAwWacpGmyAdJh+UlHtSGRPsTqJ/4Grn7reWOXQRinMdcPC 612k0iVlt7qnR2jEVQpXjrz0/HeA07/B5vDcrGKGXjcbMzHziWv4PQ== =3WZf -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 18 15:26:18 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6F129385 for ; Mon, 18 Jun 2018 15:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 o-af2yCmDvM6 for ; Mon, 18 Jun 2018 15:26:10 -0700 (PDT) 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 376E7130E4D for ; Mon, 18 Jun 2018 15:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7788; q=dns/txt; s=iport; t=1529360770; x=1530570370; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JRzlxA4n6hu3K6k9eDSgfVHUMK1QrsKZH+kNRtCaECQ=; b=ZKiTcpGICWg6I5qGuMyKqvzlO7stmlA8B0dh9ECiNqxreHIOoH9femdk SvO/nfpCGz37i6mT+uqcL3ytKu5fZPnLmDnI4laeNJrkHsCPmgXHSOnRW 0etV5snBLjptIOuM9u329XEJqNNgriRea/SiC2lCQ54Szgiov8XRVVwFg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAACfMChb/49dJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNIYn8oCoNviASMUYFekBOEfxSBZAsYAQyBUoJ1AheCSCE?= =?us-ascii?q?0GAECAQEBAQEBAm0cDIUpAgQBASFLCxACAQg/AwICAiULFBECBA4FgyUCgRt?= =?us-ascii?q?kD6pPghyEW4NugWMFiFSCE4EPJAyCLi6DEwEBAgGBKgESAYMgMYIkApkWCQK?= =?us-ascii?q?FeoJfhi6NO4oShxQCERMBgSQdOGFxcBU7KgGCGIsRhT5vAQGOcYEfgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,240,1526342400"; d="scan'208,217";a="131432537" 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; 18 Jun 2018 22:26:09 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w5IMQ9Z3019017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jun 2018 22:26:09 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 18 Jun 2018 17:26:08 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Mon, 18 Jun 2018 17:26:08 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] getting the constrained MASA voucher signing public key to JRC Thread-Index: AQHT7Yw5FgCfsJv2GEKzSYpq1d+LL6RHiAUAgBsnBwCABHBggA== Date: Mon, 18 Jun 2018 22:26:08 +0000 Message-ID: References: <1c1b65c5ff117f7a092471c366ee93ef@xs4all.nl> <7803.1525733701@localhost> <9834a534d66d57dc1bdb8d106f6a453f@xs4all.nl> <1787.1526523912@dooku.sandelman.ca> <12358.1527624010@localhost> <1316.1529116732@localhost> In-Reply-To: <1316.1529116732@localhost> 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.4] Content-Type: multipart/alternative; boundary="_000_A83661DC77894C53AEE990A66902B630ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] getting the constrained MASA voucher signing public key to JRC X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 22:26:13 -0000 --_000_A83661DC77894C53AEE990A66902B630ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1biAxNSwgMjAxOCwgYXQgODozOCBQTSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYT4+IHdyb3RlOg0K DQoNCk1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3Ir aWV0ZkBzYW5kZWxtYW4uY2E+PiB3cm90ZToNCjUpIHVzZSB0aGUgZXhpc3RpbmcgL3ZvdWNoZXJy ZXF1ZXN0LCBidXQgZGVmaW5lIHRoZSByZXN1bHQgKHdoZW4gYW4NCmFwcGxpY2F0aW9uL2Nib3Ir Y29zZSB2b3VjaGVyIHJlcXVlc3QgaXMgcHJlc2VudGVkKSB0byBiZSBhIG11bHRpcGFydA0KcmVz dWx0LCB3aXRoIHRoZSBzZWNvbmQgcGllY2UgYmVpbmcgdGhlIHB1YmxpYyBrZXkgImJhZyIuDQoN CkkndmUgYmVlbiBjb252aW5jZWQgdG8gcmV0dXJuIGEgbXVsdGlwYXJ0L3JlbGF0ZWQuDQooSSB0 aGluayBpdCdzIHJlbGF0ZWQgSSB3YW50KS4NCg0KVGhpcyBpcyBIVFRQIG5vdCBDb0FQLCB0byBi ZSBjbGVhci4NCg0KVGhlIG5leHQgNnRpc2NoLWR0c2VjdXJpdHktemVyb3RvdWNoLWpvaW4gd2ls bCBzYXk7DQoNCkluIG9yZGVyIHRvIGRvIHRoaXMsIHRoZSBNQVNBIE1BWSByZXR1cm4gYSBtdWx0 aXBhcnQvcmVsYXRlZCByZXR1cm4sIHdpdGhpbiB0aGF0DQpib2R5LCB0d28gaXRlbXMgU0hPVUxE IGJlIHJldHVybmVkOg0KDQoxLiBBbiBhcHBsaWNhdGlvbi92b3VjaGVyLWNvc2UrY2JvciBib2R5 Lg0KMi4gQW4gYXBwbGljYXRpb24vcGtjczctbWltZTsgc21pbWUtdHlwZT1jZXJ0cy1vbmx5LCBv ciBhbg0KYXBwbGljYXRpb24vU09NRVRISU5HIGNvbnRhaW5pbmcgYSBSYXcgUHVibGljIEtleS4N Cg0KSXQgc2VlbXMgd2VpcmQgdG8gY29tYmluZSB0aGUgY3d0IHN0eWxlIGJvZHkgd2l0aCBzdWNo IGFuIHVuY29uc3RyYWluZWQgdmFsdWUgc3VjaCBhcyBhIHBrY3M3LXNtaW1lIGJsb2IuDQpFdmVu IGlmIGl0IG1ha2VzIHNlbnNlIHRvIHVzZSB0aGUgaHR0cCBsYXllciBtdWx0aXBhcnQgaW5zdGVh ZCBvZiB4NWMgKHVucHJvdGVjdGVkIGhlYWRlciBmaWVsZHMpIHdvdWxkbuKAmXQgdGhlIG1vcmUg b3B0aW1pemVkIG1lc3NhZ2UgZm9ybWF0IG1ha2Ugc2Vuc2U/DQoNCkkgY2Fu4oCZdCBzZWVtIHRv IGZpbmQgYSBkZWZpbml0aW9uIG9mIG11bHRpcGFydCAob3Ig4oCccmVsYXRlZOKAnT8pIGZvciBD b0FQLiBJZiBpdHMgaGFuZGxlZCBhbnl0aGluZyBsaWtlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMyMDQ2I3NlY3Rpb24tNS4xLjEgSeKAmWQgZXhwZWN0IHRvIGZpbmQgaXQgaW4gaGVy ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTEyLjMgb3IgYXQg aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJhbWV0ZXJzL2NvcmUtcGFy YW1ldGVycy54aHRtbCNjb250ZW50LWZvcm1hdHMgLiBDYW4geW91IHByb3ZpZGUgYSBwb2ludGVy IHRvIGV4cGxhaW4gd2hhdCB0aGlzIHdvdWxkIGxvb2sgbGlrZT8NCg0KLSBtYXgNCg0KDQoNCihT ZWUgb3RoZXIgZW1haWwgd2hlcmVpbiBJIGFzayBmb3Igb3BpbmlvbnMpDQoNCg0KLS0NCk1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IrSUVURkBzYW5k ZWxtYW4uY2E+PiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQotPSBJUHY2IElvVCBjb25zdWx0 aW5nID0tDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KQW5pbWEgbWFpbGluZyBsaXN0DQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg== --_000_A83661DC77894C53AEE990A66902B630ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IEp1biAxNSwgMjAxOCwgYXQgODozOCBQTSwgTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVm PSJtYWlsdG86bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSIgY2xhc3M9IiI+bWNyJiM0MztpZXRm QHNhbmRlbG1hbi5jYTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCk1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0 ZkBzYW5kZWxtYW4uY2EiIGNsYXNzPSIiPm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0 OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj41 KSB1c2UgdGhlIGV4aXN0aW5nIC92b3VjaGVycmVxdWVzdCwgYnV0IGRlZmluZSB0aGUgcmVzdWx0 ICh3aGVuIGFuPGJyIGNsYXNzPSIiPg0KYXBwbGljYXRpb24vY2JvciYjNDM7Y29zZSB2b3VjaGVy IHJlcXVlc3QgaXMgcHJlc2VudGVkKSB0byBiZSBhIG11bHRpcGFydDxiciBjbGFzcz0iIj4NCnJl c3VsdCwgd2l0aCB0aGUgc2Vjb25kIHBpZWNlIGJlaW5nIHRoZSBwdWJsaWMga2V5ICZxdW90O2Jh ZyZxdW90Oy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJJ3Zl IGJlZW4gY29udmluY2VkIHRvIHJldHVybiBhIG11bHRpcGFydC9yZWxhdGVkLjxiciBjbGFzcz0i Ij4NCihJIHRoaW5rIGl0J3MgcmVsYXRlZCBJIHdhbnQpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClRoaXMgaXMgSFRUUCBub3QgQ29BUCwgdG8gYmUgY2xlYXIuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KVGhlIG5leHQgNnRpc2NoLWR0c2VjdXJpdHktemVyb3RvdWNoLWpvaW4g d2lsbCBzYXk7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+SW4gb3JkZXIgdG8gZG8gdGhpcywgdGhlIE1BU0EgTUFZIHJldHVybiBh IG11bHRpcGFydC9yZWxhdGVkIHJldHVybiwgd2l0aGluIHRoYXQ8YnIgY2xhc3M9IiI+DQpib2R5 LCB0d28gaXRlbXMgU0hPVUxEIGJlIHJldHVybmVkOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjEuIEFuIGFwcGxpY2F0aW9uL3ZvdWNoZXItY29zZSYjNDM7Y2JvciBib2R5LjxiciBjbGFz cz0iIj4NCjIuIEFuIGFwcGxpY2F0aW9uL3BrY3M3LW1pbWU7IHNtaW1lLXR5cGU9Y2VydHMtb25s eSwgb3IgYW48YnIgY2xhc3M9IiI+DQphcHBsaWNhdGlvbi9TT01FVEhJTkcgY29udGFpbmluZyBh IFJhdyBQdWJsaWMgS2V5LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JdCBz ZWVtcyB3ZWlyZCB0byBjb21iaW5lIHRoZSBjd3Qgc3R5bGUgYm9keSB3aXRoIHN1Y2ggYW4gdW5j b25zdHJhaW5lZCB2YWx1ZSBzdWNoIGFzIGEgcGtjczctc21pbWUgYmxvYi4mbmJzcDs8L2Rpdj4N CjxkaXY+RXZlbiBpZiBpdCBtYWtlcyBzZW5zZSB0byB1c2UgdGhlIGh0dHAgbGF5ZXIgbXVsdGlw YXJ0IGluc3RlYWQgb2YgeDVjICh1bnByb3RlY3RlZCBoZWFkZXIgZmllbGRzKSB3b3VsZG7igJl0 IHRoZSBtb3JlIG9wdGltaXplZCBtZXNzYWdlIGZvcm1hdCBtYWtlIHNlbnNlPzwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSBjYW7igJl0IHNlZW0gdG8gZmluZCBhIGRl ZmluaXRpb24gb2YgbXVsdGlwYXJ0IChvciDigJxyZWxhdGVk4oCdPykgZm9yIENvQVAuIElmIGl0 cyBoYW5kbGVkIGFueXRoaW5nIGxpa2UmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMjA0NiNzZWN0aW9uLTUuMS4xIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMjA0NiNzZWN0aW9uLTUuMS4xPC9hPiZuYnNwO0nigJlkIGV4cGVjdCB0 byBmaW5kIGl0IGluIGhlcmUmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzI1MiNzZWN0aW9uLTEyLjMiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MjUyI3NlY3Rpb24tMTIuMzwvYT4mbmJzcDtvcg0KIGF0Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJhbWV0ZXJzL2NvcmUtcGFy YW1ldGVycy54aHRtbCNjb250ZW50LWZvcm1hdHMiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzL2NvcmUtcGFyYW1ldGVycy9jb3JlLXBhcmFtZXRlcnMueGh0bWwjY29u dGVudC1mb3JtYXRzPC9hPiZuYnNwOy4gQ2FuIHlvdSBwcm92aWRlIGEgcG9pbnRlciB0byBleHBs YWluIHdoYXQgdGhpcyB3b3VsZCBsb29rDQogbGlrZT8mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pi0gbWF4PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQooU2VlIG90aGVyIGVt YWlsIHdoZXJlaW4gSSBhc2sgZm9yIG9waW5pb25zKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCi0tPGJyIGNsYXNzPSIiPg0KTWljaGFlbCBSaWNoYXJkc29uICZs dDs8YSBocmVmPSJtYWlsdG86bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYSIgY2xhc3M9IiI+bWNy JiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3M8 YnIgY2xhc3M9IiI+DQotPSBJUHY2IElvVCBjb25zdWx0aW5nID0tPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpBbmltYSBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciIGNs YXNzPSIiPkFuaW1hQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A83661DC77894C53AEE990A66902B630ciscocom_-- From nobody Mon Jun 18 16:37:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7154130DBE for ; Mon, 18 Jun 2018 16:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOgjGDqLvaAr for ; Mon, 18 Jun 2018 16:37:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6CE130E44 for ; Mon, 18 Jun 2018 16:37:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C46B620090; Mon, 18 Jun 2018 19:51:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A55EA1817; Mon, 18 Jun 2018 19:34:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A3684E2E; Mon, 18 Jun 2018 19:34:43 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" cc: "Max Pritikin \(pritikin\)" In-Reply-To: References: <1c1b65c5ff117f7a092471c366ee93ef@xs4all.nl> <7803.1525733701@localhost> <9834a534d66d57dc1bdb8d106f6a453f@xs4all.nl> <1787.1526523912@dooku.sandelman.ca> <12358.1527624010@localhost> <1316.1529116732@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] getting the constrained MASA voucher signing public key to JRC X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:37:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: mcr> 5) use the existing /voucherrequest, but define the result (wh= en an mcr> application/cbor+cose voucher request is presented) to be a multip= art mcr> result, with the second piece being the public key "bag". mcr> I've been convinced to return a multipart/related. (I think i= t's mcr> related I want). actually, probably multipart/mixed is what I want. mcr> This is HTTP not CoAP, to be clear. NOTE BENE. mcr> The next 6tisch-dtsecurity-zerotouch-join will say; mcr> In order to do this, the MASA MAY return a multipart/relat= ed mcr> return, within that body, two items SHOULD be returned: mcr> 1. An application/voucher-cose+cbor body. 2. An mcr> application/pkcs7-mime; smime-type=3Dcerts-only, or an mcr> application/SOMETHING containing a Raw Public Key. > It seems weird to combine the cwt style body with such an unconstrain= ed > value such as a pkcs7-smime blob. Even if it makes sense to use the > http layer multipart instead of x5c (unprotected header fields) > wouldn=E2=80=99t the more optimized message format make sense? Just to be clear, x5c is a *CWT* thing, not a COSE thing. CWT is built on top of COSE... if we were doing constrained voucher as CWT, then we'd want to use the CWT "iss", "sub", "aud', etc. which does not map mechanically from the YANG. We can still put a value into the unprotected header field as you suggest, but that means that the JRC either has to pass the kilobyte of certificate = on to the pledge via the constrained channel... or it has to modify the voucher to remove it. I did look for an application/cms thing that carried certificates, but I didn't find anything. > I can=E2=80=99t seem to find a definition of multipart (or =E2=80=9Cr= elated=E2=80=9D?) for > CoAP. If its handled anything like > https://tools.ietf.org/html/rfc2046#section-5.1.1 I=E2=80=99d expect = to find it > in here https://tools.ietf.org/html/rfc7252#section-12.3 or at > https://www.iana.org/assignments/core-parameters/core-parameters.xhtm= l#content-formats > . Can you provide a pointer to explain what this would look like? This is between the Registrar and MASA, which is unconstrained HTTPS, not CoAP, even in the constrained situation. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyhBkICLcPvd0N1lAQLV8Af+J3PtGzNrmEZ5ykzL48mN/FpWx/SuasG9 bfp5JQ9wrT+xg9V5xBKDGZw84U572aj8MrGOkJwDUT5cNsLlM7XSjZw5tjF1Bmma jWLrRNNuCi2XwjQxjD8zppMfoOzIWDB7cHSIUk3wqlHnTJt9JBQwulRDAO/TfJih qkOrbK0ZC/X5lPwzSXrqtHVLOLHCA8ZOdxB/Ph3wdppHO/r9k2QngWB07P10Pa3B FovPU86NYnCeToFxrAWZ4JqjHhKDO/xZdXDZ7/Xdcwdf/kZZTYDK7A2lEMnQrV3t 1Y0ExfENkqIWm4go7+cZ0aFSMF19OHcxt7r8zbenRYk8M3BZmhkvHg== =Yfe8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 19 08:11:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB191310FA; Tue, 19 Jun 2018 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl_atoovB5jR; Tue, 19 Jun 2018 08:11:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E866F130EA8; Tue, 19 Jun 2018 08:11:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2CAE420090; Tue, 19 Jun 2018 11:25:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 54A901A69; Tue, 19 Jun 2018 11:08:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 52BDA1A68; Tue, 19 Jun 2018 11:08:21 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org cc: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 15:11:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value for GRASP. In this normative part of the document, there is only one choic= e, but it is our intention to allow additional choices, as per section 2.2.2 of cddl-02. We think that we should specify our single "choice", using /=3D, rather tha= n =3D, as this should clue the reader in to expect multiple values here. From=20our document: transport-proto /=3D IPPROTO_TCP ; note this is an extensible CDDL choice ; and can be added to in subsequent ; specifications using the /=3D and //=3D It is unclear in section 2.2.2 if we can say foo /=3D without having said foo =3D 1 / 2 / 3 previously, but it seems like it should be reasonable to do in order to indicate that implementations should expect future values. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWykcYoCLcPvd0N1lAQL1jAgAusybcmaLIX9NsI/t9/LhWFq4tVsJQgC5 5rcnQjCPZfsPaTw5C4Fj3Jpxp60PiKbxOcnmb1teE+HJDimynHY0fHQBom0YkM59 3NjjGj9SimYMd2NmQPehbkzhK8Bdz+Rmu/Ia4nkenEwY5dVKa3oXnd2IXb0X6s6N R6GvumhHKXkEvimxhSAxb0afU3DVIHQ+zzQG99re1lK2PL0X/x3CgUH0NMPQm6qT MBu396c9Ya8d2Y0y5A7pRCEQwJaBlv3iswnD3O/3yHf7rqi1qgPLxd+EX0e2Gt2H TPKO7p8OgKtxhWqhZUPbzEYlj60L6U7suHwvvThYv0sOtmtR50ULDA== =YHEL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 19 08:20:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38F7130EA8; Tue, 19 Jun 2018 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2rxphkyIyX5Z; Tue, 19 Jun 2018 08:20:38 -0700 (PDT) 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 2F41A130E3C; Tue, 19 Jun 2018 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5JFKZot020467; Tue, 19 Jun 2018 17:20:35 +0200 (CEST) Received: from client-0114.vpn.uni-bremen.de (client-0114.vpn.uni-bremen.de [134.102.107.114]) (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 419BVV6gDDzDWqv; Tue, 19 Jun 2018 17:20:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <1812.1529420901@localhost> Date: Tue, 19 Jun 2018 17:20:34 +0200 Cc: cbor@ietf.org, anima@ietf.org X-Mao-Original-Outgoing-Id: 551114432.56145-f39f25e63e1f01b7bfa80e9ded777149 Content-Transfer-Encoding: quoted-printable Message-Id: <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> References: <1812.1529420901@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 15:20:41 -0000 Hi Michael, 2.2.2 says: It is not an error if a name is first used with a "/=3D" or "//=3D" (there is no need to =E2=80=9Ccreate it" with "=3D"). The intention is indeed to say that no initial rule with a =E2=80=9C=3D=E2= =80=9C is needed. Any ideas how we can clarify this some more? You could also make use of the convention (not currently checked by any = tool, but that could be done) to mark an extension point with a dollar = sign: $transport-proto /=3D IPPROTO_TCP (See section 3.9 for more about that convention.) Gr=C3=BC=C3=9Fe, Carsten > On Jun 19, 2018, at 17:08, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol = value > for GRASP. In this normative part of the document, there is only one = choice, > but it is our intention to allow additional choices, as per section = 2.2.2 > of cddl-02. >=20 > We think that we should specify our single "choice", using /=3D, = rather than =3D, > as this should clue the reader in to expect multiple values here. >=20 > =46rom our document: >=20 > transport-proto /=3D IPPROTO_TCP ; note this is an extensible CDDL = choice > ; and can be added to in subsequent > ; specifications using the /=3D and = //=3D >=20 > It is unclear in section 2.2.2 if we can say foo /=3D without having = said > foo =3D 1 / 2 / 3 > previously, but it seems like it should be reasonable to do in order = to > indicate that implementations should expect future values. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 From nobody Tue Jun 19 08:21:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC1130E3C; Tue, 19 Jun 2018 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QVx6ycvqUx4r; Tue, 19 Jun 2018 08:21:27 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7817F1310FA; Tue, 19 Jun 2018 08:21:15 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Jun 2018 08:18:10 -0700 From: Jim Schaad To: 'Michael Richardson' , CC: References: <1812.1529420901@localhost> In-Reply-To: <1812.1529420901@localhost> Date: Tue, 19 Jun 2018 08:21:08 -0700 Message-ID: <01a601d407e1$275c1850$761448f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQId9lHu77pIXu+Dt0rbOoVrMt9rC6PT1YZA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Anima] [Cbor] CDDL-02 section 2.2.2 choices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 15:21:31 -0000 Look at the last paragraph in section 2.2.2 It is not an error if a name is first used with a "/=" or "//=" (there is no need to "create it" with "="). Jim > -----Original Message----- > From: CBOR On Behalf Of Michael Richardson > Sent: Tuesday, June 19, 2018 8:08 AM > To: cbor@ietf.org > Cc: anima@ietf.org > Subject: [Cbor] CDDL-02 section 2.2.2 choices > > > In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value > for GRASP. In this normative part of the document, there is only one choice, > but it is our intention to allow additional choices, as per section 2.2.2 of cddl- > 02. > > We think that we should specify our single "choice", using /=, rather than =, > as this should clue the reader in to expect multiple values here. > > From our document: > > transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice > ; and can be added to in subsequent > ; specifications using the /= and //= > > It is unclear in section 2.2.2 if we can say foo /= without having said > foo = 1 / 2 / 3 > previously, but it seems like it should be reasonable to do in order to indicate > that implementations should expect future values. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Tue Jun 19 08:32:18 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D62131151 for ; Tue, 19 Jun 2018 08:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qP7cQp1SQhz for ; Tue, 19 Jun 2018 08:32:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7196130FEB for ; Tue, 19 Jun 2018 08:32:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C46720090 for ; Tue, 19 Jun 2018 11:46:26 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 793BF1A68 for ; Tue, 19 Jun 2018 11:29:15 -0400 (EDT) To: anima@ietf.org References: <1812.1529420901@localhost> From: Michael Richardson Message-ID: <5f216303-d326-2324-7a5f-d4e8d1b354c1@sandelman.ca> Date: Tue, 19 Jun 2018 11:29:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1812.1529420901@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] transport-proto IANA considerations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 15:32:18 -0000 On 19/06/18 11:08 AM, Michael Richardson wrote: > From our document: > > transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice > ; and can be added to in subsequent > ; specifications using the /= and //= In further discussion about whether or not we now need an IANA registry in BRSKI to deal with this, we concluded that we did not, because GRASP already dealt with that in section 2.9.5.1, note 3, so we decided to refer to that instead: transport-proto /= IPPROTO_TCP ; note this can be any value from the ; IANA protocol registry, as per ; [GRASP] section 2.9.5.1, note 3. We have also removed all referenced to IPPROTO_UDP and IPPROTO_IPV6 from the normative section. From nobody Tue Jun 19 08:34:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03500130DEC for ; Tue, 19 Jun 2018 08:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL-gZAPeXOYp for ; Tue, 19 Jun 2018 08:34:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EAB5130F56 for ; Tue, 19 Jun 2018 08:34:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 36F1C20090 for ; Tue, 19 Jun 2018 11:49:01 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 51F751A68 for ; Tue, 19 Jun 2018 11:31:50 -0400 (EDT) To: anima@ietf.org References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> From: Michael Richardson Message-ID: <60cb0d42-eb0b-7936-acff-d12539dc1193@sandelman.ca> Date: Tue, 19 Jun 2018 11:31:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] references to code ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 15:34:54 -0000 On 31/05/18 02:43 PM, Toerless Eckert wrote: > Thanks, Eliot > > Good point, forgot to ask/mention this point in my previous emails. > > As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to > mention known existing implementations, especially open source, even if just PoC. I did not hear a WG consensus to add a section on known implementations. I did not object to it, but found it a waste of time as it will be removed before publication. I note that the Shepherd could just reference this thread which contains a number of references to implementations. From nobody Tue Jun 19 08:41:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84A9126F72 for ; Tue, 19 Jun 2018 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5lgpK2uY8Sd for ; Tue, 19 Jun 2018 08:41:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EAD130DEC for ; Tue, 19 Jun 2018 08:41:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 099DE20090; Tue, 19 Jun 2018 11:55:46 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1FE6C1A68; Tue, 19 Jun 2018 11:38:35 -0400 (EDT) To: Brian E Carpenter , anima@ietf.org References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <26062.1527793635@localhost> <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> <32127.1527795086@localhost> <30241f79-8b8e-d98a-1f00-0a1f2e13cbca@gmail.com> From: Michael Richardson Message-ID: <2e4df164-e528-1b00-6200-40cd45bbfbf8@sandelman.ca> Date: Tue, 19 Jun 2018 11:38:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <30241f79-8b8e-d98a-1f00-0a1f2e13cbca@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 15:41:39 -0000 On 31/05/18 04:23 PM, Brian E Carpenter wrote: > On 01/06/2018 07:31, Michael Richardson wrote: >> >> Toerless Eckert wrote: >> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: >> >> > I would prefer to have the simple definition "ANI == systems that support >> >> > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative >> >> > normative document for ANI, so it should simply be stated equally in BRSKI and >> >> > ACP. Rest of text is fine. >> >> >> >> I'm not getting what you are suggesting. >> >> I think you are saying that we shouldn't point at ACP for the ANI term, but >> >> rather define it ourselves? >> >> > Yes. >> >> okay, I've copied text: >> >> ANI: "Autonomic Network Infrastructure". The ANI is the >> infrastructure to enable Autonomic Networks. It includes ACP, >> BRSKI and GRASP. Every Autonomic Network includes the ANI, >> but not every ANI network needs to include autonomic functions >> beyond the ANI (nor intent). An ANI network without further >> autonomic functions can for example support secure zero touch bootstrap >> and stable connectivity for SDN networks - see >> [I-D.ietf-anima-stable-connectivity] >> > > Wrong answer, IMHO. > > draft-ietf-anima-reference-model defines the ANI at some length. > That should be the (informative) reference for basic terminology. I think that you'd like us to change the text to say: The Autonomic Network Infrastructure as defined by . This document details specific requirements for pledges, proxies and registrars when they are part of an ANI. is this correct? Or did you want us to retain some other words above? From nobody Tue Jun 19 10:15:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB2E131185; Tue, 19 Jun 2018 10:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPKCr4s5DfwW; Tue, 19 Jun 2018 10:15:35 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA66130DFF; Tue, 19 Jun 2018 10:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3744; q=dns/txt; s=iport; t=1529428535; x=1530638135; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BFcXvSNWlGKgMYLKTnUzLRMeezrUrM9vACui9590I6Y=; b=cNG6xOOu3hC+FJ//rrvx12R0BLubBOZVFPcu8ol+/ANlqlfD+jFPcZBs 6UeGk2pPbZlnNEGAamx4P1pojzADmsSksTqaO5hv3phGP4uYTy4/YGLGH sxioH6nOKtb+s34I9yKg7WLpYBkU7bpWDlGhJvXDIYoTDMOYBmOKez0T4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgCBOSlb/4gNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8oCoNvlFWCAJR7gXgLGAuBVIJ1AheCVyE1FwECAQE?= =?us-ascii?q?BAQEBAm0cDIUoAQEBAwEBASERNgQLBQsCAQYCDgoCAiYCAgIlCxUQAgQOBYM?= =?us-ascii?q?lAYF3CA+QYptHghyISIFjBYELh0mCE4EPJIJogxMBAYFggwExgiQCjD6MYQk?= =?us-ascii?q?Chm6BcIYvgT+LfpEsAhETAYEkHgE2gVJwFTsqAYIYgiEXiFmFPm+LNoEaAQE?= X-IronPort-AV: E=Sophos;i="5.51,243,1526342400"; d="scan'208";a="131263961" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 17:15:34 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w5JHFYPS021401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2018 17:15:34 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 19 Jun 2018 12:15:34 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Tue, 19 Jun 2018 12:15:34 -0500 From: "Max Pritikin (pritikin)" To: Carsten Bormann CC: Michael Richardson , "cbor@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] CDDL-02 section 2.2.2 choices Thread-Index: AQHUB9/T4H6EDf6GI0Ga7rncl8Sqt6RoBjQAgAAgIIA= Date: Tue, 19 Jun 2018 17:15:34 +0000 Message-ID: References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> In-Reply-To: <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> 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.4] Content-Type: text/plain; charset="utf-8" Content-ID: <0EA05333EC660C4CB8C8D5DB307841A9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 17:15:38 -0000 DQoNCj4gT24gSnVuIDE5LCAyMDE4LCBhdCA5OjIwIEFNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBNaWNoYWVsLA0KPiANCj4gMi4yLjIgc2F5czoNCj4g DQo+ICAgSXQgaXMgbm90IGFuIGVycm9yIGlmIGEgbmFtZSBpcyBmaXJzdCB1c2VkIHdpdGggYSAi Lz0iIG9yICIvLz0iDQo+ICAgKHRoZXJlIGlzIG5vIG5lZWQgdG8g4oCcY3JlYXRlIGl0IiB3aXRo ICI94oCcKS4NCg0KV2UgbXVzdCBoYXZlIGFic29yYmVkIHRoaXMgc2VudGVuY2Ugdy9vIG5vdGlj aW5nIGl0LiANCg0KPiANCj4gVGhlIGludGVudGlvbiBpcyBpbmRlZWQgdG8gc2F5IHRoYXQgbm8g aW5pdGlhbCBydWxlIHdpdGggYSDigJw94oCcIGlzIG5lZWRlZC4NCj4gQW55IGlkZWFzIGhvdyB3 ZSBjYW4gY2xhcmlmeSB0aGlzIHNvbWUgbW9yZT8NCg0KSSB3b3VsZCBoZWxwIGlmIHRoZSB1c2Ug b2YgLz0gb3IgLy89IGlzIGNsYXJpZmllZCB0byBiZSBhIG1lc3NhZ2UgdG8gaW1wbGVtZW50b3Jz IHRoYXQgZnV0dXJlIHZhbHVlcyBzaG91bGQgYmUgZXhwZWN0ZWQgYW5kIGhhbmRsZWQgYXBwcm9w cmlhdGVseS4gQXMgaXQgcmVhZHMsIGluIGNvbmNlcnQgd2l0aCB0aGUgZmlyc3Qgc2VudGVuY2Ug b2YgdGhlIG5leHQgc2VjdGlvbiAo4oCcSW5zdGVhZCBvZiBuYW1pbmcgYWxsIHRoZSB2YWx1ZXMg dGhhdCBtYWtlIHVwIGEgY2hvaWNl4oCdKSwgSSBmaW5kIG15c2VsZiB1bnN1cmUgYXMgdG8gdGhl IG5lZWQgZm9yIGEgc2VudGVuY2Ugc3VjaCBhcyB3ZeKAmXZlIHByb3ZpZGVkLiBEbyB3ZSBuZWVk IHRvIGluZm9ybSBpbXBsZW1lbnRvcnMgdGhhdCBmdXR1cmUgdmFsdWVzIE1BWSBiZSBzZWVuPyBX aGF0IGlmIHdlIGludGVuZGVkIHRoYXQgZnV0dXJlIHZhbHVlcyBNVVNUIE5PVCBiZSBpbmNsdWRl ZD8gDQoNCkl0cyByZWFzb25hYmxlIGZvciBDRERMIHRvIGRlY2xhcmUgdGhhdCBvdXQtb2Ytc2Nv cGU7IGluIHdoaWNoIGNhc2UgdGhlIGN1cnJlbnQgbGFuZ3VhZ2UgbG9va3Mgc3VmZmljaWVudCBi dXQgaXQgd291bGQgbWVhbiB1c2Ugb2YgQ0RETCBpbiB0aGlzIGFyZWEgd2lsbCBvZnRlbiBoYXZl IGFuIGFkZGl0aW9uYWwgc2VudGVuY2UgdG8gY2xhcmlmeSBmb3IgaW1wbGVtZW50b3JzLg0KDQot IG1heA0KDQo+IA0KPiBZb3UgY291bGQgYWxzbyBtYWtlIHVzZSBvZiB0aGUgY29udmVudGlvbiAo bm90IGN1cnJlbnRseSBjaGVja2VkIGJ5IGFueSB0b29sLCBidXQgdGhhdCBjb3VsZCBiZSBkb25l KSB0byBtYXJrIGFuIGV4dGVuc2lvbiBwb2ludCB3aXRoIGEgZG9sbGFyIHNpZ246DQo+IA0KPiAk dHJhbnNwb3J0LXByb3RvIC89IElQUFJPVE9fVENQDQo+IA0KPiAoU2VlIHNlY3Rpb24gMy45IGZv ciBtb3JlIGFib3V0IHRoYXQgY29udmVudGlvbi4pDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+ IA0KPiANCj4+IE9uIEp1biAxOSwgMjAxOCwgYXQgMTc6MDgsIE1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4+IA0KPj4gU2lnbmVkIFBHUCBwYXJ0DQo+ PiANCj4+IEluIGRyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0xNSwgd2Ug c3BlY2lmeSBhIHByb3RvY29sIHZhbHVlDQo+PiBmb3IgR1JBU1AuICBJbiB0aGlzIG5vcm1hdGl2 ZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCwgdGhlcmUgaXMgb25seSBvbmUgY2hvaWNlLA0KPj4gYnV0 IGl0IGlzIG91ciBpbnRlbnRpb24gdG8gYWxsb3cgYWRkaXRpb25hbCBjaG9pY2VzLCBhcyBwZXIg c2VjdGlvbiAyLjIuMg0KPj4gb2YgY2RkbC0wMi4NCj4+IA0KPj4gV2UgdGhpbmsgdGhhdCB3ZSBz aG91bGQgc3BlY2lmeSBvdXIgc2luZ2xlICJjaG9pY2UiLCB1c2luZyAvPSwgcmF0aGVyIHRoYW4g PSwNCj4+IGFzIHRoaXMgc2hvdWxkIGNsdWUgdGhlIHJlYWRlciBpbiB0byBleHBlY3QgbXVsdGlw bGUgdmFsdWVzIGhlcmUuDQo+PiANCj4+IEZyb20gb3VyIGRvY3VtZW50Og0KPj4gDQo+PiB0cmFu c3BvcnQtcHJvdG8gLz0gSVBQUk9UT19UQ1AgICA7IG5vdGUgdGhpcyBpcyBhbiBleHRlbnNpYmxl IENEREwgY2hvaWNlDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBhbmQgY2Fu IGJlIGFkZGVkIHRvIGluIHN1YnNlcXVlbnQNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA7IHNwZWNpZmljYXRpb25zIHVzaW5nIHRoZSAvPSBhbmQgLy89DQo+PiANCj4+IEl0IGlz IHVuY2xlYXIgaW4gc2VjdGlvbiAyLjIuMiBpZiB3ZSBjYW4gc2F5IGZvbyAvPSB3aXRob3V0IGhh dmluZyBzYWlkDQo+PiAgZm9vID0gMSAvIDIgLyAzDQo+PiBwcmV2aW91c2x5LCBidXQgaXQgc2Vl bXMgbGlrZSBpdCBzaG91bGQgYmUgcmVhc29uYWJsZSB0byBkbyBpbiBvcmRlciB0bw0KPj4gaW5k aWNhdGUgdGhhdCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGV4cGVjdCBmdXR1cmUgdmFsdWVzLg0K Pj4gDQo+PiAtLQ0KPj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0N Cj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= From nobody Tue Jun 19 10:56:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA841311BD; Tue, 19 Jun 2018 10:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxr2SSgdz-e6; Tue, 19 Jun 2018 10:56:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D191311BB; Tue, 19 Jun 2018 10:56:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BA5D20090; Tue, 19 Jun 2018 14:10:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F02811A69; Tue, 19 Jun 2018 13:53:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id ED95B1A68; Tue, 19 Jun 2018 13:53:45 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org, anima@ietf.org In-Reply-To: <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 17:56:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > 2.2.2 says: >> It is not an error if a name is first used with a "/=3D" or "//=3D" >> (there is no need to =E2=80=9Ccreate it" with "=3D"). > The intention is indeed to say that no initial rule with a =E2=80=9C= =3D=E2=80=9C is needed. > Any ideas how we can clarify this some more? Neither Max nor I saw this while we were perusing this part. May I suggest that it be moved to be the second paragraph? > You could also make use of the convention (not currently checked by a= ny > tool, but that could be done) to mark an extension point with a dollar > sign: > $transport-proto /=3D IPPROTO_TCP > (See section 3.9 for more about that convention.) Ah, interesting. thank you. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWylDJ4CLcPvd0N1lAQILQAf/UT3ocGN3gGhn+YBsAIVYOjc8fwcRcXho t6n5T0tI6Jfp4mu8K1+nnu5k5gsPs3wfD3KkHIxELX99e90YqXlwVg+YmDT87Jgy do5mAisMWJhS/cRXvp4T1Zygv70GXoSwEJEg312yPZlwF+BGLb4cyojt/eUIlxy3 /eoqo204Nveq7h2X15eyil1MDjEJ3o51m7+Hr4FeTdC5imt6DTtpVWxcOTGyEgfm Pn7PE5vTPByW04yYND4MC/LVGlGl+IzBO5UjSAzim5vbqGkLqSmB8yoEsJkgxah1 pFR3COINej3IPdLwAAb3K5RXjERB8ERVJt9DYoF9PRb0240bGIB80Q== =sfbz -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 19 13:24:36 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89364130EC8 for ; Tue, 19 Jun 2018 13:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVJ45QUrOOmZ for ; Tue, 19 Jun 2018 13:24:33 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF6A130E6E for ; Tue, 19 Jun 2018 13:24:33 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id m5-v6so381912pgd.3 for ; Tue, 19 Jun 2018 13:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6gVD0IrTgM08mtFhgkntoftm6SmsqQhmye4VsMTLcIQ=; b=tcIRyigIfpWurEXYKoU8zmh3cHllgWKb3RrCuF5/QsRjfqc93zHxAlau3Z86jsm0pl jgG2Yr1hmLsklhsq+8pSOGakyl58crl9igBINpKWu/DCLp/e+Si7HAuxom9UoIPMs8n+ ezUsjF/8sVwE+aIw099D6mArzMghApdcrgBDHqYBfraY59wIbvFP8BnlNYyEsAstkVip wmDTRuCpYpZSpRcd2UHc2zoB3QwyBEyTl7XpHT2pjTADCrkpgKM454UX/p817q2dnQ2W /zE2afqPucXrb1ZWOU9+xybZZZT55c4Ha8dSz2IPCvTYkqMhR0FiA7E5uCo5LvMrYSL6 kKlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6gVD0IrTgM08mtFhgkntoftm6SmsqQhmye4VsMTLcIQ=; b=gPVyJyY0Yyy4OlAXPalNgXJiK+NIsnEB9EaIO5gIflMW5fwLiUOwZvBZ41bZxArK/8 O+BH3HwbT/rhm1YEGHSsWUBd+IgfVj+e8QJD64dt7V3/+pkefPkbgmb9ZNNHGaaT3+j4 hj9l7MW/8j8qog0E3b2/hBGRofUuTBuJCBXJx+lP6xDzsZmvVqw8Odkr7O7kqtLLLfZy /coKetMaopGK4PfwunLjc41yoyzotNtZyKR3ncEIEP5aseJMylzRWjR73K3E/Oqqn1x+ f1hjsAbqu/kblkpJBmnoTrGr0/sMGA8GrwdAjXqcSzvgYmwynF96Hye0ofqBNHgb4BYG v2Lg== X-Gm-Message-State: APt69E3CPEuekOzHIioX5WTtjKFtLsL6vVXujfYSFL3tJdCzASbv69TO u1uDEex2ewLTeeUwaTcPwxNcEg== X-Google-Smtp-Source: ADUXVKJ5WOETDA1C0tw/1olnhb1oYNfaCHYOuPRInir0PTCiyOPgn2uWw/dNJRRspzo5ACS+KhbRBg== X-Received: by 2002:a65:6355:: with SMTP id p21-v6mr15950134pgv.293.1529439872790; Tue, 19 Jun 2018 13:24:32 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id p20-v6sm549327pfn.181.2018.06.19.13.24.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 13:24:31 -0700 (PDT) To: Michael Richardson , anima@ietf.org References: <1812.1529420901@localhost> <5f216303-d326-2324-7a5f-d4e8d1b354c1@sandelman.ca> From: Brian E Carpenter Message-ID: Date: Wed, 20 Jun 2018 08:24:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5f216303-d326-2324-7a5f-d4e8d1b354c1@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] transport-proto IANA considerations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 20:24:36 -0000 On 20/06/2018 03:29, Michael Richardson wrote: > On 19/06/18 11:08 AM, Michael Richardson wrote: >> From our document: >> >> transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice >> ; and can be added to in subsequent >> ; specifications using the /= and //= > In further discussion about whether or not we now need an IANA registry > in BRSKI to deal with this, we concluded that we did not, because GRASP > already dealt with that in section 2.9.5.1, note 3, so we decided to > refer to that instead: > > transport-proto /= IPPROTO_TCP ; note this can be any value from the > ; IANA protocol registry, as per > ; [GRASP] section 2.9.5.1, note 3. > > > We have also removed all referenced to IPPROTO_UDP and IPPROTO_IPV6 from > the normative section. That's a great solution; and as "note 3" says we can always add an IANA registry if we want values outside 0..255 for some reason. (It's an obvious convention to use the same symbolic names as the socket API, but that doesn't seem necessary to state.) Brian From nobody Tue Jun 19 13:27:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B8D130E3A for ; Tue, 19 Jun 2018 13:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DsXp8aP161q for ; Tue, 19 Jun 2018 13:27:05 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55F7130EC8 for ; Tue, 19 Jun 2018 13:27:05 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id 31-v6so451290plc.4 for ; Tue, 19 Jun 2018 13:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=GMn9OwnF+J9/6p/iJrk115cE4bVf/y0osfa9VgluIP4=; b=HF0dpQjPqeYMErIYNdVLJ9ukirg7tHWEzPc5hjLaLocvLFeP3Jdl9N2n1fO14SGM4t ihg6Xfi+4DVkVd7e0xXTaf0zt7xjOJBmHSRuFbWAxSZf4Lm2MK41wxndm4OOFB2dV4I8 P8CLSORfCwymzcJ4rVdXLnkSa2SupmBPc2wchj1hPsY1xwEnZaFf7BIOZKoChAriZZvA hdjfkdRh79XAXGoOwZg5XrMdRMrzT2FD3dy6IATEbUodAfiDdHtZssxUUFOu7Tag7faf jR0GdVGkaDxfRcuIK6dAYboaip1OYirlv3yCCbMTqHA5LgCEwPb51rxM4CaZUoUdAeSC pdvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GMn9OwnF+J9/6p/iJrk115cE4bVf/y0osfa9VgluIP4=; b=NZYsD6qOnphaQlK95hdsc7QTGPSI1CCUFYzGOCob3jA/kuu8hTsvCTYqcesP/AGzTH a6bkdBIw6PbUG7Fnqj+Uw+U1D6zkOHyRefx1N9EiqUy0WL++A5JyfMynkvsL8V255B7J TsXG6gpHJfVyGM9FuWMNrS6U4818mlyxZehzZxWgd3VSQ4RdXJKQ/JCI0lSVp/Zt1N8y lfUPLIBnBsFcpJJDQpAQBHP7rIWFnQhhvU3FsnMSxBzNI49dvJIEgTLj1OrRTGp+Vfa2 SMUuOuiOuu2LNrQHT2r+WO3xbSDbCwbXZW2HIfAbRFCTk3gyVvfe5JzBMiudspEimuq1 JKOg== X-Gm-Message-State: APt69E10dVlFtM7c0pOOM2ZVKNMKkY/PX9LiTarKQi2D3PG0Q873F2uD frXhAHhYyClikVPcL3bOgrRHgA== X-Google-Smtp-Source: ADUXVKISAbIk/jX5ri2Nt30tn1RY509YjLB8PF+jzNiGd/zlWgjAJ43MjwdT2TpbSRrsLWXSVZNnZw== X-Received: by 2002:a17:902:b217:: with SMTP id t23-v6mr20595481plr.312.1529440024991; Tue, 19 Jun 2018 13:27:04 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id o13-v6sm271849pgp.50.2018.06.19.13.27.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 13:27:04 -0700 (PDT) To: Michael Richardson , anima@ietf.org References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <26062.1527793635@localhost> <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> <32127.1527795086@localhost> <30241f79-8b8e-d98a-1f00-0a1f2e13cbca@gmail.com> <2e4df164-e528-1b00-6200-40cd45bbfbf8@sandelman.ca> From: Brian E Carpenter Message-ID: <080ea9e8-555f-a686-25ff-b4cbe20a442a@gmail.com> Date: Wed, 20 Jun 2018 08:27:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2e4df164-e528-1b00-6200-40cd45bbfbf8@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 20:27:08 -0000 On 20/06/2018 03:38, Michael Richardson wrote: > On 31/05/18 04:23 PM, Brian E Carpenter wrote: >> On 01/06/2018 07:31, Michael Richardson wrote: >>> >>> Toerless Eckert wrote: >>> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: >>> >> > I would prefer to have the simple definition "ANI == systems that support >>> >> > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative >>> >> > normative document for ANI, so it should simply be stated equally in BRSKI and >>> >> > ACP. Rest of text is fine. >>> >> >>> >> I'm not getting what you are suggesting. >>> >> I think you are saying that we shouldn't point at ACP for the ANI term, but >>> >> rather define it ourselves? >>> >>> > Yes. >>> >>> okay, I've copied text: >>> >>> ANI: "Autonomic Network Infrastructure". The ANI is the >>> infrastructure to enable Autonomic Networks. It includes ACP, >>> BRSKI and GRASP. Every Autonomic Network includes the ANI, >>> but not every ANI network needs to include autonomic functions >>> beyond the ANI (nor intent). An ANI network without further >>> autonomic functions can for example support secure zero touch bootstrap >>> and stable connectivity for SDN networks - see >>> [I-D.ietf-anima-stable-connectivity] >>> >> >> Wrong answer, IMHO. >> >> draft-ietf-anima-reference-model defines the ANI at some length. >> That should be the (informative) reference for basic terminology. > > I think that you'd like us to change the text to say: > > The Autonomic Network Infrastructure as > defined by . > This document details specific requirements for pledges, > proxies and registrars when they are part of an ANI. > > is this correct? Or did you want us to retain some other words above? > Personally, I'm happy with the reference (and with it being informational). Duplication of definitions always creates a risk of confusion. Brian From nobody Tue Jun 19 13:46:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512A8130F27; Tue, 19 Jun 2018 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mCvf3hduwkU; Tue, 19 Jun 2018 13:45:58 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A536C130F0D; Tue, 19 Jun 2018 13:45:58 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id k1-v6so478697plt.2; Tue, 19 Jun 2018 13:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Tc2PnTxWVP5Ii7YVpiN/b+I5nxwg64yNQLZFpzuByhs=; b=D4fBwetOCdKYsxAyiSntjsH5P3z45l17GQjfHaaWQwO9d5USNtAk8xl9aYjMm3rrwr 79szgN7RUQeAQCt0WHZoGvTlsNva+mtxedflf6YKvO0AjqLVK62eYqz9klJE8qDSuMzc rJWBH3ATyeID9W9OKMR889mp4kwqToZZPt9cvhijxBSqIz7Sf2yEvfyL9TBVoaKzehSx A72KPu7rWyhU1BzZ2qFzT9BmMklbNt16oB8LC6WZOO79oaWNHVwTO2JtjmtfTmi1C4W0 MWnVbANbQbsP9ubDoG4Sei0g1fDorptl+CvZntVDXij2GaXMtF1LwcC1Jyz2Kj+UEGhW /Vxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Tc2PnTxWVP5Ii7YVpiN/b+I5nxwg64yNQLZFpzuByhs=; b=gHGZ+JykLKPN78+YNyzIrXBnGpuO4zAnHk07giK9Q66zBd+eTkRo5Fz9eETXbv2Pdm Y9/PBNUdos/9mRO6NCkjVejBiDbfcTxtH7ABPl4E3Xy5/z7pUbZOWfWQwd0Jg9meobXv 7OfrOqkTdQKIm32gyNS38HERKIkxV5qUeG1WrOL4MUiZCm6iv5E7ce5yy2sl0PJTp9XQ RBbaSN4zJNgn0aD7sEs9wSUs3dDHQFE8dwOg4srtMmR6nr4g1oUlYFySyMMczI7JSVAO FyyySzSajR6p1DMynZidceb0RLUij+1bvpYKKxkFQFq7xGRNUtDLsMSf9uhGu9duKZQh rPYA== X-Gm-Message-State: APt69E0qm3OsXm+WjOe9B+WVLj46FIe5JzJGjTZ6pkC1slzEznqFgd0D SpHwZXvaLz2iMQ5q/pvSyUVPCA== X-Google-Smtp-Source: ADUXVKKABNyX79nGVmOJpWV1MdWhtxlnJ8jNVQ+z+HBEPa5MgLCamKavHp9EUxHDLd8CQiHcomfouw== X-Received: by 2002:a17:902:981:: with SMTP id 1-v6mr20679515pln.11.1529441157712; Tue, 19 Jun 2018 13:45:57 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z3-v6sm659545pfn.36.2018.06.19.13.45.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 13:45:56 -0700 (PDT) To: Michael Richardson , Carsten Bormann Cc: cbor@ietf.org, anima@ietf.org References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> <4918.1529430825@localhost> From: Brian E Carpenter Message-ID: <8dd31a39-6e66-b7fe-845b-c9ffe3eb02a2@gmail.com> Date: Wed, 20 Jun 2018 08:45:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <4918.1529430825@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] [Cbor] CDDL-02 section 2.2.2 choices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 20:46:02 -0000 On 20/06/2018 05:53, Michael Richardson wrote: >=20 > Carsten Bormann wrote: > > 2.2.2 says: >=20 > >> It is not an error if a name is first used with a "/=3D" or "//=3D= " > >> (there is no need to =E2=80=9Ccreate it" with "=3D"). >=20 > > The intention is indeed to say that no initial rule with a =E2=80= =9C=3D=E2=80=9C is needed. > > Any ideas how we can clarify this some more? >=20 > Neither Max nor I saw this while we were perusing this part. > May I suggest that it be moved to be the second paragraph? >=20 > > You could also make use of the convention (not currently checked = by any > > tool, but that could be done) to mark an extension point with a d= ollar > > sign: >=20 > > $transport-proto /=3D IPPROTO_TCP >=20 > > (See section 3.9 for more about that convention.) >=20 > Ah, interesting. thank you. However: I suggest not using that in the BRSKI draft. Our emergency plan if CDDL is not yet close to being an RFC is to add a normative appendix to GRASP specifying the subset of CDDL that we use, and I'd like to keep that subset as small as possible. Even better, CBOR could wrap up the CDDL spec in Montreal. Regards Brian From nobody Tue Jun 19 14:50:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AE8130F4C for ; Tue, 19 Jun 2018 14:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 vPHx0dIt_Amg for ; Tue, 19 Jun 2018 14:50:25 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3DA130F4A for ; Tue, 19 Jun 2018 14:50:25 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E2F6458C4B2; Tue, 19 Jun 2018 23:50:20 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D0FEC4401A4; Tue, 19 Jun 2018 23:50:20 +0200 (CEST) Date: Tue, 19 Jun 2018 23:50:20 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Michael Richardson , anima@ietf.org Message-ID: <20180619215020.doaopumqqynhl4ic@faui48f.informatik.uni-erlangen.de> References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <26062.1527793635@localhost> <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> <32127.1527795086@localhost> <30241f79-8b8e-d98a-1f00-0a1f2e13cbca@gmail.com> <2e4df164-e528-1b00-6200-40cd45bbfbf8@sandelman.ca> <080ea9e8-555f-a686-25ff-b4cbe20a442a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <080ea9e8-555f-a686-25ff-b4cbe20a442a@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 21:50:29 -0000 Brian, Michael: For the purpose of BRSKI the only relevant aspect of the ANI is that it is assumed to be a system that support BRSKI and ACP, and then the document starts to define a bunch of requirements against BRSKI, which instead of saying ANI could equally say "BRSKI devices that also support ACP". So BRSKi really does not need to try to refer to a complete definition of ANI or attempt one by itself, but rather clarify the relationship to ANI that is used in the BRSKI document. To maintain the independence of BRSKI from unnecessary normative references, maybe something like the following: The Autonomic Network Infrastructure consists of devices supporting both BRSKI and (ACP). In ANI devices, BRSKI relies ACP to connect BRSKI Registrar and BRSKI Proxies. Not sure what value a reference to the reference model would have here in this terminology. Cheers Toerless On Wed, Jun 20, 2018 at 08:27:04AM +1200, Brian E Carpenter wrote: > On 20/06/2018 03:38, Michael Richardson wrote: > > On 31/05/18 04:23 PM, Brian E Carpenter wrote: > >> On 01/06/2018 07:31, Michael Richardson wrote: > >>> > >>> Toerless Eckert wrote: > >>> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: > >>> >> > I would prefer to have the simple definition "ANI == systems that support > >>> >> > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative > >>> >> > normative document for ANI, so it should simply be stated equally in BRSKI and > >>> >> > ACP. Rest of text is fine. > >>> >> > >>> >> I'm not getting what you are suggesting. > >>> >> I think you are saying that we shouldn't point at ACP for the ANI term, but > >>> >> rather define it ourselves? > >>> > >>> > Yes. > >>> > >>> okay, I've copied text: > >>> > >>> ANI: "Autonomic Network Infrastructure". The ANI is the > >>> infrastructure to enable Autonomic Networks. It includes ACP, > >>> BRSKI and GRASP. Every Autonomic Network includes the ANI, > >>> but not every ANI network needs to include autonomic functions > >>> beyond the ANI (nor intent). An ANI network without further > >>> autonomic functions can for example support secure zero touch bootstrap > >>> and stable connectivity for SDN networks - see > >>> [I-D.ietf-anima-stable-connectivity] > >>> > >> > >> Wrong answer, IMHO. > >> > >> draft-ietf-anima-reference-model defines the ANI at some length. > >> That should be the (informative) reference for basic terminology. > > > > I think that you'd like us to change the text to say: > > > > The Autonomic Network Infrastructure as > > defined by . > > This document details specific requirements for pledges, > > proxies and registrars when they are part of an ANI. > > > > is this correct? Or did you want us to retain some other words above? > > > > Personally, I'm happy with the reference (and with it being informational). > Duplication of definitions always creates a risk of confusion. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 19 14:56:05 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1FB130F6A for ; Tue, 19 Jun 2018 14:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 XvyJvobCfXuT for ; Tue, 19 Jun 2018 14:56:01 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907B2130F75 for ; Tue, 19 Jun 2018 14:55:58 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 66AE858C4B2; Tue, 19 Jun 2018 23:55:54 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5547D4401A4; Tue, 19 Jun 2018 23:55:54 +0200 (CEST) Date: Tue, 19 Jun 2018 23:55:54 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Michael Richardson , anima@ietf.org Message-ID: <20180619215554.l4jwvi7yw7tjlra2@faui48f.informatik.uni-erlangen.de> References: <1812.1529420901@localhost> <5f216303-d326-2324-7a5f-d4e8d1b354c1@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] transport-proto IANA considerations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 21:56:04 -0000 Fine with me, i was just worried about a syntactical stickler complaining how a comment ("note this can be...) is no replacement for a correct formal definition, but i will certainly not be that stickler. (Likewise i would't have a formal argument to reject such a stickler, but ould only resort to "don't be such a stickler") Cheers Toerless On Wed, Jun 20, 2018 at 08:24:31AM +1200, Brian E Carpenter wrote: > On 20/06/2018 03:29, Michael Richardson wrote: > > On 19/06/18 11:08 AM, Michael Richardson wrote: > >> From our document: > >> > >> transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice > >> ; and can be added to in subsequent > >> ; specifications using the /= and //= > > In further discussion about whether or not we now need an IANA registry > > in BRSKI to deal with this, we concluded that we did not, because GRASP > > already dealt with that in section 2.9.5.1, note 3, so we decided to > > refer to that instead: > > > > transport-proto /= IPPROTO_TCP ; note this can be any value from the > > ; IANA protocol registry, as per > > ; [GRASP] section 2.9.5.1, note 3. > > > > > > We have also removed all referenced to IPPROTO_UDP and IPPROTO_IPV6 from > > the normative section. > > That's a great solution; and as "note 3" says we can always add an > IANA registry if we want values outside 0..255 for some reason. > > (It's an obvious convention to use the same symbolic names as > the socket API, but that doesn't seem necessary to state.) > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 19 15:07:53 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA740130E63 for ; Tue, 19 Jun 2018 15:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 9Gcxt5cFZEkZ for ; Tue, 19 Jun 2018 15:07:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84F1130E1D for ; Tue, 19 Jun 2018 15:07:47 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9B70458C4B2; Wed, 20 Jun 2018 00:07:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8BC874401A4; Wed, 20 Jun 2018 00:07:43 +0200 (CEST) Date: Wed, 20 Jun 2018 00:07:43 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20180619220743.3zlo7oagjenjffba@faui48f.informatik.uni-erlangen.de> References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <6ca37514-0a83-598c-ec9b-5dc007efc3e6@cisco.com> <20180531184347.dij2ppvvktnjcixx@faui48f.informatik.uni-erlangen.de> <60cb0d42-eb0b-7936-acff-d12539dc1193@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60cb0d42-eb0b-7936-acff-d12539dc1193@sandelman.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] references to code ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 22:07:50 -0000 I did not push this further because it seemed non-obvious to me after the discussion here, what would be needed to include the information in the final RFC and whether that would be appreciated by others. I hope in the absence of suhc text, there is motivation for a small followup RFC with implementation experience after we have the RFC. Wrt to providing implementation information as input to the reviewers, i will be happy to include it into the shepherd writeup for the IESG once i can close the last call. Cheers Toerless On Tue, Jun 19, 2018 at 11:31:50AM -0400, Michael Richardson wrote: > On 31/05/18 02:43 PM, Toerless Eckert wrote: > > Thanks, Eliot > > > > Good point, forgot to ask/mention this point in my previous emails. > > > > As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to > > mention known existing implementations, especially open source, even if just PoC. > > I did not hear a WG consensus to add a section on known implementations. > > I did not object to it, but found it a waste of time as it will be removed > before publication. I note that the Shepherd could just reference this > thread which contains a number of references to implementations. > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 19 15:13:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0800C130E99 for ; Tue, 19 Jun 2018 15:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 nS4aou2-G2FO for ; Tue, 19 Jun 2018 15:13:20 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696C9130E87 for ; Tue, 19 Jun 2018 15:13:20 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6E0A458C4B2; Wed, 20 Jun 2018 00:13:16 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5BB754401A4; Wed, 20 Jun 2018 00:13:16 +0200 (CEST) Date: Wed, 20 Jun 2018 00:13:16 +0200 From: Toerless Eckert To: Toerless Eckert Cc: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra-all@ietf.org Message-ID: <20180619221316.rj7gge77x3xeiexj@faui48f.informatik.uni-erlangen.de> References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 22:13:22 -0000 We had positive feedback on the last call, and no negative feedback. For the time being (or until someone with more experience than me shows me a better option ;-), i will not declare the last-call finished, until the authors had a chance to answer how they want to resolve the last-call comment from me about the only mayor issue, which was how to make GRASP announcemments for IP-in-IP work. As said in before, any solution that works is fine. Including moving IP-in-IP out to another doc. Cheers toerless On Thu, May 31, 2018 at 03:56:08AM +0200, Toerless Eckert wrote: > Dear ANIMA WG, > > After thorough review and discussions on the mailing list and in bootstrap > meetings, leading to the -15 version the authors and WG chairs think the draft > is now mature enough for working group last call. > > This e-mail starts a two-weeks period for evaluation of this document by the WG. > > Please provide your feedback on the ANIMA mailing list by end of June 14th, 2018. > > Thanks and best regards > > Toerless (for the ANIMA chairs). > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 19 16:12:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167DA130FF5 for ; Tue, 19 Jun 2018 16:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXZFY45lLo4O for ; Tue, 19 Jun 2018 16:11:57 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C62130FF7 for ; Tue, 19 Jun 2018 16:11:56 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id g26-v6so373973pgn.11 for ; Tue, 19 Jun 2018 16:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RLZBY18deOZ2/kV/cDtA4KX55i2fqeCB1UGlpkFW1uc=; b=DZHzPv/ZSDgGkMGeUm3M2010CGUjrTCSBeX7W2uuU9LOl8BRtMZsfwUiO8XllU9pe2 J7cgcbkODVllwK+88ftnw66ZNfKCPiP3qn/sNAuZ2hGf65KCsvBigPzIqDXWRXTh0ajA LnVVibAngZsJMCYEeR5yX4r20RZHjkPJBTTRXNXoced0seIMDoigCgNCXw9GycR0IVz1 S2RFRT36GSPEFurR28PK+zB8dARDVwPZd02m4316aCvkrb3QEkcSQkwFkObBh7elz+G3 7q7lHoxDGJO8hy+kyyWJUqriACuHKRpZ67jD9agAtn/TWlQmLyEYVLoCvujK3cgpFL3G 0YEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RLZBY18deOZ2/kV/cDtA4KX55i2fqeCB1UGlpkFW1uc=; b=h9ufcvw3ZGV1D3LvXC2wVWgvy7CHNL7HZH1/1UaMSGvvW10txU7oRnl3Blq9y2XPtx QovEpassewwJnLoYy0G3OaoNOcwx1pfO+6kzS+upzHyK9nyR56P2voovtwggZ18pkFWB e77+fGwBR5h+ck9SJS/rO80MWcQ+TwB7EcRd6ETpTCTsuIZKZMWVdEI/uMFFd+84396l I3DGd/ctJdw7dO2YHX2Ir8eSYHDG4QmK7BSUHXjZQbbwoIMx6OhmQW3rYLFsHOocfe45 PCJi0Nt59cEJY6UXNG8o+9tR1STaBAAQP4wi1EhCF01UMpjJIH/7u91cRBIonU0f6b9+ JVQA== X-Gm-Message-State: APt69E0fxCM1e38NjSHv7E2tDaFdvkDJ4jt0j7vf/mWbJgVpk1+5b6Cg 5HQc3av2Lg8d8nTBsQccIz6+UA== X-Google-Smtp-Source: ADUXVKKmrondxgDwYUaMwmk+b2iLiE+O31517Tptrsf2n7Y0GNLl3fWMJbfN+29RfDj4/NyQK8SWCQ== X-Received: by 2002:a65:4081:: with SMTP id t1-v6mr16894795pgp.32.1529449916088; Tue, 19 Jun 2018 16:11:56 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id p20-v6sm841135pfn.181.2018.06.19.16.11.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 16:11:55 -0700 (PDT) To: Toerless Eckert Cc: Michael Richardson , anima@ietf.org References: <20180531015321.stnyefwn22x5cpwf@faui48f.informatik.uni-erlangen.de> <26062.1527793635@localhost> <20180531190943.3pijsvlivf53ig2y@faui48f.informatik.uni-erlangen.de> <32127.1527795086@localhost> <30241f79-8b8e-d98a-1f00-0a1f2e13cbca@gmail.com> <2e4df164-e528-1b00-6200-40cd45bbfbf8@sandelman.ca> <080ea9e8-555f-a686-25ff-b4cbe20a442a@gmail.com> <20180619215020.doaopumqqynhl4ic@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <1f6e542d-bf5b-34a2-9617-41f4dcec70e9@gmail.com> Date: Wed, 20 Jun 2018 11:11:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180619215020.doaopumqqynhl4ic@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:12:01 -0000 On 20/06/2018 09:50, Toerless Eckert wrote: > Brian, Michael: For the purpose of BRSKI the only relevant aspect of the > ANI is that it is assumed to be a system that support BRSKI and ACP, > and then the document starts to define a bunch of requirements against > BRSKI, which instead of saying ANI could equally say "BRSKI devices that > also support ACP". So BRSKi really does not need to try to refer to a > complete definition of ANI or attempt one by itself, but rather clarify > the relationship to ANI that is used in the BRSKI document. > > To maintain the independence of BRSKI from unnecessary normative > references, maybe something like the following: I don't really care, but in any case the reference model will always be a "background reading" sort of reference, i.e. Informative. Brian > > The Autonomic Network Infrastructure consists > of devices supporting both BRSKI and (ACP). > In ANI devices, BRSKI relies ACP to connect BRSKI Registrar and > BRSKI Proxies. > > Not sure what value a reference to the reference model would have here in this terminology. > > Cheers > Toerless > > On Wed, Jun 20, 2018 at 08:27:04AM +1200, Brian E Carpenter wrote: >> On 20/06/2018 03:38, Michael Richardson wrote: >>> On 31/05/18 04:23 PM, Brian E Carpenter wrote: >>>> On 01/06/2018 07:31, Michael Richardson wrote: >>>>> >>>>> Toerless Eckert wrote: >>>>> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: >>>>> >> > I would prefer to have the simple definition "ANI == systems that support >>>>> >> > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative >>>>> >> > normative document for ANI, so it should simply be stated equally in BRSKI and >>>>> >> > ACP. Rest of text is fine. >>>>> >> >>>>> >> I'm not getting what you are suggesting. >>>>> >> I think you are saying that we shouldn't point at ACP for the ANI term, but >>>>> >> rather define it ourselves? >>>>> >>>>> > Yes. >>>>> >>>>> okay, I've copied text: >>>>> >>>>> ANI: "Autonomic Network Infrastructure". The ANI is the >>>>> infrastructure to enable Autonomic Networks. It includes ACP, >>>>> BRSKI and GRASP. Every Autonomic Network includes the ANI, >>>>> but not every ANI network needs to include autonomic functions >>>>> beyond the ANI (nor intent). An ANI network without further >>>>> autonomic functions can for example support secure zero touch bootstrap >>>>> and stable connectivity for SDN networks - see >>>>> [I-D.ietf-anima-stable-connectivity] >>>>> >>>> >>>> Wrong answer, IMHO. >>>> >>>> draft-ietf-anima-reference-model defines the ANI at some length. >>>> That should be the (informative) reference for basic terminology. >>> >>> I think that you'd like us to change the text to say: >>> >>> The Autonomic Network Infrastructure as >>> defined by . >>> This document details specific requirements for pledges, >>> proxies and registrars when they are part of an ANI. >>> >>> is this correct? Or did you want us to retain some other words above? >>> >> >> Personally, I'm happy with the reference (and with it being informational). >> Duplication of definitions always creates a risk of confusion. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jun 19 16:51:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F9C13101E; Tue, 19 Jun 2018 16:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfWpGZ4PjE09; Tue, 19 Jun 2018 16:51:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DADE131012; Tue, 19 Jun 2018 16:51:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C245F20090; Tue, 19 Jun 2018 20:05:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 69BA8F0; Tue, 19 Jun 2018 19:48:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6706497; Tue, 19 Jun 2018 19:48:26 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Carsten Bormann , cbor@ietf.org, anima@ietf.org In-Reply-To: <8dd31a39-6e66-b7fe-845b-c9ffe3eb02a2@gmail.com> References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> <4918.1529430825@localhost> <8dd31a39-6e66-b7fe-845b-c9ffe3eb02a2@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Cbor] CDDL-02 section 2.2.2 choices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 23:51:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > On 20/06/2018 05:53, Michael Richardson wrote: >> >> Carsten Bormann wrote: >> > 2.2.2 says: >> >> >> It is not an error if a name is first used with a "/=3D" or "//= =3D" >> >> (there is no need to =E2=80=9Ccreate it" with "=3D"). >> >> > The intention is indeed to say that no initial rule with a =E2=80= =9C=3D=E2=80=9C is needed. >> > Any ideas how we can clarify this some more? >> >> Neither Max nor I saw this while we were perusing this part. >> May I suggest that it be moved to be the second paragraph? >> >> > You could also make use of the convention (not currently checked b= y any >> > tool, but that could be done) to mark an extension point with a do= llar >> > sign: >> >> > $transport-proto /=3D IPPROTO_TCP >> >> > (See section 3.9 for more about that convention.) >> >> Ah, interesting. thank you. > However: I suggest not using that in the BRSKI draft. Our emergency p= lan > if CDDL is not yet close to being an RFC is to add a normative append= ix > to GRASP specifying the subset of CDDL that we use, and I'd like to > keep that subset as small as possible. > Even better, CBOR could wrap up the CDDL spec in Montreal. I don't believe that BRSKI will enter the RFC-EDITOR queue before CDDL. If it does, we could fix stuff as you suggest. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWymWSICLcPvd0N1lAQIVDQgAiwMEDlV2530FrClTGRuNZLnSEz9Ar8Bo nYPjgJ/MzKUpvtCq1T8B+eiAtAHJByBvbXykkxYQOFTP1VD3YMxJoN5ulwyEss7w IjxZbUP2XSVJuvZVdQqTJf61JlB45s3u3KWunfYsG/b96iYayeSPquUMYyrYS6gb Hi9dmBBw2OwbrTgWxjbuPjFGw7IeYCz2nXQQVxgH+azckuQeYyCBnH6Kv0jhZena tCDHNV5rQajfOhRPCP1SbbIo7AAJUwM8l46X/4lCH/a64hWgZpMUKeTLpPmU2vD0 z57n2UQpfj/Jzkp8dOnKtvetv0YiL8KchKsNDxlbnwC8aFqsUxUxAA== =OFSG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 20 12:20:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0AC1310E0 for ; Wed, 20 Jun 2018 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13Vq14qm-Yjs for ; Wed, 20 Jun 2018 12:20:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780F413109F for ; Wed, 20 Jun 2018 12:20:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EECF420090 for ; Wed, 20 Jun 2018 15:34:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2D24B120B; Wed, 20 Jun 2018 15:17:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2A7EA1205 for ; Wed, 20 Jun 2018 15:17:18 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <20180619221316.rj7gge77x3xeiexj@faui48f.informatik.uni-erlangen.de> References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <20180619221316.rj7gge77x3xeiexj@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 19:20:21 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > the last-call comment from me about the only mayor issue, which was how to > make GRASP announcemments for IP-in-IP work. As said in before, any > solution that works is fine. Including moving IP-in-IP out to another > doc. 1) We removed all references to IPPROTO_IPV6 from the normative text, and also the IPPROTO_UDP, since CoAP version is another draft. 2) We used the //= notation to make it clear that transport-proto was an extension point. We also threw in the $... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyqoO4CLcPvd0N1lAQL3egf/UlrjzXYZzxsWJdTXlhIcQgM0A4af6Ive +1apWd2f+hqlKR4SJNuG0M4eXUken4u32AJvGc5F91526UOEWTIWEXhs16n4nTfe 8LrVOdAiySajMxc7rSEj790P69PW4t/aPdmveAvhLz0q89mXI7xulcq3UFftl0+l /dIq+mtbK1Bm9Vbke/y+g7cbBkRzjlrxOPfYwac1g+tP24LPt4L2yiDk5zX1P0Y+ kTL8WeaSd742Cf1RmnECcnbIiphxi1bNv/SjhadaVY0F2kudJaBQaE788kHoVPiQ 3aMCbX1Kd22IqxcbA9IiysrNsTr+2nDj/6Ad0YV0+khKso2UFoXJwA== =+N6N -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 20 12:27:21 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A79013111F for ; Wed, 20 Jun 2018 12:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4BP-pO_0TRB for ; Wed, 20 Jun 2018 12:27:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A8213111C for ; Wed, 20 Jun 2018 12:27:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 07B6B20090 for ; Wed, 20 Jun 2018 15:41:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 34E26120B; Wed, 20 Jun 2018 15:24:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 323281205 for ; Wed, 20 Jun 2018 15:24:16 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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 Jun 2018 19:27:20 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> Toerless Eckert wrote: >> > 1. The GRASP specification of 4.1.1 should only describe what is required >> > and valid for the standard of GRASP objective, which is the TCP proxy. >> >> > Appendix C proxy option is not full/formally worked out, thats why >> > its in an appendix. If the authors want to propose a formal GRASP >> >> It's not mandatory to implement, which is why it got pushed to the appendix. >> If it wasn't worked out, then it would be removed. > Ok. *sigh*. I guess i didn't quite get that. So, if we want to make > GRASP in BRSKI work correctly for IPinIP instead of just making it > sugestive, there are a bunch of fixes necessary. I just don't see them. I can't see any protocol changes necessary, and I can't understand how the GRASP definition can change unless you want to re-open GRASP and create an IANA registry on transport-proto. > You didn't like the idea of using > objective-value strings > to identify the proxy method. But the fix i suggested also fixed other GRASP > details. As far as I understood, you seem to be asking us to invent a new protocol that is not GRASP M_FLOOD, but looks almost, but not quite like it because the CDDL syntax differs slightly. > a) Insert after: > | A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. > | This announcement can be within the same message as the ACP > | announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. > The optional IPinIP proxy as described in Appendix C requires > the following extension to the syntax of [GRASP]: We are removing Appendix C. The document will go forward with NAT66 being the only described protocol for the Join Proxy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyqp3YCLcPvd0N1lAQLXdgf+LkXsP69xnHEpM1K1t0fOpQAU0L/x2KAp OT51RHT5tZXhplaekQv8pvTIRCYfInL0w3v8NSmmRcuOkJqMbl+bzJcEs3DslCRV IcpKd/L4pUyYfvoLZGinxnUnq0gko363yxkoc43QgLmuHZlrMQAm20iyq0AE9h3O 4CXoAivLOIkkW6m1ERU4TdHqUj3Y+6Q/z4ijWio9+b/clp+ffljrbWbl5/cnHb+s 0IiiQhbRBAK89ZoI3kBlZ1bGGisL2K4QGb8n4RWApeS2XKgtModu2GlUbJ1sEHNq 74ZQ4mOcrazEmT5NHP+zxerg4uMNhmi+6W4hCnVFVwYNFkXUBVq0tg== =Vmvv -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 22 13:52:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6C2130EF0 for ; Fri, 22 Jun 2018 13:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKriMZeeYCrc for ; Fri, 22 Jun 2018 13:52:02 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB67130EEB for ; Fri, 22 Jun 2018 13:52:01 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7AC5958C4AE; Fri, 22 Jun 2018 22:51:57 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5F0854401A4; Fri, 22 Jun 2018 22:51:57 +0200 (CEST) Date: Fri, 22 Jun 2018 22:51:57 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20180622205157.4jzgfr6hnej43ye6@faui48f.informatik.uni-erlangen.de> References: <20180601062342.p3njduv4o6awwxbo@faui48f.informatik.uni-erlangen.de> <20263.1529522656@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20263.1529522656@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 20:52:05 -0000 On Wed, Jun 20, 2018 at 03:24:16PM -0400, Michael Richardson wrote: > > Ok. *sigh*. I guess i didn't quite get that. So, if we want to make > > GRASP in BRSKI work correctly for IPinIP instead of just making it > > sugestive, there are a bunch of fixes necessary. > > I just don't see them. > I can't see any protocol changes necessary, and I can't understand how > the GRASP definition can change unless you want to re-open GRASP and create > an IANA registry on transport-proto. I did send a detailled suggestion for changes in my original mail about this issues. It would be easier if yo could reply inline to that email and comment on the suggstion. I spent a good amount of effort there to explain how the GRASp announcement needs to carry all the information so that we get the right auto-discovery needed for IPinIP and proposed how it can easily be encoded into the GRASP objective value. None of this requires changing the GRASP RFC. This was all just the objective-value. Thats the field that GRASP defines to cary the objective specific information in. Aka: the mayority of any GRASP application signaling wold be in the GRASP objective. In the GRSP RFC it's defined to be "any", therefore obviously no update needed. > > You didn't like the idea of using > > objective-value strings > > to identify the proxy method. But the fix i suggested also fixed other GRASP > > details. > > As far as I understood, you seem to be asking us to invent a new protocol > that is not GRASP M_FLOOD, but looks almost, but not quite like it because > the CDDL syntax differs slightly. No, in my reply email i brought up multiple issue. The discussion about expanding GRASP RFC only came up because the GRASP RFC didn't define the transport field value in the header to be "ANY" or at least a large enough numerical value, but only allowed an explicit set of numerical values via their macros, and for IPinIP another value was needed. We did lay that argument to rest so far by both Brian and you arguing that the fact that anynumeric value is allowed in that wild should be deduced fromt the comment. So forget about GRAp RFC/header changes. This discus is only about the IMHO necessary information in the objective-vale so GRASP for IPinIP signals all the necessary information so the proxy can auto-configure itself for IPinIP and also signl out the right GRASP info to the Pledge. > > a) Insert after: > > | A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. > > | This announcement can be within the same message as the ACP > > | announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. > > > The optional IPinIP proxy as described in Appendix C requires > > the following extension to the syntax of [GRASP]: > > We are removing Appendix C. > The document will go forward with NAT66 being the only described protocol for > the Join Proxy. I think we should then be fine with BRSKI, but the discuss for how to signal in GRASP for IPinIP would would come up when you do post a new draft for IPinIP, which i hope does happen, because as i told you , i think those IPinIP proxies could actually be quite useful even beyond bootstrap given how they are not state-limited as the NAT66 proxies. Let me check if there was anything left with this decision to remove, else i'll declare my comments done, and then i could put into IESG shepherd writeup that we just need to get another rev with IPinIP and related GRASP stuff removed (for followup work).o Ok ? Cheers Toerless From nobody Fri Jun 22 16:35:47 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FCA130F12; Fri, 22 Jun 2018 16:35:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152971054548.3582.3445573731294917903@ietfa.amsl.com> Date: Fri, 22 Jun 2018 16:35:45 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-16.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 23:35:46 -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 : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-16.txt Pages : 92 Date : 2018-06-22 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-16 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 23 05:59:36 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90562130E4F; Sat, 23 Jun 2018 05:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiEMu0cO_zaH; Sat, 23 Jun 2018 05:59:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457A7130E4A; Sat, 23 Jun 2018 05:59:31 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5DC0341B48D9F; Sat, 23 Jun 2018 13:59:27 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 23 Jun 2018 13:59:28 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0382.000; Sat, 23 Jun 2018 20:59:24 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 102, Montreal Thread-Index: AdQKl+zeU6B5YcYNRV6K58hpk1VFsg== Date: Sat, 23 Jun 2018 12:59:23 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.175.161] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92900ED44DNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Call for agenda ANIMA @ IETF 102, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 23 Jun 2018 12:59:34 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92900ED44DNKGEML515MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all anima, We have been allocated a session of 2.5-hour for the ANIMA WG meeting for I= ETF-102 (Montreal) and are starting to collect agenda items for the session= . Please send your request for agenda by July 5th, Thursday. Giving that most of our chartered work items have been sent to IESG for pub= lication by the meeting, we expect short time slots for only two or three o= f them. For this coming meeting, we would like to discuss potential future = ANIMA works. As normal, the priority among these non-charter work items would be: these = that have active discussion in mail list, then these have submitted drafts,= and topics without drafts. Please send us (anima-chairs at ietf.org) requests fo= r time slot by July 5th, Thursday and include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 102, Montreal can be found at: https://www.ietf.org/how/meetings/102/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Toerless & Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B92900ED44DNKGEML515MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Hi, all anim=
a,
 
We have been=
 allocated a session of 2.5-hour for the ANIMA WG meeting for IETF-102 (Mon=
treal) and are starting to collect agenda items for the session. Please sen=
d your request for agenda by July 5th, Thursday.
 
Giving that =
most of our chartered work items have been sent to IESG for publication by =
the meeting, we expect short time slots for only two or three of them. For =
this coming meeting, we would like to discuss potential future ANIMA works.=

 
As normal, t=
he priority among these non-charter work items would be: these that have ac=
tive discussion in mail list, then these have submitted drafts, and topics =
without drafts.
 
Please send =
us (anima-chairs at ietf.org) requests for time slot by Ju=
ly 5th, Thursday and include:
 
Name of time=
 slot: 
Name of draf=
t(s): 
Time request=
ed: 
Presenter na=
me(s): 
  
More details=
 about the IETF 102, Montreal can be found at:
 
ht=
tps://www.ietf.org/how/meetings/102/
 
Again, prese=
nters and draft authors please invoke active discussions in the ANIMA list.=
 Mail list is a very good place to discuss and reach consensus on technical=
 issues.
  
Best regards=
,
  
Toerless &am=
p; Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B92900ED44DNKGEML515MBXchi_-- From nobody Sun Jun 24 03:24:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D21130DC9; Sun, 24 Jun 2018 03:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 RvEmqe18COfC; Sun, 24 Jun 2018 03:24:26 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658E1130DC6; Sun, 24 Jun 2018 03:24:26 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 03682837F27B; Sun, 24 Jun 2018 10:24:25 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:2:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1575:1588:1589:1592:1594:1606:1730:1776:1792:2068:2069:2194:2198:2199:2200:2525:2527:2528:2551:2553:2560:2567:2610:2682:2685:2689:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3421:3865:3866:3867:3868:3870:3871:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4119:4250:4321:4361:4362:4860:5007:6117:6261:6657:6659:6678:6755:7558:7875:7903:7974:8583:8603:8957:9010:9025:9108:9177:10004:10346:10848:11232:11658:11914:12043:12050:12219:12291:12379:12438:12555:12683:12740:12895:13139:13149:13153:13228:13230:13237:13439:13846:14096:21060:21063:21080:21212:21433:21451:21611:21627:21740:30026:30029:30054:30060:30074:30083:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5 X-HE-Tag: knee83_7dd2f17b7b209 X-Filterd-Recvd-Size: 8733 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf01.hostedemail.com (Postfix) with ESMTPA; Sun, 24 Jun 2018 10:24:24 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b5b3f6ea6fec905357c343cb54c63b25" Date: Sun, 24 Jun 2018 12:24:24 +0200 From: Peter van der Stok To: Sheng Jiang Cc: anima@ietf.org, anima-chairs@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> Message-ID: <854adf9ec4d575223da2c2124f56a876@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.250.16] Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 102, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 24 Jun 2018 10:24:29 -0000 --=_b5b3f6ea6fec905357c343cb54c63b25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi anima WG chairs, I should like to have 10-15 mins to present draft-ietf-anima-constrained-voucher-01. to discuss: - the content formats - relation with other drafts. - open points thanks, peter Sheng Jiang schreef op 2018-06-23 14:59: > Hi, all anima, > > We have been allocated a session of 2.5-hour for the ANIMA WG meeting for IETF-102 (Montreal) and are starting to collect agenda items for the session. Please send your request for agenda by July 5th, Thursday. > > Giving that most of our chartered work items have been sent to IESG for publication by the meeting, we expect short time slots for only two or three of them. For this coming meeting, we would like to discuss potential future ANIMA works. > > As normal, the priority among these non-charter work items would be: these that have active discussion in mail list, then these have submitted drafts, and topics without drafts. > > Please send us (anima-chairs at ietf.org) [1] requests for time slot by July 5th, Thursday and include: > > Name of time slot: > > Name of draft(s): > > Time requested: > > Presenter name(s): > > More details about the IETF 102, Montreal can be found at: > > https://www.ietf.org/how/meetings/102/ > > Again, presenters and draft authors please invoke active discussions in the ANIMA list. Mail list is a very good place to discuss and reach consensus on technical issues. > > Best regards, > > Toerless & Sheng > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima Links: ------ [1] http://mail.bbhmail.nl/./#NOP --=_b5b3f6ea6fec905357c343cb54c63b25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi anima WG chairs,

I should like to have 10-15 mins to present&= nbsp;draft-ietf-anima-constrained-voucher-01.
to discuss:
- the c= ontent formats
- relation with other drafts.
- open points
<= br />thanks,

peter

Sheng Jiang schreef op 2018-06-23 14:59:

Hi, all anima,
 
We have been allocat=
ed a session of 2.5-hour for the ANIMA WG meeting for IETF-102 (Montreal) a=
nd are starting to collect agenda items for the session. Please send your r=
equest for agenda by July 5th, Thursday.
 
Giving that most of =
our chartered work items have been sent to IESG for publication by the meet=
ing, we expect short time slots for only two or three of them. For this com=
ing meeting, we would like to discuss potential future ANIMA works.<=
/pre>

 


As normal, the prior=
ity among these non-charter work items would be: these that have active dis=
cussion in mail list, then these have submitted drafts, and topics without =
drafts.


 


Please send us (anim=
a-chairs at ietf.org) requests for time slot by July 5th, Thursday an=
d include:


 


Name of time slot: 


Name of draft(s): 


Time requested: 


Presenter name(s): 


  <=
/pre>

More details about t=
he IETF 102, Montreal can be found at:


 


h=
ttps://www.ietf.org/how/meetings/102/


 


Again, presenters an=
d draft authors please invoke active discussions in the ANIMA list. Mail li=
st is a very good place to discuss and reach consensus on technical issues=
=2E


  <=
/pre>

Best regards,=



  <=
/pre>

Toerless & Sheng=

= _______________________________________________
Anima mailing listAnima@ietf.org<= br />https://www.ietf.org/mailman/listinfo/anima
--=_b5b3f6ea6fec905357c343cb54c63b25-- From nobody Mon Jun 25 00:56:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73A4130E0A; Mon, 25 Jun 2018 00:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 jRAUxMMFBIvr; Mon, 25 Jun 2018 00:56:24 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::70d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3465C1292F1; Mon, 25 Jun 2018 00:56:24 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=qJtFw6uROg8arIW29D834sElEP1+JKaoM2J7iC3R1o8=; b=KxUOXZWMmzLWBvSW45WvsV8ZwUBiJRto1qM4d8CJghlPN9qZfenDFOjhMwHdyKLsRSbbDlM43EUlFG/eZWbnxPel2If+YrGndQsX7k0oLr8eaHo7JrCxloOLS8w1Q+kSjrfWeg9lyJuJBlS6vqwlFJ4wm+Q+zE5u3+3ZRxFR2NM= Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com (10.168.36.134) by HE1PR0701MB2970.eurprd07.prod.outlook.com (10.168.93.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.15; Mon, 25 Jun 2018 07:56:20 +0000 Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::3cbd:d091:6146:45e5]) by HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::3cbd:d091:6146:45e5%7]) with mapi id 15.20.0906.018; Mon, 25 Jun 2018 07:56:20 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 102, Montreal Thread-Index: AdQKl+zeU6B5YcYNRV6K58hpk1VFsgBwDl7A Date: Mon, 25 Jun 2018 07:56:20 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2970; 7:iA/BU/VfXV8jM/t12G/QmYS9xf0MZijWx0hsx+tfqGGPp8K+XS6O/jJzSXRrRlFQyoffOE0t2kjHWlkMQPof3R92b/feI1T+BqVoSy51cw0uF5+HcFCaI9nEaXkg3JWN4uuRQq/zi1uvpX/778APygF62VHytmcggPkOj1aWhUcMJzp0uanSj2zguRy/uWmDWwMBcwaXlxcrLnwdqV4qDHR3+7fpvIo0C5WrBJjzcuQFECWS1yEc5aZ5h7qsdGBo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fee819ea-29bd-48c0-1c94-08d5da71239f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:HE1PR0701MB2970; x-ms-traffictypediagnostic: HE1PR0701MB2970: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(60392131823829)(120809045254105)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(11241501184)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:HE1PR0701MB2970; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2970; x-forefront-prvs: 0714841678 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(39380400002)(376002)(346002)(189003)(199004)(69234005)(81166006)(3280700002)(316002)(110136005)(2900100001)(3660700001)(606006)(74316002)(790700001)(8676002)(7736002)(86362001)(966005)(3846002)(6116002)(8936002)(236005)(54896002)(9686003)(68736007)(81156014)(25786009)(106356001)(33656002)(66066001)(6306002)(14454004)(478600001)(105586002)(76176011)(102836004)(59450400001)(6506007)(53546011)(446003)(99286004)(7696005)(5660300001)(476003)(11346002)(6246003)(6436002)(229853002)(486006)(55016002)(53936002)(186003)(6346003)(26005)(2906002)(4326008)(97736004)(5250100002)(2501003)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2970; H:HE1PR0701MB2203.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:0; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia-bell-labs.com; x-microsoft-antispam-message-info: fFbCOXbgHLegOsECVupt86t0hWx/d/2P1rtEcdUEF8fCGMMWeMjjZ/g6jTT8FqMuIW6oMh1hC3BahAewZ4sIEmWFGSDKwX3hYxPi+l+dreNTCmXYEWLb5FxFT9KsaMKkYRlYdBJ1B6w154Nr/+uO9eslOnbXC+Ay0hG/png9xFSHKk7bc4y9Mc3J3LzY0cPkUl5j4jqDLRx4W61QrcD8Ru1KxX9mq+FWK+mTUCKea8Y2LqXj05+1zHGsj20Z0g37WYZiIl2qO1mZFCCeU+4Vs3PPjbGdWwj6JBiNXxCNLd1L8qonGy5l6Awssa13MQFgzfN+Cnzd5wiEbgbnQlsFxJXWDnzufKuw0khRS+6Ayr4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB22031D3AF960B26F551B8243E84A0HE1PR0701MB2203_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: fee819ea-29bd-48c0-1c94-08d5da71239f X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2018 07:56:20.4611 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2970 Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 102, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 07:56:29 -0000 --_000_HE1PR0701MB22031D3AF960B26F551B8243E84A0HE1PR0701MB2203_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ANIMA WG chairs, ANIMA WG participants, I can offer to present again, shortly, on the concepts for: [1] coordinatio= n between autonomic functions ; [2] knowledge exchange (relates to other dr= afts being discussed in ANIMA WG), and [3] autonomic functions lifecycle ma= nagement (relates to draft-asa-guidelines). On another point, we have been regularly touching the "intent" topic in the= WG. Maybe it is time/worth to give it another try and determine what the W= G would be willing (or not) to investigate in that space. FYI, the NMRG will hold a 1-day technical workshop on Friday 20 July 2018 o= n Intent Based Networking at ETS Montreal (a few blocks from IETF 102 headq= uarter hotel). The goal of the meeting is to go into important topics such as : - What IBN enables, and how? - Design goals and challenges - Are intent-based and policy-based management different? Best regards, Laurent. --- [1] (expired) Autonomic Functions Coordination https://datatracker.ietf.org= /doc/draft-ciavaglia-anima-coordination/ [2] (expired) Knowledge Exchange in Autonomic Networks https://datatracker.= ietf.org/doc/draft-ciavaglia-anima-knowledge/ [3] (expired) A Day in the Life of an Autonomic Function https://datatracke= r.ietf.org/doc/draft-peloso-anima-autonomic-function/ From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Saturday, June 23, 2018 2:59 PM To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 102, Montreal Hi, all anima, We have been allocated a session of 2.5-hour for the ANIMA WG meeting for I= ETF-102 (Montreal) and are starting to collect agenda items for the session= . Please send your request for agenda by July 5th, Thursday. Giving that most of our chartered work items have been sent to IESG for pub= lication by the meeting, we expect short time slots for only two or three o= f them. For this coming meeting, we would like to discuss potential future = ANIMA works. As normal, the priority among these non-charter work items would be: these = that have active discussion in mail list, then these have submitted drafts,= and topics without drafts. Please send us (anima-chairs at ietf.org) requests fo= r time slot by July 5th, Thursday and include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 102, Montreal can be found at: https://www.ietf.org/how/meetings/102/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Toerless & Sheng --_000_HE1PR0701MB22031D3AF960B26F551B8243E84A0HE1PR0701MB2203_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear ANIMA WG chairs, ANIMA WG partici= pants,

 

I can offer to present again, shortly,= on the concepts for: [1] coordination between autonomic functions ; [2] kn= owledge exchange (relates to other drafts being discussed in ANIMA WG), and [3] autonomic functions lifecycle management (= relates to draft-asa-guidelines).

 

On another point, we have been regular= ly touching the “intent” topic in the WG. Maybe it is time/wort= h to give it another try and determine what the WG would be willing (or not) to investigate in that space.

FYI, the NMRG will hold a 1-day techni= cal workshop on Friday 20 July 2018 on Intent Based Networking at ETS Montr= eal (a few blocks from IETF 102 headquarter hotel).

The goal of the meeting is to go into = important topics such as :

- What IB= N enables, and how?

- Design = goals and challenges

- Are int= ent-based and policy-based management different?

 

Best regards, Laurent.

---

 

[1] (expired) Autonomic Functions Coordination https://datatracker.ietf.org/= doc/draft-ciavaglia-anima-coordination/

[2] (expired) Knowledge Exchange in Autonomic Networks https://datatracker.ietf= .org/doc/draft-ciavaglia-anima-knowledge/

[3] (expired) A Day in the Life of an Autonomic Function https://datatracker.ietf.= org/doc/draft-peloso-anima-autonomic-function/

 

 

 

From: = Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Saturday, June 23, 2018 2:59 PM
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 102, Montreal

 = 

Hi,=
 all anima,
 
We =
have been allocated a session of 2.5-hour for the ANIMA WG meeting for IETF=
-102 (Montreal) and are starting to collect agenda items for the session. P=
lease send your request for agenda by July 5th, Thursday.
 
Giv=
ing that most of our chartered work items have been sent to IESG for public=
ation by the meeting, we expect short time slots for only two or three of t=
hem. For this coming meeting, we would like to discuss potential future ANI=
MA works.
 
As =
normal, the priority among these non-charter work items would be: these tha=
t have active discussion in mail list, then these have submitted drafts, an=
d topics without drafts.
 
Ple=
ase send us (anima-chairs at ietf.org) requests for time s=
lot by July 5th, Thursday and include:
&nb=
sp;
Nam=
e of time slot: 
Nam=
e of draft(s): 
Tim=
e requested:&=
nbsp;
Pre=
senter name(s): 
&nb=
sp; 
Mor=
e details about the IETF 102, Montreal can be found at:
&nb=
sp;
https://www.ietf.org/how/me=
etings/102/
 
Aga=
in, presenters and draft authors please invoke active discussions in the AN=
IMA list. Mail list is a very good place to discuss and reach consensus on =
technical issues.
&nb=
sp; 
Bes=
t regards,
&nb=
sp; 
Toe=
rless & Sheng
--_000_HE1PR0701MB22031D3AF960B26F551B8243E84A0HE1PR0701MB2203_-- From nobody Mon Jun 25 19:12:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1FF130F1F; Mon, 25 Jun 2018 19:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUwzV0uV1xKU; Mon, 25 Jun 2018 19:12:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E515B130E7A; Mon, 25 Jun 2018 19:12:26 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B8B984476BB89; Tue, 26 Jun 2018 03:12:23 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 26 Jun 2018 03:12:24 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Tue, 26 Jun 2018 10:12:14 +0800 From: Sheng Jiang To: "consultancy@vanderstok.org" CC: "anima@ietf.org" , "anima-chairs@ietf.org" Thread-Topic: [Anima] Call for agenda ANIMA @ IETF 102, Montreal Thread-Index: AdQKl+zeU6B5YcYNRV6K58hpk1VFsgAyoqcAAGPxITA= Date: Tue, 26 Jun 2018 02:12:13 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92900F0076@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> <854adf9ec4d575223da2c2124f56a876@bbhmail.nl> In-Reply-To: <854adf9ec4d575223da2c2124f56a876@bbhmail.nl> 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_5D36713D8A4E7348A7E10DF7437A4B92900F0076NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 102, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 02:12:29 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92900F0076NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFBldGVyLA0KDQpUaGFua3MgZm9yIHlvdXIgZW1haWwuIEFzIHRoZSBXRyBkb2N1bWVudCwg eW91ciBwcmVzZW50YXRpb24gaXMgbmVjZXNzYXJ5LiBUaGUgY2hhaXJzIHdvdWxkIGFsbG9jYXRl IDE1bWludXRlcyBmb3IgeW91ciBwcmVzZW50YXRpb24uDQoNClJlZ2FyZHMsDQoNClNoZW5nDQoN CkZyb206IFBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tjb25zQGJiaG1haWwubmxdDQpT ZW50OiBTdW5kYXksIEp1bmUgMjQsIDIwMTggNjoyNCBQTQ0KVG86IFNoZW5nIEppYW5nIDxqaWFu Z3NoZW5nQGh1YXdlaS5jb20+DQpDYzogYW5pbWFAaWV0Zi5vcmc7IGFuaW1hLWNoYWlyc0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtBbmltYV0gQ2FsbCBmb3IgYWdlbmRhIEFOSU1BIEAgSUVURiAx MDIsIE1vbnRyZWFsDQoNCkhpIGFuaW1hIFdHIGNoYWlycywNCg0KSSBzaG91bGQgbGlrZSB0byBo YXZlIDEwLTE1IG1pbnMgdG8gcHJlc2VudCBkcmFmdC1pZXRmLWFuaW1hLWNvbnN0cmFpbmVkLXZv dWNoZXItMDEuDQp0byBkaXNjdXNzOg0KLSB0aGUgY29udGVudCBmb3JtYXRzDQotIHJlbGF0aW9u IHdpdGggb3RoZXIgZHJhZnRzLg0KLSBvcGVuIHBvaW50cw0KDQp0aGFua3MsDQoNCnBldGVyDQoN ClNoZW5nIEppYW5nIHNjaHJlZWYgb3AgMjAxOC0wNi0yMyAxNDo1OToNCg0KSGksIGFsbCBhbmlt YSwNCg0KDQoNCldlIGhhdmUgYmVlbiBhbGxvY2F0ZWQgYSBzZXNzaW9uIG9mIDIuNS1ob3VyIGZv ciB0aGUgQU5JTUEgV0cgbWVldGluZyBmb3IgSUVURi0xMDIgKE1vbnRyZWFsKSBhbmQgYXJlIHN0 YXJ0aW5nIHRvIGNvbGxlY3QgYWdlbmRhIGl0ZW1zIGZvciB0aGUgc2Vzc2lvbi4gUGxlYXNlIHNl bmQgeW91ciByZXF1ZXN0IGZvciBhZ2VuZGEgYnkgSnVseSA1dGgsIFRodXJzZGF5Lg0KDQoNCg0K R2l2aW5nIHRoYXQgbW9zdCBvZiBvdXIgY2hhcnRlcmVkIHdvcmsgaXRlbXMgaGF2ZSBiZWVuIHNl bnQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYnkgdGhlIG1lZXRpbmcsIHdlIGV4cGVjdCBzaG9y dCB0aW1lIHNsb3RzIGZvciBvbmx5IHR3byBvciB0aHJlZSBvZiB0aGVtLiBGb3IgdGhpcyBjb21p bmcgbWVldGluZywgd2Ugd291bGQgbGlrZSB0byBkaXNjdXNzIHBvdGVudGlhbCBmdXR1cmUgQU5J TUEgd29ya3MuDQoNCg0KDQpBcyBub3JtYWwsIHRoZSBwcmlvcml0eSBhbW9uZyB0aGVzZSBub24t Y2hhcnRlciB3b3JrIGl0ZW1zIHdvdWxkIGJlOiB0aGVzZSB0aGF0IGhhdmUgYWN0aXZlIGRpc2N1 c3Npb24gaW4gbWFpbCBsaXN0LCB0aGVuIHRoZXNlIGhhdmUgc3VibWl0dGVkIGRyYWZ0cywgYW5k IHRvcGljcyB3aXRob3V0IGRyYWZ0cy4NCg0KDQoNClBsZWFzZSBzZW5kIHVzIChhbmltYS1jaGFp cnMgYXQgaWV0Zi5vcmcpPC4vI05PUD4gcmVxdWVzdHMgZm9yIHRpbWUgc2xvdCBieSBKdWx5IDV0 aCwgVGh1cnNkYXkgYW5kIGluY2x1ZGU6DQoNCg0KDQpOYW1lIG9mIHRpbWUgc2xvdDoNCg0KTmFt ZSBvZiBkcmFmdChzKToNCg0KVGltZSByZXF1ZXN0ZWQ6DQoNClByZXNlbnRlciBuYW1lKHMpOg0K DQoNCg0KTW9yZSBkZXRhaWxzIGFib3V0IHRoZSBJRVRGIDEwMiwgTW9udHJlYWwgY2FuIGJlIGZv dW5kIGF0Og0KDQoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdzLzEwMi8NCg0K DQoNCkFnYWluLCBwcmVzZW50ZXJzIGFuZCBkcmFmdCBhdXRob3JzIHBsZWFzZSBpbnZva2UgYWN0 aXZlIGRpc2N1c3Npb25zIGluIHRoZSBBTklNQSBsaXN0LiBNYWlsIGxpc3QgaXMgYSB2ZXJ5IGdv b2QgcGxhY2UgdG8gZGlzY3VzcyBhbmQgcmVhY2ggY29uc2Vuc3VzIG9uIHRlY2huaWNhbCBpc3N1 ZXMuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KDQpUb2VybGVzcyAmIFNoZW5nDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5n IGxpc3QNCkFuaW1hQGlldGYub3JnPG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== --_000_5D36713D8A4E7348A7E10DF7437A4B92900F0076NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OuWui+S9kzt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC8 5byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLCBQZXRlciw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB5b3VyIGVtYWlsLiBBcyB0aGUgV0cgZG9jdW1lbnQsIHlvdXIgcHJlc2VudGF0 aW9uIGlzIG5lY2Vzc2FyeS4gVGhlIGNoYWlycyB3b3VsZCBhbGxvY2F0ZSAxNW1pbnV0ZXMgZm9y IHlvdXIgcHJlc2VudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TaGVu ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFBldGVy IHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tjb25zQGJiaG1haWwubmxdDQo8YnI+DQo8Yj5TZW50 OjwvYj4gU3VuZGF5LCBKdW5lIDI0LCAyMDE4IDY6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IFNoZW5n IEppYW5nICZsdDtqaWFuZ3NoZW5nQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBhbmlt YUBpZXRmLm9yZzsgYW5pbWEtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbQW5pbWFdIENhbGwgZm9yIGFnZW5kYSBBTklNQSBAIElFVEYgMTAyLCBNb250cmVhbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SGkgYW5pbWEgV0cgY2hh aXJzLDxicj4NCjxicj4NCkkgc2hvdWxkIGxpa2UgdG8gaGF2ZSAxMC0xNSBtaW5zIHRvIHByZXNl bnQmbmJzcDtkcmFmdC1pZXRmLWFuaW1hLWNvbnN0cmFpbmVkLXZvdWNoZXItMDEuPGJyPg0KdG8g ZGlzY3Vzczo8YnI+DQotIHRoZSBjb250ZW50IGZvcm1hdHM8YnI+DQotIHJlbGF0aW9uIHdpdGgg b3RoZXIgZHJhZnRzLjxicj4NCi0gb3BlbiBwb2ludHM8YnI+DQo8YnI+DQp0aGFua3MsPGJyPg0K PGJyPg0KcGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj5TaGVuZyBKaWFuZyBzY2hyZWVmIG9wIDIwMTgtMDYtMjMgMTQ6NTk6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA1LjBwdDttYXJnaW4t bGVmdDowY207bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzMi PkhpLCBhbGwgYW5pbWEsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3 LjVwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1i b3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzMiPldlIGhh dmUgYmVlbiBhbGxvY2F0ZWQgYSBzZXNzaW9uIG9mIDIuNS1ob3VyIGZvciB0aGUgQU5JTUEgV0cg bWVldGluZyBmb3IgSUVURi0xMDIgKE1vbnRyZWFsKSBhbmQgYXJlIHN0YXJ0aW5nIHRvIGNvbGxl Y3QgYWdlbmRhIGl0ZW1zIGZvciB0aGUgc2Vzc2lvbi4gUGxlYXNlIHNlbmQgeW91ciByZXF1ZXN0 IGZvciBhZ2VuZGEgYnkgSnVseSA1dGgsIFRodXJzZGF5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMzMzMzMzIj5HaXZpbmcgdGhhdCBtb3N0IG9mIG91ciBjaGFydGVyZWQgd29yayBpdGVt cyBoYXZlIGJlZW4gc2VudCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBieSB0aGUgbWVldGluZywg d2UgZXhwZWN0IHNob3J0IHRpbWUgc2xvdHMgZm9yIG9ubHkgdHdvIG9yIHRocmVlIG9mIHRoZW0u IEZvciB0aGlzIGNvbWluZyBtZWV0aW5nLCB3ZSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgcG90ZW50 aWFsIGZ1dHVyZSBBTklNQSB3b3Jrcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMz MyI+QXMgbm9ybWFsLCB0aGUgcHJpb3JpdHkgYW1vbmcgdGhlc2Ugbm9uLWNoYXJ0ZXIgd29yayBp dGVtcyB3b3VsZCBiZTogdGhlc2UgdGhhdCBoYXZlIGFjdGl2ZSBkaXNjdXNzaW9uIGluIG1haWwg bGlzdCwgdGhlbiB0aGVzZSBoYXZlIHN1Ym1pdHRlZCBkcmFmdHMsIGFuZCB0b3BpY3Mgd2l0aG91 dCBkcmFmdHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzMiPlBsZWFzZSBzZW5k IHVzIChhbmltYS1jaGFpcnMgYXQgaWV0Zi5vcmc8YSBocmVmPSIuLyNOT1AiPjxzcGFuIHN0eWxl PSJjb2xvcjojMzM3QUI3Ij4pPC9zcGFuPjwvYT4gcmVxdWVzdHMgZm9yIHRpbWUgc2xvdCBieSBK dWx5IDV0aCwgVGh1cnNkYXkgYW5kIGluY2x1ZGU6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMz MyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+TmFtZSBvZiB0aW1lIHNsb3Q6 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+TmFtZSBvZiBkcmFmdChzKTo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5UaW1lIHJlcXVlc3RlZDo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5QcmVzZW50ZXIgbmFtZShzKTo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMzMzMzMzIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MzMzMzMzIj5Nb3JlIGRldGFpbHMgYWJvdXQgdGhlIElFVEYgMTAyLCBNb250cmVhbCBjYW4gYmUg Zm91bmQgYXQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6IzMzMzMzMyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRp bmdzLzEwMi8iPmh0dHBzOi8vd3d3LmlldGYub3JnL2hvdy9tZWV0aW5ncy8xMDIvPC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5BZ2FpbiwgcHJlc2VudGVycyBhbmQgZHJh ZnQgYXV0aG9ycyBwbGVhc2UgaW52b2tlIGFjdGl2ZSBkaXNjdXNzaW9ucyBpbiB0aGUgQU5JTUEg bGlzdC4gTWFpbCBsaXN0IGlzIGEgdmVyeSBnb29kIHBsYWNlIHRvIGRpc2N1c3MgYW5kIHJlYWNo IGNvbnNlbnN1cyBvbiB0ZWNobmljYWwgaXNzdWVzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMz MzMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzMiPkJlc3QgcmVnYXJk cyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMzMzMzMzIj5Ub2VybGVzcyAmYW1wOyBTaGVuZzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCkFuaW1hIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpBbmltYUBpZXRmLm9yZyI+QW5pbWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B92900F0076NKGEML515MBXchi_-- From nobody Fri Jun 29 14:11:47 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0841292F1; Fri, 29 Jun 2018 14:11:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153030668982.30269.17461946805344367178@ietfa.amsl.com> Date: Fri, 29 Jun 2018 14:11:29 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-api-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 21:11:44 -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-02.txt Pages : 26 Date : 2018-06-29 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-api-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-api-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 29 14:21:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDC21294D7 for ; Fri, 29 Jun 2018 14:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP4oLuaQvhxa for ; Fri, 29 Jun 2018 14:21:39 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936F61292F1 for ; Fri, 29 Jun 2018 14:21:39 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id l123-v6so1697787pfl.13 for ; Fri, 29 Jun 2018 14:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:organization:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=SkDa6Aqvc9f+xwR1CIMDHQw77Qg8tJ2XFY7W2M/S/qg=; b=olDZwHQytL1IS0ny5XACdLWmTLx3FkL9o/68D3jPbh6nzefDCWM6Nazlv89jvZI1GX n9N6JN+JizA+CKKafQJ7dszcvfjh0XTTZwBcSi45R6rzueT0YUosGcCDGcNmTE8niyMF gNq+e2UswKeIcbVBeitOx0jZEWeSDCG+hBEoRkvSEDcYXuXG96tGtX+r7eeEUvPs6bqQ fHK1HVvfFm/8uXD2kyzIMY7IvVIHLc41ZV/AvO9o51ep3xD+QPix40zfS29fLjeiXfRe 1nmPq/kKPtj5m05M/a8Nj9Pf1eLY0bLVz246cbN/FU3dlxioD9aoKJF35gafp8gAFKES rHJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:organization:to:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=SkDa6Aqvc9f+xwR1CIMDHQw77Qg8tJ2XFY7W2M/S/qg=; b=aJf0yGoZvy+8vMnUUDdoRHul5XWNEs2Zevt57ZiI9nCVQ4UJdeYMN2iwf8x8K8/Z2Q rUAiHrZkNJRtQqgSQqqOxZvJADzwXvX5aLX77p7+qdp7/OsgZ5WEn9cyZNRsbmixyXRM QuTEahk4C8+6mAoMQsmu9RagK2fbTmzVamcLTbx8e76IPAYZscY8vM9rJx6xJsAzz9Ne F3zm6p3//BMKpb1tDsFeVyyxD/7eCgJsiVegir3iTMthFaMRigkJTuDguvRREu3OArRk MqyDAUDa/MzNi9IjHP0/0kYLtjFOkBbhZSko0hdvD8K/Bn76U73/ORLI1asdDwiCAO2U KC+w== X-Gm-Message-State: APt69E1GMwomOeFDkOUjqJsH10U9BJQj6caQ1i5SM8bqtrt8RJaMIdzA EuEJeoFOtJZ0aLiH9MdlAiThBA== X-Google-Smtp-Source: ADUXVKL/Gp4P0xLsK85oo51dBdH9NHcnv5zaYpxcYekgn6FK/Xy1rFKzqr+0Z6aqlUFK+YRGMR03Bg== X-Received: by 2002:a63:b109:: with SMTP id r9-v6mr13995010pgf.102.1530307298742; Fri, 29 Jun 2018 14:21:38 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id 14-v6sm19951411pft.10.2018.06.29.14.21.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 14:21:37 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: <59b8cc9d-1acd-7ea3-ad05-d779c44382ba@gmail.com> Date: Sat, 30 Jun 2018 09:21:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP-related draft updates X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 21:21:42 -0000 Hi, We've updated a group of GRASP-related drafts. As a reminder, the GRASP protocol is still waiting in the RFC publication queue because of missing normative references, but has been stable for a year. The updates are all minor: 1) The API https://tools.ietf.org/html/draft-ietf-anima-grasp-api-02 Additional suggestion for event-loop API. Discussion of error code values. 2) ASA guidelines: https://tools.ietf.org/html/draft-carpenter-anima-asa-guidelines-05 Added section on relationshp with non-autonomic components. Editorial corrections. 3) Bulk data via GRASP: https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-02 Update reference, fix TBDs. Comments welcome, here or at the IETF meeting. Regards Brian Carpenter + co-authors From nobody Sat Jun 30 15:28:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA6130E1D for ; Sat, 30 Jun 2018 15:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8jxnYy4iFAQ for ; Sat, 30 Jun 2018 15:28:39 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC13130F53 for ; Sat, 30 Jun 2018 15:28:39 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id w8-v6so5488686pgp.7 for ; Sat, 30 Jun 2018 15:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uv0XykDVbfIBiV0HyLXq35PGjJ4BrfQm6R7FZqgtyec=; b=Vs3U/mdTYkr21NwzuW0Ut2NqmsPu6+I7euRJC6M1m2pFpq+uvYtdZVQZDz8iLTdSh9 5C73rkeNI7Iz6XnO7O1gUqFJyXFHJ6pMKMTxzpXCq1S5OFWc5GgSyNhaDXf9kj87j8DM u6uC2eXEgni7tGqzyHirlgBYfpg/BtVqXiHdtU0qMnVXIcOA/JvuKU8Bk0KC6bayDAu0 EunmLtvSVJTYWEmMk+pVrtah57HaxRDKKxGJCr5HLw0W+5OZcb7xNiT0XHF6CBRv0jZG iPith/W0NSaEjBrHkUlBeIWW4soIpWl8FPfmonvGGNKEmhdBAgXx8OApPTSuf4g0RB3y IKzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uv0XykDVbfIBiV0HyLXq35PGjJ4BrfQm6R7FZqgtyec=; b=QqHilajH207w1vfztBvVe4fgCdOdJAZKBergLnGqHbZ8AAedSEWdKKpU4/PGlSzHOM uuRX+fsfcHDNfsGj3TtG5WjXav/PkTYabQ0KYJobF6IgeyFV3DUkvm1pqQ6Ogz3hYUKP 1PnqDZYaU72TzbbjM3vZT/Y5397qT48TOxy2/DuSdCje2En/J2X9Armq/uxE8sFaxxTe ZrSOzD6ye3jpI/HTejmKH4Q3m4sfMl9+PNBc3j3LOGtqikeVThjWwaB7TubjDYiPQY0D OUSEu+RuOOsuVnskC9iZcZp73BeX5p7EJ+vEdJCQYKzCjihRMOMAWeFBTwXAuiOQEm88 MP3Q== X-Gm-Message-State: APt69E2pLLb3mE81lLLlvZfPR5m/EqUCCP+f7UX3icJOXdDOgGqc6WyX I4nLcgb+AxaTNFl3fEP54zHOjw== X-Google-Smtp-Source: AAOMgpdqoCeEeDuXBI4GEeS2Ia3jDgZ6vYwI6ppiz72ILhpxuRgjorpz/QOabMFTkyRLuaQkl2JZZg== X-Received: by 2002:a62:8917:: with SMTP id v23-v6mr19927573pfd.127.1530397719164; Sat, 30 Jun 2018 15:28:39 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id g78-v6sm21367961pfe.39.2018.06.30.15.28.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jun 2018 15:28:38 -0700 (PDT) From: Brian E Carpenter To: Anima WG Cc: Sheng Jiang References: <153039735256.26387.5393044887262478491@ietfa.amsl.com> Message-ID: Date: Sun, 1 Jul 2018 10:28:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153039735256.26387.5393044887262478491@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 22:28:43 -0000 A small update clarifying the scope of the draft. More comments, please! Brian + Sheng -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-limited-domains-01.txt Date: Sat, 30 Jun 2018 15:22:32 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limited Domains and Internet Protocols Authors : Brian Carpenter Sheng Jiang Filename : draft-carpenter-limited-domains-01.txt Pages : 12 Date : 2018-06-30 Abstract: There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions. It shows the needs for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-limited-domains-01 https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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