Shepherd writeup
rfc8180-21

(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 <pthubert@cisco.com>
  Responsible AD: Brian Haberman <brian@innovationslab.net>

(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

Back