An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)
draft-ietf-6tisch-architecture-30

Thank you for addressing my COMMENTs.

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: /

I support Benjamin's first DISCUSS point.

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

I agree with Mirja’s DISCUSS.

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.