Re: [ire] Escrow deposit watermark

Christopher Browne <cbbrowne@afilias.info> Thu, 21 March 2013 22:06 UTC

Return-Path: <cbbrowne@afilias.info>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCFE21F8F53 for <ire@ietfa.amsl.com>; Thu, 21 Mar 2013 15:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orHvr7EdkhJM for <ire@ietfa.amsl.com>; Thu, 21 Mar 2013 15:05:59 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9021F8F4A for <ire@ietf.org>; Thu, 21 Mar 2013 15:05:59 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <cbbrowne@afilias.info>) id 1UIncU-0003cV-6L for ire@ietf.org; Thu, 21 Mar 2013 22:05:58 +0000
Received: from mail-ee0-f71.google.com ([74.125.83.71]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <cbbrowne@afilias.info>) id 1UIncU-0005XM-5r for ire@ietf.org; Thu, 21 Mar 2013 22:05:58 +0000
Received: by mail-ee0-f71.google.com with SMTP id t10so5452452eei.2 for <ire@ietf.org>; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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 10.194.178.9 with SMTP id cu9mr20075682wjc.39.1363903552779; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.178.9 with SMTP id cu9mr20075671wjc.39.1363903552640; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
Received: by 10.194.165.200 with HTTP; Thu, 21 Mar 2013 15:05:52 -0700 (PDT)
In-Reply-To: <Pine.GHP.4.64.1303211016380.24937@hp9000.do.knipp.de>
References: <Pine.GHP.4.64.1303211016380.24937@hp9000.do.knipp.de>
Date: Thu, 21 Mar 2013 18:05:52 -0400
Message-ID: <CANfbgbY282RJdBEx78rwNsNe0dewkpFsSGjY4+xFu0XcdxWanQ@mail.gmail.com>
From: Christopher Browne <cbbrowne@afilias.info>
To: Thomas Corte <Thomas.Corte@knipp.de>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQmDHLFs25ZxcyGlSil5WvPe5X7nyhYQgfYPPfnVbwP8qxpMYwHiV1lA02/SOH86YKwOElQp2VmpkxS2WK0hu1cAyhzcQXsoo4hwWvtdbvclTW/xM1IpdH5GO2CzYK4Ux4Tjy7FM
Cc: ire@ietf.org
Subject: Re: [ire] Escrow deposit watermark
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2013 22:06:00 -0000

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

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.