On the compulsory vs non-compulsory issue

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Kurt,

My prior notes have concerned issues external to the proposed EOI 
model, the suggestion that trafficing in "slots" has a security and 
stability consequence, the earliest date delegations could occur, and 
reconciliation with the zone file access model.
In this note I address a single aspect of the proposed EOI model, the 
preference for compulsion.
To motivate what follows, a hint that something rather dry is in the 
offing, yet another question about method, suppose that the preference 
is non-compulsory, and that the City of Paris is the sole municipal 
respondent to some EOI from France, and that at some later time, when 
applications are accepted, applications are received from the public 
administrations of Paris, Marseille, Lyon, Lille, Toulouse, Nice, and 
Nantes.
In what way, other than the addition of six applications by public 
administrations, can this even be discerned by the evaluation process?
Unfortunately, that question is not sufficient. To force the 
compulsory preference, the discovery of applications by the public 
administrations of Marseille, Lyon, Lille, Toulouse, Nice, and Nantes 
must result in the failure of the evaluation process. If it does not 
force failure, if the existence of a single application by a municipal 
government, or six, French or otherwise European, not previously 
announced via some expression of interest process, is insufficient to 
cause the entire evaluation process to fail, then the necessity claim 
for the compulsory preference fails.
We can repeat this with regional governmental or cultural and 
linguistic institutional applications.
If the Provincial Government of Quebec and the Regional Council of 
Bretagne, and no other regional governments or cultural and linguistic 
institions participate in some expression of interest process, and 
they and Andean Queche linguistic and cultural institutions, and North 
American Pan-Tribal linguistic and cultural institutions submit 
applications, will the evaluation process, informed only of the 
.quebec and the .bzh interest, fail when in receipt of those 
applications, and applications for .queche and .nai?
We can repeat this for every reasonable type of application, whether 
"community-based" or brought by government or quasi-governmental 
bodies, with the same "not failed" outcome.
I trust that by this point the likelihood that the evaluation process 
we've been working on since the Paris meeting will abruptly fail in 
the presence of a single "unexpressed" application, is evident and so 
unlikely as to make my question appear to be an attempt at humor.
Of course, I didn't write this note for the humorous effect.

As a matter of method, if the purpose of an investigation is 
susceptible to error, then the tools used to conduct the investigation 
must be designed not to introduce error. Conversely, the proposal to 
use a tool which is designed not to introduce error presupposes that 
the purpose of the investigation is susceptible to error, is 
substantially influenced by error.
Restated, the claim of necessity for the use of a perfect data 
collection tool requires that error in the data will cause the 
investigation to fail.
With that rather inelegant statement of the method problem, I suggest 
that there are no issues, no open questions, about the design of, or 
internal staffing, outsourcing, or algorithm selection, in the 
evaluation process described in part in the DAG, which could fail if 
the data provided to them about applications contained error, where 
error is defined to be anything from a typo in an applicant's bank 
reference to the complete absence of all data nominally obtained by 
some expression of interest.
If the evaluation process is not in fact susceptible to error, we must 
look elsewhere for the rational to support the claim that a compulsory 
participation tool is more useful than a non-compulsory participation 
tool, if the evaluation process is as well informed, that is, cannot 
be caused to produce a measurably distinct outcome, by either.
If we cannot find a compelling necessity arising from the design 
information necessary to the evaluation process, for those 
applications which are unlikely to be involved in contention, whether 
because they are community-based, or brought by, or on behalf of, a 
competent public authority, we must, to be honest, conclude that the 
design of the Staff's model is motivated by other requirements.
To put it simpler, as a question of method, the compulsory element 
contained in the Staff's draft model cannot be explained by 
applications for which the uniqueness, and prior authorization, are 
facially evident. It is therefore only explained as accommodation for 
applications which either lack uniqueness, or prior authorization, or 
both, at the expense of applications lacking neither.
With the method observation made, I'll now make a policy comment.

I've pointed out a policy error. It may be correctable, with the 
compulsion to produce data retained for applications brought by 
private parties, though as several have pointed out earlier, closing 
the door to applicants for "generics" before the news that 
applications, or proxies for applications, may be submitted, is 
received outside the ICANN bubble is profoundly problematic.
I am of course, employed by CORE, which has an interest in the
outcome, though as usual, this is offered in my individual capacity.

Cheers,
Eric