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

Tim Evens via Datatracker <noreply@ietf.org> Thu, 16 January 2020 00:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB52C120807; Wed, 15 Jan 2020 16:46:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tim Evens via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Tim Evens <tievens@cisco.com>
Message-ID: <157913558775.22436.18264578512376938105@ietfa.amsl.com>
Date: Wed, 15 Jan 2020 16:46:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/ZoF6zaCEku66HO_w4ShIXrRUpEk>
Subject: [6tisch] Genart last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
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, 16 Jan 2020 00:46:28 -0000

Reviewer: Tim Evens
Review result: Ready with Nits

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-enrollment-enhanced-beacon-??
Reviewer: Tim Evens
Review Date: 2020-01-15
IETF LC End Date: 2020-01-22
IESG Telechat date: Not scheduled for a telechat

Summary:
Overall looks good with some minor nits.

Major issues:
None

Minor issues:
None

Nits/editorial comments:

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."

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)."

"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.

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"

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


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?