ICANN ICANN Email List Archives

[soac-mapo]


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

Re: [soac-mapo] charter and mission

  • To: Evan Leibovitch <evan@xxxxxxxxx>
  • Subject: Re: [soac-mapo] charter and mission
  • From: Antony Van Couvering <avc@xxxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 12 Jul 2010 03:28:17 -0400

The issue with this approach is that the string itself may not be the issue -- 
I would contend that in most cases it would be the combination of the string 
and the applicant.  There is nothing wrong with the string "boy," for instance. 
 But there's a big difference between .boy operated by the Boy Scouts and .boy 
operated by NAMBLA 
(http://en.wikipedia.org/wiki/North_American_Man/Boy_Love_Association).


On Jul 12, 2010, at 1:42 AM, Evan Leibovitch wrote:

> 
> On 11 July 2010 23:49, Richard Tindal <richardtindal@xxxxxx> wrote:
>  
> 
> If I understand you correctly the preferred At Large position is the removal 
> of MAPO provisions from the DAG and a slight expansion of Independent 
> Objector powers to deal with "outrageous (and universally-repugnant)"  
> strings.
> 
> Yes, IIRC. I think we also suggested that some of this could also be handled 
> through the community-objection process, though there was no elaboration.
> 
>  
> Could you take a stab at what sort of guidance language the Independent 
> Objector (IO) might be given to help him/ her make that judgment?   Nothing 
> we'll hold you too here,  but it seems that even with the At Large approach 
> there has to be some sort of articulated standard.    What sort of guidance 
> would the IO be given?
> 
> As it is, the IO appears to be given fairly broad leeway to launch an 
> objection, under the realm of 'protecting the public interest' -- that is, 
> it's possible that a TLD application could meet all the technical 
> requirements but whose existence could still be seen against the public 
> interest based on unforeseen issues. Examples given are a community seeing a 
> TLD created improperly in its name but without enough funds itself to object. 
> Other objections could be in the realms of untraditional forms of "name 
> protection" that go beyond formal trademarks such as Common Law Marks in the 
> Commonwealth and aboriginal "common wisdom".
> 
> So far the flexibility offered the IO falls into the realm of "I'll know it 
> when I see it" kind of judgement, so guidelines appears to have been 
> deliberately loose. We could specifically add a mandate to the IO to object 
> to strings that are considered 
> to be repugnant a "broad community of nations" (using some definition of 
> sufficiently 'broad').
> 
> Let me give it some thought.
> 
> One other option raised during the GAC/At-Large meeting was inspired by the 
> trademark clearinghouse. There could be an advisory process through which TLD 
> applicants would know -- in advance of approval -- whether their string was 
> likely to be blocked by countries once implemented. Based on that advice, a 
> TLD applicant could withdraw or continue, knowing ahead of time that their 
> string could cause problems being seen in some jurisdictions. An advisory 
> process rather than an objection one preserves free expression, while 
> ensuring that applicants (and their investors) are aware of national 
> obstacles that may lie ahead.
>  
> 
> Also,  did At Large suggest what might happen after the IO decided a string 
> was outrageous or universally repugnant?    Did the string then go somewhere 
> else for decision -  and if so who made that decision?
> 
> 
> The idea was to follow the conventional objection process for the IO, without 
> special morality comparisons being made. The main question posed, IIRC, is 
> "does the IO's objection validly affirm that the TLD string's existence harm 
> the global Internet 'public good', its safety or stability? That's a much 
> higher burden of proof  than for the the current MAPO objection, which 
> focuses on the level of insult or objection of the objecting party.
> 
> 
> - Evan
> 
> 



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

Privacy Policy | Terms of Service | Cookies Policy