Re: [6tisch] Thomas' review of draft-ietf-6tisch-msf-02

[Thomas Watteyne <[e-mail]>]

excellent, thanks 

> De: "tengfei chang" <[e-mail]>
> À: "Thomas Watteyne" <[e-mail]>
> Cc: "6tisch" <[e-mail]>
> Envoyé: Mardi 26 Mars 2019 14:57:05
> Objet: Re: [6tisch] Thomas' review of draft-ietf-6tisch-msf-02

> Thanks for the comments! Generally, all comments are taken.

> I will fix them in the next version!
> Tengfei

> On Mon, Mar 25, 2019 at 7:59 AM Thomas Watteyne < [
> mailto:[e-mail] | [e-mail] ] > wrote:

>> Authors,

>> Please find below my review of draft-ietf-6tisch-msf-02. It's a patch file to
>> the txt version of the draft.

>> You will find inline fixes of typos, and comments, which start at the new line
>> with "TW>"

>> Overall, the draft is in good shape. The recommendations I make are editorial.
>> The biggest remark is that the draft mixes the terms "dedicated cells" and
>> "managed cells". I also would like to see some text that describes the
>> reasoning between "autonomous SHARED cells" and "autonomous non-SHARED cells".
>> Also, because those terms are obscure, you could replace them throughout by
>> "autonomous upstream cells" and "autonomous downstream cells".

>> Thomas

>> =====

>> diff --git
>> "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt"
>> "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt"
>> index 89514c6...49e59bb 100644
>> ---
>> "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt"
>> +++ "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt"
>> @@ -135,10 +135,9 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> The 6TiSCH Minimal Scheduling Function (MSF), defined in this
>> specification, is a 6TiSCH Scheduling Function (SF). The role of an
>> - SF is entirely defined in [RFC8480]: it complements [RFC8480] by
>> + SF is entirely defined in [RFC8480]. This specification complements [RFC8480]
>> by
>> providing the rules of when to add/delete cells in the communication
>> - schedule. The SF defined in this document follows that definition,
>> - and satisfies all the requirements for an SF listed in Section 4.2 of
>> + schedule. This specification satisfies all the requirements for an SF listed
>> in Section 4.2 of
>> [RFC8480].
>> MSF builds on top of the following specifications: the Minimal IPv6
>> @@ -153,11 +152,11 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> the 7 steps described in Section 4. The end state of the join
>> process is that the node is synchronized to the network, has mutually
>> authenticated to the network, has identified a preferred routing
>> - parent, has scheduled one default managed unicast cell (defined in
>> + parent, and has scheduled one default managed unicast cell (defined in
>> Section 5.1) to/from its preferred routing parent. After the join
>> process, the node can continuously add/delete/relocate cells, as
>> described in Section 5. It does so for 3 reasons: to match the link-
>> - layer resources to the traffic, to handle changing parent, to handle
>> + layer resources to the traffic, to handle changing parent, or to handle
>> a schedule collision.
>> MSF is designed to operate in a wide range of application domains.
>> @@ -172,18 +171,19 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> the nodes to the root). Appendix C contains a performance evaluation
>> of MSF.
>> +TW> I would remove this sentence, as Appexdix C might be removed
>> This specification follows the recommended structure of an SF
>> - specification in Appendix A of [RFC8480], with the following
>> + specification, given in Appendix A of [RFC8480], with the following
>> adaptations:
>> - o We have reordered part of the sections, in particular to have the
>> - section on the node behavior at boot Section 4 appear early in
>> + o We have reordered some sections, in particular to have the
>> + section on the node behavior at boot (Section 4) appear early in
>> this specification.
>> o We added sections on the interface to the minimal 6TiSCH
>> - configuration Section 2, the use of the SIGNAL command Section 6,
>> - the MSF constants Section 14, the MSF statistics Section 15, the
>> - performance of MSF Appendix C.
>> + configuration (Section 2), the use of the SIGNAL command (Section 6),
>> + the MSF constants (Section 14), the MSF statistics (Section 15), and the
>> + performance of MSF (Appendix C).
>> o This specification does not include an examples section.
>> 2. Interface to the Minimal 6TiSCH Configuration
>> @@ -193,8 +193,9 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> shared cell providing minimal connectivity between the nodes in the
>> network. The MSF implementation provided in this specification is
>> based on the implementation of the Minimal 6TiSCH Configuration. An
>> - implementor with full-awareness of the Minimal 6TiSCH Configuration
>> + implementor with full awareness of the Minimal 6TiSCH Configuration
>> implications MAY implement MSF without it.
>> +TW> I don't understand the statement "with full awareness of the Minimal 6TiSCH
>> Configuration". Rephrase.
>> MSF uses the minimal cell to exchange the following packets:
>> @@ -203,6 +204,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> 2. DODAG Information Objects (DIOs), defined by [RFC6550], with
>> broadcast type. Unicast type DIOs SHOULD NOT be sent on minimal
>> cell.
>> +TW> just say "broadcast DIOs" and "unicast DIO". "Broadcast type" doesn't mean
>> much.
>> Because the minimal cell is SHARED, the back-off algorithm defined in
>> [IEEE802154-2015] is used to resolve collisions. To ensure there is
>> @@ -214,7 +216,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> 2. send any other broadcast packets on a portion of the minimal
>> cells not exceeding 1/(3(N+1)), where N is the number of
>> neighbors of the node. For example, the broadcast DIO and DIS,
>> - IPv6 Neighbor Discovery (ND)[RFC4861] and any other application
>> + IPv6 Neighbor Discovery (ND) [RFC4861] and any other application
>> layer broadcast packets.
>> @@ -229,8 +231,8 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> The RECOMMENDED behavior for sending EBs is to have a node send EBs
>> with a probability of 1/(3(N+1)). The RECOMMENDED behavior for
>> sending DIOs is to use a Trickle timer with rate-limiting. There is
>> - no recommendation behavior for sending any other broadcast. However,
>> - the traffic portion of all broadcast packets on minimal cell, except
>> + no recommended behavior for sending any other broadcast frame. However,
>> + the traffic portion of all broadcast frames on the minimal cell, except
>> EBs, MUST not exceed 1/(3(N+1)).
>> Section 4.3 describes how to evaluate the number of neighbors during
>> @@ -240,31 +242,33 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> As detailed in Section 2.2 of [RFC8480], MSF MUST schedule cells from
>> Slotframe 1, while Slotframe 0 is used for traffic defined in the
>> Minimal 6TiSCH Configuration. The length of Slotframe 0 and
>> - Slotframe 1 SHOULD be the same value. The default of
>> + Slotframe 1 SHOULD be the same value. The default value of
>> SLOTFRAME_LENGTH is RECOMMENDED for both Slotframe 0 and Slotframe 1,
>> - although any value can be advertised in the EBs.
>> + although any value can be used, and advertised in the EBs.
>> +TW> minimal is not required, yet there is a MUST here. I suggest you start this
>> paragraph by a statement such as "If MSF is used together with the ..."
>> 3. Autonomous Cells
>> MSF nodes MUST initialize Slotframe 1 with a set of default cells for
>> - unicast communication with their neighbors. These cells are referred
>> - to as 'autonomous cells', because they are maintained autonomously by
>> - each node. To distinguish from the autonomous cells, the cell
>> - scheduled by 6P transaction is defined as 'managed cells'. How to
>> + unicast communication with their neighbors.
>> +TW> remove the MUST?
>> + These cells are
>> + called "autonomous cells", because they are maintained autonomously by
>> + each node. Cells
>> + scheduled by 6P transactions are called "managed cells". How to
>> schedule managed cells is detailed in Section 5. For autonomous
>> cells, each node has:
>> - o One cell at a [slotOffset,channelOffset] computed as a hash of the
>> - node's EUI64 (detailed next). The cell options for this cell are
>> + o One cell at a [slotOffset,channelOffset] computed as a hash of its own EUI64
>> (detailed next). The cell options for this cell are
>> TX=1, RX=1, SHARED=0.
>> o One cell at a [slotOffset,channelOffset] computed as a hash of the
>> - EUI64 of the Join Proxy or each neighbor in the IPv6 neighbor
>> - table (detailed in Section 4.4 and Section 4.5). The cell options
>> + EUI64 for each neighbor in the IPv6 neighbor
>> + table, including the Join Proxy (detailed in Section 4.4 and Section 4.5). The
>> cell options
>> for this cell are TX=1, RX=1, SHARED=1.
>> To compute a [slotOffset,channelOffset] from an EUI64 address, nodes
>> MUST use the hash function SAX [SAX-DASFAA]. The coordinates are
>> - computed to distribute the cells across all 16 channel offsets, and
>> + computed to distribute the cells across all channel offsets, and
>> all but the first time offsets of Slotframe 1. The first time offset
>> is skipped to avoid colliding with the minimal cell in Slotframe 0.
>> The slot coordinates derived from a given EUI64 address are computed
>> @@ -272,7 +276,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1)
>> o channelOffset(MAC) = hash(EUI64, 16)
>> -
>> +TW> don't you need a modulo operator here? THe hash function can return a very
>> large number.
>> @@ -282,11 +286,13 @@ Chang, et al. Expires September 12, 2019 [Page 5]
>> Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019
>> - For interoperability purpose, an example how the hash function is
>> + For interoperability purposes, an example how the hash function is
>> implemented is detailed in Appendix B.
>> - Because of hash collisions, there are cases where the autonomous
>> - SHARED and non-SHARED cells are scheduled at the same time offset
>> + Because of hash collisions, there will be cases when the autonomous
>> + SHARED and non-SHARED cells
>> +TW> what do you call "autonomous SHARED and non-SHARED cells"? Do you mean
>> autonomous and managed cells?
>> + are scheduled at the same time offset
>> and/or channel offset. Hash collisions among a set of cells at a
>> given time offset is resolved at run-time as follows:
>> @@ -294,29 +300,33 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> precedence.
>> o If all SHARED cells have empty outgoing queues, the non-SHARED
>> cell takes precedence.
>> +TW> please specify what you mena by SHARED and non-SHARED
>> Both SHARED and non-SHARED autonomous cells are scheduled to transmit
>> unicast packets. The autonomous SHARED cells can only be used to
>> - transmit packets to the neighbor whose EUI64 address is used in hash
>> - function to create this cell. The autonomous non-SHARED cells can be
>> + transmit packets to the neighbor whose EUI64 address is used in the hash
>> + function to schedule this cell. Autonomous non-SHARED cells can be
>> used to transmit packet to any neighbors. The traffic on the
>> autonomous cells are scheduled as:
>> - o The Join Request MUST be sent on a SHARED cell, the 6P Request
>> - packet MAY be sent on a SHARED cell.
>> - o The Join Response MUST be sent on a non-SHARED cell, the 6P
>> - Response packet MAY send on a non-SHARED cell.
>> + o Join Request packets MUST be sent on SHARED cells.
>> + o Join Response packets MUST be sent on non-SHARED cells.
>> + o 6P Request frames MAY be sent on SHARED cells.
>> + o 6P Response frames MAY be sent on non-SHARED cells.
>> Throughout the network lifetime, nodes MUST maintain the autonomous
>> cells as follows:
>> o The non-SHARED cell MUST always remain scheduled.
>> +TW> what do you mean?
>> o Whenever a new IPv6 neighbor is discovered, add a SHARED cell for
>> it.
>> o Whenever an IPv6 neighbor is removed, remove the SHARED cell that
>> was assigned to it.
>> o 6P CLEAR MUST NOT erase autonomous cells.
>> +TW> The whole terminology of shared and non-shared autonomous cells is
>> confusing, as it is used following a paragraph that explains that there are
>> autonomous and managed cells. Please start by explaining, possibly with an
>> example/diagram, what you mean.
>> +
>> 4. Node Behavior at Boot
>> This section details the behavior the node SHOULD follow from the
>> @@ -342,9 +352,10 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> A node implementing MSF MUST implement the Minimal Security Framework
>> for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this
>> - means that a pledge, before being switched on, is pre-configured with
>> + means that a pledge, before being switched on, may be pre-configured with
>> the Pre-Shared Key (PSK) for joining, as well as any other
>> configuration detailed in [I-D.ietf-6tisch-minimal-security].
>> + This is not needed if the node implements a security solution not based on
>> PSKs, such as [draft-ietf-6tisch-dtsecurity-zerotouch-join].
>> 4.2. Step 1 - Choosing Frequency
>> @@ -377,14 +388,15 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> The decision of which neighbor to use as a JP is implementation-
>> specific, and discussed in [I-D.ietf-6tisch-minimal-security].
>> -4.4. Step 3 - Setting up Autonomous Cells during Join Process
>> +4.4. Step 3 - Setting up Autonomous Cells during the Join Process
>> - After selected the JP, nodes MUST set up their autonomous SHARED
>> - cells, as described in Section 3. A Join Request is sent then by
>> - pledge to its JP. The JP forwards the request/response between the
>> - JRC and the JP, possibly over multiple hops. When JP received the
>> - Join Response from JRC, it sends a Join Response to the pledge, where
>> - the pledge learns the keying material used in the network, as well as
>> + After selected a JP, a node MUST set up autonomous SHARED
>> + cells to that JP, as described in Section 3. A Join Request is then sent by
>> the
>> + pledge to its JP. The JP forwards the Join Request to the JRC, possibly over
>> multiple hops.
>> + Similarly, the JRC sends the Join Response to the JP, possibly over multiple
>> hops.
>> + When the JP receive the
>> + Join Response from the JRC, it sends that Join Response to the pledge.
>> + The pledge thereby learns the keying material used in the network, as well as
>> other configurations, and becomes a "joined node". The Join Request
>> @@ -394,31 +406,27 @@ Chang, et al. Expires September 12, 2019 [Page 7]
>> Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019
>> - and Response traffics are happened on the autonomous cells, which are
>> + and Response traffic happens on autonomous cells, which are
>> scheduled as following:
>> - o The Joining Request packet MUST be sent on the autonomous SHARED
>> - cell to the JP by the pledge. A retransmition with backoff
>> - mechanism will be sent later if collision happens.
>> - o The Joining Response packet MUST be sent on the autonomous non-
>> - SHARED cell to the pledge by the JP. A retransmition will be sent
>> - immediately at next autonomous non-SHARED cell if collision
>> - happens.
>> + o The Join Request MUST be sent on the autonomous SHARED
>> + cell the pledge has to the JP. Because it is SHARED, a back-off mechanism
>> kicks in at the plegde when it doesn't receive a link-layer response.
>> + o The Join Response MUST be sent on the autonomous non-
>> + SHARED cell the JP has to be pledge. Because it is non-SHARED, the JP
>> retransmit immediately it case it doesn't receive a link-layer response (i.e.
>> there is no back-off).
>> - After joined, nodes MUST set up their autonomous non-SHARED cell, as
>> - described in Section 3. The root node MUST set up its autonomous
>> - non-SHARED cell when it is configured as root.
>> + After joining, nodes MUST set up their autonomous non-SHARED cell, as
>> + described in Section 3. The root node is consider "joined" as soon as it is
>> configured as root.
>> 4.5. Step 4 - Installing Autonomous Cells for each neighbor in neighbor
>> table
>> Because it has learnt the link-layer keying material used in the
>> - network, the joined node can now decrypt any packets sent by its
>> - neighbors. Once a new neighbor is added to the neighbor table, a new
>> - autonomous SHARED cell MUST be added to that neighbor. The
>> + network, a joined node can decrypt any packets sent by its
>> + neighbors. Once a new neighbor is added a node's neighbor table, the node MUST
>> add
>> + an autonomous SHARED cell to that neighbor. The
>> autonomous SHARED cell MUST be removed if the corresponding neighbor
>> - is removed from the neighbor table. How to decide the neighbors to
>> - keep in neighbor table is implementation-specific.
>> + is removed from the neighbor table. How to decide which neighbors to
>> + remove in the neighbor table is implementation-specific.
>> 4.6. Step 5 - Acquiring a RPL rank
>> @@ -459,6 +467,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> managed unicast cells with that neighbor from its own schedule. In
>> addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at
>> the link-layer). The node MAY be removed from the neighbor table.
>> +TW> some context or condition is missing from this last sentence.
>> If so, the autonomous SHARED cell will be removed following the
>> procedure described in Section 3.
>> @@ -472,10 +481,11 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> o it has identified its preferred routing parent
>> o it has one autonomous non-SHARED cell and a set of autonomous
>> SHARED cells to/from its neighbors
>> +TW> split in multiple bullet points for SHARED and non-SHARED
>> o it is periodically sending DIOs, potentially serving as a router
>> for other nodes' traffic
>> o it is periodically sending EBs, potentially serving as a JP for
>> - new joining nodes
>> + new pledges
>> 5. Rules for Adding/Deleting Cells
>> @@ -526,13 +536,16 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> removed by 6P, so that there always exists an autonomous cell between
>> a node and its preferred parent, even if no frames are being
>> exchanged between them. Autonomous cells are used indistinguishably
>> - together with dedicated cells, for broadcast or unicast traffic with
>> +TW> what do you mean by "used indistinguishably"?
>> + together with dedicated cells,
>> +TW> previously, you used the term managed cells but now dedicated. I suggest
>> you use the term managed throughout
>> + for broadcast or unicast traffic with
>> the target neighbor. The procedure to remove autonomous cells is
>> described in Section 3.
>> Adding/removing/relocating cells involves exchanging frames that
>> - contain 6P commands. All 6P frames MUST be sent on the autonomous
>> - cell or managed cell if the node has.
>> + contain 6P commands. All 6P frames MUST be sent on autonomous
>> + or managed cells.
>> The node MUST maintain the following counters for its preferred
>> parent:
>> @@ -551,9 +564,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> * The node sends a frame to its preferred parent. The counter
>> increments regardless of whether a link-layer acknowledgment
>> was received or not.
>> - * The node receives a frame from its preferred parent. The
>> - frame MUST be able to decrypt with the key assigned during
>> - joining process.
>> + * The node receives a frame from its preferred parent, and unsecuring of that
>> frame is successful.
>> @@ -570,36 +581,39 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> 1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when
>> the node boots.
>> - 2. After End State defined in Section 4.9, if there is no managed
>> - unicast cell to the preferred parent, trigger 6P to add a signle
>> + 2. After the End State defined in Section 4.9, if there is no managed
>> + unicast cell to the preferred parent, trigger 6P to add a
>> cell to it.
>> 3. When the value of NumCellsElapsed reaches MAX_NUMCELLS:
>> * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
>> - single cell to the preferred parent
>> + cell to the preferred parent
>> * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
>> - single cell to the preferred parent
>> + cell to the preferred parent
>> * Reset both NumCellsElapsed and NumCellsUsed to 0 and go to
>> step 2.
>> - To have the counters working, at least one unicast cell need to be
>> + To have the counters working, at least one unicast cell needs to be
>> maintained all the time and never be removed.
>> +TW> OK, so in all cases a node will have 2 cells to its preferred parent: one
>> autonomous, one managed.
>> - The reason why the counter only counts the managed unicast cell, NOT
>> - including the autonomous SHARED cell is to avoid the effects of
>> - collision. If the autonomous SHARED cell is counted as well,
>> + The reason why the counter only counts managed unicast cell (NOT
>> + autonomous SHARED cells) is to avoid the effect of
>> + collisions. If autonomous SHARED cell were counted as well,
>> NumCellsUsed > LIM_NUMCELLSUSED_HIGH could be caused by the collision
>> - on the cell. A 6P add request on the autonomous SHARED cell will
>> + on the cell. A 6P add request on the autonomous SHARED cell would
>> make the collision even worse.
>> Both NumCellsElapsed and NumCellsUsed counters can be used to cell
>> +TW> something missing
>> with cell option TX=1 or RX=1. With the rules defined above, the
>> - cell to add or remove can be transmitting cell or receiving cell
>> + cell to add or remove can be a transmitting or receiving cell
>> according to which type of cell the two counters are used for.
>> +TW> don't understand.
>> - Similar to Join Request and Response, the 6P Request is scheduled to
>> - send on the autonomous SHARED cell to the node's parent. The 6P
>> - Response is scheduled to send back on the autonomous non-SHARED cell
>> + Similar to Join Request and Response messages, 6P Request frames are
>> + sent on the autonomous SHARED cell to the node's parent. The 6P
>> + Response is sent back on the autonomous non-SHARED cell
>> to the node.
>> 5.2. Switching Parent
>> @@ -607,7 +621,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> A node implementing MSF SHOULD implement the behavior described in
>> this section.
>> - Part of its normal operation, the RPL routing protocol can have a
>> + As part of its normal operation, the RPL routing protocol can have a
>> node switch preferred parents. The procedure for switching from the
>> old preferred parent to the new preferred parent is:
>> @@ -619,7 +633,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> 1. if the new parent is not in the neighbor table, the autonomous
>> - SHARED cell MUST be added as defined in Section 3
>> + SHARED cell MUST be added, as defined in Section 3
>> 2. the node counts the number of managed unicast cell cells it has
>> per slotframe to the old preferred parent
>> 3. the node triggers one or more 6P ADD commands to schedule the
>> @@ -636,6 +650,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> Since scheduling is entirely distributed, there is a non-zero
>> probability that two pairs of nearby neighbor nodes schedule a
>> managed unicast cell at the same [slotOffset,channelOffset] location
>> +TW> why "managed unicast"? why not simply "managed"?
>> in the TSCH schedule. In that case, data exchanged by the two pairs
>> may collide on that cell. We call this case a "schedule collision".
>> @@ -817,6 +832,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF)
>> March 2019
>> quarantine, drop all frames received from that node.
>> waitretry: Abort the 6P Transaction. Wait for a duration randomly
>> and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX].
>> +TW> these names are a bit obscure. Use WAITRETRYDURATION_MIN and
>> WAITRETRYDURATION_MAX?
>> Retry the same transaction.
>> 13. Schedule Inconsistency Handling
>> @@ -1020,10 +1036,10 @@ Appendix B. Example of Implementation of SAX hash
>> function
>> o c, which is the characters of string s, to be hashed
>> In MSF, the T is replaced by the length slotframe 1. String s is
>> - replaced by the mote EUI64 address. The characters of the string c0,
>> + replaced by the mote's EUI64 address. The characters of the string c0,
>> c1, ..., c7 are the 8 bytes of EUI64 address.
>> - The SAX hash function requires shift operation which is defined as
>> + The SAX hash function requires a shift operation which is defined as
>> follow:
>> o L_shift(v,b), which refers to left shift variable v by b bits

>> _______________________________________________
>> 6tisch mailing list
>> [ mailto:[e-mail] | [e-mail] ]
>> [ https://www.ietf.org/mailman/listinfo/6tisch |
>> https://www.ietf.org/mailman/listinfo/6tisch ]

> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer , Inria