Subject: [regext] domain restore without pendingRestore state

From: Michael Bauland <[email-masked]>
Date: Fri, 7 Apr 2017 09:58:15 +0200

Hello,

I have a question regarding the EPP restoration mechanism defined in RFC
3915.

It is defined quite clearly that a domain restore command with operation
"request" must not contain a report element. Further, such a request
must have "pendingRestore" as the outcome. In a next step a restore
command with operation "report" can be sent to complete the restoration
process.

Is there a (legal) way for an ICANN regulated ngTLD to restore a domain
with just a single EPP request, e.g., sending the "report" command
without a prior restore "request" or is this two-step approach mandatory?

We've been approached by customers stating that this is stupid and no
other registry requires these two steps. Any thoughts?

Best regards,

Michael

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH             Dr. Michael Bauland
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 7 Apr 2017 11:46:16 +0000

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of Michael Bauland
> Sent: Friday, April 07, 2017 3:58 AM
> To: [email-masked]
> Subject: [EXTERNAL] [regext] domain restore without pendingRestore state
>
> Hello,
>
> "request" must not contain a report element. Further, such a request must
> have "pendingRestore" as the outcome. In a next step a restore command
> with operation "report" can be sent to complete the restoration process.
>
> with just a single EPP request, e.g., sending the "report" command without
> a prior restore "request" or is this two-step approach mandatory?
>

Michael, any registry that implements the ICANN redemption grace period process is going to use the two-step procedure associated with that process. If the ICANN process were different, it would make sense for the RFC to have been written differently. It might help to read this document:

https://archive.icann.org/en/meetings/bucharest/redemption-topic.htm

Note that the procedure includes support for out-of-band delivery of reports. I wrote 3915 the way I did in an attempt for the protocol to be consistent with the procedure. In hindsight, yes, it might have been useful to allow inclusion of the report with the restore request.

Scott

---

From: Thomas Corte <[email-masked]>
Date: Fri, 7 Apr 2017 15:03:54 +0200

Hello,

> Note that the procedure includes support for out-of-band delivery of reports. I wrote 3915 the way I did in an attempt for the protocol to be consistent with the procedure. In hindsight, yes, it mi…

Not only that, it's also doubtful IMHO which purpose most elements of the
restore report shall even serve, especially in the context of *thick*
registries, the now predominant data model:

1. Whois data prior to the deletion is known to a thick registry
2. same goes for Whois data at the time of the report
3. same goes for deletion date/time
4. same goes for restoration date/time
6. statement that registrar has not restored the Registered Name in order
   to assume the rights - should be implied, only one valid option here
7. statement that the information is true to best of the registrar’s
   knowledge - should also be implied

So the only actually useful piece of information to demand is number 5,
the reason for the restoration, which could be added to the restore request.

Best regards,

Thomas

Knipp Medien und Kommunikation GmbH