Hi, This document has been reviewed as part of the security 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. I do not have specific security concerns regarding the document; however, the relationship between metrics and routing is not yet clear to me. I acknowledge that I have not reviewed the other CATS-related documents, which may explain my limited understanding of the broader context. Nevertheless, I would appreciate clarification for my own understanding, leaving it to the authors to decide whether additional explanation is warranted in the document. My current understanding is that the considered metrics include both system-level parameters (e.g., available CPU resources) and network-related metrics such as latency. These metrics would inform decisions on service instantiation and traffic assignment. For service dimensioning, relying on monitoring data from edge data centers appears reasonable, as such information can be considered relatively trustworthy. However, when traffic from different user equipments (e.g., UE1 and UEa) is steered toward different service instances, it is unclear to me how this differentiation is achieved in practice and what role routing plays in this process. While DNS-based mechanisms and anycast can influence instance selection, their achievable granularity and level of control remain unclear in this context. Given that this work falls within the routing area, I am therefore wondering whether CATS considers routing-based traffic steering (e.g., à la anycast) or whether service instances are expected to be distinct and explicitly addressable. In the former case, if routing decisions rely on information originating from end users, this would significantly increase the attack surface. At present, it is unclear whether such scenarios are in scope of the described use cases. Similarly, if traffic steering depends on resource availability at edge sites, this could leak information about site load conditions. Such information could potentially be exploited by an attacker, for example to optimize the cost of a denial-of-service attack. While I understand that service instances may share a common identifier, there may still be indirect means to infer the physical location or load of individual sites. Other comments: 3.2. Traffic Steering among Edges Sites and Service Instances Figure 1 shows a common way to deploy edge sites in the metro. Edge sites are connected with Provider Edges(PEs). There is an edge data center for metro area which has high computing resource and provides the service to more User Equipments(UEs) at the working time. Because more office buildings are in the metro area. mglt: I think the two sentences should be a single sentence. And there are also some remote edge sites which have limited computing resource and provide the service to the UEs close to them. mglt: Based on my understanding of the scenarios, all UEs are situated within the same region. UE[1-n] are linked to the nearest data center, which can intuitively be regarded as the optimal selection. However, as resources become limited, UE[a-b] connect to their most suitable server instance located at a more remote site. Consequently, the figure illustrates that the best option is the nearest, with Edge Site 1 and Edge Site 2 being the closest locations to UE[a-b]. I believe the message would be more comprehensible if UE[a-b] appeared to be co-located with the other UEs [1-n], while maintaining a more distant connection to the Edge Sites. Applications to meet service demands could be deployed in both the edge data center in metro area and the remote edge sites. In this case, the service request and the resource are matched well. Some potential traffic steering may be needed just for special service request or some small scheduling demand. [...] +----------------+ +---+ +------------+ +----------------+ |- - |UE1| +------------+ | | +-----------+ | | +---+ +--| Edge | | | |Edge server| | | +---+ +- - -|PE| | | | +-----------+ | |- - |UE2| | +--| Site 1 |-+ | +-----------+ | | +---+ +------------+ | |Edge server| | | ... | | | +-----------+ | +--+ Potential +---+ +---+ | +-----------+ | |PE|- - - - - - -+ |UEa| |UEb| | |Edge server| | +--+ Steering +---+ +---+ | +-----------+ | | +---+ | | | +-----------+ | |- - |UE3| +------------+ | | ... ... | | | +---+ | +------------+ | | +-----------+ | | ... +--| Edge | | | | | +---+ +- - -|PE| | | |Edge data center|-+- - |UEn| +--| Site 2 |-+ +----------------+ +---+ +------------+ High computing resource Limited computing resource and more UE at metro area and less UE at remote area Figure 1: Common Deployment of Edge Sites +----------------+ +------------+ +----------------+ | +------------+ | | +-----------+ | | Steering traffic +--| Edge | | | |Edge server| | | +-----------|PE| | | | +-----------+ | | +---+ | +--| Site 1 |-+ | +-----------+ | |- - |UEa| | +----+----+-+----------+ | |Edge server| | | +---+ | | | | | +-----------+ | +--+ | +---+ +---+ +---+ +---+ +---+ | +-----------+ | |PE|-------+ |UE1| |UE2| |UE3| |...| |UEn| | |Edge server| | +--+ | +---+ +---+ +---+ +---+ +---+ | +-----------+ | | +---+ | | | | +-----------+ | |- - |UEb| | +-----+-----+------+ | | ... ... | | | +---+ | +------------+ | | +-----------+ | | | +--| Edge | | | | | +-----------|PE| | | |Edge data center|-+ Steering traffic +--| Site 2 |-+ +----------------+ +------------+ High computing resource Limited computing resource and less UE at metro area and more UE at remote area Figure 2: Steering Traffic among Edge Sites There will also be the common variable of network and computing resources, for someone who is not moving but get a poor latency sometime. Because of other UEs moving, a large number of request for temporary events such as vocal concert, shopping festival and so on, and there will also be the normal change of the network and computing resource status. So for some fixed UEs, it is also expected to steer the traffic to appropriate sites dynamically. mglt: To my understanding, UE[1-n] are anticipated to be nearer to Edge Sites 1 and 2 during the night, similar to UE[a-b]. If this is accurate, I would suggest consolidating all UEs at a single location in the illustration. The existing Fig2 appears to indicate that UE[1-n] have transitioned from downtown to the suburbs, whereas UE[a-b] have shifted from the suburbs to downtown. 4.2. Example 2: Computing-aware Intelligent Transportation For the convenience and safety of transportation, more video capture devices need to be deployed as urban infrastructure, and the better video quality is also required to facilitate the content analysis. Therefore, the transmission capacity of the network will need to be further increased, and the collected video data need to be further processed by edge nodes for edge computing, such as for pedestrian face recognition, vehicle tracking, and road accident prediction. mglt: Facial recognition presents considerable ethical concerns and ought to be regarded more as a counter-argument for exploring new technology. It also indirectly contradicts R24, as I comprehend it. At the very least, it should be eliminated.