(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:
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
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
Version 12 of the draft reflects the corrections that we made to fix all the issues.
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.
Document Shepherd: Pascal Thubert <firstname.lastname@example.org>
Responsible AD: Brian Haberman <email@example.com>
(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
(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):
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
(17) and (18) No IANA requirement
(19) Full text review but no automated checks beyond the ID-nits