--- 1/draft-ietf-ipsecme-eddsa-01.txt	2017-04-06 21:13:08.470034166 -0700
+++ 2/draft-ietf-ipsecme-eddsa-02.txt	2017-04-06 21:13:08.482034449 -0700
@@ -1,19 +1,19 @@
 
 IPSecME Working Group                                             Y. Nir
 Internet-Draft                                               Check Point
-Intended status: Standards Track                          March 12, 2017
-Expires: September 13, 2017
+Intended status: Standards Track                           April 5, 2017
+Expires: October 7, 2017
 
 Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet
                           Key Exchange (IKEv2)
-                      draft-ietf-ipsecme-eddsa-01
+                      draft-ietf-ipsecme-eddsa-02
 
 Abstract
 
    This document describes the use of the Edwards-curve digital
    signature algorithm in the IKEv2 protocol.
 
 Status of This Memo
 
    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.
@@ -21,21 +21,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on September 13, 2017.
+   This Internet-Draft will expire on October 7, 2017.
 
 Copyright Notice
 
    Copyright (c) 2017 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -90,26 +90,25 @@
    one that indicates that no hashing is performed.
 
 1.1.  Conventions Used in This Document
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].
 
 2.  The "Identity" Hash Identifier
 
-   This document defines a new value called "Identity" (value TBA by
-   IANA) in the hash algorithm registry for use in the
-   SIGNATURE_HASH_ALGORITHMS notification.  Inserting this new value
-   into the notification indicates that the receiver supports at least
-   one signature algorithm that accepts arbitrary-sized messages such as
-   Ed25519 and Ed448.
+   This document defines a new value called "Identity" (value is 5) in
+   the hash algorithm registry for use in the SIGNATURE_HASH_ALGORITHMS
+   notification.  Inserting this new value into the notification
+   indicates that the receiver supports at least one signature algorithm
+   that accepts arbitrary-sized messages such as Ed25519 and Ed448.
 
    Ed25519 and Ed448 are only defined with the Identity hash, and MUST
    NOT be sent to a receiver that has not indicated support for the
    "Identity" hash.
 
    The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph
    respectively) SHOULD NOT be used in IKE.
 
 3.  Security Considerations
 
@@ -118,24 +117,27 @@
    supported algorithms has this property.  On the other hand there is
    no good reason to pre-hash the inputs where the signature algorithm
    either does not require it or performs a hash internally.  For this
    reason implementations SHOULD have the "Identity" value in the
    SIGNATURE_HASH_ALGORITHMS notification when they support EdDSA.
    Implementations SHOULD NOT have other hash algorithms in the
    notification if all signature algorithms have this property.
 
 4.  IANA Considerations
 
-   IANA is requested to assign a new value from the "IKEv2 Hash
-   Algorithms" registry with name "Identity" and this document as
+   IANA has assigned the value 5 for the algorithm with the name
+   "Identity" in the "IKEv2 Hash Algorithms" registry with this draft as
    reference.
 
+   Upon publication of this document IANA is requested to update the
+   entry with this document as reference.
+
 5.  Normative References
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,
               DOI 10.17487/RFC2119, March 1997,
               <http://www.rfc-editor.org/info/rfc2119>.
 
    [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
               Kivinen, "Internet Key Exchange Protocol Version 2
               (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October