Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement
draft-ietf-6tisch-tsch-06

[Ballot comment]

I didn't see explicit mention of privacy (as opposed to
confidentiality), but that's not a huge deal given (I think)
TSCH supports encryption. However, if privacy is a goal (and I
hope it is) wouldn't mentioning that be good, and maybe it'd
spur someone to later thing about e.g. traffic analysis and
whether or not some mechanisms to counter that might be needed
in these contexts.

[Ballot comment]
I don't object to the publication of this document, but I have a
swathe of Comments that I think you should address before the draft is
published as an RFC.

Some of these comments arise from Deborah Brungard's review as "AD in
training".

In general, I found this document a very heavy way of saying "we need an
adaptation function, and we need a control plane that can determine and
enforce end-to-end paths subject to timeslot assignment." I don't
suppose there is anything to be done about that now, but you used a lot
of words!

---

There are a number of abbreviations that the RFC Editor will ask you to
expand on first use both in the Abstract and in the main body of text.
If you have te document open for other edits, you should take a pass at
this to make sure the right expansions are used.

---

Section 1, para 3
Not sure whether "ultra-lower power" is a typo or an undefined term.

---

Section 1

  Bringing industrial-like performance into the LLN stack...

I'm not sure what "industrial-like performance" is supposed to mean.
Two paragraphs earlier you described the industrial environment, but not
anything that matches the term "industrial-like performance".

Could you usefully reword as "Enabling the LLN protocol stack to operate
in industrial environments..."

---

Section 1

  What is missing is a Logical
  Link Control (LLC) layer between the IP abstraction of a link and the
  TSCH MAC, which is in charge of scheduling a timeslot for a given 
  packet coming down the stack from the upper layer.

I found this odd. Do you mean to say...

  What is missing is a link layer control protocol that is in charge of
  scheduling a timeslot for a given IP packet that will be encapsulated
  in the TSCH MAC.

But in Section 4 I see you have come back to the term "LLC". I'm not
comfortable with this use of the term. It doesn't fit (as far as I can
see) with the conventional (i.e., OSI) usage of the term. You might look
to GMPLS for the way that this terminology issue was handled for
adaptation into layer 2 or 1 technologies, and the way that those
technologies are controlled by signaling or management protocols.

---

It would seem that Section 2 is redundant and can be removed.

---

Section 3

  Low-power WPANs are characterized
  by small packet sizes

Is this the characterisation that you want to call to our attention or
is it the small maximum frame size?

---

The last paragraph of Section 3 seems to be out of place. It is
certainly worth noting any implementation information, but, as
recommended by RFC 6982 this information is better placed either in an
implementation report (a separate document) or in a wiki. There are good
political reasons for doing this, and also good practical reasons as the
RFC will be an ossified record - you don't want endless updates to the
RFC just because someone else has written some more code!

---

Section 4

  As highlighted in Appendix A, TSCH differs from traditional low-power
  MAC protocols because of its scheduled nature.

Is there a long tradition? Did your father's father code low-power MAC
protocols, perhaps whittling them by hand from a single piece of
hornbeam?  :-)

Maybe s/traditional/other/

---

Section 4.1

  1.  Define the Information Elements included in the Enhanced Beacons
      advertising the presence of the network.

Am I supposed to know what an "Enhanced Beacon" is? Should there be an
explanation of a reference?

---

Section 4.1

  4.  Define a mechanism to secure the joining process and the
      subsequent optional process of scheduling more communication
      cells.

This is the first mention of a cell. It would hav helped to either
explain it or give a reference.

Ah! There is the definition in 4.5. Is something out of order, or
would a forward pointer be enough? Turns out a "cell" was not what I
thought it was.

---

Section 4.5 mentions PCE. That is OK, but you will need to expand the
abbreviation, and you should give a reference.

Similarly, while 4.8 does expand "PCE" a reference would help.

---

Section 4.6 has

  The LLC needs to:

  1.  Define a queuing policy for incoming and outgoing packets.

It is not clear (to me) whether this needs to be a network-wide policy, a
per-node policy that can be standardised and/or communicated, or is a
per-node policy that can be configured or hard-wired at implementation.

Maybe "the LLC has to allow for the implementation and configuration of a
policy..."

---

Section 4.7

  1.  Ensure timely delivery of such data.

"Timely" might be subjective.
What do you really mean?

---

Section 4.8

  An example of decentralized
  algorithm is provided in [tinka10decentralized].  This mechanism can
  be used to establish multi-hop paths in a fashion similar to RSVP.

I'm afraid I didn't hunt down the referenced paper. I wonder whether you
mean RSVP or RSVP-TE. Probably you *do* mean RSVP in that the
decentralised approach allows the reservations to form along the routes
the packets happen to follow. Perhaps including a reference (probably
RFC 2205 if you do man RSVP) and some explanation of what you mean by
"decentralised" would help.

I can see "decentralised" as meaning classic RSVP or just a signaling
plane like RSVP-TE allowing the hops to select cells.

---

Section 4.8

  1.  Provide a mechanism for two 6TiSCH devices to negotiate the
      allocation and deallocation of cells between them.

This is the first mention of 6TiSCH in a 6TiSCH document! Don't you
think it would be good to define the term?

---

Section 4.9

  3.  Define a mechanism to allow for the secure transfer of signaling
      data between nodes and the LLC.

This reads as though the LLC is now being treated as the centralised
control entity not a "layer" as previously defined. Certainly, the
transfer of data between a node and a "layer" is probably achieved within
the node so security is not an issue.

Fix this with s/and/within/ ?

---

I'm not convinced by your choice to put all but one reference as non-
normative.

[I-D.ietf-6tisch-terminology] seems to be required reading to understand
the terms used in this document.

[IEEE802154e] might reasonably be assumed to be fundamental to
understanding what TSCH is.

Equally, some of the references seemed a little gratuitous. For example:
  To map the services required by the IP layer to the services provided
  by the link layer, an adaptation layer is used
  [palattella12standardized].

I'm sure there are other issues with references, but I lacked the energy
to go through them. Could you please work this issue with your AD.

---

It would have been good to have included proper forward references to
the two Appendixes from early in the document.

---

Why is Appendix B titled "TSCH Gotchas" when many of the features
described are positive attributes of TSCH?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6tisch-tsch-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: <6tisch@ietf.org>
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals) to Informational RFC


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:
- 'Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem
  Statement and Goals'
  as Informational RFC

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 2015-02-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 the environment, problem statement, and goals
  for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
  The set of goals enumerated in this document form an initial set
  only.




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

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


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

(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

(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

(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

(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.

    This doc does not standardize anything, nor does it advance/suggest any novel idea.
    Confirmation that draft "is NOT introducing any IPR" was obtained from the author at the time of this writing.
    For information, the documents that are described therein were produced by IEEE 802.15.4 and the LoA 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

(1) This document was designed for informational:
    It is a description of IEEE 802.15.4e TSCH for IETF consumption.
  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.

  IPR related to that work is handled at the IEEE following their process.
  This doc does not standardize anything above that.

(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