Subject: [6lo] Rtgdir last call review of draft-ietf-6lo-blemesh-08

From: Acee Lindem via Datatracker <[email-masked]>
Date: Sat, 31 Oct 2020 11:41:45 -0700

Reviewer: Acee Lindem
Review result: Has Nits

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-6lo-blemesh-08.txt
Reviewer: Acee Lindem
Review Date: October 31st, 2020
IETF LC End Date:
Intended Status: Standards Track

Summary: This document is basically ready for publication, but has nits
that should be considered prior to publication.

Comments:

The document extends the 6LoWPAN mechanisms to Bluetooth mesh network.
The document is well written and didn't and fairly easy to read given the
subject matter. Since I had not followed this standard previously, a
rudimentary understanding of RFC 7668. Additionally, familiarity with
RFC 6282 mechanisms is required to understand the header compression
extensions. My Routing Directorate review was primary from the routing
perspective.

Major Issues: None

Minor Issues: None

Nits:

   In section 3.2, it would be better to reference route-over in RFC 6775 in
   the first paragraph as it is essential to the viability of the subnet
   model.

   Define or Expand acronyms in figure 1 before using.

Editorial suggestions:

ACEE-M-3B86:Desktop acee$ diff draft-ietf-6lo-blemesh-08.txt.orig 
draft-ietf-6lo-blemesh-08.txt 153c153 <    subsequent Bluetooth versions (e.g. 
Bluetooth 4.2 [BTCorev4.2] or
---
>    subsequent Bluetooth versions (e.g.,  Bluetooth 4.2 [BTCorev4.2] or
199,202c199,202
<        -  - +-------------------------------------------------+- - - HCI
<             |               Bluetooth LE Link Layer           |
<             +-------------------------------------------------+
<             |                Bluetooth LE Physical            |
---
> Host   -  - +-------------------------------------------------+- - -
> Controllor  |               Bluetooth LE Link Layer           |
> Interface   +-------------------------------------------------+
> (HCI)       |                Bluetooth LE Physical            |
293c293
<    6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE
---
>    6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE
296c296
<    Multihop DAD functionality as defined in section 8.2 of RFC 6775 and
---
>    Multihop Dupicate Address Detection (DAD) functionality as defined in
section 8.2 of RFC 6775 and 317c317 <    (e.g. very short-lived connections) it
may not be worthwhile for a
---
>    (e.g., very short-lived connections) it may not be worthwhile for a
331c331
<    Bluetooth device address using the same compression context, the
---
>    the Bluetooth device address using the same compression context, the
342c342
<    Advertisements the Bluetooth LE hosts MUST, respectively, follow
---
>    Advertisements, the Bluetooth LE hosts MUST, respectively, follow
440c440
<    if the node is battery powered.  A router (i.e. a 6LR or a 6LBR) MUST
---
>    if the node is battery powered.  A router (i.e., a 6LR or a 6LBR) MUST
443c443
<    listeners for multicast groups the packets belong to.
---
>    listeners for multicast groups to which the multicast packets destined.

Thanks,
Acee