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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Tue, 11 July 2023 06:41 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: raw@ietfa.amsl.com
Delivered-To: raw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D7DC151527 for <raw@ietfa.amsl.com>; Mon, 10 Jul 2023 23:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.995
X-Spam-Level:
X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeknF63Y-n-y for <raw@ietfa.amsl.com>; Mon, 10 Jul 2023 23:41:10 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842A5C15108C for <raw@ietf.org>; Mon, 10 Jul 2023 23:41:10 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-4faaaa476a9so8528710e87.2 for <raw@ietf.org>; Mon, 10 Jul 2023 23:41:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; t=1689057668; x=1691649668; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NjFJ79x60+39mI0LfnJSk3FSey10LyKdtXjzR4A0H00=; b=RcmAWqMwPy/qSc9jNP6SdP98jnMOyOGywjYQF8jainIcR6ubmr1m3qDIIkY73H0LtS 4VT00dAqdDNaxEtsDEBBhWKdbMmojr4pWmbbzGbQ6FSWQ3wO0fVRiGJXpG8Y1nNBlfYh 95+RJwsDUgElpfRDTeu+ddSHnhd5zxfDfjs6KXKD6qf4irdPGBhU7CdP3kChodQA3Uqg kV6669U8cDiEWyjxlLqxogU1q0ioNcvJRgiwGc8wOjkfksiCbcI9qE59QJGG+UppjQ/E 2aS/Icyy3tuAa86ssep9x+1R5xF2644gvgsn7Lt/5lfwslyYumBZMcTIswWCtWixq5hQ tOmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689057668; x=1691649668; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NjFJ79x60+39mI0LfnJSk3FSey10LyKdtXjzR4A0H00=; b=YgzgSwJ0rEIyUDPF/VbmBEEUp+oKxRr9aJAE+5Xi+XNlzjYdrby/47AQnWo1GLfBnD zyO01WNVu61Q/UHdyDJWP57vT4fyuvQ6ilBawv9SaTQHcVBAUA+wxGfRDGIdkOsgDGCq FXUdWopjKD/WkVKAPan6l3Zaf+MhCQP0ed5Bnn5JGb4zFTmd1V7otNU0WKKjzI7w2mXQ S25RY8aiWnefejn/WPEFzwCrJkE1VhhTDS0IQEvQneqjGQBQO+ZhAQDwrovIHStn+68k aPjOXSa4wFyLNennwHMJRC+M5GOkDFmrjB4L9M8Tk+gApZDIbzANuTjeTgCwF0o19eSp EKPg==
X-Gm-Message-State: ABy/qLbf8qXjUfowV5jdCkeqnsXmg033I/AhfG0GwfPwVbwU1pyEP0mU ckhuGbAWbO26AIV2vgXkb/FtSK96WVBr2TVcoe7+Zw==
X-Google-Smtp-Source: APBJJlHch86betsFDK4Jo7QiBklTf1bY9NpnuSvqzMCGz0T/SNMvvhKrd83+X0cN0biwDHj7AonCxr283IsilaTHtq4=
X-Received: by 2002:a05:6512:3253:b0:4fa:da4f:636f with SMTP id c19-20020a056512325300b004fada4f636fmr10599194lfr.32.1689057667995; Mon, 10 Jul 2023 23:41:07 -0700 (PDT)
MIME-Version: 1.0
References: <CALypLp9hyNLY3wzG5oVpD_A-OARKXFDOfYjM+dFNC9-KO77vXA@mail.gmail.com> <CO1PR11MB48810A4CACA04349869A69A0D830A@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB48810A4CACA04349869A69A0D830A@CO1PR11MB4881.namprd11.prod.outlook.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Tue, 11 Jul 2023 08:40:52 +0200
Message-ID: <CALypLp_HiMmRuW5BCuLLU3zejqK=UV_Om2QRxipnLABwz=1hog@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "draft-ietf-raw-technologies@ietf.org" <draft-ietf-raw-technologies@ietf.org>, "raw@ietf.org" <raw@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004ecc1406003062cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/gfI2BQgDhWmXQCHgSUtOoFBUgWc>
Subject: Re: [Raw] Shepherding review of draft-ietf-raw-technologies
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2023 06:41:15 -0000

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) <
pthubert@cisco.com> 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 <cjbc@it.uc3m.es>
> *Envoyé :* lundi 26 juin 2023 16:25
> *À :* draft-ietf-raw-technologies@ietf.org <
> draft-ietf-raw-technologies@ietf.org>
> *Cc :* raw@ietf.org <raw@ietf.org>
> *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/
>