From nobody Tue Nov 1 15:42:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB712959C for ; Tue, 1 Nov 2016 15:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 09m1IisATTIX for ; Tue, 1 Nov 2016 15:42:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24DD12951E for ; Tue, 1 Nov 2016 15:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10600; q=dns/txt; s=iport; t=1478040154; x=1479249754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pwANKfBhTp+/8nbaKU2TgnAsJq7SDVVVCW7HxGrDVsw=; b=cWd9fVsy9pw2owEgsJ1aTiYCoG3Fg63pY1gXAsR9yiEEb/s4sEbFA51P Exf2SSjeGdZOCftusAcGAJiKr4KYBNMgu0LnJUdWCB91INXXPvs/6C3eD 1Lw5B0NM2c+ylyAfmjB3pho0vGfbLbv112Q+/1e9AFwr5r0/zr0yAcsgg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAwAlGRlY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR9YfAeNL5cAh1+MZoIHHQuCNBCDNgIagXw/FAECAQE?= =?us-ascii?q?BAQEBAWIohGEBAQEDAQEBASAEDToLBQsCAQgYAgIfBwICAh8GCxUQAgQOBRmII?= =?us-ascii?q?QMPCA6rJokBDYNzAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBB4czgliCR4FjAQE?= =?us-ascii?q?bF4JtLYIvBZQThVI1AY0EgzCBbogohXCIdoQdhAMBHjZggyQcGIE7cgGFL4Egg?= =?us-ascii?q?QwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,433,1473120000"; d="scan'208";a="342199646" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2016 22:42:33 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uA1MgX17010904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 22:42:33 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 17:42:32 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 1 Nov 2016 17:42:32 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) Thread-Index: AQHSM8TZyP6E5PobOUGQWWfnN/qHzqDDop+AgAFsHwA= Date: Tue, 1 Nov 2016 22:42:32 +0000 Message-ID: <0610AD70-3D43-4A83-BDBD-3CB8433DC3FA@cisco.com> References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.11] Content-Type: text/plain; charset="utf-8" Content-ID: <7A65EC8A9EB0F64C9E90537B1B1C5A76@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 22:42:36 -0000 DQo+IE9uIE9jdCAzMSwgMjAxNiwgYXQgNjo1OSBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBUb2VybGVzcywNCj4gT24g MDEvMTEvMjAxNiAxMToxOCwgVG9lcmxlc3MgRWNrZXJ0IHdyb3RlOg0KPj4gT24gTW9uLCBPY3Qg MzEsIDIwMTYgYXQgMDE6MjM6MzZQTSArMTMwMCwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+ Pj4+IEkgYW0gY29uZnVzZWQgYWJvdXQgdGhlIHJlYXNvbiBmb3IgdGhpcyBkaXNjdXNzaW9uLiBJ dCBzZWVtcyB5b3UgYXJlIHRyeWluZw0KPj4+PiB0byBmaWd1cmUgb3V0IGhvdyB0byBtaW5pbWl6 ZSB0aGUgaW1wYWN0IG9mIHRoZSBpbnNlY3VyZSBtdWx0aWNhc3QgcGllY2Ugb2YgR1JBU1AsDQo+ Pj4+IGJ1dCBpbiB0aGUgY29udGV4dCBvZiBBTklNQSB0aGlzIHF1ZXN0aW9uIHdvdWxkIGJlIGly cmVsZXZhbnQsIGJlY2F1c2Ugd2UgYXJlDQo+Pj4+IG5vdCBkb2luZyBhbnkgaW5zZWN1cmUgR1JB U1AgaW4gQlJTS1kgb3IgQUNQIHdpdGggY3VycmVudCBkcmFmdCAtIHRoZSB1c2Ugb2YNCj4+Pj4g aW5zZWN1cmUgR1JBU1Agd2FzIHJlbW92ZWQgaW4gdGhvc2UgZHJhZnRzIGJlZm9yZSBCZXJsaW4g YmVjYXVzZSBvZiB0aGUgbWFqb3JpdHkNCj4+Pj4gb2YgdGhlIGJvb3RzdHJhcCB0ZWFtcyBjaG9p Y2UgZm9yIEROUy1TRC9tRE5TLiANCj4+PiANCj4+PiBXaGljaCwgSSBoYXZlIHRvIHBvaW50IG91 dCwgaXMgbm90IGEgY29uc2Vuc3VzIHBvc2l0aW9uOyBkZXNpZ24gdGVhbXMgcHJvcG9zZSwNCj4+ PiB0aGV5IGRvbid0IGRlY2lkZS4gSSdtIHdhaXRpbmcgdG8gc2VlIHRoZSBuZXh0IGRyYWZ0IGJl Zm9yZSBJIHJhaXNlIHRoaXMgaXNzdWUgb24NCj4+PiB0aGUgV0cgbGlzdC4NCj4+IA0KPj4gUmln aHQuIEkgZ3Vlc3Mgd2UndmUgbm93IHBvc3RlZCBhbGwgZHJhZnRzIHdlIGNhbiBiZWZvcmUgdGhl IGRlYWRsaW5lLCBzbw0KPj4gbGV0IG1lIGNoYW5nZSB0aGlzIG1haWwgdGhyZWFkcyBzdWJqZWN0 IHRvIGdldCB0aGUgZGlzY3Vzc2lvbiBzdGFydGVkLg0KPj4gDQo+PiBDdXJyZW50IHN0YXRlOg0K Pj4gDQo+PiBhKSBUaGUgYm9vdHN0cmFwIGRlc2lnbiB0ZWFtIG1heW9yaXR5IGRpZCBjb25jbHVk ZSB0aGF0IG1ETlMgaXMgdGhlIGJlc3Qgb3B0aW9uDQo+PiAgIGZvciBkaXNjb3Zlcnkgb2YgYm9v dHN0cmFwIHByb3h5IGJ5IHRoZSBwbGVkZ2UgKGxpbmstbG9jYWwpLiBJJ2xsIHN0aWxsIGhhdmUN Cj4+ICAgdG8gcmVhZCBpbiBtb3JlIGRldGFpbCB0aHJvdWdoIHRoZSBkb2N1bWVudCB0byBzZWUg aG93IHdlbGwgdGhlIHRleHQgZGlzY3Vzc2VzDQo+PiAgIGFsbCB0aGUgcmVhc29ucyB3aHkuDQo+ IA0KPiBJIHJlc3BvbmRlZCB0byB0aGF0IHVuZGVyIGEgZGlmZmVyZW50IHN1YmplY3QgaGVhZGVy Lg0KPiANCj4+IA0KPj4gYikgSSBoYXZlIGp1c3QgcG9zdGVkIEFDUCBkcmFmdCAtMDQgaW4gd2hp Y2ggaSBoYXZlIHJldmVyc2VkIHRoZSBjaG9pY2Ugb2YgbUROUyBmb3INCj4+ICAgQUNQIGRpc2Nv dmVyeSBieSBuZWlnaGJvcnMgZnJvbSB0aGUgLTAzIHRleHQgd2hpY2ggaGFkIG1ETlMuIFNvIC0w NCBkZWZpbmVzIHRvDQo+PiAgIHVzZSAoRFVMTCkgR1JBU1AgZm9yIEFDUCBkaXNjb3Zlcnkgd2l0 aCBtb3JlIGRldGFpbHMuDQo+PiANCj4+ICAgSSBoYWQgcHV0IG1ETlMgaW50byAtMDMgYmVjYXVz ZSBvZiBteSB0aGlua2luZyB0aGF0IGFsbCB0aGUgcmVhc29ucyB0aGF0IHRoYXQgYm9vdHN0cmFw DQo+PiAgIGhhZCBmb3IgbUROUyB3b3VsZCBhKSBhbHNvIGFwcGx5IHRvIEFDUCBkaXNjb3Zlcnks IGFuZCB0aGF0IGIpIGl0IHdvdWxkIG1ha2UgbGlmZSBlYXNpZXINCj4+ICAgdG8gaGF2ZSBmZXdl ciBkaXNjb3ZlcnkgcHJvdG9jb2xzLiBhKSB3YXMgbm90IHdlbGwgdGhvdWdodCB0aHJvdWdoIG9u IG15IHNpZGUuDQo+PiANCj4+ICAgUGxzIGNoZWNrIG91dCB0aGUgdGV4dCBvbiBkaXNjb3ZlciBp biAtMDQsIGkgaG9wZSBpdCBqdXN0aWZpZXMgdXNlIG9mIEdSQVNQDQo+PiAgIGZvciBuZWlnaGJv ciBkaXNjb3ZlcnkuDQo+IA0KPiBJIHdpbGwgcmVhZCB0aGF0IGNhcmVmdWxseSwgYnV0IGZvciBt ZSB0aGF0IGRvZXNuJ3QgbmVlZCBqdXN0aWZpY2F0aW9uLCBiZWNhdXNlDQo+IHdlIG5lZWQgdGhl IEFOSSB0byBiZSBzZWxmLWNvbnRhaW5lZCwgc28gZGVwZW5kaW5nIG9uIG1ETlMgc2VlbXMgd3Jv bmcuIChJbg0KPiBmYWN0LCB3aHkgd291bGRuJ3QgY29uZmlndXJpbmcgbUROUy9ETlMtU0QvRE5T IGJlIGFuIGF1dG9ub21pYyBmdW5jdGlvbiBpdHNlbGY/KQ0KDQpUYWtlbiB0byB0aGUgZXh0cmVt ZSBvbmUgY291bGQgYXJndWUgdGhhdCB3ZSBuZWVkIEFOSSB0byBiZSBzZWxmLWNvbnRpbmVkIHNv IGRlcGVuZGluZyBvbiBJUCBzZWVtcyB3cm9uZy4gVGhlcmUgaXMgYSBwb2ludCB3aGVyZSBBTkkg bmVlZHMgdG8gZGVwZW5kIGFuZCBpbnRlZ3JhdGUgd2l0aCBleGlzdGluZyBzeXN0ZW1zLiANCg0K TXkgcG9zaXRpb24gaXMgdGhhdCB0aGUgZGVtYXJjYXRpb24gcG9pbnQgaXMgYm9vdHN0cmFwcGlu ZyBvZiB0aGUga2V5aW5nIGluZnJhc3RydWN0dXJlLiBQcmlvciB0byBib290c3RyYXBwaW5nIHdl IGRlcGVuZCBvbiBnZW5lcmljIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW9ycyB0aGF0IGFueSBkZXZp Y2UgbWlnaHQgZXhwZXJpZW5jZSBvbiBhIG1vZGVybiBuZXR3b3JrLiBQb3N0IGtleWluZyB3ZSBo YXZlIHN1ZmZpY2llbnQgbWV0aG9kcyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gQU5JIGFuZCBh bGwgdGhhdCBvdGhlciBzdHVmZi4gDQoNCkFub3RoZXIgd2F5IG9mIHN0YXRpbmcgbXkgcG9zaXRp b24g4oCcd2UgbmVlZCBib290c3RyYXBwaW5nIHRvIGJlIGFzIHdlbGwgY29udGFpbmVkIGFzIHBv c3NpYmxlLCBzbyBkZXBlbmRpbmcgb24gR1JBU1Agc2VlbXMgd3JvbmfigJ0uIEluIHRydXRoIG9m IGNvdXJzZSB0aGUgUHJveHkgdG8gUmVnaXN0cmFyIGNvbW11bmljYXRpb24gYmVuZWZpdHMgZnJv bSBHUkFTUCBzbyBpdCBpcyBzdWdnZXN0ZWQgdGhlcmUgZm9yIEFOSSBkZXZpY2VzLiBUaGlzIGNv bXByb21pc2UgaW50ZWdyYXRlcyBib290c3RyYXBwaW5nIHdpdGggQU5JIGluIGEgd2F5IHRoYXQg cHJvdmlkZXMgdmFsdWUgd2hlbiBBTkkgZXhpc3RzIGJ1dCBkb2VzbuKAmXQgZGVwZW5kIG9uIGl0 IGZvciBzaXR1YXRpb25zIHdoZXJlIGl0IGRvZXNu4oCZdCBleGlzdC4gDQoNCi0gbWF4DQoNCj4g DQo+PiANCj4+Pj4gV2hlbiBHUkFTUCBpcyBydW4gc2VjdXJlbHkgaW4gaXRzIHR3byBmb3JtcyBm b3IgdGhlIEFDUCwgaXQgaXMgYWx3YXlzIHByb3RlY3RlZC8NCj4+Pj4gZW5jcnlwdGVkIGJ5IHRo ZSBBQ1AsIHNvIGkgdGhpbmsgeW91ciBzZWN1cml0eSBjb25jZXJuIHdvdWxkIHRoZW4gbm90IGJl IHZhbGlkLg0KPj4+IA0KPj4+IEknbSBzdGlsbCB3YWl0aW5nIHRvIHNlZSBhIGNsZWFyIGV4cGxh bmF0aW9uIG9mIGhvdyB0aGUgQUNQIHdpbGwgc2VjdXJlDQo+Pj4gTEwgbXVsdGljYXN0LCBob3dl dmVyLg0KPj4gDQo+PiBJIGFtIG5vdCBzdXJlIGkgdW5kZXJzdGFuZCB0aGUgZG9jdW1lbnRhdGlv biBhc2suIFRoZSBBQ1AgaGFzIGEgYnVuY2ggb2YgKHZpcnR1YWwpIGludGVyZmFjZXMuIEluDQo+ PiB0aGUgbW9zdCBzaW1wbGUgaW1wbGVtZW50YXRpb24gb3B0aW9uLCBlYWNoIEFDUCBjaGFubmVs IHRvIGFuIEFDUCBuZWlnaGJvciBpcyBpdHMgb3duDQo+PiAocDJwKSBMMyBpbnRlcmZhY2UgaW4g dGhlIEFDUC4gQW5kIHRoYXRzIGFsbCB0aGUgaW50ZXJmYWNlcyB0aGUgQUNQIGhhcy4NCj4gDQo+ IEFuZCB0aGF0J3MgdGhlIHByb2JsZW0uIEdSQVNQIGRpc2NvdmVyeSBhbmQgZmxvb2RpbmcgbmVl ZCBzb2NrZXRzIHRoYXQNCj4gc3VwcG9ydHMgbGluay1sb2NhbCBtdWx0aWNhc3Qgc2VuZGluZyBh bmQgcmVjZWl2aW5nIGZvciBlYWNoIHBoeXNpY2FsDQo+IGludGVyZmFjZS4NCj4gDQo+IEN1cnJl bnRseSB0aGUgR1JBU1AgY29kZSBmaW5kcyBvdXQgaG93IG1hbnkgcGh5c2ljYWwgaW50ZXJmYWNl cyBpdCBoYXMNCj4gYW5kIGZvciBlYWNoIG9uZSBjcmVhdGVzIGEgbXVsdGljYXN0IHNlbmRpbmcg c29ja2V0LiBJdCBhbHNvIGhhcyBhIHNvY2tldA0KPiB0aGF0IGxpc3RlbnMgZm9yIGluY29taW5n IGxpbmstbG9jYWwgbXVsdGljYXN0cyBvbiBhbGwgcGh5c2ljYWwgaW50ZXJmYWNlcy4NCj4gSSBk b24ndCBzZWUgaG93IHRvIGRvIHRoYXQgdXNpbmcgdGhlIEFDUCBpbnRlcmZhY2VzIHRoYXQgeW91 IGRlc2NyaWJlLg0KPiANCj4+IEFsbCBwYWNrZXRzLCB1bmljYXN0IG9yIG11bHRpY2FzdCB0aGF0 IGFyZSBzZW50IGludG8gb3IgDQo+PiByZWNlaXZlZCBmcm9tIHRob3NlIGludGVyZmFjZXMgYXJl IHByb3RlY3RlZC9lbmNyeXB0ZWQgYnkgdGhlIGZhY3QgdGhhdCB0aGV5IGFyZSB0cmFuc21pdHRl ZA0KPj4gZW5jcnlwdGVkIGJ5IHRoZSBzZWxldGVkIEFDUCBjaGFubmVsIGVuY3J5cHRpb24gcHJv dG9jb2wuDQo+IA0KPiBZZXMsIGFuZCBJJ2QgbGlrZSB0aGUgTEwgbXVsdGljYXN0IHRyYWZmaWMg dG8gYmUgcHJvdGVjdGVkIHRvby4NCj4gQnV0IGFzIGZhciBhcyBJIGNhbiBzZWUgdGhhdCBuZWVk cyBleHBsaWNpdCBzdXBwb3J0IGluIHRoZSBBQ1ANCj4gdG8gZW11bGF0ZSBMTCBtdWx0aWNhc3Qg c29ja2V0cy4gVGhlIGlkZWFsIHdvdWxkIGJlIHRoYXQgdGhlIEFDUA0KPiBzaW1wbHkgZW11bGF0 ZXMgTEwgaW50ZXJmYWNlcywgc28gdGhhdCBHUkFTUCBjb3VsZCB0cmVhdCB0aGVtIGV4YWN0bHkN Cj4gbGlrZSBwaHlzaWNhbCBpbnRlcmZhY2VzLg0KPiANCj4gSWYgeW91IHdhbnQsIEkgY2FuIHBv aW50IHlvdSB0aGUgZXhhY3QgUHl0aG9uIGNvZGUgdGhhdCBoYW5kbGVzIHRoaXMNCj4gaW4gdGhl IHByb3RvdHlwZS4NCj4gDQo+PiANCj4+Pj4gRG8geW91IHNlZSBzb21lIElvVCBjb250ZXh0IHdo ZXJlIHlvdSB3b3VsZCB1c2UgaW5zZWN1cmUgR1JBU1AgaW5zdGVhZCBvZiBETlMtU0QvbUROUywN Cj4+Pj4gZWc6IGluIHNvbWUgSW9UIGNvbnRleHQgPw0KPj4+IA0KPj4+IE1pY2hhZWwgY2FuIGFu c3dlciB0aGF0IGZvciBoaW1zZWxmLCBidXQgdGhlIHJlYXNvbiB3ZSBub3RlZCB0aGUgKnBvc3Np YmlsaXR5Kg0KPj4+IG9mIGRvaW5nIHRoaXMgaW4gZ3Jhc3AtMDggaXMgYmVjYXVzZSBpdCBzZWVt cyBjbGVhcmx5IGhhcm1sZXNzLiBTbyBmcm9tIHRoZQ0KPj4+IEdSQVNQIHNwZWMgcG9pbnQgb2Yg dmlldywgSSBjb25zaWRlciB0aGUgaXNzdWUgY2xvc2VkLg0KPj4gDQo+PiBVZXMsIGkgYW0gbW9z dGx5IGludGVyZXN0ZWQgaW4gdXNlLWNhc2UgZXhwbGFuYXRpb25zIE1pY2hhZWwgaGFzIGluIG1p bmQuDQo+PiANCj4+IFRoZSBvdGhlciBwaWVjZSB3YXMgdGhhdCBNaWNoYWVsIHdhcyB0cnlpbmcg dG8gZmlndXJlIG91dCBob3cgdG8gYXZvaWQgdXNpbmcgTEwgbXVsdGljYXN0DQo+PiBhbmQgaW5z dGVhZCB1c2UgdW5pY2FzdDoNCj4+IA0KPj4gLT4gV2l0aGluIHRoZSBBQ1AgdGhpcyBxdWVzdGlv biBpcyBzb21ld2hhdCBpcnJlbGV2YW50IGJlY2F1c2UgaXRzIHNlY3VyZWQuDQo+PiANCj4+IC0+ IEdpdmVuIGhvdyBBQ1AgaW50ZXJmYWNlcyBhcmUgcDJwIHNlY3VyZWQgaW50ZXJmYWNlcyB0byBu ZWlnYmhvcnMsIHlvdQ0KPj4gICAgY291bGQga25vdyB1cGZyb250IHRoZSBMTCBJUHY2IGFkZHJl c3Mgb2YgdGhlIG5laWdoYm9yIG9uIHRoZSBpbnRlcmZhY2UsDQo+PiAgICBidXQgdGhlcmUgaXMg cmVhbGx5IG5vIGZyYW1ld29yayBpbiBJRVRGIHByb3RvY29scyB0aGF0IGxldmVyYWdlcyB0aGlz DQo+PiAgICBvcHRpbWl6YXRpb24gZm9yIHAycCBsaW5rcywgc28gaSBkb24ndCB0aGluayB3ZSBz aG91bGQgYm90aGVyIGRvaW5nIGl0Lg0KPj4gICAgSXRzIHdvcmsgd2l0aG91dCBSb0kuDQo+PiAN Cj4+IC0+IE91dHNpZGUgdGhlIEFDUCBpIGFtIG5vdCBzdXJlIGFib3V0IHRoZSB1c2UtY2FzZS4g VG8gYmUgb3B0aW9ucyBwcm9vZjogR1JBU1ANCj4+ICAgIHNob3VsZCBwZXJtaXQgc2VuZGluZyBh bmQgcmVjZWl2aW5nIG9mIExMIFVOSUNBU1QgaW5zdGVhZCBvZiBMTCBtdWx0aWNhc3QgZm9yDQo+ PiAgICB0aG9zZSBtZXNzYWdlcyB3aGVyZSBHUkFTUCBzcGVjaWZpZXMgTEwgbXVsdGljYXN0LCBz byB0aGF0IGlmIHNvbWUgZGVwbG95bWVudA0KPj4gICAgZmlndXJlcyBvdXQgdGhhdCB0aGVyZSBp cyBzb21lIG9wdGltaXphdGlvbiBwb3NzaWJsZSB3aXRoIHRoZSB1c2Ugb2YgTEwgdW5pY2FzdCwg DQo+PiAgICB0aGVuIGl0IGNhbiBzaW1wbHkgZG8gdGhhdCBpbnN0ZWFkIG9mIGFza2luZyBmb3Ig YSBHUkFTUCBzcGVjIG1vZGlmaWNhdGlvbi4NCj4gDQo+IFN1cmUuIFRoYXQgd2FzIG15IGNvbmNs dXNpb24gKGZvciBkaXNjb3Zlcnk7IGl0IG1ha2VzIG5vIHNlbnNlIGZvciBmbG9vZGluZykuDQo+ IA0KPj4gICAgVGhlIGJpZyBzZWN1cml0eSByaXNrIHRob3VnaCBpcyBHTE9CQUwgVU5JQ0FTVCBN VVNUIE5PVCBCRSBQRVJNSVRURUQgDQo+PiAgICBhcyBhIHJlcGxhY2VtZW50IGZvciBMTCBtdWx0 aWNhc3QuIFRoYXRzIGFuIGF0dGFjayB2ZWN0b3IuIEFuZCB0eXBpY2FsDQo+PiAgICBzb2NrZXQg c29mdHdhcmUgY29kZSBpcyB1c3VhbGx5IHZpY3RpbSB0byB0aGF0LiBBa2E6IHlvdSBvcGVuIGEg c29ja2V0LA0KPj4gICAgeW91IGJpbmQgaXQgdG8gYSBsaW5rLWxvY2FsIG11bHRpY2FzdCBncm91 cCBhbmQgeW91IGdvIGF3YXkuIEFsYXM6IHRoaXMNCj4+ICAgIHNvY2tldCB3aWxsIHJlY2VpdmUg bm90IG9ubHkgbGluay1sb2NhbCBtdWx0aWNhc3QsIGJ1dCBhbHNvIExMIHVuaWNhc3QgKGdvb2Qp DQo+PiAgICBhbmQgZ2xvYmFsIHVuaWNhc3QgKGJhZCkuIFNvIHRoZSBhcHBsaWNhdGlvbiBjb2Rl IHVzdWFsbHkgd291bGQgbmVlZCB0byBjaGVjaw0KPj4gICAgdGhlIGRlc3RpbmF0aW9uIGFkZHJl c3MgdGhlIHBhY2tldCB3YXMgc2VudCB0byBhbmQgZHJvcCB0aG9zZSBwYWNrZXRzIA0KPj4gICAg c2VudCB0byB0aGUgZ2xvYmFsIHVuaWNhc3QgYWRkcmVzcyAtIGlmIHRoZSBwcm90b2NvbCB3YXMg cmVhbGx5IG9ubHkNCj4+ICAgIGRlc2lnbmVkIGZvciBMTCBtdWx0aWNhc3QgLSBhbmQgdGhlcmVm b3JlIGFzc3VtaW5nIHNlY3VyaXR5IHByb3BlcnRpZXMNCj4+ICAgIG9mIExMIG11bHRpY2FzdCAo bG9naWNhbCB2aWNpbml0eSBvZiBzZW5kZXIpLg0KPiANCj4gR1JBU1AgZGlzY292ZXJ5IGFuZCBm bG9vZCBhcmUgc3BlY2lmaWVkIGFzIGxpbmstbG9jYWwsIHNvIHllcywgdGhhdCBjaGVjaw0KPiBp cyBuZWVkZWQuDQo+IA0KPj4gICAgQSBnb29kIGV4YW1wZSBmb3IgcmVwbGFjaW5nIG11bHRpY2Fz dCB3aXRoIHVuaWNhc3QgaXMgV2lGSSB3aGVyZSBsdWNraWx5DQo+PiAgICBob3N0cyBkbyBhY2Nl cHQgbXVsdGljYXN0IHBhY2tldHMgYXMgTDIgdW5pY2FzdCBpbnN0ZWFkIG9mIEwyIG11bHRpY2Fz dC4NCj4+ICAgIEFuZCB0aGF0cyBkb25lIHRvIGdldCB0aGUgYmVuZWZpdCBvZiBMMiByZXRyYW5z bWlzc2lvbnMsIHRoYXQgZG8gbm90IGV4aXN0DQo+PiAgICBmb3IgTDIgbXVsdGljYXN0Lg0KPiAN Cj4gQWNrLg0KPiAgIEJyaWFuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= From nobody Tue Nov 1 16:02:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283D6129589 for ; Tue, 1 Nov 2016 16:02:03 -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 TVFxIdqppj4I for ; Tue, 1 Nov 2016 16:02:00 -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 B640A129540 for ; Tue, 1 Nov 2016 16:02:00 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id i88so8991824pfk.2 for ; Tue, 01 Nov 2016 16:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DoXZoeIG7LiV6DgZvA2b68RVy04pTOl6L3MYVNaJod8=; b=yliSFZD4bBRJefu1p/AYkPrAm0vrKAGcXWAhmnCYpbF633bQZXmjpC96eWnJjY2KTW TkKScRU9/zXUeiQyOsdANp8Yc4TkhSKyCVNhl+bKdJQoDhlANdrqNmIc1NhUW1slpH51 knbtbXrpginc644cB93xtIaipGACkTNus1ld0/oPKmFZuErhEPubtUioyIVE4sJgHElD CcvdBesIRgBP9b7nhRB1OS1u9kDCuUrcdf4G+eyDPiKIe8qZMQZ4oJmwq/caMx8y4tpp /9S5pKWB8s0BYLg04gVczhPyyW2kP9QMWyGnxqWjLrha7vO/ebC2/Bp9s0aRKxL1Gbf2 UZbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DoXZoeIG7LiV6DgZvA2b68RVy04pTOl6L3MYVNaJod8=; b=WwRxCklV34oAMy/13SY0cOMM3YAo5FG4vOv+7jfexOAZN0EQwKuhtqmX7J4qos86RK hCbcTJI0Ad20Vp/WxX7hHwUvMJ8jWKknWgGlWpJTxAilDmuTrHtB6lO5lNvRCmqajIVF WJE2nRQqtLfiqnx20FAqGvF9YeWzU4qakjRf7OGi2KR4jhqNPrsnZ7xTdASxQcr9G/V3 5L+OLnDOhA0aIojLWJGEPOqSbx7UaMxF/ZmF9CPtKHavGWdklq8FlJybyyzj7RcwBNcz gfAaHnVzwA8WmQIg8vtqqTXU0+Z0oHXfr6JS9Anprl4aIGQ7CwCSCLKXipKOGOwaS3BQ NvHQ== X-Gm-Message-State: ABUngvfDBipY6x+bdI4xUZDWEQN7GJpJSf9D7wAQBXWaaj+s6rnrQnRxHbmAfANI8IgQKA== X-Received: by 10.98.139.157 with SMTP id e29mr794951pfl.115.1478041319992; Tue, 01 Nov 2016 16:01:59 -0700 (PDT) Received: from [192.168.178.23] ([118.148.117.117]) by smtp.gmail.com with ESMTPSA id xg4sm44582363pac.39.2016.11.01.16.01.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 16:01:59 -0700 (PDT) To: "Max Pritikin (pritikin)" References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <0610AD70-3D43-4A83-BDBD-3CB8433DC3FA@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4aaa97d7-8a9e-5b32-a4f8-54be3cdabe09@gmail.com> Date: Wed, 2 Nov 2016 12:01:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0610AD70-3D43-4A83-BDBD-3CB8433DC3FA@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 23:02:03 -0000 In line... On 02/11/2016 11:42, Max Pritikin (pritikin) wrote: >=20 >> On Oct 31, 2016, at 6:59 PM, Brian E Carpenter wrote: >> >> Hi Toerless, >> On 01/11/2016 11:18, Toerless Eckert wrote: >>> On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote: >>>>> I am confused about the reason for this discussion. It seems you ar= e trying >>>>> to figure out how to minimize the impact of the insecure multicast = piece of GRASP, >>>>> but in the context of ANIMA this question would be irrelevant, beca= use we are >>>>> not doing any insecure GRASP in BRSKY or ACP with current draft - t= he use of >>>>> insecure GRASP was removed in those drafts before Berlin because of= the majority >>>>> of the bootstrap teams choice for DNS-SD/mDNS.=20 >>>> >>>> Which, I have to point out, is not a consensus position; design team= s propose, >>>> they don't decide. I'm waiting to see the next draft before I raise = this issue on >>>> the WG list. >>> >>> Right. I guess we've now posted all drafts we can before the deadline= , so >>> let me change this mail threads subject to get the discussion started= =2E >>> >>> Current state: >>> >>> a) The bootstrap design team mayority did conclude that mDNS is the b= est option >>> for discovery of bootstrap proxy by the pledge (link-local). I'll s= till have >>> to read in more detail through the document to see how well the tex= t discusses >>> all the reasons why. >> >> I responded to that under a different subject header. >> >>> >>> b) I have just posted ACP draft -04 in which i have reversed the choi= ce of mDNS for >>> ACP discovery by neighbors from the -03 text which had mDNS. So -04= defines to >>> use (DULL) GRASP for ACP discovery with more details. >>> >>> I had put mDNS into -03 because of my thinking that all the reasons= that that bootstrap >>> had for mDNS would a) also apply to ACP discovery, and that b) it w= ould make life easier >>> to have fewer discovery protocols. a) was not well thought through = on my side. >>> >>> Pls check out the text on discover in -04, i hope it justifies use = of GRASP >>> for neighbor discovery. >> >> I will read that carefully, but for me that doesn't need justification= , because >> we need the ANI to be self-contained, so depending on mDNS seems wrong= =2E (In >> fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic functio= n itself?) >=20 > Taken to the extreme one could argue that we need ANI to be self-contin= ed so depending on IP seems wrong. There is a point where ANI needs to de= pend and integrate with existing systems.=20 >=20 > My position is that the demarcation point is bootstrapping of the keyin= g infrastructure. Prior to bootstrapping we depend on generic mechanisms = and behaviors that any device might experience on a modern network. Post = keying we have sufficient methods to differentiate between ANI and all th= at other stuff.=20 >=20 > Another way of stating my position =E2=80=9Cwe need bootstrapping to be= as well contained as possible, so depending on GRASP seems wrong=E2=80=9D= =2E In truth of course the Proxy to Registrar communication benefits from= GRASP so it is suggested there for ANI devices. This compromise integrat= es bootstrapping with ANI in a way that provides value when ANI exists bu= t doesn=E2=80=99t depend on it for situations where it doesn=E2=80=99t ex= ist.=20 I think we completely agree on that goal. It's just a matter of arranging= the mandatory mechanisms in the best relationship to achieve that goal. I suggested in https://www.ietf.org/mail-archive/web/anima/current/msg021= 98.html how I would achieve this. Brian > - max >=20 >> >>> >>>>> When GRASP is run securely in its two forms for the ACP, it is alwa= ys protected/ >>>>> encrypted by the ACP, so i think your security concern would then n= ot be valid. >>>> >>>> I'm still waiting to see a clear explanation of how the ACP will sec= ure >>>> LL multicast, however. >>> >>> I am not sure i understand the documentation ask. The ACP has a bunch= of (virtual) interfaces. In >>> the most simple implementation option, each ACP channel to an ACP nei= ghbor is its own >>> (p2p) L3 interface in the ACP. And thats all the interfaces the ACP h= as. >> >> And that's the problem. GRASP discovery and flooding need sockets that= >> supports link-local multicast sending and receiving for each physical >> interface. >> >> Currently the GRASP code finds out how many physical interfaces it has= >> and for each one creates a multicast sending socket. It also has a soc= ket >> that listens for incoming link-local multicasts on all physical interf= aces. >> I don't see how to do that using the ACP interfaces that you describe.= >> >>> All packets, unicast or multicast that are sent into or=20 >>> received from those interfaces are protected/encrypted by the fact th= at they are transmitted >>> encrypted by the seleted ACP channel encryption protocol. >> >> Yes, and I'd like the LL multicast traffic to be protected too. >> But as far as I can see that needs explicit support in the ACP >> to emulate LL multicast sockets. The ideal would be that the ACP >> simply emulates LL interfaces, so that GRASP could treat them exactly >> like physical interfaces. >> >> If you want, I can point you the exact Python code that handles this >> in the prototype. >> >>> >>>>> Do you see some IoT context where you would use insecure GRASP inst= ead of DNS-SD/mDNS, >>>>> eg: in some IoT context ? >>>> >>>> Michael can answer that for himself, but the reason we noted the *po= ssibility* >>>> of doing this in grasp-08 is because it seems clearly harmless. So f= rom the >>>> GRASP spec point of view, I consider the issue closed. >>> >>> Ues, i am mostly interested in use-case explanations Michael has in m= ind. >>> >>> The other piece was that Michael was trying to figure out how to avoi= d using LL multicast >>> and instead use unicast: >>> >>> -> Within the ACP this question is somewhat irrelevant because its se= cured. >>> >>> -> Given how ACP interfaces are p2p secured interfaces to neigbhors, = you >>> could know upfront the LL IPv6 address of the neighbor on the inte= rface, >>> but there is really no framework in IETF protocols that leverages = this >>> optimization for p2p links, so i don't think we should bother doin= g it. >>> Its work without RoI. >>> >>> -> Outside the ACP i am not sure about the use-case. To be options pr= oof: GRASP >>> should permit sending and receiving of LL UNICAST instead of LL mu= lticast for >>> those messages where GRASP specifies LL multicast, so that if some= deployment >>> figures out that there is some optimization possible with the use = of LL unicast,=20 >>> then it can simply do that instead of asking for a GRASP spec modi= fication. >> >> Sure. That was my conclusion (for discovery; it makes no sense for flo= oding). >> >>> The big security risk though is GLOBAL UNICAST MUST NOT BE PERMITT= ED=20 >>> as a replacement for LL multicast. Thats an attack vector. And typ= ical >>> socket software code is usually victim to that. Aka: you open a so= cket, >>> you bind it to a link-local multicast group and you go away. Alas:= this >>> socket will receive not only link-local multicast, but also LL uni= cast (good) >>> and global unicast (bad). So the application code usually would ne= ed to check >>> the destination address the packet was sent to and drop those pack= ets=20 >>> sent to the global unicast address - if the protocol was really on= ly >>> designed for LL multicast - and therefore assuming security proper= ties >>> of LL multicast (logical vicinity of sender). >> >> GRASP discovery and flood are specified as link-local, so yes, that ch= eck >> is needed. >> >>> A good exampe for replacing multicast with unicast is WiFI where l= uckily >>> hosts do accept multicast packets as L2 unicast instead of L2 mult= icast. >>> And thats done to get the benefit of L2 retransmissions, that do n= ot exist >>> for L2 multicast. >> >> Ack. >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue Nov 1 19:53:37 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61C2129971 for ; Tue, 1 Nov 2016 19:53:36 -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 DYlztHftpXhf for ; Tue, 1 Nov 2016 19:53:35 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 06D171294F9 for ; Tue, 1 Nov 2016 19:53:35 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id 189so2383259pfz.3 for ; Tue, 01 Nov 2016 19:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=S6vTE+POqaY9XcHYTt4AZ3oQqb0S9X3SIhXarX8o3PI=; b=NoAdjhoREm/nQ+2TE//BjhcBdGzBY2AEZ2MWCTLfOtI/n4L828YS//A2hudbS/PTH8 pQ1XMZ4fVE83zVpwIeIgtVIZkMBQZZQANZTmAOBxow8Wo5Jxbz8Yyf39i4U3ynJqO+VN /D2HXQPrXUFgjRC5CL/NXd4+cVhLkHt8aV0bQsaIcQ6eI1QvfJGcELjaNS6jkNHYmbGW HtnowB240aA8thJVGyrcpUf5L4TlZB8umzEiEYIaozAN6OoorfZHqbXxeBbM7OLbmE5V c0kNG6XKXrJX1C2xe1OSd4jKF+ahMX5S0JJbpxke669mwp2mLtc062k4A9Mtn3Geogjp DVEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=S6vTE+POqaY9XcHYTt4AZ3oQqb0S9X3SIhXarX8o3PI=; b=mF87GRqmYQn3YfXnqWAMNinFJRsUmca6pEcRkM0B8TTwHkQLZqMLzZRazCUOBlaFNy y7w187iIHpOGVYKdfiyCSMry7T/kxvLJro2PnaLmxty8IXFkKKmixAkDeYPpsh6V8D73 IHnfZpJ+oY2kXcAJxMX7/aUeuqfybXIs1A+mDCSY7PMf7yspaVkjgkmCqCnaVc1zy71d 2kV0j9p4zr5Q8I1j28Cfjg5/tdpQdLxTAPmDO4SMsCw4ZepLEEObKg75lrS6u+W53u4W QSZcTLA+NyDA1dW6WEH1qmbWD7t2pijKqTD8KJxlw5o7LsZl09yq1cEUyDYIK5ooXqgV JbIQ== X-Gm-Message-State: ABUngvf7tF3o7cHMockdIEYS9lajoNbMbfuWuh/dEzcNZlvoszvMSahqs9zWAQQEZLcdTw== X-Received: by 10.99.97.15 with SMTP id v15mr2159540pgb.10.1478055214408; Tue, 01 Nov 2016 19:53:34 -0700 (PDT) Received: from [192.168.178.23] ([118.148.117.117]) by smtp.gmail.com with ESMTPSA id jz5sm45319750pad.10.2016.11.01.19.53.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 19:53:33 -0700 (PDT) References: To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: Message-ID: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> Date: Wed, 2 Nov 2016 15:53:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: Re: [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 02:53:36 -0000 Something over on homenet prompted me to send the following. I do have the same concern for BRSKI - what's the disaster recovery mechanism when all vendor MASAs are unreachable but we must restart the network anyway? Brian -------- Forwarded Message -------- Subject: Re: [homenet] write up of time without clocks Date: Wed, 2 Nov 2016 08:38:04 +1300 From: Brian E Carpenter Organization: University of Auckland To: homenet@ietf.org On 02/11/2016 03:52, Philip Homburg wrote: ... > Which brings me to the following: given that all code has security issues, > maybe devices should check for updates and just shutdown if they can't > verify that they are running the latest firmware? That sounds absolutely dreadful for disaster recovery scenarios where the Internet is badly broken (after a hurricane, earthquake, etc.) and people need to restart essential systems (or they need to restart themselves). > So the device should have the vendor's long term TLS certicate. With possibly > an option for the user to disable this kind of security if the device is > not actually connected to the internet. No, during disaster recovery the last thing you need is for ordinary people to be faced with strange security alerts that they've never seen before. (It's rather like advising people to go into the BIOS to change an option while the fire alarm is ringing.) Things need to just work during disaster recovery. Brian From nobody Wed Nov 2 07:34:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764671294B6 for ; Wed, 2 Nov 2016 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, 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 TUE7zGjustwg for ; Wed, 2 Nov 2016 07:34:41 -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 786001293D8 for ; Wed, 2 Nov 2016 07:34:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C6173203BD for ; Wed, 2 Nov 2016 10:50:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 01425637A6 for ; Wed, 2 Nov 2016 10:34:39 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> References: <20161031221855.GA1970@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] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 14:34:43 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: te> b) I have just posted ACP draft -04 in which i have reversed the ch= oice te> of mDNS for ACP discovery by neighbors from the -03 text which had te> mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more te> details. I have no problem with the use of a GRASP multicast discovery here. I wonder about the utility of the GRASP unicast TCP response to the ACP discovery.=20=20 Why not simply respond to the ACP discovery with a key management initiation to the sender of the multicast?=20=20 My reasoning is as follows: 1) four TCP packets across the insecure ("public") LAN just to say "okay" 2) insecure GRASP instance must open TCP port on insecure LAN, and accept connections from anything. (See discussion about possible CBOR encodi= ng attacks). 3) discovery of ACP peers is meaningless outside of the the local-link. 4) IKEv2 (whether used for IPsec keying, or MACsec keying [%]) already provides all the negotiation we need, and does it with higher privacy and security than GRASP could. Yes, I realize that this is an "exception" case for GRASP, but I also claim that all insecure instances of GRASP will be extremely minimal, purpose bui= lt things. Call it uGRASP if you like. te> Pls check out the text on discover in -04, i hope it justifies u= se te> of GRASP for neighbor discovery. =20=20=20 brian> When GRASP is run securely in its two forms for the ACP, it is brian> always protected/ encrypted by the ACP, so i think your security brian> concern would then not be valid. brian>=20 brian> I'm still waiting to see a clear explanation of how the ACP will brian> secure LL multicast, however. te> I am not sure i understand the documentation ask. The ACP has a bun= ch te> of (virtual) interfaces. In the most simple implementation option, = each te> ACP channel to an ACP neighbor is its own (p2p) L3 interface in the te> ACP. And thats all the interfaces the ACP has. Your quoting style makes it hard for me to understand the flow. I think that I requoted it correctly? There are two LL multicast involved: a) outside of ACP LL multicast on the underlying link. b) inside of the ACP LL multicast, which is really just p2p traffic. Brian, RPL has an associated multicast routing protocol called "MPL". We discussed it before, but it might be worth discussing it again to be sure we went down the right path. We decided that GRASP would do application layer multicasting -- as such, there will be hardly any actual layer-2 multicast, as all the ACP links are p2p. Using multicast destinations here is a convenience to not knowing what the peer's address is, except that once we have the first response via TCP, we do know the peer, and we might as we= ll just use that channel for future communication. > All packets, unicast or multicast that are sent into or received from > those interfaces are protected/encrypted by the fact that they are > transmitted encrypted by the seleted ACP channel encryption protocol. >> Do you see some IoT context where you would use insecure GRASP >> instead of DNS-SD/mDNS, eg: in some IoT context ? >>=20 >> Michael can answer that for himself, but the reason we noted the >> *possibility* of doing this in grasp-08 is because it seems clearly >> harmless. So from the GRASP spec point of view, I consider the issue >> closed. > Ues, i am mostly interested in use-case explanations Michael has in > mind. > The other piece was that Michael was trying to figure out how to avoid > using LL multicast and instead use unicast: I see no places in IoT where we would want to use insecure GRASP on an insecure link. The killer is the TCP reply, which implies a TCP stack, whi= ch most which to avoid.=20=20 > A good exampe for replacing multicast with unicast is WiFI where > luckily hosts do accept multicast packets as L2 unicast instead of L2 > multicast. And thats done to get the benefit of L2 retransmissions, > that do not exist for L2 multicast. but, also because L2 multicast must be sent at the data rate/power-level of the weakest receiver, so L2-multicasts can eat hundreds of unicast TxOps. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWBn5fYCLcPvd0N1lAQLR5wgAmjuG6TBQV3LmyiWKDc5LX5VyAv6ptZkr uFiPC6RAxPGj2EgWYvzqBXgKzEgEiLZ5vzUBrsAUbNbMwL/W1tMAgcRytp4SBfwN yr7EW39ObjjkUA8hwWphb1DxQ2vN9Fclf+W8TaX2ic16KfRHHTuq+yQIkQfLvPF7 EI7QbQyqpKufTKyWyQ6s+2U8Lk5hHxlWS1t4/OjB0ZEoO2e5KK7+cVABWtizZaqH /DRHLOndctlNmrGe9hQkE+gbn01tvbpjLTIJo34XTyALwIL3aNOIwrw7lV1qe3TN X5TICYhaNdtxiQEjs69+wpMYGstG6e2M3hWlKUjnTxcXV/n/KazkBQ== =YieU -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 2 07:37:09 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101301293D8 for ; Wed, 2 Nov 2016 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, 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 6z2ICXEs4rKm for ; Wed, 2 Nov 2016 07:37:05 -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 CD7901295F2 for ; Wed, 2 Nov 2016 07:37:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B28D3203BD; Wed, 2 Nov 2016 10:52:31 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0747D637A6; Wed, 2 Nov 2016 10:37:05 -0400 (EDT) From: Michael Richardson To: Anima WG , Brian E Carpenter In-Reply-To: References: <20161031221855.GA1970@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: Cc: Toerless Eckert Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 14:37:07 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > Currently the GRASP code finds out how many physical interfaces it has > and for each one creates a multicast sending socket. It also has a > socket that listens for incoming link-local multicasts on all physical > interfaces. I don't see how to do that using the ACP interfaces that > you describe. if (if_name ~=3D /^acp.*/): secure =3D true >> All packets, unicast or multicast that are sent into or received from >> those interfaces are protected/encrypted by the fact that they are >> transmitted encrypted by the seleted ACP channel encryption protocol. > Yes, and I'd like the LL multicast traffic to be protected too. But = as > far as I can see that needs explicit support in the ACP to emulate LL > multicast sockets. The ideal would be that the ACP simply emulates LL > interfaces, so that GRASP could treat them exactly like physical > interfaces. This is a nil operation. I think the problem is that you don't have any ACP code at this point. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWBn6DYCLcPvd0N1lAQK+jQf/ZN1eoGEiLv5YEfas3ZQ1PEw/QJs0+4nO AMzEQLK8pWwsJW08AsQMVO+Uv4VScgjKzYIvf8TO3RYhe/0SCknDU+NbvVIhFWB5 uuW+EmqCyfLXj3dQ++W+DtJHlJJhUQEZti+jt+z1pxQo97y45jCFXCpUpPQrJNlV yXYgxpF1YIxxhAW//RWZvmZaJtcaFiaZ9Jkd30P84X/ZN92dLBdy2XmE8sv54YVF yrdiNyXbx9ai0mhf3VWB8J1M49NvO+2IBTE3fmXt2rVh0XiRoyZmPSeRpB+xs+Xg B30GL/GI8/bjKKO6+fCn0Cypd1dKQIefXHM/B8qb6nrWfQ1WKDqN8w== =vbsm -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 2 09:05:49 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF30129546 for ; Wed, 2 Nov 2016 09:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 fuPnQkTC4_bk for ; Wed, 2 Nov 2016 09:05:46 -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 E6913129462 for ; Wed, 2 Nov 2016 09:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3744; q=dns/txt; s=iport; t=1478102745; x=1479312345; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2hIAFWwehdlKnzF/JdA/8zs95cDKjyE+EY5pl2lZGFc=; b=lWzbizRl1uDuAdNrt9yDs14ZZtbJ+0cGvn+HV8SUkw9obhwE31sEZioO DVhO11g/oNZfBmrfvdtc0E8kfkaPVowD6uKVG91wD1rRQeNjFj6y8bDcJ pGssr0MvaUKJNgNLpzR29BkLH4uP+81+SsdcpVmU2MUBJrmRPDGLe6g4G o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAgCYDRpY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywBAQEBAR9YfAekMYdhjGaCBx0LhXoCGoIJQBMBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBAwEBAQEgEToLBQsCAQgRAwECAQICJgICAh8GCxUICAIEDgWIPAMPC?= =?us-ascii?q?A6tEokFDYNzAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBB4czgliCR4IXgm0tgi8?= =?us-ascii?q?FkQuIXTUBjQaDM5AJiHmEH4QDASABM2eFF3IBh0+BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,583,1473120000"; d="scan'208";a="164462251" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2016 16:05:45 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uA2G5j58003049 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Nov 2016 16:05:45 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Nov 2016 11:05:44 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 2 Nov 2016 11:05:44 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] [homenet] write up of time without clocks Thread-Index: AQHSNSL3RnA5nQxSJ0mXFRclXoeIvw== Date: Wed, 2 Nov 2016 16:05:44 +0000 Message-ID: <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> In-Reply-To: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@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.11] Content-Type: text/plain; charset="utf-8" Content-ID: <65C5D2F91DBE8F419429D04E94D13FB1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 16:05:48 -0000 TXkgcG9zaXRpb24gaXMgdGhhdCBkdXJpbmcgYSBsYXJnZSBzY2FsZSBkaXNhc3RlciBpdCB3b3Vs ZCBiZSBmb29saXNoIG9mIHVzIHRvIHRoaW5rIHRoYXQgc2VjdXJpdHkgaXMgc29tZWhvdyBsZXNz IGltcG9ydGFudC4gDQoNCkJSU0tJIHN1cHBvcnRzIG5vbmNlbGVzcyB0b2tlbnMgdGhhdCBjYW4g YmUgZGlzdHJpYnV0ZWQgaW4gYWR2YW5jZS4gVGhlc2UgaW5jbHVkZSB0aGUgc2VyaWFsIG51bWJl ciBvZiB0aGUgZGV2aWNlIGFuZCB0aGUgZG9tYWluIENBIGNlcnQgc28gaXQgSVMgTk9UIGEgIm1h c3RlciBrZXkiLg0KCUEg4oCcbWFzdGVyIGtleeKAnSBpcyB0b28gc2ltaWxhciB0byBhIOKAnGJh Y2sgZG9vcuKAnSBmb3IgbWUgdG8gc3VwcG9ydCBpdC4gDQoNCkJSU0tJIGNsaWVudCBtYXkgc3Vw cG9ydCBwaHlzaWNhbCBwcmVzZW5jZSAoYnV0dG9ucyBldGMpIHRoYXQgcHV0IHRoZW0gaW4g4oCY dHJ1c3Qgb24gZmlyc3QgdXNl4oCZIG1vZGUuIA0KDQpCUlNLSSBhZGRyZXNzZXMg4oCYdGltZSB3 aXRob3V0IGNsb2Nrc+KAmSB0aHJvdWdoIHRoZSB1c2Ugb2Ygbm9uY2VzIGFuZCBzZWN0aW9uIDMu MS41Lg0KDQpJIGNvdWxkIGJlIHBlcnN1YWRlZCB0b3dhcmQgYSBtb3JlIGdlbmVyaWMgdG9mdSBt b2RlbCBvbmx5IGlmIGRldmljZXMgaW5jbHVkZSBhbiBpbnRlZ3JhdGVkIGhhcmR3YXJlIGFzc2lz dGVkIGVuZHBvaW50IGFzc2Vzc21lbnQgKHRoaW5rIFRQTSBzdHlsZSBhdHRlc3RhdGlvbiB3LyBy dW50aW1lIG1lYXN1cmVtZW50cykuIFRoYXQgdGVjaG5vbG9neSBpc27igJl0IHJlYWxseSBhdmFp bGFibGUgeWV0Lg0KDQpUaGUgYXBwcm9hY2hlcyBwcm92aWRlZCBoZXJlIHdvcmsgd2l0aCBzb21l IHByaW9yIHBsYW5uaW5nIGJ1dCBhcmUgbm90IG1hZ2ljYWwuIA0KDQpEbyB5b3UgaGF2ZSBwaXhp ZSBkdXN0IHRvIHN1Z2dlc3Q/IA0KDQotIG1heA0KDQo+IE9uIE5vdiAxLCAyMDE2LCBhdCA4OjUz IFBNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90 ZToNCj4gDQo+IFNvbWV0aGluZyBvdmVyIG9uIGhvbWVuZXQgcHJvbXB0ZWQgbWUgdG8gc2VuZCB0 aGUgZm9sbG93aW5nLiBJIGRvIGhhdmUgdGhlDQo+IHNhbWUgY29uY2VybiBmb3IgQlJTS0kgLSB3 aGF0J3MgdGhlIGRpc2FzdGVyIHJlY292ZXJ5IG1lY2hhbmlzbSB3aGVuIGFsbA0KPiB2ZW5kb3Ig TUFTQXMgYXJlIHVucmVhY2hhYmxlIGJ1dCB3ZSBtdXN0IHJlc3RhcnQgdGhlIG5ldHdvcmsgYW55 d2F5Pw0KPiANCj4gICBCcmlhbg0KPiANCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0t LS0tLS0NCj4gU3ViamVjdDogUmU6IFtob21lbmV0XSB3cml0ZSB1cCBvZiB0aW1lIHdpdGhvdXQg Y2xvY2tzDQo+IERhdGU6IFdlZCwgMiBOb3YgMjAxNiAwODozODowNCArMTMwMA0KPiBGcm9tOiBC cmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KPiBPcmdhbml6 YXRpb246IFVuaXZlcnNpdHkgb2YgQXVja2xhbmQNCj4gVG86IGhvbWVuZXRAaWV0Zi5vcmcNCj4g DQo+IE9uIDAyLzExLzIwMTYgMDM6NTIsIFBoaWxpcCBIb21idXJnIHdyb3RlOg0KPiAuLi4NCj4+ IFdoaWNoIGJyaW5ncyBtZSB0byB0aGUgZm9sbG93aW5nOiBnaXZlbiB0aGF0IGFsbCBjb2RlIGhh cyBzZWN1cml0eSBpc3N1ZXMsDQo+PiBtYXliZSBkZXZpY2VzIHNob3VsZCBjaGVjayBmb3IgdXBk YXRlcyBhbmQganVzdCBzaHV0ZG93biBpZiB0aGV5IGNhbid0DQo+PiB2ZXJpZnkgdGhhdCB0aGV5 IGFyZSBydW5uaW5nIHRoZSBsYXRlc3QgZmlybXdhcmU/DQo+IA0KPiBUaGF0IHNvdW5kcyBhYnNv bHV0ZWx5IGRyZWFkZnVsIGZvciBkaXNhc3RlciByZWNvdmVyeSBzY2VuYXJpb3Mgd2hlcmUNCj4g dGhlIEludGVybmV0IGlzIGJhZGx5IGJyb2tlbiAoYWZ0ZXIgYSBodXJyaWNhbmUsIGVhcnRocXVh a2UsIGV0Yy4pDQo+IGFuZCBwZW9wbGUgbmVlZCB0byByZXN0YXJ0IGVzc2VudGlhbCBzeXN0ZW1z IChvciB0aGV5IG5lZWQgdG8gcmVzdGFydA0KPiB0aGVtc2VsdmVzKS4NCj4gDQo+PiBTbyB0aGUg ZGV2aWNlIHNob3VsZCBoYXZlIHRoZSB2ZW5kb3IncyBsb25nIHRlcm0gVExTIGNlcnRpY2F0ZS4g V2l0aCBwb3NzaWJseQ0KPj4gYW4gb3B0aW9uIGZvciB0aGUgdXNlciB0byBkaXNhYmxlIHRoaXMg a2luZCBvZiBzZWN1cml0eSBpZiB0aGUgZGV2aWNlIGlzDQo+PiBub3QgYWN0dWFsbHkgY29ubmVj dGVkIHRvIHRoZSBpbnRlcm5ldC4NCj4gDQo+IE5vLCBkdXJpbmcgZGlzYXN0ZXIgcmVjb3Zlcnkg dGhlIGxhc3QgdGhpbmcgeW91IG5lZWQgaXMgZm9yIG9yZGluYXJ5IHBlb3BsZQ0KPiB0byBiZSBm YWNlZCB3aXRoIHN0cmFuZ2Ugc2VjdXJpdHkgYWxlcnRzIHRoYXQgdGhleSd2ZSBuZXZlciBzZWVu IGJlZm9yZS4NCj4gKEl0J3MgcmF0aGVyIGxpa2UgYWR2aXNpbmcgcGVvcGxlIHRvIGdvIGludG8g dGhlIEJJT1MgdG8gY2hhbmdlIGFuIG9wdGlvbg0KPiB3aGlsZSB0aGUgZmlyZSBhbGFybSBpcyBy aW5naW5nLikNCj4gDQo+IFRoaW5ncyBuZWVkIHRvIGp1c3Qgd29yayBkdXJpbmcgZGlzYXN0ZXIg cmVjb3ZlcnkuDQo+IA0KPiAgICBCcmlhbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+IEFuaW1hQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0K From nobody Wed Nov 2 09:15:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEBF1296C7 for ; Wed, 2 Nov 2016 09:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik_XOETxlZ02 for ; Wed, 2 Nov 2016 09:15:20 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCBE1296BD for ; Wed, 2 Nov 2016 09:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10859; q=dns/txt; s=iport; t=1478103319; x=1479312919; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=uGBJrF53YGo5xogdcBukqimywbhVAop5U/ocDRj4ASo=; b=FjiYLogBNrcXlFiiVSOTCVZZi6Izkz2Uw7MTBvhTb3td0Bms7f29Vc+3 K34irtQqac0iOyoLYpxVMQm6/Nii+yjR5G1r5Q6TZbCLXkRbO0vckI8tj qVnUWI4NOC99ytWgTy3taIY6zkrt2h8F9gh4borgzZ+xIQoaJU8XVlfGH I=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.31,583,1473120000"; d="asc'?scan'208,217";a="647818188" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2016 16:15:18 +0000 Received: from [10.61.88.89] (ams3-vpn-dhcp6234.cisco.com [10.61.88.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uA2GFH7j019061; Wed, 2 Nov 2016 16:15:18 GMT To: "Max Pritikin (pritikin)" , Brian E Carpenter References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> From: Eliot Lear Message-ID: <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> Date: Wed, 2 Nov 2016 17:15:17 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8U8OBQv9PC2rjnsOeuiu3NCcS2KHnV3Mn" Archived-At: Cc: Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 16:15:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8U8OBQv9PC2rjnsOeuiu3NCcS2KHnV3Mn Content-Type: multipart/mixed; boundary="WCRToNPr6TVJ3HNfKPCb8oO9KWQjdGKbi"; protected-headers="v1" From: Eliot Lear To: "Max Pritikin (pritikin)" , Brian E Carpenter Cc: Anima WG Message-ID: <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> Subject: Re: [Anima] [homenet] write up of time without clocks References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> In-Reply-To: <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> --WCRToNPr6TVJ3HNfKPCb8oO9KWQjdGKbi Content-Type: multipart/alternative; boundary="------------4F55DC7CC3D1C1C143882C45" This is a multi-part message in MIME format. --------------4F55DC7CC3D1C1C143882C45 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I myself would be concerned over a downgrade attack.=20 Recall that this only impacts BRSKI in as much as the device needs to be provisioned *during* the disaster. While there may yet be some classes of devices that require this, I'm going to hazard (cough) a guess that most first responders will have trained with the equipment they have *prior* to the disaster. For the remaining equipment, if it is part of critical infrastructure and requires a network, then the network needs to be up. The only question then is whether the MASA server needs to be up. It is perfectly possible to design a system where that is the case. Eliot On 11/2/16 5:05 PM, Max Pritikin (pritikin) wrote: > My position is that during a large scale disaster it would be foolish o= f us to think that security is somehow less important.=20 > > BRSKI supports nonceless tokens that can be distributed in advance. The= se include the serial number of the device and the domain CA cert so it I= S NOT a "master key". > A =E2=80=9Cmaster key=E2=80=9D is too similar to a =E2=80=9Cback door=E2= =80=9D for me to support it.=20 > > BRSKI client may support physical presence (buttons etc) that put them = in =E2=80=98trust on first use=E2=80=99 mode.=20 > > BRSKI addresses =E2=80=98time without clocks=E2=80=99 through the use o= f nonces and section 3.1.5. > > I could be persuaded toward a more generic tofu model only if devices i= nclude an integrated hardware assisted endpoint assessment (think TPM sty= le attestation w/ runtime measurements). That technology isn=E2=80=99t re= ally available yet. > > The approaches provided here work with some prior planning but are not = magical.=20 > > Do you have pixie dust to suggest?=20 > > - max > >> On Nov 1, 2016, at 8:53 PM, Brian E Carpenter wrote: >> >> Something over on homenet prompted me to send the following. I do have= the >> same concern for BRSKI - what's the disaster recovery mechanism when a= ll >> vendor MASAs are unreachable but we must restart the network anyway? >> >> Brian >> >> -------- Forwarded Message -------- >> Subject: Re: [homenet] write up of time without clocks >> Date: Wed, 2 Nov 2016 08:38:04 +1300 >> From: Brian E Carpenter >> Organization: University of Auckland >> To: homenet@ietf.org >> >> On 02/11/2016 03:52, Philip Homburg wrote: >> ... >>> Which brings me to the following: given that all code has security is= sues, >>> maybe devices should check for updates and just shutdown if they can'= t >>> verify that they are running the latest firmware? >> That sounds absolutely dreadful for disaster recovery scenarios where >> the Internet is badly broken (after a hurricane, earthquake, etc.) >> and people need to restart essential systems (or they need to restart >> themselves). >> >>> So the device should have the vendor's long term TLS certicate. With = possibly >>> an option for the user to disable this kind of security if the device= is >>> not actually connected to the internet. >> No, during disaster recovery the last thing you need is for ordinary p= eople >> to be faced with strange security alerts that they've never seen befor= e. >> (It's rather like advising people to go into the BIOS to change an opt= ion >> while the fire alarm is ringing.) >> >> Things need to just work during disaster recovery. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------4F55DC7CC3D1C1C143882C45 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I myself would be concerned over a downgrade attack.=C2=A0

Recall that this only impacts BRSKI in as much as the device needs to be provisioned during the disaster.=C2=A0 While the= re may yet be some classes of devices that require this, I'm going to hazard (cough) a guess that most first responders will have trained with the equipment they have prior to the disaster.=C2=A0 For the remaining equipment, if it is part of criti= cal infrastructure and requires a network, then the network needs to be up.=C2=A0 The only question then is whether the MASA server need= s to be up.=C2=A0 It is perfectly possible to design a system where that= is the case.

Eliot


On 11/2/16 5:05 PM, Max Pritikin (pritikin) wrote:
My position is that during a large scale disaster it=
 would be foolish of us to think that security is somehow less important.=
=20

BRSKI supports nonceless tokens that can be distributed in advance. These=
 include the serial number of the device and the domain CA cert so it IS =
NOT a "master key".
	A =E2=80=9Cmaster key=E2=80=9D is too similar to a =E2=80=9Cback door=E2=
=80=9D for me to support it.=20

BRSKI client may support physical presence (buttons etc) that put them in=
 =E2=80=98trust on first use=E2=80=99 mode.=20

BRSKI addresses =E2=80=98time without clocks=E2=80=99 through the use of =
nonces and section 3.1.5.

I could be persuaded toward a more generic tofu model only if devices inc=
lude an integrated hardware assisted endpoint assessment (think TPM style=
 attestation w/ runtime measurements). That technology isn=E2=80=99t real=
ly available yet.

The approaches provided here work with some prior planning but are not ma=
gical.=20

Do you have pixie dust to suggest?=20

- max


On Nov 1, 2016, at 8:53 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Something over on homenet prompted me to send the following. I do have th=
e
same concern for BRSKI - what's the disaster recovery mechanism when all
vendor MASAs are unreachable but we must restart the network anyway?

  Brian

-------- Forwarded Message --------
Subject: Re: [homenet] write up of time without clocks
Date: Wed, 2 Nov 2016 08:38:04 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
To: homenet@ietf.org

On 02/11/2016 03:52, Philip Homburg wrote:
=2E..

Which brings me to the following: given that all=
 code has security issues,
maybe devices should check for updates and just shutdown if they can't
verify that they are running the latest firmware?

That sounds absolutely dreadful for disaster recovery scenarios where
the Internet is badly broken (after a hurricane, earthquake, etc.)
and people need to restart essential systems (or they need to restart
themselves).


So the device should have the vendor's long term=
 TLS certicate. With possibly
an option for the user to disable this kind of security if the device is
not actually connected to the internet.

No, during disaster recovery the last thing you need is for ordinary peop=
le
to be faced with strange security alerts that they've never seen before.
(It's rather like advising people to go into the BIOS to change an option=

while the fire alarm is ringing.)

Things need to just work during disaster recovery.

   Brian

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

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

--------------4F55DC7CC3D1C1C143882C45-- --WCRToNPr6TVJ3HNfKPCb8oO9KWQjdGKbi-- --8U8OBQv9PC2rjnsOeuiu3NCcS2KHnV3Mn 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 iQEcBAEBCAAGBQJYGhEVAAoJEIe2a0bZ0nozP/0IAM8Iy7myyGeslXaebDwOjc4W pLFxAUBbDaKQ9qtECSQb6saIVINxw/tTxluzIzZWqfmz9zxQQ/LtNpHw/dDqrsrm bVbQI4a9eXNiSRf4The4sTZ3Fx51Nidnwz4i9daRAwVq6AYxNHboTOEH6m8KUeS/ KIbfo/Z+HUFEPnqmrFrfbqzM1TQ9LvNn1737GeCKFAk0NyF5e4iq/AvtDH47emBc 058Sjdd9QO8Z9/BBR9/ksd0aKJy87j/Lx8N1kpaQZhS2GoH8Q5uQCG60YAX9zRc1 QYvJquYc5vb18JDv2erqGZLemTvYhmPkDNu/42zBWxaH9P7IyZVTZOo0wLW+uEw= =r8gz -----END PGP SIGNATURE----- --8U8OBQv9PC2rjnsOeuiu3NCcS2KHnV3Mn-- From nobody Wed Nov 2 12:09:48 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDC612988C for ; Wed, 2 Nov 2016 12:09:47 -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 Kc5oie5zvX8L for ; Wed, 2 Nov 2016 12:09:45 -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 0DA84129413 for ; Wed, 2 Nov 2016 12:09:45 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id d2so16671771pfd.0 for ; Wed, 02 Nov 2016 12:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1kW+wnLSJElDH3Dt6+5t/okL3Tm6fvVX38WjHOpw43s=; b=pzKua+AIg3pNBnFl4OpfllZvRry1RXZvBHgiFMi8iu0dh1hs6+fhc3meNi8UjYvzDl tqTk9a8CJZt5kiaFJg7fE6lxQ18kw+XO3ZEMkeLH/soIQiVgGDYe4eCWOFYRIJMJL4FW dNk7sfo6AjrOwtCVXFEa+eyD6+At8shEiSTS8biWJ1QOMcvoe2ubDINWuTu9L4ar1jGv awbDFRaISzrrToXU/pAF/UMXZygjlw4gOEov8VDMMiK67dtUUm8PaNKyTtyt1YM5b3i5 pfvAxdMGyxhWANYnO/s/IGxbcOXVYjMMlrktzviWyJyg/ujIzUa8hB/6uWlvGRBz1amd gOTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1kW+wnLSJElDH3Dt6+5t/okL3Tm6fvVX38WjHOpw43s=; b=dWxFTCMSjCwen+eLDo5A8xHi5OZ7+ec6eWsLZBcjFT/yJjyYanaGC2lvGx/odAnW41 nyW7VsSSL8kPrFhq/gF/EcpLqMfA5UXejax6QXHLvVn9EDscrhKY2WogaFQV8lyNDSsC eD17qbKUWthX37LEweAlANSgGiJOnIAnrU7KNWvZzpAA6QBtCn/IjP9sjR7+TBFkNG7u mM8b8+BZfwKyQkmxF3w1b0alxEOJqOmiDYqcfxX3r3M2XiIhy6o9kx9O2LkUd65fyiJ4 UELTnthGsydQVfW7D/fl9yG4TWkI5EBQUY+i5XChHeZALYQFY7cXpWzCydb09bMfp/NA 5z6A== X-Gm-Message-State: ABUngvcyeErtU2RA5JNv6vDds5wWv3wkRvud8mW7MfX3Esumns4t89WnK+8p98xemwehvQ== X-Received: by 10.99.51.204 with SMTP id z195mr8026204pgz.41.1478113784528; Wed, 02 Nov 2016 12:09:44 -0700 (PDT) Received: from [192.168.178.23] ([118.148.78.158]) by smtp.gmail.com with ESMTPSA id 131sm6517402pfx.92.2016.11.02.12.09.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 12:09:43 -0700 (PDT) To: Eliot Lear , "Max Pritikin (pritikin)" References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> Date: Thu, 3 Nov 2016 08:09:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 19:09:47 -0000 Firstly, no, I have no pixie dust, and I agree that we need to preserve security even after a disaster. But on the other hand, if autonomic networks matter at all, they will matter then, and we can't safely assume= that network operators are available even to switch on some sort of emerg= ency MASA server. Also, how would a temporary tactical network used by emergen= cy responders configure itself if no vendor MASA server is accessible? I'm not suggesting that the basic BRSKI mechanisms need to solve this, but I think we need to have it on the list of issues to be tackled before= we can consider Anima complete. Brian On 03/11/2016 05:15, Eliot Lear wrote: > I myself would be concerned over a downgrade attack.=20 >=20 > Recall that this only impacts BRSKI in as much as the device needs to b= e > provisioned *during* the disaster. While there may yet be some classes= > of devices that require this, I'm going to hazard (cough) a guess that > most first responders will have trained with the equipment they have > *prior* to the disaster. For the remaining equipment, if it is part of= > critical infrastructure and requires a network, then the network needs > to be up. The only question then is whether the MASA server needs to b= e > up. It is perfectly possible to design a system where that is the case= =2E >=20 > Eliot >=20 >=20 > On 11/2/16 5:05 PM, Max Pritikin (pritikin) wrote: >> My position is that during a large scale disaster it would be foolish = of us to think that security is somehow less important.=20 >> >> BRSKI supports nonceless tokens that can be distributed in advance. Th= ese include the serial number of the device and the domain CA cert so it = IS NOT a "master key". >> A =E2=80=9Cmaster key=E2=80=9D is too similar to a =E2=80=9Cback door= =E2=80=9D for me to support it.=20 >> >> BRSKI client may support physical presence (buttons etc) that put them= in =E2=80=98trust on first use=E2=80=99 mode.=20 >> >> BRSKI addresses =E2=80=98time without clocks=E2=80=99 through the use = of nonces and section 3.1.5. >> >> I could be persuaded toward a more generic tofu model only if devices = include an integrated hardware assisted endpoint assessment (think TPM st= yle attestation w/ runtime measurements). That technology isn=E2=80=99t r= eally available yet. >> >> The approaches provided here work with some prior planning but are not= magical.=20 >> >> Do you have pixie dust to suggest?=20 >> >> - max >> >>> On Nov 1, 2016, at 8:53 PM, Brian E Carpenter wrote: >>> >>> Something over on homenet prompted me to send the following. I do hav= e the >>> same concern for BRSKI - what's the disaster recovery mechanism when = all >>> vendor MASAs are unreachable but we must restart the network anyway? >>> >>> Brian >>> >>> -------- Forwarded Message -------- >>> Subject: Re: [homenet] write up of time without clocks >>> Date: Wed, 2 Nov 2016 08:38:04 +1300 >>> From: Brian E Carpenter >>> Organization: University of Auckland >>> To: homenet@ietf.org >>> >>> On 02/11/2016 03:52, Philip Homburg wrote: >>> ... >>>> Which brings me to the following: given that all code has security i= ssues, >>>> maybe devices should check for updates and just shutdown if they can= 't >>>> verify that they are running the latest firmware? >>> That sounds absolutely dreadful for disaster recovery scenarios where= >>> the Internet is badly broken (after a hurricane, earthquake, etc.) >>> and people need to restart essential systems (or they need to restart= >>> themselves). >>> >>>> So the device should have the vendor's long term TLS certicate. With= possibly >>>> an option for the user to disable this kind of security if the devic= e is >>>> not actually connected to the internet. >>> No, during disaster recovery the last thing you need is for ordinary = people >>> to be faced with strange security alerts that they've never seen befo= re. >>> (It's rather like advising people to go into the BIOS to change an op= tion >>> while the fire alarm is ringing.) >>> >>> Things need to just work during disaster recovery. >>> >>> Brian >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 From nobody Wed Nov 2 12:31:11 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEA7129841 for ; Wed, 2 Nov 2016 12:31:09 -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 4LnpAarwgTqg for ; Wed, 2 Nov 2016 12:31:08 -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 037111297CD for ; Wed, 2 Nov 2016 12:31:08 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id d2so16925953pfd.0 for ; Wed, 02 Nov 2016 12:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=m6zGiTS/oqaJESCzg7RygNaWFEcYWWIcGOkQf+smo2Q=; b=jicb0hgHMq21ukBXiKAkx4vzuwK+Co59kJ6BM1YqGzKU1QpcUkJyo242cw7rJ+X3XA 4klw9fpIF+6NQ/OfiYvxkecCZdT7JGYVkOJoF09sghFExDN0HcVeMmjUQnijhU1/XETj NwWdnRL9uJMVmXNt3HvdEEzsJfUzTp6VdnrGFTYd9zGdfdA+u+BWt7eTn75ObswevOH3 KGsUt1/YEu2RK4p1MTC1K3iG4RiWKmseWeU78MgGW6esuNZO1iEIrHKhuLlaCRuXpaqg uRkKmaTor2VpWT88/p4VAN6K5XiVYIXU0MupV1C8B4C4VxwdJ1qy3KBpmDavHMyEXuZB 6PWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=m6zGiTS/oqaJESCzg7RygNaWFEcYWWIcGOkQf+smo2Q=; b=Z6LfYqpibmOs1H93YpKJBFNdufIDfy/l164Q0oQiEPYLgWfshf/sUdH0mgO5XHolAd ck2+9Qkwl7kiAMvYG8bDthX0QZfh0la3yd+WBCqkYxdZnzByUf3xwspe586j44ykqK8c ToA+34iIUGxiaqQ+6AyzxQ5RhPbcAWmJBWqnjug+fXg+cg4goEoBPa5rQirBh66J0wLj KdxmirKG/tkIArRBHPxfsxdOpy0EdL5z/cQwRPrTlBRiBUmXnsC4EItS8PxovozPQia8 G+cnX5YtgiwlJc1GVuFdSnu+LeC8km9scbVCeXDr+UgFt1B+QEPaTLn12Ntojqh8Fv18 zZHQ== X-Gm-Message-State: ABUngvfnzOsDDAqt9mDjNx1b8PBTuDd8xaFzD4AH5VoqYrC8zzQJyemTXreSHa9FppTTLg== X-Received: by 10.99.135.200 with SMTP id i191mr8212767pge.18.1478115067536; Wed, 02 Nov 2016 12:31:07 -0700 (PDT) Received: from [192.168.178.23] ([118.148.78.158]) by smtp.gmail.com with ESMTPSA id r194sm6569571pfr.94.2016.11.02.12.31.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 12:31:06 -0700 (PDT) To: Michael Richardson , Anima WG References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18642.1478097425@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 3 Nov 2016 08:31:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <18642.1478097425@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 19:31:09 -0000 On 03/11/2016 03:37, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Currently the GRASP code finds out how many physical interfaces it has > > and for each one creates a multicast sending socket. It also has a > > socket that listens for incoming link-local multicasts on all physical > > interfaces. I don't see how to do that using the ACP interfaces that > > you describe. > > if (if_name ~= /^acp.*/): > secure = true Strangely enough my Python code currently says _tls_required = not(acp.status()) (That would lead to a dead end in the code, since I haven't actually implemented TLS wrapping, but we seem to be thinking the same way.) > > >> All packets, unicast or multicast that are sent into or received from > >> those interfaces are protected/encrypted by the fact that they are > >> transmitted encrypted by the seleted ACP channel encryption protocol. > > > Yes, and I'd like the LL multicast traffic to be protected too. But as > > far as I can see that needs explicit support in the ACP to emulate LL > > multicast sockets. The ideal would be that the ACP simply emulates LL > > interfaces, so that GRASP could treat them exactly like physical > > interfaces. > > This is a nil operation. I don't understand that statement. I do understand that the adjacency table contains enough information to make it possible for the ACP to do the right thing, but I don't see anywhere in the ACP spec that says that it will do the right thing. > I think the problem is that you don't have any ACP code at this point. True, and I don't have a clear definition of what that code will do. If it will actually support LL multicast send and receive sockets exactly like physical LL interfaces do, I will be happy. But there's no indication of that in the ACP spec. Brian From nobody Wed Nov 2 12:51:57 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211C8129873 for ; Wed, 2 Nov 2016 12:51: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 2E-Mx9-X52_n for ; Wed, 2 Nov 2016 12:51:54 -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 5208412986D for ; Wed, 2 Nov 2016 12:51:54 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id i88so17029910pfk.2 for ; Wed, 02 Nov 2016 12:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XAMS1S/hgN/QwyZTaiICNv/L+s1az5ijHKPt5j8K8so=; b=S2l/MbkAdnCx5A0kNxB8zgI40OwBON1C/LQ1ua36mX2va5eQ/IuTETrXAfcvhiMPib QYrZCs8y7weBUfuS1+W4pmIiPcLup3hn7gCUYBKL04tY7P6sBkbAYQLMHaXlS4jn7ZZY 6niO2JukxoURwFtiYZUFfeoTP2hqC5YPRfIcdiX8gPF29MuTS86Xi1JH0EnOAnMNMt98 3HMBfRuneJhQW59cAfJeqroPHsfBKfoZ9njxrs7ecSpRaKN2JOCnZ+Mxcx69vAsylSw/ uUGuKVzEKDljhXvZeE2ZR2w7QeIvkL2pz4Wvq6oR+47v7Fw1X/Atmmy5+mHh233I30r5 +qVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XAMS1S/hgN/QwyZTaiICNv/L+s1az5ijHKPt5j8K8so=; b=LIPKOYWKEnFf01496WH5qbAxDhqIlWYXdKKSWs92eSbWO8rur3E/EmVIZfjXVT9K7n NL/dl0nLKxgerV+u4rAQBTUS739XgVuS3CJAWmarGZnfdTkIQm+W6BxmX456h4GjFX1P 3h+tNosL/HytQZNtxhopNsQiThNGpM5V+hsqpto1onFce3VYqgle8soj5maeOVB2B5hi CLV/ojgMFIpPA6b1v6+HhAzrkA8tbQpASv6KM9L3yYqs557LXStmQSB8O7jnJ+HIRAC8 PrT54wpz0QqAWvCKT02UPRqyJkY1qnyye0lut5yDkEul1BPh/o7k15ftumO5lB975htQ wPaA== X-Gm-Message-State: ABUngvdthacui3VsogY2hCWqiVJyv9+dBm4GspJ2vLwimGhBuVCrwlglRg2AE/D+a+qVuA== X-Received: by 10.98.194.68 with SMTP id l65mr9956221pfg.159.1478116313580; Wed, 02 Nov 2016 12:51:53 -0700 (PDT) Received: from [192.168.178.23] ([118.148.78.158]) by smtp.gmail.com with ESMTPSA id g78sm6710577pfe.19.2016.11.02.12.51.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 12:51:52 -0700 (PDT) To: Michael Richardson , Anima WG References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18011.1478097279@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 3 Nov 2016 08:51:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <18011.1478097279@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 19:51:56 -0000 In line... On 03/11/2016 03:34, Michael Richardson wrote: > > Toerless Eckert wrote: > te> b) I have just posted ACP draft -04 in which i have reversed the choice > te> of mDNS for ACP discovery by neighbors from the -03 text which had > te> mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more > te> details. > > I have no problem with the use of a GRASP multicast discovery here. > > I wonder about the utility of the GRASP unicast TCP response to the ACP > discovery. > > Why not simply respond to the ACP discovery with a key management initiation > to the sender of the multicast? > > My reasoning is as follows: > 1) four TCP packets across the insecure ("public") LAN just to say "okay" > 2) insecure GRASP instance must open TCP port on insecure LAN, and accept > connections from anything. (See discussion about possible CBOR encoding > attacks). > 3) discovery of ACP peers is meaningless outside of the the local-link. > 4) IKEv2 (whether used for IPsec keying, or MACsec keying [%]) already > provides all the negotiation we need, and does it with higher privacy > and security than GRASP could. > > Yes, I realize that this is an "exception" case for GRASP, but I also claim > that all insecure instances of GRASP will be extremely minimal, purpose built > things. Call it uGRASP if you like. I was trying to think of a reason why this wouldn't work, and can't really find one. It could be sent as a GRASP discovery with a very short timeout, so from the GRASP point of view it would fail promptly, but the IKE message would arrive as if by magic. Alternatively we could turn it round and use a GRASP flood (also LL multicast), which never gets a TCP reply anyway. > > te> Pls check out the text on discover in -04, i hope it justifies use > te> of GRASP for neighbor discovery. > This was te> not brian>: > brian> When GRASP is run securely in its two forms for the ACP, it is > brian> always protected/ encrypted by the ACP, so i think your security > brian> concern would then not be valid. This was brian>: > brian> I'm still waiting to see a clear explanation of how the ACP will > brian> secure LL multicast, however. > > te> I am not sure i understand the documentation ask. The ACP has a bunch > te> of (virtual) interfaces. In the most simple implementation option, each > te> ACP channel to an ACP neighbor is its own (p2p) L3 interface in the > te> ACP. And thats all the interfaces the ACP has. > > Your quoting style makes it hard for me to understand the flow. > I think that I requoted it correctly? > > There are two LL multicast involved: > a) outside of ACP LL multicast on the underlying link. > b) inside of the ACP LL multicast, which is really just p2p traffic. Well, yes, all ACP is p2p traffic at the physical layer, but > Brian, RPL has an associated multicast routing protocol called "MPL". > We discussed it before, but it might be worth discussing it again to be sure > we went down the right path. We decided that GRASP would do application > layer multicasting -- as such, there will be hardly any actual layer-2 > multicast, as all the ACP links are p2p. Using multicast destinations here > is a convenience to not knowing what the peer's address is, except that once > we have the first response via TCP, we do know the peer, and we might as well > just use that channel for future communication. Can MPL support LL scope? Using LL multicast is more than convenience. If GRASP sends an LL multicast, it must be sent from a designated physical interface and must not travel more than one hop. Otherwise it defeats the point. The fact that it's being encapsulated and secured and replicated is kind of irrelevant to GRASP. > > All packets, unicast or multicast that are sent into or received from > > those interfaces are protected/encrypted by the fact that they are > > transmitted encrypted by the seleted ACP channel encryption protocol. > > >> Do you see some IoT context where you would use insecure GRASP > >> instead of DNS-SD/mDNS, eg: in some IoT context ? > >> > >> Michael can answer that for himself, but the reason we noted the > >> *possibility* of doing this in grasp-08 is because it seems clearly > >> harmless. So from the GRASP spec point of view, I consider the issue > >> closed. > > > Ues, i am mostly interested in use-case explanations Michael has in > > mind. > > > The other piece was that Michael was trying to figure out how to avoid > > using LL multicast and instead use unicast: > > I see no places in IoT where we would want to use insecure GRASP on an > insecure link. The killer is the TCP reply, which implies a TCP stack, which > most which to avoid. Yes, but then GRASP's scope is between autonomic nodes, not between all Things. I expect that most Things will be managed by an ASA in a bigger autonomic node. > > A good exampe for replacing multicast with unicast is WiFI where > > luckily hosts do accept multicast packets as L2 unicast instead of L2 > > multicast. And thats done to get the benefit of L2 retransmissions, > > that do not exist for L2 multicast. > > but, also because L2 multicast must be sent at the data rate/power-level of > the weakest receiver, so L2-multicasts can eat hundreds of unicast TxOps. Indeed, but I don't in general see that as being in AN scope. (It may well be in BRSKI scope.) Brian From nobody Wed Nov 2 14:18:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56DF129453 for ; Wed, 2 Nov 2016 14:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caP-8cAnPZ0a for ; Wed, 2 Nov 2016 14:18:10 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E071298A3 for ; Wed, 2 Nov 2016 14:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2675; q=dns/txt; s=iport; t=1478121489; x=1479331089; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=JvSrRidrSLQ3lKU/bz5CZ0xO9CcVJq8Uf3yCwSogIn0=; b=RJYi5o+U/EFT81hUuqMNAmBdfsTLs+QYjIyQrfUZ45UBz6nOO4huWBFI 5RyA0gz1Fegu4HDw9B8xCr8MB2IbzhkXiXmhDjmiU23dxeHiWtUzNXUNI 8r/IPtnXjcu3+Xay1S+Dc5wzNCiqcyH9s9WlSzcy4jceyU1Xt0CNZp0EF I=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.31,436,1473120000"; d="asc'?scan'208";a="649644171" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2016 21:18:07 +0000 Received: from [10.61.88.89] (ams3-vpn-dhcp6234.cisco.com [10.61.88.89]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uA2LI7VU031562; Wed, 2 Nov 2016 21:18:07 GMT To: Brian E Carpenter , "Max Pritikin (pritikin)" References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> From: Eliot Lear Message-ID: <57e9b4a6-c9a6-6299-28ac-eeee7eeea78e@cisco.com> Date: Wed, 2 Nov 2016 22:18:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3TXW6XAV2I27IpBaebLL9KwLlkgOjD7u5" Archived-At: Cc: Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 21:18:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3TXW6XAV2I27IpBaebLL9KwLlkgOjD7u5 Content-Type: multipart/mixed; boundary="NNrTuBGpFcG8qDCFhgLOUkfummAFxGNBN"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , "Max Pritikin (pritikin)" Cc: Anima WG Message-ID: <57e9b4a6-c9a6-6299-28ac-eeee7eeea78e@cisco.com> Subject: Re: [Anima] [homenet] write up of time without clocks References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> In-Reply-To: <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> --NNrTuBGpFcG8qDCFhgLOUkfummAFxGNBN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, On 11/2/16 8:09 PM, Brian E Carpenter wrote: > Firstly, no, I have no pixie dust, and I agree that we need to preserve= > security even after a disaster. But on the other hand, if autonomic > networks matter at all, they will matter then, and we can't safely assu= me > that network operators are available even to switch on some sort of eme= rgency > MASA server. Also, how would a temporary tactical network used by emerg= ency > responders configure itself if no vendor MASA server is accessible? > > I'm not suggesting that the basic BRSKI mechanisms need to solve this, > but I think we need to have it on the list of issues to be tackled befo= re > we can consider Anima complete. Before we start imagining what the requirements in such situations are, are they at all written somewhere? Otherwise we run the risk of inventing a lot of mechanism to deal with a non-existent use case. Eliot --NNrTuBGpFcG8qDCFhgLOUkfummAFxGNBN-- --3TXW6XAV2I27IpBaebLL9KwLlkgOjD7u5 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 iQEcBAEBCAAGBQJYGlgOAAoJEIe2a0bZ0nozrZ0IALXLU4a1QNYrcVHGUnx0XtSN xlyCtB7n2RUeXu2cqTNY/IomOSGEJm5f4X7UCbvvsOurRGZoCZzG4oNY8Xp1wAIZ 1hhdkvv/wOHp018LUVdliG1hkjuuzc3JXoLDKiuznAPGPwCVZae7s66T0VFJvGL2 JpGRhAjcbpZx/sn7LH2yRbsCkIwtY6jBE7KMc3kzIlz4BT8lLMJ5mp8GrW/nz88z kVvupeRdRTuxZ1erwr/2FpdYZNFnfnv7j3WZ5JJy7OVbmasjSgsMZbxaYjWdFMCc KIS7dlLl26rK1s82VKRSq3NIG+TwuYRm3h4/gnmzkJ8mOq31yZtUr+g7yTXQB6w= =jbEP -----END PGP SIGNATURE----- --3TXW6XAV2I27IpBaebLL9KwLlkgOjD7u5-- From nobody Wed Nov 2 14:57:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1BD129960 for ; Wed, 2 Nov 2016 14:57:02 -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 14knOIoV2MoX for ; Wed, 2 Nov 2016 14:57:01 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA7B1298A3 for ; Wed, 2 Nov 2016 14:57:01 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 189so18592594pfz.3 for ; Wed, 02 Nov 2016 14:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8z5xnUJgEceRZtbWQrZriEC3rtfkwnKFnuw3m3zbMD4=; b=VAfkhxVDezTs17NtAAFpYCt27AlJWEHmBvJmP4seFvsHwFutX+J3bFFBs/aMvCkjM6 9dPcuViFicfmAVaLXHKPOscdcOV2qj5Axrjvfq7nD4oeZHoA7RevUI9s2AbthNcQ/Fxr WH1Nee9jcCQl9NwEjbND/MZYOinAoZO4R6Dm/YxfcYd+BSycrMLQq8NwCXB3ALKn4lEq IKnYV4cIACO93U1V/h1Qthb6beDhfh1b8q8ycqz0Fmo0q4AAS6t44SPm8iLoO4a6jzoe JihFZm8R9vaOhG6rlyEySZa5RjyJ2oAvPDaDkXEVahZflOtCan7NSwr25T+wi+zVomiA 5sGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=8z5xnUJgEceRZtbWQrZriEC3rtfkwnKFnuw3m3zbMD4=; b=Yc2lCvWC1vBqcPhhTwwlMsUUS6YN9kup+VJzfzHmuUlfsE6NxLQnwtwsKN5vh8OqRB aXpIAqtBblesuhNDZM17WwV6JyMZF0cwE1ot7K84cRb8vpAH+n0EXGG6m30rRJJ5MywN +Zp4xh+cf/PjLfVah+h3f3depm/Di1aeiQBkxDjPwez5nSxVcQjkFGxz+4kCBukGu81o KaX6VSCmaMuNgYNnFiUfqLl4v1RKSNgP3mdh70vuRRVQxKczvugcPGESOb3UCKARuuP9 74wz7ldgP1qIRfonwV0h13RN5suHnx9sBhmEMhr91fRHWTP2picsZoSTYSeuRgPNeE3I 8qgw== X-Gm-Message-State: ABUngvdOsD+oUCop0KLEnDKLnnlYNwQla04MkJ7Vk/YbCUb8Lxiz+rKUxtnOMLqYayWN4g== X-Received: by 10.98.9.67 with SMTP id e64mr10985191pfd.74.1478123820756; Wed, 02 Nov 2016 14:57:00 -0700 (PDT) Received: from [192.168.178.23] ([118.148.78.158]) by smtp.gmail.com with ESMTPSA id f62sm7059928pfg.18.2016.11.02.14.56.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 14:56:59 -0700 (PDT) To: Eliot Lear , "Max Pritikin (pritikin)" References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <57e9b4a6-c9a6-6299-28ac-eeee7eeea78e@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 3 Nov 2016 10:57:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <57e9b4a6-c9a6-6299-28ac-eeee7eeea78e@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 21:57:03 -0000 On 03/11/2016 10:18, Eliot Lear wrote: > Hi Brian, > > On 11/2/16 8:09 PM, Brian E Carpenter wrote: >> Firstly, no, I have no pixie dust, and I agree that we need to preserve >> security even after a disaster. But on the other hand, if autonomic >> networks matter at all, they will matter then, and we can't safely assume >> that network operators are available even to switch on some sort of emergency >> MASA server. Also, how would a temporary tactical network used by emergency >> responders configure itself if no vendor MASA server is accessible? >> >> I'm not suggesting that the basic BRSKI mechanisms need to solve this, >> but I think we need to have it on the list of issues to be tackled before >> we can consider Anima complete. > > Before we start imagining what the requirements in such situations are, > are they at all written somewhere? Otherwise we run the risk of > inventing a lot of mechanism to deal with a non-existent use case. Certainly. And it may be a general problem, not specific to Anima and Homenet. Brian From nobody Wed Nov 2 15:17:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07221294C9 for ; Wed, 2 Nov 2016 15:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 wEu9Ep9vBQDH for ; Wed, 2 Nov 2016 15:17:01 -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 01B821296E5 for ; Wed, 2 Nov 2016 15:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7346; q=dns/txt; s=iport; t=1478125020; x=1479334620; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ngxOU6hsMl0yJ5w5ZUwejvym99YgvgxQQt7ZE7dQ5PI=; b=SCYX8owkWhG1cAdPn4yM1vRE04CWyXg4jRI8iOPSW7/1AuiH4Pq/Bc0M wW7HgNYLAoRyFfSTAxkWx5aq5+PY6ZfjW8ykVzlbwu2OmA4K5kxYqnpmF qTgUrIDdgPVf1WOSPpHuiO6xYBrg3BY7jjCLTCljWY8cd9qGVhW7qGUH4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAgA0ZRpY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywBAQEBAR9YfAekMIdhjGaCBx0LhXoCGoIPQBMBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBAwEBAQEgEToLBQsCAQgRAwECAQICJgICAh8GCxUICAIEDgWIPAMPC?= =?us-ascii?q?A6tKokADYNzAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBB4czgliCR4FqFheCbS2?= =?us-ascii?q?CLwWRC4hdNQGNBoMzkAmIeYQfhAMBIAEzZ4UXcgGGICqBBYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,436,1473120000"; d="scan'208";a="166773951" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2016 22:16:59 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uA2MGxR5007640 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Nov 2016 22:16:59 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Nov 2016 17:16:58 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 2 Nov 2016 17:16:58 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] [homenet] write up of time without clocks Thread-Index: AQHSNSL3BRQYNKneTkCmSexr2zyoYaDGMiWAgAAwwYCAADRMAA== Date: Wed, 2 Nov 2016 22:16:58 +0000 Message-ID: <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> In-Reply-To: <86ee80a9-0304-bc57-d017-844ec684cd69@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.24.80.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anima WG , Eliot Lear Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Nov 2016 22:17:03 -0000 DQo+IE9uIE5vdiAyLCAyMDE2LCBhdCAxOjA5IFBNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEZpcnN0bHksIG5vLCBJIGhhdmUg bm8gcGl4aWUgZHVzdCwgYW5kIEkgYWdyZWUgdGhhdCB3ZSBuZWVkIHRvIHByZXNlcnZlDQo+IHNl Y3VyaXR5IGV2ZW4gYWZ0ZXIgYSBkaXNhc3Rlci4gQnV0IG9uIHRoZSBvdGhlciBoYW5kLCBpZiBh dXRvbm9taWMNCj4gbmV0d29ya3MgbWF0dGVyIGF0IGFsbCwgdGhleSB3aWxsIG1hdHRlciB0aGVu LCBhbmQgd2UgY2FuJ3Qgc2FmZWx5IGFzc3VtZQ0KPiB0aGF0IG5ldHdvcmsgb3BlcmF0b3JzIGFy ZSBhdmFpbGFibGUgZXZlbiB0byBzd2l0Y2ggb24gc29tZSBzb3J0IG9mIGVtZXJnZW5jeQ0KPiBN QVNBIHNlcnZlci4gQWxzbywgaG93IHdvdWxkIGEgdGVtcG9yYXJ5IHRhY3RpY2FsIG5ldHdvcmsg dXNlZCBieSBlbWVyZ2VuY3kNCj4gcmVzcG9uZGVycyBjb25maWd1cmUgaXRzZWxmIGlmIG5vIHZl bmRvciBNQVNBIHNlcnZlciBpcyBhY2Nlc3NpYmxlPw0KDQpJIHRoaW5rIEVsaW904oCZcyBwb2lu dCB0aGF0ICJtb3N0IGZpcnN0IHJlc3BvbmRlcnMgd2lsbCBoYXZlIHRyYWluZWQgd2l0aCB0aGUg ZXF1aXBtZW50IHRoZXkgaGF2ZSBwcmlvciB0byB0aGUgZGlzYXN0ZXLigJ0gbWVhbmluZyB0aGF0 IHRoYXQgZXF1aXBtZW50IHdpbGwgYWxyZWFkeSBoYXZlIGJlZW4gYm9vdHN0cmFwcGVkLiBJbiB0 aGlzIGNhc2UgTUFTQSBpc27igJl0IG5lZWRlZC4NCg0KQW55IG5ldyBlcXVpcG1lbnQgdGhhdCBu ZWVkcyB0byBiZSBkZXBsb3llZCBjYW4gYmUgYm9vdHN0cmFwcGVkIHVzaW5nIGVpdGhlciB0aGUg bm9uY2VsZXNzIGF1ZGl0IHRva2VucyBvciB0aGUgcGh5c2ljYWwgcG9zc2Vzc2lvbiB3b3JrYXJv dW5kcy4gSW4gdGhpcyBjYXNlIHRoZSBNQVNBIGNhbiBiZSBvZmZsaW5lIHNvIGxvbmcgYXMgbmVj ZXNzYXJ5IGF1ZGl0IHRva2VucyBjYW4gYmUgYnJvdWdodCBpbnRvIHRoZSBhcmVhIGFsb25nIHdp dGggdGhlIHJlcGxhY2VtZW50IGVxdWlwbWVudC4gDQoNCkJleW9uZCB0aGF0LCBzYXkgYSBsYXJn ZSBzY2FsZSBuZXR3b3JrIG5lZWRzIHRvIGJlIGJyb3VnaHQgdXAsIHRoZW4gSSBzdXNwZWN0IGEg c2VydmljZSBsaWtlIHRoZSBDaXNjbyBORVJWIHRydWNrIHdpbGwgYmUgYnJvdWdodCBpbiB0byBw cm92aWRlIHNhdGVsbGl0ZSBjb25uZWN0aXZpdHkuIEluIHdoaWNoIGNhc2UgdGhlIE1BU0Egc2Vy dmVyIGNhbiBiZSBjb250YWN0ZWQuIA0KDQotIG1heA0KDQo+IA0KPiBJJ20gbm90IHN1Z2dlc3Rp bmcgdGhhdCB0aGUgYmFzaWMgQlJTS0kgbWVjaGFuaXNtcyBuZWVkIHRvIHNvbHZlIHRoaXMsDQo+ IGJ1dCBJIHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSBpdCBvbiB0aGUgbGlzdCBvZiBpc3N1ZXMgdG8g YmUgdGFja2xlZCBiZWZvcmUNCj4gd2UgY2FuIGNvbnNpZGVyIEFuaW1hIGNvbXBsZXRlLg0KPiAN Cj4gICBCcmlhbg0KPiANCj4gT24gMDMvMTEvMjAxNiAwNToxNSwgRWxpb3QgTGVhciB3cm90ZToN Cj4+IEkgbXlzZWxmIHdvdWxkIGJlIGNvbmNlcm5lZCBvdmVyIGEgZG93bmdyYWRlIGF0dGFjay4g DQo+PiANCj4+IFJlY2FsbCB0aGF0IHRoaXMgb25seSBpbXBhY3RzIEJSU0tJIGluIGFzIG11Y2gg YXMgdGhlIGRldmljZSBuZWVkcyB0byBiZQ0KPj4gcHJvdmlzaW9uZWQgKmR1cmluZyogdGhlIGRp c2FzdGVyLiAgV2hpbGUgdGhlcmUgbWF5IHlldCBiZSBzb21lIGNsYXNzZXMNCj4+IG9mIGRldmlj ZXMgdGhhdCByZXF1aXJlIHRoaXMsIEknbSBnb2luZyB0byBoYXphcmQgKGNvdWdoKSBhIGd1ZXNz IHRoYXQNCj4+IG1vc3QgZmlyc3QgcmVzcG9uZGVycyB3aWxsIGhhdmUgdHJhaW5lZCB3aXRoIHRo ZSBlcXVpcG1lbnQgdGhleSBoYXZlDQo+PiAqcHJpb3IqIHRvIHRoZSBkaXNhc3Rlci4gIEZvciB0 aGUgcmVtYWluaW5nIGVxdWlwbWVudCwgaWYgaXQgaXMgcGFydCBvZg0KPj4gY3JpdGljYWwgaW5m cmFzdHJ1Y3R1cmUgYW5kIHJlcXVpcmVzIGEgbmV0d29yaywgdGhlbiB0aGUgbmV0d29yayBuZWVk cw0KPj4gdG8gYmUgdXAuICBUaGUgb25seSBxdWVzdGlvbiB0aGVuIGlzIHdoZXRoZXIgdGhlIE1B U0Egc2VydmVyIG5lZWRzIHRvIGJlDQo+PiB1cC4gIEl0IGlzIHBlcmZlY3RseSBwb3NzaWJsZSB0 byBkZXNpZ24gYSBzeXN0ZW0gd2hlcmUgdGhhdCBpcyB0aGUgY2FzZS4NCj4+IA0KPj4gRWxpb3QN Cj4+IA0KPj4gDQo+PiBPbiAxMS8yLzE2IDU6MDUgUE0sIE1heCBQcml0aWtpbiAocHJpdGlraW4p IHdyb3RlOg0KPj4+IE15IHBvc2l0aW9uIGlzIHRoYXQgZHVyaW5nIGEgbGFyZ2Ugc2NhbGUgZGlz YXN0ZXIgaXQgd291bGQgYmUgZm9vbGlzaCBvZiB1cyB0byB0aGluayB0aGF0IHNlY3VyaXR5IGlz IHNvbWVob3cgbGVzcyBpbXBvcnRhbnQuIA0KPj4+IA0KPj4+IEJSU0tJIHN1cHBvcnRzIG5vbmNl bGVzcyB0b2tlbnMgdGhhdCBjYW4gYmUgZGlzdHJpYnV0ZWQgaW4gYWR2YW5jZS4gVGhlc2UgaW5j bHVkZSB0aGUgc2VyaWFsIG51bWJlciBvZiB0aGUgZGV2aWNlIGFuZCB0aGUgZG9tYWluIENBIGNl cnQgc28gaXQgSVMgTk9UIGEgIm1hc3RlciBrZXkiLg0KPj4+IAlBIOKAnG1hc3RlciBrZXnigJ0g aXMgdG9vIHNpbWlsYXIgdG8gYSDigJxiYWNrIGRvb3LigJ0gZm9yIG1lIHRvIHN1cHBvcnQgaXQu IA0KPj4+IA0KPj4+IEJSU0tJIGNsaWVudCBtYXkgc3VwcG9ydCBwaHlzaWNhbCBwcmVzZW5jZSAo YnV0dG9ucyBldGMpIHRoYXQgcHV0IHRoZW0gaW4g4oCYdHJ1c3Qgb24gZmlyc3QgdXNl4oCZIG1v ZGUuIA0KPj4+IA0KPj4+IEJSU0tJIGFkZHJlc3NlcyDigJh0aW1lIHdpdGhvdXQgY2xvY2tz4oCZ IHRocm91Z2ggdGhlIHVzZSBvZiBub25jZXMgYW5kIHNlY3Rpb24gMy4xLjUuDQo+Pj4gDQo+Pj4g SSBjb3VsZCBiZSBwZXJzdWFkZWQgdG93YXJkIGEgbW9yZSBnZW5lcmljIHRvZnUgbW9kZWwgb25s eSBpZiBkZXZpY2VzIGluY2x1ZGUgYW4gaW50ZWdyYXRlZCBoYXJkd2FyZSBhc3Npc3RlZCBlbmRw b2ludCBhc3Nlc3NtZW50ICh0aGluayBUUE0gc3R5bGUgYXR0ZXN0YXRpb24gdy8gcnVudGltZSBt ZWFzdXJlbWVudHMpLiBUaGF0IHRlY2hub2xvZ3kgaXNu4oCZdCByZWFsbHkgYXZhaWxhYmxlIHll dC4NCj4+PiANCj4+PiBUaGUgYXBwcm9hY2hlcyBwcm92aWRlZCBoZXJlIHdvcmsgd2l0aCBzb21l IHByaW9yIHBsYW5uaW5nIGJ1dCBhcmUgbm90IG1hZ2ljYWwuIA0KPj4+IA0KPj4+IERvIHlvdSBo YXZlIHBpeGllIGR1c3QgdG8gc3VnZ2VzdD8gDQo+Pj4gDQo+Pj4gLSBtYXgNCj4+PiANCj4+Pj4g T24gTm92IDEsIDIwMTYsIGF0IDg6NTMgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gU29tZXRoaW5nIG92ZXIgb24g aG9tZW5ldCBwcm9tcHRlZCBtZSB0byBzZW5kIHRoZSBmb2xsb3dpbmcuIEkgZG8gaGF2ZSB0aGUN Cj4+Pj4gc2FtZSBjb25jZXJuIGZvciBCUlNLSSAtIHdoYXQncyB0aGUgZGlzYXN0ZXIgcmVjb3Zl cnkgbWVjaGFuaXNtIHdoZW4gYWxsDQo+Pj4+IHZlbmRvciBNQVNBcyBhcmUgdW5yZWFjaGFibGUg YnV0IHdlIG11c3QgcmVzdGFydCB0aGUgbmV0d29yayBhbnl3YXk/DQo+Pj4+IA0KPj4+PiAgQnJp YW4NCj4+Pj4gDQo+Pj4+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+Pj4+ IFN1YmplY3Q6IFJlOiBbaG9tZW5ldF0gd3JpdGUgdXAgb2YgdGltZSB3aXRob3V0IGNsb2Nrcw0K Pj4+PiBEYXRlOiBXZWQsIDIgTm92IDIwMTYgMDg6Mzg6MDQgKzEzMDANCj4+Pj4gRnJvbTogQnJp YW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4NCj4+Pj4gT3JnYW5p emF0aW9uOiBVbml2ZXJzaXR5IG9mIEF1Y2tsYW5kDQo+Pj4+IFRvOiBob21lbmV0QGlldGYub3Jn DQo+Pj4+IA0KPj4+PiBPbiAwMi8xMS8yMDE2IDAzOjUyLCBQaGlsaXAgSG9tYnVyZyB3cm90ZToN Cj4+Pj4gLi4uDQo+Pj4+PiBXaGljaCBicmluZ3MgbWUgdG8gdGhlIGZvbGxvd2luZzogZ2l2ZW4g dGhhdCBhbGwgY29kZSBoYXMgc2VjdXJpdHkgaXNzdWVzLA0KPj4+Pj4gbWF5YmUgZGV2aWNlcyBz aG91bGQgY2hlY2sgZm9yIHVwZGF0ZXMgYW5kIGp1c3Qgc2h1dGRvd24gaWYgdGhleSBjYW4ndA0K Pj4+Pj4gdmVyaWZ5IHRoYXQgdGhleSBhcmUgcnVubmluZyB0aGUgbGF0ZXN0IGZpcm13YXJlPw0K Pj4+PiBUaGF0IHNvdW5kcyBhYnNvbHV0ZWx5IGRyZWFkZnVsIGZvciBkaXNhc3RlciByZWNvdmVy eSBzY2VuYXJpb3Mgd2hlcmUNCj4+Pj4gdGhlIEludGVybmV0IGlzIGJhZGx5IGJyb2tlbiAoYWZ0 ZXIgYSBodXJyaWNhbmUsIGVhcnRocXVha2UsIGV0Yy4pDQo+Pj4+IGFuZCBwZW9wbGUgbmVlZCB0 byByZXN0YXJ0IGVzc2VudGlhbCBzeXN0ZW1zIChvciB0aGV5IG5lZWQgdG8gcmVzdGFydA0KPj4+ PiB0aGVtc2VsdmVzKS4NCj4+Pj4gDQo+Pj4+PiBTbyB0aGUgZGV2aWNlIHNob3VsZCBoYXZlIHRo ZSB2ZW5kb3IncyBsb25nIHRlcm0gVExTIGNlcnRpY2F0ZS4gV2l0aCBwb3NzaWJseQ0KPj4+Pj4g YW4gb3B0aW9uIGZvciB0aGUgdXNlciB0byBkaXNhYmxlIHRoaXMga2luZCBvZiBzZWN1cml0eSBp ZiB0aGUgZGV2aWNlIGlzDQo+Pj4+PiBub3QgYWN0dWFsbHkgY29ubmVjdGVkIHRvIHRoZSBpbnRl cm5ldC4NCj4+Pj4gTm8sIGR1cmluZyBkaXNhc3RlciByZWNvdmVyeSB0aGUgbGFzdCB0aGluZyB5 b3UgbmVlZCBpcyBmb3Igb3JkaW5hcnkgcGVvcGxlDQo+Pj4+IHRvIGJlIGZhY2VkIHdpdGggc3Ry YW5nZSBzZWN1cml0eSBhbGVydHMgdGhhdCB0aGV5J3ZlIG5ldmVyIHNlZW4gYmVmb3JlLg0KPj4+ PiAoSXQncyByYXRoZXIgbGlrZSBhZHZpc2luZyBwZW9wbGUgdG8gZ28gaW50byB0aGUgQklPUyB0 byBjaGFuZ2UgYW4gb3B0aW9uDQo+Pj4+IHdoaWxlIHRoZSBmaXJlIGFsYXJtIGlzIHJpbmdpbmcu KQ0KPj4+PiANCj4+Pj4gVGhpbmdzIG5lZWQgdG8ganVzdCB3b3JrIGR1cmluZyBkaXNhc3RlciBy ZWNvdmVyeS4NCj4+Pj4gDQo+Pj4+ICAgQnJpYW4NCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IEFuaW1hIG1haWxpbmcgbGlz dA0KPj4+PiBBbmltYUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FuaW1hDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+PiBBbmltYUBpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4+IA0KPj4g DQo+IA0KDQo= From nobody Thu Nov 3 12:54:30 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4A512964F for ; Thu, 3 Nov 2016 12:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 WpquhdtPFhHI for ; Thu, 3 Nov 2016 12:54:25 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1611295E0 for ; Thu, 3 Nov 2016 12:54:25 -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 874F058C4AF; Thu, 3 Nov 2016 20:54:23 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 737CAB0AD16; Thu, 3 Nov 2016 20:54:23 +0100 (CET) Date: Thu, 3 Nov 2016 20:54:23 +0100 From: Toerless Eckert To: Eliot Lear Message-ID: <20161103195423.GA6498@faui40p.informatik.uni-erlangen.de> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <57e9b4a6-c9a6-6299-28ac-eeee7eeea78e@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57e9b4a6-c9a6-6299-28ac-eeee7eeea78e@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Max Pritikin \(pritikin\)" , Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 03 Nov 2016 19:54:27 -0000 On Wed, Nov 02, 2016 at 10:18:06PM +0100, Eliot Lear wrote: > Hi Brian, > > Before we start imagining what the requirements in such situations are, > are they at all written somewhere? Otherwise we run the risk of > inventing a lot of mechanism to deal with a non-existent use case. Not being Brian, but you being encumbered with more IETF/IAB background, let me bring up the point that during anima formation, our AD(s) where not too happy to delay progress in anima by "requirements" documents or the much. - not sure if/how this might have changed - written requireemnts from other WGs would be nice instead of us (anima) having to come up with them - Wasn't/isn't there some form of work in IETF bout emergency or the like (911)... drawing a blank here, but maybe those folks have requirements to draw from. Cheers Toerless From nobody Thu Nov 3 12:54:56 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7476F1296C2 for ; Thu, 3 Nov 2016 12:54:54 -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, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 6FZlVq9FyjcY for ; Thu, 3 Nov 2016 12:54: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 6B1F3129620 for ; Thu, 3 Nov 2016 12:54: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 C161E58C4AF; Thu, 3 Nov 2016 20:54:51 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B6545B0AD16; Thu, 3 Nov 2016 20:54:51 +0100 (CET) Date: Thu, 3 Nov 2016 20:54:51 +0100 From: Toerless Eckert To: Eliot Lear Message-ID: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Max Pritikin \(pritikin\)" , Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 03 Nov 2016 19:54:54 -0000 On Wed, Nov 02, 2016 at 10:18:06PM +0100, Eliot Lear wrote: > Hi Brian, > > Before we start imagining what the requirements in such situations are, > are they at all written somewhere? Otherwise we run the risk of > inventing a lot of mechanism to deal with a non-existent use case. Not being Brian, but you being encumbered with more IETF/IAB background, let me bring up the point that during anima formation, our AD(s) where not too happy to delay progress in anima by "requirements" documents or the much. - not sure if/how this might have changed - written requireemnts from other WGs would be nice instead of us (anima) having to come up with them - Wasn't/isn't there some form of work in IETF bout emergency or the like (911)... drawing a blank here, but maybe those folks have requirements to draw from. Cheers Toerless From nobody Thu Nov 3 13:40:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D22C129850 for ; Thu, 3 Nov 2016 13:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 0Gg1ltvAXcxy for ; Thu, 3 Nov 2016 13:40:35 -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 61689129855 for ; Thu, 3 Nov 2016 13:40:26 -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 0BD9B58C4AF; Thu, 3 Nov 2016 21:40:25 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E2B79B0AD1B; Thu, 3 Nov 2016 21:40:24 +0100 (CET) Date: Thu, 3 Nov 2016 21:40:24 +0100 From: Toerless Eckert To: "Max Pritikin (pritikin)" Message-ID: <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Eliot Lear , Anima WG Subject: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 03 Nov 2016 20:40:37 -0000 IMHO, gear replacement after large outages is quite relevant: I have seen equipment become unusable after bad power situations (spike, brownout, electrical storms,..) because of el-cheapo power supply/circuitry as well as wired interface circuitry/protection. Certifications in Telco/IoT make that type of gear often better, but those certifcations are a zoo. - Large organizations will have spares. With ANIMA, those spares should be stored pre-enrolled to avoid MASA/registrar dependency during recovery/replacements: Receive gear on any site (no central provisioning site needed), but unpack, plug in for short period, then stash away. This is imo an easy requirement also useful without desaster requirements - aka: enrolled spares would likely also have better theft/abuse protection than non-enrolled. And yes, you will have to power up these spares once a year. Which IMHO is ok. And of course certs should therefore be somewhat longer than 1 year). - If sparing would be cross-locations (eg: spares sent from some site to other sites during recovery), then its important that the ANIMA certs do not include any location specific attributes that would prohibit thart movement. So far BRSKY does not include any such attributes, but in discussions, three has been interest to lock into the cert some device role specific attributes, and for a spare piecce of equipment, those attributes may not be predetermined. Aka: Desaster sparing means domain certs need to be simple, devices reuseable across domain. - If spares are done by a shared facility: vendor, FEMO (for fed networks) or the like, one could think of that entity offering (emergency) enrolment service. Such an entity would have desaster proof MASA connectivity on site, and the customers would provide it with (emergency) registrar certs. (emergency) meaning that the entity is only permitted to enrol during emergencies, and the customer could be able to verify the emergency entities behavior by pulling from the MASA an audit log. If the customer would give the emergeny registrar credentials cert/private/public-key to the emergeny entities, then the customer itself also has the cert/private-key and could ask the MASA. This option would work with current BRSKY text. I am just not sure about security BCP (having two copies of a public key pair...). - If the shared spare storage facility is Best Buy, and the Jones family wants to replace some electric storm victims @home while their ISP takes its days (my ISP C*...*T took almost 48 hours in one case), then the gear should probably come with a nonceless voucher printed on on a scratcher piece of paper inside the box. Beyond these BRSKY considerations, the next cool ANIMA piece to consider for these use-cases is of course the ASA driven "re-configuration" of the spare device, aka: In larger outages, you should not except the whole network provisioning backend to be up and running. And its IMHO illusionary to expect devices to ONLY be driven from intent for many years (in complex networks... in a clean homenet they are driven by intent today..). Aka: for pre-intent-only desaster proof networks, we'd need: - ASA to cache neighbors configs. - reapply neighbor stored config when replacement gear is inserted. - IMHO: An anima definition for a "device-role-id" which is not the ACP IPv6 address (which will change upon gear replacement without enrolment support). Cheers toerless From nobody Thu Nov 3 15:55:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4F5129874 for ; Thu, 3 Nov 2016 15:55:04 -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, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 0dboBW96JDAT for ; Thu, 3 Nov 2016 15:55:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DA41294EB for ; Thu, 3 Nov 2016 15:55:03 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1C1AA58C4AF; Thu, 3 Nov 2016 23:55:02 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 02C8DB0AD20; Thu, 3 Nov 2016 23:55:01 +0100 (CET) Date: Thu, 3 Nov 2016 23:55:01 +0100 From: Toerless Eckert To: Michael Richardson Message-ID: <20161103225501.GD6498@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Anima WG Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 03 Nov 2016 22:55:04 -0000 On Wed, Nov 02, 2016 at 10:34:39AM -0400, Michael Richardson wrote: > I have no problem with the use of a GRASP multicast discovery here. > > I wonder about the utility of the GRASP unicast TCP response to the ACP > discovery. See my last email to Brian et.al. on the signaling list, aka: GRASP-08: A responder MAY send a Discovery Response message I also think that should be a MUST NOT or SHOULD NOT. > Why not simply respond to the ACP discovery with a key management initiation > to the sender of the multicast? Right. Thats what would happen if there is no response at the GRASP level. either IPsec session setup or eg: TLS with gRASP inside to negotiate the ACP channel protocol. > My reasoning is as follows: > 1) four TCP packets across the insecure ("public") LAN just to say "okay" > 2) insecure GRASP instance must open TCP port on insecure LAN, and accept > connections from anything. (See discussion about possible CBOR encoding > attacks). > 3) discovery of ACP peers is meaningless outside of the the local-link. > 4) IKEv2 (whether used for IPsec keying, or MACsec keying [%]) already > provides all the negotiation we need, and does it with higher privacy > and security than GRASP could. Right. The GRASP responses serve no requirement that i know in the case of DULL GRASP instances. I think they where kept in the spec so far because the original signaling exchange was discovery, discovery response, and then synchronization. Which was the sequence Brian implemented before the unsolicited "flood-sync" which wraps it all up into one message. Aka: What i want is the "flood-sync" that minimizes signaling and IMHO makes responses unnecessary. > Yes, I realize that this is an "exception" case for GRASP, but I also claim > that all insecure instances of GRASP will be extremely minimal, purpose built > things. Call it uGRASP if you like. Right. Logically it could be one implementation with multiple objectives (ACP, BRSKY,...), but technically its very good that each of these services could run it's own uGRASP instance without collision: As long as the sockets are opened with SO_REUSEADDR ;-) > There are two LL multicast involved: > a) outside of ACP LL multicast on the underlying link. > b) inside of the ACP LL multicast, which is really just p2p traffic. > > Brian, RPL has an associated multicast routing protocol called "MPL". > We discussed it before, but it might be worth discussing it again to be sure > we went down the right path. Maybe we should open a separate thread about that. Its certainly attractive to conside RPL as a carrier for additional flooded messages, but i have seen a long history of doing that in a variety of IGP, and it has always lead to a lot of frustrations when there where multiple coices of IGPs So i'd for now stick by a rule that the IGP should only flood info that only the IGP needs, the rest would be flooded by a mandatory soulution specific protocol approach. eg: GRASP in our case. > We decided that GRASP would do application > layer multicasting -- as such, there will be hardly any actual layer-2 > multicast, as all the ACP links are p2p. Using multicast destinations here > is a convenience to not knowing what the peer's address is, except that once > we have the first response via TCP, we do know the peer, and we might as well > just use that channel for future communication. By specifying the use of LL multicast for GRASP discovery, we make it most easily reuseable in arbitrary contexts: There is no dependency against "ACP", but only against "some underlying security". For example, i could build IOT networks without ACP and still use GRASP as long as i am sure all my links have eg: 802.1x or the like. A lot of IoT wireless networks will come with link-security. I am also not sure where/how we would actually make anything simpler by not using LL multicast: For the ACP, all interfaces are p2p ACP secure channels, whether i send LL multicast or LL unicast doesn't make a difference. Except that i'd need to learn the LL unicast. > I see no places in IoT where we would want to use insecure GRASP on an > insecure link. The killer is the TCP reply, which implies a TCP stack, which > most which to avoid. Another good point for optimizing the insecure GRASP the way we seem to agree upon (only LL multicast announcements). Ok, but that has IMHO two separate conclusions: -> For DULL GRASP we only need LL multicast announcements, no replies -> If we want to proliferate GRASP into IoT contexts without TCP, we need to specify how to run GRASP there. For GRASP today, Brian an I seem to be the priamry fans of TCP for reliability, flow-control etc -> which is why thats mandated for GRASP eg: in ACP. BRSKY has started to add text about CoAP as the TCP alternative . Maybe we need that for GRASP as well ? I have not yet tried to understand the properties of COAP well enough to see how well it would fit, but most GRASP exchange should be similarily simple as BRSKY, so it would probably fit easily. Except that one needs to write all that text about the encoding... > > A good exampe for replacing multicast with unicast is WiFI where > > luckily hosts do accept multicast packets as L2 unicast instead of L2 > > multicast. And thats done to get the benefit of L2 retransmissions, > > that do not exist for L2 multicast. > > but, also because L2 multicast must be sent at the data rate/power-level of > the weakest receiver, so L2-multicasts can eat hundreds of unicast TxOps. In IPv6, receivers MUST use MLD for all groups. Senders can track this and know the power level required for the furthest away receiver for each group and send packets for each group with the minimum required level for that receiver. That would make multicast TX always equal or better than unicast TX (better as soon as there are two or more receivers reachable by the same beam). Its just that no wireless technology specifies this behavior. RX is the bigger issue. I bet there is a lot of unnecessary wakeup for multicast packets not needed. Aka: Would need per multicast-address wakeup HW like there is for the unicast address. Periodic unsolicited announcements like in DULL GRASP are definitely offenders in such low powr networks. Depending on the type of network one can optimize the periodic part away or leverage some central component (AP etc.) as a helper. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > From nobody Thu Nov 3 17:35:47 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922ED1294BF for ; Thu, 3 Nov 2016 17:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 NAe_NJGdrw4q for ; Thu, 3 Nov 2016 17:35:44 -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 54E6B1294B1 for ; Thu, 3 Nov 2016 17:35:44 -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 3FB1B58C4AF; Fri, 4 Nov 2016 01:35:42 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 24A19B0AD21; Fri, 4 Nov 2016 01:35:42 +0100 (CET) Date: Fri, 4 Nov 2016 01:35:42 +0100 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20161104003541.GE6498@faui40p.informatik.uni-erlangen.de> References: <20161031221855.GA1970@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: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 00:35:46 -0000 On Tue, Nov 01, 2016 at 01:59:17PM +1300, Brian E Carpenter wrote: > I will read that carefully, but for me that doesn't need justification, because > we need the ANI to be self-contained, so depending on mDNS seems wrong. (In > fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic function itself?) Just justification why to use GRASP instead of CDP/LDP/mDNS based on the rule "ANIMA should reuse first, and invent only when reuse is not a sufficient solution to meet requirements". For example: for GRASP inside ACP we didn't need to put in justification because nobody ever claimed that there are equivalent prior IETF solutions. > And that's the problem. GRASP discovery and flooding need sockets that > supports link-local multicast sending and receiving for each physical > interface. > > Currently the GRASP code finds out how many physical interfaces it has > and for each one creates a multicast sending socket. It also has a socket > that listens for incoming link-local multicasts on all physical interfaces. > I don't see how to do that using the ACP interfaces that you describe. GRASP should have a separate socket for each interface - but use that socket both for sending and receiving. No shared socket for reception. GARSP only needs to figure out which interface is physcial and which is ACP. On router-OSs, each interface would be assigned to a VRF, so it's easy to enumerate the interfaces of eg: the ACP being one VRF. In Linux the closest equivalent are network contexts. ACP could be one network context. Compared to router-OS, linux is more secure/constrained: Processes only have access to one network context. So you'd have to run separate GRASP processes. Which may be a good thing. > > All packets, unicast or multicast that are sent into or > > received from those interfaces are protected/encrypted by the fact that they are transmitted > > encrypted by the seleted ACP channel encryption protocol. > > Yes, and I'd like the LL multicast traffic to be protected too. > But as far as I can see that needs explicit support in the ACP > to emulate LL multicast sockets. The ideal would be that the ACP > simply emulates LL interfaces, so that GRASP could treat them exactly > like physical interfaces. Right. But this is not a new ACP thing. Any existing IETF protocol implementation that uses link-local addresses and runs on any type of any form of physical or virtual interface needs some form of interface representation at the API level to send/receive LL packets. Thats why i am somewhat hesitant to add explanatory text for this to the ACP draft. It's supposed to be implied by the IPv6 addressing model and common practice in IETF documents that its not regurgitated too much. > If you want, I can point you the exact Python code that handles this > in the prototype. Please do. Just not sure when i'll find time. Cheers Toerless From nobody Thu Nov 3 17:46:41 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779AC12959C for ; Thu, 3 Nov 2016 17:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 XYm_bO9fzCeK for ; Thu, 3 Nov 2016 17:46:36 -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 BC16A129571 for ; Thu, 3 Nov 2016 17:46:36 -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 67C1858C4AF; Fri, 4 Nov 2016 01:46:35 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 25A81B0AD21; Fri, 4 Nov 2016 01:45:32 +0100 (CET) Date: Fri, 4 Nov 2016 01:45:32 +0100 From: Toerless Eckert To: "Max Pritikin (pritikin)" Message-ID: <20161104004531.GF6498@faui40p.informatik.uni-erlangen.de> References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <0610AD70-3D43-4A83-BDBD-3CB8433DC3FA@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0610AD70-3D43-4A83-BDBD-3CB8433DC3FA@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 00:46:39 -0000 On Tue, Nov 01, 2016 at 10:42:32PM +0000, Max Pritikin (pritikin) wrote: > Taken to the extreme one could argue that we need ANI to be self-contined so depending on IP seems wrong. Can you explain where you think ANI depends on IP in a fashion you ae calling "wrong" ? Cheers Toerless > There is a point where ANI needs to depend and integrate with existing systems. > > My position is that the demarcation point is bootstrapping of the keying infrastructure. Prior to bootstrapping we depend on generic mechanisms and behaviors that any device might experience on a modern network. Post keying we have sufficient methods to differentiate between ANI and all that other stuff. > > Another way of stating my position ???we need bootstrapping to be as well contained as possible, so depending on GRASP seems wrong???. In truth of course the Proxy to Registrar communication benefits from GRASP so it is suggested there for ANI devices. This compromise integrates bootstrapping with ANI in a way that provides value when ANI exists but doesn???t depend on it for situations where it doesn???t exist. > > - max > > > > >> > >>>> When GRASP is run securely in its two forms for the ACP, it is always protected/ > >>>> encrypted by the ACP, so i think your security concern would then not be valid. > >>> > >>> I'm still waiting to see a clear explanation of how the ACP will secure > >>> LL multicast, however. > >> > >> I am not sure i understand the documentation ask. The ACP has a bunch of (virtual) interfaces. In > >> the most simple implementation option, each ACP channel to an ACP neighbor is its own > >> (p2p) L3 interface in the ACP. And thats all the interfaces the ACP has. > > > > And that's the problem. GRASP discovery and flooding need sockets that > > supports link-local multicast sending and receiving for each physical > > interface. > > > > Currently the GRASP code finds out how many physical interfaces it has > > and for each one creates a multicast sending socket. It also has a socket > > that listens for incoming link-local multicasts on all physical interfaces. > > I don't see how to do that using the ACP interfaces that you describe. > > > >> All packets, unicast or multicast that are sent into or > >> received from those interfaces are protected/encrypted by the fact that they are transmitted > >> encrypted by the seleted ACP channel encryption protocol. > > > > Yes, and I'd like the LL multicast traffic to be protected too. > > But as far as I can see that needs explicit support in the ACP > > to emulate LL multicast sockets. The ideal would be that the ACP > > simply emulates LL interfaces, so that GRASP could treat them exactly > > like physical interfaces. > > > > If you want, I can point you the exact Python code that handles this > > in the prototype. > > > >> > >>>> Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS, > >>>> eg: in some IoT context ? > >>> > >>> Michael can answer that for himself, but the reason we noted the *possibility* > >>> of doing this in grasp-08 is because it seems clearly harmless. So from the > >>> GRASP spec point of view, I consider the issue closed. > >> > >> Ues, i am mostly interested in use-case explanations Michael has in mind. > >> > >> The other piece was that Michael was trying to figure out how to avoid using LL multicast > >> and instead use unicast: > >> > >> -> Within the ACP this question is somewhat irrelevant because its secured. > >> > >> -> Given how ACP interfaces are p2p secured interfaces to neigbhors, you > >> could know upfront the LL IPv6 address of the neighbor on the interface, > >> but there is really no framework in IETF protocols that leverages this > >> optimization for p2p links, so i don't think we should bother doing it. > >> Its work without RoI. > >> > >> -> Outside the ACP i am not sure about the use-case. To be options proof: GRASP > >> should permit sending and receiving of LL UNICAST instead of LL multicast for > >> those messages where GRASP specifies LL multicast, so that if some deployment > >> figures out that there is some optimization possible with the use of LL unicast, > >> then it can simply do that instead of asking for a GRASP spec modification. > > > > Sure. That was my conclusion (for discovery; it makes no sense for flooding). > > > >> The big security risk though is GLOBAL UNICAST MUST NOT BE PERMITTED > >> as a replacement for LL multicast. Thats an attack vector. And typical > >> socket software code is usually victim to that. Aka: you open a socket, > >> you bind it to a link-local multicast group and you go away. Alas: this > >> socket will receive not only link-local multicast, but also LL unicast (good) > >> and global unicast (bad). So the application code usually would need to check > >> the destination address the packet was sent to and drop those packets > >> sent to the global unicast address - if the protocol was really only > >> designed for LL multicast - and therefore assuming security properties > >> of LL multicast (logical vicinity of sender). > > > > GRASP discovery and flood are specified as link-local, so yes, that check > > is needed. > > > >> A good exampe for replacing multicast with unicast is WiFI where luckily > >> hosts do accept multicast packets as L2 unicast instead of L2 multicast. > >> And thats done to get the benefit of L2 retransmissions, that do not exist > >> for L2 multicast. > > > > Ack. > > Brian From nobody Thu Nov 3 21:28:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0331D1296EF for ; Thu, 3 Nov 2016 21:28: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 6icO2S2uij_z for ; Thu, 3 Nov 2016 21:28:18 -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 B7543127735 for ; Thu, 3 Nov 2016 21:28:18 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id d2so44016657pfd.0 for ; Thu, 03 Nov 2016 21:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ipDegvLi6DTHoviGkVijsvsQGVhN7D9fZSa7lDPfNYw=; b=rcY8Fd4esgnvoXx1fBDXAQvBcZYOCmhSN2xo5wkjLeaTPu51Qg1n3GmKhybe2RrRFo TP23AqfSSPdLE6gcw3xlZdPZirBwgLHPs7MCH4h8kfOTBngnV7yjbz5EmnEIT3+N5Wel oKptFEhgd1HNBy/iox9X8tNfPJxiNp8ZPFAxgrD0Sy1q7zU2YMV/gEbTz5WnNQ5wLcvZ WDdPFnLLwQMaBl/z9tX1gpg3IcFWdmQZyU3pAUnWKZHd08RbFsxRUXTq0HcTuy4bLE8h t4opM9w50hiCoczvurHD7dE3mR2McRL3Y8EmwXkBynLLODwOa1TxmikGTlY4xquGEEG5 k+3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ipDegvLi6DTHoviGkVijsvsQGVhN7D9fZSa7lDPfNYw=; b=lAOwWr15W9jiga/GbP42bMWHVAOWjArexU1FA9zRyRu3sLHPwYAThmyGeZq5Xhy4yZ vq3DfetHRC5c0Osowmcd2XRvf9T/na0RGjnbzqGf7bk3mtZ8mMf9kB9JAYVphvqAmA8l eN5sFWKrsPw4FUvJMVEaMBY7sfdyc7TmhD+NyvljfXHQ5Z+63ZbrMXdpKMW1b+OcBBsj Y365PBJ8wIiM/OkbNDHHnMzkH9Ux9rwvWptHktPsHllXoBMuu3CZVSxTE8K3XCU8EVXm M0jagCtrHu7mSDhyqamdOjGyArehlO9Oq/NNc/tNjdfMfAZGD+fvICy3ROBTEWKTFkP1 Y4IA== X-Gm-Message-State: ABUngvfcR/Bop52ACkgPVNK/xoIVLN4X+ZA1ugcz7xyCOxv63xidgM1Xpkw6PwmtKCgPtQ== X-Received: by 10.99.126.3 with SMTP id z3mr19245600pgc.46.1478233697803; Thu, 03 Nov 2016 21:28:17 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id a78sm16163870pfj.44.2016.11.03.21.27.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 21:28:17 -0700 (PDT) To: Toerless Eckert , Michael Richardson References: <20161103225501.GD6498@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4e12be91-e700-2db6-f52b-551fdf0f7404@gmail.com> Date: Fri, 4 Nov 2016 17:27:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161103225501.GD6498@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 04:28:21 -0000 On 04/11/2016 11:55, Toerless Eckert wrote: > On Wed, Nov 02, 2016 at 10:34:39AM -0400, Michael Richardson wrote: >> I have no problem with the use of a GRASP multicast discovery here. >> >> I wonder about the utility of the GRASP unicast TCP response to the ACP >> discovery. > > See my last email to Brian et.al. on the signaling list, aka: > > GRASP-08: A responder MAY send a Discovery Response message > I also think that should be a MUST NOT or SHOULD NOT. I assume you mean that in the restricted contex of bootstrap, because in any other case of course the unicast response is needed. It's a MAY because an ASA might want to hide for some reason. > >> Why not simply respond to the ACP discovery with a key management initiation >> to the sender of the multicast? > > Right. Thats what would happen if there is no response at the GRASP level. > either IPsec session setup or eg: TLS with gRASP inside to negotiate > the ACP channel protocol. > >> My reasoning is as follows: >> 1) four TCP packets across the insecure ("public") LAN just to say "okay" >> 2) insecure GRASP instance must open TCP port on insecure LAN, and accept >> connections from anything. (See discussion about possible CBOR encoding >> attacks). >> 3) discovery of ACP peers is meaningless outside of the the local-link. >> 4) IKEv2 (whether used for IPsec keying, or MACsec keying [%]) already >> provides all the negotiation we need, and does it with higher privacy >> and security than GRASP could. > > Right. The GRASP responses serve no requirement that i know in the > case of DULL GRASP instances. I think they where kept in the spec so far > because the original signaling exchange was discovery, discovery response, > and then synchronization. Which was the sequence Brian implemented > before the unsolicited "flood-sync" which wraps it all up into one > message. Aka: What i want is the "flood-sync" that minimizes signaling and > IMHO makes responses unnecessary. > >> Yes, I realize that this is an "exception" case for GRASP, but I also claim >> that all insecure instances of GRASP will be extremely minimal, purpose built >> things. Call it uGRASP if you like. > > Right. Logically it could be one implementation with multiple > objectives (ACP, BRSKY,...), but technically its very good that > each of these services could run it's own uGRASP instance without > collision: As long as the sockets are opened with SO_REUSEADDR ;-) > >> There are two LL multicast involved: >> a) outside of ACP LL multicast on the underlying link. >> b) inside of the ACP LL multicast, which is really just p2p traffic. >> >> Brian, RPL has an associated multicast routing protocol called "MPL". >> We discussed it before, but it might be worth discussing it again to be sure >> we went down the right path. > > Maybe we should open a separate thread about that. Its certainly > attractive to conside RPL as a carrier for additional flooded messages, > but i have seen a long history of doing that in a variety of IGP, and > it has always lead to a lot of frustrations when there where multiple > coices of IGPs So i'd for now stick by a rule that the IGP should only > flood info that only the IGP needs, the rest would be flooded by > a mandatory soulution specific protocol approach. eg: GRASP in our case. > >> We decided that GRASP would do application >> layer multicasting -- as such, there will be hardly any actual layer-2 >> multicast, as all the ACP links are p2p. Using multicast destinations here >> is a convenience to not knowing what the peer's address is, except that once >> we have the first response via TCP, we do know the peer, and we might as well >> just use that channel for future communication. > > By specifying the use of LL multicast for GRASP discovery, we > make it most easily reuseable in arbitrary contexts: There is no > dependency against "ACP", but only against "some underlying security". > For example, i could build IOT networks without ACP and still use > GRASP as long as i am sure all my links have eg: 802.1x or the like. > A lot of IoT wireless networks will come with link-security. > > I am also not sure where/how we would actually make anything simpler > by not using LL multicast: For the ACP, all interfaces are p2p ACP > secure channels, whether i send LL multicast or LL unicast doesn't make > a difference. Except that i'd need to learn the LL unicast. > >> I see no places in IoT where we would want to use insecure GRASP on an >> insecure link. The killer is the TCP reply, which implies a TCP stack, which >> most which to avoid. > > Another good point for optimizing the insecure GRASP the way we > seem to agree upon (only LL multicast announcements). > > Ok, but that has IMHO two separate conclusions: > > -> For DULL GRASP we only need LL multicast announcements, no replies If that is so, definitely use Flood not Discover. It's designed to have no reply. > > -> If we want to proliferate GRASP into IoT contexts without TCP, Out of scope for Anima, surely? Brian > we need to specify how to run GRASP there. For GRASP today, > Brian an I seem to be the priamry fans of TCP for reliability, > flow-control etc -> which is why thats mandated for GRASP eg: > in ACP. BRSKY has started to add text about CoAP as the TCP > alternative . Maybe we need that for GRASP as well ? I have not > yet tried to understand the properties of COAP well enough to > see how well it would fit, but most GRASP exchange should be > similarily simple as BRSKY, so it would probably fit easily. Except > that one needs to write all that text about the encoding... > >> > A good exampe for replacing multicast with unicast is WiFI where >> > luckily hosts do accept multicast packets as L2 unicast instead of L2 >> > multicast. And thats done to get the benefit of L2 retransmissions, >> > that do not exist for L2 multicast. >> >> but, also because L2 multicast must be sent at the data rate/power-level of >> the weakest receiver, so L2-multicasts can eat hundreds of unicast TxOps. > > In IPv6, receivers MUST use MLD for all groups. Senders can track this > and know the power level required for the furthest away receiver for > each group and send packets for each group with the minimum required level > for that receiver. That would make multicast TX always equal or better than > unicast TX (better as soon as there are two or more receivers reachable by > the same beam). Its just that no wireless technology specifies this behavior. > > RX is the bigger issue. I bet there is a lot of unnecessary wakeup for > multicast packets not needed. Aka: Would need per multicast-address wakeup > HW like there is for the unicast address. > > Periodic unsolicited announcements like in DULL GRASP are definitely > offenders in such low powr networks. Depending on the type of network > one can optimize the periodic part away or leverage some central > component (AP etc.) as a helper. > > Cheers > Toerless > >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Nov 3 21:43:51 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9974012951D for ; Thu, 3 Nov 2016 21:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkbQWjTiiuPW for ; Thu, 3 Nov 2016 21:43:47 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C0612946F for ; Thu, 3 Nov 2016 21:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2757; q=dns/txt; s=iport; t=1478234626; x=1479444226; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=71MyYajeT78ZB0ruDho+cxnFRilh41BIOjcBCUYTufg=; b=empPk5NKwi1g/Qx8m996ae4QuhJ/AiAyCbObBWH52G6FTBwlF9Sg6BwO FQL3Mnp5mE0jEfEJaRY6/1tdEkYgfRnlBWQhw4f9MktwrD4Zjqr05jFWc m4eV6kQt7X8J0Ki6c89e22dEydVA2vifBZeemVuoECRBZgC5HCWBRWYMe E=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.31,442,1473120000"; d="asc'?scan'208";a="647868921" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 04:43:44 +0000 Received: from [10.61.212.124] ([10.61.212.124]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uA44hiFV014305; Fri, 4 Nov 2016 04:43:44 GMT To: Toerless Eckert References: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: Date: Fri, 4 Nov 2016 05:43:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8rXG2tMkdlkKdbx5pnb8p3uQAKa3RSNRU" Archived-At: Cc: "Max Pritikin \(pritikin\)" , Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 04:43:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8rXG2tMkdlkKdbx5pnb8p3uQAKa3RSNRU Content-Type: multipart/mixed; boundary="XRxAlkg4Vs0FKChxngwAnjnDxog0fuJ1w"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert Cc: Brian E Carpenter , "Max Pritikin (pritikin)" , Anima WG Message-ID: Subject: Re: [Anima] [homenet] write up of time without clocks References: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> --XRxAlkg4Vs0FKChxngwAnjnDxog0fuJ1w Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Toerless, On 11/3/16 8:54 PM, Toerless Eckert wrote: > On Wed, Nov 02, 2016 at 10:18:06PM +0100, Eliot Lear wrote: >> Hi Brian, >> >> Before we start imagining what the requirements in such situations are= , >> are they at all written somewhere? Otherwise we run the risk of >> inventing a lot of mechanism to deal with a non-existent use case. > Not being Brian, but you being encumbered with more IETF/IAB > background, let me bring up the point that during anima formation, > our AD(s) where not too happy to delay progress in anima by=20 > "requirements" documents or the much. Sure, and I don't think we should. > > - not sure if/how this might have changed > - written requireemnts from other WGs would be nice instead > of us (anima) having to come up with them > - Wasn't/isn't there some form of work in IETF bout emergency > or the like (911)... drawing a blank here, but maybe those > folks have requirements to draw from. The ECRIT WG did some work, and indeed that is where I went to look at some of this stuff. But I think they were quite focused on E911-type solutions and didn't go further. Eliot --XRxAlkg4Vs0FKChxngwAnjnDxog0fuJ1w-- --8rXG2tMkdlkKdbx5pnb8p3uQAKa3RSNRU 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 iQEcBAEBCAAGBQJYHBH/AAoJEIe2a0bZ0nozUW0H/1LZlEVhYd4PE6acSFw5qK8Q +hiB5ttsmDyCN+JkB2/lKup2r8CjNq5lfLUmtgx5REmlkgowtD0ivUIbQl1Rufcv LYu+BGaAi5QtWglmTlKVQQQRdbWWRKEhcflQYqaoJzTs4+o1BjfcXJvtwopjNh3p Lr/8FVNw7QOCasWOhd7eNFzM7PU/P8bNv0nQT96D1GqWIenUAGA010ua3tCacSwB kA/BOtO8kqZPntJjcJRfmEva2+s8zwwx4lfHP1YYSsIC2avA5AIDtDwLMlg0IrTs NDznbE3Nug+VhZYscPN79Z5V/NSbE7MIwOp5trE67Mi3e53mbP569+aZxBfSEA0= =YJ4U -----END PGP SIGNATURE----- --8rXG2tMkdlkKdbx5pnb8p3uQAKa3RSNRU-- From nobody Fri Nov 4 00:08:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07159129597 for ; Fri, 4 Nov 2016 00:08:49 -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 ZEXn2cpF5ppH for ; Fri, 4 Nov 2016 00:08:48 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E59D12957B for ; Fri, 4 Nov 2016 00:08:48 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id n85so46658247pfi.1 for ; Fri, 04 Nov 2016 00:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=g1zUtQXj3n/m4uox1W1wrNpdKRthmFQLwejDlmBsJuM=; b=NO26fRdl+eEv8nKyTZmay6/wBkck2OPbZSFLgsDUu0A+xCVJ01eKxCdSDo54c2HM1z Ra8/GyzLhAlDbuW/u4rlp9xYopYPkfuHA4zkFnqChyHb5EJ/GJA9lWICknmEinIS+vUs 6CWt4VkusG2pKU+Dd/vh0Km1JXlBM3dd37qlqiAQDMQHVdwi8wiZd7/nOp/mR+WX/Kch fP/6YGzqKBLkYyEMOQjlVffHOrlF1YRmlsWEH3pW9bRd6MAdh0auIjv/XHPEfrHUvSr/ 17NvHVKrLx5wAYcDLwWqlDIUqwimq62LiF7v0JBliHO7x2AIOGuw2a4si6C96Fxo5SOs 1DPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=g1zUtQXj3n/m4uox1W1wrNpdKRthmFQLwejDlmBsJuM=; b=Axl/y4diRpsjQSAeR42azhHxTrOHJdkrpuZVC3FRUqXrqKdAb9UZ4+zmRC5GQvIB/K ZSsHSG2hutvTI7tM3cD3B6Pz9NguZXQGs+BBNcWozwrWKpslxf1blUzYyHlUpbTniFMk jJmU2P0YvG1ZW/EW7vRyPlw1N09pqNbnlP9Vzr5ny2VhVmj4TLlzATZzoP30h0hARPDc cg1FDRnjfXlZyx34g7VPRk6XL9YyoCmrEUzlalK7byjf5WL9KfsQWGZtL9Pr0FAJJgIU Va7tD1tx2okWjUKzr6ntWetN/OOuVK2Nf+SCinYI8xVupFYeymI1IEDijXfrJW0OW3In sBoQ== X-Gm-Message-State: ABUngvdyxP8LVBfeq67fwrIGmyrrIV3HcXIhqTwt0TFGElz3KUpIn2y06KHzZrHSczXCAQ== X-Received: by 10.99.49.213 with SMTP id x204mr19768553pgx.92.1478243327584; Fri, 04 Nov 2016 00:08:47 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id s7sm17525835pfg.32.2016.11.04.00.08.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 00:08:47 -0700 (PDT) To: Eliot Lear , Toerless Eckert References: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7f62920e-fe08-2d1a-93f8-05a399f3eece@gmail.com> Date: Fri, 4 Nov 2016 20:08:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Max Pritikin \(pritikin\)" , Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 07:08:49 -0000 On 04/11/2016 17:43, Eliot Lear wrote: > Hi Toerless, > > > On 11/3/16 8:54 PM, Toerless Eckert wrote: >> On Wed, Nov 02, 2016 at 10:18:06PM +0100, Eliot Lear wrote: >>> Hi Brian, >>> >>> Before we start imagining what the requirements in such situations are, >>> are they at all written somewhere? Otherwise we run the risk of >>> inventing a lot of mechanism to deal with a non-existent use case. >> Not being Brian, but you being encumbered with more IETF/IAB >> background, let me bring up the point that during anima formation, >> our AD(s) where not too happy to delay progress in anima by >> "requirements" documents or the much. > > Sure, and I don't think we should. >> >> - not sure if/how this might have changed >> - written requireemnts from other WGs would be nice instead >> of us (anima) having to come up with them >> - Wasn't/isn't there some form of work in IETF bout emergency >> or the like (911)... drawing a blank here, but maybe those >> folks have requirements to draw from. > > The ECRIT WG did some work, and indeed that is where I went to look at > some of this stuff. But I think they were quite focused on E911-type > solutions and didn't go further. Also, much of this topic is systems engineering, not protocol design. However, at the protocol design level it seems apparent that autonomic mechanisms *above all others* need to work when everything else is broken. For many aspects that reduces to defining defaults that apply on a cold start, but for security bootstrap in particular it also means defining what happens when no external dependencies are possible. That does seem to need pixie dust. Brian From nobody Fri Nov 4 00:33:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F96129436 for ; Fri, 4 Nov 2016 00:33:42 -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 bj-T8hoIHdIB for ; Fri, 4 Nov 2016 00:33:41 -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 44D451293E8 for ; Fri, 4 Nov 2016 00:33:41 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 189so47118151pfz.3 for ; Fri, 04 Nov 2016 00:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1t1xiEnBGuJeP+fQ2xvlQhhPF/cDyAajJwuV3Dm3utI=; b=qP+vOnCgO5WJuC7rBgarSjEx8vUuMW9ULtszKbpYSCNf6QbanVrYP2nAdE+MAG8aWO pcdB26WNkJiQlsGq7TFYQRmPubRoT+60KSeYO9Tx6m/mx2rZ2X3vsHf6/J5vV8Brtgwb +Gr4JzIkoSbJdnkpA7cK/ztH75woC6HkqGjKxV8AIAAcvatxXbIxTK/MezqDJQIwExQZ kST4DS5+qxJiIjiZNJBO5xpsQySaf5E5dUnLt7LBnGt405spEyZVy059jgk6i/sI5Qq5 hvbyFwKclWOn56SpoOX5Wky6hCo+SsNwOQJ5HH4vH0hTKCY0T8HxnS7EA8ianOGeCR/r 89aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1t1xiEnBGuJeP+fQ2xvlQhhPF/cDyAajJwuV3Dm3utI=; b=AzP3ZrUJyK3HfP9JJFJltAJdDvLh7qwsZ+1zzniyOEj7ZlfEhlp2O3pgh0ptAE7CQg FXbwdHMr7WPpPCCNCgcznlrnHUVTbxAlqEz4orh7/afyEGm6W9JJWQxXnd7TSHWeB5f0 Vf76obGKokaYKc8ARwHCVQPYAkK6K3GzqIfg5EnyrJPh9jpqk9FcG6dgLJs4OEZ8XpEL P8BHduVZqwHSlVWlV32iEkKMERCDnnf08Zd2jhvsMEq1am1qzWvDDi3eFvUwWUFp5I7C +aZ37U2bx8wKMGy7O7Z0aaWOp/XUJH90NeHJV4ZnpbJm/fxB90nSVmjV8Kua+bCfvBxm M7AQ== X-Gm-Message-State: ABUngveJFBqIrbAkcWSbFw6pUv8y1J0ayJ4B6AcimDCtGZ3p9V8IFabKeYB/eND0pm4ZTw== X-Received: by 10.98.87.199 with SMTP id i68mr21936186pfj.18.1478244820627; Fri, 04 Nov 2016 00:33:40 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id q7sm17813915pav.9.2016.11.04.00.33.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 00:33:39 -0700 (PDT) To: Toerless Eckert References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <20161104003541.GE6498@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 4 Nov 2016 20:33:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161104003541.GE6498@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 07:33:43 -0000 On 04/11/2016 13:35, Toerless Eckert wrote: > On Tue, Nov 01, 2016 at 01:59:17PM +1300, Brian E Carpenter wrote: >> I will read that carefully, but for me that doesn't need justification, because >> we need the ANI to be self-contained, so depending on mDNS seems wrong. (In >> fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic function itself?) > > Just justification why to use GRASP instead of CDP/LDP/mDNS based on > the rule "ANIMA should reuse first, and invent only when reuse is not > a sufficient solution to meet requirements". > > For example: for GRASP inside ACP we didn't need to put in justification because > nobody ever claimed that there are equivalent prior IETF solutions. > >> And that's the problem. GRASP discovery and flooding need sockets that >> supports link-local multicast sending and receiving for each physical >> interface. >> >> Currently the GRASP code finds out how many physical interfaces it has >> and for each one creates a multicast sending socket. It also has a socket >> that listens for incoming link-local multicasts on all physical interfaces. >> I don't see how to do that using the ACP interfaces that you describe. > > GRASP should have a separate socket for each interface How many interfaces do you mean? With no ACP, GRASP knows a reasonably small number of physical interfaces, and has to open a socket for each of the to send LL multicasts, and it has to listen for LL multicast from all of them, which as far as I know requires a separate socket that is bound to the relevant multicast address. In addition it has to open unicast sockets as and when needed, which may be bound to any kind of address. (In the limited instances they will be restricted to link-local unicast, but that's a special case.) I am still missing enough detail about the interfaces and socket options that the ACP will provide to know how this will change when the ACP is there. If there are, e.g., 400 autonomic nodes in the ACP and my node has 4 physical interfaces, each of which has 10 link-local neighbors, how many interfaces will the ACP offer me? 4, 40, 400? > - but use that > socket both for sending and receiving. No shared socket for reception. Why not? There's no problem identifying the source interface for a multicast, it comes right back in recvfrom() (at least on Windows or Linux). > GARSP only needs to figure out which interface is physcial and which > is ACP. On router-OSs, each interface would be assigned to a VRF, so > it's easy to enumerate the interfaces of eg: the ACP being one VRF. I would assume that the adjacency table would provide that sort of clue. To make my code agnostic about Winsock vs POSIX, I just use the interface numbers, not the names, and they should be system-wide unique. > In Linux the closest equivalent are network contexts. ACP could be one > network context. Compared to router-OS, linux is more secure/constrained: > Processes only have access to one network context. So you'd have to run > separate GRASP processes. Which may be a good thing. Yes. Actually I run multiple GRASP kernels all the time for my testing scenarios; it works nicely. > >>> All packets, unicast or multicast that are sent into or >>> received from those interfaces are protected/encrypted by the fact that they are transmitted >>> encrypted by the seleted ACP channel encryption protocol. >> >> Yes, and I'd like the LL multicast traffic to be protected too. >> But as far as I can see that needs explicit support in the ACP >> to emulate LL multicast sockets. The ideal would be that the ACP >> simply emulates LL interfaces, so that GRASP could treat them exactly >> like physical interfaces. > > Right. But this is not a new ACP thing. Any existing IETF protocol > implementation that uses link-local addresses and runs on any type of > any form of physical or virtual interface needs some form of interface > representation at the API level to send/receive LL packets. Thats why > i am somewhat hesitant to add explanatory text for this to the ACP > draft. It's supposed to be implied by the IPv6 addressing model and > common practice in IETF documents that its not regurgitated too much. No, it doesn't need much text but it really isn't obvious at all from the ACP draft, I assure you. > >> If you want, I can point you the exact Python code that handles this >> in the prototype. > > Please do. Just not sure when i'll find time. Let me do that when I'm back from my short vacation. Rgds Brian From nobody Fri Nov 4 01:07:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895BE129416 for ; Fri, 4 Nov 2016 01:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_ww-o54pjtf for ; Fri, 4 Nov 2016 01:07:09 -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 22DD1129407 for ; Fri, 4 Nov 2016 01:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3018; q=dns/txt; s=iport; t=1478246829; x=1479456429; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=cLNEV4xvoMfya4Eve2GJgZr/2yoCRkgaDNchNuW4FQk=; b=PFWgHnqe2lMv48L6HRgrvROksVvbSCogI01++9ameGVQ/rdT15I4yCR6 6F8Pg1p3tKXiDbr1Fn495ln46DMuOA3eYK7Frp3xWrlDzuY7HKgicMzZq 89tvztNNgl+FlA4SnxzDquqclfl8I64tYNaktxfhaFrud2oxVrdl8hDZV 0=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.31,442,1473120000"; d="asc'?scan'208";a="646852644" 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; 04 Nov 2016 08:07:07 +0000 Received: from [10.61.224.74] ([10.61.224.74]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA4877Ej010506; Fri, 4 Nov 2016 08:07:07 GMT To: Brian E Carpenter , Toerless Eckert References: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> <7f62920e-fe08-2d1a-93f8-05a399f3eece@gmail.com> From: Eliot Lear Message-ID: Date: Fri, 4 Nov 2016 09:07:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7f62920e-fe08-2d1a-93f8-05a399f3eece@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dBvEeQDdUSqM2bXA9eOHfSAs3TPf4Q8mS" Archived-At: Cc: "Max Pritikin \(pritikin\)" , Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 08:07:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dBvEeQDdUSqM2bXA9eOHfSAs3TPf4Q8mS Content-Type: multipart/mixed; boundary="q8lTh0DbnmVaiahpi7H1Qp0bwAcNPXBk4"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , Toerless Eckert Cc: "Max Pritikin (pritikin)" , Anima WG Message-ID: Subject: Re: [Anima] [homenet] write up of time without clocks References: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> <7f62920e-fe08-2d1a-93f8-05a399f3eece@gmail.com> In-Reply-To: <7f62920e-fe08-2d1a-93f8-05a399f3eece@gmail.com> --q8lTh0DbnmVaiahpi7H1Qp0bwAcNPXBk4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, On 11/4/16 8:08 AM, Brian E Carpenter wrote: > > Also, much of this topic is systems engineering, not protocol design. > However, at the protocol design level it seems apparent that autonomic > mechanisms *above all others* need to work when everything else is brok= en. > For many aspects that reduces to defining defaults that apply on a cold= > start, but for security bootstrap in particular it also means defining > what happens when no external dependencies are possible. That does seem= > to need pixie dust. > I could envision multiple approaches to addressing this, but I didn't want to go down the solutions path until we have a clear understanding of what we are solving for. For instance, there is replacement equipment, and then there are first responders. Do first responders require authentication? Is authentication in these cases a binary output or perhaps characterized differently? And how does this differ from other problems, such as electronic health records (EHR) in these circumstances? I think we could spend quite some time in that sort of discussion. For a proposed standard, we may be overreaching, and so we should be quite careful. But I would agree that the topic should be covered in greater depth. My issue is one of how much to bite off now. Eliot --q8lTh0DbnmVaiahpi7H1Qp0bwAcNPXBk4-- --dBvEeQDdUSqM2bXA9eOHfSAs3TPf4Q8mS 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 iQEcBAEBCAAGBQJYHEGqAAoJEIe2a0bZ0noz2OQH/05+HIdebuxXKdgicYVUE7g6 cw+d/1gmSMobcxqHL68ojum1V1tmAHBO/dtpn+Zv5Xa7cKmQjRwVBJL3pIpI5GR4 PVdoDxXYMF7f1QOIUkWopHIAM2fQ0wOy1muL21OVRej7MBxSiEjUMtemIEboN2FJ KbSQTN1DTLJMUBO7T2izrwuDsicxlVmQ2LO0bKqW+FWrRMFM6h5mdgspTnbu0kM/ s9v0xkeiqhXSpSpcP+UGTeAN9jH/MoH463+cuR3yxJWlZ/U82/zM8R2hPmdNazp8 3xUO17+GRbqN4bNa7+tetaNJBRc29v/0CjxcNEZQIJZ5uXWl9z93eDFzwHL/sK0= =BX9A -----END PGP SIGNATURE----- --dBvEeQDdUSqM2bXA9eOHfSAs3TPf4Q8mS-- From nobody Fri Nov 4 08:02:57 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A383129545 for ; Fri, 4 Nov 2016 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 wU-2enWH8Bml for ; Fri, 4 Nov 2016 08:02:52 -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 D0FFD129406 for ; Fri, 4 Nov 2016 08:02:51 -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 5A06858C4AF; Fri, 4 Nov 2016 16:02:50 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3EDD7B0AD2C; Fri, 4 Nov 2016 16:02:50 +0100 (CET) Date: Fri, 4 Nov 2016 16:02:50 +0100 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20161104150250.GI6498@faui40p.informatik.uni-erlangen.de> References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <20161104003541.GE6498@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: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 15:02:56 -0000 On Fri, Nov 04, 2016 at 08:33:43PM +1300, Brian E Carpenter wrote: > > GRASP should have a separate socket for each interface > > How many interfaces do you mean? With no ACP, GRASP knows a reasonably > small number of physical interfaces, and has to open a socket for each of > the to send LL multicasts, and it has to listen for LL multicast from > all of them, which as far as I know requires a separate socket that is bound > to the relevant multicast address. If each physcial interface connects to one ACP neighbor, the number of logical ACP interfaces would be the same as the number of physical interfaces. If an interface is a LAN connecting to N ACP neighbors, you would have N ACP virtual interfaces, one for each such neighbor. In an implementation of ACP that i could imagine. Of course, on a LAN with N ACP neighbors, those would be eg: routers interconnected via a switch, so if that switch was autonomic itself, then you should only see one ACP neighbor, the switch. That the point of the discussion about GRASP instead of mDNS for ACP discovery, and of course, on the switch, we'd need to figure out how to intercept the ACP messages to make that work. > In addition it has to open unicast sockets as and when needed, which may > be bound to any kind of address. (In the limited instances they will > be restricted to link-local unicast, but that's a special case.) > > I am still missing enough detail about the interfaces and socket options > that the ACP will provide to know how this will change when the ACP > is there. If there are, e.g., 400 autonomic nodes in the ACP and my node > has 4 physical interfaces, each of which has 10 link-local neighbors, > how many interfaces will the ACP offer me? 4, 40, 400? Never 400. 4 if the L2 switches on the LANs are ACP capable, 40 otherwise. > > - but use that > > socket both for sending and receiving. No shared socket for reception. > > Why not? There's no problem identifying the source interface for a multicast, > it comes right back in recvfrom() (at least on Windows or Linux). I probably should not have used "should" when i was recommending a separate socket per interface but instead: -> To me the logic of dealing with multiple interfaces wold be most easy if an implementation could have a separate socket for each interface, physcial and ACP-channel (aka: per ACP neighbor). With that approach, its clear at the socket level, which sockets belong to which security domain, and you do not have to enforce that via filtering when you receive messages. Socket API is a lot of confusing complexity. I haven't played with LL IP6 myself on linux, so i can only guess: - Lets assume you bind your socket to the LL IPv6 address of an interface via what the API doc calls the "scope ID" (which really is a zone ID). You should then be able to send/receive only from/to that interface. - I am not sure what impact this has on multicast. I was hoping that you could still do the setsockopt to add the GRASP LL IPv6 multicasr group, and in that API call you'd equally indicate your LL IPv6 addr and would then send and receive IPv6 LL multicast only on that interface. I have not tested this, so this is right now just conjecture. > > GARSP only needs to figure out which interface is physcial and which > > is ACP. On router-OSs, each interface would be assigned to a VRF, so > > it's easy to enumerate the interfaces of eg: the ACP being one VRF. > > I would assume that the adjacency table would provide that sort of clue. > To make my code agnostic about Winsock vs POSIX, I just use the interface > numbers, not the names, and they should be system-wide unique. Have to look at your code.. > > Right. But this is not a new ACP thing. Any existing IETF protocol > > implementation that uses link-local addresses and runs on any type of > > any form of physical or virtual interface needs some form of interface > > representation at the API level to send/receive LL packets. Thats why > > i am somewhat hesitant to add explanatory text for this to the ACP > > draft. It's supposed to be implied by the IPv6 addressing model and > > common practice in IETF documents that its not regurgitated too much. > > No, it doesn't need much text but it really isn't obvious at all from > the ACP draft, I assure you. Can you propose text ? Cheers Toerless > >> If you want, I can point you the exact Python code that handles this > >> in the prototype. > > > > Please do. Just not sure when i'll find time. > > Let me do that when I'm back from my short vacation. > > Rgds > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Nov 4 11:46:32 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B48129635 for ; Fri, 4 Nov 2016 11:46:31 -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 D2ADIGMXOgcM for ; Fri, 4 Nov 2016 11:46:30 -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 1CF71129580 for ; Fri, 4 Nov 2016 11:46:30 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id d2so56147557pfd.0 for ; Fri, 04 Nov 2016 11:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lpPaN9Rf4+e5b24CSaUaKNkHdcnRTWIiCdEyu6+Oq2U=; b=dOAgvoNQ3xQE5c9eDcryZ6IEwHX+PCrKSMGBcYewPvPSzXTIVsNZI+Mn0fk8XDBj4+ W5VS721USflcLKYsYAcoT9lNtQV69dleeEu5E/hz4YnPtUSpMp+he7W41iuNZn4FKQCm BHTwikRl55oHLrjyUxFIO0MUamzfZysrSr5hWYDR94LXqFYKYQd23iVmzndG2H4YDxAw xi8/R8ZmLJtFmmFUmyJmkD3Eg/mIyuqYErxgkdwJ8Dp5C7XQKi5QizYPjjqEWH09Avgt AkGKra3xwL+Ewyj0KKgbv1Z/VjgnK8c9Gve5I8wSZmUJap4YSk82F3Mg6gGx+FqP1iut /leA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=lpPaN9Rf4+e5b24CSaUaKNkHdcnRTWIiCdEyu6+Oq2U=; b=iEZGoqfIZRPQBAF6qFfrFnEPINz4kzPDet0NzW0bc/BiPiiYbgjgqDtj0DtEe2COqp slsqhl5Gje6tT48m1GIes2T0Ipl9/MBBI2QbvrIQ/lF9hez9Xw+AdWgb1u2/9jI1FJkN vAu698m0BkJMgJGl30TV2TiN+f5IiXspiZwc/8t0jKC9crP7q0fP6H9453S/LbvXtlmF V5e7m+5srK/rLajN8/fSOwzmXPXj4PfRbJAPpuFxlrspyqIcFJ7oksrHDa3l/+JsUFsA 05YHYYwjpN+G18rKq8PzrmCdZgFb1NaBkWbo1HVqUyvAiBJ82NGU6ZnowBKMMZhjabpQ kcmg== X-Gm-Message-State: ABUngvdYkeqpIqE0BTf/qp+EpS3fFTfnpArduibO0nWFRSUzYogI6EV9YmNi2l+7/6q1xA== X-Received: by 10.99.127.72 with SMTP id p8mr24355399pgn.142.1478285189598; Fri, 04 Nov 2016 11:46:29 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id r88sm22040426pfe.93.2016.11.04.11.46.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 11:46:29 -0700 (PDT) To: Eliot Lear , Toerless Eckert References: <20161103195451.GA8396@faui40p.informatik.uni-erlangen.de> <7f62920e-fe08-2d1a-93f8-05a399f3eece@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 5 Nov 2016 07:46:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Max Pritikin \(pritikin\)" , Anima WG Subject: Re: [Anima] [homenet] write up of time without clocks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 18:46:31 -0000 On 04/11/2016 21:07, Eliot Lear wrote: > Hi Brian, > > On 11/4/16 8:08 AM, Brian E Carpenter wrote: >> >> Also, much of this topic is systems engineering, not protocol design. >> However, at the protocol design level it seems apparent that autonomic >> mechanisms *above all others* need to work when everything else is broken. >> For many aspects that reduces to defining defaults that apply on a cold >> start, but for security bootstrap in particular it also means defining >> what happens when no external dependencies are possible. That does seem >> to need pixie dust. >> > > I could envision multiple approaches to addressing this, but I didn't > want to go down the solutions path until we have a clear understanding > of what we are solving for. For instance, there is replacement > equipment, and then there are first responders. Do first responders > require authentication? Is authentication in these cases a binary > output or perhaps characterized differently? And how does this differ > from other problems, such as electronic health records (EHR) in these > circumstances? I think we could spend quite some time in that sort of > discussion. For a proposed standard, we may be overreaching, and so we > should be quite careful. But I would agree that the topic should be > covered in greater depth. My issue is one of how much to bite off now. I completely agree. And indeed my concern is whether there is something fundamental that we need in BRSKI to allow for this - I mean something that would be very painful to retrofit later. Apart from that, the question can be deferred. Brian From nobody Fri Nov 4 13:54:59 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3884A1295C7 for ; Fri, 4 Nov 2016 13:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYKfXzltmpj5 for ; Fri, 4 Nov 2016 13:54:55 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B326129666 for ; Fri, 4 Nov 2016 13:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9140; q=dns/txt; s=iport; t=1478292895; x=1479502495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zrPovBIh08tKjVil/K7pkkTwSg5hZFDbDpwS+jMStfc=; b=BK7mr5vxoxezCOpPGl+beWmAPIXx8jcV1KjVw/1gnasQVyUaxWUojZCA +PjpvTnmArgi/faZUEDAZgcCqMu0+SpjZIVUh/oNs4Em6fw63lMaPnNe/ MoPsbMAZlDQiyZ0yG/eyiX2vyMqzD8xhwkMlg9d3evISPgo4yKs4/qHot 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAwBC9RxY/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR+BVAeNMZcAkjeCD4IIgl0QgzYCGoF+PxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRhAQEBAwEjBA1FBQsCAQgOCgICHwcCAgIwFRACBA4FiFAIryCMdwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARyBCYczCIJQhEeDBC2CLwWUG4YIAZA/kAqNIYQ?= =?us-ascii?q?DAR43bINcgUVyhjiBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,445,1473120000"; d="scan'208";a="344448465" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 20:54:54 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA4Kssrb030901 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 20:54:54 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 15:54:53 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Fri, 4 Nov 2016 15:54:53 -0500 From: "Max Pritikin (pritikin)" To: Toerless Eckert Thread-Topic: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) Thread-Index: AQHSM8TZyP6E5PobOUGQWWfnN/qHzqDDop+AgAFsHwCAA0cIAIABUeOA Date: Fri, 4 Nov 2016 20:54:53 +0000 Message-ID: <695835EA-B186-4949-981E-84C5F2FDACF5@cisco.com> References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <0610AD70-3D43-4A83-BDBD-3CB8433DC3FA@cisco.com> <20161104004531.GF6498@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20161104004531.GF6498@faui40p.informatik.uni-erlangen.de> 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: <67E889609B8BF54BA011ECE4ACAB47AD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 20:54:57 -0000 DQoNCj4gT24gTm92IDMsIDIwMTYsIGF0IDY6NDUgUE0sIFRvZXJsZXNzIEVja2VydCA8dHRlQGNz LmZhdS5kZT4gd3JvdGU6DQo+IA0KPiBPbiBUdWUsIE5vdiAwMSwgMjAxNiBhdCAxMDo0MjozMlBN ICswMDAwLCBNYXggUHJpdGlraW4gKHByaXRpa2luKSB3cm90ZToNCj4+IFRha2VuIHRvIHRoZSBl eHRyZW1lIG9uZSBjb3VsZCBhcmd1ZSB0aGF0IHdlIG5lZWQgQU5JIHRvIGJlIHNlbGYtY29udGlu ZWQgc28gZGVwZW5kaW5nIG9uIElQIHNlZW1zIHdyb25nLg0KPiANCj4gQ2FuIHlvdSBleHBsYWlu IHdoZXJlIHlvdSB0aGluayBBTkkgZGVwZW5kcyBvbiBJUCBpbiBhIGZhc2hpb24geW91DQo+IGFl IGNhbGxpbmcgIndyb25n4oCdID8NCg0KU2lnaC4gVG9vIG11Y2ggc25hcmsg4oCUIG5vdCBlbm91 Z2ggaW5mb3JtYXRpb24uDQoNCk15IHBvaW50IGlzIHRoYXQgQU5JIHdpbGwsIG9mIGNvdXJzZSwg ZGVwZW5kIG9uIHRoaW5ncy4gSXQgaXNu4oCZdCBhIHNlbGYgY29udGFpbmVkIHJlLWVudmlzaW9u bWVudCBvZiB0aGUgZW50aXJlIGNvbmNlcHQgb2YgbmV0d29ya2luZy4gDQoNCldoZXJlIHRob3Nl IHRoaW5ncyBhcmUgdGhlbXNlbHZlcyByZWFzb25hYmx5IGJvdW5kZWQgSSBkb27igJl0IHNlZSB0 aGUgcHJvYmxlbSB3aXRoIHVzaW5nIHRoZW0uIEZvciBleGFtcGxlIEkgY291bGQgc2VlIGFuIGFy Z3VtZW50IGFnYWluc3QgZGlzY3Vzc2luZyBETlMtU0QgYmVjYXVzZSBpdCBpcyBpbnRlbmRlZCB0 byBzcGFuIGxpbmtzIGFuZCB0aGVyZWZvcmUg4oCYZGVwZW5kc+KAmSBvbiB0aGUgRE5TIGluZnJh c3RydWN0dXJlLiBPbmUgY291bGQgYXJndWUgc2VjdXJlIEdSQVNQIHByb3ZpZGVzIHRoYXQgcm9s ZSB3aXRoaW4gYW4gQU5JIG5ldHdvcmsgYW5kIGRvZXMgc28gYmV0dGVyIChpZSBzZWN1cmVseSku IA0KDQpCdXQgbUROUyBpcyBub3QgZGVwZW5kZW50IG9uIHRoYXQgaW5mcmFzdHJ1Y3R1cmUuIElu c3RlYWQgaXQgaXMgYSByZWxhdGl2ZWx5IHNlbGYgY29udGFpbmVkIG1lY2hhbmlzbSB0aGF0IGRv ZXNu4oCZdCDigJxzdGVwIG9uIHRoZSB0b2Vz4oCdIG9yIGR1cGxpY2F0ZSB0aGluZ3MgaW4gdGhl IEFOSSBpbmZyYXN0cnVjdHVyZSBhbmQgaXQgZXhpc3RzIGFuZCBpcyB1c2VkIGFscmVhZHkuIFNv IGNyZWF0aW5nIHRvbyBtYW55IG9wdGlvbnMgaW4gdGhhdCBzcGFjZSBpcyBzaW1wbHkgYWRkaW5n IGNvbmZ1c2lvbi4gSnVzdCBsaWtlIGl04oCZZCBiZSBzaWxseSB0byBzdWdnZXN0IHRoYXQgQU5J IGRldmljZXMgc2hvdWxkbuKAmXQgdXNlIElQLiANCg0KLSBtYXgNCg0KPiANCj4gQ2hlZXJzDQo+ ICAgIFRvZXJsZXNzDQo+IA0KPj4gVGhlcmUgaXMgYSBwb2ludCB3aGVyZSBBTkkgbmVlZHMgdG8g ZGVwZW5kIGFuZCBpbnRlZ3JhdGUgd2l0aCBleGlzdGluZyBzeXN0ZW1zLiANCj4+IA0KPj4gTXkg cG9zaXRpb24gaXMgdGhhdCB0aGUgZGVtYXJjYXRpb24gcG9pbnQgaXMgYm9vdHN0cmFwcGluZyBv ZiB0aGUga2V5aW5nIGluZnJhc3RydWN0dXJlLiBQcmlvciB0byBib290c3RyYXBwaW5nIHdlIGRl cGVuZCBvbiBnZW5lcmljIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW9ycyB0aGF0IGFueSBkZXZpY2Ug bWlnaHQgZXhwZXJpZW5jZSBvbiBhIG1vZGVybiBuZXR3b3JrLiBQb3N0IGtleWluZyB3ZSBoYXZl IHN1ZmZpY2llbnQgbWV0aG9kcyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gQU5JIGFuZCBhbGwg dGhhdCBvdGhlciBzdHVmZi4gDQo+PiANCj4+IEFub3RoZXIgd2F5IG9mIHN0YXRpbmcgbXkgcG9z aXRpb24gPz8/d2UgbmVlZCBib290c3RyYXBwaW5nIHRvIGJlIGFzIHdlbGwgY29udGFpbmVkIGFz IHBvc3NpYmxlLCBzbyBkZXBlbmRpbmcgb24gR1JBU1Agc2VlbXMgd3Jvbmc/Pz8uIEluIHRydXRo IG9mIGNvdXJzZSB0aGUgUHJveHkgdG8gUmVnaXN0cmFyIGNvbW11bmljYXRpb24gYmVuZWZpdHMg ZnJvbSBHUkFTUCBzbyBpdCBpcyBzdWdnZXN0ZWQgdGhlcmUgZm9yIEFOSSBkZXZpY2VzLiBUaGlz IGNvbXByb21pc2UgaW50ZWdyYXRlcyBib290c3RyYXBwaW5nIHdpdGggQU5JIGluIGEgd2F5IHRo YXQgcHJvdmlkZXMgdmFsdWUgd2hlbiBBTkkgZXhpc3RzIGJ1dCBkb2Vzbj8/P3QgZGVwZW5kIG9u IGl0IGZvciBzaXR1YXRpb25zIHdoZXJlIGl0IGRvZXNuPz8/dCBleGlzdC4gDQo+PiANCj4+IC0g bWF4DQo+PiANCj4+PiANCj4+Pj4gDQo+Pj4+Pj4gV2hlbiBHUkFTUCBpcyBydW4gc2VjdXJlbHkg aW4gaXRzIHR3byBmb3JtcyBmb3IgdGhlIEFDUCwgaXQgaXMgYWx3YXlzIHByb3RlY3RlZC8NCj4+ Pj4+PiBlbmNyeXB0ZWQgYnkgdGhlIEFDUCwgc28gaSB0aGluayB5b3VyIHNlY3VyaXR5IGNvbmNl cm4gd291bGQgdGhlbiBub3QgYmUgdmFsaWQuDQo+Pj4+PiANCj4+Pj4+IEknbSBzdGlsbCB3YWl0 aW5nIHRvIHNlZSBhIGNsZWFyIGV4cGxhbmF0aW9uIG9mIGhvdyB0aGUgQUNQIHdpbGwgc2VjdXJl DQo+Pj4+PiBMTCBtdWx0aWNhc3QsIGhvd2V2ZXIuDQo+Pj4+IA0KPj4+PiBJIGFtIG5vdCBzdXJl IGkgdW5kZXJzdGFuZCB0aGUgZG9jdW1lbnRhdGlvbiBhc2suIFRoZSBBQ1AgaGFzIGEgYnVuY2gg b2YgKHZpcnR1YWwpIGludGVyZmFjZXMuIEluDQo+Pj4+IHRoZSBtb3N0IHNpbXBsZSBpbXBsZW1l bnRhdGlvbiBvcHRpb24sIGVhY2ggQUNQIGNoYW5uZWwgdG8gYW4gQUNQIG5laWdoYm9yIGlzIGl0 cyBvd24NCj4+Pj4gKHAycCkgTDMgaW50ZXJmYWNlIGluIHRoZSBBQ1AuIEFuZCB0aGF0cyBhbGwg dGhlIGludGVyZmFjZXMgdGhlIEFDUCBoYXMuDQo+Pj4gDQo+Pj4gQW5kIHRoYXQncyB0aGUgcHJv YmxlbS4gR1JBU1AgZGlzY292ZXJ5IGFuZCBmbG9vZGluZyBuZWVkIHNvY2tldHMgdGhhdA0KPj4+ IHN1cHBvcnRzIGxpbmstbG9jYWwgbXVsdGljYXN0IHNlbmRpbmcgYW5kIHJlY2VpdmluZyBmb3Ig ZWFjaCBwaHlzaWNhbA0KPj4+IGludGVyZmFjZS4NCj4+PiANCj4+PiBDdXJyZW50bHkgdGhlIEdS QVNQIGNvZGUgZmluZHMgb3V0IGhvdyBtYW55IHBoeXNpY2FsIGludGVyZmFjZXMgaXQgaGFzDQo+ Pj4gYW5kIGZvciBlYWNoIG9uZSBjcmVhdGVzIGEgbXVsdGljYXN0IHNlbmRpbmcgc29ja2V0LiBJ dCBhbHNvIGhhcyBhIHNvY2tldA0KPj4+IHRoYXQgbGlzdGVucyBmb3IgaW5jb21pbmcgbGluay1s b2NhbCBtdWx0aWNhc3RzIG9uIGFsbCBwaHlzaWNhbCBpbnRlcmZhY2VzLg0KPj4+IEkgZG9uJ3Qg c2VlIGhvdyB0byBkbyB0aGF0IHVzaW5nIHRoZSBBQ1AgaW50ZXJmYWNlcyB0aGF0IHlvdSBkZXNj cmliZS4NCj4+PiANCj4+Pj4gQWxsIHBhY2tldHMsIHVuaWNhc3Qgb3IgbXVsdGljYXN0IHRoYXQg YXJlIHNlbnQgaW50byBvciANCj4+Pj4gcmVjZWl2ZWQgZnJvbSB0aG9zZSBpbnRlcmZhY2VzIGFy ZSBwcm90ZWN0ZWQvZW5jcnlwdGVkIGJ5IHRoZSBmYWN0IHRoYXQgdGhleSBhcmUgdHJhbnNtaXR0 ZWQNCj4+Pj4gZW5jcnlwdGVkIGJ5IHRoZSBzZWxldGVkIEFDUCBjaGFubmVsIGVuY3J5cHRpb24g cHJvdG9jb2wuDQo+Pj4gDQo+Pj4gWWVzLCBhbmQgSSdkIGxpa2UgdGhlIExMIG11bHRpY2FzdCB0 cmFmZmljIHRvIGJlIHByb3RlY3RlZCB0b28uDQo+Pj4gQnV0IGFzIGZhciBhcyBJIGNhbiBzZWUg dGhhdCBuZWVkcyBleHBsaWNpdCBzdXBwb3J0IGluIHRoZSBBQ1ANCj4+PiB0byBlbXVsYXRlIExM IG11bHRpY2FzdCBzb2NrZXRzLiBUaGUgaWRlYWwgd291bGQgYmUgdGhhdCB0aGUgQUNQDQo+Pj4g c2ltcGx5IGVtdWxhdGVzIExMIGludGVyZmFjZXMsIHNvIHRoYXQgR1JBU1AgY291bGQgdHJlYXQg dGhlbSBleGFjdGx5DQo+Pj4gbGlrZSBwaHlzaWNhbCBpbnRlcmZhY2VzLg0KPj4+IA0KPj4+IElm IHlvdSB3YW50LCBJIGNhbiBwb2ludCB5b3UgdGhlIGV4YWN0IFB5dGhvbiBjb2RlIHRoYXQgaGFu ZGxlcyB0aGlzDQo+Pj4gaW4gdGhlIHByb3RvdHlwZS4NCj4+PiANCj4+Pj4gDQo+Pj4+Pj4gRG8g eW91IHNlZSBzb21lIElvVCBjb250ZXh0IHdoZXJlIHlvdSB3b3VsZCB1c2UgaW5zZWN1cmUgR1JB U1AgaW5zdGVhZCBvZiBETlMtU0QvbUROUywNCj4+Pj4+PiBlZzogaW4gc29tZSBJb1QgY29udGV4 dCA/DQo+Pj4+PiANCj4+Pj4+IE1pY2hhZWwgY2FuIGFuc3dlciB0aGF0IGZvciBoaW1zZWxmLCBi dXQgdGhlIHJlYXNvbiB3ZSBub3RlZCB0aGUgKnBvc3NpYmlsaXR5Kg0KPj4+Pj4gb2YgZG9pbmcg dGhpcyBpbiBncmFzcC0wOCBpcyBiZWNhdXNlIGl0IHNlZW1zIGNsZWFybHkgaGFybWxlc3MuIFNv IGZyb20gdGhlDQo+Pj4+PiBHUkFTUCBzcGVjIHBvaW50IG9mIHZpZXcsIEkgY29uc2lkZXIgdGhl IGlzc3VlIGNsb3NlZC4NCj4+Pj4gDQo+Pj4+IFVlcywgaSBhbSBtb3N0bHkgaW50ZXJlc3RlZCBp biB1c2UtY2FzZSBleHBsYW5hdGlvbnMgTWljaGFlbCBoYXMgaW4gbWluZC4NCj4+Pj4gDQo+Pj4+ IFRoZSBvdGhlciBwaWVjZSB3YXMgdGhhdCBNaWNoYWVsIHdhcyB0cnlpbmcgdG8gZmlndXJlIG91 dCBob3cgdG8gYXZvaWQgdXNpbmcgTEwgbXVsdGljYXN0DQo+Pj4+IGFuZCBpbnN0ZWFkIHVzZSB1 bmljYXN0Og0KPj4+PiANCj4+Pj4gLT4gV2l0aGluIHRoZSBBQ1AgdGhpcyBxdWVzdGlvbiBpcyBz b21ld2hhdCBpcnJlbGV2YW50IGJlY2F1c2UgaXRzIHNlY3VyZWQuDQo+Pj4+IA0KPj4+PiAtPiBH aXZlbiBob3cgQUNQIGludGVyZmFjZXMgYXJlIHAycCBzZWN1cmVkIGludGVyZmFjZXMgdG8gbmVp Z2Job3JzLCB5b3UNCj4+Pj4gICBjb3VsZCBrbm93IHVwZnJvbnQgdGhlIExMIElQdjYgYWRkcmVz cyBvZiB0aGUgbmVpZ2hib3Igb24gdGhlIGludGVyZmFjZSwNCj4+Pj4gICBidXQgdGhlcmUgaXMg cmVhbGx5IG5vIGZyYW1ld29yayBpbiBJRVRGIHByb3RvY29scyB0aGF0IGxldmVyYWdlcyB0aGlz DQo+Pj4+ICAgb3B0aW1pemF0aW9uIGZvciBwMnAgbGlua3MsIHNvIGkgZG9uJ3QgdGhpbmsgd2Ug c2hvdWxkIGJvdGhlciBkb2luZyBpdC4NCj4+Pj4gICBJdHMgd29yayB3aXRob3V0IFJvSS4NCj4+ Pj4gDQo+Pj4+IC0+IE91dHNpZGUgdGhlIEFDUCBpIGFtIG5vdCBzdXJlIGFib3V0IHRoZSB1c2Ut Y2FzZS4gVG8gYmUgb3B0aW9ucyBwcm9vZjogR1JBU1ANCj4+Pj4gICBzaG91bGQgcGVybWl0IHNl bmRpbmcgYW5kIHJlY2VpdmluZyBvZiBMTCBVTklDQVNUIGluc3RlYWQgb2YgTEwgbXVsdGljYXN0 IGZvcg0KPj4+PiAgIHRob3NlIG1lc3NhZ2VzIHdoZXJlIEdSQVNQIHNwZWNpZmllcyBMTCBtdWx0 aWNhc3QsIHNvIHRoYXQgaWYgc29tZSBkZXBsb3ltZW50DQo+Pj4+ICAgZmlndXJlcyBvdXQgdGhh dCB0aGVyZSBpcyBzb21lIG9wdGltaXphdGlvbiBwb3NzaWJsZSB3aXRoIHRoZSB1c2Ugb2YgTEwg dW5pY2FzdCwgDQo+Pj4+ICAgdGhlbiBpdCBjYW4gc2ltcGx5IGRvIHRoYXQgaW5zdGVhZCBvZiBh c2tpbmcgZm9yIGEgR1JBU1Agc3BlYyBtb2RpZmljYXRpb24uDQo+Pj4gDQo+Pj4gU3VyZS4gVGhh dCB3YXMgbXkgY29uY2x1c2lvbiAoZm9yIGRpc2NvdmVyeTsgaXQgbWFrZXMgbm8gc2Vuc2UgZm9y IGZsb29kaW5nKS4NCj4+PiANCj4+Pj4gICBUaGUgYmlnIHNlY3VyaXR5IHJpc2sgdGhvdWdoIGlz IEdMT0JBTCBVTklDQVNUIE1VU1QgTk9UIEJFIFBFUk1JVFRFRCANCj4+Pj4gICBhcyBhIHJlcGxh Y2VtZW50IGZvciBMTCBtdWx0aWNhc3QuIFRoYXRzIGFuIGF0dGFjayB2ZWN0b3IuIEFuZCB0eXBp Y2FsDQo+Pj4+ICAgc29ja2V0IHNvZnR3YXJlIGNvZGUgaXMgdXN1YWxseSB2aWN0aW0gdG8gdGhh dC4gQWthOiB5b3Ugb3BlbiBhIHNvY2tldCwNCj4+Pj4gICB5b3UgYmluZCBpdCB0byBhIGxpbmst bG9jYWwgbXVsdGljYXN0IGdyb3VwIGFuZCB5b3UgZ28gYXdheS4gQWxhczogdGhpcw0KPj4+PiAg IHNvY2tldCB3aWxsIHJlY2VpdmUgbm90IG9ubHkgbGluay1sb2NhbCBtdWx0aWNhc3QsIGJ1dCBh bHNvIExMIHVuaWNhc3QgKGdvb2QpDQo+Pj4+ICAgYW5kIGdsb2JhbCB1bmljYXN0IChiYWQpLiBT byB0aGUgYXBwbGljYXRpb24gY29kZSB1c3VhbGx5IHdvdWxkIG5lZWQgdG8gY2hlY2sNCj4+Pj4g ICB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyB0aGUgcGFja2V0IHdhcyBzZW50IHRvIGFuZCBkcm9w IHRob3NlIHBhY2tldHMgDQo+Pj4+ICAgc2VudCB0byB0aGUgZ2xvYmFsIHVuaWNhc3QgYWRkcmVz cyAtIGlmIHRoZSBwcm90b2NvbCB3YXMgcmVhbGx5IG9ubHkNCj4+Pj4gICBkZXNpZ25lZCBmb3Ig TEwgbXVsdGljYXN0IC0gYW5kIHRoZXJlZm9yZSBhc3N1bWluZyBzZWN1cml0eSBwcm9wZXJ0aWVz DQo+Pj4+ICAgb2YgTEwgbXVsdGljYXN0IChsb2dpY2FsIHZpY2luaXR5IG9mIHNlbmRlcikuDQo+ Pj4gDQo+Pj4gR1JBU1AgZGlzY292ZXJ5IGFuZCBmbG9vZCBhcmUgc3BlY2lmaWVkIGFzIGxpbmst bG9jYWwsIHNvIHllcywgdGhhdCBjaGVjaw0KPj4+IGlzIG5lZWRlZC4NCj4+PiANCj4+Pj4gICBB IGdvb2QgZXhhbXBlIGZvciByZXBsYWNpbmcgbXVsdGljYXN0IHdpdGggdW5pY2FzdCBpcyBXaUZJ IHdoZXJlIGx1Y2tpbHkNCj4+Pj4gICBob3N0cyBkbyBhY2NlcHQgbXVsdGljYXN0IHBhY2tldHMg YXMgTDIgdW5pY2FzdCBpbnN0ZWFkIG9mIEwyIG11bHRpY2FzdC4NCj4+Pj4gICBBbmQgdGhhdHMg ZG9uZSB0byBnZXQgdGhlIGJlbmVmaXQgb2YgTDIgcmV0cmFuc21pc3Npb25zLCB0aGF0IGRvIG5v dCBleGlzdA0KPj4+PiAgIGZvciBMMiBtdWx0aWNhc3QuDQo+Pj4gDQo+Pj4gQWNrLg0KPj4+ICBC cmlhbg0KDQo= From nobody Fri Nov 4 14:09:16 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BE312964F for ; Fri, 4 Nov 2016 14:09:14 -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 4p9LOto0m0nA for ; Fri, 4 Nov 2016 14:09:12 -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 760E7129579 for ; Fri, 4 Nov 2016 14:09:12 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id d2so57702530pfd.0 for ; Fri, 04 Nov 2016 14:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fejw4OhiiwOMLzmHGZB7u/v8SJ4Y4doBlQWWCdtQ43o=; b=fH8DPjrcNJDau0XC0IDr6YUadVeBaqW4H5+xcJiJ7Jgeh8cWGBKg53xgSvWBYDW40D YZFvkmbwXpdwPggIv3onDKZOnyYEz0fW4q/07h2HFjlMpFVdKy5R0jgN0p3VY8xnGSQ+ djKy2lum76eVL7V7JaqpwEuyoCZ6G7olu43mxr/mGzCL8e2EaCWtGyPXvwJJE2Ixpi6J KzilofYLmHGkwvSKye3J6QoDeSr8TL2PEJvBC5E6FVs1M+5H3bOI5p4WXysE+cUJz2G0 zHmCS4+XnFjNz6hmfqjTfz5lmZU8FLPDwUmU/2IqORsJch5CsDH2E0cLjJyTEA0cbOPS L13A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=fejw4OhiiwOMLzmHGZB7u/v8SJ4Y4doBlQWWCdtQ43o=; b=fRcakd4MjSSrHuuCUDd6V0tKcwNrPL5+7cyvoeVuhshiFQqaqhho9nQY1CIZ/woT0Q MEF9EpvcSizDQKwZTeuRlceqAItU/3JEgn5u31C0PY5uVn7XMVHhamYwS2ZuUDZ/4E9e XWX0sBVT65KfzvLBS0dCX3hZDm8xkCoEEExB8wG4q5QbsNtNiWJMdvrfYOOnmUPeQQhT 22/BJ6i/VKmDgr7COp7vBkPVlqoOsxAdHqRqto2SltHOXwgJOZZR6LzNPk5r8vtVp8xD /p5YBa0chdYRf0GLlb3C4HB+oJR2dhKj8RrqWXkh/Lpf3MaYpcXL9jMRYsqxfbw/dpZM yjJA== X-Gm-Message-State: ABUngvcLMczTYc3tz0mFJ2YzxH1QsfU2TFXgPVqKx4LBcjLJDaP0PLdFZFD/cvRPFCrXNQ== X-Received: by 10.98.160.140 with SMTP id p12mr29836733pfl.122.1478293751911; Fri, 04 Nov 2016 14:09:11 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id z3sm22479469paw.48.2016.11.04.14.09.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 14:09:11 -0700 (PDT) To: "Max Pritikin (pritikin)" , Toerless Eckert References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <0610AD70-3D43-4A83-BDBD-3CB8433DC3FA@cisco.com> <20161104004531.GF6498@faui40p.informatik.uni-erlangen.de> <695835EA-B186-4949-981E-84C5F2FDACF5@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 5 Nov 2016 10:09:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <695835EA-B186-4949-981E-84C5F2FDACF5@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 21:09:15 -0000 On 05/11/2016 09:54, Max Pritikin (pritikin) wrote: >=20 >=20 >> On Nov 3, 2016, at 6:45 PM, Toerless Eckert wrote: >> >> On Tue, Nov 01, 2016 at 10:42:32PM +0000, Max Pritikin (pritikin) wrot= e: >>> Taken to the extreme one could argue that we need ANI to be self-cont= ined so depending on IP seems wrong. >> >> Can you explain where you think ANI depends on IP in a fashion you >> ae calling "wrong=E2=80=9D ? >=20 > Sigh. Too much snark =E2=80=94 not enough information. >=20 > My point is that ANI will, of course, depend on things. It isn=E2=80=99= t a self contained re-envisionment of the entire concept of networking.=20 >=20 > Where those things are themselves reasonably bounded I don=E2=80=99t se= e the problem with using them. For example I could see an argument agains= t discussing DNS-SD because it is intended to span links and therefore =E2= =80=98depends=E2=80=99 on the DNS infrastructure. One could argue secure = GRASP provides that role within an ANI network and does so better (ie sec= urely).=20 >=20 > But mDNS is not dependent on that infrastructure. Instead it is a relat= ively self contained mechanism that doesn=E2=80=99t =E2=80=9Cstep on the = toes=E2=80=9D or duplicate things in the ANI infrastructure and it exists= and is used already. Yes. Which is why having non-autonomic nodes discover their BRSKI proxy b= y mDNS is a good idea. It isn't necessarily a good idea for ever, maybe a cheaper d= iscovery method will come along, but it's the best we have for now. > So creating too many options in that space is simply adding confusion. = Just like it=E2=80=99d be silly to suggest that ANI devices shouldn=E2=80=99t use IP. =2E..or shouldn't use GRASP discovery :-) Brian >=20 > - max >=20 >> >> Cheers >> Toerless >> >>> There is a point where ANI needs to depend and integrate with existin= g systems.=20 >>> >>> My position is that the demarcation point is bootstrapping of the key= ing infrastructure. Prior to bootstrapping we depend on generic mechanism= s and behaviors that any device might experience on a modern network. Pos= t keying we have sufficient methods to differentiate between ANI and all = that other stuff.=20 >>> >>> Another way of stating my position ???we need bootstrapping to be as = well contained as possible, so depending on GRASP seems wrong???. In trut= h of course the Proxy to Registrar communication benefits from GRASP so i= t is suggested there for ANI devices. This compromise integrates bootstra= pping with ANI in a way that provides value when ANI exists but doesn???t= depend on it for situations where it doesn???t exist.=20 >>> >>> - max >>> >>>> >>>>> >>>>>>> When GRASP is run securely in its two forms for the ACP, it is al= ways protected/ >>>>>>> encrypted by the ACP, so i think your security concern would then= not be valid. >>>>>> >>>>>> I'm still waiting to see a clear explanation of how the ACP will s= ecure >>>>>> LL multicast, however. >>>>> >>>>> I am not sure i understand the documentation ask. The ACP has a bun= ch of (virtual) interfaces. In >>>>> the most simple implementation option, each ACP channel to an ACP n= eighbor is its own >>>>> (p2p) L3 interface in the ACP. And thats all the interfaces the ACP= has. >>>> >>>> And that's the problem. GRASP discovery and flooding need sockets th= at >>>> supports link-local multicast sending and receiving for each physica= l >>>> interface. >>>> >>>> Currently the GRASP code finds out how many physical interfaces it h= as >>>> and for each one creates a multicast sending socket. It also has a s= ocket >>>> that listens for incoming link-local multicasts on all physical inte= rfaces. >>>> I don't see how to do that using the ACP interfaces that you describ= e. >>>> >>>>> All packets, unicast or multicast that are sent into or=20 >>>>> received from those interfaces are protected/encrypted by the fact = that they are transmitted >>>>> encrypted by the seleted ACP channel encryption protocol. >>>> >>>> Yes, and I'd like the LL multicast traffic to be protected too. >>>> But as far as I can see that needs explicit support in the ACP >>>> to emulate LL multicast sockets. The ideal would be that the ACP >>>> simply emulates LL interfaces, so that GRASP could treat them exactl= y >>>> like physical interfaces. >>>> >>>> If you want, I can point you the exact Python code that handles this= >>>> in the prototype. >>>> >>>>> >>>>>>> Do you see some IoT context where you would use insecure GRASP in= stead of DNS-SD/mDNS, >>>>>>> eg: in some IoT context ? >>>>>> >>>>>> Michael can answer that for himself, but the reason we noted the *= possibility* >>>>>> of doing this in grasp-08 is because it seems clearly harmless. So= from the >>>>>> GRASP spec point of view, I consider the issue closed. >>>>> >>>>> Ues, i am mostly interested in use-case explanations Michael has in= mind. >>>>> >>>>> The other piece was that Michael was trying to figure out how to av= oid using LL multicast >>>>> and instead use unicast: >>>>> >>>>> -> Within the ACP this question is somewhat irrelevant because its = secured. >>>>> >>>>> -> Given how ACP interfaces are p2p secured interfaces to neigbhors= , you >>>>> could know upfront the LL IPv6 address of the neighbor on the int= erface, >>>>> but there is really no framework in IETF protocols that leverages= this >>>>> optimization for p2p links, so i don't think we should bother doi= ng it. >>>>> Its work without RoI. >>>>> >>>>> -> Outside the ACP i am not sure about the use-case. To be options = proof: GRASP >>>>> should permit sending and receiving of LL UNICAST instead of LL m= ulticast for >>>>> those messages where GRASP specifies LL multicast, so that if som= e deployment >>>>> figures out that there is some optimization possible with the use= of LL unicast,=20 >>>>> then it can simply do that instead of asking for a GRASP spec mod= ification. >>>> >>>> Sure. That was my conclusion (for discovery; it makes no sense for f= looding). >>>> >>>>> The big security risk though is GLOBAL UNICAST MUST NOT BE PERMIT= TED=20 >>>>> as a replacement for LL multicast. Thats an attack vector. And ty= pical >>>>> socket software code is usually victim to that. Aka: you open a s= ocket, >>>>> you bind it to a link-local multicast group and you go away. Alas= : this >>>>> socket will receive not only link-local multicast, but also LL un= icast (good) >>>>> and global unicast (bad). So the application code usually would n= eed to check >>>>> the destination address the packet was sent to and drop those pac= kets=20 >>>>> sent to the global unicast address - if the protocol was really o= nly >>>>> designed for LL multicast - and therefore assuming security prope= rties >>>>> of LL multicast (logical vicinity of sender). >>>> >>>> GRASP discovery and flood are specified as link-local, so yes, that = check >>>> is needed. >>>> >>>>> A good exampe for replacing multicast with unicast is WiFI where = luckily >>>>> hosts do accept multicast packets as L2 unicast instead of L2 mul= ticast. >>>>> And thats done to get the benefit of L2 retransmissions, that do = not exist >>>>> for L2 multicast. >>>> >>>> Ack. >>>> Brian >=20 From nobody Fri Nov 4 14:23:23 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BC61296BD for ; Fri, 4 Nov 2016 14:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 0wPxyYQQcF17 for ; Fri, 4 Nov 2016 14:23:20 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203191294DB for ; Fri, 4 Nov 2016 14:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10506; q=dns/txt; s=iport; t=1478294597; x=1479504197; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dJ29/KqB4NP8WhEC6WZizsId5YpWmCdSx8jQ9Upmkqw=; b=mdkOamU1OYfT8cXQJEaIN+GOKcoRiU6JZMWwfXxWjHaoIW5D0udEd98a LTff2I2Rp66O3m6XtYJWJPF0mH7P+rEF5wm6yPy/WvDHMxnAQSlxD3IgE +yw2iIlk2X6JYoBQWUyQpKmqbe93RngQbcRpoYwLXwrCPIu//SXEhSc3Q 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQAw+xxY/5FdJa1TCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMuAQEBAQEfgVQHjTGXAJRGggiGIwIagX4/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEDASMRRQULAgEIGAICJgICAjAVEAIEDgWIUAivHox5AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR6BCYczgVOBBYQgDQYUgwQtgi8FmiMBhUuDL4dFkAqEeYgohAMBHjd?= =?us-ascii?q?sg1yBRXKFCYEvgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,445,1473120000"; d="scan'208";a="344243267" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 21:23:16 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA4LNG2l029806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 21:23:16 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 16:23: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.1210.000; Fri, 4 Nov 2016 16:23:15 -0500 From: "Max Pritikin (pritikin)" To: Toerless Eckert Thread-Topic: Desaster recover... (was: Re: [Anima] [homenet] write up of time without clocks) Thread-Index: AQHSNhKH12OcT6VTAUqgY6dYwye4haDJqvoA Date: Fri, 4 Nov 2016 21:23:15 +0000 Message-ID: <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> 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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Eliot Lear , Anima WG Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 21:23:22 -0000 VGhlcmUgaXMgYSBsb3QgaGVyZS4gQXR0ZW1wdGluZyB0byBjb21tZW50IG9uIGl0IGFsbC4gDQoN Ckl0IHdvdWxkIHJlYWxseSBoZWxwIGlmIHdlIGNvdWxkIHJlbGF0ZSB0aGVzZSBkaXNjdXNzaW9u cyB0byBzcGVjaWZpYyB0ZXh0IHNlY3Rpb25zIHRoYXQgY291bGQgYmUgaW1wcm92ZWQuIE90aGVy d2lzZSB3ZeKAmXJlIGp1c3QgYmxvd2luZyBpbnRvIHRoZSB3aW5kLiAoV2hlcmUgaXQgc2VlbXMg b2J2aW91cyBJ4oCZdmUgYWRkZWQgc3VjaCBub3RlcykuIA0KDQo+IE9uIE5vdiAzLCAyMDE2LCBh dCAyOjQwIFBNLCBUb2VybGVzcyBFY2tlcnQgPHR0ZStpZXRmQGNzLmZhdS5kZT4gd3JvdGU6DQo+ IA0KPiBJTUhPLCBnZWFyIHJlcGxhY2VtZW50IGFmdGVyIGxhcmdlIG91dGFnZXMgaXMgcXVpdGUg cmVsZXZhbnQ6DQo+IA0KPiBJIGhhdmUgc2VlbiBlcXVpcG1lbnQgYmVjb21lIHVudXNhYmxlIGFm dGVyIGJhZA0KPiBwb3dlciBzaXR1YXRpb25zIChzcGlrZSwgYnJvd25vdXQsIGVsZWN0cmljYWwg c3Rvcm1zLC4uKSBiZWNhdXNlIG9mDQo+IGVsLWNoZWFwbyBwb3dlciBzdXBwbHkvY2lyY3VpdHJ5 IGFzIHdlbGwgYXMgd2lyZWQgaW50ZXJmYWNlDQo+IGNpcmN1aXRyeS9wcm90ZWN0aW9uLiBDZXJ0 aWZpY2F0aW9ucyBpbiBUZWxjby9Jb1QgbWFrZSB0aGF0IHR5cGUgb2YgZ2Vhcg0KPiBvZnRlbiBi ZXR0ZXIsIGJ1dCB0aG9zZSBjZXJ0aWZjYXRpb25zIGFyZSBhIHpvby4NCj4gDQo+IC0gTGFyZ2Ug b3JnYW5pemF0aW9ucyB3aWxsIGhhdmUgc3BhcmVzLiBXaXRoIEFOSU1BLCB0aG9zZSBzcGFyZXMg c2hvdWxkDQo+ICBiZSBzdG9yZWQgcHJlLWVucm9sbGVkIHRvIGF2b2lkIE1BU0EvcmVnaXN0cmFy IGRlcGVuZGVuY3kgZHVyaW5nDQo+ICByZWNvdmVyeS9yZXBsYWNlbWVudHM6IFJlY2VpdmUgZ2Vh ciBvbiBhbnkgc2l0ZSAobm8gY2VudHJhbCBwcm92aXNpb25pbmcNCj4gIHNpdGUgbmVlZGVkKSwg YnV0IHVucGFjaywgcGx1ZyBpbiBmb3Igc2hvcnQgcGVyaW9kLCB0aGVuIHN0YXNoIGF3YXkuDQoN CkRldmljZXMgdGhhdCBoYXZlIGJlZW4gYnJvdWdodCB1cCBhbmQgYXJlIGluIHRoZSBuZXR3b3Jr IHBvc3QgYm9vdHN0cmFwIGFyZSBub3QgcmVsZXZhbnQgdG8gdGhlIEJSU0tJIGRvY3VtZW50LiAN Cg0KPiAgVGhpcyBpcyBpbW8gYW4gZWFzeSByZXF1aXJlbWVudCBhbHNvIHVzZWZ1bCB3aXRob3V0 IGRlc2FzdGVyIHJlcXVpcmVtZW50cw0KPiAgLSBha2E6IGVucm9sbGVkIHNwYXJlcyB3b3VsZCBs aWtlbHkgYWxzbyBoYXZlIGJldHRlciB0aGVmdC9hYnVzZSBwcm90ZWN0aW9uDQo+ICB0aGFuIG5v bi1lbnJvbGxlZC4gQW5kIHllcywgeW91IHdpbGwgaGF2ZSB0byBwb3dlciB1cCB0aGVzZSBzcGFy ZXMNCj4gIG9uY2UgYSB5ZWFyLiBXaGljaCBJTUhPIGlzIG9rLiBBbmQgb2YgY291cnNlIGNlcnRz IHNob3VsZCB0aGVyZWZvcmUNCj4gIGJlIHNvbWV3aGF0IGxvbmdlciB0aGFuIDEgeWVhcikuDQoN ClRoaXMgY291bGQgYmUgY2FwdHVyZWQgYXMgYSBkaXNjdXNzaW9uOiB3aGF0IGRvZXMgYSBkZXZp Y2UgZG8gd2hlbiBpdHMgY3JlZGVudGlhbHMgYXJlIG91dCBvZiBkYXRlPyBEb2VzIGl0IGZhbGwg YmFjayBvbiBmdWxsIGJvb3RzdHJhcHBpbmc/IElmIHNvIHRoaXMgYmVjb21lcyBhIHBvdGVudGlh bCBhdHRhY2sgdmVjdG9yIHdoZXJlaW4gdGhlIGF0dGFja2VyIGNhbiBjb252aW5jZSB0aGUgZGV2 aWNlIGl0IGlzIG91dCBvZiBkYXRlIGFuZCB0aGVuIGZvcmNlIGl0IHRvIHJlc3RhcnQgYm9vdHN0 cmFwcGluZy4gVGhhdCB3b3VsZCBiZSBiYWQuIA0KDQpTbywgc2hvdWxkIHRoZXJlIGJlIGFuIGlu amVjdGlvbiBwb2ludCBpbnRvIHRoZSBib290c3RyYXBwaW5nIHN0YXRlIG1hY2hpbmUgdGhhdCBz YXlzIHNvbWV0aGluZyBsaWtlOg0KDQpJZiBhIGRldmljZSBmYWlscyB0byBqb2luIHRoZSBBTkkg YWZ0ZXIgW3NvbWUgbnVtYmVyXSBvZiBhdHRlbXB0cyBpdCBhdHRlbXB0cyB0byByZXBlYXQgYm9v dHN0cmFwcGluZyB1c2luZyBpdHMgb3JpZ2luYWwgU1VESSBjcmVkZW50aWFscy4gRHVyaW5nIHRo aXMgYm9vdHN0cmFwcGluZyBhdHRlbXB0IGl0IE1VU1Qgb25seSBib290c3RyYXAgb24gYSBSZWdp c3RyYXIgdGhhdCBwcm92aWRlcyBib3RoIGEgdmFsaWQgdm91Y2hlciBhbmQgYW4gaWRlbnRpdHkg cmVjb2duaXphYmx5IHdpdGhpbiB0aGUgc2FtZSBQS0kgaGllcmFyY2h5IHRoZSBkZXZpY2Ugd2Fz IGluIHByZXZpb3VzbHkuIFRoaXMgaXMgZGV0ZWN0ZWQgYnkgdGhlIGRldmljZSBieSBlaXRoZXIg KGEpIHRoZSBkb21haW5DQWNlcnQgaXMgYW4gZXhhY3QgbWF0Y2ggZm9yIHRoZSBjdXJyZW50IGRv bWFpbiB0cnVzdCBhbmNob3Iga25vd24gdG8gdGhlIGRldmljZSBvciAoYikgdGhlIEVTVCAvY2Fj ZXJ0cyByZXNwb25zZSBpbmNsdWRlcyBhIGNoYWluIHRoYXQgdGVybWluYXRlcyBpbiB0aGUgY3Vy cmVudCBkb21haW4gdHJ1c3QgYW5jaG9yIGtub3duIHRvIHRoZSBkZXZpY2UuICANCg0KVGhpcyBl eHRlbmRzIHRoZSBsaWZldGltZSBvZiBzdWNoIGEgc3RvcmVkIGRldmljZSBiZXlvbmQgaXRzIG93 biBjZXJ0aWZpY2F0ZSAobWF5YmUgMSB5ZWFyKSAqYW5kKiBiZXlvbmQgdGhlIGN1cnJlbnQgQ0Eg Y2VydGlmaWNhdGUgKG1heWJlIGEgMnllYXIgY2VydCkgYW4gYWxsIHRoZSB3YXkgaW50byB0aGUg bmV4dCBDQSBjZXJ0aWZpY2F0ZSAoYW5vdGhlciAyIHllYXJzKS4gVGhhdCBpcyBhIHByZXR0eSBz b2xpZCBsaWZldGltZSAodXAgdG8gNCB5ZWFycykgZm9yIHJlY292ZXJ5Lg0KDQo+IC0gSWYgc3Bh cmluZyB3b3VsZCBiZSBjcm9zcy1sb2NhdGlvbnMgKGVnOiBzcGFyZXMgc2VudCBmcm9tIHNvbWUg c2l0ZSB0bw0KPiAgb3RoZXIgc2l0ZXMgZHVyaW5nIHJlY292ZXJ5KSwgdGhlbiBpdHMgaW1wb3J0 YW50IHRoYXQgdGhlIEFOSU1BIGNlcnRzIGRvDQo+ICBub3QgaW5jbHVkZSBhbnkgbG9jYXRpb24g c3BlY2lmaWMgYXR0cmlidXRlcyB0aGF0IHdvdWxkIHByb2hpYml0IHRoYXJ0DQo+ICBtb3ZlbWVu dC4gU28gZmFyIEJSU0tZIGRvZXMgbm90IGluY2x1ZGUgYW55IHN1Y2ggYXR0cmlidXRlcywgYnV0 IGluDQo+ICBkaXNjdXNzaW9ucywgdGhyZWUgaGFzIGJlZW4gaW50ZXJlc3QgdG8gbG9jayBpbnRv IHRoZSBjZXJ0IHNvbWUgZGV2aWNlDQo+ICByb2xlIHNwZWNpZmljIGF0dHJpYnV0ZXMsIGFuZCBm b3IgYSBzcGFyZSBwaWVjY2Ugb2YgZXF1aXBtZW50LCB0aG9zZQ0KPiAgYXR0cmlidXRlcyBtYXkg bm90IGJlIHByZWRldGVybWluZWQuDQo+IA0KPiAgQWthOiBEZXNhc3RlciBzcGFyaW5nIG1lYW5z IGRvbWFpbiBjZXJ0cyBuZWVkIHRvIGJlIHNpbXBsZSwgZGV2aWNlcw0KPiAgcmV1c2VhYmxlIGFj cm9zcyBkb21haW4uDQoNCkkgYWdyZWUgdGhhdCBjZXJ0cyBzaG91bGQgaW5jbHVkZSB0aGUgYWJz b2x1dGUgbWluaW11bSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZGV2aWNlLiBUaGUgYWN0dWFsIElE IGlzIHN1ZmZpY2llbnQgaW4gbXkgYm9vay4gQXR0cmlidXRlIENlcnRzIG9yIGJhY2tlbmQgZGF0 YWJhc2UgbG9va3VwcyBvciBzaG9ydCB0ZXJtIHRva2VucyBvYnRhaW5lZCBieSB0aGUgZGV2aWNl IGluIHBsYWNlIGFyZSBhbGwgbWV0aG9kcyBvZiBkaXN0cmlidXRpbmcgYWRkaXRpb25hbCBpbmZv cm1hdGlvbi4gDQoNCj4gLSBJZiBzcGFyZXMgYXJlIGRvbmUgYnkgYSBzaGFyZWQgZmFjaWxpdHk6 IHZlbmRvciwgRkVNTyAoZm9yIGZlZCBuZXR3b3JrcykNCj4gIG9yIHRoZSBsaWtlLCBvbmUgY291 bGQgdGhpbmsgb2YgdGhhdCBlbnRpdHkgb2ZmZXJpbmcgKGVtZXJnZW5jeSkNCj4gIGVucm9sbWVu dCBzZXJ2aWNlLg0KPiANCj4gIFN1Y2ggYW4gZW50aXR5IHdvdWxkIGhhdmUgZGVzYXN0ZXIgcHJv b2YgTUFTQSBjb25uZWN0aXZpdHkgb24gc2l0ZSwNCj4gIGFuZCB0aGUgY3VzdG9tZXJzIHdvdWxk IHByb3ZpZGUgaXQgd2l0aCAoZW1lcmdlbmN5KSByZWdpc3RyYXIgY2VydHMuDQoNCk9rLiBTbyBs aWtlIGEgQ2lzY28gTkVSViB0cnVjayB0aGF0IHByb3ZpZGVzIGNvbm5lY3Rpdml0eSBzdWZmaWNp ZW50IHRvIHJlYnVpbGQgYSBuZXR3b3JrIGluIHBsYWNlLiANCg0KSXNzdWluZyBhIG5ldyBSZWdp c3RyYXIgSUQgd291bGQgbWVhbiBiZWluZyBhYmxlIHRvIGJyaW5nIHVwIHRoZSBQS0kgaW5mcmFz dHJ1Y3R1cmUgZHVyaW5nIHRoZSByZWNvdmVyeSBwcm9jZXNzLiBCdXQgdGhpcyBpcyBleGFjdGx5 IHRoZSB0aW1lIHBlcmlvZCB3aGVuIGhhdmluZyBhcyBtdWNoIG9mIHRoZSBjcml0aWNhbCBrZXlp bmcgaW5mcmFzdHJ1Y3R1cmUgb2ZmbGluZSBhbmQgc2VjdXJlZCBjb3VsZCBiZSBiZW5lZmljaWFs IGZvciBsb25ndGVybSBzZWN1cml0eS4gT25lIGNvdWxkIGFyZ3VlIHRoYXQgZXh0cmEgYXR0ZW1w dHMgc2hvdWxkIGJlIG1hZGUgdG8gZW5zdXJlIHRoZSBQS0kgaXMgb2ZmbGluZS4gDQoNCj4gIChl bWVyZ2VuY3kpIG1lYW5pbmcgdGhhdCB0aGUgZW50aXR5IGlzIG9ubHkgcGVybWl0dGVkIHRvIGVu cm9sIGR1cmluZw0KPiAgZW1lcmdlbmNpZXMsIGFuZCB0aGUgY3VzdG9tZXIgY291bGQgYmUgYWJs ZSB0byB2ZXJpZnkgdGhlIGVtZXJnZW5jeQ0KPiAgZW50aXRpZXMgYmVoYXZpb3IgYnkgcHVsbGlu ZyBmcm9tIHRoZSBNQVNBIGFuIGF1ZGl0IGxvZy4NCg0KU2VjdGlvbiA1LjYgZG9lc27igJl0IGlu Y2x1ZGUgdGhlIFJlZ2lzdHJhciBpZGVudGl0eSBvbmx5IHRoZSBkb21haW5JRCBpbiB0aGUgbG9n LiBEbyBmb2xrcyB0aGluayB0aGUgUmVnaXN0cmFyIElEIHNob3VsZCBiZSBpbmNsdWRlZCBhcyB3 ZWxsPw0KDQpJZiB0aGlzIHdhcyBkb25lIHRoZW4gZG9lcyBpdCBtYXR0ZXIgaWYgdGhlIFJlZ2lz dHJhciBjZXJ0IGhhcyByb2xlIGluZm9ybWF0aW9uIGluIGl0PyBBcyBwZXIgdGhlIGFib3ZlIHdo YXQgd291bGQgaGFwcGVuIGlmIGFsbCBkZXZpY2VzIGluIHRoZSBBTkkgY291bGQgYWN0IGFzIGEg cmVnaXN0cmFyPyBUaGVyZSB3b3VsZCBiZSBhIGhpZ2hlciBjaGFuY2UgdGhhdCBvbmUgb2YgdGhl bSB3b3VsZCBtZXNzIHVwIGFuZCBhY3R1YWxseSBwZXJmb3JtIHJlZ2lzdHJhciBhY3Rpdml0aWVz IGluY29ycmVjdGx5IOKAlCBidXQgaXQgd291bGQgYmUgbG9nZ2VkIHNvIHRoZSBhZG1pbiBjb3Vs ZCB3YXRjaCBmb3IgdGhhdC4NCg0KVGhvdWdodHM/IEnigJltIHdvcnJpZWQgYnV0IHNlZSB0aGUg Y29udmVyc2F0aW9uIGdvaW5nIHRoYXQgd2F5Lg0KDQo+ICBJZiB0aGUgY3VzdG9tZXIgd291bGQg Z2l2ZSB0aGUgZW1lcmdlbnkgcmVnaXN0cmFyIGNyZWRlbnRpYWxzDQo+ICBjZXJ0L3ByaXZhdGUv cHVibGljLWtleSB0byB0aGUgZW1lcmdlbnkgZW50aXRpZXMsIHRoZW4gdGhlIGN1c3RvbWVyDQo+ ICBpdHNlbGYgYWxzbyBoYXMgdGhlIGNlcnQvcHJpdmF0ZS1rZXkgYW5kIGNvdWxkIGFzayB0aGUg TUFTQS4NCj4gIFRoaXMgb3B0aW9uIHdvdWxkIHdvcmsgd2l0aCBjdXJyZW50IEJSU0tZIHRleHQu IEkgYW0ganVzdCBub3Qgc3VyZQ0KPiAgYWJvdXQgc2VjdXJpdHkgQkNQIChoYXZpbmcgdHdvIGNv cGllcyBvZiBhIHB1YmxpYyBrZXkgcGFpcuKApikuDQoNClNvcnJ5IC0gSSBjYW7igJl0IHdyaXRl IHRleHQgYXJvdW5kIGNvcHlpbmcgYSBwcml2YXRlIGtleS4gSWYgd2XigJlyZSBnb2luZyB0aGF0 IHJvdXRlIGxldHMgZHVtcCBhbGwgdGhlIFBLSSBzdHVmZiBhbmQganVzdCB1c2UgYmVhcmVyIHRv a2VucyBhbmQgYmUgdXAgZnJvbnQgYWJvdXQgdGhlIHNlY3VyaXR5IHdl4oCZcmUgcHJvdmlkaW5n LiBTZWUgYWJvdmUgZm9yIGRpZmZlcmVudCBpZGVhcy4gDQoNCj4gLSBJZiB0aGUgc2hhcmVkIHNw YXJlIHN0b3JhZ2UgZmFjaWxpdHkgaXMgQmVzdCBCdXksIGFuZCB0aGUgSm9uZXMNCj4gIGZhbWls eSB3YW50cyB0byByZXBsYWNlIHNvbWUgZWxlY3RyaWMgc3Rvcm0gdmljdGltcyBAaG9tZSB3aGls ZQ0KPiAgdGhlaXIgSVNQIHRha2VzIGl0cyBkYXlzIChteSBJU1AgQyouLi4qVCB0b29rIGFsbW9z dCA0OCBob3VycyBpbiBvbmUgY2FzZSksDQo+ICB0aGVuIHRoZSBnZWFyIHNob3VsZCBwcm9iYWJs eSBjb21lIHdpdGggYSBub25jZWxlc3Mgdm91Y2hlcg0KPiAgcHJpbnRlZCBvbiBvbiBhIHNjcmF0 Y2hlciBwaWVjZSBvZiBwYXBlciBpbnNpZGUgdGhlIGJveC4NCg0KRXZlbiBhIG5vbmNlbGVzcyB2 b3VjaGVyIGluY2x1ZGVzIHRoZSBkb21haW5DQWNlcnQgc28gdGhpcyBpZGVhIGRvZXNu4oCZdCBm bHkgd2l0aCB0aGUgY3VycmVudCB0ZXh0LiBXaGF0IHlvdeKAmXJlIGxvb2tpbmcgZm9yIGlzIHNv bWUgZm9ybSBvZiDigJxiZWFyZXIgdm91Y2hlcuKAnSB0aGF0IGNvbnRhaW5zIGEgc3ltbWV0cmlj IGtleS4gQW55Ym9keSB3aG8gY2FuIHNjYW4gaXQgb2ZmIHRoZSBib3ggY2FuIGRlcGxveSB0aGUg ZGV2aWNlLiANCg0KSeKAmWQgbm9ybWFsbHkgcmFpbCBhZ2FpbnN0IHRoaXMgYnV0IGFtIGFjdHVh bGx5IHBsZWFzZWQgdG8gc2VlIGl0IGZpdCBzbyB3ZWxsIGludG8gdGhlIG1vZGVsLiBBIGJlYXJl ciB2b3VjaGVyIHNvcnRhIHN1Y2tzIGJ1dCBjcmVhdGluZyBvbmUgZGlkbuKAmXQgY2hhbmdlIGFu eSBvZiBvdXIgbWVzc2FnaW5nIGZsb3cgb3IgYW55dGhpbmcuIEludGVyZXN0aW5nIHBvc2l0aXZl IHRoYXTigKYgDQoNCknigJltIHRoaW5raW5nIHRoYXQgaXQgaXMgdGltZSBmb3IgYSBzZWN0aW9u IDMuNyDigJxWb3VjaGVyIHR5cGVz4oCdIHRoYXQgZGlncyBpbnRvIHdoYXQgd2XigJlyZSB0YWxr aW5nIGFib3V0IGZvciB0aGVzZSBkaWZmZXJlbnQgdm91Y2hlciB0eXBlcy4gQ3VycmVudGx5IHRo ZSB0ZXh0IGlzIHNjYXR0ZXJlZCBpbiB0aGUgb3RoZXIgc2VjdGlvbnMuIA0KDQotIG1heA0KDQo+ IEJleW9uZCB0aGVzZSBCUlNLWSBjb25zaWRlcmF0aW9ucywgdGhlIG5leHQgY29vbCBBTklNQSBw aWVjZSB0byBjb25zaWRlcg0KPiBmb3IgdGhlc2UgdXNlLWNhc2VzIGlzIG9mIGNvdXJzZSB0aGUg QVNBIGRyaXZlbiAicmUtY29uZmlndXJhdGlvbiIgb2YgdGhlDQo+IHNwYXJlIGRldmljZSwgYWth OiBJbiBsYXJnZXIgb3V0YWdlcywgeW91IHNob3VsZCBub3QgZXhjZXB0IHRoZSB3aG9sZQ0KPiBu ZXR3b3JrIHByb3Zpc2lvbmluZyBiYWNrZW5kIHRvIGJlIHVwIGFuZCBydW5uaW5nLiBBbmQgaXRz IElNSE8NCj4gaWxsdXNpb25hcnkgdG8gZXhwZWN0IGRldmljZXMgdG8gT05MWSBiZSBkcml2ZW4g ZnJvbSBpbnRlbnQgZm9yIG1hbnkNCj4geWVhcnMgKGluIGNvbXBsZXggbmV0d29ya3MuLi4gaW4g YSBjbGVhbiBob21lbmV0IHRoZXkgYXJlIGRyaXZlbiBieQ0KPiBpbnRlbnQgdG9kYXkuLikuIA0K PiANCj4gQWthOiBmb3IgcHJlLWludGVudC1vbmx5IGRlc2FzdGVyIHByb29mIG5ldHdvcmtzLCB3 ZSdkIG5lZWQ6DQo+ICAtIEFTQSB0byBjYWNoZSBuZWlnaGJvcnMgY29uZmlncy4NCj4gIC0gcmVh cHBseSBuZWlnaGJvciBzdG9yZWQgY29uZmlnIHdoZW4gcmVwbGFjZW1lbnQgZ2VhciBpcyBpbnNl cnRlZC4NCj4gIC0gSU1ITzogQW4gYW5pbWEgZGVmaW5pdGlvbiBmb3IgYSAiZGV2aWNlLXJvbGUt aWQiIHdoaWNoIGlzIG5vdA0KPiAgICB0aGUgQUNQIElQdjYgYWRkcmVzcyAod2hpY2ggd2lsbCBj aGFuZ2UgdXBvbiBnZWFyIHJlcGxhY2VtZW50DQo+ICAgIHdpdGhvdXQgZW5yb2xtZW50IHN1cHBv cnQpLg0KPiANCj4gQ2hlZXJzDQo+ICAgIHRvZXJsZXNzDQoNCg== From nobody Sun Nov 6 22:01:45 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B73129C32 for ; Sun, 6 Nov 2016 22:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 6Aeu7SisSM62 for ; Sun, 6 Nov 2016 22:01:40 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54113129C31 for ; Sun, 6 Nov 2016 22:01:40 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4F3C958C4BC; Mon, 7 Nov 2016 07:01:38 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 36383B0AD53; Mon, 7 Nov 2016 07:01:38 +0100 (CET) Date: Mon, 7 Nov 2016 07:01:38 +0100 From: Toerless Eckert To: "Max Pritikin (pritikin)" Message-ID: <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Toerless Eckert , Eliot Lear , Anima WG Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 06:01:43 -0000 On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) wrote: > There is a lot here. Attempting to comment on it all. > > It would really help if we could relate these discussions to specific text sections that could be improved. Otherwise we???re just blowing into the wind. (Where it seems obvious I???ve added such notes). Sure, but lets high level agree what type of content is useful and where it would fit. > > - Large organizations will have spares. With ANIMA, those spares should > > be stored pre-enrolled to avoid MASA/registrar dependency during > > recovery/replacements: Receive gear on any site (no central provisioning > > site needed), but unpack, plug in for short period, then stash away. > > Devices that have been brought up and are in the network post bootstrap are not relevant to the BRSKI document. To me the most important goal should be to provide candidate users with deployment guidance. This should fit ANIMA goals given how its an OPS group. Lets say we have two options: a) keep spares unenrolled, enrol during desaster recovery with satellite link b) enrol spare devices when they are stocked, deploy during desaster. lets assume we agree both are relevant deployment options that users should understand, compare pro/cons for their case and choose. If you think we can not mention both in the BRSKY spec, then i think it would be better to have a separate document where both could be discussed. > > This is imo an easy requirement also useful without desaster requirements > > - aka: enrolled spares would likely also have better theft/abuse protection > > than non-enrolled. And yes, you will have to power up these spares > > once a year. Which IMHO is ok. And of course certs should therefore > > be somewhat longer than 1 year). > > This could be captured as a discussion: what does a device do when its credentials are out of date? Does it fall back on full bootstrapping? If so this becomes a potential attack vector wherein the attacker can convince the device it is out of date and then force it to restart bootstrapping. That would be bad. Haha... ;-) i just wanted to show what IMHO are the most simple deployment options to deal with desaster recover. Now you're the one who is opening another round of discussions trying to figure out the best security compromise for those deployment processes. Which is great. Just don't blame me that there are more and more interesting details to capture somewhere. > So, should there be an injection point into the bootstrapping state machine that says something like: > > If a device fails to join the ANI after [some number] of attempts it attempts to repeat bootstrapping using its original SUDI credentials. I'd prepare a flag 'operational' set by SDN controller or ASA after the device is "provisioned" (config/intent applied). > During this bootstrapping attempt it MUST only bootstrap on a Registrar that provides both a valid voucher and an identity recognizably within the same PKI hierarchy the device was in previously. This is detected by the device by either (a) the domainCAcert is an exact match for the current domain trust anchor known to the device or (b) the EST /cacerts response includes a chain that terminates in the current domain trust anchor known to the device. > > This extends the lifetime of such a stored device beyond its own certificate (maybe 1 year) *and* beyond the current CA certificate (maybe a 2year cert) an all the way into the next CA certificate (another 2 years). That is a pretty solid lifetime (up to 4 years) for recovery. Interesting thought. a) Would like to understand how this compares to just making certs longer-lived, eg: 3 years, but doing normal renewal after 30% time. b) Seem like there's quite a bit of analysis to be done of how different parameter/options will work together: - device with/without reliable RTC - what would be necessary/beneficial with nonce-less vouchers ? how about nonceless vouchers with sequence number... -> remember ownership voucher and allow for it to be replaced only with one that hass a higher serial number. > > - If sparing would be cross-locations (eg: spares sent from some site to > > other sites during recovery), then its important that the ANIMA certs do > > not include any location specific attributes that would prohibit thart > > movement. So far BRSKY does not include any such attributes, but in > > discussions, three has been interest to lock into the cert some device > > role specific attributes, and for a spare piecce of equipment, those > > attributes may not be predetermined. > > > > Aka: Desaster sparing means domain certs need to be simple, devices > > reuseable across domain. > > I agree that certs should include the absolute minimum information about the device. The actual ID is sufficient in my book. Attribute Certs or backend database lookups or short term tokens obtained by the device in place are all methods of distributing additional information. Desaster recovery seems to be one good motivation to not put more than the minimum into the certs. I was a fan of putting more into certs in the past... > > - If spares are done by a shared facility: vendor, FEMO (for fed networks) > > or the like, one could think of that entity offering (emergency) > > enrolment service. > > > > Such an entity would have desaster proof MASA connectivity on site, > > and the customers would provide it with (emergency) registrar certs. > > Ok. So like a Cisco NERV truck that provides connectivity sufficient to rebuild a network in place. > > Issuing a new Registrar ID would mean being able to bring up the PKI infrastructure during the recovery process. But this is exactly the time period when having as much of the critical keying infrastructure offline and secured could be beneficial for longterm security. One could argue that extra attempts should be made to ensure the PKI is offline. My thought was a) the desaster recovery registrar-IDs are preprovisioned _before_ desaster (contract between domain and desaster/spare recovery entity). b) The facility to which they are allocated is shared across multiple domains. c) the facility is not "desaster on-site" -> the spares will not be on-site, but will be stored at some central site. Enrollment would happen at that central site, then they'd be shipped onto-desaster-site. > > (emergency) meaning that the entity is only permitted to enrol during > > emergencies, and the customer could be able to verify the emergency > > entities behavior by pulling from the MASA an audit log. > > Section 5.6 doesn???t include the Registrar identity only the domainID in the log. Do folks think the Registrar ID should be included as well? Oh, right. i confused domain-id with registrar-ID. I definitely think registrar-ID would be necessary to log so that audit-logs become more useful to backtrack what happened. > If this was done then does it matter if the Registrar cert has role information in it? As per the above what would happen if all devices in the ANI could act as a registrar? There would be a higher chance that one of them would mess up and actually perform registrar activities incorrectly ??? but it would be logged so the admin could watch for that. I don't think we need many/all devices to be registrars. I don't think we've got a working security model to do this anyhow - eg: authenticating all those devices against the CA. I hope we do not need to discuss other roles beside "registrar" in this context. > Thoughts? I???m worried but see the conversation going that way. > > If the customer would give the emergeny registrar credentials > > cert/private/public-key to the emergeny entities, then the customer > > itself also has the cert/private-key and could ask the MASA. > > This option would work with current BRSKY text. I am just not sure > > about security BCP (having two copies of a public key pair???). > > Sorry - I can???t write text around copying a private key. If we???re going that route lets dump all the PKI stuff and just use bearer tokens and be up front about the security we???re providing. See above for different ideas. Yepp. There should be easier options to achieve the same goal. Eg: I create a registrar as a VM, and run it onprem of the desaster recovery provider so that provider can enroll devices for my domain in case there is a desaster in my domain. > > - If the shared spare storage facility is Best Buy, and the Jones > > family wants to replace some electric storm victims @home while > > their ISP takes its days (my ISP C*...*T took almost 48 hours in one case), > > then the gear should probably come with a nonceless voucher > > printed on on a scratcher piece of paper inside the box. > > Even a nonceless voucher includes the domainCAcert so this idea doesn???t fly with the current text. What you???re looking for is some form of ???bearer voucher??? that contains a symmetric key. Probably. Yes. I guess we have not discussed how to apply BRSKY enrollment for home users. It's outside of scope for ANIMA anyhow, but would be interesting. Some of those home thoughts likely equally apply to low-end IoT devices. >Anybody who can scan it off the box can deploy the device. Thats why i said "scratcher", eg: some one-time-unveil where you can easily check that its untampered when you buy the device. > I???d normally rail against this but am actually pleased to see it fit so well into the model. A bearer voucher sorta sucks but creating one didn???t change any of our messaging flow or anything. Interesting positive that??? > I???m thinking that it is time for a section 3.7 ???Voucher types??? that digs into what we???re talking about for these different voucher types. Currently the text is scattered in the other sections. We could also start discussing those aspects in the submission from Kent et. al. about vouchers and move into BRSKY when we see it fit. Cheers Toerless > - max > > > Beyond these BRSKY considerations, the next cool ANIMA piece to consider > > for these use-cases is of course the ASA driven "re-configuration" of the > > spare device, aka: In larger outages, you should not except the whole > > network provisioning backend to be up and running. And its IMHO > > illusionary to expect devices to ONLY be driven from intent for many > > years (in complex networks... in a clean homenet they are driven by > > intent today..). > > > > Aka: for pre-intent-only desaster proof networks, we'd need: > > - ASA to cache neighbors configs. > > - reapply neighbor stored config when replacement gear is inserted. > > - IMHO: An anima definition for a "device-role-id" which is not > > the ACP IPv6 address (which will change upon gear replacement > > without enrolment support). > > > > Cheers > > toerless > From nobody Mon Nov 7 00:41:02 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2CA129D93 for ; Mon, 7 Nov 2016 00:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.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 cV66s8LCvZfi for ; Mon, 7 Nov 2016 00:40:57 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (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 C42D8129D33 for ; Mon, 7 Nov 2016 00:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:References:In-Reply-To:Date: Subject:From:Cc:To:MIME-Version:Sender:Reply-To:Message-ID: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kp7hkubfsPkZL1lvOifozDnOSoL2itn5/X0oRsOzSts=; b=UpfKu9xHaD2zgQKeCvVpX7ZI4 Hn5Xev+I3T73tv5aB7m4py3HHzAeUFGVCn6HUwsdjtrgAXYWCn2nPrUetXLLxTyc26j+ZGjWyPFhY +uBYmT/q7ZODlIBGTrS9PBy8Fl8L1wupt+oYtk5NCoU/ktMHGmFEq1AesPMuFte2pfHR+PwEYo3Ww oKL015ZWloi55XJbx3PzGvo0T5HgGHoZgBOANWevw/K+89T7w4hx6gG4dm5/OXXriA57VxpX95dzJ oAXBytlhbFl7R8QafEDqPRqvYARt1d4rol8UC3wxefks4EJran3vsSrMj+6ACzyQkdIiuD3SEO6CF kTCPTNaOw==; Received: from host-92-19-235-91.static.as13285.net ([92.19.235.91]:51597 helo=[IPv6:::ffff:192.168.1.125]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1c3fU3-001p5m-NK; Mon, 07 Nov 2016 08:40:53 +0000 MIME-Version: 1.0 To: Toerless Eckert , "Max Pritikin (pritikin)" From: Date: Mon, 7 Nov 2016 08:42:48 +0000 Importance: normal X-Priority: 3 In-Reply-To: <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/alternative; boundary="_21F78BE0-3751-415E-8EDD-39015865FBC0_" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Message-Id: <20161107084056.C42D8129D33@ietfa.amsl.com> Archived-At: Cc: Toerless Eckert , Anima WG , Eliot Lear Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up oftime without clocks) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 08:41:00 -0000 --_21F78BE0-3751-415E-8EDD-39015865FBC0_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi, Following ANIMA in fits and starts and saw the reference to BRSKY. Tried to= follow up on what it was all about and found the reference to it in draft-= ietf-anima-autonomic-control-plane-04. Section 5.2.4 is entitled =E2=80=9CD= iscovery and BRSKY=E2=80=9D but appears to make no reference to it and, des= pite three uses of the term BRSKY in the document, I find the protocol is a= ctually the Bootstrapping Remote Secure Key Infrastructures (BRSKI). Is the intention to rename to BRSKY or is it just that people have got into= the habit of calling it that? Jonathan =3DO) From: Toerless Eckert Sent: 07 November 2016 06:01 To: Max Pritikin (pritikin) Cc: Toerless Eckert; Eliot Lear; Anima WG Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up oftim= e without clocks) On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) wrote: > There is a lot here. Attempting to comment on it all.=20 >=20 > It would really help if we could relate these discussions to specific tex= t sections that could be improved. Otherwise we???re just blowing into the = wind. (Where it seems obvious I???ve added such notes).=20 Sure, but lets high level agree what type of content is useful and where it would fit. > > - Large organizations will have spares. With ANIMA, those spares should > > be stored pre-enrolled to avoid MASA/registrar dependency during > > recovery/replacements: Receive gear on any site (no central provisioni= ng > > site needed), but unpack, plug in for short period, then stash away. >=20 > Devices that have been brought up and are in the network post bootstrap a= re not relevant to the BRSKI document.=20 To me the most important goal should be to provide candidate users with deployment guidance. This should fit ANIMA goals given how its an OPS group= . Lets say we have two options: a) keep spares unenrolled, enrol during desaster recovery with satellite = link b) enrol spare devices when they are stocked, deploy during desaster. lets assume we agree both are relevant deployment options that users should understand, compare pro/cons for their case and choose. If you think we can not mention both in the BRSKY spec, then i think it would be better to have a separate document where both could be discussed.=20 > > This is imo an easy requirement also useful without desaster requireme= nts > > - aka: enrolled spares would likely also have better theft/abuse prote= ction > > than non-enrolled. And yes, you will have to power up these spares > > once a year. Which IMHO is ok. And of course certs should therefore > > be somewhat longer than 1 year). >=20 > This could be captured as a discussion: what does a device do when its cr= edentials are out of date? Does it fall back on full bootstrapping? If so t= his becomes a potential attack vector wherein the attacker can convince the= device it is out of date and then force it to restart bootstrapping. That = would be bad.=20 Haha... ;-) i just wanted to show what IMHO are the most simple deployment options to deal with desaster recover. Now you're the one who is opening another round of discussions trying to figure out the best security compromise for those deployment processes. Which is great. Just don't blame me that there are more and more interesting details to capture somewhere. > So, should there be an injection point into the bootstrapping state machi= ne that says something like: >=20 > If a device fails to join the ANI after [some number] of attempts it atte= mpts to repeat bootstrapping using its original SUDI credentials. I'd prepare a flag 'operational' set by SDN controller or ASA after=20 the device is "provisioned" (config/intent applied). > During this bootstrapping attempt it MUST only bootstrap on a Registrar t= hat provides both a valid voucher and an identity recognizably within the s= ame PKI hierarchy the device was in previously. This is detected by the dev= ice by either (a) the domainCAcert is an exact match for the current domain= trust anchor known to the device or (b) the EST /cacerts response includes= a chain that terminates in the current domain trust anchor known to the de= vice. =20 >=20 > This extends the lifetime of such a stored device beyond its own certific= ate (maybe 1 year) *and* beyond the current CA certificate (maybe a 2year c= ert) an all the way into the next CA certificate (another 2 years). That is= a pretty solid lifetime (up to 4 years) for recovery. Interesting thought. a) Would like to understand how this compares to just making certs longer-lived, eg: 3 years, but doing normal renewal after 30% time. b) Seem like there's quite a bit of analysis to be done of how different parameter/options will work together: - device with/without reliable RTC - what would be necessary/beneficial with nonce-less vouchers ? how about nonceless vouchers with sequence number... -> remember ownership voucher and allow for it to be replaced only with one that hass a higher serial number. > > - If sparing would be cross-locations (eg: spares sent from some site t= o > > other sites during recovery), then its important that the ANIMA certs = do > > not include any location specific attributes that would prohibit thart > > movement. So far BRSKY does not include any such attributes, but in > > discussions, three has been interest to lock into the cert some device > > role specific attributes, and for a spare piecce of equipment, those > > attributes may not be predetermined. > >=20 > > Aka: Desaster sparing means domain certs need to be simple, devices > > reuseable across domain. >=20 > I agree that certs should include the absolute minimum information about = the device. The actual ID is sufficient in my book. Attribute Certs or back= end database lookups or short term tokens obtained by the device in place a= re all methods of distributing additional information.=20 Desaster recovery seems to be one good motivation to not put more than the minimum into the certs. I was a fan of putting more into certs in the past... > > - If spares are done by a shared facility: vendor, FEMO (for fed networ= ks) > > or the like, one could think of that entity offering (emergency) > > enrolment service. > >=20 > > Such an entity would have desaster proof MASA connectivity on site, > > and the customers would provide it with (emergency) registrar certs. >=20 > Ok. So like a Cisco NERV truck that provides connectivity sufficient to r= ebuild a network in place.=20 >=20 > Issuing a new Registrar ID would mean being able to bring up the PKI infr= astructure during the recovery process. But this is exactly the time period= when having as much of the critical keying infrastructure offline and secu= red could be beneficial for longterm security. One could argue that extra a= ttempts should be made to ensure the PKI is offline.=20 My thought was a) the desaster recovery registrar-IDs are preprovisioned _before_ desaster (contract between domain and desaster/spare recovery entity). b) The facility to which they are allocated is shared across multiple domains. c) the facility is not "desaster on-site" -> the spares will not be on-site= , but will be stored at some central site. Enrollment would happen at that central site, then they'd be shipped onto-desaster-site. > > (emergency) meaning that the entity is only permitted to enrol during > > emergencies, and the customer could be able to verify the emergency > > entities behavior by pulling from the MASA an audit log. >=20 > Section 5.6 doesn???t include the Registrar identity only the domainID in= the log. Do folks think the Registrar ID should be included as well? Oh, right. i confused domain-id with registrar-ID. I definitely think registrar-ID would be necessary to log so that audit-logs become more useful to backtrack what happened. > If this was done then does it matter if the Registrar cert has role infor= mation in it? As per the above what would happen if all devices in the ANI = could act as a registrar? There would be a higher chance that one of them w= ould mess up and actually perform registrar activities incorrectly ??? but = it would be logged so the admin could watch for that. I don't think we need many/all devices to be registrars. I don't think we've got a working security model to do this anyhow - eg: authenticating all those devices against the CA. I hope we do not need to discuss other roles beside "registrar" in this context. > Thoughts? I???m worried but see the conversation going that way. > > If the customer would give the emergeny registrar credentials > > cert/private/public-key to the emergeny entities, then the customer > > itself also has the cert/private-key and could ask the MASA. > > This option would work with current BRSKY text. I am just not sure > > about security BCP (having two copies of a public key pair???). >=20 > Sorry - I can???t write text around copying a private key. If we???re goi= ng that route lets dump all the PKI stuff and just use bearer tokens and be= up front about the security we???re providing. See above for different ide= as.=20 Yepp. There should be easier options to achieve the same goal. Eg: I create a registrar as a VM, and run it onprem of the desaster recovery provider so that provider can enroll devices for my domain in case there is a desaster in my domain. > > - If the shared spare storage facility is Best Buy, and the Jones > > family wants to replace some electric storm victims @home while > > their ISP takes its days (my ISP C*...*T took almost 48 hours in one c= ase), > > then the gear should probably come with a nonceless voucher > > printed on on a scratcher piece of paper inside the box. >=20 > Even a nonceless voucher includes the domainCAcert so this idea doesn???t= fly with the current text. What you???re looking for is some form of ???be= arer voucher??? that contains a symmetric key. Probably. Yes. I guess we have not discussed how to apply BRSKY enrollment for home users. It's outside of scope for ANIMA anyhow, but would be interesting. Some of those home thoughts likely equally apply to low-end IoT devices. >Anybody who can scan it off the box can deploy the device.=20 Thats why i said "scratcher", eg: some one-time-unveil where you can easily check that its untampered when you buy the device.=20 > I???d normally rail against this but am actually pleased to see it fit so= well into the model. A bearer voucher sorta sucks but creating one didn???= t change any of our messaging flow or anything. Interesting positive that??= ?=20 > I???m thinking that it is time for a section 3.7 ???Voucher types??? that= digs into what we???re talking about for these different voucher types. Cu= rrently the text is scattered in the other sections.=20 We could also start discussing those aspects in the submission from Kent et. al. about vouchers and move into BRSKY when we see it fit. Cheers Toerless > - max >=20 > > Beyond these BRSKY considerations, the next cool ANIMA piece to conside= r > > for these use-cases is of course the ASA driven "re-configuration" of t= he > > spare device, aka: In larger outages, you should not except the whole > > network provisioning backend to be up and running. And its IMHO > > illusionary to expect devices to ONLY be driven from intent for many > > years (in complex networks... in a clean homenet they are driven by > > intent today..).=20 > >=20 > > Aka: for pre-intent-only desaster proof networks, we'd need: > > - ASA to cache neighbors configs. > > - reapply neighbor stored config when replacement gear is inserted. > > - IMHO: An anima definition for a "device-role-id" which is not > > the ACP IPv6 address (which will change upon gear replacement > > without enrolment support). > >=20 > > Cheers > > toerless >=20 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima --_21F78BE0-3751-415E-8EDD-39015865FBC0_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi,

&nb= sp;

Following ANIMA in fits and starts and sa= w the reference to BRSKY. Tried to follow up on what it was all about and f= ound the reference to it in draft-ietf-anima-autonomic-control-plane-04. Se= ction 5.2.4 is entitled =E2=80=9CDiscovery and BRSKY=E2=80=9D but appears t= o make no reference to it and, despite three uses of the term BRSKY in the = document, I find the protocol is actually the Bootstrapping Remote Secure K= ey Infrastructures (BRSKI).

 

Is the intention to rename to BRSKY or is it just that p= eople have got into the habit of calling it that?

<= br>Jonathan

=3DO)

 

From: Toerless Eckert
Sent: 07 November 2016 06:01
To: Max Pritikin (pritikin)
Cc: Toerless Eckert; Eliot Lear; Anima WG
Su= bject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up oft= ime without clocks)

 

On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pr= itikin) wrote:

> There is a lot here. Attempting= to comment on it all.

>

> It would really help if we could relate these discussions to specif= ic text sections that could be improved. Otherwise we???re just blowing int= o the wind. (Where it seems obvious I???ve added such notes).

 

Sure, but lets high = level agree what type of content is useful and

wher= e it would fit.

 

> > - Large organizations will have spares. With ANIMA, those = spares should

> >=C2=A0 be stored pre-enrolle= d to avoid MASA/registrar dependency during

> &g= t;=C2=A0 recovery/replacements: Receive gear on any site (no central provis= ioning

> >=C2=A0 site needed), but unpack, pl= ug in for short period, then stash away.

>

<= p class=3DMsoNormal>> Devices that have been brought up and are in the n= etwork post bootstrap are not relevant to the BRSKI document.

 

To me the most impor= tant goal should be to provide candidate users with

deployment guidance. This should fit ANIMA goals given how its an OPS grou= p.

 

Lets s= ay we have two options:

 

=C2=A0 a) keep spares unenrolled, enrol during desaster reco= very with satellite link

=C2=A0 b) enrol spare devi= ces when they are stocked, deploy during desaster.

=  

lets assume we agree both are rel= evant deployment options that users

should understa= nd, compare pro/cons for their case and choose. If you think

we can not mention both in the BRSKY spec, then i think it would = be better

to have a separate document where both co= uld be discussed.

 

> >=C2=A0 This is imo an easy requirement also useful witho= ut desaster requirements

> >=C2=A0 - aka: enr= olled spares would likely also have better theft/abuse protection

> >=C2=A0 than non-enrolled. And yes, you will have to= power up these spares

> >=C2=A0 once a year.= Which IMHO is ok. And of course certs should therefore

> >=C2=A0 be somewhat longer than 1 year).

>

> This could be captured as a discussio= n: what does a device do when its credentials are out of date? Does it fall= back on full bootstrapping? If so this becomes a potential attack vector w= herein the attacker can convince the device it is out of date and then forc= e it to restart bootstrapping. That would be bad.

=  

Haha... ;-) i just wanted to show= what IMHO are the most simple

deployment options t= o deal with desaster recover. Now you're the one who is

opening another round of discussions trying to figure out the best

=

security compromise for those deployment processes.=C2= =A0 Which is great.

Just don't blame me that there = are more and more interesting details to

capture so= mewhere.

 

= > So, should there be an injection point into the bootstrapping state ma= chine that says something like:

>

> If a device fails to join the ANI after [some number] of = attempts it attempts to repeat bootstrapping using its original SUDI creden= tials.

 

I'= d prepare a flag 'operational' set by SDN controller or ASA after

the device is "provisioned" (config/intent applie= d).

 

> = During this bootstrapping attempt it MUST only bootstrap on a Registrar tha= t provides both a valid voucher and an identity recognizably within the sam= e PKI hierarchy the device was in previously. This is detected by the devic= e by either (a) the domainCAcert is an exact match for the current domain t= rust anchor known to the device or (b) the EST /cacerts response includes a= chain that terminates in the current domain trust anchor known to the devi= ce.=C2=A0

>

> This = extends the lifetime of such a stored device beyond its own certificate (ma= ybe 1 year) *and* beyond the current CA certificate (maybe a 2year cert) an= all the way into the next CA certificate (another 2 years). That is a pret= ty solid lifetime (up to 4 years) for recovery.

 

Interesting thought.

 

a) Would like to underst= and how this compares to just making certs

longer-l= ived, eg: 3 years, but doing normal renewal after 30% time.

 

b) Seem like there's qui= te a bit of analysis to be done of how different

pa= rameter/options will work together:

=C2=A0 - device= with/without reliable RTC

=C2=A0 - what would be n= ecessary/beneficial with nonce-less vouchers ?

=C2= =A0=C2=A0=C2=A0 how about nonceless vouchers with sequence number... -> = remember

=C2=A0=C2=A0=C2=A0 ownership voucher and a= llow for it to be replaced only with one that

=C2= =A0=C2=A0=C2=A0 hass a higher serial number.

&= nbsp;

> > - If sparing would be cross-l= ocations (eg: spares sent from some site to

> &g= t;=C2=A0 other sites during recovery), then its important that the ANIMA ce= rts do

> >=C2=A0 not include any location spe= cific attributes that would prohibit thart

> >= ;=C2=A0 movement. So far BRSKY does not include any such attributes, but in=

> >=C2=A0 discussions, three has been intere= st to lock into the cert some device

> >=C2= =A0 role specific attributes, and for a spare piecce of equipment, those

> >=C2=A0 attributes may not be predetermined.<= /p>

> >

> >=C2=A0 = Aka: Desaster sparing means domain certs need to be simple, devices

> >=C2=A0 reuseable across domain.

>

> I agree that certs should include= the absolute minimum information about the device. The actual ID is suffic= ient in my book. Attribute Certs or backend database lookups or short term = tokens obtained by the device in place are all methods of distributing addi= tional information.

 

Desaster recovery seems to be one good motivation to not put

more than the minimum into the certs. I was a fan of= putting more

into certs in the past...

 

> > - If spare= s are done by a shared facility: vendor, FEMO (for fed networks)

> >=C2=A0 or the like, one could think of that entity o= ffering (emergency)

> >=C2=A0 enrolment servi= ce.

> >

> >=C2= =A0 Such an entity would have desaster proof MASA connectivity on site,

=

> >=C2=A0 and the customers would provide it wit= h (emergency) registrar certs.

>

> Ok. So like a Cisco NERV truck that provides connectivity su= fficient to rebuild a network in place.

>

<= p class=3DMsoNormal>> Issuing a new Registrar ID would mean being able t= o bring up the PKI infrastructure during the recovery process. But this is = exactly the time period when having as much of the critical keying infrastr= ucture offline and secured could be beneficial for longterm security. One c= ould argue that extra attempts should be made to ensure the PKI is offline.=

 

My thou= ght was

a) the desaster recovery registrar-IDs are = preprovisioned _before_ desaster

=C2=A0=C2=A0 (cont= ract between domain and desaster/spare recovery entity).

b) The facility to which they are allocated is shared across multiple=

=C2=A0=C2=A0 domains.

c) t= he facility is not "desaster on-site" -> the spares will not b= e on-site,

=C2=A0=C2=A0 but will be stored at some = central site. Enrollment would happen at

=C2=A0=C2= =A0 that central site, then they'd be shipped onto-desaster-site.

 

> >=C2=A0 (e= mergency) meaning that the entity is only permitted to enrol during

> >=C2=A0 emergencies, and the customer could be abl= e to verify the emergency

> >=C2=A0 entities = behavior by pulling from the MASA an audit log.

>= ;

> Section 5.6 doesn???t include the Registrar= identity only the domainID in the log. Do folks think the Registrar ID sho= uld be included as well?

 

Oh, right. i confused domain-id with registrar-ID.

 

I definitely thin= k registrar-ID would be necessary to log so

that au= dit-logs become more useful to backtrack what happened.

 

> If this was done then d= oes it matter if the Registrar cert has role information in it? As per the = above what would happen if all devices in the ANI could act as a registrar?= There would be a higher chance that one of them would mess up and actually= perform registrar activities incorrectly ??? but it would be logged so the= admin could watch for that.

 

<= p class=3DMsoNormal> 

I don't think= we need many/all devices to be registrars. I don't think

we've got a working security model to do this anyhow - eg: authentic= ating

all those devices against the CA. I hope we d= o not need to discuss other

roles beside "regi= strar" in this context.

 

<= p class=3DMsoNormal>> Thoughts? I???m worried but see the conversation g= oing that way.

 

> >=C2=A0 If the customer would give the emergeny registrar cre= dentials

> >=C2=A0 cert/private/public-key to= the emergeny entities, then the customer

> >= =C2=A0 itself also has the cert/private-key and could ask the MASA.

> >=C2=A0 This option would work with current BRSKY = text. I am just not sure

> >=C2=A0 about secu= rity BCP (having two copies of a public key pair???).

>

> Sorry - I can???t write text around c= opying a private key. If we???re going that route lets dump all the PKI stu= ff and just use bearer tokens and be up front about the security we???re pr= oviding. See above for different ideas.

 = ;

Yepp. There should be easier options to ach= ieve the same goal.

 

Eg: I create a registrar as a VM, and run it onprem of the

=

desaster recovery provider so that provider can enroll= devices

for my domain in case there is a desaster = in my domain.

 

> > - If the shared spare storage facility is Best Buy, and the = Jones

> >=C2=A0 family wants to replace some = electric storm victims @home while

> >=C2=A0 = their ISP takes its days (my ISP C*...*T took almost 48 hours in one case),=

> >=C2=A0 then the gear should probably come= with a nonceless voucher

> >=C2=A0 printed o= n on a scratcher piece of paper inside the box.

>= ;

> Even a nonceless voucher includes the domai= nCAcert so this idea doesn???t fly with the current text. What you???re loo= king for is some form of ???bearer voucher??? that contains a symmetric key= .

 

Probabl= y. Yes. I guess we have not discussed how to apply BRSKY

enrollment for home users. It's outside of scope for ANIMA anyhow,

but would be interesting. Some of those home thoughts= likely equally

apply to low-end IoT devices.

 

>Anybody wh= o can scan it off the box can deploy the device.

<= o:p> 

Thats why i said "scratcher&q= uot;, eg: some one-time-unveil where you

can easily= check that its untampered when you buy the device.

 

> I???d normally rail agains= t this but am actually pleased to see it fit so well into the model. A bear= er voucher sorta sucks but creating one didn???t change any of our messagin= g flow or anything. Interesting positive that???

<= o:p> 

> I???m thinking that it is tim= e for a section 3.7 ???Voucher types??? that digs into what we???re talking= about for these different voucher types. Currently the text is scattered i= n the other sections.

 

We could also start discussing those aspects in the submissio= n from

Kent et. al. about vouchers and move into BR= SKY when we see it fit.

 

Cheers

=C2=A0=C2=A0=C2=A0 Toerless

 

> - max=

>

> > Beyond the= se BRSKY considerations, the next cool ANIMA piece to consider

> > for these use-cases is of course the ASA driven &quo= t;re-configuration" of the

> > spare dev= ice, aka: In larger outages, you should not except the whole

> > network provisioning backend to be up and running. And = its IMHO

> > illusionary to expect devices to= ONLY be driven from intent for many

> > year= s (in complex networks... in a clean homenet they are driven by

> > intent today..).

> > =

> > Aka: for pre-intent-only desaster proof = networks, we'd need:

> >=C2=A0 - ASA to cache= neighbors configs.

> >=C2=A0 - reapply neigh= bor stored config when replacement gear is inserted.

> >=C2=A0 - IMHO: An anima definition for a "device-role-id&qu= ot; which is not

> >=C2=A0=C2=A0=C2=A0 the AC= P IPv6 address (which will change upon gear replacement

> >=C2=A0=C2=A0=C2=A0 without enrolment support).

> >

> > Cheers

> >=C2=A0=C2=A0=C2=A0 toerless

&= gt;

 

____= ___________________________________________

Anima m= ailing list

Anima@ietf.org

= https://www.ietf.org/mailman/listinfo/anima

&n= bsp;

= --_21F78BE0-3751-415E-8EDD-39015865FBC0_-- From nobody Mon Nov 7 21:16:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C925129681 for ; Mon, 7 Nov 2016 21:16:38 -0800 (PST) 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 xv4_V21TcsKU for ; Mon, 7 Nov 2016 21:16:35 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 C349C129668 for ; Mon, 7 Nov 2016 21:16:35 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id d2so101601074pfd.0 for ; Mon, 07 Nov 2016 21:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=flUe+TYLU6e85lUrt8bTaeZiZNQR6inqXoE1ts6+Jyg=; b=D+nhZkMbNb5mgu2uS49XU034lXPrepxyjvcL1025KFh2C6nOsMOcWxfrIui8SNZYUN mhtN75b9QMTOaC6l5m0TDRjne/vQx4n3XL3T3Fb2uxTdnxmWz+5qRq5p0cg+lgE4YtQF DVeRJE1+QvlQ02uXfhywfwHqD790pXX55C/2WO0RBFeUc2G7NUiw2ea0LnnNXt1d1w5Z L5vRTdpZsOXPbj4SO9vqOhPsTaGaCEjF9bPYg13oScXC0hGoCOZ4oYPaVo0vNUCHa6h7 asM0qP4gFmKZ05bDFryEIkG2HUgcMHPhrWGDJjf9qUe2xDR5UmxEFUgPXbVNraHkz4fN LYbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=flUe+TYLU6e85lUrt8bTaeZiZNQR6inqXoE1ts6+Jyg=; b=Idi2Un2schqQ0U9VRcam/n9o5vC7VysfQHdoHS/3i0vMfWCgHSytMXe1mt4VRdDEId csFZAdUFkJwKUmrokVeswKGcYUdk2GfN2sNnppiKHhBVco4CVcauW+K3a4E6EJkpvH7e I/kzDZ8WAL71sW1LjpcYn6l4iHfJX1XE3UQbvrESKcyDEgjlAyp85/BbQa8z6aiEnj+2 kzDxK4UcuzdfkjeXG6CSTg+d0qmchTGaVX1U4K522epv+t2/hKUT0VuhbG6+ZX97xMkA YHgMST7794HEmWB+lE7llwLC4dVBuCYqBoY8VzUUdrisS1d2LjevcYpPHrLL/uJ3yhOU qwxw== X-Gm-Message-State: ABUngvdxxJ1FJX8Va3jqNXsJziuzkd+WkinhBt8R77yIR7jdOz2RqdOBz+ZlNVKXzX8leA== X-Received: by 10.98.26.88 with SMTP id a85mr20143604pfa.57.1478581747296; Mon, 07 Nov 2016 21:09:07 -0800 (PST) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id c142sm41882363pfb.23.2016.11.07.21.09.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 21:09:06 -0800 (PST) To: jonathan@hansfords.net, Toerless Eckert , "Max Pritikin (pritikin)" References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> <20161107084056.C42D8129D33@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 8 Nov 2016 18:09:04 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161107084056.C42D8129D33@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , Eliot Lear , Anima WG Subject: Re: [Anima] Desaster recover... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 05:16:38 -0000 Jonathan, BRSKI (I not Y) is defined in draft-ietf-anima-bootstrapping-keyinfra-04 "Bootstrapping Remote Secure Key Infrastructures (BRSKI)". If there are incomplete or incorrect references in other documents, of course they nee= d to be completed or corrected. Regards Brian On 07/11/2016 21:42, jonathan@hansfords.net wrote: > Hi, >=20 > Following ANIMA in fits and starts and saw the reference to BRSKY. Trie= d to follow up on what it was all about and found the reference to it in = draft-ietf-anima-autonomic-control-plane-04. Section 5.2.4 is entitled =E2= =80=9CDiscovery and BRSKY=E2=80=9D but appears to make no reference to it= and, despite three uses of the term BRSKY in the document, I find the pr= otocol is actually the Bootstrapping Remote Secure Key Infrastructures (B= RSKI). >=20 > Is the intention to rename to BRSKY or is it just that people have got = into the habit of calling it that? >=20 > Jonathan >=20 > =3DO) >=20 > From: Toerless Eckert > Sent: 07 November 2016 06:01 > To: Max Pritikin (pritikin) > Cc: Toerless Eckert; Eliot Lear; Anima WG > Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up o= ftime without clocks) >=20 > On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) wrote= : >> There is a lot here. Attempting to comment on it all.=20 >> >> It would really help if we could relate these discussions to specific = text sections that could be improved. Otherwise we???re just blowing into= the wind. (Where it seems obvious I???ve added such notes).=20 >=20 > Sure, but lets high level agree what type of content is useful and > where it would fit. >=20 >>> - Large organizations will have spares. With ANIMA, those spares shou= ld >>> be stored pre-enrolled to avoid MASA/registrar dependency during >>> recovery/replacements: Receive gear on any site (no central provisio= ning >>> site needed), but unpack, plug in for short period, then stash away.= >> >> Devices that have been brought up and are in the network post bootstra= p are not relevant to the BRSKI document.=20 >=20 > To me the most important goal should be to provide candidate users with= > deployment guidance. This should fit ANIMA goals given how its an OPS g= roup. >=20 > Lets say we have two options: >=20 > a) keep spares unenrolled, enrol during desaster recovery with satell= ite link > b) enrol spare devices when they are stocked, deploy during desaster.= >=20 > lets assume we agree both are relevant deployment options that users > should understand, compare pro/cons for their case and choose. If you t= hink > we can not mention both in the BRSKY spec, then i think it would be bet= ter > to have a separate document where both could be discussed.=20 >=20 >>> This is imo an easy requirement also useful without desaster require= ments >>> - aka: enrolled spares would likely also have better theft/abuse pro= tection >>> than non-enrolled. And yes, you will have to power up these spares >>> once a year. Which IMHO is ok. And of course certs should therefore >>> be somewhat longer than 1 year). >> >> This could be captured as a discussion: what does a device do when its= credentials are out of date? Does it fall back on full bootstrapping? If= so this becomes a potential attack vector wherein the attacker can convi= nce the device it is out of date and then force it to restart bootstrappi= ng. That would be bad.=20 >=20 > Haha... ;-) i just wanted to show what IMHO are the most simple > deployment options to deal with desaster recover. Now you're the one wh= o is > opening another round of discussions trying to figure out the best > security compromise for those deployment processes. Which is great. > Just don't blame me that there are more and more interesting details to= > capture somewhere. >=20 >> So, should there be an injection point into the bootstrapping state ma= chine that says something like: >> >> If a device fails to join the ANI after [some number] of attempts it a= ttempts to repeat bootstrapping using its original SUDI credentials. >=20 > I'd prepare a flag 'operational' set by SDN controller or ASA after=20 > the device is "provisioned" (config/intent applied). >=20 >> During this bootstrapping attempt it MUST only bootstrap on a Registra= r that provides both a valid voucher and an identity recognizably within = the same PKI hierarchy the device was in previously. This is detected by = the device by either (a) the domainCAcert is an exact match for the curre= nt domain trust anchor known to the device or (b) the EST /cacerts respon= se includes a chain that terminates in the current domain trust anchor kn= own to the device. =20 >> >> This extends the lifetime of such a stored device beyond its own certi= ficate (maybe 1 year) *and* beyond the current CA certificate (maybe a 2y= ear cert) an all the way into the next CA certificate (another 2 years). = That is a pretty solid lifetime (up to 4 years) for recovery. >=20 > Interesting thought. >=20 > a) Would like to understand how this compares to just making certs > longer-lived, eg: 3 years, but doing normal renewal after 30% time. >=20 > b) Seem like there's quite a bit of analysis to be done of how differen= t > parameter/options will work together: > - device with/without reliable RTC > - what would be necessary/beneficial with nonce-less vouchers ? > how about nonceless vouchers with sequence number... -> remember > ownership voucher and allow for it to be replaced only with one tha= t > hass a higher serial number. >=20 >>> - If sparing would be cross-locations (eg: spares sent from some site= to >>> other sites during recovery), then its important that the ANIMA cert= s do >>> not include any location specific attributes that would prohibit tha= rt >>> movement. So far BRSKY does not include any such attributes, but in >>> discussions, three has been interest to lock into the cert some devi= ce >>> role specific attributes, and for a spare piecce of equipment, those= >>> attributes may not be predetermined. >>> >>> Aka: Desaster sparing means domain certs need to be simple, devices >>> reuseable across domain. >> >> I agree that certs should include the absolute minimum information abo= ut the device. The actual ID is sufficient in my book. Attribute Certs or= backend database lookups or short term tokens obtained by the device in = place are all methods of distributing additional information.=20 >=20 > Desaster recovery seems to be one good motivation to not put > more than the minimum into the certs. I was a fan of putting more > into certs in the past... >=20 >>> - If spares are done by a shared facility: vendor, FEMO (for fed netw= orks) >>> or the like, one could think of that entity offering (emergency) >>> enrolment service. >>> >>> Such an entity would have desaster proof MASA connectivity on site, >>> and the customers would provide it with (emergency) registrar certs.= >> >> Ok. So like a Cisco NERV truck that provides connectivity sufficient t= o rebuild a network in place.=20 >> >> Issuing a new Registrar ID would mean being able to bring up the PKI i= nfrastructure during the recovery process. But this is exactly the time p= eriod when having as much of the critical keying infrastructure offline a= nd secured could be beneficial for longterm security. One could argue tha= t extra attempts should be made to ensure the PKI is offline.=20 >=20 > My thought was > a) the desaster recovery registrar-IDs are preprovisioned _before_ desa= ster > (contract between domain and desaster/spare recovery entity). > b) The facility to which they are allocated is shared across multiple > domains. > c) the facility is not "desaster on-site" -> the spares will not be on-= site, > but will be stored at some central site. Enrollment would happen at > that central site, then they'd be shipped onto-desaster-site. >=20 >>> (emergency) meaning that the entity is only permitted to enrol durin= g >>> emergencies, and the customer could be able to verify the emergency >>> entities behavior by pulling from the MASA an audit log. >> >> Section 5.6 doesn???t include the Registrar identity only the domainID= in the log. Do folks think the Registrar ID should be included as well? >=20 > Oh, right. i confused domain-id with registrar-ID. >=20 > I definitely think registrar-ID would be necessary to log so > that audit-logs become more useful to backtrack what happened. >=20 >> If this was done then does it matter if the Registrar cert has role in= formation in it? As per the above what would happen if all devices in the= ANI could act as a registrar? There would be a higher chance that one of= them would mess up and actually perform registrar activities incorrectly= ??? but it would be logged so the admin could watch for that. >=20 >=20 > I don't think we need many/all devices to be registrars. I don't think > we've got a working security model to do this anyhow - eg: authenticati= ng > all those devices against the CA. I hope we do not need to discuss othe= r > roles beside "registrar" in this context. >=20 >> Thoughts? I???m worried but see the conversation going that way. >=20 >>> If the customer would give the emergeny registrar credentials >>> cert/private/public-key to the emergeny entities, then the customer >>> itself also has the cert/private-key and could ask the MASA. >>> This option would work with current BRSKY text. I am just not sure >>> about security BCP (having two copies of a public key pair???). >> >> Sorry - I can???t write text around copying a private key. If we???re = going that route lets dump all the PKI stuff and just use bearer tokens a= nd be up front about the security we???re providing. See above for differ= ent ideas.=20 >=20 > Yepp. There should be easier options to achieve the same goal. >=20 > Eg: I create a registrar as a VM, and run it onprem of the > desaster recovery provider so that provider can enroll devices > for my domain in case there is a desaster in my domain. >=20 >>> - If the shared spare storage facility is Best Buy, and the Jones >>> family wants to replace some electric storm victims @home while >>> their ISP takes its days (my ISP C*...*T took almost 48 hours in one= case), >>> then the gear should probably come with a nonceless voucher >>> printed on on a scratcher piece of paper inside the box. >> >> Even a nonceless voucher includes the domainCAcert so this idea doesn?= ??t fly with the current text. What you???re looking for is some form of = ???bearer voucher??? that contains a symmetric key. >=20 > Probably. Yes. I guess we have not discussed how to apply BRSKY > enrollment for home users. It's outside of scope for ANIMA anyhow, > but would be interesting. Some of those home thoughts likely equally > apply to low-end IoT devices. >=20 >> Anybody who can scan it off the box can deploy the device.=20 >=20 > Thats why i said "scratcher", eg: some one-time-unveil where you > can easily check that its untampered when you buy the device.=20 >=20 >> I???d normally rail against this but am actually pleased to see it fit= so well into the model. A bearer voucher sorta sucks but creating one di= dn???t change any of our messaging flow or anything. Interesting positive= that???=20 >=20 >> I???m thinking that it is time for a section 3.7 ???Voucher types??? t= hat digs into what we???re talking about for these different voucher type= s. Currently the text is scattered in the other sections.=20 >=20 > We could also start discussing those aspects in the submission from > Kent et. al. about vouchers and move into BRSKY when we see it fit. >=20 > Cheers > Toerless >=20 >> - max >> >>> Beyond these BRSKY considerations, the next cool ANIMA piece to consi= der >>> for these use-cases is of course the ASA driven "re-configuration" of= the >>> spare device, aka: In larger outages, you should not except the whole= >>> network provisioning backend to be up and running. And its IMHO >>> illusionary to expect devices to ONLY be driven from intent for many >>> years (in complex networks... in a clean homenet they are driven by >>> intent today..).=20 >>> >>> Aka: for pre-intent-only desaster proof networks, we'd need: >>> - ASA to cache neighbors configs. >>> - reapply neighbor stored config when replacement gear is inserted. >>> - IMHO: An anima definition for a "device-role-id" which is not >>> the ACP IPv6 address (which will change upon gear replacement >>> without enrolment support). >>> >>> Cheers >>> toerless >> >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue Nov 8 01:14:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D341295BC for ; Tue, 8 Nov 2016 01:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.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 dmDzEAAVsxPF for ; Tue, 8 Nov 2016 01:13:59 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (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 852B4129448 for ; Tue, 8 Nov 2016 01:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zsJsBYxAA19o/9uw0mufjso/Sc0Ev3Pa7RTctirNcYo=; b=gHzhecM4v69wW8XCc/hjelePK5 2ZU+97jGLFGYp3R+dJKynHIGBRbEXILEWkk6i0/AcjvyiK4zIsEQZg22muzPfzW0krBJ1h46EEWp1 IDfdtSqqxAgf3RTXL/+t5GzBBfo+mAjSmvVI7UFq8HPRRQZF3vSIbZXVN2t/o0jFlqUtMQuGwUbiQ VIq6A/7xOv/Vm4kCVczvZROej0HYj6/QBb2hf6a3EuM14+OP8u8C9MOTqGBZxzf23vFkBqsnJu27x psSdvzWVTNnQ0Jr1sKWTlqrB43v7kW5z4fH6MyDBpII1YnzpCCZK3+il58L3xx2wicKPuNsSCtbeU dbGKWQpw==; Received: from hansfords.plus.com ([84.92.116.209]:36804 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1c42TX-00376p-I4; Tue, 08 Nov 2016 09:13:52 +0000 From: "Jonathan Hansford" To: "'Brian E Carpenter'" , "'Toerless Eckert'" , "'Max Pritikin \(pritikin\)'" References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> <20161107084056.C42D8129D33@ietfa.amsl.com> In-Reply-To: Date: Tue, 8 Nov 2016 09:13:48 -0000 Message-ID: <007101d239a0$6ce05f00$46a11d00$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL/3iUb6FRTHtSsvhKCvPuUz0B7xAFqxFpDAqHIxlwB7o0yCQIJgaazARCuHCcBsyWdvAHDOWw5AfEC3hYB4tCbKQIHIXK9neBPSGA= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Cc: 'Toerless Eckert' , 'Eliot Lear' , 'Anima WG' Subject: Re: [Anima] Desaster recover... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 09:14:02 -0000 It would also be good if the correct acronym could be used in emails as = it makes it easier to track down what people are referring to. Jonathan > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 08 November 2016 05:09 > To: jonathan@hansfords.net; Toerless Eckert ; Max = Pritikin > (pritikin) > Cc: Toerless Eckert ; Anima WG ; = Eliot > Lear > Subject: Re: [Anima] Desaster recover... >=20 > Jonathan, >=20 > BRSKI (I not Y) is defined in = draft-ietf-anima-bootstrapping-keyinfra-04 > "Bootstrapping Remote Secure Key Infrastructures (BRSKI)". If there = are > incomplete or incorrect references in other documents, of course they = need > to be completed or corrected. >=20 > Regards > Brian >=20 > On 07/11/2016 21:42, jonathan@hansfords.net wrote: > > Hi, > > > > Following ANIMA in fits and starts and saw the reference to BRSKY. = Tried to > follow up on what it was all about and found the reference to it in = draft-ietf- > anima-autonomic-control-plane-04. Section 5.2.4 is entitled = =E2=80=9CDiscovery and > BRSKY=E2=80=9D but appears to make no reference to it and, despite = three uses of the > term BRSKY in the document, I find the protocol is actually the = Bootstrapping > Remote Secure Key Infrastructures (BRSKI). > > > > Is the intention to rename to BRSKY or is it just that people have = got into > the habit of calling it that? > > > > Jonathan > > > > =3DO) > > > > From: Toerless Eckert > > Sent: 07 November 2016 06:01 > > To: Max Pritikin (pritikin) > > Cc: Toerless Eckert; Eliot Lear; Anima WG > > Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write = up > > oftime without clocks) > > > > On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) = wrote: > >> There is a lot here. Attempting to comment on it all. > >> > >> It would really help if we could relate these discussions to = specific text > sections that could be improved. Otherwise we???re just blowing into = the > wind. (Where it seems obvious I???ve added such notes). > > > > Sure, but lets high level agree what type of content is useful and > > where it would fit. > > > >>> - Large organizations will have spares. With ANIMA, those spares > >>> should be stored pre-enrolled to avoid MASA/registrar dependency > >>> during > >>> recovery/replacements: Receive gear on any site (no central > >>> provisioning site needed), but unpack, plug in for short period, = then > stash away. > >> > >> Devices that have been brought up and are in the network post = bootstrap > are not relevant to the BRSKI document. > > > > To me the most important goal should be to provide candidate users > > with deployment guidance. This should fit ANIMA goals given how its = an > OPS group. > > > > Lets say we have two options: > > > > a) keep spares unenrolled, enrol during desaster recovery with = satellite > link > > b) enrol spare devices when they are stocked, deploy during = desaster. > > > > lets assume we agree both are relevant deployment options that users > > should understand, compare pro/cons for their case and choose. If = you > > think we can not mention both in the BRSKY spec, then i think it = would > > be better to have a separate document where both could be discussed. > > > >>> This is imo an easy requirement also useful without desaster > >>> requirements > >>> - aka: enrolled spares would likely also have better theft/abuse > >>> protection than non-enrolled. And yes, you will have to power up > >>> these spares once a year. Which IMHO is ok. And of course certs > >>> should therefore be somewhat longer than 1 year). > >> > >> This could be captured as a discussion: what does a device do when = its > credentials are out of date? Does it fall back on full bootstrapping? = If so this > becomes a potential attack vector wherein the attacker can convince = the > device it is out of date and then force it to restart bootstrapping. = That would > be bad. > > > > Haha... ;-) i just wanted to show what IMHO are the most simple > > deployment options to deal with desaster recover. Now you're the one > > who is opening another round of discussions trying to figure out the > > best security compromise for those deployment processes. Which is = great. > > Just don't blame me that there are more and more interesting details > > to capture somewhere. > > > >> So, should there be an injection point into the bootstrapping state > machine that says something like: > >> > >> If a device fails to join the ANI after [some number] of attempts = it > attempts to repeat bootstrapping using its original SUDI credentials. > > > > I'd prepare a flag 'operational' set by SDN controller or ASA after > > the device is "provisioned" (config/intent applied). > > > >> During this bootstrapping attempt it MUST only bootstrap on a = Registrar > that provides both a valid voucher and an identity recognizably within = the > same PKI hierarchy the device was in previously. This is detected by = the > device by either (a) the domainCAcert is an exact match for the = current > domain trust anchor known to the device or (b) the EST /cacerts = response > includes a chain that terminates in the current domain trust anchor = known to > the device. > >> > >> This extends the lifetime of such a stored device beyond its own > certificate (maybe 1 year) *and* beyond the current CA certificate = (maybe a > 2year cert) an all the way into the next CA certificate (another 2 = years). That > is a pretty solid lifetime (up to 4 years) for recovery. > > > > Interesting thought. > > > > a) Would like to understand how this compares to just making certs > > longer-lived, eg: 3 years, but doing normal renewal after 30% time. > > > > b) Seem like there's quite a bit of analysis to be done of how > > different parameter/options will work together: > > - device with/without reliable RTC > > - what would be necessary/beneficial with nonce-less vouchers ? > > how about nonceless vouchers with sequence number... -> remember > > ownership voucher and allow for it to be replaced only with one = that > > hass a higher serial number. > > > >>> - If sparing would be cross-locations (eg: spares sent from some > >>> site to other sites during recovery), then its important that the > >>> ANIMA certs do not include any location specific attributes that > >>> would prohibit thart movement. So far BRSKY does not include any > >>> such attributes, but in discussions, three has been interest to > >>> lock into the cert some device role specific attributes, and for = a > >>> spare piecce of equipment, those attributes may not be > predetermined. > >>> > >>> Aka: Desaster sparing means domain certs need to be simple, = devices > >>> reuseable across domain. > >> > >> I agree that certs should include the absolute minimum information = about > the device. The actual ID is sufficient in my book. Attribute Certs or = backend > database lookups or short term tokens obtained by the device in place = are all > methods of distributing additional information. > > > > Desaster recovery seems to be one good motivation to not put more = than > > the minimum into the certs. I was a fan of putting more into certs = in > > the past... > > > >>> - If spares are done by a shared facility: vendor, FEMO (for fed > >>> networks) or the like, one could think of that entity offering > >>> (emergency) enrolment service. > >>> > >>> Such an entity would have desaster proof MASA connectivity on = site, > >>> and the customers would provide it with (emergency) registrar = certs. > >> > >> Ok. So like a Cisco NERV truck that provides connectivity = sufficient to > rebuild a network in place. > >> > >> Issuing a new Registrar ID would mean being able to bring up the = PKI > infrastructure during the recovery process. But this is exactly the = time period > when having as much of the critical keying infrastructure offline and = secured > could be beneficial for longterm security. One could argue that extra > attempts should be made to ensure the PKI is offline. > > > > My thought was > > a) the desaster recovery registrar-IDs are preprovisioned _before_ > desaster > > (contract between domain and desaster/spare recovery entity). > > b) The facility to which they are allocated is shared across = multiple > > domains. > > c) the facility is not "desaster on-site" -> the spares will not be = on-site, > > but will be stored at some central site. Enrollment would happen = at > > that central site, then they'd be shipped onto-desaster-site. > > > >>> (emergency) meaning that the entity is only permitted to enrol > >>> during emergencies, and the customer could be able to verify the > >>> emergency entities behavior by pulling from the MASA an audit = log. > >> > >> Section 5.6 doesn???t include the Registrar identity only the = domainID in > the log. Do folks think the Registrar ID should be included as well? > > > > Oh, right. i confused domain-id with registrar-ID. > > > > I definitely think registrar-ID would be necessary to log so that > > audit-logs become more useful to backtrack what happened. > > > >> If this was done then does it matter if the Registrar cert has role > information in it? As per the above what would happen if all devices = in the > ANI could act as a registrar? There would be a higher chance that one = of > them would mess up and actually perform registrar activities = incorrectly ??? > but it would be logged so the admin could watch for that. > > > > > > I don't think we need many/all devices to be registrars. I don't = think > > we've got a working security model to do this anyhow - eg: > > authenticating all those devices against the CA. I hope we do not = need > > to discuss other roles beside "registrar" in this context. > > > >> Thoughts? I???m worried but see the conversation going that way. > > > >>> If the customer would give the emergeny registrar credentials > >>> cert/private/public-key to the emergeny entities, then the = customer > >>> itself also has the cert/private-key and could ask the MASA. > >>> This option would work with current BRSKY text. I am just not = sure > >>> about security BCP (having two copies of a public key pair???). > >> > >> Sorry - I can???t write text around copying a private key. If = we???re going > that route lets dump all the PKI stuff and just use bearer tokens and = be up > front about the security we???re providing. See above for different = ideas. > > > > Yepp. There should be easier options to achieve the same goal. > > > > Eg: I create a registrar as a VM, and run it onprem of the desaster > > recovery provider so that provider can enroll devices for my domain = in > > case there is a desaster in my domain. > > > >>> - If the shared spare storage facility is Best Buy, and the Jones > >>> family wants to replace some electric storm victims @home while > >>> their ISP takes its days (my ISP C*...*T took almost 48 hours in = one > >>> case), then the gear should probably come with a nonceless = voucher > >>> printed on on a scratcher piece of paper inside the box. > >> > >> Even a nonceless voucher includes the domainCAcert so this idea > doesn???t fly with the current text. What you???re looking for is some = form > of ???bearer voucher??? that contains a symmetric key. > > > > Probably. Yes. I guess we have not discussed how to apply BRSKY > > enrollment for home users. It's outside of scope for ANIMA anyhow, = but > > would be interesting. Some of those home thoughts likely equally = apply > > to low-end IoT devices. > > > >> Anybody who can scan it off the box can deploy the device. > > > > Thats why i said "scratcher", eg: some one-time-unveil where you can > > easily check that its untampered when you buy the device. > > > >> I???d normally rail against this but am actually pleased to see it = fit so well > into the model. A bearer voucher sorta sucks but creating one didn???t > change any of our messaging flow or anything. Interesting positive = that??? > > > >> I???m thinking that it is time for a section 3.7 ???Voucher = types??? that > digs into what we???re talking about for these different voucher = types. > Currently the text is scattered in the other sections. > > > > We could also start discussing those aspects in the submission from > > Kent et. al. about vouchers and move into BRSKY when we see it fit. > > > > Cheers > > Toerless > > > >> - max > >> > >>> Beyond these BRSKY considerations, the next cool ANIMA piece to > >>> consider for these use-cases is of course the ASA driven > >>> "re-configuration" of the spare device, aka: In larger outages, = you > >>> should not except the whole network provisioning backend to be up > >>> and running. And its IMHO illusionary to expect devices to ONLY be > >>> driven from intent for many years (in complex networks... in a = clean > >>> homenet they are driven by intent today..). > >>> > >>> Aka: for pre-intent-only desaster proof networks, we'd need: > >>> - ASA to cache neighbors configs. > >>> - reapply neighbor stored config when replacement gear is = inserted. > >>> - IMHO: An anima definition for a "device-role-id" which is not > >>> the ACP IPv6 address (which will change upon gear replacement > >>> without enrolment support). > >>> > >>> Cheers > >>> toerless > >> > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > From nobody Tue Nov 8 20:32:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550AC12943E for ; Tue, 8 Nov 2016 20:32:33 -0800 (PST) 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 pju8fJgvu12x for ; Tue, 8 Nov 2016 20:32:31 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0061E129550 for ; Tue, 8 Nov 2016 20:32:30 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id i88so119083994pfk.2 for ; Tue, 08 Nov 2016 20:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:organization:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=XLfUqOZEdYdeA4iMpjmiD+pgKyZEvwSbXtfWiF4wuik=; b=KbuDKv9F7yfE0F0UBz2XPNOOL4nQ71JvxgRkA3M4yjr5giC1bPMDYKvwrD5TIIUEMn SxvPpyYy2kbv8tAB1jztjBuPK/fD+gvvkIjWsukOLYCJllbeSeywzllf5J1nJcXrTCb8 skG3bpOcKc6P7YyAjpjvAkIBGnHC/1kEjrZr/xZlu/dA1oMmj9SXvZsA1QbdSiyb0+rj MI1tajpt/9R+LP08WCc5WDo+C9vCUZWwf3z2BY0mFg/buaZZIR0pMruDiGGedT5N45z3 aqyrw+IZLJlPRTjDy8QLCRrLy8dmUWcqO9/HIqUpTaN72fvn+Dl/xGFUAI4w/goEZ1Tm wxDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:organization:to:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=XLfUqOZEdYdeA4iMpjmiD+pgKyZEvwSbXtfWiF4wuik=; b=RPGdWPM06Jq9aTlBWkeztC69pbe6vtwaW+7IvcwiUnY7/gyXQdml3U5o8zodTJpAkP sfUjRCWn0KO7xW2CpBhMYjDR7cf897JpXqhParqPSscSIDvRYLNpiXf+J1zAOby7Fa/p GCiPuu5sY9OaTVzMgd+5FzkZXJQJ9l/nhyFB3X/Te+mfreOUNh6FPZ9NGbKsdBPIOdAg grlJM/iDPfLI+SMXx8NnVG2mAN8pYQmCQ7Tz82ukDc95Rt2zfLdwCkjIDDTIhGf/qjdu 6iW8G6uaKNIhNmrt2vEGMd9bgWS630HmiM6YR8NFcRLw4+qtMjDK+zht1ztoQFn5wPq8 7Kmw== X-Gm-Message-State: ABUngvfOPofyTAAnkOfbRbSItjf56JPtvnGhHARMAoiVet6xBWoX3aIYW9OGOR7tb84LTQ== X-Received: by 10.99.125.77 with SMTP id m13mr12008570pgn.58.1478665949837; Tue, 08 Nov 2016 20:32:29 -0800 (PST) Received: from [192.168.178.23] ([118.148.77.145]) by smtp.gmail.com with ESMTPSA id t5sm51387859pfb.58.2016.11.08.20.32.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 20:32:28 -0800 (PST) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: Date: Wed, 9 Nov 2016 17:32:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Review of draft-ietf-anima-autonomic-control-plane-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 09 Nov 2016 04:32:33 -0000 Hi, This is not an exhaustive review, because I've mainly focussed on the aspects that concern me most as co-author of the GRASP draft. But in general, I like this document and what it proposes. > Abstract > > Autonomic functions need a control plane to communicate, which > depends on some addressing and routing. I think this should say "a secure control plane" because security is an absolute requirement. Similarly: > 1. Introduction ... > Autonomic functions need a stable and robust infrastructure to > communicate on. I suggest Autonomic functions need a secure, stable and robust infrastructure to communicate on. > 5.1.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. An autonomic device MUST maintain this > adjacency table up to date. This table is used to determine to which > neighbor an ACP connection is established. I'm pretty sure it should be "neighbors" (plural) in the last line. If not, I have misunderstood something. > 5.2.1. L2 topology considerations ... > Predictable scaling requirements for ACP neighbors can most easily be > achieved if in topologies like these, AN capable L2 switches can > ensure that discovery messages terminate on them ... This is troubling. Hopefully it's just terminology, but there may be something deeper. An L2 switch that is AN capable is more or less a contradiction in terms. (I'm old fashioned, and I think of an L2 device with many physical ports as a bridge, that knows nothing about anything except MAC addresses.) So I assume you mean "A device that combines L2 bridging with L3 routing capability and has enough resource to run the ANI components." If so, I think you should say so. An important issue linked to this is MLD snooping. You're going to also require that *if* the device performs MLD snooping it treats the GRASP LL multicast address as a special case, when and only when it is operating in the way you describe in this section. If not, it will treat MLD joins from GRASP nodes as an instruction to be transparent to such multicasts, which is exactly what you are trying to stop. An L2 device that is *not* acting as you describe MUST be transparent to GRASP multicasts. > 5.2.3. Discovery with GRASP One question is whether the best model is Discover or Flood. The Discover model means that a newcomer will find all neighboring ACP nodes individually. The Flood model means that it will announce itself to all such nodes. Either will work, I think. I have no strong opinion. I would prefer to name the objective "AN_ACP" (and to use the same convention for all infrastructure objectives). That's a detail of course. I can do some more work on the objective, such as implementing a toy version, if there's general agreement. (Also see comments below on 5.5.4.) > 5.2.4. Discovery and BRSKY s/BRSKY/BRSKI/ Also needs a reference to draft-ietf-anima-bootstrapping-keyinfra ... > When an autonomic device is a registrar, it will announce the > registrar function via GRASP in the ACP as the "6JOIN" objective. I already commented to Michael that we really don't need the "6" prefix (especially after the recent IAB statement). Also, it's unclear to me whether a registrar and a proxy will announce themselves in exactly the same way. Is the pledge supposed to know any difference? In any case, the proxy will only be announced or discovered on-link, whereas the registrar will be announced or discovered across the whole AN. I had assumed we'd need separate objectives "AN_registrar" and "AN_proxy". If we can manage with just one, that's fine. The choice whether we use GRASP Discover/Synchronize, Discover/Negotiate or Flood is also open. I think any of them could work. At the cost of repeating myself, I feel strongly that one of these MUST be supported for autonomic nodes, quite independent of using mDNS for non-autonmic nodes. That's all a bit out of scope for the ACP draft, however. But next: > 5.5.4. GRASP/TLS negotiation I'm perhaps a bit confused. Firstly, GRASP is supposed to use TLS automatically when there's no ACP (and there are certificates). So that's OK. Let's say (skipping some syntactic sugar): 1. Bob issues grasp.discover(["AN_ACP"]) 2. One of the replies is from Alice. 3. Bob issues grasp.negotiate(["AN_ACP", [0,7]) to Alice, meaning he wants either channel type 0 or 7. 4. Alice replies grasp.negotiate(["AN_ACP", [0]), meaning she offers only type 0. 5. Bob replies grasp.end_negotiate(True) meaning he accepts. Is that what you want? > The GRASP/TLS connection can be kept > alive or timed out as long as the seelected channel protocol has a > secure association between Alice and Bob. Why is that useful? > 5.6. GRASP instance details I think it's in this section that you should state which network interfaces GRASP will use in each case. > 5.7. Context Separation I've been looking around for a document that actually explains VRFs in more than one line of text. I suspect it's a term of art whose meaning varies, but I didn't find an RFC that helps. > 6.2. ACP through Non-Autonomic L3 Clouds ... > One workaround is to manually configure IP tunnels between autonomic > nodes across a non-autonomic Layer-3 cloud. Is that really "manually"? I think it could be automatic via some sort of rendezvous server. We don't really want the word "manually" in Anima ;-). Regards Brian From nobody Wed Nov 9 17:55:52 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01188129705 for ; Wed, 9 Nov 2016 17:55:50 -0800 (PST) X-Quarantine-ID: <18e68yYsIOIy> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe 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 18e68yYsIOIy for ; Wed, 9 Nov 2016 17:55:48 -0800 (PST) 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 05F221296E0 for ; Wed, 9 Nov 2016 17:55:48 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id n85so136398734pfi.1 for ; Wed, 09 Nov 2016 17:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:organization:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=F0vO8CLuBOEogZb7knmedbIJUhw1jodLOI3Fkjji/ts=; b=LspXPDBYJtvXFjcVxq9OGfIsxxylNKwylC+jFvTOrbdzO+bw1Cl02+THcDXA7cQUML RvYswafKAISpwhP/us6dWx10cOfkiFSjTW95VABywQjTLuhujIAV7oYv5mgXxQWD52Jt RTueZdO6PQTczkGo+LePOJgVvOp7zLBRVozBTll6aXUZ4CZjb3bt16gACvftwz9Ymq8e IAqSZqGmxOSy95grL4qxAsqylegxgSAI4AwqwZaKwq/JtEWiZJATskkFxuUiVrDp908a Pcn/HdwwWuMWZkiF7QeTZ7JVsbCPgVUfqGj3R7ZPCgks8d14q9V+NSZ9ncRe3y/imKhR 6yzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:organization:subject:to:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=F0vO8CLuBOEogZb7knmedbIJUhw1jodLOI3Fkjji/ts=; b=NqpaBpu9owHKP6XwUe+3ZzM4AEuXUMMpijmphbVqpymHBNTKMHcMB1abpiLtSu9WdK H1Tj+BqJDYFKa1xWLF2VmWvUsVuMse1nSfCrmggM6+RpWmgDAKgsoV61hOi7K6wpDQ0l iOVSZmQkhfsWikwhEu4Bx6QzJZ1tc+t/R8qy+O1WVja/PfV7nutUwfx501rvAExYHsp8 za5DowKSJnlZjo/FBwQnALLp0xiGaxjJ2QBBnOa7Y032os5KKLwyecVdYqWTXBDp702v TYKZS2JWyDTPqsf3xsR1nq1ScMLA9vaOE4+hmXoNnPzK6xDVDcQnGrYPJi+j8JFPklgP JuzQ== X-Gm-Message-State: ABUngvcZFGaU6f4Zm4tqsO58+qREmBZENPbcjbO0iCW/E/L8r2ft8gx/BaiS4NkKqLbytQ== X-Received: by 10.99.181.10 with SMTP id y10mr31609256pge.161.1478742947187; Wed, 09 Nov 2016 17:55:47 -0800 (PST) Received: from [192.168.178.23] ([118.148.122.26]) by smtp.gmail.com with ESMTPSA id f129sm2200053pfc.3.2016.11.09.17.55.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 17:55:46 -0800 (PST) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: <400c1744-d114-5238-c894-ec335f3a5c7e@gmail.com> Date: Thu, 10 Nov 2016 14:55:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] How GRASP uses interfaces and sockets X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 01:55:50 -0000 Hi, This message is part of an off-list discussion I've been having with Toerless, but I hope it's of general interest. The topic is how GRASP will "see" the network when the ACP is running. I've been concerned that the ACP draft isn't specific enough about this: what interfaces, sockets and socket options will GRASP use to communicate over the ACP. Partly this is due to my own ignorance about practical aspects of VRFs. So, the rest of this message is about exactly how the current GRASP prototype handles interfaces and sockets. Hopefully with this information, the ACP team can explain how this needs to change in the presence of the ACP. I hope it's only the "WHO AM I" section that needs to change. The prototype code is documented at https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf and the Python3 code itself is at https://www.cs.auckland.ac.nz/~brian/graspy/grasp.py (under Simplified BSD license). PART 1: WHO AM I? When GRASP starts up, the first thing it does is discover what network interfaces and link-local IPv6 addresses it has, and what global-scope IPv6 address it will use. The way this is done is different between Windows (Winsock) systems and POSIX systems. In this message I focus on POSIX (tested on Linux). (This part is actually a lot easier in Winsock, but completely different.) This is done by a function _get_my_address(). The guts of it, skipping failure cases: for _iid, _ in socket.if_nameindex(): with socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) as _s: try: _s.connect(('fe80::100', 4096, 0, _iid)) _addr = _s.getsockname()[0] if '%' in _addr: _addr, _zid = _addr.split('%') #strip any Zone ID _loc = ipaddress.IPv6Address(_addr) if _loc.is_link_local: _ll_zone_ids.append([_zid, _loc]) except: pass #Convert interface (Zone) IDs to indexes _ll_zone_ids = [[socket.if_nametoindex(zid), loc] for zid, loc in _ll_zone_ids] #Now _ll_zone_ids[] contains [interface-index, LL-address] for each interface #Get own IPv6 address somewhat portably... _s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) try: #This is a hack. We send a bogon to a site-local multicast #address (reserved by IANA for 'any private experiment'). #Then we can find the sending address from the socket. #Note that this used to use a bogus global unicast address #('2001:db8:f000:baaa:f000:baaa:f000:baaa') but that fails in #case of a ULA prefix with no default IPv6 route. # #To find a non-hack solution, google for 'getnifs.py' _s.connect(('ff05::114', GRASP_LISTEN_PORT)) _s.send(b'0',0) except: pass _sn = _s.getsockname()[0] _s.close() if (not '%' in _sn) and _sn != '::': _new_locator = ipaddress.IPv6Address(_sn) #_new_locator is the IPv6 address we will use PART 2: MULTICASTING GRASP needs to send link-local multicasts separately to each interface. So it needs to create a socket for each interface for this purpose. for _x in _ll_zone_ids: _make_mcssock(_x[0]) where the function _make_mcssock(ifi) does this: mcssock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) mcssock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) mcssock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_MULTICAST_IF, struct.pack('@I', ifi)) if not listen_self: #don't listen to yourself talking mcssock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_MULTICAST_LOOP, 0) mcssock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_MULTICAST_HOPS, 1) _mcssocks.append([ifi, mcssock]) so now whenever we need to send a multicast packet on interface ifi, we do something like: _mcssocks[ifi][1].sendto(msgbytes,0,(str(ALL_GRASP_NEIGHBOR_6), GRASP_LISTEN_PORT)) PART 3: LISTENING FOR MULTICASTS GRASP also needs to listen for incoming LL multicasts. That's done by a separate thread called _mclisten(). Simplifying the code a bit: mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) mcrsock.bind(('',GRASP_LISTEN_PORT)) #join LL multicast group on all interfaces for x in _ll_zone_ids: mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', x[0]) mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) mcrsock.settimeout(120) while True: try: rawmsg, send_addr = mcrsock.recvfrom(GRASP_DEF_MAX_SIZE) if "%" in send_addr[0]: a,b = send_addr[0].split('%') saddr = ipaddress.IPv6Address(a) else: saddr = ipaddress.IPv6Address(send_addr[0]) sport = send_addr[1] ifn = send_addr[3] At this point we have the raw message in rawmsg, the interface number in ifn, the source address in saddr and the source port in sport. PART 4: LISTENING FOR TCP GRASP needs to listen for incoming discovery responses via TCP. This is fairly straightforward use of a normal socket so I will miss out the details -- see function _init_drsocks(i) and the class of threads _drlisten(threading.Thread) socket.socket(socket.AF_INET6, socket.SOCK_STREAM) setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) bind(('',_port)) listen(5) accept() recvfrom(GRASP_DEF_MAX_SIZE) There is one tricky bit - we bind the TCP socket to the port number used for *sending* discovery multicasts on the same interface. That's the point Michael Richardson and I discussed a few weeks back, so I won't repeat it here. The other TCP sockets used during GRASP synchronization and negotiation are completely straightforward. Regards Brian Carpenter From nobody Thu Nov 10 08:04:32 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF840129526 for ; Thu, 10 Nov 2016 08:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 CEWxHqQ1JawY for ; Thu, 10 Nov 2016 08:04:29 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4978E12943B for ; Thu, 10 Nov 2016 08:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63017; q=dns/txt; s=iport; t=1478793869; x=1480003469; h=from:to:subject:date:message-id:mime-version; bh=rss3V28mD3GTgK2WwTS5TAmjyU8MtonhnLzZLJ+293Y=; b=I+MJFRCXt7AlIOehA3sSxuUfXaxZzeKAZV5Wig7eEkiYNDIMjEgo7dXv c05X9U/wbJnv/dzLYc/lPuEAIZKvTzjV0cwNXID85RWh8hyU9pziBQHFo IuI9wEA/IQOiCoxXP1mUzRLl4SMsqF+uoEzxdGL4yldhPthj7KnGR2h1m g=; X-Files: draft-ietf-anima-reference-model-03.pptx : 44773 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAQCfmSRY/4QNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzABAQEBAR+BXo02qVOCD4IHiDs/FAECAQEBAQEBAWIohGiBCwFQMCYBBBs?= =?us-ascii?q?GiFGgWpI8i0IBAQEBBgEBAQEBARMOhj6PAwWaNwGDTYx+gXWOLoc3igsBHjeBA?= =?us-ascii?q?IU0h32BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,619,1473120000"; d="xml'?pptx'72,48?scan'72,48,72,48,208,145?jpeg'72,48,72,48,208,145,145?rels'72,48,72,48,208,145,145"; a="167954311" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2016 16:04:28 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uAAG4SEj028751 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Nov 2016 16:04:28 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 10:04:27 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Thu, 10 Nov 2016 10:04:27 -0600 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: ANIMA state machines, take two Thread-Index: AdI7asT0Zoke1dTJRUewcsuTMEjA6Q== Date: Thu, 10 Nov 2016 16:04:27 +0000 Message-ID: <03d8d4c491e6452d90fdbdc254f68ce8@XCH-RCD-006.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.132] Content-Type: multipart/mixed; boundary="_002_03d8d4c491e6452d90fdbdc254f68ce8XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Anima] ANIMA state machines, take two X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 16:04:31 -0000 --_002_03d8d4c491e6452d90fdbdc254f68ce8XCHRCD006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had already sent out an early version of the state machines before, here = an update.=20 To the high level state machine, I added a state "Proxy mode". A node is in= that state when the ACP is up AND it can see a registrar. Other than that,= I think the high level diagram should be ok. Looking for feedback.=20 The state machine for the BRSKI pledge (it's a detail on the ANIMA state ma= chine) still has a lot of open questions. Most are under discussion. I trie= d to illustrate where we have open points.=20 I now tried also a state machine for the ACP. I'd appreciate some feedback = on it.=20 To me, the big open things are:=20 - nail down discovery protocol and packet formats for both discoveries (for= bootstrap and ACP).=20 - decide which (if any) feedback we want to give to the pledge.=20 But, I think these diagrams show nicely how all the drafts fit together, wh= ich was the purpose of this exercise. Feedback? See you in Seoul! (Will be there from Sunday evening) Michael --_002_03d8d4c491e6452d90fdbdc254f68ce8XCHRCD006ciscocom_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="draft-ietf-anima-reference-model-03.pptx" Content-Description: draft-ietf-anima-reference-model-03.pptx Content-Disposition: attachment; filename="draft-ietf-anima-reference-model-03.pptx"; size=44773; creation-date="Fri, 14 Oct 2016 07:12:53 GMT"; modification-date="Thu, 10 Nov 2016 16:01:17 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCKfmBEwgEAANoLAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE lstuwjAQRfeV+g+RtxUxfaqqCCz6WPWBVPoBbjKAW8e27IHC33eSAEoraKAhYhNp4rl3jpPMxJ3e LFXBFJyXRkfsNGyzAHRsEqlHEXsbPLSuWeBR6EQooyFic/Cs1z0+6gzmFnxAau0jNka0N5z7eAyp 8KGxoGllaFwqkEI34lbEn2IE/KzdvuKx0QgaW5h5sG7nDoZiojC4n9HtguTDwogFt0ViVitiMs0M 8gW+VuNA+V8aYa2SsUBa51Od/CJrLahCUuY5fiytP6GEDRWylc0FFroXepxOJhD0hcNnkVIWtxa5 deBJl+eGfzutQTXDoYwhMfEkJUlYNkvVjzBMhdTLTWyC8YpuPgmP9OrLwem+yUreWzEtaJrh2IXg 7OAE5wcnuDg4weVBCLRB8MvuKAV7/ypL3lVMmbLvjPVNzI7cuIpgKuGrEYKVcRUB0v8Fimv9V5Hb VFYU7wpeca5g77suWW/VEY9ibia46IsiaGZKFt7/ZWpmbtZjamaS1mNqZrbWY2pm2m7HVOrt+p9Q ZW9TZj5x6CzqYPdyy4Njpm5ZMgKH8u8+XlUk69r7g+xMmkCypjbPT+bdbwAAAP//AwBQSwMEFAAG AAgAAAAhAGj4dKEDAQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskttKAzEQhu8F3yHMfTfb KiLSbG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr3MzD8f3yRZb/ZuFO+Usg1ewbKqQZDXwVjfK3hu Hxa3IDKjNzgGTwoOlGHTXF6sn2hELkN5sDGLQvFZwcAc76TMeiCHuQqRfOl0ITnkcky9jKjfsCe5 qusbmX4yoJkwxdYoSFtzBaI9RPofWzpiNMgodUi0iKlMJ7ZlF9Fi6okVmKAfSzkfE1Uhg5wXWp1X iIede/FoxxmVr171Gqn/TWj5d6HQdVbTfdA7R57nvKaJb6cYWcZEuRSP6VM3dH1OIdozeUPm9KNh jJ9GcvIzmw8AAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wAAAADcBAAAgAAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTEueG1sLnJlbHOMz71qwzAQB/A90HcQt1eyO4QQLGUpBUOnkD7AIZ1tUVsSOrnE bx+NMXTIeF+/P9dd7sss/iizj0FDKxsQFGx0Powafm5f7ycQXDA4nGMgDRsxXMzbobvSjKUe8eQT i6oE1jCVks5KsZ1oQZYxUaiTIeYFSy3zqBLaXxxJfTTNUeVnA8zOFL3TkHvXgrhtiV6x4zB4S5/R rguF8k+E4tk7+sYtrqWymEcqGqR87u+WWlkjQJlO7d41DwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1 Pey9AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc4zPvQrCMBAH8F3w HcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2EtKxDkTbDOdxrut9Nq B4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKGNGIuZepURPPAjtSmqrYq fRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIGKb/7s6WNLBGgmlrN3m0+ AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU0LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9X H97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9 jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44 hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQDLCHM3NQEAAH0GAAAf AAgBcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAALyVy07DMBBF90j8g+U9dZI+eKhONwipCyQE4QNMMkksEtuyTSF/j1WgdarK YmFlOdfjO0dXfqw3X32HdqANl4LidJZgBKKUFRcNxa/Fw9UNRsYyUbFOCqB4AIM3+eXF+hk6Zt0m 03JlkHMRhuLWWnVHiClb6JmZSQXCrdRS98y6UjdEsfKdNUCyJFkR7XvgfOSJthXFelu5+cWg4D/e sq55Cfey/OhB2DMjiNJgnrR0w1DBdAOW4oM0c26YnIeYx4QwHa/gCLAvf9UsBHEdE0JIC+aRGQv6 iOKJo440hJVNlE0QIo0OcZqNJ446gliribJZBrOJGo5lbx282KED7xJ5YohkOVEci2AcSdQ43F6P Yl/+iMGDsZgoiXkI4jYmxI7D58nTepD+IMjo08i/AQAA//8DAFBLAwQUAAYACAAAACEAS/U97L0A AAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m 1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6 i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DM THG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD/ /wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMu eG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMg XpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE 8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiFZy4s po6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAApMve+yAgAA9w0AABQAAABw cHQvcHJlc2VudGF0aW9uLnhtbOyX3W7aMBTH7yftHaLcTjQ43yBCVdZlmsQkVNoHcBNTojp2ZBsK nfbuOzaGBKimPkCuYvt/fHz807HjM7nd1dTZEiErzjIX3Qxdh7CClxV7ydynx3yQuo5UmJWYckYy d0+kezv9+mXSjBtBJGEKK5jqgBsmxzhz10o1Y8+TxZrUWN7whjDQVlzUWEFXvHilwG/gvqaePxzG Xo0r5tr54jPz+WpVFeSeF5salj84EYSaOOS6auTRW/MZb91dnIck8ZYsN8+SqJwzJYGOO4VtS1r+ xlIR8aucS3Ux4lRl5vooTMI0iENgJ8Z6BBTketOJ99F0xhWR/xtrnSTWyUdTwPF5+xBLFHeC8PX8 MzlBHTm4loOOHF7LfkeOruWwI8ctgG6cy3en2AFbH42APaRfsc/cOI1S3TEOzWat2VEwViMUhier kqzwhqpHslNLtadkOsF6bLEQtvWwEA7FOq0JGzwtTTRdE7qlqAGbGot55sISmL7AkaCuAzaP+Hn5 flwRNqWoMSF4zmbiVaeGoxOQ2S5Ia1gKsnyxYYU6pM4pCgmeUKr9vBKhTx1s3OiS06rMK0pNR+cs +U6Fs8WwmtodMujCyqzqqH0D2y/gfH6r2YAqbYnHBF8IBB+EQl4IhWxxPGgc3omHReO3aMIo0QH3 fAwUyydo+Rwh9Hw0FMsnbPmgIEFxD+hIxQKKOoBSPzXR94A0FQsobgH5fhqbv0APSFOxgJIOoCQM +jv6RMUCSltAmk5/SZ+oWECjDqA4SvpL+kTFvFyvn5jNGNr2LQstZyOqzP3zI7/LZ34QDIZxkA9C fxYNUvjpDUb3eZBHaHaHhnd/dS2BIv0C/rmpSgJOjlULiq7qlroqBJd8pW4KXtsCyGv4GxENr0wN hPxD1XJ4Y0Msx6+Jzjuv1qb/AAAA//8DAFBLAwQUAAYACAAAACEA0efMsbINAACdgQAAFQAAAHBw dC9zbGlkZXMvc2xpZGUzLnhtbOxd627juBX+X6DvQPjHIgNMxhIvumSaXSSZyXband1BMtuivwpF omztyJJWonPpBVigr9ECfbZ9gb5CD0lJtmz5Mr4knhnlRyxLFHlInsvHcw7p331zP4rRLc+LKE1O e+YLo4d44qdBlAxOez++vzx2eqgQXhJ4cZrw094DL3rffP3b3/wuOyniAMHbSXHinfaGQmQn/X7h D/nIK16kGU/gWZjmI0/A13zQD3LvDmodxX1sGFZ/5EVJr3w/X+f9NAwjn79K/fGIJ0JXkvPYE0B5 MYyyoqotW6e2LOcFVKPebpD0NfTMv44D+Vlk73PO5VVy+22eXWfvcvX4+9t3OYoCGK8eSrwRDEuv Xz4oi6mvya266M+8PqguvZP7MB/JT+gbuj/tweA/yP99eY/fC+Trm/7krj/8oaWsP3zdUrpfNdCf alT2ShM33x1cded9JGKOzLpXFb1F9l3qfyhQkkJ/ZPd19+oSus/yMxsi8ZBBVUJWVZbTD9XFhJjW kXCIA1OiukgsZmKrOSamwUxmyQKys4ww5sz1WNecnYj78zR4kG/fwKduLQFOOBuLNIwECtNEXPte DLS6BvyV9UwKx4W4Fg8xVxRk8p+6ncOgxZ4UE54cf3veQ0GUCzX0qBiJi5h7ST0/4utrYDWO3nr+ MEr4CTq/uv7jG/Qu5sGAy9aEalPVy5PgnZd7Vwur1/RlqpNV51R/l0+uVU3uFfdBoAcwwawxwXM8 u2KOsG0YjqUnCZvYsYmqb2qWLMukzNSTRAmhGDcmCTqRF+Jbno6QvDjt5UBZT973br8rRNnPskhj Tgs5H2pukiseQvckOepNJfL8Is7RrRef9jzfByk39aOhF3B9m01NdP2G+qYqlKXDKI7russK2uvW 1ZTlVf/DEDpSv2ysfrl+Q7UMDFm/PIqAV9sqiCct6/J6gPTAzHM9ykV8kcaKPb3EH6agc32R6wmb 53AYZ+TFg2SqUDvTF3+D0VGiupT9X0WFn4KZeViT2VuqXcr2/n1yXXL+hbycZX6nYv5rkXvRYCjQ WZ6nd+giTRIY+TRHdi0LdQUw5gK+qAoo1FCymebxJKgeWeUTTWKziqZATd1eIFOEEZM5lpIp08LE sGdkqlJ5BrOspsqbk6ai7GrdR83FrbIlGV/NlBfFr5Og0t15pBRF2Y4sskII1xCUdglbQ0geW8LE /RIJk/Nc8dxinevWBhXm7zy9R05D4yLJx2rUPlb3EuoyajmaT2zDxpaqY0r3UuIYkpEkt2Dbcl13 G90rTeYljL8mb5FpRXe5B7AgAaTYm1I4GjlIe3sZlTV/vHVdU9F40MrxjJJZv0Ke5wrUtVTsp0m4 cb0t9aEoETwPPZ8Xe9KJi9nSNOaxgGKPLbGAqQGbYdmO2WGBDgu0c/4V/3nMC3H8hzRKGqyvWXlP rR4lHIzhTTrOn6MglUu9Z0+ERcx61bgQjJiqicVopIIc82BEivZe0AhmFjaZQklTUj1BI0yZtg6N HDAaMeksHDHJHvAItgzLZDNeDEJcx6AlHqEWmANlID57PALd4NEtrPh//eXfUXIbCY7CHDr5VSxe 1hrpq4F4iUSqbmrdJO/8+st/0GL9uDZVFd7YKXg5GnpJAKih7F6ARrwovAEvNm9mCfYKozDdJfnP 0TgRUSznhCd5GsuRLqSDZl8mYYlMtrhlNHbaiV+GGobluB0W67BYuyT8yYujQDnBnwoM2avBkHL+ LgZDNeRpQUNb+2ZQGEfZ7ytOa8FFhBkmJh0u+pRxUe0drHHRxBu4O1xEmMNKVTvhFMBK2LTxF+en mcZFkgcygY4m8AeJfFyIUiEqdCSfKVstg38oSsJU3n72jyP1ZB+gwxsHkfirSD/wWd24VcdLsvdH tRjuiWhASU9kJHDtr3od3zRtw8Rttdw2VO7RiW3AZvmIbmwb8lTIJhyJWrT4VBAMWzYlrl4OUdO2 HNXIROxL1KWk3rHgsVqILZb6G+D6utcaUXUW4vEshOQVzYA/QJUIT9wzGwF002XYwJo7sE2wobh4 2nlPqU01d5TXS7mDxwBSCt5B9AOF6Av05HY6sXbmLATOeOLdaVWOtQassivmY5pTGR4bexExIa5l l15EQhmlM9kcxDJNp2T3LqZ58LqwXrFVaFln5+wALZuuaTGjXFdhh7LZvB+bmK7LNKdY1CKk6s0X ApZ34A5sqx8weM5/grHaVwMS7VaY/Zunw5GELMKRRC3LluDIhkJsx5HaibZbHDmNFNpUZ+lh0EjB sR1zVVJIA0iSiWzIi0FQjo4X/ASdCkexd9qTeAfk0jYqP0ZZvFO1+1e1hM2qWqKQ4C5ULbWxQzRn wUrEpnMYlID2lRGjLyxgc1t7RFEI3MyDPanEoyxPbyNA1SHnwY3nf2jGHjaJJZCWWILOydxJXgd1 KXPtWU9nF0voYgmao19L91wcJYOnsu6rQwlkVShhcWKFFK69JFbA+t4g2uHcGkDo0jwP3k7T2j9Z 2+lmOt0WAQQZPsA6gADrIcqMGU+iCcsgS66ZvrAAwpSdLsbAA0URjuOtTSitHX2lCR3HXo4uvDhO xwLR7fx+zHZdQ/qy5fLWJYYzm05FMCgF1y7hvEWooxfAiyfzTm4gkaSWJK4J6I/dSq80C+FGIWIC SlyK+tt4pbPbe7bbq8TmRpmPduFRxKYgOXLe1Jd8cFPTrdaf9dhPikl50hw9nTGwe3fE9tS9CTdO QNq+cenleINy/vM4yvnWiVDb07N9LHAHYzIQL092wCfbU4IQisKdRIs/n5mRpaPgBKFEmiCVAneC 2nH8E04bjwsgC93EsEqOo0LM5Em+bFDfvtNsQ+W0swmXXYg23j+yg1E8PN20dXbFjpTTLqzY56ad DmRuKvXUaaf9UK9Jbx3dF2supVY5ZWh9psBsyIVOjhdo9cXUDpenCLmQFSEXt1xvO6aN6QqP50Yh F2y7TI9QF3J5VFdOHSKsXDl6encRciHYITJYJx17pk2tuazhLzTkMsnr/NQiLrR2Obe6i5p5ER/L L9QlhDFana9h0cpjU/GLS7HhVuxiWLZbOWt27CwyTYNW+7kWeosY1t3tfEWfkq9oX36Ytz9ev0cS Dc1AyINwEr09+wsqAE5sHqfamIZJGxsqnHqrwlU6TgIeoEmoV/tqd7JtzDQd12IqfXCbUK8kUdK3 WNE0NMjUqLWrkMVDfrFoyPcEfpYqqVWKZI1WN1AkwYdDDRbPT12T8ptBRfkCgb30JHR+QAEPvXEs dim361GyrdiyyYEb82K75ckblstMzDSqdEzs4NmTYDqx7cT2ScRWOxNm8PwByesq34UUmhUJJRoW r+HEmE8okTphL3tTMXMk5epgRNslOh9gyn9hS6LWVQZddsmTuyTkErDpktDIbCfZJZbpWnqfGgMj YekEqSnjwQzLIqXx+EyzSyovxC43TNYejR3mprA6G7jN2cCamcEfywm2abtMtqDQv9yROJubQgBn yC2Ne89NMUEt6fyppckpjK5ISe8cDofscNh+GX+Gwua6AD5vI5+jo0ydq/sMRQWKEgRqBKUhEkNe cDRKA148R0MvD5AP18Gy+J/UrSMv/07u48euJD8C8J4Abx+XN9Q4jaVO+n48Kg0eAI+byAf8wZOr KqNV0/yIg/NTCj33kofyrDN0FEYgGtDlEUf6cifqbjeEPkNPl7Wjn6nrm0dqVRqux+glfHnQTCmP mTzt/TlKBvJg96KHMi9JC7hlKIXW/IOnkfCHl94oiqXVB5UP4lJwUcXbpmbvf//6L/o+RW/Prs+q 5ILDcKt9+hJc5WqoaDxS0fhZKekYdiOGbXDr83KApWH4bCzBIwzkhD3BsCYi8nUudlvWyL7ZdM+9 /by5P71LeC5/PwPBSt//AO3Ni8KnERth9fY3dvwOUIVA1wIWSGy7HXCW7ZLKveoyG88epkdM26bl sohg19Qr6GUOFS9ny1bIi8fu8nIR42i/ywZ+1rX8Md0C6fCOB1kiBrM5CfKHPrbLRHAZMeXWOCUD lovp3B4k5sjsgx15idZ0DT1misoJepuCsbtL8w8o4TzYBuVuOq916Lep3raL+sosM1tGldUBdabl OrOHs3T6rdNvB6Xf6h/VaMpB86c1PlYOHAtTadv13jyp8GYOauzkoJODg5IDmarTJgfbpRNQw6C2 ZZdJhza29RFLnRx0cnCoclBH6RtyoJNlN0+roa48lqHCRa5hzYTROzno5OCw5KDeadOUg+aveH70 pgUDM8ulZWAYFgiAkzpB6AThgAWBTHKkW/Ik9KabLTdl6O1hrT90hjG1DKNKt9zjrgwbbJJa8yzL ksCuY3fbMrptGdXOB+9enbj/RsauovBBZkh4qOAZSJ/gqBA82+p0zifz/cvEpCUyv51vAEyeoc7j lqfOgkQb5owJxJi4RO4FU/5PZlKrS43qhP5QhP6VzooaelLWy3Qgn+cg/zJoe6iRPvXxPudq5EHQ FBurKzTOo9Pe38/PXQtfOOfH5ya9PKavXPv47NJix5eMUHpx7pxdkNf/BBozk574OVfh6TcBuh/F SXECN097QyGyk35fMYFXvBhFfp4WaShe+OmoD7IPo9bP0jueZxJO97FhGn05ej3dQWowR/7KQxns ULRVn1roQONcx4HSPHH+1st+uFVDDI0Jnl+oW1mUDMr070kR2Xd47/8AAAD//wMAUEsDBBQABgAI AAAAIQCgPABsNAQAALkQAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTEueG1szFfdbts2FL4fsHcgdLUB USTbSmIbtQvLSYoOSWrE7gPQ0lFElCI1knacDr1Jn2fYgA3YTd4mD5BX2CElJc1fkYs46Y1I8eec 7/zwI8+bt6uCkyUozaQYeK3N0CMgEpkycTLwPs72/a5HtKEipVwKGHhnoL23w59/elP2NU8J7ha6 TwdebkzZDwKd5FBQvSlLEDiXSVVQg7/qJEgVPUWpBQ/aYbgdFJQJr96vnrJfZhlLYFcmiwKEqYQo 4NQgcp2zUjfSyqdIKxVoFON234I0RMuSKU9tq8uZArA9sXynymk5UW76aDlRhKXoL48IWqBbvKCe qJe5X7F0neDO9pOmS/urTBW2RdvIauCh88/sN7BjsDIkqQaTm9Ek//DA2iTfe2B10CgIvlFqrarA 3Ten3ZgzY4YDaV1b1eDV5YFMPmkiJNpjza/Mu15R2WzbMifmrERRiVFOWr20mnedGzy1v8wqlumZ 1TPH1g3SPtdmas44uJ/SfhwShZA5tUkKwn8XeyRlyjjDiS7MmAMV9sc5kjooGU0QztXFn1cX/5Cr i78vz/+9PP/v8uvXy/O/0Gk5VRrMwPNb7W7tPFUZbYYjcgwZKDwYQA5lCpxgKhG7xFQLHeaXxRVc a3x5dyyMFLJgCTkCcyrVJzzWd5xxH9TH6VpB1X+PBGKdyr8TCKtWfx54URSG6w0JkmtmfAYm86lg BfVVk7B+YRPWDzubBiniTphApBOq6PGj2VOpKd2JbY5n0FDI40TSaYhkupgbxyXt5+ASvZhXXIJK Vjdb1sIpa87XYW/nSUdmTjVwZm/eThiuO4tM/trHeEje7832N8iRXJJ22Nq+hafKxFeL2CHDaeT+ GHKFjAeK/AIpM1L9unH3XL08J8eKUUHGVOFTx4B6AqLb7gKl3HPm+ZHNJCgOWr9+au0ln0CZDXJA F0iN98jw9Vw0ZnRJTzijr+6jDTJhaCf8OL6ZAJda/gCOifHMkwO22CC/QYaXq5YCaWquAAdkLsjU KKq1APU4Z63ruo2ur1vOUiBHi2KO7DThaG4ueYr9zrNcvzxF0dWT5vcFVcgz9U0cPd9NnGFVaW36 I27Ho+5We8+Pw1HHj7bC2O/2RqHfjdu7u3Er2u9sdb9419DQcIHgHiTeb9PBaTLD1k2UMlvsPRqc 74TENU2FiOXagTZ1jywUsybEve32uBv7Fq4f7fZ2/NH+9pa/v9WJonHcHY07e19sxdmK+okCV4y+ b4pqHLxXyOKbW+FpyMxmIou6Ig5KeQqqlMwVxa2wrqyXlGNcWju9TrsXRu75FThsTevQ2ojXxW7C 1SEtPyxddqAyjO7YDZWY+HVy3CxBZ7ACJ1xP1JaXtErMmWiq43SBvMBEChkTzODDDctug5kz8AQs bfoIfJ3OXAhNcSylqXE6SdbjlWjbq9VZpyPg/wEAAP//AwBQSwMEFAAGAAgAAAAhAMFw6/FdAwAA mgoAABUAAABwcHQvc2xpZGVzL3NsaWRlNS54bWzEVlFz0zgQfr6buf+g8dPdDK6dxAmphzQTJ02H AdpMU36AKm9qH7IkJCUkMPx3VrLdQEmhU8rdiyVLq93v+1Ze74vxtuJkA9qUUoyCzlEcEBBM5qW4 GQVvr+bhMCDGUpFTLgWMgh2YYHzy158vVGp4TvC0MCkdBYW1Ko0iwwqoqDmSCgTuraSuqMVXfRPl mn5ArxWPunE8iCpaiqA5rx9yXq5WJYOZZOsKhK2daODUInJTlMq03tRDvCkNBt34099AOkFmbMlz Nxp1pQHcTGzOtFqqhfbb55uFJmWOegVE0AplCaJmozHzr2LjJ9Gd4zftlKbbla7ciNzIdhSg+Dv3 jNwabC1h9SLbr7Li4oAtK04PWEdtgOiroI5VDe57Ot2WzlVpOZDOLasWr1GvJXtniJDIx9Gv6d1a 1JzdqApidwpdWeeqsas3/WQPphHLbjOZ71yQaxz9Ik25sUu74+BflHt4GBrxcupuKIjwLAtIXmrr WRNT2SkHKm6lsScXmH3yfg3G3xSnivXaeFcg8gXV9PJej7WOysNuMUatiPdL2WulnEph8aKRBacM Cslz0KT7a8KW+XZv8v9oOisNk1g2dukf3whaS9U+nMsNb7D+PA5o7T+pA/Gq2fnyTuYegZpITc4u J8vFmDwd6gNxsFKiQaMQqcAWMidYfUh2uXz1kmA1JZPp4pmDYwBtKP/NgKo1tyWjxpJcuipHSrGS d2I+4Fu46/oRMA+AU5S9A+v0cdX5STE9QiqfovS3ZmMOkF8jaWIlsQUQxSG/gTH52yhgJf7lKOe7 lFwCNVL4e6PhX2CufJEI51bvxv/8R3UsaevYkpc5kPN1dY0F7Oti1nuKvwT2Euga1fo4Ct6vqbag g7rOJU9X51bYsDhOn7JuNhn2u6dhFk96YdKPs3B4PInDYdadzbJOMu/1h5+DW2hIXCC4h97n/j41 K9dH3JucH6TED23zgZ3Aa2ObGVnr0lHIjgfd6TALHdwwmR0/DyfzQT+c93tJMs2Gk2nv9LNrZjpJ yjT4Pudl26/h4nc9UlUyLY1c2SMmq6bZipT8AFrJ0vdbnbhp2jbUXf9BPOgPkrjf5AehtaMH6xLe tFGM6zdUXWz85cBYmNypX1LYDzZ3Y2/iqOO5LwAAAP//AwBQSwMEFAAGAAgAAAAhAH5gggEcDQAA PHgAABUAAABwcHQvc2xpZGVzL3NsaWRlNC54bWzsXeuS27YV/t+ZvgNGPzLtTHeXAAGQ3GST2ZW9 STq248k6D0CTkMSaIlmQ2ks7ncmDtC+XJ+kBQFISJVKyLmvZ5v5Y3UAQl3P5zgWH3/3wOI3RvZB5 lCZXA3xuDZBIgjSMkvHV4Ld3t2fuAOWFn4R+nCbiavAk8sEP3//5T99ll3kcIrg6yS/9q8GkKLLL i4s8mIipn5+nmUjgt1Eqp34BH+X4IpT+A/Q6jS+IZfGLqR8lg/J6uc316WgUBeJFGsymIilMJ1LE fgEjzydRlle9Zdv0lkmRQzf66qUhfQ8zC+7iUL3m2TsphHqX3P8os7vsrdQ/v7l/K1EUwnoNUOJP YVkGF+UPZTP9MbnXby4al4+rt/7l40hO1SvMDT1eDWDxn9T/C/WdeCxQYL4M5t8Gk1/WtA0mL9e0 vqhucLFwUzUrM7jV6ZBqOu+iIhYI17Oqxptnr9LgQ46SFOajpm+mV7cwc1av2QQVTxl0Vaiuynbm R/1mPpi1K+HaLmyJnqLNGSZ8eU2wxTDjqoGaLLMZc1dmbHrOLovHmzR8Ule/h1dztwQo4XpWpKOo QKM0Ke4CP4axehb8lf3MG8d5cVc8xUKPIFP/9NcSFi32FZuI5OzHmwEKI1nopUf5tBjGwk/q/Sm+ vwNSE+i1H0yiRFyi6+FbdZNC30p3J5LwrS/9X1t7NcPK9NyqOelpdu8pr/b0VxEAH49hX9nSvq6Q 6oatoY7HHNvWe4M9TCxiNzaHc0wZNntDbZsSsrQ3MAmZFz+KdIrUm6uBhJEN1Pf+/au8KOdZNlna ylxtg96S5Fcxguk9KprVhKk4XQxjie79+GrgBwEwNzY/TfxQmK/Zwv7WV+hPukPVehTFcd132cH6 vk03ZXs9/9EIJlJfbG2+uL5C3xnosL54GgGJrusgnt/ZtDcLZBZmldiRLOJhGmuq9JNgkoKoDQpp NmyVsGGdkR+Pk4VG62k9/xesjubQTqp/EeVBCtrlaUtiX9NtJ9kHj8ldSflD9bZJ/G5F/HeF9KPx pEDXUqYPaJgmCax8KpFT80LdAax5AR90BxR6KMnM0HgSVj9hi5S/mUEud7LMUgtft3AV44RT5hmu opbnuU2uMvwEv7lMM3A7P+XlZOtZGjpey12K9PVe+VH8MgkroS0jLSrK+6gmG9hwC1ZZz2NbsMlz 81jx2MFjap8rqttEfrjGB630hzXxtBMgb6U/ELt7kh8axVH2U7V3c0LEtk00IRKbMko1tc0JEbSx Y2iRuK4HDNLT4inQYjsCwGsgAD4EBqAGnzmehd0GkfQYoMcAJQYAnD2B+UaBAsDfxMW3SRqKb8bF t0uYwOj4Iw3hThSogUD26m+WoVwEMylQMPFBrsWfCN5gZ7N+0ZZTu36x2xUM9Y6lYDjlxrajrmM7 tGHwllKDcAvUS69dTly7KAJqahf7ENqFGQqh1LKxBhm9dum1y4oofvBzVEwi9U+gUQR7qnwrqJgp sfzDJ5LL9ma5bG+Qywq0tcjlWmQfzO6spDEhNre0RbwqjTF3cEUYvTQ+VWms/BWlNE5nSShCNJfK dO7r2Nfv5zmccT3YfYSyGqEa3pxK1JtxWM7AD/8xQKNp7F8NYHnQomgtGzcoKk/jKLyFTdMf5Ph9 vbJDdW0tl+fNjkVcnSpjE3FtcdcdiCv8cKpifXXrlkf+flyNfHHndN9GB7xMZBrHItxd2u86hPkt dnPOM6uDXb2DmejMxcQlPb/2/HoS/Ppz8hHxr2fn1k3gTrHMBnDHNjh1a8t6FdwpiXAUcMcYdy3W iKOWAVRCKSj0HtydOLhjrGFqz2JfoqEfx+msQEz7SnbWFw5h2PGM3x9b3GG21j9zWgHjwLNp5fpn mHJNTO0U8yDCsVAjLUfYrjbwot44c5lrZP9yI7LYCDvc6LNW5ZKkiu/N5Hvr/pms+91M+W4soKHA OiywoFFeiPsoEGji58hHYaoSeVAgZBGNtNv5kKpmy6HtjQxrtxo7e5tGSYHuCmB2E/rdmcm549nE ONYYwEPiNcI2NnYcpZwUi9vEw8ZL0aUUfMm69ED72t3erl+7SnfsAA630ik9vx8XRrYw147ZS6z2 pC2kL81dZ7vwgMdsrLxrmge4B9inYRdR5jpepecc7nlaER7Aubyy2A/Sz64GSZoIs3WZykm7jco+ Pj4DbUuf6SV6nUqBHlL5ASVChPtYzrtmpdWG77J428/m5ZbncWrwLvaYS0z8qJdvvXw7UflGa0j/ Dmj0Jn1ERhzVLIBUZ3rpP5YZGPMsm+L2RB7sArOoEPJhBN16yN0l8xY24znFX5WUeMiMgIOmFywm SXyrPhhEe9BbNPMvnkPoq4y1pjI3Tsd9vJyYYOPlJNymYKKueDktomLJishdi3i2joL0oeKvL1Q8 nIjgA8pAoQZPaJRKnYxkWEuxw+UyDx83IWmSzuIQPQgkAGK8j6N8olyix4pXd7Ck19Q/ROdaHED/ UGZbHnZNjqBlOYw0IsuEU1cB8a9M/TTl+HMlJSgosMFvbTKx2v3Wdcrxmmz4Aycl1DnIINMd226k iDEMZGpQPCN9PvxnkJdQu7NqnLvsyToMzrUptTwTOF2QM8wGQ/+LljOlaDnWMZuOfa31x0LgelmD 7BW4xjYFVNdn//WQbq0uFQmAJ3FQ40tlDx6yP5nOiigZw+qEyA9DKfIcPj47o7L52d5SALPl4717 CGDOCXMM0ANEZ1NWwYOvRwCv2/lPdeiR12b2y/j9Er7jc2O7+zBAlSo0x3d86SDkTocBZFqo0LJr 3JuLEp86YCqYsBTBxObNs482AVuhSkRltq3C0J0U9B6EYD1te8vAM3Ysl+k7twaVe2x4BGyoSMvs yC9qG/ieaaqamEqPkEUASTQ9Qg5YnaU0wh7hzoYTjCKOoyw3EZoeQHzpDnlnRU86h9KTiw4Ryplj kaah0jtEnlNPOrRNTzpaZGzhB+nQk+bk2mH1pPKLlECLEFgJY/gspmiBKVwGdFzMXLrhwMaSmjRy qneKPHeRAKd2jbQXqZj7StYXCaiIrkrvXKDHRUrd0y1HdSUeE143OK1Bf5gq7VsW5bGMGdC75U6f AmsAtiIIN5RHUTirRRB6SzLyAIJw7WFi6ri2KpWiMz6whylvOouwU7uKXEq4ewzL4cxl2PJqINnb Ds9mOygqa/ofvb1DyvXpY88hHu0QctR2rE1KdmuUVpHIHLb1CT9fnH2hJOYKwc7h5m4Eq2RgfdIL QGLDrugptqfYPSh2JUXAO1SKAPFAOyuLW4d6CBBuo9CDyzxdFE0bNGA9e3sl73yURZz/c+bLfWzi +cYcItIR+0uVDdA4VUGFMH04lvXcUU9KFb5bKShlLbtJ9on6YcYs1+6q+UGIy/lyxc8+6vfVRP1U VrZhhuu7609VesmqM3c7avvNc3nXF/moS0iuJtTsnU/TXnypKjPpOB5tStyqzKRNGOnTak6+tJ81 r/ex5kgoNsVc9jgTCra1Y1Jr1p4fXjoT6hLCTYTxCGdCOTfx6q4zoRZ3qnph/ZnQ/kyoORN6kFyO /UcT5ShKdJEq0FvnHanGn2qAf3mTFuISvVO1tMJUqBrvBZpC9ygqUC6EOlkrxThSUl8i0G4pTEbC L1Itc36O/j4DhFpMfPVPSIGgH18Xejj/65rZfizkbOaZNeTcfilnjo2Jaxs5h6lDsdPIN+3Pvvdy 7lTl3M8jdY5g6n8QphCeDzyZAQQuhILH5+cNYfN5HH/H89LZaxl+oWz2LgzvcmxZVdjAdS3XWK9L YQOYWuUzA2CxyfOwK8MT2yVVzKKV488o7EvP8T3HG45/IwRYUCkKxShKBMr84INQzzFRT7c5/wyZ XSnWdl6n+x33dyziUlWxvu1xJR4lOl/s2JwOMouawlAdnM6Ime6WNdO2qXvVC4QvXiC8/u3uHYoB motlb/BJGBZ6cDnIiM8ShjRd3Q0Ysp/T29gdZUKNQ5hjfNoLdgfl8HV5eplB801H3XYVTh7zjLOy C4VgF/MqJbGHIV+91LlNJUrSh78pHOLP4qI8Wt11jvpTDfWP3/8LZlKUoBwouywQ9sfv/ztFP8wr MNyksugCP0ET/16Ujha9uJHIP0eAh1WFhpWIId4v7cFxbJXbbx4RSFlZnXzRZ+O6TmXCfZF1nFQN A+EHE2hlKpqAWXD9BoHc9kFgBc9/GhTjOij2SowKdCNhIEjt/j4bbVsudlSdGl3jA1uENHL8CJjH vHLO2WBRG1XWvtMxDE6PbUv1yDA3J466kPvGcseb6j51MGAfGTu1jBn9Uj0dFghRb7h+h2Yyuhr8 ++bG42To3pzdYHp7Rl94ztn1LWdnt8ymdHjjXg/tl/9RT5vF9DKQQj+I9ufqgbrw5cpDbKdRINM8 HRXnQTotn4Z7kaUPQmaqgNoFsbBVPlVXLyKhKkcCyNJARj226tWQ5/xBt0EsX/vZL/ea/eBmoIKG +qssSsZl/HneRM0drvs/AAAA//8DAFBLAwQUAAYACAAAACEAptZ96cwNAAAqkQAAFQAAAHBwdC9z bGlkZXMvc2xpZGUyLnhtbOxd63KjyBX+n6q8Q5d+baqiEX0FlPVs2Z7xZJL1rGs8m6r8xNCSyCBg oe2xk0rVPkjycvsk6QsggdBlhOSxY7ZmLYSaprs55zvXPnz/w/08Anc8y8MkPhnAV9YA8NhPgjCe ngx+/nQxdAYgF14ceFES85PBA88HP7z+/e++T8d5FAB5dZyPvZPBTIh0PBrl/ozPvfxVkvJY/jZJ srkn5NdsOgoy74vsdR6NkGWx0dwL40FxfbbL9clkEvr8TeLfznksTCcZjzwhR57PwjQve0t36S3N eC670VfXhvRazsy/jgL1maefMs7VUXz3Lkuv06tM//zh7ioDYSDXawBiby6XZTAqfiia6a/xnT4Y NS6flofe+H6SzdWnnBu4PxnIxX9Qf0fqHL8XwDcn/cVZf/ZTS1t/9ral9ai8wWjppnKU9/F1asZ3 rg6bk6JOOatrkXnhdCbAeRLH3BdJBqhdTbW62BvnQn4xF9sD+SkHgvQI6g3rS7J0Om9fD+wghxGs Z0oYll8aa8OYBaltt83ZG6dZLt7xZA7UwckgCmM+UOe9ux9zYZqWTdTpKNYzSaIwuAijSH/Jpjfn UQbuvEh2r/8r7lFrpnp54+Uz0y6aquOinep0VM5PfoqHiJubfeQTs1BQD0qTKq9u5vm+pE5Y9SJb q1YTecfqQmv7hUV7vWSTiXyCX3NxdYW+cxIvLp6HcZK1dSDuqzub9mb2ZtaKGErS20aDhG2gQUI3 0yBGR6JBbBHM5NBqNEhtTGyMexp8bjSYFwS4Sn2oJL5PoYg40P3p3ytaS39M/M85iBOJ62r5Kjpb JjL1mc6AeEhlV0J1VbQzP+qDLdTnSPKzDNRjRiFq0B60KKRMNVDERzGlzgryl89d3J8lwYO6+kZ+ mrvJJZyf3opkEgqgVuva9yI5VneJyhaNo1xcq1XUI0jVH306k4sWeUpd4PHw3dkABGEmNCuAfC7O I+7FlZwSr6+lyOXg0vNnkhXG4PTD+8tT8IbfSdGu7ib0PXW/PA6uvMz7uLb7gn30JMvJ6fnuAjCr Mu40y5IvSyizRdARZxlk9HDLn1jxixliN/hhtouh62oKgMyGUEJRm3qAmW1Rshl98mKq1RwN22/E IuGF0ds4KIk4C+WjKOi4R5avRxa3Qhb5/M6Se+DUsAUoOtartqJAbqUTZmEIDZ3YlGLkNqCCYMdy mKEWZDPX1Q3WU0sml2cTfcSJkj1meOswBnzJPImPsTQdBiAT0XmihJhZ21QBz0VY9Pz1MJP/U05K g+NGwPHkXYYNaNm9Q55lWstv6dhP4sne/bb0B8JY8Gzi+TzfEQlbOu6EiYp8toAi1LdYj4ol9B1C 81qGPkRsyGCDpCvog9Dpoe+pQx8kTeyDWpQdGPyQ0ohgKZQLSnExJgy+OOwLJyC/lY8+zye30ZFA ZcMDr2y4j3I5NfMAuDDdWt0kWx40dZlEgsIYYwhSoollScoxBgktnjSRTx0ZJNrzSW/hcLSJ1/RP My/g5jRdttzKKzaAwA7o8dggEC3uvAoCLQywIHrgxf4skaLUF5l5YKuUrhDAi6bxUqNOxP+XJIzB IQX06fnV/jzU7LCDlLa3S2ltJjal9JKFoljzKCYKRowhpJl8VU5LrdSMrJfTT94Bh7dTGW6lsoUu WBHZqoVMrSPRH5FGsMvWmchST+zp76nricRq6olYa2uH0BMdqHwoBaUw5hoNdEEp0nC2pSnx0vRE KdnAb7/+5zb97df/1kTcPmofqZCjUPtuIy8D514UJbcCGO/53gqgQyyHKvRQbg7iEJs2PaLMlicd 8wgZko9TP+L1j/ALD6ZcjbQY4eJxqoNpUMzFC/4h6WYyj7yTgaR0MHSpU3pjlxuh5UYUEVzyQ9Hl DgTSa5pH1jT345X9IjOKjwwli9efZmEO5L+zj9d/ff9H4OUg5zwGk0wRY6To8E/qjPw/lVql4Crw Lv/OjbN8f91z75Ev7rEnFFRe9o/JbRzwACwsQbLwr3e1BCHCto06W4JqiGp86xGgxttLq9bO2+uX /Hzdkh9JUdiIHts4fIe77sHhwednYUuuPsf6NG6m5TTW8PyFp7TIBxDwiXcbiUMy8W4j6crDStiu 5eG6YtaFhwmBkl+bMYueh3se3oeHO7Pt+xh0cvccl1u3ZnBtD+TQLYGcykJfNd6lOXYk490hLrUb crw03iGGUKsMvfH+hI13uhLkoQcL8kh7y4GooBQb26SRDIhs4iLbfXHW+7uPp9dX4E2Y+8kdl6qG p7FrLOX0NFQskYGJEos7GvZbM/PKB/w2uqm7A7cAytZ0maUsqq+DE5AlQpGekchgEoXpn0vOLInH shEhxEQIISEu1okXS8Sjk2tKTYMxQ7braedGslo1d7Kr00ASKNIgtsFpACnC1d3btZIeuo4BXavR Sp1UsLd6yxAljBrAQtiVJNcQbchxXGUiK5qzETIk2Ycqn2Woco1uuGfovCVyfrjAObIkJboFDPWB 8z5w3tAnzpJEKL0hTcN4+uhZI7jyGVbhn7qncH8NktrYtZldpAmpXGkN8Eup/JA4Dn2JaUJx0sE1 te+TrpJhFyhnZOBBYI5CJg2GhprXw1wPcwXV58LLxEEThG5K4Dxor2mW3D88OnMqW2lDFLdu1H91 FBdZ1FJcqDetWNg23qg1UVxiMduoK4eP4jpEocHWKG6ZNdIHcfsg7qYgbjdW/XZx2sr2LXUuUjd9 D5OajTFG1G3oXEpeW+Tlee3MzrdjbEz5wMPp7CbJDro5JSjcizwA3x1j0PM3H64POeA/PL7EXNnb RQ61uYtADAkq1FpGLNg0XBzLsUvDhTCp5GpvwaPwUP7LrZd14aKFXncIra5yere4u49ywyjJO5hO u6eFb7Cjqmjfkh21CO/tpaC5xMXMJNe4NrJWQi3MIa6FDgXaOyL1Y8JzkHkTcZR9gyEXB903OPTi cO4NK+NDeW2OMvDP/CGMJ5n3+I6Caj/+j3wiwFnm+ZLC67vyv5bCMVUhxILEEcSUNraMIQKR8hUp CocOtiyjuGyo7SDHpoe2o+1BITM5cJtMj60JKvtWjOhDRM8sJKACSSsxgW48sITy1GIMOU0W6FG+ R/lHQ3mKW1DeoPJBUL61gFQN5aFl26hH+R7lvyHKt0V+u4V+bWoRZrIQMHOxbTeSbJEDLYsdLOr1 jVH+oMB+ACyvw7cqRhIn89Af+pI6syQaprIDXncD7UU31aarZfDsttdqGTxbK5/VwJM6LoI9ePbg +Q3BcxFQXtmqQA8RWC5yuRxMbZOU0G9V6LcqfOutCm9jKUciXs/vfRZbi1i1tYgOr5IwFuBaeBmg 3XYVqRRbC5blKFzCmmYthrZdBpxkA2jqGGzaVuBldJO3fD3nXVysq9e5TSit5dmdhFIfaX5W2Z6V A7/GB8ZW3Z8PKMOV7eswyppBo54Pej54WnxQuTjrfNDNy8ksZFG3SDayoFNYKT0f9HzwVPmg8oTW +aCbL1TttETUsIFLbeQ2qnT1bNCzwdNig2YKqjTjTWmvDjoRhqosmeYB5iKT5rZcJJk6Ktf0/zfi NQaXScbBlyT7DGLOgy52476JUu3qrskx2d/NjZFF1O5fvcPJpkUOVI9vPb49UXwjzYh+PcW+m9Zr KzeIiiZpqLMIbkIdQtjFqlbbsVPsCWaw2IWz1ok/dLBtUtb6JPs+yV68vvz5+hPIJbtVeccPYM7z 3JvyHHx3w33vNudAzHhRNw1cnv5dt++Q9vvtsu8rdb8VB7pp/Q6RstApNv4iRPFKnTSXWqR8gwzG FjlawUSGS8t7PQ5g5lYlgnscePE4oF7cB0LB5/lYV0bUm26ADu4/Q0anzRITNUY3b+/pEPYg1EWO CXtI4W+ZV3UsR+sdQss9dcdkdIKrIk7rGR0SRqqCFz2nv3hOD7gfqneQFkYpSDrU7m/Lbuw+woPt UOo+FDACuujTM8RAlWi2HgNZNwyEFrYdqmBWx7ywRMGGEwAyYjlljbBjgqDjkvINXGtBEGFmlf6l HgJfPAQq5AMiAXkqsXDyYFi8NHuAeXnxc+T4ZkprneO7Jbc6xHYdVLz5idnQsRsMX3NzICrVji1u v73NG6t4/+IGhrctZiod9AzfM7x4bV57CmZeDjwQJOr148DnmQgnoe+J51jwXWUDr8vANIzXMQOz COM7ECmu7zMw+wzMp1bw/UrVAAGXSXBQ/n3M6tFs+7uR2ZaXI1cloluqvdpdq0e3F3jVdaRNbTcq sQKuuD8KFcDUee3rSD/tYqyspTYc65bCTyyXaNOvrw3X14bbWhsuOWwRt+dXGm7rayirqFWzELh5 +e6Gd0SXEqBU4JaEQ01u7F8LHFqO0biW+d9FlFlFAlybhIAWZo6yVnfl/1oNcMPPvYx47BdVwkpb WaHDLUpKRWz7ayJrCs/ro781NBQKbRciU4KeYKmuNN9dTJHrqACO3k5Z0GJPf09XR7Hbty+xbtuX iGVjrFIf+3T1Xjd6Mnls+uNTxvWAJCVq94c+ArdZeDL419mZy9C5czY8g+RiSN649vD0gtHhBcWE nJ85p+f47b/l5FNIxn7GPREm8fsA3M+jOB/LkyeDmRDpeDTSa+Plr+ahnyV5MhGv/GQ+kswR+nyU Jl94lipeG6kA90i5zAZmEaVAR66FXcMNemjlp/HVSI68jgLNmVF26aU/3Wn2k/cSPDvXp1RRlUIU LJqoqcvr/gcAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQB juTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLR XGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j /WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAI AAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEu eG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02j eFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQ yZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF 1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEAXpnptW8HAAAeMAAAIQAAAHBw dC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxaf3LbuhH+vzO9A4f9s2XE36Q0kd9YdpR6 xi/1xH4HgEnQZA2CLAgpdjpvJmfpLdrj5CRdLAGJciRXdpJOnJE9I4KL5QLY78Nil9LrX+5qZi2p 6KqGT23vlWtblGdNXvGbqf3b1dxJbauThOeENZxO7Xva2b8c/fEPr9tJx/JfSSepsMAG7yZkapdS tpPRqMtKWpPuVdNSDn1FI2oi4VbcjHJBPoDtmo18141HNam4rZ8X+zzfFEWV0dMmW9SUy96IoIxI mH9XVm1nrLX7WGsF7cAMPr0xpSNYX3bJcnW9vuk/39PCqvI78JLreqBBJmiZnjBhLQmb2tc3nj06 ej3SyrqlHu7aK0GpavHlW9FethcCR3i3vBBgE0zaFic1+FcZwA6thrd8iY3Rg8dvTJNM7gpRqyu4 x4IZAor36nOkZPROWlkvzNbSrPzbFt2sfLNFe2QGGA0GVavqJ/flcnyznKtKMmpdMJLRsmE5cAVd hLpm7l173mS3ncUbWJtyRb/UlUa/fnVtS0vet2BWKrNar+/ExnpiW72SBikgjMsN4sjzo03/eG7k RbFSUAv3Aj+K4mBj+WTSik6+pU1tqcbUFjSTyASyPO9kr2pUcE79TNqJvJs1+b3SvIYreAm2HDxf NuKjbbEz3k3tsReGMLbEmzBKfLgRw57rjR7JThqGMBGegZ2pnUmBc+FA8OOFbIpKz6gfUnWxTl7K e0Zx3a36QLGACTGidjzlzm+XsONrecIo4SteyKMTVmW3lmwsmlfS0hsfcYD4ACbVQBKHQ5OU5xdE kPdDy29n2pst+sb4BN30OJ+CFZ8UWEM6+d+CTspBtt7bX8MqL/Wj+HFahUHkBUH649PqyUxqFdRL fBaF25mVV0JiWNmfY8qRSLFug2M9jx4Ojvg9a/BLmjU8txhdUrbHQEi8Zw10VVZi/3EwAj1rnHmz ELLce6Dw+QNVxdZxdkaBtblnxoPYxINLVuXUereor4Epw7iAm/Br4wJkOGAa1vxxav9jQQTQUYcJ dNbTwkTsuRgFYN1xACdL9OB49pMwwECiwsT6fHpBhw8uxwQGbC+Zp/hF2A3wpT+dclooOiiXemq5 CE0DMM4rxrYkVfKuz7VkxWUvSSLXNcxZKfd3azsjMxI29UT69mCCuAMKliOp/jnzZ8dp5L9xZu5x 4ISRO3PS8bHrpDP/9HTmhfMgSn+3V9wA5nFgxxf7RRF8yy75/Onff/r86T/rHVKo9PJbn5Tj4Uk5 a+4sPGpWNLeUKXPM9fS1Fh0Vp5CWq/x/Rev/xWbfj8djTeaxm3jJg0MvHHvjMNFkdhP4+xoyq6NI 4drPbievPwgCO5tDofLwJOtadY7Nn5cRIaCKr6Hano+GwrM3V3NrnPzFetcsLd/14j0D4hbzzySA 5xoGvAeXwhiQoI03OPB1yIe+G3qpp6GHhCd5EMcCdxx5YfCtoN8T7/8nyFDDFtKpqCwcwquaOIIW VEDZTJ26ySlz3OCVvJPfBXq8mGISXA4e0y1rISoVxGbj2D9JZ44KWE54Ok6c43kcOfMoCMOTWXp8 Erz5XdW3XjjJBMXS9yw3RbMXflE211Ummq4p5KusqXX9PWqbD1S0TYUluOfqOh7Dc5ymSRJ6rjki YWrmipNVZ66urDMmfiWtBXXz1GYSOAXBfmrnt9C6vvGVzFcyX8mgRbIMinXQ0A0j8Y1kpRMYSWAk oZGERhIZSWQksZFAelGyit+CL9TFtoqG/bUXmFa/oyBBOCf3zUKe5RqIgaSvhL0wCdMgDiFYiomS iLNcR99dupE6Yo2uLnB26voDXcwVH9ENB7oIzyO60UC3T0S2LbcsrDIXuFEK2V9zqSmsuIvbrsO2 KhV3ZAYMnqLFFbm+/KgTjj7JQHuUnPOZuMV3JOo9D9e30FXCPqr4zcWCZ1L1o2V+2WZ9NMguMp0y jN11yjBUmKm3NJuqq8xi1Xu9eAcRBvf+IHnpJ3lLhQqe+yYy2vRQC5eEOUUB2evU/nP9d4dJHVLJ gw5K9Gua7kFH1mnbW5OeTe+3GBm/gKIm4hzw91PMUisO2Q041TGCHwcp2fWq3iANHIA1byBRXHvn WFQEZt0S3nRw6/ruDPLwEK7mH3ZFW8msnJO6YurMAkFWEtFRw2Rl9gQkKJ7anz/9q5cO6OCn34sO fBcd+C468MfpgE1/DXmcRjj5FwB59CMh/t0CwDdEXMGsEQ/WiHuQnymfHyB/IuTotB8ccoWzhjwc QA7w4tuFA+RPgtx7CXFd4awhjwZHuRslCOMB8p8PcoWzhjweQA6V90tJ3w6QPxFyhbOGPBlAPk76 2R8g//kgVzhryNM15EHoK6cfIP8ZIVc4a8jHA8jTND6kbz8p5Arn/sdC6/cy7aSRJRWrtzTwxEVP DL264dezK6NaZfOVznchyUvz8fZXH/h95sE/O18UGCcc/LOjqg4SVVgfHLSrBvVSP8XZHxy0o2LD Y/zgoN31jflZzMFBO6oBmO4hSD+WO8dRcgjSm5nmMLnEHxmYL2r7b3n7n14e/RcAAP//AwBQSwME FAAGAAgAAAAhAJZnxxjwAAAAJgQAACwAAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFz dGVyMS54bWwucmVsc8TTzWrEIBAH8Huh7yBzrybZD8qyZi9lYaGnsn0A0UkiTVR0dmnevtJS2MAS eijkIjg6//khuD98Dj27YkzWOwklL4Ch095Y10p4Px+fnoElUs6o3juUMGKCQ/34sH/DXlFuSp0N ieUUlyR0RGEnRNIdDipxH9Dlk8bHQVHexlYEpT9Ui6Iqiq2ItxlQTzLZyUiIJ7MCdh4D/iXbN43V +OL1ZUBHd0aI1FuDr2r0F8qxKrZIEji/rU8urXgeAeK+rFpSVs3JyiVl5Zxs+58yyr04MX1XftZZ xmbJB9rMydZLyta/MjH53fUXAAAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m rYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0 FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7 M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP// AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0NC54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vR goPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxr GHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5 R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAA ADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOMz70K wjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtg ne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHN HXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIB qm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEAcO8DOEUEAAAyDQAAIQAAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxLnhtbLSXa27bOBCA/y+wdxC0vx29ZdmoU0TOAwXSNFinB6AlOhZKkVqS du0uCvRau8fpSXaGoiw7yaZ5tEAQUdTw4wznwfGbt5uaOWsqVSX4xA2OfNehvBBlxW8n7seb80Hm OkoTXhImOJ24W6rct8e///amGStWXpKtWGkHGFyNycRdat2MPU8VS1oTdSQayuHbQsiaaHiVt14p yWdg18wLfT/1alJx166XT1kvFouqoKeiWNWU6xYiKSMa9FfLqlEdrXkKrZFUAcasPlRJbxuwVlea UdcxYnINE4F7DJYXM1Y6nNQwcYMSzoxVJTWfVHMjKcURX1/IZtZcS7Pian0tnapEgl3pevaDFTOv fG0G3p3lt92QjDcLWeMTDsLZTFzw1xb/ezhHN9op2sminy2WHx6QLZZnD0h73Qbe3qZoVavcfXPC zpz2IIKdVZ2+qrkUxSflcAH2oPmteTuJ1mZ8Nkt76oWWhmZF2+9m0Ovz4GEESRj7fmtmEIRhlEaH BzMK4lYADQ6jbJj698xu2c1Yb3JRbnH1HJ5gLuHFUkCQzlsmU3qmt4ya8ZoFDYqwW270d3G2pIs/ YVJ9mbgp7tpuZGXb8R6jwX/GKgmLGMEEpHzwcQYJWOspo4TvnKePp6wqPjlaOLSstPOeKE2lY8IV 0hWISNdmD4OkvLwmkqA6O/JFbjVqjN2dveYIHnd61Dl9tpq3e4Y/w+9qNW/9DpugN1/l/yj1Qz/K HvF/kCbJMDWaP8X//+v0mshLk0UVL6GYmOFhIMxXV1A8DWAvJlDXuzFhhmFPjZNhiPo+F30Qbsiz 6KhHt2fxbHSQ7aORZ9Fxjw6iYYCZ9Wx2n44WaNnJHjsLM1ThdWwEWnbas8MwM4n6OjYCLXu4xx7G 0UtcechGoGVnPRvBL/LlARuBlj3aY6eJqZKvYyPwV1Q81RWgX1/0Rruih5e9c7Wq56DANSMFXQpW wjj5KUWQlYB2zRn+tSISrLT1MH52PczSwDe+g2qXRgn83WkUdkGJ9RA8HYTGhl05hGOSSl9QUTs4 mLiSFto4nawvlbYnaUUevz2hx4T1cIF+cR32jitbgKDTMi+m0LmO3P8yP/ii2VSwNvzsRYwB+IOr +N5FHKC5xjUC3HheMWZesEWkUwZqEthDb7DPg1iquG5nhklfUXfC7VvP8bqdfnzPL6CBxKD6Ow/z kywJzwa5fxIN4sTPB9noxB9keXh6mgfxeZRkX7t2VGHkcYiOezkDYf1Qznz/9s8f37/92+cF7Puy zDCPrrWF8AHv25GzkhUako/ScJrlA1R6EJ+OhoOT8zQZnCdRHE/z7GQanX3FFjmIx4WkpuV+V3bN ehDfa9frqpBCiYU+KkRt+36vEZ+pbERlWv/At826cRG8J/4oGibtjW50655GW0y8GdoPTybfk+bD 2iRNbUrJ1Ew18NvE5mgvgrZ3v3WO/wMAAP//AwBQSwMEFAAGAAgAAAAhALHdjH4uBAAApA8AACEA AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWzkV9tu2zgQfV9g/4HQPju627JRp7Cc OCiQtkGdfgAj0ZG2lKgladduUaC/tfs5/ZIOR5JvcQp73YdFFzDMi4aHM4eHl3nxcllwsmBS5aIc Wu6FYxFWJiLNy8eh9f5+0oksojQtU8pFyYbWiinr5eXvv72oBoqnt3Ql5poARqkGdGhlWlcD21ZJ xgqqLkTFSvg2E7KgGpry0U4l/QjYBbc9x+naBc1LqxkvjxkvZrM8YVcimRes1DWIZJxq8F9leaVa tOoYtEoyBTA4etclvaogWvHwp0XQSC6g6VqXEHcy5SkpaQEd97nmjAA7ZCxKDUhooKp7yZiplYsb WU2rO4nj3izuJMlTg9OMt+zmQ2OGzXKBFXtv+GNbpYPlTBamBDLIcmjBmq3Mv2362FKTpO5MNr1J 9vaAbZJdH7C22wnsrUlNVLVzT8Px2nBqOtx1VK2/qroVyQdFSgHxmPDr8NYWdcymrLKGeW2gGrv6 I1Y2zjRk6WUs0pWZ5AFK7KQDrvRUrzjDRmX+0A0J/nJqhM3KzvspCLvQY85ouSZEX455nnwgWhCW 5pq8pkozSdAZ2AYAadjRyBFCsjK9o5K+20a+iRsWK3S69dBuKXyeSL8lslETueM0YZngKTjhnUdr ni43Jj+B0cqEvOBr6s5k2MgWCVY7DNcs7k+JYZww5ZQlAvYoZwvGj4BHpk+Av89yeTy6fyL6RMyl zo6GD06Fz2cH0X+2tnuttq+oZjvCRkLOPS9SDdF9gjOf8plVix2X8XmxHzhIIz+CKwBPyK4fwm/v TPV6gY8G5qz0u6HrhTsHJtAilb5hoiCmMrQkS8yVQAd0cat0w1xj0rBWO7S/6cyVDOMzIT9ZhL8q 1dDqu0EAU2tsBGHPg4bc/vKw80XzscDdCddTAjhDK9GyDqfdzFhfcNdoh/JHUAVHZ1M2M4tu6HRN uLgkgufpJOccG+ZGZWMOblKYQy/NxQjayeHIwp5e6DjtXbI2rlsbHLudCauNI3V9y0FU9zNSJGku 9da1dbIoo1aUEyHMMbQtS9xI58pyBpwjkX/NqYQZGmmi5E+SZuD4UfdH2gxcN4h+ZW0ak/+XOvut OqfgFSNv5sXDnkZxic/VKLzjAfqQTHELnHaCdl3nhzL95Y/Q/6pIZ5C0GFF9jr14FIXedSd2Rn4n CJ24E/VHTieKvaur2A0mfhh9aRMgZZRXgjqePCeMwA88J759/fuPb1//2TwlYN5/95jAok2kQD6w +k2NzGVuAon7XW8cxR3jdCe46vc6o0k37ExCPwjGcTQa+9dfTELmBoNEMkzyXqVteugGTxLEIk+k UGKmLxJRNJmmXYmPTFYix2TTdZr0EJfIi3pOP3L6TvvSAN/aEr01G29q4oeSy9e0ervATVPgo3eM XRVkw80e3ZiY2Nvs+vI7AAAA//8DAFBLAwQUAAYACAAAACEAEexTcGQEAABIEwAAIQAAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbOxY227bOBB9X2D/gdA+O7rbslGniJy4KJA2wTr9 AEaiY20pUkvSjt2iQH9r93P6JTscSbaTOIHd5KHoFgjM23A4l3OoCV+9XpacLJjShRRDxz/yHMJE JvNC3AydD1fjTuIQbajIKZeCDZ0V087r499/e1UNNM/P6UrODQEdQg/o0JkZUw1cV2czVlJ9JCsm YG0qVUkNDNWNmyt6C7pL7gae13VLWgin2a/22S+n0yJjpzKbl0yYWolinBqwX8+KSrfaqn20VYpp UIO775pkVhV4a27lxfVfDkE5tYAZ3zkG17MJz4mgJUxc3UoyksKAGlzS1ZVizPbE4o2qJtWlwh3v F5eKFLnV0Ox03GahEcOhWGDHvbf9pu3SwXKqSttCJMhy6EDCVvbXtXNsaUhWT2ab2Wx2sUM2m53t kHbbA9ytQ61XtXEP3Qlad64Kwxnx11619urqXGYfNRES/LHu1+6tJWqfbVvN2rBbVY1cvYidjTFN sMwylfnKHnINLU7SAddmYlac4aCyP2iGAns5tahmovNhAqguzYgzKtYBMccjXmQfiZGE5YUh76g2 TBE0BjgAKm10DMYIVTKRX1JF/9zW/CZtolih0a2FbhvCxwMZtoFs0EQuOc3YTPIcjAieF1b9CdhA +dSBk5Yb4UdiuwNlSZgAORA+fhLE3SC+C7jYT/yuFbBAisLYD8PkPpxq1XtnrbJhXfB1ep6ZRWsp JlHfyWKdqftHYoAOOHLCMilywtmC8T3UYzYPUH81K9T+2sMDtY/lXJnZ3uqjQ9UX053aX5o/0VP8 wZi8GH8wfwfxp+v3gl8E+kWgH5lASUugU2rYS7Kn/qjnxnnwHapLju/8EHXDGP7uVT5BLwpRwPIo 7MZ+TbQ1jSAuSps3TJbEdoaOYpkt3OiALs61aULXiDzJOls1w/6ZVJ8cwt8KPXT6fhTB0QYHUdwL YKC2V67vrBg+kkhPQkUGeoZOZlTtTstm7C+4b8FD+Q3AgqOxOZvarNt4+tZdzInkRT4uOMeBLXrZ iIOZFM4wS1u4AngKuBhxphd7XlvxrYXr0UaP256E3caQur9lIML7ESySvFBmq7g8GJX9FpVjKe09 tI1LZNJzcTmFmGMg/55TBSc02ETMHwTNyAsTvMIfw2bk+1HyM2PTivy/0Ak3WAPPCZjFyPt5eX0P pJjj54IU/tcG1btwihw47Art+t6TOP3p79AfFaVTniOqPqdBepLEwVkn9U7CThR7aSfpn3idJA1O T1M/Godx8qV9pNAWeQLQ8aCgsAjfUVB8+/rPH9++/rspJuDc7ysnsGnfOwA+kP2mR+aqsI6k/W4w StKONboTnfZ7nZNxN+6M4zCKRmlyMgrPvth3Ez8aZIrhQ8zbvH3C8aMHjzhlkSmp5dQcZbJsXoPc St4yVckCH4R8r3nCwRT5QRD1oijw+g1PwLa2RWst8SbWf2i5ekeriwWSpsSyd4RTVSFuGo5uRKzv 7QvY8X8AAAD//wMAUEsDBBQABgAIAAAAIQCjWmwUzQMAAMYMAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDQueG1s5Ffbbts4EH1fYP+B4D4rutuyUaew7DgokDZBnX4AI1GxUIrkkrRr tyjQ39r9nH5Jh5QUO4kbNLt9WHQBw7wNh2cOzxCjFy+3DUMbqnQt+ASHJwFGlBeirPntBL+7XngZ RtoQXhImOJ3gHdX45envv72QY83KC7ITa4PAB9djMsErY+TY93Wxog3RJ0JSDmuVUA0xMFS3fqnI B/DdMD8KgoHfkJrjbr/6kf2iquqCzkWxbig3rRNFGTGAX69qqXtv8ke8SUU1uHG770MyOwnRmtow esnZDiNnqjYwGeJTiL5YshJx0sDEtbVCzsyuaHmtKLU9vjlXcimvlNvwZnOlUF1aB91G7HcLnZkb 8o3r+A+23/ZdMt5WqrEtcIG2EwxXtrP/vp2jW4OKdrLYzxaryyO2xersiLXfH+AfHGqjasE9Difq w2l5CO+i6vFqeSGK9xpxAfHY8Nvw7izamG0rV4fEd3btouvswXRkmW0uyp095AZaN0nGTJul2THq BtL+ORgK8DJidU25924Jum7MjFHC7wgxpzNWF++REYiWtUGviTZUIQcGsgBcWnaM48i5pLy8Ioq8 PfR8nncsSge6R+j3FH6fyEFP5JwYiq4YKehKsBIQxD+D09JAyB8hLQirMBy4tVf3JMVHxJbFGWSJ U9EgTuH3QHfRMImdgdVTPEjDKL0nKqBFaXNORYNsZ4IVLQy282RzoU3HXGfSsdYCenjV9tWC/Suh PmLEXnE9waMwSeBo4wZJOoxgoA5Xbu6tGDYTzImf8AL8THBhVBtOLyHX37AQMCDCbkEqzIEtaWUv 3dIZ2nDdlQhWl4uaMTewjw6dMYBJ4Ayzta8GaKfmpp0ZpkHQ59udcTva+/H7k1y3A9L2DwA6iX9H iqislTlI7WeLctiLciGETYZDWSY/Q5YVcO6I/HNNFJzQSdNJ/lnSTII4GzylzSQMk+xX1qY1+X+p M+vVuQRUFL1ZNzcPNOqu+N9qFEodcH1Mpi4FnveCDsLgSZn+8k/of1WkFVR0VlSf8iifZml05uXB NPaSNMi9bDQNvCyP5vM8TBZxmn3ua0RtlcdBHY9qDCvwIzXG1y9//fH1y9/7UgLO/WfFhGv6YhPk A7ff9dBa1TaQfDSIZlnuWdBeMh8NvelikHqLNE6SWZ5NZ/HZZ1u0hsm4UNTVwa/KvoIOk0c1dFMX SmhRmZNCNF0x7kvxgSopalePh0FXQbsrSqM4GEVhkHVpAtD61oG1ebe04UPL1GsiLzcuZxpXec3c lITvhS5F9yY29P774/QbAAAA//8DAFBLAwQUAAYACAAAACEAQL4bKocDAAB0CwAAIQAAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbORWXW7bOBB+L9A7EOyzon9ZNuoUlh0HBbJtUKcH YCQqFkqRLEm7dosCvdb2ODlJh5SUOGlgtNh9WHSBIBwOhzPfDL+R5+WrXcvQlirdCD7F4UmAEeWl qBp+M8Xvr5ZejpE2hFeECU6neE81fnX6/NlLOdGsuiB7sTEIfHA9IVO8NkZOfF+Xa9oSfSIk5XBW C9USA1t141eKfALfLfOjIMj8ljQc9/fVr9wXdd2UdCHKTUu56ZwoyogB/HrdSD14k7/iTSqqwY27 /RCS2UvI9poR/gEjZ6a2oAjxKWRerliFOGlBUTgLq9TySlFqJb49V3IlL5WzfbO9VKip7N3+Dvb7 g97MbfnWCf6j6zeDSCa7WrV2hRKg3RTDS+3tf9/q6M6gslOW99py/fYJ23J99oS1PwTwD4LarDpw P6eTDuksiKHokpGSrgWrqELxXYIDdC0vRPlBIy4gNVuJLtM7iy59u8p1X/rKAPE+wyMSVmMICHCj /lpn64R7mE/WKI9zeFOXfBan8PeoXNEoiZ2BLUOcpWGUPqgFmUilzTkVLbLCFCtaGmz1ZHuhTWc6 mDhIHRA5MbtCVHtreQ0rlAx6DO6vhfqMEXvN9RSPwySB0MZtknQUwUYdnlw/ODFsLph7M8JL8DPF pVFdOkybldkz6uQtCwEDIuwGGpo5sBWt34HKljO06bonEayplg1jbmNbhM4ZwCQQw+wsz8nENNx0 mlEaBANN7oy73b0ff4jkxB5IJx8AlO4BeHVJFLGooIHgU0O5d15gVDXKHDBSupoOtXTlPU7KbCDl UggDVDykZfJv0LKGmrtCftwQBRF6ajrK/xY1kyDOs2PcTMIwyf9kblqT/xc7RwM7V4CKojeb9voR R90T/1OOwg8zuH6Kpq4Ffu8LmoXBUZr+8Z/Q/ypJa5hBLKm+FFExy9PozCuCWewlaVB4+XgWeHkR LRZFmCzjNP86TDTaMo8DO6wL9ZjgujVzRgm/mxXM6e23v1/cfvtuIRgHBOIe6ZEjneGWYUYC+sDr 9xLaqMYmUoyzaJ4XngXtJYvxyJsts9RbpnGSzIt8No/PvtpZK0wmpaJuantdDfNemPw08bVNqYQW tTkpRduPjr4Un6iSonHTYxj08173RHk8irJoNO7bBKANqwNr+25l04eVqb+IfLt1PQOxoMfmTiVh uu1b9N7Epj5My6c/AAAA//8DAFBLAwQUAAYACAAAACEAtM9YGbkAAAAkAQAALAAAAHBwdC9ub3Rl c01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzjM/BCsIwDAbgu+A7lNxttx1EZO0u Iuwq8wFKl3XFrS1tFff2FnZx4MFLIAn/F1I373kiLwzROMuhpAUQtMr1xmoO9+56OAGJSdpeTs4i hwUjNGK/q284yZRDcTQ+kqzYyGFMyZ8Zi2rEWUbqPNq8GVyYZcpt0MxL9ZAaWVUURxa+DRAbk7Q9 h9D2JZBu8fiP7YbBKLw49ZzRph8nWMpZzKAMGhMHStfJWiuaPWCiZpvfxAcAAP//AwBQSwMEFAAG AAgAAAAhAELygi+8BQAAzh0AACEAAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWzs WNuO2zYQfS/QfxDUx0LR/WIj3mBtr5MFNski3nwALdG2YIpUKdrZTRAgv9V+Tr6kQ4r0bbepd+sW DeIXazQcDsnDM6PxPH9xWxFrhXlTMtqz/WeebWGas6Kks579/mbkZLbVCEQLRBjFPfsON/aLs59/ el53KRO4eY0agbkFXmjTRT17LkTddd0mn+MKNc9YjSmMTRmvkIBXPnMLjj6A94q4geclboVKauv5 /JD5bDotczxk+bLCVLROOCZIwAmaeVk3xlt9iLea4wbcqNk7WzqDE+ZjUsjnZNb+vsNTqyxuASfP 88ECdZVnPCDcWiHSsycz33bPnrvaWEtyclPfcIylRFcveT2ur7la4c3qmoNPcGlbFFWAsHSgBrSZ eqUrJbh702dGRN3bKa/kE+CxYIdwj3fy15U6fCusvFXmG20+f/uAbT6/eMDaNQu4W4vKU7Wbu3+c wBznFUYFEOSaoBzPGZGywkgZm8039RXLF41FGRxOYtGedW3RAiCf9dwSdzX4nRccmPmxZ/+2RBwo qKe0dkrYbPJwhIJO6meePnkUZ2mW7RwfdWveiJeYVZYUejbHuVBMQKurRrSmxkTto1297orbPivu pOUEnoASBB3MnzP+0bbIJW16dsePIlhaqJcoTgN44dsjk50RQQaMrE9AGjEWdwQreUV8WNZCZAZB TdT+Cjx9ByqJmA8s16fSlq285aFWoNDiGnEkpxEk8wGmzsu+nlmr05lTqYN+mxGhYcQQCbzDh+AY fCiErWPz0UwIsyxK/PBH4QN/Kh+mpFA3+SkYDPvhIPWc0chLnShKYyfrpJkTjRIv8gYXw/PM+2yb i4HrFmWFR+VsyfHbZQsP3yOV1VRiQDCi6wOIM99zfR9Ssp/I7Qi1qanMyMemZmSoOSZlga3LCs12 GRr+PUNBeseElgZz2BQ+b2pgw2H0bUhxWc00hVVAPIrCSRYrmgJLfT8KvfZCNzyOoyyJDI9DL0v8 9ZU/icgIvv6jkpCWatT6IFmUgk+FDQMY5ahxu/k+AqYLve6WlSQb/a+iw0I0Bz89Oxfqo7Ehunr5 FzJfbOj1RlZMO8SKjpH6JES738KWRoq1T6URQOjF8TdplHhe1Fp8R/lwc8kyI0K+W1soQHby0vvx g3lpQMp8YQlm4aIUlq6AhcSokSs0m2zVJtJ2tZ0l1bU+YskxzhktLIJXmBzgXiWQR7i/mZf8cO+K V4/wPmJLLuYHu1cx8Rj35fRB78cO48SE8YgxeePbcRwfI46nYq+kbcNY4fGE0jaDaA58fVl/XdCk //8AXqfsyXdS66a7BcWbZTXZI0xyDMJA0QCuH+KM4uOTi+AfkTn/vCoO4/QiS4exM/A6AVTF57HT 94Z9J476YZZ6nf5FMFhXxY0kBoXLO7QY/vrl91++fvnjCJWwephuBNwuXI6WrCUv4SD9ficJBlnf 6fvRyImGndQ5HyWxM4rDKBr0s/NBePFZNkj8qJtzrHonl4XpuvjRvb5LVeacNWwqnuWs0g0ct2Yf MK9ZqXo4UOq3jSBVJgZpmGRe0okNjWFv5ql2K+NC92Zywl+j2prMfIh+AdW3uAWpWIA0mQVSF0hd IHUgoTzHVICFFowmMJq1TWg0odFERhMZTWw0sdEkRgNfizkp6QLAkA/bmjLyqlUYqU0Bqo12j5QV 4lctgXVes4CaN2gy/qgp39JcmWB0Rft8of57yD4Y1a8wJP+HlHR2vaTtH5GHOG4tMJe9PynfK9/3 GlwA7v3yHXYtV1XMnkKK69m/VtQhQucPtDeAke40NXsDeaN9tzvcDT0lBhtoVKif8NGgaHzCDT4G hBM+EhSNT7TBxw9TPzkBZFDRAMVbAGVBpr73J4AkKhqgZANQEGSJbLScAFKoaIDSLYDSKDzl6DUq GqBsA5BE55Sk16hogDpbACVxekrSa1Taf3Jb9aJ5bXtQZ38CAAD//wMAUEsDBBQABgAIAAAAIQDg 2BvwGQYAAJcaAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWU+LGzcUvxf6HcTcHY/tGf9Z4g32 2E7a7CYhu0nJUZ6RZ5TVjIwk764JgZIcC4XStPRS6K2H0jaQQC/pp9k2pU0hX6EajceWbJklzRYC jQ0e6c3vPf303tOTxnP5ymlKwDFiHNOs69QuuQ5AWUgjnMVd587hqNJ2ABcwiyChGeo6c8SdK7sf fnAZ7ogEpQhI/YzvwK6TCDHdqVZ5KMWQX6JTlMl7E8pSKGSXxdWIwRNpNyXVuus2qynEmQMymEqz NycTHCJwmJt0dkvjQyJ/MsFzQUjYQW4aGRoKGx3V8guf84AwcAxJ15HjRPTkEJ0KBxDIhbzRdVz1 caq7l6tLJSK26Gp6I/VZ6C0UoqO60mPxeKnoeb7X7C3tKwARm7hha9gcNpf2FACGoZxpwUXH+v1O f+AvsBqoaFpsD1qDRs3Aa/YbG/ien38NvAIVTW8DPxoFKx9qoKLpW3zSqgeegVegotncwLfc3sBr GXgFSgjOjjbQrt9sBOVsl5AJJdes8I7vjVr1BXyFqmrZVehnYluupfA+ZSMJUMGFAmdAzKdoAkOJ CyDBY4bBHo4TmXhTmFEuxW7dHbkN+Zt/PdVSHoE7CGrahSjkG6KcD+Ahw1PRdT6WVh0N8vrFj69f PAOvXzw9e/T87NEvZ48fnz362aJ4DWaxrvjq+y/+/vZT8Nez7149+cqO5zr+958+++3XL+1AoQNf fv30j+dPX37z+Z8/PLHAewyOdfghThEHN9AJuE1TOTfLAGjM3kzjMIFY1+hlMYcZzHUs6KFIDPSN OSTQgusj04N3mawUNuDV2X2D8EHCZgJbgNeT1ADuU0r6lFnndD0fS/fCLIvtg7OZjrsN4bFt7GAt vsPZVKY8tpkMEmTQvEVkyGGMMiRAfo8eIWRRu4ex4dd9HDLK6USAexj0Iba65BCPjWxaKV3DqYzL 3EZQxtvwzf5d0KfEZn6Ajk2kXBWQ2EwiYrjxKpwJmFoZw5ToyD0oEhvJgzkLDYdzISMdI0LBMEKc 23RusrlB97qsMPaw75N5aiKZwEc25B6kVEcO6FGQwHRq5YyzRMd+xI9kikJwiworCWqukLwv4wCz reG+i5ER7vPX9h1ZXO0Jkt+ZMduSQNRcj3MygUgZr66V9BRn59b3tcruv6/s9sreY9i6tNbr+Tbc ehUPKIvwu1/EB3CW3UJy3byv4e9r+P+xhm9bzxdfuVfFWh3oy2O7MpNuPcNPMCEHYk7QHldlnsvp RSMpVB2ltHxkmCayuRjOwMUMqjZgVHyCRXKQwKkcpqZGiPnCdMzBlHK5USix1bbaaGbpPo0Kaa1W PqVKBShWcrnRlHK5LYlC2mytHseW5lUvVo/NJYFc901IaIOZJBoWEq1SeA4JNbMLYdGxsGjn5rey UJdFVOT6AzD/g8P3CkYy3yBBUR6nQr+M7oVHepszzWnXLdPr5FwvJtIGCS3dTBJaGiYwQuviC451 ZxVSg17uik0arfZ/Eeu8iKzVBpKZPXAi11zDl2ZCOO06E3lElM10Ku3xvG5CEmddJxQLR/+byjJl XAwgTwqYulXMP8UCMUBwKnNdDwPJVtxq9VY+x3eUXMd99zynLnqQ0WSCQrFFsurKe4UR6923BOcd OpOkD5LoBIzJjN2G0lF+q5Y7MMJcLL0ZYaYl98qLa+VqsRSNf89WSxSSaQIXO4pezAu4ai/paPNQ TNdnZfYXkxnHeZDeetc9X2mtaG7ZQPJd014//rtNXmO1qvsGq6J0r9e6Tlnrtu0Sb78haNRWgxnU csYWatv2jgs8EGjDLVNz2x5x0bvBetbmG0R5rlS9jdcUdHxfZv5AHldnRPDir4BT+YwQlH8wF5VA ScvqcirAjOGu88D1e15Q94OK2/aHFa/huZW232tUer7fqA39mjvo1x9Kp4gkrfnF2CP5PEPmi7cw Sr7xJiYtj9mXQppWqToHV5WyehNTq29/EwOw9MyDZn3UaXT6zUqn0RtVvEG/XekEzX5l0Axag9Eg 8Nud0UMHHCuw12sEXnPYrjRrQVDxmm5Ov92ptLx6vee1eu2h13u48LWceXkt3at47f4DAAD//wMA UEsDBAoAAAAAAAAAIQA4SOabhB8AAIQfAAAXAAAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWf/2P/g ABBKRklGAAEBAQBgAGAAAP/bAEMAAwICAwICAwMDAwQDAwQFCAUFBAQFCgcHBggMCgwMCwoLCw0O EhANDhEOCwsQFhARExQVFRUMDxcYFhQYEhQVFP/bAEMBAwQEBQQFCQUFCRQNCw0UFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFP/AABEIAJABAAMBIgACEQED EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0B AgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEB AQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP1TooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKK891r4yafonxf0TwFJY3EkupW+9tSVh5NvM6zyW8DDrukSzu2B7eUAfvr QB6FRXJ/FDx0/wAOvCDazDp39rXLX1hp0Fn54hDy3d5Dax7n2ttUPOpJweAeKzPCPxYTVL7xRpni XTk8Kar4bigutQ8+9SW0FtMrtHOs+F+T91KDvVSpjPGCCQDv6K8m+JX7RnhDwj8K7rxjo/ijw3q9 s17BpVndf2tCbNruWVIwrSqxHyBzI6j5giMeMZrodN+K3hqytfD1nr3jXwqNb1iGOWzS21GKJNQV zhJLZHkLOrcY2ls9iaAO4orDuvHXhux8QW2hXPiDSrfXLp2ig02W9iW5lcIJCqRFtzEIysQB0IPQ 1BoXxI8JeKL7UbLRvFOi6veaaCb23sdQhnktcEg+aqsSnII+bHINAHR0Vzug/Ebwp4q1a60vRPE+ jaxqdrGs1xZWGoRTzQocYd0RiyqcjBIxyKXRviL4U8RapqWm6T4n0bVNR0zd9us7PUIpprXBKnzU ViUwQQdwHIoA6GisDwn8QPC/j6G5l8MeJNI8RxWriOd9JvorpYmIyFcxsdpI7GuV8K/G6x8S/Gbx l8Om024sb7w+sTQ3srqYtQBt7aafywOQYhe2obPXzlIoA9JorzrR/jPZa58bNX+Hdrp1wz6Zpxu5 tV3r5JmUwF7cL1LKl1bsW6fPjqDXReG/iR4S8Z6je6f4f8U6Lrt/Zf8AH1a6bqENxLB8xX94qMSv II5xyMUAdHRXm1x8cfDt74+8N+GPD+s6N4gub+/uLLUEsNQjmlsDHbTzDeiElSWhK4bHf0rqNK+I nhXXfEV74f03xNo+oa9Y7jdaXa38Ut1b7SA3mRKxZcEgHIHJoA6GivNdI+NFivwFh+Jmvi20mzGl HUp43uAkanBxGHfAyzYUZ6lgKpeB/jtoE3w20bxT4x8a+C9Oh1b5re5tNVjjtM7AzQiSSTDyRncr EY+7navQAHq9Fc/r3xC8LeFbO2vNa8S6Po9pcx+bBcX9/FBHKmUG5WdgGGZIxkcZdfUV0FABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABXy1rnwv+KHijwp4z8VWd5pFhrF/rn/CSabod9oszX6tYSIth b/aRdqsYlitYtw8khftMwIbJJ+pa5nwV8SPD3xCm1+LQb/7a+h6lLpN+PLZPLuY8b1G4DcBnG5cq SGAPBoA5L46aDefEb4S2NlaWGoeZe614fuZbaF3t7qGBNVs5pm3IweNo41diysGXYSCCK8n8dfBv X/D+n+NPDmg22tX2i3Gs6L4pi1KORL7UZ447lPtdoZrsSG4khFuk0az78rIIxwoA+q6o6Lrlh4j0 2LUNMu4r6ylLKk8LZVirFWAPsykfhQB8533gWXxB4a8T6xo93428S6tquq+Glnk8T6PFprNHZ6nH KzxwLa2zErG775HQ5WNACQlZ/jr4c3l542+LOleItU8e2mkeNLiE2ieFdFtL63u7U2FvbmJp3s5m tpEkjmI8ySNBvV1O5nNfVVFAHii/DfVrjWvjrPp8B0zWfEVtBZaZrMg2tJt0xI42DjnCTM/0Oa4v 4aeB/tltoomufiB/bfh7w5dadFpGtaHZ2VjZeZCkb2yzw2cSzjcibfKlkQ+WGPQGvp+igD538P8A wx1fSvDvwNstL0o6Jc6R4butPu5YYRGLCSXT4xh9vTM6KSO7KD1rFfQ7/wAYfszv8PNJ8F61oni3 TPCS6XP9o05beJHQQrPZQ3Mw8qbz/LbDJviYKDIRwD9KR6xFJrlxpYhuhPDbx3LTNayC3ZXZ1CrM V2M4MZLICWUMhIAdSb1AHi3wf0K1vvHNx4lOr+O9T1CHSRpj/wDCVaHBpcMcZlEgjUR2duZWQq2G G9FDvtPzc8n4u8F+KdC8RfELx9ofh661PXtG8ZW2s6XYQlUfV7BtF06zvII2JwchZioPHm20fpmv XND+NXg/xJo/jHU9P1Uz2vhG7vLHWcwSK9tLbbvOAUqC6jY2GUEMVIBJBrsdPvodTsba8t2329xG ssbEEZVgCDg9ODQB80ap8EvF1vpt7pmnuf8AhJNU+Huv2tzrkZKRf25fTQylg3VR5pcoP4UQDoor TvtPvfiZqvgmHwl4Y1fwRN4c0rUILi41LTpLFLES2TW8VjGzACYCYwy7od8YFqDuyVB9+XXLBtbf RxdxHVEt1u2td3ziFmKB8ehZWH4VeoA+YvBul3Gsa18DrSx8A6v4fufCFlcWGo317pnkR6Yx02SH 7PHI2PORpFQ74d8R2rlskCqnwB+HV1pkPwx0bxJqXj7/AISLwbGTLp93o1pFpMNyLSW3mcXsdknn xSebIy7Z3diyNINwbH1RRQB4t4T8J6xZ/skjw5Pp08Wuf8IvcWn2Bl/e+c0LqEx6kkD8ay7BLz4b /EPTfEGu+HtY1LS7nwVp2jWsul6bLfyWN3DLO9zC8cSs6CZZbb58bM2uGYYXPr/g/wAY2XjWz1C5 sYp4o7HUrvS5BcKoJlt5micjBPylkJB64xkDpWhoesRa/pNrqMEN1bw3Cb1ivrWS2mUejxSKrofZ gDQB4F8IvhTqvh/xZ8KrrV9B+zR6N4d8R+WjhJBpD3eoWMttaBlJVXS28yH5SRiJwCR1+i6KKACi iigAooooAKKKKACiiigAooooAKKzte16y8M6Y+oahKYbVHjjZwpb5nkWNRgc8syj8a0aAOP+L3jW b4e/DfXdcs4VutUihEGm2rdLi+mdYbWH/gc8kSf8CrxH4caP4k+D/wAQvCemavolrpGmeINAXw01 5b6obtrvVLRJbmCWTMUe15Y2vizclmWMdhXv11460ax8SS6HcXLQ3kUMM8skkbLBH50hihRpSNge R1ZVTO4kDjlc695qENi1uJfMzcSiFPLid/mIJGdoO0cH5jge/IoA+XPhv8R9K8YaT+zl4ZTxB/am rnS2h16xjuWeaJ00eaOWO7wcpIJVcbZMNujcgZRscx4Ij8I+G/hd4G0s6hBpnh1vF11ZeNhHqLJ9 mVf7RFtDeHfmGNrlLdCG2hjtVsq7A/ZFzc2Ojxme4lt7KOaaOMySMsYeWRljRcnqzMyKB1JIA5Ir N03xBpOra9rmj2sUkl1YOkd+32VhD5jxJIIzIV2s3lyRsQCeHHvgA+YdQSzv7PX9J8Kavdn4dzeN /D9nYT6TqMoiVpJIVvoLWdGysOSoIjbartMBtIIF7xkg8AN8RfD+mXN3ovgi21zw7NqK2tzIg0+w uHRb5kcNuhiZUBkKEBVeZ8qctX1VHGkMaxxoscajaqqMAAdABUNxqENtdWts/mebclhHtidl+Vdx 3MBheB/ERnoOaAPkjxpcaTZ6b8T7T4bawyeC10fSfNl0K/Z7W01J751f7PIrFUlaDyzIqHj90xGX y274i+E+gQ+PPipokQ1KHRtN8F6drFlYpqdwI4NQmk1WOS8X58+eVsrf95ncCrMDudifp+3t4rWF YoIkhiX7qRqFUfQCpKAPkzxR4w8Q3Wh+KNRXUtQjeX4feEry/ns5HWSCCa+vhqFxHs5SQW4kbeuG GxSPuivcvhIvw8ji1WP4ealYX1kGiN1HpOom7tYpChKkYdkR2XDNtwWyrNnIJ9BrD/4STS9P8SW3 huFJBfywNdeVbWzmKGMlsNI6jam5lcDcRuKnGcUAfIfirT7nwT8FPHnxD02CSa3fUPGmh+I7eFSz S2L6zqfkXOByWtppCT6RT3B5IWtTxtKdQ8cxad4o1jw3o+hw+EdMl0b/AISjVJ7CJXInF1PbOjov noRCGfO+NfKI2hyW+xKjmt4rjZ5sSS7GDpvUHaw6EZ6H3oA+ZfD/AIR8PW3x38Nv4v1ez1XxFqPg Wwhj1hrtrcaveJI0c0sC7wGLK6NtXOBIp75rz2H4s+JfA7WPi7U7zU9Q0v4VRnwXr1sGYnUrqTz4 vOZf45HeHRZFbst5J0zX248MckkbvGrPGcozKCVJGCR6cVJQB8qWmi+H/DHim08M/GfxBbiy0/wf p89lNrWptbWl1qDTXR1S4jZnUNMrfZsclokddm0O2Zfhr4fu/H3iT4W2njSbVNQhh8HX16LPUJ5U NyVvbVbWe6TILzCFlb5+Q7FiNwBH1FNbxXGwSxJKEYOu9QdrDoRnv71JQB8p/CPULqw+L16nii4n g8NXHifXI/DJt5GjtG1P7dc+dHdgfemMXMAY7CBLx5gUlvw40OH4j3nwS07xHPe6nps3gbV725s5 buUQ3cy3WlojTqGHm7RI+A+QCc9QK+ndW16y0OTTo7yUxtqF0tnb4UtulKswHHThG5PHFLrOvWWg R2j3spiW6uorOLClsyyNtQcdMnv0oA+MdW8aR2Gk/DDT/EllfeLdCjt/FFr/AGbdX8kayPa6lDbW k0kpJMjxRB1y5yBIzgllAP05+z3pMGg/BHwVp8GsWniAW+lwpLqljdG5huptv72RZScuDJv5PPqA eKyvi5YeHtO8S6X4hvPGuseCNbjsLi2+1aPFBOXsg8bytNHNbzokUbeWWmKqE3AM4BxW34HufCng P7H4G03UJ3vBJNMHvFdjeXErPdTt520RvMxkeZkQ5AYnaFHAB3lFV4tQtZ7ye0juYZLq3CtNArgv GGztLL1AO04z1waP7QtTfGyFzCb1YxMbfePMEZJAfb125BGemRQBYooooAKKKKACiiigAooooA8M +Lvw51rxV4qvJY/Dsmu+c+lPpmpC9jhTS1guvMuVIZw4LqM/u1bzeEfAQVR8QfCfWY/C9xBB4ci1 W81bxDqd3qbs0NxcG3a5u3sivnyrHtVZY+DuMYY7E3fMv0DRQB813HwCvdU0C8vtc8K6brfiObS/ DP2qS4S3luL6ezmWS8jMjnDMyxquXYKx25OBken674R1+7bQJNPvJYbSHUoLgac0UES6dAsMqlB5 fDgFkG3LD5eOOa9FooA+W9F+A+tP4Cls9e0K91vVIJtFuL2y1H+z5LbU5rW9jmuZ4iHzJLJGsq+Z ceWzh1V8fw+p+DfhfLoOu+NdR0u2t/CD6zrcF8slnaWzSXFuthaxtHJgED98k/fOckfeyfUaKAPm e6+FvjrWtc8SyS6VJpcOp288N01ndQ28dzJ/aNu8MiSRymZiLdZv3khVhuKqqDC1teKvhL4ljs/F GneHLQWelyT6kdKtYLpYo4o5tFjhQIu4BAbzzjjjBYt3zXv1FAHh9x8EZNJ8RXl/oentB5d/odxY yfbWJiEd0n9ouoZzteSBSJG+9N0Ysaq/D3wF45h8ca3qN2j+E0vrRluLi0S1kimuVuCyui75HlBj JHmzYc5I2oMKPUfGnxN8N/DySzXxBqK6ct0skiSPGxQIjRozMQDgbpol+rjsCRX0H4qaJ4kvobez F0Um3+VcNEPLcqiuRwSRwT1A5Rh1HIB5n4u+Dut3sOsX0FtJeXd34kF1eRo8Es+oaYLYIsCrOwiC CbZKYWKodj8ZbnH1D4C6w2m6hd6bYzpqz6TpttFe3xtDqJij1Kae6sw6koAbVxAq7vLKlULYBI9Z 0j40+G9fW0fTXu72K6uvsUckNuxHm+W0mGHVRtRzlgPu/StLTPiZoWreE9G8SW080mk6vNBBaTLA z7mmkEce7aDsBYgZbABIBweKAPMvDfwd1Br7QJJbe+trOws9WktYNWa226deSy2TWpSC3dotqeTO 6AbghPG3IAwvCHwS15fDcVhqdpq8ckl3o/8AalvdXVqlvdiCVmuZlaCTfKXBw7yhXlUIGU4IHsej /Fzwtrmj22q22pY0+4upLNLiaJ408xIXmYEsBgBI2JJ6EFThgVF/SfiB4f1zVrzTbTU7eS9trlbU xeYMvIYfOATn5hsD/wDft/SgDyvT/hvq+kX2mRan4Zm8R6Jaz6pHYWMF5Co0zfqLy2swEkigKLco qlMvCE2quGIB8N/hd4o0fxZq95qN9rFhqkq3qvrCLYyWt4JLpZImI3GZ2SNQqCVAIgZEU7cZ7W6+ O3hGxjunnur2P7LHNJOn9nXBePyxOWUqEzuxa3BAHaJvbPTaH4y0nxJqmr6fp10tzc6VKsN2FHCO Qfl98YIPbII6g4APKtb+Ct5rmvanqOoQSajdyeINOkjvGuzEZNPS0torpdisFVJGWcPGABIMBgwC 4xtU+FfiKPTbixufDs3iGzEGqWmi20OoRxDR5Hv7h7WfLSKUAt3tlV4t0kIhKqvzEV9E0UAfPGpf CvxXeeL7C4l0x7zXLbWBejxk11Esa2v2BoVjEW/f8spz5Ozy85kB3kiofAHwg8SaTpditza6pb38 d9pEt6l7NZm3me3kdp7qMxOWkdt3zSShZJAI8jK4H0bRQB5B4k8K+LNH1y8v7e2l8cPqWhS6Tvka 2tTbS+YWjMgJQeS3mMHZAzjy1wjZ4Xw/oGv2/jLw1pmqaBqM2geE7WODTNTjmtTDc3P2Qwvdygz+ auEeWJEEZ/1js2crs9eooA8F1/4b6trHiDxVrFl4PTSPEHiTSdLMGtxyWol0u7jk+fzXV98jQnyp dqho5RBszyBV34c/DG88O+OfD2tav4YhudVXRZNOu9cDQTSpdJPKz3DOzCTbceYzKEBK7yrBK9to oAKKKKACiiigAooooAKKKKACs+38Q6VeSWiQanZzveRia2WOdGMyEEhkwfmXAJyOODWhXiml/su6 To0Filrr2pKbO2ntIWYIcQyRbTEQAMxiRpZdp7ysM4AwAey295BeCQwTRziN2ify3DbXBwVOOhHc VXvtc03S1uGvNQtbRbZElnM8yoIkdiqM2T8oZlYAnqVIHSvM5/2e7FpoprfV57B/t9rqEy2kCRq7 wPIyhQOU+/gYPCqByCajt/glpXg3wRqls+u3FtbrBZyzX9xLKRGLK4e5ErMZd4LEkuUdedzLsJoA 9WOoWoa1BuYQbriAeYP33ylvk/vfKCeOwJqSO4imeVI5Ed4m2SKrAlGwGwfQ4ZTj0I9a8E8O/B3w Zaiztx4lulu4ri3S1/tTzILvzoYDHHiOYgblE67THGpA2KScDEHiv4c+D9M8F38lt47t7Ge1sZoL a7NzGTHM1nCjMAuWLuId7BQWbzX4O7kA+hqit7qG8jZ4Jo50V2jLRsGAZWKspx3DAgjsQRXi3wy+ D+jWerWl9JrUOoanp7pLcWFvLJsjKxtEitEWChQVEqnyl/eeYy7VfYuWPCPhHWNY1O9ufF8cFzBd 3cbrdebFbx7dTkuTGyuyRujG4EcikESBBtYbTQB65qmi+GPiZY2/2o2uvWCr5iRx3JkgkVxgMyq2 1xxlSwOCMjBGav6Pp+keH7GXSbJ0ihtw9xNFJcNJIvmu7tI7OxY728w7mPJ3eleN2PwQ8KWtvb6T Z+LRNcqsOiPIojln8yGK7KxsVPyOqTyyKD914Ymx8u1ut8KeCLR5LqXR9agm0nUNJhtZlWMNPKA9 4fMbptJe4PUZzCQe+ADd8L+FPB1hpumHRDDJp32hprDyr95ofN8uVWMWXK52tNkL/tE8jItXHgXQ 4dDFjcG4TSbWa3vIomvpY47b7OsYiCkOMIphR9pO0tljkk14teeEvAHg3wpbXF949SGN0TE8gMwK PHezlWQlpBHIk8sjZbOIgQy7VK9L4b8F+DNF8I6jZjxss0Oq2EdjLd3l1EspaNSwdw/Vwsi5Vx0w CMGgDs9L+F3gm68N29np9lHcaMxeWLyL2V0Ytb/ZiwcOc4h/dqc/KB8uMVPpHwn8N6D4gsNYsLOS C6s47hIw0zSBmmECvIxcli+23RQ2ejP13GuA8TfDPS/FGtateTeN7OTXL5ZLOK1jeOKEXa2skKrs DElo2m8wA5kUkfMcLihpPw/8B3WpXTy+Lobz7PObO6t55DFDE8Wo+dJbCMuI1jMg8vy2ViRgg4PI B6JF8GPBclg1ounyzQC3eybdqNy7bGEqsCxkLbv9InG4nd+9k5+Y50tG0nwr4U8STW1lNb22u6jE rNbTXrSTyohY7lR3JxuZ2YqPmYszZOTXkejfC3wJNpsF1H42hntfLvIjNPc+TIzvHtuJHAkUGUmT LmRW+XyuAVDHuPHHhPS9WsdAbWvEFpY3FvYyQLI0KLZXAL28rloydvl/6OuFLY+brwKAPR7q7gsY TNcTR28QKqZJWCrkkADJ9SQB7mpq8F8PfDfwLFdXcq+NDqEkV4YDJf3xeb7Q8ySoWMjlTJiJ40dF XdGcfNtzVW3+GfhHQWXSj4x+xy2qDTGlvfNYSTxkXe4PNIyNIiRNIyr8m4lpEYbUAB7xDrFhcXl3 aRXtvLdWe37TAkql4Nw3LvUHK5HIz1FT2t1De20Vxbyxz28yCSOWJgyOpGQwI4II5yK8rvfDvhzU Nc1DVT4y0421zqy6obd51kjWSC0WCRcNKUG1CkmVVSrbWbdgVg+FPgz4N8PyWkTeL01dLXyNPVLy 9DsxSZJlgZfM2Nu8rkMhcku275myAe4i8gYQETxkT/6r5x+84LfL68AnjsKmrzDSvhkJvBXh7TNJ 8Q2v9naSPL066tLON1+zGzNsRjcUZ/nkffgrkgFCBg1tC+ANvo8lukmvXt3YQytOLKQZj3ma3k2j czHy1FrGiIScBnyWyMAHqskiQxs8jqiLyWY4Ap9eMQ/sx6PHoo099TubjFutvvuA04YBLhcsJHbO 9p1kcAhWeFWAXt7Mq7VA44GOBgUALRRRQAUUUUAFFFFABRRRQAUUUUAFUtb0e18RaPfaXfRmWyvY Ht5kVihKOpVgGBBBweoORV2igDzrWvgV4d8RXa3ep3GpXl4JJpzcNdbX86S2FsZl2gBHWMDaUC4I B/hXGBrX7MPhzUdWt7u0u7qwtxE1rc2u4yLNbFlYQgk8BcEKWDlAV27THGU9kooA4vRPhRpHh3xS +vafcX0F3KzGaNpt8ciMGzHgjITcwfaCMMuR95s5S/s++D/tt7dtaztNeS3U0mJQi5uG3SfKoAJz /EctgAFiFUD0migDzjwn8F7fwvHeKNYu5Wk1uXW7eSNFDwSyK6MCX378pIy88AY2qpGa0fCPwl0j wLMG0W5v7SAQpB9nM+9NimZlXkZxvuJpOuSzDnCqo7aigDzaD9n3wdb+biykLSweQ8hKiUg2Zs2J kC7zmEgEE7cqGABzmeX4E+FJG1V0tWt5tRNwZZ4FjSUedcJcOQ4TOfNjDKzEshPylcLj0KigDhbX 4M+GrTVF1ERXMl1GVETyTk+XGt1HdLGP9kSxK3OTywJIxinqHwD8IajqF7fNbXMNzetKbhobllEn mm483K9Mut1NGWxu2lACCiFfRqKAPOm+A3hR7eeKSC4mMgwHmkEmwebBMoCsCpCyW0TAMCDggggk VpXXwr0q+0/S7Oa4u/L0tt9h5RSMWzLKkkJRVULiLy0VVI27Rhg1dnRQB55D8BvB9tp6WUVlMluk DW6r9oYkIYZ4cZJznZcyjPXkelXNc+EHh/xFqepX96tw9xqACzlHChk+zz2+04HI8u5mGWyRkYIC gDt6KAPOZ/gP4auL++vS159pvbm4u5pGdJCzzKqsDvQ5QBEwjZXKISCUQq9vgP4Ra+srxrOSa5tG 3RyXTi4J/wBIluDnzQ3zGWZm3/fBAww7+h0UAVNJ02DRdLs9PtVKWtpCkESk5wiqFUfkBVuiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKAP/ZUEsDBBQABgAIAAAAIQDg2BvwGQYAAJcaAAAUAAAA cHB0L3RoZW1lL3RoZW1lMi54bWzsWU+LGzcUvxf6HcTcHY/tGf9Z4g322E7a7CYhu0nJUZ6RZ5TV jIwk764JgZIcC4XStPRS6K2H0jaQQC/pp9k2pU0hX6EajceWbJklzRYCjQ0e6c3vPf303tOTxnP5 ymlKwDFiHNOs69QuuQ5AWUgjnMVd587hqNJ2ABcwiyChGeo6c8SdK7sffnAZ7ogEpQhI/YzvwK6T CDHdqVZ5KMWQX6JTlMl7E8pSKGSXxdWIwRNpNyXVuus2qynEmQMymEqzNycTHCJwmJt0dkvjQyJ/ MsFzQUjYQW4aGRoKGx3V8guf84AwcAxJ15HjRPTkEJ0KBxDIhbzRdVz1caq7l6tLJSK26Gp6I/VZ 6C0UoqO60mPxeKnoeb7X7C3tKwARm7hha9gcNpf2FACGoZxpwUXH+v1Of+AvsBqoaFpsD1qDRs3A a/YbG/ien38NvAIVTW8DPxoFKx9qoKLpW3zSqgeegVegotncwLfc3sBrGXgFSgjOjjbQrt9sBOVs l5AJJdes8I7vjVr1BXyFqmrZVehnYluupfA+ZSMJUMGFAmdAzKdoAkOJCyDBY4bBHo4TmXhTmFEu xW7dHbkN+Zt/PdVSHoE7CGrahSjkG6KcD+Ahw1PRdT6WVh0N8vrFj69fPAOvXzw9e/T87NEvZ48f nz362aJ4DWaxrvjq+y/+/vZT8Nez7149+cqO5zr+958+++3XL+1AoQNffv30j+dPX37z+Z8/PLHA ewyOdfghThEHN9AJuE1TOTfLAGjM3kzjMIFY1+hlMYcZzHUs6KFIDPSNOSTQgusj04N3mawUNuDV 2X2D8EHCZgJbgNeT1ADuU0r6lFnndD0fS/fCLIvtg7OZjrsN4bFt7GAtvsPZVKY8tpkMEmTQvEVk yGGMMiRAfo8eIWRRu4ex4dd9HDLK6USAexj0Iba65BCPjWxaKV3DqYzL3EZQxtvwzf5d0KfEZn6A jk2kXBWQ2EwiYrjxKpwJmFoZw5ToyD0oEhvJgzkLDYdzISMdI0LBMEKc23RusrlB97qsMPaw75N5 aiKZwEc25B6kVEcO6FGQwHRq5YyzRMd+xI9kikJwiworCWqukLwv4wCzreG+i5ER7vPX9h1ZXO0J kt+ZMduSQNRcj3MygUgZr66V9BRn59b3tcruv6/s9sreY9i6tNbr+TbcehUPKIvwu1/EB3CW3UJy 3byv4e9r+P+xhm9bzxdfuVfFWh3oy2O7MpNuPcNPMCEHYk7QHldlnsvpRSMpVB2ltHxkmCayuRjO wMUMqjZgVHyCRXKQwKkcpqZGiPnCdMzBlHK5USix1bbaaGbpPo0Kaa1WPqVKBShWcrnRlHK5LYlC 2mytHseW5lUvVo/NJYFc901IaIOZJBoWEq1SeA4JNbMLYdGxsGjn5reyUJdFVOT6AzD/g8P3CkYy 3yBBUR6nQr+M7oVHepszzWnXLdPr5FwvJtIGCS3dTBJaGiYwQuviC451ZxVSg17uik0arfZ/Eeu8 iKzVBpKZPXAi11zDl2ZCOO06E3lElM10Ku3xvG5CEmddJxQLR/+byjJlXAwgTwqYulXMP8UCMUBw KnNdDwPJVtxq9VY+x3eUXMd99zynLnqQ0WSCQrFFsurKe4UR6923BOcdOpOkD5LoBIzJjN2G0lF+ q5Y7MMJcLL0ZYaYl98qLa+VqsRSNf89WSxSSaQIXO4pezAu4ai/paPNQTNdnZfYXkxnHeZDeetc9 X2mtaG7ZQPJd014//rtNXmO1qvsGq6J0r9e6Tlnrtu0Sb78haNRWgxnUcsYWatv2jgs8EGjDLVNz 2x5x0bvBetbmG0R5rlS9jdcUdHxfZv5AHldnRPDir4BT+YwQlH8wF5VAScvqcirAjOGu88D1e15Q 94OK2/aHFa/huZW232tUer7fqA39mjvo1x9Kp4gkrfnF2CP5PEPmi7cwSr7xJiYtj9mXQppWqToH V5WyehNTq29/EwOw9MyDZn3UaXT6zUqn0RtVvEG/XekEzX5l0Axag9Eg8Nud0UMHHCuw12sEXnPY rjRrQVDxmm5Ov92ptLx6vee1eu2h13u48LWceXkt3at47f4DAAD//wMAUEsDBBQABgAIAAAAIQCn U5d9fQEAAB4DAAARAAAAcHB0L3ZpZXdQcm9wcy54bWyMkk1vwjAMhu+T9h+i3EdLYYVVtGjTtBOH SbDdo8SUTG0SJQEKv37uBx8VHDi1tl+/fpxkNq/KguzAOqlVSoeDkBJQXAup8pT+rL5eppQ4z5Rg hVaQ0gM4Os+en2Ym2UnYf1uCBsolLKUb700SBI5voGRuoA0orK21LZnH0OaBsGyPxmURRGEYByWT inb99pF+vV5LDp+ab0tQvjWxUDCP8G4jjTu5mUfcjAWHNk13DynD5VQtLH7bFTfaHj+YXaIWj6Bk lSzlEUQjRBOvLYgFrD1xx5RG09fRmBK29fpd/G2dT2lIg2vpSptG+TaO46YU9OfVWldIAZeQLwtx FXVcO2TirECmYcPi6iCbscRVpL7NcEiJqL/NFEwf7qSDc59JtJW5VKTC4ggv/pDSURx3om5oLcu3 CLdwvitcsdVmfXKlPbgVVP4G/x5xC9ajvaTuk4YN52mVs3dzpjejcyvF0jCOr5BwbJ5E0WhCCT+c fluX9mln/wAAAP//AwBQSwMEFAAGAAgAAAAhAO7N3i2qAQAAdwMAABEAAABwcHQvcHJlc1Byb3Bz LnhtbKyT22rcMBCG7wt9B6N7rQ4+7NqsN8iHhUILoaQPoMjyrqhtCUmbpJS+exWvk24aAqF0bkZi mF/fP5K2Vw/jEN1J65SeSkBWGERyErpT06EE3272cAMi5/nU8UFPsgQ/pANXu48ftqYwVjo5ee5D 67WNgtDkCl6Co/emQMiJoxy5W2kjp1DrtR25D1t7QJ3l9+GAcUAU4wyNXE1g6bfv6dd9r4RstDiN AeAsYuUwk7ijMu5JzbxH7dLHC6RdMCkG+8WedlteOHu4rQcb3fGhBHgOgF4V9iHq+rGA/jSbQj74 z84vq+hkVQl+tuusbvOEwQzHNUxIQmGVtxXMGhKvMSaY0fWvRwiSFJ1ygtvu08gPsu2Ub7jnTx5J 8srlqITVTvd+JfS4jAsZfS+t0WqeGMHL2M92FuAA95KxiQnDGWVwnW8YTGKaQ1Y1DawqtkmzjOKU 4GdG2fPT4GfGxqj/iEfpm4D7Jm33jDUQt3ULkzRuYb6JCUyyisZVG1KcnAHTQhy59TeWi+/h8X2V fcWd7J4x03/BpJeY5BLynOdLR3//ld1vAAAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wAAAC2AAAA EwAAAHBwdC90YWJsZVN0eWxlcy54bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS 491l+fKSL80/SqKXWOxkNAP/4AESujXdpAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69Cm aJtwBqNzc0KIbUehuD2YWejt9WZR3G25DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgD XHo0xnFU1tW5qf0qLH5Asj8AAAD//wMAUEsDBBQABgAIAAAAIQDWsX4ucgEAANICAAARAAgBZG9j UHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEkkFvgjAU x+9L9h1IT9sBSjWiIYCJWzzNhGQuW3brylOa0Za0nei3X0FBl5l4o3m/9+Pf95rM96LydqANVzJF JAiRB5Kpgsttit7WS3+GPGOpLGilJKToAAbNs/u7hNUxUxpyrWrQloPxnEmamNUpKq2tY4wNK0FQ EzhCuuJGaUGtO+otrin7plvAozCMsABLC2opboV+PRjRSVmwQVn/6KoTFAxDBQKkNZgEBJ9ZC1qY qw1d5YIU3B5quIr2xYHeGz6ATdMEzbhDXX6CP1Yvr91VfS7bWTFAWVKw2HJbQZarBnSuuLRersG4 xNS6YSd4IFqWaaBW6WzFWUmh8hZQarcD0N6D+Dp+P3YtPdguoKLGrtyuNhyKxeFG73++VWjY8Xb3 WTTpkOGcnCZ5/CEUnptAfJxXX3kfPz2vlygbhSTyw6lPpmsyiUkUh7PPNuuf/rNQnBLcMhLik3Dd 6khMphfGXpB1if++wuwXAAD//wMAUEsDBBQABgAIAAAAIQBozEeCsgIAAFgGAAAQAAgBZG9jUHJv cHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKRV3U7bMBS+n7R3 sHKfpuVPULlBXRECjUJEC1yb+KSxcOzMNoXuEp5n2qRN2g1v0wfgFXaSkNCOCsHWm56fz8efP/uc 0N3bTJIpGCu06nmdVtsjoGLNhZr0vLPxvr/tEeuY4kxqBT1vBtbbDT9+oJHRORgnwBIsoWzPS53L u0Fg4xQyZluYVphJtMmYQ9dMAp0kIoY9HV9noFyw1m5vBXDrQHHgft4U9KqK3an716JcxwU/ez6e 5VgvpGPtmByLDML1jZ0dGjz79EIbbsON7TUaVCbt57kUMXMoSTgUsdFWJ46clPuQSN+AibRQjgaL QBQELBIovf2SX3ghONjYACgarEjTiBk2MSxPbdhpbyPm2acjWSwON2nwZNFj7fCvTYPKoAeCc1BP WQwv+XQ4HEiRl4napKOYSRigMGHCpAUs3QToAbDi0iMmDCKnrjuF2GlDrPiK177lkUtmoZCz502Z EUw5r4JVTmnL3DoT7mvlLDmzwGnQBEtzEbtoi43inJXxKrCqNca3AO+o3XlH7VI+MhZOgv1/+qVT 6oj2ssLVFicJ3rlbIXins6h4SaLSu+Lz+PDt8eEneXz4Mb/7Nb/7Pb+/n999XyTcWH3kIldmBkyK SyNey5EjMUndSsQFnqU4z5JMjfXULS+u6pkWOYUEDA4bIEPNQRJsakL6104rnYmYHIO70eYKdyDc sMT5AlziMyUy5pt6qZ8VS/32esvdOrJyoxH2HG7B4lQo6JL+8eGwT/ZgivTegv90Ovp8SCIJfPIm fH8QrRYEJxf5cg22GAAvn1b9SP56FgOd5UzNwoGwsSajmXWQ4eI6TI+EurJn+VjvIYm6q5eDdJQy AxwHZNP1TYAe4PMyssAPUqYmwGvMy0QxFs+rD0XY2Wy18VdOwDpWjLh6god/AAAA//8DAFBLAQIt ABQABgAIAAAAIQCKfmBEwgEAANoLAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAGj4dKEDAQAA4gIAAAsAAAAAAAAAAAAAAAAA+wMAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TAAAAANwEAACAAAAAAAAAAAAAAAAAALwcAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey9AAAANwEAACAAAAAA AAAAAAAAAAAALQgAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAEv1Pey9AAAANwEAACAAAAAAAAAAAAAAAAAAKAkAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0 LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAMsIczc1AQAAfQYAAB8AAAAAAAAAAAAAAAAAIwoAAHBw dC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAA IAAAAAAAAAAAAAAAAACdDAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQSwECLQAU AAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAACYDQAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEACky977ICAAD3DQAAFAAAAAAAAAAAAAAAAACT DgAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEA0efMsbINAACdgQAAFQAAAAAA AAAAAAAAAAB3EQAAcHB0L3NsaWRlcy9zbGlkZTMueG1sUEsBAi0AFAAGAAgAAAAhAKA8AGw0BAAA uRAAABUAAAAAAAAAAAAAAAAAXB8AAHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBLAQItABQABgAIAAAA IQDBcOvxXQMAAJoKAAAVAAAAAAAAAAAAAAAAAMMjAABwcHQvc2xpZGVzL3NsaWRlNS54bWxQSwEC LQAUAAYACAAAACEAfmCCARwNAAA8eAAAFQAAAAAAAAAAAAAAAABTJwAAcHB0L3NsaWRlcy9zbGlk ZTQueG1sUEsBAi0AFAAGAAgAAAAhAKbWfenMDQAAKpEAABUAAAAAAAAAAAAAAAAAojQAAHBwdC9z bGlkZXMvc2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAA AKFCAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc1BLAQItABQA BgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAAKdDAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc1BLAQItABQABgAIAAAAIQBemem1bwcAAB4wAAAhAAAA AAAAAAAAAAAAAK1EAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYA CAAAACEAlmfHGPAAAAAmBAAALAAAAAAAAAAAAAAAAABbTAAAcHB0L3NsaWRlTWFzdGVycy9fcmVs cy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAA AAAAAAAAAACVTQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHNQ SwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAACbTgAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3 AQAALAAAAAAAAAAAAAAAAAChTwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAcO8DOEUEAAAyDQAAIQAAAAAAAAAAAAAAAACnUAAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhALHdjH4uBAAApA8A ACEAAAAAAAAAAAAAAAAAK1UAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQIt ABQABgAIAAAAIQAR7FNwZAQAAEgTAAAhAAAAAAAAAAAAAAAAAJhZAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0My54bWxQSwECLQAUAAYACAAAACEAo1psFM0DAADGDAAAIQAAAAAAAAAAAAAA AAA7XgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAEC+ GyqHAwAAdAsAACEAAAAAAAAAAAAAAAAAR2IAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1 LnhtbFBLAQItABQABgAIAAAAIQC0z1gZuQAAACQBAAAsAAAAAAAAAAAAAAAAAA1mAABwcHQvbm90 ZXNNYXN0ZXJzL19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBC8oIv vAUAAM4dAAAhAAAAAAAAAAAAAAAAABBnAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54 bWxQSwECLQAUAAYACAAAACEA4Ngb8BkGAACXGgAAFAAAAAAAAAAAAAAAAAALbQAAcHB0L3RoZW1l L3RoZW1lMS54bWxQSwECLQAKAAAAAAAAACEAOEjmm4QfAACEHwAAFwAAAAAAAAAAAAAAAABWcwAA ZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEA4Ngb8BkGAACXGgAAFAAAAAAA AAAAAAAAAAAPkwAAcHB0L3RoZW1lL3RoZW1lMi54bWxQSwECLQAUAAYACAAAACEAp1OXfX0BAAAe AwAAEQAAAAAAAAAAAAAAAABamQAAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYACAAAACEA7s3e LaoBAAB3AwAAEQAAAAAAAAAAAAAAAAAGmwAAcHB0L3ByZXNQcm9wcy54bWxQSwECLQAUAAYACAAA ACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAADfnAAAcHB0L3RhYmxlU3R5bGVzLnhtbFBLAQIt ABQABgAIAAAAIQDWsX4ucgEAANICAAARAAAAAAAAAAAAAAAAALydAABkb2NQcm9wcy9jb3JlLnht bFBLAQItABQABgAIAAAAIQBozEeCsgIAAFgGAAAQAAAAAAAAAAAAAAAAAGWgAABkb2NQcm9wcy9h cHAueG1sUEsFBgAAAAAkACQAggoAAE2kAAAAAA== --_002_03d8d4c491e6452d90fdbdc254f68ce8XCHRCD006ciscocom_-- From nobody Thu Nov 10 11:28:00 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1011295AC for ; Thu, 10 Nov 2016 11:27:58 -0800 (PST) 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 WQ7Da6QS3FUa for ; Thu, 10 Nov 2016 11:27:57 -0800 (PST) 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 11D78126CD8 for ; Thu, 10 Nov 2016 11:27:57 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id i88so150306306pfk.2 for ; Thu, 10 Nov 2016 11:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DUyYyecDKy3nh9iWlrriQXa4AcwCTUKwSGpwLOZ/dIk=; b=ZQPoswqMZxv5irAqx2lWlLopK9GHkVz3k0r3cELXVc8m6w9K2e083UF/rkzLR1OEWF pmRKV4FLgezbIIhz0pDvb2x6NZCFTSWcpdeIpk0uG8egeeqvqf19osD9XLDkRBXh9O5W rdnyTr2EOKgoQafyWUdvPwabj1VBHW/M+qdzMUduv8F9OG63arOX/Fcat3GXOBGd0F2D lKsoxCqEbHd6wSaAUNdcUhLBP9DTWGLaZtSes//0k6fTJTLFizvUQ31j2hPf58/7chMM GmBhwhlzFqOD+uZY43tRjAJpcCKRvFGCxEe2WhvBFAqYNiDTxITw8oIF7Lu0eogOPWIW +XRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DUyYyecDKy3nh9iWlrriQXa4AcwCTUKwSGpwLOZ/dIk=; b=av601EBrrjufj2MppoYlOmWr0gtSygxM/hB5C1W+2O5J4KRwqyXsQT6ox7+6OYYWoQ mgWbfLZ9TeK5HSj43Hj1gVAjPUVawJiPH93OHd8BSGcrjn5R75AGm+bC3R5hsQcN6SbH vDAtQtE8adU2vE7391T19UZY/s/Verx850//Uo0BJnm0EmPyicx8RNb70co4H4OyX81R kO2Rs+kFpjyjRJ0ce9wvonR1OGtyUEuyvzbjZjIZLxHb2Bp+bvZxSX/7y9DpPEwuw3HI 89k4fCKByKRmKD9hiOAYjmFoOFyvVb2UlTG9VAg3hs1HTGf5qAeYPvgcdrdp0LxZ1Xmd Zj/g== X-Gm-Message-State: ABUngvcjZq+gH3aExph0OrLYvFqafQpYcQJqdaGNE/E67sqzYxTv+70MlsAmsRTQQKsHNA== X-Received: by 10.99.6.134 with SMTP id 128mr37827003pgg.53.1478806076315; Thu, 10 Nov 2016 11:27:56 -0800 (PST) Received: from [192.168.178.23] ([118.148.123.98]) by smtp.gmail.com with ESMTPSA id dc3sm9116239pad.32.2016.11.10.11.27.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 11:27:55 -0800 (PST) To: "Michael Behringer (mbehring)" References: <03d8d4c491e6452d90fdbdc254f68ce8@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6c10eee2-651c-66dc-f222-a5a07a470960@gmail.com> Date: Fri, 11 Nov 2016 08:27:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <03d8d4c491e6452d90fdbdc254f68ce8@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] ANIMA state machines, take two X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 19:27:59 -0000 Michael, I like this. I have a few comments on some of your open questions: > Discovery: > mDNS or GRASP? I feel very strongly that we need the ANI to be as self-contained as possible. Therefore, it must be possible for the ANI to create itself without depending on mDNS. Therefore, we must use GRASP discovery (or flooding, if we prefer an announcement method) for AN nodes. > one discovery method for BRSKI and ACP, or several? Non-ANI nodes can also use BRSKI. So to say this one more time, since I won't be in Seoul: BRSKI proxies MUST be discoverable by both mDNS and GRASP. (One open question in my mind is this: does the pledge know or care whether it is dealing with a proxy or directly with the registrar, if the registrar happens to be on the local link? That does affect some details, at least in the GRASP case.) > multicast domain info? > packet formats For the discovery methods, that is already settled by mDNS and GRASP, isn't it? For BRSKI itself and ACP formation, the formats belong in the BRSKI and ACP drafts. Regards Brian On 11/11/2016 05:04, Michael Behringer (mbehring) wrote: > I had already sent out an early version of the state machines before, here an update. > > To the high level state machine, I added a state "Proxy mode". A node is in that state when the ACP is up AND it can see a registrar. Other than that, I think the high level diagram should be ok. Looking for feedback. > > The state machine for the BRSKI pledge (it's a detail on the ANIMA state machine) still has a lot of open questions. Most are under discussion. I tried to illustrate where we have open points. > > I now tried also a state machine for the ACP. I'd appreciate some feedback on it. > > To me, the big open things are: > - nail down discovery protocol and packet formats for both discoveries (for bootstrap and ACP). > - decide which (if any) feedback we want to give to the pledge. > > But, I think these diagrams show nicely how all the drafts fit together, which was the purpose of this exercise. > > Feedback? See you in Seoul! (Will be there from Sunday evening) > Michael > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Nov 11 18:52:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C7129633 for ; Fri, 11 Nov 2016 18:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUXs6okRrntG for ; Fri, 11 Nov 2016 18:52:04 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42066129545 for ; Fri, 11 Nov 2016 18:52:04 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id C5EE71F906 for ; Sat, 12 Nov 2016 02:52:02 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B15703412; Fri, 11 Nov 2016 21:51:39 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: <20161030235424.GA30878@faui40p.informatik.uni-erlangen.de> References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> <8498.1477165076@obiwan.sandelman.ca> <20161030235424.GA30878@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Mon, 31 Oct 2016 00:54:24 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 12 Nov 2016 11:51:39 +0900 Message-ID: <9017.1478919099@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 02:52:05 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I am confused about the reason for this discussion. It seems you are > trying to figure out how to minimize the impact of the insecure > multicast piece of GRASP, but in the context of ANIMA this question > would be irrelevant, because we are not doing any insecure GRASP in > BRSKY or ACP with current draft - the use of insecure GRASP was removed > in those drafts before Berlin because of the majority of the bootstrap > teams choice for DNS-SD/mDNS. In ANIMA, agreed. > Do you see some IoT context where you would use insecure GRASP instead > of DNS-SD/mDNS, eg: in some IoT context ? In 6tisch-secure-join, I specified a GRASP query (over TCP) between Join Assistant and Registrar. It would be "secure" in the sense that it would not be exposed to traffic from new nodes, only existing nodes. The time sequence diagram I envisioned was: JA Int-Nodes Registrar ---disc-----> -----disc-----> <----------- TCP M_END-------- new TCP ------ QUERY ---M_REQ_NEG----> same TCP <----- REPLY ---M_END--------- same TCP However, I think that we will have to replace the GRASP query with something else, maybe just a CoAP request, as the TCP for GRASP is rather too much for some.. To be discussed. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYJoO7AAoJEJVM4Vb9/EKQFugIAKj7YGZoRLPLcmXBsWLnjI6k 2t4GmK+N3lVhecJgL/AVDQ1HM4GudKYenbFaaTZ+vSBPa3+fwgWfAyYKAwnjfNdC QnCJ9YI5RLVXThaqp/gmuUMJnoi1cFkz/3SZMv4aVpp6FgREFZtoNogEnlLsOxUm kW5+tQtvbjxolgnnlPgE5+kB59hK9JVVEPhp1sEY0jS0V1dSX5YTR7g5k19EDAHm bDrtfnNbIqumkOVLkZfKl4uTbEi1kxmzF0GBKKyaCr6oxVYzrcIkDMyy5QogO3eb JNEyY+psXRPWf717zypPwJuTA/DImqlz7exeCJ5XMeVOUpzL380JbX9lwNjqUZg= =85Nu -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 11 18:52:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E091296B3 for ; Fri, 11 Nov 2016 18:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KSs1RnJ_PCDj for ; Fri, 11 Nov 2016 18:52:08 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF01129664 for ; Fri, 11 Nov 2016 18:52:08 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id C8F3A1F906 for ; Sat, 12 Nov 2016 02:52:06 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id E8F58321D; Fri, 11 Nov 2016 21:52:03 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: <20161031221831.GA941@faui40p.informatik.uni-erlangen.de> References: <20161031000352.GA967@faui40p.informatik.uni-erlangen.de> <519c36bf-843a-d215-95d3-1efa829b7f60@gmail.com> <20161031221831.GA941@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Mon, 31 Oct 2016 23:18:31 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 12 Nov 2016 11:52:03 +0900 Message-ID: <9057.1478919123@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 02:52:10 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> Which, I have to point out, is not a consensus position; design teams >> propose, they don't decide. I'm waiting to see the next draft before I >> raise this issue on the WG list. > Right. I guess we've now posted all drafts we can before the deadline, > so let me change this mail threads subject to get the discussion > started. ... > b) I have just posted ACP draft -04 in which i have reversed the choice > of mDNS for ACP discovery by neighbors from the -03 text which had > mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more > details. Cool. I think that this is the right way. I am just not certain that we need a TCP reply to the M_DISCOVERY... the simple fact of receiving the multicast M_DISCOVERY tells one about the peer. That would be some new mode of GRASP, I think though. > I am not sure i understand the documentation ask. The ACP has a bunch > of (virtual) interfaces. In the most simple implementation option, each > ACP channel to an ACP neighbor is its own (p2p) L3 interface in the > ACP. And thats all the interfaces the ACP has. Ditto. > Ues, i am mostly interested in use-case explanations Michael has in > mind. > The other piece was that Michael was trying to figure out how to avoid > using LL multicast and instead use unicast: It wasn't so much that I want to avoid the "LL" multicast, so much as that it's kinda redundant, as the ACP is a p2p system. Both ends know where the other end is, might as well just leave a TCP connection up between them. It's basically the same as a BGP4 in many ways... BC> Given how ACP interfaces are p2p secured interfaces to neigbhors, you BC> could know upfront the LL IPv6 address of the neighbor on the BC> interface, but there is really no framework in IETF protocols that BC> leverages this optimization for p2p links, so i don't think we should BC> bother doing it. Its work without RoI. I see it as simplying myself. > The big security risk though is GLOBAL UNICAST MUST NOT BE > PERMITTED as a replacement for LL multicast. Thats an attack > vector. And typical socket software code is usually victim to Agreed. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYJoPTAAoJEJVM4Vb9/EKQpbgH/3V3I9zDV3RBIVFpVimUUrdN 6rpQNmi74Celc2MFS4jcHkzevO8YW5C3oJ3qtdd7TSorCXQUzdJasGoYopOne8qZ V6i2ew53/hq4sQycn42j4XCkSYHjyAbfVtTHiuV4Qf7tiHeX4vF7RdQLpE9J9aEy aeAriBbx8sb8JxvovAIcS828JW0i1y6irMfiUqni6fjAj1yV5T+fjvtplq8+tB3S M1ow//iGKPZ4s+m5l0x1W1biLlznVK9RMNnAd+RBMPjpkcxPWLcNWLk8mG3Thf/o yA/QjZyG3M5qh+cc9AeSWQb7yYUIOo7XEq1HEkPKz7ZdW6SfM9YMHlJ4n8hpdR4= =XOZa -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 11 18:54:26 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72FA1295D1 for ; Fri, 11 Nov 2016 18:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkwJT4rDHho1 for ; Fri, 11 Nov 2016 18:54:24 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE68129443 for ; Fri, 11 Nov 2016 18:54:24 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id 00BBE1F906 for ; Sat, 12 Nov 2016 02:54:22 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 71C44321D; Fri, 11 Nov 2016 21:54:20 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: References: <147793791802.23181.7413424443005063098.idtracker@ietfa.amsl.com> Comments: In-reply-to Brian E Carpenter message dated "Tue, 01 Nov 2016 12:40:36 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 12 Nov 2016 11:54:20 +0900 Message-ID: <9222.1478919260@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 02:54:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > registrars. In this case it will be possible for autonomic nodes that > wish to join the AN to use GRASP with no need for mDNS. If we don't do Please be clear: are these enrolled nodes, or new pledges? > this, the Anima solution will not be complete in itself. Especially > during the early formation of an AN after a cold start, this is a > problem. Please define "cold start", here. > So specifically I want bootstrapping-keyinfra to specify that - > registrars and proxies MUST be disoverable by both mDNS/DNS-SD and > GRASP. - pledges MUST use one of these two mechanisms Sure, but as a pledge, I don't want to announce a TCP socket that is open f= or attack. This is the part that I'm concerned about. The mDNS announcements From=20the JA can be multicast, and therefore can be observed without annou= ncing oneself... > Unfortunately I will not be in Seoul to argue this point, so it would > be nice to settle it by email. okay. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYJoRcAAoJEJVM4Vb9/EKQG8QH/i/Nc0cejXwy3F/3zI0YDV3x p2Bj9DU3QkFUd7qQfBM4mJ78FlWyPUiBSHHyJcCpLnbclxRIs7EZIg84TrwnxRKT nD80krpuWxF5ydOvEa1VoqAY7m1HeNJQIPet2SON/sf6cNJvjhs7zmgcLd41Euw/ IRCaX65n62Pv8tL5hUOAV/o6YtFPtgjndU6BG8Hw5VJe0YPdd/ns4kK95fQpSNKt XspmynA9wV5rdgZsokHU+n5suRajbKznbHDQR6T/952DxL+QI1XS5R9UYcY1iB/o cDdJjxbDh6cghLouuhUT/nST4ebXE/NTjgOIEpfiXrvE6gRo0XxnwhunvnRpbjI= =KgnH -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 11 18:56:55 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20599129545 for ; Fri, 11 Nov 2016 18:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G9n6XJ628Lv for ; Fri, 11 Nov 2016 18:56:53 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DDA129536 for ; Fri, 11 Nov 2016 18:56:52 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id 207CC1F906 for ; Sat, 12 Nov 2016 02:56:51 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 84C8C3412; Fri, 11 Nov 2016 21:56:48 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18011.1478097279@obiwan.sandelman.ca> Comments: In-reply-to Brian E Carpenter message dated "Thu, 03 Nov 2016 08:51:56 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 12 Nov 2016 11:56:48 +0900 Message-ID: <9542.1478919408@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 02:56:54 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> I have no problem with the use of a GRASP multicast discovery here. >> >> I wonder about the utility of the GRASP unicast TCP response to the >> ACP discovery. >> >> Why not simply respond to the ACP discovery with a key management >> initiation to the sender of the multicast? >> >> My reasoning is as follows: 1) four TCP packets across the insecure >> ("public") LAN just to say "okay" 2) insecure GRASP instance must open >> TCP port on insecure LAN, and accept connections from anything. (See >> discussion about possible CBOR encoding attacks). 3) discovery of ACP >> peers is meaningless outside of the the local-link. 4) IKEv2 (whether >> used for IPsec keying, or MACsec keying [%]) already provides all the >> negotiation we need, and does it with higher privacy and security than >> GRASP could. >> >> Yes, I realize that this is an "exception" case for GRASP, but I also >> claim that all insecure instances of GRASP will be extremely minimal, >> purpose built things. Call it uGRASP if you like. > I was trying to think of a reason why this wouldn't work, and can't > really find one. It could be sent as a GRASP discovery with a very > short timeout, so from the GRASP point of view it would fail promptly, > but the IKE message would arrive as if by magic. > Alternatively we could turn it round and use a GRASP flood (also LL > multicast), which never gets a TCP reply anyway. This seems like the right answer to me. I hadn't understood it's purpose. Could an M_FLOOD announce a node as an ACP peer, and also indicate if it could be a Join Assistant? (in a single message)? > Well, yes, all ACP is p2p traffic at the physical layer, but >> Brian, RPL has an associated multicast routing protocol called "MPL". >> We discussed it before, but it might be worth discussing it again to >> be sure we went down the right path. We decided that GRASP would do >> application layer multicasting -- as such, there will be hardly any >> actual layer-2 multicast, as all the ACP links are p2p. Using >> multicast destinations here is a convenience to not knowing what the >> peer's address is, except that once we have the first response via >> TCP, we do know the peer, and we might as well just use that channel >> for future communication. > Can MPL support LL scope? You don't need MPL for LL scope :-) MPL is to permit scope > 2 multicast to propogate across the RPL mesh the same way that a network that is entirely onlink would get multicast. >> I see no places in IoT where we would want to use insecure GRASP on an >> insecure link. The killer is the TCP reply, which implies a TCP >> stack, which most which to avoid. > Yes, but then GRASP's scope is between autonomic nodes, not between all > Things. I expect that most Things will be managed by an ASA in a > bigger autonomic node. agreed. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYJoTwAAoJEJVM4Vb9/EKQjtQIAJJt/34YY2CxHIXuLxd/g2qo Gn9AYWWn0FvmGI1hRGWflvetjW8ItWJejEvGelpaoJX2SsXFOCqu4T/sxHq+U0ug p15aPR86vxoskudBdG60gn4Ru4oCQr3OnjwJ731wgXpmQPdWcP84wH/Go6fFx+US 1SuxCZrjUeNo0DDIOFTYIZGEr/wsGhc59N6dFVYFtPpMmBlzjJLA/8TwIlfdvyD1 GZet0iiJ3sG4IhXS4HYzF5boM8W/SUPiW58aAiLCk3UMc8AXsKYoGJGdMr4PLtjC QvS63xal6voyxJeVCD0XY1qY3nFj2OG9yf605N65iBfVoSedIhF797kKue9ZhNw= =2yM0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 11 18:57:11 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901C01294C0 for ; Fri, 11 Nov 2016 18:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V-LjfbkAAMVl for ; Fri, 11 Nov 2016 18:57:09 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A044129652 for ; Fri, 11 Nov 2016 18:57:08 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id 90F9C1F906 for ; Sat, 12 Nov 2016 02:57:06 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id BD94C334A; Fri, 11 Nov 2016 21:57:03 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18642.1478097425@obiwan.sandelman.ca> Comments: In-reply-to Brian E Carpenter message dated "Thu, 03 Nov 2016 08:31:11 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 12 Nov 2016 11:57:03 +0900 Message-ID: <9574.1478919423@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 02:57:10 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > True, and I don't have a clear definition of what that code will do. > If it will actually support LL multicast send and receive sockets > exactly like physical LL interfaces do, I will be happy. But there's no > indication of that in the ACP spec. So, it's clear that we have to fix this doc bug with some running code. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYJoT/AAoJEJVM4Vb9/EKQO7EH/0jW30WsR1OF82Nt9pOEhQpG ytRxZ80akpe2LANV1ALigDv6MeP4DBrzLavpa/lU0hNPV3i8hCT7LPHPshLPYMjp qNXKhziJ3rwgtqUouANBbSsblTFWXpLcXAgaUvD1LVPXr8Og1vMRT/0cQSFepDVE 1v1JWkMO06c/mDbqRLVPkEL5cAM0AaPxnTX3FkiqhBGZyJ1tSmWo252Fsj2a735E hY93ycINwdBm8jcSWDCNtmrjt8S/lizuke9yzheTRtzt0QnxqKoKUf4yi31uyo4h i3MuCcXtpr/B4gW7m2A6kTJmQ5k2AjQyVvGt54DU7heLzm4zblwdVmf1mTz19ls= =I/Mj -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 11 19:11:28 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1F129620 for ; Fri, 11 Nov 2016 19:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 NhSpGHkH_iS8 for ; Fri, 11 Nov 2016 19:11:25 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7B51293FC for ; Fri, 11 Nov 2016 19:11:25 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id p66so20530426pga.2 for ; Fri, 11 Nov 2016 19:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=GoNBRevbsS/sKw5BgcLG9l2lx0Jz4llYyQw3kBjPXjs=; b=LVRFFoJTqMYDbAkhXZNt5T8NlLSbmGhViS+kMzOs9QsxKQl3pkSYF18AThmUr6KSXd 7DhhWgm08jq94LWUVjcn6jZggMkMFvux0vmns8BBjNfJZdW/C/SEkItooYjGE2KR1qlL ui18yCi2uwVtBHekwOxGPA2gpyzZCV7R0LtfHTEQM0i/sM6lrdRATquGY91RXRunAmsf UT8Ei7t8EROD6UJ5SGkCUJYvIqI1zAxCAkJ0qhHU+YSIIBJ/T5vWGt3eWFcjyc/5Dh9g nAEpxWCMb7Mjq6JQyJ8sjw121mIHFQFmygRKUClIeawjNVztcw5tt0b9ZmX7h7jh9Jlw 1jMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GoNBRevbsS/sKw5BgcLG9l2lx0Jz4llYyQw3kBjPXjs=; b=apyA+RflTOvusd8jzsZbptG6AVmzT2xNWtNBltbms0fq/xNHgZ86DaSzl/sSwJYH3S vT8P1iF8eFXwEnDHhspFlmg+Sk/MbPdwt97F0MMSoQMhgkngP2wqsDPSK9RA8bSGfJ/D SBCZ6ykHeop+RNK41jY+9mn+cvU3vFm5b12EW01JYkid8dwDz5Vp+ZVdAPQg9pzaI/mV x/bi7kI7v5aQ88/DH50g55FLCmKWOi5+CVyrawHeU1GYxjygrpgFwd+9rUzBDwVsWy+1 35mUilOJDgZ4/UQM++tezhzPOFYsPnG+YgkWu/BGBBCMm9iJMaXv7dJwJcoQBbGc93P9 6Afw== X-Gm-Message-State: ABUngvfouToi3UkAVfr2f7QUG2HBfPFmoi054eA9ypteXASzbRafLH/kySM7cZWNIZ5hPw== X-Received: by 10.99.237.17 with SMTP id d17mr9930397pgi.48.1478920284659; Fri, 11 Nov 2016 19:11:24 -0800 (PST) Received: from ?IPv6:2406:e007:6d7b:1:28cc:dc4c:9703:6781? ([2406:e007:6d7b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x1sm17178462pax.38.2016.11.11.19.11.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2016 19:11:24 -0800 (PST) To: Michael Richardson , Anima WG References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> <8498.1477165076@obiwan.sandelman.ca> <20161030235424.GA30878@faui40p.informatik.uni-erlangen.de> <9017.1478919099@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <760b75f2-c557-f702-61f1-3470bd8fe8ca@gmail.com> Date: Sat, 12 Nov 2016 16:11:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9017.1478919099@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 03:11:26 -0000 So, I guess you've arrived... below: On 12/11/2016 15:51, Michael Richardson wrote: > > Toerless Eckert wrote: > > I am confused about the reason for this discussion. It seems you are > > trying to figure out how to minimize the impact of the insecure > > multicast piece of GRASP, but in the context of ANIMA this question > > would be irrelevant, because we are not doing any insecure GRASP in > > BRSKY or ACP with current draft - the use of insecure GRASP was removed > > in those drafts before Berlin because of the majority of the bootstrap > > teams choice for DNS-SD/mDNS. > > In ANIMA, agreed. > > > Do you see some IoT context where you would use insecure GRASP instead > > of DNS-SD/mDNS, eg: in some IoT context ? > > In 6tisch-secure-join, I specified a GRASP query (over TCP) between Join > Assistant and Registrar. It would be "secure" in the sense that it would not > be exposed to traffic from new nodes, only existing nodes. > > The time sequence diagram I envisioned was: > JA Int-Nodes Registrar > ---disc-----> -----disc-----> > <----------- TCP M_END-------- new TCP > ------ QUERY ---M_REQ_NEG----> same TCP > <----- REPLY ---M_END--------- same TCP > > However, I think that we will have to replace the GRASP query with something > else, maybe just a CoAP request, as the TCP for GRASP is rather too much for > some.. To be discussed. I agree, GRASP is designed for autonomic nodes and I don't think we should promote it for other usage at the moment. Brian From nobody Fri Nov 11 19:17:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524F812963F for ; Fri, 11 Nov 2016 19:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Tekn3lw0Py8r for ; Fri, 11 Nov 2016 19:17:01 -0800 (PST) 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 B7B6A1295C8 for ; Fri, 11 Nov 2016 19:17:01 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id p66so20587205pga.2 for ; Fri, 11 Nov 2016 19:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=8IDxYJ2R6MGMxZNf09Wi7B4CR9gwnkReQWA15od15HM=; b=tabl5BhxTc8Hz4WPuvSVBB3y/VYSm+jrAAHZduUS2if9ayFUUcIkBxyNSisjDamE8Y cJYYcMjo2rhIhsH7QatQ0ZWuN4dhOU3g3acUrh9ApiowEt+27UYj53Tlcyv3nwaluRLv iFWzPQkNXyinshIo36/kMIHKJ3bVQReSrfdWVSgiy32BT5cqM7iJQb183UMsteW4GZLO oaxBOI4WP/QFT1f1EVClNuqGh4krdMQC0POgynFkUgcNtZQbHqPUkwB/o9L4HIO7zG2B MP/sLnpkS0yDA0ZMZztvwJfcVZaUWaAqopv/Gv1wUwCJmdJ2I/KLWxFoU+X5BIDtzrik UsYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=8IDxYJ2R6MGMxZNf09Wi7B4CR9gwnkReQWA15od15HM=; b=jKCweJ/QNsCOaEfmryTnqJsLa7GhjKEe+rTnYMD9slIliriRERRYlhezU3uhUWuAAy 4p8h5KbFNyDcb4A3xP8Q43Id90V72J21IUzzZ00fgECwplfPVJZnTZU5ZpMOv8ivZDlm pYd2v48uWXDboD+71t6JuBZjls2WaITptYfgCReYtzgjnkQoh87Zm95z8MFzhPQUVV34 xeu9CJeqfE2fQqYTBtjdRfrTK+URc6vmkEnjmV+8qYbI5x1vKYwd1IA5mNHNrBFYhXhE TQGy6WRx5+Nrrz7l38I1ObeYxrptMta7rwuf40uKXUkwGJm2KwqR5YmtktqRhFoHJroh pq/w== X-Gm-Message-State: ABUngvdwmbKIwqORAh8LBd5FReAWhp86lnR/XMSO90d86/dsOtkZpyDjayV907JBu6UG5A== X-Received: by 10.98.80.140 with SMTP id g12mr13302460pfj.54.1478920621306; Fri, 11 Nov 2016 19:17:01 -0800 (PST) Received: from ?IPv6:2406:e007:6d7b:1:28cc:dc4c:9703:6781? ([2406:e007:6d7b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id sh9sm18204096pac.41.2016.11.11.19.16.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2016 19:17:00 -0800 (PST) To: Michael Richardson , Anima WG References: <20161031000352.GA967@faui40p.informatik.uni-erlangen.de> <519c36bf-843a-d215-95d3-1efa829b7f60@gmail.com> <20161031221831.GA941@faui40p.informatik.uni-erlangen.de> <9057.1478919123@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <034af282-463c-fb53-8d7b-4b5eaee0f1cc@gmail.com> Date: Sat, 12 Nov 2016 16:17:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9057.1478919123@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of GRSP in discovery X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 03:17:03 -0000 On 12/11/2016 15:52, Michael Richardson wrote: > > Toerless Eckert wrote: > >> Which, I have to point out, is not a consensus position; design teams > >> propose, they don't decide. I'm waiting to see the next draft before I > >> raise this issue on the WG list. > > > Right. I guess we've now posted all drafts we can before the deadline, > > so let me change this mail threads subject to get the discussion > > started. > > ... > > > b) I have just posted ACP draft -04 in which i have reversed the choice > > of mDNS for ACP discovery by neighbors from the -03 text which had > > mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more > > details. > > Cool. I think that this is the right way. I am just not certain that we > need a TCP reply to the M_DISCOVERY... the simple fact of receiving the > multicast M_DISCOVERY tells one about the peer. > That would be some new mode of GRASP, I think though. > > > I am not sure i understand the documentation ask. The ACP has a bunch > > of (virtual) interfaces. In the most simple implementation option, each > > ACP channel to an ACP neighbor is its own (p2p) L3 interface in the > > ACP. And thats all the interfaces the ACP has. > > Ditto. > > > Ues, i am mostly interested in use-case explanations Michael has in > > mind. > > > The other piece was that Michael was trying to figure out how to avoid > > using LL multicast and instead use unicast: > > It wasn't so much that I want to avoid the "LL" multicast, so much as that > it's kinda redundant, as the ACP is a p2p system. Both ends know where the > other end is, might as well just leave a TCP connection up between them. > It's basically the same as a BGP4 in many ways... I don't care how it's implemented inside the ACP. The GRASP engine has to send its discovery and floood messages to all on-link neighbours, and no off-link neighbours, so it needs to *look like* a LL multicast socket, whatever the ACP VRF does internally. > BC> Given how ACP interfaces are p2p secured interfaces to neigbhors, you > BC> could know upfront the LL IPv6 address of the neighbor on the > BC> interface, but there is really no framework in IETF protocols that > BC> leverages this optimization for p2p links, so i don't think we should > BC> bother doing it. Its work without RoI. That wasn't BC. > > I see it as simplying myself. > > > The big security risk though is GLOBAL UNICAST MUST NOT BE > > PERMITTED as a replacement for LL multicast. Thats an attack > > vector. And typical socket software code is usually victim to > > Agreed. Sure. Who ever suggested that? Brian From nobody Fri Nov 11 19:27:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660C41295B9 for ; Fri, 11 Nov 2016 19:27:11 -0800 (PST) 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 lGdWFiGiF4WH for ; Fri, 11 Nov 2016 19:27:08 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 F2B191295A8 for ; Fri, 11 Nov 2016 19:27:07 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id d2so15445194pfd.0 for ; Fri, 11 Nov 2016 19:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3vA/fWb5ZI+zwRJXp6qhYkBCdj0pE3gvLbvOSQ7s55k=; b=H88KL4imb7h4+7kIGJw8d5qJo1SMo4MfkHPB+3G24xD39UXUvn0Ns4F5qNQTUxoi5q GegWGpLSZ9YTiRC4cRmNKkjQhfw6/oC543GgHBP4qw1XtSpbOnIddiCL0qXvPAVJwOtl +pM/VaxNAn8gDRBoVfSgNTYLg0XxjQz+rueNEtrG3i4U98WUJUmRTXsRsgE52utFfz7l 8NHr19ocsW1SebIcSGwK3qxvqPtE+pPXxxWs5stPZB+X9Bijt5y/sjS9AS8nxeaAbenD 0zLNZAg5ZDYK0Kzr9u0dTvJEVs7M1G/Pj5EHCtenWXMI/am1JlaF5Hx6VfUCvvrNeyEB IgJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3vA/fWb5ZI+zwRJXp6qhYkBCdj0pE3gvLbvOSQ7s55k=; b=bb9p1eDfFbQRyScq6OhVfT0v5//aQqic+tnbuUwPGaM49SvgKZOSbHrZx042+vreFX OUJjKMGugw7YZ1bQXSIp6JcHbCO45rEJ3rJL5nqRi9tMKO8eQgCKUiMvbOtQI7yF0/XZ zsvTVgTFvYVQO1JZJo2D4zjtHiJTADReNoV7ijoHnb4Yz/+iJ7ZZEe1DILHt4i5dWQjB /RyHCFieV5IWJDoV8WuMPu7z+aTdBPAEhQMrkD1nMhz7wNviRYWz6BMZ70pGw3JDuhTI la/ItSkRsJgaqv8ABiuCR69WHoe0Pp2444nK6CXkDynzYYUkWjmvJafTYtWJ/0DO7KJA d8Ag== X-Gm-Message-State: ABUngvdNZWunC5C+1jdjELuUAPrClDTQP4MutVJo94dDAbFMwGxm3alDNC4dyOo3qpsx9A== X-Received: by 10.99.155.26 with SMTP id r26mr50254201pgd.165.1478921227369; Fri, 11 Nov 2016 19:27:07 -0800 (PST) Received: from ?IPv6:2406:e007:6d7b:1:28cc:dc4c:9703:6781? ([2406:e007:6d7b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id uk8sm3815918pab.4.2016.11.11.19.27.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2016 19:27:06 -0800 (PST) To: anima@ietf.org References: <147793791802.23181.7413424443005063098.idtracker@ietfa.amsl.com> <9222.1478919260@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <399b6388-5115-78c8-17d0-04fc1592dec4@gmail.com> Date: Sat, 12 Nov 2016 16:27:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9222.1478919260@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 03:27:11 -0000 On 12/11/2016 15:54, Michael Richardson wrote: > > Brian E Carpenter wrote: > > registrars. In this case it will be possible for autonomic nodes that > > wish to join the AN to use GRASP with no need for mDNS. If we don't do > > Please be clear: are these enrolled nodes, or new pledges? Pledges. > > > this, the Anima solution will not be complete in itself. Especially > > during the early formation of an AN after a cold start, this is a > > problem. > > Please define "cold start", here. Power off on all racks; humans pressing factory reset buttons. Systems coming back in random order. All dependencies broken. > > So specifically I want bootstrapping-keyinfra to specify that - > > registrars and proxies MUST be disoverable by both mDNS/DNS-SD and > > GRASP. - pledges MUST use one of these two mechanisms > > Sure, but as a pledge, I don't want to announce a TCP socket that is open for > attack. This is the part that I'm concerned about. The mDNS announcements > From the JA can be multicast, and therefore can be observed without announcing > oneself... Yes, and that's why I thought that in Berlin we'd agreed on a Flood based model (where the proxy floods out its info and any pledge can listen). That's what's coded in demo form as Reggie.py, Procksy.py and Pledji.py at https://www.cs.auckland.ac.nz/~brian/graspy/brski/ . I also coded the discovery approach but it's more complex as well as more vulnerable. Brian > > > Unfortunately I will not be in Seoul to argue this point, so it would > > be nice to settle it by email. > > okay. > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Nov 11 19:34:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA731294F7 for ; Fri, 11 Nov 2016 19:34:49 -0800 (PST) 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 OF6sLwibbVbN for ; Fri, 11 Nov 2016 19:34:47 -0800 (PST) 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 65670129610 for ; Fri, 11 Nov 2016 19:34:47 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id 189so15425545pfz.3 for ; Fri, 11 Nov 2016 19:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YLcyJFpCtQvM5scx5ljwSSaDuzgYF5KT2WjHbWrtyhk=; b=KDz0QI24YcLyOCg02F1bn0rveoENJjNdocCjHur+pz/2OH+LZBLJEqKbnUeF0ZbFCt pZTStl5zWh2NpcambNpml3FfILYHb3XVeW6xFuUOylx4x0tZdR/H46mRDNlcgdSkP6Zr 3qwa9wTaFs3AvoVuAbBTmR39r5UGNB+SWIsq1xPbFvfNui39NF9UX9LGkfSzGhRmACp8 A/PrcNjnUstqDHmHaMLudH4301qNtLoaC8PfsSdWKs983ND6bkFdyk07cGe9DdHVxx6Q o7qTi4IUcqPSuK0mR20bDw5XMZt1/bgyRRSU/d3xfL3jVGTDBWRLYrAZOMpbzZrD/xL7 QKDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=YLcyJFpCtQvM5scx5ljwSSaDuzgYF5KT2WjHbWrtyhk=; b=UkIUy1TxUs8VESVH5l6PWukDxpbDK4hz1UTHCazq6cpW7+iczvJ2KV4DkcWk1+yQn6 IAf2T40gfoPkQ9yXDnxgAMlvzUHALYgG00VPzjTIadJMvEy0UuQ4tndMKohK0osxVrkm r/I96xpbfGv0OHqjoSG5nFxHU4hAcfEPPi8JR6Ggi3Z077uPW+9gbw3ZaPnKInbqvyZl pQ9/8pYqAweQg2YB7OOtWUvncrMvuJxhRo8BZJC6VCmgc4F+LkPe5aIeEuRm+gDvK1wX lwG+wbsZ+GF+vqxxGOFJvkfiUjnYvQQUD8I1Vn4YXfLGbt4CAzA+7VJQSw+m774Hf2Fo BIqw== X-Gm-Message-State: ABUngvdK4EfGhhFewyIQ4MnXw0hmOD+/t8YEhkGdJXmNjIC0lU3ep24uhjixzhniPIRusw== X-Received: by 10.99.8.133 with SMTP id 127mr10242882pgi.76.1478921686763; Fri, 11 Nov 2016 19:34:46 -0800 (PST) Received: from ?IPv6:2406:e007:6d7b:1:28cc:dc4c:9703:6781? ([2406:e007:6d7b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c142sm18296481pfb.23.2016.11.11.19.34.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2016 19:34:46 -0800 (PST) To: Michael Richardson , Anima WG References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18011.1478097279@obiwan.sandelman.ca> <9542.1478919408@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2abbdca2-5db3-3359-c11f-b41391849c69@gmail.com> Date: Sat, 12 Nov 2016 16:34:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9542.1478919408@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 03:34:49 -0000 On 12/11/2016 15:56, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> I have no problem with the use of a GRASP multicast discovery here. > >> > >> I wonder about the utility of the GRASP unicast TCP response to the > >> ACP discovery. > >> > >> Why not simply respond to the ACP discovery with a key management > >> initiation to the sender of the multicast? > >> > >> My reasoning is as follows: 1) four TCP packets across the insecure > >> ("public") LAN just to say "okay" 2) insecure GRASP instance must open > >> TCP port on insecure LAN, and accept connections from anything. (See > >> discussion about possible CBOR encoding attacks). 3) discovery of ACP > >> peers is meaningless outside of the the local-link. 4) IKEv2 (whether > >> used for IPsec keying, or MACsec keying [%]) already provides all the > >> negotiation we need, and does it with higher privacy and security than > >> GRASP could. > >> > >> Yes, I realize that this is an "exception" case for GRASP, but I also > >> claim that all insecure instances of GRASP will be extremely minimal, > >> purpose built things. Call it uGRASP if you like. > > > I was trying to think of a reason why this wouldn't work, and can't > > really find one. It could be sent as a GRASP discovery with a very > > short timeout, so from the GRASP point of view it would fail promptly, > > but the IKE message would arrive as if by magic. > > > Alternatively we could turn it round and use a GRASP flood (also LL > > multicast), which never gets a TCP reply anyway. > > This seems like the right answer to me. > I hadn't understood it's purpose. > > Could an M_FLOOD announce a node as an ACP peer, and also indicate if it > could be a Join Assistant? (in a single message)? Certainly. We have no limits on the content of an objective, and actually M_FLOOD is defined to carry more than one objective if required. This seems like a good approach to me. > > > Well, yes, all ACP is p2p traffic at the physical layer, but > > >> Brian, RPL has an associated multicast routing protocol called "MPL". > >> We discussed it before, but it might be worth discussing it again to > >> be sure we went down the right path. We decided that GRASP would do > >> application layer multicasting -- as such, there will be hardly any > >> actual layer-2 multicast, as all the ACP links are p2p. Using > >> multicast destinations here is a convenience to not knowing what the > >> peer's address is, except that once we have the first response via > >> TCP, we do know the peer, and we might as well just use that channel > >> for future communication. > > > Can MPL support LL scope? > > You don't need MPL for LL scope :-) > MPL is to permit scope > 2 multicast to propogate across the RPL mesh the > same way that a network that is entirely onlink would get multicast. Duh. > > >> I see no places in IoT where we would want to use insecure GRASP on an > >> insecure link. The killer is the TCP reply, which implies a TCP > >> stack, which most which to avoid. > > > Yes, but then GRASP's scope is between autonomic nodes, not between all > > Things. I expect that most Things will be managed by an ASA in a > > bigger autonomic node. > > agreed. > Good! Brian From nobody Fri Nov 11 19:38:26 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C96B129525 for ; Fri, 11 Nov 2016 19:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7RAWVtgrJlq6 for ; Fri, 11 Nov 2016 19:38:23 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C2C1294F7 for ; Fri, 11 Nov 2016 19:38:22 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id x23so17927557pgx.1 for ; Fri, 11 Nov 2016 19:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=RvuG6ifwI7wN9JOw/S1WkUP6zOmx6S0AQ2i+HVBcXFs=; b=OUay2sArwxGJrq/TRUyJjt0CTA8Gs9qRluylDFnuR9vtGMv7JgZ8cOFlUVDkjNGf9H cMMrginb+Zu7P44VOrs2msvIdSYLxtCqZo+uOhiQB7gyOZZGvbk0/ARCSivU+qnzKgWL l44g0tHrdsb6wAHtPIKiYKNM6yVmh8SAkU5lNTr5Qr27mP5gMXIH/oICakWYnP1wqWeW skHEzNxr7iFX5Q2C1vmY5XgzP63GNcviEal0lOhFjFMawWeD7zKzETY3RSE1dOXusmTd 6cHbb4scDWJfbq99SsvuSkZkIxjCRquiC51H1qYfUMZtNbWo4DWQCcqTDZLdCcRU2qBT 67bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=RvuG6ifwI7wN9JOw/S1WkUP6zOmx6S0AQ2i+HVBcXFs=; b=m0vIdebiCZSpd6XtWhx1uWWRzoe/3EHzcAp8iWI7540yomeufp1wBWyrL09mdMR4oj esjEzBd5cE50scGwu1Wo7vs6pVRDQ8o2rfrJTYdHmMvUDLse0FoXKwYENecZ/5/Nh9Mx BXbFqTyFUpgD3HThbgHe/sIGOpIRDj+vg+d3ei8L4Ad8X/eRb7ea0uRs+sSQg0Oxak3F HdDkeC1JAxFNTGnWGUdhzxZT9DQpMGfA5fJjby8Ez9ztKbyjE1dK7OitoDX2XTBFMexg frJt1vB+3SVjwME7p48SDlJZH5yLAZ7T5gStEKZW3aIbM3h+fN2wI3I/3QZadSZ5aIXB 3pog== X-Gm-Message-State: ABUngveTe+u6nqhVI3ClIYbiSJB4NRnbyOjWw4m0HmPOifvoQkuyGl9dEGbp9EsqM3xsKw== X-Received: by 10.99.43.8 with SMTP id r8mr50341552pgr.83.1478921902539; Fri, 11 Nov 2016 19:38:22 -0800 (PST) Received: from ?IPv6:2406:e007:6d7b:1:28cc:dc4c:9703:6781? ([2406:e007:6d7b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l187sm18322978pfc.0.2016.11.11.19.38.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2016 19:38:21 -0800 (PST) To: Michael Richardson , Anima WG References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18642.1478097425@obiwan.sandelman.ca> <9574.1478919423@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1e6f855a-7a5a-7695-ee15-827450d95597@gmail.com> Date: Sat, 12 Nov 2016 16:38:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9574.1478919423@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 03:38:24 -0000 On 12/11/2016 15:57, Michael Richardson wrote: > > Brian E Carpenter wrote: > > True, and I don't have a clear definition of what that code will do. > > If it will actually support LL multicast send and receive sockets > > exactly like physical LL interfaces do, I will be happy. But there's no > > indication of that in the ACP spec. > > So, it's clear that we have to fix this doc bug with some running code. Yes. I'd love if someone could send me an ACP module to install on my Linux box. One for my Windows box would be nice too. (Both with a Python interface please.) Brian From nobody Fri Nov 11 19:41:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB97B129691 for ; Fri, 11 Nov 2016 19:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 i8f-FYRM344M for ; Fri, 11 Nov 2016 19:41:03 -0800 (PST) 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 4FD1D1294F7 for ; Fri, 11 Nov 2016 19:41:03 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id p66so20838512pga.2 for ; Fri, 11 Nov 2016 19:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZTpiapXxkdlm2Emgk5ViFYW15Vt1XAhoIz6O4N4Q6mY=; b=XVYvx2viKeWui+OhFxVYTAgIc2PqDV9TCAnF+4sQqnfnPnas8JdJ6wBBY5rW/HI6jn Bq8P4SrBbXRksC9wSvb+hfH/R2L0DhGngHZt5mLkB7Hf6NIgUq2GjtK25Ua2Kh34vyy0 c8GAftPSuer80NjdsEBRfzHbuWfITe+o/pjIXb1n3xLp9avBHQlvG5PMO3+qjkHm+KR5 /pGUUU8ikqbvMUJ1aaaWRkF0RLACqmEyNuZkAcFcpS2/8NLdMXmj2Cmpi5N0lOY5qeBv IxwP2pCmD01/8Wz7bIK0+OegKQFUMV0AWDmFIdwExDEdO4E//T1shaOyDoFfj9mdlHE4 Z2cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZTpiapXxkdlm2Emgk5ViFYW15Vt1XAhoIz6O4N4Q6mY=; b=G8tP+eOaeldU7C3Zm38Mxfb77cQFw8F6fPk5yaacTMNB+MkvIIiENAmV0QW/7ZiDEs wPt/iHarTbfT2yPrXDAyF3Vy2CEnADzb5cq6m0cLsn3pRaawpGT8aufQEWfaJOs5AQdw jSxzypTaz82H+/yUAFZlIWQAyvnS2Gu+YzwPuoaQXhh8u1UYo3EPb8SpoBsXKrjsLlUW Nhf/yfsPywF9VtdQu9x2/QoQQKsGAyDJpjzDaDObcRxcI44pSZwYBrJGAuYGNz187j6u RObBh3pprw4Pv1YRBGma4AZ17j6Nc4agxbqJEzze3va8vCooDdF9Iq+/jF2m1nC/gEza lA2A== X-Gm-Message-State: ABUngvcRMdEtt6KLlMQsFIEathD4zV2z6Hzvzejcr+S9j4+BwTh+GU6tUcWT8VTulCpWpw== X-Received: by 10.99.139.199 with SMTP id j190mr50310934pge.115.1478922062929; Fri, 11 Nov 2016 19:41:02 -0800 (PST) Received: from ?IPv6:2406:e007:6d7b:1:28cc:dc4c:9703:6781? ([2406:e007:6d7b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id af14sm18356139pac.13.2016.11.11.19.41.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2016 19:41:02 -0800 (PST) To: Michael Richardson , Anima WG References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18642.1478097425@obiwan.sandelman.ca> <9574.1478919423@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0aab1163-16c5-f940-fd59-b86e7952b1dd@gmail.com> Date: Sat, 12 Nov 2016 16:41:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9574.1478919423@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 03:41:05 -0000 On 12/11/2016 15:57, Michael Richardson wrote: > > Brian E Carpenter wrote: > > True, and I don't have a clear definition of what that code will do. > > If it will actually support LL multicast send and receive sockets > > exactly like physical LL interfaces do, I will be happy. But there's no > > indication of that in the ACP spec. > > So, it's clear that we have to fix this doc bug with some running code. Yes. I'd love if someone could send me an ACP module to install on my Linux box. One for my Windows box would be nice too. (Both with a Python interface please.) I'm not joking, either. I've been very happy checking GRASP concepts by writing prototype code, and I think we need to do the same for all components of the ANI. Also a virtual ACP that we could extend between sites across the Internet would be great for testing. I don't see any reason why a hackathon needs to be held in one room. Brian Brian From nobody Sat Nov 12 14:04:07 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC9F12950F for ; Sat, 12 Nov 2016 14:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VEFZ5TaXqRR for ; Sat, 12 Nov 2016 14:04:02 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E2A129538 for ; Sat, 12 Nov 2016 14:04:01 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id D58F81F91A; Sat, 12 Nov 2016 22:03:59 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 651C3341D; Sat, 12 Nov 2016 16:17:23 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: <03d8d4c491e6452d90fdbdc254f68ce8@XCH-RCD-006.cisco.com> References: <03d8d4c491e6452d90fdbdc254f68ce8@XCH-RCD-006.cisco.com> Comments: In-reply-to "Michael Behringer (mbehring)" message dated "Thu, 10 Nov 2016 16:04:27 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 13 Nov 2016 06:17:23 +0900 Message-ID: <903.1478985443@dooku.sandelman.ca> Archived-At: Cc: "Michael Behringer \(mbehring\)" Subject: Re: [Anima] ANIMA state machines, take two X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 22:04:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Behringer (mbehring) wrote: > I had already sent out an early version of the state machines before, > here an update. > To the high level state machine, I added a state "Proxy mode". A node > is in that state when the ACP is up AND it can see a registrar. Other > than that, I think the high level diagram should be ok. Looking for > feedback. I disagree with this state or machine. The proxy process is, as you described, dependant upon having reached the In ACP mode, and having discovered a Registrar. That's true. Assuming IKEv2 (whether keying IPsec, or keying MACSEC [%]) There is some RPL state machine inside the In ACP state as well, but I'm not=20 But, I wouldn't describe it as a seperate state, rather it's an attribute of having reached In ACP mode. I would expect the ACP process, once it has= =20 been informed by the RPL daemon that it has found a ground RPL DODAG to joi= n, that it would spawn off the Join Assistant process. The Join Assistant would then open a TCP socket to receive the GRASP reply (binding the socket to the ACP ULA address), and then do a GRASP M_DISCOVER= Y. Once it gets a response from a Registrar, it would begin listening for New Node discovery messages and relaying. This would be a seperate state machine. Would you like this in the bootstrapping document? > The state machine for the BRSKI pledge (it's a detail on the ANIMA > state machine) still has a lot of open questions. Most are under > discussion. I tried to illustrate where we have open points. You have listed: Discovery:=09 mDNS or GRASP?=20 one discovery method for BRSKI and ACP, or several?=20 multicast domain info?=20 packet formats BRSKI: Feedback to the pledge? (specifically: Reason for rejection / retry?) Let me be more specific, because I think these are not open questions. Discovery of AN peer: - GRASP M_FLOOD (MTI) Discovery of Join Assistant by Pledge: - GRASP M_FLOOD (MUST for JA, SHOULD for Pledge) - mDNS (SHOULD for JA, MAY for Pledge) The "multicast domain info" question is vague to me, but if you mean the multicast scope, it's LL, scope=3D2. (scope=3D1 being host) Packet formats are determined by GRASP and mDNS. The feedback to the pledge about rejection would occur inside of EST, and so is about RFC7030, right? [%] - Linux now has a MACSEC implementation I noticed.=20 If supporting MACSEC is interesting to many, then we need a KMP for it, and we need to negotiate it's use via IKEv2. I suggest that a document doing this would not be very long or difficult to pass through the IPsec WG. If supporting MACSEC is not a priority now, then as long as we negotiate the ACP using IKEv2, then we can add it later on rather easily. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYJ4bjAAoJEJVM4Vb9/EKQXwEIAJl7IoUTJsNzc5cxBv1RYpxk Rx8+gNMM318LvjEC2Zbecau5uKwRNppYiorc0wNEmgY1G4GFoFl9t52j0a2TPAFA e9r1N/ADWV3MGNaumSxDGyc6xqta73GOO6ybMY1qNG9HINGTFQSacpIEaajYyMvD s5MVQGGY2b0EKQNoSBpxsCQXYCsN58M5QTeTp5qWzMH2YW+r1f9JqTiwah9DjCbf 3iKqUsxdGbyy/nNOkkcpJtSSbxsOTjMliBjw9cAR7af2PlcXRz/sYK+VY9msjYa2 G212SsOFnRKuRKl33WMQF8GucBBlx4yFKHm9ZXEgkjDFTtgZb5OeqeinSURqGA8= =fBVi -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 12 23:02:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783D41296C0 for ; Sat, 12 Nov 2016 23:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQW4XJFPIE7Q for ; Sat, 12 Nov 2016 23:02:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C566D1295FB for ; Sat, 12 Nov 2016 23:02:46 -0800 (PST) Received: from dooku.sandelman.ca (unknown [211.44.215.72]) by relay.sandelman.ca (Postfix) with ESMTPS id 147101F906 for ; Sun, 13 Nov 2016 07:02:45 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id BE5C4321D; Sun, 13 Nov 2016 02:02:41 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Mon, 07 Nov 2016 07:01:38 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 13 Nov 2016 16:02:41 +0900 Message-ID: <28804.1479020561@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 07:02:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: >> Devices that have been brought up and are in the network post >> bootstrap are not relevant to the BRSKI document. > To me the most important goal should be to provide candidate users wi= th > deployment guidance. This should fit ANIMA goals given how its an OPS > group. Chairs,=20 I think we should add a new document to our set. The title might be: Autonomic Networking in Disaster Recovery: preperation and operation This would be a very very very operational BCP. We won't finish this until after everything has been put to bed, but I think we should start it soonest, so that we can capture much of this discussion/concern. > a) keep spares unenrolled, enrol during desaster recovery with > satellite link b) enrol spare devices when they are stocked, deploy > during desaster. > lets assume we agree both are relevant deployment options that users > should understand, compare pro/cons for their case and choose. If you > think we can not mention both in the BRSKY spec, then i think it would > be better to have a separate document where both could be discussed. A reason why one would have unenrolled spares is because the spares are kept by the manufacturer in distributed warehouses, close to where they might be needed, or perhaps even, would be in a FEMA-like entities' warehouse, to be deployed to whichever operator needed them. The use of Autonomic mechanisms might result in normalization much of the configuration of some devices, so it wouldn't matter as much which vendor's device was deployed. Maybe this won't be for core BGP-happy BFRs, but it could be the case that less complicated things like 24 10/100/1000s switches would be in that category. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYKBARAAoJEJVM4Vb9/EKQNT4H+gLHMrLYtlWaqJ+e61THqPuZ 9Ms70yMrlgMMqr4+WZsKnPDYeVGC+tfAbbuELE7wvqhLqSlLx4PVran+WdHu1x3l LebQEIx6Dg/Ru5zqPPIFaLmT3bI045dC74LOPl/iboyRaQwW3R8JIB8kHYTuJ5es mCn6I0YSnlV/bucqPU3JlbPFlqo1fLjweScK/qFIxYs0repuKjtKbYFUJVpxh0of +srWyZNRconpQcuTQnZ7WOMhcNztBQ8rwEpTPIQfaN2oGEjHBo+wYaUMLz2+NsO9 0g21tln0q1Ab24L7Dz3f6kgWCxZQMWRZMTjofUcHl/5tbs10vr6APFHAMszN5/I= =mdhu -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 12 23:32:13 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFCC1296CF for ; Sat, 12 Nov 2016 23:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv8OQuPLx64c for ; Sat, 12 Nov 2016 23:32:11 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B7B1296CC for ; Sat, 12 Nov 2016 23:32:11 -0800 (PST) Received: from dooku.sandelman.ca (unknown [211.44.215.72]) by relay.sandelman.ca (Postfix) with ESMTPS id F0F7D1F906; Sun, 13 Nov 2016 07:32:06 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 922ED249E; Sun, 13 Nov 2016 02:31:10 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-reply-to: <760b75f2-c557-f702-61f1-3470bd8fe8ca@gmail.com> References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> <8498.1477165076@obiwan.sandelman.ca> <20161030235424.GA30878@faui40p.informatik.uni-erlangen.de> <9017.1478919099@dooku.sandelman.ca> <760b75f2-c557-f702-61f1-3470bd8fe8ca@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Sat, 12 Nov 2016 16:11:28 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32419.1479022270.1@dooku.sandelman.ca> Date: Sun, 13 Nov 2016 16:31:10 +0900 Message-ID: <32420.1479022270@dooku.sandelman.ca> Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 07:32:12 -0000 Brian E Carpenter wrote: >> However, I think that we will have to replace the GRASP query with >> something else, maybe just a CoAP request, as the TCP for GRASP is >> rather too much for some.. To be discussed. > I agree, GRASP is designed for autonomic nodes and I don't think we > should promote it for other usage at the moment. GRASP over CoAP would work, but still, it might not be right. From nobody Sun Nov 13 04:05:26 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A29129518 for ; Sun, 13 Nov 2016 04:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXHb5QUUEipZ for ; Sun, 13 Nov 2016 04:05:23 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C2112978B for ; Sun, 13 Nov 2016 04:05:23 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id AA1771F91A for ; Sun, 13 Nov 2016 12:05:21 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id DA5A73240; Sun, 13 Nov 2016 06:34:12 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-reply-to: <399b6388-5115-78c8-17d0-04fc1592dec4@gmail.com> References: <147793791802.23181.7413424443005063098.idtracker@ietfa.amsl.com> <9222.1478919260@dooku.sandelman.ca> <399b6388-5115-78c8-17d0-04fc1592dec4@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Sat, 12 Nov 2016 16:27:11 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 13 Nov 2016 20:34:12 +0900 Message-ID: <6037.1479036852@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 12:05:25 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> > this, the Anima solution will not be complete in itself. Especially >> > during the early formation of an AN after a cold start, this is a > >> problem. >>=20 >> Please define "cold start", here. > Power off on all racks; humans pressing factory reset buttons. Systems > coming back in random order. All dependencies broken. I think that we need to define "factory reset" in a document somewhere! Thanks to ANIMA and LDevID certificates, I think that there are two kinds of reset, but I'd like the WG to come to consensus. There is "reset to factory defaults", which I would take to make to erase all configuration files and all administrative credentials, and might even mean to boot a specific OS image. But, it wouldn't mean to remove the LDev= ID. An operator would do this when redeploying the equipment from one purpose to another. The second kind of "factor reset", would mean to delete the LDevID. Still, I'm skeptical that we'd ever want to do that; it might mean to boot using the IDevID. It might really mean, specifically, to run bootstrap aga= in without doing anything else. This is what a machine might do if it's LDevID certificate is expired. So, Max, Toerless, MichaelB, what are your thoughts here? And I agree with Brian that we need a pure ANIMA solution when we cold start a rack of equipment. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYKE+0AAoJEJVM4Vb9/EKQtiIH/RmV+Fitt7XWvOQzLPTfYJrp +aJoLG8bX9Mf21BTBBIB18U+Sgn00obIl/uiaJAk4voOe3nj+UxN76/UByX9K0gM F1hyFt+42jvR1TdA2O/uBw5rH0Js1/1orCiY7UkCblTMcXscrqE9N7GQHHUg0OLT gkXs6C+TEAfsNYSKhLNZNAvJGaQiS4IPgj+clniKifghpYtOXwpcxGdhrUYjZ5T+ rXq0RjnrziiSGYHcY5v8Eplqo5j6kkQrdcKupiKyVBrHAOrvumIv3/TSCvAVrl7x aOjsdVluUn5X+C+ru8VvtW01rLGXJjxAHi6JY+1lamJt8tfvKnNMRj18jxLMv+s= =O3H6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 13 11:04:27 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF47612958B for ; Sun, 13 Nov 2016 11:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 rua6647UZEnc for ; Sun, 13 Nov 2016 11:04:24 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5183B1294F4 for ; Sun, 13 Nov 2016 11:04:24 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id 3so44089114pgd.0 for ; Sun, 13 Nov 2016 11:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=aymerTFqOy9WnXxtOr8unGUi0ZE4u+2HJ/YkUb1D/sM=; b=v0Soxjsi7ir58Ab7vjDPWxvPwPPt7X1+Rq1S1d7B9tVhwtqZXbFi+qu8Ql+1yZcKOV Kb6KY8alUEFkDVG8+VN6y4q6OQ0sPmBGXINOboIvIapLsD3czE9Ma0Rvu24fuSLCyzVj Yj2nbmwgNv5KFgPtoATfyGSQpSYQ9mqUO5QxS7sGg8bzbTQDvHOLPwJQHdx7Rp8kFjFp vCw8/8jFeAbaS0+8u0g2Z/6OjFnkOUYi4lkBxpB1/LK336CusOWZmveNJHH+OOBtbqeh TF28zmzAifJUpuIsgb+kdvUYipPQiBBCxP6EqB7j+UnD3Q75a4y1GrfYr1g3ctWX2Nk0 TAHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=aymerTFqOy9WnXxtOr8unGUi0ZE4u+2HJ/YkUb1D/sM=; b=K+E1vXa7qUMuZ6SQVb8Ddo1WmZW+zmtn+g8Bd9WS2lnjz51gy6S59cuWSBbDINs2mP Aclz83iKjDrSmdpRsjbgXNXM5kzeIFkN00gCY6alDCidDlxPfouQCy8Xxl5GMdZ2FpV7 oMppyCL6eOsebfqGvDE9LjWKZEQyK4Q2+NIWXmDsgvEdDyNleuJIbTVa/PUWx8GbTv8R UITSWSZ0eO9eHd1fANZoTQ/no2c1ujcS5Zmiq/oSlp3PsHVGvdX4IFU3Yd5I1B7Ij5Dq TIorfKDQIjFE6siPC/H93FWv09Z6vIpnuwi6TPzDvVieR6/PXD/mxhdf/GIUPqB7m0v7 utGw== X-Gm-Message-State: ABUngvfUxn6TgzWSirKZq/2ks+Xl1/MbFtF6EctGIisJbeyKiW+tAdAuMFK7ytYQf7ry7A== X-Received: by 10.99.127.72 with SMTP id p8mr62785347pgn.183.1479063863691; Sun, 13 Nov 2016 11:04:23 -0800 (PST) Received: from [192.168.178.23] (169.221.47.163.dynamic.snap.net.nz. [163.47.221.169]) by smtp.gmail.com with ESMTPSA id r74sm29590309pfl.79.2016.11.13.11.04.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2016 11:04:23 -0800 (PST) To: Michael Richardson , Anima WG References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> <28804.1479020561@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 14 Nov 2016 08:04:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <28804.1479020561@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Desaster recover... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 19:04:26 -0000 On 13/11/2016 20:02, Michael Richardson wrote: > > Toerless Eckert wrote: > >> Devices that have been brought up and are in the network post > >> bootstrap are not relevant to the BRSKI document. > > > To me the most important goal should be to provide candidate users with > > deployment guidance. This should fit ANIMA goals given how its an OPS > > group. > > Chairs, > I think we should add a new document to our set. The title might be: > Autonomic Networking in Disaster Recovery: preperation and operation Yes. I don't know if rechartering is already on the agenda, because we still have several base documents that are overdue, but this makes a lot of sense for Anima Phase 2. Brian > > This would be a very very very operational BCP. > We won't finish this until after everything has been put to bed, but I think > we should start it soonest, so that we can capture much of this > discussion/concern. > > > a) keep spares unenrolled, enrol during desaster recovery with > > satellite link b) enrol spare devices when they are stocked, deploy > > during desaster. > > > lets assume we agree both are relevant deployment options that users > > should understand, compare pro/cons for their case and choose. If you > > think we can not mention both in the BRSKY spec, then i think it would > > be better to have a separate document where both could be discussed. > > A reason why one would have unenrolled spares is because the spares are kept > by the manufacturer in distributed warehouses, close to where they might be > needed, or perhaps even, would be in a FEMA-like entities' warehouse, to be > deployed to whichever operator needed them. > > The use of Autonomic mechanisms might result in normalization much of the > configuration of some devices, so it wouldn't matter as much which vendor's > device was deployed. Maybe this won't be for core BGP-happy BFRs, but it > could be the case that less complicated things like 24 10/100/1000s switches > would be in that category. > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Nov 13 11:05:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E181295B2 for ; Sun, 13 Nov 2016 11:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 dTENoUhSo6I7 for ; Sun, 13 Nov 2016 11:05:20 -0800 (PST) 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 C8EED1294F4 for ; Sun, 13 Nov 2016 11:05:20 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id p66so44037634pga.2 for ; Sun, 13 Nov 2016 11:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4sy/fdLRfm0gluccV2Z+ZYMBkZ0gd97OZcfM/a9XQ+o=; b=cHmWWMGiB5qHWbAtGRGT1IzTus1XeHn+d+sTBAnzLUNaEa2lC5s1aNv/tm4mBQ9lbu HNEsYI+v2zk3rAUErCdRvCL0kCygrpuW3Hh2j1hmmDnrDesYFrTfQGO31dC3vNurvfd8 EhtiiBEt0QjZzLRBVnjX7dOmsTWFUSLv7XknxeOGMbXN3jfde/8pbxu1WnMHCQdOcoUx jb3FxYXxxSRoEPg1WxvcF1h+wrMfiYx+/yb5BygDxxgxcyYjyI+SlBg46doBIABgHfD0 DHlso/gZ/vkx2FNESqem1TKa1cWWnUmAed56LxoVB34q7R0iA4JvHhkt2+nWhHNUjsGU GzXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4sy/fdLRfm0gluccV2Z+ZYMBkZ0gd97OZcfM/a9XQ+o=; b=EwzDa9fGKGsxrgk50PGNv56xZ5+33v+kqhM2wODX5MGfAce599+TXJk/tPX2JbINiK fFYx+60I7edVKgD0dMqdYSaUluHqHrWXmq8dFnVttiKJa6SWHuLZd48L6zgfnEaB4Xf2 4VlxCX5id/Yj0pAarcdlgaY1BfL4fN354sEy7ZjZfVi101JIYD1HYT+4SO+KC+DXOTIU SHTn1+9X6/URJOSXB2er8kT3mPh3V9eTxEriYcF2HUD1SBtLPIBgQQVqbYdlQ/J1MWWW 4Iw665FQkrOL3mR13ay0HjMpX57Mdx717J8PEQKJTo2g52BmhJuIKNgMjw4I6B7sueOE m1yQ== X-Gm-Message-State: ABUngverIgvIWYrh7RiYVfNiZ46TsXnSTQJEsJ7FvbLUy1INq0+QfkCP/wy/6ZOfFZrSRw== X-Received: by 10.98.94.7 with SMTP id s7mr28356374pfb.37.1479063920216; Sun, 13 Nov 2016 11:05:20 -0800 (PST) Received: from [192.168.178.23] (169.221.47.163.dynamic.snap.net.nz. [163.47.221.169]) by smtp.gmail.com with ESMTPSA id qy2sm29709348pab.27.2016.11.13.11.05.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2016 11:05:19 -0800 (PST) To: Michael Richardson References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> <8498.1477165076@obiwan.sandelman.ca> <20161030235424.GA30878@faui40p.informatik.uni-erlangen.de> <9017.1478919099@dooku.sandelman.ca> <760b75f2-c557-f702-61f1-3470bd8fe8ca@gmail.com> <32420.1479022270@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7347fb90-127c-9240-3e1c-ab4b24d6644f@gmail.com> Date: Mon, 14 Nov 2016 08:05:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <32420.1479022270@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 19:05:22 -0000 On 13/11/2016 20:31, Michael Richardson wrote: > Brian E Carpenter wrote: > >> However, I think that we will have to replace the GRASP query with > >> something else, maybe just a CoAP request, as the TCP for GRASP is > >> rather too much for some.. To be discussed. > > > I agree, GRASP is designed for autonomic nodes and I don't think we > > should promote it for other usage at the moment. > > GRASP over CoAP would work, but still, it might not be right. > Exactly, so let's get the basic work finished first. Brian From nobody Mon Nov 14 18:30:30 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10A91296B2 for ; Mon, 14 Nov 2016 18:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 H-vqqJn2obnM for ; Mon, 14 Nov 2016 18:30:25 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AABD1296D2 for ; Mon, 14 Nov 2016 18:30:24 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id uAF2UM70018831 for ; Tue, 15 Nov 2016 11:30:22 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw1.nict.go.jp with ESMTP id uAF2UMoD018771 for ; Tue, 15 Nov 2016 11:30:22 +0900 (JST) Received: from spectre (ssh1.nict.go.jp [133.243.3.49]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id DEA2B84E1 for ; Tue, 15 Nov 2016 11:30:21 +0900 (JST) Date: Tue, 15 Nov 2016 11:30:20 +0900 From: Pedro Martinez-Julia To: anima@ietf.org Message-ID: <20161115023011.GA9840@spectre> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Subject: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:30:28 -0000 Dear WG members, According to the presentation in the NMRG session, the ANIMA model relies in a registry which seems to be centralized. I think it does not suit autonomicity as well as a distributed registry would, so different definition and implementation strategies can appear in the future. In order to be a widely accepted model, which I think would be really useful, ANImA should support different kinds of registries. Please let me know if you have plans to consider it. Thank you. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Mon Nov 14 18:40:48 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E30F1299F8 for ; Mon, 14 Nov 2016 18:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 wRSHZFASRXhj for ; Mon, 14 Nov 2016 18:40:42 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6BB1299F0 for ; Mon, 14 Nov 2016 18:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2441; q=dns/txt; s=iport; t=1479177640; x=1480387240; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xa2dAmEzV2/NxnzPPdRVVD6RY4cn+2JKki4z2kFQRfo=; b=dV98VQPXRUUoTkHXWDM+N3cZZks/n3exC0oytXNGNpH/06QfTqyFrarU VsHE4N1fnhbkuQp2FowQb5LeRzYJimQhfCkwyvIvkggvJyQnC0I1PoKbP MSlYeojW1R7Cwm9zO8BOyk7MnQEXmqiQ1vyHSYKxfe7cofDvGDP+icMtX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAwBWdSpY/5hdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzEBAQEBAR9YgQAHpEGUX4IHHQuFewKCJ0ESAQIBAQEBAQEBYiiEYQE?= =?us-ascii?q?BAQMBAQEBNzQXBAIBCBEEAQEfCQcnCxQJCAIEARIIE4g+CA6yMotYAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBFwWGPIRahBoRAYV9BYhQkXEBiUmHDIF2hHaJO41EhAk?= =?us-ascii?q?BJQUrWikchRpyhRGBIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,640,1473120000"; d="scan'208";a="348407328" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2016 02:40:39 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAF2ed1c030527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Nov 2016 02:40:39 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 20:40:38 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Mon, 14 Nov 2016 20:40:38 -0600 From: "Michael Behringer (mbehring)" To: Pedro Martinez-Julia , "anima@ietf.org" Thread-Topic: [Anima] Autonomic Registry Thread-Index: AQHSPuhO+KqmkKRFAE6LxSIxqenEqaDZU3yQ Date: Tue, 15 Nov 2016 02:40:38 +0000 Message-ID: <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> References: <20161115023011.GA9840@spectre> In-Reply-To: <20161115023011.GA9840@spectre> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.234.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:40:43 -0000 Hi Pedro,=20 Thanks for your feedback and follow-up! Appreciated! Inline... > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Pedro Martinez- > Julia > Sent: 15 November 2016 11:30 > To: anima@ietf.org > Subject: [Anima] Autonomic Registry >=20 > Dear WG members, >=20 > According to the presentation in the NMRG session, the ANIMA model relies > in a registry which seems to be centralized. I think it does not suit > autonomicity as well as a distributed registry would, so different defini= tion > and implementation strategies can appear in the future. In order to be a > widely accepted model, which I think would be really useful, ANImA should > support different kinds of registries. Please let me know if you have pla= ns to > consider it. Thank you. Generically, ANIMA devices get a domain certificate. Today, practically all= certificate management solutions are centralised, with a central CA, and s= everal RAs (Registration Authorities). So for now this is the working model= . And a registrar is logically an RA in this model. Given that certificate = interactions are infrequent, and given that this PKI model is very well dev= eloped, I think this is a reasonable starting point.=20 We have had suggestions to look at peer to peer trust models, and I agree t= hat philosophically this would be even better. However, such models are not= widely used today. My personal opinion is that we could well support a dif= ferent enrolment procedure, using a peer-to-peer trust model in the future;= the ANIMA reference model is generic and modular enough.=20 But my priority is to get the current solution, using standard PKI methods = off the ground before going there.=20 Do you have a concrete proposal? Would be interesting to discuss.=20 Michael >=20 > Regards, > Pedro >=20 > -- > Pedro Martinez-Julia > Network Science and Convergence Device Technology Laboratory Network > System Research Institute National Institute of Information and > Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo > 184-8795, Japan > Email: pedro@nict.go.jp > --------------------------------------------------------- > *** Entia non sunt multiplicanda praeter necessitatem *** >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Nov 14 18:51:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC411299F0 for ; Mon, 14 Nov 2016 18:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, 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 8F3nGai8H88k for ; Mon, 14 Nov 2016 18:51:01 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 27EB11294F7 for ; Mon, 14 Nov 2016 18:51:01 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A489B9689F97B; Tue, 15 Nov 2016 02:50:58 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAF2owv8013508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 02:50:59 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAF2owu7030613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 03:50:58 +0100 Received: from [135.224.211.170] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 15 Nov 2016 03:50:57 +0100 To: "Michael Behringer (mbehring)" , Pedro Martinez-Julia , "anima@ietf.org" References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: <7202d5ff-7aa6-bc75-72a3-64a450c505f5@nokia-bell-labs.com> Date: Tue, 15 Nov 2016 03:50:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> Content-Type: multipart/alternative; boundary="------------5644F22970392357EC09C202" X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:51:04 -0000 --------------5644F22970392357EC09C202 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello, Without the will to throw buzzwords to the list, but there are works on block-chain that may be relevant to consider. Best regards, Laurent. On 15/11/2016 03:40, Michael Behringer (mbehring) wrote: > Hi Pedro, > > Thanks for your feedback and follow-up! Appreciated! Inline... > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Pedro Martinez- >> Julia >> Sent: 15 November 2016 11:30 >> To: anima@ietf.org >> Subject: [Anima] Autonomic Registry >> >> Dear WG members, >> >> According to the presentation in the NMRG session, the ANIMA model relies >> in a registry which seems to be centralized. I think it does not suit >> autonomicity as well as a distributed registry would, so different definition >> and implementation strategies can appear in the future. In order to be a >> widely accepted model, which I think would be really useful, ANImA should >> support different kinds of registries. Please let me know if you have plans to >> consider it. Thank you. > Generically, ANIMA devices get a domain certificate. Today, practically all certificate management solutions are centralised, with a central CA, and several RAs (Registration Authorities). So for now this is the working model. And a registrar is logically an RA in this model. Given that certificate interactions are infrequent, and given that this PKI model is very well developed, I think this is a reasonable starting point. > > We have had suggestions to look at peer to peer trust models, and I agree that philosophically this would be even better. However, such models are not widely used today. My personal opinion is that we could well support a different enrolment procedure, using a peer-to-peer trust model in the future; the ANIMA reference model is generic and modular enough. > > But my priority is to get the current solution, using standard PKI methods off the ground before going there. > > Do you have a concrete proposal? Would be interesting to discuss. > > Michael > > >> Regards, >> Pedro >> >> -- >> Pedro Martinez-Julia >> Network Science and Convergence Device Technology Laboratory Network >> System Research Institute National Institute of Information and >> Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo >> 184-8795, Japan >> Email: pedro@nict.go.jp >> --------------------------------------------------------- >> *** Entia non sunt multiplicanda praeter necessitatem *** >> >> _______________________________________________ >> 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 > -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------5644F22970392357EC09C202 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello,

Without the will to throw buzzwords to the list, but there are works on block-chain that may be relevant to consider.

Best regards, Laurent.

On 15/11/2016 03:40, Michael Behringer (mbehring) wrote:
Hi Pedro, 

Thanks for your feedback and follow-up! Appreciated! Inline...


-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Pedro Martinez-
Julia
Sent: 15 November 2016 11:30
To: anima@ietf.org
Subject: [Anima] Autonomic Registry

Dear WG members,

According to the presentation in the NMRG session, the ANIMA model relies
in a registry which seems to be centralized. I think it does not suit
autonomicity as well as a distributed registry would, so different definition
and implementation strategies can appear in the future. In order to be a
widely accepted model, which I think would be really useful, ANImA should
support different kinds of registries. Please let me know if you have plans to
consider it. Thank you.

Generically, ANIMA devices get a domain certificate. Today, practically all certificate management solutions are centralised, with a central CA, and several RAs (Registration Authorities). So for now this is the working model. And a registrar is logically an RA in this model. Given that certificate interactions are infrequent, and given that this PKI model is very well developed, I think this is a reasonable starting point. 

We have had suggestions to look at peer to peer trust models, and I agree that philosophically this would be even better. However, such models are not widely used today. My personal opinion is that we could well support a different enrolment procedure, using a peer-to-peer trust model in the future; the ANIMA reference model is generic and modular enough. 

But my priority is to get the current solution, using standard PKI methods off the ground before going there. 

Do you have a concrete proposal? Would be interesting to discuss. 

Michael



Regards,
Pedro

--
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory Network
System Research Institute National Institute of Information and
Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo
184-8795, Japan
Email: pedro@nict.go.jp
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

_______________________________________________
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

--

Laurent Ciavaglia

Nokia, Bell Labs

 

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

--------------5644F22970392357EC09C202-- From nobody Mon Nov 14 18:53:15 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D8B1299B6 for ; Mon, 14 Nov 2016 18:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 yqa-ybL-Fkth for ; Mon, 14 Nov 2016 18:53:12 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE1A12968C for ; Mon, 14 Nov 2016 18:53:11 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id uAF2rAf4069130 for ; Tue, 15 Nov 2016 11:53:10 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw1.nict.go.jp with ESMTP id uAF2rAB7069127 for ; Tue, 15 Nov 2016 11:53:10 +0900 (JST) Received: from spectre (ssh1.nict.go.jp [133.243.3.49]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 5E0B888E5 for ; Tue, 15 Nov 2016 11:53:10 +0900 (JST) Date: Tue, 15 Nov 2016 11:53:09 +0900 From: Pedro Martinez-Julia To: anima@ietf.org Message-ID: <20161115025300.GB9840@spectre> References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:53:14 -0000 On Tue, Nov 15, 2016 at 02:40:38AM +0000, Michael Behringer (mbehring) wrote: > Hi Pedro, Hi, > Generically, ANIMA devices get a domain certificate. Today, > practically all certificate management solutions are centralised, with > a central CA, and several RAs (Registration Authorities). So for now > this is the working model. And a registrar is logically an RA in this > model. Given that certificate interactions are infrequent, and given > that this PKI model is very well developed, I think this is a > reasonable starting point. Yes it is, but being a "model" not a "solution" I think it could consider different schemes. > We have had suggestions to look at peer to peer trust models, and I > agree that philosophically this would be even better. However, such > models are not widely used today. My personal opinion is that we could > well support a different enrolment procedure, using a peer-to-peer > trust model in the future; the ANIMA reference model is generic and > modular enough. > > But my priority is to get the current solution, using standard PKI > methods off the ground before going there. > > Do you have a concrete proposal? Would be interesting to discuss. Not for the moment, but in my team we are working in some models that would benefit from centralized and distributed registration procedures, depending on the specific scenario. For instance, disaster recovery scenarios require to establish network systems (virtual and physical) that should be autonomic and disconnected from any previously centralized infrastructure. This could be reflected in the unattended deployment of drones to provide connectivity to places where infrastructure has been broken. In this situation, both security and interoperability should be ensured without requiring the system to contact a centralized registry. I hope this gives some perspective to my concerns. In summary I only encourage the consideration of abstract mechanisms to cover any point that can have polarized schemes (centralized vs distributed). > Michael Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Mon Nov 14 19:02:35 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1010A1296BE for ; Mon, 14 Nov 2016 19:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 SU_O7v8VuxqZ for ; Mon, 14 Nov 2016 19:02:32 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82012968C for ; Mon, 14 Nov 2016 19:02:31 -0800 (PST) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id uAF32UHs059995 for ; Tue, 15 Nov 2016 12:02:30 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw2.nict.go.jp with ESMTP id uAF32UEY059991 for ; Tue, 15 Nov 2016 12:02:30 +0900 (JST) Received: from spectre (ssh1.nict.go.jp [133.243.3.49]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 058E18A54 for ; Tue, 15 Nov 2016 12:02:29 +0900 (JST) Date: Tue, 15 Nov 2016 12:02:29 +0900 From: Pedro Martinez-Julia To: anima@ietf.org Message-ID: <20161115030109.GA8504@spectre> References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> <7202d5ff-7aa6-bc75-72a3-64a450c505f5@nokia-bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7202d5ff-7aa6-bc75-72a3-64a450c505f5@nokia-bell-labs.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 03:02:33 -0000 On Tue, Nov 15, 2016 at 03:50:51AM +0100, Laurent Ciavaglia wrote: > Hello, Hi, > Without the will to throw buzzwords to the list, but there are works on > block-chain that may be relevant to consider. IMHO, the block-chain mechanisms fits well with autonomic control and management. I will try to follow such works. If you have some pointers to those works, I mean ANIMA+block-chain, please share them. Thank you. > Best regards, Laurent. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Mon Nov 14 19:23:13 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046F012956E for ; Mon, 14 Nov 2016 19:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 CNOD2xZSFF_g for ; Mon, 14 Nov 2016 19:23:10 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B0D129558 for ; Mon, 14 Nov 2016 19:23:10 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id p66so61282472pga.2 for ; Mon, 14 Nov 2016 19:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=z9UKrQlUrEN8aOCVERmoo7FsAoZSyRWoyXdv2FgBIY4=; b=GpHh1LqtGLo5kkBuGcHHaG63uNjSbKp+Y2XfNyeQL2zRVNEejof3pbFvp1T8yFxwXG rWsIZYRqsAb/NfikYJBJwnHjLp3sbkRtt9sg1abMezdzR0lqeh4wHFT4GQZ29ejeL2d2 3VV5U97zwlNWcTfQ2Jt+zqTRGN2wIVmu7D5TzKPYblmPtwUakatBC361SNnuTbmAPqJW Yatd/+Fw93Eu50iZQsqtjVr2IR7he1uhcKk5g5833xgcxtDZOQzox5iz9l7PAK8aJR+u ie3eiMX915G7tOEuGLGkMxSc029r+I7welhVoL5vnDvQlgW3LLAtq8veWwFcpZKANOVg Pt8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=z9UKrQlUrEN8aOCVERmoo7FsAoZSyRWoyXdv2FgBIY4=; b=kc1xnpJ0wm6tYTrObxyET9s28q6XNNbRLpnev5aVqejc21cOTuBYfU8H9VpIUdj3hh sjg/WbilHyZLcSBEFjJX/09vQdmdfNDnxWOv6JTneisgwsGJWyiWmac9ZoKhodCCxnHb VzS3Y3+l+92vnnkaYQdNkIfjCZJMVsBW0AkPor2bH9MW0/ZBGMsHkSwLMtjbWWzFi/BI 0KEjQ3WaXsKs/QAJvFCP2kPjUDR6ZrNrJcvZQSogbk2mIuwmnZnJtcteykSyI5ihLvr0 qo5GFFtPqoRNFGANLOsA1AhyAX30AEy8sZW6t4eBYC674mrppUmr+3bwrFerYeAmVBNl 0JZQ== X-Gm-Message-State: ABUngvd07Hv2v6XTh3428PSyUHG+pa3USaRMP8F3Y3KWYPjwSCDaIYqiopMr6IiFW60LWA== X-Received: by 10.99.181.86 with SMTP id u22mr34215118pgo.24.1479180190127; Mon, 14 Nov 2016 19:23:10 -0800 (PST) Received: from ?IPv6:2406:e007:4874:1:28cc:dc4c:9703:6781? ([2406:e007:4874:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id xi6sm25658764pab.5.2016.11.14.19.23.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 19:23:09 -0800 (PST) To: Pedro Martinez-Julia , anima@ietf.org References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> <20161115025300.GB9840@spectre> From: Brian E Carpenter Organization: University of Auckland Message-ID: <506ceafe-ab37-7b54-1ec5-222bbb44c6d7@gmail.com> Date: Tue, 15 Nov 2016 16:23:08 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161115025300.GB9840@spectre> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 03:23:12 -0000 Pedro, > For instance, disaster recovery scenarios require to establish network > systems (virtual and physical) that should be autonomic and disconnected > from any previously centralized infrastructure. Yes, we have already understood this problem, but there's a trade-off between this and security - you want to come up quickly, and you want to come up securely to prevent evil-doers. (You may have read that less than two days ago, numerous homes in Christchurch NZ were burgled during a tsunami evacuation. Similarly, I don't think it's safe to assume that there will be no cyber attackers in a disaster area.) If the drone has even a slow link back to the Internet, that should be sufficient for an autonomic domain to bootstrap securely. Although we expect things to work with only one registrar per domain, that is a software function. We can imagine that after a disaster this function will start up somewhere, but not in its normal host. Of course, more work is needed. Regards Brian Carpenter On 15/11/2016 15:53, Pedro Martinez-Julia wrote: > On Tue, Nov 15, 2016 at 02:40:38AM +0000, Michael Behringer (mbehring) wrote: >> Hi Pedro, > > Hi, > >> Generically, ANIMA devices get a domain certificate. Today, >> practically all certificate management solutions are centralised, with >> a central CA, and several RAs (Registration Authorities). So for now >> this is the working model. And a registrar is logically an RA in this >> model. Given that certificate interactions are infrequent, and given >> that this PKI model is very well developed, I think this is a >> reasonable starting point. > > Yes it is, but being a "model" not a "solution" I think it could > consider different schemes. > >> We have had suggestions to look at peer to peer trust models, and I >> agree that philosophically this would be even better. However, such >> models are not widely used today. My personal opinion is that we could >> well support a different enrolment procedure, using a peer-to-peer >> trust model in the future; the ANIMA reference model is generic and >> modular enough. >> >> But my priority is to get the current solution, using standard PKI >> methods off the ground before going there. >> >> Do you have a concrete proposal? Would be interesting to discuss. > > Not for the moment, but in my team we are working in some models that > would benefit from centralized and distributed registration procedures, > depending on the specific scenario. > > For instance, disaster recovery scenarios require to establish network > systems (virtual and physical) that should be autonomic and disconnected > from any previously centralized infrastructure. This could be reflected > in the unattended deployment of drones to provide connectivity to places > where infrastructure has been broken. In this situation, both security > and interoperability should be ensured without requiring the system to > contact a centralized registry. > > I hope this gives some perspective to my concerns. In summary I only > encourage the consideration of abstract mechanisms to cover any point > that can have polarized schemes (centralized vs distributed). > >> Michael > > Regards, > Pedro > From nobody Mon Nov 14 19:44:42 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E791296BB for ; Mon, 14 Nov 2016 19:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwd2FHucAnDe for ; Mon, 14 Nov 2016 19:44:35 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0973B1296B6 for ; Mon, 14 Nov 2016 19:44:35 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-8d96.meeting.ietf.org [31.133.141.150]) by relay.sandelman.ca (Postfix) with ESMTPS id 98E091F8EE; Tue, 15 Nov 2016 03:44:33 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7E53D249E; Mon, 14 Nov 2016 22:44:01 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-reply-to: <6c10eee2-651c-66dc-f222-a5a07a470960@gmail.com> References: <03d8d4c491e6452d90fdbdc254f68ce8@XCH-RCD-006.cisco.com> <6c10eee2-651c-66dc-f222-a5a07a470960@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Fri, 11 Nov 2016 08:27:57 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 15 Nov 2016 12:44:01 +0900 Message-ID: <20268.1479181441@dooku.sandelman.ca> Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] ANIMA state machines, take two X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 03:44:40 -0000 --=-=-= Content-Type: text/plain {pushing send on an email in process for some days} Brian E Carpenter wrote: > I like this. I have a few comments on some of your open questions: >> Discovery: mDNS or GRASP? > I feel very strongly that we need the ANI to be as self-contained as > possible. Therefore, it must be possible for the ANI to create itself > without depending on mDNS. Therefore, we must use GRASP discovery (or > flooding, if we prefer an announcement method) for AN nodes. I agree that enrolled AN nodes MUST use GRASP for discovery, and I think that M_FLOOD is the way to create the neighbour table for that. >> one discovery method for BRSKI and ACP, or several? > Non-ANI nodes can also use BRSKI. So to say this one more time, since I > won't be in Seoul: BRSKI proxies MUST be discoverable by both mDNS and > GRASP. I am warming to use of M_FLOOD for this, whereby the Join Assistant announces itself. >> multicast domain info? >> packet formats > For the discovery methods, that is already settled by mDNS and GRASP, > isn't it? For BRSKI itself and ACP formation, the formats belong in the > BRSKI and ACP drafts. Agreed, I don't think that there are any open questions here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYKoSBAAoJEJVM4Vb9/EKQUNsH/3i5kMPo+RUfZJlfyKvvVGMq V5b+SbLDXTOVLTYs6V0PFfDrYX17V44qNxW2VF5HmvQyJk86rxsTDHowQmhtytnU APfz5XnMNZ3P+yHES95AL2f4EkiO9KJBTh2Ps7YcMl79P7EI04CvBe2nwxPcLRdt AlJuOgkF+VVJdmJmdKSVdVu2fFpBkkNrRkUQ5Qd/yX0hsztzGs2WQsfMLv6trta+ Fhq+4xXzxQVdbsH4rkFjbTzkaqg/159Qx27PiaPEYZyw1HxasoOal8MJiC6Xmlbh UDVv0FuITf6sxP4d2xDl4gYnEY83UEIvWa0DyJEZx8JqfieECXtWhYNgmzcw0XM= =v1yu -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 14 20:44:47 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABC9129473 for ; Mon, 14 Nov 2016 20:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cDzE66p_MAN for ; Mon, 14 Nov 2016 20:44:44 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017E9129501 for ; Mon, 14 Nov 2016 20:44:44 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-8d96.meeting.ietf.org [31.133.141.150]) by relay.sandelman.ca (Postfix) with ESMTPS id E22591F8EE; Tue, 15 Nov 2016 04:44:41 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 94B86249E; Mon, 14 Nov 2016 23:44:38 -0500 (EST) From: Michael Richardson To: "anima\@ietf.org" In-reply-to: <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> Comments: In-reply-to "Michael Behringer (mbehring)" message dated "Tue, 15 Nov 2016 02:40:38 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 15 Nov 2016 13:44:38 +0900 Message-ID: <26805.1479185078@dooku.sandelman.ca> Archived-At: Cc: Pedro Martinez-Julia Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 04:44:46 -0000 --=-=-= Content-Type: text/plain see inline Pedro Martinez-Julia writes: >> To: anima@ietf.org >> Subject: [Anima] Autonomic Registry >> >> Dear WG members, >> >> According to the presentation in the NMRG session, the ANIMA model relies >> in a registry which seems to be centralized. I think it does not suit You are using the word "registry", but it's a registrar. The different in the word is perhaps subtle, but very significant. >> autonomicity as well as a distributed registry would, so different definition >> and implementation strategies can appear in the future. In order to be a >> widely accepted model, which I think would be really useful, ANImA should >> support different kinds of registries. Please let me know if you have plans to >> consider it. Thank you. Michael Behringer (mbehring) wrote: > Generically, ANIMA devices get a domain certificate. Today, practically > all certificate management solutions are centralised, with a central > CA, and several RAs (Registration Authorities). So for now this is the > working model. And a registrar is logically an RA in this model. Given > that certificate interactions are infrequent, and given that this PKI > model is very well developed, I think this is a reasonable starting > point. And, the centralized nature of current PKI implementations is an implementation limitation, not an architectural limitation. The architecture supports talking the nearest registrar which is functioning. There are PKI implementation challenges with partitioning of the PKIX SerialNumber space (which must be unique), but it's a solved problem. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYKpK2AAoJEJVM4Vb9/EKQPHwH/R9ZidSP2deEn8t7A+H+lwYM iN767iJ4Qj/+5akYQesKESAuPVQpbtX1r68/cspVcIO/bohUNxebsWQvcE50hdpy 8NugZcmpus1FgQMSAVKjN+ypIgtTaWDJlDK/tJ2cuvDsvp4XUiSp/Cz05E846SCa IoQRxnsVllCRsvhimgW3rizphmolxF6MgpwPVHJ4hhUb/n2xuFxoYaJk5B5N8DEG NGtnuI/tjiheXjgV17rCGmu01AMCB2LgzH9inwbR8h3TbS94VUjKBk0BehRa8A9m C3rH5knGYCZFtt9y1drNJJiZTyGheUZGUFMNkyN1GTn1MZyf2QREunIW8CJQK8E= =iBPm -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 14 20:54:31 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1633129645 for ; Mon, 14 Nov 2016 20:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 Lkk5D8uksl2r for ; Mon, 14 Nov 2016 20:54:26 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4527A1295A0 for ; Mon, 14 Nov 2016 20:54:26 -0800 (PST) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id uAF4sOKV095829 for ; Tue, 15 Nov 2016 13:54:24 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw2.nict.go.jp with ESMTP id uAF4sOS7095822 for ; Tue, 15 Nov 2016 13:54:24 +0900 (JST) Received: from spectre (ssh1.nict.go.jp [133.243.3.49]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 08317865D for ; Tue, 15 Nov 2016 13:54:23 +0900 (JST) Date: Tue, 15 Nov 2016 13:54:23 +0900 From: Pedro Martinez-Julia To: anima@ietf.org Message-ID: <20161115045417.GA8996@spectre> References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> <20161115025300.GB9840@spectre> <506ceafe-ab37-7b54-1ec5-222bbb44c6d7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <506ceafe-ab37-7b54-1ec5-222bbb44c6d7@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 04:54:29 -0000 On Tue, Nov 15, 2016 at 04:23:08PM +1300, Brian E Carpenter wrote: > Pedro, Hi, > > For instance, disaster recovery scenarios require to establish > > network systems (virtual and physical) that should be autonomic and > > disconnected from any previously centralized infrastructure. > > Yes, we have already understood this problem, but there's a trade-off > between this and security - you want to come up quickly, and you want > to come up securely to prevent evil-doers. (You may have read that > less than two days ago, numerous homes in Christchurch NZ were burgled > during a tsunami evacuation. Similarly, I don't think it's safe to > assume that there will be no cyber attackers in a disaster area.) > > If the drone has even a slow link back to the Internet, that should be > sufficient for an autonomic domain to bootstrap securely. Although we > expect things to work with only one registrar per domain, that is a > software function. We can imagine that after a disaster this function > will start up somewhere, but not in its normal host. Of course, more > work is needed. Of course security is a big issue and its good to push it in the ANIMA model. However, my point is that there could be different mechanisms that can be used for the task without such link and providing the required security level (such as the previous reference to a block-chain based mechanism). Domains in emergency scenarios are well structured but very dynamic, due to the different situations they have to overcome. They can start with a centralized registrar entity but at some point new devices would need to form part of the domain without reaching the centralized registrar. They can rely a distributed mechanism that allows them to interact with other elements of the domain without reaching the registrar. Anyway, my point is that the registrar definition within the ANIMA model should be abstracted/generalized to support centralized, distributed, or even mixed approaches. Would it be possible within its current scope? > Regards > Brian Carpenter Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Mon Nov 14 20:54:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2BA1298CA for ; Mon, 14 Nov 2016 20:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTPGpm0l-J-f for ; Mon, 14 Nov 2016 20:54:47 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93064129645 for ; Mon, 14 Nov 2016 20:54:46 -0800 (PST) Received: from dooku.sandelman.ca (s2001067c037001280a1196fffe0181e0.v6.meeting.ietf.org [IPv6:2001:67c:370:128:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 2E8891F8EE for ; Tue, 15 Nov 2016 04:54:45 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id AE2FF1937; Mon, 14 Nov 2016 23:54:32 -0500 (EST) From: Michael Richardson To: "anima\@ietf.org" In-reply-to: <7202d5ff-7aa6-bc75-72a3-64a450c505f5@nokia-bell-labs.com> References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> <7202d5ff-7aa6-bc75-72a3-64a450c505f5@nokia-bell-labs.com> Comments: In-reply-to Laurent Ciavaglia message dated "Tue, 15 Nov 2016 03:50:51 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 15 Nov 2016 13:54:32 +0900 Message-ID: <27535.1479185672@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 04:54:48 -0000 --=-=-= Content-Type: text/plain Laurent Ciavaglia wrote: > Without the will to throw buzzwords to the list, but there are works on > block-chain that may be relevant to I can see no way that block-chain mechanisms help with the bootstrap process. They might help in the supplier chain process that delivers an ownership voucher to the Registrar, but that's not in scope for the WG at this time. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYKpUIAAoJEJVM4Vb9/EKQP/8H/2JBR875lOU45jQKH/yRIGBQ SgpUBqZZPbz+M7BUC8LNFPlWIeeCIiM2fL+7NW2oKG/cVO9R8XgYrUjTGnXqi9Ww /RaO1NMLdLXo+OJpKQANBHHcRag4bXKzL9mvkuaSDwjJGkuzzGzOr08RK7FzZqbc ZBlTZduogf6wrkg3GfB4eEH9ZMJQYSUtRQjTbvV7+/XgD0u9R+wbDW+9Y4tHo23A rH4IyuXFM4Vf65kPnKmaWVecmMY6VGR7rYJ/rbyxz+Sw8Zp+nFSlO/SC2AIemcf+ oIztRatUI3SSR1fTXYiUkQZ29e4oxjhMYLlDpfM0yJJYWBxSSL+3rBx13s2d2qA= =Ar+6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 14 21:05:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9A129A09 for ; Mon, 14 Nov 2016 21:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 7mK3ll7k1RuS for ; Mon, 14 Nov 2016 21:05:23 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 53F391298CA for ; Mon, 14 Nov 2016 21:05:23 -0800 (PST) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id uAF55MLO060889 for ; Tue, 15 Nov 2016 14:05:22 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw2.nict.go.jp with ESMTP id uAF55MvC060827 for ; Tue, 15 Nov 2016 14:05:22 +0900 (JST) Received: from spectre (ssh1.nict.go.jp [133.243.3.49]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 44DC387E1 for ; Tue, 15 Nov 2016 14:05:22 +0900 (JST) Date: Tue, 15 Nov 2016 14:05:21 +0900 From: Pedro Martinez-Julia To: anima@ietf.org Message-ID: <20161115050521.GA2948@spectre> References: <20161115023011.GA9840@spectre> <244bf7849e094de0b80e419e73f0a287@XCH-RCD-006.cisco.com> <26805.1479185078@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <26805.1479185078@dooku.sandelman.ca> User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Subject: Re: [Anima] Autonomic Registry X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 05:05:24 -0000 On Tue, Nov 15, 2016 at 01:44:38PM +0900, Michael Richardson wrote: > You are using the word "registry", but it's a registrar. The > different in the word is perhaps subtle, but very significant. Yes, it is and I'm sorry for mixing the terminology. However, either of them should be better distributed to achieve a good level of autonomic networking. > And, the centralized nature of current PKI implementations is an > implementation limitation, not an architectural limitation. > > The architecture supports talking the nearest registrar which is > functioning. There are PKI implementation challenges with > partitioning of the PKIX SerialNumber space (which must be unique), > but it's a solved problem. This is a good point, and considering this with some constraints imposed to the implementation, it could conform a proper mechanism even for the highly dynamic scenarios (as the disaster scenario I mentioned before). Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Tue Nov 15 05:39:54 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8FC1294C0 for ; Tue, 15 Nov 2016 05:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 I736v7RDeORM for ; Tue, 15 Nov 2016 05:39:52 -0800 (PST) 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 C35C812949B for ; Tue, 15 Nov 2016 05:39:51 -0800 (PST) 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 CVF11253; Tue, 15 Nov 2016 13:39:49 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Nov 2016 13:39:42 +0000 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; Tue, 15 Nov 2016 21:39:38 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Agenda and material links Thread-Index: AdI/RZirKih0zEZqQsewsMDRywqRbQ== Date: Tue, 15 Nov 2016 13:39:37 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC60791@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.112.113] 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.0A090204.582B1026.005D, 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: 94733a5a75f918e23c943215d96fca3c Archived-At: Subject: [Anima] Agenda and material links X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 13:39:53 -0000 Hi, ANIMA,=0A= =0A= Due to the new proceeding tools, we do not have agenda showed in tools.ietf= .org. Please use the below link to access the agenda. Also, the main materi= al page fails to show the material for our second session. Please use the s= econd URL to access all materials.=0A= =0A= https://datatracker.ietf.org/meeting/97/session/anima=0A= =0A= Best regards,=0A= =0A= Sheng= From nobody Tue Nov 15 21:29:27 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEDE129467; Tue, 15 Nov 2016 21:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKYhwVmqiyF5; Tue, 15 Nov 2016 21:29:13 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8368712950E; Tue, 15 Nov 2016 21:29:12 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-8d96.meeting.ietf.org [31.133.141.150]) by relay.sandelman.ca (Postfix) with ESMTPS id 2886B1F8F0; Wed, 16 Nov 2016 05:29:11 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 91FC7321A; Wed, 16 Nov 2016 00:29:08 -0500 (EST) From: Michael Richardson To: anima@ietf.org, netconf@ietf.org In-reply-to: <5D36713D8A4E7348A7E10DF7437A4B927CC61212@NKGEML515-MBX.china.huawei.com> References: <48BBDF02-F7C3-426D-901F-699A6D9643DF@juniper.net> <5D36713D8A4E7348A7E10DF7437A4B927CC61100@NKGEML515-MBX.china.huawei.com> <20161115232222.GO9776@faui40p.informatik.uni-erlangen.de> <2A2BAEFB-8F9A-404F-BFAD-805EB7DFC947@juniper.net>, <20161116001700.GS9776@faui40p.informatik.uni-erlangen.de> <5D36713D8A4E7348A7E10DF7437A4B927CC61212@NKGEML515-MBX.china.huawei.com> Comments: In-reply-to Sheng Jiang message dated "Wed, 16 Nov 2016 00:22:43 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 16 Nov 2016 14:29:08 +0900 Message-ID: <2023.1479274148@dooku.sandelman.ca> Archived-At: Cc: Benoit Claise , Terry Manderson Subject: Re: [Anima] voucher presentation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 16 Nov 2016 05:29:26 -0000 --=-=-= Content-Type: text/plain Sheng, I think we need some time in the next session to discuss where we are going to with draft-kwatsen-netconf-voucher, unless we can resolve this by email. We had said that we thought it was all up to Benoit, since he was the AD for both groups, but I just looked up and noticed that ANIMA is being handled by Terry, not Benoit :-) This document will also be used by 6tisch, btw. None of the authors care where the work is done; each of the groups would have to do the work themselves if it didn't happen elsewhere. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYK+6kAAoJEJVM4Vb9/EKQnZ0H/iMGV8UqQUrbe/NyJwUPkOZ5 x9O7hPEUK7sE1ZkQmzJoJ0mpWULpSsZMxCCB//lJ/CRSQfHi2BmsKbkYLVDYHM3Y HX8Dfi7ZhiGUbSEXAdUCpcuqHdf1Yjdu+jHUqaG4D7jiYChGKg8dtPKJvodK+xiF vNPkiUHttamcP+nNo7IMEWKytzieo9/JUTsQFqMFJqUsVpYJVMvkDPJV1xTpx0bO RRXJRi7WUxpWjIOc/dsTz4HXLwacetqcBakk4GAe6WnfrsE4tL787XRpIFso6gP3 Lqc9abhWu5Npn+l8/24BkSCjBXijKuFdATsF06+janOD4fkPSFrUf4Sh4GPzI88= =y0j/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 16 15:09:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FEC129587; Wed, 16 Nov 2016 15:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 8WDdhfnV0-Mw; Wed, 16 Nov 2016 15:09:19 -0800 (PST) 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 72FB3129432; Wed, 16 Nov 2016 15:09:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVI36167; Wed, 16 Nov 2016 23:09:16 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Nov 2016 23:09:15 +0000 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; Thu, 17 Nov 2016 07:09:09 +0800 From: Sheng Jiang To: Michael Richardson , "anima@ietf.org" , "netconf@ietf.org" Thread-Topic: [Anima] voucher presentation Thread-Index: AQHSP4blpynB1Ul29kWhDm0kdaLQKKDarNZ1//98OwCAAAyngIAAAp0AgACG4VX//9BUAIAAjiyS Date: Wed, 16 Nov 2016 23:09:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC6378C@NKGEML515-MBX.china.huawei.com> References: <48BBDF02-F7C3-426D-901F-699A6D9643DF@juniper.net> <5D36713D8A4E7348A7E10DF7437A4B927CC61100@NKGEML515-MBX.china.huawei.com> <20161115232222.GO9776@faui40p.informatik.uni-erlangen.de> <2A2BAEFB-8F9A-404F-BFAD-805EB7DFC947@juniper.net>, <20161116001700.GS9776@faui40p.informatik.uni-erlangen.de> <5D36713D8A4E7348A7E10DF7437A4B927CC61212@NKGEML515-MBX.china.huawei.com>, <2023.1479274148@dooku.sandelman.ca> In-Reply-To: <2023.1479274148@dooku.sandelman.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.122.222] 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.0A090204.582CE71C.0071, 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: 8dad144eef5be98618233c9241e23109 Archived-At: Cc: Benoit Claise , Terry Manderson Subject: Re: [Anima] voucher presentation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 16 Nov 2016 23:09:21 -0000 Hi, Michael R,=0A= =0A= We have a full agenda for Friday session. Since you do not apply a time slo= t, I don't think I have any spare time could allocate. =0A= =0A= I am not sure how you want to have the content for this document. If you wa= nt to integrate it into bootstrap document, it is simple straight forward. = But, if you want to process it as an independent document, we need to consu= ltant our AD. Let's do it offline.=0A= =0A= Sheng=0A= ________________________________________=0A= From: Anima [anima-bounces@ietf.org] on behalf of Michael Richardson [mcr+i= etf@sandelman.ca]=0A= Sent: 16 November 2016 13:29=0A= To: anima@ietf.org; netconf@ietf.org=0A= Cc: Benoit Claise; Terry Manderson=0A= Subject: Re: [Anima] voucher presentation=0A= =0A= Sheng, I think we need some time in the next session to discuss where we ar= e=0A= going to with draft-kwatsen-netconf-voucher, unless we can resolve this by = email.=0A= =0A= We had said that we thought it was all up to Benoit, since he was the AD fo= r=0A= both groups, but I just looked up and noticed that ANIMA is being handled b= y=0A= Terry, not Benoit :-)=0A= =0A= This document will also be used by 6tisch, btw.=0A= =0A= None of the authors care where the work is done; each of the groups would= =0A= have to do the work themselves if it didn't happen elsewhere.=0A= =0A= --=0A= Michael Richardson , Sandelman Software Works=0A= -=3D IPv6 IoT consulting =3D-=0A= =0A= =0A= =0A= From nobody Wed Nov 16 15:42:57 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765F312946C for ; Wed, 16 Nov 2016 15:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 3BhVfk-wwofL for ; Wed, 16 Nov 2016 15:42:54 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF1F1293FF for ; Wed, 16 Nov 2016 15:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3198; q=dns/txt; s=iport; t=1479339774; x=1480549374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QwbyNcR9wTE2W4BaYE4thRTonZg7NK6L3tmWbpPncSw=; b=MoEZWk4jFknFnA8brc4GR/bJzNQjPxb3B/IKMI/WwJiX2T4+9UW4s9xf wAhBFEA0xkgS/tarQbdb4aACaJuGBn14Vm0+4pkygRYBEQhgwvLH4qyTK ljc4C+iXPA88acmtgL2S0d0M3qrGOhba+3UQMX8go95kFvW51toF1E4bD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgAz7ixY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9YgQAHpEWUYoIHHQuFeQIagXlAEwECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDAQEBASAROgsFCwIBBgIYAgImAgICJQsVEAIEDgWIZAgOlRedRYIpi?= =?us-ascii?q?2IBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEJhzCCXYRJF4JtLYIwBYhZkWkBhVS?= =?us-ascii?q?LE5AjjU2ECQEgATSBBxMJg1iBRXKHGoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,650,1473120000"; d="scan'208";a="347881512" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 23:42:53 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uAGNgrDk005512 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2016 23:42:53 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 17:42:53 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 16 Nov 2016 17:42:53 -0600 From: "Max Pritikin (pritikin)" To: Michael Richardson Thread-Topic: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks) Thread-Index: AQHSPXv3uINP/86omEazChBbTlUL/6Dcr+gA Date: Wed, 16 Nov 2016 23:42:52 +0000 Message-ID: References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> <28804.1479020561@dooku.sandelman.ca> In-Reply-To: <28804.1479020561@dooku.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.5] Content-Type: text/plain; charset="utf-8" Content-ID: <767044EC166E7B4D9A6C35FD434BFE58@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 16 Nov 2016 23:42:56 -0000 DQpBc3N1bWluZyB3ZSB3b3JrIG91dCB0aGUgQlJTS0kgcXVlc3Rpb25zIHN1Y2ggdGhhdCBib290 c3RyYXBwaW5nIGR1cmluZyBkaXNhc3RlciByZWNvdmVyeSBpcyBjbGVhcmx5IGRlZmluZWQgSeKA mWQgaW1hZ2luZSB0aGUgcmVzdCBvZiBhbmltYSB3b3JrIHdvcmsg4oCcbWFnaWNhbGx54oCdIOKA lCBpbiB0aGF0IHRoZSBuZXcgZXF1aXBtZW50IGFkZGVkIHRvIGEgbmV0d29yayBkb2VzIHdoYXQg aXQgaXMgaW50ZW5kZWQgdG8gZG8gYXV0b21hdGljYWxseS4gDQoNCi0gbWF4DQoNCj4gT24gTm92 IDEzLCAyMDE2LCBhdCAxMjowMiBBTSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5k ZT4gd3JvdGU6DQo+Pj4gRGV2aWNlcyB0aGF0IGhhdmUgYmVlbiBicm91Z2h0IHVwIGFuZCBhcmUg aW4gdGhlIG5ldHdvcmsgcG9zdA0KPj4+IGJvb3RzdHJhcCBhcmUgbm90IHJlbGV2YW50IHRvIHRo ZSBCUlNLSSBkb2N1bWVudC4NCj4gDQo+PiBUbyBtZSB0aGUgbW9zdCBpbXBvcnRhbnQgZ29hbCBz aG91bGQgYmUgdG8gcHJvdmlkZSBjYW5kaWRhdGUgdXNlcnMgd2l0aA0KPj4gZGVwbG95bWVudCBn dWlkYW5jZS4gVGhpcyBzaG91bGQgZml0IEFOSU1BIGdvYWxzIGdpdmVuIGhvdyBpdHMgYW4gT1BT DQo+PiBncm91cC4NCj4gDQo+IENoYWlycywgDQo+ICBJIHRoaW5rIHdlIHNob3VsZCBhZGQgYSBu ZXcgZG9jdW1lbnQgdG8gb3VyIHNldC4gIFRoZSB0aXRsZSBtaWdodCBiZToNCj4gICAgIEF1dG9u b21pYyBOZXR3b3JraW5nIGluIERpc2FzdGVyIFJlY292ZXJ5OiBwcmVwZXJhdGlvbiBhbmQgb3Bl cmF0aW9uDQo+IA0KPiBUaGlzIHdvdWxkIGJlIGEgdmVyeSB2ZXJ5IHZlcnkgb3BlcmF0aW9uYWwg QkNQLg0KPiBXZSB3b24ndCBmaW5pc2ggdGhpcyB1bnRpbCBhZnRlciBldmVyeXRoaW5nIGhhcyBi ZWVuIHB1dCB0byBiZWQsIGJ1dCBJIHRoaW5rDQo+IHdlIHNob3VsZCBzdGFydCBpdCBzb29uZXN0 LCBzbyB0aGF0IHdlIGNhbiBjYXB0dXJlIG11Y2ggb2YgdGhpcw0KPiBkaXNjdXNzaW9uL2NvbmNl cm4uDQo+IA0KPj4gIGEpIGtlZXAgc3BhcmVzIHVuZW5yb2xsZWQsIGVucm9sIGR1cmluZyBkZXNh c3RlciByZWNvdmVyeSB3aXRoDQo+PiBzYXRlbGxpdGUgbGluayBiKSBlbnJvbCBzcGFyZSBkZXZp Y2VzIHdoZW4gdGhleSBhcmUgc3RvY2tlZCwgZGVwbG95DQo+PiBkdXJpbmcgZGVzYXN0ZXIuDQo+ IA0KPj4gbGV0cyBhc3N1bWUgd2UgYWdyZWUgYm90aCBhcmUgcmVsZXZhbnQgZGVwbG95bWVudCBv cHRpb25zIHRoYXQgdXNlcnMNCj4+IHNob3VsZCB1bmRlcnN0YW5kLCBjb21wYXJlIHByby9jb25z IGZvciB0aGVpciBjYXNlIGFuZCBjaG9vc2UuIElmIHlvdQ0KPj4gdGhpbmsgd2UgY2FuIG5vdCBt ZW50aW9uIGJvdGggaW4gdGhlIEJSU0tZIHNwZWMsIHRoZW4gaSB0aGluayBpdCB3b3VsZA0KPj4g YmUgYmV0dGVyIHRvIGhhdmUgYSBzZXBhcmF0ZSBkb2N1bWVudCB3aGVyZSBib3RoIGNvdWxkIGJl IGRpc2N1c3NlZC4NCj4gDQo+IEEgcmVhc29uIHdoeSBvbmUgd291bGQgaGF2ZSB1bmVucm9sbGVk IHNwYXJlcyBpcyBiZWNhdXNlIHRoZSBzcGFyZXMgYXJlIGtlcHQNCj4gYnkgdGhlIG1hbnVmYWN0 dXJlciBpbiBkaXN0cmlidXRlZCB3YXJlaG91c2VzLCBjbG9zZSB0byB3aGVyZSB0aGV5IG1pZ2h0 IGJlDQo+IG5lZWRlZCwgb3IgcGVyaGFwcyBldmVuLCB3b3VsZCBiZSBpbiBhIEZFTUEtbGlrZSBl bnRpdGllcycgd2FyZWhvdXNlLCB0byBiZQ0KPiBkZXBsb3llZCB0byB3aGljaGV2ZXIgb3BlcmF0 b3IgbmVlZGVkIHRoZW0uDQo+IA0KPiBUaGUgdXNlIG9mIEF1dG9ub21pYyBtZWNoYW5pc21zIG1p Z2h0IHJlc3VsdCBpbiBub3JtYWxpemF0aW9uIG11Y2ggb2YgdGhlDQo+IGNvbmZpZ3VyYXRpb24g b2Ygc29tZSBkZXZpY2VzLCBzbyBpdCB3b3VsZG4ndCBtYXR0ZXIgYXMgbXVjaCB3aGljaCB2ZW5k b3Incw0KPiBkZXZpY2Ugd2FzIGRlcGxveWVkLiAgTWF5YmUgdGhpcyB3b24ndCBiZSBmb3IgY29y ZSBCR1AtaGFwcHkgQkZScywgYnV0IGl0DQo+IGNvdWxkIGJlIHRoZSBjYXNlIHRoYXQgbGVzcyBj b21wbGljYXRlZCB0aGluZ3MgbGlrZSAyNCAxMC8xMDAvMTAwMHMgc3dpdGNoZXMNCj4gd291bGQg YmUgaW4gdGhhdCBjYXRlZ29yeS4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= From nobody Wed Nov 16 16:02:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BF21295DD for ; Wed, 16 Nov 2016 16:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 nKLiiDjbwftP for ; Wed, 16 Nov 2016 16:02:14 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AB2129429 for ; Wed, 16 Nov 2016 16:02:14 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id 3so84564656pgd.0 for ; Wed, 16 Nov 2016 16:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=bCUuIJrxeMCUOstsFGAXHhR0X6pmEhh8Y05iL+E79RI=; b=Eiw5vv1eXqqgMd5ZdAGpfsWz+/BdK3/ut4KhcMU5Hks1dpC7uZ8BJmAvOA9UHgRxQa 7DHIM83b3uLb9GQDWgxxNE3e68foUjPRWq3ejS36bAvIlBvtEkAIB63kVqgboXVI8u+n hrvL9SDyj5i72PapuybOiwK45dZbMjRFn7LdBVFSNT9Sg/45B8Y9ERb7PIZ2JYglbf9+ aBH5rqJf2iR6LhitIS7mys9yN+oR+nAdF5ZNy2chbMRuxlB3k6BxEAgFC2vrVHBU201t k4I2PpX9VzhDhO8hGBc7lR+M3a6uaYcUuroiF6rK+cd4qk9yVxBwoGPiq9ZRZQfpDzKf cqdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=bCUuIJrxeMCUOstsFGAXHhR0X6pmEhh8Y05iL+E79RI=; b=EzhdyCMm5vuQyz0uE7h05B9oXuqoJxfta3dt+OSuDm8UDHpuxIQ0UoW0gI+CUN7QFO tOR8wW51uj/PBClM45Eu9ZXpQM2X/ObHSPcra6CYk6mL7tuFyYkPzEr4XtN0ur0tft3J 4FDb4DhnxAz6TMnKISNmjnnZ8/K1XuVzdJPnO4i0E5y5E9tE/aGO5rlOz4D7EcCR8+ko Fi6+5zRvUrmk6+XL89r+ZNxxjBBM9DME14x4BjSyqwlXPfFgGsPCYNs3zKe63bE9SG/d 2QsWw8eTBN/n2YFnsixhlSji8YcoGpMMTxyCrmbVmdiNGegrK9sYArVaBtofF9NmGoJi gbAA== X-Gm-Message-State: ABUngvc2goeL5tRaRsBj8Aw62Lsa+V9N/V9G8ScIusY5mv6qQzBz6Pe1Jwy30MtG6Rsesw== X-Received: by 10.98.139.157 with SMTP id e29mr323796pfl.115.1479340933528; Wed, 16 Nov 2016 16:02:13 -0800 (PST) Received: from [192.168.178.23] (153.23.255.123.dynamic.snap.net.nz. [123.255.23.153]) by smtp.gmail.com with ESMTPSA id b126sm261428pfg.90.2016.11.16.16.02.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 16:02:12 -0800 (PST) To: anima@ietf.org References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> <28804.1479020561@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3cd4ec63-2652-dc92-0667-2f661142dd65@gmail.com> Date: Thu, 17 Nov 2016 13:02:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Desaster recover... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:02:16 -0000 On 17/11/2016 12:42, Max Pritikin (pritikin) wrote: >=20 > Assuming we work out the BRSKI questions such that bootstrapping during= disaster recovery is clearly defined I=E2=80=99d imagine the rest of ani= ma work work =E2=80=9Cmagically=E2=80=9D =E2=80=94 in that the new equipm= ent added to a network does what it is intended to do automatically.=20 Yes, that would be the plan ;-). It might be worth understanding how cellphone systems deal with this. Aft= er a disaster (as this week in Kaikoura NZ) there's initially no electricity= and no link out from the base stations. How do they rebuild the trust infrastructure so that SIM cards from anywhere in the world can connect? Does this only work after there's a connection to the provider's infrastr= ucture? http://www.stuff.co.nz/business/industries/86463492/options-being-assesse= d-for-restoring-phone-services-to-kaikoura Brian >=20 > - max >=20 >> On Nov 13, 2016, at 12:02 AM, Michael Richardson wrote: >> >> >> Toerless Eckert wrote: >>>> Devices that have been brought up and are in the network post >>>> bootstrap are not relevant to the BRSKI document. >> >>> To me the most important goal should be to provide candidate users wi= th >>> deployment guidance. This should fit ANIMA goals given how its an OPS= >>> group. >> >> Chairs,=20 >> I think we should add a new document to our set. The title might be:= >> Autonomic Networking in Disaster Recovery: preperation and operati= on >> >> This would be a very very very operational BCP. >> We won't finish this until after everything has been put to bed, but I= think >> we should start it soonest, so that we can capture much of this >> discussion/concern. >> >>> a) keep spares unenrolled, enrol during desaster recovery with >>> satellite link b) enrol spare devices when they are stocked, deploy >>> during desaster. >> >>> lets assume we agree both are relevant deployment options that users >>> should understand, compare pro/cons for their case and choose. If you= >>> think we can not mention both in the BRSKY spec, then i think it woul= d >>> be better to have a separate document where both could be discussed. >> >> A reason why one would have unenrolled spares is because the spares ar= e kept >> by the manufacturer in distributed warehouses, close to where they mig= ht be >> needed, or perhaps even, would be in a FEMA-like entities' warehouse, = to be >> deployed to whichever operator needed them. >> >> The use of Autonomic mechanisms might result in normalization much of = the >> configuration of some devices, so it wouldn't matter as much which ven= dor's >> device was deployed. Maybe this won't be for core BGP-happy BFRs, but= it >> could be the case that less complicated things like 24 10/100/1000s sw= itches >> would be in that category. >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Wed Nov 16 16:17:41 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84061294FF for ; Wed, 16 Nov 2016 16:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzzCvBNlQPde for ; Wed, 16 Nov 2016 16:17:37 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6181812946F for ; Wed, 16 Nov 2016 16:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17940; q=dns/txt; s=iport; t=1479341857; x=1480551457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xpyUZRd8LemRVWgxiEYeqNtYaNDGConTZU5E+Qn9RkM=; b=f/GOykFcG7KyHWvr4wcEjb4u5Oz64IFU8MT+HduFc1tdESUCvFuztPNg Fzv6I04CtgBjj43L5BLPStf4SRS9z9J/tcKqrmIJOiBc8a8q72Tc6ydf0 dcCX1eGQTm2RycWE7A/3OmBGWHMDwxewcXNrcOI2+PI/0swgmGkBAl9oz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQD09SxY/5hdJa1VCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMpDgEBAQEBH4FYB403lw6UYoIHhiECGoF6PxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBAwEjBA1FBQsCAQgOCgICJgICAjAVEAIEDgWIZAiybIFsPYtjAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR6BCYcwgVWBCIQiDQYUgwQtgjAFmkIBhVSDM4dgkCONTYQ?= =?us-ascii?q?JAR43RkGDQBwYgUVyhWuBL4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,650,1473120000"; d="scan'208";a="349454331" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2016 00:17:36 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAH0HZXV019012 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 00:17:35 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 18:17:35 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 16 Nov 2016 18:17:35 -0600 From: "Max Pritikin (pritikin)" To: Toerless Eckert Thread-Topic: Desaster recover... (was: Re: [Anima] [homenet] write up of time without clocks) Thread-Index: AQHSNhKH12OcT6VTAUqgY6dYwye4haDJqvoAgAPGRACAD1cuAA== Date: Thu, 17 Nov 2016 00:17:34 +0000 Message-ID: <31F53517-74D0-4B56-A1DF-68FC948F1CB4@cisco.com> References: <9948c34a-eb3a-7c6b-ef2f-ea5e71f6bbcf@gmail.com> <8747064C-2FB1-4FF5-B34C-3F602F1AB046@cisco.com> <4a0adf25-e99a-656f-811a-cdfcaa4ffe9c@cisco.com> <86ee80a9-0304-bc57-d017-844ec684cd69@gmail.com> <7A849AE1-26EC-4E6C-B186-14EBFECCA33D@cisco.com> <20161103204024.GB6498@faui40p.informatik.uni-erlangen.de> <7812136A-55F4-42CE-999F-6CD53DD6934F@cisco.com> <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20161107060138.GA30450@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: text/plain; charset="utf-8" Content-ID: <4828339C5EC8174C907CCB7636AFA4FE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Toerless Eckert , Eliot Lear , Anima WG Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up of time without clocks) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:17:40 -0000 UmU6IHF1ZXN0aW9ucyBvZiBzY29wZSBmb3IgZGlzYXN0ZXIgcmVjb3ZlcnkNCg0KSSB0aGluayBC UlNLSSBuZWVkcyB0byBjbGFyaWZ5IGhvdyBkaXNhc3RlciByZWNvdmVyeSB3b3Jrcy4gUGVyaGFw cyBhIHNlY3Rpb24gb24gdGhpcyBvciBwZXJoYXBzIGVtYmVkZGVkIGluIHRoZSB0ZXh0Lg0KT25j ZSB0aGUgbmV0d29yayBpcyB1cCBJIGRvbuKAmXQgc2VlIGhvdyBkaXNhc3RlcuKAmXMgZWZmZWN0 cyBBbmltYSBvcGVyYXRpb25zLiBJdHMganVzdCBhIG5ldHdvcmsgYW5kIHJ1bnMgYXMgc3VjaC4g DQoNCkNvbnRpbnVlZCBkZXRhaWxlZCBkaXNjdXNzaW9uIGluIGxpbmUsDQoNCg0KPiBPbiBOb3Yg NiwgMjAxNiwgYXQgMTE6MDEgUE0sIFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT4gd3Jv dGU6DQo+IA0KPiBPbiBGcmksIE5vdiAwNCwgMjAxNiBhdCAwOToyMzoxNVBNICswMDAwLCBNYXgg UHJpdGlraW4gKHByaXRpa2luKSB3cm90ZToNCj4+IFRoZXJlIGlzIGEgbG90IGhlcmUuIEF0dGVt cHRpbmcgdG8gY29tbWVudCBvbiBpdCBhbGwuIA0KPj4gDQo+PiBJdCB3b3VsZCByZWFsbHkgaGVs cCBpZiB3ZSBjb3VsZCByZWxhdGUgdGhlc2UgZGlzY3Vzc2lvbnMgdG8gc3BlY2lmaWMgdGV4dCBz ZWN0aW9ucyB0aGF0IGNvdWxkIGJlIGltcHJvdmVkLiBPdGhlcndpc2Ugd2U/Pz9yZSBqdXN0IGJs b3dpbmcgaW50byB0aGUgd2luZC4gKFdoZXJlIGl0IHNlZW1zIG9idmlvdXMgST8/P3ZlIGFkZGVk IHN1Y2ggbm90ZXMpLiANCj4gDQo+IFN1cmUsIGJ1dCBsZXRzIGhpZ2ggbGV2ZWwgYWdyZWUgd2hh dCB0eXBlIG9mIGNvbnRlbnQgaXMgdXNlZnVsIGFuZA0KPiB3aGVyZSBpdCB3b3VsZCBmaXQuDQo+ IA0KPj4+IC0gTGFyZ2Ugb3JnYW5pemF0aW9ucyB3aWxsIGhhdmUgc3BhcmVzLiBXaXRoIEFOSU1B LCB0aG9zZSBzcGFyZXMgc2hvdWxkDQo+Pj4gYmUgc3RvcmVkIHByZS1lbnJvbGxlZCB0byBhdm9p ZCBNQVNBL3JlZ2lzdHJhciBkZXBlbmRlbmN5IGR1cmluZw0KPj4+IHJlY292ZXJ5L3JlcGxhY2Vt ZW50czogUmVjZWl2ZSBnZWFyIG9uIGFueSBzaXRlIChubyBjZW50cmFsIHByb3Zpc2lvbmluZw0K Pj4+IHNpdGUgbmVlZGVkKSwgYnV0IHVucGFjaywgcGx1ZyBpbiBmb3Igc2hvcnQgcGVyaW9kLCB0 aGVuIHN0YXNoIGF3YXkuDQo+PiANCj4+IERldmljZXMgdGhhdCBoYXZlIGJlZW4gYnJvdWdodCB1 cCBhbmQgYXJlIGluIHRoZSBuZXR3b3JrIHBvc3QgYm9vdHN0cmFwIGFyZSBub3QgcmVsZXZhbnQg dG8gdGhlIEJSU0tJIGRvY3VtZW50LiANCj4gDQo+IFRvIG1lIHRoZSBtb3N0IGltcG9ydGFudCBn b2FsIHNob3VsZCBiZSB0byBwcm92aWRlIGNhbmRpZGF0ZSB1c2VycyB3aXRoDQo+IGRlcGxveW1l bnQgZ3VpZGFuY2UuIFRoaXMgc2hvdWxkIGZpdCBBTklNQSBnb2FscyBnaXZlbiBob3cgaXRzIGFu IE9QUyBncm91cC4NCj4gDQo+IExldHMgc2F5IHdlIGhhdmUgdHdvIG9wdGlvbnM6DQo+IA0KPiAg YSkga2VlcCBzcGFyZXMgdW5lbnJvbGxlZCwgZW5yb2wgZHVyaW5nIGRlc2FzdGVyIHJlY292ZXJ5 IHdpdGggc2F0ZWxsaXRlIGxpbmsNCj4gIGIpIGVucm9sIHNwYXJlIGRldmljZXMgd2hlbiB0aGV5 IGFyZSBzdG9ja2VkLCBkZXBsb3kgZHVyaW5nIGRlc2FzdGVyLg0KPiANCj4gbGV0cyBhc3N1bWUg d2UgYWdyZWUgYm90aCBhcmUgcmVsZXZhbnQgZGVwbG95bWVudCBvcHRpb25zIHRoYXQgdXNlcnMN Cj4gc2hvdWxkIHVuZGVyc3RhbmQsIGNvbXBhcmUgcHJvL2NvbnMgZm9yIHRoZWlyIGNhc2UgYW5k IGNob29zZS4gSWYgeW91IHRoaW5rDQo+IHdlIGNhbiBub3QgbWVudGlvbiBib3RoIGluIHRoZSBC UlNLWSBzcGVjLCB0aGVuIGkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyDQo+IHRvIGhhdmUgYSBz ZXBhcmF0ZSBkb2N1bWVudCB3aGVyZSBib3RoIGNvdWxkIGJlIGRpc2N1c3NlZC4gDQoNClllcywg dGhlc2UgYXJlIHRoZSB0d28gb3B0aW9ucyBhdmFpbGFibGUgdG8gYSBuZXR3b3JrIHRoYXQgdXNl cyBCUlNLSS4gV2UgY2FuIGNsZWFybHkgc3RhdGUgYXMgc3VjaCBpZiB3ZSBhZGQgYSBzZWN0aW9u IG9uIGRpc2FzdGVyIHJlY292ZXJ5Lg0KDQo+Pj4gVGhpcyBpcyBpbW8gYW4gZWFzeSByZXF1aXJl bWVudCBhbHNvIHVzZWZ1bCB3aXRob3V0IGRlc2FzdGVyIHJlcXVpcmVtZW50cw0KPj4+IC0gYWth OiBlbnJvbGxlZCBzcGFyZXMgd291bGQgbGlrZWx5IGFsc28gaGF2ZSBiZXR0ZXIgdGhlZnQvYWJ1 c2UgcHJvdGVjdGlvbg0KPj4+IHRoYW4gbm9uLWVucm9sbGVkLiBBbmQgeWVzLCB5b3Ugd2lsbCBo YXZlIHRvIHBvd2VyIHVwIHRoZXNlIHNwYXJlcw0KPj4+IG9uY2UgYSB5ZWFyLiBXaGljaCBJTUhP IGlzIG9rLiBBbmQgb2YgY291cnNlIGNlcnRzIHNob3VsZCB0aGVyZWZvcmUNCj4+PiBiZSBzb21l d2hhdCBsb25nZXIgdGhhbiAxIHllYXIpLg0KPj4gDQo+PiBUaGlzIGNvdWxkIGJlIGNhcHR1cmVk IGFzIGEgZGlzY3Vzc2lvbjogd2hhdCBkb2VzIGEgZGV2aWNlIGRvIHdoZW4gaXRzIGNyZWRlbnRp YWxzIGFyZSBvdXQgb2YgZGF0ZT8gRG9lcyBpdCBmYWxsIGJhY2sgb24gZnVsbCBib290c3RyYXBw aW5nPyBJZiBzbyB0aGlzIGJlY29tZXMgYSBwb3RlbnRpYWwgYXR0YWNrIHZlY3RvciB3aGVyZWlu IHRoZSBhdHRhY2tlciBjYW4gY29udmluY2UgdGhlIGRldmljZSBpdCBpcyBvdXQgb2YgZGF0ZSBh bmQgdGhlbiBmb3JjZSBpdCB0byByZXN0YXJ0IGJvb3RzdHJhcHBpbmcuIFRoYXQgd291bGQgYmUg YmFkLiANCj4gDQo+IEhhaGEuLi4gOy0pIGkganVzdCB3YW50ZWQgdG8gc2hvdyB3aGF0IElNSE8g YXJlIHRoZSBtb3N0IHNpbXBsZQ0KPiBkZXBsb3ltZW50IG9wdGlvbnMgdG8gZGVhbCB3aXRoIGRl c2FzdGVyIHJlY292ZXIuIE5vdyB5b3UncmUgdGhlIG9uZSB3aG8gaXMNCj4gb3BlbmluZyBhbm90 aGVyIHJvdW5kIG9mIGRpc2N1c3Npb25zIHRyeWluZyB0byBmaWd1cmUgb3V0IHRoZSBiZXN0DQo+ IHNlY3VyaXR5IGNvbXByb21pc2UgZm9yIHRob3NlIGRlcGxveW1lbnQgcHJvY2Vzc2VzLiAgV2hp Y2ggaXMgZ3JlYXQuDQo+IEp1c3QgZG9uJ3QgYmxhbWUgbWUgdGhhdCB0aGVyZSBhcmUgbW9yZSBh bmQgbW9yZSBpbnRlcmVzdGluZyBkZXRhaWxzIHRvDQo+IGNhcHR1cmUgc29tZXdoZXJlLg0KPiAN Cj4+IFNvLCBzaG91bGQgdGhlcmUgYmUgYW4gaW5qZWN0aW9uIHBvaW50IGludG8gdGhlIGJvb3Rz dHJhcHBpbmcgc3RhdGUgbWFjaGluZSB0aGF0IHNheXMgc29tZXRoaW5nIGxpa2U6DQo+PiANCj4+ IElmIGEgZGV2aWNlIGZhaWxzIHRvIGpvaW4gdGhlIEFOSSBhZnRlciBbc29tZSBudW1iZXJdIG9m IGF0dGVtcHRzIGl0IGF0dGVtcHRzIHRvIHJlcGVhdCBib290c3RyYXBwaW5nIHVzaW5nIGl0cyBv cmlnaW5hbCBTVURJIGNyZWRlbnRpYWxzLg0KPiANCj4gSSdkIHByZXBhcmUgYSBmbGFnICdvcGVy YXRpb25hbCcgc2V0IGJ5IFNETiBjb250cm9sbGVyIG9yIEFTQSBhZnRlciANCj4gdGhlIGRldmlj ZSBpcyAicHJvdmlzaW9uZWQiIChjb25maWcvaW50ZW50IGFwcGxpZWQpLg0KPiANCj4+IER1cmlu ZyB0aGlzIGJvb3RzdHJhcHBpbmcgYXR0ZW1wdCBpdCBNVVNUIG9ubHkgYm9vdHN0cmFwIG9uIGEg UmVnaXN0cmFyIHRoYXQgcHJvdmlkZXMgYm90aCBhIHZhbGlkIHZvdWNoZXIgYW5kIGFuIGlkZW50 aXR5IHJlY29nbml6YWJseSB3aXRoaW4gdGhlIHNhbWUgUEtJIGhpZXJhcmNoeSB0aGUgZGV2aWNl IHdhcyBpbiBwcmV2aW91c2x5LiBUaGlzIGlzIGRldGVjdGVkIGJ5IHRoZSBkZXZpY2UgYnkgZWl0 aGVyIChhKSB0aGUgZG9tYWluQ0FjZXJ0IGlzIGFuIGV4YWN0IG1hdGNoIGZvciB0aGUgY3VycmVu dCBkb21haW4gdHJ1c3QgYW5jaG9yIGtub3duIHRvIHRoZSBkZXZpY2Ugb3IgKGIpIHRoZSBFU1Qg L2NhY2VydHMgcmVzcG9uc2UgaW5jbHVkZXMgYSBjaGFpbiB0aGF0IHRlcm1pbmF0ZXMgaW4gdGhl IGN1cnJlbnQgZG9tYWluIHRydXN0IGFuY2hvciBrbm93biB0byB0aGUgZGV2aWNlLiAgDQo+PiAN Cj4+IFRoaXMgZXh0ZW5kcyB0aGUgbGlmZXRpbWUgb2Ygc3VjaCBhIHN0b3JlZCBkZXZpY2UgYmV5 b25kIGl0cyBvd24gY2VydGlmaWNhdGUgKG1heWJlIDEgeWVhcikgKmFuZCogYmV5b25kIHRoZSBj dXJyZW50IENBIGNlcnRpZmljYXRlIChtYXliZSBhIDJ5ZWFyIGNlcnQpIGFuIGFsbCB0aGUgd2F5 IGludG8gdGhlIG5leHQgQ0EgY2VydGlmaWNhdGUgKGFub3RoZXIgMiB5ZWFycykuIFRoYXQgaXMg YSBwcmV0dHkgc29saWQgbGlmZXRpbWUgKHVwIHRvIDQgeWVhcnMpIGZvciByZWNvdmVyeS4NCj4g DQo+IEludGVyZXN0aW5nIHRob3VnaHQuDQo+IA0KPiBhKSBXb3VsZCBsaWtlIHRvIHVuZGVyc3Rh bmQgaG93IHRoaXMgY29tcGFyZXMgdG8ganVzdCBtYWtpbmcgY2VydHMNCj4gbG9uZ2VyLWxpdmVk LCBlZzogMyB5ZWFycywgYnV0IGRvaW5nIG5vcm1hbCByZW5ld2FsIGFmdGVyIDMwJSB0aW1lLg0K PiANCj4gYikgU2VlbSBsaWtlIHRoZXJlJ3MgcXVpdGUgYSBiaXQgb2YgYW5hbHlzaXMgdG8gYmUg ZG9uZSBvZiBob3cgZGlmZmVyZW50DQo+IHBhcmFtZXRlci9vcHRpb25zIHdpbGwgd29yayB0b2dl dGhlcjoNCj4gIC0gZGV2aWNlIHdpdGgvd2l0aG91dCByZWxpYWJsZSBSVEMNCj4gIC0gd2hhdCB3 b3VsZCBiZSBuZWNlc3NhcnkvYmVuZWZpY2lhbCB3aXRoIG5vbmNlLWxlc3Mgdm91Y2hlcnMgPw0K PiAgICBob3cgYWJvdXQgbm9uY2VsZXNzIHZvdWNoZXJzIHdpdGggc2VxdWVuY2UgbnVtYmVyLi4u IC0+IHJlbWVtYmVyDQo+ICAgIG93bmVyc2hpcCB2b3VjaGVyIGFuZCBhbGxvdyBmb3IgaXQgdG8g YmUgcmVwbGFjZWQgb25seSB3aXRoIG9uZSB0aGF0DQo+ICAgIGhhc3MgYSBoaWdoZXIgc2VyaWFs IG51bWJlci4NCj4gDQo+Pj4gLSBJZiBzcGFyaW5nIHdvdWxkIGJlIGNyb3NzLWxvY2F0aW9ucyAo ZWc6IHNwYXJlcyBzZW50IGZyb20gc29tZSBzaXRlIHRvDQo+Pj4gb3RoZXIgc2l0ZXMgZHVyaW5n IHJlY292ZXJ5KSwgdGhlbiBpdHMgaW1wb3J0YW50IHRoYXQgdGhlIEFOSU1BIGNlcnRzIGRvDQo+ Pj4gbm90IGluY2x1ZGUgYW55IGxvY2F0aW9uIHNwZWNpZmljIGF0dHJpYnV0ZXMgdGhhdCB3b3Vs ZCBwcm9oaWJpdCB0aGFydA0KPj4+IG1vdmVtZW50LiBTbyBmYXIgQlJTS1kgZG9lcyBub3QgaW5j bHVkZSBhbnkgc3VjaCBhdHRyaWJ1dGVzLCBidXQgaW4NCj4+PiBkaXNjdXNzaW9ucywgdGhyZWUg aGFzIGJlZW4gaW50ZXJlc3QgdG8gbG9jayBpbnRvIHRoZSBjZXJ0IHNvbWUgZGV2aWNlDQo+Pj4g cm9sZSBzcGVjaWZpYyBhdHRyaWJ1dGVzLCBhbmQgZm9yIGEgc3BhcmUgcGllY2NlIG9mIGVxdWlw bWVudCwgdGhvc2UNCj4+PiBhdHRyaWJ1dGVzIG1heSBub3QgYmUgcHJlZGV0ZXJtaW5lZC4NCj4+ PiANCj4+PiBBa2E6IERlc2FzdGVyIHNwYXJpbmcgbWVhbnMgZG9tYWluIGNlcnRzIG5lZWQgdG8g YmUgc2ltcGxlLCBkZXZpY2VzDQo+Pj4gcmV1c2VhYmxlIGFjcm9zcyBkb21haW4uDQo+PiANCj4+ IEkgYWdyZWUgdGhhdCBjZXJ0cyBzaG91bGQgaW5jbHVkZSB0aGUgYWJzb2x1dGUgbWluaW11bSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgZGV2aWNlLiBUaGUgYWN0dWFsIElEIGlzIHN1ZmZpY2llbnQg aW4gbXkgYm9vay4gQXR0cmlidXRlIENlcnRzIG9yIGJhY2tlbmQgZGF0YWJhc2UgbG9va3VwcyBv ciBzaG9ydCB0ZXJtIHRva2VucyBvYnRhaW5lZCBieSB0aGUgZGV2aWNlIGluIHBsYWNlIGFyZSBh bGwgbWV0aG9kcyBvZiBkaXN0cmlidXRpbmcgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4gDQo+IA0K PiBEZXNhc3RlciByZWNvdmVyeSBzZWVtcyB0byBiZSBvbmUgZ29vZCBtb3RpdmF0aW9uIHRvIG5v dCBwdXQNCj4gbW9yZSB0aGFuIHRoZSBtaW5pbXVtIGludG8gdGhlIGNlcnRzLiBJIHdhcyBhIGZh biBvZiBwdXR0aW5nIG1vcmUNCj4gaW50byBjZXJ0cyBpbiB0aGUgcGFzdC4uLg0KPiANCj4+PiAt IElmIHNwYXJlcyBhcmUgZG9uZSBieSBhIHNoYXJlZCBmYWNpbGl0eTogdmVuZG9yLCBGRU1PIChm b3IgZmVkIG5ldHdvcmtzKQ0KPj4+IG9yIHRoZSBsaWtlLCBvbmUgY291bGQgdGhpbmsgb2YgdGhh dCBlbnRpdHkgb2ZmZXJpbmcgKGVtZXJnZW5jeSkNCj4+PiBlbnJvbG1lbnQgc2VydmljZS4NCj4+ PiANCj4+PiBTdWNoIGFuIGVudGl0eSB3b3VsZCBoYXZlIGRlc2FzdGVyIHByb29mIE1BU0EgY29u bmVjdGl2aXR5IG9uIHNpdGUsDQo+Pj4gYW5kIHRoZSBjdXN0b21lcnMgd291bGQgcHJvdmlkZSBp dCB3aXRoIChlbWVyZ2VuY3kpIHJlZ2lzdHJhciBjZXJ0cy4NCj4+IA0KPj4gT2suIFNvIGxpa2Ug YSBDaXNjbyBORVJWIHRydWNrIHRoYXQgcHJvdmlkZXMgY29ubmVjdGl2aXR5IHN1ZmZpY2llbnQg dG8gcmVidWlsZCBhIG5ldHdvcmsgaW4gcGxhY2UuIA0KPj4gDQo+PiBJc3N1aW5nIGEgbmV3IFJl Z2lzdHJhciBJRCB3b3VsZCBtZWFuIGJlaW5nIGFibGUgdG8gYnJpbmcgdXAgdGhlIFBLSSBpbmZy YXN0cnVjdHVyZSBkdXJpbmcgdGhlIHJlY292ZXJ5IHByb2Nlc3MuIEJ1dCB0aGlzIGlzIGV4YWN0 bHkgdGhlIHRpbWUgcGVyaW9kIHdoZW4gaGF2aW5nIGFzIG11Y2ggb2YgdGhlIGNyaXRpY2FsIGtl eWluZyBpbmZyYXN0cnVjdHVyZSBvZmZsaW5lIGFuZCBzZWN1cmVkIGNvdWxkIGJlIGJlbmVmaWNp YWwgZm9yIGxvbmd0ZXJtIHNlY3VyaXR5LiBPbmUgY291bGQgYXJndWUgdGhhdCBleHRyYSBhdHRl bXB0cyBzaG91bGQgYmUgbWFkZSB0byBlbnN1cmUgdGhlIFBLSSBpcyBvZmZsaW5lLiANCj4gDQo+ IE15IHRob3VnaHQgd2FzDQo+IGEpIHRoZSBkZXNhc3RlciByZWNvdmVyeSByZWdpc3RyYXItSURz IGFyZSBwcmVwcm92aXNpb25lZCBfYmVmb3JlXyBkZXNhc3Rlcg0KPiAgIChjb250cmFjdCBiZXR3 ZWVuIGRvbWFpbiBhbmQgZGVzYXN0ZXIvc3BhcmUgcmVjb3ZlcnkgZW50aXR5KS4NCj4gYikgVGhl IGZhY2lsaXR5IHRvIHdoaWNoIHRoZXkgYXJlIGFsbG9jYXRlZCBpcyBzaGFyZWQgYWNyb3NzIG11 bHRpcGxlDQo+ICAgZG9tYWlucy4NCj4gYykgdGhlIGZhY2lsaXR5IGlzIG5vdCAiZGVzYXN0ZXIg b24tc2l0ZSIgLT4gdGhlIHNwYXJlcyB3aWxsIG5vdCBiZSBvbi1zaXRlLA0KPiAgIGJ1dCB3aWxs IGJlIHN0b3JlZCBhdCBzb21lIGNlbnRyYWwgc2l0ZS4gRW5yb2xsbWVudCB3b3VsZCBoYXBwZW4g YXQNCj4gICB0aGF0IGNlbnRyYWwgc2l0ZSwgdGhlbiB0aGV5J2QgYmUgc2hpcHBlZCBvbnRvLWRl c2FzdGVyLXNpdGUuDQo+IA0KPj4+IChlbWVyZ2VuY3kpIG1lYW5pbmcgdGhhdCB0aGUgZW50aXR5 IGlzIG9ubHkgcGVybWl0dGVkIHRvIGVucm9sIGR1cmluZw0KPj4+IGVtZXJnZW5jaWVzLCBhbmQg dGhlIGN1c3RvbWVyIGNvdWxkIGJlIGFibGUgdG8gdmVyaWZ5IHRoZSBlbWVyZ2VuY3kNCj4+PiBl bnRpdGllcyBiZWhhdmlvciBieSBwdWxsaW5nIGZyb20gdGhlIE1BU0EgYW4gYXVkaXQgbG9nLg0K Pj4gDQo+PiBTZWN0aW9uIDUuNiBkb2Vzbj8/P3QgaW5jbHVkZSB0aGUgUmVnaXN0cmFyIGlkZW50 aXR5IG9ubHkgdGhlIGRvbWFpbklEIGluIHRoZSBsb2cuIERvIGZvbGtzIHRoaW5rIHRoZSBSZWdp c3RyYXIgSUQgc2hvdWxkIGJlIGluY2x1ZGVkIGFzIHdlbGw/DQo+IA0KPiBPaCwgcmlnaHQuIGkg Y29uZnVzZWQgZG9tYWluLWlkIHdpdGggcmVnaXN0cmFyLUlELg0KPiANCj4gSSBkZWZpbml0ZWx5 IHRoaW5rIHJlZ2lzdHJhci1JRCB3b3VsZCBiZSBuZWNlc3NhcnkgdG8gbG9nIHNvDQo+IHRoYXQg YXVkaXQtbG9ncyBiZWNvbWUgbW9yZSB1c2VmdWwgdG8gYmFja3RyYWNrIHdoYXQgaGFwcGVuZWQu DQoNCkkgY2FuIHNlZSB5b3VyIHBvaW50cyB3cnQgdG8gbG9nZ2luZyB0aGUgUmVnaXN0cmFyLUlE cy4gQnV0IEkgdGhpbmsgSSdsbCBjb250aW51ZSB0byBwdXNoIGJhY2sgb24gaXQgZm9yIHRoZSBt b21lbnQuIA0KDQpBcyBjdXJyZW50bHkgZW52aXNpb25lZCB0aGUgTUFTQSBzZXJ2aWNlIGlzIHBy b3ZpZGluZyB0aGUgYWJzb2x1dGUgbWluaW11bSBzZXJ2aWNlIG5lY2Vzc2FyeSB0byBhbGxvdyB0 aGUgRG9tYWluIHRvIHNlY3VyZWx5IGJvb3RzdHJhcCBkZXZpY2VzLiBJZiB3ZSBhZGQgdGhlIFJl Z2lzdHJhci1JRCB3ZSBhcmUgYWRkaW5nIGFkZGl0aW9uYWwgZmVhdHVyZXMgdG8gdGhpcyBzZXJ2 aWNlLiBUaGUgUmVnaXN0cmFycyBzaG91bGQga2VlcCB0aGVpciBvd24gbG9ncyBhbmQgdGhlIGRv bWFpbiBhZG1pbiBzaG91bGQgYmUgYWJsZSB0byBzZWFyY2ggdGhlbSDigJQgdGhlcmUgaXMgbm8g bmVlZCB0byBvZmZsb2FkIHRoaXMgZnVuY3Rpb25hbGl0eSBvbnRvIHRoZSBNQVNBLiANCg0KWWVz LCB0aGUgTUFTQSAqY291bGQqIGVhc2lseSBsb2cgdGhpcyBpbmZvcm1hdGlvbiBhbmQgYSBEb21h aW4gYWRtaW4gbWlnaHQgZmluZCBpdCB2ZXJ5IHVzZWZ1bCB0byBoYXZlIHRoaXMgaW5mb3JtYXRp b24uIElmIHdlIGFzc3VtZSB0aGV5IGNhbuKAmXQgKGZvciBzb21lIHJlYXNvbikgdHJ1c3QgdGhl aXIgbG9jYWwgUmVnaXN0cmFyIGluZnJhc3RydWN0dXJlLiBJIGNvbnRlbmQgdGhlcmUgaXMgZW5v dWdoIGdvaW5nIG9uIHdpdGhvdXQgYWRkaW5nIGV4dHJhIHNlcnZpY2VzLiANCg0KVGhpcyBhbmQg dGhlIOKAnHJldm9jYXRpb27igJ0gKGljaykgZGlzY3Vzc2lvbiBoYXZlIG1ha2UgaXQgY2xlYXIg dGhhdCB3ZSBzaG91bGQgZnV0dXJlIHByb29mIHRoZSBsb2cuIFRoYXQgd2F5IGFkZGl0aW9uYWwg c2VydmljZXMvZXZlbnQgdHlwZXMgY2FuIGJlIGFkZGVkIHRoYXQgY292ZXIgdGhlc2UgYW5kIG1v cmUgc2NlbmFyaW9zLiANCg0KPj4gSWYgdGhpcyB3YXMgZG9uZSB0aGVuIGRvZXMgaXQgbWF0dGVy IGlmIHRoZSBSZWdpc3RyYXIgY2VydCBoYXMgcm9sZSBpbmZvcm1hdGlvbiBpbiBpdD8gQXMgcGVy IHRoZSBhYm92ZSB3aGF0IHdvdWxkIGhhcHBlbiBpZiBhbGwgZGV2aWNlcyBpbiB0aGUgQU5JIGNv dWxkIGFjdCBhcyBhIHJlZ2lzdHJhcj8gVGhlcmUgd291bGQgYmUgYSBoaWdoZXIgY2hhbmNlIHRo YXQgb25lIG9mIHRoZW0gd291bGQgbWVzcyB1cCBhbmQgYWN0dWFsbHkgcGVyZm9ybSByZWdpc3Ry YXIgYWN0aXZpdGllcyBpbmNvcnJlY3RseSA/Pz8gYnV0IGl0IHdvdWxkIGJlIGxvZ2dlZCBzbyB0 aGUgYWRtaW4gY291bGQgd2F0Y2ggZm9yIHRoYXQuDQo+IA0KPiANCj4gSSBkb24ndCB0aGluayB3 ZSBuZWVkIG1hbnkvYWxsIGRldmljZXMgdG8gYmUgcmVnaXN0cmFycy4gSSBkb24ndCB0aGluaw0K PiB3ZSd2ZSBnb3QgYSB3b3JraW5nIHNlY3VyaXR5IG1vZGVsIHRvIGRvIHRoaXMgYW55aG93IC0g ZWc6IGF1dGhlbnRpY2F0aW5nDQo+IGFsbCB0aG9zZSBkZXZpY2VzIGFnYWluc3QgdGhlIENBLiBJ IGhvcGUgd2UgZG8gbm90IG5lZWQgdG8gZGlzY3VzcyBvdGhlcg0KPiByb2xlcyBiZXNpZGUgInJl Z2lzdHJhciIgaW4gdGhpcyBjb250ZXh0Lg0KPiANCj4+IFRob3VnaHRzPyBJPz8/bSB3b3JyaWVk IGJ1dCBzZWUgdGhlIGNvbnZlcnNhdGlvbiBnb2luZyB0aGF0IHdheS4NCj4gDQo+Pj4gSWYgdGhl IGN1c3RvbWVyIHdvdWxkIGdpdmUgdGhlIGVtZXJnZW55IHJlZ2lzdHJhciBjcmVkZW50aWFscw0K Pj4+IGNlcnQvcHJpdmF0ZS9wdWJsaWMta2V5IHRvIHRoZSBlbWVyZ2VueSBlbnRpdGllcywgdGhl biB0aGUgY3VzdG9tZXINCj4+PiBpdHNlbGYgYWxzbyBoYXMgdGhlIGNlcnQvcHJpdmF0ZS1rZXkg YW5kIGNvdWxkIGFzayB0aGUgTUFTQS4NCj4+PiBUaGlzIG9wdGlvbiB3b3VsZCB3b3JrIHdpdGgg Y3VycmVudCBCUlNLWSB0ZXh0LiBJIGFtIGp1c3Qgbm90IHN1cmUNCj4+PiBhYm91dCBzZWN1cml0 eSBCQ1AgKGhhdmluZyB0d28gY29waWVzIG9mIGEgcHVibGljIGtleSBwYWlyPz8/KS4NCj4+IA0K Pj4gU29ycnkgLSBJIGNhbj8/P3Qgd3JpdGUgdGV4dCBhcm91bmQgY29weWluZyBhIHByaXZhdGUg a2V5LiBJZiB3ZT8/P3JlIGdvaW5nIHRoYXQgcm91dGUgbGV0cyBkdW1wIGFsbCB0aGUgUEtJIHN0 dWZmIGFuZCBqdXN0IHVzZSBiZWFyZXIgdG9rZW5zIGFuZCBiZSB1cCBmcm9udCBhYm91dCB0aGUg c2VjdXJpdHkgd2U/Pz9yZSBwcm92aWRpbmcuIFNlZSBhYm92ZSBmb3IgZGlmZmVyZW50IGlkZWFz LiANCj4gDQo+IFllcHAuIFRoZXJlIHNob3VsZCBiZSBlYXNpZXIgb3B0aW9ucyB0byBhY2hpZXZl IHRoZSBzYW1lIGdvYWwuDQo+IA0KPiBFZzogSSBjcmVhdGUgYSByZWdpc3RyYXIgYXMgYSBWTSwg YW5kIHJ1biBpdCBvbnByZW0gb2YgdGhlDQo+IGRlc2FzdGVyIHJlY292ZXJ5IHByb3ZpZGVyIHNv IHRoYXQgcHJvdmlkZXIgY2FuIGVucm9sbCBkZXZpY2VzDQo+IGZvciBteSBkb21haW4gaW4gY2Fz ZSB0aGVyZSBpcyBhIGRlc2FzdGVyIGluIG15IGRvbWFpbi4NCg0KSSBzdWdnZXN0IHdlIGFkZCB0 aGlzIHN0dWZmIHRvIGEgZGlzYXN0ZXIgcmVjb3Zlcnkgc2VjdGlvbiDigJxiZXN0IGNvbW1vbiBw cmFjdGljZeKAnSBldGMgYW5kIHNlZSBob3cgaXQgbG9va3MgaW4gYmxhY2sgYW5kIHdoaXRlLiAo T3Igd2hhdGV2ZXIgeW91ciBtb25pdG9yIGNvbG9ycyBhcmUpLiANCg0KPiANCj4+PiAtIElmIHRo ZSBzaGFyZWQgc3BhcmUgc3RvcmFnZSBmYWNpbGl0eSBpcyBCZXN0IEJ1eSwgYW5kIHRoZSBKb25l cw0KPj4+IGZhbWlseSB3YW50cyB0byByZXBsYWNlIHNvbWUgZWxlY3RyaWMgc3Rvcm0gdmljdGlt cyBAaG9tZSB3aGlsZQ0KPj4+IHRoZWlyIElTUCB0YWtlcyBpdHMgZGF5cyAobXkgSVNQIEMqLi4u KlQgdG9vayBhbG1vc3QgNDggaG91cnMgaW4gb25lIGNhc2UpLA0KPj4+IHRoZW4gdGhlIGdlYXIg c2hvdWxkIHByb2JhYmx5IGNvbWUgd2l0aCBhIG5vbmNlbGVzcyB2b3VjaGVyDQo+Pj4gcHJpbnRl ZCBvbiBvbiBhIHNjcmF0Y2hlciBwaWVjZSBvZiBwYXBlciBpbnNpZGUgdGhlIGJveC4NCj4+IA0K Pj4gRXZlbiBhIG5vbmNlbGVzcyB2b3VjaGVyIGluY2x1ZGVzIHRoZSBkb21haW5DQWNlcnQgc28g dGhpcyBpZGVhIGRvZXNuPz8/dCBmbHkgd2l0aCB0aGUgY3VycmVudCB0ZXh0LiBXaGF0IHlvdT8/ P3JlIGxvb2tpbmcgZm9yIGlzIHNvbWUgZm9ybSBvZiA/Pz9iZWFyZXIgdm91Y2hlcj8/PyB0aGF0 IGNvbnRhaW5zIGEgc3ltbWV0cmljIGtleS4NCj4gDQo+IFByb2JhYmx5LiBZZXMuIEkgZ3Vlc3Mg d2UgaGF2ZSBub3QgZGlzY3Vzc2VkIGhvdyB0byBhcHBseSBCUlNLWQ0KPiBlbnJvbGxtZW50IGZv ciBob21lIHVzZXJzLiBJdCdzIG91dHNpZGUgb2Ygc2NvcGUgZm9yIEFOSU1BIGFueWhvdywNCj4g YnV0IHdvdWxkIGJlIGludGVyZXN0aW5nLiBTb21lIG9mIHRob3NlIGhvbWUgdGhvdWdodHMgbGlr ZWx5IGVxdWFsbHkNCj4gYXBwbHkgdG8gbG93LWVuZCBJb1QgZGV2aWNlcy4NCj4gDQo+PiBBbnli b2R5IHdobyBjYW4gc2NhbiBpdCBvZmYgdGhlIGJveCBjYW4gZGVwbG95IHRoZSBkZXZpY2UuIA0K PiANCj4gVGhhdHMgd2h5IGkgc2FpZCAic2NyYXRjaGVyIiwgZWc6IHNvbWUgb25lLXRpbWUtdW52 ZWlsIHdoZXJlIHlvdQ0KPiBjYW4gZWFzaWx5IGNoZWNrIHRoYXQgaXRzIHVudGFtcGVyZWQgd2hl biB5b3UgYnV5IHRoZSBkZXZpY2UuIA0KPiANCj4+IEk/Pz9kIG5vcm1hbGx5IHJhaWwgYWdhaW5z dCB0aGlzIGJ1dCBhbSBhY3R1YWxseSBwbGVhc2VkIHRvIHNlZSBpdCBmaXQgc28gd2VsbCBpbnRv IHRoZSBtb2RlbC4gQSBiZWFyZXIgdm91Y2hlciBzb3J0YSBzdWNrcyBidXQgY3JlYXRpbmcgb25l IGRpZG4/Pz90IGNoYW5nZSBhbnkgb2Ygb3VyIG1lc3NhZ2luZyBmbG93IG9yIGFueXRoaW5nLiBJ bnRlcmVzdGluZyBwb3NpdGl2ZSB0aGF0Pz8/IA0KPiANCj4+IEk/Pz9tIHRoaW5raW5nIHRoYXQg aXQgaXMgdGltZSBmb3IgYSBzZWN0aW9uIDMuNyA/Pz9Wb3VjaGVyIHR5cGVzPz8/IHRoYXQgZGln cyBpbnRvIHdoYXQgd2U/Pz9yZSB0YWxraW5nIGFib3V0IGZvciB0aGVzZSBkaWZmZXJlbnQgdm91 Y2hlciB0eXBlcy4gQ3VycmVudGx5IHRoZSB0ZXh0IGlzIHNjYXR0ZXJlZCBpbiB0aGUgb3RoZXIg c2VjdGlvbnMuIA0KPiANCj4gV2UgY291bGQgYWxzbyBzdGFydCBkaXNjdXNzaW5nIHRob3NlIGFz cGVjdHMgaW4gdGhlIHN1Ym1pc3Npb24gZnJvbQ0KPiBLZW50IGV0LiBhbC4gYWJvdXQgdm91Y2hl cnMgYW5kIG1vdmUgaW50byBCUlNLWSB3aGVuIHdlIHNlZSBpdCBmaXQuDQoNCkFuZCBub3cgdGhh dCBNaWNoYWVsIGJyb3VnaHQgaXQgdXAgYXMgYW4gaXNzdWUgaW4gdGhlIHNsaWRlcyBhdCBpZXRm OTcgd2UgbWlnaHQgYXMgd2VsbCBkZWFsIHdpdGggaXQuIDopIA0KDQotIG1heA0KDQo+IA0KPiBD aGVlcnMNCj4gICAgVG9lcmxlc3MNCj4gDQo+PiAtIG1heA0KPj4gDQo+Pj4gQmV5b25kIHRoZXNl IEJSU0tZIGNvbnNpZGVyYXRpb25zLCB0aGUgbmV4dCBjb29sIEFOSU1BIHBpZWNlIHRvIGNvbnNp ZGVyDQo+Pj4gZm9yIHRoZXNlIHVzZS1jYXNlcyBpcyBvZiBjb3Vyc2UgdGhlIEFTQSBkcml2ZW4g InJlLWNvbmZpZ3VyYXRpb24iIG9mIHRoZQ0KPj4+IHNwYXJlIGRldmljZSwgYWthOiBJbiBsYXJn ZXIgb3V0YWdlcywgeW91IHNob3VsZCBub3QgZXhjZXB0IHRoZSB3aG9sZQ0KPj4+IG5ldHdvcmsg cHJvdmlzaW9uaW5nIGJhY2tlbmQgdG8gYmUgdXAgYW5kIHJ1bm5pbmcuIEFuZCBpdHMgSU1ITw0K Pj4+IGlsbHVzaW9uYXJ5IHRvIGV4cGVjdCBkZXZpY2VzIHRvIE9OTFkgYmUgZHJpdmVuIGZyb20g aW50ZW50IGZvciBtYW55DQo+Pj4geWVhcnMgKGluIGNvbXBsZXggbmV0d29ya3MuLi4gaW4gYSBj bGVhbiBob21lbmV0IHRoZXkgYXJlIGRyaXZlbiBieQ0KPj4+IGludGVudCB0b2RheS4uKS4gDQo+ Pj4gDQo+Pj4gQWthOiBmb3IgcHJlLWludGVudC1vbmx5IGRlc2FzdGVyIHByb29mIG5ldHdvcmtz LCB3ZSdkIG5lZWQ6DQo+Pj4gLSBBU0EgdG8gY2FjaGUgbmVpZ2hib3JzIGNvbmZpZ3MuDQo+Pj4g LSByZWFwcGx5IG5laWdoYm9yIHN0b3JlZCBjb25maWcgd2hlbiByZXBsYWNlbWVudCBnZWFyIGlz IGluc2VydGVkLg0KPj4+IC0gSU1ITzogQW4gYW5pbWEgZGVmaW5pdGlvbiBmb3IgYSAiZGV2aWNl LXJvbGUtaWQiIHdoaWNoIGlzIG5vdA0KPj4+ICAgdGhlIEFDUCBJUHY2IGFkZHJlc3MgKHdoaWNo IHdpbGwgY2hhbmdlIHVwb24gZ2VhciByZXBsYWNlbWVudA0KPj4+ICAgd2l0aG91dCBlbnJvbG1l bnQgc3VwcG9ydCkuDQo+Pj4gDQo+Pj4gQ2hlZXJzDQo+Pj4gICB0b2VybGVzcw0KPj4gDQoNCg== From nobody Wed Nov 16 17:19:40 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F7B129875; Wed, 16 Nov 2016 17:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 0_MXvQKTWiQM; Wed, 16 Nov 2016 17:19:11 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB46A129851; Wed, 16 Nov 2016 17:19:11 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 16 Nov 2016 17:19:08 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 16 Nov 2016 17:19:08 -0800 From: Terry Manderson To: Sheng Jiang , Michael Richardson , "anima@ietf.org" , "netconf@ietf.org" Thread-Topic: [Anima] voucher presentation Thread-Index: AQHSP8poJb1Lhnt8Q0mM59Ak79zJM6Dcw2UAgADL8wA= Date: Thu, 17 Nov 2016 01:19:07 +0000 Message-ID: References: <48BBDF02-F7C3-426D-901F-699A6D9643DF@juniper.net> <5D36713D8A4E7348A7E10DF7437A4B927CC61100@NKGEML515-MBX.china.huawei.com> <20161115232222.GO9776@faui40p.informatik.uni-erlangen.de> <2A2BAEFB-8F9A-404F-BFAD-805EB7DFC947@juniper.net> <20161116001700.GS9776@faui40p.informatik.uni-erlangen.de> <5D36713D8A4E7348A7E10DF7437A4B927CC61212@NKGEML515-MBX.china.huawei.com> <2023.1479274148@dooku.sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B927CC6378C@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CC6378C@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3562226346_1091858464" MIME-Version: 1.0 Archived-At: Cc: Benoit Claise Subject: Re: [Anima] voucher presentation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:19:13 -0000 --B_3562226346_1091858464 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I'm comfortable in the WG considering this as a WG document if that is the consensus of the WG and I think that can be done on-list and not wait until chicago. The corollary to that is cross WG review is a must have due to the significant YANG content in the document. Further if this document is accepted as a WG document I would very much like a non-chair document shepherd assigned at adoption to ensure that the appropriate reviews happen. It might be worth flagging it to the WG in the Chair's session intro to the folks in the room as a 'watch this space' item. Cheers Terry On 17/11/2016, 9:09 AM, "Anima on behalf of Sheng Jiang" wrote: Hi, Michael R, We have a full agenda for Friday session. Since you do not apply a time slot, I don't think I have any spare time could allocate. I am not sure how you want to have the content for this document. If you want to integrate it into bootstrap document, it is simple straight forward. But, if you want to process it as an independent document, we need to consultant our AD. Let's do it offline. Sheng ________________________________________ From: Anima [anima-bounces@ietf.org] on behalf of Michael Richardson [mcr+ietf@sandelman.ca] Sent: 16 November 2016 13:29 To: anima@ietf.org; netconf@ietf.org Cc: Benoit Claise; Terry Manderson Subject: Re: [Anima] voucher presentation Sheng, I think we need some time in the next session to discuss where we are going to with draft-kwatsen-netconf-voucher, unless we can resolve this by email. We had said that we thought it was all up to Benoit, since he was the AD for both groups, but I just looked up and noticed that ANIMA is being handled by Terry, not Benoit :-) This document will also be used by 6tisch, btw. None of the authors care where the work is done; each of the groups would have to do the work themselves if it didn't happen elsewhere. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima --B_3562226346_1091858464 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEBq iIy+ryx7KUU7tl5QY+O2itmfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE2MTExNzAxMTkwNlowDQYJKoZIhvcNAQEBBQAEggEAD4UonPGfDd49sjsmxmBB 82tdJeDUKsJsYm6Nj2iL9FVohUy5IPEhu5Ff2fPfb0Mt8V7EFQNG9HPhcFM7xbGp9qBWdT56 KuF4aCUlFZMV737BvzSSVkTe6Ad0U8lqbmxPsnR3Q2FWZ2pqpP2NaLgeWpVVQUanATf98Knw v5iXIolUGiamgKPwxyb9m4Ns3YCMYNnHq6Yeca+kLcdswCOh9UnGONF4WaY/rgzbKcwmXGXI 73VB+f49gBNWzqumjIkgmzsWUiuhO1IQUc0N9hcXTKo3CEikJKfs9+9tCHCPZnKY7PHmRzTy I439qm5Uvi+W+C8Ql3t6O1nl5HGm1LgXRg== --B_3562226346_1091858464-- From nobody Wed Nov 16 23:32:59 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E932D1295AE; Wed, 16 Nov 2016 23:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywoi7qDk2waE; Wed, 16 Nov 2016 23:32:55 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826E5129507; Wed, 16 Nov 2016 23:32:55 -0800 (PST) Received: from dooku.sandelman.ca (s2001067c037001280a1196fffe0181e0.v6.meeting.ietf.org [IPv6:2001:67c:370:128:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 296CA1F8F0; Thu, 17 Nov 2016 07:32:54 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 9FD2233EB; Thu, 17 Nov 2016 16:32:46 +0900 (KST) From: Michael Richardson To: "anima\@ietf.org" , "netconf\@ietf.org" , Benoit Claise , Terry Manderson In-reply-to: <5D36713D8A4E7348A7E10DF7437A4B927CC6378C@NKGEML515-MBX.china.huawei.com> References: <48BBDF02-F7C3-426D-901F-699A6D9643DF@juniper.net> <5D36713D8A4E7348A7E10DF7437A4B927CC61100@NKGEML515-MBX.china.huawei.com> <20161115232222.GO9776@faui40p.informatik.uni-erlangen.de> <2A2BAEFB-8F9A-404F-BFAD-805EB7DFC947@juniper.net>, <20161116001700.GS9776@faui40p.informatik.uni-erlangen.de> <5D36713D8A4E7348A7E10DF7437A4B927CC61212@NKGEML515-MBX.china.huawei.com>, <2023.1479274148@dooku.sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B927CC6378C@NKGEML515-MBX.china.huawei.com> Comments: In-reply-to Sheng Jiang message dated "Wed, 16 Nov 2016 23:09:08 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 17 Nov 2016 16:32:46 +0900 Message-ID: <2263.1479367966@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] voucher presentation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 07:32:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sheng Jiang wrote: > We have a full agenda for Friday session. Since you do not apply a ti= me > slot, I don't think I have any spare time could allocate. okay, I thought we might have some open mic time, because this really wants= discussion. > I am not sure how you want to have the content for this document. If > you want to integrate it into bootstrap document, it is simple straig= ht > forward. But, if you want to process it as an independent document, we > need to consultant our AD. Let's do it offline. And Terry says: Terry Manderson wrote: > I'm comfortable in the WG considering this as a WG document if that is > the consensus of the WG and I think that can be done on-list and not > wait until chicago. The corollary to that is cross WG review is a must > have due to the significant YANG content in the document. Further if > this document is accepted as a WG document I would very much like a > non-chair document shepherd assigned at adoption to ensure that the > appropriate reviews happen. Benoit, do you feel the same? Again, we don't care where we do it. We know it's going to at least Max, Ke= nt and I. It makes no sense to do it three times, so we'll have one document for 6tisch, ANIMA and NETCONF. Based upon this, we'll probably ask the chairs for a document adoption call in January. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYLV0eAAoJEJVM4Vb9/EKQu5IH/1KCLnzgIqWJtx7CTdwNPVru ca+RjfCmn8LrJkwiu4DyF2kUQo1oVrjqUES1opWHGg3Q0DMoksUDn0GyThhbd+Eh 0bhgHbJ3jDbDYWR3AiTtIhgiZZ+m5YKV1pldanuj9cjz8D8ZWRyqk8f7mEUVz5Ul woyGdQxtw5qSRwUf1unf2+jlnkH/S7ATbIrGMlcFcS5OZKJ7ngwHom/oAsIGOC8Y z4SIuSEU8nM3azMCtEbEUajMGp7aeJT5ZRJHaXRSSQe8jqExFx8GJf0Bs9Blg++i rYVNbNKuwpAJzECA9iQhQfcTuYF1VipONVy44ORq52ZuCsQsW9Kn+7KOuEYQPB4= =E7Z3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 17 02:11:03 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84F2129874 for ; Thu, 17 Nov 2016 02:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHpeMfttlrUT for ; Thu, 17 Nov 2016 02:11:00 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D46712987B for ; Thu, 17 Nov 2016 02:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2064; q=dns/txt; s=iport; t=1479377460; x=1480587060; h=to:from:subject:cc:message-id:date:mime-version; bh=9bBgmWloWAxTiZM7YvHh50v5yA5uWXOv0ojuA8AmHXg=; b=QmGcphw9mBujWR6c9bhcmlky1/PiKMMK7scsiyL4NzLNgvGttoLy6Mvz 146b+oIcGKlE01cS0cI4fs6bsbdJpgug8AsITtHoytWck99XGJnl4T6p6 OFDAGBYoUm4MpiK1eq0+xH89JjN+OnIvrg9XBJ2AlDvRHosDSfzWdQ7WP M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzBgAjgS1Y/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAXopjhOpY4IOggeGIYJiFAECAQEBAQEBAWIohGoEJFYFWAJ?= =?us-ascii?q?sCAEBiGAIrWKCKYtiIw6IOQiHaoI4gl0FmkKDUoF6ix4CgViIKIYikVoeN24RD?= =?us-ascii?q?IU8PYhaAQEB?= X-IronPort-AV: E=Sophos;i="5.31,653,1473120000"; d="asc'?scan'208";a="648180936" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2016 10:10:58 +0000 Received: from [10.61.192.63] ([10.61.192.63]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uAHAAv0q012878; Thu, 17 Nov 2016 10:10:57 GMT To: draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org From: Eliot Lear Message-ID: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> Date: Thu, 17 Nov 2016 11:10:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xB3Mqag1MqEbx5IG77EhoiaPePL8spix9" Archived-At: Cc: Anima WG Subject: [Anima] additional information and JSON/CBOR X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 10:11:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xB3Mqag1MqEbx5IG77EhoiaPePL8spix9 Content-Type: multipart/mixed; boundary="r2THvEQFERhAt6PRSd3htpMo80aG62LEA"; protected-headers="v1" From: Eliot Lear To: draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org Cc: Anima WG Message-ID: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> Subject: additional information and JSON/CBOR --r2THvEQFERhAt6PRSd3htpMo80aG62LEA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi authors, The Fairhair folk would like some clarity on the following statement in Section 3.1.7: > Functionality to provide generic "configuration" information is > supported. The parsing of this data and any subsequent use of the > data, for example communications with a Network Management System is= > out of scope but is expected to occur after bootstrapping enrollment= > is complete. Many of us this, but we need to know how to hook in. Specifically we're aiming to provide the address of the resource directory, preferably in a way that is signed by the registrar. Also, we're wondering what effort it would be to move to CBOR for transactions. Eliot --r2THvEQFERhAt6PRSd3htpMo80aG62LEA-- --xB3Mqag1MqEbx5IG77EhoiaPePL8spix9 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 iQEcBAEBCAAGBQJYLYIxAAoJEIe2a0bZ0noz6SUIANEAle3XWDJ4zH77elK4OQtn UvWsFC4LGsonJXcKOzlmxS/2SCOnu5ViGBGEVFnpSB0VnZxeuaiTQTvvdkAm5c2X ahlrSwyTFel+QPmcidvIcr3bEn0KQiamuVGNzrCTAhEi6QRVcrZV2PIibJT6X3Ov vOQFfMR2xNqGyX0xa+D7LbZ2DDh1lUNiZew5DPVb6ubSWH4q6yG9wjQ9bAyOYMpO v/hxd/P6IIn8OD+gmU2lnkBLAFBx06b47OypDPrxsbEe/0uzP59lIWyTbzZT95o1 g3qI1gJdAkerRX9xd5fr/TZopCnQe7E+vKkwIXNq5BwiV7NMfjVAqUGd7+82z08= =j+f4 -----END PGP SIGNATURE----- --xB3Mqag1MqEbx5IG77EhoiaPePL8spix9-- From nobody Thu Nov 17 02:11:51 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A41129871 for ; Thu, 17 Nov 2016 02:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_cQ8ycjvCSp for ; Thu, 17 Nov 2016 02:11:49 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582271297BC for ; Thu, 17 Nov 2016 02:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4768; q=dns/txt; s=iport; t=1479377508; x=1480587108; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=nmq/VgziNmN6ojeAyVNCLGkP3hwqk/+SdUM4s+5W1CA=; b=N4DC9LOKDwRuK7IVndeQK3hNXFbM4TRTRK0pw+G5VYefgEN5XlnRtw7g dTkup/GqBQS7W/ABs1pyjidvAB+D+No/sLdiVAYGwIEHQucdhFTtNFN0L 5IjmJn762jDrdaNAoxzP1KcayO0YCZcn5QSZK0vWj+o4th3wLWskH7civ A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjBADXgS1Y/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXcDKVSNP5cOj0iFG4IHHQEKhXkCgmAUAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQMBAQEBIEsLBQsLBBQqAgInMBMGAgEBiGAIDq1YgikvizMBAQEBA?= =?us-ascii?q?QEBAQIBAQEBAQEBAQEQCQWIOYJdhRWCOIJdBZpCg1KBeoseigKGIpFaHjduEQw?= =?us-ascii?q?dhR89NIgmAQEB?= X-IronPort-AV: E=Sophos;i="5.31,653,1473120000"; d="asc'?scan'208,217";a="650000081" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2016 10:11:46 +0000 Received: from [10.61.192.63] ([10.61.192.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAHABjP2016508; Thu, 17 Nov 2016 10:11:46 GMT To: draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org References: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> From: Eliot Lear Message-ID: <9f37a834-3f9f-fda8-447d-9aab8ddee0a4@cisco.com> Date: Thu, 17 Nov 2016 11:11:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i3hWGBl9BxSpX1c12bLRlu5tekfeE9ek0" Archived-At: Cc: Anima WG Subject: Re: [Anima] additional information and JSON/CBOR X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 10:11:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i3hWGBl9BxSpX1c12bLRlu5tekfeE9ek0 Content-Type: multipart/mixed; boundary="JsH42bRgHcMIWdiJnHE3l22OnuK7QOoh5"; protected-headers="v1" From: Eliot Lear To: draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org Cc: Anima WG Message-ID: <9f37a834-3f9f-fda8-447d-9aab8ddee0a4@cisco.com> Subject: Re: [Anima] additional information and JSON/CBOR References: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> In-Reply-To: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> --JsH42bRgHcMIWdiJnHE3l22OnuK7QOoh5 Content-Type: multipart/alternative; boundary="------------D376CBC0894258DD67B02A0C" This is a multi-part message in MIME format. --------------D376CBC0894258DD67B02A0C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/17/16 11:10 AM, Eliot Lear wrote: > Hi authors, > > The Fairhair folk would like some clarity on the following statement in= > Section 3.1.7: > >> Functionality to provide generic "configuration" information is >> supported. The parsing of this data and any subsequent use of the >> data, for example communications with a Network Management System i= s >> out of scope but is expected to occur after bootstrapping enrollmen= t >> is complete. > > Many of us this,=20 Sorry- word missing is "like". Eliot > but we need to know how to hook in. Specifically we're > aiming to provide the address of the resource directory, preferably in = a > way that is signed by the registrar. > > Also, we're wondering what effort it would be to move to CBOR for > transactions. > > Eliot > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------D376CBC0894258DD67B02A0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 11/17/16 11:10 AM, Eliot Lear wrote= :
Hi authors,

The Fairhair folk would like some clarity on the following statement in
Section 3.1.7:


   Functionality to provide generic "configuration=
" information is
   supported.  The parsing of this data and any subsequent use of the
   data, for example communications with a Network Management System is
   out of scope but is expected to occur after bootstrapping enrollment
   is complete.


Many of us this,

Sorry- word missing is "like".

Eliot

but we need to know how to hook in.  Specifically we=
're
aiming to provide the address of the resource directory, preferably in a
way that is signed by the registrar.

Also, we're wondering what effort it would be to move to CBOR for
transactions.

Eliot






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

--------------D376CBC0894258DD67B02A0C-- --JsH42bRgHcMIWdiJnHE3l22OnuK7QOoh5-- --i3hWGBl9BxSpX1c12bLRlu5tekfeE9ek0 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 iQEcBAEBCAAGBQJYLYJhAAoJEIe2a0bZ0nozN1oIAKQSW7XzMh4XMGYC7YCAmHJm wjAEBGsOp3hIMv+MUf4rdJ0YKvpnfQwlhlMWJUR62ZlSZQVj+FzP78lJ+1GE8cLN obtTS/pPghWPay05URW7Xts4Dxh8caC/0OIgVfTWwzZolPlZ4wZvCwQ2cnzmIQNt RpdmZVvNV9oV9EJTsf8EZx7zYV7eiQHm8gFwQCp5jlWs+gpoOQppHZk2HP8kxHx6 aDT/RKjxR3ktLMuZ3jGt5roITYqDnRlEqeai/Ed6kiLKm2Et+HgSBJHJioZwptC2 q1CJL97ZeqqgIMocpyBmwioP6GT43PqDuMoBWwyFQGIRXrIZCc12aXyWKv9Thjs= =AgSY -----END PGP SIGNATURE----- --i3hWGBl9BxSpX1c12bLRlu5tekfeE9ek0-- From nobody Thu Nov 17 04:31:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E9512979D for ; Thu, 17 Nov 2016 04:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 1U1I6rmdoZ-A for ; Thu, 17 Nov 2016 04:31:19 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E82129795 for ; Thu, 17 Nov 2016 04:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uAHCVCbM010551; Thu, 17 Nov 2016 13:31:12 +0100 (CET) Received: from t2001067c037001442d661b3c2636fdcf.hotel-wired.v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:144:2d66:1b3c:2636:fdcf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tKL8G3wqjz7xNK; Thu, 17 Nov 2016 13:31:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> Date: Thu, 17 Nov 2016 21:31:02 +0900 X-Mao-Original-Outgoing-Id: 501078662.69797-ce9ebd5a628c53adb4b3c0b5532cf806 Content-Transfer-Encoding: quoted-printable Message-Id: <1CCFD0A3-83EB-4E59-85A8-9A7F2867DE55@tzi.org> References: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Anima WG , draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org Subject: Re: [Anima] additional information and JSON/CBOR X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 12:31:23 -0000 On 17 Nov 2016, at 19:10, Eliot Lear wrote: >=20 > Also, we're wondering what effort it would be to move to CBOR for > transactions. Moving from JSON to CBOR is zero effort if you just do it to gain = runtime efficiency or use the better datatypes. If you want to use the last bit of on-the-wire efficiency, you also want = to replace the string-based keys (=E2=80=9CIDevIDAuthorityKeyIdentifier=E2= =80=9D) with integers (say, 7). That requires some housekeeping; i.e. = that is no longer zero-effort. (The examples in the current draft aren=E2=80=99t always really JSON, = but that can be easily fixed. I usually try to run a publishing pipeline that validates all the = examples.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Nov 17 11:45:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9FD129413 for ; Thu, 17 Nov 2016 11:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XYObsnG-D42 for ; Thu, 17 Nov 2016 11:44:58 -0800 (PST) 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 7FA42129499 for ; Thu, 17 Nov 2016 11:44:58 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id x23so91650818pgx.1 for ; Thu, 17 Nov 2016 11:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MKFs9SLdM7DuY/JFLDoTMg9qYc4NcfvdrlLYMXNZhmM=; b=Ov6xVDug1MKgMoBmKG8S2wDNxFErb2M2tCcXfkR7apMigqPZN8TrsxRfxX6eEr0Iyc fJ28diGHdb0SkR4OdItz2kJKY2y2FFSjnQDtslN69k3YAT2XDs07JtOgWHxarVoOKTIw cqCwP38lyrz8DvUgeasovS4Yu/s1BoOEgVn+XDUnMTOqQY8uzUHsmsF9MbQ7UE2yCSsW 5lhhBvYOXESkxk0tH9OS/KmEJH6SIR+KAfRsv1JLnFgXe05IA2uyFEafmCIMtDqlqVqy bD0X39ASmtzBWtlS2rU3LFouYUArH8pDmXnzDQ54d8/2HgGjLPMHI0QgwD65BdXAb6OU Ifhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=MKFs9SLdM7DuY/JFLDoTMg9qYc4NcfvdrlLYMXNZhmM=; b=YUsHcQHSFvtGyXXz82eENt7wJHyT5sg8aQmzm3zdONbxt6WBxeflxwuk8xCLPUP2wT ahxHQBPYNMaEo51nYWXltWwNtOTTcrxhFJtzlnTO1OBGZbplUJ0Gw471XenIYrNPcEaX 87kE0qKUqKMgEyGs+vIIDH/mbvZLEnrPlpyLrzLuvzGbFTItwpi5HUP6JwxHWbnwoXDF fbi+9qfA4XC63Orv4hOAnQEX/dmqSc7yrUshhLyjKl2LCMXeJxYFKRgabJLK6Ru3dfKE qE8cwuIw4PLyMDB7b4//cQULJOQBXgDNZr53MpFiW645HZL6ty50D30R+Miqw/RvDhKZ Zp0g== X-Gm-Message-State: ABUngvfHv3IJFCrvOYGvxnKUmER4dLTrLI/qpvxKJh2bCftLUNRWw/Ti1pTV+dFslsKb7A== X-Received: by 10.99.106.200 with SMTP id f191mr10638476pgc.143.1479411897686; Thu, 17 Nov 2016 11:44:57 -0800 (PST) Received: from [192.168.178.23] (117.228.69.111.dynamic.snap.net.nz. [111.69.228.117]) by smtp.gmail.com with ESMTPSA id 65sm10175574pfn.12.2016.11.17.11.44.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 11:44:57 -0800 (PST) To: Anima WG References: <147941174845.1634.18190691129736165522.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <42f5a85a-78ac-668d-83cd-51ece6ac27f7@gmail.com> Date: Fri, 18 Nov 2016 08:45:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147941174845.1634.18190691129736165522.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 19:45:00 -0000 A bit last minute but if you have a chance to look at this today, please do so. It attempts to make some important details more precise. Note: This draft is posted to allow systematic discussion of the various objectives in a consistent way. It is quite probable that rather than this being published as an RFC, the various objective definitions will be incorporated directly in the relevant specifications. Regards Brian Carpenter On 18/11/2016 08:42, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Technical Objectives for the Autonomic Network Infrastructure > Authors : Brian Carpenter > Bing Liu > Filename : draft-carpenter-anima-ani-objectives-00.txt > Pages : 10 > Date : 2016-11-17 > > Abstract: > This document defines several technical objectives for the Generic > Autonomic Signaling Protocol (GRASP) for use by components of the > Autonomic Networking Infrastructure outlined in the ANIMA reference > model. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-ani-objectives/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu Nov 17 14:18:02 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818891295A5 for ; Thu, 17 Nov 2016 14:18:00 -0800 (PST) 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, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 RK-39rucAbs1 for ; Thu, 17 Nov 2016 14:17:57 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23DD12947E for ; Thu, 17 Nov 2016 14:17:52 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 319F658C4B0; Thu, 17 Nov 2016 23:17:51 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 186FFB0AE76; Thu, 17 Nov 2016 23:17:50 +0100 (CET) Date: Thu, 17 Nov 2016 23:17:50 +0100 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20161117221750.GA23347@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:18:00 -0000 Thanks Brian & Bing Inline > This document defines several technical objectives for use with for ^^^^^^^^^^^^^^^^^^^^ > the Generic Autonomic Signaling Protocol (GRASP) > [I-D.ietf-anima-grasp]. Given how GRASP defines the term "objective" very specific, it would be good to either say "GRASP objectives" if that's what you meant to say, or rephrase to avoid the word and resulting confusion. GRASP is used by several autonomic service functions for signaling between the ASA realising those functions - as outlined in... Or just some good upfront statment how exactly you're using the ord "objective" in this document and what different adjectives to it mean. > Autonomic Service Agents (ASAs) that realise infrastructure > components of the Autonomic Network Infrastructure (ANI) outlined in > the ANIMA reference model [I-D.ietf-anima-reference-model]. Also > other early use cases are in scope. > > Note: This draft is posted to allow systematic discussion of the > various objectives in a consistent way. It is quite probable that > rather than this being published as an RFC, the various objective > definitions will be incorporated directly in the relevant > specifications. > > The reference model identifies several infrastructure components that > will fit together to form the ANI, and early use cases for ANIMA are > also considered: early autonomic use cases beyond the ANI are considered... Not sure if you want to summarize a bit the use cases beyond naming them, if you want, here's what i'd say: > Secure Bootstrap. ANI use case: bootstrapping autonomic devices, non-ANI use case: bootstrapping non-autonomic devices. > Autonomic Control Plane (ACP). Part of the ANI, serving autonomic and non-autonomic use cases. > Stable Connectivity of Network OAM. Primarily non-autonomic as it discusses SDN management via the ACP without intent being involved (yet). > Intent Distribution. ANI use case. ... > 2. Objectives for Secure Bootstrap > > Three components are involved in the Bootstrapping Remote Secure Key ^^ insert ANI > Infrastructures (BRSKI) process described in > [I-D.ietf-anima-bootstrapping-keyinfra]: the Registrar, the Join > Assistant (or Proxy), and the Joining Node (or Pledge). Pls. get the final official word for proxy/pledge. we're carrying around too many terms and repeating them everywhere. Note: ... Bootstrapping has more functions, such as MASA and CA, but we do not foresee the need for GRASP signalling with them at this time. > The proxy > and the pledge are attached to the same link-layer and use link-local > communications only, to minimize exposure to eavesdroppers and > malicious nodes. I think this is not the right security claim to make. We do have important use-cases where the proxy MUST be remote, eg: when i attach a pledge to just an open internet connection without any prior ANI in the vicinity. And the security comparison of this setup vs. the one with L2 is kinda complex and should maybe not had in this doc. I'd suggest: Operationally, the most simple case is when proxy and pledge have a link-local connection between each other. In this case, mutual discovery and bootstrap can happen without any prior provisioning of helper information such as DHCP parameters or DNS entries through which the pledge would have to find the proxy otherwise. Instead, link-local multicast with GRASP can and will be used. > There may be multiple hops between the proxy and > the registrar. Between registrar and proxy, there can and likely will be multiple hops, but in an autonomic network, these hops will have autoconfigured ACP and GRASP forwarders between them, so this connectivity too is zero-touch like the link-local connectivity beteeen pledge and proxy. > Therefore, two different GRASP objectives are > required: one that is used over an existing secure network between the (ACP) > the registrar and the proxy, and another that is used over an > insecure link-local hop between the proxy and the pledge. The > security aspects and the corresponding limited instances of GRASP are > discussed in [I-D.ietf-anima-bootstrapping-keyinfra] and > [I-D.ietf-anima-grasp]. And i need to check ACP draft ifhow i capture that fact there as well. Especially that each ACP node needs to run a GRASP forwarder for that hop-by-hop forwarding of the GRASP flood - securely. > Note that since secure bootstrap takes place, by definition, on an > incompletely secure network, the use of any protocol needs to be kept > as simple and limited as possible. Therefore, only one GRASP message > type is used - flooding - to avoid giving away any unnecessary > information by any node involved. Suggest to move that paragraph up before the proxy/registrar text to make reading easier. > A registrar announces itself to potential proxies by use of the > "AN_registrar" objective. This is a synchronization objective > primarily intended to be flooded throughout the network using the > GRASP Flood Synchronization (M_FLOOD) message. In accordance with > the design of the Flood message, a locator consisting of a specific > IP address, IP protocol number and port number will be distributed > with the flooded objective. An example of the objective is > informally: > > ["AN_registrar", F_SYNCH, loop_count, [7, "BRSKI-TLS"]] > > The formal CDDL definition is > > registrar-objective = ["AN_registrar", F_SYNCH, loop-count, [radius, > method]] > > radius = uint ; loop-count at the source node > method = text ; name of the BRSKI method supported > > The 'radius' parameter allows a proxy that receives this message to > determine its distance in hops from the registrar, by subtracting the > received 'loop-count' from 'radius'. *rotfl* when i read the word radius i asked myself why we would do anything with the radius protocol here. Diameter is also overloaded. "sender-loop-count" would be most descriptive. Also, i would suggest to remove the informal representation and rather put the information into the comments of the formal description: sender-loop-count = uint ; loop-count at the source node ; 255 is a good default. May use smaller values ; if diameter of ACP network is known method = text ; Name of BRSKI metho supported ; eg: "BRSKI-TLS" ; Should have some pointer to where values are defined. > The 'method' parameter indicates the specific BRSKI method available > at the given locator. The initial possible values are "BRSKI-TLS" > and "BRSKI-COAP". A registrar that supports more than one method > will flood multiple versions of the "AN_registrar" objective. Just curious: If it would be possible to encode multiple methods in a single objective, why would you prefer to use different ones ? My preference for different objectives would be as follows, and maybe that's good text to have: A different objective is used for each method to most easy support the option that independent ASAs are providing the registrar function for different methods. For example, BRSKI-COAP would most likely be focussed to help enrol also non-autonomic pledges and could have a range of aspects that would make implementation in a separate ASA beneficial (eg: different scale/policies for non-autonomic pledges). Another point to mention is the timing of this, eg: Active Registrars will send this objective flood announcement periodically (whats a good periodicity ?). Proxies will discovery these messages. A proxy can be active whenever it knows one or more registrars. And then what happens when a registrar fails: - Can we describe the timeout behavior, eg: when/how will proxy learn that the registrar went away. Does a registrar ASA that is going down in a controlled fashion have a way to explicitly withdraw the objective ? I know, this text/these questions would go beyoond just defining the objective encoding, but i think it would help a lot to have this type of concise summary of the GRASP objective behavior. > 2.1. Flooding Alternative for Proxy > > A proxy announces itself to potential pledges by use of the > "AN_proxy" objective. This is a synchronization objective primarily > intended to be flooded on a single link using the GRASP Flood > Synchronization (M_FLOOD) message. In accordance with the design of > the Flood message, a locator consisting of a specific link-local IP > address, IP protocol number and port number will be distributed with > the flooded objective. An example of the objective is informally: > > ["AN_proxy", F_SYNCH, 1, "BRSKI-TLS"] > > The formal CDDL definition is > > proxy-objective = ["AN_proxy", F_SYNCH, 1, method] > method = text ; name of the BRSKI method supported > > The loop-count is fixed at 1 since this is a link-local operation. Unless we want to add this TTL forwarding detection scheme whose name i forgot. (set TTL to 255, ignore on receiver messages with lower TTL). > The 'method' parameter indicates the specific BRSKI method available > at the given locator. The initial possible values are "BRSKI-TLS" > and "BRSKI-COAP". A proxy that supports more than one method will > flood multiple versions of the "AN_proxy" objective. > > 2.2. Negotiation Alternative for Proxy > > This alternative to "AN_proxy" uses additional features of GRASP. It > requires additional complexity in the pledge, and requires the pledge > to announce its existence to any on-link eavesdroppers via a > Discovery message. It is therefore not recommended on security > grounds, but is defined here for completeness. That paragraph does not sound like the best sales pitch. And again, i am not sure if the negative security assessment you make is correct. First of all, maybe move to an appendix given how this goes beyond our MTI (Mandatory To Implement). Secondly: flooding announcements from proxies to pledges is based on security assumptions that the network info (with proxies on the edge) is well secured/protected, and that pledges are more vulnerable. Attackers wold have to become active with flood multicasts to find a pledge which would otherwise be quiet. And those attacker flood multicasts can be detected. Eg: when we'd turn it around like you describe here, attackers could just unicast answer to pledges and therefore attack the pledge with less of a visible trail (aka: a valid proxy would not necessarily see the unicast traffic between attacker and pledge). But lets turn the assumptions around: In IoT, one might be foremost concerned about the security of the infra (with the proxies). Let those pledges multicast for bootstrap help, but our proxy may GRASP respond only when it feels that's safe. For example, if the link between pledge and proxy is some IoT radio with some vendor encryption/security (like in a lot of low-power radio options), this argument might fly and make this order of signaling preferrable. > A pledge discovers a local proxy and negotiates a BRSKI method with > it by use of the "AN_join" objective. First, the pledge performs > GRASP discovery, with the loop-count set to 1 and limited to link- > local addresses. If multiple responses occur, it chooses one by an > > implementation-defined method. Then the pledge initiates GRASP > negotiation to choose a mutually acceptable BRSKI method. > > An example of the objective is informally: > > ["AN_join", F_NEG, 6, ["BRSKI-COAP","BRSKI-TLS"]] > > The formal CDDL definition is > > join-objective = ["AN_join", F_NEG, loop-count, [*method]] > method = text ; name of the BRSKI method supported > > The parties will negotiate until one side proposes a single BRSKI > method and the other side accepts. In the simplest case of immediate > acceptance, there will only be two messages (Request Negotiate and > End Negotiate). The locator (IP address, IP protocol number, port > number) used for the negotiation will be available for the subsequent > BRSKI operations, if required. > > Note that in the Discovery message, the loop count will be set to 1 > to limit discovery to the local link. In the negotiation stage, the > loop count will serve its normal purpose (limiting the negotiation to > 6 steps in the above example). > > 3. Objective for Autonomic Control Plane > > The Autonomic Control Plane (ACP) > [I-D.ietf-anima-autonomic-control-plane] constructs itself without > outside intervention. To achieve this, each node needs to identify ^^^^^^^ s/intervention/help/ ? > its link-local neighbors on all interfaces, and agree on a secure > connection method with each of them. There are at least two possible > approaches for this: a flooding mechanism, in which each node > announces itself and it security methods to its neighbors, or a > discovery and negotiation mechanism, in which each node actively > discovers its neighbors. For the moment this draft describes both > methods. > For either method, each node runs an ASA that supports the > corresponding objective. This ASA runs permanently, in order to ^^^^^^^^^^^ always when the ACP is capable and willing to connect to neighbbors > discover or detect new ACP neighbors or to remove failed neighbors. > > 3.1. Flooding Alternative Indicating a "method" for the protocol is an undesirable attack vector. Thats probably true for the BRSKI announcements as well, but i'll let Max etc. argue that point. In ACP, the ACP draft describes how the insecure GRASP signaling would only indicate AN_ACP without parameters, and then any negotiation would have to be subject to the node either just trying the methods it supports, or building a TLS connection and running GRASP inside for negotiation. I do like the flood and thats what i described in ACP draft. I would even like to see mthod being included in it, but purely for operator diagnostics. Eg: the receiving ASA MUST NOT change its behavior based on it. Eg: Have a Diag element which might be structured, and which as it's first element has the "methods" supported. I hope the diagnostics benefits outweigh the minor securitydownside it has. > 3.2. Negotiation Alternative It seems as if you have no section for the TLS secured negotiation for the ACP channel. Why do you not simply reword this 3.2 to be exactly that ? Another question: For all those string names like for the "method", do we need registries in the IETF ? > 4. Objective for Stable Connectivity of Network OAM Nice. Let me discuss high level some steps: 1. The way i imagine it, the NOC is a bunch of services, and not specifically a single "NOC" service. So for example, each ACP node should perform syslog to a NOC syslog service. Or authenticate data-plane sessions into the ACP node (netconf, SNMP, SSH,...) via a NOC authentication service (radius/diameter,...) A bunch of these services have already defined DNS-SD service names and sometimes also service-parameters. So a simple extensible approach would be to come up with a scheme how to map DNS-SD service announcement attributes into GRASP objectives that the NOC equipment would then flood (flooding like you described for the registrar seems like the easiest scalable way when the objective is required by the mayority of ACP nodes). This way we would not have to reinvent the whole namespace of services a NOC could have, and even if we have to invent new names, it wouldn't be in a silo, but we'd pick names that are free in DNS-SD, allocate them to DNS-SD registry, and e voila: no need to maintain additional registries for it. 2. You are correct that the NOC should know about wanting to know about devices in the network. Alas, there are a bunch of things we could do, and i am not sure how we could most easily make progress. Here's roughly how i think it could look: NOC ACP-topology ASA is the entity wanting to track network topology. It would also indicate to some backend whenever new devices show up. The parameters to it's objective could indicate a lot of options: - announce yourself - always after you've connected - only when you're in "unconfigured state" - announce ACP neighbors - when they connet - when they disconnect I am not sure if the actual announcements then to this service should be done via GRASP (as a negotiation ? ) or some other protocol. Syslog comes to mind, but it has reliability problems. > 5. Objectives for Intent Distribution Except for the ACP channel protocol negotiation, all of the above is about the simple GRASP flood. Which makes me happy (because it's simple), and you probably unhappy (because it doesn't explore all the options of GRASP). So i wonder: Isn't Intent something where we would need a more intelligent use of GRASP than just good ol' flood ? Aka: If we had an Intent agent on every ACP node that has GRASP negotiation with each neighbor: I could modify intent on any node, and that node would negotiate with it's neighbors that it had a new version, and this is what would make that new intent flow hop-by-hop across the autonomic network via Intent ASAs. And there are tricky parts here: If the network becomes partitioned and intent gets modified on both sides and then there is a network merge again - how do you resolve the conflict. Whatever method of signaling you use. If we want to solve the problem with absolute timestamps, it seems to me as if i'd still need relative timestamps: Network i connected whole network have version I1 with originator assigned timestamp I1t. Network partitions into part A and part B. Node in part A modifies intent to I1+1 at time I1t+ta. Node in part B modifies intent to I1+1 at time I1t+tb. When network merges, the policy could be that all nodes would apply the intent that is newer. eg: lets assume intent in A was applied later. Nodes in B should be ablle to figure this out by using the relative time tracked against the last applied intent (I1/I1t). Cheers Toerless > 6. Objective for Prefix Management > > TBD > > 7. Flood Frequency > > Any ASA that floods one of the above objectives should do so at a > carefully chosen frequency. Recipient nodes may be starting up, > reconnecting, or waking up from sleep, so floods need to be refreshed > periodically. On the other hand, excessive flooding will consume > bandwidth, CPU and battery capacity throughout the network, and might > even resemble a DoS attack. A general guideline is to flood an > objective once immediately after its value is initialised or changed, > and then repeat the flood at intervals of at least 30 seconds. > Additionally, the flooding interval should be slightly jittered to > avoid synchronicity with other floods. Finally, the value of a > flooded objective should change as rarely as possible (on a timescale > of at least minutes, not seconds). > > 8. Security Considerations > > General security issues for GRASP are covered in > [I-D.ietf-anima-grasp]. Specific issues that are not mentioned above > are discussed in the referenced drafts for BRSKI, ACP, stable > connectivity and Intent. > > > > > > > > > Carpenter & Liu Expires May 22, 2017 [Page 8] > > Internet-Draft ANI GRASP Objectives November 2016 > > > 9. IANA Considerations > > IANA is requested to add the following entries to the GRASP Objective > Names Table registry created by [I-D.ietf-anima-grasp]: > AN_registrar > AN_proxy > AN_ACP > AN_NOC > AN_intent > > 10. Acknowledgements > > TBD. > > 11. References > > 11.1. Normative References > > [I-D.greevenbosch-appsawg-cbor-cddl] > Vigano, C. and H. Birkholz, "CBOR data definition language > (CDDL): a notational convention to express CBOR data > structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work > in progress), September 2016. > > [I-D.ietf-anima-grasp] > Bormann, C., Carpenter, B., and B. Liu, "A Generic > Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- > grasp-08 (work in progress), October 2016. > > 11.2. Informative References > > [I-D.du-anima-an-intent] > Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. > Behringer, "ANIMA Intent Policy and Format", draft-du- > anima-an-intent-04 (work in progress), July 2016. > > [I-D.ietf-anima-autonomic-control-plane] > Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic > Control Plane", draft-ietf-anima-autonomic-control- > plane-04 (work in progress), October 2016. > > [I-D.ietf-anima-bootstrapping-keyinfra] > Pritikin, M., Richardson, M., Behringer, M., Bjarnason, > S., and K. Watsen, "Bootstrapping Remote Secure Key > Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- > keyinfra-04 (work in progress), October 2016. > > > > > > Carpenter & Liu Expires May 22, 2017 [Page 9] > > Internet-Draft ANI GRASP Objectives November 2016 > > > [I-D.ietf-anima-reference-model] > Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., > Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A > Reference Model for Autonomic Networking", draft-ietf- > anima-reference-model-02 (work in progress), July 2016. > > [I-D.ietf-anima-stable-connectivity] > Eckert, T. and M. Behringer, "Using Autonomic Control > Plane for Stable Connectivity of Network OAM", draft-ietf- > anima-stable-connectivity-01 (work in progress), July > 2016. > > Appendix A. Change log [RFC Editor: Please remove] > > draft-carpenter-anima-ani-objectives-00, 2018-11-15: > > Initial version > > Authors' Addresses > > Brian Carpenter > Department of Computer Science > University of Auckland > PB 92019 > Auckland 1142 > New Zealand > > Email: brian.e.carpenter@gmail.com > > > Bing Liu > Huawei Technologies Co., Ltd > Q14, Huawei Campus > No.156 Beiqing Road > Hai-Dian District, Beijing 100095 > P.R. China > > Email: leo.liubing@huawei.com > > > > > > > > > > > > > > Carpenter & Liu Expires May 22, 2017 [Page 10] From nobody Thu Nov 17 14:21:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB41295A5 for ; Thu, 17 Nov 2016 14:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 Zi0TRMWG3n6e for ; Thu, 17 Nov 2016 14:21:15 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0A412947E for ; Thu, 17 Nov 2016 14:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7732; q=dns/txt; s=iport; t=1479421275; x=1480630875; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qVPZ42mF0+Lf2dYOz1ckEbwbBMcuEIPI8O07IlLFueM=; b=knMzLrXYv3l+y62h0QapNu5qqierAHc51HyFkO/+jGwDAM1GFRV9ukjR EVt4G6nmUKoegawu5OdwSVeh44bnaRGBcuNOAlLMZMU998orjQsQ8ps/+ aRHVRjimcmkFU7fPsXX5mo7fJ10h4RHUxEK/3fke6yrRDP88bPG2dwFiS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAQBsLC5Y/4UNJK1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWHAQB404lxGUZIIHHQ2FdwIaggI/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEDAQEBASAEDToLBQsCAQgYAgImAgICJQsVEAIEDgWIZAgOq0oOg?= =?us-ascii?q?RuBbD2LVQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQmHMIJdhCIRFoMELYIwBYh?= =?us-ascii?q?RkXIBhj+DD4cekCaNUIQKAR43gQsdhR5yhm2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,655,1473120000"; d="scan'208";a="349891265" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2016 22:21:14 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uAHMLEYx001659 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 22:21:14 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 16:21:14 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Thu, 17 Nov 2016 16:21:14 -0600 From: "Max Pritikin (pritikin)" To: Eliot Lear Thread-Topic: [Anima] additional information and JSON/CBOR Thread-Index: AQHSQLrrpd0iuCGf+EGso0De1SkE9aDeJO6A Date: Thu, 17 Nov 2016 22:21:13 +0000 Message-ID: <70FD3B9A-A8B0-48D9-83DB-B6A58ED0A03D@cisco.com> References: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> In-Reply-To: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.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.5] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anima WG , "draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org" Subject: Re: [Anima] additional information and JSON/CBOR X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:21:17 -0000 DQo+IE9uIE5vdiAxNywgMjAxNiwgYXQgMzoxMCBBTSwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5j b20+IHdyb3RlOg0KPiANCj4gSGkgYXV0aG9ycywNCj4gDQo+IFRoZSBGYWlyaGFpciBmb2xrIHdv dWxkIGxpa2Ugc29tZSBjbGFyaXR5IG9uIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IGluDQo+IFNl Y3Rpb24gMy4xLjc6DQo+IA0KPj4gICBGdW5jdGlvbmFsaXR5IHRvIHByb3ZpZGUgZ2VuZXJpYyAi Y29uZmlndXJhdGlvbiIgaW5mb3JtYXRpb24gaXMNCj4+ICAgc3VwcG9ydGVkLiAgVGhlIHBhcnNp bmcgb2YgdGhpcyBkYXRhIGFuZCBhbnkgc3Vic2VxdWVudCB1c2Ugb2YgdGhlDQo+PiAgIGRhdGEs IGZvciBleGFtcGxlIGNvbW11bmljYXRpb25zIHdpdGggYSBOZXR3b3JrIE1hbmFnZW1lbnQgU3lz dGVtIGlzDQo+PiAgIG91dCBvZiBzY29wZSBidXQgaXMgZXhwZWN0ZWQgdG8gb2NjdXIgYWZ0ZXIg Ym9vdHN0cmFwcGluZyBlbnJvbGxtZW50DQo+PiAgIGlzIGNvbXBsZXRlLg0KPiANCj4gDQo+IE1h bnkgb2YgdXMgW2xpa2VdIHRoaXMsIGJ1dCB3ZSBuZWVkIHRvIGtub3cgaG93IHRvIGhvb2sgaW4u ICBTcGVjaWZpY2FsbHkgd2UncmUNCj4gYWltaW5nIHRvIHByb3ZpZGUgdGhlIGFkZHJlc3Mgb2Yg dGhlIHJlc291cmNlIGRpcmVjdG9yeSwgcHJlZmVyYWJseSBpbiBhDQo+IHdheSB0aGF0IGlzIHNp Z25lZCBieSB0aGUgcmVnaXN0cmFyLg0KDQpUaGlzIGhhcyBiZWVuIGRlcmFpbGVkIGEgYml0IGJ5 IHRoZSB2b3VjaGVyIGNvbnZlcnNhdGlvbiBzbyB0aGFuayB5b3UgZm9yIGJyaW5naW5nIGl0IGJh Y2sgdXAuIA0KDQpUaGUg4oCcb3B0aW9uYWwgY29uZmlnIGluZm9ybWF0aW9u4oCdIGlzIGVudGly ZWx5IGEgcG90ZW50aWFsIHByb3RvY29sIG9wdGltaXphdGlvbiDigJQgd2hpY2ggaXMgd2h5IGl0 IGhhcyBmYWxsZW4gdG8gdGhlIHdheXNpZGUgZHVyaW5nIGFyY2hpdGVjdHVyYWwgYW5kIGFsaWdu bWVudCBkaXNjdXNzaW9ucyAoLTAyIGhhcyBzb21lIG1vcmUgaW5mbyBidXQgaXRzIG1pbm9yIHNv IGxldHMganVzdCBidWlsZCBmcm9tIC0wNCkuIA0KDQpMZXQgbWUgZXhwbGFpbiBieSB1c2luZyB0 aGUgZGlhZ3JhbSBmcm9tIC0wNCBmaWd1cmUgNjoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmEtMDQjc2VjdGlvbi01DQoo c2xpZ2h0bHkgbW9kaWZpZWQgZm9yIGNsYXJpdHkgLSBp4oCZbGwgbWFrZSB0aGVzZSBjaGFuZ2Vz IGluIHRoZSBkb2MpIA0KDQogICAgICAgICAgICAgICstLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0r ICstLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0rDQogICAgICAgICAgICAgIHwgUGxlZGdlICAgIHwg fCBDaXJjdWl0ICB8IHwgICAgICAgICAgIHwgfCAgICAgICAgICB8DQogICAgICAgICAgICAgIHwg ICAgICAgICAgIHwgfCBQcm94eSAgICB8IHwgUmVnaXN0cmFyIHwgfCBNQVNBICAgICB8DQogICAg ICAgICAgICAgIHwgICAgICAgICAgIHwgfCAgICAgICAgICB8IHwgICAgICAgICAgIHwgfCAgICAg ICAgICB8DQogICAgICAgICAgICAgICsrLS0tLS0tLS0tLSsgKy0tKy0tLS0tLS0rICstLS0tLSst LS0tLSsgKy0tLS0tLS0tKy0rDQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAvcmVxdWVzdHZvdWNoZXJ8DQogICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgfCAgKG5vbmNlICAgICAgICstLS0tLS0tLS0tLS0tLS0t Pg0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgIHVua25vd24pICAgICA8LS0tLS0t LS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCAvcmVxdWVzdGxvZyAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tPg0KICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAg IHwgICBUTFMgaGVsbG8gICB8ICBUTFMgaGVsbG8gICAgfCAgICAgICAgICAgICAgICB8DQogICBF c3RhYmxpc2ggICArLS0tLS0tLS0tLS0tLS0tQy0tLS0tLS0tLS0tLS0tLT4gICAgICAgICAgICAg ICAgfA0KICAgVExTICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgIHwNCiAgIGNvbm5lY3Rpb24gIHwgICAgICAgICAgICAgICB8IFNlcnZlciBD ZXJ0ICAgfCAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0t Qy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBDbGll bnQgQ2VydCAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQog ICBIVFRQIFJFU1QgICB8IFBPU1QgL3JlcXVlc3R2b3VjaGVyICAgICAgICAgIHwgICAgICAgICAg ICAgICAgfA0KICAgRGF0YSAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ub25jZS0tLS0+ ICAgKGRpc2NhcmQgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICB2b3VjaGVyICAg ICAgICAgICAgfCAgIG5vbmNlKSAgICAgICB8DQogICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAo b3B0aW9uYWwgY29uZmlnIGluZm9ybWF0aW9uKSB8ICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAuICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8 DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgLiAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgfA0KDQpIZXJlIHdlIHNob3cgdGhlIGZsb3cgd2l0aCBub25jZS1sZXNzIEF1ZGl0 IFZvdWNoZXJzLiBJIGNob3NlIHRoaXMgZmxvdyB0byBoaWdobGlnaHQgdGhhdCB0aGVyZSBpcyAq bm8qIHJlYWx0aW1lIGNvbW11bmljYXRpb25zIHdpdGggdGhlIHZlbmRvciBNQVNBIHNlcnZpY2Ug ZHVyaW5nIGFjdHVhbCBCUlNLSSBib290c3RyYXBwaW5nIHdpdGggdGhlIGNsaWVudC4NCg0KVGhl IG9wdGltaXphdGlvbiBnb2FsOiB0byBkaXN0cmlidXRlIHNvbWUgY29uZmlnIGluZm9ybWF0aW9u IHRvIHRoZSBQbGVkZ2UhDQpXaXRob3V0IG9wdGltaXphdGlvbiB0aGUgUGxlZGdlIG5lZWRzIHRv IGRpc2NvdmVyIGEgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIGF1dGhlbnRpY2F0ZSBpdCBhbmQgZG93 bmxvYWQgdGhlIGNvbmZpZyBpbmZvcm1hdGlvbiB2aWEgdGhhdCBwYXRoLiANCg0KU29tZSBwb3Rl bnRpYWwgbWV0aG9kcyBpbiBvcmRlciBvZiBpbnRlZ3JhdGVkIG9wdGltaXphdGlvbjoNCg0KUG9z c2liaWxpdHktMSkgVGhlIFJFU1QgcmVzcG9uc2UgY29udGFpbmluZyB0aGUgdm91Y2hlciBNQVkg YmUgYSBhIGNvbnRlbnQtdHlwZSBvZiAibXVsdGlwYXJ0L21peGVk4oCdIGNvbnNpc3Rpbmcgb2Yg dHdvIHBhcnRzOiBvbmUgcGFydCBpcyB0aGUgdm91Y2hlciBhbmQgdGhlIG90aGVyIHBhcnQgaXMg dGhlIGNvbmZpZyBpbmZvcm1hdGlvbi4gVGhlIFBsZWRnZSBNVVNUIGNvbXBsZXRlIHM1LjMuMSDi gJxhdXRoZW50aWNhdGlvbiBvZiB0aGUgUHJvdmlzaW9uYWwgVExTIGNvbm5lY3Rpb27igJ0gYmVm b3JlIGFjY2VwdGluZyBhbmQgcGFyc2luZyB0aGUgMm5kIHBhcnQuDQoNClBvc3NpYmlsaXR5LTIp IFNhbWUgYXMgUkVTVCByZXNwb25zZSAjMSBleGNlcHQgdGhhdCB0aGUgc2Vjb25kIHBhcnQg4oCc TVVTVCBiZSBhIHNpZ25lZCBtc2cgd2l0aGluIHRoZSBQS0kgaGllcmFyY2h5IG9mIHRoZSBkb21h aW4gYXMgZXN0YWJsaXNoZWQgYnkgdGhlIFZvdWNoZXLigJ0uICANCg0KUG9zc2liaWxpdHktMykg SW50cm9kdWNlIGEgZm9sbG93dXAgUkVTVCBtZXNzYWdlIHRoYXQgdGhlIFBsZWRnZSBNQVkgdXNl IHRvIG9idGFpbiB0aGUgY29uZmlndXJhdGlvbiBhZnRlciBzNS4zLjEgaXMgY29tcGxldGUuIFRo aXMgYWxsb3dzIHRoZSBUTFMgY29ubmVjdGlvbiB0byBiZSBtYWludGFpbmVkIGFuZCBvcHRpbWl6 ZXMgdGhlIGZsb3cgYnV0IGtlZXBzIHRoZSBkaXN0aW5jdCBSRVNUIGFwaSBjYWxscyBmcm9tIGJl aW5nIG92ZXJsb2FkZWQuIEl0IGlzIG1vc3QgY29uc2lzdGVudCB3aXRoIHNlY3Rpb24gNS43IGFu ZCBpcyBwcm9iYWJseSB0aGUgYXBwcm9hY2ggSeKAmWQgcHJlZmVyLiBVc2luZyBwZXJzaXN0ZW50 IGNvbm5lY3Rpb25zIHRoaXMgaXMgY2xvc2UgdG8gdGhlIG9wdGltaXphdGlvbiBwcm92aWRlZCBi eSAxIG9yIDIgYW5kIGFsbG93cyBmb3Igc2ltcGxlciBoYW5kbGluZyBvbiB0aGUgUGxlZGdlLiAN Cg0KSXQgd291bGQgbm90IGJlIGZhaXIgdG8gZGlzY3VzcyB0aGlzIHdpdGhvdXQgdG91Y2hpbmcg b24gaG93IG5ldGNvbmYgemVyby10b3VjaCBkcmFmdCBhZGRyZXNzZXMgdGhpcyBpc3N1ZS4gVGhl IGRhdGEgc3RydWN0dXJlIHVzZWQgaW4gZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3VjaC0wOSBp cyBjYWxsZWQg4oCcYm9vc3RyYXAtaW5mb3JtYXRpb27igJ0gYW5kIGl0IGNvbnRhaW5zIGFuIG9w dGlvbmFsIOKAnGNvbmZpZ3VyYXRpb27igJ0uIFRoaXMgaXMgdGhlIGVxdWl2YWxlbnQgZGF0YS4g SG93IGl0IGlzIHByb3RlY3RlZCBpcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiA2LjQgYW5kIGNhbiBi ZSBzdW1tYXJpemVkIGFzIGEgc2ltaWxhciBmbG93OiBhdXRoZW50aWNhdGUgdGhlIHZvdWNoZXIs IHRoZW4gdXNlIHRoZSB2b3VjaGVyIGluZm9ybWF0aW9uIHRvIGF1dGhlbnRpY2F0ZSB0aGUgc2ln bmVkIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uIFNlY3Rpb24gNi4zIGFwcGVhcnMgdG8gY292 ZXIgdGhlIGlkZWEgdGhhdCB0aGUgYm9vdHN0cmFwPWluZm9ybWF0aW9uIG1pZ2h0IG5vdCBiZSBz aWduZWQgYWx0aG91Z2ggaXQgaXNu4oCZdCBjbGVhciBpZiB0aGUgYXV0aGVudGljYXRlZCBpZGVu dGl0eSBvZiB0aGUgYm9vdHN0cmFwLXNlcnZlciBpcyB1c2VkIGZvciB0aGUg4oCcQWJsZSB0byBi b290c3RyYXAgb2ZmIGFueSBzb3VyY2XigJ0gY29uZGl0aW9uYWwgb3IgaWYgaXQgc2ltcGx5IGZh aWxzIG9wZW4uIFJlZ2FyZGxlc3MgdGhlIHNpbWlsYXJpdGllcyB0byB0aGUgYWJvdmUgZGlzY3Vz c2lvbiBzaG91bGQgYmUgY2xlYXIuIA0KDQotIG1heA0KDQo+IA0KPiBBbHNvLCB3ZSdyZSB3b25k ZXJpbmcgd2hhdCBlZmZvcnQgaXQgd291bGQgYmUgdG8gbW92ZSB0byBDQk9SIGZvcg0KPiB0cmFu c2FjdGlvbnMuDQo+IA0KPiBFbGlvdA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5p bWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmlt YQ0KDQo= From nobody Thu Nov 17 14:54:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ACB1294F4 for ; Thu, 17 Nov 2016 14:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G95WF90EOKqO for ; Thu, 17 Nov 2016 14:54:36 -0800 (PST) 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 5E535129474 for ; Thu, 17 Nov 2016 14:54:35 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id f188so95555226pgc.3 for ; Thu, 17 Nov 2016 14:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=z7uh3am6HtAykyhN/yrNQVLN2hJ996kbXHrbljvg+Bg=; b=FCOXoyymzzGvXQgAO/cOyAy2xtuOzFUzwyRoLGKt/ylB+oMEEg5KfI/SA6yqbVj9UD 2Yvwvsz5BcvP3ts+qxjPlA6Wk0RmChtUNE9Acg/CHLZeEW+lpAPYfuMTDt5AAw2FcjGT UbLvzXHV2U3jXgG7wXSVyL8gf1mwjRZiMT8ypD0XQHLf40ERuPxIihXoIRFomR+t7zJi cncRAO4W+n+NaQJktt3Exm5u/uiuPV3sv/csYBDTcqXD/uBUcyQCsVsQpxy/hPLFeGY3 hduQsomSRgIPgil8IT1QSMkX8M5vH17AIV5c97nwvZmyO+BpgThdqmzEnXb5v/I7cTeM hBWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=z7uh3am6HtAykyhN/yrNQVLN2hJ996kbXHrbljvg+Bg=; b=JT8CK68fzGIauiDUd32LLBFhxOFjJuAjqyBx01dlOY4Kq1qqCXyFS5+1JMwG4tZzQR PSu8j5Rt1xMz+Wa7BAMnRUR24oyDexJixNj1jg+c1omw9GDw0+z8XGKfAgLdZKqCuYP4 2Q/A2IBP4KqR6GZ9IvGikU8LlvXHr2zu049z7ZeLcoSVDCdL5aGwFdAVCoIpn9v7EUk3 NzGL9FIfMVXTr0oYQ6BMtLyEV2rtxH3xEWYCSeNkKhvAij9Fx3G+CdMzLVYBt+clTvaP CUO/o3xjmQESdSP308z4NNIr70hfI5MAfRQ6WMxULvqt7zvBPCoC6NsPqCRSSWu+C9qy /ZbA== X-Gm-Message-State: ABUngvfxqUabirAjAOgpuBMoaflnWKos+4MkZI9AtGdRmhwKdqE961crodbw3UqazZNnOg== X-Received: by 10.99.209.5 with SMTP id k5mr11874306pgg.13.1479423274495; Thu, 17 Nov 2016 14:54:34 -0800 (PST) Received: from [192.168.178.23] (117.228.69.111.dynamic.snap.net.nz. [111.69.228.117]) by smtp.gmail.com with ESMTPSA id g82sm10801367pfb.43.2016.11.17.14.54.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 14:54:33 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 18 Nov 2016 11:54:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Quick clarification re GRASP tests X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:54:38 -0000 Just to clarify a comment Bing made about the tests with my Python prototype: - I have tested it in a single host by running multiple GRASP instances. These tests require the host to listen to its own multicasts. Done on both Windows 7 and Linux. - I have tested it between Windows and Linux on a single LAN, both in the lab at the University of Auckland and in my home office. That included a test with the machines connected via two LANs (Ethernet and WiFi) in a physical loop, to verify that loop suppression works. - I have tested with GUA, ULA and link-local-only addressing. - As Bing mentioned, I also did some tests between Windows at home, and Linux at the UNI, over Internet IPv6 service. That worked, but was a bit bogus as I had to fake the discovery mechanism. Anyway, I've tested about everything I can until another implementation of the current spec comes along, for interop tests, as Sheng suggested. Regards Brian From nobody Thu Nov 17 15:33:52 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23783129455 for ; Thu, 17 Nov 2016 15:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 99dsCatfI_zC for ; Thu, 17 Nov 2016 15:33:47 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053141293FB for ; Thu, 17 Nov 2016 15:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33274; q=dns/txt; s=iport; t=1479425627; x=1480635227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8QpX6i7b6iPc48Vr76/rpxG4/QU+DW8JWiOft6e2Yl0=; b=TOparx2Fl2tIzmmKETDnpBdXtExzjA8yVGVpWZqracD5tsXi0lVpd0k0 Mefl/NPSo7lUu+2dmUUN1I5ik4BfCU8tk+86LqyIhAjzaFkZzjKN8Nmkd VetFOacX8wJNeBM+07cfHQLyT8EJtBeNUPABMS8+hpP3PdKP7/Z6wmG5O Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAQBkPS5Y/5NdJa1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWIEAB404lxCHb4x1ggQDHQuFeQIaggQ/FAECAQE?= =?us-ascii?q?BAQEBAWIohGgBAQEDAQEBARcJEToGBQULAgEIDgoCAiYCAgIfBgsVEAIEDgWIU?= =?us-ascii?q?gMPCA6sVoIph0YNhAUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEJhzCBVYEIgki?= =?us-ascii?q?BTQQCBgQBBgECGheCbS2CMAWISoYXgUGCfYERhV41AYQ0hRqDUoNMgXCEdoM/h?= =?us-ascii?q?gGJJoQqhAoBHjc5JC4dhR5yAYU8AQ4XgQqBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,655,1473120000"; d="scan'208";a="349729896" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2016 23:33:45 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uAHNXiS4016656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 23:33:44 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 17:33:43 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Thu, 17 Nov 2016 17:33:43 -0600 From: "Max Pritikin (pritikin)" To: Toerless Eckert Thread-Topic: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt Thread-Index: AQHSQSBuqiIqC1OfZUSnjWjGxit30KDeOGWA Date: Thu, 17 Nov 2016 23:33:43 +0000 Message-ID: References: <20161117221750.GA23347@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20161117221750.GA23347@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: text/plain; charset="utf-8" Content-ID: <7E749E93ABCF5646A9FAA58BB062DFFD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 23:33:50 -0000 U29tZSBjb21tZW50cyBvbiB0aGUgQlJTS0kgZGlzY3Vzc2lvbiBpbmxpbmUsIA0KDQo+IE9uIE5v diAxNywgMjAxNiwgYXQgMzoxNyBQTSwgVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPiB3 cm90ZToNCj4gDQo+IA0KPiBUaGFua3MgQnJpYW4gJiBCaW5nDQo+IA0KPiBJbmxpbmUNCj4gDQoN ClRoZSBmb2xsb3dpbmcgcXVvdGUgbGV2ZWxzIGFwcGVhciB0byBiZSBkaXJlY3Qgb3IgcGFyYXBo cmFzZXMgZnJvbSB0aGUgb2JqZWN0aXZlcyBkcmFmdC4NCknigJltIHRlbXB0ZWQgbm90IGV2ZW4g dG8gcmVzcG9uZCB0byB0aGlzIGVtYWlsIHRocmVhZCBkdWUgdG8gdGhlIHNsb3BweSBxdW90aW5n IGJ1dCB3ZeKAmWxsIHNlZSBob3cgaXQgZ29lcy4gDQoNCj4+ICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIHNldmVyYWwgdGVjaG5pY2FsIG9iamVjdGl2ZXMgZm9yIHVzZSB3aXRoIGZvcg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4+ICAg dGhlIEdlbmVyaWMgQXV0b25vbWljIFNpZ25hbGluZyBQcm90b2NvbCAoR1JBU1ApDQo+PiAgIFtJ LUQuaWV0Zi1hbmltYS1ncmFzcF0uDQoNCltzbmlwXSBJ4oCZbSBmb2N1c2luZyBvbiBqdXN0IGJv b3RzdHJhcCBkaXNjdXNzaW9ucw0KDQo+PiAgICAgIFNlY3VyZSBCb290c3RyYXAuDQo+IA0KPiBB TkkgdXNlIGNhc2U6IGJvb3RzdHJhcHBpbmcgYXV0b25vbWljIGRldmljZXMsIG5vbi1BTkkgdXNl IGNhc2U6IGJvb3RzdHJhcHBpbmcNCj4gbm9uLWF1dG9ub21pYyBkZXZpY2VzLg0KDQpTaW5jZSBp dHMgb2JqZWN0aXZlcyBmb3IgYXV0b25vbWljIEkgZG9u4oCZdCBzZWUgdGhhdCBkaXNjdXNzaW5n IG5vbi1hdXRvbm9taWMgaXMgbmVjZXNzYXJ5IGluIHRoaXMgZG9jdW1lbnQuIA0KVGhlIGJyb2Fk ZXIgcG9pbnQgdGhhdCBCUlNLSSBuZWVkIG5vdCBiZSBmb3JjZWQgdG8gYmUgQU5JIHNwZWNpZmlj IGlzIGltcG9ydGFudCB0byByZS1lbmZvY2UsIHNvIHRoYW5rIHlvdS4gDQoNCj4gDQo+PiAgICAg IEF1dG9ub21pYyBDb250cm9sIFBsYW5lIChBQ1ApLg0KPiANCj4gUGFydCBvZiB0aGUgQU5JLCBz ZXJ2aW5nIGF1dG9ub21pYyBhbmQgbm9uLWF1dG9ub21pYyB1c2UgY2FzZXMuDQo+IA0KPj4gICAg ICBTdGFibGUgQ29ubmVjdGl2aXR5IG9mIE5ldHdvcmsgT0FNLg0KPiANCj4gUHJpbWFyaWx5IG5v bi1hdXRvbm9taWMgYXMgaXQgZGlzY3Vzc2VzIFNETiBtYW5hZ2VtZW50IHZpYSB0aGUgQUNQIHdp dGhvdXQNCj4gaW50ZW50IGJlaW5nIGludm9sdmVkICh5ZXQpLg0KPiANCj4+ICAgICAgSW50ZW50 IERpc3RyaWJ1dGlvbi4NCj4gDQo+IEFOSSB1c2UgY2FzZS4NCj4gDQo+IC4uLg0KPj4gMi4gIE9i amVjdGl2ZXMgZm9yIFNlY3VyZSBCb290c3RyYXANCj4+IA0KPj4gICBUaHJlZSBjb21wb25lbnRz IGFyZSBpbnZvbHZlZCBpbiB0aGUgQm9vdHN0cmFwcGluZyBSZW1vdGUgU2VjdXJlIEtleQ0KPiAg ICAgICAgICBeXiBpbnNlcnQgQU5JDQo+PiAgIEluZnJhc3RydWN0dXJlcyAoQlJTS0kpIHByb2Nl c3MgZGVzY3JpYmVkIGluDQo+PiAgIFtJLUQuaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWlu ZnJhXTogdGhlIFJlZ2lzdHJhciwgdGhlIEpvaW4NCj4+ICAgQXNzaXN0YW50IChvciBQcm94eSks IGFuZCB0aGUgSm9pbmluZyBOb2RlIChvciBQbGVkZ2UpLiANCj4gDQo+IFBscy4gZ2V0IHRoZSBm aW5hbCBvZmZpY2lhbCB3b3JkIGZvciBwcm94eS9wbGVkZ2UuIHdlJ3JlIGNhcnJ5aW5nIGFyb3Vu ZA0KPiB0b28gbWFueSB0ZXJtcyBhbmQgcmVwZWF0aW5nIHRoZW0gZXZlcnl3aGVyZS4NCg0KUGxl ZGdlLCBQcm94eSwgUmVnaXN0cmFyLCBNQVNBDQoNCj4gDQo+IE5vdGU6IC4uLiBCb290c3RyYXBw aW5nIGhhcyBtb3JlIGZ1bmN0aW9ucywgc3VjaCBhcyBNQVNBIGFuZCBDQSwgYnV0IHdlDQo+IGRv IG5vdCBmb3Jlc2VlIHRoZSBuZWVkIGZvciBHUkFTUCBzaWduYWxsaW5nIHdpdGggdGhlbSBhdCB0 aGlzIHRpbWUuDQo+IA0KPj4gICBUaGUgcHJveHkNCj4+ICAgYW5kIHRoZSBwbGVkZ2UgYXJlIGF0 dGFjaGVkIHRvIHRoZSBzYW1lIGxpbmstbGF5ZXIgYW5kIHVzZSBsaW5rLWxvY2FsDQo+PiAgIGNv bW11bmljYXRpb25zIG9ubHksIHRvIG1pbmltaXplIGV4cG9zdXJlIHRvIGVhdmVzZHJvcHBlcnMg YW5kDQo+PiAgIG1hbGljaW91cyBub2Rlcy4NCj4gDQo+IEkgdGhpbmsgdGhpcyBpcyBub3QgdGhl IHJpZ2h0IHNlY3VyaXR5IGNsYWltIHRvIG1ha2UuIFdlIGRvIGhhdmUgaW1wb3J0YW50DQo+IHVz ZS1jYXNlcyB3aGVyZSB0aGUgcHJveHkgTVVTVCBiZSByZW1vdGUsIGVnOiB3aGVuIGkgYXR0YWNo IGENCj4gcGxlZGdlIHRvIGp1c3QgYW4gb3BlbiBpbnRlcm5ldCBjb25uZWN0aW9uIHdpdGhvdXQg YW55IHByaW9yIEFOSQ0KPiBpbiB0aGUgdmljaW5pdHkuIEFuZCB0aGUgc2VjdXJpdHkgY29tcGFy aXNvbiBvZiB0aGlzIHNldHVwIHZzLiB0aGUgb25lIHdpdGgNCj4gTDIgaXMga2luZGEgY29tcGxl eCBhbmQgc2hvdWxkIG1heWJlIG5vdCBoYWQgaW4gdGhpcyBkb2MuIA0KPiANCj4gSSdkIHN1Z2dl c3Q6DQo+IA0KPiBPcGVyYXRpb25hbGx5LCB0aGUgbW9zdCBzaW1wbGUgY2FzZSBpcyB3aGVuIHBy b3h5IGFuZCBwbGVkZ2UgaGF2ZSBhDQo+IGxpbmstbG9jYWwgY29ubmVjdGlvbiBiZXR3ZWVuIGVh Y2ggb3RoZXIuIEluIHRoaXMgY2FzZSwgbXV0dWFsIGRpc2NvdmVyeSBhbmQNCj4gYm9vdHN0cmFw IGNhbiBoYXBwZW4gd2l0aG91dCBhbnkgcHJpb3IgcHJvdmlzaW9uaW5nIG9mIGhlbHBlciBpbmZv cm1hdGlvbg0KPiBzdWNoIGFzIERIQ1AgcGFyYW1ldGVycyBvciBETlMgZW50cmllcyB0aHJvdWdo IHdoaWNoIHRoZSBwbGVkZ2Ugd291bGQgaGF2ZQ0KPiB0byBmaW5kIHRoZSBwcm94eSBvdGhlcndp c2UuIEluc3RlYWQsIGxpbmstbG9jYWwgbXVsdGljYXN0IHdpdGggR1JBU1AgY2FuIGFuZA0KPiB3 aWxsIGJlIHVzZWQuDQoNClRoaXMgZnJhbWluZyBpcyBwcm9iYWJseSBiZXR0ZXIuIFdlIGFsc28g bXVzdCBub3RlIHRoYXQgdGhlIFBsZWRnZSByZXF1aXJlbWVudCB0byB3b3JrIHdoZW4gdGhlIHBy b3h5IGlzIHJlbW90ZSBhbHNvIG1lYW5zIHRob3NlIFBsZWRnZXMgbXVzdCBzdXBwb3J0IHRoZSBE TlMgbWVjaGFuaXNtcy4gQWRkaW5nIEdSQVNQIGlzIHRydWx5IGFuIGFkZGl0aW9uIHRvIHRoZSBt ZXRob2RzIG5vdCBhIHJlcGxhY2VtZW50IG9yIGFuIG9wdGltaXphdGlvbi4NCg0KPj4gICBUaGVy ZSBtYXkgYmUgbXVsdGlwbGUgaG9wcyBiZXR3ZWVuIHRoZSBwcm94eSBhbmQNCj4+ICAgdGhlIHJl Z2lzdHJhci4NCj4gDQo+IEJldHdlZW4gcmVnaXN0cmFyIGFuZCBwcm94eSwgdGhlcmUgY2FuIGFu ZCBsaWtlbHkgd2lsbCBiZSBtdWx0aXBsZSBob3BzLA0KPiBidXQgaW4gYW4gYXV0b25vbWljIG5l dHdvcmssIHRoZXNlIGhvcHMgd2lsbCBoYXZlIGF1dG9jb25maWd1cmVkIEFDUCBhbmQNCj4gR1JB U1AgZm9yd2FyZGVycyBiZXR3ZWVuIHRoZW0sIHNvIHRoaXMgY29ubmVjdGl2aXR5IHRvbyBpcyB6 ZXJvLXRvdWNoIGxpa2UNCj4gdGhlIGxpbmstbG9jYWwgY29ubmVjdGl2aXR5IGJldGVlZW4gcGxl ZGdlIGFuZCBwcm94eS4NCj4gDQo+PiAgIFRoZXJlZm9yZSwgdHdvIGRpZmZlcmVudCBHUkFTUCBv YmplY3RpdmVzIGFyZQ0KPj4gICByZXF1aXJlZDogb25lIHRoYXQgaXMgdXNlZCBvdmVyIGFuIGV4 aXN0aW5nIHNlY3VyZSBuZXR3b3JrIGJldHdlZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhlICAgICAgICAgICAgICAgICAgICAgIChBQ1ApDQo+PiAgIHRoZSByZWdp c3RyYXIgYW5kIHRoZSBwcm94eSwgYW5kIGFub3RoZXIgdGhhdCBpcyB1c2VkIG92ZXIgYW4NCj4+ ICAgaW5zZWN1cmUgbGluay1sb2NhbCBob3AgYmV0d2VlbiB0aGUgcHJveHkgYW5kIHRoZSBwbGVk Z2UuICBUaGUNCj4+ICAgc2VjdXJpdHkgYXNwZWN0cyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgbGlt aXRlZCBpbnN0YW5jZXMgb2YgR1JBU1AgYXJlDQo+PiAgIGRpc2N1c3NlZCBpbiBbSS1ELmlldGYt YW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV0gYW5kDQo+PiAgIFtJLUQuaWV0Zi1hbmltYS1n cmFzcF0uDQo+IA0KPiBBbmQgaSBuZWVkIHRvIGNoZWNrIEFDUCBkcmFmdCBpZmhvdyBpIGNhcHR1 cmUgdGhhdCBmYWN0IHRoZXJlIGFzIHdlbGwuDQo+IEVzcGVjaWFsbHkgdGhhdCBlYWNoIEFDUCBu b2RlIG5lZWRzIHRvIHJ1biBhIEdSQVNQIGZvcndhcmRlciBmb3IgdGhhdA0KPiBob3AtYnktaG9w IGZvcndhcmRpbmcgb2YgdGhlIEdSQVNQIGZsb29kIC0gc2VjdXJlbHkuDQo+IA0KPj4gICBOb3Rl IHRoYXQgc2luY2Ugc2VjdXJlIGJvb3RzdHJhcCB0YWtlcyBwbGFjZSwgYnkgZGVmaW5pdGlvbiwg b24gYW4NCj4+ICAgaW5jb21wbGV0ZWx5IHNlY3VyZSBuZXR3b3JrLCB0aGUgdXNlIG9mIGFueSBw cm90b2NvbCBuZWVkcyB0byBiZSBrZXB0DQo+PiAgIGFzIHNpbXBsZSBhbmQgbGltaXRlZCBhcyBw b3NzaWJsZS4gIFRoZXJlZm9yZSwgb25seSBvbmUgR1JBU1AgbWVzc2FnZQ0KPj4gICB0eXBlIGlz IHVzZWQgLSBmbG9vZGluZyAtIHRvIGF2b2lkIGdpdmluZyBhd2F5IGFueSB1bm5lY2Vzc2FyeQ0K Pj4gICBpbmZvcm1hdGlvbiBieSBhbnkgbm9kZSBpbnZvbHZlZC4NCj4gDQo+IFN1Z2dlc3QgdG8g bW92ZSB0aGF0IHBhcmFncmFwaCB1cCBiZWZvcmUgdGhlIHByb3h5L3JlZ2lzdHJhciB0ZXh0IHRv DQo+IG1ha2UgcmVhZGluZyBlYXNpZXIuDQo+IA0KPj4gICBBIHJlZ2lzdHJhciBhbm5vdW5jZXMg aXRzZWxmIHRvIHBvdGVudGlhbCBwcm94aWVzIGJ5IHVzZSBvZiB0aGUNCj4+ICAgIkFOX3JlZ2lz dHJhciIgb2JqZWN0aXZlLiAgVGhpcyBpcyBhIHN5bmNocm9uaXphdGlvbiBvYmplY3RpdmUNCj4+ ICAgcHJpbWFyaWx5IGludGVuZGVkIHRvIGJlIGZsb29kZWQgdGhyb3VnaG91dCB0aGUgbmV0d29y ayB1c2luZyB0aGUNCj4+ICAgR1JBU1AgRmxvb2QgU3luY2hyb25pemF0aW9uIChNX0ZMT09EKSBt ZXNzYWdlLiAgSW4gYWNjb3JkYW5jZSB3aXRoDQo+PiAgIHRoZSBkZXNpZ24gb2YgdGhlIEZsb29k IG1lc3NhZ2UsIGEgbG9jYXRvciBjb25zaXN0aW5nIG9mIGEgc3BlY2lmaWMNCj4+ICAgSVAgYWRk cmVzcywgSVAgcHJvdG9jb2wgbnVtYmVyIGFuZCBwb3J0IG51bWJlciB3aWxsIGJlIGRpc3RyaWJ1 dGVkDQo+PiAgIHdpdGggdGhlIGZsb29kZWQgb2JqZWN0aXZlLiAgQW4gZXhhbXBsZSBvZiB0aGUg b2JqZWN0aXZlIGlzDQo+PiAgIGluZm9ybWFsbHk6DQo+PiANCj4+ICAgWyJBTl9yZWdpc3RyYXIi LCBGX1NZTkNILCBsb29wX2NvdW50LCBbNywgIkJSU0tJLVRMUyJdXQ0KPj4gDQo+PiAgIFRoZSBm b3JtYWwgQ0RETCBkZWZpbml0aW9uIGlzDQo+PiANCj4+ICAgcmVnaXN0cmFyLW9iamVjdGl2ZSA9 IFsiQU5fcmVnaXN0cmFyIiwgRl9TWU5DSCwgbG9vcC1jb3VudCwgW3JhZGl1cywNCj4+ICAgbWV0 aG9kXV0NCj4+IA0KPj4gICByYWRpdXMgPSB1aW50IDsgbG9vcC1jb3VudCBhdCB0aGUgc291cmNl IG5vZGUNCj4+ICAgbWV0aG9kID0gdGV4dCA7IG5hbWUgb2YgdGhlIEJSU0tJIG1ldGhvZCBzdXBw b3J0ZWQNCj4+IA0KPj4gICBUaGUgJ3JhZGl1cycgcGFyYW1ldGVyIGFsbG93cyBhIHByb3h5IHRo YXQgcmVjZWl2ZXMgdGhpcyBtZXNzYWdlIHRvDQo+PiAgIGRldGVybWluZSBpdHMgZGlzdGFuY2Ug aW4gaG9wcyBmcm9tIHRoZSByZWdpc3RyYXIsIGJ5IHN1YnRyYWN0aW5nIHRoZQ0KPj4gICByZWNl aXZlZCAnbG9vcC1jb3VudCcgZnJvbSAncmFkaXVz4oCZLg0KDQpJ4oCZbSBub3Qgc2VlaW5nIGEg ZGlzY3Vzc2lvbiBvZiBkaXN0YW5jZSBhcyBhIHNlbGVjdGlvbiBtZXRob2Qgd2l0aGluIEdSQVNQ LiBJcyB0aGUgYWJpbGl0eSB0byBwcm92aWRlIGRpc3RhbmNlIG1ldHJpY3MgYSBnb2FsIG9mIEdS QVNQPyBJcyBpdCBzcGVjaWZpYyB0byBib290c3RyYXBwaW5nPyBUaGVyZSBpcyBubyBkaXNjdXNz aW9uIG9mIGxvZ2ljIHVzaW5nIHRoaXMgZm9ybSBvZiBtZXRyaWMgaW4gdGhlIEJSU0tJIGRvY3Vt ZW50Lg0KDQo+ICpyb3RmbCogd2hlbiBpIHJlYWQgdGhlIHdvcmQgcmFkaXVzIGkgYXNrZWQgbXlz ZWxmIHdoeSB3ZSB3b3VsZCBkbyBhbnl0aGluZw0KPiB3aXRoIHRoZSByYWRpdXMgcHJvdG9jb2wg aGVyZS4gRGlhbWV0ZXIgaXMgYWxzbyBvdmVybG9hZGVkLiANCj4gInNlbmRlci1sb29wLWNvdW50 IiB3b3VsZCBiZSBtb3N0IGRlc2NyaXB0aXZlLg0KPiANCj4gQWxzbywgaSB3b3VsZCBzdWdnZXN0 IHRvIHJlbW92ZSB0aGUgaW5mb3JtYWwgcmVwcmVzZW50YXRpb24gYW5kIHJhdGhlciBwdXQNCj4g dGhlIGluZm9ybWF0aW9uIGludG8gdGhlIGNvbW1lbnRzIG9mIHRoZSBmb3JtYWwgZGVzY3JpcHRp b246DQo+IA0KPiANCj4gICAgIHNlbmRlci1sb29wLWNvdW50ID0gdWludCA7IGxvb3AtY291bnQg YXQgdGhlIHNvdXJjZSBub2RlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyAyNTUg aXMgYSBnb29kIGRlZmF1bHQuIE1heSB1c2Ugc21hbGxlciB2YWx1ZXMNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA7IGlmIGRpYW1ldGVyIG9mIEFDUCBuZXR3b3JrIGlzIGtub3duDQo+ ICAgICBtZXRob2QgPSB0ZXh0ICAgICAgICAgICAgOyBOYW1lIG9mIEJSU0tJIG1ldGhvIHN1cHBv cnRlZA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgZWc6ICJCUlNLSS1UTFMiDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBTaG91bGQgaGF2ZSBzb21lIHBvaW50ZXIg dG8gd2hlcmUgdmFsdWVzIGFyZSBkZWZpbmVkLg0KPiANCj4+ICAgVGhlICdtZXRob2QnIHBhcmFt ZXRlciBpbmRpY2F0ZXMgdGhlIHNwZWNpZmljIEJSU0tJIG1ldGhvZCBhdmFpbGFibGUNCj4+ICAg YXQgdGhlIGdpdmVuIGxvY2F0b3IuICBUaGUgaW5pdGlhbCBwb3NzaWJsZSB2YWx1ZXMgYXJlICJC UlNLSS1UTFMiDQo+PiAgIGFuZCAiQlJTS0ktQ09BUCIuICBBIHJlZ2lzdHJhciB0aGF0IHN1cHBv cnRzIG1vcmUgdGhhbiBvbmUgbWV0aG9kDQo+PiAgIHdpbGwgZmxvb2QgbXVsdGlwbGUgdmVyc2lv bnMgb2YgdGhlICJBTl9yZWdpc3RyYXIiIG9iamVjdGl2ZS4NCj4gDQo+IEp1c3QgY3VyaW91czog SWYgaXQgd291bGQgYmUgcG9zc2libGUgdG8gZW5jb2RlIG11bHRpcGxlIG1ldGhvZHMgaW4gYQ0K PiBzaW5nbGUgb2JqZWN0aXZlLCB3aHkgd291bGQgeW91IHByZWZlciB0byB1c2UgZGlmZmVyZW50 IG9uZXMgPw0KPiANCj4gTXkgcHJlZmVyZW5jZSBmb3IgZGlmZmVyZW50IG9iamVjdGl2ZXMgd291 bGQgYmUgYXMgZm9sbG93cywgYW5kIG1heWJlIHRoYXQncw0KPiBnb29kIHRleHQgdG8gaGF2ZToN Cj4gDQo+IEEgZGlmZmVyZW50IG9iamVjdGl2ZSBpcyB1c2VkIGZvciBlYWNoIG1ldGhvZCB0byBt b3N0IGVhc3kgc3VwcG9ydA0KPiB0aGUgb3B0aW9uIHRoYXQgaW5kZXBlbmRlbnQgQVNBcyBhcmUg cHJvdmlkaW5nIHRoZSByZWdpc3RyYXIgZnVuY3Rpb24gZm9yDQo+IGRpZmZlcmVudCBtZXRob2Rz LiBGb3IgZXhhbXBsZSwgQlJTS0ktQ09BUCB3b3VsZCBtb3N0IGxpa2VseSBiZSBmb2N1c3NlZA0K PiB0byBoZWxwIGVucm9sIGFsc28gbm9uLWF1dG9ub21pYyBwbGVkZ2VzIGFuZCBjb3VsZCBoYXZl IGEgcmFuZ2Ugb2YNCj4gYXNwZWN0cyB0aGF0IHdvdWxkIG1ha2UgaW1wbGVtZW50YXRpb24gaW4g YSBzZXBhcmF0ZSBBU0EgYmVuZWZpY2lhbA0KPiAoZWc6IGRpZmZlcmVudCBzY2FsZS9wb2xpY2ll cyBmb3Igbm9uLWF1dG9ub21pYyBwbGVkZ2VzKS4NCj4gDQo+IEFub3RoZXIgcG9pbnQgdG8gbWVu dGlvbiBpcyB0aGUgdGltaW5nIG9mIHRoaXMsIGVnOg0KPiANCj4gQWN0aXZlIFJlZ2lzdHJhcnMg d2lsbCBzZW5kIHRoaXMgb2JqZWN0aXZlIGZsb29kIGFubm91bmNlbWVudCBwZXJpb2RpY2FsbHkN Cj4gKHdoYXRzIGEgZ29vZCBwZXJpb2RpY2l0eSA/KS4gUHJveGllcyB3aWxsIGRpc2NvdmVyeSB0 aGVzZSBtZXNzYWdlcy4NCj4gQSBwcm94eSBjYW4gYmUgYWN0aXZlIHdoZW5ldmVyIGl0IGtub3dz IG9uZSBvciBtb3JlIHJlZ2lzdHJhcnMuDQo+IA0KPiBBbmQgdGhlbiB3aGF0IGhhcHBlbnMgd2hl biBhIHJlZ2lzdHJhciBmYWlsczoNCj4gIC0gQ2FuIHdlIGRlc2NyaWJlIHRoZSB0aW1lb3V0IGJl aGF2aW9yLA0KDQpUaGlzIHdvdWxkIGJlIGNvdmVyZWQgYnkgdGhlIEdSQVNQIHMzLjUuNC4zIOKA mGxpZmV0aW1l4oCZIGRpc2N1c3Npb24/IEkgZG9u4oCZdCBzZWUgaXQgYXMgc3BlY2lmaWMgdG8g Ym9vdHN0cmFwcGluZy4NCg0KPiBlZzogd2hlbi9ob3cgd2lsbCBwcm94eSBsZWFybg0KPiAgICB0 aGF0IHRoZSByZWdpc3RyYXIgd2VudCBhd2F5LiBEb2VzIGEgcmVnaXN0cmFyIEFTQSB0aGF0IGlz IGdvaW5nIGRvd24NCj4gICAgaW4gYSBjb250cm9sbGVkIGZhc2hpb24gaGF2ZSBhIHdheSB0byBl eHBsaWNpdGx5IHdpdGhkcmF3IHRoZSBvYmplY3RpdmUgPw0KDQpJIGRvbuKAmXQgc2VlIGFueSBk aXNjdXNzaW9uIG9mIGRlbGV0aW9uIGluIHRoZSBtYWluIEdSQVNQIGRvY3VtZW50LiBIb3cgZG9l cyB0aGF0IHdvcms/IA0KDQotIG1heA0KDQo+IA0KPiBJIGtub3csIHRoaXMgdGV4dC90aGVzZSBx dWVzdGlvbnMgd291bGQgZ28gYmV5b29uZCBqdXN0IGRlZmluaW5nIHRoZQ0KPiBvYmplY3RpdmUg ZW5jb2RpbmcsIGJ1dCBpIHRoaW5rIGl0IHdvdWxkIGhlbHAgYSBsb3QgdG8gaGF2ZSB0aGlzIHR5 cGUNCj4gb2YgY29uY2lzZSBzdW1tYXJ5IG9mIHRoZSBHUkFTUCBvYmplY3RpdmUgYmVoYXZpb3Iu DQo+IA0KPj4gMi4xLiAgRmxvb2RpbmcgQWx0ZXJuYXRpdmUgZm9yIFByb3h5DQo+PiANCj4+ICAg QSBwcm94eSBhbm5vdW5jZXMgaXRzZWxmIHRvIHBvdGVudGlhbCBwbGVkZ2VzIGJ5IHVzZSBvZiB0 aGUNCj4+ICAgIkFOX3Byb3h5IiBvYmplY3RpdmUuICBUaGlzIGlzIGEgc3luY2hyb25pemF0aW9u IG9iamVjdGl2ZSBwcmltYXJpbHkNCj4+ICAgaW50ZW5kZWQgdG8gYmUgZmxvb2RlZCBvbiBhIHNp bmdsZSBsaW5rIHVzaW5nIHRoZSBHUkFTUCBGbG9vZA0KPj4gICBTeW5jaHJvbml6YXRpb24gKE1f RkxPT0QpIG1lc3NhZ2UuICBJbiBhY2NvcmRhbmNlIHdpdGggdGhlIGRlc2lnbiBvZg0KPj4gICB0 aGUgRmxvb2QgbWVzc2FnZSwgYSBsb2NhdG9yIGNvbnNpc3Rpbmcgb2YgYSBzcGVjaWZpYyBsaW5r LWxvY2FsIElQDQo+PiAgIGFkZHJlc3MsIElQIHByb3RvY29sIG51bWJlciBhbmQgcG9ydCBudW1i ZXIgd2lsbCBiZSBkaXN0cmlidXRlZCB3aXRoDQo+PiAgIHRoZSBmbG9vZGVkIG9iamVjdGl2ZS4g IEFuIGV4YW1wbGUgb2YgdGhlIG9iamVjdGl2ZSBpcyBpbmZvcm1hbGx5Og0KPj4gDQo+PiAgIFsi QU5fcHJveHkiLCBGX1NZTkNILCAxLCAiQlJTS0ktVExTIl0NCj4+IA0KPj4gICBUaGUgZm9ybWFs IENEREwgZGVmaW5pdGlvbiBpcw0KPj4gDQo+PiAgIHByb3h5LW9iamVjdGl2ZSA9IFsiQU5fcHJv eHkiLCBGX1NZTkNILCAxLCBtZXRob2RdDQo+PiAgIG1ldGhvZCA9IHRleHQgOyBuYW1lIG9mIHRo ZSBCUlNLSSBtZXRob2Qgc3VwcG9ydGVkDQo+PiANCj4+ICAgVGhlIGxvb3AtY291bnQgaXMgZml4 ZWQgYXQgMSBzaW5jZSB0aGlzIGlzIGEgbGluay1sb2NhbCBvcGVyYXRpb24uDQo+IA0KPiBVbmxl c3Mgd2Ugd2FudCB0byBhZGQgdGhpcyBUVEwgZm9yd2FyZGluZyBkZXRlY3Rpb24gc2NoZW1lIHdo b3NlIG5hbWUgaSBmb3Jnb3QuDQo+IChzZXQgVFRMIHRvIDI1NSwgaWdub3JlIG9uIHJlY2VpdmVy IG1lc3NhZ2VzIHdpdGggbG93ZXIgVFRMKS4NCj4gDQo+PiAgIFRoZSAnbWV0aG9kJyBwYXJhbWV0 ZXIgaW5kaWNhdGVzIHRoZSBzcGVjaWZpYyBCUlNLSSBtZXRob2QgYXZhaWxhYmxlDQo+PiAgIGF0 IHRoZSBnaXZlbiBsb2NhdG9yLiAgVGhlIGluaXRpYWwgcG9zc2libGUgdmFsdWVzIGFyZSAiQlJT S0ktVExTIg0KPj4gICBhbmQgIkJSU0tJLUNPQVAiLiAgQSBwcm94eSB0aGF0IHN1cHBvcnRzIG1v cmUgdGhhbiBvbmUgbWV0aG9kIHdpbGwNCj4+ICAgZmxvb2QgbXVsdGlwbGUgdmVyc2lvbnMgb2Yg dGhlICJBTl9wcm94eSIgb2JqZWN0aXZlLg0KPj4gDQo+PiAyLjIuICBOZWdvdGlhdGlvbiBBbHRl cm5hdGl2ZSBmb3IgUHJveHkNCj4+IA0KPj4gICBUaGlzIGFsdGVybmF0aXZlIHRvICJBTl9wcm94 eSIgdXNlcyBhZGRpdGlvbmFsIGZlYXR1cmVzIG9mIEdSQVNQLiAgSXQNCj4+ICAgcmVxdWlyZXMg YWRkaXRpb25hbCBjb21wbGV4aXR5IGluIHRoZSBwbGVkZ2UsIGFuZCByZXF1aXJlcyB0aGUgcGxl ZGdlDQo+PiAgIHRvIGFubm91bmNlIGl0cyBleGlzdGVuY2UgdG8gYW55IG9uLWxpbmsgZWF2ZXNk cm9wcGVycyB2aWEgYQ0KPj4gICBEaXNjb3ZlcnkgbWVzc2FnZS4gIEl0IGlzIHRoZXJlZm9yZSBu b3QgcmVjb21tZW5kZWQgb24gc2VjdXJpdHkNCj4+ICAgZ3JvdW5kcywgYnV0IGlzIGRlZmluZWQg aGVyZSBmb3IgY29tcGxldGVuZXNzLg0KPiANCj4gVGhhdCBwYXJhZ3JhcGggZG9lcyBub3Qgc291 bmQgbGlrZSB0aGUgYmVzdCBzYWxlcyBwaXRjaC4gIEFuZCBhZ2FpbiwgaSBhbQ0KPiBub3Qgc3Vy ZSBpZiB0aGUgbmVnYXRpdmUgc2VjdXJpdHkgYXNzZXNzbWVudCB5b3UgbWFrZSBpcyBjb3JyZWN0 Lg0KPiANCj4gRmlyc3Qgb2YgYWxsLCBtYXliZSBtb3ZlIHRvIGFuIGFwcGVuZGl4IGdpdmVuIGhv dyB0aGlzIGdvZXMgYmV5b25kIA0KPiBvdXIgTVRJIChNYW5kYXRvcnkgVG8gSW1wbGVtZW50KS4N Cj4gDQo+IFNlY29uZGx5OiBmbG9vZGluZyBhbm5vdW5jZW1lbnRzIGZyb20gcHJveGllcyB0byBw bGVkZ2VzIGlzIGJhc2VkIG9uDQo+IHNlY3VyaXR5IGFzc3VtcHRpb25zIHRoYXQgdGhlIG5ldHdv cmsgaW5mbyAod2l0aCBwcm94aWVzIG9uIHRoZSBlZGdlKSBpcw0KPiB3ZWxsIHNlY3VyZWQvcHJv dGVjdGVkLCBhbmQgdGhhdCBwbGVkZ2VzIGFyZSBtb3JlIHZ1bG5lcmFibGUuIEF0dGFja2Vycw0K PiB3b2xkIGhhdmUgdG8gYmVjb21lIGFjdGl2ZSB3aXRoIGZsb29kIG11bHRpY2FzdHMgdG8gZmlu ZCBhIHBsZWRnZSB3aGljaCB3b3VsZA0KPiBvdGhlcndpc2UgYmUgcXVpZXQuIEFuZCB0aG9zZSBh dHRhY2tlciBmbG9vZCBtdWx0aWNhc3RzIGNhbiBiZSBkZXRlY3RlZC4NCj4gDQo+IEVnOiB3aGVu IHdlJ2QgdHVybiBpdCBhcm91bmQgbGlrZSB5b3UgZGVzY3JpYmUgaGVyZSwgYXR0YWNrZXJzIGNv dWxkIGp1c3QNCj4gdW5pY2FzdCBhbnN3ZXIgdG8gcGxlZGdlcyBhbmQgdGhlcmVmb3JlIGF0dGFj ayB0aGUgcGxlZGdlIHdpdGggbGVzcw0KPiBvZiBhIHZpc2libGUgdHJhaWwgKGFrYTogYSB2YWxp ZCBwcm94eSB3b3VsZCBub3QgbmVjZXNzYXJpbHkgc2VlIHRoZSB1bmljYXN0DQo+IHRyYWZmaWMg YmV0d2VlbiBhdHRhY2tlciBhbmQgcGxlZGdlKS4NCj4gDQo+IEJ1dCBsZXRzIHR1cm4gdGhlIGFz c3VtcHRpb25zIGFyb3VuZDogSW4gSW9ULCBvbmUgbWlnaHQgYmUgZm9yZW1vc3QNCj4gY29uY2Vy bmVkIGFib3V0IHRoZSBzZWN1cml0eSBvZiB0aGUgaW5mcmEgKHdpdGggdGhlIHByb3hpZXMpLiBM ZXQgdGhvc2UNCj4gcGxlZGdlcyBtdWx0aWNhc3QgZm9yIGJvb3RzdHJhcCBoZWxwLCBidXQgb3Vy IHByb3h5IG1heSBHUkFTUCByZXNwb25kIG9ubHkNCj4gd2hlbiBpdCBmZWVscyB0aGF0J3Mgc2Fm ZS4gRm9yIGV4YW1wbGUsIGlmIHRoZSBsaW5rIGJldHdlZW4gcGxlZGdlIGFuZCBwcm94eQ0KPiBp cyBzb21lIElvVCByYWRpbyB3aXRoIHNvbWUgdmVuZG9yIGVuY3J5cHRpb24vc2VjdXJpdHkgKGxp a2UgaW4gYSBsb3Qgb2YNCj4gbG93LXBvd2VyIHJhZGlvIG9wdGlvbnMpLCB0aGlzIGFyZ3VtZW50 IG1pZ2h0IGZseSBhbmQgbWFrZSB0aGlzIG9yZGVyDQo+IG9mIHNpZ25hbGluZyBwcmVmZXJyYWJs ZS4NCj4gDQo+PiAgIEEgcGxlZGdlIGRpc2NvdmVycyBhIGxvY2FsIHByb3h5IGFuZCBuZWdvdGlh dGVzIGEgQlJTS0kgbWV0aG9kIHdpdGgNCj4+ICAgaXQgYnkgdXNlIG9mIHRoZSAiQU5fam9pbiIg b2JqZWN0aXZlLiAgRmlyc3QsIHRoZSBwbGVkZ2UgcGVyZm9ybXMNCj4+ICAgR1JBU1AgZGlzY292 ZXJ5LCB3aXRoIHRoZSBsb29wLWNvdW50IHNldCB0byAxIGFuZCBsaW1pdGVkIHRvIGxpbmstDQo+ PiAgIGxvY2FsIGFkZHJlc3Nlcy4gIElmIG11bHRpcGxlIHJlc3BvbnNlcyBvY2N1ciwgaXQgY2hv b3NlcyBvbmUgYnkgYW4NCj4+IA0KPj4gICBpbXBsZW1lbnRhdGlvbi1kZWZpbmVkIG1ldGhvZC4g IFRoZW4gdGhlIHBsZWRnZSBpbml0aWF0ZXMgR1JBU1ANCj4+ICAgbmVnb3RpYXRpb24gdG8gY2hv b3NlIGEgbXV0dWFsbHkgYWNjZXB0YWJsZSBCUlNLSSBtZXRob2QuDQo+PiANCj4+ICAgQW4gZXhh bXBsZSBvZiB0aGUgb2JqZWN0aXZlIGlzIGluZm9ybWFsbHk6DQo+PiANCj4+ICAgWyJBTl9qb2lu IiwgRl9ORUcsIDYsIFsiQlJTS0ktQ09BUCIsIkJSU0tJLVRMUyJdXQ0KPj4gDQo+PiAgIFRoZSBm b3JtYWwgQ0RETCBkZWZpbml0aW9uIGlzDQo+PiANCj4+ICAgam9pbi1vYmplY3RpdmUgPSBbIkFO X2pvaW4iLCBGX05FRywgbG9vcC1jb3VudCwgWyptZXRob2RdXQ0KPj4gICBtZXRob2QgPSB0ZXh0 IDsgbmFtZSBvZiB0aGUgQlJTS0kgbWV0aG9kIHN1cHBvcnRlZA0KPj4gDQo+PiAgIFRoZSBwYXJ0 aWVzIHdpbGwgbmVnb3RpYXRlIHVudGlsIG9uZSBzaWRlIHByb3Bvc2VzIGEgc2luZ2xlIEJSU0tJ DQo+PiAgIG1ldGhvZCBhbmQgdGhlIG90aGVyIHNpZGUgYWNjZXB0cy4gIEluIHRoZSBzaW1wbGVz dCBjYXNlIG9mIGltbWVkaWF0ZQ0KPj4gICBhY2NlcHRhbmNlLCB0aGVyZSB3aWxsIG9ubHkgYmUg dHdvIG1lc3NhZ2VzIChSZXF1ZXN0IE5lZ290aWF0ZSBhbmQNCj4+ICAgRW5kIE5lZ290aWF0ZSku ICBUaGUgbG9jYXRvciAoSVAgYWRkcmVzcywgSVAgcHJvdG9jb2wgbnVtYmVyLCBwb3J0DQo+PiAg IG51bWJlcikgdXNlZCBmb3IgdGhlIG5lZ290aWF0aW9uIHdpbGwgYmUgYXZhaWxhYmxlIGZvciB0 aGUgc3Vic2VxdWVudA0KPj4gICBCUlNLSSBvcGVyYXRpb25zLCBpZiByZXF1aXJlZC4NCj4+IA0K Pj4gICBOb3RlIHRoYXQgaW4gdGhlIERpc2NvdmVyeSBtZXNzYWdlLCB0aGUgbG9vcCBjb3VudCB3 aWxsIGJlIHNldCB0byAxDQo+PiAgIHRvIGxpbWl0IGRpc2NvdmVyeSB0byB0aGUgbG9jYWwgbGlu ay4gIEluIHRoZSBuZWdvdGlhdGlvbiBzdGFnZSwgdGhlDQo+PiAgIGxvb3AgY291bnQgd2lsbCBz ZXJ2ZSBpdHMgbm9ybWFsIHB1cnBvc2UgKGxpbWl0aW5nIHRoZSBuZWdvdGlhdGlvbiB0bw0KPj4g ICA2IHN0ZXBzIGluIHRoZSBhYm92ZSBleGFtcGxlKS4NCj4+IA0KPj4gMy4gIE9iamVjdGl2ZSBm b3IgQXV0b25vbWljIENvbnRyb2wgUGxhbmUNCj4+IA0KPj4gICBUaGUgQXV0b25vbWljIENvbnRy b2wgUGxhbmUgKEFDUCkNCj4+ICAgW0ktRC5pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBs YW5lXSBjb25zdHJ1Y3RzIGl0c2VsZiB3aXRob3V0DQo+PiAgIG91dHNpZGUgaW50ZXJ2ZW50aW9u LiAgVG8gYWNoaWV2ZSB0aGlzLCBlYWNoIG5vZGUgbmVlZHMgdG8gaWRlbnRpZnkNCj4gICAgICAg ICAgICAgXl5eXl5eXiBzL2ludGVydmVudGlvbi9oZWxwLyA/DQo+PiAgIGl0cyBsaW5rLWxvY2Fs IG5laWdoYm9ycyBvbiBhbGwgaW50ZXJmYWNlcywgYW5kIGFncmVlIG9uIGEgc2VjdXJlDQo+PiAg IGNvbm5lY3Rpb24gbWV0aG9kIHdpdGggZWFjaCBvZiB0aGVtLiAgVGhlcmUgYXJlIGF0IGxlYXN0 IHR3byBwb3NzaWJsZQ0KPj4gICBhcHByb2FjaGVzIGZvciB0aGlzOiBhIGZsb29kaW5nIG1lY2hh bmlzbSwgaW4gd2hpY2ggZWFjaCBub2RlDQo+PiAgIGFubm91bmNlcyBpdHNlbGYgYW5kIGl0IHNl Y3VyaXR5IG1ldGhvZHMgdG8gaXRzIG5laWdoYm9ycywgb3IgYQ0KPj4gICBkaXNjb3ZlcnkgYW5k IG5lZ290aWF0aW9uIG1lY2hhbmlzbSwgaW4gd2hpY2ggZWFjaCBub2RlIGFjdGl2ZWx5DQo+PiAg IGRpc2NvdmVycyBpdHMgbmVpZ2hib3JzLiAgRm9yIHRoZSBtb21lbnQgdGhpcyBkcmFmdCBkZXNj cmliZXMgYm90aA0KPj4gICBtZXRob2RzLg0KPiANCj4+ICAgRm9yIGVpdGhlciBtZXRob2QsIGVh Y2ggbm9kZSBydW5zIGFuIEFTQSB0aGF0IHN1cHBvcnRzIHRoZQ0KPj4gICBjb3JyZXNwb25kaW5n IG9iamVjdGl2ZS4gIFRoaXMgQVNBIHJ1bnMgcGVybWFuZW50bHksIGluIG9yZGVyIHRvDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl4gYWx3 YXlzIHdoZW4gdGhlIEFDUCBpcyBjYXBhYmxlIGFuZCB3aWxsaW5nIHRvIGNvbm5lY3QgdG8gbmVp Z2hiYm9ycw0KPj4gICBkaXNjb3ZlciBvciBkZXRlY3QgbmV3IEFDUCBuZWlnaGJvcnMgb3IgdG8g cmVtb3ZlIGZhaWxlZCBuZWlnaGJvcnMuDQo+PiANCj4+IDMuMS4gIEZsb29kaW5nIEFsdGVybmF0 aXZlDQo+IA0KPiBJbmRpY2F0aW5nIGEgIm1ldGhvZCIgZm9yIHRoZSBwcm90b2NvbCBpcyBhbiB1 bmRlc2lyYWJsZSBhdHRhY2sgdmVjdG9yLg0KPiBUaGF0cyBwcm9iYWJseSB0cnVlIGZvciB0aGUg QlJTS0kgYW5ub3VuY2VtZW50cyBhcyB3ZWxsLCBidXQgaSdsbCBsZXQNCj4gTWF4IGV0Yy4gYXJn dWUgdGhhdCBwb2ludC4NCj4gDQo+IEluIEFDUCwgdGhlIEFDUCBkcmFmdCBkZXNjcmliZXMgaG93 IHRoZSBpbnNlY3VyZSBHUkFTUCBzaWduYWxpbmcgd291bGQNCj4gb25seSBpbmRpY2F0ZSBBTl9B Q1Agd2l0aG91dCBwYXJhbWV0ZXJzLCBhbmQgdGhlbiBhbnkgbmVnb3RpYXRpb24gd291bGQNCj4g aGF2ZSB0byBiZSBzdWJqZWN0IHRvIHRoZSBub2RlIGVpdGhlciBqdXN0IHRyeWluZyB0aGUgbWV0 aG9kcyBpdCBzdXBwb3J0cywNCj4gb3IgYnVpbGRpbmcgYSBUTFMgY29ubmVjdGlvbiBhbmQgcnVu bmluZyBHUkFTUCBpbnNpZGUgZm9yIG5lZ290aWF0aW9uLg0KPiANCj4gSSBkbyBsaWtlIHRoZSBm bG9vZCBhbmQgdGhhdHMgd2hhdCBpIGRlc2NyaWJlZCBpbiBBQ1AgZHJhZnQuIA0KPiANCj4gSSB3 b3VsZCBldmVuIGxpa2UgdG8gc2VlIG10aG9kIGJlaW5nIGluY2x1ZGVkIGluIGl0LA0KPiBidXQg cHVyZWx5IGZvciBvcGVyYXRvciBkaWFnbm9zdGljcy4gRWc6IHRoZSByZWNlaXZpbmcgQVNBIE1V U1QgTk9UDQo+IGNoYW5nZSBpdHMgYmVoYXZpb3IgYmFzZWQgb24gaXQuDQo+IA0KPiBFZzogSGF2 ZSBhIERpYWcgZWxlbWVudCB3aGljaCBtaWdodCBiZSBzdHJ1Y3R1cmVkLCBhbmQgd2hpY2ggYXMg aXQncw0KPiBmaXJzdCBlbGVtZW50IGhhcyB0aGUgIm1ldGhvZHMiIHN1cHBvcnRlZC4gDQo+IA0K PiBJIGhvcGUgdGhlIGRpYWdub3N0aWNzIGJlbmVmaXRzIG91dHdlaWdoIHRoZSBtaW5vciBzZWN1 cml0eWRvd25zaWRlIGl0IGhhcy4NCj4gDQo+PiAzLjIuICBOZWdvdGlhdGlvbiBBbHRlcm5hdGl2 ZQ0KPiANCj4gSXQgc2VlbXMgYXMgaWYgeW91IGhhdmUgbm8gc2VjdGlvbiBmb3IgdGhlIFRMUyBz ZWN1cmVkIG5lZ290aWF0aW9uIGZvciB0aGUNCj4gQUNQIGNoYW5uZWwuICBXaHkgZG8geW91IG5v dCBzaW1wbHkgcmV3b3JkIHRoaXMgMy4yIHRvIGJlIGV4YWN0bHkgdGhhdCA/IA0KPiANCj4gQW5v dGhlciBxdWVzdGlvbjogRm9yIGFsbCB0aG9zZSBzdHJpbmcgbmFtZXMgbGlrZSBmb3IgdGhlICJt ZXRob2QiLA0KPiBkbyB3ZSBuZWVkIHJlZ2lzdHJpZXMgaW4gdGhlIElFVEYgPyANCj4gDQo+PiA0 LiAgT2JqZWN0aXZlIGZvciBTdGFibGUgQ29ubmVjdGl2aXR5IG9mIE5ldHdvcmsgT0FNDQo+IA0K PiBOaWNlLiBMZXQgbWUgZGlzY3VzcyBoaWdoIGxldmVsIHNvbWUgc3RlcHM6DQo+IA0KPiAxLiBU aGUgd2F5IGkgaW1hZ2luZSBpdCwgdGhlIE5PQyBpcyBhIGJ1bmNoIG9mIHNlcnZpY2VzLCBhbmQg bm90IHNwZWNpZmljYWxseQ0KPiAgIGEgc2luZ2xlICJOT0MiIHNlcnZpY2UuIFNvIGZvciBleGFt cGxlLCBlYWNoIEFDUCBub2RlIHNob3VsZCBwZXJmb3JtDQo+ICAgc3lzbG9nIHRvIGEgTk9DIHN5 c2xvZyBzZXJ2aWNlLiBPciBhdXRoZW50aWNhdGUgZGF0YS1wbGFuZQ0KPiAgIHNlc3Npb25zIGlu dG8gdGhlIEFDUCBub2RlIChuZXRjb25mLCBTTk1QLCBTU0gsLi4uKSB2aWEgYSBOT0MNCj4gICBh dXRoZW50aWNhdGlvbiBzZXJ2aWNlIChyYWRpdXMvZGlhbWV0ZXIsLi4uKQ0KPiANCj4gICBBIGJ1 bmNoIG9mIHRoZXNlIHNlcnZpY2VzIGhhdmUgYWxyZWFkeSBkZWZpbmVkIEROUy1TRCBzZXJ2aWNl IG5hbWVzDQo+ICAgYW5kIHNvbWV0aW1lcyBhbHNvIHNlcnZpY2UtcGFyYW1ldGVycy4gU28gYSBz aW1wbGUgZXh0ZW5zaWJsZSBhcHByb2FjaA0KPiAgIHdvdWxkIGJlIHRvIGNvbWUgdXAgd2l0aCBh IHNjaGVtZSBob3cgdG8gbWFwIEROUy1TRCBzZXJ2aWNlIGFubm91bmNlbWVudA0KPiAgIGF0dHJp YnV0ZXMgaW50byBHUkFTUCBvYmplY3RpdmVzIHRoYXQgdGhlIE5PQyBlcXVpcG1lbnQgd291bGQg dGhlbiBmbG9vZA0KPiAgIChmbG9vZGluZyBsaWtlIHlvdSBkZXNjcmliZWQgZm9yIHRoZSByZWdp c3RyYXIgc2VlbXMgbGlrZSB0aGUgZWFzaWVzdA0KPiAgICBzY2FsYWJsZSB3YXkgd2hlbiB0aGUg b2JqZWN0aXZlIGlzIHJlcXVpcmVkIGJ5IHRoZSBtYXlvcml0eSBvZiBBQ1Agbm9kZXMpLg0KPiAN Cj4gICBUaGlzIHdheSB3ZSB3b3VsZCBub3QgaGF2ZSB0byByZWludmVudCB0aGUgd2hvbGUgbmFt ZXNwYWNlIG9mIHNlcnZpY2VzDQo+ICAgYSBOT0MgY291bGQgaGF2ZSwgYW5kIGV2ZW4gaWYgd2Ug aGF2ZSB0byBpbnZlbnQgbmV3IG5hbWVzLCBpdCB3b3VsZG4ndCBiZQ0KPiAgIGluIGEgc2lsbywg YnV0IHdlJ2QgcGljayBuYW1lcyB0aGF0IGFyZSBmcmVlIGluIEROUy1TRCwgYWxsb2NhdGUgdGhl bSB0bw0KPiAgIEROUy1TRCByZWdpc3RyeSwgYW5kIGUgdm9pbGE6IG5vIG5lZWQgdG8gbWFpbnRh aW4gYWRkaXRpb25hbCByZWdpc3RyaWVzIGZvciBpdC4NCj4gDQo+IDIuIFlvdSBhcmUgY29ycmVj dCB0aGF0IHRoZSBOT0Mgc2hvdWxkIGtub3cgYWJvdXQgd2FudGluZyB0byBrbm93IGFib3V0DQo+ ICAgZGV2aWNlcyBpbiB0aGUgbmV0d29yay4gQWxhcywgdGhlcmUgYXJlIGEgYnVuY2ggb2YgdGhp bmdzIHdlIGNvdWxkIGRvLA0KPiAgIGFuZCBpIGFtIG5vdCBzdXJlIGhvdyB3ZSBjb3VsZCBtb3N0 IGVhc2lseSBtYWtlIHByb2dyZXNzLg0KPiANCj4gICBIZXJlJ3Mgcm91Z2hseSBob3cgaSB0aGlu ayBpdCBjb3VsZCBsb29rOg0KPiANCj4gICBOT0MgQUNQLXRvcG9sb2d5IEFTQSBpcyB0aGUgZW50 aXR5IHdhbnRpbmcgdG8gdHJhY2sgbmV0d29yayB0b3BvbG9neS4NCj4gICBJdCB3b3VsZCBhbHNv IGluZGljYXRlIHRvIHNvbWUgYmFja2VuZCB3aGVuZXZlciBuZXcgZGV2aWNlcyBzaG93IHVwLg0K PiAgIFRoZSBwYXJhbWV0ZXJzIHRvIGl0J3Mgb2JqZWN0aXZlIGNvdWxkIGluZGljYXRlIGEgbG90 IG9mIG9wdGlvbnM6DQo+IA0KPiAgIC0gYW5ub3VuY2UgeW91cnNlbGYNCj4gICAgIC0gYWx3YXlz IGFmdGVyIHlvdSd2ZSBjb25uZWN0ZWQNCj4gICAgIC0gb25seSB3aGVuIHlvdSdyZSBpbiAidW5j b25maWd1cmVkIHN0YXRlIg0KPiAgIC0gYW5ub3VuY2UgQUNQIG5laWdoYm9ycw0KPiAgICAgLSB3 aGVuIHRoZXkgY29ubmV0DQo+ICAgICAtIHdoZW4gdGhleSBkaXNjb25uZWN0DQo+IA0KPiAgIEkg YW0gbm90IHN1cmUgaWYgdGhlIGFjdHVhbCBhbm5vdW5jZW1lbnRzIHRoZW4gdG8gdGhpcyBzZXJ2 aWNlIHNob3VsZCBiZQ0KPiAgIGRvbmUgdmlhIEdSQVNQIChhcyBhIG5lZ290aWF0aW9uID8gKSBv ciBzb21lIG90aGVyIHByb3RvY29sLiBTeXNsb2cgY29tZXMNCj4gICB0byBtaW5kLCBidXQgaXQg aGFzIHJlbGlhYmlsaXR5IHByb2JsZW1zLg0KPiANCj4+IDUuICBPYmplY3RpdmVzIGZvciBJbnRl bnQgRGlzdHJpYnV0aW9uDQo+IA0KPiBFeGNlcHQgZm9yIHRoZSBBQ1AgY2hhbm5lbCBwcm90b2Nv bCBuZWdvdGlhdGlvbiwgYWxsIG9mIHRoZSBhYm92ZQ0KPiBpcyBhYm91dCB0aGUgc2ltcGxlIEdS QVNQIGZsb29kLiBXaGljaCBtYWtlcyBtZSBoYXBweSAoYmVjYXVzZSBpdCdzIHNpbXBsZSksDQo+ IGFuZCB5b3UgcHJvYmFibHkgdW5oYXBweSAoYmVjYXVzZSBpdCBkb2Vzbid0IGV4cGxvcmUgYWxs IHRoZSBvcHRpb25zIG9mIEdSQVNQKS4NCj4gDQo+IFNvIGkgd29uZGVyOiBJc24ndCBJbnRlbnQg c29tZXRoaW5nIHdoZXJlIHdlIHdvdWxkIG5lZWQgYSBtb3JlIGludGVsbGlnZW50DQo+IHVzZSBv ZiBHUkFTUCB0aGFuIGp1c3QgZ29vZCBvbCcgZmxvb2QgPw0KPiANCj4gQWthOiBJZiB3ZSBoYWQg YW4gSW50ZW50IGFnZW50IG9uIGV2ZXJ5IEFDUCBub2RlIHRoYXQgaGFzIEdSQVNQDQo+IG5lZ290 aWF0aW9uIHdpdGggZWFjaCBuZWlnaGJvcjogSSBjb3VsZCBtb2RpZnkgaW50ZW50IG9uIGFueSBu b2RlLA0KPiBhbmQgdGhhdCBub2RlIHdvdWxkIG5lZ290aWF0ZSB3aXRoIGl0J3MgbmVpZ2hib3Jz IHRoYXQgaXQgaGFkIGEgbmV3IHZlcnNpb24sDQo+IGFuZCB0aGlzIGlzIHdoYXQgd291bGQgbWFr ZSB0aGF0IG5ldyBpbnRlbnQgZmxvdyBob3AtYnktaG9wIGFjcm9zcyB0aGUNCj4gYXV0b25vbWlj IG5ldHdvcmsgdmlhIEludGVudCBBU0FzLg0KPiANCj4gQW5kIHRoZXJlIGFyZSB0cmlja3kgcGFy dHMgaGVyZTogSWYgdGhlIG5ldHdvcmsgYmVjb21lcyBwYXJ0aXRpb25lZCBhbmQNCj4gaW50ZW50 IGdldHMgbW9kaWZpZWQgb24gYm90aCBzaWRlcyBhbmQgdGhlbiB0aGVyZSBpcyBhIG5ldHdvcmsg bWVyZ2UgYWdhaW4gLQ0KPiBob3cgZG8geW91IHJlc29sdmUgdGhlIGNvbmZsaWN0LiBXaGF0ZXZl ciBtZXRob2Qgb2Ygc2lnbmFsaW5nIHlvdSB1c2UuDQo+IA0KPiBJZiB3ZSB3YW50IHRvIHNvbHZl IHRoZSBwcm9ibGVtIHdpdGggYWJzb2x1dGUgdGltZXN0YW1wcywgaXQgc2VlbXMgdG8gbWUNCj4g YXMgaWYgaSdkIHN0aWxsIG5lZWQgcmVsYXRpdmUgdGltZXN0YW1wczoNCj4gDQo+ICBOZXR3b3Jr IGkgY29ubmVjdGVkIHdob2xlIG5ldHdvcmsgaGF2ZSB2ZXJzaW9uIEkxIHdpdGggb3JpZ2luYXRv cg0KPiAgYXNzaWduZWQgdGltZXN0YW1wIEkxdC4NCj4gDQo+ICBOZXR3b3JrIHBhcnRpdGlvbnMg aW50byBwYXJ0IEEgYW5kIHBhcnQgQi4NCj4gIE5vZGUgaW4gcGFydCBBIG1vZGlmaWVzIGludGVu dCB0byBJMSsxIGF0IHRpbWUgSTF0K3RhLg0KPiAgTm9kZSBpbiBwYXJ0IEIgbW9kaWZpZXMgaW50 ZW50IHRvIEkxKzEgYXQgdGltZSBJMXQrdGIuDQo+IA0KPiAgV2hlbiBuZXR3b3JrIG1lcmdlcywg dGhlIHBvbGljeSBjb3VsZCBiZSB0aGF0IGFsbCBub2RlcyB3b3VsZCBhcHBseQ0KPiAgdGhlIGlu dGVudCB0aGF0IGlzIG5ld2VyLiBlZzogbGV0cyBhc3N1bWUgaW50ZW50IGluIEEgd2FzIGFwcGxp ZWQgbGF0ZXIuDQo+ICBOb2RlcyBpbiBCIHNob3VsZCBiZSBhYmxsZSB0byBmaWd1cmUgdGhpcyBv dXQgYnkgdXNpbmcgdGhlIHJlbGF0aXZlDQo+ICB0aW1lIHRyYWNrZWQgYWdhaW5zdCB0aGUgbGFz dCBhcHBsaWVkIGludGVudCAoSTEvSTF0KS4NCj4gDQo+IENoZWVycw0KPiAgICBUb2VybGVzcw0K PiANCj4+IDYuICBPYmplY3RpdmUgZm9yIFByZWZpeCBNYW5hZ2VtZW50DQo+PiANCj4+ICAgVEJE DQo+PiANCj4+IDcuICBGbG9vZCBGcmVxdWVuY3kNCj4+IA0KPj4gICBBbnkgQVNBIHRoYXQgZmxv b2RzIG9uZSBvZiB0aGUgYWJvdmUgb2JqZWN0aXZlcyBzaG91bGQgZG8gc28gYXQgYQ0KPj4gICBj YXJlZnVsbHkgY2hvc2VuIGZyZXF1ZW5jeS4gIFJlY2lwaWVudCBub2RlcyBtYXkgYmUgc3RhcnRp bmcgdXAsDQo+PiAgIHJlY29ubmVjdGluZywgb3Igd2FraW5nIHVwIGZyb20gc2xlZXAsIHNvIGZs b29kcyBuZWVkIHRvIGJlIHJlZnJlc2hlZA0KPj4gICBwZXJpb2RpY2FsbHkuICBPbiB0aGUgb3Ro ZXIgaGFuZCwgZXhjZXNzaXZlIGZsb29kaW5nIHdpbGwgY29uc3VtZQ0KPj4gICBiYW5kd2lkdGgs IENQVSBhbmQgYmF0dGVyeSBjYXBhY2l0eSB0aHJvdWdob3V0IHRoZSBuZXR3b3JrLCBhbmQgbWln aHQNCj4+ICAgZXZlbiByZXNlbWJsZSBhIERvUyBhdHRhY2suICBBIGdlbmVyYWwgZ3VpZGVsaW5l IGlzIHRvIGZsb29kIGFuDQo+PiAgIG9iamVjdGl2ZSBvbmNlIGltbWVkaWF0ZWx5IGFmdGVyIGl0 cyB2YWx1ZSBpcyBpbml0aWFsaXNlZCBvciBjaGFuZ2VkLA0KPj4gICBhbmQgdGhlbiByZXBlYXQg dGhlIGZsb29kIGF0IGludGVydmFscyBvZiBhdCBsZWFzdCAzMCBzZWNvbmRzLg0KPj4gICBBZGRp dGlvbmFsbHksIHRoZSBmbG9vZGluZyBpbnRlcnZhbCBzaG91bGQgYmUgc2xpZ2h0bHkgaml0dGVy ZWQgdG8NCj4+ICAgYXZvaWQgc3luY2hyb25pY2l0eSB3aXRoIG90aGVyIGZsb29kcy4gIEZpbmFs bHksIHRoZSB2YWx1ZSBvZiBhDQo+PiAgIGZsb29kZWQgb2JqZWN0aXZlIHNob3VsZCBjaGFuZ2Ug YXMgcmFyZWx5IGFzIHBvc3NpYmxlIChvbiBhIHRpbWVzY2FsZQ0KPj4gICBvZiBhdCBsZWFzdCBt aW51dGVzLCBub3Qgc2Vjb25kcykuDQo+PiANCj4+IDguICBTZWN1cml0eSBDb25zaWRlcmF0aW9u cw0KPj4gDQo+PiAgIEdlbmVyYWwgc2VjdXJpdHkgaXNzdWVzIGZvciBHUkFTUCBhcmUgY292ZXJl ZCBpbg0KPj4gICBbSS1ELmlldGYtYW5pbWEtZ3Jhc3BdLiAgU3BlY2lmaWMgaXNzdWVzIHRoYXQg YXJlIG5vdCBtZW50aW9uZWQgYWJvdmUNCj4+ICAgYXJlIGRpc2N1c3NlZCBpbiB0aGUgcmVmZXJl bmNlZCBkcmFmdHMgZm9yIEJSU0tJLCBBQ1AsIHN0YWJsZQ0KPj4gICBjb25uZWN0aXZpdHkgYW5k IEludGVudC4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBDYXJw ZW50ZXIgJiBMaXUgICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDE3ICAgICAgICAgICAgICAg ICAgW1BhZ2UgOF0NCj4+IA0KPj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBBTkkgR1JBU1Ag T2JqZWN0aXZlcyAgICAgICAgICAgICBOb3ZlbWJlciAyMDE2DQo+PiANCj4+IA0KPj4gOS4gIElB TkEgQ29uc2lkZXJhdGlvbnMNCj4+IA0KPj4gICBJQU5BIGlzIHJlcXVlc3RlZCB0byBhZGQgdGhl IGZvbGxvd2luZyBlbnRyaWVzIHRvIHRoZSBHUkFTUCBPYmplY3RpdmUNCj4+ICAgTmFtZXMgVGFi bGUgcmVnaXN0cnkgY3JlYXRlZCBieSBbSS1ELmlldGYtYW5pbWEtZ3Jhc3BdOg0KPj4gICBBTl9y ZWdpc3RyYXINCj4+ICAgQU5fcHJveHkNCj4+ICAgQU5fQUNQDQo+PiAgIEFOX05PQw0KPj4gICBB Tl9pbnRlbnQNCj4+IA0KPj4gMTAuICBBY2tub3dsZWRnZW1lbnRzDQo+PiANCj4+ICAgVEJELg0K Pj4gDQo+PiAxMS4gIFJlZmVyZW5jZXMNCj4+IA0KPj4gMTEuMS4gIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzDQo+PiANCj4+ICAgW0ktRC5ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGxdDQo+PiAg ICAgICAgICAgICAgVmlnYW5vLCBDLiBhbmQgSC4gQmlya2hvbHosICJDQk9SIGRhdGEgZGVmaW5p dGlvbiBsYW5ndWFnZQ0KPj4gICAgICAgICAgICAgIChDRERMKTogYSBub3RhdGlvbmFsIGNvbnZl bnRpb24gdG8gZXhwcmVzcyBDQk9SIGRhdGENCj4+ICAgICAgICAgICAgICBzdHJ1Y3R1cmVzIiwg ZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1jZGRsLTA5ICh3b3JrDQo+PiAgICAgICAg ICAgICAgaW4gcHJvZ3Jlc3MpLCBTZXB0ZW1iZXIgMjAxNi4NCj4+IA0KPj4gICBbSS1ELmlldGYt YW5pbWEtZ3Jhc3BdDQo+PiAgICAgICAgICAgICAgQm9ybWFubiwgQy4sIENhcnBlbnRlciwgQi4s IGFuZCBCLiBMaXUsICJBIEdlbmVyaWMNCj4+ICAgICAgICAgICAgICBBdXRvbm9taWMgU2lnbmFs aW5nIFByb3RvY29sIChHUkFTUCkiLCBkcmFmdC1pZXRmLWFuaW1hLQ0KPj4gICAgICAgICAgICAg IGdyYXNwLTA4ICh3b3JrIGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDE2Lg0KPj4gDQo+PiAxMS4y LiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KPj4gDQo+PiAgIFtJLUQuZHUtYW5pbWEtYW4taW50 ZW50XQ0KPj4gICAgICAgICAgICAgIER1LCBaLiwgSmlhbmcsIFMuLCBOb2JyZSwgSi4sIENpYXZh Z2xpYSwgTC4sIGFuZCBNLg0KPj4gICAgICAgICAgICAgIEJlaHJpbmdlciwgIkFOSU1BIEludGVu dCBQb2xpY3kgYW5kIEZvcm1hdCIsIGRyYWZ0LWR1LQ0KPj4gICAgICAgICAgICAgIGFuaW1hLWFu LWludGVudC0wNCAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxNi4NCj4+IA0KPj4gICBbSS1E LmlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmVdDQo+PiAgICAgICAgICAgICAgQmVo cmluZ2VyLCBNLiwgRWNrZXJ0LCBULiwgYW5kIFMuIEJqYXJuYXNvbiwgIkFuIEF1dG9ub21pYw0K Pj4gICAgICAgICAgICAgIENvbnRyb2wgUGxhbmUiLCBkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21p Yy1jb250cm9sLQ0KPj4gICAgICAgICAgICAgIHBsYW5lLTA0ICh3b3JrIGluIHByb2dyZXNzKSwg T2N0b2JlciAyMDE2Lg0KPj4gDQo+PiAgIFtJLUQuaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtl eWluZnJhXQ0KPj4gICAgICAgICAgICAgIFByaXRpa2luLCBNLiwgUmljaGFyZHNvbiwgTS4sIEJl aHJpbmdlciwgTS4sIEJqYXJuYXNvbiwNCj4+ICAgICAgICAgICAgICBTLiwgYW5kIEsuIFdhdHNl biwgIkJvb3RzdHJhcHBpbmcgUmVtb3RlIFNlY3VyZSBLZXkNCj4+ICAgICAgICAgICAgICBJbmZy YXN0cnVjdHVyZXMgKEJSU0tJKSIsIGRyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy0NCj4+ ICAgICAgICAgICAgICBrZXlpbmZyYS0wNCAod29yayBpbiBwcm9ncmVzcyksIE9jdG9iZXIgMjAx Ni4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBDYXJwZW50ZXIgJiBMaXUgICAgICAgICAg IEV4cGlyZXMgTWF5IDIyLCAyMDE3ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCj4+IA0KPj4g SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBBTkkgR1JBU1AgT2JqZWN0aXZlcyAgICAgICAgICAg ICBOb3ZlbWJlciAyMDE2DQo+PiANCj4+IA0KPj4gICBbSS1ELmlldGYtYW5pbWEtcmVmZXJlbmNl LW1vZGVsXQ0KPj4gICAgICAgICAgICAgIEJlaHJpbmdlciwgTS4sIENhcnBlbnRlciwgQi4sIEVj a2VydCwgVC4sIENpYXZhZ2xpYSwgTC4sDQo+PiAgICAgICAgICAgICAgUGllcnJlLCBQLiwgTGl1 LCBCLiwgTm9icmUsIEouLCBhbmQgSi4gU3RyYXNzbmVyLCAiQQ0KPj4gICAgICAgICAgICAgIFJl ZmVyZW5jZSBNb2RlbCBmb3IgQXV0b25vbWljIE5ldHdvcmtpbmciLCBkcmFmdC1pZXRmLQ0KPj4g ICAgICAgICAgICAgIGFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMiAod29yayBpbiBwcm9ncmVzcyks IEp1bHkgMjAxNi4NCj4+IA0KPj4gICBbSS1ELmlldGYtYW5pbWEtc3RhYmxlLWNvbm5lY3Rpdml0 eV0NCj4+ICAgICAgICAgICAgICBFY2tlcnQsIFQuIGFuZCBNLiBCZWhyaW5nZXIsICJVc2luZyBB dXRvbm9taWMgQ29udHJvbA0KPj4gICAgICAgICAgICAgIFBsYW5lIGZvciBTdGFibGUgQ29ubmVj dGl2aXR5IG9mIE5ldHdvcmsgT0FNIiwgZHJhZnQtaWV0Zi0NCj4+ICAgICAgICAgICAgICBhbmlt YS1zdGFibGUtY29ubmVjdGl2aXR5LTAxICh3b3JrIGluIHByb2dyZXNzKSwgSnVseQ0KPj4gICAg ICAgICAgICAgIDIwMTYuDQo+PiANCj4+IEFwcGVuZGl4IEEuICBDaGFuZ2UgbG9nIFtSRkMgRWRp dG9yOiBQbGVhc2UgcmVtb3ZlXQ0KPj4gDQo+PiAgIGRyYWZ0LWNhcnBlbnRlci1hbmltYS1hbmkt b2JqZWN0aXZlcy0wMCwgMjAxOC0xMS0xNToNCj4+IA0KPj4gICBJbml0aWFsIHZlcnNpb24NCj4+ IA0KPj4gQXV0aG9ycycgQWRkcmVzc2VzDQo+PiANCj4+ICAgQnJpYW4gQ2FycGVudGVyDQo+PiAg IERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZQ0KPj4gICBVbml2ZXJzaXR5IG9mIEF1Y2ts YW5kDQo+PiAgIFBCIDkyMDE5DQo+PiAgIEF1Y2tsYW5kICAxMTQyDQo+PiAgIE5ldyBaZWFsYW5k DQo+PiANCj4+ICAgRW1haWw6IGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbQ0KPj4gDQo+PiAN Cj4+ICAgQmluZyBMaXUNCj4+ICAgSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZA0KPj4gICBR MTQsIEh1YXdlaSBDYW1wdXMNCj4+ICAgTm8uMTU2IEJlaXFpbmcgUm9hZA0KPj4gICBIYWktRGlh biBEaXN0cmljdCwgQmVpamluZyAgMTAwMDk1DQo+PiAgIFAuUi4gQ2hpbmENCj4+IA0KPj4gICBF bWFpbDogbGVvLmxpdWJpbmdAaHVhd2VpLmNvbQ0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBDYXJwZW50ZXIgJiBMaXUg ICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAxMF0N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEFuaW1hIG1haWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg== From nobody Thu Nov 17 16:16:17 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C571296BD for ; Thu, 17 Nov 2016 16:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozNmkqkWUQNy for ; Thu, 17 Nov 2016 16:16:13 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244A01297BD for ; Thu, 17 Nov 2016 16:16:13 -0800 (PST) Received: from dooku.sandelman.ca (s2001067c037001280a1196fffe0181e0.v6.meeting.ietf.org [IPv6:2001:67c:370:128:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id BDB7C1F8F0 for ; Fri, 18 Nov 2016 00:16:11 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0161433F1; Fri, 18 Nov 2016 09:16:08 +0900 (KST) From: Michael Richardson To: Anima WG In-reply-to: <9f37a834-3f9f-fda8-447d-9aab8ddee0a4@cisco.com> References: <99979052-9b80-7751-a0b3-89f509df3cb2@cisco.com> <9f37a834-3f9f-fda8-447d-9aab8ddee0a4@cisco.com> Comments: In-reply-to Eliot Lear message dated "Thu, 17 Nov 2016 11:11:45 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 18 Nov 2016 09:16:08 +0900 Message-ID: <24792.1479428168@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] additional information and JSON/CBOR X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 00:16:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > but we need to know how to hook in. Specifically we're aiming to > provide the address of the resource directory, preferably in a way th= at > is signed by the registrar. I feel that I'm missing some context, so let me repeat. You'd like to have a link to a resource directory, and you'd like to have it signed by registrar. I just want quibble slightly: while the registrar MAY be the CA, it isn't always directly the CA, it doesn't necessary have that kind of CA abilities. On the other hand, "signed by the registrar" could mean that it came through the (D)TLS connection from the Registrar, so maybe that's enough. In which case, let me repeat part of Max's response: max> Possibility-3) Introduce a followup REST message that the Pledge MAY u= se max> to obtain the configuration after s5.3.1 is complete. This allows the max> TLS connection to be maintained and optimizes the flow but keeps the max> distinct REST api calls from being overloaded. It is most consistent max> with section 5.7 and is probably the approach I=E2=80=99d prefer. Using max> persistent connections this is close to the optimization provided by 1 max> or 2 and allows for simpler handling on the Pledge. I definitely prefer that keeping up. I would suggest that a TLS resumption ticket be obtained and stored long term. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYLkhIAAoJEJVM4Vb9/EKQ4XAH/0yXkTTzdqmFPK0rbb0lX7I1 0zGIVlt2F6syU26+XKzQpkNPPeH6EDAGTwGtPRh6cw8YlYYYDopr8S0S6z2ztGgt ZYJcU6d1Mo+tSizm0VaLW9hgg8eKtf1U+AVPqp5XhpfJHQNZ5LWgUFFp//jL5oGI qgcL+LYODCYBGIxS3pEzN3xLN2mnxAlsJdxcFdZ9As0XMYd9+7jspsTDLgGTJ/Qy E5fL2An01DS/R5tWhr7F3UYy7a4X/zudKLZye28vz6b+t2QaGT060NevIQeiB3es ZkPqnLmwLFn34EQ45rjLcl3yOVHrH58iehwIlN7B/Myii3tlgn3X71xFRvTvb6E= =aKbF -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 17 16:35:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637571295A4 for ; Thu, 17 Nov 2016 16:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sBScJlfB3ES for ; Thu, 17 Nov 2016 16:35:20 -0800 (PST) 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 EB78E128E18 for ; Thu, 17 Nov 2016 16:35:19 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id f188so96355618pgc.3 for ; Thu, 17 Nov 2016 16:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QsNiYN3k0/lflr1vlg3Y8FXTPpnzPEVsPvt8oORBJoY=; b=MsLtSoE6lClnJxDCQz4asvfwK2HCAfU8uoma2pwkQpArnCtatS2cd44Sox5vyv9u5M WKRC7rS4cLnJL//NgLgoZ00pLCZpKM8JQ1fX5qG8U09oQy1qISkunY5EqZwq1XX33/PV vToChhcLS7r5DctNiQN/zPwepjg0QQZFt/kSn3hKq8OcQaa12XgIfryt8ub3shCYOZWn ilglDrTWUi7DmSAlBd9ZRW0vv1orrOdETcTgVeIqtJIPkecxr7IWTYHGN+p2SeDTrxCA L6/7aegYPV/P9MnpRc1dqvInDXH/DNqYIhgKspfxwnJJY3MSnNkMgtwIhVKudXmYAvUf lp7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=QsNiYN3k0/lflr1vlg3Y8FXTPpnzPEVsPvt8oORBJoY=; b=LUfZ4Wye2DJ+i5WF91giZdxYh3xSj7FKBgRuuQF3tFrIjL2SkruFqUNIhLrVh7SqK7 asis4BBUSMSEsf934SD5VMiOJjezcE2Ks9GO9Y/SMd0z+OOu+WlbPw0VMxrJ2BDhlfq6 bSRqMKsnWJGocFmHPrRPZk2tQIF2/SHnAv+DNjkvDyJF3Qv2b24oorNlkKinObGzdLgf tXMHuXPyrzCOT4Ak3qCXAqsqa8HqGiX7LW70wsyL1sywrYAeFLrBfW3lsGPTF/rpWzXz 8/afyna43yfs8a845c1dK9UjTl0MDsZbcI2CpHdCHPWP93831LKlaxSSVoQUhLcEWjZ1 od0g== X-Gm-Message-State: ABUngvffRUj+MgqR+NNJC0YFhabnCnWH+IqbxlTBqdTHrStrGjAjvCEyxyyeJ+b7Xn3Yow== X-Received: by 10.99.219.81 with SMTP id x17mr12658624pgi.138.1479429318867; Thu, 17 Nov 2016 16:35:18 -0800 (PST) Received: from [192.168.178.23] (117.228.69.111.dynamic.snap.net.nz. [111.69.228.117]) by smtp.gmail.com with ESMTPSA id 89sm11095378pfi.70.2016.11.17.16.35.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 16:35:17 -0800 (PST) To: "Max Pritikin (pritikin)" , Toerless Eckert References: <20161117221750.GA23347@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 18 Nov 2016 13:35:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 00:35:23 -0000 Max, Cherry-picking your comments; I will respond to Toerless's detailed comments later: On 18/11/2016 12:33, Max Pritikin (pritikin) wrote: > Some comments on the BRSKI discussion inline,=20 >=20 >> On Nov 17, 2016, at 3:17 PM, Toerless Eckert wrote: >> >> >> Thanks Brian & Bing >> >> Inline >> >=20 > The following quote levels appear to be direct or paraphrases from the = objectives draft. > I=E2=80=99m tempted not even to respond to this email thread due to the= sloppy quoting but we=E2=80=99ll see how it goes.=20 >=20 >>> This document defines several technical objectives for use with for= >> ^^^^^^^^^^^^^^^^^^^^ >>> the Generic Autonomic Signaling Protocol (GRASP) >>> [I-D.ietf-anima-grasp]. >=20 > [snip] I=E2=80=99m focusing on just bootstrap discussions >=20 >>> Secure Bootstrap. >> >> ANI use case: bootstrapping autonomic devices, non-ANI use case: boots= trapping >> non-autonomic devices. >=20 > Since its objectives for autonomic I don=E2=80=99t see that discussing = non-autonomic is necessary in this document.=20 > The broader point that BRSKI need not be forced to be ANI specific is i= mportant to re-enfoce, so thank you.=20 Indeed. The context is when the pledge is GRASP-capable; for other pledge= s, mDNS applies. >> >>> Autonomic Control Plane (ACP). >> >> Part of the ANI, serving autonomic and non-autonomic use cases. >> >>> Stable Connectivity of Network OAM. >> >> Primarily non-autonomic as it discusses SDN management via the ACP wit= hout >> intent being involved (yet). >> >>> Intent Distribution. >> >> ANI use case. >> >> ... >>> 2. Objectives for Secure Bootstrap >>> >>> Three components are involved in the Bootstrapping Remote Secure Ke= y >> ^^ insert ANI >>> Infrastructures (BRSKI) process described in >>> [I-D.ietf-anima-bootstrapping-keyinfra]: the Registrar, the Join >>> Assistant (or Proxy), and the Joining Node (or Pledge).=20 >> >> Pls. get the final official word for proxy/pledge. we're carrying arou= nd >> too many terms and repeating them everywhere. >=20 > Pledge, Proxy, Registrar, MASA OK. Michael Richardson pointed out that other efforts use the other terms= =2E >=20 >> >> Note: ... Bootstrapping has more functions, such as MASA and CA, but w= e >> do not foresee the need for GRASP signalling with them at this time. >> >>> The proxy >>> and the pledge are attached to the same link-layer and use link-loc= al >>> communications only, to minimize exposure to eavesdroppers and >>> malicious nodes. >> >> I think this is not the right security claim to make. We do have impor= tant >> use-cases where the proxy MUST be remote, eg: when i attach a >> pledge to just an open internet connection without any prior ANI >> in the vicinity. And the security comparison of this setup vs. the one= with >> L2 is kinda complex and should maybe not had in this doc.=20 >> >> I'd suggest: >> >> Operationally, the most simple case is when proxy and pledge have a >> link-local connection between each other. In this case, mutual discove= ry and >> bootstrap can happen without any prior provisioning of helper informat= ion >> such as DHCP parameters or DNS entries through which the pledge would = have >> to find the proxy otherwise. Instead, link-local multicast with GRASP = can and >> will be used. >=20 > This framing is probably better. We also must note that the Pledge requ= irement to work when the proxy is remote also means those Pledges must su= pport the DNS mechanisms. Adding GRASP is truly an addition to the method= s not a replacement or an optimization. Sure. >=20 >>> There may be multiple hops between the proxy and >>> the registrar. >> >> Between registrar and proxy, there can and likely will be multiple hop= s, >> but in an autonomic network, these hops will have autoconfigured ACP a= nd >> GRASP forwarders between them, so this connectivity too is zero-touch = like >> the link-local connectivity beteeen pledge and proxy. >> >>> Therefore, two different GRASP objectives are >>> required: one that is used over an existing secure network between >> the (ACP) >>> the registrar and the proxy, and another that is used over an >>> insecure link-local hop between the proxy and the pledge. The >>> security aspects and the corresponding limited instances of GRASP a= re >>> discussed in [I-D.ietf-anima-bootstrapping-keyinfra] and >>> [I-D.ietf-anima-grasp]. >> >> And i need to check ACP draft ifhow i capture that fact there as well.= >> Especially that each ACP node needs to run a GRASP forwarder for that >> hop-by-hop forwarding of the GRASP flood - securely. >> >>> Note that since secure bootstrap takes place, by definition, on an >>> incompletely secure network, the use of any protocol needs to be ke= pt >>> as simple and limited as possible. Therefore, only one GRASP messa= ge >>> type is used - flooding - to avoid giving away any unnecessary >>> information by any node involved. >> >> Suggest to move that paragraph up before the proxy/registrar text to >> make reading easier. >> >>> A registrar announces itself to potential proxies by use of the >>> "AN_registrar" objective. This is a synchronization objective >>> primarily intended to be flooded throughout the network using the >>> GRASP Flood Synchronization (M_FLOOD) message. In accordance with >>> the design of the Flood message, a locator consisting of a specific= >>> IP address, IP protocol number and port number will be distributed >>> with the flooded objective. An example of the objective is >>> informally: >>> >>> ["AN_registrar", F_SYNCH, loop_count, [7, "BRSKI-TLS"]] >>> >>> The formal CDDL definition is >>> >>> registrar-objective =3D ["AN_registrar", F_SYNCH, loop-count, [radi= us, >>> method]] >>> >>> radius =3D uint ; loop-count at the source node >>> method =3D text ; name of the BRSKI method supported >>> >>> The 'radius' parameter allows a proxy that receives this message to= >>> determine its distance in hops from the registrar, by subtracting t= he >>> received 'loop-count' from 'radius=E2=80=99. >=20 > I=E2=80=99m not seeing a discussion of distance as a selection method w= ithin GRASP. Is the ability to provide distance metrics a goal of GRASP? = Is it specific to bootstrapping? There is no discussion of logic using th= is form of metric in the BRSKI document. OK, well, a while back Toerless sort of asked for this. He also asked for= priority and weight (like mDNS offers) which I could add in the same way. If BRSKI= is happy with just picking an arbitary registrar if there are several, we can drop= it. >=20 >> *rotfl* when i read the word radius i asked myself why we would do any= thing >> with the radius protocol here. Diameter is also overloaded.=20 >> "sender-loop-count" would be most descriptive. >> >> Also, i would suggest to remove the informal representation and rather= put >> the information into the comments of the formal description: >> >> >> sender-loop-count =3D uint ; loop-count at the source node >> ; 255 is a good default. May use smaller = values >> ; if diameter of ACP network is known >> method =3D text ; Name of BRSKI metho supported >> ; eg: "BRSKI-TLS" >> ; Should have some pointer to where value= s are defined. >> >>> The 'method' parameter indicates the specific BRSKI method availabl= e >>> at the given locator. The initial possible values are "BRSKI-TLS" >>> and "BRSKI-COAP". A registrar that supports more than one method >>> will flood multiple versions of the "AN_registrar" objective. >> >> Just curious: If it would be possible to encode multiple methods in a >> single objective, why would you prefer to use different ones ? >> >> My preference for different objectives would be as follows, and maybe = that's >> good text to have: >> >> A different objective is used for each method to most easy support >> the option that independent ASAs are providing the registrar function = for >> different methods. For example, BRSKI-COAP would most likely be focuss= ed >> to help enrol also non-autonomic pledges and could have a range of >> aspects that would make implementation in a separate ASA beneficial >> (eg: different scale/policies for non-autonomic pledges). >> >> Another point to mention is the timing of this, eg: >> >> Active Registrars will send this objective flood announcement periodic= ally >> (whats a good periodicity ?). Proxies will discovery these messages. >> A proxy can be active whenever it knows one or more registrars. >> >> And then what happens when a registrar fails: >> - Can we describe the timeout behavior, >=20 > This would be covered by the GRASP s3.5.4.3 =E2=80=98lifetime=E2=80=99 = discussion? I don=E2=80=99t see it as specific to bootstrapping. Yes. Both discovery and flood support a TTL, and I assume MDNS does too. = So when any ASA goes away, its objectives will vanish at most TTL later. It's easy to write ro= bust code that survives that. Demo at https://www.cs.auckland.ac.nz/~brian/graspy/b= rski/ ;-) >> eg: when/how will proxy learn >> that the registrar went away. Does a registrar ASA that is going do= wn >> in a controlled fashion have a way to explicitly withdraw the objec= tive ? >=20 > I don=E2=80=99t see any discussion of deletion in the main GRASP docume= nt. How does that work?=20 Caches time out. Do we need to say more? Probably this belongs in draft-c= arpenter-anima-asa-guidelines Brian > - max >=20 >> >> I know, this text/these questions would go beyoond just defining the >> objective encoding, but i think it would help a lot to have this type >> of concise summary of the GRASP objective behavior. >> >>> 2.1. Flooding Alternative for Proxy >>> >>> A proxy announces itself to potential pledges by use of the >>> "AN_proxy" objective. This is a synchronization objective primaril= y >>> intended to be flooded on a single link using the GRASP Flood >>> Synchronization (M_FLOOD) message. In accordance with the design o= f >>> the Flood message, a locator consisting of a specific link-local IP= >>> address, IP protocol number and port number will be distributed wit= h >>> the flooded objective. An example of the objective is informally: >>> >>> ["AN_proxy", F_SYNCH, 1, "BRSKI-TLS"] >>> >>> The formal CDDL definition is >>> >>> proxy-objective =3D ["AN_proxy", F_SYNCH, 1, method] >>> method =3D text ; name of the BRSKI method supported >>> >>> The loop-count is fixed at 1 since this is a link-local operation. >> >> Unless we want to add this TTL forwarding detection scheme whose name = i forgot. >> (set TTL to 255, ignore on receiver messages with lower TTL). >> >>> The 'method' parameter indicates the specific BRSKI method availabl= e >>> at the given locator. The initial possible values are "BRSKI-TLS" >>> and "BRSKI-COAP". A proxy that supports more than one method will >>> flood multiple versions of the "AN_proxy" objective. >>> >>> 2.2. Negotiation Alternative for Proxy >>> >>> This alternative to "AN_proxy" uses additional features of GRASP. = It >>> requires additional complexity in the pledge, and requires the pled= ge >>> to announce its existence to any on-link eavesdroppers via a >>> Discovery message. It is therefore not recommended on security >>> grounds, but is defined here for completeness. >> >> That paragraph does not sound like the best sales pitch. And again, i= am >> not sure if the negative security assessment you make is correct. >> >> First of all, maybe move to an appendix given how this goes beyond=20 >> our MTI (Mandatory To Implement). >> >> Secondly: flooding announcements from proxies to pledges is based on >> security assumptions that the network info (with proxies on the edge) = is >> well secured/protected, and that pledges are more vulnerable. Attacker= s >> wold have to become active with flood multicasts to find a pledge whic= h would >> otherwise be quiet. And those attacker flood multicasts can be detecte= d. >> >> Eg: when we'd turn it around like you describe here, attackers could j= ust >> unicast answer to pledges and therefore attack the pledge with less >> of a visible trail (aka: a valid proxy would not necessarily see the u= nicast >> traffic between attacker and pledge). >> >> But lets turn the assumptions around: In IoT, one might be foremost >> concerned about the security of the infra (with the proxies). Let thos= e >> pledges multicast for bootstrap help, but our proxy may GRASP respond = only >> when it feels that's safe. For example, if the link between pledge and= proxy >> is some IoT radio with some vendor encryption/security (like in a lot = of >> low-power radio options), this argument might fly and make this order >> of signaling preferrable. >> >>> A pledge discovers a local proxy and negotiates a BRSKI method with= >>> it by use of the "AN_join" objective. First, the pledge performs >>> GRASP discovery, with the loop-count set to 1 and limited to link- >>> local addresses. If multiple responses occur, it chooses one by an= >>> >>> implementation-defined method. Then the pledge initiates GRASP >>> negotiation to choose a mutually acceptable BRSKI method. >>> >>> An example of the objective is informally: >>> >>> ["AN_join", F_NEG, 6, ["BRSKI-COAP","BRSKI-TLS"]] >>> >>> The formal CDDL definition is >>> >>> join-objective =3D ["AN_join", F_NEG, loop-count, [*method]] >>> method =3D text ; name of the BRSKI method supported >>> >>> The parties will negotiate until one side proposes a single BRSKI >>> method and the other side accepts. In the simplest case of immedia= te >>> acceptance, there will only be two messages (Request Negotiate and >>> End Negotiate). The locator (IP address, IP protocol number, port >>> number) used for the negotiation will be available for the subseque= nt >>> BRSKI operations, if required. >>> >>> Note that in the Discovery message, the loop count will be set to 1= >>> to limit discovery to the local link. In the negotiation stage, th= e >>> loop count will serve its normal purpose (limiting the negotiation = to >>> 6 steps in the above example). >>> >>> 3. Objective for Autonomic Control Plane >>> >>> The Autonomic Control Plane (ACP) >>> [I-D.ietf-anima-autonomic-control-plane] constructs itself without >>> outside intervention. To achieve this, each node needs to identify= >> ^^^^^^^ s/intervention/help/ ? >>> its link-local neighbors on all interfaces, and agree on a secure >>> connection method with each of them. There are at least two possib= le >>> approaches for this: a flooding mechanism, in which each node >>> announces itself and it security methods to its neighbors, or a >>> discovery and negotiation mechanism, in which each node actively >>> discovers its neighbors. For the moment this draft describes both >>> methods. >> >>> For either method, each node runs an ASA that supports the >>> corresponding objective. This ASA runs permanently, in order to >> ^^^^^^^^^^^ always when th= e ACP is capable and willing to connect to neighbbors >>> discover or detect new ACP neighbors or to remove failed neighbors.= >>> >>> 3.1. Flooding Alternative >> >> Indicating a "method" for the protocol is an undesirable attack vector= =2E >> Thats probably true for the BRSKI announcements as well, but i'll let >> Max etc. argue that point. >> >> In ACP, the ACP draft describes how the insecure GRASP signaling would= >> only indicate AN_ACP without parameters, and then any negotiation woul= d >> have to be subject to the node either just trying the methods it suppo= rts, >> or building a TLS connection and running GRASP inside for negotiation.= >> >> I do like the flood and thats what i described in ACP draft.=20 >> >> I would even like to see mthod being included in it, >> but purely for operator diagnostics. Eg: the receiving ASA MUST NOT >> change its behavior based on it. >> >> Eg: Have a Diag element which might be structured, and which as it's >> first element has the "methods" supported.=20 >> >> I hope the diagnostics benefits outweigh the minor securitydownside it= has. >> >>> 3.2. Negotiation Alternative >> >> It seems as if you have no section for the TLS secured negotiation for= the >> ACP channel. Why do you not simply reword this 3.2 to be exactly that= ?=20 >> >> Another question: For all those string names like for the "method", >> do we need registries in the IETF ?=20 >> >>> 4. Objective for Stable Connectivity of Network OAM >> >> Nice. Let me discuss high level some steps: >> >> 1. The way i imagine it, the NOC is a bunch of services, and not speci= fically >> a single "NOC" service. So for example, each ACP node should perform= >> syslog to a NOC syslog service. Or authenticate data-plane >> sessions into the ACP node (netconf, SNMP, SSH,...) via a NOC >> authentication service (radius/diameter,...) >> >> A bunch of these services have already defined DNS-SD service names >> and sometimes also service-parameters. So a simple extensible approa= ch >> would be to come up with a scheme how to map DNS-SD service announce= ment >> attributes into GRASP objectives that the NOC equipment would then f= lood >> (flooding like you described for the registrar seems like the easies= t >> scalable way when the objective is required by the mayority of ACP = nodes). >> >> This way we would not have to reinvent the whole namespace of servic= es >> a NOC could have, and even if we have to invent new names, it wouldn= 't be >> in a silo, but we'd pick names that are free in DNS-SD, allocate the= m to >> DNS-SD registry, and e voila: no need to maintain additional registr= ies for it. >> >> 2. You are correct that the NOC should know about wanting to know abou= t >> devices in the network. Alas, there are a bunch of things we could d= o, >> and i am not sure how we could most easily make progress. >> >> Here's roughly how i think it could look: >> >> NOC ACP-topology ASA is the entity wanting to track network topology= =2E >> It would also indicate to some backend whenever new devices show up.= >> The parameters to it's objective could indicate a lot of options: >> >> - announce yourself >> - always after you've connected >> - only when you're in "unconfigured state" >> - announce ACP neighbors >> - when they connet >> - when they disconnect >> >> I am not sure if the actual announcements then to this service shoul= d be >> done via GRASP (as a negotiation ? ) or some other protocol. Syslog = comes >> to mind, but it has reliability problems. >> >>> 5. Objectives for Intent Distribution >> >> Except for the ACP channel protocol negotiation, all of the above >> is about the simple GRASP flood. Which makes me happy (because it's si= mple), >> and you probably unhappy (because it doesn't explore all the options o= f GRASP). >> >> So i wonder: Isn't Intent something where we would need a more intelli= gent >> use of GRASP than just good ol' flood ? >> >> Aka: If we had an Intent agent on every ACP node that has GRASP >> negotiation with each neighbor: I could modify intent on any node, >> and that node would negotiate with it's neighbors that it had a new ve= rsion, >> and this is what would make that new intent flow hop-by-hop across the= >> autonomic network via Intent ASAs. >> >> And there are tricky parts here: If the network becomes partitioned an= d >> intent gets modified on both sides and then there is a network merge a= gain - >> how do you resolve the conflict. Whatever method of signaling you use.= >> >> If we want to solve the problem with absolute timestamps, it seems to = me >> as if i'd still need relative timestamps: >> >> Network i connected whole network have version I1 with originator >> assigned timestamp I1t. >> >> Network partitions into part A and part B. >> Node in part A modifies intent to I1+1 at time I1t+ta. >> Node in part B modifies intent to I1+1 at time I1t+tb. >> >> When network merges, the policy could be that all nodes would apply >> the intent that is newer. eg: lets assume intent in A was applied lat= er. >> Nodes in B should be ablle to figure this out by using the relative >> time tracked against the last applied intent (I1/I1t). >> >> Cheers >> Toerless >> >>> 6. Objective for Prefix Management >>> >>> TBD >>> >>> 7. Flood Frequency >>> >>> Any ASA that floods one of the above objectives should do so at a >>> carefully chosen frequency. Recipient nodes may be starting up, >>> reconnecting, or waking up from sleep, so floods need to be refresh= ed >>> periodically. On the other hand, excessive flooding will consume >>> bandwidth, CPU and battery capacity throughout the network, and mig= ht >>> even resemble a DoS attack. A general guideline is to flood an >>> objective once immediately after its value is initialised or change= d, >>> and then repeat the flood at intervals of at least 30 seconds. >>> Additionally, the flooding interval should be slightly jittered to >>> avoid synchronicity with other floods. Finally, the value of a >>> flooded objective should change as rarely as possible (on a timesca= le >>> of at least minutes, not seconds). >>> >>> 8. Security Considerations >>> >>> General security issues for GRASP are covered in >>> [I-D.ietf-anima-grasp]. Specific issues that are not mentioned abo= ve >>> are discussed in the referenced drafts for BRSKI, ACP, stable >>> connectivity and Intent. >>> >>> >>> >>> >>> >>> >>> >>> >>> Carpenter & Liu Expires May 22, 2017 [Page= 8] >>> >>> Internet-Draft ANI GRASP Objectives November 2= 016 >>> >>> >>> 9. IANA Considerations >>> >>> IANA is requested to add the following entries to the GRASP Objecti= ve >>> Names Table registry created by [I-D.ietf-anima-grasp]: >>> AN_registrar >>> AN_proxy >>> AN_ACP >>> AN_NOC >>> AN_intent >>> >>> 10. Acknowledgements >>> >>> TBD. >>> >>> 11. References >>> >>> 11.1. Normative References >>> >>> [I-D.greevenbosch-appsawg-cbor-cddl] >>> Vigano, C. and H. Birkholz, "CBOR data definition langua= ge >>> (CDDL): a notational convention to express CBOR data >>> structures", draft-greevenbosch-appsawg-cbor-cddl-09 (wo= rk >>> in progress), September 2016. >>> >>> [I-D.ietf-anima-grasp] >>> Bormann, C., Carpenter, B., and B. Liu, "A Generic >>> Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-= >>> grasp-08 (work in progress), October 2016. >>> >>> 11.2. Informative References >>> >>> [I-D.du-anima-an-intent] >>> Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. >>> Behringer, "ANIMA Intent Policy and Format", draft-du- >>> anima-an-intent-04 (work in progress), July 2016. >>> >>> [I-D.ietf-anima-autonomic-control-plane] >>> Behringer, M., Eckert, T., and S. Bjarnason, "An Autonom= ic >>> Control Plane", draft-ietf-anima-autonomic-control- >>> plane-04 (work in progress), October 2016. >>> >>> [I-D.ietf-anima-bootstrapping-keyinfra] >>> Pritikin, M., Richardson, M., Behringer, M., Bjarnason, >>> S., and K. Watsen, "Bootstrapping Remote Secure Key >>> Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping= - >>> keyinfra-04 (work in progress), October 2016. >>> >>> >>> >>> >>> >>> Carpenter & Liu Expires May 22, 2017 [Page= 9] >>> >>> Internet-Draft ANI GRASP Objectives November 2= 016 >>> >>> >>> [I-D.ietf-anima-reference-model] >>> Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,= >>> Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A >>> Reference Model for Autonomic Networking", draft-ietf- >>> anima-reference-model-02 (work in progress), July 2016. >>> >>> [I-D.ietf-anima-stable-connectivity] >>> Eckert, T. and M. Behringer, "Using Autonomic Control >>> Plane for Stable Connectivity of Network OAM", draft-iet= f- >>> anima-stable-connectivity-01 (work in progress), July >>> 2016. >>> >>> Appendix A. Change log [RFC Editor: Please remove] >>> >>> draft-carpenter-anima-ani-objectives-00, 2018-11-15: >>> >>> Initial version >>> >>> Authors' Addresses >>> >>> Brian Carpenter >>> Department of Computer Science >>> University of Auckland >>> PB 92019 >>> Auckland 1142 >>> New Zealand >>> >>> Email: brian.e.carpenter@gmail.com >>> >>> >>> Bing Liu >>> Huawei Technologies Co., Ltd >>> Q14, Huawei Campus >>> No.156 Beiqing Road >>> Hai-Dian District, Beijing 100095 >>> P.R. China >>> >>> Email: leo.liubing@huawei.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Carpenter & Liu Expires May 22, 2017 [Page = 10] >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Thu Nov 17 17:19:41 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FF3126579 for ; Thu, 17 Nov 2016 17:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4K1WYt671Hrb for ; Thu, 17 Nov 2016 17:19:35 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DE61294A9 for ; Thu, 17 Nov 2016 17:19:33 -0800 (PST) Received: from dooku.sandelman.ca (s2001067c037001280a1196fffe0181e0.v6.meeting.ietf.org [IPv6:2001:67c:370:128:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 3D9B51F8F0 for ; Fri, 18 Nov 2016 01:19:32 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2E3A233F1; Fri, 18 Nov 2016 10:19:27 +0900 (KST) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 18 Nov 2016 10:19:27 +0900 Message-ID: <29627.1479431967@dooku.sandelman.ca> Archived-At: Subject: [Anima] red/yellow/green lights for bootstrap and ACP feedback X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:19:37 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We discussed today in the meeting that the bootstrap (and overall anima-reference-model state machine) should indicate in it's failure transitions whether the failure is permanent, "red light", and whether it is a "yellow light" (try again). We may also need an "orange light" which means, "failed, but requires NMS i= ntervention" We didn't have time to get a sense from the room whether or not this kind of feedback (which may ideally, be real physical feedback to the installer) is valuable. Of course, devices with bigger displays might want to provide mo= re details about the process... {I recall the three-digit display on the RS/6000, and the mystery that ensued when I had a code come up that IBM support couldn't explain....} =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYLlceAAoJEJVM4Vb9/EKQEwQH/j+A0SBGtrOkXSJwoQ+U04Bc 0RSKO2JwU//c9eqLZZpf4STw40LjVuQn8cCbq+k9CTg6Soc93xYwt2MYbPhaMLFj nvB21FCXniX9+y22EDEEl4MwdkpAGuX55K2FmQ/DnlEmXuR1JcrG1KuCr8stuzM9 a5gi+pLwhtzgi2KlSUEY3ODedfXiVBkJVFO0Y8erp6lgTzo/he4GbQcoN7pTHwjg k3fPcsBx808G0Xb7cYcoQ/+AabA/yuj+G80kApVYuHQlp0HNmoxEKmJFE2ln9vzF 2CldmkcnjQdamk38SKV55oPRxsDDhacvF/GubFGK/UBFaUr8fFS+/JC91oTSpfo= =PuMS -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 17 17:32:02 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57267129429 for ; Thu, 17 Nov 2016 17:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pyxwAt5q29l for ; Thu, 17 Nov 2016 17:32:00 -0800 (PST) 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 5F142129861 for ; Thu, 17 Nov 2016 17:31:55 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id 3so97239153pgd.0 for ; Thu, 17 Nov 2016 17:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=LBUsLDo4sjnSHJgXsKPjhQtvILdau+2Cb8r4w4T+xpM=; b=ht8v3+J8h2ZrcjNnRMxrkPhSongmuUFJK5eXPqUK5XXqXy87bCOAMKOMHoz9v2dUwC 5E583ZBspWWe/SZRT7+LvqqvHNchP2XP5aqSnqjHVTc7n6GYO6F/xDK7j3qxKwplBG85 SFCgywCnnmJi6G+kDc3ogXkw/oROGjwkFlHOgqI+NWTcyyjGgmA/CyPQaxbZhbPBa4NV +5tPLfkyZo9rdlU73B13jY8b1J3GcmK25S/AAGZ396/aQL3W98Gll9nK+6i4lxeunPSE VKNEO/BHGtPBJhdK9I9CURPEoW6etlvjlO0HwY7l7WNsTXVCg0JtodFj4S4mrlaxXWHu Fjuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=LBUsLDo4sjnSHJgXsKPjhQtvILdau+2Cb8r4w4T+xpM=; b=VIk0sQOhfGIT5Y/IXJSqw1JHeXCZTbgqmTZA/vmZ4S+U3NCUVqsPWnpoxQuvy+kts8 dzlnO9JvsrIfCYOFTgn9SxI4ishWSaWfl7FSIHGPAJXyAzPAE+RyqIfLIoci5BOG0p7V jwMkVTrP883RJmvc9RygsGDTX6YoAdtCf2Q2sJ+eNfml/NxCkZgCIB7uGSt/6UTU4Cjo +ZTYGV9MAhsfs+OZv2VzeTxhFUx5AmkB9zvdYNBzWWPbJpNh44k0gzL9beo1kkxSEcjh gmcmy8JsdEV6V1jlc9Ne59822KmujLr+YzyUQkPDnrEAzZA/bcDgrw1M5+tvijCI45qn UNyA== X-Gm-Message-State: ABUngvc3hyzz5tg/T4m+6wG734W/LBzwraOxs2uLegZMOGacQ2U0b/n0ul7YObbfwXaE/w== X-Received: by 10.98.166.70 with SMTP id t67mr8360680pfe.132.1479432714518; Thu, 17 Nov 2016 17:31:54 -0800 (PST) Received: from [192.168.178.23] (117.228.69.111.dynamic.snap.net.nz. [111.69.228.117]) by smtp.gmail.com with ESMTPSA id y189sm11340116pfy.32.2016.11.17.17.31.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 17:31:53 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 18 Nov 2016 14:32:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] The ACP is not an ASA, but... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:32:01 -0000 The ACP is not an ASA, it's actually a set of components, and probably it includes several daemons. However, I think that modelling the ACP *neighbor discovery function* as an ASA is correct - it will after all be using GRASP, and it will probably need to run indefinitely because of handling new neighbors or neighbors that disappear. It is also a user of one of the limited instances of GRASP (I can't remember which one at this moment, while also listening to Bing's talk). Regards Brian From nobody Thu Nov 17 17:53:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9672129602 for ; Thu, 17 Nov 2016 17:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 kNB_14TvxDw5 for ; Thu, 17 Nov 2016 17:53:04 -0800 (PST) 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 EB5CB1293E1 for ; Thu, 17 Nov 2016 17:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=587; q=dns/txt; s=iport; t=1479433983; x=1480643583; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=irZhiL8ao7PUj0NFLOA/Ci6dSqDMZ7eU7sZyyc8Z5Ew=; b=FyJs0ZrXsj4xjTCzkgBSfyY9qTXrf8nwIIwbRkvC/J22fgG3wZPQ8TSd hpOmZJ/4jAqHZqdlVS5vIaaT9woElGkOnUcYF45OVvAaja/r3jj8akULB 5xpXmeng1PVP+b5OckJzY6YbSZcQj1HxHHBCxRRJeEcc6qS7gesEj9Y9l 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDpXS5Y/5hdJa1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzcBAQEBAR+BX404q3SCB4URgzE/FAECAQEBAQEBAWIdC4RvOlEBPkImAQQ?= =?us-ascii?q?biGScSJIli1gBAQgBAQEBI4Y8jwQFmkMBgUWPIIFhjkyRWgEeN4ELhTuHX4EMA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.31,655,1473120000"; d="scan'208";a="175622615" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2016 01:53:03 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAI1r32B011771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 Nov 2016 01:53:03 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 19:53:02 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Thu, 17 Nov 2016 19:53:02 -0600 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: Intent per ASA or per AF? Thread-Index: AdJBPZCUap75TyB7THivcdpl+3+EcA== Date: Fri, 18 Nov 2016 01:53:02 +0000 Message-ID: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:53:05 -0000 One question that just came up: Should Intent be designed per ASA or per AF= ?=20 My suggestion previously was to segment Intent into sections per Autonomic = Functions.=20 Example: Intent for the bootstrap function could be:=20 - allow bootstrapping new devices only during maintenance window For such Intent, action could be taken on the registrar (one ASA of the AF)= , or on the proxy (another ASA of the same AF).=20 It seems to me an author of an AF might like all ASAs of his AF to know abo= ut the Intent, because the proxy may also take actions.=20 Michael From nobody Thu Nov 17 18:04:43 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043F512985B for ; Thu, 17 Nov 2016 18:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThyGg8HcGiXb for ; Thu, 17 Nov 2016 18:04:39 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2C7E512979D for ; Thu, 17 Nov 2016 18:04:37 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 9BD08DFC0C790; Fri, 18 Nov 2016 02:04:34 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAI24YeK017153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Nov 2016 02:04:35 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uAI24YrV006612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Nov 2016 03:04:34 +0100 Received: from [135.224.207.20] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 18 Nov 2016 03:04:33 +0100 To: "Michael Behringer (mbehring)" , "anima@ietf.org" References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: Date: Fri, 18 Nov 2016 03:04:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> Content-Type: multipart/alternative; boundary="------------377EF7A34481CE41A9E810DB" X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:04:42 -0000 --------------377EF7A34481CE41A9E810DB Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Michael, Definitely not designed per ASA. As mentioned at the mic, in draft-peloso (https://datatracker.ietf.org/doc/draft-peloso-anima-autonomic-function), we've proposed format for "intent" at the AF level. Please note, that once "resolved" the AF intent will exist (be translated) in the instances of the AF (the ASAs) as AF instance descriptor. This is ASA-level/specific information. Best regards, Laurent. On 18/11/2016 02:53, Michael Behringer (mbehring) wrote: > One question that just came up: Should Intent be designed per ASA or per AF? > > My suggestion previously was to segment Intent into sections per Autonomic Functions. > > Example: Intent for the bootstrap function could be: > - allow bootstrapping new devices only during maintenance window > > For such Intent, action could be taken on the registrar (one ASA of the AF), or on the proxy (another ASA of the same AF). > > It seems to me an author of an AF might like all ASAs of his AF to know about the Intent, because the proxy may also take actions. > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------377EF7A34481CE41A9E810DB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Michael,

Definitely not designed per ASA.

As mentioned at the mic, in draft-peloso (https://datatracker.ietf.org/doc/draft-peloso-anima-autonomic-function), we've proposed format for "intent" at the AF level.
Please note, that once "resolved" the AF intent will exist (be translated) in the instances of the AF (the ASAs) as AF instance descriptor. This is ASA-level/specific information.

Best regards, Laurent.

On 18/11/2016 02:53, Michael Behringer (mbehring) wrote:
One question that just came up: Should Intent be designed per ASA or per AF? 

My suggestion previously was to segment Intent into sections per Autonomic Functions. 

Example: Intent for the bootstrap function could be: 
- allow bootstrapping new devices only during maintenance window

For such Intent, action could be taken on the registrar (one ASA of the AF), or on the proxy (another ASA of the same AF). 

It seems to me an author of an AF might like all ASAs of his AF to know about the Intent, because the proxy may also take actions. 

Michael

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

--

Laurent Ciavaglia

Nokia, Bell Labs

 

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

--------------377EF7A34481CE41A9E810DB-- From nobody Thu Nov 17 18:10:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE3A129604 for ; Thu, 17 Nov 2016 18:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 4gYXC4c8MLOU for ; Thu, 17 Nov 2016 18:10:18 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC831294FD for ; Thu, 17 Nov 2016 18:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1336; q=dns/txt; s=iport; t=1479435014; x=1480644614; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IYO73dgECURz/vQbs53rfh6WCNSXpxahVGQlNzEn2Lk=; b=U9yUM4WdimyhK8KzJJ/IR+xPldCNaSAx5OL3IiFQlgo+S36elhOikeh7 YAB1DZA2/FavhQvI98vi89JkAEFysfkwz8li8bhvu1Tdhf0v1+dBXM2EO cHU2tl7PTfEf0bNufmrdgACh4kw1aJHdXYqf02IBOgS/EJAkj775vqVmr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AgBWYi5Y/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9YgQAHjTiXEJRkggcdC4RpAYEPAoIfPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBAwEBAQE3NBAHBAIBCBEEAQEfCQcnCxQJCAIEARIIiFwIDq5Yi?= =?us-ascii?q?1cBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY8hFqEJYYFBZpDAZBlkC2NUIQKAR4?= =?us-ascii?q?3OVIdhR5yhT2BMIEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,655,1473120000"; d="scan'208";a="349049073" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2016 02:10:10 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAI2A9s7017609 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 02:10:09 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 20:10:09 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Thu, 17 Nov 2016 20:10:09 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] The ACP is not an ASA, but... Thread-Index: AQHSQTugJvRwHb7MpEmcDe/iGLExoaDd/mAA Date: Fri, 18 Nov 2016 02:10:08 +0000 Message-ID: <6d3cd3431fa645c39225c6504e577e7b@XCH-RCD-006.cisco.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] The ACP is not an ASA, but... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:10:20 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 18 November 2016 10:32 > To: Anima WG > Subject: [Anima] The ACP is not an ASA, but... >=20 > The ACP is not an ASA, it's actually a set of components, and probably it > includes several daemons. >=20 > However, I think that modelling the ACP *neighbor discovery function* as = an > ASA is correct - it will after all be using GRASP, and it will probably n= eed to run > indefinitely because of handling new neighbors or neighbors that disappea= r. > It is also a user of one of the limited instances of GRASP (I can't remem= ber > which one at this moment, while also listening to Bing's talk). The concrete question is whether we should document the ACP functional bloc= k in section 7.3 in the reference draft.=20 I think you're suggesting to do so.=20 In this case, can I ask you to provide some text? ;-) As mentioned, I'm n= ot 100% convinced, but not opposed either. I'll then rename section 7.3 fr= om "Specific ASAs for the Enrolment Process" to " Specific ASAs" Agree? Michael =20 > Regards > Brian >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Nov 17 18:14:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5229D1295F3 for ; Thu, 17 Nov 2016 18:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDInEfJPfsih for ; Thu, 17 Nov 2016 18:14:36 -0800 (PST) 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 EA0EF128E18 for ; Thu, 17 Nov 2016 18:14:33 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id x23so94730467pgx.1 for ; Thu, 17 Nov 2016 18:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=xGsDIyxhgOECZt3dQO0fYUeFAPtpB6bKaGEskqKK9x0=; b=sNbTaCfQ7czDaupOFp7eaiNA1XfFgMxEmEJEnJ/ow2awLDZN56tgq90XmKPPiXctRA vSLOMpBFke72EIYqwdt+5ZmU+FVDpFI87DKrFChHp44tZuglqKYQM92GcSm/jcdwQKRh k5q/FpO0WPTo9T+vFUVub/c3L5m0lr1mdk2kK2NGlivfzUuhSJo4nng7WaX4is3m3a7a oPtJPeg0N8Mj7fAtCOGJEtmO0gQJ6PUvcCE0spFduW7dJ9Fgk5rKCNm2vFyHNOr0Kagk WI9H6rKjkcEAcYIdNLMEp5CipopnKHnZe9dULASjt0aYnr93bJ44oDQrORb2YukBEO+4 kjqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xGsDIyxhgOECZt3dQO0fYUeFAPtpB6bKaGEskqKK9x0=; b=hKoqb8s/rUvnItGdvKpVg6QPAQ8rLIwNQoq0pbeH1YHg50RXFL7cHtzewGxy7juXsm q5JoK5vluOARPtnmlhp4c/j0P4+ZrF0IVpIsozoW7sTrCvv+uFXphN9iMSX7eN7rI0f+ M+Lpdv8mcIWBpbdkOj0cM8wR3MbB/GVN4Zk7JccDqUtmpJ0bin8LMnbPnyRWptZh7G6U ED4B0IQO27hRExAuzyd5hbxjSCyuJbNkHTj31Yhe2vtQz7xRovqc5pF7ig70VNPeNGPl Q5303/k5I2a1QpAZ15n0hSFkbwlXAy3xQj/0gwufNLys02ufWKlNZDpObEASq9BMP0YR dKrA== X-Gm-Message-State: ABUngveQRahwc8x3NKdP03Y3vGjuUf0ZQLWh2l5/SFj+iWpTlWywPiWOSObr3yE2Dpf+Gg== X-Received: by 10.98.9.91 with SMTP id e88mr8547977pfd.72.1479435273210; Thu, 17 Nov 2016 18:14:33 -0800 (PST) Received: from [192.168.178.23] (117.228.69.111.dynamic.snap.net.nz. [111.69.228.117]) by smtp.gmail.com with ESMTPSA id c2sm11482976pfl.66.2016.11.17.18.14.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 18:14:32 -0800 (PST) To: anima@ietf.org References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 18 Nov 2016 15:14:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:14:40 -0000 On 18/11/2016 14:53, Michael Behringer (mbehring) wrote: > One question that just came up: Should Intent be designed per ASA or per AF? > > My suggestion previously was to segment Intent into sections per Autonomic Functions. > > Example: Intent for the bootstrap function could be: > - allow bootstrapping new devices only during maintenance window > > For such Intent, action could be taken on the registrar (one ASA of the AF), or on the proxy (another ASA of the same AF). > > It seems to me an author of an AF might like all ASAs of his AF to know about the Intent, because the proxy may also take actions. Yes, I think so. Again we hit the question of granularity and whether this is actually Intent, but a policy like that might be added to Intent-for-BRSKI, and both registrars and proxies need to know it. So I'd expect we will need intent to be in sections that are per-function (and we will therefore need a method of guaranteeing that function names are unique). In fact we get a more general result if we simply say that intent is divided in sections that have unique labels; then it's easy to support intent per-function, per-objective, or even per-geography if we want. Brian > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Nov 17 18:19:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A9512979D for ; Thu, 17 Nov 2016 18:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Otlx-zLWnTHI for ; Thu, 17 Nov 2016 18:19:29 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF38128E18 for ; Thu, 17 Nov 2016 18:19:29 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 3so97649013pgd.0 for ; Thu, 17 Nov 2016 18:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=iGdc66/Pq7EFLdLOvvzS2Txc3UFm7zOgsDVYJFSdtS8=; b=J/uUO6mZQSq2QkjhxoIa6KHOJwS3TgEKQTPjbAEJMn248GEXMUs9jLF1C0kjK3vyW7 1W3ab7ExVu22/KMUM5dtH4ZKG22NBVJgPbS1Bp40zj7fPxs0QiFP+/Bz6b3nlLOYQQ9U wnX+K+eUw1vG7UhlYbI8RNWNOIZTD+tQO1m9P928T5/ojvW8h8IA5vf11mMPWZRkAlZt glUSus9lBYF0meCWMYpb9aj8s1NDIQVVf86Ub+Hj+2YwHnLQMobStxfG/FqkJQOHwzj2 Dkk7qxDurfjbeuNPHZI2agaOM8N58F0USh43yEHO+PryPAaAIhp9BlKxKyO9d6IB2oSA 4Yew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=iGdc66/Pq7EFLdLOvvzS2Txc3UFm7zOgsDVYJFSdtS8=; b=VbKftCDXl73Do7kRq0KpOa9AYvUz7Gh+TjdMRMfuAM0Cz/F28FRS1m1w1KCD95oXl0 JtD/968qJlRhNy9st3D9XCqAxyJyF+AUMiDQIVCYzjeOs3Si/++FHbxdCY7M4SSSWSxn MNzSnia5McBI5SwbshUeIltvfAceefcI5SbV1vJkSW/hLPXSG2a/fhiymAuhgdbVkrRk TXBNH5j6IwVJWbsYQip+jWlZgTACdfT6ushcUsMUb7oIt4BxJtAjMntPVhJS4eYMlyjI xAGxd6qOfAUg9bhUlzwwxH8GM34QLsTDhJzyFlWUyQRC1chKecvXK6orYEybmP7Qvyht y/Jw== X-Gm-Message-State: ABUngvf2cJGV4IiN787E/sPS3dU0FgTCJvSZur0kbVyPGnFUV5YTyCzIsyqKE5KItgIjCQ== X-Received: by 10.99.230.83 with SMTP id p19mr13817534pgj.121.1479435569237; Thu, 17 Nov 2016 18:19:29 -0800 (PST) Received: from [192.168.178.23] (117.228.69.111.dynamic.snap.net.nz. [111.69.228.117]) by smtp.gmail.com with ESMTPSA id y189sm11530301pfy.32.2016.11.17.18.19.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 18:19:28 -0800 (PST) To: "Michael Behringer (mbehring)" , Anima WG References: <6d3cd3431fa645c39225c6504e577e7b@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <206d7caf-f7d2-7734-4b96-719ae48d9e90@gmail.com> Date: Fri, 18 Nov 2016 15:19:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6d3cd3431fa645c39225c6504e577e7b@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] The ACP is not an ASA, but... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:19:31 -0000 Off list. Will do. Not before Monday though. Safe travel home. On 18/11/2016 15:10, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 18 November 2016 10:32 >> To: Anima WG >> Subject: [Anima] The ACP is not an ASA, but... >> >> The ACP is not an ASA, it's actually a set of components, and probably it >> includes several daemons. >> >> However, I think that modelling the ACP *neighbor discovery function* as an >> ASA is correct - it will after all be using GRASP, and it will probably need to run >> indefinitely because of handling new neighbors or neighbors that disappear. >> It is also a user of one of the limited instances of GRASP (I can't remember >> which one at this moment, while also listening to Bing's talk). > > The concrete question is whether we should document the ACP functional block in section 7.3 in the reference draft. > > I think you're suggesting to do so. > > In this case, can I ask you to provide some text? ;-) As mentioned, I'm not 100% convinced, but not opposed either. I'll then rename section 7.3 from "Specific ASAs for the Enrolment Process" to " Specific ASAs" > > Agree? > Michael > >> Regards >> Brian >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Nov 17 18:21:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6312979D for ; Thu, 17 Nov 2016 18:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 VEvEhp2ZhCn1 for ; Thu, 17 Nov 2016 18:21:36 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA9F128E18 for ; Thu, 17 Nov 2016 18:21:36 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 73E5358C4B0; Fri, 18 Nov 2016 03:21:34 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 56B6BB0AE82; Fri, 18 Nov 2016 03:21:34 +0100 (CET) Date: Fri, 18 Nov 2016 03:21:34 +0100 From: Toerless Eckert To: Laurent Ciavaglia Message-ID: <20161118022132.GA3400@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: anima@ietf.org Subject: [Anima] Anima/Laurent: re. figuring out intent X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:21:38 -0000 Laurent: wrt to your comment on the mike in Seoul: Thanks for crushing my hopes to find a way through the jungle ;-) Kidding. Very good comment, very much appreciated. So, if a full, even high level, direction for intent is further out because, would it then make sense to think of shorter term incremental definitions, hopefully in a way that they could be reuseable building blocks for intent later. For example: A lot of network service provisioning today is done just with group-template based per-device configuration. Shouldn't we look at how we could improve and/or standardize this approach with anima. The semantic would be blocks of device configuration surrounded by a meta layer to define groupings eg: by device/vendor type/roles etc.. Maybe this is not the right incremental step. But my main question is: what incremental steps, if any do make most sense to you and others looking into intent. Cheers Toerless From nobody Thu Nov 17 18:24:08 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6F1295C8 for ; Thu, 17 Nov 2016 18:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.007 X-Spam-Level: X-Spam-Status: No, score=-16.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gh6QPSFovZ6 for ; Thu, 17 Nov 2016 18:24:05 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3ED31293FD for ; Thu, 17 Nov 2016 18:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16820; q=dns/txt; s=iport; t=1479435845; x=1480645445; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aHzXZuvRSXKduMOw6bTADh+lpYyneB4CJUI7/aEPMY8=; b=dbv77X3Oq+7t/mM9aikz1QRjOHx/45HDib23y+e48Kdzmm78X8XvBtxf 7T/DGvslTVSpNPOvSihLOELIuR0aGxeqLIzyqmEg9XIU3D8GXcnElVMft rl2o5cA99UfruwhO5T+Mi3cxpF2sKb9uE+8FA3QDGSZ+DoLaICL2DX0fA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAQB5ZS5Y/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNEAQEBAQEfWIEAB404lxCPSYUbggcdAQqEaYEQAhqCBT8UAQI?= =?us-ascii?q?BAQEBAQEBYiiEaAEBAQQBAQEgCkEbAgEIEQQBASgDAgICJQsUCQgBAQQBEgiIZ?= =?us-ascii?q?A6sM4IpL4soAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY8hFqEYB+CToJdBZpDAYY?= =?us-ascii?q?/iiaBd0+EJ4lAjVCECgEeN4ELHYUecoZtgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,655,1473120000"; d="scan'208,217";a="348055913" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2016 02:24:04 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uAI2O4d1001726 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 02:24:04 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 20:24:04 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Thu, 17 Nov 2016 20:24:03 -0600 From: "Michael Behringer (mbehring)" To: Laurent Ciavaglia , "anima@ietf.org" Thread-Topic: [Anima] Intent per ASA or per AF? Thread-Index: AdJBPZCUap75TyB7THivcdpl+3+EcAANNHQAAAvsTaA= Date: Fri, 18 Nov 2016 02:24:03 +0000 Message-ID: <8934c1bb6dbb47878a0f8b911376bad7@XCH-RCD-006.cisco.com> References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.136] Content-Type: multipart/alternative; boundary="_000_8934c1bb6dbb47878a0f8b911376bad7XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:24:07 -0000 --_000_8934c1bb6dbb47878a0f8b911376bad7XCHRCD006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUsIExhdXJlbnQuIFRoZW4gbGV04oCZcyBuYWlsIHRoaXMgZG93biBpbiB0aGUgSW50ZW50 IGRyYWZ0OiDigJxJbnRlbnQgaXMgZGVmaW5lZCBwZXIgQXV0b25vbWljIEZ1bmN0aW9u4oCdLg0K TWljaGFlbA0KRnJvbTogTGF1cmVudCBDaWF2YWdsaWEgW21haWx0bzpMYXVyZW50LkNpYXZhZ2xp YUBub2tpYS1iZWxsLWxhYnMuY29tXQ0KU2VudDogMTggTm92ZW1iZXIgMjAxNiAxMTowNA0KVG86 IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgPG1iZWhyaW5nQGNpc2NvLmNvbT47IGFuaW1h QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FuaW1hXSBJbnRlbnQgcGVyIEFTQSBvciBwZXIgQUY/ DQoNCk1pY2hhZWwsDQoNCkRlZmluaXRlbHkgbm90IGRlc2lnbmVkIHBlciBBU0EuDQoNCkFzIG1l bnRpb25lZCBhdCB0aGUgbWljLCBpbiBkcmFmdC1wZWxvc28gKGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbG9zby1hbmltYS1hdXRvbm9taWMtZnVuY3Rpb24pLCB3ZSd2 ZSBwcm9wb3NlZCBmb3JtYXQgZm9yICJpbnRlbnQiIGF0IHRoZSBBRiBsZXZlbC4NClBsZWFzZSBu b3RlLCB0aGF0IG9uY2UgInJlc29sdmVkIiB0aGUgQUYgaW50ZW50IHdpbGwgZXhpc3QgKGJlIHRy YW5zbGF0ZWQpIGluIHRoZSBpbnN0YW5jZXMgb2YgdGhlIEFGICh0aGUgQVNBcykgYXMgQUYgaW5z dGFuY2UgZGVzY3JpcHRvci4gVGhpcyBpcyBBU0EtbGV2ZWwvc3BlY2lmaWMgaW5mb3JtYXRpb24u DQoNCkJlc3QgcmVnYXJkcywgTGF1cmVudC4NCk9uIDE4LzExLzIwMTYgMDI6NTMsIE1pY2hhZWwg QmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQoNCk9uZSBxdWVzdGlvbiB0aGF0IGp1c3QgY2Ft ZSB1cDogU2hvdWxkIEludGVudCBiZSBkZXNpZ25lZCBwZXIgQVNBIG9yIHBlciBBRj8NCg0KDQoN Ck15IHN1Z2dlc3Rpb24gcHJldmlvdXNseSB3YXMgdG8gc2VnbWVudCBJbnRlbnQgaW50byBzZWN0 aW9ucyBwZXIgQXV0b25vbWljIEZ1bmN0aW9ucy4NCg0KDQoNCkV4YW1wbGU6IEludGVudCBmb3Ig dGhlIGJvb3RzdHJhcCBmdW5jdGlvbiBjb3VsZCBiZToNCg0KLSBhbGxvdyBib290c3RyYXBwaW5n IG5ldyBkZXZpY2VzIG9ubHkgZHVyaW5nIG1haW50ZW5hbmNlIHdpbmRvdw0KDQoNCg0KRm9yIHN1 Y2ggSW50ZW50LCBhY3Rpb24gY291bGQgYmUgdGFrZW4gb24gdGhlIHJlZ2lzdHJhciAob25lIEFT QSBvZiB0aGUgQUYpLCBvciBvbiB0aGUgcHJveHkgKGFub3RoZXIgQVNBIG9mIHRoZSBzYW1lIEFG KS4NCg0KDQoNCkl0IHNlZW1zIHRvIG1lIGFuIGF1dGhvciBvZiBhbiBBRiBtaWdodCBsaWtlIGFs bCBBU0FzIG9mIGhpcyBBRiB0byBrbm93IGFib3V0IHRoZSBJbnRlbnQsIGJlY2F1c2UgdGhlIHBy b3h5IG1heSBhbHNvIHRha2UgYWN0aW9ucy4NCg0KDQoNCk1pY2hhZWwNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkFuaW1hIG1haWxpbmcg bGlzdA0KDQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0KDQoNCi0tDQoNCkxhdXJlbnQg Q2lhdmFnbGlhDQpOb2tpYSwgQmVsbCBMYWJzDQoNCiszMyAxNjAgNDAyIDYzNg0Kcm91dGUgZGUg VmlsbGVqdXN0IC0gTm96YXksIEZyYW5jZQ0KbGlua2VkaW4uY29tL2luL2xhdXJlbnQuY2lhdmFn bGlhDQo= --_000_8934c1bb6dbb47878a0f8b911376bad7XCHRCD006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTAuMHB0Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgls aW5lLWhlaWdodDoxMTUlOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEw LjBwdDsNCgltYXJnaW4tbGVmdDowY207DQoJbGluZS1oZWlnaHQ6MTE1JTsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAu ODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Y29sb3I6IzFGNDk3RCI+QWdy ZWUsIExhdXJlbnQuIFRoZW4gbGV04oCZcyBuYWlsIHRoaXMgZG93biBpbiB0aGUgSW50ZW50IGRy YWZ0OiDigJxJbnRlbnQgaXMgZGVmaW5lZCBwZXIgQXV0b25vbWljIEZ1bmN0aW9u4oCdLg0KPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlO2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+ DQo8Yj48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLUdCO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9u dD48L2I+PGZvbnQgY29sb3I9ImJsYWNrIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPg0KIExhdXJlbnQgQ2lhdmFn bGlhIFttYWlsdG86TGF1cmVudC5DaWF2YWdsaWFAbm9raWEtYmVsbC1sYWJzLmNvbV0gPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gMTggTm92 ZW1iZXIgMjAxNiAxMTowNDxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzo8L3NwYW4+PC9iPiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpICZsdDttYmVocmluZ0Bj aXNjby5jb20mZ3Q7OyBhbmltYUBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbQW5pbWFdIEludGVudCBwZXIgQVNB IG9yIHBlciBBRj88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNr IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1o ZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TWljaGFlbCw8 YnI+DQo8YnI+DQpEZWZpbml0ZWx5IG5vdCBkZXNpZ25lZCBwZXIgQVNBLjxicj4NCjxicj4NCkFz IG1lbnRpb25lZCBhdCB0aGUgbWljLCBpbiBkcmFmdC1wZWxvc28gKDxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbG9zby1hbmltYS1hdXRvbm9taWMtZnVu Y3Rpb24iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbG9zby1hbmlt YS1hdXRvbm9taWMtZnVuY3Rpb248L2E+KSwgd2UndmUgcHJvcG9zZWQgZm9ybWF0IGZvciAmcXVv dDtpbnRlbnQmcXVvdDsgYXQgdGhlIEFGIGxldmVsLjxicj4NClBsZWFzZSBub3RlLCB0aGF0IG9u Y2UgJnF1b3Q7cmVzb2x2ZWQmcXVvdDsgdGhlIEFGIGludGVudCB3aWxsIGV4aXN0IChiZSB0cmFu c2xhdGVkKSBpbiB0aGUgaW5zdGFuY2VzIG9mIHRoZSBBRiAodGhlIEFTQXMpIGFzIEFGIGluc3Rh bmNlIGRlc2NyaXB0b3IuIFRoaXMgaXMgQVNBLWxldmVsL3NwZWNpZmljIGluZm9ybWF0aW9uLjxi cj4NCjxicj4NCkJlc3QgcmVnYXJkcywgTGF1cmVudC48L3NwYW4+PC9mb250Pjxmb250IHNpemU9 IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjExNSU7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlIj5PbiAxOC8x MS8yMDE2IDAyOjUzLCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xv cj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtsaW5lLWhlaWdodDoxMTUlIj5PbmUgcXVlc3Rpb24gdGhhdCBqdXN0IGNhbWUgdXA6IFNob3Vs ZCBJbnRlbnQgYmUgZGVzaWduZWQgcGVyIEFTQSBvciBwZXIgQUY/IDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1 JSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXpl PSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj5NeSBzdWdnZXN0aW9uIHByZXZpb3VzbHkgd2Fz IHRvIHNlZ21lbnQgSW50ZW50IGludG8gc2VjdGlvbnMgcGVyIEF1dG9ub21pYyBGdW5jdGlvbnMu IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29s b3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7bGluZS1oZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJl Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj5FeGFtcGxlOiBJ bnRlbnQgZm9yIHRoZSBib290c3RyYXAgZnVuY3Rpb24gY291bGQgYmU6IDxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6 MTE1JSI+LSBhbGxvdyBib290c3RyYXBwaW5nIG5ldyBkZXZpY2VzIG9ubHkgZHVyaW5nIG1haW50 ZW5hbmNlIHdpbmRvdzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQg c2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUl Ij5Gb3Igc3VjaCBJbnRlbnQsIGFjdGlvbiBjb3VsZCBiZSB0YWtlbiBvbiB0aGUgcmVnaXN0cmFy IChvbmUgQVNBIG9mIHRoZSBBRiksIG9yIG9uIHRoZSBwcm94eSAoYW5vdGhlciBBU0Egb2YgdGhl IHNhbWUgQUYpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNp emU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+ SXQgc2VlbXMgdG8gbWUgYW4gYXV0aG9yIG9mIGFuIEFGIG1pZ2h0IGxpa2UgYWxsIEFTQXMgb2Yg aGlzIEFGIHRvIGtub3cgYWJvdXQgdGhlIEludGVudCwgYmVjYXVzZSB0aGUgcHJveHkgbWF5IGFs c28gdGFrZSBhY3Rpb25zLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6 MTE1JSI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQg c2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUl Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNr IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1o ZWlnaHQ6MTE1JSI+QW5pbWEgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj48YSBocmVm PSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciPkFuaW1hQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6 MTE1JSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmlt YSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUt aGVpZ2h0OjExNSUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWln aHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTou MDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2si IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLSA8YnI+DQo8 YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGZv bnQgc2l6ZT0iMSIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkxhdXJlbnQgQ2lhdmFnbGlhPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjEiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ob2tpYSwgQmVsbCBMYWJz PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9y bWFsIj4NCjxmb250IHNpemU9IjEiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMSIgY29sb3I9ImJsYWNr IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7MzMgMTYwIDQwMiA2 MzY8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpu b3JtYWwiPg0KPGZvbnQgc2l6ZT0iMSIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPnJvdXRlIGRlIFZpbGxlanVzdCAtIE5vemF5LCBGcmFuY2U8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwi Pg0KPGZvbnQgc2l6ZT0iMSIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPmxpbmtlZGluLmNvbS9pbi9sYXVyZW50LmNpYXZhZ2xpYTwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_8934c1bb6dbb47878a0f8b911376bad7XCHRCD006ciscocom_-- From nobody Thu Nov 17 18:46:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2C126CD8 for ; Thu, 17 Nov 2016 18:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbBPwPGXZC0k for ; Thu, 17 Nov 2016 18:46:42 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BEFF128E18 for ; Thu, 17 Nov 2016 18:46:42 -0800 (PST) Received: from LAPTOPR7T053C2 ([107.18.128.211]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LueDW-1cpb933yCW-00zrBG; Fri, 18 Nov 2016 03:46:38 +0100 From: To: "'Michael Behringer \(mbehring\)'" , "'Laurent Ciavaglia'" , References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> <8934c1bb6dbb47878a0f8b911376bad7@XCH-RCD-006.cisco.com> In-Reply-To: <8934c1bb6dbb47878a0f8b911376bad7@XCH-RCD-006.cisco.com> Date: Thu, 17 Nov 2016 21:46:38 -0500 Message-ID: <00ff01d24145$fd820070$f8860150$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0100_01D2411C.14AD7F10" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGm6i93Ts9PlZSen5cNpIqmN6f4EQLjObglAkfrncGhC14UgA== Content-Language: en-us X-Provags-ID: V03:K0:cDrewyXjy8CmN1mVTdVCc2UtdJpTDoft9/xM+qcCvlh08wqnFUc 5FHqJZHY3UFQ3v6gIh6qi+WmoycbEI1sPmx+N6yxnJvbCej3LuIhfesbPWhKIWoSroDEXd/ 4gFto9Todfw2e9TbH7UmS6Ldwp10dZnjDdkcoz1jUpF6jADxshu3O021JUfHEESyEj72rKq sLrx/6Ky33OvJMcb+kBRA== X-UI-Out-Filterresults: notjunk:1;V01:K0:sOS4nbRxPPA=:8frfE16nixWiAv38Yzvm2k +JrwJHz+3M7lvuRmockzYJoujwdW7zN7owJa0XbWAcIobQTSKed0Z/ga7uWPeBWg604v87YP8 +b5YlRbdxDs6MxPaeJZRF/plfD+A5j8G4QcVoHeANhJDBxz14k5vXTE4B1hDUE5lrkVLoYKEd 9GFQhAaZNwSga5qi75JYxbGF98rNhJ9obK9Yw30k7+6IO7H668UiigqO6Yj2E4ehgON86a9Od jyG37Elo+cM9MGkYkTz3ZtVp6SJz5bO0q8H1pBDBmbCFfvrR0TCT3L+RluFOps6hMMrE5nDKo hIx+HOFlN2ujTbHMEJhzlkwzu7hydBfclvsGarnWjy/mIQPofCPyBVjEAzznB+fqtFm1psuaJ WHQdkHi2XLuT7WA66JGXeVYAUInhTj2zxzN8NT2bK3gjmHKjq4Wr6lRGsNsuYPW+Hc2M6QsTM 8VaayrFaDVTd7eCvMsjhDIVJpxbkVn6Auq4NkVxSTFJ+ZOBSKOABCTJ0Z6XV0vnI/tD1vQYmX 7m6cCWk2xkmGVZxu6RDwsumx9dOWjkIIwyPN49eu7BPxDvfz9btYjrO7m7J3lJZ1X7EGCO6/k AiCgn/dTCq20Ajs091KogdviP1Q4R6PlOnieQEHtrJXalKsldW16iy4VcJ/h1Xd8UI8sN0Xmu fJkCfYsVwx537y/0vhP+T9+BglkbZFCh8Olxkk60tHhz1tp8LOBtDx/cjlchyo2/hpXCcJxsx yxMnQSayO/F+16j4 Archived-At: Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:46:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0100_01D2411C.14AD7F10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for defining it per autonomic function. This is also a way to = potentially =E2=80=9Cscope=E2=80=9D intent distribution. =20 --- Alex From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael = Behringer (mbehring) Sent: Thursday, November 17, 2016 9:24 PM To: Laurent Ciavaglia ; = anima@ietf.org Subject: Re: [Anima] Intent per ASA or per AF? =20 Agree, Laurent. Then let=E2=80=99s nail this down in the Intent draft: = =E2=80=9CIntent is defined per Autonomic Function=E2=80=9D.=20 Michael From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@nokia-bell-labs.com]=20 Sent: 18 November 2016 11:04 To: Michael Behringer (mbehring) >; anima@ietf.org =20 Subject: Re: [Anima] Intent per ASA or per AF? =20 Michael, Definitely not designed per ASA. As mentioned at the mic, in draft-peloso = (https://datatracker.ietf.org/doc/draft-peloso-anima-autonomic-function),= we've proposed format for "intent" at the AF level. Please note, that once "resolved" the AF intent will exist (be = translated) in the instances of the AF (the ASAs) as AF instance = descriptor. This is ASA-level/specific information. Best regards, Laurent. On 18/11/2016 02:53, Michael Behringer (mbehring) wrote: One question that just came up: Should Intent be designed per ASA or per = AF?=20 =20 My suggestion previously was to segment Intent into sections per = Autonomic Functions.=20 =20 Example: Intent for the bootstrap function could be:=20 - allow bootstrapping new devices only during maintenance window =20 For such Intent, action could be taken on the registrar (one ASA of the = AF), or on the proxy (another ASA of the same AF).=20 =20 It seems to me an author of an AF might like all ASAs of his AF to know = about the Intent, because the proxy may also take actions.=20 =20 Michael =20 _______________________________________________ Anima mailing list Anima@ietf.org =20 https://www.ietf.org/mailman/listinfo/anima =20 =20 --=20 Laurent Ciavaglia Nokia, Bell Labs =20 +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia ------=_NextPart_000_0100_01D2411C.14AD7F10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1 for defining it = per autonomic function.=C2=A0 This is also a way to potentially = =E2=80=9Cscope=E2=80=9D intent distribution.=C2=A0 =

--- Alex

<= span style=3D'color:windowtext'>From: Anima [mailto:anima-bounces@ietf.org] On = Behalf Of Michael Behringer (mbehring)
Sent: Thursday, = November 17, 2016 9:24 PM
To: Laurent Ciavaglia = <Laurent.Ciavaglia@nokia-bell-labs.com>; = anima@ietf.org
Subject: Re: [Anima] Intent per ASA or per = AF?

 

Agree, Laurent. Then let=E2=80=99s = nail this down in the Intent draft: =E2=80=9CIntent is defined per = Autonomic Function=E2=80=9D.

Michael

<= span = style=3D'color:windowtext;mso-fareast-language:EN-GB'>From: Laurent = Ciavaglia [mailto:Laurent.Ciav= aglia@nokia-bell-labs.com]
Sent: 18 November 2016 = 11:04
To: Michael Behringer (mbehring) <mbehring@cisco.com>; anima@ietf.org
Subject: Re: = [Anima] Intent per ASA or per AF?

 

Michael,

Definitely not = designed per ASA.

As mentioned at the mic, in draft-peloso (https://datatracker.ietf.org/doc/draft-peloso-anima-autonomic-func= tion), we've proposed format for "intent" at the AF = level.
Please note, that once "resolved" the AF intent will = exist (be translated) in the instances of the AF (the ASAs) as AF = instance descriptor. This is ASA-level/specific information.

Best = regards, Laurent.

On = 18/11/2016 02:53, Michael Behringer (mbehring) = wrote:

One question that just came up: Should Intent be designed =
per ASA or per AF? 
 
My =
suggestion previously was to segment Intent into sections per Autonomic =
Functions. 
 
Example: Intent for the bootstrap function could be: =

- allow bootstrapping =
new devices only during maintenance =
window
 
For =
such Intent, action could be taken on the registrar (one ASA of the AF), =
or on the proxy (another ASA of the same AF). =

 
It =
seems to me an author of an AF might like all ASAs of his AF to know =
about the Intent, because the proxy may also take actions. =

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

 

-- =

Laurent = Ciavaglia

Nokia, = Bell Labs

 

+33 160 = 402 636

route de = Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

------=_NextPart_000_0100_01D2411C.14AD7F10-- From nobody Thu Nov 17 19:31:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E281293D8; Thu, 17 Nov 2016 19:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfW2vvgo-wzE; Thu, 17 Nov 2016 19:30:54 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CE71293D6; Thu, 17 Nov 2016 19:30:54 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-8d96.meeting.ietf.org [31.133.141.150]) by relay.sandelman.ca (Postfix) with ESMTPS id C7D2B1F418; Fri, 18 Nov 2016 03:30:52 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6693B33DD; Fri, 18 Nov 2016 12:30:49 +0900 (KST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 18 Nov 2016 12:30:49 +0900 Message-ID: <8226.1479439849@dooku.sandelman.ca> Archived-At: Cc: 6tisch@ietf.org, anima@ietf.org Subject: [Anima] 6tisch security bi-weekly meetings X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch@ietf.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 03:30:56 -0000 --=-=-= Content-Type: text/plain The 6tisch security design team will meet every two weeks starting on November 29th at 14:00 UTC. The meeting is anchored to UTC, not EST, but that will matter only in March. The nov. 29th meeting will be devoted to: a) recap of IETF97; work ensuing from the meeting. b) 6tisch-minimal-security Tuesday, November 29, 2016 9:00 am Eastern Standard Time (GMT-05:00) Recurrence: Every 2 weeks on Tuesday, from Tuesday, November 29, 2016, to Tuesday, March 21, 2017 Meeting number: 641 335 839 Meeting password: pledge Meeting link: https://ietf.webex.com/ietf/j.php?MTID=me98f12cebda5e6b55c1b8c66c095d0a9 Host key: 587716 Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYLnXpAAoJEJVM4Vb9/EKQJSoIAIzq0506mP9lJbxqzXNi1lTQ JhOZF6VAhPpEUKQvHqrnOZRYoGb2GSrMhTLbZ4hgZZ4b/El0G1sdg0+ZW2uzppbU 2/lMrUvQDDROamCHkcmv2jtOMslseieKpmTUz4xDdGXuuHK1isbDvZbRU3+Padc2 uze9qyuWsVY1Ek+I6NPijPCRyADfCz6Z8RpPT6AHaoD0Uk7L/ES6mWEZ+e23wazN lOlzTck50XqgYQ++0qNQVOhJ1eut/GfDNJcdmf7Xz1IsctRVEO6SUAHlAvSP88HB KSHYnp2nZeAEl04exSKrsZB7wuGqfbLy5nJxhoGQEgtM02jo1g6ryZ+0Phufnq8= =Imkr -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 17 19:39:20 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADCB1295E8; Thu, 17 Nov 2016 19:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKjq7yU2OrWd; Thu, 17 Nov 2016 19:39:17 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5378E1294B9; Thu, 17 Nov 2016 19:39:17 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-8d96.meeting.ietf.org [31.133.141.150]) by relay.sandelman.ca (Postfix) with ESMTPS id 0405F1F418; Fri, 18 Nov 2016 03:39:16 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id EA1062631; Fri, 18 Nov 2016 12:39:13 +0900 (KST) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 18 Nov 2016 12:39:13 +0900 Message-ID: <9165.1479440353@dooku.sandelman.ca> Archived-At: Cc: netconf@ietf.org, anima@ietf.org Subject: [Anima] weekly boostrap design team meetings X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: anima@ietf.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 03:39:19 -0000 --=-=-= Content-Type: text/plain The Anima Bootstrap design team (which includes work on the ownership voucher) will continue to meet at 15:00 UTC on Tuesdays via RTC-enabled webex. The meeting is anchored to UTC, not EST. anima bootstrap design team Tuesday, November 22, 2016 10:00 am Eastern Standard Time (GMT-05:00) Recurrence: Every Tuesday, from Tuesday, November 22, 2016, to Tuesday, March 21, 2017 Less information Meeting number: 644 519 877 Meeting password: bootstrap Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m2045414e2e484e0ad47311ce67c1d596 Host key: 959942 Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Show toll-free dialing restrictions Access code: 644 519 877 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYLnfhAAoJEJVM4Vb9/EKQp2kH/A5nxB8PBhrFA5XQEfPyzcq8 j8bZ8K4YHIUjXiwUE84iV/Wy87BJASHoUFTtYydvtYUKlt0iVM1j9+Am7lAB9f48 oGJgeF7OoQBUdVf331ksaVaI0aTgt8DJ0W8mGp/vd8ILK/RGYfuL6Ir9DK3E2kuy FqRG+ecxOxfkbhEw+Fi5M0bYMPQSHg8CmFdcnur58nleaINj/adIwJkjJMgZebAM 9m5Lyl3VR2bXoQjbE+Qx2K89Wf9+JJzhtk9u06eKehlWblUgDbAFZud7RWePCA3B WRnMOWkW3iDdyOesxfw3mjpnS++Xzuv4EHbKITOZLrW0aALHdIkFiOoxaWdZ4DI= =gcld -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 18 08:00:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9A12969E for ; Fri, 18 Nov 2016 08:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 x-LxuuRCCuJF for ; Fri, 18 Nov 2016 08:00:20 -0800 (PST) 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 BAC1B1295CA for ; Fri, 18 Nov 2016 08:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4250; q=dns/txt; s=iport; t=1479484820; x=1480694420; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SFikRyuufUHX58ocjQE9wIcltg4HZ+RAF37M0UKdcGU=; b=GQ98HfFCYpNjmQiY5p57HQ/ce9RIPg1V/NGvuFsDwaudYAqeUNy4XD8X AXxVZJ1eblTvaDvo7rdhY3ijOttaJz1bhhHH9pGZBR2a+nEgXGKAzmzOY SVG7fYrLlWYqNYeG5MLoBFBEKWQkTIxl+K0c0ZnWu5spaxsyRzge2eS8c s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAQD4JC9Y/5BdJa1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWIEAB404lw+UZoIHHQuCQ4M2AhqBcD8UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaAEBAQMBAQEBIBETJxALAgEIGAICJgICAiULFRACBAESH4hFCA6sD?= =?us-ascii?q?4Ipg0CIDQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQmHMIJdhCKDKy2CMAWITod?= =?us-ascii?q?chA6GEwGJTocjkCeNW4QKAR43gQsdhSFyhz6BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,510,1473120000"; d="scan'208";a="170732509" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2016 16:00:19 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAIG0JZ0009800 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 16:00:19 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 10:00:19 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Fri, 18 Nov 2016 10:00:19 -0600 From: "Max Pritikin (pritikin)" To: Michael Richardson , anima Thread-Topic: [Anima] red/yellow/green lights for bootstrap and ACP feedback Thread-Index: AQHSQTncqxhC0If76Eqc3haUhlyRW6DfS9mA Date: Fri, 18 Nov 2016 16:00:19 +0000 Message-ID: <5626B645-B742-4CFA-A42D-47FBBB310668@cisco.com> References: <29627.1479431967@dooku.sandelman.ca> In-Reply-To: <29627.1479431967@dooku.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.5] Content-Type: text/plain; charset="utf-8" Content-ID: <1D38AE9FDBBB824DB707141AB787B201@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] red/yellow/green lights for bootstrap and ACP feedback X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 16:00:23 -0000 DQpUaGUgY3VycmVudCB0ZXh0IGFyb3VuZCBlcnJvciBjYXNlcyBpbmNsdWRlczoNCg0KU2VjdGlv biAzLjEuMS4gRGlzY292ZXJ5DQpTdXBwb3J0cyBhIGJhY2tvZmYgbWVjaGFuaXNtcyBidXQgb24g cmV2aWV3IEnigJltIHRoaW5raW5nIHRoZSBsYW5ndWFnZSBhYm91dCBmaW5hbCBmYWlsdXJlIHRv IGJlIHZhZ3VlOg0KICAgIk9uY2UgYWxsIGRpc2NvdmVyZWQgc2VydmljZXMgYXJlIGF0dGVtcHRl ZCB0aGUgZGV2aWNlIFNIT1VMRCByZXR1cm4NCiAgIHRvIE11bHRpY2FzdCBETlMuICBJdCBzaG91 bGQgcGVyaW9kaWNhbGx5IHJldHJ5IHRoZSB2ZW5kb3Igc3BlY2lmaWMNCiAgIG1lY2hhbmlzbXMu ICBUaGUgUGxlZGdlIG1heSBwcmlvcml0aXplIHNlbGVjdGlvbiBvcmRlciBhcyBhcHByb3ByaWF0 ZQ0KICAgZm9yIHRoZSBhbnRpY2lwYXRlZCBlbnZpcm9ubWVudC4iDQoNClNlY3Rpb24gNS4xIFJl cXVlc3QgVm91Y2hlciBmcm9tIHRoZSBSZWdpc3RyYXINCiAgIkFzIGRldGFpbGVkIGluIFNlY3Rp b24gMy4xLjEgaWYgbm8gc3VpdGFibGUgUmVnaXN0cmFyIGlzIGZvdW5kIHRoZSBQbGVkZ2UgcmVz dGFydHMNCiAgIHRoZSBzdGF0ZSBtYWNoaW5lIGFuZCB0cmllcyBhZ2Fpbi4gIFNvIGEgUmVnaXN0 cmFyIHRoYXQgaXMgdW5hYmxlIHRvDQogICBjb21wbGV0ZSB0aGUgdHJhbnNhY3Rpb24gdGhlIGZp cnN0IHRpbWUgd2lsbCBoYXZlIGZ1dHVyZSBjaGFuY2VzLuKAnSANCg0KU2VjdGlvbiA1LjQgVm91 Y2hlciBTdGF0dXMgVGVsZW1ldHJ5DQpUaGlzIGlzIGN1cnJlbnRseSB3b3JkZWQgYXMgZmVlZGJh Y2sgZGlyZWN0bHkgdG8gdGhlIFJlZ2lzdHJhciAodGhyb3VnaCB0aGUgcHJveHkgb2YgY291cnNl KSBvZiBmYWlsdXJlLiANCg0KU2VjdGlvbiA1LjcuNC4gIEVucm9sbG1lbnQgU3RhdHVzIFRlbGVt ZXRyeQ0KVGhpcyBhZGRzIGFuIGVucm9sbG1lbnQgc3RhdHVzIHRlbGVtZXRyeSBvcHRpb24gYXMg RVNUIGZlZWRiYWNrIGhhcyBpbmRpY2F0ZWQgdGhpcyB3aWxsIGJlIGltcG9ydGFudCBmb3IgaGVh ZGxlc3MgZGV2aWNlcy4gDQoNCkltcHJvdmVtZW50cyBjb3VsZCBpbmNsdWRlOg0KDQpBIGZsb29k IHRlbGVtZXRyeSBzdGF0dXMgaW5kaWNhdG9yIGluIGFkZGl0aW9uIHRvIGRpcmVjdCBmZWVkYmFj ayB0byB0aGUgUmVnaXN0cmFyLiBUaGlzIHdvdWxkIGVuYWJsZSBhbnkgbG9jYWwgZXF1aXBtZW50 IHRvIGJldHRlciByZXBvcnQgdGhlIFBsZWRnZeKAmXMgc3RhdGUuIEkgc3VwcG9zZSB0aGlzIFNI T1VMRCBiZSBzaWduZWQgYnV0IG1heSBiZSB1bnNpZ25lZCB0byBhdm9pZCBleHRyYSBwcm9jZXNz aW5nIG92ZXJoZWFkIG9uIHRoZSBQbGVkZ2UuICBUaGlzIHdvdWxkIGxlYWsgdGhlIFBsZWRnZeKA mXMgaWRlbnRpdHkgaW5mb3JtYXRpb24gc28gdGhlcmUgYXJlIHByaXZhY3kvc2VjdXJpdHkgY29u Y2VybnMgYnV0IGl0IGRvZXMgcHJvdmlkZSBmZWVkYmFjay4gDQoNCk5vcm1hdGl2ZSB0ZXh0IGlu ZGljYXRpbmcgcGh5c2ljYWwgaW5kaWNhdG9ycyBzdWNoIGFzIGEgYmxpbmtpbmcgTEVEIGFzc29j aWF0ZWQgd2l0aCBlYWNoIGRpc2NvdmVyeSBzdGF0ZSBjb3VsZCBiZSBSRUNPTU1FTkRFRCBmb3Ig Y2FwYWJsZSBkZXZpY2VzLiBPYnZpb3VzbHkgc29tZSBkZXZpY2VzIHNpbXBseSB3b27igJl0IGhh dmUgc3VjaCB0aGluZ3Mgc28gdGhpcyBjYW7igJl0IGJlIHJlcXVpcmVkLiBEb2luZyB0aGlzIHdv dWxkIGhlbHAgY2xhcmlmeSB0aGUgZGlzY292ZXJ5IHN0YXRlcy4gQWx0aG91Z2gga2VlcCBpbiBt aW5kIHRoZSBleGlzdGluZyBzMy4xLjEuMSByZWNvbW1lbmRhdGlvbiB0aGF0ICJNZXRob2RzIFNI T1VMRCBiZSBydW4gaW4gcGFyYWxsZWwgdG8gYXZvaWQgaGVhZCBvZiBxdWV1ZSBwcm9ibGVtc+KA nTsgbWVhbmluZyB0aGF0IHRoZSBzdGF0ZXMgaW5kaWNhdGVkIG1pZ2h0IGJlIGEgZ2VuZXJpYyDi gJxkaXNjb3ZlcnnigJ0uIA0KDQotIG1heA0KDQo+IE9uIE5vdiAxNywgMjAxNiwgYXQgNjoxOSBQ TSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiAN Cj4gDQo+IFdlIGRpc2N1c3NlZCB0b2RheSBpbiB0aGUgbWVldGluZyB0aGF0IHRoZSBib290c3Ry YXAgKGFuZCBvdmVyYWxsDQo+IGFuaW1hLXJlZmVyZW5jZS1tb2RlbCBzdGF0ZSBtYWNoaW5lKSBz aG91bGQgaW5kaWNhdGUgaW4gaXQncyBmYWlsdXJlDQo+IHRyYW5zaXRpb25zIHdoZXRoZXIgdGhl IGZhaWx1cmUgaXMgcGVybWFuZW50LCAicmVkIGxpZ2h0IiwgYW5kDQo+IHdoZXRoZXIgaXQgaXMg YSAieWVsbG93IGxpZ2h0IiAodHJ5IGFnYWluKS4NCj4gDQo+IFdlIG1heSBhbHNvIG5lZWQgYW4g Im9yYW5nZSBsaWdodCIgd2hpY2ggbWVhbnMsICJmYWlsZWQsIGJ1dCByZXF1aXJlcyBOTVMgaW50 ZXJ2ZW50aW9uIg0KPiANCj4gV2UgZGlkbid0IGhhdmUgdGltZSB0byBnZXQgYSBzZW5zZSBmcm9t IHRoZSByb29tIHdoZXRoZXIgb3Igbm90IHRoaXMga2luZCBvZg0KPiBmZWVkYmFjayAod2hpY2gg bWF5IGlkZWFsbHksIGJlIHJlYWwgcGh5c2ljYWwgZmVlZGJhY2sgdG8gdGhlIGluc3RhbGxlcikg aXMNCj4gdmFsdWFibGUuICBPZiBjb3Vyc2UsIGRldmljZXMgd2l0aCBiaWdnZXIgZGlzcGxheXMg bWlnaHQgd2FudCB0byBwcm92aWRlIG1vcmUNCj4gZGV0YWlscyBhYm91dCB0aGUgcHJvY2Vzcy4u Lg0KPiAge0kgcmVjYWxsIHRoZSB0aHJlZS1kaWdpdCBkaXNwbGF5IG9uIHRoZSBSUy82MDAwLCBh bmQgdGhlIG15c3RlcnkgdGhhdA0KPiAgZW5zdWVkIHdoZW4gSSBoYWQgYSBjb2RlIGNvbWUgdXAg dGhhdCBJQk0gc3VwcG9ydCBjb3VsZG4ndCBleHBsYWluLi4uLn0NCj4gDQo+IA0KPiANCj4gLS0g DQo+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFu IFNvZnR3YXJlIFdvcmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4gDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQW5p bWEgbWFpbGluZyBsaXN0DQo+IEFuaW1hQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0K From nobody Fri Nov 18 09:54:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A90129420 for ; Fri, 18 Nov 2016 09:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 Kci5r4uZZoFk for ; Fri, 18 Nov 2016 09:54:20 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB06B1293F4 for ; Fri, 18 Nov 2016 09:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1860; q=dns/txt; s=iport; t=1479491660; x=1480701260; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1swV1fSdIjr0/Rxy23Uc64rpPWs3I+4eLgc+K1rNWUg=; b=V1NR1gYKPzk9Iq1QG7LBeZGsrQsZRODZfMoERZQTyfpd6D6w5fMydC1b M8gEtgZ5zdI2E2adptCwU6k2sQ4RAgMmBryQ7531i06A348TeKgHHRayX MkC8QPSVkUutxn8FOsYu3YsvitjDRhlhEOarirqsKcvEmevJfPkA3vp6h U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAAAgPy9Y/5BdJa1EFwMaAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGDNwEBAQEBH1iBAAeNOJcPlGaBHwVjHQ2CQYM2AhqBcj8UAQIBAQE?= =?us-ascii?q?BAQEBYh0LhGgBAQEDAQEBASARMggQCwIBCBgCAhAEDAYCAgIlCxUPAQIBAxOIZ?= =?us-ascii?q?AgOLqtOgimDVod0AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBCYcwgl2DC4EvJgo?= =?us-ascii?q?mB4I2LYIwBZpLAYY/ijKQJ41bhAoBHjeBCx2DKByBEktyAYc2gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,510,1473120000"; d="scan'208";a="349356483" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2016 17:54:19 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAIHsJYc007825 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 Nov 2016 17:54:19 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 11:54:19 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Fri, 18 Nov 2016 11:54:19 -0600 From: "Max Pritikin (pritikin)" To: "anima@ietf.org" Thread-Topic: [Anima-bootstrap] weekly boostrap design team meetings Thread-Index: AQHSQU1cH8Dx3xRPFU20eRG4kcEuf6Dfa4sA Date: Fri, 18 Nov 2016 17:54:18 +0000 Message-ID: <66210CE2-586F-4F04-93AF-996E35D16D57@cisco.com> References: <9165.1479440353@dooku.sandelman.ca> In-Reply-To: <9165.1479440353@dooku.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.5] Content-Type: text/plain; charset="utf-8" Content-ID: <1390E23DE153854BAF01307DAF0AB541@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] [Anima-bootstrap] weekly boostrap design team meetings X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 17:54:22 -0000 InRpbWUgem9uZXMgYXJlIGhhcmTigJ0NCg0KSSB0aGluayB0aGlzIHNoaWZ0cyBvdXIgbWVldGlu Z3Mg4oCUIG1ha2luZyB0aGVtIG9jY3VyIDFociBlYXJsaWVyIHRoYW4gdGhleSBoYXZlIGJlZW4u IA0KDQpJcyB0aGF0IGludGVudGlvbmFsPyBBbSBJIGluIGVycm9yPyANCg0KLSBtYXgNCg0KPiBP biBOb3YgMTcsIDIwMTYsIGF0IDg6MzkgUE0sIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZA c2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gDQo+IA0KPiBUaGUgQW5pbWEgQm9vdHN0cmFwIGRlc2ln biB0ZWFtICh3aGljaCBpbmNsdWRlcyB3b3JrIG9uIHRoZSBvd25lcnNoaXANCj4gdm91Y2hlcikg d2lsbCBjb250aW51ZSB0byBtZWV0IGF0IDE1OjAwIFVUQyBvbiBUdWVzZGF5cyB2aWEgUlRDLWVu YWJsZWQNCj4gd2ViZXguICBUaGUgbWVldGluZyBpcyBhbmNob3JlZCB0byBVVEMsIG5vdCBFU1Qu DQo+IA0KPiBhbmltYSBib290c3RyYXAgZGVzaWduIHRlYW0NCj4gVHVlc2RheSwgTm92ZW1iZXIg MjIsIDIwMTYNCj4gMTA6MDAgYW0gRWFzdGVybiBTdGFuZGFyZCBUaW1lIChHTVQtMDU6MDApDQo+ IFJlY3VycmVuY2U6IEV2ZXJ5IFR1ZXNkYXksIGZyb20gVHVlc2RheSwNCj4gTm92ZW1iZXIgMjIs IDIwMTYsIHRvIFR1ZXNkYXksIE1hcmNoIDIxLCAyMDE3DQo+IA0KPiBMZXNzIGluZm9ybWF0aW9u DQo+IE1lZXRpbmcgbnVtYmVyOiA2NDQgNTE5IDg3Nw0KPiBNZWV0aW5nIHBhc3N3b3JkOiBib290 c3RyYXANCj4gTWVldGluZyBsaW5rOg0KPiBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tMjA0NTQxNGUyZTQ4NGUwYWQ0NzMxMWNlNjdjMWQ1OTYNCj4gSG9zdCBrZXk6IDk1 OTk0Mg0KPiANCj4gQXVkaW8gY29ubmVjdGlvbjoNCj4gMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0 b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpDQo+IDEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSkNCj4gU2hvdyB0b2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlv bnMNCj4gQWNjZXNzIGNvZGU6IDY0NCA1MTkgODc3DQo+IA0KPiANCj4gDQo+IC0tDQo+IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4gDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQW5pbWEtYm9vdHN0 cmFwIG1haWxpbmcgbGlzdA0KPiBBbmltYS1ib290c3RyYXBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYS1ib290c3RyYXANCg0K From nobody Fri Nov 18 16:42:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9AD129572 for ; Fri, 18 Nov 2016 16:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n5vj-pSsjHh for ; Fri, 18 Nov 2016 16:42:32 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160B8129567 for ; Fri, 18 Nov 2016 16:42:31 -0800 (PST) Received: from dooku.sandelman.ca (cl-27.chi-03.us.sixxs.net [IPv6:2604:8800:100:1a::2]) by relay.sandelman.ca (Postfix) with ESMTPS id 3ADF61F8FB; Sat, 19 Nov 2016 00:42:30 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C51A533F3; Sat, 19 Nov 2016 09:42:27 +0900 (KST) From: Michael Richardson To: "Max Pritikin \(pritikin\)" In-reply-to: <66210CE2-586F-4F04-93AF-996E35D16D57@cisco.com> References: <9165.1479440353@dooku.sandelman.ca> <66210CE2-586F-4F04-93AF-996E35D16D57@cisco.com> Comments: In-reply-to "Max Pritikin (pritikin)" message dated "Fri, 18 Nov 2016 17:54:18 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 19 Nov 2016 09:42:27 +0900 Message-ID: <11433.1479516147@dooku.sandelman.ca> Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] [Anima-bootstrap] weekly boostrap design team meetings X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 00:42:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: > "time zones are hard=E2=80=9D > I think this shifts our meetings =E2=80=94 making them occur 1hr earl= ier than > they have been. > Is that intentional? Am I in error? If the meeting is anchored to UTC, then the change is because we changed ou= r clocks two weeks ago. If you'd rather the meeting was anchored otherwise, such th= at it stays at 11am EST, please say so. I'm flexible regardless. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYL5/zAAoJEJVM4Vb9/EKQgmQH/RonDYRS16TCXoduZO+Xwkjf zRmW4PxLVuujvVFLy8UNOJKOj5t38AAnpg8K9J4hxJrBm+GhZwyZUwpr2HKDrlgU nOBN3T3nkd/D+uZEgHgl8nW+7kBMfmAAgC0Blu2HcoUSPJza39cAeIB0w2gCE2gE 1NX+S+j0Ewld/USUskNQ39VQgEHZRK4SMYzqbhOWguQmWL3AQXKypJcoryIsjq07 na5udIeVqOR6H13dMGh/ieSaDKiGWRk/HVqqJHPFtm5vIcr9bAXl2t6iuw7gLRcN 2QZG8nq+FzefaS0QBVdmlBoB35Cq4bObZmxfYNjmo8LSODCkkQ0uozNelgaAsMI= =tWDV -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 18 18:32:19 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3107812960E for ; Fri, 18 Nov 2016 18:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 J6un80r4Av2E for ; Fri, 18 Nov 2016 18:32:15 -0800 (PST) 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 A89AE129601 for ; Fri, 18 Nov 2016 18:32:15 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id x23so106042851pgx.1 for ; Fri, 18 Nov 2016 18:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Zvow0z8mVCorvFlBLp5eEXkleIlkh8AjG/3Cd96TZws=; b=Daw2BtlFXCq0vuM9gXPvRwqpXdKq4Jt3osTEHb7hrymX8uQgeE40LqMFkFkITTmMMY f9hSDmnrPvHU7Yi08KSRhSpMeZCxKQ2VOiEx+YGnVWDmrWNT/WE3bvP+iUw+nWyfB9nr uA6Fds56DylBfj5xWugG2ghDGWB09dA1hJjow1p1HKtqtCovxSGlj0kkd8awZhSiV6NU aVli3EDoaqh/JfRZ6B9/g8uuT+zVtaY4mnk5JOu33P4D9RpDO2jr90wJaxg1D8LS9kmd /wZWlqSU5xS/dhvA5B8R1838zI1+hXdw4RMz45IZ8jOQrmxsxdkd+XA6PI+BBvPR2A4R p/hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=Zvow0z8mVCorvFlBLp5eEXkleIlkh8AjG/3Cd96TZws=; b=Cun5HylUCcuvdOacoLe2QHll3dgKPzBWe+x2XFbqEMN3BSi4SzxhS+yaEPqXlT6a55 eQt7bQPZHk+XDCLdIGketIwvnavlOjg/n4OlzisiprtJgyMa/oLZ1cWfxf7bpAzEo+iV pr2NMBv6+rI9AVi99hENCXb5d8hPaRx/LrlfaFAk0f0uHg43bHW+nHl3PbzhuIHhDTol m4jmkqZ7ldd5Vdmr+cQ+sN/hudhRi250mNIFykP18qzuEFM38vXu9B0c4qZPKqnIhB7/ EfLU79nSo6koTBGSLukz2yXK/tWglVI3c/JZOr7QzELOEVwhzGBNeo6+d/SQII3uHu4A eNkg== X-Gm-Message-State: AKaTC02KyuwBEceQ39LoUD31h7maWAToTAJVYQgoqfVFyGLRb9SLkj2t3jx6cIz2msnhfw== X-Received: by 10.98.41.3 with SMTP id p3mr3693021pfp.22.1479522734930; Fri, 18 Nov 2016 18:32:14 -0800 (PST) Received: from [192.168.178.23] (228.225.69.111.dynamic.snap.net.nz. [111.69.225.228]) by smtp.gmail.com with ESMTPSA id b64sm20767554pfc.74.2016.11.18.18.32.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 18:32:14 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 19 Nov 2016 15:32:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] For the next version of GRASP... X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 02:32:17 -0000 Hi, At the moment, the only suggested updates for the next version of the GRASP draft are in this message from Toerless: https://mailarchive.ietf.org/arch/msg/anima-signaling/KyPI7tvxuAt-ehxHZ4yiEMB-qeg I didn't hear anything in the Anima sessions in Seoul that would require updates to the draft, so please do send along any other comments, however minor, as soon as possible. https://tools.ietf.org/html/draft-ietf-anima-grasp Regards Brian From nobody Sat Nov 19 15:53:07 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E0D126D73 for ; Sat, 19 Nov 2016 15:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ammP29zMq083 for ; Sat, 19 Nov 2016 15:53:05 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D98126B6D for ; Sat, 19 Nov 2016 15:53:04 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id E1F931F8EE for ; Sat, 19 Nov 2016 23:53:02 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 014F82234; Sun, 20 Nov 2016 08:52:57 +0900 (KST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 20 Nov 2016 08:52:57 +0900 Message-ID: <21744.1479599577@dooku.sandelman.ca> Archived-At: Subject: [Anima] update to slide 5 --- audit vs ownership voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 23:53:07 -0000 --=-=-= Content-Type: text/plain I've fixed slide 5, as it was off-by-a-line when going from ODP to PPT. The replacement is at: http://www.sandelman.ca/tmp/anima/ in the files ietf97_summary.odp and ietf97_summary.pdf Chairs, it would be better if the proceedings had the corrected slide. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYMOXZAAoJEJVM4Vb9/EKQr9gH/0eVnLvoyYT1HCyWqRrDsRhU NhXDbcpQd+1ttt3AAeK98FJeRPy7NRqiA72mf69uvNtgGRXWeWgB2dBGmRzIO7Hy d2g40fdR4+CgqorErUjFO8Q/opsY9/La4rbI1x+9xLruW/q5ciNwbYX/5QTpWJCt 3+TgKxbHtL7zhwGsNW6WBn0ClJDDDqBCvkSs70xRdvnxRZio5WkeIyVUlbJ6hNfx x4a3GHueiOeTODiZoGLYHAG3tn24kXjAba8uZmmOS7/jmWfgCeAC2rEf0cI/GPZN YDs7AFuZO0mC9U3sWkl+hapQy197eaQS2Vcr/0J/nVr3JlJKZxU2EFuZ8VOtL8s= =nejg -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 20 00:27:17 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25937129596 for ; Sun, 20 Nov 2016 00:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgZ545pwE4HR for ; Sun, 20 Nov 2016 00:27:12 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D74C12958C for ; Sun, 20 Nov 2016 00:27:12 -0800 (PST) Received: from dooku.sandelman.ca (cl-27.chi-03.us.sixxs.net [IPv6:2604:8800:100:1a::2]) by relay.sandelman.ca (Postfix) with ESMTPS id 23DBD1F914; Sun, 20 Nov 2016 08:27:09 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 43B2F3407; Sun, 20 Nov 2016 15:41:37 +0900 (KST) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-reply-to: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> Comments: In-reply-to "Michael Behringer (mbehring)" message dated "Fri, 18 Nov 2016 01:53:02 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 20 Nov 2016 15:41:37 +0900 Message-ID: <8220.1479624097@dooku.sandelman.ca> Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 08:27:15 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > One question that just came up: Should Intent be designed per ASA or > per AF? > My suggestion previously was to segment Intent into sections per > Autonomic Functions. > Example: Intent for the bootstrap function could be: - allow > bootstrapping new devices only during maintenance window I agree that this is a useful policy. I come back to such pseudo-time-based Intents to wonder how they work. We discussed this a year ago... and never, I thought, reached consensus. I think that the answer to that would tell me how Intents should be partitioned. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYMUWhAAoJEJVM4Vb9/EKQS0sIAKSU87m5epXdU9xF7owZ2m2V Qf/+I/jTeBlObEOC8DH/mh9eDaEJNRJ7Un8AU8rJ4M6AAW18pPo1oKUwKY4dzCK7 sSpXu4wur2PUX1ybdoFxvmTUONkg6ENt2rLDTk9N819zY979HXs22Azpmt0HsjUK 97tXhsN/g9tCYdT6TlXev6bpjpFyU1K2gxbChO6D2MkqCI6fU9u4xqcLGE3lW6mj jrgCUatzj7YyLOIXX3+NgswKTNp8nm90vH46SoCJq3cIBsk1AOKMFPkZRMoX3DKQ CLqh4iqQnuW6JYAKCDwbDMn04ASgnkyOLWdhLPYKRBe96j4X765dPwm5CJqXYi0= =0u4n -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 20 00:27:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF91295A4 for ; Sun, 20 Nov 2016 00:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkM5hX4Uzgg2 for ; Sun, 20 Nov 2016 00:27:15 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C45129596 for ; Sun, 20 Nov 2016 00:27:15 -0800 (PST) Received: from dooku.sandelman.ca (cl-27.chi-03.us.sixxs.net [IPv6:2604:8800:100:1a::2]) by relay.sandelman.ca (Postfix) with ESMTPS id A7C341F92C; Sun, 20 Nov 2016 08:27:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id D13471928; Sun, 20 Nov 2016 15:26:36 +0900 (KST) From: Michael Richardson To: "Max Pritikin \(pritikin\)" In-reply-to: <5626B645-B742-4CFA-A42D-47FBBB310668@cisco.com> References: <29627.1479431967@dooku.sandelman.ca> <5626B645-B742-4CFA-A42D-47FBBB310668@cisco.com> Comments: In-reply-to "Max Pritikin (pritikin)" message dated "Fri, 18 Nov 2016 16:00:19 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 20 Nov 2016 15:26:36 +0900 Message-ID: <6937.1479623196@dooku.sandelman.ca> Archived-At: Cc: anima Subject: Re: [Anima] red/yellow/green lights for bootstrap and ACP feedback X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 08:27:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: > Section 3.1.1. Discovery Supports a backoff mechanisms but on review > I=E2=80=99m thinking the language about final failure to be vague: "O= nce all > discovered services are attempted the device SHOULD return to Multica= st > DNS. It should periodically retry the vendor specific mechanisms. T= he > Pledge may prioritize selection order as appropriate for the > anticipated environment." Michael B and I had some long conversation about how manufacturers configure new nodes. We are pretty sure that they will require either audit tokens, or ownership vouchers, never both. As part of that definition, the manufacturer would also decide what other vendor specific mechanisms will exist. So to emphasize your point, our role isn't to say what those mechanisms are, (with the exception of mDNS, which I'd like to put into an appendix), but rather when they get used in the state machine. > Section 5.1 Request Voucher from the Registrar "As detailed in Section > 3.1.1 if no suitable Registrar is found the Pledge restarts the state > machine and tries again. So a Registrar that is unable to complete t= he > transaction the first time will have future chances.=E2=80=9D > A flood telemetry status indicator in addition to direct feedback to > the Registrar. This would enable any local equipment to better report > the Pledge=E2=80=99s state. I suppose this SHOULD be signed but may b= e unsigned > to avoid extra processing overhead on the Pledge. This would leak the > Pledge=E2=80=99s identity information so there are privacy/security c= oncerns > but it does provide feedback. I think that this can be decoupled from our work, and we could define this later? I think it's pretty important, but I want to get it right. > Normative text indicating physical indicators such as a blinking LED > associated with each discovery state could be RECOMMENDED for capable > devices. Obviously some devices simply won=E2=80=99t have such things= so this > can=E2=80=99t be required. Doing this would help clarify the discovery > states. Although keep in mind the existing s3.1.1.1 recommendation th= at > "Methods SHOULD be run in parallel to avoid head of queue problems=E2= =80=9D; > meaning that the states indicated might be a generic =E2=80=9Cdiscove= ry=E2=80=9D. Glad you agree about the difficulties here, yet the opportunity is clear. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYMUIcAAoJEJVM4Vb9/EKQAeYH/2IKoD/8kJNQExYSx+sEbCsx 2vrks65jAsw0wQt1jj7v2ddBcYsueSOOlz8IAN+u6x3HVW8rPmu0ntvx37XIMR9r 9sRe2m9v1uk01PPJqSiw1PN7n/iylaQVIvah+FJmZUEHYCcLj627KpcSghnZGiSN 4KKdO8Fvpovy7vIfi0G7jgpUp+2fvCOqDlIkUlQx4He4MBAvr3Er0zbjOow1YFdd fpmumssjZzUMTwU/4DqJ6B9pJej+BokJ7wMPXImyYMp4Mt0bBYhyKOzVo94g7qr1 7gqB4pFiwIxh7hVKJir9+PL0RcCdUo7e3vP1jagVAeuCkmvB55MZrba1h+EYFKU= =AcyM -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 20 09:36:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AABC1294AA for ; Sun, 20 Nov 2016 09:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 mNTlEC0xnDOc for ; Sun, 20 Nov 2016 09:36:31 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F97128B37 for ; Sun, 20 Nov 2016 09:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1256; q=dns/txt; s=iport; t=1479663391; x=1480872991; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cFhXVnm4pr88kdpVPZvyCnYHcO4mjTdbJ+muojAOLpA=; b=PovPKK6sIfaG0ATefwXIUECS45yR7xzmHATmKq30J+HSVdbCuWOyetvi Nl9KhIpbu2nABocsPaxpmMiVnpO+AVxim8AQo5xqPgNFLpeZr/XNZSQWJ tZ4OW6wn3GSIzo/o6LpaWUGPTcGV99IHBRm+3gOIM6hWlbEnjt6taXAFq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAQBm3jFY/51dJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAR+BWAeNOJcRlG6CBYURgRACgX0/FAECAQEBAQEBAWIohGg?= =?us-ascii?q?BAQEEOj8MBAIBCBEEAQEBHgkHMhQJCAEBBA4FCIhlqR+LSwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARyGPIRaiioFmk0BkG+QLo1fhAoBHjeBEoVBcocBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,522,1473120000"; d="scan'208";a="173498369" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2016 17:36:30 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uAKHaUBR004439 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 20 Nov 2016 17:36:30 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 20 Nov 2016 11:36:29 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Sun, 20 Nov 2016 11:36:29 -0600 From: "Michael Behringer (mbehring)" To: Michael Richardson Thread-Topic: [Anima] Intent per ASA or per AF? Thread-Index: AdJBPZCUap75TyB7THivcdpl+3+EcAB7d5OAAAo/4aA= Date: Sun, 20 Nov 2016 17:36:29 +0000 Message-ID: References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> <8220.1479624097@dooku.sandelman.ca> In-Reply-To: <8220.1479624097@dooku.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.65.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 17:36:32 -0000 > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: 20 November 2016 07:42 > To: Michael Behringer (mbehring) > Cc: anima@ietf.org > Subject: Re: [Anima] Intent per ASA or per AF? >=20 >=20 > Michael Behringer (mbehring) wrote: > > One question that just came up: Should Intent be designed per ASA o= r > > per AF? >=20 > > My suggestion previously was to segment Intent into sections per > > Autonomic Functions. >=20 > > Example: Intent for the bootstrap function could be: - allow > > bootstrapping new devices only during maintenance window >=20 > I agree that this is a useful policy. >=20 > I come back to such pseudo-time-based Intents to wonder how they work. > We discussed this a year ago... and never, I thought, reached consensus. >=20 > I think that the answer to that would tell me how Intents should be > partitioned. Not sure I completely understand, and not sure that's what I wanted to say.= My point was that a policy like above could be implemented on the proxy as= well as the registrar. Maybe in some cases on both. So, segmenting per fun= ction seems more useful than by ASA.=20 Michael From nobody Sun Nov 20 11:08:30 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B8129685 for ; Sun, 20 Nov 2016 11:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1Bz4BxtwQxs for ; Sun, 20 Nov 2016 11:08:27 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2979A12942F for ; Sun, 20 Nov 2016 11:08:27 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id f188so122025853pgc.3 for ; Sun, 20 Nov 2016 11:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=l2LN/DThE1Lh2inEAiLdJKH+k8Cih7y/8MFATk1Zme0=; b=EnUYCgzQ8MKgGpQK54JQ4p6BnH7FPPvnGwJdxVqbhb43g/fGTRj7hgBBaDEMnKE2lv 8hI11Fz1SCBx8lmKznlW8d3wQ1TNKkD+SIwmN7D/C3AIPVblJkzaPeiCEpT/STsXG4+v Sbkns5hoowy8EXO+CpWMGvIsdmm7DH786jSRl3MGHASZz44ARfwdrCU8fdgNiLlkSd4j oo1k9cN+ooweSNHCQusTIB6YsNDqVzOGnp4Da0R8xeRquctaAPZEAlgCnmzoD+kTBGIm hQgb74MlUfbQaNslVUZY+qRKT1LTwRRMQrqvNuuCf9QZgiRPxbspLTYa2suaFLh94/dA IAbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=l2LN/DThE1Lh2inEAiLdJKH+k8Cih7y/8MFATk1Zme0=; b=lZ0wyu8Ya7d4tJtsEPZhMIZeph+Je2Gv+G0nbXUdAqTZIb1AUJUckqHtvwXXrW7vCB jyl/1CoTLo5nWQqAlYT19aaE1wEFwQSgGy9iyTtcRgLnQyjm1TqhE+/qtDbY7WzLvPV/ AJ50S5u9TaKcjIVyYIthdXtNgAyKvI/713cOIxjrd9lX0A6Ql+fUVgXA6/uPCJUQl1/j 8W59MExttu+3M1iqKdN6TJCa/GLVjQaciyg4ywEDJwOVWopfNeg6oa+SYXY5fOM6PAFr EXKME4DHk0+8w7KPlDa45CqfLMF4F1mDrnOWJAY2ZQJXzDR8VjjITUuPiSqs3n6bdKJp l53Q== X-Gm-Message-State: AKaTC01e6EZqA8D9ituXPT4vUorHBqqY9BDcwiK/lq/QOQoCjwrj5NGvdUfMJFF5iVg8gw== X-Received: by 10.99.218.21 with SMTP id c21mr23250354pgh.67.1479668906434; Sun, 20 Nov 2016 11:08:26 -0800 (PST) Received: from [192.168.178.23] (77.219.69.111.dynamic.snap.net.nz. [111.69.219.77]) by smtp.gmail.com with ESMTPSA id x123sm13815895pgb.3.2016.11.20.11.08.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 11:08:25 -0800 (PST) To: anima@ietf.org References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> <8220.1479624097@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <890c0598-bcdb-cade-2437-30f4360033c8@gmail.com> Date: Mon, 21 Nov 2016 08:08:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 19:08:29 -0000 On 21/11/2016 06:36, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] >> Sent: 20 November 2016 07:42 >> To: Michael Behringer (mbehring) >> Cc: anima@ietf.org >> Subject: Re: [Anima] Intent per ASA or per AF? >> >> >> Michael Behringer (mbehring) wrote: >> > One question that just came up: Should Intent be designed per ASA or >> > per AF? >> >> > My suggestion previously was to segment Intent into sections per >> > Autonomic Functions. >> >> > Example: Intent for the bootstrap function could be: - allow >> > bootstrapping new devices only during maintenance window >> >> I agree that this is a useful policy. >> >> I come back to such pseudo-time-based Intents to wonder how they work. >> We discussed this a year ago... and never, I thought, reached consensus. >> >> I think that the answer to that would tell me how Intents should be >> partitioned. > > Not sure I completely understand, and not sure that's what I wanted to say. My point was that a policy like above could be implemented on the proxy as well as the registrar. Maybe in some cases on both. So, segmenting per function seems more useful than by ASA. This conversation strengthens my conviction that we should leave this as flexible as possible, because the requirements will change with experience. In other words, label each segment of Intent - and the label may well be the name of an autonomic function - but do not make rules about the labels. That way there is flexibility for the future. Brian From nobody Mon Nov 21 09:15:13 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5A5129AC9 for ; Mon, 21 Nov 2016 09:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umV0ubbJmBvi for ; Mon, 21 Nov 2016 09:15:10 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3192A129A7F for ; Mon, 21 Nov 2016 09:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1166; q=dns/txt; s=iport; t=1479748510; x=1480958110; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DgBgH/9A4lXAh+0OpxOXKwN+yvlkWES+AGLummgfkjI=; b=gTBFkw/qYAJXxD1HpAaaHrBEsTMvoyAx1AWEwp9U5ytyGmYA2sMF6ZM6 IPnTdyw8DshJ6LxAbvtzN2ItIl7RqN/EYXEtbj7HI8Ozbv8asHCMgKUuu Vgfajtslvjwvem83AkhTokKhAxtvHzaMqGOeAjA/is6ixxUrVHMjtyoeK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMBABYKjNY/5JdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAR+BWAekS5RuggWCa4M2AhqBaUESAQIBAQEBAQEBYiiEaAE?= =?us-ascii?q?BAQMBIxFFBQsCAQgYAgImAgICMBUQAgQOBYhlCKsEgimLTAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARyBCYcwgl2HTS2CMAEEmk0BkHaBcIR3iUCNX4QKASUOIoEShUF?= =?us-ascii?q?yh0WBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,528,1473120000"; d="scan'208";a="350328052" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2016 17:15:09 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uALHF9WE008422 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Nov 2016 17:15:09 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.1210.3; Mon, 21 Nov 2016 11:15:08 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Mon, 21 Nov 2016 11:15:08 -0600 From: "Max Pritikin (pritikin)" To: Michael Richardson Thread-Topic: [Anima] [Anima-bootstrap] weekly boostrap design team meetings Thread-Index: AQHSQU1cH8Dx3xRPFU20eRG4kcEuf6Dfa4sAgAByCYCABDoEAA== Date: Mon, 21 Nov 2016 17:15:08 +0000 Message-ID: <99620E8A-4F28-4E3D-A313-E5FA2FE65774@cisco.com> References: <9165.1479440353@dooku.sandelman.ca> <66210CE2-586F-4F04-93AF-996E35D16D57@cisco.com> <11433.1479516147@dooku.sandelman.ca> In-Reply-To: <11433.1479516147@dooku.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.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] [Anima-bootstrap] weekly boostrap design team meetings X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Nov 2016 17:15:12 -0000 SeKAmW0gYW0gT0sgd2l0aCB0aGUgY3VycmVudCBhbmNob3JpbmcuIA0KDQpJdCBpcyBub3QgY2xl YXIgdGhhdCB0aGUgY2FsZW5kYXJpbmcgdG9vbHMgZGVhbCB3aXRoIHRoaXMgd2VsbCBzbyBJIHdh bnRlZCB0byBiZSBzdXJlIG9mIGhvdyBpdCBzaG9vayBvdXQuIHRoYW5rcywNCg0KLSBtYXgNCg0K PiBPbiBOb3YgMTgsIDIwMTYsIGF0IDU6NDIgUE0sIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2ll dGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gDQo+IA0KPiBNYXggUHJpdGlraW4gKHByaXRpa2lu KSA8cHJpdGlraW5AY2lzY28uY29tPiB3cm90ZToNCj4+ICJ0aW1lIHpvbmVzIGFyZSBoYXJk4oCd DQo+IA0KPj4gSSB0aGluayB0aGlzIHNoaWZ0cyBvdXIgbWVldGluZ3Mg4oCUIG1ha2luZyB0aGVt IG9jY3VyIDFociBlYXJsaWVyIHRoYW4NCj4+IHRoZXkgaGF2ZSBiZWVuLg0KPiANCj4+IElzIHRo YXQgaW50ZW50aW9uYWw/IEFtIEkgaW4gZXJyb3I/DQo+IA0KPiBJZiB0aGUgbWVldGluZyBpcyBh bmNob3JlZCB0byBVVEMsIHRoZW4gdGhlIGNoYW5nZSBpcyBiZWNhdXNlIHdlIGNoYW5nZWQgb3Vy IGNsb2Nrcw0KPiB0d28gd2Vla3MgYWdvLiAgSWYgeW91J2QgcmF0aGVyIHRoZSBtZWV0aW5nIHdh cyBhbmNob3JlZCBvdGhlcndpc2UsIHN1Y2ggdGhhdA0KPiBpdCBzdGF5cyBhdCAxMWFtIEVTVCwg cGxlYXNlIHNheSBzby4gIEknbSBmbGV4aWJsZSByZWdhcmRsZXNzLg0KPiANCj4gLS0gDQo+IE1p Y2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3 YXJlIFdvcmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4gDQo+IA0KPiANCg0K From nobody Mon Nov 21 09:19:53 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C9512956D for ; Mon, 21 Nov 2016 09:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF9uhse0E_5q for ; Mon, 21 Nov 2016 09:19:50 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022AB129AE8 for ; Mon, 21 Nov 2016 09:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=787; q=dns/txt; s=iport; t=1479748773; x=1480958373; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=//eLJ3p4+zKtT1EbrfDNrk3S4GriKqayLPROLMpbFtU=; b=iWNwAqSs0wQaFMEjRlLgNdaZTb1YDvnSHAjEIdFqzSTv9ZEvU6FHoghR ur7lVKF4oBaFEdH/I9Di9dQ2uwnGFRHfFfVSINyQhdqnZvZzcXCvuGiEQ ka0DVbWGU8YISIJeK2LDOaCrxj7nMuA1t9F+cw+i7Y1xbn3hC9nB+85r7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCBQA6LDNY/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAR+BX6RLlG6CBYURgRACggNAEwECAQEBAQEBAWIohGgBAQE?= =?us-ascii?q?DATpECwIBCDYQMiUBAQQBGohdCK00i0wBAQEBAQEBAwEBAQEBAQEghjyEWooqB?= =?us-ascii?q?Y5ri2IBkG+QLpFpASACM4EShUGIN4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,528,1473120000"; d="scan'208";a="349332473" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2016 17:19:33 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uALHJXPY000317 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Nov 2016 17:19:33 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 21 Nov 2016 11:19:32 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Mon, 21 Nov 2016 11:19:32 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Intent per ASA or per AF? Thread-Index: AdJBPZCUap75TyB7THivcdpl+3+EcAB7d5OAAAo/4aAAD9S8gAAhoQ7A Date: Mon, 21 Nov 2016 17:19:32 +0000 Message-ID: References: <7f30b33118334c09a54acb9293b2c265@XCH-RCD-006.cisco.com> <8220.1479624097@dooku.sandelman.ca> <890c0598-bcdb-cade-2437-30f4360033c8@gmail.com> In-Reply-To: <890c0598-bcdb-cade-2437-30f4360033c8@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent per ASA or per AF? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Nov 2016 17:19:51 -0000 > This conversation strengthens my conviction that we should leave this as > flexible as possible, because the requirements will change with experienc= e. > In other words, label each segment of Intent - and the label may well be = the > name of an autonomic function - but do not make rules about the labels. >=20 > That way there is flexibility for the future. In principle, I agree, we want to be as flexible as possible. But the ANI M= UST be able to segment Intent into components. So I think we can only permi= t "segment types" that the ANI understands and knows how to handle.=20 In that, I think we can only define "AN-function" and "AN-ASA" at this mome= nt, at least there is no other clear option right now. My point, we do need= some rules.=20 Michael From nobody Wed Nov 23 14:47:46 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7EF129476 for ; Wed, 23 Nov 2016 14:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, 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 mXTegMZC4byo for ; Wed, 23 Nov 2016 14:47:42 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B8F12944D for ; Wed, 23 Nov 2016 14:47:42 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ABDEDE1F4 for ; Wed, 23 Nov 2016 18:04:20 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AD2C8637A8 for ; Wed, 23 Nov 2016 17:47:40 -0500 (EST) From: Michael Richardson To: anima@ietf.org 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] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 22:47:45 -0000 --=-=-= Content-Type: text/plain I'm sorry for the wide-ranging comments here; I started on Sunday on the airplane, but didn't finish until today. We talked M_FLOOD yesterday at the bootstrap call, and we will edit to synchronize with my comments here. Chairs: Are we using the issue tracker? It's not in the menu at: https://tools.ietf.org/wg/anima/ If not, where did the issue # that Brian and co. used to track my previous comments? Oh, it's just numbers in the issues part of the document... I went through my previous comments which are at: https://www.ietf.org/mail-archive/web/anima/current/msg02148.html I think that sections 3.3 and 3.4 are a response to my request for an operating overview, and I think that this works well. I asked for examples, and they are in Appendix D, but while reading the document, I had forgot about it, and nothing told me to go look there in the text. A see D.1 would be good. Could I ask for small change: from: The initiator multicasts a discovery message: to: The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a discovery message: [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 2, 2, 0]] and ditto for "A peer (X) responds", as it took me a minute or two to figure out what this third argument was, that it was the initiator address. Now to comments on the -08 text... 2.1 --- does this belong in GRASP, vs reference model document? Would like MB and Toerless to confirm that it is consistent in wording with reference model document! > D8. The discovery process must not generate excessive traffic and > must take account of sleeping nodes in the case of a constrained-node > network [RFC7228]. I think this actually out of charter, and furthermore, GRASP doesn't do a very good job of taking this into account. I think it should be striked out. SN7. orig: o Dependencies and conflicts: In order to decide a configuration on a given device, the device may need information from neighbors. orig: o Dependencies and conflicts: In order to decide upon a configuration for a given device, the device may need information from neighbors. > be as automatic as possible. The protocol's role is limited to > the ability to handle discovery, synchronization and negotiation > at any time, in case an ASA detects an anomaly such as a > negotiation counterpart failing. I think this sentence could use some work. Maybe: The protocol's role is limited to discovery, synchronization and negotiation. This process can occur at any time, and an ASA may need to repeat any of these steps when the ASA detects an anomaly such as a negotiation counterpart failing. 3.1. terminology was: Discovery, Negotiation and Synchronization. In the protocol, an objective is represented by an identifier and if relevant a value. new: Discovery, Negotiation and Synchronization. In the protocol, an objective is represented by an identifier and -- if relevant -- a value. (or maybe two comma are more correct) There is too much functional description in the XYZ Objective descriptions. At least, it needs to have a forward reference. going on, remove *cut*/*tuc* o Discovery Responder: a peer that either contains an ASA supporting the discovery objective indicated by the discovery initiator, or caches the locator(s) of the ASA(s) supporting the objective. *cut*The locator(s) are indicated in a Discovery Response, which is normally sent by the protocol kernel, as described later.*tuc* 3.2: >Interface (API) will be needed between GRASP and the ASAs. In some >implementations, ASAs would run in user space with a GRASP library >providing the API, and this library would in turn communicate via >system calls with core GRASP functions running in kernel mode. For I still don't know why "kernel mode" is used here. Certainly on Linux and Windows, we don't need code in the "kernel", just a priviledged process if we are allocated a <1024 port, otherwise, just an unprivledged system daemon. On a Cisco/Huawei/Broacade router, I don't know a lot about OS architecture, but on Juniper a straight FreeBSD process would work fine. "operating system core module" (section 3.4) is much better. I think I mentioned "kernel" issue before. The reference to RFC2608 seems unwaranteed on page 13. section 3.3 was good to write down, but seems like it is too much like a discussion. I would like the bullets as subsections, as they are really modes of operation! 3.4 should mention M_FLOOD along with M_DISCOVERY. or, perhaps the M_FLOOD mechanism can be clearly labelled as providing awareness of an ASA. I appreciate 3.5.1 trying to establish some security via (D)TLS, but it simply doesn't say enough to result in interoperability. (for instance, should certificates be validated? If so, what should be in the CN? Do we need PFS? When do we rekey? Are client-side certificates important? Is there a link between IP addresses and something in the CN?) I'd prefer that all the mention of TLS be removed to another document that would specify it more completely, a document titled something like: "Using GRASP between service providers" or: "Securing GRASP using TLS" or: "CoAP/DTLS mode for GRASP" I'd like 3.5.2 point (1) be numbered 3.5.2.1 so it can be better referenced, and I'd like it say something like: 3.5.2.1 Inter-domain GRASP Instance As mentioned in Section 3.3, some GRASP operations might be performed across an administrative domain boundary by mutual agreement. Such operations MUST be confined to a separate instance of GRASP with its own copy of all GRASP data structures. Details of this mode are the subject of a future document that would clearly detail the security limitations of such an instance. 3.5.2.2 Bootstrap and ACP GRASP Instance (DULL) This instance is nicknamed DULL - Discovery Unsolicited Link Local. The bootstrap process uses only M_FLOOD messages to announce the location of the bootstrap proxy. This message is used only on-link using link-local multicast, on the underlying (insecure) media. Full ANIMA nodes that act are willing to act as bootstrap proxies will include a flag indicating this into this message. Full ANIMA nodes looking for ACP peers will also indicate that in the message. Full ANIMA nodes MAY listen for M_FLOOD messages on insecure interfaces. Other messages MUST be discarded. M_FLOOD messages which are improperly formatted such as: o having a loop count > 1 o having a GRASP message type != M_FLOOD o having a non-link-local source address MUST be discarded. It is acceptable for the M_FLOOD to be to the ALL_GRASP_NEIGHBOR multicast address, or to be unicast to the host in question. ANIMA nodes in bootstrap mode listen on the ALL_GRASP_NEIGHBOR multicast address, and listen according to the same rules above, but examine the BOOTSTRAP_PROXY attribute only. Details of DULL are included in: [I-D.ietf-anima-autonomic-control-plane] I want to suggest that point (3), about ACP formation be dropped, as it is included in part 2. In 3.5.3, please delete: In particular, to guarantee interoperability during bootstrap and startup, using TCP for discovery responses is strongly advised. I don't think it makes any sense at this point. Bootstrap discovery will use M_FLOOD, while actual bootstrap uses either EST (RFC7030) which is HTTP/TCP, or possibly one of the EST over CoAP proposal(s) [yes, currently plural, alas] Again, please omit further discussion of TLS. In section 3.5.4.1, can we write: The discovery (M_DISCOVERY) action will normally be followed by a negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action. The discovery results could be utilized by the negotiation protocol to decide which ASA the initiator will negotiate with. 3.5.4.2: A complete discovery process will start with a multicast (of M_DISCOVERY) on the local link. On-link neighbors supporting the discovery objective will respond directly (with M_DISCOVERY). A neighbor with multiple interfaces SHOULD respond with a cached discovery response if it was learnt from another interface. ADD: A neighbor SHOULD NOT respond with a cached response on an interface if it learnt that information from the same interface. 3.5.4.3: s/GRASP kernel/GRASP core/ 3.5.4.4: QUERY re: The relayed discovery message MUST have the same Session ID as the incoming discovery message and MUST be tagged with the IP address of its original initiator (see Section 3.8.4). I thought we were adding something about Link Local addresses here? 3.5.5: re: The details, including the distinction between dry run and an actual configuration change, will be defined separately for each type of negotiation objective. I would very much like it if dry-run/real-run request was standardized. This would make external auditing/debugging (such as via network sniffer) much easier to see. Can we change this paragraph to include message types? If the counterpart can immediately apply the requested configuration, it will give an immediate positive (accept) answer (using M_END). This will end the negotiation phase immediately. Otherwise, it will negotiate (using M_NEGOTIATE) It will reply with a proposed alternative configuration that it can apply (typically, a configuration that uses fewer resources than requested by the negotiation initiator). This will start a bi- directional negotiation (using M_NEGOTIATE) to reach a compromise between the two ASAs. ... a peer to insert latency in a negotiation process if necessary (Section 3.8.9, M_WAIT). 3.5.5.1: change: A Discovery message MAY include a Negotiation Objective option. In this case the Discovery message also acts as a Request Negotiation message to indicate to the Discovery Responder that it could directly reply to the Discovery Initiator with a Negotiation message for rapid processing, if it could act as the corresponding negotiation counterpart. However, the indication is only advisory not prescriptive. to: A Discovery message MAY include a Negotiation Objective option. In this case it is as if the initiator sent the sequence M_DISCOVERY, followed by M_REQ_NEG. This has implications for the construction of the GRASP core, as it must carefully pass the contents of the Negotiation Objective option to the ASA so that it may evaluate the objective directly. When a Negotiation Objective option is present the ASA replies with an M_NEGOTIATE message (or M_END if it is immediately satisfied with the proposal), rather than with an M_RESPONSE. 3.5.6.1: s/GRASP kernel/GRASP core/ Please add, after para 4, ("..with multiple link-layer.."): Link-Layer Flooding is supported by GRASP by setting the loop count to 1, and sending with a link-layer source address. Floods with link-layer source addresses and a loop count larger than 1 are not supported, and such messages MUST be discarded. My comments about section 3.5.5.1 would seem to apply to 3.5.6.2 as well. 3.8.3: please add: The CBOR parser used by GRASP should be configured to know about the GRASP_DEF_MAX_SIZE so that it may defend against overly long messages. 3.8.4: Exceptionally, a Discovery message MAY be sent unicast to a peer node (via UDP or TCP), which will then proceed exactly as if the message had been multicast, except that when TCP is used, the response will be on the same socket as the query. 3.8.6, about: > If a node receives a Request message for an objective for which no > ASA is currently listening, it MUST immediately close the relevant > socket to indicate this to the initiator. if the time sequence is: initiator ----M_DISCOVERY---> responder (GRASP core) (UDP) ...> pass details to ASA initiator<----M_RESPONSE----- ASA (TCP) initiator-----M_REQ_NEG-----> ASA (same socket) then, according to above, why would an ASA have responded in the first place if not be the right ASA? 3.8.11: I think that the "initiator" option is just an IP address. No port number or protocol (UDP/TCP), right? Can we please have an example for M_FLOOD? Is this valid: [M_FLOOD, 124567, fe80::1234, 27, [[O_IPv6_LOCATOR, fe80::1234, IPPROTO_UDP, 500]], ["ACP", flags, 1, ["bootstrap-okay"]] Could an O_DIVERT occur in an M_FLOOD? Can we have more than one locator option? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWDYciYCLcPvd0N1lAQJpcAgAnbCJZnw8vknM6GiEXP9TAnR2Lupp5RVr SH5dHCao0R0xoLruVlAizCtfn7vyKcsbl3BZBX80ZNF/LI7Pj8MXPYOiLSe+VS1r N1B6zTe0/La2OAT+sapnP9czkz4XJ5Lbh6RjmfHmA/wElIMYjmbwjRwsnCugviVJ KYEOb8hobRCOg/ErsM7nAAFN1SA0W0GbYe2vmGuFwuoSxpRU71/cUgZJvrDNAo+x 0syLPs+lC+SqfIPqdJpPJX1DOqBHQvYd7+sWGC57tDghBjlyTd+MhZXNHlZtjVma RFxdShPg07DEhvigLXUrh/vViIHLQBQingAuuVAB2zGp2CZcvZ6Tyw== =mcmD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 23 19:41:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7029B129464 for ; Wed, 23 Nov 2016 19:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVitUl_KpDT7 for ; Wed, 23 Nov 2016 19:41:32 -0800 (PST) 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 EE1C0126D73 for ; Wed, 23 Nov 2016 19:41:31 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id x23so13291992pgx.1 for ; Wed, 23 Nov 2016 19:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=JdxqvWXJNzM2fyvOKRK/w+CMTOALCkW1JjjFflc5dmE=; b=QC0/GmvFssO+J/0VURa/3lxiZye+om+TaHydmw0hrkELpZc8ywX/wKgYkLZ5rFIydf dCN9WEcA4gSC8PQShRUPS76ihqM6UJyKmv6aMCNhn++NbDiL++LLo1g0hHKAFiSYv68Y wbOC447r7UAr2z5NTnQz+hX35M0NE39prSchIfYVt0Jw99nr15I8COVhS17linN1zdeb MYaSuOZSa7+9wl++vdGAj7zJNv+/X0ID4VmKbsFpkcEY627+0wvLQXG+fw7BQTWdLLie i1PqeXw91KYTm3yO4D+571aWDHwE5vqdXMWdM7JRnQpiPAeYgMSFwcZkkaSEn4wMJWZ1 09Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=JdxqvWXJNzM2fyvOKRK/w+CMTOALCkW1JjjFflc5dmE=; b=l3fSk7U0dsMQ0mqLp//4/2TEkIxj6fHzQJqtxJdKkQBrg5sxKYyXjDayvK7fF0hcEH iGxnH6jbeAzG6aGABsND/oqkx1R492PPZ0cCIUmFqspUVrh4MvMv3DpUz0ElrQGRCk2c wZksl5L63tWCwqrds6+u2cA6N4suFrDIMja4etyvan90fnYYlfI0khLLOEzDvFGdeSxI 8lspFhfxg3UqHdgd+uk02bM4xy57smzOYzBHC9y4PaS5ZUWhsiZd2U4JgvhA3pXjJQ/u 4+zzg4BaUjpUQXTzt+JePAN0QmpM0EphQVIl5HkH0brIGODpWo2NqcurDoIyOYnLYIQ0 c2Xg== X-Gm-Message-State: AKaTC033Z0rKCnr4RDqiwPx5og0UgHZDN9GbD6FqXuo3gXO0qKwlYY0cxUD1QDPxjH9qWQ== X-Received: by 10.84.172.67 with SMTP id m61mr727376plb.60.1479958891161; Wed, 23 Nov 2016 19:41:31 -0800 (PST) Received: from [192.168.178.23] ([118.148.64.182]) by smtp.gmail.com with ESMTPSA id o126sm37874264pga.34.2016.11.23.19.41.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 19:41:30 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <4565.1479941260@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 24 Nov 2016 16:41:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <4565.1479941260@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 24 Nov 2016 03:41:35 -0000 Thanks Michael, we will wait a few more days before rolling up all comments received. I am fine with most of your suggestions. A few things caught my eye: >> in the case of a constrained-node network [RFC7228]. Yes, that clause is out of scope. >> >system calls with core GRASP functions running in kernel mode. For ... > I still don't know why "kernel mode" is used here. You're correct, it's unnecessary. > The reference to RFC2608 seems unwaranteed on page 13. A matter of taste I guess. But it can be dropped with no pain. > I'd prefer that all the mention of TLS be removed to another document that > would specify it more completely, If we did that, we'd need at least to say that it's out of scope. I certainly agree that it's underspecified at the moment, which probably worse than saying nothing. > 3.5.4.4: > QUERY re: > The relayed discovery message MUST have the same Session ID as the > incoming discovery message and MUST be tagged with the IP address of > its original initiator (see Section 3.8.4). > > I thought we were adding something about Link Local addresses here? What was the point there? (Clearly, discovered link-local addresses MUST NOT be sent on to another interface, is that it? But that affects the Discovery Response process, not the relay process. Must check my code, too...) > 3.5.5: > re: > The details, including the > distinction between dry run and an actual configuration change, will > be defined separately for each type of negotiation objective. > > I would very much like it if dry-run/real-run request was standardized. > This would make external auditing/debugging (such as via network sniffer) > much easier to see. Hmm. That needs some thought. I thought that the semantics of this was very hard to capture in a generic way. (One way would be to add a new flag value, so that an objective could be labelled F_NEG for negotiation and F_NEG_DRY for dry-run negotiation. That has a great advantage - it could be retrofitted any time, and can be rejected with an M_INVALID by a node without dry-run capability.) > 3.8.6, about: > >> If a node receives a Request message for an objective for which no >> ASA is currently listening, it MUST immediately close the relevant >> socket to indicate this to the initiator. > > if the time sequence is: > initiator ----M_DISCOVERY---> responder (GRASP core) (UDP) > ...> pass details to ASA > initiator<----M_RESPONSE----- ASA (TCP) > initiator-----M_REQ_NEG-----> ASA (same socket) > > then, according to above, why would an ASA have responded in the first > place if not be the right ASA? This covers the case where the ASA crashes at the critical moment - without this provision (depending on implementation details) the socket would be left hanging. Also consider that discovery results can be cached, so there might be a real time gap between the M_RESPONSE and the M_REQ_NEG, giving more chance that the ASA crashes or even exits cleanly. > 3.8.11: > I think that the "initiator" option is just an IP address. > No port number or protocol (UDP/TCP), right? Correct, as currently specified. It's only there to disambiguate the session ID in the minute chance of an ID collision. > Can we please have an example for M_FLOOD? > > Is this valid: > > [M_FLOOD, 124567, fe80::1234, 27, > [[O_IPv6_LOCATOR, fe80::1234, IPPROTO_UDP, 500]], > ["ACP", flags, 1, ["bootstrap-okay"]] I think so, but I'll need to run it through my primitive validation chain... > Could an O_DIVERT occur in an M_FLOOD? Not in the current syntax, and I'm not sure why we'd need it. > Can we have more than one locator option? No. That is a feature - if you embed multiple objectives in a single M_FLOOD, they are all associated with the same locator option. If that's a problem, now would be a good time to say so ;-). Regards Brian On 24/11/2016 11:47, Michael Richardson wrote: > > I'm sorry for the wide-ranging comments here; I started on Sunday on the > airplane, but didn't finish until today. We talked M_FLOOD yesterday at the > bootstrap call, and we will edit to synchronize with my comments here. > > Chairs: Are we using the issue tracker? It's not in the menu at: > https://tools.ietf.org/wg/anima/ > > If not, where did the issue # that Brian and co. used to track my previous > comments? Oh, it's just numbers in the issues part of the document... > > I went through my previous comments which are at: > https://www.ietf.org/mail-archive/web/anima/current/msg02148.html > > I think that sections 3.3 and 3.4 are a response to my request for > an operating overview, and I think that this works well. > > I asked for examples, and they are in Appendix D, but while reading the > document, I had forgot about it, and nothing told me to go look there in the > text. A see D.1 would be good. > Could I ask for small change: > > from: The initiator multicasts a discovery message: > to: The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a discovery message: > > [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 2, 2, 0]] > > and ditto for "A peer (X) responds", as it took me a minute or two to figure > out what this third argument was, that it was the initiator address. > > > Now to comments on the -08 text... > > 2.1 --- does this belong in GRASP, vs reference model document? > Would like MB and Toerless to confirm that it is consistent in wording > with reference model document! > >> D8. The discovery process must not generate excessive traffic and >> must take account of sleeping nodes in the case of a constrained-node >> network [RFC7228]. > > I think this actually out of charter, and furthermore, GRASP doesn't do a > very good job of taking this into account. I think it should be striked out. > > SN7. > orig: o Dependencies and conflicts: In order to decide a configuration on > a given device, the device may need information from neighbors. > > orig: o Dependencies and conflicts: In order to decide upon a configuration > for a given device, the device may need information from neighbors. > > >> be as automatic as possible. The protocol's role is limited to >> the ability to handle discovery, synchronization and negotiation >> at any time, in case an ASA detects an anomaly such as a >> negotiation counterpart failing. > > I think this sentence could use some work. Maybe: > The protocol's role is limited to discovery, synchronization and > negotiation. This process can occur at any time, and an ASA may > need to repeat any of these steps when the ASA detects an anomaly > such as a negotiation counterpart failing. > > 3.1. terminology > > was: > Discovery, Negotiation and Synchronization. In the protocol, an > objective is represented by an identifier and if relevant a value. > > new: > Discovery, Negotiation and Synchronization. In the protocol, an > objective is represented by an identifier and -- if relevant -- a value. > > (or maybe two comma are more correct) > > There is too much functional description in the XYZ Objective descriptions. > At least, it needs to have a forward reference. > > going on, remove *cut*/*tuc* > > o Discovery Responder: a peer that either contains an ASA supporting > the discovery objective indicated by the discovery initiator, or > caches the locator(s) of the ASA(s) supporting the objective. *cut*The > locator(s) are indicated in a Discovery Response, which is > normally sent by the protocol kernel, as described later.*tuc* > > 3.2: > >Interface (API) will be needed between GRASP and the ASAs. In some > >implementations, ASAs would run in user space with a GRASP library > >providing the API, and this library would in turn communicate via > >system calls with core GRASP functions running in kernel mode. For > > I still don't know why "kernel mode" is used here. Certainly on Linux and > Windows, we don't need code in the "kernel", just a priviledged process if > we are allocated a <1024 port, otherwise, just an unprivledged system daemon. > > On a Cisco/Huawei/Broacade router, I don't know a lot about OS architecture, but on > Juniper a straight FreeBSD process would work fine. > "operating system core module" (section 3.4) is much better. > I think I mentioned "kernel" issue before. > > The reference to RFC2608 seems unwaranteed on page 13. > > section 3.3 was good to write down, but seems like it is too much like a discussion. > I would like the bullets as subsections, as they are really modes of > operation! > > 3.4 should mention M_FLOOD along with M_DISCOVERY. > or, perhaps the M_FLOOD mechanism can be clearly labelled as providing > awareness of an ASA. > > I appreciate 3.5.1 trying to establish some security via (D)TLS, but it > simply doesn't say enough to result in interoperability. (for instance, > should certificates be validated? If so, what should be in the CN? Do we need > PFS? When do we rekey? Are client-side certificates important? Is there a > link between IP addresses and something in the CN?) > > I'd prefer that all the mention of TLS be removed to another document that > would specify it more completely, a document titled something like: > "Using GRASP between service providers" > or: "Securing GRASP using TLS" > or: "CoAP/DTLS mode for GRASP" > > > I'd like 3.5.2 point (1) be numbered 3.5.2.1 so it can be better referenced, > and I'd like it say something like: > > 3.5.2.1 Inter-domain GRASP Instance > As mentioned in Section 3.3, some GRASP operations might be performed > across an administrative domain boundary by mutual agreement. > Such operations MUST be confined to a separate instance of GRASP with its > own copy of all GRASP data structures. Details of this mode are the > subject of a future document that would clearly detail the security > limitations of such an instance. > > 3.5.2.2 Bootstrap and ACP GRASP Instance (DULL) > > This instance is nicknamed DULL - Discovery Unsolicited Link Local. > > The bootstrap process uses only M_FLOOD messages to announce the location > of the bootstrap proxy. This message is used only on-link using > link-local multicast, on the underlying (insecure) media. > > Full ANIMA nodes that act are willing to act as bootstrap proxies will > include a flag indicating this into this message. Full ANIMA nodes > looking for ACP peers will also indicate that in the message. > > Full ANIMA nodes MAY listen for M_FLOOD messages on insecure interfaces. > Other messages MUST be discarded. M_FLOOD messages which are improperly > formatted such as: > > o having a loop count > 1 > o having a GRASP message type != M_FLOOD > o having a non-link-local source address > > MUST be discarded. It is acceptable for the M_FLOOD to be to the > ALL_GRASP_NEIGHBOR multicast address, or to be unicast to the host in > question. > > ANIMA nodes in bootstrap mode listen on the ALL_GRASP_NEIGHBOR multicast > address, and listen according to the same rules above, but examine the > BOOTSTRAP_PROXY attribute only. > > Details of DULL are included in: [I-D.ietf-anima-autonomic-control-plane] > > > I want to suggest that point (3), about ACP formation be dropped, as it is > included in part 2. > > In 3.5.3, please delete: > > In particular, > to guarantee interoperability during bootstrap and startup, using TCP > for discovery responses is strongly advised. > > I don't think it makes any sense at this point. > Bootstrap discovery will use M_FLOOD, while actual bootstrap uses either EST > (RFC7030) which is HTTP/TCP, or possibly one of the EST over CoAP proposal(s) > [yes, currently plural, alas] > > Again, please omit further discussion of TLS. > > In section 3.5.4.1, can we write: > > The discovery (M_DISCOVERY) action will normally be followed by a > negotiation (M_REQ_NEG) or > synchronization (M_REQ_SYN) action. The discovery results could be utilized by > the negotiation protocol to decide which ASA the initiator will > negotiate with. > > 3.5.4.2: > > A complete discovery process will start with a multicast (of M_DISCOVERY) > on the local > link. On-link neighbors supporting the discovery objective will > respond directly (with M_DISCOVERY). A neighbor with multiple interfaces > SHOULD respond with a cached discovery response if it was learnt from > another interface. > > ADD: > A neighbor SHOULD NOT respond with a cached response on an interface > if it learnt that information from the same interface. > > 3.5.4.3: > s/GRASP kernel/GRASP core/ > > > 3.5.4.4: > QUERY re: > The relayed discovery message MUST have the same Session ID as the > incoming discovery message and MUST be tagged with the IP address of > its original initiator (see Section 3.8.4). > > I thought we were adding something about Link Local addresses here? > > 3.5.5: > re: > The details, including the > distinction between dry run and an actual configuration change, will > be defined separately for each type of negotiation objective. > > I would very much like it if dry-run/real-run request was standardized. > This would make external auditing/debugging (such as via network sniffer) > much easier to see. > > Can we change this paragraph to include message types? > > If the counterpart can immediately apply the requested configuration, > it will give an immediate positive (accept) answer (using M_END). This > will end the negotiation phase immediately. Otherwise, it will negotiate > (using M_NEGOTIATE) > It will reply with a proposed alternative configuration that it can > apply (typically, a configuration that uses fewer resources than > requested by the negotiation initiator). This will start a bi- > directional negotiation (using M_NEGOTIATE) to reach a compromise between > the two ASAs. > > ... > a peer to insert latency in a negotiation process if necessary > (Section 3.8.9, M_WAIT). > > 3.5.5.1: > change: > A Discovery message MAY include a Negotiation Objective option. In > this case the Discovery message also acts as a Request Negotiation > message to indicate to the Discovery Responder that it could directly > reply to the Discovery Initiator with a Negotiation message for rapid > processing, if it could act as the corresponding negotiation > counterpart. However, the indication is only advisory not > prescriptive. > > to: > A Discovery message MAY include a Negotiation Objective option. In > this case it is as if the initiator sent the sequence M_DISCOVERY, > followed by M_REQ_NEG. This has implications for the construction of > the GRASP core, as it must carefully pass the contents of the Negotiation > Objective option to the ASA so that it may evaluate the objective directly. > > When a Negotiation Objective option is present the ASA replies with an > M_NEGOTIATE message (or M_END if it is immediately satisfied with the > proposal), rather than with an M_RESPONSE. > > 3.5.6.1: > s/GRASP kernel/GRASP core/ > > Please add, after para 4, ("..with multiple link-layer.."): > > Link-Layer Flooding is supported by GRASP by setting the loop count to > 1, and sending with a link-layer source address. Floods with link-layer > source addresses and a loop count larger than 1 are not supported, and > such messages MUST be discarded. > > My comments about section 3.5.5.1 would seem to apply to 3.5.6.2 as well. > > 3.8.3: > please add: > The CBOR parser used by GRASP should be configured to know about > the GRASP_DEF_MAX_SIZE so that it may defend against overly long > messages. > > 3.8.4: > > Exceptionally, a Discovery message MAY be sent unicast to a peer > node (via UDP or TCP), which will then proceed exactly as if the message > had been multicast, except that when TCP is used, the response will be > on the same socket as the query. > > 3.8.6, about: > >> If a node receives a Request message for an objective for which no >> ASA is currently listening, it MUST immediately close the relevant >> socket to indicate this to the initiator. > > if the time sequence is: > initiator ----M_DISCOVERY---> responder (GRASP core) (UDP) > ...> pass details to ASA > initiator<----M_RESPONSE----- ASA (TCP) > initiator-----M_REQ_NEG-----> ASA (same socket) > > then, according to above, why would an ASA have responded in the first > place if not be the right ASA? > > 3.8.11: > I think that the "initiator" option is just an IP address. > No port number or protocol (UDP/TCP), right? > > Can we please have an example for M_FLOOD? > > Is this valid: > > [M_FLOOD, 124567, fe80::1234, 27, > [[O_IPv6_LOCATOR, fe80::1234, IPPROTO_UDP, 500]], > ["ACP", flags, 1, ["bootstrap-okay"]] > > Could an O_DIVERT occur in an M_FLOOD? > Can we have more than one locator option? > > > > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Nov 24 12:37:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DE3129C51 for ; Thu, 24 Nov 2016 12:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, 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 xAhH1ZS210aF for ; Thu, 24 Nov 2016 12:37:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC942129CC0 for ; Thu, 24 Nov 2016 12:37:28 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4AF14203B8; Thu, 24 Nov 2016 15:54:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 24E39637A6; Thu, 24 Nov 2016 15:37:27 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: References: <4565.1479941260@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] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 24 Nov 2016 20:37:33 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Thanks Michael, we will wait a few more days before rolling up all > comments received. I am fine with most of your suggestions. A few > things caught my eye: Cool. >> 3.5.4.4: QUERY re: The relayed discovery message MUST have the same >> Session ID as the incoming discovery message and MUST be tagged with >> the IP address of its original initiator (see Section 3.8.4). >> >> I thought we were adding something about Link Local addresses here? > What was the point there? (Clearly, discovered link-local addresses > MUST NOT be sent on to another interface, is that it? But that affects > the Discovery Response process, not the relay process. Must check my > code, too...) I think that's the point. Should we even relay discovery messages from LL origins? >> 3.5.5: re: The details, including the distinction between dry run and >> an actual configuration change, will be defined separately for each >> type of negotiation objective. >> >> I would very much like it if dry-run/real-run request was >> standardized. This would make external auditing/debugging (such as >> via network sniffer) much easier to see. > Hmm. That needs some thought. I thought that the semantics of this was > very hard to capture in a generic way. > (One way would be to add a new flag value, so that an objective could > be labelled F_NEG for negotiation and F_NEG_DRY for dry-run > negotiation. That has a great advantage - it could be retrofitted any > time, and can be rejected with an M_INVALID by a node without dry-run > capability.) I very much like this. >> 3.8.6, about: >> >>> If a node receives a Request message for an objective for which no >>> ASA is currently listening, it MUST immediately close the relevant >>> socket to indicate this to the initiator. >> >> if the time sequence is: initiator ----M_DISCOVERY---> responder >> (GRASP core) (UDP) ...> pass details to ASA >> initiator<----M_RESPONSE----- ASA (TCP) initiator-----M_REQ_NEG-----> ASA (same socket) >> >> then, according to above, why would an ASA have responded in the first >> place if not be the right ASA? > This covers the case where the ASA crashes at the critical moment - > without this provision (depending on implementation details) the socket > would be left hanging. Also consider that discovery results can be > cached, so there might be a real time gap between the M_RESPONSE and > the M_REQ_NEG, giving more chance that the ASA crashes or even exits > cleanly. So, are you saying that on some systems that the ASA could crash without closing the socket that is opened for the M_RESPONSE? >> Can we please have an example for M_FLOOD? >> >> Is this valid: >> >> [M_FLOOD, 124567, fe80::1234, 27, [[O_IPv6_LOCATOR, fe80::1234, >> IPPROTO_UDP, 500]], ["ACP", flags, 1, ["bootstrap-okay"]] > I think so, but I'll need to run it through my primitive validation > chain... okay, I want to make sure that I understand it. >> Could an O_DIVERT occur in an M_FLOOD? > Not in the current syntax, and I'm not sure why we'd need it. I don't think we do, but I'm just asking random questions as to why not... >> Can we have more than one locator option? > No. That is a feature - if you embed multiple objectives in a single > M_FLOOD, they are all associated with the same locator option. If > that's a problem, now would be a good time to say so ;-). I think that we physically can, it's an object inside an array. Could we have an IPv4 and an IPv6 address? Or a UDP and a TCP locator, or...? I'm thinking about how to construct the ACP neighbour awareness M_FLOOD such that it can also carry the Proxy locator. I think it's probably not a problem, as the locator can be the Proxy locator, and the ACP is implicitely port-500 IKEv2, except that I'm reading the ACP document, and see that actually there are many options for ACP security, but I haven't gotten that far yet. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWDdPhICLcPvd0N1lAQJw2gf/a4Ng4kJ2CK/IR4Pc+zcg3YC0pYJF9bHv D0VWA1SQtby1DKrrRtAJ1VQZPmqU1IEF+S+PufQbf7fHqlcx4yJo+6mia/PNpu42 5iyXGwllTXO7E002Y2EHIrDMQ8Wu76AShKvE56l2ddRA+N0h8SZ3q2mi1JcvtQBX CaSlQPFvneJYZWajLM13mZvNdjufoBm+bibeeHqZfr6kST72NyHBnT+wToe6Fb8P W1yX/9sqKKbwZnGV/GaLaGrFBgnH0eYWxrtN0roR9eiOyuNxHLT8OPhaGoM5VWz9 O2PMrOguHcEOg+JZy4Ke7zXTvottzctR/UlMGo66vVKlai7ujBMmqg== =HX15 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 24 13:35:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E96129D6B for ; Thu, 24 Nov 2016 13:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 kGKINLgAYXt5 for ; Thu, 24 Nov 2016 13:35:19 -0800 (PST) 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 92184129D66 for ; Thu, 24 Nov 2016 13:35:19 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id f188so21851591pgc.3 for ; Thu, 24 Nov 2016 13:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9uIoau2of2bLFhwSuPo1oNXub13UixPHrQYXV75biOM=; b=zCrh3WVmTWyiI4jdG9w0+yKMEWQSyJmjHvix/zwcCfcN0cTB9IMiyDyh+bffBHWTrc OCEMi3My5Ov1hLwECUA/PL0oO/mIGzVr3OkpcqbzEUCzENoCaVVCSMi+GEXv+K60/mhZ JnTiXKmQ+thHk5JwJvVaFDQ46r270vNa3JeRVyS1++xdVQ57rUbYeWwtQJ5q9G5v/czK LgDRG/Aqx7f55R9JaZ4DVlbVad5ZGQTyV9gA5GZg6MiUyxmMTaRpduhr1ZFVfYZ8v313 HhU+Oo6cxF9tjoVAjX/FkOuVX1O5rLRxtAxXmyn6/1oPWxs+QGzDCBDdrddQQJqUhuen 6JEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9uIoau2of2bLFhwSuPo1oNXub13UixPHrQYXV75biOM=; b=OmeG8CmsOJ/ZUhAPAgW6fAsGfs9RuaFzt63z6LMYr/d2hVlA6H/PhNPB8jhjTueV3P wUMXRK5mmSmkNzrzV4yBZQ/A7YdEyedMGPHC/Tpr8ZGk3rwNj52W8PESM/tj4EyH7elp cFyyykj7TwJtpAgkx/CRinbqeYa4zukCXXtTIThYl/hOtjqX47VYKu6cGvvv2Q4e4TeF gEgZ493iw/uY9O0fV+6kIfnCa3hEJMzV8cjYO9PfzmQLecdfM8Aw3oJWtU2X2MHlMiyS bTVU0hUKTJiulPel8O+F8IiHjmoxPawoczvJodF1fC0vNBXtHZS/8glgDtjxwq5bM+dR OULQ== X-Gm-Message-State: AKaTC02dsp2TsqOavbrg3e3dd2CUCiFkYbWIlqXL27BGzAqr4XPtG+zVsyWVaciglGgLqA== X-Received: by 10.99.168.10 with SMTP id o10mr7853848pgf.105.1480023318862; Thu, 24 Nov 2016 13:35:18 -0800 (PST) Received: from [192.168.178.23] (133.22.255.123.dynamic.snap.net.nz. [123.255.22.133]) by smtp.gmail.com with ESMTPSA id w5sm62504010pfl.31.2016.11.24.13.35.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 13:35:18 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <4565.1479941260@obiwan.sandelman.ca> <10713.1480019847@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 25 Nov 2016 10:35:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <10713.1480019847@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 24 Nov 2016 21:35:21 -0000 Comments in line.. On 25/11/2016 09:37, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Thanks Michael, we will wait a few more days before rolling up all > > comments received. I am fine with most of your suggestions. A few > > things caught my eye: > > Cool. > > >> 3.5.4.4: QUERY re: The relayed discovery message MUST have the same > >> Session ID as the incoming discovery message and MUST be tagged with > >> the IP address of its original initiator (see Section 3.8.4). > >> > >> I thought we were adding something about Link Local addresses here? > > > What was the point there? (Clearly, discovered link-local addresses > > MUST NOT be sent on to another interface, is that it? But that affects > > the Discovery Response process, not the relay process. Must check my > > code, too...) > > I think that's the point. Should we even relay discovery messages from LL > origins? No. I definitely need to check this and add some words. > > >> 3.5.5: re: The details, including the distinction between dry run and > >> an actual configuration change, will be defined separately for each > >> type of negotiation objective. > >> > >> I would very much like it if dry-run/real-run request was > >> standardized. This would make external auditing/debugging (such as > >> via network sniffer) much easier to see. > > > Hmm. That needs some thought. I thought that the semantics of this was > > very hard to capture in a generic way. > > > (One way would be to add a new flag value, so that an objective could > > be labelled F_NEG for negotiation and F_NEG_DRY for dry-run > > negotiation. That has a great advantage - it could be retrofitted any > > time, and can be rejected with an M_INVALID by a node without dry-run > > capability.) > > I very much like this. It's low cost to add to the spec, and harmless if not used. I also think I like it, but what do other people think? > > >> 3.8.6, about: > >> > >>> If a node receives a Request message for an objective for which no > >>> ASA is currently listening, it MUST immediately close the relevant > >>> socket to indicate this to the initiator. > >> > >> if the time sequence is: initiator ----M_DISCOVERY---> responder > >> (GRASP core) (UDP) > ...> pass details to ASA > >> initiator<----M_RESPONSE----- ASA (TCP) > initiator-----M_REQ_NEG-----> ASA (same socket) > >> > >> then, according to above, why would an ASA have responded in the first > >> place if not be the right ASA? > > > This covers the case where the ASA crashes at the critical moment - > > without this provision (depending on implementation details) the socket > > would be left hanging. Also consider that discovery results can be > > cached, so there might be a real time gap between the M_RESPONSE and > > the M_REQ_NEG, giving more chance that the ASA crashes or even exits > > cleanly. > > So, are you saying that on some systems that the ASA could crash without > closing the socket that is opened for the M_RESPONSE? Yes - if the the actual listen() and accept() are in a separate thread started by the GRASP engine, whereas the listen_negotiate() call is in a thread started by the ASA. (I have a lot of threads and queues in my prototype, because Python makes this extremely easy...) > >> Can we please have an example for M_FLOOD? > >> > >> Is this valid: > >> > >> [M_FLOOD, 124567, fe80::1234, 27, [[O_IPv6_LOCATOR, fe80::1234, > >> IPPROTO_UDP, 500]], ["ACP", flags, 1, ["bootstrap-okay"]] > > > I think so, but I'll need to run it through my primitive validation > > chain... > > okay, I want to make sure that I understand it. > > >> Could an O_DIVERT occur in an M_FLOOD? > > > Not in the current syntax, and I'm not sure why we'd need it. > > I don't think we do, but I'm just asking random questions as to why not... > > >> Can we have more than one locator option? > > > No. That is a feature - if you embed multiple objectives in a single > > M_FLOOD, they are all associated with the same locator option. If > > that's a problem, now would be a good time to say so ;-). > > I think that we physically can, it's an object inside an array. > Could we have an IPv4 and an IPv6 address? Or a UDP and a TCP locator, or...? > > I'm thinking about how to construct the ACP neighbour awareness M_FLOOD such > that it can also carry the Proxy locator. I think it's probably not a > problem, as the locator can be the Proxy locator, and the ACP is implicitely > port-500 IKEv2, except that I'm reading the ACP document, and see that > actually there are many options for ACP security, but I haven't gotten that > far yet. Right. But to be very clear, at the moment the M_FLOOD syntax is flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option / []), +objective] but to associate a locator with each objective it would need to be flood-message = [M_FLOOD, session-id, initiator, ttl, +[(locator-option / []), objective]] That would be more powerful for the case you describe. Since the locator option could be a URI, it would suit EST quite well, wouldn't it? Rgds Brian From nobody Thu Nov 24 21:30:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3CC12943A for ; Thu, 24 Nov 2016 21:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 b67GizoSAAJD for ; Thu, 24 Nov 2016 21:30:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB2E129418 for ; Thu, 24 Nov 2016 21:30:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B28452054A; Fri, 25 Nov 2016 00:46:49 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5EEAC637A6; Fri, 25 Nov 2016 00:30:05 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <4565.1479941260@obiwan.sandelman.ca> <10713.1480019847@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: Cc: anima@ietf.org Subject: Re: [Anima] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 05:30:11 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Right. But to be very clear, at the moment the M_FLOOD syntax is > flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option > / []), +objective] > but to associate a locator with each objective it would need to be > flood-message = [M_FLOOD, session-id, initiator, ttl, > +[(locator-option / []), objective]] > That would be more powerful for the case you describe. Since the > locator option could be a URI, it would suit EST quite well, wouldn't > it? yes-ish, but really, the proxy is in charge of where the Registrar is. In a pure-ANIMA scenario, we don't use an EST URI. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWDfMWoCLcPvd0N1lAQIg/Qf/Q63I8URy5ESUqVLgSPGHNlQRS3YWhSf/ FlkAQ7IJcatt+AOR3GcFj8455iLXegT0xwJ4FVwAvzOd0hEaw/1Yc66mQEaJ66/1 Cw1GfHYP79AQ9eK6wsSvFb3EnjMA7nD5j0DitlFDzQtb+ioZHgSuQAIPwyM/5JFe 1GocAqtYk2ZxngZMUoXq32gln38R86b1v6Ktsf3n6vrAZYsBkbWHLPPBMhaOo+Hj TcK23UbHXX1ia6ipIccSSAmK1VyDXiwXupXAOrofRVftM883dQGimL3MJAxxwVrQ dc1AxxdDLKHYUqgwLFH6n5sSzbXropcvhDTpActq2z955FazTicQ+A== =EblO -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 25 11:12:09 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0511295E5 for ; Fri, 25 Nov 2016 11:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OgaEeB9DoJX for ; Fri, 25 Nov 2016 11:12:07 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C031294A8 for ; Fri, 25 Nov 2016 11:12:07 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id x23so32209976pgx.1 for ; Fri, 25 Nov 2016 11:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2JFZ0K0JPTs4Zyu6YkoSM/MDqyOiRpTsu6Baj9//RcA=; b=YCYcClnbN5PQoezlvSTIumgzPiK4EIzTTlZjTbWYeJMGAMT/bdn0Q1X24bRREsMry2 MSZvMvN0ldpfPDIbfLfQCTm+/nn7C0+swWZAyYVlys2GFR0pNr0wnfdZIcJ+Rmg1vNU0 dmuaBgO7/OCHkWOI4MP1BqWiGhBZfOK3fCWW7EPUdD/Me+LU6kk8YaoKZHE0NnoThqYp i+tcNtXfdH3dLnxoO5pIboRKQ8ZO1aiu25cicq/qLxb9EIc9KVglmkvaokW4WQD+vlxW FFpYWZRlm8YeClr+ovcdG/QzSP2sJkFj6fgRGYI2JUsdxq43lJDuA1Pk+V6S37ajvUFN CfEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=2JFZ0K0JPTs4Zyu6YkoSM/MDqyOiRpTsu6Baj9//RcA=; b=D0fOF+IkatrXd44o9meBqXyxbYp8Ye3zWBE8HWEG4iw2x+pBVletzg68HCCvyNiAdi wyh6hGC9M3dkCvuPb14QCZmXAuFQ30/Xxa34xvUXdPxblXb9GIe7J70vh61E7BQLOHpo ZAlIaLXRbYdy5A6nLdEPNw3u9uitb2r1/rUb0f/leEk/gssuubWl5r+xm0pZQ+ZZT61i Dr3F0lDhRz2TcgQfQXhT1V/tq4jgkWKiOn8pIJrwSgTaqYNsAEU48y449BVGw/8zOwBV x9il+fYcLunepczQAkzK6J1O6Pyrle7p6qfK13VwTyw7PThCtsvWueskigF+TVBWCQQZ k2SQ== X-Gm-Message-State: AKaTC012tn6DQ7GDgYRqR6OfrEy/8w4unl/2+BHlQSxLwNydZ9M1pqtrkwvCYM1cgZ97WQ== X-Received: by 10.84.142.70 with SMTP id 64mr19231469plw.177.1480101126379; Fri, 25 Nov 2016 11:12:06 -0800 (PST) Received: from ?IPv6:2406:e007:7832:1:28cc:dc4c:9703:6781? ([2406:e007:7832:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k25sm14997948pfg.84.2016.11.25.11.12.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Nov 2016 11:12:05 -0800 (PST) To: Michael Richardson References: <4565.1479941260@obiwan.sandelman.ca> <10713.1480019847@obiwan.sandelman.ca> <3899.1480051805@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 26 Nov 2016 08:12:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <3899.1480051805@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 19:12:08 -0000 On 25/11/2016 18:30, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Right. But to be very clear, at the moment the M_FLOOD syntax is > > > flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option > > / []), +objective] > > > but to associate a locator with each objective it would need to be > > > flood-message = [M_FLOOD, session-id, initiator, ttl, > > +[(locator-option / []), objective]] > > > That would be more powerful for the case you describe. Since the > > locator option could be a URI, it would suit EST quite well, wouldn't > > it? > > yes-ish, but really, the proxy is in charge of where the Registrar is. > In a pure-ANIMA scenario, we don't use an EST URI. > Ack. In any case, do you think we should make this change? It's now or never. Brian From nobody Sat Nov 26 18:51:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C2E1293E0 for ; Sat, 26 Nov 2016 18:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 wspU8k9tTd4T for ; Sat, 26 Nov 2016 18:51:35 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 91DFD126CD8 for ; Sat, 26 Nov 2016 18:51:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CDC3200A3; Sat, 26 Nov 2016 22:08:25 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EFD7463B09; Sat, 26 Nov 2016 21:44:20 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <4565.1479941260@obiwan.sandelman.ca> <10713.1480019847@obiwan.sandelman.ca> <3899.1480051805@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 Date: Sat, 26 Nov 2016 21:44:20 -0500 Message-ID: <10817.1480214660@obiwan.sandelman.ca> Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 02:51:37 -0000 Brian E Carpenter wrote: > On 25/11/2016 18:30, Michael Richardson wrote: >> >> Brian E Carpenter wrote: > Right. But to >> be very clear, at the moment the M_FLOOD syntax is >> >> > flood-message = [M_FLOOD, session-id, initiator, ttl, >> (locator-option > / []), +objective] >> >> > but to associate a locator with each objective it would need to be >> >> > flood-message = [M_FLOOD, session-id, initiator, ttl, > >> +[(locator-option / []), objective]] >> >> > That would be more powerful for the case you describe. Since the > >> locator option could be a URI, it would suit EST quite well, wouldn't >> > it? >> >> yes-ish, but really, the proxy is in charge of where the Registrar is. >> In a pure-ANIMA scenario, we don't use an EST URI. >> > Ack. In any case, do you think we should make this change? It's now or > never. I will propose something by Monday... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sun Nov 27 16:27:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD25129438 for ; Sun, 27 Nov 2016 16:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDXmQSPSggpR for ; Sun, 27 Nov 2016 16:27:32 -0800 (PST) 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 14EEF126579 for ; Sun, 27 Nov 2016 16:27:31 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id p66so50438880pga.2 for ; Sun, 27 Nov 2016 16:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VGWntVFfSaJ6W6Ceo4iVyWm53lHt/qmgOnePqCVs5E4=; b=jjyMdgzTOJ155lcDOGdYfbMERvPbEXesZx8aYdlgBu5atRNEmQPKAqjSNmKzjVj9SL q8wNils8+gVkPD+AD9CVQi5mOiTIsiqyUJ+3r/S6yqM5KlRp6zqGIorPCUB15+KVBo9E PW2jzye1C97jp0wgtPe0y6QxCjCdtzcmFtsT/gA9ZxHwQPO+pEVj6eSsSdp/uZg5F3dT vij2+B+ng3oqGOM8p+nvXcdA1NNAzyD1OtVvDyIOKNw8WpZibyyG5w9VqdJi502tnvmK 8Tq+Q1TsVeuYGy847Yr9IyUnJdaFjn+WMrHKYnIDoF+Id+e3RTdCog6jqPKr1tSYOFuy cpSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=VGWntVFfSaJ6W6Ceo4iVyWm53lHt/qmgOnePqCVs5E4=; b=Iyya2vX2RZMSrV4qea5ybUxHnzkvUqCLZREIWdfoCN1lEz9ahM5EHUiel5/kFZPCKH NEOlJ27AFTAlrdLS0u/GyYxPQNMA2SAhoc4CFgHmeghNZ9ldPCUgzE6pRXcfhvWXybUf CmdRBJO4DoA/4uGNl5Luud3FrMuas3tS57WJf7a9zEatm/TDCWsCFwV1sba5CqE2TJJ6 YO33Z3IaJFe5XUkMj+CL5ypS3LxHzvc0UZZGVdx1Y1y0AC+uwpKPObXP1sZ6rWAZugcW qkYEV0o2+iOQD7wkMi+OnGaBeXe7xsBFppaPX0v9Szk3LxwL5lOFtwWLn8HTLzEHOItP FqOQ== X-Gm-Message-State: AKaTC01T9kvlQMkC4XsMdhvZqNJbUX523QL7BJs0dCFbiX+juxCLmK07rZD2nuLBZvE4lQ== X-Received: by 10.84.206.37 with SMTP id f34mr43522221ple.127.1480292851194; Sun, 27 Nov 2016 16:27:31 -0800 (PST) Received: from [192.168.178.23] ([118.148.115.30]) by smtp.gmail.com with ESMTPSA id y200sm77358077pfb.16.2016.11.27.16.27.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Nov 2016 16:27:30 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <4565.1479941260@obiwan.sandelman.ca> <10713.1480019847@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <632839c1-f73c-db68-3fbe-7e9822b8c1d0@gmail.com> Date: Mon, 28 Nov 2016 13:27:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <10713.1480019847@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Discovered link-local addresses [was review of grasp-08] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 28 Nov 2016 00:27:33 -0000 On 25/11/2016 09:37, Michael Richardson wrote: ... > >> 3.5.4.4: QUERY re: The relayed discovery message MUST have the same > >> Session ID as the incoming discovery message and MUST be tagged with > >> the IP address of its original initiator (see Section 3.8.4). > >> > >> I thought we were adding something about Link Local addresses here? > > > What was the point there? (Clearly, discovered link-local addresses > > MUST NOT be sent on to another interface, is that it? But that affects > > the Discovery Response process, not the relay process. Must check my > > code, too...) > > I think that's the point. Should we even relay discovery messages from LL > origins? In fact, this point is covered in the formal spec of the Locator Option. I propose to augment it slightly thus: Note 1: The IPv6 address MUST normally have global scope. Exceptionally, during initialisation, a link-local address MAY be used for specific objectives only (). In this case the corresponding Discovery Response message MUST be sent via the interface to which the link-local address applies. Note 2: A link-local IPv6 address MUST NOT be used when this option is included in a Divert option. From nobody Sun Nov 27 16:46:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECCD129439 for ; Sun, 27 Nov 2016 16:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ2UmS9tHlvd for ; Sun, 27 Nov 2016 16:46:32 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E199412941C for ; Sun, 27 Nov 2016 16:46:31 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id 3so50599314pgd.0 for ; Sun, 27 Nov 2016 16:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=zA1AmmiZFKs1O6Xo0eoKJvrhK8eyA+QUcaThNNaBVq4=; b=KrdmABrZkOVj7sTIymyQ7I0CYsbBMcyAVIuHQeKf6bEefts7cR6rVrQRUHU3auwIKO smdyogU/XAOzjEqqSs6ex2vrfJZ8mbHDc59fjzxnC4CjanN9kLY4bJ6uwlrqaaam4yUW IVXyr0Aig8+UUQKh9umqN+RmrDBWnyoCHK4GdMsUQBQwJ54rDjXuXTssNB4BlC4wMFH5 3QgUR+GzK4cfKNN3KSVNaxbqYjgNv1fVvxAH3S6SGlbA1yaUTkmpc5+9qd6ZrXJ9zOeR xrvXYy7loYHVkNtMQXLH9LDXdEmcAL02C/BBEgyfQIO6gsrHCjMjj68I5kMdO+SrjNZq G2eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zA1AmmiZFKs1O6Xo0eoKJvrhK8eyA+QUcaThNNaBVq4=; b=D7FitUs6c/PQ5ddRCXB8dl70N8tmnz6Uy3ZjFQuYW4Ugu6b+BvvNdTOo1T02N6Ds2N 334pIArcQKSXWdMNUrzT8OK5Z8LRbotk1JCbNwnJhTWqUV9wjURk1LUj5aGXAyXVvfcg wxISqI6Q+C1EAHVEiT3N1XEO8CJh0AJxAB7y+Q4KBQwqXy4rmPpPZriAYwMaeg/eTF0O PVEaLoP1P4j0e54MyhNYnlXEtr9A/CPqPYPY9fVrahsufkdMPzv61Ylq7+ayq6g5CsAB /LDZC9hHR0PRdexhKkkEziCRD4664HxejWNkU8PHPOMRfN8inkftWCczN0kfXjNMh2VK UMpg== X-Gm-Message-State: AKaTC01vFlJC3Su1NB7LaNt0cy/Bq2YHzGTq595e4CFExTGtN9hTx3099Ykt6iLkkHKhqA== X-Received: by 10.99.111.78 with SMTP id k75mr35436030pgc.114.1480293991181; Sun, 27 Nov 2016 16:46:31 -0800 (PST) Received: from [192.168.178.23] ([118.148.115.30]) by smtp.gmail.com with ESMTPSA id y2sm82377138pff.82.2016.11.27.16.46.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Nov 2016 16:46:30 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <4565.1479941260@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5b9b549e-208c-87b6-d21f-3c9dd2919cc8@gmail.com> Date: Mon, 28 Nov 2016 13:46:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] example for M_FLOOD? [was review of grasp-08] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 28 Nov 2016 00:46:33 -0000 > Can we please have an example for M_FLOOD? Was there a problem with the one at https://tools.ietf.org/html/draft-ietf-anima-grasp-08#appendix-D.2 ? Brian From nobody Mon Nov 28 14:53:32 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D4612A07A for ; Mon, 28 Nov 2016 14:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chhb3CyJJcXu for ; Mon, 28 Nov 2016 14:53:29 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3803B12A0FC for ; Mon, 28 Nov 2016 14:50:54 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 3so61662991pgd.0 for ; Mon, 28 Nov 2016 14:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Z2w3rrG29EmprLhfT/L2YYR/28SNsVxKEq0MPZuMCys=; b=df9UFVJ1n2hYwQQskwj2UsH5I/QXnbZLBjHvQXKXo6rZJ5cesH+7Krj/9w9TCxduVX xi/MsCVhXm7Ax8ZUhBTGFyKKCPGrpKJ6swaeUxlEmM37MAFnHU7C+34v6PzvpRmiBVch Ilz1l7OAzw+onRdoDRsUoou9C52uguZfO43g0hGASJSPFtqtgchUGfDujdQyByf5dHEz 1vZm7tRg6RjoTx7pe7NFE4kFkEjowXEG8m20FUCNYsiol17dfXBkTCf6YOmoxBB7hh6j Uv12ipU5Z/igH7YKGaG3TGNxS3PBZkjk+TNhD7Svo2hVox4QqTEW5o1LZuwCVBDUpaXa 6zEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Z2w3rrG29EmprLhfT/L2YYR/28SNsVxKEq0MPZuMCys=; b=BKS9FP38bRe9fl6olZ7t7uSwvgBs15CtthsrX/Afs92VcVSBPW0hzwvtBAKP9KtNxj t0WHLA9EANsjV18Q8BsV04TC3yFwrxuuRp9j/t12VhAqHadNH8d/RIPcGmMxfsqCLKZX xOUn10GHGx3X42zKtR+XAmAzpbZNbrD/l8R0SAj6nw3U0DNpF3SKk/k11z6LFfoyFO3p CIvfH10pYK5rODHkAe7wNGnIQWxZWUq82akcmiMbwJO1lIUZ4FeiB3bW4L7AQZn8jttM 1h3IyJdae8l9UqIafbsd3iGiaZybyThr10GtJXBVYdHr2KbWX+eD/IpWFXRw8AY65sYL clYg== X-Gm-Message-State: AKaTC01Ht7rQy5QwuwDV1LSmvMR8uqY34cQIp1YQNkTLPBoFXLFx6hoEUBKohQ691o2IlQ== X-Received: by 10.99.114.2 with SMTP id n2mr44118003pgc.130.1480373453393; Mon, 28 Nov 2016 14:50:53 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id q14sm89612168pfa.40.2016.11.28.14.50.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 14:50:52 -0800 (PST) From: Brian E Carpenter To: Michael Richardson , anima@ietf.org References: <4565.1479941260@obiwan.sandelman.ca> Organization: University of Auckland Message-ID: <715763aa-678a-d6cc-6f59-3cfa6f5aad49@gmail.com> Date: Tue, 29 Nov 2016 11:50:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <4565.1479941260@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] review of grasp-08 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 28 Nov 2016 22:53:31 -0000 Replying on some details in Michael's review. Points that are omitted here are either obvious and will be fixed in the next version, or are already the subject of other threads: On 24/11/2016 11:47, Michael Richardson wrote: ... > 2.1 [Requirements for Discovery] --- does this belong in GRASP, vs reference model document? > Would like MB and Toerless to confirm that it is consistent in wording > with reference model document! It's lot more detailed than the reference model, and IMHO it is needed here to provide context for the actual design. As far as consistency goes, Bing and I are co-authors of the reference model so I guess it's our job to check. As far as I know there is no inconsistency. >> D8. The discovery process must not generate excessive traffic and >> must take account of sleeping nodes in the case of a constrained-node >> network [RFC7228]. > > I think this actually out of charter, and furthermore, GRASP doesn't do a > very good job of taking this into account. I think it should be striked out. Agreed for the 'constrained node' part. I think that traffic volume and sleeping nodes always apply. ... > section 3.3 was good to write down, but seems like it is too much like a discussion. We can try to tighten up the language. It seems like useful material, though/ > I would like the bullets as subsections, as they are really modes of > operation! Hmm. Other opinions? That would make a *lot* of small subsections. ... > I appreciate 3.5.1 trying to establish some security via (D)TLS, but it > simply doesn't say enough to result in interoperability. (for instance, > should certificates be validated? If so, what should be in the CN? Do we need > PFS? When do we rekey? Are client-side certificates important? Is there a > link between IP addresses and something in the CN?) > > I'd prefer that all the mention of TLS be removed to another document that > would specify it more completely, a document titled something like: > "Using GRASP between service providers" > or: "Securing GRASP using TLS" > or: "CoAP/DTLS mode for GRASP" > > > I'd like 3.5.2 point (1) be numbered 3.5.2.1 so it can be better referenced, > and I'd like it say something like: > > 3.5.2.1 Inter-domain GRASP Instance > As mentioned in Section 3.3, some GRASP operations might be performed > across an administrative domain boundary by mutual agreement. > Such operations MUST be confined to a separate instance of GRASP with its > own copy of all GRASP data structures. Details of this mode are the > subject of a future document that would clearly detail the security > limitations of such an instance. Hmm. I have a counter-proposal. I'm reluctant to drop all mention of TLS from the draft, because otherwise, who knows what people might do - so how about this (with other mentions of TLS removed): 3.5.2.1. No ACP As mentioned in Section 3.3, some GRASP operations might be performed across an administrative domain boundary by mutual agreement, without the benefit of an ACP. Such operations MUST be confined to a separate instance of GRASP with its own copy of all GRASP data structures. Messages MUST be authenticated and SHOULD be encrypted. TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure (PKI) [RFC5280] are RECOMMENDED for this purpose. Further details are out of scope for this document. > 3.5.2.2 Bootstrap and ACP GRASP Instance (DULL) > > This instance is nicknamed DULL - Discovery Unsolicited Link Local. > > The bootstrap process uses only M_FLOOD messages to announce the location > of the bootstrap proxy. This message is used only on-link using > link-local multicast, on the underlying (insecure) media. > > Full ANIMA nodes that act are willing to act as bootstrap proxies will > include a flag indicating this into this message. Full ANIMA nodes > looking for ACP peers will also indicate that in the message. > > Full ANIMA nodes MAY listen for M_FLOOD messages on insecure interfaces. > Other messages MUST be discarded. M_FLOOD messages which are improperly > formatted such as: > > o having a loop count > 1 > o having a GRASP message type != M_FLOOD > o having a non-link-local source address > > MUST be discarded. It is acceptable for the M_FLOOD to be to the > ALL_GRASP_NEIGHBOR multicast address, or to be unicast to the host in > question. > > ANIMA nodes in bootstrap mode listen on the ALL_GRASP_NEIGHBOR multicast > address, and listen according to the same rules above, but examine the > BOOTSTRAP_PROXY attribute only. > > Details of DULL are included in: [I-D.ietf-anima-autonomic-control-plane] I'm confused. I don't think we want any specifics about bootrap or ACP formation in this draft. What we need here is the rules of the game for the GRASP implementer, and I think the existing formulation (with the updates already suggested by Toerless) is more appropriate. How DULL is *used* belongs in the ACP draft, of course. Specifically, I don't think we should exclude discovery messages. I don't think it's wise to *use* them, but that choice belongs in the BRSKI and ACP drafts. And we definitely should not say anything about specific objectives in the GRASP draft - it needs to be completely agnostic about that. > > I want to suggest that point (3), about ACP formation be dropped, as it is > included in part 2. Well, that's an argument you need to have with Toerless. There are two key differences between DULL and SONN: 1. SONN says "with unicast messages secured by TLS" (and don't ask me where the PKI comes from, I only work here). 2. SONN says: Any type of GRASP message MAY be sent. ... > In section 3.5.4.1, can we write: > > The discovery (M_DISCOVERY) action will normally be followed by a > negotiation (M_REQ_NEG) or > synchronization (M_REQ_SYN) action. The discovery results could be utilized by > the negotiation protocol to decide which ASA the initiator will > negotiate with. > > 3.5.4.2: > > A complete discovery process will start with a multicast (of M_DISCOVERY) > on the local > link. On-link neighbors supporting the discovery objective will > respond directly (with M_DISCOVERY). A neighbor with multiple interfaces > SHOULD respond with a cached discovery response if it was learnt from > another interface. Question to the WG - do you like that idea (inserting the message mnemonics at various points)? It seems natural enough to me, because of course I use them in my code, but is it the right thing to do in an RFC? > > ADD: > A neighbor SHOULD NOT respond with a cached response on an interface > if it learnt that information from the same interface. That's a subtle point. If it does so, it will very likely generate redundant traffic. But if it doesn't do so, there might be cases of discovery failure. (Also, this is the wrong thing to say on an NBMA network, I think.) I propose to change it as Michael suggests, but I have a slight doubt. The SHOULD NOT leaves us some wiggle room. Thanks again for a very thorough review! Brian From nobody Mon Nov 28 17:17:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1966212A218 for ; Mon, 28 Nov 2016 17:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqhjbY1tx7Dp for ; Mon, 28 Nov 2016 17:17:22 -0800 (PST) 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 D9B2F129432 for ; Mon, 28 Nov 2016 17:17:21 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id p66so62898176pga.2 for ; Mon, 28 Nov 2016 17:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zEkFrLqGozblxUOMyQV1AxsYVPgaezJyajjg7FsUIig=; b=0wKz5g83FhtZ6qm2kcEVmYL2oLawNISnFIJqOl0SNN+mTWj5BKaM2UP9tAu/qjVhpE jkg/mwrvJeWTYaiMHyVE8pzsCYil9uslUJN+627jFDxTCJXuzgqT6b1IjcOX2O4Xg9Sq CajsttJj43R4cDl7KlECYb/C2gPZsOaz/51eozBc4ZPb6fQsMpdT9v1GxBCVZazk4V6R dulqSRZzST10dTeqaAmy17aDfiLVdvy2to//mQuGu8YMM8cTQfjhu4QQbpdByEq5o/QI l7/aGZPE4547EJomcap5oxXu+gkcgH7YHH67zRhd7eFCWqVI5Vyn4M3bzgWRCPJR5iOB 3b9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zEkFrLqGozblxUOMyQV1AxsYVPgaezJyajjg7FsUIig=; b=UTTW8Src83ePuDSzThemsbU/1MVHwSA24X56d8ogNQbjSzMYRx+234L5g+ocDR7C9i BAvJMUVFqrs4c8aDzAC7wzd0Mf7g+LkHJecr0D6ch6mbyZRWBYkubi+ngXeVXcgmQl91 20RnYD6YAPUCYgr/YxkA/g1C6X159Icg7TmAERCJsPPanN7uVNOQdRO0ugh0tYjBjyF3 3rhnN7fi903JLfBan3w6fn4mH1DJXfHciVBe0XCVMtdWbn3Kogq8Hg5HGrVvU/PwAR5N LjamV4ngxO4TQNZXnylE44Ri7PLpSJ2SEc9AKWrmTPculfmW86RImpDnVwMfurSig2Bb D5RA== X-Gm-Message-State: AKaTC005CnTPxawp9mPcogtJ2G/oM0NcicYy+3svxHSPtc8B+Dw7UzDatBmjRKuDCSimUg== X-Received: by 10.98.83.193 with SMTP id h184mr24706883pfb.175.1480382241229; Mon, 28 Nov 2016 17:17:21 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id f14sm90036780pfk.5.2016.11.28.17.17.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 17:17:20 -0800 (PST) To: Toerless Eckert References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <20161104003541.GE6498@faui40p.informatik.uni-erlangen.de> <20161104150250.GI6498@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7cb844d3-9f37-23a2-e630-5182ad0e89fd@gmail.com> Date: Tue, 29 Nov 2016 14:17:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161104150250.GI6498@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert , Anima WG , Michael Richardson Subject: [Anima] ACP interfaces (was: Use of GRSP in discovery) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 01:17:24 -0000 I put this aside just before the IETF: On 05/11/2016 04:02, Toerless Eckert wrote: > On Fri, Nov 04, 2016 at 08:33:43PM +1300, Brian E Carpenter wrote: >>> GRASP should have a separate socket for each interface >> >> How many interfaces do you mean? With no ACP, GRASP knows a reasonably >> small number of physical interfaces, and has to open a socket for each of >> the to send LL multicasts, and it has to listen for LL multicast from >> all of them, which as far as I know requires a separate socket that is bound >> to the relevant multicast address. > > If each physcial interface connects to one ACP neighbor, the number > of logical ACP interfaces would be the same as the number of physical > interfaces. If an interface is a LAN connecting to N ACP neighbors, > you would have N ACP virtual interfaces, one for each such neighbor. > In an implementation of ACP that i could imagine. Yes, that makes sense. > Of course, on a LAN with N ACP neighbors, those would be eg: routers > interconnected via a switch, so if that switch was autonomic itself, then > you should only see one ACP neighbor, the switch. That the point of the > discussion about GRASP instead of mDNS for ACP discovery, and of course, > on the switch, we'd need to figure out how to intercept the ACP messages > to make that work. > >> In addition it has to open unicast sockets as and when needed, which may >> be bound to any kind of address. (In the limited instances they will >> be restricted to link-local unicast, but that's a special case.) >> >> I am still missing enough detail about the interfaces and socket options >> that the ACP will provide to know how this will change when the ACP >> is there. If there are, e.g., 400 autonomic nodes in the ACP and my node >> has 4 physical interfaces, each of which has 10 link-local neighbors, >> how many interfaces will the ACP offer me? 4, 40, 400? > > Never 400. 4 if the L2 switches on the LANs are ACP capable, 40 > otherwise. Fair enough. 40 is a bit scary (the most my prototype has ever seen is 2, but actually the code should work with 40). I think we should RECOMMEND that the L2 switches support the ACP. > >>> - but use that >>> socket both for sending and receiving. No shared socket for reception. >> >> Why not? There's no problem identifying the source interface for a multicast, >> it comes right back in recvfrom() (at least on Windows or Linux). > > I probably should not have used "should" when i was recommending > a separate socket per interface but instead: > > -> To me the logic of dealing with multiple interfaces wold be most > easy if an implementation could have a separate socket for each > interface, physcial and ACP-channel (aka: per ACP neighbor). > With that approach, its clear at the socket level, which sockets > belong to which security domain, and you do not have to > enforce that via filtering when you receive messages. Not sure it's an issue, but certainly I don't see a problem in doing that - but again, better with 4 interfaces than 40. > Socket API is a lot of confusing complexity. I haven't played with LL > IP6 myself on linux, so i can only guess: > > - Lets assume you bind your socket to the LL IPv6 address of an interface > via what the API doc calls the "scope ID" (which really is a zone ID). Yes, Zone ID is the correct IPv6 terminology, but in any case it's much cleaner to use interface numbers IMHO. My code figures that out on both Windows and Linux, but they are quite different. In this area Winsock seems to be superior to POSIX, even when viewed through the Python library. > You should then be able to send/receive only from/to that interface. > - I am not sure what impact this has on multicast. I was hoping that you > could still do the setsockopt to add the GRASP LL IPv6 multicasr group, > and in that API call you'd equally indicate your LL IPv6 addr and > would then send and receive IPv6 LL multicast only on that interface. Yes, you must do IPV6_JOIN_GROUP for each interface separately, with the right mreq structure. If I can inflict more Python on you, this is how I join the group on all interfaces with the same socket (slightly simplified): for i in _ll_zone_ids: mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', i) mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) so it would be easy to do that with separate sockets. You'd need a thread per socket, however. With a single socket, you don't need that. > I have not tested this, so this is right now just conjecture. No, it's correct for both POSIX and Winsock. >>> GARSP only needs to figure out which interface is physcial and which >>> is ACP. On router-OSs, each interface would be assigned to a VRF, so >>> it's easy to enumerate the interfaces of eg: the ACP being one VRF. VRFs on Linux may turn out to be a dark art; a quick Google didn't help much. I didn't get much out of https://www.kernel.org/doc/Documentation/networking/vrf.txt >> >> I would assume that the adjacency table would provide that sort of clue. >> To make my code agnostic about Winsock vs POSIX, I just use the interface >> numbers, not the names, and they should be system-wide unique. > > Have to look at your code.. > >>> Right. But this is not a new ACP thing. Any existing IETF protocol >>> implementation that uses link-local addresses and runs on any type of >>> any form of physical or virtual interface needs some form of interface >>> representation at the API level to send/receive LL packets. Thats why >>> i am somewhat hesitant to add explanatory text for this to the ACP >>> draft. It's supposed to be implied by the IPv6 addressing model and >>> common practice in IETF documents that its not regurgitated too much. >> >> No, it doesn't need much text but it really isn't obvious at all from >> the ACP draft, I assure you. > > Can you propose text ? Not sure I can. But something along the lines of: The ACP will appear to its users as a VRF instance that supports various network interfaces which in turn support standard TCP/IP sockets. These sockets can support link-local or global-scope IPv6 addresses. Multicast support SHOULD be limited to link-local operations. The way in which a program using the ACP detects that the ACP is present and attaches itself to the VRF instance is implementation-dependent. IMHO you should also recommend an API for the detection/attachment and for accessing the adjacency table, but like the GRASP API that should be a separate document. Regards Brian > > Cheers > Toerless > >>>> If you want, I can point you the exact Python code that handles this >>>> in the prototype. >>> >>> Please do. Just not sure when i'll find time. >> >> Let me do that when I'm back from my short vacation. >> >> Rgds >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Nov 29 08:51:46 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573361293D8 for ; Tue, 29 Nov 2016 08:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, 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 bDS0c7d2z24f for ; Tue, 29 Nov 2016 08:51:43 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F7F1293FD for ; Tue, 29 Nov 2016 08:51:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 43D06200A7; Tue, 29 Nov 2016 12:08:42 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8D751637A6; Tue, 29 Nov 2016 11:51:42 -0500 (EST) From: Michael Richardson To: anima@ietf.org 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: Cc: Terry Manderson Subject: [Anima] ownership vouchers (and git repo) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 16:51:45 -0000 --=-=-= Content-Type: text/plain ANIMA Chairs, Terry, Do you think we have consensus that ownership vouchers belongs in ANIMA? That seemed to be the result after many discussions at IETF97. The feedback from NETCONF and 6tisch WG is that they don't seem to want it. At the anima-bootstrap design team meeting, we sorted out our github permissions and which text was going into which document, etc. and in the process it was pointed out that we didn't have all the repos into the same "organization", and so we created an "anima-wg" org. https://github.com/anima-wg Perhaps in-advance of actually asking the chairs about that, sorry. May we be forgiven? We also forked all the repos we knew about into that org. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWD2yG4CLcPvd0N1lAQK8RAf/Z0TNK1L2fURszWCr16Yc0Z+z8Sh4oFm5 VtL5aGHgL+bbN/n7hpKKGvNmrjieV0kQjqnz2uwlnnIaL88xrkP5euGUiI0qnQSj ACs5aPmnOskVmFZ3F8dp/EtXujiLciztXDy1wwCQnYn8XSWP+rMfHgtZmpjNcGwW ipNOveiQQPkGiDhy7tWrrHgAgdNDl8INVAcO9QC3bnmWt29S8pOsM8dZlSqp59DU 6n5x4/sQcE5wbAaotoksE+bgZe7tYwmvCd6NyADI7Aab5ddexSlvAJJ1LIRSowPZ guEx/v9qE+ae1p1ktMcB3EL+p4kFh/spM/r55xt3b5fvletXWDPJGA== =oaMP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 29 17:08:53 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841AD1295B9 for ; Tue, 29 Nov 2016 17:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 Wt0NTMct7g-N for ; Tue, 29 Nov 2016 17:08:49 -0800 (PST) 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 BBF5F129CFF for ; Tue, 29 Nov 2016 17:08:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWG67654; Wed, 30 Nov 2016 01:08:46 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 30 Nov 2016 01:08:45 +0000 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, 30 Nov 2016 09:08:41 +0800 From: Sheng Jiang To: Michael Richardson , "anima@ietf.org" , "mersue@gmail.com" Thread-Topic: [Anima] ownership vouchers (and git repo) Thread-Index: AQHSSmDornApu1Aj90+gSWCF0dP51qDwtgxQ Date: Wed, 30 Nov 2016 01:08:40 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC6E6BC@NKGEML515-MBX.china.huawei.com> References: <14156.1480438302@obiwan.sandelman.ca> In-Reply-To: <14156.1480438302@obiwan.sandelman.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.583E269E.010B, 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: 6c9d5be526a7fea6de7a5c31ed085f7f Archived-At: Cc: Terry Manderson Subject: Re: [Anima] ownership vouchers (and git repo) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 30 Nov 2016 01:08:51 -0000 Hi, Michael, The information I got from netconf looks conflict. It seems Kent and you th= ought Netconf did not want this work and it is not a right home for it. But= , Mehmet thought netconf was interested in this work and would like to have= it in netconf. Personally, I support this work and think it should be done= before or at least parallel with ANIMA bootstrap. I am fine to see it grow= up in either Netconf or ANIMA. Best regards, Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: Wednesday, November 30, 2016 12:52 AM > To: anima@ietf.org > Cc: Terry Manderson > Subject: [Anima] ownership vouchers (and git repo) >=20 >=20 > ANIMA Chairs, Terry, >=20 > Do you think we have consensus that ownership vouchers belongs in ANIMA? > That seemed to be the result after many discussions at IETF97. > The feedback from NETCONF and 6tisch WG is that they don't seem to want i= t. >=20 > At the anima-bootstrap design team meeting, we sorted out our github > permissions and which text was going into which document, etc. and in the > process it was pointed out that we didn't have all the repos into the sam= e > "organization", and so we created an "anima-wg" org. > https://github.com/anima-wg >=20 > Perhaps in-advance of actually asking the chairs about that, sorry. > May we be forgiven? We also forked all the repos we knew about into that > org. >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Nov 30 08:40:58 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF46C12998D for ; Wed, 30 Nov 2016 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 kfruUGqg-2Rf for ; Wed, 30 Nov 2016 08:40:49 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C351299B3 for ; Wed, 30 Nov 2016 08:22:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E4E9C200A7 for ; Wed, 30 Nov 2016 11:39:28 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CB6F0637A6 for ; Wed, 30 Nov 2016 11:22:25 -0500 (EST) From: Michael Richardson To: anima@ietf.org 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] review of autonomic-control-plane-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 30 Nov 2016 16:40:55 -0000 --=-=-= Content-Type: text/plain This is a review of: draft-ietf-anima-autonomic-control-plane-04. I will attempt to reply to parts of my review with more pertitent subject lines, because some substantive comments/discussion are embedded, or feel free to do that yourself. Sorry that it's 400 lines long, if you'd like, I can find an XML file and submit patches. section 1: s/access devices through console ports/ /access devices through console ports (craft ports)/ { cf: http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/intro-why.html There are many pages asking why the telco's call the console port the "Craft" port, and it seems to have something to do with providing access to the system to the "craftsmen personnel" to verify if the system they just installed was operational. } change: For example, GRASP [I-D.ietf-anima-grasp] can run inside the ACP. to: For example, GRASP [I-D.ietf-anima-grasp] can run securely inside the ACP. section 3, can we number the requirements like in GRASP-08, i.e: ACP1, ACP2, etc. I think that this is confusing: It may be necessary to have end-to-end connectivity in some cases, for example to provide an end-to-end security association for some protocols. This is possible, but then has a dependency on routable address space. I think that you mean to say that the ACP could run *OVER* some kind of global end-to-end connectivity, but that then it depends upon routable address space. But, as I read it, it suggests that some protocols *inside* the ACP might need end-to-end connectivity, and this would depend upon routable address space. (My take is that the purpose of the ACP is to provide end-to-end connectivity for protocols that run inside the ACP, and I think we all agree about that) section 4: "Intent can override this default policy." Instead of getting into what an Intent is, and confusing the security reviewers, since we don't define it, can we just instead say: "Unless overridden by some other policy, the default policy is: To all adjacent nodes in the same domain. " Can we number the steps in this section? Please turn the following three points into numbered paragraphs or points seperate from the previous "steps", since they are really notes: o Non-autonomic NMS systems or controllers have to be manually connected into the ACP. o Connecting over non-autonomic Layer-3 clouds initially requires a tunnel between autonomic nodes. o None of the above operations (except manual ones) is reflected in the configuration of the device. Your diagram is great. I have heard some say that they would want to enable the ACP on interfaces which were marked Admin Down, with maybe even some kind of auto-negotiate (or auto-guess based upon energy detection) of lambdas. Is it worth saying something in section 4 about this? 5.1: specific Unique Device Identifier (UDI) or IDevID certificate. (Note: the UDI used in this document is NOT the UUID specified in [RFC4122].) how about telling us what the UDI is, rather than what it isn't? Isn't this a Cisco internal term? Is this here to steer your colleagues correctly? (I don't object to it being there, I just want to make sure that it doesn't confuse others) ==== The domain certificate (LDevID) of an autonomic node MUST contain ANIMA specific information, specifically the domain name, and its ACP address with the zone-ID set to zero. This information MUST be encoded in the LDevID in the subjectAltName / rfc822Name field in the following way: anima.acp+@ An example: anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.com This puts some pretty clear and pretty strong requirements onto the Registrar, which I think belongs in the bootstrap document. We don't really have a place for this. I will start a new thread about this part. 5.1.2: please move this elsewhere, as the table has not yet been defined, and you are already making exceptions to it: Where the next autonomic device is not directly adjacent, the information in the adjacency table can be supplemented by configuration. For example, the node-ID and IP address could be configured. This also seems like an pre-mature optimization: The adjacency table MAY contain information about the validity and trust of the adjacent autonomic node's certificate. However, subsequent steps MUST always start with authenticating the peer. In diagram Figure 2, please change "ANrtrI" to another letter, because "I" and "1" are hard to distinguish. It's true that a full mesh of ACP channels will be built: we ideally need to create some metrix for RPL to use to pick parents. It would be desireable to be aware of the L2 fabric. You are, I think suggesting having the ANswitchX block forwarding of the ALL_GRASP_NEIGHBOR mcast group. I'm not sure I like this solution. One possible solution to the large number of channels is not to create the IPsec CHILD SA unless needed. This would be possible if the IKEv2 deamon was also the RPL routing daemon, and we did RPL over the IKEv2 layer. Also really sick layer violations :-) 5.2.2: Unfortunately, they [CDP? mDNS?] will also terminate their messages if they do not support the ACP and would then inhibit ACP neighbor discovery Can you explain this? I don't understand what you are saying from the text. Are you saying that an L2 switch that spoke LLDP, but didn't speak ACP would eat the LLDP rather than forward it, and in this case, we want to forward it. (A switch which didn't speak LLDP would just forward it) It's good to point out that LLDP is not forwarded, and that L2 switches already do this kind of thing when considering how to limit the ACP discovery. It seems like the point of 5.2.2 is to discuss why we can't use mDNS. Maybe we could split the CDP/LLDP section from the mDNS section. (Looks like just a section header would do that) 5.2.3: we need to define it more clearly in this document, and if we want to point elsewhere, we need to point to new anobjectives document. 5.2.4: I will write some text in coordination with the next update to BRSKY to point at M_FLOOD. XXX I feel it is important to combine the ACP discovery with the proxy discovery. Thanks for noticing richardson-anima-6join-discovery and pointing to it. I think that there will be some changes to this too. {so many documents, so little time} 5.3: This is interesting, you are suggesting that while many nodes may be part of the "example.com" domain, that the ACP would only be established among some subset of it. I can see how it might be important to connect CPE devices (with "*.access.example.com" certificates) a different ACP than the core routers (with "*.core.example.com") One way is to run two instances of GRASP, and enroll each instance seperately with different certificates. Another way might to give the access concentrators certificates with multiple CNs. A third way might be to create some kind of ACP proxy/tunnel mechanism that permitted the CPE devices to build ACP tunnels *through* the access concentrators, via the "core" ACP, to the access network infrastructure. I have another use for such a thing, which is providing ACP backhauls in multi-tenant data centers. I will start an entirely new thread on this. I suggest third paragraph, "Intent can change.." be written: This ACP document puts a requirement that Intents be able to change this default behaviour. The precise way in which this should be expressed needs to be defined outside this document. Example Intent policies which need to be supported include: 5.4: From the use-cases it is clear that not all type of autonomic devices can or need to connect directly to each other or are able to support or prefer all possible mechanisms. For example, code space limited IoT devices may only support dTLS (because that code exists already I claim that any "IoT" device that is "big enough" to participate meaningfully in the ACP is also big enough to support the common protocols other than DTLS. The ACP should be connected lighting controllers, not light bulbs. As for MacSEC vs IPsec, it is my understanding that MacSEC does have a key management protocol defined for it by the IEEE, so really the common situation is that one supports IKEv2 to negotiate if one supports IPsec or MacSEC. As for the two stage process, I don't want to do this. I want to just use IKEv2, and I claim that there will be no people who will say, "I can not live with this". (Of course, some may have other preferences, but preferences does not equal rough consensus) ...Alice must be able to simultaneously act as a responder in parallel for all of them - so that she can respond to any order in which Bob wants to prefer... it's this part that I think is too complex and error prone to code. 5.5.1: encryption. Further parameter options can be negotiated via IKEv2 or via GRASP/TLS. I think that the last sentence should be striked out, I think it is meaningless. IKEv2 negotiates everything, and there is no GRASP/TLS. 5.5.2: ACP via GRE/IPsec Given that you add GRE here, I don't understand 5.5.1. Do you mean to write that 5.5.1 is really IPsec(transport-mode) IPIP(94)? And 5.5.2 is really IPsec(transport-mode) GRE(47)? Note that without explicit negotiation (eg: via GRASP/TLS), this method is incompatible to direct ACP via IPsec, so it must only be used as an option during GRASP/TLS negotiation. That's not true. IKEv2 can negotiate this quite well. We may want to define some Notify messages to make it abundantly clear that this is an ACP negotiation going on, but that's easy. 5.5.3. ACP via dTLS So, it's UDP and then... ? GRE inside UDP? (there is a draft tsvwg-gre-in-udp-encap-19) When Alice and Bob successfully establish the GRASP/TSL session, they will initially negotiate the channel mechanism to use. Yeah, no. Tons of code with no benefit. Who is actually asking for these options? 5.5.5. ACP Security Profiles A baseline autonomic device MUST support IPsec and SHOULD support GRASP/TLS and dTLS. A constrained autonomic device MUST support dTLS. if we want to do something for constrained devices, then we should say that they always initiate, that they should join as RPL leafs (so no forwarding of packets), and that they the LWIG version of IKEv2 should be supported, and maybe the diet-ESP mechanisms. We should also be clear if we are trying to support constrained devices, constrained networks, or challenged networks. 5.7: to: If possible by the platform SW architecture, separation options that minimize shared components are preferred. add: ..such as a logical container (reference to Linux container), or virtual machine instance (reference to KVM and also to the Cisco router VM platform) o Usage: Autonomic addresses are exclusively used for self- management functions inside a trusted domain. They are not used for user traffic. Communications with entities outside the s/user/customer/ - whichever term we use, we may want to put this into the terminology s/consensus was to use standard ULA, because it was deemed to be/ /consensus was to use ULA-random [RFC4193 with L=1], because it was deemed to be/ as the first 40 bits of the MD5 hash of the domain name, in the example "example.com". we will get beat up for using MD5 by someone who uses grep, even as a PRF here. Might as well just say SHA256, as it costs nothing here. o Type: This field allows different address sub-schemes in the In IANA Considerations, I suggest Standards Action, with 111 reserved for private use. I would like V to be at least three bits, maybe 8 bits. In the bootstrap proxy IPIP mechanism, we need to allocate an ACP address for each insecure L2-domain ("port") so that traffic from the Registrar (which inside the IPIP header is v6LL) to get back to the correct link-layer. I have mixed feelings about the 48-bit Registrar ID. I know why you did it, and why you'd want to use 48-bits. (It took two reads to realize it was the Registar's MAC, not the enrolled node's MAC address). So the diagram is really: 48 3 13 48 15 1 +-------------+-+--------+-------------+----------+---+ | hash(domain)|T| ZoneID | Registar ID |Device Num| V | +-------------+-+--------+-------------+----------+---+ Since we never care about the /64 boundary in RPL, since we pass around /128 routes in the ACP, do we care if we've placed the Registar ID here? Clearly it is nice because we have ZoneID as a /64. I'm thinking that I would like to instead do something like: 48 2 46 32 16 +-------------+-+------------+----------+-------------+ | hash(domain)|T| Registar ID|Device Num| V | +-------------+-+------------+----------+-------------+ Where RegistarID is still MAC address derived, with the G and U bits removed, and we now have 2^32 space for devices (I think 2^16 might be too small if one includes CPE devices in the CPE, and one has some churn over a decade+ of CPE devices). There is now 16 bits available to do things, and we can pass /114 routes around in RPL, btw. I'm open as to whether V remains as a specified bit, or if "physical" machine is just V=0x0000. If we need ZoneID, then I suggest that we can easily get it by having different Registrar IDs for each zone. If you want them in different /64s then just construct the RegistarID to be unique in the upper 14 bits. This brings up an important aspect, which I know we have discussed before, which is what does the certificate say, and how does it relate to IPsec SA permissions, and therefore to ability for GRASP to trust things. XXX I need to write something here to make it clearer that the ACP isn't so squisshy in the middle... 5.8.4: If a device learns through an autonomic method or through configuration that it is part of a zone, it MUST also respond to its ACP address with that zone number. In this case the ACP loopback is I don't like this, because it seriously breaks up the aggregation that might otherwise be possible. I don't want explicit ZoneID, I'd rather go with the Note: in 5.8.4, or use the RegistrarID. 5.9: Needs to say more clearly that we are using 6550 RPL, and we need to decide if we are using storing or non-storing mode. I strongly suggest that we want storing mode. We will have to define a bunch of other RPL parameters. We also need to be clear that RPL is occuring *within* the ACP channels. (Alternatively, we could run RPL outside the ACP channels, using RPL layer-3 security, and then setup ACP channels when we pick a parent. There are definite advantages to this, and also many downsides. I don't suggest this, but, it might be worth saying why) 5.10: When we establish multiple ACP channels RPL (or any other routing protocol!) will need to have some metrics to pick among them. I'm not sure what we can provide here, at the least, we should prefer shorter paths to longer ones. If an autonomic node decides to have a limit on how many channels it sets up, or how many it will setup with a particular peer, it SHOULD indicate a clear "thanks, I'm full" message in the ACP channel negotiation protocol (i.e. an IKEv2 Notification). 6.1: Is there a distinction between marking a port on a switch as "ACP access" (no ACP channel) to connect to the NMS, from a case where the switch is told to negotiate an ACP channel with the NMS machines (extending the ACP via explicit configuration, rather than via discovery)? I think so, does 6.1 cover only the "ACP access" case then? Can we give it a clear name? I'd like to add a 6.3: ACP through third-party L3 Clouds I'm thinking that a cooperating L3 device could M_FLOOD ACP, and then, when the IKEv2 negotiation comes in, could have been configured to forward the traffic back to a designated ACP node at the edge of the NMS. (maybe over IPv4 including NATs). The resulting tunnel would be an ESP-over-UDP tunnel. A multi-tenant datacenter might provide this as a service to it's tenants. (where would the bandwidth come from? The datacenter would probably buy that from a it's transit tenants and be multihomed) 7. o If an existing device gets revoked, it will automatically be denied access to the ACP as its domain certificate will be validated against a Certificate Revocation List during authentication. Since the revocation check is only done at the First mention of CRLs, btw! This is one of the details that belong in section 5.5.1/5.5.2. automatically torn down. If an immediate disconnect is required, existing sessions to a freshly revoked device can be re-set. the problem is that the knowledge to know to re-set is not distributed, unless we do it via GRASP. The detail missing is that we should be restarting the IKEv2 Parent SAs periodically (we can do this without killing the Child SAs), and doing the OCSP checks there. I suggest that OCSP is probably the better solution rather than CRLs here as we have an ACP over which to do it. Max may have an opinion here, and maybe we should do CRLs instead for reasons of network partition. There are few central dependencies: A certificate revocation list (CRL) may not be available during a network partition; a suitable policy to not immediately disconnect neighbors when no CRL is available can address this issue. Assuming that "immediately" means that we eventually disconnect neighbours when no CRL is available, isn't that the same as just making the CRL recheck time longer? i.e. CRL check time of X + grace period Y same as: CRL check time = X+Y rekey time = X section 10, needs a discussion about source address spoofing within the ACP. Appendix A: of the network, the less state needs to be maintained. This adapts nicely to the typical network design. Also, all changes below a common parent node are kept below that parent node. this implies that we are using storing mode. It's not true for non-storing mode. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWD78voCLcPvd0N1lAQKSDwf+LQ5K86UDq2DesYhhVm4jejxOQvV23wSn xIZgAJTGsuPaX8y7LSjlUllkEVUQ/wnb7fvNjoM1AsniqQwDSqcRA/ICpxRSs7El aXs9rq/oLlXIBxb12U8A9p2nndIvXeyRVUs+nv/5+Sq3ly9ThdtoC34V7+6J2fAf c1IMjZJfYiL/aVpOrXkj6WWAwh2z3gv2rH24TnnYRtEs70+Fn3mfRw9ZaZfYcDI+ 8XdxpQEl0CGtw3qWdQcu3lPn9IX0jV8BJbINtir6qzQWqTwX0uYtTdW/L2q6Fw5Q U2OBVX8cLc0IPbYFN27WCmLXMZHzbX12apaXIgajchs7DzG/dGxzZQ== =adtD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 30 12:00:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8322C1299FB for ; Wed, 30 Nov 2016 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 dR3vCETm5tol for ; Wed, 30 Nov 2016 12:00:00 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13378129A09 for ; Wed, 30 Nov 2016 11:59:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 24FCFE19D; Wed, 30 Nov 2016 15:16:52 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 89B55637A6; Wed, 30 Nov 2016 14:59:48 -0500 (EST) From: Michael Richardson To: Sheng Jiang In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CC6E6BC@NKGEML515-MBX.china.huawei.com> References: <14156.1480438302@obiwan.sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B927CC6E6BC@NKGEML515-MBX.china.huawei.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: Cc: Terry Manderson , "mersue@gmail.com" , "anima@ietf.org" Subject: Re: [Anima] ownership vouchers (and git repo) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 30 Nov 2016 20:00:03 -0000 --=-=-= Content-Type: text/plain Sheng Jiang wrote: > The information I got from netconf looks conflict. It seems Kent and > you thought Netconf did not want this work and it is not a right home > for it. But, Mehmet thought netconf was interested in this work and > would like to have it in netconf. Personally, I support this work and > think it should be done before or at least parallel with ANIMA > bootstrap. I am fine to see it grow up in either Netconf or ANIMA. I'm reporting a conversation that Kent and I had about the NETCONF WG meeting's reaction to adopting the work. So it's all heresay... Ultimately, it's an AD decision, and I'd like to hear from them, and get on with the actual work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWD8vsYCLcPvd0N1lAQJpjgf7BYsyZb5dws8GfKCVD4t+dVYUwbngZfZz GCQ7W6yohPLERKu9zNLVEhAqoNdJBHuy2xB1NV1a2UCVIg7k9tqHTQQlEN6odjN4 wkn4pwTWZmh7U/wckgVIm8TeqoQVTr4eIbAlI1pniN2OM4em+7sJsKUdY7ectzqa WOJ7hIwHF91zqXD2UL88XwOkvMziFecUFABs5cgfOyFKzLLs+n8X+d0PAdIVCTA+ F4+tNFYmdhxfnHE1QpVtiAwYHUPzYP0fid1yFQkCfnFAcx65jWK/vv8npZhE8gt4 ODWfZTd23soi//zM4DaUv/de94Bxt7DJLsS5cKNOEAcF5/R976IjVA== =Mk29 -----END PGP SIGNATURE----- --=-=-=--