From nobody Mon Jan 11 01:58:32 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01E1A888C; Mon, 11 Jan 2016 01:58:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111095820.20691.2066.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 01:58:20 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 09:58:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. Title : A Reference Model for Autonomic Networking Authors : Michael H. Behringer Brian Carpenter Toerless Eckert Laurent Ciavaglia Bing Liu Jeferson Campos Nobre John Strassner Filename : draft-ietf-anima-reference-model-00.txt Pages : 24 Date : 2016-01-11 Abstract: This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-reference-model-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 11 02:21:03 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF3E1A88C9 for ; Mon, 11 Jan 2016 02:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUyYUtUg3NsR for ; Mon, 11 Jan 2016 02:20:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDB31A88CB for ; Mon, 11 Jan 2016 02:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3018; q=dns/txt; s=iport; t=1452507659; x=1453717259; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RolHDkLiltS78KywFykEiCEId2CiUikriaA1FXZupQg=; b=bjJzt/MRQ2a6ZLd4VU2iF0gyzrVYd00P6q74sTuGc/aUFbu59CHM+dwH T7/w8TUclNO6aKo6XwbJKc3ULVC3WEaxbQ6eUw6gOpKkPoYA42BsIIOni 0b1ybB5g2gATg68eNlW9CxWSRIFPxmA6piafur5gX6ZhCASvP6d2pxYqj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgAygZNW/5ldJa1egzpSbQaIU7NeA?= =?us-ascii?q?Q2BZiKFbQIcgQM4FAEBAQEBAQF/C4Q0AQEBBCMRPgUOBAIBCBEEAQEDAiMDAgI?= =?us-ascii?q?CHxEUAQYBAQUDAgQTCBOHfgMSDq5pjGwNgn8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYgQGFVYR/gk+BYS00gmKBSQWNP4lUAYVChh6BcYFlSoN5iFyGcodeASABAUK?= =?us-ascii?q?ECnIBhFxDgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,552,1444694400"; d="scan'208";a="65986513" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 10:20:58 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0BAKwVj012297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jan 2016 10:20:58 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.1104.5; Mon, 11 Jan 2016 04:20:58 -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.1104.009; Mon, 11 Jan 2016 04:20:57 -0600 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-ietf-anima-reference-model-00.txt Thread-Index: AQHRTFachNwhE/Z3EUiuw/+5gYYYsp72GWVg Date: Mon, 11 Jan 2016 10:20:57 +0000 Message-ID: <9e610be2a6d84d8492fcab2a2ad10e94@XCH-RCD-006.cisco.com> References: <20160111095820.20691.26888.idtracker@ietfa.amsl.com> In-Reply-To: <20160111095820.20691.26888.idtracker@ietfa.amsl.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.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-ietf-anima-reference-model-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 10:21:02 -0000 QU5JTUEsIA0KDQpJIGhhdmUgbm93IHBvc3RlZCB0aGUgcmVmZXJlbmNlIG1vZGVsIGFzIGEgV0cg ZG9jdW1lbnQuIEl0IGlzIHVuY2hhbmdlZCBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uLiANCg0K V2hpbGUgSSBnbyBiYWNrIHRocm91Z2ggdGhlIGRvYyB0byBzZWUgd2hhdCBpcyBwZW5kaW5nLCBt YXkgSSByZW1pbmQgdGhlIChudW1lcm91cykgZm9sa3Mgd2hvIHZvbHVudGVlcmVkIHRvIGNvbnRy aWJ1dGUgdG8gYSBzZWN0aW9uLCB0byBsZXQgdGhlIHRlYW0ga25vdyB3aGF0IHRoYXQgc3RhdHVz IG9mIHRoZWlyIGNvbnRyaWJ1dGlvbiBpcyA7LSkgDQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogMTEgSmFudWFyeSAyMDE2IDEw OjU4DQo+IFRvOiBMYXVyZW50IENpYXZhZ2xpYSA8bGF1cmVudC5jaWF2YWdsaWFAYWxjYXRlbC1s dWNlbnQuY29tPjsgSmVmZXJzb24NCj4gQ2FtcG9zIE5vYnJlIDxqY25vYnJlQGluZi51ZnJncy5i cj47IEJpbmcgTGl1IDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsNCj4gQnJpYW4gRS4gQ2FycGVu dGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBNaWNoYWVsIEJlaHJpbmdlcg0KPiAo bWJlaHJpbmcpIDxtYmVocmluZ0BjaXNjby5jb20+OyBUb2VybGVzcyBFY2tlcnQgKGVja2VydCkN Cj4gPGVja2VydEBjaXNjby5jb20+OyBMYXVyZW50IENpYXZhZ2xpYSA8TGF1cmVudC5DaWF2YWds aWFAYWxjYXRlbC0NCj4gbHVjZW50LmNvbT47IEJyaWFuIENhcnBlbnRlciA8YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tPjsgSm9obg0KPiBTdHJhc3NuZXIgPGpvaG4uc2Muc3RyYXNzbmVyQGh1 YXdlaS5jb20+DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwtDQo+IDAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMC50eHQNCj4g aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWNoYWVsIEguIEJlaHJpbmdlciBh bmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQt aWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwNCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJQSBS ZWZlcmVuY2UgTW9kZWwgZm9yIEF1dG9ub21pYyBOZXR3b3JraW5nDQo+IERvY3VtZW50IGRhdGU6 CTIwMTYtMDEtMTENCj4gR3JvdXA6CQlhbmltYQ0KPiBQYWdlczoJCTI0DQo+IFVSTDogICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hbmlt YS1yZWZlcmVuY2UtDQo+IG1vZGVsLTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtDQo+IG1v ZGVsLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLQ0KPiAwMA0KPiANCj4gDQo+IEFic3RyYWN0Og0K PiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHJlZmVyZW5jZSBtb2RlbCBmb3IgQXV0b25v bWljIE5ldHdvcmtpbmcuDQo+ICAgIFRoZSBnb2FsIGlzIHRvIGRlZmluZSBob3cgdGhlIHZhcmlv dXMgZWxlbWVudHMgaW4gYW4gYXV0b25vbWljDQo+ICAgIGNvbnRleHQgd29yayB0b2dldGhlciwg dG8gZGVzY3JpYmUgdGhlaXIgaW50ZXJmYWNlcyBhbmQgcmVsYXRpb25zLg0KPiAgICBXaGlsZSB0 aGUgZG9jdW1lbnQgaXMgd3JpdHRlbiBhcyBnZW5lcmFsbHkgYXMgcG9zc2libGUsIHRoZSBpbml0 aWFsDQo+ICAgIHNvbHV0aW9ucyBhcmUgbGltaXRlZCB0byB0aGUgY2hhcnRlcmVkIHNjb3BlIG9m IHRoZSBXRy4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Jan 11 11:56:26 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E08061A90AC; Mon, 11 Jan 2016 11:56:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 11:56:22 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:56:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks Authors : Sheng Jiang Zongpeng Du Brian Carpenter Qiong Sun Filename : draft-ietf-anima-prefix-management-00.txt Pages : 14 Date : 2016-01-11 Abstract: This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 11 13:46:27 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24D1ABB19 for ; Mon, 11 Jan 2016 13:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bsDwHniTnoD for ; Mon, 11 Jan 2016 13:46:24 -0800 (PST) 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 A00A11A930A for ; Mon, 11 Jan 2016 13:46:24 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id n128so50772321pfn.3 for ; Mon, 11 Jan 2016 13:46: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-type:content-transfer-encoding; bh=/3Da/o+hn0+om+BX9A6q5EBd/Sny+/PBQx1LHIytYBs=; b=Zl2nz1jizEfT6OhVf10pBzIyZFBpczc/gfKoAvIb0ep6fciAxjs7WGxjR/m202i/lH 5fCz9NIZ62vZ+nTY3PcYtCE0ZJVH4OSB6Z8FIkVZISHvU3WoWusg2huEO7e1H9gIVzN0 li9MRGyYRddGRVuFq38gw+Y0qb6g8CJ5yiu+yR+VJiBv1QtSmE2KdYEOt9WqDmFrnKaU 5PEOBTeYRIYzPzepTbXTPfvbU+ZHb+X+Z3EuN2ZuDsn8V+ZPHEGHwvFqcQqz0xmPYzA5 sDQ/sGMdVCKG8w3TtJvfsnT0//JpFufro6HxVu0qvpSE16yb9r+9WtPj7S6QdA1pHnfg BNYQ== X-Received: by 10.98.64.83 with SMTP id n80mr29558414pfa.149.1452548784357; Mon, 11 Jan 2016 13:46:24 -0800 (PST) Received: from ?IPv6:2406:e007:59f5:1:28cc:dc4c:9703:6781? ([2406:e007:59f5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r66sm25365531pfr.59.2016.01.11.13.46.20 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jan 2016 13:46:22 -0800 (PST) To: Anima WG References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <569422AD.9060009@gmail.com> Date: Tue, 12 Jan 2016 10:46:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 21:46:27 -0000 Hi, There are extensive changes in this compared to the pre-WG draft, so please review it and send your comments to the list. Regards Brian P.S. We hope to release a major update to the GRASP specification in the coming days. On 12/01/2016 08:56, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. > > Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks > Authors : Sheng Jiang > Zongpeng Du > Brian Carpenter > Qiong Sun > Filename : draft-ietf-anima-prefix-management-00.txt > Pages : 14 > Date : 2016-01-11 > > Abstract: > This document describes an autonomic solution for IPv6 prefix > management at the edge of large-scale ISP networks. An important > purpose of the document is to use it for validation of the design of > various components of the autonomic networking infrastructure. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-prefix-management-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 Tue Jan 12 09:46:53 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7B1A0135 for ; Tue, 12 Jan 2016 09:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQnE0mLRKooP for ; Tue, 12 Jan 2016 09:46:50 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDAB1A012D for ; Tue, 12 Jan 2016 09:46:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2A6FB25F012; Tue, 12 Jan 2016 09:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1452620810; bh=PoIS4i2LcuTchW6IEehfnOKxAJq3p7nw68CrTM5EU04=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ll30lYyUbjHJYZWnsQQkyNOzQdeosZn/06BU8yZjKZRBO8EBppKAGtXV6LUI2EnJf fiXgCiV7SgoY+64KgkwKFSaCeMI0XNTkIyXUow0IN4XNI5cZTz5ALvMXLVcqkPapKr 4Kdl4lHJDYgkltEC8js6LJ8R8tgn8X0DPAXWmSmg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C908925F017; Tue, 12 Jan 2016 09:46:49 -0800 (PST) To: Brian E Carpenter , Anima WG References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> <569422AD.9060009@gmail.com> From: "Joel M. Halpern" Message-ID: <56953BDA.1090501@joelhalpern.com> Date: Tue, 12 Jan 2016 12:46:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569422AD.9060009@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 17:46:52 -0000 My thanks to the authors for all the work on this. It is now very clear what it is attempting to do, and why. This appears to surface an issue with what it means to support an objective. The PrefixManager objective seems to include two kinds of parties. One kind just wishes to receive Anima Prefix Delegation (for example, and edge device participates in the objective, but generally will not hand part of its allocated prefix to another edge device. The other kind both requests prefixes (unless it happens to be the source of all knoweldge) and delegates them using Anima. This distinction is supported in the sense that redirection permits it happen. But determining how a device would decide to redirect vs answer, and how the policy system would cause things to behave right, seems very difficult to extract from the system. This is similar to the notion relative to DHCPv6 PD, where one may support PD for purposes of requesting prefixes, for purposes of granting prefixes, or both. But all we have is a single bit. Yours, Joel On 1/11/16 4:46 PM, Brian E Carpenter wrote: > Hi, > > There are extensive changes in this compared to the pre-WG draft, > so please review it and send your comments to the list. > > Regards > Brian > > P.S. We hope to release a major update to the GRASP specification > in the coming days. > > > On 12/01/2016 08:56, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. >> >> Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks >> Authors : Sheng Jiang >> Zongpeng Du >> Brian Carpenter >> Qiong Sun >> Filename : draft-ietf-anima-prefix-management-00.txt >> Pages : 14 >> Date : 2016-01-11 >> >> Abstract: >> This document describes an autonomic solution for IPv6 prefix >> management at the edge of large-scale ISP networks. An important >> purpose of the document is to use it for validation of the design of >> various components of the autonomic networking infrastructure. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jan 12 16:36:12 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AADBF1A9139; Tue, 12 Jan 2016 16:36:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160113003610.7570.78040.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 16:36:10 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-grasp-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 00:36:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-02.txt Pages : 56 Date : 2016-01-12 Abstract: This document establishes requirements for a signaling protocol that enables autonomic devices and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings mutually with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 16:52:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72F61AC3E6 for ; Tue, 12 Jan 2016 16:52:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nERTToVEAKxg for ; Tue, 12 Jan 2016 16:52:47 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214831AC3E0 for ; Tue, 12 Jan 2016 16:52:47 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id q63so73453842pfb.1 for ; Tue, 12 Jan 2016 16:52: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-type:content-transfer-encoding; bh=3igp8N/uPhxkmcibtNqxsfbQ4pA5VUCAVOYZdxq3p3A=; b=Kgk44rz4FGhsrXmjKr+ccuyYI9SIJlBRfihEOjLVKuGdB0z7ijzI+H5J6Z+HMSaAdA iHzgUc44Xbh/MJ/SVsz9BgX7rFBlw6vqL6bXI5Xjp0OokfJe1XPqgLyRfUO9zOAry+r0 +Pdw83WFrelwjMM+Q4s5iZz3ePLXhZ903stEEKwlgtZDdFN+LBKw0EVDXy5o2/1IFySE alajrpWdxcXORjFlN0UXZ6/QrqLcPhMolij/2aDm/1y195wYWgk2DJPAacbKrRBxZQds WxsywHMA+RwK5OQu2TvBaVT+4H7T5uJQO9diJb/eQSP5aW9UkjCdjRjuNn/0RKTpxHm9 Usqg== X-Received: by 10.98.74.202 with SMTP id c71mr38848594pfj.14.1452646366750; Tue, 12 Jan 2016 16:52:46 -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 b84sm32980587pfj.25.2016.01.12.16.52.43 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 16:52:45 -0800 (PST) To: Anima WG References: <20160113003610.7570.78040.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56959FDF.9080209@gmail.com> Date: Wed, 13 Jan 2016 13:52:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160113003610.7570.78040.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 00:52:49 -0000 Hi, This update to the GRASP design hopefully addresses the issues raised in Yokohama. It also reflects experience with a demonstration prototype implementation of GRASP in Python, which has taken most of the time since the IETF. As a result there are a number of changes to the protocol. The biggest one was splitting the RESPONSE message into three separate messages (RESPONSE for discovery responses, SYNCHRONIZE for synchronization responses, and FLOOD for unsolicited flood messages). We need careful reviews of this version and decisions about the open issues. After people have had a few days to digest the document, we will start discussion threads on the open issues. Change log: https://tools.ietf.org/html/draft-ietf-anima-grasp-02#section-9 Open and closed issues: https://tools.ietf.org/html/draft-ietf-anima-grasp-02#section-4 Anyone who has Python 3.4 and IPv6 on their machine, and is feeling brave, please contact me off list about the demonstration code. Regards Brian On 13/01/2016 13:36, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-02.txt > Pages : 56 > Date : 2016-01-12 > > Abstract: > This document establishes requirements for a signaling protocol that > enables autonomic devices and autonomic service agents to dynamically > discover peers, to synchronize state with them, and to negotiate > parameter settings mutually with them. The document then defines a > general protocol for discovery, synchronization and negotiation, > while the technical objectives for specific scenarios are to be > described in separate documents. An Appendix briefly discusses > existing protocols with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 Tue Jan 12 17:48:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B295C1B2B8B for ; Tue, 12 Jan 2016 17:48: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tusT69rkw4An for ; Tue, 12 Jan 2016 17:48:33 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC221B2B8F for ; Tue, 12 Jan 2016 17:48:33 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id q63so74221783pfb.1 for ; Tue, 12 Jan 2016 17:48: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-type:content-transfer-encoding; bh=xjTkKrDEVZXZBbf6gVIF1frFUezRH2RA06d9Xy/csqg=; b=o9bjAPPQS9KlGZA6o/wVpl2tt13LLoAMbYlQBXNPdGWxIdBI0pa2VM7Tx5UWqEfLm/ H3jGzyDcO3NqyQetbVu6TEkIJB7GrApD6FVcX1HHr+Ti89mU8v/xjLEiY+8zcuNs0/Hv BatliVNj3wm7ucM6iD/1v52F2HK7VtoUM3JlaSEbwKj7GrLnHKoEqecitTKC+ClZP14v hlJKwjgnpuhVn9wGUMVMAHfDneHPiDgQpz/78Ln+I7TnTj6A65ALG4kashb13Sb0XIG0 IVlNFTD6aeZqCgPrIeDjxj+EpLKdyetGsBMmNrtrSrG8Zgah0aFeZHXMe6pANOg/AWQq lIMA== X-Received: by 10.98.8.218 with SMTP id 87mr39251236pfi.39.1452649713479; Tue, 12 Jan 2016 17:48:33 -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 q8sm193829226pap.45.2016.01.12.17.48.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 17:48:31 -0800 (PST) To: "Joel M. Halpern" , Anima WG References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> <569422AD.9060009@gmail.com> <56953BDA.1090501@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5695ACF0.5060404@gmail.com> Date: Wed, 13 Jan 2016 14:48:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56953BDA.1090501@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 01:48:35 -0000 On 13/01/2016 06:46, Joel M. Halpern wrote: > My thanks to the authors for all the work on this. It is now very clear what it is attempting to do, and why. > > This appears to surface an issue with what it means to support an objective. The PrefixManager objective seems to include two > kinds of parties. One kind just wishes to receive Anima Prefix Delegation (for example, and edge device participates in the > objective, but generally will not hand part of its allocated prefix to another edge device. The other kind both requests > prefixes (unless it happens to be the source of all knoweldge) and delegates them using Anima. Right. The protocol is certainly agnostic on that issue; it's more a question of the role and capabilities of a given ASA. That's an issue we have ducked so far. > This distinction is supported in the sense that redirection permits it happen. But determining how a device would decide to > redirect vs answer, and how the policy system would cause things to behave right, seems very difficult to extract from the system. Yes. I do note that an ASA that does not listen for incoming requests will never respond to them, however! Brian > > This is similar to the notion relative to DHCPv6 PD, where one may support PD for purposes of requesting prefixes, for purposes > of granting prefixes, or both. But all we have is a single bit. > > Yours, > Joel > > On 1/11/16 4:46 PM, Brian E Carpenter wrote: >> Hi, >> >> There are extensive changes in this compared to the pre-WG draft, >> so please review it and send your comments to the list. >> >> Regards >> Brian >> >> P.S. We hope to release a major update to the GRASP specification >> in the coming days. >> >> >> On 12/01/2016 08:56, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. >>> >>> Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks >>> Authors : Sheng Jiang >>> Zongpeng Du >>> Brian Carpenter >>> Qiong Sun >>> Filename : draft-ietf-anima-prefix-management-00.txt >>> Pages : 14 >>> Date : 2016-01-11 >>> >>> Abstract: >>> This document describes an autonomic solution for IPv6 prefix >>> management at the edge of large-scale ISP networks. An important >>> purpose of the document is to use it for validation of the design of >>> various components of the autonomic networking infrastructure. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > From nobody Wed Jan 13 16:56:13 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC71AD09F; Wed, 13 Jan 2016 16:56:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160114005610.2522.76531.idtracker@ietfa.amsl.com> Date: Wed, 13 Jan 2016 16:56:10 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 00:56:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-00.txt Pages : 16 Date : 2016-01-13 Abstract: OAM (Operations, Administration and Management) processes for data networks are often subject to the problem of circular dependencies when relying on network connectivity of the network to be managed for the OAM operations itself. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability can not be automated either because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN). to provide stable and secure connectivity for those OAM processes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 13 18:25:10 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E761B29E6 for ; Wed, 13 Jan 2016 18:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrz4KOKDNRgy for ; Wed, 13 Jan 2016 18:25:06 -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 554471B2A43 for ; Wed, 13 Jan 2016 18:25:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGU35233; Thu, 14 Jan 2016 02:25:02 +0000 (GMT) Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Jan 2016 02:25:01 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Jan 2016 02:25:01 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Thu, 14 Jan 2016 10:24:54 +0800 From: "Liubing (Leo)" To: Anima WG Thread-Topic: GRASP messages-//RE: [Anima] I-D Action: draft-ietf-anima-grasp-02.txt Thread-Index: AQHRTZpujbg9vPcumE6Bfn8lLmnbAZ74GB+AgAImXcA= Date: Thu, 14 Jan 2016 02:24:53 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D3D532@nkgeml514-mbx.china.huawei.com> References: <20160113003610.7570.78040.idtracker@ietfa.amsl.com> <56959FDF.9080209@gmail.com> In-Reply-To: <56959FDF.9080209@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] 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.0A020202.569706FF.016F, 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: 9d60d4ca63b3e95a45638fd8b563c2d4 Archived-At: Subject: [Anima] GRASP messages-//RE: I-D Action: draft-ietf-anima-grasp-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 02:25:09 -0000 Hi Dear all, > As a result there are a number of changes to the protocol. The biggest on= e > was splitting the RESPONSE message into three separate messages > (RESPONSE for discovery responses, SYNCHRONIZE for synchronization > responses, and FLOOD for unsolicited flood messages). >=20 > We need careful reviews of this version and decisions about the open issu= es. > After people have had a few days to digest the document, we will start > discussion threads on the open issues. [Bing] Please allow me to discuss the following open question firstly: 47. REQUEST is a dual purpose message (request negotiation or request synchronization). Would it be better to split this into two different messages (and adjust various message names accordingly)? For my personal feeling, the issue is not only the overloading for both Neg= otiation and Synchronization, but also the violation the custom that "Reque= st" is usually coupled with "Response" in other protocols. In GRASP, "Respo= nse" is coupled with "Discovery". So, if we split the REQUEST message, I think might fit more to the split RE= SPONSE messages (RESPONSE for discovery responses, SYNCHRONIZE for synchron= ization responses, and FLOOD for unsolicited flood messages), plus, with a = bit renaming, the messages could be like this: - Discovery & Discovery_Res - Negotiation_Init & Negotiation & Negotiation_End - Synchronization & Synchronization_Res - Confirm-waiting - Flood Btw, the message name "Flooding message" is a very common/abstract phrase, = can we find another more precise name? E.g., "Flooded Synchronization" or "= Unsolicited Synchronization".=20 These seem more institutive for me. What are your thought? Best regards, Bing From nobody Sun Jan 17 14:26:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB84F1A901D for ; Sun, 17 Jan 2016 14:26: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx2XcQ0m-Uwg for ; Sun, 17 Jan 2016 14:26:30 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 A2F051A901C for ; Sun, 17 Jan 2016 14:26:30 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id cy9so423277627pac.0 for ; Sun, 17 Jan 2016 14:26:30 -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-type:content-transfer-encoding; bh=AYDlc6U5WrG743NkEl6xpXJzSWwBkSQlkLoe3CI1aro=; b=sVqebfLw9BKNjG1WgDpk5Rzv7Xp8CGKc64m4C9ySiJYhJwnHjjLj1Idq88P5bqB6PV mDblPjWg1CC7thSsU/IbetyppKp+sY0EvZjGx6uZDZnB59C7pR1ZT8s8tZqQM2MQ5wDz 9NNCyB2hydxZn9wo2qD8gddCAKiW8V5IqV6SBJ897Wg1k0k+w++EgKyUsMetfm+++Tte S3AzuuJb/Qi72eApPAXHADuxopy98rtj1qkVIpGNXAXDhnU1qa75KVHqYlWfcJ0mSWdu Zu6KlhKcnbyNUvhxbHrVZf/WlMOPsqMHJN1Q+t6Ir3JMpZaIVjmfdjuWMdvYc1u3aNTN D0nA== 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-type :content-transfer-encoding; bh=AYDlc6U5WrG743NkEl6xpXJzSWwBkSQlkLoe3CI1aro=; b=Z2gjiHaVNWK3HHNqCcNw8Pe1+m+FY7YjgV4RlnQFL3hNXkwI0QiEh4/3Ge0fgLxg+N MJuPrbw/tk6AI9rzODWD9P2N53ar1MSRspqJDJztdtYJYjH+IkM4OdMuVFaTLRX9l4oR RqcRmF2NHK4fM9bIy/dFYy2OSijNnkEtTXdY9Eg8fiA4iepTGqHMeCfJ++xvFXdD/55f /jRvmyl/yoV9DJjky7p7XmU6Wg9H+z0RdguIoKyP+D4owIH+DCQeqLxoLFlNJHwzYLXZ MuibaDDO8ZbdJ46UztxSnYmAzMJDILWn7f9fuywRr7/8Aj4SOKz5hWP3l8B+SbncIR7l 5M9A== X-Gm-Message-State: AG10YOSTdrNoYJ8vLUb3u3LfHEDWP2ZyBmHuFxAeQF78Mlt1tDhXVb/NHr70cY8OOSSjNQ== X-Received: by 10.66.102.40 with SMTP id fl8mr21754240pab.136.1453069590334; Sun, 17 Jan 2016 14:26:30 -0800 (PST) Received: from ?IPv6:2406:e007:4924:1:28cc:dc4c:9703:6781? ([2406:e007:4924:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s13sm27275099pfi.12.2016.01.17.14.26.27 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jan 2016 14:26:28 -0800 (PST) To: anima@ietf.org References: <20160117031203.15651.47936.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <569C1513.7000803@gmail.com> Date: Mon, 18 Jan 2016 11:26:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160117031203.15651.47936.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-richardson-anima-state-for-joinrouter-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 22:26:31 -0000 > 1. Introduction ... > It order to > avoid providing globally reachable addresses to the prospective new > network member, it assumes that a Join Router. That sentence ends a bit abruptly. Section 3 has various sentences like: > In response to discovery, the proxy would reply with... Does that mean you have settled on the new node sending a discovery multicast? (Just asking. GRASP could work this way round, or by the proxy occasionally flooding its information for new nodes to hear. It could even send a URI as the immediate response to discovery.) > 3.4. 4. CoAP/DTLS with relay mechanism ... > The new node would then initiate a DTLS session over UDP I don't understand where the certificate comes from in that case. Do you plan to add pros and cons for the various methods? I realise that your purpose is to describe all the choices, but I think we should immediately wipe all the NAT approaches off the table. IMHO, we must never encourage any form of NAT for IPv6. Regards Brian From nobody Mon Jan 18 08:11:20 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089621B392D for ; Mon, 18 Jan 2016 08:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 U5M3uPh7MZHn for ; Mon, 18 Jan 2016 08:11:18 -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 F3EE31B392C for ; Mon, 18 Jan 2016 08:11:15 -0800 (PST) Received: from sandelman.ca (199-7-157-95.eng.wind.ca [199.7.157.95]) by relay.sandelman.ca (Postfix) with ESMTPS id 402CA22086; Mon, 18 Jan 2016 11:11:14 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8CCF66CB03; Mon, 18 Jan 2016 11:11:09 -0500 (EST) From: Michael Richardson To: "Joel M. Halpern" In-reply-to: <56953BDA.1090501@joelhalpern.com> References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> <569422AD.9060009@gmail.com> <56953BDA.1090501@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Tue, 12 Jan 2016 12:46:02 -0500." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 18 Jan 2016 11:11:09 -0500 Message-ID: <23199.1453133469@dooku.sandelman.ca> Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 16:11:20 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > This distinction is supported in the sense that redirection permits it > happen. But determining how a device would decide to redirect vs answer, and > how the policy system would cause things to behave right, seems very > difficult to extract from the system. I think you are asking about scenario where device A asks device B for some space, but... while device B has some space, and it could allocate it, topologically it might make more sense for device B to redirect device A to device C, which has a larger pool. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWnQ6bAAoJEKD0KQ7Gj3P2Q/wIAIMU8pnR0rKR4hdxcg0mvMrA nPEso0eDkI/wU9sr8ASx7vyoqmef6WhIe/REG3wkwgLE+Tx1LPc50nL8G6ug/ZbT IReNIIFlOgBzSmT1wQ2faelaqlGpLdOQ55nUDKhxkOc4roEEPDCTm3joHMFAbRYN CkwY8F9LJjheFZiUgNitDWluf/aliPWA3GGhFdhVKe4PxiWG0fRmSTWTbnc0Vtu+ 3wJo5UIloK5AFAvZSSBSv2LU3x72+VS7st3LYViRkncspR4LiTJZPZ7pyCI255ak GwlaeK0iUmoESeqvjRFtttSUTEm/LrgU457BR2isFCqhee/Iz8Y6jt6SbXtntJA= =LD0J -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 18 09:04:30 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5E11B3A49 for ; Mon, 18 Jan 2016 09:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naIR2zGKkwrq for ; Mon, 18 Jan 2016 09:04:28 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B08B1B3A41 for ; Mon, 18 Jan 2016 09:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id EE578500169; Mon, 18 Jan 2016 09:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1453136667; bh=0B2UO5TJOt/t5SaKb7YdcEex+69nv45D6/OeHZ061cE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ax8a1zamepRpUoU/BybRQnl7JplNIvZ3o1XvVtg3DXJIhViAmSo4c86xsF+IcIisF rzbgO5n5XpV7rfKNhjfNIr+pPt6LBrp2GlWaz9fiqgah+6Vb4i62TDHPsSi7d31Zhq w1G5y2HS30sVCtwwq2zV+ZxnfQiafUMLmgZAHTA8= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EFF7D50018F; Mon, 18 Jan 2016 09:04:26 -0800 (PST) To: Michael Richardson References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> <569422AD.9060009@gmail.com> <56953BDA.1090501@joelhalpern.com> <23199.1453133469@dooku.sandelman.ca> From: "Joel M. Halpern" Message-ID: <569D1ADC.4050009@joelhalpern.com> Date: Mon, 18 Jan 2016 12:03:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <23199.1453133469@dooku.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 17:04:29 -0000 There are a number of cases where device B should not give an address block to device A. Some seem to work more easily than others, but without configuration it is hard to see from the document how they are supposed to work. The simplest case is where B has gotten address space for allocation to customers. If it reallocates part of that to another device, topological abstraction becomes harder, and it is likely to simply need to make another request sooner. Conceptually, this could even be generalized to B supports the objective, but has no logic for handing out addresses. It simply is not built to do that. We could require that all objective supporters always support both the request role and the allocator role, but that seems to make implementations more complex. Another case is the one you suggest where topologically, it would be better for A to get its address block from a different participant. Yours, Joel On 1/18/16 11:11 AM, Michael Richardson wrote: > > Joel M. Halpern wrote: >> This distinction is supported in the sense that redirection permits it >> happen. But determining how a device would decide to redirect vs answer, and >> how the policy system would cause things to behave right, seems very >> difficult to extract from the system. > > I think you are asking about scenario where device A asks device B for some > space, but... while device B has some space, and it could allocate it, > topologically it might make more sense for device B to redirect device A to > device C, which has a larger pool. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Jan 18 10:56:00 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93631B3BD5 for ; Mon, 18 Jan 2016 10:55:59 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIzPcblqY1B5 for ; Mon, 18 Jan 2016 10:55:58 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 2CB991B3BD2 for ; Mon, 18 Jan 2016 10:55:58 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id ho8so177082400pac.2 for ; Mon, 18 Jan 2016 10:55:58 -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-type :content-transfer-encoding; bh=RK3pWNJ8qxkl43ZbOEoomE04elEhS/8xCkyiQUipvmg=; b=hjlKoHsv7YSc5s1k016Vn2kLYOZEjdgRwWplJ1jwDNZDU2E+guo3Ilkvp8Q4Q7QIwh wk2nyYKLTyOZ7yMHVWkuJqX/7/3M7RpvrZ2dZOyLdR/x96oxvxEVwi1KF/8xGAOfHYvy 6LvD3nOkCmgJm72/6Uu491N+N1eLd/bh0lrktzmLLQ0SZfUHaL0HeK4p9aghzWWn35aj NY5lsYKjouh+Q5lDU56b6WNZPQs475MC5Skzk3RFmvR6AgGcxaS1Wa3/jPaacsB++8Bs vuvs8+LibCDRW1lrazn/bwcQWOIrHHCHbhBRHaXDLzN1JhHVGfkK873lzFV5Z5UGgoi8 oM8A== 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-type :content-transfer-encoding; bh=RK3pWNJ8qxkl43ZbOEoomE04elEhS/8xCkyiQUipvmg=; b=HSRjkPS5PxV3uQIuWqPfejQ/qhyzSp3kHMp7PoSh4dTLKOyVQ1k7MQxwAOxIqDukmB Wy0afxVuGJCBnH5JnZdlZmArBlsrW5ao8GhGqlWubddFUQPZsrJpHLUSosfl1zh04VCL YFUUkC30q60Io1s/8j9XJsbwii66T2QewApssZXRitPLW5l+0mQq1+ydODkRQdexvnD2 51DjWVelgy+KM/Rh2dpwP4aXlBAHwBHMTUmq4y52UmQBHTnfF226I9ySAme29OtDhc2B 4hGcZISNx5Vh7E/cIr0lzHUZQMSDo0F8VMiWX5tG+T1DDbP0uClYgh8cdNebgBO3BrVG TGPA== X-Gm-Message-State: ALoCoQliZm4uQ4TWYq3EeirazSQUqYHcq5pZi/yZN14XrB+Cq4k316eixPTKwjuludbHaMZXKDWUl6X83tUZ5UTscZ8DfZZQuA== X-Received: by 10.66.139.166 with SMTP id qz6mr38668799pab.148.1453143357617; Mon, 18 Jan 2016 10:55:57 -0800 (PST) Received: from ?IPv6:2406:e007:63e1:1:28cc:dc4c:9703:6781? ([2406:e007:63e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r12sm35731160pfi.9.2016.01.18.10.55.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 10:55:55 -0800 (PST) To: "Joel M. Halpern" , Michael Richardson References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> <569422AD.9060009@gmail.com> <56953BDA.1090501@joelhalpern.com> <23199.1453133469@dooku.sandelman.ca> <569D1ADC.4050009@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <569D353B.5080300@gmail.com> Date: Tue, 19 Jan 2016 07:55:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569D1ADC.4050009@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 18:56:00 -0000 Joel, Yes, there are numerous scenarios and cases. From a standards point of view, I think we have to ask several questions: 1. Can we define the Objective and the related Intent with semantics that are sufficient to cover all the scenarios? 2. Can we we make writing an ASA sufficiently straightforward that vendors, or even sophisticated operators, can write their own ASA for a particular scenario? [To be concrete, for example, an ASA that asks for prefixes, but does not hand out prefixes, will simply never listen for incoming negotiation requests; it will only send them. An ASA that does hand out prefixes will also listen for requests and will apply the relevant Intent when negotiating them.] 3. What does this tell us about authorization and roles for ASAs (a topic that we have set aside so far)? 4. Does any of this lead to new or different requirements for GRASP itself? Regards Brian On 19/01/2016 06:03, Joel M. Halpern wrote: > There are a number of cases where device B should not give an address block to device A. Some seem to work more easily than > others, but without configuration it is hard to see from the document how they are supposed to work. > > The simplest case is where B has gotten address space for allocation to customers. If it reallocates part of that to another > device, topological abstraction becomes harder, and it is likely to simply need to make another request sooner. > > Conceptually, this could even be generalized to B supports the objective, but has no logic for handing out addresses. It simply > is not built to do that. We could require that all objective supporters always support both the request role and the allocator > role, but that seems to make implementations more complex. > > Another case is the one you suggest where topologically, it would be better for A to get its address block from a different > participant. > > Yours, > Joel > > On 1/18/16 11:11 AM, Michael Richardson wrote: >> >> Joel M. Halpern wrote: >>> This distinction is supported in the sense that redirection permits it >>> happen. But determining how a device would decide to redirect vs answer, and >>> how the policy system would cause things to behave right, seems very >>> difficult to extract from the system. >> >> I think you are asking about scenario where device A asks device B for some >> space, but... while device B has some space, and it could allocate it, >> topologically it might make more sense for device B to redirect device A to >> device C, which has a larger pool. >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > From nobody Mon Jan 18 11:06:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A761B3BDB for ; Mon, 18 Jan 2016 11:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujwHFbxGIWuV for ; Mon, 18 Jan 2016 11:06:03 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A811B3BD6 for ; Mon, 18 Jan 2016 11:06:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5B9C39800FA; Mon, 18 Jan 2016 11:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1453143963; bh=PKlxNyZUksQudN9HyPyzSPoEKFt2xyy655ETjTOX3t0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=MTZPddxfOkGRKcZtuYziheH8T5VjZ8aRAfi0A90IByqE2wsTWxh+2seuKsispV7nx A6xvS/nqKJdD32Ll4V28KVD6Pwrlfp7/GX0XXgKQuF44no2o++zQT523PjW+4tP1NA tk+uo5WKdwp+Q4+W9gXYClS2ypTTpotMXWdcp9DA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E46B01C08B8; Mon, 18 Jan 2016 11:06:02 -0800 (PST) To: Brian E Carpenter , Michael Richardson References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> <569422AD.9060009@gmail.com> <56953BDA.1090501@joelhalpern.com> <23199.1453133469@dooku.sandelman.ca> <569D1ADC.4050009@joelhalpern.com> <569D353B.5080300@gmail.com> From: "Joel M. Halpern" Message-ID: <569D375C.1020605@joelhalpern.com> Date: Mon, 18 Jan 2016 14:05:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569D353B.5080300@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 19:06:04 -0000 I agree with your points Brian. As written, the current text implies that all participants in this Objective are preapred to delegate address, but they can sometimes refer a requestor to someone else anyway. It allows the needed behavior, it is just unclear about how one would cause it to happen. Yours, Joel On 1/18/16 1:55 PM, Brian E Carpenter wrote: > Joel, > > Yes, there are numerous scenarios and cases. From a standards point of view, > I think we have to ask several questions: > > 1. Can we define the Objective and the related Intent with semantics that are > sufficient to cover all the scenarios? > > 2. Can we we make writing an ASA sufficiently straightforward that vendors, > or even sophisticated operators, can write their own ASA for a particular > scenario? > > [To be concrete, for example, an ASA that asks for prefixes, but does > not hand out prefixes, will simply never listen for incoming negotiation > requests; it will only send them. An ASA that does hand out prefixes will > also listen for requests and will apply the relevant Intent when negotiating > them.] > > 3. What does this tell us about authorization and roles for ASAs (a topic that > we have set aside so far)? > > 4. Does any of this lead to new or different requirements for GRASP itself? > > Regards > Brian > > On 19/01/2016 06:03, Joel M. Halpern wrote: >> There are a number of cases where device B should not give an address block to device A. Some seem to work more easily than >> others, but without configuration it is hard to see from the document how they are supposed to work. >> >> The simplest case is where B has gotten address space for allocation to customers. If it reallocates part of that to another >> device, topological abstraction becomes harder, and it is likely to simply need to make another request sooner. >> >> Conceptually, this could even be generalized to B supports the objective, but has no logic for handing out addresses. It simply >> is not built to do that. We could require that all objective supporters always support both the request role and the allocator >> role, but that seems to make implementations more complex. >> >> Another case is the one you suggest where topologically, it would be better for A to get its address block from a different >> participant. >> >> Yours, >> Joel >> >> On 1/18/16 11:11 AM, Michael Richardson wrote: >>> >>> Joel M. Halpern wrote: >>>> This distinction is supported in the sense that redirection permits it >>>> happen. But determining how a device would decide to redirect vs answer, and >>>> how the policy system would cause things to behave right, seems very >>>> difficult to extract from the system. >>> >>> I think you are asking about scenario where device A asks device B for some >>> space, but... while device B has some space, and it could allocate it, >>> topologically it might make more sense for device B to redirect device A to >>> device C, which has a larger pool. >>> >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >> > From nobody Mon Jan 18 11:15:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CF01B3C08 for ; Mon, 18 Jan 2016 11:15:22 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bS4a_P169ef for ; Mon, 18 Jan 2016 11:15:21 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 219721B3BE3 for ; Mon, 18 Jan 2016 11:15:21 -0800 (PST) Received: by mail-pa0-x230.google.com with SMTP id ho8so177295791pac.2 for ; Mon, 18 Jan 2016 11:15: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-type :content-transfer-encoding; bh=39/tzaqnCBLNRMDDT589LErQqwM/OGz9JLLYwM4/Xr8=; b=s4RppC5aOAYDaFzJPq3VFcdi2HcEto0lwndw3noISzAKNu46wd/sqxY67tgvtDKA8e vbgf2uwsJgEL16uguM8K94DSapF/O+VfJID56vhiUOGA6KsjNAic1QWX/TiSjOrz2zM1 h/TLMOoUv36Yqg1hOpqU6Pi245cJuyiOZ/qVHDDbw2Oxka9jR7ki4UdWBmpaKdV78Xb8 H5/tV1ZdBhlC6Hho/NXiXFKnRQ+819Ztk4OfiJkvIk1gCMQ6xZax/hXIyvYED1lfLF0o oV1rbgTaWfHU6y4OUx0m9pnZk/64xOyGNwrq0mnwksx1PEWxerPh5e5kxrSxoVtUk8DN PCKQ== 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-type :content-transfer-encoding; bh=39/tzaqnCBLNRMDDT589LErQqwM/OGz9JLLYwM4/Xr8=; b=eInFoZqHId5rKJFx8YyOtoHJVAUYYMNhkVQixHdIh0ZG24xopDmR0XDbmTqog+yoRC oWMwbm5XgT2D2m82+7Uib8TCw3x4rzht7Wc2jgnWN5L4sORN0qsxQyvIqBpa2QdLVfa4 snMPqqy8fesMNhRfc5Vo1AXjuEiBkClrDDqE16pvR7MZGygsQOVXULHWXHMQr5POIGDT gfU/ll5/QLnICY1kEY53AASG/jmLPeOgldRRlis9ZTSd8x5pqx5fO9Ulf50mE1Qz+095 Bo4od7frleCl+WitcyewhkAew/pCcXV+5WYUhpT/s75Xo2zN/fsFuyO1Tz7+cAmZ+mjB V9jQ== X-Gm-Message-State: ALoCoQkwdKfWtx+fVN1vfyvGq0gxv8+8QYYgWXnjA/tbl0QzzxllXBlGDslLz7wLCb5YRuIrYhn9cL/H7KP4GqX29qmEVRnxJA== X-Received: by 10.66.100.163 with SMTP id ez3mr39077909pab.5.1453144520747; Mon, 18 Jan 2016 11:15:20 -0800 (PST) Received: from ?IPv6:2406:e007:63e1:1:28cc:dc4c:9703:6781? ([2406:e007:63e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w22sm35676730pfa.79.2016.01.18.11.15.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 11:15:19 -0800 (PST) To: "Joel M. Halpern" , Michael Richardson References: <20160111195622.29302.31971.idtracker@ietfa.amsl.com> <569422AD.9060009@gmail.com> <56953BDA.1090501@joelhalpern.com> <23199.1453133469@dooku.sandelman.ca> <569D1ADC.4050009@joelhalpern.com> <569D353B.5080300@gmail.com> <569D375C.1020605@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <569D39C8.2070901@gmail.com> Date: Tue, 19 Jan 2016 08:15:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569D375C.1020605@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 19:15:22 -0000 On 19/01/2016 08:05, Joel M. Halpern wrote: > I agree with your points Brian. > As written, the current text implies that all participants in this Objective are preapred to delegate address, but they can > sometimes refer a requestor to someone else anyway. It allows the needed behavior, it is just unclear about how one would cause > it to happen. Yes, we should modify the text to make it clear that not all ASAs will behave the same way in this regard. Brian > > Yours, > Joel > > On 1/18/16 1:55 PM, Brian E Carpenter wrote: >> Joel, >> >> Yes, there are numerous scenarios and cases. From a standards point of view, >> I think we have to ask several questions: >> >> 1. Can we define the Objective and the related Intent with semantics that are >> sufficient to cover all the scenarios? >> >> 2. Can we we make writing an ASA sufficiently straightforward that vendors, >> or even sophisticated operators, can write their own ASA for a particular >> scenario? >> >> [To be concrete, for example, an ASA that asks for prefixes, but does >> not hand out prefixes, will simply never listen for incoming negotiation >> requests; it will only send them. An ASA that does hand out prefixes will >> also listen for requests and will apply the relevant Intent when negotiating >> them.] >> >> 3. What does this tell us about authorization and roles for ASAs (a topic that >> we have set aside so far)? >> >> 4. Does any of this lead to new or different requirements for GRASP itself? >> >> Regards >> Brian >> >> On 19/01/2016 06:03, Joel M. Halpern wrote: >>> There are a number of cases where device B should not give an address block to device A. Some seem to work more easily than >>> others, but without configuration it is hard to see from the document how they are supposed to work. >>> >>> The simplest case is where B has gotten address space for allocation to customers. If it reallocates part of that to another >>> device, topological abstraction becomes harder, and it is likely to simply need to make another request sooner. >>> >>> Conceptually, this could even be generalized to B supports the objective, but has no logic for handing out addresses. It simply >>> is not built to do that. We could require that all objective supporters always support both the request role and the allocator >>> role, but that seems to make implementations more complex. >>> >>> Another case is the one you suggest where topologically, it would be better for A to get its address block from a different >>> participant. >>> >>> Yours, >>> Joel >>> >>> On 1/18/16 11:11 AM, Michael Richardson wrote: >>>> >>>> Joel M. Halpern wrote: >>>>> This distinction is supported in the sense that redirection permits it >>>>> happen. But determining how a device would decide to redirect vs answer, and >>>>> how the policy system would cause things to behave right, seems very >>>>> difficult to extract from the system. >>>> >>>> I think you are asking about scenario where device A asks device B for some >>>> space, but... while device B has some space, and it could allocate it, >>>> topologically it might make more sense for device B to redirect device A to >>>> device C, which has a larger pool. >>>> >>>> >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> -= IPv6 IoT consulting =- >>>> >>>> >>>> >>> >> > From nobody Mon Jan 25 03:41:26 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5491A8AA4; Mon, 25 Jan 2016 03:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usbCRhURbTg3; Mon, 25 Jan 2016 03:41:22 -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 EE3B71A8AB7; Mon, 25 Jan 2016 03:41:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDK68648; Mon, 25 Jan 2016 11:41:19 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 25 Jan 2016 11:41:17 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.62]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Mon, 25 Jan 2016 19:41:13 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Potential ANIMA interim meeting/workshop Thread-Index: AdFXZUrxKYyhiNRGTsizQ+RIFS1olA== Date: Mon, 25 Jan 2016 11:41:13 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C61AF49@NKGEML515-MBS.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.84.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A609DF.0114, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.62, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: df6365225e50c19839dfbf70d672a1f2 Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: [Anima] Potential ANIMA interim meeting/workshop X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 11:41:24 -0000 Hi, Anima, We did talk about a potential ANIMA interim meeting/workshop for a while, s= o that we can have an opportunity to discuss wide topic regarding to autono= mic network and potential next steps or next work items. Although the ANIMA= chairs does arrange second sessions in every IETF meeting, one more meetin= g/workshop with less restriction of current charter would be helpful. Now, there is a good possibility to have a such interim meeting/workshop of= at EUCNC conference, which have the "Autonomic network management" in thei= r track (http://www.eucnc.eu/?q=3Dnode/70). The time is in June 27 in Athen= s Greece. It is a good time we could discuss potential work item for our ne= xt charter too. The date for workshop proposals submission deadline is Feb. 5th. So, if we = want to do so, we need to work on an proposal as soon as possible. How do y= ou think?=20 Best regards, =20 Sheng= From nobody Mon Jan 25 22:28:23 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2A51B2F8C; Mon, 25 Jan 2016 22:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4McofKpXP0yd; Mon, 25 Jan 2016 22:28: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 949171B2F8B; Mon, 25 Jan 2016 22:28:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHL04966; Tue, 26 Jan 2016 06:28:15 +0000 (GMT) Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 06:28:14 +0000 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, 26 Jan 2016 06:28:14 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.62]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 26 Jan 2016 14:28:11 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Potential ANIMA interim meeting/workshop Thread-Index: AdFXZUrxKYyhiNRGTsizQ+RIFS1olAAnMCeQ Date: Tue, 26 Jan 2016 06:28:10 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C61B4AE@NKGEML515-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927C61AF49@NKGEML515-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927C61AF49@NKGEML515-MBS.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.86.36] 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.0A020206.56A71200.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.62, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dade4fcd84746ad34deb1f53d03aac05 Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Potential ANIMA interim meeting/workshop X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 06:28:22 -0000 Hi, ANIMA, Since I did receive some questions/concerns from a couple of people after m= y privious email, I feel more clarification is needed. What I proposed is an unusual interim meeting of IETF WG. Normally, the int= erim meetings of IETF WG are used to discuss ongoing work item in order to = accelerate the progress on them. That's not the case for us. ANIMA WG are r= unning on a right track. For the current status, I don't think we necessari= ly need an interim meeting. So, the interim meeting that I proposed is a pr= e-research meeting for wider autonomic network topics, some of which may be= come the work items for our next charter. So, it is indeed a IRTF-style mee= ting. In the case if there are rejections for such workshop to be hold as a= n ANIMA interim meeting, it may be possible to hold this meeting as an NMRG= meeting, which did dedicate two meetings for autonomic network before ANIM= A formed. For this unusual interim meeting, I think half day (4 hours) are = proper. Regarding to the interim meeting fees, I am checking with the organizer of = EUCNC conference. I expect be less for participants who do not plan to atte= nd the other part of the conference. There may be even more other concerns too. We would like to know these conc= erns and make discussion/clarifications, then have the best choice after it= . Many thanks and best regards, Sheng ________________________________________ From: Sheng Jiang Sent: 25 January 2016 19:41 To: anima@ietf.org Cc: Toerless Eckert; anima-chairs@ietf.org Subject: Potential ANIMA interim meeting/workshop Hi, Anima, We did talk about a potential ANIMA interim meeting/workshop for a while, s= o that we can have an opportunity to discuss wide topic regarding to autono= mic network and potential next steps or next work items. Although the ANIMA= chairs does arrange second sessions in every IETF meeting, one more meetin= g/workshop with less restriction of current charter would be helpful. Now, there is a good possibility to have a such interim meeting/workshop of= at EUCNC conference, which have the "Autonomic network management" in thei= r track (http://www.eucnc.eu/?q=3Dnode/70). The time is in June 27 in Athen= s Greece. It is a good time we could discuss potential work item for our ne= xt charter too. The date for workshop proposals submission deadline is Feb. 5th. So, if we = want to do so, we need to work on an proposal as soon as possible. How do y= ou think? Best regards, Sheng= From nobody Tue Jan 26 18:20:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0121B33CC for ; Tue, 26 Jan 2016 18:20:43 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe,Briggs.py X-Spam-Flag: NO X-Spam-Score: 3.444 X-Spam-Level: *** X-Spam-Status: No, score=3.444 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FILL_THIS_FORM_FRAUD_PHISH=0.334, FREEMAIL_FROM=0.001, J_CHICKENPOX_19=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 qvwTg_eOB1UX for ; Tue, 26 Jan 2016 18:20:40 -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 B86C41ACDC8 for ; Tue, 26 Jan 2016 18:20:40 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id n128so108927094pfn.3 for ; Tue, 26 Jan 2016 18:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:organization:subject:message-id:date:user-agent :mime-version:content-type; bh=F1qztqk/GpxZ/Q/RFkbCbw2B+dKfvv6X6+qbtz86Ysc=; b=dDsGYpDzKfajmArNNE+2Vojzo5n8DBi003RcY6mTifaIWNSk7vQMYvTC5TFBE0ueZz Tot2lj0ZRog3F5OOcqBjTQuQW99zEjxOl0JtD+7JLyGkOswl+L4VOcY7JX0OvA8qNHbD xGp5w1Yi6QX/+wp7ho5X3UUr021fKk0Ak11L19PCeej6RsFpAORUGsCwtFnsS8YIrKMx YBRTDsAqgtiAl8SXmhYyLda/SU5Y3cZrE4MmN/Hgwt7F19xE+peFxpyV03Ftq3+aFrFH o3+PyiAl41j9+9DRrBR4rcj1s/1+u6MYtRlNH47/hfy3gji2LnSo5oA39OA4dh12X4bR HzmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:organization:subject:message-id:date :user-agent:mime-version:content-type; bh=F1qztqk/GpxZ/Q/RFkbCbw2B+dKfvv6X6+qbtz86Ysc=; b=JkTHzWjnL/Pt+D0cMUqGBvOZ458a7KZCQTON5IfWQrBe7avS6g9SRXvMBm6wNTk+sE Gz0ySOE7/GngUPWG+lOFKphvFef8wydER+TrnfciGq0c0bmEsNOb//5zEA5JgVdCQs4W ENCG4kC1d6MKgMa4YbqPbUSsjbh4zvttz7SLORB7ZqoS1kbpdJr6U/3ujHkS6mx/nu6r 0yKYg91Ezc1xbcn546j7jXQ7EUwqQ9GKoZNot3JPJq++6+iJYCS1Cv5+91t6p06NT0NY 3F/RT4VLFQMxYnZd66AOT18w/rMaael5HMeRZgjey8DpXjMIyLIhIBX6LbnVia7qcE2w AGZg== X-Gm-Message-State: AG10YORpYPiO86VH3SYo+9yaxLNuuN2v3M8UDcpsvsT59Gqxj1Zy7/Hkt4aqHideBwgQKA== X-Received: by 10.98.9.75 with SMTP id e72mr38103822pfd.29.1453861240450; Tue, 26 Jan 2016 18:20:40 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o4sm4584187pfa.85.2016.01.26.18.20.36 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 18:20:38 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A8297A.4080802@gmail.com> Date: Wed, 27 Jan 2016 15:20:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080203080603090906080204" Archived-At: Subject: [Anima] Grasp progress X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2016 02:20:43 -0000 This is a multi-part message in MIME format. --------------080203080603090906080204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, The main reason I've been silent on the Anima list recently is that I've been waiting for people to review https://tools.ietf.org/html/draft-ietf-anima-grasp-02. We really do need to discuss the open issues. However, I have been amusing myself with the prototype code. It's hard to mount a complete test without a quite complex lab setup, but a few minutes ago I did succeed in getting two ASAs to negotiate with each other between a Linux box in the lab at the University of Auckland and my Windows box at home a few kilometres away. Yes, I had to fake discovery for that to work, but I had discovery working on the LAN in the lab yesterday. So, just now ASA Briggs and ASA Gray negotiated with other, with Gray asking Briggs for dollars and Briggs offering less than requested (i.e. this is the toy example used as slideware several IETFs ago). I need to do more tests in the lab when I can, because there are a few failures that I don't understand (but they prove that the model is quite robust, since both Briggs and Gray keep on negotiating after the failures). Quite soon I will feel comfortable putting the code on GitHub. I've attached Briggs and Gray as a teaser. Some interesting discoveries on the way about using sockets in Python and about how the lab switch apparently blocks ff02::114. Also discovered that my home gateway really does block incoming TCP unless you tell it not to. But GRASP has now run over the open IPv6 Internet, with absolutely no security. If anyone has a prototype ACP I'd love to know. Anyway - please read the draft. Now that we have some running code, which is easy to update because it's all Python, we should be able to settle the open issues and test them out very quickly. Brian --------------080203080603090906080204 Content-Type: text/plain; charset=UTF-8; name="Briggs.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Briggs.py" IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMw0KIyAtKi0gY29kaW5nOiB1dGYtOCAtKi0NCg0KaW1w b3J0IGdyYXNwDQppbXBvcnQgdGhyZWFkaW5nDQppbXBvcnQgdGltZQ0KaW1wb3J0IGRhdGV0 aW1lDQoNCmdyYXNwLnRwcmludCgiQVNBIEJyaWdncyBpcyBzdGFydGluZyB1cCIpICAgICAg ICANCg0KZ3Jhc3AudGVzdF9tb2RlID0gVHJ1ZSAjIHRlbGwgZXZlcnlib2R5IGl0J3MgYSB0 ZXN0DQp0aW1lLnNsZWVwKDEpICMganVzdCB0byBhdm9pZCBtaXhlZCB1cCBwcmludCBvdXRw dXQNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIFJlZ2lzdGVy IEFTQS9vYmplY3RpdmVzDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN Cg0KX29rLF9hc2Ffbm9uY2UgPSBncmFzcC5yZWdpc3Rlcl9hc2EoIkJyaWdncyIpDQppZiBf b2s6DQogICAgZ3Jhc3AudHByaW50KCJBU0EgQnJpZ2dzIHJlZ2lzdGVyZWQgT0siKQ0KZWxz ZToNCiAgICBleGl0KCkNCiAgICANCl9vYmoxID0gZ3Jhc3Aub2JqZWN0aXZlKCJFWDEiKQ0K X29iajEubG9vcF9jb3VudCA9IDQNCl9vYmoxLnN5bmNoID0gVHJ1ZQ0KDQpfb2ssIF90ZW1w ID0gZ3Jhc3AucmVnaXN0ZXJfb2JqKF9hc2Ffbm9uY2UsX29iajEpDQppZiBfb2s6DQogICAg Z3Jhc3AudHByaW50KCJPYmplY3RpdmUgRVgxIHJlZ2lzdGVyZWQgT0siKQ0KZWxzZToNCiAg ICBleGl0KCkNCg0KX29iajIgPSBncmFzcC5vYmplY3RpdmUoIkVYMiIpDQpfb2JqMi5sb29w X2NvdW50ID0gNA0KX29iajIuc3luY2ggPSBUcnVlDQoNCl9vaywgX3RlbXAgPSBncmFzcC5y ZWdpc3Rlcl9vYmooX2FzYV9ub25jZSxfb2JqMikNCmlmIF9vazoNCiAgICBncmFzcC50cHJp bnQoIk9iamVjdGl2ZSBFWDIgcmVnaXN0ZXJlZCBPSyIpDQplbHNlOg0KICAgIGV4aXQoKQ0K DQpfb2JqMyA9IGdyYXNwLm9iamVjdGl2ZSgiRVgzIikNCl9vYmozLm5lZyA9IFRydWUNCg0K X29rLCBfdGVtcCA9IGdyYXNwLnJlZ2lzdGVyX29iaihfYXNhX25vbmNlLF9vYmozKQ0KaWYg X29rOg0KICAgIGdyYXNwLnRwcmludCgiT2JqZWN0aXZlIEVYMyByZWdpc3RlcmVkIE9LIikN CmVsc2U6DQogICAgZXhpdCgpDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIw0KIyBGbG9vZCBFWDEgcmVwZWF0ZWRseQ0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjDQoNCmNsYXNzIF9mbG9vZGVyKHRocmVhZGluZy5UaHJlYWQpOg0KICAg ICIiIlRocmVhZCB0byBmbG9vZCBFWDEgcmVwZWF0ZWRseSIiIg0KICAgIGRlZiBfX2luaXRf XyhzZWxmKToNCiAgICAgICAgdGhyZWFkaW5nLlRocmVhZC5fX2luaXRfXyhzZWxmKQ0KDQog ICAgZGVmIHJ1bihzZWxmKToNCiAgICAgICAgd2hpbGUgVHJ1ZToNCiAgICAgICAgICAgIHRp bWUuc2xlZXAoNjApDQogICAgICAgICAgICBfb2JqMS52YWx1ZSA9IGRhdGV0aW1lLmRhdGV0 aW1lLm5vdygpLnN0cmZ0aW1lKCIlWS0lbS0lZCAlSDolTSIpDQogICAgICAgICAgICBncmFz cC5mbG9vZChfYXNhX25vbmNlLCBfb2JqMSkNCiAgICAgICAgICAgIHRpbWUuc2xlZXAoMSkN CiAgICAgICAgICAgIGR1bXBfc29tZSgpDQoNCl9mbG9vZGVyKCkuc3RhcnQoKQ0KZ3Jhc3Au dHByaW50KCJGbG9vZGluZyBFWDEgZm9yIGV2ZXIiKQ0KDQojIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIw0KIyBMaXN0ZW4gU3luY2hyb25pemUgRVgyDQojIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KDQpfb2JqMi52YWx1ZSA9IFsxLCJ0d28iLDNd DQpfb2ssIF9yZXN1bHQgPSBncmFzcC5saXN0ZW5fc3luY2hyb25pemUoX2FzYV9ub25jZSwg X29iajIpDQpncmFzcC50cHJpbnQoIkxpc3RlbiBzeW5jaCBFWDIiLCBfb2ssIF9yZXN1bHQp DQoNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMgUHJpbnQgb2Jq X3JlZ2lzdHJ5IGFuZCBmbG9vZCBjYWNoZQ0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMNCg0KZGVmIGR1bXBfc29tZSgpOg0KICAgIGdyYXNwLnRwcmludCgiT2JqZWN0 aXZlIHJlZ2lzdHJ5IGNvbnRlbnRzOiIpICAgICAgICAgDQogICAgZm9yIHggaW4gZ3Jhc3Au X29ial9yZWdpc3RyeToNCiAgICAgICAgbz0geC5vYmplY3RpdmUNCiAgICAgICAgZ3Jhc3Au dHByaW50KG8ubmFtZSwiQVNBOiIseC5hc2FfaWQsIkxpc3RlbjoiLHgubGlzdGVuaW5nLCJO ZWc6IixvLm5lZywNCiAgICAgICAgICAgICAgICJTeW5jaDoiLG8uc3luY2gsIkNvdW50OiIs by5sb29wX2NvdW50LCJWYWx1ZToiLG8udmFsdWUpDQogICAgZ3Jhc3AudHByaW50KCJGbG9v ZCBjYWNoZSBjb250ZW50czoiKSAgICAgICAgICAgIA0KICAgIGZvciB4IGluIGdyYXNwLl9m bG9vZF9jYWNoZToNCiAgICAgICAgZ3Jhc3AudHByaW50KHgubmFtZSwiY291bnQ6Iix4Lmxv b3BfY291bnQsInZhbHVlOiIsIHgudmFsdWUpDQogICAgdGltZS5zbGVlcCg1KQ0KDQpkdW1w X3NvbWUoKQ0KDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBOZWdv dGlhdGUgRVgzIGFzIGxpc3RlbmVyIGZvciBldmVyDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIw0KDQpfb2JqMy52YWx1ZSA9IFsiTlpEIiwwXQ0KDQp3aGlsZSBUcnVl Og0KICAgICNzdGFydCBvZiBhIG5lZ290aWF0aW5nIHNlc3Npb24NCg0KICAgICNjcmVhdGUg YSByYW5kb20gYW1vdW50IG9mIHJlc291cmNlIGFuZCBhIHJhbmRvbSB3YWl0aW5nIHRpbWUN CiAgICByZXNlcnZlcyA9IGdyYXNwLl9wcm5nLnJhbmRpbnQoMTAwLCA0MDApDQogICAgd3Qg PSBncmFzcC5fcHJuZy5yYW5kaW50KDE1MDAwLCA0MDAwMCkNCiAgICBncmFzcC50cHJpbnQo IlJlc2VydmVzOiAkIixyZXNlcnZlcywgIndhaXQ6Iix3dCkNCiAgICANCiAgICAjYXR0ZW1w dCB0byBsaXN0ZW4gZm9yIG5lZ290aWF0aW9uDQogICAgb2ssIHNub25jZSwgYW5zd2VyID0g Z3Jhc3AubGlzdGVuX25lZ290aWF0ZShfYXNhX25vbmNlLCBfb2JqMykNCiAgICBpZiBub3Qg b2s6DQogICAgICAgIGdyYXNwLnRwcmludCgibGlzdGVuX25lZ290aWF0ZSBlcnJvcjoiLGFu c3dlcikNCiAgICAgICAgdGltZS5zbGVlcCg1KSAjdG8gY2FsbSB0aGluZ3MgaWYgdGhlcmUn cyBhIGxvb3BpbmcgZXJyb3INCiAgICBlbHNlOg0KICAgICAgICBncmFzcC50cHJpbnQoImxp c3RlbmVkLCBhbnN3ZXIiLGFuc3dlci5uYW1lLCBhbnN3ZXIudmFsdWUpDQogICAgICAgIHJl c3VsdD1UcnVlDQogICAgICAgIHJlYXNvbj1Ob25lICAgICAgIA0KICAgICAgICANCiAgICAg ICAgaWYgYW5zd2VyLnZhbHVlWzBdIT0iTlpEIjoNCiAgICAgICAgICAgIHJlc3VsdD1GYWxz ZQ0KICAgICAgICAgICAgcmVhc29uPSJJbnZhbGlkIGN1cnJlbmN5Ig0KICAgICAgICBlbGlm IGFuc3dlci52YWx1ZVsxXSA+IHJlc2VydmVzLzI6DQogICAgICAgICAgICAjb3RoZXIgZW5k IHdhbnRzIHRvbyBtdWNoLCB3ZSBuZWVkIHRvIG5lZ290aWF0ZQ0KICAgICAgICAgICAgcHJv ZmZlciA9IGludChyZXNlcnZlcy8yKQ0KICAgICAgICAgICAgc3RlcCA9IDENCiAgICAgICAg ICAgIGNvbmNsdWRlZCA9IEZhbHNlDQogICAgICAgICAgICB3aGlsZSBub3QgY29uY2x1ZGVk Og0KICAgICAgICAgICAgICAgICNwcm9mZmVyIHNvbWUgcmVzb3VyY2UNCiAgICAgICAgICAg ICAgICBfb2JqMy52YWx1ZVsxXSA9IHByb2ZmZXINCiAgICAgICAgICAgICAgICBvayx0ZW1w LGFuc3dlciA9IGdyYXNwLm5lZ290aWF0ZV9zdGVwKF9hc2Ffbm9uY2UsIHNub25jZSwgX29i ajMsIDEwMDApDQogICAgICAgICAgICAgICAgZ3Jhc3AudHByaW50KCJTdGVwIiwgc3RlcCwg ImdhdmU6Iiwgb2ssIHRlbXAsIGFuc3dlcikNCiAgICAgICAgICAgICAgICBpZiBvayBhbmQg bm90IHRlbXA6DQogICAgICAgICAgICAgICAgICAgIGNvbmNsdWRlZCA9IFRydWUNCiAgICAg ICAgICAgICAgICAgICAgZ3Jhc3AudHByaW50KCJOZWdvdGlhdGlvbiBzdWNjZWVkZWQiLCBh bnN3ZXIudmFsdWUpICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICBlbGlmIG9r Og0KICAgICAgICAgICAgICAgICAgICAjd2FpdCAoZm9yIG5vIHBhcnRpY3VsYXIgcmVhc29u KQ0KICAgICAgICAgICAgICAgICAgICBvazEsYW5zd2VyID0gZ3Jhc3AubmVnb3RpYXRlX3dh aXQoX2FzYV9ub25jZSwgc25vbmNlLCB3dCkNCiAgICAgICAgICAgICAgICAgICAgZ3Jhc3Au dHByaW50KCJUcmllZCB3YWl0OiIsIG9rMSwgYW5zd2VyKQ0KICAgICAgICAgICAgICAgICAg ICB0aW1lLnNsZWVwKDIwKSAjbm90ZSAtIGlmIHd0PDIwMDAwIHRoaXMgdGVzdHMgYW5vbWFs eSBoYW5kbGluZw0KICAgICAgICAgICAgICAgICAgICBncmFzcC50cHJpbnQoIldva2UgdXAi KQ0KICAgICAgICAgICAgICAgICAgICBpZiBwcm9mZmVyIDwgMC45KnJlc2VydmVzLTE1Og0K ICAgICAgICAgICAgICAgICAgICAgICAgcHJvZmZlciArPSAxMA0KICAgICAgICAgICAgICAg ICAgICBlbHNlOg0KICAgICAgICAgICAgICAgICAgICAgICAgI3dlIGRvbid0IGhhdmUgZW5v dWdoIHJlc291cmNlLCB3ZSB3aWxsIHJlamVjdA0KICAgICAgICAgICAgICAgICAgICAgICAg cmVzdWx0PUZhbHNlDQogICAgICAgICAgICAgICAgICAgICAgICAjcmFuZG9tbHkgY2hvb3Nl IEVuZ2xpc2ggb3IgUnVzc2lhbiBlcnJvciBtZXNzYWdlDQogICAgICAgICAgICAgICAgICAg ICAgICBpZiByZXNlcnZlcyUyOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYXNv bj0iSW5zdWZmaWNpZW50IGZ1bmRzIg0KICAgICAgICAgICAgICAgICAgICAgICAgZWxzZToN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWFzb249dSLQndC10LTQvtGB0YLQsNGC 0L7Rh9C90L4g0YHRgNC10LTRgdGC0LIiICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgIGVsc2U6ICAgIA0KICAgICAgICAgICAgICAgICAgICAjb3RoZXIgZW5kIHJlamVj dGVkDQogICAgICAgICAgICAgICAgICAgIGNvbmNsdWRlZD1UcnVlDQogICAgICAgICAgICAg ICAgICAgIGdyYXNwLnRwcmludCgiUGVlciByZWplY3Q6IixhbnN3ZXIpICAgICAgICAgICAN CiAgICAgICAgICAgICAgICBpZiBub3QgY29uY2x1ZGVkOg0KICAgICAgICAgICAgICAgICAg ICBvaywgYW5zd2VyID0gZ3Jhc3AuZW5kX25lZ290aWF0ZShfYXNhX25vbmNlLCBzbm9uY2Us IHJlc3VsdCwgcmVhc29uPXJlYXNvbikNCiAgICAgICAgICAgICAgICAgICAgaWYgbm90IG9r Og0KICAgICAgICAgICAgICAgICAgICAgICAgZ3Jhc3AudHByaW50KCJlbmRfbmVnb3RpYXRl IGVycm9yOiIsYW5zd2VyKQ0KICAgICAgICAgICAgICAgICAgICBjb25jbHVkZWQgPSBUcnVl DQogICAgICAgICAgICAjZW5kIG9mIG5lZ290aWF0aW9uIHJlYWNoZWQNCiAgICAgICAgICAg IGNvbnRpbnVlDQogICAgICAgIGVsc2U6ICN3ZSBjYW4gYWNjZXB0IHRoZSBpbml0aWFsbHkg cmVxdWVzdGVkIHZhbHVlDQogICAgICAgICAgICBwYXNzDQogICAgICAgIG9rLCBhbnN3ZXIg PSBncmFzcC5lbmRfbmVnb3RpYXRlKF9hc2Ffbm9uY2UsIHNub25jZSwgcmVzdWx0LCByZWFz b249cmVhc29uKQ0KICAgICAgICBpZiBub3Qgb2s6DQogICAgICAgICAgICBncmFzcC50cHJp bnQoImVuZF9uZWdvdGlhdGUgZXJyb3I6IixhbnN3ZXIpDQogICAgI2VuZCBvZiBhIG5lZ290 aWF0aW5nIHNlc3Npb24NCg== --------------080203080603090906080204 Content-Type: text/plain; charset=UTF-8; name="Gray.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Gray.py" IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMw0KIyAtKi0gY29kaW5nOiB1dGYtOCAtKi0NCg0KaW1w b3J0IGdyYXNwDQppbXBvcnQgdGhyZWFkaW5nDQppbXBvcnQgdGltZQ0KaW1wb3J0IGRhdGV0 aW1lDQppbXBvcnQgaXBhZGRyZXNzDQoNCmdyYXNwLnRwcmludCgiQVNBIEdyYXkgaXMgc3Rh cnRpbmcgdXAiKSAgICAgICAgDQoNCmdyYXNwLnRlc3RfbW9kZSA9IFRydWUgIyB0ZWxsIGV2 ZXJ5Ym9keSBpdCdzIGEgdGVzdA0KdGltZS5zbGVlcCgxKSAjIGp1c3QgdG8gYXZvaWQgbWl4 ZWQgdXAgcHJpbnQgb3V0cHV0DQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIw0KIyBGYWtlIGRpc2NvdmVyeSBmb3IgcmVtb3RlIHRlc3RpbmcNCiMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KDQpncmFzcC50cHJpbnQoIkdpbW1lIHBlZXIn cyB2NiBhZGRyZXNzIikNCl9sID0gaW5wdXQoKQ0KdHJ5Og0KICAgIF9sID0gaXBhZGRyZXNz LklQdjZBZGRyZXNzKF9sKQ0KZXhjZXB0Og0KICAgIGdyYXNwLnRwcmludCgiT0ssIEknbGwg dHJ5IG5vcm1hbCBkaXNjb3ZlcnkiKQ0KICAgIF9sID0gRmFsc2UNCg0KIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIFJlZ2lzdGVyIEFTQS9vYmplY3RpdmVzDQoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCg0KX29rLF9hc2Ffbm9uY2Ug PSBncmFzcC5yZWdpc3Rlcl9hc2EoIkdyYXkiKQ0KaWYgX29rOg0KICAgIGdyYXNwLnRwcmlu dCgiQVNBIEdyYXkgcmVnaXN0ZXJlZCBPSyIpDQplbHNlOg0KICAgIGV4aXQoKQ0KDQojVGhp cyBvYmplY3RpdmUgaXMgZm9yIHRoZSBmbG9vZGluZyB0ZXN0DQojc28gZG9lc24ndCBuZWVk IHRvIGJlIHJlZ2lzdGVyZWQNCl9vYmoxID0gZ3Jhc3Aub2JqZWN0aXZlKCJFWDEiKQ0KX29i ajEubG9vcF9jb3VudCA9IDQNCl9vYmoxLnN5bmNoID0gVHJ1ZQ0KDQojVGhpcyBvYmplY3Rp dmUgaXMgZm9yIHRoZSBzeW5jaHJvbml6aW5nIHRlc3QNCiNzbyBkb2Vzbid0IG5lZWQgdG8g YmUgcmVnaXN0ZXJlZA0KX29iajIgPSBncmFzcC5vYmplY3RpdmUoIkVYMiIpDQpfb2JqMi5s b29wX2NvdW50ID0gNA0KX29iajIuc3luY2ggPSBUcnVlDQoNCiNUaGlzIG9iamVjdGl2ZSBp cyBmb3IgdGhlIG5lZ290aWF0aW5nIHRlc3QNCl9vYmozID0gZ3Jhc3Aub2JqZWN0aXZlKCJF WDMiKQ0KX29iajMubmVnID0gVHJ1ZQ0KDQpfb2ssIF90ZW1wID0gZ3Jhc3AucmVnaXN0ZXJf b2JqKF9hc2Ffbm9uY2UsX29iajMpDQppZiBfb2s6DQogICAgZ3Jhc3AudHByaW50KCJPYmpl Y3RpdmUgRVgzIHJlZ2lzdGVyZWQgT0siKQ0KZWxzZToNCiAgICBleGl0KCkNCg0KaWYgX2w6 DQogICAgI2Zha2UgZGlzY292ZXJ5DQogICAgX2FfbCA9IGdyYXNwLmFzYV9sb2NhdG9yKF9s LDAsRmFsc2UpDQogICAgX2FfbC5pc19pcGFkZHJlc3MgPSBUcnVlDQogICAgX2RfbyA9IGdy YXNwLl9kaXNjb3ZlcmVkX29iamVjdGl2ZShfb2JqMyxbX2FfbF0pDQogICAgZ3Jhc3AuX2Rp c2NvdmVyeV9jYWNoZS5hcHBlbmQoX2RfbykNCiAgICANCg0KDQojIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBUcnkgc3luY2hyb25pemVzDQojIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KDQp0aW1lLnNsZWVwKDUpDQoNCl9vaywgX3Jlc3Vs dCA9IGdyYXNwLnN5bmNocm9uaXplKF9hc2Ffbm9uY2UsIF9vYmoxLCBOb25lLCA1MDAwKQ0K aWYgX29rOg0KICAgIGdyYXNwLnRwcmludCgiU3luY2hyb25pemVkIEVYMSIsIF9yZXN1bHQu dmFsdWUpDQplbHNlOg0KICAgIGdyYXNwLnRwcmludCgiU3luY2ggZmFpbGVkIEVYMSIsIF9y ZXN1bHQpDQoNCl9vaywgX3Jlc3VsdCA9IGdyYXNwLnN5bmNocm9uaXplKF9hc2Ffbm9uY2Us IF9vYmoyLCBOb25lLCA1MDAwKQ0KaWYgX29rOg0KICAgIGdyYXNwLnRwcmludCgiU3luY2hy b25pemVkIEVYMiIsIF9yZXN1bHQudmFsdWUpDQplbHNlOg0KICAgIGdyYXNwLnRwcmludCgi U3luY2ggZmFpbGVkIEVYMiIsIF9yZXN1bHQpICAgIA0KDQogIA0KI1RoaXMgc2hvdWxkIGZh aWwgYXMgdGVzdF9vYmogd2FzIG5laXRoZXIgZmxvb2RlZCBvciBsaXN0ZW5lZCBmb3IuDQpf dGVzdF9vYmogPSBncmFzcC5vYmplY3RpdmUoIk5vbnNlbnNlIikNCl9vaywgX3Jlc3VsdCA9 IGdyYXNwLnN5bmNocm9uaXplKF9hc2Ffbm9uY2UsIF90ZXN0X29iaiwgTm9uZSwgNTAwMCkN CmlmIF9vazoNCiAgICBncmFzcC50cHJpbnQoIlN5bmNocm9uaXplZCBOb25zZW5zZSAoc2hv dWxkIGZhaWwpIiwgX3Jlc3VsdC52YWx1ZSkNCmVsc2U6DQogICAgZ3Jhc3AudHByaW50KCJT eW5jaCBmYWlsZWQgTm9uc2Vuc2UgKHNob3VsZCBmYWlsKSIsIF9yZXN1bHQpDQoNCiNyZXBl YXQNCl9vaywgX3Jlc3VsdCA9IGdyYXNwLnN5bmNocm9uaXplKF9hc2Ffbm9uY2UsIF9vYmoy LCBOb25lLCA1MDAwKQ0KaWYgX29rOg0KICAgIGdyYXNwLnRwcmludCgiU3luY2hyb25pemVk IEVYMiIsIF9yZXN1bHQudmFsdWUpDQplbHNlOg0KICAgIGdyYXNwLnRwcmludCgiU3luY2gg ZmFpbGVkIEVYMiIsIF9yZXN1bHQpDQogICAgDQojcmVwZWF0DQpfb2ssIF9yZXN1bHQgPSBn cmFzcC5zeW5jaHJvbml6ZShfYXNhX25vbmNlLCBfb2JqMSwgTm9uZSwgNTAwMCkNCmlmIF9v azoNCiAgICBncmFzcC50cHJpbnQoIlN5bmNocm9uaXplZCBFWDEiLCBfcmVzdWx0LnZhbHVl KQ0KZWxzZToNCiAgICBncmFzcC50cHJpbnQoIlN5bmNoIGZhaWxlZCBFWDEiLCBfcmVzdWx0 KQ0KDQogICAgICAgICAgIA0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN CiMgUHJpbnQgb2JqX3JlZ2lzdHJ5IGFuZCBmbG9vZCBjYWNoZQ0KIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMNCg0KZGVmIGR1bXBfc29tZSgpOg0KICAgIGdyYXNwLnRw cmludCgiT2JqZWN0aXZlIHJlZ2lzdHJ5IGNvbnRlbnRzOiIpICAgICAgICAgDQogICAgZm9y IHggaW4gZ3Jhc3AuX29ial9yZWdpc3RyeToNCiAgICAgICAgbz0geC5vYmplY3RpdmUNCiAg ICAgICAgZ3Jhc3AudHByaW50KG8ubmFtZSwiQVNBOiIseC5hc2FfaWQsIkxpc3RlbjoiLHgu bGlzdGVuaW5nLCJOZWc6IixvLm5lZywNCiAgICAgICAgICAgICAgICJTeW5jaDoiLG8uc3lu Y2gsIkNvdW50OiIsby5sb29wX2NvdW50LCJWYWx1ZToiLG8udmFsdWUpDQogICAgZ3Jhc3Au dHByaW50KCJGbG9vZCBjYWNoZSBjb250ZW50czoiKSAgICAgICAgICAgIA0KICAgIGZvciB4 IGluIGdyYXNwLl9mbG9vZF9jYWNoZToNCiAgICAgICAgZ3Jhc3AudHByaW50KHgubmFtZSwi Y291bnQ6Iix4Lmxvb3BfY291bnQsInZhbHVlOiIsIHgudmFsdWUpDQogICAgdGltZS5zbGVl cCg1KQ0KDQpkdW1wX3NvbWUoKQ0KDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIw0KIyBOZWdvdGlhdGUgRVgzIGFzIGluaXRpYXRvciBmb3IgZXZlcg0KIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCg0Kd2hpbGUgVHJ1ZToNCiAgICAjc3RhcnQg b2YgYSBuZWdvdGlhdGluZyBzZXNzaW9uDQogICAgaXdhbnQgPSBncmFzcC5fcHJuZy5yYW5k aW50KDEwLCA1MDApDQogICAgZ3Jhc3AudHByaW50KCJBc2tpbmcgZm9yICQiLGl3YW50KQ0K ICAgIF9vYmozLnZhbHVlID0gWyJOWkQiLGl3YW50XQ0KICAgIF9vYmozLmxvb3BfY291bnQg PSA1DQogICAgaWYgbm90IGl3YW50JTc6DQogICAgICAgIF9vYmozLnZhbHVlWzBdID0gIlVT RCIgICMgcmFuZG9tIGVycm9yIGZvciB0ZXN0aW5nIHB1cnBvc2VzDQogICAgI2Rpc2NvdmVy IGEgcGVlcg0KICAgIGxsID0gZ3Jhc3AuZGlzY292ZXIoX2FzYV9ub25jZSwgX29iajMsIDUw MDApDQogICAgaWYgbGw9PVtdOg0KICAgICAgICBncmFzcC50cHJpbnQoIkRpc2NvdmVyeSBm YWlsZWQiKQ0KICAgICAgICBjb250aW51ZQ0KICAgIGdyYXNwLnRwcmludCgiRGlzY292ZXJl ZCBsb2NhdG9yIiwgbGxbMF0ubG9jYXRvcikNCiAgICAjYXR0ZW1wdCB0byBuZWdvdGlhdGUN CiAgICBvaywgc25vbmNlLCBhbnN3ZXIgPSBncmFzcC5yZXFfbmVnb3RpYXRlKF9hc2Ffbm9u Y2UsIF9vYmozLCBsbFswXSwgTm9uZSkNCiAgICBpZiBub3Qgb2s6DQogICAgICAgIGdyYXNw LnRwcmludCgicmVxX25lZ290aWF0ZSBlcnJvcjoiLGFuc3dlcikNCiAgICAgICAgdGltZS5z bGVlcCg1KSAjdG8gY2FsbSB0aGluZ3MgaWYgdGhlcmUncyBhIGxvb3BpbmcgZXJyb3INCiAg ICBlbGlmIG9rIGFuZCBzbm9uY2U6DQogICAgICAgIGdyYXNwLnRwcmludCgicmVxdWVzdGVk LCBzZXNzaW9uX25vbmNlOiIsc25vbmNlLCJhbnN3ZXIiLGFuc3dlcikNCiAgICAgICAgcHJv ZmZlciA9IDAuOSppd2FudA0KICAgICAgICBsaW1pdCA9IDAuNSppd2FudA0KICAgICAgICBz dGVwID0gMQ0KICAgICAgICBpZiBhbnN3ZXIudmFsdWVbMV08cHJvZmZlcjogDQogICAgICAg ICAgICAjbmVlZCB0byBuZWdvdGlhdGUNCiAgICAgICAgICAgIF9vYmozLnZhbHVlID0gcHJv ZmZlcg0KICAgICAgICAgICAgY29uY2x1ZGVkID0gRmFsc2UNCiAgICAgICAgICAgIHdoaWxl IG5vdCBjb25jbHVkZWQ6DQogICAgICAgICAgICAgICAgb2ssdGVtcCxhbnN3ZXIgPSBncmFz cC5uZWdvdGlhdGVfc3RlcChfYXNhX25vbmNlLCBzbm9uY2UsIF9vYmozLCAxMDAwKQ0KICAg ICAgICAgICAgICAgIGdyYXNwLnRwcmludCgiU3RlcCIsIHN0ZXAsICJnYXZlOiIsIG9rLCB0 ZW1wLCBhbnN3ZXIpDQogICAgICAgICAgICAgICAgaWYgb2sgYW5kIG5vdCB0ZW1wOg0KICAg ICAgICAgICAgICAgICAgICBncmFzcC50cHJpbnQoIk5lZ290aWF0aW9uIHN1Y2NlZWRlZCIs IGFuc3dlci52YWx1ZSkNCiAgICAgICAgICAgICAgICAgICAgY29uY2x1ZGVkID0gVHJ1ZQ0K ICAgICAgICAgICAgICAgIGVsaWYgb2s6DQogICAgICAgICAgICAgICAgICAgIHByb2ZmZXIg PSAwLjkqcHJvZmZlcg0KICAgICAgICAgICAgICAgICAgICBpZiBwcm9mZmVyIDwgbGltaXQ6 DQogICAgICAgICAgICAgICAgICAgICAgICAjbm90IGFjY2VwdGFibGUNCiAgICAgICAgICAg ICAgICAgICAgICAgIG9rLCBhbnN3ZXIgPSBncmFzcC5lbmRfbmVnb3RpYXRlKF9hc2Ffbm9u Y2UsIHNub25jZSwgRmFsc2UsIHJlYXNvbj0iWW91IGFyZSBtZWFuISIpDQogICAgICAgICAg ICAgICAgICAgICAgICBpZiBub3Qgb2s6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg Z3Jhc3AudHByaW50KCJlbmRfbmVnb3RpYXRlIGVycm9yOiIsYW5zd2VyKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgY29uY2x1ZGVkID0gVHJ1ZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgYnJlYWsNCiAgICAgICAgICAgICAgICBlbHNlOiAgICANCiAgICAgICAgICAgICAgICAg ICAgI290aGVyIGVuZCByZWplY3RlZA0KICAgICAgICAgICAgICAgICAgICBncmFzcC50cHJp bnQoIlBlZXIgcmVqZWN0OiIsYW5zd2VyKQ0KICAgICAgICAgICAgICAgICAgICBjb25jbHVk ZWQgPSBUcnVlDQogICAgICAgICAgICAgICAgICAgIGJyZWFrDQogICAgICAgIGVsc2U6ICNh Y2NlcHRhYmxlIGFuc3dlcg0KICAgICAgICAgICAgb2ssIGFuc3dlcjIgPSBncmFzcC5lbmRf bmVnb3RpYXRlKF9hc2Ffbm9uY2UsIHNub25jZSwgVHJ1ZSkNCiAgICAgICAgICAgIGlmIG9r Og0KICAgICAgICAgICAgICAgIGdyYXNwLnRwcmludCgiTmVnb3RpYXRpb24gc3VjY2VlZGVk IiwgYW5zd2VyLnZhbHVlKQ0KICAgICAgICAgICAgZWxzZToNCiAgICAgICAgICAgICAgICBn cmFzcC50cHJpbnQoImVuZF9uZWdvdGlhdGUgZXJyb3I6IixhbnN3ZXIyKQ0KICAgIGVsc2U6 ICNhY2NlcHRhYmxlIGFuc3dlciBmaXJzdCB0aW1lDQogICAgICAgIGdyYXNwLnRwcmludCgi TmVnb3RpYXRpb24gc3VjY2VlZGVkIiwgYW5zd2VyLnZhbHVlKQ0KIA0KICAgICNlbmQgb2Yg YSBuZWdvdGlhdGluZyBzZXNzaW9uDQo= --------------080203080603090906080204-- From nobody Wed Jan 27 16:26:31 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE11A00EF for ; Wed, 27 Jan 2016 16:26: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3JVVsA14Dmi for ; Wed, 27 Jan 2016 16:26:28 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71111A00EE for ; Wed, 27 Jan 2016 16:26:27 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id x125so13468004pfb.0 for ; Wed, 27 Jan 2016 16:26: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-type:content-transfer-encoding; bh=c/ibegHqMvNGWDdI8qFI6smNIRmCEzU6aBJyrUIbpGc=; b=pjivTjD2316c6K4oajLwJ0nPz1F/qvIkuS/zyvthqDYU1H99QxUk01XSPyFqIkNMJI O/aKNpnsEPoqCJi+GW+v1NKetmMEpBX/924ZjO5QGC4KmVmXvvZcex4JTEOgZ+a8tkRp QdqMIXVeoN8jIlko0W/s22x2q4uBlim9EKw4UYmUJkB4DCy2Kf0PazKVHAx8NmqOQaTN kAys6nBAbeN0igJv1nNzF7x8BsCIOLjXS4XlIIQcnB0VUfwU8GyuB8GdXCWnamr1sVdR hJt/iUZpfphjg7pEEWB4ZMEabBcYYwoDfkbChigrJ7JCaRRcggx/tD/tJBlG7y7qEV2F co7w== 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-type :content-transfer-encoding; bh=c/ibegHqMvNGWDdI8qFI6smNIRmCEzU6aBJyrUIbpGc=; b=AcYzHS1CpFRV219U0YIC0Am1dWfFankTcWvBT1jLtfffutNXMzAxrWx2HxbnXRlhxS Gp0u13Z5UylLjztkZkRZI3JMdyLQh3DKxFTF1OfOiIO82slwrb6kFZrbJ7tDiicO7MBO rAl8MSTX2v8XFuURgmcdQzKCdhrmpKpQtZU7o0xDsMosH46AXOt+IOf5fjmzZAnxr07S JUYSvXyQcavasFvtpapR0aE1zvk7sAXuWtMTa2nTgu8keuOIPlkqtcyFJu6SJ2bjkmB9 CjQ+c5W0Da7P3wY8KjpKxhfgMzlbvelngxUfUUPR2puqCkU1VlTpg89qdVB5IcyjG+Wp e/BA== X-Gm-Message-State: AG10YOTDiVe+sZF1GBVgcZMZDYGNr7Y7tf9hsZ9QOtXBv3G/y4yuoUxxKXt9jw9dxo54dA== X-Received: by 10.98.69.209 with SMTP id n78mr174080pfi.81.1453940787595; Wed, 27 Jan 2016 16:26:27 -0800 (PST) Received: from ?IPv6:2406:e007:756a:1:28cc:dc4c:9703:6781? ([2406:e007:756a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d8sm11603924pas.14.2016.01.27.16.26.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 16:26:25 -0800 (PST) To: "Liubing (Leo)" , Anima WG References: <20160113003610.7570.78040.idtracker@ietfa.amsl.com> <56959FDF.9080209@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D3D532@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A96039.3080207@gmail.com> Date: Thu, 28 Jan 2016 13:26:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D3D532@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP messages-//RE: I-D Action: draft-ietf-anima-grasp-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2016 00:26:29 -0000 Hi everybody, Since nobody else has responded, here are my comments: On 14/01/2016 15:24, Liubing (Leo) wrote: > Hi Dear all, > >> As a result there are a number of changes to the protocol. The biggest one >> was splitting the RESPONSE message into three separate messages >> (RESPONSE for discovery responses, SYNCHRONIZE for synchronization >> responses, and FLOOD for unsolicited flood messages). >> >> We need careful reviews of this version and decisions about the open issues. >> After people have had a few days to digest the document, we will start >> discussion threads on the open issues. > > [Bing] Please allow me to discuss the following open question firstly: > > 47. REQUEST is a dual purpose message (request negotiation or > request synchronization). Would it be better to split this into > two different messages (and adjust various message names > accordingly)? > > For my personal feeling, the issue is not only the overloading for both Negotiation and Synchronization, but also the violation the custom that "Request" is usually coupled with "Response" in other protocols. In GRASP, "Response" is coupled with "Discovery". > > So, if we split the REQUEST message, I think might fit more to the split RESPONSE messages (RESPONSE for discovery responses, SYNCHRONIZE for synchronization responses, and FLOOD for unsolicited flood messages), plus, with a bit renaming, the messages could be like this: > - Discovery & Discovery_Res > - Negotiation_Init & Negotiation & Negotiation_End Confirm-waiting fits here, doesn't it? I don't think we have that for synchronization, only for negotiation. > - Synchronization & Synchronization_Res > - Confirm-waiting > - Flood > Btw, the message name "Flooding message" is a very common/abstract phrase, can we find another more precise name? E.g., "Flooded Synchronization" or "Unsolicited Synchronization". > > These seem more institutive for me. What are your thought? In general, I agree. I think we can use full names in the text, like Discovery and Discovery_Response, and shorter ones in the formal (CDDL) description, like M_DISCOVER and M_DISC_RESP. Apart from that the only real change is splitting Request into two cases, and I think 'request' is fine, so I would suggest that the long names are Request_Negotiation and Request_Synchronization. The changes to the CDDL and the prototype code would be quite small. If there's no disagreement on the list, we'll plan this for the -03 draft. Brian From nobody Wed Jan 27 16:49:26 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAA71A0248 for ; Wed, 27 Jan 2016 16:49: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWOXLafmHx5B for ; Wed, 27 Jan 2016 16:49:23 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 798B61A022C for ; Wed, 27 Jan 2016 16:49:23 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id ho8so13273329pac.2 for ; Wed, 27 Jan 2016 16:49:23 -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-type:content-transfer-encoding; bh=Ck9c6ErpQ1n8bUwE2IKUzUuc6ugQOFlEwondoe5Wz10=; b=FVZwupyAFB69uYikPyhuOR/W6tsxSm7+RTofQ4S4GPqt0CqJRJ26xQucDZCB32vh+s rjuFJdKVCDqBdQPRg5fxJqSLZ2r2wxGzY1UDlYR6HgGXTlnYXWsq77Xa5UGymXojU2i3 4kh7kQBhboM0eKNOctrKPaFFDiKbU3v1MkLWDEMFjf3bpqEwJ9lsr8qRjRtCLfkIRa1S DAV2Lu3lSgyjo8WtraKNT7diI0iN9mErHteN47IKfmYVbeyBaTUCfpW0Ky5VP804qLf5 5Vne8c5dkcKNYhExYewgpfGbcKG2lngaquoqhHPc7rnIBPfbgB6jysyHThUwOoxZkCbF ETNQ== 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-type:content-transfer-encoding; bh=Ck9c6ErpQ1n8bUwE2IKUzUuc6ugQOFlEwondoe5Wz10=; b=FvhfEffQz+MBfvjCZpr4PRKw1jIt2uXXfTnOOraYyFLSAY0PaxGTq4WPPFLna8Ql4T WFO72ZGEgbt27N5S2E3JREQE/GpVhV6Viv+WSetOWbBQ5U7uGVQfECRqtw1wib0lpPIA mcnCV+IL8VGHztB3Y1OY7c0Ht8TuRgJy9c3uw9fdCyfrCXQH0f9pzLqEDEgl3y7bUA58 cWBNQVV+htenUiRzG8zKwq0agLx6rD3hix0mS6JoSMHk3FXR+9sJcbZvnmc1hQBYCNAc YCvNIbk4pCwwLlHq3jo4/Xt5KGMrZgW7iBRPCLnHGHOnpzfV1JYEQOjs5GKrvBiu1YaV 3FXw== X-Gm-Message-State: AG10YOTobVVhBCQBYaEP2iEUFVTHqd4vKgwvhaVocoInTudJmNSaQVk1MVReLPO29WXKUw== X-Received: by 10.66.152.204 with SMTP id va12mr379044pab.0.1453942163150; Wed, 27 Jan 2016 16:49:23 -0800 (PST) Received: from ?IPv6:2406:e007:756a:1:28cc:dc4c:9703:6781? ([2406:e007:756a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id oj9sm11678688pab.8.2016.01.27.16.49.20 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 16:49:21 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A96599.4000403@gmail.com> Date: Thu, 28 Jan 2016 13:49:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP issue 46 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2016 00:49:25 -0000 > o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD > messages is intended to assist in loop prevention. However, we > also have the loop count for that. It would be simpler to remove > the initiator, making message parsing more uniform. Is that OK? We added this in version -02 in response to Joel Halpern's observation that a session_id might (with very low probability) be ambiguous, so it needs to be associated with the address of the node that created it. That remains true. However, the 'initiator' field only matters for disambiguating multicast Discovery messages that have been relayed between LANs, so that responses go back to the correct host in the end. In all other cases, the node that receives a message and needs to make use of the session_id automatically knows who sent the message. When debugging my code for relaying Discovery and Flood messages, I realised that I could make this problem go away very simply: by creating a *new* Discovery or Flood message with a new session_id. For example, if A says discover("C") and this is received by relay B, then B says discover("C") on its other interface, waits for the response, caches it, and then responds to A with a Divert option. The two discovery processes are independent. Not only does it solve the problem above, it's also simpler to code. Node A __|____________________ | Node B ______|___________________ | Node C If the WG agrees, the fix would be: 1. Abolish the 'initiator' field in DISCOVER, RESPONSE and FLOOD. 2. Change the descriptions of the relay actions (for Discover and Flood) to require that the relayed messages have a *new* session_id. But they still decrement the loop count. 3. Simplify the loop detection text. My prototype code works this way and it works well. I've tested loop prevention using the loop count mechanism, and it works too. Brian From nobody Fri Jan 29 00:28:59 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 701891A1A72; Fri, 29 Jan 2016 00:28:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129082856.27660.58583.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 00:28:56 -0800 Archived-At: Cc: anima-chairs@ietf.org, terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com Subject: [Anima] anima - New Meeting Session Request for IETF 95 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 08:28:56 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: homenet netconf dhc v6ops 6tisch nmlrg nmrg Second Priority: opsarea 6man softwire roll 6lo supa Third Priority: cfrg saag intarea Special Requests: Please arrange the first session on Monday/Tuesday and the second session on Thursday. So the WG participators could work and make progress between the two sessions. --------------------------------------------------------- From nobody Fri Jan 29 01:24:30 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CDD1A6F2B for ; Fri, 29 Jan 2016 01:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjn_IEjxCW0N for ; Fri, 29 Jan 2016 01:24:26 -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 C9B201A6F4C for ; Fri, 29 Jan 2016 01:24:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHQ34436; Fri, 29 Jan 2016 09:24:21 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 29 Jan 2016 09:24:20 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Fri, 29 Jan 2016 17:24:12 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] GRASP messages-//RE: I-D Action: draft-ietf-anima-grasp-02.txt Thread-Index: AQHRWWKLfQwLa/QHS06f/BTS76kBUp8SOniw Date: Fri, 29 Jan 2016 09:24:11 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D3FFD9@nkgeml514-mbx.china.huawei.com> References: <20160113003610.7570.78040.idtracker@ietfa.amsl.com> <56959FDF.9080209@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D3D532@nkgeml514-mbx.china.huawei.com> <56A96039.3080207@gmail.com> In-Reply-To: <56A96039.3080207@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56AB2FC6.0101, 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: f45f49196792b0e66b44ba1bc91c541e Archived-At: Subject: Re: [Anima] GRASP messages-//RE: I-D Action: draft-ietf-anima-grasp-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 09:24:28 -0000 SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgcmVwbHlpbmcuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4LCAyMDE2IDg6Mjcg QU0NCj4gVG86IExpdWJpbmcgKExlbyk7IEFuaW1hIFdHDQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFd IEdSQVNQIG1lc3NhZ2VzLS8vUkU6IEktRCBBY3Rpb246DQo+IGRyYWZ0LWlldGYtYW5pbWEtZ3Jh c3AtMDIudHh0DQo+IA0KPiBIaSBldmVyeWJvZHksDQo+IA0KPiBTaW5jZSBub2JvZHkgZWxzZSBo YXMgcmVzcG9uZGVkLCBoZXJlIGFyZSBteSBjb21tZW50czoNCj4gDQo+IE9uIDE0LzAxLzIwMTYg MTU6MjQsIExpdWJpbmcgKExlbykgd3JvdGU6DQo+ID4gSGkgRGVhciBhbGwsDQo+ID4NCj4gPj4g QXMgYSByZXN1bHQgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIGNoYW5nZXMgdG8gdGhlIHByb3RvY29s LiBUaGUNCj4gPj4gYmlnZ2VzdCBvbmUgd2FzIHNwbGl0dGluZyB0aGUgUkVTUE9OU0UgbWVzc2Fn ZSBpbnRvIHRocmVlIHNlcGFyYXRlDQo+ID4+IG1lc3NhZ2VzIChSRVNQT05TRSBmb3IgZGlzY292 ZXJ5IHJlc3BvbnNlcywgU1lOQ0hST05JWkUgZm9yDQo+ID4+IHN5bmNocm9uaXphdGlvbiByZXNw b25zZXMsIGFuZCBGTE9PRCBmb3IgdW5zb2xpY2l0ZWQgZmxvb2QgbWVzc2FnZXMpLg0KPiA+Pg0K PiA+PiBXZSBuZWVkIGNhcmVmdWwgcmV2aWV3cyBvZiB0aGlzIHZlcnNpb24gYW5kIGRlY2lzaW9u cyBhYm91dCB0aGUgb3Blbg0KPiBpc3N1ZXMuDQo+ID4+IEFmdGVyIHBlb3BsZSBoYXZlIGhhZCBh IGZldyBkYXlzIHRvIGRpZ2VzdCB0aGUgZG9jdW1lbnQsIHdlIHdpbGwNCj4gPj4gc3RhcnQgZGlz Y3Vzc2lvbiB0aHJlYWRzIG9uIHRoZSBvcGVuIGlzc3Vlcy4NCj4gPg0KPiA+IFtCaW5nXSBQbGVh c2UgYWxsb3cgbWUgdG8gZGlzY3VzcyB0aGUgZm9sbG93aW5nIG9wZW4gcXVlc3Rpb24gZmlyc3Rs eToNCj4gPg0KPiA+IDQ3LiAgUkVRVUVTVCBpcyBhIGR1YWwgcHVycG9zZSBtZXNzYWdlIChyZXF1 ZXN0IG5lZ290aWF0aW9uIG9yDQo+ID4gICAgICAgcmVxdWVzdCBzeW5jaHJvbml6YXRpb24pLiAg V291bGQgaXQgYmUgYmV0dGVyIHRvIHNwbGl0IHRoaXMgaW50bw0KPiA+ICAgICAgIHR3byBkaWZm ZXJlbnQgbWVzc2FnZXMgKGFuZCBhZGp1c3QgdmFyaW91cyBtZXNzYWdlIG5hbWVzDQo+ID4gICAg ICAgYWNjb3JkaW5nbHkpPw0KPiA+DQo+ID4gRm9yIG15IHBlcnNvbmFsIGZlZWxpbmcsIHRoZSBp c3N1ZSBpcyBub3Qgb25seSB0aGUgb3ZlcmxvYWRpbmcgZm9yIGJvdGgNCj4gTmVnb3RpYXRpb24g YW5kIFN5bmNocm9uaXphdGlvbiwgYnV0IGFsc28gdGhlIHZpb2xhdGlvbiB0aGUgY3VzdG9tIHRo YXQNCj4gIlJlcXVlc3QiIGlzIHVzdWFsbHkgY291cGxlZCB3aXRoICJSZXNwb25zZSIgaW4gb3Ro ZXIgcHJvdG9jb2xzLiBJbiBHUkFTUCwNCj4gIlJlc3BvbnNlIiBpcyBjb3VwbGVkIHdpdGggIkRp c2NvdmVyeSIuDQo+ID4NCj4gPiBTbywgaWYgd2Ugc3BsaXQgdGhlIFJFUVVFU1QgbWVzc2FnZSwg SSB0aGluayBtaWdodCBmaXQgbW9yZSB0byB0aGUgc3BsaXQNCj4gUkVTUE9OU0UgbWVzc2FnZXMg KFJFU1BPTlNFIGZvciBkaXNjb3ZlcnkgcmVzcG9uc2VzLCBTWU5DSFJPTklaRSBmb3INCj4gc3lu Y2hyb25pemF0aW9uIHJlc3BvbnNlcywgYW5kIEZMT09EIGZvciB1bnNvbGljaXRlZCBmbG9vZCBt ZXNzYWdlcyksIHBsdXMsDQo+IHdpdGggYSBiaXQgcmVuYW1pbmcsIHRoZSBtZXNzYWdlcyBjb3Vs ZCBiZSBsaWtlIHRoaXM6DQo+ID4gLSBEaXNjb3ZlcnkgJiBEaXNjb3ZlcnlfUmVzDQo+ID4gLSBO ZWdvdGlhdGlvbl9Jbml0ICYgTmVnb3RpYXRpb24gJiBOZWdvdGlhdGlvbl9FbmQNCj4gDQo+IENv bmZpcm0td2FpdGluZyBmaXRzIGhlcmUsIGRvZXNuJ3QgaXQ/IEkgZG9uJ3QgdGhpbmsgd2UgaGF2 ZSB0aGF0IGZvcg0KPiBzeW5jaHJvbml6YXRpb24sIG9ubHkgZm9yIG5lZ290aWF0aW9uLg0KW0Jp bmddIFllcywgSSBtaXNzZWQgaXQuIFRoYW5rcyBmb3IgY29ycmVjdGluZyBpdC4NCg0KPiA+IC0g U3luY2hyb25pemF0aW9uICYgU3luY2hyb25pemF0aW9uX1Jlcw0KPiA+IC0gQ29uZmlybS13YWl0 aW5nDQo+ID4gLSBGbG9vZA0KPiA+IEJ0dywgdGhlIG1lc3NhZ2UgbmFtZSAiRmxvb2RpbmcgbWVz c2FnZSIgaXMgYSB2ZXJ5IGNvbW1vbi9hYnN0cmFjdA0KPiBwaHJhc2UsIGNhbiB3ZSBmaW5kIGFu b3RoZXIgbW9yZSBwcmVjaXNlIG5hbWU/IEUuZy4sICJGbG9vZGVkDQo+IFN5bmNocm9uaXphdGlv biIgb3IgIlVuc29saWNpdGVkIFN5bmNocm9uaXphdGlvbiIuDQo+ID4NCj4gPiBUaGVzZSBzZWVt IG1vcmUgaW5zdGl0dXRpdmUgZm9yIG1lLiBXaGF0IGFyZSB5b3VyIHRob3VnaHQ/DQo+IA0KPiBJ biBnZW5lcmFsLCBJIGFncmVlLiBJIHRoaW5rIHdlIGNhbiB1c2UgZnVsbCBuYW1lcyBpbiB0aGUg dGV4dCwgbGlrZSBEaXNjb3ZlcnkNCj4gYW5kIERpc2NvdmVyeV9SZXNwb25zZSwgYW5kIHNob3J0 ZXIgb25lcyBpbiB0aGUgZm9ybWFsDQo+IChDRERMKSBkZXNjcmlwdGlvbiwgbGlrZSBNX0RJU0NP VkVSIGFuZCBNX0RJU0NfUkVTUC4NCj4gDQo+IEFwYXJ0IGZyb20gdGhhdCB0aGUgb25seSByZWFs IGNoYW5nZSBpcyBzcGxpdHRpbmcgUmVxdWVzdCBpbnRvIHR3byBjYXNlcywgYW5kIEkNCj4gdGhp bmsgJ3JlcXVlc3QnIGlzIGZpbmUsIHNvIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBsb25nIG5h bWVzIGFyZQ0KPiBSZXF1ZXN0X05lZ290aWF0aW9uIGFuZCBSZXF1ZXN0X1N5bmNocm9uaXphdGlv bi4gVGhlIGNoYW5nZXMgdG8gdGhlDQo+IENEREwgYW5kIHRoZSBwcm90b3R5cGUgY29kZSB3b3Vs ZCBiZSBxdWl0ZSBzbWFsbC4NCj4gDQo+IElmIHRoZXJlJ3Mgbm8gZGlzYWdyZWVtZW50IG9uIHRo ZSBsaXN0LCB3ZSdsbCBwbGFuIHRoaXMgZm9yIHRoZSAtMDMgZHJhZnQuDQpbQmluZ10gSSB0aGlu ayBpdCdzIGdvb2QuIFRoYW5rcy4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQo+ICAgICBCcmlh bg0K