Hi, I have been selected as the Operational Directorate (OpsDir) reviewer for this Internet-Draft.

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of “Guidelines for Considering Operations and Management in IETF Specifications” can be found at:
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/

While these comments are primarily intended for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.

Document: draft-ietf-cats-usecases-requirements-11

Reviewer: Samier Barguil

Review Date: 01-14-2026

Intended Status: Standards Track

Summary

This Internet-Draft defines requirements and use cases for steering traffic in distributed computing environments using both network and computing resource metrics. The document shows strong awareness of operational constraints and aligns well with the guidance in RFC 5706bis. No major operational issues were identified. A small number of editorial nits should be addressed prior to publication.

General Operational Comments (RFC 5706bis Alignment)

The draft demonstrates significant consideration for operational feasibility by defining requirements that address practical constraints of network and computing systems, including:

Scalability and Cost: Requirement R6 states that the Resource Model must be executable in a scalable manner and at an “affordable cost” in terms of memory footprint and energy consumption.

Network Stability: Requirement R11 mandates that the use of metrics MUST avoid introducing routing loops or path oscillations.

Handling Dynamic Metrics: The draft acknowledges the highly dynamic nature of computing metrics. Requirement R16 specifies that the system MUST NOT be sensitive to metric update frequency or vulnerable to the distribution mechanisms used.

Resource Management: Requirement R20 aims to prevent operational strain on network devices by requiring that the system MUST avoid maintaining per-flow state for specific applications.

Metric Staleness: Requirement R8 ensures operational accuracy by requiring mechanisms to indicate when a metric value is no longer valid.

Overall, these requirements reflect good alignment with operational best practices.

Nits

The following typographical and editorial issues were noted:

- categoried: In Section 4.1, latency is described as being “categoried” into various delays.

- could't: Used in the analysis of end-to-end delay requirements.

- newtork: This misspelling appears three times in the labels for Figure 3 (e.g., “newtork|delay(9ms)”).

- maneuveur: Used in the context of intelligent transportation.

- severer: Used to describe the overload of edge sites (e.g., “become much severer”).

- initail: Found in Appendix A regarding the “initail charter of the CATS Working Group”.

- modificaition: Found in Appendix A regarding the design of the CATS framework.

- stilluse: A spacing error in Appendix A.1: “in the figure we stilluse the old terminology”.