Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

Yasuyuki Tanaka <> Thu, 21 March 2019 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F47D1311EE for <>; Thu, 21 Mar 2019 08:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q-W-e4Ny8dGm for <>; Thu, 21 Mar 2019 08:25:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9B981311DB for <>; Thu, 21 Mar 2019 08:25:08 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,253,1549926000"; d="scan'208";a="375128244"
Received: from (HELO []) ([]) by with ESMTP/TLS/AES128-SHA; 21 Mar 2019 16:25:06 +0100
To: Tengfei Chang <>
References: <> <> <>
From: Yasuyuki Tanaka <>
Message-ID: <>
Date: Thu, 21 Mar 2019 16:25:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
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] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published
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: Thu, 21 Mar 2019 15:25:11 -0000

Thank you, Tengfei.

Additional and following-up comments:

[Section 5.1, what to do after timeout of a 6P transaction]

The draft does not say anything about how to handle timeout of a 6P
transaction. I know, the initiator of the timed out transaction will
resend a 6P request to the same peer ;-) But, it's better to mention
that as well as the maximum number of retries if we have.

[Section 9, 6P Timeout Value]

A couple of questions:

- "C" includes the autonomous cell to the neighbor or it is the number
   of the managed cells?
- How can the timeout value be calculated while PDR is not available?

[Section 4.5, Step 4 of the bootstrap process]

tengfei> I don't know whether there is a specification for how the
tengfei> neighbor table should be managed. If no, I think PERSONALLY
tengfei> it's better not keeping the address from pledge in neighbor
tengfei> table.

Although the actual way to manage neighbor information is
implementation-dependent, the minimal security framework draft
suggests to have separate memory for joined nodes and for pledges

Again, my comment on Section 4.5 is just that, I think we need some
text in "Security Considerations" section for this operation described
in Step 4. And, it seems the term of "the neighbor table" in the Step
4 is ambiguous. Some may think it's IPv6 neighbor cache, some may
think L2 neighbor table.

[Appendix-B, SAX configuration]

tengfei> This is a pre-configured (offline) for interoperability
tengfei> purpose only.

It's better to mention how a pledge gets the SAX parameters used in
the network where it is trying to join. There are always two options:

- pre-configured
- advertised in EBs