Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

Tengfei Chang <> Tue, 24 March 2020 11:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42BB03A0801; Tue, 24 Mar 2020 04:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0gvJDMZeJCjc; Tue, 24 Mar 2020 04:57:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAEEA3A077E; Tue, 24 Mar 2020 04:57:46 -0700 (PDT)
Received: by with SMTP id t3so4708078vkm.10; Tue, 24 Mar 2020 04:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FzgS30/MMX+0Jx4p5sUe6clEIaM/1l4lpJCilBp0ADY=; b=XoUfxb3wdETywQXyjSgcZT6Zz/ARP1HQRpxAsU0LDEGBE+K05yZpokYmYPX+lEwReg dsyqxI/sg/BLss+PEgeuvhSJMVYufwmYkmncRFKAgyZt6oomqqdW0E36srCv2MbvJ+fI ss/gy5o/isV/gQB7TPl77FaDkwoTtGJyNJFPdXqzWuEhRU3geTA8W7uQJBSnUTJsP8kX jWMEjCPmSHFjJPT6OUAybZE0YAbpW84HmJWoXjiTwwhpALSArUZESTV1XOyWRx4eULPy QCDH7FXjFNCisFTA5nlcnrO+oVuCbc9MxkumHQNLNaE63WBhIchTh4sbnt1tP3XTZQCz 1c8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FzgS30/MMX+0Jx4p5sUe6clEIaM/1l4lpJCilBp0ADY=; b=igU+aP3ZrHKiiFfADEkwubgXnyhTNKKGsaPeReevMgGDyLcxs5evPY4BeblnXdBHKC eyfO3xTMAETp3fls3Cz/l3F9I5NtbEMHerQpCMZYNITdIwBzAriTFJM5gvC/1fIkgjNt nC4T0GwkCyFKtGBbSoPr9RmT/TrNjiedfG5b9wcT5KSWKM2UAnGgXbGMlZPz8Zuwc013 BADtd/VmJQVElPKAsVJ1NNHKgwO2P+i70CI9LTevnZ148TAu88B9WQ4rQmKqTa+i3cl5 WTm6IGji5OESD9JbrQPu+eb+lNqTfsgxbuTWbZ/08AJbEnSwScWB6MjErZOg1XBgOiCi RLuw==
X-Gm-Message-State: ANhLgQ0dAUvolzify2P2x0fPLcztQpC1/r9zqeQqYgw/cvCV9lk62gN1 MQc85uFEHa861U6mOI4hF6czLUKt6XGMqRbaH+c=
X-Google-Smtp-Source: ADFU+vs+KwQIHOsSmOzgBMHv/fWIsP5i2d78hkRkOlAEwZ3LzKSmZafZsJOMeum8zrvEQTM+WPGujDat/fZaE1XCJ3o=
X-Received: by 2002:a1f:9d16:: with SMTP id g22mr17991178vke.22.1585051065743; Tue, 24 Mar 2020 04:57:45 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tengfei Chang <>
Date: Tue, 24 Mar 2020 12:57:34 +0100
Message-ID: <>
To: Alvaro Retana <>
Cc: The IESG <>,, 6tisch <>,, Pascal Thubert <>
Content-Type: multipart/alternative; boundary="000000000000b97d7105a19875d6"
Archived-At: <>
Subject: Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Mar 2020 11:57:50 -0000

Hi Alvaro,

I replied in the following starting with " *RESPONSE *", in case ">" is not
well displayed.

On Thu, Mar 12, 2020 at 2:41 PM Alvaro Retana via Datatracker <> wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-6tisch-msf-12: 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (1) I support Roman's DISCUSS.

*RESPONSE*: yes, Roman's DISCUSS should be fixed in the next revision.

> (2) The datatracker should point at draft-chang-6tisch-msf being replaced
> by
> this document.
> (3) §2: "MSF RECOMMENDS the use of 3 slotframes."  Why isn't this
> How does an implementation signal to a neighboring node that a different
> number
> of slotframes are being used (or a different length, which is also
> later)?  It seems to me that RECOMMENDING may not be enough for an
> interoperable implementation...but I may also be missing something in
> 802.15.4
> or rfc8180 (or somewhere else).  [BTW, the rfc2119 keyword is RECOMMENDED
> (not

* RESPONSE *: In RFC8480, the 6P request is able to point out the cell is
to installed/removed on which slotframe, by specifying the slotframe ID.
There is no problem to run multiple slotframe with different length, only
the slot boundary is needed to be aligned, according to IEEE802.15.4.

> I think the use of RECOMMENDED (vs REQUIRED) may be related to this text a
> couple of paragraphs before:
>    A node implementing MSF SHOULD implement the Minimal 6TiSCH
>    Configuration [RFC8180], which defines the "minimal cell", a single
>    shared cell providing minimal connectivity between the nodes in the
>    network.  The MSF implementation provided in this specification is
>    based on the implementation of the Minimal 6TiSCH Configuration.
>    However, an implementor MAY implement MSF based on other
>    specifications as long as the specification defines a way to
>    advertise the EB/DIO among the network.
> I understand that a configuration other than rfc8180 is possible, but if
> this
> document is based on rfc8180, then it would be clearer if the language was
> stronger (s/SHOULD/MUST) with the understanding that the specification
> refers
> to that case.

* RESPONSE: *by using MUST, it will restrict MSF to RFC8180 only.
IMO, the text is able to convey the relationship between MSF and RFC8180.

> (4) §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].
> rfc8180/§6.2 says that "after having received the first EB, a node MAY
> listen
> for at most MAX_EB_DELAY seconds until it has received EBs from
> NUM_NEIGHBOURS_TO_WAIT distinct neighbors."  The use of RECOMMENDED here
> is not
> consistent with the optional nature of the MAY.

*RESPONSE *: thanks for the comment. This paragraph will be revised
according to RFC8180 to be consistent.

> (5) Nits...
> s/represents node's preferred parent/represents the node's preferred parent
> s/no restrictions to go multiple MSF sessions/no restrictions to use (?)
> multiple MSF sessions
> s/One of the algorithm met the rule/One of the algorithms that meet the
> rule
> s/Alternative behaviors may involved/Alternative behaviors may be involved
> s/when alternative security/when an alternative security
> s/node keeps listen/node keeps listening
> s/pairs of following counters/pairs of the following counters

  *RESPONSE*: Those will be reolsved in the next revision.


> _______________________________________________
> 6tisch mailing list


Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria