Subject: [6tisch] Pascal's review on draft-ietf-6tisch-tsch-01

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Oct 2014 16:56:19 +0000

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

      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?

   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 ?
   
   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?
   
      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.   
   
   => Please expand the acronyms on first use: 
   the Constrained Application Protocol (CoAP)
   the IPv6 Routing Protocol for Low power and Lossy Networks (RPL)

   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"

   => 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>

   2.  TSCH in the LLN Context
   
   => Shouldn't that be "IP over TSCH" or "TSCH in an IoT context"

    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

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

   Page 4: could you split that very long paragraph?
   
   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

      As highlighted in Appendix A, TSCH is different for traditional low-
   power MAC protocols because of its scheduled nature.
   
   => maybe "differs from" ?

   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.

   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?

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

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

   => 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>

Cheers;

Pascal

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 9 Oct 2014 18:17:53 -0700

Pascal,

I realized I hadn't answered yet! Absolutely beautiful, thanks a million
for the detailed and constructive comments. I'm tracking this at
http://tools.ietf.org/wg/6tisch/trac/ticket/27 and am preparing an update
of the doc.

Let's discuss the proposed changes at the 6TiSCH call tomorrow.

Thomas

On Tue, Oct 7, 2014 at 9:56 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>