ICANN ICANN Email List Archives

[draft-eoi-model]


<<< Chronological Index >>>    <<< Thread Index >>>

On the compulsory vs non-compulsory issue

  • To: draft-eoi-model@xxxxxxxxx
  • Subject: On the compulsory vs non-compulsory issue
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 29 Dec 2009 18:23:12 -0500

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


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy