Hello, On 07/04/2017 13:46, Hollenbeck, Scott wrote:
> 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. 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 -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
