Re: [ire] Escrow deposit watermark

Gustavo Lozano <gustavo.lozano@icann.org> Thu, 21 March 2013 23:17 UTC

Return-Path: <gustavo.lozano@icann.org>
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 3F59921F841D for <ire@ietfa.amsl.com>; Thu, 21 Mar 2013 16:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.441
X-Spam-Level:
X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 YXTGL+wKVNkM for <ire@ietfa.amsl.com>; Thu, 21 Mar 2013 16:17:01 -0700 (PDT)
Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB921F8F92 for <ire@ietf.org>; Thu, 21 Mar 2013 16:17:01 -0700 (PDT)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 21 Mar 2013 16:17:00 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: James Mitchell <james.mitchell@ausregistry.com.au>, "ire@ietf.org" <ire@ietf.org>
Date: Thu, 21 Mar 2013 16:16:59 -0700
Thread-Topic: [ire] Escrow deposit watermark
Thread-Index: Ac4mijBiRpBYODy2Sw+H7Wj1DlfYAg==
Message-ID: <CD70DF74.E30B%gustavo.lozano@icann.org>
In-Reply-To: <CD6F502A.6A7E1%james.mitchell@ausregistry.com.au>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CD70DF74E30Bgustavolozanoicannorg_"
MIME-Version: 1.0
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 23:17:13 -0000

James,

Comments inline.

Regards,
Gustavo

From: James Mitchell <james.mitchell@ausregistry.com.au<mailto:james.mitchell@ausregistry.com.au>>
Date: Tuesday, March 19, 2013 5:38 PM
To: "ire@ietf.org<mailto:ire@ietf.org>" <ire@ietf.org<mailto:ire@ietf.org>>
Subject: [ire] Escrow deposit watermark

All,

This email is primarily targeted towards ICANN and the draft registry agreement, however posting here for feedback from others who are implementing escrow.

Our proposed escrow solution would produce deposits for all transactions committed up to the point in time that the extract is generated. This may be considered contrary to the base agreement, where deposits must reflect the state of the registry as at 00:00 UTC. As we will generate full deposits every day, each deposit would include the state of the registry as at 00:00, plus the state of the registry including transactions committed up until the generation of the deposit. We do not perceive this as a lesser service, given the escrowed data is more up-to-date, unless there are other reasons for the 00:00 requirement that are unknown to us. Is the proposed solution considered acceptable given the requirements outlined in the base agreement?

Unfortunately no.

The reason for this requirement is our audit process. One of the projected tests is the correlation of data from different sources: monthly reports, escrow deposits, bulk registration data and DNS zone.


It should be noted that acceptance of the above will require that escrow deposit validation does not check for the presence of date-times, for example domain creation date, that are after 00:00 UTC. If date-time validation is deemed required, the validator should ensure that no date-time is greater than the watermark.

Further to this, we seek confirmation that in the event of a failed deposit, a subsequent full deposit representing the current state of the registry database would constitute remedy. ARI would not provide a full deposit of the state of the registry database as at the time of the previous failed deposit.

Comments/feedback welcome.

Regards,
James