Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 7296
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Jari Arkko; former steering group member) Yes
(Kathleen Moriarty; former steering group member) Yes
(Richard Barnes; former steering group member) Yes
RSA is so well known we no longer need a reference?
(Adrian Farrel; former steering group member) No Objection
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.
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
Any comments I have are included in Zhen's INTDir review that is embedded in the other INT AD's ballot.
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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.
(Spencer Dawkins; former steering group member) No Objection
Thanks to Stephen for balloting that he had reviewed the diff vs. 5996 :)
(Stephen Farrell; former steering group member) No Objection
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
(Ted Lemon; former steering group member) No Objection
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