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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 22 May 2003 12:36:14 -0400

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:[email-masked]]
> Sent: Thursday, May 22, 2003 11:33 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> 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: [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: Edward Lewis <[email-masked]>
Date: Thu, 22 May 2003 13:06:44 -0400

>isn't a provreg work item.  I'll follow up with you privately.

I would encourage you to continue to make use of the mailing list. 
The list will outlast the group (assuming the current plan of 
shutting down the group at PS holds).  The list will be a good place 
to collect implementation thoughts, etc., and a good place to make a 
call to form a group to publish the Draft Standard documents.

Keep in mind, In RFC 2026, section 4.1.1.:

    Implementors should treat Proposed Standards as immature
    specifications.  It is desirable to implement them in order to gain
    experience and to validate, test, and clarify the specification.
    However, since the content of Proposed Standards may be changed if
    problems are found or better solutions are identified, deploying
    implementations of such standards into a disruption-sensitive
    environment is not recommended.

So, draft standard is something folks should have an eye on down the road.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Your office is *not* a reality-based sit-com TV show.