Subject: [6tisch] Preliminary AD Review comments: draft-ietf-6tisch-minimal

From: Brian Haberman <[email-masked]>
Date: Wed, 28 Oct 2015 14:27:14 -0400

All,
     I apologize for the tardiness in this review.  I haven't completed
my entire review, but I wanted to get some issues out so that the
authors/WG can consider them along with the INT-Dir review already sent.
 There should be another INT-Dir review delivered in the next week or
so.  Feel free to discuss these with me if there are any questions on them.

* Meta : The document should be consistent in the use of SHOULD vs.
RECOMMENDED and MUST vs. SHALL.  Pick one nomenclature and stick with it.

* Meta : Suresh raised this same point, but I want to echo it.  Is
Standards Track the approach the WG wants to proceed with this document?
 Do you expect this to advance to Internet Standard at some point?
Would Best Current Practice be a better fit if it is expected that the
advice will change?

* Meta : Using a direct reference (e.g., [IEEE802154]) as a noun is not
the correct way to reference other works. I prefer seeing the reference
at the end of the sentence as is required in many journals and
conferences. For example, in the Introduction, I would make the
following change:

OLD:
   [IEEE802154] provides a mechanism whereby the
   details of slotframe length, timeslot timing, and channel hopping
   pattern are communicated when a node synchronizes to the network.

NEW:
   The IEEE 802.15.4 specification provides a mechanism whereby the
   details of slotframe length, timeslot timing, and channel hopping
   pattern are communicated when a node synchronizes to the network
   [IEEE802154].

This occurs in many places in the draft and should be changed.

* Meta : All the figures should be numbered and referenced by number in
the text.

* Meta : All acronyms should be expanded on first use.

* Introduction

  1. I don't think 2119 keywords make sense in an introduction.

  2. What constitutes a TSCH-compliant network? Is RPL required in order
to be compliant?

* Section 3 : What exactly is a "minimum schedule configuration"?

* Section 3.1

  1. s/length, and which repeats/length that repeats/

  2. The text says that there is only a single active slot in slotframe,
but the figure indicates that the number of slots is variable. Why
aren't these consistent?

  3. I don't understand this sentence : "The active slot MAY be
scheduled at the slotOffset 0x00 and channelOffset 0x00..." Does this
mean it can really be scheduled anywhere and the nodes will find it
since it is advertised in the EB?

  4. The text mentions slotframe length but provides no definition or
reference for it.

  5. The text RECOMMENDS a default slot duration of 10ms. I don't see a
slot duration in the accompanying figure. What if an implementation
chooses a different duration?

* Section 3.2 : The 2nd paragraph starts with "... bitmap of cell
options below." Not sure how to follow the "below" directive.

* Section 3.3 : I would like to see a little bit of discussion on how
the number of re-transmits affect minimal operation.

* Section 3.4

  1. There are a bunch of declarative statements in this section (e.g.,
"The radio of the RX node is turned on tsRxWait/2..."). Do these need to
be re-worded with 2119 keywords?

  2. It is unclear to me where to find the description of CCA.

* Section 4

  1. *How* does an implementer indicate in the corresponding Frame
Control field that the source address contains an extended address?

  2. There are a couple of instances of lower-case "shall".  Should
those be interpreted as SHALL/MUST?

  3. There is reference to a Table 2a.  Is that a table in the 802.15.4
spec?  Some clarity is needed.

  4. I see ASN and immediately think "Autonomous System Number", but I
don't think you mean that.

* Section 5

  1.  s/EBs MUST NOT in general/EBs MUST NOT/

  2. How does the discussion of the TSCH Timeslot IE relate to the
discussion in section 3.1?

  3. Is the 2.4GHz OQPSK Phy the only phy supported by 6tisch-minimal?

* Section 7 : I am left wondering how the neighbor information
maintained by a node/mote affects interoperability. A brief sentence or
two would go a long way to motivate this section.

* Section 9

  1. s/Section Section 5/Section 5/

  2. I am really confused on how the management of K1 and K2 are
supposed to work given all the optional language here. K1 could be equal
to K2. K1 MAY be some value. I know there is ongoing discussion on the
key management subject, but I suspect that this text will get very
interesting comments from Sec-Dir reviewers.

* Section 10.1.1

  1. Is all of this needed if it is already in RFC 6552?

  2. I am curious as to what happens if a node/mote does not use a
rank_factor of 1. Does the Earth stop rotating?

  3. OF0 = Objective Function 0?

* Section 10.2 : s/these MUST obey to/these MUST follow/

* Section 10.2.1 : Does "MUST support" imply "MUST use"?

* Section 10.2.4 : The text says the variables are defined in the
previous section, but the variables are actually defined in different
sections.

* Section 11

1. s/the IEs the form/the IEs that form/

2. s/the later has/the latter has/

Regards,
Brian