Subject: [6tisch] answers Brian comments for minimal

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 20 Jan 2017 13:18:14 +0100

Dear Brian,

find below our answers to your comments. They have been included to v18 of
the draft recently published.
-------------------

1) MAJOR COMMENT 1

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.

RESOLUTIONS

Introduction and abstract have been changed to clarify this point.

NEW abstract
   This document describes a minimal mode of operation for a 6TiSCH
   Network.  A minimal mode of operation is a baseline set of protocols,
   recommended configurations and modes of operation sufficient to
   enable a 6TiSCH functional network.  6TiSCH provides IPv6
   connectivity over a Time Synchronized Channel Hopping (TSCH) mesh
   composed of IEEE Std 802.15.4 TSCH links.  This minimal mode uses a
   collection of protocols with the respective configurations, including
   the 6LoWPAN framework, enabling interoperable IPv6 connectivity over
   IEEE Std 802.15.4 TSCH.  This minimal configuration provides the
   necessary bandwidth for network and security bootstrap and defines
   the proper link between the IETF protocols that interface to the IEEE
   Std 802.15.4 TSCH.  This minimal mode of operation should be
   implemented by all 6TiSCH compliant devices.

NEW Introduction

 A 6TiSCH Network provides IPv6 connectivity [RFC2460] over a Time
   Synchronized Channel Hopping (TSCH) mesh [RFC7554] composed of IEEE
   Std 802.15.4 TSCH links [IEEE802154-2015].  IPv6 connectivity is
   obtained by the use of the 6LoWPAN framework ([RFC4944], [RFC6282],
   [RFC8025],[I-D.ietf-6lo-routing-dispatch] and [RFC6775]), RPL
   [RFC6550], and its Objective Function 0 (OF0) [RFC6552].

   This specification defines operational parameters and procedures for
   a minimal mode of operation to build a 6TiSCH Network.  Any 6TiSCH
   complaint device SHOULD implement this mode of operation.  This
   operational parameters configuration provides the necessary bandwidth
   for nodes to bootstrap the network.  The bootstrap process includes
   initial network configuration and security bootstrap.  In this
   specification, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL
   [RFC6550], and its Objective Function 0 (OF0) [RFC6552], are used
   unmodified.  Parameters and particular operations of TSCH are
   specified to guarantee interoperability between nodes in a 6TiSCH
   Network.  RPL is specified to provide the framework for time
   synchronization in an 802.15.4 TSCH network.  The specifics for
   interoperable interaction between RPL and TSCH are described.

   In a 6TiSCH network, nodes follow a communication schedule as per
   802.15.4 TSCH.  In it, nodes learn the schedule of the network when
   joining.  When following this specification, the learned schedule is
   the same for all nodes and does not change over time.  Future
   specifications may define mechanisms for dynamically managing the
   communication schedule.  Dynamic scheduling solutions are out of
   scope of this document.

   IPv6 addressing and compression are achieved by the 6LoWPAN
   framework.  The framework includes [RFC4944], [RFC6282], [RFC8025],
   the 6LoWPAN Routing Header dispatch [I-D.ietf-6lo-routing-dispatch]
   for addressing and header compression, and [RFC6775] for duplicate
   address detection (DAD) and address resolution.

   More advanced work is expected in the future to complement the
   Minimal Configuration with dynamic operations that can adapt the
   schedule to the needs of the traffic at run time.

2)MAJOR COMMENT 2

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/.

RESOLUTION

NEW abstract
   This document describes a minimal mode of operation for a 6TiSCH
   Network.  A minimal mode of operation is a baseline set of protocols,
   recommended configurations and modes of operation sufficient to
   enable a 6TiSCH functional network.  6TiSCH provides IPv6
   connectivity over a Time Synchronized Channel Hopping (TSCH) mesh
   composed of IEEE Std 802.15.4 TSCH links.  This minimal mode uses a
   collection of protocols with the respective configurations, including
   the 6LoWPAN framework, enabling interoperable IPv6 connectivity over
   IEEE Std 802.15.4 TSCH.  This minimal configuration provides the
   necessary bandwidth for network and security bootstrap as well as
   define the proper link between the IETF protocols that interface the
   IEEE Std 802.15.4 TSCH.  This minimal mode of operation should be
   implemented by all 6TiSCH compliant devices.

3) MAJOR COMMENT 3

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).

RESOLUTION
Added Security Considerations Section. (See document as it is long).

4) MINOR COMMENT 1

> 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"?

DISCUSSION

This comment doesn’t really apply. tsTxAckDelay is measured from the end of
the data packet until the beginning of the ACK. Per Table 8-145 in
IEEE802.15.4-2015, 1000 us. Even if the drift is 100ppm, the error would be
100ns. The max error allowed macTsAckWait is 400us.
That discussion does not belong in an IETF document, it’s IEEE world

RESOLUTION

Suggestion: drop the word “exactly”

OLD
   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
NEW
The RX node sends the first bit after the SFD of the MAC acknowledgment
tsTxAckDelay after the end of the last byte of the received packet.

5)MINOR COMMENT 2

> 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?

DISCUSSION

The title of the section is unclear.
IEEE802.15.4-2015 defines the format of frames. Through a set of flags,
IEEE802.15.4-2015 allows for several fields to be present or not, to have
different lengths and different values. This specification details the
RECOMMENDED contents of the IEEE802.15.4 frame, while strictly complying to
IEEE802.15.4-2015.

RESOLUTION

OLD
   Frame Format
   The following sections detail the RECOMMENDED format of link-layer
   frames of different types.  A node MAY use a different formats (bit
   settings, etc), but MUST implement IEEE802.15.4 TSCH correctly.  As
   long as an implementation follows IEEE802.15.4 TSCH correctly, it is
   compliant to this specification.
NEW
Frame Contents
<xref target="IEEE802154-2015"/> defines the format of frames.
Through a set of flags, <xref target="IEEE802154-2015"/> allows for several
fields to be present or not, to have different lengths, and to have
different values.
This specification details the RECOMMENDED contents of IEEE802.15.4 frames,
while strictly complying to <xref target="IEEE802154-2015"/>.

6)MINOR COMMENT 3

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?

DISCUSSION

Again, this is an IEEE discussion which we don’t want to start at the IETF
The IEEE header allows for some addresses to be omitted, so in some cases
it could make sense to omit some addresses
We are NOT redefining any of that, and the IETF spec is not the right
location to have those discussions (as highlighted by Brian’s remark)

RESOLUTION

Suggestion: drop the discussion from this spec

OLD
   The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames
   SHOULD include the Source Address field and the Destination Address
   field.  The Frame Version field SHOULD be set to 0b10 (Frame Version
   2).  The IEEE802.15.4 header SHOULD include Source Address field and
   the Destination Address field.  The Sequence Number field MAY be
   elided.
NEW
The Frame Version field SHOULD be set to 0b10 (Frame Version 2).
The Sequence Number field MAY be elided.

7)MINOR COMMENT 4

> 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?

DISCUSSION

See comments to Tero.

The current texts reads as follow:
   The value
   36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 38 ("6TiSCH minimal18")
   is RECOMMENDED for PI, but a network operator MAY change it for
   administrative and segregation reasons.

8) NITS 1

> 1.  Introduction
>
>   A 6TiSCH Network provides IPv6 connectivity...

I would expect to see a reference to [RFC2460] right there.

RESOLUTION

citation to [RFC2460] has been added.

9)NITS 2

Outdated reference: draft-ietf-6lo-paging-dispatch has been published
as RFC 8025.

RESOLUTION

The reference has been updated.

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain