Re: [ire] Extended verification process of the escrow deposit files

[Gustavo Lozano <[e-mail]>]

James,

Comments below.

From: <Gould>, James <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 17, 2012 10:57 AM
To: Gustavo Lozano <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ire] Extended verification process of the escrow deposit files

Gustavo,

Has the concept of an "extended verification process" for the data escrow agents been previously discussed or documented?   It looks like some of the data integrity checks (linked contacts and hosts) along with business rules like whether or not there are glue records and the creation and last update dates in the future are better handled by an EBERO provider based on the deposits made.  The Data Escrow Provider should be able to validate the completeness of the deposit by verifying the signatures and verify the deposit against the format definition.

GL. The problem perceived with this approach is that the format definition on the draft is too generic. An extension mechanism is being incorporated in the new version of the draft-arias-noguchi-dnrd-objects-mapping draft and we require that data escrow agents validate the data related to extensions. I understand that you define some extensions guidelines in the draft-gould-thippeswamy-dnrd-csv-mapping draft as well.

 Items like email address validation should be covered by the XSD format definition.  Applying differential deposits to the full deposit also sounds like the job of the EBERO provider and not the Data Escrow Provider.    In summary, I believe that only #1 below should be required of the Data Escrow Provider and the remainder should be discussed as a requirement for an EBERO provider.

GL. Requiring the EBEROs perform verification of the escrow deposit files frequently is an unlikely scenario. The data escrow agent is the party other than the registry with frequent (daily) access to escrow files, therefore the data escrow agent is in best position to perform a verification procedure. Depending on the day of the week, the full deposit and differentials are require to have a snapshot of the SRS database at that point in time, and it is expected that the extended verification procedure will require access to a snapshot of the SRS database.


--

JG

[cid:2FE192F5-206E-41B1-B26D-69A4A5A73698]

James Gould
Principal Software Engineer
[e-mail]<mailto:[e-mail]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



From: Gustavo Lozano <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 13, 2012 7:28 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [ire] Extended verification process of the escrow deposit files


Colleagues,



Specification 2, Part A, 8. of the new gTLD applicant guidebook specifies:



" (5) If [1] includes a verification process, that will be applied at this step."



We are in the process of defining the extended verification process that the data escrow agents must perform daily with the escrow deposit file. This process will be included in new versions of the data escrow draft.



The purpose of this continuous verification process is to mitigate the risk of  an inconsistent data escrow deposit file.


In case of differentials deposits, the escrow agent shall use the last full and all the differentials deposits to perform the extended verification process.


I am interested in your feedback regarding:

 1. Other tests that you consider should be present in the draft.

 2. The proposed tests itself.


Proposed tests (this is not a final list of tests, we want to create the final list of tests with your input):

 1. Validate the escrow deposit file using the schema defined for the TLD including extensions as defined in Specification 2, Part A, 3.2 of the new gTLD base agreement.

 2. All contacts linked to domain names in the escrow deposit files are present.

 3. All hosts linked to domain names in the escrow deposit files are present.

 4. All the required glue records are present.

 5. The IPv4 addresses of the glue records are valid global address, or in other words not present in the special use IPv4 address blocks defined in: RFC5735 and RFC6598.

 6. The IPv6 addresses of the glue records are part of 2000::/3 with the exception of sub allocations mentioned in RFC5156.

 7. The creation and last update date of objects is not in the future.

 8. Email addresses are syntactically valid.


Note: heuristics tests like the abrupt increase or decrease of domain names escrowed will be performed by ICANN using the data escrow report sent by the data escrow agents to ICANN.