IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-ipsec-11

General: the "implementations compatible with this specification" stuff is really awkward and unnecessary.  It would be better if it were changed to "implementations of this method" (and similar phrasing, such as "clients implementing this method") throughout the document.  But this is non-blocking, and there's no reason to discuss it.  I urge you to consider the change, but please do with that urging as you think best.

-- Section 3 --

   This document reserves from the TWAMP-Modes registry the Mode value
   IKEv2Derived which is equal to 128 (i.e. bit set in position 7) and
   MUST be used by TWAMP implementations compatible with this
   specification.

Pete Resnick has left the IESG in body only, but not in spirit.
I think what you mean here is that you signal that you're using this method by setting IKEv2Derived.  Is that correct?  Assuming so, this would be more clearly and simply said in a way such as this (definitely without any 2119 words, which aren't appropriate for that):

NEW
   TWAMP implementations signal the use of this method by setting
   IKEv2Derived (see Section 7).
END

Please leave the details of the registry, and which bit was assigned, to the IANA Considerations section, where that stuff belongs.  The reference to Section 7 makes it easy to find.

-- Section 5.2 --
As in Section 3, it's better just to refer to IKEv2Derived, and not to talk about the registration details here.  So:

OLD
   The Modes field in Figure 2 will need to allow for support of key
   derivation as discussed in Section 5.1.  As such, the Modes value
   extension MUST be supported by implementations compatible with this
   document, indicating support for deriving the shared key from the
   IKEv2 SA.  The new Modes value indicating support for this
   specification is IKEv2Derived and is equal to 128 (i.e. bit set in
   position 7).  Clearly, an implementation compatible with this
   specification MUST support the authenticated, encrypted and mixed
   modes as per [RFC4656][RFC5357][RFC5618].
NEW
   The Modes field in Figure 2 will need to allow for support of key
   derivation as discussed in Section 5.1.  Therefore, when this
   method is used, the Modes value extension MUST be supported.
   Support for deriving the shared key from the IKEv2 SA is indicated
   by setting IKEv2Derived (see Section 7).  The authenticated,
   encrypted and mixed modes (see [RFC4656][RFC5357][RFC5618]) MUST
   also be supported.
END

Thanks for addressing my DISCUSS and comments!

Thanks for considering the SecDir review and providing edits in the current draft revision.
https://www.ietf.org/mail-archive/web/secdir/current/msg05444.html

Since you're touching on the key managment code, I'd have
loved to see you also update the O/TWAMP crypto itself to e.g.
use an AEAD cipher rather than AES-CBC. Did the WG consider
that? (I assume it's too late now, but I'm not clear from the
write-up if this is implemented or not, so I guess there's a
small chance that the WG may want to update more than just the
key mgmt.)