From nobody Mon Apr 1 02:59:15 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9AF120147; Mon, 1 Apr 2019 02:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYgbKwq6sDYy; Mon, 1 Apr 2019 02:58:55 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 CD0D91200FD; Mon, 1 Apr 2019 02:58:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,296,1549926000"; d="scan'208,217";a="301368646" Received: from wifi-pro-83-211.paris.inria.fr ([128.93.83.211]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2019 11:58:52 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <5BFE7704-2EF0-4F53-9299-299FEC3687D3@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 1 Apr 2019 11:58:52 +0200 In-Reply-To: <1912967484.2862085.1553967089097.JavaMail.zimbra@inria.fr> Cc: secdispatch@ietf.org, 6tisch <6tisch@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org> To: Thomas Watteyne References: <1912967484.2862085.1553967089097.JavaMail.zimbra@inria.fr> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] [Secdispatch] EDHOC Summary X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 09:59:07 -0000 --Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 We are happy to contribute to this effort through feedback on the = design, implementation for constrained devices and its evaluation in = 6TiSCH networks. Mali=C5=A1a > On 30 Mar 2019, at 18:31, Thomas Watteyne = wrote: >=20 > The 6TiSCH WG has produced a set of documents [1,2] that specify the = use of OSCORE to secure message exchanges at the application layer = including network access. At the side meeting in Prague two years ago = involving several ADs and WG chairs, the 6TiSCH chairs have indicated = the need for an efficient authenticated key exchange protocol that we = could use during the network access to key OSCORE. We have also restated = this request at the SECDISPATCH interim a couple of weeks ago. >=20 > The EDHOC specification was discussed on numerous occasions during the = 6TiSCH working group meetings and the approach on using it for the = extension of [1] towards zero-touch [3] deployments had a wide = consensus. We welcome the work in this area to be done, and strongly = support any decision of the security ADs that leads to the fast progress = of this specification. >=20 > [1] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ = =20= > [2] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ = > [3] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-jo= in/ = =20 >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

We are = happy to contribute to this effort through feedback on the design, = implementation for constrained devices and its evaluation in 6TiSCH = networks.

Mali=C5=A1a

On 30 Mar 2019, at 18:31, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:

The 6TiSCH WG has produced a = set of documents [1,2] that specify the use of OSCORE to secure message = exchanges at the application layer including network access. At the side = meeting in Prague two years ago involving several ADs and WG chairs, the = 6TiSCH chairs have indicated the need for an efficient authenticated key = exchange protocol that we could use during the network access to key = OSCORE. We have also restated this request at the SECDISPATCH interim a = couple of weeks ago.

The EDHOC specification was discussed = on numerous occasions during the 6TiSCH working group meetings and the = approach on using it for the extension of [1] towards zero-touch [3] = deployments had a wide consensus. We welcome the work in this area to be = done, and strongly support any decision of the security ADs that leads = to the fast progress of this specification.

_______________________________________= ________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

= --Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864-- From nobody Mon Apr 1 05:06:17 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E27412010C; Mon, 1 Apr 2019 05:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DF+D3qsL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e5HGa06n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMMU_q7pOjJQ; Mon, 1 Apr 2019 05:06:06 -0700 (PDT) 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 9171C120100; Mon, 1 Apr 2019 05:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15678; q=dns/txt; s=iport; t=1554120365; x=1555329965; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N2LaIsPQDZ8wzpRUHGwFNcw5rU+M7rV0ufAzarxZx+4=; b=DF+D3qsLw5YKFJOviy9F8KI6Ef4ZtvYoCOoV7VgxvQxTXKFArj0iePrY UwGsiWGrXwP4VEomxNpmPeKnAk4iOtVU8uxyVjyyKzsIXMbOgP18rtm9i aDANrjulA4ooJaHjCLq0lZBNNZoAyFtpm3qyDKyiagNOsAEb4yfHxMGcd Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Ame0dwRDA/GyjNjhOcZhzUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACS/aFc/5BdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vUANodAQLJwqEBINHA4RSimCCV5J?= =?us-ascii?q?GhEmBLoEkA1QOAQEYAQwHg3pGAheFLCI0CQ0BAQMBAQkBAwJtHAyFSgEBAQE?= =?us-ascii?q?DAQEhChMBASwLAQ8CAQgRAQMBASgDAgICJQsUAwYIAgQBDQUIgxuBEUwDFQE?= =?us-ascii?q?CDJ8SAooUcYEvgnkBAQWBMQEDAw1BgnMYggwDBYEvAYsyF4FAP4FXgkw+gmE?= =?us-ascii?q?BAQIBARaBSSsJglQxgiaNA4QjlCcJAodvjAmQLoN+iz+GEY09AgQCBAUCDgE?= =?us-ascii?q?BBYFNODWBIXAVO4I4AQEyggqDboUUhT9yDIEcjhQBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.60,296,1549929600"; d="scan'208,217";a="255796310" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2019 12:06:04 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x31C64cL026714 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Apr 2019 12:06:04 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 07:06:03 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 07:06:03 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 1 Apr 2019 07:06:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N2LaIsPQDZ8wzpRUHGwFNcw5rU+M7rV0ufAzarxZx+4=; b=e5HGa06nIcPqiK1pxKSjEQ76D4Pjd1f6S9shOHTB/wf8XdRgtA271Ajmo6CDy2dfzX5db3Afa48rdNmHzT+UP3RvUXJZDqM1zEnIkSaRraWVqrUQX5oikQc9JCU/y3Od4xr936hDfs8e7+GUzA6EhmADF0r7osa+a/AITyNv3Kg= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3663.namprd11.prod.outlook.com (20.178.253.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Mon, 1 Apr 2019 12:06:01 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 12:06:01 +0000 From: "Pascal Thubert (pthubert)" To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , "Thomas Watteyne" CC: "secdispatch@ietf.org" , 6tisch <6tisch@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org> Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: 3ogcPYDenFGsRTCB8gJNHpq5AmS495mYaAMAgAAi9lA= Date: Mon, 1 Apr 2019 12:05:39 +0000 Deferred-Delivery: Mon, 1 Apr 2019 12:04:59 +0000 Message-ID: References: <1912967484.2862085.1553967089097.JavaMail.zimbra@inria.fr> <5BFE7704-2EF0-4F53-9299-299FEC3687D3@inria.fr> In-Reply-To: <5BFE7704-2EF0-4F53-9299-299FEC3687D3@inria.fr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.57] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa2c5450-9aaa-4649-9264-08d6b69a68d9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3663; x-ms-traffictypediagnostic: MN2PR11MB3663: x-ms-exchange-purlcount: 11 x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(346002)(396003)(376002)(199004)(189003)(9686003)(14444005)(54906003)(99286004)(54896002)(55016002)(236005)(256004)(478600001)(25786009)(7736002)(33656002)(4326008)(53936002)(966005)(66066001)(81156014)(14454004)(68736007)(6436002)(229853002)(8936002)(6306002)(74316002)(110136005)(7696005)(106356001)(81166006)(26005)(105586002)(6506007)(53546011)(186003)(6116002)(606006)(6246003)(2906002)(8676002)(76176011)(52536014)(97736004)(486006)(11346002)(86362001)(5660300002)(71190400001)(71200400001)(476003)(6666004)(446003)(316002)(3846002)(66574012)(790700001)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3663; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bgLEBWoEXknbQ6VIShMeZoRiFw0Bjb+xd1rFgPQQnmTSv9LiGJR+KuYOMcXEcNn8aWCtz15vYlKpKm9z08AeRTbEus82uRVTPuAz0DdrSXcd6YaAVjMcpzJcjhJOG297P+HZFiE1u+E6bMfiTS0VHvQ7XzPqhODV7p21DrxIE8IT5xMY4Jb3eqh4skfSKLn7ntEye8iuxmrsXevhDTBnPL/MO03+eu7zJAHQZ4pzEetRZx0hmuqyYdZbIYyNh4WGhrQh777yxVmoUT5s2iTrbW0fgbFCGu2+x7RVbpW9XtW6xAh0TVGPg6fIFCVy3AZZ2AlREYYdj8o7eD/4iSdH7sbWA4yUWzbjmZg3YqjKcJIkZg9cS75Bx7nVCXD0hzKe9LrNCUVZJM0v2Ys1SkA8CRm8cB2db5nUI6CmkYJNFMI= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa2c5450-9aaa-4649-9264-08d6b69a68d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 12:06:01.7990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3663 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [6tisch] [Secdispatch] EDHOC Summary X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 12:06:09 -0000 --_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgSSBoYWQgdGhlIGRpc2N1c3Npb24gcHJpdmF0ZWx5LCBtaW5pbWFsIHNlY3VyaXR5IGFu ZCBlZGhvYyB3ZXJlIGRpc2N1c3NlZCBhdCA2VGlTQ0ggYXQgcHJldHR5IG11Y2ggZXZlcnkgbWVl dGluZywgcGxlbmFyeSBvciBpbnRlcmltLCBzaW5jZSBhcm91bmQgSUVURiA5Ny4NCg0KVGhlIG1p bnV0ZXMgZm9yIGFuIElFVEYgYXJlIGxvY2F0ZWQgaW4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvbWludXRlcy14eC02dGlzY2gvIHdoZXJlIHh4IGlzIHRoZSBJRVRGIG51bWJlci4N ClNlZSBmb3IgaW5zdGFuY2UgSUVURiA5OCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9taW51dGVzLTk4LTZ0aXNjaC87IG9uZSBjYW4gYWxzbyBnb29nbGUgaHR0cHM6Ly93d3cuZ29v Z2xlLmNvbS9zZWFyY2g/Y2xpZW50PWZpcmVmb3gtYi1kJnE9NnRpc2NoK21pbnV0ZXMrZWRob2MN ClRoZXJlIHdhcyBhbHNvIGEgc2lkZSBtZWV0aW5nIGF0IElFVEYgMTAzLCBhbGwgcmVwb3J0ZWQg aW4gdGhlIG1pbnV0ZXMgaHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9tZWV0aW5ncy93aWtp LzE4MTEwOF9pZXRmMTAzX2Jhbmdrb2sNCg0KT25lIG1heSBhbHNvIGNvbnN1bHQgdGhlIG1pbnV0 ZXMgZnJvbSB0aGUgNlRpU0NIIFdpS2kgIGh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVl dGluZ3Mvd2lraS9icm93c2UvIHdoZXJlIGFsbCBhcmUgc3RvcmVkIHNpbmNlIGluY2VwdGlvbiBv ZiB0aGUgV0cuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFzY2FsDQoNCkZyb206IE1hbGnFoWEgVnXE jWluacSHIDxtYWxpc2EudnVjaW5pY0BpbnJpYS5mcj4NClNlbnQ6IGx1bmRpIDEgYXZyaWwgMjAx OSAxMTo1OQ0KVG86IFRob21hcyBXYXR0ZXluZSA8dGhvbWFzLndhdHRleW5lQGlucmlhLmZyPg0K Q2M6IHNlY2Rpc3BhdGNoQGlldGYub3JnOyA2dGlzY2ggPDZ0aXNjaEBpZXRmLm9yZz47IDZ0aXNj aC1jaGFpcnMgPDZ0aXNjaC1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1NlY2Rpc3Bh dGNoXSBFREhPQyBTdW1tYXJ5DQoNCisxDQoNCldlIGFyZSBoYXBweSB0byBjb250cmlidXRlIHRv IHRoaXMgZWZmb3J0IHRocm91Z2ggZmVlZGJhY2sgb24gdGhlIGRlc2lnbiwgaW1wbGVtZW50YXRp b24gZm9yIGNvbnN0cmFpbmVkIGRldmljZXMgYW5kIGl0cyBldmFsdWF0aW9uIGluIDZUaVNDSCBu ZXR3b3Jrcy4NCg0KTWFsacWhYQ0KDQpPbiAzMCBNYXIgMjAxOSwgYXQgMTg6MzEsIFRob21hcyBX YXR0ZXluZSA8dGhvbWFzLndhdHRleW5lQGlucmlhLmZyPG1haWx0bzp0aG9tYXMud2F0dGV5bmVA aW5yaWEuZnI+PiB3cm90ZToNCg0KVGhlIDZUaVNDSCBXRyBoYXMgcHJvZHVjZWQgYSBzZXQgb2Yg ZG9jdW1lbnRzIFsxLDJdIHRoYXQgc3BlY2lmeSB0aGUgdXNlIG9mIE9TQ09SRSB0byBzZWN1cmUg bWVzc2FnZSBleGNoYW5nZXMgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGluY2x1ZGluZyBuZXR3 b3JrIGFjY2Vzcy4gQXQgdGhlIHNpZGUgbWVldGluZyBpbiBQcmFndWUgdHdvIHllYXJzIGFnbyBp bnZvbHZpbmcgc2V2ZXJhbCBBRHMgYW5kIFdHIGNoYWlycywgdGhlIDZUaVNDSCBjaGFpcnMgaGF2 ZSBpbmRpY2F0ZWQgdGhlIG5lZWQgZm9yIGFuIGVmZmljaWVudCBhdXRoZW50aWNhdGVkIGtleSBl eGNoYW5nZSBwcm90b2NvbCB0aGF0IHdlIGNvdWxkIHVzZSBkdXJpbmcgdGhlIG5ldHdvcmsgYWNj ZXNzIHRvIGtleSBPU0NPUkUuIFdlIGhhdmUgYWxzbyByZXN0YXRlZCB0aGlzIHJlcXVlc3QgYXQg dGhlIFNFQ0RJU1BBVENIIGludGVyaW0gYSBjb3VwbGUgb2Ygd2Vla3MgYWdvLg0KDQpUaGUgRURI T0Mgc3BlY2lmaWNhdGlvbiB3YXMgZGlzY3Vzc2VkIG9uIG51bWVyb3VzIG9jY2FzaW9ucyBkdXJp bmcgdGhlIDZUaVNDSCB3b3JraW5nIGdyb3VwIG1lZXRpbmdzIGFuZCB0aGUgYXBwcm9hY2ggb24g dXNpbmcgaXQgZm9yIHRoZSBleHRlbnNpb24gb2YgWzFdIHRvd2FyZHMgemVyby10b3VjaCBbM10g ZGVwbG95bWVudHMgaGFkIGEgd2lkZSBjb25zZW5zdXMuIFdlIHdlbGNvbWUgdGhlIHdvcmsgaW4g dGhpcyBhcmVhIHRvIGJlIGRvbmUsIGFuZCBzdHJvbmdseSBzdXBwb3J0IGFueSBkZWNpc2lvbiBv ZiB0aGUgc2VjdXJpdHkgQURzIHRoYXQgbGVhZHMgdG8gdGhlIGZhc3QgcHJvZ3Jlc3Mgb2YgdGhp cyBzcGVjaWZpY2F0aW9uLg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC1zZWN1cml0eS8NClsyXSBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZ0aXNjaC1hcmNoaXRlY3R1cmUvDQpbM10gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtZHRzZWN1cml0 eS16ZXJvdG91Y2gtam9pbi8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClNlY2Rpc3BhdGNoIG1haWxpbmcgbGlzdA0KU2VjZGlzcGF0Y2hAaWV0Zi5v cmc8bWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0KDQo= --_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLm9i amVjdA0KCXttc28tc3R5bGUtbmFtZTpvYmplY3Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSBJ IGhhZCB0aGUgZGlzY3Vzc2lvbiBwcml2YXRlbHksIG1pbmltYWwgc2VjdXJpdHkgYW5kIGVkaG9j IHdlcmUgZGlzY3Vzc2VkIGF0IDZUaVNDSCBhdCBwcmV0dHkgbXVjaCBldmVyeSBtZWV0aW5nLCBw bGVuYXJ5IG9yIGludGVyaW0sIHNpbmNlIGFyb3VuZCBJRVRGIDk3LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgbWludXRlcyBmb3IgYW4gSUVURiBhcmUgbG9jYXRlZCBpbiA8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLXh4LTZ0aXNjaC8iPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy14eC02dGlzY2gvPC9hPiB3aGVy ZSB4eCBpcyB0aGUgSUVURiBudW1iZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TZWUgZm9yIGluc3RhbmNlIElFVEYgOTggPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvbWludXRlcy05OC02dGlzY2gvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL21pbnV0ZXMtOTgtNnRpc2NoLzwvYT47IG9uZSBjYW4gYWxzbyBnb29nbGUg PGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9zZWFyY2g/Y2xpZW50PWZpcmVmb3gtYi1k JmFtcDtxPTZ0aXNjaCYjNDM7bWludXRlcyYjNDM7ZWRob2MiPg0KaHR0cHM6Ly93d3cuZ29vZ2xl LmNvbS9zZWFyY2g/Y2xpZW50PWZpcmVmb3gtYi1kJmFtcDtxPTZ0aXNjaCYjNDM7bWludXRlcyYj NDM7ZWRob2M8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSB3 YXMgYWxzbyBhIHNpZGUgbWVldGluZyBhdCBJRVRGIDEwMywgYWxsIHJlcG9ydGVkIGluIHRoZSBt aW51dGVzDQo8YSBocmVmPSJodHRwczovL2JpdGJ1Y2tldC5vcmcvNnRpc2NoL21lZXRpbmdzL3dp a2kvMTgxMTA4X2lldGYxMDNfYmFuZ2tvayI+aHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9t ZWV0aW5ncy93aWtpLzE4MTEwOF9pZXRmMTAzX2Jhbmdrb2s8L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uZSBtYXkgYWxzbyBjb25zdWx0IHRoZSBtaW51dGVzIGZyb20gdGhlIDZUaVNDSCBX aUtpJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVldGluZ3Mv d2lraS9icm93c2UvIj4NCmh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVldGluZ3Mvd2lr aS9icm93c2UvPC9hPiB3aGVyZSBhbGwgYXJlIHN0b3JlZCBzaW5jZSBpbmNlcHRpb24gb2YgdGhl IFdHLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIHRoZSBiZXN0LDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBNYWxpxaFhIFZ1xI1pbmnEhyAmbHQ7bWFsaXNhLnZ1Y2luaWNAaW5yaWEu ZnImZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBsdW5kaSAxIGF2cmlsIDIwMTkgMTE6NTk8YnI+DQo8 Yj5Ubzo8L2I+IFRob21hcyBXYXR0ZXluZSAmbHQ7dGhvbWFzLndhdHRleW5lQGlucmlhLmZyJmd0 Ozxicj4NCjxiPkNjOjwvYj4gc2VjZGlzcGF0Y2hAaWV0Zi5vcmc7IDZ0aXNjaCAmbHQ7NnRpc2No QGlldGYub3JnJmd0OzsgNnRpc2NoLWNoYWlycyAmbHQ7NnRpc2NoLWNoYWlyc0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTZWNkaXNwYXRjaF0gRURIT0MgU3VtbWFyeTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgaGFwcHkgdG8gY29udHJp YnV0ZSB0byB0aGlzIGVmZm9ydCB0aHJvdWdoIGZlZWRiYWNrIG9uIHRoZSBkZXNpZ24sIGltcGxl bWVudGF0aW9uIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzIGFuZCBpdHMgZXZhbHVhdGlvbiBpbiA2 VGlTQ0ggbmV0d29ya3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1hbGnFoWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMwIE1hciAyMDE5LCBhdCAxODoz MSwgVGhvbWFzIFdhdHRleW5lICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLndhdHRleW5lQGlu cmlhLmZyIj50aG9tYXMud2F0dGV5bmVAaW5yaWEuZnI8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZjtiYWNrZ3JvdW5kOiNGREZERkQiPlRoZSA2VGlTQ0ggV0cgaGFzIHByb2R1Y2Vk IGEgc2V0IG9mIGRvY3VtZW50cyBbMSwyXSB0aGF0IHNwZWNpZnkgdGhlIHVzZSBvZiBPU0NPUkUg dG8gc2VjdXJlIG1lc3NhZ2UgZXhjaGFuZ2VzIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBpbmNs dWRpbmcgbmV0d29yaw0KIGFjY2Vzcy4gQXQgdGhlIHNpZGUgbWVldGluZyBpbiBQcmFndWUgdHdv IHllYXJzIGFnbyBpbnZvbHZpbmcgc2V2ZXJhbCBBRHMgYW5kIFdHIGNoYWlycywgdGhlIDZUaVND SCBjaGFpcnMgaGF2ZSBpbmRpY2F0ZWQgdGhlIG5lZWQgZm9yIGFuIGVmZmljaWVudCBhdXRoZW50 aWNhdGVkIGtleSBleGNoYW5nZSBwcm90b2NvbCB0aGF0IHdlIGNvdWxkIHVzZSBkdXJpbmcgdGhl IG5ldHdvcmsgYWNjZXNzIHRvIGtleSBPU0NPUkUuIFdlIGhhdmUgYWxzbw0KIHJlc3RhdGVkIHRo aXMgcmVxdWVzdCBhdCB0aGUgU0VDRElTUEFUQ0ggaW50ZXJpbSBhIGNvdXBsZSBvZiB3ZWVrcyBh Z28uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRkRGREZEIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRkRGREZEIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNl cmlmIj5UaGUgRURIT0Mgc3BlY2lmaWNhdGlvbiB3YXMgZGlzY3Vzc2VkIG9uIG51bWVyb3VzIG9j Y2FzaW9ucyBkdXJpbmcgdGhlIDZUaVNDSCB3b3JraW5nIGdyb3VwIG1lZXRpbmdzIGFuZCB0aGUg YXBwcm9hY2ggb24gdXNpbmcgaXQgZm9yIHRoZSBleHRlbnNpb24NCiBvZiBbMV0gdG93YXJkcyB6 ZXJvLXRvdWNoIFszXSBkZXBsb3ltZW50cyBoYWQgYSB3aWRlIGNvbnNlbnN1cy4gV2Ugd2VsY29t ZSB0aGUgd29yayBpbiB0aGlzIGFyZWEgdG8gYmUgZG9uZSwgYW5kIHN0cm9uZ2x5IHN1cHBvcnQg YW55IGRlY2lzaW9uIG9mIHRoZSBzZWN1cml0eSBBRHMgdGhhdCBsZWFkcyB0byB0aGUgZmFzdCBw cm9ncmVzcyBvZiB0aGlzIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGREZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOiNGREZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPlsxXSZuYnNwOzxz cGFuIGNsYXNzPSJvYmplY3QiPjxzcGFuIHN0eWxlPSJjb2xvcjpkYXJrYmx1ZSI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1h bC1zZWN1cml0eS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6ZGFya2JsdWU7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJpdHkvPC9zcGFuPjwvYT48L3NwYW4+PC9zcGFu PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGREZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPlsy XSZuYnNwOzxzcGFuIGNsYXNzPSJvYmplY3QiPjxzcGFuIHN0eWxlPSJjb2xvcjpkYXJrYmx1ZSI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlz Y2gtYXJjaGl0ZWN0dXJlLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpkYXJr Ymx1ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi02dGlzY2gtYXJjaGl0ZWN0dXJlLzwvc3Bhbj48L2E+PC9zcGFuPjwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNG REZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPlszXSZuYnNwOzxzcGFuIGNsYXNzPSJvYmplY3QiPjxz cGFuIHN0eWxlPSJjb2xvcjpkYXJrYmx1ZSI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtZHRzZWN1cml0eS16ZXJvdG91Y2gtam9pbi8i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6ZGFya2JsdWU7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRp c2NoLWR0c2VjdXJpdHktemVyb3RvdWNoLWpvaW4vPC9zcGFuPjwvYT48L3NwYW4+PC9zcGFuPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTZWNkaXNwYXRjaCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmciPlNl Y2Rpc3BhdGNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2giPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2VjZGlzcGF0Y2g8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_-- From nobody Tue Apr 2 04:17:23 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9788E1200E5 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 04:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fjlbZz7E; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ELeAgOMz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQNjjKdgmHx3 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 04:17:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2E51200DE for <6tisch@ietf.org>; Tue, 2 Apr 2019 04:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3312; q=dns/txt; s=iport; t=1554203840; x=1555413440; h=from:to:subject:date:message-id:mime-version; bh=wHkdpClfLtT+bLi4WXvCcIaZrwKwKVupcL0Boh+R1vQ=; b=fjlbZz7E3xyS27j4BOnDTmp/fQJR9G4yVtADq/I+718qB6zzX4Z4zQVC FruufXvdyIRAcc3mWja9cA5izD6HNJY0Ewz7kak5SGtO7QJGlzoQruYIS D+m/2lfbKO2zTSOwICuofa46+Li+e6u0L0T8gaLgJMXkBPedXozIluunf 4=; IronPort-PHdr: =?us-ascii?q?9a23=3ARrTBKB+PIhm9hP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaZCVDxIeT2Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AACJQ6Nc/40NJK1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYEOL1ADaFQgBAsnh1UDhFKKYkqFRo8PhEmBLhSBEAN?= =?us-ascii?q?UDgEBIwmEQAKFPCI0CQ0BAQMBAQkBAwJtHAyFfhMBATgRAQx0JgEEG4MbgRF?= =?us-ascii?q?MAxUBAgyiMQKKFIIggnkBAQWBNQQMQYMMGIIMAwWBLwGLMheBQD+BV4QOgV0?= =?us-ascii?q?CAwGBJTorgw6CJpEolCwJAodxjA6CA4YMjCWLRoEYhH6NQgIEAgQFAg4BAQW?= =?us-ascii?q?BTTiBVnAVgyeCCoNuhRSFP3KBKI83AQE?= X-IronPort-AV: E=Sophos;i="5.60,300,1549929600"; d="scan'208,217";a="545756323" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 11:17:18 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x32BHIh2027917 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Tue, 2 Apr 2019 11:17:18 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 06:17:17 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 07:17:16 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 06:17:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ew0qp29df+i7Hs10MJ1H6YSh8W/eV7qw3AMYPSStUao=; b=ELeAgOMzkk2evDff/s6htseMQWjVjQwaU/DYtfRft/hYtENO3fbrlGemhgRu5M4TEwLN77G9MPpBjGehLQEzSon2Ybp4vKDTb/HCQI2cPmJTxNMdIFe/RHA3ZVbQ/e08qSn+6rIi0QXReFufiufUNVWwBuvZXajZ/iZZ2ghrgXw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3725.namprd11.prod.outlook.com (20.178.253.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Tue, 2 Apr 2019 11:17:15 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Tue, 2 Apr 2019 11:17:15 +0000 From: "Pascal Thubert (pthubert)" To: "'6tisch@ietf.org'" <6tisch@ietf.org> Thread-Topic: IETF 104 WG Minutes and meeting summary Thread-Index: AdTpOgx74BpsLJT2TVKXZvpUY19gJQ== Date: Tue, 2 Apr 2019 11:16:01 +0000 Deferred-Delivery: Tue, 2 Apr 2019 09:56:34 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ef54820-ac62-4772-4ffe-08d6b75cc33a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3725; x-ms-traffictypediagnostic: MN2PR11MB3725: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(136003)(346002)(39860400002)(366004)(396003)(376002)(199004)(189003)(256004)(46003)(966005)(53936002)(7736002)(68736007)(9686003)(6666004)(6916009)(6506007)(54896002)(25786009)(558084003)(102836004)(14454004)(105586002)(106356001)(97736004)(478600001)(55016002)(606006)(6436002)(74316002)(7696005)(790700001)(186003)(6116002)(2906002)(236005)(86362001)(99286004)(8676002)(71200400001)(14444005)(486006)(316002)(6306002)(81166006)(8936002)(476003)(81156014)(71190400001)(33656002)(52536014)(5660300002)(491001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3725; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Pr7Uu3nxm/JoHsHRCsYAz1yGnJFBFl2BP1xox9om5Miwp0DkxNpSZWEPMRc2eJKTfEqnKPaGgPKlIj2KhINL5UZZ90pTDYgavHin9XW2ct/qWmqcdS8XK9NfqlRaOFHFRHPxpUooNVZhL1354eNoLHMQzGEGxiDOykG957+bZWpH6Qkrc390yW6cEccv5KmWIs0gZnT4OVwqeM48EZZIHM5WDo7UWbzVi1IjOh15VSRKtWRqORMDSZILMVgmDIFaDOwJeeqBkUt7SLc96HdOJgOhXYcypyKQzHa1De8jgiNQyx3QyTqABDuA5YVUApxq2YYDSgGQNICzk/z87dvoVF50IJs8mDRzjY/ItPP2ZAsh3uOk3ZKQ4ryjebBfKfQi79DpT3wGdaK+LY6CNy6W0xCGuYO31PrTqKjsyw8Lsfw= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565C38D3989E3688E9D31C9D8560MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3ef54820-ac62-4772-4ffe-08d6b75cc33a X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 11:17:15.8465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3725 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: [6tisch] IETF 104 WG Minutes and meeting summary X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 11:17:23 -0000 --_000_MN2PR11MB3565C38D3989E3688E9D31C9D8560MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear 6TiSCHers As usual the summary of the meeting is posted at https://trac.ietf.org/trac= /int/wiki/IETF104 and the minutes are available at https://datatracker.ietf= .org/doc/minutes-104-6tisch/. Please let us know if we missed anything and we will update : ) The chairs --_000_MN2PR11MB3565C38D3989E3688E9D31C9D8560MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear 6TiSCHers

 

As usual the summary of the meeting is posted at https://trac.ietf.org/trac/int/wiki/IETF104 and the minutes are availab= le at https://datatracker.ietf.org/doc/minutes-104-6tisch/.

 

Please let us know if we missed anything and we will= update : )

 

The chairs

 

--_000_MN2PR11MB3565C38D3989E3688E9D31C9D8560MN2PR11MB3565namp_-- From nobody Tue Apr 2 05:55:27 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195D71200FF for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 05:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z63FmWQ1zf5d for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 05:55:22 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 EA3681200F9 for <6tisch@ietf.org>; Tue, 2 Apr 2019 05:55:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,300,1549926000"; d="scan'208";a="301527427" Received: from wifi-pro-83-211.paris.inria.fr ([128.93.83.211]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2019 14:55:18 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 2 Apr 2019 14:55:17 +0200 Cc: 6tisch <6tisch@ietf.org> To: Michael Richardson Message-Id: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [6tisch] Progress zero-touch document X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 12:55:25 -0000 Michael, all, With the EDHOC specification finally seeing progress (see [1]), it seems = like a good time to restart the work on zero touch and progress the = adopted working group document. Reading the current version of = draft-ietf-6tisch-dtsecurity-zerotouch-join-03, it seems that there are = many options available, including the choice between DTLS and EDHOC for = authentication. Many available options may pose interoperability = challenges and also add unnecessary code complexity. Given that the = working group decided on using OSCORE during network access [2], as well = as for application purposes [3], the implementation of the 6TiSCH stack = includes the CBOR/COSE primitives in the footprint, as well as the = support to go through an application-layer proxy as specified in [2]. = EDHOC protocol is built on these primitives, can be easily carried = within messages specified in [2] for network access to go through an = application-layer proxy, and is quite efficient when it comes to the = encoding overhead using CBOR resulting in a small number of L2 frames to = complete the key exchange. It seems as a natural way forward for the = working group to focus on using EDHOC in [4]. Therefore, I would like to propose to keep track of the EDHOC progress = and to work on a more streamlined zero-touch solution. Doing these = changes in [4] seems to make the most sense at this point.=20 What are your thoughts on this? Mali=C5=A1a [1] = https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXI= m0c [2] https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ [3] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ [4] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-jo= in/= From nobody Tue Apr 2 06:34:56 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC89A120135 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 06:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BTP/6mtE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OjBHF1WW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzfefLL209b4 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 06:34:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9001A120130 for <6tisch@ietf.org>; Tue, 2 Apr 2019 06:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3360; q=dns/txt; s=iport; t=1554212092; x=1555421692; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LIJ7ceW9YK6TlEzQiRMHcqfi3+padIVzfiVACSf8JjY=; b=BTP/6mtE7zNYdtuoYNdEnRigkv4uAUbf3BoND+blmE4RFCZSntAsHo0P 9xWczA6vmu6hleW9iMh4jZczmVEGB7vllYIcGOF3obDIOJZv6qt+koMUC 86WbH0E9xKZsyGc3ldlha6eUv2YyOPEWPXhjfXCDOORFZPRbPvcPBVzUf k=; IronPort-PHdr: =?us-ascii?q?9a23=3AHnyMChFMsFS115ldsRqjiZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAADdYqNc/4ENJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYE+UANodAQLJ4QOg0cDjzWCV5cRglIDVA4BARgNB4N?= =?us-ascii?q?6RgIXhSUiOBIBAQMBAQkBAgECbRwMhUoBAQEBAwEBIREMAQElBwsBBAcEAgE?= =?us-ascii?q?IEQEDAQEDAiYCAgIlCxUCBggCBAENBQgTgwiBXQMVAQIMolkCihRxgS+CeQE?= =?us-ascii?q?BBYExARNBgwsYggwDBYELJIRehlUXgUA/gRFGgkw+gmEBAQIBAYFfgwgxggQ?= =?us-ascii?q?ijQWYUgkCh3KMDpQ4i0aGFo1GAgQCBAUCDgEBBYFkIYFWcBU7gmyCCoNuhRS?= =?us-ascii?q?FP3IMgRyPMQEB?= X-IronPort-AV: E=Sophos;i="5.60,300,1549929600"; d="scan'208";a="542157335" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 13:34:50 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x32DYoW9002486 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Apr 2019 13:34:50 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 08:34:49 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 09:34:48 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 09:34:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LIJ7ceW9YK6TlEzQiRMHcqfi3+padIVzfiVACSf8JjY=; b=OjBHF1WWwmfKd+y1Qe1QnkZcxr89eoqxZIuJJC0OduSSHbkhVjeYIWf53kXL4Kcfam5v3DNEd6ipC/FN1S/SPLwq6I+FpbP4D+Qj8M4jjf1VBjyCfnS6S1HcHsbLRq3z56XvGpHzWDNti4x+Xo9JzKXVcWR2/f940U984tCpWBY= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4029.namprd11.prod.outlook.com (10.255.181.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.22; Tue, 2 Apr 2019 13:34:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Tue, 2 Apr 2019 13:34:47 +0000 From: "Pascal Thubert (pthubert)" To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , "Michael Richardson" CC: 6tisch <6tisch@ietf.org> Thread-Topic: [6tisch] Progress zero-touch document Thread-Index: AQHU6VNtE8HY08QcQki/mXT6U/kPJaYo261Q Date: Tue, 2 Apr 2019 13:34:38 +0000 Deferred-Delivery: Tue, 2 Apr 2019 13:34:24 +0000 Message-ID: References: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> In-Reply-To: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a0169c6-7404-4848-b28b-08d6b76ff96f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB4029; x-ms-traffictypediagnostic: MN2PR11MB4029: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(396003)(136003)(39860400002)(199004)(189003)(13464003)(52054003)(6306002)(486006)(478600001)(66574012)(305945005)(6436002)(316002)(6246003)(55016002)(81156014)(76176011)(4326008)(81166006)(52536014)(8936002)(7696005)(68736007)(53936002)(14444005)(8676002)(966005)(256004)(9686003)(2906002)(6666004)(71200400001)(53546011)(25786009)(6506007)(71190400001)(102836004)(5660300002)(46003)(229853002)(7736002)(446003)(86362001)(186003)(97736004)(6116002)(110136005)(106356001)(74316002)(11346002)(99286004)(476003)(14454004)(105586002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4029; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: I9UrbEaa8UYOWXxbMfSonFrenxD+MXMdoFi+5sOtpwG6IW1gHoQQ4nskUF8y43POuyBk89/hu+MLvfaSbr+IN3oCrL6GmRZg5l1ABPYl3eUPon1Z5m3Eg1UFiEydTavF9saBCqPYJvXTblIlEf652b4UxbwI4B86OxwhBY6w4Knmgb7s3+tKMFo9nYM5A1aEO22WxbW3upJPazVUdE8vd3vdYaPu/gda0gBqhzKsz7/H6CPoSGKHn1696FVxRpapSCabVK2sLXl0pc9Lp7LFKyzvTu8zZ797uQacqENw4yb1uxhdGhQiu4rAafYFM6AvbGfpkTEJrgUBN5OXEdSV2u6w/m5uQC2SNiNaE8nUaohgnRZUHVoqxqNYQYjRYSsrsLkWi+MWJ6Q4bNUGilDM5iGZY1X5NpBpDpqwBx0evuE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5a0169c6-7404-4848-b28b-08d6b76ff96f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 13:34:47.1752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4029 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [6tisch] Progress zero-touch document X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:34:55 -0000 SGVsbG8gTWFsaXNhDQoNClNwZWFraW5nIGZvciBteXNlbGYgaGVyZSwgSSdtIGhhcHB5IHRoYXQg eW91IHN0YXJ0IG9uIHRoYXQgZGlyZWN0aW9uIGFscmVhZHk7IGJ1dCB3b3VsZCBsaWtlIHRvIHNl ZSB0aGUgZWRob2MgZ3JvdXAgZm9ybWVkIGFuZCBwcm9ncmVzc2luZyBiZWZvcmUgY29tbWl0dGlu ZyBmdWxseSB0byBpdC4NCg0KQWxsIHRoZSBiZXN0LA0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiA2dGlzY2ggPDZ0aXNjaC1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgTWFsacWhYSBWdWNpbmljDQo+IFNlbnQ6IG1hcmRpIDIgYXZyaWwgMjAx OSAxNDo1NQ0KPiBUbzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+ DQo+IENjOiA2dGlzY2ggPDZ0aXNjaEBpZXRmLm9yZz4NCj4gU3ViamVjdDogWzZ0aXNjaF0gUHJv Z3Jlc3MgemVyby10b3VjaCBkb2N1bWVudA0KPiANCj4gTWljaGFlbCwgYWxsLA0KPiANCj4gV2l0 aCB0aGUgRURIT0Mgc3BlY2lmaWNhdGlvbiBmaW5hbGx5IHNlZWluZyBwcm9ncmVzcyAoc2VlIFsx XSksIGl0IHNlZW1zIGxpa2UgYQ0KPiBnb29kIHRpbWUgdG8gcmVzdGFydCB0aGUgd29yayBvbiB6 ZXJvIHRvdWNoIGFuZCBwcm9ncmVzcyB0aGUgYWRvcHRlZCB3b3JraW5nDQo+IGdyb3VwIGRvY3Vt ZW50Lg0KPiANCj4gUmVhZGluZyB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtNnRp c2NoLWR0c2VjdXJpdHktemVyb3RvdWNoLWpvaW4tMDMsIGl0DQo+IHNlZW1zIHRoYXQgdGhlcmUg YXJlIG1hbnkgb3B0aW9ucyBhdmFpbGFibGUsIGluY2x1ZGluZyB0aGUgY2hvaWNlIGJldHdlZW4N Cj4gRFRMUyBhbmQgRURIT0MgZm9yIGF1dGhlbnRpY2F0aW9uLiBNYW55IGF2YWlsYWJsZSBvcHRp b25zIG1heSBwb3NlDQo+IGludGVyb3BlcmFiaWxpdHkgY2hhbGxlbmdlcyBhbmQgYWxzbyBhZGQg dW5uZWNlc3NhcnkgY29kZSBjb21wbGV4aXR5LiBHaXZlbg0KPiB0aGF0IHRoZSB3b3JraW5nIGdy b3VwIGRlY2lkZWQgb24gdXNpbmcgT1NDT1JFIGR1cmluZyBuZXR3b3JrIGFjY2VzcyBbMl0sIGFz DQo+IHdlbGwgYXMgZm9yIGFwcGxpY2F0aW9uIHB1cnBvc2VzIFszXSwgdGhlIGltcGxlbWVudGF0 aW9uIG9mIHRoZSA2VGlTQ0ggc3RhY2sNCj4gaW5jbHVkZXMgdGhlIENCT1IvQ09TRSBwcmltaXRp dmVzIGluIHRoZSBmb290cHJpbnQsIGFzIHdlbGwgYXMgdGhlIHN1cHBvcnQgdG8NCj4gZ28gdGhy b3VnaCBhbiBhcHBsaWNhdGlvbi1sYXllciBwcm94eSBhcyBzcGVjaWZpZWQgaW4gWzJdLiBFREhP QyBwcm90b2NvbCBpcw0KPiBidWlsdCBvbiB0aGVzZSBwcmltaXRpdmVzLCBjYW4gYmUgZWFzaWx5 IGNhcnJpZWQgd2l0aGluIG1lc3NhZ2VzIHNwZWNpZmllZCBpbiBbMl0NCj4gZm9yIG5ldHdvcmsg YWNjZXNzIHRvIGdvIHRocm91Z2ggYW4gYXBwbGljYXRpb24tbGF5ZXIgcHJveHksIGFuZCBpcyBx dWl0ZQ0KPiBlZmZpY2llbnQgd2hlbiBpdCBjb21lcyB0byB0aGUgZW5jb2Rpbmcgb3ZlcmhlYWQg dXNpbmcgQ0JPUiByZXN1bHRpbmcgaW4gYQ0KPiBzbWFsbCBudW1iZXIgb2YgTDIgZnJhbWVzIHRv IGNvbXBsZXRlIHRoZSBrZXkgZXhjaGFuZ2UuIEl0IHNlZW1zIGFzIGEgbmF0dXJhbA0KPiB3YXkg Zm9yd2FyZCBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gZm9jdXMgb24gdXNpbmcgRURIT0MgaW4g WzRdLg0KPiANCj4gVGhlcmVmb3JlLCBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0byBrZWVwIHRy YWNrIG9mIHRoZSBFREhPQyBwcm9ncmVzcyBhbmQgdG8NCj4gd29yayBvbiBhIG1vcmUgc3RyZWFt bGluZWQgemVyby10b3VjaCBzb2x1dGlvbi4gRG9pbmcgdGhlc2UgY2hhbmdlcyBpbiBbNF0NCj4g c2VlbXMgdG8gbWFrZSB0aGUgbW9zdCBzZW5zZSBhdCB0aGlzIHBvaW50Lg0KPiANCj4gV2hhdCBh cmUgeW91ciB0aG91Z2h0cyBvbiB0aGlzPw0KPiANCj4gTWFsacWhYQ0KPiANCj4gWzFdDQo+IGh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2VjZGlzcGF0Y2gvS3pfNnk2SnE0 SHNXeGdsc1VIYWZXag0KPiBYSW0wYw0KPiBbMl0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC1zZWN1cml0eS8NCj4gWzNdIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRpc2NoLWFyY2hpdGVjdHVyZS8N Cj4gWzRdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRpc2No LWR0c2VjdXJpdHktemVyb3RvdWNoLQ0KPiBqb2luLw0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA2dGlzY2ggbWFpbGluZyBsaXN0DQo+IDZ0aXNj aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNj aA0K From nobody Tue Apr 2 07:59:08 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86F012014C for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 07:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb80NBAL9ETi for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 07:59:03 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 2E3141200F7 for <6tisch@ietf.org>; Tue, 2 Apr 2019 07:59:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,301,1549926000"; d="scan'208";a="376860588" Received: from wifi-pro-83-211.paris.inria.fr ([128.93.83.211]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2019 16:59:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= In-Reply-To: Date: Tue, 2 Apr 2019 16:59:00 +0200 Cc: Michael Richardson , 6tisch <6tisch@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] Progress zero-touch document X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 14:59:07 -0000 Hello Pascal, Are you suggesting that we should start working out the details on using = EDHOC but keep an alternative as an appendix in the document? Since we = have stalled on this work for some time for reasons outside of the = working group control, I think it would make sense to catch up.. Let me know. Mali=C5=A1a > On 2 Apr 2019, at 15:34, Pascal Thubert (pthubert) = wrote: >=20 > Hello Malisa >=20 > Speaking for myself here, I'm happy that you start on that direction = already; but would like to see the edhoc group formed and progressing = before committing fully to it. >=20 > All the best, >=20 > Pascal >=20 >> -----Original Message----- >> From: 6tisch <6tisch-bounces@ietf.org> On Behalf Of Mali=C5=A1a = Vucinic >> Sent: mardi 2 avril 2019 14:55 >> To: Michael Richardson >> Cc: 6tisch <6tisch@ietf.org> >> Subject: [6tisch] Progress zero-touch document >>=20 >> Michael, all, >>=20 >> With the EDHOC specification finally seeing progress (see [1]), it = seems like a >> good time to restart the work on zero touch and progress the adopted = working >> group document. >>=20 >> Reading the current version of = draft-ietf-6tisch-dtsecurity-zerotouch-join-03, it >> seems that there are many options available, including the choice = between >> DTLS and EDHOC for authentication. Many available options may pose >> interoperability challenges and also add unnecessary code complexity. = Given >> that the working group decided on using OSCORE during network access = [2], as >> well as for application purposes [3], the implementation of the = 6TiSCH stack >> includes the CBOR/COSE primitives in the footprint, as well as the = support to >> go through an application-layer proxy as specified in [2]. EDHOC = protocol is >> built on these primitives, can be easily carried within messages = specified in [2] >> for network access to go through an application-layer proxy, and is = quite >> efficient when it comes to the encoding overhead using CBOR resulting = in a >> small number of L2 frames to complete the key exchange. It seems as a = natural >> way forward for the working group to focus on using EDHOC in [4]. >>=20 >> Therefore, I would like to propose to keep track of the EDHOC = progress and to >> work on a more streamlined zero-touch solution. Doing these changes = in [4] >> seems to make the most sense at this point. >>=20 >> What are your thoughts on this? >>=20 >> Mali=C5=A1a >>=20 >> [1] >> = https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWj >> XIm0c >> [2] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ >> [3] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ >> [4] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch- >> join/ >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch From nobody Tue Apr 2 08:03:55 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC4C120159 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 08:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EH209xn/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cNpqef57 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsCFwfRd4tjP for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 08:03:52 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18560120156 for <6tisch@ietf.org>; Tue, 2 Apr 2019 08:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4906; q=dns/txt; s=iport; t=1554217432; x=1555427032; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CdOfAKgC5+76VkmxUZzwT8dasbcEv+5D2NJHgjOpU1g=; b=EH209xn/tMx1rdA0LDIVvkGSSAH/U4Nf+S0+OsXquRqgL01cvHnzOXYe /GnV/qpZXY4t4D5F7vAS60MGOAaCw9uT+vqVfIbxEnjvhd4iO6KmZguSA pDJ4I14gcqsu4zpO1knpSceXMM8YQkyHRywb95A6l/prqWfg9ajD77WeF w=; IronPort-PHdr: =?us-ascii?q?9a23=3AUMl5UhfiiayHSgvwORZT/MAilGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAABOeKNc/5ldJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYE+UANodAQLJ4QOg0cDjziCV5cRglIDVA4BARgLCYN6RgI?= =?us-ascii?q?XhSUiOBIBAQMBAQkBAwJtHAyFSgEBAQEDAQEhEQwBASUHCwELBAIBCBEBAwE?= =?us-ascii?q?BAQICJgICAiULFQIGCAIEDgUIE4MIgV0DFQECDKMGAooUcYEvgnkBAQWBMQE?= =?us-ascii?q?TQYMHGIIMAwWBCySEXoZVF4FAP4ERRoJMPoJhAQECAQGBX4MIMYIEIoo+gke?= =?us-ascii?q?YUgkCh3KMDpQ4kVyNRgIEAgQFAg4BAQWBZCGBVnAVO4JsggqDboUUhT9yDIE?= =?us-ascii?q?cjzEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,301,1549929600"; d="scan'208";a="254488265" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 15:03:50 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x32F3ocq002051 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Apr 2019 15:03:50 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 10:03:49 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 10:03:49 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 10:03:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CdOfAKgC5+76VkmxUZzwT8dasbcEv+5D2NJHgjOpU1g=; b=cNpqef57ZY1+DykR2OXPWhs3SeW/xP4MTNo0l5NSsARIqWuGJKf3qLxN2y8bbgnWKaBcMDrLO9a9YRJI84f55IF0IntQd5auoofLnXRNBPxLRcplBvDLEz19XrPNU8e1xerKctgvJA1+4ythHZYPHlzIkxZn391H39g/ynGlY40= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3632.namprd11.prod.outlook.com (20.178.251.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Tue, 2 Apr 2019 15:03:48 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Tue, 2 Apr 2019 15:03:48 +0000 From: "Pascal Thubert (pthubert)" To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= CC: Michael Richardson , 6tisch <6tisch@ietf.org> Thread-Topic: [6tisch] Progress zero-touch document Thread-Index: AQHU6VNtE8HY08QcQki/mXT6U/kPJaYo261QgAAa4QCAAADMwA== Date: Tue, 2 Apr 2019 15:03:45 +0000 Deferred-Delivery: Tue, 2 Apr 2019 15:03:43 +0000 Message-ID: References: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f065266-f5eb-43bd-e6ed-08d6b77c68d6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3632; x-ms-traffictypediagnostic: MN2PR11MB3632: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(376002)(39860400002)(366004)(199004)(189003)(52054003)(13464003)(8936002)(6306002)(54906003)(229853002)(6246003)(6436002)(25786009)(106356001)(9686003)(6506007)(6116002)(7736002)(966005)(97736004)(52536014)(476003)(99286004)(186003)(33656002)(14454004)(55016002)(53546011)(53936002)(6666004)(478600001)(105586002)(4326008)(102836004)(305945005)(74316002)(256004)(5660300002)(14444005)(6916009)(446003)(316002)(8676002)(71190400001)(68736007)(11346002)(76176011)(66574012)(81166006)(81156014)(2906002)(46003)(486006)(7696005)(71200400001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3632; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: noQCt3QxxkHc0TZMrUbINPuexptAAfytMS2J2OByG6BIPcyPjiNrJMKH8EW4klw1M8CfPFdln64RPsenUFlxx93wR1c07R+e24C4IsI26w+uzSgIyzgR9ZWgyb0nXU2kSoeRi23f/9Vz+B92QYOQ7usdekYWntzRdIQ3lRaMv6E66BETjPmxjD0KtMAQzXXLDalv3mTQAR8I9ce10C0ExQ/d0WHwDJ5y7W+VjXDaE3+hVc2scoRGhXI9ei5t1oBxjzMSDjFLGC8+pIbMbG3a9AmfBQWehj04DmHmDHjGwYF4AW7PclvZ4Zv7BbrOUAUwsRrmHzPrs1Db/i/9Ufu+iuNxbIfoBpOJBHO3s5Wj0UlMyJQ9JgtWHuPzNNQs8HjJCHa87suqVScvsaHtIXMcs4d1UlC0UnKEvBhsg9TvTyc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f065266-f5eb-43bd-e6ed-08d6b77c68d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 15:03:48.1285 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3632 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [6tisch] Progress zero-touch document X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 15:03:54 -0000 Tm8sIEknbSBzYXlpbmcgdGhhdCBtYXliZSB3ZSBjYW4gcmVmcmFpbiBmcm9tIHB1Ymxpc2hpbmcg aW4gdGhlIG5leHQgd2Vla3MgdGlsbCB0aGUgZGVjaXNpb24gaXMgbWFkZSB0byBmb3JtIHRoZSBn cm91cC4NCkhvcGVmdWxseSB0aGF0J3Mgbm90IHRvbyBsb25nIQ0KDQpBbGwgdGhlIGJlc3QsDQoN ClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hbGnFoWEg VnXEjWluacSHIDxtYWxpc2EudnVjaW5pY0BpbnJpYS5mcj4NCj4gU2VudDogbWFyZGkgMiBhdnJp bCAyMDE5IDE2OjU5DQo+IFRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBj aXNjby5jb20+DQo+IENjOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5j YT47IDZ0aXNjaCA8NnRpc2NoQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogWzZ0aXNjaF0gUHJv Z3Jlc3MgemVyby10b3VjaCBkb2N1bWVudA0KPiANCj4gSGVsbG8gUGFzY2FsLA0KPiANCj4gQXJl IHlvdSBzdWdnZXN0aW5nIHRoYXQgd2Ugc2hvdWxkIHN0YXJ0IHdvcmtpbmcgb3V0IHRoZSBkZXRh aWxzIG9uIHVzaW5nDQo+IEVESE9DIGJ1dCBrZWVwIGFuIGFsdGVybmF0aXZlIGFzIGFuIGFwcGVu ZGl4IGluIHRoZSBkb2N1bWVudD8gU2luY2Ugd2UNCj4gaGF2ZSBzdGFsbGVkIG9uIHRoaXMgd29y ayBmb3Igc29tZSB0aW1lIGZvciByZWFzb25zIG91dHNpZGUgb2YgdGhlIHdvcmtpbmcNCj4gZ3Jv dXAgY29udHJvbCwgSSB0aGluayBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGNhdGNoIHVwLi4NCj4g DQo+IExldCBtZSBrbm93Lg0KPiANCj4gTWFsacWhYQ0KPiANCj4gPiBPbiAyIEFwciAyMDE5LCBh dCAxNTozNCwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0K PiB3cm90ZToNCj4gPg0KPiA+IEhlbGxvIE1hbGlzYQ0KPiA+DQo+ID4gU3BlYWtpbmcgZm9yIG15 c2VsZiBoZXJlLCBJJ20gaGFwcHkgdGhhdCB5b3Ugc3RhcnQgb24gdGhhdCBkaXJlY3Rpb24gYWxy ZWFkeTsNCj4gYnV0IHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBlZGhvYyBncm91cCBmb3JtZWQgYW5k IHByb2dyZXNzaW5nIGJlZm9yZQ0KPiBjb21taXR0aW5nIGZ1bGx5IHRvIGl0Lg0KPiA+DQo+ID4g QWxsIHRoZSBiZXN0LA0KPiA+DQo+ID4gUGFzY2FsDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogNnRpc2NoIDw2dGlzY2gtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIE1hbGnFoWEgVnVjaW5pYw0KPiA+PiBTZW50OiBtYXJkaSAyIGF2cmlsIDIw MTkgMTQ6NTUNCj4gPj4gVG86IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFu LmNhPg0KPiA+PiBDYzogNnRpc2NoIDw2dGlzY2hAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFs2 dGlzY2hdIFByb2dyZXNzIHplcm8tdG91Y2ggZG9jdW1lbnQNCj4gPj4NCj4gPj4gTWljaGFlbCwg YWxsLA0KPiA+Pg0KPiA+PiBXaXRoIHRoZSBFREhPQyBzcGVjaWZpY2F0aW9uIGZpbmFsbHkgc2Vl aW5nIHByb2dyZXNzIChzZWUgWzFdKSwgaXQNCj4gPj4gc2VlbXMgbGlrZSBhIGdvb2QgdGltZSB0 byByZXN0YXJ0IHRoZSB3b3JrIG9uIHplcm8gdG91Y2ggYW5kIHByb2dyZXNzDQo+ID4+IHRoZSBh ZG9wdGVkIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4+DQo+ID4+IFJlYWRpbmcgdGhlIGN1 cnJlbnQgdmVyc2lvbiBvZg0KPiA+PiBkcmFmdC1pZXRmLTZ0aXNjaC1kdHNlY3VyaXR5LXplcm90 b3VjaC1qb2luLTAzLCBpdCBzZWVtcyB0aGF0IHRoZXJlDQo+ID4+IGFyZSBtYW55IG9wdGlvbnMg YXZhaWxhYmxlLCBpbmNsdWRpbmcgdGhlIGNob2ljZSBiZXR3ZWVuIERUTFMgYW5kDQo+ID4+IEVE SE9DIGZvciBhdXRoZW50aWNhdGlvbi4gTWFueSBhdmFpbGFibGUgb3B0aW9ucyBtYXkgcG9zZQ0K PiA+PiBpbnRlcm9wZXJhYmlsaXR5IGNoYWxsZW5nZXMgYW5kIGFsc28gYWRkIHVubmVjZXNzYXJ5 IGNvZGUgY29tcGxleGl0eS4NCj4gPj4gR2l2ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBkZWNp ZGVkIG9uIHVzaW5nIE9TQ09SRSBkdXJpbmcgbmV0d29yaw0KPiA+PiBhY2Nlc3MgWzJdLCBhcyB3 ZWxsIGFzIGZvciBhcHBsaWNhdGlvbiBwdXJwb3NlcyBbM10sIHRoZQ0KPiA+PiBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgNlRpU0NIIHN0YWNrIGluY2x1ZGVzIHRoZSBDQk9SL0NPU0UgcHJpbWl0aXZl cw0KPiA+PiBpbiB0aGUgZm9vdHByaW50LCBhcyB3ZWxsIGFzIHRoZSBzdXBwb3J0IHRvIGdvIHRo cm91Z2ggYW4NCj4gPj4gYXBwbGljYXRpb24tbGF5ZXIgcHJveHkgYXMgc3BlY2lmaWVkIGluIFsy XS4gRURIT0MgcHJvdG9jb2wgaXMgYnVpbHQNCj4gPj4gb24gdGhlc2UgcHJpbWl0aXZlcywgY2Fu IGJlIGVhc2lseSBjYXJyaWVkIHdpdGhpbiBtZXNzYWdlcyBzcGVjaWZpZWQNCj4gPj4gaW4gWzJd IGZvciBuZXR3b3JrIGFjY2VzcyB0byBnbyB0aHJvdWdoIGFuIGFwcGxpY2F0aW9uLWxheWVyIHBy b3h5LA0KPiA+PiBhbmQgaXMgcXVpdGUgZWZmaWNpZW50IHdoZW4gaXQgY29tZXMgdG8gdGhlIGVu Y29kaW5nIG92ZXJoZWFkIHVzaW5nIENCT1INCj4gcmVzdWx0aW5nIGluIGEgc21hbGwgbnVtYmVy IG9mIEwyIGZyYW1lcyB0byBjb21wbGV0ZSB0aGUga2V5IGV4Y2hhbmdlLiBJdA0KPiBzZWVtcyBh cyBhIG5hdHVyYWwgd2F5IGZvcndhcmQgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGZvY3VzIG9u IHVzaW5nDQo+IEVESE9DIGluIFs0XS4NCj4gPj4NCj4gPj4gVGhlcmVmb3JlLCBJIHdvdWxkIGxp a2UgdG8gcHJvcG9zZSB0byBrZWVwIHRyYWNrIG9mIHRoZSBFREhPQw0KPiA+PiBwcm9ncmVzcyBh bmQgdG8gd29yayBvbiBhIG1vcmUgc3RyZWFtbGluZWQgemVyby10b3VjaCBzb2x1dGlvbi4gRG9p bmcNCj4gPj4gdGhlc2UgY2hhbmdlcyBpbiBbNF0gc2VlbXMgdG8gbWFrZSB0aGUgbW9zdCBzZW5z ZSBhdCB0aGlzIHBvaW50Lg0KPiA+Pg0KPiA+PiBXaGF0IGFyZSB5b3VyIHRob3VnaHRzIG9uIHRo aXM/DQo+ID4+DQo+ID4+IE1hbGnFoWENCj4gPj4NCj4gPj4gWzFdDQo+ID4+IGh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2VjZGlzcGF0Y2gvS3pfNnk2SnE0SHNXeGdsc1VI YQ0KPiA+PiBmV2oNCj4gPj4gWEltMGMNCj4gPj4gWzJdDQo+ID4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJpdHkvDQo+ID4+ IFszXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZ0aXNjaC1h cmNoaXRlY3R1cmUvDQo+ID4+IFs0XQ0KPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLTZ0aXNjaC1kdHNlY3VyaXR5LXplcm90b3UNCj4gPj4gY2gtDQo+ID4+ IGpvaW4vDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+IDZ0aXNjaCBtYWlsaW5nIGxpc3QNCj4gPj4gNnRpc2NoQGlldGYub3JnDQo+ID4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoDQoNCg== From nobody Tue Apr 2 08:05:00 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DD3120159 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8skhtujOzawR for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 08:04:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55F9120156 for <6tisch@ietf.org>; Tue, 2 Apr 2019 08:04:56 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8BAB338263; Tue, 2 Apr 2019 11:04:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3F8A71791; Tue, 2 Apr 2019 11:04:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D16E5D; Tue, 2 Apr 2019 11:04:55 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FB=3FTWFsacWhYSBWdcSNaW5pxIc=3D=3F=3D?= cc: 6tisch <6tisch@ietf.org> In-Reply-To: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> References: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] Progress zero-touch document X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 15:04:59 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > Reading the current version of > draft-ietf-6tisch-dtsecurity-zerotouch-join-03, it seems that there a= re The current version is shit, and I need to rewrite it, almost from scratch. I intend to do that in the next couple of weeks, once I get the BRSKI throu= gh WGLC. > Therefore, I would like to propose to keep track of the EDHOC progress > and to work on a more streamlined zero-touch solution. Doing these > changes in [4] seems to make the most sense at this point. > What are your thoughts on this? If you want to start now, please go ahead, but I'd prefer if you waited thr= ee weeks. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyjehYACgkQgItw+93Q 3WVmAAgAlcGHTms8wjBy6mtBsFuUvcqxVEyxoXxTIVpMqWTyZ0jg2sySNTvugVJh dnxDPQbuILWCgErq4HEhz4xVclotKYbTdlcp3Fo5m6dD9ng7/dStauUDBKTehBjX iTfiNFk87q2OrU3Zx6rJv+k1hSRBMlcIAjQkjdiAK2C8Nb+2/vx+nCdD1sPBBikY hkFY9AHAvrBChMxwABkO3AXgvWegO+Hg76s1FPd4WEFbBcID3pZwJyVob7GFmlfp 3NYqcrMQMLAzFO09Nj9d+Cco4ttAT2k9OL2cfyltWJ4kZsOq+Y0Lmx5JW7VASrbt w/BzR/F/wOMgDPlnr17yBx1Eq+OQvA== =TvmO -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 2 09:14:04 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74731201AA for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 09:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYbWzp5sTl4q for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 09:13:53 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 A460E120181 for <6tisch@ietf.org>; Tue, 2 Apr 2019 09:13:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,301,1549926000"; d="scan'208,217";a="376876420" Received: from wifi-pro-83-211.paris.inria.fr ([128.93.83.211]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2019 18:13:50 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <227CB668-DDB8-4CBC-A3F3-37241D2466B0@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_F925F57B-FE20-4D00-9251-E11EF9750EEE" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 2 Apr 2019 18:13:50 +0200 In-Reply-To: <12363.1554217495@localhost> Cc: 6tisch <6tisch@ietf.org> To: Michael Richardson References: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> <12363.1554217495@localhost> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] Progress zero-touch document X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 16:14:03 -0000 --Apple-Mail=_F925F57B-FE20-4D00-9251-E11EF9750EEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 How about we form a focused design team to start working out the details = and we can do the editorial work and publish once the EDHOC decision is = out? Mali=C5=A1a > On 2 Apr 2019, at 17:04, Michael Richardson = wrote: >=20 >>=20 >> What are your thoughts on this? >=20 > If you want to start now, please go ahead, but I'd prefer if you = waited three > weeks. --Apple-Mail=_F925F57B-FE20-4D00-9251-E11EF9750EEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 How = about we form a focused design team to start working out the details and = we can do the editorial work and publish once the EDHOC decision is = out?

Mali=C5=A1a

On 2 Apr 2019, at 17:04, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


What are your thoughts on this?

If you want to start now, please go ahead, but I'd prefer if = you waited three
weeks.

= --Apple-Mail=_F925F57B-FE20-4D00-9251-E11EF9750EEE-- From nobody Tue Apr 2 11:07:44 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270B120172 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 11:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=I2kxSBiZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lFF8Pd4Y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_okMUoCQoS9 for <6tisch@ietfa.amsl.com>; Tue, 2 Apr 2019 11:07:38 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83480120167 for <6tisch@ietf.org>; Tue, 2 Apr 2019 11:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6147; q=dns/txt; s=iport; t=1554228458; x=1555438058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+rklBJXAzN7qlsvUdh0815QRYTRG6ytje7L1Hok/hNs=; b=I2kxSBiZR0xvUK5JmftZaz1UVRfz3eHXyj73LnQspGMKBsvCqn2GxDEu d/n3mIY+GK7kv/A+HpR+kjdim+UCmLYnhMqWq41v1aM3XjDM7BvA37XPG rIuC+KWVqjBcCRjH7hMrWw6rU33UuVfydIebiAdzyvcPTOvcLY66umSvl g=; IronPort-PHdr: =?us-ascii?q?9a23=3A1Z4caBFC1cC6VM6Jy1Hcbp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAADno6Nc/5ldJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEPL1ADaHQECycKhASDRwOPOJUfhEmCUgNUDgEBGAEKCYN?= =?us-ascii?q?6RgIXhSUiOBIBAQMBAQkBAwJtHAyFSwIBAwEBIR0BASwLAQ8CAQg/AwICAiU?= =?us-ascii?q?LFBECBA4FgyIBgRFMAxUBAgELoyECihRxgS+CeQEBBYExAYEUgjwYggwDBYE?= =?us-ascii?q?vizMXgUA/gTgfgkw+gmEBAYIOgl0xggQiij4+ggmEJZQtCQKTZhMHggOGDow?= =?us-ascii?q?nnyICBAIEBQIOAQEFgWQhgVZwFTsqAYJBggqDboUUhT9ygSiODQGBHgEB?= X-IronPort-AV: E=Sophos;i="5.60,301,1549929600"; d="scan'208,217";a="253408204" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 18:07:37 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x32I7bAt025650 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Apr 2019 18:07:37 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 13:07:36 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 14:07:35 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 13:07:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+rklBJXAzN7qlsvUdh0815QRYTRG6ytje7L1Hok/hNs=; b=lFF8Pd4YSZWzSdD7uap2C7lO8toygCoaXsAHDOiVarBlLroMOkUqD3r70XxvQjc7yvCemedGLVWfXdAxlXAQ5Bw0tjpLF6ZhY24iUKUxWAcYZ4Yv97TNbWvqRHZxv6U7K9mBv/AUJxVb9DFIqqFpO6qzjGOSuwxfCGGoeT1IwxU= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3727.namprd11.prod.outlook.com (20.178.252.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Tue, 2 Apr 2019 18:07:34 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Tue, 2 Apr 2019 18:07:34 +0000 From: "Pascal Thubert (pthubert)" To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= CC: Michael Richardson , 6tisch <6tisch@ietf.org> Thread-Topic: [6tisch] Progress zero-touch document Thread-Index: AQHU6W8OE8HY08QcQki/mXT6U/kPJaYpKwam Date: Tue, 2 Apr 2019 18:07:33 +0000 Message-ID: References: <800982CD-FCE1-48AC-A4BB-0FE249685806@inria.fr> <12363.1554217495@localhost>,<227CB668-DDB8-4CBC-A3F3-37241D2466B0@inria.fr> In-Reply-To: <227CB668-DDB8-4CBC-A3F3-37241D2466B0@inria.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [91.69.164.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fd4bca1-8db8-42f1-453a-08d6b79614c1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3727; x-ms-traffictypediagnostic: MN2PR11MB3727: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(396003)(39860400002)(136003)(52054003)(189003)(199004)(36756003)(76176011)(606006)(83716004)(71200400001)(71190400001)(11346002)(486006)(256004)(316002)(446003)(25786009)(106356001)(3846002)(14454004)(105586002)(6116002)(82746002)(2906002)(4326008)(4744005)(2616005)(54906003)(966005)(476003)(66066001)(5660300002)(86362001)(8676002)(99286004)(53936002)(6506007)(53546011)(97736004)(478600001)(186003)(26005)(8936002)(102836004)(229853002)(6512007)(81156014)(81166006)(7736002)(68736007)(6246003)(6486002)(54896002)(6306002)(6916009)(6436002)(33656002)(236005)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3727; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4YQ2og3V1ypJ0zTJ9mmojagqta7twqWik8DFggIJbkOq2Vn/xFKfCQjmBhRljaSiMRquk5X60hjQUdeVtnsvUN/Gzkha2sHaag9oF2c/cmABs7POevw8bSXUStS7QohXhEUzvosRTCgNqf0kRO3ZMrPCS0RTVhG2FkIuFcUllw6M+iE3gjlLLx/3/lQG3uW/7NX0d+hzMiRqfC2Z39hTyDYq0BvTbl/wlAxRoJa+AOIygj9kb5tfr4C1JF9WKaKWBtbYbcYCO5gegnwk3/yUlYiRH44kY8Hht9cdkNL2p3YgTr5zKiDNmxgffRAOEOEk06Qb004Hm1odwQVctXquIpKLoJOEFvB1BPuLbuN7oB84IZCy3uD09FT2tqVSBJcv11MRfQTE0isiLK0y3/jCNZEDbEK0F/psF6p5mkpRaWE= Content-Type: multipart/alternative; boundary="_000_E8754BCF7BC04FB48B556D9B4FC33C1Cciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5fd4bca1-8db8-42f1-453a-08d6b79614c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 18:07:33.8810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3727 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [6tisch] Progress zero-touch document X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 18:07:43 -0000 --_000_E8754BCF7BC04FB48B556D9B4FC33C1Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V291bGQgYmUgZ3JlYXQgKGFjdHVhbGx5IHRvIHJlY29uc3RydWN0IGl0ISkNCldob+KAmXMgaW4/ DQoNCg0KUmVnYXJkcywNCg0KUGFzY2FsDQoNCkxlIDIgYXZyLiAyMDE5IMOgIDE4OjE0LCBNYWxp xaFhIFZ1xI1pbmnEhyA8bWFsaXNhLnZ1Y2luaWNAaW5yaWEuZnI8bWFpbHRvOm1hbGlzYS52dWNp bmljQGlucmlhLmZyPj4gYSDDqWNyaXQgOg0KDQpIb3cgYWJvdXQgd2UgZm9ybSBhIGZvY3VzZWQg ZGVzaWduIHRlYW0gdG8gc3RhcnQgd29ya2luZyBvdXQgdGhlIGRldGFpbHMgYW5kIHdlIGNhbiBk byB0aGUgZWRpdG9yaWFsIHdvcmsgYW5kIHB1Ymxpc2ggb25jZSB0aGUgRURIT0MgZGVjaXNpb24g aXMgb3V0Pw0KDQpNYWxpxaFhDQoNCk9uIDIgQXByIDIwMTksIGF0IDE3OjA0LCBNaWNoYWVsIFJp Y2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyK2lldGZAc2FuZGVsbWFu LmNhPj4gd3JvdGU6DQoNCg0KV2hhdCBhcmUgeW91ciB0aG91Z2h0cyBvbiB0aGlzPw0KDQpJZiB5 b3Ugd2FudCB0byBzdGFydCBub3csIHBsZWFzZSBnbyBhaGVhZCwgYnV0IEknZCBwcmVmZXIgaWYg eW91IHdhaXRlZCB0aHJlZQ0Kd2Vla3MuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo2dGlzY2ggbWFpbGluZyBsaXN0DQo2dGlzY2hAaWV0Zi5vcmc8 bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vNnRpc2NoDQo= --_000_E8754BCF7BC04FB48B556D9B4FC33C1Cciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpX b3VsZCBiZSBncmVhdCAoYWN0dWFsbHkgdG8gcmVjb25zdHJ1Y3QgaXQhKQ0KPGRpdj5XaG/igJlz IGluPzxicj4NCjxicj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSIgZGlyPSJsdHIiPg0K PGRpdj48YnI+DQo8L2Rpdj4NClJlZ2FyZHMsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QYXNj YWw8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KTGUgMiBhdnIuIDIwMTkgw6Ag MTg6MTQsIE1hbGnFoWEgVnXEjWluacSHICZsdDs8YSBocmVmPSJtYWlsdG86bWFsaXNhLnZ1Y2lu aWNAaW5yaWEuZnIiPm1hbGlzYS52dWNpbmljQGlucmlhLmZyPC9hPiZndDsgYSDDqWNyaXQmbmJz cDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGly PSJsdHIiPkhvdyBhYm91dCB3ZSBmb3JtIGEgZm9jdXNlZCBkZXNpZ24gdGVhbSB0byBzdGFydCB3 b3JraW5nIG91dCB0aGUgZGV0YWlscyBhbmQgd2UgY2FuIGRvIHRoZSBlZGl0b3JpYWwgd29yayBh bmQgcHVibGlzaCBvbmNlIHRoZSBFREhPQyBkZWNpc2lvbiBpcyBvdXQ/DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYWxpxaFhPGJyIGNsYXNzPSIi Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+T24gMiBBcHIgMjAxOSwgYXQgMTc6MDQsIE1pY2hhZWwgUmljaGFyZHNv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EiIGNsYXNzPSIi Pm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQpXaGF0IGFyZSB5b3VyIHRob3VnaHRzIG9uIHRoaXM/PGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi PklmDQogeW91IHdhbnQgdG8gc3RhcnQgbm93LCBwbGVhc2UgZ28gYWhlYWQsIGJ1dCBJJ2QgcHJl ZmVyIGlmIHlvdSB3YWl0ZWQgdGhyZWU8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPndlZWtzLjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+NnRpc2NoIG1haWxpbmcgbGlzdDwv c3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIj42dGlzY2hA aWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvLzZ0aXNjaDwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E8754BCF7BC04FB48B556D9B4FC33C1Cciscocom_-- From nobody Tue Apr 2 18:06:46 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F6F1203FE; Tue, 2 Apr 2019 18:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85lstXCS_n0x; Tue, 2 Apr 2019 18:06:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E808D120401; Tue, 2 Apr 2019 18:06:42 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 14E9F38263; Tue, 2 Apr 2019 21:05:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5C772340F; Tue, 2 Apr 2019 21:06:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5A1681C1F; Tue, 2 Apr 2019 21:06:41 -0400 (EDT) From: Michael Richardson To: 6tisch@ietf.org cc: draft-tiloca-6tisch-robust-scheduling@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 01:06:45 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I read draft-tiloca-6tisch-robust-scheduling-01. I found this to be an interesting way to both announce the schedule, and ye= t, hide it. Very well done. I have some initial comment about the section 3.1 about the adversary. I wondered about why someone would do this. What's the benefit. It occured to me that an important point about the selective jamming is that an attacker can mess with a competitors network while still permitting their own network to operate! That might be worth adding. The document seems well written, although I'd like to have some example keys and show how they permute things in practice so that implementors can validate their work. The additions to CoJP seems well done, I'm so glad we changed that to a hash From=20an array :-) If the permutation is replaced whenever the network key is changed, which means that the permutation is going to change! This means that some nodes could be on the new permutation while others are on the old. A thought to deal with this is that the new permutation is not used until t= he node switches to the new keys. EXCEPT that the adjacent nodes will now not be listening at the right time, won't hear traffic encrypted with the new key, and won't change over themselves. Authenticated enhanced beacons wou= ld perhaps help here. Maybe I'm wrong about this problem. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlykByEACgkQgItw+93Q 3WV6eAf/beKjPSvlT5gO4UuCFp1LWs3I4psV65OTO6OaY0AIfqQvCrK8WVHmjnDz e7vDqPcijAm69NIP5ZR1oQRR74Z9ROU/Yza9O0syqNSxxQ0qnosti8glyb85U2Sp AVmo38r9clHVg+3+06Dau6QmshtofLeFIoNKbBxOK1jMfbMdnIxVfxdVoQFTlqoX CMshsxeigxkYrJGg+4mLGRe0WmGi03AwNrr7W3H2ERDPJzVxLQFrtqgusPVLAbd6 SG6tD+kBptJf/uXl/MAwLBBzhCOdBHQiCRgM/bqo86hcY/Bsk3DVJHGvIgftkH06 Hn/fgSS434bJ8+EB0lbRJSDNYoT6qQ== =8fiV -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 4 00:04:51 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A978A1203A5; Thu, 4 Apr 2019 00:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.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 4t1rjnL4DP_6; Thu, 4 Apr 2019 00:04:44 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10084.outbound.protection.outlook.com [40.107.1.84]) (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 B1E85120004; Thu, 4 Apr 2019 00:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QQIFSXlobe2aXv+Y2eK2hozhwcotnOuO9codNeBjLBU=; b=Z4jUN2CKy1Y+N3t809Rv8T/klDI7kGFN02pMOHNhdohsA8osprcCd7FlnXuXi16R1kgdoBaapqJxK0z9Vot5J5yzMmSXaLmTW3Zhfgl+4h1fYvaQVY2MdQqyKySBVlSOtFM5y6Y4pxSWWQ2j5osAi7YIYiG6VBriykKtuVclGb4= Received: from DB6P18901CA0015.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::25) by HE1P18901MB0106.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:9b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.16; Thu, 4 Apr 2019 07:04:40 +0000 Received: from AM5EUR02FT056.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::209) by DB6P18901CA0015.outlook.office365.com (2603:10a6:4:16::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15 via Frontend Transport; Thu, 4 Apr 2019 07:04:40 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT056.mail.protection.outlook.com (10.152.9.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1750.20 via Frontend Transport; Thu, 4 Apr 2019 07:04:40 +0000 Received: from [10.8.1.7] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 4 Apr 2019 09:04:39 +0200 To: Michael Richardson , <6tisch@ietf.org> CC: References: <5427.1554253601@localhost> From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> Date: Thu, 4 Apr 2019 09:04:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <5427.1554253601@localhost> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y5PMUyvinTJhfNNODgcOTDdKAmFXnGipz" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39860400002)(376002)(2980300002)(495844002)(189003)(199004)(81166006)(126002)(64126003)(106002)(305945005)(7736002)(478600001)(44832011)(11346002)(486006)(31686004)(58126008)(5660300002)(14444005)(16576012)(74482002)(110136005)(6246003)(5024004)(966005)(6306002)(3846002)(16586007)(6116002)(69596002)(66574012)(235185007)(68736007)(568964002)(4326008)(53936002)(476003)(356004)(2906002)(336012)(104016004)(186003)(8936002)(26005)(65806001)(53546011)(6666004)(16526019)(97736004)(2616005)(229853002)(22746008)(81156014)(22756006)(40036005)(386003)(316002)(86362001)(106466001)(8676002)(65826007)(31696002)(33964004)(446003)(65956001)(77096007)(84326002)(71190400001)(36756003)(21480400003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P18901MB0106; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 86a66e4b-b086-4a49-0bc1-08d6b8cbce7d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1P18901MB0106; X-MS-TrafficTypeDiagnostic: HE1P18901MB0106: X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0997523C40 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: yPiDib9IX6ceQelpq0b7LAA9cfLwkikBBw11LrXPNEoh2bDq/zJDPWUq7Rvu7r46fxqrnJzgsifgeCCpMyN4JbBl3L/2Dmz7++PBGFXC4+xeDp3etHNMPzGskh/hYVr1dvnYMcdgBCaOlrsbOCe6GtMRtiafmMm7rMvrg+z9xMWv3z+/h+eSMsgbZ8jTUqA2HjoclXK1RMIC8foL3FrqbHEDefjYNn62b2e+tUtQDnRJs+ERDUMwunAoZf/YnxGDIO+BfFNpfSN8lnnyvmIB59i8IZdRGO2zNfyYgB4Y4cbg4Rh85h+Hj34IBKI4PGXZhw77FtxEI1UQBxbZ7PpJQl6Vli0AVoqL5IoAx0MxGe+qFgDDf+RDeinxt3p/k1w4YeSVQ7CGN8uhkpxJghnQ51lIMnenOxmbSMnzD7zFQrE= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2019 07:04:40.0446 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 86a66e4b-b086-4a49-0bc1-08d6b8cbce7d X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P18901MB0106 Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 07:04:49 -0000 --y5PMUyvinTJhfNNODgcOTDdKAmFXnGipz Content-Type: multipart/mixed; boundary="LAyoW9QkeMDvQ5ChWPA4E7YKQtF3aKTd0"; protected-headers="v1" From: Marco Tiloca To: Michael Richardson , 6tisch@ietf.org Cc: draft-tiloca-6tisch-robust-scheduling@ietf.org Message-ID: <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> Subject: Re: draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key References: <5427.1554253601@localhost> In-Reply-To: <5427.1554253601@localhost> --LAyoW9QkeMDvQ5ChWPA4E7YKQtF3aKTd0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Michael, Thank you very much for your review! We'll definitely take into account your comments for the next version. Please, find also some answers inline. Best, /Marco On 4/3/19 3:06 AM, Michael Richardson wrote: > I read draft-tiloca-6tisch-robust-scheduling-01. > > I found this to be an interesting way to both announce the schedule, an= d yet, > hide it. Very well done. Thanks! > > I have some initial comment about the section 3.1 about the adversary. > I wondered about why someone would do this. What's the benefit. > > It occured to me that an important point about the selective jamming is= that > an attacker can mess with a competitors network while still permitting = their > own network to operate! That might be worth adding. It's a very good point! We'll add this as an attack motivation in Section 3.1. > The document seems well written, although I'd like to have some example= keys > and show how they permute things in practice so that implementors can > validate their work. Right, we will produce an example, possibly as an Appendix referred at the end of Section 4. > The additions to CoJP seems well done, I'm so glad we changed that to a= hash > From an array :-) > > If the permutation is replaced whenever the network key is changed, > which means that the permutation is going to change! This means that s= ome > nodes could be on the new permutation while others are on the old. > > A thought to deal with this is that the new permutation is not used unt= il the > node switches to the new keys. EXCEPT that the adjacent nodes will now= not > be listening at the right time, won't hear traffic encrypted with the n= ew > key, and won't change over themselves. Authenticated enhanced beacons= would > perhaps help here. Maybe I'm wrong about this problem. This seems to deserve some more text in the Security Considerations of Section 6.2, such as the following points. The new link keys and permutation keys are expected to be distributed together, just like for the described provisioning through the CoJP Join Response, possibly through the same procedure described in [1]. After a rekeying process is completed, a node should indeed start using the new permutation keys once switched to the new link keys only, i.e. after it has discarded the old key material as per the handling of the "link-layer key set" in [2]. If a node A discards the old key material (considerably) before a node B, they will be temporarily unaligned. That is, node B would temporarily secure outgoing messages still using the old key material [2] that A does not own anymore, and would still permute its schedule the old way. Eventually, B will also discard the old key material, e.g. after receiving and successfully security processing an incoming message secured with the new key material [2], of course though while still over its old-fashion-permuted schedule. Here enhanced beacons authenticated with the new key material seem to help. Also, a local upper bound can be enforced through a parameter similar to COJP_REKEYING_GUARD_TIME [2]. Then, the two nodes will be aligned again on both processing secure messages and permuting their schedule. What do you think? [1] https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section= -8.2 [2] https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section= -8.4 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --LAyoW9QkeMDvQ5ChWPA4E7YKQtF3aKTd0-- --y5PMUyvinTJhfNNODgcOTDdKAmFXnGipz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlylrIYACgkQ7iZktA5Y 2kPsiwf/faNuZzBnNWUNdNenPmmblaJHKgAK5NpMKUB7sIUDczoFfAs5IrFhG2VS KYrg2Y2PSCjafZJF1OutkR4gLnE+q3Rki1kEkNVa1rIjLrnrjwsPHzssxqplEeUD Kdoa/pE27WMG2EqUjrSzFJcljGxJ3AqyrJGdMVnVQ2ZFaEMBWoAJFumZtSTcazxY o4u4XGft2HEWdQ5YMdiWQ76UdYFGwjNldAFCMrYD99a/q7IFj2CSxFkflhA3VqwK t/GboJu2Rf5WCHH7HsmVg5VY5fkF7XgrFiH28jXzNl7jqK5psCzIccLqOU1Tzavi c32uw8EfJbrlpYXhr8QmlgdMGhMxoQ== =zi3Z -----END PGP SIGNATURE----- --y5PMUyvinTJhfNNODgcOTDdKAmFXnGipz-- From nobody Thu Apr 4 02:58:49 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D1F12000E for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 02:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F66W7Smdte4 for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 02:58:46 -0700 (PDT) Received: from mail.dei.unipd.it (webmail2.dei.unipd.it [147.162.2.99]) by ietfa.amsl.com (Postfix) with SMTP id 40B52120005 for <6tisch@ietf.org>; Thu, 4 Apr 2019 02:58:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.dei.unipd.it (Postfix) with ESMTP id 6210840077 for <6tisch@ietf.org>; Thu, 4 Apr 2019 11:58:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at dei.unipd.it Received: from mail.dei.unipd.it ([127.0.0.1]) by localhost (mail.dei.unipd.it [127.0.0.1]) (amavisd-new, port 10024) with SMTP id t9HQZYh4sYov for <6tisch@ietf.org>; Thu, 4 Apr 2019 11:58:43 +0200 (CEST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: fcarnova) by mail.dei.unipd.it (Postfix) with ESMTPSA id 852A0400D3 for <6tisch@ietf.org>; Thu, 4 Apr 2019 11:58:43 +0200 (CEST) Received: by mail-pf1-f174.google.com with SMTP id i17so1112909pfo.6 for <6tisch@ietf.org>; Thu, 04 Apr 2019 02:58:43 -0700 (PDT) X-Gm-Message-State: APjAAAV5W4UfAKDw1dcytTBOdp3NmZIbagMnK8hAz4Ga59aeStSvb5SX AOFiomt6jdrcS2Z6+z5Txo/+wjqYk8LPOhhH6uA= X-Google-Smtp-Source: APXvYqwjyEdXI0rlwad1JrTvuUi494HRhl5fBMBshYN3KeB2OPFDq7sIMjw96CeF07ikmjJPWoHcqqn+FHeoTXxshgY= X-Received: by 2002:a63:1247:: with SMTP id 7mr4847013pgs.352.1554371922289; Thu, 04 Apr 2019 02:58:42 -0700 (PDT) MIME-Version: 1.0 From: Filippo Carnovalini Date: Thu, 4 Apr 2019 11:58:31 +0200 X-Gmail-Original-Message-ID: Message-ID: To: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="00000000000046e8d90585b16a41" Archived-At: Subject: [6tisch] [CFP] [Deadline approaching] GOODTECHS 2019 - Track Session in Serious Games to Improve Quality of Life, 25/09 - 27/09, Valencia, Spain X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 09:58:48 -0000 --00000000000046e8d90585b16a41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -Apologies if you received this CFP multiple times- Deadline approaching! ******************************************************************** * Call for Papers * GoodTechs 2019 *Track Session in Serious Games to Improve Quality of Life * September 25-27, 2019, Valencia, Spain *. SUBMISSION BY 10 APRIL 2019 * ******************************************************************** More info at: http://goodtechs.eu/serious-game-to-improve-the-quality-of-life/ SCOPE =3D=3D=3D=3D=3D=3D Gamification techniques and serious games are often used to capture and maintain user=E2=80=99s attention and motivation. This is particularly impo= rtant when dealing with young patients or people with special needs. Patient=E2= =80=99s collaboration is crucial for doctors to perform a good diagnosis, and to provide an efficient therapy, but it cannot always be taken for granted. Moreover, serious games are proved to be an efficient tool to incentivize people to improve their lifestyle, e.g., making more physical activity. This track will feature new insights, research, and practice on how to design, develop and use gamification and persuasive technologies to create serious games and applications to improve individuals=E2=80=99 Quality of L= ife (QoL) and behavior, with a particular focus on people with disabilities. The track targets researchers, doctoral students, practitioners and other people interested in presenting, discussing, reflecting and networking on central themes associated with the development and use of serious games and applications to help people with special needs. Papers on both theoretical aspects and design method of gamification techniques and serious games are welcomed, as well as system prototypes and novel evaluation methods. In addition, the track welcomes full research, work in progress papers and educational cases. Chair: Ombretta Gaggi, Universit=C3=A0 di Padova Co-Chair: Antonio Rod=C3=A0, Universit=C3=A0 di Padova TOPICS OF INTEREST =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Serious game design for better lifestyle promotion Serious games for people with disability Games for Education and Learning Gamification Pervasive Systems Assistive Technologies Persuasive solutions Methods, models and principles for gamification design Usability and accessibility issues Games for Health and Well-Being Serious Games for social inclusion Serious Games for cultural heritage IMPORTANT DATES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Full Paper Submission deadline: 10 April 2019 Notification deadline: 1 June 2019 Follow the submission instructions at: http://goodtechs.eu/paper-submission/ --00000000000046e8d90585b16a41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-Apologies if you r= eceived this CFP multiple times-

Deadl= ine approaching!

*********= ***********************************************************
* =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Call for Papers
* =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GoodTechs 20= 19
*Track Session in Serious Games to Improve Quality of Life
* =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0September 25-27, 2019, Valencia, Spai= n
*. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SUBM= ISSION BY 10 APRIL 2019
*
************************= ********************************************

=
SCOPE
=3D=3D=3D=3D=3D=3D<= br>

Gamification techniques and serious games are often used to ca= pture and maintain user=E2=80=99s attention and motivation. This is particu= larly important when dealing with young patients or people with special nee= ds. Patient=E2=80=99s collaboration is crucial for doctors to perform a goo= d diagnosis, and to provide an efficient therapy, but it cannot always be t= aken for granted. Moreover, serious games are proved to be an efficient too= l to incentivize people to improve their lifestyle, e.g., making more physi= cal activity.

This track will feature new insights, research, and pr= actice on how to design, develop and use gamification and persuasive techno= logies to create serious games and applications to improve individuals=E2= =80=99 Quality of Life (QoL) and behavior, with a particular focus on peopl= e with disabilities.=C2=A0

The track targets researchers, doctoral s= tudents, practitioners and other people interested in presenting, discussin= g, reflecting and networking on central themes associated with the developm= ent and use of serious games and applications to help people with special n= eeds. Papers on both theoretical aspects and design method of gamification = techniques and serious games are welcomed, as well as system prototypes and= novel evaluation methods. In addition, the track welcomes full research, w= ork in progress papers and educational cases.

Chair: Ombretta Gaggi,= Universit=C3=A0 di Padova
Co-Chair: Antonio Rod=C3=A0, Universit=C3=A0 = di Padova

TOPICS OF INTEREST
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Serious game design for b= etter lifestyle promotion
Serious games for people with disability
Ga= mes for Education and Learning
Gamification
Pervasive Systems
Assi= stive Technologies
Persuasive solutions
Methods, models and principle= s for gamification design
Usability and accessibility issues
Games fo= r Health and Well-Being
Serious Games for social inclusion
Serious Ga= mes for cultural heritage

IMPORTANT DATES
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Full Paper Submission = deadline:=C2=A010 April 2019
Notification deadline: =C2=A01 June 2019
Follow the submission instructions at:=C2=A0http://goodtechs.e= u/paper-submission/=C2=A0
--00000000000046e8d90585b16a41-- From nobody Thu Apr 4 07:04:40 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3BF12067A; Thu, 4 Apr 2019 07:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCRuW4yp9Cbw; Thu, 4 Apr 2019 07:04:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA5212069A; Thu, 4 Apr 2019 07:04:31 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 898C338275; Thu, 4 Apr 2019 10:03:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1D598D63; Thu, 4 Apr 2019 10:04:30 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1B403CBE; Thu, 4 Apr 2019 10:04:30 -0400 (EDT) From: Michael Richardson To: Marco Tiloca , Malisa Vucinic cc: 6tisch@ietf.org, draft-tiloca-6tisch-robust-scheduling@ietf.org In-Reply-To: <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 14:04:39 -0000 --=-=-= Content-Type: text/plain Marco Tiloca wrote: >> A thought to deal with this is that the new permutation is not used >> until the node switches to the new keys. EXCEPT that the adjacent >> nodes will now not be listening at the right time, won't hear traffic >> encrypted with the new key, and won't change over themselves. >> Authenticated enhanced beacons would perhaps help here. Maybe I'm >> wrong about this problem. > This seems to deserve some more text in the Security > Considerations of Section 6.2, such as the following points. > The new link keys and permutation keys are expected to be distributed > together, just like for the described provisioning through the CoJP > Join Response, possibly through the same procedure described in [1]. yes, that's fine, but you have skipped the communications that will occur *during* the rekey, when some nodes have new keys and some are still using older keys. I was looking for some text from 6tisch-minimal that explains how the rekey actually occurs. Malisa, it seems like this text has been lost. Or did we move this process to another document? The issue Marco is that use of the new key is signaled by receipt of a packet that uses the new key. The sending node will have already switched to a new permuation, while the receiving node will still be on the old schedule. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlymDu0ACgkQgItw+93Q 3WUNyggAuDeRyUbg8sTc4E6kw1rVptWKoyUQlxWtMIgYQg29h8gGyAYEMDhndTV8 4MBMFse6Skwb6621gyUeOV0jZ6g+1l/g6NRgyMCndsjynmDPqmZM8NYIooeVwdAF P6xlEIwlS6sbO7Ho65N0HOexf4dQ8mTKakFhqMGB8xGwsv7v+/UId1KtwHAMjDSo 45AGQkQZS8H36w9tCr/v6JgQ9bvRngKrBnRUtq27se8p1tAMYlVl1HKUgirdGzZ3 NQl0+ofXWi/9H4KOTaFNSrArs8wv09XYqFWnxP2w03n8CBuw4SjfvIl6XhjaXjJk HDmuAnlyGfHQQclRfG9Iwgfi3fLAIA== =G004 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 4 07:52:18 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946F51204AD; Thu, 4 Apr 2019 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ydhxm-u9Oeh; Thu, 4 Apr 2019 07:52:14 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 0825E120368; Thu, 4 Apr 2019 07:52:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,308,1549926000"; d="scan'208,217";a="301826914" Received: from wifi-pro-83-027.paris.inria.fr ([128.93.83.27]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 16:52:10 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_33BF59CF-81B9-4957-B83D-12683C85041B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 16:52:10 +0200 In-Reply-To: <8081.1554386670@localhost> Cc: Marco Tiloca , 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org To: Michael Richardson References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 14:52:17 -0000 --Apple-Mail=_33BF59CF-81B9-4957-B83D-12683C85041B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Should be covered in = https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-= 8.4.2 = Mali=C5=A1a > On 4 Apr 2019, at 16:04, Michael Richardson = wrote: >=20 > I was looking for some text from 6tisch-minimal that explains how the = rekey > actually occurs. >=20 > Malisa, it seems like this text has been lost. > Or did we move this process to another document? --Apple-Mail=_33BF59CF-81B9-4957-B83D-12683C85041B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Should be covered in https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-= 09#section-8.4.2

Mali=C5=A1a

On 4 Apr = 2019, at 16:04, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I was looking for some text from = 6tisch-minimal that explains how the rekey
actually occurs.

Malisa, it seems like this text has been lost.
Or did we move this process to = another document?

= --Apple-Mail=_33BF59CF-81B9-4957-B83D-12683C85041B-- From nobody Thu Apr 4 07:59:53 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9911204AE; Thu, 4 Apr 2019 07:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iTJzuj6O; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=d2QKhp3S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6lZ_eJlDpoy; Thu, 4 Apr 2019 07:59:49 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDC51205D0; Thu, 4 Apr 2019 07:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7074; q=dns/txt; s=iport; t=1554389989; x=1555599589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pxLWOYAll9Ci7o4Wc5uyu1b7AYyAjqKrI1G5fBwMBPA=; b=iTJzuj6OMlt6PV5+N/lvIFLe/DEb/wWOAfwAPNnvY/FDEEeSJVI+LYk4 GvsjMhna4SE+MB/O5wu2EdtG5Mw6T4tYhwy+59uW+sO6182L7wfyQjbor Xlvu9lFElRcg1iPSA4JxatYTME3zmsW8gNfZj1tYyetd/EznwAryShYaB o=; IronPort-PHdr: =?us-ascii?q?9a23=3Abh5O4R0PhecAjq1ssmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAAB3G6Zc/5pdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgT1QA2hUIAQLJwqEBINHA48igleXFYE?= =?us-ascii?q?uFIEQA1QOAQElB4FLgnUCF4U2IjYHDQEBAwEBCQEDAm0cDIVKAQEBAQMjEQw?= =?us-ascii?q?BATcBCwICAgEIEQQBAQECAhEVAgICGRcVCAgCBAENBQiDG4FdAxUBAgyifAK?= =?us-ascii?q?KFHGBL4J5AQEFhQoYggwDBQWBBiUBiGiCLR0XgUA/gRFGgkw+gmEBAQIBgRl?= =?us-ascii?q?HBRAjBYJLMYImijWCWZgDXAkCh36BEIsEggWGFINchFCECoNWh3mGHI1UAgQ?= =?us-ascii?q?CBAUCDgEBBYFWAi+BVnAVgyeCCgsYFIM4hRSBLYQScgELgRyMcAIkBAOBAQG?= =?us-ascii?q?BHgEB?= X-IronPort-AV: E=Sophos;i="5.60,308,1549929600"; d="scan'208";a="254394144" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Apr 2019 14:59:48 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x34Exl6T028733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Apr 2019 14:59:48 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Apr 2019 09:59:46 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Apr 2019 09:59:46 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 4 Apr 2019 09:59:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pxLWOYAll9Ci7o4Wc5uyu1b7AYyAjqKrI1G5fBwMBPA=; b=d2QKhp3SdRDg8PB6MEJnJ3cA8kkRWEZFxWV6bvLpgR+22u4MT15vuby3T6P4bs5dLeDpaS89HCxJNgrvj3lbbFIl9so2Jo+WyrQ6vxrP/GVPIB/R3ba8gEm0+Oflb4DpiH31Qc/hbStm1b8wJlL8XTegbYIFUgrVopph2fuPflw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3678.namprd11.prod.outlook.com (20.178.252.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.20; Thu, 4 Apr 2019 14:59:45 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Thu, 4 Apr 2019 14:59:45 +0000 From: "Pascal Thubert (pthubert)" To: Marco Tiloca , Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org> CC: "draft-tiloca-6tisch-robust-scheduling@ietf.org" Thread-Topic: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key Thread-Index: AQHU6rTJv39yIIxOMkqd9je8yGJvzaYsFBsw Date: Thu, 4 Apr 2019 14:59:40 +0000 Deferred-Delivery: Thu, 4 Apr 2019 14:58:45 +0000 Message-ID: References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> In-Reply-To: <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b851d304-6829-4b6d-16f4-08d6b90e2d25 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3678; x-ms-traffictypediagnostic: MN2PR11MB3678: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(396003)(346002)(136003)(495844002)(199004)(189003)(13464003)(84114002)(81156014)(186003)(6306002)(105586002)(305945005)(76176011)(6246003)(11346002)(486006)(66066001)(14454004)(476003)(446003)(966005)(4326008)(52536014)(102836004)(106356001)(8936002)(53546011)(6506007)(97736004)(25786009)(53936002)(68736007)(26005)(478600001)(5660300002)(9686003)(55016002)(33656002)(86362001)(256004)(71190400001)(71200400001)(229853002)(74316002)(316002)(6436002)(8676002)(81166006)(110136005)(2906002)(14444005)(66574012)(2501003)(99286004)(6666004)(7696005)(3846002)(6116002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3678; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ot3QOW8lQsJEMCM/dsmaRU9KOysYjVjaQhrhT4vaBkewsbKr2QWQskfOmGKTL3hlkNG00GeoolPuj3eyiKZ+yQaHsUJc4VvyeHRzZHZzn+5goa4MihQ+dBapc8jZE/byRV+p15IGmlYxc7Jtcjsm+8Bgb7U954LpL0hfeBXuG3DgOAmAiR9g82zNOe1ekqgO/aHv/X7h0t9oxl7TzHjqtgM9/in8ol8sYrZpnPdotggaVAiqJHhLOxVEQc36L/szc52U5gjScoGwtqEGJAFr94uBufv88OAqFdkG1X+xuI/v5gJLQq/KKpSqcnyL6vNfL3afmOc7ufmEeqzzD7vwf4wLD6id0P5HQ8kASWoxsSzf4LVGio9HCQYK/TPpq9vt1+MHY4zPbwyihbtA11ZgKzvi9Ctc8uMgoaQP8co6bAw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b851d304-6829-4b6d-16f4-08d6b90e2d25 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 14:59:45.4788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3678 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 14:59:52 -0000 SSBjb25jdXIgd2l0aCBNaWNoYWVsLCB0aGlzIGlzIGludGVyZXN0aW5nIHdvcmsuDQoNCk5vdGUg dGhhdCANCjEpIEl0IGlzIHBvc3NpYmxlIHRvIGNvbW11dGUgb25seSBhIHN1YnNldCBvZiB0aGUg Y2hhbm5lbCBvZmZzZXRzIGF0IGEgZ2l2ZW4gdGltZSBvZmZzZXQuIFRoaXMgcmVkdWNlcyB0aGUg bnVtYmVyIG9mIG5vZGVzIHRoYXQgbmVlZCB0byBrbm93IGFib3V0IHRoZSBzd2FwIGFuZCB0aHVz IHRoZSBleHBvc3VyZSB0byBhIGxlYWthZ2UuDQoyKSBzZWN1cml0eSBpcyBub3QgdGhlIG9ubHkg cmVhc29uIHdoeSBzd2FwcGluZyBpcyB1c2VmdWwuIEFzIHlvdSBrbm93LCB1bmRlciBjb25zdGFu dCBjb25kaXRpb25zLCBwYWlycyBvZiBub2RlcyB3aWxsIHN1ZmZlciBmcm9tIG11bHRpcGF0aCBm YWRpbmcgb24gc29tZSBjaGFubmVscyBhbmQgbm90IG9uIG90aGVycy4gT25jZSB0aGlzIGhhcyBi ZWVuIG9ic2VydmVkLCBpdCBpcyBwb3NzaWJsZSB0byBkbyBhIHNlbGVjdGl2ZSBzd2FwIHRvIGF2 b2lkIHRoZSBwYXJ0aWN1bGFyIGNoYW5uZWxzIHRoYXQgYWZmZWN0IGEgcGFydGljdWxhciBwYWly IG9mIG5vZGVzLiANCjMpIEkgaGF2ZSBJUFIgb24gdGhhdCBzb3J0IG9mIHN0dWZmIChVU1BUTyA5 LDY3Myw4NTYpOyBpdCBpcyBub3QgZXhhY3RseSB0aGUgbWV0aG9kIHlvdSBwcm9wb3NlIGJ1dCBj bG9zZSBlbm91Z2guIEp1c3QgaW4gY2FzZSBJJ2xsIGFzayB0byBwdWJsaXNoIHRlcm1zLg0KDQpB bGwgdGhlIGJlc3QsDQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IDZ0aXNjaCA8NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNYXJj byBUaWxvY2ENCj4gU2VudDogamV1ZGkgNCBhdnJpbCAyMDE5IDA5OjA1DQo+IFRvOiBNaWNoYWVs IFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IDZ0aXNjaEBpZXRmLm9yZw0KPiBD YzogZHJhZnQtdGlsb2NhLTZ0aXNjaC1yb2J1c3Qtc2NoZWR1bGluZ0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogWzZ0aXNjaF0gZHJhZnQtdGlsb2NhLTZ0aXNjaC1yb2J1c3Qtc2NoZWR1bGluZy0w MSAtLS0gcmVrZXlpbmcNCj4gcGVybXV0YXRpb24ga2V5DQo+IA0KPiBIaSBNaWNoYWVsLA0KPiAN Cj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXchDQo+IA0KPiBXZSdsbCBkZWZp bml0ZWx5IHRha2UgaW50byBhY2NvdW50IHlvdXIgY29tbWVudHMgZm9yIHRoZSBuZXh0IHZlcnNp b24uDQo+IA0KPiBQbGVhc2UsIGZpbmQgYWxzbyBzb21lIGFuc3dlcnMgaW5saW5lLg0KPiANCj4g QmVzdCwNCj4gL01hcmNvDQo+IA0KPiBPbiA0LzMvMTkgMzowNiBBTSwgTWljaGFlbCBSaWNoYXJk c29uIHdyb3RlOg0KPiA+IEkgcmVhZCBkcmFmdC10aWxvY2EtNnRpc2NoLXJvYnVzdC1zY2hlZHVs aW5nLTAxLg0KPiA+DQo+ID4gSSBmb3VuZCB0aGlzIHRvIGJlIGFuIGludGVyZXN0aW5nIHdheSB0 byBib3RoIGFubm91bmNlIHRoZSBzY2hlZHVsZSwNCj4gPiBhbmQgeWV0LCBoaWRlIGl0LiAgVmVy eSB3ZWxsIGRvbmUuDQo+IA0KPiA8TVQ+DQo+IFRoYW5rcyENCj4gPC9NVD4NCj4gDQo+ID4NCj4g PiBJIGhhdmUgc29tZSBpbml0aWFsIGNvbW1lbnQgYWJvdXQgdGhlIHNlY3Rpb24gMy4xIGFib3V0 IHRoZSBhZHZlcnNhcnkuDQo+ID4gSSB3b25kZXJlZCBhYm91dCB3aHkgc29tZW9uZSB3b3VsZCBk byB0aGlzLiAgV2hhdCdzIHRoZSBiZW5lZml0Lg0KPiA+DQo+ID4gSXQgb2NjdXJlZCB0byBtZSB0 aGF0IGFuIGltcG9ydGFudCBwb2ludCBhYm91dCB0aGUgc2VsZWN0aXZlIGphbW1pbmcNCj4gPiBp cyB0aGF0IGFuIGF0dGFja2VyIGNhbiBtZXNzIHdpdGggYSBjb21wZXRpdG9ycyBuZXR3b3JrIHdo aWxlIHN0aWxsDQo+ID4gcGVybWl0dGluZyB0aGVpciBvd24gbmV0d29yayB0byBvcGVyYXRlISAg VGhhdCBtaWdodCBiZSB3b3J0aCBhZGRpbmcuDQo+IA0KPiA8TVQ+DQo+IEl0J3MgYSB2ZXJ5IGdv b2QgcG9pbnQhIFdlJ2xsIGFkZCB0aGlzIGFzIGFuIGF0dGFjayBtb3RpdmF0aW9uIGluIFNlY3Rp b24gMy4xLg0KPiA8L01UPg0KPiANCj4gPiBUaGUgZG9jdW1lbnQgc2VlbXMgd2VsbCB3cml0dGVu LCBhbHRob3VnaCBJJ2QgbGlrZSB0byBoYXZlIHNvbWUNCj4gPiBleGFtcGxlIGtleXMgYW5kIHNo b3cgaG93IHRoZXkgcGVybXV0ZSB0aGluZ3MgaW4gcHJhY3RpY2Ugc28gdGhhdA0KPiA+IGltcGxl bWVudG9ycyBjYW4gdmFsaWRhdGUgdGhlaXIgd29yay4NCj4gDQo+IDxNVD4NCj4gUmlnaHQsIHdl IHdpbGwgcHJvZHVjZSBhbiBleGFtcGxlLCBwb3NzaWJseSBhcyBhbiBBcHBlbmRpeCByZWZlcnJl ZCBhdCB0aGUgZW5kDQo+IG9mIFNlY3Rpb24gNC4NCj4gPC9NVD4NCj4gDQo+IA0KPiA+IFRoZSBh ZGRpdGlvbnMgdG8gQ29KUCBzZWVtcyB3ZWxsIGRvbmUsIEknbSBzbyBnbGFkIHdlIGNoYW5nZWQg dGhhdCB0bw0KPiA+IGEgaGFzaCBGcm9tIGFuIGFycmF5IDotKQ0KPiA+DQo+ID4gSWYgdGhlIHBl cm11dGF0aW9uIGlzIHJlcGxhY2VkIHdoZW5ldmVyIHRoZSBuZXR3b3JrIGtleSBpcyBjaGFuZ2Vk LA0KPiA+IHdoaWNoIG1lYW5zIHRoYXQgdGhlIHBlcm11dGF0aW9uIGlzIGdvaW5nIHRvIGNoYW5n ZSEgIFRoaXMgbWVhbnMgdGhhdA0KPiA+IHNvbWUgbm9kZXMgY291bGQgYmUgb24gdGhlIG5ldyBw ZXJtdXRhdGlvbiB3aGlsZSBvdGhlcnMgYXJlIG9uIHRoZSBvbGQuDQo+ID4NCj4gPiBBIHRob3Vn aHQgdG8gZGVhbCB3aXRoIHRoaXMgaXMgdGhhdCB0aGUgbmV3IHBlcm11dGF0aW9uIGlzIG5vdCB1 c2VkDQo+ID4gdW50aWwgdGhlIG5vZGUgc3dpdGNoZXMgdG8gdGhlIG5ldyBrZXlzLiAgRVhDRVBU IHRoYXQgdGhlIGFkamFjZW50DQo+ID4gbm9kZXMgd2lsbCBub3cgbm90IGJlIGxpc3RlbmluZyBh dCB0aGUgcmlnaHQgdGltZSwgd29uJ3QgaGVhciB0cmFmZmljIGVuY3J5cHRlZA0KPiB3aXRoIHRo ZSBuZXcNCj4gPiBrZXksIGFuZCB3b24ndCBjaGFuZ2Ugb3ZlciB0aGVtc2VsdmVzLiAgIEF1dGhl bnRpY2F0ZWQgZW5oYW5jZWQgYmVhY29ucw0KPiB3b3VsZA0KPiA+IHBlcmhhcHMgaGVscCBoZXJl LiAgTWF5YmUgSSdtIHdyb25nIGFib3V0IHRoaXMgcHJvYmxlbS4NCj4gDQo+IDxNVD4NCj4gVGhp cyBzZWVtcyB0byBkZXNlcnZlIHNvbWUgbW9yZSB0ZXh0IGluIHRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBvZg0KPiBTZWN0aW9uIDYuMiwgc3VjaCBhcyB0aGUgZm9sbG93aW5nIHBvaW50cy4N Cj4gDQo+IFRoZSBuZXcgbGluayBrZXlzIGFuZCBwZXJtdXRhdGlvbiBrZXlzIGFyZSBleHBlY3Rl ZCB0byBiZSBkaXN0cmlidXRlZA0KPiB0b2dldGhlciwganVzdCBsaWtlIGZvciB0aGUgZGVzY3Jp YmVkIHByb3Zpc2lvbmluZyB0aHJvdWdoIHRoZSBDb0pQIEpvaW4NCj4gUmVzcG9uc2UsIHBvc3Np Ymx5IHRocm91Z2ggdGhlIHNhbWUgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiBbMV0uDQo+IA0KPiBB ZnRlciBhIHJla2V5aW5nIHByb2Nlc3MgaXMgY29tcGxldGVkLCBhIG5vZGUgc2hvdWxkIGluZGVl ZCBzdGFydCB1c2luZyB0aGUNCj4gbmV3IHBlcm11dGF0aW9uIGtleXMgb25jZSBzd2l0Y2hlZCB0 byB0aGUgbmV3IGxpbmsga2V5cyBvbmx5LCBpLmUuDQo+IGFmdGVyIGl0IGhhcyBkaXNjYXJkZWQg dGhlIG9sZCBrZXkgbWF0ZXJpYWwgYXMgcGVyIHRoZSBoYW5kbGluZyBvZiB0aGUgImxpbmstbGF5 ZXINCj4ga2V5IHNldCIgaW4gWzJdLg0KPiANCj4gSWYgYSBub2RlIEEgZGlzY2FyZHMgdGhlIG9s ZCBrZXkgbWF0ZXJpYWwgKGNvbnNpZGVyYWJseSkgYmVmb3JlIGEgbm9kZSBCLCB0aGV5DQo+IHdp bGwgYmUgdGVtcG9yYXJpbHkgdW5hbGlnbmVkLiBUaGF0IGlzLCBub2RlIEIgd291bGQgdGVtcG9y YXJpbHkgc2VjdXJlDQo+IG91dGdvaW5nIG1lc3NhZ2VzIHN0aWxsIHVzaW5nIHRoZSBvbGQga2V5 IG1hdGVyaWFsIFsyXSB0aGF0IEEgZG9lcyBub3Qgb3duDQo+IGFueW1vcmUsIGFuZCB3b3VsZCBz dGlsbCBwZXJtdXRlIGl0cyBzY2hlZHVsZSB0aGUgb2xkIHdheS4NCj4gDQo+IEV2ZW50dWFsbHks IEIgd2lsbCBhbHNvIGRpc2NhcmQgdGhlIG9sZCBrZXkgbWF0ZXJpYWwsIGUuZy4gYWZ0ZXIgcmVj ZWl2aW5nIGFuZA0KPiBzdWNjZXNzZnVsbHkgc2VjdXJpdHkgcHJvY2Vzc2luZyBhbiBpbmNvbWlu ZyBtZXNzYWdlIHNlY3VyZWQgd2l0aCB0aGUgbmV3DQo+IGtleSBtYXRlcmlhbCBbMl0sIG9mIGNv dXJzZSB0aG91Z2ggd2hpbGUgc3RpbGwgb3ZlciBpdHMgb2xkLWZhc2hpb24tcGVybXV0ZWQNCj4g c2NoZWR1bGUuIEhlcmUgZW5oYW5jZWQgYmVhY29ucyBhdXRoZW50aWNhdGVkIHdpdGggdGhlIG5l dyBrZXkgbWF0ZXJpYWwNCj4gc2VlbSB0byBoZWxwLiBBbHNvLCBhIGxvY2FsIHVwcGVyIGJvdW5k IGNhbiBiZSBlbmZvcmNlZCB0aHJvdWdoIGEgcGFyYW1ldGVyDQo+IHNpbWlsYXIgdG8gQ09KUF9S RUtFWUlOR19HVUFSRF9USU1FIFsyXS4NCj4gVGhlbiwgdGhlIHR3byBub2RlcyB3aWxsIGJlIGFs aWduZWQgYWdhaW4gb24gYm90aCBwcm9jZXNzaW5nIHNlY3VyZSBtZXNzYWdlcw0KPiBhbmQgcGVy bXV0aW5nIHRoZWlyIHNjaGVkdWxlLg0KPiANCj4gDQo+IFdoYXQgZG8geW91IHRoaW5rPw0KPiAN Cj4gDQo+IFsxXQ0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02dGlz Y2gtbWluaW1hbC1zZWN1cml0eS0wOSNzZWN0aW9uLTguMg0KPiBbMl0NCj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJpdHktMDkjc2Vj dGlvbi04LjQNCj4gDQo+IDwvTVQ+DQo+IA0KPiA+IC0tDQo+ID4gTWljaGFlbCBSaWNoYXJkc29u IDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gPiAt PSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+IA0KPiAtLQ0KPiBNYXJjbyBUaWxvY2ENCj4gUGgu RC4sIFNlbmlvciBSZXNlYXJjaGVyDQo+IA0KPiBSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2Yg U3dlZGVuDQo+IERpdmlzaW9uIElDVA0KPiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8Olbmdl biAxNg0KPiBTRS0xNjQgNDAgS2lzdGEgKFN3ZWRlbikNCj4gDQo+IFBob25lOiArNDYgKDApNzAg NjAgNDYgNTAxDQo+IGh0dHBzOi8vd3d3LnJpLnNlDQo+IA0KDQo= From nobody Thu Apr 4 08:41:05 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286CE1200DE; Thu, 4 Apr 2019 08:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33kqyB0r3mvQ; Thu, 4 Apr 2019 08:41:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D591205DF; Thu, 4 Apr 2019 08:40:55 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id DB93D38277; Thu, 4 Apr 2019 11:40:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 86764DF2; Thu, 4 Apr 2019 11:40:53 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 83F9ECCC; Thu, 4 Apr 2019 11:40:53 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FB=3FTWFsacWhYSBWdcSNaW5pxIc=3D=3F=3D?= cc: Marco Tiloca , 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org In-Reply-To: References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:41:04 -0000 Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > Should be covered in > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#sec= tion-8.4.2 right! It was hard to find this burried in that point. Can you see how the old/new key issue interacts poorly with the permuted schedule? -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Thu Apr 4 09:47:02 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512D812010D for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 09:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Y2hp8ws2Riyg for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 09:46:57 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 7BB441200C7 for <6tisch@ietf.org>; Thu, 4 Apr 2019 09:46:57 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id i19so1660350pfd.0 for <6tisch@ietf.org>; Thu, 04 Apr 2019 09:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sEhdhepvxL/jRXdGxkPf56ZGpTcW5RFbuSvrnfMqcp0=; b=itXv8E5BKkcxW9ls9LrfRaNo3yH4owqHgZtkIL8HM31IKKw08/q/ELho9tqOGSCc9j qkbJ9Z5SRd5Oi6q30WxfLjp1oJqteC4vDHAkJK+6mbXxTkP6meR0YDTa3i1Z7jYbSXoy VquLBEsUjGhw7ydFl2uq0At+oMaskIPsdDai4AyuqZM8vpzc6pbE4WJ9gIB3ZkQemTbY 9944ux3W8urCYp4a2JpvgTI1qvcuaaM4I/MqXFUHaQ5ri7/3ATRuco/usCKC3jgrni0i Miwe9yS9YJ9JEfTNnemgB3Rb9McTvE6sPVq3WCDcLAOPm04gvn06jiC/OjWPaRaMnLL3 bCsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sEhdhepvxL/jRXdGxkPf56ZGpTcW5RFbuSvrnfMqcp0=; b=SE1pPCthaWPWn2tXKFwuIf7Oq2jr+Dym0KwqC4R8WCJzy4Iasn0IiwZqBOKk+f1qND 2NBF3MDXsCS8HLLpKnzG3AKYF2eDaV40YzjwRBIfGdv/uBMmkpJk9DEszJmZuhUVYLd4 L5NWTjKom8EemmfzSWxxRW7lFnX/rpz3YGmlcCXNautVEhk68eTXi2LOGwS38JrUlpcz 4QWQPOltggAsUjMMk/Ln6yUhM6HPo49kD5oA7uw3niyiT1Rsp6nRFq8ZxZQCegH/p/Ex feT0eOdkv7xG6ncpJYMA5e4TXXNbWP4knvRzgNKiR6VJJ/rOn0C39pJ+2IkJuU61uRyk UwZQ== X-Gm-Message-State: APjAAAVmua1Rtfj4bHPf/2a+qkA/eDgvdWIIi/Ca102i75uW4pwNWA5A uqKCaCy7t8hzVMcYYohGcNYQjsyv3an17AL5D4DMHhPT X-Google-Smtp-Source: APXvYqzeeGEL1fHsaJKQAN+j6W3y5sx+bRqiGfKiPeEUEyXXWMzWnuOu+jf6NIGvok8buAgdMaY9RE0OSI+GpohtCgY= X-Received: by 2002:a63:460a:: with SMTP id t10mr6649839pga.354.1554396415758; Thu, 04 Apr 2019 09:46:55 -0700 (PDT) MIME-Version: 1.0 From: Tengfei Chang Date: Thu, 4 Apr 2019 18:46:43 +0200 Message-ID: To: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="0000000000003396060585b71e22" Archived-At: Subject: [6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:47:01 -0000 --0000000000003396060585b71e22 Content-Type: text/plain; charset="UTF-8" Hello Authors, I just reviewed the draft. It reads pretty good for me! I only found a tiny typo error in Eq.1 where the 'c' is not defined actually, I believe you mean 'chOff'. Besides, I have two questions referring the usage of minimal cell. 1. What if the selective jamming applied on the minimal cell? Do you consider to resolve this case? 2. The joining traffic is going on minimal cell in slotframe 0. Do you plan to use some strategy to regulate the traffic on minimal cell? I am asking this because this is different from what MSF is doing, which send joining packet over autonomous cell. Tengfei -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria --0000000000003396060585b71e22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Authors,

I just reviewed the draf= t. It reads pretty good for me! I only found a tiny typo error in Eq.1 wher= e the 'c' is not defined actually, I believe you mean 'chOff= 9;.

Besides, I have two questions referring the us= age of minimal cell.

1. What if the selective jamm= ing applied on the minimal cell? Do you consider to resolve this case?

2. The joining traffic is going on=C2=A0 minimal cell = in slotframe 0. Do you plan to use some strategy to regulate the traffic on= minimal cell? I am asking this because this is different from what MSF is = doing, which send joining packet over autonomous cell.

=
Tengfei

--
Chang Tengfei,
Pre-Postdoctoral Rese= arch Engineer, Inria
--0000000000003396060585b71e22-- From nobody Thu Apr 4 10:33:08 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940F91201DE; Thu, 4 Apr 2019 10:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZOr_J_B_6Pu; Thu, 4 Apr 2019 10:33:04 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 A94B21201CF; Thu, 4 Apr 2019 10:33:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="scan'208,217";a="377247363" Received: from wifi-pro-83-027.paris.inria.fr ([128.93.83.27]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 19:33:01 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_2FD4BAB6-F8FB-43E4-99C5-662B8C40A066" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 19:33:01 +0200 In-Reply-To: <10538.1554392453@localhost> Cc: Marco Tiloca , 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org To: Michael Richardson References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 17:33:07 -0000 --Apple-Mail=_2FD4BAB6-F8FB-43E4-99C5-662B8C40A066 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My understanding is that the problem in the permuted schedule arises = during COJP_REKEYING_GUARD_TIME after nodes in the network started using = the new keys, but have still kept the old key in case someone has not = yet switched. When coupled with a rekeyed permutation key to calculate = the schedule, this means that during COJP_REKEYING_GUARD_TIME a node = would need to follow two schedules, one with the old permutation key and = one with the new one. The problem in following two schedules for = COJP_REKEYING_GUARD_TIME is that = draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset = and the channelOffset be permuted so that it may occur that there can be = a collision in slotOffset between the new and the old schedule. The problem that draft-tiloca-6tisch-robust-scheduling solves seems to = be the predictability of the channel on which a transmission is going to = take place. With that in mind, I have second thoughts about the = recommendation on permuting the slotOffset, especially taking into = account that this will break any scheduling function that optimizes for = latency, as discussed in Section 6.3. Mali=C5=A1a > On 4 Apr 2019, at 17:40, Michael Richardson wrote: >=20 > Can you see how the old/new key issue interacts poorly with the = permuted > schedule? --Apple-Mail=_2FD4BAB6-F8FB-43E4-99C5-662B8C40A066 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = understanding is that the problem in the permuted schedule arises during = COJP_REKEYING_GUARD_TIME after nodes in the network started using the = new keys, but have still kept the old key in case someone has not yet = switched. When coupled with a rekeyed permutation key to calculate the = schedule, this means that during COJP_REKEYING_GUARD_TIME a node would = need to follow two schedules, one with the old permutation key and one = with the new one. The problem in following two schedules for = COJP_REKEYING_GUARD_TIME is that = draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset = and the channelOffset be permuted so that it may occur that there can be = a collision in slotOffset between the new and the old schedule.

The problem that = draft-tiloca-6tisch-robust-scheduling solves seems to be the = predictability of the channel on which a transmission is going to take = place. With that in mind, I have second thoughts about the = recommendation on permuting the slotOffset, especially taking into = account that this will break any scheduling function that optimizes for = latency, as discussed in Section 6.3.

Mali=C5=A1a


On 4 Apr 2019, at 17:40, Michael Richardson <mcr@sandelman.ca> = wrote:

Can you see how the old/new key = issue interacts poorly with the permuted
schedule?

= --Apple-Mail=_2FD4BAB6-F8FB-43E4-99C5-662B8C40A066-- From nobody Thu Apr 4 11:57:37 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC91200F7 for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 11:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nUeNVUTYGuR for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 11:57:33 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 79B571200FD for <6tisch@ietf.org>; Thu, 4 Apr 2019 11:57:33 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id k17so5084226wrx.10 for <6tisch@ietf.org>; Thu, 04 Apr 2019 11:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=km2lRwQDY31FMP0M3cPsgc7Vf9haXWrOFt4cnz25sAw=; b=I3nW7Hs16HrmXkJNPoBlpQdoFFOLoEiZRq+wTCRUiV+O9qwHnnq2spCBqRj/E6UMQo h+imueWAcdaWLwN52VTtlHsHDkiOFOnbUTKLFW0ZDIOwyJDGsUvEriKuCRBa0y42Pqpt GxNc+sbSCk/mZZzTLZzaagPYZNBfJaeUgsU8D4n6tdyU4gHLkQ1QY7PsdfkPvYgnoBL+ aG4taJhpYxCMi4AKkN2oKUdy+fPOLc7KPvgRIZ4dxzBn3Gz3pKQ0y8PH1HZ016VGzS7R zzLdSYGapMtc0Dom+OJCKQGLQ8OnftoS/7cod4i8A5lVxVIADmTI5bmJDR0PWPE89Lot JPFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=km2lRwQDY31FMP0M3cPsgc7Vf9haXWrOFt4cnz25sAw=; b=sNtibjDrSRTroGz7Bs/KIAFFri3LVFhNguWfxRDVrm50O07UHtRQg0IaJkW8e/ZBDd 7QyXOX4S0pRIem3FEoyoDk+cTKEuWU10t6O6hqy7mZZxodGBKQEeWnPbbyA9+TYLPSCR C+Bd4vgKuUgVVZU2wkCclHLyFAD7b3mfoVjAi88jXQ6CWqByw65IYhXnqUh45UmEqwWu F1HbPTbcsRJU9nXdQbSSLlN3FL1yldOkPLKvZbtMuIn+56UmnqqnOD+jUDLlc1zdx7hu NgTJt1OUCoFUD7pNCgzSnRr9OqTGyYYCirMQIsuljgnBmhH2nfk688WTm7bqS2XpHWS8 lT/g== X-Gm-Message-State: APjAAAXNaJ0gqKlWnvW5mtKeqW3SbSUg92hg0xY+cLPA4nHM8rGqkWfA estXPr19wNiNeFDGraHApgTfZJLHEUon+1GujYk= X-Google-Smtp-Source: APXvYqySzI+APqtD0RByyYZWHukn4P6Wyh/O+i5iLd+IIFtuCbU6gTrxVMVPmGO/zm1UdX775g72kGs458hbTRyvZb4= X-Received: by 2002:a5d:4a8d:: with SMTP id o13mr5143528wrq.209.1554404251962; Thu, 04 Apr 2019 11:57:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon Duquennoy Date: Thu, 4 Apr 2019 20:57:21 +0200 Message-ID: To: Tengfei Chang Cc: 6tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="0000000000004696bd0585b8f1ca" Archived-At: Subject: Re: [6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 18:57:36 -0000 --0000000000004696bd0585b8f1ca Content-Type: text/plain; charset="UTF-8" Hi Tengfei, Thanks for these questions. 1. We're not protecting against selective jamming on the minimal cell indeed. This is a tricky problem, because beacons must include enough information for nodes to find out when to tx/rx for the join procedure, and a not-joined-yet node can do it then so can an attacker. Our threat model is where the attacker is interested in degrading the performance for a given [set of] node[s] in a running network. 2. This is a great point. We currently know of two approaches, both of which involve a slight modification of MSF. (a) make MSF use the minimal cell instead of autonomous for joining or (b) move autonomous cells to a different slotframe than dedicated cells (e.g. to autonomous to slotframe 0, or dedicated to a new slotframe 2). Best, Simon On Thu, Apr 4, 2019 at 6:47 PM Tengfei Chang wrote: > Hello Authors, > > I just reviewed the draft. It reads pretty good for me! I only found a > tiny typo error in Eq.1 where the 'c' is not defined actually, I believe > you mean 'chOff'. > > Besides, I have two questions referring the usage of minimal cell. > > 1. What if the selective jamming applied on the minimal cell? Do you > consider to resolve this case? > > 2. The joining traffic is going on minimal cell in slotframe 0. Do you > plan to use some strategy to regulate the traffic on minimal cell? I am > asking this because this is different from what MSF is doing, which send > joining packet over autonomous cell. > > Tengfei > > -- > Chang Tengfei, > Pre-Postdoctoral Research Engineer, Inria > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --0000000000004696bd0585b8f1ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tengfei,

Thanks for these questions.=

1. We're not protecting against selective jam= ming on the minimal cell indeed. This is a tricky problem, because beacons = must include enough information for nodes to find out when to tx/rx for the= join procedure, and a not-joined-yet node can do it then so can an attacke= r. Our threat model is where the attacker is interested in degrading the pe= rformance for a given [set of] node[s] in a running network.

=
2. This is a great point. We currently know of two approaches, b= oth of which involve a slight modification of MSF. (a) make MSF use the min= imal cell instead of autonomous for joining or (b) move autonomous cells to= a different slotframe than dedicated cells (e.g. to autonomous to slotfram= e 0, or dedicated to a new slotframe 2).

Best,
Simon

On Thu, Apr 4, 2019 at 6:47 PM Tengfei Chang <tengfei.chang@gmail.com> wrote:<= br>
Hello Authors,

I just reviewed the draft. It reads pret= ty good for me! I only found a tiny typo error in Eq.1 where the 'c'= ; is not defined actually, I believe you mean 'chOff'.
Besides, I have two questions referring the usage of minimal c= ell.

1. What if the selective jamming applied on t= he minimal cell? Do you consider to resolve this case?

=
2. The joining traffic is going on=C2=A0 minimal cell in slotframe 0. = Do you plan to use some strategy to regulate the traffic on minimal cell? I= am asking this because this is different from what MSF is doing, which sen= d joining packet over autonomous cell.

Tengfei

--
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inr= ia
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
--0000000000004696bd0585b8f1ca-- From nobody Thu Apr 4 14:39:03 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82511201A1; Thu, 4 Apr 2019 14:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5SZNeP-er6P; Thu, 4 Apr 2019 14:38:58 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 1E53912011A; Thu, 4 Apr 2019 14:38:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="scan'208,217";a="301858514" Received: from lfbn-1-4128-78.w92-169.abo.wanadoo.fr (HELO mp341-pro.home) ([92.169.126.78]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 23:38:55 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_3FF05691-B3C5-4810-9CB0-F4DCACCB0A0E" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 23:38:54 +0200 In-Reply-To: <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> Cc: 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org, Marco Tiloca To: Michael Richardson References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 21:39:02 -0000 --Apple-Mail=_3FF05691-B3C5-4810-9CB0-F4DCACCB0A0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It seems i have permuted slotOffset and channelOffset below :-) This may = be a piste if slotOffset permutation is kept but there would likely be = problems for nodes with higher bandwidth requirements and many cells in = the schedule to guarantee zero slotOffset collisions in one own=E2=80=99s = schedule across slotframe iterations. Don=E2=80=99t really like it = though for the reason of breaking the scheduling function. As a reminder, in minimal-security we resorted to the current rekeying = mechanism and not the one using the exact timestamp in the future when = the whole network switches to new keys in order to avoid having to know = the network notion of time at the JRC. Mali=C5=A1a > On 4 Apr 2019, at 19:33, Mali=C5=A1a Vu=C4=8Dini=C4=87 = wrote: >=20 > My understanding is that the problem in the permuted schedule arises = during COJP_REKEYING_GUARD_TIME after nodes in the network started using = the new keys, but have still kept the old key in case someone has not = yet switched. When coupled with a rekeyed permutation key to calculate = the schedule, this means that during COJP_REKEYING_GUARD_TIME a node = would need to follow two schedules, one with the old permutation key and = one with the new one. The problem in following two schedules for = COJP_REKEYING_GUARD_TIME is that = draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset = and the channelOffset be permuted so that it may occur that there can be = a collision in slotOffset between the new and the old schedule. >=20 > The problem that draft-tiloca-6tisch-robust-scheduling solves seems to = be the predictability of the channel on which a transmission is going to = take place. With that in mind, I have second thoughts about the = recommendation on permuting the slotOffset, especially taking into = account that this will break any scheduling function that optimizes for = latency, as discussed in Section 6.3. >=20 > Mali=C5=A1a >=20 >=20 >> On 4 Apr 2019, at 17:40, Michael Richardson > wrote: >>=20 >> Can you see how the old/new key issue interacts poorly with the = permuted >> schedule? >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --Apple-Mail=_3FF05691-B3C5-4810-9CB0-F4DCACCB0A0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = seems i have permuted slotOffset and channelOffset below :-) This may be = a piste if slotOffset permutation is kept but there would likely be = problems for nodes with higher bandwidth requirements and many cells in = the schedule to guarantee zero slotOffset collisions in one own=E2=80=99s = schedule across slotframe iterations. Don=E2=80=99t really like it = though for the reason of breaking the scheduling function.

As a reminder, in = minimal-security we resorted to the current rekeying mechanism and not = the one using the exact timestamp in the future when the whole network = switches to new keys in order to avoid having to know the network notion = of time at the JRC.

Mali=C5=A1a

On 4 Apr 2019, at 19:33, = Mali=C5=A1a Vu=C4=8Dini=C4=87 <malisa.vucinic@inria.fr> wrote:

My understanding is = that the problem in the permuted schedule arises during = COJP_REKEYING_GUARD_TIME after nodes in the network started using the = new keys, but have still kept the old key in case someone has not yet = switched. When coupled with a rekeyed permutation key to calculate the = schedule, this means that during COJP_REKEYING_GUARD_TIME a node would = need to follow two schedules, one with the old permutation key and one = with the new one. The problem in following two schedules for = COJP_REKEYING_GUARD_TIME is that = draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset = and the channelOffset be permuted so that it may occur that there can be = a collision in slotOffset between the new and the old schedule.

The problem that = draft-tiloca-6tisch-robust-scheduling solves seems to be the = predictability of the channel on which a transmission is going to take = place. With that in mind, I have second thoughts about the = recommendation on permuting the slotOffset, especially taking into = account that this will break any scheduling function that optimizes for = latency, as discussed in Section 6.3.

Mali=C5=A1a


On 4 Apr 2019, at 17:40, Michael Richardson = <mcr@sandelman.ca> wrote:

Can you see how the old/new key = issue interacts poorly with the permuted
schedule?

___________________________= ____________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

= --Apple-Mail=_3FF05691-B3C5-4810-9CB0-F4DCACCB0A0E-- From nobody Fri Apr 5 01:17:33 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F812038D; Fri, 5 Apr 2019 01:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.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 1yJAtxtNGVU7; Fri, 5 Apr 2019 01:17:28 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70084.outbound.protection.outlook.com [40.107.7.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66112120390; Fri, 5 Apr 2019 01:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EfnOeUECnjMHX66gHM/Q40HbaJf0wUmkKtTBoqqNoP0=; b=RfzpgbA37P1OmW59bc/WB0MC90jH4AcXt0BT/N49iS7pti+42KM3f02isC+7SLL8hfCqYHF+KsYiOS291akvWB1muRNQEgpj7QEv4b3J5OXqlIpJc//R2CKKDx9x7DCw/R5yijXCB/enkdGbTwLekntPRxVF0+Re5NCHFlNADzY= Received: from DB6P18901CA0012.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::22) by VI1P189MB0334.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Fri, 5 Apr 2019 08:17:24 +0000 Received: from AM5EUR02FT058.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::201) by DB6P18901CA0012.outlook.office365.com (2603:10a6:4:16::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16 via Frontend Transport; Fri, 5 Apr 2019 08:17:24 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT058.mail.protection.outlook.com (10.152.9.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1750.20 via Frontend Transport; Fri, 5 Apr 2019 08:17:23 +0000 Received: from [10.112.10.131] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 5 Apr 2019 10:17:23 +0200 To: "Pascal Thubert (pthubert)" , Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org> CC: "draft-tiloca-6tisch-robust-scheduling@ietf.org" References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Fri, 5 Apr 2019 10:17:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FGdYRubHA4AOEwxmTDCql0Rcz8FHVpfXa" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(136003)(376002)(2980300002)(495844002)(189003)(199004)(13464003)(84114002)(5660300002)(36756003)(68736007)(81166006)(8676002)(81156014)(106466001)(235185007)(966005)(40036005)(104016004)(22756006)(4326008)(21480400003)(53936002)(106002)(316002)(7736002)(16586007)(305945005)(58126008)(110136005)(97736004)(65826007)(84326002)(229853002)(6306002)(6246003)(66574012)(8936002)(69596002)(568964002)(74482002)(44832011)(6116002)(3846002)(14444005)(5024004)(486006)(126002)(86362001)(16576012)(65956001)(11346002)(446003)(65806001)(476003)(336012)(31686004)(2616005)(2906002)(2501003)(64126003)(45080400002)(71190400001)(386003)(53546011)(478600001)(31696002)(76176011)(6666004)(33964004)(356004)(26005)(16526019)(186003)(77096007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0334; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ea58ed88-a22b-42f1-8c1a-08d6b99f21d0 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4709054)(2017052603328)(7193020); SRVR:VI1P189MB0334; X-MS-TrafficTypeDiagnostic: VI1P189MB0334: X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0998671D02 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: HB8OQRy1dPXIlv6Ncu+0tTVUaJjIgraapnrgvuKe3XKSUf2o+4cdyy4oJCdOUc5g0Y1Q93nYulCXMTC7rCMnGaH9e9pXBRxkE5a0upEiL1RHIa667FlW/bKlTSJEyz8bZ2yorod3zAejPMnTYyxcX0GQJbKaqyuTzVSw6ue4SnXn2nTSC5gd9UQjdR83HaKW/3ufJgaSYsYFYS02CpFPVAYcXT1s338pJgjyCfoakeroi370xQ2GAN3pXUbIe2O8WhDQhk4D6wdaGocc3nd9rNItK0g/b/ZA58P60b0DTG9MB63nb0dibzqrOoL36WDsBoClNGa7Dti9e6pVyWmW4cnm7hEUfDM7MkjjBK+0d/1ArKJOTDFItlZ+OAu+z1fYE7V6Y0qO/yRTeEkr2ZdIf0LF3aM8iBQ0CNxiu001U7Y= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2019 08:17:23.6527 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea58ed88-a22b-42f1-8c1a-08d6b99f21d0 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0334 Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 08:17:32 -0000 --FGdYRubHA4AOEwxmTDCql0Rcz8FHVpfXa Content-Type: multipart/mixed; boundary="d6qXB4BTrcyRTK2J7kM9UJ6tSxsl4CyHC"; protected-headers="v1" From: Marco Tiloca To: "Pascal Thubert (pthubert)" , Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org> Cc: "draft-tiloca-6tisch-robust-scheduling@ietf.org" Message-ID: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> In-Reply-To: --d6qXB4BTrcyRTK2J7kM9UJ6tSxsl4CyHC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello Pascal, Thanks a lot for your review, feedback and pointers to further applicability of this approach. Best, /Marco On 4/4/19 4:59 PM, Pascal Thubert (pthubert) wrote: > I concur with Michael, this is interesting work. > > Note that=20 > 1) It is possible to commute only a subset of the channel offsets at a = given time offset. This reduces the number of nodes that need to know abo= ut the swap and thus the exposure to a leakage. > 2) security is not the only reason why swapping is useful. As you know,= under constant conditions, pairs of nodes will suffer from multipath fad= ing on some channels and not on others. Once this has been observed, it i= s possible to do a selective swap to avoid the particular channels that a= ffect a particular pair of nodes.=20 > 3) I have IPR on that sort of stuff (USPTO 9,673,856); it is not exactl= y the method you propose but close enough. Just in case I'll ask to publi= sh terms. > > All the best, > > Pascal > >> -----Original Message----- >> From: 6tisch <6tisch-bounces@ietf.org> On Behalf Of Marco Tiloca >> Sent: jeudi 4 avril 2019 09:05 >> To: Michael Richardson ; 6tisch@ietf.org >> Cc: draft-tiloca-6tisch-robust-scheduling@ietf.org >> Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rek= eying >> permutation key >> >> Hi Michael, >> >> Thank you very much for your review! >> >> We'll definitely take into account your comments for the next version.= >> >> Please, find also some answers inline. >> >> Best, >> /Marco >> >> On 4/3/19 3:06 AM, Michael Richardson wrote: >>> I read draft-tiloca-6tisch-robust-scheduling-01. >>> >>> I found this to be an interesting way to both announce the schedule, >>> and yet, hide it. Very well done. >> >> Thanks! >> >> >>> I have some initial comment about the section 3.1 about the adversary= =2E >>> I wondered about why someone would do this. What's the benefit. >>> >>> It occured to me that an important point about the selective jamming >>> is that an attacker can mess with a competitors network while still >>> permitting their own network to operate! That might be worth adding.= >> >> It's a very good point! We'll add this as an attack motivation in Sect= ion 3.1. >> >> >>> The document seems well written, although I'd like to have some >>> example keys and show how they permute things in practice so that >>> implementors can validate their work. >> >> Right, we will produce an example, possibly as an Appendix referred at= the end >> of Section 4. >> >> >> >>> The additions to CoJP seems well done, I'm so glad we changed that to= >>> a hash From an array :-) >>> >>> If the permutation is replaced whenever the network key is changed, >>> which means that the permutation is going to change! This means that= >>> some nodes could be on the new permutation while others are on the ol= d. >>> >>> A thought to deal with this is that the new permutation is not used >>> until the node switches to the new keys. EXCEPT that the adjacent >>> nodes will now not be listening at the right time, won't hear traffic= encrypted >> with the new >>> key, and won't change over themselves. Authenticated enhanced beaco= ns >> would >>> perhaps help here. Maybe I'm wrong about this problem. >> >> This seems to deserve some more text in the Security Considerations of= >> Section 6.2, such as the following points. >> >> The new link keys and permutation keys are expected to be distributed >> together, just like for the described provisioning through the CoJP Jo= in >> Response, possibly through the same procedure described in [1]. >> >> After a rekeying process is completed, a node should indeed start usin= g the >> new permutation keys once switched to the new link keys only, i.e. >> after it has discarded the old key material as per the handling of the= "link-layer >> key set" in [2]. >> >> If a node A discards the old key material (considerably) before a node= B, they >> will be temporarily unaligned. That is, node B would temporarily secur= e >> outgoing messages still using the old key material [2] that A does not= own >> anymore, and would still permute its schedule the old way. >> >> Eventually, B will also discard the old key material, e.g. after recei= ving and >> successfully security processing an incoming message secured with the = new >> key material [2], of course though while still over its old-fashion-pe= rmuted >> schedule. Here enhanced beacons authenticated with the new key materia= l >> seem to help. Also, a local upper bound can be enforced through a para= meter >> similar to COJP_REKEYING_GUARD_TIME [2]. >> Then, the two nodes will be aligned again on both processing secure me= ssages >> and permuting their schedule. >> >> >> What do you think? >> >> >> [1] >> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#sect= ion-8.2 >> [2] >> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#sect= ion-8.4 >> >> >> >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >> -- >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://www.ri.se >> --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --d6qXB4BTrcyRTK2J7kM9UJ6tSxsl4CyHC-- --FGdYRubHA4AOEwxmTDCql0Rcz8FHVpfXa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlynDxAACgkQ7iZktA5Y 2kPqDQgAo8jJDM84mrA8EcRIbn90Fzo6I2VazyPAVR6dgIf3Nxf+ErJNyQjEYFXY pE4H3fW0h3JmTOT6pbK47Lb+umkocnGUuEh+tgwG2F1/8kttevm2a8UvHBOnLVcw Wc3iQzqFPjcyFXADebb6Vo+mhMTmT6n7jSeQzEzQa5jDHrV1wEs/cMMFKVZ8Zb3o 7xOUD6QGX1Wgj2otjd5jflHYPByRXY/RIzYtqV3HRprdLHOx029L4i5Yq7myIttI Vlx9Sw7gBGcAYSEALJXXURaiMKfyqqxhj1foAq7Q9SPwe60OOSAhGUG9ojaF+s9+ /KFiOO7ZmkScudr+tmfBzPP/k4oSVA== =mUNt -----END PGP SIGNATURE----- --FGdYRubHA4AOEwxmTDCql0Rcz8FHVpfXa-- From nobody Fri Apr 5 01:19:11 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65324120390 for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 01:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.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 QiiGk7w5cSlJ for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 01:19:06 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00085.outbound.protection.outlook.com [40.107.0.85]) (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 D9F4E12038D for <6tisch@ietf.org>; Fri, 5 Apr 2019 01:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x8ZziPyRSIav9SYqIyOttLoPMAYMG9p5GH2OSBQDzZE=; b=CLeJnWA65SHg+XauaBBNgwZqkZ35vqnx4RUWarSTXu2YPPpCbFn526WPjfMGMEUe/dedKYEOhGVxiLvk2RVrzfgB+AAOpHNGILF9nxDvd6re3F7LiCpZqJAMkrlgbvthmZV3Sg/Jl1ImzuDoPncB1L6bjBHaRoGzdbna/49yj0E= Received: from HE1P189CA0013.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::26) by VI1P189MB0333.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Fri, 5 Apr 2019 08:19:03 +0000 Received: from AM5EUR02FT059.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::209) by HE1P189CA0013.outlook.office365.com (2603:10a6:7:53::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17 via Frontend Transport; Fri, 5 Apr 2019 08:19:02 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT059.mail.protection.outlook.com (10.152.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1750.20 via Frontend Transport; Fri, 5 Apr 2019 08:19:02 +0000 Received: from [10.112.10.131] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 5 Apr 2019 10:19:02 +0200 To: Simon Duquennoy , Tengfei Chang CC: 6tisch <6tisch@ietf.org> References: From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <7895e2f3-706f-6121-91ff-f61a75bca6b3@ri.se> Date: Fri, 5 Apr 2019 10:19:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JrX2lHMk71oE7IkbFJ3dTfBrB3z8tKFYW" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(979002)(39860400002)(136003)(376002)(346002)(396003)(2980300002)(199004)(51914003)(189003)(7736002)(64126003)(36756003)(104016004)(65956001)(40036005)(65806001)(106002)(53546011)(68736007)(71190400001)(22756006)(33964004)(386003)(235185007)(6246003)(44832011)(5070765005)(478600001)(4326008)(97736004)(5660300002)(66574012)(316002)(356004)(110136005)(58126008)(5024004)(568964002)(16586007)(16576012)(31686004)(229853002)(336012)(53936002)(486006)(8936002)(11346002)(8676002)(84326002)(74482002)(65826007)(2906002)(476003)(126002)(236005)(446003)(966005)(2616005)(6116002)(16526019)(69596002)(54896002)(76176011)(606006)(186003)(86362001)(31696002)(106466001)(3846002)(21480400003)(77096007)(26005)(6306002)(81166006)(81156014)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0333; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e49a22df-5a03-44de-a6cb-08d6b99f5c9f X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4709054)(2017052603328)(7193020); SRVR:VI1P189MB0333; X-MS-TrafficTypeDiagnostic: VI1P189MB0333: X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0998671D02 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: iJ+fyWQX4mXHzg2dRQvmhRBSw1Mz3GRcUYlvb4e7iOti+lk+ZHn/lUdRjO6lNKPDnjjg6utu6lzRQlMlL6+oJBMtGf1BaXvgueFJsmU+sHF+W7V8SmyP0dV3+gY6Y4cHP7JxWHYM3oR2z0V4C6KAp0y5R97rcm1T5l3gs6D59NCzH/hD1972tPv4JwqlmqPbaobLVcrzcCvdT/Biss+v7ytKxawQmujaUCOxdI+RnmbjhJl2xoXauvAZZZEKTcE3uNBIAovwx/M9fhxY4BDocu2CBSQA+qu5ze4rtQD2UGGSKHBvsbjKH3QypSkC1kgE/v1EjM+T12WDwR4nmSnIlLAWL6QVPMXKeYTnMETzOi2XEeAtXz7PHR47eCCdS4tW0bLwEyLfUjys5XKJ/isOgFMMQWbEPCQ0bxSyaSZ/uo8= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2019 08:19:02.3348 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e49a22df-5a03-44de-a6cb-08d6b99f5c9f X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0333 Archived-At: Subject: Re: [6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 08:19:09 -0000 --JrX2lHMk71oE7IkbFJ3dTfBrB3z8tKFYW Content-Type: multipart/mixed; boundary="EovDF3VH7HcdTHaYVx2pVrV7RlAEHXIVH"; protected-headers="v1" From: Marco Tiloca To: Simon Duquennoy , Tengfei Chang Cc: 6tisch <6tisch@ietf.org> Message-ID: <7895e2f3-706f-6121-91ff-f61a75bca6b3@ri.se> Subject: Re: [6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01 References: In-Reply-To: --EovDF3VH7HcdTHaYVx2pVrV7RlAEHXIVH Content-Type: multipart/alternative; boundary="------------B2EE8B29BA30A47C0AA96349" Content-Language: en-US This is a multi-part message in MIME format. --------------B2EE8B29BA30A47C0AA96349 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Tengfei, Thank you for your review! As to your comment on Equation 1, we used 'c' to highlight it as the unknown variable when solving the equation, but indeed it refers to the channel offset. We will make this explicit in the text. Best, /Marco On 4/4/19 8:57 PM, Simon Duquennoy wrote: > Hi Tengfei, > > Thanks for these questions. > > 1. We're not protecting against selective jamming on the minimal cell > indeed. This is a tricky problem, because beacons must include enough > information for nodes to find out when to tx/rx for the join > procedure, and a not-joined-yet node can do it then so can an > attacker. Our threat model is where the attacker is interested in > degrading the performance for a given [set of] node[s] in a running > network. > > 2. This is a great point. We currently know of two approaches, both of > which involve a slight modification of MSF. (a) make MSF use the > minimal cell instead of autonomous for joining or (b) move autonomous > cells to a different slotframe than dedicated cells (e.g. to > autonomous to slotframe 0, or dedicated to a new slotframe 2). > > Best, > Simon > > On Thu, Apr 4, 2019 at 6:47 PM Tengfei Chang > wrote: > > Hello Authors, > > I just reviewed the draft. It reads pretty good for me! I only > found a tiny typo error in Eq.1 where the 'c' is not defined > actually, I believe you mean 'chOff'. > > Besides, I have two questions referring the usage of minimal cell. > > 1. What if the selective jamming applied on the minimal cell? Do > you consider to resolve this case? > > 2. The joining traffic is going on=C2=A0 minimal cell in slotframe = 0. > Do you plan to use some strategy to regulate the traffic on > minimal cell? I am asking this because this is different from what > MSF is doing, which send joining packet over autonomous cell. > > Tengfei > > --=20 > Chang Tengfei, > Pre-Postdoctoral Research Engineer, Inria > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------B2EE8B29BA30A47C0AA96349 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Tengfei,

Thank you for your review!

As to your comment on Equation 1, we used 'c' to highlight it as the unknown variable when solving the equation, but indeed it refers to the channel offset. We will make this explicit in the text.

Best,
/Marco

On 4/4/19 8:57 PM, Simon Duquennoy wrote:
Hi Tengfei,

Thanks for these questions.

1. We're not protecting against selective jamming on the minimal cell indeed. This is a tricky problem, because beacons must include enough information for nodes to find out when to tx/rx for the join procedure, and a not-joined-yet node can do it then so can an attacker. Our threat model is where the attacker is interested in degrading the performance for a given [set of] node[s] in a running network.

2. This is a great point. We currently know of two approaches, both of which involve a slight modification of MSF. (a) make MSF use the minimal cell instead of autonomous for joining or (b) move autonomous cells to a different slotframe than dedicated cells (e.g. to autonomous to slotframe 0, or dedicated to a new slotframe 2).

Best,
Simon

On Thu, Apr 4, 2019 at 6:47= PM Tengfei Chang <tengfei.chang@gmail.com> wrote:
=
Hello Authors,

I just reviewed the draft. It reads pretty good for me! I only found a tiny typo error in Eq.1 where the 'c' is not defined actually, I believe you mean 'chOff'.

Besides, I have two questions referring the usage of minimal cell.

1. What if the selective jamming applied on the minimal cell? Do you consider to resolve this case?

2. The joining traffic is going on=C2=A0 minimal cell in= slotframe 0. Do you plan to use some strategy to regulate the traffic on minimal cell? I am asking this because this is different from what MSF is doing, which send joining packet over autonomous cell.

Tengfei

--
Chang Tengfei,
Pre= -Postdoctoral Research Engineer, Inria
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

____________________________=
___________________
6tisch mailing list
6ti=
sch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

--=20
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------B2EE8B29BA30A47C0AA96349-- --EovDF3VH7HcdTHaYVx2pVrV7RlAEHXIVH-- --JrX2lHMk71oE7IkbFJ3dTfBrB3z8tKFYW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlynD3UACgkQ7iZktA5Y 2kMEWQf5AQJMqsQBXd0GgG++LHOXZSvUZBWt4rgS3mdt3bk6Zh39I2ew+NbFXs5u NEGHnH+P01Qa4VM13wK5geTPzfN1bT05LmfRdXjMKEjdMLTujOaDJHgy8hOck0cn IrJuocBmEg8g28TCUGSl1ueSMj/45w2qPDDPo1PkjgC97ZD+LawgkM/GScEAvFpb 1jU8uqTJ4rVJ1olwiGc9I2b7IK6k0PgsUHHxKYsIYptEX816D9LbVRB7tkBl2mxI kCkMJ531z0QkSwEPsoSlnbkAL/TXSc6MDuZblw9t+SuHUrq2EBCQseiDjkrFJOh+ 7HoFpJs1+5ggSc8lWhrH+uwVD1SqRg== =mL/n -----END PGP SIGNATURE----- --JrX2lHMk71oE7IkbFJ3dTfBrB3z8tKFYW-- From nobody Fri Apr 5 01:30:06 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66AC120391; Fri, 5 Apr 2019 01:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.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 OWDjrMIBaiMj; Fri, 5 Apr 2019 01:30:01 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40053.outbound.protection.outlook.com [40.107.4.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF891201BE; Fri, 5 Apr 2019 01:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d8/MwwXlDpmmWhJFOusKg0XuTMfTbJIux5Mv3/QfosM=; b=A507TSxVw6IY8CATiokcvEeWTxOsZq4ctgdA5k5rwZFC945nezMxH6HpJFohaVlHNqxJ6jUBtSaBTVEFcpEu6EmoQXpofTX5MAblu0bFFEqKowrEQrcCjK59hB2vVhekaF6vU/EHKpS7xDJK2a5jPBurskKaG4tkpRSdEG6oUmk= Received: from VI1P189CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::36) by AM5P189MB0322.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:20::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15; Fri, 5 Apr 2019 08:29:57 +0000 Received: from HE1EUR02FT023.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::209) by VI1P189CA0023.outlook.office365.com (2603:10a6:802:2a::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15 via Frontend Transport; Fri, 5 Apr 2019 08:29:57 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT023.mail.protection.outlook.com (10.152.10.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1750.20 via Frontend Transport; Fri, 5 Apr 2019 08:29:56 +0000 Received: from [10.112.10.131] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 5 Apr 2019 10:29:56 +0200 To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , "Michael Richardson" CC: 6tisch <6tisch@ietf.org>, References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <35064ce6-b5a1-e757-08c0-7b5b00900c74@ri.se> Date: Fri, 5 Apr 2019 10:29:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pd0IhZUlC3fglBwMytfnG7tSo5c3vbz3z" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(2980300002)(189003)(199004)(26005)(235185007)(5660300002)(44832011)(65826007)(8676002)(81166006)(81156014)(58126008)(54906003)(110136005)(93886005)(106466001)(8936002)(16526019)(186003)(53936002)(2616005)(6116002)(106002)(68736007)(336012)(446003)(476003)(486006)(126002)(64126003)(65806001)(65956001)(236005)(4326008)(11346002)(54896002)(6306002)(74482002)(7736002)(2906002)(568964002)(6246003)(478600001)(36756003)(14444005)(966005)(31686004)(21480400003)(229853002)(606006)(22756006)(40036005)(31696002)(104016004)(76176011)(6666004)(356004)(71190400001)(33964004)(16576012)(16586007)(386003)(53546011)(77096007)(84326002)(86362001)(5024004)(3846002)(66574012)(97736004)(69596002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0322; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cf8537e3-5352-40d5-3009-08d6b9a0e2dc X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4709054)(2017052603328)(7193020); SRVR:AM5P189MB0322; X-MS-TrafficTypeDiagnostic: AM5P189MB0322: X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0998671D02 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: lVRjuiuzp9EkHJxPo4W6XcbDbMSwZixesiyX49cyduCGCSU89oYL1P0e610iXqkpB5ofUiVTPhqwU+NJOutBiOHH9tzs2Xuu43JmrEY3EHV852hoc+SyBPkSAzH8mq2AwuR4cL94xud9z56Rpf5Ebv9a1AYZy/w00RHLSPlDCv3r9iz+TDmDVuTIC15yMrfZugvZkuDcTW+UBAJkOT5caJL7+BAu9Bc/IXqBkybJz+wfX1rHA1JAf9sktO0WfV/M1gpk+yJbjZLPyNhIvwE1BBvJq8AAYamCu9BcQC3QTsd9XDHZX6j6ipHhfzxrRildD1nDp5xCmcyxeArKBIAt2MX9+MeFnjVLd+xp77LOKaMH3nKPJ70RSu9/qkLpf6J0gG+RdpKuwtU/PI7GZobKAdJBrxL8YLnT6huEZHi2Sws= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2019 08:29:56.9367 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cf8537e3-5352-40d5-3009-08d6b9a0e2dc X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P189MB0322 Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 08:30:05 -0000 --pd0IhZUlC3fglBwMytfnG7tSo5c3vbz3z Content-Type: multipart/mixed; boundary="APnMniy1swYpYHcFrGc4RmNVtlxwy4m1I"; protected-headers="v1" From: Marco Tiloca To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , Michael Richardson Cc: 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org Message-ID: <35064ce6-b5a1-e757-08c0-7b5b00900c74@ri.se> Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> In-Reply-To: <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> --APnMniy1swYpYHcFrGc4RmNVtlxwy4m1I Content-Type: multipart/alternative; boundary="------------9A4D0B71B7E5DA1DFEF479F2" Content-Language: en-US This is a multi-part message in MIME format. --------------9A4D0B71B7E5DA1DFEF479F2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Mali=C5=A1a, Michael, Thanks for this discussion, I think this is a good summary of the problem= =2E Just to stress that the full-fledged approach, by making also slotOffsets unpredictable rather than static (i.e. obviously predictable) further greatly decreases the attack surface, since a now-random jammer would be forced to guess both channels and timeslots of target node(s). On the other hand, it's surely undesirable when keeping latency at bay is a priority and a criterion of the original scheduling function. So, I agree that we can better think of what recommending in Section 6.3, and under which assumptions. In case: i) the original scheduling function is not oriented to latency optimization; and ii) it is acceptable for nodes to experience collisions during COJP_REKEYING_GUARD_TIME upon network rekeying; then permuting also the slotOffsets should IMHO still be the preferable thing to do and recommend= =2E Best, /Marco On 4/4/19 11:38 PM, Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > It seems i have permuted slotOffset and channelOffset below :-) This > may be a piste if slotOffset permutation is kept but there would > likely be problems for nodes with higher bandwidth requirements and > many cells in the schedule to guarantee zero slotOffset collisions in > one own=E2=80=99s schedule across slotframe iterations. Don=E2=80=99t r= eally like it > though for the reason of breaking the scheduling function. > > As a reminder, in minimal-security we resorted to the current rekeying > mechanism and not the one using the exact timestamp in the future when > the whole network switches to new keys in order to avoid having to > know the network notion of time at the JRC. > > Mali=C5=A1a > >> On 4 Apr 2019, at 19:33, Mali=C5=A1a Vu=C4=8Dini=C4=87 > > wrote: >> >> My understanding is that the problem in the permuted schedule arises >> during COJP_REKEYING_GUARD_TIME after nodes in the network started >> using the new keys, but have still kept the old key in case someone >> has not yet switched. When coupled with a rekeyed permutation key to >> calculate the schedule, this means that during >> COJP_REKEYING_GUARD_TIME a node would need to follow two schedules, >> one with the old permutation key and one with the new one. The >> problem in following two schedules for COJP_REKEYING_GUARD_TIME is >> that draft-tiloca-6tisch-robust-scheduling-01 recommends both the >> slotOffset and the channelOffset be permuted so that it may occur >> that there can be a collision in slotOffset between the new and the >> old schedule. >> >> The problem that draft-tiloca-6tisch-robust-scheduling solves seems >> to be the predictability of the channel on which a transmission is >> going to take place. With that in mind, I have second thoughts about >> the recommendation on permuting the slotOffset, especially taking >> into account that this will break any scheduling function that >> optimizes for latency, as discussed in Section 6.3. >> >> Mali=C5=A1a >> >> >>> On 4 Apr 2019, at 17:40, Michael Richardson >> > wrote: >>> >>> Can you see how the old/new key issue interacts poorly with the permu= ted >>> schedule? >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------9A4D0B71B7E5DA1DFEF479F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Mali=C5=A1a, Michael,

Thanks for this discussion, I think this is a good summary of the problem.

Just to stress that the full-fledged approach, by making also slotOffsets unpredictable rather than static (i.e. obviously predictable) further greatly decreases the attack surface, since a now-random jammer would be forced to guess both channels and timeslots of target node(s). On the other hand, it's surely undesirable when keeping latency at bay is a priority and a criterion of the original scheduling function.

So, I agree that we can better think of what recommending in Section 6.3, and under which assumptions. In case: i) the original scheduling function is not oriented to latency optimization; and ii) it is acceptable for nodes to experience collisions during COJP_REKEYING_GUARD_TIME upon network rekeying; then permuting also the slotOffsets should IMHO still be the preferable thing to do and recommend.

Best,
/Marco

On 4/4/19 11:38 PM, Mali=C5=A1a Vu=C4=8D= ini=C4=87 wrote:
It seems i have permuted slotOffset and channelOffset below :-) This may be a piste if slotOffset permutation is kept but there would likely be problems for nodes with higher bandwidth requirements and many cells in the schedule to guarantee zero slotOffset collisions in one own=E2=80=99s schedule across slotfram= e iterations. Don=E2=80=99t really like it though for the reason of b= reaking the scheduling function.

As a reminder, in minimal-security we resorted to the current rekeying mechanism and not the one using the exact timestamp in the future when the whole network switches to new keys in order to avoid having to know the network notion of time at the JRC.

Mali=C5=A1a

On 4 Apr 2019, at 19:33, Mali=C5=A1a Vu=C4=8D= ini=C4=87 <malisa.vucinic@inria.fr> wrote:

My understanding is that the problem in the permuted schedule arises during COJP_REKEYING_GUARD_TIME after nodes in the network started using the new keys, but have still kept the old key in case someone has not yet switched. When coupled with a rekeyed permutation key to calculate the schedule, this means that during COJP_REKEYING_GUARD_TIME a node would need to follow two schedules, one with the old permutation key and one with the new one. The problem in following two schedules for COJP_REKEYING_GUARD_TIME is that draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset and the channelOffset be permuted so that it may occur that there can be a collision in slotOffset between the new and the old schedule.

The problem that draft-tiloca-6tisch-robust-scheduling solves seems to be the predictability of the channel on which a transmission is going to take place. With that in mind, I have second thoughts about the recommendation on permuting the slotOffset, especially taking into account that this will break any scheduling function that optimizes for latency, as discussed in Section 6.3.

Mali=C5=A1a


On 4 Apr 2019, at 17:40, Michael Richardson <mcr= @sandelman.ca> wrote:

Can you see how the old/new key issue interacts poorly with the permuted
schedule?

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6ti= sch


--=20
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------9A4D0B71B7E5DA1DFEF479F2-- --APnMniy1swYpYHcFrGc4RmNVtlxwy4m1I-- --pd0IhZUlC3fglBwMytfnG7tSo5c3vbz3z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlynEf4ACgkQ7iZktA5Y 2kPcXwf/ZmDZlV/iS5kbJCzGK1fbARLi8CatJVSmyVEdZFmmuxlPBU4jEEOB8MZz Ha4o69NPr7aByZDo9DIwGogUgmt8GJO9+UG7pbGoq2zl5i7AkstQKZq7Mu19n9+x iC0zazSr/xvIByV+xIf6nrNHa/UrjA31hRD8lffb6WrItVRq9dJZW0H94G7pmxKE +0x1dBWgp6OJyKXr2dpcp1PJ8UXOXnL4RspUPBwEPjRaD3ON5mOXiaYWd9+Q1zZ4 dFCB4/gsKORvWIxbI2TMpfzDQOWA8CYSoZoowQ3WlPLF4ZjoGjiSqK82S2Sap09j 37xkD61QhkdQpiHMYrgP7LGDlGjKRQ== =enpH -----END PGP SIGNATURE----- --pd0IhZUlC3fglBwMytfnG7tSo5c3vbz3z-- From nobody Fri Apr 5 07:32:53 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42AF12044F for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 07:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nR4Y2ojBkJjH for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 07:32:49 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98900120250 for <6tisch@ietf.org>; Fri, 5 Apr 2019 07:32:48 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id EACDE43811; Fri, 5 Apr 2019 16:32:45 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2177526; Fri, 5 Apr 2019 16:32:45 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:61:a2::907]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B061374; Fri, 5 Apr 2019 16:32:44 +0200 (CEST) Received: (nullmailer pid 30735 invoked by uid 1000); Fri, 05 Apr 2019 14:32:37 -0000 Date: Fri, 5 Apr 2019 16:32:37 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Cc: 6tisch@ietf.org Message-ID: <20190405143235.GA7326@hephaistos.amsuess.com> References: <20190327172921.GA9348@hephaistos.amsuess.com> <20190328002907.GC28841@hephaistos.amsuess.com> <1CE26FD6-ACDB-4E95-A195-19953750FDD9@inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <1CE26FD6-ACDB-4E95-A195-19953750FDD9@inria.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 14:32:52 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Mali=C5=A1a, > Let me know what do you think. thanks for the update, this addresses my concerns. Only a small question remains: When a pledge sends [0 /* unsupported */, 42 /* some fancy extension */, X] as an Unsupported Configuration, why should it send the full value that was sent with the join response and not just a syntactic placeholder (null)? Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlynZwAACgkQOY0REtOk veFYyg//Y5wKoSNn5Edf8/Kb7Y0DAPHMC1U0gTr68XkM/euUIWV9VqDOCRSpUfuV 5IFKUGngKR0Qg8e4TrW0vnJfrMZ4VBRBDHxcHYlhqAc99eXCcC7H8QTe0xXtmt70 jkz9Ix3WMegOkVqwpkRoPB+Av+lHFrvP1bCF+fVH0NL0wua4dEWZGyfGUYWXNE5I Zwy81SPI1wjZCUQFHYCroSB2JAOApXeRg4SoBgN3MqEpiGPmmaSlF3GJT/SgES95 bwk2NlJUvaMrJdobjcvf+VeotsbAz/jMX+eceOyRWxrFkNh7F8IJ8VAuZyDe3LKJ Nt4JG1p9euqEsjW/pb+H4T6tY99TcIry+ijk6NOyhHepTnLk3dF9y8/V5GJxRYqd ZjtwjfQ2XnRuqaEV1gjnnrHfNJbIzp5jT1W8kvkJpB2UA/uNgS+K7AQ5hLkS0I/2 m//RiMwigrTFk9i1LP8q4lbgT95PYzjDsmDzlxjXSRtwGY0MzAFlJ/p9GMfiUdhQ mDZkBE7li7UfqoN0nvXYFxGI0ThpOPwfqpxNYGY3uLci+eTIo39RnuBADhd0X8kB UnuqEC4BU9JSM1BK6N5LweI4sfkc78OiOmOF/QHmpbFWu6kcSwAacq7wfdul34qM PW/wF5YUzk+Z6Op/Jo7vfl3WOIN/ZqpE4QzPQwU6yn2UMkKXDFU= =iG8f -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From nobody Fri Apr 5 08:08:31 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91650120052 for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 11:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehBOqz2RVTCm for <6tisch@ietfa.amsl.com>; Thu, 4 Apr 2019 11:54:52 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 1AD6412003F for <6tisch@ietf.org>; Thu, 4 Apr 2019 11:54:52 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id r186so7969933wmf.1 for <6tisch@ietf.org>; Thu, 04 Apr 2019 11:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U6HCIGQKZvcrcIK8V5AqrhUM/DyM6H4eAlQPUZCNxN4=; b=omXuWCGkDhIIAD6kNspcbrOc+VMpBFZT+hD8M5hLZ0n8QadDvb+7HGa7cwOQ/bQkNb SJNDFcdt3KoyYyXqPGB35QxnJ/KMACC+jQoF37iHSfnUp9bbMwBu7gJGXpRVSUCXfoSz TqtReQXg7BrkpjE7bGGJXjYXqDFIZsblzXk79g7ktXYhC/Xt7jvoNdZf99G0KMoDCXvg BsLQmYoj4c14aXlOTevIPZ+7gQd4wAX4AeDVIV5TBJ/WOWyKqS1P0nLGmwmZ3h8jZIeo uqW4xO5MMcLP8L4qeZZu4yxFmwQJXO9ZqG5GHRSkzxNFIM779ozqf0ENfA6+YDNFIITd ii7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U6HCIGQKZvcrcIK8V5AqrhUM/DyM6H4eAlQPUZCNxN4=; b=KnhGZQIOefXpt0mdGGwI3cVvXfujogrtcUXzAa9RJfdftilTSx6vjZPu6/SDFp3Dmh euZ5bnvs+vrLMZTmnrdt/8xjGzPz9zcWG39LdkEsldiAt382V4dIgni475DpExGmgL+7 Z4Q/NSiijvbcTkKlGJ6YDBwTPyblncWRZCsxqkijV+q4/1zVqOpsx1KwZaMeKoGAjFbS AxBkCgPgkXRu9Vt3GijThfO0oGI9jZOOFZF/wzRGZm+o39xaBexJUdzfhORggzS3cLrd pPZsAyB2+BS7WqlipH2mNhk4aY4ZMWwrkeWXCLxGcc36moyef5UriC2prt3XIgh+tXhi RMNQ== X-Gm-Message-State: APjAAAXVxXr5W+mpICyq7eSBiTQWQytv1bq/XjInlxn/i7A92rOMAEJe +JdCwETMBZIi4Htg9g3OCP8hUURe3nrsdrbAUKU= X-Google-Smtp-Source: APXvYqzOD5jBohzP04jlDCPsHRyLdrXsR/kkMuGiKCqIL5Gqjcfnbps4E7tTL3KPNfXqQ55llQWNv3kNwuDPQr0v7Kk= X-Received: by 2002:a1c:be13:: with SMTP id o19mr4843787wmf.19.1554404090429; Thu, 04 Apr 2019 11:54:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon Duquennoy Date: Thu, 4 Apr 2019 20:54:39 +0200 Message-ID: To: Tengfei Chang Cc: 6tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="000000000000a5c7e00585b8e77c" Archived-At: X-Mailman-Approved-At: Fri, 05 Apr 2019 08:08:30 -0700 Subject: Re: [6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 18:54:55 -0000 --000000000000a5c7e00585b8e77c Content-Type: text/plain; charset="UTF-8" Hi Tengfei, Thanks for these questions. 1. We're not protecting against selective jamming on the minimal cell indeed. This is a tricky problem, because beacons must include enough information for nodes to find out when to tx/rx for the join procedure, and a not-joined-yet node can do it then so can an attacker. Our threat model is where the attacker is interested in degrading the performance for a given [set of] node[s] in a running network. 2. This is a great point. We currently know of two approaches, both of which involve a slight modification of MSF. (a) make MSF use the minimal cell instead of autonomous for joining or (b) move autonomous cells to a different slotframe than dedicated cells (e.g. to autonomous to slotframe 0, or dedicated to a new slotframe 2). Best, Simon On Thu, Apr 4, 2019 at 6:47 PM Tengfei Chang wrote: > Hello Authors, > > I just reviewed the draft. It reads pretty good for me! I only found a > tiny typo error in Eq.1 where the 'c' is not defined actually, I believe > you mean 'chOff'. > > Besides, I have two questions referring the usage of minimal cell. > > 1. What if the selective jamming applied on the minimal cell? Do you > consider to resolve this case? > > 2. The joining traffic is going on minimal cell in slotframe 0. Do you > plan to use some strategy to regulate the traffic on minimal cell? I am > asking this because this is different from what MSF is doing, which send > joining packet over autonomous cell. > > Tengfei > > -- > Chang Tengfei, > Pre-Postdoctoral Research Engineer, Inria > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --000000000000a5c7e00585b8e77c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tengfei,

Thanks for these questions.=

1. We're not protecting against selective jam= ming on the minimal cell indeed. This is a tricky problem, because beacons = must include enough information for nodes to find out when to tx/rx for the= join procedure, and a not-joined-yet node can do it then so can an attacke= r. Our threat model is where the attacker is interested in degrading the pe= rformance for a given [set of] node[s] in a running network.

=
2. This is a great point. We currently know of two approaches, b= oth of which involve a slight modification of MSF. (a) make MSF use the min= imal cell instead of autonomous for joining or (b) move autonomous cells to= a different slotframe than dedicated cells (e.g. to autonomous to slotfram= e 0, or dedicated to a new slotframe 2).

Best,
Simon



Tengfei

--
Chang Tengfei,
Pre-Postdoctoral Research Engi= neer, Inria
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
--000000000000a5c7e00585b8e77c-- From nobody Fri Apr 5 08:38:52 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA212048C for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 08:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMc5mOYyoq7l for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 08:38:48 -0700 (PDT) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (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 F2712120445 for <6tisch@ietf.org>; Fri, 5 Apr 2019 08:38:47 -0700 (PDT) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id x35FcfqG047937 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <6tisch@ietf.org>; Fri, 5 Apr 2019 15:38:42 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id x35FcfkN056549 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <6tisch@ietf.org>; Fri, 5 Apr 2019 15:38:41 GMT Received: from dhcp138.math.unipd.it (dhcp138.math.unipd.it [147.162.114.138]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Fri, 05 Apr 2019 17:38:41 +0200 Date: Fri, 05 Apr 2019 17:38:41 +0200 Message-ID: <20190405173841.Horde.dn-TwxiU4m-0HidtIkKxLKT@webmail.math.unipd.it> From: gquadrio@math.unipd.it To: 6tisch@ietf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DCC-dmv.com-Metrics: server4 1096; Body=65 Fuz1=65 Fuz2=148 X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker (-11) X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.83 Archived-At: Subject: [6tisch] [CFP] [5 days Remained] EAI GOODTECHS 2019 - Valencia, Spain, 25/09 - 27/09 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 15:38:51 -0000 ******************************************************************** * * Call for Papers * * GoodTechs 2019 * * 5th EAI International Conference on * Smart Objects and Technologies for Social Good * * September 25-27, 2019 * * Submissions due: April 10, 2019 [extended] * ******************************************************************** SCOPE ====== By social good we refer to a “good” or a service that benefits the largest number of people in the largest possible way. Some classic examples of social goods are, of course, healthcare, safety, environment, democracy, and human rights, but we can add to this classic list even communication, art, entertainment and much more. In this context, the popularity of portable computing devices, like smartphones, tablets, or smart watches combined with the emergence of many other small smart objects with computational, sensing and communication capabilities coupled with the popularity of social networks and new human-technology interaction paradigms is creating unprecedented opportunities for each of us to do something useful, ranging from a single person to the whole world. Furthermore, Internet of Things, Smart-cities, distributed sensing and Fog computing are representative examples of modern ICT paradigms that aim to describe a dynamic and globally cooperative infrastructure built upon objects’ intelligence and self-configuring capabilities. These connected objects are finding their way into our pockets, vehicles, urban areas and infrastructure, thus becoming the very texture of our society and providing us the possibility, but also the responsibility, to shape it. In GOODTECHS we are hence interested in experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Clearly, we are not considering only the so called first world as the scenario for this evolution; we also refer to those areas where ICT is currently less widespread, hoping that it may represent a societal development opportunity rather than a source for further divide. Topics Authors are solicited to submit original, previously unpublished papers in the following, but not limited to topic areas: - App concepts and technologies for different mobile platforms - Blockchain for social good - Communication between mobile devices - Content Distribution - E-learning solutions - Data collection, organization and dissemination methods - Delay-tolerant aerial networks and ferrying approaches - Deployment and field-testing - Digital tools for art and feelings - Environment sensing, monitoring and preservation - Experimental results of communication testbeds - Game, entertainment, and multimedia applications - Health and social care - Human-object interaction - ICT for development - Mobile service architectures and frameworks - Mobility and handover management - New application scenarios for vehicular communications - Pervasive and ubiquitous services in cloud and IoT - Platforms and frameworks for mobile devices - Privacy issues and solutions - Protocol design, testing and verification - Security issues, architectures and solutions - Smart cities and transportation - Smart economy solutions: e-banking, e-business - Smart governance and e-administration - Smart living and E-health - Technology addressing the digital divide SPECIAL SESSIONS ================ In addition to the main conference, GOODTECHS19 features special sessions, aimed to emphasize emerging topics not fully or not specifically covered in the main conference. Special sessions highlight current topics related to experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Presentations delivered during the events should be based on original papers, selected through a peer-review process and that have not been previously published. Accepted papers will be included in the Conference Proceedings. For more information please refer to the main conference website: http://goodtechs.eu PUBLICATION =========== All registered papers will be published by ACM and made available through ACM Digital Library. Papers should be in English. Regular papers should be up to 6 pages in length. Short papers should be up to 4 pages in length. Previously published work may not be submitted, nor may the work be concurrently submitted to any other conference or journal. Such papers will be rejected without review. Proceedings will be submitted for inclusion in leading indexing services, Ei Compendex, ISI Web of Science, Scopus, CrossRef, Google Scholar, DBLP, as well as EAI’s own EU Digital Library (EUDL). Authors of selected best accepted and presented papers will be invited to submit an extended version to: - Springer Mobile Networks and Applications (MONET) Journal (IF: 2.497) - Wiley Concurrency and Computation: Practice and Experience Journal (IF: 1.114) All accepted authors are eligible to submit an extended version in a fast track of: - EAI Endorsed Transactions on Cloud Systems - EAI Endorsed Transactions on Serious Games SUBMISSION ========== Papers should be submitted through EAI ‘Confy‘ system (http://confy.eai.eu/52608), and have to comply with the ACM format (see Author’s kit section). IMPORTANT DATES =============== Full Paper Submission deadline: April 10, 2019 Notification deadline: June 1, 2019 Camera-ready deadline: July 1, 2019 Start of Conference: September 25, 2019 End of Conference: September 27, 2019 -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy From nobody Fri Apr 5 09:55:23 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C62A1204A3 for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHKAvwzF896n for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 09:55:18 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 E262A12007C for <6tisch@ietf.org>; Fri, 5 Apr 2019 09:55:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,313,1549926000"; d="scan'208,217";a="377420341" Received: from unknown (HELO [192.168.1.138]) ([79.143.111.171]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2019 18:54:59 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <3E48D726-D39D-456A-9D4E-B15DAC0FE6CF@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_F56B0651-20FB-47C9-9F1D-6586165381BC" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 5 Apr 2019 18:54:55 +0200 In-Reply-To: <20190405143235.GA7326@hephaistos.amsuess.com> Cc: 6tisch@ietf.org To: =?utf-8?Q?Christian_Ams=C3=BCss?= References: <20190327172921.GA9348@hephaistos.amsuess.com> <20190328002907.GC28841@hephaistos.amsuess.com> <1CE26FD6-ACDB-4E95-A195-19953750FDD9@inria.fr> <20190405143235.GA7326@hephaistos.amsuess.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 16:55:22 -0000 --Apple-Mail=_F56B0651-20FB-47C9-9F1D-6586165381BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The original intent was to allow the pledge to signal =E2=80=9CI can act = on this parameter but not on that value that you gave me=E2=80=9D, = cherry-picking specific keys from the key set or just copying the whole = thing if nothing works. The previous text optimized for that by = mandating the value or its CBOR-encoded subset to be included all the = time.=20 I rewrote the paragraph now in order to allow the pledge to send a null = for the case where the JRC should not bother to retry configuring that = specific parameter again. The commit is at: = https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/60= e2a8a2acbae5cca624932e88c1f650a95d9ca6?at=3Dminimal-security-10 = Let me know if it reads better. Mali=C5=A1a > On 5 Apr 2019, at 16:32, Christian Ams=C3=BCss = wrote: >=20 > Only a small question remains: When a pledge sends [0 /* unsupported = */, > 42 /* some fancy extension */, X] as an Unsupported Configuration, why > should it send the full value that was sent with the join response and > not just a syntactic placeholder (null)? --Apple-Mail=_F56B0651-20FB-47C9-9F1D-6586165381BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = original intent was to allow the pledge to signal =E2=80=9CI can act on = this parameter but not on that value that you gave me=E2=80=9D, = cherry-picking specific keys from the key set or just copying the whole = thing if nothing works. The previous text optimized for that by = mandating the value or its CBOR-encoded subset to be included all the = time. 

I = rewrote the paragraph now in order to allow the pledge to send a null = for the case where the JRC should not bother to retry configuring that = specific parameter again.

The commit is at:


Let me = know if it reads better.

Mali=C5=A1a

On 5 Apr 2019, at 16:32, Christian Ams=C3=BCss = <christian@amsuess.com> wrote:

Only a small question remains: When a pledge = sends [0 /* unsupported */,
42 /* some fancy extension */, = X] as an Unsupported Configuration, why
should it send the = full value that was sent with the join response and
not = just a syntactic placeholder = (null)?


= --Apple-Mail=_F56B0651-20FB-47C9-9F1D-6586165381BC-- From nobody Fri Apr 5 11:15:26 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633EE12047C; Fri, 5 Apr 2019 11:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URWOu9SkwXuG; Fri, 5 Apr 2019 11:15:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB481201CC; Fri, 5 Apr 2019 11:15:22 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id AACC838277; Fri, 5 Apr 2019 14:14:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id ED8F0FEC; Fri, 5 Apr 2019 14:15:19 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EB225DC7; Fri, 5 Apr 2019 14:15:19 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FB=3FTWFsacWhYSBWdcSNaW5pxIc=3D=3F=3D?= cc: Marco Tiloca , 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org In-Reply-To: <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 18:15:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > My understanding is that the problem in the permuted schedule arises > during COJP_REKEYING_GUARD_TIME after nodes in the network started > using the new keys, but have still kept the old key in case someone h= as It's not just during that time, but from the time it receives the new keys until it switches to the new key and permutation. If it would listen on bo= th permutations, I guess it would work. The problem is that the rekey for a node does not start until it receives traffic with the new key. If it's not listening at the right time (and rig= ht channel), then it will never receive such a packet. If we could delay the switch to the new schedule until *after* COJP_REKEYING_GUARD_TIME has elapsed, then that might work. Alternatively, if we could number the rekeys then a EB could signal the switch to the new schedule some time after the keys are changed. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlynmzcACgkQgItw+93Q 3WWHewgAwEFAdPEQQrn/geCq3eQs/efg4nhhPDuqqxRy8OzMVAyXnniLYPEpzhOc tLjITXO+wv2W0LQpl1mFkse6HLQCsDxKkyVnzFmVNkb8Vw8qa0h/AgwxnB+ZO2Bb UqR+EPFzUR8+O0WA0gR42aE19h9GlICbw9GFr6iRDD0NMhR25Ga8if1jqoqawTFb 9eQeGnx6TBhaNaGR3WcpGr4fwFrELDBtkl2y4DofWDOM5juhWR1IKd7j+FG0pZhL 0xS+xk+AGWbDLBtdW/85ejMuqALRjXXNobi517G+ZoN5uuixZKWjO3swWIuoz2pC Bga+be7FM0nocLabBlzyN0XfpJv0lQ== =DlfM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 5 11:22:59 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8591205F9 for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 11:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1VtmRWeoVIs for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 11:22:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BADE1203F6 for <6tisch@ietf.org>; Fri, 5 Apr 2019 11:22:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 653D138277 for <6tisch@ietf.org>; Fri, 5 Apr 2019 14:22:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A7890FEC; Fri, 5 Apr 2019 14:22:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A4A05DC7 for <6tisch@ietf.org>; Fri, 5 Apr 2019 14:22:54 -0400 (EDT) From: Michael Richardson To: 6tisch <6tisch@ietf.org> In-Reply-To: <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 18:22:59 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > As a reminder, in minimal-security we resorted to the current rekeying > mechanism and not the one using the exact timestamp in the future when > the whole network switches to new keys in order to avoid having to kn= ow > the network notion of time at the JRC. Also so that the many unicast conversations needed to do the rekey can be s= pread across a large amount of time, letting the JRC reach out to even very sleepy nodes. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlynnP4ACgkQgItw+93Q 3WUGtAf9GgCIR98Q3pC+mz9kuTBFKvjLTDVT4HY1UcDL9dXv3CVDjAMsNarZ3MoB YZbsl/y60/AuqgFypBzgM/pgcBcebTZp9D9hIyPw7GbNwXpaNUaRR58Fq4blsVBR 9zzgyubWms1uPkjDQP61B69cVrYVUf9r/KW7Y4YyIi7bUKF2O1jR8aMATcCxwWxj rzpO6vluOx1Xqm+A42NTSWdfI3tq047SMvi+VnB2ffOqwUrBnChvdvUYIAA3P2QT SB9WCfAu42ZRonGpNhwfiwZJbMy65okmYdaHRVGnwDfcByViYrq/5OL2v0QJbYfv ZhS9rGDgnlyQNO82yxz5MP4InMyPQQ== =Uan3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 5 14:10:18 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAA412032D for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 14:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQlMoaO5Oh3Y for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 14:10:14 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 1A7A5120167 for <6tisch@ietf.org>; Fri, 5 Apr 2019 14:10:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,313,1549926000"; d="scan'208,217";a="377436727" Received: from unknown (HELO [192.168.1.138]) ([79.143.111.171]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2019 23:10:12 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <634BC96B-31B8-4BBF-867D-207CEF9F58B7@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_7BE6443C-2454-4135-B4BB-EE3E28B60DAD" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 5 Apr 2019 23:10:08 +0200 In-Reply-To: <668.1554488574@localhost> Cc: 6tisch <6tisch@ietf.org> To: Michael Richardson References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr> <668.1554488574@localhost> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 21:10:17 -0000 --Apple-Mail=_7BE6443C-2454-4135-B4BB-EE3E28B60DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 5 Apr 2019, at 20:22, Michael Richardson = wrote: >=20 > Also so that the many unicast conversations needed to do the rekey can = be spread > across a large amount of time, letting the JRC reach out to even very = sleepy > nodes. Good point indeed, sleepy nodes may miss the reception slots and appear = disconnected but as long as they are in the network they will eventually = get the CoJP Parameter Update Request and the new keys, assuming JRC = implements the default retransmission mechanism. Mali=C5=A1a= --Apple-Mail=_7BE6443C-2454-4135-B4BB-EE3E28B60DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 5 Apr 2019, at 20:22, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Also so that the many unicast = conversations needed to do the rekey can be spread
across a large amount of time, = letting the JRC reach out to even very sleepy
nodes.

Good = point indeed, sleepy nodes may miss the reception slots and appear = disconnected but as long as they are in the network they will eventually = get the CoJP Parameter Update Request and the new keys, assuming JRC = implements the default retransmission mechanism.

Mali=C5=A1a
= --Apple-Mail=_7BE6443C-2454-4135-B4BB-EE3E28B60DAD-- From nobody Fri Apr 5 14:10:34 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD3612061F; Fri, 5 Apr 2019 14:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUo1MMktluK2; Fri, 5 Apr 2019 14:10:18 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 49D2D120167; Fri, 5 Apr 2019 14:10:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,313,1549926000"; d="scan'208";a="377436729" Received: from unknown (HELO [192.168.1.138]) ([79.143.111.171]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2019 23:10:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= In-Reply-To: <31163.1554488119@localhost> Date: Fri, 5 Apr 2019 23:10:16 +0200 Cc: Marco Tiloca , 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <31107CBF-3BD5-4466-B837-F9F837340C68@inria.fr> References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> <31163.1554488119@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 21:10:32 -0000 > On 5 Apr 2019, at 20:15, Michael Richardson = wrote: >=20 > If we could delay the switch to the new schedule until *after* > COJP_REKEYING_GUARD_TIME has elapsed, then that might work. > Alternatively, if we could number the rekeys then a EB could signal = the > switch to the new schedule some time after the keys are changed. Not sure about that the exact switch after COJP_REKEYING_GUARD_TIME = would work, different nodes receive the new keys at different instants = so it would be hard to sync them. I like better the trigger with an EB, = it originates at 6LBR that is trusted and the frame can be authenticated = by the nodes that have installed the new keys. Mali=C5=A1a= From nobody Fri Apr 5 14:25:56 2019 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7410612016D; Fri, 5 Apr 2019 14:25:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: 6tisch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: 6tisch@ietf.org Message-ID: <155449955342.10004.14520865901363485250@ietfa.amsl.com> Date: Fri, 05 Apr 2019 14:25:53 -0700 Archived-At: Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-10.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 21:25:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG of the IETF. Title : Minimal Security Framework for 6TiSCH Authors : Malisa Vucinic Jonathan Simon Kris Pister Michael Richardson Filename : draft-ietf-6tisch-minimal-security-10.txt Pages : 49 Date : 2019-04-05 Abstract: This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and configures the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-10 https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 5 14:37:31 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE91202E3 for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 14:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56rFbWSdoAir for <6tisch@ietfa.amsl.com>; Fri, 5 Apr 2019 14:37:26 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 ACA6E1204BE for <6tisch@ietf.org>; Fri, 5 Apr 2019 14:37:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,313,1549926000"; d="scan'208";a="377438228" Received: from unknown (HELO [192.168.1.138]) ([79.143.111.171]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2019 23:37:23 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 5 Apr 2019 23:37:19 +0200 References: <155449955342.10004.14520865901363485250@ietfa.amsl.com> To: 6tisch <6tisch@ietf.org> In-Reply-To: <155449955342.10004.14520865901363485250@ietfa.amsl.com> Message-Id: <3EA73952-3DC8-4F69-B6C0-685441882776@inria.fr> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-10.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 21:37:31 -0000 Dear all, We have submitted the new version of the minimal-security draft fixing = the remaining issues that were brought during the 2nd WGLC and the = Prague meeting. In particular, this version: - Resolves the JRC failure issue by relying on the mechanism specified = in OSCORE Appendix B.2 - Revisits the CoJP error handling parameters to enable stateless = handling of CoJP requests by the JRC - Clarifies the network-wide rekeying process through separate sections = for 6LBR and 6LN handling Mali=C5=A1a > On 5 Apr 2019, at 23:25, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE = 802.15.4e WG of the IETF. >=20 > Title : Minimal Security Framework for 6TiSCH > Authors : Malisa Vucinic > Jonathan Simon > Kris Pister > Michael Richardson > Filename : draft-ietf-6tisch-minimal-security-10.txt > Pages : 49 > Date : 2019-04-05 >=20 > Abstract: > This document describes the minimal framework required for a new > device, called "pledge", to securely join a 6TiSCH (IPv6 over the > TSCH mode of IEEE 802.15.4e) network. The framework requires that > the pledge and the JRC (join registrar/coordinator, a central > entity), share a symmetric key. How this key is provisioned is out > of scope of this document. Through a single CoAP (Constrained > Application Protocol) request-response exchange secured by OSCORE > (Object Security for Constrained RESTful Environments), the pledge > requests admission into the network and the JRC configures it with > link-layer keying material and other parameters. The JRC may at any > time update the parameters through another request-response exchange > secured by OSCORE. This specification defines the Constrained Join > Protocol and its CBOR (Concise Binary Object Representation) data > structures, and configures the rest of the 6TiSCH communication = stack > for this join process to occur in a secure manner. Additional > security mechanisms may be added on top of this minimal framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-10 > = https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-1= 0 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-security-10 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Fri Apr 5 15:24:11 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E28120167; Fri, 5 Apr 2019 15:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LWZD-aq8ZIv; Fri, 5 Apr 2019 15:24:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CEF12011A; Fri, 5 Apr 2019 15:24:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C8DC838277; Fri, 5 Apr 2019 18:23:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 52C6317DA; Fri, 5 Apr 2019 18:24:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 502F6DF6; Fri, 5 Apr 2019 18:24:05 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FB=3FTWFsacWhYSBWdcSNaW5pxIc=3D=3F=3D?= cc: Marco Tiloca , 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org In-Reply-To: <31107CBF-3BD5-4466-B837-F9F837340C68@inria.fr> References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr> <31163.1554488119@localhost> <31107CBF-3BD5-4466-B837-F9F837340C68@inria.fr> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 22:24:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: >> If we could delay the switch to the new schedule until *after* >> COJP_REKEYING_GUARD_TIME has elapsed, then that might work. >> Alternatively, if we could number the rekeys then a EB could signal >> the switch to the new schedule some time after the keys are changed. > Not sure about that the exact switch after COJP_REKEYING_GUARD_TIME > would work, different nodes receive the new keys at different instants > so it would be hard to sync them. I like better the trigger with an E= B, > it originates at 6LBR that is trusted and the frame can be > authenticated by the nodes that have installed the new keys. So we need to add a permutation index to the key update that robust-scheduling provides, and then it needs to allocate a IE value. Oh: chairs, I think we should adopt this document. I know you didn't ask yet. I think it's useful enough to make it part of the base architecture! =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyn1YUACgkQgItw+93Q 3WW+Jgf/diM+FA0t8m5gdWAu/hAIFHh7rIm7RYela8ULowT1gndly+Rs1efG/QGh C0Aq3+kbPTD7iAECI/BfUW2w82Rl3x+wQzloVmhqHKGWWkjQLddKRXwZzT/EmEt1 5sXm0AwZm27punyT/1HvFOzRClkbk0qV+PUcdg6feUl8KdoY/FgY7wh+dUeZ/72q MUVoo2ftd/BsMiJzsqE6Jf6n9QXiZSB3kR77h+DGIpJCWyCH9cTYYxkvAFBl2i1Q dEhCLlhCMra4qp1wdjktxyxrhR5Wb9s0XJerhTfINdddbHLsKRZMW3Ywbee1QYZ7 qO7u3Z4o7RA00UlIe3tNErK+b75SVw== =Ma1J -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 7 02:57:58 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4272B120306 for <6tisch@ietfa.amsl.com>; Sun, 7 Apr 2019 02:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 21mZcdikhtUb for <6tisch@ietfa.amsl.com>; Sun, 7 Apr 2019 02:57:54 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C33120304 for <6tisch@ietf.org>; Sun, 7 Apr 2019 02:57:52 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 31C8140092; Sun, 7 Apr 2019 11:57:51 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7C13C26; Sun, 7 Apr 2019 11:57:44 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:dd7:4b5d:c66a:31ff]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9BBEE74; Sun, 7 Apr 2019 11:57:39 +0200 (CEST) Received: (nullmailer pid 857 invoked by uid 1000); Sun, 07 Apr 2019 09:57:25 -0000 Date: Sun, 7 Apr 2019 11:57:24 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Cc: 6tisch@ietf.org Message-ID: <20190407095639.GA24399@hephaistos.amsuess.com> References: <20190327172921.GA9348@hephaistos.amsuess.com> <20190328002907.GC28841@hephaistos.amsuess.com> <1CE26FD6-ACDB-4E95-A195-19953750FDD9@inria.fr> <20190405143235.GA7326@hephaistos.amsuess.com> <3E48D726-D39D-456A-9D4E-B15DAC0FE6CF@inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <3E48D726-D39D-456A-9D4E-B15DAC0FE6CF@inria.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 09:57:56 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 05, 2019 at 06:54:55PM +0200, Mali=C5=A1a Vu=C4=8Dini=C4=87 wro= te: > Let me know if it reads better. Looks good to me now, and also makes the distinction between "malformed" and "unsupported" clearer to me. Thanks Christian --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlypyVIACgkQOY0REtOk veFjQw/+OJSTYeZs41dEShaZPYZYXIDawU3eIQNCKf/kYM5gr5C/9AJBuBvPgbms FRfBTPpTph22HHnd0ysOiQbNvL8zOcyw3sV8g23jBG1fLa29l5SqLXdLPLwGFmqO HPehmTaXz037UmatAF7F2JFrHRDy2LHq9zaJoVTqK+7OinHuO0NJ3PO5OW8gD4BQ 1qfNnjLHa4CDfrtPhLS8Y6JMgcS07EfgMxrYwmNqvxEKfnD6/0r7JcKnXqX//go8 8ME8AIdIYy3iDXLPlqrc8HqZwbUl825BZyJjfq+tc0lwqK+xCvyJeJngdTspDtTR 0xRVuyT+DfBPy8RQf9+GTogYupycW8J4SjGk4XKwjkY+bkxtOPMy9QR19FS6a+BM zg3CjX5CzEiRRFzwqFbesNoN+Ce7esi63oBx+wTPLp8cSrke1e8DEc9yyk1JJICz x3GHnHJD4mtVbjef96NDXkA/A/vqtlRWzjEq46+Cb/ihyqWopxGZGvXOgrmfUGyP uFNSuoY6Ffgjj+ieUZ4BXkkGSkaHAhVrqj66trfafZ0nPbWActYLo+8JTkWy32gc BjQOUlHrfpbSO8xXJBeYxfonamK3CbaYlbc3BU6jRTuyNpTGyi5beMCcSoYTewVx VkO+/90ZDSM+JUYjh8QPLSnjj42SdYV4FN+PCWht7ExctoSRYBQ= =tQby -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From nobody Mon Apr 8 20:56:18 2019 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A70120292; Mon, 8 Apr 2019 20:56:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: 6tisch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: 6tisch@ietf.org Message-ID: <155478217633.30185.18164105197372994636@ietfa.amsl.com> Date: Mon, 08 Apr 2019 20:56:16 -0700 Archived-At: Subject: [6tisch] I-D Action: draft-ietf-6tisch-msf-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 03:56:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG of the IETF. Title : 6TiSCH Minimal Scheduling Function (MSF) Authors : Tengfei Chang Malisa Vucinic Xavier Vilajosana Simon Duquennoy Diego Dujovne Filename : draft-ietf-6tisch-msf-03.txt Pages : 18 Date : 2019-04-08 Abstract: This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6tisch-msf-03 https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-msf-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-msf-03 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 Apr 8 21:06:42 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571D21202AF for <6tisch@ietfa.amsl.com>; Mon, 8 Apr 2019 21:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI1GCitz7kcU for <6tisch@ietfa.amsl.com>; Mon, 8 Apr 2019 21:06:38 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 C08C312004B for <6tisch@ietf.org>; Mon, 8 Apr 2019 21:06:38 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id w25so7434684pfi.9 for <6tisch@ietf.org>; Mon, 08 Apr 2019 21:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JAvqlqoh2q2v2CDMTY+Mcm8Bwu4vSZew2rv0P9i13UA=; b=QMvHYdiFKDoPyPRy0NkFkbL2at2kNllY5QgfP1+c5OmvyAX6UEyqKb+3Xhf7eciuFa BQnFk26aJvyAe60ZPcyI+8wGMGPayj5IO8HP6In03Ewc5khJ+8ogQB0GOCHAjdPMvywA MHDRAgJaFZ9y8+j64CQo7Nf99xaEz07geMXsr/wnF4VvlQNtCjjqcq0VGLwbchaj8bIg OZtfRNatwfRzl76CFErSP9uhrJi3aBXiBCykjp6o7HtNxCX4ZCRqqLkePB3JieZukhaB o3m4d1CBoD832o1riZAZ88rSv/CwuXyvhV30wBFoj+CAxqePhazLRuw2lAoNPI0FpAbp l9CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JAvqlqoh2q2v2CDMTY+Mcm8Bwu4vSZew2rv0P9i13UA=; b=ZgPHC1QjwGNYSO/P+6oAJ3DxDZLL+6OtYjVok7xirnR9jMWCd3wm55KqFMA8C2jJr+ YW6vpOBBOYP4v3WFO/TQ8PK7HwIpuEUJL06B6eiui06UlL4QWNb9yuhSjdr16DRMjECS Me3FcGe1ap+bvKbcrR/gt6HoQxRql9F0M9L+4jjyQxMtiBJdIFr+Ypv/sUijHlfNsrjt BrgJpaSPlB5Ygeh1O93XAk/2/tC8nKl9i8zvrTha6ADLd2nC1cqxgVP+gcAzuwIXwDJF f8MyVDlNW0TmPRDWIlixN6aSdwg3m03tgmUf/gBSE3ZQHGnhVQBI6VbGaTwBP1byWUem 3B/Q== X-Gm-Message-State: APjAAAWYJAknhUIBDX6fEEqyTPXJKoQY0C/tZj2lF0l0W+DjJBbTwTn2 aY48+oCUbFtUX5oh/fyJVp8d08rm4Zl2XjIxKKLX5P/P9ikj+Q== X-Google-Smtp-Source: APXvYqw4NQyYMvfIxSnr5EwOvWdnD3jtKNDRNhx0RvrbBxd0EJ+p6uKO0D0kFCX2jBlnu6e0bEdsZUQRInGJuJojZ1A= X-Received: by 2002:a63:fb4d:: with SMTP id w13mr5888430pgj.397.1554782797839; Mon, 08 Apr 2019 21:06:37 -0700 (PDT) MIME-Version: 1.0 From: Tengfei Chang Date: Mon, 8 Apr 2019 21:06:26 -0700 Message-ID: To: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e421d05861114bb" Archived-At: Subject: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 04:06:40 -0000 --0000000000005e421d05861114bb Content-Type: text/plain; charset="UTF-8" Dear all, A new version of "draft-ietf-6tisch-msf" is just published at here: https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt This version mainly resolved the issues presented during IETF 104 meeting. I would like to mention one of the main changes in this version is we removed the frame pending bit feature. It's for two reasons: - it will influence the "adapt to traffic" strategy of MSF. - the "adapt to traffic" strategy has the ability to handle burst traffic by using a smaller MAX_NUMCELLS Now we are calling for reviews on the new version of MSF! Any comments and feedback are appreciated! Tengfei -- Chang Tengfei, Postdoctoral Research Engineer, Inria --0000000000005e421d05861114bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

A new versio= n of "draft-ietf-6tisch-msf" is just published at here:=C2=A0https://www.ie= tf.org/id/draft-ietf-6tisch-msf-03.txt

This ve= rsion mainly resolved the issues presented during IETF 104 meeting.
I would like to mention one of the main changes in this version is we re= moved the frame pending bit feature.

It's for = two reasons:
- it will influence = the "adapt to traffic" strategy of MSF.
- the "adapt to traffic" strategy has the ability to = handle burst traffic by using a smaller MAX_NUMCELLS

Now we are calling for reviews on the new version of MSF!=C2=A0
Any comments and feedback are appreciated!

Tengfei



--
= Chang Teng= fei,
Postdoctora= l Research Engineer, Inria
--0000000000005e421d05861114bb-- From nobody Tue Apr 9 02:39:58 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F58A1203CD for <6tisch@ietfa.amsl.com>; Tue, 9 Apr 2019 02:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v4UPCksVTtz for <6tisch@ietfa.amsl.com>; Tue, 9 Apr 2019 02:39:53 -0700 (PDT) Received: from smr1.u-strasbg.fr (smr1.u-strasbg.fr [130.79.222.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2551B1202D8 for <6tisch@ietf.org>; Tue, 9 Apr 2019 02:39:52 -0700 (PDT) Received: from local-mr.u-strasbg.fr (lmr3.u-strasbg.fr [172.30.21.3]) by smr1.u-strasbg.fr (Postfix) with ESMTP id DF37460601; Tue, 9 Apr 2019 11:39:48 +0200 (CEST) Received: from local-mr.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id B2F431AC; Tue, 9 Apr 2019 11:39:48 +0200 (CEST) Received: from minet.u-strasbg.fr (minet.u-strasbg.fr [130.79.91.198]) (Authenticated sender: theoleyre) by lmr3.u-strasbg.fr (Postfix) with ESMTPSA id 78CC6B2; Tue, 9 Apr 2019 11:39:46 +0200 (CEST) From: Fabrice Theoleyre Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7C184DC9-5700-42EC-A5B0-CF7ECBABED3D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 9 Apr 2019 11:39:46 +0200 In-Reply-To: Cc: 6tisch@ietf.org To: Tengfei Chang References: X-Mailer: Apple Mail (2.3445.104.8) X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 09:39:57 -0000 --Apple-Mail=_7C184DC9-5700-42EC-A5B0-CF7ECBABED3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Tengfei,=20 Please find below my review of the draft. I isolated the corresponding = blocks, and inserted my comments after 'FT>' The draft is very well written, and I have mostly minor comments. Great job! Best regards, Fabrice =E2=80=94=E2=80=94=E2=80=94=E2=80=94 an implementor MAY implements MSF FT> an implementor MAY implement MSF FT> I=E2=80=99m also a little bit confused. The section describes how to = use the shared FT> cell of Minimal 6TISCH. If Minimal 6TISCH is not used, how does the FT> scheme work? Shouldn=E2=80=99t some minimum requirements be FT given = here? =E2=80=94=E2=80=94=E2=80=94 These cells are called 'autonomous cells', because they are maintained = autonomously=20 by each node. =20 FT> I find the term =E2=80=98autonomous=E2=80=99 quite misleading, since = manage cells are FT> also negotiated autonomously (without any controller). I would = rather use FT> something else like =E2=80=98pseudo-random=E2=80=99.=20 FT> or rename the 'managed cells' in =E2=80=99negotiated cells=E2=80=99? =E2=80=94=E2=80=94=E2=80=94 There are other optional parameters defined in SAX determines the = performance of SAX hash function. =20 FT> Other optional parameters defined in SAX FT> determine the performance of SAX hash function. =E2=80=94=E2=80=94=E2=80=94 The AutoUpCell with the most packets in the outgoing queue takes precedence. FT> does a node has several upstream cells? I would have thought FT> that a single upstream cell exists (or you consider multiple = parents?) =E2=80=94=E2=80=94=E2=80=94 Autonomous Downstream Cell (AutoDownCell), one cell at a [slotOffset,channelOffset] computed as a hash of its own EUI64 (detailed next). Its cell options bits are assigned as TX=3D1, RX=3D1, SHARED=3D0. FT> I would have explained here the role of this cell (i.e. receiving FT> control packets from any neighbor), and similarly for the upstream = cell. FT> I conjecture it may be quite hard for the reader to understand FT> their purpose =E2=80=94=E2=80=94=E2=80=94 6P RELOCATE Request frames to the node's RPL routing child MUST be sent on AutoDownCell. FT> What about 6P RELOCATE request to the parent? Can only a parent FT> relocate a cell with 6P?=20 =E2=80=94=E2=80=94=E2=80=94 Join Response packets and 6P ADD/DELETE Response frames to the pledge or its RPL routing child MUST be sent on AutoDownCell. FT> does this mean that a cell MUST be inserted in the schedule FT> for each child (or after the reception of a Join-req)? Or can FT> a node send a packet through a cell not registered in its schedule? =E2=80=94=E2=80=94=E2=80=94 A node implementing MSF MUST implement the Minimal Security Framework for 6TiSCH=20 FT> In contradiction with section 2 'MAY implements MSF without = implementing FT> Minimal 6TiSCH Configuration.' =E2=80=94=E2=80=94=E2=80=94 The section 4 is particularly clearly, explaining well the =E2=80=98flow=E2= =80=99 when a device joins the network =E2=80=94=E2=80=94=E2=80=94 While autonomous cells have a dedicated section (2), managed cells are = not described.=20 In particular, are they bidirectional, shared, etc.? =E2=80=94=E2=80=94=E2=80=94 NumCellsUsed: Counts the number of managed cells that have been used. This counter is initialized at 0. NumCellsUsed is incremented by exactly 1 when, during a managed cell to the preferred parent, either of the following happens: =20 [=E2=80=A6]=20 * The node receives a frame from its preferred parent. FT> Let assume a cell is shared, and is only used to receive packets. FT> Because of a bad PDR, we have many retransmissions. The receiver=20 FT> implements the counter only when the cell is decoded. It may decide FT> to DELETE this cell.=20 FT> Doesn=E2=80=99t it? FT> Shouldn=E2=80=99t the description consider separately the SHARED and = NON-SHARED FT> cases?=20 =E2=80=94=E2=80=94=E2=80=94 1. if there is managed cell conflicted with the AutoUpCells to be installed, the node MUST issue a 6P RELOCATE command to relocate the conflicted cell FT> When is the AutoUpCells installed? After the 6P RELOCATE RESPONSE? FT> Before, and the AutoUpCells has the priority?=20 =E2=80=94=E2=80=94=E2=80=94 That is, for example, from NumTx=3D256 and NumTxAck=3D128, they become NumTx=3D128 and NumTxAck=3D64. This = operation does not change the value of the PDR, but allows the counters to keep incrementing. FT> yes, but it increases the convergence time. For instance, a burst of FT> packets is dropped at the beginning (i.e. during convergence, with=20= FT> many collisions). Then, everything is fine. The PDR will take a long = time FT> to reflect the actual PDR. The cell may be RELOCATED erroneously. FT> (the collision may have been solved meanwhile by the conflicting = link) FT> Is it something you considered? =E2=80=94=E2=80=94=E2=80=94 towards it preferred parent FT> towards its preferred parent=20 =E2=80=94=E2=80=94=E2=80=94 is calcualted as ((2^MAXBE)-1)*SLOTFRAME_LENGTH, where: FT>is calculated as =20 =E2=80=94=E2=80=94=E2=80=94 MAXEB is the maxmium backoff exponent is used FT> MAXBE is the maximum backoff exponent used (3 errors)=20 =E2=80=94=E2=80=94=E2=80=94 >=20 > Le 9 avr. 2019 =C3=A0 06:06, Tengfei Chang a = =C3=A9crit : >=20 > Dear all, >=20 > A new version of "draft-ietf-6tisch-msf" is just published at here: = https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt = >=20 > This version mainly resolved the issues presented during IETF 104 = meeting. > I would like to mention one of the main changes in this version is we = removed the frame pending bit feature. >=20 > It's for two reasons: > - it will influence the "adapt to traffic" strategy of MSF. > - the "adapt to traffic" strategy has the ability to handle burst = traffic by using a smaller MAX_NUMCELLS >=20 > Now we are calling for reviews on the new version of MSF!=20 > Any comments and feedback are appreciated! >=20 > Tengfei >=20 >=20 >=20 > --=20 > Chang Tengfei, > Postdoctoral Research Engineer, Inria > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --Apple-Mail=_7C184DC9-5700-42EC-A5B0-CF7ECBABED3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Tengfei, 

Please find below my review of the = draft. I isolated the corresponding blocks, and inserted my comments = after 'FT>'

The draft is very well written, and I have mostly minor = comments.
Great job!

Best regards,
Fabrice


=E2=80=94=E2=80=94=E2=80=94= =E2=80=94


an implementor MAY implements = MSF

FT> an implementor = MAY implement MSF

FT> I=E2=80=99m also a little bit confused. The section = describes how to use the shared
FT>  cell = of Minimal 6TISCH. If Minimal 6TISCH is not used, how does the
FT> scheme work? Shouldn=E2=80=99t some minimum = requirements be FT given here?

=E2=80=94=E2=80=94=E2=80=94

These cells are called =  'autonomous cells', because they are maintained = autonomously 
by each node.  

FT> I find the term = =E2=80=98autonomous=E2=80=99 quite misleading, since manage cells = are
FT> also negotiated autonomously (without = any controller). I would rather use
FT> = something else like =E2=80=98pseudo-random=E2=80=99. 
FT> or rename the 'managed cells' in =E2=80=99negotiated = cells=E2=80=99?

=E2=80=94=E2=80=94=E2=80=94

There = are other optional parameters defined in SAX determines the performance = of SAX hash function.
 
FT> Other optional parameters defined in SAX
FT>  determine the performance of SAX hash = function.

=E2=80=94=E2=80=94=E2=80=94

The = AutoUpCell with the most packets in the outgoing queue takes
      precedence.
FT> does a node has several = upstream cells? I would have thought
FT> that a = single upstream cell exists (or you consider multiple = parents?)

=E2=80=94=E2=80=94=E2=80=94

Autonomous Downstream Cell (AutoDownCell), one cell at = a
      [slotOffset,channelOffset] = computed as a hash of its own EUI64
    =   (detailed next).  Its cell options bits are assigned as = TX=3D1,
      RX=3D1, = SHARED=3D0.

FT> I would have explained here the role of this cell = (i.e. receiving
FT> control packets from any = neighbor), and similarly  for the upstream cell.
FT> I conjecture it may be quite hard for the reader to = understand
FT> their purpose

=E2=80=94=E2=80=94=E2=80=94=

 6P RELOCATE Request frames to the node's RPL routing = child MUST be
      sent on = AutoDownCell.

FT> What about 6P RELOCATE request to the = parent? Can only a parent
FT> relocate = a cell with 6P? 

=E2=80=94=E2=80=94=E2=80=94

Join = Response packets and 6P ADD/DELETE Response frames to the
      pledge or its RPL routing child MUST be = sent on AutoDownCell.

FT> does this mean that a cell MUST be = inserted in the schedule
FT> for each child (or = after the reception of a Join-req)? Or can
FT> a = node send a packet through a cell not registered in its = schedule?

=E2=80=94=E2=80=94=E2=80=94

 A node = implementing MSF MUST implement the Minimal Security Framework
   for 6TiSCH 

FT> In contradiction with section 2 = 'MAY implements MSF without implementing
FT> = Minimal 6TiSCH Configuration.'

=E2=80=94=E2=80=94=E2=80=94=

The = section 4 is particularly clearly, explaining well the =E2=80=98flow=E2=80= =99 when a device joins the network

=E2=80=94=E2=80=94=E2=80=94=

While = autonomous cells have a dedicated section (2), managed cells are not = described. 
In particular, are they = bidirectional, shared, etc.?

=E2=80=94=E2=80=94=E2=80=94=

NumCellsUsed:  Counts the number of managed cells that = have been
       used. =  This counter is initialized at 0.  NumCellsUsed is
       incremented by exactly 1 when, = during a managed cell to the
      =  preferred parent, either of the following happens:
   
[=E2=80=A6] 

   *  The = node receives a frame from its preferred parent.

FT> Let assume a cell is shared, and = is only used to receive packets.
FT> Because of a bad PDR, we have many retransmissions. = The receiver 
FT> implements the counter = only when the cell is decoded. It may decide
FT> = to DELETE this cell. 
FT> Doesn=E2=80=99= t it?

FT> = Shouldn=E2=80=99t the description consider separately the SHARED and = NON-SHARED
FT> cases? 

=E2=80=94=E2=80=94=E2=80=94=

1.  if there is managed cell conflicted with the = AutoUpCells to be
      =  installed, the node MUST issue a 6P RELOCATE command to = relocate
       the conflicted = cell

FT> When is the AutoUpCells installed? After the 6P = RELOCATE RESPONSE?
FT> Before, and the = AutoUpCells has the priority? 

=E2=80=94=E2=80=94=E2=80=94
That is, for example, from NumTx=3D256 = and
   NumTxAck=3D128, they become = NumTx=3D128 and NumTxAck=3D64.  This operation
   does not change the value of the PDR, but allows = the counters to keep
  =  incrementing.

FT> yes, but it increases the convergence time. For = instance, a burst of
FT> packets is dropped at = the beginning (i.e. during convergence, with 
FT> many collisions). Then, everything is = fine. The PDR will take a long time
FT> to = reflect the actual PDR. The cell may be RELOCATED erroneously.
FT> (the collision may have been solved meanwhile by the = conflicting link)

FT> Is it something you considered?
=E2=80=94=E2=80=94=E2=80=94
towards it preferred parent

FT> towards its = preferred parent 

=E2=80=94=E2=80=94=E2=80=94=

is calcualted as
  =  ((2^MAXBE)-1)*SLOTFRAME_LENGTH, where:

FT>is calculated = as
 
=E2=80=94=E2=80=94=E2=80=94

MAXEB is the maxmium backoff exponent = is used

FT> MAXBE is the maximum backoff exponent = used
(3 errors) 

=E2=80=94=E2=80=94=E2=80=94=





Le 9 avr. 2019 =C3=A0 06:06, Tengfei Chang <tengfei.chang@gmail.com> a =C3=A9crit :

Dear all,

A new version of = "draft-ietf-6tisch-msf" is just published at here: https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt
<= div class=3D"">
This version mainly = resolved the issues presented during IETF 104 meeting.
I would like to mention one of the main changes in this = version is we removed the frame pending bit feature.

It's for two = reasons:
- it will = influence the "adapt to traffic" strategy of MSF.
- the "adapt to traffic" strategy has the ability to handle = burst traffic by using a smaller MAX_NUMCELLS

Now we are calling for = reviews on the new version of MSF! 
Any = comments and feedback are appreciated!

Tengfei



--
Chang= Tengfei,
Postdoctoral = Research Engineer, = Inria
_______________________________________________
6tisch = mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

= --Apple-Mail=_7C184DC9-5700-42EC-A5B0-CF7ECBABED3D-- From nobody Tue Apr 9 04:06:31 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432671203C5 for <6tisch@ietfa.amsl.com>; Tue, 9 Apr 2019 04:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WckEh4VFYPuN for <6tisch@ietfa.amsl.com>; Tue, 9 Apr 2019 04:06:27 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 3E8491200D8 for <6tisch@ietf.org>; Tue, 9 Apr 2019 04:06:27 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id w10so20343440wrm.4 for <6tisch@ietf.org>; Tue, 09 Apr 2019 04:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mLFG71twL7g91+ZUM6RBt/MsLR9sFZQPEafEnPGH7Oc=; b=NG1zLBAhXR0ijinrY+ycok149sVcwF8nPoBJ2xp2Ej/hPNM8oIjceBo2kuRwrmXPvk MCLnmRueqnAkyL+mAteM6SieDe1gHuN9gROQY7HWs3Wyl942X+vu0X+Mu5hZaj4E/X0C ifTQMZB9FmVYqSdlAp9In094cLbbufxrqIpGySFD4aiV2Ju86w9BnT5RYDH6I8tzNmdT /9snugcg07qL5b7D9hTIZa7agVebCxZArtfmFcJ7JhFliwqfU6dtZKYC/3uqAuya5QW8 XVmqa5YEKfKRLoVSDE8GmPNOobjMMu3Ri9EDZKEAsLekGU4gU2eMdZfLpC8vNmYkJk2t a0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mLFG71twL7g91+ZUM6RBt/MsLR9sFZQPEafEnPGH7Oc=; b=VOGSPXYdz49bYyWnCNTnhR7NdFdxMTz+AtHJ7+HGCpZxBwM9l6ATvnfdj/UE8MxNUg pXkJR9reP56EuLDe7TTKyTupJd9mh536cGZw49TxtUWSM6w4VFWaF+gr4gF9ZMa3wSlz BhYgcz7O41IImfJRw4wTni7gOKEq8TWHP0Zc5dI6oliMv6xYb/XsA/HA0g9GJu0EI+qq K+YjWgaPt5utGCwAZY/yZA4Nw9JBWlTu408NbRxA7loPloKXKS3RKCj2BewdxbBtw2lf ZPyQvmZICFGli3xQ5fYFMzBTXL51dbxStWxlzZiarUOzcwzdGDGyGJqgB0YiW+L4qoRf vijw== X-Gm-Message-State: APjAAAUaWzpfPZecGPxDNY+awB+Q0OUGWRZ6dmvmiS9UlPzJ+3AhGQsn q5o6i2KHqtbdqG9BkpbHBCI6nEkt/2y5DdB16hM= X-Google-Smtp-Source: APXvYqyM39FNc/qUA2Lhf0ZZJ3RUPX8j7TPa6AdiytNy8sO0IX4Zy6TwncDbzIPtWhqRNJ4nO7LE7nt66SK+sJ4BpkU= X-Received: by 2002:a5d:69c2:: with SMTP id s2mr21887090wrw.83.1554807985711; Tue, 09 Apr 2019 04:06:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Atis Elsts Date: Tue, 9 Apr 2019 14:06:13 +0300 Message-ID: To: Tengfei Chang Cc: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="000000000000aeafe1058616f113" Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 11:06:29 -0000 --000000000000aeafe1058616f113 Content-Type: text/plain; charset="UTF-8" Hello Tengfei and the 6tisch community, I'm happy to see the frame pending bit removed and other big improvements in clarity and functionality. Following up on my other previous comments, - There is still one reference left to the number 16 as the max number of channels (which 2.4 GHz frequency-band-specific). It's in the formula `channelOffset(MAC) = hash(EUI64, 16)`. This may conflict with the intention expressed previously in the text, where you say that "the coordinates are computed to distribute the cells across all channel offsets" (i.e. not exactly 16 channel offsets) - Have you considered suggesting that the implementers to prioritize 6top packets over data packets? - Have you considered providing a recommended value for MAX_NUMCELLS or discussing how to select it? Minor new comments: - The parameter KA_PERIOD from the recommended values is not referenced in the main text. - There are a number of typos in the text, for example: Boradcast -> Broadcast maxmium -> maximum calcualted -> calculated bewteen -> between Best regards, Atis On Tue, Apr 9, 2019 at 7:06 AM Tengfei Chang wrote: > Dear all, > > A new version of "draft-ietf-6tisch-msf" is just published at here: > https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt > > This version mainly resolved the issues presented during IETF 104 meeting. > I would like to mention one of the main changes in this version is we > removed the frame pending bit feature. > > It's for two reasons: > - it will influence the "adapt to traffic" strategy of MSF. > - the "adapt to traffic" strategy has the ability to handle burst traffic > by using a smaller MAX_NUMCELLS > > Now we are calling for reviews on the new version of MSF! > Any comments and feedback are appreciated! > > Tengfei > > > > -- > Chang Tengfei, > Postdoctoral Research Engineer, Inria > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Dr. Atis Elsts Researcher, Institute of Electronics and Computer Science (EDI) Dzerbenes str. 14, Riga, LV-1006 --000000000000aeafe1058616f113 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Tengfei and the 6t= isch community,

I'm happy to see the frame pending bit removed a= nd other big improvements in clarity and functionality.

Following up= on my other previous comments,
- There is still one reference left to t= he number 16 as the max number of channels (which 2.4 GHz frequency-band-sp= ecific). It's in the formula `channelOffset(MAC) =3D hash(EUI64, 16)`. = This may conflict with the intention expressed previously in the text, wher= e you say that "the coordinates are computed to distribute the cells= across all channel offsets" (i.e. not exactly 16 channel offsets)
=
- Have you considered suggesting that the implemente= rs to prioritize 6top packets over data packets?
- Have you considered p= roviding a recommended value for MAX_NUMCELLS or discussing how to select i= t?

Minor new comments:

- The parameter KA_PERIOD from the rec= ommended values is not referenced in the main text.

- There are a nu= mber of typos in the text, for example:
=C2=A0Boradcast -> Broadcast<= br>=C2=A0maxmium -> maximum
=C2=A0calcualted -> calculated
=C2= =A0bewteen -> between

Best regards,=
Atis



On Tue, Apr 9, 2019 = at 7:06 AM Tengfei Chang <tengfei.chang@gmail.com> wrote:
Dea= r all,

A new version of "draft-ietf-6tisch-msf"= ; is just published at here:=C2=A0https://www.ietf.org/id/draft-iet= f-6tisch-msf-03.txt

This version mainly resolv= ed the issues presented during IETF 104 meeting.
I would like to = mention one of the main changes in this version is we removed the frame pen= ding bit feature.

It's for two reasons:
<= div>
- it will influence the "adapt to = traffic" strategy of MSF.
- the &= quot;adapt to traffic" strategy has the ability to handle burst traffi= c by using a smaller MAX_NUMCELLS

Now we are= calling for reviews on the new version of MSF!=C2=A0
Any comment= s and feedback are appreciated!

Tengfei
=


--
Chang Tengfei,
=
Postdoctoral Research Engineer, Inria
<= /font>
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

--
Dr. Atis Elsts=
Researcher, Institute of Electronics and Computer Science (EDI)<= br>
Dzerbenes str. 14, Riga, LV-1006
=C2=A0
--000000000000aeafe1058616f113-- From nobody Tue Apr 9 05:03:13 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C5C1207B3 for <6tisch@ietfa.amsl.com>; Tue, 9 Apr 2019 05:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFME8eQWUUjF for <6tisch@ietfa.amsl.com>; Tue, 9 Apr 2019 05:03:00 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 422E21207B5 for <6tisch@ietf.org>; Tue, 9 Apr 2019 05:03:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,329,1549926000"; d="scan'208";a="377854131" Received: from wifi-pro-83-062.paris.inria.fr (HELO [128.93.83.62]) ([128.93.83.62]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 09 Apr 2019 14:02:58 +0200 From: Yasuyuki Tanaka To: 6tisch@ietf.org Cc: yasuyuki.tanaka@inria.fr References: Message-ID: Date: Tue, 9 Apr 2019 14:02:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [6tisch] Review of draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 12:03:12 -0000 Thank you, the authors! I confirmed most of my comments to the previous version have been addressed. It reads better :-) Here are my comments: two comments are major, the rest are minor. [major: usage of the autonomous cell and the managed cell] The draft specifies rules what type of frames MUST be sent over the autonomous cell. How can we implement the rules on top of TSCH MAC defined by IEEE802.15.4? https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 draft-03> The traffic on the autonomous cells are scheduled as: draft-03> draft-03> o Join Request packets and 6P ADD/DELETE Request frames to the draft-03> node's Join Proxy or its RPL routing parent MUST be sent on draft-03> AutoUpCell. draft-03> o Join Response packets and 6P ADD/DELETE Response frames to the draft-03> pledge or its RPL routing child MUST be sent on AutoDownCell. draft-03> o 6P RELOCATE Request frames to the node's RPL routing child MUST be draft-03> sent on AutoDownCell. draft-03> o 6P RELOCATE Response frames to its RPL routing parent MUST be sent draft-03> on AutoUpCell. https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 draft-03> Adding/removing/relocating cells involves exchanging frames that draft-03> contain 6P commands. All 6P Request frames to its parent MUST be draft-03> sent on the AutoUpCell All 6P Response frames to non-parent neighbor draft-03> MUST be sent on AutoDownCell. At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell to the same neighbor are used without distinction. This is totally fine and straightforward. Why do we need the change to this part? https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1 draft-02> Autonomous cells are used indistinguishably draft-02> together with dedicated cells, for broadcast or unicast traffic with draft-02> the target neighbor. The procedure to remove autonomous cells is draft-02> described in Section 3. To my understandings, TSCH MAC selects a cell (link) to transmit a frame seeing macTxType, macLinkType, and macNodeAddress of the cell, which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC cares only the destination MAC address and the frame type of a TX frame, doesn't it? [major: some confusions in Section 5] We don't need to maintain NumCellsElapsed and NumCellsUsed for RX cells because managed cells have always only TX=1. https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 draft-03> NumCellsElapsed : Counts the number of managed cells that have draft-03> elapsed since the counter was initialized. This counter is draft-03> initialized at 0. Each time the TSCH state machine indicates draft-03> that the current cell is a managed cell to the preferred parent, draft-03> NumCellsElapsed is incremented by exactly 1, regardless of draft-03> whether the cell is used to transmit/receive a frame. "to transmit/receive a frame" in the last sentence should be replaced with "to transmit a frame", and draft-03> Both NumCellsElapsed and NumCellsUsed counters can be used to cell draft-03> with cell option TX=1 or RX=1. "with cell option TX=1 or RX=1" should be replaced with "with cell option TX=1"? Another thing is related to what Fabrice pointed out. There is something wrong in text about the RELOCATE operation. Since NumTx and NumTxAck are the key counters for the RELOCATE operation, a RELOCATE request is never issued for an RX cell. Then, the direction in the following text is opposite... https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 draft-03> o 6P RELOCATE Request frames to the node's RPL routing child MUST be draft-03> sent on AutoDownCell. draft-03> o 6P RELOCATE Response frames to its RPL routing parent MUST be sent draft-03> on AutoUpCell. One more thing: https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3 draft-03> 4. For any other cell, it compares its PDR against that of the cell draft-03> with the highest PDR. If the different is less than draft-03> RELOCATE_PDRTHRES, it triggers the relocation of that cell using draft-03> a 6P RELOCATE command. - s/different/difference/ - s/less than/larger than/ ?? Can you check the entire text in Section 5? [minor comment #1] https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-2 draft-03> For example, a Trickle Timer defined in [RFC6550] MAY be draft-03> applied on DIOs. Do we need "MAY" here? If you implement RFC6550, DIO is automatically controlled by Trickle Timer. [minor comment #2] https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 draft-03> MUST use the hash function SAX [SAX-DASFAA]. The coordinates are draft-03> computed to distribute the cells across all channel offsets, and all draft-03> but the first time offsets of Slotframe 1. The first time offset is draft-03> skipped to avoid colliding with the minimal cell in Slotframe 0. s/time offset/slot offset/ [minor comment #3] https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 draft-03> o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) draft-03> o channelOffset(MAC) = hash(EUI64, 16) draft-03> draft-03> The second input parameter defines the maxmium return value of the draft-03> hash function. The second input should be "the maximum return value plus 1", which is the parameter 'T' of SAX. https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#appendix-B draft-03> In MSF, the T is replaced by the length slotframe 1. String s is draft-03> replaced by the mote EUI64 address. The characters of the string c0, draft-03> c1, ..., c7 are the 8 bytes of EUI64 address. This may be misleading. The first sentence could be... For slotOffset(), T is the length of the slotframe 1. For channelOffset(), T is the number of available channels. [minor comment #4] https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 draft-03> The second input parameter defines the maxmium return value of the draft-03> hash function. There are other optional parameters defined in SAX draft-03> determines the performance of SAX hash function. Those parameters draft-03> could be broadcasted in EB frame or pre-configured. What parameters...? The parameters to configure are be h0, l_bit, and r_bit, I believe. By the way, s/maxmium/maximum/ [minor comment #5] https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 draft-03> Implementors MAY choose to create the same counters for each draft-03> neighbor, and add them as additional statistics in the neighbor draft-03> table. https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3 draft-03> Implementors MAY choose to maintain the same counters for each draft-03> managed cell in the schedule. For what purposes? Do we need these sentences? [minor comment #6] Want to have test vectors of SAX! :-) [minor comment #7] https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 draft-03> * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a draft-03> single cell to the preferred parent draft-03> * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a draft-03> single cell to the preferred parent It would be better to put "managed" there: proposed> * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a proposed> single managed cell to the preferred parent proposed> * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a proposed> single managed cell to the preferred parent [minor comment #8] s/Tx Cell/TX cell/ s/Tx cell/TX cell/ Best, Yatch From nobody Wed Apr 17 04:57:36 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5635112035B for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 04:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xR10P2DHXwf for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 04:57:31 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 6DD64120092 for <6tisch@ietf.org>; Wed, 17 Apr 2019 04:57:31 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id n8so11920106plp.10 for <6tisch@ietf.org>; Wed, 17 Apr 2019 04:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5XGr/R2p4nW4/42IEkLWtrqKwH+s62qD6nUKBKoCI9Q=; b=JRygQBkTICQWR9+L0ttS9gbcwRadDg/ODXgY7h7hpmVdOvhLnzRxLYAWWpNQ7Yz7c2 lDr253H3CC/gLyacz6ODxIM2oMS5BPqevxSiuGErHdTl0EILXiirg19L/1U3AlA1P1Xr LkLhE9yQX41OY0V3Hx1/kaUuklYAIETzoLSomL8Ao0NrOXm7HNpwQmr8IzVqBN9lCtgB L5F7nP+6WlaJCYq6W3xNOIXK0mxBN0PBOCpBTCbJ58+NkM+i6bU0/xQPBhH+FbVHv0JK MTDpu+5YS5gZVsHEbogMeJ+XlO3qVgaFgp9H3/d/quNDuzSxGT3Tgv2py9CpA20yQ6DV VG0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5XGr/R2p4nW4/42IEkLWtrqKwH+s62qD6nUKBKoCI9Q=; b=QK4h9+2RSvP6mSjc+BtIxc3WhftQgfuUpY+G1zWn7qoEqvtmUk1Ett92IUOABMr40r k1U+u3iIjdJiDtajkaHWmq1NfCPFRdcBzBWCcWRqmGqqpj2dOqz7Mp1RRlsVohRncOMO id0vYENGGGBwKZ/WKGxmYueGbrpWesCrqig9oG8PkcWq/YeFhvsbZFw5IWrGoc3d9vQq RcRD05XAB0nl2yOvnzIHsmMoP2wAr+0T6Q5kVtuhdoCvbggEZa5lh6ODkdQ91OpRivNC SlYmefhpiwkZov9bk3lxj9gxpJVU+e6GAyNwRgqIJwJthBp6CtyP1wf8pSLBo+e2laff kP3Q== X-Gm-Message-State: APjAAAVu78c/8iUVA8wjBpcAZrKyjzTEAO7cFcYjA8vJVEEAaIhPfUpt U6y1FuOoxfDjGZe9ebF7KULWtMjVENgjGMV/khs= X-Google-Smtp-Source: APXvYqxKjHyLbilULDrS4IQXpq7gi/TBlYYNJUYYelWS6GkeCaWmorGllKr9BKRypHB9237uPH3Fs6D/vl3zzk8kDzc= X-Received: by 2002:a17:902:29:: with SMTP id 38mr65786637pla.178.1555502250710; Wed, 17 Apr 2019 04:57:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Wed, 17 Apr 2019 13:57:17 +0200 Message-ID: To: Fabrice Theoleyre Cc: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="00000000000019df000586b89793" Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 11:57:34 -0000 --00000000000019df000586b89793 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabrice, Thanks a lot for your detailed comments! I will reply them inline below. On Tue, Apr 9, 2019 at 11:39 AM Fabrice Theoleyre wrote: > Dear Tengfei, > > Please find below my review of the draft. I isolated the corresponding > blocks, and inserted my comments after 'FT>' > > The draft is very well written, and I have mostly minor comments. > Great job! > > Best regards, > Fabrice > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > > an implementor MAY implements MSF > > FT> an implementor MAY implement MSF > > FT> I=E2=80=99m also a little bit confused. The section describes how to = use the > shared > FT> cell of Minimal 6TISCH. If Minimal 6TISCH is not used, how does the > FT> scheme work? Shouldn=E2=80=99t some minimum requirements be FT given = here? > > =E2=80=94=E2=80=94=E2=80=94 > > These cells are called 'autonomous cells', because they are maintained > autonomously > by each node. > > FT> I find the term =E2=80=98autonomous=E2=80=99 quite misleading, since = manage cells are > FT> also negotiated autonomously (without any controller). I would rather > use > FT> something else like =E2=80=98pseudo-random=E2=80=99. > FT> or rename the 'managed cells' in =E2=80=99negotiated cells=E2=80=99? > > TC: yes, "negotiated cells" sounds good for me. =E2=80=94=E2=80=94=E2=80=94 > > There are other optional parameters defined in SAX determines the > performance of SAX hash function. > > FT> Other optional parameters defined in SAX > FT> determine the performance of SAX hash function. > > =E2=80=94=E2=80=94=E2=80=94 > > The AutoUpCell with the most packets in the outgoing queue takes > precedence. > > FT> does a node has several upstream cells? I would have thought > FT> that a single upstream cell exists (or you consider multiple parents?= ) > > =E2=80=94=E2=80=94=E2=80=94 > > Autonomous Downstream Cell (AutoDownCell), one cell at a > [slotOffset,channelOffset] computed as a hash of its own EUI64 > (detailed next). Its cell options bits are assigned as TX=3D1, > RX=3D1, SHARED=3D0. > > FT> I would have explained here the role of this cell (i.e. receiving > FT> control packets from any neighbor), and similarly for the upstream > cell. > FT> I conjecture it may be quite hard for the reader to understand > FT> their purpose > > =E2=80=94=E2=80=94=E2=80=94 > > 6P RELOCATE Request frames to the node's RPL routing child MUST be > sent on AutoDownCell. > > FT> What about 6P RELOCATE request to the parent? Can only a parent > FT> relocate a cell with 6P? > > =E2=80=94=E2=80=94=E2=80=94 > > Join Response packets and 6P ADD/DELETE Response frames to the > pledge or its RPL routing child MUST be sent on AutoDownCell. > > FT> does this mean that a cell MUST be inserted in the schedule > FT> for each child (or after the reception of a Join-req)? Or can > FT> a node send a packet through a cell not registered in its schedule? > > =E2=80=94=E2=80=94=E2=80=94 > > A node implementing MSF MUST implement the Minimal Security Framework > for 6TiSCH > > FT> In contradiction with section 2 'MAY implements MSF without > implementing > FT> Minimal 6TiSCH Configuration.' > > =E2=80=94=E2=80=94=E2=80=94 > > The section 4 is particularly clearly, explaining well the =E2=80=98flow= =E2=80=99 when a > device joins the network > > =E2=80=94=E2=80=94=E2=80=94 > > While autonomous cells have a dedicated section (2), managed cells are no= t > described. > In particular, are they bidirectional, shared, etc.? > > =E2=80=94=E2=80=94=E2=80=94 > > NumCellsUsed: Counts the number of managed cells that have been > used. This counter is initialized at 0. NumCellsUsed is > incremented by exactly 1 when, during a managed cell to the > preferred parent, either of the following happens: > > [=E2=80=A6] > > * The node receives a frame from its preferred parent. > > FT> Let assume a cell is shared, and is only used to receive packets. > FT> Because of a bad PDR, we have many retransmissions. The receiver > FT> implements the counter only when the cell is decoded. It may decide > FT> to DELETE this cell. > FT> Doesn=E2=80=99t it? > > FT> Shouldn=E2=80=99t the description consider separately the SHARED and = NON-SHARED > FT> cases? > > =E2=80=94=E2=80=94=E2=80=94 > > 1. if there is managed cell conflicted with the AutoUpCells to be > installed, the node MUST issue a 6P RELOCATE command to relocate > the conflicted cell > > FT> When is the AutoUpCells installed? After the 6P RELOCATE RESPONSE? > FT> Before, and the AutoUpCells has the priority? > > =E2=80=94=E2=80=94=E2=80=94 > That is, for example, from NumTx=3D256 and > NumTxAck=3D128, they become NumTx=3D128 and NumTxAck=3D64. This opera= tion > does not change the value of the PDR, but allows the counters to keep > incrementing. > > FT> yes, but it increases the convergence time. For instance, a burst of > FT> packets is dropped at the beginning (i.e. during convergence, with > FT> many collisions). Then, everything is fine. The PDR will take a long > time > FT> to reflect the actual PDR. The cell may be RELOCATED erroneously. > FT> (the collision may have been solved meanwhile by the conflicting link= ) > > FT> Is it something you considered? > > =E2=80=94=E2=80=94=E2=80=94 > towards it preferred parent > > FT> towards its preferred parent > > =E2=80=94=E2=80=94=E2=80=94 > > is calcualted as > ((2^MAXBE)-1)*SLOTFRAME_LENGTH, where: > > FT>is calculated as > > =E2=80=94=E2=80=94=E2=80=94 > > MAXEB is the maxmium backoff exponent is used > > FT> MAXBE is the maximum backoff exponent used > (3 errors) > > =E2=80=94=E2=80=94=E2=80=94 > > > > > > Le 9 avr. 2019 =C3=A0 06:06, Tengfei Chang a = =C3=A9crit : > > Dear all, > > A new version of "draft-ietf-6tisch-msf" is just published at here: > https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt > > This version mainly resolved the issues presented during IETF 104 meeting= . > I would like to mention one of the main changes in this version is we > removed the frame pending bit feature. > > It's for two reasons: > - it will influence the "adapt to traffic" strategy of MSF. > - the "adapt to traffic" strategy has the ability to handle burst traffic > by using a smaller MAX_NUMCELLS > > Now we are calling for reviews on the new version of MSF! > Any comments and feedback are appreciated! > > Tengfei > > > > -- > Chang Tengfei, > Postdoctoral Research Engineer, Inria > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > --=20 Chang Tengfei, Postdoctoral Research Engineer, Inria --00000000000019df000586b89793 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabrice,

Thanks a lot for= your detailed comments! I will reply them inline below.

On Tue, Apr 9, = 2019 at 11:39 AM Fabrice Theoleyre <theoleyre@unistra.fr> wrote:
Dear= Tengfei,=C2=A0

Please find below my review of the= draft. I isolated the corresponding blocks, and inserted my comments after= 'FT>'

The draft is very well written, = and I have mostly minor comments.
Great job!

=
Best regards,
Fabrice


=E2=80=94=E2=80=94=E2=80=94=E2=80=94


<= div>an implementor MAY implements MSF

FT>=C2=A0an im= plementor MAY implement MSF

FT> I=E2=80=99m also a li= ttle bit confused. The section describes how to use the shared
FT= > =C2=A0cell of Minimal 6TISCH. If Minimal 6TISCH is not used, how does = the
FT> scheme work? Shouldn=E2=80=99t some minimum requiremen= ts be FT given here?

=E2=80=94=E2=80=94=E2=80=94

These cells are called =C2=A0'autonomous cells&= #39;, because they are maintained autonomously=C2=A0
by each node= . =C2=A0

FT> I find the term =E2=80=98autonomou= s=E2=80=99 quite misleading, since manage cells are
FT> also n= egotiated autonomously (without any controller). I would rather use
FT> something else like =E2=80=98pseudo-random=E2=80=99.=C2=A0
<= div>FT> or rename the 'managed cells' in =E2=80=99negotiated cel= ls=E2=80=99?

TC:=C2=A0 yes, &qu= ot;negotiated cells" sounds good for me.=C2=A0

=E2=80=94=E2=80=94=E2=80=94
<= div>
There are other optional parameters defined in SAX = determines the performance of SAX hash function.
=C2=A0
FT> Other optional parameters defined in SAX
FT> =C2= =A0determine the performance of SAX hash function.

=E2=80=94=E2=80=94=E2=80=94

= The AutoUpCell with the most packets in the outgoing queue takes
= =C2=A0 =C2=A0 =C2=A0 precedence.

FT> does= a node has several upstream cells? I would have thought
FT> t= hat a single upstream cell exists (or you consider multiple parents?)
=

=E2=80=94=E2=80=94=E2=80=94
<= br>
Autonomous Downstream Cell (AutoDownCell), one cell at a=
=C2=A0 =C2=A0 =C2=A0 [slotOffset,channelOffset] computed as a ha= sh of its own EUI64
=C2=A0 =C2=A0 =C2=A0 (detailed next).=C2=A0 I= ts cell options bits are assigned as TX=3D1,
=C2=A0 =C2=A0 =C2=A0= RX=3D1, SHARED=3D0.

FT> I would have exp= lained here the role of this cell (i.e. receiving
FT> control = packets from any neighbor), and similarly =C2=A0for the upstream cell.
FT> I conjecture it may be quite hard for the reader to understand=
FT> their purpose

=E2=80=94=E2= =80=94=E2=80=94

=C2=A06P RELOCATE Request fra= mes to the node's RPL routing child MUST be
=C2=A0 =C2=A0 =C2= =A0 sent on AutoDownCell.

FT> What about = 6P RELOCATE request to the parent?=C2=A0Can=C2=A0only a parent
FT= > relocate a cell with 6P?=C2=A0

=E2=80=94= =E2=80=94=E2=80=94

Join Response packet= s and 6P ADD/DELETE Response frames to the
=C2=A0 =C2=A0 =C2=A0 p= ledge or its RPL routing child MUST be sent on AutoDownCell.

FT> does this mean that a cell MUST be inserted in= the schedule
FT> for each child (or after the reception of a = Join-req)? Or can
FT> a node send a packet through a cell not = registered in its schedule?

=E2=80=94=E2=80= =94=E2=80=94

=C2=A0A node implementing = MSF MUST implement the Minimal Security Framework
=C2=A0 =C2=A0fo= r 6TiSCH=C2=A0

FT> In contradiction with = section 2 'MAY implements MSF without implementing
FT> Min= imal 6TiSCH Configuration.'

=E2=80=94=E2= =80=94=E2=80=94

The section 4 is particularl= y clearly, explaining well the =E2=80=98flow=E2=80=99 when a device joins t= he network

=E2=80=94=E2=80=94=E2=80=94
<= /div>

While autonomous cells have a dedicated section (2= ), managed cells are not described.=C2=A0
In particular, are they= bidirectional, shared, etc.?

=E2=80=94=E2=80= =94=E2=80=94

NumCellsUsed: =C2=A0Counts= the number of managed cells that have been
=C2=A0 =C2=A0 =C2=A0 = =C2=A0used.=C2=A0 This counter is initialized at 0.=C2=A0 NumCellsUsed is
=C2=A0 =C2=A0 =C2=A0 =C2=A0incremented by exactly 1 when, during a= managed cell to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0preferred parent,= either of the following happens:
=C2=A0 =C2=A0
[= =E2=80=A6]=C2=A0

=C2=A0 =C2=A0* =C2=A0The node rec= eives a frame from its preferred parent.

FT> Le= t assume a cell is shared, and is only used to receive packets.
=
FT> Because of a bad PDR, we have many retransmissions. The re= ceiver=C2=A0
FT> implements the counter only when the cell is = decoded. It may decide
FT> to DELETE this cell.=C2=A0
FT> Doesn=E2=80=99t it?

FT> Shouldn= =E2=80=99t the description consider separately the SHARED and NON-SHARED
FT> cases?=C2=A0

=E2=80=94=E2=80=94=E2= =80=94

1. =C2=A0if there is managed cell conf= licted with the AutoUpCells to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0inst= alled, the node MUST issue a 6P RELOCATE command to relocate
=C2= =A0 =C2=A0 =C2=A0 =C2=A0the conflicted cell

= FT> When is the AutoUpCells installed? After the 6P RELOCATE RESPONSE?
FT> Before, and the AutoUpCells has the priority?=C2=A0

=E2=80=94=E2=80=94=E2=80=94
That is, for e= xample, from NumTx=3D256 and
=C2=A0 =C2=A0NumTxAck=3D128, they be= come NumTx=3D128 and NumTxAck=3D64.=C2=A0 This operation
=C2=A0 = =C2=A0does not change the value of the PDR, but allows the counters to keep=
=C2=A0 =C2=A0incrementing.

FT>= yes, but it increases the convergence time. For instance, a burst of
=
FT> packets is dropped at the beginning (i.e. during convergence, w= ith=C2=A0
FT> many collisions). Then, everything is fine.= The PDR will take a long time
FT> to reflect the actual PDR. = The cell may be RELOCATED erroneously.
FT> (the collision may = have been solved meanwhile by the conflicting link)

FT> Is it something you considered?

=E2=80=94= =E2=80=94=E2=80=94
towards it preferred parent

FT> towards its preferred parent=C2=A0

=E2=80=94=E2=80=94=E2=80=94

<= div>is calcualted as
=C2=A0 =C2=A0((2^MAXBE)-1)*SLOTFRAME_LENGTH,= where:

FT>is calculated as
=C2= =A0
=E2=80=94=E2=80=94=E2=80=94

MA= XEB is the maxmium backoff exponent is used

F= T> MAXBE is the maximum backoff exponent used
(3 errors)= =C2=A0

=E2=80=94=E2=80=94=E2=80=94





Le 9 avr. 2019 =C3=A0 06:06, Tengfei Chang <tengfei.chang@gm= ail.com> a =C3=A9crit :

Dear al= l,

A new version of "draft-ietf-6tisch-msf" is= just published at here:=C2=A0https://www.ietf.org/id/draft-ietf-6t= isch-msf-03.txt

This version mainly resolved t= he issues presented during IETF 104 meeting.
I would like to ment= ion one of the main changes in this version is we removed the frame pending= bit feature.

It's for two reasons:
=
- it will influence the "adapt to traffic" strategy of MSF.<= /div>
- the "adapt to traffic" strategy has the ability to ha= ndle burst traffic by using a smaller MAX_NUMCELLS

Now we are calling for reviews on the new version of MSF!=C2=A0
Any comments and feedback are appreciated!

T= engfei



--
<= div dir=3D"ltr" class=3D"gmail-m_-7063881493954390539gmail_signature">
Cha= ng Tengfei,
Postdoctoral Research = Engineer, Inria
_______________________________________________
6tisch mailing list
<= a href=3D"mailto:6tisch@ietf.org" target=3D"_blank">6tisch@ietf.org
= = https://www.ietf.org/mailman/listinfo/6tisch



--
= Chang Teng= fei,
Postdoctora= l Research Engineer, Inria
--00000000000019df000586b89793-- From nobody Wed Apr 17 05:48:41 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CF3120108 for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 05:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFWJmMXu3bxz for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 05:48:36 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 080D61200DF for <6tisch@ietf.org>; Wed, 17 Apr 2019 05:48:35 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id b3so11997816plr.7 for <6tisch@ietf.org>; Wed, 17 Apr 2019 05:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M8kP/y1AFwDMSUpY+1wH4zw9o1vYKHEwxsFPAIkYYCY=; b=dLprF49WRwOkfCHMrbcDeRhzTyBDifBS1xackPJz/TLjwnbZHxyzizQYoy0BU7n/fG FmxXzfrFOqPyK5brxbvlytBfWvYcDlaP20JLJ5LhA9pI4Gg1WLwsO6kffu4RX+vo7PD7 bHDWmDtcliNsdnYnxF6Ljl2nfuYZQsT4eEBfJ4aXNTjdFQ7vAL++Av68AK48g9KKzWSB ua50gPS2CuW1ejDP//grAzL/8HqvbMh9xc4KYrX57w3t6P2V2ZHLzq7LPSPUrAdgDF1F WuV9p3hzvwwYgFsv48J9yM5QuAuqJoJoc/EimNaCgNmUmx6Ei0DZ4EoOl787k8G8ooRl QtRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M8kP/y1AFwDMSUpY+1wH4zw9o1vYKHEwxsFPAIkYYCY=; b=CywbaW6/UT7V6wn5U1yarH82ULACkTfq/lgYGO6j6MyeyfCfaPhGM5IBFy1gFBbw4v 74yHsh9FmoX+YhHxhhZNTRX0cjV3w9vTTJfZhFDsY6oTJgQcaRbSPEHAnwD3fk7o6YSf kysyJFVR91lu3vZzFJ97g35HpPj1HuRoTX1wTWeqCDLq1gV8c2qM6U3riH7HVOWf3J6d J7dZo7Q3VSbzl9liTnJAzhVDdSFCd9D0MDROcXaPgYjoQ5TF/1I29CDFzDw1Hi3qaNue KJec8jPeJDC6IAPgpPI4swymaj+hoUmids9FqdCUyU/utKJk2+NUWcXNysQL6zNIc9Va RdPw== X-Gm-Message-State: APjAAAXRTr41Iycqf/5Hqy+mcO/LDfUpPwkQEK4kdd+dzxf9J9mMNjgN jcSXSATA2HsOJ7riNkB29wmlG2binWmAxHz+hUs= X-Google-Smtp-Source: APXvYqyFVBoyNadRXnWQBU2z+nS2FMZadtYnWwjaigDLEqx/cBYJXLTYmjn4NE8NDjTO0jseJXg6PAPY1qsxwR9PM2I= X-Received: by 2002:a17:902:9a83:: with SMTP id w3mr89985179plp.241.1555505315326; Wed, 17 Apr 2019 05:48:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Wed, 17 Apr 2019 14:48:22 +0200 Message-ID: To: Fabrice Theoleyre Cc: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="000000000000c42f0b0586b94db7" Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 12:48:39 -0000 --000000000000c42f0b0586b94db7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ( I accidentally sending the email before finishing) the reply continues inline... On Wed, Apr 17, 2019 at 1:57 PM Tengfei Chang wrote: > Hi Fabrice, > > Thanks a lot for your detailed comments! I will reply them inline below. > > On Tue, Apr 9, 2019 at 11:39 AM Fabrice Theoleyre > wrote: > >> Dear Tengfei, >> >> Please find below my review of the draft. I isolated the corresponding >> blocks, and inserted my comments after 'FT>' >> >> The draft is very well written, and I have mostly minor comments. >> Great job! >> >> Best regards, >> Fabrice >> >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> >> >> an implementor MAY implements MSF >> >> FT> an implementor MAY implement MSF >> >> FT> I=E2=80=99m also a little bit confused. The section describes how to= use the >> shared >> FT> cell of Minimal 6TISCH. If Minimal 6TISCH is not used, how does the >> FT> scheme work? Shouldn=E2=80=99t some minimum requirements be FT given= here? >> > TC: The minimum requirements will be that the the joining nodes are able to find a way to listen the EB/DIO from neighbors. It could be implemented in someway that not only sent on minimal cell. TC: However, consider your comments further below that the minimal security is a MUST for MSF, and minimal security is based on minimal configuration, we may need command the minimal configuration as well. > >> =E2=80=94=E2=80=94=E2=80=94 >> >> These cells are called 'autonomous cells', because they are maintained >> autonomously >> by each node. >> >> FT> I find the term =E2=80=98autonomous=E2=80=99 quite misleading, since= manage cells are >> FT> also negotiated autonomously (without any controller). I would rathe= r >> use >> FT> something else like =E2=80=98pseudo-random=E2=80=99. >> FT> or rename the 'managed cells' in =E2=80=99negotiated cells=E2=80=99? >> >> TC: yes, "negotiated cells" sounds good for me. > TC: I will rephrase the sentence as : > TC: These cells are called 'autonomous cells', because they are maintained autonomously TC: by each node without negotiation through 6P. TC: Cells scheduled through 6P transaction are called ' negotiated cells'. > =E2=80=94=E2=80=94=E2=80=94 >> >> There are other optional parameters defined in SAX determines the >> performance of SAX hash function. >> >> FT> Other optional parameters defined in SAX >> FT> determine the performance of SAX hash function. >> >> TC: Will be fixed in next version. > =E2=80=94=E2=80=94=E2=80=94 >> >> The AutoUpCell with the most packets in the outgoing queue takes >> precedence. >> >> FT> does a node has several upstream cells? I would have thought >> FT> that a single upstream cell exists (or you consider multiple parents= ?) >> >> TC: no. only one parent is considered. Will change something like: "AutoUpCell takes precedence if its outgoing queue is non-empty." > =E2=80=94=E2=80=94=E2=80=94 >> >> Autonomous Downstream Cell (AutoDownCell), one cell at a >> [slotOffset,channelOffset] computed as a hash of its own EUI64 >> (detailed next). Its cell options bits are assigned as TX=3D1, >> RX=3D1, SHARED=3D0. >> >> FT> I would have explained here the role of this cell (i.e. receiving >> FT> control packets from any neighbor), and similarly for the upstream >> cell. >> FT> I conjecture it may be quite hard for the reader to understand >> FT> their purpose >> >> TC: The traffic on the autonomous cells are defined later in the section= , which explains what packets/frames are sent on those cells. We could replace that explanation early in the section. For example, right after the definition of the autonomous cell. > =E2=80=94=E2=80=94=E2=80=94 >> >> 6P RELOCATE Request frames to the node's RPL routing child MUST be >> sent on AutoDownCell. >> >> FT> What about 6P RELOCATE request to the parent? Can only a parent >> FT> relocate a cell with 6P? >> >> TC: 6P RELOCATE request to the parent will be sent on AutoUpCell. I missed the RELOCATE 6P request. Will be fixed in next version. > =E2=80=94=E2=80=94=E2=80=94 >> >> Join Response packets and 6P ADD/DELETE Response frames to the >> pledge or its RPL routing child MUST be sent on AutoDownCell. >> >> FT> does this mean that a cell MUST be inserted in the schedule >> FT> for each child (or after the reception of a Join-req)? Or can >> FT> a node send a packet through a cell not registered in its schedule? >> > TC: no. There is only on AutoDownCell. The parent/JP can use the cell to send to any of its chidren/pledge. > >> =E2=80=94=E2=80=94=E2=80=94 >> >> A node implementing MSF MUST implement the Minimal Security Framework >> for 6TiSCH >> >> FT> In contradiction with section 2 'MAY implements MSF without >> implementing >> FT> Minimal 6TiSCH Configuration.' >> > TC: yes, as a consequence, we may use "MUST" again on the Minimal 6TiSCH Configuration. Or make the security strategy open as well? I am tending to the former. > >> =E2=80=94=E2=80=94=E2=80=94 >> >> The section 4 is particularly clearly, explaining well the =E2=80=98flow= =E2=80=99 when a >> device joins the network >> > TC: =F0=9F=91=8D > >> =E2=80=94=E2=80=94=E2=80=94 >> >> While autonomous cells have a dedicated section (2), managed cells are >> not described. >> In particular, are they bidirectional, shared, etc.? >> > TC: no, they are considered as only one direction, with cell option either TX=3D1 or RX=3D1. > >> =E2=80=94=E2=80=94=E2=80=94 >> >> NumCellsUsed: Counts the number of managed cells that have been >> used. This counter is initialized at 0. NumCellsUsed is >> incremented by exactly 1 when, during a managed cell to the >> preferred parent, either of the following happens: >> >> [=E2=80=A6] >> >> * The node receives a frame from its preferred parent. >> >> FT> Let assume a cell is shared, and is only used to receive packets. >> FT> Because of a bad PDR, we have many retransmissions. The receiver >> FT> implements the counter only when the cell is decoded. It may decide >> FT> to DELETE this cell. >> FT> Doesn=E2=80=99t it? >> > TC: This is good point! I think the adaption strategy doesn't fit the case for the RX cell in this sense. TC: if we can't figure out a good way to handle that case, we will remove the support of RX cell. > >> FT> Shouldn=E2=80=99t the description consider separately the SHARED and >> NON-SHARED >> FT> cases? >> >> TC: Right now we are not considering the case of SHARED "managed cell" (negotiated cell) since It may influence the calculation of cell Usage. > =E2=80=94=E2=80=94=E2=80=94 >> >> 1. if there is managed cell conflicted with the AutoUpCells to be >> installed, the node MUST issue a 6P RELOCATE command to relocate >> the conflicted cell >> >> FT> When is the AutoUpCells installed? After the 6P RELOCATE RESPONSE? >> FT> Before, and the AutoUpCells has the priority? >> > TC: for general case, AutoUpcell is installed before issuing 6P RELOCATE RESPONSE. However, in case of parent switching, the sequence may change. > >> =E2=80=94=E2=80=94=E2=80=94 >> That is, for example, from NumTx=3D256 and >> NumTxAck=3D128, they become NumTx=3D128 and NumTxAck=3D64. This oper= ation >> does not change the value of the PDR, but allows the counters to keep >> incrementing. >> >> FT> yes, but it increases the convergence time. For instance, a burst of >> FT> packets is dropped at the beginning (i.e. during convergence, with >> FT> many collisions). Then, everything is fine. The PDR will take a long >> time >> FT> to reflect the actual PDR. The cell may be RELOCATED erroneously. >> FT> (the collision may have been solved meanwhile by the conflicting lin= k) >> >> FT> Is it something you considered? >> > TC: in convergence time, the traffic goes on autonomous cell, when the "managed cell" is installed, that cell shouldn't have collision. Though the PDR take a long time to reflect the actual PDR, in case of bad PDR on the cell, the MSF traffic adapting strategy will compensate by allocating extra cell to meet the throughput. > >> =E2=80=94=E2=80=94=E2=80=94 >> towards it preferred parent >> >> FT> towards its preferred parent >> >> TC: will be fixed in next version. > =E2=80=94=E2=80=94=E2=80=94 >> >> is calcualted as >> ((2^MAXBE)-1)*SLOTFRAME_LENGTH, where: >> >> FT>is calculated as >> > TC: will be fixed in next version. > >> =E2=80=94=E2=80=94=E2=80=94 >> >> MAXEB is the maxmium backoff exponent is used >> >> FT> MAXBE is the maximum backoff exponent used >> (3 errors) >> > TC: will be fixed in next version. > >> =E2=80=94=E2=80=94=E2=80=94 >> >> >> >> >> >> Le 9 avr. 2019 =C3=A0 06:06, Tengfei Chang a = =C3=A9crit : >> >> Dear all, >> >> A new version of "draft-ietf-6tisch-msf" is just published at here: >> https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt >> >> This version mainly resolved the issues presented during IETF 104 meetin= g. >> I would like to mention one of the main changes in this version is we >> removed the frame pending bit feature. >> >> It's for two reasons: >> - it will influence the "adapt to traffic" strategy of MSF. >> - the "adapt to traffic" strategy has the ability to handle burst traffi= c >> by using a smaller MAX_NUMCELLS >> >> Now we are calling for reviews on the new version of MSF! >> Any comments and feedback are appreciated! >> >> Tengfei >> >> >> >> -- >> Chang Tengfei, >> Postdoctoral Research Engineer, Inria >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> > > -- > Chang Tengfei, > Postdoctoral Research Engineer, Inria > --=20 Chang Tengfei, Postdoctoral Research Engineer, Inria --000000000000c42f0b0586b94db7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
( I accidentally sending= the email before finishing) the reply continues inline...

On Wed, Apr 17, 2= 019 at 1:57 PM Tengfei Chang <tengfei.chang@gmail.com> wrote:
Hi Fabrice,

Thanks a lot for your detailed comments! I will reply them inline b= elow.

On Tue, Apr 9, 2019 at 11:39 AM Fabrice Theoleyre <theoleyre@unistra.fr> = wrote:
Dear Tengfei,=C2=A0

Please find below my review o= f the draft. I isolated the corresponding blocks, and inserted my comments = after 'FT>'

The draft is very well writ= ten, and I have mostly minor comments.
Great job!

<= /div>
Best regards,
Fabrice


=E2=80=94=E2=80=94=E2=80=94=E2=80=94


an implementor MAY implements MSF

FT>=C2=A0= an implementor MAY implement MSF

FT> I=E2=80=99m also= a little bit confused. The section describes how to use the shared
FT> =C2=A0cell of Minimal 6TISCH. If Minimal 6TISCH is not used, how = does the
FT> scheme work? Shouldn=E2=80=99t some minimum requi= rements be FT given here?
=

TC: The minimum requirements will be that the the joini= ng nodes are able to find a way to listen the EB/DIO from neighbors.
<= div>It could be implemented in someway that not only sent on minimal cell.<= /div>

TC: However, consider your comments further below = that the minimal security is a MUST for MSF, and minimal security is based = on minimal configuration, we may need command the minimal configuration as = well.

=E2=80=94=E2=80=94=E2=80=94

These cells are called =C2=A0'autonomous cells', because th= ey are maintained autonomously=C2=A0
by each node. =C2=A0

FT> I find the term =E2=80=98autonomous=E2=80=99 quite= misleading, since manage cells are
FT> also negotiated autono= mously (without any controller). I would rather use
FT> someth= ing else like =E2=80=98pseudo-random=E2=80=99.=C2=A0
FT> or re= name the 'managed cells' in =E2=80=99negotiated cells=E2=80=99?

TC:=C2=A0 yes, "negotiated ce= lls" sounds good for me.=C2=A0
TC: I will rephrase the sente= nce as :=C2=A0
TC: These cells are = called =C2=A0'autonomous cells', because they are maintained autono= mously=C2=A0
TC: by each node without negotiation through 6P.=C2= =A0
TC: Cells scheduled through 6P transaction are called '= =C2=A0 negotiated=C2=A0cells'.
=E2=80=94=E2=80= =94=E2=80=94

There are other optional p= arameters defined in SAX determines the performance of SAX hash function.
=C2=A0
FT> Other optional parameters defined in= SAX
FT> =C2=A0determine the performance of SAX hash function.=

TC: Will be fixed in next version.=C2=A0
=E2=80=94=E2=80=94=E2=80=94

The AutoU= pCell with the most packets in the outgoing queue takes
=C2=A0 = =C2=A0 =C2=A0 precedence.

FT> does a node= has several upstream cells? I would have thought
FT> that a s= ingle upstream cell exists (or you consider multiple parents?)

=C2=A0TC: no. only one parent is considered. Will change somethin= g like: "AutoUpCell=C2=A0 takes precedence if its outgoing queue is no= n-empty."
=E2=80=94=E2=80=94=E2=80= =94

Autonomous Downstream Cell (AutoDow= nCell), one cell at a
=C2=A0 =C2=A0 =C2=A0 [slotOffset,channelOff= set] computed as a hash of its own EUI64
=C2=A0 =C2=A0 =C2=A0 (de= tailed next).=C2=A0 Its cell options bits are assigned as TX=3D1,
=C2=A0 =C2=A0 =C2=A0 RX=3D1, SHARED=3D0.

FT= > I would have explained here the role of this cell (i.e. receiving
FT> control packets from any neighbor), and similarly =C2=A0for th= e upstream cell.
FT> I conjecture it may be quite hard for the= reader to understand
FT> their purpose

TC: The traffic = on the autonomous cells are defined later in the section, which explains wh= at packets/frames are sent on those cells.
We could replace that = explanation early in the section. For example, right after the definition o= f the autonomous cell.
=E2=80=94=E2=80=94=E2=80=94=

=C2=A06P RELOCATE Request frames to the node= 's RPL routing child MUST be
=C2=A0 =C2=A0 =C2=A0 sent on Aut= oDownCell.

FT> What about 6P RELOCATE req= uest to the parent?=C2=A0Can=C2=A0only a parent
FT> relocate a= cell with 6P?=C2=A0

TC:=C2=A0 6P RELOCATE request to the parent will be se= nt on AutoUpCell. I missed the RELOCATE 6P request. Will be fixed in next v= ersion.
=E2=80=94=E2=80=94=E2=80=94
=

Join Response packets and 6P ADD/DELETE Resp= onse frames to the
=C2=A0 =C2=A0 =C2=A0 pledge or its RPL routing= child MUST be sent on AutoDownCell.

FT= > does this mean that a cell MUST be inserted in the schedule
= FT> for each child (or after the reception of a Join-req)? Or can
<= div>FT> a node send a packet through a cell not registered in its schedu= le?

<= /div>
TC: no. There is only on AutoDownCell. The parent/JP can use the = cell to send to any of its chidren/pledge.=C2=A0

=E2=80=94=E2=80=94=E2=80=94

=C2=A0A node implementing MSF MUST implement the Minimal Security Framewo= rk
=C2=A0 =C2=A0for 6TiSCH=C2=A0

F= T> In contradiction with section 2 'MAY implements MSF without imple= menting
FT> Minimal 6TiSCH Configuration.'

TC: yes, = as a consequence, we may use "MUST" again on the Minimal 6TiSCH C= onfiguration. Or make the security strategy open as well?
I am te= nding to the former.=C2=A0

=E2=80=94= =E2=80=94=E2=80=94

The section 4 is particul= arly clearly, explaining well the =E2=80=98flow=E2=80=99 when a device join= s the network
=
TC:=C2=A0=F0=9F=91=8D=C2=A0

= =E2=80=94=E2=80=94=E2=80=94

While autonomous= cells have a dedicated section (2), managed cells are not described.=C2=A0=
In particular, are they bidirectional, shared, etc.?
=
=C2=A0
TC:= no, they are considered as only one direction, with cell option either TX= =3D1 or RX=3D1.=C2=A0

=E2=80=94=E2= =80=94=E2=80=94

NumCellsUsed: =C2=A0Cou= nts the number of managed cells that have been
=C2=A0 =C2=A0 =C2= =A0 =C2=A0used.=C2=A0 This counter is initialized at 0.=C2=A0 NumCellsUsed = is
=C2=A0 =C2=A0 =C2=A0 =C2=A0incremented by exactly 1 when, duri= ng a managed cell to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0preferred par= ent, either of the following happens:
=C2=A0 =C2=A0
[=E2=80=A6]=C2=A0

=C2=A0 =C2=A0* =C2=A0The node= receives a frame from its preferred parent.

FT>= ; Let assume a cell is shared, and is only used to receive packets.
FT> Because of a bad PDR, we have many retransmissions. Th= e receiver=C2=A0
FT> implements the counter only when the cell= is decoded. It may decide
FT> to DELETE this cell.=C2=A0
FT> Doesn=E2=80=99t it?
=
=C2=A0
TC: This is good point! I think th= e adaption strategy doesn't fit the case for the RX cell in this sense.= =C2=A0=C2=A0
TC: if we can't figure out a good way to handle = that case, we will remove the support of RX cell.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

<= div>FT> Shouldn=E2=80=99t the description consider separately the SHARED= and NON-SHARED
FT> cases?=C2=A0

TC: Right now we are not cons= idering the case of SHARED "managed cell" (negotiated cell) since= It may influence the calculation of cell Usage.=C2=A0
=
=E2=80=94=E2=80=94=E2=80=94

1. =C2=A0if = there is managed cell conflicted with the AutoUpCells to be
=C2= =A0 =C2=A0 =C2=A0 =C2=A0installed, the node MUST issue a 6P RELOCATE comman= d to relocate
=C2=A0 =C2=A0 =C2=A0 =C2=A0the conflicted cell

FT> When is the AutoUpCells installed? After = the 6P RELOCATE RESPONSE?
FT> Before, and the AutoUpCells has = the priority?=C2=A0
=
=C2=A0
TC: for general case, AutoUpcell is installed before = issuing 6P RELOCATE RESPONSE. However, in case of parent switching, the seq= uence may change.=C2=A0

=E2=80=94=E2=80=94=E2= =80=94
That is, for example, from NumTx=3D256 and
= =C2=A0 =C2=A0NumTxAck=3D128, they become NumTx=3D128 and NumTxAck=3D64.=C2= =A0 This operation
=C2=A0 =C2=A0does not change the value of the = PDR, but allows the counters to keep
=C2=A0 =C2=A0incrementing.

FT> yes, but it increases the convergence = time. For instance, a burst of
FT> packets is dropped at the b= eginning (i.e. during convergence, with=C2=A0
FT> many co= llisions). Then, everything is fine. The PDR will take a long time
FT> to reflect the actual PDR. The cell may be RELOCATED erroneously.<= /div>
FT> (the collision may have been solved meanwhile by the confl= icting link)

FT> Is it something you considered= ?

TC: in convergence time, the traffic goes on autonomous cell, when = the "managed cell"=C2=A0 is installed, that cell shouldn't ha= ve collision.
Though the PDR take a long time to reflect the actu= al PDR, in case of bad PDR on the cell, the MSF traffic adapting=C2=A0=C2= =A0strategy will compensate by allocating extra cell to meet the throughput= .
<= div class=3D"gmail_quote">

=E2=80=94=E2=80=94=E2=80=94
t= owards it preferred parent

FT> towards its= preferred parent=C2=A0

TC: will be fixed in next ve= rsion.=C2=A0
=E2=80=94=E2=80=94=E2=80=94

is calcualted as
=C2=A0 =C2=A0((2^MAXBE= )-1)*SLOTFRAME_LENGTH, where:

FT>is calcu= lated as
= TC: will be fixed in next version.=C2=A0=C2=A0
=C2=A0
=E2=80=94=E2=80=94=E2=80=94

MAXEB is= the maxmium backoff exponent is used

FT> = MAXBE is the maximum backoff exponent used
(3 errors)=C2=A0=
=C2=A0
TC: will be fixed in next version.=C2=A0=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=E2=80=94=E2=80=94=E2=80=94





Le= 9 avr. 2019 =C3=A0 06:06, Tengfei Chang <tengfei.chang@gmail.com> a =C3=A9crit= :

Dear all= ,

A new version of "draft-ietf-6tisch-msf" is = just published at here:=C2=A0https://www.ietf.org/id/draft-ietf-6ti= sch-msf-03.txt

This version mainly resolved th= e issues presented during IETF 104 meeting.
I would like to menti= on one of the main changes in this version is we removed the frame pending = bit feature.

It's for two reasons:
<= div>- it will influence the "adapt to traffic" strategy of MSF.
- the "adapt to traffic" strategy has the ability to han= dle burst traffic by using a smaller MAX_NUMCELLS

Now we are calling for reviews on the new version of MSF!=C2=A0
=
Any comments and feedback are appreciated!

Te= ngfei



--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
<= /div>
_______________________________________________
6tisch mailing list
<= a href=3D"mailto:6tisch@ietf.org" target=3D"_blank">6tisch@ietf.org
= = https://www.ietf.org/mailman/listinfo/6tisch



--
Chang Tengfei,
Postdoctoral Research Engineer, Inria


--
Chang Tengfei,
<= span style=3D"font-size:12.8px">
Postdoctoral Research Enginee= r, Inria
--000000000000c42f0b0586b94db7-- From nobody Wed Apr 17 06:31:49 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A865120104 for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 06:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Hjm6aeKEFS for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 06:31:45 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 7A99412008D for <6tisch@ietf.org>; Wed, 17 Apr 2019 06:31:45 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id z9so12013927pgu.10 for <6tisch@ietf.org>; Wed, 17 Apr 2019 06:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y7PD3NEQAjmrgAoqm0m31WmHuX+72448e1cbdScjzmw=; b=j35/QWAOFYRufZqXlLGntR4AptrhcEFQ+h35VCNmuTmQJyvCuInO3wqkDRt1/oZDgX bmZM6+0ndCo/UQYt8W/UnVXaYqADE6UwEIU7vE+dQdh1fag5c9rQdNnzH/1bUJS0H/vp eANqcv0A1e8hgai95tXKYftmjO1NFoQJCainsiurFdo6nv+L7/t98NeONiGJvap8ZbYr 2xZx3+nW0MFAdhWCFV010R9NeIBOa7w4Vfn5GmqZ4kFHWG36U9R0ogwUs5lIFpXYZpQx 3PQ2jmQVA5DWiWio/bTz9fHIP6rpAzUFvQCSQpL2A6xuEY8Fq1QrhqaZjOT8F/aAkFIU Rfew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y7PD3NEQAjmrgAoqm0m31WmHuX+72448e1cbdScjzmw=; b=hcsig8UsvyoQrKe8L8jexz0mFQSK/R+qZK0m5gRWD1+hivO9p79M4tLqowuthtRIXL rQ7i3p3pJDsbJ4vtOPZHg+NbKhXVTyn/gC1JgcgZdKA94zvm7eSIWgPvwt5IjpdJmODj Gy3raffSt7eyN4IrjfZdIhwLWmU0qzyQOHENUHzeeupquOAJSc8sZdEJa1Xt/6xFLjUP ZjRfm4F4/mll5+SA6k9UmMbmuFQQ+d3Zx2hUIJszqRLlLhhTmUsPzXQe/XqeYYd3Fqb+ 2QLKcn7FlgubvdtHwUmpjnDKEHOifIhdxZ7mjX6JZkGSdhyxbhLzuoxoEs89Y1JT59qJ KExw== X-Gm-Message-State: APjAAAUFcxbJeZthgrvTC+janEdRXrkk2c5BlafccMyOkTwaveSHOjFS /VDlthgWUfCNRQx3w8ioG3pIjpOPwKxrhyNAAmQ= X-Google-Smtp-Source: APXvYqzm6Es24k/AdOkeGejJePnmsA3WYFesfelyAvZIopW91yH0ocqElcLPL7VNex3SEzp1wmeNPISS33zNDce0fFA= X-Received: by 2002:a62:fb0a:: with SMTP id x10mr90368790pfm.179.1555507904891; Wed, 17 Apr 2019 06:31:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Wed, 17 Apr 2019 15:31:31 +0200 Message-ID: To: Atis Elsts Cc: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="0000000000001dcfcf0586b9e80f" Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:31:48 -0000 --0000000000001dcfcf0586b9e80f Content-Type: text/plain; charset="UTF-8" Hi Atis, Thank you for reviewing and giving the comments! I will reply them below. For your comments: *- There is still one reference left to the number 16 as the max number of channels (which 2.4 GHz frequency-band-specific). It's in the formula `channelOffset(MAC) = hash(EUI64, 16)`. This may conflict with the intention expressed previously in the text, where you say that "the coordinates are computed to distribute the cells across all channel offsets" (i.e. not exactly 16 channel offsets)* TC: Yes, we will replace the 16 by NUM_CH_OFFSET and added it to the recommended value table. *- Have you considered suggesting that the implementers to prioritize 6top packets over data packets?* TC: Sure, we may add a rule about the application packet is not allowed to send on autonomous cell, this will separate the traffic between 6P and application. Then prioritizing 6P is not necessary. *- Have you considered providing a recommended value for MAX_NUMCELLS or discussing how to select it?* TC: Maybe we will discuss it. TC: Generally, to quick react the changes of traffic, a small size of MAX_NUMCELLS is preferred, otherwise, a large value is preferred. For more details, some investigation on this is required. A recommendation value or discussion will come after that. TC: I will fixed the other comments in the next version. Tengfei On Tue, Apr 9, 2019 at 1:06 PM Atis Elsts wrote: > Hello Tengfei and the 6tisch community, > > I'm happy to see the frame pending bit removed and other big improvements > in clarity and functionality. > > Following up on my other previous comments, > - There is still one reference left to the number 16 as the max number of > channels (which 2.4 GHz frequency-band-specific). It's in the formula > `channelOffset(MAC) = hash(EUI64, 16)`. This may conflict with the > intention expressed previously in the text, where you say that "the > coordinates are computed to distribute the cells across all channel > offsets" (i.e. not exactly 16 channel offsets) > - Have you considered suggesting that the implementers to prioritize 6top > packets over data packets? > - Have you considered providing a recommended value for MAX_NUMCELLS or > discussing how to select it? > > Minor new comments: > > - The parameter KA_PERIOD from the recommended values is not referenced in > the main text. > > - There are a number of typos in the text, for example: > Boradcast -> Broadcast > maxmium -> maximum > calcualted -> calculated > bewteen -> between > > Best regards, > Atis > > > > On Tue, Apr 9, 2019 at 7:06 AM Tengfei Chang > wrote: > >> Dear all, >> >> A new version of "draft-ietf-6tisch-msf" is just published at here: >> https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt >> >> This version mainly resolved the issues presented during IETF 104 meeting. >> I would like to mention one of the main changes in this version is we >> removed the frame pending bit feature. >> >> It's for two reasons: >> - it will influence the "adapt to traffic" strategy of MSF. >> - the "adapt to traffic" strategy has the ability to handle burst traffic >> by using a smaller MAX_NUMCELLS >> >> Now we are calling for reviews on the new version of MSF! >> Any comments and feedback are appreciated! >> >> Tengfei >> >> >> >> -- >> Chang Tengfei, >> Postdoctoral Research Engineer, Inria >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > -- > Dr. Atis Elsts > Researcher, Institute of Electronics and Computer Science (EDI) > Dzerbenes str. 14, Riga, LV-1006 > > -- Chang Tengfei, Postdoctoral Research Engineer, Inria --0000000000001dcfcf0586b9e80f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Atis,

Thank you for reviewing and giving the comments!=C2=A0I will repl= y them below.=C2=A0

For your comments:=C2=A0
- There is still one refe= rence left to the number 16 as the max number of channels (which 2.4 GHz fr= equency-band-specific). It's in the formula `channelOffset(MAC) =3D has= h(EUI64, 16)`. This may conflict with the intention expressed previously in= the text, where you say that "the coordinates are computed to distrib= ute the cells across all channel offsets" (i.e. not exactly 16 channel= offsets)

TC: Yes, we will replace the = 16 by NUM_CH_OFFSET and added it to the recommended value table.
<= div dir=3D"ltr" style=3D"color:rgb(0,0,0)">
- Have you considered suggesting that the implemen= ters to prioritize 6top packets over data packets?

TC: = Sure, we may add a rule about the application packet is not allowed to send= on autonomous cell, this will separate the traffic between 6P and applicat= ion.
Then prioritizing 6P is not neces= sary.=C2=A0

- Have = you considered providing a recommended value for MAX_NUMCELLS or discussing= how to select it?
TC: Maybe we will discuss it.
<= div style=3D"color:rgb(0,0,0)">
TC= : Generally, to quick react the changes of traffic, a small size of MAX_NUM= CELLS is preferred, otherwise, a large value is preferred.
For more details, some investigation on this is requi= red. A recommendation value or discussion will come after that.

TC: I w= ill fixed the other comments in the next version.=C2=A0

Tengfei



On Tue, Apr 9, 2019 at 1:06 PM Atis= Elsts <atis.elsts@gmail.com= > wrote:
Hello Tengfei and the 6tisch= community,

I'm happy to see the frame pending bit removed and o= ther big improvements in clarity and functionality.

Following up on = my other previous comments,
- There is still one reference left to the n= umber 16 as the max number of channels (which 2.4 GHz frequency-band-specif= ic). It's in the formula `channelOffset(MAC) =3D hash(EUI64, 16)`. This= may conflict with the intention expressed previously in the text, where yo= u say that "the coordinates are computed to distribute the cells acr= oss all channel offsets" (i.e. not exactly 16 channel offsets)
- Have you considered suggesting that the implementers t= o prioritize 6top packets over data packets?
- Have you considered provi= ding a recommended value for MAX_NUMCELLS or discussing how to select it?
Minor new comments:

- The parameter KA_PERIOD from the recomme= nded values is not referenced in the main text.

- There are a number= of typos in the text, for example:
=C2=A0Boradcast -> Broadcast
= =C2=A0maxmium -> maximum
=C2=A0calcualted -> calculated
=C2=A0b= ewteen -> between

Best regards,
=
Atis



On Tue, Apr 9, 2019 at 7= :06 AM Tengfei Chang <tengfei.chang@gmail.com> wrote:
Dear a= ll,

A new version of "draft-ietf-6tisch-msf" i= s just published at here:=C2=A0https://www.ietf.org/id/draft-ietf-6= tisch-msf-03.txt

This version mainly resolved = the issues presented during IETF 104 meeting.
I would like to men= tion one of the main changes in this version is we removed the frame pendin= g bit feature.

It's for two reasons:
- it will influence the "adapt to tra= ffic" strategy of MSF.
- the &quo= t;adapt to traffic" strategy has the ability to handle burst traffic b= y using a smaller MAX_NUMCELLS

Now we are ca= lling for reviews on the new version of MSF!=C2=A0
Any comments a= nd feedback are appreciated!

Tengfei


--
Chang Tengfei,
Postdoctoral Research Engin= eer, Inria
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

--
Dr. Atis Elsts=
Researcher, Institute of Electronics and Computer Science (EDI)<= br>
Dzerbenes str. 14, Riga, LV-1006
=C2=A0


--
Chang Tengfei,
<= span style=3D"font-size:12.8px">
Postdoctoral Research Enginee= r, Inria
--0000000000001dcfcf0586b9e80f-- From nobody Wed Apr 17 07:58:44 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8416C120167 for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 07:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBiaA-gZiH9Z for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 07:58:38 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 47FD51200C4 for <6tisch@ietf.org>; Wed, 17 Apr 2019 07:58:38 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id e24so12216099pfi.12 for <6tisch@ietf.org>; Wed, 17 Apr 2019 07:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I6hXcMX0wgZOlNZ4045WrQQ33+7AZApLcQJvRHd9Xac=; b=Yl2HggH0SJRzZBw4PekVo/VNZBshRMkI+SCNYtboXScs4O6dMm5/aE1l196Qdt50xM RvajJI5+s4VNnyQhNfXWTXqcTHPteirpDTQg7kl33QZM0fjYypdomTlQ3bVo8g32Bp28 NyJe2F9rys+N/6sW06qwBFK+nk+Node/nic7KkanC4jrj8BoMMFPFPjMXnvsLSTv6REW x323rogk+wTTGw0qxtVIRxmMhzXW7gizc2ykrp0JCGlqm8GhgjXeGmfNBD/JiZjAeYJ8 ovMG3e1ieOPD+P4IUttmz9993Uc11tlvBjKArLjUbRcs9/kRnEcfWlvYyzXr4APHlf+x 6wyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I6hXcMX0wgZOlNZ4045WrQQ33+7AZApLcQJvRHd9Xac=; b=iUCOrY4gZ4zzMtyUlQw6ZNrvpOZ0WZWaluM8tztrVleGrxNW7L7Xt9ye9g8JnhqwS/ 7Dp+e78PrVqQtZvnbmSLYJ8d7nLbxZs5ZlCOLXn17PoNV61ihkfauVeoOFQ2FmIz3WLA mUX7OytIXMfm40O8DsB3OSUYdUIAkpMXUCpXeqwhFwmk6AgFlxlV7z+j3/w2NgaU36NU 5Zk/LQtKpQ7cg5e6Dmo346lQqtWjecelNSgwyvNCrU/vifRuIvu47GJEtPL9uo1zbnkJ PTVURGqgRkMbTJUbLQyOMOp1vS8sVuHeW2pw4S/NRGIBHn4b4c74rcM7P+YTTIhFDB1J 8ZLQ== X-Gm-Message-State: APjAAAWfQmm6mo+v5XNXSn/vc9bpdZVaeJ7d+HGVnMOblFSHqgBeMHr0 j1CnniDiOwxkx4DyGj1zuuLt6mLjbs4VDTAfwAk= X-Google-Smtp-Source: APXvYqxw1TPU6XKBYZNtbml2jfd/GCpSMziPL5GDx+ZF34rnZlJiFAuMMjPxLQm5ieNjfUWKaiTpAY6tk/QF9NQzWaY= X-Received: by 2002:a65:4247:: with SMTP id d7mr78348322pgq.114.1555513117281; Wed, 17 Apr 2019 07:58:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Wed, 17 Apr 2019 16:58:24 +0200 Message-ID: To: Yasuyuki Tanaka Cc: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="000000000000cc934d0586bb1ee9" Archived-At: Subject: Re: [6tisch] Review of draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 14:58:42 -0000 --000000000000cc934d0586bb1ee9 Content-Type: text/plain; charset="UTF-8" Hi Yatch, Thanks for the reviewing! I will reply your comments inline. On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka wrote: > Thank you, the authors! > > I confirmed most of my comments to the previous version have been > addressed. It reads better :-) > > Here are my comments: two comments are major, the rest are minor. > > > [major: usage of the autonomous cell and the managed cell] > > The draft specifies rules what type of frames MUST be sent over the > autonomous cell. How can we implement the rules on top of TSCH MAC > defined by IEEE802.15.4? > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 > draft-03> The traffic on the autonomous cells are scheduled as: > draft-03> > draft-03> o Join Request packets and 6P ADD/DELETE Request frames to the > draft-03> node's Join Proxy or its RPL routing parent MUST be sent on > draft-03> AutoUpCell. > draft-03> o Join Response packets and 6P ADD/DELETE Response frames to > the > draft-03> pledge or its RPL routing child MUST be sent on AutoDownCell. > draft-03> o 6P RELOCATE Request frames to the node's RPL routing child > MUST be > draft-03> sent on AutoDownCell. > draft-03> o 6P RELOCATE Response frames to its RPL routing parent MUST > be sent > draft-03> on AutoUpCell. > TC: For implementing, it requires some flag for the frame to mark as what type of 6P frames. TC: I agree that there are other frames that should be able to send on the autonomous cell according to IEEE802.15.4 standards. TC: Here is to limit the type frames on one cell but it doesn't break what defined in IEEE802.15.4 standards, IMO. > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 > draft-03> Adding/removing/relocating cells involves exchanging frames > that > draft-03> contain 6P commands. All 6P Request frames to its parent MUST > be > draft-03> sent on the AutoUpCell All 6P Response frames to non-parent > neighbor > draft-03> MUST be sent on AutoDownCell. > > At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell > to the same neighbor are used without distinction. This is totally > fine and straightforward. Why do we need the change to this part? > TC: this is to avoid the failure of 6P frames on inconsistent managed cell, for example, the node has a Tx cell to parent but the parent doesn't have the RX cell. TC: Though, it will be resolved at next 6P transaction (two transactions actually), it will be underperformance. > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1 > draft-02> Autonomous cells are used indistinguishably > draft-02> together with dedicated cells, for broadcast or unicast > traffic with > draft-02> the target neighbor. The procedure to remove autonomous cells > is > draft-02> described in Section 3. > > To my understandings, TSCH MAC selects a cell (link) to transmit a > frame seeing macTxType, macLinkType, and macNodeAddress of the cell, > which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC > cares only the destination MAC address and the frame type of a TX > frame, doesn't it? > > TC: It does in IEEE802.15.4 standard. TC: I am just not considering instead of caring only the destination MAC address and frame type, caring about more parameters is not a violation of standard. TC: Though, just in my opinion. > > [major: some confusions in Section 5] > > We don't need to maintain NumCellsElapsed and NumCellsUsed for RX > cells because managed cells have always only TX=1. > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 > draft-03> NumCellsElapsed : Counts the number of managed cells that have > draft-03> elapsed since the counter was initialized. This counter is > draft-03> initialized at 0. Each time the TSCH state machine > indicates > draft-03> that the current cell is a managed cell to the preferred > parent, > draft-03> NumCellsElapsed is incremented by exactly 1, regardless of > draft-03> whether the cell is used to transmit/receive a frame. > > "to transmit/receive a frame" in the last sentence should be replaced > with "to transmit a frame", and > > draft-03> Both NumCellsElapsed and NumCellsUsed counters can be used to > cell > draft-03> with cell option TX=1 or RX=1. > > "with cell option TX=1 or RX=1" should be replaced with "with cell > option TX=1"? > > Another thing is related to what Fabrice pointed out. There is > something wrong in text about the RELOCATE operation. Since NumTx and > NumTxAck are the key counters for the RELOCATE operation, a RELOCATE > request is never issued for an RX cell. Then, the direction in the > following text is opposite... > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 > draft-03> o 6P RELOCATE Request frames to the node's RPL routing child > MUST be > draft-03> sent on AutoDownCell. > draft-03> o 6P RELOCATE Response frames to its RPL routing parent MUST > be sent > draft-03> on AutoUpCell. > TC: yes, accepted this comment. TC: As replied to Fabrice, I will remove the RX=1 cell case for the adapting traffic strategy in next version.. > > One more thing: > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3 > draft-03> 4. For any other cell, it compares its PDR against that of the > cell > draft-03> with the highest PDR. If the different is less than > draft-03> RELOCATE_PDRTHRES, it triggers the relocation of that cell > using > draft-03> a 6P RELOCATE command. > > - s/different/difference/ > - s/less than/larger than/ ?? > > Can you check the entire text in Section 5? > TC: sure. Sorry for the confusing! Will be clarified in next version. > > > [minor comment #1] > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-2 > draft-03> For example, a Trickle Timer defined in [RFC6550] MAY be > draft-03> applied on DIOs. > > Do we need "MAY" here? If you implement RFC6550, DIO is automatically > controlled by Trickle Timer. > > TC: yes, it's a requirement. > > [minor comment #2] > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 > draft-03> MUST use the hash function SAX [SAX-DASFAA]. The coordinates > are > draft-03> computed to distribute the cells across all channel offsets, > and all > draft-03> but the first time offsets of Slotframe 1. The first time > offset is > draft-03> skipped to avoid colliding with the minimal cell in Slotframe > 0. > > s/time offset/slot offset/ > > TC: Thanks! I will go over the draft to make sure this is consistent. > > [minor comment #3] > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 > draft-03> o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) > draft-03> o channelOffset(MAC) = hash(EUI64, 16) > draft-03> > draft-03> The second input parameter defines the maxmium return value > of the > draft-03> hash function. > > The second input should be "the maximum return value plus 1", which > is the parameter 'T' of SAX. > TC: That's correct! Will be fixed. > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#appendix-B > draft-03> In MSF, the T is replaced by the length slotframe 1. String s > is > draft-03> replaced by the mote EUI64 address. The characters of the > string c0, > draft-03> c1, ..., c7 are the 8 bytes of EUI64 address. > > This may be misleading. The first sentence could be... > > For slotOffset(), T is the length of the slotframe 1. For > channelOffset(), T is the number of available channels. > > TC: Will be applied in next verison. Thanks! > > [minor comment #4] > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 > draft-03> The second input parameter defines the maxmium return value of > the > draft-03> hash function. There are other optional parameters defined in > SAX > draft-03> determines the performance of SAX hash function. Those > parameters > draft-03> could be broadcasted in EB frame or pre-configured. > > What parameters...? The parameters to configure are be h0, l_bit, > and r_bit, I believe. > TC: yes, I didn't say that but presented in the example section. Maybe I should mention there though. > > By the way, s/maxmium/maximum/ > TC: will be fixed! Thanks! > > > [minor comment #5] > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 > draft-03> Implementors MAY choose to create the same counters for each > draft-03> neighbor, and add them as additional statistics in the neighbor > draft-03> table. > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3 > draft-03> Implementors MAY choose to maintain the same counters for each > draft-03> managed cell in the schedule. > > For what purposes? Do we need these sentences? > TC: For parent selection. In case parent switching happens, those counters can record the link quality of previous parent for future parent selection. > > > [minor comment #6] > Want to have test vectors of SAX! :-) > > TC: like givem a node EUI64 address, to have the slotoffset and choffset? we could. > > [minor comment #7] > > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 > draft-03> * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to > add a > draft-03> single cell to the preferred parent > draft-03> * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to > remove a > draft-03> single cell to the preferred parent > > It would be better to put "managed" there: > > proposed> * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to > add a > proposed> single managed cell to the preferred parent > proposed> * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to > remove a > proposed> single managed cell to the preferred parent > TC: will put in next version! > > > [minor comment #8] > > s/Tx Cell/TX cell/ > s/Tx cell/TX cell/ > TC: Will go through the text in the next version about the consistency! Thanks! > > Best, > Yatch > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Chang Tengfei, Postdoctoral Research Engineer, Inria --000000000000cc934d0586bb1ee9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yatch,=C2=A0

Thanks for the reviewing! I will reply your comments = inline.

On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> wrote:
Thank you, the authors!<= br>
I confirmed most of my comments to the previous version have been
addressed. It reads better :-)

Here are my comments: two comments are major, the rest are minor.


[major: usage of the autonomous cell and the managed cell]

The draft specifies rules what type of frames MUST be sent over the
autonomous cell. How can we implement the rules on top of TSCH MAC
defined by IEEE802.15.4?

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 The traffic on the autonomous cells are scheduled as: draft-03>
draft-03>=C2=A0 o=C2=A0 Join Request packets and 6P ADD/DELETE Request f= rames to the
draft-03>=C2=A0 =C2=A0 =C2=A0node's Join Proxy or its RPL routing pa= rent MUST be sent on
draft-03>=C2=A0 =C2=A0 =C2=A0AutoUpCell.
draft-03>=C2=A0 o=C2=A0 Join Response packets and 6P ADD/DELETE Response= frames to the
draft-03>=C2=A0 =C2=A0 =C2=A0pledge or its RPL routing child MUST be sen= t on AutoDownCell.
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Request frames to the node's RPL= routing child MUST be
draft-03>=C2=A0 =C2=A0 =C2=A0sent on AutoDownCell.
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Response frames to its RPL routing p= arent MUST be sent
draft-03>=C2=A0 =C2=A0 =C2=A0on AutoUpCell.

TC: For implementing, it requires some flag for the frame to mark a= s what type of 6P frames.=C2=A0
TC: I agree that there are other = frames that should be able to send on the autonomous cell according to IEEE= 802.15.4 standards.
TC: Here is to limit the type frames on one c= ell but it doesn't break what defined in IEEE802.15.4 standards, IMO.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0Adding/removing/relocating cells involves exchangi= ng frames that
draft-03>=C2=A0 =C2=A0contain 6P commands.=C2=A0 All 6P Request frames t= o its parent MUST be
draft-03>=C2=A0 =C2=A0sent on the AutoUpCell All 6P Response frames to n= on-parent neighbor
draft-03>=C2=A0 =C2=A0MUST be sent on AutoDownCell.

At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell
to the same neighbor are used without distinction. This is totally
fine and straightforward. Why do we need the change to this part?

TC: this is to avoid the failure of 6P frames on= inconsistent managed cell, for example, the node has a Tx cell to parent b= ut the parent doesn't have the RX cell.
TC: Though, it will b= e resolved at next 6P transaction (two transactions actually), it will be u= nderperformance.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-02#section-5.1
draft-02>=C2=A0 =C2=A0Autonomous cells are used indistinguishably
draft-02>=C2=A0 =C2=A0together with dedicated cells, for broadcast or un= icast traffic with
draft-02>=C2=A0 =C2=A0the target neighbor.=C2=A0 The procedure to remove= autonomous cells is
draft-02>=C2=A0 =C2=A0described in Section 3.

To my understandings, TSCH MAC selects a cell (link) to transmit a
frame seeing macTxType, macLinkType, and macNodeAddress of the cell,
which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC
cares only the destination MAC address and the frame type of a TX
frame, doesn't it?

TC: It does in IEEE802.15.4 standard.
TC: I= am just not considering instead of caring only the destination MAC address= and frame type, caring about more parameters is not a violation of standar= d.=C2=A0
TC: Though, just in my opinion.=C2=A0

[major: some confusions in Section 5]

We don't need to maintain NumCellsElapsed and NumCellsUsed for RX
cells because managed cells have always only TX=3D1.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0NumCellsElapsed :=C2=A0 Counts the number of manag= ed cells that have
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0elapsed since the counter was initia= lized.=C2=A0 This counter is
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0initialized at 0.=C2=A0 Each time th= e TSCH state machine indicates
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0that the current cell is a managed c= ell to the preferred parent,
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0NumCellsElapsed is incremented by ex= actly 1, regardless of
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0whether the cell is used to transmit= /receive a frame.

"to transmit/receive a frame" in the last sentence should be repl= aced
with "to transmit a frame", and

draft-03>=C2=A0 =C2=A0Both NumCellsElapsed and NumCellsUsed counters can= be used to cell
draft-03>=C2=A0 =C2=A0with cell option TX=3D1 or RX=3D1.

"with cell option TX=3D1 or RX=3D1" should be replaced with "= ;with cell
option TX=3D1"?

Another thing is related to what Fabrice pointed out. There is
something wrong in text about the RELOCATE operation. Since NumTx and
NumTxAck are the key counters for the RELOCATE operation, a RELOCATE
request is never issued for an RX cell. Then, the direction in the
following text is opposite...

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Request frames to the node's RPL= routing child MUST be
draft-03>=C2=A0 =C2=A0 =C2=A0sent on AutoDownCell.
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Response frames to its RPL routing p= arent MUST be sent
draft-03>=C2=A0 =C2=A0 =C2=A0on AutoUpCell.

TC: yes, accepted this comment.=C2=A0
TC: As replied to F= abrice, I will remove the RX=3D1 cell case for the adapting traffic strateg= y in next version..

One more thing:

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.3
draft-03>=C2=A0 4.=C2=A0 For any other cell, it compares its PDR against= that of the cell
draft-03>=C2=A0 =C2=A0 =C2=A0 with the highest PDR.=C2=A0 If the differe= nt is less than
draft-03>=C2=A0 =C2=A0 =C2=A0 RELOCATE_PDRTHRES, it triggers the relocat= ion of that cell using
draft-03>=C2=A0 =C2=A0 =C2=A0 a 6P RELOCATE command.

- s/different/difference/
- s/less than/larger than/ ??

Can you check the entire text in Section 5?

=
TC: sure. Sorry for the confusing! Will be clarified in next version.= =C2=A0


[minor comment #1]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-2
draft-03>=C2=A0 =C2=A0For example, a Trickle Timer defined in [RFC6550] = MAY be
draft-03>=C2=A0 =C2=A0applied on DIOs.

Do we need "MAY" here? If you implement RFC6550, DIO is automatic= ally
controlled by Trickle Timer.

TC: yes, it's a requirement.=C2=A0

[minor comment #2]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 =C2=A0MUST use the hash function SAX [SAX-DASFAA].=C2=A0= The coordinates are
draft-03>=C2=A0 =C2=A0computed to distribute the cells across all channe= l offsets, and all
draft-03>=C2=A0 =C2=A0but the first time offsets of Slotframe 1.=C2=A0 T= he first time offset is
draft-03>=C2=A0 =C2=A0skipped to avoid colliding with the minimal cell i= n Slotframe 0.

s/time offset/slot offset/

TC: Thanks! I will go over the draft to make sure thi= s is consistent.=C2=A0

[minor comment #3]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 =C2=A0 o=C2=A0 slotOffset(MAC) =3D 1 + hash(EUI64, lengt= h(Slotframe_1) - 1)
draft-03>=C2=A0 =C2=A0 o=C2=A0 channelOffset(MAC) =3D hash(EUI64, 16) draft-03>
draft-03>=C2=A0 =C2=A0 The second input parameter defines the maxmium re= turn value of the
draft-03>=C2=A0 =C2=A0 hash function.

The second input should be "the maximum return value plus 1", whi= ch
is the parameter 'T' of SAX.
=C2=A0
= TC: That's correct! Will be fixed.

https://tools.ietf.org/html/draft-iet= f-6tisch-msf-03#appendix-B
draft-03>=C2=A0 =C2=A0In MSF, the T is replaced by the length slotframe = 1.=C2=A0 String s is
draft-03>=C2=A0 =C2=A0replaced by the mote EUI64 address.=C2=A0 The char= acters of the string c0,
draft-03>=C2=A0 =C2=A0c1, ..., c7 are the 8 bytes of EUI64 address.

This may be misleading. The first sentence could be...

=C2=A0 For slotOffset(), T is the length of the slotframe 1. For
=C2=A0 channelOffset(), T is the number of available channels.

TC: Will be applied in next verison. Thanks!=C2=A0

[minor comment #4]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 =C2=A0The second input parameter defines the maxmium ret= urn value of the
draft-03>=C2=A0 =C2=A0hash function.=C2=A0 There are other optional para= meters defined in SAX
draft-03>=C2=A0 =C2=A0determines the performance of SAX hash function.= =C2=A0 Those parameters
draft-03>=C2=A0 =C2=A0could be broadcasted in EB frame or pre-configured= .

What parameters...? The parameters to configure are be h0, l_bit,
and r_bit, I believe.

TC: yes, I didn&#= 39;t say that but presented in the example section. Maybe I should mention = there though.

By the way, s/maxmium/maximum/

TC: will= be fixed! Thanks!=C2=A0


[minor comment #5]

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0Implementors MAY choose to create the same counter= s for each
draft-03>=C2=A0 =C2=A0neighbor, and add them as additional statistics in= the neighbor
draft-03>=C2=A0 =C2=A0table.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.3
draft-03>=C2=A0 =C2=A0Implementors MAY choose to maintain the same count= ers for each
draft-03>=C2=A0 =C2=A0managed cell in the schedule.

For what purposes? Do we need these sentences?

TC: For parent selection. In case parent switching happens, those c= ounters can record the link quality of previous parent for future parent se= lection.


[minor comment #6]
Want to have test vectors of SAX! :-)

TC: like givem a node EUI64 address, to have the slot= offset and choffset? we could.=C2=A0=C2=A0

[minor comment #7]


https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed > LIM_NUM= CELLSUSED_HIGH, trigger 6P to add a
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single cell to the preferred= parent
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed < LIM_NUM= CELLSUSED_LOW, trigger 6P to remove a
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single cell to the preferred= parent

It would be better to put "managed" there:

proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed > LIM_NUM= CELLSUSED_HIGH, trigger 6P to add a
proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single managed cell to the p= referred parent
proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed < LIM_NUM= CELLSUSED_LOW, trigger 6P to remove a
proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single managed cell to the p= referred parent

TC: will put in next ve= rsion!


[minor comment #8]

s/Tx Cell/TX cell/
s/Tx cell/TX cell/

TC: Will go through = the text in the next version about the consistency! Thanks!

Best,
Yatch

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch


--
Chang Tengfei,
<= span style=3D"font-size:12.8px">
Postdoctoral Research Enginee= r, Inria
--000000000000cc934d0586bb1ee9-- From nobody Wed Apr 17 09:50:51 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F211120143 for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vop1FKoiJZl0 for <6tisch@ietfa.amsl.com>; Wed, 17 Apr 2019 09:50:46 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 6A22312001E for <6tisch@ietf.org>; Wed, 17 Apr 2019 09:50:46 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id j26so12263487pgl.5 for <6tisch@ietf.org>; Wed, 17 Apr 2019 09:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mfG3PZAbmwJ6ag6o3BY9mosZDr/ZZ89R56zccKqmg9w=; b=rs1O+waf3DZNIWuktpEvH4dpkkpiRxWFGJDua3BBtlUk657Aq2kTxb7TAqQ3OyEjtw GJYZmOLqR1Y4gLZf4cZvxl21AHY+O8GTqfZ4b0T4jOoNdb2bGCK+IYkjqsLBCVoRNM6p Mq0jpTzO/Vfi+W94UVHRgRuWnF0VxZp6UcXvePoT4JdCcpZ1HBBa0GcB7OdATh0Pl8mt 8oeLw3TAzcAl6XBqew8sTC74r1o89EAISrAF372yHBCynvEgpFzrQsmxRqhvaOfR2Gaq XkmP4VV+4H9wzh7BmLKp1VGfhimA2R5YoImXLs5xFr3t+b4kfEg3KiTO2pd52g/KBSkg oyFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mfG3PZAbmwJ6ag6o3BY9mosZDr/ZZ89R56zccKqmg9w=; b=D7qtYmiODP094GT1mn9OYNF4J7bp1u/X/PsWLh/wNgEqN4xxKux16VsKZr610OrvIt klOFUOvQ188uGxznbvR8cPutWkEa3ENhleCXDDn/jU+KEd5BkVupAXl5cqdzQyaEthcT PEjY6E3IWPfCQ8OJyXxfmPly7Bv5caOQ3UIbeaT0T6YBgnb/abyAhY2l+wZnKXemxnJ5 POSlXeoZzvmX71N+FTFbFq8rR1Enu9sR7KT2e4CgtcKusXwl2f8JMnsPbLjvhgsZHpHM OM8Z3jSOE+tVqXflOnQBSl6zBOgG/Y8xbsOL5pEVMqLFc43bK3B9n7AGVTTf7WSLbH2c 4CdA== X-Gm-Message-State: APjAAAUjFd9JygWbvIK4zhV8NaBQfYWzGH7mmtaJMxEg0KxyPO6F2lgu TAky9Nbq+SpApK0IN/mR0h7Zl3eBKWzS1SYuOJo= X-Google-Smtp-Source: APXvYqyPsf8tLuR/FK2Gh78sqwVtRJoMy+Gf0i/OiWoHMChAqce9aZ8SCIFcEiv2/Tk0yCGUBgx7ZEcGj6EYHLKZ9IA= X-Received: by 2002:a65:4247:: with SMTP id d7mr78901715pgq.114.1555519845556; Wed, 17 Apr 2019 09:50:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Wed, 17 Apr 2019 18:50:32 +0200 Message-ID: To: Yasuyuki Tanaka Cc: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5e5fd0586bcaf81" Archived-At: Subject: Re: [6tisch] Review of draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 16:50:50 -0000 --000000000000d5e5fd0586bcaf81 Content-Type: text/plain; charset="UTF-8" After talking with Yatch, I realize I misunderstand the first comments: (Yatch, please correct me if I said something wrong.) For the join request/response, they are only sent on autonomous cell at the first hop, after that, they are OK to sent on managed cell since the node will only recognize the packet as IPv6. For the 6P request/response, There are two aspects we are concerning: 1. standard-complaint : now I am concerning it may be not standard-complaint with IEEE802.15.4. The TSCH MAC layer shouldn't be able to aware whether it's 6P or not and what is the type of it. 2. performance: we agreed that either allowing send 6P on managed cell or not will work. Put the standard-complaint issue on the side, it's only performance concern. What I consider is if a 6P cell inconsistency happens, sending 6P on managed cell may consume the number of re-transmission chance. For example, node A has a Tx cell to node B, but node B doesn't have a Rx cell to node A. If node A wants to add another cell to node B by issuing a 6P ADD request, the 6P ADD request If 6P ADD request send on autoUpCell successfully, then there is no problem. If not, the ADD request will be sent later on the Tx cell but will be failed because of inconsistent. If there is other managed Tx Cell, the performance will be better. If not, the ADD request will try to send on autoUpCell again but because of backoof algorithm, it will skip it and try to send on the inconsistent Tx cell again. The number of re-transmission will be consumed on the Tx cell and probably failed finally. As a conclusion, making sure only regulating the traffic on autonomous cell is standard complaint or not is primary. I want to have more comments on this. @Tero, @Pat, @pascal any comment on this? Tengfei On Wed, Apr 17, 2019 at 4:58 PM Tengfei Chang wrote: > Hi Yatch, > > Thanks for the reviewing! I will reply your comments inline. > > On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka > wrote: > >> Thank you, the authors! >> >> I confirmed most of my comments to the previous version have been >> addressed. It reads better :-) >> >> Here are my comments: two comments are major, the rest are minor. >> >> >> [major: usage of the autonomous cell and the managed cell] >> >> The draft specifies rules what type of frames MUST be sent over the >> autonomous cell. How can we implement the rules on top of TSCH MAC >> defined by IEEE802.15.4? >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 >> draft-03> The traffic on the autonomous cells are scheduled as: >> draft-03> >> draft-03> o Join Request packets and 6P ADD/DELETE Request frames to the >> draft-03> node's Join Proxy or its RPL routing parent MUST be sent on >> draft-03> AutoUpCell. >> draft-03> o Join Response packets and 6P ADD/DELETE Response frames to >> the >> draft-03> pledge or its RPL routing child MUST be sent on >> AutoDownCell. >> draft-03> o 6P RELOCATE Request frames to the node's RPL routing child >> MUST be >> draft-03> sent on AutoDownCell. >> draft-03> o 6P RELOCATE Response frames to its RPL routing parent MUST >> be sent >> draft-03> on AutoUpCell. >> > > TC: For implementing, it requires some flag for the frame to mark as what > type of 6P frames. > TC: I agree that there are other frames that should be able to send on the > autonomous cell according to IEEE802.15.4 standards. > TC: Here is to limit the type frames on one cell but it doesn't break what > defined in IEEE802.15.4 standards, IMO. > >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 >> draft-03> Adding/removing/relocating cells involves exchanging frames >> that >> draft-03> contain 6P commands. All 6P Request frames to its parent >> MUST be >> draft-03> sent on the AutoUpCell All 6P Response frames to non-parent >> neighbor >> draft-03> MUST be sent on AutoDownCell. >> >> At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell >> to the same neighbor are used without distinction. This is totally >> fine and straightforward. Why do we need the change to this part? >> > > TC: this is to avoid the failure of 6P frames on inconsistent managed > cell, for example, the node has a Tx cell to parent but the parent doesn't > have the RX cell. > TC: Though, it will be resolved at next 6P transaction (two transactions > actually), it will be underperformance. > >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1 >> draft-02> Autonomous cells are used indistinguishably >> draft-02> together with dedicated cells, for broadcast or unicast >> traffic with >> draft-02> the target neighbor. The procedure to remove autonomous >> cells is >> draft-02> described in Section 3. >> >> To my understandings, TSCH MAC selects a cell (link) to transmit a >> frame seeing macTxType, macLinkType, and macNodeAddress of the cell, >> which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC >> cares only the destination MAC address and the frame type of a TX >> frame, doesn't it? >> >> TC: It does in IEEE802.15.4 standard. > TC: I am just not considering instead of caring only the destination MAC > address and frame type, caring about more parameters is not a violation of > standard. > TC: Though, just in my opinion. > >> >> [major: some confusions in Section 5] >> >> We don't need to maintain NumCellsElapsed and NumCellsUsed for RX >> cells because managed cells have always only TX=1. >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 >> draft-03> NumCellsElapsed : Counts the number of managed cells that >> have >> draft-03> elapsed since the counter was initialized. This counter >> is >> draft-03> initialized at 0. Each time the TSCH state machine >> indicates >> draft-03> that the current cell is a managed cell to the preferred >> parent, >> draft-03> NumCellsElapsed is incremented by exactly 1, regardless of >> draft-03> whether the cell is used to transmit/receive a frame. >> >> "to transmit/receive a frame" in the last sentence should be replaced >> with "to transmit a frame", and >> >> draft-03> Both NumCellsElapsed and NumCellsUsed counters can be used to >> cell >> draft-03> with cell option TX=1 or RX=1. >> >> "with cell option TX=1 or RX=1" should be replaced with "with cell >> option TX=1"? >> >> Another thing is related to what Fabrice pointed out. There is >> something wrong in text about the RELOCATE operation. Since NumTx and >> NumTxAck are the key counters for the RELOCATE operation, a RELOCATE >> request is never issued for an RX cell. Then, the direction in the >> following text is opposite... >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 >> draft-03> o 6P RELOCATE Request frames to the node's RPL routing child >> MUST be >> draft-03> sent on AutoDownCell. >> draft-03> o 6P RELOCATE Response frames to its RPL routing parent MUST >> be sent >> draft-03> on AutoUpCell. >> > > TC: yes, accepted this comment. > TC: As replied to Fabrice, I will remove the RX=1 cell case for the > adapting traffic strategy in next version.. > >> >> One more thing: >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3 >> draft-03> 4. For any other cell, it compares its PDR against that of >> the cell >> draft-03> with the highest PDR. If the different is less than >> draft-03> RELOCATE_PDRTHRES, it triggers the relocation of that cell >> using >> draft-03> a 6P RELOCATE command. >> >> - s/different/difference/ >> - s/less than/larger than/ ?? >> >> Can you check the entire text in Section 5? >> > > TC: sure. Sorry for the confusing! Will be clarified in next version. > >> >> >> [minor comment #1] >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-2 >> draft-03> For example, a Trickle Timer defined in [RFC6550] MAY be >> draft-03> applied on DIOs. >> >> Do we need "MAY" here? If you implement RFC6550, DIO is automatically >> controlled by Trickle Timer. >> >> TC: yes, it's a requirement. > >> >> [minor comment #2] >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 >> draft-03> MUST use the hash function SAX [SAX-DASFAA]. The coordinates >> are >> draft-03> computed to distribute the cells across all channel offsets, >> and all >> draft-03> but the first time offsets of Slotframe 1. The first time >> offset is >> draft-03> skipped to avoid colliding with the minimal cell in Slotframe >> 0. >> >> s/time offset/slot offset/ >> >> TC: Thanks! I will go over the draft to make sure this is consistent. > >> >> [minor comment #3] >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 >> draft-03> o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) >> draft-03> o channelOffset(MAC) = hash(EUI64, 16) >> draft-03> >> draft-03> The second input parameter defines the maxmium return value >> of the >> draft-03> hash function. >> >> The second input should be "the maximum return value plus 1", which >> is the parameter 'T' of SAX. >> > > TC: That's correct! Will be fixed. > >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#appendix-B >> draft-03> In MSF, the T is replaced by the length slotframe 1. String >> s is >> draft-03> replaced by the mote EUI64 address. The characters of the >> string c0, >> draft-03> c1, ..., c7 are the 8 bytes of EUI64 address. >> >> This may be misleading. The first sentence could be... >> >> For slotOffset(), T is the length of the slotframe 1. For >> channelOffset(), T is the number of available channels. >> >> TC: Will be applied in next verison. Thanks! > >> >> [minor comment #4] >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3 >> draft-03> The second input parameter defines the maxmium return value >> of the >> draft-03> hash function. There are other optional parameters defined >> in SAX >> draft-03> determines the performance of SAX hash function. Those >> parameters >> draft-03> could be broadcasted in EB frame or pre-configured. >> >> What parameters...? The parameters to configure are be h0, l_bit, >> and r_bit, I believe. >> > > TC: yes, I didn't say that but presented in the example section. Maybe I > should mention there though. > >> >> By the way, s/maxmium/maximum/ >> > > TC: will be fixed! Thanks! > >> >> >> [minor comment #5] >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 >> draft-03> Implementors MAY choose to create the same counters for each >> draft-03> neighbor, and add them as additional statistics in the >> neighbor >> draft-03> table. >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3 >> draft-03> Implementors MAY choose to maintain the same counters for each >> draft-03> managed cell in the schedule. >> >> For what purposes? Do we need these sentences? >> > > TC: For parent selection. In case parent switching happens, those counters > can record the link quality of previous parent for future parent selection. > >> >> >> [minor comment #6] >> Want to have test vectors of SAX! :-) >> >> TC: like givem a node EUI64 address, to have the slotoffset and choffset? > we could. > >> >> [minor comment #7] >> >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1 >> draft-03> * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to >> add a >> draft-03> single cell to the preferred parent >> draft-03> * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to >> remove a >> draft-03> single cell to the preferred parent >> >> It would be better to put "managed" there: >> >> proposed> * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to >> add a >> proposed> single managed cell to the preferred parent >> proposed> * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to >> remove a >> proposed> single managed cell to the preferred parent >> > > TC: will put in next version! > >> >> >> [minor comment #8] >> >> s/Tx Cell/TX cell/ >> s/Tx cell/TX cell/ >> > > TC: Will go through the text in the next version about the consistency! > Thanks! > >> >> Best, >> Yatch >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > > -- > Chang Tengfei, > Postdoctoral Research Engineer, Inria > -- Chang Tengfei, Postdoctoral Research Engineer, Inria --000000000000d5e5fd0586bcaf81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After talking with Yatch, I realize I misunderstand the fi= rst comments: (Yatch, please correct me if I said something wrong.)
For the join request/response, they are only sent on autonomous= cell at the first hop, after that, they are OK to sent on managed cell sin= ce the node will only recognize the packet as IPv6.
For the 6P re= quest/response,

There are two aspects we are conce= rning:

1. standard-complaint : now I am concerning= it may be not standard-complaint with IEEE802.15.4. The TSCH MAC layer sho= uldn't be able to aware whether it's 6P or not and what is the type= of it.
2. performance: we agreed that either allowing send 6P on= managed cell or not will work. Put the standard-complaint issue on the sid= e, it's only performance concern.

What I consi= der is if a 6P cell inconsistency happens, sending 6P on managed cell may c= onsume the number of re-transmission chance.

For e= xample, node A has a Tx cell to node B, but node B doesn't have a Rx ce= ll to node A.
If node A wants to add another cell to node B b= y issuing a 6P ADD request, the 6P ADD request
If 6P ADD req= uest send on autoUpCell successfully, then there is no problem.
I= f not,=C2=A0 the ADD request will be sent later on the Tx cell but will be = failed because of inconsistent.=C2=A0
If there is other managed T= x Cell, the performance will be better.
If not, the ADD request w= ill try to send on autoUpCell again but because of backoof algorithm, it wi= ll skip it and try to send on the inconsistent Tx cell again.
The= number of re-transmission will be consumed on the Tx cell and probably fai= led finally.=C2=A0

As a conclusion, making sure on= ly regulating the traffic on autonomous cell is standard complaint or not i= s primary.
I want to have more comments on this.=C2=A0
= @Tero,=C2=A0@Pat,=C2=A0@pascal=C2=A0any comment on this?

Tengfe= i


On Wed, Apr 17, 2019 at 4:58 PM Tengfei Chang= <tengfei.chang@gmail.com= > wrote:
Hi Yatch,=C2=A0

Thanks for the reviewing! I will reply your comments inli= ne.

On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> w= rote:
Thank you,= the authors!

I confirmed most of my comments to the previous version have been
addressed. It reads better :-)

Here are my comments: two comments are major, the rest are minor.


[major: usage of the autonomous cell and the managed cell]

The draft specifies rules what type of frames MUST be sent over the
autonomous cell. How can we implement the rules on top of TSCH MAC
defined by IEEE802.15.4?

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 The traffic on the autonomous cells are scheduled as: draft-03>
draft-03>=C2=A0 o=C2=A0 Join Request packets and 6P ADD/DELETE Request f= rames to the
draft-03>=C2=A0 =C2=A0 =C2=A0node's Join Proxy or its RPL routing pa= rent MUST be sent on
draft-03>=C2=A0 =C2=A0 =C2=A0AutoUpCell.
draft-03>=C2=A0 o=C2=A0 Join Response packets and 6P ADD/DELETE Response= frames to the
draft-03>=C2=A0 =C2=A0 =C2=A0pledge or its RPL routing child MUST be sen= t on AutoDownCell.
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Request frames to the node's RPL= routing child MUST be
draft-03>=C2=A0 =C2=A0 =C2=A0sent on AutoDownCell.
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Response frames to its RPL routing p= arent MUST be sent
draft-03>=C2=A0 =C2=A0 =C2=A0on AutoUpCell.

TC: For implementing, it requires some flag for the frame to mark a= s what type of 6P frames.=C2=A0
TC: I agree that there are other = frames that should be able to send on the autonomous cell according to IEEE= 802.15.4 standards.
TC: Here is to limit the type frames on one c= ell but it doesn't break what defined in IEEE802.15.4 standards, IMO.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0Adding/removing/relocating cells involves exchangi= ng frames that
draft-03>=C2=A0 =C2=A0contain 6P commands.=C2=A0 All 6P Request frames t= o its parent MUST be
draft-03>=C2=A0 =C2=A0sent on the AutoUpCell All 6P Response frames to n= on-parent neighbor
draft-03>=C2=A0 =C2=A0MUST be sent on AutoDownCell.

At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell
to the same neighbor are used without distinction. This is totally
fine and straightforward. Why do we need the change to this part?

TC: this is to avoid the failure of 6P frames on= inconsistent managed cell, for example, the node has a Tx cell to parent b= ut the parent doesn't have the RX cell.
TC: Though, it will b= e resolved at next 6P transaction (two transactions actually), it will be u= nderperformance.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-02#section-5.1
draft-02>=C2=A0 =C2=A0Autonomous cells are used indistinguishably
draft-02>=C2=A0 =C2=A0together with dedicated cells, for broadcast or un= icast traffic with
draft-02>=C2=A0 =C2=A0the target neighbor.=C2=A0 The procedure to remove= autonomous cells is
draft-02>=C2=A0 =C2=A0described in Section 3.

To my understandings, TSCH MAC selects a cell (link) to transmit a
frame seeing macTxType, macLinkType, and macNodeAddress of the cell,
which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC
cares only the destination MAC address and the frame type of a TX
frame, doesn't it?

TC: It does in IEEE802.15.4 standard.
TC: I= am just not considering instead of caring only the destination MAC address= and frame type, caring about more parameters is not a violation of standar= d.=C2=A0
TC: Though, just in my opinion.=C2=A0

[major: some confusions in Section 5]

We don't need to maintain NumCellsElapsed and NumCellsUsed for RX
cells because managed cells have always only TX=3D1.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0NumCellsElapsed :=C2=A0 Counts the number of manag= ed cells that have
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0elapsed since the counter was initia= lized.=C2=A0 This counter is
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0initialized at 0.=C2=A0 Each time th= e TSCH state machine indicates
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0that the current cell is a managed c= ell to the preferred parent,
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0NumCellsElapsed is incremented by ex= actly 1, regardless of
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0whether the cell is used to transmit= /receive a frame.

"to transmit/receive a frame" in the last sentence should be repl= aced
with "to transmit a frame", and

draft-03>=C2=A0 =C2=A0Both NumCellsElapsed and NumCellsUsed counters can= be used to cell
draft-03>=C2=A0 =C2=A0with cell option TX=3D1 or RX=3D1.

"with cell option TX=3D1 or RX=3D1" should be replaced with "= ;with cell
option TX=3D1"?

Another thing is related to what Fabrice pointed out. There is
something wrong in text about the RELOCATE operation. Since NumTx and
NumTxAck are the key counters for the RELOCATE operation, a RELOCATE
request is never issued for an RX cell. Then, the direction in the
following text is opposite...

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Request frames to the node's RPL= routing child MUST be
draft-03>=C2=A0 =C2=A0 =C2=A0sent on AutoDownCell.
draft-03>=C2=A0 o=C2=A0 6P RELOCATE Response frames to its RPL routing p= arent MUST be sent
draft-03>=C2=A0 =C2=A0 =C2=A0on AutoUpCell.

TC: yes, accepted this comment.=C2=A0
TC: As replied to F= abrice, I will remove the RX=3D1 cell case for the adapting traffic strateg= y in next version..

One more thing:

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.3
draft-03>=C2=A0 4.=C2=A0 For any other cell, it compares its PDR against= that of the cell
draft-03>=C2=A0 =C2=A0 =C2=A0 with the highest PDR.=C2=A0 If the differe= nt is less than
draft-03>=C2=A0 =C2=A0 =C2=A0 RELOCATE_PDRTHRES, it triggers the relocat= ion of that cell using
draft-03>=C2=A0 =C2=A0 =C2=A0 a 6P RELOCATE command.

- s/different/difference/
- s/less than/larger than/ ??

Can you check the entire text in Section 5?

=
TC: sure. Sorry for the confusing! Will be clarified in next version.= =C2=A0


[minor comment #1]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-2
draft-03>=C2=A0 =C2=A0For example, a Trickle Timer defined in [RFC6550] = MAY be
draft-03>=C2=A0 =C2=A0applied on DIOs.

Do we need "MAY" here? If you implement RFC6550, DIO is automatic= ally
controlled by Trickle Timer.

TC: yes, it's a requirement.=C2=A0

[minor comment #2]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 =C2=A0MUST use the hash function SAX [SAX-DASFAA].=C2=A0= The coordinates are
draft-03>=C2=A0 =C2=A0computed to distribute the cells across all channe= l offsets, and all
draft-03>=C2=A0 =C2=A0but the first time offsets of Slotframe 1.=C2=A0 T= he first time offset is
draft-03>=C2=A0 =C2=A0skipped to avoid colliding with the minimal cell i= n Slotframe 0.

s/time offset/slot offset/

TC: Thanks! I will go over the draft to make sure thi= s is consistent.=C2=A0

[minor comment #3]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 =C2=A0 o=C2=A0 slotOffset(MAC) =3D 1 + hash(EUI64, lengt= h(Slotframe_1) - 1)
draft-03>=C2=A0 =C2=A0 o=C2=A0 channelOffset(MAC) =3D hash(EUI64, 16) draft-03>
draft-03>=C2=A0 =C2=A0 The second input parameter defines the maxmium re= turn value of the
draft-03>=C2=A0 =C2=A0 hash function.

The second input should be "the maximum return value plus 1", whi= ch
is the parameter 'T' of SAX.
=C2=A0
= TC: That's correct! Will be fixed.

https://tools.ietf.org/html/draft-iet= f-6tisch-msf-03#appendix-B
draft-03>=C2=A0 =C2=A0In MSF, the T is replaced by the length slotframe = 1.=C2=A0 String s is
draft-03>=C2=A0 =C2=A0replaced by the mote EUI64 address.=C2=A0 The char= acters of the string c0,
draft-03>=C2=A0 =C2=A0c1, ..., c7 are the 8 bytes of EUI64 address.

This may be misleading. The first sentence could be...

=C2=A0 For slotOffset(), T is the length of the slotframe 1. For
=C2=A0 channelOffset(), T is the number of available channels.

TC: Will be applied in next verison. Thanks!=C2=A0

[minor comment #4]

https://tools.ietf.org/html/draft-ietf= -6tisch-msf-03#section-3
draft-03>=C2=A0 =C2=A0The second input parameter defines the maxmium ret= urn value of the
draft-03>=C2=A0 =C2=A0hash function.=C2=A0 There are other optional para= meters defined in SAX
draft-03>=C2=A0 =C2=A0determines the performance of SAX hash function.= =C2=A0 Those parameters
draft-03>=C2=A0 =C2=A0could be broadcasted in EB frame or pre-configured= .

What parameters...? The parameters to configure are be h0, l_bit,
and r_bit, I believe.

TC: yes, I didn&#= 39;t say that but presented in the example section. Maybe I should mention = there though.

By the way, s/maxmium/maximum/

TC: will= be fixed! Thanks!=C2=A0


[minor comment #5]

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0Implementors MAY choose to create the same counter= s for each
draft-03>=C2=A0 =C2=A0neighbor, and add them as additional statistics in= the neighbor
draft-03>=C2=A0 =C2=A0table.

https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.3
draft-03>=C2=A0 =C2=A0Implementors MAY choose to maintain the same count= ers for each
draft-03>=C2=A0 =C2=A0managed cell in the schedule.

For what purposes? Do we need these sentences?

TC: For parent selection. In case parent switching happens, those c= ounters can record the link quality of previous parent for future parent se= lection.


[minor comment #6]
Want to have test vectors of SAX! :-)

TC: like givem a node EUI64 address, to have the slot= offset and choffset? we could.=C2=A0=C2=A0

[minor comment #7]


https://tools.ietf.org/html/draft-ie= tf-6tisch-msf-03#section-5.1
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed > LIM_NUM= CELLSUSED_HIGH, trigger 6P to add a
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single cell to the preferred= parent
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed < LIM_NUM= CELLSUSED_LOW, trigger 6P to remove a
draft-03>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single cell to the preferred= parent

It would be better to put "managed" there:

proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed > LIM_NUM= CELLSUSED_HIGH, trigger 6P to add a
proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single managed cell to the p= referred parent
proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If NumCellsUsed < LIM_NUM= CELLSUSED_LOW, trigger 6P to remove a
proposed>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single managed cell to the p= referred parent

TC: will put in next ve= rsion!


[minor comment #8]

s/Tx Cell/TX cell/
s/Tx cell/TX cell/

TC: Will go through = the text in the next version about the consistency! Thanks!

Best,
Yatch

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch


--
= Chang Tengfei,
P= ostdoctoral Research Engineer, Inria
=


--
Chang Tengfei,
<= span style=3D"font-size:12.8px">
Postdoctoral Research Enginee= r, Inria
--000000000000d5e5fd0586bcaf81-- From nobody Fri Apr 19 09:05:54 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4FF120302 for <6tisch@ietfa.amsl.com>; Fri, 19 Apr 2019 09:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2dYVddEFgqy for <6tisch@ietfa.amsl.com>; Fri, 19 Apr 2019 09:05:50 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 4D1DB1202FF for <6tisch@ietf.org>; Fri, 19 Apr 2019 09:05:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,370,1549926000"; d="scan'208";a="303439228" Received: from poi92-3-88-190-144-98.fbxo.proxad.net (HELO [192.168.1.14]) ([88.190.144.98]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2019 18:05:48 +0200 From: Yasuyuki Tanaka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> Date: Fri, 19 Apr 2019 18:05:47 +0200 Cc: Yasuyuki Tanaka To: 6tisch@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [6tisch] SeqNum definition in RFC8480 (6P) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 16:05:53 -0000 Hi, I came across a question in RFC8480 (6P), which looks like an error to me... Can anybody help? This is about the SeqNum field of the 6P header. Section 3.2.2 defines SeqNum like this: [https://tools.ietf.org/html/rfc8480#section-3.2.2] > SeqNum: The sequence number associated with the 6P Transaction. > Used to match the 6P Request, 6P Response, and 6P Confirmation > of the same 6P Transaction. So, basically, a response and a confirmation have the same SeqNum value as the corresponding request. This is very normal. However, Section 3.4.6.2 says, if a node detect schedule inconsistency with a received request, the node does a different thing. A response in this case has a different SeqNum value from the corresponding request. This is strange... [https://tools.ietf.org/html/rfc8480#section-3.4.6.2] > If the inconsistency is detected during a 6P Transaction (Figure 31), > the node that has detected it MUST send back a 6P Response or 6P > Confirmation with an error code of RC_ERR_SEQNUM. In this 6P > Response or 6P Confirmation, the SeqNum field MUST be set to the > value of the sender of the message (0 in the example in Figure 31). In Figure 31, Node A receives 6P Response (SeqNum=0, RC_ERR_SEQNUM) in the last part of the message sequence. But, according to the definition by Section 3.2.2, Node A doesn't consider the response to be part of the transaction initiated by 6P Request (SeqNum=88), [https://tools.ietf.org/html/rfc8480#section-3.4.6.2] > +----------+ +----------+ > | Node A | | Node B | > +----+-----+ +-----+----+ > SeqNum=87 | | SeqNum=87 > | | > | 6P Request (SeqNum=87) | > |-------------------------------------->| > | L2 ACK | > |<- - - - - - - - - - - - - - - - - - - | > | | > | 6P Response (SeqNum=87) | > |<--------------------------------------| > | L2 ACK | > | - - - - - - - - - - - - - - - - - - ->| > | ==== power-cycle > | | > SeqNum=88 | | SeqNum=0 > | | > | 6P Request (SeqNum=88) | > |-------------------------------------->| Inconsistency > | L2 ACK | detected > |<- - - - - - - - - - - - - - - - - - - | > | | > | 6P Response (SeqNum=0, RC_ERR_SEQNUM) | > |<--------------------------------------| > | L2 ACK | > | - - - - - - - - - - - - - - - - - - ->| > > Figure 31: Example of Inconsistency Because Node B Resets > (Detected by Node B) If this is an error, I'm going to file an errata entry. Otherwise, I'd like to know why Node B in Figure 31 MUST set 0 to SeqNum for the 6P Response having RC_ERR_SEQNUM. Node A becomes aware of schedule inconsistency anyway, seeing RC_ERR_SEQNUM in the response. By the way, the 5th paragraph in Section 3.4.6 supports Section 3.2.2. The response in an example of the paragraph has the same SeqNum value as the response, which is 0. This is the same case as explained with Figure 32. [https://tools.ietf.org/html/rfc8480#section-3.4.6] > When node B receives a 6P Request from node A with SeqNum equal to 0, > it checks the stored SeqNum for A. If A is a new neighbor, the > stored SeqNum in B will be 0. The transaction can continue. If the > stored SeqNum for A in B is different than 0, a potential > inconsistency is detected. In this case, B MUST return RC_ERR_SEQNUM > with SeqNum=0. The SF of node A MAY decide what to do next, as > described in Section 3.4.6.2. Or, am I just confused...? Best, Yatch From nobody Mon Apr 22 17:52:00 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4834F1202A3 for <6tisch@ietfa.amsl.com>; Mon, 22 Apr 2019 17:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBIVpIYiXuyx for <6tisch@ietfa.amsl.com>; Mon, 22 Apr 2019 17:51:55 -0700 (PDT) Received: from mo-csw.securemx.jp (mo-csw1514.securemx.jp [210.130.202.153]) (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 9882B1202AB for <6tisch@ietf.org>; Mon, 22 Apr 2019 17:51:55 -0700 (PDT) Received: by mo-csw.securemx.jp (mx-mo-csw1514) id x3N0pp3Q021968; Tue, 23 Apr 2019 09:51:51 +0900 X-Iguazu-Qid: 34ts1uRUeIEZeEMY2E X-Iguazu-QSIG: v=2; s=0; t=1555980711; q=34ts1uRUeIEZeEMY2E; m=ygkxPDU93EOP+sTD07hO/zr5AZMFniZJG4gWo7Ebod4= Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) by relay.securemx.jp (mx-mr1513) id x3N0poMq015633; Tue, 23 Apr 2019 09:51:50 +0900 Received: from enc01.localdomain ([106.186.93.100]) by imx2.toshiba.co.jp with ESMTP id x3N0poGt003522; Tue, 23 Apr 2019 09:51:50 +0900 (JST) Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.localdomain with ESMTP id x3N0posk006559; Tue, 23 Apr 2019 09:51:50 +0900 From: To: , <6tisch@ietf.org> Thread-Topic: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 Thread-Index: AQHU7om12W7S4Bn/P0yQjcGYDJ8uE6ZI+KIA Date: Tue, 23 Apr 2019 00:51:46 +0000 X-TSB-HOP: ON Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP authentication-results: spf=none (sender IP is ) smtp.mailfrom=toshio9.ito@toshiba.co.jp; x-originating-ip: [103.91.184.0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4fcccc75-e391-4ad7-0fa2-08d6c785dc97 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:OSAPR01MB5268; x-ms-traffictypediagnostic: OSAPR01MB5268: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(346002)(376002)(366004)(51914003)(189003)(199004)(76176011)(26005)(14454004)(25786009)(99286004)(76116006)(73956011)(5660300002)(486006)(966005)(66946007)(8676002)(53546011)(46636005)(102836004)(6506007)(2501003)(3846002)(110136005)(54896002)(478600001)(66066001)(316002)(2906002)(9686003)(52536014)(7736002)(236005)(6306002)(6116002)(74316002)(53936002)(66446008)(64756008)(66556008)(81156014)(81166006)(55016002)(6246003)(8936002)(66476007)(86362001)(6436002)(74482002)(606006)(229853002)(14444005)(7696005)(476003)(186003)(11346002)(446003)(71190400001)(71200400001)(256004)(33656002)(97736004)(68736007)(7756004); DIR:OUT; SFP:1101; SCL:1; SRVR:OSAPR01MB5268; H:OSAPR01MB3713.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: toshiba.co.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5ns/zuV2lBQ3123p+AXHP60XGGVaHJoXKXsA1KAP7mb+lY6GhRkZneo+6k58sQGj8zcwQjgG4DRFfgPWy8UEEWsnQjBbGIJw1HrAooxP1JI58M6N1tOEU32KhpGgA/CWdTHFex9xYdIoPFhAbneV8ZpHHWoaZLaRwiDDn+NTSmFjQDUt/cYDCx4NkWGcAlE6QsfYbuxfP7Rfzz08ZIcaoq8438uq6mI9lVP5qK64JvCwCRgSezhA9+qXhiTEU8jEt9qiT7zz8gkPGNMbijgA9aiY8UORJtqaPFnBzDhTLg9otxnCCDqQeAEYqHyeouTyWky5a3QOX6JJlNIvIgF60ldShbHUy2tr3IcKrzqt1SCUCtk8F5oTUvAQryIqnbBRY8Ty78tHc5YSOuppLtBkhYq9IIx4Yjr5y0sbE5ZCTUE= Content-Type: multipart/alternative; boundary="_000_OSAPR01MB3713ACD140322CF8D83F1582E5230OSAPR01MB3713jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4fcccc75-e391-4ad7-0fa2-08d6c785dc97 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 00:51:46.4248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB5268 MSSCP.TransferMailToMossAgent: 103 X-OriginatorOrg: toshiba.co.jp Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 00:51:59 -0000 --_000_OSAPR01MB3713ACD140322CF8D83F1582E5230OSAPR01MB3713jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVuZ2ZlaSwNCg0KVGhhbmtzIGZvciB0aGUgd29yay4gVGhlIGRyYWZ0IGxvb2tzIHByb21p c2luZy4NCg0KSSBoYXZlIHR3byBjb21tZW50cyBvbiB0aGUgbWFuYWdlZCBjZWxscy4NCg0KDQoq IE1pbmltdW0gbnVtYmVyIG9mIG1hbmFnZWQgY2VsbHMNCg0KU2VjLiA1LjE6IFJldmlzaW9uIC0w MiBoYWQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZS4NCg0KbXNmLTAyPiBUbyBoYXZlIHRoZSBjb3Vu dGVycyB3b3JraW5nLCBhdCBsZWFzdCBvbmUgdW5pY2FzdCBjZWxsIG5lZWQNCm1zZi0wMj4gdG8g YmUgbWFpbnRhaW5lZCBhbGwgdGhlIHRpbWUgYW5kIG5ldmVyIGJlIHJlbW92ZWQuDQoNCkhvd2V2 ZXIsIHRoaXMgaXMgcmVtb3ZlZCBpbiAtMDMuIFNvLCBJIHRoaW5rIGl0J3MgcG9zc2libGUgdGhh dCBtc2YtMDMNCnJlbW92ZXMgYWxsIG1hbmFnZWQgY2VsbHMsIGFzIGEgcmVzdWx0IG9mIGFkYXB0 YXRpb24gdG8gdGhlDQp0cmFmZmljLiBJcyBpdCBPSz8NCg0KDQoqIERpcmVjdGlvbiBvZiBtYW5h Z2VkIGNlbGxzDQoNCkl0IGxvb2tzIGxpa2UgbWFuYWdlZCBjZWxscyBhcmUgb25seSBmb3IgdXBz dHJlYW0gdHJhZmZpYy4NCg0KSW4gc2VjdGlvbiA0LjYsIHRoZSBqb2luaW5nIG5vZGUgYWRkcyBh IFR4IGNlbGwgdG8gdGhlIHByZWZlcnJlZA0KcGFyZW50Lg0KDQptc2YtMDM+IFRoZW4gaXQgTVVT VCBpc3N1ZSBhIDZQIEFERCBjb21tYW5kIE1VU1QgdG8gdGhhdCBwYXJlbnQsIHdpdGgNCm1zZi0w Mz4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQptc2YtMDM+ICAgIG8gIENlbGxPcHRpb25zOiBzZXQg dG8gVFg9MSxSWD0wLFNIQVJFRD0wDQptc2YtMDM+ICAgIG8gIE51bUNlbGxzOiBzZXQgdG8gMQ0K DQpJbiBzZWN0aW9uIDUuMSwgdGhlIG5vZGUgYWRkcyBhIFR4IGNlbGwgdG8gdGhlIHByZWZlcnJl ZCBwYXJlbnQgdG8NCmFkYXB0IHRvIHRoZSB0cmFmZmljLg0KDQptc2YtMDM+IHRoZSBub2RlIGlz c3VlcyBhIDZQIEFERCBjb21tYW5kIHRvIGl0cyBwcmVmZXJyZWQgcGFyZW50IHRvDQptc2YtMDM+ IGFkZCBvbmUgbWFuYWdlZCBUeCBjZWxsIHRvIHRoZSBUU0NIIHNjaGVkdWxlLg0KDQpCZWNhdXNl IDZQIHRyYW5zYWN0aW9uIGlzIGFsd2F5cyBpbml0aWF0ZWQgZnJvbSB0aGUgY2hpbGQgdG8gdGhl DQpwcmVmZXJyZWQgcGFyZW50LCBhbmQgQ2VsbE9wdGlvbiBpbiA2UCBBREQgcmVxdWVzdCBpcyBh bHdheXMgKD8pIFR4PTENClJYPTAsIHRoZXJlIGlzIG5vIGRvd25zdHJlYW0gbWFuYWdlZCBjZWxs cy4gQXMgYSByZXN1bHQsIGRvd25zdHJlYW0NCnBhY2tldHMgc3VjaCBhcyBEQU8tQUNLIGhhdmUg dG8gdXNlIEF1dG9Eb3duQ2VsbCBvciB0aGUgbWluaW1hbA0KY2VsbC4gSSB0aGluayB3ZSBzaG91 bGQgaGF2ZSBkb3duc3RyZWFtIGNlbGxzLCB0b28uDQoNCg0KQmVzdCByZWdhcmRzLA0KVG9zaGlv IEl0bw0KDQpGcm9tOiA2dGlzY2ggPDZ0aXNjaC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgVGVuZ2ZlaSBDaGFuZw0KU2VudDogVHVlc2RheSwgQXByaWwgMDksIDIwMTkgMTowNiBQTQ0K VG86IDZ0aXNjaEBpZXRmLm9yZw0KU3ViamVjdDogWzZ0aXNjaF0gW0NhbGwgZm9yIFJldmlld10g ZHJhZnQtaWV0Zi02dGlzY2gtbXNmLTAzDQoNCkRlYXIgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9m ICJkcmFmdC1pZXRmLTZ0aXNjaC1tc2YiIGlzIGp1c3QgcHVibGlzaGVkIGF0IGhlcmU6IGh0dHBz Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtNnRpc2NoLW1zZi0wMy50eHQNCg0KVGhpcyB2 ZXJzaW9uIG1haW5seSByZXNvbHZlZCB0aGUgaXNzdWVzIHByZXNlbnRlZCBkdXJpbmcgSUVURiAx MDQgbWVldGluZy4NCkkgd291bGQgbGlrZSB0byBtZW50aW9uIG9uZSBvZiB0aGUgbWFpbiBjaGFu Z2VzIGluIHRoaXMgdmVyc2lvbiBpcyB3ZSByZW1vdmVkIHRoZSBmcmFtZSBwZW5kaW5nIGJpdCBm ZWF0dXJlLg0KDQpJdCdzIGZvciB0d28gcmVhc29uczoNCi0gaXQgd2lsbCBpbmZsdWVuY2UgdGhl ICJhZGFwdCB0byB0cmFmZmljIiBzdHJhdGVneSBvZiBNU0YuDQotIHRoZSAiYWRhcHQgdG8gdHJh ZmZpYyIgc3RyYXRlZ3kgaGFzIHRoZSBhYmlsaXR5IHRvIGhhbmRsZSBidXJzdCB0cmFmZmljIGJ5 IHVzaW5nIGEgc21hbGxlciBNQVhfTlVNQ0VMTFMNCg0KTm93IHdlIGFyZSBjYWxsaW5nIGZvciBy ZXZpZXdzIG9uIHRoZSBuZXcgdmVyc2lvbiBvZiBNU0YhDQpBbnkgY29tbWVudHMgYW5kIGZlZWRi YWNrIGFyZSBhcHByZWNpYXRlZCENCg0KVGVuZ2ZlaQ0KDQoNCg0KLS0NCkNoYW5nIFRlbmdmZWks DQpQb3N0ZG9jdG9yYWwgUmVzZWFyY2ggRW5naW5lZXIsIElucmlhDQo= --_000_OSAPR01MB3713ACD140322CF8D83F1582E5230OSAPR01MB3713jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw 44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQO+8re+8syDvvLDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1 IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDvvLDjgrTjgrfjg4Pj gq8iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwg bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowbW07DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MG1tOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDvvLDjgrTjgrfjg4Pjgq8iO30NCnNwYW4uMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDjgrTj grfjg4Pjgq8iOw0KCWNvbG9yOiMyRjU0OTY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46OTkuMjVw dCAzMC4wbW0gMzAuMG1tIDMwLjBtbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2Ij4NCjx2OnRleHRib3ggaW5zZXQ9IjUu ODVwdCwuN3B0LDUuODVwdCwuN3B0IiAvPg0KPC9vOnNoYXBlZGVmYXVsdHM+PC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkpBIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij5IaSBU ZW5nZmVpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvv vK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44Kv JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPlRoYW5rcyBmb3IgdGhlIHdvcmsuIFRoZSBkcmFmdCBsb29r cyBwcm9taXNpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfj g4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+SSBoYXZlIHR3byBjb21tZW50cyBvbiB0aGUgbWFu YWdlZCBjZWxscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+OD g+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjoj MkY1NDk2Ij4qIE1pbmltdW0gbnVtYmVyIG9mIG1hbmFnZWQgY2VsbHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90 Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij5T ZWMuIDUuMTogUmV2aXNpb24gLTAyIGhhZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD 44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMy RjU0OTYiPm1zZi0wMiZndDsgVG8gaGF2ZSB0aGUgY291bnRlcnMgd29ya2luZywgYXQgbGVhc3Qg b25lIHVuaWNhc3QgY2VsbCBuZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+bXNm LTAyJmd0OyB0byBiZSBtYWludGFpbmVkIGFsbCB0aGUgdGltZSBhbmQgbmV2ZXIgYmUgcmVtb3Zl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yz IOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90 Oztjb2xvcjojMkY1NDk2Ij5Ib3dldmVyLCB0aGlzIGlzIHJlbW92ZWQgaW4gLTAzLiBTbywgSSB0 aGluayBpdCdzIHBvc3NpYmxlIHRoYXQgbXNmLTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJG NTQ5NiI+cmVtb3ZlcyBhbGwgbWFuYWdlZCBjZWxscywgYXMgYSByZXN1bHQgb2YgYWRhcHRhdGlv biB0byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 77yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij50cmFmZmljLiBJcyBpdCBP Sz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yz IOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90 Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij4q IERpcmVjdGlvbiBvZiBtYW5hZ2VkIGNlbGxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5 NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+SXQgbG9va3MgbGlrZSBt YW5hZ2VkIGNlbGxzIGFyZSBvbmx5IGZvciB1cHN0cmVhbSB0cmFmZmljLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1 b3Q7O2NvbG9yOiMyRjU0OTYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYi PkluIHNlY3Rpb24gNC42LCB0aGUgam9pbmluZyBub2RlIGFkZHMgYSBUeCBjZWxsIHRvIHRoZSBw cmVmZXJyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 77yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij5wYXJlbnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pj gq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJG NTQ5NiI+bXNmLTAzJmd0OyBUaGVuIGl0IE1VU1QgaXNzdWUgYSA2UCBBREQgY29tbWFuZCBNVVNU IHRvIHRoYXQgcGFyZW50LCB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+bXNm LTAzJmd0OyB0aGUgZm9sbG93aW5nIGZpZWxkczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1 NDk2Ij5tc2YtMDMmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQ2VsbE9wdGlvbnM6IHNl dCB0byBUWD0xLFJYPTAsU0hBUkVEPTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij5t c2YtMDMmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTnVtQ2VsbHM6IHNldCB0byAxPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTj grfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29s b3I6IzJGNTQ5NiI+SW4gc2VjdGlvbiA1LjEsIHRoZSBub2RlIGFkZHMgYSBUeCBjZWxsIHRvIHRo ZSBwcmVmZXJyZWQgcGFyZW50IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+YWRh cHQgdG8gdGhlIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDj grTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+bXNmLTAzJmd0OyB0aGUgbm9kZSBpc3N1 ZXMgYSA2UCBBREQgY29tbWFuZCB0byBpdHMgcHJlZmVycmVkIHBhcmVudCB0bzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44Kv JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPm1zZi0wMyZndDsgYWRkIG9uZSBtYW5hZ2VkIFR4IGNlbGwg dG8gdGhlIFRTQ0ggc2NoZWR1bGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8 syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+QmVjYXVzZSA2UCB0cmFuc2FjdGlv biBpcyBhbHdheXMgaW5pdGlhdGVkIGZyb20gdGhlIGNoaWxkIHRvIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1 b3Q7O2NvbG9yOiMyRjU0OTYiPnByZWZlcnJlZCBwYXJlbnQsIGFuZCBDZWxsT3B0aW9uIGluIDZQ IEFERCByZXF1ZXN0IGlzIGFsd2F5cyAoPykgVHg9MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMy RjU0OTYiPlJYPTAsIHRoZXJlIGlzIG5vIGRvd25zdHJlYW0gbWFuYWdlZCBjZWxscy4gQXMgYSBy ZXN1bHQsIGRvd25zdHJlYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij5wYWNrZXRz IHN1Y2ggYXMgREFPLUFDSyBoYXZlIHRvIHVzZSBBdXRvRG93bkNlbGwgb3IgdGhlIG1pbmltYWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOC tOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij5jZWxsLiBJIHRoaW5rIHdlIHNob3VsZCBo YXZlIGRvd25zdHJlYW0gY2VsbHMsIHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 77yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OC ryZxdW90Oztjb2xvcjojMkY1NDk2Ij5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29s b3I6IzJGNTQ5NiI+VG9zaGlvIEl0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowbW0gMG1tIDBtbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMG1tIDBtbSAwbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiA2dGlzY2ggJmx0OzZ0aXNjaC1ib3VuY2VzQGlldGYub3JnJmd0Ow0K PGI+T24gQmVoYWxmIE9mIDwvYj5UZW5nZmVpIENoYW5nPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIEFwcmlsIDA5LCAyMDE5IDE6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IDZ0aXNjaEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbNnRpc2NoXSBbQ2FsbCBmb3IgUmV2aWV3XSBkcmFmdC1p ZXRmLTZ0aXNjaC1tc2YtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkEgbmV3IHZlcnNpb24gb2YgJnF1b3Q7ZHJhZnQtaWV0Zi02dGlzY2gtbXNmJnF1b3Q7IGlz IGp1c3QgcHVibGlzaGVkIGF0IGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtaWV0Zi02dGlzY2gtbXNmLTAzLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi02dGlzY2gtbXNmLTAzLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgdmVyc2lvbiBtYWlubHkgcmVzb2x2ZWQg dGhlIGlzc3VlcyBwcmVzZW50ZWQgZHVyaW5nIElFVEYgMTA0IG1lZXRpbmcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkkgd291bGQgbGlrZSB0byBtZW50aW9uIG9uZSBvZiB0aGUgbWFpbiBjaGFuZ2Vz IGluIHRoaXMgdmVyc2lvbiBpcyB3ZSByZW1vdmVkIHRoZSBmcmFtZSBwZW5kaW5nIGJpdCBmZWF0 dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SXQn cyBmb3IgdHdvIHJlYXNvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPi0gaXQgd2lsbCBpbmZsdWVuY2UgdGhlICZxdW90O2FkYXB0IHRvIHRyYWZmaWMm cXVvdDsgc3RyYXRlZ3kgb2YgTVNGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPi0gdGhlICZxdW90O2FkYXB0IHRvIHRyYWZmaWMmcXVvdDsgc3RyYXRlZ3kgaGFzIHRo ZSBhYmlsaXR5IHRvIGhhbmRsZSBidXJzdCB0cmFmZmljIGJ5IHVzaW5nIGEgc21hbGxlciBNQVhf TlVNQ0VMTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Tm93IHdlIGFyZSBjYWxsaW5nIGZvciByZXZpZXdzIG9uIHRoZSBuZXcgdmVyc2lv biBvZiBNU0YhJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFueSBjb21tZW50cyBhbmQgZmVl ZGJhY2sgYXJlIGFwcHJlY2lhdGVkITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGVuZ2ZlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDojRkRGREZEIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoYW5n IFRlbmdmZWksPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRkRGREZEIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+UG9zdGRvY3RvcmFsIFJlc2VhcmNoIEVuZ2luZWVy PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LA0KIElucmlhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_OSAPR01MB3713ACD140322CF8D83F1582E5230OSAPR01MB3713jpnp_-- From nobody Mon Apr 22 20:34:54 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E255120155 for <6tisch@ietfa.amsl.com>; Mon, 22 Apr 2019 20:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plK-l6Xh2yvb for <6tisch@ietfa.amsl.com>; Mon, 22 Apr 2019 20:34:49 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 D9652120136 for <6tisch@ietf.org>; Mon, 22 Apr 2019 20:34:48 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id l23so1522820lja.3 for <6tisch@ietf.org>; Mon, 22 Apr 2019 20:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B9t/TntHXrok6yrPRVhii5XjbSFYiVd/uEhD+Gy8i18=; b=MRWJt5Xjn9cJtjtZMJWscplW2Y43rTJO5qYKMo+NIMLnsFlAuZvsquEV/Ee+0kNa6e pX3qwUnbjoRMlE+n6iClPZbuVjvYTH9n35/0ZMdGSWqhYCPsGMVZVAi063/34/2Otuou +WNbY7SMhbdhAmew4Ocm4XfJWpJMqNTaLY3b0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B9t/TntHXrok6yrPRVhii5XjbSFYiVd/uEhD+Gy8i18=; b=d8q+DglCZX9TDfCsC2i+cyLFzAR53MYLynZRB/ztT98SR0su4+EtU3D9RhK7MElYLG EQM7IHV53oXUYaNs6OWRYGIZoHTok4ymNrWhLmnPdqe7MEngF+n+I/8IbiyPPILrv7+Y f4IGn0wvemInzuQ1jI93BGew/6byAdl0U2g0NUbZBAVxCP6DY8qd+GNAYEClEkRQLFyA M13jAMbuIdokYYQ+viAn2KOdykyfMrL1dUM1RsnvV18oXyj1IkEA8/N5wZckdRznMfAo sZ7uP4l5hvjlM4RmzavtQjBU2NzihVjS6JjnRuFhDpAmz+lkKs+4fzSkoF+C8c7RGCXF RRmQ== X-Gm-Message-State: APjAAAW0pFgiMurW56iwueTNGZvu9QRJsopH6RfA1wLyXYvDnIk5aqa3 mbGnEfXD1hL7plstjWpmim7NlnJ9cELJyJmN+jh4yQ== X-Google-Smtp-Source: APXvYqzXLOh+kUb8ikMRVAz6sBYIwbLMpVSqWTR+25EOrxH/Js3bvxIq1g51jTs5PYbwKMGjWY4WToXy3nTKQtCl2I4= X-Received: by 2002:a2e:a301:: with SMTP id l1mr13159803lje.61.1555990486797; Mon, 22 Apr 2019 20:34:46 -0700 (PDT) MIME-Version: 1.0 References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> In-Reply-To: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> From: Xavi Vilajosana Guillen Date: Mon, 22 Apr 2019 17:34:35 +0200 Message-ID: To: Yasuyuki Tanaka Cc: tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="0000000000003d71eb05872a4437" Archived-At: Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 03:34:53 -0000 --0000000000003d71eb05872a4437 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yatch, thanks for your observation. I think that the behaviour is correct as described in the text. When node B power cycles loses the last seen seqNum. Its stored value is then 0 and hence when it receives the request responds with the error and with the stored last seen seqnum (0). does it make sense? regards Xavi Missatge de Yasuyuki Tanaka del dia dv., 19 d=E2=80=99abr. 2019 a les 18:05: > Hi, > > I came across a question in RFC8480 (6P), which looks like an error to > me... Can anybody help? This is about the SeqNum field of the 6P header. > > Section 3.2.2 defines SeqNum like this: > > [https://tools.ietf.org/html/rfc8480#section-3.2.2] > > SeqNum: The sequence number associated with the 6P Transaction. > > Used to match the 6P Request, 6P Response, and 6P Confirmation > > of the same 6P Transaction. > > So, basically, a response and a confirmation have the same SeqNum > value as the corresponding request. This is very normal. > > However, Section 3.4.6.2 says, if a node detect schedule inconsistency > with a received request, the node does a different thing. A response > in this case has a different SeqNum value from the corresponding > request. This is strange... > > [https://tools.ietf.org/html/rfc8480#section-3.4.6.2] > > If the inconsistency is detected during a 6P Transaction (Figure 31), > > the node that has detected it MUST send back a 6P Response or 6P > > Confirmation with an error code of RC_ERR_SEQNUM. In this 6P > > Response or 6P Confirmation, the SeqNum field MUST be set to the > > value of the sender of the message (0 in the example in Figure 31). > > In Figure 31, Node A receives 6P Response (SeqNum=3D0, RC_ERR_SEQNUM) in > the last part of the message sequence. But, according to the > definition by Section 3.2.2, Node A doesn't consider the response to > be part of the transaction initiated by 6P Request (SeqNum=3D88), > > [https://tools.ietf.org/html/rfc8480#section-3.4.6.2] > > +----------+ +----------+ > > | Node A | | Node B | > > +----+-----+ +-----+----+ > > SeqNum=3D87 | | SeqNum=3D87 > > | | > > | 6P Request (SeqNum=3D87) | > > |-------------------------------------->| > > | L2 ACK | > > |<- - - - - - - - - - - - - - - - - - - | > > | | > > | 6P Response (SeqNum=3D87) | > > |<--------------------------------------| > > | L2 ACK | > > | - - - - - - - - - - - - - - - - - - ->| > > | =3D=3D=3D=3D power= -cycle > > | | > > SeqNum=3D88 | | SeqNum=3D0 > > | | > > | 6P Request (SeqNum=3D88) | > > |-------------------------------------->| Inconsistency > > | L2 ACK | detected > > |<- - - - - - - - - - - - - - - - - - - | > > | | > > | 6P Response (SeqNum=3D0, RC_ERR_SEQNUM) | > > |<--------------------------------------| > > | L2 ACK | > > | - - - - - - - - - - - - - - - - - - ->| > > > > Figure 31: Example of Inconsistency Because Node B Resets > > (Detected by Node B) > > If this is an error, I'm going to file an errata entry. Otherwise, I'd > like to know why Node B in Figure 31 MUST set 0 to SeqNum for the 6P > Response having RC_ERR_SEQNUM. Node A becomes aware of schedule > inconsistency anyway, seeing RC_ERR_SEQNUM in the response. > > By the way, the 5th paragraph in Section 3.4.6 supports Section > 3.2.2. The response in an example of the paragraph has the same SeqNum > value as the response, which is 0. This is the same case as explained > with Figure 32. > > [https://tools.ietf.org/html/rfc8480#section-3.4.6] > > When node B receives a 6P Request from node A with SeqNum equal to 0, > > it checks the stored SeqNum for A. If A is a new neighbor, the > > stored SeqNum in B will be 0. The transaction can continue. If the > > stored SeqNum for A in B is different than 0, a potential > > inconsistency is detected. In this case, B MUST return RC_ERR_SEQNUM > > with SeqNum=3D0. The SF of node A MAY decide what to do next, as > > described in Section 3.4.6.2. > > Or, am I just confused...? > > Best, > Yatch > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --0000000000003d71eb05872a4437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yatch,

thanks for your observation. = I think that the behaviour is correct as described in the text. When node B= power cycles loses the last seen seqNum. Its stored value is then 0 and he= nce when it receives the request responds with the error and with the store= d last seen seqnum (0).=C2=A0

does it make sense?<= /div>
regards
Xavi=C2=A0

Missatge de Yasuyuki Tanaka <= ;yasuyuki.tanaka@inria.fr&g= t; del dia dv., 19 d=E2=80=99abr. 2019 a les 18:05:
Hi,

I came across a question in RFC8480 (6P), which looks like an error to
me... Can anybody help? This is about the SeqNum field of the 6P header.
Section 3.2.2 defines SeqNum like this:

[https://tools.ietf.org/html/rfc8480#section-3.2.2<= /a>]
>=C2=A0 =C2=A0SeqNum:=C2=A0 The sequence number associated with the 6P T= ransaction.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Used to match the 6P Request, 6P Resp= onse, and 6P Confirmation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the same 6P Transaction.

So, basically, a response and a confirmation have the same SeqNum
value as the corresponding request. This is very normal.

However, Section 3.4.6.2 says, if a node detect schedule inconsistency
with a received request, the node does a different thing. A response
in this case has a different SeqNum value from the corresponding
request. This is strange...

[
https://tools.ietf.org/html/rfc8480#section-3.4.= 6.2]
>=C2=A0 =C2=A0If the inconsistency is detected during a 6P Transaction (= Figure 31),
>=C2=A0 =C2=A0the node that has detected it MUST send back a 6P Response= or 6P
>=C2=A0 =C2=A0Confirmation with an error code of RC_ERR_SEQNUM.=C2=A0 In= this 6P
>=C2=A0 =C2=A0Response or 6P Confirmation, the SeqNum field MUST be set = to the
>=C2=A0 =C2=A0value of the sender of the message (0 in the example in Fi= gure 31).

In Figure 31, Node A receives 6P Response (SeqNum=3D0, RC_ERR_SEQNUM) in the last part of the message sequence. But, according to the
definition by Section 3.2.2, Node A doesn't consider the response to be part of the transaction initiated by 6P Request (SeqNum=3D88),

[https://tools.ietf.org/html/rfc8480#section-3.4.= 6.2]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----------+=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+----------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 Node A=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 Node B=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----+-----+=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+-----+----+
>=C2=A0 =C2=A0 =C2=A0 SeqNum=3D87 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SeqNum=3D87
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6P Request=C2= =A0 (SeqNum=3D87)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |--------------= ------------------------>|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 L2 ACK |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<- - - - - = - - - - - - - - - - - - - - |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6P Response= =C2=A0 (SeqNum=3D87)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<----------= ----------------------------|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | L2 ACK=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | - - - - - - -= - - - - - - - - - - - ->|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D power-cycle
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 SeqNum=3D88 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SeqNum=3D0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6P Request (S= eqNum=3D88)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |--------------= ------------------------>| Inconsistency
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 L2 ACK | detected
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<- - - - - = - - - - - - - - - - - - - - |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6P Response (= SeqNum=3D0, RC_ERR_SEQNUM) |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<----------= ----------------------------|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | L2 ACK=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | - - - - - - -= - - - - - - - - - - - ->|
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 31: Example of Inconsistency B= ecause Node B Resets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(Detected by Node B)

If this is an error, I'm going to file an errata entry. Otherwise, I= 9;d
like to know why Node B in Figure 31 MUST set 0 to SeqNum for the 6P
Response having RC_ERR_SEQNUM. Node A becomes aware of schedule
inconsistency anyway, seeing RC_ERR_SEQNUM in the response.

By the way, the 5th paragraph in Section 3.4.6 supports Section
3.2.2. The response in an example of the paragraph has the same SeqNum
value as the response, which is 0. This is the same case as explained
with Figure 32.

[https://tools.ietf.org/html/rfc8480#section-3.4.6<= /a>]
>=C2=A0 =C2=A0When node B receives a 6P Request from node A with SeqNum = equal to 0,
>=C2=A0 =C2=A0it checks the stored SeqNum for A.=C2=A0 If A is a new nei= ghbor, the
>=C2=A0 =C2=A0stored SeqNum in B will be 0.=C2=A0 The transaction can co= ntinue.=C2=A0 If the
>=C2=A0 =C2=A0stored SeqNum for A in B is different than 0, a potential<= br> >=C2=A0 =C2=A0inconsistency is detected.=C2=A0 In this case, B MUST retu= rn RC_ERR_SEQNUM
>=C2=A0 =C2=A0with SeqNum=3D0.=C2=A0 The SF of node A MAY decide what to= do next, as
>=C2=A0 =C2=A0described in Section 3.4.6.2.

Or, am I just confused...?

Best,
Yatch

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch


--
Parc Mediterrani de la Tecnologia= =C2=A0
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Ba= rcelona). Catalonia. Spain
Dr. Xavier Vilajosana
Wireless Networks Lab
I= nternet Interdisciplinary Institute (IN3)
Professor

(+34) 646 633= 681
xvilajosana@uoc.edu
http://xvilajosana.org
http://wine.rdi.uoc.edu
3D"Universitat=C2=A0=C2=A0
=C2=AD
<= /div>
--0000000000003d71eb05872a4437-- From nobody Tue Apr 23 01:49:55 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB01200FA for <6tisch@ietfa.amsl.com>; Tue, 23 Apr 2019 01:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kid1L7uI560S for <6tisch@ietfa.amsl.com>; Tue, 23 Apr 2019 01:49:50 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 EF9C61200A2 for <6tisch@ietf.org>; Tue, 23 Apr 2019 01:49:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,385,1549926000"; d="scan'208";a="379775875" Received: from wifi-pro-82-172.paris.inria.fr (HELO [128.93.82.172]) ([128.93.82.172]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 Apr 2019 10:49:48 +0200 Cc: yasuyuki.tanaka@inria.fr, tisch <6tisch@ietf.org> To: Xavi Vilajosana Guillen References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> From: Yasuyuki Tanaka Message-ID: Date: Tue, 23 Apr 2019 10:49:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 08:49:53 -0000 Hi Xavi, Thank you for your reply. On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote: > When node B power cycles loses the last seen seqNum. Its stored value is then 0 and hence when it receives the request responds with the error and with the stored last seen seqnum (0). > > does it make sense? I don't think so... Why doesn't Node B just use SeqNum received from Node A for its response? Node A in Figure 31 would drop the response with SeqNum=0 at 6P layer because it is not considered as part of the transaction started by the request with SeqNum=88. Again, the definition of SeqNum is: > SeqNum: The sequence number associated with the 6P Transaction. > Used to match the 6P Request, 6P Response, and 6P Confirmation > of the same 6P Transaction. Best, Yatch From nobody Tue Apr 23 06:32:10 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D707E12016D for <6tisch@ietfa.amsl.com>; Tue, 23 Apr 2019 06:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inY5yjRdh6OH for <6tisch@ietfa.amsl.com>; Tue, 23 Apr 2019 06:32:05 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 99B2C120437 for <6tisch@ietf.org>; Tue, 23 Apr 2019 06:32:05 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id c207so7499107pfc.7 for <6tisch@ietf.org>; Tue, 23 Apr 2019 06:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KjqLTWFMzW2ZO0qjKFkPUzf3kCTgOMM32dhQo9Vi0SY=; b=vSVURbwX44wq8cPzrRm99lUM7haiRghsQDAUaoeAG2xmjDtqrnl3Oxkgl7NvFivlWX YaES4f1i8ucHOJf1tGuKURcOWWPSA7/jWX/37UGlORTKHyswmBavXFujsAWS7FKfZt1j a7tlBkWQUGK+Bczb4mWI+l6gL3lSS6ENqYa2VoMw7ylYSnlQD/Paylw2jFtKkY6QlEac MaqtZJhyZXwKJOcuLXLtiD9B3QhwOfMpjQYqOgqBLdgF2ufv+0qYKM7aoYTgPM5FogUb 2X2xAtKQrgLDqGSys1B4hLSJzPrZ3Rv0lzfp4e0QjeDoIaJrYhZhksF5XPLMH1j9uazo gt1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KjqLTWFMzW2ZO0qjKFkPUzf3kCTgOMM32dhQo9Vi0SY=; b=nkKN3tqIxwy27+JOR/VLxcgthBpnt0a8B+f9aPXAyQbFuW1LVlEALAPHlDuXXBvIH3 t11FfWV4xhjTkSWc+EMwkK5xaI0ICkY4/pFDs4n8lBiQ4VX1va1NColzrfVsm9zJYLT9 JSgvuxSTn5ZsCxIvpTZfACQtYyukdanbWyQ6I2rAz+nVr11DZDOevkOcayDwXy3goGug JpRDxZM0m4nHK7eWoKOyVroVloPvAxPGfwlxzLxpn0xEVJC1U9YfV2tYkjoG8A9w088d 5gM2DBxZyo7qWWqLWu7YGMPOKIJtov+2H8TTNf8GSQ+WKYwQtoZFSGYoWeMiHMAYiu4j NMJg== X-Gm-Message-State: APjAAAUGCQ5L3qFivXGidfm1QB/hXFNZNpxQhOAINAuMk4JsXXzBxP0C oRJ+wU5kXNnSMbJGvhCTjWVLbnCqGx3xgaOH5+g= X-Google-Smtp-Source: APXvYqyCc2uCwUzzR6NZACrLI3f/1b70/rLXHXj7Y9s0c77cYQ5iKjtIDsL6CYlstThyX4KNC6QKDahl0svs6uE9M1Y= X-Received: by 2002:a63:2b03:: with SMTP id r3mr24159862pgr.105.1556026324840; Tue, 23 Apr 2019 06:32:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Tue, 23 Apr 2019 15:31:52 +0200 Message-ID: To: toshio9.ito@toshiba.co.jp Cc: 6tisch@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a763f0587329c94" Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 13:32:09 -0000 --0000000000005a763f0587329c94 Content-Type: text/plain; charset="UTF-8" Hi Toshio, Thanks for review the draft! For your comments: *Minimum number of managed cells * TC: Yes, it's better to have at least one Tx Managed Cell to parent, maybe one Rx Managed Cell as well for downstream, for your second point. *Direction of managed cells* TC: yes, the support on Tx and Rx managed cell are not clear in 03. We will rephrase the section. TC: One problem discovered by now is that the adaption to traffic only works on Tx cell actually. TC: For Rx managed cell, if the node didn't receive a packet at Rx cell, it doesn't know where there is no packet incoming or the packet is failed because of interference/collision. TC: One solution for that is, we will only support Tx managed cell but the initiator of 6P could be parent and the request is sent to one of its children. Tengfei On Tue, Apr 23, 2019 at 2:51 AM wrote: > Hi Tengfei, > > > > Thanks for the work. The draft looks promising. > > > > I have two comments on the managed cells. > > > > > > * Minimum number of managed cells > > > > Sec. 5.1: Revision -02 had the following sentence. > > > > msf-02> To have the counters working, at least one unicast cell need > > msf-02> to be maintained all the time and never be removed. > > > > However, this is removed in -03. So, I think it's possible that msf-03 > > removes all managed cells, as a result of adaptation to the > > traffic. Is it OK? > > > > > > * Direction of managed cells > > > > It looks like managed cells are only for upstream traffic. > > > > In section 4.6, the joining node adds a Tx cell to the preferred > > parent. > > > > msf-03> Then it MUST issue a 6P ADD command MUST to that parent, with > > msf-03> the following fields: > > msf-03> o CellOptions: set to TX=1,RX=0,SHARED=0 > > msf-03> o NumCells: set to 1 > > > > In section 5.1, the node adds a Tx cell to the preferred parent to > > adapt to the traffic. > > > > msf-03> the node issues a 6P ADD command to its preferred parent to > > msf-03> add one managed Tx cell to the TSCH schedule. > > > > Because 6P transaction is always initiated from the child to the > > preferred parent, and CellOption in 6P ADD request is always (?) Tx=1 > > RX=0, there is no downstream managed cells. As a result, downstream > > packets such as DAO-ACK have to use AutoDownCell or the minimal > > cell. I think we should have downstream cells, too. > > > > > > Best regards, > > Toshio Ito > > > > *From:* 6tisch <6tisch-bounces@ietf.org> *On Behalf Of *Tengfei Chang > *Sent:* Tuesday, April 09, 2019 1:06 PM > *To:* 6tisch@ietf.org > *Subject:* [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 > > > > Dear all, > > > > A new version of "draft-ietf-6tisch-msf" is just published at here: > https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt > > > > This version mainly resolved the issues presented during IETF 104 meeting. > > I would like to mention one of the main changes in this version is we > removed the frame pending bit feature. > > > > It's for two reasons: > > - it will influence the "adapt to traffic" strategy of MSF. > > - the "adapt to traffic" strategy has the ability to handle burst traffic > by using a smaller MAX_NUMCELLS > > > > Now we are calling for reviews on the new version of MSF! > > Any comments and feedback are appreciated! > > > > Tengfei > > > > > > > > -- > > Chang Tengfei, > > Postdoctoral Research Engineer, Inria > -- Chang Tengfei, Postdoctoral Research Engineer, Inria --0000000000005a763f0587329c94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Toshio,

Thanks for review the draft!=

For your comments:
Minimum number of mana= ged cells =C2=A0

TC: Yes, it's better to have at= least one Tx Managed Cell to parent, maybe one Rx Managed Cell as well for= downstream, for your second point.

Direction of mana= ged cells

TC: yes, the support on= Tx and Rx managed cell are not clear in 03. We will rephrase the section.<= /div>

TC: One problem discovered by now is that the adap= tion to traffic only works on Tx cell actually.=C2=A0
TC: For Rx = managed cell, if the node didn't receive a packet at Rx cell, it doesn&= #39;t know where there is no packet incoming or the packet is failed becaus= e of interference/collision.

TC: One solution for = that is, we will only support Tx managed cell but the initiator of 6P=C2=A0= could be parent and the request is sent to one of its children.
=
Tengfei



On Tue, Apr 23, 2= 019 at 2:51 AM <toshio9.ito= @toshiba.co.jp> wrote:

Hi Tengfei,

=C2=A0

Thanks for the work. The draft looks promising.

=C2=A0

I have two comments on the managed cells.

=C2=A0

=C2=A0

* Minimum number of managed cells

=C2=A0

Sec. 5.1: Revision -02 had the following sentence.

=C2=A0

msf-02> To have the counters working, at least one unicast cell= need

msf-02> to be maintained all the time and never be removed.<= /u>

=C2=A0

However, this is removed in -03. So, I think it's possible tha= t msf-03

removes all managed cells, as a result of adaptation to the=

traffic. Is it OK?

=C2=A0

=C2=A0

* Direction of managed cells

=C2=A0

It looks like managed cells are only for upstream traffic.<= u>

=C2=A0

In section 4.6, the joining node adds a Tx cell to the preferred

parent.

=C2=A0

msf-03> Then it MUST issue a 6P ADD command MUST to that parent= , with

msf-03> the following fields:

msf-03>=C2=A0=C2=A0=C2=A0 o=C2=A0 CellOptions: set to TX=3D1,RX= =3D0,SHARED=3D0

msf-03>=C2=A0=C2=A0=C2=A0 o=C2=A0 NumCells: set to 1<= /u>

=C2=A0

In section 5.1, the node adds a Tx cell to the preferred parent to=

adapt to the traffic.

=C2=A0

msf-03> the node issues a 6P ADD command to its preferred paren= t to

msf-03> add one managed Tx cell to the TSCH schedule.=

=C2=A0

Because 6P transaction is always initiated from the child to the

preferred parent, and CellOption in 6P ADD request is always (?) T= x=3D1

RX=3D0, there is no downstream managed cells. As a result, downstr= eam

packets such as DAO-ACK have to use AutoDownCell or the minimal=

cell. I think we should have downstream cells, too.<= /span>

=C2=A0

=C2=A0

Best regards,

Toshio Ito

=C2=A0

From: 6tisch <6tisch-bounces@ietf.org> On Behalf Of Tengfei Chang
Sent: Tuesday, April 09, 2019 1:06 PM
To: 6tisch@ietf= .org
Subject: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03<= u>

=C2=A0

Dear all,<= /p>

=C2=A0

A new version of "draft-ie= tf-6tisch-msf" is just published at here:=C2=A0https://www.iet= f.org/id/draft-ietf-6tisch-msf-03.txt

=C2=A0

This version mainly resolved th= e issues presented during IETF 104 meeting.

I would like to mention one of = the main changes in this version is we removed the frame pending bit featur= e.

=C2=A0

It's for two reasons:

- it will= influence the "adapt to traffic" strategy of MSF.<= /span>

- the &qu= ot;adapt to traffic" strategy has the ability to handle burst traffic = by using a smaller MAX_NUMCELLS

=C2=A0

Now we are calling for reviews = on the new version of MSF!=C2=A0

Any comments and feedback are a= ppreciated!

=C2=A0

Tengfei

=C2=A0

=C2=A0

=C2=A0

--

Chang Tengfei,

Postdoctoral Research Engineer, Inria



--
Chang Tengfei,
<= span style=3D"font-size:12.8px">
Postdoctoral Research Enginee= r, Inria
--0000000000005a763f0587329c94-- From nobody Wed Apr 24 02:12:46 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B225112023F for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 02:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez1ltDuEic_s for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 02:12:41 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 C3DB7120150 for <6tisch@ietf.org>; Wed, 24 Apr 2019 02:12:40 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id t4so16151847ljc.2 for <6tisch@ietf.org>; Wed, 24 Apr 2019 02:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=phy4bhmxsIF6/0e6Y8zkqbGgtBuzXqlygEYGMmOuZxA=; b=b0+ZS0fYshrd/LJLiRq7uHy/24VBVbs2P4Fc/wYhEy9Tu1BGkiTMmz9T+BnMMQufTC FzffzegORNFPUhCjtUh5klrDPUJmn8tpIAowwgwLjjqQEjRPGNsweLvhvP1SnEazlMdx aSBitxGiTjy0GIQJmWbKG60Qou+JmrpjVX8Jo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=phy4bhmxsIF6/0e6Y8zkqbGgtBuzXqlygEYGMmOuZxA=; b=bSiLsVauey9xa1eP/X4iFq0rO5bZxn/8+G2j7L59/ZQhMoajE2GeRsMiQwefjiqFFr YvNzny5VATtHSwCLWIv+jeiYTGwaqkSndVcesSE/5OkYwi1KRqFklKhEgfVsre7OfFPv C12cHh+WZ6gbpQGJvGkYbMy8oFFHRhsuXV3TZsfsNFAmIRq49uJPflsc5Q57gplcUlIz QOVo4QMNooioBt4nOm/yF0Bhc4J8S8+Wcs7PEaRYjvp/lIBY4mKbFaQpa9/BgyALE/lB xNNDxDCB9lqC3ZwLn1EmVrRpXMV5kBSHJ9TkIi5P9WiK8xhs0RjwvKoiQitEJiaxgl6e MvsA== X-Gm-Message-State: APjAAAUEA+NuGh6OqpYk3UbGoWr1jWsP/ksrMg4hyWAO+dtBntTBdyy4 jhophiUET2LQ1cjfGBBLjleq/FeYR/AF50MvuNXDpg== X-Google-Smtp-Source: APXvYqwa8FNTdWglkGop1+T/N67S7xvzCYIDezmHAO+T6rKwhTx17jwfPlEQx5lVfdU5y8iEYPOQtV+9i5Wod86jtic= X-Received: by 2002:a2e:8693:: with SMTP id l19mr16305747lji.47.1556097158443; Wed, 24 Apr 2019 02:12:38 -0700 (PDT) MIME-Version: 1.0 References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> In-Reply-To: From: Xavi Vilajosana Guillen Date: Wed, 24 Apr 2019 11:12:24 +0200 Message-ID: To: Yasuyuki Tanaka Cc: tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="0000000000005d86f40587431a3b" Archived-At: Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 09:12:45 -0000 --0000000000005d86f40587431a3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yatch, thanks for your response. see inline my comments. Missatge de Yasuyuki Tanaka del dia dt., 23 d=E2=80=99abr. 2019 a les 10:49: > Hi Xavi, > > Thank you for your reply. > > On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote: > > When node B power cycles loses the last seen seqNum. Its stored value i= s > then 0 and hence when it receives the request responds with the error and > with the stored last seen seqnum (0). > > > > does it make sense? > > I don't think so... Why doesn't Node B just use SeqNum received from Node > A for its response? > > Node A in Figure 31 would drop the response with SeqNum=3D0 at 6P layer > because it is not considered as part of the transaction started by the > request with SeqNum=3D88. > well SeqNum=3D0 is only possible after a reset or when the node boots. SeqN= um will always be different than 0 except for that occasions. So 6P can be aware situation happening in the middle of a transaction. We took that decision as we consider that Node B may have completely lost the state, which is critical. Probably the option you mention would have been also possible but we took that direction. What is the issue you see with this? > Again, the definition of SeqNum is: > > > SeqNum: The sequence number associated with the 6P Transaction. > > Used to match the 6P Request, 6P Response, and 6P Confirmation > > of the same 6P Transaction. > > Best, > Yatch > regards X --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --0000000000005d86f40587431a3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yatch,

thanks for y= our response. see inline my comments.

Missatge de Yasuyuki Tanaka <= yasuyuki.tanaka@inria.fr>= ; del dia dt., 23 d=E2=80=99abr. 2019 a les 10:49:
Hi Xavi,

Thank you for your reply.

On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:
> When node B power cycles loses the last seen seqNum. Its stored value = is then 0 and hence when it receives the request responds with the error an= d with the stored last seen seqnum (0).
>
> does it make sense?

I don't think so... Why doesn't Node B just use SeqNum received fro= m Node A for its response?

Node A in Figure 31 would drop the response with SeqNum=3D0 at 6P layer bec= ause it is not considered as part of the transaction started by the request= with SeqNum=3D88.

well SeqNum=3D0 is o= nly possible after a reset or when the node boots. SeqNum will always be di= fferent than 0 except for that occasions. So 6P can be aware situation happ= ening in the middle of a transaction.=C2=A0

We too= k that decision as we consider that Node B may have completely lost the sta= te, which is critical. Probably the option you mention would have been also= possible but we took that direction.=C2=A0

What i= s the issue you see with this?



Again, the definition of SeqNum is:

>=C2=A0 =C2=A0 SeqNum:=C2=A0 The sequence number associated with the 6P = Transaction.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Used to match the 6P Request, 6P Res= ponse, and 6P Confirmation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the same 6P Transaction.=C2=A0
Best,
Yatch

regards
X

<= /div>--
3D"Universitat=C2=A0=C2=A0
=C2=AD=
--0000000000005d86f40587431a3b-- From nobody Wed Apr 24 03:24:33 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00A7120227 for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 03:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa1dX0DkV4O8 for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 03:24:29 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 F00D7120223 for <6tisch@ietf.org>; Wed, 24 Apr 2019 03:24:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,389,1549926000"; d="scan'208";a="303823668" Received: from wifi-pro-82-156.paris.inria.fr ([128.93.82.156]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2019 12:24:27 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Yasuyuki Tanaka In-Reply-To: Date: Wed, 24 Apr 2019 12:24:26 +0200 Cc: Yasuyuki Tanaka , 6tisch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <817EBD8A-34E4-41D0-8127-939E61BC0732@inria.fr> References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> To: Xavi Vilajosana Guillen X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 10:24:32 -0000 Hi Xavi, > What is the issue you see with this? At least, there is an inconsistency in RFC8480. Here is another example: https://tools.ietf.org/html/rfc8480#section-3.2.2 rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a = given rfc8480> transaction MUST share the same Version, SFID, and SeqNum = values. Such an inconsistency could bring confusion and/or an interoperability = issue. According to you, a response having SeqNum=3D0 AND RC_ERR_SEQNUM has a = special meaning which is "I've lost all the states completely (due to = power-cycle)", although this is another case we will receive such a response as shown = in Figure 32... Honestly, I'm not sure how valuable it is to know the peer = has performed power-cycle, by the way. So, if setting 0 to SeqNum of a response is a right thing, I would add = some text to the SeqNum definition in Section 3.2.2, to tell there is an = exception.=20 Best, Yatch= From nobody Wed Apr 24 03:48:17 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1D120324 for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 03:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqs6dEZO2-je for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 03:48:12 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 5896E120328 for <6tisch@ietf.org>; Wed, 24 Apr 2019 03:48:12 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id e5so15670383otk.12 for <6tisch@ietf.org>; Wed, 24 Apr 2019 03:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BA+iOMPHIeoQ5hG2Lor9JQlL56q2i/LFWTNG9eJWeb0=; b=rqKX/CTaIWUxPKmkpXoGWJQIU3iWdnKnhexKrwyfDFMmYjq/oetwoglU9voX9TTLk5 oEMWgZdDXVKkH4BlYY5fO3tkOCM45oGGVAsqOkIxf9jKQFZR9Cwv8CRIhAqU5ds7pO4q 4SZU12P9u95v2Vi9EmTC5GIA17zvQAhIYIWbqGV/hiz+N39u6bzemgfEMds39wyfYXX0 OcEeoCM/JKcX3rtA44moe4zTa8yPqU0KwIUAsED0ACPFEZd+9CO2N0+cbisZQ88lhLXu d8BBWfviS6ERkBEOZJ2hSUqNon3tf95jFLC/QHTvEy8szujmi7V56suAREietrD/1Lpp Lwzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BA+iOMPHIeoQ5hG2Lor9JQlL56q2i/LFWTNG9eJWeb0=; b=i+Oa1w/jKWZ22V249yPRBFOjTH/F6DjjcGtdHwghipranIwhsBkbE0MQROJaUayP47 FiXju3nUFV4AmuQhc8lNx3nY/xGOKmujZ+9hHPvxkQ/LZ+qALc9A5k+KaK/VniGi7L6m lOonUhINNRP2kBRP6c37IZXcriT4Hznnlb7CRVpeNNZ5sBmKDDaXzSqJG4rJ5ZwT1rlW bvuZYcBjzfBzu1YksJGEqj4tM2Z5XR7TAo2Fw0s4lAFKUSxi4R1Ms8lBFa8ON0frHMof q+nV+VUbrjlTgE8NsaBnpm95XjcVPCjMlONpRG/eQ6hXjMM2LgwnTavzivOA4Q2rXmH2 hl+A== X-Gm-Message-State: APjAAAW3VYY0SDFxKY7zN8O5giUu2nvAi9dZOagr2Zndv40ZXMfh9hIP WN5MTVtjNP0jZ8AIndv1c1GDwnt1SdRRYRmkDwKKEw== X-Google-Smtp-Source: APXvYqwzaUZNvu/B/2oGpF0u1cnaZA9wQH+XBgPX64aSbySENpXRypT3xn/fM/opE/Njot94qfvkmrgBczVgNEFW2Mc= X-Received: by 2002:a05:6830:1145:: with SMTP id x5mr19985724otq.40.1556102891317; Wed, 24 Apr 2019 03:48:11 -0700 (PDT) MIME-Version: 1.0 References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> <817EBD8A-34E4-41D0-8127-939E61BC0732@inria.fr> In-Reply-To: <817EBD8A-34E4-41D0-8127-939E61BC0732@inria.fr> From: "Prof. Diego Dujovne" Date: Wed, 24 Apr 2019 06:47:58 -0400 Message-ID: To: Yasuyuki Tanaka Cc: =?UTF-8?Q?Xavi_Vilajosana_Guill=C3=A9n?= , 6tisch@ietf.org Content-Type: multipart/alternative; boundary="0000000000001241b305874470b5" Archived-At: Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 10:48:16 -0000 --0000000000001241b305874470b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yacht, Let me chime in a little bit. Responses below. Regards, Diego El mi=C3=A9., 24 de abr. de 2019 06:24, Yasuyuki Tanaka escribi=C3=B3: > Hi Xavi, > > > What is the issue you see with this? > > At least, there is an inconsistency in RFC8480. Here is another example: > > https://tools.ietf.org/html/rfc8480#section-3.2.2 > > rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a > given > rfc8480> transaction MUST share the same Version, SFID, and SeqNum > values. > > Such an inconsistency could bring confusion and/or an interoperability > issue. > > According to you, a response having SeqNum=3D0 AND RC_ERR_SEQNUM has a > special > meaning which is "I've lost all the states completely (due to > power-cycle)", > although this is another case we will receive such a response as shown in > Figure 32... Honestly, I'm not sure how valuable it is to know the peer h= as > performed power-cycle, by the way. > As far as I can remember, it is important to know that the peer has forgotten all the states and has lost his schedule, so all the allocated cells with that neighbour are currently not valid anymore and should be wiped from the local schedule. > So, if setting 0 to SeqNum of a response is a right thing, I would add so= me > text to the SeqNum definition in Section 3.2.2, to tell there is an > exception. > > Best, > Yatch > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --0000000000001241b305874470b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yacht,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Let me chime in a little bit. Responses below.
Regards,

=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego


El mi=C3=A9., 24 de abr. de 201= 9 06:24, Yasuyuki Tanaka <ya= suyuki.tanaka@inria.fr> escribi=C3=B3:
Hi Xavi,

> What is the issue you see with this?

At least, there is an inconsistency in RFC8480. Here is another example:
https://tools.ietf.org/html/rfc8480#sect= ion-3.2.2

rfc8480>=C2=A0 =C2=A06P Request, 6P Response, and 6P Confirmation messag= es for a given
rfc8480>=C2=A0 =C2=A0transaction MUST share the same Version, SFID, and = SeqNum values.

Such an inconsistency could bring confusion and/or an interoperability issu= e.

According to you, a response having SeqNum=3D0 AND RC_ERR_SEQNUM has a spec= ial
meaning which is "I've lost all the states completely (due to powe= r-cycle)",
although this is another case we will receive such a response as shown in Figure 32... Honestly, I'm not sure how valuable it is to know the peer= has
performed power-cycle, by the way.

As far as I can remember, it is important= to know that the peer has forgotten all the states and has lost his schedu= le, so all the allocated cells with that neighbour are currently not valid = anymore and should be wiped from the local schedule.


So, if setting 0 to SeqNum of a response is a right thing, I would add some=
text to the SeqNum definition in Section 3.2.2, to tell there is an excepti= on.

Best,
Yatch
_______________________________________________
6tisch mailing list
6ti= sch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch<= /a>
--0000000000001241b305874470b5-- From nobody Wed Apr 24 05:45:17 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF00312009A for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 05:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB_OarqNFDCx for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 05:45:13 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 3661E120086 for <6tisch@ietf.org>; Wed, 24 Apr 2019 05:45:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,389,1549926000"; d="scan'208";a="380011910" Received: from wifi-pro-82-156.paris.inria.fr ([128.93.82.156]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2019 14:45:11 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Yasuyuki Tanaka In-Reply-To: Date: Wed, 24 Apr 2019 14:45:11 +0200 Cc: Yasuyuki Tanaka , 6tisch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4887CFDC-B782-4153-8428-4905DB969F79@inria.fr> References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> <817EBD8A-34E4-41D0-8127-939E61BC0732@inria.fr> To: "Prof. Diego Dujovne" X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 12:45:16 -0000 Thanks, Diego! I think, if SeqNum=3D0 has the special meaning, 6P would need to pass a = received SeqNum to a corresponding SF... But, my understandings is that, SeqNum = is maintained only by 6P and not revealed to SFs... An alternative way to = tell a power-cycle event to the peer would have been defining a separate = return code from RC_ERR_SEQNUM. > On Apr 24, 2019, at 12:47, Prof. Diego Dujovne = wrote: >=20 > As far as I can remember, it is important to know that the peer has = forgotten all the states and has lost his schedule, so all the allocated = cells with that neighbour are currently not valid anymore and should be = wiped from the local schedule. Actually, a node having such a peer should remove outdated cells somehow without having an explicit signaling. This is not a job of 6P, though. The SF should take care of it. A peer may move away from the node without sending a CLEAR request. Even if the peer sends a CLEAR request before moving somewhere, the CLEAR request = may be lost in the air.=20 RPL may do something for this case. If a node has some dedicated TX = cells to its parent, and the parent reboots, RPL on the node could notice there = is something wrong with the parent since measured link quality to the = parent is getting worse. Then, parent switch will be performed. Or, a SF like MSF would try to relocate badly performed cells. Then, it=20= receives RC_ERR_SEQNUM from the parent and take actions to resolve the = schedule inconsistency in the same manner as for other scheduling consistency = cases. The node can see whether the peer loses all the states nor not by having = a following COUNT transaction if the SF really wants to know. If the SF always = issues a CLEAR request to a peer which sent RC_ERR_SEQNUM, the SF doesn't care = about the power-cycle event. Another possibility is that the RELOCATE = transaction ends by 6P Timeout. Again, some actions will be taken by the SF. Best, Yatch= From nobody Wed Apr 24 20:03:21 2019 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0A1202AA for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 20:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vteCJb3mKUkZ for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 20:03:16 -0700 (PDT) Received: from mo-csw.securemx.jp (mo-csw1114.securemx.jp [210.130.202.156]) (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 A409D120120 for <6tisch@ietf.org>; Wed, 24 Apr 2019 20:03:15 -0700 (PDT) Received: by mo-csw.securemx.jp (mx-mo-csw1114) id x3P33Cag016510; Thu, 25 Apr 2019 12:03:12 +0900 X-Iguazu-Qid: 2wHHEpXCl5GVeLrNPt X-Iguazu-QSIG: v=2; s=0; t=1556161391; q=2wHHEpXCl5GVeLrNPt; m=HpAnFrLaWmUwFwct3MMAID/ZTT33D+tQFDHteds6oDE= Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.securemx.jp (mx-mr1110) id x3P33Bf2010032; Thu, 25 Apr 2019 12:03:11 +0900 Received: from enc02.toshiba.co.jp ([61.202.160.51]) by imx12.toshiba.co.jp with ESMTP id x3P33AnQ028450; Thu, 25 Apr 2019 12:03:10 +0900 (JST) Received: from hop101.toshiba.co.jp ([133.199.85.107]) by enc02.toshiba.co.jp with ESMTP id x3P339Uv032181; Thu, 25 Apr 2019 12:03:10 +0900 From: To: CC: <6tisch@ietf.org> Thread-Topic: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 Thread-Index: AQHU7om12W7S4Bn/P0yQjcGYDJ8uE6ZI+KIAgADcHACAAmurwA== Date: Thu, 25 Apr 2019 03:03:08 +0000 X-TSB-HOP: ON Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP authentication-results: spf=none (sender IP is ) smtp.mailfrom=toshio9.ito@toshiba.co.jp; x-originating-ip: [103.91.184.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6858b5d9-ee3b-4172-8f77-08d6c92a8b35 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:OSAPR01MB2273; x-ms-traffictypediagnostic: OSAPR01MB2273: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(136003)(396003)(346002)(366004)(189003)(199004)(51914003)(8676002)(14454004)(53546011)(316002)(71200400001)(81166006)(71190400001)(9686003)(6306002)(11346002)(81156014)(53936002)(966005)(66446008)(64756008)(5660300002)(66946007)(8936002)(55016002)(236005)(66556008)(4326008)(6506007)(66476007)(54896002)(74482002)(66066001)(99286004)(102836004)(97736004)(6246003)(73956011)(76116006)(446003)(7696005)(186003)(26005)(476003)(486006)(478600001)(7736002)(74316002)(6436002)(76176011)(33656002)(6916009)(3846002)(6116002)(86362001)(25786009)(256004)(14444005)(46636005)(606006)(52536014)(68736007)(229853002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:OSAPR01MB2273; H:OSAPR01MB3713.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: toshiba.co.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Fv+QmDv1yE1jxLVX2ry6KhngeTQs9o6n/iVN6RhylVficz2cFifI4erZQ/4xb114m8LG8+Q4qzfiW84+vzwIUUt4AQx6OKscwPMR6XdImu9QvG10Gj64Ulvm4b8+h+WvoaUUnj6TsOL9v7ya9ysv9O1bTxNqo10cDgfqi69FACl1EaCTJMpB6te81fC0NdezxIiZJcccIhsA/ffsh9Ng2pJRJIr+RqZmXsuwRmMt5gsZOhljh2ZONQHhf307x/I4OYGtB5hDoPvxIz85onpIa06Fu6VbfJGmW9tZk+rSV7KPCY9UHc1iLk/RxQpwMh1/9fqzifgDyi1eXsUTSuWxF+qUacyAen/LQg3LZKuMQL/TOU8pFYlf/xCSmJYZTOBxYjIhKfAR1WMmi55oDsze9D2VgpqpgwfzvJtuKyYp7X0= Content-Type: multipart/alternative; boundary="_000_OSAPR01MB3713BB5598E03C3D8644687EE53D0OSAPR01MB3713jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6858b5d9-ee3b-4172-8f77-08d6c92a8b35 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 03:03:08.0546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB2273 MSSCP.TransferMailToMossAgent: 103 X-OriginatorOrg: toshiba.co.jp Archived-At: Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 03:03:20 -0000 --_000_OSAPR01MB3713BB5598E03C3D8644687EE53D0OSAPR01MB3713jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBUZW5nZmVpLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBhZGFwdGF0aW9uIHRvIHRyYWZm aWMgZG9lc24ndCB3b3JrIGZvciBSeA0KbWFuYWdlZCBjZWxscy4gU28sIGFzIHlvdSBzdWdnZXN0 ZWQsIHRoZSBwYXJlbnQgbm9kZSBzaG91bGQNCnRyaWdnZXIgNlAgQUREL0RFTEVURS9SRUxPQ0FU RSB0byBvbmUgb2YgaXRzIGNoaWxkcmVuLCBwcm9iYWJseQ0KdXNpbmcgMy1zdGVwIHRyYW5zYWN0 aW9uLiBUaGF0IHdvdWxkIGFmZmVjdCBkZXNjcmlwdGlvbiBvbiB1c2FnZQ0Kb2YgQXV0b1VwQ2Vs bCBhbmQgQXV0b0Rvd25DZWxsLg0KDQoNCkJlc3QgcmVnYXJkcywNClRvc2hpbyBJdG8NCg0KRnJv bTogVGVuZ2ZlaSBDaGFuZyA8dGVuZ2ZlaS5jaGFuZ0BnbWFpbC5jb20+DQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAyMywgMjAxOSAxMDozMiBQTQ0KVG86IGl0byB0b3NoaW8o5LyK6JekIOS/iuWkqyDi l4vvvLLvvKTvvKPilqHvvKPvvK7vvKwpIDx0b3NoaW85Lml0b0B0b3NoaWJhLmNvLmpwPg0KQ2M6 IDZ0aXNjaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFs2dGlzY2hdIFtDYWxsIGZvciBSZXZpZXdd IGRyYWZ0LWlldGYtNnRpc2NoLW1zZi0wMw0KDQpIaSBUb3NoaW8sDQoNClRoYW5rcyBmb3IgcmV2 aWV3IHRoZSBkcmFmdCENCg0KRm9yIHlvdXIgY29tbWVudHM6DQpNaW5pbXVtIG51bWJlciBvZiBt YW5hZ2VkIGNlbGxzDQoNClRDOiBZZXMsIGl0J3MgYmV0dGVyIHRvIGhhdmUgYXQgbGVhc3Qgb25l IFR4IE1hbmFnZWQgQ2VsbCB0byBwYXJlbnQsIG1heWJlIG9uZSBSeCBNYW5hZ2VkIENlbGwgYXMg d2VsbCBmb3IgZG93bnN0cmVhbSwgZm9yIHlvdXIgc2Vjb25kIHBvaW50Lg0KDQpEaXJlY3Rpb24g b2YgbWFuYWdlZCBjZWxscw0KDQpUQzogeWVzLCB0aGUgc3VwcG9ydCBvbiBUeCBhbmQgUnggbWFu YWdlZCBjZWxsIGFyZSBub3QgY2xlYXIgaW4gMDMuIFdlIHdpbGwgcmVwaHJhc2UgdGhlIHNlY3Rp b24uDQoNClRDOiBPbmUgcHJvYmxlbSBkaXNjb3ZlcmVkIGJ5IG5vdyBpcyB0aGF0IHRoZSBhZGFw dGlvbiB0byB0cmFmZmljIG9ubHkgd29ya3Mgb24gVHggY2VsbCBhY3R1YWxseS4NClRDOiBGb3Ig UnggbWFuYWdlZCBjZWxsLCBpZiB0aGUgbm9kZSBkaWRuJ3QgcmVjZWl2ZSBhIHBhY2tldCBhdCBS eCBjZWxsLCBpdCBkb2Vzbid0IGtub3cgd2hlcmUgdGhlcmUgaXMgbm8gcGFja2V0IGluY29taW5n IG9yIHRoZSBwYWNrZXQgaXMgZmFpbGVkIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlL2NvbGxpc2lv bi4NCg0KVEM6IE9uZSBzb2x1dGlvbiBmb3IgdGhhdCBpcywgd2Ugd2lsbCBvbmx5IHN1cHBvcnQg VHggbWFuYWdlZCBjZWxsIGJ1dCB0aGUgaW5pdGlhdG9yIG9mIDZQICBjb3VsZCBiZSBwYXJlbnQg YW5kIHRoZSByZXF1ZXN0IGlzIHNlbnQgdG8gb25lIG9mIGl0cyBjaGlsZHJlbi4NCg0KVGVuZ2Zl aQ0KDQoNCg0KT24gVHVlLCBBcHIgMjMsIDIwMTkgYXQgMjo1MSBBTSA8dG9zaGlvOS5pdG9AdG9z aGliYS5jby5qcDxtYWlsdG86dG9zaGlvOS5pdG9AdG9zaGliYS5jby5qcD4+IHdyb3RlOg0KSGkg VGVuZ2ZlaSwNCg0KVGhhbmtzIGZvciB0aGUgd29yay4gVGhlIGRyYWZ0IGxvb2tzIHByb21pc2lu Zy4NCg0KSSBoYXZlIHR3byBjb21tZW50cyBvbiB0aGUgbWFuYWdlZCBjZWxscy4NCg0KDQoqIE1p bmltdW0gbnVtYmVyIG9mIG1hbmFnZWQgY2VsbHMNCg0KU2VjLiA1LjE6IFJldmlzaW9uIC0wMiBo YWQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZS4NCg0KbXNmLTAyPiBUbyBoYXZlIHRoZSBjb3VudGVy cyB3b3JraW5nLCBhdCBsZWFzdCBvbmUgdW5pY2FzdCBjZWxsIG5lZWQNCm1zZi0wMj4gdG8gYmUg bWFpbnRhaW5lZCBhbGwgdGhlIHRpbWUgYW5kIG5ldmVyIGJlIHJlbW92ZWQuDQoNCkhvd2V2ZXIs IHRoaXMgaXMgcmVtb3ZlZCBpbiAtMDMuIFNvLCBJIHRoaW5rIGl0J3MgcG9zc2libGUgdGhhdCBt c2YtMDMNCnJlbW92ZXMgYWxsIG1hbmFnZWQgY2VsbHMsIGFzIGEgcmVzdWx0IG9mIGFkYXB0YXRp b24gdG8gdGhlDQp0cmFmZmljLiBJcyBpdCBPSz8NCg0KDQoqIERpcmVjdGlvbiBvZiBtYW5hZ2Vk IGNlbGxzDQoNCkl0IGxvb2tzIGxpa2UgbWFuYWdlZCBjZWxscyBhcmUgb25seSBmb3IgdXBzdHJl YW0gdHJhZmZpYy4NCg0KSW4gc2VjdGlvbiA0LjYsIHRoZSBqb2luaW5nIG5vZGUgYWRkcyBhIFR4 IGNlbGwgdG8gdGhlIHByZWZlcnJlZA0KcGFyZW50Lg0KDQptc2YtMDM+IFRoZW4gaXQgTVVTVCBp c3N1ZSBhIDZQIEFERCBjb21tYW5kIE1VU1QgdG8gdGhhdCBwYXJlbnQsIHdpdGgNCm1zZi0wMz4g dGhlIGZvbGxvd2luZyBmaWVsZHM6DQptc2YtMDM+ICAgIG8gIENlbGxPcHRpb25zOiBzZXQgdG8g VFg9MSxSWD0wLFNIQVJFRD0wDQptc2YtMDM+ICAgIG8gIE51bUNlbGxzOiBzZXQgdG8gMQ0KDQpJ biBzZWN0aW9uIDUuMSwgdGhlIG5vZGUgYWRkcyBhIFR4IGNlbGwgdG8gdGhlIHByZWZlcnJlZCBw YXJlbnQgdG8NCmFkYXB0IHRvIHRoZSB0cmFmZmljLg0KDQptc2YtMDM+IHRoZSBub2RlIGlzc3Vl cyBhIDZQIEFERCBjb21tYW5kIHRvIGl0cyBwcmVmZXJyZWQgcGFyZW50IHRvDQptc2YtMDM+IGFk ZCBvbmUgbWFuYWdlZCBUeCBjZWxsIHRvIHRoZSBUU0NIIHNjaGVkdWxlLg0KDQpCZWNhdXNlIDZQ IHRyYW5zYWN0aW9uIGlzIGFsd2F5cyBpbml0aWF0ZWQgZnJvbSB0aGUgY2hpbGQgdG8gdGhlDQpw cmVmZXJyZWQgcGFyZW50LCBhbmQgQ2VsbE9wdGlvbiBpbiA2UCBBREQgcmVxdWVzdCBpcyBhbHdh eXMgKD8pIFR4PTENClJYPTAsIHRoZXJlIGlzIG5vIGRvd25zdHJlYW0gbWFuYWdlZCBjZWxscy4g QXMgYSByZXN1bHQsIGRvd25zdHJlYW0NCnBhY2tldHMgc3VjaCBhcyBEQU8tQUNLIGhhdmUgdG8g dXNlIEF1dG9Eb3duQ2VsbCBvciB0aGUgbWluaW1hbA0KY2VsbC4gSSB0aGluayB3ZSBzaG91bGQg aGF2ZSBkb3duc3RyZWFtIGNlbGxzLCB0b28uDQoNCg0KQmVzdCByZWdhcmRzLA0KVG9zaGlvIEl0 bw0KDQpGcm9tOiA2dGlzY2ggPDZ0aXNjaC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzo2dGlzY2gt Ym91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBUZW5nZmVpIENoYW5nDQpTZW50OiBUdWVz ZGF5LCBBcHJpbCAwOSwgMjAxOSAxOjA2IFBNDQpUbzogNnRpc2NoQGlldGYub3JnPG1haWx0bzo2 dGlzY2hAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbNnRpc2NoXSBbQ2FsbCBmb3IgUmV2aWV3XSBkcmFm dC1pZXRmLTZ0aXNjaC1tc2YtMDMNCg0KRGVhciBhbGwsDQoNCkEgbmV3IHZlcnNpb24gb2YgImRy YWZ0LWlldGYtNnRpc2NoLW1zZiIgaXMganVzdCBwdWJsaXNoZWQgYXQgaGVyZTogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi02dGlzY2gtbXNmLTAzLnR4dA0KDQpUaGlzIHZlcnNp b24gbWFpbmx5IHJlc29sdmVkIHRoZSBpc3N1ZXMgcHJlc2VudGVkIGR1cmluZyBJRVRGIDEwNCBt ZWV0aW5nLg0KSSB3b3VsZCBsaWtlIHRvIG1lbnRpb24gb25lIG9mIHRoZSBtYWluIGNoYW5nZXMg aW4gdGhpcyB2ZXJzaW9uIGlzIHdlIHJlbW92ZWQgdGhlIGZyYW1lIHBlbmRpbmcgYml0IGZlYXR1 cmUuDQoNCkl0J3MgZm9yIHR3byByZWFzb25zOg0KLSBpdCB3aWxsIGluZmx1ZW5jZSB0aGUgImFk YXB0IHRvIHRyYWZmaWMiIHN0cmF0ZWd5IG9mIE1TRi4NCi0gdGhlICJhZGFwdCB0byB0cmFmZmlj IiBzdHJhdGVneSBoYXMgdGhlIGFiaWxpdHkgdG8gaGFuZGxlIGJ1cnN0IHRyYWZmaWMgYnkgdXNp bmcgYSBzbWFsbGVyIE1BWF9OVU1DRUxMUw0KDQpOb3cgd2UgYXJlIGNhbGxpbmcgZm9yIHJldmll d3Mgb24gdGhlIG5ldyB2ZXJzaW9uIG9mIE1TRiENCkFueSBjb21tZW50cyBhbmQgZmVlZGJhY2sg YXJlIGFwcHJlY2lhdGVkIQ0KDQpUZW5nZmVpDQoNCg0KDQotLQ0KQ2hhbmcgVGVuZ2ZlaSwNClBv c3Rkb2N0b3JhbCBSZXNlYXJjaCBFbmdpbmVlciwgSW5yaWENCg0KDQotLQ0KQ2hhbmcgVGVuZ2Zl aSwNClBvc3Rkb2N0b3JhbCBSZXNlYXJjaCBFbmdpbmVlciwgSW5yaWENCg== --_000_OSAPR01MB3713BB5598E03C3D8644687EE53D0OSAPR01MB3713jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw 44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDvvLDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0x OjIgMTEgNiAwIDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt 77yzIOOCtOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IsO/MmTDvzMzICAwYjQwYjcwYzMw YWYiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBtbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBtbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowbW07DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi77yt77yzIO+8 sOOCtOOCt+ODg+OCryI7fQ0Kc3Bhbi4xOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToi77yt77yzIOOCtOOCt+ODg+OCryI7DQoJY29sb3I6IzJGNTQ5Njt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQXJpYWwiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo5OS4yNXB0IDMwLjBtbSAzMC4wbW0gMzAuMG1tO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiPg0KPHY6dGV4dGJveCBpbnNldD0iNS44NXB0LC43cHQsNS44NXB0LC43cHQiIC8+DQo8 L286c2hhcGVkZWZhdWx0cz48L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iSkEiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD 44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYiPlRoYW5rcywgVGVuZ2ZlaS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90 Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij5J IHVuZGVyc3RhbmQgdGhhdCBhZGFwdGF0aW9uIHRvIHRyYWZmaWMgZG9lc24ndCB3b3JrIGZvciBS eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg 44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYiPm1hbmFnZWQgY2VsbHMuIFNvLCBhcyB5 b3Ugc3VnZ2VzdGVkLCB0aGUgcGFyZW50IG5vZGUgc2hvdWxkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29s b3I6IzJGNTQ5NiI+dHJpZ2dlciA2UCBBREQvREVMRVRFL1JFTE9DQVRFIHRvIG9uZSBvZiBpdHMg Y2hpbGRyZW4sIHByb2JhYmx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzJGNTQ5NiI+dXNpbmcg My1zdGVwIHRyYW5zYWN0aW9uLiBUaGF0IHdvdWxkIGFmZmVjdCBkZXNjcmlwdGlvbiBvbiB1c2Fn ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg 44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYiPm9mIEF1dG9VcENlbGwgYW5kIEF1dG9E b3duQ2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 77yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OC ryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMyRjU0 OTYiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh cGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMyRjU0OTYiPlRvc2hpbyBJ dG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yz IOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAw bW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVu Z2ZlaSBDaGFuZyAmbHQ7dGVuZ2ZlaS5jaGFuZ0BnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgQXByaWwgMjMsIDIwMTkgMTA6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IGl0 byB0b3NoaW8oPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7kvIrol6Q8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+5L+K5aSrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiDil4s8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPu+8su+8pO+8ozwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj7ilqE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPu+8o++8ru+8rDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4pDQogJmx0 O3Rvc2hpbzkuaXRvQHRvc2hpYmEuY28uanAmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA2dGlzY2hAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFs2dGlzY2hdIFtDYWxsIGZvciBSZXZpZXdd IGRyYWZ0LWlldGYtNnRpc2NoLW1zZi0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5IaSBUb3NoaW8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhhbmtzIGZvciByZXZpZXcgdGhlIGRyYWZ0ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIHlvdXIgY29tbWVudHM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJF Ti1VUyI+TWluaW11bSBudW1iZXIgb2YgbWFuYWdlZCBjZWxscyAmbmJzcDs8L3NwYW4+PC9pPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UQzogWWVzLCBpdCdzIGJldHRlciB0byBoYXZlIGF0IGxlYXN0IG9uZSBUeCBNYW5hZ2VkIENl bGwgdG8gcGFyZW50LCBtYXliZSBvbmUgUnggTWFuYWdlZCBDZWxsIGFzIHdlbGwgZm9yIGRvd25z dHJlYW0sIGZvciB5b3VyIHNlY29uZCBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxz cGFuIGxhbmc9IkVOLVVTIj5EaXJlY3Rpb24gb2YgbWFuYWdlZCBjZWxsczwvc3Bhbj48L2k+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UQzogeWVzLCB0aGUgc3VwcG9ydCBvbiBUeCBhbmQgUnggbWFuYWdl ZCBjZWxsIGFyZSBub3QgY2xlYXIgaW4gMDMuIFdlIHdpbGwgcmVwaHJhc2UgdGhlIHNlY3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UQzogT25l IHByb2JsZW0gZGlzY292ZXJlZCBieSBub3cgaXMgdGhhdCB0aGUgYWRhcHRpb24gdG8gdHJhZmZp YyBvbmx5IHdvcmtzIG9uIFR4IGNlbGwgYWN0dWFsbHkuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRDOiBGb3IgUnggbWFuYWdlZCBjZWxsLCBpZiB0aGUgbm9kZSBkaWRuJ3QgcmVjZWl2ZSBh IHBhY2tldCBhdCBSeCBjZWxsLCBpdCBkb2Vzbid0IGtub3cgd2hlcmUgdGhlcmUgaXMgbm8gcGFj a2V0IGluY29taW5nIG9yIHRoZSBwYWNrZXQgaXMgZmFpbGVkIGJlY2F1c2Ugb2YgaW50ZXJmZXJl bmNlL2NvbGxpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRDOiBPbmUgc29sdXRpb24gZm9yIHRoYXQgaXMsIHdlIHdpbGwgb25seSBzdXBwb3J0 IFR4IG1hbmFnZWQgY2VsbCBidXQgdGhlIGluaXRpYXRvciBvZiA2UCZuYnNwOyBjb3VsZCBiZSBw YXJlbnQgYW5kIHRoZSByZXF1ZXN0IGlzIHNlbnQgdG8gb25lIG9mIGl0cyBjaGlsZHJlbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRlbmdmZWk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBBcHIg MjMsIDIwMTkgYXQgMjo1MSBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvc2hpbzkuaXRvQHRvc2hp YmEuY28uanAiPnRvc2hpbzkuaXRvQHRvc2hpYmEuY28uanA8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBtbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7 Y29sb3I6IzJGNTQ5NiI+SGkgVGVuZ2ZlaSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAw YjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzJGNTQ5NiI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYi PlRoYW5rcyBmb3IgdGhlIHdvcmsuIFRoZSBkcmFmdCBsb29rcyBwcm9taXNpbmcuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0 OTYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90 OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij5JIGhhdmUgdHdvIGNvbW1lbnRzIG9uIHRoZSBtYW5hZ2Vk IGNlbGxzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90Oyxz ZXJpZjtjb2xvcjojMkY1NDk2Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAw YjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzJGNTQ5NiI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYi PiogTWluaW11bSBudW1iZXIgb2YgbWFuYWdlZCBjZWxsczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78y ZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6 IzJGNTQ5NiI+U2VjLiA1LjE6IFJldmlzaW9uIC0wMiBoYWQgdGhlIGZvbGxvd2luZyBzZW50ZW5j ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7 Y29sb3I6IzJGNTQ5NiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3 MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPm1zZi0wMiZndDsgVG8gaGF2ZSB0aGUg Y291bnRlcnMgd29ya2luZywgYXQgbGVhc3Qgb25lIHVuaWNhc3QgY2VsbCBuZWVkPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0 OTYiPm1zZi0wMiZndDsgdG8gYmUgbWFpbnRhaW5lZCBhbGwgdGhlIHRpbWUgYW5kIG5ldmVyIGJl IHJlbW92ZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7 LHNlcmlmO2NvbG9yOiMyRjU0OTYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMg IDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij5Ib3dldmVyLCB0aGlzIGlz IHJlbW92ZWQgaW4gLTAzLiBTbywgSSB0aGluayBpdCdzIHBvc3NpYmxlIHRoYXQgbXNmLTAzPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9y OiMyRjU0OTYiPnJlbW92ZXMgYWxsIG1hbmFnZWQgY2VsbHMsIGFzIGEgcmVzdWx0IG9mIGFkYXB0 YXRpb24gdG8gdGhlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1 b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPnRyYWZmaWMuIElzIGl0IE9LPzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2Vy aWY7Y29sb3I6IzJGNTQ5NiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0 MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPiogRGlyZWN0aW9uIG9mIG1hbmFn ZWQgY2VsbHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDss c2VyaWY7Y29sb3I6IzJGNTQ5NiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAg MGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPkl0IGxvb2tzIGxpa2UgbWFu YWdlZCBjZWxscyBhcmUgb25seSBmb3IgdXBzdHJlYW0gdHJhZmZpYy48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzJGNTQ5NiI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlm O2NvbG9yOiMyRjU0OTYiPkluIHNlY3Rpb24gNC42LCB0aGUgam9pbmluZyBub2RlIGFkZHMgYSBU eCBjZWxsIHRvIHRoZSBwcmVmZXJyZWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQw YjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzJGNTQ5NiI+cGFyZW50Ljwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2Vy aWY7Y29sb3I6IzJGNTQ5NiI+bXNmLTAzJmd0OyBUaGVuIGl0IE1VU1QgaXNzdWUgYSA2UCBBREQg Y29tbWFuZCBNVVNUIHRvIHRoYXQgcGFyZW50LCB3aXRoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJk w78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPm1zZi0wMyZndDsg dGhlIGZvbGxvd2luZyBmaWVsZHM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3 MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPm1zZi0wMyZndDsmbmJzcDsmbmJzcDsm bmJzcDsgbyZuYnNwOyBDZWxsT3B0aW9uczogc2V0IHRvIFRYPTEsUlg9MCxTSEFSRUQ9MDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjoj MkY1NDk2Ij5tc2YtMDMmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTnVtQ2VsbHM6IHNl dCB0byAxPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNl cmlmO2NvbG9yOiMyRjU0OTYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBi NDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij5JbiBzZWN0aW9uIDUuMSwgdGhl IG5vZGUgYWRkcyBhIFR4IGNlbGwgdG8gdGhlIHByZWZlcnJlZCBwYXJlbnQgdG88L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzJGNTQ5 NiI+YWRhcHQgdG8gdGhlIHRyYWZmaWMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0 MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij5t c2YtMDMmZ3Q7IHRoZSBub2RlIGlzc3VlcyBhIDZQIEFERCBjb21tYW5kIHRvIGl0cyBwcmVmZXJy ZWQgcGFyZW50IHRvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1 b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPm1zZi0wMyZndDsgYWRkIG9uZSBtYW5hZ2VkIFR4IGNl bGwgdG8gdGhlIFRTQ0ggc2NoZWR1bGUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0 MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij5C ZWNhdXNlIDZQIHRyYW5zYWN0aW9uIGlzIGFsd2F5cyBpbml0aWF0ZWQgZnJvbSB0aGUgY2hpbGQg dG8gdGhlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNl cmlmO2NvbG9yOiMyRjU0OTYiPnByZWZlcnJlZCBwYXJlbnQsIGFuZCBDZWxsT3B0aW9uIGluIDZQ IEFERCByZXF1ZXN0IGlzIGFsd2F5cyAoPykgVHg9MTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/ MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij5SWD0wLCB0aGVyZSBp cyBubyBkb3duc3RyZWFtIG1hbmFnZWQgY2VsbHMuIEFzIGEgcmVzdWx0LCBkb3duc3RyZWFtPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9y OiMyRjU0OTYiPnBhY2tldHMgc3VjaCBhcyBEQU8tQUNLIGhhdmUgdG8gdXNlIEF1dG9Eb3duQ2Vs bCBvciB0aGUgbWluaW1hbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBh ZiZxdW90OyxzZXJpZjtjb2xvcjojMkY1NDk2Ij5jZWxsLiBJIHRoaW5rIHdlIHNob3VsZCBoYXZl IGRvd25zdHJlYW0gY2VsbHMsIHRvby48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQw YjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzJGNTQ5NiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJp Zjtjb2xvcjojMkY1NDk2Ij5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78z MyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMyRjU0OTYiPlRvc2hpbyBJdG88L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6 IzJGNTQ5NiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAw bW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiA2 dGlzY2gNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOjZ0aXNjaC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxm IE9mIDwvYj5UZW5nZmVpIENoYW5nPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDA5 LCAyMDE5IDE6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42dGlzY2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFs2dGlzY2hdIFtDYWxsIGZvciBSZXZpZXddIGRyYWZ0LWlldGYtNnRpc2NoLW1zZi0w Mzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbmV3IHZlcnNpb24gb2YgJnF1b3Q7ZHJhZnQtaWV0Zi02 dGlzY2gtbXNmJnF1b3Q7IGlzIGp1c3QgcHVibGlzaGVkIGF0IGhlcmU6Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi02dGlzY2gtbXNmLTAzLnR4dCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtNnRpc2NoLW1z Zi0wMy50eHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhpcyB2ZXJzaW9uIG1haW5seSByZXNvbHZlZCB0aGUgaXNzdWVzIHByZXNlbnRl ZCBkdXJpbmcgSUVURiAxMDQgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdvdWxk IGxpa2UgdG8gbWVudGlvbiBvbmUgb2YgdGhlIG1haW4gY2hhbmdlcyBpbiB0aGlzIHZlcnNpb24g aXMgd2UgcmVtb3ZlZCB0aGUgZnJhbWUgcGVuZGluZyBiaXQgZmVhdHVyZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCdzIGZvciB0d28gcmVh c29uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4t IGl0IHdpbGwgaW5mbHVlbmNlIHRoZSAmcXVvdDthZGFwdCB0byB0cmFmZmljJnF1b3Q7IHN0cmF0 ZWd5IG9mIE1TRi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+LSB0aGUgJnF1b3Q7YWRhcHQgdG8gdHJhZmZpYyZxdW90 OyBzdHJhdGVneSBoYXMgdGhlIGFiaWxpdHkgdG8gaGFuZGxlIGJ1cnN0IHRyYWZmaWMgYnkgdXNp bmcgYSBzbWFsbGVyIE1BWF9OVU1DRUxMUzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5O b3cgd2UgYXJlIGNhbGxpbmcgZm9yIHJldmlld3Mgb24gdGhlIG5ldyB2ZXJzaW9uIG9mIE1TRiEm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbnkgY29tbWVudHMgYW5kIGZlZWRiYWNrIGFy ZSBhcHByZWNpYXRlZCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5UZW5nZmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOiNGREZERkQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGFu ZyBUZW5nZmVpLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6I0ZERkRG RCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+ UG9zdGRvY3RvcmFsIFJlc2VhcmNoIEVuZ2luZWVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+LCBJbnJpYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4t LSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGREZERkQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hhbmcgVGVuZ2ZlaSw8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OiNGREZERkQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndo aXRlIj5Qb3N0ZG9jdG9yYWwgUmVzZWFyY2ggRW5naW5lZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4sDQogSW5yaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_OSAPR01MB3713BB5598E03C3D8644687EE53D0OSAPR01MB3713jpnp_--
Dr. Xavier Vilajosana
Wi= reless Networks Lab
Internet Interdisciplinary Institute (IN3)
Pro= fessor

(+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.orghttp://wine.rdi.uoc.= edu
Parc Med= iterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Building08860 Castelldefels (Barcelona). Catalonia. Spain