[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Thu, 3 Jun 2004 07:42:28 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: [ietf-provreg] FW: Protocol Action: 'Redemption Grace Period Mapping for the Extensible Provisioning Protocol' to Proposed Standard

For what it's worth...

-Scott-

-----Original Message-----
From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org]
On Behalf Of The IESG
Sent: Wednesday, June 02, 2004 6:13 PM
To: ietf-announce@ietf.org
Cc: Internet Architecture Board; RFC Editor
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-04.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.

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].


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

Home | Date list | Subject list