Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration
draft-ietf-6tisch-minimal-21

- Substantive Comments

-- Section 4, 2nd paragraph, "A node MAY use different values": Is that intended to weaken the RECOMMENDED in the previous sentence? (If not, then is the MAY needed at all?)

-- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you articulate why it might be reasonable to make other choices?

-- 4.5.2, 3rd paragraph, "It MAY be necessary..."
That seems like a statement of fact. Please consider non-2119 language.

--- 4th paragraph: It's not clear to me if the MUST in "MUST be sent as per the 802.15.4 specification..." is constraining options from that specification, or just referring to requirements that exists in that specification. If the latter, please consider descriptive rather than normative language. (e.g. "The 802.15.4 specification requires...."

-- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make sense not to follow those rules?


- Editorial Comments

-- Abstract: Please expand 6TICH on first mention

While reading, I frowned upon the same MAY & RPL issue as mentioned by Alvaro:
The Introduction mentions that "RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network.", but Section 5 (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used."

sounds like 20 works for us thanks.

Thank you for addressing the issues raised by the SecDir review.

A couple of comments mostly on the use of normative language:

1) The following sentence contradict a little all other normative language in this document (basically making everything a SHOULD):
"Any 6TiSCH compliant device SHOULD implement this mode of operation."
Why is this a upper case SHOULD? Is this sentence needed at all? 

2) Here the usage of normative language is also not clear to me:
"The default values of the TSCH Timeslot template (defined in
   [IEEE802154-2015]  section 8.4.2.2.3) and Channel Hopping sequence
   (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used.  A node
   MAY use different values by properly announcing them in its Enhanced
   Beacon."

3) Is it correct that these are SHOULDs?
"EB Destination Address field SHOULD be set to 0xFFFF (short broadcast
   address).  The EB Source Address field SHOULD be set as the node's
   short address if this is supported.  Otherwise the long address
   SHOULD be used."

4) What the recommended value for EB_PERIOD?:
"In a minimal TSCH
   configuration, a node SHOULD send an EB every EB_PERIOD."

5) This is also a weird SHOULD for me:
"EBs SHOULD be used to obtain information about local networks, ..."
What else should be used? Or you just don't obtain the information you need. I actually guess that you should simply use a lower case should in this sentence.
Should it be?:
"The default values of the TSCH Timeslot template (defined in
   [IEEE802154-2015]  section 8.4.2.2.3) and Channel Hopping sequence
   (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used.  If a node
   uses different values, it MUST properly announcing them in its Enhanced
   Beacon."
Or is this sentence just duplicating the SHOULD of the previous sentence slightly differently?

6) Maybe also name the recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to section 7.3?

7) "At any time, a node MUST maintain connectivity to at least one time
   source neighbor. "
  How can you ensure that you can maintain connectivity? I guess this must be a SHOULD... or what do you mean exactly by 'maintain connectivity'?

8) I think this sentence is confusing given the recommended value for NUM_UPPERLAYER_PACKETS is 1:
"One entry in the queue is reserved at all times for frames of type BEACON."
I guess what you want to say it that if a BEACON should be send and there is no space in the queue one frame should be drop and the BEACON should be queued instead?

9) I'm a little surprised to not see anything about 6LoWPAN in the body of the document (besides the intro in section 1). Shouldn't there also be some normative language on the use of 6LoWPAN?

One editorial comment (from the abstract):
I don't really understand this sentence
"A minimal mode of operation is a baseline set of protocols, ..."
I guess you want to say something like
"This minimal mode of operation specifies the baseline set of protocols that need to be supported, .."

- Figure 5: Don't you need to specify units?

- section 8: I see no point whatsoever in saying "Details are
out of scope, but the link layer must provide some
flexibility here." What is an implementer supposed to do with
that?

- section 8: You ought add a reference to the spec that
explains how a JN that doesn't know K1 or K2 still fails the
joining process for a fake EB.

- section 8: "MUST be avoided" is bogus, you ought rephrase
that with a MUST NOT I think (or a SHOULD NOT maybe if
combined with the exception in the next sentence).