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

[Gustavo Lozano <[e-mail]>]

James, James, and Christopher,

Thank you for your comments.

The objective of the extended verification process is to reduce the risk of finding that the escrow deposit is inconsistent when it is too late (e.g. the EBERO is needed and the current registry operator is uncooperative or unable to provide the requisite data).

The objective is not to create provisioning requirements nor create an audit process.

ICANN access to the escrow deposit is sporadic; therefore the data escrow agent is in the best position to execute a verification procedure of the data escrow deposit file.

The standard verification procedure performed by the data escrow agent, specification 2 of the new gTLD AGB part A, 8, 1-4, basically require the data escrow agent verify the signature and validate using the XML schema of the dnrd draft. The XML schema of the dnrd draft is too generic and it does not include extensions.

Step 5 of the verification procedure mentioned in the AGB (specification 2 of the new gTLD AGB, part A, 5) is there to define extra tests that must be performed by the escrow agent. We envisioned use step 5 to at least define that escrow agents must validate the escrow deposit file using the customized XML schema for the new gTLD and the data escrow extensions.

We want to add more tests to this verification procedure (step 5) in order to reduce the risk mentioned above. These tests must be universally applicable regarding of the business model of the registry operator. We believe that the expertise present in this list could help to refine this extended verification process to narrow the filter of what appears to be a consistent data escrow deposit.

The extended verification tests could be separated in two categories: applicable to all TLDs (e.g. ccTLDs) and applicable to the new gTLD program.

It is worth mentioned that the extended verification process is not the only mechanism envisioned by ICANN to mitigate the risk of an inconsistent escrow deposit file.

Thank you.

Regards,
Gustavo

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.  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.

--

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.


Regards,
Gustavo Lozano