IETF Last Call Review of draft-ietf-cats-usecases-requirements-12
review-ietf-cats-usecases-requirements-12-opsdir-lc-barguil-2026-01-13-01

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