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

[Carles Gomez Montenegro <[e-mail]>]

Hi Acee,

Sorry for the late reply, and thanks a lot for your review of the draft!

We just submitted -09, which aims at addressing the last round of review
comments, including yours:
https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09

We believe that we incorporated your points below into the document.

Should you have further comments, please do not hesitate to let us know.

Cheers,

Carles (on behalf of the authors)



> 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
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>