I am the DNS Directorate reviewer for this I-D.

Although the document is mostly well-written and clear overall, the
text about DNS at the end of A.1 is unsatisfactory. It needs further
work. More clarification is needed.

It is not clear which entity/entities are making CATS-related DNS
lookups or why they do this every 600 seconds. Why 600? Why not 60 or
60000 seconds? What data are being looked up? How are they provisioned
in the DNS and published? Who/What manages that? What sort of
RRType(s) are involved? Are the DNS lookups secured with DNSSEC and/or
encrypted DNS transport? If not, why not? Why/how was 15 seconds
chosen as the metric update and distribution frequency?

Nothing is said about the impact of DNS cacheing and TTL values. What
happens if the DNS lookups return data with a TTL that's greater than
600 or 15 seconds? What are the trade-offs here betweeen short- and
long-lived DNS data? These need to be explained.

IMO, A.2 is inappropriate for any sort of standards document. It seems
to be a vendor-specific marketing blurb. I do not understand why any
RFC needs to mention that some unidentified resource in Wuxi can
handle over 200,000 connections per second. Or how that matters.
Appendix A.2 does not explain how MIGU actually uses CATS, what the
compute metrics are or how the entities act on those metrics, what the
roles and responsibilities of these actors are, etc, etc. I think this
appendix should be removed. Fixing A.2 will be painful. It will take a lot
of work for something that at best is marginal to the I-D.

Further work is needed on Security Considerations too. It currently
says "Security issues need to be considered when designing CATS
system" and "the security status of computing resources SHOULD be
taken into consideration". Well, fancy that! I'd never have
known. There's almost no information on what security issues have to
be taken into account or an explanation of why these matter.

Simply saying security issues have to be considered is an empty platitude
that can't help those implementing or deploying CATS-based technology.
A document describing use cases really should explain what security
issues were taken into consideration (and why) and how they were addressed.


PS It would be nice to get rid of the horrible Americanism of
placename, bigger placename: for instance Henan, China. This trope is
annoying and unnecessary. Where else could Henan be if it wasn't in
China? RFCs are no place for geography lessons. For example, it doesn't
matter to the IETF (or anyone reading this I-D) that Zhengzhou is the
capital of Henan. That information has no relevance to Computing-Aware
Traffic Steering technology and its use cases.