Re: [Gen-art] Review of draft-ietf-6tisch-minimal-17

[Thomas Watteyne <[e-mail]>]

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 <
[e-mail]> 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
_______________________________________