This is the second ARTART review and has no special standing. 

This review concerns draft-ietf-cats-usecases-requirements-12. This draft is substantially improved since the last draft reviewed, but still has a few issues.

General:

There is no mention of CDNs? Are they not an important piece of the puzzle? Many of the CDN providers advertise the availability of edge compute in various flavors.

It says in 4.2 that it's a requirement that CATS is entirely application-transparent. Shouldn't that show up as one of the numbered requirements?

There is very little discussion of databases, which I think is a gap.  In many real-world scenarios (a majority?) the performance of distributed systems is dominated by a shared database which maintains system state.  I think the discussion of metrics and bottlenecks would benefit from a mention of this.  This pops up at several points in the detail points that follow.

Abstract

"follow and use" - why not just "use"?

The phrase "the typical scenarios" suggests that those offered are *the* most common.  Maybe just "and typical scenarios"

1.

"Regular capacity expansion of a single site is neither practical nor economical."  Lots of people do this, could possibly acknowledge this reality by saying "is often neither…"

"However, existing routing schemes and traffic engineering methods fall short" This is often not true. Need to acknowledge with a "sometimes" or "often".

3.2 ALTO and Anycast are mentioned. How about good old ICMP?

4.1

This section is now quantitative and now much better. One problem: In my experience with AR/VR, the server side provides a scene graph and images from a database, while the GPU work is done on the client, in something like the Vision Pro. There's typically not enough network bandwidth to send the GPU *output*, just its input.  So I think the paragraph beginning "The conclusion is…" needs some work to revise the GPU-specific language. It takes plenty of CPU to build a scene graph, so the analysis is still broadly correct.

4.2 "high-quality video and LIDAR data" would be more accurate

4.5.2 "platforms for federated or distributed training are being positioned, specifically when employing edge computing resources." Really?  Would love to see a citation here.  I am not convinced that this is really a thing.

5. Requirements. Maybe I'm being pedantic, but all this 2119 language in an informational RFC bothers me.  Whenever in RFC says something MUST be some way, shouldn't there be a crystal-clear way to ascertain whether it is nor not?

5.1 

The first sentence here is very good, and I would try to include it in the Abstract or Introduction.

What does a CS-ID identify? An instance of a particular user of a particular application?  It seems like an important concept. If there's a nice crisp reference and I missed it, oops.

5.2

Note that in a high proportion of cases, the limiting factor in a distributed application is a shared database rather than CPU or networking.  The metric that gets interesting in that case is the throughput in transactions per second, which might be low even when the CPU load is not high.

In the real world, it is very common to see metrics associated with percentiles, for example "P99 latency".  To the extent that when someone says to me "I need 150ms latency" I suspect they're don't know what they're talking about if they don't say P50 or P95 or some such.  It feels weird that this isn't even mentioned as an issue.

R6. For this requirement to be enforced, there must be supporting metrics (not sure what they would be) describing the performance of the Resource Model.

5.3 What’s a "CATS Domain"?

R14: The beginning of the sentence is missing? I don't understand what it's trying to say and to the extent I do, it seems unrealistic? Of course the performance of the CATS facility is going to be sensitive to the metrics update frequency.  How could it not be?

5.4. 

The discussion of stateless services and the value of HTTP-style requests is good, but also implies, as mentioned above, that there's a database somewhere that maintains the service state.  Which is to say, once again, that its performance is apt to be critical in the CATS context. 

The paragraph beginning "However, a client, e.g., a mobile UE, may…" is troublesome. If I have multiple client apps on a field device, typically they connect to service endpoints through DNS names, and the DNS names are service-specific. In fact, load balancing is commonly accomplished by fiddling DNS tables. It would be perfectly reasonable for different apps to have zero, some, or lots of instance affinity requirements. 

R15. What does "per-flow" mean?

5.5

R18 is huge and complex and intersects the legal/regulatory environment, which should be stated. This probably requires some metrics and quite a lot more discussion. (There is some in the Security Considerations section, which should probably be stated.)

6. 

"Description: Attackers may spoof legitimate service instance identities" - really? In the case where the traffic is HTTPS, it becomes difficult to spoof service instance identities.

"Description: Attackers may tamper with core scheduling metrics or submit false data" - once again, one would hope that CATS traffic offers at least TLS levels of security and exclude plaintext.  This document should be clear on this. Seriously, anything that wants to have a chance of getting through the IETF process in 2026 needs to be rigorous on this point.