Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org> Subject: Protocol Action: 'Redemption Grace Period Mapping for the Extensible Provisioning Protocol' to Proposed Standard The IESG has approved the following document: - 'Redemption Grace Period Mapping for the Extensible Provisioning Protocol ' <draft-hollenbeck-epp-rgp-05.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 Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rgp-05.txt
Technical Summary This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. Working Group Summary This document is the work of an individual submitter, but it has been discussed on the mailing list previously associated with the PROVREG working group. No dissent over this extension was received during Last Call or in mailing list discussion. Protocol Quality This document was reviewed by Ted Hardie for the IESG. There is at least one implementation, and more are expected. RFC Editor Note: Old: As with other domain object updates, redemption of a deleted domain objec MUST be restricted to the sponsoring client. New: As with other domain object updates, redemption of a deleted domain objec MUST be restricted to the sponsoring client as authenticated using the mechanisms described in sections 18.104.22.168 and 7 of RFC 3730 .