Re: [6tisch] Comments on draft-ietf-6tisch-msf-00

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Fri, 31 August 2018 13:33 UTC

Return-Path: <yasuyuki.tanaka@inria.fr>
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 6B373129AB8 for <6tisch@ietfa.amsl.com>; Fri, 31 Aug 2018 06:33:43 -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] 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 pdySpHigZjMo for <6tisch@ietfa.amsl.com>; Fri, 31 Aug 2018 06:33:41 -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 EF8C6127AC2 for <6tisch@ietf.org>; Fri, 31 Aug 2018 06:33:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.53,311,1531778400"; d="scan'208";a="277328879"
Received: from wifi-pro-82-010.paris.inria.fr ([128.93.82.10]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2018 15:33:38 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
In-Reply-To: <CAC9+vPgkks2MxcVew2ip1uS4ot=gxRwpg+QLyRx-8SipB1fw9g@mail.gmail.com>
Date: Fri, 31 Aug 2018 15:33:38 +0200
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, tisch <6tisch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C508DE48-82D4-4054-84E2-A18278DBB97E@inria.fr>
References: <AB8128C5-C5A4-4E1D-95E5-66ED6A98A1F8@inria.fr> <CAMxvJt+b=pDKz7Tsm1ZXtTsggp1eEiuj9eoKPAz7HNKww=c_Rw@mail.gmail.com> <CAC9+vPgkks2MxcVew2ip1uS4ot=gxRwpg+QLyRx-8SipB1fw9g@mail.gmail.com>
To: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>, Simon Duquennoy <simon.duquennoy@ri.se>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/qIb0IJZLOeiaoK6rghxn8d3FFlM>
Subject: Re: [6tisch] Comments on draft-ietf-6tisch-msf-00
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 31 Aug 2018 13:33:44 -0000

Thank you, Simon and Xavi!

A couple of things:

>>> 'MUST' here sounds too strong... Some may want to use MSF with a base schedule
>>> other than one defined RFC 8180 with full understands on implications by not
>>> following RFC 8180. Then, I'd propose 'SHOULD'.
>>> 
>>> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP
>>> document or not.
>> 
>> MSF assumes the presence of the minimal cell, but might be able to run without the full RFC8180.
>> Happy to hear what others think
>> 
> XV>> MSF needs at least one pre-existing cell in the schedule so a node can receive/send EBs and form/join into the network. To ensure this we enforce RFC8180.

If the minimal shared cell is only the dependency for MSF, it'd be much clearer to say that instead of saying, "MSF MUST implement RFC 8180". RFC 8180 defines far more things than having the minimal shared cell. And, it concerns 2.4 GHz O-QPSK PHY alone.

>>> * minor comment 6
>>> 
>>> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
>>> section?
>>> 
>> I'll let other co-authors answer
>> 
> XV> I think this was though to handle pagination when the LIST command is received. This is, define what are the cells to return when a list command is requesting cells from a particular offset. 

I see; then, I'd like to have such explanation in Section 10 :-)

   https://tools.ietf.org/html/draft-ietf-6tisch-msf-00#section-10

Best,
Yatch