Last Call Review of draft-ietf-6tisch-minimal-17
review-ietf-6tisch-minimal-17-genart-lc-carpenter-2016-12-10-00

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