Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 13 May 2020 09:08 UTC
Return-Path: <pthubert@cisco.com>
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 2861F3A0FDD; Wed, 13 May 2020 02:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=J22bRkz1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ThmyEPma
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd0hn-ey_hLC; Wed, 13 May 2020 02:08:09 -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 754143A0C0B; Wed, 13 May 2020 02:08:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=183459; q=dns/txt; s=iport; t=1589360889; x=1590570489; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=djHcac264f1h6+2oK5EEllqjTdjYY1IjKq1M7nnJ3h0=; b=J22bRkz12oEdcXY5/leIswWJiqL1RASstugbCWYJ3zl+uuxFHeQDj84N l0yfRfslEqeYN+ulikFPfYh4RAZ0CzjePpKwS9Mhk8jHaLw33co7YO4E7 evJfbgq5pwuPZrSXMMlazj9pLATiWDoYwrF3ahhquxzdJUqbSDiZGHKdy k=;
X-Files: image001.jpg, inria.jpg : 10697, 10697
IronPort-PHdr: 9a23:XpGjMhMwYwu17REEayIl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvKw13lrIQcPW5+8Xw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoNElJXsvyeg6arni79zVHHBL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DzAQD0t7te/40NJK1mGwEBAQEBAQEBBQEBARIBAQEDAwEBAYIHgSUvJC0Hb1gvLIQlg0YDjRIliXqOPYFCgRADUAQEBwEBAQkBAgEBGAEKCgIEAQGDf0UCF4FxJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQMBAQMBDAgBCAIIARIBAQceBwsBDwIBBgIRBAEBBgEBCw4BBgMCAgIFEAoGCxQJCAIEDgUJBQ0HgwQBgksDLgEOlGKQZwKBOYhhdoEygwEBAQWBMgETQYM4DQuCBwcJgTiCY4JIghmEfhqBQT+BEScMEFF+fj6CHkkBAQECAYEjCQEJAgcBAwQUCwMPCAgGCQiCVjOCLY4sAREOAQOCTQE8hiGBOYk5h2oDWIZSM0oKgkuGZAKBN4tBBIRQHYJciGwWhGyEA4dQgSuaB4JHkQ4CBAIEBQIOAQEFgSsEOiJmWBEHcBUaISoBgj4JRxgNkEAHBAEXFYM6hRSFQnQCNQIGAQcBAQMJfIwDgkUBAQ
X-IronPort-AV: E=Sophos;i="5.73,387,1583193600"; d="jpg'145?scan'145,208,217,145";a="769827820"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 May 2020 09:08:07 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 04D986HL021498 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2020 09:08:07 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 04:08:06 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 04:08:05 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 13 May 2020 05:08:05 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m7QyhUyV2AFwc2cg8CXhuMiHl2NufQuLZ/Dx5Mp2skWQooOVYuCiwrir6GNunFFWIDaWpzUEiQxAIMVYoUNADT1Ci1lrf4j7WAUbNroHYu0ktIbTcnDetQs/rLjLWfnDixfIrT8oLNDCeirtZKWW87AxmB95hzEKv0zn8rY6ejIw3rRsQw0kVtGjO1QwYVDH0pylDE3PhZsZiorXno35lxk6G7wpnLDlbblT0wIqdqibvBSppXflXxBvEMtUHTjlJIu+0VgUvZ37rk1aqg3angyw58h9oJ2V9kqNp4kyXlwjkPKoCQirBDJj4y84S/Vtos8TCA4JYWXwmPCQ18MiyQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jKmrRDIGux/F/SKbSb2bdSkDebkqzihOKdtFKAmeBn4=; b=mF+jtz2Hw7wp1YA3bZf30dY37VLPAlmjoh+G+RcDfelDwgWpLLaH0LqsGnsuVYTqJ3GaF8XBFOx53P7nX7RHaIL9wQBCAvjln+CT3Ln2tayAxggN4W1Z7V/dKBOGva4PljvwSIo1Z47SaDZVdfu+/1iqQ6vzSromt937flzLS6e4USaHMof8QToydAo41kyx+3eN7IXWoBD+VssGaXZ2oXjZP4tiZEsZKO1DCJ6EvePe6YE8tl6lpu3rgPCZHyY0/RbkeFTJpfTqgk0+/+g/u31Ke2EWrg9uVkoO2nrDkI784+Wzxn/YhHmdvzlG+LwqDCDji5DhdzDPdR46/LQQUg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jKmrRDIGux/F/SKbSb2bdSkDebkqzihOKdtFKAmeBn4=; b=ThmyEPma62oGlnyfSvWh2nhYa1lnCUDHzSUskbpRc6jMb7BszIBWleuqZpTX8Hl6lt8M4BDrTPPF23+bVpPagbhS8y/AzjvGvjt9K7FKW9+v2YJWRECi/C0fOSGkfBrGewtUyn3laGEs6iHuHNkBL/6j6VTwhmsUQXn9EXbPzt8=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3614.namprd11.prod.outlook.com (2603:10b6:208:ea::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Wed, 13 May 2020 09:08:03 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2979.033; Wed, 13 May 2020 09:08:03 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tengfei Chang <tengfei.chang@inria.fr>
CC: Benjamin Kaduk <kaduk@mit.edu>, tengfei chang <tengfei.chang@gmail.com>, iesg <iesg@ietf.org>, draft-ietf-6tisch-msf <draft-ietf-6tisch-msf@ietf.org>, 6tisch <6tisch@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org>
Thread-Topic: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)
Thread-Index: AQHWJ4ybnh6Qi3kpc0am7qSSZwMhPqii39AQ8SgemAmO2A4YUDT/wawQ/lqyXCA=
Date: Wed, 13 May 2020 09:08:03 +0000
Message-ID: <893DF4D7-603B-4281-9A40-D3340A4325CA@cisco.com>
References: <158588511619.26351.4149213511250395502@ietfa.amsl.com> <CAAdgstQ8QfXg5TtL30vqL38C=Ey8Qaa0RT2Gzd_at1pBhQOaeA@mail.gmail.com> <MN2PR11MB35651B029F7998BC4EE7CDBBD8A10@MN2PR11MB3565.namprd11.prod.outlook.com> <350915165.1841546.1589209223906.JavaMail.zimbra@inria.fr> <MN2PR11MB3565AD8A8F85BD204C7D6B45D8A10@MN2PR11MB3565.namprd11.prod.outlook.com>, <1029635691.2295344.1589360582240.JavaMail.zimbra@inria.fr>
In-Reply-To: <1029635691.2295344.1589360582240.JavaMail.zimbra@inria.fr>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:83e:9ef3:c409:f81f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4c6e04e9-a902-425b-885a-08d7f71d247d
x-ms-traffictypediagnostic: MN2PR11MB3614:
x-microsoft-antispam-prvs: <MN2PR11MB3614B981AE8168438E13FF37D8BF0@MN2PR11MB3614.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0402872DA1
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: V/rCx6/DGk8bI1FAr3tzp2WxWj9Kjqi8vlOLPt8RclwZG+lQsm6GUPEiB/P+tZChEjgGuvUvsXBhoumrmE8l2yS0E/ouncfkKtO/gqpCq3WzFJxTBT1hW7AwPyi8X+N2p1ss6bFV0CMOrWB6sqDwQfRKwtuucCztaRmiY2gKUK8gjMgZH4IQc14hWEmRvIBfrAMcREfqCIB945TwERhJ6io356HY1Z//60VEh3CahDtyMyhFoAWtG7R/u0gC/2nJmcKanvqfZXoN9toiQ3scTc6RKNxkx4gRbcAusuvHWGNaLUGwWV4mVUtLDXlyj1Ry20hXvi4gauGhT97fGKEm8AAtmW5v+p228ffH4syCLXFzMYxtQ4zkBNcjXsgYyZ5jON3yw0/A/uCAUqw3Przefu1dWo0qPtKCdbXcQq25kieKSfnhhw1lr7qhqWCQ2+VqesKk4H+qimGhmoTBW8bxBvjjhF1CFLilGIDjlZwJ5rsVp6ZVU8FHAgTeMvlCfuZEli2T0J9zWSwxVjj6IcxNm2T1/NKMoGNLYQkWlWzJZocyFyTVe9cX8Xr+0aF841FbCN4gbL7eNvbFKq/Dv4GAhNb2nZjx0OlIOjhFg5CiuC3u7QBEEp58rKo0zP8txxoI
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(366004)(396003)(39850400004)(33430700001)(66946007)(66576008)(33440700001)(8676002)(64756008)(54906003)(4326008)(5660300002)(2616005)(8936002)(30864003)(6916009)(33656002)(66574014)(86362001)(478600001)(66446008)(6506007)(966005)(76116006)(166002)(66556008)(6486002)(66476007)(91956017)(186003)(53546011)(21615005)(316002)(99936003)(6512007)(2906002)(71200400001)(36756003)(579004)(559001)(244885003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: UBtj7gSOU06JGs1hOe47082saUOQsVOscvwOf0t60i8Vk5diFwAO4a5/udhxHz4vEwEOK0nWIH4Md2DGbxhXCvCRSurrN6e9XR3vVi7sJoZMHXdVtie6DHCWrCh2X22gssz6FkyHrR+VfWQYLmlSQJoJEPhxwSkctBvg7ut1zAC1o4bSnL6VJl4BgEJQ5fUMiS+STEZsPPzBpqHvdv1p5+fBvT2QKSU69Me48/amuEu2lgHezEC3zM186cebOmiUt6HPd8ahMM8b8HrpftoHihtH8VeDrq2pJVh5OKaVLdP8k0/TQfGQKnE4x8FFqCONi9YfUlNNxbfo8CFIeAxVmUy5MbG3RSPCwYsqVHI9IsoQu2pbqGEVZBh79lJ0lbg1ya0E/ZPWvYU84ZH4ZE+UgSjannVwJcOrAyf2XLsXvegbsh4G5FYFOj/dwV/R7AH4DHhbaK3P/gctweP1BRXOm9SvgQQUYwzLUCk8tif5RfhDwkKXbxsFyXz9Cd9BmyKPashuf1RFy/J74KUrgjapxcx+R0eJlHKqbdeSnnPO3ekp2DiEw67uk7k2StGQVfrl
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_005_893DF4D7603B42819A40D3340A4325CAciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c6e04e9-a902-425b-885a-08d7f71d247d
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 09:08:03.2924 (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-CrossTenant-userprincipalname: K2fV5V54EECH1hTUEa4f+1AXvtViOf3oX/po5HOI6sJfRvW+rjTH5r+bS68mUCyWGvdJtyKedBjBLmCC7qlnCA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3614
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/QRCJQF9e0yBuLhuU1rkvLzFOHOg>
Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)
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: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2020 09:08:15 -0000
Oh that’s cool then we can keep a note for the rfc editor no need for republishing I’ll ping Alvaro see if the doc can be queued now. Take care, Pascal Le 13 mai 2020 à 11:03, Tengfei Chang <tengfei.chang@inria.fr> a écrit : Hi Pascal, It turns out I missed read Benjamin's suggestion: Benjiamin suggested: I suggest '''one routing parent; this parent is referred to as the "selected parent"'''. I miss read it as the suggestion is to replace "one routing parent" by "the selected parent", which I changed it to the "selected routing parent". Will correct it and publish a new version. Thanks for the catching! Tengfei ________________________________ Stay Healthy! Stay Optimistic! Dr. Tengfei Chang Post-doctoral Researcher Wireless Networking for Evolving & Adaptive Applications (EVA) National Inst. for Research in Comp. Sci. and Automation (Inria) (+33)1 80 49 41 43 tengfei.chang@inria.fr www.tchang.org ____________________ <inria.jpg> ________________________________ From: "Pascal Thubert, pthubert" <pthubert@cisco.com> To: "Tengfei Chang" <tengfei.chang@inria.fr>, "Benjamin Kaduk" <kaduk@mit.edu> Cc: "tengfei chang" <tengfei.chang@gmail.com>, "iesg" <iesg@ietf.org>, "draft-ietf-6tisch-msf" <draft-ietf-6tisch-msf@ietf.org>, "6tisch" <6tisch@ietf.org>, "6tisch-chairs" <6tisch-chairs@ietf.org> Sent: Monday, May 11, 2020 6:08:50 PM Subject: RE: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT) Hello Benjamin and Tengfei; What I did is pick one randomly, and picked this; “ MSF works closely with RPL, specifically the routing parent defined in [RFC6550]. This specification only describes how MSF works with one routing parent, which is phrased as "selected parent". The nit: I suggest '''one routing parent; this parent is referred to as the "selected parent"'''. “ Then I looked at 16 and the text is still MSF works closely with the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), specifically the routing parent defined in [RFC6550<https://tools.ietf.org/html/rfc6550>]. This specification only describes how MSF works with the selected routing parent, which is phrased as "selected parent". The activity of MSF towards the single routing parent is called a "MSF session". Though the performance of MSF is evaluated only when the "selected parent" represents the node's preferred parent, there This tells me that the handling of Benjamin’s review is not complete, so I asked Tengfei to double check. Take care; Pascal From: Tengfei Chang <tengfei.chang@inria.fr> Sent: lundi 11 mai 2020 17:00 To: Pascal Thubert (pthubert) <pthubert@cisco.com> Cc: tengfei chang <tengfei.chang@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; iesg <iesg@ietf.org>; draft-ietf-6tisch-msf <draft-ietf-6tisch-msf@ietf.org>; 6tisch <6tisch@ietf.org>; 6tisch-chairs <6tisch-chairs@ietf.org> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT) Hi Pascal, If comparing the comments to draft-ietf-6tisch-msf-12 from another thread previously, you will find out they are actually the same. Those comments are indeed fixed with the MSF versions after 12, including draft-ietf-6tisch-msf-16. Regards, Tengfei ________________________________ Stay Healthy! Stay Optimistic! Dr. Tengfei Chang Post-doctoral Researcher Wireless Networking for Evolving & Adaptive Applications (EVA) National Inst. for Research in Comp. Sci. and Automation (Inria) (+33)1 80 49 41 43 tengfei.chang@inria.fr<mailto:tengfei.chang@inria.fr> www.tchang.org<http://www.tchang.org> ____________________ <image001.jpg> ________________________________ From: "Pascal Thubert, pthubert" <pthubert@cisco.com<mailto:pthubert@cisco.com>> To: "tengfei chang" <tengfei.chang@gmail.com<mailto:tengfei.chang@gmail.com>>, "Benjamin Kaduk" <kaduk@mit.edu<mailto:kaduk@mit.edu>> Cc: "iesg" <iesg@ietf.org<mailto:iesg@ietf.org>>, "draft-ietf-6tisch-msf" <draft-ietf-6tisch-msf@ietf.org<mailto:draft-ietf-6tisch-msf@ietf.org>>, "6tisch" <6tisch@ietf.org<mailto:6tisch@ietf.org>>, "6tisch-chairs" <6tisch-chairs@ietf.org<mailto:6tisch-chairs@ietf.org>> Sent: Monday, May 11, 2020 4:23:12 PM Subject: RE: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT) Hello Tengfei My reading is that the comments below apply to version 16 as the title indicates. I randomly checked the proposed nit fixes and the issues are effectively still left to be fixed. Can you please have a look? Take care, Pascal From: Tengfei Chang <tengfei.chang@gmail.com<mailto:tengfei.chang@gmail.com>> Sent: lundi 11 mai 2020 14:06 To: Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> Cc: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; draft-ietf-6tisch-msf@ietf.org<mailto:draft-ietf-6tisch-msf@ietf.org>; 6tisch <6tisch@ietf.org<mailto:6tisch@ietf.org>>; 6tisch-chairs@ietf.org<mailto:6tisch-chairs@ietf.org>; Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT) Hi Benjamin, Thanks for updating the comments! I believe the change from the current email comparing to previous one is that the DISCUSSION part is removed as we fixed it in another previous thread. The other comments from the current email are actually for old version of MSF, which are all resolved in the latest version MSF-16. For the administration, I want to clarify that the draft-ietf-6tisch-msf-16 has resolved all comments which were discussed. Please advise me if there is any further action required. Thanks a lot! Regards, Tengfei On Fri, Apr 3, 2020 at 5:38 AM Benjamin Kaduk via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-6tisch-msf-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for clarifying the non-issue nature of my original Discuss points! Original COMMENT section preserved below (possibly stale). I support Roman's Discuss -- we need more information for this to be a useful reference; even what seem to be the official DASFAA 1997 proceedings (https://dblp.org/db/conf/dasfaa/dasfaa97) do not have an associated document). Basing various scheduling aspects on (a hash of) the EUI64 ties functionality to a persistent identifier for a device. How significant a disruption would be incurred if a device periodically changes its presented EUI64 for anonymization purposes? There seems to be a general pattern of "if you don't have a 6P-negotiated Tx cell, install and AutoTxCell to send your one message and then remove it after sending"; I wonder if it would be easier on the reader to consolidate this as a general principle and not repeat the details every time it occurs. Requirements Language "NOT RECOMMENDED" is not in the RFC2119 boilerplate (but is a BCP 14 keyword). Section 1 the 6 steps described in Section 4. The end state of the join process is that the node is synchronized to the network, has mutually authenticated to the network, has identified a routing parent, and nit(?): I guess maybe "mutually authenticated with" is more correct for the bidirectional operation. It does so for 3 reasons: to match the link-layer resources to the traffic, to handle changing parent, to handle a schedule collision. nit: end the list with "or" (or "and"?). MSF works closely with RPL, specifically the routing parent defined in [RFC6550]. This specification only describes how MSF works with one routing parent, which is phrased as "selected parent". The nit: I suggest '''one routing parent; this parent is referred to as the "selected parent"'''. activity of MSF towards to single routing parent is called as a "MSF nit: "towards the" * We added sections on the interface to the minimal 6TiSCH configuration (Section 2), the use of the SIGNAL command (Section 6), the MSF constants (Section 14), the MSF statistics (Section 15). nit: end the list with "and". Section 2 In a TSCH network, time is sliced up into time slots. The time slots are grouped as one of more slotframes which repeat over time. The nit(?): should this be "one or more"? channel) is indicated as a cell of TSCH schedule. MSF is one of the policies defining how to manage the TSCH schedule. nit: if there is only one such policy active at a given time for a given network, I suggest "MSF is a policy for managing the TCSH schedule". (If multiple policies are active simultaneously, no change is needed.) MSF uses the minimal cell for broadcast frames such as Enhanced Beacons (EBs) [IEEE802154] and broadcast DODAG Information Objects (DIOs) [RFC6550]. Cells scheduled by MSF are meant to be used only for unicast frames. If this paragraph was moved before the previous paragraph, then EB and DIO would be defined before their first usage. bandwidth of minimal cell. One of the algorithm met the rule is the Trickle timer defined in [RFC6206] which is applied on DIO messages [RFC6550]. However, any such algorithm of limiting the broadcast nit(?): "One of the algorithms that fulfills this requirement"? MSF RECOMMENDS the use of 3 slotframes. MSF schedules autonomous cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe 2 (Section 5) , while Slotframe 0 is used for the bootstrap traffic as defined in the Minimal 6TiSCH Configuration. It is RECOMMENDED to use the same slotframe length for Slotframe 0, 1 and 2. Thus it is Perhaps this is just a question of writing style, but if an implementation is free to use an alternative SF or a variant of MSF, could we not say that "MSF uses 3 slotframts", "MSF uses the same slotframe length for", etc.? Section 3 Is there any risk of unwanted correlation between slot and channel offsets when using the same hash function and input for both calculations? hash function. Other optional parameters defined in SAX determine the performance of SAX hash function. Those parameters could be broadcasted in EB frame or pre-configured. For interoperability purposes, an example how the hash function is implemented is detailed in Appendix B. Given the lack of usable reference for [SAX-DASFAA], I assume that the content in Appendix B is going to be used as a specification, not just an example. * The AutoRxCell MUST always remain scheduled after synchronized. nit: s/synchronized/synchronization/ AutoRxCell. In case of conflicting with a negotiated cell, autonomous cells take precedence over negotiated cell, which is stated in [IEEE802154]. However, when the Slotframe 0, 1 and 2 use the same length value, it is possible for negotiated cell to avoid the collision with AutoRxCell. Presumably this factors in to the recommendation to have the three listed slotframes use the same length, but mentioning it explicitly (whether here or where the recommendation is made) might be nice. Section 4 network. Alternative behaviors may involved, for example, when alternative security solution is used for the network. Section 4.1 nit: singular/plural mismatch "behaviors"/"solution is used" Section 4.1 A node implementing MSF SHOULD implement the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a Didn't this get renamed to CoJP? Section 4.2 I a little bit wonder if there is a better description than "available frequencies" but don't have one to offer. Section 4.3 While the exact behavior is implementation-specific, it is RECOMMENDED that after having received the first EB, a node keeps listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in [RFC8180]. nit(?): this phrasing implies that only NUM_NEIGHBOURS_TO_WAIT is defined in RFC 8180, but MAX_EB_DELAY is also defined there. not-nit: this phrasing is ambiguous as to whether one of MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT is sufficient to move to the next step or whether both are required. Section 4.4 After selected a JP, a node generates a Join Request and installs an AutoTxCell to the JP. The Join Request is then sent by the pledge to its JP over the AutoTxCell. The AutoTxCell is removed by the pledge editorial: I'd suggest s/its JP/its selected JP/ Response is sent out. The pledge receives the Join Response from its AutoRxCell, thereby learns the keying material used in the network, as well as other configurations, and becomes a "joined node". nit: maybe "other configuration values" or "other configuration settings"? Section 4.6 Once it has selected a routing parent, the joined node MUST generate a 6P ADD Request and install an AutoTxCell to that parent. The 6P ADD Request is sent out through the AutoTxCell with the following fields: * CellOptions: set to TX=1,RX=0,SHARED=0 * NumCells: set to 1 * CellList: at least 5 cells, chosen according to Section 8 Is this listing describing the contents of the ADD request or the AuthTxCell used to send it? (I presume the former, in which case I suggest to use "containing" or similar in preference to "with".) Section 5.1 The goal of MSF is to manage the communication schedule in the 6TiSCH schedule in a distributed manner. For a node, this translates into monitoring the current usage of the cells it has to the selected parent: Is this goal strictly limited to traffic "to the selected parent" vs. all traffic? * If the node determines that the number of link-layer frames it is attempting to exchange with the selected parent per unit of time is larger than the capacity offered by the TSCH negotiated cells it has scheduled with it, the node issues a 6P ADD command to that parent to add cells to the TSCH schedule. * If the traffic is lower than the capacity, the node issues a 6P DELETE command to that parent to delete cells from the TSCH schedule. As written, this would potentially lead to oscillation when demand is basically at capacity, due to the quantization of capacity. Perhaps some provisioning for hysteresis is appropriate? The cell option of cells listed in CellList in 6P Request frame SHOULD be either Tx=1 only or Rx=1 only. Both NumCellsElapsed and NumCellsUsed counters can be used to both type of negotiated cells. Would this be more clear as "(Tx=1,Rx=0) or (Tx=0,Rx=1)"? * NumCellsElapsed is incremented by exactly 1 when the current cell is AutoRxCell. This holds for all peers/parents we're keeping counters for, so the AutoRxCell can get "double counted"? In case that a node booted or disappeared from the network, the cell reserved at the selected parent may be kept in the schedule forever. A clean-up mechanism MUST be provided to resolve this issue. The clean-up mechanism is implementation-specific. It could either be a periodic polling to the neighbors the nodes have negotiated cells with, or monitoring the activities on those cells. The goal is to confirm those negotiated cells are not used anymore by the associated neighbors and remove them from the schedule. I'm not sure that "monitoring the activities on those cells" is safe with the current level of specification; if a node negotiates a 6P transmit cell to a parent and uses it only sparingly, with the parent eventually reclaiming it due to inactivity, I don't see a mechanism by which the node will reliably discover the negotiated cell to be nonfunctional and fall back to (e.g.) the corresponding AutoTxCell. It may be most prudent to just not mention that as an example (a "periodic polling" procedure does not seem to have the same potential for information skew) Section 5.3 schedule is executed and the node sends frames to that parent. When NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided by 2. For example, when MAX_NUMTX is set to 256, from NumTx=255 and NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one frame is sent to the parent with an Acknowledgment received. This operation does not change the value of the PDR, but allows the counters to keep incrementing. The value of MAX_NUMTX is implementation-specific. Does MAX_NUMTX need to be a power of two (to avoid errors when the division occurs)? 4. For any other cell, it compares its PDR against that of the cell with the highest PDR. If the difference is larger than RELOCATE_PDRTHRES, it triggers the relocation of that cell using a 6P RELOCATE command. The recommended RELOCATE_PDRTHRES is given as "50 %". Is this "difference" performed as a subtraction (so that if the highest PDR is less than 50%, no cells can ever be relocated) or a ratio (a PDR that's half than the maximum PDR or smaller will trigger relocation)? Section 7 Maybe reference Section 17.1 where the allocation will occur? Section 8 * The slotOffset of a cell in the CellList SHOULD be randomly and uniformly chosen among all the slotOffset values that satisfy the restrictions above. * The channelOffset of a cell in the CellList SHOULD be randomly and uniformly chosen in [0..numFrequencies], where numFrequencies represents the number of frequencies a node can communicate on. Do these random selections need to be independent from each other? (I note that the selection for the autonomous cells are not.) Section 9 Is there a reference for these three parameters (MAXBE, MAXRETRIES, SLOTFRAME_LENGTH)? SLOTFRAME_LENGTH seems new in this document and is listed in the table in Section 14, but the other two are not listed there. Section 14 Why is MAX_NUMTX not listed in the table? Can we really give a recommended NUM_CH_OFFSET value, since this is in effect dependent on the number of channels available? KA_PERIOD is defined but not used elsewhere in the document. What are the considerations in using a power of 10 vs. a power of 2 as MAX_NUM_CELLS? Section 16 MSF defines a series of "rules" for the node to follow. It triggers several actions, that are carried out by the protocols defined in the following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation I'd suggest a brief note that the security considerations of those protocols continue to apply (even though it ought to be obvious); reading them could help a reader understand the behavior of this document as well. Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF [CoJP again] prevent it from receiving the join response. This situation should be detected through the absence of a particular node from the network and handled by the network administrator through out-of-band means, e.g. by moving the node outside the radio range of the attacker. "the radio range of the attacker" is not exactly a fixed constant ... attackers are not in general bound by legal limits and can increase Tx power subject only to their equipment and budget. MSF adapts to traffics containing packets from IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2597]) value in its IPv6 header. The decision whether to hand RFC 2597 is talking more about specifically assured forwarding PHB groups than "DSCP codepoint"s per se. Section 18.1 RFC 6206 seems to only be used as an example (Trickle), and could probably be informative. RFC 8505 might also not need to be normative. Appendix B In MSF, the T is replaced by the length slotframe 1. String s is nit: "length of" 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci Is this addition performed in "infinite precision" integer arithmetic or limited to the output width of h, e.g., by modular division? (It's not clear to me whether this is the role T plays or not.) 8. assign the result of Step 5 to h The value from step 5 *is* h, so taken literally this says "assign h to h" and is not needed. _______________________________________________ 6tisch mailing list 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch -- —————————————————————————————————————— Stay healthy, stay optimistic! Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tchang.org/<http://www.tchang.org/> ——————————————————————————————————————
- [6tisch] Benjamin Kaduk's No Objection on draft-i… Benjamin Kaduk via Datatracker
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Tengfei Chang
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Pascal Thubert (pthubert)
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Tengfei Chang
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Benjamin Kaduk
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Pascal Thubert (pthubert)
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Tengfei Chang
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Pascal Thubert (pthubert)
- Re: [6tisch] Benjamin Kaduk's No Objection on dra… Tengfei Chang