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

From: Kostas Pentikousis <[email-masked]>
Date: Fri, 29 May 2015 15:14:59 +0200

Dear Barry, all,

We have updated draft-ietf-ippm-ipsec to address all comments received in the last round of review (see the diff at https://www.ietf.org/rfcdiff?url1=draft-ietf-ippm-ipsec-09&url2=draft-ietf-ippm-ipsec-10). 

<snip>

| 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.

Done.

| -- Section 3 --

<snip>

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

Done.

| 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.

Done, with the help of the WG chairs (many thanks!): https://tools.ietf.org/html/draft-ietf-ippm-ipsec-10#section-7

| -- Section 5.2 --

<snip>

| 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

Done, with the exception of the last sentence, which was removed to address Ben Campbell's comment ("Why does the use of IKEv2 create a stronger requirement to support all 3 protection modes?")

Best regards,

Kostas