--- 1/draft-ietf-dnsext-dnssec-algo-signal-04.txt	2012-03-26 16:14:13.610671898 +0200
+++ 2/draft-ietf-dnsext-dnssec-algo-signal-05.txt	2012-03-26 16:14:13.630672629 +0200
@@ -1,19 +1,19 @@
 
 DNS Extensions Working Group                                  S. Crocker
 Internet-Draft                                             Shinkuro Inc.
 Intended status: Standards Track                                 S. Rose
-Expires: September 7, 2012                                          NIST
-                                                           March 6, 2012
+Expires: September 27, 2012                                         NIST
+                                                          March 26, 2012
 
        Signaling Cryptographic Algorithm Understanding in DNSSEC
-                draft-ietf-dnsext-dnssec-algo-signal-04
+                draft-ietf-dnsext-dnssec-algo-signal-05
 
 Abstract
 
    The DNS Security Extensions (DNSSEC) were developed to provide origin
    authentication and integrity protection for DNS data by using digital
    signatures.  These digital signatures can be generated using
    different algorithms.  This draft sets out to specify a way for
    validating end-system resolvers to signal to a server which
    cryptographic algorithms and hash algorithms they support.
 
@@ -31,21 +31,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 7, 2012.
+   This Internet-Draft will expire on September 27, 2012.
 
 Copyright Notice
 
    Copyright (c) 2012 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
@@ -259,30 +259,34 @@
    processing on the server side.
 
    If the options are present but the DNSSEC-OK (OK) bit is not set, the
    server does not do any DNSSEC processing, including any recording of
    the option(s).
 
 6.  Traffic Analysis Considerations
 
    Zone administrators that are planning or are in the process of a
    cryptographic algorithm rollover operation should monitor DNS query
-   traffic and record the values of the DAU/DHU/N3U option(s) in
-   queries.  This monitoring can measure the deployment of client code
-   that implements (and signals) certain algorithms.  Exactly how to
+   traffic and record the number of queries, the presense of the OPT RR
+   in queries and the values of the DAU/DHU/N3U option(s) (if present).
+   This monitoring can be used to measure the deployment of client code
+   that implements (and signals) certain algorithms.  The Exactly how to
    capture DNS traffic and measure new algorithm adoption is beyond the
    scope of this document.
 
-   Zone administrators can use this data to set plans for starting an
-   algorithm rollover and determine when older algorithms can be phased
-   out without disrupting a significant number of clients.  In order to
-   keep this disruption to a minimum, zone administrators should wait to
+   Zone administrators that need to comply with changes to their
+   organization's security policy (with regards to cryptographic
+   algorithm use) can use this data to set milestone dates for
+   performing an algorithm rollover.  For example, zone administrators
+   can use the data to determine when older algorithms can be phased out
+   without disrupting a significant number of clients.  In order to keep
+   this disruption to a minimum, zone administrators should wait to
    complete an algorithm rollover until a large majority of clients
    signal that they understand the new algorithm.  This may be in the
    order of years rather than months.  Note that clients that do not
    implement these options are likely to be older implementations which
    would also not implement any newly deployed algorithm.
 
 7.  IANA Considerations
 
    The algorithm codes used to identify DNSSEC algorithms, DS RR hash
    algorithms and NSEC3 hash algorithms have already been established by