Re: [soac-mapo] charter and mission

[Richard Tindal <richardtindal@xxxxxx>]

Evan/ Antony,

I think the two approaches you're discussing are similar, in the sense  that 
both of you are leaning away from a very specific description of what's 
unacceptable as both of you are suggesting there should be room for subjective 
decision.

The main difference in your two ideas is that with Evan this decision rests 
with the IO,  whereas with Antony it rests with a relatively large panel.

Is that a fair comment?

RT

 
On Jul 12, 2010, at 12: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
> 
>