diff --git a/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt b/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt
new file mode 100644
index 0000000000..0a7516bd64
--- /dev/null
+++ b/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt
@@ -0,0 +1,336 @@
+
+
+
+Domain Name System Operations                                 W. Mekking
+Internet-Draft                                                NLnet Labs
+Intended status: Standards Track                           June 29, 2010
+Expires: December 31, 2010
+
+
+    Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
+                   draft-mekking-dnsop-auto-cpsync-00
+
+Abstract
+
+   This document proposes a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+Requirements Language
+
+   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 RFC 2119 [RFC2119].
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 December 31, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+
+
+
+Mekking                 Expires December 31, 2010               [Page 1]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   This memo defines a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+   To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
+   must submit their DNSKEYs, or hashes of their DNSKEYs, to their
+   parent zone.  The parent zone publishes the hashes of the DNSKEYs in
+   the form of a DS record.  The DNSKEY RRset at the child may change
+   over time.  In order to keep the chain of trust intact, the DS
+   records at the parent zone also needs to be updated.  The rolling of
+   the keys with the SEP bit on is one of the few tasks in DNSSEC that
+   yet has to be fully automated.
+
+   The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
+   changes to the parent.
+
+   To bootstrap the direct communication channel, information must be
+   exchanged in order to detect service location and granting update
+   privileges.  A new or existing child zone can request a direct
+   communication channel with the parent.  If the parent allows for
+   direct communication with child zones, the parent can share the
+   required data to set up the channel to the child zone.  Once the
+   child has the required credentials, it can use the direct
+   communication channel with the parent to request zone changes related
+   to its delegation.
+
+   If a third party is involved, the third party can act on behalf of
+   the parent.  In this case, the third party will give out the required
+   credentials to set up the communication channel.
+
+   It is RECOMMENDED that the direct communication channel is secured
+   with TSIG [RFC2845] or SIG0 [RFC2931].
+
+2.  Access and Update Control
+
+   The DNS UPDATE normally is used for granting update permissions to a
+   machine that is within the boundary of the same organization.  This
+   document proposes to grant child zones the same permissions.
+   However, it MUST NOT be possible that a child zone updates
+
+
+
+Mekking                 Expires December 31, 2010               [Page 2]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   information in the parent zone that falls outside the administrative
+   domain of the corresponding delegation.  For example, it MUST NOT be
+   possible for a child zone to update the data that the parent is
+   authoritative for, or update a delegation that is pointed to a
+   different child zone.  It MUST only be able to update records that
+   match one of the following:
+
+   Or:   The owner name is equal the child zone name and RRtype is
+      delegation specific.  Currently those are records with RRtype NS
+      or DS.
+
+   Or:   The owner name is a subdomain of the child zone name and RRtype
+      is glue specific.  Currently those are records with RRtype A or
+      AAAA.
+
+   This list may be expanded in the future, if there is need for more
+   delegation related zone content.
+
+   In case of adding or deleting delegation specific records, the DNSSEC
+   related RRs in the parent zone might need to be updated.
+
+   The service location may be handed out by the registrar during
+   bootstrap If this information is missing, the normal guidelines for
+   sending DNS UPDATE messages SHOULD be followed.
+
+3.  Update Mechanism
+
+3.1.  Child Duties
+
+   Updating the NS RRset or corresponding glue at the parent, an update
+   can be sent at any time.  Updating the DS RRset is part of key
+   rollover, as described in RFC 4641 [RFC4641].  When performing a key
+   rollover that involves updating the RRset at the parent, the child
+   introduces a new DNSKEY in its zone that represents the security
+   entry point for determining the chain of trust.  After a while, it
+   will revoke and/or remove the previous security entry point.  The
+   timings when to update the DS RRset at the parent are described in
+   draft-dnsop-morris-dnssec-key-timing [keytiming].  When updating the
+   DS RRset at the parent automatically, these timing specifications
+   SHOULD be followed.  To determine the propagation delays described in
+   this document, the child should poll the parent zone for a short
+   time, until the DS is visible at all parent name servers.
+
+   To discuss: A child zone might be unable to reach all parent name
+   servers.
+
+   The child notifies the parent of the requested changes by sending a
+   DNS UPDATE message.  If it receives a NOERROR reply in return, the
+
+
+
+Mekking                 Expires December 31, 2010               [Page 3]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   update is acknowledged by the parent zone.  Otherwise, the child MAY
+   retry transmitting the update.  In order to prevent duplicate
+   updates, it SHOULD follow the guidelines described in RFC 2136
+   [RFC2136].
+
+3.2.  Parent Duties
+
+   When the master DNS server of the parent receives a DNS UPDATE from
+   one of its children the following must be done:
+
+   Step 1:  Check the TSIG/SIG0 credentials.  In case of TSIG, the
+      parent should follow the TSIG processing described in section 3.2
+      of RFC 2845.  In case of SIG0, the parent should follow the SIG0
+      processing described in section 3.2 of RFC 2931.
+
+   Step 2:  Verify that the updates matches the update policy for child
+      zones.
+
+   Step 3:  If verified, send back DNS UPDATE OK.  Otherwise, send back
+      DNS UPDATE REFUSED.
+
+   Step 4:  If verified, apply changes.  How that is done is a matter of
+      policy.
+
+3.3.  Proxy considerations
+
+   Some environments don't allow for direct communication between parent
+   and child zone.  In these case, the parent duties can be performed by
+   a different party (for example, the registar).  The third party will
+   forward the update to the parent zone.  In what format depends on
+   local policy.
+
+4.  Example BIND9 Configuration
+
+   This is how a parent zone can configure a policy to enable a child
+   zone synchronize delegation specific records.  The first rule of the
+   update policy grants children to update their DS and NS records in
+   the parent zone, in this case example.com.  The second rule of the
+   update policy grants children to update the corresponding glue
+   records.
+
+   key cs.example.com. {
+   algorithm HMAC-MD5;
+   secret "secretforcs";
+   }
+
+   key math.example.com. {
+   algorithm HMAC-MD5;
+
+
+
+Mekking                 Expires December 31, 2010               [Page 4]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   secret "secretformath";
+   }
+
+   ...
+
+   zone "example.com" {
+   type master;
+   file "example.com";
+   update-policy { grant *.example.com. self *.example.com.  DS NS; };
+   update-policy { grant *.example.com. selfsub *.example.com.  A AAAA;
+   };
+   };
+
+5.  Security Considerations
+
+   Automating the synchronization of (DNSSEC) records between the parent
+   and child created a new channel.  We have recommended that this
+   channel should be secured with TSIG or SIG0.  There is an advantage
+   and a disadvantage of the new security channel.  The disadvantage is
+   that you create a new attack window for your DNSSEC credentials.  If
+   the automated synchronization is used for updating DS records at the
+   parent, you SHOULD pick a cryptographically an equally strong or
+   stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
+
+   The advantage is that if somehow your DNSSEC keys are compromised,
+   you can still use this channel to perform an emergency key rollover.
+
+6.  IANA Considerations
+
+   None.
+
+7.  Acknowledgments
+
+   Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
+
+8.  References
+
+8.1.  Informative References
+
+   [RFC2136]    Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+                "Dynamic Updates in the Domain Name System (DNS
+                UPDATE)", RFC 2136, April 1997.
+
+   [RFC4641]    Kolkman, O. and R. Gieben, "DNSSEC Operational
+                Practices", RFC 4641, September 2006.
+
+   [keytiming]  Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
+                Timing Considerations", March 2010.
+
+
+
+Mekking                 Expires December 31, 2010               [Page 5]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+8.2.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+                Wellington, "Secret Key Transaction Authentication for
+                DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]    Eastlake, D., "DNS Request and Transaction Signatures (
+                SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC4035]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                Rose, "Protocol Modifications for the DNS Security
+                Extensions", RFC 4035, March 2005.
+
+Author's Address
+
+   Matthijs Mekking
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: matthijs@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mekking                 Expires December 31, 2010               [Page 6]
+