ICANN ICANN Email List Archives

[soac-newgtldapsup-wg]


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

Re: [soac-newgtldapsup-wg] Q&A - RyC and JAS WG - PLEASE REVIEW by Friday May 20

  • To: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Subject: Re: [soac-newgtldapsup-wg] Q&A - RyC and JAS WG - PLEASE REVIEW by Friday May 20
  • From: Elaine Pruis <elaine@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 20 May 2011 06:30:48 -0700


Good point.

On May 19, 2011, at 8:13 PM, Eric Brunner-Williams wrote:


Elaine,

I was off-grid after reading your reminder (which pre-dates my participation in the JAS, so it was more of a "minder" than a "re- minder"), so I thought about it but didn't write a response.

Now I'm back to where there are wires ...

The approach you outline assumes no change in the fee itself, only in the points in time at which portions of it fall due.

As Michele Neylon pointed out, the schedule itself is advantageous to applicants generally, something ICANN staff has attempted to create through their refund schedule for withdrawals at similar points in time.

However, for an application which meets the JAS eligibility criteria, that is, which is made by a community, or ... (our several criteria)

o does the cost of string contention bring any benefit to the applicant?

The SWORD algorithm creates, out of all the strings submitted, zero or more classes of two or more strings that "are in contention".

While the applicant qualification tests currently under consideration by the Working Group do not specifically attempt to determine if any community application meets the criteria which is dispositive, 14 of 16 in the past several versions of the DAG, and I'll check with Olaf Nordling (ICANN Staff) just to be sure this hasn't changed, it is my understanding that an application meeting the eligibility admissions criteria is likely to meet the current string-contention dispositive criteria in the current DAG, or the still someone nebulous but possibly better dispositive criteria the GAC is in the process of proposing.

I don't for a moment assume you or anyone personally agrees, but suppose for this moment that JAS applicants are more likely to prevail over the general applicants in string contention, because of the application of the JAS eligibility criteria.

Are the JAS qualified applicants "benefited" by the cost of the SWORD algorithm?

I think not. To pick an example we all know, the Comoros Islands registry operator is happy with "cm". She or he is indifferent that Verisign was awarded "com", as no substantive confusion exists in the Comoros Island name space users population with "com". Conversely, Verisign would like all strings "confusingly similar" to "com" to be barred by the string contention process outcome, an auction to the right to operate the unique string in the SWORD- defined set of strings that contain "com" which is added to the IANA root.

A prospective users of a community or ... (our several criteria) applicant are unlikely to be confused by other strings that are just "close" in the SWORD algorithmic computational sense to the string that user community chose. Like the .cm name space users, they are not likely to be confused by the existence of a .com name space.

This is a long way of offering the claim that applicants qualified for support under the guidelines we have been entertaining for the past year are benefited less than the general applicant by the cost of string contention -- SWORD development costs and the cost of the actual evaluation.

My point being that I'm glad you brought up the staggered payment schedule, I simply think that the JAS should be pushing ICANN staff to look at the value the JAS-qualified applicants receive at each step of the application process, when setting the base cost to the applicant to progress to that step in the application process, and before the Board makes whatever choices it makes to reduce, or not reduce, the fee to advance its business and geo-political diversity goals.


Eric

Elaine Pruis
VP Client Services
elaine@xxxxxxxxxxxxxxxxxxxx
+1 509 899 3161




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

Privacy Policy | Terms of Service | Cookies Policy