Subject: [6tisch] Sheperd's WGLC review for draft-ietf-6tisch-6top-protocol-08

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Sep 2017 10:31:31 +0000

Dear authors:

All in all, I think the document is ready but believe that a pass on language from a native person may help.

Also, the document should include a terminology where all the terms are defined, e.g. NumCandidates and so on.

Still, Please find my comments, with a [PT] tag associated with text snippets, below:

<snip>

Abstract

   This document defines the 6top Protocol (6P), which enables
   distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
   to add/delete TSCH cells to one another.  6P is part of the 6TiSCH
   Operation Sublayer (6top), the next higher layer to the IEEE Std
   802.15.4 TSCH medium access control layer.  The 6top Scheduling
   Function (SF) decides when to add/delete cells, and triggers 6P
   Transactions.  Several SFs can be defined, each identified by a
   different 6top Scheduling Function Identifier (SFID).  This document
   lists the requirements for an SF, but leaves the definition of the SF
   out of scope.  SFs are expected to be defined in future companion
   specifications.

[PT] that's too much text on SF which is out of scope. Enough to say that the 6top sublayer comprises the 6P protocol defined here, and a SF that "decides when to add/delete cells, and triggers 6P Transactions"
This must be repeated in the intro to position 6P vs. 6top vs. SF

<snip>

1.  Introduction

   All communication in a 6TiSCH network is orchestrated by a schedule
   [RFC7554].  This specification defines the 6top Protocol (6P), part
   of the 6TiSCH Operation sublayer (6top).  6P allows a node to
[PT] that's concise! Please introduce that the schedule indicates transmission cells in the [slotOffset,channelOffset] CDU matrix and point at the terminology draft and RFC 7554 for more information.
You'll be needing this a few lines below.

   communicate with a neighbor to add/delete TSCH cells to one another.
   This results in distributed schedule management in a 6TiSCH network.

<snip>

   In the context of this specification, all the cells used by 6top are
   soft cells.  Hard cells can be used for example when "hard-coding" a
   schedule [RFC8180].

[PT] Also ref the 6TiSCH architecture.

<snip>

   The 6P messages exchanged between nodes A and B during a 6P
   Transaction SHOULD be exchanged on dedicated cells between A and B.
   If no dedicated cells are scheduled between nodes A and B, shared
   cells MAY be used.

[PT] Define dedicated, the reader does not necessarily know what is meant here. Do we need a terminology?

<snip>

   A 6P Transaction can consist of 2 or 3 steps.  An SF MUST specify
   whether to use 2-step transactions, 3-step transactions, or both.

[PT] Hum, the fact that 2 step and 3 steps are meant to enable respectively the requester or the responder to allocate the cells should be said clearly here, before 3.1.1.
When the reader is here, he does not figure why there are 2 models.

<snip>

3.1.1.  2-step 6P Transaction

   Figure 4 shows an example 2-step 6P Transaction.  In a 2-step
   transaction, node A selects the candidate cells.  Several elements
   are left out to simplify understanding.

            +----------+                           +----------+
            |  Node A  |                           |  Node B  |
            +----+-----+                           +-----+----+
                 |                                       |
                 | 6P ADD Request                        |
                 |   Type         = REQUEST              |
                 |   Code         = ADD                  |
                 |   SeqNum       = 123                  |
                 |   NumCells     = 2                    |
         timeout |   CellList     = [(1,2),(2,2),(3,5)]  |
           ---   |-------------------------------------->|
            |    |                                       |
            |    | 6P Response                           |
            |    |   Type         = RESPONSE             |
            |    |   Code         = SUCCESS              |
            |    |   SeqNum       = 123                  |
            |    |   CellList     = [(2,2),(3,5)]        |
            X    |<--------------------------------------|
                 |                                       |

                Figure 4: An example 2-step 6P Transaction.

   In this example, the 2-step transaction occurs as follows:

[PT] MAC-layer acks should be shown for completeness, since they are being  used in the logic of the protocol.

<snip>

   6P messages travel over a single hop.  6P messages are carried as
   payload of an IEEE 802.15.4 Payload Information Element (IE)
   [IEEE802154].  The messages are encapsulated with the Payload IE
   Header (per Section 7.4.3 of the [IEEE802154]).  The Group ID is set

[PT] Be careful when citing down to a section. I think that this implies that you place a dated reference to the IEEE spec, like 2015. And you do not want that.
=> I think you have to omit "per Section 7.4.3 of the"

<snip>

  Other Fields:  The list of other fields depends on the type of
         messages, and is detailed in Section 3.3.

[PT] More precisely the other fields are the options below and how they are used is detailed in 3.3, no?

      +-------------+-------------------------------------------------+
      | CellOptions | cells scheduled with A that are to be selected  |
      | Value       | by B when receiving a 6P message from A         |
      +-------------+-------------------------------------------------+
     |TX=0,RX=0,S=0| select all cells                                |
      +-------------+-------------------------------------------------+
      |TX=1,RX=0,S=0| select the cells scheduled marked as RX         |
      +-------------+-------------------------------------------------+
      |TX=0,RX=1,S=0| select the cells marked as TX                   |
      +-------------+-------------------------------------------------+

[PT] Did you mix up RX and TX above?

<snip>

3.2.4.  6P CellList

   A CellList field MAY be present in a 6P ADD Request, a 6P DELETE
   Request, a 6P RELOCATE Request, a 6P Response or a 6P Confirmation.
   It is composed of zero, one or more 6P Cell containers.  The contents
   of the CellOptions field specify the options associated with all
   cells in the CellList.  This necessarily means that the same options
   are associated with all cells in the CellList.

[PT] If a CellList is as I expect the concatenation of 6P Cells, then maybe you should clarify it; also clarify where NumCandidate is found.

<snip>

   The 6P Cell is a 4-byte field, its RECOMMENDED format is:

[PT] Is there another format less RECOMMENDED? If not, just say, "its format is" or something:

<snip>

               [Page 12]

Internet-Draft            6tisch-6top-protocol            September 2017

   Figure 10 defines the format of a 6P ADD Response and Confirmation.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      |     SeqNum    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CellList ...
     +-+-+-+-+-+-+-+-+-

           Figure 10: 6P ADD Response and Confirmation Formats.

   CellList:  A list of 0, 1 or multiple 6P Cells.

   Consider the topology in Figure 1 where the SF on node A decides to
   add NumCells cells to node B.

  Node A's SF selects NumCandidate cells from its schedule as candidate

[PT] First use of NumCandidate. Is that a definition? Should be in introduced and defined better. Maybe a terminology?

<snip>

   In a 2-step 6P RELOCATE Transaction, the candidate CellList MUST
   therefore contain at least NumCells entries.

[PT] No, it must contain exactly NumCells entries; otherwise, how do we know where the first CellList ends?

<snip>

   specified offset.  Node B SHOULD include as many cells as fit in the
   frame.  If the response contains the last cell, Node B MUST set the
   Code field in the response to EOL, indicating to Node A that there no
   more cells that match the request.  Node B MUST return at least one
   cell, unless the specified Offset is beyond the end of B's cell list
   in its schedule.  If node B has less than Offset cells that match the
   request, node B returns an empty CellList and a Code field set to
   EOL.

[PT] define EOL. Is there a table of Codes?

<snip>

3.4.  Protocol Functional Details

3.4.1.  Version Checking

   All messages contain a Version field.  If multiple Versions of the 6P
   protocol have been defined (in future specifications for Version
   values different from 0), a node MAY implement multiple protocol
   versions at the same time.  When receiving a 6P message with a
   Version number it does not implement, a node MUST reply with a 6P
   Response with a Return Code field set to VER_ERR.  The Version field
   in the 6P Response MUST be the same as the Version field in the
   corresponding 6P Request.  In a 3-step transaction, the Version field
   in the 6P Confirmation MUST match that of the 6P Request and 6P
   Response in the same transaction.

[PT] How does the node signal the version it supports? How can it even build a message that matches the version it does not know? I think it should respond with a format that it understands and hat hopefully the requester also understands.

I wonder if there should not be an ERROR message used to report any error. It would be defined in this version and would be mandatory to implement in all further versions with this version number.
For instance, If a node with an old version receives a message with an unknown version, it could return error, wrong version, with the supported version as data.

<snip>

3.4.2.  SFID Checking

Similar, there is now way to enumerate which SFs are supported.

<snip>

   Response with return code BUSY.  In case the requested cells are
   locked, it MUST reply to that request with a 6P Response with return
   code NORES.  The node receiving BUSY or a NORES MAY implement a retry
   mechanism, defined by the SF.

Again, all these codes should have been introduced earlier, at least by a forward pointer to table 34.

<snip>

3.4.4.  Timeout

   A timeout occurs when the node sending the 6P Request has not
   received the 6P Response within a specified amount of time determined
   by the SF.  In a 3-step transaction, a timeout also occurs when the
   node sending the 6P Response has not received the 6P Confirmation.
   The timeout should be longer than the longest possible time it can
   take for the exchange to finish.  The value of the timeout hence
   depends on the number of cells scheduled between the neighbor nodes,
   the maximum number of link-layer retransmissions, etc.  The SF MUST
   determine the value of the timeout.  The value of the timeout is out
   of scope of this document.

Is there a dependency on the value of a timer on one side vs. the other? Eg in a 3-step, do we want the requester to time out first and retry, or the responder to retry his response before the requester times out?

<snip>

3.4.6.2.  Detecting and Handling Schedule Inconsistency
   Inconsistency may happen when L2 acknowledgment of the last packet in
   a transaction is lost, i.e. RESPONSE (in 2-step 6P transaction) or
   CONFIRMATION (in 3-step 6P transaction) have been received on one
   side while timeout happens on the other side.  Take 2-step 6P
   transaction as example, i.e. timeout happens when node B is waiting
   for L2 acknowledgment to its Response message.  Upon the timeout, the
   SF running on the node that timeout (e.g node B) MUST take action to
   validate the schedule state on both sides.

What makes the node decide what the best course is? Shouldn't you RECOMMEND a way?
Isn't the last transaction the one that brings an issue? Can we ask the number of the last transaction on the other side and use to figure if it is the req or the ack that was missed?

<snip>

   inconsistency is detected.  When such inconsistency is detected, node
   B MUST respond with the return code INCON_ERR and the transaction
   MUST be discarded.  It is up to the SF to decide what to do next.
  For example, upon receiving INCON_ERR, node A starts a LIST
   transaction to node B to obtain the scheduled cells with B.

I disagree, it is not up to the SF. The SF asks something, and should be answered whether it happened or not. Trouble and cleaning trouble should be done at 6P.
OTOH, SF needs to know when an action happens like a clear or something, otherwise we have an inconsistency between 6P and SF.
BTW upon a clear that is not on both sides, the right action is probably to clear again, no? After a number of tries, failure means a software issue.

<snip>

4.  Guidelines for 6top Scheduling Functions (SF)

This is more like a dependency, things that SF MUST do. The title above should be changed, and real guidelines should go to appendix (e.g. 4.3)

<snip>

   o  MAY redefine the format of the CellList field.
   o  MAY redefine the format of the CellOptions field.
   o  MAY redefine the meaning of the CellOptions field.

No, all SF knows about Cells is via APIs, not packet formats.
The format on the wire is 6P business. 6P must parse it and it must understand it.
If this is changed, then we need a new protocol version.

<snip>

4.3.  Recommended Structure of an SF Specification

These are guideline that should go in the appendix sc

<snip>

5.  Implementation Status

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC6982].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

The 2 sections above should go.

<snip>

6.  Security Considerations

   6P messages are carried inside 802.15.4 Payload Information Elements
   (IEs).  Those Payload IEs are encrypted and authenticated at the link
   layer through CCM*.  6P benefits from the same level of security as

Nede ref on CCM*

<snip>

   The IANA policy for future additions to this sub-registry is "IETF
   Review or IESG Approval" as described in [RFC5226].

Please reference normatively  https://tools.ietf.org/html/rfc8126 Instead of RFC 5226
Several occurences

<snip>

Voila!

Take care,

Pascal

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 29 Sep 2017 14:12:25 +0200

Thanks Pascal for the feedback. @Xavi, would you have a second to turn
those suggestions into issue on the bitbucket repo?

On Fri, Sep 29, 2017 at 12:31 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> [PT] that’s too much text on SF which is out of scope. Enough to say that
> the 6top sublayer comprises the 6P protocol defined here, and a SF that
> “decides when to add/delete cells, and triggers 6P Transactions”
>
> [PT] that’s concise! Please introduce that the schedule indicates
> transmission cells in the [slotOffset,channelOffset] CDU matrix and point
> at the terminology draft and RFC 7554 for more information.
>
> You’ll be needing this a few lines below.
>
>
>
> [PT] Hum, the fact that 2 step and 3 steps are meant to enable
> respectively the requester or the responder to allocate the cells should be
> said clearly here, before 3.1.1.
>
> [PT] Be careful when citing down to a section. I think that this implies
> that you place a dated reference to the IEEE spec, like 2015. And you do
> not want that.
>
> => I think you have to omit “per Section 7.4.3 of the”
>
>
>
> <snip>
>
>
>
> [PT] If a CellList is as I expect the concatenation of 6P Cells, then
> maybe you should clarify it; also clarify where NumCandidate is found.
>
>
>
> <snip>
>
>
>
>
>
> [PT] Is there another format less RECOMMENDED? If not, just say, “its
> format is” or something:
>
>
>
> <snip>
>
>
>
>
>
>
>
>                [Page 12]
>
>
>
> [PT] First use of NumCandidate. Is that a definition? Should be in
> introduced and defined better. Maybe a terminology?
>
>
>
> <snip>
>
>
>
>
>
>
>
>
>
>
>
> [PT] How does the node signal the version it supports? How can it even
> build a message that matches the version it does not know? I think it
> should respond with a format that it understands and hat hopefully the
> requester also understands.
>
>
>
> I wonder if there should not be an ERROR message used to report any error.
> It would be defined in this version and would be mandatory to implement in
> all further versions with this version number.
>
> For instance, If a node with an old version receives a message with an
> unknown version, it could return error, wrong version, with the supported
> version as data.
>
>
>
> <snip>
>
>
>
>
>
> 3.4.2.  SFID Checking
>
>
>
> Is there a dependency on the value of a timer on one side vs. the other?
> Eg in a 3-step, do we want the requester to time out first and retry, or
> the responder to retry his response before the requester times out?
>
>
>
> <snip>
>
>
>
> What makes the node decide what the best course is? Shouldn’t you
> RECOMMEND a way?
>
> Isn’t the last transaction the one that brings an issue? Can we ask the
> number of the last transaction on the other side and use to figure if it is
> the req or the ack that was missed?
>
>
>
> <snip>
>
>
>
> I disagree, it is not up to the SF. The SF asks something, and should be
> answered whether it happened or not. Trouble and cleaning trouble should be
> done at 6P.
>
> OTOH, SF needs to know when an action happens like a clear or something,
> otherwise we have an inconsistency between 6P and SF.
>
> BTW upon a clear that is not on both sides, the right action is probably
> to clear again, no? After a number of tries, failure means a software issue.
>
>
>
> <snip>
>
>
>
> This is more like a dependency, things that SF MUST do. The title above
> should be changed, and real guidelines should go to appendix (e.g. 4.3)
>
>
>
> <snip>
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 29 Sep 2017 14:30:15 +0200

Hi,

yes I will do it asap.

thanks Pascal for the comments!!
X

2017-09-29 14:12 GMT+02:00 Thomas Watteyne <[email-masked]>:

>> I wonder if there should not be an ERROR message used to report any
>> error. It would be defined in this version and would be mandatory to
>> implement in all further versions with this version number.
>>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 29 Sep 2017 10:20:50 -0300

All,
    Let me chime in. See my coments inline.

Thanks,

                          Diego

>> This must be repeated in the intro to position 6P vs. 6top vs. SF

According to the 6P draft,
The SF has currently 4 main tasks/functions:
- Decide when to add/delete cells
- Decide when to relocate cells
- Keep up-to date statistics on cells
- Define every transaction timeout

I think that if specific items are mentioned in the
introduction, either all or none of them should
be mentioned.

>> When the reader is here, he does not figure why there are 2 models.
It must be specified that this is a fixed definition of the SF by design,
and it cannot be changed dynamically, so this
item must be specified on the SF requirements list.

>> Similar, there is now way to enumerate which SFs are supported.}
>>
>

Agree. Again, the SF requirements list must include "MUST verify that the
SF is supported on the target neighbour", for example

>> the responder to retry his response before the requester times out?

The SF is in charge of the timeout calculation, and it does it in a
per-transaction basis (there is no a single value,
but depends on the transaction). Does an exchange include all the
sequential ADD requests until the whole number
of required cells is satisfied? Is an exchange a single ADD command, for
example? If it is a single ADD command,
why it does depend on the number of cells to be scheduled between neighbour
nodes? Is it because of the packet
size?

>> the req or the ack that was missed?
How can the SF validate the state on both sides?

>> to clear again, no? After a number of tries, failure means a software issue.
I do agree with Pascal on this point too. Unless the SF (on both sides) has
a way to rollback the schedule changes
without affecting other connections (imagine the case when the schedule
version was not updated on the neighbour
and a number of transactions with other neighbours happened before it was
detected), issuing a clear is the best
way of solving the inconsistency. The SF will have to issue a new ADD
command to recover the resources lost.

>> If this is changed, then we need a new protocol version.
I agree with Pascal, at the SF there is still a field where SF-to-SF
messages can be issued (Metadata)

This requires at least a change also on section 3.2.3:

The CellOptions is an opaque set of bits, sent unmodified to the SF.
   The SF MAY redefine the format of the CellOptions bitmap.  The SF MAY
   redefine the meaning of the CellOptions bitmap.

And on section 3.2.4:

The CellList is an opaque set of bytes, sent unmodified to the SF.
   The SF MAY redefine the format of the CellList field.

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Qin Wang <[email-masked]>
Date: Fri, 29 Sep 2017 14:33:24 +0000 (UTC)

Pascal and Diego, thank you very much for your comments.
Xavi, let me know what I can help.
ThanksQin

    On Friday, September 29, 2017 8:30 AM, Xavi Vilajosana Guillen <[email-masked]> wrote:

 Hi,
yes I will do it asap. 
thanks Pascal for the comments!!X
2017-09-29 14:12 GMT+02:00 Thomas Watteyne <[email-masked]>:

Thanks Pascal for the feedback. @Xavi, would you have a second to turn those suggestions into issue on the bitbucket repo?
On Fri, Sep 29, 2017 at 12:31 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:

Dear authors: All in all, I think the document is ready but believe that a pass on language from a native person may help. Also, the document should include a terminology where all the terms are defined, e.g. NumCandidates and so on. Still, Please find my comments, with a [PT] tag associated with text snippets, below: <snip> Abstract    This document defines the 6top Protocol (6P), which enables   distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes   to add/delete TSCH cells to one another.  6P is part of the 6TiSCH   Operation Sublayer (6top), the next higher layer to the IEEE Std   802.15.4 TSCH medium access control layer.  The 6top Scheduling   Function (SF) decides when to add/delete cells, and triggers 6P   Transactions.  Several SFs can be defined, each identified by a   different 6top Scheduling Function Identifier (SFID).  This document   lists the requirements for an SF, but leaves the definition of the SF   out of scope.  SFs are expected to be defined in future companion   specifications. [PT] that’s too much text on SF which is out of scope. Enough to say that the 6top sublayer comprises the 6P protocol defined here, and a SF that “decides when to add/delete cells, and triggers 6P Transactions”This must be repeated in the intro to position 6P vs. 6top vs. SF <snip> 1.  Introduction    All communication in a 6TiSCH network is orchestrated by a schedule   [RFC7554].  This specification defines the 6top Protocol (6P), part   of the 6TiSCH Operation sublayer (6top).  6P allows a node to[PT] that’s concise! Please introduce that the schedule indicates transmission cells in the [slotOffset,channelOffset] CDU matrix and point at the terminology draft and RFC 7554 for more information.You’ll be needing this a few lines below.    communicate with a neighbor to add/delete TSCH cells to one another.   This results in distributed schedule management in a 6TiSCH network. <snip>    In the context of this specification, all the cells used by 6top are   soft cells.  Hard cells can be used for example when "hard-coding" a   schedule [RFC8180]. [PT] Also ref the 6TiSCH architecture. <snip>       The 6P messages exchanged between nodes A and B during a 6P   Transaction SHOULD be exchanged on dedicated cells between A and B.   If no dedicated cells are scheduled between nodes A and B, shared   cells MAY be used. [PT] Define dedicated, the reader does not necessarily know what is meant here. Do we need a terminology?  <snip>     A 6P Transaction can consist of 2 or 3 steps.  An SF MUST specify   whether to use 2-step transactions, 3-step transactions, or both. [PT] Hum, the fact that 2 step and 3 steps are meant to enable respectively the requester or the responder to allocate the cells should be said clearly here, before 3.1.1.When the reader is here, he does not figure why there are 2 models. <snip>  3.1.1.  2-step 6P Transaction    Figure 4 shows an example 2-step 6P Transaction.  In a 2-step   transaction, node A selects the candidate cells.  Several elements   are left out to simplify understanding.               +----------+                            +----------+            |  Node A  |                           |  Node B  |            +----+-----+                            +-----+----+                 |                                        |                 | 6P ADD Request                        |                 |   Type         = REQUEST              |                 |   Code         = ADD                  |                 |   SeqNum       = 123                  |                 |   NumCells     = 2                    |         timeout |   CellList     = [(1,2),(2,2),(3,5)]  |           ---   |----------------------------- --------->|            |    |                                        |            |    | 6P Response                            |           |    |   Type         = RESPONSE             |            |    |   Code         = SUCCESS              |            |    |   SeqNum       = 123                  |           |    |   CellList     = [(2,2),(3,5)]        |            X    |<---------------------------- ----------|                 |                                        |                 Figure 4: An example 2-step 6P Transaction.    In this example, the 2-step transaction occurs as follows:  [PT] MAC-layer acks should be shown for completeness, since they are being  used in the logic of the protocol. <snip>    6P messages travel over a single hop.  6P messages are carried as   payload of an IEEE 802.15.4 Payload Information Element (IE)   [IEEE802154].  The messages are encapsulated with the Payload IE   Header (per Section 7.4.3 of the [IEEE802154]).  The Group ID is set  [PT] Be careful when citing down to a section. I think that this implies that you place a dated reference to the IEEE spec, like 2015. And you do not want that.=> I think you have to omit “per Section 7.4.3 of the” <snip>   Other Fields:  The list of other fields depends on the type of         messages, and is detailed in Section 3.3. [PT] More precisely the other fields are the options below and how they are used is detailed in 3.3, no?       +-------------+--------------- ------------------------------ ----+      | CellOptions | cells scheduled with A that are to be selected  |      | Value       | by B when receiving a 6P message from A         |      +-------------+--------------- ------------------------------ ----+     |TX=0,RX=0,S=0| select all cells                                 |      +-------------+--------------- ------------------------------ ----+      |TX=1,RX=0,S=0| select the cells scheduled marked as RX         |      +-------------+--------------- ------------------------------ ----+      |TX=0,RX=1,S=0| select the cells marked as TX                   |      +-------------+--------------- ------------------------------ ----+ [PT] Did you mix up RX and TX above? <snip>   3.2.4.  6P CellList    A CellList field MAY be present in a 6P ADD Request, a 6P DELETE   Request, a 6P RELOCATE Request, a 6P Response or a 6P Confirmation.   It is composed of zero, one or more 6P Cell containers.  The contents   of the CellOptions field specify the options associated with all   cells in the CellList.  This necessarily means that the same options   are associated with all cells in the CellList. [PT] If a CellList is as I expect the concatenation of 6P Cells, then maybe you should clarify it; also clarify where NumCandidate is found. <snip>     The 6P Cell is a 4-byte field, its RECOMMENDED format is:  [PT] Is there another format less RECOMMENDED? If not, just say, “its format is” or something: <snip>                  [Page 12] Internet-Draft            6tisch-6top-protocol             September 2017     Figure 10 defines the format of a 6P ADD Response and Confirmation.                           1                   2                   3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+     |Version| T | R |     Code      |     SFID      |     SeqNum    |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+     | CellList ...     +-+-+-+-+-+-+-+-+-            Figure 10: 6P ADD Response and Confirmation Formats.    CellList:  A list of 0, 1 or multiple 6P Cells.    Consider the topology in Figure 1 where the SF on node A decides to   add NumCells cells to node B.   Node A's SF selects NumCandidate cells from its schedule as candidate  [PT] First use of NumCandidate. Is that a definition? Should be in introduced and defined better. Maybe a terminology? <snip>        In a 2-step 6P RELOCATE Transaction, the candidate CellList MUST   therefore contain at least NumCells entries.   [PT] No, it must contain exactly NumCells entries; otherwise, how do we know where the first CellList ends? <snip>     specified offset.  Node B SHOULD include as many cells as fit in the   frame.  If the response contains the last cell, Node B MUST set the   Code field in the response to EOL, indicating to Node A that there no   more cells that match the request.  Node B MUST return at least one   cell, unless the specified Offset is beyond the end of B's cell list   in its schedule.  If node B has less than Offset cells that match the   request, node B returns an empty CellList and a Code field set to   EOL.   [PT] define EOL. Is there a table of Codes? <snip>    3.4.  Protocol Functional Details 3.4.1.  Version Checking    All messages contain a Version field.  If multiple Versions of the 6P   protocol have been defined (in future specifications for Version   values different from 0), a node MAY implement multiple protocol   versions at the same time.  When receiving a 6P message with a   Version number it does not implement, a node MUST reply with a 6P   Response with a Return Code field set to VER_ERR.  The Version field   in the 6P Response MUST be the same as the Version field in the   corresponding 6P Request.  In a 3-step transaction, the Version field   in the 6P Confirmation MUST match that of the 6P Request and 6P   Response in the same transaction.  [PT] How does the node signal the version it supports? How can it even build a message that matches the version it does not know? I think it should respond with a format that it understands and hat hopefully the requester also understands.  I wonder if there should not be an ERROR message used to report any error. It would be defined in this version and would be mandatory to implement in all further versions with this version number.For instance, If a node with an old version receives a message with an unknown version, it could return error, wrong version, with the supported version as data. <snip>  3.4.2.  SFID Checking Similar, there is now way to enumerate which SFs are supported. <snip>    Response with return code BUSY.  In case the requested cells are   locked, it MUST reply to that request with a 6P Response with return   code NORES.  The node receiving BUSY or a NORES MAY implement a retry   mechanism, defined by the SF. Again, all these codes should have been introduced earlier, at least by a forward pointer to table 34. <snip>   3.4.4.  Timeout    A timeout occurs when the node sending the 6P Request has not   received the 6P Response within a specified amount of time determined   by the SF.  In a 3-step transaction, a timeout also occurs when the   node sending the 6P Response has not received the 6P Confirmation.   The timeout should be longer than the longest possible time it can   take for the exchange to finish.  The value of the timeout hence   depends on the number of cells scheduled between the neighbor nodes,   the maximum number of link-layer retransmissions, etc.  The SF MUST   determine the value of the timeout.  The value of the timeout is out   of scope of this document.  Is there a dependency on the value of a timer on one side vs. the other? Eg in a 3-step, do we want the requester to time out first and retry, or the responder to retry his response before the requester times out? <snip> 3.4.6.2.  Detecting and Handling Schedule Inconsistency   Inconsistency may happen when L2 acknowledgment of the last packet in   a transaction is lost, i.e. RESPONSE (in 2-step 6P transaction) or   CONFIRMATION (in 3-step 6P transaction) have been received on one   side while timeout happens on the other side.  Take 2-step 6P   transaction as example, i.e. timeout happens when node B is waiting   for L2 acknowledgment to its Response message.  Upon the timeout, the   SF running on the node that timeout (e.g node B) MUST take action to   validate the schedule state on both sides.  What makes the node decide what the best course is? Shouldn’t you RECOMMEND a way?Isn’t the last transaction the one that brings an issue? Can we ask the number of the last transaction on the other side and use to figure if it is the req or the ack that was missed? <snip>    inconsistency is detected.  When such inconsistency is detected, node   B MUST respond with the return code INCON_ERR and the transaction   MUST be discarded.  It is up to the SF to decide what to do next.  For example, upon receiving INCON_ERR, node A starts a LIST   transaction to node B to obtain the scheduled cells with B.  I disagree, it is not up to the SF. The SF asks something, and should be answered whether it happened or not. Trouble and cleaning trouble should be done at 6P.OTOH, SF needs to know when an action happens like a clear or something, otherwise we have an inconsistency between 6P and SF.BTW upon a clear that is not on both sides, the right action is probably to clear again, no? After a number of tries, failure means a software issue. <snip> 4.  Guidelines for 6top Scheduling Functions (SF) This is more like a dependency, things that SF MUST do. The title above should be changed, and real guidelines should go to appendix (e.g. 4.3) <snip>     o  MAY redefine the format of the CellList field.   o  MAY redefine the format of the CellOptions field.   o  MAY redefine the meaning of the CellOptions field.   No, all SF knows about Cells is via APIs, not packet formats.The format on the wire is 6P business. 6P must parse it and it must understand it.If this is changed, then we need a new protocol version. <snip> 4.3.  Recommended Structure of an SF Specification These are guideline that should go in the appendix sc <snip>  5.  Implementation Status    This section records the status of known implementations of the   protocol defined by this specification at the time of posting of this   Internet-Draft, and is based on a proposal described in [RFC6982].   The description of implementations in this section is intended to   assist the IETF in its decision processes in progressing drafts to   RFCs.  Please note that the listing of any individual implementation   here does not imply endorsement by the IETF.  Furthermore, no effort   has been spent to verify the information presented here that was   supplied by IETF contributors.  This is not intended as, and must not   be construed to be, a catalog of available implementations or their   features.  Readers are advised to note that other implementations may   exist.    According to [RFC6982], "this will allow reviewers and working groups   to assign due consideration to documents that have the benefit of   running code, which may serve as evidence of valuable experimentation   and feedback that have made the implemented protocols more mature.   It is up to the individual working groups to use this information as   they see fit".  The 2 sections above should go. <snip>  6.  Security Considerations    6P messages are carried inside 802.15.4 Payload Information Elements   (IEs).  Those Payload IEs are encrypted and authenticated at the link   layer through CCM*.  6P benefits from the same level of security as  Nede ref on CCM* <snip>       The IANA policy for future additions to this sub-registry is "IETF   Review or IESG Approval" as described in [RFC5226]. Please reference normatively  https://tools.ietf.org/html/r fc8126 Instead of RFC 5226Several occurences <snip> Voila! Take care, Pascal  
______________________________ _________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/l istinfo/6tisch

-- 
______________________________ _________
Thomas Watteyne, PhDResearch Scientist & Innovator, InriaSr Networking Design Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-chair, IETF 6TiSCH
www.thomaswatteyne.com______________________________ _________
______________________________ _________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/ listinfo/6tisch

-- 

| Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email-masked]
http://xvilajosana.org
http://wine.rdi.uoc.edu
 |
| Parc Mediterrani de la Tecnologia 
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain |