ICANN ICANN Email List Archives

[soac-newgtldapsup-wg]


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

Re: [soac-newgtldapsup-wg] WG2-Who

  • To: Tijani BEN JEMAA <tijani.benjemaa@xxxxxxxx>
  • Subject: Re: [soac-newgtldapsup-wg] WG2-Who
  • From: Alex Gakuru <gakuru@xxxxxxxxx>
  • Date: Mon, 7 Jun 2010 20:36:59 +0300

On Mon, Jun 7, 2010 at 8:02 PM, Tijani BEN JEMAA
<tijani.benjemaa@xxxxxxxx>wrote:

>  We will need to consider the string and the applicant.
>
This would therefore imply that we exhaustively pre-define what strings are
acceptable for support deserving applicants? We would need it to avoid
creating/passing that criteria determination to others, after our task is
completed.

>
>  ------------------------------
>
> *De :* owner-soac-newgtldapsup-wg@xxxxxxxxx [mailto:
> owner-soac-newgtldapsup-wg@xxxxxxxxx] *De la part de* Rafik Dammak
> *Envoyé :* dimanche 6 juin 2010 22:27
> *À :* Richard Tindal
> *Cc :* soac-newgtldapsup-wg@xxxxxxxxx
> *Objet :* Re: [soac-newgtldapsup-wg] WG2-Who
>
>
>
> Hello,
>
>
>
> I don't think that we should help for profit applicants in particular for
> generic names, but the board resolution don't make restriction(only stating
> that assistance is toward applicants requests help). The assistance for "for
> profit" applicants may create competition for the shared resources between
> the applicants which we want to assist. maybe we can  make positive
> discrimination for non-profit applicants?
>
>
> in other side, we need to encourage the applicants  to
> have sustainable plan to be economically viable and not being dependent
> to assistance for long-term.
>
>
>
> Rafik
>
>
>
> 2010/6/3 Richard Tindal <richardtindal@xxxxxx>
>
>
> Elaine,
>
> I agree with your note below, however , to reiterate a point I made in a
> note earlier today, I don't think applicants who apply for purely commercial
> strings (e.g. .COFFEE) should receive support.  I think the strings for
> ''our" applicants should be closely reflective of their identity as
> cultural, linguistic, ethnic, religious or other groups.
>
> I understand your point is about the non-profit/ for profit nature of the
> applicant itself  (rather than the string)  but I just want to make sure
> we're on the same page regarding the strings  we support.
>
> Does anyone on the WG disagree with this?  Does anyone feel we should
> support applicants who apply for broadly generic/ commercial strings?
>
> RT
>
>
>
>
> On Jun 2, 2010, at 7:55 PM, Elaine Pruis wrote:
>
> >
> > On the call yesterday Allen talked about an applicant possibly morphing
> from not-for-profit, (or not profitable) to for-profit (or commercially
> viable).  It makes sense that our pool of providers might only be a starting
> point - or stepping stool -  for these applicants.  Possibly these gTLDs
> will grow and become profitable. They could also morph from non-profit to
> for profit.  It makes sense to incentivize potential registry service
> providers with the possibility of our applicants becoming commercially
> successful.
> >
> > A few possible scenarios:
> > 1. A not for profit, non commercial operator needs help with
> infrastructure. They utilize any of the providers willing to provide this
> type of support.  These providers know that supporting this gTLD might
> always be a charitable act.
> >
> > 2. A disadvantaged applicant with a potential commercially viable gTLD
> starts out with one of our providers but as it becomes successful it should
> be able to a) transition to a different registry or  b) stay with the
> initial provider and pay for the services it uses.  I've seen this happen
> several times within the CoCCA framework... a ccTLD operator needs EPP/IPV6,
> so they migrate from their legacy system to the very low cost CoCCA
> infrastructure.  As the TLD grows, the operator is able to contribute much
> more towards the cost of operation, and eventually becomes independent.
> >
> > I don't think our criteria should block for-profit or commercial
> applicants-rather, we can give them a "leg-up".
> >
> > Elaine
> >
> >
>
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr
> Version: 9.0.829 / Base de données virale: 271.1.1/2923 - Date: 06/07/10
> 07:35:00
>


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

Privacy Policy | Terms of Service | Cookies Policy