This e-mail lists the different comments about draft-ietf-6tisch-minimal-12
received as part of the initial review of the document.
To progress the work, I have put a discussion after each point, and
included a recommended change.
- @Editor action items are for the editor
- @WG indicates we need to poll the WG
- @AD remarks are for our AD
- @Chairs are action points for 6TiSCH co-chairs
Please send further remarks by replying to this thread.
Thomas
###############################################################################
################### Suresh Krishnan [INT area directorate]
###############################################################################
Summary:
The draft is almost ready for publication but I have two comments that you
may want to address.
Major
=====
* Intended Status:
This looks more like a recommended set of network configuration parameters
than a new protocol definition. Has the wg considered whether the Proposed
Standard status is appropriate (as opposed to Info or BCP)?
TW> Ideally, we'd like to keep the "proposed standard" track as:
TW> - 6TiSCH builds upon it as a foundation
TW> - this spec is to be followed for interoperation
TW> We need to poll the WG on this.
TW> @WG, we will discuss this at the IETF94 6TiSCH WG meeting.
TW> @AD, we welcome your input/recommendation on this decision.
* Section 10.1.1
I have a question about the Sp computation. Looks like the Sp value needs to
be between 1 and 9. In my view, the recommended method (3*ETX)-2 yields
values between 1 and 10. This needs to be fixed.
This is how I see it.
On a very high quality link, if there are no retransmissions required ETX
will be 1/1 => 1. Sp will be (3*1)-2 => 1
On a very poor quality link where the packet only gets through after the
full
3 retries ETX will be 4/1 => 4. Sp will be (3*4)-2 => 10.
Is my calculation correct?
TW> I'll let Pascal and Xavi comment.
Editorial
=========
Section 3.2
s/maintin/maintain/
TW> Editorial.
TW> @Editor, please fix.
Section 3.3
s/if none is/if none are/
TW> Editorial.
TW> @Editor, please fix.
###############################################################################
################### Brian Haberman [INT area AD]
###############################################################################
* Meta : The document should be consistent in the use of SHOULD vs.
RECOMMENDED and MUST vs. SHALL. Pick one nomenclature and stick with it.
TW> Editorial.
TW> @Editor, please fix.
* Meta : Suresh raised this same point, but I want to echo it. Is
Standards Track the approach the WG wants to proceed with this document?
Do you expect this to advance to Internet Standard at some point?
Would Best Current Practice be a better fit if it is expected that the
advice will change?
TW> Same comment from Suresh above.
TW> We need to poll the WG on this.
TW> @WG, we will discuss this at the IETF94 6TiSCH WG meeting.
TW> @AD, we welcome your input/recommendation on this decision.
* Meta : Using a direct reference (e.g., [IEEE802154]) as a noun is not
the correct way to reference other works. I prefer seeing the reference
at the end of the sentence as is required in many journals and
conferences. For example, in the Introduction, I would make the
following change:
OLD:
[IEEE802154] provides a mechanism whereby the
details of slotframe length, timeslot timing, and channel hopping
pattern are communicated when a node synchronizes to the network.
NEW:
The IEEE 802.15.4 specification provides a mechanism whereby the
details of slotframe length, timeslot timing, and channel hopping
pattern are communicated when a node synchronizes to the network
[IEEE802154].
This occurs in many places in the draft and should be changed.
TW> Editorial.
TW> @Editor, please fix.
* Meta : All the figures should be numbered and referenced by number in
the text.
TW> Editorial.
TW> @Editor, please fix.
* Meta : All acronyms should be expanded on first use.
TW> Editorial.
TW> @Editor, please fix.
* Introduction
1. I don't think 2119 keywords make sense in an introduction.
TW> Editorial.
TW> @Editor, please fix.
2. What constitutes a TSCH-compliant network? Is RPL required in order
to be compliant?
TW> RPL is not required in order to be compliant with IEEE802.15.4e TSCH.
TW> I recommend to use the following language:
TW> In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be
used.
TW> @Editor, please fix.
* Section 3 : What exactly is a "minimum schedule configuration"?
TW> Editorial.
TW> @Editor, please add definition.
* Section 3.1
1. s/length, and which repeats/length that repeats/
TW> Editorial.
TW> @Editor, please fix.
2. The text says that there is only a single active slot in slotframe,
but the figure indicates that the number of slots is variable. Why
aren't these consistent?
TW> Both concepts are not contradictory. In a slot frame with N slots:
TW> - 1 slot is scheduled, i.e. used for sending/receiving frames
TW> - N-1 slots are not scheduled, i.e. the radio of the nodes stays off
TW> You comment shows this isn't clear.
TW> @Editor, can you propose a rewording?
3. I don't understand this sentence : "The active slot MAY be
scheduled at the slotOffset 0x00 and channelOffset 0x00..." Does this
mean it can really be scheduled anywhere and the nodes will find it
since it is advertised in the EB?
TW> Yes, that is correct. We want an implementor to have the freedom to
TW> have the active slot scheduled at a different slotOffset and
channelOffset.
TW> The EB contains that information.
TW> You comment shows this isn't clear.
TW> @Editor, can you propose an extra sentence to make this clear?
4. The text mentions slotframe length but provides no definition or
reference for it.
TW> Editorial.
TW> @Editor, could you add a reference to IEEE802.15.4e and a definition.
TW> @Editor, please coordinate with the editor of
draft-ietf-6tisch-terminology to add a definition for "Slotframe Length"
5. The text RECOMMENDS a default slot duration of 10ms. I don't see a
slot duration in the accompanying figure. What if an implementation
chooses a different duration?
TW> In that case, the EB would contain that slot duration explicitly
(through
TW> a set of fields called "TSCH Timeslot" payload IE).
TW> You comment shows this isn't clear.
TW> @Editor, can you propose an extra sentence to make this clear?
* Section 3.2 : The 2nd paragraph starts with "... bitmap of cell
options below." Not sure how to follow the "below" directive.
TW> Editorial.
TW> @Editor, please fix.
* Section 3.3 : I would like to see a little bit of discussion on how
the number of re-transmits affect minimal operation.
TW> That's an important point, indeed. I suggest we add a subsection in
TW> Section 3 (called "Retransmissions") which states:
TW> - the link layer provides a max number of retries
TW> - that affect the use of the scheduled slot.
TW> @Editor, could you propose new text to that effect?
* Section 3.4
1. There are a bunch of declarative statements in this section (e.g.,
"The radio of the RX node is turned on tsRxWait/2..."). Do these need to
be re-worded with 2119 keywords?
TW> IMO, no. These are describing the IEEE802.15.4e TSCH operation, rather
TW> than specifying something new. Yes, an implementation must follow these
TW> rules, but these rules are dictated by IEEE802.15.4e TSCH, no by
TW> draft-ietf-6tisch-minimal-12.
TW> @AD, we welcome your input/recommendation.
2. It is unclear to me where to find the description of CCA.
TW> Editorial.
TW> @Editor, please provide a description and coordinate with the Editor of
the terminology draft to add one.
* Section 4
1. *How* does an implementer indicate in the corresponding Frame
Control field that the source address contains an extended address?
TW> There is a bitmap in the FCF which indicates the length of the different
TW> addresses. We could indicate this precisely in this draft, but we
believe
TW> this is well-know for IEEE802.15.4 implementers, and would rather
TW> not repeat too much information from IEEE802.15.4.
TW> @AD, we welcome your input/recommendation.
2. There are a couple of instances of lower-case "shall". Should
those be interpreted as SHALL/MUST?
TW> Editorial.
TW> @Editor, please fix.
3. There is reference to a Table 2a. Is that a table in the 802.15.4
spec? Some clarity is needed.
TW> Editorial.
TW> Yes, it's a table in the IEEE802.15.4e-2012 standard.
TW> @Editor, please fix.
4. I see ASN and immediately think "Autonomous System Number", but I
don't think you mean that.
TW> No. We mean "Absolute Slot Number".
TW> It is already present in draft-ietf-6tisch-terminology-06.
TW> @Editor, please spell out in the first occurrence (it is not).
* Section 5
1. s/EBs MUST NOT in general/EBs MUST NOT/
TW> Editorial.
TW> @Editor, please fix.
2. How does the discussion of the TSCH Timeslot IE relate to the
discussion in section 3.1?
TW> It does not really. The "TSCH Timeslot IE" is used to indicate the
duration
TW> of the timeslot to use, and does not indicate anything about which
timeslot
TW> in the slotframe to use.
TW> @Editor, could you add a sentence to that effect?
3. Is the 2.4GHz OQPSK Phy the only phy supported by 6tisch-minimal?
TW> No. Any PHY which IEEE802.15.4e support is supported by 6tisch-minimal.
TW> 2.4GHz OQPSK happens to be the most popular today, but IEEE802.15.4e was
TW> written so it would "work" on different PHYs, including future ones.
TW> @Editor, please add a sentence to that effect in Section 3.
* Section 7 : I am left wondering how the neighbor information
maintained by a node/mote affects interoperability. A brief sentence or
two would go a long way to motivate this section.
TW> Agreed. This sentence should go in the intro paragraph of Sections 7.1.
TW> Something like this:
TW> "Future version of the 6top Protocol [LINK] might require those
statistics."
TW> @Editor, please add that sentence.
* Section 9
1. s/Section Section 5/Section 5/
TW> Editorial.
TW> @Editor, please fix.
2. I am really confused on how the management of K1 and K2 are
supposed to work given all the optional language here. K1 could be equal
to K2. K1 MAY be some value. I know there is ongoing discussion on the
key management subject, but I suspect that this text will get very
interesting comments from Sec-Dir reviewers.
TW> You are right, this text has been changing and changing based on the
discussions
TW> and walks through a minefield. We expect a person deploying to set K1
and K2 to some
TW> arbitrary value if no KMP is present. The default value of K1 is there
to allow
TW> interop events.
TW> @AD, advice on rewording is welcome.
* Section 10.1.1
1. Is all of this needed if it is already in RFC 6552?
TW> The intro text describing the different elements are not strictly
needed, but
TW> the recommendation we make are.
TW> I would suggest we have a newline when we transition from the intro
text and
TW> recommendation from this spec. We can then decide whether we remove the
intro text.
TW> @Editor, please make that change.
2. I am curious as to what happens if a node/mote does not use a
rank_factor of 1. Does the Earth stop rotating?
TW> I'll let Pascal and Xavi comment.
3. OF0 = Objective Function 0?
TW> Editorial.
TW> @Editor, please spell out OF0.
* Section 10.2 : s/these MUST obey to/these MUST follow/
TW> Editorial.
TW> @Editor, please fix.
* Section 10.2.1 : Does "MUST support" imply "MUST use"?
TW> No, motes could be using storing mode only.
* Section 10.2.4 : The text says the variables are defined in the
previous section, but the variables are actually defined in different
sections.
TW> Editorial.
TW> @Editor, please fix.
* Section 11
1. s/the IEs the form/the IEs that form/
TW> Editorial.
TW> @Editor, please fix.
2. s/the later has/the latter has/
TW> Editorial.
TW> @Editor, please fix.
###############################################################################
################### Ralph Droms [INT area directorate]
###############################################################################
Summary: In my opinion, the WG needs to reconsider some of the
fundamental aspects of this proposed specification, and the document
needs significant restructuring and editing. I will be happy to work
with the WG to revise the document and review future revisions.
There may be overlaps between my comments and those in other reviews
because I avoided reading those reviews before writing up my review.
Here are my comments on the document. The first four comments apply
to the document as a whole, while the remainder address more specific
issues, roughly in the order of appearance in the document.
1. Goals and requirements are unclear
The requirements for this document are unclear to me. Exactly what
services would a "minimal mode of operation" provide? The Abstract
and most of the document talks about the operation of an IEEE 802.15.4
TSCH network, yet the title of the document is "Minimal 6TiSCH
Configuration". Does a network that follows these rules provide an L2
IEEE 802.15.4 service, an IPv6 6TiSCH service, ???
Related to this question, does this document describe "a minimal set
of rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal
mode of operation" (both text snippets from the Abstract).
TW> Hmm. This remark doesn't translate into a direct (editorial) action
point.
TW> I therefore propose we start a thread on the 6TiSCH ML around these
terms.
TW> @Chairs, start thread on 6TiSCH ML.
2. Requirement for RPL is ill-advised
This document seems to be focused on IEEE 802.15.4 TSCH operational
parameters. Yet, it calls for the use of RPL, which seems to me to be
a highly undesirable entangling of protocols at different layers of
the protocol stack. IEEE 802.15.4 TSCH is expected to be
used in networks that don't use RPL.
My understanding of the document is that RPL is assumed to be in use
because it is required in a 6TiSCH network. RPL is then used
to generate the Join Priority through the DAGRank function as
specified in section 7.2. The use of RPL implies to me the
configuration and operation of a full IPv6 stack, which hardly seems
like a minimal mode of operation for IEEE 802.15.4 TSCH.
TW> Brian raised a similar question. RPL is not required to
TW> RPL is not required in order to be compliant with IEEE802.15.4e TSCH.
TW> My recommendation is for this spec to RECOMMEND the use RPL, hence the
rephrasing
TW> In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be
used.
TW> (see above)
TW> You do point out the one dependency, which is the join priority field
in the EB.
TW> Currently, we set that to the RPL rank; if RPL is not used, something
else has to
TW> set the join priority in a consistent manner.
TW> @Chairs, discuss further with Ralph to better scope the point raised,
and report to ML.
I have a question about this text from section 7.2:
When a node joins the network,
it MUST NOT send EBs before having acquired a RPL rank. This avoids
routing loops and matches RPL topology with underlying mesh topology.
What is meant by "avoiding routing loops"? My understanding is that
IEEE 802.15.4 TSCH simply provides for frame delivery between
neighbors and does not provide frame forwarding. How would routing
loops arise from running IEEE 802.15.4 TSCH?
TW> "Routing loops" in not the right term. As per your comment,
IEEE802.15.4e TSCH
TW> is independent from routing, but loops in the synchronization structure
TW> should be avoided.
TW> @Editor, please rephrase to:
TW> When a node joins the network and the RPL routing protocol is used,
TW> it MUST NOT send EBs before having acquired a RPL rank. This avoids
TW> inconsistencies in the time synchronization structure.
Has the WG considered reorganizing the 6TiSCH protocol suite and
documents to separate the minimal operation of IEEE 802.15.4 TSCH from
IPv6/RPL/ND/etc? For example, has the WG considered allowing a
simpler, initial Join Priority scheme that would provide minimal IEEE
802.15.4 TSCH operation until the full IPv6 suite is running, at which
time RPL will provide optimal routing.
TW> The only thing needed is for the time synchronization structure to be
consistent, i.e.
TW> the relationships between each node and its time source neighbor forms
TW> a directed acyclic graph rooted in one node.
TW> If RPL is not present, a simple way to achieve this is for each node to
TW> use the join priority of its time source neighbor incremented by one.
TW> If RPL is present, RPL rank should be used as join priority.
TW> @Chairs, discuss further with Ralph to better scope the point raised,
and report to ML.
3. Restatement of specifications in IEEE 802.15.4 documents
I haven't read the most recent IEEE 802.15.4 docs and it has been a
while since I took a close look at earlier revs. With that disclaimer
in mind, how much of the text in sections 3 through 9 is a restatement
of the IEEE 802.15.4 specification and how much is the specification
of operational parameters for minimal operation of a IEEE 802.15.4
TSCH network? Restatement of specifications can be confusing and lead
to a lack of interoperability. As a small example, here is section 6:
6. Acknowledgment
Link-layer acknowledgment frames are built according to [IEEE802154].
Unicast frames sent to a unicast MAC destination address MUST request
an acknowledgment. The sender node MUST set the ACK requested bit in
the MAC header. The acknowledgment frame is of type ACK (frame type
value 0b010). Each acknowledgment contains the following IE:
ACK/NACK Time Correction IE: The ACK/NACK time correction IE
carries the measured de-synchronization between the sender and the
receiver. Refer to Section 11.3 for an example of the Header IE
content. The possible values for the Time Synchronization
Information and ACK status are described in [IEEE802154].
Out of that section, it seems to me that the first sentence is
harmless, the second sentence is a specification for this
document, the third and fourth sentences are a restatement of
[IEEE802154] and the fifth sentence is an inferred specification for
this document. The description of the IE is a restatement of
[IEEE802154].
TW> Editorial.
TW> @Editor, please go through the text and remove any restatements of
IEEE802.15.4/IEEE802.15.4e docs.
Section 6 could be rewritten as:
6. Acknowledgement frames
Unicast frames sent to a unicast MAC destination address MUST request
an acknowledgment. Each acknowledgment MUST contain an ACK/NACK
Time Correction IE.
TW> Editorial.
TW> @Editor, please fix.
4. Default behavior versus learned behavior
Which of the configuration and operational specifications in this
document must be pre-configured before a node joins the network, and
which are learned through, e.g., EBs.
TW> These are really two different questons.
TW> What a node needs to join a network using this specification are the
security keys.
TW> It learn the rest (i.e. duration of a timeslot, length of the
slotframe, location of the cell to use in that schedule) from the EB.
TW> @Editor, please add a sentence to that effect in Section 3.
Are operational control and
management questions out of scope for this document, such as:
- when does a node switch from the "minimal 6TiSCH configuration" to
some other configuration?
TW> This is not defined, yet. A product can very well use this
specification alone.
TW> Future specification can detail how this spec can be augmented to
schedule more cells in the slotframe.
TW> However, we do not want/can specify this at this point.
- does a node use the configuration parameters it has received
through EBs to generate its own EBs or does it use the "minimal
6TiSCH configuration" parameters?
TW> By default, the node uses the information it receives from the EBs, so
that become the
TW> "minimal 6TiSCH configuration" parameters. Was difference are you
making.
TW> By default, the node also uses that information to create its own EBs.
TW> To make this clearer, my recommendation is to add the following
sentence at the
TW> very end of Section 5 (under "Frame and Link IE")
TW> This specification RECOMMMENDS that the node indicates the same
information
TW> in the "Frame and Link IE" in the EBs it sends, than the "Frame and
Link IE"
TW> information it has received in an EB.
TW> @Editor, please add the sentence above.
5. In this text from the Introduction, does "synchronizes with the
network" mean time synchronization or something else:
[...] when a node synchronizes to the network.
TW> Editorial.
TW> @Editor, please use the term "time synchronizes"
6. I don't think the last sentence of the Introduction is relevant to
an Introduction.
TW> Editorial.
TW> @Editor, please remove "Nodes must broadcast properly-formed Enhanced
Beacons to announce these values."
7. The document could use a section on the terminology used in the
document, to provide definitive sources for definitions of the various
terms and acronyms used in the document. Most likely, the terminology
section would simply point to relevant sections of [IEEE802154] and
[I-D.ietf-6tisch-terminology].
TW> Editorial.
TW> @Editor, please add a "Terminology" section which points to
[I-D.ietf-6tisch-terminology].
8. Section 11 should be an Appendix, rather than part of the body of the
document, so as to avoid making those examples normative standards text.
TW> Editorial.
TW> @Editor, please move Section 1 to Appendix A.
9. I think the contents of section 7.1 are entirely dependent on the
specifics of an implementation and the section should be omitted.
TW> I believe this section might help and implementor, no?
TW> I suggest we apply the comment by Brian on the same section, and
reconsider whether 7.1 should stay.
10. I think the information in section 8 would be more generally
useful if not stated in terms of a queue-based implementation:
A node must not transmit frames containing higher-layer packets
until the node has successfully joined a network.
Frames generated by the IEEE 802.15.4 layer are transmitted before
frames containing higher-layer packets.
Frame types BEACON and COMMAND are transmitted before frame types
DATA and ACK.
A node has to be prepared to send a BEACON or COMMAND frame at any
time.
I've tried to infer the desired behavior from the description of queue
usage. If I understand the original text correctly, there is no
difference between the second and third requirements.
TW> Editorial.
TW> @Editor, please merge requirements 2 and 3.
11. According to [I-D.ietf-6tisch-terminology], the correct term is
"timeslot", so s/time slot/timeslot/ throughout the document.
TW> Editorial.
TW> @Editor, please fix.
12. In the table at the top of page 4 (BTW, please number and add a
title to all tables),
TW> Editorial.
TW> @Editor, please fix.
are the listed properties the only properties
that have numeric or short text string values? If not, all of those
properties should be gathered together into a single table. As an
editorial aside, this table is pretty much what I expected to be the
bulk of this document.
TW> Editorial.
TW> @Editor, please fix.
13. Even if the number of timeslots in a slotframe is variable for
this minimal configuration, should there be a default?
TW> The danger with a default value is that it doesn't satisfy anyone.
TW> We could indicate a default value (11? such as in the plugtest?) and
indicate
TW> that this value should be chosen to match the number of frames
exchanged by
TW> nodes per unit time.
TW> @Editor, please add a default value and the note above.
14. In the table at the top of page 5, what do the empty boxes
represent?
TW> Editorial.
TW> @Editor, please put "OFF" in currently empty boxes.
15. The last sentence of section 3.2 seems to be a low-level
implementation detail that can be omitted.
TW> Editorial.
TW> @Editor, please remove
TW> In a memory-efficient implementation,
TW> scheduled cells can be represented by a circular linked list.
TW> Unscheduled cells SHOULD NOT occupy any memory.
16. Without having read the IEEE 802.15.4 docs recently to confirm,
I'll suggest that almost all of section 3.4 is a restatement of the
IEEE 802.15.4 spec. The last sentence is important, and isn't
entirely clear. It would be clearer to write:
For the minimal configuration specified in this document, the use
of CCA is OPTIONAL.
TW> Editorial.
TW> @Editor, please make the following change:
TW> OLD
TW> As for a minimal configuration, CCA is OPTIONAL.
TW> NEW
TW> For the minimal configuration specified in this document,
TW> the use of CCA is OPTIONAL.
17. End of section 3 - not clear when to use macTimeslotTemplate.
TW> Editorial.
TW> This would be much clearer if that paragraph provided a 1-sentence
definition of
TW> macTimeslotTemplate.
TW> @Editorial, please add this sentence.
18. The third paragraph of section 4 is completely unclear to me:
A Node aiming to join the network by receving a properly formed
BEACON shall enter in a scan phase and shall store the value of
macPANId and then set it to 0xffff for the duration of the scan in
order to meet the filtering rules in [IEEE802154].
What are "macPANId" and "scan phase"? I don't see those terms used
anywhere else in this document; do the terms come from the IEEE
802.15.4 specs? Why would an implementation store the value of
macPANId and then set it to 0xffff?
TW> Edtorial.
TW> @Editor, please fix.
19. Does "synchronization" in section 5 mean "time synchronization"?
TW> Editorial.
TW> @Editor, please use "time synchronization".
20. In section 5, is "EB_PERIOD" the same value as defined in the
table in section 10.2.4 that defines "RPL-related variables"? If so,
I don't understand why "EB_PERIOD" is in that table, as it only
appears once in the rest of the document in section 5.
TW> Editorial.
TW> This is an typo.
TW> @Editorial, please remove the term EB_PERIOD.
21. I see that section 10 includes the statement:
Nodes in a multihop network MUST use the RPL routing protocol
[RFC6550].
This statement is certainly false if one takes a broad definition of
the word "multihop". Even if edited to "multilink subnet" or "mesh",
I can't find any support in RFC 6550 for the statement "MUST use RPL
routing protocol". I think it would be much clearer and more correct
to quote verbatim the text describing this requirement from RFC 6550
rather than paraphrasing it here.
TW> This is the same discussion as above.
TW> I believe addressing the discussion above will address this comment.
Similarly, this sentence in section 10.1 needs, at least, to be
edited, and I think it should be replaced with quoted text from RFC
6552.
Nodes in the multihop network MUST implement the RPL Objective
Function Zero [RFC6552].
TW> Editorial.
TW> @Editor, please add a statement "if RPL is used" in that sentence.
While I haven't provided a detailed review of the remainder of section
10 because I don't think it's necessary for the goals of this
document, it appears to me that much of section 10 is a restatement of
the RPL specification from RFC 6550 and should, therefore, be omitted
(if RPL is retained as a part of this recommendation).
TW> Editorial.
TW> @Editor, please go through the specification
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
