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

From: "6tisch issue tracker" <[email-masked]>
Date: Fri, 10 Oct 2014 01:15:38 -0000

#27: Pascal's review on draft-ietf-6tisch-tsch-01

 ===== COMMENT 1 =====

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

 ===== COMMENT 2 =====

    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?

 ===== COMMENT 3 =====

    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 ?

 ===== COMMENT 4 =====

    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?

 ===== COMMENT 5 =====

    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.

 ===== COMMENT 6 =====

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

 ===== COMMENT 7 =====

    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"

 ===== COMMENT 8 =====

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

 ===== COMMENT 9 =====

    2.  TSCH in the LLN Context

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

 ===== COMMENT 10 =====

    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

 ===== COMMENT 11 =====

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

 ===== COMMENT 12 =====

    Page 4: could you split that very long paragraph?

 ===== COMMENT 13 =====

    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

 ===== COMMENT 14 =====

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

    => maybe "differs from" ?

 ===== COMMENT 15 =====

    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.

 ===== COMMENT 16 =====

    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?

 ===== COMMENT 17 =====

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

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

 ===== COMMENT 18 =====

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

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-6tisch-
  [email-masked]         |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  tsch                     |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "6tisch issue tracker" <[email-masked]>
Date: Tue, 21 Oct 2014 17:13:03 -0000

Changes (by [email-masked]):

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

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-6tisch-
  [email-masked]         |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  tsch                     |     Version:
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/27#comment:1>
6tisch <http://tools.ietf.org/6tisch/>