Subject: [ippm] Barry Leiba's No Objection on draft-ietf-ippm-ipsec-09: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 07 Apr 2015 11:29:44 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-ippm-ipsec-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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