All,

Thanks for the large amount of feedback on draft-ietf-6tisch-tsch. I'm
detailing below the rewording we propose. Alternatively, you can see the
current version at https://bitbucket.org/6tisch/draft-ietf-6tisch-tsch/.

We will discuss these at the 6TiSCH call tomorrow. When we reach consensus
on these (including confirmation on the ML), we will publish a new
revision. Let's target end of next week.

Thomas, Maria Rita, Alfredo

--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/22

*summary*: clarify why EB are sent on all frequencies

OLD:
Motes already part of the network can periodically send Enhanced Beacon
(EB) frames to announce the presence the network. These contain information
about the size of the timeslot used in the network, the current ASN,
information about the slotframes and timeslots the beaconing mote is
listening on, and a 1-byte join priority. Because of the channel hopping
nature of TSCH, these EB frames are sent on all frequencies.
NEW:
Motes already part of the network can periodically send Enhanced Beacon
(EB) frames to announce the presence the network. These contain information
about the size of the timeslot used in the network, the current ASN,
information about the slotframes and timeslots the beaconing mote is
listening on, and a 1-byte join priority. Even if a node is configured to
send all EB frames on the same channel offset, because of the channel
hopping nature of TSCH described in <xref target="sec_channel_hopping" />,
this channel offset translates into a different frequency at different
slotframe cycles. As a result, EB frames are sent on all frequencies.


OLD:
This results in "channel hopping": even with a static schedule, pairs of
neighbors "hop" between the different frequencies when communicating.
Channel hopping is a technique known to efficiently combat multi-path
fading and external interference.
NEW:
This results in "channel hopping": even with a static schedule, pairs of
neighbors "hop" between the different frequencies when communicating. A way
of ensuring communication happens on all available frequencies is to set
the number of timeslots in a slotframe to a prime number. Channel hopping
is a technique known to efficiently combat multi-path fading and external
interference.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/23

*summary*: high level description about joining node behavior

OLD:
A mote wishing to join the network listens for EBs. Using the ASN and the
other timing information of the EB, the new mote synchronizes to the
network. Using the slotframe and link information from the EB, it knows how
to contact the network.
NEW:
A mote wishing to join the network listens for EBs. Since EBs are sent on
all frequencies, the joining node can listen on any frequency until it
hears and EB. What frequency it listen on, of whether it slowly changes
frequency during this joining period is implementation-specific. Using the
ASN and the other timing information of the EB, the new mote synchronizes
to the network. Using the slotframe and link information from the EB, it
knows how to contact the network.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/24

*summary*: clarify use of join priority?

Several people have pointed out the need to be more specific about the join
priority, including the discussion started at ​
http://www.ietf.org/mail-archive/web/6tisch/current/msg02528.html

We need to reach consensus how much of this discussion belongs in the
6tisch-tsch draft, and update the draft accordingly.

*Discussion: before a rewording, we need to agree on whether this belongs
in this draft.*


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/25

*summary*: clarify use of MLME-TSCH-MODE.request primitive during joining?

Several people have pointed out the need to be more specific about the use
of the MLME-TSCH-MODE.request primitive during joining. That is, when does
a node issue this command. This discussion was ongoing in the thread ​
http://www.ietf.org/mail-archive/web/6tisch/current/msg02528.html

We need to reach consensus how much of this discussion belongs in the
6tisch-tsch draft, and update the draft accordingly.

*Discussion**: before a rewording, we need to agree on whether this belongs
in this draft.*


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT1

*   The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an*
*   amendment to the Medium Access Control (MAC) protocol defined by the*
*   IEEE802.15.4-2011 [IEEE802154] standard.  The Timeslotted Channel*
*   Hopping (TSCH) mode of IEEE802.15.4e is the object of this document.*

*   => could we indicate that it will be merged in the next version (is
that*
*   going to be IEEE 802.15.4-2015?)*

OLD:
The IEEE802.15.4e standard <xref target="IEEE802154e"/> was published in
2012 as an amendment to the Medium Access Control (MAC) protocol defined by
the IEEE802.15.4-2011 <xref target="IEEE802154"/> standard. The Timeslotted
Channel Hopping (TSCH) mode of IEEE802.15.4e is the object of this document.
NEW:
IEEE802.15.4e <xref target="IEEE802154e"/> was published in 2012 as an
amendment to the Medium Access Control (MAC) protocol defined by the
IEEE802.15.4-2011 <xref target="IEEE802154"/> standard. IEEE802.15.4e will
be rolled into the next revision of IEEE802.15.4, scheduled to be published
in 2015. The Timeslotted Channel Hopping (TSCH) mode of IEEE802.15.4e is
the object of this document.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT2

*   TSCH was designed to "allow IEEE802.15.4 devices to support a wide*
*   range of industrial applications" [IEEE802154e].*

*   => could we indicate that its applicability is not necessarily limited
to*
*   industrial?*

OLD:
TSCH was designed to "allow IEEE802.15.4 devices to support a wide range of
industrial applications" <xref target="IEEE802154e"/>. At its core is a
medium access technique which uses time synchronization to achieve ultra
low-power operation and channel hopping to enable high reliability. This is
very different from the "legacy" IEEE802.15.4 MAC protocol, and is
therefore better described as a "redesign". TSCH does not amend the
physical layer; i.e., it can operate on any IEEE802.15.4-compliant hardware.
NEW:
TSCH was designed to allow IEEE802.15.4 devices to support a wide range of
applications including, but not limited to, industrial <xref
target="IEEE802154e"/>. At its core is a medium access technique which uses
time synchronization to achieve ultra low-power operation and channel
hopping to enable high reliability. This is very different from the
"legacy" IEEE802.15.4 MAC protocol, and is therefore better described as a
"redesign". TSCH does not amend the physical layer; i.e., it can operate on
any IEEE802.15.4-compliant hardware.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT3

*   At its core is a medium access technique which uses time
synchronization to*
*   achieve ultra low-power operation and channel hopping to enable high*
*   reliability.*

*   => could we indicate the order of precision that is currently obtained,
like*
*   10s of microseconds or better in some implementations ?*

OLD:
TSCH was designed to allow IEEE802.15.4 devices to support a wide range of
applications including, but not limited to, industrial <xref
target="IEEE802154e"/>. At its core is a medium access technique which uses
time synchronization to achieve ultra low-power operation and channel
hopping to enable high reliability. This is very different from the
"legacy" IEEE802.15.4 MAC protocol, and is therefore better described as a
"redesign". TSCH does not amend the physical layer; i.e., it can operate on
any IEEE802.15.4-compliant hardware.
NEW:
TSCH was designed to allow IEEE802.15.4 devices to support a wide range of
applications including, but not limited to, industrial <xref
target="IEEE802154e"/>. At its core is a medium access technique which uses
time synchronization to achieve ultra low-power operation and channel
hopping to enable high reliability. Synchronization accuracy impacts power
consumption, and can vary from micro-seconds to milli-seconds depending on
the solution. This is very different from the "legacy" IEEE802.15.4 MAC
protocol, and is therefore better described as a "redesign". TSCH does not
amend the physical layer; i.e., it can operate on any
IEEE802.15.4-compliant hardware.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT4

*   IEEE802.15.4e can be seen as the latest generation of ultra-lower*
*   power and reliable networking solutions for LLNs.  [RFC5673]*
*   discusses industrial applications, and highlights the harsh operating*
*   conditions as well as the stringent reliability, availability, and*
*   security requirements for an LLN to operate in an industrial*
*   environment.*

*   => maybe insist on the vast amounts of metallic equipment that creates
a*
*   terrible environment for radios, with a lot of self-induced as well as*
*   co channel interference?*

OLD:
IEEE802.15.4e can be seen as the latest generation of ultra-lower power and
reliable networking solutions for LLNs. <xref target="RFC5673"/> discusses
industrial applications, and highlights the harsh operating conditions as
well as the stringent reliability, availability, and security requirements
for an LLN to operate in an industrial environment. Commercial networking
solutions are available today in which motes consume 10's of micro-amps on
average <xref target="CurrentCalculator"/> with end-to-end packet delivery
ratios over 99.999% <xref target="doherty07channel"/>.
NEW:
IEEE802.15.4e is the latest generation of ultra-lower power and reliable
networking solutions for LLNs. <xref target="RFC5673"/> discusses
industrial applications, and highlights the harsh operating conditions as
well as the stringent reliability, availability, and security requirements
for an LLN to operate in an industrial environment. In these environments,
vast deployment environments with large (metallic) equipment cause
multi-path fading and interference to thwart any attempt of a
single-channel solution to be reliable; the channel agility of TSCH is the
key to its ultra high reliability. Commercial networking solutions are
available today in which motes consume 10's of micro-amps on average <xref
target="CurrentCalculator"/> with end-to-end packet delivery ratios over
99.999% <xref target="doherty07channel"/>.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT5

*   IEEE802.15.4e TSCH focuses on the MAC layer only.  This clean*
*   layering allows for TSCH to fit under an IPv6 enabled protocol stack*
*   for LLNs, running 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP*
*   [RFC7252].*

*   => we need to insist that there is a missing LLC layer between the IP*
*   abstraction of a link and the TSCH MAC, that is is charge in particular
to*
*   schedule a timeslot for a given packet coming down the stack from the
upper*
*   layer. I'd suggest to move this paragraph below the next one, so as to*
*   continue on the LLC operations that are described there.*

OLD:
<t>
         IEEE802.15.4e TSCH focuses on the MAC layer only. This clean
layering allows for TSCH to fit under an IPv6 enabled protocol stack for
LLNs, running 6LoWPAN <xref target="RFC6282"/>, RPL <xref
target="RFC6550"/> and CoAP <xref target="RFC7252"/>.
      </t>
      <t>
         Bringing industrial-like performance into the LLN stack developed
by the 6LoWPAN, ROLL and CoRE working groups opens up new application
domains for these networks. Sensors deployed in smart cities <xref
target="RFC5548"/> will be able to be installed for years without needing
battery replacement. "Umbrella" networks will interconnect smart elements
from different entities in smart buildings <xref target="RFC5867"/>.
Peel-and-stick switches will obsolete the need for costly conduits for
lighting solutions in smart homes <xref target="RFC5826"/>.
NEW:
<t>
         Bringing industrial-like performance into the LLN stack developed
by the 6LoWPAN, ROLL and CoRE working groups opens up new application
domains for these networks. Sensors deployed in smart cities <xref
target="RFC5548"/> will be able to be installed for years without needing
battery replacement. "Umbrella" networks will interconnect smart elements
from different entities in smart buildings <xref target="RFC5867"/>.
Peel-and-stick switches will obsolete the need for costly conduits for
lighting solutions in smart homes <xref target="RFC5826"/>.
      </t>
      <t>
         IEEE802.15.4e TSCH focuses on the MAC layer only. This clean
layering allows for TSCH to fit under an IPv6 enabled protocol stack for
LLNs, running 6LoWPAN <xref target="RFC6282"/>, RPL <xref
target="RFC6550"/> and CoAP <xref target="RFC7252"/>. What is missing is
Logical Link Control (LLC) layer between the IP abstraction of a link and
the TSCH MAC, which is is charge of scheduling a timeslot for a given
packet coming down the stack from the upper layer.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT6

*   => Please expand the acronyms on first use:*
*   the Constrained Application Protocol (CoAP)*
*   the IPv6 Routing Protocol for Low power and Lossy Networks (RPL)*

OLD:
IEEE802.15.4e TSCH focuses on the MAC layer only. This clean layering
allows for TSCH to fit under an IPv6 enabled protocol stack for LLNs,
running 6LoWPAN <xref target="RFC6282"/>, RPL <xref target="RFC6550"/> and
CoAP <xref target="RFC7252"/>. What is missing is Logical Link Control
(LLC) layer between the IP abstraction of a link and the TSCH MAC, which is
is charge of scheduling a timeslot for a given packet coming down the stack
from the upper layer.
NEW:
IEEE802.15.4e TSCH focuses on the MAC layer only. This clean layering
allows for TSCH to fit under an IPv6 enabled protocol stack for LLNs,
running 6LoWPAN <xref target="RFC6282"/>, IPv6 Routing Protocol for Low
power and Lossy Networks (RPL) <xref target="RFC6550"/> and the Constrained
Application Protocol (CoAP) <xref target="RFC7252"/>. What is missing is
Logical Link Control (LLC) layer between the IP abstraction of a link and
the TSCH MAC, which is is charge of scheduling a timeslot for a given
packet coming down the stack from the upper layer.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT7

*   by the 6LoWPAN, ROLL and CORE working groups*

*   => We might also use work from other WGs such as 6lo ACE, DICE, SACM
...*
*   What about:*
*   "by IoT related IETF working groups such as 6Lo, ROLL and CORE"*

OLD:
Bringing industrial-like performance into the LLN stack developed by the
6LoWPAN, ROLL and CoRE working groups opens up new application domains for
these networks. Sensors deployed in smart cities <xref target="RFC5548"/>
will be able to be installed for years without needing battery replacement.
"Umbrella" networks will interconnect smart elements from different
entities in smart buildings <xref target="RFC5867"/>. Peel-and-stick
switches will obsolete the need for costly conduits for lighting solutions
in smart homes <xref target="RFC5826"/>.
NEW:
Bringing industrial-like performance into the LLN stack developed by
Internet of Things (IoT) related IETF working groups such as 6Lo, ROLL and
CoRE opens up new application domains for these networks. Sensors deployed
in smart cities <xref target="RFC5548"/> will be able to be installed for
years without needing battery replacement. "Umbrella" networks will
interconnect smart elements from different entities in smart buildings
<xref target="RFC5867"/>. Peel-and-stick switches will obsolete the need
for costly conduits for lighting solutions in smart homes <xref
target="RFC5826"/>.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT8

*   => Please include a section like below after the intro, it appears to
be a*
*   good idea even in Informational; you are also missing a security
section and*
*   a IANA section in the end:*

*   <section anchor="ref_for_later" title="Requirements Language">*
*        <t>*
*        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT",*
*        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this*
*        document are to be interpreted as described in <xref*
*        target="RFC2119">RFC 2119</xref>.*
*        </t>*
*   </section>*

NEW:
<section anchor="ref_for_later" title="Requirements Language">
      <t>
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC
2119</xref>.
      </t>
   </section>


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT9

*   2.  TSCH in the LLN Context*

*   => Shouldn't that be "IP over TSCH" or "TSCH in an IoT context"*

OLD:
Using IEEE802.15.4e TSCH in an LLN context:
Overview,&nbsp;Problem&nbsp;Statement&nbsp;and&nbsp;Goals
NEW:
Using IEEE802.15.4e TSCH in an IoT context:
Overview,&nbsp;Problem&nbsp;Statement&nbsp;and&nbsp;Goals


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT10

*   For these reasons, the 6LoWPAN working*
*   group has defined an effective adaptation layer [RFC6568].*
*   => I think you mean RFC 4944/6282. RFC 6568 is about LLN use cases*

yes. done


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT11

*   Further issues encompass the auto-configuration of IPv6 addresses*
*   [RFC2464][RFC6755],*
*   => I think you mean RFC 2460 and 4862*

yes. done


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT12

*   Page 4: could you split that very long paragraph?*

yes. done


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT13

*   Regardless of the way it is computed, the Rank monotonically decreases
along*
*   the DODAG towards the destination, building a gradient.*

*   => "towards the root" would be more acurate*

yes. done


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT14

*   As highlighted in Appendix A, TSCH is different for traditional low-*
*   power MAC protocols because of its scheduled nature.*

*   => maybe "differs from" ?*

yes. done


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT15

*   generic name "6TiSCH".*

*   => Unsure it is a good idea to overload 6TiSCH. Could we use the term
LLC*
*   instead when referring to the layer? In 3.1 6TiSCH seems to refer to
the WG,*
*   which IMHO is more proper.*

yes. done


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT16

*   3.  Schedule transmissions of Enhanced Beacons to advertise the*
*       presence of the network.*

*   => only in EBs? We need IEs to negotiate timeslots between peers as
well, and*
*   I understand that these can be in any data frame or ack, correct?*

While IEs can be in other packets, on the EBs can advertise the network to
new motes.


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT17

*   3.  Define rules on when to add or delete links in a particular*
*       slotframe.*

*   => I think we want to use the term CELL here*

yes. done


--------------------

http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#COMMENT18

*   => Please include a  a security section and a IANA section in the end*
*    <section anchor="IANA" title="IANA Considerations">*
*      <t>This memo includes no request to IANA.</t>*
*    </section>*

*    <section anchor="Security" title="Security Considerations">*
*      <t> Security of the join process is described in section blah.*
*      Data frame protection is discussed in section blah.</t>*
*    </section>*

yes. done