Shepherd writeup

(1) This document was designed for informational: 
    * It is a description of IEEE 802.15.4e TSCH for IETF consumption;
    * It is not a requirement or a problem statement draft;
    * It does not add intellectual content to the described IEEE work.
   The document lays the basis of the 6TiSCH work but does not standardize a thing.
(2) Document Announcement Write-Up:
Technical Summary
   This document describes the environment, problem statement, and goals
   for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
   This MAC is the base for the 6TiSCH work. 6TiSCH adds in particular a LLC 
   Sublayer and security mechanisms that are described is separate documents.
Working Group Summary
  The 6TiSCH group counts a number of 802.15.4 and 4e experts, on topics 
  including MAC operations and security. This document focuses on MAC 
  operations only.  6TiSCH has started a new line of work on the security 
  of the join process and of link operation separately so that piece is not
 expected from the present document. 
Document Quality
  The document is a high-level description of an IEEE standard and does not define 
  a standard component by itself. It can be expected that  802.15.4e will be slightly 
  revised as it is wrapped up in the IEEE 802.15.4-2015 standard.  The changes, 
  though, will probably be below the level of detail addressed in the document.
  Document Shepherd: Pascal Thubert
  Responsible Area Director: Ted Lemon
(3) On document readiness 
   The last call agenda was discussed at the WG meeting in Hawaii.
   6TiSCH also maintains a biweekly interim meeting over webex.
    The last call for this document was started on 11/28 over the WG ML; 
    conclusions were discussed at the 12/5 interim and published in the minutes on 12/6.
    This document addresses the last call comments and is ready for publication.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?  
    No. The document was stable for a while now.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
   No. It is good information for people involved in 6TiSCH
(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 
  No concern. 
  The security piece is weak but 6TiSCH and 802.15.9 are covering that separately.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.
The authors have been asked if they are aware of any IPR applicable to
the document, and have indicated that they are not aware of any.  Note
that this document explains the IEEE TSCH extension to 802.15.4
(802.15.4e) in the context of proposed standards work within the IETF.
There is IPR applicable to IEEE 802.15.4 and IEEE 802.15.4e. As port
of the IEEE process, companies participating have signed LoAs, a list
of which can be found here:
(8) Has an IPR disclosure been filed that references this document?
(9) How solid is the WG consensus behind this document?  
   I believe the WG as a whole understand and agree with it, since it is a base tool for working at 6TiSCH.
(10) Has anyone threatened an appeal or otherwise indicated extreme 
(11) Identify any ID nits the Document Shepherd has found in this
A number of references cleaned up.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
  No such need
(13) Have all references within this document been identified as
either normative or informative?
  Yes. All references are informative but RFC2119 which is there as a boiler plate but NOT used. The nits also reports 7 missing references but those are effectively present, unsure what the tool was looking for.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in 
the Last Call procedure. 
(16) Will publication of this document change the status of any
existing RFCs?  
(17) Describe the Document Shepherd's review of the IANA considerations
  No IANA action
(18) List any new IANA registries that require Expert Review for future
  No IANA registry  
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
   No formal language