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