I am an assigned INT directorate reviewer for . These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . 1. Introduction IOAM [RFC9197] is used for monitoring traffic in the network by incorporating IOAM data fields into in-flight data packets. Should we read that the data is manipulated in-flight? Then it's not just incorporated... If an encapsulating node receives a looped back packet that was not originated from the current encapsulating node, the packet is dropped. Should we read "originated from self"? or sets the loopack typo The copy is also truncated, i.e., any payload that resides after the IOAM option(s) is removed before transmitting the looped back packet back towards the encapsulating node. IUs there enough info to correlate with the copied packet in case the encapsulator keeps stats, e.g. packet size? Could the loopbakc copy carry packets stats (again like size or time) The looped back data rate SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM node's interfaces. Using N>100 is RECOMMENDED. Depending on the IOAM node's architecture This is not really the same N as before. Why is it the same value? I see that it makes sense to throttle at the encapsulation, but here this should not be done beyond a self protection maesure wihc should not be triggering in normal conditions. Because loosing loop back copies may cause the encapsulator to think there is a problem when there is none. It is not intended as a replacement for existing active OAM protocols, which may run in higher layers and make use of the Active flag. Sorry could you reformulate? Higher levels could not use that flag, that would be a layer violation.