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

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Thu, 21 March 2019 15:25 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 2F47D1311EE for <6tisch@ietfa.amsl.com>; Thu, 21 Mar 2019 08:25:11 -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 q-W-e4Ny8dGm for <6tisch@ietfa.amsl.com>; Thu, 21 Mar 2019 08:25:09 -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 B9B981311DB for <6tisch@ietf.org>; 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 wifi-pro-82-014.paris.inria.fr (HELO [128.93.82.14]) ([128.93.82.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 21 Mar 2019 16:25:06 +0100
Cc: yasuyuki.tanaka@inria.fr, 6tisch@ietf.org
To: Tengfei Chang <tengfei.chang@gmail.com>
References: <CAAdgstS-O33+0yVH4Aahknope74GeVZpyqwzp=f-P7QRcGctbw@mail.gmail.com> <c1fed393-6355-1ed8-0611-86719aab8dd0@inria.fr> <CAAdgstQggMW7i5We81YNm0M+NaJ=s2v0ZNZVagzU9+ppYr_Avg@mail.gmail.com>
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Message-ID: <11746723-9851-86a5-b927-9bfb6e722355@inria.fr>
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: <CAAdgstQggMW7i5We81YNm0M+NaJ=s2v0ZNZVagzU9+ppYr_Avg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/Sb2jvCtOFmc7IDXV5kei7pOg9vY>
Subject: Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published
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: 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]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5

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]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-9

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]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.5

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
respectively:

 
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6

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

Best,
Yatch