Note: This ballot was opened for revision 24 and is now closed.
I support Benjamin's first DISCUSS point.
Thank you for addressing my COMMENTs.
Thank you for addressing my Discuss and Comment points!
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.
I agree with Mirja’s DISCUSS.
I support Mirja's DISCUSS. The same point has been brought up in several of the Directorate reviews...for example  and . It seems that the concern has not been fully addressed.  https://mailarchive.ietf.org/arch/msg/tsv-art/OErnkMZ1Vb-BzYSGRs1KMC7g_f8  https://mailarchive.ietf.org/arch/msg/rtg-dir/9eR1oXVO0_n6Cl3CFV1Ytxrv2FU
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 18.104.22.168 -- Duplicate line. Duplicate line. ;-) - Section 4.6 -- s/three different forwarding model, /three different forwarding models: /