Hello Qin
Many thanks for your review and for the important amount of time you obviously spent on our work. This is really appreciated.
Please see below:
> By looking at high level architecture section, it is hard to create a whole
> picture for what this architecture looks like and how these architecture
> component can be put together. Also architecture components defined in
> architecture component section seem not to align with high level architecture
> section. For Some architecture component,e.g.,Communication Paradigms and
> Interaction Models, Network access and addressing haven't appeared in the
> high level architecture first.
This is an interesting comment.
If you look back at say, draft 18, the sections in the high level architecture have been modified and quite a bit of text went from section 3 to section 4.
The reason is that the first reviews we got from outside the WG told us to shrink section 3 to the minimum, which caused us to move text to section 4.
I'm intrigued by your comment " seem not to align with high level architecture ". This is certainly something we need to act upon; but there is a difference between the fact that a discussion appears only in section 4 and a misalignment, which I read as a discrepancy or an inconsistency in the architecture. Could you please provide suggestions on where to focus without undoing what we did for the previous reviewers? If this is about moving text back to section 3, I generally agree but need to confirm with the original reviewers (cc), more below.
A few editorial comments and suggestions
> 1.Section 1 IT and OT should be part of terminology section too.
Expanded both in first use and added a terminology for OT. IT is a bit too obvious for a terminology section isn't it?
"
<t hangText="Operational Technology:">
OT refers to technology used in automation, for instance in
industrial control networks. The convergence of IT and OT is
the main object of the Industrial Internet of Things (IIOT).
"
> 2.Section 2
> ND-proxying and binding should provide reference,e.g.,RFC4389
Well, this reference would be misleading because it considers specific network models that are not the one we need in 6TiSCH. So we refrained from using it.
Turns out that there is no IPv6 RFC that would be equivalent to ARP proxya and that we could reference. That's until now since we are doing the backbone router. Which is what the architecture discusses later. Sorry but I have no clean path to fix this...
> 3.Section 3 I
> think Architecture Components Defined in section 4 should be consistent with
> high level architecture, e.g.,Network access and Adressing component seems
> not to be discussed in high level architecture section.
See https://tools.ietf.org/html/draft-ietf-6tisch-architecture-17 section 3.7, that subsection was in section 3. This is how I thought it should be structured. But then it was moved to 4 on request of a previous IESG review to improve the clarity y making section 3 more concise. I'm happy to move it back but cc the original reviewers to make sure we all agree on the final result.
Please confirm that this is effectively your recommendation.
> 4. Section 3.1 figure1
> NME and PCE should be part of terminology section
Added terminology + verified that the terms are expanded in first use.
Note that I got the exact reverse remark from another reviewer, said something like expanding in first use is the IETF way and sufficient.
A hint that there is no perfection ; )
5.Section 4.3.1.1,1st
> paragraph The first sentence should not belong to this section since this
> section focuses on introduction of Hard cell.
Agreed; moved above the section boundary.
6.Section 4.3.1.1, Section 4.3.1.2
> Two section seesm only to discuss how to use hard cells or soft cell, but
> doesn't define what it is. Please clarify the difference between hard cell or soft
> cell
Actually it does but it could be a lot more clear.
Proposed text:
On hard cells
"Hard" cells are cells that are
are owned and managed by a separate scheduling entity (e.g. a PCE)
that specifies the slotOffset/channelOffset of the cells to be
added/moved/deleted, in which case 6top can only act as instructed,
and may not move hard cells in the TSCH schedule on its own.
On soft cells
In contrast, "soft" cells are cells that 6top can manage locally.
6top contains a monitoring process which monitors the performance of
cells, and can add, remove soft cells in the TSCH schedule to adapt
to the traffic needs, or move one when it performs poorly.
> 7. Section 4.4 How this section is related to high level architecture
> described in section 3
If that is what you have in mind, yes, this section is mostly an introduction to sections 4.5 to 4.8.
If that corrects the issue as you see it, then I agree to move it to section 3.
Please confirm that this is effectively your recommendation.
> 8. Section 4.5.3 The content in section 4.5.3 is badly
> written and hard to understand. By reading the first paragraph of section 4.5.3,
> it is hard to get sense of what remote monitoring and schedule management
> means and how reproduced figure 10 is related to remote monitoring and
> schedule management.
> How Remote monitoring and schedule management is different from other
> scheduling mechanism. Please rewrite.
It is effectively a DetNet/SDN model whereby the controller assigns physical resources in the form of time slots.
I can add text at the beginning of the section:
before
"
The work at the 6TiSCH WG is focused on non-deterministic traffic and
does not provide the generic data model that would be necessary to
monitor and manage resources of the 6top sublayer. It is recognized
that CoAP can be appropriate to interact with the 6top layer of a
node that is multiple hops away across a 6TiSCH mesh.
The entity issuing the CoAP requests can be a central scheduling
entity (e.g. a PCE), a node multiple hops away with the authority to
modify the TSCH schedule (e.g. the head of a local cluster), or a
external device monitoring the overall state of the network (e.g.
NME). It is also possible that a mapping entity on the backbone
transforms a non-CoAP protocol such as PCEP into the RESTful
interfaces that the 6TiSCH devices support.
"
After
"
Remote monitoring and Schedule Management refers to a DetNet/SDN
model whereby an NME and a scheduling entity, associated with a PCE,
reside in a central controller and interact with the 6top layer to
control IPv6 Links and Tracks (Section 4.6) in a 6TiSCH network. The
composite centralized entity can assign physical resources (e.g.,
buffers and hard cells) to a particular Track so as to optimize the
reliability within a bounded latency for a well-specified flow.
The work at the 6TiSCH WG focused on non-deterministic traffic and
did not provide the generic data model that is necessary for the PCE
to monitor and manage resources of the 6top sublayer. This is
deferred to future work, more in Appendix A.2.2.
"
Note that since we do not do the work, it is too early to presume that CoAP and PCEP will be finally adopted for this purpose and the references are removed.
9. Section 7 Too many thanks in the acknowledgment section, suggest to simplify it.
This is the only place where I really disagree. Those people helped. The WG has been on this spec for 5+ years. I do not see why it hurts to recognize them.
> 10.Appendix A not sure the
> importance of this part and how these related work are related to architecture
> or section 2.3. Suggest to remove this appendix or consolidate some text with
> section 2.3.
Then again your suggestion is how I would have done it and actually did in earlier versions. The text moved to appendix due to IESG review; we got a concern that the architecture had too many references to incomplete work, so the text was moved. Since there were 3+ reviewers indicating the issue, I'd rather not undo if that's OK with you.
Please
