Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration
draft-ietf-6tisch-minimal-21

[Ballot comment]
While reading, I frowned upon the same MAY & RPL issue as mentioned by Alvaro:
The Introduction mentions that "RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network.", but Section 5 (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used."

[Ballot comment]
- Substantive Comments

-- Section 4, 2nd paragraph, "A node MAY use different values": Is that intended to weaken the RECOMMENDED in the previous sentence? (If not, then is the MAY needed at all?)

-- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you articulate why it might be reasonable to make other choices?

-- 4.5.2, 3rd paragraph, "It MAY be necessary..."
That seems like a statement of fact. Please consider non-2119 language.

--- 4th paragraph: It's not clear to me if the MUST in "MUST be sent as per the 802.15.4 specification..." is constraining options from that specification, or just referring to requirements that exists in that specification. If the latter, please consider descriptive rather than normative language. (e.g. "The 802.15.4 specification requires...."

-- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make sense not to follow those rules?


- Editorial Comments

-- Abstract: Please expand 6TICH on first mention

[Ballot comment]


- Figure 5: Don't you need to specify units?

- section 8: I see no point whatsoever in saying "Details are
out of scope, but the link layer must provide some
flexibility here." What is an implementer supposed to do with
that?

- section 8: You ought add a reference to the spec that
explains how a JN that doesn't know K1 or K2 still fails the
joining process for a fake EB.

- section 8: "MUST be avoided" is bogus, you ought rephrase
that with a MUST NOT I think (or a SHOULD NOT maybe if
combined with the exception in the next sentence).

[Ballot discuss]
Thanks for responding to the SecDir review, it looks like the updates needed are planned for the next version.  There were a number of significant findings, so this placeholder is to make sure those happen (protocol and security).

https://www.ietf.org/mail-archive/web/secdir/current/msg07162.html

For some reason, the SecDir review isn't linked off of the document.

[Ballot discuss]
I agree with Mirja's comments about the use of Normative Language and believe that for a BCP document its use is not clear enough such that it could result in different "compliant" implementations that may not interoperate properly.  So I am making the issue a DISCUSS.

As Mirja mentioned, this statement in the Introduction opens the door for other configurations: "Any 6TiSCH compliant device SHOULD implement this mode of operation."  The question to answer for this "SHOULD" (and others) is what are the particular circumstances when ignoring this recommendation is ok.  The document doesn't elaborate at all on details.

I understand that there are in fact other posible configurations, but if this document is describing the Best Current Practice then I think it should be explicit as to what that BCP is.

Another example of the lack of clarity (besides those already mentioned by Mirja) is the use of RPL:  The Introduction mentions that "RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network.", but Section 5 (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used."

[Ballot comment]
A couple of comments mostly on the use of normative language:

1) The following sentence contradict a little all other normative language in this document (basically making everything a SHOULD):
"Any 6TiSCH compliant device SHOULD implement this mode of operation."
Why is this a upper case SHOULD? Is this sentence needed at all?

2) Here the usage of normative language is also not clear to me:
"The default values of the TSCH Timeslot template (defined in
  [IEEE802154-2015]  section 8.4.2.2.3) and Channel Hopping sequence
  (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used.  A node
  MAY use different values by properly announcing them in its Enhanced
  Beacon."

3) Is it correct that these are SHOULDs?
"EB Destination Address field SHOULD be set to 0xFFFF (short broadcast
  address).  The EB Source Address field SHOULD be set as the node's
  short address if this is supported.  Otherwise the long address
  SHOULD be used."

4) What the recommended value for EB_PERIOD?:
"In a minimal TSCH
  configuration, a node SHOULD send an EB every EB_PERIOD."

5) This is also a weird SHOULD for me:
"EBs SHOULD be used to obtain information about local networks, ..."
What else should be used? Or you just don't obtain the information you need. I actually guess that you should simply use a lower case should in this sentence.
Should it be?:
"The default values of the TSCH Timeslot template (defined in
  [IEEE802154-2015]  section 8.4.2.2.3) and Channel Hopping sequence
  (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used.  If a node
  uses different values, it MUST properly announcing them in its Enhanced
  Beacon."
Or is this sentence just duplicating the SHOULD of the previous sentence slightly differently?

6) Maybe also name the recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to section 7.3?

7) "At any time, a node MUST maintain connectivity to at least one time
  source neighbor. "
  How can you ensure that you can maintain connectivity? I guess this must be a SHOULD... or what do you mean exactly by 'maintain connectivity'?

8) I think this sentence is confusing given the recommended value for NUM_UPPERLAYER_PACKETS is 1:
"One entry in the queue is reserved at all times for frames of type BEACON."
I guess what you want to say it that if a BEACON should be send and there is no space in the queue one frame should be drop and the BEACON should be queued instead?

9) I'm a little surprised to not see anything about 6LoWPAN in the body of the document (besides the intro in section 1). Shouldn't there also be some normative language on the use of 6LoWPAN?

One editorial comment (from the abstract):
I don't really understand this sentence
"A minimal mode of operation is a baseline set of protocols, ..."
I guess you want to say something like
"This minimal mode of operation specifies the baseline set of protocols that need to be supported, .."

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-6tisch-minimal-17.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-6tisch-minimal@ietf.org, 6tisch@ietf.org, pthubert@cisco.com, 6tisch-chairs@ietf.org, suresh.krishnan@ericsson.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Minimal 6TiSCH Configuration) to Best Current Practice


The IESG has received a request from the IPv6 over the TSCH mode of IEEE
802.15.4e WG (6tisch) to consider the following document:
- 'Minimal 6TiSCH Configuration'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 composed of IEEE802.15.4 Timeslotted Channel
  Hopping (TSCH) links.  This minimal mode uses a collection of
  protocols including the 6LoWPAN framework to enable interoperable
  IPv6 connectivity over IEEE802.15.4 TSCH with minimal network
  configuration and infrastructure.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6719: The Minimum Rank with Hysteresis Objective Function (Proposed Standard - IETF stream)
    rfc6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks (Proposed Standard - IETF stream)
    rfc8025: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch (Proposed Standard - IETF stream)
    rfc6553: The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams (Proposed Standard - IETF stream)
    rfc2460: Internet Protocol, Version 6 (IPv6) Specification (Draft Standard - IETF stream)
    draft-ietf-6lo-routing-dispatch: 6LoWPAN Routing Header (None - IETF stream)
    rfc6206: The Trickle Algorithm (Proposed Standard - IETF stream)
    rfc6554: An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) (Proposed Standard - IETF stream)
    rfc6552: Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (Proposed Standard - IETF stream)
    rfc6551: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (Proposed Standard - IETF stream)
    rfc6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (Proposed Standard - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

> Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

  This document describes the minimal set of rules to run IPv6 over
  an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network,
  including the operation of the RPL routing protocol and the
  procedures to forward packets using a static schedule of shared
  time slots in a slotted-aloha fashion.

Working Group Summary

  Like for the other 6TiSCH documents, it took a long time and great
  care to achieve consensus on the security piece. Considering the
  complexity (and issues) in IEEE802.15.4-2011, the group decided
  to provide reference examples of how the MAC can be set in order to
  achieve interoperability.

  Though MAC level messages are widely discussed and many references
  to undated IEEE802.15.4 specs are made, and apart from a particular
  problem with the IEEE802.15.4e spec that has to be treated in
  section 4, the example section 11 is the only place in the document that
  has dated IEEE references.
 
The rest of the document uses undated references so it is preserved
  through future backward compatible updates of IEEE802.15.4.

  The draft was the subject to an ETSI PlugTest and the Hackathon in Prague.
  4 different implementation on multiple platforms and OSes were tested
  (more below).

  Version 12 of the draft reflects the corrections that we made to fix all the issues.

Document Quality

  There are 3 different open source implementations, Contiki, TinyOS
  and Open WSN. Multiple derivatives of Open WSN are also available
  and were confronted at the ETSI PlugTest in Prague. There are
  also shipping products in the AMI/AMR domain (Wi-NAN) that operate
  in pre-standard variations of this work and we expect them
  to move to the standard version at some point of time.
  There were also discussions on how IEEE specs should be
  referenced; the authors followed the best practices obtained
  from multiple parties, including the RFC editor and the
  IEEE-IETF coordination, of using undated references whenever possible.

Personal

  Document Shepherd: Pascal Thubert
  Responsible AD: Brian Haberman

(3) The shepherd has followed the document along the WG process.
In particular, being editor of RPL, the shepherd provided guidance
and review on the usage of RPL in the draft.

(4) The document Shepherd has no concern about the depth or breadth of the
reviews that have been done. Multiple implementations and bi-weekly calls
attest of the thoroughness of the process. Detailed corrections were made
in the recent versions that attest from the in-depth review and implementations.

One of the authors is the inventor of TSCH, and his company is shipping TSCH products.
The other was the maintainer of the OpenWSN code base.

(5) The group got early security review from Tero Kivinen. The resulting
discussion took 2 IETF meetings and a lot of time at the interim calls
as well as long threads to resolve issues way beyond the visible part
of the iceberg that appears in the security section and the Auxiliary
Security Header example. 6TiSCH also formed a security design team that
has already produced work on the join process, and that work fed into
this document.


(6) The only concern is that we are 6/9 month behind schedule. As can
be observed from the ML activity, this is mostly related to security.
There are complexities involved in setting security properly with
802.15.4-2011, and there were discussions related to which key can
be used for which purpose during the join process and then during
the runtime of the network.

(7) The authors confirmed via mail that they have or know of no IPR that is new to this draft.

(8) There was IPR filed related to (draft-ietf-6tisch-architecture):
ftp://ietf.org/ietf/IPR/Linear%20Technology%20Corporation-ipr-draft-thubert-6tisch-architecture-00.txt
This IPR was discussed early in the 6TiSCH process. This is the
basic building block of IEEE 802.15.4 TSCH and there was no
objection that it exists.

(9) Very solid. The document was discussed at most interims and
at all F2F meeting.

(10) No threat of an appeal or apparent discontentment.

(11) Passed ID nits

    Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--).

(12) No required formal review

(13) All references within this document have been identified as
either normative or informative.

(14) All normative references to documents refer to completed work.
Required IEEE references already exist but undated ones are subject to update.

(15) No downward normative reference

(16) Publication of this document will not change the status of any
existing RFC.


(17) and (18) No IANA requirement

(19) Full text review but no automated checks beyond the ID-nits