Re: [6tisch] Genart last call review of draft-ietf-6tisch-msf-10

Tengfei Chang <tengfei.chang@gmail.com> Sat, 15 February 2020 13:35 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 C484D120071; Sat, 15 Feb 2020 05:35: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 GwK83puUPXyh; Sat, 15 Feb 2020 05:35:32 -0800 (PST)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 E01CB12001E; Sat, 15 Feb 2020 05:35:28 -0800 (PST)
Received: by mail-vs1-xe29.google.com with SMTP id n27so8019289vsa.0; Sat, 15 Feb 2020 05:35:28 -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=8VRctJ0AH7A2X5zZgb+Di+siNm7iP9JtMisRrCsTCvc=; b=hirQ6wDuCJDGodvd+cZvzHIdwTuN5QFm42YIeo7yPznrcdOUHxQ5BfCKKiaWsiVKkT zpqd8FRvcLK3Wlz/9OxOmYJ3EcjKAgPVAQrtJx7LTVTa0MljXp5Dm/RisREVvWWrNayj vuAqanbD61yWJ3bZN7x2Ed+09OyMr+PZHKuxK1Qr3gneuGONpGTnbO2aPtCu48Sk8qoU DDMnq3YZdnapdCk/p1nS1078TY+2wcClzWyRxWwSIEKxgpqkGHHMVbccFcH+Bp7/Dr/w aLf2oeud7MVZnCfpJfsdeVrpL8maW8BMZBBSaNpcfxe0UDHfVdQTXnvw1D9LQ8smewQY s/Vg==
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=8VRctJ0AH7A2X5zZgb+Di+siNm7iP9JtMisRrCsTCvc=; b=mLHLu6tsPdJ8unLoX/OuivUtYnNfLK+14BFsVJgVWtfguDY3d1Yam8TOSijmB3oadI pQAN87WV1QYtiJNFkkoPAVdV+LSvJS/gFyrCxFhFWHnuGfI4EhjZ0hIQRoRGgQmZgeTl z9xJf5sp/smYuPDLlURd0XW7yXFHk37IHRh4rYzTnh0cx+hEZEEiI8hR8zDGW/NGkvQm Rk8+Lz2UARPUt0SjuuMrt821h4/Fudseb8KLWF+1Q4q8SEGliwR1qjvkYx1DgIFYXN6U lAuAjlH/PKQpEXbh3dVxficyQficR2oZcjyuxAYeA+cHRrbAr4KSa6E63BxZVfZjJiT5 yNzg==
X-Gm-Message-State: APjAAAV16HU3acLYN/vrRC0yxasab8yZby/PAunpMA4AVAr8g2vyale1 r2BGCAkYG0tYrepKwyPkTZuHZGfhAAwnH54sdmY=
X-Google-Smtp-Source: APXvYqzzd490f47YrH14hqqDeCGuiZEUNOdSwVi7TVoJOQPJ+R6FE2OuCTnxofA0rVPJHQFUGJ/BwxbZot70/YqA6hI=
X-Received: by 2002:a67:ad0c:: with SMTP id t12mr3923607vsl.232.1581773727791; Sat, 15 Feb 2020 05:35:27 -0800 (PST)
MIME-Version: 1.0
References: <158169855672.16297.13529972066012125176@ietfa.amsl.com>
In-Reply-To: <158169855672.16297.13529972066012125176@ietfa.amsl.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Sat, 15 Feb 2020 14:35:16 +0100
Message-ID: <CAAdgstRnfyspPz9zcwya1zOrrj+kN1Y+TwKdwkyVfFKuUeHRfQ@mail.gmail.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>
Cc: gen-art@ietf.org, draft-ietf-6tisch-msf.all@ietf.org, last-call@ietf.org, 6tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000028fe4e059e9d654f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/hzYvZZd0ljsCoK9jZQTXRaK55TU>
Subject: Re: [6tisch] Genart last call review of draft-ietf-6tisch-msf-10
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: Sat, 15 Feb 2020 13:35:35 -0000

H Vijay,

Thanks a lot for the review!

For the major comment, what we want to explain here is that there are
multiple way to limit traffic to lighten the collisions.
Trickle timer is one of those algorithm for that purpose.
What "*This behavior is out of the scope for MSF*." means here actually is
that we don't want to limit the various ways of limiting traffic by just
using Trickle timer.
The implementer can  design their own algorithm to mitigate the traffic
collisions on minimal cell.

The paragraph is rephrased as following:

*To ensure there is enough bandwidth available on the minimal cell, a node
implementing MSF SHOULD enforce some rules for limiting the traffic of
broadcast frames. *
*For example, the overall broadcast traffic among the node and its
neighbors **SHOULD NOT exceed 1/3 of the bandwidth of minimal cell.*
*One of the algorithm met the rule is the Trickle timer defined in
[RFC6206] which is applied on DIO messages [RFC6550]. *
*The algorithm of limiting the broadcast traffic to meet those rules is
implementation-specific and is out of the scope of MSF.*

Does this version sound clear for you?

Tengfei



On Fri, Feb 14, 2020 at 5:43 PM Vijay Gurbani via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Vijay Gurbani
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-6tisch-msf-10
> Reviewer: Vijay K. Gurbani
> Review Date: 2020-02-14
> IETF LC End Date: 2020-02-27
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The draft is almost ready to be published as a Proposed Standard.
>
> Major issues: 1
>
> Minor issues: 0
>
> Nits/editorial comments: 1
>
> Sn below stands for "Section n".
>
> Major:
>
> - S2, paragraph 4: The text says that "...a node implementing MSF SHOULD
> enforce
>   some rules for limiting the traffic broadcast frames...".  It goes ahead
> and
>   gives an example of the "Trickle" operation, but in the very next
> sentence, it
>   says, "This behavior is out of the scope for MSF."  I am confused since
> the
>   paragraph does not seem self consistent.
>
>   The paragraph is asking the implementor to use normative strength
> (SHOULD) to
>   enforce "some" rules, but does not enumerate the rules.  To be fair, the
>   paragraph gives one example of such a rule, but immediately invalidates
> that
>   example!  What would an implementor do?  Where would he or she go to get
> an
>   idea of "some" rules that can be used to limit the traffic of broadcast
>   frames? Perhaps some reference could be provided to a document that
> contains
>   these rules?
>
> Nits:
>
>  - S6: s/It is calculated/The timeout value is calculated/
>
> Thank you.
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————