This is an interesting document to read, thanks. 

Please note the TSV-ART review by Wes, at review-ietf-raw-architecture-25-tsvart-lc-eddy-2025-06-19-00. I agree with the review and support all the comments. 

As noted in that review, the multiple definition of terms is a little distracting if you read through this document DLEP is defined more than once; as are: OODA, OAM, NC, ARQ, HARQ, FEC, and some other terms also. A careful read to avoid repetition would significantly improve the readability of this well written document.

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.

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.

## The text you quoted does not appear as such in the final version. Please 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. 

# YANG Model: Be consistent with the reco in RFC8407bis for the terminology usage

Please change all such occurrences in the draft to “YANG data model”.

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

# Check the classification of many references currently marked as normative

For example, I don’t 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’t think RFC4655 is normative as well given that the 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.

Cheers,
Med