Reliable and Available Wireless Architecture
draft-ietf-raw-architecture-30

[Ballot comment]
Thank you to Behcet Sarikaya for the GENART review

Thank you to the DETNET WG chairs for addressing my DISCUSS feedback via another consensus check to publish this document.

[Ballot discuss]
(This DISUSS feedback is for the DETNET WG Chairs and Responsible AD)

Given that this document was moved from the closed RAW WG to DETNET, I explicitly checked for consensus to publish this document during WGLC.  I note with appreciation that this document was explicitly added as a milestone during the DETNET -04 re-chartering process in April 2025.

I note that the shepherd report says:
==[ snip ]==
1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

The normal WG process has been followed with nothing special worth mentioning. The work was started in the RAW WG and has been completed in the DetNet WG after the merge of the RAW WG to the DetNet WG. The document reflects WG consensus, which represents strong concurrence of a number of individuals.

==[ snip ]==

However, upon review, I cannot find evidence of support to publish this document in the WG discussion during the WGLC.

The Datatracker history reports that the WGLC started in Oct-2024 and ended in Mar-2025.  Thank you to the WG chairs for using this state in the Datatracker.

==[ snip ]==
2025-03-15/-24 closed of WGLC (Lou Berger)
2024-10-18/-21 start WGLC (Lou Berger)
==[ snip ]==

The WGLC call thread on the DETNET ML started on 18-October-2024 at https://mailarchive.ietf.org/arch/msg/detnet/eYumAudcJqPFSARwmHRu8Mwfgi4/.
While I can find Last Call directorate reviews and responses from the document authors and WG chairs to these reviews, no one from the WG appears to have responded to the WGLC supporting publication.

Next, I assumed that the F2F plenary meeting discussions during the WGLC had established interest to publish this document.  However, the meeting minutes did not establish that either.  Caveat, I didn’t listen to the meeting recordings.

==[ snip ]==
The IETF 121 (Nov-2024) DETNET meeting (during the WGLC) has no tangible sense of consensus -- https://datatracker.ietf.org/doc/minutes-121-detnet-202411071300/

The IETF 122 (Mar-2025) DETNET meeting (also during the WGLC) has no mention of this document -- https://datatracker.ietf.org/doc/minutes-122-detnet-202503170230/
==[ snip ]==

Perhaps my search skills missed key interim meetings or mailing list threads.  Could some pointers please be provided that substantiate WG interest to publish.

[Ballot comment]
# 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).

[Ballot comment]

# É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 ;-)

[Ballot comment]
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,
              .

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

[Ballot comment]
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.

[Ballot comment]
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 would significantly improve the readability of this well written document.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-raw-architecture-25, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for IETF Last Call review by TSVART Completed: Ready with Nits. Reviewer: Wesley Eddy. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2025-06-24):

From: The IESG
To: IETF-Announce
CC: detnet-chairs@ietf.org, detnet@ietf.org, draft-ietf-raw-architecture@ietf.org, eve_schooler@acm.org, janos.farkas@ericsson.com, ketant.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Reliable and Available Wireless Architecture) to Informational RFC


The IESG has received a request from the Deterministic Networking WG (detnet)
to consider the following document: - 'Reliable and Available Wireless
Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-06-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Reliable and Available Wireless (RAW) extends the reliability and
  availability of DetNet to networks composed of any combination of
  wired and wireless segments.  The RAW Architecture leverages and
  extends RFC 8655, the Deterministic Networking Architecture, to adapt
  to challenges that affect prominently the wireless medium, notably
  intermittent transmission loss.  This document defines a network
  control loop that optimizes the use of constrained bandwidth and
  energy while assuring the expected DetNet services.  The loop
  involves a new Point of Local Repair (PLR) function in the DetNet
  service sublayer that dynamically selects the DetNet path(s) for
  packets to route around local connectivity degradation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4898/
  https://datatracker.ietf.org/ipr/5702/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The normal WG process has been followed with nothing special worth mentioning. The work was started in the RAW WG and has been completed in the DetNet WG after the merge of the RAW WG to the DetNet WG.
The document reflects WG consensus, which represents strong concurrence of a number of individuals.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an architecture document without protocol specification.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Some work of the TEAS WG has been leveraged. There has been cross-WG participation at the contribution and the WG review level.  No specific review needed or requested.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A, there is no such definition in the document.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A, the document does not contain YANG module.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A, no formal language in the document.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues have been identified.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status is Informational. This is the appropriate for an architecture document.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, see: https://mailarchive.ietf.org/arch/msg/detnet/Tvkvt9Ne5094i5SGe1L4ArqgEvM/.
See also IPR disclosures at: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-raw-architecture, and corresponding additional discussion: https://mailarchive.ietf.org/arch/msg/detnet/CZmHyORGlKQXCkPVCUXXf1eE-Co/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.
Less than 5 authors.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No issues.
There is some warning related to informational reference, which can be fixed by the RFC editor or the next revision, if one is needed.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The currently normative “use cases” documents (RFC 8578 and RFC 9450) might be considered to be made informative references.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are freely available to anyone.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

N/A, no IANA actions.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No expert review needed.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The normal WG process has been followed with nothing special worth mentioning. The work was started in the RAW WG and has been completed in the DetNet WG after the merge of the RAW WG to the DetNet WG.
The document reflects WG consensus, which represents strong concurrence of a number of individuals.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an architecture document without protocol specification.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Some work of the TEAS WG has been leveraged. There has been cross-WG participation at the contribution and the WG review level.  No specific review needed or requested.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A, there is no such definition in the document.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A, the document does not contain YANG module.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A, no formal language in the document.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues have been identified.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status is Informational. This is the appropriate for an architecture document.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, see: https://mailarchive.ietf.org/arch/msg/detnet/Tvkvt9Ne5094i5SGe1L4ArqgEvM/.
See also IPR disclosures at: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-raw-architecture, and corresponding additional discussion: https://mailarchive.ietf.org/arch/msg/detnet/CZmHyORGlKQXCkPVCUXXf1eE-Co/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.
Less than 5 authors.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No issues.
There is some warning related to informational reference, which can be fixed by the RFC editor or the next revision, if one is needed.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The currently normative “use cases” documents (RFC 8578 and RFC 9450) might be considered to be made informative references.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are freely available to anyone.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

N/A, no IANA actions.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No expert review needed.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Pre-WGLC IPR call: https://mailarchive.ietf.org/arch/msg/detnet/Tvkvt9Ne5094i5SGe1L4ArqgEvM/
Received:
Pascal Thubert: https://mailarchive.ietf.org/arch/msg/detnet/KI4blT7DxSdsTczmwznHndSmV9k/
Lou Berger: https://mailarchive.ietf.org/arch/msg/detnet/jREnPquui9yQyJxavCuHegFNruw/
Xavier Vilajosana: https://mailarchive.ietf.org/arch/msg/detnet/-rFyEVmpaIjp8rkNq2RHcE2xUaU/
Geogios Papadopolous: https://mailarchive.ietf.org/arch/msg/detnet/tnZqw6HYtZlujCbKSLO6tlorgjI/
Remous-Aris Koutsiamanis: https://mailarchive.ietf.org/arch/msg/detnet/GnBKavt8TojtNSMJ76ZfPzqS_hA/
Rex Buddenberg: https://mailarchive.ietf.org/arch/msg/raw/f3Ww5mT67w3mc3Xzsnym8MZXPMk/
Greg Mirsky: https://mailarchive.ietf.org/arch/msg/detnet/GQbb92iaehp7tNrKYF1u5a57mEY/