ICANN ICANN Email List Archives

[soac-mapo]


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

Re: [soac-mapo] charter and mission

  • To: Jon Nevett <jon@xxxxxxxxxx>
  • Subject: Re: [soac-mapo] charter and mission
  • From: Antony Van Couvering <avc@xxxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 12 Jul 2010 08:56:00 -0400

Thanks Jon you did wonderfully :-)

An IO is one person, hence a lightning rod for conspiracy theories.  Also, one 
person, even of the utmost probity, has biases a broad-based group would not 
(though a group might have other biases).  That's why a panel might work 
better. 

On the other hand, the IO position already exists.  

Sent from my handheld.   

On Jul 12, 2010, at 7:55, Jon Nevett <jon@xxxxxxxxxx> wrote:

>   
> I can't speak for Antony, but I think that the approach he was taking issue 
> with was the one Evan mentions directly below and not the IO process.  If 
> not, I will.  I think that the IO objection process would be easier to 
> implement than a banned list or a pre-application advisory process.  First, a 
> list would require a whole lot of needless debate about names that no one 
> would have applied for during the process.  Second, a pre-application 
> advisory would not be able to take into account the applicant, the string, 
> and the intended use.  If it did, it would give these applicants an unfair 
> advantage over other applicants that might be in a grey area on other issues 
> (e.g. trademarks on the top level, string similarity, etc.).  Finally, we 
> shouldn't be too worried about applicants (and their investors) who apply for 
> a name that they know will be highly controversial.  They obviously will know 
> that going in and there already is a partial refund available in DAG4 if they 
> see that their application got caught up in an objection process and they 
> choose not to proceed. 
> 
> Thanks.
> 
> Jon
> 
> 
>>  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.
> 
> 
> 
> On Jul 12, 2010, at 3:49 AM, Evan Leibovitch wrote:
> 
>> 
>> 
>> On 12 July 2010 03:28, Antony Van Couvering <avc@xxxxxxxxxxxxxxxxxxxx> wrote:
>> 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.
>> 
>> On the contrary, that's the strength of the At-Large proposed approach. By 
>> putting such issues in the hands of the Independent Objector and offering 
>> sufficient leeway, context can matter as much as the literal string itself. 
>> Unanticipated problem applications can be objected to "on behalf of the 
>> public interest" by the IO rather than depending upon some external body 
>> (who? The Boy Scouts? A government? The Catholic Church?) to object to a 
>> NAMBLA-run registry ".boy".
>> 
>> (Of course none of this prevents NAMBLA from purchasing second-level domains 
>> under .boy, but that's a different issue :-P)
>> 
>> Under a similar scenario mentioned in one of the meetings, even everyone's 
>> favourite example of  ".nazi" might be acceptable if it was proposed purely 
>> for academic study. But this, like the NAMBLA one, is a rhetorical device 
>> rather than a real-world proposal that will have to be confronted. That's 
>> the nice thing about having an IO process that's not tightly restricted ... 
>> that when real-world problem applications come up, we have a process 
>> suitably able to deal with it.
>> 
>> (In more recent versions of the DAG, certain undesirable restrictions were 
>> put on the IO that would inhibit the role's effectiveness in performing such 
>> a duty. However we can recommend changes that remove such limitations.)
>> 
>> - Evan
>> 
>> 
> 


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

Privacy Policy | Terms of Service | Cookies Policy