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

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.

Any comments I have are included in Zhen's INTDir review that is embedded in the other INT AD's ballot.

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.

Thanks to Stephen for balloting that he had reviewed the diff vs. 5996  :)

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

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",
             <http://www.iana.org>.

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