Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
draft-hollenbeck-epp-rgp-04

Approval announcement
Draft of message to be sent after approval:

Announcement

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: '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

Ballot Text

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 2.9.1.1 and 7 of RFC 3730 [1].

RFC Editor Note