Dear Pascal,
find below our answers (XV:) :
---------------------------------
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>
XV: Done
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.
XV: Done
communicate with a neighbor to add/delete TSCH cells to one another.
This results in distributed schedule management in a 6TiSCH network.
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?
XV: It is already in the terminology draft.
<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.
XV: clarified this part.
A 6P Transaction can consist of 2 or 3 steps.
A 2-step transaction is used when node A selects the cells to be allocated.
A 3-step transaction is used when node B selects the cells to be
allocated.
<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.
XV: Done
<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”
XV: fixed - removed the specific section.
<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?
XV: yes this has been clarified.
+-------------+-------------------------------------------------+
| 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?
XV: No, the query is from the point of view of the 6P requester (say it A).
THis is, if I want to know what cells has the counterpart (B) that on A
side are TX, B would respond the RX cells from A in B's schedule.
<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.
XV: the text has been clarified.
<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:
XV: Done
<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?
XV: has been introduced here.
<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?
XV: this has been corrected.
<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?
XV: Yes below. Figure 36.
<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.
XV: this has been clarified as per discussion had during the interin
meeting in September.
<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.
XV: A pointer to figure 36 have been added.
<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?
XV: the inconsistency handling section have been improved. Yet, the draft
lists the possible actions to be taken to determine what is wrong. Is the
SF who has to decide what to do.
<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.
XV: the SF asks something and eventually 6P detects the possible
inconsistency and notifies the SF. The SF then needs to take action to
correct the problem.
<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>
XV: this section has been renamed to Requirements for 6top Scheduling
Functions (SF). THe rest has been moved to appendix as indicated.
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
XV: DONE
<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.
XV: THey are in the appendix now.
<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*
XV: DONE
<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
`
XV: DONE
-----------------------------
2017-09-29 12:31 GMT+02:00 Pascal Thubert (pthubert) <[email protected]>:
> 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
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
--
Dr. Xavier Vilajosana
Wireless Networks Lab
*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email protected] <[email protected]>
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
[image: Universitat Oberta de Catalunya]
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Libre
de virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
