This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thanks for sharing this document. Overall, it does a good job of describing various functions
in the architecture and defines its terminology in depth. Without expertise in the specific
area, I don't see problems in these details.

From a transport perspective, and also looking partly at the security and privacy
aspects, however, there are some issues that deserve clarification or rethinking.

- Classification of traffic
Section 3.4.5 describes the "Traffic Classifier". This is responsible for classifying
client traffic to aid in the routing. There is a reference to section 5.1 for more details,
but I don't actually see many details in 5.1 about how the classifier is provisioned or
what it is matching on. I'm assuming there are aspects of the 5-tuple being observed,
and the text explicitly mentions SNI inspection. Clarifying the nature of this classification
and how it interacts with transports would be good to add. TCP will behave differently from
QUIC; QUIC can migrate paths, and both TCP and QUIC have multipath variants that may
interact in unexpected ways with a naive classifier. Also, explicitly calling out SNI
tracking brings up questions of usage for TLS encrypted client hello (RFC 9849), which just
was standardized. It's worth thinking about if traffic classification here can be encouraged
to rely on more explicit signals, such as the approach in SCONE (https://datatracker.ietf.org/wg/scone/about/).

- Privacy
While the goals of the privacy sections are good ("must support preventing on-path nodes in the
underlay infrastructure to fingerprint and track clients"), I'm concerned about the overall privacy
approach. It seems to rely on policies of networks being benevolent, rather than technical properties
to reduce information disclosure. For example, "personal data must not be exposed to external parties"
is mainly a statement of policy, and should be framed as such.

The text specifically calls out that "the CATS solution may need to know about applications, clients,
and even user identity". Tracking applications and user identity is indeed very sensitive, and this raises
the question of how this information about applications being used by a client is shared with the network.
It seems insufficient to say that this information "should be encrypted"; encrypting the PII is good, but
it also needs to be clear which entities in the architecture get to see that information, and what
they are able to track or correlate to. It is possible to make policy decisions based on information without
having to correlate the data, but I'm concerned that this document sets the bar too low at just
recommending encryption as a solution. That is necessary, but not necessarily sufficient. The specific
solutions are not in scope for this document, but it would be good to explain what the architectural
privacy goals should be, such that specific protocols can be judged to conform to those or not.