In the whole draft there are several cases where IPsec is spelled incorrectly (IPSec). -- In section 5.3 there is text saying: The Security Parameter Index (SPI)(see [RFC4301] [RFC7296]) can uniquely identify the Security Association (SA). If the client supports the derivation of shared secret key from IKEv2 SA, it will choose the corresponding mode value and carry SPIi and SPIr in the Key ID field. SPIi and SPIr MUST be included in the Key ID field of Set-Up-Response Message to indicate the IKEv2 SA from which the O/ TWAMP shared secret key derived from. The length of SPI is 4 octets. ^ Therefore, the first 4 octets of Key ID field MUST carry SPIi and the ^ second 4 octets MUST carry SPIr. The remaining bits of the Key ID ^ field MUST set to zero. This is wrong. The SPIi and SPIr in the IKEv2 SA are 8 octets each. The ESP and AH SPI is 4 octets, for IKEv2 SA it is 8+8. Also in the next paragraph it should say "first 16 octets" not "first 8 octets". -- In section 5.4 you there is text: ... If the two endpoints are already connected through an IPSec tunnel it is RECOMMENDED that the O/TWAMP measurement packets are forwarded over the IPSec tunnel if the peers choose the unauthenticated mode in order to ensure authenticity and security. Part of the IPsec architecture model specifies policy rules which dictate which packets go to the tunnel and which do not. This text above seems to indicate that someone else than the policy rules could say that those O/TWAMP measurement packets might ignore those policy rules and go out bypassing those rules. I think it would be better to rewrite the text above to reflect that the IPsec policy model is followed with those packets just as for any other packets. I.e. the normal case would be that IPsec policy rules will specify whether the measurement packets go to the tunnel or not. If I understand correctly that this text tries to say that IPsec tunnel should be configured so that it SHOULD include O/TWAMP measurement packets, even when using unauthenticated mode, to ensure authenticity and security. -- kivinen@xxxxxx