Internet Key Exchange Protocol Version 2 (IKEv2)
draft-kivinen-ipsecme-ikev2-rfc5996bis-04

[Ballot comment]
Shepherd writeup had me confused; this is going for Internet Standard. (And bad form to have one of the editors shepherd their own document.) But this seems perfectly ready for IS, so no objection from me.

[Ballot comment]
The Abstract is a bit confused and aspirational. It wouldn't fit on the document once published as an RFC. Possibly update the last sentence from...

  This document obsoletes RFC 5996, and includes all of the
  errata for it, and it is intended to update IKEv2 to be Internet
  Standard.

...to...

  This document obsoletes RFC 5996, and includes all of the
  errata for it. It advances IKEv2 to be an Internet Standard.

[Ballot comment]
I would like to see the comments Cao Zhen raised during the IntArea directorate review addressed, but I don't think they rise to the level of a DISCUSS.  I've included them below, can forward the whole message if desired.  This review was requested by Brian, so any credit for it happening goes to him--I'm just concurring with Zhen.

The major update of the this document to RFC5996 is the DEPRECATION of RAW RSA PUBLIC KEY entry. Thank the authors for this work, to catch this important issue in the smart and constrained communication world.

1. In Section 1.8
  " Deprecated Raw RSA Public keys.  There is new work ongoing to replace
  that with more generic format for generic raw public keys. "

Suggestion: to include some references to the "ongoing work". I believe they include draft-kivinen-ipsecme-oob-pubkey-07, draft-ietf-tls-oob-pubkey-01 and etc. But they are necessary for readers to track the on going work.

2. In Section 3.6, after the declaration that "Raw RSA Key " is deprecated, it is expected some explanation of background, and how could the implementation be forward/backward compatible. Say, if the Sender/Initiator is RFC5996 compatible, and includes a CERT with Raw RSA Key, but the Responder is updated with RFC5996-bis, what's the expected behaviors of both sides.  In section 3.7, for the CERT Request message handling, it is the same thing, what's the responder's behavior if the initiator asks for a CERT encode type of 'RAW RSA KEY' that has been deprecated, and similarly what will happen if the sender ask for the NEW ENCODE TYPE but the receiver does not support it. And so on and so forth.

If authors meant all the issues have been explained in the Section 3.2 of "Critical Bit", then the left question is how the initiator set the critical bit in these cases. But I do not think this is a self-explained issue. Some more text here will leave the implementers with less interop pain. 

3. Reference to IKEV2 IANA
  [IKEV2IANA]
            "Internet Key Exchange Version 2 (IKEv2) Parameters",
            .

  Suggest changing the URL to :
  http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml

[Ballot comment]


My review was based on the diff vs. 5996. [1] All the changes look
ok to me.

But, I see there's a reported (not yet verified) erratum (3718) [2]
for which no change has been made.  Should that also be verified
and the change made or not?

[1] https://tools.ietf.org/rfcdiff?url1=rfc5996&url2=draft-kivinen-ipsecme-ikev2-rfc5996bis-03.txt

[2] http://www.rfc-editor.org/errata_search.php?rfc=5996

Shepherd Writeup for draft-kivinen-ipsecme-ikev2-rfc5996bis-02

1. Summary

Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the
responsible AD.

This document replaces and updates RFC 5996 (IKEv2), and includes all of the errata for it,
and it is intended to update IKEv2 to be Internet Standard. It was meant to be part of an
effort to move IKEv2 to Full Standard, but that effort flagged; still, the draft has useful
clarifications.


2. Review and Consensus

The WG discussion of the document was scant, but with enough review to make it acceptable.
There were no objections to adoption.


3. Intellectual Property

The authors of RFC 5996 were already under the IPR rules.


4. Other Points

There is one necessary normative downref. RFC 3447 is for PKCS#1, which is required for implementation
of IKEv2. This was allowed for RFC 5996 (and others), and should be put on the allowed-downrefs list.

There are no new IANA registries because it is all clarifications.

IESG/Authors/WG Chairs:

IANA has reviewed draft-kivinen-ipsecme-ikev2-rfc5996bis-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about the action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the IKEv2 Certificate Encodings subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

http://www.iana.org/assignments/ikev2-parameters/

the document said:

"One item has been removed from the IKEv2 Certificate Encodings table:
  "Raw RSA Key"."

QUESTIONS:
1) Do the authors mean that this document is intended to remove
the value 11, "Raw RSA Key" from the subregistry?

2) If yes, should this item be removed, or should the item be left in
the registry and marked "Obsolete?"

Second, in the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

http://www.iana.org/assignments/ikev2-parameters/

references to the document RFC 5996 should be changed to [ RFC-to-be ].

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'Internet Key Exchange Protocol Version 2 (IKEv2)'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-04-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes version 2 of the Internet Key Exchange (IKE)
  protocol.  IKE is a component of IPsec used for performing mutual
  authentication and establishing and maintaining Security Associations
  (SAs).  This document replaces and updates RFC 5996, and includes all
  of the errata for it, and it is intended to update IKEv2 to be
  Internet Standard.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd Writeup for draft-kivinen-ipsecme-ikev2-rfc5996bis-02

1. Summary

Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the
responsible AD.

This document replaces and updates RFC 5996 (IKEv2), and includes all of the errata for it,
and it is intended to update IKEv2 to be Internet Standard. It was meant to be part of an
effort to move IKEv2 to Full Standard, but that effort flagged; still, the draft has useful
clarifications.


2. Review and Consensus

The WG discussion of the document was scant, but with enough review to make it acceptable.
There were no objections to adoption.


3. Intellectual Property

The authors of RFC 5996 were already under the IPR rules.


4. Other Points

There are no normative downrefs.

There are no new IANA registries because it is all clarifications.