Dear all,
We've gone through all the comments raised in the last review of the
minimal draft. In order to clarify the status of the work and how the
raised comments have been addressed we provide next the answers to the
received comments.
see XV> as my comments
see TW> as Thomas Watteyne comments
see PT> as Pascal Thubert comments.
kind regards,
Xavi
------------
============================
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.
PT> @all: solved, the draft is now presented as a BCP, following Suresh’s
recommendation
* 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.
XV> SP cannot be 4, it won't be considered as a candidate as this means
that this link is really bad.
PT> I think that there is a misconception. ETX is not an integer, it is a
float. The design point is that neighbors that in average require 4
transmissions should not be selected unless there is absolutely no choice.
Editorial
=========
Section 3.2
s/maintin/maintain/
TW> Editorial.
TW> @Editor, please fix.
XV>DONE
Section 3.3
s/if none is/if none are/
TW> Editorial.
TW> @Editor, please fix.
XV>DONE
###############################################################################
################### 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.
XV>DONE
* 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.
XV>DONE. It is BCP now
* 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.
XV>DONE. This has been addressed. All references to 15.4 and other
references in general are at the end of the sentence.
* Meta : All the figures should be numbered and referenced by number in
the text.
TW> Editorial.
TW> @Editor, please fix.
XV>DONE.
* Meta : All acronyms should be expanded on first use.
TW> Editorial.
TW> @Editor, please fix.
XV>DONE.
* Introduction
1. I don't think 2119 keywords make sense in an introduction.
TW> Editorial.
TW> @Editor, please fix.
XV> this has been moved to section 2 as in other RFCs.
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.
XV>DONE.see section 11 for example.
* Section 3 : What exactly is a "minimum schedule configuration"?
TW> Editorial.
TW> @Editor, please add definition.
XV> section 4 clarifies that. This has been corrected.
* Section 3.1
1. s/length, and which repeats/length that repeats/
TW> Editorial.
TW> @Editor, please fix.
XV> DONE.
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?
XV> This has been clarified in section 4, 4.1 and 4.2.
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?
XV> This has been clarified with the following test:
The active cell MAY be scheduled at any slotOffset
(default 0x00) and any channelOffset (default 0x00) within the
slotframe and this location MUST be announced in the EBs.
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"
XV> This has been clarified in Section 4.1 "The number of timeslots in the
slotframe is referred as slotframe length [IEEE802154]."
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?
XV>DONE. See section 4.1
In a minimal configuration, a default timeslot duration set to 10ms
and its corresponding default timeslot internal timings defined by
the IEEE 802.15.4 specification SHOULD be used [IEEE802154]. The
timeslot timing is defined by the macTimeslotTemplate in the
IEEE802.15.4 specification. The use of the default
macTimeslotTemplate MUST be announced in the Enhanced Beacon (EB) by
using the Timeslot Information Element (IE) containing only the
default macTimeslotTemplateId. Other timeslot durations MAY be
supported and MUST be announced in the EBs. Joining nodes MUST learn
the configuration from the received EB. If a network uses a timeslot
duration different than the default (10ms), EBs MUST contain the
complete Timeslot IE and fill all the fields of the
macTimeslotTemplate as described in Section 4.4. Nodes not
supporting the default timeslot value SHOULD be clearly indicated.
* 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.
XV> this has been removed with numerous formatting changes in the section.
The bitmap of cell options is presented in section 4.2
* 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?
XV> DONE. See section 4.3. Retransmissions
* 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.
XV> Waiting AD advice. We think that wording is clear and inline with the
15.4e TSCH description.
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.
XV> added in section 3 Terminology. To be included by the terminology draft.
* 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.
XV> Section 5 discusses the specific header fields.
2. There are a couple of instances of lower-case "shall". Should
those be interpreted as SHALL/MUST?
TW> Editorial.
TW> @Editor, please fix.
XV> DONE.
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.
XV> DONE.
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).
XV> DONE. See section 5.
* Section 5
1. s/EBs MUST NOT in general/EBs MUST NOT/
TW> Editorial.
TW> @Editor, please fix.
XV> DONE.
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?
XV> DONE.
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.
XV> DONE. This sentence has been added in Section 4.
The present specification is independent of the actual physical layer
and it is only dependent on the IEEE 802.15.4 TSCH MAC layer
specification.
* 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.
XV> DONE. the sentence has been added.
* Section 9
1. s/Section Section 5/Section 5/
TW> Editorial.
TW> @Editor, please fix.
XV> DONE.
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.
XV> DONE.
* 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.
XV> DONE.
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.
XV> This exagerates the rank between node, it weights the step of rank,
that is the link properties.
PT > This is when ones builds a network with highly different link types.
The factor multiplies the rank increment, making the slow link less
desirable.
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.
XV> DONE.
* 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.
XV> DONE. All variable definitions have been moved to section 12 so they
are all together.
* Section 11
1. s/the IEs the form/the IEs that form/
TW> Editorial.
TW> @Editor, please fix.
XV> DONE.
2. s/the later has/the latter has/
TW> Editorial.
TW> @Editor, please fix.
XV> DONE.
###############################################################################
################### 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.
XV> DONE. This has been largely discussed. Abstract and intro reworded and
most of the sections oriented towards the contribution of the document.
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.
PT > we have updated the introduction and worked with Ralph; we reached a
consensus on that part
XV> DONE. We have gone through the whole text and removed unnecessary
references. We kept those that we consider necessary.
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.
XV>DONE
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 questions.
TW> Editorial.
TW> @Editor, please fix.
XV>DONE, this has been removed as this was extracted from 15.4. We refer to
15.4.
19. Does "synchronization" in section 5 mean "time synchronization"?
TW> Editorial.
TW> @Editor, please use "time synchronization".
XV>DONE
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.
XV>DONE. Added in table 1 and referred in the text.
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.
XV>DONE. See above.
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.
XV>DONE
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
XV> DONE. We reviewed that section.
PT> there is a little bit of restatement (the formula) but it is my opinion
(RPL editor hat on) that the text is conform and simplifies the reading.
PT> The text specifies a mix of OF0 and ETX which is not prescribed in the
previous work, including hysteresis, which inherits from MrHof.
PT> I’m happy with that text (reviewer hat on)
2016-02-12 15:22 GMT+01:00 6tisch issue tracker <[email protected]>
:
> #41: intended status for draft minimal
>
> Changes (by [email protected]):
>
> * status: new => closed
> * resolution: => fixed
>
>
> --
> -----------------------------------+------------------------------------
> Reporter: [email protected] | Owner: [email protected]
> Type: defect | Status: closed
> Priority: major | Milestone: milestone1
> Component: minimal | Version: 1.0
> Severity: Submitted WG Document | Resolution: fixed
> Keywords: |
> -----------------------------------+------------------------------------
>
> Ticket URL: <
> https://trac.tools.ietf.org/wg/6tisch/trac/ticket/41#comment:4>
> 6tisch <https://tools.ietf.org/6tisch/>
> IPv6 over the TSCH mode of IEEE 802.15.4e
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
