ICANN ICANN Email List Archives

[soac-newgtldapsup-wg]


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

Re: [soac-newgtldapsup-wg] soac-newgtldapsup-wg@xxxxxxxxx

  • To: soac-newgtldapsup-wg@xxxxxxxxx
  • Subject: Re: [soac-newgtldapsup-wg] soac-newgtldapsup-wg@xxxxxxxxx
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Thu, 11 Aug 2011 21:55:15 +0100

Hi,

I am sure this does not satisfy Eric's condition, but the fact that the 
supported applicant is more than likely doing a community string should help 
mitigate this in most cases.

While it is not an absolute requirement that support applicants be community 
applicants, I do think it is something to be encouraged, despite the claims by 
many that the game is rigged against the community applicants.

As for modifying the string, I have long argued to this in the general arena of 
the AG, but like others have gotten no where. I am also unconvinced that it 
would necessarily lead to gaming, but while I do not see it as a capability 
that should be necessarily limited to JAS qualified Applicants, this could be 
reasonable as long as the change of name had to be approved by the same panel 
that had approved the the applicant in the first place and that the change 
would be arbitrated by the panel between the applicants - both the qualified 
applicant and the regular applicant.  Or something like that.

Since it is recommended that this support determination review panel have 
masters at gaming detection on it, the likelihood of gaming should be minimized.

a.



On 11 Aug 2011, at 19:05, Krista Papac wrote:

> 
> Eric,
> 
> This is a tough one to solve and I appreciate your efforts to do so. 
> 
> On one hand, we don't want candidates needing support to be limited to 'ugly' 
> and 'unlikely' strings -- yet we also want the funds and non-financial 
> services to go to a TLD that have a likelihood of being awarded. We also 
> won't know what 'pretty' and 'likely' strings will actually be applied for 
> until it's too late, nor how many candidates will apply for support.
> 
> I, unfortunately, don't have any suggestions for solving this problem but I 
> do feel we should afford support qualified candidates a chance at applying 
> for their TLD. Maybe the thing to do is build in a process to "avoid wasting 
> support resources on applications certain to fail" only if the number of 
> support qualified candidates exceeds a certain threshold. We also need to be 
> ensure candidates are educated about the risks associated with 'pretty' and 
> 'likely' strings (i.e., auction) so they are selecting their string(s) 
> carefully and with their eyes open. I would really hate for a support 
> qualified candidate to walk away feeling they were set up to fail because 
> they applied for .POPULAR-STRING. One way this could be accomplished is to 
> require candidates to demonstrate understanding of the New gTLD Program as 
> part of the qualification process. 
> 
> Krista Papac
> Chief Strategy Officer
> AusRegistry Group Pty Ltd
> Email: krista.papac@xxxxxxxxxxxxxxx
> Web: www.ausregistry.com
> -----Original Message-----
> From: owner-soac-newgtldapsup-wg@xxxxxxxxx 
> [mailto:owner-soac-newgtldapsup-wg@xxxxxxxxx] On Behalf Of 
> ebw@xxxxxxxxxxxxxxxxxxxx
> Sent: Wednesday, August 10, 2011 10:58 AM
> To: soac-newgtldapsup-wg@xxxxxxxxx
> Subject: [soac-newgtldapsup-wg] Re: soac-newgtldapsup-wg@xxxxxxxxx
> 
> 
> Colleagues,
> 
> Following up on yesterday's note, staff has maintained that applications
> in a contention set may find alternatives, meaning that cash and equity
> swaps may reduce a contention set from N to 1 prior to any auction. The
> assumption appears to be that each of the N applicants don't know at what
> point in a rising auction the N - 1 other applicants will exit the auction
> and from this lack of knowledge will prefer to bargin to set an agreed on
> "price" for each applicant's equity opportunity in the auction.
> 
> However, if one of the N applicants is is a supported applicant, than the
> other N - 1 applicants do know the point at which the supported applicant
> will exist the auction, and so the equity opportunity of the supported
> applicant is zero, and the fair price to "buy out" the supported applicant
> is also zero.
> 
> So, unlike non-supported applicants, supported applicants which do not
> have auction dispositive status (community type with 14/16 proven or made
> by on on behalf of some public administration for the common name of the
> associated territorial jurisdiction), who's application is determined to
> be in a contention set with at least one other non-supported application,
> can neither benefit in auction outcomes, nor can they benefit in auction
> avoidance outcomes.
> 
> We could, in order to avoid wasting support resources on applications
> certain to fail:
> 
>       o condition support on the applied for string being unlikely
>         to fall in a contention set, e.g., more than 10 Latin, Cyrillic
>         or Arabic script characters, more than 4 Han characters, and
>         not one of the first thousand google-ranked keywords in the
>         script. Support is limited to the ugly and unlikely.
> or
>       o order, or eliminate, support for applications which lack one
>         of the auction dispositive status characteristics, or which
>         meet the prior criteria of being ugly or unlikely. Support is
>         limited to the above plus 14/16 scoring (which we actually can
>         not know in advance) Community Based applications and those
>         made by or on behalf of public administrations for the associated
>         common name.
> or
>       o inform the Board that a mechanism is required to be added to
>         those identified in the DAG to allow supported applicants to
>         obtain one or more strings also sought by unsupported applicants.
> 
> I still don't have a best answer, I'm thinking and writing, comments are
> sought.
> 
> Eric
> 
> 





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

Privacy Policy | Terms of Service | Cookies Policy