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

[Gustavo Lozano <[e-mail]>]

Christopher,

Comments below.

On 12/14/12 8:07 AM, "Christopher Browne" <[e-mail]> wrote:

>On Thu, Dec 13, 2012 at 7:28 PM, Gustavo Lozano
><[e-mail]> wrote:
>> 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.
>
>In keeping with James Mitchell's comments about "the quick brown fox
>jumps over the lazy dog", which could be set as a domain name, which
>may be "structurally valid," but structurally nonsense, I would
>suggest that mere comparison of escrow deposits is nowhere near
>sufficient.
>
>We could have a near-infinite number of policies, for each bit of the
>escrow format, and someone with a Markov Chain generator could make up
>a conforming escrow file out of random, but still policy-conforming,
>junk.  Verifying that it's not just junk requires looking to other
>sources such as WHOIS or DNS.

GL. The objective of this extended verification procedure is to verify
that the escrow deposit file appears to be consistent.

>
>I daresay I have seen all the cases he mentions as problems, and more.
> Most typical and painful to resolve is to receive phone numbers not
>complying with the ITU E164 standard. My "favourite" was receiving
>contact <contact:id> values that did not conform to RFC 5733, so that
>I had to remap them to new values in multiple places before
>proceeding.
>
>A more legitimate test would be more "end-to-end"; it would compare
>escrow with other notionally authoritative sources.
>
>The approach that comes to mind is to select data from 4 sources and
>make sure that they match:
>
>The data sources:
>
>1.  Escrow is the one that is obviously at hand;
>
>2.  Zone files tend to be not difficult to obtain, and they indicate
>the state of the resolving portions of the 'portfolio' of domains in a
>registry;
>
>3.  WHOIS reports information on the state of the registry, albeit on
>a one-by-one per-request basis;
>
>4.  Submitting DNS requests to the authoritative DNS resolver for the
>registry returns authoritative information on resolution information
>for active domains.
>
>#1 and #2 (perhaps just #1) are available "en masse", for the entire
>registry.
>
>A test that escrow matches against the registry would be to pick a
>sample of domain names from sources 1 (escrow) and 2 (zone file), and
>agree them against WHOIS (#3) and the DNS resolver (#4).
>
>It would not be reasonable to try to do this with all names in the
>registry; a reasonably small statistically random sample should, if
>collected regularly, provide confidence that samples taken from escrow
>match against the "real data" in the registry.  Using stratification
>would be appropriate to make sure that different sorts of cases get
>examined (or perhaps avoided - it's desirable not to have many "false
>mismatches" as would happen when objects legitimately change between
>the time escrow is dumped and when validation tests are done.)

GL. As you mentioned this steps are appropriate for an audit procedure. I
will send your suggestions to the persons involved in the audit process
for new gTLD.


>Over time, a validation involving doing a domain data reconciliation
>of even as small a sample as a few dozen names per day should provide
>useful assurance that the sources are not vastly out of sync,
>particularly if discrepancies get escalated into larger targeted
>samples.  Note that this is the standard sort of thing you'll find in
>literature on auditing procedures.