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

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?

The reference to 2119 appears to be unnecessary.

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.