Address Comments

Remarks:

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".
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.
"[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.
"the radio of the nodes remains off." You might want to indicate that those 95 timeslots are available for a dynamic scheduling solution.
in the "Minimal schedule overview" figure, why "TxRxS" and not simply "TxRx"?
"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.
Unscheduled cells should not occupy any memory -> Unscheduled cells SHOULD NOT occupy any memory
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
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.
"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.
it is recommended to sent EBs at least once every 10s -> a mote SHOULD send an EB every 10s
EBs must be sent with the Beacon IEEE802.15.4 frame type -> EBs MUST be sent with the Beacon IEEE802.15.4 frame type
"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.
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.
In 3.1.2., what's the value of Join Priority?
"each node SHOULD indicate the schedule in each EB through a Frame and Cell IE". Per discussion above, maybe MUST?
please give each neighbor statistics a name, e.g. numTx
"Neighbour address". Which address? EUI, IPv6, both?
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."
"Connectivity statistics (RSSI, LQI, etc),". I would simply RSSI, since LQI is not well defined.
"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"
PAN coordinator is an old term. Let's use the term DAG root.
"it is NOT allowed" -> "is MUST NOT" (NOT cannot be used alone)
"start advertising the network" -> "send EBs"
I would remove "e.g RSSI when the EB has been received as no other metrics are available at that moment"
Strictly speaking, "time parent" does not exist. Please use the term "time source neighbor"
"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.
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"
"Lower-layer packets " -> "Frames generated by the MAC layer (e.g. EBs and ACK)"
"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".
Same thing for the long intro to Section 7.1.
In 7.1.1, I would not repeat RFC6552, just state that a mote MUST use step_of_rank as 2*ETX
"This information can be extracted from the neighbours information described in Section 5.1." Please replace by equation based on counters.
I would keep 7.1.2, which helps clarify.
Same for 7.2.2, please remove repeats, and list simply the configuration.
If possible, please federate the discussion about hysteresis for both the routing and time source selection, since it's one and the same thing.
What's the recommended value for PARENT_SWITCH_THRESHOLD?

Minor remarks (a means add, a means remove, please use Ctrl+F to find):

Number of time slots per **Slotframe** *slotframe*
Amendament->Amendment
Number of EB**s** cells
These EBs *sent to the broadcast MAC address and* are not acknowledged
Per the [IEEE802154e] **TSCH** standard
options below that -> options below, which
set,* *in
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
node (RX), and a MAC -> node (RX). A MAC
fully to **be able to** configure
Size Slotframe (b32-b47) = 0x65 *(101)*
"Slot Number (2B) = from (0x00 to 0x05)" why the parenthesis?
Time Synch*ronization* information
"but it should at least contain the following information, for each neighbour" -> "it SHOULD contain the following information for each neighbor"
RPL objective function (OF) -> RPL Objective Function (OF)
"parent, uses the Join Priority" -> parent, it uses the Join Priority
of **the** [IEEE802154e]
i.e*.* EBs sent
 When a nodes Joins -> When a node joins
" The later aims to avoid" -> "The latter avoids"
match*es* RPL topology
it is allowed to send Enhanced Beacons -> it SHOULD send Enhanced Beacons
In case of a node receiving EBs -> In case a node receives EBs
a*n* IEEE802.15.4
Watteyene -> Watteyne

administrative remark:

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.
please use the bitbucket issue tracker built into your repository to track these remarks.

Remarks about the XML file:

While I reviewed the TXT version, I took the liberty to look at the XML file.
For homogeneity with the other 6TiSCH drafts, please replace tabs by 3 spaces, especially in figures. This should also fix indentation issues.
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.

Comments (1)