Subject: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 22 May 2003 08:07:54 -0400

This new I-D might be of interest to anyone having to implement ICANN's
Redemption Grace Period policy within EPP.  Comments and suggestions around
the "TBD" items are welcome.

-Scott-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 20, 2003 7:26 AM
To: IETF-Announce; @ietf.org
Subject: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Redemption Grace Period Mapping for the Extensible

                          Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-hollenbeck-epp-rgp-00.txt
	Pages		: 22
	Date		: 2003-5-19
	
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the management of Domain Name System (DNS)
domain names subject to the Redemption Grace Period (RGP) policies
defined by the Internet Corporation for Assigned Names and Numbers
(ICANN).  Specified in XML, this mapping extends the EPP domain name
mapping to provide additional features required for RGP processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rgp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hollenbeck-epp-rgp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hollenbeck-epp-rgp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: janusz sienkiewicz <[email-masked]>
Date: Thu, 22 May 2003 11:32:55 -0400

As the state diagram on page 5 shows rgp restore is in fact a two step process.
Step one is submitting <rgp:restore> request and step two is submitting resore
report. Step two can be repeated in case incorrect data was submitted in the
original report.

I think it would be useful if <rgp:restore> syntax allowed submiting
information required in restore report. It could be acomplished by introducing
"op" attribute (similiar to the one in transfer request). Valid values for the
attribute would be: "request", "validate".

Example restore request command:

...
<rgp:restore op="request"/>
...

Example restore validate command:

...
<rgp:restore op="validate">
    <!-- the content of restore report -->
</rgp:restore>
...

Multiple restore validate requests should be allowed. It is possible that a
client may send incorrect restore data so correction may be required.

Janusz Sienkiewicz

---

From: Peter Chow <[email-masked]>
Date: Fri, 23 May 2003 04:31:11 +0900 (JST)

> the "TBD" items are welcome.

Scott, in section 2 you said "(TBD: should the report be submitted through
the protocol (as part of the <restore>) or an out-of-band facility such as
a web site?)"

I would prefer if there is a mechanism in the protocol to submit the
reports.  Recently VGRS started an IDN renewal period extension program
that would allow registrars to have extra time to convince customers to
renew IDN domains.  This program required that the IDN domains first be
deleted and then restored, with the restore reports being submitted via
the Registrar Tool website.

The amount of manual work required to submit the restore report via the
website made this solution ineffective.  A mechanism for us to submit
the reports through the protocol would have allowed us to participate
in this program.

Peter

---

From: Mike Lampson <[email-masked]>
Date: Fri, 23 May 2003 12:39:09 -0400

Hi,

I am working on upgrading our EPP implementation to support the PIR Registry
and have come across an issue that I'm not sure is a problem with the
protocol definition or the implementation.

Both contact-05 (which PIR uses) and contact-07 describe the e164StringType
as follows:

    <simpleType name="e164StringType">
      <restriction base="token">
        <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?"/>
        <maxLength value="17"/>
      </restriction>
    </simpleType>

Should be maxLength be 19 instead of 17 to allow for the 2 fixed characters?

Thanks,

Mike Lampson
The Registry at Info Avenue, LLC