Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-architecture-22

[Qin Wu <[e-mail]>]

Hi, Pascal:
-----邮件原件-----
发件人: Pascal Thubert (pthubert) [mailto:[e-mail]] 
发送时间: 2019年6月27日 22:48
收件人: Qin Wu <[e-mail]>; [e-mail]
抄送: [e-mail]; [e-mail]; [e-mail]; Eliot Lear (elear) <[e-mail]>; Carlos Pignataro (cpignata) <[e-mail]>
主题: RE: Opsdir last call review of draft-ietf-6tisch-architecture-22

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.


[Qin]: My concern is on consistency between section 3 an section 4 and scope clarity since one focuses on high level architecture or requirements while the other aims at details functional component. If there is some stuff in section 4 not abstracted or reflected in section 3, I am wondering why keep these stuff, I will feel the scope lack clarity.

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).
"
[Qin]: Okay.
> 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...
[Qin]: So ND proxying and binding is not state of art or prior of art but the mechanism specified in this document? If the answer is yes, please point where they are specified in this draft.
> 3.Section 3 I Is ND-proxying and binding are 
> 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.

[Qin]: I like the figure in section 3.7 which provide a whole picture for me, but it looks the scope of this architecture work is more than that. Would it be great to have a similar picture for an architecture overview, that will help readers better understand it.
If you don't tell me, I don't see the connection between section 3.7 and section 4.2, if you can point reader in section 3 to read details in section 4, that will be great.
> 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 ; )
[Qin]: works for me.
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.

[Qin]: The proposed changes look good, thanks.

> 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.

[Qin]: Not sure the importance of this section, how it is related to section 4.7 and section 4.8, 
can you delete it or consolidated into existing section?

> 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.

[Qin]: Thanks for rewriting. The proposed change is much better now.

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.

[Qin]: Jealous on you writing such lyrics acknowledge section I have never seen before,:-), you can ignore my comment here.

> 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.

[Qin]: Thank for clarification, works for me.

Please