All,
I apologize for the tardiness in this review. I haven't completed
my entire review, but I wanted to get some issues out so that the
authors/WG can consider them along with the INT-Dir review already sent.
There should be another INT-Dir review delivered in the next week or
so. Feel free to discuss these with me if there are any questions on them.* Meta : The document should be consistent in the use of SHOULD vs. RECOMMENDED and MUST vs. SHALL. Pick one nomenclature and stick with it. * 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? * 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. * Meta : All the figures should be numbered and referenced by number in the text. * Meta : All acronyms should be expanded on first use. * Introduction 1. I don't think 2119 keywords make sense in an introduction. 2. What constitutes a TSCH-compliant network? Is RPL required in order to be compliant? * Section 3 : What exactly is a "minimum schedule configuration"? * Section 3.1 1. s/length, and which repeats/length that repeats/ 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? 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? 4. The text mentions slotframe length but provides no definition or reference for it. 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? * Section 3.2 : The 2nd paragraph starts with "... bitmap of cell options below." Not sure how to follow the "below" directive. * Section 3.3 : I would like to see a little bit of discussion on how the number of re-transmits affect minimal operation. * 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? 2. It is unclear to me where to find the description of CCA. * Section 4 1. *How* does an implementer indicate in the corresponding Frame Control field that the source address contains an extended address? 2. There are a couple of instances of lower-case "shall". Should those be interpreted as SHALL/MUST? 3. There is reference to a Table 2a. Is that a table in the 802.15.4 spec? Some clarity is needed. 4. I see ASN and immediately think "Autonomous System Number", but I don't think you mean that. * Section 5 1. s/EBs MUST NOT in general/EBs MUST NOT/ 2. How does the discussion of the TSCH Timeslot IE relate to the discussion in section 3.1? 3. Is the 2.4GHz OQPSK Phy the only phy supported by 6tisch-minimal? * 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. * Section 9 1. s/Section Section 5/Section 5/ 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. * Section 10.1.1 1. Is all of this needed if it is already in RFC 6552? 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? 3. OF0 = Objective Function 0? * Section 10.2 : s/these MUST obey to/these MUST follow/ * Section 10.2.1 : Does "MUST support" imply "MUST use"? * Section 10.2.4 : The text says the variables are defined in the previous section, but the variables are actually defined in different sections. * Section 11 1. s/the IEs the form/the IEs that form/ 2. s/the later has/the latter has/ Regards, Brian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
