Dear Suresh,
see inline our responses. The new version of the draft has been published
already (v17).
thanks for your reviews!
--------------------
Hi authors,
I went through the latest version of the draft and it is almost ready to
go. There are a few issues that I would like to see fixed before I progress
it and I have detailed them in this mail.
Section 3:
CCA: Clear Channel Assessment.
- Can you provide a description or a reference? This is not in the
terminology document. Is this the same CCA as WiFi?
Authors>> The definition has been pushed to the terminology draft.
CCA: Clear Channel Assessment. Mechanism defined in <xref
target="IEEE802154-2015"/>, section 6.2.5.2. In a TSCH network, CCA can be
used to detect other radio networks in vicinity. Nodes listen before
sending to detect other ongoing transmissions. Because the network is
synchronized, CCA cannot be used to detect colliding transmission within
the same network.
Section 4:
- Not clear what the point of this MUST is
These set of rules and default parameters constitute a minimal configuration
to which nodes implementing this specification MUST comply.
How is this testable and how does this relate to the SHOULDs in this
document?
Authors>>This paragraph has been rewriten as it was not clear.
" An implementation compliant to this specification MUST implement the
IEEE802.15.4 [IEEE802154-2015] in "timeslotted channel hopping"
(TSCH) mode.
The remainder of this section details the RECOMMENDED TSCH settings,
which are summarized in Figure 1. A node MAY use different values.
Any of the properties marked in the EB column are announced in the
Enhanced Beacons (EB) the nodes send [IEEE802154-2015]. Changing
their value hence means changing the contents of the EB.
In case of discrepancy between the values in this specification and
the IEEE802.15.4 specification [IEEE802154-2015], the IEEE standard
has precedence."
- Table 1 summarizes the main configuration parameters for a minimal
configuration.
What about the other parameters?
Authors>>The table summarizes the recommended IEEE802.15.4 TSCH Settings.
RPL settings are summarized in section 5.1.1.
Section 4.1
- The slotframe definition here seems a bit different from the terminology
document. Please don't redefine and fix the definition in the terminology
document
Authors>>This has been removed pointing to the terminology draft as well.
- Compliant nodes SHOULD obey to the following configuration as defined
* Why is this not a MUST?
* s/obey/follow/
Authors>>This has been rephrased.
"
The remainder of this section details the RECOMMENDED TSCH settings,
which are summarized in Figure 1. A node MAY use different values.
Any of the properties marked in the EB column are announced in the
Enhanced Beacons (EB) the nodes send [IEEE802154-2015]. Changing
their value hence means changing the contents of the EB."
The minimal draft recommends a set of settings from 15.4 and indicates that
other values
are supported but must be announced properly according to the rules of
802.15.4
- The trade-off between bandwidth, latency and energy consumption can be
controlled by choosing a different slotframe length.
Can a node be compliant to this document and make different trade-off?
Authors>> Yes.
- Other timeslot durations MAY be supported and MUST be announced in the
EBs.
Again, can a node use a different timeslot duration and be compliant with
this document?
Authors>> Yes, other configurations are supported but MUST be announced in
the EB per IEEE802.15.4 spec.
- Nodes not supporting the default timeslot value SHOULD be clearly
indicated.
How are they indicated?
Authors>> This sentence has been removed. Is out of scope whether the
vendor adds an sticker to the device indicating that.
Section 5
- When preparing the security header, the Absolute Sequence Number
(ASN) MUST be written into the Nonce in most significant byte first
(MSB) format as indicated in the IEEE 802.15.4 specification
[IEEE802154-2015]
Please provide a section reference into the 802.15.4 document
Authors>> The references to the IEEE802.15.4 have been added. The text has
been rewriteen as follow.
"The Nonce is formatted according to [IEEE802154-2015]. In the
IEEE802.15.4 specification [IEEE802154-2015], Nonce generation is
described in Section 9.3.2.2, and byte ordering in Section 9.3.1,
Annex B.2 and Annex B.2.2."
* Section 9
A single queue with the following rules SHOULD be used
Can a node be compliant without following this? What are the exception
cases?
Authors>>This section has been converted into an Implementation
Recommendation (see Section 7). We recommend a set of rules extracted from
the experience in implementations of the protocol (e.g openwsn).
* Section 11.1.1
Is this section (and this level of detail) needed?
Authors>>The section has been shortened, pointing RFC6552. A table with the
OF0 have been added to clarify the configuration proposed by minimal.
2016-11-17 1:31 GMT+01:00 Suresh Krishnan <[email protected]>:
> Hi authors,
> I went through the latest version of the draft and it is almost ready to
> go. There are a few issues that I would like to see fixed before I progress
> it and I have detailed them in this mail.
>
>
> Section 3:
>
> CCA: Clear Channel Assessment.
>
> - Can you provide a description or a reference? This is not in the
> terminology document. Is this the same CCA as WiFi?
>
> Section 4:
>
> - Not clear what the point of this MUST is
>
> These set of rules and default parameters constitute a minimal
> configuration
> to which nodes implementing this specification MUST comply.
>
> How is this testable and how does this relate to the SHOULDs in this
> document?
>
> - Table 1 summarizes the main configuration parameters for a minimal
> configuration.
>
> What about the other parameters?
>
>
> Section 4.1
>
> - The slotframe definition here seems a bit different from the terminology
> document. Please don't redefine and fix the definition in the terminology
> document
>
> - Compliant nodes SHOULD obey to the following configuration as defined
>
> * Why is this not a MUST?
> * s/obey/follow/
>
> - The trade-off between bandwidth, latency and energy consumption can be
> controlled by choosing a different slotframe length.
>
> Can a node be compliant to this document and make different trade-off?
>
> - Other timeslot durations MAY be supported and MUST be announced in the
> EBs.
>
> Again, can a node use a different timeslot duration and be compliant with
> this document?
>
> - Nodes not supporting the default timeslot value SHOULD be clearly
> indicated.
>
> How are they indicated?
>
> Section 5
>
> - When preparing the security header, the Absolute Sequence Number
> (ASN) MUST be written into the Nonce in most significant byte first
> (MSB) format as indicated in the IEEE 802.15.4 specification
> [IEEE802154-2015]
>
> Please provide a section reference into the 802.15.4 document
>
> * Section 9
>
> A single queue with the following rules SHOULD be used
>
> Can a node be compliant without following this? What are the exception
> cases?
>
> * Section 11.1.1
>
> Is this section (and this level of detail) needed?
>
>
> Thanks
> Suresh
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
Dr. Xavier Vilajosana Guillén
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya
+34 646 633 681| [email protected] | Skype: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
