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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Pascal, all,

Thanks for the review. I'm generally OK with the changes. I still think
that the 5G part would benefit from some of my comments (e.g., explaining
why ATSSS would not help improving reliability, while doing dual PDU
sessions does; I'd expect that ATSSS could be used as well, or considered
to be used in the future with some modifications), but I understand that
this is probably just different views, so I'm fine with keeping current
text.

Thanks,

Carlos

On Mon, Jul 10, 2023 at 11:21 AM Pascal Thubert (pthubert) <
[e-mail]> wrote:

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