Last Call Review of draft-ietf-6lo-blemesh-08
review-ietf-6lo-blemesh-08-rtgdir-lc-lindem-2020-10-31-00

Request Review of draft-ietf-6lo-blemesh
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2020-10-31
Requested 2020-10-08
Requested by Alvaro Retana
Authors Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk
Draft last updated 2020-10-31
Completed reviews Rtgdir Last Call review of -08 by Acee Lindem (diff)
Secdir Last Call review of -08 by Catherine Meadows (diff)
Genart Last Call review of -08 by Pete Resnick (diff)
Iotdir Last Call review of -08 by Dominique Barthel (diff)
Comments
Even though the document says that it doesn't specify the routing protocol to be used, we should consider whether a routing protocol can run over it.  Specifically, from the point of view of RPL.
Assignment Reviewer Acee Lindem 
State Completed
Review review-ietf-6lo-blemesh-08-rtgdir-lc-lindem-2020-10-31
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/RX3ebaNVRepaFEn8d85zGJ9V2bE
Reviewed rev. 08 (document currently at 09)
Review result Has Nits
Review completed: 2020-10-31

Review
review-ietf-6lo-blemesh-08-rtgdir-lc-lindem-2020-10-31

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