Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
RFC 5910

Approval announcement
Draft of message to be sent after approval:

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>
Subject: Protocol Action: 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)' to Proposed Standard

The IESG has approved the following document:

- 'Domain Name System (DNS) Security Extensions Mapping for the 
   Extensible Provisioning Protocol (EPP) '
   <draft-gould-rfc4310bis-07.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-07.txt

Technical Summary

   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for the provisioning and management of Domain Name
   System security extensions (DNSSEC) for domain names stored in a
   shared central repository.  Specified in XML, this mapping extends
   the EPP domain name mapping to provide additional features required
   for the provisioning of DNS security extensions.

   This document incorporates feedback from implementers and users.

   This document obsoletes RFC 4310.

Working Group Summary

   This document is not a product of a working group, the people that
   have participated in the discussions on the document seem to have
   come to an agreement that this is a good specification.
   As this was not a product of a working group some people that actually
   work in this area did not know the discussion of updating RFC4310
   was taking place. These same people once they joined the discussion
   made significant contributions.

Document Quality

   There are existing implementations of RFC 4310.
   This document is based on feedback from such implementors.

Personnel

   Olafur Gudmundsson is the Document Shepherd for this document.
   Alexey Melnikov is the responsible AD.

RFC Editor Note

In Section 4.1, 1st paragraph, last sentence:

   The key data SHOULD have the Secure Entry Point (SEP) bit set as
   described in RFC 3757 [RFC3757].

Please add a second reference to RFC 4034 at the end.