ICANN ICANN Email List Archives

[soac-mapo]


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

RE: [soac-mapo] A proposal: GLOS

  • To: "Evan Leibovitch" <evan@xxxxxxxxx>, "Stuart Lawley" <stuart@xxxxxxxxxx>
  • Subject: RE: [soac-mapo] A proposal: GLOS
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Wed, 1 Sep 2010 15:41:36 -0400

I have been trying to avoid suggesting possible solutions myself and certainly 
will not push the following but think I will communicate it for group 
consideration and let the group decide whether it has any merit for further 
consideration.

 

First of all let me provide some context.  Thanks to Mark Carvel, I just 
reviewed most of the transcript from the GAC plenary in Brussels on this topic. 
 In it the GAC representative from Greece suggested an approach for GAC 
involvement with regard to sensitive strings.  I am going to describe that 
approach because that is a GAC issue, but it did get my mind going in the 
direction that follows.

 

Guidebook v.4 includes provision regarding community-based gTLDs and government 
related strings.  It seems to me that some of the concerns of sensitive strings 
may already be able to be handled  via the community-based gTLD requirements.  
That would not solve the issues some have for open gTLDs but it possibly could 
cover a subset of them.  Guidebook v.4 requires applicants of community-based 
gTLDs and those applying for government related strings to provide statements 
of support from relevant entities.   What about adding a recommendation in the 
guidebook that encourages applicants to try to assess in advance of applying 
whether or not their desired string might raise objections in certain 
communities or countries and to consult with possible affected parties before 
applying to try to address the concerns and possibly minimize disputes after 
application.  This would not be a complete solution but might help some.  Maybe 
it is common sense that any applicant should do this any way (I would like to 
think so), but it wouldn’t hurt to explicitly encourage it.

 

Another idea would be to encourage applicants who are willing to submit any 
strings that they think might raise sensitivity issues to the GAC in advance of 
application for GAC comment.  If this was done, would the GAC be able to 
respond in a timely fashion?

 

Chuck

 

From: owner-soac-mapo@xxxxxxxxx [mailto:owner-soac-mapo@xxxxxxxxx] On Behalf Of 
Evan Leibovitch
Sent: Wednesday, September 01, 2010 2:26 PM
To: Stuart Lawley
Cc: Avri Doria; soac-mapo
Subject: Re: [soac-mapo] A proposal: GLOS

 

 

On 1 September 2010 12:22, Stuart Lawley <stuart@xxxxxxxxxx> wrote:


A list will not work for the reasons mentioned by Avri.
There is little chance that the list will be inclusive enough to include all 
derivatives and many would be submitters will be too squeamish (understandably) 
to submit many of the outrageous terms linked to subject like Pedophilia etc.


.... but not too sqeamish to be the subject of an $185K TLD proposal?

Nevertheless, it's a reasonable point. Perhaps a window could be offered, just 
in case, that would give objectors a small period of time (say, 30 days) from 
the time an application is made to register appropriate entries in GLOS before 
the report is given to the applicant. This could happen in parallel to other 
early components of the application (such as its checking against the 
Clearinghouse).

This way, objectors would not necessarily have to think of every possible 
disgusting string in advance -- just ones being proposed. It has the downside 
of not letting applicants know in advance all the possible objections to their 
string before they apply -- however they don't know that under the current 
regime either. On the positive side, such a window would also address Avri's 
concerns about the total size of the database getting too big since many orgs 
may simply choose to wait until they see an objectionable application to 
register their objection in GLOS.

- Evan



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

Privacy Policy | Terms of Service | Cookies Policy