--- 1/draft-ietf-ipsecme-esp-ah-reqts-08.txt	2014-05-16 11:14:17.551503801 -0700
+++ 2/draft-ietf-ipsecme-esp-ah-reqts-09.txt	2014-05-16 11:14:17.579504482 -0700
@@ -1,20 +1,20 @@
 
 Network Working Group                                          D. McGrew
 Internet-Draft                                             Cisco Systems
 Obsoletes: 4835 (if approved)                                 P. Hoffman
 Intended status: Standards Track                          VPN Consortium
-Expires: November 16, 2014                                  May 15, 2014
+Expires: November 17, 2014                                  May 16, 2014
 
  Cryptographic Algorithm Implementation Requirements and Usage Guidance
 for Encapsulating Security Payload (ESP) and Authentication Header (AH)
-                   draft-ietf-ipsecme-esp-ah-reqts-08
+                   draft-ietf-ipsecme-esp-ah-reqts-09
 
 Abstract
 
    This Internet Draft is a standards track proposal to update the
    Cryptographic Algorithm Implementation Requirements for ESP and AH;
    it also adds usage guidance to help in the selection of these
    algorithms.
 
    The Encapsulating Security Payload (ESP) and Authentication Header
    (AH) protocols make use of various cryptographic algorithms to
@@ -39,21 +39,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 November 16, 2014.
+   This Internet-Draft will expire on November 17, 2014.
 
 Copyright Notice
 
    Copyright (c) 2014 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
@@ -251,21 +251,21 @@
    gigabytes of data will be encrypted with a single key.  As a 64-bit
    block cipher, it leaks information about plaintexts above that
    "birthday bound" [M13].  Triple-DES CBC is listed as a MAY implement
    for the sake of backwards compatibility, but its use is discouraged.
 
 4.  Rationale
 
    This section explains the principles behind the implementation
    requirements described above.
 
-   The algorithms listed as MAY-implement are not meant to be endorsed
+   The algorithms listed as "MAY implement" are not meant to be endorsed
    over other non-standard alternatives.  All of the algorithms that
    appeared in [RFC4835] are included in this document, for the sake of
    continuity.  In some cases, these algorithms have moved from being
    "SHOULD implement" to "MAY implement" algorithms.
 
 4.1.  Authenticated Encryption
 
    This document encourages the use of authenticated encryption
    algorithms because they can provide significant efficiency and
    throughput advantages, and the tight binding between authentication