Re: [Raw] Shepherding review of draft-ietf-raw-technologies

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Carlos

Many thanks for your review! The response is collegial by all the authors, you'll find the answers and names within <> tags.

Please see below

All the best

Pascal

---------

I find the document well written and quite detailed, probably too detailed sometimes. I think we should probably reduce the level of detail in some parts to what is really needed to understand the applicability of these technologies to DETNET/RAW. Some additional comments below.

<Pascal> Did quite a bit of clean up in the TSCH section in particular </Pascal>

Abstract:

“This document presents a series of recent technologies” —> I’d rewrite it to say that it identifies/describes a series of recent technologies and analyzes its applicability to deterministic flows, or something like that.

<Pascal> I keep that in mind, unclear what to write but more reviews will follow </Pascal>

1. Introduction:

“every packet reach” —> “every packet reaches”

“network must highly” —> “network must be highly”

“On the one hand the network” —> “On the one hand, the network”

“time interval. .” —> “time interval.”

Expand P2MP

<Pascal>
all done, removed P2MP
</Pascal>


2. Terminology


“This specification” —> “This document”
<Pascal>
done
</Pascal>

“Deterministic Flow Identifier (L2) :” —> “Deterministic Flow Identifier (L2):”

Add reference regarding PCE.

“PREOF :” —> “PREOF:”
<Pascal>
Now refer to RAW Architecture
</Pascal>

Expand MUMIMO.
<Pascal>
done
</Pascal>

Check for consistency the definition of Track that has been discussed in the framework/architecture documents.


<Pascal>
done
</Pascal>

3.1 Scheduling for Reliability

“the Precision Time Protocol” —> “the Precision Time Protocol (PTP)”

<Pascal>
removed
</Pascal>

“A typical process control loop will tolerate an occasional

packet loss, but a loss of several packets in a row will cause an

emergency stop (e.g., after 4 packets lost, within a period of 1

second” —> Add reference supporting this.

<Pascal>
removed
</Pascal>


3.3  Benefits of Scheduling

Expand IOW

<Pascal>
removed
</Pascal>

“a nd” —> “and”


<Pascal>
done
</Pascal>


Section 4

<Dave> those comments are similar to the ones processed for Victoria's review and answered there </Dave>
I miss some text introducing the technologies that are going to be explained in Sections 4-7.



4.1  Provenance and Documents

“The main 802.11ax and 802.11be capabilities and their relevance to RAW are discussed in the remainder of this document.” —> it is not only those, also 802.11ad and 802.11ay. Besides, I think it should be explained why those from the previous list of amendments are described.



4.2.1 General Characteristics

Expand AP.



4.2.2 Applicability to deterministic flows

“in [Fang_2021].Nevertheless,” —> “in [Fang_2021].Nevertheless ,”



4.2.2.2. Scheduling for bounded latency and diversity

Expand MCS



4.4.1 General Characteristics

Remove space in “ .” at the end of each paragraph.



5.2.2.1.  Centralized Path Computation

Add caption to Figure 2.


<Pascal> done </Pascal>

5.2.2.2 6TiSCH Tracks

“oveall” —> “overall”

<Pascal> done </Pascal>

Overall, I find section 5 too long, especially comparing with section 4. I think it’d be useful to try to do an exercise of consistency across sections 4 to 7.


<Pascal> I trimmed, please see diffs! </Pascal>

6.1.  Provenance and Documents

I’d remove the first sentence, as it does not really add much.

<Janos>
The goal with the sentence is to introduce 3GPP, which may be useful for some
readers. Otherwise it could be deleted, nonetheless, it may not hurt keeping it.
</Janos>


6.2. General Characteristics

I think we don’t need to go into that much details and at least I’d remove the last paragraph on authentication.

<Janos>
Well, I think each paragraph explains a different characteristics.
In particular, the last paragraph is about security. I guess it is better to
keep it as security is importatn. Each IETF documetn has a section dedicated to security.
</Janos>


6.4.1.  System Architecture

I know it is hard, but the text just mentions some of the core elements, while the figure 10 shows more. Maybe the text has to be a bit updated to mention this point.

<Janos>
Add:
"(Note that this document only explains key functions, however, Figure 10 provides a more detailed view.)"
</Janos>

6.4.5. Time-Sensitive Communications (TSC)

The 2nd and 3rd paragraphs explain concepts that are useful/needed to understand points made earlier in the document. Therefore, I think it might be worth moving that piece of text before each of the different technologies are deep dived into.

<Janos>
I'm not sure where to move.
The text is crafted in a way tp provide concise introduction to what comes later in 6.4.5, e.g., what TSN features are supported by 5G.
</Janos>

Shouldn’t the document mention something about ATSSS in the context of reliability and availability?

<Janos>
Well, we've got comments that too much details have been provided already. It seems better not to add more.
Furhtermore, ATSSS is not for time-critical traffic. It has no relations to URLLC, M-MTC, or I-IoT.
In addidion, ATSSS is not a sole 5G technology, it is for a combination of 3GPP and non-3GPP access.
Moreover, ATSSS is not capabale for any kind of high-reliability provided by DetNet PREOF.
So, it seems better for me not to add ATSSS.
</Janos>


9. Security Considerations

I find the current text a bit insufficient. Either we: (ii) clearly state that this document is purely informational on some technologies that could be applicable to RAW, each of which have their own security mechanisms in place; or (ii) we provide much more details.



Sections 4 and 5 do not have a Summary subsection.


--
CARLOS J. BERNARDOS https://www.it.uc3m.es/cjbc/
Universidad Carlos III de Madrid
YouTube channel: https://www.youtube.com/CacharREDando/


regards,

Pascal
________________________________
De : CARLOS JESUS BERNARDOS CANO <[e-mail]>
Envoyé : lundi 26 juin 2023 16:25
À : [e-mail] <[e-mail]>
Cc : [e-mail] <[e-mail]>
Objet : Shepherding review of draft-ietf-raw-technologies

Dear authors,

Please find below my review as part of my shepherding of the document. Huge apologies for the belated review.

Thanks,

Carlos


Shepherd review of draft-ietf-raw-technologies-07


I find the document well written and quite detailed, probably too detailed sometimes. I think we should probably reduce the level of detail in some parts to what is really needed to understand the applicability of these technologies to DETNET/RAW. Some additional comments below.


Abstract:

“This document presents a series of recent technologies” —> I’d rewrite it to say that it identifies/describes a series of recent technologies and analyzes its applicability to deterministic flows, or something like that.


1. Introduction:

“every packet reach” —> “every packet reaches”

“network must highly” —> “network must be highly”

“On the one hand the network” —> “On the one hand, the network”

“time interval. .” —> “time interval.”

Expand P2MP


2. Terminology

“This specification” —> “This document”

“Deterministic Flow Identifier (L2) :” —> “Deterministic Flow Identifier (L2):”

Add reference regarding PCE.

“PREOF :” —> “PREOF:”

Expand MUMIMO.

Check for consistency the definition of Track that has been discussed in the framework/architecture documents.


3.1 Scheduling for Reliability

“the Precision Time Protocol” —> “the Precision Time Protocol (PTP)”

“A typical process control loop will tolerate an occasional

packet loss, but a loss of several packets in a row will cause an

emergency stop (e.g., after 4 packets lost, within a period of 1

second” —> Add reference supporting this.


3.3  Benefits of Scheduling

Expand IOW

“a nd” —> “and”


I miss some text introducing the technologies that are going to be explained in Sections 4-7.


4.1  Provenance and Documents

“The main 802.11ax and 802.11be capabilities and their relevance to RAW are discussed in the remainder of this document.” —> it is not only those, also 802.11ad and 802.11ay. Besides, I think it should be explained why those from the previous list of amendments are described.


4.2.1 General Characteristics

Expand AP.


4.2.2 Applicability to deterministic flows

“in [Fang_2021].Nevertheless,” —> “in [Fang_2021].Nevertheless ,”


4.2.2.2. Scheduling for bounded latency and diversity

Expand MCS


4.4.1 General Characteristics

Remove space in “ .” at the end of each paragraph.


5.2.2.1.  Centralized Path Computation

Add caption to Figure 2.


5.2.2.2 6TiSCH Tracks

“oveall” —> “overall”


Overall, I find section 5 too long, especially comparing with section 4. I think it’d be useful to try to do an exercise of consistency across sections 4 to 7.


6.1.  Provenance and Documents

I’d remove the first sentence, as it does not really add much.


6.2. General Characteristics

I think we don’t need to go into that much details and at least I’d remove the last paragraph on authentication.


6.4.1.  System Architecture

I know it is hard, but the text just mentions some of the core elements, while the figure 10 shows more. Maybe the text has to be a bit updated to mention this point.


6.4.5. Time-Sensitive Communications (TSC)

The 2nd and 3rd paragraphs explain concepts that are useful/needed to understand points made earlier in the document. Therefore, I think it might be worth moving that piece of text before each of the different technologies are deep dived into.

Shouldn’t the document mention something about ATSSS in the context of reliability and availability?


9. Security Considerations

I find the current text a bit insufficient. Either we: (ii) clearly state that this document is purely informational on some technologies that could be applicable to RAW, each of which have their own security mechanisms in place; or (ii) we provide much more details.


Sections 4 and 5 do not have a Summary subsection.

--
CARLOS J. BERNARDOS https://www.it.uc3m.es/cjbc/
Universidad Carlos III de Madrid
YouTube channel: https://www.youtube.com/CacharREDando/