Subject: [6tisch] AD evaluation: draft-ietf-6tisch-minimal-16

From: Suresh Krishnan <[email-masked]>
Date: Thu, 17 Nov 2016 00:31:39 +0000

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Nov 2016 04:47:42 +0200

[as I happen to have 802.15.4-2015 open, here are suitable references
to it...]

> terminology document. Is this the same CCA as WiFi?

CCA for TSCH is to help it work with other radio networks in same
band, it is ineffective against other nodes in TSCH network.

This is described in the 802.15.4-2015 section 6.2.5.2 TSCH CCA
algorithm:

6.2.5.2 TSCH CCA algorithm

	When a device is operating in TSCH mode as described in 6.3.6,
	CCA may be used to promote coexistence with other users of the
	radio channel. For other devices in the same network, the
	start time of transmissions, macTsTxOffset, is closely aligned
	making intra-network collision avoidance using CCA
	ineffective. TSCH devices also use channel hopping so there is
	no backoff period used when CCA prevents a transmission.
...

> Please provide a section reference into the 802.15.4 document

Nonce generation in 802.15.4-2015 is described in the section "9.3.2.2
CCM* nonce for TSCH mode".

Byte order is specified in the section "9.3.1 Integer and octet
representation", which then referes to the B.2, and B.2.2. tells
crypto uses MSB order (most of the other things in 802.15.4 is in
LSB).
-- 
[email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 17 Nov 2016 20:59:50 -0500

I'm new here, but I notice that draft-ietf-6tisch-minimal mostly uses
"802.15.4" (39 instances) rather than "802.15.4e" (4 instances), even
though it applies only to TiSCH networks.  Is this intended?  What is
the best style?

Dale

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Nov 2016 05:29:44 +0200

> though it applies only to TiSCH networks.  Is this intended?  What is

The 802.15.4e is and addition to the 802.15.4-2011, and it got
incorporated to the latest 802.15.4-2015 document. When it is using
802.15.4 that is refering to the latest version of the 802.15.4 + all
approved amendments to it, i.e. currently 802.15.4-2015 +
802.15.4u-2016 - 802.15.4q-2016.

Using 802.15.4e is like refering to the RFC that obsoleted with newer
bis document, so it should not refer to the 4e unless it is talking
about the history... 
-- 
[email-masked]