ICANN ICANN Email List Archives

[soac-mapo]


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

Re: [soac-mapo] charter and mission

  • To: soac-mapo@xxxxxxxxx
  • Subject: Re: [soac-mapo] charter and mission
  • From: Richard Tindal <richardtindal@xxxxxx>
  • Date: Mon, 12 Jul 2010 12:38:42 -0700

i agree with Graham about the practical problems of a list approach.

Looking back on the dialogues in Brussels,  there were various GAC members who 
agreed that a list had issues

When it was discussed they were OK with it -- as long as there was a 
supplementary method of challenging strings not on the list.   

RT




On Jul 12, 2010, at 12:28 PM, Graham Chynoweth wrote:

> In addition to the concerns with the banned list Jon notes below, I would add 
> such a list would, overtime, certainly become both over and under-inclusive 
> (if it wasn't from the outset).  More specifically on this point I mean that, 
> if there ever were a 'seven dirty words' style list, eventually that list 
> would come to include words that were no longer 'dirty' (e.g., as George 
> Carlin taught us, it used to be that you couldn't say 'piss' on American 
> television) and not include words that had become 'dirty' (I'll let you use 
> your imagination here).
> 
> Thanks,
> Gray
> 
> Graham H. Chynoweth
> General Counsel & VP, Business Operations
> Dynamic Network Services, Inc.
> 1230 Elm Street, 5th Floor
> Manchester, NH 03101
> (p) +1.603.296.1515
> (e) gchynoweth@xxxxxxx
> (w) http://www.dyn.com
> 
> Confidentiality Statement
> 
> Privileged and Confidential. The information contained in this electronic 
> message and any attachments to this message are intended for the exclusive 
> use of the addressee(s) and may contain confidential or privileged 
> information. If you are not the intended recipient, please notify Dynamic 
> Network Services, Inc. immediately at +1.603.668.4998 or reply to 
> gchynoweth@xxxxxxx and destroy all copies of this message and any 
> attachments. This message is not intended as an electronic signature.
> 
> 
> ----- Original Message -----
> From: "Jon Nevett" <jon@xxxxxxxxxx>
> To: "Evan Leibovitch" <evan@xxxxxxxxx>
> Cc: "Antony Van Couvering" <avc@xxxxxxxxxxxxxxxxxxxx>, "Richard Tindal" 
> <richardtindal@xxxxxx>, soac-mapo@xxxxxxxxx
> Sent: Monday, July 12, 2010 7:55:36 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [soac-mapo] charter and mission
> 
>   
> 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