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

[Gustavo Lozano <[e-mail]>]

James,

Comments below.

From: James Mitchell <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 14, 2012 6:45 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

Comments below.

James

From: Gustavo Lozano <[e-mail]<mailto:[e-mail]>>
Date: Friday, 14 December 2012 11:28 AM
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.

JM: My biggest gripe with this is that valid is subjective to the party that has to restore the registry. I say this because different registries have different business rules, or have different interpretations of specifications etc. Verisign's comments on the provreg list about the crID field mirrors exactly that. We (ARI) would expect the crID field to be a registrar id, matching the same definition of client as used in the definition of clID (sponsoring client) and would consider invalid any deposit where the crID is not a registrar. We store the creating user information separate however this is not available through the EPP interface.

I am fairly concerned that introducing this validation seems a somewhat roundabout way at mandating business rules on the registry's provisioning systems. Consider four possible scenarios:

 *   The EBERO compares contact identifiers in a case insensitive manner (lets assume that they store them uppercase), however they receive a deposit from a registry where contact identifiers "abc" and "ABC" match different ROIDs.
 *   The EBERO can store domain passwords up to 16 characters, however they receive a deposit with a password that is 17 characters.
 *   The EBERO requires contact country codes are on the ISO 3166-2 list, however they receive a deposit with a contact having 'xx' or '12' as their country.
 *   The EBERO uses a schema validating parser, however receives a deposit where the contact identifiers "abc def" and "abc  def" (two spaces) match different ROIDs.

I could go on for quite awhile but I hope by now you get my point. If you want to make sure that data is valid then I would much prefer the discussion is about provisioning system requirements and it is made clear that every registry would have to implement these requirements (to the theme of consensus policy or equivalent). As a side note, if you want to go so far as to state all these validations then I would expect to see these requirements somewhere in the EBERO contract.


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.

JM: Fine. I am dubious to what value this provides other than syntactical validation of certain fields (date, phone etc). I could theoretically put "the quick brown fox jumps over the lazy dog" as a domain name and apparently you'd never think this invalid.

The main value is to validate using the schema and extensions specific for that TLD.

The schema validation won't tell us that the content is valid but we will know that the format is correct, the escrow deposit file can be processed and the syntax validations passed.



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

JM: Agree. I see no reason for referenced contact objects to be missing.


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

JM: Disagree. Hosts are required to be objects only for glue records. There is no  reason for the host "ns1.example.com" to be an object in my registry because 1) it cannot have addresses, 2) we do not allow change of host name. A registrar could create the aforementioned host, however they will never be able to do anything with it.

Have you considered that registries may use host attributes instead of host objects? Perhaps those yet unknown SRSU registries may use attributes for simplicity since they have to implement EPP even though there will be only one registrar...

This could be solved with levels of indirection, but if no support for this test is gathered on the list it won't make it to the draft.



 4. All the required glue records are present.

JM: What is a required glue record? If a registrar omits glue address records then the name may not resolve. This is indifferent to the registrar providing the wrong name servers, or failing to supply name servers for delegation when the child zone is "live". Registrars will fix the issue if it is a problem. I disagree with validation of glue records.

This test was a cross match with the DNS zone provided by the registry operator, but if no support for this test is gathered on the list it won't make it to the draft.



 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.

JM: I see no real problem with the above two. I am wary of having too many restrictions that will require changes if and when new allocations are made.


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



JM: This test seems to provide no value, especially given that it should be almost impossible for a registry to have data that would invalidate this test. Testing that the creation date is not later than the last update date makes some sense as it may identify producers that have selected data into the wrong field/element.

Agree with your proposed test.



8. Email addresses are syntactically valid.

JM: Please define the syntax that registries will be held accountable to for validation of email addresses. Note that I do not see anywhere that the registry must validate email addresses (we do not send emails to registrants). Actually, if email data is incorrect then ICANN should be looking at the registrars who provided "invalid" data to the registry.

The idea of this test is to verify that the syntax is correct and not the content.



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.

JM: fine as long as your heuristics are not considered immediate validation failures.

Yes, we will contact the registry operator in order to verify if this was an expected behaviour.



Gustavo Lozano