From gustavo.lozano@icann.org Tue Mar 12 07:54:49 2013 Return-Path: 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 50E9421F8B2B for ; Tue, 12 Mar 2013 07:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 ObieZhDpZMko for ; Tue, 12 Mar 2013 07:54:48 -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 2876421F8A18 for ; Tue, 12 Mar 2013 07:54:48 -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; Tue, 12 Mar 2013 07:54:47 -0700 From: Gustavo Lozano To: "ire@ietf.org" Date: Tue, 12 Mar 2013 07:54:46 -0700 Thread-Topic: New versions of data escrow drafts Thread-Index: Ac4fMYocS0NoaqyiSYW/Y095rpHTkQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Tue, 12 Mar 2013 14:54:49 -0000 Colleagues, =20 Two new versions of the data escrow drafts have been published: * http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt * http://www.ietf.org/id/draft-arias-noguchi-registry-data-escrow-05.txt =20 These drafts incorporate feedback received in this list and private emails. =20 The authors of draft-arias-noguchi-dnrd-objects-mapping and draft-gould-thippeswamy-dnrd-csv-mapping agreed to merge both drafts to create a single specification that supports XML only and XML+CSV. =20 The data elements/objects in both drafts have been normalized. =20 The authors of draft-gould-thippeswamy-dnrd-csv-mapping will publish a new version of the CSV draft before the merge of both drafts. =20 The new version (03) of the draft draft-arias-noguchi-dnrd-objects-mapping is going to include both models (XML only and XML+CSV). =20 Version 03 should include only minor changes to the data escrow specification. =20 If you are attending the IETF 86 meeting and want to talk about data escrow, please send me an email and we can arrange an informal meeting. =20 Regards, Gustavo Lozano From chris@ausregistry.com.au Tue Mar 12 17:35:19 2013 Return-Path: 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 E587311E80EF for ; Tue, 12 Mar 2013 17:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=1.129, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_33=0.6] 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 wKHwnjKFwqgZ for ; Tue, 12 Mar 2013 17:35:19 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 04D5011E80E9 for ; Tue, 12 Mar 2013 17:35:17 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 13 Mar 2013 11:35:16 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 13 Mar 2013 11:35:05 +1100 From: Chris Wright To: Gustavo Lozano , "ire@ietf.org" Date: Wed, 13 Mar 2013 11:35:14 +1100 Thread-Topic: New versions of data escrow drafts Thread-Index: Ac4fMYocS0NoaqyiSYW/Y095rpHTkQAUP2ZA Message-ID: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 00:35:20 -0000 Thanks Gustavo, We are still a little unsure as to why it is XML + CSV, and not just simply= CSV? The choices should be XML or CSV.. Thanks Chris -----Original Message----- From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of Gusta= vo Lozano Sent: Wednesday, 13 March 2013 1:55 AM To: ire@ietf.org Subject: [ire] New versions of data escrow drafts Colleagues, =20 Two new versions of the data escrow drafts have been published: * http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt * http://www.ietf.org/id/draft-arias-noguchi-registry-data-escrow-05.txt =20 These drafts incorporate feedback received in this list and private emails. =20 The authors of draft-arias-noguchi-dnrd-objects-mapping and draft-gould-thi= ppeswamy-dnrd-csv-mapping agreed to merge both drafts to create a single sp= ecification that supports XML only and XML+CSV. =20 The data elements/objects in both drafts have been normalized. =20 The authors of draft-gould-thippeswamy-dnrd-csv-mapping will publish a new = version of the CSV draft before the merge of both drafts. =20 The new version (03) of the draft draft-arias-noguchi-dnrd-objects-mapping is going to include both models (XML only and XML+CSV). =20 Version 03 should include only minor changes to the data escrow specificati= on. =20 If you are attending the IETF 86 meeting and want to talk about data escrow= , please send me an email and we can arrange an informal meeting. =20 Regards, Gustavo Lozano _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire From fobispo@isc.org Tue Mar 12 19:47:11 2013 Return-Path: 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 84BFE11E8113 for ; Tue, 12 Mar 2013 19:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396] 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 mjFu9ry+v46Z for ; Tue, 12 Mar 2013 19:47:09 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AA52A21F8596 for ; Tue, 12 Mar 2013 19:47:09 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A31BCC9518; Wed, 13 Mar 2013 02:46:58 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363142829; bh=/M9IxAiCVLHXCFDMDAg3WLr3ELcgfpNiUWo82N6DwBM=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=LTjmwJOv/8nYSLV61nX6pk539BT0M84hFIlf2YLtzBC845KeNOkSqPjveuJalIQ8o cWKH5jKnxf/Wyj4Rs27dqfBOAaLRBwtVOPsEVVTiZKAeBtNcvMTy1IX8ZTJbM2SAnU 0u32QdYGEA5G9FmsAATIULOE6SdWluCtRMVHF/M8= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 13 Mar 2013 02:46:58 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [10.153.104.35] (mobile-166-137-214-174.mycingular.net [166.137.214.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CA8C4216C40; Wed, 13 Mar 2013 02:46:57 +0000 (UTC) (envelope-from fobispo@isc.org) References: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local> Mime-Version: 1.0 (1.0) In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: Francisco Obispo Date: Tue, 12 Mar 2013 19:46:52 -0700 To: Chris Wright X-DCC--Metrics: post.isc.org; whitelist Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 02:47:11 -0000 Or just simply xml! I've done my testing and the resulting compressed xml files are similar if n= ot smaller than the csv alternative Sent from my iPhone On Mar 12, 2013, at 5:35 PM, Chris Wright wrote: > Thanks Gustavo, >=20 > We are still a little unsure as to why it is XML + CSV, and not just simpl= y CSV? >=20 > The choices should be XML or CSV.. >=20 > Thanks >=20 > Chris >=20 >=20 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of Gust= avo Lozano > Sent: Wednesday, 13 March 2013 1:55 AM > To: ire@ietf.org > Subject: [ire] New versions of data escrow drafts >=20 > Colleagues, >=20 >=20 > Two new versions of the data escrow drafts have been > published: > * http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt > * http://www.ietf.org/id/draft-arias-noguchi-registry-data-escrow-05.txt >=20 >=20 > These drafts incorporate feedback received in this list and private emails= . >=20 >=20 > The authors of draft-arias-noguchi-dnrd-objects-mapping and draft-gould-th= ippeswamy-dnrd-csv-mapping agreed to merge both drafts to create a single sp= ecification that supports XML only and XML+CSV. >=20 >=20 > The data elements/objects in both drafts have been normalized. >=20 >=20 > The authors of draft-gould-thippeswamy-dnrd-csv-mapping will publish a new= version of the CSV draft before the merge of both drafts. >=20 >=20 > The new version (03) of the draft draft-arias-noguchi-dnrd-objects-mapping= > is going to include both models (XML only and XML+CSV). >=20 >=20 > Version 03 should include only minor changes to the data escrow specificat= ion. >=20 >=20 > If you are attending the IETF 86 meeting and want to talk about data escro= w, please send me an email and we can arrange an informal meeting. >=20 >=20 > Regards, > Gustavo Lozano >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire From wil@cloudregistry.net Tue Mar 12 20:21:53 2013 Return-Path: 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 0D7EA11E8111 for ; Tue, 12 Mar 2013 20:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 cjysNLwpo79Q for ; Tue, 12 Mar 2013 20:21:52 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7917B11E80FC for ; Tue, 12 Mar 2013 20:21:52 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id k38so541960iah.19 for ; Tue, 12 Mar 2013 20:21: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:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=/StIa98csYDaMgfzBhMYs98zdpG5ZRbbfohKr8o/DWI=; b=cFLeyEGDKxfMN1f5BaH0CDCWyioxlbYd69vyNor01uI19aLbuHj712h8yMobhB7aPB SzUuXxyZrVldFrnU+9pZfBTqwXkxyjKw5W4VSRs0hH24TN2/cZH4sGAgTl1/DNbxTOqB qDqP+FTORVBA9KjbG8fa4MP77UXZYlld3AnDAfCzrzVROuIwh9mlqy3+YKTssoC9O4Qp ZhYWPvuP6m6N4sSo25d9EvLELM814hBAJe63pIXSlEk9g3YHlUhz3lfD88fYGxrN+kNQ Xcf0BnbhqeMr7+CrlJPhUA4upVRzzH7wrMQ4P6JQ31sNzDp8Pp0VuJpB/qea0omHgKyO whXg== X-Received: by 10.50.73.133 with SMTP id l5mr14428841igv.108.1363144912074; Tue, 12 Mar 2013 20:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.170.170 with HTTP; Tue, 12 Mar 2013 20:21:11 -0700 (PDT) In-Reply-To: References: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local> From: Wil Tan Date: Wed, 13 Mar 2013 14:21:11 +1100 Message-ID: To: Francisco Obispo Content-Type: multipart/alternative; boundary=089e0129483a431df404d7c5e86e X-Gm-Message-State: ALoCoQlgPmtbyEdl1UuxrtS9RFfTKFwasXY/aEcpXT2GOgCYngFpenKwOL/f3R2CmCikrKenIiM6 Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 03:21:53 -0000 --089e0129483a431df404d7c5e86e Content-Type: text/plain; charset=UTF-8 On Wed, Mar 13, 2013 at 1:46 PM, Francisco Obispo wrote: > Or just simply xml! > > I've done my testing and the resulting compressed xml files are similar if > not smaller than the csv alternative > Did you test compressed xml against plain or compressed csv? .wil --089e0129483a431df404d7c5e86e Content-Type: text/html; charset=UTF-8

On Wed, Mar 13, 2013 at 1:46 PM, Francisco Obispo <fobispo@isc.org> wrote:
Or just simply xml!

I've done my testing and the resulting compressed xml files are similar if not smaller than the csv alternative

Did you test compressed xml against plain or compressed csv?

.wil
--089e0129483a431df404d7c5e86e-- From fobispo@isc.org Tue Mar 12 20:23:59 2013 Return-Path: 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 4218911E8113 for ; Tue, 12 Mar 2013 20:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 qspAO5selPwj for ; Tue, 12 Mar 2013 20:23:58 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5C00511E80F9 for ; Tue, 12 Mar 2013 20:23:58 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4AF7E5F9891; Wed, 13 Mar 2013 03:23:48 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363145037; bh=weIkzEOLsvRbocDxU4j2njABdmDmXCyCYte9D+cALpE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=as3wakHjCz3ch+CclpBC7Lu/f/MfXJ3/s4dDvUftm5cZ+zOOYeDP/5a7XaTwwkSPR RTz1LYBC61ueti54YHUj3+xgYzJwa281KOLKF88sBNixLr84cag6x6aPZMxd1Re5yh 5ESr/uS1EZ/jKg6rNqgSK+QSyo2KgiRoVZ2jl5oo= Received: from [IPv6:2001:470:1f05:1326:5806:f2e:885:904f] (unknown [IPv6:2001:470:1f05:1326:5806:f2e:885:904f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C2130216C3B; Wed, 13 Mar 2013 03:23:46 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: Date: Tue, 12 Mar 2013 20:23:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4840545C-DD20-445E-AA1B-C0EAA1B35048@isc.org> References: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local> To: Wil Tan X-Mailer: Apple Mail (2.1499) Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 03:23:59 -0000 Yes, of course. I loaded 400k domains into my database, exported using both formats, = compressed both results with bz2, the end files ended up being about = 10MB. (over 300MB compressed). On Mar 12, 2013, at 8:21 PM, Wil Tan wrote: >=20 > On Wed, Mar 13, 2013 at 1:46 PM, Francisco Obispo = wrote: > Or just simply xml! >=20 > I've done my testing and the resulting compressed xml files are = similar if not smaller than the csv alternative >=20 > Did you test compressed xml against plain or compressed csv? >=20 > .wil Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From fobispo@isc.org Tue Mar 12 20:31:00 2013 Return-Path: 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 6317011E80D1 for ; Tue, 12 Mar 2013 20:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] 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 r8PadmoJXDGS for ; Tue, 12 Mar 2013 20:30:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7911E80FE for ; Tue, 12 Mar 2013 20:30:58 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id EE3CDC9428; Wed, 13 Mar 2013 03:30:53 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363145458; bh=0oyy4pNG7Xbm11q6zOmDJZDFI2gqxnqoOsDux8dzY74=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=oHDPkNYMc0WmCMe3ujnKSxip+g3FTgxpNsakgyL7Pj9NCQHbTY+5jnzmE7Y9q9zeH EtVAOpaAJiZPuz3y4yBn54VSLPSO8RQOt/31EqcBm8l1F5/2+54jSkqx912mTDv9T8 KAJAYUoB+UNvktwkcOqU/y4GNZ+rPoMxHaBdE9XQ= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 13 Mar 2013 03:30:53 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:470:1f05:1326:5806:f2e:885:904f] (unknown [IPv6:2001:470:1f05:1326:5806:f2e:885:904f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C2CDC216C3B; Wed, 13 Mar 2013 03:30:53 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <4840545C-DD20-445E-AA1B-C0EAA1B35048@isc.org> Date: Tue, 12 Mar 2013 20:30:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF50CF9-50E6-4550-8523-96C4A5EE2D20@isc.org> References: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local> <4840545C-DD20-445E-AA1B-C0EAA1B35048@isc.org> To: Wil Tan X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 03:31:00 -0000 300 MB uncompressed I meant. On Mar 12, 2013, at 8:23 PM, Francisco Obispo wrote: > Yes, of course. >=20 > I loaded 400k domains into my database, exported using both formats, = compressed both results with bz2, the end files ended up being about = 10MB. (over 300MB compressed). Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From JGould@verisign.com Wed Mar 13 05:12:02 2013 Return-Path: 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 1EE6321F8D11 for ; Wed, 13 Mar 2013 05:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, 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 SqCscrPGUR1k for ; Wed, 13 Mar 2013 05:12:00 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1628221F8D87 for ; Wed, 13 Mar 2013 05:11:56 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUUBtDEWgI/igVmaLj9H4IjWFMTaXQW/r@postini.com; Wed, 13 Mar 2013 05:12:00 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2DCBoge005185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 08:11:53 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 08:11:50 -0400 From: "Gould, James" To: Francisco Obispo , Wil Tan Thread-Topic: [ire] New versions of data escrow drafts Thread-Index: Ac4fMYocS0NoaqyiSYW/Y095rpHTkQAUP2ZAAA0A3gAAATLRgAAAF4uAAAA/oQAACc5AAA== Date: Wed, 13 Mar 2013 12:11:49 +0000 Message-ID: In-Reply-To: <5BF50CF9-50E6-4550-8523-96C4A5EE2D20@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 12:12:02 -0000 Francisco, I had done some testing a while back that showed that the XML is much larger uncompressed and is larger compressed. Compression does a great job with XML, so the variance is not huge after compression. The compressed size is not the only factor in deciding between XML and CSV. I believe that we've debated this at length on prior postings, where the goal now is to merge the drafts into a single draft that supports both models with a common set of objects and object attributes. --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/12/13 11:30 PM, "Francisco Obispo" wrote: >300 MB uncompressed I meant. > >On Mar 12, 2013, at 8:23 PM, Francisco Obispo wrote: > >> Yes, of course. >>=20 >> I loaded 400k domains into my database, exported using both formats, >>compressed both results with bz2, the end files ended up being about >>10MB. (over 300MB compressed). > >Francisco Obispo=20 >Director of Applications and Services - ISC >email: fobispo@isc.org >Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >PGP KeyID =3D B38DB1BE > >_______________________________________________ >ire mailing list >ire@ietf.org >https://www.ietf.org/mailman/listinfo/ire From gustavo.lozano@icann.org Wed Mar 13 06:14:46 2013 Return-Path: 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 2A3E921F8935 for ; Wed, 13 Mar 2013 06:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 g48w3OrFZ10i for ; Wed, 13 Mar 2013 06:14:45 -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 9EA6021F87D3 for ; Wed, 13 Mar 2013 06:14:45 -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; Wed, 13 Mar 2013 06:14:44 -0700 From: Gustavo Lozano To: Chris Wright , "ire@ietf.org" Date: Wed, 13 Mar 2013 06:14:47 -0700 Thread-Topic: New versions of data escrow drafts Thread-Index: Ac4f7Lo7NKlfpLEqTF+zdTKMuOAPGA== Message-ID: In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 13:14:46 -0000 Thanks Chris, It's possible that for some objects there may not be a mapping for CSV (e.g. EPP parameters, IDN practices, header object). We (authors of both drafts) have not yet made a decission about this. We just want to leave the door open for the scenario of a data escrow deposit with some objects in CSV and others in XML. Regards, Gustavo On 3/12/13 5:35 PM, "Chris Wright" wrote: >Thanks Gustavo, > >We are still a little unsure as to why it is XML + CSV, and not just >simply CSV? > >The choices should be XML or CSV.. > >Thanks > >Chris > > >-----Original Message----- >From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of >Gustavo Lozano >Sent: Wednesday, 13 March 2013 1:55 AM >To: ire@ietf.org >Subject: [ire] New versions of data escrow drafts > >Colleagues, > >=20 >Two new versions of the data escrow drafts have been >published: >* http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt >* http://www.ietf.org/id/draft-arias-noguchi-registry-data-escrow-05.txt >=20 > >These drafts incorporate feedback received in this list and private >emails. >=20 > >The authors of draft-arias-noguchi-dnrd-objects-mapping and >draft-gould-thippeswamy-dnrd-csv-mapping agreed to merge both drafts to >create a single specification that supports XML only and XML+CSV. >=20 > >The data elements/objects in both drafts have been normalized. >=20 > >The authors of draft-gould-thippeswamy-dnrd-csv-mapping will publish a >new version of the CSV draft before the merge of both drafts. >=20 > >The new version (03) of the draft draft-arias-noguchi-dnrd-objects-mapping >is going to include both models (XML only and XML+CSV). >=20 > >Version 03 should include only minor changes to the data escrow >specification. >=20 > >If you are attending the IETF 86 meeting and want to talk about data >escrow, please send me an email and we can arrange an informal meeting. >=20 > >Regards, >Gustavo Lozano > >_______________________________________________ >ire mailing list >ire@ietf.org >https://www.ietf.org/mailman/listinfo/ire From JGould@verisign.com Wed Mar 13 06:18:23 2013 Return-Path: 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 6317221F8A43 for ; Wed, 13 Mar 2013 06:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 h4xnHMN8zDSL for ; Wed, 13 Mar 2013 06:18:21 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 98EB021F8D11 for ; Wed, 13 Mar 2013 06:17:45 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUUB8eWHDPbpOBdAVRb7AERUqzRm+RIqs@postini.com; Wed, 13 Mar 2013 06:18:11 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2DDHixU031038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 09:17:44 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 09:17:44 -0400 From: "Gould, James" To: Gustavo Lozano , "chris@ausregistry.com.au" , "ire@ietf.org" Thread-Topic: New versions of data escrow drafts Thread-Index: Ac4fMYocS0NoaqyiSYW/Y095rpHTkQAUP2ZAACLu4oD//70+5g== Date: Wed, 13 Mar 2013 13:17:43 +0000 Message-ID: References: <8CEF048B9EC83748B1517DC64EA130FB76EE44B69C@off-win2003-01.ausregistrygroup.local>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 13:18:24 -0000 That is correct. Objects that are mainly static content like the EPP param= eters can be represented in the XML definition file. =0A= =0A= Jim=0A= ________________________________________=0A= From: ire-bounces@ietf.org [ire-bounces@ietf.org] on behalf of Gustavo Loza= no [gustavo.lozano@icann.org]=0A= Sent: Wednesday, March 13, 2013 9:14 AM=0A= To: chris@ausregistry.com.au; ire@ietf.org=0A= Subject: Re: [ire] New versions of data escrow drafts=0A= =0A= Thanks Chris,=0A= =0A= It's possible that for some objects there may not be a mapping for CSV=0A= (e.g. EPP parameters, IDN practices, header object). We (authors of both=0A= drafts) have not yet made a decission about this.=0A= =0A= We just want to leave the door open for the scenario of a data escrow=0A= deposit with some objects in CSV and others in XML.=0A= =0A= Regards,=0A= =0A= Gustavo=0A= =0A= =0A= On 3/12/13 5:35 PM, "Chris Wright" wrote:=0A= =0A= >Thanks Gustavo,=0A= >=0A= >We are still a little unsure as to why it is XML + CSV, and not just=0A= >simply CSV?=0A= >=0A= >The choices should be XML or CSV..=0A= >=0A= >Thanks=0A= >=0A= >Chris=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of=0A= >Gustavo Lozano=0A= >Sent: Wednesday, 13 March 2013 1:55 AM=0A= >To: ire@ietf.org=0A= >Subject: [ire] New versions of data escrow drafts=0A= >=0A= >Colleagues,=0A= >=0A= >=0A= >Two new versions of the data escrow drafts have been=0A= >published:=0A= >* http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt= =0A= >* http://www.ietf.org/id/draft-arias-noguchi-registry-data-escrow-05.txt= =0A= >=0A= >=0A= >These drafts incorporate feedback received in this list and private=0A= >emails.=0A= >=0A= >=0A= >The authors of draft-arias-noguchi-dnrd-objects-mapping and=0A= >draft-gould-thippeswamy-dnrd-csv-mapping agreed to merge both drafts to=0A= >create a single specification that supports XML only and XML+CSV.=0A= >=0A= >=0A= >The data elements/objects in both drafts have been normalized.=0A= >=0A= >=0A= >The authors of draft-gould-thippeswamy-dnrd-csv-mapping will publish a=0A= >new version of the CSV draft before the merge of both drafts.=0A= >=0A= >=0A= >The new version (03) of the draft draft-arias-noguchi-dnrd-objects-mapping= =0A= >is going to include both models (XML only and XML+CSV).=0A= >=0A= >=0A= >Version 03 should include only minor changes to the data escrow=0A= >specification.=0A= >=0A= >=0A= >If you are attending the IETF 86 meeting and want to talk about data=0A= >escrow, please send me an email and we can arrange an informal meeting.=0A= >=0A= >=0A= >Regards,=0A= >Gustavo Lozano=0A= >=0A= >_______________________________________________=0A= >ire mailing list=0A= >ire@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/ire=0A= =0A= _______________________________________________=0A= ire mailing list=0A= ire@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ire=0A= From gustavo.lozano@icann.org Wed Mar 13 06:52:29 2013 Return-Path: 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 BFDE221F8D42 for ; Wed, 13 Mar 2013 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 dcGMKQM0UOYa for ; Wed, 13 Mar 2013 06:52:29 -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 3CFB921F8D41 for ; Wed, 13 Mar 2013 06:52:29 -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; Wed, 13 Mar 2013 06:52:28 -0700 From: Gustavo Lozano To: "ire@ietf.org" Date: Wed, 13 Mar 2013 06:52:27 -0700 Thread-Topic: Data escrow deposit validation tool Thread-Index: Ac4f8f/wCW8g8+qiQviFQ/ZRkBb7OA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD65D2ABCD0Egustavolozanoicannorg_" MIME-Version: 1.0 Subject: [ire] Data escrow deposit validation tool X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 13:52:29 -0000 --_000_CD65D2ABCD0Egustavolozanoicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues, The Internet Draft: http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects= -mapping-02.txt, describes a "Data escrow agent extended verification" proc= ess. The data escrow deposits are valuable if they can be used when needed, basi= cally during an emergency. The creation of an open source data escrow deposit validation tool is an im= portant step to mitigate risks related to the quality of the escrow deposit= . This tool could be used by data escrow agents, registries and EBEROs. Who is interested in participating in the development of such a tool? Basically, the tool should receive as input a full and optionally several d= ifferential deposits. After applying the deltas the tool should perform the= tests listed in the draft. The tool should be able to handle deposits of a= t least several millions of objects. Regards, Gustavo --_000_CD65D2ABCD0Egustavolozanoicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Colleagues,

The Internet Draft: http://www.ietf.org/id/draft-arias-no= guchi-dnrd-objects-mapping-02.txt, describes a "Data escrow agent extended = verification" process.

The data escrow deposits ar= e valuable if they can be used when needed, basically during an emergency.<= /div>

The creation of an open source data escrow deposit= validation tool is an important step to mitigate risks related to the qual= ity of the escrow deposit. This tool could be used by data escrow agents, r= egistries and EBEROs.

Who is interested in partici= pating in the development of such a tool?

Basicall= y, the tool should receive as input a full and optionally several different= ial deposits. After applying the deltas the tool should perform the tests l= isted in the draft. The tool should be able to handle deposits of at least = several millions of objects.

Regards,
Gu= stavo
--_000_CD65D2ABCD0Egustavolozanoicannorg_-- From JGould@verisign.com Wed Mar 13 14:36:20 2013 Return-Path: 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 34AAC11E80C5 for ; Wed, 13 Mar 2013 14:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 w4vmCyVX6Oz7 for ; Wed, 13 Mar 2013 14:36:19 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 825E421F8A98 for ; Wed, 13 Mar 2013 14:35:58 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUUDxPX4iLRXYuW9Egn/RS3VMI2iEoIwI@postini.com; Wed, 13 Mar 2013 14:36:19 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2DLZspo015831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 17:35:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 17:35:53 -0400 From: "Gould, James" To: Gustavo Lozano , "ire@ietf.org" Thread-Topic: [ire] Data escrow deposit validation tool Thread-Index: Ac4f8f/wCW8g8+qiQviFQ/ZRkBb7OAAQLSeA Date: Wed, 13 Mar 2013 21:35:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CD6612C64ADF7jgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [ire] Data escrow deposit validation tool X-BeenThere: ire@ietf.org 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: Wed, 13 Mar 2013 21:36:20 -0000 --_004_CD6612C64ADF7jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CD6612C64ADF7jgouldverisigncom_" --_000_CD6612C64ADF7jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gustavo, The "Data escrow agent extended verification" fundamentally changes the res= ponsibilities of a data escrow provider, which can and will increase the co= st of the data escrow. Data escrow providers today are responsible for ens= uring the completeness of the deposits and for storing them. They have no = idea of the data content including its syntactic and semantic structure. R= ight now the extended validation process is optional in the draft, but if a= nd when it becomes a requirement for the data escrow providers, it would ne= ed to be vetted out by the broader community. If extended validation does become a requirement, then a standardized open = source tool is a good idea and is a minimum requirement to ensure that all= data escrow providers execute the same validation. We may be able to cont= ribute to this effort. Thanks, -- JG [cid:195536F0-7E46-44B2-88AE-82E8B9FEB1E2] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano > Date: Wednesday, March 13, 2013 9:52 AM To: "ire@ietf.org" > Subject: [ire] Data escrow deposit validation tool Colleagues, The Internet Draft: http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects= -mapping-02.txt, describes a "Data escrow agent extended verification" proc= ess. The data escrow deposits are valuable if they can be used when needed, basi= cally during an emergency. The creation of an open source data escrow deposit validation tool is an im= portant step to mitigate risks related to the quality of the escrow deposit= . This tool could be used by data escrow agents, registries and EBEROs. Who is interested in participating in the development of such a tool? Basically, the tool should receive as input a full and optionally several d= ifferential deposits. After applying the deltas the tool should perform the= tests listed in the draft. The tool should be able to handle deposits of a= t least several millions of objects. Regards, Gustavo --_000_CD6612C64ADF7jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <648DEE800AD77F4EB26267687B86BAE9@verisign.com> Content-Transfer-Encoding: quoted-printable
Gustavo,

The "Data escrow agent extended verification" fundamentally = changes the responsibilities of a data escrow provider, which can and will = increase the cost of the data escrow.  Data escrow providers today are= responsible for ensuring the completeness of the deposits and for storing them.  They have no idea of the data content= including its syntactic and semantic structure.  Right now the extend= ed validation process is optional in the draft, but if and when it becomes = a requirement for the data escrow providers, it would need to be vetted out by the broader community.  

If extended validation does become a requirement, then a standardized = open source tool is a good idea and is  a minimum requirement to ensur= e that all data escrow providers execute the same validation.  We may = be able to contribute to this effort.  

Thanks,

-- 

 

JG

 

 

James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

VerisignInc.com


From: Gustavo Lozano <gustavo.lozano@icann.org>
Date: Wednesday, March 13, 2013 9:5= 2 AM
To: "ire@ietf.org" <ire@ietf.= org>
Subject: [ire] Data escrow deposit = validation tool

Colleagues,

The Internet Draft: http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt,= describes a "Data escrow agent extended verification" process.

The data escrow deposits are valuable if they can be used when needed,= basically during an emergency.

The creation of an open source data escrow deposit validation tool is = an important step to mitigate risks related to the quality of the escrow de= posit. This tool could be used by data escrow agents, registries and EBEROs= .

Who is interested in participating in the development of such a tool?<= /div>

Basically, the tool should receive as input a full and optionally seve= ral differential deposits. After applying the deltas the tool should perfor= m the tests listed in the draft. The tool should be able to handle deposits= of at least several millions of objects.

Regards,
Gustavo
--_000_CD6612C64ADF7jgouldverisigncom_-- --_004_CD6612C64ADF7jgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png"; size=4109; creation-date="Wed, 13 Mar 2013 21:35:53 GMT"; modification-date="Wed, 13 Mar 2013 21:35:53 GMT" Content-ID: <195536F0-7E46-44B2-88AE-82E8B9FEB1E2> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CD6612C64ADF7jgouldverisigncom_-- From JGould@verisign.com Thu Mar 14 05:34:08 2013 Return-Path: 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 0B95021F8E57 for ; Thu, 14 Mar 2013 05:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Q5ME4E+YvETB for ; Thu, 14 Mar 2013 05:34:04 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9802A21F8DCB for ; Thu, 14 Mar 2013 05:33:55 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUUHDs9GRsi+7GnsWqh2zwOIHJ/NB4ERe@postini.com; Thu, 14 Mar 2013 05:34:03 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2ECXqKp018241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 08:33:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 08:33:52 -0400 From: "Gould, James" To: "ire@ietf.org" Thread-Topic: DNRD CSV 02 Draft Thread-Index: AQHOILAu2skodHbwiEGWEbWJraAaSg== Date: Thu, 14 Mar 2013 12:33:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_004_CD67399F4AFA3jgouldverisigncom_" MIME-Version: 1.0 Cc: "Thippeswamy, Chethan" Subject: [ire] DNRD CSV 02 Draft X-BeenThere: ire@ietf.org 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, 14 Mar 2013 12:34:08 -0000 --_004_CD67399F4AFA3jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CD67399F4AFA3jgouldverisigncom_" --_000_CD67399F4AFA3jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The Domain Name Registration Data (DNRD) Comma-Separated Values (CSV) Objec= ts Mapping 02 draft has been created that primarily syncs up with draft-ari= as-noguchi-dnrd-objects for the merge of the drafts. The full list of chan= ges are below: 1. Replaced the field with the , , and fields, since there is no eppcom:s= tatusType element, but there is a domain:statusValueType, host:statusValueT= ype, and contact:statusValueType types. 2. Fixed reference of XSD datatime to dateTime in the rdeCsv:fDatetimeTy= pe field, that was renamed to the rdeCsv:fDataTimeType field. 3. Fixed reference to XSD unsignedbyte to unsignedByte in the rdeCsv:fUn= signedByteType field. 4. Fixed some of the CSV sample data. 5. Removed , , and fields to sync up with draft-arias-noguchi-dnrd-objects. 6. Added and fields to sync up with draft-= arias-noguchi-dnrd-objects. 7. Removed use of and from "registrar" to = sync up with draft-arias-noguchi-dnrd-objects. 8. Removed and to sync up wit= h draft-arias-noguchi-dnrd-objects. 9. Removed the "registrarContacts" object, the field, the field, the to sync up with draft-arias-noguchi-dnrd-= objects. 10. Added the and fields to sync up with dr= aft-arias-noguchi-dnrd-objects. 11. Removed the and fields, and re= moved reference to of the "host" object. 12. Changed the enumerated list to include only "o= k", "readonly", and "terminated" to sync up with draft-arias-noguchi-dnrd-o= bject. Also removed support for the field. 13. Updated the description of the "Registrar Object" to include an organ= ization for clients that create and update objects, including the registry. 14. Added definition of the "isRequired" boolean field attribute to indic= ate whether a field must be non-empty in the CSV file. The 02 draft is available below for feedback: http://www.ietf.org/internet-drafts/draft-gould-thippeswamy-dnrd-csv-mappin= g-02.txt http://tools.ietf.org/html/draft-gould-thippeswamy-dnrd-csv-mapping-02 Thanks, -- JG [cid:D53BB67F-0D37-41F7-BE9A-73A4F307DB92] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com --_000_CD67399F4AFA3jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8D621A439F5B1D4498FFED4764797BB6@verisign.com> Content-Transfer-Encoding: quoted-printable
All,

The Domain Name Registration Data= (DNRD) Comma-Separated Values (CSV) Objects Mapping 02 draft has been crea= ted that primarily syncs up with draft-arias-noguchi-dnrd-objects for the merge of the drafts.  The full list of changes are bel= ow:

  1. Replaced the <rdeCsv:fStatus> field with the <csvDomain:fStatu= s>, <csvHost:fStatus>, and <csvContact:fStatus> fields, sinc= e there is no eppcom:statusType element, but there is a domain:statusValueT= ype, host:statusValueType, and contact:statusValueType types.
  2. Fixed= reference of XSD datatime to dateTime in the rdeCsv:fDatetimeType field, t= hat was renamed to the rdeCsv:fDataTimeType field.
  3. Fixed reference = to XSD unsignedbyte to unsignedByte in the rdeCsv:fUnsignedByteType field.<= /li>
  4. Fixed some of the CSV sample data.
  5. Removed <csvDomain:fI= dn>, <csvDomain:fVariant>, and <csvDomain:fReserved> fields = to sync up with draft-arias-noguchi-dnrd-objects.
  6. Added <rdeCsv:= fCrRr> and <rdeCsv:fUpRr> fields to sync up with draft-arias-noguc= hi-dnrd-objects.
  7. Removed use of <rdeCsv:fCrID> and <rdeCsv= :fUpID> from "registrar" to sync up with draft-arias-noguchi-d= nrd-objects.
  8. Removed <domain:fPwAuthInfo> and <contact:fPw= AuthInfo> to sync up with draft-arias-noguchi-dnrd-objects.
  9. Remo= ved the "registrarContacts" <rdeCsv:csv> object, the <cs= vContact:fIsRegistrarContact> field, the <csvRegistrar:fContactType&g= t; field, the <csvRegistrar:fCustomContactTypeName> to sync up with d= raft-arias-noguchi-dnrd-objects.
  10. Added the <rdeCsv:fReRr> and= <rdeCsv:fAcRr> fields to sync up with draft-arias-noguchi-dnrd-objec= ts.
  11. Removed the <csvHost:fParentDomain> and <csvHost:fIdn&= gt; fields, and removed reference to <rdeCsv:fUName> of the "hos= t" object.
  12. Changed the <csvRegistrar:fStatus> enumerated= list to include only "ok", "readonly", and "termi= nated" to sync up with draft-arias-noguchi-dnrd-object. Also removed s= upport for the <csvRegistrar:fStatusName> field.
  13. Updated the = description of the "Registrar Object" to include an organization = for clients that create and update objects, including the registry.
    14. Added definition of the "isRequired" boolean field attribute to = indicate whether a field must be non-empty in the CSV file.
The 02 draft is available below for feedback:


Thanks,


--

  

JG<= /p>

 

 

James Gould

Principal Software Engineer

jgould@verisign.= com=

 

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

=

--_000_CD67399F4AFA3jgouldverisigncom_-- --_004_CD67399F4AFA3jgouldverisigncom_ Content-Type: image/png; name="86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[18].png" Content-Description: 86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[18].png Content-Disposition: attachment; filename="86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[18].png"; size=4109; creation-date="Thu, 14 Mar 2013 12:33:51 GMT"; modification-date="Thu, 14 Mar 2013 12:33:51 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CD67399F4AFA3jgouldverisigncom_-- From david.kipling@nccgroup.com Fri Mar 15 03:21:15 2013 Return-Path: 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 193D221F8C22 for ; Fri, 15 Mar 2013 03:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=1.496, RCVD_IN_DNSWL_LOW=-1] 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 YGKJ1KGwRGjt for ; Fri, 15 Mar 2013 03:21:13 -0700 (PDT) Received: from service141.mimecast.com (service141.mimecast.com [91.220.42.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5330721F8B9C for ; Fri, 15 Mar 2013 03:21:10 -0700 (PDT) Received: from keyserver.nccgroup.com (keyserver.nccgroup.com [195.95.131.32]) (Using TLS) by service141.mimecast.com; Fri, 15 Mar 2013 10:21:09 +0000 Received: from manexchprd02.nccgroup.local ([172.20.1.93]) by keyserver.nccgroup.com (PGP Universal service); Fri, 15 Mar 2013 10:21:09 +0000 X-PGP-Universal: processed; by keyserver.nccgroup.com on Fri, 15 Mar 2013 10:21:09 +0000 Received: from MANEXCHPRD01.nccgroup.local ([172.20.1.92]) by manexchprd02 ([172.20.1.93]) with mapi id 14.01.0438.000; Fri, 15 Mar 2013 10:21:08 +0000 From: David Kipling To: "gustavo.lozano@icann.org" , "ire@ietf.org" Thread-Topic: Extended Verification Process Thread-Index: Ac4hZpPe4wqkSPI1Rcq+cOj1nTrJAg== Date: Fri, 15 Mar 2013 10:21:08 +0000 Message-ID: <31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DF@manexchprd01> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.5.228] signature: OK MIME-Version: 1.0 X-MC-Unique: 113031510210908901 Content-Type: multipart/alternative; boundary="_000_31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DFmanexchprd01_" Subject: [ire] Extended Verification Process X-BeenThere: ire@ietf.org 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: Fri, 15 Mar 2013 10:21:15 -0000 --_000_31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DFmanexchprd01_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Gustavo, At NCC Group we are working on the extended verification process and have n= oted a query around the RDE policy rule. The element allows you to specify= required fields such as "" as required. The issue I have with this is that the scope of the elemen= t needs to be known to be able to perform the check e.g. is it : * one registrant per deposit? * one registrant per domain record? * one registrant per postalInfo element in each contact record? You have the namespace, though I would suggest to be clear that the policy = element is altered to include the scope of the parent element as an XPath q= uery: "" "" What are your thoughts? Regards David Kipling 1. I have some really easy XPath queries etc. setup to handle the exte= nded validation though my issue is with the CSV files. Looks like I'm goin= g to have to build a module to load all the csv elements into the same XML = file for me to process. It's a shame it isn't just XML as the process woul= d be a lot easier including the Open Source Tool. Regards David ________________________________ David Kipling IT Service Desk Analyst NCC Group Manchester Technology Centre, Oxford Road Manchester, M1 7EF Telephone: +44 161 209 5430 Mobile: Fax: Website: www.nccgroup.com Email: David.Kipling@nccgroup.com [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] ________________________________ This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4= 627044). Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then d= elete the original. If you are not the intended recipient you may not use, = disclose, distribute, copy, print or rely on any information contained in t= his e-mail. You must not inform any other person other than NCC Group or th= e sender of its existence. For more information about NCC Group please visit www.nccgroup.com P Before you print think about the ENVIRONMENT For more information please visit http:= //www.mimecast.com
This email message has been delivered safely and archived online by Mimecas= t. --_000_31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DFmanexchprd01_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Gustavo,

 

At NCC Group we are working on the exten= ded verification process and have noted a query around the RDE policy rule.=   The element allows you to specify required fields such as “<rdePolicy:policy element=3D"rdeDom:registrant" /= >” as required.  The issue I have with thi= s is that the scope of the element needs to be known to be able to perform the check e.g. is it :

&nbs= p;

·     &= nbsp;  one registrant per deposit?

·     &= nbsp;  one registrant per domain record?

·     &= nbsp;  one registrant per postalInfo element in e= ach contact record?

&nbs= p;

You have the namespace, though I would s= uggest to be clear that the policy element is altered to include the scope = of the parent element as an XPath query:

 

“<rdePolicy:policy scope=3D”{XPath query}” element=3D"{qualified eleme= nt name}" />”

“<rdePolicy:policy scope=3D”//rde:deposit/rde:contents/rdeDomain:domain” el= ement=3D"rdeDomain:registrant" />”

 

What are your thoughts?

 

Regards

 

David Kipling

 

 

 

 

 

 

1.&nbs= p;     I have some really easy XPath queries etc.= setup to handle the extended validation though my issue is with the CSV fi= les.  Looks like I’m going to have to build a module to load all the csv elements into the same XML file for me to process.  = It’s a shame it isn’t just XML as the process would be a lot ea= sier including the Open Source Tool.

 

Regards

 

David

David Kipling
IT Service Desk Analyst
NCC Group
Manchester Technology Centre, Oxford Road
Manchester, M1 7EF

Telephone: +44 161 209 5430
Mobile:
Fax:
Website: www.nccgroup.com
Email:  David.Kipling@nccgroup.com

This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4627044).

Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then delete the original. If you are not th= e intended recipient you may not use, disclose, distribute, copy, print or = rely on any information contained in this e-mail. You must not inform any o= ther person other than NCC Group or the sender of its existence.

For more information about NCC Group please visit www.nccgroup.com

P Before you print think about the ENVIRONMENT


--_000_31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DFmanexchprd01_-- From james.mitchell@ausregistry.com.au Sat Mar 16 07:39:42 2013 Return-Path: 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 656DE21F89A5 for ; Sat, 16 Mar 2013 07:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 VFfF6iRZOXnY for ; Sat, 16 Mar 2013 07:39:41 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87E21F899E for ; Sat, 16 Mar 2013 07:39:36 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 17 Mar 2013 01:39:34 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Sun, 17 Mar 2013 01:39:24 +1100 From: James Mitchell To: David Kipling , "gustavo.lozano@icann.org" , "ire@ietf.org" Date: Sun, 17 Mar 2013 01:39:28 +1100 Thread-Topic: [ire] Extended Verification Process Thread-Index: Ac4iVA1gD8CXTJayR7C/G9qJy/tpXQ== Message-ID: In-Reply-To: <31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DF@manexchprd01> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD6ABFF5654F1jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: Re: [ire] Extended Verification Process X-BeenThere: ire@ietf.org 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: Sat, 16 Mar 2013 14:39:42 -0000 --_000_CD6ABFF5654F1jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Worried. Are we going to assume that every validator has to map the prefixes rde and= rdeDomain to "urn:ietf:params:xml:ns:rde-1.0" and "urn:ietf:params:xml:ns:= rdeDomain-1.0" respectively? What happens when I use namespace prefixes oth= er than those used in the examples (e.g. bind rde to default and rdeDomain = to "d")? I assume that I would not change the Xpath query because I would g= uess that I would break validator implementations=85 I note also the inconsistent use of namespace prefixes for the RDE Domain n= amespace, with the document referring to both rdeDom and rdeDomain. Regards, James From: David Kipling > Date: Friday, 15 March 2013 9:21 PM To: "gustavo.lozano@icann.org" >, "ire@ietf.org" > Subject: [ire] Extended Verification Process Hi Gustavo, At NCC Group we are working on the extended verification process and have n= oted a query around the RDE policy rule. The element allows you to specify= required fields such as =93=94 as required. The issue I have with this is that the scope of the el= ement needs to be known to be able to perform the check e.g. is it : =B7 one registrant per deposit? =B7 one registrant per domain record? =B7 one registrant per postalInfo element in each contact record? You have the namespace, though I would suggest to be clear that the policy = element is altered to include the scope of the parent element as an XPath q= uery: =93=94 =93=94 What are your thoughts? Regards David Kipling 1. I have some really easy XPath queries etc. setup to handle the exte= nded validation though my issue is with the CSV files. Looks like I=92m go= ing to have to build a module to load all the csv elements into the same XM= L file for me to process. It=92s a shame it isn=92t just XML as the proces= s would be a lot easier including the Open Source Tool. Regards David ________________________________ David Kipling IT Service Desk Analyst NCC Group Manchester Technology Centre, Oxford Road Manchester, M1 7EF Telephone: +44 161 209 5430 Mobile: Fax: Website: www.nccgroup.com Email: David.Kipling@nccgroup.com [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] ________________________________ This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4= 627044). Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then d= elete the original. If you are not the intended recipient you may not use, = disclose, distribute, copy, print or rely on any information contained in t= his e-mail. You must not inform any other person other than NCC Group or th= e sender of its existence. For more information about NCC Group please visit www.nccgroup.com P Before you print think about the ENVIRONMENT --_000_CD6ABFF5654F1jamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Worried.

Are we going to assume that every validator has to map the prefixes rde = and rdeDomain to "urn:ietf:params:xml:ns:rde-1.0" and "urn:i= etf:params:xml:ns:rdeDomain-1.0" respectively? What happens when I use= namespace prefixes other than those used in the examples (e.g. bind rde to= default and rdeDomain to "d")? I assume that I would not change = the Xpath query because I would guess that I would break validator implemen= tations=85

I note also the inconsistent use of nam= espace prefixes for the RDE Domain namespace, with the document referring t= o both rdeDom and rdeDomain.

Regards,
Ja= mes

From: = David Kipling <David.Kipl= ing@nccgroup.com>
Date: = Friday, 15 March 2013 9:21 PM
To: "gustavo.lozano@icann.o= rg" <gustavo.lozano= @icann.org>, "ire@ietf.org&= quot; <ire@ietf.org>
Subject: [ire] Extended Verification Proces= s

Hi Gustavo,

 =

At NCC Group we are working on the extended verification = process and have noted a query around the RDE policy rule.  The elemen= t allows you to specify required fields such as =93<rdePolicy:policy element=3D"rdeDom:registrant" />=94 as req= uired.  The issue I have with this is that the scope of the element needs to be known to be able to perform the check e.g. is it :

 

<= p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt">=B7        one registrant per deposit?

=B7 =        one registrant per domain record?

= =B7=         one registrant per postalInfo element in each contact record?

 

You have the namespace, though I would suggest to be clear t= hat the policy element is altered to include the scope of the parent elemen= t as an XPath query:

&= nbsp;

=93<rdePolicy:policy scope=3D=94{XPath query}=94 element=3D"{qualified element name}= " />=94

=93<rdePolicy:policy scope=3D=94//rde:deposit/rde:contents/rdeDomain:domain=94 element=3D= "rdeDomain:registrant" />=94

 

What are your thoughts?

&nbs= p;

Regards

 

David Kipling

 

 

 

 

 

1.      I have some really easy XPath queries etc. setup to handle the = extended validation though my issue is with the CSV files.  Looks like= I=92m going to have to build a module to load all the csv elements into the same XML file for me to process.  = It=92s a shame it isn=92t just XML as the process would be a lot easier inc= luding the Open Source Tool.

 

Regards

 

D= avid

David Kipling
IT Service Desk Analyst
NCC Group
Manchester Technology Centre, Oxford Road
Manchester, M1 7EF

Telephone: +44 161 209 5430
Mobile:
Fax:
Website: www.nccgroup.com
Email:  David.Kipling@nccgroup.com

This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4627044).

Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then delete the original. If you are not th= e intended recipient you may not use, disclose, distribute, copy, print or = rely on any information contained in this e-mail. You must not inform any o= ther person other than NCC Group or the sender of its existence.

For more information about NCC Group please visit www.nccgroup.com

P Before you print think about the ENVI= RONMENT


--_000_CD6ABFF5654F1jamesmitchellausregistrycomau_-- From fobispo@isc.org Sat Mar 16 10:23:35 2013 Return-Path: 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 8D13A21F8900 for ; Sat, 16 Mar 2013 10:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599] 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 30JYzP3HfLGA for ; Sat, 16 Mar 2013 10:23:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C508321F88F1 for ; Sat, 16 Mar 2013 10:23:33 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2D4D85F98EB; Sat, 16 Mar 2013 17:23:20 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363454613; bh=rPZMS2sF0DUAL66lLVbB4T8sWa6FSly/VuYyozg+TZw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=iGSMnFzFBOGK0xbRNlobJH3wA/Rn/JbSihn5mm6X63DIAsnpGu98XiOsdXjJXE41d EFl35VjJRvak7ZWNkertdlxd4n9XvecvbyyIK1KKbegiaGIEFoQIL3gsKWbxfMvQrR sEOtpH4nhoVFoAzEAi1d+wD+hRWiChO+0Bz32/j0= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EF113216C3B; Sat, 16 Mar 2013 17:23:18 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: Date: Sat, 16 Mar 2013 10:23:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James Mitchell X-Mailer: Apple Mail (2.1503) Cc: "ire@ietf.org" Subject: Re: [ire] Extended Verification Process X-BeenThere: ire@ietf.org 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: Sat, 16 Mar 2013 17:23:35 -0000 It shouldn't be a problem, because he must've used xmlns declarations in = the root, and the parser will simply use that as a reference, internally = XML parsers will expand the prefix to '{namespace-uri}attribute' form, = so regardless of what the prefix was, as long as the namespace = declarations are good, it should all work as expected. On Mar 16, 2013, at 7:39 AM, James Mitchell = wrote: > Worried. >=20 > Are we going to assume that every validator has to map the prefixes = rde and rdeDomain to "urn:ietf:params:xml:ns:rde-1.0" and = "urn:ietf:params:xml:ns:rdeDomain-1.0" respectively? What happens when I = use namespace prefixes other than those used in the examples (e.g. bind = rde to default and rdeDomain to "d")? I assume that I would not change = the Xpath query because I would guess that I would break validator = implementations=85 >=20 > I note also the inconsistent use of namespace prefixes for the RDE = Domain namespace, with the document referring to both rdeDom and = rdeDomain. >=20 > Regards, > James >=20 > From: David Kipling > Date: Friday, 15 March 2013 9:21 PM > To: "gustavo.lozano@icann.org" , = "ire@ietf.org" > Subject: [ire] Extended Verification Process >=20 > Hi Gustavo, > =20 > At NCC Group we are working on the extended verification process and = have noted a query around the RDE policy rule. The element allows you = to specify required fields such as =93=94 as required. The issue I have with = this is that the scope of the element needs to be known to be able to = perform the check e.g. is it : > =20 > =B7 one registrant per deposit? > =B7 one registrant per domain record? > =B7 one registrant per postalInfo element in each contact = record? > =20 > You have the namespace, though I would suggest to be clear that the = policy element is altered to include the scope of the parent element as = an XPath query: > =20 > =93=94 > =93=94 > =20 > What are your thoughts? > =20 > Regards > =20 > David Kipling > =20 > =20 > =20 > =20 > =20 > =20 > 1. I have some really easy XPath queries etc. setup to handle the = extended validation though my issue is with the CSV files. Looks like = I=92m going to have to build a module to load all the csv elements into = the same XML file for me to process. It=92s a shame it isn=92t just XML = as the process would be a lot easier including the Open Source Tool. > =20 > Regards > =20 > David > David Kipling > IT Service Desk Analyst > NCC Group > Manchester Technology Centre, Oxford Road > Manchester, M1 7EF >=20 > Telephone: +44 161 209 5430 > Mobile:=20 > Fax:=20 > Website: www.nccgroup.com > Email: David.Kipling@nccgroup.com >=20 >=20 > This email is sent for and on behalf of NCC Group. NCC Group is the = trading name of NCC Services Limited (Registered in England CRN: = 2802141). Registered Office: Manchester Technology Centre, Oxford Road, = Manchester, M1 7EF. The ultimate holding company is NCC Group plc = (Registered in England CRN: 4627044).=20 >=20 > Confidentiality: This e-mail contains proprietary information, some or = all of which may be confidential and/or legally privileged. It is for = the intended recipient only. If an addressing or transmission error has = misdirected this e-mail, please notify the author by replying to this = e-mail and then delete the original. If you are not the intended = recipient you may not use, disclose, distribute, copy, print or rely on = any information contained in this e-mail. You must not inform any other = person other than NCC Group or the sender of its existence.=20 >=20 > For more information about NCC Group please visit www.nccgroup.com >=20 > P Before you print think about the ENVIRONMENT >=20 >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From james.mitchell@ausregistry.com.au Sat Mar 16 13:30:06 2013 Return-Path: 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 BCD2921F8614 for ; Sat, 16 Mar 2013 13:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 VC1En+ov19hu for ; Sat, 16 Mar 2013 13:30:06 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5105E21F8750 for ; Sat, 16 Mar 2013 13:30:04 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 17 Mar 2013 07:30:03 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Sun, 17 Mar 2013 07:29:52 +1100 From: James Mitchell To: Francisco Obispo Date: Sun, 17 Mar 2013 07:30:10 +1100 Thread-Topic: [ire] Extended Verification Process Thread-Index: Ac4ihQNU0BAME4KgRmmviIcI+pnxgA== Message-ID: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] Extended Verification Process X-BeenThere: ire@ietf.org 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: Sat, 16 Mar 2013 20:30:06 -0000 I understand how namespaces are used, and how many EPP toolkits and servers don't use them correctly. I'm sure his example worked, however in the following example valid deposit I will probably have broken Davids validation routines; it would work for me because my xpath will be configured with a namespace resolver that will map "D" to the rdeDomain-1.0 namespace etc, however Davids may be configured to only map rdeDomain to the rdeDomain-1.0 namespace. 2010-10-18T00:00:00Z 1.0 ... example1.test Dexample1-TEST jd1234 sh8013 sh8013 ns1.example.com ns1.example1.test RegistrarX RegistrarX 1999-04-03T22:00:00.0Z 2015-04-03T22:00:00.0Z Using java as an example, I know he could use the SAX DefaultHandler.startPrefixMapping() method to find the namespace prefixes bound in the document (I'm not sure how to achieve this in DOM), and use this information to build a NamespaceContext that can be set on the XPath instance, however it is not wrong if the xpath expression in the document uses namespace prefixes not even bound in the document itselff because I could have configured any prefixes in my xpath evaluator, e.g. the above example instead with . Regards, James On 17/03/13 4:23 AM, "Francisco Obispo" wrote: >It shouldn't be a problem, because he must've used xmlns declarations in >the root, and the parser will simply use that as a reference, internally >XML parsers will expand the prefix to '{namespace-uri}attribute' form, so >regardless of what the prefix was, as long as the namespace declarations >are good, it should all work as expected. > > > >On Mar 16, 2013, at 7:39 AM, James Mitchell > wrote: > >> Worried. >>=20 >> Are we going to assume that every validator has to map the prefixes rde >>and rdeDomain to "urn:ietf:params:xml:ns:rde-1.0" and >>"urn:ietf:params:xml:ns:rdeDomain-1.0" respectively? What happens when I >>use namespace prefixes other than those used in the examples (e.g. bind >>rde to default and rdeDomain to "d")? I assume that I would not change >>the Xpath query because I would guess that I would break validator >>implementations=8A >>=20 >> I note also the inconsistent use of namespace prefixes for the RDE >>Domain namespace, with the document referring to both rdeDom and >>rdeDomain. >>=20 >> Regards, >> James >>=20 >> From: David Kipling >> Date: Friday, 15 March 2013 9:21 PM >> To: "gustavo.lozano@icann.org" , >>"ire@ietf.org" >> Subject: [ire] Extended Verification Process >>=20 >> Hi Gustavo, >> =20 >> At NCC Group we are working on the extended verification process and >>have noted a query around the RDE policy rule. The element allows you >>to specify required fields such as =B3>element=3D"rdeDom:registrant" />=B2 as required. The issue I have with t= his >>is that the scope of the element needs to be known to be able to perform >>the check e.g. is it : >> =20 >> =B7 one registrant per deposit? >> =B7 one registrant per domain record? >> =B7 one registrant per postalInfo element in each contact record? >> =20 >> You have the namespace, though I would suggest to be clear that the >>policy element is altered to include the scope of the parent element as >>an XPath query: >> =20 >> =B3>name}" />=B2 >> =B3>element=3D"rdeDomain:registrant" />=B2 >> =20 >> What are your thoughts? >> =20 >> Regards >> =20 >> David Kipling >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> 1. I have some really easy XPath queries etc. setup to handle the >>extended validation though my issue is with the CSV files. Looks like >>I=B9m going to have to build a module to load all the csv elements into >>the same XML file for me to process. It=B9s a shame it isn=B9t just XML = as >>the process would be a lot easier including the Open Source Tool. >> =20 >> Regards >> =20 >> David >> David Kipling >> IT Service Desk Analyst >> NCC Group >> Manchester Technology Centre, Oxford Road >> Manchester, M1 7EF >>=20 >> Telephone: +44 161 209 5430 >> Mobile:=20 >> Fax:=20 >> Website: www.nccgroup.com >> Email: David.Kipling@nccgroup.com >>=20 >>=20 >> This email is sent for and on behalf of NCC Group. NCC Group is the >>trading name of NCC Services Limited (Registered in England CRN: >>2802141). Registered Office: Manchester Technology Centre, Oxford Road, >>Manchester, M1 7EF. The ultimate holding company is NCC Group plc >>(Registered in England CRN: 4627044). >>=20 >> Confidentiality: This e-mail contains proprietary information, some or >>all of which may be confidential and/or legally privileged. It is for >>the intended recipient only. If an addressing or transmission error has >>misdirected this e-mail, please notify the author by replying to this >>e-mail and then delete the original. If you are not the intended >>recipient you may not use, disclose, distribute, copy, print or rely on >>any information contained in this e-mail. You must not inform any other >>person other than NCC Group or the sender of its existence. >>=20 >> For more information about NCC Group please visit www.nccgroup.com >>=20 >> P Before you print think about the ENVIRONMENT >>=20 >>=20 >> _______________________________________________ >> ire mailing list >> ire@ietf.org >> https://www.ietf.org/mailman/listinfo/ire > >Francisco Obispo=20 >Director of Applications and Services - ISC >email: fobispo@isc.org >Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >PGP KeyID =3D B38DB1BE > From david.kipling@nccgroup.com Mon Mar 18 02:41:35 2013 Return-Path: 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 A0C8921F8951 for ; Mon, 18 Mar 2013 02:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 5lAmUP19tXVL for ; Mon, 18 Mar 2013 02:41:34 -0700 (PDT) Received: from service141.mimecast.com (service141.mimecast.com [91.220.42.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE0221F8934 for ; Mon, 18 Mar 2013 02:41:33 -0700 (PDT) Received: from keyserver.nccgroup.com (keyserver.nccgroup.com [195.95.131.32]) (Using TLS) by service141.mimecast.com; Mon, 18 Mar 2013 09:41:31 +0000 Received: from manexchprd01.nccgroup.local ([172.20.1.92]) by keyserver.nccgroup.com (PGP Universal service); Mon, 18 Mar 2013 09:41:31 +0000 X-PGP-Universal: processed; by keyserver.nccgroup.com on Mon, 18 Mar 2013 09:41:31 +0000 Received: from MANEXCHPRD02.nccgroup.local ([172.20.1.93]) by manexchprd01 ([172.20.1.92]) with mapi id 14.01.0438.000; Mon, 18 Mar 2013 09:37:22 +0000 From: David Kipling To: James Mitchell , Francisco Obispo Thread-Topic: [ire] Extended Verification Process Thread-Index: Ac4hZpPe4wqkSPI1Rcq+cOj1nTrJAgA7XwMAAAW474AABoaRAABNjmbw Date: Mon, 18 Mar 2013 09:37:22 +0000 Message-ID: <31655AEAB7ACEE41A2D1321E18D4BF3261D504EE@manexchprd02> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.5.228] MIME-Version: 1.0 X-MC-Unique: 113031809413111301 Content-Type: text/plain; charset=WINDOWS-1257 Content-Transfer-Encoding: quoted-printable Cc: "ire@ietf.org" Subject: Re: [ire] Extended Verification Process X-BeenThere: ire@ietf.org 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: Mon, 18 Mar 2013 09:41:35 -0000 I was expecting the namespace declarations to be at the root level so I wil= l investigate if there are any scenarios where this could cause an issue, t= hough as Francisco mentioned as long as the XML document provided is intern= ally consistent and the prefixes in the XPath query use the prefixes define= d in the document then there is no problem. My implementation maps from th= e document namespaces to the namespace prefixes I use in my validation, the= refore as long as the xml document provided is consistent then there would = be no issue. As you mention I have already had to manage the use of rdeDom= to my prefix of rdeDomain with no problems. I am keen though to understand the problem domain more as you mention the u= se of namespaces with EPP toolkits etc. could be an issue. The only issue = I would have with the example below would be that the XPath query uses pref= ix "E" which is not defined in the document below. This would require the = original document to be updated to include prefix "E". Can you think of an= y other concerns on the proposed update? Regards David -----Original Message----- From: James Mitchell [mailto:james.mitchell@ausregistry.com.au]=20 Sent: 16 March 2013 20:30 To: Francisco Obispo Cc: David Kipling; gustavo.lozano@icann.org; ire@ietf.org Subject: Re: [ire] Extended Verification Process I understand how namespaces are used, and how many EPP toolkits and servers= don't use them correctly. I'm sure his example worked, however in the foll= owing example valid deposit I will probably have broken Davids validation r= outines; it would work for me because my xpath will be configured with a na= mespace resolver that will map "D" to the rdeDomain-1.0 namespace etc, however Davids may be configured to only map r= deDomain to the rdeDomain-1.0 namespace. 2010-10-18T00:00:00Z 1.0 ... example1.test Dexample1-TEST jd1234 sh8013 sh8013 ns1.example.com ns1.example1.test RegistrarX RegistrarX 1999-04-03T22:00:00.0Z 2015-04-03T22:00:00.0Z Using java as an example, I know he could use the SAX DefaultHandler.startPrefixMapping() method to find the namespace prefixes b= ound in the document (I'm not sure how to achieve this in DOM), and use thi= s information to build a NamespaceContext that can be set on the XPath inst= ance, however it is not wrong if the xpath expression in the document uses = namespace prefixes not even bound in the document itselff because I could h= ave configured any prefixes in my xpath evaluator, e.g. the above example i= nstead with . Regards, James On 17/03/13 4:23 AM, "Francisco Obispo" wrote: >It shouldn't be a problem, because he must've used xmlns declarations=20 >in the root, and the parser will simply use that as a reference,=20 >internally XML parsers will expand the prefix to=20 >'{namespace-uri}attribute' form, so regardless of what the prefix was,=20 >as long as the namespace declarations are good, it should all work as expe= cted. > > > >On Mar 16, 2013, at 7:39 AM, James Mitchell=20 > wrote: > >> Worried. >>=20 >> Are we going to assume that every validator has to map the prefixes=20 >>rde and rdeDomain to "urn:ietf:params:xml:ns:rde-1.0" and=20 >>"urn:ietf:params:xml:ns:rdeDomain-1.0" respectively? What happens when=20 >>I use namespace prefixes other than those used in the examples (e.g.=20 >>bind rde to default and rdeDomain to "d")? I assume that I would not=20 >>change the Xpath query because I would guess that I would break=20 >>validator implementations=D0 >>=20 >> I note also the inconsistent use of namespace prefixes for the RDE=20 >>Domain namespace, with the document referring to both rdeDom and=20 >>rdeDomain. >>=20 >> Regards, >> James >>=20 >> From: David Kipling >> Date: Friday, 15 March 2013 9:21 PM >> To: "gustavo.lozano@icann.org" ,=20 >>"ire@ietf.org" >> Subject: [ire] Extended Verification Process >>=20 >> Hi Gustavo, >> =20 >> At NCC Group we are working on the extended verification process and=20 >>have noted a query around the RDE policy rule. The element allows you=20 >>to specify required fields such as =B3>element=3D"rdeDom:registrant" />=B2 as required. The issue I have with= =20 >>this is that the scope of the element needs to be known to be able to=20 >>perform the check e.g. is it : >> =20 >> =B7 one registrant per deposit? >> =B7 one registrant per domain record? >> =B7 one registrant per postalInfo element in each contact record? >> =20 >> You have the namespace, though I would suggest to be clear that the=20 >>policy element is altered to include the scope of the parent element=20 >>as an XPath query: >> =20 >> =B3>name}" />=B2 =B3>scope=3D=B2//rde:deposit/rde:contents/rdeDomain:domain=B2 >>element=3D"rdeDomain:registrant" />=B2 >> =20 >> What are your thoughts? >> =20 >> Regards >> =20 >> David Kipling >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> 1. I have some really easy XPath queries etc. setup to handle the >>extended validation though my issue is with the CSV files. Looks like=20 >>I=B9m going to have to build a module to load all the csv elements into= =20 >>the same XML file for me to process. It=B9s a shame it isn=B9t just XML= =20 >>as the process would be a lot easier including the Open Source Tool. >> =20 >> Regards >> =20 >> David >> David Kipling >> IT Service Desk Analyst >> NCC Group >> Manchester Technology Centre, Oxford Road Manchester, M1 7EF >>=20 >> Telephone: +44 161 209 5430 >> Mobile:=20 >> Fax:=20 >> Website: www.nccgroup.com >> Email: David.Kipling@nccgroup.com >>=20 >>=20 >> This email is sent for and on behalf of NCC Group. NCC Group is the=20 >>trading name of NCC Services Limited (Registered in England CRN: >>2802141). Registered Office: Manchester Technology Centre, Oxford=20 >>Road, Manchester, M1 7EF. The ultimate holding company is NCC Group=20 >>plc (Registered in England CRN: 4627044). >>=20 >> Confidentiality: This e-mail contains proprietary information, some=20 >>or all of which may be confidential and/or legally privileged. It is=20 >>for the intended recipient only. If an addressing or transmission=20 >>error has misdirected this e-mail, please notify the author by=20 >>replying to this e-mail and then delete the original. If you are not=20 >>the intended recipient you may not use, disclose, distribute, copy,=20 >>print or rely on any information contained in this e-mail. You must=20 >>not inform any other person other than NCC Group or the sender of its exi= stence. >>=20 >> For more information about NCC Group please visit www.nccgroup.com >>=20 >> P Before you print think about the ENVIRONMENT >>=20 >>=20 >> _______________________________________________ >> ire mailing list >> ire@ietf.org >> https://www.ietf.org/mailman/listinfo/ire > >Francisco Obispo >Director of Applications and Services - ISC >email: fobispo@isc.org >Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE > For more information please visit http:= //www.mimecast.com
This email message has been delivered safely and archived online by Mimecas= t. From fobispo@isc.org Tue Mar 19 17:28:21 2013 Return-Path: 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 2F8F121F8E16 for ; Tue, 19 Mar 2013 17:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] 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 pYJZQ8iTO80g for ; Tue, 19 Mar 2013 17:28:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0941D21F8E14 for ; Tue, 19 Mar 2013 17:28:19 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4BA945F98E4; Wed, 20 Mar 2013 00:28:06 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363739297; bh=NYex/i41Jcd+motsx86N5yQ8EtrEMgpp876ICL8ZQ3o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hl810GuNzjzzhe1AsrqFa6AwUTwP9PMFy3Rl4iXHzu+ipi1hblF3vbkuzRpqxP4fw 6996VphK0sSgy8rU32jKnsa2wHUAkShzPDEy0kgNA/iBtB55l1HXsjGFPXlNQVCsl+ 368yfqT8PkoYPI4H7Jpj2B5DGaykZsy3hf9hKASE= Received: from [IPv6:2001:4f8:3:64:90ee:23b3:5a87:688f] (unknown [IPv6:2001:4f8:3:64:90ee:23b3:5a87:688f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 79289216C3B; Wed, 20 Mar 2013 00:28:04 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: Date: Tue, 19 Mar 2013 17:28:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Gustavo Lozano X-Mailer: Apple Mail (2.1503) Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 20 Mar 2013 00:28:21 -0000 I just went over the new drafts and found something interesting: The example XML documents in the draft reference the rdeDomain = namespace: example1.test Dexample1-TEST jd1234 sh8013 sh8013 ns1.example.com ns1.example1.test RegistrarX RegistrarX 1999-04-03T22:00:00.0Z 2015-04-03T22:00:00.0Z but the XML schema is referencing the EPP (Domain) namespace for = validation: (example validation of one of my escrow dump) [][][][]_2013-03-20_full_S1_R0.ryde:1: element pw: Schemas validity = error : Element '{urn:ietf:params:xml:ns:rdeDomain-1.0}pw': This element = is not expected. Expected is one of ( = {urn:ietf:params:xml:ns:domain-1.0}pw, = {urn:ietf:params:xml:ns:domain-1.0}ext ). So it seems like the schema will need to be modified to include the = elements from the EPP schema, (or re-define them), otherwise the schema = validation will fail. Or should I be using the EPP Domain NS instead? This is part of my escrow dump: deleteme.[][][][] = DO_c13a4e438c6471d8ead63a8031d41698-ISC updateme03 foobar foobar 2013-03-19T16:36:31.961Z 2014-03-19T16:36:31.961Z OhXahpatahriomi6 Francisco On Mar 12, 2013, at 7:54 AM, Gustavo Lozano = wrote: > Colleagues, >=20 >=20 > Two new versions of the data escrow drafts have been > published: > * = http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt > * = http://www.ietf.org/id/draft-arias-noguchi-registry-data-escrow-05.txt >=20 >=20 > These drafts incorporate feedback received in this list and > private emails. >=20 >=20 > The authors of draft-arias-noguchi-dnrd-objects-mapping and > draft-gould-thippeswamy-dnrd-csv-mapping agreed to merge both drafts = to > create > a single specification that supports XML only and XML+CSV. >=20 >=20 > The data elements/objects in both drafts have been > normalized. >=20 >=20 > The authors of draft-gould-thippeswamy-dnrd-csv-mapping will > publish a new version of the CSV draft before the merge of both = drafts. >=20 >=20 > The new version (03) of the draft = draft-arias-noguchi-dnrd-objects-mapping > is going to include both models (XML only and XML+CSV). >=20 >=20 > Version 03 should include only minor changes to the data > escrow specification. >=20 >=20 > If you are attending the IETF 86 meeting and want to talk > about data escrow, please send me an email and we can arrange an = informal > meeting. >=20 >=20 > Regards, > Gustavo Lozano >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From james.mitchell@ausregistry.com.au Tue Mar 19 17:38:24 2013 Return-Path: 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 42F0521F8EF1 for ; Tue, 19 Mar 2013 17:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 l8GsjB-Q6kUk for ; Tue, 19 Mar 2013 17:38:22 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7981921F8EDE for ; Tue, 19 Mar 2013 17:38:22 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 20 Mar 2013 11:38:20 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 20 Mar 2013 11:38:18 +1100 From: James Mitchell To: "ire@ietf.org" Date: Wed, 20 Mar 2013 11:38:18 +1100 Thread-Topic: Escrow deposit watermark Thread-Index: Ac4lAzbnX5qQt9QMTxWVjvYIHRvrFA== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD6F502A6A7E1jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [ire] Escrow deposit watermark X-BeenThere: ire@ietf.org 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: Wed, 20 Mar 2013 00:38:24 -0000 --_000_CD6F502A6A7E1jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This email is primarily targeted towards ICANN and the draft registry agree= ment, however posting here for feedback from others who are implementing es= crow. Our proposed escrow solution would produce deposits for all transactions co= mmitted 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 ev= ery 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 th= e generation of the deposit. We do not perceive this as a lesser service, g= iven the escrowed data is more up-to-date, unless there are other reasons f= or the 00:00 requirement that are unknown to us. Is the proposed solution c= onsidered acceptable given the requirements outlined in the base agreement? It should be noted that acceptance of the above will require that escrow de= posit 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 t= he state of the registry database as at the time of the previous failed dep= osit. Comments/feedback welcome. Regards, James --_000_CD6F502A6A7E1jamesmitchellausregistrycomau_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

=
This email is primarily targeted towards ICANN and the draft reg= istry agreement, however posting here for feedback from others who are impl= ementing escrow.

Our proposed escrow solution woul= d produce deposits for all transactions committed up to the point in time t= hat the extract is generated. This may be considered contrary to the base a= greement, 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 inclu= de the state of the registry as at 00:00, plus the state of the registry in= cluding 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 requi= rement that are unknown to us. Is the proposed solution considered acceptab= le given the requirements outlined in the base agreement?

It should be noted that acceptance of the above will require that e= scrow 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 valid= ation is deemed required, the validator should ensure that no date-time is = greater than the watermark.

Further to this, we se= ek confirmation that in the event of a failed deposit, a subsequent full de= posit representing the current state of the registry database would constit= ute remedy. ARI would not provide a full deposit of the state of the regist= ry database as at the time of the previous failed deposit.
=
Comments/feedback welcome.

Regards,=
James
--_000_CD6F502A6A7E1jamesmitchellausregistrycomau_-- From fobispo@isc.org Tue Mar 19 18:57:41 2013 Return-Path: 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 7624721F8D92 for ; Tue, 19 Mar 2013 18:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.781 X-Spam-Level: X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599] 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 cgNiEDPrcp1m for ; Tue, 19 Mar 2013 18:57:40 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BC6C121F85B2 for ; Tue, 19 Mar 2013 18:57:40 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1B40F5F98EE; Wed, 20 Mar 2013 01:57:28 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363744660; bh=QhElPBC2c88aBKW5iZ0QTYIk3863b0Ew01G7c1CO/QA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WS4NtI6EIfHr7IZpAN5fi8zOGIA90YC2jdgq5TSLOW25k1mvFMgqD9btBA5wyGUao r8honJy6ITjRtT2H1YRS0pGzQAqo0+C/T+xpA+JHmUmw7R76G/11CYUPRItwn0ioQv 8iGeTbdl/ctpIQkx6iQu5pwlQQ/b0CgUywe8MLE8= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 200F3216C47; Wed, 20 Mar 2013 01:57:27 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: Date: Tue, 19 Mar 2013 18:57:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James Mitchell X-Mailer: Apple Mail (2.1503) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 01:57:41 -0000 Hi James, We have thought about this as well, and I agree with you. The = requirement should be of a daily deposit (full or incremental), I don't = see a value of having the state of the registry at a specific time. On Mar 19, 2013, at 5:38 PM, James Mitchell = wrote: > 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? >=20 Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From david.kipling@nccgroup.com Wed Mar 20 02:27:53 2013 Return-Path: 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 06A6421F8A8E for ; Wed, 20 Mar 2013 02:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] 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 VEFXH4dagdH9 for ; Wed, 20 Mar 2013 02:27:51 -0700 (PDT) Received: from service141.mimecast.com (service141.mimecast.com [91.220.42.81]) by ietfa.amsl.com (Postfix) with ESMTP id 956EE21F8A71 for ; Wed, 20 Mar 2013 02:27:50 -0700 (PDT) Received: from keyserver.nccgroup.com (keyserver.nccgroup.com [195.95.131.32]) (Using TLS) by service141.mimecast.com; Wed, 20 Mar 2013 09:27:48 +0000 Received: from manexchprd01.nccgroup.local ([172.20.1.92]) by keyserver.nccgroup.com (PGP Universal service); Wed, 20 Mar 2013 09:27:48 +0000 X-PGP-Universal: processed; by keyserver.nccgroup.com on Wed, 20 Mar 2013 09:27:48 +0000 Received: from MANEXCHPRD02.nccgroup.local ([172.20.1.93]) by manexchprd01 ([172.20.1.92]) with mapi id 14.01.0438.000; Wed, 20 Mar 2013 09:27:47 +0000 From: David Kipling To: Francisco Obispo Thread-Topic: [ire] New versions of data escrow drafts Thread-Index: Ac4fMYocS0NoaqyiSYW/Y095rpHTkQF0D8EAABKK0oA= Date: Wed, 20 Mar 2013 09:27:47 +0000 Message-ID: <31655AEAB7ACEE41A2D1321E18D4BF3261D51893@manexchprd02> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.5.228] signature: OK MIME-Version: 1.0 X-MC-Unique: 113032009274807401 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org 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: Wed, 20 Mar 2013 09:27:53 -0000 Hi Francisco, You need to use the domain-1.0 namespace for the pw element e.g. if you hav= e xmlns:domain=3D" urn:ietf:params:xml:ns:domain-1.0" declared then I would= expect the change below from: < rdeDomain:pw>OhXahpatahriomi6 To: OhXahpatahriomi6 This is because the pw element is declared in domain-1.0 schema and not the= rdeDomain-1.0 schema or the eppcom-1.0 schema. The pw element just confor= ms to the eppcom-1.0 type of pwAuthInfoType rather than is part of the eppc= om-1.0 schema. I hope this helps Regards David -----Original Message----- From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of Franc= isco Obispo Sent: 20 March 2013 00:28 To: Gustavo Lozano Cc: ire@ietf.org Subject: Re: [ire] New versions of data escrow drafts I just went over the new drafts and found something interesting: The example XML documents in the draft reference the rdeDomain namespace: example1.test Dexample1-TEST jd1234 sh8013 sh8013 ns1.example.com ns1.example1.test RegistrarX RegistrarX 1999-04-03T22:00:00.0Z 2015-04-03T22:00:00.0Z but the XML schema is referencing the EPP (Domain) namespace for validation= : (example validation of one of my escrow dump) [][][][]_2013-03-20_full_S1_R0.ryde:1: element pw: Schemas validity error := Element '{urn:ietf:params:xml:ns:rdeDomain-1.0}pw': This element is not ex= pected. Expected is one of ( {urn:ietf:params:xml:ns:domain-1.0}pw, {urn:ie= tf:params:xml:ns:domain-1.0}ext ). So it seems like the schema will need to be modified to include the element= s from the EPP schema, (or re-define them), otherwise the schema validation= will fail. Or should I be using the EPP Domain NS instead? This is part of my escrow dump: deleteme.[][][][] DO_c13a4e438c6471d8ead63a8031d41698-ISC updateme03 foobar foobar 2013-03-19T16:36:31.961Z 2014-03-19T16:36:31.961Z OhXahpatahriomi6 Francisco On Mar 12, 2013, at 7:54 AM, Gustavo Lozano wrot= e: > Colleagues, > > > Two new versions of the data escrow drafts have been > published: > * > http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt > * > http://www.ietf.org/id/draft-arias-noguchi-registry-data-escrow-05.txt > > > These drafts incorporate feedback received in this list and private > emails. > > > The authors of draft-arias-noguchi-dnrd-objects-mapping and > draft-gould-thippeswamy-dnrd-csv-mapping agreed to merge both drafts > to create a single specification that supports XML only and XML+CSV. > > > The data elements/objects in both drafts have been normalized. > > > The authors of draft-gould-thippeswamy-dnrd-csv-mapping will publish a > new version of the CSV draft before the merge of both drafts. > > > The new version (03) of the draft > draft-arias-noguchi-dnrd-objects-mapping > is going to include both models (XML only and XML+CSV). > > > Version 03 should include only minor changes to the data escrow > specification. > > > If you are attending the IETF 86 meeting and want to talk about data > escrow, please send me an email and we can arrange an informal > meeting. > > > Regards, > Gustavo Lozano > > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire ________________________________ David Kipling Solutions Architect NCC Group Manchester Technology Centre, Oxford Road Manchester, M1 7EF Telephone: +44 161 209 5430 Mobile: Fax: Website: www.nccgroup.com Email: David.Kipling@nccgroup.com [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] ________________________________ This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4= 627044). Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then d= elete the original. If you are not the intended recipient you may not use, = disclose, distribute, copy, print or rely on any information contained in t= his e-mail. You must not inform any other person other than NCC Group or th= e sender of its existence. For more information about NCC Group please visit www.nccgroup.com P Before you print think about the ENVIRONMENT For more information please visit http:= //www.mimecast.com
This email message has been delivered safely and archived online by Mimecas= t. From Adrian.Cho@nominet.org.uk Wed Mar 20 04:32:12 2013 Return-Path: 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 7FA2821F8F13 for ; Wed, 20 Mar 2013 04:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.8 X-Spam-Level: X-Spam-Status: No, score=-9.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] 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 tDl1Um4ZmqQB for ; Wed, 20 Mar 2013 04:32:11 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7523021F8EF2 for ; Wed, 20 Mar 2013 04:32:11 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=IrX38R7VEhlTRQKwk/4AdW0AH6wCrGaGw7/Dw7TatKGWTvbzT/FYvWBM +9YI79JiJP1nHZpNFsgl4icemGpwVBP/RJFXrSxpymfUXDf1uHbUZ7+iT CDbbgHbuNn80Ab4; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Adrian.Cho@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1363779131; x=1395315131; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Adrian=20Cho=20 |Subject:=20A=20question=20on=20upRr=20field|Date:=20Wed, =2020=20Mar=202013=2011:32:08=20+0000|Message-ID:=20<7DF7 6593066AD744A79617DBD0D8A0F210C6FA8A@wds-exc1.okna.nomine t.org.uk>|To:=20"ire@ietf.org"=20,=20Gustav o=20Lozano=20|MIME-Version:=201 .0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<479480D012523D4BB21AE2699D0A8B39@okna.nom inet.org.uk>; bh=MY6/Q7CY6hmflP9NjX2qiG1eh2xy0XfgFVK/oMd88gc=; b=ue0YVd26bVfw8/Mlh3qKBk5eT/wqBtvLSLPv+aRVDX4ZckdoO2rk/u1j wD9jqg+ESyMIJpHpmN/w0fY0vrzJ7ZFEtSAzyR3FvsVg39XaxFmwz5Za4 uZ1uYfM/7t8ZED5; X-IronPort-AV: E=Sophos;i="4.84,878,1355097600"; d="scan'208";a="47294203" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 20 Mar 2013 11:32:10 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 11:32:09 +0000 From: Adrian Cho To: "ire@ietf.org" , Gustavo Lozano Thread-Topic: A question on upRr field Thread-Index: AQHOJV6OkRxKKCsYj0mH08+nioGu/A== Date: Wed, 20 Mar 2013 11:32:08 +0000 Message-ID: <7DF76593066AD744A79617DBD0D8A0F210C6FA8A@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <479480D012523D4BB21AE2699D0A8B39@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ire] A question on upRr field X-BeenThere: ire@ietf.org 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: Wed, 20 Mar 2013 11:32:12 -0000 Hello Gustavo On Page 7 of=20 http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt It says An OPTIONAL element that contains the identifier of the registrar that last updated the domain name object. This element MUST NOT be present if the domain has never been modified.=20 Question What happens if the domain object is updated internally by the registry? Fo= r instance, if a customer service agent put serverUpdateProhibited status on a domain. How do we get this last piece of "change history" into escrow file?? Thanks in advance From bmodi@afilias.info Wed Mar 20 07:01:50 2013 Return-Path: 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 EE89F21F8F8A for ; Wed, 20 Mar 2013 07:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 dbDihsaBZMNz for ; Wed, 20 Mar 2013 07:01:49 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DF0D821F8F87 for ; Wed, 20 Mar 2013 07:01:48 -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 ) id 1UIJaO-000701-4E for ire@ietf.org; Wed, 20 Mar 2013 14:01:48 +0000 Received: from mail-ee0-f72.google.com ([74.125.83.72]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UIJaO-0005uH-3Q for ire@ietf.org; Wed, 20 Mar 2013 14:01:48 +0000 Received: by mail-ee0-f72.google.com with SMTP id b15so2764898eek.11 for ; Wed, 20 Mar 2013 07:01:42 -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:content-type:x-gm-message-state; bh=S6LJX/7i/UYUbPumWjQU0L8PLvWiAX0MVeaHxUlbNpM=; b=CBxFExuQZgs7YEjfhoHIopOA066w16t1edDiNt0U0UODRprOUyjMhB3D7nOutF4TgX gsDxnco1jkVfDUlwRLHF5lU9EnRBF6puoFueDiZOUy+zK0m3ujcCkx2bhHRW382iQ6iM pp5iKBugcOkDFUk1DjD1v8qZgeJPENOBQurhGv0rMzjCDzP08MCma49o/vG1JKp65657 c+vbLfj/Itl7m0EVgPC6/qBI2fuDKN4OYm6FIsb2aTnNIXTzc7/Wt3Eixqn4wFxW6WH5 NfMoFaN0qe0cbT8j6C0Z7W3um+kq5QbJg71ZpKm2/2JDyDLN2DLINVgtF4mtWSLLio7U 9LgQ== X-Received: by 10.180.108.3 with SMTP id hg3mr10308353wib.33.1363788102010; Wed, 20 Mar 2013 07:01:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr10308327wib.33.1363788101788; Wed, 20 Mar 2013 07:01:41 -0700 (PDT) Received: by 10.194.10.4 with HTTP; Wed, 20 Mar 2013 07:01:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Mar 2013 10:01:41 -0400 Message-ID: From: Bhadresh Modi To: "ire@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba6e35b3b1c04d85ba9a2 X-Gm-Message-State: ALoCoQkxODaMxyfjA6tNMQnzRZ+6QVjrPxJRArxVQSJWSFpO64mMAbzkOpE68JKlgMLp+20nXI8ZY5ecYcQCjXw2POHEIN9GAYrfNLfxi7UCwspDzlzbajbWK9fz5rowEdHpIeo8nEI0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 14:01:50 -0000 --e89a8f3ba6e35b3b1c04d85ba9a2 Content-Type: text/plain; charset=ISO-8859-1 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. The validation should be that no date/times within the escrow file are newer than the watermark, and that the watermark is for the correct day (not some date/time in the future). Regards, Bhadresh Modi bmodi@afilias.info On Tue, Mar 19, 2013 at 9:57 PM, Francisco Obispo wrote: > Hi James, > > We have thought about this as well, and I agree with you. The requirement > should be of a daily deposit (full or incremental), I don't see a value of > having the state of the registry at a specific time. > > > > > On Mar 19, 2013, at 5:38 PM, James Mitchell < > james.mitchell@ausregistry.com.au> wrote: > > > 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? > > > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID = B38DB1BE > > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > --e89a8f3ba6e35b3b1c04d85ba9a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. =A0Restarting the process then will begin a new escrow but it may be = impossible to return to the state at exactly 00:00 UTC. =A0Again as pointed= out before, this new deposit file would contain all information as of 00:0= 0 UTC and also include any new transactions taken place after that time.

The validation should be that no date/times within the = escrow file are newer than the watermark, and that the watermark is for the= correct day (not some date/time in the future).

Regards,
Bhadresh Modi


On Tue, Mar 19, 2013 at 9:57 PM, Francisco Obispo <fobispo@isc.org= > wrote:
Hi James,

We have thought about this as well, and I agree with you. The requirement s= hould be of a daily deposit (full or incremental), I don't see a value = of having the state of the registry at a specific time.




On Mar 19, 2013, at 5:38 PM, James Mitchell <james.mitchell@ausregistry.com.au> wrote:<= br>
> Our proposed escrow solution would produce deposits for all transactio= ns committed up to the point in time that the extract is generated. This ma= y 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 deposi= ts 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 unt= il the generation of the deposit. We do not perceive this as a lesser servi= ce, given the escrowed data is more up-to-date, unless there are other reas= ons for the 00:00 requirement that are unknown to us. Is the proposed solut= ion considered acceptable given the requirements outlined in the base agree= ment?
>

Francisco Obispo
Director of Applications and Services - ISC
email: fobispo@isc.org
Phone: +1 65= 0 423 1374 || INOC-DBA *3557* NOC
PGP KeyID =3D B38DB1BE

_______________________________________________
ire mailing list
ire@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ire

--e89a8f3ba6e35b3b1c04d85ba9a2-- From cbbrowne@afilias.info Wed Mar 20 08:35:30 2013 Return-Path: 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 7D79B21F8C93 for ; Wed, 20 Mar 2013 08:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SUB_RAND_LETTRS4=0.799] 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 HTZaat+iYvur for ; Wed, 20 Mar 2013 08:35:30 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DFD1821F8C7D for ; Wed, 20 Mar 2013 08:35:29 -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 ) id 1UIL33-0003mp-4d for ire@ietf.org; Wed, 20 Mar 2013 15:35:29 +0000 Received: from mail-we0-f200.google.com ([74.125.82.200]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UIL33-0000Wp-4C for ire@ietf.org; Wed, 20 Mar 2013 15:35:29 +0000 Received: by mail-we0-f200.google.com with SMTP id d7so2681203wer.3 for ; Wed, 20 Mar 2013 08:35:23 -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=GyA0sehROzj4oOc9aVCQU8Bdi9x0kn/EuB840sBrRlM=; b=U6V0Ju/AAxpnaZ7gX0S8F+eACnjsNYBBFvW7CZelGm83ndXz/NUy5xU6D6HqrDL8N1 984dku0ZSwmOdx85hXWPiI/kdKKjh1Nh/6qtAJhDkerzlcaPzp5dKVQztKcuQNC/7bap Xdrjecd2PuHK3guJ8l9wvUjK2x5+9G3zR9Q8eXB2IcwQ3XDCw9mbxTALCrlob7pLJZR8 oZ0whm7qtzB8HSPzt2CQGRZ1ueTMLPpY4pXtlek2U2AOfEmfPrLeUz/9jaSfYJnhkVk2 8uCRXzeSJLbiGarQdOs/W7AHhnahhsNLA6/0H4lrq6uARBiH1lmmwMZK2h8JT2FrrW2d ugQw== X-Received: by 10.194.173.167 with SMTP id bl7mr11412538wjc.50.1363793723127; Wed, 20 Mar 2013 08:35:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr11412403wjc.50.1363793721711; Wed, 20 Mar 2013 08:35:21 -0700 (PDT) Received: by 10.194.165.200 with HTTP; Wed, 20 Mar 2013 08:35:21 -0700 (PDT) In-Reply-To: <7DF76593066AD744A79617DBD0D8A0F210C6FA8A@wds-exc1.okna.nominet.org.uk> References: <7DF76593066AD744A79617DBD0D8A0F210C6FA8A@wds-exc1.okna.nominet.org.uk> Date: Wed, 20 Mar 2013 11:35:21 -0400 Message-ID: From: Christopher Browne To: Adrian Cho Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm9U0Y7F7bdrjNN4SNGrCLH2Zf1JQVG2g1q/TLEaQiUL7C7nMVEFx+BWvctZ0YY7jUsNvZSDq2abgyZhW472Y6DFteMOiUyPfhlOLQH0Dn75HwvMTcAvU/EHyy8hzVLTDOr+4Dr Cc: "ire@ietf.org" Subject: Re: [ire] A question on upRr field X-BeenThere: ire@ietf.org 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: Wed, 20 Mar 2013 15:35:30 -0000 On Wed, Mar 20, 2013 at 7:32 AM, Adrian Cho wrote: > Hello Gustavo > > On Page 7 of > > http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt > > It says > An OPTIONAL element that contains the identifier of the > registrar that last updated the domain name object. This element > MUST NOT be present if the domain has never been modified. > > Question > > What happens if the domain object is updated internally by the registry? For instance, if a customer service agent put > > serverUpdateProhibited status > > on a domain. > > How do we get this last piece of "change history" into escrow file?? > > Thanks in advance This is a place where the terminology of EPP is a bit peculiar. If you look at RFC 5730, you see that the set of RFCs are characterized as being motivated for use in registry/registrar interactions. However, it is curious to observe that the word "registrar" never occurs in RFCs 5731, 5732, 5733, or 5734. The word "client" is used instead, and it just struck me that it is possible that the IRE specifications should consider the same usage. Everyone involved in domain registrations understands and generally expects that the interactions are mostly between registries and registrars. However, there do tend to be some other sorts of clients present that do work that needs to be tracked, so that the set of clients includes: a) Registrars, obviously, b) Registry operators, which could include and require distinguishing between "legal operators" and "technical operators" c) A naming authority such as ICANN or IANA For the specific case you're talking about, I don't see it as unreasonable that the escrow would be expected to capture that a change might be made by the registry operator, which implies that mustn't strictly be required to be a registrar. In the latest draft, IRE uses the term "registrar" 218 times, and I wonder if most of those shouldn't be replaced with the term "client." There is a fairly different use made of the term "client" in the IRE draft, so it definitely isn't as simple as merely substituting "client" for "registrar." At any rate, I don't think all of the "registrars" identified in IRE are necessarily actually registrars, and the document probably needs some modification to indicate the possibility of other kinds of parties being responsible for data in a registry. From JGould@verisign.com Wed Mar 20 10:05:30 2013 Return-Path: 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 A50E721F8F12 for ; Wed, 20 Mar 2013 10:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.15 X-Spam-Level: X-Spam-Status: No, score=-4.15 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 RgO4m0D6Ylvi for ; Wed, 20 Mar 2013 10:05:28 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3160D21F8AD5 for ; Wed, 20 Mar 2013 10:05:06 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUUnsORW1w/J9qUXNQil+Oz9V6RA2RXVY@postini.com; Wed, 20 Mar 2013 10:05:28 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2KH4sMT002281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 13:04:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 13:04:54 -0400 From: "Gould, James" To: Christopher Browne , Adrian Cho Thread-Topic: [ire] A question on upRr field Thread-Index: AQHOJV6OkRxKKCsYj0mH08+nioGu/Jiu+WGA///V5AA= Date: Wed, 20 Mar 2013 17:04:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <3BF17258D6DA704689919D88A7C7EE1E@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] A question on upRr field X-BeenThere: ire@ietf.org 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: Wed, 20 Mar 2013 17:05:30 -0000 I believe that the reference to Registrar is meant to match up to the RDE Registrar object, in section 5.4, that includes the below text: The RDE registrar object is the sponsoring client of other RDE objects, for operational purposes MAY be the registry operator. The majority of the cases it will be a registrar, but MAY include the registry operator. A more generic term in this case would be Account, but I personally don't have a major issue using the name Registrar. Other types of accounts / registrar records could be deposited like ICANN or IANA if it's applicable. --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/20/13 11:35 AM, "Christopher Browne" wrote: >On Wed, Mar 20, 2013 at 7:32 AM, Adrian Cho >wrote: >> Hello Gustavo >> >> On Page 7 of >> >> http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt >> >> It says >> An OPTIONAL element that contains the identifier of the >> registrar that last updated the domain name object. This element >> MUST NOT be present if the domain has never been modified. >> >> Question >> >> What happens if the domain object is updated internally by the >>registry? For instance, if a customer service agent put >> >> serverUpdateProhibited status >> >> on a domain. >> >> How do we get this last piece of "change history" into escrow file?? >> >> Thanks in advance > >This is a place where the terminology of EPP is a bit peculiar. > >If you look at RFC 5730, you see that the set of RFCs are characterized >as being motivated for use in registry/registrar interactions. > >However, it is curious to observe that the word "registrar" never occurs >in RFCs 5731, 5732, 5733, or 5734. The word "client" is used instead, >and it just struck me that it is possible that the IRE specifications >should consider the same usage. > >Everyone involved in domain registrations understands and generally >expects that the interactions are mostly between registries and >registrars. However, there do tend to be some other sorts of clients >present that do work that needs to be tracked, so that the set of >clients includes: > >a) Registrars, obviously, >b) Registry operators, which could include and require distinguishing >between > "legal operators" and "technical operators" >c) A naming authority such as ICANN or IANA > >For the specific case you're talking about, I don't see it as unreasonable >that the escrow would be expected to capture that a change might be made >by the registry operator, which implies that mustn't strictly be >required to be a registrar. > >In the latest draft, IRE uses the term "registrar" 218 times, and I wonder >if most of those shouldn't be replaced with the term "client." There is a >fairly different use made of the term "client" in the IRE draft, so >it definitely isn't as simple as merely substituting "client" for >"registrar." > >At any rate, I don't think all of the "registrars" identified in IRE are >necessarily actually registrars, and the document probably needs >some modification to indicate the possibility of other kinds of parties >being responsible for data in a registry. >_______________________________________________ >ire mailing list >ire@ietf.org >https://www.ietf.org/mailman/listinfo/ire From Thomas.Corte@knipp.de Thu Mar 21 02:35:25 2013 Return-Path: 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 418AE21F8E1C for ; Thu, 21 Mar 2013 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 bQuhTX5JOix7 for ; Thu, 21 Mar 2013 02:35:24 -0700 (PDT) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9A21F8E16 for ; Thu, 21 Mar 2013 02:35:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 1349750 for ; Thu, 21 Mar 2013 10:35:22 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id hI1JEoujlMph for ; Thu, 21 Mar 2013 10:35:16 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 8BA6853 for ; Thu, 21 Mar 2013 10:35:16 +0100 (MEZ) Received: from localhost (thomas@localhost) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August, 2006/8.13.3) with ESMTP id r2L9ZGf3028694 for ; Thu, 21 Mar 2013 10:35:16 +0100 (MEZ) X-Authentication-Warning: hp9000.do.knipp.de: thomas owned process doing -bs Date: Thu, 21 Mar 2013 10:35:16 +0100 (MEZ) From: Thomas Corte X-X-Sender: thomas@hp9000.do.knipp.de To: ire@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:35:25 -0000 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. 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: Thomas.Corte@knipp.de E-Mail: Thomas.Corte@knipp.de Register Court: District Court Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp From gustavo.lozano@icann.org Thu Mar 21 12:11:22 2013 Return-Path: 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 160AA21F8FE8 for ; Thu, 21 Mar 2013 12:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 zye0SUTOlkUM for ; Thu, 21 Mar 2013 12:11:20 -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 F099221F8FAC for ; Thu, 21 Mar 2013 12:11:19 -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 12:11:18 -0700 From: Gustavo Lozano To: "Gould, James" , "ire@ietf.org" Date: Thu, 21 Mar 2013 12:11:17 -0700 Thread-Topic: [ire] Data escrow deposit validation tool Thread-Index: Ac4mZ91s4scLXICSQyKRVESpQ+bzyA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_CD70A7B5E072gustavolozanoicannorg_" MIME-Version: 1.0 Subject: Re: [ire] Data escrow deposit validation tool X-BeenThere: ire@ietf.org 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 19:11:22 -0000 --_004_CD70A7B5E072gustavolozanoicannorg_ Content-Type: multipart/alternative; boundary="_000_CD70A7B5E072gustavolozanoicannorg_" --_000_CD70A7B5E072gustavolozanoicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, For new gTLDs, the extended verification process has been part of the AGB f= or a long time. See Specification 2, Part A, 8, (5): " (5) If [1] includes a verification process, that will be applied at this = step. If any discrepancy is found in any of the steps, the Deposit will be consid= ered incomplete." For current gTLDs, several escrow specifications have similar provisions. F= or example, .org has the following: "4. Escrow Agent will run a program (to be supplied by ICANN) on the Deposi= t file (without report) that will ..." As part of the application for becoming a new gTLD data escrow agent, the p= rospect escrow agent must implement the extended verification process: "If this application is approved, Applicant will implement (or use the offi= cial ICANN open source developed data escrow deposit testing suite) the ext= ended verification procedure of the data escrow deposit files in less than = 30 days after publication by ICANN." (http://newgtlds.icann.org/en/announce= ments-and-media/announcement-07mar13-en) ICANN has the responsibility to preserve the security and stability of the = DNS, the EBERO program for example is part of this commitment for new gTLDs= . The risk of not usable data escrow deposit is a risk worth mitigating. Th= e extended verification process is one of the mitigation strategies for thi= s risk. As mentioned before, we are willing to contribute to an open source tool to= verify the escrow deposits. Regards, Gustavo From: , James > Date: Wednesday, March 13, 2013 2:35 PM To: Gustavo Lozano >, "ire@ietf.org" = > Subject: Re: [ire] Data escrow deposit validation tool Gustavo, The "Data escrow agent extended verification" fundamentally changes the res= ponsibilities of a data escrow provider, which can and will increase the co= st of the data escrow. Data escrow providers today are responsible for ens= uring the completeness of the deposits and for storing them. They have no = idea of the data content including its syntactic and semantic structure. R= ight now the extended validation process is optional in the draft, but if a= nd when it becomes a requirement for the data escrow providers, it would ne= ed to be vetted out by the broader community. If extended validation does become a requirement, then a standardized open = source tool is a good idea and is a minimum requirement to ensure that all= data escrow providers execute the same validation. We may be able to cont= ribute to this effort. Thanks, -- JG [cid:195536F0-7E46-44B2-88AE-82E8B9FEB1E2] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano > Date: Wednesday, March 13, 2013 9:52 AM To: "ire@ietf.org" > Subject: [ire] Data escrow deposit validation tool Colleagues, The Internet Draft: http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects= -mapping-02.txt, describes a "Data escrow agent extended verification" proc= ess. The data escrow deposits are valuable if they can be used when needed, basi= cally during an emergency. The creation of an open source data escrow deposit validation tool is an im= portant step to mitigate risks related to the quality of the escrow deposit= . This tool could be used by data escrow agents, registries and EBEROs. Who is interested in participating in the development of such a tool? Basically, the tool should receive as input a full and optionally several d= ifferential deposits. After applying the deltas the tool should perform the= tests listed in the draft. The tool should be able to handle deposits of a= t least several millions of objects. Regards, Gustavo --_000_CD70A7B5E072gustavolozanoicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
James,

For new gTLDs, the extended verification process has = been part of the AGB for a long time.

See Specification 2, Part A, 8, (5):
" (5) If [1] includes a verification process,= that will be applied at this step.
If any discrepancy is found in any of the steps, the Dep= osit will be considered incomplete."

For current gTLDs, several escrow specifications have similar pro= visions. For example, .org has the following:
"4. Escrow Agent will run a program (to be sup= plied by ICANN) on the Deposit file (without report) that will ..."<= /div>

As part of the application for = becoming a new gTLD data escrow agent, the prospect escrow agent must imple= ment the extended verification process:
http://newgtlds.icann= .org/en/announcements-and-media/announcement-07mar13-en)

ICANN has the responsibility to preserve the= security and stability of the DNS, the EBERO program for example is part o= f this commitment for new gTLDs. The risk of not usable data escrow deposit= is a risk worth mitigating. The extended verification process is one of th= e mitigation strategies for this risk. 

As mentioned before, we are willing to contribute to an ope= n source tool to verify the escrow deposits.

Regards,
Gustavo

From: <Gould>, James &l= t;JGould@verisign.com>
Date: Wednesday, March 13, 2013 2:35 = PM
To: Gustavo Lozano <gustavo.lozano@icann.org>, "<= a href=3D"mailto:ire@ietf.org">ire@ietf.org" <ire@ietf.org>
Subject:= Re: [ire] Data escrow deposit validation tool

Gustavo,

The "Data escrow agen= t extended verification" fundamentally changes the responsibilities of a da= ta escrow provider, which can and will increase the cost of the data escrow= .  Data escrow providers today are responsible for ensuring the comple= teness of the deposits and for storing them.  They have no idea of the data content= including its syntactic and semantic structure.  Right now the extend= ed validation process is optional in the draft, but if and when it becomes = a requirement for the data escrow providers, it would need to be vetted out by the broader community.  
=
If extended validation does become a requirement, then a sta= ndardized open source tool is a good idea and is  a minimum requiremen= t to ensure that all data escrow providers execute the same validation. &nb= sp;We may be able to contribute to this effort.  

=
Thanks,

-- 

 = ;

JG

 

 = ;

James Gou= ld

Pr= incipal Software Engineer

jgould@verisign.= com

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com


Fro= m: Gustavo Lozano <gu= stavo.lozano@icann.org>
Date: Wednesday, March 13, 2013 9:52 AM
= To: "ire@ietf.org" <ire@ietf.org>
Subject: [ire] Data escrow deposit validation tool
<= div>
Colleagues,

The Internet Draft: http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt,= describes a "Data escrow agent extended verification" process.
<= br>
The data escrow deposits are valuable if they can be used whe= n needed, basically during an emergency.

The creat= ion of an open source data escrow deposit validation tool is an important s= tep to mitigate risks related to the quality of the escrow deposit. This to= ol could be used by data escrow agents, registries and EBEROs.
Who is interested in participating in the development of such = a tool?

Basically, the tool should receive as inpu= t a full and optionally several differential deposits. After applying the d= eltas the tool should perform the tests listed in the draft. The tool shoul= d be able to handle deposits of at least several millions of objects.

Regards,
Gustavo
 --_000_CD70A7B5E072gustavolozanoicannorg_-- --_004_CD70A7B5E072gustavolozanoicannorg_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png Content-Disposition: attachment; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png"; size=4109; creation-date="Thu, 21 Mar 2013 19:11:17 GMT"; modification-date="Thu, 21 Mar 2013 19:11:17 GMT" Content-ID: <195536F0-7E46-44B2-88AE-82E8B9FEB1E2> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CD70A7B5E072gustavolozanoicannorg_-- From JGould@verisign.com Thu Mar 21 12:27:21 2013 Return-Path: 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 0BD0921F8554 for ; Thu, 21 Mar 2013 12:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.441 X-Spam-Level: X-Spam-Status: No, score=-4.441 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 FhaOLiIxCDP8 for ; Thu, 21 Mar 2013 12:27:19 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id AB26021F905C for ; Thu, 21 Mar 2013 12:26:55 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUUte/3kyn3FHIFU0547U88tO+DXnBkHl@postini.com; Thu, 21 Mar 2013 12:27:19 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2LJQsDO019238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 15:26:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 15:26:54 -0400 From: "Gould, James" To: Gustavo Lozano , "ire@ietf.org" Thread-Topic: [ire] Data escrow deposit validation tool Thread-Index: Ac4f8f/wCW8g8+qiQviFQ/ZRkBb7OAAQLSeAAZWr24D//8A17A== Date: Thu, 21 Mar 2013 19:26:53 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [ire] Data escrow deposit validation tool X-BeenThere: ire@ietf.org 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 19:27:21 -0000 --_004_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_" --_000_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gustavo, The AGB doesn't say anything about an "extended" verification as you descri= be. The verification process in the AGB could be a verification of the com= pleteness and the syntax of the deposits, so your claim that it has been pa= rt of the AGB for a long time is not true. I'm not going to comment on the= contents of the gTLD data escrow agent application. Jim ________________________________ From: Gustavo Lozano [gustavo.lozano@icann.org] Sent: Thursday, March 21, 2013 3:11 PM To: Gould, James; ire@ietf.org Subject: Re: [ire] Data escrow deposit validation tool James, For new gTLDs, the extended verification process has been part of the AGB f= or a long time. See Specification 2, Part A, 8, (5): " (5) If [1] includes a verification process, that will be applied at this = step. If any discrepancy is found in any of the steps, the Deposit will be consid= ered incomplete." For current gTLDs, several escrow specifications have similar provisions. F= or example, .org has the following: "4. Escrow Agent will run a program (to be supplied by ICANN) on the Deposi= t file (without report) that will ..." As part of the application for becoming a new gTLD data escrow agent, the p= rospect escrow agent must implement the extended verification process: "If this application is approved, Applicant will implement (or use the offi= cial ICANN open source developed data escrow deposit testing suite) the ext= ended verification procedure of the data escrow deposit files in less than = 30 days after publication by ICANN." (http://newgtlds.icann.org/en/announce= ments-and-media/announcement-07mar13-en) ICANN has the responsibility to preserve the security and stability of the = DNS, the EBERO program for example is part of this commitment for new gTLDs= . The risk of not usable data escrow deposit is a risk worth mitigating. Th= e extended verification process is one of the mitigation strategies for thi= s risk. As mentioned before, we are willing to contribute to an open source tool to= verify the escrow deposits. Regards, Gustavo From: , James > Date: Wednesday, March 13, 2013 2:35 PM To: Gustavo Lozano " > Subject: Re: [ire] Data escrow deposit validation tool Gustavo, The "Data escrow agent extended verification" fundamentally changes the res= ponsibilities of a data escrow provider, which can and will increase the co= st of the data escrow. Data escrow providers today are responsible for ens= uring the completeness of the deposits and for storing them. They have no = idea of the data content including its syntactic and semantic structure. R= ight now the extended validation process is optional in the draft, but if a= nd when it becomes a requirement for the data escrow providers, it would ne= ed to be vetted out by the broader community. If extended validation does become a requirement, then a standardized open = source tool is a good idea and is a minimum requirement to ensure that all= data escrow providers execute the same validation. We may be able to cont= ribute to this effort. Thanks, -- JG [cid:195536F0-7E46-44B2-88AE-82E8B9FEB1E2] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano > Date: Wednesday, March 13, 2013 9:52 AM To: "ire@ietf.org> Subject: [ire] Data escrow deposit validation tool Colleagues, The Internet Draft: http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects= -mapping-02.txt, describes a "Data escrow agent extended verification" proc= ess. The data escrow deposits are valuable if they can be used when needed, basi= cally during an emergency. The creation of an open source data escrow deposit validation tool is an im= portant step to mitigate risks related to the quality of the escrow deposit= . This tool could be used by data escrow agents, registries and EBEROs. Who is interested in participating in the development of such a tool? Basically, the tool should receive as input a full and optionally several d= ifferential deposits. After applying the deltas the tool should perform the= tests listed in the draft. The tool should be able to handle deposits of a= t least several millions of objects. Regards, Gustavo --_000_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Gustavo,

The AGB doesn't say anything about an "extended&= quot; verification as you describe.  The verification process in the A= GB could be a verification of the completeness and the syntax of the deposi= ts, so your claim that it has been part of the AGB for a long time is not true.  I'm not going to comment on the content= s of the gTLD data escrow agent application.  

Jim 

From: Gustavo Lozano [gustavo.lozano@ica= nn.org]
Sent: Thursday, March 21, 2013 3:11 PM
To: Gould, James; ire@ietf.org
Subject: Re: [ire] Data escrow deposit validation tool

James,

For new gTLDs, the extended verifi= cation process has been part of the AGB for a long time.

See Specification 2, Part A, 8, (5= ):
" (5) If [1] includes a verif= ication process, that will be applied at this step.
If any discrepancy is found in any= of the steps, the Deposit will be considered incomplete."

For current gTLDs, several escrow = specifications have similar provisions. For example, .org has the following= :
"4. Escrow Agent will run a p= rogram (to be supplied by ICANN) on the Deposit file (without report) that = will ..."

As part of the application for becoming a new gTLD data esc= row agent, the prospect escrow agent must implement the extended verificati= on process:
"If this application is approved, Applicant will i= mplement (or use the official ICANN open source developed data escrow depos= it testing suite) the extended verification procedure of the data escrow deposit files in less than 30 days after publ= ication by ICANN." (http://newgtlds.ic= ann.org/en/announcements-and-media/announcement-07mar13-en)

ICANN has the responsibility to pr= eserve the security and stability of the DNS, the EBERO program for example= is part of this commitment for new gTLDs. The risk of not usable data escrow deposit is a risk worth mitigating. The= extended verification process is one of the mitigation strategies for this= risk. 

As mentioned before, we are willin= g to contribute to an open source tool to verify the escrow deposits.

Regards,
Gustavo

From: <Gould>, James <JGould@verisign.com>
Date: Wednesday, March 13, 2013 2:3= 5 PM
To: Gustavo Lozano <ire@ietf.org" <ire@ietf.org>
Subject: Re: [ire] Data escrow depo= sit validation tool

Gustavo,

The "Data escrow agent extended verification" fundamentally = changes the responsibilities of a data escrow provider, which can and will = increase the cost of the data escrow.  Data escrow providers today are= responsible for ensuring the completeness of the deposits and for storing them.  They have no idea of the data content= including its syntactic and semantic structure.  Right now the extend= ed validation process is optional in the draft, but if and when it becomes = a requirement for the data escrow providers, it would need to be vetted out by the broader community.  

If extended validation does become a requirement, then a standardized = open source tool is a good idea and is  a minimum requirement to ensur= e that all data escrow providers execute the same validation.  We may = be able to contribute to this effort.  

Thanks,

-- 

 

JG

 

 

Jame= s Gould

Princ= ipal Software Engineer

jgould@verisign.com<= /span>

 = ;

703-9= 48-3271 (Office)

12061= Bluemont Way

Resto= n, VA 20190

Veri= signInc.com


From: Gustavo Lozano <gustavo.lozano@icann.or= g>
Date: Wednesday, March 13, 2013 9:5= 2 AM
To: "ire@ietf.org>
Subject: [ire] Data escrow deposit = validation tool

Colleagues,

The Internet Draft: http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt,= describes a "Data escrow agent extended verification" process.

The data escrow deposits are valuable if they can be used when needed,= basically during an emergency.

The creation of an open source data escrow deposit validation tool is = an important step to mitigate risks related to the quality of the escrow de= posit. This tool could be used by data escrow agents, registries and EBEROs= .

Who is interested in participating in the development of such a tool?<= /div>

Basically, the tool should receive as input a full and optionally seve= ral differential deposits. After applying the deltas the tool should perfor= m the tests listed in the draft. The tool should be able to handle deposits= of at least several millions of objects.

Regards,
Gustavo
--_000_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_-- --_004_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png"; size=4109; creation-date="Thu, 21 Mar 2013 19:11:17 GMT"; modification-date="Thu, 21 Mar 2013 19:11:17 GMT" Content-ID: <195536F0-7E46-44B2-88AE-82E8B9FEB1E2> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C41D7AF7FCECBE44940E9477E8E70D7A24C5F5B7BRN1WNEXMBX01vc_-- From cbbrowne@afilias.info Thu Mar 21 15:06:00 2013 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ) 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 ; 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: 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 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." 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. 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. From gustavo.lozano@icann.org Thu Mar 21 16:17:13 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: James Mitchell , "ire@ietf.org" Date: Thu, 21 Mar 2013 16:16:59 -0700 Thread-Topic: [ire] Escrow deposit watermark Thread-Index: Ac4mijBiRpBYODy2Sw+H7Wj1DlfYAg== Message-ID: In-Reply-To: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:17:13 -0000 --_000_CD70DF74E30Bgustavolozanoicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, Comments inline. Regards, Gustavo From: James Mitchell > Date: Tuesday, March 19, 2013 5:38 PM To: "ire@ietf.org" > Subject: [ire] Escrow deposit watermark All, This email is primarily targeted towards ICANN and the draft registry agree= ment, however posting here for feedback from others who are implementing es= crow. Our proposed escrow solution would produce deposits for all transactions co= mmitted 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 ev= ery 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 th= e generation of the deposit. We do not perceive this as a lesser service, g= iven the escrowed data is more up-to-date, unless there are other reasons f= or the 00:00 requirement that are unknown to us. Is the proposed solution c= onsidered 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, e= scrow deposits, bulk registration data and DNS zone. It should be noted that acceptance of the above will require that escrow de= posit 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 t= he state of the registry database as at the time of the previous failed dep= osit. Comments/feedback welcome. Regards, James --_000_CD70DF74E30Bgustavolozanoicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
James,

Comments inline.

Regards,
Gustavo

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

All,

This email is primarily targete= d 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 co= mmitted 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 regis= try 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 ther= e are other reasons for the 00:00 requirement that are unknown to us. Is th= e proposed solution considered acceptable given the requirements outlined i= n the base agreement?

Unfortunately no.

The reason for this requirement is our audit process. On= e 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 t= he above will require that escrow deposit validation does not check for the= presence of date-times, for example domain creation date, that are after 0= 0:00 UTC. If date-time validation is deemed required, the validator should ensure that no date-time is greater than the watermark.

Furth= er to this, we seek confirmation that in the event of a failed deposit, a s= ubsequent full deposit representing the current state of the registry datab= ase would constitute remedy. ARI would not provide a full deposit of the st= ate of the registry database as at the time of the previous failed deposit.

Comments/feedba= ck welcome.

Regards,
James
 --_000_CD70DF74E30Bgustavolozanoicannorg_-- From david.kipling@nccgroup.com Fri Mar 22 05:34:08 2013 Return-Path: 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 2CEC721F8B35 for ; Fri, 22 Mar 2013 05:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 GYAvehuzHU+8 for ; Fri, 22 Mar 2013 05:34:07 -0700 (PDT) Received: from service141.mimecast.com (service141.mimecast.com [91.220.42.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1921321F8A08 for ; Fri, 22 Mar 2013 05:34:06 -0700 (PDT) Received: from keyserver.nccgroup.com (keyserver.nccgroup.com [195.95.131.32]) (Using TLS) by service141.mimecast.com; Fri, 22 Mar 2013 12:34:04 +0000 Received: from manexchprd01.nccgroup.local ([172.20.1.92]) by keyserver.nccgroup.com (PGP Universal service); Fri, 22 Mar 2013 12:34:04 +0000 X-PGP-Universal: processed; by keyserver.nccgroup.com on Fri, 22 Mar 2013 12:34:04 +0000 Received: from MANEXCHPRD02.nccgroup.local ([172.20.1.93]) by manexchprd01 ([172.20.1.92]) with mapi id 14.01.0438.000; Fri, 22 Mar 2013 12:34:02 +0000 From: David Kipling To: "gustavo.lozano@icann.org" , "ire@ietf.org" Thread-Topic: [ire] Extended Verification Process - FQDN step Thread-Index: Ac4m+SHIKQRZykiPSCq3qcc8bF+Uvw== Date: Fri, 22 Mar 2013 12:34:02 +0000 Message-ID: <31655AEAB7ACEE41A2D1321E18D4BF3261D5200C@manexchprd02> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.5.228] signature: OK MIME-Version: 1.0 X-MC-Unique: 113032212340412501 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: [ire] Extended Verification Process - FQDN step X-BeenThere: ire@ietf.org 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: Fri, 22 Mar 2013 12:34:08 -0000 Hi Gustavo, At NCC Group we are working on the extended verification process and after = speaking with some of our customers and registry backend providers it was u= nclear as to how the step below could be tested effectively: "An FQDN exists only as a domain name or NNDN." Is this literally that any values in the name element of the domain record = should not exist as the value of the aName element of an NNDN record? e.g. example1.test means the value of example1.test s= hould not exist as a value of the tag e.g. rdeNNDN:aName>e= xample1.test and vice versa so if the element xn--exampl-gva.test exists then xn--exampl-g= va.test should not exist in the deposit. Regards David ________________________________ David Kipling Solutions Architect NCC Group Manchester Technology Centre, Oxford Road Manchester, M1 7EF Telephone: +44 161 209 5430 Mobile: Fax: Website: www.nccgroup.com Email: David.Kipling@nccgroup.com [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] ________________________________ This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4= 627044). Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then d= elete the original. If you are not the intended recipient you may not use, = disclose, distribute, copy, print or rely on any information contained in t= his e-mail. You must not inform any other person other than NCC Group or th= e sender of its existence. For more information about NCC Group please visit www.nccgroup.com P Before you print think about the ENVIRONMENT For more information please visit http:= //www.mimecast.com
This email message has been delivered safely and archived online by Mimecas= t. From JGould@verisign.com Tue Mar 26 12:57:27 2013 Return-Path: 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 DEB1021F8D2D for ; Tue, 26 Mar 2013 12:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 SlQPkvfCi60A for ; Tue, 26 Mar 2013 12:57:26 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6856321F8D2C for ; Tue, 26 Mar 2013 12:57:23 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUVH9ojq4bnYLKh1UREc5RQBUIEaoRZCD@postini.com; Tue, 26 Mar 2013 12:57:23 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2QJvMOi031240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Mar 2013 15:57:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 15:57:21 -0400 From: "Gould, James" To: "ire@ietf.org" Thread-Topic: DNRD CSV 03 Draft Thread-Index: AQHOKlwgzE/yvZaCukOmBkDAkP4aww== Date: Tue, 26 Mar 2013 19:57:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_004_CD7773674BE5Ajgouldverisigncom_" MIME-Version: 1.0 Subject: [ire] DNRD CSV 03 Draft X-BeenThere: ire@ietf.org 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: Tue, 26 Mar 2013 19:57:27 -0000 --_004_CD7773674BE5Ajgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CD7773674BE5Ajgouldverisigncom_" --_000_CD7773674BE5Ajgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The Domain Name Registration Data (DNRD) Comma-Separated Values (CSV) Objec= ts Mapping 03 draft has been created that primarily addresses an issue with= the changes made in draft-arias-noguchi-registry-data-escrow-05. The plan= is to start merging draft-gould-thippeswamy-dnrd-csv-mapping-03 and draft-= arias-noguchi-dnrd-objects-mapping-02. The full list of changes in draft-g= ould-thippeswamy-dnrd-csv-mapping-03 are below: 1. Incorporated fixes to issues with examples identified by Rickard Bellgrim. 2. Updates to support draft-arias-noguchi-registry-data-escrow-05 by removing the reference to and replacing with the reference to in the CSV object schemas, and removing reference to in the rdeCsv-1.0 schema. 3. Restructured the sub-elements of by removing the generic element and replacing with object specific deletes elements like that contains elements. The 03 draft is available below for feedback: http://www.ietf.org/internet-drafts/draft-gould-thippeswamy-dnrd-csv-mappin= g-03.txt http://tools.ietf.org/html/draft-gould-thippeswamy-dnrd-csv-mapping-03 Thanks, -- JG [cid:D53BB67F-0D37-41F7-BE9A-73A4F307DB92] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com --_000_CD7773674BE5Ajgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <89B024F13DD20149B0AC85A4B0F6B73C@verisign.com> Content-Transfer-Encoding: quoted-printable
All,

The Domain Name Registration Data= (DNRD) Comma-Separated Values (CSV) Objects Mapping 03 draft has been crea= ted that primarily addresses an issue with the changes made in draft-a= rias-noguchi-registry-data-escrow-05.  The plan is to start merging draft-gould-thippeswamy-dnrd-csv-mapping-03 and draft-= arias-noguchi-dnrd-objects-mapping-02.  The full list of changes in&nb= sp;draft-gould-thippeswamy-dnrd-csv-mapping-03 are below:

   1.  Incorporated fixes =
to issues with examples identified by Rickard
       Bellgrim.

   2.  Updates to support draft-arias-noguchi-registry-data-escrow-05 by
       removing the reference to <rde:contents> and replacing with th=
e
       reference to <rde:content> in the CSV object schemas, and
       removing reference to <rde:content> in the rdeCsv-1.0 schema.

   3.  Restructured the sub-elements of <rde:deletes> by removing the
       generic <rdeCsv:csvDelete> element and replacing with
       object specific deletes elements like <csvDomain:deletes> that
       contains <rdeCsv:csv> elements.


The 03 draft =
is available below for feedback:


Thanks,


--

  

JG<= /p>

 

 

James Gould

Principal Software Engineer

jgould@verisign.= com=

 

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com


 --_000_CD7773674BE5Ajgouldverisigncom_-- --_004_CD7773674BE5Ajgouldverisigncom_ Content-Type: image/png; name="86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[18].png" Content-Description: 86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[18].png Content-Disposition: attachment; filename="86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[18].png"; size=4109; creation-date="Tue, 26 Mar 2013 19:57:21 GMT"; modification-date="Tue, 26 Mar 2013 19:57:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CD7773674BE5Ajgouldverisigncom_-- From gustavo.lozano@icann.org Tue Mar 26 18:17:19 2013 Return-Path: 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 85B4521F86A8 for ; Tue, 26 Mar 2013 18:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 C8AaD5AHUtDz for ; Tue, 26 Mar 2013 18:17:18 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5068221F84BD for ; Tue, 26 Mar 2013 18:17:18 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 26 Mar 2013 18:17:17 -0700 From: Gustavo Lozano To: David Kipling , "ire@ietf.org" Date: Tue, 26 Mar 2013 18:17:15 -0700 Thread-Topic: [ire] Extended Verification Process - FQDN step Thread-Index: Ac4qiNIOPgXMeCvfT06jSiMdiglETA== Message-ID: In-Reply-To: <31655AEAB7ACEE41A2D1321E18D4BF3261D5200C@manexchprd02> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] Extended Verification Process - FQDN step X-BeenThere: ire@ietf.org 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: Wed, 27 Mar 2013 01:17:19 -0000 Hi David, Comments inline. Regards, Gustavo On 3/22/13 5:34 AM, "David Kipling" wrote: >Hi Gustavo, > >At NCC Group we are working on the extended verification process and >after speaking with some of our customers and registry backend providers >it was unclear as to how the step below could be tested effectively: > >"An FQDN exists only as a domain name or NNDN." > >Is this literally that any values in the name element of the domain >record should not exist as the value of the aName element of an NNDN >record? > >e.g. > >example1.test means the value of example1.test >should not exist as a value of the tag e.g. >rdeNNDN:aName>example1.test and vice versa so if the >element xn--exampl-gva.test exists then >xn--exampl-gva.test should not exist in the >deposit. You are correct. =20 The NNDN object was created to support those registries that use a reserved list of names that are not created as domain objects and also to support the use case of using a name (but not a domain object) to specify granular policies regarding IDN variants handling. =20 If a registry creates reserved names as domain objects with an internal registrar for example, such registry may only use domain objects. If a registry handle reserved names as a list of names, such registry may use the NNDN object. If a registry creates variants in blocked or withheld state, such registry may use the NNDN object instead of a creating a domain object. If a registry creates mirror variants algorithmically, such registry may use the NNDN to block variants that are not valid. =20 The registry must choose if the use of a NNDN is appropriate based on the design of its SRS. Basically a NNDN is like a light domain object with no registrar, registrant or NS servers associated to it. Regards, Gustavo > >Regards > >David >________________________________ > >David Kipling >Solutions Architect >NCC Group >Manchester Technology Centre, >Oxford Road >Manchester, M1 7EF > >Telephone: +44 161 209 5430 >Mobile: >Fax: >Website: www.nccgroup.com >Email: David.Kipling@nccgroup.com > [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] > >________________________________ > >This email is sent for and on behalf of NCC Group. NCC Group is the >trading name of NCC Services Limited (Registered in England CRN: >2802141). Registered Office: Manchester Technology Centre, Oxford Road, >Manchester, M1 7EF. The ultimate holding company is NCC Group plc >(Registered in England CRN: 4627044). > >Confidentiality: This e-mail contains proprietary information, some or >all of which may be confidential and/or legally privileged. It is for the >intended recipient only. If an addressing or transmission error has >misdirected this e-mail, please notify the author by replying to this >e-mail and then delete the original. If you are not the intended >recipient you may not use, disclose, distribute, copy, print or rely on >any information contained in this e-mail. You must not inform any other >person other than NCC Group or the sender of its existence. > >For more information about NCC Group please visit >www.nccgroup.com > >P Before you print think about the ENVIRONMENT > > >For more information please visit href=3D"http://www.mimecast.com">http://www.mimecast.com
>This email message has been delivered safely and archived online by >Mimecast. > > From gustavo.lozano@icann.org Tue Mar 26 18:25:47 2013 Return-Path: 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 361F221F86F5 for ; Tue, 26 Mar 2013 18:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 DFGaoutU8Icu for ; Tue, 26 Mar 2013 18:25:46 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC6F21F84CE for ; Tue, 26 Mar 2013 18:25:46 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 26 Mar 2013 18:25:45 -0700 From: Gustavo Lozano To: David Kipling , "ire@ietf.org" Date: Tue, 26 Mar 2013 18:25:42 -0700 Thread-Topic: Extended Verification Process Thread-Index: Ac4qigD4f9miWR3VQnWrEunxGk4RGQ== Message-ID: In-Reply-To: <31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DF@manexchprd01> 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_CD77981AEABAgustavolozanoicannorg_" MIME-Version: 1.0 Subject: Re: [ire] Extended Verification Process X-BeenThere: ire@ietf.org 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: Wed, 27 Mar 2013 01:25:47 -0000 --_000_CD77981AEABAgustavolozanoicannorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, Comments inline. Regards, Gustavo From: David Kipling > Date: Friday, March 15, 2013 3:21 AM To: Gustavo Lozano >, "ire@ietf.org" = > Subject: Extended Verification Process Hi Gustavo, At NCC Group we are working on the extended verification process and have n= oted a query around the RDE policy rule. The element allows you to specify= required fields such as =93=94 as required. The issue I have with this is that the scope of the el= ement needs to be known to be able to perform the check e.g. is it : =B7 one registrant per deposit? =B7 one registrant per domain record? =B7 one registrant per postalInfo element in each contact record? You have the namespace, though I would suggest to be clear that the policy = element is altered to include the scope of the parent element as an XPath q= uery: =93=94 =93=94 What are your thoughts? This makes a lot of sense. I will discuss with the co authors of the draft,= the inclusion of this idea, in the new version of the draft (merge of CSV = and XML). Regards David Kipling 1. I have some really easy XPath queries etc. setup to handle the exte= nded validation though my issue is with the CSV files. Looks like I=92m go= ing to have to build a module to load all the csv elements into the same XM= L file for me to process. It=92s a shame it isn=92t just XML as the proces= s would be a lot easier including the Open Source Tool. Regards David ________________________________ David Kipling IT Service Desk Analyst NCC Group Manchester Technology Centre, Oxford Road Manchester, M1 7EF Telephone: +44 161 209 5430 Mobile: Fax: Website: www.nccgroup.com Email: David.Kipling@nccgroup.com [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] ________________________________ This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4= 627044). Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then d= elete the original. If you are not the intended recipient you may not use, = disclose, distribute, copy, print or rely on any information contained in t= his e-mail. You must not inform any other person other than NCC Group or th= e sender of its existence. For more information about NCC Group please visit www.nccgroup.com P Before you print think about the ENVIRONMENT --_000_CD77981AEABAgustavolozanoicannorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi David,

Comments inline.

Regards,
Gustavo=

From: David Kipling = <David.Kipling@nccgroup.co= m>
Date: Friday, March 1= 5, 2013 3:21 AM
To: Gustavo Loz= ano <gustavo.lozano@icann.or= g>, "ire@ietf.org" <= ;ire@ietf.org>
Subject: Extended Verification Process

Hi Gustavo,

 =

At NCC Group we are working on the extended verification = process and have noted a query around the RDE policy rule.  The elemen= t allows you to specify required fields such as =93<rdePolicy:policy element=3D"rdeDom:registrant" />=94 as req= uired.  The issue I have with this is that the scope of the element needs to be known to be able to perform the check e.g. is it :

 

<= p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt">=B7        one registrant per deposit?

=B7 =        one registrant per domain record?

= =B7=         one registrant per postalInfo element in each contact record?

 

You have the namespace, though I would suggest to be clear t= hat the policy element is altered to include the scope of the parent elemen= t as an XPath query:

&= nbsp;

=93<rdePolicy:policy scope=3D=94{XPath query}=94 element=3D"{qualified element name}= " />=94

=93<rdePolicy:policy scope=3D=94//rde:deposit/rde:contents/rdeDomain:domain=94 element=3D= "rdeDomain:registrant" />=94

 

What are your thoughts?

=

This makes a lot of se= nse. I will discuss with the co authors of the draft, the inclusion of this= idea, in the new version of the draft (merge of CSV and XML).
=

 =

Regards

 

<= p class=3D"MsoNormal">David Kipling

 

 

 

 

 

&= nbsp;

1.      I have some really easy XPath queries etc. setup to handle the = extended validation though my issue is with the CSV files.  Looks like= I=92m going to have to build a module to load all the csv elements into the same XML file for me to process.  = It=92s a shame it isn=92t just XML as the process would be a lot easier inc= luding the Open Source Tool.

 

Regards

 

D= avid

David Kipling
IT Service Desk Analyst
NCC Group
Manchester Technology Centre, Oxford Road
Manchester, M1 7EF

Telephone: +44 161 209 5430
Mobile:
Fax:
Website: www.nccgroup.com
Email:  David.Kipling@nccgroup.com

This email is sent for and on behalf of NCC Group. NCC Group is the trading= name of NCC Services Limited (Registered in England CRN: 2802141). Registe= red Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. = The ultimate holding company is NCC Group plc (Registered in England CRN: 4627044).

Confidentiality: This e-mail contains proprietary information, some or all = of which may be confidential and/or legally privileged. It is for the inten= ded recipient only. If an addressing or transmission error has misdirected = this e-mail, please notify the author by replying to this e-mail and then delete the original. If you are not th= e intended recipient you may not use, disclose, distribute, copy, print or = rely on any information contained in this e-mail. You must not inform any o= ther person other than NCC Group or the sender of its existence.

For more information about NCC Group please visit www.nccgroup.com

P Before you print think about the ENVI= RONMENT


--_000_CD77981AEABAgustavolozanoicannorg_-- From alexander.mayrhofer@nic.at Fri Mar 29 07:27:29 2013 Return-Path: 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 8DEC221F9406 for ; Fri, 29 Mar 2013 07:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.33 X-Spam-Level: X-Spam-Status: No, score=-9.33 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] 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 vN+f5D8N99RV for ; Fri, 29 Mar 2013 07:27:28 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id C680C21F9402 for ; Fri, 29 Mar 2013 07:27:27 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Fri, 29 Mar 2013 15:27:26 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 29 Mar 2013 15:27:23 +0100 From: Alexander Mayrhofer To: "ire@ietf.org" Thread-Topic: "resend" attribute in "deposit" element. Thread-Index: Ac4shj7+b9scwC9ySlWUUK04pAlE9w== Date: Fri, 29 Mar 2013 14:27:22 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750982F68A@NICS-EXCH.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Cc: Mark Hofstetter Subject: [ire] "resend" attribute in "deposit" element. X-BeenThere: ire@ietf.org 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: Fri, 29 Mar 2013 14:27:29 -0000 Hi, We're in the late stages of implementing our escrow export script, and have= discussed internally the purpose of the "resend" attribute in the "deposit= " element itself.=20 Reading through the definition, this attribute is not related to the *creat= ion* of the escrow deposit, but rather to its *transport* (Our understandin= g is that the id attribute is more related to the creation of the file).=20 More specifically, we don't see a reason why the "resend" attribute should = actually be contained in the file itself, because failure to "send" the fil= e to the Escrow provider is completely unrelated to the contents of the fil= e.=20 If a transport attempt fails, a registry should simply be able to rename th= e (successfully created, validated) escrow file, and just retry the *transp= ort*, rather than the *creation*. However, since the "resend" attribute is = included in the (compressed/encrypted/signed) file itself (in addition to t= he file name!), a failed *transport* attempt (eg. a interrupted upload) req= uires registries to essentially restart the generation: modify the origina= l escrow dump, and repeat the whole split/compress/encrypt/sign steps.=20 We hence believe that the "resend" attribute should be removed from the def= inition of the "deposit" element. It is not only redundant (since it's also= included in the file name itself), but its inclusion in the escrow content= itself is actually misleading, and puts extra burden on the escrow process= . *If* ICANN's intent with the "resend" attribute was to reflect whether a = file has been re-*generated* (and not just re-*sent*), we propose to change= the current structure as follows: - Keep the "resend" part of the file names, and provide clear instructions = that this number is to be increased when *transport* of the deposit failed,= and is repeated with the identical file contents (retransmission). - Remove the "resend" attribute from the "deposit" element. - (Optionally) add a "revision" attribute to the "deposit" element, and pro= vide clear instructions that the number contained in that attribute is to b= e increased when the *creation* of a deposit with an identical "id" is perf= ormed (re-generation). Feedback appreciated Alex