Internet Key Exchange (IKEv2) Protocol
draft-ietf-ipsec-ikev2-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ipsec mailing list <ipsec@ietf.org>, 
    ipsec chair <ipsec-chairs@tools.ietf.org>
Subject: Protocol Action: 'Internet Key Exchange (IKEv2) 
         Protocol' to Proposed Standard 

The IESG has approved the following document:

- 'Internet Key Exchange (IKEv2) Protocol '
   <draft-ietf-ipsec-ikev2-18.txt> as a Proposed Standard

This document is the product of the IP Security Protocol Working Group. 

The IESG contact persons are Russ Housley and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-18.txt

Ballot Text

Technical Summary

  This document describes version 2 of the Internet Key Exchange (IKE)
  protocol.  IKE is the component of IPsec used for performing mutual
  authentication and establishing and maintaining security associations.

  Version 2 of the IKE specification includes the contents of what were
  previously separate documents, including ISAKMP (RFC 2408), IKE
  version 1 (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal,
  Legacy authentication, and remote address acquisition.

  Version 2 of IKE does not interoperate with version 1 of IKE.
  However, it has enough of the header format in common that both
  versions can unambiguously share the same UDP port.

Working Group Summary

  The IPsec Working Group came to rough consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.

RFC Editor Note

  The last paragraph of section 2 includes a typo.  Please change
  "rather then" to "rather than."

  OLD:

  ... Use of the "Hash and URL" formats rather
  then including certificates in exchanges where possible can avoid
  most problems. ...

  NEW:

  ... Use of the "Hash and URL" formats rather
  than including certificates in exchanges where possible can avoid
  most problems. ...

RFC Editor Note