Re: [soac-mapo] charter and mission

[Richard Tindal <richardtindal@xxxxxx>]

I agree with Avri, however I do think the expansiveness of the definition (the 
standard applied) is related to who is making the decision.      

The tighter the standard the more comfortable I am with a smaller group making 
the decision.     The broader the standard the more I want to see a large group 
making it.  

These are really the 2 issues every approach must determine   (actually,  every 
approach except the one proposed by Milton -- which is remove MOPO entirely).

1.     What standard will apply?;

2.     Who will make the decision?

It seems to me 2. is a little easier to decide that 1.      For 2. we could 
have the IO,  a Panel,  a suite of judges (per the DAG) or we could even have 
ICANN SO/ ACs make the decision.   There are pros and cons to each.

For me 1. is harder.   The standard could be very broad (e.g.  'something I 
find objectionable' )  to very specific (e.g.  a list),    or anything in 
between.  

By way of background,   the current DAG has a attempted a sort of hybrid 
standard of specificity.     It has three, fairly specific standards:  (1)  
incitement to violent lawless action  (2) Incitement to or promotion of 
discrimination (race, color, gender, ethnicity, religion, national origin) ; 
and (3) Incitement for child pornography or other sexual abuse of children.     
 I haven't read any deep concerns about these standards.

The fourth standard in the DAG is more expansive though - (4)  contrary to 
norms recognized under principles of international law   (note:  my bold type). 
    This is the DAG standard that seems to be most objectionable to the GAC and 
some others.

RT




On Jul 12, 2010, at 6:51 AM, Avri Doria wrote:

> 
> Hi,
> 
> an intersting idea.
> 
> since an IO already exists, how about an IO with an advisory panel?  This 
> would have difference sorts of specialists, and depending on the kind of 
> string.  Again like a RSTEP.
> 
> I have a problem with the expansiveness of our definitions however. and the 
> fuzzing of the boundary between problems with a string 
> (.burn-a-vampire-today) that is an incitement in itself, and a string 
> (vampirelove) that might contain unsavory and unacceptable content.
> 
> a.
> 
> 
> 
> 
> 
> 
> On 12 Jul 2010, at 08:56, Antony Van Couvering wrote:
> 
>> 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 tha!
 t!
>  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
>>>> 
>>>> 
>>> 
> 
>