Re: [6tisch] Genart last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 17 January 2020 00:58 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 ABF4D1200C7; Thu, 16 Jan 2020 16:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 c6khogE3gMIb; Thu, 16 Jan 2020 16:58:53 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5664012008C; Thu, 16 Jan 2020 16:58:53 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E2C83897D; Thu, 16 Jan 2020 19:58:24 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0869ED98; Thu, 16 Jan 2020 19:58:52 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tim Evens <tievens@cisco.com>
cc: gen-art@ietf.org, last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org
In-Reply-To: <157913558775.22436.18264578512376938105@ietfa.amsl.com>
References: <157913558775.22436.18264578512376938105@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Thu, 16 Jan 2020 19:58:52 -0500
Message-ID: <5113.1579222732@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/EvvjOAmrPrD1B3TfMiRubnTcPCM>
Subject: Re: [6tisch] Genart last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
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: Fri, 17 Jan 2020 00:58:56 -0000

Tim Evens via Datatracker <noreply@ietf.org> wrote:
    > 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.

Thank you.

    > In section 1.2,
    > "These slots are rare, and with 10ms
    > slots, with a slot-frame length of 100, there may be only 1 slot/s
    > for the beacon."

    > IMO, this could be reworded to increase clarity. For example, "Considering 10ms
    > slots and a slot-frame length of 100, these slots are rare and could result in
    > only 1 slot for a beacon."

Reworded as you suggest:

 There is a limited number of timeslots designated as a broadcast slot by
 each
 -router in the network. These slots are rare, and with 10ms slots, with a
 slot-frame length of
 -100, there may be only 1 slot/s for the beacon.
 +router in the network. Considering 10ms slots and a slot-frame length of
 100,
 +these slots are rare and could result in only 1 slot/s for a broadcast,
 which
 +needs to be used for the beacon.  Additional broadcasts for Router
 +Advertisements, or Neighbor Discovery could even more scarce.

    > In section 1.3,
    > "At layer 3, [RFC4861] defines a mechanism by which nodes learn about
    > routers by listening for multicasted Router Advertisements (RA)."

    > Would it be possible to reword to not use "multicasted?"  For example,
    > "by receiving multicast Router Advertisements (RA)."

done.

    > "no RA is heard within a set time, then a Router Solicitation (RS) may
    > be multicast,"

    > "may be sent as multicast" might be more clear.

done.

    > In section 2,
    > "proxy priority  this field indicates the willingness fo the sender to
    > act as join proxy.  Lower value indicates greater willingness"

    > Typo "fo"

fixed.

    > IMO, it would be clearer if the field name in the protocol header
    > matches the description for it. For example, "Proxy priority (proxy prio)"

okay.

    > In Section 4,
    > "An interloper with a radio sniffer would be able to use the network
    > ID to map out the extend of the mesh network."

    > extend or extent?

extent, thank you catching that.

All this in -07 about to be published.



--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-