MIME-Version: 1.0
References: 
 <175196630576.2041761.15343195449709394413@dt-datatracker-6fcb845cd4-p6tkq>
In-Reply-To: 
 <175196630576.2041761.15343195449709394413@dt-datatracker-6fcb845cd4-p6tkq>
From: Pascal Thubert <pascal.thubert@gmail.com>
Date: Fri, 11 Jul 2025 16:15:54 +0200
Message-ID: 
 <CADPqcJK_wV3T+t=Pp72hHR3LY5CryWoHVdrAvtkq5jhJRM7HXw@mail.gmail.com>
To: Mohamed Boucadair <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary="00000000000065338a0639a7f37d"
Message-ID-Hash: J3WCGVJUVOB66ELQPVBNTCD343TLXEFV
CC: The IESG <iesg@ietf.org>, draft-ietf-raw-architecture@ietf.org,
 detnet-chairs@ietf.org, detnet@ietf.org, eve_schooler@acm.org,
 janos.farkas@ericsson.com
Precedence: list
Subject: =?utf-8?q?=5BDetnet=5D_Re=3A_Mohamed_Boucadair=27s_No_Objection_on_draft-iet?=
 =?utf-8?q?f-raw-architecture-27=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/detnet/Ou1QzYg2FiY3ma3Sba8QPXhi2AY>

--00000000000065338a0639a7f37d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Med :)

Many thanks for your review!

I placed proposed changes in guthub as
https://github.com/raw-wg/raw-architecture/commit/b91d50c2128f5bf560f1b3dd9=
0c8fae87249a058

Please see below for the details:


> ----------------------------------------------------------------------
>
> Hi Pascal,
>
> Thank you for the effort put into this document. I find it well-written,
> interesting, and useful.
>
> Thanks to Giuseppe Fioccola for the OPSDIR review and Pascal for engaging
> and
> agreeing changes. I like the new OAM text you proposed.
>

Well, there was more discussion in the thread you contributed to. Greg
pointed that the DetNet terminology is agreed upon and consistent within
the DetNet world at least, so the word of caution about not using some
terms therein may be unnecessary within that context.
I'm trying to reach a consensus in-between. The current proposed text in
GitHub is:

"
  RAW reuses terminology defined for Operations, Administration, and
   Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM
   for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods
   (with Hybrid Types In-Between)" [RFC7799].  "Guidelines for
   Characterizing OAM" [I-D.ietf-opsawg-oam-characterization] provides
   additional semantics of the terms Active, Passive, Hybrid, and In-
   Packet OAM that are consistent with [RFC7799].  It also warns about
   potential inconsistencies in the way the terms "in-band" and "out-of-
   band" are used across the IETF; the DetNet reference for those terms
   is [DetNet-OAM].

"
Is that acceptable?


> Please find below some very minor comments:
>
> # Gymnastic :-)
>
> CURRENT:
>    RAW extends the DetNet services by providing elements that are
>    specialized for transporting IP flows over deterministic radio
>    technologies such as listed in [RAW-TECHNOS].  Conceptually, RAW is
>    agnostic to the lower layer, though the capability to control latency
>    is assumed to assure the DetNet services that RAW extends.
>
> There is a tension between the two sentences (and even some inconsistency
> given
> W part of RAW at the first place :-)), but I think this reflects the
> spirit of
> RAW. Thanks for having included this section early in the document.
>
> # PANRG Path Properties
>
> CURRENT:
>    Section 2 of [I-D.irtf-panrg-path-properties] points to a longer,
>    more modern definition of path, which begins as follows:
>
>    |  A sequence of adjacent path elements over which a packet can be
>    |  transmitted, starting and ending with a node.  A path is
>    |  unidirectional.  Paths are time-dependent, i.e., the sequence of
>    |  path elements over which packets are sent from one node to another
>    |  may change.  A path is defined between two nodes.
>
> ## Please note that draft was published as RFC 9473.
>

Thanks for shepherding it :)


>
> ## The text you quoted does not appear as such in the final version. Plea=
se
> update it
>
> NEW:
>       A sequence of adjacent path elements over which a packet can
>       be transmitted, starting and ending with a node.
>
>       Paths are unidirectional and time-dependent, i.e., there can be a
>       variety of paths from one node to another, and the path over which
>       packets are transmitted may change.  A path definition can be
>       strict (i.e., the exact sequence of path elements remains the
>       same) or loose (i.e., the start and end node remain the same, but
>       the path elements between them may vary over time).
>
>       The representation of a path and its properties may depend on the
>       entity considering the path.  On the one hand, the representation
>       may differ due to entities having partial visibility of path
>       elements comprising a path or their visibility changing over time.
>
> # Do we really need these terms;
>
> CURRENT:
> 3.5.2.  Service Level Objective
>
>    A service level objective (SLO) is one term in the SLA, for which
>    specific network setting and operations are implemented.  For
>    instance, a dynamic tuning of the packet redundancy addresses an SLO
>    of consecutive losses in a row by augmenting the chances of delivery
>    of a packet that follows a loss.
>
> 3.5.3.  Service Level Indicator
>
>    A service level indicator (SLI) measures the compliance of an SLO to
>    the terms of the contract.  It can be for instance, the statistics of
>    individual losses and losses in a row as time series.
>
> These are not called in the main text.
>

The architecture is also a base reference for the work to come; e.g., the
RAW framework that uses the term.
More than that, this illustrates that a sentence using SLO was missing.
I reworked the last sentence of the introduction, moving the paragraph on
Lower Layer API deeper in the spec.
The proposed new text reads as:
"
   The intent of RAW is to meet Service Level Objectives (SLO) in terms
   of packet delivery ratio (PDR), maximum contiguous losses or latency
   boundaries for DetNet flows over mixes of wired and wireless
   networks, including wireless access and meshes (see Section 2 for
   more on the RAW problem).  This document introduces and/or leverages
   terminology (see Section 3), principles (see Section 4), and concepts
   such as protection path and recovery graph, to put together a
   conceptual model for RAW (see Section 5), and, based on that model,
   elaborate on an in-network optimization control loop (see Section 6).
"



>
> # YANG Model: Be consistent with the reco in RFC8407bis for the terminolo=
gy
> usage
>
> Please change all such occurrences in the draft to =E2=80=9CYANG data mod=
el=E2=80=9D.
>
>
done


> # SLA vs SLO
>
> Section 6 says:
>
>    The overall OODA Loop optimizes the use of redundancy to achieve the
>    required reliability and availability Service Level Agreement (SLA)
>    while minimizing the use of constrained resources such as spectrum
>    and battery.
>
> But reliability and availability are SLOs as these can be part of traffic
> performance parameters enclosed in an SLA. Refer, for example, to RFC9544=
.
>

Changed to SLO. Also added text in a new terminology subsection, I agree it
would be a useful pointer for the subsequent work:
"
3.5.4.  Precision Availability Metrics

   Precision Availability Metrics (PAMs) [RFC9544] aim at capturing
   service levels for a flow, specifically the degree to which the flow
   complies with the SLOs that are in effect.
"


>
> # Check the classification of many references currently marked as normati=
ve
>
> For example, I don=E2=80=99t think the following one is normative:
>
> CURRENT:
>
>    Nevertheless, deterministic capabilities are required in a number of
>    wireless use cases as well [RAW-USE-CASES].
>
>    ..
>
>    [RAW-USE-CASES]
>               Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F.
>               Theoleyre, "RAW Use-Cases", Work in Progress, Internet-
>               Draft, draft-ietf-raw-use-cases-11, 17 April 2023,
>               <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
>               cases-11>.
>
> Likewise, I don=E2=80=99t think RFC4655 is normative as well given that t=
he only
> citation is as follows:
>
> CURRENT:
>    [I-D.ietf-detnet-controller-plane-framework], and may use a Path
>    computation Element (PCE) [RFC4655]
>
> Idem for [INT-ARCHI], [RAW-TECHNOS], etc.
>
> Please do a full check of your entries and move at least the ones cited
> above
> to be under Informative. Thanks.
>

I moved them and others. But left  [RAW-TECHNOS]. Reason being, I was
explained that for an "informational" I-D, which is not "normative" anyway,
we could leverage the "normative" section for the "important reading". For
RAW, I'd argue that understanding the lower layers is important reading.

Again, many thanks for your review, and please let me know if more is
desirable.

--=20
Pascal

--00000000000065338a0639a7f37d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hello Med :)<div><br></div><div>Many than=
ks for your review!</div><div><br></div><div>I placed proposed changes=C2=
=A0in guthub=C2=A0as=C2=A0<a href=3D"https://github.com/raw-wg/raw-architec=
ture/commit/b91d50c2128f5bf560f1b3dd90c8fae87249a058">https://github.com/ra=
w-wg/raw-architecture/commit/b91d50c2128f5bf560f1b3dd90c8fae87249a058</a></=
div><div><br></div><div>Please see below for the details:</div><div><br></d=
iv></div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br>
----------------------------------------------------------------------<br>
<br>
Hi Pascal,<br>
<br>
Thank you for the effort put into this document. I find it well-written,<br=
>
interesting, and useful.<br>
<br>
Thanks to Giuseppe Fioccola for the OPSDIR review and Pascal for engaging a=
nd<br>
agreeing changes. I like the new OAM text you proposed.<br></blockquote><di=
v><br></div><div>Well, there was more discussion in the thread you contribu=
ted to. Greg pointed that the DetNet terminology is agreed upon and consist=
ent within the DetNet world at least, so the word of caution about not usin=
g some terms therein may be unnecessary within that context.</div><div>I=
9;m trying to reach a consensus in-between. The current proposed text in Gi=
tHub is:</div><div><br></div><div>&quot;</div><div>=C2=A0 RAW reuses termin=
ology defined for Operations, Administration, and<br>=C2=A0 =C2=A0Maintenan=
ce (OAM) protocols in Section 1.1 of the &quot;Framework of OAM<br>=C2=A0 =
=C2=A0for DetNet&quot; [DetNet-OAM] and &quot;Active and Passive Metrics an=
d Methods<br>=C2=A0 =C2=A0(with Hybrid Types In-Between)&quot; [RFC7799]. =
=C2=A0&quot;Guidelines for<br>=C2=A0 =C2=A0Characterizing OAM&quot; [I-D.ie=
tf-opsawg-oam-characterization] provides<br>=C2=A0 =C2=A0additional semanti=
cs of the terms Active, Passive, Hybrid, and In-<br>=C2=A0 =C2=A0Packet OAM=
 that are consistent with [RFC7799].=C2=A0 It also warns about<br>=C2=A0 =
=C2=A0potential inconsistencies in the way the terms &quot;in-band&quot; an=
d &quot;out-of-<br>=C2=A0 =C2=A0band&quot; are used across the IETF; the De=
tNet reference for those terms<br>=C2=A0 =C2=A0is [DetNet-OAM].<br><br></di=
v><div>&quot;</div><div>Is that acceptable?=C2=A0</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
<br>
Please find below some very minor comments:<br>
<br>
# Gymnastic :-)<br>
<br>
CURRENT:<br>
=C2=A0 =C2=A0RAW extends the DetNet services by providing elements that are=
<br>
=C2=A0 =C2=A0specialized for transporting IP flows over deterministic radio=
<br>
=C2=A0 =C2=A0technologies such as listed in [RAW-TECHNOS].=C2=A0 Conceptual=
ly, RAW is<br>
=C2=A0 =C2=A0agnostic to the lower layer, though the capability to control =
latency<br>
=C2=A0 =C2=A0is assumed to assure the DetNet services that RAW extends.<br>
<br>
There is a tension between the two sentences (and even some inconsistency g=
iven<br>
W part of RAW at the first place :-)), but I think this reflects the spirit=
 of<br>
RAW. Thanks for having included this section early in the document.<br>
<br>
# PANRG Path Properties<br>
<br>
CURRENT:<br>
=C2=A0 =C2=A0Section 2 of [I-D.irtf-panrg-path-properties] points to a long=
er,<br>
=C2=A0 =C2=A0more modern definition of path, which begins as follows:<br>
<br>
=C2=A0 =C2=A0|=C2=A0 A sequence of adjacent path elements over which a pack=
et can be<br>
=C2=A0 =C2=A0|=C2=A0 transmitted, starting and ending with a node.=C2=A0 A =
path is<br>
=C2=A0 =C2=A0|=C2=A0 unidirectional.=C2=A0 Paths are time-dependent, i.e., =
the sequence of<br>
=C2=A0 =C2=A0|=C2=A0 path elements over which packets are sent from one nod=
e to another<br>
=C2=A0 =C2=A0|=C2=A0 may change.=C2=A0 A path is defined between two nodes.=
<br>
<br>
## Please note that draft was published as RFC 9473.<br></blockquote><div><=
br></div><div>Thanks for shepherding=C2=A0it :)</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
<br>
## The text you quoted does not appear as such in the final version. Please=
<br>
update it<br>
<br>
NEW:<br>
=C2=A0 =C2=A0 =C2=A0 A sequence of adjacent path elements over which a pack=
et can<br>
=C2=A0 =C2=A0 =C2=A0 be transmitted, starting and ending with a node.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 Paths are unidirectional and time-dependent, i.e., the=
re can be a<br>
=C2=A0 =C2=A0 =C2=A0 variety of paths from one node to another, and the pat=
h over which<br>
=C2=A0 =C2=A0 =C2=A0 packets are transmitted may change.=C2=A0 A path defin=
ition can be<br>
=C2=A0 =C2=A0 =C2=A0 strict (i.e., the exact sequence of path elements rema=
ins the<br>
=C2=A0 =C2=A0 =C2=A0 same) or loose (i.e., the start and end node remain th=
e same, but<br>
=C2=A0 =C2=A0 =C2=A0 the path elements between them may vary over time).<br=
>
<br>
=C2=A0 =C2=A0 =C2=A0 The representation of a path and its properties may de=
pend on the<br>
=C2=A0 =C2=A0 =C2=A0 entity considering the path.=C2=A0 On the one hand, th=
e representation<br>
=C2=A0 =C2=A0 =C2=A0 may differ due to entities having partial visibility o=
f path<br>
=C2=A0 =C2=A0 =C2=A0 elements comprising a path or their visibility changin=
g over time.<br>
<br>
# Do we really need these terms;<br>
<br>
CURRENT:<br>
3.5.2.=C2=A0 Service Level Objective<br>
<br>
=C2=A0 =C2=A0A service level objective (SLO) is one term in the SLA, for wh=
ich<br>
=C2=A0 =C2=A0specific network setting and operations are implemented.=C2=A0=
 For<br>
=C2=A0 =C2=A0instance, a dynamic tuning of the packet redundancy addresses =
an SLO<br>
=C2=A0 =C2=A0of consecutive losses in a row by augmenting the chances of de=
livery<br>
=C2=A0 =C2=A0of a packet that follows a loss.<br>
<br>
3.5.3.=C2=A0 Service Level Indicator<br>
<br>
=C2=A0 =C2=A0A service level indicator (SLI) measures the compliance of an =
SLO to<br>
=C2=A0 =C2=A0the terms of the contract.=C2=A0 It can be for instance, the s=
tatistics of<br>
=C2=A0 =C2=A0individual losses and losses in a row as time series.<br>
<br>
These are not called in the main text.<br></blockquote><div><br></div><div>=
The architecture is also a base reference for the work to come; e.g., the R=
AW framework that uses the term.=C2=A0</div><div>More than that, this illus=
trates that a sentence using SLO was missing.</div><div>I reworked the last=
 sentence of the introduction, moving the paragraph on Lower Layer API deep=
er in the spec.</div><div>The proposed new text reads as:</div><div>&quot;<=
/div><div>=C2=A0 =C2=A0The intent of RAW is to meet Service Level Objective=
s (SLO) in terms<br>=C2=A0 =C2=A0of packet delivery ratio (PDR), maximum co=
ntiguous losses or latency<br>=C2=A0 =C2=A0boundaries for DetNet flows over=
 mixes of wired and wireless<br>=C2=A0 =C2=A0networks, including wireless a=
ccess and meshes (see Section 2 for<br>=C2=A0 =C2=A0more on the RAW problem=
).=C2=A0 This document introduces and/or leverages<br>=C2=A0 =C2=A0terminol=
ogy (see Section 3), principles (see Section 4), and concepts<br>=C2=A0 =C2=
=A0such as protection path and recovery graph, to put together a<br>=C2=A0 =
=C2=A0conceptual model for RAW (see Section 5), and, based on that model,<b=
r>=C2=A0 =C2=A0elaborate on an in-network optimization control loop (see Se=
ction 6).</div><div>&quot;</div><div><br></div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
<br>
# YANG Model: Be consistent with the reco in RFC8407bis for the terminology=
<br>
usage<br>
<br>
Please change all such occurrences in the draft to =E2=80=9CYANG data model=
=E2=80=9D.<br>
<br></blockquote><div><br></div><div>done</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
# SLA vs SLO<br>
<br>
Section 6 says:<br>
<br>
=C2=A0 =C2=A0The overall OODA Loop optimizes the use of redundancy to achie=
ve the<br>
=C2=A0 =C2=A0required reliability and availability Service Level Agreement =
(SLA)<br>
=C2=A0 =C2=A0while minimizing the use of constrained resources such as spec=
trum<br>
=C2=A0 =C2=A0and battery.<br>
<br>
But reliability and availability are SLOs as these can be part of traffic<b=
r>
performance parameters enclosed in an SLA. Refer, for example, to RFC9544.<=
br></blockquote><div><br></div><div>Changed to SLO. Also added text in a ne=
w terminology subsection, I agree it would=C2=A0be a useful pointer for the=
 subsequent work:</div><div>&quot;</div><div>3.5.4.=C2=A0 Precision Availab=
ility Metrics<br><br>=C2=A0 =C2=A0Precision Availability Metrics (PAMs) [RF=
C9544] aim at capturing<br>=C2=A0 =C2=A0service levels for a flow, specific=
ally the degree to which the flow<br>=C2=A0 =C2=A0complies with the SLOs th=
at are in effect.</div><div>&quot;</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
# Check the classification of many references currently marked as normative=
<br>
<br>
For example, I don=E2=80=99t think the following one is normative:<br>
<br>
CURRENT:<br>
<br>
=C2=A0 =C2=A0Nevertheless, deterministic capabilities are required in a num=
ber of<br>
=C2=A0 =C2=A0wireless use cases as well [RAW-USE-CASES].<br>
<br>
=C2=A0 =C2=A0..<br>
<br>
=C2=A0 =C2=A0[RAW-USE-CASES]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bernardos, C. J., Papadopo=
ulos, G. Z., Thubert, P., and F.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Theoleyre, &quot;RAW Use-C=
ases&quot;, Work in Progress, Internet-<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft, draft-ietf-raw-use-=
cases-11, 17 April 2023,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"https://dat=
atracker.ietf.org/doc/html/draft-ietf-raw-use-" rel=3D"noreferrer" target=
=3D"_blank">https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-</a><b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases-11&gt;.<br>
<br>
Likewise, I don=E2=80=99t think RFC4655 is normative as well given that the=
 only<br>
citation is as follows:<br>
<br>
CURRENT:<br>
=C2=A0 =C2=A0[I-D.ietf-detnet-controller-plane-framework], and may use a Pa=
th<br>
=C2=A0 =C2=A0computation Element (PCE) [RFC4655]<br>
<br>
Idem for [INT-ARCHI], [RAW-TECHNOS], etc.<br>
<br>
Please do a full check of your entries and move at least the ones cited abo=
ve<br>
to be under Informative. Thanks.<br></blockquote><div><br></div><div>I move=
d them and others. But left=C2=A0 [RAW-TECHNOS]. Reason being, I was explai=
ned that for an &quot;informational&quot; I-D, which=C2=A0is not &quot;norm=
ative&quot; anyway, we could=C2=A0leverage the &quot;normative&quot; sectio=
n for the &quot;important reading&quot;. For RAW, I&#39;d argue that unders=
tanding the lower layers is important reading.</div><div><br></div><div>Aga=
in, many thanks for your review, and please let me know if more is desirabl=
e.</div><div>=C2=A0</div></div><span class=3D"gmail_signature_prefix">-- </=
span><br><div dir=3D"ltr" class=3D"gmail_signature">Pascal</div></div>

--00000000000065338a0639a7f37d--