Re: [ire] Escrow deposit watermark

Christopher Browne <> Thu, 21 March 2013 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CCFE21F8F53 for <>; Thu, 21 Mar 2013 15:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id orHvr7EdkhJM for <>; Thu, 21 Mar 2013 15:05:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6ED9021F8F4A for <>; Thu, 21 Mar 2013 15:05:59 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.69) (envelope-from <>) id 1UIncU-0003cV-6L for; Thu, 21 Mar 2013 22:05:58 +0000
Received: from ([]) by with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <>) id 1UIncU-0005XM-5r for; Thu, 21 Mar 2013 22:05:58 +0000
Received: by with SMTP id t10so5452452eei.2 for <>; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WzOipzbKnyqynGX+FEz7KhB8ZHA7s59oM+uvRKB+4yE=; b=YOV7n8JOuGeBDz8Gsq/x0D3f/PlvNNT22NIyN7RmVqktmkgmDK/FKJJnbdOXRI5e6X aM6Q5MQ0ZBOTI+9kbKWv3qYWzvF6q2fhd6rD3GlBdLfxlo+sf7XnQo/HqDM4OhHojPkf T6pRFXPbHywKeRuafKbvvC6U0CdRuFcj8rLjuoyVa8qBsvYbTb18j7/7epUkjToFW4h5 Hng6eT2eMYQ67qsWpD8dUNQLZD4BOSZSczkMPEm0o87Hye5Xv/CcOIdOsRPtYwn42gIa 7hbLE2b2srG7Ph+smM+XHkf7pLdJtN6iaQjbBRL9XaDgfeHpty92GP/0NuqHHAkW5nYM no/w==
X-Received: by with SMTP id cu9mr20075682wjc.39.1363903552779; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id cu9mr20075671wjc.39.1363903552640; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
Received: by with HTTP; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 21 Mar 2013 18:05:52 -0400
Message-ID: <>
From: Christopher Browne <>
To: Thomas Corte <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmDHLFs25ZxcyGlSil5WvPe5X7nyhYQgfYPPfnVbwP8qxpMYwHiV1lA02/SOH86YKwOElQp2VmpkxS2WK0hu1cAyhzcQXsoo4hwWvtdbvclTW/xM1IpdH5GO2CzYK4Ux4Tjy7FM
Subject: Re: [ire] Escrow deposit watermark
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Mar 2013 22:06:00 -0000

On Thu, Mar 21, 2013 at 5:35 AM, Thomas Corte <>; wrote:
> Hello,
> on Wed, 20 Mar 2013, Bhadresh Modi <>; 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.

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.

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.