Hi Carles,
The changes look good to me. Note that since my comments were nits, I had already marked the review completed.
Thanks,
Acee
On 12/8/20, 3:27 AM, "Carles Gomez Montenegro" <carlesgo@xxxxxxxxxxxxx> wrote:
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
> 6lo@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/6lo
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
