Re: [6tisch] MSF Shepherd review
Tengfei Chang <tengfei.chang@gmail.com> Wed, 27 November 2019 20:44 UTC
Return-Path: <tengfei.chang@gmail.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 1C23E120988; Wed, 27 Nov 2019 12:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cP9hlPSz92Ap; Wed, 27 Nov 2019 12:44:30 -0800 (PST)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A362712007C; Wed, 27 Nov 2019 12:44:27 -0800 (PST)
Received: by mail-pf1-x42e.google.com with SMTP id h14so1538407pfe.10; Wed, 27 Nov 2019 12:44:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+RKAlmfWaJrKyoCwSdadnJOCzUlFfjTv8wO0fhyoUyA=; b=kBGsyNue9AuDxnYKntpN9MYFGG7vLxPtljn4WlcQYpnsw4aBz2CKF9DZC3shhhrzy0 Y/qAYJoxeczLeIWPlHxtGXfluwz6Sn/sSyWuwfZoQ4T/4l/2E3Z0Iuue/dLo25rL8R3/ lvHAIxvHH+gg8IRmOwFXdj7UW9XsJmQqIAR1JvqjSoe3QYOycdsTuLEVXTdDgjMDgCe2 Xo0PKBBrVZlyluyUJ3pEm9q6hWP8M5WHDKdolc7/MQxxjImEB7rhc2k4yk/tLGJ6NZOe /8+70u916qRzZ8DmheQuQcJ2PCP/O3M0t+x/iRBvNeUDzBZcKqkE22sY15XUMwYek2gG WbJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+RKAlmfWaJrKyoCwSdadnJOCzUlFfjTv8wO0fhyoUyA=; b=Bu1oOJfnEmvNoPywPA4I+w4TKmJD3hNEdArdpOYKZYq8/m3oRrHYAu3YPJ61l0Lx9+ HRde6dmJqD57m1KPyjt0CcEkMr8IvmjYNr00G3DVWRzqJG4ZUKSVF8jAKW+5TIbEIjrk RrHkqpIDFEDc6olS9WIixTF3DWPd3JJbLoCOrk91zceBNuBfbWwOxs6ZaK9KfeoZTpKW kgkv/eDMdrcYu9b+4mVGq0fikCFENx5eddxRT3x1+x489JJIBf63tSl+GRstFJdhbsnn xdOnJrGx0i4a0swg5bqoV6d4+MVFx7TsBP+knYo0o1usv3/dMY1c0uECdAGBUxuIe38p O6+A==
X-Gm-Message-State: APjAAAWCX0rW5tJsQl6uMYZRsjnWrNx/Ue08ZwL52NleR4N7FTnzDmwK xPYEYyY7gG1n1cVrX4o++411EuugO5Eewl11j3o=
X-Google-Smtp-Source: APXvYqxYqqgvNQnzFpxW52uQcG+uiAW6sGV8shGHMGpPKFju/Nvau7ju2ea314lAo+1oFSJqN3WJ0RbyMHkirOH1zWA=
X-Received: by 2002:aa7:96e2:: with SMTP id i2mr48756116pfq.256.1574887466968; Wed, 27 Nov 2019 12:44:26 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB3565642A73EC6629FA68137DD84A0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565642A73EC6629FA68137DD84A0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Wed, 27 Nov 2019 21:44:13 +0100
Message-ID: <CAAdgstRhP2aOfekS5swmXPbD1rwnR-bAAm9ToBQnwmv77KCSEw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "draft-ietf-6tisch-msf@ietf.org" <draft-ietf-6tisch-msf@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000007ab9105985a107f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/g9jlIP4fVnF5nlSj0RBM10-ckSE>
Subject: Re: [6tisch] MSF Shepherd review
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, 27 Nov 2019 20:44:34 -0000
Thanks a lot for the reviewing, I responded inline: On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Dear all > > > > Please find some comments below: > > > > > > > > > > Please migrate to XML2RFC v3. This will save time in the future. > TC: got it! Will used in version 9. > > > > > > > However, an implementor MAY implement MSF without implementing > > Minimal 6TiSCH Configuration. > > > > > > This is not helpful without explanations. What is the tradeoff? How does > the network operates in that case? > TC: Yes, the sentence is misleading. What we try to say is MSF can work with other specifications protocols, rather then minimal 6TiSCH configuration, as long as the protocols gives a way to communicate the EB and DIO among the network. > > > > > > > > > For example, a Trickle Timer defined in > > [RFC6550 <https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. However, this behavior is > > implementation-specific which is out of the scope of MSF. > > > > > > This is not for this spec to define. RPL already mandates trickle. > Suggestion: > > > > For example, the Trickle operation defined in [RFC6206] > > is applied on DIO Messages [RFC6550 <https://tools.ietf.org/html/rfc6550>]. This behavior is > > out of the scope of MSF. > > > > TC: agreed! > > > > > > > > > MSF RECOMMENDS the use of 3 slotframes. > > > > Discussion on slotframes and cells comes without an introduction to TSCH. > > I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH > architecture section 4.3.5. to introduce those concepts. > > They should probably be normative references. > TC: I added the following text at beginning of 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 TSCH schedule instructs a node what to do at each time slots, such as transmit, receive or sleep <xref target="RFC7554"/>. In case of a slot to transmit or receive, a channel is assigned to the time slot. The tuple (slot, channel) is indicated as a cell of TSCH schedule. MSF is one of the policies defining how to manage the TSCH schedule. > > > > > > > > > Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author > SHOULD explain the alternate, what if the SHOULD is not followed. > > Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD > use minimal is less obvious. Please consider adding text after the SHOULDs. > TC: agreed! I have resolved this SHOULD issues in a new version. either the unnecessaries are removed or alternative explanation is added > > > > > > > field it contains, the presence and contents of the IE defined in > > [I-D.richardson-6tisch-join-enhanced-beacon <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>], or the key used to > > authenticate it. > > > > The reference is now draft-ietf.. I agree that it should be normative; no > worries the draft is already submitted for publication. > > More important: Please move the reference to > 6tisch-dtsecurity-zerotouch-join to informational. This is a DOWNREF today > and your draft may be stuck in MISSREF in the future. > TC: I have updated *richardson-6tisch-join-enhanced-beacon* to * ietf-6tisch-enrollment-enhanced-beacon.* I didn't get it how "*move the reference to 6tisch-dtsecurity-zerotouch-join to informational*" is done in the draft? > > > > > > After selected a preferred parent, the joined node MUST generate a 6P > > > > Grammar: “After selecting” or “once it has selected” sound better. > > > TC: the latter sounds better! Thanks! > > > > > Section Section 8 <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#section-8> > > > > The <xref …> already generates the word “section”. If you write it too, it > becomes duplicated as above. > TC: agreed! > > > > > > > For a node, this translates into > > monitoring the current usage of the cells it has to its preferred > > parent: > > > > This is disturbing. MSF should not be used only with preferred parents. > The whole game of doing a DODAG is to have and possibly use multiple > parents. > > A node can for instance send a NSM DAO with multiple transit options to > the root. Also, it could be good to clarify that the child manages both > directions. > > Proposal: > > > > For a node, this translates into > > monitoring the current usage of the cells it has to the parents it uses > > at this point of time for sending and receiving traffic: > > > > Later there a numerous references to “preferred parent” => I’d suggest you > use just “selected parent” or “active parent” or something in that vein. > TC: I think "preferred parent" is same with "selected parent". it indicates one preferred parent out of multiple. Isn't it right? > > > > > > Cell installed at initial > > > > Not sure this is correct. Maybe “at init time” > TC: Applied! > > > > > > > > > It is recommended to set MAX_NUMCELLS value at > > least 4 times than the maximum link traffic load of the network in > > packets per slotframe. > > > > > > This does not parse. Can you please rephrase? > TC: it's rephrased as "*It is recommended to set MAX_NUMCELLS value at least 4x of the maximum link traffic load of the network with unit of packets per slotframe*." > > > > > > > > > Section 8 does not try to avoid collisions with autocells. But it’s easy > to compute the slot offset of autocells for self and parent and avoids > those. Why not do that? > TC: agreed! Will apply in the next version. > > > > > > > Section 16 will require more attention, either now or during secdir > review, probably both. You should start now. Think, say, what if an > attacker claims many cells to all its neighbors? Can it attack someone’s > autocells to block him? > TC: That's a good question! It may have a chance to do so. We need discuss internally on this section. Thanks for belling ahead! > > > > > > > Voila! > > > > Pascal as shepherd. > > > > > > > > > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tchang.org/ ——————————————————————————————————————
- [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Yasuyuki Tanaka
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Prof. Diego Dujovne
- Re: [6tisch] MSF Shepherd review Yasuyuki Tanaka
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Yasuyuki Tanaka
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang