Subject: [Int-dir] INT-DIR review of draft-ietf-6tisch-minimal-12

From: Ralph Droms <[email-masked]>
Date: Sat, 31 Oct 2015 07:52:48 +0900

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

---

From: Ralph Droms <[email-masked]>
Date: Sat, 31 Oct 2015 08:49:12 +0900

I just noticed I didn't complete the text for comment 10.  Here is the revised review.

  6.  Acknowledgment

  Frame types BEACON and COMMAND are transmitted before frame types
  DATA and ACK.

  A node has to be prepared to send a BEACON or COMMAND frame at any
  time.

I've tried to infer the desired behavior from the description of queue
usage.  If I understand the original text correctly, there is no
difference between the second and third requirements.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 31 Oct 2015 03:45:33 +0000

Hello Ralph

Regarding specifically your item 2, about RPL. 

This  may be related to your item 1 (clarity of the goal) but your comment indicates that you missed the point of this draft.

The point is to document a collection of protocols and settings that will enable to build a 6TiSCH mesh network and lead to interoperable implementations.

6TiSCH defined that this minimal collection would include a TSCH MAC, IPv6, 6LoWPAN and RPL. This makes full sense to me and in any fashion is the group decision.

Cheers,

Pascal

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]]
> Sent: samedi 31 octobre 2015 08:49
> To: <[email-masked]> <[email-masked]>; draft-ietf-6tisch-
> [email-masked]
> Subject: Re: INT-DIR review of draft-ietf-6tisch-minimal-12
> 
> 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
> any other Last Call comments that have been received. For more details on
> the INT Directorate, see http://www.ietf.org/iesg/directorate.html.
> 
> needs significant restructuring and editing.  I will be happy to work with the
> WG to revise the document and review future revisions.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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
> 
> 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].
> 
> 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:
> 
> 5. In this text from the Introduction, does "synchronizes with the network"
> mean time synchronization or something else:
> 
> 6. I don't think the last sentence of the Introduction is relevant to an
> Introduction.
> 
> 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].
> 
> 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:
> 
> I've tried to infer the desired behavior from the description of queue usage.
> If I understand the original text correctly, there is no difference between the
> second and third requirements.
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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).

---

From: Ralph Droms <[email-masked]>
Date: Sat, 31 Oct 2015 13:24:41 +0900

> On Oct 31, 2015, at 12:45 PM 10/31/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ralph
> 

OK, but the first sentence of the abstract is:

   This document describes the minimal set of rules to operate an IEEE
   802.15.4 Timeslotted Channel Hopping (TSCH) network.

The *only* occurrence of the string "6tisch" (case insensitive) in the text of this document (not in citations, etc.) is in the Acknowledgments section:

   Also our acknowledge to the 6TiSCH
   Chairs Pascal Thubert and Thomas Watteyne for their guideance and
   advice.

How in the world would anyone know this document is intended to cover the entire stack as required by a "6TiSCH mesh network".

> 6TiSCH defined that this minimal collection would include a TSCH MAC, IPv6, 6LoWPAN and RPL. This makes full sense to me and in any fashion is the group decision.

I didn't say it wasn't a group decision ... I disagree with the group decision, as I understood the purpose of this document from the Abstract.

If this document is really supposed to describe the minimal requirements for the whole stack in a "6TiSCH mesh network", doesn't it need text describing address assignment, which flavor and how to use ND, etc., etc.

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 31 Oct 2015 10:00:27 +0000

All good points, Ralph.

I agree with the need to improve the abstract. 

The main structure of a 6TiSCH network with RPl and all is in the architecture draft but that doc is now delayed.

6LoWPAN ND does not really have options so there was no need to spend text on it. We could mention it though, since the architecture cannot be referenced.

Cheers,

Pascal

> Sent: samedi 31 octobre 2015 13:25
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: <[email-masked]> <[email-masked]>; draft-ietf-6tisch-
> [email-masked]
> > This  may be related to your item 1 (clarity of the goal) but your comment
> indicates that you missed the point of this draft.
> >
> > The point is to document a collection of protocols and settings that will
> enable to build a 6TiSCH mesh network and lead to interoperable
> implementations.
> 
> The *only* occurrence of the string "6tisch" (case insensitive) in the text of
> this document (not in citations, etc.) is in the Acknowledgments section:
> 
> How in the world would anyone know this document is intended to cover
> the entire stack as required by a "6TiSCH mesh network".
> 
> > 6TiSCH defined that this minimal collection would include a TSCH MAC,
> IPv6, 6LoWPAN and RPL. This makes full sense to me and in any fashion is
> the group decision.
> 
> I didn't say it wasn't a group decision ... I disagree with the group decision,
> as I understood the purpose of this document from the Abstract.
> 
> If this document is really supposed to describe the minimal requirements
> for the whole stack in a "6TiSCH mesh network", doesn't it need text
> describing address assignment, which flavor and how to use ND, etc., etc.
> 
> - Ralph
> 
> >
> > Cheers,
> >
> > Pascal
> >
> >> These comments were written primarily for the benefit of the Internet
> >> Area Directors. Document editors and
> >> any other Last Call comments that have been received. For more
> >> details on the INT Directorate, see
> >> 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, ???
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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?
> >>
> >> 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
> >> 802.15.4 TSCH operation until the full IPv6 suite is running, at
> >> which time RPL will provide optimal routing.
> >>
> >> 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?
> >> 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].
> >>
> network"
> >> 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.
> >>
> usage.
> >> If I understand the original text correctly, there is no difference
> >> between the second and third requirements.
> >>
> >> editorial aside, this table is pretty much what I expected to be the bulk
> of this document.
> >>
> >> edited, and I think it should be replaced with quoted text from RFC 6552.
> >>
> >> 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).
> >

---

From: Brian Haberman <[email-masked]>
Date: Sat, 31 Oct 2015 23:21:31 -0400

Pascal,

On 10/31/15 6:00 AM, Pascal Thubert (pthubert) wrote:
> The main structure of a 6TiSCH network with RPl and all is in the
> architecture draft but that doc is now delayed.

Saying the architecture draft is delayed appears to make it sound like
it is stuck. It is only delayed because the WG is not actively trying to
address all the comments that were raised during review.

Brian

> 
> 6LoWPAN ND does not really have options so there was no need to spend
> text on it. We could mention it though, since the architecture cannot
> be referenced.
> 
> Cheers,
> 
> Pascal
> 
> 
>> -----Original Message----- From: Ralph Droms
>> [mailto:[email-masked]] Sent: samedi 31 octobre 2015 13:25 
>> To: Pascal Thubert (pthubert) <[email-masked]> Cc:
>> <[email-masked]> <[email-masked]>; draft-ietf-6tisch- 
>> [email-masked] Subject: Re: INT-DIR review of
>> draft-ietf-6tisch-minimal-12
>> 
>> 
>> This document describes the minimal set of rules to operate an
>> IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network.
>> 
>> The *only* occurrence of the string "6tisch" (case insensitive) in
>> the text of this document (not in citations, etc.) is in the
>> Acknowledgments section:
>> 
>> Also our acknowledge to the 6TiSCH Chairs Pascal Thubert and Thomas
>> Watteyne for their guideance and advice.
>> 
>> How in the world would anyone know this document is intended to
>> cover the entire stack as required by a "6TiSCH mesh network".
>> 
>> IPv6, 6LoWPAN and RPL. This makes full sense to me and in any
>> fashion is the group decision.
>> 
>> I didn't say it wasn't a group decision ... I disagree with the
>> group decision, as I understood the purpose of this document from
>> the Abstract.
>> 
>> If this document is really supposed to describe the minimal
>> requirements for the whole stack in a "6TiSCH mesh network",
>> doesn't it need text describing address assignment, which flavor
>> and how to use ND, etc., etc.
>> 
>> - Ralph
>> 
>>> 
>>> Cheers,
>>> 
>>> Pascal
>>> 
>>>> -----Original Message----- From: Ralph Droms
>>>> [mailto:[email-masked]] Sent: samedi 31 octobre 2015
>>>> 08:49 To: <[email-masked]> <[email-masked]>;
>>>> draft-ietf-6tisch- [email-masked] Subject: Re: INT-DIR
>>>> review of draft-ietf-6tisch-minimal-12
>>>> 
>>>> 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
>>>> 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.
>>>> 
>>>> to the document as a whole, while the remainder address more
>>>> specific issues, roughly in the order of appearance in the
>>>> document.
>>>> 
>>>> 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).
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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
>>>> 
>>>> an acknowledgment.  The sender node MUST set the ACK requested 
>>>> bit in the MAC header.  The acknowledgment frame is of type ACK
>>>> (frame
>> type
>>>> receiver.  Refer to Section 11.3 for an example of the Header
>>>> IE content.  The possible values for the Time Synchronization 
>>>> [IEEE802154] and the fifth sentence is an inferred
>>>> specification for this document. The description of the IE is a
>>>> 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?
>>>> 
>>>> 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.
>>>> 
>>>> Frames generated by the IEEE 802.15.4 layer are transmitted
>>>> before frames containing higher-layer packets.
>>>> 
>>>> If I understand the original text correctly, there is no
>>>> 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
>>>> 13. Even if the number of timeslots in a slotframe is variable
>>>> for this minimal configuration, should there be a default?
>>>> 
>>>> 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.
>>>> 
>>>> 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?
>>>> 
>>>> 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.
>>>> 
>>>> 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 
>>>> 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.
>>>> 
>>>> 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).
>>>