Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2bis (Internet Key Exchange Protocol: IKEv2) to Proposed Standard

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Mar 2010 15:01:36 -0800

Of definite interest to the WG:

>X-Original-To: [email-masked]
>Delivered-To: [email-masked]
>X-idtracker: yes
>To: IETF-Announce <[email-masked]>
>From: The IESG <[email-masked]>
>Subject: Last Call: draft-ietf-ipsecme-ikev2bis (Internet Key Exchange
>	Protocol: IKEv2) to Proposed Standard
>Date: Thu,  4 Mar 2010 11:45:13 -0800 (PST)
>Cc: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.9
>Reply-To: [email-masked]
>List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>
>The IESG has received a request from the IP Security Maintenance and
>Extensions WG (ipsecme) to consider the following document:
>
>- 'Internet Key Exchange Protocol: IKEv2 '
>   <draft-ietf-ipsecme-ikev2bis-08.txt> as a Proposed 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
>[email-masked] mailing lists by 2010-03-18. Exceptionally,
>comments may be sent to [email-masked] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-08.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17667&rfc_flag=0
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Mar 2010 19:17:50 -0700

The IETF Last Call on IKEv2bis is now over (but comments are still welcome). I have made the following changes to the draft. I'll turn in the draft on Monday after the face-to-face meeting, and our new AD will then put it on a future IESG telechat. You'll have plenty of time to review the diffs before that telechat so you can tell me if I muffed anything.

Thanks again for all the input!

--Paul Hoffman

D.16.  Changes from draft-ietf-ipsecme-ikev2bis-08 to
       draft-ietf-ipsecme-ikev2bis-09

   These changes came during IETF Last Call.

   Fixed some minor editorial nits.

   In 1.3, changed "this notify" to "this notification".

   In 2.6, changed "will cause two packets:" to "will cause two packets
   to be sent:".

   Moved the paragraph that starts "When the IKE_SA_INIT exchange does
   not result" from 2.7 to 2.6.  Also changed"the responder's SPI will
   be zero" to "the responder's SPI will be zero also in the response
   message".

   In 2.8.2, last paragraph: Change the beginning of the sentence and
   changed "older peers may receive these notifications" to "older peers
   that implement RFC 4306 but not this document may receive these
   notifications".

   Fixed the first two paragraphs of 2.9 to talk about PFKEY in the
   correct context.

   In 2.23, clarified the paragraph that starts "An initiator can
   use..." in many places, saying that it is UDP encapsulated ESP.

   In 3.3.6, changed "If one of the proposals offered is for the Diffie-
   Hellman group of NONE, the responder MUST ignore the initiator's KE
   payload and omit the KE payload from the response" to "If one of the
   proposals offered is for the Diffie-Hellman group of NONE, and the
   responder selects that Diffie-Hellman group, then it MUST ignore the
   initiator's KE payload and omit the KE payload from the response".
   [Issue #176]

   In 3.5, changed "IPv6-only implementations MAY be configurable to
   send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses" to
   "IPv6-only implementations MAY be configurable to send only
   ID_IPV6_ADDR instead of ID_IPV4_ADDR for IP addresses".