Brian, all, We have discussed the possible resolutions to your comments with Xavi. I have captured those in a slideset [1] to be presented at this Friday's interim meeting [2].
Early comments about the discussions and proposed resoltuion in the slideset, in preparation for their presentation on Friday, welcome. Thomas [1] https://bitbucket.org/6tisch/meetings/src/master/170106_webex/slides_170106_webex_b_minimal_brian.ppt?fileviewer=file-view-default [2] https://www.ietf.org/mail-archive/web/6tisch/current/msg05106.html On Wed, Jan 4, 2017 at 1:38 PM, Thomas Watteyne <thomas.watte...@inria.fr> wrote: > 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 > _______________________________________ > -- _______________________________________ 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
