Brian, Just a quick admin update that the authors have taken your comments into account, which will be integrated in -18. We will discuss the proposed resolutions at an interim meeting this Friday and publish it next week. Thomas
On Sat, Dec 10, 2016 at 11:39 PM, Brian Carpenter < brian.e.carpen...@gmail.com> wrote: > Reviewer: Brian Carpenter > Review result: Almost Ready > > Gen-ART Last Call review of draft-ietf-6tisch-minimal-17 > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-6tisch-minimal-17.txt > Reviewer: Brian Carpenter > Review Date: 2016-12-11 > IETF LC End Date: 2016-12-20 > IESG Telechat date: 2017-01-05 > > Summary: Almost Ready > -------- > > Comment: > -------- > > Although I found some issues, this is a good document which is mainly > very clear. I was not in a position to check IEEE802.15.4 details. > > It's too late now, but judging by the shepherd's writeup, this draft > would have been an excellent candidate for an Implementation Status > section under RFC 6982. > > Major Issues: > ------------- > > I was very confused for several pages until I went back and read this > again: > > > This specification defines operational parameters and procedures > for > > a minimal mode of operation to build a 6TiSCH Network. The > 802.15.4 > > TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective > > Function 0 (OF0) [RFC6552], are used unmodified. > > Then I realised that there is some very basic information missing at > the beginning > of the Introduction. That little phrase "the 6LoWPAN framework" seems > to be the clue. > What is the 6LoWPAN framework? Which RFCs? I'm guessing it would be > RFC4944, RFC6282 > and RFC6775, but maybe not. In any case, the very first sentence of > the Introduction > really needs to be a short paragraph that explains in outline, with > citations, how a > 6TiSCH network provides IPv6 connectivity over NBMA. With that, the > rest of the document > makes sense. > > But related to that, the Abstract is confusing in the same way: > > > Abstract > > > > This document describes a minimal mode of operation for a 6TiSCH > > Network. It provides IPv6 connectivity over a Non-Broadcast > Multi- > > Access (NBMA) mesh... > > "It" is confusing since it seems to refer to this document, which > hardly > mentions IPv6 connectivity. I suggest s/It/6TiSCH/. > > As far as I know a Security Considerations section is still always > required. I understand > that this document discusses security in detail, but that doesn't > cancel the > requirement (https://tools.ietf.org/html/rfc3552#section-5). > > Minor issues: > ------------- > > > 4.4. Timeslot Timing > ... > > The RX node needs to send the first bit after the > > SFD of the MAC acknowledgment exactly tsTxAckDelay after the end > of > > the last byte of the received packet. > > I don't understand "exactly". Nothing is exact - there is always clock > jitter. > Shouldn't there be a stated tolerance rather than "exactly"? > > > 4.5. Frame Formats > > > > The following sections detail the RECOMMENDED format of link-layer > > frames of different types. A node MAY use a different formats > (bit > > settings, etc)... > > Doesn't this create an interoperability issue for independent > implementations? > How can you mix and match implementations that use variants of the > frame format? > This seems particularly strange: > > > The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames > > SHOULD include the Source Address field and the Destination > Address > > field. > > How will it work if some nodes omit the addresses? > > > 4.6. Link-Layer Security > ... > > For early interoperability testing, value 36 54 69 53 43 48 20 6D > 69 > > 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1. > > Shouldn't this also say that this value MUST NOT be used in > operational networks? > > Nits: > ----- > > > 1. Introduction > > > > A 6TiSCH Network provides IPv6 connectivity... > > I would expect to see a reference to [RFC2460] right there. > > Outdated reference: draft-ietf-6lo-paging-dispatch has been published > as RFC 8025 > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
