Subject: Re: [ire] Escrow deposit watermark

From: Thomas Corte <[email-masked]>
Date: Thu, 21 Mar 2013 10:35:16 +0100 (MEZ)

Hello,

on Wed, 20 Mar 2013, Bhadresh Modi <[email-masked]> wrote:

> We've had the same concern and some of our account managers have
> raised the issue before with icann.
>
> Another thing to point out is that even if all processes to esrow all
> registries are started at 00:00 UTC with that watermark, there may be
> a problem which causes an escrow to fail.  Restarting the process
> then will begin a new escrow but it may be impossible to return to
> the state at exactly 00:00 UTC.  Again as pointed out before, this
> new deposit file would contain all information as of 00:00 UTC and
> also include any new transactions taken place after that time.

Frankly, I'm quite surprised by this simplistic approach to Escrow 
generation (which inevitably leads to the problem you're describing), 
which seems to have been taken by other backend providers, too.

In order to achieve what the applicant guide book demands (and which has 
been a requirement in previous Escrow specifications issued by ICANN btw), 
it is of course essential that a registry maintains a detailed version 
history of all repository objects, each object version carrying the start 
and end date/time of its validity. Only this allows taking a snapshot of 
the registry database for a given time stamp and, in turn, creating a 
precise escrow, regardless of when the Escrow is produced.

While I recognize that having an Escrow for an exact date and time is 
probably more a formal than a practical matter, I think it is questionable 
to simply disregard this requirement from the applicant guidebook. After 
all, other applicants and their backend providers (such as the company I 
am working for) *do* adhere to the specification, and had to go to great 
length in order to achieve that. Simply asking ICANN to alter the spec for 
simplification purposes means gaining an unfair competitive advantage over 
those backend providers who decided to add the required sophistication to 
their systems.

Best regards,

Thomas Corte

-- 
____________________________________________________________________
      |       |
      | knipp |            Knipp  Medien und Kommunikation GmbH
       -------                    Technologiepark
                                  Martin-Schmeisser-Weg 9
                                  44227 Dortmund
                                  Germany

      Dipl.-Informatiker          Fon:    +49 231 9703-0
      Thomas Corte                Fax:    +49 231 9703-200
      Senior Software Developer   SIP:    [email-masked]
                                  E-Mail: [email-masked]

                                  Register Court:
                                  District Court Dortmund, HRB 13728

                                  Chief Executive Officers:
                                  Dietmar Knipp, Elmar Knipp

---

From: Christopher Browne <[email-masked]>
Date: Thu, 21 Mar 2013 18:05:52 -0400

On Thu, Mar 21, 2013 at 5:35 AM, Thomas Corte <[email-masked]> wrote:
> generation (which inevitably leads to the problem you're describing), which
> seems to have been taken by other backend providers, too.
>
> and end date/time of its validity. Only this allows taking a snapshot of the
> registry database for a given time stamp and, in turn, creating a precise
> escrow, regardless of when the Escrow is produced.
>
> all, other applicants and their backend providers (such as the company I am
> working for) *do* adhere to the specification, and had to go to great length
> in order to achieve that. Simply asking ICANN to alter the spec for

Hmm. I was going to retort that the IRE specifications say nothing about a
"00:00 UTC" requirement, however I found the place where that *is*
imposed, namely in the Revised New gTLD Registry Agreement.

http://www.icann.org/en/news/public-comment/base-agreement-05feb13-en.htm

It arguably invalidates some of the details of the recent IRE drafts, in that
it imposes the use of specific filenames that comprise the watermark data,
NOT in a date/time form, but rather with the strict imposition of YYYY-MM-DD,
with 00:00 UTC.

It seems to impose more than I'd expect to be considered reasonable; I
wouldn't think that this is the right forum to pursue fixes to it.