Re: [soac-mapo] charter and mission

[Antony Van Couvering <avc@xxxxxxxxxxxxxxxxxxxx>]

I think the major problem with a list is that it will be very hard to get 
anything off of it.   The temptation will be to add anything that might be 
considered "dirty" in any language.

Another issue with lists is false positives, esp. where the forbidden word is 
hidden in a longer string.   Can you spot the dirty word in "yankeeshitters"?  
(That's a baseball allusion for all you non-US-sports people.) 

Finally, as I've mentioned, the issue is apt to be with the application (i.e., 
the combination of string + applicant), and not just the string itself. 

I think a list is a very poor solution.

Antony


On Jul 12, 2010, at 12:38 PM, Richard Tindal wrote:

> 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
>> 
>> 
>> 
>> 
>