From nobody Tue Sep 5 00:18:15 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A9D132697 for ; Tue, 5 Sep 2017 00:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150459589340.28657.18059869314100977145.idtracker@ietfa.amsl.com> Date: Tue, 05 Sep 2017 00:18:13 -0700 From: IETF Secretariat Archived-At: Subject: [Anima] Milestones changed for anima WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:18:13 -0000 Changed milestone "Adoption of initial drafts on AN components: Discovery and negotiation protocol(s), Bootstrap a trust infrastructure solution, Autonomic control plane solution", resolved as "Done". Changed milestone "Adoption of reference model", resolved as "Done". Changed milestone "Adoption of the two validation drafts", resolved as "Done". Changed milestone "Submit discovery and negotiation protocol(s) to IESG (Standards Track)", resolved as "Done". URL: https://datatracker.ietf.org/wg/anima/about/ From nobody Tue Sep 5 17:09:32 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053E01321CB for ; Tue, 5 Sep 2017 17:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb8oNUlkP3dX for ; Tue, 5 Sep 2017 17:09: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 31EBE12426E for ; Tue, 5 Sep 2017 17:09:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E24120566; Tue, 5 Sep 2017 20:13:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E52A280B17; Tue, 5 Sep 2017 20:09:28 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: max pritikin , Kent Watsen X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] PKCS7 certificate SignerData certificates X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 00:09:32 -0000 --=-=-= Content-Type: text/plain PKCS7 artifacts have three things in them: 1) the content (technically optional, but we need them) 2) a set of SignerInfo objects on the content. 3) within the SignerData, a bag of certificates, one or more of which has signed the content, and the rest which may be useful to establish a trust path to a CA. Max and Kent do we need to say anything about what's in this bag of certificates, or whether or not they can/should be used to validate a voucher or voucher request. Both the JRC (Registrar) and the MASA SHOULD validate signed requests are in fact signed by the key they claim is making the request. In a signed voucher request from the pledge to the registrar the pinned-domain-cert is that of the *PLEDGE* (signed with it's IDevID). a) is that certificate also included in the PKCS7 bag of certificates? I think the answer SHOULD be yes. b) is there any operationally valid reason why there should be additional certificates in the PKCS7 bag? I can not come up with one. The registrar is never going to validate any chain that the manufacturer might have used internally to set up their CA for their IDevID. It cares about the end-certificate only. In a signed voucher request from the JRC (registrar) to the MASA the pinned-domain-cert is that of the *Registrar* (signed with it's cmcRA marked certificate from the domain owner's CA). a) is that certificate also included in the PKCS7 bag of certificates? I think the answer SHOULD be yes. b) is there any operationally valid reason why there should be additional certificates in the PKCS7 bag? Yes. At least the domain owner's CA and any certificates in between the Registrar and the CA SHOULD be presented. Should the domain owner be using a WebPKI of some sort, I think that it SHOULD send it all. Given pinned-domain-cert (vs our previous ideas), the issued voucher is going to be pinned to the Registrar's cert (not some DN specified chain). But, the audit log probably ought to include the entire chain. Additionally, the entire chain MAY be needed in order to properly invoke the sales channel integration. If you agree with my analysis, I will cook up some text for the newly created 3.2 Examples section to explain this. Some adaptation of the text above. In my code I'm doing: i. extract the first certificate from the PKCS7 bag, and use it to verify the PKCS7, telling the verifyer not to validate the chain, and not to use any certificates from the PKCS7. I found that I could not find a way to access the content of the PKCS7 content without verifying first. I don't know if this is a ruby-openssl, or underlying libssl limitation yet. ii. I look at the content now, parse the JSON, pull pinned-domain-cert out. iii. I then use the pinned-domain-cert to verify the PKCS7 again. Perhaps I could do a memcpy() against what I had in step (i), and avoid the second signature check if it was the same. I could probably be more flexible in (i) by permitting it to use the bag of certificates, but telling it not to validate any chain. I feel like there may be an attack lurking here because I wouldn't know which certificate actually validated the object, but that's just a gut instinct. {But, the above change makes the same code directly useable on the MASA as well. But, really, it's only four lines} Alternatively, in step (i), I should try all the certificates until one works, guarding aginst there being more than one. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmvPLgACgkQgItw+93Q 3WViFAf9GaHl3y5ODlD39YWs/8BVpgVeHt8kwSsbw38qsEn96Q+czFxF5dbwIAxC GIDa4VWFLrdjBI/0BPly/iyA16toY25gT3cP5HDf26NshSDl/NstwLtt0GnWteVh mDH2TJKIFu5Rv028DhIWj1oR+j331ym7eMiqSy1vhwLuGGRsrhhd7XZqzzRnjZU3 k6U4Oj8VfKXzgpWAnDVnQoWkYDaGyQcz+VHT1Zb5d8rPnBqIL4Fh9L9f1x0Ary4N t2L0tUKXz+EuygpeutV4YDzDFp6Cy6MqLjd5y6ICGkR1I1SLddkhRjYAuNotfZ/b +oSqLSEXSYAAK70/a+4+hj6feakwyg== =rLrt -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 5 21:03:43 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C05132376 for ; Tue, 5 Sep 2017 21:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg4O3kTztRGb for ; Tue, 5 Sep 2017 21:03:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3777A1321A4 for ; Tue, 5 Sep 2017 21:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10834; q=dns/txt; s=iport; t=1504670619; x=1505880219; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h4jD88RYV97qTm0m+b2b14R7ZKlL1su3TFdmdSsY5Vs=; b=CApbnJGAjE3IvXnvF5V44LoaVNcbGNPUnG/7CUSKGLIkOXwqoGr7tRFa +2jDNy0DtJPnHlJ8z6J9nzaEX+gbgIR6uUzMHBXyZ9qcXrawOR8/UIO4V RIPXCIuDWnPuUQm3IqOa8ohNcyjGb8djT2cENJc9FNRRGykeXszJGMYyg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgA/c69Z/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeQeDcJpCgXGWKA6CBAqCA4M7AhqEGEEWAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECASMRRQULAgEIGAICJgICAjAVEAIEDgWKKQiuYIInizoBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgQ2CGQSCAoMxK4J9hF2DKzCCMQWKEpZiAosziRwMkmW?= =?us-ascii?q?UfgIDCwIYAYE4ASYDLoENdxVbAYUAggh2h2YrgQWBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,482,1498521600"; d="scan'208";a="294800102" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2017 04:03:27 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8643R7H012061 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Sep 2017 04:03:27 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 5 Sep 2017 23:03:26 -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.1263.000; Tue, 5 Sep 2017 23:03:26 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: Anima WG , Kent Watsen Thread-Topic: PKCS7 certificate SignerData certificates Thread-Index: AQHTJqRqifnVkYJPxUmkEeSk4gXn+6KnkOeA Date: Wed, 6 Sep 2017 04:03:26 +0000 Message-ID: References: <4705.1504656568@obiwan.sandelman.ca> In-Reply-To: <4705.1504656568@obiwan.sandelman.ca> 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.3] Content-Type: text/plain; charset="utf-8" Content-ID: <911EA71445F60E4CA1DBE38EC9878BB8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] PKCS7 certificate SignerData certificates X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 04:03:41 -0000 DQo+IE9uIFNlcCA1LCAyMDE3LCBhdCA2OjA5IFBNLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitp ZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+IA0KPiANCj4gUEtDUzcgYXJ0aWZhY3RzIGhhdmUg dGhyZWUgdGhpbmdzIGluIHRoZW06DQo+IDEpIHRoZSBjb250ZW50ICh0ZWNobmljYWxseSBvcHRp b25hbCwgYnV0IHdlIG5lZWQgdGhlbSkNCj4gMikgYSBzZXQgb2YgU2lnbmVySW5mbyBvYmplY3Rz IG9uIHRoZSBjb250ZW50Lg0KPiAzKSB3aXRoaW4gdGhlIFNpZ25lckRhdGEsIGEgYmFnIG9mIGNl cnRpZmljYXRlcywgb25lIG9yIG1vcmUgb2Ygd2hpY2ggaGFzDQo+ICAgc2lnbmVkIHRoZSBjb250 ZW50LCBhbmQgdGhlIHJlc3Qgd2hpY2ggbWF5IGJlIHVzZWZ1bCB0byBlc3RhYmxpc2ggYSB0cnVz dA0KPiAgIHBhdGggdG8gYSBDQS4NCj4gDQo+IE1heCBhbmQgS2VudCBkbyB3ZSBuZWVkIHRvIHNh eSBhbnl0aGluZyBhYm91dCB3aGF0J3MgaW4gdGhpcyBiYWcgb2YNCj4gY2VydGlmaWNhdGVzLCBv ciB3aGV0aGVyIG9yIG5vdCB0aGV5IGNhbi9zaG91bGQgYmUgdXNlZCB0byB2YWxpZGF0ZSBhIHZv dWNoZXINCj4gb3Igdm91Y2hlciByZXF1ZXN0Lg0KDQpUaGUgdm91Y2hlci1yZXF1ZXN0IGhhcyB0 aGlzIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnQ6DQoNCnMzLjMgb2YgQlJTS0ktMDcsDQogICAgICBU aGUgcmVxdWVzdCBpcyBhICJZQU5HLWRlZmluZWQgSlNPTg0KICAgICAgZG9jdW1lbnQgdGhhdCBo YXMgYmVlbiBzaWduZWQgdXNpbmcgYSBQS0NTIzcgc3RydWN0dXJlIiBhcw0KICAgICAgZGVzY3Jp YmVkIGluIFtJLUQuaWV0Zi1hbmltYS12b3VjaGVyXSB1c2luZyB0aGUgSlNPTiBlbmNvZGVkDQog ICAgICBkZXNjcmliZWQgaW4gW1JGQzc5NTFdLiAgVGhlIFJlZ2lzdHJhciBNVVNUIHNpZ24gdGhl IHJlcXVlc3QuICBUaGUNCiAgICAgIGVudGlyZSBSZWdpc3RyYXIgY2VydGlmaWNhdGUgY2hhaW4s IHVwIHRvIGFuZCBpbmNsdWRpbmcgdGhlIERvbWFpbg0KICAgICAgQ0EsIE1VU1QgYmUgaW5jbHVk ZWQgaW4gdGhlIFBLQ1MjNyBzdHJ1Y3R1cmUuDQoNCj4gQm90aCB0aGUgSlJDIChSZWdpc3RyYXIp IGFuZCB0aGUgTUFTQSBTSE9VTEQgdmFsaWRhdGUgc2lnbmVkIHJlcXVlc3RzIGFyZSBpbg0KPiBm YWN0IHNpZ25lZCBieSB0aGUga2V5IHRoZXkgY2xhaW0gaXMgbWFraW5nIHRoZSByZXF1ZXN0Lg0K DQpzMy4zIG9mIEJSU0tJLTA3LA0KDQogICAgICBUaGUgTUFTQSB2YWxpZGF0aW9uIGNoZWNrcyBi ZWZvcmUgaXNzdWluZyBhIHZvdWNoZXIgYXJlIGFzIGZvbGxvd3M6DQogICAgICBbYWRkaXRpb25h bCByZXF1aXJlbWVudHMgcmVtb3ZlZCBmb3IgYnJldml0eV0NCg0KICAgICAgVm91Y2hlciBzaWdu YXR1cmUgY29uc2lzdGVuY3k6ICBUaGUgTUFTQSBNVVNUIHZlcmlmeSB0aGF0IHRoZSB2b3VjaGVy DQogICAgICByZXF1ZXN0IGlzIHNpZ25lZCBieSBhIFJlZ2lzdHJhci4gIFRoaXMgaXMgY29uZmly bWVkIGJ5IHZlcmlmeWluZw0KICAgICAgdGhhdCB0aGUgaWQta3AtY21jUkEgZXh0ZW5kZWQga2V5 IHVzYWdlIGV4dGVuc2lvbiBmaWVsZCAoYXMNCiAgICAgIGRldGFpbGVkIGluIEVTVCBSRkM3MDMw IHNlY3Rpb24gMy42LjEpIGV4aXN0cyBpbiB0aGUgY2VydGlmaWNhdGUNCiAgICAgIG9mIHRoZSBl bnRpdHkgdGhhdCBzaWduZWQgdGhlIHZvdWNoZXIgcmVxdWVzdC4gIFRoaXMgdmVyaWZpY2F0aW9u DQogICAgICBpcyBvbmx5IGEgY29uc2lzdGVuY3kgY2hlY2sgdGhhdCB0aGUgdW5hdXRoZW50aWNh dGVkIGRvbWFpbiBDQQ0KICAgICAgaW50ZW5kZWQgdGhpcyB0byBiZSBhIFJlZ2lzdHJhci4gIFBl cmZvcm1pbmcgdGhpcyBjaGVjayBwcm92aWRlcw0KICAgICAgdmFsdWUgdG8gZG9tYWluIFBLSSBi eSBhc3N1cmluZyB0aGUgZG9tYWluIGFkbWluaXN0cmF0b3IgdGhhdCB0aGUNCiAgICAgIE1BU0Eg c2VydmljZSB3aWxsIG9ubHkgcmVzcGVjdCBjbGFpbXMgZnJvbSBhdXRob3JpemVkIFJlZ2lzdHJh dGlvbg0KICAgICAgQXV0aG9yaXRpZXMgb2YgdGhlIGRvbWFpbi4gIChUaGUgcmVxdWlyZW1lbnQg Zm9yIHRoZSBSZWdpc3RyYXIgdG8NCiAgICAgIGluY2x1ZGUgdGhlIERvbWFpbiBDQSBjZXJ0aWZp Y2F0ZSBpbiB0aGUgc2lnbmF0dXJlIHN0cnVjdHVyZSB3YXMNCiAgICAgIHN0YXRlZCBhYm92ZSku DQoNCj4gSW4gYSBzaWduZWQgdm91Y2hlciByZXF1ZXN0IGZyb20gdGhlIHBsZWRnZSB0byB0aGUg cmVnaXN0cmFyIHRoZQ0KPiBwaW5uZWQtZG9tYWluLWNlcnQgaXMgdGhhdCBvZiB0aGUgKlBMRURH RSogKHNpZ25lZCB3aXRoIGl0J3MgSURldklEKS4NCg0KQWN0dWFsbHkgdGhpcyBwaW5uZWQtZG9t YWluLWNlcnQgaXMgdGh1cywgZnJvbSBzMy4yIG9mIEJSU0tJLTA3LA0KDQogICBwaW5uZWQtZG9t YWluLWNlcnQ6ICBJbiBhIFBsZWRnZSB2b3VjaGVyIHJlcXVlc3QgdGhpcyBpcyB0aGUNCiAgICAg IFJlZ2lzdHJhciBjZXJ0aWZpY2F0ZSBhcyBleHRyYWN0ZWQgZnJvbSB0aGUgVExTIGhhbmRzaGFr ZSAoZm9yDQogICAgICBleGFtcGxlIHRoZSBmaXJzdCBjZXJ0aWZpY2F0ZSBpbiB0aGUgVExTICdj ZXJ0aWZpY2F0ZV9saXN0Jw0KICAgICAgc2VxdWVuY2UgKHNlZSBbUkZDNTI0Nl0pLiAgVGhpcyBN VVNUIGJlIHBvcHVsYXRlZCBpbiBhIFBsZWRnZSdzDQogICAgICB2b3VjaGVyIHJlcXVlc3QgaWYg dGhlICJwcm94aW1pdHkiIGFzc2VydGlvbiBpcyBwb3B1bGF0ZWQuDQoNCkkgd2FzIHdvbmRlcmlu ZyBlYXJsaWVyIHRvZGF5IGlmIHRoaXMgd2FzIGNvbmZ1c2luZy4gV2UgY291bGQgYWRkIGEgbGVh ZiBmb3Ig4oCcdGxzLWRvbWFpbi1jZXJ04oCdIG9yIHNvbWV0aGluZy4gQW4gYWRkaXRpb25hbCBw b2ludCBpcyB0aGF0IHRoZSAqYXNzdW1wdGlvbiogaXMgdGhhdCB0aGlzIGlzIHRoZSBzYW1lIGNl cnQgYXMgdGhlIGlkLWtwLWNtY1JBIGNlcnQgaW4gdGhlIGNoYWluIGRpc2N1c3NlZCBhYm92ZSBh bmQgaW4gczMuMyBidXQgbWF5YmUgdGhhdCBpcyBhbiBhc3N1bXB0aW9uIHRvbyBmYXIgYW5kIHdl IHNob3VsZCBzdXBwb3J0IGJhZ3Mgb2YgY2VydHMgYW5kIGFyYml0cmFyeSBjb21wbGV4aXR5PyBJ 4oCZbSB0aXJlZCBvZiB0aGlzIFBLSSBtZXNzLg0KDQo+ICBhKSBpcyB0aGF0IGNlcnRpZmljYXRl IGFsc28gaW5jbHVkZWQgaW4gdGhlIFBLQ1M3IGJhZyBvZiBjZXJ0aWZpY2F0ZXM/DQo+ICAgICBJ IHRoaW5rIHRoZSBhbnN3ZXIgU0hPVUxEIGJlIHllcy4NCj4gIGIpIGlzIHRoZXJlIGFueSBvcGVy YXRpb25hbGx5IHZhbGlkIHJlYXNvbiB3aHkgdGhlcmUgc2hvdWxkIGJlIGFkZGl0aW9uYWwNCj4g ICAgIGNlcnRpZmljYXRlcyBpbiB0aGUgUEtDUzcgYmFnPw0KPiAgICAgSSBjYW4gbm90IGNvbWUg dXAgd2l0aCBvbmUuIFRoZSByZWdpc3RyYXIgaXMgbmV2ZXIgZ29pbmcgdG8gdmFsaWRhdGUNCj4g ICAgIGFueSBjaGFpbiB0aGF0IHRoZSBtYW51ZmFjdHVyZXIgbWlnaHQgaGF2ZSB1c2VkIGludGVy bmFsbHkgdG8gc2V0IHVwDQo+ICAgICB0aGVpciBDQSBmb3IgdGhlaXIgSURldklELiAgSXQgY2Fy ZXMgYWJvdXQgdGhlIGVuZC1jZXJ0aWZpY2F0ZSBvbmx5Lg0KDQpUaGUgcmVhc29uIHMzLjMuIG1h bmRhdGVzIHRoZSBlbnRpcmUgY2hhaW4sIGluY2x1ZGluZyB0aGUgZG9tYWluIENBIGNlcnRpZmlj YXRlLCBpcyB0byBhbGxvdyB0aGUgYWJvdmUgY29uc2lzdGVuY3kgY2hlY2tzLiBCdXQgb3JpZ2lu YWxseSB0aGlzIHdhcyBzbyB0aGF0IHRoZSBkb21haW5DQSBjZXJ0aWZpY2F0ZSB3b3VsZCBiZSB1 c2VkIGZvciB0aGUgcGlubmVkIGNlcnQuIE1vdmluZyB0byBqdXN0IHRoZSBSQSBjZXJ0IGluIHRo ZSBwaW5uZWQtZG9tYWluLWNlcnQgZmllbGQgd291bGQgYmUgYSBzaW1wbGlmaWNhdGlvbj8gVGhl IHRleHQgb2YgdGhlIHZvdWNoZXItMDUgbGVhZiBkZXNjcmlwdGlvbiBzZWVtcyB0byBhbGxvdyB0 aGlzLg0KDQo+IA0KPiBJbiBhIHNpZ25lZCB2b3VjaGVyIHJlcXVlc3QgZnJvbSB0aGUgSlJDIChy ZWdpc3RyYXIpIHRvIHRoZSBNQVNBIHRoZQ0KPiBwaW5uZWQtZG9tYWluLWNlcnQgaXMgdGhhdCBv ZiB0aGUgKlJlZ2lzdHJhciogKHNpZ25lZCB3aXRoIGl0J3MgY21jUkEgbWFya2VkDQo+IGNlcnRp ZmljYXRlIGZyb20gdGhlIGRvbWFpbiBvd25lcidzIENBKS4NCj4gDQo+ICBhKSBpcyB0aGF0IGNl cnRpZmljYXRlIGFsc28gaW5jbHVkZWQgaW4gdGhlIFBLQ1M3IGJhZyBvZiBjZXJ0aWZpY2F0ZXM/ DQo+ICAgICBJIHRoaW5rIHRoZSBhbnN3ZXIgU0hPVUxEIGJlIHllcy4NCg0KVGhpcyBpcyB0aGUg Y3VycmVudCBsYW5ndWFnZSBhbmQgKm5vdCogdGhhdCB0aGUgcGlubmVkLWRvbWFpbi1jZXJ0IGlz IHBvcHVsYXRlZCBhdCBhbGwuIEluIGZhY3QgaWYgeW91IGxvb2sgYXQgdGhlIG5ldyB2b3VjaGVy LXJlcXVlc3QteWFuZyBicmFuY2ggYW5kIEV4YW1wbGUgKDIpIG9mIHRoZSB2b3VjaGVyIHJlcXVl c3RzIHlvdSBzZWU6DQoNCiAgIHsNCiAgICAgICAiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hl ciI6IHsNCiAgICAgICAgICAgImNyZWF0ZWQtb24iOiAiMjAxNy0wMS0wMVQwMDowMDowMi4wMDBa IiwNCiAgICAgICAgICAgImFzc2VydGlvbiI6ICJUQkQiLA0KICAgICAgICAgICAiaWRldmlkLWlz c3VlciI6ICJiYXNlNjRlbmNvZGVkdmFsdWU9PSINCiAgICAgICAgICAgInNlcmlhbC1udW1iZXIi OiAiSkFEQTEyMzQ1Njc4OSINCiAgICAgICB9DQogICB9DQoNCkkgd2FzIGNvbnNpZGVyaW5nIG9w ZW5pbmcgYW4gaXNzdWUgYWJvdXQgdGhpcyBUQkQgYW5kIHRoZSByZXN1bHRpbmcgdW5jZXJ0YWlu dHkgYWJvdXQgdGhlIG1lYW5pbmcgb2YgdGhlIHBpbm5lZC1kb21haW4tY2VydCBpbiB0aGlzIHNp dHVhdGlvbi4gDQoNCj4gDQo+ICBiKSBpcyB0aGVyZSBhbnkgb3BlcmF0aW9uYWxseSB2YWxpZCBy ZWFzb24gd2h5IHRoZXJlIHNob3VsZCBiZSBhZGRpdGlvbmFsDQo+ICAgICBjZXJ0aWZpY2F0ZXMg aW4gdGhlIFBLQ1M3IGJhZz8NCj4gDQo+ICAgICBZZXMuICBBdCBsZWFzdCB0aGUgZG9tYWluIG93 bmVyJ3MgQ0EgYW5kIGFueSBjZXJ0aWZpY2F0ZXMgaW4gYmV0d2Vlbg0KPiAgICAgdGhlIFJlZ2lz dHJhciBhbmQgdGhlIENBIFNIT1VMRCBiZSBwcmVzZW50ZWQuDQo+ICAgICBTaG91bGQgdGhlIGRv bWFpbiBvd25lciBiZSB1c2luZyBhIFdlYlBLSSBvZiBzb21lIHNvcnQsIEkgdGhpbmsgdGhhdA0K PiAgICAgaXQgU0hPVUxEIHNlbmQgaXQgYWxsLg0KPiANCj4gICAgIEdpdmVuIHBpbm5lZC1kb21h aW4tY2VydCAodnMgb3VyIHByZXZpb3VzIGlkZWFzKSwgdGhlIGlzc3VlZCB2b3VjaGVyDQo+ICAg ICBpcyBnb2luZyB0byBiZSBwaW5uZWQgdG8gdGhlIFJlZ2lzdHJhcidzIGNlcnQgKG5vdCBzb21l IEROIHNwZWNpZmllZA0KPiAgICAgY2hhaW4pLiAgQnV0LCB0aGUgYXVkaXQgbG9nIHByb2JhYmx5 IG91Z2h0IHRvIGluY2x1ZGUgdGhlIGVudGlyZSBjaGFpbi4NCj4gDQo+ICAgICBBZGRpdGlvbmFs bHksIHRoZSBlbnRpcmUgY2hhaW4gTUFZIGJlIG5lZWRlZCBpbiBvcmRlciB0byBwcm9wZXJseSBp bnZva2UNCj4gICAgIHRoZSBzYWxlcyBjaGFubmVsIGludGVncmF0aW9uLg0KPiANCj4gSWYgeW91 IGFncmVlIHdpdGggbXkgYW5hbHlzaXMsIEkgd2lsbCBjb29rIHVwIHNvbWUgdGV4dCBmb3IgdGhl IG5ld2x5DQo+IGNyZWF0ZWQgMy4yIEV4YW1wbGVzIHNlY3Rpb24gdG8gZXhwbGFpbiB0aGlzLiAg U29tZSBhZGFwdGF0aW9uIG9mIHRoZSB0ZXh0IGFib3ZlLg0KDQpJIHRoaW5rIHdl4oCZcmUgY2xv c2UgdG8gYWdyZWVpbmcuIFNvbWUgY29tbWVudHM6IA0KDQpJIGxpa2UgdGhlIGp3dCBhcHByb2Fj aCB0byBjZXJ0cyB3aGVyZSB0aGV5IGluY2x1ZGUgYW4gZW50aXJlIOKAnHg1Y+KAnSBjaGFpbiBy YXRoZXIgdGhhbiBhIHNpbmdsZSBjZXJ0LiBNYXliZSB3ZSBzaG91bGQgYmUgY29weWluZyB0aGF0 PyBJbiBwYXJ0aWN1bGFyIEkgbGlrZSBpdCBiZXR0ZXIgdGhhbiB0cnlpbmcgdG8gc3BlY2lmeSBl eHRyYSBzdHVmZiBpbiB0aGUgY2VydGlmaWNhdGUgYmFnLiBUaGUgbGVzcyB3ZSBkZXBlbmQgb24g dGhlIHBrY3MjNyBzdHJ1Y3R1cmUgdGhlIGJldHRlciBhbmQgSeKAmW0gd2lsbGluZyB0byBjaGFu Z2UgdGhlIGFib3ZlIHVzZXMgdG8gbWVldCB0aGF0IGdvYWwuIA0KDQo+IEluIG15IGNvZGUgSSdt IGRvaW5nOg0KPiANCj4gaS4gIGV4dHJhY3QgdGhlIGZpcnN0IGNlcnRpZmljYXRlIGZyb20gdGhl IFBLQ1M3IGJhZywgYW5kIHVzZSBpdCB0bw0KPiAgICB2ZXJpZnkgdGhlIFBLQ1M3LCB0ZWxsaW5n IHRoZSB2ZXJpZnllciBub3QgdG8gdmFsaWRhdGUgdGhlIGNoYWluLA0KPiAgICBhbmQgbm90IHRv IHVzZSBhbnkgY2VydGlmaWNhdGVzIGZyb20gdGhlIFBLQ1M3Lg0KPiAgICBJIGZvdW5kIHRoYXQg SSBjb3VsZCBub3QgZmluZCBhIHdheSB0byBhY2Nlc3MgdGhlIGNvbnRlbnQgb2YgdGhlIFBLQ1M3 DQo+ICAgIGNvbnRlbnQgd2l0aG91dCB2ZXJpZnlpbmcgZmlyc3QuICBJIGRvbid0IGtub3cgaWYg dGhpcyBpcyBhIHJ1Ynktb3BlbnNzbCwNCj4gICAgb3IgdW5kZXJseWluZyBsaWJzc2wgbGltaXRh dGlvbiB5ZXQuDQoNClRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50LiBJbiBvcGVuc3NsIEkgYmVs aWV2ZSBJIHdhcyBhYmxlIHRvIGNyYWNrIGludG8gdGhlIGRldGFpbHMgd2l0aG91dCB2ZXJpZnlp bmcgYW5kIHRoZW4gZ28gYmFjayBhbmQgdmVyaWZ5IG9uY2UgSeKAmWQgZXh0cmFjdGVkIHRoZSBj ZXJ0IGJhZ3MuIA0KDQo+IA0KPiBpaS4gIEkgbG9vayBhdCB0aGUgY29udGVudCBub3csIHBhcnNl IHRoZSBKU09OLCBwdWxsIHBpbm5lZC1kb21haW4tY2VydCBvdXQuDQo+IGlpaS4gSSB0aGVuIHVz ZSB0aGUgcGlubmVkLWRvbWFpbi1jZXJ0IHRvIHZlcmlmeSB0aGUgUEtDUzcgYWdhaW4uICBQZXJo YXBzDQo+ICAgICBJIGNvdWxkIGRvIGEgbWVtY3B5KCkgYWdhaW5zdCB3aGF0IEkgaGFkIGluIHN0 ZXAgKGkpLCBhbmQgYXZvaWQgdGhlDQo+ICAgICBzZWNvbmQgc2lnbmF0dXJlIGNoZWNrIGlmIGl0 IHdhcyB0aGUgc2FtZS4NCj4gDQo+IEkgY291bGQgcHJvYmFibHkgYmUgbW9yZSBmbGV4aWJsZSBp biAoaSkgYnkgcGVybWl0dGluZyBpdCB0byB1c2UgdGhlIGJhZyBvZg0KPiBjZXJ0aWZpY2F0ZXMs IGJ1dCB0ZWxsaW5nIGl0IG5vdCB0byB2YWxpZGF0ZSBhbnkgY2hhaW4uICAgSSBmZWVsIGxpa2Ug dGhlcmUNCj4gbWF5IGJlIGFuIGF0dGFjayBsdXJraW5nIGhlcmUgYmVjYXVzZSBJIHdvdWxkbid0 IGtub3cgd2hpY2ggY2VydGlmaWNhdGUNCj4gYWN0dWFsbHkgdmFsaWRhdGVkIHRoZSBvYmplY3Qs IGJ1dCB0aGF0J3MganVzdCBhIGd1dCBpbnN0aW5jdC4NCj4ge0J1dCwgdGhlIGFib3ZlIGNoYW5n ZSBtYWtlcyB0aGUgc2FtZSBjb2RlIGRpcmVjdGx5IHVzZWFibGUgb24gdGhlIE1BU0EgYXMNCj4g d2VsbC4gIEJ1dCwgcmVhbGx5LCBpdCdzIG9ubHkgZm91ciBsaW5lc30NCj4gDQo+IEFsdGVybmF0 aXZlbHksIGluIHN0ZXAgKGkpLCBJIHNob3VsZCB0cnkgYWxsIHRoZSBjZXJ0aWZpY2F0ZXMgdW50 aWwgb25lDQo+IHdvcmtzLCBndWFyZGluZyBhZ2luc3QgdGhlcmUgYmVpbmcgbW9yZSB0aGFuIG9u ZS4NCg0KRHVubm8gdGhlIG9wdGlvbnMuIEkgYnJvdWdodCBteSBjb2RlIHVwIHRoaXMgZXZlbmlu ZyB0byByZWxvb2sgYXQgdGhlIHBpbm5lZC1jZXJ0IGRpc2N1c3Npb24gaW4gdGhpcyBleGFjdCBh cmVhIGJ1dCBkaWRu4oCZdCBtYWtlIGFueSBwcm9ncmVzcy4gSeKAmWxsIHRyeSBhbmQgbG9vayBh dCBpdCB0b21vcnJvdy4gDQoNCi0gbWF4DQoNCj4gDQo+IA0KPiANCj4gDQo+IC0tDQo+IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4gDQo+IA0KPiANCg0K From nobody Wed Sep 6 12:56:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8832124E15 for ; Wed, 6 Sep 2017 12:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 5tkiwVXda06a for ; Wed, 6 Sep 2017 12:56:53 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0117.outbound.protection.outlook.com [104.47.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9826126B71 for ; Wed, 6 Sep 2017 12:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JmOiIo1duQP5zfGKfsgOHabwDZBShr6rky46HCZ/mdY=; b=Y8Ep6B/drUaRiJaA+g2NQf9NRij7OJ5pEBcDvz55s2BbTN7ULb1WwrcollKl4M1Ftb8cYSm/bdV2oUYYPrjXmh/zwHw43mNgWkoD8h+YHqd2s9n+mJSePa6HEN8CBHtUw/UYJOQbFRtLU8TmpxZI9zNZ7KCnYzJDzlp++83YB2E= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1298.namprd05.prod.outlook.com (10.160.183.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Wed, 6 Sep 2017 19:56:50 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0035.010; Wed, 6 Sep 2017 19:56:49 +0000 From: Kent Watsen To: "Max Pritikin (pritikin)" , Michael Richardson CC: Anima WG Thread-Topic: PKCS7 certificate SignerData certificates Thread-Index: AQHTJqRrsEcgwhL1eECJLCw/Gd3iLKKnPOUAgADHUYA= Date: Wed, 6 Sep 2017 19:56:49 +0000 Message-ID: <8EC759E5-598F-43B7-B63E-6008346767B6@juniper.net> References: <4705.1504656568@obiwan.sandelman.ca> In-Reply-To: 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.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1298; 6:uBAJxYFFJ2zGlp6v5dmCONCcAtWDC+VaKaqhAu15yQ33s/fPcqSRIx6u47PUHoW+s6ryCH8p5t4rdie6ju70Qq7A3NdPahX39t1uI+YaduANdap95wpVQr+anL8LbNlaSVfByoZmr8cbI7T2pSdol486HO0odjpYxC0GMiMLgTaGfA8rOe3bsb8wAXEI3M0E0Ul+q/exngCftSm26wRWQcUNZh7kE2nbwviUji4/oVm0dYKX6ojmkXQIm7AAZlSBSvCE2Gv+pDb7tbHiQVPDK8Kvz0jpfmH8GYtxQ47BwdCee95K1jIyVZYDKwURdo8fA1NJI0fR3h4JnUvvmsEPNQ==; 5:qASQM8RxQBnJIoFi4OpnSATUnO240pQEwn52ZAACt2Mqzak0XC2FckkxI4GubqjbegA+ivIq87933BeFPVBaSD+60i4rhqdwzFKoX0L7FDSDdbMRRiY23pCjQ9Ua9/o5jcSu1iGDy6kkdaIzOSvdvQ==; 24:lqUslOqwqSPxX+R1In043NfvO6Kc5RgsdwFaBGHF0+cFEFrzm+YO5TglmMT/MccBSkGwsA08dsYEN48WmQpxk5JQ0zTZVS++Znuy0DZYKuo=; 7:pQLIvBxpNZvxcDQCzKPyLIaN6pc56aSURVY858COP8AnQFUrPwqo7ZrNyl4JyQ/ApbrlbPN9GAfliBZrqYvGkjtGBlu/rIT5cfWQKOU0wie0It+rhwyujtke9QRVSRiO+/CwdZiK+fRQVAWtqU7o5QTSDK11krblKsFzKQVC454P2iiuFVJHx9X8wLtpMmP8Nfuu6H3DcMhBkYqp+LoGbZE5irWSJx1XD22C+2ps02Y= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9451eb35-dbd3-4df9-ea73-08d4f56169aa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1298; x-ms-traffictypediagnostic: BN3PR0501MB1298: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:(60795455431006)(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1298; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1298; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(24454002)(57704003)(377454003)(189002)(51444003)(53936002)(6246003)(7736002)(5660300001)(101416001)(14454004)(2950100002)(99286003)(6306002)(966005)(82746002)(6512007)(6486002)(3280700002)(8676002)(8936002)(4326008)(229853002)(83716003)(305945005)(4001350100001)(97736004)(83506001)(2906002)(81156014)(81166006)(86362001)(77096006)(6506006)(66066001)(2900100001)(189998001)(6436002)(3660700001)(68736007)(25786009)(33656002)(105586002)(6116002)(3846002)(102836003)(54356999)(76176999)(50986999)(106356001)(36756003)(478600001)(53546010)(87944003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1298; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6ABE2DBB8CEAA04EBE4EDACB46E1D284@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 19:56:49.8742 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1298 Archived-At: Subject: Re: [Anima] PKCS7 certificate SignerData certificates X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 19:56:56 -0000 DQoNCg0KPiBPbiBTZXAgNSwgMjAxNywgYXQgNjowOSBQTSwgTWljaGFlbCBSaWNoYXJkc29uIDxt Y3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IFBLQ1M3IGFydGlmYWN0cyBo YXZlIHRocmVlIHRoaW5ncyBpbiB0aGVtOg0KPiAxKSB0aGUgY29udGVudCAodGVjaG5pY2FsbHkg b3B0aW9uYWwsIGJ1dCB3ZSBuZWVkIHRoZW0pDQo+IDIpIGEgc2V0IG9mIFNpZ25lckluZm8gb2Jq ZWN0cyBvbiB0aGUgY29udGVudC4NCj4gMykgd2l0aGluIHRoZSBTaWduZXJEYXRhLCBhIGJhZyBv ZiBjZXJ0aWZpY2F0ZXMsIG9uZSBvciBtb3JlIG9mIHdoaWNoIGhhcw0KPiAgIHNpZ25lZCB0aGUg Y29udGVudCwgYW5kIHRoZSByZXN0IHdoaWNoIG1heSBiZSB1c2VmdWwgdG8gZXN0YWJsaXNoIGEg dHJ1c3QNCj4gICBwYXRoIHRvIGEgQ0EuDQoNCk5vdCB0aGF0IGl0IG1hdHRlcnMgdG8gQlJTS0ks IGJ1dDoNCg0KICAgVGhlIFBLQ1MjNyBzdHJ1Y3R1cmUgTUFZIGFsc28gY29udGFpbiByZXZvY2F0 aW9uIG9iamVjdHMgZm9yIGFueQ0KICAgaW50ZXJtZWRpYXRlIENBcyBiZXR3ZWVuIHRoZSB2b3Vj aGVyLWlzc3VlciBhbmQgdGhlIHRydXN0IGFuY2hvcg0KICAga25vd24gdG8gdGhlIHJlY2lwaWVu dC4NCg0KDQo+IE1heCBhbmQgS2VudCBkbyB3ZSBuZWVkIHRvIHNheSBhbnl0aGluZyBhYm91dCB3 aGF0J3MgaW4gdGhpcyBiYWcgb2YNCj4gY2VydGlmaWNhdGVzLCBvciB3aGV0aGVyIG9yIG5vdCB0 aGV5IGNhbi9zaG91bGQgYmUgdXNlZCB0byB2YWxpZGF0ZSBhIHZvdWNoZXINCj4gb3Igdm91Y2hl ciByZXF1ZXN0Lg0KDQpTNiBpbiB0aGUgdm91Y2hlciBkcmFmdCBzYXlzOg0KDQogICBUaGUgUEtD UyM3IHN0cnVjdHVyZSBTSE9VTEQgYWxzbyBjb250YWluIGFsbCB0aGUgY2VydGlmaWNhdGVzIGxl YWRpbmcNCiAgIHVwIHRvIGFuZCBpbmNsdWRpbmcgdGhlIHNpZ25lcidzIHRydXN0IGFuY2hvciBj ZXJ0aWZpY2F0ZSBrbm93biB0bw0KICAgdGhlIHJlY2lwaWVudC4NCg0KYW5kIFM1LjQgaW4gdGhl IE5FVENPTkYgemVyb3RvdWNoIGRyYWZ0IHNheXM6DQoNCiAgIFRoZSBkZXZpY2UgTVVTVCBmaXJz dCBhdXRoZW50aWNhdGUgdGhlIG93bmVyc2hpcCB2b3VjaGVyIGJ5DQogICB2YWxpZGF0aW5nIHRo ZSBzaWduYXR1cmUgb24gaXQgdG8gb25lIG9mIGl0cyBwcmVjb25maWd1cmVkIHRydXN0DQogICBh bmNob3JzIChzZWUgU2VjdGlvbiA1LjEpLg0KDQpQZXJoYXBzIGl0IHNob3VsZCBhZGQgInVzaW5n IGFueSBhZGRpaW90aW9uYWwgaW50ZXJtZWRpYXRlIGNlcnRpZmljYXRlcw0Kc3RhcGxlZCB0byB0 aGUgdm91Y2hlciI/DQoNCg0KDQoNCj4gQm90aCB0aGUgSlJDIChSZWdpc3RyYXIpIGFuZCB0aGUg TUFTQSBTSE9VTEQgdmFsaWRhdGUgc2lnbmVkIHJlcXVlc3RzIGFyZSBpbg0KPiBmYWN0IHNpZ25l ZCBieSB0aGUga2V5IHRoZXkgY2xhaW0gaXMgbWFraW5nIHRoZSByZXF1ZXN0Lg0KDQpJbmRlZWQs IGFuZCB3aGF0IE1heCBwb3N0ZWQgc2VlbXMgdG8gc2hvdyB0aGF0IGl0J3MgY292ZXJlZC4NCg0K DQoNCj4gSW4gYSBzaWduZWQgdm91Y2hlciByZXF1ZXN0IGZyb20gdGhlIHBsZWRnZSB0byB0aGUg cmVnaXN0cmFyIHRoZQ0KPiBwaW5uZWQtZG9tYWluLWNlcnQgaXMgdGhhdCBvZiB0aGUgKlBMRURH RSogKHNpZ25lZCB3aXRoIGl0J3MgSURldklEKS4NCj4gIGEpIGlzIHRoYXQgY2VydGlmaWNhdGUg YWxzbyBpbmNsdWRlZCBpbiB0aGUgUEtDUzcgYmFnIG9mIGNlcnRpZmljYXRlcz8NCj4gICAgIEkg dGhpbmsgdGhlIGFuc3dlciBTSE9VTEQgYmUgeWVzLg0KDQpZZXMsIHNlZSB0aGUgU0hPVUxEIGZy b20gUzYgYWJvdmUuDQoNCg0KPiAgYikgaXMgdGhlcmUgYW55IG9wZXJhdGlvbmFsbHkgdmFsaWQg cmVhc29uIHdoeSB0aGVyZSBzaG91bGQgYmUgYWRkaXRpb25hbA0KPiAgICAgY2VydGlmaWNhdGVz IGluIHRoZSBQS0NTNyBiYWc/DQo+ICAgICBJIGNhbiBub3QgY29tZSB1cCB3aXRoIG9uZS4gVGhl IHJlZ2lzdHJhciBpcyBuZXZlciBnb2luZyB0byB2YWxpZGF0ZQ0KPiAgICAgYW55IGNoYWluIHRo YXQgdGhlIG1hbnVmYWN0dXJlciBtaWdodCBoYXZlIHVzZWQgaW50ZXJuYWxseSB0byBzZXQgdXAN Cj4gICAgIHRoZWlyIENBIGZvciB0aGVpciBJRGV2SUQuICBJdCBjYXJlcyBhYm91dCB0aGUgZW5k LWNlcnRpZmljYXRlIG9ubHkuDQoNCk5vbmUgdGhhdCBJIGNhbiB0aGluayBvZi4NCg0KDQo+IElu IGEgc2lnbmVkIHZvdWNoZXIgcmVxdWVzdCBmcm9tIHRoZSBKUkMgKHJlZ2lzdHJhcikgdG8gdGhl IE1BU0EgdGhlDQo+IHBpbm5lZC1kb21haW4tY2VydCBpcyB0aGF0IG9mIHRoZSAqUmVnaXN0cmFy KiAoc2lnbmVkIHdpdGggaXQncyBjbWNSQSBtYXJrZWQNCj4gY2VydGlmaWNhdGUgZnJvbSB0aGUg ZG9tYWluIG93bmVyJ3MgQ0EpLg0KPiANCj4gIGEpIGlzIHRoYXQgY2VydGlmaWNhdGUgYWxzbyBp bmNsdWRlZCBpbiB0aGUgUEtDUzcgYmFnIG9mIGNlcnRpZmljYXRlcz8NCj4gICAgIEkgdGhpbmsg dGhlIGFuc3dlciBTSE9VTEQgYmUgeWVzLg0KDQpUaGUgc2lnbmVyIG9mIHRoZSBQS0NTNyBTSE9V TEQgcHV0IGl0cyBjZXJ0aWZpY2F0ZSBpbnRvIHRoZSBTaWduZWREYXRhDQpzdHJ1Y3QuICAgV2hl dGhlciB0aGUgc2FtZSBjZXJ0aWZpY2F0ZSBpcyBhbHNvIGluIHRoZSBwYXlsb2FkIG9mIHRoZQ0K UEtDUzcgaXMgaW5jb25zZXF1ZW50aWFsLg0KDQoNCg0KPj4gIGIpIGlzIHRoZXJlIGFueSBvcGVy YXRpb25hbGx5IHZhbGlkIHJlYXNvbiB3aHkgdGhlcmUgc2hvdWxkIGJlIGFkZGl0aW9uYWwNCj4+ ICAgICBjZXJ0aWZpY2F0ZXMgaW4gdGhlIFBLQ1M3IGJhZz8NCj4+IA0KPj4gICAgIFllcy4gIEF0 IGxlYXN0IHRoZSBkb21haW4gb3duZXIncyBDQSBhbmQgYW55IGNlcnRpZmljYXRlcyBpbiBiZXR3 ZWVuDQo+PiAgICAgdGhlIFJlZ2lzdHJhciBhbmQgdGhlIENBIFNIT1VMRCBiZSBwcmVzZW50ZWQu DQo+PiAgICAgU2hvdWxkIHRoZSBkb21haW4gb3duZXIgYmUgdXNpbmcgYSBXZWJQS0kgb2Ygc29t ZSBzb3J0LCBJIHRoaW5rIHRoYXQNCj4+ICAgICBpdCBTSE9VTEQgc2VuZCBpdCBhbGwuDQo+PiAN Cj4+ICAgICBHaXZlbiBwaW5uZWQtZG9tYWluLWNlcnQgKHZzIG91ciBwcmV2aW91cyBpZGVhcyks IHRoZSBpc3N1ZWQgdm91Y2hlcg0KPj4gICAgIGlzIGdvaW5nIHRvIGJlIHBpbm5lZCB0byB0aGUg UmVnaXN0cmFyJ3MgY2VydCAobm90IHNvbWUgRE4gc3BlY2lmaWVkDQo+PiAgICAgY2hhaW4pLiAg QnV0LCB0aGUgYXVkaXQgbG9nIHByb2JhYmx5IG91Z2h0IHRvIGluY2x1ZGUgdGhlIGVudGlyZSBj aGFpbi4NCj4+IA0KPj4gICAgIEFkZGl0aW9uYWxseSwgdGhlIGVudGlyZSBjaGFpbiBNQVkgYmUg bmVlZGVkIGluIG9yZGVyIHRvIHByb3Blcmx5IGludm9rZQ0KPj4gICAgIHRoZSBzYWxlcyBjaGFu bmVsIGludGVncmF0aW9uLg0KPj4gDQo+PiBJZiB5b3UgYWdyZWUgd2l0aCBteSBhbmFseXNpcywg SSB3aWxsIGNvb2sgdXAgc29tZSB0ZXh0IGZvciB0aGUgbmV3bHkNCj4+IGNyZWF0ZWQgMy4yIEV4 YW1wbGVzIHNlY3Rpb24gdG8gZXhwbGFpbiB0aGlzLiAgU29tZSBhZGFwdGF0aW9uIG9mIHRoZQ0K Pj4gdGV4dCBhYm92ZS4NCj4NCj4gSSB0aGluayB3ZeKAmXJlIGNsb3NlIHRvIGFncmVlaW5nLiBT b21lIGNvbW1lbnRzOiANCj4NCj4gSSBsaWtlIHRoZSBqd3QgYXBwcm9hY2ggdG8gY2VydHMgd2hl cmUgdGhleSBpbmNsdWRlIGFuIGVudGlyZSDigJx4NWPigJ0gY2hhaW4NCj4gcmF0aGVyIHRoYW4g YSBzaW5nbGUgY2VydC4gTWF5YmUgd2Ugc2hvdWxkIGJlIGNvcHlpbmcgdGhhdD8gSW4gcGFydGlj dWxhcg0KPiBJIGxpa2UgaXQgYmV0dGVyIHRoYW4gdHJ5aW5nIHRvIHNwZWNpZnkgZXh0cmEgc3R1 ZmYgaW4gdGhlIGNlcnRpZmljYXRlIGJhZy4NCj4gVGhlIGxlc3Mgd2UgZGVwZW5kIG9uIHRoZSBw a2NzIzcgc3RydWN0dXJlIHRoZSBiZXR0ZXIgYW5kIEnigJltIHdpbGxpbmcgdG8NCj4gY2hhbmdl IHRoZSBhYm92ZSB1c2VzIHRvIG1lZXQgdGhhdCBnb2FsLiANCg0KSSBsaWtlIGEgY2hhaW4gbW9y ZSB0aGFuIGEgc2luZ2xlIGNlcnQgYXMgd2VsbC4gIEknbSBhbWJpdmFsZW50IHRvIHRoZQ0KVEEg Y2VydCBiZWluZyBwcm92aWRlZCwgYnV0IEknbSBva2F5IHdpdGggaXQgaWYgaXQgYWxpZ25kIGJl dHRlciB3aXRoDQp4NWMuDQoNCg0KDQoNCj4+IEluIG15IGNvZGUgSSdtIGRvaW5nOg0KPj4gDQo+ PiBpLiAgZXh0cmFjdCB0aGUgZmlyc3QgY2VydGlmaWNhdGUgZnJvbSB0aGUgUEtDUzcgYmFnLCBh bmQgdXNlIGl0IHRvDQo+PiAgICB2ZXJpZnkgdGhlIFBLQ1M3LCB0ZWxsaW5nIHRoZSB2ZXJpZnll ciBub3QgdG8gdmFsaWRhdGUgdGhlIGNoYWluLA0KPj4gICAgYW5kIG5vdCB0byB1c2UgYW55IGNl cnRpZmljYXRlcyBmcm9tIHRoZSBQS0NTNy4NCj4+ICAgIEkgZm91bmQgdGhhdCBJIGNvdWxkIG5v dCBmaW5kIGEgd2F5IHRvIGFjY2VzcyB0aGUgY29udGVudCBvZiB0aGUgUEtDUzcNCj4+ICAgIGNv bnRlbnQgd2l0aG91dCB2ZXJpZnlpbmcgZmlyc3QuICBJIGRvbid0IGtub3cgaWYgdGhpcyBpcyBh IHJ1Ynktb3BlbnNzbCwNCj4+ICAgIG9yIHVuZGVybHlpbmcgbGlic3NsIGxpbWl0YXRpb24geWV0 Lg0KPg0KPiBUaGlzIGlzIGFuIGltcG9ydGFudCBwb2ludC4gSW4gb3BlbnNzbCBJIGJlbGlldmUg SSB3YXMgYWJsZSB0byBjcmFjayBpbnRvIHRoZQ0KPiBkZXRhaWxzIHdpdGhvdXQgdmVyaWZ5aW5n IGFuZCB0aGVuIGdvIGJhY2sgYW5kIHZlcmlmeSBvbmNlIEnigJlkIGV4dHJhY3RlZCB0aGUNCj4g Y2VydCBiYWdzLiANCg0KV2FoPyAgRmlyc3QsIHdlIGNhbid0IGFzc3VtZSB0aGUgMXN0IGNlcnQg aXMgdGhlIG9uZSB5b3Ugd2FudC4gIEluIEFTTi4xDQpwYXJsYW5jZSwgaXQgaXMgYSBTRVQgKG5v dCBhIFNFUVVFTkNFKS4gIE5leHQsIG15IGNvZGUgWzFdIHZhbGlkYXRlZCB0aGUNCnZvdWNoZXIn cyBzaWduYXR1cmUgZmlyc3QgLSBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIG5lZWQgdG8gYmUgb3V0 LW9mLW9yZGVyDQpoZXJlLiAgTGFzdCwgeWVzLCB5b3UgY2FuIGFjY2VzcyB0aGUgY29udGVudHMg d2l0aG91dCB2ZXJpZmljYXRpb24gdXNpbmcNCnRoZSBzbWltZSAtbm92ZXJpZnkgZmxhZy4NCg0K WzFdIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvYmxvYi9tYXN0ZXIv b3BlbnNzbC10ZXN0L2RldmljZS9yZW1vdmFibGUtc3RvcmFnZS1kZXZpY2UvTWFrZWZpbGUNCg0K DQoNCj4+IGlpLiAgSSBsb29rIGF0IHRoZSBjb250ZW50IG5vdywgcGFyc2UgdGhlIEpTT04sIHB1 bGwgcGlubmVkLWRvbWFpbi1jZXJ0IG91dC4NCj4+IGlpaS4gSSB0aGVuIHVzZSB0aGUgcGlubmVk LWRvbWFpbi1jZXJ0IHRvIHZlcmlmeSB0aGUgUEtDUzcgYWdhaW4uICBQZXJoYXBzDQo+PiAgICAg SSBjb3VsZCBkbyBhIG1lbWNweSgpIGFnYWluc3Qgd2hhdCBJIGhhZCBpbiBzdGVwIChpKSwgYW5k IGF2b2lkIHRoZQ0KPj4gICAgIHNlY29uZCBzaWduYXR1cmUgY2hlY2sgaWYgaXQgd2FzIHRoZSBz YW1lLg0KPj4gDQo+PiBJIGNvdWxkIHByb2JhYmx5IGJlIG1vcmUgZmxleGlibGUgaW4gKGkpIGJ5 IHBlcm1pdHRpbmcgaXQgdG8gdXNlIHRoZSBiYWcgb2YNCj4+IGNlcnRpZmljYXRlcywgYnV0IHRl bGxpbmcgaXQgbm90IHRvIHZhbGlkYXRlIGFueSBjaGFpbi4gICBJIGZlZWwgbGlrZSB0aGVyZQ0K Pj4gbWF5IGJlIGFuIGF0dGFjayBsdXJraW5nIGhlcmUgYmVjYXVzZSBJIHdvdWxkbid0IGtub3cg d2hpY2ggY2VydGlmaWNhdGUNCj4+IGFjdHVhbGx5IHZhbGlkYXRlZCB0aGUgb2JqZWN0LCBidXQg dGhhdCdzIGp1c3QgYSBndXQgaW5zdGluY3QuDQo+PiB7QnV0LCB0aGUgYWJvdmUgY2hhbmdlIG1h a2VzIHRoZSBzYW1lIGNvZGUgZGlyZWN0bHkgdXNlYWJsZSBvbiB0aGUgTUFTQSBhcw0KPj4gd2Vs bC4gIEJ1dCwgcmVhbGx5LCBpdCdzIG9ubHkgZm91ciBsaW5lc30NCj4+IA0KPj4gQWx0ZXJuYXRp dmVseSwgaW4gc3RlcCAoaSksIEkgc2hvdWxkIHRyeSBhbGwgdGhlIGNlcnRpZmljYXRlcyB1bnRp bCBvbmUNCj4+IHdvcmtzLCBndWFyZGluZyBhZ2luc3QgdGhlcmUgYmVpbmcgbW9yZSB0aGFuIG9u ZS4NCj4NCj4gRHVubm8gdGhlIG9wdGlvbnMuIEkgYnJvdWdodCBteSBjb2RlIHVwIHRoaXMgZXZl bmluZyB0byByZWxvb2sgYXQgdGhlIA0KPiBwaW5uZWQtY2VydCBkaXNjdXNzaW9uIGluIHRoaXMg ZXhhY3QgYXJlYSBidXQgZGlkbuKAmXQgbWFrZSBhbnkgcHJvZ3Jlc3MuIA0KPiBJ4oCZbGwgdHJ5 IGFuZCBsb29rIGF0IGl0IHRvbW9ycm93LiANCg0KSWYgeW91IGhhdmUgc2VwYXJhdGVseSB2ZXJp ZmllZCB0aGUgc2lnbmVyIGNlcnQgKGUuZy4sICB2YWxpZCBjaGFpbiwgZXRjLiksDQp0aGVuIHlv dSBjYW4gdXNlIGBzbWltZSAtbm92ZXJpZnkgLXNpZ25lciAuLi5gIHdoaWNoICpvbmx5KiB2ZXJp ZmllcyB0aGF0DQp0aGUgc2lnbmVyIGNlcnQgc2lnbmVkIHRoZSBjb250ZW50IChidXQgc2tpcHMg dmVyaWZ5aW5nIGlmIHRoZSBzaWduZXIgY2VydA0KaXMgaXRzZWxmIHZhbGlkKS4NCg0KDQpLLg0K DQoNCg0K From nobody Thu Sep 7 08:19:27 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3181321BB for ; Thu, 7 Sep 2017 08:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrH8Ci__FjOd for ; Thu, 7 Sep 2017 08:19: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 14109132A65 for ; Thu, 7 Sep 2017 08:19:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 57A62203B2; Thu, 7 Sep 2017 11:23:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A8C6F806B4; Thu, 7 Sep 2017 11:19:20 -0400 (EDT) From: Michael Richardson To: "Max Pritikin \(pritikin\)" cc: Anima WG , Kent Watsen In-Reply-To: References: <4705.1504656568@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] PKCS7 certificate SignerData certificates X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 15:19:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: > The voucher-request has this additional requirement: > s3.3 of BRSKI-07, > The request is a "YANG-defined JSON > document that has been signed using a PKCS#7 structure" as > described in [I-D.ietf-anima-voucher] using the JSON encoded > described in [RFC7951]. The Registrar MUST sign the request. The > entire Registrar certificate chain, up to and including the Domain > CA, MUST be included in the PKCS#7 structure. I feel dumb, because I was sure that I looked for such a sentence, and I didn't find it. Good that it is there. >> In a signed voucher request from the pledge to the registrar the >> pinned-domain-cert is that of the *PLEDGE* (signed with it's IDevID). > Actually this pinned-domain-cert is thus, from s3.2 of BRSKI-07, > pinned-domain-cert: In a Pledge voucher request this is the > Registrar certificate as extracted from the TLS handshake (for > example the first certificate in the TLS 'certificate_list' > sequence (see [RFC5246]). This MUST be populated in a Pledge's > voucher request if the "proximity" assertion is populated. Huh, this is actually surprising... I guess we need the Registrar to keep the same thing there, and really the voucher *HAS* to be issued for this key in order for the Pledge to get out = of provisional state... > I was wondering earlier today if this was confusing. We could add a > leaf for =E2=80=9Ctls-domain-cert=E2=80=9D or something. An additiona= l point is that > the *assumption* is that this is the same cert as the id-kp-cmcRA cert > in the chain discussed above and in s3.3 but maybe that is an > assumption too far and we should support bags of certs and arbitrary > complexity? I=E2=80=99m tired of this PKI mess. Yes, that's an assumption. The *VOUCHER* that results has to match the certificate in the TLS. So it makes sense for the PLEDGE to indicate what certificate it is expecting. That lets the Registrar be built using a variety of certificates for load balancing purposes, and deals with a race condition that could occur if the Registrar's certificate is renewed during the imprinting process. If a Registrar wants/needs to update it's cmcRA cert, it could present the previously signed voucher to the MASA with previous... >> a) is that certificate also included in the PKCS7 bag of certificate= s? >> I think the answer SHOULD be yes. >> b) is there any operationally valid reason why there should be addit= ional >> certificates in the PKCS7 bag? >> I can not come up with one. The registrar is never going to validate >> any chain that the manufacturer might have used internally to set up >> their CA for their IDevID. It cares about the end-certificate only. > The reason s3.3. mandates the entire chain, including the domain CA > certificate, is to allow the above consistency checks. But originally > this was so that the domainCA certificate would be used for the pinned > cert. Moving to just the RA cert in the pinned-domain-cert field would > be a simplification? The text of the voucher-05 leaf description seems > to allow this. I would like it to be just the RA cert. >> In a signed voucher request from the JRC (registrar) to the MASA the >> pinned-domain-cert is that of the *Registrar* (signed with it's cmcR= A marked >> certificate from the domain owner's CA). >> >> a) is that certificate also included in the PKCS7 bag of certificate= s? >> I think the answer SHOULD be yes. > This is the current language and *not* that the pinned-domain-cert is > populated at all. In fact if you look at the new voucher-request-yang > branch and Example (2) of the voucher requests you see: Are you saying that pinned-domain-cert should not be populated in the voucher request ("VR") from Registrar->MASA? > I think we=E2=80=99re close to agreeing. Some comments: > I like the jwt approach to certs where they include an entire =E2=80= =9Cx5c=E2=80=9D > chain rather than a single cert. Maybe we should be copying that? In > particular I like it better than trying to specify extra stuff in the > certificate bag. The less we depend on the pkcs#7 structure the better > and I=E2=80=99m willing to change the above uses to meet that goal. So, our pinned-domain-cert in the VR would include the entire chain? What format would we use? Is it just concatenated DER of certificates? >> In my code I'm doing: >> >> i. extract the first certificate from the PKCS7 bag, and use it to >> verify the PKCS7, telling the verifyer not to validate the chain, >> and not to use any certificates from the PKCS7. >> I found that I could not find a way to access the content of the PKC= S7 >> content without verifying first. I don't know if this is a ruby-ope= nssl, >> or underlying libssl limitation yet. > This is an important point. In openssl I believe I was able to crack > into the details without verifying and then go back and verify once I= =E2=80=99d > extracted the cert bags. I believe it should be possible, but that I may not have access to the right API from ruby-openssl. I've now upstreamed one patch for ruby-openssl, so I'll probably fix that and upstream and another patch. >> Alternatively, in step (i), I should try all the certificates until = one >> works, guarding aginst there being more than one. > Dunno the options. I brought my code up this evening to relook at the > pinned-cert discussion in this exact area but didn=E2=80=99t make any > progress. I=E2=80=99ll try and look at it tomorrow. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmxY3gACgkQgItw+93Q 3WXplQf/YCuWgiAixN/RsLYrd8iudXmRR5IY3jAqAK0tc93r2/88aDo64ULQPFg4 x2lQbViijRxGB49X0cYYC7qdJdsfsysc3rfBXWAG4jQDQt+z5s82qwon4D0c+vul dXCwbXjyaWDBz9CRQ0Q5ghVKdBM5M0vQVsLfLyDiFSLmpC1zmjPJ4QCeBkwiXdWS ReXnEQ81BajrXvo7Q0o16VYrHLOGiQhE6J84yfIBnW8xeaO2QdzOvdfSgly/rFgn Bi1aL4Y4/5Fy37MHrZTC8udyVNf4RhAnZ3+by5qNCuUVhYaPU4EaM4SVpWKsfQLc QF138ThH7jeBhBUDARVxVZ3CTygMWw== =2KMw -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 7 08:27:58 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A18132EAB for ; Thu, 7 Sep 2017 08:27:56 -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 Y9zL6arcTvqU for ; Thu, 7 Sep 2017 08:27:55 -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 D5AA1132F40 for ; Thu, 7 Sep 2017 08:27:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DEC69203AF; Thu, 7 Sep 2017 11:31:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32E1E806B4; Thu, 7 Sep 2017 11:27:54 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: "Max Pritikin \(pritikin\)" , Anima WG In-Reply-To: <8EC759E5-598F-43B7-B63E-6008346767B6@juniper.net> References: <4705.1504656568@obiwan.sandelman.ca> <8EC759E5-598F-43B7-B63E-6008346767B6@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] PKCS7 certificate SignerData certificates X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 15:27:56 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: > S6 in the voucher draft says: > The PKCS#7 structure SHOULD also contain all the certificates leading > up to and including the signer's trust anchor certificate known to > the recipient. Agreed. And the MASA should know exactly what that list is for each device. > and S5.4 in the NETCONF zerotouch draft says: > The device MUST first authenticate the ownership voucher by > validating the signature on it to one of its preconfigured trust > anchors (see Section 5.1). > Perhaps it should add "using any addiiotional intermediate certificates > stapled to the voucher"? It would be worth saying: "It may need to use additional intermediate certificates included with the signature artifact (such as PKCS7 SignerData certificates)" > I like a chain more than a single cert as well. I'm ambivalent to the > TA cert being provided, but I'm okay with it if it alignd better with > x5c. I think it's useful for intermediary auditing if the TA cert is included, (and ignored by the pledge). We have an existing situation with WebPKI where some browsers complain if any TA is passed down. During the SHA1->SHA256 switch over for intermediate CAs, it was sometimes necessary to pass extra things that the browsers' would eventually have built-in. > Wah? First, we can't assume the 1st cert is the one you want. In ASN.1 > parlance, it is a SET (not a SEQUENCE). Next, my code [1] validated the > voucher's signature first - I don't understand the need to be > out-of-order > here. Last, yes, you can access the contents without verification using > the smime -noverify flag. I agree, I shouldn't be assuming it's the first certificate. I'm going in via API, not CLI. And btw, the noverify flag in the API still checks that the content is signed by the provided certificate, it just doesn't check that the certificate is valid. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmxZXkACgkQgItw+93Q 3WVHjQf/QmzqphkGW3PbfGbSrA6oXi+lNXNAVzWhW+6xJ7kniI8LC4MtLFfUQfh/ WN13roFxFl3LVAvkoNz15vkeCb2DkZRmV4PReZjXfiBkIn7LeKQarpzmGs4fEEYN WEDn+0k2G6DohUNdknKwTxZiVgooM1krZ9/zQP3K9BcFLyrr3MFwvWWFQR6Uq8Tj Zjvp/vSh/hGPoeNjVRuW+P2av5/eZATNtcLWrrQhHyn2zToHcC3TGdC5uKrwzcV6 h6n3mtwyIcQdPfcLVzk70uyfnZ+1XVskbf45/Jx0L7/gIBtXdIGfqjzc7z7GrXkw 4qwshzH1nXCw88PpvNrdpQZhZ3MMGg== =IJHU -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 8 12:43:12 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D964013292F for ; Fri, 8 Sep 2017 12:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, 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 ERrDq3zPEfuI for ; Fri, 8 Sep 2017 12:43:10 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 0516F1204DA for ; Fri, 8 Sep 2017 12:43:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5810D6228E; Fri, 8 Sep 2017 15:43:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id in16yzjAsC4y; Fri, 8 Sep 2017 15:43:02 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2AF176228C; Fri, 8 Sep 2017 15:43:00 -0400 (EDT) To: Michael Richardson Cc: Kent Watsen , "anima@ietf.org" References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> <99b486aa-b1ec-d488-13f3-2f7bede32e88@htt-consult.com> <14722.1503940755@obiwan.sandelman.ca> From: Robert Moskowitz Message-ID: <0574b0d6-563d-b918-65c3-1fed070a6d58@htt-consult.com> Date: Fri, 8 Sep 2017 15:42:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <14722.1503940755@obiwan.sandelman.ca> Content-Type: multipart/alternative; boundary="------------E02C5C3FA9D020EE6ABAD870" Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 19:43:12 -0000 This is a multi-part message in MIME format. --------------E02C5C3FA9D020EE6ABAD870 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit New version of the draft. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ecdsa-pki-01.txt Date: Fri, 08 Sep 2017 12:26:36 -0700 From: internet-drafts@ietf.org To: Robert Moskowitz , Liang Xia , Henk Birkholz , Liang Xia A new version of I-D, draft-moskowitz-ecdsa-pki-01.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ecdsa-pki Revision: 01 Title: Guide for building an ECC pki Document date: 2017-09-07 Group: Individual Submission Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-01.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ecdsa-pki-01 Abstract: This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates. 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 On 08/28/2017 01:19 PM, Michael Richardson wrote: > Robert Moskowitz wrote: > >> Aren't the formats defined in the drafts? E.g., the voucher draft > >> says it’s a PKCS#7. > > > I think PKCS is mentioned twice in the bootstrap draft. Nothing about > > iDevID format, for example. 802.1AR does not say anything about iDevID > > (or lDevID) format. > > BTW: Doesn't rfc2315 officially replaced PKCS7 from a reference point of view? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > --------------E02C5C3FA9D020EE6ABAD870 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit New version of the draft.




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-ecdsa-pki-01.txt
Date: Fri, 08 Sep 2017 12:26:36 -0700
From: internet-drafts@ietf.org
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Liang Xia <frank.xialiang@huawei.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Liang Xia <Frank.xialiang@huawei.com> 


A new version of I-D, draft-moskowitz-ecdsa-pki-01.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-ecdsa-pki
Revision:	01
Title:		Guide for building an ECC pki
Document date:	2017-09-07
Group:		Individual Submission
Pages:		31
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-01.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ecdsa-pki-01

Abstract:
   This memo provides a guide for building a PKI (Public Key
   Infrastructure) using openSSL.  All certificates in this guide are
   ECDSA, P-256, with SHA256 certificates.  Along with common End Entity
   certificates, this guide provides instructions for creating IEEE
   802.1AR iDevID Secure Device certificates.

                                                                                  


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



On 08/28/2017 01:19 PM, Michael Richardson wrote:
Robert Moskowitz <rgm-sec@htt-consult.com> wrote:
    >> Aren't the formats defined in the drafts?  E.g., the voucher draft
    >> says it’s a PKCS#7.

    > I think PKCS is mentioned twice in the bootstrap draft.  Nothing about
    > iDevID format, for example.  802.1AR does not say anything about iDevID
    > (or lDevID) format.

BTW: Doesn't rfc2315 officially replaced PKCS7 from a reference point of view?

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

--------------E02C5C3FA9D020EE6ABAD870-- From nobody Fri Sep 8 14:24:32 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565921326BB for ; Fri, 8 Sep 2017 14:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7S-Z-byuohE for ; Fri, 8 Sep 2017 14:24:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E07F124E15 for ; Fri, 8 Sep 2017 14:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13314; q=dns/txt; s=iport; t=1504905868; x=1506115468; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X+goZxtUq9u4ZY5F+3dEVu79gnf7FIkjEEZ/cWO8n/k=; b=UpaaKhzTFojOwZmQa95gkBI9kN4FEJw5NzEY3g50PEEKl0ycjBve3Jv6 jorhS3ZD9ZkPvwLzUhekppteOPIPGmXA7ubZRFHW7rx6o4pLXiZBB5Rj4 g2UZY/TeHRXMQ5SxF6g2VjviCC3OCPlgwF0qPECjh5nTpTFhwuE2btsvb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAgAVCbNZ/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg3CaRIF0liiCEgolgV6DOwIag3FAFwECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEDASMEDUUFCwIBBgIYAgImAgICMBUQAgQOBYopCBCNX51mgW06i0IBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYENgh2CAoMzK4J9hGAWgxMwgjEFihKHFo9?= =?us-ascii?q?MAodZg1qJHAyCB5BeiXyLAgIRGQGBOAEhATWBDXcVXAGHCHYBAQOGFyuBBYEPA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.42,363,1500940800"; d="scan'208";a="75109040" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2017 21:24:27 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v88LORdQ019307 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Sep 2017 21:24:27 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 16:24:26 -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.1263.000; Fri, 8 Sep 2017 16:24:26 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: Anima WG , Kent Watsen Thread-Topic: PKCS7 certificate SignerData certificates Thread-Index: AQHTJqRqifnVkYJPxUmkEeSk4gXn+6KnkOeAgAJO/ACAAfhXAA== Date: Fri, 8 Sep 2017 21:24:26 +0000 Message-ID: References: <4705.1504656568@obiwan.sandelman.ca> <27261.1504797560@obiwan.sandelman.ca> In-Reply-To: <27261.1504797560@obiwan.sandelman.ca> 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.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] PKCS7 certificate SignerData certificates X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 21:24:31 -0000 SeKAmXZlIGNvbW1lbnRlZCBpbmxpbmUgYWJvdXQgdGhlc2UgZGlzY3Vzc2lvbi4gDQoNCknigJl2 ZSBhbHNvIHByZXBhcmVkIGEgc2V0IG9mIGRpZmZzIHRvIGhlbHAgYnJpbmcgY2xhcml0eSBhcyBw ZXIgdGhlIGRpc2N1c3Npb24uIFRoZSBkaWZmcyBhcmUgaW4gdGhpcyBicmFuY2g6DQoJaHR0cHM6 Ly9naXRodWIuY29tL2FuaW1hLXdnL2FuaW1hLWJvb3RzdHJhcC9jb21taXQvYmVjNmQ5NzIwN2Fh OGZhYWE2MDBkNjA2MjJjOWI0NjUwZWUwNDkzNA0KDQo+IE9uIFNlcCA3LCAyMDE3LCBhdCA5OjE5 IEFNLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+ IA0KPiANCj4gTWF4IFByaXRpa2luIChwcml0aWtpbikgPHByaXRpa2luQGNpc2NvLmNvbT4gd3Jv dGU6DQo+PiBUaGUgdm91Y2hlci1yZXF1ZXN0IGhhcyB0aGlzIGFkZGl0aW9uYWwgcmVxdWlyZW1l bnQ6DQo+IA0KPj4gczMuMyBvZiBCUlNLSS0wNywNCj4+IFRoZSByZXF1ZXN0IGlzIGEgIllBTkct ZGVmaW5lZCBKU09ODQo+PiBkb2N1bWVudCB0aGF0IGhhcyBiZWVuIHNpZ25lZCB1c2luZyBhIFBL Q1MjNyBzdHJ1Y3R1cmUiIGFzDQo+PiBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLWFuaW1hLXZvdWNo ZXJdIHVzaW5nIHRoZSBKU09OIGVuY29kZWQNCj4+IGRlc2NyaWJlZCBpbiBbUkZDNzk1MV0uICBU aGUgUmVnaXN0cmFyIE1VU1Qgc2lnbiB0aGUgcmVxdWVzdC4gIFRoZQ0KPj4gZW50aXJlIFJlZ2lz dHJhciBjZXJ0aWZpY2F0ZSBjaGFpbiwgdXAgdG8gYW5kIGluY2x1ZGluZyB0aGUgRG9tYWluDQo+ PiBDQSwgTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgUEtDUyM3IHN0cnVjdHVyZS4NCj4gDQo+IEkg ZmVlbCBkdW1iLCBiZWNhdXNlIEkgd2FzIHN1cmUgdGhhdCBJIGxvb2tlZCBmb3Igc3VjaCBhIHNl bnRlbmNlLCBhbmQgSQ0KPiBkaWRuJ3QgZmluZCBpdC4gIEdvb2QgdGhhdCBpdCBpcyB0aGVyZS4N Cj4gDQo+Pj4gSW4gYSBzaWduZWQgdm91Y2hlciByZXF1ZXN0IGZyb20gdGhlIHBsZWRnZSB0byB0 aGUgcmVnaXN0cmFyIHRoZQ0KPj4+IHBpbm5lZC1kb21haW4tY2VydCBpcyB0aGF0IG9mIHRoZSAq UExFREdFKiAoc2lnbmVkIHdpdGggaXQncyBJRGV2SUQpLg0KPiANCj4+IEFjdHVhbGx5IHRoaXMg cGlubmVkLWRvbWFpbi1jZXJ0IGlzIHRodXMsIGZyb20gczMuMiBvZiBCUlNLSS0wNywNCj4gDQo+ PiBwaW5uZWQtZG9tYWluLWNlcnQ6ICBJbiBhIFBsZWRnZSB2b3VjaGVyIHJlcXVlc3QgdGhpcyBp cyB0aGUNCj4+IFJlZ2lzdHJhciBjZXJ0aWZpY2F0ZSBhcyBleHRyYWN0ZWQgZnJvbSB0aGUgVExT IGhhbmRzaGFrZSAoZm9yDQo+PiBleGFtcGxlIHRoZSBmaXJzdCBjZXJ0aWZpY2F0ZSBpbiB0aGUg VExTICdjZXJ0aWZpY2F0ZV9saXN0Jw0KPj4gc2VxdWVuY2UgKHNlZSBbUkZDNTI0Nl0pLiAgVGhp cyBNVVNUIGJlIHBvcHVsYXRlZCBpbiBhIFBsZWRnZSdzDQo+PiB2b3VjaGVyIHJlcXVlc3QgaWYg dGhlICJwcm94aW1pdHkiIGFzc2VydGlvbiBpcyBwb3B1bGF0ZWQuDQo+IA0KPiBIdWgsIHRoaXMg aXMgYWN0dWFsbHkgc3VycHJpc2luZy4uLg0KPiBJIGd1ZXNzIHdlIG5lZWQgdGhlIFJlZ2lzdHJh ciB0byBrZWVwIHRoZSBzYW1lIHRoaW5nIHRoZXJlLCBhbmQgcmVhbGx5IHRoZQ0KPiB2b3VjaGVy ICpIQVMqIHRvIGJlIGlzc3VlZCBmb3IgdGhpcyBrZXkgaW4gb3JkZXIgZm9yIHRoZSBQbGVkZ2Ug dG8gZ2V0IG91dCBvZg0KPiBwcm92aXNpb25hbCBzdGF0ZeKApg0KDQpUaGUgcmVnaXN0cmFyIOKA nGtlZXBz4oCdIHRoaXMgZmllbGQgYnkgcG9wdWxhdGluZyB0aGUgcHJpb3Itc2lnbmVkLXZvdWNo ZXItcmVxdWVzdCAoYWxzbyBwcmVzZXJ2aW5nIHRoZSBQbGVkZ2VzIHNpZ25hdHVyZSBvdmVyIHRo ZSBwcm94aW1pdHkgYXNzZXJ0aW9uKS4gIA0KDQo+IA0KPj4gSSB3YXMgd29uZGVyaW5nIGVhcmxp ZXIgdG9kYXkgaWYgdGhpcyB3YXMgY29uZnVzaW5nLiBXZSBjb3VsZCBhZGQgYQ0KPj4gbGVhZiBm b3Ig4oCcdGxzLWRvbWFpbi1jZXJ04oCdIG9yIHNvbWV0aGluZy4gQW4gYWRkaXRpb25hbCBwb2lu dCBpcyB0aGF0DQo+PiB0aGUgKmFzc3VtcHRpb24qIGlzIHRoYXQgdGhpcyBpcyB0aGUgc2FtZSBj ZXJ0IGFzIHRoZSBpZC1rcC1jbWNSQSBjZXJ0DQo+PiBpbiB0aGUgY2hhaW4gZGlzY3Vzc2VkIGFi b3ZlIGFuZCBpbiBzMy4zIGJ1dCBtYXliZSB0aGF0IGlzIGFuDQo+PiBhc3N1bXB0aW9uIHRvbyBm YXIgYW5kIHdlIHNob3VsZCBzdXBwb3J0IGJhZ3Mgb2YgY2VydHMgYW5kIGFyYml0cmFyeQ0KPj4g Y29tcGxleGl0eT8gSeKAmW0gdGlyZWQgb2YgdGhpcyBQS0kgbWVzcy4NCj4gDQo+IFllcywgdGhh dCdzIGFuIGFzc3VtcHRpb24uDQo+IFRoZSAqVk9VQ0hFUiogdGhhdCByZXN1bHRzIGhhcyB0byBt YXRjaCB0aGUgY2VydGlmaWNhdGUgaW4gdGhlIFRMUy4NCj4gU28gaXQgbWFrZXMgc2Vuc2UgZm9y IHRoZSBQTEVER0UgdG8gaW5kaWNhdGUgd2hhdCBjZXJ0aWZpY2F0ZSBpdCBpcw0KPiBleHBlY3Rp bmcuDQo+IA0KPiBUaGF0IGxldHMgdGhlIFJlZ2lzdHJhciBiZSBidWlsdCB1c2luZyBhIHZhcmll dHkgb2YgY2VydGlmaWNhdGVzIGZvcg0KPiBsb2FkIGJhbGFuY2luZyBwdXJwb3NlcywgYW5kIGRl YWxzIHdpdGggYSByYWNlIGNvbmRpdGlvbiB0aGF0IGNvdWxkIG9jY3VyIGlmDQo+IHRoZSBSZWdp c3RyYXIncyBjZXJ0aWZpY2F0ZSBpcyByZW5ld2VkIGR1cmluZyB0aGUgaW1wcmludGluZyBwcm9j ZXNzLg0KPiANCj4gSWYgYSBSZWdpc3RyYXIgd2FudHMvbmVlZHMgdG8gdXBkYXRlIGl0J3MgY21j UkEgY2VydCwgaXQgY291bGQgcHJlc2VudA0KPiB0aGUgcHJldmlvdXNseSBzaWduZWQgdm91Y2hl ciB0byB0aGUgTUFTQSB3aXRoIHByZXZpb3Vz4oCmDQoNClRoZXJlIGFyZSB0d28gcGxhY2VzIHdo ZXJlIGNvbnNpc3RlbnQgdXNlIG9mIFJlZ2lzdHJhciBjZXJ0IG9uIGJvdGggbGVncyBpcyByZWZl cmVuY2VkLiAgDQoNCkZpcnN0IEJSU0tJLTA4IHM0LjMgaW5kaWNhdGVzIHRoZSBNQVNBICJNQVkg dmVyaWZ54oCdIHRoZSBwbGVkZ2XigJlzIHByb3hpbWl0eSBhc3NlcnRpb24gaXMg4oCcY29uc2lz dGVudCB3aXRoIHRoZSBbUmVnaXN0cmFy4oCZcyBSZWdpc3RyYXIncyAnVExTIGNsaWVudCBjZXJ0 aWZpY2F0ZV3igJ0uIFRoZSBSZWdpc3RyYXLigJlzIFRMUyBjbGllbnQgY2VydGlmaWNhdGUgY2hh aW4gcm9vdCBjZXJ0aWZpY2F0ZSBpcyB0aGVuIHVzZWQgdG8gcG9wdWxhdGUgdGhlIOKAmHBpbm5l ZC1kb21haW4tY2VydOKAmSAoZmluYWwgcGFyYWdyYXBoIHM0LjMpLg0KDQpTZWNvbmQgQlJTS0kt MDggczQuNCBpbmRpY2F0ZXMgaG93IHRoZSBQbGVkZ2UgY29tcGxldGVzIHRoZSBwcm92aXNpb25h bCBUTFMgYXV0aGVudGljYXRpb246ICJUaGUgJ3Bpbm5lZC1kb21haW4tY2VydCcgZWxlbWVudCBv ZiB0aGUgdm91Y2hlciBjb250YWlucyB0aGUgZG9tYWluIENBJ3MgcHVibGljIGtleS4gVGhlIFBs ZWRnZSBNVVNUIHVzZSB0aGUgJ3Bpbm5lZC1kb21haW4tY2VydCcgdHJ1c3QgYW5jaG9yIHRvIGlt bWVkaWF0ZWx5IGNvbXBsZXRlIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBwcm92aXNpb25hbCBUTFMg Y29ubmVjdGlvbi4iDQoNClRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaGVyZSBhbGxvd3MgZm9yIFBs ZWRnZXMgdGhhdCBkb27igJl0IG1ha2UgdGhlIHByb3hpbWl0eSBhc3NlcnRpb24uIFRoaXMgYWxz byBhbGxvd3MgYSBSZWdpc3RyYXIgdG8gcHJlc2VudCBhIGNlcnQgdG8gdGhlIFBsZWRnZSB0aGF0 IGlzICpkaWZmZXJlbnQqIHRoYW4gdGhlIGNlcnQgaXQgcHJlc2VudHMgdG8gdGhlIE1BU0E7IHNv IGxvbmcgYXMgdGhleSBhcmUgaXNzdWVkIGJ5IHRoZSBzYW1lIENBIGFuZCBzbyBsb25nIGFzIHRo ZSBNQVNBIGFsbG93cyBmb3IgdGhlIGRpc2NyZXBhbmN5LiBXZSAqY291bGQqIHN0cmVuZ3RoZW4g dGhpcyBub3JtYXRpdmUgc3RhdGVtZW50IGxpa2Ugc286DQoNCgnigJxJZiB0aGUgUGxlZGdlIHBy b3ZpZGVzIGEgcHJveGltaXR5IGFzc2VydGlvbiB0aGVuIHRoZSBNQVNBIE1VU1QgdmVyaWZ54oCm 4oCdDQoNClRoZSBjdXJyZW50IGxvZ2ljIGlzIHNvZnRlciB0byBhbGxvdyBmb3IgbW9yZSBmbGV4 aWJpbGl0eSBpbiBQbGVkZ2UgYmVoYXZpb3IuIFNlZSBteSBuZXh0IGNvbW1lbnQ6DQoNCj4+PiBh KSBpcyB0aGF0IGNlcnRpZmljYXRlIGFsc28gaW5jbHVkZWQgaW4gdGhlIFBLQ1M3IGJhZyBvZiBj ZXJ0aWZpY2F0ZXM/DQo+Pj4gSSB0aGluayB0aGUgYW5zd2VyIFNIT1VMRCBiZSB5ZXMuDQo+Pj4g YikgaXMgdGhlcmUgYW55IG9wZXJhdGlvbmFsbHkgdmFsaWQgcmVhc29uIHdoeSB0aGVyZSBzaG91 bGQgYmUgYWRkaXRpb25hbA0KPj4+IGNlcnRpZmljYXRlcyBpbiB0aGUgUEtDUzcgYmFnPw0KPj4+ IEkgY2FuIG5vdCBjb21lIHVwIHdpdGggb25lLiBUaGUgcmVnaXN0cmFyIGlzIG5ldmVyIGdvaW5n IHRvIHZhbGlkYXRlDQo+Pj4gYW55IGNoYWluIHRoYXQgdGhlIG1hbnVmYWN0dXJlciBtaWdodCBo YXZlIHVzZWQgaW50ZXJuYWxseSB0byBzZXQgdXANCj4+PiB0aGVpciBDQSBmb3IgdGhlaXIgSURl dklELiAgSXQgY2FyZXMgYWJvdXQgdGhlIGVuZC1jZXJ0aWZpY2F0ZSBvbmx5Lg0KPiANCj4+IFRo ZSByZWFzb24gczMuMy4gbWFuZGF0ZXMgdGhlIGVudGlyZSBjaGFpbiwgaW5jbHVkaW5nIHRoZSBk b21haW4gQ0ENCj4+IGNlcnRpZmljYXRlLCBpcyB0byBhbGxvdyB0aGUgYWJvdmUgY29uc2lzdGVu Y3kgY2hlY2tzLiBCdXQgb3JpZ2luYWxseQ0KPj4gdGhpcyB3YXMgc28gdGhhdCB0aGUgZG9tYWlu Q0EgY2VydGlmaWNhdGUgd291bGQgYmUgdXNlZCBmb3IgdGhlIHBpbm5lZA0KPj4gY2VydC4gTW92 aW5nIHRvIGp1c3QgdGhlIFJBIGNlcnQgaW4gdGhlIHBpbm5lZC1kb21haW4tY2VydCBmaWVsZCB3 b3VsZA0KPj4gYmUgYSBzaW1wbGlmaWNhdGlvbj8gVGhlIHRleHQgb2YgdGhlIHZvdWNoZXItMDUg bGVhZiBkZXNjcmlwdGlvbiBzZWVtcw0KPj4gdG8gYWxsb3cgdGhpcy4NCj4gDQo+IEkgd291bGQg bGlrZSBpdCB0byBiZSBqdXN0IHRoZSBSQSBjZXJ0Lg0KDQpXaGVyZSDigJxqdXN0IHRoZSBSQSBj ZXJ04oCdIGlzIGEgc2ltcGxpZmljYXRpb24sIHRydWUuIEkgdGhpbmsgdGhlIGN1cnJlbnQgbGFu Z3VhZ2Ugb2YgdXNpbmcgdGhlIHBpbm5lZC1kb21haW4tY2VydCBwcm92aWRlcyBhIHNldCBvZiBi ZW5lZml0czoNCg0KCWEpIGFsbG93cyB0aGUgUkFzIHRvIGNoYW5nZSBjZXJ0cyBhcyBuZWVkZWQg YmV0d2VlbiB2b3VjaGVyIHJlcXVlc3RzIGFuZCBkZXBsb3ltZW50cw0KCWIpIHNpbXBsaWZpZXMg bG9nIHZlcmlmaWNhdGlvbiBhcyBpdHMgYWx3YXlzIHJvb3QgQ0EgY2VydHMgaW4gdGhlIGxvZw0K CWMpIEVuc3VyZXMgUGxlZGdlcyDigJxwaW7igJ0gYSByb290IGNlcnQgaW5zdGVhZCBvZiBhIHN1 YmNlcnQgd2l0aGluIHRoZSB0cmVlDQoJZCkgRm9yIFBsZWRnZXMgdGhhdCBkb27igJl0IGRvIEVT VCB0aGV5IGhhdmUgYSBDQSBjZXJ0IHJhdGhlciB0aGFuIGp1c3QgYW4gUkENCgkJKG5vdGU6IHM0 LjcgaW5kaWNhdGVzIG9ubHkgdGhhdCBQbGVkZ2VzIOKAnFNIT1VMROKAnSBjb250aW51ZSB3aXRo IEVTVCkNCg0KUG9pbnQgKGQpIGlzIGltcG9ydGFudC4gSWYgd2UgY2hhbmdlIHRvIGEg4oCYcmVn aXN0cmFyLWNlcnTigJkgd2XigJlkIG5lZWQgdG8gc3RyZW5ndGhlbiB0aGF0IHJlY29tbWVuZGF0 aW9uIHRvIGEg4oCcTVVTVOKAnS4NCg0KPj4+IEluIGEgc2lnbmVkIHZvdWNoZXIgcmVxdWVzdCBm cm9tIHRoZSBKUkMgKHJlZ2lzdHJhcikgdG8gdGhlIE1BU0EgdGhlDQo+Pj4gcGlubmVkLWRvbWFp bi1jZXJ0IGlzIHRoYXQgb2YgdGhlICpSZWdpc3RyYXIqIChzaWduZWQgd2l0aCBpdCdzIGNtY1JB IG1hcmtlZA0KPj4+IGNlcnRpZmljYXRlIGZyb20gdGhlIGRvbWFpbiBvd25lcidzIENBKS4NCj4+ PiANCj4+PiBhKSBpcyB0aGF0IGNlcnRpZmljYXRlIGFsc28gaW5jbHVkZWQgaW4gdGhlIFBLQ1M3 IGJhZyBvZiBjZXJ0aWZpY2F0ZXM/DQo+Pj4gSSB0aGluayB0aGUgYW5zd2VyIFNIT1VMRCBiZSB5 ZXMuDQo+IA0KPj4gVGhpcyBpcyB0aGUgY3VycmVudCBsYW5ndWFnZSBhbmQgKm5vdCogdGhhdCB0 aGUgcGlubmVkLWRvbWFpbi1jZXJ0IGlzDQo+PiBwb3B1bGF0ZWQgYXQgYWxsLiBJbiBmYWN0IGlm IHlvdSBsb29rIGF0IHRoZSBuZXcgdm91Y2hlci1yZXF1ZXN0LXlhbmcNCj4+IGJyYW5jaCBhbmQg RXhhbXBsZSAoMikgb2YgdGhlIHZvdWNoZXIgcmVxdWVzdHMgeW91IHNlZToNCj4gDQo+IEFyZSB5 b3Ugc2F5aW5nIHRoYXQgcGlubmVkLWRvbWFpbi1jZXJ0IHNob3VsZCBub3QgYmUgcG9wdWxhdGVk IGluIHRoZQ0KPiB2b3VjaGVyIHJlcXVlc3QgKCJWUiIpIGZyb20gUmVnaXN0cmFyLT5NQVNBPw0K DQpJdHMgcG9wdWxhdGVkIHZpYSB0aGUgcHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCAoc2Vl IGFib3ZlKS4NCg0KPiANCj4+IEkgdGhpbmsgd2XigJlyZSBjbG9zZSB0byBhZ3JlZWluZy4gU29t ZSBjb21tZW50czoNCj4gDQo+PiBJIGxpa2UgdGhlIGp3dCBhcHByb2FjaCB0byBjZXJ0cyB3aGVy ZSB0aGV5IGluY2x1ZGUgYW4gZW50aXJlIOKAnHg1Y+KAnQ0KPj4gY2hhaW4gcmF0aGVyIHRoYW4g YSBzaW5nbGUgY2VydC4gTWF5YmUgd2Ugc2hvdWxkIGJlIGNvcHlpbmcgdGhhdD8gSW4NCj4+IHBh cnRpY3VsYXIgSSBsaWtlIGl0IGJldHRlciB0aGFuIHRyeWluZyB0byBzcGVjaWZ5IGV4dHJhIHN0 dWZmIGluIHRoZQ0KPj4gY2VydGlmaWNhdGUgYmFnLiBUaGUgbGVzcyB3ZSBkZXBlbmQgb24gdGhl IHBrY3MjNyBzdHJ1Y3R1cmUgdGhlIGJldHRlcg0KPj4gYW5kIEnigJltIHdpbGxpbmcgdG8gY2hh bmdlIHRoZSBhYm92ZSB1c2VzIHRvIG1lZXQgdGhhdCBnb2FsLg0KPiANCj4gU28sIG91ciBwaW5u ZWQtZG9tYWluLWNlcnQgaW4gdGhlIFZSIHdvdWxkIGluY2x1ZGUgdGhlIGVudGlyZSBjaGFpbj8N Cj4gV2hhdCBmb3JtYXQgd291bGQgd2UgdXNlPyAgSXMgaXQganVzdCBjb25jYXRlbmF0ZWQgREVS IG9mIGNlcnRpZmljYXRlcz8NCg0KQ3VycmVudCBsYW5ndWFnZSBpcyAqb25seSogdGhlIFJlZ2lz dHJhcuKAmXMgY2VydC4gDQoNCjEpIFRoZSBQbGVkZ2UgYXR0ZXN0cyB0byB0aGUgc2VlbiDigJxw cm94aW1pdHktcmVnaXN0cmFyLWNlcnTigJ0gYnkgZXh0cmFjdGluZyB0aGUgUmVnaXN0cmFy4oCZ cyBUTFMgc2VydmVyIGNlcnQgZnJvbSB0aGUgVExTIGhhbmRzaGFrZS4gVGhpcyBpcyBhIHNpbmds ZSBjZXJ0IG5vdCBhIGNoYWluLiBUaGlzIG5ldyB2b3VjaGVyIHJlcXVlc3QgbGVhZiBuYW1lIGlz IG5vdyBjbGVhcmVyIGluIHRoaXMgcG9pbnQuDQoNCjIpIFRoZSBNQVNBIGF0dGVzdHMgdG8gdGhl IHNlZW4g4oCccGlubmVkLWRvbWFpbi1jZXJ04oCdIGJ5IGV4dHJhY3RpbmcgdGhlIFJlZ2lzdHJh cuKAmXMgKnJvb3QgQ0EgY2VydGlmaWNhdGUqIGZyb20gdGhlIFBLQ1MjNyBzaWduYXR1cmUuDQoN ClRoZSBjaGFuZ2VzIGluIHRoZSBhYm92ZSBicmFuY2ggZG9u4oCZdCBlZmZlY3QgdGhlIG5vcm1h dGl2ZSBiZWhhdmlvciBidXQgZG8gcHJvdmlkZSBjbGFyaXR5OyBJIHN1Z2dlc3Qgd2UgYWRvcHQg dGhlbS4gQmV5b25kIHRoYXQgdGhlIHF1ZXN0aW9uIGF0IGhhbmQgaXM6DQoNClExKSBzaG91bGQg d2UgbWFrZSDigJxyZWdpc3RyYXItY2VydOKAnSBvciDigJxkb21haW4tY2VydOKAnSBjb25zaXN0 ZW50IGFyb3VuZCDigJxyZWdpc3RyYXLigJ0gb3Ig4oCcZG9tYWlu4oCdIG9yIG1haW50YWluIHRo ZSBjdXJyZW50IGRpZmZlcmVuY2VzPw0KUTIpIGlmIHdlIG1vdmUgdG8g4oCcY2hhaW7igJ0gc2hv dWxkIHdlIG1vdmUgYWxsIHRoZSB3YXkgdG8g4oCcZG9tYWluLWNoYWlu4oCdPyBbMV0NCg0KTXkg dGhpbmtpbmcgaXMgdG8gYWNjZXB0IG15IGJyYW5jaOKAmXMgZGlmZnMgYnV0IG5vdCBtb3ZlIHRv d2FyZCBjaGFpbnMuIA0KDQotIG1heA0KDQoNClsxXSBXaGF0IHdvdWxkIOKAmGNoYWlu4oCZIGxv b2sgbGlrZT8NCg0KeDVjIGlzIHdlbGwgZGVmaW5lZCBhcyBhIEpTT04gZmllbGQuIEnigJlkIHVz ZSB0aGUgc3RydWN0dXJlIGFzIGlzLiBTb21ldGhpbmcgbGlrZSB0aGUgbGFuZ3VhZ2Ugb2YgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTUjc2VjdGlvbi00LjEuNiBtb2RpZmllZCB0 byB0aGlzOg0KCVRoZSAicHJveGltaXR5LWRvbWFpbi1jaGFpbuKAnSBwYXJhbWV0ZXIgY29udGFp bnMgdGhlIFguNTA5IHB1YmxpYyBrZXkgDQoJY2VydGlmaWNhdGUgb3IgY2VydGlmaWNhdGUgY2hh aW4gW1JGQzUyODBdIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGtleSANCgl1c2VkIGZvciBUTFMgc2Vy dmVyIGF1dGhlbnRpY2F0aW9uIGJ5IHRoZSBSZWdpc3RyYXIgdGhlIFBsZWRnZSBpcyBjb21tdW5p Y2F0aW5nIHdpdGguDQpJIGhhdmUgTk9UIG1hZGUgdGhpcyBtb2RpZmljYXRpb24uDQoNCj4+PiBJ biBteSBjb2RlIEknbSBkb2luZzoNCj4+PiANCj4+PiBpLiAgZXh0cmFjdCB0aGUgZmlyc3QgY2Vy dGlmaWNhdGUgZnJvbSB0aGUgUEtDUzcgYmFnLCBhbmQgdXNlIGl0IHRvDQo+Pj4gdmVyaWZ5IHRo ZSBQS0NTNywgdGVsbGluZyB0aGUgdmVyaWZ5ZXIgbm90IHRvIHZhbGlkYXRlIHRoZSBjaGFpbiwN Cj4+PiBhbmQgbm90IHRvIHVzZSBhbnkgY2VydGlmaWNhdGVzIGZyb20gdGhlIFBLQ1M3Lg0KPj4+ IEkgZm91bmQgdGhhdCBJIGNvdWxkIG5vdCBmaW5kIGEgd2F5IHRvIGFjY2VzcyB0aGUgY29udGVu dCBvZiB0aGUgUEtDUzcNCj4+PiBjb250ZW50IHdpdGhvdXQgdmVyaWZ5aW5nIGZpcnN0LiAgSSBk b24ndCBrbm93IGlmIHRoaXMgaXMgYSBydWJ5LW9wZW5zc2wsDQo+Pj4gb3IgdW5kZXJseWluZyBs aWJzc2wgbGltaXRhdGlvbiB5ZXQuDQo+IA0KPj4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgcG9pbnQu IEluIG9wZW5zc2wgSSBiZWxpZXZlIEkgd2FzIGFibGUgdG8gY3JhY2sNCj4+IGludG8gdGhlIGRl dGFpbHMgd2l0aG91dCB2ZXJpZnlpbmcgYW5kIHRoZW4gZ28gYmFjayBhbmQgdmVyaWZ5IG9uY2Ug SeKAmWQNCj4+IGV4dHJhY3RlZCB0aGUgY2VydCBiYWdzLg0KPiANCj4gSSBiZWxpZXZlIGl0IHNo b3VsZCBiZSBwb3NzaWJsZSwgYnV0IHRoYXQgSSBtYXkgbm90IGhhdmUgYWNjZXNzIHRvIHRoZSBy aWdodA0KPiBBUEkgZnJvbSBydWJ5LW9wZW5zc2wuICBJJ3ZlIG5vdyB1cHN0cmVhbWVkIG9uZSBw YXRjaCBmb3IgcnVieS1vcGVuc3NsLCBzbw0KPiBJJ2xsIHByb2JhYmx5IGZpeCB0aGF0IGFuZCB1 cHN0cmVhbSBhbmQgYW5vdGhlciBwYXRjaC4NCj4gDQo+Pj4gQWx0ZXJuYXRpdmVseSwgaW4gc3Rl cCAoaSksIEkgc2hvdWxkIHRyeSBhbGwgdGhlIGNlcnRpZmljYXRlcyB1bnRpbCBvbmUNCj4+PiB3 b3JrcywgZ3VhcmRpbmcgYWdpbnN0IHRoZXJlIGJlaW5nIG1vcmUgdGhhbiBvbmUuDQo+IA0KPj4g RHVubm8gdGhlIG9wdGlvbnMuIEkgYnJvdWdodCBteSBjb2RlIHVwIHRoaXMgZXZlbmluZyB0byBy ZWxvb2sgYXQgdGhlDQo+PiBwaW5uZWQtY2VydCBkaXNjdXNzaW9uIGluIHRoaXMgZXhhY3QgYXJl YSBidXQgZGlkbuKAmXQgbWFrZSBhbnkNCj4+IHByb2dyZXNzLiBJ4oCZbGwgdHJ5IGFuZCBsb29r IGF0IGl0IHRvbW9ycm93Lg0KPiANCj4gDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiAtPSBJ UHY2IElvVCBjb25zdWx0aW5nID0tDQo+IA0KPiANCj4gDQoNCg== From nobody Fri Sep 8 15:50:42 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545DE129C41 for ; Fri, 8 Sep 2017 15:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SWQiF2_luA6 for ; Fri, 8 Sep 2017 15:50:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2002F124F57 for ; Fri, 8 Sep 2017 15:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4070; q=dns/txt; s=iport; t=1504911036; x=1506120636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TSg1BSLkmfRVyuDkRtZHIylThXT/gu8XBOUqSiftwgY=; b=ljFWqUYjeMLTUTjy9vAZA3NI4DbH/6l/QIVtZbj0u+jryd4QVb6BAm8c VDqJQOcj+5e+3WuVvLnUB+P4hrdDUlUGE2QbhpyYV4y4MxJluMMUewzLl 855ek25egae7pMJ6Xq4MDX06yyMLraT//IWgEcAtaReZtYFZ7SJRieiXi w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAAByHrNZ/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg3CKIZAjgVIid5UxghIKGA2BXoM7AhqDcT8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQMBAQEhBA06CwULAgEIGAICJgICAiULFRACBA4FiikIEKsng?= =?us-ascii?q?W06i0IBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYENgh2CAoMzKwuCPTWEZhCDEzC?= =?us-ascii?q?CMQWgdAKHWYx2knGUfgIRGQGBOAEfOIENdxVKEgGHCHYFh0eBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,363,1500940800"; d="scan'208";a="75131796" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2017 22:50:34 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v88MoYa8012995 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Sep 2017 22:50:34 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 17:50: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.1263.000; Fri, 8 Sep 2017 17:50:34 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: anima Thread-Topic: [Anima] two EST question/suggestions Thread-Index: AQHTIQXdDQD3LWJmSEK5TOw40YgcLaKr+4eA Date: Fri, 8 Sep 2017 22:50:33 +0000 Message-ID: References: <961.1504038708@obiwan.sandelman.ca> In-Reply-To: <961.1504038708@obiwan.sandelman.ca> 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.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 22:50:41 -0000 DQo+IE9uIEF1ZyAyOSwgMjAxNywgYXQgMjozMSBQTSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IE1heCwgSSBzdWdnZXN0IHRoYXQg d2UgYWRkIHNvbWUgdGV4dCB0byBzZWN0aW9uIDIgdG8gaW5kaWNhdGUgdGhhdCBCUlNLSSBFU1QN Cj4gY29ubmVjdGlvbnMgU0hPVUxEIGJlIEhUVFAgMS4xIHBlcnNpc3RlbnQgY29ubmVjdGlvbnMu DQo+IEkgd3JvdGU6DQo+ICAgICAgICA8dD5Fc3RhYmxpc2htZW50IG9mIHRoZSBUTFMgY29ubmVj dGlvbiBmb3IgYm9vdHN0cmFwcGluZyBpcyBhcw0KPiAgICAgICAgICAgc3BlY2lmaWVkIGluIEVT VCA8eHJlZiB0YXJnZXQ9IlJGQzcwMzAiLz4gc2VjdGlvbiA0LjEuMSAiQm9vdHN0cmFwDQo+ICAg ICAgICAgICBEaXN0cmlidXRpb24gb2YgQ0EgQ2VydGlmaWNhdGVzIiA8eHJlZiB0YXJnZXQ9IlJG QzcwMzAiLz4uDQo+ICAgICAgICAgICBXaGlsZSBFU1Qgc2VjdGlvbiAzLjIgZG9lcyBub3QgaW5z aXN0DQo+ICAgICAgICAgICB1cG9uIHVzZSBvZiBIVFRQIDEuMSBwZXJzaXN0ZW50DQo+ICAgICAg ICAgICBjb25uZWN0aW9ucywgQlJTS0kgY29ubmVjdGlvbnMgU0hPVUxEIHVzZQ0KPiAgICAgICAg ICAgcGVyc2lzdGVudCBjb25uZWN0aW9ucy4gIFRoaXMgaXMgZHVlIHRvIHRoZSBwcm92aXNpb25h bCBzdGF0ZQ0KPiAgICAgICAgICAgdGhhdCBvY2N1cnMgaW4gdGhlIFRMUyBjb25uZWN0aW9uLg0K PiAgICAgICAgICAgVGhlIGZvbGxvd2luZyBleHRlbnNpb25zIGFyZSBhZGRlZCBmb3IgYXV0b21h dGlvbjoNCj4gICAgICAgICA8L3Q+DQo+IA0KDQpJIGFncmVlIHdpdGggdGhpcyBhbmQgdXNlZCB0 aGUgY2hhbmdlIHRvIHRpZ2h0ZW4gbGFuZ3VhZ2UgYWJvdXQgRVNUIGludGVncmF0aW9uIGEgYml0 IG1vcmU6DQoJaHR0cHM6Ly9naXRodWIuY29tL2FuaW1hLXdnL2FuaW1hLWJvb3RzdHJhcC9jb21t aXQvZGVmOWU2MzUxYjAzZjkzMDczZjdmZjA5ZWJiYWJkODdlODY0M2Y5NQ0KDQo+IFdlIG1heSBh bHNvIHdhbnQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCBIVFRQIDIuMCdzIG11bHRpcGxleGVkDQo+ IHJlcXVlc3QvcmVzcG9uc2VzIChJIHRoaW5rIHdlIGRvbid0IHdhbnQgdGhlbSkuICBJJ20gbm90 IHN1cmUgZXhhY3RseSB3aGF0DQo+IHRoZSBsaXN0IG9mIHRoaW5ncyB3ZSBkb24ndCB3YW50IHll dCwgb3IgaG93IHRvIGV4cHJlc3MgdGhpcy4NCj4gSSBhbSBzdXJlIHRoYXQgd2UgZG9uJ3Qgd2Fu dCBRVUlDIChvciBTUERZKSBvciBvdGhlciBzdHVmZiBsaWtlIHRoYXQhDQo+IA0KPiBJIGRvbid0 IGtub3cgaWYgdGhlIGJpbmFyeS1uZXNzIG9mIEhUVFAyIG1hdHRlcnMgdG8gdXNlIGF0IGFsbCBp biB0aGUgZW5kLA0KPiBhbmQgd2Ugc2hvdWxkIGp1c3QgbGV0IHRoYXQgdXBncmFkZSBwYXRoIHNp bXBseSBwcm9jZWVlZC4NCg0KVGhlIG9ubHkgSFRUUCB2ZXJzaW9uIHdlIGluZGljYXRlIGlzIDEu MS4gaW4geW91ciBsYW5ndWFnZSBpbnNlcnRlZCBhYm92ZS4gDQpFU1QgaXMgc2ltaWxhcmx5IHZh Z3VlLCBvbmx5IHJlZmVyZW5jaW5nIDEuMS4gaW4gdGhlIGNvbnRleHQgb2YgcGVyc2lzdGVudCBj b25uZWN0aW9ucy4gDQoNCkkgYWdyZWUgYSBzdGF0ZW1lbnQgdGhhdCBIVFRQMiBldGMgaXMgb2sg c28gbG9uZyBhcyBpdCBkb2VzbuKAmXQgY2hhbmdlIHRoZSBwb3NzaWJsZSBjbGllbnQgc3RhdGUg bWFjaGluZeKApiAgPw0KDQo+IA0KPiBUaGUgb3RoZXIgcXVlc3Rpb24gaXMgYWJvdXQgdGhlIHVz ZSBvZiAxMDIgUHJvY2Vzc2luZyBjb2RlcywgYW5kIDIwMSBDcmVhdGVkDQo+IGNvZGVzLiAgSSB0 aGluayB0aGF0IHdlIGRpc2N1c3NlZCBtYWtpbmcgL3JlcXVlc3R2b3VjaGVyIG1vcmUgUkVTVGZ1 bCBieQ0KPiByZXR1cm5pbmcgYSAyMDEgQ3JlYXRlZCwgYWxvbmcgd2l0aCBhIExvY2F0aW9uOiBo ZWFkZXIsIGFuZCBkZWNpZGVkIGFnYWluc3QNCj4gaXQuICBJIHRoaW5rIHRoYXQgSSdtIHBhcnRs eSByZS1vcGVuaW5nIHRoaXMgcXVlc3Rpb24uIChTaGFsbCBJIG1ha2UgaXQgYSB0aWNrZXQpDQoN CknigJlkIHJlY29tbWVuZCBhIHRpY2tldC4gTm90IHN1cmUgSSB3YW50IHRvIG9wZW4gdGhpcyBh Z2FpbiBidXQgYW0gd2lsbGluZyB0byBoZWFyIHRoZSBhcmd1bWVudC4gDQoNCj4gDQo+IFRoZSBy ZWFzb24gZm9yIG15IHF1ZXN0aW9uIGlzIGFib3V0IFJlZ2lzdHJhci0+TUFTQSBpbnRlcmFjdGlv bnMgdGhhdCBuZWVkIHRvDQo+IG9jY3VyLCBhbmQgdGltZW91dHMgdGhhdCBtaWdodCBvY2N1ci4g IFJldHVybmluZyBhIDIwMSBDcmVhdGVkIHBvaW50aW5nIHRvIGENCj4gVVJMIHRoYXQgY291bGQg YmUgdXNlZCB0byByZXRyaWV2ZSB0aGUgcmVzdWx0aW5nIHZvdWNoZXIgd291bGQgcHJvdmlkZSBh IG5pY2UNCj4gd2F5IHRvIGRvIHRoaW5ncy4gSWYgdXBvbiB0aGUgcGxlZGdlIGlzc3VpbmcgdGhl IEdFVCwgdGhlIHZvdWNoZXIgc3RpbGwgaXNuJ3QNCj4gcmVhZHksIGEgMTAyIFByb2Nlc3Npbmcg Y29kZSBjb3VsZCBiZSByZXR1cm5lZC4NCj4gDQo+IEknbSBwYXJ0aWN1bGFybHkgY29uY2VybmVk IHRoYXQgdGhlIHBsZWRnZSBub3Qgc2V0IHRvby1zaG9ydCB0aW1lb3V0cyBoZXJlLA0KPiBhcyB0 aGUgb25seSByZWNvdXJzZSBpdCB3b3VsZCBoYXZlIGlzIHRvIGNsb3NlIHRoZSBjb25uZWN0aW9u Lg0KDQp1bmRlcnN0b29kLA0KDQotIG1heA0KDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRz b24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiAt PSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiBB bmltYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fu aW1hDQoNCg== From nobody Mon Sep 11 18:41:37 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F13133226 for ; Mon, 11 Sep 2017 18:41: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 mx50wTeF1NJ9 for ; Mon, 11 Sep 2017 18:41: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 CA0A1133227 for ; Mon, 11 Sep 2017 18:41:33 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 188so18535497pgb.2 for ; Mon, 11 Sep 2017 18:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/JtSunr93w0A10brhNpxsUkKt1NFdxIH5w7O0+6gSXA=; b=C72g3JfcBDvL3dot946056f6oboPy6VFYWC0rIUWvnWHQy4I46l7CqTmszj4I9rUDC +PTWM25n3a0TMXG20Wnq/aVS7K8T104yEj+fvL8Mz8scoWaK8k298dzvAXn5GBo/l/97 wdNgVFYznVJP+KsvPboxucl+5W+XrxpTA4XzFaw0ljnHre6hIMHy8H4Hj8z0rgo8xOxQ Ox/Cd6G+K/LZAB1INCim8l2knp3BMBSjDKEXFpiB+TNJ2s+XeQ/kduhm0pWfFWC5lek+ MbvdVCjCoKDVc2TN1WVbhA4JXLbe9xZlkGBYnZ28/cJbN1i5bm+4klW68e5dhQn9E4iH NpEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/JtSunr93w0A10brhNpxsUkKt1NFdxIH5w7O0+6gSXA=; b=BR85kXQp6xWKe8PLBpAcnl+LRQXABUNwd1McDUl6weEj5Jdfm3WQ1qw/r4jwj80wIz FxxChl+LUSeAEJ4RHfQ28K8KyawIabqjLCX2axoWTWaQzw0OGbr0ImJGB/TV1mSOaQ/6 loVuUFAFtMA3MbtJ8dXcb/w+uimcuFDlbWXQy84rEF9lrpXsxpZxBd5YH7dQ7/VK3W4s hsKlT9bpCME4wtM1cPKoC95w3q1Ay/Ln9qMDSycURZrMy9/Hql0xUouLMiFezpu8T1cj 1tOOkdc5ixmlUS2yFOBEvd+iDDFmM42wxTv8iyWbc29oMrLQn3+tCGDJ1sQCaSDU15mk HRgw== X-Gm-Message-State: AHPjjUg/TnUtrZgMGPRu/QB+cQZ05V9B6qSs516jXpedIAchcI9kuLZV 5zZcgkPS0OP1g5qy X-Google-Smtp-Source: ADKCNb6+daKmusm7c2Bh71G4Gs2cdCsBe8qBEFu1hNUooVMCpPaA4PdWJoA5797VnjrNQBoPbIAJ1g== X-Received: by 10.98.138.17 with SMTP id y17mr6096759pfd.149.1505180492922; Mon, 11 Sep 2017 18:41:32 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j83sm17536503pfe.133.2017.09.11.18.41.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 18:41:32 -0700 (PDT) References: <150517994829.4728.308177286707996361@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <150517994829.4728.308177286707996361@ietfa.amsl.com> Message-ID: <86ef1c42-af4b-e1dd-52e7-a3586490ebff@gmail.com> Date: Tue, 12 Sep 2017 13:41:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150517994829.4728.308177286707996361@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-anima-grasp-bulk-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 01:41:36 -0000 Comments welcomed! -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt Date: Mon, 11 Sep 2017 18:32:28 -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 : Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP) Authors : Brian Carpenter Sheng Jiang Bing Liu Filename : draft-carpenter-anima-grasp-bulk-00.txt Pages : 10 Date : 2017-09-11 Abstract: This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-grasp-bulk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-00 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-grasp-bulk-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 Sep 11 20:17:39 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544DB1321A6 for ; Mon, 11 Sep 2017 20:17:38 -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 UQYZn3ZOk4Ae for ; Mon, 11 Sep 2017 20:17:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 0AD12132964 for ; Mon, 11 Sep 2017 20:17:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E254A5E0085; Mon, 11 Sep 2017 20:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1505186256; bh=+nBWHtnk+/UaBkdPxAPGd5agvkY/T4n8r3Fgj3rWSNc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KaLYweljtbepOSFxMDhIDEqpERAfWRPf34omkHgSDzB8DSzIkQqFK80pj8lDJWzAQ vnk+XhMFOB84iNfGlsOh79B8264bMt+SQXUZ3pU1IftMEKiKmtmk2+tUnUGjlPMBDQ z63se6oYkaHxRumYi4VhrF2zNE3GeMZnj4Cc27Dc= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6A6615E0082; Mon, 11 Sep 2017 20:17:36 -0700 (PDT) To: Brian E Carpenter , Anima WG References: <150517994829.4728.308177286707996361@ietfa.amsl.com> <86ef1c42-af4b-e1dd-52e7-a3586490ebff@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Mon, 11 Sep 2017 23:17:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <86ef1c42-af4b-e1dd-52e7-a3586490ebff@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 03:17:38 -0000 Given our experience with file transfers, several things seem to be called for: 1) There should be a mechanism for the sender to initiate. Several of the use cases you cite are such that the sender would better than the receiver when it is a good time to send the data. 2) I realize that it does not fit the pattern, but without some sort of position indication, this seems very fragile. I think you need to come up with a way to indicate the position. 3) Unless we want to restrict this to very local environments, we really should have a way to resume a failed transfer at the failure point, rather than start from teh beginning. In particular, without these features, the justification for using GRASP rather than a better transfer protocol over the ANIMA infrastructure becomes very weak. Yours, Joel On 9/11/17 9:41 PM, Brian E Carpenter wrote: > Comments welcomed! > > -------- Forwarded Message -------- > Subject: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt > Date: Mon, 11 Sep 2017 18:32:28 -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 : Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP) > Authors : Brian Carpenter > Sheng Jiang > Bing Liu > Filename : draft-carpenter-anima-grasp-bulk-00.txt > Pages : 10 > Date : 2017-09-11 > > Abstract: > This document describes how bulk data may be transferred between > Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol > (GRASP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-grasp-bulk/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-00 > https://datatracker.ietf.org/doc/html/draft-carpenter-anima-grasp-bulk-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 > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Sep 11 21:56:22 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1467813208E for ; Mon, 11 Sep 2017 21:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoIHrD7T6pTN for ; Mon, 11 Sep 2017 21:56:19 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 7A5DE132195 for ; Mon, 11 Sep 2017 21:56:18 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 6so20187879itl.1 for ; Mon, 11 Sep 2017 21:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=F3K1CFxZhSiDRNN0P+kEUctriEn2lKeyo5uD3SLqiiM=; b=BRvD36x/kFEbQru/g3YI6qZh8J3eDgCQmBHHwNI+k/7GWW+La72GCjiDbbozRR3V7S mPEbZZwiqBOVdOV6enKovZaOP+hGtIEPVpnP1PwKDJlUVmB++D5J3gLAAzfHTlPly3zS r3Om1e/bVcOMTeFgzd4jEvi21UPp2ELwnoneKV7+lfeX6e1hJr2lJREbkxqxYSoN220A 8SECxICZ3RqNtr1rxRL38uVATJOTtLBuZuRgg4nPX5U7X++v0svTxT4uCmBNulKJ2IKn 0fCb6VBGuNy32SwoVN+rTJsP1sVJdB+1GdLX3cWANXX4BGLCD1BYEfIeZ10dgAOHpbo3 reNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=F3K1CFxZhSiDRNN0P+kEUctriEn2lKeyo5uD3SLqiiM=; b=sbhNSKJddEoG3QT7t9ep+QmFaML4+tnGeZPlIgANiK3gw917Tx+mRFpy3nOxSJNF/z i+36x92vi08MJVxecx1/prw4OhlWQnEc80SBa39A9mQo2tt9oiL8+UtIvSxp3jFv4/f6 jHZpDCbIZdYAsNYkDN3uHepJeOdYSuvOoZQjrHTPQnu5dZLAtt2OFds3JiE0wI32GHzm mLQptuSgT0dSP/ACg5fwlcb16mLht2H5cqv4aqoIqE0bSQihR9ycuxdfQnanm0Mhn6oB xQpBnV8JLCvnXT2Gt0e+m4tkiL55m68W5+DQI6uDr5igaPUGfw/31OqRUKIrf0Yzh8oa 62rA== X-Gm-Message-State: AHPjjUi1cFx7SosVsIbSu7rGzsyyGPq+LKSHK+XDhEgPEARrm121d5hA sHP+m750sxrPVsIOUQlvKh2V3Q== X-Google-Smtp-Source: ADKCNb7PagRDWT2EW78I4shB1zHxy5mUxEdtR/VSmuYTaP/y6o/kehVsIlc/byaNpvL4nEa5QRg6fQ== X-Received: by 10.36.185.88 with SMTP id k24mr16474746iti.71.1505192177435; Mon, 11 Sep 2017 21:56:17 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o71sm5899546itb.15.2017.09.11.21.56.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 21:56:16 -0700 (PDT) To: "Joel M. Halpern" , Anima WG References: <150517994829.4728.308177286707996361@ietfa.amsl.com> <86ef1c42-af4b-e1dd-52e7-a3586490ebff@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <174cd4ab-eb2c-08ea-2573-57635303b167@gmail.com> Date: Tue, 12 Sep 2017 16:56:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 04:56:21 -0000 Hi Joel, thanks for the rapid comments. More in-line: On 12/09/2017 15:17, Joel M. Halpern wrote: > Given our experience with file transfers, several things seem to be > called for: > > 1) There should be a mechanism for the sender to initiate. Several of > the use cases you cite are such that the sender would better than the > receiver when it is a good time to send the data. Yes, certainly. That's behind the mention that the mechanism could be turned round for upload. Maybe it would be better to call it push and pull, since ANIMA does not assume a hierarchy. > 2) I realize that it does not fit the pattern, but without some sort of > position indication, this seems very fragile. I think you need to come > up with a way to indicate the position. It wouldn't be hard to add a block number, both for the sending side and the acknowledgements. But then it would be very tempting to also add a retransmission mechanism, and look, we've re-invented the wheel. So we just have to decide where to stop in complexity. > 3) Unless we want to restrict this to very local environments, we really > should have a way to resume a failed transfer at the failure point, > rather than start from teh beginning. Ditto. To be honest I had to stop myself adding such mechanisms, when writing a quick prototype. > In particular, without these features, the justification for using GRASP > rather than a better transfer protocol over the ANIMA infrastructure > becomes very weak. Well, there we might disagree. Or at least, that is the question of scope. What do we want to assume is already installed on an autonomic node? If it's a fully-featured host or host-like device, I would expect some existing mechanism to be available. If it's a bare-bones device, maybe not. But in that case, we'd want a GRASP-based mechanism to be bare-bones too*. We'd be interested in WG opinions about this. *Just to scale it, the client side that corresponds to the example in the draft is about 110 lines of Python. Thanks Brian > > Yours, > Joel > > On 9/11/17 9:41 PM, Brian E Carpenter wrote: >> Comments welcomed! >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt >> Date: Mon, 11 Sep 2017 18:32:28 -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 : Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP) >> Authors : Brian Carpenter >> Sheng Jiang >> Bing Liu >> Filename : draft-carpenter-anima-grasp-bulk-00.txt >> Pages : 10 >> Date : 2017-09-11 >> >> Abstract: >> This document describes how bulk data may be transferred between >> Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol >> (GRASP). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-anima-grasp-bulk/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-00 >> https://datatracker.ietf.org/doc/html/draft-carpenter-anima-grasp-bulk-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 >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > From nobody Tue Sep 12 07:10:16 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1CB1326DF for ; Tue, 12 Sep 2017 07:10:14 -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 FbAbJJxM8_oj for ; Tue, 12 Sep 2017 07:10:13 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D555132D43 for ; Tue, 12 Sep 2017 07:10:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E63142E04D2; Tue, 12 Sep 2017 07:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1505225411; bh=Sg0yPeccXQWsFFcNk2unaEQKu+MlE2p6jobD/wb6Ig4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OmH0/CJkNZPxtXFJk445OGrGU455+pkVRiRSoN8OwpJxindsG69PdusyshTlo9nGb HS372mDLxzFrXmE9mAWCPNsd7Xez7KBYJPtTHHRdypO0f/5shDgXeHE3yFCUOxncZ+ kSsDnG3Djysp8vwvmRWampmAbt513L9Yq1tIqWyc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 57509244DFE; Tue, 12 Sep 2017 07:10:11 -0700 (PDT) To: Brian E Carpenter , Anima WG References: <150517994829.4728.308177286707996361@ietfa.amsl.com> <86ef1c42-af4b-e1dd-52e7-a3586490ebff@gmail.com> <174cd4ab-eb2c-08ea-2573-57635303b167@gmail.com> From: "Joel M. Halpern" Message-ID: <042a863a-b7c9-d6fd-12bc-80ba3d003267@joelhalpern.com> Date: Tue, 12 Sep 2017 10:10:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <174cd4ab-eb2c-08ea-2573-57635303b167@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:10:15 -0000 Even if you want a simple mechanism, I think the bidirectionality and block numbers would be VERY good ideas. I think these two are critical. Without either resumption or retransmission, there seem to be many environments where low complexity is valuable but the system is unlikely to be able to perform the transfers. This does edge into the argument about how much size and work it would be to just use the code for an existing protocol. Yours, Joel On 9/12/17 12:56 AM, Brian E Carpenter wrote: > Hi Joel, thanks for the rapid comments. More in-line: > > On 12/09/2017 15:17, Joel M. Halpern wrote: >> Given our experience with file transfers, several things seem to be >> called for: >> >> 1) There should be a mechanism for the sender to initiate. Several of >> the use cases you cite are such that the sender would better than the >> receiver when it is a good time to send the data. > > Yes, certainly. That's behind the mention that the mechanism could > be turned round for upload. Maybe it would be better to call it > push and pull, since ANIMA does not assume a hierarchy. > >> 2) I realize that it does not fit the pattern, but without some sort of >> position indication, this seems very fragile. I think you need to come >> up with a way to indicate the position. > > It wouldn't be hard to add a block number, both for the sending side > and the acknowledgements. But then it would be very tempting to also add > a retransmission mechanism, and look, we've re-invented the wheel. So > we just have to decide where to stop in complexity. > >> 3) Unless we want to restrict this to very local environments, we really >> should have a way to resume a failed transfer at the failure point, >> rather than start from teh beginning. > > Ditto. To be honest I had to stop myself adding such mechanisms, when writing > a quick prototype. > > In particular, without these features, the justification for using GRASP >> rather than a better transfer protocol over the ANIMA infrastructure >> becomes very weak. > > Well, there we might disagree. Or at least, that is the question of scope. > What do we want to assume is already installed on an autonomic node? If it's > a fully-featured host or host-like device, I would expect some existing > mechanism to be available. If it's a bare-bones device, maybe not. But in that > case, we'd want a GRASP-based mechanism to be bare-bones too*. We'd be interested > in WG opinions about this. > > *Just to scale it, the client side that corresponds to the example > in the draft is about 110 lines of Python. > > Thanks > Brian > >> >> Yours, >> Joel >> >> On 9/11/17 9:41 PM, Brian E Carpenter wrote: >>> Comments welcomed! >>> >>> -------- Forwarded Message -------- >>> Subject: I-D Action: draft-carpenter-anima-grasp-bulk-00.txt >>> Date: Mon, 11 Sep 2017 18:32:28 -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 : Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP) >>> Authors : Brian Carpenter >>> Sheng Jiang >>> Bing Liu >>> Filename : draft-carpenter-anima-grasp-bulk-00.txt >>> Pages : 10 >>> Date : 2017-09-11 >>> >>> Abstract: >>> This document describes how bulk data may be transferred between >>> Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol >>> (GRASP). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-carpenter-anima-grasp-bulk/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-00 >>> https://datatracker.ietf.org/doc/html/draft-carpenter-anima-grasp-bulk-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 >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> > From nobody Tue Sep 12 07:33:55 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B15132716 for ; Tue, 12 Sep 2017 07:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpmaffjv_v9h for ; Tue, 12 Sep 2017 07:33:52 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36209132332 for ; Tue, 12 Sep 2017 07:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1505226832; x=1506436432; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=8b4w2Elk7zm8+jF6QX+95Y8om9LH2AA9zHH9CGl+l9A=; b=i4CA+rfyeNuDFM+t5oAbbgrDa1ghL2XfIHy4KyvptAGbhon+O5/RsI5c 2MPeX1/8rIQldJnBmn8Z7pMy4zrSdoud6mH+xH/iH0LxiCl+Jo/2pUrs8 SyYG1EKHqd5SLPqMSNqW8e9Tr70zc6Q7FdtIjO5t9Bz6eG3B4mqRWOXxA I=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="asc'?scan'208";a="654563079" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 14:33:50 +0000 Received: from [10.61.216.42] ([10.61.216.42]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8CEXo7Q023381; Tue, 12 Sep 2017 14:33:50 GMT To: "Max Pritikin (pritikin)" , Michael Richardson Cc: anima References: <961.1504038708@obiwan.sandelman.ca> From: Eliot Lear Message-ID: <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> Date: Tue, 12 Sep 2017 16:33:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DBFdTGwoVbGoQ2SVIGuQV6D2gst4Xv0qT" Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:33:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DBFdTGwoVbGoQ2SVIGuQV6D2gst4Xv0qT Content-Type: multipart/mixed; boundary="xmFkp889x3x4oK9DVWewqwR3IB0a3coTv"; protected-headers="v1" From: Eliot Lear To: "Max Pritikin (pritikin)" , Michael Richardson Cc: anima Message-ID: <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> Subject: Re: [Anima] two EST question/suggestions References: <961.1504038708@obiwan.sandelman.ca> In-Reply-To: --xmFkp889x3x4oK9DVWewqwR3IB0a3coTv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, > I agree a statement that HTTP2 etc is ok so long as it doesn=E2=80=99t = change the possible client state machine=E2=80=A6 ? You need an MTI, and it should be the easiest and most compact thing to implement.=C2=A0 While CoAP would be optimal, HTTP/1.1 is more than sufficient, and the features in 2 in this case are not only unnecessary, but undesirable overhead. Eliot --xmFkp889x3x4oK9DVWewqwR3IB0a3coTv-- --DBFdTGwoVbGoQ2SVIGuQV6D2gst4Xv0qT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZt/BQAAoJEIe2a0bZ0nozyqIIANTThbTyeEwhoroznFZBdlcQ kCRnddFl38FUkgbx50ktiGLTwkiDUWMBBqAw1hofBpyxqCmn0AdmTbNrtEXDyDyx vKthocr37Q4xpWyPqfXBxUYfWYiRJ4LEgfxAo713173C2qrntL7YXloTbQTL/sfx ZP3XTRlzt9sB2jaH5OoTHShuGS04wc8/oqB9QzFvfPD5n7befo7K4k0kc5iWY/Q2 4glizP4Qd9vSiPqZGhXQhAvIgddKMM8OUGLHsddLGsQOvsg+tQMm9aQO1/bbzo+F SgHQG9P7/v4x0R38Yv3Q60UPFac9LOP066TM67Ijq4YgsJY2Ys9ldqYw4ujHkeY= =f7zz -----END PGP SIGNATURE----- --DBFdTGwoVbGoQ2SVIGuQV6D2gst4Xv0qT-- From nobody Tue Sep 12 13:03:49 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBC81330C8 for ; Tue, 12 Sep 2017 13:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fwnuBYopDNm for ; Tue, 12 Sep 2017 13:03:47 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B581330C7 for ; Tue, 12 Sep 2017 13:03:47 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id e199so20222744pfh.3 for ; Tue, 12 Sep 2017 13:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qBx7vYnvQXqEL0EI1Uj0Pa4kiIpfU63Ikh8sHC5afvc=; b=a0iPPhkxnTl1dEjFuW4pzQHyP8h24/L9oO3lDFBuy87sson0WdQ7UnRbSJ4Spwy2+U bdv99+o8rUT5++/rYFQi4BQSr38QQtvLFCfRsr7jVJrIk5U8GYKcIOgmdomq/ceQ+x1c iIG9rsN1cjv1bH1oRkDQa/g/xHjlAWzU0sBbacCvnIZDZChvstNVIkKWIc0o+SZp9Wkb m75ffQwDdWEZhFXEu5u9VNzaWIbsW0EZHs7sTEYwh5AmJh95N3C601v4/hzZFrOUsLRF y17ZIIBnQV8PnzyvEGJoXlag55B51134i7oPBq3FReN/DKNNIM03TfTEa/Gv6fKx3mKS +7CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qBx7vYnvQXqEL0EI1Uj0Pa4kiIpfU63Ikh8sHC5afvc=; b=YxDuCVw4Co3yfy6+gbllscH7n3aFxG3WgBBLudv5ENCOIQIC281wkfmUEjxyrlM6bV 2NteG23v5F3NCHC95diaY0J3w5A914p6nV60NJGaijZ9wjWTZvvx2sgAmi28PgAtrAMT SCwYNnGtZIRkO7HCOGrUE4Hx7Tc2ZfWq0VVQ9A/kLcolUhxUaDzxr2e4VTdd8thnHDiE B6l4HC/Nz/T0/CeSKX+dhE6d4IyGCWkp2e6IMqxcMhrZfzNUWzOof+Dd+umjmJOOddS3 jnMn/C5smRGCzDOrthTfhQLzRZjURB1dVbolc3OYIa+h32ChULPI1qxLXNAEgrMOcEBm 5TOw== X-Gm-Message-State: AHPjjUhPsjOThR0opWZdojsaxSu9ebKkq/Bo4E/cMFWKDk1LD5bF3ZVQ p+hQeacEvYtXd4r7 X-Google-Smtp-Source: AOwi7QBFYyYJILmhCCmFdcpJwivMAB0oDoyLuP942X7h3P+lVUQkl5mt7eQviBsiZPP+99BDTS3KDw== X-Received: by 10.84.194.1 with SMTP id g1mr3663338pld.74.1505246626579; Tue, 12 Sep 2017 13:03:46 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i87sm13552706pfi.184.2017.09.12.13.03.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 13:03:45 -0700 (PDT) To: anima@ietf.org References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> Date: Wed, 13 Sep 2017 08:03:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 20:03:48 -0000 On 13/09/2017 02:33, Eliot Lear wrote: > Hi, >=20 >> I agree a statement that HTTP2 etc is ok so long as it doesn=E2=80=99t= change the possible client state machine=E2=80=A6 ? >=20 > You need an MTI, and it should be the easiest and most compact thing to= > implement.=C2=A0 While CoAP would be optimal, HTTP/1.1 is more than > sufficient, and the features in 2 in this case are not only unnecessary= , > but undesirable overhead. I am a bit bothered by the assumption that all devices of interest can be= assumed to include X, for whatever value of X we deem to be MTI. Or are you only intending MTI to apply at the server end? It seems to me that we want to minimise the requirements for low end pled= ge devices, and every item that we make mandatory works against that. Brian From nobody Tue Sep 12 13:42:06 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED21B1330DE for ; Tue, 12 Sep 2017 13:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htmIOdI2o3C7 for ; Tue, 12 Sep 2017 13:42:03 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555F513239C for ; Tue, 12 Sep 2017 13:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2795; q=dns/txt; s=iport; t=1505248923; x=1506458523; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=tRXJQ45s462aQdsJN3WgKSUZtsqTXoUYJZXbWGjuGU8=; b=mykXv8v+5VltQT9hS4ggJX9arPAWVa0oYAb64PprGhzt7bZadANHnBFj HsBs+CzQAVs9ysDsZGos9OWM7wIctOanxAXSFDecA34UEO591SfccQx54 002OdWLLaW7b1pRMB7w4l4r0pCSI4E5cMI4jkqPrf17aVS0p0AWRMh6fu I=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEBgCURbhZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhB6LFZB6K5g6BwOFPgKFBhUBAgEBAQEBAQFrKIUYAQEBAwE?= =?us-ascii?q?jZgsYKgICVwYBDAgBAYolCKxUgieLNAEBAQEBAQEDAQEBAQEBARIPgyuFYIJ9h?= =?us-ascii?q?GGDKYJhAQSgdIQ5giGNeItVhx2VL4E5NSKBDTIhCBwVh2c+ijwBAQE?= X-IronPort-AV: E=Sophos;i="5.42,384,1500940800"; d="asc'?scan'208";a="654570147" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 20:42:01 +0000 Received: from [10.61.216.42] ([10.61.216.42]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8CKg02J020243; Tue, 12 Sep 2017 20:42:01 GMT To: Brian E Carpenter , anima@ietf.org References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> From: Eliot Lear Message-ID: Date: Tue, 12 Sep 2017 22:42:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6aSmFnPPLUH9RwFvK2bN1UVFUhKFo0UHf" Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 20:42:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6aSmFnPPLUH9RwFvK2bN1UVFUhKFo0UHf Content-Type: multipart/mixed; boundary="MGpTIB1fM6LaHskaHPSjLwD87KnqgGmm3"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , anima@ietf.org Message-ID: Subject: Re: [Anima] two EST question/suggestions References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> In-Reply-To: <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> --MGpTIB1fM6LaHskaHPSjLwD87KnqgGmm3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 9/12/17 10:03 PM, Brian E Carpenter wrote: > On 13/09/2017 02:33, Eliot Lear wrote: >> Hi, >> >>> I agree a statement that HTTP2 etc is ok so long as it doesn=E2=80=99= t change the possible client state machine=E2=80=A6 ? >> You need an MTI, and it should be the easiest and most compact thing t= o >> implement.=C2=A0 While CoAP would be optimal, HTTP/1.1 is more than >> sufficient, and the features in 2 in this case are not only unnecessar= y, >> but undesirable overhead. > I am a bit bothered by the assumption that all devices of interest can = be assumed > to include X, for whatever value of X we deem to be MTI. Or are you onl= y > intending MTI to apply at the server end? Hmm.=C2=A0 Actually, I don't like my own text precisely for the reason yo= u state.=C2=A0 But I do think we don't want to create a plethora of choices= =2E=C2=A0 There is an interoperability issue here that has to be addressed. > > It seems to me that we want to minimise the requirements for low end pl= edge > devices, and every item that we make mandatory works against that. > > =20 Right, but we need to have something there. Eliot --MGpTIB1fM6LaHskaHPSjLwD87KnqgGmm3-- --6aSmFnPPLUH9RwFvK2bN1UVFUhKFo0UHf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZuEabAAoJEIe2a0bZ0noznMEH/j6icSNBJRCRKyFPVmmA591z dAS4Yq6kq7TyV72H8pBLDSiLgCtYtDJyD1/DokakMeUp1/O8UFskZ56J1r/um+X5 hoSXKrWKyiBqcioH42YV/l4vLD2UM/0c37V2fKEwfrJ1OBMdpEycLx9Ic8+pQV3p lZ10tiiD8Qar6T5z6IU2mUulbC3rIV9w8p5PIWiZ+ewynF1L4NVJFfBcinGXEyz0 Wahp2rXqoURySipL8hvY7NxVOadfPLPzbXU80AXS+46o8VB4DkDnYIvvIaDsnQal ++XfQLIBePd2yLDPDxKXnoOTjYF9IVe0e8OiUp39sVrO+BY8xZ7YncF6S6a8T0A= =/G7x -----END PGP SIGNATURE----- --6aSmFnPPLUH9RwFvK2bN1UVFUhKFo0UHf-- From nobody Tue Sep 12 13:51:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756661330DE for ; Tue, 12 Sep 2017 13:51:37 -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 4Li-GhApl0dN for ; Tue, 12 Sep 2017 13:51:36 -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 2275E13239C for ; Tue, 12 Sep 2017 13:51:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E999D2009E; Tue, 12 Sep 2017 16:55:46 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5487280CFA; Tue, 12 Sep 2017 16:51:35 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 20:51:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> You need an MTI, and it should be the easiest and most compact thing= to >> implement.=C2=A0 While CoAP would be optimal, HTTP/1.1 is more than >> sufficient, and the features in 2 in this case are not only unnecess= ary, >> but undesirable overhead. > I am a bit bothered by the assumption that all devices of interest ca= n be assumed > to include X, for whatever value of X we deem to be MTI. Or are you o= nly > intending MTI to apply at the server end? We are running over HTTP 1.1, we have to assume that. The issue is that both client and server libraries will grow HTTP 2, and we need to know if this is a problem. > It seems to me that we want to minimise the requirements for low end = pledge > devices, and every item that we make mandatory works against that. BRSKI does not target constrained devices; in the future having only an HT= TP 2 library (because the application is using that) might be simplest. Is it going to work okay? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlm4SNcACgkQgItw+93Q 3WWv7QgAso+SZKeSVso2EJmgAlW19itl7H1E+zOOZdZQiaRq2bkdBUgPk2hrcW8W b98Q2WMuVoUOe6uzl6/2sBM6jDYimEFwbFIlAWgR8dqzmSsMJ7gyUNtryY5DDrp8 l6V8vPEHWsjvV9FafHoBjsWN3+4PSKt+i7Tl5iQSENgp51BKzbIkZwJmH/7GlFHW nrdYBFzF8aBM8hXf9YtT7zHAWOPRHKT9eAPNTUcnuqbI2MvFO+eihqErvPYwsyqt A7IehKwHhrlRBiilh1ayUIhOCFwhv+ZUsMAKru3SP7gDq+5e75Zp7tedjFwMvL5d z+vul6xw5t8nNCyf7+0rkwZE4HXrIA== =yj82 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 12 15:25:19 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042E7133164 for ; Tue, 12 Sep 2017 15:25:18 -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 nK9_PJ3bArG2 for ; Tue, 12 Sep 2017 15:25:16 -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 77E8112421A for ; Tue, 12 Sep 2017 15:25:16 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id e1so20725627pfk.1 for ; Tue, 12 Sep 2017 15:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=m7hao7ZgWCsOEa4XghbrJb05t2/5CHFzl+kUOJkO+CE=; b=Po50M/al7ZkWU6MAqubB5axd8d13qIwPkgHQRrOf7L/w0Nz5GA2g9wfW11fzpdqBhm rfcE7kH7vT+ovI18olfOWiUU9UM4yN16ew0WPUYsgW+YCU+EAQAxbqDCXsXEmfhpXl4n beQCNOud8+C6ZC90Qs9n31v9fvjEOgRafv0pIqtxV7JlNNCumT+Z255f6bKMOaiBoElg cv/3Y9a1Spgy9aUUz1NV+Js3avxD2pTTMK9ocgdDKs3mefmPlJfOsPcYjBbZWTU9PmQe IDUQbzRyx8/cbIdJ5sXf/3akVp3rrOjJUP0Bm8xi8Qo1vMtyZjpmI9+JcUntA2OS7nr6 QesQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=m7hao7ZgWCsOEa4XghbrJb05t2/5CHFzl+kUOJkO+CE=; b=sSgn8Zo3T8T34iA1xEx3b6Sd5rP3UnJbERsOnzWvmxgOhJ9Fn3mh3OfglCxP6cWOse RbES/5ws0rRlHUpvxSP0gtppfMb79kskni5M3l1sbRO9gMja2GULeyvgmoQlCcmWgk9x ISbUz24GLN6zajjOIsu0b8su5hgoAD3qxlTkmr0x/LsQ21OqE/npAFBkexzzYvNIHjCj MXnMztRvogwu8TlWsog/lnQtD7Bfh32TRNqtJnCSkuHIzFjhqca9zZe9fylKvWhe+mWf 410NSMpvppXeOKAGzYBdUlLBhWFBrVZTKvvMZ24AhgIsqZmYcreDhx9mxuyMn1+7BkPZ Gsmw== X-Gm-Message-State: AHPjjUioZCsoonVgF0SIMQlskRm0MJSGP5TXmCgLp/u1+R0q7XnVoFEq JyT7rF4whQXKS/cj X-Google-Smtp-Source: ADKCNb5BGDfT9V7zh1OPcG1gYlpM9XSHoWptLSWqfYe0yULb/MKUIo+3N0WbyxrJZKTID7YiLGnO8A== X-Received: by 10.84.244.6 with SMTP id g6mr18780325pll.223.1505255115624; Tue, 12 Sep 2017 15:25:15 -0700 (PDT) Received: from [130.216.38.13] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.13]) by smtp.gmail.com with ESMTPSA id t81sm22235002pfg.154.2017.09.12.15.25.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 15:25:14 -0700 (PDT) To: Michael Richardson Cc: anima@ietf.org References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> <27231.1505249495@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 13 Sep 2017 10:25:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <27231.1505249495@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 22:25:18 -0000 On 13/09/2017 08:51, Michael Richardson wrote: >=20 > Brian E Carpenter wrote: > >> You need an MTI, and it should be the easiest and most compact t= hing to > >> implement.=C2=A0 While CoAP would be optimal, HTTP/1.1 is more t= han > >> sufficient, and the features in 2 in this case are not only unne= cessary, > >> but undesirable overhead. >=20 > > I am a bit bothered by the assumption that all devices of interes= t can be assumed > > to include X, for whatever value of X we deem to be MTI. Or are y= ou only > > intending MTI to apply at the server end? >=20 > We are running over HTTP 1.1, we have to assume that. > The issue is that both client and server libraries will grow HTTP 2, an= d we > need to know if this is a problem. >=20 > > It seems to me that we want to minimise the requirements for low = end pledge > > devices, and every item that we make mandatory works against that= =2E >=20 > BRSKI does not target constrained devices; in the future having only a= n HTTP > 2 library (because the application is using that) might be simplest. I= s it > going to work okay? I don't see why not. But isn't there potentially a class of devices that while not being 'constrained' in the formal sense, nevertheless needs to minimise its software footprint? So the implementer will want to choose the solution with the smallest footprint, rather than whatever MTI we happen to define in 2017. Of course we can always change the MTI later, but if we say right now tha= t the MTI only applies to the server side, adding new solutions for future types of pledge becomes more straightforward. As far as I can see, this would have zero impact on first-generation implementations; initially both servers and clients will support the MTI anyway. Brian From nobody Tue Sep 12 16:57:49 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6562D13318A for ; Tue, 12 Sep 2017 16:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7gcFb0Jduvy for ; Tue, 12 Sep 2017 16:57:45 -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 CBEB71320C9 for ; Tue, 12 Sep 2017 16:57:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7F9F02009E; Tue, 12 Sep 2017 20:01:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7741C806AE; Tue, 12 Sep 2017 19:57:43 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> <27231.1505249495@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 23:57:47 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> We are running over HTTP 1.1, we have to assume that. >> The issue is that both client and server libraries will grow HTTP 2, and we >> need to know if this is a problem. >> >> > It seems to me that we want to minimise the requirements for low end pledge >> > devices, and every item that we make mandatory works against that. >> >> BRSKI does not target constrained devices; in the future having only an HTTP >> 2 library (because the application is using that) might be simplest. Is it >> going to work okay? > I don't see why not. But isn't there potentially a class of devices that > while not being 'constrained' in the formal sense, nevertheless needs to > minimise its software footprint? So the implementer will want to choose > the solution with the smallest footprint, rather than whatever MTI we > happen to define in 2017. Yes, I agree with you. That's why I would like us to permit pledges to support a single client HTTP library. They will use whatever HTTP client library that they need for their primary application... so if it's a webrtc nanny camera, then it might well be HTTP2 + QUIC. The problem with HTTP2 is that it permits requests and responses to be interleaved and not-sequential in the TCP sense. This potentially has a poor interaction with the BRSKI state machine. We ought to say something about this *today*. > Of course we can always change the MTI later, but if we say right now that > the MTI only applies to the server side, adding new solutions for future > types of pledge becomes more straightforward. As far as I can see, this > would have zero impact on first-generation implementations; initially > both servers and clients will support the MTI anyway. My take is that the server has to support every single MTI that we have every supported. That's okay. But, HTTP 1.1 with persistent connections is the minimum (not the maximum). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlm4dHcACgkQgItw+93Q 3WVsPAf+PaCNBJcTTnHD5D2xcSwcWrMWhheizMpHLnTtmDZu5nzL9OO0LEzoAY3e q8ApaW9ZdOhPR+NQm1/rNcyNqOt9U+UBXi5Ub7KKYWb1L6N7Bzp66vaA3EKH9Qmh WrKZ1NXBtiXbaIIw+DdZrKaqzd9qAD4Z1P5vijc73iLFsEHjL9maQSfH9ZpIbgI1 lOpH1aela2sGGgBKWXtLSCDKwEeVTuMsOVnGCMCUuhVsdvd1k0m1jojjZW80+RB7 pcGnX16isVvUEqCDw5wpt7dGwCFBDywp9WKOI/B3osnf74JXCQFqY0Y8cNNXBVgx Dg++J0oecdyDFf8l0P41wbT7tcYg2g== =BUwT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 13 13:13:36 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1A133033 for ; Wed, 13 Sep 2017 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCbJunVi8tCf for ; Wed, 13 Sep 2017 13:13:32 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90210132D45 for ; Wed, 13 Sep 2017 13:13:32 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id y29so1869017pff.0 for ; Wed, 13 Sep 2017 13:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=t3TIT3G4Q+LFWnegiNPIuZxq8ru5wwqpHKgDXmE0zOo=; b=aJdRtbLtTPxibqNVuNSD7srTcBXwJpjTwAZmp1jCqPAkvs1XAkP3QllymBf89C+iEE 6H0+TBnde7TC9dp3hc/Rcc6CDMHxkyApBMCFXQJLrD/5Aml2yUBM0SBoreOlFWkZJpcq b2hVJ5WqO0At9SkU3EqchZG3N0w8VQYUBkR9IT99QpPruGHbHChwuQAgejRAeK3Qu8b/ P0cMYdwt4XRbNHY/TyWCe0zURmqpBHur8NecZ67JMuPWT56WI2AipKyb/15sYYwuFl56 97+kcDC8pQm4lDDp4ny2g+ml8peYtN3qzCq7xu8YFcKsNGemM9giNvuid8W9tRZvtA59 lKyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=t3TIT3G4Q+LFWnegiNPIuZxq8ru5wwqpHKgDXmE0zOo=; b=CdwKP/b9SANA5stMfa/ENwV2LkjBxSzGiYac3FdOpkFtg6/twbL+40QmjjuKxdEehg MJgFFvKF0ERcOfQZDFEVHSpNVbz6nA73U3TgdaYBeLegDIE2+QXUJeyuH6/YlAoduuB2 bKtr1yYdbZ/HTIpsfnwXfFkrjwUUEkYPAAC1nNx/saADze7joqwRUctR87RNSK1mpdrq Rpk3XktuooepaaCtP6QikX5GdCelBiiw/mBUll5PVna9Tz2Bg1xWiDDy8omv2gr1ekBY DzPYiRXQ3Oy1mOGSF/t+Z+usZdBCJ2hf3MJOgRM+Ebyj/8BQ4RLmtHJxPB4LCbDbzoF1 Cm9Q== X-Gm-Message-State: AHPjjUhp/Mw6Lt1Kp8gl7JGYt9DtrViRLwwaG9LdWiIE29VVkX6/vbYB Lw+tjrTWM3ThR7j8 X-Google-Smtp-Source: AOwi7QDoyKp4EnvS0wa9qyeDtYjRmkh9/NC1uJIis80Tf9bKmBGuq56H6P/6/8bsz11VC+IiXSRmQA== X-Received: by 10.98.242.16 with SMTP id m16mr1422844pfh.72.1505333611749; Wed, 13 Sep 2017 13:13:31 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x4sm25470435pfb.101.2017.09.13.13.13.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 13:13:30 -0700 (PDT) To: Michael Richardson Cc: anima@ietf.org References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> <27231.1505249495@obiwan.sandelman.ca> <6079.1505260663@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5c00237e-98fa-9764-d816-919307bdd994@gmail.com> Date: Thu, 14 Sep 2017 08:13:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6079.1505260663@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 20:13:35 -0000 On 13/09/2017 11:57, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> We are running over HTTP 1.1, we have to assume that. > >> The issue is that both client and server libraries will grow HTTP 2, and we > >> need to know if this is a problem. > >> > >> > It seems to me that we want to minimise the requirements for low end pledge > >> > devices, and every item that we make mandatory works against that. > >> > >> BRSKI does not target constrained devices; in the future having only an HTTP > >> 2 library (because the application is using that) might be simplest. Is it > >> going to work okay? > > > I don't see why not. But isn't there potentially a class of devices that > > while not being 'constrained' in the formal sense, nevertheless needs to > > minimise its software footprint? So the implementer will want to choose > > the solution with the smallest footprint, rather than whatever MTI we > > happen to define in 2017. > > Yes, I agree with you. > > That's why I would like us to permit pledges to support a single client HTTP > library. They will use whatever HTTP client library that they need for their > primary application... so if it's a webrtc nanny camera, then it might well > be HTTP2 + QUIC. > > The problem with HTTP2 is that it permits requests and responses to be > interleaved and not-sequential in the TCP sense. This potentially has a poor > interaction with the BRSKI state machine. We ought to say something about > this *today*. > > > Of course we can always change the MTI later, but if we say right now that > > the MTI only applies to the server side, adding new solutions for future > > types of pledge becomes more straightforward. As far as I can see, this > > would have zero impact on first-generation implementations; initially > > both servers and clients will support the MTI anyway. > > My take is that the server has to support every single MTI that we have every > supported. That's okay. But, HTTP 1.1 with persistent connections is the > minimum (not the maximum). Fair enough. I just want to be sure that when someone comes up with a brilliant new method with a tiny footprint, pledges are free to adopt it despite any MUSTs we write down in 2017. Brian From nobody Thu Sep 14 14:18:54 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABA71320D9 for ; Thu, 14 Sep 2017 14:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2gdQMn7cJ9T for ; Thu, 14 Sep 2017 14:18:49 -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 563E013208E for ; Thu, 14 Sep 2017 14:18:49 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6CB6858C4AF; Thu, 14 Sep 2017 23:18:45 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5066FB0CB9F; Thu, 14 Sep 2017 23:18:45 +0200 (CEST) Date: Thu, 14 Sep 2017 23:18:45 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 21:18:52 -0000 Hi Brian, Sorry, for the delay. I have not sen further feedback on stable-connectivity-05 bside this mail of yours. See answers below, let me know if you want me to rev with the one possible textual improvement or if we think -05 is good enough. Cheers Toerless On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: > I'm just coming back on a couple of points. Generally -05 is almost there... > > > See the rewritten SIIT section. IMHO, there can be no simpler "network" based > > address translation. Where network based means that the translation happens > > in some device he network operator needs to provision. Like the ACP edge device. > > Or even an additional address translation device. > > > > So, the only IMHO easier option is when the OS of the NMS host would internally > > have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. > > Yes, that is exactly the effect of 464XLAT in the end-system (not in the > router). I found rfc6877 a confusing read, but from what i figure, it's not exactly what i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable IPv4 address, and that is something any device in the ACP does not have naturally. (aka: NOC server as client connecting to ACP device, ACP device is server). If i already need to set up some other form of NAT to give an ACP device an outside IPv4 address, then 464XLAT does not buy me any simplifications. I was rather thinking of taking the NAT network function that i was describing and simply embody them in a set of linux NAT rules configured on on the NOC linux system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme, but just a way to avoid having to deal with the problem in the network (adding a NAT device you would otherwise not need): Its a NMS host problme, deal with it in the NMS host. If you can not change the app, let the OS do the NAT. Of course, this would not work for the poor customer who bought a black-blox NMS soution which may run windows, or where you can not configure the linux. Then again, nowadays, most NOC components should be software in VMs, and for those, you should certainly be able to do the NAT in the vswitch of the server. In any case: my interest in expanding the NAT section further is quite limited. The whole goal of the NAT section was to explain that you need 1:1 address mapping and that you can hack this up in likely most available routers with NAT support, but do not consider this to be a good long term solution but use it as a stopgap to upgrade your NOC software to IPv6. No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-)) So, let me know if you feel strongly anything that should be added/modified to the NAT section. > > Alas, i didn't have the time to investigate these options. And most likely if at > > all you could only make those work for linux. > > Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they > will all support IPv6 anyway? Lets hope so, yes. > > So, for now i just remove the note and clarified the last sentence a bit. > > > > If there is anything specific to be said bout why 464XLAT might be better > > longer term, let me know and i can add it. For now it looks like yet another > > network device configured option to me, but i have not tried to understand it > > all the way. > > I think you'd need one of the 464XLAT authors to have a look at the scenario, > because I don't claim to understand it all. Well, the analysis i made above (server must support IPv4 as stated in the RFC) makes me discount it as a more beneficial option to mention. > >>> Using current registration options implies that there will not be > >>> reverse DNS mapping for ACP addresses. > >> > >> Really? I assume we're talking about two-faced DNS, and afaik nothing > >> stops an operator providing reverse mapping in the private DNS. > >> That seems to be implied by the following paragraphs, so the text > >> seems inconsistent anyway. > > > > I know it under the name "split-horizon DNS". Is there any reference ? > > The DNS community in the IETF hates split DNS so much that > not much has been written about it. I did find these: > https://tools.ietf.org/html/rfc6950#section-4 > https://tools.ietf.org/html/rfc7157#section-6.3 > https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens RFC1918 actually explains it succinctly without giving it a name. RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-) So, let me know if you think it's worth creating another stable-connectivity rev, i'd suggest to replace the "split-horizon" sentence with: Operators may therefore need to use a private DNS setup for the ACP ULA addresses. This is the same setup that would be necessary for using RFC1918 addresses in DNS. See for example [RFC1918] section 5, last paragraph. In [RFC6950] section 4, these setups are discussed in more detail. Cheers Toerless > Regards, > Brian From nobody Thu Sep 14 16:05:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E4D13219F for ; Thu, 14 Sep 2017 16:05:50 -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 OtWq6Twhc-7q for ; Thu, 14 Sep 2017 16:05:47 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A049113214D for ; Thu, 14 Sep 2017 16:05:47 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id m63so450194pfk.7 for ; Thu, 14 Sep 2017 16:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7mf3O+AskTjQp7mCBWuSYum0wVNSOox9FV54G/r37M8=; b=WeY5NO6h9sh0JO0yy2mMieoRLlSXDChcVbeAEqW0qnyTYQQfOY8djUqkB2w0fNYMw6 BzmsaDQRkkN8QLtOlZPuW+lqiXF0sI/CaZPUerCw+Jxt8fiIRI2GNWjl2KjFET2JTVDa T3W9QFnAYhvJ2BUKbLN+eTomJEUa+XXzF6T3paFvPQqPY3Gw8LT6IjYZERaD5ttWJ8VV QOvs8ks9hr1gFzcas9BXAwgcoCVih54l5f2uBco7nS98ECaub0JWUnlld8+D8MA41meo bmhhNMd0xuvRfau3mRcv2wWPy2pubFARzzhObhOZAX1ojkO5PyHPVv3IFre4xQ90rIF0 xv+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=7mf3O+AskTjQp7mCBWuSYum0wVNSOox9FV54G/r37M8=; b=UH9laEXU7yENvJhLayfxrZ7naDtIxF7NFCbblBDu8DywE5SMwkIqCMwR5FKZiJTKHy ba3r+ThLjbAAR+AoOtyhjablLjd6qHsDlarw5pbb6M7l6pVS0FiPtZh/I6VycFx22T5C /1xIhQMTX5r98vDNZ4DM/DH1cGxDMjE7DXuiS2clg5592XCej+pqdNtzZMNbl0O4cSUg 0+y6Q1c8wIolbrx0065OovrbCQ6NC2m6HyWpc9sf3NL51KQPh3cWalrQkmQ3kZTnJjQB E/OKrI1THTpG18MTI9B8FZoWAxaItw4Vb+Hy62v0pJMkVHAhFHChlWyitL2gxHgjLuIQ u25A== X-Gm-Message-State: AHPjjUhWBFnZTxP76RIFnkK8DmDcLc+w8hRIgJrfqqdjukZIOWEh66m6 i/Z59uyEcwabtP3f X-Google-Smtp-Source: ADKCNb7TDzZ1yEtKVTH2LHbMttFRK0eaZYtENUaz1PIYYC/EU7shpwKIE5GIC4/IQP5YNA7q++Ifvg== X-Received: by 10.99.116.19 with SMTP id p19mr22440263pgc.303.1505430346545; Thu, 14 Sep 2017 16:05:46 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u184sm30752321pfb.126.2017.09.14.16.05.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2017 16:05:45 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> Date: Fri, 15 Sep 2017 11:05:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 23:05:50 -0000 To cut a long story short, here's a friendly suggestion. The goal is to avoid comments during IETF/IESG review that the NAT text is too vague: OLD To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 NAT can be used. This NAT setup could for example be done in Rt1r1 in above picture to also support IPv4 only NMS hots connected to NOClan. NEW To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 translation [RFC 6145] could be used. This could for example be done in Rt1r1 in the above picture to also support IPv4-only NMS hosts connected to NOClan. Details of the address mapping to be used would depend on the exact scenario and are not specified here. And yes, I like this: > i'd suggest to replace the "split-horizon" sentence with: > > Operators may therefore need to use a private DNS setup for the ACP ULA > addresses. This is the same setup that would be necessary for using > RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > paragraph. In [RFC6950] section 4, these setups are discussed in more detail. Regards Brian On 15/09/2017 09:18, Toerless Eckert wrote: > > Hi Brian, > > Sorry, for the delay. I have not sen further feedback on stable-connectivity-05 > bside this mail of yours. See answers below, let me know if you want me to rev > with the one possible textual improvement or if we think -05 is good enough. > > Cheers > Toerless > > On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: >> I'm just coming back on a couple of points. Generally -05 is almost there... >> >>> See the rewritten SIIT section. IMHO, there can be no simpler "network" based >>> address translation. Where network based means that the translation happens >>> in some device he network operator needs to provision. Like the ACP edge device. >>> Or even an additional address translation device. >>> >>> So, the only IMHO easier option is when the OS of the NMS host would internally >>> have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. >> >> Yes, that is exactly the effect of 464XLAT in the end-system (not in the >> router). > > I found rfc6877 a confusing read, but from what i figure, it's not exactly what > i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable > IPv4 address, and that is something any device in the ACP does not have naturally. > (aka: NOC server as client connecting to ACP device, ACP device is server). > > If i already need to set up some other form of NAT to give an ACP device an outside IPv4 > address, then 464XLAT does not buy me any simplifications. > > I was rather thinking of taking the NAT network function that i was describing > and simply embody them in a set of linux NAT rules configured on on the NOC linux > system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme, > but just a way to avoid having to deal with the problem in the network (adding a NAT > device you would otherwise not need): > > Its a NMS host problme, deal with it in the NMS host. If you can not change the app, > let the OS do the NAT. Of course, this would not work for the poor customer who bought > a black-blox NMS soution which may run windows, or where you can not configure the > linux. Then again, nowadays, most NOC components should be software in VMs, and > for those, you should certainly be able to do the NAT in the vswitch of the server. > > In any case: my interest in expanding the NAT section further is quite limited. > The whole goal of the NAT section was to explain that you need 1:1 address mapping > and that you can hack this up in likely most available routers with NAT support, > but do not consider this to be a good long term solution but use it as a stopgap > to upgrade your NOC software to IPv6. > > No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-)) > > So, let me know if you feel strongly anything that should be added/modified to the > NAT section. > >>> Alas, i didn't have the time to investigate these options. And most likely if at >>> all you could only make those work for linux. >> >> Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they >> will all support IPv6 anyway? > > Lets hope so, yes. > >>> So, for now i just remove the note and clarified the last sentence a bit. >>> >>> If there is anything specific to be said bout why 464XLAT might be better >>> longer term, let me know and i can add it. For now it looks like yet another >>> network device configured option to me, but i have not tried to understand it >>> all the way. >> >> I think you'd need one of the 464XLAT authors to have a look at the scenario, >> because I don't claim to understand it all. > > Well, the analysis i made above (server must support IPv4 as stated in the RFC) > makes me discount it as a more beneficial option to mention. > >>>>> Using current registration options implies that there will not be >>>>> reverse DNS mapping for ACP addresses. >>>> >>>> Really? I assume we're talking about two-faced DNS, and afaik nothing >>>> stops an operator providing reverse mapping in the private DNS. >>>> That seems to be implied by the following paragraphs, so the text >>>> seems inconsistent anyway. >>> >>> I know it under the name "split-horizon DNS". Is there any reference ? >> >> The DNS community in the IETF hates split DNS so much that >> not much has been written about it. I did find these: >> https://tools.ietf.org/html/rfc6950#section-4 >> https://tools.ietf.org/html/rfc7157#section-6.3 >> https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens > > RFC1918 actually explains it succinctly without giving it a name. > RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-) > > So, let me know if you think it's worth creating another stable-connectivity rev, > i'd suggest to replace the "split-horizon" sentence with: > > Operators may therefore need to use a private DNS setup for the ACP ULA > addresses. This is the same setup that would be necessary for using > RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > paragraph. In [RFC6950] section 4, these setups are discussed in more detail. > > Cheers > Toerless > >> Regards, >> Brian > From nobody Fri Sep 15 09:56:45 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F48133039 for ; Fri, 15 Sep 2017 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL9fP1MNBrL8 for ; Fri, 15 Sep 2017 09:56:41 -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 48983133016 for ; Fri, 15 Sep 2017 09:56:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 33DF4E00C for ; Fri, 15 Sep 2017 13:01:01 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EDB9D80B2F for ; Fri, 15 Sep 2017 12:56:39 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 16:56:43 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > NEW > To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 > translation [RFC 6145] could be used. This could for example be done in Rt1r1 > in the above picture to also support IPv4-only NMS hosts connected to > NOClan. Details of the address mapping to be used would depend on > the exact scenario and are not specified here. +1 RFC7915 obsoletes 6145, and there is also both: RFC7756:Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode but specifically: rfc7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments builds upon 7915. which I suggest be mentioned. They solve exactly the problem. (I'm a big fan...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlm8BkcACgkQgItw+93Q 3WXVxAf/RWNW3/ih0DbTvrC5yK5UwrOaQheHKKVHD7BfuzPewoHURy9SYtQaMIXa +EqQ1cl9aOQBe00lyReQLFHYE+y4pLxjqiQAEYRehLtyEsNpoOXceOe+gOscBULt eT/t8rJBxg9UAFwCZTUoN2yR7GZBvLVACRczqeu/UAyjsNiVxl4GYB4871rRI/Ce h1VWpe5Bi1GlccLW8GDn2brCWd7lwUQMC6nhduRVhBDzxSGsU5l6us7kSeGgDTew AuyvzOMHVYuxETT0a2AUXhT57awH9MOauydq1hH67UsEzz3vHLrtYybg1FcgBZQC X28P84hr6WdKHKN6a4dhUh/r4JgEmQ== =km+d -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 15 13:34:47 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2985A1341FC for ; Fri, 15 Sep 2017 13:34: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 6JhbPVLpua1K for ; Fri, 15 Sep 2017 13:34:44 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C23132944 for ; Fri, 15 Sep 2017 13:34:44 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id d8so2136753pgt.4 for ; Fri, 15 Sep 2017 13:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9ctB0EsC7oEVSxDyHZFcAFlWB8hiykJKZarmDy/08h0=; b=OoBFjfTeACJ/2lIQRJti5TYI4RKOv2z55ofMVZsfFnLP53TP+LurAhYu9ycUXpaL/9 FY/uad1RcYqh3k5BWwzGkRvNl4Rcg+80YI5fUCFD8HjnQsmdXHFhQ+HUDW1dlF8E5pgE I+++Gfsa3pk+OR2dsjgGHpatMV75bY62VtFvQ4hxTLv/iq4ndLiRu70PRE0gAdKcyALz jjSJGvwmBx0mbI1KQdGnPF7IK7BgBLGz3vxeTojyij3zwsF7FTexvjtH47OYS3zUp98R ecMvhmvBdzn9JWa1t0L7GPM8O/XHyP9pxn0yvKISTNwumxUhUni7r2LHDriGSoxyiQGH KsUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=9ctB0EsC7oEVSxDyHZFcAFlWB8hiykJKZarmDy/08h0=; b=ZCVKVmZz/bnMsz7rY+QlNBdgZbGDM02Jy7oIRN7ixVk3Y3ZIgvu/jIKYpod+Set/JZ nkHBiuYOx1pmyrwrbyC+Uti7RQgCTwzKEpg3KthQlnG8adLag/BzN+FZXW1OZI3yUQQ/ 6hdsevGfl/b3w7xaBrGFpkSkl/yzvxN5bX+uqaLPX+u0O2FlYTYH2SNQw4I74CFGj9zK sTcUG57L8YD444tGquCOb3qG7xXPYw6eYXcHYIuWXtdQq9BY8WFRzHzZgjLaCt5XAfkj Mz9sjTgRKNm2UP63CtXm969x+M5V6FwKNn8734oRyWsOjVPqO1c51d+PTKs1wrMRDiu3 BSyQ== X-Gm-Message-State: AHPjjUhe557vsaoX5mZqyU7ArzJUCwV8MyCNrSduWtQdUxC3NgG8iqfi 0x+9WPsHvcKP1PAt X-Google-Smtp-Source: AOwi7QCpYkhubE9QBTqzcFZENEI/0sggsnw+DfnEFX4xuxcfALgE9AMvNpv1keWxY0GFbs2yqE5Rzw== X-Received: by 10.98.245.74 with SMTP id n71mr869492pfh.102.1505507683907; Fri, 15 Sep 2017 13:34:43 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g68sm3532367pfc.64.2017.09.15.13.34.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Sep 2017 13:34:42 -0700 (PDT) To: Michael Richardson , Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> <23676.1505494599@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 16 Sep 2017 08:34:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <23676.1505494599@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 20:34:46 -0000 On 16/09/2017 04:56, Michael Richardson wrote: > > Brian E Carpenter wrote: > > NEW > > To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 > > translation [RFC 6145] could be used. This could for example be done in Rt1r1 > > in the above picture to also support IPv4-only NMS hosts connected to > > NOClan. Details of the address mapping to be used would depend on > > the exact scenario and are not specified here. > > +1 > RFC7915 obsoletes 6145, Oops, sorry about that. > and there is also both: > > RFC7756:Stateless IP/ICMP Translation for IPv6 Internet Data Center > Environments (SIIT-DC): Dual Translation Mode > > but specifically: rfc7755 > SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments > > builds upon 7915. which I suggest be mentioned. They solve exactly the > problem. (I'm a big fan...) I'm not, but unfortunately I agree that sometimes such things are unavoidable. However, it's a messy topic and limiting the discussion in the present draft seems best to me. Brian From nobody Sun Sep 17 22:36:20 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 367AC132025; Sun, 17 Sep 2017 22:36:18 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150571297817.555.4376807133659131576@ietfa.amsl.com> Date: Sun, 17 Sep 2017 22:36:18 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 05:36:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-06.txt Pages : 22 Date : 2017-09-17 Abstract: OAM (Operations, Administration and Maintenance - as per BCP161, [RFC6291]) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-06 https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 17 22:38:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB3C133023 for ; Sun, 17 Sep 2017 22:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWYZaxz_5PF2 for ; Sun, 17 Sep 2017 22:38:53 -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 56EF3132025 for ; Sun, 17 Sep 2017 22:38:53 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 41F9658C4D6; Mon, 18 Sep 2017 07:38:48 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 26A0AB0CC04; Mon, 18 Sep 2017 07:38:48 +0200 (CEST) Date: Mon, 18 Sep 2017 07:38:48 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 05:38:56 -0000 Thanks, Brian: The "OLD" paragraph you list was from -04. After your review i had already changed this in -05 to NEW: To connect IPv4 only management plane devices/applications with the ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is necessary. The basic mechanisms for this are defined in SIIT ([RFC7915]). There are multiple solutions using this mechanisms. To understand the possible solutions, we consider the requirements: .... http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt I also did spend a good amount of time because of your -04 review and prior request by mohammed to detail in the following parapgraphs the possible options in more detail. That text leverages the 'SIIT' term and discusses the EAM solutions (RFC7757 is best). Given how this is an informational OPS document, i think it is helpfull to elaborate on the understood details of requirements and how known current solutions fit them. The fact that none of the currently defined NAT solutions provides for the most simple possible configuration (aka: minimum number of prefix EAM's to configure) is also IMHO a perfectly valid outcome for an OPS document. It could mean that users will simply accept the need for longer mnaual NAT config (long list of 1:1 mappings) or vendors implement a proprietary EAM (explicit address mapping) CLI to make it simpler. Or users will move faster to IPv6 on the NOC ;-) So, for the time being, i just commited -06 with the second fix. Let me know what you folks think about WG last call status of the stable connectivity draft. Cheers Toerless On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote: > To cut a long story short, here's a friendly suggestion. The goal is to avoid > comments during IETF/IESG review that the NAT text is too vague: > > OLD > To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 > NAT can be used. This NAT setup could for example be done in Rt1r1 > in above picture to also support IPv4 only NMS hots connected to > NOClan. > > NEW > To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 > translation [RFC 6145] could be used. This could for example be done in Rt1r1 > in the above picture to also support IPv4-only NMS hosts connected to > NOClan. Details of the address mapping to be used would depend on > the exact scenario and are not specified here. > > And yes, I like this: > > > i'd suggest to replace the "split-horizon" sentence with: > > > > Operators may therefore need to use a private DNS setup for the ACP ULA > > addresses. This is the same setup that would be necessary for using > > RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > > paragraph. In [RFC6950] section 4, these setups are discussed in more detail. > > Regards > Brian > > On 15/09/2017 09:18, Toerless Eckert wrote: > > > > Hi Brian, > > > > Sorry, for the delay. I have not sen further feedback on stable-connectivity-05 > > bside this mail of yours. See answers below, let me know if you want me to rev > > with the one possible textual improvement or if we think -05 is good enough. > > > > Cheers > > Toerless > > > > On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: > >> I'm just coming back on a couple of points. Generally -05 is almost there... > >> > >>> See the rewritten SIIT section. IMHO, there can be no simpler "network" based > >>> address translation. Where network based means that the translation happens > >>> in some device he network operator needs to provision. Like the ACP edge device. > >>> Or even an additional address translation device. > >>> > >>> So, the only IMHO easier option is when the OS of the NMS host would internally > >>> have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. > >> > >> Yes, that is exactly the effect of 464XLAT in the end-system (not in the > >> router). > > > > I found rfc6877 a confusing read, but from what i figure, it's not exactly what > > i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable > > IPv4 address, and that is something any device in the ACP does not have naturally. > > (aka: NOC server as client connecting to ACP device, ACP device is server). > > > > If i already need to set up some other form of NAT to give an ACP device an outside IPv4 > > address, then 464XLAT does not buy me any simplifications. > > > > I was rather thinking of taking the NAT network function that i was describing > > and simply embody them in a set of linux NAT rules configured on on the NOC linux > > system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme, > > but just a way to avoid having to deal with the problem in the network (adding a NAT > > device you would otherwise not need): > > > > Its a NMS host problme, deal with it in the NMS host. If you can not change the app, > > let the OS do the NAT. Of course, this would not work for the poor customer who bought > > a black-blox NMS soution which may run windows, or where you can not configure the > > linux. Then again, nowadays, most NOC components should be software in VMs, and > > for those, you should certainly be able to do the NAT in the vswitch of the server. > > > > In any case: my interest in expanding the NAT section further is quite limited. > > The whole goal of the NAT section was to explain that you need 1:1 address mapping > > and that you can hack this up in likely most available routers with NAT support, > > but do not consider this to be a good long term solution but use it as a stopgap > > to upgrade your NOC software to IPv6. > > > > No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-)) > > > > So, let me know if you feel strongly anything that should be added/modified to the > > NAT section. > > > >>> Alas, i didn't have the time to investigate these options. And most likely if at > >>> all you could only make those work for linux. > >> > >> Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they > >> will all support IPv6 anyway? > > > > Lets hope so, yes. > > > >>> So, for now i just remove the note and clarified the last sentence a bit. > >>> > >>> If there is anything specific to be said bout why 464XLAT might be better > >>> longer term, let me know and i can add it. For now it looks like yet another > >>> network device configured option to me, but i have not tried to understand it > >>> all the way. > >> > >> I think you'd need one of the 464XLAT authors to have a look at the scenario, > >> because I don't claim to understand it all. > > > > Well, the analysis i made above (server must support IPv4 as stated in the RFC) > > makes me discount it as a more beneficial option to mention. > > > >>>>> Using current registration options implies that there will not be > >>>>> reverse DNS mapping for ACP addresses. > >>>> > >>>> Really? I assume we're talking about two-faced DNS, and afaik nothing > >>>> stops an operator providing reverse mapping in the private DNS. > >>>> That seems to be implied by the following paragraphs, so the text > >>>> seems inconsistent anyway. > >>> > >>> I know it under the name "split-horizon DNS". Is there any reference ? > >> > >> The DNS community in the IETF hates split DNS so much that > >> not much has been written about it. I did find these: > >> https://tools.ietf.org/html/rfc6950#section-4 > >> https://tools.ietf.org/html/rfc7157#section-6.3 > >> https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens > > > > RFC1918 actually explains it succinctly without giving it a name. > > RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-) > > > > So, let me know if you think it's worth creating another stable-connectivity rev, > > i'd suggest to replace the "split-horizon" sentence with: > > > > Operators may therefore need to use a private DNS setup for the ACP ULA > > addresses. This is the same setup that would be necessary for using > > RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > > paragraph. In [RFC6950] section 4, these setups are discussed in more detail. > > > > Cheers > > Toerless > > > >> Regards, > >> Brian > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Sun Sep 17 22:45:36 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CD913306A for ; Sun, 17 Sep 2017 22:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWrUP_a9yM3n for ; Sun, 17 Sep 2017 22:45:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9A013305F for ; Sun, 17 Sep 2017 22:45:34 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3034558C4D6; Mon, 18 Sep 2017 07:45:30 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 10946B0CC04; Mon, 18 Sep 2017 07:45:29 +0200 (CEST) Date: Mon, 18 Sep 2017 07:45:29 +0200 From: Toerless Eckert To: Michael Richardson Cc: Anima WG Message-ID: <20170918054529.GB31832@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> <23676.1505494599@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23676.1505494599@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 05:45:36 -0000 On Fri, Sep 15, 2017 at 12:56:39PM -0400, Michael Richardson wrote: > RFC7915 obsoletes 6145, and there is also both: That's the one i had used already in static-connectivity-05 as the primary reference. > RFC7756:Stateless IP/ICMP Translation for IPv6 Internet Data Center > Environments (SIIT-DC): Dual Translation Mode > > but specifically: rfc7755 > SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments > > builds upon 7915. which I suggest be mentioned. They solve exactly the > problem. (I'm a big fan...) When i was comparing the different solutions, i found RFC7757 to be best suited in the case of ACP because of its flexibility. Thats what i am referring to in stable-connectivity-05. I didn't find that RFC7755 was adding any more benefits for the ACP NAT use case. Check out the section about NAT in stable-connectivity-05 (or -06, unchanged). Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Sun Sep 17 22:48:46 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64076127517; Sun, 17 Sep 2017 22:48:37 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150571371737.570.8543301307048365272@ietfa.amsl.com> Date: Sun, 17 Sep 2017 22:48:37 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 05:48:37 -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 : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-10.txt Pages : 82 Date : 2017-09-17 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-10 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 17 23:04:45 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F8213306A; Sun, 17 Sep 2017 23:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjLyFQGWLNW4; Sun, 17 Sep 2017 23:04:38 -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 EE59F13306F; Sun, 17 Sep 2017 23:04:34 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5EE0358C4B7; Mon, 18 Sep 2017 08:04:29 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3E128B0CC08; Mon, 18 Sep 2017 08:04:29 +0200 (CEST) Date: Mon, 18 Sep 2017 08:04:29 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org Message-ID: <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 06:04:44 -0000 On Wed, Aug 02, 2017 at 02:39:03PM +1200, Brian E Carpenter wrote: > Hi, > > Here are my comments on ACP version -08. First the ones I rank > as substantive isssues, then a few nits. Thanks so much Brian, lots of help to improve quality. Alas, i got derailed from finishing the fixes for your review because the reviews/last-call for stable connectivity which had me figure out a bunch of changes to ACP document, and i first put all of those in acp-09 (and then i had a bunch of business travel, so i thin i hadn't even sent out a note about -09 to the list). Changes -08 - 09: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-08.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt Might be useful to check that diff out separately, key big blocks: - Made the V8 scheme more flexible (allow 16 bit addresses, eg: for the the stateless BRSKI proxy mechanisms you and MichaelR where discussing. - All RPL profile detail fixups from MichaelR's review - Expanded ACP connect section (taken over from stable-connectivity). - introduced manual addressing sub-scheme for more consistent autonomic-connect (also as outcome of stable-connectivity review) - Doc now claims to update RFC4291/RFC4193, section to summarize those updates - aka: that section is meant for later review by 6ops or 6man. Details of changes of course in changelog of the draft. The changes from your review below then got into acp -10 that i just posted: Changes -09 - 10: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-10.txt See below. Hopefully all answers to your points are satisfactory. Cheers Toerless > Issues: > ------- > > > 2. Terminology > ... > > ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 > > addresses. ACP addresses are ULA. > > No, they are *not* equivalent to RFC1918, because those are ambiguous > and ULAs are not. Please avoid controversy, just cite RFC4193. IMHO, a terminology section has to try to explain terms without making the reader refer to ever mor ereferences. Had a lot of customers who didn't know what ULA are, but who klicked when i mentioned 1918. And differences/benefits over 1918 become obvious later in doc anyhow (ambiguity). acp-10 text: A "Unique Local Address" (ULA) is an IPv6 address in the block fc00::/7, defined in . It is the approximate IPv6 counterpart of the IPv4 private address (). If you do not like that, please fix in Wikipedia wherer i stole this from: https://en.wikipedia.org/wiki/Unique_local_address ;-) > > 3.2. Secure Bootstrap over an Unconfigured Network > ... > > ...This does not require any configuration > > on intermediate nodes, because they can communicate through the ACP. > > s/they can communicate/they can communicate securely/ ACK > > 4. Requirements > ... > > ACP4: The ACP MUST be generic. Usable by all the functions and > > protocols of the AN infrastructure. It MUST NOT be tied to a > > particular protocol. > > I'm not sure what the last sentence is saying. Do you mean > "MUST NOT be tied to a particular transport protocol" or > "MUST NOT be tied to a particular security protocol"? > Or do you mean "MUST NOT restrict the choice of upper layer > protocol"? Or do you simply mean "MUST provide a generic > IPv6 service"? This goes back to very early discussions in ANIMA when we argued that a greenfield autonomic networking design would not need any protocol other than GRASP for any ASA to ASA communications. In which case there would not have been a good argument for ACPs concept of a virtual IPv6 network to transport any management traffic. acp-10: "NOT be tied to a particular application or transport protocol.". Please suggest better text if thats not sufficient. > Also, there's no requirement about performance or the > expected traffic density. Should we say something either > in the Requirements section or in the Notes in the > Overview section? I assume that performance is not critical > and ACP traffic density is expected to be low. My practical experience was that proliferation of implementation was easier when you did not have performance requirements but when you could implement also in just software forwarding path. This did then lead to text in stable connectivity arguing about using the ACP primarily for critical operations. acp-10 has a new performance section restate that position:
There are no performance requirements against ACP implementations defined in this document because the performance requirements depend on the intended use case. It is expected that full autonomic devices with a wide range of ASA can require high forwarding plane performance in the ACP, for example for telemetry, but that determination is for future work. Implementations of ACP to solely support traditional/SDN style use cases can benefit from ACP at lower performance, especially if the ACP is used only for critical operations, eg: when the data plane is not available. See for more details.
Pls. suggest better text if you feel this is insufficient/inadequate. > > 5. Overview > ... > > Default policy is: To all adjacent nodes in the > > same domain. > > I know this is explained later, but I think both > "adjacent" and "domain" need some qualification. > For example: > > Default policy is: To all adjacent link-layer autonomic > nodes in the same autonomic domain. I am daring to claim this is better english: acp-10: To all link-layer adjacent autonomic nodes in the same autonomic domain. > > 5. Inside the ACP VRF, each node sets up a virtual (loopback) > > interface with its ULA IPv6 address. > > I think we have cases where a node has multiple ULAs. Right now, an ACP would have exacty one Certificate derived ULA and 0 or more configured ones for autonomic-connect interfaces in case the operator wants to use the manual addressing sub-scheme on the autonomic connect interface. What other cases are you thinking of ? > > 6.1. Domain Certificate > > > > To establish an ACP securely, an ACP device MUST have a globally > > unique domain certificate (LDevID),... > > You need a normative reference for the LDevID format. acp-10: Added 802.1AR reference and pointed to it in terminology section for IDevID and LDevID. > > 6.1.1. ACP information > > > > The domain certificate (LDevID) of an autonomic node MUST contain ACP > > specific information, specifically the domain name, the address of > > the device in the ACP with the Zone-ID set to zero ("ACP address"). > > You need a cross-reference for Zone-ID, which is undefined at this point. acp-10: Removed the zone-ID details here and explained it only in the description of the sub-schemes More logical now that there are multiple address sub-schemes (only one of them with a zone field). > ... > > anima.acp+{+{+}}@ > > What notation is that? Is {} supposed to be an optional item? > If so, why not use [] as in ABNF, and cite ABNF. acp-10: Done. Please check again. Got a lot more complex by using ABNF, but maybe more precise. > > is used to indicate... > > Is that required to respect DNS syntax? If so, please say so. Yes. That was already in -09. > > {.} > > That's wrong. is preceded by "@" in your syntax, and > in your example, the dot is in the element > "area51.research". > No, it was correct, but hopefully now with ABNF and the explicit example expanded it's less easy to misread, although i am not 100% sure that ABNF really allows me to specify what i want 100%: anima.acp+fda379A6f6ee00000200000064000000+area51.research@acp.example.com routing-subdomain = area51.research.acp.example.com ^ | This dot needs to come from the syntax because it is not in the actual ACP information string, it is the connector between the rsub part and the acp-domain. In ABNF the problem is that i need the option to specify the rsub part as optional, but then i want to say that this connecting dot is also only used when the rsub part is empty. And i think there is no ABNF element to do this. Check the ABNF i have written, i am rying to wing that problem. ... > Is there a length limit on the rfc822Name ? Seemingly yes, but difficult to hunt down. I have written now: Note that the maximum size of "acp-information" is 254 characters and the maximum size of acp-device-info is 64 characters according to that is referring to (superceeded by > 6.1.2. Maintenance > > a) As Michael R said, > b) all the stuff about the registrar should be in BRSKI, not duplicated here. > c) In fact, it's > very confusing to have it here. > d) If we want a cert renewal mechanism, surely that's part of BRSKI? b), c) BRSKI only specifies zero touch bootstrap, but not certificate maintenance/renewal. ACP should be modular, eg: we should be able to combine it with any initial bootstrap (BRSKI of course preferred and only BRSKI+ANIMA+GRASP = ANI, but netconf-zero-touch or other would be possible option if so desired). So we need zero-touch certificate (renewal, revocation) specification in ACP doc. Cert renewal in ACP spec is using EST (RFC7030). Use of GRASP is specified in ACP draft is solely to support this EST renewal. Without GRASP to find EST-Server, we can not support EST-Server redundancy: YOu can specify a URL for reneal in the certificate, but if that URL goes down, you're lost. Without ACP/GRASP you would have had to setup some form of anycast domain-name or ip-address in the URL - or worse yet list multiple registrar. The GRASP objective in BRSKI is BRSKI-TLS and is discovered by bootstrap proxies, the GRASP objective in ACP is EST-TLS and is discovered by encrolled ACP members for their own Cert renewal. Big difference. c) Initially i thought too that RSKI would be a superset of everything that we'd need for certificate maintenance, but thats not the goal of BRSKI. It is only meant o specify initial bootstrap, but not cert renewal or the like. a) I think to remember that MichaelR was pretty positive on the mike in Prague about the inclusion of EST in ACP spec for renewal. But i am sure he will chime in. The confusing bits may be how to use GRASP. Here is what current ACP and BRSKI text would lead to: - ACP registrar without BRSKI: registrar == EST-server registrar announces AN_join_registrar with only EST-TLS objective value - ACP registrar with BRSKI: registrar == EST-server + BRSKI spec registrar announces AN_join_registrar with both EST-TLS and EST-BRSKI objective values > > The loop-count MUST be sete to 255. When an ACP node > > receives the M_FLOOD, it will have been reduced by the number of hops > > from the EST server. > > I don't like that. The role of the loop count is loop prevention, > so it should be set to a reasonable upper bound on the "radius" > of the network. GRASP has two measures for loop detection, this > one and detection of duplicate session IDs, but that was > intentional redundancy.] Sure, and if we set loop-count to a well-known value such as 255 then we do use it in the same way as IP uses TTL: Just as a way of last defense. Primary method is loop-free routing protocols (IP) or duplicate session ID (GRASP). [50% rant:] Every new technology seems to think that TTL is a great tool, only then to figure out later that its only a good protection of last resort. IP unicast did this, and today, nobody really uses any TTL other than 255 or 1. IP multicast regurgitated TTL values for "TTL scoping" and it took almost 10 years to get rid of it, we depreciated that, and since ~2000 IP multicast also only uses 255 or 1 since then. IMHO: Same learning curve is necessary for GRASP. Maybe we will come up with good use cases for 1 < TTL < 255 still, but i doubt it. Unless you have very specific variations of eg: ACP for networks with well-knon smaller max-TTL, i do not see it. [/rant] But you do not need to buy into this logic of mine. I just want to put you in the bind for an ability in GRASP to discover the closest instance of an objective. Thats i think something you agreed GRASP will support a long time ago. If you do not like to use the fixed TTL value of 255 as a mechanism to help support the "closest objective announcer" mechanism, then i need to specify a more complex way to discover the closest objective announcer: - objective-values for AN_join_registrar would need to be extended to be a structure like: objective-value = [ sender-ttl, method-list [, future-extensions]* ] method-list = [ method ]*1 methd = BRSKI-TLS | EST-TLS | ... sender-ttl = NUM (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) That way, the recipient can compare sender-ttl with the TTL of the received objective and threeby figue out which one is closest. I fine either way. I just tried to go for the most simple, logical option. > > 6.2. AN Adjacency Table > > > > To know to which nodes to establish an ACP channel, every autonomic > > node maintains an adjacency table. The adjacency table contains > > information about adjacent autonomic nodes, at a minimum: node-ID, IP > > address, domain, certificate. > > Please specify which IP address(es) you mean. Link-Local, ACP > Address(es), or both? acp-10: Added. Its the link local. It was described further below in the doc already: The result of the discovery is the IPv6 link-local address of the neighbor as well as its supported secure channel protocols (and non-standard port they are running on). It is stored in the AN Adjacency Table, see which then drives the further building of the ACP to that neighbor. > Can you also indicate that an API to this table is needed (at > least by the GRASP core, and possibly by any ASA that wants to > make direct use of the ACP)? acp-10: Interaction between ACP and other autonomic elements like GRASP (see below) or ASAs should be via an API that allows (appropriately access controlled) read/write access to the AN Adjacency Table. Specification of such an API is subject to future work. > > 6.3. Neighbor Discovery with DULL GRASP > ... > > [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1, > > ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"], > > [O_IPv6_LOCATOR, > > h'fe80000000000000c0011001FEEF0000, UDP, 15000] > > ] > > Once we are fully settled on this I can generate an example and > its binary value for complete clarity. I have one comment which is > that when I last updated draft-carpenter-anima-ani-objectives, > I replaced "SYNCH-FLAG" with "5" (the actual value of the flag > byte) - otherwise you have to define SYNCH-FLAG. Actually > the value 5 indicates discovery+synchronization; everything > should work just the same if it was 4 (synchronization alone), > since it's flooded. I don't know if we care about that difference. acp-10: defined sync-only and used that for both grasp ojectives. > > The ttl and loop-count are fixed at 1 since this is a link-local > > operation. > > No, the ttl is milliseconds - the valid lifetime of the flood. > You have that correct in your version of AN_join_registrar. acp-10: Fixed. > > 6.8.2. ACP as the Security and Transport substrate for GRASP > ... > > GRASP inside the ACP uses link-local UDP IPv6 multicast across the > > ACP virtual interfaces for GRASP neighbor discovery... > > and flooding acp-10: Ack. > Also, you might want to add a reminder that GRASP does its own > relaying of multicast packets between interfaces; the ACP is > not required to provide multicast routing. Saying that was actually the intent of the prior section "GRASP as a core service of the ACP" But maye sentence was not good. acp-10: Please check 6.8.1 again. There is now a rather comprehensive description of GRASP, IP multicast, flooding and so on. Too long to paste here unfortunately. Maybe some of the later paragraphs can go into an appendix. But given how this IMHO abuse of IP multicast to do service discovery is still going on since 30 years no, i do appreciate any opportunity to write down a sane option ;-) > > ...and IPv6 over TLS > > across the ACP virtual interfaces for any of its unicast messages. > > Wait, what are you saying here? Do you really mean IPv6 > over TLS, or TLS over TCP over IPv6? Oops, that was just a bad ordering of words. The intention even in -08 was to have GRASP always be carried "natively" (without any UDP/IP packet headers) inside TLS/TCP (for "unicast" connections) or just via TCP (for connections to ACP neighbors on their link-local addresses - TLS not required here because it doesn't add anything on top of the ACP secure channel mechanism in this case). Pls. re-check 6.8.2 i overhauled it. > As Eric Rescorla asked us at one point, please draw a ladder > diagram of the protocol stack. This is now part of 6.8.2: ACP: ............................................................... . . . /-GRASP-flooding-\ ACP GRASP instance . . / \ . . GRASP GRASP GRASP . . link-local unicast link-local . . multicast messages multicast . . messages | messages . . | | | . ............................................................... . v v v ACP security and transport . . | | | substrate for GRASP . . | | | . . | ACP GRASP | - ACP GRASP loopback . . | loopback | loopback interface . . | TLS | - AN-cert auth . . | | | . . ACP GRASP | ACP GRASP - ACP GRASP virtual . . subnet1 | subnet2 virtual inerfaces . . TCP | TCP . . | | | . ............................................................... . | | | ^^^ Users of ACP (GRASP/ASA) . . | | | ACP interfaces/addressing . . | | | . . | | | . . | ACP-loopack | - ACP loopback interface . . | ACP-address | - address (global ULA) . . subnet1 | subnet2 - ACP virtual interfaces . . link-local | link-local - addresses . ............................................................... . | | | ACP routing and forwarding . . | RPL-routing | . . | /IP-Forwarding\ | . . | / \ | . . ACP IPv6 packets ACP IPv6 packets . . |/ \| . . IPsec/dTLS IPsec/dTLS - AN-cert auth . ............................................................... | | Data Plane | | | | - ACP secure channe link-local link-local - encap addresses subnet1 subnet2 - data plane interfaces | | ACP-Nbr1 ACP-Nbr2 > ... > > TLS is mandated for GRASP because the ACP secure channel mandatory > > authentication and encryption protects only against attacks from the > > outside but not against attacks from the inside - compromised ACP > > members > > I think the threat model really needs a clearer explanation. I assume > that Bob and Alice are good guys, and Eve is a malicious ACP member. > So a packet from Alice to Bob is encrypted from Alice to Eve, decrypted > by Eve, then encrypted from Eve to Bob. So Eve can do what she wants > with the decrypted packet. I've only been using https://en.wikipedia.org/wiki/Alice_and_Bob where it was easy enough, but not when discussing attacks against GRASP/ACP I think its easier to memorize the cast of character from Hamlet first than that rocky horror picture show ensemble. Eve seems to be only allowed to do passive attacks (Eve(dropper). If Eve was an ACP member onpath between Alice and Bob, it could observe the GRASP TCP connection. Assuming Alice and Bob are not only ACP members but also members of the privacy-advocacy team, they would always demand end-to-end encryption against Eve. Thats why ACP now provides TLS connections to GRASP for that purpose. What i did explain in 6.8.2 is that Mallory, who is permitted to be an active attacker could be an ACP member and now when Alice tries to find an objective from Bob, Mallory intercepts the objecive discovery (whether it's M_FLOOD or M_DISCOVERY), and makes itself look like Bobs objecctive to Alice, and then once it has captured the GRASP unicast connection from Alice, it will open another unicast connection to Bob and now it proxies the unicast GRASP negotiation between Alice and Bob - so TLs does not help at all. Check out if you think 6.8.2 is sufficient now, if not maybe propose more specific text. 9.2.2 is also summarizing the attack vector. > Now, who does the TLS wrapping? Will that be done by the ACP, > or by the GRASP core? If the latter, you still need to explain > how the ACP conveys the cert information to GRASP. Should be obvious from 6.8.2 now i hope: the ACP GRASP loopback/ virtual interfaces are interfaces that take GRASP messages, so ACP does the TCP/TLS encap/decap. > > 6.10.1. Fundamental Concepts of Autonomic Addressing > ... > > o Addresses in the ACP are permanent, and do not support temporary > > addresses as defined in [RFC4941]. > > Add something like: > > o Addresses in the ACP are not considered sensitive on > privacy grounds, so do not need to be pseudo-random > as discussed in [RFC7721]. > > (You probably also need to discuss why the ACP is not subject > to scanning attacks: because ULAs are not propagated across > domain boundaries.) acp-10: Addresses in the ACP are not considered sensitive on privacy grounds, so do not need to be pseudo-random as discussed in Because they are not propagated to untrusted (non ACP) devices and stay within a domain, we also consider them not to be subject to scanning attacks.. > > > 6.10.2. The ACP Addressing Base Scheme > > > > The Base ULA addressing scheme for autonomic nodes has the following > > format: > > > > 8 40 2 78 > > +--+-----------------+------+------------------------------------------+ > > |FD| hash(subdomain) | Type | (sub-scheme) | > > +--+-----------------+------+------------------------------------------+ > > > > Figure 2: ACP Addressing Base Scheme > > > > The first 48 bits follow the ULA scheme, as defined in [RFC4193], to > > which a type field is added: > > > > o "FD" identifies a locally defined ULA address. > > For the Nth time, please s/FD/fd/ as required by RFC5952 Fixed. Day 1 bug. Although we can not really use 5952 in the acp-information field, but i like consistency too. > > o Type: This field allows different address sub-schemes in the > > future. The goal is to start with a single sub-schemes, but to > > allow for extensions later if and when required. This addresses > > the "upgradability" requirement. Assignment of types for this > > field should be maintained by IANA. > > You need to write precise directions to IANA. acp-10: Done. It's just the addressing Type field for now, but could become more. > > 6.10.3. ACP Zone Addressing Sub-Scheme > > > > The sub-scheme defined here is defined by the Type value 0 (zero) in > > the base scheme. > > > > 51 1 13 63 1 > > +---------------------+---+---------+-----------------------------+---+ > > | (base scheme) | Z | Zone-ID | Device-ID | V | > > | | | | Registrar-ID | Device-Number| | > > +---------------------+---+---------+--------------+--------------+---+ > > 48 15 > > s/51/50/ Thanks. > Although I think it would be simpler to do this: > > 48 2 1 13 63 1 > +----------------+----+---+---------+-----------------------------+---+ > | ULA prefix |Type| Z | Zone-ID | Device-ID | V | > | | 00 | | | Registrar-ID | Device-Number| | > +----------------+----+---+---------+--------------+--------------+---+ > 48 15 Not changed: MichaelM came up with the picture, so i didn't want to change it too much. Besides, i did run into a benefit of this approach: i changed the hash(subdomain) to hash(routing-subdomain) because thats the correct term now, and e voila: i did not have to do this change in the now 3 sub schema pictures. (its 3 sub schemes now because in -09 i did introduce the manual addressing sub-scheme as well after the "stable-connectivity" review and its resulting options for addressing - aka: the safe bet when the 6man police does not like to use the Vlong addressing scheme on autonomic connect interfaces). > > > > 6.10.4. ACP V8 Addressing Sub-Scheme > > > > The sub-scheme defined here is defined by the Type value 1 (one) in > > the base scheme. > > > > 51 63 8 > > +---------------------+-----------------------------+----------+ > > | (base scheme) | Device-ID | V | > > | | Registrar-ID | Device-Number| | > > +---------------------+--------------+--------------+----------+ > > 46 32 > > Same comments. see above > > 6.10.5. Other ACP Addressing Sub-Schemes > > > > Other ACP addressing sub-schemes can be defined if and when required. > > IANA would need to assign a new "type" for each new addressing sub- > > scheme. With the current allocations, 5 more schemes are possible > > That's confusing. In your terminology, only two more types are > possible (10 and 11). Right. Fixed. > It would be simpler to simply define 3 type bits. The main constraint is that the original (zone scheme) tried to comply to the IPv6 address architecture by using a 64 bit interface identifier part. The same is now true of the manual addressing scheme that i added and i would like to keep it that way (to be on the safe side with IETF architectures). MichaelB came up with the zone address scheme and i already stole one bit from the zone-field to enable the manual addressing sub-scheme because i wanted to make sure that deployments can get started with using manual configured ACP connect interfaces without conflicting with later automatic assigned zones. I am quite unsure how important zones are. I do very much like the Vlong (was called V8 in -08) scheme because it allows a lot of internal address assignment within a node, which i think is more important for future work than Zones. But Vlong does not comply to the 64-bit interface identifier rule. If you want 3 type bits, we need to go to 12 subnet bits in the zone scheme and maybe 32/16 Device-ID in the Vlong scheme. I also would feel safer if we had more Type field options to explore/experiment, but i would like for more ANIMA participants to chime in. > A general remark: when a wider audience looks at this, there will > be complaints that we are re-creating classful addressing. I suggest > adding some text about this. (Along the lines of: it's true, and > here is why it doesn't matter.) I will certainl not mention that word in the document. Its like the courtroom: I do not want to open the door to that type of accusation by bringing up the word myself first ;-) Here is the paragraph i added at the beginning of 6.10.6 (other ACP addressing sub schemes): Before further addressing sub-schemes are defined, experience with the schemes defined here should be collected. The schemes defined in this document have been devised to allow hopefully sufficiently flexible setup of ACPs for a variety of situation. These reasons also lead to the fairly liberal use of address space: The Zone addressing sub-schemes is intended to enable optimized routing in large networks by reserving bits for zones. The Vlong addressing sub-scheme enables the allocation of 8/16 bit of addresses inside individual ACP nodes. Both address spaces allow distributed, uncoordinated allocation of node addresses by reserving bits for the Registrar-ID field in the address. > > Every ACP device (RPL node) announces an IPv7 prefix > > Forward into the future! ;-) > > 6.12.4. ACP interfaces > ... > > These packets are of course redundant (unnecessary) and would be > > discarded by GRASP on receipt as duplicates. > > ...by use of the GRASP Session ID. ack. > > 7.2. How (per L2 port DULL GRASP) > ... > > L3/L2 devices SHOULD support per-L2 port ACP. > > Clarify that ACP (and GRASP) capable devices do > not need to depend on MLD snooping, since they > catch LL multicasts directly per port. But non-ACP > switches MUST either support MLDv2 snooping or > operate as pure L2 bridges for all multicast > packets. acp-10, added to 6.3: Note that the use of the IPv6 link-local multicast address (ALL_GRASP_NEIGHBORS) implies the need to use MLD () to announce the desire to receive packets for that address. Otherwise DULL GRASP could fail to operate correctly in the presence of MLD snooping, non-ACP enabled L2 switches - because those would stop forwarding DULL GRASP packets. Switches not supporting MLD snooping simply need to operate as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. Its a common oversight of pretty much every protocol RFC i know thats using link-local scope multicast to NOT mention the need to use IGMP/MLD. In IPv4 it was unclear whether it was necessary to do this for link-local scope addresses and in result, no sane IGMP snooping switch would ever try to constrain link-local messages. I am 100% sure we did make it mandatory in IPv6 to announce membership for link-local addresses, even though i can not find a line in RFC3810 to that end right now. Anyhow, better be safe than sorry (should have gone into GRASP RFC though, oh well.. too late). For 7.2 i added: If the device with L2 ports is supporting per L2 port ACP DULL GRASP as well as MLD snooping (), then MLD snooping must be changed to never forward packets for ALL_GRASP_NEIGHBORS because that would cause the problem that per L2 port ACP DULL GRASP is meant to overcome (forwarding DULL GRASP packets across L2 ports). > Also, is there anything to say here about VLANs? Nothing special comes to mind... Not that i'd be trying hard ;-) > > 11. Security Considerations > > I think you need to insert cross-references to > various security discussions elswhere in the draft. Ok. Probably not complete, but i added 6 hopefully good paragraphs with pointers to make security reviewers happy. > > > 12. IANA Considerations > > TBD! Yes, from above. > Nits: > ----- > > > 2. Terminology > ... > > ACP VRF The ACP is modelled in this document as a "Virtual Routing > > and Forwarding" (VRF) component in a network device. > > I suggest listing this alphabetically as VRF, not under A. ack > > AN "Autonomic Network". A network according to > > [I-D.ietf-anima-reference-model]. Its main components are Intent, > > Autonomic Functions and ANI. > > I find the second sentence doesn't help, especially by referring to Intent. Any better idea ? Right now i just added a definition for Intent: Northbound operator and automation facing interface of an Autonomic Network according to . For me it's important that readers of the ACP document know the simple distinction between ANI and AN: AN = ANI + autonomic-functions + intent. That makes it difficult not to mention intent. Of course, anything related to intent is fuzzy, but thats an IETF ANIMA charter issue ;-) > ** The document seems to lack a both a reference to RFC 2119 and the > recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 > keywords. > > == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', > or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please > use uppercase 'NOT' together with RFC 2119 keywords (if that is what you > mean). Ok, i just stole the boilerplate from GRASP. > > Regards > Brian > ============ original mail from Brian appended =============================== >From brian.e.carpenter@gmail.com Wed Aug 2 04:39:14 2017 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on faui40.informatik.uni-erlangen.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIM_SIGNED=0.1, DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,RCVD_IN_DNSWL_MED=-2.3 autolearn=disabled version=3.4.0 X-Original-To: eckert+ietf@i4.informatik.uni-erlangen.de Delivered-To: eckert+ietf@i4.informatik.uni-erlangen.de Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id D124F58C4E1 for ; Wed, 2 Aug 2017 04:39:14 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 0F2DF74D0F2 for ; Wed, 2 Aug 2017 04:39:12 +0200 (CEST) Received: by ietfa.amsl.com (Postfix, from userid 65534) id 77B18120724; Tue, 1 Aug 2017 19:39:10 -0700 (PDT) X-Original-To: xfilter-draft-ietf-anima-autonomic-control-plane@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-anima-autonomic-control-plane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42928127B60; Tue, 1 Aug 2017 19:39:10 -0700 (PDT) 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 yquVlTbL3oSY; Tue, 1 Aug 2017 19:39:08 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15BC120724; Tue, 1 Aug 2017 19:39:04 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id l64so15274325pge.5; Tue, 01 Aug 2017 19:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OpTTtKELwWT6v6Ga6LK8VwNhfPuXRL+U5tBH/U/5t0s=; b=ZA9L2k91LQsUZEJPf9U3r31Vsaqbs11DN5C6TJFc2ja/Ke/AF0eF3x8Xjm8MB+uc2j HbVEFCyVc/d3GS8Hzdcr8/qbFKO7ccCOI8xBQqQ4ZiZUXt6/A/TF9LmHYnLx+i77jNxQ +E9XIOS2fviooEIu+9lgHe9Ff2DrkR1dqQm7lcNPJiLa3vo518Fs1dEKF+g59frb82oV pogn+PGZWpVWVDGSNPB6ttSjJ0bQQ5qMFZT0UJh8q172UTHQ85tSRvlTnfzJhFYTqkhq cPuD3wgluYxPhrWKhPCP7Gy8VqIQDT6HYFCX71zLUxeE/2GEZwvzkfOxbJcj9l2Ozpw3 /Q/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OpTTtKELwWT6v6Ga6LK8VwNhfPuXRL+U5tBH/U/5t0s=; b=rJJFHIqQDiUlG9VObY1FWTxsxex3gzkM2uM/31TAoVVWBzX2hnpBk5wgsxanGoMSl/ S5JYvWUTDnBY9n/WK7swXgsixIQfM+r2OuKMNen/6sQnJKhLKjYAaPJpzDqa2nQRpdkp v6ojSFlvNKKRLYVSfGoDZqgqYMDf8m3Ds7g0WhRKUNqm3lECuufBNGXie2gB1y+h6U1r sQNU2fyIQM6J9djqAdMYEGdM7/XX34LR4wdEW4gI5jtKlkmeiAIx/QbCSm/nBpFBHsCH XhJsiHt0PiEIJXg0eQFkhn9t6pQDsE9YfcUkFBf6R696NzuPm/Pc89aEmBGTV1LiI2+B NA/w== X-Gm-Message-State: AIVw110KyAWhsLqjmKfHmNcxin3y23sYyEAeGHbDEuEir6RRFgAxVCm2 X8pf/ISgJ4N0xLnM X-Received: by 10.84.210.203 with SMTP id a69mr23091589pli.397.1501641543965; Tue, 01 Aug 2017 19:39:03 -0700 (PDT) Received: from [130.216.38.9] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.9]) by smtp.gmail.com with ESMTPSA id n19sm23178838pfi.35.2017.08.01.19.39.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 19:39:03 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt To: draft-ietf-anima-autonomic-control-plane@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Cc: anima@ietf.org Message-ID: Date: Wed, 2 Aug 2017 14:39:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150044138257.25233.12391471568614147773@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Resent-From: Resent-To: Michael.H.Behringer@gmail.com, tte+ietf@cs.fau.de, sbjarnason@arbor.net Resent-Message-Id: <20170802023910.77B18120724@ietfa.amsl.com> Resent-Date: Tue, 1 Aug 2017 19:39:10 -0700 (PDT) X-Virus-Scanned: clamav-milter 0.99.2 at faui45 X-Virus-Status: Clean Status: RO Content-Length: 12076 Lines: 342 Hi, Here are my comments on ACP version -08. First the ones I rank as substantive isssues, then a few nits. Issues: ------- > 2. Terminology ... > ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 > addresses. ACP addresses are ULA. No, they are *not* equivalent to RFC1918, because those are ambiguous and ULAs are not. Please avoid controversy, just cite RFC4193. > 3.2. Secure Bootstrap over an Unconfigured Network ... > ...This does not require any configuration > on intermediate nodes, because they can communicate through the ACP. s/they can communicate/they can communicate securely/ > 4. Requirements ... > ACP4: The ACP MUST be generic. Usable by all the functions and > protocols of the AN infrastructure. It MUST NOT be tied to a > particular protocol. I'm not sure what the last sentence is saying. Do you mean "MUST NOT be tied to a particular transport protocol" or "MUST NOT be tied to a particular security protocol"? Or do you mean "MUST NOT restrict the choice of upper layer protocol"? Or do you simply mean "MUST provide a generic IPv6 service"? Also, there's no requirement about performance or the expected traffic density. Should we say something either in the Requirements section or in the Notes in the Overview section? I assume that performance is not critical and ACP traffic density is expected to be low. > 5. Overview ... > Default policy is: To all adjacent nodes in the > same domain. I know this is explained later, but I think both "adjacent" and "domain" need some qualification. For example: Default policy is: To all adjacent link-layer autonomic nodes in the same autonomic domain. ... > 5. Inside the ACP VRF, each node sets up a virtual (loopback) > interface with its ULA IPv6 address. I think we have cases where a node has multiple ULAs. > 6.1. Domain Certificate > > To establish an ACP securely, an ACP device MUST have a globally > unique domain certificate (LDevID),... You need a normative reference for the LDevID format. > 6.1.1. ACP information > > The domain certificate (LDevID) of an autonomic node MUST contain ACP > specific information, specifically the domain name, the address of > the device in the ACP with the Zone-ID set to zero ("ACP address"). You need a cross-reference for Zone-ID, which is undefined at this point. ... > anima.acp+{+{+}}@ What notation is that? Is {} supposed to be an optional item? If so, why not use [] as in ABNF, and cite ABNF. > is used to indicate... Is that required to respect DNS syntax? If so, please say so. > {.} That's wrong. is preceded by "@" in your syntax, and in your example, the dot is in the element "area51.research". Is there a length limit on the rfc822Name ? > 6.1.2. Maintenance As Michael R said, all the stuff about the registrar should be in BRSKI, not duplicated here. In fact, it's very confusing to have it here. If we want a cert renewal mechanism, surely that's part of BRSKI? [One detail however: > The loop-count MUST be sete to 255. When an ACP node > receives the M_FLOOD, it will have been reduced by the number of hops > from the EST server. I don't like that. The role of the loop count is loop prevention, so it should be set to a reasonable upper bound on the "radius" of the network. GRASP has two measures for loop detection, this one and detection of duplicate session IDs, but that was intentional redundancy.] > 6.2. AN Adjacency Table > > To know to which nodes to establish an ACP channel, every autonomic > node maintains an adjacency table. The adjacency table contains > information about adjacent autonomic nodes, at a minimum: node-ID, IP > address, domain, certificate. Please specify which IP address(es) you mean. Link-Local, ACP Address(es), or both? Can you also indicate that an API to this table is needed (at least by the GRASP core, and possibly by any ASA that wants to make direct use of the ACP)? > 6.3. Neighbor Discovery with DULL GRASP ... > [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1, > ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"], > [O_IPv6_LOCATOR, > h'fe80000000000000c0011001FEEF0000, UDP, 15000] > ] Once we are fully settled on this I can generate an example and its binary value for complete clarity. I have one comment which is that when I last updated draft-carpenter-anima-ani-objectives, I replaced "SYNCH-FLAG" with "5" (the actual value of the flag byte) - otherwise you have to define SYNCH-FLAG. Actually the value 5 indicates discovery+synchronization; everything should work just the same if it was 4 (synchronization alone), since it's flooded. I don't know if we care about that difference. ... > The ttl and loop-count are fixed at 1 since this is a link-local > operation. No, the ttl is milliseconds - the valid lifetime of the flood. You have that correct in your version of AN_join_registrar. > 6.8.2. ACP as the Security and Transport substrate for GRASP ... > GRASP inside the ACP uses link-local UDP IPv6 multicast across the > ACP virtual interfaces for GRASP neighbor discovery... and flooding Also, you might want to add a reminder that GRASP does its own relaying of multicast packets between interfaces; the ACP is not required to provide multicast routing. > ...and IPv6 over TLS > across the ACP virtual interfaces for any of its unicast messages. Wait, what are you saying here? Do you really mean IPv6 over TLS, or TLS over TCP over IPv6? As Eric Rescorla asked us at one point, please draw a ladder diagram of the protocol stack. ... > TLS is mandated for GRASP because the ACP secure channel mandatory > authentication and encryption protects only against attacks from the > outside but not against attacks from the inside - compromised ACP > members I think the threat model really needs a clearer explanation. I assume that Bob and Alice are good guys, and Eve is a malicious ACP member. So a packet from Alice to Bob is encrypted from Alice to Eve, decrypted by Eve, then encrypted from Eve to Bob. So Eve can do what she wants with the decrypted packet. Now, who does the TLS wrapping? Will that be done by the ACP, or by the GRASP core? If the latter, you still need to explain how the ACP conveys the cert information to GRASP. > 6.10.1. Fundamental Concepts of Autonomic Addressing ... > o Addresses in the ACP are permanent, and do not support temporary > addresses as defined in [RFC4941]. Add something like: o Addresses in the ACP are not considered sensitive on privacy grounds, so do not need to be pseudo-random as discussed in [RFC7721]. (You probably also need to discuss why the ACP is not subject to scanning attacks: because ULAs are not propagated across domain boundaries.) > 6.10.2. The ACP Addressing Base Scheme > > The Base ULA addressing scheme for autonomic nodes has the following > format: > > 8 40 2 78 > +--+-----------------+------+------------------------------------------+ > |FD| hash(subdomain) | Type | (sub-scheme) | > +--+-----------------+------+------------------------------------------+ > > Figure 2: ACP Addressing Base Scheme > > The first 48 bits follow the ULA scheme, as defined in [RFC4193], to > which a type field is added: > > o "FD" identifies a locally defined ULA address. For the Nth time, please s/FD/fd/ as required by RFC5952 > > o Type: This field allows different address sub-schemes in the > future. The goal is to start with a single sub-schemes, but to > allow for extensions later if and when required. This addresses > the "upgradability" requirement. Assignment of types for this > field should be maintained by IANA. You need to write precise directions to IANA. > 6.10.3. ACP Zone Addressing Sub-Scheme > > The sub-scheme defined here is defined by the Type value 0 (zero) in > the base scheme. > > 51 1 13 63 1 > +---------------------+---+---------+-----------------------------+---+ > | (base scheme) | Z | Zone-ID | Device-ID | V | > | | | | Registrar-ID | Device-Number| | > +---------------------+---+---------+--------------+--------------+---+ > 48 15 s/51/50/ Although I think it would be simpler to do this: 48 2 1 13 63 1 +----------------+----+---+---------+-----------------------------+---+ | ULA prefix |Type| Z | Zone-ID | Device-ID | V | | | 00 | | | Registrar-ID | Device-Number| | +----------------+----+---+---------+--------------+--------------+---+ 48 15 > > 6.10.4. ACP V8 Addressing Sub-Scheme > > The sub-scheme defined here is defined by the Type value 1 (one) in > the base scheme. > > 51 63 8 > +---------------------+-----------------------------+----------+ > | (base scheme) | Device-ID | V | > | | Registrar-ID | Device-Number| | > +---------------------+--------------+--------------+----------+ > 46 32 Same comments. > 6.10.5. Other ACP Addressing Sub-Schemes > > Other ACP addressing sub-schemes can be defined if and when required. > IANA would need to assign a new "type" for each new addressing sub- > scheme. With the current allocations, 5 more schemes are possible That's confusing. In your terminology, only two more types are possible (10 and 11). It would be simpler to simply define 3 type bits. A general remark: when a wider audience looks at this, there will be complaints that we are re-creating classful addressing. I suggest adding some text about this. (Along the lines of: it's true, and here is why it doesn't matter.) > Every ACP device (RPL node) announces an IPv7 prefix Forward into the future! > 6.12.4. ACP interfaces ... > These packets are of course redundant (unnecessary) and would be > discarded by GRASP on receipt as duplicates. ...by use of the GRASP Session ID. > 7.2. How (per L2 port DULL GRASP) ... > L3/L2 devices SHOULD support per-L2 port ACP. Clarify that ACP (and GRASP) capable devices do not need to depend on MLD snooping, since they catch LL multicasts directly per port. But non-ACP switches MUST either support MLDv2 snooping or operate as pure L2 bridges for all multicast packets. Also, is there anything to say here about VLANs? > 11. Security Considerations I think you need to insert cross-references to various security discussions elswhere in the draft. > 12. IANA Considerations TBD! Nits: ----- > 2. Terminology ... > ACP VRF The ACP is modelled in this document as a "Virtual Routing > and Forwarding" (VRF) component in a network device. I suggest listing this alphabetically as VRF, not under A. > AN "Autonomic Network". A network according to > [I-D.ietf-anima-reference-model]. Its main components are Intent, > Autonomic Functions and ANI. I find the second sentence doesn't help, especially by referring to Intent. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Regards Brian From nobody Sun Sep 17 23:07:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8CC126C19; Sun, 17 Sep 2017 23:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlD_uqa97Fv6; Sun, 17 Sep 2017 23:07:43 -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 38143133059; Sun, 17 Sep 2017 23:07:40 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1C5AC58C4B7; Mon, 18 Sep 2017 08:07:36 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 02A74B0CC08; Mon, 18 Sep 2017 08:07:35 +0200 (CEST) Date: Mon, 18 Sep 2017 08:07:35 +0200 From: Toerless Eckert To: Sheng Jiang Cc: "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane.authors@ietf.org" , "anima-chairs@ietf.org" Message-ID: <20170918060735.GD31832@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CE86398@NKGEML515-MBX.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B927CE869BC@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE869BC@NKGEML515-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Review on draft-ietf-anima-autonomic-control-plane-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 06:07:45 -0000 Thanks Sheng, Sorry for the delay, i was working through my queue in order. See prior reply to Brians review for which i just posted acp-10. Your review is now top of queue for me and i will quickly triangulate your -09 comments with -10 and work in your comments for -11. Cheers Toeress On Fri, Sep 01, 2017 at 01:21:25AM +0000, Sheng Jiang wrote: > Somehow, I don't know how, I misspelled the name of the draft. Resend my review comments with the right name in title and to the right authors alias. > > Sheng > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: Thursday, August 31, 2017 7:01 PM > To: anima@ietf.org > Cc: draft-ietf-anima-auotnomic-data-plane.authors@ietf.org > Subject: [Anima] Review on draft-ietf-anima-auotnomic-data-plane-09 > > > Hi, authors of draft-ietf-anima-auotnomic-data-plane, > > > > I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. This is a petty long document. Therefore, my review may be a little bit disordered. Overall, I think this document has been in a good sharp although I cannot claim all my comments are minor. I believe they are not difficult to address. > > > In introduction section, it is better to reference the "Autonomic Control Plane" definition & description in Section 5 of RFC7575, rather than "[RFC7575] calls it the 'Autonomic Control Plane'" . > > > > The ACP could actually be communication channel for both management and control plane. So, the name seems be mis-leading. My understanding is that we could not change the name in such late stage. But it worth to see more on this in the introduction, even in the abstract. > > > > "This document describes options for a ... ACP". I am confused by the word "option". What option does it actually mean? At least, it is not clear from the context. > > > > "It therefore remains operational even in...". My understanding for "it" is the network, but from the context, my first expression for "it" is ACP. > > > > Used short for the first appearance, ANI, VRF, IKE, TLS/dTLS, SDN, NOC, OAM, NMS, CA and although GRASP, BRSKI, EST, ULA, are defined in Section 2, but their first appearance is before their terminologies. > > > > Section 2, > > > > "ACP provides secure zero-touch network wide IPv6 connectivity between devices supporting it." This is not accurate. These two devices must be in the same autonomic network. Actually, we did not define an important concept yet - the domain of autonomic network. We were always assume there is only one domain within the connectivity range or the autonomic network would naturally be separated by non-AN devices. But it would not always be the case if AN technologies become widely deployed > > > > In Section 3, > > > > "certain AAA misconfigurations can lock an administrator out of a device", I am not sure how ACP helps in this use case. It seems for me the only way is to log in with another admin account, then change the misconfig. It is no different through normal data plane. This can still be recovered remotely without ACP. > > > > "The ACP provides reachability that is largely independent of the data plane." Why "largely"? It implies that is still partially (maybe small proportion) dependent on the data plane. > > > > "ACP MUST NOT be tied to a particular protocol." ACP does need support from some specific protocol, GRASP, IPv6. I am sure you did not mean them. But the description should be improved to be more precise. > > > > "The ACP MUST provide security". I am not sure the "MUST". In many scenarios, for example, some layer has very strong layer 2 security mechanism, or network with physics isolation/protection. The connectivity is the vital functionality that ACP could provide, while security provided by ACP is redundant or not necessary. > > > > "The default mode of operation of the ACP is hop-by-hop." I guess you mean "basic" or "fundamental" rather than "default". The multiple connectivity is made up by hop-by-hop connections. > > > > " ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 addresses. ACP addresses are ULA."Please don't consider ULA as an equivalent to RFC1918. We used to have relevant discussion in v6ops WG, and people had strong consensus on ULAs != RFC1918. (see https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02#section-3.1) > > > > The content of section 3.3 reads like the essential benefit rather than a specific use case, especially comparing to Section 3.1 and 3.2. More proper place for this may be Section 9 (Benefits). > > > > "ACP loopback interface" and "ACP virtual interface" refer to different things as defined in the Terminology section. However, in the main text, sometimes they are mixed together ((E.g. in section 5, Item 5 and 6). Either they should be used in a canonical way in this document, or other more distinguished terminologies should be used to refer the two things. > > > > The terminology "ACP connect" same not proper. It would be more proper to call the connect/channel for non-ACP device joining the ACP through an ACP device "ACP bridge"? > > > > In section 6, > > > > Initially, it must have a ... as well as an adjacency table."The word here is misleading. The authors should mean the functionality of an adjacency table. But it reads like an adjacency table with already learned neighbor information. > > > > Inadvert -> inadvertent > > > > The term "Autonomic Domain" first appears at section 6.1, it should be defined in section 3. > > > > acp-address within ACP information should be optional. It may be the address is generated by AN after getting the domain certificate. > > > > It is worthy to clarify that although the LDevID contains ACP-information, it is not specific for ACP only; it is generic for other functions that request node-level authentication. > > > > "To establish an ACP securely, an ACP device MUST have a globally unique domain certificate (LDevID)"I think the requirement in this sentence is too strong in two perspective: why globally unique, secondly it is not necessary to be a domain certificate that newly assigned in this domain. Furthermore, this seems imply ACP depend on BRSKI as pre-step, which I don't think is in authors original meaning. > > > > "The ACP network MUST have one or more nodes that support EST server through which ACP nodes can renew their domain certificate." The work "MUST" is far too strong here. > > > > "it should choose am FQDN" -> it should choose "an" FQDN > > > > "The format of the rfc822Name is choosen" -> The format of the rfc822Name is "chosen". There are another 4 instance of "choosen". > > > > "The loop-count MUST be sete to 255" -> The loop-count MUST be "set" to 255 > > > > "When it is time for domain certificate reneal" -> When it is time for domain certificate "renewal" > > > > "the primarily imiting factor for shorter certificate lifetimes", my guess is "limiting" > > > > "the assigning CA has enough performance" -> the assigning CA has enough "performance" > > > > "See Section 10.1 for further optimizationss" -> See Section 10.1 for further "optimizations" > > > > The first sentence of section 6.3, "Because of the the considerations", the second "the"should be deleted > > > > "ACP discovery MUST NOT be enabled by default on any non-physical interfaces." This seems rule out the possibility of applying ACP with virtual devices. My suggestion would be deleted the sentence since we ready have the follow up sentence "ACP discovery MUST NOT run inside the ACP." Or not deleting, we should at least soften it to be "SHOULD NOT". > > > > Section 6.5, > > > > "the next step after discoving" -> the next step after "discovering" > > > > "The roles of Bob abd Alice" -> The roles of Bob "and" Alice > > > > "It is not up to Alice to devide" -> It is not up to Alice to "divide" > > > > "interfaces are the ame devices" -> interfaces are the "same" devices > > > > Section 6.6, > > > > "certificate must be valid occording to"-> certificate must be valid "according" to > > > > Section 6.7, > > > > "the ACP secure channel protocol" -> the ACP secure channel "protocol" > > > > "ACP mechanisms they support" -> ACP mechanisms they "support" > > > > "ACP secure channel MUST imediately be terminated" -> ACP secure channel MUST "immediately" be terminated > > > > "Note that is is not standard behavior" -> Note that is not standard behavior > > > > Section 6.8, > > > > "Authentication is via the the domain" -> Authentication is via the domain > > > > Section 6.10, > > > > "65536 different virtualized adddresses" -> 65536 different virtualized "addresses" > > > > Section 6.11, > > > > on-RPL-aware leafs (or "Internet") accoding to -> on-RPL-aware leafs (or "Internet") "according" to > > > > "the ACP will only accommodate" -> the ACP will only "accommodate" > > > > Routeable - > routable; at least two instances > > > > "The multi-access ACP virtual interace" -> The multi-access ACP virtual "interface" > > > > Thanks for your hand work and good contribution to the ANIMA group. > > > > Regards, > > > > Sheng -- --- tte@cs.fau.de From nobody Mon Sep 18 02:29:41 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD4F126B6E; Mon, 18 Sep 2017 02:29:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150572698013.29085.899210515452747331.idtracker@ietfa.amsl.com> Date: Mon, 18 Sep 2017 02:29:40 -0700 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 100 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 09:29:40 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf Third Priority: cfrg saag intarea opsarea People who must be present: Toerless Eckert Sheng Jiang Terry Manderson Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Mon Sep 18 13:12:03 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400321321A4 for ; Mon, 18 Sep 2017 13:12:02 -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 JkQ6KPaFXxoB for ; Mon, 18 Sep 2017 13:12:00 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEF912421A for ; Mon, 18 Sep 2017 13:12:00 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id m30so747743pgn.6 for ; Mon, 18 Sep 2017 13:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uC0AyEVF6jKncpmxGH5/Ytpk28ef+95/MoVXjnRio3c=; b=KwTWmiyVH2/6hZXg2rX6PRvwjXFYdBOnnoqe+EDwCXVJFL1E1NVXMrz5NSBfBzSO10 y2KGW79l8mRMTymfpobB111FpQHGOBBEXgpmK1Gc5qB7tTMxyFvSLvx/d1RHZQyz+Zah sHKnzCaaap0hmnIKh4AfPiRbqu9Sajo3dgerYUtHn5VHuvQHN/GloTSl28W77uaEUcQq y3Yp/7ukRYlev/sFZG2N97trTo69ipZIK5N47q+VLBttUkr76dpSYy7/y6xMuTgsBQFt nEmZzpw34rsBl4TtfM4tvON7m5h+2vbOJDGykotAgTurCbbHh+YfgbOevgYEXDU40ka9 aQMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uC0AyEVF6jKncpmxGH5/Ytpk28ef+95/MoVXjnRio3c=; b=gGQuJEIwMRQgd0G4O09AOLXbeOlIZHTd1ToKRHUxOswmJRUGMsfdZafZvgTIzBy0P5 JIw0Wn1dRnWsR+VcM+C2wV1zw03iXHCQTRx9m3LRRdDqAK3z7sPLibvSe3XA8FuffbH1 qOcgFGL4Lu49+VgrSiOxd7P6zdO42XI/GBvyquIzpuXnfq9o6TEBGN0iwtQHX8Ge9Laj G8EMjwmYiUsjerotTY+tk1IHRIYPKz1xBXK23CpFcrUShOqZ+ZmlqRYNaNWZCvVuV9HP o2LND5tJ0/09NyEalt8K8/gBEJz/669ZYvwYZWVl3yIoJfg+t7Q8ErP3dgMRdKkVy3fw QUgw== X-Gm-Message-State: AHPjjUhNbfvDJmGj4SeTI0bteu0iSae5WK0gQu1DamsW2uSNghw3D4aj yrIDH+6//OStEIF/ X-Google-Smtp-Source: ADKCNb7giQedv99f2Br9WELVZerp3ejj74avDjpPlD2DTDMdoaph1jBmcsiu6zUTFHnfU8S2i+oAmQ== X-Received: by 10.98.61.142 with SMTP id x14mr33440665pfj.258.1505765518559; Mon, 18 Sep 2017 13:11:58 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v10sm237843pgf.8.2017.09.18.13.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 13:11:57 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com> Date: Tue, 19 Sep 2017 08:11:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:12:02 -0000 This is embarassing. For some reason I completely missed the announcement of draft-ietf-anima-stable-connectivity-05, until today. I have now looked at the -05 and -06 versions and I'm happy with the result. Regards Brian On 18/09/2017 17:38, Toerless Eckert wrote: > Thanks, Brian: > > The "OLD" paragraph you list was from -04. After your review i had already > changed this in -05 to > > NEW: > > To connect IPv4 only management plane devices/applications with the > ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is > necessary. The basic mechanisms for this are defined in SIIT > ([RFC7915]). There are multiple solutions using this mechanisms. To > understand the possible solutions, we consider the requirements: > .... > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt > > I also did spend a good amount of time because of your -04 review and prior > request by mohammed to detail in the following parapgraphs the possible > options in more detail. That text leverages the 'SIIT' term and > discusses the EAM solutions (RFC7757 is best). > > Given how this is an informational OPS document, > i think it is helpfull to elaborate on the understood details of > requirements and how known current solutions fit them. > > The fact that none of the > currently defined NAT solutions provides for the most simple possible > configuration (aka: minimum number of prefix EAM's to configure) is > also IMHO a perfectly valid outcome for an OPS document. > > It could mean that users will simply accept the need for longer mnaual > NAT config (long list of 1:1 mappings) or vendors implement a proprietary > EAM (explicit address mapping) CLI to make it simpler. Or users will > move faster to IPv6 on the NOC ;-) > > So, for the time being, i just commited -06 with the second fix. > > Let me know what you folks think about WG last call status of > the stable connectivity draft. > > Cheers > Toerless > > On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote: >> To cut a long story short, here's a friendly suggestion. The goal is to avoid >> comments during IETF/IESG review that the NAT text is too vague: >> >> OLD >> To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 >> NAT can be used. This NAT setup could for example be done in Rt1r1 >> in above picture to also support IPv4 only NMS hots connected to >> NOClan. >> >> NEW >> To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 >> translation [RFC 6145] could be used. This could for example be done in Rt1r1 >> in the above picture to also support IPv4-only NMS hosts connected to >> NOClan. Details of the address mapping to be used would depend on >> the exact scenario and are not specified here. >> >> And yes, I like this: >> >>> i'd suggest to replace the "split-horizon" sentence with: >>> >>> Operators may therefore need to use a private DNS setup for the ACP ULA >>> addresses. This is the same setup that would be necessary for using >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last >>> paragraph. In [RFC6950] section 4, these setups are discussed in more detail. >> >> Regards >> Brian >> >> On 15/09/2017 09:18, Toerless Eckert wrote: >>> >>> Hi Brian, >>> >>> Sorry, for the delay. I have not sen further feedback on stable-connectivity-05 >>> bside this mail of yours. See answers below, let me know if you want me to rev >>> with the one possible textual improvement or if we think -05 is good enough. >>> >>> Cheers >>> Toerless >>> >>> On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: >>>> I'm just coming back on a couple of points. Generally -05 is almost there... >>>> >>>>> See the rewritten SIIT section. IMHO, there can be no simpler "network" based >>>>> address translation. Where network based means that the translation happens >>>>> in some device he network operator needs to provision. Like the ACP edge device. >>>>> Or even an additional address translation device. >>>>> >>>>> So, the only IMHO easier option is when the OS of the NMS host would internally >>>>> have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. >>>> >>>> Yes, that is exactly the effect of 464XLAT in the end-system (not in the >>>> router). >>> >>> I found rfc6877 a confusing read, but from what i figure, it's not exactly what >>> i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable >>> IPv4 address, and that is something any device in the ACP does not have naturally. >>> (aka: NOC server as client connecting to ACP device, ACP device is server). >>> >>> If i already need to set up some other form of NAT to give an ACP device an outside IPv4 >>> address, then 464XLAT does not buy me any simplifications. >>> >>> I was rather thinking of taking the NAT network function that i was describing >>> and simply embody them in a set of linux NAT rules configured on on the NOC linux >>> system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme, >>> but just a way to avoid having to deal with the problem in the network (adding a NAT >>> device you would otherwise not need): >>> >>> Its a NMS host problme, deal with it in the NMS host. If you can not change the app, >>> let the OS do the NAT. Of course, this would not work for the poor customer who bought >>> a black-blox NMS soution which may run windows, or where you can not configure the >>> linux. Then again, nowadays, most NOC components should be software in VMs, and >>> for those, you should certainly be able to do the NAT in the vswitch of the server. >>> >>> In any case: my interest in expanding the NAT section further is quite limited. >>> The whole goal of the NAT section was to explain that you need 1:1 address mapping >>> and that you can hack this up in likely most available routers with NAT support, >>> but do not consider this to be a good long term solution but use it as a stopgap >>> to upgrade your NOC software to IPv6. >>> >>> No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-)) >>> >>> So, let me know if you feel strongly anything that should be added/modified to the >>> NAT section. >>> >>>>> Alas, i didn't have the time to investigate these options. And most likely if at >>>>> all you could only make those work for linux. >>>> >>>> Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they >>>> will all support IPv6 anyway? >>> >>> Lets hope so, yes. >>> >>>>> So, for now i just remove the note and clarified the last sentence a bit. >>>>> >>>>> If there is anything specific to be said bout why 464XLAT might be better >>>>> longer term, let me know and i can add it. For now it looks like yet another >>>>> network device configured option to me, but i have not tried to understand it >>>>> all the way. >>>> >>>> I think you'd need one of the 464XLAT authors to have a look at the scenario, >>>> because I don't claim to understand it all. >>> >>> Well, the analysis i made above (server must support IPv4 as stated in the RFC) >>> makes me discount it as a more beneficial option to mention. >>> >>>>>>> Using current registration options implies that there will not be >>>>>>> reverse DNS mapping for ACP addresses. >>>>>> >>>>>> Really? I assume we're talking about two-faced DNS, and afaik nothing >>>>>> stops an operator providing reverse mapping in the private DNS. >>>>>> That seems to be implied by the following paragraphs, so the text >>>>>> seems inconsistent anyway. >>>>> >>>>> I know it under the name "split-horizon DNS". Is there any reference ? >>>> >>>> The DNS community in the IETF hates split DNS so much that >>>> not much has been written about it. I did find these: >>>> https://tools.ietf.org/html/rfc6950#section-4 >>>> https://tools.ietf.org/html/rfc7157#section-6.3 >>>> https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens >>> >>> RFC1918 actually explains it succinctly without giving it a name. >>> RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-) >>> >>> So, let me know if you think it's worth creating another stable-connectivity rev, >>> i'd suggest to replace the "split-horizon" sentence with: >>> >>> Operators may therefore need to use a private DNS setup for the ACP ULA >>> addresses. This is the same setup that would be necessary for using >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last >>> paragraph. In [RFC6950] section 4, these setups are discussed in more detail. >>> >>> Cheers >>> Toerless >>> >>>> Regards, >>>> Brian >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Sep 19 07:31:29 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DCB13432B for ; Tue, 19 Sep 2017 07:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR1XPpnhIVXQ for ; Tue, 19 Sep 2017 07:31:24 -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 432311330B3 for ; Tue, 19 Sep 2017 07:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15248; q=dns/txt; s=iport; t=1505831484; x=1507041084; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vvuPBwPKDPvliOU0SNJMSMidEwwAVSowHBm+C8wQ6gw=; b=e5vZTCoVEgKcjgOyT+UmYLRaaRDdtaHVDlx/I40OQCcEtZUzZIgPrJk6 SRcvUcNyCohxrHkqdLJiTg9vHrnt/JhpY4eSr/mQM69afoWftxg8tmocR kK2IuKc9K1ZycywmjeKLb14vr8jtSGzxi/dUH4Krr8sTGeFzAprVAcMp3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQCXKcFZ/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26aF4F0liSCEgoYDYFcgzoCGoRAQBcBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQIBAQEhBA06CwULAgEGGgICHwcCAgIlCxUQAgQOBYorCBCNMJ1mg?= =?us-ascii?q?W06iyMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEOgh2CAoMzK4J9hGKDKS+CMQW?= =?us-ascii?q?KGIcbj1kCh1qDXIkeghOQZ4oBiwkCERkBgTgBIQMzgQ13FUkSAYU7gU52AQEDh?= =?us-ascii?q?ikrgQWBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="297339740" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 14:31:22 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8JEVMlb003761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 14:31:22 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 09:31:19 -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.1263.000; Tue, 19 Sep 2017 09:31:19 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: Kent Watsen , Anima WG Thread-Topic: resolving overload of pinnned-domain-cert field (was: Re: [Anima] PKCS7 certificate SignerData certificates) Thread-Index: AQHTMVP1odJBnoX0A0exraoi/Z6i0Q== Date: Tue, 19 Sep 2017 14:31:19 +0000 Message-ID: <6DF7C15A-45A8-42BD-BF77-B0FA0524780F@cisco.com> References: <4705.1504656568@obiwan.sandelman.ca> <27261.1504797560@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="utf-8" Content-ID: <4BC63A539122AF4E953D6735122C7219@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] resolving overload of pinnned-domain-cert field (was: Re: PKCS7 certificate SignerData certificates) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 14:31:28 -0000 DQpUaGVyZSB3ZXJlIHR3byBpc3N1ZXMsDQoNCmEpIFRoZSBwaW5uZWQtZG9tYWluLWNlcnQgd2Fz IHVzZWQgYXMgdGhlIE1BU0Egc3RhdGVtZW50IGZvciB0aGUgZG9tYWluIHJvb3QgY2VydGlmaWNh dGUgaW4gdm91Y2hlcnMgYnV0IG92ZXJsb2FkZWQgYXMgdGhlIFJlZ2lzdHJhciBjZXJ0aWZpY2F0 ZSBpbiB2b3VjaGVyIHJlcXVlc3RzLiBUaGlzIGNhdXNlZCBjb25mdXNpb24gYW5kIHRoZSBsYXRl c3QgdGV4dCBub3cgYWRkcyBhIOKAnHByb3hpbWl0eS1yZWdpc3RyYXItY2VydOKAnSB0bw0KdGhl IHZvdWNoZXIgcmVxdWVzdC4gDQoNCmIpIEVhY2ggb2YgdGhlc2UgZmllbGRzIGlzIGEgc2luZ2xl IGNlcnRpZmljYXRlIHdoaWxlIFBLSSBkaXNjdXNzaW9ucyBvZnRlbiBpbmNsdWRlIGNoYWlucy4g V2UgZGVjaWRlZCB0aGF0IGNvbnRpbnVpbmcgd2l0aCB0aGUgc2luZ2xlIGNlcnRpZmljYXRlIGFw cHJvYWNoIGlzIHZhbGlkIGFuZCBhcmUgbm90IHRyYW5zaXRpb25pbmcgdG8gZ3JlYXRlciBQS0kg aW50ZWdyYXRpb25zLiBObyBjaGFuZ2UuDQoNClRoZSBwdWxsIHJlcXVlc3QgZml4aW5nIHRoZXNl IHR3byB3YXMgbWVyZ2VkIHdpdGggdGhpcyBjb21taXQ6DQoJaHR0cHM6Ly9naXRodWIuY29tL2Fu aW1hLXdnL2FuaW1hLWJvb3RzdHJhcC9jb21taXQvNGM0ZWVlNjdjYjM2N2ZhYWNjOTc2YmNlMDAy MDgzMGE5ZGFlYTliZg0KDQpjKSBUaGVyZSB3YXMgYSBjdXQvcGFzdGUgZXJyb3IgaW4gdGhlIGxh bmd1YWdlIGFyb3VuZCBwa2NzNyBzaWduYXR1cmVzIChyZWdhcmRpbmcgd2hvIHNpZ25zIHRoZW0p IHRoYXQgd2FzIGZpeGVkIHdpdGggdGhpcyBjb21taXQ6DQoJaHR0cHM6Ly9naXRodWIuY29tL2Fu aW1hLXdnL2FuaW1hLWJvb3RzdHJhcC9jb21taXQvZDhhZWZmNTNmZDA0OGMwN2NlYmNjODg4Mjg1 NThjNmJhZmMxNzlkZg0KDQoNCi0gbWF4DQoNCg0KPiBPbiBTZXAgOCwgMjAxNywgYXQgMzoyNCBQ TSwgTWF4IFByaXRpa2luIChwcml0aWtpbikgPHByaXRpa2luQGNpc2NvLmNvbT4gd3JvdGU6DQo+ IA0KPiBJ4oCZdmUgY29tbWVudGVkIGlubGluZSBhYm91dCB0aGVzZSBkaXNjdXNzaW9uLiANCj4g DQo+IEnigJl2ZSBhbHNvIHByZXBhcmVkIGEgc2V0IG9mIGRpZmZzIHRvIGhlbHAgYnJpbmcgY2xh cml0eSBhcyBwZXIgdGhlIGRpc2N1c3Npb24uIFRoZSBkaWZmcyBhcmUgaW4gdGhpcyBicmFuY2g6 DQo+IAlodHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvYW5pbWEtYm9vdHN0cmFwL2NvbW1pdC9i ZWM2ZDk3MjA3YWE4ZmFhYTYwMGQ2MDYyMmM5YjQ2NTBlZTA0OTM0DQo+IA0KPj4gT24gU2VwIDcs IDIwMTcsIGF0IDk6MTkgQU0sIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFu LmNhPiB3cm90ZToNCj4+IA0KPj4gDQo+PiBNYXggUHJpdGlraW4gKHByaXRpa2luKSA8cHJpdGlr aW5AY2lzY28uY29tPiB3cm90ZToNCj4+PiBUaGUgdm91Y2hlci1yZXF1ZXN0IGhhcyB0aGlzIGFk ZGl0aW9uYWwgcmVxdWlyZW1lbnQ6DQo+PiANCj4+PiBzMy4zIG9mIEJSU0tJLTA3LA0KPj4+IFRo ZSByZXF1ZXN0IGlzIGEgIllBTkctZGVmaW5lZCBKU09ODQo+Pj4gZG9jdW1lbnQgdGhhdCBoYXMg YmVlbiBzaWduZWQgdXNpbmcgYSBQS0NTIzcgc3RydWN0dXJlIiBhcw0KPj4+IGRlc2NyaWJlZCBp biBbSS1ELmlldGYtYW5pbWEtdm91Y2hlcl0gdXNpbmcgdGhlIEpTT04gZW5jb2RlZA0KPj4+IGRl c2NyaWJlZCBpbiBbUkZDNzk1MV0uICBUaGUgUmVnaXN0cmFyIE1VU1Qgc2lnbiB0aGUgcmVxdWVz dC4gIFRoZQ0KPj4+IGVudGlyZSBSZWdpc3RyYXIgY2VydGlmaWNhdGUgY2hhaW4sIHVwIHRvIGFu ZCBpbmNsdWRpbmcgdGhlIERvbWFpbg0KPj4+IENBLCBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBQ S0NTIzcgc3RydWN0dXJlLg0KPj4gDQo+PiBJIGZlZWwgZHVtYiwgYmVjYXVzZSBJIHdhcyBzdXJl IHRoYXQgSSBsb29rZWQgZm9yIHN1Y2ggYSBzZW50ZW5jZSwgYW5kIEkNCj4+IGRpZG4ndCBmaW5k IGl0LiAgR29vZCB0aGF0IGl0IGlzIHRoZXJlLg0KPj4gDQo+Pj4+IEluIGEgc2lnbmVkIHZvdWNo ZXIgcmVxdWVzdCBmcm9tIHRoZSBwbGVkZ2UgdG8gdGhlIHJlZ2lzdHJhciB0aGUNCj4+Pj4gcGlu bmVkLWRvbWFpbi1jZXJ0IGlzIHRoYXQgb2YgdGhlICpQTEVER0UqIChzaWduZWQgd2l0aCBpdCdz IElEZXZJRCkuDQo+PiANCj4+PiBBY3R1YWxseSB0aGlzIHBpbm5lZC1kb21haW4tY2VydCBpcyB0 aHVzLCBmcm9tIHMzLjIgb2YgQlJTS0ktMDcsDQo+PiANCj4+PiBwaW5uZWQtZG9tYWluLWNlcnQ6 ICBJbiBhIFBsZWRnZSB2b3VjaGVyIHJlcXVlc3QgdGhpcyBpcyB0aGUNCj4+PiBSZWdpc3RyYXIg Y2VydGlmaWNhdGUgYXMgZXh0cmFjdGVkIGZyb20gdGhlIFRMUyBoYW5kc2hha2UgKGZvcg0KPj4+ IGV4YW1wbGUgdGhlIGZpcnN0IGNlcnRpZmljYXRlIGluIHRoZSBUTFMgJ2NlcnRpZmljYXRlX2xp c3QnDQo+Pj4gc2VxdWVuY2UgKHNlZSBbUkZDNTI0Nl0pLiAgVGhpcyBNVVNUIGJlIHBvcHVsYXRl ZCBpbiBhIFBsZWRnZSdzDQo+Pj4gdm91Y2hlciByZXF1ZXN0IGlmIHRoZSAicHJveGltaXR5IiBh c3NlcnRpb24gaXMgcG9wdWxhdGVkLg0KPj4gDQo+PiBIdWgsIHRoaXMgaXMgYWN0dWFsbHkgc3Vy cHJpc2luZy4uLg0KPj4gSSBndWVzcyB3ZSBuZWVkIHRoZSBSZWdpc3RyYXIgdG8ga2VlcCB0aGUg c2FtZSB0aGluZyB0aGVyZSwgYW5kIHJlYWxseSB0aGUNCj4+IHZvdWNoZXIgKkhBUyogdG8gYmUg aXNzdWVkIGZvciB0aGlzIGtleSBpbiBvcmRlciBmb3IgdGhlIFBsZWRnZSB0byBnZXQgb3V0IG9m DQo+PiBwcm92aXNpb25hbCBzdGF0ZeKApg0KPiANCj4gVGhlIHJlZ2lzdHJhciDigJxrZWVwc+KA nSB0aGlzIGZpZWxkIGJ5IHBvcHVsYXRpbmcgdGhlIHByaW9yLXNpZ25lZC12b3VjaGVyLXJlcXVl c3QgKGFsc28gcHJlc2VydmluZyB0aGUgUGxlZGdlcyBzaWduYXR1cmUgb3ZlciB0aGUgcHJveGlt aXR5IGFzc2VydGlvbikuICANCj4gDQo+PiANCj4+PiBJIHdhcyB3b25kZXJpbmcgZWFybGllciB0 b2RheSBpZiB0aGlzIHdhcyBjb25mdXNpbmcuIFdlIGNvdWxkIGFkZCBhDQo+Pj4gbGVhZiBmb3Ig 4oCcdGxzLWRvbWFpbi1jZXJ04oCdIG9yIHNvbWV0aGluZy4gQW4gYWRkaXRpb25hbCBwb2ludCBp cyB0aGF0DQo+Pj4gdGhlICphc3N1bXB0aW9uKiBpcyB0aGF0IHRoaXMgaXMgdGhlIHNhbWUgY2Vy dCBhcyB0aGUgaWQta3AtY21jUkEgY2VydA0KPj4+IGluIHRoZSBjaGFpbiBkaXNjdXNzZWQgYWJv dmUgYW5kIGluIHMzLjMgYnV0IG1heWJlIHRoYXQgaXMgYW4NCj4+PiBhc3N1bXB0aW9uIHRvbyBm YXIgYW5kIHdlIHNob3VsZCBzdXBwb3J0IGJhZ3Mgb2YgY2VydHMgYW5kIGFyYml0cmFyeQ0KPj4+ IGNvbXBsZXhpdHk/IEnigJltIHRpcmVkIG9mIHRoaXMgUEtJIG1lc3MuDQo+PiANCj4+IFllcywg dGhhdCdzIGFuIGFzc3VtcHRpb24uDQo+PiBUaGUgKlZPVUNIRVIqIHRoYXQgcmVzdWx0cyBoYXMg dG8gbWF0Y2ggdGhlIGNlcnRpZmljYXRlIGluIHRoZSBUTFMuDQo+PiBTbyBpdCBtYWtlcyBzZW5z ZSBmb3IgdGhlIFBMRURHRSB0byBpbmRpY2F0ZSB3aGF0IGNlcnRpZmljYXRlIGl0IGlzDQo+PiBl eHBlY3RpbmcuDQo+PiANCj4+IFRoYXQgbGV0cyB0aGUgUmVnaXN0cmFyIGJlIGJ1aWx0IHVzaW5n IGEgdmFyaWV0eSBvZiBjZXJ0aWZpY2F0ZXMgZm9yDQo+PiBsb2FkIGJhbGFuY2luZyBwdXJwb3Nl cywgYW5kIGRlYWxzIHdpdGggYSByYWNlIGNvbmRpdGlvbiB0aGF0IGNvdWxkIG9jY3VyIGlmDQo+ PiB0aGUgUmVnaXN0cmFyJ3MgY2VydGlmaWNhdGUgaXMgcmVuZXdlZCBkdXJpbmcgdGhlIGltcHJp bnRpbmcgcHJvY2Vzcy4NCj4+IA0KPj4gSWYgYSBSZWdpc3RyYXIgd2FudHMvbmVlZHMgdG8gdXBk YXRlIGl0J3MgY21jUkEgY2VydCwgaXQgY291bGQgcHJlc2VudA0KPj4gdGhlIHByZXZpb3VzbHkg c2lnbmVkIHZvdWNoZXIgdG8gdGhlIE1BU0Egd2l0aCBwcmV2aW91c+KApg0KPiANCj4gVGhlcmUg YXJlIHR3byBwbGFjZXMgd2hlcmUgY29uc2lzdGVudCB1c2Ugb2YgUmVnaXN0cmFyIGNlcnQgb24g Ym90aCBsZWdzIGlzIHJlZmVyZW5jZWQuICANCj4gDQo+IEZpcnN0IEJSU0tJLTA4IHM0LjMgaW5k aWNhdGVzIHRoZSBNQVNBICJNQVkgdmVyaWZ54oCdIHRoZSBwbGVkZ2XigJlzIHByb3hpbWl0eSBh c3NlcnRpb24gaXMg4oCcY29uc2lzdGVudCB3aXRoIHRoZSBbUmVnaXN0cmFy4oCZcyBSZWdpc3Ry YXIncyAnVExTIGNsaWVudCBjZXJ0aWZpY2F0ZV3igJ0uIFRoZSBSZWdpc3RyYXLigJlzIFRMUyBj bGllbnQgY2VydGlmaWNhdGUgY2hhaW4gcm9vdCBjZXJ0aWZpY2F0ZSBpcyB0aGVuIHVzZWQgdG8g cG9wdWxhdGUgdGhlIOKAmHBpbm5lZC1kb21haW4tY2VydOKAmSAoZmluYWwgcGFyYWdyYXBoIHM0 LjMpLg0KPiANCj4gU2Vjb25kIEJSU0tJLTA4IHM0LjQgaW5kaWNhdGVzIGhvdyB0aGUgUGxlZGdl IGNvbXBsZXRlcyB0aGUgcHJvdmlzaW9uYWwgVExTIGF1dGhlbnRpY2F0aW9uOiAiVGhlICdwaW5u ZWQtZG9tYWluLWNlcnQnIGVsZW1lbnQgb2YgdGhlIHZvdWNoZXIgY29udGFpbnMgdGhlIGRvbWFp biBDQSdzIHB1YmxpYyBrZXkuIFRoZSBQbGVkZ2UgTVVTVCB1c2UgdGhlICdwaW5uZWQtZG9tYWlu LWNlcnQnIHRydXN0IGFuY2hvciB0byBpbW1lZGlhdGVseSBjb21wbGV0ZSBhdXRoZW50aWNhdGlv biBvZiB0aGUgcHJvdmlzaW9uYWwgVExTIGNvbm5lY3Rpb24uIg0KPiANCj4gVGhlIG5vcm1hdGl2 ZSBsYW5ndWFnZSBoZXJlIGFsbG93cyBmb3IgUGxlZGdlcyB0aGF0IGRvbuKAmXQgbWFrZSB0aGUg cHJveGltaXR5IGFzc2VydGlvbi4gVGhpcyBhbHNvIGFsbG93cyBhIFJlZ2lzdHJhciB0byBwcmVz ZW50IGEgY2VydCB0byB0aGUgUGxlZGdlIHRoYXQgaXMgKmRpZmZlcmVudCogdGhhbiB0aGUgY2Vy dCBpdCBwcmVzZW50cyB0byB0aGUgTUFTQTsgc28gbG9uZyBhcyB0aGV5IGFyZSBpc3N1ZWQgYnkg dGhlIHNhbWUgQ0EgYW5kIHNvIGxvbmcgYXMgdGhlIE1BU0EgYWxsb3dzIGZvciB0aGUgZGlzY3Jl cGFuY3kuIFdlICpjb3VsZCogc3RyZW5ndGhlbiB0aGlzIG5vcm1hdGl2ZSBzdGF0ZW1lbnQgbGlr ZSBzbzoNCj4gDQo+IAnigJxJZiB0aGUgUGxlZGdlIHByb3ZpZGVzIGEgcHJveGltaXR5IGFzc2Vy dGlvbiB0aGVuIHRoZSBNQVNBIE1VU1QgdmVyaWZ54oCm4oCdDQo+IA0KPiBUaGUgY3VycmVudCBs b2dpYyBpcyBzb2Z0ZXIgdG8gYWxsb3cgZm9yIG1vcmUgZmxleGliaWxpdHkgaW4gUGxlZGdlIGJl aGF2aW9yLiBTZWUgbXkgbmV4dCBjb21tZW50Og0KPiANCj4+Pj4gYSkgaXMgdGhhdCBjZXJ0aWZp Y2F0ZSBhbHNvIGluY2x1ZGVkIGluIHRoZSBQS0NTNyBiYWcgb2YgY2VydGlmaWNhdGVzPw0KPj4+ PiBJIHRoaW5rIHRoZSBhbnN3ZXIgU0hPVUxEIGJlIHllcy4NCj4+Pj4gYikgaXMgdGhlcmUgYW55 IG9wZXJhdGlvbmFsbHkgdmFsaWQgcmVhc29uIHdoeSB0aGVyZSBzaG91bGQgYmUgYWRkaXRpb25h bA0KPj4+PiBjZXJ0aWZpY2F0ZXMgaW4gdGhlIFBLQ1M3IGJhZz8NCj4+Pj4gSSBjYW4gbm90IGNv bWUgdXAgd2l0aCBvbmUuIFRoZSByZWdpc3RyYXIgaXMgbmV2ZXIgZ29pbmcgdG8gdmFsaWRhdGUN Cj4+Pj4gYW55IGNoYWluIHRoYXQgdGhlIG1hbnVmYWN0dXJlciBtaWdodCBoYXZlIHVzZWQgaW50 ZXJuYWxseSB0byBzZXQgdXANCj4+Pj4gdGhlaXIgQ0EgZm9yIHRoZWlyIElEZXZJRC4gIEl0IGNh cmVzIGFib3V0IHRoZSBlbmQtY2VydGlmaWNhdGUgb25seS4NCj4+IA0KPj4+IFRoZSByZWFzb24g czMuMy4gbWFuZGF0ZXMgdGhlIGVudGlyZSBjaGFpbiwgaW5jbHVkaW5nIHRoZSBkb21haW4gQ0EN Cj4+PiBjZXJ0aWZpY2F0ZSwgaXMgdG8gYWxsb3cgdGhlIGFib3ZlIGNvbnNpc3RlbmN5IGNoZWNr cy4gQnV0IG9yaWdpbmFsbHkNCj4+PiB0aGlzIHdhcyBzbyB0aGF0IHRoZSBkb21haW5DQSBjZXJ0 aWZpY2F0ZSB3b3VsZCBiZSB1c2VkIGZvciB0aGUgcGlubmVkDQo+Pj4gY2VydC4gTW92aW5nIHRv IGp1c3QgdGhlIFJBIGNlcnQgaW4gdGhlIHBpbm5lZC1kb21haW4tY2VydCBmaWVsZCB3b3VsZA0K Pj4+IGJlIGEgc2ltcGxpZmljYXRpb24/IFRoZSB0ZXh0IG9mIHRoZSB2b3VjaGVyLTA1IGxlYWYg ZGVzY3JpcHRpb24gc2VlbXMNCj4+PiB0byBhbGxvdyB0aGlzLg0KPj4gDQo+PiBJIHdvdWxkIGxp a2UgaXQgdG8gYmUganVzdCB0aGUgUkEgY2VydC4NCj4gDQo+IFdoZXJlIOKAnGp1c3QgdGhlIFJB IGNlcnTigJ0gaXMgYSBzaW1wbGlmaWNhdGlvbiwgdHJ1ZS4gSSB0aGluayB0aGUgY3VycmVudCBs YW5ndWFnZSBvZiB1c2luZyB0aGUgcGlubmVkLWRvbWFpbi1jZXJ0IHByb3ZpZGVzIGEgc2V0IG9m IGJlbmVmaXRzOg0KPiANCj4gCWEpIGFsbG93cyB0aGUgUkFzIHRvIGNoYW5nZSBjZXJ0cyBhcyBu ZWVkZWQgYmV0d2VlbiB2b3VjaGVyIHJlcXVlc3RzIGFuZCBkZXBsb3ltZW50cw0KPiAJYikgc2lt cGxpZmllcyBsb2cgdmVyaWZpY2F0aW9uIGFzIGl0cyBhbHdheXMgcm9vdCBDQSBjZXJ0cyBpbiB0 aGUgbG9nDQo+IAljKSBFbnN1cmVzIFBsZWRnZXMg4oCccGlu4oCdIGEgcm9vdCBjZXJ0IGluc3Rl YWQgb2YgYSBzdWJjZXJ0IHdpdGhpbiB0aGUgdHJlZQ0KPiAJZCkgRm9yIFBsZWRnZXMgdGhhdCBk b27igJl0IGRvIEVTVCB0aGV5IGhhdmUgYSBDQSBjZXJ0IHJhdGhlciB0aGFuIGp1c3QgYW4gUkEN Cj4gCQkobm90ZTogczQuNyBpbmRpY2F0ZXMgb25seSB0aGF0IFBsZWRnZXMg4oCcU0hPVUxE4oCd IGNvbnRpbnVlIHdpdGggRVNUKQ0KPiANCj4gUG9pbnQgKGQpIGlzIGltcG9ydGFudC4gSWYgd2Ug Y2hhbmdlIHRvIGEg4oCYcmVnaXN0cmFyLWNlcnTigJkgd2XigJlkIG5lZWQgdG8gc3RyZW5ndGhl biB0aGF0IHJlY29tbWVuZGF0aW9uIHRvIGEg4oCcTVVTVOKAnS4NCj4gDQo+Pj4+IEluIGEgc2ln bmVkIHZvdWNoZXIgcmVxdWVzdCBmcm9tIHRoZSBKUkMgKHJlZ2lzdHJhcikgdG8gdGhlIE1BU0Eg dGhlDQo+Pj4+IHBpbm5lZC1kb21haW4tY2VydCBpcyB0aGF0IG9mIHRoZSAqUmVnaXN0cmFyKiAo c2lnbmVkIHdpdGggaXQncyBjbWNSQSBtYXJrZWQNCj4+Pj4gY2VydGlmaWNhdGUgZnJvbSB0aGUg ZG9tYWluIG93bmVyJ3MgQ0EpLg0KPj4+PiANCj4+Pj4gYSkgaXMgdGhhdCBjZXJ0aWZpY2F0ZSBh bHNvIGluY2x1ZGVkIGluIHRoZSBQS0NTNyBiYWcgb2YgY2VydGlmaWNhdGVzPw0KPj4+PiBJIHRo aW5rIHRoZSBhbnN3ZXIgU0hPVUxEIGJlIHllcy4NCj4+IA0KPj4+IFRoaXMgaXMgdGhlIGN1cnJl bnQgbGFuZ3VhZ2UgYW5kICpub3QqIHRoYXQgdGhlIHBpbm5lZC1kb21haW4tY2VydCBpcw0KPj4+ IHBvcHVsYXRlZCBhdCBhbGwuIEluIGZhY3QgaWYgeW91IGxvb2sgYXQgdGhlIG5ldyB2b3VjaGVy LXJlcXVlc3QteWFuZw0KPj4+IGJyYW5jaCBhbmQgRXhhbXBsZSAoMikgb2YgdGhlIHZvdWNoZXIg cmVxdWVzdHMgeW91IHNlZToNCj4+IA0KPj4gQXJlIHlvdSBzYXlpbmcgdGhhdCBwaW5uZWQtZG9t YWluLWNlcnQgc2hvdWxkIG5vdCBiZSBwb3B1bGF0ZWQgaW4gdGhlDQo+PiB2b3VjaGVyIHJlcXVl c3QgKCJWUiIpIGZyb20gUmVnaXN0cmFyLT5NQVNBPw0KPiANCj4gSXRzIHBvcHVsYXRlZCB2aWEg dGhlIHByaW9yLXNpZ25lZC12b3VjaGVyLXJlcXVlc3QgKHNlZSBhYm92ZSkuDQo+IA0KPj4gDQo+ Pj4gSSB0aGluayB3ZeKAmXJlIGNsb3NlIHRvIGFncmVlaW5nLiBTb21lIGNvbW1lbnRzOg0KPj4g DQo+Pj4gSSBsaWtlIHRoZSBqd3QgYXBwcm9hY2ggdG8gY2VydHMgd2hlcmUgdGhleSBpbmNsdWRl IGFuIGVudGlyZSDigJx4NWPigJ0NCj4+PiBjaGFpbiByYXRoZXIgdGhhbiBhIHNpbmdsZSBjZXJ0 LiBNYXliZSB3ZSBzaG91bGQgYmUgY29weWluZyB0aGF0PyBJbg0KPj4+IHBhcnRpY3VsYXIgSSBs aWtlIGl0IGJldHRlciB0aGFuIHRyeWluZyB0byBzcGVjaWZ5IGV4dHJhIHN0dWZmIGluIHRoZQ0K Pj4+IGNlcnRpZmljYXRlIGJhZy4gVGhlIGxlc3Mgd2UgZGVwZW5kIG9uIHRoZSBwa2NzIzcgc3Ry dWN0dXJlIHRoZSBiZXR0ZXINCj4+PiBhbmQgSeKAmW0gd2lsbGluZyB0byBjaGFuZ2UgdGhlIGFi b3ZlIHVzZXMgdG8gbWVldCB0aGF0IGdvYWwuDQo+PiANCj4+IFNvLCBvdXIgcGlubmVkLWRvbWFp bi1jZXJ0IGluIHRoZSBWUiB3b3VsZCBpbmNsdWRlIHRoZSBlbnRpcmUgY2hhaW4/DQo+PiBXaGF0 IGZvcm1hdCB3b3VsZCB3ZSB1c2U/ICBJcyBpdCBqdXN0IGNvbmNhdGVuYXRlZCBERVIgb2YgY2Vy dGlmaWNhdGVzPw0KPiANCj4gQ3VycmVudCBsYW5ndWFnZSBpcyAqb25seSogdGhlIFJlZ2lzdHJh cuKAmXMgY2VydC4gDQo+IA0KPiAxKSBUaGUgUGxlZGdlIGF0dGVzdHMgdG8gdGhlIHNlZW4g4oCc cHJveGltaXR5LXJlZ2lzdHJhci1jZXJ04oCdIGJ5IGV4dHJhY3RpbmcgdGhlIFJlZ2lzdHJhcuKA mXMgVExTIHNlcnZlciBjZXJ0IGZyb20gdGhlIFRMUyBoYW5kc2hha2UuIFRoaXMgaXMgYSBzaW5n bGUgY2VydCBub3QgYSBjaGFpbi4gVGhpcyBuZXcgdm91Y2hlciByZXF1ZXN0IGxlYWYgbmFtZSBp cyBub3cgY2xlYXJlciBpbiB0aGlzIHBvaW50Lg0KPiANCj4gMikgVGhlIE1BU0EgYXR0ZXN0cyB0 byB0aGUgc2VlbiDigJxwaW5uZWQtZG9tYWluLWNlcnTigJ0gYnkgZXh0cmFjdGluZyB0aGUgUmVn aXN0cmFy4oCZcyAqcm9vdCBDQSBjZXJ0aWZpY2F0ZSogZnJvbSB0aGUgUEtDUyM3IHNpZ25hdHVy ZS4NCj4gDQo+IFRoZSBjaGFuZ2VzIGluIHRoZSBhYm92ZSBicmFuY2ggZG9u4oCZdCBlZmZlY3Qg dGhlIG5vcm1hdGl2ZSBiZWhhdmlvciBidXQgZG8gcHJvdmlkZSBjbGFyaXR5OyBJIHN1Z2dlc3Qg d2UgYWRvcHQgdGhlbS4gQmV5b25kIHRoYXQgdGhlIHF1ZXN0aW9uIGF0IGhhbmQgaXM6DQo+IA0K PiBRMSkgc2hvdWxkIHdlIG1ha2Ug4oCccmVnaXN0cmFyLWNlcnTigJ0gb3Ig4oCcZG9tYWluLWNl cnTigJ0gY29uc2lzdGVudCBhcm91bmQg4oCccmVnaXN0cmFy4oCdIG9yIOKAnGRvbWFpbuKAnSBv ciBtYWludGFpbiB0aGUgY3VycmVudCBkaWZmZXJlbmNlcz8NCj4gUTIpIGlmIHdlIG1vdmUgdG8g 4oCcY2hhaW7igJ0gc2hvdWxkIHdlIG1vdmUgYWxsIHRoZSB3YXkgdG8g4oCcZG9tYWluLWNoYWlu 4oCdPyBbMV0NCj4gDQo+IE15IHRoaW5raW5nIGlzIHRvIGFjY2VwdCBteSBicmFuY2jigJlzIGRp ZmZzIGJ1dCBub3QgbW92ZSB0b3dhcmQgY2hhaW5zLiANCj4gDQo+IC0gbWF4DQo+IA0KPiANCj4g WzFdIFdoYXQgd291bGQg4oCYY2hhaW7igJkgbG9vayBsaWtlPw0KPiANCj4geDVjIGlzIHdlbGwg ZGVmaW5lZCBhcyBhIEpTT04gZmllbGQuIEnigJlkIHVzZSB0aGUgc3RydWN0dXJlIGFzIGlzLiBT b21ldGhpbmcgbGlrZSB0aGUgbGFuZ3VhZ2Ugb2YgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc1MTUjc2VjdGlvbi00LjEuNiBtb2RpZmllZCB0byB0aGlzOg0KPiAJVGhlICJwcm94aW1p dHktZG9tYWluLWNoYWlu4oCdIHBhcmFtZXRlciBjb250YWlucyB0aGUgWC41MDkgcHVibGljIGtl eSANCj4gCWNlcnRpZmljYXRlIG9yIGNlcnRpZmljYXRlIGNoYWluIFtSRkM1MjgwXSBjb3JyZXNw b25kaW5nIHRvIHRoZSBrZXkgDQo+IAl1c2VkIGZvciBUTFMgc2VydmVyIGF1dGhlbnRpY2F0aW9u IGJ5IHRoZSBSZWdpc3RyYXIgdGhlIFBsZWRnZSBpcyBjb21tdW5pY2F0aW5nIHdpdGguDQo+IEkg aGF2ZSBOT1QgbWFkZSB0aGlzIG1vZGlmaWNhdGlvbi4NCj4gDQo+Pj4+IEluIG15IGNvZGUgSSdt IGRvaW5nOg0KPj4+PiANCj4+Pj4gaS4gIGV4dHJhY3QgdGhlIGZpcnN0IGNlcnRpZmljYXRlIGZy b20gdGhlIFBLQ1M3IGJhZywgYW5kIHVzZSBpdCB0bw0KPj4+PiB2ZXJpZnkgdGhlIFBLQ1M3LCB0 ZWxsaW5nIHRoZSB2ZXJpZnllciBub3QgdG8gdmFsaWRhdGUgdGhlIGNoYWluLA0KPj4+PiBhbmQg bm90IHRvIHVzZSBhbnkgY2VydGlmaWNhdGVzIGZyb20gdGhlIFBLQ1M3Lg0KPj4+PiBJIGZvdW5k IHRoYXQgSSBjb3VsZCBub3QgZmluZCBhIHdheSB0byBhY2Nlc3MgdGhlIGNvbnRlbnQgb2YgdGhl IFBLQ1M3DQo+Pj4+IGNvbnRlbnQgd2l0aG91dCB2ZXJpZnlpbmcgZmlyc3QuICBJIGRvbid0IGtu b3cgaWYgdGhpcyBpcyBhIHJ1Ynktb3BlbnNzbCwNCj4+Pj4gb3IgdW5kZXJseWluZyBsaWJzc2wg bGltaXRhdGlvbiB5ZXQuDQo+PiANCj4+PiBUaGlzIGlzIGFuIGltcG9ydGFudCBwb2ludC4gSW4g b3BlbnNzbCBJIGJlbGlldmUgSSB3YXMgYWJsZSB0byBjcmFjaw0KPj4+IGludG8gdGhlIGRldGFp bHMgd2l0aG91dCB2ZXJpZnlpbmcgYW5kIHRoZW4gZ28gYmFjayBhbmQgdmVyaWZ5IG9uY2UgSeKA mWQNCj4+PiBleHRyYWN0ZWQgdGhlIGNlcnQgYmFncy4NCj4+IA0KPj4gSSBiZWxpZXZlIGl0IHNo b3VsZCBiZSBwb3NzaWJsZSwgYnV0IHRoYXQgSSBtYXkgbm90IGhhdmUgYWNjZXNzIHRvIHRoZSBy aWdodA0KPj4gQVBJIGZyb20gcnVieS1vcGVuc3NsLiAgSSd2ZSBub3cgdXBzdHJlYW1lZCBvbmUg cGF0Y2ggZm9yIHJ1Ynktb3BlbnNzbCwgc28NCj4+IEknbGwgcHJvYmFibHkgZml4IHRoYXQgYW5k IHVwc3RyZWFtIGFuZCBhbm90aGVyIHBhdGNoLg0KPj4gDQo+Pj4+IEFsdGVybmF0aXZlbHksIGlu IHN0ZXAgKGkpLCBJIHNob3VsZCB0cnkgYWxsIHRoZSBjZXJ0aWZpY2F0ZXMgdW50aWwgb25lDQo+ Pj4+IHdvcmtzLCBndWFyZGluZyBhZ2luc3QgdGhlcmUgYmVpbmcgbW9yZSB0aGFuIG9uZS4NCj4+ IA0KPj4+IER1bm5vIHRoZSBvcHRpb25zLiBJIGJyb3VnaHQgbXkgY29kZSB1cCB0aGlzIGV2ZW5p bmcgdG8gcmVsb29rIGF0IHRoZQ0KPj4+IHBpbm5lZC1jZXJ0IGRpc2N1c3Npb24gaW4gdGhpcyBl eGFjdCBhcmVhIGJ1dCBkaWRu4oCZdCBtYWtlIGFueQ0KPj4+IHByb2dyZXNzLiBJ4oCZbGwgdHJ5 IGFuZCBsb29rIGF0IGl0IHRvbW9ycm93Lg0KPj4gDQo+PiANCj4+IA0KPj4gLS0NCj4+IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQo+PiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+PiANCj4+IA0KPj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmlt YSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= From nobody Tue Sep 19 11:53:35 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D541213436E for ; Tue, 19 Sep 2017 11:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br47XYWU5u-6 for ; Tue, 19 Sep 2017 11:53:29 -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 8C66F13435C for ; Tue, 19 Sep 2017 11:53:29 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 255BE58C4F5; Tue, 19 Sep 2017 20:53:24 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1061DB0CC22; Tue, 19 Sep 2017 20:53:23 +0200 (CEST) Date: Tue, 19 Sep 2017 20:53:23 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170919185323.GB10511@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de> <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 18:53:33 -0000 Thanks, Brian! Sheng: i think/hop i am trough all outstanding issues with stable-connectivity. Please decide what to do next to move to next stage, eg: another WG last call or pass to IETF/IESG. Cheers Toerless On Tue, Sep 19, 2017 at 08:11:56AM +1200, Brian E Carpenter wrote: > This is embarassing. For some reason I completely missed the announcement > of draft-ietf-anima-stable-connectivity-05, until today. > > I have now looked at the -05 and -06 versions and I'm happy with the result. > > Regards > Brian > > On 18/09/2017 17:38, Toerless Eckert wrote: > > Thanks, Brian: > > > > The "OLD" paragraph you list was from -04. After your review i had already > > changed this in -05 to > > > > NEW: > > > > To connect IPv4 only management plane devices/applications with the > > ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is > > necessary. The basic mechanisms for this are defined in SIIT > > ([RFC7915]). There are multiple solutions using this mechanisms. To > > understand the possible solutions, we consider the requirements: > > .... > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt > > > > I also did spend a good amount of time because of your -04 review and prior > > request by mohammed to detail in the following parapgraphs the possible > > options in more detail. That text leverages the 'SIIT' term and > > discusses the EAM solutions (RFC7757 is best). > > > > Given how this is an informational OPS document, > > i think it is helpfull to elaborate on the understood details of > > requirements and how known current solutions fit them. > > > > The fact that none of the > > currently defined NAT solutions provides for the most simple possible > > configuration (aka: minimum number of prefix EAM's to configure) is > > also IMHO a perfectly valid outcome for an OPS document. > > > > It could mean that users will simply accept the need for longer mnaual > > NAT config (long list of 1:1 mappings) or vendors implement a proprietary > > EAM (explicit address mapping) CLI to make it simpler. Or users will > > move faster to IPv6 on the NOC ;-) > > > > So, for the time being, i just commited -06 with the second fix. > > > > Let me know what you folks think about WG last call status of > > the stable connectivity draft. > > > > Cheers > > Toerless > > > > On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote: > >> To cut a long story short, here's a friendly suggestion. The goal is to avoid > >> comments during IETF/IESG review that the NAT text is too vague: > >> > >> OLD > >> To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 > >> NAT can be used. This NAT setup could for example be done in Rt1r1 > >> in above picture to also support IPv4 only NMS hots connected to > >> NOClan. > >> > >> NEW > >> To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 > >> translation [RFC 6145] could be used. This could for example be done in Rt1r1 > >> in the above picture to also support IPv4-only NMS hosts connected to > >> NOClan. Details of the address mapping to be used would depend on > >> the exact scenario and are not specified here. > >> > >> And yes, I like this: > >> > >>> i'd suggest to replace the "split-horizon" sentence with: > >>> > >>> Operators may therefore need to use a private DNS setup for the ACP ULA > >>> addresses. This is the same setup that would be necessary for using > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > >>> paragraph. In [RFC6950] section 4, these setups are discussed in more detail. > >> > >> Regards > >> Brian > >> > >> On 15/09/2017 09:18, Toerless Eckert wrote: > >>> > >>> Hi Brian, > >>> > >>> Sorry, for the delay. I have not sen further feedback on stable-connectivity-05 > >>> bside this mail of yours. See answers below, let me know if you want me to rev > >>> with the one possible textual improvement or if we think -05 is good enough. > >>> > >>> Cheers > >>> Toerless > >>> > >>> On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: > >>>> I'm just coming back on a couple of points. Generally -05 is almost there... > >>>> > >>>>> See the rewritten SIIT section. IMHO, there can be no simpler "network" based > >>>>> address translation. Where network based means that the translation happens > >>>>> in some device he network operator needs to provision. Like the ACP edge device. > >>>>> Or even an additional address translation device. > >>>>> > >>>>> So, the only IMHO easier option is when the OS of the NMS host would internally > >>>>> have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. > >>>> > >>>> Yes, that is exactly the effect of 464XLAT in the end-system (not in the > >>>> router). > >>> > >>> I found rfc6877 a confusing read, but from what i figure, it's not exactly what > >>> i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable > >>> IPv4 address, and that is something any device in the ACP does not have naturally. > >>> (aka: NOC server as client connecting to ACP device, ACP device is server). > >>> > >>> If i already need to set up some other form of NAT to give an ACP device an outside IPv4 > >>> address, then 464XLAT does not buy me any simplifications. > >>> > >>> I was rather thinking of taking the NAT network function that i was describing > >>> and simply embody them in a set of linux NAT rules configured on on the NOC linux > >>> system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme, > >>> but just a way to avoid having to deal with the problem in the network (adding a NAT > >>> device you would otherwise not need): > >>> > >>> Its a NMS host problme, deal with it in the NMS host. If you can not change the app, > >>> let the OS do the NAT. Of course, this would not work for the poor customer who bought > >>> a black-blox NMS soution which may run windows, or where you can not configure the > >>> linux. Then again, nowadays, most NOC components should be software in VMs, and > >>> for those, you should certainly be able to do the NAT in the vswitch of the server. > >>> > >>> In any case: my interest in expanding the NAT section further is quite limited. > >>> The whole goal of the NAT section was to explain that you need 1:1 address mapping > >>> and that you can hack this up in likely most available routers with NAT support, > >>> but do not consider this to be a good long term solution but use it as a stopgap > >>> to upgrade your NOC software to IPv6. > >>> > >>> No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-)) > >>> > >>> So, let me know if you feel strongly anything that should be added/modified to the > >>> NAT section. > >>> > >>>>> Alas, i didn't have the time to investigate these options. And most likely if at > >>>>> all you could only make those work for linux. > >>>> > >>>> Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they > >>>> will all support IPv6 anyway? > >>> > >>> Lets hope so, yes. > >>> > >>>>> So, for now i just remove the note and clarified the last sentence a bit. > >>>>> > >>>>> If there is anything specific to be said bout why 464XLAT might be better > >>>>> longer term, let me know and i can add it. For now it looks like yet another > >>>>> network device configured option to me, but i have not tried to understand it > >>>>> all the way. > >>>> > >>>> I think you'd need one of the 464XLAT authors to have a look at the scenario, > >>>> because I don't claim to understand it all. > >>> > >>> Well, the analysis i made above (server must support IPv4 as stated in the RFC) > >>> makes me discount it as a more beneficial option to mention. > >>> > >>>>>>> Using current registration options implies that there will not be > >>>>>>> reverse DNS mapping for ACP addresses. > >>>>>> > >>>>>> Really? I assume we're talking about two-faced DNS, and afaik nothing > >>>>>> stops an operator providing reverse mapping in the private DNS. > >>>>>> That seems to be implied by the following paragraphs, so the text > >>>>>> seems inconsistent anyway. > >>>>> > >>>>> I know it under the name "split-horizon DNS". Is there any reference ? > >>>> > >>>> The DNS community in the IETF hates split DNS so much that > >>>> not much has been written about it. I did find these: > >>>> https://tools.ietf.org/html/rfc6950#section-4 > >>>> https://tools.ietf.org/html/rfc7157#section-6.3 > >>>> https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens > >>> > >>> RFC1918 actually explains it succinctly without giving it a name. > >>> RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-) > >>> > >>> So, let me know if you think it's worth creating another stable-connectivity rev, > >>> i'd suggest to replace the "split-horizon" sentence with: > >>> > >>> Operators may therefore need to use a private DNS setup for the ACP ULA > >>> addresses. This is the same setup that would be necessary for using > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > >>> paragraph. In [RFC6950] section 4, these setups are discussed in more detail. > >>> > >>> Cheers > >>> Toerless > >>> > >>>> Regards, > >>>> Brian > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de From nobody Tue Sep 19 13:34:20 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7E6134390 for ; Tue, 19 Sep 2017 13:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoPJGpfC2hhy for ; Tue, 19 Sep 2017 13:34:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5EC1329B5 for ; Tue, 19 Sep 2017 13:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5198; q=dns/txt; s=iport; t=1505853257; x=1507062857; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CJwpHRAKIY8S1+xHHre2r1pIYT2KTSBPEOuMpTKYREE=; b=PGbU+/irwEGvpr7TAJJVzlWEXFHYT0yDXXpgFCKxUHIGYNxpzz5k0dBJ /2B2VCf7X3n5NZhDANoVnHpxoNL5DyTJbSkX5be6StpTfWGBBwQltSaFx ew6xwqTlNBuq9+rr78qVaOaY+tK3w3qrN12p8awOnfVJKP2Qz1xvn5KYc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAACjfsFZ/5hdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZG4nB4NuiiCPdoF0eYdDjWmCEgoYC4FegzoCGoRBPxgBAgE?= =?us-ascii?q?BAQEBAQFrKIUYAQEBAQIBAQEMFRExCQsFCwIBCBgCAiYCAgIfBgsVEAIEDgUbi?= =?us-ascii?q?gADDQgQqHKCJ4czDYNfAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBDoIdgQt3gzU?= =?us-ascii?q?rgkg1glmCDBYXgnwvgjEFoFA8Ao9dhHeSeoxciC4CERkBgTgBHziBDXcVSRIBh?= =?us-ascii?q?wl2AYdqgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="295296589" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 20:34:16 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8JKYGw2007453 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 20:34:16 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.1263.5; Tue, 19 Sep 2017 15:34:15 -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.1263.000; Tue, 19 Sep 2017 15:34:15 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter CC: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] two EST question/suggestions Thread-Index: AQHTIQXdDQD3LWJmSEK5TOw40YgcLaKr+4eAgAW+jQCAAFwsgIAADV2AgAAaKgCAABnXgIABU7OAgAlz3oA= Date: Tue, 19 Sep 2017 20:34:15 +0000 Message-ID: <4C500E2F-FDBB-484B-898B-F90B64D3C69C@cisco.com> References: <961.1504038708@obiwan.sandelman.ca> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> <27231.1505249495@obiwan.sandelman.ca> <6079.1505260663@obiwan.sandelman.ca> <5c00237e-98fa-9764-d816-919307bdd994@gmail.com> In-Reply-To: <5c00237e-98fa-9764-d816-919307bdd994@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="utf-8" Content-ID: <58CA52FDB32E72428CDE41E6D11D0529@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 20:34:19 -0000 DQpBbnkgcHJvdG9jb2wgd29yayBuZWVkcyBiYWxhbmNlIGZ1dHVyZSBwcm9vZmluZyAoYW50aWNp cGF0aW5nIGNoYW5nZXMgaW4gdGhlIE1USSkgYWdhaW5zdCBjbGVhciBhbmQgZGVmaW5pdGl2ZSBz dGF0ZW1lbnRzIHRvIG1lZXQgdGhlIGN1cnJlbnQgcmVxdWlyZW1lbnRzLiBJZiB0aGVyZSBhcmUg cGxhY2VzIHdoZXJlIHRoZSBjdXJyZW50IGxhbmd1YWdlIGZhbGxzIGRvd24gY29tbWVudGluZyBv biB0aGF0IHNwZWNpZmljIGxhbmd1YWdlIHdvdWxkIGhlbHAuDQoNClJlIHRoZSBIVFRQLzIgZGlz Y3Vzc2lvbjoNCg0KSFRUUC8yIGlzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50IHZpYSBvbmUgb2Yg dGhlIFJGQzc1NDAgc2VjdGlvbjMgbWV0aG9kcy4gVGhlcmUgaXMgbm90aGluZyBpbiB0aGUgTVRJ IEJSU0tJIGxhbmd1YWdlIHRoYXQgd291bGQgYmxvY2sgYXR0ZW1wdHMgdG8gc28gdXBncmFkZSBi eSBjbGllbnRzLiBUaGUgc2VydmVyIGNvdWxkIG9mIGNvdXJzZSBzdXBwb3J0IHRoaXMgaWYgaXQg c28gZGVzaXJlZC4gDQoNCkkgZG9u4oCZdCBzZWUgYW4gYWR2YW50YWdlIHRvIEhUVFAvMiBmb3Ig QlJTS0kgYW5kIEVTVCBpbnRlcmFjdGlvbnMuIEkgZ3Vlc3MgYSBzZXJ2ZXIgY291bGQgZmluaXNo IGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGllbnQgYW5kIGltbWVkaWF0ZWx5IGluaXRpYXRlIGEg c2VydmVyIHB1c2ggb2YgdGhlIGNzcmF0dHJpYnV0ZXMsIHZvdWNoZXIgcmVzcG9uc2UgKGlmIGF2 YWlsYWJsZSksIGFuZCBvdGhlciBtZXNzYWdlcy4gVGhpcyB3b3VsZCBzYXZlIHNvbWUgcm91bmQg dHJpcHMgYnV0IGluIHRoZSBwcmltYXJ5IGZsb3dzIHRoZSBjbGllbnQgbmVlZHMgdG8gcGVyZm9y bSBhIGNyeXB0byBvcGVyYXRpb24gdGhhdCBpcyB1c2VkIG9yIHZlcmlmaWVkIGJ5IHRoZSBzZXJ2 ZXIgYmVmb3JlIGEgcmVzcG9uc2UgaXMgZ2VuZXJhdGVkLiBTbyB0aGUgYmFzaWMgc3RhdGUgbWFj aGluZSwgSSB0aGluaywgd291bGQgY29udGludWUgdG8gZmxvdyBhcyBjdXJyZW50bHkgc3BlY2lm aWVkLiANCg0KSSBhZ3JlZSB3aXRoIHRoZSBjb25jbHVzaW9uIGJlbG93IHRoYXQgIlRUUCAxLjEg d2l0aCBwZXJzaXN0ZW50IGNvbm5lY3Rpb25zIGlzIHRoZSBtaW5pbXVtIChub3QgdGhlIG1heGlt dW0p4oCdIGFuZCB0aGF0IHdlIGRvbuKAmXQgaGF2ZSBhbnl0aGluZyBlbHNlIHRvIHNheSBoZXJl LiANCg0KLSBtYXgNCg0KDQo+IE9uIFNlcCAxMywgMjAxNywgYXQgMjoxMyBQTSwgQnJpYW4gRSBD YXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAx My8wOS8yMDE3IDExOjU3LCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6DQo+PiANCj4+IEJyaWFu IEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4+PiBX ZSBhcmUgcnVubmluZyBvdmVyIEhUVFAgMS4xLCB3ZSBoYXZlIHRvIGFzc3VtZSB0aGF0Lg0KPj4+ PiBUaGUgaXNzdWUgaXMgdGhhdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIGxpYnJhcmllcyB3aWxs IGdyb3cgSFRUUCAyLCBhbmQgd2UNCj4+Pj4gbmVlZCB0byBrbm93IGlmIHRoaXMgaXMgYSBwcm9i bGVtLg0KPj4+PiANCj4+Pj4+IEl0IHNlZW1zIHRvIG1lIHRoYXQgd2Ugd2FudCB0byBtaW5pbWlz ZSB0aGUgcmVxdWlyZW1lbnRzIGZvciBsb3cgZW5kIHBsZWRnZQ0KPj4+Pj4gZGV2aWNlcywgYW5k IGV2ZXJ5IGl0ZW0gdGhhdCB3ZSBtYWtlIG1hbmRhdG9yeSB3b3JrcyBhZ2FpbnN0IHRoYXQuDQo+ Pj4+IA0KPj4+PiBCUlNLSSBkb2VzIG5vdCB0YXJnZXQgY29uc3RyYWluZWQgZGV2aWNlczsgIGlu IHRoZSBmdXR1cmUgaGF2aW5nIG9ubHkgYW4gSFRUUA0KPj4+PiAyIGxpYnJhcnkgKGJlY2F1c2Ug dGhlIGFwcGxpY2F0aW9uIGlzIHVzaW5nIHRoYXQpIG1pZ2h0IGJlIHNpbXBsZXN0LiAgSXMgaXQN Cj4+Pj4gZ29pbmcgdG8gd29yayBva2F5Pw0KPj4gDQo+Pj4gSSBkb24ndCBzZWUgd2h5IG5vdC4g QnV0IGlzbid0IHRoZXJlIHBvdGVudGlhbGx5IGEgY2xhc3Mgb2YgZGV2aWNlcyB0aGF0DQo+Pj4g d2hpbGUgbm90IGJlaW5nICdjb25zdHJhaW5lZCcgaW4gdGhlIGZvcm1hbCBzZW5zZSwgbmV2ZXJ0 aGVsZXNzIG5lZWRzIHRvDQo+Pj4gbWluaW1pc2UgaXRzIHNvZnR3YXJlIGZvb3RwcmludD8gU28g dGhlIGltcGxlbWVudGVyIHdpbGwgd2FudCB0byBjaG9vc2UNCj4+PiB0aGUgc29sdXRpb24gd2l0 aCB0aGUgc21hbGxlc3QgZm9vdHByaW50LCByYXRoZXIgdGhhbiB3aGF0ZXZlciBNVEkgd2UNCj4+ PiBoYXBwZW4gdG8gZGVmaW5lIGluIDIwMTcuDQo+PiANCj4+IFllcywgSSBhZ3JlZSB3aXRoIHlv dS4NCj4+IA0KPj4gVGhhdCdzIHdoeSBJIHdvdWxkIGxpa2UgdXMgdG8gcGVybWl0IHBsZWRnZXMg dG8gc3VwcG9ydCBhIHNpbmdsZSBjbGllbnQgSFRUUA0KPj4gbGlicmFyeS4gIFRoZXkgd2lsbCB1 c2Ugd2hhdGV2ZXIgSFRUUCBjbGllbnQgbGlicmFyeSB0aGF0IHRoZXkgbmVlZCBmb3IgdGhlaXIN Cj4+IHByaW1hcnkgYXBwbGljYXRpb24uLi4gc28gaWYgaXQncyBhIHdlYnJ0YyBuYW5ueSBjYW1l cmEsIHRoZW4gaXQgbWlnaHQgd2VsbA0KPj4gYmUgSFRUUDIgKyBRVUlDLg0KPj4gDQo+PiBUaGUg cHJvYmxlbSB3aXRoIEhUVFAyIGlzIHRoYXQgaXQgcGVybWl0cyByZXF1ZXN0cyBhbmQgcmVzcG9u c2VzIHRvIGJlDQo+PiBpbnRlcmxlYXZlZCBhbmQgbm90LXNlcXVlbnRpYWwgaW4gdGhlIFRDUCBz ZW5zZS4gIFRoaXMgcG90ZW50aWFsbHkgaGFzIGEgcG9vcg0KPj4gaW50ZXJhY3Rpb24gd2l0aCB0 aGUgQlJTS0kgc3RhdGUgbWFjaGluZS4gIFdlIG91Z2h0IHRvIHNheSBzb21ldGhpbmcgYWJvdXQN Cj4+IHRoaXMgKnRvZGF5Ki4NCj4+IA0KPj4+IE9mIGNvdXJzZSB3ZSBjYW4gYWx3YXlzIGNoYW5n ZSB0aGUgTVRJIGxhdGVyLCBidXQgaWYgd2Ugc2F5IHJpZ2h0IG5vdyB0aGF0DQo+Pj4gdGhlIE1U SSBvbmx5IGFwcGxpZXMgdG8gdGhlIHNlcnZlciBzaWRlLCBhZGRpbmcgbmV3IHNvbHV0aW9ucyBm b3IgZnV0dXJlDQo+Pj4gdHlwZXMgb2YgcGxlZGdlIGJlY29tZXMgbW9yZSBzdHJhaWdodGZvcndh cmQuIEFzIGZhciBhcyBJIGNhbiBzZWUsIHRoaXMNCj4+PiB3b3VsZCBoYXZlIHplcm8gaW1wYWN0 IG9uIGZpcnN0LWdlbmVyYXRpb24gaW1wbGVtZW50YXRpb25zOyBpbml0aWFsbHkNCj4+PiBib3Ro IHNlcnZlcnMgYW5kIGNsaWVudHMgd2lsbCBzdXBwb3J0IHRoZSBNVEkgYW55d2F5Lg0KPj4gDQo+ PiBNeSB0YWtlIGlzIHRoYXQgdGhlIHNlcnZlciBoYXMgdG8gc3VwcG9ydCBldmVyeSBzaW5nbGUg TVRJIHRoYXQgd2UgaGF2ZSBldmVyeQ0KPj4gc3VwcG9ydGVkLiAgVGhhdCdzIG9rYXkuICBCdXQs IEhUVFAgMS4xIHdpdGggcGVyc2lzdGVudCBjb25uZWN0aW9ucyBpcyB0aGUNCj4+IG1pbmltdW0g KG5vdCB0aGUgbWF4aW11bSkuDQo+IA0KPiBGYWlyIGVub3VnaC4gSSBqdXN0IHdhbnQgdG8gYmUg c3VyZSB0aGF0IHdoZW4gc29tZW9uZSBjb21lcyB1cCB3aXRoDQo+IGEgYnJpbGxpYW50IG5ldyBt ZXRob2Qgd2l0aCBhIHRpbnkgZm9vdHByaW50LCBwbGVkZ2VzIGFyZSBmcmVlIHRvIGFkb3B0DQo+ IGl0IGRlc3BpdGUgYW55IE1VU1RzIHdlIHdyaXRlIGRvd24gaW4gMjAxNy4NCj4gDQo+ICAgIEJy aWFuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= From nobody Tue Sep 19 17:54:20 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6F133061 for ; Tue, 19 Sep 2017 17:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 20yVDFAmgR0G for ; Tue, 19 Sep 2017 17:54:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0006F133023 for ; Tue, 19 Sep 2017 17:54:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVV13873; Wed, 20 Sep 2017 00:54:13 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 20 Sep 2017 01:54:11 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 20 Sep 2017 08:54:08 +0800 From: Sheng Jiang To: Toerless Eckert , Brian E Carpenter CC: Anima WG Thread-Topic: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 Thread-Index: AQHTLZ8aSjvwEciiX0y/fMRrjnoBG6K0eqqAgAUkyACAAPPzAIABfGOAgADh09A= Date: Wed, 20 Sep 2017 00:54:07 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CEC1508@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de> <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com> <20170919185323.GB10511@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170919185323.GB10511@faui40p.informatik.uni-erlangen.de> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59C1BC36.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 808a86cbdd82031337151673a36ba796 Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 00:54:19 -0000 Hi, Toerless, Thanks for your hard and fruitful work. Giving the change mount from -03 ve= rsion, which is the base for the first WGLC, I feel another WGLC is needed.= I will launch a short one-week WGLC on this. Meanwhile, I still not receiv= e IPR disclosure from all authors. I would not be able to move this documen= t forward with the proper IPR disclosures, even after the WGLC passed. Cheers, Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: Wednesday, September 20, 2017 2:53 AM > To: Brian E Carpenter > Cc: Anima WG > Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - > Respond by July 28, 2017 >=20 > Thanks, Brian! >=20 > Sheng: i think/hop i am trough all outstanding issues with > stable-connectivity. Please decide what to do next to move to next stage, > eg: another WG last call or pass to IETF/IESG. >=20 > Cheers > Toerless >=20 > On Tue, Sep 19, 2017 at 08:11:56AM +1200, Brian E Carpenter wrote: > > This is embarassing. For some reason I completely missed the > > announcement of draft-ietf-anima-stable-connectivity-05, until today. > > > > I have now looked at the -05 and -06 versions and I'm happy with the > result. > > > > Regards > > Brian > > > > On 18/09/2017 17:38, Toerless Eckert wrote: > > > Thanks, Brian: > > > > > > The "OLD" paragraph you list was from -04. After your review i had > > > already changed this in -05 to > > > > > > NEW: > > > > > > To connect IPv4 only management plane devices/applications with > the > > > ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is > > > necessary. The basic mechanisms for this are defined in SIIT > > > ([RFC7915]). There are multiple solutions using this mechanisms. > To > > > understand the possible solutions, we consider the requirements: > > > .... > > > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools= . > > > ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=3Dhttps:= / > > > /tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt > > > > > > I also did spend a good amount of time because of your -04 review > > > and prior request by mohammed to detail in the following > parapgraphs > > > the possible options in more detail. That text leverages the 'SIIT' > > > term and discusses the EAM solutions (RFC7757 is best). > > > > > > Given how this is an informational OPS document, i think it is > > > helpfull to elaborate on the understood details of requirements and > > > how known current solutions fit them. > > > > > > The fact that none of the > > > currently defined NAT solutions provides for the most simple > > > possible configuration (aka: minimum number of prefix EAM's to > > > configure) is also IMHO a perfectly valid outcome for an OPS > document. > > > > > > It could mean that users will simply accept the need for longer > > > mnaual NAT config (long list of 1:1 mappings) or vendors implement a > > > proprietary EAM (explicit address mapping) CLI to make it simpler. > > > Or users will move faster to IPv6 on the NOC ;-) > > > > > > So, for the time being, i just commited -06 with the second fix. > > > > > > Let me know what you folks think about WG last call status of the > > > stable connectivity draft. > > > > > > Cheers > > > Toerless > > > > > > On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote: > > >> To cut a long story short, here's a friendly suggestion. The goal > > >> is to avoid comments during IETF/IESG review that the NAT text is to= o > vague: > > >> > > >> OLD > > >> To bridge an IPv4 only management plane with the ACP, IPv4 to > IPv6 > > >> NAT can be used. This NAT setup could for example be done in > Rt1r1 > > >> in above picture to also support IPv4 only NMS hots connected to > > >> NOClan. > > >> > > >> NEW > > >> To bridge an IPv4-only management plane with the ACP, IPv4 to > IPv6 > > >> translation [RFC 6145] could be used. This could for example be > done in Rt1r1 > > >> in the above picture to also support IPv4-only NMS hosts > connected to > > >> NOClan. Details of the address mapping to be used would > depend on > > >> the exact scenario and are not specified here. > > >> > > >> And yes, I like this: > > >> > > >>> i'd suggest to replace the "split-horizon" sentence with: > > >>> > > >>> Operators may therefore need to use a private DNS setup for the > > >>> ACP ULA addresses. This is the same setup that would be necessary > > >>> for using > > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, > > >>> last paragraph. In [RFC6950] section 4, these setups are discussed = in > more detail. > > >> > > >> Regards > > >> Brian > > >> > > >> On 15/09/2017 09:18, Toerless Eckert wrote: > > >>> > > >>> Hi Brian, > > >>> > > >>> Sorry, for the delay. I have not sen further feedback on > > >>> stable-connectivity-05 bside this mail of yours. See answers > > >>> below, let me know if you want me to rev with the one possible > textual improvement or if we think -05 is good enough. > > >>> > > >>> Cheers > > >>> Toerless > > >>> > > >>> On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: > > >>>> I'm just coming back on a couple of points. Generally -05 is almos= t > there... > > >>>> > > >>>>> See the rewritten SIIT section. IMHO, there can be no simpler > > >>>>> "network" based address translation. Where network based > means > > >>>>> that the translation happens in some device he network operator > needs to provision. Like the ACP edge device. > > >>>>> Or even an additional address translation device. > > >>>>> > > >>>>> So, the only IMHO easier option is when the OS of the NMS host > > >>>>> would internally have IPv4/IPv6 translation so the device/VM > looks to the outside like full IPv6. > > >>>> > > >>>> Yes, that is exactly the effect of 464XLAT in the end-system (not > > >>>> in the router). > > >>> > > >>> I found rfc6877 a confusing read, but from what i figure, it's not > > >>> exactly what i was thinking of: with rfc6877, you still need the > > >>> server side to have a reachable/mappable > > >>> IPv4 address, and that is something any device in the ACP does not > have naturally. > > >>> (aka: NOC server as client connecting to ACP device, ACP device is > server). > > >>> > > >>> If i already need to set up some other form of NAT to give an ACP > > >>> device an outside IPv4 address, then 464XLAT does not buy me any > simplifications. > > >>> > > >>> I was rather thinking of taking the NAT network function that i > > >>> was describing and simply embody them in a set of linux NAT rules > > >>> configured on on the NOC linux system that runs the IPv4-only NMS > > >>> application. Aka: Not a novel NAT scheme, but just a way to avoid > > >>> having to deal with the problem in the network (adding a NAT > device you would otherwise not need): > > >>> > > >>> Its a NMS host problme, deal with it in the NMS host. If you can > > >>> not change the app, let the OS do the NAT. Of course, this would > > >>> not work for the poor customer who bought a black-blox NMS > soution > > >>> which may run windows, or where you can not configure the linux. > > >>> Then again, nowadays, most NOC components should be software in > VMs, and for those, you should certainly be able to do the NAT in the > vswitch of the server. > > >>> > > >>> In any case: my interest in expanding the NAT section further is > quite limited. > > >>> The whole goal of the NAT section was to explain that you need 1:1 > > >>> address mapping and that you can hack this up in likely most > > >>> available routers with NAT support, but do not consider this to be > > >>> a good long term solution but use it as a stopgap to upgrade your > NOC software to IPv6. > > >>> > > >>> No idea why IETF draft/RFC doesn't allow me to write such a simple > > >>> paragraph ;-)) > > >>> > > >>> So, let me know if you feel strongly anything that should be > > >>> added/modified to the NAT section. > > >>> > > >>>>> Alas, i didn't have the time to investigate these options. And > > >>>>> most likely if at all you could only make those work for linux. > > >>>> > > >>>> Linux or Windows, yes. In a vendor's router o/s, who knows? But > > >>>> maybe they will all support IPv6 anyway? > > >>> > > >>> Lets hope so, yes. > > >>> > > >>>>> So, for now i just remove the note and clarified the last sentenc= e > a bit. > > >>>>> > > >>>>> If there is anything specific to be said bout why 464XLAT might > > >>>>> be better longer term, let me know and i can add it. For now it > > >>>>> looks like yet another network device configured option to me, > > >>>>> but i have not tried to understand it all the way. > > >>>> > > >>>> I think you'd need one of the 464XLAT authors to have a look at > > >>>> the scenario, because I don't claim to understand it all. > > >>> > > >>> Well, the analysis i made above (server must support IPv4 as > > >>> stated in the RFC) makes me discount it as a more beneficial option > to mention. > > >>> > > >>>>>>> Using current registration options implies that there will > not be > > >>>>>>> reverse DNS mapping for ACP addresses. > > >>>>>> > > >>>>>> Really? I assume we're talking about two-faced DNS, and afaik > > >>>>>> nothing stops an operator providing reverse mapping in the > private DNS. > > >>>>>> That seems to be implied by the following paragraphs, so the > > >>>>>> text seems inconsistent anyway. > > >>>>> > > >>>>> I know it under the name "split-horizon DNS". Is there any > reference ? > > >>>> > > >>>> The DNS community in the IETF hates split DNS so much that not > > >>>> much has been written about it. I did find these: > > >>>> https://tools.ietf.org/html/rfc6950#section-4 > > >>>> https://tools.ietf.org/html/rfc7157#section-6.3 > > >>>> https://tools.ietf.org/html/draft-richardson-homenet-secret-garde > > >>>> ns > > >>> > > >>> RFC1918 actually explains it succinctly without giving it a name. > > >>> RFC4193 only tells you what you shouldn't do with DNS. How > > >>> helpfull ;-) > > >>> > > >>> So, let me know if you think it's worth creating another > > >>> stable-connectivity rev, i'd suggest to replace the "split-horizon" > sentence with: > > >>> > > >>> Operators may therefore need to use a private DNS setup for the > > >>> ACP ULA addresses. This is the same setup that would be necessary > > >>> for using > > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, > > >>> last paragraph. In [RFC6950] section 4, these setups are discussed = in > more detail. > > >>> > > >>> Cheers > > >>> Toerless > > >>> > > >>>> Regards, > > >>>> Brian > > >>> > > >> > > >> _______________________________________________ > > >> Anima mailing list > > >> Anima@ietf.org > > >> https://www.ietf.org/mailman/listinfo/anima > > > >=20 > -- > --- > tte@cs.fau.de >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Sep 19 18:08:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BEF1326ED; Tue, 19 Sep 2017 18:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 ApubFXeBUVeh; Tue, 19 Sep 2017 18:08:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3032B1252BA; Tue, 19 Sep 2017 18:08:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVV15176; Wed, 20 Sep 2017 01:08:43 +0000 (GMT) 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.301.0; Wed, 20 Sep 2017 02:08:42 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 20 Sep 2017 09:08:39 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: The second WGLC on draft-ietf-anima-stable-connectivity (06 version) - Respond by September 27, 2017 Thread-Index: AdMxrMPs1JuhIUYVSmur325YX7RwGw== Date: Wed, 20 Sep 2017 01:08:38 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CEC1525@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CEC1525NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59C1BF9B.005A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d5fbb303a4069e76710f12e80b9ab3bd Archived-At: Subject: [Anima] The second WGLC on draft-ietf-anima-stable-connectivity (06 version) - Respond by September 27, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 01:08:47 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CEC1525NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all ANIMA, Although the draft-ietf-anima-stable-connectivity-03 did pass our WGLC, see= below link. The authors have made good work of refining on this document s= ince then. Giving the change mount from -03 to current 06 version, I feel a= nother WGLC is needed. https://www.ietf.org/mail-archive/web/anima/current/msg02923.html The change between 03 and o6 versions can be changed using the below URL https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-anima-stable-connectivity-03= &url2=3Ddraft-ietf-anima-stable-connectivity-06&difftype=3D--html So, this message starts a shorter one-week ANIMA Working Group Last Call to= advance draft-ietf-anima-stable-connectivity-06, Using Autonomic Control P= lane for Stable Connectivity of Network OAM. This document's intended statu= s is Informational. At present, there is no IPR file against this document. Please send your comments by September 27, 2017. If you do not feel this d= ocument should advance, please state your reasons why. Sheng JIANG is the assigned document shepherd. Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CEC1525NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all ANIMA,

 

Although the draft-ietf-anima-s= table-connectivity-03 did pass our WGLC, see below link. The authors have m= ade good work of refining on this document since then. Giving the change mo= unt from -03 to current 06 version, I feel another WGLC is needed.

 

https://www.ietf.org/mail-archive/web/anima/curre= nt/msg02923.html

 

The change between 03 and o6 ve= rsions can be changed using the below URL

 

https://www.ietf.org/rfcdiff?ur= l1=3Ddraft-ietf-anima-stable-connectivity-03&url2=3Ddraft-ietf-anima-st= able-connectivity-06&difftype=3D--html

 

So, this message starts a short= er one-week ANIMA Working Group Last Call to advance draft-ietf-anima-stabl= e-connectivity-06, Using Autonomic Control Plane for Stable Connectivity of= Network OAM. This document's intended status is Informational. At present, there is no IPR file against this doc= ument.

 

Please send your comments by Se= ptember 27, 2017. If you do not feel this  document should advance, pl= ease state your reasons why. 

 

Sheng JIANG is the assigned doc= ument shepherd.

 

Regards,

 

Sheng

--_000_5D36713D8A4E7348A7E10DF7437A4B927CEC1525NKGEML515MBXchi_-- From nobody Tue Sep 19 19:46:29 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE12132D45; Tue, 19 Sep 2017 19:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG6i284AmBfg; Tue, 19 Sep 2017 19:46:26 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC8F120724; Tue, 19 Sep 2017 19:46:26 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id j16so927559pga.1; Tue, 19 Sep 2017 19:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BzuPykqNQetbQgYixJX4986OVJ5YLtYu3r7m1u6DyDk=; b=ixkpb+iqsgf1KBO/QyS1GRpckZBYcn7n8YRan7b8oWcF8i01CrEdIRBKEi2qQWVAi/ KWCi3X9DOo++a3jOZiZEeKY+jJ5psr+9sgHfsyQSPh4KkF2H1zy5LIjFdqedJcjjPecY Z/PZloO84U8N0OaleisuCawGLr2RRioli+kK933SoeBkvHsyqujkWx6G01kHgj/euBil rrK4xAfQ9W8+GxzNutQCWeMuAoBadpgdE7JkGEVw9g24rlF/3ioTd6hp7j2Xn99JVqB/ C9j14d0IeNHEUfI2G297k0ZxHoRsqb4qL2SH4LSJLvejLf8u9m/OK6PcCSVVF2Bt5Zoo nn/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BzuPykqNQetbQgYixJX4986OVJ5YLtYu3r7m1u6DyDk=; b=VtQ/V7SSdCgYhkzAyP81hxcjrxAJ0bqnl/hy+4G9lwuilp/HKEer3audBWgguoth0W vQMB6owabr22kdImKPm9u6XNqYCXLsZDu/+yK+tr0OZ84vWLfn2VCFwLeTfzD7SP8joI g1oRJm6hO7ZTqxlYAy2a9KHgf3wkAgEiIOwwVvek4FggG/nCKU7GQpzXD/VtgnFj+aT+ j/jX8352a9yeNHtRHjTmKCmlwRV0NPIwbEZQH0ocHBbFfiVg8LVf64wgnivU3BGhQCsn RAOuAvUKb9LjWZWXO9dmIKJwIc8ILBcU4gpqDXeEWOT6uZAYYSsgTqfsGvaCOGoTpTNG s6eA== X-Gm-Message-State: AHPjjUgtSpUtS7uK/Z7bHbO0Mf6muZd40gGJNcE16t/jxgiqwdSedick fKP1kAOguz8n5pa7bdxXAJLfAQ== X-Google-Smtp-Source: AOwi7QBDQjsTEjjjeGqh+pIvB+uDOaLivMJR/HQ0VxhtQs4aLbVWrh+Su+iAWSToNzTFMwyQYgiXCQ== X-Received: by 10.84.201.6 with SMTP id u6mr584690pld.289.1505875585697; Tue, 19 Sep 2017 19:46:25 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a25sm7225635pfg.111.2017.09.19.19.46.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 19:46:24 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> Date: Wed, 20 Sep 2017 14:46:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 02:46:29 -0000 Hi Toerless, Slight change of subject header to bring us up to date. Thanks for all the work. I think the -10 version is much better. No comments on the -08 to -09 revisions. On -09 to -10 revisions: ... >>> 5. Inside the ACP VRF, each node sets up a virtual (loopback) >>> interface with its ULA IPv6 address. >> >> I think we have cases where a node has multiple ULAs. > > Right now, an ACP would have exacty one Certificate derived ULA > and 0 or more configured ones for autonomic-connect interfaces in case > the operator wants to use the manual addressing sub-scheme on the autonomic > connect interface. > > What other cases are you thinking of ? I forget but I think Michael R had a case for this. Or possibly Michael B. ... >>> anima.acp+{+{+}}@ >> >> What notation is that? Is {} supposed to be an optional item? >> If so, why not use [] as in ABNF, and cite ABNF. > > acp-10: Done. Please check again. Got a lot more complex by using ABNF, but maybe more precise. Looks OK to me, except for some surviving {} in {+}} ... On the question of duplicate description of the "AN_join_registrar" objective: > b), c) BRSKI only specifies zero touch bootstrap, but not certificate maintenance/renewal. > > ACP should be modular, eg: we should be able to combine it with any initial bootstrap > (BRSKI of course preferred and only BRSKI+ANIMA+GRASP = ANI, but netconf-zero-touch or > other would be possible option if so desired). So we need zero-touch certificate > (renewal, revocation) specification in ACP doc> > Cert renewal in ACP spec is using EST (RFC7030). Use of GRASP is specified in ACP draft > is solely to support this EST renewal. Without GRASP to find EST-Server, we can not > support EST-Server redundancy: YOu can specify a URL for reneal in the certificate, > but if that URL goes down, you're lost. Without ACP/GRASP you would have had to setup some > form of anycast domain-name or ip-address in the URL - or worse yet list multiple registrar. > > The GRASP objective in BRSKI is BRSKI-TLS and is discovered by bootstrap proxies, the > GRASP objective in ACP is EST-TLS and is discovered by encrolled ACP members for their > own Cert renewal. Big difference. Understood, but we can't have two standards track documents claiming to define the same objective. If it's *different* from the one in BRSKI it needs a different name. If it's the *same* one and you are extending its semantics, you have to say that, and BRSKI becomes a normative reference. The latest BRSKI draft calls it "AN_registrar" but I assume it is intended to be the same thing. Anyway I suggest that the ACP authors and the BRSKI authors agree on what you want. I'm very happy to help with the GRASP details but only when it's clear what you want. > c) Initially i thought too that RSKI would be a superset of everything that we'd need > for certificate maintenance, but thats not the goal of BRSKI. It is only meant o specify > initial bootstrap, but not cert renewal or the like. > > a) I think to remember that MichaelR was pretty positive on the mike in Prague about > the inclusion of EST in ACP spec for renewal. But i am sure he will chime in. > > The confusing bits may be how to use GRASP. Here is what current ACP and BRSKI text > would lead to: > > - ACP registrar without BRSKI: registrar == EST-server > registrar announces AN_join_registrar with only EST-TLS objective value > > - ACP registrar with BRSKI: registrar == EST-server + BRSKI spec > registrar announces AN_join_registrar with both EST-TLS and EST-BRSKI objective values I agree, it should work. > >>> The loop-count MUST be sete to 255. When an ACP node >>> receives the M_FLOOD, it will have been reduced by the number of hops >>> from the EST server. >> >> I don't like that. The role of the loop count is loop prevention, >> so it should be set to a reasonable upper bound on the "radius" >> of the network. GRASP has two measures for loop detection, this >> one and detection of duplicate session IDs, but that was >> intentional redundancy.] > > Sure, and if we set loop-count to a well-known value such as 255 then > we do use it in the same way as IP uses TTL: Just as a way of last defense. > Primary method is loop-free routing protocols (IP) or duplicate session ID (GRASP). > > [50% rant:] > Every new technology seems to think that TTL is a great tool, only then to > figure out later that its only a good protection of last resort. IP unicast > did this, and today, nobody really uses any TTL other than 255 or 1. > IP multicast regurgitated TTL values for "TTL scoping" and it took almost > 10 years to get rid of it, we depreciated that, and since ~2000 IP multicast > also only uses 255 or 1 since then. IMHO: Same learning curve is necessary for GRASP. > Maybe we will come up with good use cases for 1 < TTL < 255 still, but i doubt > it. Unless you have very specific variations of eg: ACP for networks with > well-knon smaller max-TTL, i do not see it. > [/rant] > > But you do not need to buy into this logic of mine. I just want to put you in the > bind for an ability in GRASP to discover the closest instance of an objective. > Thats i think something you agreed GRASP will support a long time ago. > > If you do not like to use the fixed TTL value of 255 as a mechanism to help > support the "closest objective announcer" mechanism, then i need to specify > a more complex way to discover the closest objective announcer: > > - objective-values for AN_join_registrar would need to be extended to be a structure like: > > objective-value = [ sender-ttl, method-list [, future-extensions]* ] > method-list = [ method ]*1 > methd = BRSKI-TLS | EST-TLS | ... > sender-ttl = NUM > > (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) Not only do I get the idea, I tested it out many months ago; actually after the discussions in Berlin, I think. In my Pythonic world it was very easy, but it is indeed a bit more complicated than the 255-N method. > > That way, the recipient can compare sender-ttl with the TTL of the received objective > and threeby figue out which one is closest. > > I fine either way. I just tried to go for the most simple, logical option. Right, so the question for the WG (are you all listening?) is whether we want to defend the value of the loop count in limiting propagation of multicast messages. (Remember that it has another role in negotiation sessions, where it really is a loop-prevention counter.) I will note that in testing on looped topologies I have seen looped multicasts dropped because of the session ID; theoretically that is sufficient, and the loop count is logically redundant. Otherwise, me happy. Thanks again for all the work, Brian From nobody Wed Sep 20 00:17:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48EA1331F6 for ; Wed, 20 Sep 2017 00:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5NvvlvpZ6Yg for ; Wed, 20 Sep 2017 00:17:54 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 8DBC0133209 for ; Wed, 20 Sep 2017 00:17:53 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a137so3309829wma.0 for ; Wed, 20 Sep 2017 00:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=jE6lgXnQe5j4VlC+j/WVHz4gvnEsPHiXCuzBv40r8UI=; b=QyQl3P9kw2m2m/nbkUaMWO0CH4/UzJEk//gd/FIo+f0conN+j6HTJyJGGfZJongzdT X5K0Mb8rik13ZuoUIHqbIcsy2JPpouS3cvOaok0+jKsh+CEPmH5lZW62hpTrPqPud/E0 jXBMHFVRz/NacUhq4bnkHzlN8vDfyf7ZQVmL7eFBjEhf+yjiXnqzsUr4E2cN3d7S6Ky8 4bw3F9pMgcXbD5OS6oIIfZObk9g8Nn483sNmfSjxya92TycOlc2ZpyWPemkyAKuDIwml djeSzqnPIHS9JF3aBe9JrBWhAu2fdUDBG+os3uskytlBJsypSXelj0RmPykbaNPDPeuo my5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jE6lgXnQe5j4VlC+j/WVHz4gvnEsPHiXCuzBv40r8UI=; b=eFJ+QD/LHXiqRv6PTZTu6RLGDW0mIzx6I2b7LeBLZC/9osdn81oLLHj3kT+eLowV2L e6wKgrDh62NRFlRTOiHsrrN03cDgVQQ3VF4g3rL5RnHy7QJ2/hAa0AZc+h1L7X3G+Waz 9tFQYFvLa+JLnvRol7m37etYydd9LSx3AtynZwyRlcoo5bNy27WH1Amf38nJG1v1T8PP aWqCNvu+31N90To6AW6nU1a5yj725UGsQUsz2gHacoGuhrSZbNVMYBbqKd3+/jSgZXd5 /RQ5IIQjqHNAF4f7y4S8Ual43eIJq84qVIjjs/6gou56gMyr8qcs9ynJLfYsfVa1bAHJ wZgw== X-Gm-Message-State: AHPjjUhau71S45aRUJCWzRqAOMSUYcvk0LiibibXswC/BcKg28m6YvlI mIIz0hSpjUqhD1vHZHnqJJJncK6x X-Google-Smtp-Source: AOwi7QCVfJVLbw/G6sS+F6hWmnyGf5IhnH1qXh8S1wEmWS324zlTpXnNwBZq6eaZQ+2/T9aueeybpA== X-Received: by 10.28.97.11 with SMTP id v11mr3139744wmb.45.1505891871831; Wed, 20 Sep 2017 00:17:51 -0700 (PDT) Received: from [192.168.1.25] (ANice-652-1-72-101.w86-205.abo.wanadoo.fr. [86.205.71.101]) by smtp.gmail.com with ESMTPSA id 109sm1104592wrc.25.2017.09.20.00.17.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 00:17:50 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de> <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com> <20170919185323.GB10511@faui40p.informatik.uni-erlangen.de> <5D36713D8A4E7348A7E10DF7437A4B927CEC1508@NKGEML515-MBX.china.huawei.com> Message-ID: Date: Wed, 20 Sep 2017 09:17:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CEC1508@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 07:17:57 -0000 Hi Sheng, I'm not aware of any IPR relating to this document. Michael On 20/09/17 02:54, Sheng Jiang wrote: > Hi, Toerless, > > Thanks for your hard and fruitful work. Giving the change mount from -03 version, which is the base for the first WGLC, I feel another WGLC is needed. I will launch a short one-week WGLC on this. Meanwhile, I still not receive IPR disclosure from all authors. I would not be able to move this document forward with the proper IPR disclosures, even after the WGLC passed. > > Cheers, > > Sheng > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert >> Sent: Wednesday, September 20, 2017 2:53 AM >> To: Brian E Carpenter >> Cc: Anima WG >> Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - >> Respond by July 28, 2017 >> >> Thanks, Brian! >> >> Sheng: i think/hop i am trough all outstanding issues with >> stable-connectivity. Please decide what to do next to move to next stage, >> eg: another WG last call or pass to IETF/IESG. >> >> Cheers >> Toerless >> >> On Tue, Sep 19, 2017 at 08:11:56AM +1200, Brian E Carpenter wrote: >>> This is embarassing. For some reason I completely missed the >>> announcement of draft-ietf-anima-stable-connectivity-05, until today. >>> >>> I have now looked at the -05 and -06 versions and I'm happy with the >> result. >>> Regards >>> Brian >>> >>> On 18/09/2017 17:38, Toerless Eckert wrote: >>>> Thanks, Brian: >>>> >>>> The "OLD" paragraph you list was from -04. After your review i had >>>> already changed this in -05 to >>>> >>>> NEW: >>>> >>>> To connect IPv4 only management plane devices/applications with >> the >>>> ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is >>>> necessary. The basic mechanisms for this are defined in SIIT >>>> ([RFC7915]). There are multiple solutions using this mechanisms. >> To >>>> understand the possible solutions, we consider the requirements: >>>> .... >>>> >>>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools. >>>> ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https:/ >>>> /tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt >>>> >>>> I also did spend a good amount of time because of your -04 review >>>> and prior request by mohammed to detail in the following >> parapgraphs >>>> the possible options in more detail. That text leverages the 'SIIT' >>>> term and discusses the EAM solutions (RFC7757 is best). >>>> >>>> Given how this is an informational OPS document, i think it is >>>> helpfull to elaborate on the understood details of requirements and >>>> how known current solutions fit them. >>>> >>>> The fact that none of the >>>> currently defined NAT solutions provides for the most simple >>>> possible configuration (aka: minimum number of prefix EAM's to >>>> configure) is also IMHO a perfectly valid outcome for an OPS >> document. >>>> It could mean that users will simply accept the need for longer >>>> mnaual NAT config (long list of 1:1 mappings) or vendors implement a >>>> proprietary EAM (explicit address mapping) CLI to make it simpler. >>>> Or users will move faster to IPv6 on the NOC ;-) >>>> >>>> So, for the time being, i just commited -06 with the second fix. >>>> >>>> Let me know what you folks think about WG last call status of the >>>> stable connectivity draft. >>>> >>>> Cheers >>>> Toerless >>>> >>>> On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote: >>>>> To cut a long story short, here's a friendly suggestion. The goal >>>>> is to avoid comments during IETF/IESG review that the NAT text is too >> vague: >>>>> OLD >>>>> To bridge an IPv4 only management plane with the ACP, IPv4 to >> IPv6 >>>>> NAT can be used. This NAT setup could for example be done in >> Rt1r1 >>>>> in above picture to also support IPv4 only NMS hots connected to >>>>> NOClan. >>>>> >>>>> NEW >>>>> To bridge an IPv4-only management plane with the ACP, IPv4 to >> IPv6 >>>>> translation [RFC 6145] could be used. This could for example be >> done in Rt1r1 >>>>> in the above picture to also support IPv4-only NMS hosts >> connected to >>>>> NOClan. Details of the address mapping to be used would >> depend on >>>>> the exact scenario and are not specified here. >>>>> >>>>> And yes, I like this: >>>>> >>>>>> i'd suggest to replace the "split-horizon" sentence with: >>>>>> >>>>>> Operators may therefore need to use a private DNS setup for the >>>>>> ACP ULA addresses. This is the same setup that would be necessary >>>>>> for using >>>>>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, >>>>>> last paragraph. In [RFC6950] section 4, these setups are discussed in >> more detail. >>>>> Regards >>>>> Brian >>>>> >>>>> On 15/09/2017 09:18, Toerless Eckert wrote: >>>>>> Hi Brian, >>>>>> >>>>>> Sorry, for the delay. I have not sen further feedback on >>>>>> stable-connectivity-05 bside this mail of yours. See answers >>>>>> below, let me know if you want me to rev with the one possible >> textual improvement or if we think -05 is good enough. >>>>>> Cheers >>>>>> Toerless >>>>>> >>>>>> On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: >>>>>>> I'm just coming back on a couple of points. Generally -05 is almost >> there... >>>>>>>> See the rewritten SIIT section. IMHO, there can be no simpler >>>>>>>> "network" based address translation. Where network based >> means >>>>>>>> that the translation happens in some device he network operator >> needs to provision. Like the ACP edge device. >>>>>>>> Or even an additional address translation device. >>>>>>>> >>>>>>>> So, the only IMHO easier option is when the OS of the NMS host >>>>>>>> would internally have IPv4/IPv6 translation so the device/VM >> looks to the outside like full IPv6. >>>>>>> Yes, that is exactly the effect of 464XLAT in the end-system (not >>>>>>> in the router). >>>>>> I found rfc6877 a confusing read, but from what i figure, it's not >>>>>> exactly what i was thinking of: with rfc6877, you still need the >>>>>> server side to have a reachable/mappable >>>>>> IPv4 address, and that is something any device in the ACP does not >> have naturally. >>>>>> (aka: NOC server as client connecting to ACP device, ACP device is >> server). >>>>>> If i already need to set up some other form of NAT to give an ACP >>>>>> device an outside IPv4 address, then 464XLAT does not buy me any >> simplifications. >>>>>> I was rather thinking of taking the NAT network function that i >>>>>> was describing and simply embody them in a set of linux NAT rules >>>>>> configured on on the NOC linux system that runs the IPv4-only NMS >>>>>> application. Aka: Not a novel NAT scheme, but just a way to avoid >>>>>> having to deal with the problem in the network (adding a NAT >> device you would otherwise not need): >>>>>> Its a NMS host problme, deal with it in the NMS host. If you can >>>>>> not change the app, let the OS do the NAT. Of course, this would >>>>>> not work for the poor customer who bought a black-blox NMS >> soution >>>>>> which may run windows, or where you can not configure the linux. >>>>>> Then again, nowadays, most NOC components should be software in >> VMs, and for those, you should certainly be able to do the NAT in the >> vswitch of the server. >>>>>> In any case: my interest in expanding the NAT section further is >> quite limited. >>>>>> The whole goal of the NAT section was to explain that you need 1:1 >>>>>> address mapping and that you can hack this up in likely most >>>>>> available routers with NAT support, but do not consider this to be >>>>>> a good long term solution but use it as a stopgap to upgrade your >> NOC software to IPv6. >>>>>> No idea why IETF draft/RFC doesn't allow me to write such a simple >>>>>> paragraph ;-)) >>>>>> >>>>>> So, let me know if you feel strongly anything that should be >>>>>> added/modified to the NAT section. >>>>>> >>>>>>>> Alas, i didn't have the time to investigate these options. And >>>>>>>> most likely if at all you could only make those work for linux. >>>>>>> Linux or Windows, yes. In a vendor's router o/s, who knows? But >>>>>>> maybe they will all support IPv6 anyway? >>>>>> Lets hope so, yes. >>>>>> >>>>>>>> So, for now i just remove the note and clarified the last sentence >> a bit. >>>>>>>> If there is anything specific to be said bout why 464XLAT might >>>>>>>> be better longer term, let me know and i can add it. For now it >>>>>>>> looks like yet another network device configured option to me, >>>>>>>> but i have not tried to understand it all the way. >>>>>>> I think you'd need one of the 464XLAT authors to have a look at >>>>>>> the scenario, because I don't claim to understand it all. >>>>>> Well, the analysis i made above (server must support IPv4 as >>>>>> stated in the RFC) makes me discount it as a more beneficial option >> to mention. >>>>>>>>>> Using current registration options implies that there will >> not be >>>>>>>>>> reverse DNS mapping for ACP addresses. >>>>>>>>> Really? I assume we're talking about two-faced DNS, and afaik >>>>>>>>> nothing stops an operator providing reverse mapping in the >> private DNS. >>>>>>>>> That seems to be implied by the following paragraphs, so the >>>>>>>>> text seems inconsistent anyway. >>>>>>>> I know it under the name "split-horizon DNS". Is there any >> reference ? >>>>>>> The DNS community in the IETF hates split DNS so much that not >>>>>>> much has been written about it. I did find these: >>>>>>> https://tools.ietf.org/html/rfc6950#section-4 >>>>>>> https://tools.ietf.org/html/rfc7157#section-6.3 >>>>>>> https://tools.ietf.org/html/draft-richardson-homenet-secret-garde >>>>>>> ns >>>>>> RFC1918 actually explains it succinctly without giving it a name. >>>>>> RFC4193 only tells you what you shouldn't do with DNS. How >>>>>> helpfull ;-) >>>>>> >>>>>> So, let me know if you think it's worth creating another >>>>>> stable-connectivity rev, i'd suggest to replace the "split-horizon" >> sentence with: >>>>>> Operators may therefore need to use a private DNS setup for the >>>>>> ACP ULA addresses. This is the same setup that would be necessary >>>>>> for using >>>>>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, >>>>>> last paragraph. In [RFC6950] section 4, these setups are discussed in >> more detail. >>>>>> Cheers >>>>>> Toerless >>>>>> >>>>>>> Regards, >>>>>>> Brian >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Sep 20 02:39:40 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4F6132403; Wed, 20 Sep 2017 02:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TgzzHrwBIz_V; Wed, 20 Sep 2017 02:39:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B117133187; Wed, 20 Sep 2017 02:39:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOY73551; Wed, 20 Sep 2017 09:39:34 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 20 Sep 2017 10:39:33 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 20 Sep 2017 17:39:26 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: Calling new works and discussion Thread-Index: AdMx9E4PHxMyI1m7TYKG/qrd4Wym+w== Date: Wed, 20 Sep 2017 09:39:26 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CEC4B49@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CEC4B49NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59C23757.0005, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 853c9c6952b6785ff181f0d07652bb94 Archived-At: Subject: [Anima] Calling new works and discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 09:39:38 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CEC4B49NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all ANIMA, As we are sending more documents to IESG for publication, the group has del= ivered most of our original milestones without boiling the ocean. We are no= w in a little bit more confidence to explore slightly wider area of autonom= ic networking. We are now calling new works/work proposals. We would like t= o start to discuss new potential works and whether they are doable, whether= they are worth to solve by ANIMA WG, whether ANIMA is the right WG for it,= etc. The below is three rough categories that may be interested by the group. - Leveraging the Current ANI (GRASP, ACP & BRISK) - ANI extension & other reusable components for AN - Autonomic Service Agents over ANI and other reusable components Thanks and regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CEC4B49NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all ANIMA,

 

As we are sending more document= s to IESG for publication, the group has delivered most of our original mil= estones without boiling the ocean. We are now in a little bit more confiden= ce to explore slightly wider area of autonomic networking. We are now calling new works/work proposals. We woul= d like to start to discuss new potential works and whether they are doable,= whether they are worth to solve by ANIMA WG, whether ANIMA is the right WG= for it, etc.

 

The below is three rough catego= ries that may be interested by the group.

 

-=    &n= bsp;      Leveraging the Current = ANI (GRASP, ACP & BRISK)

-=    &n= bsp;      ANI extension & oth= er reusable components for AN

-=    &n= bsp;      Autonomic Service Agent= s over ANI and other reusable components

 

Thanks and regards,<= /span>

 

Sheng

--_000_5D36713D8A4E7348A7E10DF7437A4B927CEC4B49NKGEML515MBXchi_-- From nobody Wed Sep 20 10:07:34 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB65C133020; Wed, 20 Sep 2017 10:07: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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6Ezw0RF6_in; Wed, 20 Sep 2017 10:07:30 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81962126D0C; Wed, 20 Sep 2017 10:07:30 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D2C1058C4FA; Wed, 20 Sep 2017 19:07:26 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id BA590B0CC3A; Wed, 20 Sep 2017 19:07:26 +0200 (CEST) Date: Wed, 20 Sep 2017 19:07:26 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org Message-ID: <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 17:07:34 -0000 Thanks, Brian a) i will fix the ABNF with next update (for Shengs review). b) Given the order of likely last calls, i will suggest in the bootstrap meeting that we define the AN_Registrar objective authoritatively in ACP and BRSKI adds to it the "BRSKI" method. BRSKI already should have no issue having ACP as normative reference. Lets see how that discussion goes. c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the objective-value structure to include the TTL and method, eg: fixup the following: > > objective-value = [ sender-ttl, method-list [, future-extensions]* ] > > method-list = [ method ]*1 > > methd = BRSKI-TLS | EST-TLS | ... > > sender-ttl = NUM If we do not get further feedback from the WG supporting my simple TTL=255 approach, i would rather go with this structure approach, so that we can let the TTL disussion take its natural course (figure out it should be 255 over 10 years ;-P). Primarily, because i like the idea to show off a bit the flexiblity of GRASP for the objective value being a structure. ANd because it would be a good reference for further objectives where we want to discover/select closest instance (and we didn't include this into the GRASP document proper). Cheers Toerless > > (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) > > Not only do I get the idea, I tested it out many months ago; actually after the > discussions in Berlin, I think. In my Pythonic world it was very easy, but it is > indeed a bit more complicated than the 255-N method. > > > > > That way, the recipient can compare sender-ttl with the TTL of the received objective > > and threeby figue out which one is closest. > > > > I fine either way. I just tried to go for the most simple, logical option. > > Right, so the question for the WG (are you all listening?) is whether we > want to defend the value of the loop count in limiting propagation of multicast > messages. (Remember that it has another role in negotiation sessions, where > it really is a loop-prevention counter.) > > I will note that in testing on looped topologies I have seen looped multicasts > dropped because of the session ID; theoretically that is sufficient, and the > loop count is logically redundant. > > Otherwise, me happy. > > Thanks again for all the work, > > Brian From nobody Wed Sep 20 19:51:49 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878451320DC; Wed, 20 Sep 2017 19:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 YWi73DvCYUEX; Wed, 20 Sep 2017 19:51:46 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8832126DD9; Wed, 20 Sep 2017 19:51:45 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id b11so2761445pgn.12; Wed, 20 Sep 2017 19:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZhQ79oxS2eRliAMWVjpXxbT2bDW/j5NRsu+3JUA6hLQ=; b=KcS/Qjg8WpJuPWu60WNSZx7/w3a1Ol3XCIPojs9tjuHb4h1qechhJgaOaBXzXzRIvR CcnQKe6b5OCtebAAF+tNuWgeGdesBzPy5P1sLFRsxQc1kMLnVFRbuuceWjYE1pPtjjOT gKqYr6X306a6khQwuiZY4kuO7UyXrD1fXEHE4G6P6CVIyzh42zokaXlHNJ9UK/ggiJMx kUQQQtqcFClJLSNrA+dRIl0QBkY41Rxh4FCV5dWwP1Y/gInAzSEIb+JNew4sXlzsV+H9 I+yRRnNZQFhEyTDlPcmREYMFCNwJWx+dvNu7lGr9EoS/TXIerpRBwyW7XD3bXhf5RpCm uB6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZhQ79oxS2eRliAMWVjpXxbT2bDW/j5NRsu+3JUA6hLQ=; b=Etwo2T6J1SG8+JfJFCPf2m8hlJgT/Sa7nqVzlTHuIgnLzEFioZnaCVOVhOX0hjnPD3 ckVjCCIHU2JL30f06NZk6hv/v/HMJ7kminMrDYX3E7GnW145VI/bK0D2LrBAhX6qClTw vDF8pyBOsUz7/JcBUTzB27yTX9rkR8LDW9nxMde6Ss0q3c0Z30C7Ejrmm6rRupfRdWKt tBF8E+n0lB49x6W7E0JHwFWKx22juUMrCYqcNw7KEFhObX/+jazNSJbQ+XPL9I2tQrq8 1UgzOQzWYtVrr6Zxnzw/NT93dxWyQIqa/ZazsbINJg5xmBtNwQG2P55Jnza9rkYDfQIy aVIg== X-Gm-Message-State: AHPjjUjbUeEh0BAr92nRrmBPMkOQushi6QisA9nYIji9noOyUjYRpCTw l5RZkDNHVvy76iMX/8Re1mS8kg== X-Google-Smtp-Source: AOwi7QAhd7aONMGjx+6HLb9KK90Th4SNxxKP3Eu0Tf3vKLG8OhSumDb565hX0iW52SRAzSW8tTEiVw== X-Received: by 10.84.136.34 with SMTP id 31mr4117995plk.174.1505962305039; Wed, 20 Sep 2017 19:51:45 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 77sm389062pfi.103.2017.09.20.19.51.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 19:51:43 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 21 Sep 2017 14:51:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 02:51:47 -0000 On 21/09/2017 05:07, Toerless Eckert wrote: > Thanks, Brian > > a) i will fix the ABNF with next update (for Shengs review). Great. > b) Given the order of likely last calls, i will suggest in the bootstrap meeting that we > define the AN_Registrar objective authoritatively in ACP and BRSKI adds to it the > "BRSKI" method. BRSKI already should have no issue having ACP as normative reference. > Lets see how that discussion goes. Works for me. Just decide whether you want AN_registrar or AN_join_registrar. > c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the > objective-value structure to include the TTL and method, eg: fixup the following: > >>> objective-value = [ sender-ttl, method-list [, future-extensions]* ] >>> method-list = [ method ]*1 >>> methd = BRSKI-TLS | EST-TLS | ... >>> sender-ttl = NUM I would go for this: objective-value = [ sender-ttl, method-list, *[ future-extensions ] ] method-list = [ +method ] method = "BRSKI-TLS" / "EST-TLS" sender-ttl = 0..255 future-extensions = any The "+" prefix means 1 or more in CDDL and "*" means zero or more. The commas in lists like [+method] are implied. (I checked this fragment with the CDDL tool.) I used strings for the method for simplicity; if you want to save a few bytes you could use symbols but then they have to be assigned values like BRSKI-TLS = 0 EST-TLS = 1 and you end up with another IANA registry in your life. Regards Brian > If we do not get further feedback from the WG supporting my simple TTL=255 approach, > i would rather go with this structure approach, so that we can let the TTL disussion > take its natural course (figure out it should be 255 over 10 years ;-P). Primarily, > because i like the idea to show off a bit the flexiblity of GRASP for the objective > value being a structure. ANd because it would be a good reference for further objectives > where we want to discover/select closest instance (and we didn't include this into the > GRASP document proper). > > Cheers > Toerless > >>> (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) >> >> Not only do I get the idea, I tested it out many months ago; actually after the >> discussions in Berlin, I think. In my Pythonic world it was very easy, but it is >> indeed a bit more complicated than the 255-N method. >> >>> >>> That way, the recipient can compare sender-ttl with the TTL of the received objective >>> and threeby figue out which one is closest. >>> >>> I fine either way. I just tried to go for the most simple, logical option. >> >> Right, so the question for the WG (are you all listening?) is whether we >> want to defend the value of the loop count in limiting propagation of multicast >> messages. (Remember that it has another role in negotiation sessions, where >> it really is a loop-prevention counter.) >> >> I will note that in testing on looped topologies I have seen looped multicasts >> dropped because of the session ID; theoretically that is sufficient, and the >> loop count is logically redundant. >> >> Otherwise, me happy. >> >> Thanks again for all the work, >> >> Brian > From nobody Thu Sep 21 16:25:13 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2091331E4; Thu, 21 Sep 2017 16:25:10 -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 Ugw8BoanbWPY; Thu, 21 Sep 2017 16:25:08 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592481320D8; Thu, 21 Sep 2017 16:25:08 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id b70so3950051pfl.8; Thu, 21 Sep 2017 16:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vHG5ajhri5dlYPeBliMBY5YgEm6R01ay7bNjtRp6zO0=; b=pRlErF2gB7TvuT9Z5fkjK52JjWR+lnS+xF2hAPIJLOxn73XHiXuW1sEBxxaVe5DwHo z2IlVwBGuFUa+Tf4KOkaFQqVqnq0sTbT2YIcXFOgpW7o2z/OBFi3AEZYB6/6O2O4wJ62 w9lj8/6eUrhSxbqPs/DU6aCI+HvhFAS9bB8SJdvSZ4qNW0aLHoqvf4OSo1Uz0bmMVpVc VA/q3DiElHD8tOF2/VjTzlm208A49f92Bdbm0A0yGNNQSXh431q68gH+nH5zokKD3E2E yNOJWCVaumephMy0b+nX8uOf0ZB7IL3YJRlKxMHBw1Dl7z97K6pbgsPFnMgfTLgCJcEV IOIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vHG5ajhri5dlYPeBliMBY5YgEm6R01ay7bNjtRp6zO0=; b=k8q3Dqk1mJDXLHUHlfPCfwClbS5e6vPkrH05BT7MrWfamV33Cm4q96NktregI5SGd6 Mv+jEU2WiCFxO6Ul6sYNQEr/kXbxvkGi8g1DltTYN/9N2h7JjpSK9ywiaZx2yhXwK/dI WJhaUYaY/TaKxTuujaZ+QbIjpqFGkxBkmug24ZT/g9KfdgV6IYVy8IP58z50V4HgDXX0 ABFk0xEv3hwXtlvynuL1XuLsM0qf5/vUGvbay4rzKxLn5HVCjO3VCQRPd+mFn0YzfQA7 I7LDZfLGLj+Lno35npLhS4i5akeuFvJPC5HBOaBQfISiCr1Eug3JhedR7/caBW92cn/y HRUA== X-Gm-Message-State: AHPjjUiMG09uUeRX3NcW74skhFSE50eugdrd//l8eMFOMBefLzyYn1c0 AlwXE+BVUXjUQIJY/93NIxtwjA== X-Google-Smtp-Source: AOwi7QAp8IAR3iQUMGdHvL5AfvAWu44RWta/hFT5xRQ1Q3vrysDg2TvByo0o4WtP+G3Uo9lb1AxNXA== X-Received: by 10.98.156.207 with SMTP id u76mr7289705pfk.190.1506036307275; Thu, 21 Sep 2017 16:25:07 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l85sm4565299pfb.176.2017.09.21.16.25.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Sep 2017 16:25:06 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 22 Sep 2017 11:25:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 23:25:10 -0000 By the way, I just realised the obvious: we could write much more succinct CDDL definitions of objective-values if we wanted to. For my suggestion below, this means exactly the same: objective-value = [ 0..255, [ +("BRSKI-TLS" / "EST-TLS") ], *[ any ] ] Regards Brian On 21/09/2017 14:51, Brian E Carpenter wrote: > On 21/09/2017 05:07, Toerless Eckert wrote: >> Thanks, Brian >> >> a) i will fix the ABNF with next update (for Shengs review). > > Great. > >> b) Given the order of likely last calls, i will suggest in the bootstrap meeting that we >> define the AN_Registrar objective authoritatively in ACP and BRSKI adds to it the >> "BRSKI" method. BRSKI already should have no issue having ACP as normative reference. >> Lets see how that discussion goes. > > Works for me. Just decide whether you want AN_registrar or AN_join_registrar. > >> c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the >> objective-value structure to include the TTL and method, eg: fixup the following: >> >>>> objective-value = [ sender-ttl, method-list [, future-extensions]* ] >>>> method-list = [ method ]*1 >>>> methd = BRSKI-TLS | EST-TLS | ... >>>> sender-ttl = NUM > > I would go for this: > > objective-value = [ sender-ttl, method-list, *[ future-extensions ] ] > method-list = [ +method ] > method = "BRSKI-TLS" / "EST-TLS" > sender-ttl = 0..255 > future-extensions = any > > The "+" prefix means 1 or more in CDDL and "*" means zero or more. > The commas in lists like [+method] are implied. (I checked > this fragment with the CDDL tool.) > > I used strings for the method for simplicity; if you want to save a few > bytes you could use symbols but then they have to be assigned values like > BRSKI-TLS = 0 > EST-TLS = 1 > and you end up with another IANA registry in your life. > > Regards > Brian > >> If we do not get further feedback from the WG supporting my simple TTL=255 approach, >> i would rather go with this structure approach, so that we can let the TTL disussion >> take its natural course (figure out it should be 255 over 10 years ;-P). Primarily, >> because i like the idea to show off a bit the flexiblity of GRASP for the objective >> value being a structure. ANd because it would be a good reference for further objectives >> where we want to discover/select closest instance (and we didn't include this into the >> GRASP document proper). >> >> Cheers >> Toerless >> >>>> (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) >>> >>> Not only do I get the idea, I tested it out many months ago; actually after the >>> discussions in Berlin, I think. In my Pythonic world it was very easy, but it is >>> indeed a bit more complicated than the 255-N method. >>> >>>> >>>> That way, the recipient can compare sender-ttl with the TTL of the received objective >>>> and threeby figue out which one is closest. >>>> >>>> I fine either way. I just tried to go for the most simple, logical option. >>> >>> Right, so the question for the WG (are you all listening?) is whether we >>> want to defend the value of the loop count in limiting propagation of multicast >>> messages. (Remember that it has another role in negotiation sessions, where >>> it really is a loop-prevention counter.) >>> >>> I will note that in testing on looped topologies I have seen looped multicasts >>> dropped because of the session ID; theoretically that is sufficient, and the >>> loop count is logically redundant. >>> >>> Otherwise, me happy. >>> >>> Thanks again for all the work, >>> >>> Brian >> From nobody Fri Sep 22 01:44:27 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB81329B5; Fri, 22 Sep 2017 01:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aug8N2CNkOZ5; Fri, 22 Sep 2017 01:44:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FBB132025; Fri, 22 Sep 2017 01:44:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPC06330; Fri, 22 Sep 2017 08:44:20 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 22 Sep 2017 09:44:19 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 22 Sep 2017 16:44:14 +0800 From: "Liubing (Leo)" To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: ANI Objectives-//RE: Calling new works and discussion Thread-Index: AdMzedrkJiBUYPFDRmSMErv9P4fgDg== Date: Fri, 22 Sep 2017 08:44:14 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7B@nkgeml514-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7Bnkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59C4CD65.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9b9805d7a65237d529b70f515a5e7702 Archived-At: Subject: [Anima] ANI Objectives-//RE: Calling new works and discussion 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, 22 Sep 2017 08:44:26 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7Bnkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dear all, To response to the Chairs' calling, I'd like to firstly mention an existing= work, draft-carpenter-anima-ani-objectives, which belongs to the first cat= egory as Sheng defined below: > Leveraging the Current ANI (GRASP, ACP & BRISK) It is very specific technical details (just like "option names" in other pr= otocols) related to all ANI components (BRSKI, ACP and GRASP), but necessar= y for interoperability. We used to have some discussion about whether to define these objectives in= each ANI component. But there is two problems as I see: 1. This draft defines an additional value for GRASP message syntax to = indicate transport-protocol. So far it is actually used for BRSKI to indica= te IP-in-IP encapsulation. However, from definition perspective, this value= is generic than BRSKI-specific, so I'm not very sure it is proper to defin= ed it in BRSKI. 2. Technically, it is ok to define each GRASP-objective in each ANI do= cument, but would it be a bit scattered? In any case, I think the ANI objective content should reach consensus and b= e published as soon as possible. Then, the problem again: shall we make it as a standalone draft, or incorpo= rate them into each ANI draft? Best regards, Bing From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Wednesday, September 20, 2017 5:39 PM To: Anima WG Cc: anima-chairs@ietf.org Subject: [Anima] Calling new works and discussion Hi, all ANIMA, As we are sending more documents to IESG for publication, the group has del= ivered most of our original milestones without boiling the ocean. We are no= w in a little bit more confidence to explore slightly wider area of autonom= ic networking. We are now calling new works/work proposals. We would like t= o start to discuss new potential works and whether they are doable, whether= they are worth to solve by ANIMA WG, whether ANIMA is the right WG for it,= etc. The below is three rough categories that may be interested by the group. - Leveraging the Current ANI (GRASP, ACP & BRISK) - ANI extension & other reusable components for AN - Autonomic Service Agents over ANI and other reusable components Thanks and regards, Sheng --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7Bnkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi De= ar all,

=  

To re= sponse to the Chairs’ calling, I’d like to firstly mention an e= xisting work, draft-carpenter-anima-ani-objectives, which belongs to the fi= rst category as Sheng defined below:

> = Leveraging the Current ANI (GRASP, ACP & BRISK)

=  

It is= very specific technical details (just like “option names” in o= ther protocols) related to all ANI components (BRSKI, ACP and GRASP), but n= ecessary for interoperability.

We us= ed to have some discussion about whether to define these objectives in each= ANI component. But there is two problems as I see:

1.      This draft defines an additional value for GRASP message syntax to indic= ate transport-protocol. So far it is actually used for BRSKI to indicate IP= -in-IP encapsulation. However, from definition perspective, this value is generic than BRSKI-specific, so I= 217;m not very sure it is proper to defined it in BRSKI.<= /p>

2.      Technically, it is ok to define each GRASP-objective in each ANI documen= t, but would it be a bit scattered?

=  

In an= y case, I think the ANI objective content should reach consensus and be pub= lished as soon as possible.

Then,= the problem again: shall we make it as a standalone draft, or incorporate = them into each ANI draft?

=  

Best = regards,

Bing<= o:p>

=  

=  

=  

From: = Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Wednesday, September 20, 2017 5:39 PM
To: Anima WG <anima@ietf.org>
Cc: anima-chairs@ietf.org
Subject: [Anima] Calling new works and discussion<= /p>

 =

Hi, all ANIMA,

 

As we are sending more documents to IESG for publica= tion, the group has delivered most of our original milestones without boili= ng the ocean. We are now in a little bit more confidence to explore slightl= y wider area of autonomic networking. We are now calling new works/work proposals. We would like to start to dis= cuss new potential works and whether they are doable, whether they are wort= h to solve by ANIMA WG, whether ANIMA is the right WG for it, etc.

 

The below is three rough categories that may be inte= rested by the group.

 

-       = ; Leveraging the Current ANI (GRASP, ACP & BRISK)=

-       = ; ANI extension & other reusable components for A= N

-       = ; Autonomic Service Agents over ANI and other reusabl= e components

 

Thanks and regards,

 

Sheng

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7Bnkgeml514mbxchi_-- From nobody Fri Sep 22 13:12:18 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B139A132D67 for ; Fri, 22 Sep 2017 13:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] 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 wGxgpsP8vunw for ; Fri, 22 Sep 2017 13:12:14 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9655E133018 for ; Fri, 22 Sep 2017 13:12:14 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id z84so1056369pfi.2 for ; Fri, 22 Sep 2017 13:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rws+d3k64l7HyOqpyJQax43qH2w/5oi8LRD+ZDtwQqk=; b=SdHiUG4O1IpJ2TotJnoU7fCQsRyXcwqjhIdagktvlYzk3VSeK/Zqo1R1/dWNpdTEZN 9vjJwB8kstTrFyD3vZkpS9KSrlEOBg0ghH3+H6+Zyc2T22Gv6J0G5HsI/UPZrGbEKOTo ZVPRW+Zas8dlhHkkCPRqTc/QGcwl1tUyXO8kr/OU0V6ebI0WaUJ1wW1HrS2zdOGD1pmz G9JxTXun2g5NaGr/7a8SaH8ScjdXxyiFElSDcBO8GKSMi0MhEcq4JBLNkMFfkbkpQItF p5kftXN8SQco1NQZJvoC4MovmYgxplxWF/4VqgSpHB1SPkaxOoa/E5XXRJfigZS5oOSE 75Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=rws+d3k64l7HyOqpyJQax43qH2w/5oi8LRD+ZDtwQqk=; b=T+epZC8Ft0cfe6oHNw18yJba3nYfkheK9lfJAhizzbB+LBAOMcI4gddCGmBu0du/Zv iq8s77ob762+iZQQCTM1yPQ1ptfd04p9ctVn+9X2IJcCUl2ZqZwrr72bQInAeCZCDvdZ QQqW1p5NOp+HjFgfkPjEwZBVayH00Oy/VqA+n89mrjVxMavj3AOGoZLo8QRNWYG7DE/g H9nD3ql4zEYBmyo4CX/PQt8/wVUvCbmn2PuwLfOnn6RRA3An6lXs1feZiGaPXeRBAEOS WgHuQ6GYCNkDCKupAdON8EE2MV6g8Ue+PHzDyE9ZsDzxECtctaJ7gMQU0nltjYCXLtsz GSnA== X-Gm-Message-State: AHPjjUi6nknuEaepNtnQyytQ7JvCrxu55TL3fgKbapud4GuTSDzMWLVf 7f6/WJOpWew6zqH1juImrN0/PA== X-Google-Smtp-Source: AOwi7QCxjOZAwDEz8MttQezudBmtDsNjl9IoXA1r8Acjosemra9YoHVAdlPSMuUqd+IyPzdBIWy9fA== X-Received: by 10.99.119.195 with SMTP id s186mr254206pgc.263.1506111133762; Fri, 22 Sep 2017 13:12:13 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 13sm750324pfm.138.2017.09.22.13.12.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 13:12:12 -0700 (PDT) To: anima@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7B@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <63d6e469-c366-4a63-490d-66f38ee539a6@gmail.com> Date: Sat, 23 Sep 2017 08:12:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7B@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ANI Objectives-//RE: Calling new works and discussion 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, 22 Sep 2017 20:12:17 -0000 On 22/09/2017 20:44, Liubing (Leo) wrote: > Hi Dear all, > > To response to the Chairs' calling, I'd like to firstly mention an existing work, draft-carpenter-anima-ani-objectives, which belongs to the first category as Sheng defined below: >> Leveraging the Current ANI (GRASP, ACP & BRISK) > > It is very specific technical details (just like "option names" in other protocols) related to all ANI components (BRSKI, ACP and GRASP), but necessary for interoperability. > We used to have some discussion about whether to define these objectives in each ANI component. But there is two problems as I see: > > 1. This draft defines an additional value for GRASP message syntax to indicate transport-protocol. So far it is actually used for BRSKI to indicate IP-in-IP encapsulation. However, from definition perspective, this value is generic than BRSKI-specific, so I'm not very sure it is proper to defined it in BRSKI. > > 2. Technically, it is ok to define each GRASP-objective in each ANI document, but would it be a bit scattered? > > In any case, I think the ANI objective content should reach consensus and be published as soon as possible. > Then, the problem again: shall we make it as a standalone draft, or incorporate them into each ANI draft? The first conclusion after the previous IETF was to add the objectives into the corresponding drafts. That is in progress for BRSKI and ACP. For the "stable connectivity" draft, it is not included in draft-ietf-anima-stable-connectivity-06 but it is also not clear what is needed. Toerless should comment, but I think he believes that NOC services are expected to be discovered via DNS-SD in non-ANIMA scenarios, so maybe the best approach is to bridge ANIMA based discovery to DNS-SD somehow. I have done a little work on that topic**, but we need some clarity on the requirements. So in answer to your question, I think we can let the ani-objectives draft expire, but we may need a new draft on the DNSSD aspect. ** At https://github.com/becarpenter/graspy, see AskDNSSD.py and GetDNSSD.py Regards Brian From nobody Fri Sep 22 16:02:13 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620FB13303F; Fri, 22 Sep 2017 16:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNWT7JVOsnKF; Fri, 22 Sep 2017 16:02:02 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F6A132705; Fri, 22 Sep 2017 16:01:57 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A0C1D58C4D2; Sat, 23 Sep 2017 01:01:53 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 873A8B0CC7D; Sat, 23 Sep 2017 01:01:53 +0200 (CEST) Date: Sat, 23 Sep 2017 01:01:53 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org Message-ID: <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] GRASP objective details for registrar (was: Re: ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 23:02:12 -0000 Some opinions/suggestions: a) Name of objective should be "ACP_registrar". The registrar supports multiple services, eg: brski-join, est-renewal, and if we had ducklings also est-enroll. ACP_*, because it's not AN_* unless we could guarantee we always have intent (which we don't), and not ANI_* because we also do not necessarily always have BRSKI (but eg: Netconf Zero Touch + ACP). But this is terminology. I have an option, but i am happy getting anything that works. ultimately i do not care about this part. b) More importantliy, elements in objective-value should be standardizeable, reuseable, extensible and optional. AFAIK, for extensible and optionality, we need to use maps instead of arrays in CBOR ({} instead of [] in CDDL). For standardizeable, we should define the structure to include standards elements c) The IMHO most easy and useful standardized options are the ones that a) allow for objective services to be aligned with DNS-SD so that we have a superset of the service-selection facilities of DNS-SD and if desired the same name space. d) So, for the ACP draft, i think i would want to write down the most simple subset of the intended syntax for objective-values and not describe the background and also not yet start to worry about IANA registration, because that would make sense only once we agree on the need of extensibility. Worst case, the following syntax would not be extended in future, then we just made it a bit more generic than necessary: objective-value = { std: { sender-ttl: 255, service: { "brski-join" }, service: { "est-renew" }, } } e) In a separate small document we could detail those GRASP aspects in more detail, this doc could update ACP RFC, so we can take more time without holding up ACP RFC. And we could then also ask for the IANA registries when we feel that there really is enough future add-ons to justify the registry. Here is my current definition i would use (aka superset of avove example): objective-value = { *parameter } ; map of parameters to be extensible and ; all prameters can be optional. parameter /= std: { *std-param } ; create subset of parameters standardized ; the std-param names would be an IANA registry. ; parameter /= ... ; Any parameter specific to an objective. std-param /= sender-ttl: 1..255 ; value of ttl field of flood-message ; as set by sender. Upon receipt, ; (sender-ttl - ttl) is the distance of ; the receiver from the sender. std-param /= service: { ; Services supported by objective. service-name, ; Name must be registered according to RFC6335 *service-param ; would therefore also useable in RFC2782 } ; For newly registered service names, do not ; allocate/register protocol/port numbers. These ; are learned via other GRASP message elements service-name = tstr service-param /= selection-param selection-param /= priority: 0..65535 ; Same semantic as rfc2782. Default = 0 selection-param /= weight: 0..65535 ; Same semantic as rfc2782. Default = 0 Aka: pretty much allowing 1:1 mapping of the DNS-SD SRV parameters we need (service-name, priority, weight) to GRASP "services". And make "services" a sub-element of an objective. And RFC6335 also explains why not to use capital letters in "est-renew", "brski-join" (uncommon to use capital letters in RFC6335). As you see, i did not make sender-ttl part of service, so we may use sender-ttl even if some objective does not want a "service:" parameter. We may need to add locator options to service-params, thats and example of how this is yet incomplete. With just one service indicated the locator element of the existing GRASP is sufficient. Cheers Toerless On Thu, Sep 21, 2017 at 02:51:48PM +1200, Brian E Carpenter wrote: > Works for me. Just decide whether you want AN_registrar or AN_join_registrar. a) OK, let me obsess about terminology a bit: I always think of objectives as services, which would make "XXX_registrar" the right word - it does not prescribe what to do with the service: ignore, consume(join), buy-stock, resell, attack... "objective" to me always implies an action, which i think is why "XXX_join_registrar" was preferred choosen ? When we, as i suggest have the same registrar objective used for both BRSKI and EST, we have at least two actions: BRKI-join and EST-renew. Logically we could also have EST-enroll, but that one is a no-no (eg: ducking enrollment without voucher). So we could call what we named "method" also "action" or "service" and call them BRSKI-join and EST-renew. But those words do then not imply the transport stack to use (TLS). I would like XXX = ACP because XXX = AN seems to imply the network is autonomic, which i think by definition it is not unless we have intent ;-P. XXX = ANI would also be wrong if for example we combine ACP with Netconf Zero Touch and only offer EST-renew but not BRSKI-enroll. b) I would like the parameters of an objective reuseable, extensible and optional when not needed. I think that we need to use a map instead of an array in CBOR to get extensibility and optionality (CDDL concerned about the word objective - i am never sure if i will not run into a service where there is really more than > > > c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the > > objective-value structure to include the TTL and method, eg: fixup the following: > > > >>> objective-value = [ sender-ttl, method-list [, future-extensions]* ] > >>> method-list = [ method ]*1 > >>> methd = BRSKI-TLS | EST-TLS | ... > >>> sender-ttl = NUM > > I would go for this: > > objective-value = [ sender-ttl, method-list, *[ future-extensions ] ] > method-list = [ +method ] > method = "BRSKI-TLS" / "EST-TLS" > sender-ttl = 0..255 > future-extensions = any > > The "+" prefix means 1 or more in CDDL and "*" means zero or more. > The commas in lists like [+method] are implied. (I checked > this fragment with the CDDL tool.) > > I used strings for the method for simplicity; if you want to save a few > bytes you could use symbols but then they have to be assigned values like > BRSKI-TLS = 0 > EST-TLS = 1 > and you end up with another IANA registry in your life. > > Regards > Brian > > > If we do not get further feedback from the WG supporting my simple TTL=255 approach, > > i would rather go with this structure approach, so that we can let the TTL disussion > > take its natural course (figure out it should be 255 over 10 years ;-P). Primarily, > > because i like the idea to show off a bit the flexiblity of GRASP for the objective > > value being a structure. ANd because it would be a good reference for further objectives > > where we want to discover/select closest instance (and we didn't include this into the > > GRASP document proper). > > > > Cheers > > Toerless > > > >>> (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) > >> > >> Not only do I get the idea, I tested it out many months ago; actually after the > >> discussions in Berlin, I think. In my Pythonic world it was very easy, but it is > >> indeed a bit more complicated than the 255-N method. > >> > >>> > >>> That way, the recipient can compare sender-ttl with the TTL of the received objective > >>> and threeby figue out which one is closest. > >>> > >>> I fine either way. I just tried to go for the most simple, logical option. > >> > >> Right, so the question for the WG (are you all listening?) is whether we > >> want to defend the value of the loop count in limiting propagation of multicast > >> messages. (Remember that it has another role in negotiation sessions, where > >> it really is a loop-prevention counter.) > >> > >> I will note that in testing on looped topologies I have seen looped multicasts > >> dropped because of the session ID; theoretically that is sufficient, and the > >> loop count is logically redundant. > >> > >> Otherwise, me happy. > >> > >> Thanks again for all the work, > >> > >> Brian > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Sep 22 16:06:25 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC87B13307F for ; Fri, 22 Sep 2017 16:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URI_NOVOWEL=0.5] 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 Yw0AegeouldF for ; Fri, 22 Sep 2017 16:06:22 -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 57A13132705 for ; Fri, 22 Sep 2017 16:06:22 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A075E58C4D2; Sat, 23 Sep 2017 01:06:18 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 88ED9B0CC7D; Sat, 23 Sep 2017 01:06:18 +0200 (CEST) Date: Sat, 23 Sep 2017 01:06:18 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org Message-ID: <20170922230618.GB32014@faui40p.informatik.uni-erlangen.de> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7B@nkgeml514-mbx.china.huawei.com> <63d6e469-c366-4a63-490d-66f38ee539a6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63d6e469-c366-4a63-490d-66f38ee539a6@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] ANI Objectives-//RE: Calling new works and discussion 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, 22 Sep 2017 23:06:24 -0000 Thanks, Brian I thought i had mentioned elsewhere already that one follow-on work i would like to write up (hopefully until singapore) is a simple set of GRASP objectives to allow autoconfigurion of the ANI infra against common NOC services. This would exactly be a target standards track followup work from the "stable-connectivity concept. It would use exactly the format i descriped for GRASP objective-value in my last email. I primarily have to figure out how to cut the work into one or more small docs. In any case i would first want to concentrate on the small add-on / refinements needed to implement full systems out of the current charter item work. Cheers Toerless On Sat, Sep 23, 2017 at 08:12:21AM +1200, Brian E Carpenter wrote: > On 22/09/2017 20:44, Liubing (Leo) wrote: > > Hi Dear all, > > > > To response to the Chairs' calling, I'd like to firstly mention an existing work, draft-carpenter-anima-ani-objectives, which belongs to the first category as Sheng defined below: > >> Leveraging the Current ANI (GRASP, ACP & BRISK) > > > > It is very specific technical details (just like "option names" in other protocols) related to all ANI components (BRSKI, ACP and GRASP), but necessary for interoperability. > > We used to have some discussion about whether to define these objectives in each ANI component. But there is two problems as I see: > > > > 1. This draft defines an additional value for GRASP message syntax to indicate transport-protocol. So far it is actually used for BRSKI to indicate IP-in-IP encapsulation. However, from definition perspective, this value is generic than BRSKI-specific, so I'm not very sure it is proper to defined it in BRSKI. > > > > 2. Technically, it is ok to define each GRASP-objective in each ANI document, but would it be a bit scattered? > > > > In any case, I think the ANI objective content should reach consensus and be published as soon as possible. > > Then, the problem again: shall we make it as a standalone draft, or incorporate them into each ANI draft? > > The first conclusion after the previous IETF was to add the objectives into the > corresponding drafts. That is in progress for BRSKI and ACP. For the "stable > connectivity" draft, it is not included in draft-ietf-anima-stable-connectivity-06 > but it is also not clear what is needed. Toerless should comment, but I think > he believes that NOC services are expected to be discovered via DNS-SD > in non-ANIMA scenarios, so maybe the best approach is to bridge ANIMA based > discovery to DNS-SD somehow. I have done a little work on that topic**, > but we need some clarity on the requirements. > > So in answer to your question, I think we can let the ani-objectives draft > expire, but we may need a new draft on the DNSSD aspect. > > ** At https://github.com/becarpenter/graspy, see AskDNSSD.py and GetDNSSD.py > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Sep 22 20:31:42 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C813132D22; Fri, 22 Sep 2017 20:31: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 F3wOxUltywLf; Fri, 22 Sep 2017 20:31:38 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 70D1013293A; Fri, 22 Sep 2017 20:31:38 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id u18so1508679pgo.0; Fri, 22 Sep 2017 20:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cQoMXScqu8wvHEYT8rsMfqnaOQMpoG1FOoqlZfwEbOM=; b=nseHaBYjLp8zOPxMqRUpxZXmL8qTO2eD0m+EKjuqagrQ+pk46KZ/lxCNlqLbJ+NFHX 1hug/bDjWWtQ8316xCa2whcZ2aCzgvF3Bdb3+2g5pIUZgM661R+xe7zqMPSLBZjKa1Nx E5QOaGWIyvDbxtkG35NG/j6NbTK1sF2VhcruWihtEcl2g8BI/JFYgvpFDhmIaDXXazAT BxadAGbf64VjRHNsjJRXRBUAnAneBgBnn5wUCoS4FnYU+Qq9xRt+uPN9D8cH/SgbyluN /rp2BxZZT9odLeZ8HBToPhyyOX1vq45uGJIVch2QC6B7Gye6deERLJWkzLoTAmqYnLIU qAWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cQoMXScqu8wvHEYT8rsMfqnaOQMpoG1FOoqlZfwEbOM=; b=e1u3d7L+H/o6uRsXWHy8dfAhjvteWgj63RMnwFI3tbCzjKl7l6O77S6yvzirnDuyyg CvCuyH9dKrGIBGk5iIYxvJpFyWcdreukkyrREvxGlMmKSpllgXPke8DbCigzv9ZbHgU1 c+n7DqqTLcgBY01qXCM0a7nRvWzEJTzCtmRgshto3Cqt+2go+hUl2mPcWWOawnb+nyKq ori7kZFUoiUfJVINa8Cz7DKHS/w0BE7QZz7TNq6+0dWF6UT0xDWwbuiT8WV8j9x0jX84 GsRFBRBvLpQ9scg3IgeBWvZZtCVzLAYQF+ZCnEtxpY9iwKhpm+AoxhSM72dEEheJOhtj SNfQ== X-Gm-Message-State: AHPjjUied7bNfz9rm930j54XiVpZJVZJ9nFH8QHNtfRYsJTJsXXV1fnW O8Szmc6E1/6TJUnQR7z8fO8OPw== X-Google-Smtp-Source: AOwi7QBkLymeH72HcNkw0AT+i6z9io3o5v9W80c24HGUSXcTtzv4k0J7iatbrefTQrFj4VD4jiXBMg== X-Received: by 10.98.178.204 with SMTP id z73mr1017298pfl.107.1506137497430; Fri, 22 Sep 2017 20:31:37 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m10sm1306581pgs.77.2017.09.22.20.31.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 20:31:35 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 23 Sep 2017 15:31:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP objective details for registrar 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, 23 Sep 2017 03:31:41 -0000 On 23/09/2017 11:01, Toerless Eckert wrote: > Some opinions/suggestions: > > a) Name of objective should be "ACP_registrar". The registrar supports multiple > services, eg: brski-join, est-renewal, and if we had ducklings also est-enroll. > > ACP_*, because it's not AN_* unless we could guarantee we always have intent > (which we don't), and not ANI_* because we also do not necessarily always have > BRSKI (but eg: Netconf Zero Touch + ACP). > > But this is terminology. I have an option, but i am happy getting anything that works. > ultimately i do not care about this part. Well, settle the name between the ACP and BRSKI authors > > b) More importantliy, elements in objective-value should be standardizeable, reuseable, > extensible and optional. > > AFAIK, for extensible and optionality, we need to use maps instead of > arrays in CBOR ({} instead of [] in CDDL). I would argue that in many cases of simple objectives this would be a mistake. It's a conceptual and practical complication for the ASA writer, unless a map (and probably JSON) is already "native" for the problem at hand. I am absolutely not against maps for cases where they are the natural solution. But if the objective happens to be a simple value, why? > For standardizeable, we should define the structure to include standards elements > > > c) The IMHO most easy and useful standardized options are the ones that > a) allow for objective services to be aligned with DNS-SD so that > we have a superset of the service-selection facilities of DNS-SD and > if desired the same name space. Sure, when we are dealing with that sort of objective. (More below on that.) > d) So, for the ACP draft, i think i would want to write down the most simple > subset of the intended syntax for objective-values and not describe the > background and also not yet start to worry about IANA registration, > because that would make sense only once we agree on the need of extensibility. All that IANA registration really requires is a name and a reference document, so this comes at the RFC stage. > Worst case, the following syntax would not be extended in future, then > we just made it a bit more generic than necessary: > > objective-value = { > std: { > sender-ttl: 255, > service: { "brski-join" }, > service: { "est-renew" }, > } > } Please work with Carsten to get that right, all I can tell you is that the tool reports a parse error. > e) In a separate small document we could detail those GRASP aspects in more detail, > this doc could update ACP RFC, so we can take more time without holding up ACP RFC. > And we could then also ask for the IANA registries when we feel that there really > is enough future add-ons to justify the registry. > > Here is my current definition i would use (aka superset of avove example): Again, a parse error. > > objective-value = { *parameter } ; map of parameters to be extensible and > ; all prameters can be optional. > > parameter /= std: { *std-param } ; create subset of parameters standardized > ; the std-param names would be an IANA registry. > > ; parameter /= ... ; Any parameter specific to an objective. > > std-param /= sender-ttl: 1..255 ; value of ttl field of flood-message > ; as set by sender. Upon receipt, > ; (sender-ttl - ttl) is the distance of > ; the receiver from the sender. > > std-param /= service: { ; Services supported by objective. > service-name, ; Name must be registered according to RFC6335 > *service-param ; would therefore also useable in RFC2782 > } ; For newly registered service names, do not > ; allocate/register protocol/port numbers. These > ; are learned via other GRASP message elements > service-name = tstr > > service-param /= selection-param > selection-param /= priority: 0..65535 ; Same semantic as rfc2782. Default = 0 > selection-param /= weight: 0..65535 ; Same semantic as rfc2782. Default = 0 > > Aka: pretty much allowing 1:1 mapping of the DNS-SD SRV parameters we need > (service-name, priority, weight) to GRASP "services". And make "services" > a sub-element of an objective. And RFC6335 also explains why not to use > capital letters in "est-renew", "brski-join" (uncommon to use capital letters > in RFC6335). All the same, DNS-SD is Unicode, so you can in theory use anything for the Instance name (human readable part). I agree that the DNS-SD Service name is case-folded ASCII. > As you see, i did not make sender-ttl part of service, so we may use sender-ttl > even if some objective does not want a "service:" parameter. > > We may need to add locator options to service-params, thats and example of > how this is yet incomplete. With just one service indicated the locator > element of the existing GRASP is sufficient. > > Cheers > Toerless One more comment below... > > On Thu, Sep 21, 2017 at 02:51:48PM +1200, Brian E Carpenter wrote: >> Works for me. Just decide whether you want AN_registrar or AN_join_registrar. > > a) OK, let me obsess about terminology a bit: > > I always think of objectives as services, which would make > "XXX_registrar" the right word - it does not prescribe what > to do with the service: ignore, consume(join), buy-stock, resell, attack... Well, these objectives and probably many associated with a NOC are services. But if the ASA is handling some sort of optimisation or resource management, the objective really is a parameter. It might be a real number or more complicated, but it's not a service. Really a GRASP objective is just a container. > "objective" to me always implies an action, which i think is why > "XXX_join_registrar" was preferred choosen ? I just tried to copy the terminology in BRSKI. > When we, as i suggest have the same registrar objective used for both BRSKI > and EST, we have at least two actions: BRKI-join and EST-renew. Sure, but you can expand the semantics by adding a field to the objective-value if you want. > Logically > we could also have EST-enroll, but that one is a no-no (eg: ducking enrollment > without voucher). > > So we could call what we named "method" also "action" or "service" and > call them BRSKI-join and EST-renew. But those words do then not imply the > transport stack to use (TLS). > > I would like XXX = ACP because XXX = AN seems to imply the network is > autonomic, which i think by definition it is not unless we have intent ;-P. > XXX = ANI would also be wrong if for example we combine ACP with Netconf > Zero Touch and only offer EST-renew but not BRSKI-enroll. > > b) I would like the parameters of an objective reuseable, extensible and > optional when not needed. I think that we need to use a map instead of > an array in CBOR to get extensibility and optionality (CDDL > > concerned about the word objective - i am never sure if i will not run > into a service where there is really more than Maybe you won't in the NOC space, but if we're optimising usage of radio links in 3D space maybe you will find complex numbers in the control loop, and therefore in the objective values. Brian > >> >>> c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the >>> objective-value structure to include the TTL and method, eg: fixup the following: >>> >>>>> objective-value = [ sender-ttl, method-list [, future-extensions]* ] >>>>> method-list = [ method ]*1 >>>>> methd = BRSKI-TLS | EST-TLS | ... >>>>> sender-ttl = NUM >> >> I would go for this: >> >> objective-value = [ sender-ttl, method-list, *[ future-extensions ] ] >> method-list = [ +method ] >> method = "BRSKI-TLS" / "EST-TLS" >> sender-ttl = 0..255 >> future-extensions = any >> >> The "+" prefix means 1 or more in CDDL and "*" means zero or more. >> The commas in lists like [+method] are implied. (I checked >> this fragment with the CDDL tool.) >> >> I used strings for the method for simplicity; if you want to save a few >> bytes you could use symbols but then they have to be assigned values like >> BRSKI-TLS = 0 >> EST-TLS = 1 >> and you end up with another IANA registry in your life. >> >> Regards >> Brian >> >>> If we do not get further feedback from the WG supporting my simple TTL=255 approach, >>> i would rather go with this structure approach, so that we can let the TTL disussion >>> take its natural course (figure out it should be 255 over 10 years ;-P). Primarily, >>> because i like the idea to show off a bit the flexiblity of GRASP for the objective >>> value being a structure. ANd because it would be a good reference for further objectives >>> where we want to discover/select closest instance (and we didn't include this into the >>> GRASP document proper). >>> >>> Cheers >>> Toerless >>> >>>>> (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) >>>> >>>> Not only do I get the idea, I tested it out many months ago; actually after the >>>> discussions in Berlin, I think. In my Pythonic world it was very easy, but it is >>>> indeed a bit more complicated than the 255-N method. >>>> >>>>> >>>>> That way, the recipient can compare sender-ttl with the TTL of the received objective >>>>> and threeby figue out which one is closest. >>>>> >>>>> I fine either way. I just tried to go for the most simple, logical option. >>>> >>>> Right, so the question for the WG (are you all listening?) is whether we >>>> want to defend the value of the loop count in limiting propagation of multicast >>>> messages. (Remember that it has another role in negotiation sessions, where >>>> it really is a loop-prevention counter.) >>>> >>>> I will note that in testing on looped topologies I have seen looped multicasts >>>> dropped because of the session ID; theoretically that is sufficient, and the >>>> loop count is logically redundant. >>>> >>>> Otherwise, me happy. >>>> >>>> Thanks again for all the work, >>>> >>>> Brian >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Sat Sep 23 00:00:07 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D86132F30; Sat, 23 Sep 2017 00:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBPumZep-lUG; Sat, 23 Sep 2017 00:00: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 673EB126DFE; Sat, 23 Sep 2017 00:00:01 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A843258C4D4; Sat, 23 Sep 2017 08:59:56 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8F309B0CC88; Sat, 23 Sep 2017 08:59:56 +0200 (CEST) Date: Sat, 23 Sep 2017 08:59:56 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org Message-ID: <20170923065956.GC32014@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] GRASP objective details for registrar 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, 23 Sep 2017 07:00:04 -0000 On Sat, Sep 23, 2017 at 03:31:44PM +1200, Brian E Carpenter wrote: > Well, settle the name between the ACP and BRSKI authors Sure > > AFAIK, for extensible and optionality, we need to use maps instead of > > arrays in CBOR ({} instead of [] in CDDL). > > I would argue that in many cases of simple objectives this would be a mistake. > It's a conceptual and practical complication for the ASA writer, unless a > map (and probably JSON) is already "native" for the problem at hand. > > I am absolutely not against maps for cases where they are the natural > solution. But if the objective happens to be a simple value, why? As soon as you want to include discovery parameters such as the sender-ttl or the dns SRV style weight/prio the map for example. > All that IANA registration really requires is a name and a reference document, > so this comes at the RFC stage. Sure. Its more about feeling safe enough that the idea is right before asking IANA to maintain a registry. Easier done when there is more time to revisit the decision. > > objective-value = { > > std: { > > sender-ttl: 255, > > service: { "brski-join" }, > > service: { "est-renew" }, > > } > > } > > Please work with Carsten to get that right, all I can tell > you is that the tool reports a parse error. What's the CBOR/CDDL tool you're using, i'll try it myelf first before yelling for help ;-) > All the same, DNS-SD is Unicode, so you can in theory use anything for the > Instance name (human readable part). I agree that the DNS-SD Service name > is case-folded ASCII. I was just trying to follow what seems to be common practice and minimize the new wheels we're inventing by re--using existing wheels. > One more comment below... > > I always think of objectives as services, which would make > > "XXX_registrar" the right word - it does not prescribe what > > to do with the service: ignore, consume(join), buy-stock, resell, attack... > > Well, these objectives and probably many associated with a NOC are > services. But if the ASA is handling some sort of optimisation > or resource management, the objective really is a parameter. > It might be a real number or more complicated, but it's not > a service. Really a GRASP objective is just a container. Right. Which is why the objective-value structure proposal also hass the whole "service" element as an optional subelement only. > > "objective" to me always implies an action, which i think is why > > "XXX_join_registrar" was preferred choosen ? > > I just tried to copy the terminology in BRSKI. Yes, pretty sure "join_registrar" was some BRSKI collaborator idea. > > When we, as i suggest have the same registrar objective used for both BRSKI > > and EST, we have at least two actions: BRKI-join and EST-renew. > > Sure, but you can expand the semantics by adding a field to the > objective-value if you want. Thats what the objective-value proposal is doing. > > concerned about the word objective - i am never sure if i will not run > > into a service where there is really more than > > Maybe you won't in the NOC space, but if we're optimising usage of > radio links in 3D space maybe you will find complex numbers in > the control loop, and therefore in the objective values. I hope i did mention initialy in my email that the proposed structure for objetive-value was primarily for flooded objectives and just trying to establish a structure that allows to define cross-objective shared eleemnts - without limiting the objective specific ones. Cheers Toerless > Brian > > > > >> > >>> c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the > >>> objective-value structure to include the TTL and method, eg: fixup the following: > >>> > >>>>> objective-value = [ sender-ttl, method-list [, future-extensions]* ] > >>>>> method-list = [ method ]*1 > >>>>> methd = BRSKI-TLS | EST-TLS | ... > >>>>> sender-ttl = NUM > >> > >> I would go for this: > >> > >> objective-value = [ sender-ttl, method-list, *[ future-extensions ] ] > >> method-list = [ +method ] > >> method = "BRSKI-TLS" / "EST-TLS" > >> sender-ttl = 0..255 > >> future-extensions = any > >> > >> The "+" prefix means 1 or more in CDDL and "*" means zero or more. > >> The commas in lists like [+method] are implied. (I checked > >> this fragment with the CDDL tool.) > >> > >> I used strings for the method for simplicity; if you want to save a few > >> bytes you could use symbols but then they have to be assigned values like > >> BRSKI-TLS = 0 > >> EST-TLS = 1 > >> and you end up with another IANA registry in your life. > >> > >> Regards > >> Brian > >> > >>> If we do not get further feedback from the WG supporting my simple TTL=255 approach, > >>> i would rather go with this structure approach, so that we can let the TTL disussion > >>> take its natural course (figure out it should be 255 over 10 years ;-P). Primarily, > >>> because i like the idea to show off a bit the flexiblity of GRASP for the objective > >>> value being a structure. ANd because it would be a good reference for further objectives > >>> where we want to discover/select closest instance (and we didn't include this into the > >>> GRASP document proper). > >>> > >>> Cheers > >>> Toerless > >>> > >>>>> (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea) > >>>> > >>>> Not only do I get the idea, I tested it out many months ago; actually after the > >>>> discussions in Berlin, I think. In my Pythonic world it was very easy, but it is > >>>> indeed a bit more complicated than the 255-N method. > >>>> > >>>>> > >>>>> That way, the recipient can compare sender-ttl with the TTL of the received objective > >>>>> and threeby figue out which one is closest. > >>>>> > >>>>> I fine either way. I just tried to go for the most simple, logical option. > >>>> > >>>> Right, so the question for the WG (are you all listening?) is whether we > >>>> want to defend the value of the loop count in limiting propagation of multicast > >>>> messages. (Remember that it has another role in negotiation sessions, where > >>>> it really is a loop-prevention counter.) > >>>> > >>>> I will note that in testing on looped topologies I have seen looped multicasts > >>>> dropped because of the session ID; theoretically that is sufficient, and the > >>>> loop count is logically redundant. > >>>> > >>>> Otherwise, me happy. > >>>> > >>>> Thanks again for all the work, > >>>> > >>>> Brian > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de From nobody Sat Sep 23 12:35:39 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76063126D0C; Sat, 23 Sep 2017 12:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TzHqtRyl-dr; Sat, 23 Sep 2017 12:35:35 -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 C230E126C0F; Sat, 23 Sep 2017 12:35:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D494B2009E; Sat, 23 Sep 2017 15:40:21 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 44751806CE; Sat, 23 Sep 2017 15:35:33 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 19:35:37 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless, thank you for this version. We are very very close! Brian, Max, I invoke your name in my comments... please read and +1, or disagree with me. I noticed in this version has two places with no space after the .: across the network.[RFC7575] defines the fundamental ideas and design and it should be re-usable by all autonomic functions.[RFC7575] calls Can we avoid semantic/normative statments like "ACP routing table may inclu= de multiple" in a terminology section? Change: ACP (ULA) prefix(es) The prefixes routed across the ACP. In the normal/simple case, the ACP has one ULA prefix, see Section 6.10. The ACP routing table may include multiple ULA prefixes if the "rsub" option is used to create addresses from more than one ULA prefix. See Section 6.1.1. The ACP may also include non-ULA prefixes if those are configured on ACP connect interfaces. See Section 8.1.1. to: ACP (ULA) prefix(es) The prefixes routed across the ACP. In the normative case, the ACP has one ULA prefix as specified in Section 6.10. The cases where multiple prefixes are present are explained in Section 6.1.1, and use of non-ULA prefixes are explained in Section 8.1.1. There are some good updates to the ACP domain. I want to bring up this iss= ue From=20BRSKI here: https://github.com/anima-wg/anima-bootstrap/issues/20 I was suggesting that the information for the Pledge's CSR should be broken up such that the pledge will create the right CN from the pieces, which it needs to know anyway. I had suggested: "ACPinfo" : { "acp-prefix" : "fda379A6f6ee00000200000064000001", "acp-prefix-length": 96, "acp-plus-part": "area51.research", "acp-domain": "acp.example.com" } I don't like your text: If the operator does not own any FQDN, it should choose am FQDN format string that intends to be equally unique. I suggest that: If they don't own any FQDN, then, aside from WTF?, that they form a unique name as: $(uuidgen).example.com. Or, perhaps that they use ${ULA}.example.com. the only real-life situation where this is going to happen is in a test lab run by co-op students, and in that case, the software might as well have a pre-configured default. =3D=3D=3D=3D=3D=3D Brian, Max and I asked you to remove the EST requirements on announcements From=20the ACP document. =3D=3D=3D=3D=3D=3D ACP secure channel MUST imediately be terminated when the lifetime of any certificate in the chain used to authenticate the neighbor expires or becomes revoked. Note that is is not standard behavior in secure channel protocols such as IPsec because the certificate authentication only influences the setup of the secure channel in these protocols. This is rather impractical to implement in real life, that's why IPsec doesn't do that. I strongly suggest you sit down with some Cisco, Juniper (Netscreen) and Checkpoint IPsec product managers, and ask them what they actually do, and why. Assuming you really want to have this kind of behaviour, then the correct w= ay to do this is to make statements about the rekey intervals on the channels. ACP secure channels created with the use of certificates will include so= me lifetimes for the certificates. The set of lifetimes includes: 1) the expiry date of the certificate 2) the lifetime of the OCSP response 3) the validity time of the CRL response The earliest date provided by these provides a time at which the keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed. 6.10.4. ACP Manual Addressing Sub-Scheme The sub-scheme defined here is defined by the Type value 1 (one) in was changed to: The sub-scheme defined here is defined by the Type value 00b (zero) I think that this is a typo, and should be 01b ? Or does the Manual mechanism somehow fit into the ACP Zone Addressing Sub-Scheme because the Z bit is different? Do you explain this manual zone better somewhere? Can you show the two Types with their bits set at the end of the base schem= e? 64 64 +---------------------+---------+---++-----------------------------+ | (base scheme) 01|Subnet-ID| Z || Interface Identifier | +---------------------+---------+---++-----------------------------+ <-------48--------->TT 13 1 section 8.8.1, starting at: The ACP connect interface must be (auto-)configured with an IPv6 seems to be missing articles and/or words, and needs an english editing pas= s. =3D=3D=3D=3D=3D=3D section 11 This document may be considered to be updating the IPv6 addressi= ng architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast addresses ([RFC4193]) depending on how strict specific statements in I don't like this statement. Either it violates the spec, and updates it, = or it does not. I do not think that it violates. This is not a multi-link subnet, this is a prefix that is not on-link. It is possible, that this scheme constitutes an update to RFC4191 because the same 64 bit subnet prefix is used across many ACP devices. The ACP Zone addressing Sub-Scheme is very similar to the common operational practices of assigning /128 loopback addresses to network devices from the same /48 or /64 subnet prefix. It does not. Brian? Do you concur? The goal for the 8 or 16-bit addresses available to an ACP device in this scheme is to assign them as required to software components, which in autonomic networking are called ASA (Autonomic Service We are not providing 8-bit or 16-bit IIDs. We are providing 256 or 65536 /128 addresses which are conveniently aggregated for routing purposes. In practical terms, the ACP should be enabled to create from its /8 or /16 prefix one or more device internal virtual subnets and to start software components connected to those virtual subnets. No, don't say this, and don't do this in practice. Create /128 routes to LL address of the internal VM and configure the /128 as a loopback address inside the VM. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnGt4QACgkQgItw+93Q 3WXS9ggAkduoqvsB+SySoyHoX94tCXibZJKiZWWiG+xu4kI2VGsA9nTmXmfUmDRN c68OA23SITBmqF+Y8M1dbQg7WljZ287e70srS58vQhKHAH93G82ZKTrVOqxgi+zu 8sQf6kR0aLEsa+PhUi/UZYw/f3Xgp1mx6vWkmnoJ5GnAHROrblf4snSWdaWkzKi4 OzG9psPHwtd8F4RIMA+9aAD5Q9kC2+oNGaTufWbiuXB4e5qBGiBSZaW+DacL6CqR +LBSNXms5bwQOStB/nc+UtBVg2pk0RUFvsFx7wa5BwETCxWqTxncWEj/HcRn6Qnz r3ZHbX5dyd40iOK0jbs6pr0d89jEig== =jfkA -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Sep 23 12:43:12 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6A132C2A; Sat, 23 Sep 2017 12:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS6WgiMCrM_p; Sat, 23 Sep 2017 12:43:09 -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 CDE1F13295C; Sat, 23 Sep 2017 12:43:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EA612009E; Sat, 23 Sep 2017 15:47:56 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D7C27806CE; Sat, 23 Sep 2017 15:43:07 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Toerless Eckert , draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org In-Reply-To: <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 19:43:10 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> That way, the recipient can compare sender-ttl with the TTL of the received objective >> and threeby figue out which one is closest. >> >> I fine either way. I just tried to go for the most simple, logical option. > Right, so the question for the WG (are you all listening?) is whether we > want to defend the value of the loop count in limiting propagation of multicast > messages. (Remember that it has another role in negotiation sessions, where > it really is a loop-prevention counter.) > I will note that in testing on looped topologies I have seen looped multicasts > dropped because of the session ID; theoretically that is sufficient, and the > loop count is logically redundant. So, this lets one a) notice if the M_FLOOD is forged because the TTL of the underlying packet does not agree. b) figure out which M_FLOOD is closer. Given: We have ACP built with P2P tunnels between nodes, and on top of that we run RPL to form a *unicast* routing topology. Should a GRASP deamon send M_FLOODs to all P2P tunnels, regardless of whether they are active RPL routes? I would tend to say *YES*. Given that, one will expect to see the same M_FLOOD from the same sender via multiple paths. That's fine, and I think it's good. But, comparing them is kind of meaningless, because once you find out who the sender is, the unicast routing takes over, and you will take the unicast direction only. If one hears announcements from multiple senders, then there might be different directions, but the TTL you see in the M_FLOOD may have NOTHING to do with what the unicast cost is. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnGuUsACgkQgItw+93Q 3WWuOgf/ZGaWTRPPlTi0rd7P2YoixFZII2SpG9jJY/NeN2knSTXTIIvdjaAUDzea hH/iNhr5bTzSk+8va7RaM9/zIQCvkX/CBPU2Bf8eyLCyY7h+sEuZvehKjCaNmWzn k0K/wrq+xmFlPTBGkYhUFnI+VDVK83+pTWv5FZPz7zqnDBNHgxJOCYhxoEzdPCNM 28RVjKvrD93aID6xM7AlE8senjMvyZZg1mTm49lksDdd9PKM74QNhnU/Idqq/OOA F19ntPMNxRk/ApQuSv0w3B1Lcs/VlHBBdDVxLNu6xhlWTcf/zEDeaHSAhA7AW4dH /lyxSiQdinEPabX/GcDOqTG9yd4dtQ== =cQ3h -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Sep 23 13:05:39 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19E9132705; Sat, 23 Sep 2017 13:05:37 -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 KOPlcBr_O6cT; Sat, 23 Sep 2017 13:05:36 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FDD13202D; Sat, 23 Sep 2017 13:05:36 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 7so2123979pgd.13; Sat, 23 Sep 2017 13:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NRD6nRUUf4YedtYnvuc6tFzw604FVXeS19YzSiWd4pA=; b=P15w9o+lkXcVU67QXgylaGpAO6puyUPR/a5BF58gRRmb2M/RT4fbJpWqZY7w6gH3pq JaAw7ehAFf2F8huOBGRcnPQWFG5+hLEfdaH7Pj7DJPPu5WOqb8q5BffhDSh24Q6DKhpL MnWT3lE76cmDs4bYgK9WUftdCHGFEzTcNEc0LFG/k9l9tLMUGnltWcDNnhSreFGeJiVS T/j8d0yIYWUt+rk9N3MahdVfqu4hm0vF1hEYV3GISID+Qj2IPUdYR636X4vmWcsNGyTR C1sGEnsibGinGncdlhpXFzS4KxaKEOZBvIAGfvDf80DrAWzOkpENcyzOAoC5eUJfPlwq fKNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=NRD6nRUUf4YedtYnvuc6tFzw604FVXeS19YzSiWd4pA=; b=rYPd2uy43sNkKMEqKQgTFNt8JUk8ygHLboWkIs/1u9kuV11kJfyZr0nwdwP4XSEXvs +hJpqMm6JbKgLcDyzMuEjNaBjPKy9gmgo51h0RrpgvrvmxjXltDWZnoHYORQPjuX0Lpi N9oxL6+gfQKcUVAYggVOLx6TbrK+oIWXntr9nfdtQL+dDPj4WdG2OaDetM8S9ac75ZAb 2ZpxTfo4zVrp5eyhg1H0fW6bhZQjB5mGLm2WnkSXM1LIG3AmIA0Lqhu+DFriocuxKXAb CndXDoybwKDTTJviNIuMXr7sC9IbO2AQ885c5GcwJ7zNrQC/y4IbGZLiwFR0aIgFTAZm F0Ag== X-Gm-Message-State: AHPjjUgV5vemE3xeM9TNvOc5CP/fdPL9ibBg4IoEoTfhrckDNyw192AF 7ZhY8aH/bcs0e/5C2W2KOhWgBg== X-Google-Smtp-Source: AOwi7QDaDE44A80tpDxNjiMR1Zf83AuXF2GMQYD8jsfsO8IXzekXq8byMn1JsmI9AxhdINyL2ShziA== X-Received: by 10.159.194.137 with SMTP id y9mr3018892pln.77.1506197135419; Sat, 23 Sep 2017 13:05:35 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z30sm4995443pfg.54.2017.09.23.13.05.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 13:05:34 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> <20170923065956.GC32014@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3ad2ebe1-c975-d115-4f26-2fe792f02779@gmail.com> Date: Sun, 24 Sep 2017 09:05:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170923065956.GC32014@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP objective details for registrar 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, 23 Sep 2017 20:05:38 -0000 > What's the CBOR/CDDL tool you're using, i'll try it myelf first > before yelling for help ;-) It's a Ruby tool called simply 'cddl' Install Ruby and then install the gem called cddl. http://www.rubygemsearch.org/rubygems/cddl Regards Brian From nobody Sat Sep 23 13:52:59 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FCA132198; Sat, 23 Sep 2017 13:52:58 -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 XT9he73hLSzm; Sat, 23 Sep 2017 13:52:55 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE74129B7A; Sat, 23 Sep 2017 13:52:55 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id l188so2049318pfc.6; Sat, 23 Sep 2017 13:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vI9iXjioWKLHhp+TZNDDwWEhBBFhaEtwSnDgy6C3rMU=; b=mzdB+p4OYDjJUe8j4GiwEYdot8VtfUdojGxf9D9hBDRRSGUkTlSLmAi305AKybGZGX kkVoj8Tt+0eosipz46ea8/1RT47u3zNwIs9MaUKV91S3bi/UO/aLLpNJbfuWSiJy393G O3rTpCbVXDAxjjaEQsFjJbyi/WrCj1U1GwieG9yQeNOmsBgAhsg/cyOuaYNCXEnxrPbO 9tV8/ZJQ3BM5AJ5GNNIpWtf3RboHU76Su10b6IxniFK50ieWfyyPbNRslsQ3pBqD2XGN 0u7/ZEdw1ZSHfnDjrrifSQ81DXm3vzqZYuhzHZ55bJis16IMNSGlDpqUXhRSY/OC43h0 qjZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vI9iXjioWKLHhp+TZNDDwWEhBBFhaEtwSnDgy6C3rMU=; b=SUViiqBC1viMBsGH0upMjMngz006bPBeZL+6bk67V+xd1/dwbDe/HNUF05w2bNzCTO pT0TQtEkeQBNOi6DnvlxPr9+kMojh8GPE+ph7nIVFdYPe8mLCV7vbNGJivtug8aqNsRY wVoVsQ5DQSnI9hL7eIlRXXDIsvJWiWzPPGPnafX9/JT0LSoOZj1MmpZd4mvWw2tk56Ug SwSgaZxgYmyW37iKPIxQgCdOp+GjeYh9Mpa8IKyUlfCcf0EvxbImZI0aZE63J3kfDpaB 9NbfjhIFB08/u1cZhSOaeL5mel7ffGD0WRillViTGEoP7EJH0MDSnpyUsylfVciblYfZ IcuA== X-Gm-Message-State: AHPjjUjGKVCB6DBaEikZ6jT3UJBFCVV7BU37ZWcHDySh4macQ4JlPBZj tj3EI+H+Ne19OQX1GjlT2Gx8LA== X-Google-Smtp-Source: AOwi7QC2p9T7R04jhEEFc/5ebx1YvBWTgEVDu6FnJmTIsyrU2EEGakqyK8s59pfjgCL3EWyuhDOg9Q== X-Received: by 10.84.234.196 with SMTP id i4mr3019414plt.432.1506199974355; Sat, 23 Sep 2017 13:52:54 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s81sm5853132pfg.162.2017.09.23.13.52.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 13:52:53 -0700 (PDT) To: Michael Richardson , anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> Date: Sun, 24 Sep 2017 09:52:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <11713.1506195333@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 20:52:58 -0000 Michael, I get a bit confused by the way your mail agent doesn't distinguish new and old text, but in line... On 24/09/2017 08:35, Michael Richardson wrote: > > Toerless, thank you for this version. We are very very close! > Brian, Max, I invoke your name in my comments... please read and +1, > or disagree with me. > > I noticed in this version has two places with no space after the .: > > across the network.[RFC7575] defines the fundamental ideas and design > and it should be re-usable by all autonomic functions.[RFC7575] > calls > > > Can we avoid semantic/normative statments like "ACP routing table may include > multiple" in a terminology section? > > Change: > ACP (ULA) prefix(es) The prefixes routed across the ACP. In the > normal/simple case, the ACP has one ULA prefix, see Section 6.10. > The ACP routing table may include multiple ULA prefixes if the > "rsub" option is used to create addresses from more than one ULA > prefix. See Section 6.1.1. The ACP may also include non-ULA > prefixes if those are configured on ACP connect interfaces. See > Section 8.1.1. > > to: > ACP (ULA) prefix(es) The prefixes routed across the ACP. In the > normative case, the ACP has one ULA prefix as specified in > Section 6.10. The cases where multiple prefixes are present > are explained in Section 6.1.1, and use of non-ULA prefixes > are explained in Section 8.1.1. > > There are some good updates to the ACP domain. I want to bring up this issue > From BRSKI here: > https://github.com/anima-wg/anima-bootstrap/issues/20 > > I was suggesting that the information for the Pledge's CSR should be broken > up such that the pledge will create the right CN from the pieces, which it > needs to know anyway. I had suggested: > > "ACPinfo" : { "acp-prefix" : "fda379A6f6ee00000200000064000001", > "acp-prefix-length": 96, > "acp-plus-part": "area51.research", > "acp-domain": "acp.example.com" > } > > I don't like your text: > If the operator does not own any FQDN, it should > choose am FQDN format string that intends to be equally unique. > > I suggest that: > If they don't own any FQDN, then, aside from WTF?, that they form a > unique name as: $(uuidgen).example.com. > Or, perhaps that they use ${ULA}.example.com. > > the only real-life situation where this is going to happen is in a test lab > run by co-op students, and in that case, the software might as well have a > pre-configured default. > > ====== > > Brian, Max and I asked you to remove the EST requirements on announcements > From the ACP document. Toerless explained elsewhere why he thinks the duplication is needed. > ====== > ACP secure channel MUST imediately be terminated when the lifetime of > any certificate in the chain used to authenticate the neighbor > expires or becomes revoked. Note that is is not standard behavior in > secure channel protocols such as IPsec because the certificate > authentication only influences the setup of the secure channel in > these protocols. > > This is rather impractical to implement in real life, that's why IPsec > doesn't do that. I strongly suggest you sit down with some Cisco, Juniper > (Netscreen) and Checkpoint IPsec product managers, and ask them what they > actually do, and why. > > Assuming you really want to have this kind of behaviour, then the correct way > to do this is to make statements about the rekey intervals on the channels. > > ACP secure channels created with the use of certificates will include some > lifetimes for the certificates. The set of lifetimes includes: > 1) the expiry date of the certificate > 2) the lifetime of the OCSP response > 3) the validity time of the CRL response > > The earliest date provided by these provides a time at which the > keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed. > > > 6.10.4. ACP Manual Addressing Sub-Scheme > > The sub-scheme defined here is defined by the Type value 1 (one) in > > was changed to: > The sub-scheme defined here is defined by the Type value 00b (zero) > > I think that this is a typo, and should be 01b ? > Or does the Manual mechanism somehow fit into the > ACP Zone Addressing Sub-Scheme because the Z bit is different? > > Do you explain this manual zone better somewhere? > > > Can you show the two Types with their bits set at the end of the base scheme? > > 64 64 > +---------------------+---------+---++-----------------------------+ > | (base scheme) 01|Subnet-ID| Z || Interface Identifier | > +---------------------+---------+---++-----------------------------+ > <-------48--------->TT 13 1 > > > section 8.8.1, starting at: > The ACP connect interface must be (auto-)configured with an IPv6 > > seems to be missing articles and/or words, and needs an english editing pass. > > ====== section 11 > This document may be considered to be updating the IPv6 addressing > architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast > addresses ([RFC4193]) depending on how strict specific statements in > > I don't like this statement. Either it violates the spec, and updates it, or > it does not. I do not think that it violates. This is not a multi-link > subnet, this is a prefix that is not on-link. As readers of the 6man list know, this has been a very contentious topic. I think it's safer to duck it in the ACP draft: say what we do, but say nothing about RFC4291 etc. > It is possible, that this scheme constitutes an update to RFC4191 > because the same 64 bit subnet prefix is used across many ACP > devices. The ACP Zone addressing Sub-Scheme is very similar to the > common operational practices of assigning /128 loopback addresses to > network devices from the same /48 or /64 subnet prefix. > > It does not. Brian? Do you concur? Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links"). But we don't need to apologise. As you say, we're simply assigning /128 addresses to (virtual) interfaces using our own scheme. And we're relying on BCP 198 (RFC 7608) which says that routing prefixes can be any length up to /128. If you want to cite anything, cite RFC 7608. > The goal for the 8 or 16-bit addresses available to an ACP device in > this scheme is to assign them as required to software components, > which in autonomic networking are called ASA (Autonomic Service > > We are not providing 8-bit or 16-bit IIDs. > We are providing 256 or 65536 /128 addresses which are conveniently > aggregated for routing purposes. > > In practical terms, the ACP should be enabled to create from its /8 > or /16 prefix one or more device internal virtual subnets and to > start software components connected to those virtual subnets. > > No, don't say this, and don't do this in practice. Create /128 routes to LL > address of the internal VM and configure the /128 as a loopback address > inside the VM. So yes, I concur with Michael. Brian From nobody Sat Sep 23 13:59:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD3132C3F; Sat, 23 Sep 2017 13:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGdkhwozT5Jg; Sat, 23 Sep 2017 13:59:01 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE022129B7A; Sat, 23 Sep 2017 13:59:01 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id j16so2169712pga.1; Sat, 23 Sep 2017 13:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yqXHY6cddYdQ39XmIiOz10Qt1k5ZL07ykTcz2xDm8so=; b=hvOFg0rH9hFceU/mp5/3mU7xKWd9Vsrmqw0wBNwe/78/l4PQO0AEZo7RM9zkiN4G+E pd6quMqWjgjtbLJ5drZ5nU6rIEvcwSwlld0c7rh3ut2TvNB+n9KhIg5CiOdxxhtzcbe9 IKSUJXo3GHUt6hhWnos9wZ6KchD5hX+m0UyQ5/+yUm0iJhngVVWyD4j6vHEudsuCUGQ8 4sRGiMrnskHpymA+2eI4/PipjHLD+HytJiipBsMhW0jQKfyg/QW9hGTmxopbng72Gh/q kmj8sOTrO7GhFF5d2Va5aS/FHqAlD4u+wWlGppmgoz0DWDWcd27uPUKUIF49maS8Ft+p NJ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yqXHY6cddYdQ39XmIiOz10Qt1k5ZL07ykTcz2xDm8so=; b=qcrrwia/jjcfZKSRF5DC4eAn719LeV9L+QRA2WOp/G6MIMYZdIgj2776jMliLJ9pdC VgsVv2R/+qyhTdkOnDksNnlBOaAWwYjkwQlnHblz8hC41T3BOUSqxHyMwFQQSW/CxKxg r5lbG+IjANNEsQBZCT9AF/pu6P87PzcKFxwP/RCubFnlSSxs2hnrmUi6H4EhOG7zBeKq 4hgjoJLsTM9diQZuRL5n+0gVc9uoA1zjEaEwS3P+7MrMaVacTsi1CHMVvCjtXr1FBnSj 2D2kf+/x+jkk9damRtF0v4OuOVDHlmuUM72HkhikUYEn7OHwyANl8fKarJ8f25RVV30T HP7Q== X-Gm-Message-State: AHPjjUgu8cLHgSpve9+/QEeuTvb/z32QK8sY1WUpnytoFSWIyoGzVCGp UTRZ7bPX82VRehsvsxjoFNzlpA== X-Google-Smtp-Source: AOwi7QBEMaSgfRVJ2qJawJ3e0dv7B4lNmkSamVNUTI5RiWD07eNiBvz539Bt7yghEN5QTKTTV9iVUw== X-Received: by 10.84.129.65 with SMTP id 59mr3033873plb.442.1506200340715; Sat, 23 Sep 2017 13:59:00 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q13sm7690708pfi.110.2017.09.23.13.58.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 13:58:59 -0700 (PDT) To: Michael Richardson Cc: Toerless Eckert , draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <13482.1506195787@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <11c60420-0460-9f6e-50ac-e7485d58a5ce@gmail.com> Date: Sun, 24 Sep 2017 09:58:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <13482.1506195787@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 20:59:03 -0000 On 24/09/2017 08:43, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> That way, the recipient can compare sender-ttl with the TTL of the received objective > >> and threeby figue out which one is closest. > >> > >> I fine either way. I just tried to go for the most simple, logical option. > > > Right, so the question for the WG (are you all listening?) is whether we > > want to defend the value of the loop count in limiting propagation of multicast > > messages. (Remember that it has another role in negotiation sessions, where > > it really is a loop-prevention counter.) > > > I will note that in testing on looped topologies I have seen looped multicasts > > dropped because of the session ID; theoretically that is sufficient, and the > > loop count is logically redundant. > > So, this lets one > a) notice if the M_FLOOD is forged because the TTL of the underlying > packet does not agree. > b) figure out which M_FLOOD is closer. > > Given: > We have ACP built with P2P tunnels between nodes, and on top of > that we run RPL to form a *unicast* routing topology. > > Should a GRASP deamon send M_FLOODs to all P2P tunnels, regardless of whether > they are active RPL routes? I would tend to say *YES*. In practice, I think GRASP will send to all the ACP interfaces flagged as active in the adjacency table. But that amounts to the same thing. > Given that, one will expect to see the same M_FLOOD from the same sender via > multiple paths. That's fine, and I think it's good. But, comparing them is > kind of meaningless, because once you find out who the sender is, the unicast > routing takes over, and you will take the unicast direction only. > If one hears announcements from multiple senders, then there might be > different directions, but the TTL you see in the M_FLOOD may have NOTHING to > do with what the unicast cost is. True, in a general topology - the LL multicasts combined with GRASP relaying will ammount to a spanning tree rooted at the M_FLOOD sender, but the unicast paths will be set by RPL. There's no reason they will be congruent. They might be. This is a good point! Brian From nobody Mon Sep 25 06:40:31 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A00133085; Mon, 25 Sep 2017 06:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8Y6KjcmTK64; Mon, 25 Sep 2017 06:40:22 -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 5C6D8134311; Mon, 25 Sep 2017 06:40:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 169C62009E; Mon, 25 Sep 2017 09:45:15 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AE05980CFA; Mon, 25 Sep 2017 09:40:20 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:40:29 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I get a bit confused by the way your mail agent doesn't distinguish > new and old text, but in line... Well, there isn't any old text in it, rather there are quotes from the document! brian> Toerless explained elsewhere why he thinks the duplication is brian> needed. I read that after my email. I simply can't agree. >> ====== section 11 >> This document may be considered to be updating the IPv6 addressing >> architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast >> addresses ([RFC4193]) depending on how strict specific statements in >> >> I don't like this statement. Either it violates the spec, and updates it, or >> it does not. I do not think that it violates. This is not a multi-link >> subnet, this is a prefix that is not on-link. brian> As readers of the 6man list know, this has been a very contentious topic. brian> I think it's safer to duck it in the ACP draft: say what we do, but say brian> nothing about RFC4291 etc. I agree. >> It is possible, that this scheme constitutes an update to RFC4191 >> because the same 64 bit subnet prefix is used across many ACP >> devices. The ACP Zone addressing Sub-Scheme is very similar to the >> common operational practices of assigning /128 loopback addresses to >> network devices from the same /48 or /64 subnet prefix. >> >> It does not. Brian? Do you concur? > Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign > them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that > sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links"). > But we don't need to apologise. As you say, we're simply assigning /128 > addresses to (virtual) interfaces using our own scheme. And we're relying > on BCP 198 (RFC 7608) which says that routing prefixes can be any length > up to /128. If you want to cite anything, cite RFC 7608. Toerless, do you want text to say this? draft> The goal for the 8 or 16-bit addresses available to an ACP device in draft> this scheme is to assign them as required to software components, draft> which in autonomic networking are called ASA (Autonomic Service mcr> We are not providing 8-bit or 16-bit IIDs. mcr> We are providing 256 or 65536 /128 addresses which are conveniently mcr> aggregated for routing purposes. draft> In practical terms, the ACP should be enabled to create from its /8 draft> or /16 prefix one or more device internal virtual subnets and to draft> start software components connected to those virtual subnets. mcr> No, don't say this, and don't do this in practice. Create /128 routes to LL mcr> address of the internal VM and configure the /128 as a loopback address mcr> inside the VM. brian> So yes, I concur with Michael. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnJB0QACgkQgItw+93Q 3WWyKwf/dFVECnHqiDebHAV8RzQxgnE1oFtQDzFtXa+6sHXJ1/EJYkrt9vqu8P06 YPUknCgN5lde5e5ndyUYG20d7vzaQWA3u4+CtC8mAEaZh8vqsGakkOEEzSThScvS yGUrIm7lWDZrf60hFlWChbAS6LJP+3TiD4vGVaTQeKOu4eLl0z1SUjURvF26gn9a uQevIITpK8SMMv1U+27DjtjZwSVZQdN+yD3LC7Jsk/xJI9ABtiapcLGFrl1HdHjL FB2i9FdXh9kIsX+5HHXHZ2FPMNK7r2DuZnt0QKNrQympvnqNr+/1MydT6LRoNsqy xhazEDhm3zil/NgVMLXAy761GhUHxg== =ka7Y -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 25 06:44:26 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AA0134310; Mon, 25 Sep 2017 06:44:25 -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 EvEg2_U7tax4; Mon, 25 Sep 2017 06:44: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 B85F2133085; Mon, 25 Sep 2017 06:44:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5985F2009E; Mon, 25 Sep 2017 09:49:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E6C1D80CFA; Mon, 25 Sep 2017 09:44:22 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Toerless Eckert , draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org In-Reply-To: <11c60420-0460-9f6e-50ac-e7485d58a5ce@gmail.com> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <13482.1506195787@obiwan.sandelman.ca> <11c60420-0460-9f6e-50ac-e7485d58a5ce@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:44:25 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Given that, one will expect to see the same M_FLOOD from the same sender via >> multiple paths. That's fine, and I think it's good. But, comparing them is >> kind of meaningless, because once you find out who the sender is, the unicast >> routing takes over, and you will take the unicast direction only. >> If one hears announcements from multiple senders, then there might be >> different directions, but the TTL you see in the M_FLOOD may have NOTHING to >> do with what the unicast cost is. > True, in a general topology - the LL multicasts combined with GRASP relaying > will ammount to a spanning tree rooted at the M_FLOOD sender, but the unicast > paths will be set by RPL. There's no reason they will be congruent. They might > be. This is a good point! As an example, take any ring-like metro-ethernet architecture that an ISP might deploy. They have multiple redundant paths across the network, and they use them for customer data... there is a lot of work going to balance traffic across such structures. On top of that, impose a strict DODAG structure with the NOC as the root, and one can see that ACP traffic between adjacent nodes on a metro-ethernet ring may well travel all the way to the DODAG root and down again, while an M_FLOOD will travel sideways. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnJCDYACgkQgItw+93Q 3WX7ZQf+MbbzPCo6DPMRGSudrThhzBZknDPk6CzUlRkoElyjIFQ7iBPdQ8nMfjH4 g6oTmkrO4qolfyhWbvcznCluYv48CBaMYUDsFPP/3NEz/74j/KEUKmrgmQ7FjxTP 3j488FjUlnlE+bxUYws5B2F4fN8PDgjXSEUPZOqarBmzY2oX/Hzjm8gCDorC82tl I/Mk/qFs+ZmFhEyoY0yvulHWIbwzHAGD/960+q3L4PqIY44TEw2rvIBCCoWO/u3f 2LV8DuVd5iw4LrKCuf25ypR17NdRbQJb8gu4zJ+3RH87tWZjXPCa0VgGmXi+j+8g CIRovyddEKyUG6Vpb/nKXmHYAT+3ZA== =cGmh -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 25 06:49:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89A134318; Mon, 25 Sep 2017 06:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw273VL_N55k; Mon, 25 Sep 2017 06:49:18 -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 9E44413430A; Mon, 25 Sep 2017 06:49:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 304BC2009E; Mon, 25 Sep 2017 09:54:12 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C3C1D80CFA; Mon, 25 Sep 2017 09:49:17 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: Brian E Carpenter , draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org In-Reply-To: <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP objective details for registrar (was: Re: ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:49:20 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I always think of objectives as services, which would make > "XXX_registrar" the right word - it does not prescribe what > to do with the service: ignore, consume(join), buy-stock, resell, attack... > "objective" to me always implies an action, which i think is why > "XXX_join_registrar" was preferred choosen ? We used the term "registrar" as the short form of Join Registrar/Coordinator. After joining, it could be there are other registrars that can be reached to renew certificates. Those registrars do not necessarily have to do all of the EST work with the MASA, etc. I don't care if it's called XXX_join_registrar or whatever. I do insist quite strongly that it be described in the BRSKI document. > I would like XXX = ACP because XXX = AN seems to imply the network is > autonomic, which i think by definition it is not unless we have intent ;-P. > XXX = ANI would also be wrong if for example we combine ACP with Netconf > Zero Touch and only offer EST-renew but not BRSKI-enroll. I don't care which name. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnJCV0ACgkQgItw+93Q 3WXSMAf9EqkAm8xQ/DcqeptDCHE73nQBufUZ7prLQLFa/wMgnlCjbVgR1LEmah2F wqHPEnrBQIZKU6AZ1aJkgNQLiW6JkIi7JcdXFkZ1DbHkZApCJ1X5MvsLZv0enFdO FRT2S1QEHuawjlqdXZPMURNLWvo7XsjwnkwavUNFU2J8udmUDalnBcpdtyr5qw/y t0TBXWaWJM8IrCQqzd9lKXmY1Hnb6/so4CKb051rAO3YICaOcjB4HSIB2xl658i0 bPdBj6TBZoodo0Tgd8RmGh7nQkfg9ZC4KNHMGfz+qoCgIKhFjiq0dcc652bxM3OT dR9ouWV/5NJsTVmWLDfhhuNfiv+2hw== =dB7Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 25 12:36:55 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8B0134576; Mon, 25 Sep 2017 12:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 686aImt6D2sN; Mon, 25 Sep 2017 12:36: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 7C7BA134587; Mon, 25 Sep 2017 12:36:49 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 96E2B58C4E9; Mon, 25 Sep 2017 21:36:44 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 78554B0CCC2; Mon, 25 Sep 2017 21:36:44 +0200 (CEST) Date: Mon, 25 Sep 2017 21:36:44 +0200 From: Toerless Eckert To: Brian E Carpenter , cabo@tzi.org Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org Message-ID: <20170925193644.GA9705@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> <20170923065956.GC32014@faui40p.informatik.uni-erlangen.de> <3ad2ebe1-c975-d115-4f26-2fe792f02779@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ad2ebe1-c975-d115-4f26-2fe792f02779@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] GRASP objective details for registrar X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:36:54 -0000 On Sun, Sep 24, 2017 at 09:05:29AM +1300, Brian E Carpenter wrote: > > What's the CBOR/CDDL tool you're using, i'll try it myelf first > > before yelling for help ;-) > > It's a Ruby tool called simply 'cddl' > > Install Ruby and then install the gem called cddl. > http://www.rubygemsearch.org/rubygems/cddl Thanks! [ Cabo: Would be great if the output of cddl generate would show barewords as strings and not as hexadecimal... ] > I would argue that in many cases of simple objectives this would be a mistake. > It's a conceptual and practical complication for the ASA writer, unless a > map (and probably JSON) is already "native" for the problem at hand. > I am absolutely not against maps for cases where they are the natural > solution. But if the objective happens to be a simple value, why? Sure. My high level question is how CBOR in IETF can and will establish a larger framework of pre-defined/reused data types so that app developer using GRASP (or other protocols with CBOR) could easier reuse existing data-types when composing new information models. I remember the initial discussion about how to indicate IPv6 addresses etc. pp. My simple starting point idea within GRASP is to allow a structure in which we can start defining such standardized data-types and reuse them. They would not be at all mandatory, but offered as an option to objective developers. The two simple ways to do this is to use a map where the key 'std:' has a sub-map with standardized keys using standardized value structures. So, for M_FLOOD of services, which is what we need for ACP and BRSKI, the standardized parameters i am interested in are: -> ability to indicate sender-ttl -> Ability to express service in an RFC2782/RFC6335 compatible fashion so that: a) We do not have to come up with a registry of our own, but just register the services names according to RFC6335 b) We can perform service selection also compatible with RFC2782 if desired (prio/weight). Appended the fixed syntax that i would want to propose as the structure for mflood objective values - in a followup draft. In ACP i will just use the definitions without assuming those will establish a standard registry - that way we can make the choice whether we like the idea of this becoming a standard registry for future work. (oh: and if/when the low-bitrate folks start to complain about keys as barewords not being efficient, we can always add a numerical registration based map option.) Cheers Toerless objective-value = mflood-ovalue ; objective-value in M_FLOOD: mflood-ovalue /= { 1*parameter } ; Standardized parameter: parameter //= ( std: { 1*std-param } ) ; Any non-standardized objective-value elements can be ; added by objectives in two ways: ; a) add to parameters (any map/tlv where the type is not 'std'). ; This allows to have both std-param and objective specific params ; together ; parameter //= ... ; b) choose a different value for mflood-ovalue, eg: ; string or list. Then you can not use std-param ; mflood-ovalue /= ... ; value of ttl field of flood-message as set by sender. ; Upon receipt, (sender-ttl - ttl) is the distance of ; the receiver from the sender. std-param //= ( grasp-sender-ttl: 1..255 ) ; DNS-SD compatible service supported by objective. ; service-name must be registered according to RFC6335 ; an would therefore also useable in RFC2782 (DNS-SD) ; Do not register protocol/port numbers for new services ; unless there is a good reason. When using GRASP/ACP, ; protocol/port can be dynamically discovered. std-param //= ( service: service ) service = { service-name , *service-param } ; Same syntax, guidelines as service name in rfc2782 service-name = ( name: tstr ) service-param = selection-param ; Same semantic as rfc2782. Default = 0 selection-param //= ( priority: 0..65535 ) selection-param //= ( weight: 0..65535 ) From nobody Mon Sep 25 12:38:12 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6461913458D for ; Mon, 25 Sep 2017 12:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcSmAyPdZJGZ for ; Mon, 25 Sep 2017 12:38:09 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C91134586 for ; Mon, 25 Sep 2017 12:38:09 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id r68so4314954pfj.3 for ; Mon, 25 Sep 2017 12:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=53bP0si1l6Kqc6I9AzjJAQwt5VEOdr3XPubYPcZtB7I=; b=rYtmmtPv0F8JXD7EYn6upS+4wfZCI150VuR6hZ8NM9OkzEfDc0xdnSkujd56K0T9kB tb2FXbzKYlzTGHCSG68JI1nCyMmakSDkNjjRK2+B9bqsYT81NS1qqN7aMyriG8IMwjq+ 3uZ+H+MSdc11Dyx8BfHfIa5hwGVQB0OofzuG4oFHVzk9EwwNEmeNvmjWHbUQfaME1bOh tjzY25ca4kQ0qZLji6/S/paSz+pi4YkMWAQcv96hfPVlWyv92AoVpfJa3BdfPAVP12hx Znplm5ytJ2AlTnNrGtysuapzt1imiwNuECWT4mFkYAH92AgICS7t9vJ1aq85bCx1eD74 DBPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=53bP0si1l6Kqc6I9AzjJAQwt5VEOdr3XPubYPcZtB7I=; b=FRUpTAISOXJYTL4/1GsyCCNbLA7+AdzyWGhm38Gj+vYsJQdvznEADBJQCdJs80/IT0 bxGUFFBlhnAghS8kOyasSL/7/d5HNAuuQ2ZHE15OHvdSmt/x2kTrtkddXer3WQZavj5V FsEIk8+5LBgO6jxw105imF28QerrKup0uvVyY+pD1MaMLEy3i9b5DMwkWrULWC48I0+i UOQCs16b+v7lmSmq9d4fmPbd7B8H7yZP2wvZX5Knh2w4UBYWIt2tZwzdbHLyo3sU7eoO lYgd/gcNDt+gu4SbIYdOeLS2So33VlJOR2xCyCQM6/LNtwQiKuDyDAa8tWyqYEBwNhBV c/rQ== X-Gm-Message-State: AHPjjUhoAUfr5xu2UXnYrs8hCn2Ku1po826Xkhkt2JVzZIOBmb9VZIi8 mNETWnJhnE8K/eCnuUufI9B5Azi4 X-Google-Smtp-Source: AOwi7QAYIAB7P/cpBTjt5PPv/O8iLV2+YSb+qky4qRvt3+1oI0i6oC2iGVXSnZAZiqYONGmULPfJyQ== X-Received: by 10.99.113.94 with SMTP id b30mr8691699pgn.312.1506368288919; Mon, 25 Sep 2017 12:38:08 -0700 (PDT) Received: from ?IPv6:2406:e007:7d76:1:28cc:dc4c:9703:6781? ([2406:e007:7d76:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r16sm12790531pfk.178.2017.09.25.12.38.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 12:38:08 -0700 (PDT) To: anima@ietf.org Cc: Michael Richardson , Toerless Eckert References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> <23496.1506346820@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6af7671d-81b8-a40b-e3d1-2bc9a9acc6b0@gmail.com> Date: Tue, 26 Sep 2017 08:38:08 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <23496.1506346820@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP objectives used in multiple documents [was I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:38:11 -0000 Separating out one issue: On 26/09/2017 02:40, Michael Richardson wrote: > > Brian E Carpenter wrote: [Discussing whether the ACP draft or the BRKSI draft or both should define the GRASP objective AN_join_registrar] > brian> Toerless explained elsewhere why he thinks the duplication is > brian> needed. > > I read that after my email. > I simply can't agree. As a general matter, what do people in the WG think we should do when different aspects of the same objective are defined in different drafts? There are at least three possible solutions: 1. Accept this situation; both documents will be references for the IANA registry at https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml#objective-names 2. Forbid this situation. 3. Have the complete definition in document A and make a normative reference to it in document B. Brian From nobody Mon Sep 25 13:18:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D5313457C; Mon, 25 Sep 2017 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtirwK2OiChb; Mon, 25 Sep 2017 13:18:19 -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 0C83E13306A; Mon, 25 Sep 2017 13:18:19 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 22F7D58C4EB; Mon, 25 Sep 2017 22:18:15 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0B721B0CCC7; Mon, 25 Sep 2017 22:18:14 +0200 (CEST) Date: Mon, 25 Sep 2017 22:18:14 +0200 From: Toerless Eckert To: Michael Richardson Cc: Brian E Carpenter , anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20170925201814.GB9705@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> <23496.1506346820@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23496.1506346820@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:18:21 -0000 On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote: > brian> Toerless explained elsewhere why he thinks the duplication is > brian> needed. > > I read that after my email. > I simply can't agree. I don't think i was suggesting duplication. I was suggesting for one document to define an extensibel objective and the other draft to extend it. The extensibel notation i was suggesting would also result in the definition of a brski-enrol service name that would be useable outside of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI. > >> ====== section 11 > >> This document may be considered to be updating the IPv6 addressing > >> architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast > >> addresses ([RFC4193]) depending on how strict specific statements in > >> > >> I don't like this statement. Either it violates the spec, and updates it, or > >> it does not. I do not think that it violates. This is not a multi-link > >> subnet, this is a prefix that is not on-link. > > brian> As readers of the 6man list know, this has been a very contentious topic. > brian> I think it's safer to duck it in the ACP draft: say what we do, but say > brian> nothing about RFC4291 etc. > > I agree. I can easily remove the whole section 11 from the ACP document and we can bring it back if/when 6man review is asking for it, no problem. > >> It is possible, that this scheme constitutes an update to RFC4191 > >> because the same 64 bit subnet prefix is used across many ACP > >> devices. The ACP Zone addressing Sub-Scheme is very similar to the > >> common operational practices of assigning /128 loopback addresses to > >> network devices from the same /48 or /64 subnet prefix. > >> > >> It does not. Brian? Do you concur? > > > Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign > > them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that > > sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links"). > > But we don't need to apologise. As you say, we're simply assigning /128 > > addresses to (virtual) interfaces using our own scheme. And we're relying > > on BCP 198 (RFC 7608) which says that routing prefixes can be any length > > up to /128. If you want to cite anything, cite RFC 7608. > > Toerless, do you want text to say this? Always happy to get text suggested, but please also with a fitting place, especially if you do not like section 11. And then do not blame me if we again get more and more explanatory text into standards sections ;-P (which i do like, but which normal IETF reviewer usually bitch about). > draft> The goal for the 8 or 16-bit addresses available to an ACP device in > draft> this scheme is to assign them as required to software components, > draft> which in autonomic networking are called ASA (Autonomic Service > > mcr> We are not providing 8-bit or 16-bit IIDs. > mcr> We are providing 256 or 65536 /128 addresses which are conveniently > mcr> aggregated for routing purposes. Hmm... I guess you are implying but also prefer not to explicitly say: -> If an implementation wants to pick any shorter than /127 prefix from thiss block of addresses to assign to a subnet, then it's up to that implementation to argue how such an implementation will fit the IPv6 architecture. The ACP document does no require or prescribe any such approaches. > draft> In practical terms, the ACP should be enabled to create from its /8 > draft> or /16 prefix one or more device internal virtual subnets and to > draft> start software components connected to those virtual subnets. > > mcr> No, don't say this, and don't do this in practice. Create /128 routes to LL > mcr> address of the internal VM and configure the /128 as a loopback address > mcr> inside the VM. > > brian> So yes, I concur with Michael. Ok, let me see how to best deal with this all. > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- tte@cs.fau.de From nobody Mon Sep 25 16:28:54 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3EE1345F4; Mon, 25 Sep 2017 16:28:50 -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 IbbpMp-PBHHD; Mon, 25 Sep 2017 16:28:48 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E985132355; Mon, 25 Sep 2017 16:28:48 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id k193so4889748pgc.8; Mon, 25 Sep 2017 16:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=HKlaaIAfCneVJmvgz1uORZ0Rt66vH5zkyDBAz48PNlI=; b=LPhbkRSTPHHBY5ZJdnbwAqx3GATtnGFCViF4VZFHGAKorvowRDarArgD3cwAWA1wmF BW2kxuNDpgOn33I+vySul+PE0aP3tEmOc0haeneA/hlBxJ2rPihAbyJUs816RNvbFbM8 uFiKia0EXGTYycJzkqy2dH8e0hIZeSa13UGBTOxNPxiKG2irIxli7IwHAp7bk4pvdd9w R84DB4BiMeCW1aRmEpMf4+V2rKFjAG6P/xKSY4z4/3HYIbcoyMY9Ki3UfEiVtP7+YrLC tzyHTbLIDbuutVBYIN1eEcSfC2/4E3PcwfilWexVaMCIigBZBxxWfNN+4j4HIBkAPrFf CKMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=HKlaaIAfCneVJmvgz1uORZ0Rt66vH5zkyDBAz48PNlI=; b=bb82rc5GFymdl2OXWY5Nmck48Mq2v/obBX72H2TC/JWEuqtky0l8A3cfe2Mm2KNquv ItDo3pfXfW0ySFEMSX/jsVO7YpHzoo5Dta6QVo6F3wqqPfxH8+tg6Q60gq0g5cc+mKE3 X5vVNcnk9R77lxkZGTTIB0v5KwM61E7peJVzrH/+UxJ8Ebnbw9JJutDEzPC6L4qn1lrT ahVtQSPG1Ruuoh1s49AOM2V/Dxhkew0mddzpS+r59MHTckJYwpJH7QRYUlqLMsDoCOtf pTZmmqvd4hG7VSomyAQeWRNRnrsKz/OxbcEd0ddCa5ba/N0E1JpXLpxmVcZXFfWiUQpq G+vg== X-Gm-Message-State: AHPjjUhCIdYVQZVRJepxKi+a/nzhFgq+laeCRt8qNTcxY+rmvjnufXMY mrAOvmRloNnQ4fC5Ac5eqZzg8w== X-Google-Smtp-Source: AOwi7QAve+bCKVcW84Gj+acqIfIiOTWqQE+nMfGNjZvIaSjg2UR1YhiMwffarCP+VEOdCmd/S7QCnQ== X-Received: by 10.101.81.135 with SMTP id h7mr9407805pgq.48.1506382127796; Mon, 25 Sep 2017 16:28:47 -0700 (PDT) Received: from [130.216.38.103] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.103]) by smtp.gmail.com with ESMTPSA id s62sm13809255pfe.91.2017.09.25.16.28.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 16:28:46 -0700 (PDT) To: Toerless Eckert , cabo@tzi.org Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> <20170923065956.GC32014@faui40p.informatik.uni-erlangen.de> <3ad2ebe1-c975-d115-4f26-2fe792f02779@gmail.com> <20170925193644.GA9705@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4b7558e7-c5f1-cb7e-999a-34ea7aae8ebc@gmail.com> Date: Tue, 26 Sep 2017 12:28:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170925193644.GA9705@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/mixed; boundary="------------26FAFF0F9CA994E636591C6D" Content-Language: en-US Archived-At: Subject: Re: [Anima] GRASP objective details for registrar X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 23:28:51 -0000 This is a multi-part message in MIME format. --------------26FAFF0F9CA994E636591C6D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Here's confirmation that your CDDL generates a valid objective-value. In the attached, you will find 8 Python statements and the resulting output from a GRASP instance talking to itself. If there's consensus to go this way I can update my demo code for the BRSKI actors accordingly. But we need some WG discussion about that, and I need to learn a bit about using maps in Python :-). Regards Brian On 26/09/2017 08:36, Toerless Eckert wrote: > On Sun, Sep 24, 2017 at 09:05:29AM +1300, Brian E Carpenter wrote: >>> What's the CBOR/CDDL tool you're using, i'll try it myelf first >>> before yelling for help ;-) >> >> It's a Ruby tool called simply 'cddl' >> >> Install Ruby and then install the gem called cddl. >> http://www.rubygemsearch.org/rubygems/cddl > > Thanks! [ Cabo: Would be great if the output of cddl generate would > show barewords as strings and not as hexadecimal... ] > >> I would argue that in many cases of simple objectives this would be a mistake. >> It's a conceptual and practical complication for the ASA writer, unless a >> map (and probably JSON) is already "native" for the problem at hand. > > I am absolutely not against maps for cases where they are the natural >> solution. But if the objective happens to be a simple value, why? > > Sure. My high level question is how CBOR in IETF can and will establish > a larger framework of pre-defined/reused data types so that app developer > using GRASP (or other protocols with CBOR) could easier reuse existing > data-types when composing new information models. I remember the initial > discussion about how to indicate IPv6 addresses etc. pp. > > My simple starting point idea within GRASP is to allow a structure > in which we can start defining such standardized data-types and > reuse them. They would not be at all mandatory, but offered as an > option to objective developers. > > The two simple ways to do this is to use a map where the key 'std:' has > a sub-map with standardized keys using standardized value structures. > > So, for M_FLOOD of services, which is what we need for ACP and BRSKI, > the standardized parameters i am interested in are: > > -> ability to indicate sender-ttl > -> Ability to express service in an RFC2782/RFC6335 compatible > fashion so that: > a) We do not have to come up with a registry of our own, but just > register the services names according to RFC6335 > b) We can perform service selection also compatible with > RFC2782 if desired (prio/weight). > > Appended the fixed syntax that i would want to propose as the structure for > mflood objective values - in a followup draft. In ACP i will just > use the definitions without assuming those will establish a standard > registry - that way we can make the choice whether we like the > idea of this becoming a standard registry for future work. > > (oh: and if/when the low-bitrate folks start to complain about > keys as barewords not being efficient, we can always add > a numerical registration based map option.) > > Cheers > Toerless > > objective-value = mflood-ovalue > > ; objective-value in M_FLOOD: > mflood-ovalue /= { 1*parameter } > > ; Standardized parameter: > parameter //= ( std: { 1*std-param } ) > > ; Any non-standardized objective-value elements can be > ; added by objectives in two ways: > ; a) add to parameters (any map/tlv where the type is not 'std'). > ; This allows to have both std-param and objective specific params > ; together > ; parameter //= ... > ; b) choose a different value for mflood-ovalue, eg: > ; string or list. Then you can not use std-param > ; mflood-ovalue /= ... > > ; value of ttl field of flood-message as set by sender. > ; Upon receipt, (sender-ttl - ttl) is the distance of > ; the receiver from the sender. > std-param //= ( grasp-sender-ttl: 1..255 ) > > ; DNS-SD compatible service supported by objective. > ; service-name must be registered according to RFC6335 > ; an would therefore also useable in RFC2782 (DNS-SD) > ; Do not register protocol/port numbers for new services > ; unless there is a good reason. When using GRASP/ACP, > ; protocol/port can be dynamically discovered. > > std-param //= ( service: service ) > service = { service-name , *service-param } > ; Same syntax, guidelines as service name in rfc2782 > service-name = ( name: tstr ) > service-param = selection-param > ; Same semantic as rfc2782. Default = 0 > selection-param //= ( priority: 0..65535 ) > selection-param //= ( weight: 0..65535 ) > > --------------26FAFF0F9CA994E636591C6D Content-Type: text/plain; charset=UTF-8; name="sample.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sample.txt" aW1wb3J0IGdyYXNwDQplcnIsIGFub25jZSA9IGdyYXNwLnJlZ2lzdGVyX2FzYSgidGVzdCIp ICNyZWdpc3RlciBhcyBhbiBhc2ENCm9iaiA9IGdyYXNwLm9iamVjdGl2ZSgiQU5fcmVnaXN0 cmFyIikgICAgI2NyZWF0ZSBhbiBvYmplY3RpdmUNCm9iai5zeW5jaCA9IFRydWUNCm9iai52 YWx1ZSA9IHsic3RkIjogeyJncmFzcC1zZW5kZXItdHRsIjogMTAsICJzZXJ2aWNlIjogeyJu YW1lIjogInRvZSIsICJwcmlvcml0eSI6IDMsICJ3ZWlnaHQiOiA1fX19DQplcnIgPSBncmFz cC5yZWdpc3Rlcl9vYmooYW5vbmNlLCBvYmopICAgICNyZWdpc3RlciB0aGUgb2JqZWN0aXZl DQp0b2JqID0gZ3Jhc3AudGFnZ2VkX29iamVjdGl2ZShvYmosTm9uZSkgICN0YWcgdGhlIG9i amVjdGl2ZSAobGF6eTogc2V0IGEgbnVsbCBsb2NhdG9yKQ0KZXJyID0gZ3Jhc3AuZmxvb2Qo YW5vbmNlLCBOb25lLCB0b2JqKSAgICAjZmxvb2QgdGhlIHRhZ2dlZCBvYmplY3RpdmUNCg0K X01haW5UaHJlYWQgMzYzNiBBc3NlbWJsZWQgUHl0aG9uIG1lc3NhZ2UgWzksIDg2Mzg4NDE1 OSwgYidmZDYzNDVlYmRjMTUwMDAwMDAwMDAwMDAwMDAwMDAwMScsIDAsIFtbWydBTl9yZWdp c3RyYXInLCA1LCA2LCB7J3N0ZCc6IHsnZ3Jhc3Atc2VuZGVyLXR0bCc6IDEwLCAnc2Vydmlj ZSc6IHsnbmFtZSc6ICd0b2UnLCAnd2VpZ2h0JzogNSwgJ3ByaW9yaXR5JzogM319fV0sIFtd XV1dIA0KX01haW5UaHJlYWQgMzYzNiBBc3NlbWJsZWQgQ0JPUiBtZXNzYWdlOiBiJzg1MDkx YTMzN2RkMzdmNTBmZDYzNDVlYmRjMTUwMDAwMDAwMDAwMDAwMDAwMDAwMTAwODE4Mjg0NmM0 MTRlNWY3MjY1Njc2OTczNzQ3MjYxNzIwNTA2YTE2MzczNzQ2NGEyNzA2NzcyNjE3MzcwMmQ3 MzY1NmU2NDY1NzIyZDc0NzQ2YzBhNjc3MzY1NzI3NjY5NjM2NWEzNjQ2ZTYxNmQ2NTYzNzQ2 ZjY1NjY3NzY1Njk2NzY4NzQwNTY4NzA3MjY5NmY3MjY5NzQ3OTAzODAnIA0KX21jbGlzdGVu IDM0MjQgIFJlY2VpdmVkIG11bHRpY2FzdCBiJzg1MDkxYTMzN2RkMzdmNTBmZDYzNDVlYmRj MTUwMDAwMDAwMDAwMDAwMDAwMDAwMTAwODE4Mjg0NmM0MTRlNWY3MjY1Njc2OTczNzQ3MjYx NzIwNTA2YTE2MzczNzQ2NGEyNzA2NzcyNjE3MzcwMmQ3MzY1NmU2NDY1NzIyZDc0NzQ2YzBh Njc3MzY1NzI3NjY5NjM2NWEzNjQ2ZTYxNmQ2NTYzNzQ2ZjY1NjY3NzY1Njk2NzY4NzQwNTY4 NzA3MjY5NmY3MjY5NzQ3OTAzODAnIGZyb20gZmU4MDo6YzBkYTphYzE3OjVmNmQ6OGU3NiBw b3J0IDUxODY1IGludGVyZmFjZSAxMSANCl9tY2xpc3RlbiAzNDI0IE11bHRpY2FzdDogQ0JP Ui0+UHl0aG9uOiBbOSwgODYzODg0MTU5LCBiJ2ZkNjM0NWViZGMxNTAwMDAwMDAwMDAwMDAw MDAwMDAxJywgMCwgW1tbJ0FOX3JlZ2lzdHJhcicsIDUsIDYsIHsnc3RkJzogeydncmFzcC1z ZW5kZXItdHRsJzogMTAsICdzZXJ2aWNlJzogeyduYW1lJzogJ3RvZScsICd3ZWlnaHQnOiA1 LCAncHJpb3JpdHknOiAzfX19XSwgW11dXV0gDQpfbWNsaXN0ZW4gMzQyNCBJbml0aWF0b3I6 IGZkNjM6NDVlYjpkYzE1OjoxIA0KX21jbGlzdGVuIDM0MjQgTGlzdGVuaW5nIGZvciBMTCBt dWx0aWNhc3RzIA0KX21jaGFuZGxlciA1NTIwIE11bHRpY2FzdCBoYW5kbGVyIGdvdCBzb21l dGhpbmcgW0lQdjZBZGRyZXNzKCdmZTgwOjpjMGRhOmFjMTc6NWY2ZDo4ZTc2JyksIDUxODY1 LCAxMSwgWzksIDg2Mzg4NDE1OSwgYidmZDYzNDVlYmRjMTUwMDAwMDAwMDAwMDAwMDAwMDAw MScsIDAsIFtbWydBTl9yZWdpc3RyYXInLCA1LCA2LCB7J3N0ZCc6IHsnZ3Jhc3Atc2VuZGVy LXR0bCc6IDEwLCAnc2VydmljZSc6IHsnbmFtZSc6ICd0b2UnLCAnd2VpZ2h0JzogNSwgJ3By aW9yaXR5JzogM319fV0sIFtdXV1dXSANCl9tY2hhbmRsZXIgNTUyMCBHb3QgRmxvb2QgbWVz c2FnZSANCg0KZHVtcF9hbGwoKQ0KDQo8U05JUD4NCg0KRmxvb2QgY2FjaGUgY29udGVudHM6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQU5fcmVnaXN0cmFyIGNvdW50OiA2IHZhbHVlOiB7 J3N0ZCc6IHsnZ3Jhc3Atc2VuZGVyLXR0bCc6IDEwLCAnc2VydmljZSc6IHsnbmFtZSc6ICd0 b2UnLCAnd2VpZ2h0JzogNSwgJ3ByaW9yaXR5JzogM319fSBzb3VyY2U6IE5vbmUgNiA3MDE3 IDA= --------------26FAFF0F9CA994E636591C6D-- From nobody Thu Sep 28 06:22:50 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 153CF13304A; Thu, 28 Sep 2017 06:22:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk CC: tte+anima@cs.fau.de, anima-chairs@ietf.org, Toerless Eckert , draft-ietf-anima-prefix-management@ietf.org, anima@ietf.org, terry.manderson@icann.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150660496408.13716.15096110724047210602.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 06:22:44 -0700 Archived-At: Subject: [Anima] Last Call: (Autonomic IPv6 Edge Prefix Management in Large-scale Networks) to Informational RFC X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 13:22:44 -0000 The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'Autonomic IPv6 Edge Prefix Management in Large-scale Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3026/ https://datatracker.ietf.org/ipr/3027/ From nobody Thu Sep 28 06:24:07 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F03B7134737; Thu, 28 Sep 2017 06:24:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-anima-voucher@ietf.org, anima-chairs@ietf.org, Sheng Jiang , terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150660504597.13691.5244155942892496049.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 06:24:05 -0700 Archived-At: Subject: [Anima] Last Call: (Voucher Profile for Bootstrapping Protocols) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 13:24:06 -0000 The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'Voucher Profile for Bootstrapping Protocols' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". The voucher artifact is a YANG-defined JSON document that has (by default) been signed using a PKCS#7 structure. The voucher artifact is normally generated by the pledge's manufacturer or delegate (i.e. the Manufacturer Authorized Signing Authority). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Sep 29 10:25:01 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D470413214D; Fri, 29 Sep 2017 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUHYIcBaH1Vg; Fri, 29 Sep 2017 10:24:58 -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 F305813207A; Fri, 29 Sep 2017 10:24:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A1F6A200A1; Fri, 29 Sep 2017 13:30:04 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 563698189F; Fri, 29 Sep 2017 13:24:56 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20170925201814.GB9705@faui40p.informatik.uni-erlangen.de> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> <23496.1506346820@obiwan.sandelman.ca> <20170925201814.GB9705@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 17:25:00 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote: brian> Toerless explained elsewhere why he thinks the duplication is brian> needed. >> >> I read that after my email. >> I simply can't agree. > I don't think i was suggesting duplication. I was suggesting for > one document to define an extensibel objective and the other draft to > extend it. Objectives are so easy to define and require so little IANA coordination that I don't see why we would want to extend it without also updating the BRSKI document. So to be clear: this is overly general, and I am opposed to this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnOgegACgkQgItw+93Q 3WVbuwgAo4odzwNZZnsTfhg5Lohuj3C0O/HXcIdzC4gIRiYAT9VwMqcEWIJqAFhQ x4ZSygxKmS02qa43T4cKCB4bQVgrqjPTzsx5xP+f4hDT2REK7tAzkX+cUluXu+qT JwcIOq47mjwmdQ+azsOVVapOr0OPQHRFVD7np4+y12fCuhOusuJsGMjFGBS4rRWs dALQvEwmZT3WkAXtM3KPlmoAZQDVivDTjzlRsukTN+0rAVLZDPC2H56B5liIUa21 DluYXEG2lSALP73E/izxysNJyYnxDJrJ5+5AAVU/K2/OtVfmkGQvB3HtkYk5YZI/ DBSLkIbjdoybrIPFl6XMsgOqOFN3Ng== =lnmR -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 29 18:03:10 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D51134317; Fri, 29 Sep 2017 18:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjTyMZU-WSf5; Fri, 29 Sep 2017 18:03:07 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CC81342FF; Fri, 29 Sep 2017 18:03:07 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id d187so582054pfg.11; Fri, 29 Sep 2017 18:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/vP7K6abK5upi/51uZvzrCIWIzXtdFuzhv9L9RBZg6I=; b=FXuwp8VIvIRV33AOE+skxzo1ECn1TnfWTE/cm81Gw8RbR7x7kBI5xrYG4DS5fSkhuE v69/DUEDkRzdQrBFkodmC2TEV8V2xXDEFh/se7YQPDi4w0zLLFd7Y00KUsUGR8Lq3Ph7 3ObjL1t2n4NQElDvJNT/Hhsz3BiolvoDaSzJf9QpYM2KcS8Vbp4iV4U4p3wKXqViieHu bV/4EAczVfDNV3CwEUZ0xvsLXYHy2Hg4qOPgusMSfGC7n5sELuwz1vCTe6NA6Kv1enHr vnZvV2YVDta8KnVqQpP4uA4kyk09TjNsxALDx5gaRSpcUtRwauysM+DO7LhZyJe618Bk fbPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/vP7K6abK5upi/51uZvzrCIWIzXtdFuzhv9L9RBZg6I=; b=c2913T1KE5zzVpgnNVtRa9NppiTI4N+ZJq/+8uGjdd4MuVO9gAmOcwvT/dRknm97F4 h69aUmSa/u3g5XOKHHR5L1W4Xcuotq+txS17JkWS4cMAnGzb9IlUaMjIbHtwJL3NLt3y fKBNNgANQwplMBM0QWlAsoWmpyQVzfLrUYC8mR13cTqjCNS2+147SMk4VRQ9JiMFM14r jkDnhTtQYX/bgL+DlMrPFxTiyUBNU97tFNj1bH6VZdYjxfSZLjLS/JdxHskxSKqB50bq qygre+D/BJUcKFkltgyT2zgbW6ilUFzSDpHhrXUKtXJ7f5LE77luBBAUryzjv2AeI45V l8yw== X-Gm-Message-State: AHPjjUgWx/+nVCItIdyV/uHMNLaF/jshKfWpx9isbQQwYPUIJ1g86J1w 14PoHblYqCApHpGuittOLjuqcg== X-Google-Smtp-Source: AOwi7QCSIhyvdk2LCPLh4gddMXNPQcQpVEgNjleAEog0v/75/hQGYIe4AsQYB6jUN4XXZse7R3T5CA== X-Received: by 10.98.34.15 with SMTP id i15mr9396535pfi.257.1506733386282; Fri, 29 Sep 2017 18:03:06 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 65sm7881748pgh.31.2017.09.29.18.03.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 18:03:05 -0700 (PDT) To: Michael Richardson , anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> <23496.1506346820@obiwan.sandelman.ca> <20170925201814.GB9705@faui40p.informatik.uni-erlangen.de> <19014.1506705896@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 30 Sep 2017 14:03:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <19014.1506705896@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Some questions to the WG: [I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 01:03:09 -0000 On 30/09/2017 06:24, Michael Richardson wrote: > > Toerless Eckert wrote: > > On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote: > brian> Toerless explained elsewhere why he thinks the duplication is > brian> needed. > >> > >> I read that after my email. > >> I simply can't agree. > > > I don't think i was suggesting duplication. I was suggesting for > > one document to define an extensibel objective and the other draft to > > extend it. > > Objectives are so easy to define and require so little IANA coordination that > I don't see why we would want to extend it without also updating the BRSKI > document. > > So to be clear: this is overly general, and I am opposed to this. So there are several separate questions here. 1. I understood Toerless to be arguing that the registrar may need to be contacted again some considerable time after the bootstrap (i.e. join) action, specifically for what he called EST-renew. Is that agreed? 2. If yes, would that need a new discovery action? I assume the answer is yes, since we want to be reasonably stateless and not assume that we can cache the registrar's address and port indefinitely. 3. If so, do we want to re-use the same objective (AN_join_registrar for the sake of argument)? Or would we prefer this to be a distinct objective? (I don't think the question would be different in a DNS-SD regime: one service or two?) 4. In any case, do we want to make this objective or objectives highly extensible (which basically means using CBOR maps instead of simple CBOR arrays)? This has the usual pros and cons: highly extensible = more complex parsing. There's no doubt this can be done; I've already checked that even my prototype GRASP code can carry quite complex CBOR structures transparently. But it does assume that the recipient ASA can reliably parse them, which is a reasonably complex requirement for AN infrastructure components. I don't have preconceived answers to questions 1, 3 and 4. What do people think? Toerless also wrote: > The extensibel notation i was suggesting would also result in the > definition of a brski-enrol service name that would be useable outside > of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI. I didn't quite get that. Although we currently require that GRASP runs over an ACP, there is nothing magic about that. I don't see that BRSKI actually depends on the ACP either; both would surely run over bare metal if we told them to (and the Security ADs weren't watching). Brian