(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.
Personnel
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:
http://standards.ieee.org/about/sasb/patcom/pat802_12.html
(8) Has an IPR disclosure been filed that references this document?
No
(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
discontent?
No
(11) Identify any ID nits the Document Shepherd has found in this
document.
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?
No
(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.
No
(16) Will publication of this document change the status of any
existing RFCs?
No
(17) Describe the Document Shepherd's review of the IANA considerations
section.
No IANA action
(18) List any new IANA registries that require Expert Review for future
allocations.
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