Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements
draft-ietf-cats-usecases-requirements-14

[Ballot comment]

Thanks also to Zhed for his TSV-ART review and thanks to the authors and the WG for their work on this document and in resolving my DISCUSS topics.

Comments (non-blocking) follow:

Abstract :
I am curious about the more factors" mentioned in the introduction, could these be enumerated to set the focus of the document?

I see the following text: "However, it is undeniable that.." c- which seems a very strong assertion fro rthe iETF. IS it possible to rephrase this?

[Ballot comment]
Thanks to the authors and the WG for their work on this document and the discussion of my comments.

While the v13 introduced some improvements, it does not substantially address the points that I had raised. This comes down to the WG consensus to publish this document in its current state as opposed to my view that the document is not ready to be published (basically that it is still work-in-progress) since it leaves out (IMHO) important aspects that need to be addressed for the document to be helpful as an IETF RFC reference.

I am changing the position of my ballot from DISCUSS to ABSTAIN to not stand in the way of the WG consensus after discussions with the responsible AD.

Original DISCUSS ballot contents follow:

I have some points that I would like to discuss.

Should the problem statement not include gap analysis?

The objective of the CATS solution/framework is clear in the charter itself. I believe one of the goals of the Problem Statement analysis is to identify gaps in "how things are done today" (as in the functional blocks that exist and are in use today), what are the gaps that need to filed (new capabilities introduced by CATS - this is covered), and the external interfaces/interactions between the new and old to be developed. I find the Problem Statement portion lacking these details. There are no citations for the "current state of art" except for ALTO (not sure of its real world use) and the use of anycast. Mainly I was looking for the clients application interaction with the CATS solution.

Section 3.2 says:
"When a client issues a service request for a required service, the request is steered to one of the available service instances."

The details of what the envisioned/supported ways of making such a service request and what are gaps to "steer" it to available service instances are missing. Is this a DNS query? Are DNS servers meant to interact with CATS. Being a routing person, this is not my area of expertise and I was looking for some analysis from a routing area WG (with help of inputs from INT/ART/WIT) to cover these aspects (with appropriate citations).

Is there necessary clarity to publish these use-cases at this juncture of the development of the CATS framework/architecture?

The use-cases do not describe the current state of art (neither do I see adequate citations for them). In my understanding, all of these use-cases are already deployed and in use currently. They are just being implemented differently and the development of CATS solution is supposed to integrate in these use-cases and improve them. Please correct me if I am wrong. If I am correct, then it would be good to know these improvements or new capabilities and how they would integrate with CATS.

More importantly, the use cases come across as claims of how CATS architecture/framework would 'solve their problems and provide improvements' (my words) while the CATS systems is still under specification and not yet implemented (let alone integrated/deployed). Is it appropriate to publish this in an RFC at this juncture? My view is that we are not there yet and the use-cases are better published as RFC after integration/deployment with CATS to as practical and relevant blueprints.

Requirements - do we have the necessary and sufficient set?

I've found the requirements related to the routing aspects (e.g., metrics) to be sufficiently worked out - it is OK for them to be at a high-level at this stage.

However, I am missing the requirements for the glue/integration/adaptation with existing components in the application layer but also the routing system. Are we sure we have everything to publish? Or is it a work in progress?

Looking at ISAC in appendix A and the mailing list discussion on it, looks like it has not been covered and fully fleshed out. Likely more is needed to be done. But I don't see a conclusion of that discussion or the WG decision - (a) the WG is desirous of investigating this requirement and covering it, OR (b) the WG does not believe this to be a problem to solve. I get the impression that authors are saying (a) but they don't want to take it up as yet. This is perfect. But yet another reason to wait and not publish the requirements?

[Ballot comment]

Thanks to the authors and the WG for their work on this document.

Comments (non-blocking) follow:

Abstract :
I am curious about the more factors" mentioned in the introduction, could these be enumerated to set the focus of the document?

I see the following text: "However, it is undeniable that.." c- which seems a very strong assertion fro rthe iETF. IS it possible to rephrase this?

[Ballot discuss]
As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. I hope that this review helps to improve the document,

Thanks also to Zhed for his TSV-ART review.

# Introduction :
    - "The term end-side" needs some description. What is this?

# Section 3.1 :
It is not really clear if CATS changed the core goal of edge computing to "provide computing services closer to users through shorter network paths". Is that the idea? Maybe it is better to remove that statement and focus on the last paragraph to make the problem statement clear.

# flows
The TSV-ART review noted the use of  "per-flow states" and the need to define what a "flow" means in
this context. is this particular 5 tuple or something else. What is intended?

[Ballot discuss]
Thanks also to Zhed for his TSV-ART review.

# Introduction :
    - "The term end-side" needs some description. What is this?

# Section 3.1 :
It is not really clear if CATS changed the core goal of edge computing to "provide computing services closer to users through shorter network paths". Is that the idea? Maybe it is better to remove that statement and focus on the last paragraph to make the problem statement clear.

# flows
The TSV-ART review noted the use of  "per-flow states" and the need to define what a "flow" means in
this context. is this particular 5 tuple or something else. What is intended?

[Ballot comment]

Thanks to the authors and the WG for their work on this document.

Comments (non-blocking) follow:

# Abstract :
I am curious about the more factors" mentioned in the introduction, could these be enumerated to set the focus of the document?

[Ballot comment]
Thank you to Daniel Migault for their secdir reviews.

Please spell out acronyms (that are not listed w/ a * in https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list).  This includes SD-WAN, VR, AR, etc.

Section 6:  While R19 remains a broad requirement, R20, R21, R22 immediately jump to encryption, even though there appear to be requirements for authentication, integrity, and confidentiality.

Section 6, R20:  The requirement for authentication does not normally lead directly to encryption. In fact, some forms of 'encryption' do not provide authentication, i.e. the data can still be modified.  Perhaps there is a requirement for proof of authentication over the data?  Digital signatures are often a suggested mechanism to meet a requirement like this.

Section 6, R21:  The requirement for 'encryption' is not sufficient.  The requirement for integrity can be done in conjunction with R20 to protect the data.  It can also be met by using an encryption algorithm with an Authenticated Encryption with Associated Data (AEAD) mode.

Section 6, R22: End-to-end encryption does not always prevent the modification of the underlying data (for example, homomorphic encryption).  Using an AEAD mode with your favorite encryption algorithm will protect the data from modification as well as disclosure.  ICC codes are also a way to protect the integrity, although there are issues (which is why they have fallen out of favor).

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I have some points that I would like to discuss.

Should the problem statement not include gap analysis?

The objective of the CATS solution/framework is clear in the charter itself. I believe one of the goals of the Problem Statement analysis is to identify gaps in "how things are done today" (as in the functional blocks that exist and are in use today), what are the gaps that need to filed (new capabilities introduced by CATS - this is covered), and the external interfaces/interactions between the new and old to be developed. I find the Problem Statement portion lacking these details. There are no citations for the "current state of art" except for ALTO (not sure of its real world use) and the use of anycast. Mainly I was looking for the clients application interaction with the CATS solution.

Section 3.2 says:
"When a client issues a service request for a required service, the request is steered to one of the available service instances."

The details of what the envisioned/supported ways of making such a service request and what are gaps to "steer" it to available service instances are missing. Is this a DNS query? Are DNS servers meant to interact with CATS. Being a routing person, this is not my area of expertise and I was looking for some analysis from a routing area WG (with help of inputs from INT/ART/WIT) to cover these aspects (with appropriate citations).

Is there necessary clarity to publish these use-cases at this juncture of the development of the CATS framework/architecture?

The use-cases do not describe the current state of art (neither do I see adequate citations for them). In my understanding, all of these use-cases are already deployed and in use currently. They are just being implemented differently and the development of CATS solution is supposed to integrate in these use-cases and improve them. Please correct me if I am wrong. If I am correct, then it would be good to know these improvements or new capabilities and how they would integrate with CATS.

More importantly, the use cases come across as claims of how CATS architecture/framework would 'solve their problems and provide improvements' (my words) while the CATS systems is still under specification and not yet implemented (let alone integrated/deployed). Is it appropriate to publish this in an RFC at this juncture? My view is that we are not there yet and the use-cases are better published as RFC after integration/deployment with CATS to as practical and relevant blueprints.

Requirements - do we have the necessary and sufficient set?

I've found the requirements related to the routing aspects (e.g., metrics) to be sufficiently worked out - it is OK for them to be at a high-level at this stage.

However, I am missing the requirements for the glue/integration/adaptation with existing components in the application layer but also the routing system. Are we sure we have everything to publish? Or is it a work in progress?

Looking at ISAC in appendix A and the mailing list discussion on it, looks like it has not been covered and fully fleshed out. Likely more is needed to be done. But I don't see a conclusion of that discussion or the WG decision - (a) the WG is desirous of investigating this requirement and covering it, OR (b) the WG does not believe this to be a problem to solve. I get the impression that authors are saying (a) but they don't want to take it up as yet. This is perfect. But yet another reason to wait and not publish the requirements?

[Ballot comment]
Thank you to Roni Evan for the GENART review.

I am choosing to ABSTAIN on this document.  I was challenged in evaluating this document given the level of detail it provided and the precision by which the notional architecture, use cases, and requirements were explained.

My specific feedback is as follows:

** Section 1.
  Network operators are increasingly deploying computing resources,
  with a focus on enhancing edge capabilities to support services
  requiring low latency, high reliability, and dynamic resource
  scaling.

Is it just “network operators”?  Is “network operators” the right term?  I was under the impression that the “entire cloud industry” and “content delivery industry” (which also provides compute for application) builds out infrastructure geographically proximate to their customers.

** Section 4.1.  What is the difference between a normal cloud (e.g., https://aws.amazon.com/, https://www.tencentcloud.com/) and an “edge cloud” described here?

** Section 4.2
  Urban intelligent transportation relies on a large number of high-
  quality video capture devices, whose data needs to be processed at
  edge service sites (e.g., pedestrian flow statistics, vehicle
  tracking).  This imposes stringent requirements on the computing
  capabilities of edge service sites (for video processing) and network
  performance (bandwidth, latency).  CATS can address the issue by
  coordinating network and computing resources.

Given how specific the previously example in Section 4.1, could these “stringent requirements” be defined more precisely?

** Section 4.2
  In auxiliary driving scenarios (for example, "Extended Electronic
  Horizon" [HORITA]), edge service sites collect road and traffic data
  via V2X to address blind-spot and collision risks, and provide real-
  time warnings and maneuver guidance.  Requests are typically sent
  preferentially to the closest edge node.

As above.  Is this technology widely deployed enough to provide the field experience to frame the existing gaps for CATS to solve?

** Section 4.3.  I am having trouble understanding the link between digital twin models which can be run on a number of platforms and this CATS work.  It isn’t clear to me how the industrial control application is a novel use case demonstrating CATS.

** Section 4.5.1  As described here, it is unclear what about this use case is related to edge services, rather than just “traditional data centers”.

** Section 4.5.2
  Although large language models are nowadays confined to be trained
  with very large centers with computational, often GPU-based,
  resources, platforms for federated or distributed training are being
  positioned, specifically when employing edge computing resources.

I don’t understand the use case.  Can more be said about the circumstances where the significant computing resources required to train models are being distributed across _edge_ resources?  This seems the opposite of the trends to grow larger, and larger data centers.  Could this edge resource be better explained? What class of users is seeking this type of solution.

** Section 5.
  In the following, we outline the requirements for the CATS system to
  overcome the observed problems in the realization of the use cases
  above.

It isn’t clear with some of these requirements what novel requirements are being defined for CATS.  Some of these seem akin to design requirements of building any IT system.  A non-comprehensive annotation of the requirements is as follows:

-- Section 5.2
  R3: The implementations MUST agree on using metrics that are oriented
  towards compute capabilities and resources and their representation
  among service instances in the participating edges, at both design
  time and runtime.

Does this amount to saying any system (CATS or otherwise) needs to agree on the data format that it exchanges (in the case of CATS, metrics)?

-- Section 5.2
  R6: The Resource Model MUST be executable in a scalable manner.  That
  is, the Resource Model MUST be capable of being executed at the
  required time scale and at an affordable cost (e.g., memory
  footprint, energy, etc.).

Does this amount to saying any system (CATS or otherwise) needs to scale to the size of the use case?

-- Section 5.2
  R8: All metric information used in CATS MUST be produced and encoded
  in a format that is understood by participating CATS components. 

What is the alternative to this design for any system?  Doesn’t any system component (CATS or otherwise) need to understand the data it exchanges (CATS metrics or otherwise)?

-- Section 5.2
  R9: CATS MAY be applied in non-CATS network environments when needed,
  considering that CATS is designed with extensibility and could work
  compatibly with existing non-CATS network environments when the
  network components in these environments could be upgraded to know
  the meaning of CATS metrics.

Does this amount to saying that any new network technology (CATS or otherwise) could be brought to a network that that doesn’t use it if this network is updated to use the newer networking technology?

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-cats-usecases-requirements-12
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cats-usecases-requirements-12.txt&submitcheck=True

* 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/

## Thanks to the Reviewers

Thanks to Tim Bray for the ARTART review.

## Comments

Thanks for this document and the work that went into it.

### Applicability to all networks

907        R9: CATS MAY be applied in non-CATS network environments when needed,
908        considering that CATS is designed with extensibility and could work
909        compatibly with existing non-CATS network environments when the
910        network components in these environments could be upgraded to know
911        the meaning of CATS metrics.

Is the intent of this requirement to allow a CATS solution to be applicable
outside of CATS environments? In other words, a solution can be considered a
CATS solution even if it useful in non-CATS environments? Or is it only a
CATS solution if it is applicable to a non-CATS environment that will be
upgraded to a CATS environment? If it is the former, do you think a clarification
is necessary?

Thanks.

[Ballot comment]
# Internet AD comments for draft-ietf-cats-usecases-requirements-12
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

### S5.1

* "mapping CS-ID to one or more current service instance addresses"

  Surely there are circumstances where a CS-ID might have *zero* instances?
  (e.g. failure scenarios)

  What are the requirements around any of these special cases?

### S5.3

* How can R14 be met?  It seems like every possible solution would be
  "dependent on or vulnerable to" the mechanisms that gather and distribute
  the data used by the solution, no?

## Nits

### S3.2

* "routering systems" -> "routing systems"?

* "get a poor latency sometime" -> "experiences poor latency", perhaps

Request for IETF Last Call review by RTGDIR Completed: Not Ready. Reviewer: Linda Dunbar. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2025-12-17):

From: The IESG
To: IETF-Announce
CC: cats-chairs@ietf.org, cats@ietf.org, draft-ietf-cats-usecases-requirements@ietf.org, huang.guangping@zte.com.cn, james.n.guichard@futurewei.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements) to Informational RFC


The IESG has received a request from the Computing-Aware Traffic Steering WG
(cats) to consider the following document: - 'Computing-Aware Traffic
Steering (CATS) Problem Statement, Use Cases,
  and Requirements'
  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-12-17. 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


  Distributed computing is a computing pattern that service providers
  can follow and use to achieve better service response time and
  optimized energy consumption.  In such a distributed computing
  environment, compute intensive and delay sensitive services can be
  improved by utilizing computing resources hosted in various computing
  facilities.  Ideally, compute services are balanced across servers
  and network resources to enable higher throughput and lower response
  time.  To achieve this, the choice of server and network resources
  should consider metrics that are oriented towards compute
  capabilities and resources instead of simply dispatching the service
  requests in a static way or optimizing solely on connectivity
  metrics.  The process of selecting servers or service instance
  locations, and of directing traffic to them on chosen network
  resources is called "Computing-Aware Traffic Steering" (CATS).

  This document provides the problem statement and the typical
  scenarios for CATS, which shows the necessity of considering more
  factors when steering traffic to the appropriate computing resource
  to better meet the customer's expectations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cats-usecases-requirements/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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

There is good consensus behind this document, specifically those actively participating in the CATS WG. The document has been adopted as a WG item and has progressed through several iterations based on WG list and meeting feedback. Working Group Last Call ended on November 18, 2025.

The WG milestones only explicitly say to adopt this document (not to publish as an RFC). However, the charter does not preclude this. The working group discussed this point and had strong consensus that publication as an Informational RFC would be helpful for future protocol work.

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

There has been technical discussions, especially around alignment of terminology with the CATS framework (definitions, roles, metrics). These issues were resolved by updating the text. From the list no issues or controversies remain. There were no areas where consensus was not clear at the time this write-up was prepared but additional comments may be identified during Working Group Last Call.

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)?

No, none that have been shared with the working group.
This is an Informational document and, as it describes use cases and requirements ahead of any solutions work, it would not qualify for implementation.

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

Not specifically, the use cases relate to the main CATS framework and metrics documents and has been used as an input to them.

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.

Not applicable. The document defines no MIB modules, YANG modules, media types, URIs, or similar constructs

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]?

Not applicable. The document does not contain a 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.

Not applicable. The document does not define any formal language artefacts.

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

In the shepherd’s opinion, this document is needed, clearly written, and complete for its intended purpose. The -09 revision incorporates WG feedback and addresses comments from the RTGDIR early review and is ready to be handed to the responsible Area Director.

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?

The shepherd has considered the routing-area and general IESG review checklists. No area-specific issues have been identified beyond those already covered by WG discussions and the RTGDIR early review. Any additional comments from other areas (such as security and operations) can be performed by the IESG members.

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 publication status is Informational. This is appropriate, as the document provides the CATS problem statement, use cases, and requirements; it does not define a protocol or mechanism. The Datatracker correctly records the intended status as Informational.

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.

The shepherd (and WG chairs) have reminded all authors and key contributors of their obligations under BCP 79 and polled them via the CATS mailing list. All authors and contributors have responded (https://mailarchive.ietf.org/arch/msg/cats/oiyL5Kb0tvp6XDcB1uS-lnO4mhs/). To the shepherd’s knowledge, there are no undisclosed IPR claims relating specifically to this document; any filed disclosures, if present, are recorded on the Datatracker IPR page for the draft.

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.

All listed authors and contributors have not publicly disclosed any unwillingness to be named as such, and by responding to the IPR poll (above) have indicated that they are aware of their roles. There are five authors, which is within the usual guideline. Additional contributors are acknowledged in the “Contributors” section of the document.

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

The document passes the IETF Submission check with zero Errors. However there is one warning:
"There is 1 instance of lines with non-ascii characters in the document."
This occurs in someone's name.

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

The split between normative and informative references appears appropriate.

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 normative references are IETF RFCs and freely available. There are no paywalled or otherwise unavailable normative references

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]).

No new IANA registries are defined.

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 IANA action is required. No Designated Expert is needed.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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

There is good consensus behind this document, specifically those actively participating in the CATS WG. The document has been adopted as a WG item and has progressed through several iterations based on WG list and meeting feedback. Working Group Last Call ended on November 18, 2025.

The WG milestones only explicitly say to adopt this document (not to publish as an RFC). However, the charter does not preclude this. The working group discussed this point and had strong consensus that publication as an Informational RFC would be helpful for future protocol work.

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

There has been technical discussions, especially around alignment of terminology with the CATS framework (definitions, roles, metrics). These issues were resolved by updating the text. From the list no issues or controversies remain. There were no areas where consensus was not clear at the time this write-up was prepared but additional comments may be identified during Working Group Last Call.

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)?

No, none that have been shared with the working group.
This is an Informational document and, as it describes use cases and requirements ahead of any solutions work, it would not qualify for implementation.

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

Not specifically, the use cases relate to the main CATS framework and metrics documents and has been used as an input to them.

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.

Not applicable. The document defines no MIB modules, YANG modules, media types, URIs, or similar constructs

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]?

Not applicable. The document does not contain a 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.

Not applicable. The document does not define any formal language artefacts.

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

In the shepherd’s opinion, this document is needed, clearly written, and complete for its intended purpose. The -09 revision incorporates WG feedback and addresses comments from the RTGDIR early review and is ready to be handed to the responsible Area Director.

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?

The shepherd has considered the routing-area and general IESG review checklists. No area-specific issues have been identified beyond those already covered by WG discussions and the RTGDIR early review. Any additional comments from other areas (such as security and operations) can be performed by the IESG members.

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 publication status is Informational. This is appropriate, as the document provides the CATS problem statement, use cases, and requirements; it does not define a protocol or mechanism. The Datatracker correctly records the intended status as Informational.

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.

The shepherd (and WG chairs) have reminded all authors and key contributors of their obligations under BCP 79 and polled them via the CATS mailing list. All authors and contributors have responded (https://mailarchive.ietf.org/arch/msg/cats/oiyL5Kb0tvp6XDcB1uS-lnO4mhs/). To the shepherd’s knowledge, there are no undisclosed IPR claims relating specifically to this document; any filed disclosures, if present, are recorded on the Datatracker IPR page for the draft.

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.

All listed authors and contributors have not publicly disclosed any unwillingness to be named as such, and by responding to the IPR poll (above) have indicated that they are aware of their roles. There are five authors, which is within the usual guideline. Additional contributors are acknowledged in the “Contributors” section of the document.

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

The document passes the IETF Submission check with zero Errors. However there is one warning:
"There is 1 instance of lines with non-ascii characters in the document."
This occurs in someone's name.

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

The split between normative and informative references appears appropriate.

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 normative references are IETF RFCs and freely available. There are no paywalled or otherwise unavailable normative references

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]).

No new IANA registries are defined.

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 IANA action is required. No Designated Expert is needed.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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

There is good consensus behind this document, specifically those actively participating in the CATS WG. The document has been adopted as a WG item and has progressed through several iterations based on WG list and meeting feedback. Working Group Last Call ended on November 18, 2025.

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

There has been technical discussions, especially around alignment of terminology with the CATS framework (definitions, roles, metrics). These issues were resolved by updating the text. From the list no issues or controversies remain. There were no areas where consensus was not clear at the time this write-up was prepared but additional comments may be identified during Working Group Last Call.

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)?

No, none that have been shared with the working group.
This is an Informational document and, as it describes use cases and requirements ahead of any solutions work, it would not qualify for implementation.

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

Not specifically, the use cases relate to the main CATS framework and metrics documents and has been used as an input to them.

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.

Not applicable. The document defines no MIB modules, YANG modules, media types, URIs, or similar constructs

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]?

Not applicable. The document does not contain a 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.

Not applicable. The document does not define any formal language artefacts.

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

In the shepherd’s opinion, this document is needed, clearly written, and complete for its intended purpose. The -09 revision incorporates WG feedback and addresses comments from the RTGDIR early review and is ready to be handed to the responsible Area Director.

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?

The shepherd has considered the routing-area and general IESG review checklists. No area-specific issues have been identified beyond those already covered by WG discussions and the RTGDIR early review. Any additional comments from other areas (such as security and operations) can be performed by the IESG members.

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 publication status is Informational. This is appropriate, as the document provides the CATS problem statement, use cases, and requirements; it does not define a protocol or mechanism. The Datatracker correctly records the intended status as Informational.

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.

The shepherd (and WG chairs) have reminded all authors and key contributors of their obligations under BCP 79 and polled them via the CATS mailing list. All authors and contributors have responded (https://mailarchive.ietf.org/arch/msg/cats/oiyL5Kb0tvp6XDcB1uS-lnO4mhs/). To the shepherd’s knowledge, there are no undisclosed IPR claims relating specifically to this document; any filed disclosures, if present, are recorded on the Datatracker IPR page for the draft.

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.

All listed authors and contributors have not publicly disclosed any unwillingness to be named as such, and by responding to the IPR poll (above) have indicated that they are aware of their roles. There are five authors, which is within the usual guideline. Additional contributors are acknowledged in the “Contributors” section of the document.

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

The document passes the IETF Submission check with zero Errors. However there is one warning:
"There is 1 instance of lines with non-ascii characters in the document."
This occurs in someone's name.

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

The split between normative and informative references appears appropriate.

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 normative references are IETF RFCs and freely available. There are no paywalled or otherwise unavailable normative references

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]).

No new IANA registries are defined.

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 IANA action is required. No Designated Expert is needed.

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

  There is good consensus behind this document, specifically those actively participating in the CATS WG. The document has been adopted as a WG item and has progressed through several iterations based on WG list and meeting feedback. Working Group Last Call ended on November 18, 2025.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
  There has been technical discussions, especially around alignment of terminology with the CATS framework (definitions, roles, metrics). These issues were resolved by updating the text. From the list no issues or controversies remain. There were no areas where consensus was not clear at the time this write-up was prepared but additional comments may be identified during Working Group Last Call.

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)?
No, none that have been shared with the working group.
## 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.
Not specifically, the use cases relate to the main CATS framework and metrics documents and has been used as an input to them. However, there is one normative reference to an individual document in the TLS working group, and one informative BM working group documents, it is unlikely this document would need to be reviewed by either TLS or BM working groups.

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.
Not applicable. The document defines no MIB modules, YANG modules, media types, URIs, or similar constructs

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]?
Not applicable. The document does not contain a 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.
Not applicable. The document does not define any formal language artefacts.
## 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?

  In the shepherd’s opinion, this document is needed, clearly written, and complete for its intended purpose. The -09 revision incorporates WG feedback and addresses comments from the RTGDIR early review and is ready to be handed to the responsible Area Director.

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?
  The shepherd has considered the routing-area and general IESG review checklists. No area-specific issues have been identified beyond those already covered by WG discussions and the RTGDIR early review. Any additional comments from other areas (such as security and operations) can be performed by the IESG members.
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 publication status is Informational. This is appropriate, as the document provides the CATS problem statement, use cases, and requirements; it does not define a protocol or mechanism. The Datatracker correctly records the intended status as Informational.
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.
  The shepherd (and WG chairs) have reminded all authors and key contributors of their obligations under BCP 79 and polled them via the CATS mailing list. Authors and contributors have responded except for Markus Amend. To the shepherd’s knowledge, there are no undisclosed IPR claims relating specifically to this document; any filed disclosures, if present, are recorded on the Datatracker IPR page for the draft.
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.
  All listed authors have not publicly disclosed any unwillingness to be named on the front page. There are five authors, which is within the usual guideline. Additional contributors are acknowledged in the “Contributors” section of the document.
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.)
  The document passes the IETF Submission check with zero Errors. However there is one warning:
"There are 8 instances of lines with non-ascii characters in the document."
15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
  The split between normative and informative references appears appropriate.
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 normative references are IETF RFCs and freely available. There are no paywalled or otherwise unavailable normative references
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]).
  No new IANA registries are defined.
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 IANA action is required. No Designated Expert is 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/

Request for posting confirmation emailed to previous authors: Dirk Trossen , Hang Shi , Kehan Yao , Luis Contreras , Qing An , Shuai Zhang , Yizhou Li , cats-chairs@ietf.org