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

[Brian Carpenter <[e-mail]>]

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