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
