From nobody Tue Jan 3 18:52:59 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549B4129B33; Tue, 3 Jan 2017 18:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhfzcprOcu1u; Tue, 3 Jan 2017 18:52:56 -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 BA2C9129528; Tue, 3 Jan 2017 18:52:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYF09332; Wed, 04 Jan 2017 02:52:53 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Jan 2017 02:52:52 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 4 Jan 2017 10:51:57 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Conclusion//RE: Call for adoption on draft-kwatsen-netconf-voucher-00 Thread-Index: AQHSZjWDv1tNfB16AUuEtC/o8lzvcQ== Date: Wed, 4 Jan 2017 02:51:53 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC7DA92@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.255.62] 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.0A090202.586C6386.000C, 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: b611033dd27155926a6e5ca090b63076 Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: [Anima] Conclusion//RE: Call for adoption on draft-kwatsen-netconf-voucher-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 02:52:58 -0000 After we had the two-week consensus call on the WG mailing list, we receiv= e supports and have no any objections. The chairs conclude there is a conse= nsus in the ANIMA working group to have this draft become a working group d= raft. The authors should submit the next version as an ANIMA working group = document (draft-ietf-anima-*-00).=0A= =0A= The authors should keep working on this document as editor towards its matu= rity as soon as possible since other documents depend on it. The authors sh= ould report any major modifications to the WG, either on mail list or in th= e face-to-face meetings, and acquire consensus in ANIMA WG.=0A= =0A= Thanks,=0A= =0A= Sheng=0A= ________________________________________=0A= From: Sheng Jiang=0A= Sent: 14 December 2016 0:57=0A= To: anima@ietf.org=0A= Cc: Toerless Eckert; anima-chairs@ietf.org=0A= Subject: Call for adoption on draft-kwatsen-netconf-voucher-00=0A= =0A= Hi, all,=0A= =0A= This message starts a two-week adoption call for Voucher work, which is a s= traight-forward definition of common voucher formats as needed in both ANIM= A and NETCONF WG. Although it was submitted to netconf WG originally, after= discussion with netconf chairs and corresponding ADs, we all agree ANIMA i= s the right home for it. If adopted, the authors hope to be ready for WGLC = before Chicago, giving that our milestone work item bootstrap key infrastru= cture normatively refer it.=0A= =0A= Title: Voucher and Voucher Revocation Profiles for Bootstrapping Pro= tocols=0A= =0A= Authors : Watsen, et al.=0A= Filename: draft-kwatsen-netconf-voucher=0A= =0A= https://tools.ietf.org/html/draft-kwatsen-netconf-voucher-00=0A= =0A= Please express your support or rejection. If you think this document should= _not_ be adopted, please also explicitly indicate the reasons.=0A= =0A= This adoption call will end on Dec. 27, 2016.=0A= =0A= Regards,=0A= =0A= Sheng=0A= From nobody Wed Jan 4 16:11:44 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 276B8129449; Wed, 4 Jan 2017 16:11:38 -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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148357509815.13006.13696242097529251863.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 16:11:38 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-voucher-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:11:38 -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 of the IETF. Title : Voucher and Voucher Revocation Profiles for Bootstrapping Protocols Authors : Kent Watsen Michael C. Richardson Max Pritikin Toerless Eckert Filename : draft-ietf-anima-voucher-00.txt Pages : 19 Date : 2017-01-04 Abstract: This memo defines the two artifacts "voucher" and "voucher- revocation", which are YANG-defined structures that have been signed by a TBD algorithm. The voucher artifact is generated by the device's manufacture or delegate. The voucher's purpose is to securely assign one or more devices to an owner. The voucher informs each device which entity it should consider to be its owner. The voucher revocation artifact is used by the manufacturer or delegate (i.e. the issuer of the voucher) to revoke vouchers, if ever necessary. The voucher revocation format defined herein supports both issuer-wide and voucher-specific constructs, enabling usage flexibility. For both artifacts, this memo only defines the artifact, leaving it to future work to describe specialized protocols for accessing them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-voucher-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 4 16:58:04 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8C012947A; Wed, 4 Jan 2017 16:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFiHVEiKiO6K; Wed, 4 Jan 2017 16:57:59 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975681270B4; Wed, 4 Jan 2017 16:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aPVISy70LOKQ3IAIp3MeJXoykBqW2geZdYquG/TggRQ=; b=Z9WopTtskx49gUC+puPPcmIJL25lclUzV2+wS+xMgMJnxhV9wvvHUhiKuLVJuqk/7jgtOUgEilOZHV7roQL/+JBwJ9a1ms4RtPsOQKwb5Q8AUnsabcVBjLnzY5r6gIdsLkQBaaP8/D6U5pLgOuncotHzqbCReYLqaK6sckOUS9Y= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.5; Thu, 5 Jan 2017 00:57:58 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.003; Thu, 5 Jan 2017 00:57:57 +0000 From: Kent Watsen To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Anima] I-D Action: draft-ietf-anima-voucher-00.txt Thread-Index: AQHSZuhNjEjdaA3d80eFjJkODcNC4KEou9+A Date: Thu, 5 Jan 2017 00:57:57 +0000 Message-ID: <48D58FD8-CF9B-433C-87AC-4ED922E5F7BB@juniper.net> References: <148357509815.13006.13696242097529251863.idtracker@ietfa.amsl.com> In-Reply-To: <148357509815.13006.13696242097529251863.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 2f5970ee-5926-41c6-77fb-08d43505e3cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:hkz2JK8ku5R0ajxxLPGsCFc2DkVJxPGfNRsNyFuHV6CZgXo3qLFTs4iOuHz64UrXnBdRNCzpG7xlzOVCGf+bR/PWwfTF/XZfMdQ1HY7t++Z9g1l7YgQlTamnMYlDsfOChhE5Jx1WuczRLbDVotuMqXu5vB9PsK4Sr6GWXX4ytUtwYn/JPflLWDh5YWeYz52d9uj8FlRY6gCV9rikPZsEUGDZBENefMiYNWnjLjhAdiXFOSdJp2F7LJRmalzItqFtx/Ddrsew1uHpPh/poCrt3n14lczvxnoQMdXd9HTERqxq+G6+gutSevn9o6CUKwxl/vdQAJuWyWVTr35QowIQOBsRpH5TpX7AjZY4rUwvgNIGZ3Ugy60DPZyztv4MOcG2tCLYkOZQ4h/kbgEEseN9cNQ7COJtRMiAZbcZz7lFX4KfsIBnwneWqc4BmA62+uYWhnvxf+UnMlXF+xPjumvmiQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39860400002)(39410400002)(39450400003)(377424004)(189002)(199003)(101416001)(6486002)(77096006)(50986999)(4326007)(54356999)(76176999)(6436002)(2906002)(25786008)(6506006)(229853002)(6512006)(2950100002)(3846002)(102836003)(66066001)(230783001)(6116002)(92566002)(122556002)(5660300001)(38730400001)(3280700002)(106116001)(106356001)(2900100001)(450100001)(105586002)(3660700001)(82746002)(83506001)(6306002)(99286003)(81156014)(7736002)(97736004)(68736007)(5001770100001)(2501003)(305945005)(189998001)(8676002)(81166006)(86362001)(4001350100001)(8936002)(83716003)(36756003)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 00:57:57.8484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:58:02 -0000 DQpUaGlzIC0wMCB0aGUgZHJhZnQgaXMgaWRlbnRpY2FsIHRvIGRyYWZ0LWt3YXRzZW4tYW5pbWEt dm91Y2hlciB3aXRoIHRoZSBmb2xsb3dpbmcgdHdvIGNoYW5nZXM6DQoNCiAgLSByZXBsYWNlIGRy YWZ0LWt3YXRzZW4tKiB3aXRoIGRyYWZ0LWlldGYtKg0KICAtIHJlbW92ZXMgVG9lcmxlc3PigJlz IGFmZmlsaWF0aW9uDQoNCk5vdyB0aGF0IHRoaXMgZHJhZnQgaXMgYWRvcHRlZCwgYWxsIHN1YnNl cXVlbnQgY2hhbmdlcyB3aWxsIGJlIHJldmlld2VkIGJ5IHRoZSBXRy4NCg0KVGhhbmtzLA0KS2Vu dA0KDQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgQXV0b25vbWljIE5ldHdvcmtpbmcgSW50ZWdyYXRlZCBNb2RlbCBhbmQgQXBwcm9h Y2ggb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogVm91Y2hlciBhbmQg Vm91Y2hlciBSZXZvY2F0aW9uIFByb2ZpbGVzIGZvciBCb290c3RyYXBwaW5nIFByb3RvY29scw0K ICAgICAgICBBdXRob3JzICAgICAgICAgOiBLZW50IFdhdHNlbg0KICAgICAgICAgICAgICAgICAg ICAgICAgICBNaWNoYWVsIEMuIFJpY2hhcmRzb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg TWF4IFByaXRpa2luDQogICAgICAgICAgICAgICAgICAgICAgICAgIFRvZXJsZXNzIEVja2VydA0K CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYW5pbWEtdm91Y2hlci0wMC50eHQNCglQYWdl cyAgICAgICAgICAgOiAxOQ0KCURhdGUgICAgICAgICAgICA6IDIwMTctMDEtMDQNCg0KQWJzdHJh Y3Q6DQogICBUaGlzIG1lbW8gZGVmaW5lcyB0aGUgdHdvIGFydGlmYWN0cyAidm91Y2hlciIgYW5k ICJ2b3VjaGVyLQ0KICAgcmV2b2NhdGlvbiIsIHdoaWNoIGFyZSBZQU5HLWRlZmluZWQgc3RydWN0 dXJlcyB0aGF0IGhhdmUgYmVlbiBzaWduZWQNCiAgIGJ5IGEgVEJEIGFsZ29yaXRobS4NCg0KICAg VGhlIHZvdWNoZXIgYXJ0aWZhY3QgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBkZXZpY2UncyBtYW51ZmFj dHVyZSBvcg0KICAgZGVsZWdhdGUuICBUaGUgdm91Y2hlcidzIHB1cnBvc2UgaXMgdG8gc2VjdXJl bHkgYXNzaWduIG9uZSBvciBtb3JlDQogICBkZXZpY2VzIHRvIGFuIG93bmVyLiAgVGhlIHZvdWNo ZXIgaW5mb3JtcyBlYWNoIGRldmljZSB3aGljaCBlbnRpdHkgaXQNCiAgIHNob3VsZCBjb25zaWRl ciB0byBiZSBpdHMgb3duZXIuDQoNCiAgIFRoZSB2b3VjaGVyIHJldm9jYXRpb24gYXJ0aWZhY3Qg aXMgdXNlZCBieSB0aGUgbWFudWZhY3R1cmVyIG9yDQogICBkZWxlZ2F0ZSAoaS5lLiAgdGhlIGlz c3VlciBvZiB0aGUgdm91Y2hlcikgdG8gcmV2b2tlIHZvdWNoZXJzLCBpZg0KICAgZXZlciBuZWNl c3NhcnkuICBUaGUgdm91Y2hlciByZXZvY2F0aW9uIGZvcm1hdCBkZWZpbmVkIGhlcmVpbg0KICAg c3VwcG9ydHMgYm90aCBpc3N1ZXItd2lkZSBhbmQgdm91Y2hlci1zcGVjaWZpYyBjb25zdHJ1Y3Rz LCBlbmFibGluZw0KICAgdXNhZ2UgZmxleGliaWxpdHkuDQoNCiAgIEZvciBib3RoIGFydGlmYWN0 cywgdGhpcyBtZW1vIG9ubHkgZGVmaW5lcyB0aGUgYXJ0aWZhY3QsIGxlYXZpbmcgaXQNCiAgIHRv IGZ1dHVyZSB3b3JrIHRvIGRlc2NyaWJlIHNwZWNpYWxpemVkIHByb3RvY29scyBmb3IgYWNjZXNz aW5nIHRoZW0uDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFu aW1hLXZvdWNoZXIvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxl IGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtdm91Y2hl ci0wMA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg0K From nobody Fri Jan 6 11:13:35 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F78C129DBD for ; Fri, 6 Jan 2017 11:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyRfhAKqbEje for ; Fri, 6 Jan 2017 11:13:32 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D94129DBC for ; Fri, 6 Jan 2017 11:13:32 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id 14so9780586pgg.1 for ; Fri, 06 Jan 2017 11:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PVxwqvRKxn8pW1TZZXCPNjyWxHLiq4E2lN/efnNqb2I=; b=Y1VQYZ+oZVcS1oyZbVWfi+vfWeYzmMfkSLjHSY5l6vQofD4Jhaxlc03z2ibVVKy/Of bwWVeMA77eKl8uchTx2i24CQ+mS3EsfjhyyKqAyl18Pjv4rqzCExR2fPhVMHgSZZGwiZ CJRD33xiCoe+bBSbKWRDj8eYk5P1yhp6Vk113CInWoVUvCH47a1SNxTMfgYzvQPQTIRI LqR7SplSM7mqVMeUXcrfDD2PdfrB9aBO1q4mH012aH80rpzNr5fXeQ9Xaq8pf3XKRrlb aDO9szoOu2srA52EVVqi4SCbBoxpkxvm+7atpBTNqrIDmdkN2Z6LyV1TX76VZBvBwahw P2Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PVxwqvRKxn8pW1TZZXCPNjyWxHLiq4E2lN/efnNqb2I=; b=H+w6yVcAe2JfE67Hu0CtAI+PLAEgpBaGEECHjHi3VBGSfVNLJ53vtEd7h6EGWEYR45 KZXGchRbaKEsfjW4DXYqKwP77FpPj5TaXpMKOt7Nt7KsH+ddNuqBQy24Vxx0jYbxCzwi 35xdAmQl7bQ0ayZtPq/4Bbj2qbmzJcI7xNKdQvqZKJzYnpX2x0fqk91Oks/ET2ZiLEdi NhllgXJOyXDAgirR8KrH+b68xKdan9FFNKtS8PQxmTF64mdBYI9iDyeW4XrSIcmysITX 0DlB0XgMIZfRpdzCt/9P9aMhKVJQ/XrQW1+zYMl6LNV1BNKOtI2n5nNwhBkk9Rfnn3cf SS7A== X-Gm-Message-State: AIkVDXLSXscylxw8lHEFEW21Agk+Jll6m3GnKusurDO17efhRcDQjb3SzTUeKNR1nmjh8w== X-Received: by 10.98.44.138 with SMTP id s132mr71280820pfs.134.1483730012192; Fri, 06 Jan 2017 11:13:32 -0800 (PST) Received: from [192.168.178.21] (21.226.69.111.dynamic.snap.net.nz. [111.69.226.21]) by smtp.gmail.com with ESMTPSA id x2sm161406224pfx.65.2017.01.06.11.13.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 11:13:31 -0800 (PST) To: Anima WG References: <148372974611.17446.17663952835175494328.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 7 Jan 2017 08:13:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148372974611.17446.17663952835175494328.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-asa-guidelines-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:13:34 -0000 This draft has been expanded from the earlier version to fill in some gaps. The authors would welcome more thoughts and contributions. If Anima is a success there will be many ASAs, so it seems important to have some guidelines. Regards Brian Carpenter On 07/01/2017 08:09, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Guidelines for Autonomic Service Agents > Authors : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-anima-asa-guidelines-01.txt > Pages : 10 > Date : 2017-01-06 > > Abstract: > This document proposes guidelines for the design of Autonomic Service > Agents for autonomic networks. It is based on the Autonomic Network > Infrastructure outlined in the ANIMA reference model, making use of > the Autonomic Control Plane and the Generic Autonomic Signaling > Protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-asa-guidelines/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-carpenter-anima-asa-guidelines-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-asa-guidelines-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Sun Jan 8 09:27:35 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479CE1294E7 for ; Sun, 8 Jan 2017 09:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CZato8zltdb for ; Sun, 8 Jan 2017 09:27:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34C01294C0 for ; Sun, 8 Jan 2017 09:27:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B60FEE1DF for ; Sun, 8 Jan 2017 12:46:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0A8B8636BB for ; Sun, 8 Jan 2017 12:27:30 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] M_FLOOD vs M_DISCOVERY X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 17:27:33 -0000 --=-=-= Content-Type: text/plain We want to use GRASP to permit the bootstrap proxy to discover where the Registrar(s) are. As far as I can see there are really two options, and they might not be mutually exclusive. a) start a multicast M_DISCOVERY which will be propagated forward and can be answered from caches. b) listen for an M_FLOOD. As I see it there are advantages and disadvantages to each. My take before was that M_DISCOVERY was to be preferred in most cases. I'm really just writing to confirm this belief. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhydoEACgkQgItw+93Q 3WUOuAgAuCUDznM+Lzb5c3AuweuytO67APb0UKE4kFF9Z42yr4YvsylvuAuSIIjt nfkbnlqu9Fze9ojykCxu9432ffsEbu6m4zQB7IvTu848eagn8VojB6AiVX/bLheT b+833G4tvPGKAdHy5Lt1ZlPBrsJumrR1w+o3XDLh7k6Ck+J+aPGO31sVyTuPNdw2 5iuQUkT7FuoHED38spHnXEEpPPt6r4je/YrjEKBZouF0Q6e08UjAMxTyzmOmrLZX 6puXPjPaDKbLSwMi+E0GnWG2d9M1ZSkgv0oq0dG+ziwBknEn1loK+auJx+HC0hXR EQX/rfwnB3ZA81rCmYd/dZeqqStsyg== =45bC -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 8 11:20:04 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083FA124281 for ; Sun, 8 Jan 2017 11:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH7YHVu-aahw for ; Sun, 8 Jan 2017 11:20:01 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB48127071 for ; Sun, 8 Jan 2017 11:20:01 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id 204so14601424pge.0 for ; Sun, 08 Jan 2017 11:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=UOqj0v7Py52poBnYQY50x1ZuKjyblmwPDji4pIpqiys=; b=XMUqtS5kazdepXq/iaTV0uBMq4GKW17RcYU18HX7JDo3PM9inyXEIWtAie8ltDL7En bUCBqGPmyeXD1RumYLBXXNFFf8kw1X3z03ngdOeJ/CrGrqlpXRMG7KTx5qQA4Tfd3pgB YFL5sU/empr4ABRfxvUMXUqAvuNpK35tELiig2tgm9RlJ1BeBj/doHUNN+ocKD1x79YQ gowgj5fzrMEaSN/EM13BFZyqSJP/ZSG7J2hqDK7lMms4gP/xmPZ0H21Xi6K3+Al+h4pM izyzuiZFvq3XvOqwSPRdUC++iLm6yZYUODoy1xE4TFgR1LRgM42Y6tOniv/qZqABaWsy Rqug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=UOqj0v7Py52poBnYQY50x1ZuKjyblmwPDji4pIpqiys=; b=VDmn5juGmk6ndEL6wP3fOFqlUxf0sUIu+aRkEASJnScKbh1zYK/9uJiALURy+qEbZU LZG1TNWnrs7D1qIKIoO8NYt6TVDKRXrGqPA7GEOykftnPKsZvsh/lNBQDgkT/VVzWPpj OWwtSNj42Zkpe8lD7Y+goSuc6r4TQRJloqdpHwCGQWVLwRD05N5nkv4MEp+WQp7NFsma vdCsvGOJN11C6ZcEAa3WY0A3wRlZmbb1PJdByA+3zpL0Krqa1hkww1eFdNkfZGUhVk9K nYKOwlVH7kE6I2CEVkMexMTqH8BQLJnOX69DSLgm+5lw/4nQDuHsd1VyhbCDOmpk8DF2 dnzA== X-Gm-Message-State: AIkVDXK3717MMxHx0GsooqW5brcCHZ8KZunSaANo6riUpn/DJRUjYFxz8/JtkSKkBr76Uw== X-Received: by 10.99.36.65 with SMTP id k62mr155740882pgk.13.1483903200817; Sun, 08 Jan 2017 11:20:00 -0800 (PST) Received: from ?IPv6:2406:e007:756c:1:28cc:dc4c:9703:6781? ([2406:e007:756c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b83sm17464967pfe.12.2017.01.08.11.19.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jan 2017 11:19:59 -0800 (PST) To: anima@ietf.org References: <21051.1483896450@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 9 Jan 2017 08:19:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <21051.1483896450@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] M_FLOOD vs M_DISCOVERY X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 19:20:03 -0000 On 09/01/2017 06:27, Michael Richardson wrote: > > We want to use GRASP to permit the bootstrap proxy to discover where the > Registrar(s) are. As far as I can see there are really two options, and they > might not be mutually exclusive. > > a) start a multicast M_DISCOVERY which will be propagated forward and can be > answered from caches. > b) listen for an M_FLOOD. > > As I see it there are advantages and disadvantages to each. > > My take before was that M_DISCOVERY was to be preferred in most cases. > I'm really just writing to confirm this belief. As always, it's a tradeoff. My impression after discussions some months ago was the the BRSKI team preferred M_FLOOD, but I have no strong opinion. Firstly, I assume that the registrar/proxy hookup can take place over the ACP, because the nodes involved already have certificates and the ACP has formed itself. (This will occur as an expanding circle around the registrar, which will proxy for itself on its own link-local interfaces.) So from a security viewpoint, there isn't much difference. Secondly, the methods aren't mutually exclusive. If the "normal" method is flooding an objective that I've called "AN_registrar" in my toy code, nothing prevents discovery/synchronize being used as a backup. That said, it seems that once a proxy has found a registrar, there's no need for a regular refresh, so discovery seems appropriate. (Don't forget that the discovery cache will time out, but that's standard.) Send comments on https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives We assumed the flooding model for registrar/proxy there, but described both models for the pledge/proxy hookup. Brian From nobody Sun Jan 8 16:57:41 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C8E12941E for ; Sun, 8 Jan 2017 16:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQop0azvElLF for ; Sun, 8 Jan 2017 16:57:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44111293DF for ; Sun, 8 Jan 2017 16:57:38 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2327920573; Sun, 8 Jan 2017 20:16:57 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 57D90636BB; Sun, 8 Jan 2017 19:57:37 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <21051.1483896450@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] M_FLOOD vs M_DISCOVERY X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 00:57:40 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> We want to use GRASP to permit the bootstrap proxy to discover where >> the Registrar(s) are. As far as I can see there are really two >> options, and they might not be mutually exclusive. >> >> a) start a multicast M_DISCOVERY which will be propagated forward and >> can be answered from caches. b) listen for an M_FLOOD. >> >> As I see it there are advantages and disadvantages to each. >> >> My take before was that M_DISCOVERY was to be preferred in most cases. >> I'm really just writing to confirm this belief. > As always, it's a tradeoff. My impression after discussions some months > ago was the the BRSKI team preferred M_FLOOD, but I have no strong > opinion. We want M_FLOOD for discovery *OF* the proxy. I'm asking about discovery *BY* the proxy *OF* the registrar. > Firstly, I assume that the registrar/proxy hookup can take place over > the ACP, because the nodes involved already have certificates and the > ACP has formed itself. (This will occur as an expanding circle around > the registrar, which will proxy for itself on its own link-local > interfaces.) So from a security viewpoint, there isn't much difference. Agreed. > Secondly, the methods aren't mutually exclusive. If the "normal" method > is flooding an objective that I've called "AN_registrar" in my toy > code, nothing prevents discovery/synchronize being used as a backup. Question: should all the internal objectives be AN_ ?? > That said, it seems that once a proxy has found a registrar, there's no > need for a regular refresh, so discovery seems appropriate. (Don't > forget that the discovery cache will time out, but that's standard.) > Send comments on > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives We > assumed the flooding model for registrar/proxy there, but described > both models for the pledge/proxy hookup. I intend to contribute to it this week. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhy4AEACgkQgItw+93Q 3WU0ugf8CnZW5lKh6XwTJ+aambfiyaCPw7QUjB9FdbMMNVWowKAG40PolqKaLOvQ QnAVENaepGYtcI2YP1OVXT2btTFruyETi+W2Qo/8L8KgKfNVcNseowLKFm+BWPFa o1wN9I1qijdzNTjav9AiByjHaLhPcArXqNmMn9D+AVTzOTepYli/qzfJwbiJJLsR 4kwQi0w0Tgfui27FzvmMFkvHKP/DbG/MlTWWeVLyb6KQcUjsU2OwhnFqRfd/FXRW 5LVmiWr4OPtJ1g97MT/EWrwySq+SlkQ02LbQpAVvij4LvWGvRD4bKd1jVDIiqI4x Y8JAPTwP+ayxnLgpInjSBrq/9V+Pew== =30cK -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 8 17:02:58 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024912967E for ; Sun, 8 Jan 2017 17:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb-g3okvSESY for ; Sun, 8 Jan 2017 17:02:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C330129677 for ; Sun, 8 Jan 2017 17:02:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1135F20573 for ; Sun, 8 Jan 2017 20:22:14 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 45461636BB for ; Sun, 8 Jan 2017 20:02:54 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] clarify +locator-option X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 01:02:56 -0000 --=-=-= Content-Type: text/plain When I read: divert-option = [O_DIVERT, +locator-option] I think that it means that +locator-option means that one can multiple options, and that they would be inside an array? So, for example: [O_DIVERT, [ [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number], [O_IPv4_LOCATOR, ipv6-address, transport-proto, port-number], [O_FQDN_LOCATOR, ipv6-address, transport-proto, port-number]]] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhy4T0ACgkQgItw+93Q 3WVjeAf+NPkSlE2y1llT2G++5FhY6+DIf4WMI9YaylEUiRz+cO6x67mYF7BlV4Sp tDfXgW/5rRJmzDd36u9errpKZORLgdQPjSwzXu9DndngcrdjZxybMUlDkro2OXYK FdeVsIvj5s9mQTTFVNAWeobIKKN1P9ZsHFlXAS0qgZioNG6xV/BK3aOv/oBlg+tM IVgwpfwAMupPhhjXDR/Uf/4nQbE5LJe55oSwF7ZnGnG+8BlBX5dle6aWNoaZyNwp EolTtnYZkJoLEE/rZeNtaE21LvQQKEAtE9dAN8dyc9SyzJY3iBxk+P8jGzlcfy7Z qpANY3WVVs9sC9wqym/Lb6rREILhMw== =RCYc -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 8 17:40:59 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA92127076 for ; Sun, 8 Jan 2017 17:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhzer0hs5gM2 for ; Sun, 8 Jan 2017 17:40:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E91B126B6D for ; Sun, 8 Jan 2017 17:40:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 003E7E288; Sun, 8 Jan 2017 21:00:14 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1851D636BB; Sun, 8 Jan 2017 20:40:55 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <27272.1483923457@obiwan.sandelman.ca> References: <21051.1483896450@obiwan.sandelman.ca> <27272.1483923457@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] M_FLOOD vs M_DISCOVERY X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 01:40:58 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: bc> Secondly, the methods aren't mutually exclusive. If the "normal" bc> method is flooding an objective that I've called "AN_registrar" in my bc> toy code, nothing prevents discovery/synchronize being used as a bc> backup. > Question: should all the internal objectives be AN_ ?? https://github.com/anima-wg/anima-bootstrap/commit/853dc9334c6dcb0e6a9b199b846960be18a0504c I will add this to the other document, and maybe I can learn how to better present it. This is the latest text I just wrote:
The registrar responds to discovery messages from the proxy (or GRASP caches between them) as follows:
Figure 6: Registrar Discovery
The response from the registrar (or cache) will be a M_RESPONSE with the following parameters:
Figure 7: Registrar Response
-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhy6iYACgkQgItw+93Q 3WXw5wf+KeGZ2wTJ6VQ2nmBd+5opyRVDdK+NEh1EZ69JCOnzmhl7RI2PBvl9qLOE v36Hzj6HLXbATuuXvK+KylmGUT/32zFDNU9SC+vR6NqcL40pf0mWZnhSgSWwSTgf KnMfNBhTHLDZmWc5Wzc/Hpmf/ugo0LxhkBXYvNeGxxMey3nYOGp+j63JuQSIepbZ 9a1tZA0kFQphAqU0JxFy8O/LO7EUk4vCNrEqJBvMzm93YEvCYWsACzkyo+pyJJLw Ltr+7rKye/hSRCkoAxLAO8qkX1PBBjsaJAx/TLgEv/OnHIkIh8a9pf5Pn5LV2rHa Hr8Ob/Ejx/bDPJz/5PZ++SPPEz/LjQ== =Jolo -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 8 18:58:54 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAA11296DB for ; Sun, 8 Jan 2017 18:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL-a-lRdk5RM for ; Sun, 8 Jan 2017 18:58:52 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A5C129A58 for ; Sun, 8 Jan 2017 18:58:52 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id y143so2402117pfb.1 for ; Sun, 08 Jan 2017 18:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Oq1eHH2wcmeFHaT8H3jts88XBh7lxtc+OE+5NTG9TVc=; b=c6t/9dH0bHW3AT6zOHMs4eaETjBv00HxAGGTnh1w+89TLmCLmOrmXTIldoEbSfwX9q lDrZOym4O9h/a7xTC0lzVmKKxI6ClVsIvrTz+d9lUrWWZ1Oi3XEnrsMvMOsLYWv0g0Vi kKiwe5rTkd+GJwpDF8DwtJXXV4NQ3COwtt1ddTGjrzOnjxQGC12iolMPuscS4ReQeVtJ 6GxWi5MjS9KqDgKEt8gqTDQmDuT+Avs2aQ+kHz6xHan8wvdJYDsn1GZ21Hxjv6F10zy4 ST8LPvTwGEQZ8HFNxWNVThaVAGbHW1RdIQrpK1BkWbyS9rLDlxGHMYfet80sfINCmlEg Yf6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Oq1eHH2wcmeFHaT8H3jts88XBh7lxtc+OE+5NTG9TVc=; b=e2z8VrW+tmRzgFuk1/JDU59UOrQ79ckQshBQ39dxNUjLSJ7Dxlu4P6uvEGQMN3i0cE Cc+ZsifFR1GADwxxnzlhakzqs3LWR296Pgm6Ey5TaT7QAkCA/jcH+C+Xsmr+wFSAOj9Z xZ1ARQUreeIqQgLoRun5ipxwUAjLK9pHbazt12BI8OjhGGK77tAXwny5EgYQypadioSE GYwyNtOKr5K8MxlMi3HsV4nGUt/ez8oPcpu3k61v8Smx35MjW8S0qsP//SWoxDpJb4xt EtOXmASUmGbVm1CV7wizr3jTGHccUXoWGVtX4aHgtFDgF5rgP8SKucO5oNndOL+fOJop YAIw== X-Gm-Message-State: AIkVDXISxgYHahItNtYom30BBq4uI09ZEhE3RVOEeEMzDfRJ9US2CfYtxBq7H9Irlx5bJw== X-Received: by 10.99.192.69 with SMTP id z5mr159060697pgi.169.1483930731433; Sun, 08 Jan 2017 18:58:51 -0800 (PST) Received: from ?IPv6:2406:e007:52c5:1:28cc:dc4c:9703:6781? ([2406:e007:52c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t184sm175672454pgt.36.2017.01.08.18.58.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jan 2017 18:58:50 -0800 (PST) To: anima@ietf.org References: <28451.1483923774@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <25c86c7d-a7ad-fb8c-8b2b-fb4f0fc6facd@gmail.com> Date: Mon, 9 Jan 2017 15:58:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <28451.1483923774@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] clarify +locator-option X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 02:58:53 -0000 On 09/01/2017 14:02, Michael Richardson wrote: > > When I read: > divert-option = [O_DIVERT, +locator-option] > > I think that it means that +locator-option means that one can multiple > options, and that they would be inside an array? > > So, for example: > > [O_DIVERT, [ [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number], > [O_IPv4_LOCATOR, ipv6-address, transport-proto, port-number], > [O_FQDN_LOCATOR, ipv6-address, transport-proto, port-number]]] I'm not sure there's an additional array. CBOR can handle arrays of undefined length, so I think that syntax generates [O_DIVERT, [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number], [O_IPv4_LOCATOR, ipv6-address, transport-proto, port-number], [O_FQDN_LOCATOR, ipv6-address, transport-proto, port-number]] but I'd rather hear that from Carsten to be sure. Brian From nobody Sun Jan 8 19:01:53 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D71C129A59 for ; Sun, 8 Jan 2017 19:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQmoW37sjHuq for ; Sun, 8 Jan 2017 19:01:50 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4A61296DB for ; Sun, 8 Jan 2017 19:01:50 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id 14so25691890pgg.1 for ; Sun, 08 Jan 2017 19:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DftcPuXkZgYPwG3+9HaQDFQBZP93mfHanWo64Kqgv7I=; b=U/FzEzsd8wfc//BDlpnAcqPHwxemxzXvgs766NUndk5i/nQ2hkLzFltFVlF47ynS6+ HpATfEFsrpZa93rmtnN1MpwUyEpKA8lAvfbq53p5c79W4YbdJ417r6nXEAVHpwGBavWN BUqxb5Q4kRuwiklAV6WzxfQ6XTmJKJwG1UOZ09UAJq10vq2JknGieMUhvZ0toj87Qio6 lzxnOMirhWGHhnhmZDaszCeFuLMzZ/oR/u1RBMpZHdQVK09z4MDJgYsDxoUOeqUGfrIT aYLsa3NotAETxHNTKREgedFMUMt8JO93+I8u/02Hk2Am4kFUMEeEhkeCa68hoWgH2SvK SNUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DftcPuXkZgYPwG3+9HaQDFQBZP93mfHanWo64Kqgv7I=; b=O78WwjGOcgNsSrLTlTmguL2jrWZXYOP2C5XWlSSEkSVUvWbY15WvBN+7sTlQ87QCuA 4Bnk4ZneIv2d+Qt4Y7QcauWnj5GV+g0eF47Tq/dijBo665eB8MmXhWYaZrQydOrI0RGX B1AzaYhFG6vlQTO75GxzlygtMgIgI8rUBcCe8QEdfBKDm7QhU1SiPsKjTaPC22svZDJZ qIB1kXW36t7ttL2tNN5yffwSU3gLcfjaPcvJ5nt2imdHUrgplGpld3AApGEBJICNNWnU jxwU8KkB8/kAXIg8+W2+19p0CaPaXg0fk8YUnofwQQTWjYpyk1gSJkvUZ6HzKxFah/wq eKXA== X-Gm-Message-State: AIkVDXLvjAXrVwLWt9wwur9LLS2qeM3dUARPBREc42K+egyXwxivrqZGWrF3R5qOjKj7Xg== X-Received: by 10.98.138.72 with SMTP id y69mr81692170pfd.52.1483930909638; Sun, 08 Jan 2017 19:01:49 -0800 (PST) Received: from ?IPv6:2406:e007:52c5:1:28cc:dc4c:9703:6781? ([2406:e007:52c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k22sm116819435pfg.84.2017.01.08.19.01.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jan 2017 19:01:49 -0800 (PST) To: Michael Richardson References: <21051.1483896450@obiwan.sandelman.ca> <27272.1483923457@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <12e491b5-aea3-dc4a-76de-5da695a7c6ea@gmail.com> Date: Mon, 9 Jan 2017 16:01:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <27272.1483923457@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] M_FLOOD vs M_DISCOVERY X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 03:01:52 -0000 Regards Brian Carpenter On 09/01/2017 13:57, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> We want to use GRASP to permit the bootstrap proxy to discover where > >> the Registrar(s) are. As far as I can see there are really two > >> options, and they might not be mutually exclusive. > >> > >> a) start a multicast M_DISCOVERY which will be propagated forward and > >> can be answered from caches. b) listen for an M_FLOOD. > >> > >> As I see it there are advantages and disadvantages to each. > >> > >> My take before was that M_DISCOVERY was to be preferred in most cases. > >> I'm really just writing to confirm this belief. > > > As always, it's a tradeoff. My impression after discussions some months > > ago was the the BRSKI team preferred M_FLOOD, but I have no strong > > opinion. > > We want M_FLOOD for discovery *OF* the proxy. > I'm asking about discovery *BY* the proxy *OF* the registrar. Understood (now, but not when I wrote my toy code or the draft). > > Firstly, I assume that the registrar/proxy hookup can take place over > > the ACP, because the nodes involved already have certificates and the > > ACP has formed itself. (This will occur as an expanding circle around > > the registrar, which will proxy for itself on its own link-local > > interfaces.) So from a security viewpoint, there isn't much difference. > > Agreed. > > > Secondly, the methods aren't mutually exclusive. If the "normal" method > > is flooding an objective that I've called "AN_registrar" in my toy > > code, nothing prevents discovery/synchronize being used as a backup. > > Question: should all the internal objectives be AN_ ?? Personally I think that would be a helpful convention, but I'm not sure we should have a *rule*. > > That said, it seems that once a proxy has found a registrar, there's no > > need for a regular refresh, so discovery seems appropriate. (Don't > > forget that the discovery cache will time out, but that's standard.) > > > Send comments on > > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives We > > assumed the flooding model for registrar/proxy there, but described > > both models for the pledge/proxy hookup. > > I intend to contribute to it this week. Great. And where the assumptions are false, don't hesitate to say so. Brian From nobody Sun Jan 8 19:59:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228A2129470 for ; Sun, 8 Jan 2017 19:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVS1m0fQMffQ for ; Sun, 8 Jan 2017 19:59:48 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3D012946D for ; Sun, 8 Jan 2017 19:59:48 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id 204so17386375pge.0 for ; Sun, 08 Jan 2017 19:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Uq6s637LTg1X8gFarbmEaHb4TFYfad+lL+E/2XTOA4Q=; b=q4xVSwVvNqIh6vDgYc4T5/xcukTARXARR7rEqvUeCKxGeh9zY8djjnyr/9NC4YHq5H EGdrZdOyaTrwkEYSdCQLduvr4gaBBKp3KfD8f56U/wARls29sqACC0yIwZIsxzKkaagf WBHrD+ThWap8J2nr9Ui0g8+9orvuEfvIcXggy6egpgQW8FNc75hIsycmhbXJSDs0OqB5 nI3OW+wQxJLSCrIQRJhJ+o12zROwIMR7JstQdhrgJtI+fBGUeKugwW+N15Xtv3RAIJ73 bb4KSXv1Q9F3P7rZXFcJVCfJuEk45HKiQ70gsb3y8pNyJmZv/TzNfHLhhc5peh+Q11M5 mefA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Uq6s637LTg1X8gFarbmEaHb4TFYfad+lL+E/2XTOA4Q=; b=nzlYXCjts0TQnNG0gywXTK+SUMt6U77jZVCFjYskIh/RPC2WYlD6VB5HXWQvEuplwt OLIJHahXyKlIKaazz71JxjUopJ+m+wJ06LtFT2rdbUBRPoMtY5yywAeiZ5iGlBL7DdCh LfxPg9GuJKfCQgBbav5Qr2jblRwJipVEHrDSDeNNgkki1RL3PA0EpEI8lsaaAq/XX6Vs oQOyt8YGa9v9ezI4S+viTtqLL48+m600WcEV/Q+q10gVfpFbtHr+aHHT7P5bH9k8lKVX tnosJfbf6SLKPns+fy9etTqNybcj8Oom8bnxRnpaMA9e2O1+a9ceUo2nSeV8+6ZmCwbX aWDQ== X-Gm-Message-State: AIkVDXL1Fq2YCWYLN9l7Xqra1Ail/jQedIrbnZdA0XeXgRzT2Sg3SoP5iZ2VZ2IYSES1WQ== X-Received: by 10.84.231.2 with SMTP id f2mr42154636plk.28.1483934387632; Sun, 08 Jan 2017 19:59:47 -0800 (PST) Received: from ?IPv6:2406:e007:52c5:1:28cc:dc4c:9703:6781? ([2406:e007:52c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a11sm174435901pfe.96.2017.01.08.19.59.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jan 2017 19:59:46 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <21051.1483896450@obiwan.sandelman.ca> <27272.1483923457@obiwan.sandelman.ca> <5372.1483926055@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <95bd33c3-8872-b86f-54b2-c334eadfc4ad@gmail.com> Date: Mon, 9 Jan 2017 16:59:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5372.1483926055@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] M_FLOOD vs M_DISCOVERY X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 03:59:50 -0000 Two minor things: [O_IPv6_LOCATOR, fe80::1234, 41, nil] The address is represented as 128 bit quantity, bytes .size 16 in CDDL, so it will actually just be an in6_addr in C terms. If you really want to write it down, 0xfe800000000000000000000000001234 nil is a valid element in CDDL, but is there any reason not to use port 0? It's explicitly reserved by IANA and it will avoid any type issues. Regards Brian On 09/01/2017 14:40, Michael Richardson wrote: > > Michael Richardson wrote: > bc> Secondly, the methods aren't mutually exclusive. If the "normal" > bc> method is flooding an objective that I've called "AN_registrar" in my > bc> toy code, nothing prevents discovery/synchronize being used as a > bc> backup. > > > Question: should all the internal objectives be AN_ ?? > > https://github.com/anima-wg/anima-bootstrap/commit/853dc9334c6dcb0e6a9b199b846960be18a0504c > > I will add this to the other document, and maybe I can learn how to better present > it. > > This is the latest text I just wrote: > >
> > The registrar responds to discovery messages from the proxy > (or GRASP caches between them) as follows: >
> objective = ["AN_registrar", F_DISC, 255 ] > discovery-message = [M_DISCOVERY, session-id, initiator, objective]]]> > > Figure 6: Registrar Discovery >
> > > > The response from the registrar (or cache) will be a M_RESPONSE with the > following parameters:
> response-message = [M_RESPONSE, session-id, initiator, ttl, > (+locator-option // divert-option), ?objective)] > initiator = ACP address of Registrar > locator1 = [O_IPv6_LOCATOR, fe80::1234, 6, 443] > locator2 = [O_IPv6_LOCATOR, fe80::1234, 17, 5683] > locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]> > > Figure 7: Registrar Response >
> >
> > > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Jan 9 06:43:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACDE129CFF for ; Mon, 9 Jan 2017 06:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ2yAOqGrdqn for ; Mon, 9 Jan 2017 06:43:02 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608AF129CF3 for ; Mon, 9 Jan 2017 06:43:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 596B4205C9; Mon, 9 Jan 2017 10:02:22 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 953AB636BB; Mon, 9 Jan 2017 09:43:00 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <25c86c7d-a7ad-fb8c-8b2b-fb4f0fc6facd@gmail.com> References: <28451.1483923774@obiwan.sandelman.ca> <25c86c7d-a7ad-fb8c-8b2b-fb4f0fc6facd@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] clarify +locator-option X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:43:04 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> When I read: divert-option = [O_DIVERT, +locator-option] >> >> I think that it means that +locator-option means that one can multiple >> options, and that they would be inside an array? >> >> So, for example: >> >> [O_DIVERT, [ [O_IPv6_LOCATOR, ipv6-address, transport-proto, >> port-number], [O_IPv4_LOCATOR, ipv6-address, transport-proto, >> port-number], [O_FQDN_LOCATOR, ipv6-address, transport-proto, >> port-number]]] > I'm not sure there's an additional array. CBOR can handle arrays of > undefined length, so I think that syntax generates > [O_DIVERT, [O_IPv6_LOCATOR, ipv6-address, transport-proto, > port-number], [O_IPv4_LOCATOR, ipv6-address, transport-proto, > port-number], [O_FQDN_LOCATOR, ipv6-address, transport-proto, > port-number]] > but I'd rather hear that from Carsten to be sure. But, have specification like: response-message = [M_RESPONSE, session-id, initiator, ttl, (+locator-option // divert-option), ?objective)] so unless the () implies a level of sub-array, then there would be some unknown number of location-options, and then the last item would be objective, *if* it exists. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhzoXQACgkQgItw+93Q 3WVj9gf/div0jd0MdrWhs38saFY57sLx4fJPtw6SS90Cx4CAyDKJFXMBkgFGW0N3 EU0ineA948iR6TGmhuY2ArPy33dMvh+LZSN2QwB02WufyTaIwy+KvkCM8FDqwE33 1fOlF3+t62OxdMk6+KNuKafTSoEesDhE7DRit0BXg4Bb8aKgC5GBY80x0Z+/KpFK lSLuZlMdtoGNd0IrNiakcEo8ItUkzxd+Teh1kgw19FUsT3sDi7FtoTor3lyUH2SC l+bAlHVpkU4iyL9orOAW73z9yXJGSGJVQ6PkoQ3HTD5dNHJpZfLcrgGg9S0BXfDH JxYvOEYOV39BchA54YDtwf2B/SuZcw== =EedW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 9 11:31:44 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAD612986C; Mon, 9 Jan 2017 11:31:39 -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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148399029963.24931.3027559496253465919.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 11:31:39 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:31:39 -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 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-02.txt Pages : 14 Date : 2017-01-09 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-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 Mon Jan 9 11:40:30 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF7129DC1 for ; Mon, 9 Jan 2017 11:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEKnsvxTAXUV for ; Mon, 9 Jan 2017 11:40:27 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 86497129DC0 for ; Mon, 9 Jan 2017 11:40:27 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id 194so16656425pgd.2 for ; Mon, 09 Jan 2017 11:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=cEBBvnFLNe/bcqfkdmaWnRPq41ugY0UCR9Oy8E3JU1w=; b=ruE8DH5aj9MmE9QC49qOsckXda3to/ec+ozqn4eFWHr78KxgAOQX48vcobsLh8ZZvD N9nHdg2ZBeeek8G3KMpe+aHlLSaa4mQNryoIt7lH0ZsjxOziH+nLSgBAayOVow4wke7I AAIqaKsg8+a0ryZqjBE7Pisl0wIVLBwmC2OnFPTq/MG+KGpEAocOikJ+8BsNPRJwZMFO sRqB4NW6X3jGybfB30Plv6UQNuTN+ehRwr5Stc8Bzo1h1VzRBYSiWz1RNom25rcXv8yg kLdcb5Jvb81obf8QUkdl8CYyut7znUoN1hG5JVATEvBoHP+OUZjaiN7wSDYC22tUwOR/ L07g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cEBBvnFLNe/bcqfkdmaWnRPq41ugY0UCR9Oy8E3JU1w=; b=bbso8kvH0c/dJWUCUQXDR3nvJ4C86KV1dsKUebHYD/SGPz34rPjBSmJpb8ItoTCbf5 /Yx2RPG5/TYY/BarhRBw1+E9W4nDvlLGOkWcmnjvcOdZ8Rxgsq98XyT8JGqUA9vrqJJJ 3rE0y0YbCF68bJn3HHDl3jGvq6HgoklOrA9/eGMFftqD95WzUq/lXp3nToUymBNXfkkB pL+7Oev61y8EB2IRhTLmyWy/rEvqjApx0p4EY4wVnvehTcFG9INrGtE437IlOhN1zi8r JdBjqScFzDIUmvF2R8tnJI8KCx8Vx+OzLec3sHNNWay6uQbhKZCgBEYIUDFLOFaW4+QS 1Arg== X-Gm-Message-State: AIkVDXLEOES+nxLIbYaKEQE27Gqg97zWjwjgIs8VMuBk3zuow/MBR7vNZN/3770Mt/SY8w== X-Received: by 10.99.96.9 with SMTP id u9mr158719548pgb.151.1483990826776; Mon, 09 Jan 2017 11:40:26 -0800 (PST) Received: from [192.168.178.21] ([118.148.64.77]) by smtp.gmail.com with ESMTPSA id l63sm124837280pfl.83.2017.01.09.11.40.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 11:40:25 -0800 (PST) References: <148399029963.24931.3027559496253465919.idtracker@ietfa.amsl.com> To: anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 10 Jan 2017 08:40:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148399029963.24931.3027559496253465919.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-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:40:29 -0000 Hi, This version has the description of "Intent" replaced by a description of non-default parameter setting, since we do not yet have an Intent mechanism. This version should be implementable just with GRASP and the ACP. Please review, comments are welcome. Regards Brian On 10/01/2017 08:31, 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 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-02.txt > Pages : 14 > Date : 2017-01-09 > > 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-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-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 Mon Jan 9 15:33:29 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851931295E7 for ; Mon, 9 Jan 2017 15:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8OCmyhnDd9H for ; Mon, 9 Jan 2017 15:33:26 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210EC1293F5 for ; Mon, 9 Jan 2017 15:33:26 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 189so22903354pfu.3 for ; Mon, 09 Jan 2017 15:33:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=K7mS/j6F7/b7sA5tJ4zQwSWg9WIm8ei1oeP+zoPJuaI=; b=mUtywc4huKwTYq+s9frnKlx9hn4MPcFJ7mncSRdB68PvFFxe+xFAKVrJAW0e2lOT/4 t+Ba5zIq6tr2sBYZN2Er6NAUmctoC9F69AGqtADDT4gsGgP8A6Iuvo4xTVsm0DCByQQ6 PHNCKAawHDNlFY1jHyMdV/0d4SHW2GnKWA149ClxiaonGCJZyuEurUT8Hr/4VF1AV1Cn dteuvdvXk+u+N/c8tvrWmuIb3tuxiXmGNY27CcKMlZka58SHRRsF/kimUhRmcG8P0IX8 qdl4wz36wuJDPgkUPR+wR/YEanYYheNFUuLy30+4bTKsVV+K/hQ7B+BqZzmXzShKT9dV lIPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=K7mS/j6F7/b7sA5tJ4zQwSWg9WIm8ei1oeP+zoPJuaI=; b=pwZTaxwYEKsiJB6HTjXb6b7H0jFevXaPb1f0+M0u0oXgtBIH/rugO5SSm/anVpqiZw Yl3TlkcXdGSpSsTVw0LhkPvS9Nw7Dp/p4z/ImFjBcLCRmkt7Do/4sZofQbMEgibA66n6 71gcRJc8ujPwbD9NHF/u5LVZ+YUyQv49ufq0xH2mOZ/Wihj2G0s6Tx7yCqN+9KsVInn2 12GgS4qgiHya6y6WRgf9XSQpRLLI6NKXsMVAJorwL3Q0Why4ns5uXIDZglG61U4jhaPu OWPPNtEtfZ7r3EUVVHpn7F3huh/NfoDA4JxDAP7G+4kKvz+T7EyZ6EPdAsLFdrzBl+WB dzww== X-Gm-Message-State: AIkVDXKyG+gdjASP6GRSLpf18vV82h3CufSTvaIyyBYv0cFuE6em7UEFBoCYVspXgXo3GQ== X-Received: by 10.84.139.129 with SMTP id 1mr359892plr.178.1484004805395; Mon, 09 Jan 2017 15:33:25 -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 f3sm59104pfd.10.2017.01.09.15.33.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 15:33:24 -0800 (PST) To: Michael Richardson References: <28451.1483923774@obiwan.sandelman.ca> <25c86c7d-a7ad-fb8c-8b2b-fb4f0fc6facd@gmail.com> <26441.1483972980@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5dc9f313-2910-d7fe-9359-b52449bf809d@gmail.com> Date: Tue, 10 Jan 2017 12:33:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <26441.1483972980@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] clarify +locator-option X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 23:33:27 -0000 Regards Brian Carpenter On 10/01/2017 03:43, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> When I read: divert-option = [O_DIVERT, +locator-option] > >> > >> I think that it means that +locator-option means that one can multiple > >> options, and that they would be inside an array? > >> > >> So, for example: > >> > >> [O_DIVERT, [ [O_IPv6_LOCATOR, ipv6-address, transport-proto, > >> port-number], [O_IPv4_LOCATOR, ipv6-address, transport-proto, > >> port-number], [O_FQDN_LOCATOR, ipv6-address, transport-proto, > >> port-number]]] > > > > I'm not sure there's an additional array. CBOR can handle arrays of > > undefined length, so I think that syntax generates > > > [O_DIVERT, [O_IPv6_LOCATOR, ipv6-address, transport-proto, > > port-number], [O_IPv4_LOCATOR, ipv6-address, transport-proto, > > port-number], [O_FQDN_LOCATOR, ipv6-address, transport-proto, > > port-number]] > > > but I'd rather hear that from Carsten to be sure. > > But, have specification like: > > response-message = [M_RESPONSE, session-id, initiator, ttl, > (+locator-option // divert-option), ?objective)] > > so unless the () implies a level of sub-array, then there would be > some unknown number of location-options, and then the last item would be > objective, *if* it exists. In CDDL (...) is just a way of grouping items syntactically, it doesn't represent anything in the data. [...] signals an array and {...} signals a map, which we haven't used in GRASP. So yes, there is a possible parsing problem in that syntax, because the + signals "one or more" and the ? signals "0 or 1". So if there are at least 2 elements, the last one might be a locator or an objective. The reason I hadn't thought about this is in the comments at the beginning of my code: # - the spec allows an optional Objective option in # Response messages: not implemented To be honest I don't know what value this feature adds. It can be parsed from the CBOR, however. All options *except* objectives start with an integer. Objectives start with a text string. If you don't like that, we'd have to change the syntax slightly. Brian From nobody Thu Jan 12 09:34:00 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD99D1294BD; Thu, 12 Jan 2017 09:33:57 -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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148424243777.2935.14591600696757497157.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 09:33:57 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:33:58 -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 of the IETF. Title : An Autonomic Control Plane Authors : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-05.txt Pages : 34 Date : 2017-01-12 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-05 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 Thu Jan 12 11:17:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BCE1293E0 for ; Thu, 12 Jan 2017 11:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv8zHkaOg5ex for ; Thu, 12 Jan 2017 11:17:34 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7F3126579 for ; Thu, 12 Jan 2017 11:17:34 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id 189so17496233pfu.3 for ; Thu, 12 Jan 2017 11:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=o6sqfVmtXE0B/SbvjlFs6mFNNdvh7+ibHTgHuBXWm30=; b=XN0optC/Tu8eGBQ4xyp8j+i9E8xP4lpjG+4sHtHiIKJ7Yh26aBId1zP9xND1AHx385 kpjFe4als/rzKk08N2kxQqQl6kRygdemKOUq5p4M7dVEzQb/THsK2oIUnIUYaSSCN1fu RhhoJQ1H6o2tODebMy2Qdlt1gMZyXPA/5f+T/wiAHqs1tW7q/xiiw/4qCmDXJLLAYsG8 cogRWg0oaoBEXHCbFdQVwjYHTz4C7FZbtyxWUixLJWZZQK08FUoi6xajGoHlJHYxlZSm STinFDCDtPOH1FGUh+/2wNNgpuBpPPLEPdn1DeY8Z27MSvR2aOLYXxuO5d5GctLXtZNM zgDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=o6sqfVmtXE0B/SbvjlFs6mFNNdvh7+ibHTgHuBXWm30=; b=D7+PDlRbBCCVS7d0WvFGzCMsBRqr6B+lZdHy92JlhkqMhyMT11gJXIZkL3H+wQPz48 tyhQqp7eCL4XK8/qpRcX5SBIYZYW3Hs4Cv1t9WIB39UW5AnA925++I7220x/CqrZCWxX Jj/YSl+nP3z2+g/WDR7yPh7wzrBBIjsfAGvMW79mPOZezI55TouDTdG+IO422n1hfgUF baI7Sbi4NGtLCdsi4epwbg/1W+roTadCq1sw80v0c5ko0ya4TvZwLUQzS7m634J1wAyF O5mTcim3hZWm/ej+1OD6Ixkch3z1f9RGbYHf7mzTK5BZsrQ2msrZHUgLyUqNHkSHgGQX dDKA== X-Gm-Message-State: AIkVDXLrvcHx+7fnSXSWPInmGHP3vmRrfX2Xp78GE6CWyzoGdSXxlU71BVI++5Xuf+uERw== X-Received: by 10.84.217.66 with SMTP id e2mr23944336plj.109.1484248653988; Thu, 12 Jan 2017 11:17:33 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id c22sm23684601pgn.12.2017.01.12.11.17.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 11:17:33 -0800 (PST) To: anima@ietf.org References: <27315.1483060778@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 13 Jan 2017 08:17:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <27315.1483060778@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Hackathon at IETF94 thoughts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 19:17:37 -0000 Apart from me and Michael, who else wants to work on code and run it in Chicago on March 25 and 26? We need BRSKI, ACP and GRASP. Regards Brian On 30/12/2016 14:19, Michael Richardson wrote: > > Brian and I have been discussing thoughts about an ANIMA Hackathon at IETF94. > > The question has been: how much code would be ready, and how much > interoperation could be actually attempt! > > In my mind the first bakeoff/hackathon will likely be a bit underwhelming > because people won't have enough code yet. That's okay: the point is to > invite people to come and consider how they are going to do things. > i.e. this is as much marketing is it is interoperation, but it's > marketing to get participation in the future!!!! > > We can't plan just the one hackathon. > > From my point of view, I see the several stages/actors of bootstrap. > I'm listing them because they can be mock'ed if someone has no code for this. > > 1) registrar. > 2) network of ACP nodes running GRASP, of which one is a willing proxy. > 3) new pledge > 4) vendor / manufacturer CA > > I have some (RubyOnRails) code that can operate as a bit of a registrar, and > I'll have more by March that can do more EST things, but the code I have now > can be used to manually generate certificates. So, ANIMA systems that > don't have bootstrap code could be manually bootstrapped, and we likely will > learn something doing that. > > The network of ACP nodes running GRASP, at least on Linux, is "trivial" to > setup in a mock situation. > > At least, it's easy for me to do, and I would very much be happy to share > that experience, so you'd have "installed ACP code". > > Could we find someone with enough Microsoft Windows IPsec clue to set up > tunnel on Windows, and figure out how to get the right certificates loaded? > I dunno... maybe someone here knows how. Also Cisco, Juniper, Ericsson, etc > routers might be manually configured to do ACP tunnels; and we likely learn > something trying to make things interoperate. > > So even if we couldn't get RPL to operate across a multi-platform situation, > we might still be able to, for instance, M_FLOOD something across a bunch of > IPsec P2P tunnels connecting things. That would be a significant > accomplishment in my mind for a first attempt. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Jan 12 12:27:13 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C431A1294B7 for ; Thu, 12 Jan 2017 12:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.734 X-Spam-Level: X-Spam-Status: No, score=-6.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBJIFcioDoZV for ; Thu, 12 Jan 2017 12:27:09 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 405BA129459 for ; Thu, 12 Jan 2017 12:27:08 -0800 (PST) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id v0CKR6g3001957 for ; Thu, 12 Jan 2017 15:27:06 -0500 To: anima@ietf.org References: <27315.1483060778@obiwan.sandelman.ca> From: William Atwood Organization: Concordia University, Montreal Message-ID: <20971c47-420d-cc6a-3009-384a97e3071e@concordia.ca> Date: Thu, 12 Jan 2017 15:27:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2017-01-12 15:27:06 EST Archived-At: Subject: Re: [Anima] Hackathon at IETF94 thoughts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:27:12 -0000 Brian, Michael, I am very interested in this work. IF I can get somewhat up to speed, and IF I can sort out the travel support, I would very much like to come early to Chicago and participate in a Hackathon. If it does not work out, I live two hours from Ottawa by car, so I could possibly visit my children and have a (smaller) hackathon in Ottawa with Michael. I have in my lab at Concordia a collection of ten (older) PCs running Ubuntu, plus two collections of 4 machines running a variety of Linux flavors. I don't have any IPv6 support (yet) in the lab, but the university does have an IPv6 address range assigned, and I am sure that I could get my hands on as many (small) pieces of this as I could need. (If not, I can always set up my Freenet6 /56 at the university. However, Freenet6 is about to go away...) Getting up to speed is partly the reading that I have to do, and partly finding a suitable Master's student to dig into the project. For Chicago, I could probably bring three Dell Latitude laptops: E5450 (i5-5200U, Windows 7, Ubuntu), E6400 (Core 2 Duo P9500, Windows 7, Ubuntu), C600 (Pentium III, Lubuntu only). Bill On 12/01/2017 2:17 PM, Brian E Carpenter wrote: > Apart from me and Michael, who else wants to work on code and run > it in Chicago on March 25 and 26? We need BRSKI, ACP and GRASP. > > Regards > Brian > > On 30/12/2016 14:19, Michael Richardson wrote: >> >> Brian and I have been discussing thoughts about an ANIMA Hackathon at IETF94. >> >> The question has been: how much code would be ready, and how much >> interoperation could be actually attempt! >> >> In my mind the first bakeoff/hackathon will likely be a bit underwhelming >> because people won't have enough code yet. That's okay: the point is to >> invite people to come and consider how they are going to do things. >> i.e. this is as much marketing is it is interoperation, but it's >> marketing to get participation in the future!!!! >> >> We can't plan just the one hackathon. >> >> From my point of view, I see the several stages/actors of bootstrap. >> I'm listing them because they can be mock'ed if someone has no code for this. >> >> 1) registrar. >> 2) network of ACP nodes running GRASP, of which one is a willing proxy. >> 3) new pledge >> 4) vendor / manufacturer CA >> >> I have some (RubyOnRails) code that can operate as a bit of a registrar, and >> I'll have more by March that can do more EST things, but the code I have now >> can be used to manually generate certificates. So, ANIMA systems that >> don't have bootstrap code could be manually bootstrapped, and we likely will >> learn something doing that. >> >> The network of ACP nodes running GRASP, at least on Linux, is "trivial" to >> setup in a mock situation. >> >> At least, it's easy for me to do, and I would very much be happy to share >> that experience, so you'd have "installed ACP code". >> >> Could we find someone with enough Microsoft Windows IPsec clue to set up >> tunnel on Windows, and figure out how to get the right certificates loaded? >> I dunno... maybe someone here knows how. Also Cisco, Juniper, Ericsson, etc >> routers might be manually configured to do ACP tunnels; and we likely learn >> something trying to make things interoperate. >> >> So even if we couldn't get RPL to operate across a multi-platform situation, >> we might still be able to, for instance, M_FLOOD something across a bunch of >> IPsec P2P tunnels connecting things. That would be a significant >> accomplishment in my mind for a first attempt. >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Thu Jan 12 13:03:37 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FE1127A90 for ; Thu, 12 Jan 2017 13:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNMChHqY2BAS for ; Thu, 12 Jan 2017 13:03:34 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 35F9F1294FD for ; Thu, 12 Jan 2017 12:57:12 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id b22so4934042pfd.3 for ; Thu, 12 Jan 2017 12:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Kj5vIcBOznUaJXnGg7uul3KqgW4FdgweuIrWYuJPFpQ=; b=peYWdCeGt3XDR8uhafjnFWtLI77kVzxO4xLidYR1XZnS7moTr1HDU2Png9uS+Ssgpb g4B+DIHU8p0dBB/AXzcpOyKnvBmm31CEb9++KthgDsphD8kBdUdZUEuq8rm+jIIfD0BF RuSIGoSLPKf6jk4xASxyirIw5nBusmRTbCw1WbADBvJNsDVPIc4M5PGRxSFoxu/hzXIW MHPhLavcO5c4BXdhNkNDmt0lwN+vudjPA/Smbj3bYqP3mRDUWuzsALlbIREJIgqf0Sbw 97n11/NW1O8+jS70Q2r0RN8fOT3HsbdxnPO9XtmbcEpLqfma2Qg6HwLZ8bIhrMtQ9UWt A6BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Kj5vIcBOznUaJXnGg7uul3KqgW4FdgweuIrWYuJPFpQ=; b=FYnKSRquKiiwQCHvfS+CBTemedPH2AK5LNdMi1846GSeOYgX8/o1RCw7eTQUxqT7XV mGlWoIo+K119x1ir4uNOPdb1enUiNZ+PSVIb50RJ5ad8dmyrcGsuo1XB9kaEcm8d4AUr FLvZkqCGIOnxYa4XP8mhalUh7IGXv6Oqk+rHq0gN7murgaF4aGcbc+3Vaoa9W2IVc9iI 5WAANGKa3cUTLKQiLO2UZMUjebw/oCNbO4W5Jk5YqAab/6llmq4CiOQpobQwdHJfLE2s /mEoLNHSTHVFAgvRxPILcawLWIiRdOY9IqKVSrGwTfvBeUA9yMpwNd/ovqPIXnx2z1b6 k6pQ== X-Gm-Message-State: AIkVDXLqGPs72cY+ceKIzNiy1ZxKULscOk8z3EfzlNoaoSuZ6bx7kXy1ZckKyUCnbt41Rg== X-Received: by 10.99.149.1 with SMTP id p1mr20071798pgd.21.1484254631531; Thu, 12 Jan 2017 12:57:11 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id w65sm23779202pfw.9.2017.01.12.12.57.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 12:57:11 -0800 (PST) To: William Atwood References: <27315.1483060778@obiwan.sandelman.ca> <20971c47-420d-cc6a-3009-384a97e3071e@concordia.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 13 Jan 2017 09:57:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20971c47-420d-cc6a-3009-384a97e3071e@concordia.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] Hackathon at IETF94 thoughts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:03:36 -0000 Great. > but the > university does have an IPv6 address range assigned You don't even need it, if you can persuade your lab router to announce a ULA prefix. For my code, you need Python 3 but that seems to come with recent Linux flavours. https://www.cs.auckland.ac.nz/~brian/graspy/ (start with https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf) Regards Brian On 13/01/2017 09:27, William Atwood wrote: > Brian, Michael, > > I am very interested in this work. IF I can get somewhat up to speed, > and IF I can sort out the travel support, I would very much like to come > early to Chicago and participate in a Hackathon. If it does not work > out, I live two hours from Ottawa by car, so I could possibly visit my > children and have a (smaller) hackathon in Ottawa with Michael. > > I have in my lab at Concordia a collection of ten (older) PCs running > Ubuntu, plus two collections of 4 machines running a variety of Linux > flavors. I don't have any IPv6 support (yet) in the lab, but the > university does have an IPv6 address range assigned, and I am sure that > I could get my hands on as many (small) pieces of this as I could need. > (If not, I can always set up my Freenet6 /56 at the university. > However, Freenet6 is about to go away...) > > Getting up to speed is partly the reading that I have to do, and partly > finding a suitable Master's student to dig into the project. > > For Chicago, I could probably bring three Dell Latitude laptops: E5450 > (i5-5200U, Windows 7, Ubuntu), E6400 (Core 2 Duo P9500, Windows 7, > Ubuntu), C600 (Pentium III, Lubuntu only). > > Bill > > On 12/01/2017 2:17 PM, Brian E Carpenter wrote: >> Apart from me and Michael, who else wants to work on code and run >> it in Chicago on March 25 and 26? We need BRSKI, ACP and GRASP. >> >> Regards >> Brian >> >> On 30/12/2016 14:19, Michael Richardson wrote: >>> >>> Brian and I have been discussing thoughts about an ANIMA Hackathon at IETF94. >>> >>> The question has been: how much code would be ready, and how much >>> interoperation could be actually attempt! >>> >>> In my mind the first bakeoff/hackathon will likely be a bit underwhelming >>> because people won't have enough code yet. That's okay: the point is to >>> invite people to come and consider how they are going to do things. >>> i.e. this is as much marketing is it is interoperation, but it's >>> marketing to get participation in the future!!!! >>> >>> We can't plan just the one hackathon. >>> >>> From my point of view, I see the several stages/actors of bootstrap. >>> I'm listing them because they can be mock'ed if someone has no code for this. >>> >>> 1) registrar. >>> 2) network of ACP nodes running GRASP, of which one is a willing proxy. >>> 3) new pledge >>> 4) vendor / manufacturer CA >>> >>> I have some (RubyOnRails) code that can operate as a bit of a registrar, and >>> I'll have more by March that can do more EST things, but the code I have now >>> can be used to manually generate certificates. So, ANIMA systems that >>> don't have bootstrap code could be manually bootstrapped, and we likely will >>> learn something doing that. >>> >>> The network of ACP nodes running GRASP, at least on Linux, is "trivial" to >>> setup in a mock situation. >>> >>> At least, it's easy for me to do, and I would very much be happy to share >>> that experience, so you'd have "installed ACP code". >>> >>> Could we find someone with enough Microsoft Windows IPsec clue to set up >>> tunnel on Windows, and figure out how to get the right certificates loaded? >>> I dunno... maybe someone here knows how. Also Cisco, Juniper, Ericsson, etc >>> routers might be manually configured to do ACP tunnels; and we likely learn >>> something trying to make things interoperate. >>> >>> So even if we couldn't get RPL to operate across a multi-platform situation, >>> we might still be able to, for instance, M_FLOOD something across a bunch of >>> IPsec P2P tunnels connecting things. That would be a significant >>> accomplishment in my mind for a first attempt. >>> >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > From nobody Thu Jan 12 13:30:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD34129499 for ; Thu, 12 Jan 2017 13:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beEVWfABhFj7 for ; Thu, 12 Jan 2017 13:30:19 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A1E129514 for ; Thu, 12 Jan 2017 13:30:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B9657203AD; Thu, 12 Jan 2017 16:49:47 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A71836381A; Thu, 12 Jan 2017 16:30:14 -0500 (EST) From: Michael Richardson To: William Atwood In-Reply-To: <20971c47-420d-cc6a-3009-384a97e3071e@concordia.ca> References: <27315.1483060778@obiwan.sandelman.ca> <20971c47-420d-cc6a-3009-384a97e3071e@concordia.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] Hackathon at IETF94 thoughts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:30:21 -0000 --=-=-= Content-Type: text/plain William Atwood wrote: > I have in my lab at Concordia a collection of ten (older) PCs running > Ubuntu, plus two collections of 4 machines running a variety of Linux > flavors. I don't have any IPv6 support (yet) in the lab, but the > university does have an IPv6 address range assigned, and I am sure that > I could get my hands on as many (small) pieces of this as I could need. > (If not, I can always set up my Freenet6 /56 at the university. > However, Freenet6 is about to go away...) While I strongly encourage you to go through the effort to get v6 into your lab, you don't need externally functioning IPv6 to have the ACP work. > Getting up to speed is partly the reading that I have to do, and partly > finding a suitable Master's student to dig into the project. I am open to having a meet up among us, but it may be easier for me to bring things to you in Feb or early March. It would make sense to do that after you have a student. Or you can come visit me at my credil.org office, which is in the innovation build of UQO.ca. (Which can't even spell IPv6) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlh39WYACgkQgItw+93Q 3WVe5wf/ex/sMw792BmJnNmAKqv6zYE9s/rOSLyG/+LGQvrVZKZdmqHx3qk6XxgK VjvJQPjNtiAs46dKFCceumQIMlgdGJEm6Nibqcsvfp1b5kG6Zne6qrTM7Kr6pf5d +B8SL0lkZO4dEj5ygbqcVK+Z+w5A+kTIf0/+tEjt3zrqN34f7knnUEK3a9dTeqvu 5oEVyR2B16pvnhMFN9QkXJmurmA3WHSqKXTaqd1x8JvtaRb0ZILMKpsPepLoPlaW p3/zfOZO7raDLbCccoReZ59yqWzBzlDZkpOynHjj2Jw5R5HOH1FFSQWG30Vboor5 o5vqhUwqNN1zHgw1zyo8QXbBP8mECw== =As67 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 18 05:52:15 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4D12952C for ; Wed, 18 Jan 2017 05:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ7UcjeeQXFP for ; Wed, 18 Jan 2017 05:52:10 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5880F129404 for ; Wed, 18 Jan 2017 05:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15568; q=dns/txt; s=iport; t=1484747530; x=1485957130; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BKJNJLS6FlMDoi6famn05vwxTsK2dOfkfZX6TPB2lS0=; b=c7msRcBIc75T3TKYuKJXGYmEQdPxyv/NDNkFiHtBDN+nOt8nhQ4P1voh CxX9HjWeuK0ss8+A3MCDao0Lt8lU55S9N50e3zfEgS18mWIKHiUUAnFpV rF5va9JfkzTGFMfN28D1ziF9o6VxRPcmzaYXFfyrviHwpQ5wi6AK+1XkF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAQAbcn9Y/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoPAQEBAQEfX4EJB4NKigiSApUsggsshXYCGoFZPxgBAgEBAQE?= =?us-ascii?q?BAQFjHQuEaQEBAQQjBA1AAw4EAgEIEQQBAQMCIwMCAgIwFAEGAQEFAwIEEwgTi?= =?us-ascii?q?GgOr0WBazqKKAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VAgm6CAIMMgRkBKhA?= =?us-ascii?q?hAoJMgl4FiH6GKYwaAYZegxeHY4IAUYQ9iWiSbgEfOIFEFRgihDYBHBiBSHMBh?= =?us-ascii?q?kMBJYEKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,249,1477958400"; d="scan'208";a="373249983" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jan 2017 13:52:09 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0IDq9sP014612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Jan 2017 13:52:09 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jan 2017 07:52:08 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Wed, 18 Jan 2017 07:52:08 -0600 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-ietf-anima-autonomic-control-plane-05.txt Thread-Index: AQHSbPoSj7i0VHlWN0CCHKKqSBLewKE+SMDQ Date: Wed, 18 Jan 2017 13:52:08 +0000 Message-ID: <177e00107b464e8aac910aeb811134f6@XCH-RCD-006.cisco.com> References: <148424243788.2935.16541044798344858576.idtracker@ietfa.amsl.com> In-Reply-To: <148424243788.2935.16541044798344858576.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-autonomic-control-plane-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 13:52:13 -0000 QU5JTUEgV0csIA0KDQpZb3UgbWF5IGhhdmUgbm90aWNlZCB0aGUgbmV3IHZlcnNpb24gb2YgdGhl IEFDUCBkcmFmdCwgd2hpY2ggSSBwb3N0ZWQgbGFzdCB3ZWVrIChsaW5rcyBiZWxvdykuIA0KDQpJ 4oCZdmUgbm93IGluY29ycG9yYXRlZCBhbGwg4oCcdG8gZG9z4oCdIEkgaGFkIG5vdGVkLiBNb3N0 IGNvbW1lbnRzIGNhbWUgZnJvbSBhIHJldmlldyBmcm9tIE1DUiBvbiAzMCBOb3YgKHNlZSBhbmlt YSBsaXN0KS4gSSBoYXZlIGFkZHJlc3NlZCBtb3N0IG9mIHRoZW0uIFRoZSBvbmVzIHRoYXQgSSBo YXZlIE5PVCBhZGRyZXNzZWQgYXJlIGJlbG93LiBTb21lIEkgdGhpbmsgd2Ugc2hvdWxkbuKAmXQg YWRkcmVzcyAoYWRkcyB0b28gbXVjaCBjb21wbGljYXRpb25zKSwgc29tZSBuZWVkIG1vcmUgZGlz Y3Vzc2lvbi4gSSBoYXZlIHN0YXJ0ZWQgdG8gYWRkIOKAnEVETk9URVPigJ0gaW50byB0aGUgZG9j dW1lbnQgdG8gbWFyayBwbGFjZXMgd2hlcmUgd2UgbmVlZCBtb3JlIHdvcmsuIA0KDQpXb3VsZCBs aWtlIGZlZWRiYWNrIG9uIHRoZSBuZXcgdmVyc2lvbiwgYW5kIGNvbW1lbnRzIG9uIGFsbCBiZWxv dyB0b3BpY3MuIA0KDQpNaWNoYWVsDQoNCg0KDQpOb3QgYWRkcmVzc2VkIGZyb20gTWljaGFlbCBS aWNoYXJkc29uJ3MgY29tbWVudHM6IA0KDQotLQ0KDQpJIGhhdmUgaGVhcmQgc29tZSBzYXkgdGhh dCB0aGV5IHdvdWxkIHdhbnQgdG8gZW5hYmxlIHRoZSBBQ1Agb24gaW50ZXJmYWNlcyB3aGljaCB3 ZXJlIG1hcmtlZCBBZG1pbiBEb3duLCB3aXRoIG1heWJlIGV2ZW4gc29tZSBraW5kIG9mIGF1dG8t bmVnb3RpYXRlIChvciBhdXRvLWd1ZXNzIGJhc2VkIHVwb24gZW5lcmd5IGRldGVjdGlvbikgb2Yg bGFtYmRhcy4gIElzIGl0IHdvcnRoIHNheWluZyBzb21ldGhpbmcgaW4gc2VjdGlvbiA0IGFib3V0 IHRoaXM/DQoNCk1COiBJIHRoaW5rIHRoaXMgY29tcGxpY2F0ZXMgbWF0dGVycyB0b28gbXVjaCDi gJMgc3VnZ2VzdCB0byBpZ25vcmUgZm9yIG5vdy4NCg0KLS0NCg0KPT09PQ0KICAgVGhlIGRvbWFp biBjZXJ0aWZpY2F0ZSAoTERldklEKSBvZiBhbiBhdXRvbm9taWMgbm9kZSBNVVNUIGNvbnRhaW4N CiAgIEFOSU1BIHNwZWNpZmljIGluZm9ybWF0aW9uLCBzcGVjaWZpY2FsbHkgdGhlIGRvbWFpbiBu YW1lLCBhbmQgaXRzIEFDUA0KICAgYWRkcmVzcyB3aXRoIHRoZSB6b25lLUlEIHNldCB0byB6ZXJv LiAgVGhpcyBpbmZvcm1hdGlvbiBNVVNUIGJlDQogICBlbmNvZGVkIGluIHRoZSBMRGV2SUQgaW4g dGhlIHN1YmplY3RBbHROYW1lIC8gcmZjODIyTmFtZSBmaWVsZCBpbiB0aGUNCiAgIGZvbGxvd2lu ZyB3YXk6DQoNCiAgIGFuaW1hLmFjcCs8QUNQIGFkZHJlc3M+QDxkb21haW4+DQoNCiAgIEFuIGV4 YW1wbGU6DQoNCiAgIGFuaW1hLmFjcCtGRDk5OkIwMkQ6OEVDMzowOjIwMDowOjY0MDA6MUBleGFt cGxlLmNvbQ0KDQpUaGlzIHB1dHMgc29tZSBwcmV0dHkgY2xlYXIgYW5kIHByZXR0eSBzdHJvbmcg cmVxdWlyZW1lbnRzIG9udG8gdGhlIFJlZ2lzdHJhciwgd2hpY2ggSSB0aGluayBiZWxvbmdzIGlu IHRoZSBib290c3RyYXAgZG9jdW1lbnQuICBXZSBkb24ndCByZWFsbHkgaGF2ZSBhIHBsYWNlIGZv ciB0aGlzLiAgSSB3aWxsIHN0YXJ0IGEgbmV3IHRocmVhZCBhYm91dCB0aGlzIHBhcnQuDQoNCk1C OiBPSywgYnV0IEkgbGVhdmUgaXQgZm9yIG5vdyBhbHNvIGluIEFDUCBkcmFmdC4gDQotLQ0KDQo1 LjEuMjoNCnBsZWFzZSBtb3ZlIHRoaXMgZWxzZXdoZXJlLCBhcyB0aGUgdGFibGUgaGFzIG5vdCB5 ZXQgYmVlbiBkZWZpbmVkLCBhbmQgeW91IGFyZSBhbHJlYWR5IG1ha2luZyBleGNlcHRpb25zIHRv IGl0Og0KICAgV2hlcmUgdGhlIG5leHQgYXV0b25vbWljIGRldmljZSBpcyBub3QgZGlyZWN0bHkg YWRqYWNlbnQsIHRoZQ0KICAgaW5mb3JtYXRpb24gaW4gdGhlIGFkamFjZW5jeSB0YWJsZSBjYW4g YmUgc3VwcGxlbWVudGVkIGJ5DQogICBjb25maWd1cmF0aW9uLiAgRm9yIGV4YW1wbGUsIHRoZSBu b2RlLUlEIGFuZCBJUCBhZGRyZXNzIGNvdWxkIGJlDQogICBjb25maWd1cmVkLg0KDQpUaGlzIGFs c28gc2VlbXMgbGlrZSBhbiBwcmUtbWF0dXJlIG9wdGltaXphdGlvbjoNCiAgIFRoZSBhZGphY2Vu Y3kgdGFibGUgTUFZIGNvbnRhaW4gaW5mb3JtYXRpb24gYWJvdXQgdGhlIHZhbGlkaXR5IGFuZA0K ICAgdHJ1c3Qgb2YgdGhlIGFkamFjZW50IGF1dG9ub21pYyBub2RlJ3MgY2VydGlmaWNhdGUuICBI b3dldmVyLA0KICAgc3Vic2VxdWVudCBzdGVwcyBNVVNUIGFsd2F5cyBzdGFydCB3aXRoIGF1dGhl bnRpY2F0aW5nIHRoZSBwZWVyLg0KDQpNQjogRGlzYWdyZWUgaGVyZSwgSSB0aGluayB3ZSBuZWVk IHRvIGNvdmVyIHRoYXQsIGFuZCBJIGRvbuKAmXQgc2VlIGEgYmV0dGVyIHBsYWNlLiANCg0KLS0N Cg0KSXQncyB0cnVlIHRoYXQgYSBmdWxsIG1lc2ggb2YgQUNQIGNoYW5uZWxzIHdpbGwgYmUgYnVp bHQ6IHdlIGlkZWFsbHkgbmVlZCB0byBjcmVhdGUgc29tZSBtZXRyaXggZm9yIFJQTCB0byB1c2Ug dG8gcGljayBwYXJlbnRzLiAgSXQgd291bGQgYmUgZGVzaXJlYWJsZSB0byBiZSBhd2FyZSBvZiB0 aGUgTDIgZmFicmljLg0KDQpNQjogUlBMIHBhcmFtZXRlcnMgc3RpbGwgbmVlZCB0byBiZSBhZGRy ZXNzZWQuIA0KDQotLS0NCg0KWW91IGFyZSwgSSB0aGluayBzdWdnZXN0aW5nIGhhdmluZyB0aGUg QU5zd2l0Y2hYIGJsb2NrIGZvcndhcmRpbmcgb2YgdGhlIEFMTF9HUkFTUF9ORUlHSEJPUiBtY2Fz dCBncm91cC4gIEknbSBub3Qgc3VyZSBJIGxpa2UgdGhpcyBzb2x1dGlvbi4NCg0KT25lIHBvc3Np YmxlIHNvbHV0aW9uIHRvIHRoZSBsYXJnZSBudW1iZXIgb2YgY2hhbm5lbHMgaXMgbm90IHRvIGNy ZWF0ZSB0aGUgSVBzZWMgQ0hJTEQgU0EgdW5sZXNzIG5lZWRlZC4gIFRoaXMgd291bGQgYmUgcG9z c2libGUgaWYgdGhlIElLRXYyIGRlYW1vbiB3YXMgYWxzbyB0aGUgUlBMIHJvdXRpbmcgZGFlbW9u LCBhbmQgd2UgZGlkIFJQTCBvdmVyIHRoZSBJS0V2MiBsYXllci4NCkFsc28gcmVhbGx5IHNpY2sg bGF5ZXIgdmlvbGF0aW9ucyA6LSkNCg0KTUI6IFRoaXMgc3RpbGwgbmVlZHMgZGlzY3Vzc2lvbjsg bm8gY2hhbmdlIHNvIGZhci4gDQoNCi0tDQoNCjUuMi4yOg0KICAgVW5mb3J0dW5hdGVseSwgdGhl eSBbQ0RQPyBtRE5TP10gd2lsbCBhbHNvDQogICB0ZXJtaW5hdGUgdGhlaXIgbWVzc2FnZXMgaWYg dGhleSBkbyBub3Qgc3VwcG9ydCB0aGUgQUNQIGFuZCB3b3VsZA0KICAgdGhlbiBpbmhpYml0IEFD UCBuZWlnaGJvciBkaXNjb3ZlcnkNCg0KQ2FuIHlvdSBleHBsYWluIHRoaXM/ICBJIGRvbid0IHVu ZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNheWluZyBmcm9tIHRoZSB0ZXh0Lg0KQXJlIHlvdSBzYXlp bmcgdGhhdCBhbiBMMiBzd2l0Y2ggdGhhdCBzcG9rZSBMTERQLCBidXQgZGlkbid0IHNwZWFrIEFD UCB3b3VsZCBlYXQgdGhlIExMRFAgcmF0aGVyIHRoYW4gZm9yd2FyZCBpdCwgYW5kIGluIHRoaXMg Y2FzZSwgd2Ugd2FudCB0byBmb3J3YXJkIGl0LiAgKEEgc3dpdGNoIHdoaWNoIGRpZG4ndCBzcGVh ayBMTERQIHdvdWxkIGp1c3QgZm9yd2FyZCBpdCkNCg0KTUI6IFJlLXdvcmRlZCB0aGUgc2VudGVu Y2U7IHBsZWFzZSBjaGVjayENCg0KLS0NCg0KNS40Og0KICAgRnJvbSB0aGUgdXNlLWNhc2VzIGl0 IGlzIGNsZWFyIHRoYXQgbm90IGFsbCB0eXBlIG9mIGF1dG9ub21pYyBkZXZpY2VzDQogICBjYW4g b3IgbmVlZCB0byBjb25uZWN0IGRpcmVjdGx5IHRvIGVhY2ggb3RoZXIgb3IgYXJlIGFibGUgdG8g c3VwcG9ydA0KICAgb3IgcHJlZmVyIGFsbCBwb3NzaWJsZSBtZWNoYW5pc21zLiAgRm9yIGV4YW1w bGUsIGNvZGUgc3BhY2UgbGltaXRlZA0KICAgSW9UIGRldmljZXMgbWF5IG9ubHkgc3VwcG9ydCBk VExTIChiZWNhdXNlIHRoYXQgY29kZSBleGlzdHMgYWxyZWFkeQ0KDQpJIGNsYWltIHRoYXQgYW55 ICJJb1QiIGRldmljZSB0aGF0IGlzICJiaWcgZW5vdWdoIiB0byBwYXJ0aWNpcGF0ZSBtZWFuaW5n ZnVsbHkgaW4gdGhlIEFDUCBpcyBhbHNvIGJpZyBlbm91Z2ggdG8gc3VwcG9ydCB0aGUgY29tbW9u IHByb3RvY29scyBvdGhlciB0aGFuDQpEVExTLiAgIFRoZSBBQ1Agc2hvdWxkIGJlIGNvbm5lY3Rl ZCBsaWdodGluZyBjb250cm9sbGVycywgbm90IGxpZ2h0IGJ1bGJzLg0KDQpBcyBmb3IgTWFjU0VD IHZzIElQc2VjLCBpdCBpcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgTWFjU0VDIGRvZXMgaGF2ZSBh IGtleSBtYW5hZ2VtZW50IHByb3RvY29sIGRlZmluZWQgZm9yIGl0IGJ5IHRoZSBJRUVFLCBzbyBy ZWFsbHkgdGhlIGNvbW1vbiBzaXR1YXRpb24gaXMgdGhhdCBvbmUgc3VwcG9ydHMgSUtFdjIgdG8g bmVnb3RpYXRlIGlmIG9uZSBzdXBwb3J0cyBJUHNlYyBvciBNYWNTRUMuDQoNCkFzIGZvciB0aGUg dHdvIHN0YWdlIHByb2Nlc3MsIEkgZG9uJ3Qgd2FudCB0byBkbyB0aGlzLiAgSSB3YW50IHRvIGp1 c3QgdXNlIElLRXYyLCBhbmQgSSBjbGFpbSB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gcGVvcGxlIHdo byB3aWxsIHNheSwgIkkgY2FuIG5vdCBsaXZlIHdpdGggdGhpcyIuIChPZiBjb3Vyc2UsIHNvbWUg bWF5IGhhdmUgb3RoZXIgcHJlZmVyZW5jZXMsIGJ1dCBwcmVmZXJlbmNlcyBkb2VzIG5vdCBlcXVh bCByb3VnaCBjb25zZW5zdXMpDQoNCiAgICAgLi4uQWxpY2UgbXVzdCBiZSBhYmxlDQogICAgIHRv IHNpbXVsdGFuZW91c2x5IGFjdCBhcyBhIHJlc3BvbmRlciBpbiBwYXJhbGxlbCBmb3IgYWxsIG9m IHRoZW0gLSBzbw0KICAgICB0aGF0IHNoZSBjYW4gcmVzcG9uZCB0byBhbnkgb3JkZXIgaW4gd2hp Y2ggQm9iIHdhbnRzIHRvIHByZWZlci4uLg0KDQppdCdzIHRoaXMgcGFydCB0aGF0IEkgdGhpbmsg aXMgdG9vIGNvbXBsZXggYW5kIGVycm9yIHByb25lIHRvIGNvZGUuDQoNCk1COiBOb3QgYWRkcmVz c2VkLCBub3QgY2xlYXIgd2hhdCBuZWVkcyB0byBjaGFuZ2UuIA0KDQotLQ0KDQo1LjUuMy4gIEFD UCB2aWEgZFRMUw0KU28sIGl0J3MgVURQIGFuZCB0aGVuLi4uID8gR1JFIGluc2lkZSBVRFA/ICh0 aGVyZSBpcyBhIGRyYWZ0IHRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMTkpDQoNCiAgIFdoZW4gQWxp Y2UgYW5kIEJvYiBzdWNjZXNzZnVsbHkgZXN0YWJsaXNoIHRoZSBHUkFTUC9UU0wgc2Vzc2lvbiwg dGhleQ0KICAgd2lsbCBpbml0aWFsbHkgbmVnb3RpYXRlIHRoZSBjaGFubmVsIG1lY2hhbmlzbSB0 byB1c2UuDQoNClllYWgsIG5vLiAgVG9ucyBvZiBjb2RlIHdpdGggbm8gYmVuZWZpdC4NCldobyBp cyBhY3R1YWxseSBhc2tpbmcgZm9yIHRoZXNlIG9wdGlvbnM/DQoNCk1COiBMZWZ0IGl0IGZvciBu b3csIG5lZWRzIGRpc2N1c3Npb24uIA0KDQotLQ0KDQo1LjUuNS4gIEFDUCBTZWN1cml0eSBQcm9m aWxlcw0KDQogICBBIGJhc2VsaW5lIGF1dG9ub21pYyBkZXZpY2UgTVVTVCBzdXBwb3J0IElQc2Vj IGFuZCBTSE9VTEQgc3VwcG9ydA0KICAgR1JBU1AvVExTIGFuZCBkVExTLiAgQSBjb25zdHJhaW5l ZCBhdXRvbm9taWMgZGV2aWNlIE1VU1Qgc3VwcG9ydA0KICAgZFRMUy4NCg0KaWYgd2Ugd2FudCB0 byBkbyBzb21ldGhpbmcgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMsIHRoZW4gd2Ugc2hvdWxkIHNh eSB0aGF0IHRoZXkgYWx3YXlzIGluaXRpYXRlLCB0aGF0IHRoZXkgc2hvdWxkIGpvaW4gYXMgUlBM IGxlYWZzIChzbyBubyBmb3J3YXJkaW5nIG9mIHBhY2tldHMpLCBhbmQgdGhhdCB0aGV5IHRoZSBM V0lHIHZlcnNpb24gb2YgSUtFdjIgc2hvdWxkIGJlIHN1cHBvcnRlZCwgYW5kIG1heWJlIHRoZSBk aWV0LUVTUCBtZWNoYW5pc21zLiAgV2Ugc2hvdWxkIGFsc28gYmUgY2xlYXIgaWYgd2UgYXJlIHRy eWluZyB0byBzdXBwb3J0IGNvbnN0cmFpbmVkIGRldmljZXMsIGNvbnN0cmFpbmVkIG5ldHdvcmtz LCBvciBjaGFsbGVuZ2VkIG5ldHdvcmtzLg0KDQpNQjogTGVmdCBmb3Igbm93LiANCg0KLS0NCg0K SSB3b3VsZCBsaWtlIFYgdG8gYmUgYXQgbGVhc3QgdGhyZWUgYml0cywgbWF5YmUgOCBiaXRzLg0K SW4gdGhlIGJvb3RzdHJhcCBwcm94eSBJUElQIG1lY2hhbmlzbSwgd2UgbmVlZCB0byBhbGxvY2F0 ZSBhbiBBQ1AgYWRkcmVzcyBmb3IgZWFjaCBpbnNlY3VyZSBMMi1kb21haW4gKCJwb3J0Iikgc28g dGhhdCB0cmFmZmljIGZyb20gdGhlIFJlZ2lzdHJhciAod2hpY2ggaW5zaWRlIHRoZSBJUElQIGhl YWRlciBpcyB2NkxMKSB0byBnZXQgYmFjayB0byB0aGUgY29ycmVjdCBsaW5rLWxheWVyLg0KDQpN QjogTmVlZHMgZGlzY3Vzc2lvbiwgbm90IGNoYW5nZWQgeWV0LiANCg0KLS0NCg0KSSBoYXZlIG1p eGVkIGZlZWxpbmdzIGFib3V0IHRoZSA0OC1iaXQgUmVnaXN0cmFyIElELg0KSSBrbm93IHdoeSB5 b3UgZGlkIGl0LCBhbmQgd2h5IHlvdSdkIHdhbnQgdG8gdXNlIDQ4LWJpdHMuDQooSXQgdG9vayB0 d28gcmVhZHMgdG8gcmVhbGl6ZSBpdCB3YXMgdGhlIFJlZ2lzdGFyJ3MgTUFDLCBub3QgdGhlIGVu cm9sbGVkIG5vZGUncyBNQUMgYWRkcmVzcykuDQoNClNvIHRoZSBkaWFncmFtIGlzIHJlYWxseToN Cg0KICAgICAgICA0OCAgICAgICAgMyAgIDEzICAgICAgICAgNDggICAgICAgICAgMTUgICAgICAg IDENCiAgICstLS0tLS0tLS0tLS0tKy0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t Ky0tLSsNCiAgIHwgaGFzaChkb21haW4pfFR8IFpvbmVJRCB8IFJlZ2lzdGFyIElEIHxEZXZpY2Ug TnVtfCBWIHwNCiAgICstLS0tLS0tLS0tLS0tKy0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tKy0tLSsNCg0KU2luY2Ugd2UgbmV2ZXIgY2FyZSBhYm91dCB0aGUgLzY0IGJvdW5kYXJ5 IGluIFJQTCwgc2luY2Ugd2UgcGFzcyBhcm91bmQNCi8xMjggcm91dGVzIGluIHRoZSBBQ1AsIGRv IHdlIGNhcmUgaWYgd2UndmUgcGxhY2VkIHRoZSBSZWdpc3RhciBJRCBoZXJlPyAgQ2xlYXJseSBp dCBpcyBuaWNlIGJlY2F1c2Ugd2UgaGF2ZSBab25lSUQgYXMgYSAvNjQuDQoNCkknbSB0aGlua2lu ZyB0aGF0IEkgd291bGQgbGlrZSB0byBpbnN0ZWFkIGRvIHNvbWV0aGluZyBsaWtlOg0KDQogICAg ICAgIDQ4ICAgICAgICAyICAgNDYgICAgICAgICAgICAzMiAgICAgICAxNg0KICAgKy0tLS0tLS0t LS0tLS0rLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KICAgfCBoYXNo KGRvbWFpbil8VHwgUmVnaXN0YXIgSUR8RGV2aWNlIE51bXwgViAgICAgICAgICAgfA0KICAgKy0t LS0tLS0tLS0tLS0rLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KDQpX aGVyZSBSZWdpc3RhcklEIGlzIHN0aWxsIE1BQyBhZGRyZXNzIGRlcml2ZWQsIHdpdGggdGhlIEcg YW5kIFUgYml0cyByZW1vdmVkLCBhbmQgd2Ugbm93IGhhdmUgMl4zMiBzcGFjZSBmb3IgZGV2aWNl cyAoSSB0aGluayAyXjE2IG1pZ2h0IGJlIHRvbyBzbWFsbCBpZiBvbmUgaW5jbHVkZXMgQ1BFIGRl dmljZXMgaW4gdGhlIENQRSwgYW5kIG9uZSBoYXMgc29tZSBjaHVybiBvdmVyIGEgZGVjYWRlKyBv ZiBDUEUgZGV2aWNlcykuDQpUaGVyZSBpcyBub3cgMTYgYml0cyBhdmFpbGFibGUgdG8gZG8gdGhp bmdzLCBhbmQgd2UgY2FuIHBhc3MgLzExNCByb3V0ZXMgYXJvdW5kIGluIFJQTCwgYnR3LiAgSSdt IG9wZW4gYXMgdG8gd2hldGhlciBWIHJlbWFpbnMgYXMgYSBzcGVjaWZpZWQgYml0LCBvciBpZiAi cGh5c2ljYWwiIG1hY2hpbmUgaXMganVzdCBWPTB4MDAwMC4NCg0KSWYgd2UgbmVlZCBab25lSUQs IHRoZW4gSSBzdWdnZXN0IHRoYXQgd2UgY2FuIGVhc2lseSBnZXQgaXQgYnkgaGF2aW5nIGRpZmZl cmVudCBSZWdpc3RyYXIgSURzIGZvciBlYWNoIHpvbmUuICBJZiB5b3Ugd2FudCB0aGVtIGluIGRp ZmZlcmVudCAvNjRzIHRoZW4ganVzdCBjb25zdHJ1Y3QgdGhlIFJlZ2lzdGFySUQgdG8gYmUgdW5p cXVlIGluIHRoZSB1cHBlciAxNCBiaXRzLg0KDQpNQjogVGhpcyBuZWVkcyBtb3JlIGRpc2N1c3Np b24uIFRoZSBhYm92ZSBwcm9wb3NhbCBhZGRzIHVwIHRvIDE0NCBiaXRzLCB3aGljaCBkb2VzbuKA mXQgZml0IGludG8gYW4gSVB2NiBhZGRyZXNzIDstKSAgIEkgYWRkZWQgYW4gRUROT1RFIGluIHRo ZSBkcmFmdCBmb3Igbm93Lg0KDQotLQ0KDQo1LjguNDoNCiAgIElmIGEgZGV2aWNlIGxlYXJucyB0 aHJvdWdoIGFuIGF1dG9ub21pYyBtZXRob2Qgb3IgdGhyb3VnaA0KICAgY29uZmlndXJhdGlvbiB0 aGF0IGl0IGlzIHBhcnQgb2YgYSB6b25lLCBpdCBNVVNUIGFsc28gcmVzcG9uZCB0byBpdHMNCiAg IEFDUCBhZGRyZXNzIHdpdGggdGhhdCB6b25lIG51bWJlci4gIEluIHRoaXMgY2FzZSB0aGUgQUNQ IGxvb3BiYWNrIGlzDQoNCkkgZG9uJ3QgbGlrZSB0aGlzLCBiZWNhdXNlIGl0IHNlcmlvdXNseSBi cmVha3MgdXAgdGhlIGFnZ3JlZ2F0aW9uIHRoYXQgbWlnaHQgb3RoZXJ3aXNlIGJlIHBvc3NpYmxl LiAgSSBkb24ndCB3YW50IGV4cGxpY2l0IFpvbmVJRCwgSSdkIHJhdGhlciBnbyB3aXRoIHRoZSBO b3RlOiBpbiA1LjguNCwgb3IgdXNlIHRoZSBSZWdpc3RyYXJJRC4NCg0KTUI6IERpc2FncmVlIGhl cmUuIEFnZ3JlZ2F0aW9uIGlzIHBvc3NpYmxlLCBiZWNhdXNlIHRoZSBkZXZpY2UgbXVzdCBsaXN0 ZW4gdG8gYm90aC4gDQoNCi0tDQoNCjUuMTA6DQogICAgICAgIFdoZW4gd2UgZXN0YWJsaXNoIG11 bHRpcGxlIEFDUCBjaGFubmVscyBSUEwgKG9yIGFueSBvdGhlciByb3V0aW5nDQogICAgICAgIHBy b3RvY29sISkgd2lsbCBuZWVkIHRvIGhhdmUgc29tZSBtZXRyaWNzIHRvIHBpY2sgYW1vbmcgdGhl bS4NCiAgICAgICAgSSdtIG5vdCBzdXJlIHdoYXQgd2UgY2FuIHByb3ZpZGUgaGVyZSwgYXQgdGhl IGxlYXN0LCB3ZSBzaG91bGQNCiAgICAgICAgcHJlZmVyIHNob3J0ZXIgcGF0aHMgdG8gbG9uZ2Vy IG9uZXMuDQoNCk1COiBPdXIgcHJlLXN0YW5kYXJkIGltcGxlbWVudGF0aW9uIHRyZWF0cyBhbGwg QUNQIGxpbmtzIGVxdWFsLCBhbmQgbGV04oCZcyBSUEwgZG8gaXRzIHdvcmsuIE5vIG1ldHJpY3Mg YXJlIHJlcXVpcmVkLg0KDQotLQ0KDQogICAgICAgIElmIGFuIGF1dG9ub21pYyBub2RlIGRlY2lk ZXMgdG8gaGF2ZSBhIGxpbWl0IG9uIGhvdyBtYW55IGNoYW5uZWxzDQogICAgICAgIGl0IHNldHMg dXAsIG9yIGhvdyBtYW55IGl0IHdpbGwgc2V0dXAgd2l0aCBhIHBhcnRpY3VsYXIgcGVlciwNCiAg ICAgICAgaXQgU0hPVUxEIGluZGljYXRlIGEgY2xlYXIgInRoYW5rcywgSSdtIGZ1bGwiIG1lc3Nh Z2UgaW4gdGhlIEFDUA0KICAgICAgICBjaGFubmVsIG5lZ290aWF0aW9uIHByb3RvY29sIChpLmUu IGFuIElLRXYyIE5vdGlmaWNhdGlvbikuDQoNCk1COiBTdWdnZXN0IHRvIGxlYXZlIHRoYXQgZm9y IGxhdGVyIG9wdGltaXNhdGlvbnMuIEl0IHdpbGwgbGVhZCB0byBpbmNvbXBsZXRlIG92ZXJsYXlz IGFuZCBvcGVuIGEgc2V0IG9mIG5ldyBxdWVzdGlvbnMuIEZvciB0aGUgZmlyc3QgcGhhc2Ugd2Ug c2hvdWxkIGp1c3Qgc3RhdGUg4oCcb25lIGxpbmsgLS0+IG9uZSBBQ1AgY2hhbm5lbOKAnS4gDQoN Ci0tDQoNCg0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiAxMiBKYW51YXJ5IDIwMTcgMTg6MzQNClRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJl aHJpbmcpIDxtYmVocmluZ0BjaXNjby5jb20+OyBhbmltYS1jaGFpcnNAaWV0Zi5vcmc7IFRvZXJs ZXNzIEVja2VydCA8dHRlK2lldGZAY3MuZmF1LmRlPjsgU3RlaW50aG9yIEJqYXJuYXNvbiA8c2Jq YXJuYXNvbkBhcmJvci5uZXQ+OyBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmlu Z0BjaXNjby5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDUudHh0DQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDUu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgSC4gQmVocmlu Z2VyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWll dGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUNClJldmlzaW9uOgkwNQ0KVGl0bGU6CQlB biBBdXRvbm9taWMgQ29udHJvbCBQbGFuZQ0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wMS0xMQ0KR3Jv dXA6CQlhbmltYQ0KUGFnZXM6CQkzNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBs YW5lLTA1LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUvDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYXV0b25v bWljLWNvbnRyb2wtcGxhbmUtMDUNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZS0w NQ0KDQpBYnN0cmFjdDoNCiAgIEF1dG9ub21pYyBmdW5jdGlvbnMgbmVlZCBhIGNvbnRyb2wgcGxh bmUgdG8gY29tbXVuaWNhdGUsIHdoaWNoDQogICBkZXBlbmRzIG9uIHNvbWUgYWRkcmVzc2luZyBh bmQgcm91dGluZy4gIFRoaXMgQXV0b25vbWljIENvbnRyb2wgUGxhbmUNCiAgIHNob3VsZCBpZGVh bGx5IGJlIHNlbGYtbWFuYWdpbmcsIGFuZCBhcyBpbmRlcGVuZGVudCBhcyBwb3NzaWJsZSBvZg0K ICAgY29uZmlndXJhdGlvbi4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiAiQXV0b25vbWljIENv bnRyb2wgUGxhbmUiLA0KICAgd2l0aCB0aGUgcHJpbWFyeSB1c2UgYXMgYSBjb250cm9sIHBsYW5l IGZvciBhdXRvbm9taWMgZnVuY3Rpb25zLiAgSXQNCiAgIGFsc28gc2VydmVzIGFzIGEgInZpcnR1 YWwgb3V0IG9mIGJhbmQgY2hhbm5lbCIgZm9yIE9BTSBjb21tdW5pY2F0aW9ucw0KICAgb3ZlciBh IG5ldHdvcmsgdGhhdCBpcyBub3QgY29uZmlndXJlZCwgb3IgbWlzLWNvbmZpZ3VyZWQuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Jan 20 07:26:24 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9787129961; Fri, 20 Jan 2017 07:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvcE20dWtJn1; Fri, 20 Jan 2017 07:26:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5EF129BDC; Fri, 20 Jan 2017 07:26:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F11DCE1E4; Fri, 20 Jan 2017 10:46:07 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 03837636BB; Fri, 20 Jan 2017 10:26:08 -0500 (EST) From: Michael Richardson To: anima@ietf.org, 6tisch@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap , netconf@ietf.org, 6tisch-security@ietf.org Subject: [Anima] converging on some common terminology X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: anima@ietf.org, 6tisch@ietf.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:26:11 -0000 --=-=-= Content-Type: text/plain At the 6tisch-security design team call and then on the anima bootstrap call on Tuesday, we discussed merging of terminology as an important step to getting all the bootstrap ideas together. These are the terms which we have concluded on: 1) PLEDGE. replaces Joining Node and "New Node" 2) JOIN PROXY. replaces Join Assistant and bare "Proxy" 3) JOIN REGISTRAR (and Coordinator). Replaces bare "Registrar", and JCE. The "Coordinator" part is considered a seperate, co-located, but optional role. 4) MASA. remains the same. 5) vendor provided interface that MASA uses to talk to remains unnamed. Here are the proposals therefore: ANIMA, dtbootstrap document. was already using PLEDGE. (KEEP IT) PROXY -> JOIN PROXY. REGISTRAR -> officially, "Join Registrar", maybe be shortened in the text to "Registrar" where this is unambiguous. 6tisch-dtsecurity ("Phase one") and 6tisch-minimal security ("One-Touch/Phase two"): Was using Joining Node --> Pledge. Was using Join Assistant --> Join Proxy Was using Joint Coordination Entity (JCE) -> Join Registrar and Coordinator. Adds term MASA. Additional terms which we need to import: 1) "drop ship" 2) "imprint", 3) "enrollment", 4) "audit token", "ownership token" <- from draft-ietf-anima-voucher. There also some discussion about the terminology used by 802.15.10: "mesh root" <- has a coordinator role and a registrar role as I understand it. We asked if: Registrar and Coordinator always co-located? We thought so, but there could be exceptions, and it might be out of scope. ACTION ITEMS ============ 1) ANIMA documents to update terms, and be authoritative for terms. 2) 6tisch documents to update terms, pointing at ANIMA and 6tisch terminology. 3) 6tisch terminology document to include the terms as being imported from ANIMA. 4) netconf: probably just adjust terminology to point at when they terms are the same as ANIMA, or when they are different. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAliCLA8ACgkQgItw+93Q 3WXILggAikWHJ5gI/lcU8OmBhhUolxtusxq/watPkHC4XwQb5rT54dXtQigsGH72 1F+4JMRS9VxunGSqnQPeA+fL9XUubzxvaAmErDe9epnqWTJzol0hM244ceymNkm3 oU40o+ZDRmiIJr4uW7qEjvBKE3Cy6YdGIL34Ybgtt9Gt7I3GYoCv/MFHv9X/yEr2 UhzwPhOqudjSKdx6jokGo7VdlFHqfMZD4T1WUxBL69NW0XvtQzI0BOvNocHHIxg5 Sa9jN6CUsgFTO0Z8BW9a2qO6bcHlnQUS+ikRmF7T4ap0k+Csq4z7ENNii0s2Qcd/ BgH3o369Q8W8UJh+bm30koYMiYTRGQ== =xsrY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 20 09:15:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE13129490; Fri, 20 Jan 2017 09:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou_QbHC1u-wo; Fri, 20 Jan 2017 09:15:44 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41F8126B6D; Fri, 20 Jan 2017 09:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2787; q=dns/txt; s=iport; t=1484932544; x=1486142144; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4ji28jbCLINaAXd269+Np6Grxx6glkR4+CqK14tdI64=; b=QAnuVK6FVnSUf9/30cKO5FJzQb7PbaPL+RyxM+HX6uarLjJp6GHse1/c 7JNyO11OYHiGVLDfoD92UT8W2Qw0XAHf+SBYn3CInbUV02PTOXIV9RPGD DkWMiCNXOUtFUSmRiLrbLDc+dhZH+SFIJaxL8hPQORH2YjAUMrNHcKXzL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQC5RIJY/4sNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAR+BaQeNVJIDlS6CDIJsgzYCghQ/FAECAQEBAQEBAWM?= =?us-ascii?q?ohGkBAQEEJxM/DAQCAQgRBAEBHwkHMhQJCAIEAQ0FCIh8sS46ikIBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdhkuEcIotBZU3hhEBkV2CAI53iB6KVQEfOIFFFYZvc4g?= =?us-ascii?q?HgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,259,1477958400"; d="scan'208";a="374460537" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2017 17:15:43 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0KHFgxQ015963 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jan 2017 17:15:43 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 20 Jan 2017 11:15:42 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 20 Jan 2017 11:15:42 -0600 From: "Pascal Thubert (pthubert)" To: "anima@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] converging on some common terminology Thread-Index: AQHSczGM3CVAjZlwgEW6Reon1I50pKFBmpdA Date: Fri, 20 Jan 2017 17:15:27 +0000 Deferred-Delivery: Fri, 20 Jan 2017 17:15:14 +0000 Message-ID: <54870898247e402499d8cfff9dbe6cce@XCH-RCD-001.cisco.com> References: <2978.1484925967@obiwan.sandelman.ca> In-Reply-To: <2978.1484925967@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: anima-bootstrap , "netconf@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [Anima] [6tisch] converging on some common terminology X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 17:15:45 -0000 Thanks a lot Michael! I do support this convergence which will help people working at the interse= ction of IOT and ANIMA, which hopefully is quite extensive. Take care, Pascal -----Original Message----- From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Michael Richards= on Sent: vendredi 20 janvier 2017 16:26 To: anima@ietf.org; 6tisch@ietf.org Cc: anima-bootstrap ; netconf@ietf.org; 6tisch-se= curity@ietf.org Subject: [6tisch] converging on some common terminology At the 6tisch-security design team call and then on the anima bootstrap cal= l on Tuesday, we discussed merging of terminology as an important step to g= etting all the bootstrap ideas together. These are the terms which we have concluded on: 1) PLEDGE. replaces Joining Node and "New Node" 2) JOIN PROXY. replaces Join Assistant and bare "Proxy" 3) JOIN REGISTRAR (and Coordinator). Replaces bare "Registrar", and JCE. The "Coordinator" part is considered a seperate, co-located, but optional role. 4) MASA. remains the same. 5) vendor provided interface that MASA uses to talk to remains unnamed. Here are the proposals therefore: ANIMA, dtbootstrap document. was already using PLEDGE. (KEEP IT) PROXY -> JOIN PROXY. REGISTRAR -> officially, "Join Registrar", maybe be shortened in the text to "Registrar" where this is unambiguous. 6tisch-dtsecurity ("Phase one") and 6tisch-minimal security ("One-Touch/Pha= se two"): Was using Joining Node --> Pledge. Was using Join Assistant --> Join Proxy Was using Joint Coordination Entit= y (JCE) -> Join Registrar and Coordinator. Adds term MASA. Additional terms which we need to import: 1) "drop ship" 2) "imprint", 3) "enrollment", 4) "audit token", "ownership token" <- from draft-ietf-anima-voucher. There also some discussion about the terminology used by 802.15.10: "mesh root" <- has a coordinator role and a registrar role as I understand it. We asked if: Registrar and Coordinator always co-located? We thought so, but there could be exceptions, and it might be out of scope. ACTION ITEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) ANIMA documents to update terms, and be authoritative for terms. 2) 6tisch documents to update terms, pointing at ANIMA and 6tisch terminolo= gy. 3) 6tisch terminology document to include the terms as being imported from = ANIMA. 4) netconf: probably just adjust terminology to point at when they terms ar= e the same as ANIMA, or when they are different. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Sat Jan 21 13:43:06 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B671293F5; Sat, 21 Jan 2017 13:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5ljedaoFkmD; Sat, 21 Jan 2017 13:42:50 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 01F631293FD; Sat, 21 Jan 2017 13:42:49 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id t6so9963284pgt.1; Sat, 21 Jan 2017 13:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2zlio+A7Zjk4w3eOZxGIXHfVQXEPNl/g/dvDott7uKQ=; b=dH1v8N7+UqeV8hlTrvGvohhgq3rvUKiM6o+LyXbZ6n9zoI5SKOiYLMQRlR6mBkqiNo fXDDtiyctE3KMOZ1/tllhHd5arRHWPHcoR64IZe3LRom/DWZ9mfjM4/eUK1hg2pkylhe shjaMENjImTc3+aQH6B9k5CBVxodHB9ZUz+LKS688OaxRYVylzrsPOtkobeNB2Q1RiZ6 UcuMQel4gyypvl0Bm9QLCrGWwfDmHWZT9aRZyydyHDXqhr0GNpIp8M2gn7ceon+IIUVM NbiHjmWjN+l2AJWoKDcc4T9CJZGnEHw1tp4hN2WhNZzsCTrH7hLVn51httqZZAWJf49u FvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=2zlio+A7Zjk4w3eOZxGIXHfVQXEPNl/g/dvDott7uKQ=; b=We5U8XyIPD0gmJ54ZBpxbVkTwSaBDmQi9TLy64ohPaJjfCjvDDua076htzSTiYN1AL e/VGS9ws7HkxdDVYN5pyD96Q5ZTy7iXZNZbUW6SkECpAGOw69+13J5I3fKloZaqRakhR +BtYO/+EItN9J+EidqkdUO6ff51r9xgxWXHX7NLPIA4jK9H/PTYT7dQDrHrDppzoYolu 2EFftipqfHfMqrZP3AGg7ujaLsb5NZQEDKBfUrrJehcGMODplfHuYZdGYCpETKxevFC4 UNy2GyG/X/2BsK+4ziAbKKlu/1VILhxmPdVcQghXZbjTyu7mWI/Irz0/LtvOgLjRV43d DuBw== X-Gm-Message-State: AIkVDXK4jH43ggHAbD8IHrLkYTjtNlewQIF2SPRa/3WDe+n75++s5MK4KHrGaz8lCCPI8A== X-Received: by 10.84.215.149 with SMTP id l21mr16336372pli.16.1485034969394; Sat, 21 Jan 2017 13:42:49 -0800 (PST) Received: from [192.168.178.21] (84.25.255.123.static.snap.net.nz. [123.255.25.84]) by smtp.gmail.com with ESMTPSA id o126sm26102154pga.34.2017.01.21.13.42.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2017 13:42:48 -0800 (PST) To: anima@ietf.org, 6tisch@ietf.org References: <2978.1484925967@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <676ffd6f-7e9a-5879-a08e-41b1c3b72ad9@gmail.com> Date: Sun, 22 Jan 2017 10:42:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2978.1484925967@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima-bootstrap , netconf@ietf.org, 6tisch-security@ietf.org Subject: Re: [Anima] [Anima-bootstrap] converging on some common terminology X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 21:42:51 -0000 So, we should adopt this terminology for the GRASP objectives, I guess. We also need to make them correspond to the latest thinking in other ways too. Any more comments on draft-carpenter-anima-ani-objectives before we update it? Regards Brian On 21/01/2017 04:26, Michael Richardson wrote: > > At the 6tisch-security design team call and then on the anima bootstrap call > on Tuesday, we discussed merging of terminology as an important step to > getting all the bootstrap ideas together. > > These are the terms which we have concluded on: > > 1) PLEDGE. replaces Joining Node and "New Node" > 2) JOIN PROXY. replaces Join Assistant and bare "Proxy" > 3) JOIN REGISTRAR (and Coordinator). Replaces bare "Registrar", and JCE. > The "Coordinator" part is considered a seperate, > co-located, but optional role. > > 4) MASA. remains the same. > 5) vendor provided interface that MASA uses to talk to remains unnamed. > > Here are the proposals therefore: > > ANIMA, dtbootstrap document. > was already using PLEDGE. (KEEP IT) > PROXY -> JOIN PROXY. > REGISTRAR -> officially, "Join Registrar", maybe be shortened > in the text to "Registrar" where this is unambiguous. > > 6tisch-dtsecurity ("Phase one") and 6tisch-minimal security ("One-Touch/Phase two"): > > Was using Joining Node --> Pledge. > Was using Join Assistant --> Join Proxy > Was using Joint Coordination Entity (JCE) -> Join Registrar and Coordinator. > Adds term MASA. > > Additional terms which we need to import: > > 1) "drop ship" > 2) "imprint", > 3) "enrollment", > 4) "audit token", "ownership token" <- from draft-ietf-anima-voucher. > > There also some discussion about the terminology used by 802.15.10: > "mesh root" <- has a coordinator role and a registrar role as I > understand it. > > We asked if: Registrar and Coordinator always co-located? > We thought so, but there could be exceptions, and it might be out of scope. > > > ACTION ITEMS > ============ > 1) ANIMA documents to update terms, and be authoritative for terms. > 2) 6tisch documents to update terms, pointing at ANIMA and 6tisch terminology. > 3) 6tisch terminology document to include the terms as being imported from ANIMA. > 4) netconf: probably just adjust terminology to point at when they terms are > the same as ANIMA, or when they are different. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap > From nobody Tue Jan 24 23:45:56 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A9B1297EF for ; Tue, 24 Jan 2017 23:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.056 X-Spam-Level: X-Spam-Status: No, score=-8.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ9hXo5oy1rn for ; Tue, 24 Jan 2017 23:45:52 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10569129841 for ; Tue, 24 Jan 2017 23:45:51 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B8D4E88D289B5 for ; Wed, 25 Jan 2017 07:45:48 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0P7jmXK031053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jan 2017 07:45:50 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0P7jgqs021165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Jan 2017 07:45:45 GMT Received: from [172.27.205.185] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 25 Jan 2017 08:45:19 +0100 References: <1d964bb8-f075-e7c3-96b6-74e45cdcb131@nokia-bell-labs.com> To: anima From: Laurent Ciavaglia Organization: Nokia Bell Labs X-Forwarded-Message-Id: <1d964bb8-f075-e7c3-96b6-74e45cdcb131@nokia-bell-labs.com> Message-ID: <1173f170-ce9c-8bc4-0544-977403d64c27@nokia-bell-labs.com> Date: Wed, 25 Jan 2017 08:45:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1d964bb8-f075-e7c3-96b6-74e45cdcb131@nokia-bell-labs.com> Content-Type: multipart/mixed; boundary="------------804F30055C811A7C125BE31A" X-Originating-IP: [135.239.27.39] Archived-At: Subject: [Anima] Fwd: [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 07:45:54 -0000 --------------804F30055C811A7C125BE31A Content-Type: multipart/alternative; boundary="------------76315D4C8ECE95A6121122B8" --------------76315D4C8ECE95A6121122B8 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Dear All, This last call might be of interest to the WG: "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection) Please provide your feedback on the NMRG mailing list by February 8th, 2017. Thanks, best regards, Laurent. -------- Forwarded Message -------- Subject: [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations Date: Wed, 25 Jan 2017 08:21:55 +0100 From: Laurent Ciavaglia Organization: Nokia Bell Labs To: nmrg@irtf.org Dear NMRG, At IETF97/Seoul, the authors of the document "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection) assessed their work was mature and asked for a RG last call. This e-mail starts a two-weeks period for evaluation of this document by the RG. Please provide your feedback on the NMRG mailing list by February 8th, 2017. Thanks, best regards, Laurent. -- -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------76315D4C8ECE95A6121122B8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Dear All,

This last call might be of interest to the WG:
    "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection)

Please provide your feedback on the NMRG mailing list by February 8th, 2017.

Thanks, best regards, Laurent.


-------- Forwarded Message --------
Subject: [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations
Date: Wed, 25 Jan 2017 08:21:55 +0100
From: Laurent Ciavaglia <Laurent.Ciavaglia@nokia-bell-labs.com>
Organization: Nokia Bell Labs
To: nmrg@irtf.org <nmrg@irtf.org>


Dear NMRG,

At IETF97/Seoul, the authors of the document "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection) assessed their work was mature and asked for a RG last call.

This e-mail starts a two-weeks period for evaluation of this document by the RG.
Please provide your feedback on the NMRG mailing list by February 8th, 2017.

Thanks, best regards, Laurent.
--


--

Laurent Ciavaglia

Nokia, Bell Labs

 

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

--------------76315D4C8ECE95A6121122B8-- --------------804F30055C811A7C125BE31A Content-Type: text/plain; charset="UTF-8"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5tcmcg bWFpbGluZyBsaXN0DQpubXJnQGlydGYub3JnDQpodHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25tcmcNCg0K --------------804F30055C811A7C125BE31A-- From nobody Tue Jan 24 23:46:09 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE433129841 for ; Tue, 24 Jan 2017 23:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.056 X-Spam-Level: X-Spam-Status: No, score=-8.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyHtYKqvQNOR for ; Tue, 24 Jan 2017 23:46:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C782B129872 for ; Tue, 24 Jan 2017 23:46:03 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id CB827E71A66D2 for ; Wed, 25 Jan 2017 07:46:00 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0P7k1Hr031686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jan 2017 07:46:02 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0P7jgr2021165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Jan 2017 07:45:59 GMT Received: from [172.27.205.185] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 25 Jan 2017 08:45:27 +0100 References: <1d964bb8-f075-e7c3-96b6-74e45cdcb131@nokia-bell-labs.com> To: anima From: Laurent Ciavaglia Organization: Nokia Bell Labs X-Forwarded-Message-Id: <1d964bb8-f075-e7c3-96b6-74e45cdcb131@nokia-bell-labs.com> Message-ID: <11b231ca-4dda-78e7-706d-b62e4e354cc3@nokia-bell-labs.com> Date: Wed, 25 Jan 2017 08:45:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1d964bb8-f075-e7c3-96b6-74e45cdcb131@nokia-bell-labs.com> Content-Type: multipart/mixed; boundary="------------9DB37ED7BB5D5AF7F7DEAF53" X-Originating-IP: [135.239.27.41] Archived-At: Subject: [Anima] [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 07:46:08 -0000 --------------9DB37ED7BB5D5AF7F7DEAF53 Content-Type: multipart/alternative; boundary="------------9C5AB2B721A0A9C6B34ABD8A" --------------9C5AB2B721A0A9C6B34ABD8A Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Dear All, This last call might be of interest to the WG: "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection) Please provide your feedback on the NMRG mailing list by February 8th, 2017. Thanks, best regards, Laurent. -------- Forwarded Message -------- Subject: [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations Date: Wed, 25 Jan 2017 08:21:55 +0100 From: Laurent Ciavaglia Organization: Nokia Bell Labs To: nmrg@irtf.org Dear NMRG, At IETF97/Seoul, the authors of the document "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection) assessed their work was mature and asked for a RG last call. This e-mail starts a two-weeks period for evaluation of this document by the RG. Please provide your feedback on the NMRG mailing list by February 8th, 2017. Thanks, best regards, Laurent. -- -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------9C5AB2B721A0A9C6B34ABD8A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Dear All,

This last call might be of interest to the WG:
    "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection)

Please provide your feedback on the NMRG mailing list by February 8th, 2017.

Thanks, best regards, Laurent.


-------- Forwarded Message --------
Subject: [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations
Date: Wed, 25 Jan 2017 08:21:55 +0100
From: Laurent Ciavaglia <Laurent.Ciavaglia@nokia-bell-labs.com>
Organization: Nokia Bell Labs
To: nmrg@irtf.org <nmrg@irtf.org>


Dear NMRG,

At IETF97/Seoul, the authors of the document "Autonomic Networking Use Case for Distributed Detection of SLA Violations" (https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection) assessed their work was mature and asked for a RG last call.

This e-mail starts a two-weeks period for evaluation of this document by the RG.
Please provide your feedback on the NMRG mailing list by February 8th, 2017.

Thanks, best regards, Laurent.
--


--

Laurent Ciavaglia

Nokia, Bell Labs

 

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

--------------9C5AB2B721A0A9C6B34ABD8A-- --------------9DB37ED7BB5D5AF7F7DEAF53 Content-Type: text/plain; charset="UTF-8"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5tcmcg bWFpbGluZyBsaXN0DQpubXJnQGlydGYub3JnDQpodHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25tcmcNCg0K --------------9DB37ED7BB5D5AF7F7DEAF53-- From nobody Sun Jan 29 14:09:00 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF75129681 for ; Sun, 29 Jan 2017 14:08: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lClLmFi_6ZbC for ; Sun, 29 Jan 2017 14:08:58 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C75E12966C for ; Sun, 29 Jan 2017 14:08:58 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id 204so95760779pge.0 for ; Sun, 29 Jan 2017 14:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=u2xjARAi5w6k/S//47mN3KGDYdJGo9DxDs0tOcAMIeg=; b=i4Mpv39B0kncTIRpP3rg99tJG71VDTeZGiTJ6clBj7yiSeqrNv8RVjQXCxDxNnewuh esH9JGeTTMucdh64LSVIunYBoOckJdPhqt7Dl+Q1CaeXTeeA0J/8GTVDrIhRVDvvKizg +7X+7LFDpRp+Yl7XOXfa37eW6rcEzeWEXO3Pn0McokRN8KGW9erTtKo55ABigDTFn9UJ OJsGW7r372Z6HHeSSxHdx+P/Ichbb9YT0y5iwbY+XJWUOsj85B4FyCn8y9BdL78H+9fL KLj+jGLz9EYPl+1VngimkjYrhSXxv84XaYdVNVM8KboZcdIQYkA3duGsHvw5h9vO2DPI ixmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=u2xjARAi5w6k/S//47mN3KGDYdJGo9DxDs0tOcAMIeg=; b=XMeCh1i73cohzZ+JXFMQJCE4Pd0g3xK4HywJ3fLCgnOO5BUMCKXDYqbGiX3dQp0TJB Bavt9L+qRjsdN/ab6VbIbjyvt9fcbGKWoPJ0QZ7faqkTOuj7ozn+YOYynlBVB77LsCk3 xLdOxOwvKlmM2rU1fEAzc/X/z7SXIAI5ViZmlH/we/vnWsbpodePKpv3yaGSmNTpfHBo UfSwWWluZfedheYeOheKMJ6Qyx5cPFtWRNfukqd1I77YSUWcsL1eKsHJ9kYsQ8yLgOh/ 8SEWPd2XNk5d4ETA/ytPzrqQSEC/3IHCVl0Sbd4zfgUoV2vr35SsU6mNmahcf072d010 VzxA== X-Gm-Message-State: AIkVDXKorJ3BgxB9GUhHmMPoEmh06gQi7GNASzYQbkD+GaRpGhPupXqqwneGzyDh3rjD/A== X-Received: by 10.84.174.1 with SMTP id q1mr27768364plb.19.1485727737367; Sun, 29 Jan 2017 14:08:57 -0800 (PST) Received: from [192.168.178.21] ([118.148.114.240]) by smtp.gmail.com with ESMTPSA id g70sm26674371pfb.50.2017.01.29.14.08.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 14:08:56 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <21051.1483896450@obiwan.sandelman.ca> <27272.1483923457@obiwan.sandelman.ca> <5372.1483926055@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5919d164-3912-096c-d02d-1775d69d4e15@gmail.com> Date: Mon, 30 Jan 2017 11:08:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <5372.1483926055@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] M_FLOOD vs M_DISCOVERY X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 22:08:59 -0000 Michael, You show the objective as ["AN_registrar", F_DISC, 255 ] i.e. with a null value. SHouldn't it include a value field that indicates the supported method(s)? I've been using values like "BRSKI-COAP" and "BRSKI-TLS". Just relying on the port numbers seems a bit schlonky. Regards Brian On 09/01/2017 14:40, Michael Richardson wrote: > > Michael Richardson wrote: > bc> Secondly, the methods aren't mutually exclusive. If the "normal" > bc> method is flooding an objective that I've called "AN_registrar" in my > bc> toy code, nothing prevents discovery/synchronize being used as a > bc> backup. > > > Question: should all the internal objectives be AN_ ?? > > https://github.com/anima-wg/anima-bootstrap/commit/853dc9334c6dcb0e6a9b199b846960be18a0504c > > I will add this to the other document, and maybe I can learn how to better present > it. > > This is the latest text I just wrote: > >
> > The registrar responds to discovery messages from the proxy > (or GRASP caches between them) as follows: >
> objective = ["AN_registrar", F_DISC, 255 ] > discovery-message = [M_DISCOVERY, session-id, initiator, objective]]]> > > Figure 6: Registrar Discovery >
> > > > The response from the registrar (or cache) will be a M_RESPONSE with the > following parameters:
> response-message = [M_RESPONSE, session-id, initiator, ttl, > (+locator-option // divert-option), ?objective)] > initiator = ACP address of Registrar > locator1 = [O_IPv6_LOCATOR, fe80::1234, 6, 443] > locator2 = [O_IPv6_LOCATOR, fe80::1234, 17, 5683] > locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]> > > Figure 7: Registrar Response >
> >
> > > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Jan 30 17:03:12 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04241129784 for ; Mon, 30 Jan 2017 17:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syASQJhCD6q9 for ; Mon, 30 Jan 2017 17:03:07 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91871294AD for ; Mon, 30 Jan 2017 17:03:06 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id e4so95929021pfg.1 for ; Mon, 30 Jan 2017 17:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=f4LxwJpE2gn/1VfpSNwBbO8s82LlJmzOU6BWz07KsWE=; b=VLHyN1MHTehFp4ivhd+X/4RiFlGooP36a+EOn2u2KeGJ9M64aKU7HY6+oW6lfhdhHB 9csoDCV0l+jrTfCeyFByw6dOwI8okFdZZKveWpwdR7PsJ/eCZl0bPM4/yhj1QHDz9rGZ wRZQLn30HRAghJL5q0YJfYuGw2TPaCwlHsaOA0nOqhN0Bv8MY5hLe1bitBnRcfk8NeGy gk1cDSc2CHuI1Vw96kCk5MBTGT9Vvor5uCsaDTfbrOBjTZBQDr4ZoDB5SGJEV6f7tvwI z5RCgA7hqJf7cfrJBihJqtbVZs45QdgQ7RP2ofiqBdcx/fHtV7eJo3K1ZdvcSwTOZ6Nx pPsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=f4LxwJpE2gn/1VfpSNwBbO8s82LlJmzOU6BWz07KsWE=; b=o/lovemmA5+YiGhmwq0DOjV+j26U0V15r7rMH8jWLchC71PafW5XEnA/53ZgNn1spR he6+hn5eVIjBhrul6ACikMNzJxYldlaU8m42pB0vKjbLGnEwBVeyBw/K3LSc2H6hpvC9 73ujzDuzzaijO8BFncPovr3OBeuYdlOEshUjk99b6+1rTuPWhRBLF9StZteThUgdbwTR kao+4Z2ZI8JkjGnbpKSx66H7BDTnzwCV2THIznNsZ+OyzR8c5nM7dVRV9ZgF86n8mIlf QwD/yGhO0otoDa6kMrN0LyLvLyTvYyuzh76qn2TKji1AaDi4Ss07MUnh66jcwpqduTFF rA7g== X-Gm-Message-State: AIkVDXIgLlHvLH1o3yAZRPr7RbwVMC9UxnqhqGCqMUH8uL6DN+qsuSzGxwc0jVdI5jlb+g== X-Received: by 10.99.228.69 with SMTP id i5mr27572934pgk.63.1485824585578; Mon, 30 Jan 2017 17:03:05 -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 o12sm35531713pfg.15.2017.01.30.17.03.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 17:03:05 -0800 (PST) To: Toerless Eckert References: <20161117221750.GA23347@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5bcd3506-cfc7-f91c-952b-4aec7f8c2f7b@gmail.com> Date: Tue, 31 Jan 2017 14:03:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20161117221750.GA23347@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:03:10 -0000 This is a reply to an old but very interesting message. We're working on an update to the draft. Some of Toerless's points will be directly addressed in the new draft. Some of them are out of scope since the draft only aims to define formats. I have commented on a few others below. On 18/11/2016 11:17, Toerless Eckert wrote: > > Thanks Brian & Bing > > Inline > >> This document defines several technical objectives for use with for > ^^^^^^^^^^^^^^^^^^^^ >> the Generic Autonomic Signaling Protocol (GRASP) >> [I-D.ietf-anima-grasp]. > > Given how GRASP defines the term "objective" very specific, it would be > good to either say "GRASP objectives" if that's what you meant to say, > or rephrase to avoid the word and resulting confusion. > > GRASP is used by several autonomic service functions for signaling > between the ASA realising those functions - as outlined in... > > Or just some good upfront statment how exactly you're using the ord > "objective" in this document and what different adjectives to it mean. > >> Autonomic Service Agents (ASAs) that realise infrastructure >> components of the Autonomic Network Infrastructure (ANI) outlined in >> the ANIMA reference model [I-D.ietf-anima-reference-model]. Also >> other early use cases are in scope. >> >> Note: This draft is posted to allow systematic discussion of the >> various objectives in a consistent way. It is quite probable that >> rather than this being published as an RFC, the various objective >> definitions will be incorporated directly in the relevant >> specifications. >> >> The reference model identifies several infrastructure components that >> will fit together to form the ANI, and early use cases for ANIMA are >> also considered: > > early autonomic use cases beyond the ANI are considered... > > Not sure if you want to summarize a bit the use cases beyond naming them, > if you want, here's what i'd say: > >> Secure Bootstrap. > > ANI use case: bootstrapping autonomic devices, non-ANI use case: bootstrapping > non-autonomic devices. > >> Autonomic Control Plane (ACP). > > Part of the ANI, serving autonomic and non-autonomic use cases. > >> Stable Connectivity of Network OAM. > > Primarily non-autonomic as it discusses SDN management via the ACP without > intent being involved (yet). > >> Intent Distribution. > > ANI use case. > > ... >> 2. Objectives for Secure Bootstrap >> >> Three components are involved in the Bootstrapping Remote Secure Key > ^^ insert ANI >> Infrastructures (BRSKI) process described in >> [I-D.ietf-anima-bootstrapping-keyinfra]: the Registrar, the Join >> Assistant (or Proxy), and the Joining Node (or Pledge). > > Pls. get the final official word for proxy/pledge. we're carrying around > too many terms and repeating them everywhere. > > Note: ... Bootstrapping has more functions, such as MASA and CA, but we > do not foresee the need for GRASP signalling with them at this time. > >> The proxy >> and the pledge are attached to the same link-layer and use link-local >> communications only, to minimize exposure to eavesdroppers and >> malicious nodes. > > I think this is not the right security claim to make. We do have important > use-cases where the proxy MUST be remote, eg: when i attach a > pledge to just an open internet connection without any prior ANI > in the vicinity. And the security comparison of this setup vs. the one with > L2 is kinda complex and should maybe not had in this doc. > > I'd suggest: > > Operationally, the most simple case is when proxy and pledge have a > link-local connection between each other. In this case, mutual discovery and > bootstrap can happen without any prior provisioning of helper information > such as DHCP parameters or DNS entries through which the pledge would have > to find the proxy otherwise. Instead, link-local multicast with GRASP can and > will be used. > >> There may be multiple hops between the proxy and >> the registrar. > > Between registrar and proxy, there can and likely will be multiple hops, > but in an autonomic network, these hops will have autoconfigured ACP and > GRASP forwarders between them, so this connectivity too is zero-touch like > the link-local connectivity beteeen pledge and proxy. > >> Therefore, two different GRASP objectives are >> required: one that is used over an existing secure network between > the (ACP) >> the registrar and the proxy, and another that is used over an >> insecure link-local hop between the proxy and the pledge. The >> security aspects and the corresponding limited instances of GRASP are >> discussed in [I-D.ietf-anima-bootstrapping-keyinfra] and >> [I-D.ietf-anima-grasp]. > > And i need to check ACP draft ifhow i capture that fact there as well. > Especially that each ACP node needs to run a GRASP forwarder for that > hop-by-hop forwarding of the GRASP flood - securely. > >> Note that since secure bootstrap takes place, by definition, on an >> incompletely secure network, the use of any protocol needs to be kept >> as simple and limited as possible. Therefore, only one GRASP message >> type is used - flooding - to avoid giving away any unnecessary >> information by any node involved. > > Suggest to move that paragraph up before the proxy/registrar text to > make reading easier. > >> A registrar announces itself to potential proxies by use of the >> "AN_registrar" objective. This is a synchronization objective >> primarily intended to be flooded throughout the network using the >> GRASP Flood Synchronization (M_FLOOD) message. In accordance with >> the design of the Flood message, a locator consisting of a specific >> IP address, IP protocol number and port number will be distributed >> with the flooded objective. An example of the objective is >> informally: >> >> ["AN_registrar", F_SYNCH, loop_count, [7, "BRSKI-TLS"]] >> >> The formal CDDL definition is >> >> registrar-objective = ["AN_registrar", F_SYNCH, loop-count, [radius, >> method]] >> >> radius = uint ; loop-count at the source node >> method = text ; name of the BRSKI method supported >> >> The 'radius' parameter allows a proxy that receives this message to >> determine its distance in hops from the registrar, by subtracting the >> received 'loop-count' from 'radius'. > > *rotfl* when i read the word radius i asked myself why we would do anything > with the radius protocol here. Diameter is also overloaded. > "sender-loop-count" would be most descriptive. > > Also, i would suggest to remove the informal representation and rather put > the information into the comments of the formal description: > > > sender-loop-count = uint ; loop-count at the source node > ; 255 is a good default. May use smaller values > ; if diameter of ACP network is known > method = text ; Name of BRSKI metho supported > ; eg: "BRSKI-TLS" > ; Should have some pointer to where values are defined. I'm reluctant to do that. Unfortunately CDDL is still a long way from the standards track, so although we definitely need to use it, we may need to adapt this document (and the GRASP spec) to avoid a formal normative reference. So I want to minimise the amount of CDDL text. > >> The 'method' parameter indicates the specific BRSKI method available >> at the given locator. The initial possible values are "BRSKI-TLS" >> and "BRSKI-COAP". A registrar that supports more than one method >> will flood multiple versions of the "AN_registrar" objective. > > Just curious: If it would be possible to encode multiple methods in a > single objective, why would you prefer to use different ones ? > > My preference for different objectives would be as follows, and maybe that's > good text to have: > > A different objective is used for each method to most easy support > the option that independent ASAs are providing the registrar function for > different methods. For example, BRSKI-COAP would most likely be focussed > to help enrol also non-autonomic pledges and could have a range of > aspects that would make implementation in a separate ASA beneficial > (eg: different scale/policies for non-autonomic pledges). Agreed, but the advantage of retaining the [*method] syntax is that it gives the implementer free choice: one or multiple methods per objective. > Another point to mention is the timing of this, eg: > > Active Registrars will send this objective flood announcement periodically > (whats a good periodicity ?). Proxies will discovery these messages. > A proxy can be active whenever it knows one or more registrars. > > And then what happens when a registrar fails: > - Can we describe the timeout behavior, eg: when/how will proxy learn > that the registrar went away. Does a registrar ASA that is going down > in a controlled fashion have a way to explicitly withdraw the objective ? > > I know, this text/these questions would go beyoond just defining the > objective encoding, but i think it would help a lot to have this type > of concise summary of the GRASP objective behavior. Not sure. Doesn't that really belong with BRSKI itself? > >> 2.1. Flooding Alternative for Proxy >> >> A proxy announces itself to potential pledges by use of the >> "AN_proxy" objective. This is a synchronization objective primarily >> intended to be flooded on a single link using the GRASP Flood >> Synchronization (M_FLOOD) message. In accordance with the design of >> the Flood message, a locator consisting of a specific link-local IP >> address, IP protocol number and port number will be distributed with >> the flooded objective. An example of the objective is informally: >> >> ["AN_proxy", F_SYNCH, 1, "BRSKI-TLS"] >> >> The formal CDDL definition is >> >> proxy-objective = ["AN_proxy", F_SYNCH, 1, method] >> method = text ; name of the BRSKI method supported >> >> The loop-count is fixed at 1 since this is a link-local operation. > > Unless we want to add this TTL forwarding detection scheme whose name i forgot. > (set TTL to 255, ignore on receiver messages with lower TTL). > >> The 'method' parameter indicates the specific BRSKI method available >> at the given locator. The initial possible values are "BRSKI-TLS" >> and "BRSKI-COAP". A proxy that supports more than one method will >> flood multiple versions of the "AN_proxy" objective. >> >> 2.2. Negotiation Alternative for Proxy >> >> This alternative to "AN_proxy" uses additional features of GRASP. It >> requires additional complexity in the pledge, and requires the pledge >> to announce its existence to any on-link eavesdroppers via a >> Discovery message. It is therefore not recommended on security >> grounds, but is defined here for completeness. > > That paragraph does not sound like the best sales pitch. And again, i am > not sure if the negative security assessment you make is correct. Nevertheless, I am told that BRSKI wants Flood for this so we'll drop the negotiation option. Conversely, BRSKI seems less sure what it wants for the proxy-discovers-registrar case. > > First of all, maybe move to an appendix given how this goes beyond > our MTI (Mandatory To Implement). > > Secondly: flooding announcements from proxies to pledges is based on > security assumptions that the network info (with proxies on the edge) is > well secured/protected, and that pledges are more vulnerable. Attackers > wold have to become active with flood multicasts to find a pledge which would > otherwise be quiet. And those attacker flood multicasts can be detected. > > Eg: when we'd turn it around like you describe here, attackers could just > unicast answer to pledges and therefore attack the pledge with less > of a visible trail (aka: a valid proxy would not necessarily see the unicast > traffic between attacker and pledge). > > But lets turn the assumptions around: In IoT, one might be foremost > concerned about the security of the infra (with the proxies). Let those > pledges multicast for bootstrap help, but our proxy may GRASP respond only > when it feels that's safe. For example, if the link between pledge and proxy > is some IoT radio with some vendor encryption/security (like in a lot of > low-power radio options), this argument might fly and make this order > of signaling preferrable. > >> A pledge discovers a local proxy and negotiates a BRSKI method with >> it by use of the "AN_join" objective. First, the pledge performs >> GRASP discovery, with the loop-count set to 1 and limited to link- >> local addresses. If multiple responses occur, it chooses one by an >> >> implementation-defined method. Then the pledge initiates GRASP >> negotiation to choose a mutually acceptable BRSKI method. >> >> An example of the objective is informally: >> >> ["AN_join", F_NEG, 6, ["BRSKI-COAP","BRSKI-TLS"]] >> >> The formal CDDL definition is >> >> join-objective = ["AN_join", F_NEG, loop-count, [*method]] >> method = text ; name of the BRSKI method supported >> >> The parties will negotiate until one side proposes a single BRSKI >> method and the other side accepts. In the simplest case of immediate >> acceptance, there will only be two messages (Request Negotiate and >> End Negotiate). The locator (IP address, IP protocol number, port >> number) used for the negotiation will be available for the subsequent >> BRSKI operations, if required. >> >> Note that in the Discovery message, the loop count will be set to 1 >> to limit discovery to the local link. In the negotiation stage, the >> loop count will serve its normal purpose (limiting the negotiation to >> 6 steps in the above example). >> >> 3. Objective for Autonomic Control Plane >> >> The Autonomic Control Plane (ACP) >> [I-D.ietf-anima-autonomic-control-plane] constructs itself without >> outside intervention. To achieve this, each node needs to identify > ^^^^^^^ s/intervention/help/ ? >> its link-local neighbors on all interfaces, and agree on a secure >> connection method with each of them. There are at least two possible >> approaches for this: a flooding mechanism, in which each node >> announces itself and it security methods to its neighbors, or a >> discovery and negotiation mechanism, in which each node actively >> discovers its neighbors. For the moment this draft describes both >> methods. > >> For either method, each node runs an ASA that supports the >> corresponding objective. This ASA runs permanently, in order to > ^^^^^^^^^^^ always when the ACP is capable and willing to connect to neighbbors >> discover or detect new ACP neighbors or to remove failed neighbors. >> >> 3.1. Flooding Alternative > > Indicating a "method" for the protocol is an undesirable attack vector. Why? If the attacker doesn't have the domain cert, they can do nothing. If they do have the domain cert, they can do anything. > Thats probably true for the BRSKI announcements as well, but i'll let > Max etc. argue that point. > > In ACP, the ACP draft describes how the insecure GRASP signaling would > only indicate AN_ACP without parameters, and then any negotiation would > have to be subject to the node either just trying the methods it supports, > or building a TLS connection and running GRASP inside for negotiation. > > I do like the flood and thats what i described in ACP draft. Yes. On balance I think Flood is the cleanest solution for infrastructure elements. Everybody needs them and the method is robust since it can simply be repeated at some reasonable rate. > > I would even like to see mthod being included in it, > but purely for operator diagnostics. Eg: the receiving ASA MUST NOT > change its behavior based on it. > > Eg: Have a Diag element which might be structured, and which as it's > first element has the "methods" supported. > > I hope the diagnostics benefits outweigh the minor securitydownside it has. > >> 3.2. Negotiation Alternative > > It seems as if you have no section for the TLS secured negotiation for the > ACP channel. Why do you not simply reword this 3.2 to be exactly that ? ? You seem to be conflating GRASP negotiation with TLS negotiation? > > Another question: For all those string names like for the "method", > do we need registries in the IETF ? I don't know. I'm a bit reluctant to say yes, because then every ASA designer will want their own registry. > >> 4. Objective for Stable Connectivity of Network OAM > > Nice. Let me discuss high level some steps: > > 1. The way i imagine it, the NOC is a bunch of services, and not specifically > a single "NOC" service. So for example, each ACP node should perform > syslog to a NOC syslog service. Or authenticate data-plane > sessions into the ACP node (netconf, SNMP, SSH,...) via a NOC > authentication service (radius/diameter,...) > > A bunch of these services have already defined DNS-SD service names > and sometimes also service-parameters. So a simple extensible approach > would be to come up with a scheme how to map DNS-SD service announcement > attributes into GRASP objectives that the NOC equipment would then flood > (flooding like you described for the registrar seems like the easiest > scalable way when the objective is required by the mayority of ACP nodes). > > This way we would not have to reinvent the whole namespace of services > a NOC could have, and even if we have to invent new names, it wouldn't be > in a silo, but we'd pick names that are free in DNS-SD, allocate them to > DNS-SD registry, and e voila: no need to maintain additional registries for it. > > 2. You are correct that the NOC should know about wanting to know about > devices in the network. Alas, there are a bunch of things we could do, > and i am not sure how we could most easily make progress. > > Here's roughly how i think it could look: > > NOC ACP-topology ASA is the entity wanting to track network topology. > It would also indicate to some backend whenever new devices show up. > The parameters to it's objective could indicate a lot of options: > > - announce yourself > - always after you've connected > - only when you're in "unconfigured state" > - announce ACP neighbors > - when they connet > - when they disconnect > > I am not sure if the actual announcements then to this service should be > done via GRASP (as a negotiation ? ) or some other protocol. Syslog comes > to mind, but it has reliability problems. > >> 5. Objectives for Intent Distribution > > Except for the ACP channel protocol negotiation, all of the above > is about the simple GRASP flood. Which makes me happy (because it's simple), > and you probably unhappy (because it doesn't explore all the options of GRASP). > > So i wonder: Isn't Intent something where we would need a more intelligent > use of GRASP than just good ol' flood ? Well, see draft-liu-anima-grasp-distribution. > Aka: If we had an Intent agent on every ACP node that has GRASP > negotiation with each neighbor: I could modify intent on any node, > and that node would negotiate with it's neighbors that it had a new version, > and this is what would make that new intent flow hop-by-hop across the > autonomic network via Intent ASAs. You could but whether that would be a good thing is another discussion. For the moment we're talking about an Intent repository. Using a version number rather than a timestamp avoids quite a few problems. But since it's a repository model I think we should rename the objective as "AN_intent-repo". Brian > > And there are tricky parts here: If the network becomes partitioned and > intent gets modified on both sides and then there is a network merge again - > how do you resolve the conflict. Whatever method of signaling you use. > > If we want to solve the problem with absolute timestamps, it seems to me > as if i'd still need relative timestamps: > > Network i connected whole network have version I1 with originator > assigned timestamp I1t. > > Network partitions into part A and part B. > Node in part A modifies intent to I1+1 at time I1t+ta. > Node in part B modifies intent to I1+1 at time I1t+tb. > > When network merges, the policy could be that all nodes would apply > the intent that is newer. eg: lets assume intent in A was applied later. > Nodes in B should be ablle to figure this out by using the relative > time tracked against the last applied intent (I1/I1t). > > Cheers > Toerless > >> 6. Objective for Prefix Management >> >> TBD >> >> 7. Flood Frequency >> >> Any ASA that floods one of the above objectives should do so at a >> carefully chosen frequency. Recipient nodes may be starting up, >> reconnecting, or waking up from sleep, so floods need to be refreshed >> periodically. On the other hand, excessive flooding will consume >> bandwidth, CPU and battery capacity throughout the network, and might >> even resemble a DoS attack. A general guideline is to flood an >> objective once immediately after its value is initialised or changed, >> and then repeat the flood at intervals of at least 30 seconds. >> Additionally, the flooding interval should be slightly jittered to >> avoid synchronicity with other floods. Finally, the value of a >> flooded objective should change as rarely as possible (on a timescale >> of at least minutes, not seconds). >> >> 8. Security Considerations >> >> General security issues for GRASP are covered in >> [I-D.ietf-anima-grasp]. Specific issues that are not mentioned above >> are discussed in the referenced drafts for BRSKI, ACP, stable >> connectivity and Intent. >> >> >> >> >> >> >> >> >> Carpenter & Liu Expires May 22, 2017 [Page 8] >> >> Internet-Draft ANI GRASP Objectives November 2016 >> >> >> 9. IANA Considerations >> >> IANA is requested to add the following entries to the GRASP Objective >> Names Table registry created by [I-D.ietf-anima-grasp]: >> AN_registrar >> AN_proxy >> AN_ACP >> AN_NOC >> AN_intent >> >> 10. Acknowledgements >> >> TBD. >> >> 11. References >> >> 11.1. Normative References >> >> [I-D.greevenbosch-appsawg-cbor-cddl] >> Vigano, C. and H. Birkholz, "CBOR data definition language >> (CDDL): a notational convention to express CBOR data >> structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work >> in progress), September 2016. >> >> [I-D.ietf-anima-grasp] >> Bormann, C., Carpenter, B., and B. Liu, "A Generic >> Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- >> grasp-08 (work in progress), October 2016. >> >> 11.2. Informative References >> >> [I-D.du-anima-an-intent] >> Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. >> Behringer, "ANIMA Intent Policy and Format", draft-du- >> anima-an-intent-04 (work in progress), July 2016. >> >> [I-D.ietf-anima-autonomic-control-plane] >> Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic >> Control Plane", draft-ietf-anima-autonomic-control- >> plane-04 (work in progress), October 2016. >> >> [I-D.ietf-anima-bootstrapping-keyinfra] >> Pritikin, M., Richardson, M., Behringer, M., Bjarnason, >> S., and K. Watsen, "Bootstrapping Remote Secure Key >> Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- >> keyinfra-04 (work in progress), October 2016. >> >> >> >> >> >> Carpenter & Liu Expires May 22, 2017 [Page 9] >> >> Internet-Draft ANI GRASP Objectives November 2016 >> >> >> [I-D.ietf-anima-reference-model] >> Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., >> Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A >> Reference Model for Autonomic Networking", draft-ietf- >> anima-reference-model-02 (work in progress), July 2016. >> >> [I-D.ietf-anima-stable-connectivity] >> Eckert, T. and M. Behringer, "Using Autonomic Control >> Plane for Stable Connectivity of Network OAM", draft-ietf- >> anima-stable-connectivity-01 (work in progress), July >> 2016. >> >> Appendix A. Change log [RFC Editor: Please remove] >> >> draft-carpenter-anima-ani-objectives-00, 2018-11-15: >> >> Initial version >> >> Authors' Addresses >> >> Brian Carpenter >> Department of Computer Science >> University of Auckland >> PB 92019 >> Auckland 1142 >> New Zealand >> >> Email: brian.e.carpenter@gmail.com >> >> >> Bing Liu >> Huawei Technologies Co., Ltd >> Q14, Huawei Campus >> No.156 Beiqing Road >> Hai-Dian District, Beijing 100095 >> P.R. China >> >> Email: leo.liubing@huawei.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> Carpenter & Liu Expires May 22, 2017 [Page 10] > From nobody Mon Jan 30 19:58:40 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691F212946A for ; Mon, 30 Jan 2017 19:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD0_F-1Ulu6e for ; Mon, 30 Jan 2017 19:58:35 -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 84464129D5B for ; Mon, 30 Jan 2017 19:58:35 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id y143so98281362pfb.0 for ; Mon, 30 Jan 2017 19:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:organization:to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=mNKRo2ZGggCcA3GuxuaT4P4YPVy4jafp1LVskP449nE=; b=rl3d5wcOCJL5gnLq91s4khaaF/LyV//PzaurIL9Eu0iTlS8RWHQp8dGNXKTga4I5i7 RQkXZrfrRe/jyMncMiTujfY9nu7EP+hN+tTnenqqOBgq7FNmOpiN4P+QfawygacIW55A KsI2BEI2JgdsMX50DoRDOO8APKlHgDaM+yj+jq8FwpUMl6Nu0ASniK6/JXDXmifAyVvV hQURb/wJ3WNnZWW2/qPLBDb2EjyJxH1hrDYglLYfhe+2A+NWoaRE8Owy4kEIuhyaF6XO FbEuGycUPw1Gfy3VgGXXhUHaBNr+Qzz8JfNODZ0b8nTwYzEQDCnl1CTdHuMRa1Pp6Zl0 p+sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:organization:to :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=mNKRo2ZGggCcA3GuxuaT4P4YPVy4jafp1LVskP449nE=; b=Fiq8MsebJFoTEjwaAwE3XWEy7puqJOSUPTl5uwsAcrC3HFQsb59DzKiUR61dCsO7rI e0fLa9bHhSUzqbYBxBhImBk6NUfz3924+QaQj/x/OhkH3d7ktj/Ul8Ao4qt49pVnaFVI P7dGaotj8jrmaW8jD3MnshLFcZ87t0ZOPXK0XNhPa8FlV1A2EsW230Opt8sGjCKofhEe mg4gxbFJJEcx8w7ovNFDadacbyrO22XKqHu2rK8hV8ZDusxx/E2zJMo3iHDHmJegUL6Q njzxnakokhKB41n2qYPUlus9ssLzJhOfYTrj0d+el7du8mayfuTAeLnpxRjYCET73EQC Mr5A== X-Gm-Message-State: AIkVDXKdObVEFSnF9+q1zmPK0aw9pWrSgPQfpKaLXJKriRWloU02o0PqFT0YMIiDjNql/w== X-Received: by 10.99.134.199 with SMTP id x190mr28169740pgd.68.1485835114820; Mon, 30 Jan 2017 19:58:34 -0800 (PST) Received: from ?IPv6:2406:e007:7505:1:28cc:dc4c:9703:6781? ([2406:e007:7505:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u82sm36034733pfd.7.2017.01.30.19.58.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 19:58:34 -0800 (PST) References: <148424243777.2935.14591600696757497157.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: Date: Tue, 31 Jan 2017 16:58:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148424243777.2935.14591600696757497157.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-autonomic-control-plane-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 03:58:39 -0000 Hi, Some comments, not in order of importance. > 2.3. Data Plane Independent Permanent Reachability It's probably worth noting in this section that the ACP does depend on some basics: e.g. layer 2 bridges functioning and intermediate nodes functioning (even if their data plane routing is down). Otherwise it sounds a bit miraculous. Maybe this is also the place to first mention that the ACP may partition when something basic breaks. > 5.1.1. Domain Certificate with ANIMA information ... > An example: > > anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.com > > The ACP address MUST be specified in its canonical form, as specified > in [RFC5952], to allow for easy textual comparisons. Er-hum. RFC5952 specifies lower case hexadecimal. > 5.1.2. AN Adjacency Table ... > Where the next autonomic device is not directly adjacent, the > information in the adjacency table can be supplemented by > configuration. For example, the node-ID and IP address could be > configured. I hate this. If we let this camel put its nose in the tent, how can we claim the result is "autonomic"? At the very least, I would to see this (and any other such items) in a separate section with a big red flag on it. Maybe move this point to "6.2. ACP through Non-Autonomic L3 Clouds"? > 5.2.1. L2 topology considerations ... > Predictable scaling requirements for ACP neighbors can most easily be > achieved if in topologies like these, AN capable L2 switches can > ensure that discovery messages terminate on them so that neighboring > AN routers and switches will only find the physcially connected AN L2 > switches as their candidate ACP neighbors. Correct, but since you will soon present GRASP as the discovery mechanism, I think you need to say here that *as a result of this requirement*, such L2 switches need to run L3 (i.e. IPv6) and the ANI software suite (i.e. at least ACP, BRSKI and GRASP). Dumb switches need not apply. > 5.2.3. Discovery with GRASP ... > The name of the GRASP objective to announce/discover the capability > of a neighbor to run the ACP is "ACP". We're now suggesting "AN_ACP" simply so that it's identified as an ANI objective. Not a big deal, just a suggested convention. > The precise > GRASP objective to be used is specified in Section 3 of > [I-D.carpenter-anima-ani-objectives]. That's fine for now. Later we should consider moving the definition into this draft. There's an open question whether we use the Flood or Discover/Negotiate mechanism of GRASP for this. My view is that Flood is the simplest and since it doesn't require any GRASP message from the discovering node, it's marginally less attackable. [I-D.carpenter-anima-ani-objectives] describes both options, but we need to decide. > 5.2.4. Discovery and BRSKY s/BRSKY/BRSKI/ This section needs to use the agreed terminology at https://mailarchive.ietf.org/arch/msg/anima-bootstrap/Iqsosf7pBgOeep4UL0C73mSUSKQ > When an autonomic device is a registrar, it will announce the > registrar function via GRASP in the ACP as the "6JOIN" objective. That name is not settled. I suggest deleting it here; it belongs in the BRSKI spec. (Also, every Join Registrar will also behave as a Join Assistant, so it will also announce the assistant function as a GRASP objective.) > 5.5.5. ACP Security Profiles The MTI for normal nodes is IPsec, but you make dTLS the MTI for constrained devices. That doesn't guarantee interoperability. Or do you mean that constrained nodes MUST support IPsec and dTLS? > Autonomic devices need to specify in documentation the set of secure > ACP mechanisms they suppport. That's very nice but no use; autonomic nodes don't read each other's documentation. What is useful is that a device announces the mechanisms it supports to its peers, e.g. in a GRASP Flood message. > 6. Workarounds for Non-Autonomic Nodes I guess we have to cover this. I would like it to start with a short rant about how awful it is. But more realistically, we have to be very clear that (a) the ACP will come up and run without any of this and (b) the points that have to be configured will be singularities in the AN - they won't recover spontaneously if broken, etc. That's it for now. Brian