# Internet AD comments for draft-ietf-raw-architecture-27
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S2

* "and hop count turns into a bad idea as the link budget drops with
   the distance"

  I think this means "drops with the physical distance".  If so, that
  might be a useful clarification as the mention of "hop count" can
  imply a different context for interpreting "distance" -- one that
  doesn't make any sense (i.e. link budget has nothing to do with the
  number of hops).

* "subset of the hops arof the packet rate observed"

  "arof"?  I couldn't parse this sentence in general.

### S3.1.6

* This says that PER is the ratio of packets received in error
  (with errors?) to the total transmitted.  Should the denominator
  be total received?  Only the sender can know the total transmitted,
  as the receiver might not have received some packets at all (so
  no errors could be detected in a packet that never arrived).

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

# Éric Vyncke, INT AD, comments for draft-ietf-raw-architecture-27
CC @evyncke

Thank you for the work put into this document even if it not so easy to read when it dives in the complexities of RAW & DetNet.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to János Farkas for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Brian Haberman, the Internet directorate reviewer, and to Dave Thaler, the IoT directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-raw-architecture-25-intdir-telechat-haberman-2025-06-30/ (and I have read the author's reply)
https://datatracker.ietf.org/doc/review-ietf-raw-architecture-25-iotdir-telechat-thaler-2025-07-02/ (and I have read the author's discussion with Dave)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Section 1

Please add an informative reference to `IEEE 802.1 Time-Sensitive networking` and to `Time Slotted Channel Hopping (TSCH)`.

### Section 2

I am unable to parse `RAW and DetNet serve application flows that require a special treatment along the paths that provide that treatment.`, please consider re-phrasing it.

### Section 3

Missing word(s) in `that are defined in [DetNet-OAM] but .` ?

### Section 3.1

Thanks for this useful terminology section.

### Section 3.3.1

Who is the `we` in `we refer to that complex scenario` ? The author ? the WG ? the IETF community ? Please be accurate (or use the passive voice). Possiby in other places as well.

### Section 4.1.1

Should some reactions be added after `prompt detection of failures as they occur`?

### Section 4.1.1.3

Is there a need to introduce the FCAPS acronym ?

### Section 5.1

It is of course a difficult issue to fix w/o changing the flow, but referring to figure that are much further down in the text is not easy for the reader.

Unsure whether the use of "wisdom" fits an IETF document in `generates knowledge and wisdom`...

### Section 5.2

s/which can be tuned to unsure /which can be tuned to *e*nsure / ?

### Section 6.2

Like in all control loop, it is essential to aim for stability without oscillation. The document seems to be light on this aspect.

### Section 6.3

RAN in the figure appears before the expansion later in the text.

## NITS (non-blocking / cosmetic)

### Section 1

s/. it/. It/ but I will stop noting these nits as the RFC Editor will make another pass.

### Section 2

s/Operating at the Layer-3/Operating at the layer 3/ ?

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)