Re: [6tsch] comments unpublished draft-vilajosana-6tisch-minimal-00.txt

[Xavier Vilajosana Guillen <[e-mail]>]

thanks Thomas for the exhaustive review! I will address your comments
tomorrow.

regards,
Xavi


On Mon, Sep 30, 2013 at 8:58 PM, Thomas Watteyne <[e-mail]
> wrote:

> Xavi, Kris,
>
> Per the last 6TiSCH webex on Friday, I reviewed the unpublished version
> of draft-vilajosana-6tisch-minimal-00, in particular the file
> https://bitbucket.org/6tsch/draft-vilajosana-6tsch-basic/src/3ead236bdc563747fea826e8d632fd99f3bb868e/draft-vilajosana-6tisch-minimal-00.txt?at=master.
> You will find the remarks below.
>
> Thomas
>
> ----
>
> Remarks:
>
>    1. In the abstract, you might consider indicating that the minimal
>    configuration can be used for more than interop testing. Example rewording:
>    "This minimal mode of operation can be used during network bootstrap, as a
>    fallback mode of operation when no dynamic scheduling solution is available
>    or functioning, or during early interoperability testing and development".
>    2. Similarly, I would highlight these cases also in the introduction,
>    maybe providing one sentence per case. A reference
>    to draft-ietf-roll-rpl-industrial-applicability might be appropriate at
>    that point.
>    3. "[IEEE802154e] provides a mechanism whereby the details of
>    slotframe length, timeslot timing, and channel hopping pattern are
>    communicated to a node during initial synchronization". I believe the EB
>    can also indicate the cells to use.
>    4. "the radio of the nodes remains off." You might want to indicate
>    that those 95 timeslots are available for a dynamic scheduling solution.
>    5. in the "Minimal schedule overview" figure, why "TxRxS" and not
>    simply "TxRx"?
>    6. "All scheduled cells in the minimal schedule are configured as Hard
>    cells [I-D.watteyne-6tsch-tsch-lln-context][I-D.draft-wang-6tsch-6top]
>    since reallocation is not considered in that simple approach." That's not
>    strictly true if we consider a dynamic scheduling approach can schedule the
>    remaining 95 slots. Maybe specify that the cell allocated by this document
>    are hard cells, but that this does not necessarily apply to any additional
>    cells scheduled by a dynamic scheduling solution.
>    7. Unscheduled cells should not occupy any memory -> Unscheduled cells
>    SHOULD NOT occupy any memory
>    8. the transmissions is considered failed at the MAC layer, and the
>    upper layer needs to be notified -> the transmissions is considered failed
>    and the MAC layer MUST notify the upper layer
>    9. 2.4.  Time Slot timing is redundant
>    with draft-watteyne-6tsch-tsch-lln-context. We could consider moving the
>    diagram and text to that draft, and leave just the table in this draft,
>    together with a reference to the draft-watteyne-6tsch-tsch-lln-context.
>    Thoughts welcome.
>    10. "this document recommends to hard-code the different durations to
>    the values listed below." This it not strictly true, since the intro says
>    that one can dynamically learn through the EB. Please say the same in this
>    text.
>    11. it is recommended to sent EBs at least once every 10s -> a mote
>    SHOULD send an EB every 10s
>    12. EBs must be sent with the Beacon IEEE802.15.4 frame type -> EBs
>    MUST be sent with the Beacon IEEE802.15.4 frame type
>    13. "this document recommends that they carry the following
>    Information Elements (IEs)". Since nodes can either hard-code or learn on
>    the fly, I believe the list of IEs is a MUST.
>    14. Section 3 contains the value of all fields. Please specify that
>    this is redundant with [IEEE802.15.4e]
>    and [I-D.watteyne-6tsch-tsch-lln-contex], and provided here for clarity.
>    15. In 3.1.2., what's the value of Join Priority?
>    16. "each node SHOULD indicate the schedule in each EB through a Frame
>    and Cell IE". Per discussion above, maybe MUST?
>    17. please give each neighbor statistics a name, e.g. numTx
>    18. "Neighbour address". Which address? EUI, IPv6, both?
>    19. Per last call use timestamp rather than ASN in "Timestamp when
>    that neighbour was heard for the last time. This can be based on the ASN
>    counter or any other time base."
>    20. "Connectivity statistics (RSSI, LQI, etc),". I would simply RSSI,
>    since LQI is not well defined.
>    21. "Each node selects at least one time parent amongst its known
>    neighbours." I suggest "Each node MUST select a time source neighbor among
>    the neighbors in its RPL routing parent set"
>    22. PAN coordinator is an old term. Let's use the term DAG root.
>    23. "it is NOT allowed" -> "is MUST NOT" (NOT cannot be used alone)
>    24. "start advertising the network" -> "send EBs"
>    25. I would remove "e.g RSSI when the EB has been received as no other
>    metrics are available at that moment"
>    26. Strictly speaking, "time parent" does not exist. Please use the
>    term "time source neighbor"
>    27. "A backup time parent can also be selected (as required by RPL and
>    described in Section 7.1 following the same rule)." It is unclear how that
>    backup is used. What you could say is that, if connectivity to the time
>    source neighbor is lost, a new time source neighbor MUST be chosen among
>    the neighbor in the RPL routing parent set.
>    28. I understand "Optionally, a node [...] selected" is about
>    hysteresis. As is, it is not clear what exactly is defined. I would simply
>    state that "some form of hysteresis SHOULD be implemented to avoid frequent
>    changes in time source neighbors"
>    29. "Lower-layer packets " -> "Frames generated by the MAC layer (e.g.
>    EBs and ACK)"
>    30. "A minimal TSCH configuration [...] tests" is WAY to verbose.
>    Please reword by something as simple as "Nodes in the network MUST use the
>    RPL routing protocol".
>    31. Same thing for the long intro to Section 7.1.
>    32. In 7.1.1, I would not repeat RFC6552, just state that a mote MUST
>    use step_of_rank as 2*ETX
>    33. "This information can be extracted from the neighbours information
>    described in Section 5.1." Please replace by equation based on counters.
>    34. I would keep 7.1.2, which helps clarify.
>    35. Same for 7.2.2, please remove repeats, and list simply the
>    configuration.
>    36. If possible, please federate the discussion about hysteresis for
>    both the routing and time source selection, since it's one and the same
>    thing.
>    37. What's the recommended value for PARENT_SWITCH_THRESHOLD?
>
> Minor remarks (*a* means add, **a** means remove, please use Ctrl+F to
> find):
>
>    1. Number of time slots per **Slotframe** *slotframe*
>    2. Amendament->Amendment
>    3. Number of EB**s** cells
>    4. These EBs *sent to the broadcast MAC address and* are not
>    acknowledged
>    5. Per the [IEEE802154e] **TSCH** standard
>    6. options below that -> options below, which
>    7. set,* *in
>    8. in presence of collisions it uses the back-off mechanism defined in
>    [IEEE802154e] -> the back-off mechanism defined in [IEEE802154e] is used to
>    resolve contention
>    9. node (RX), and a MAC -> node (RX). A MAC
>    10. fully to **be able to** configure
>    11. Size Slotframe (b32-b47) = 0x65 *(101)*
>    12. "Slot Number (2B) = from (0x00 to 0x05)" why the parenthesis?
>    13. Time Synch*ronization* information
>    14. "but it should at least contain the following information, for
>    each neighbour" -> "it SHOULD contain the following information for each
>    neighbor"
>    15. RPL objective function (OF) -> RPL Objective Function (OF)
>    16. "parent, uses the Join Priority" -> parent, it uses the Join
>    Priority
>    17. of **the** [IEEE802154e]
>    18. i.e*.* EBs sent
>    19.  When a nodes Joins -> When a node joins
>    20. " The later aims to avoid" -> "The latter avoids"
>    21. match*es* RPL topology
>    22. it is allowed to send Enhanced Beacons -> it SHOULD send Enhanced
>    Beacons
>    23. In case of a node receiving EBs -> In case a node receives EBs
>    24. a*n* IEEE802.15.4
>    25. Watteyene -> Watteyne
>
> administrative remark:
>
>    1. the repository is now called draft-vilajosana-6tsch-basic. Please
>    rename to draft-vilajosana-6tisch-minimal. You might want to give people
>    48h notice in case they have it cloned.
>    2. please use the bitbucket issue tracker built into your repository
>    to track these remarks.
>
> Remarks about the XML file:
>
>    1. While I reviewed the TXT version, I took the liberty to look at the
>    XML file.
>    2. For homogeneity with the other 6TiSCH drafts, please replace tabs
>    by 3 spaces, especially in figures. This should also fix indentation issues.
>    3. The draft-wang-6tsch-6top is published. Please replace the explicit
>    reference to "I-D.draft-wang-6tsch-6top" accordingly. This will also ensure
>    the correct I-D version.
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>