I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document concerns embedding In-situ Operations, Administration, and Maintenance (IOAM) data in IPv6 extension headers. IOAM data is telemetry data added by routers to packets as they transit a network, and sometimes removed by routers if the packets leave an "IOAM domain". IOAM extensions can be either Hop-by-Hop options or Destination options. The IOAM data itself is defined in another document (RFC9197). This document has a lot of jargon that makes it difficult to parse for the uninitiated (and I count myself among them). My one concern with respect to security comes from the statement in section 5.1: "OAM data leaks can affect the forwarding behavior and state of network elements outside an IOAM domain. IOAM domains SHOULD provide a mechanism to prevent data leaks or be able to ensure that if a leak occurs, network elements outside the domain are not affected (i.e., they continue to process other valid packets)." The concern is that IOAM domains should be clearly delimited and IOAM extensions should be stripped before a packet leaves the domain and/or as it enters a domain. My concern is that this could be difficult to enforce when IPv6 packets are encapsulated - in particular by IPsec. AH needs to understand which extensions are mutable and which are immutable. I don't know whether the defaults cover these extensions adequately or whether additional specification in necessary. ESP needs to know whether the other end of the security association is in the same IOAM domain so that it knows whether to encapsulate IOAM extensions or drop them. All of this may require additional configuration and may not behave correctly with implementations that are not aware of IOAM data. There may also be a matter of merging IOAM data from an outer envelope with IOAM data from an inner envelope when doing decapsulation. I'm not an expert on either IOAM or IPsec's handling of IPv6 extensions, but someone who is should look at this specification and make sure it is not going to create problems. Radia