Hello Brian: For the track I created a separate issue and I will foster discussions on the ML. Please have no doubt that this was the intention.
Cheers, Pascal > -----Original Message----- > From: 6tisch [mailto:[email protected]] On Behalf Of Brian Haberman > Sent: lundi 30 novembre 2015 18:10 > To: [email protected] > Subject: Re: [6tisch] handling comments on draft-ietf-6tisch-minimal-12 > > 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 > > TW> 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 > > TW> different addresses. We could indicate this precisely in this > > TW> 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 > > TW> IEEE802.15.4e was 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 > > TW> the > > discussions > > TW> and walks through a minefield. We expect a person deploying to set > > TW> K1 > > and K2 to some > > TW> arbitrary value if no KMP is present. The default value of K1 is > > TW> 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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
