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

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Janusz,

Thanks for reading the document and taking time to comment.  We should
probably take this discussion off the provreg list, though, as this document
isn't a provreg work item.  I'll follow up with you privately.

-Scott-

> -----Original Message-----
> From: janusz sienkiewicz [mailto:janusz@libertyrms.info]
> Sent: Thursday, May 22, 2003 11:33 AM
> To: Hollenbeck, Scott
> Cc: 'ietf-provreg@cafax.se'
> Subject: Re: [ietf-provreg] FW: I-D
> ACTION:draft-hollenbeck-epp-rgp-00.txt
> 
> 
> 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
> 
> 
> 
> "Hollenbeck, Scott" wrote:
> 
> > 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > 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:
> >         mailserv@ietf.org.
> > 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.
>