IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
RFC 7717

Note: This ballot was opened for revision 09 and is now closed.

(Spencer Dawkins) (was Discuss, Yes) Yes

Comment (2015-10-05)
No email
send info
I'm clearing my Discuss-for-IANA, now that draft-ietf-ippm-owamp-registry is on the next telechat agenda.

(Brian Haberman) (was Discuss) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2015-06-05 for -10)
No email
send info
Thanks for addressing my DISCUSS and comments!

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-04-08 for -10)
No email
send info
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.)

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-04-07 for -09)
No email
send info
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

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-04-05 for -09)
No email
send info
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

Alvaro Retana No Objection

(Martin Stiemerling) No Objection