Subject: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

From: "6tisch issue tracker" <[email-masked]>
Date: Fri, 27 Nov 2015 10:54:39 -0000

#40: Ralph's INT AREA review on minimal

 I am an assigned INT directorate reviewer for draft-ietf-6tisch-
 minimal-12.  These comments were written primarily for the benefit of the
 Internet Area Directors. Document editors and
 shepherd(s) should treat these comments just like they would treat
 comments from any other IETF contributors and resolve them along with any
 other Last Call comments that have been received. For more details on the
 INT Directorate, see http://www.ietf.org/iesg/directorate.html.

 Review submitted by Ralph Droms

 Summary: In my opinion, the WG needs to reconsider some of the fundamental
 aspects of this proposed specification, and the document needs significant
 restructuring and editing.  I will be happy to work with the WG to revise
 the document and review future revisions.

 There may be overlaps between my comments and those in other reviews
 because I avoided reading those reviews before writing up my review.

 Here are my comments on the document.  The first four comments apply to
 the document as a whole, while the remainder address more specific issues,
 roughly in the order of appearance in the document.

 1. Goals and requirements are unclear

 The requirements for this document are unclear to me.  Exactly what
 services would a "minimal mode of operation" provide?  The Abstract and
 most of the document talks about the operation of an IEEE 802.15.4 TSCH
 network, yet the title of the document is "Minimal 6TiSCH Configuration".
 Does a network that follows these rules provide an L2 IEEE 802.15.4
 service, an IPv6 6TiSCH service, ???

 Related to this question, does this document describe "a minimal set of
 rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of
 operation" (both text snippets from the Abstract).

 2. Requirement for RPL is ill-advised

 This document seems to be focused on IEEE 802.15.4 TSCH operational
 parameters.  Yet, it calls for the use of RPL, which seems to me to be a
 highly undesirable entangling of protocols at different layers of the
 protocol stack.  IEEE 802.15.4 TSCH is expected to be used in networks
 that don't use RPL.

 My understanding of the document is that RPL is assumed to be in use
 because it is required in a 6TiSCH network.  RPL is then used to generate
 the Join Priority through the DAGRank function as specified in section
 7.2.  The use of RPL implies to me the configuration and operation of a
 full IPv6 stack, which hardly seems like a minimal mode of operation for
 IEEE 802.15.4 TSCH.

 I have a question about this text from section 7.2:

    When a node joins the network,
    it MUST NOT send EBs before having acquired a RPL rank.  This avoids
    routing loops and matches RPL topology with underlying mesh topology.

 What is meant by "avoiding routing loops"?  My understanding is that IEEE
 802.15.4 TSCH simply provides for frame delivery between neighbors and
 does not provide frame forwarding.  How would routing loops arise from
 running IEEE 802.15.4 TSCH?

 Has the WG considered reorganizing the 6TiSCH protocol suite and documents
 to separate the minimal operation of IEEE 802.15.4 TSCH from
 IPv6/RPL/ND/etc?  For example, has the WG considered allowing a simpler,
 initial Join Priority scheme that would provide minimal IEEE
 802.15.4 TSCH operation until the full IPv6 suite is running, at which
 time RPL will provide optimal routing.

 3. Restatement of specifications in IEEE 802.15.4 documents

 I haven't read the most recent IEEE 802.15.4 docs and it has been a while
 since I took a close look at earlier revs.  With that disclaimer in mind,
 how much of the text in sections 3 through 9 is a restatement of the IEEE
 802.15.4 specification and how much is the specification of operational
 parameters for minimal operation of a IEEE 802.15.4 TSCH network?
 Restatement of specifications can be confusing and lead to a lack of
 interoperability.  As a small example, here is section 6:

   6.  Acknowledgment

      Link-layer acknowledgment frames are built according to [IEEE802154].
      Unicast frames sent to a unicast MAC destination address MUST request
      an acknowledgment.  The sender node MUST set the ACK requested bit in
      the MAC header.  The acknowledgment frame is of type ACK (frame type
      value 0b010).  Each acknowledgment contains the following IE:

         ACK/NACK Time Correction IE: The ACK/NACK time correction IE
         carries the measured de-synchronization between the sender and the
         receiver.  Refer to Section 11.3 for an example of the Header IE
         content.  The possible values for the Time Synchronization
         Information and ACK status are described in [IEEE802154].

 Out of that section, it seems to me that the first sentence is harmless,
 the second sentence is a specification for this document, the third and
 fourth sentences are a restatement of [IEEE802154] and the fifth sentence
 is an inferred specification for this document.  The description of the IE
 is a restatement of [IEEE802154].

 Section 6 could be rewritten as:

   6. Acknowledgement frames

      Unicast frames sent to a unicast MAC destination address MUST request
      an acknowledgment.  Each acknowledgment MUST contain an ACK/NACK
      Time Correction IE.

 4. Default behavior versus learned behavior

 Which of the configuration and operational specifications in this document
 must be pre-configured before a node joins the network, and which are
 learned through, e.g., EBs.  Are operational control and management
 questions out of scope for this document, such as:

   - when does a node switch from the "minimal 6TiSCH configuration" to
     some other configuration?
   - does a node use the configuration parameters it has received
     through EBs to generate its own EBs or does it use the "minimal
     6TiSCH configuration" parameters?

 5. In this text from the Introduction, does "synchronizes with the
 network" mean time synchronization or something else:

    [...] when a node synchronizes to the network.

 6. I don't think the last sentence of the Introduction is relevant to an
 Introduction.

 7. The document could use a section on the terminology used in the
 document, to provide definitive sources for definitions of the various
 terms and acronyms used in the document.  Most likely, the terminology
 section would simply point to relevant sections of [IEEE802154] and [I-D
 .ietf-6tisch-terminology].

 8. Section 11 should be an Appendix, rather than part of the body of the
 document, so as to avoid making those examples normative standards text.

 9. I think the contents of section 7.1 are entirely dependent on the
 specifics of an implementation and the section should be omitted.

 10. I think the information in section 8 would be more generally useful if
 not stated in terms of a queue-based implementation:

   A node must not transmit frames containing higher-layer packets
   until the node has successfully joined a network.

   Frame types BEACON and ACK

   Frames generated by the IEEE 802.15.4 layer are transmitted before
   frames containing higher-layer packets.

 11. According to [I-D.ietf-6tisch-terminology], the correct term is
 "timeslot", so s/time slot/timeslot/ throughout the document.

 12. In the table at the top of page 4 (BTW, please number and add a title
 to all tables), are the listed properties the only properties that have
 numeric or short text string values?  If not, all of those properties
 should be gathered together into a single table.  As an editorial aside,
 this table is pretty much what I expected to be the bulk of this document.

 13. Even if the number of timeslots in a slotframe is variable for this
 minimal configuration, should there be a default?

 14. In the table at the top of page 5, what do the empty boxes represent?

 15. The last sentence of section 3.2 seems to be a low-level
 implementation detail that can be omitted.

 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll
 suggest that almost all of section 3.4 is a restatement of the IEEE
 802.15.4 spec.  The last sentence is important, and isn't entirely clear.
 It would be clearer to write:

    For the minimal configuration specified in this document, the use
    of CCA is OPTIONAL.

 17. End of section 3 - not clear when to use macTimeslotTemplate.

 18. The third paragraph of section 4 is completely unclear to me:

    A Node aiming to join the network by receving a properly formed
    BEACON shall enter in a scan phase and shall store the value of
    macPANId and then set it to 0xffff for the duration of the scan in
    order to meet the filtering rules in [IEEE802154].

 What are "macPANId" and "scan phase"?  I don't see those terms used
 anywhere else in this document; do the terms come from the IEEE
 802.15.4 specs?  Why would an implementation store the value of macPANId
 and then set it to 0xffff?

 19. Does "synchronization" in section 5 mean "time synchronization"?

 20. In section 5, is "EB_PERIOD" the same value as defined in the table in
 section 10.2.4 that defines "RPL-related variables"?  If so, I don't
 understand why "EB_PERIOD" is in that table, as it only appears once in
 the rest of the document in section 5.

 21. I see that section 10 includes the statement:

    Nodes in a multihop network MUST use the RPL routing protocol
    [RFC6550].

 This statement is certainly false if one takes a broad definition of the
 word "multihop".  Even if edited to "multilink subnet" or "mesh", I can't
 find any support in RFC 6550 for the statement "MUST use RPL routing
 protocol".  I think it would be much clearer and more correct to quote
 verbatim the text describing this requirement from RFC 6550 rather than
 paraphrasing it here.

 Similarly, this sentence in section 10.1 needs, at least, to be edited,
 and I think it should be replaced with quoted text from RFC 6552.

    Nodes in the multihop network MUST implement the RPL Objective
    Function Zero [RFC6552].

 While I haven't provided a detailed review of the remainder of section
 10 because I don't think it's necessary for the goals of this document, it
 appears to me that much of section 10 is a restatement of the RPL
 specification from RFC 6550 and should, therefore, be omitted (if RPL is
 retained as a part of this recommendation).

-- 
-----------------------------------+-----------------------------------
 Reporter:  [email-masked]     |      Owner:  [email-masked]
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:  milestone1
Component:  minimal                |    Version:  1.0
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+-----------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40>
6tisch <https://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e

---

From: "6tisch issue tracker" <[email-masked]>
Date: Mon, 30 Nov 2015 12:20:44 -0000

Comment (by [email-masked]):

 Xavi addressed comments one by one, tracked under bitbucket as
 https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/
 All issues are solved but the intended status that we will track with a
 separate ticket

-- 
-----------------------------------+------------------------------------
 Reporter:  [email-masked]     |       Owner:  [email-masked]
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:  milestone1
Component:  minimal                |     Version:  1.0
 Severity:  Submitted WG Document  |  Resolution:
 Keywords:                         |
-----------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40#comment:1>
6tisch <https://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e

---

From: "6tisch issue tracker" <[email-masked]>
Date: Mon, 30 Nov 2015 12:29:19 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-----------------------------------+------------------------------------
 Reporter:  [email-masked]     |       Owner:  [email-masked]
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:  milestone1
Component:  minimal                |     Version:  1.0
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40#comment:2>
6tisch <https://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e

---

From: "6tisch issue tracker" <[email-masked]>
Date: Mon, 30 Nov 2015 12:31:33 -0000

All issues but the intended status fixed in https://www.ietf.org/id/draft-
 ietf-6tisch-minimal-13.txt. Intended status tracked as issue #41. This
 issu is fixed, waiting for feed back to close.

Ticket URL: <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40#comment:3>
6tisch <https://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e