Hi Thomas,
I am generally fine with most of the responses/changes made. I
have a few follow-ups on some of the ones that I think need more
work/discussion...On 11/4/15 9:56 AM, Thomas Watteyne wrote: > * 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. > I see that there was some discussion on one of your conference calls about the status of the document. But, I don't see that discussion on the mailing list. The conference calls (or virtual interim meetings) cannot be the final say on the consensus of the WG. The only mention of this issue on the mailing list is as a part of an issue tracker ticket, which isn't sufficient. Additionally, if the WG does reach a consensus of leaving this document on the Standards Track, I will be expecting to see some justification provided in the shepherd writeup on this decision (i.e., there are two questions asked in bullet 1 of the writeup). > * Introduction > > 1. I don't think 2119 keywords make sense in an introduction. > > TW> Editorial. > TW> @Editor, please fix. > I don't think this is fixed. I am not sure why the 2119 boilerplate was moved before the Introduction, either. The simple fix is to perform a s/MAY/could/g to the Introduction. > > 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. > I still find the above an issue. Section 11 says RPL is optional, but that occurs after the RPL discussion in sections 8.1, 8.2, etc. What I think would work is a paragraph in the Introduction that clearly describes what constitutes a "minimal configuration". This should include rationale for the components described in this document. > > * 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. > If K1 and K2 are supposed to be set to some arbitrary value, why is the document suggesting the arbitrary value(s)? Is this assuming that the values are hard-coded by an implementer? Where is the Security Considerations that discuss the issues with the above approach? Additional issues that were raised, but not included above: 1. I can infer that CCA comes from one of the 802.15.4 specs, but I would prefer a definitive statement in the Terminology section as to where I can find the description of CCA. Regards, Brian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
