An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)
RFC 9030
Yes
No Objection
Note: This ballot was opened for revision 24 and is now closed.
Alvaro Retana No Objection
I support Mirja's DISCUSS. The same point has been brought up in several of the Directorate reviews...for example [1] and [2]. It seems that the concern has not been fully addressed. [1] https://mailarchive.ietf.org/arch/msg/tsv-art/OErnkMZ1Vb-BzYSGRs1KMC7g_f8 [2] https://mailarchive.ietf.org/arch/msg/rtg-dir/9eR1oXVO0_n6Cl3CFV1Ytxrv2FU
Roman Danyliw No Objection
Thank you for addressing my COMMENTs.
Éric Vyncke (was No Record, No Objection) No Objection
Pascal, Thank you for the hard work put into this document. It is extensive and comprehensive. I really appreciate this well-written document as it is clear (albeit long...), so, the COMMENTs and NITs are to improve the document quality and not as a negative criticism; your reply + comments will be welcome though. Regards, Bien à toi, -éric == COMMENTS == -- Section 1 -- Suggest to be more specific about the backbone: layer-2 or IP backbone ? -- Section 2.1 -- Please define 'PAN' before first use. The choice of 'ASN' in an IETF document was probably not the choice... ;-) I was unable to understand the concept and use of layer-2 bundle by reading the definition. Let's hope it is defined/explained later... It is probably too late to change now, but, this section is really too heavy and by alphabetical order, so, its usefulness is reduced for first-time readers. Section 3 is rather easy to read for similar explanations. -- Section 3.2 -- For my own curiosity, reducing mcast is always good of course but not critical on the backbone if it is wired Ethernet. So, why mentioning this fact in this memo? -- Section 3.4 -- Minor inconsistency between the list of the schedule management ways and the enumeration. Nothing critical though but confusing. In "Neighbor-to-Neighbor Scheduling", perhaps replace "between adjacent routers" by "between adjacent peers" as the text is mainly about peers? -- Section 3.6 -- It is probably useful to define what "feasable" means in the context of this memo. Probably too late in the publication process to change, but, I would suggest to use "6LoWPAN Fragments Forwarding" (plural) of even "6LoWPAN Fragments Chain Forwarding". More a nit but can you re-use the same names in the table at the end of the section? This table should also have a number such as Table 1 -- Section 3.7 -- Figure 4 mentions "to be IEEE Std. 802.15.12"... this is a hint to a IEEE work which should be explained in the text or be removed. -- Section 3.8 -- The first paragraph would benefit if it was clear that it is about "*difference* between information and data models". Please define what "duocast" is ;-) -- Section 4.1.2 -- Its title is just in the reverse order of the previous sentence :-O And, should it mention "colocated" ? -- Section 4.2.2 -- Is there a difference between "IPv6 ND" in figure 5 and figure 6? It is followed by "NA" "NS" in the latter. -- Section 4.3.3 -- Please define "ETX" and "LQI" ? -- Section 4.4 -- Is it on purpose that there is a lot of overlap with section 3.4 ? -- Section 4.5.3 -- Is it worth to define "PRE" or is DetNet knowledge assumed? -- Section 4.6 -- Please be consistent with the naming of the sub-sections wrt "three different forwarding model" -- Section 5 -- Please replace "This specification" by "This document" as it is not aimed to be a Proposed Standard. -- Section 6 -- "ASN" was not fully described before (except briefly in terminology section), so, I find it weird to build the security section around this concept; moreover, as it comes from DetNet, I would assume that the DetNet documents are more suitable to have this security discussion (with just a point in this memo). == NITS == -- Section 1 -- A comma is probably needed before "Industrial Automation Control Systems (IACS)". Same section could possibly also introduce the 'IT' acronym. s/require the addition/requires the addition/ ? s/, e.g., an Ethernet bridged network,/ (e.g. an Ethernet bridged network)/ -- Section 2.1 -- s/: : /: / -- Section 3.2 -- s/RPL network needs to share information/RPL network need to share information/ ? -- Section 3.7 -- s/aloha/Aloha/ ? The sentence "The reference stack that the 6TiSCH architecture presents was implemented and interop tested" would benefit from a couple of commas. -- Section 4.3.1.1 -- Duplicate line. Duplicate line. ;-) - Section 4.6 -- s/three different forwarding model, /three different forwarding models: /
(Suresh Krishnan; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
I support Benjamin's first DISCUSS point.
(Barry Leiba; former steering group member) No Objection
I agree with Mirja’s DISCUSS.
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you for addressing my Discuss and Comment points!
(Deborah Brungard; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) (was Discuss) No Objection
Thanks for addressing my discuss and putting more work into the doc. OLD COMMENT: As I said, I only had a rather brief read, however, I had a bit of problems to follow exactly which parts of the architecture rely on existing protocols and mechanisms and where 6tsch actually needs to define new approaches. Maybe a short, even higher-level overview than section 3, could address this and help the reader.