ICANN/DNSO
DNSO Mailling lists archives

[nc-org]


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

Re: [nc-org] Unsponsored, Unrestricted


Cary:
Let me respond to one of the meta-points
you make first, and in a subsequent message,
I will go point by point through some of
the detail points.

The key point you make is that we might want
to heed Brett Fausett's advice and allow
applicants to choose their contractual form
(S,R; U,U, etc) and their policies.

I want to make it clear that I oppose this,
rather strongly. But if the rest of the TF strongly 
supported it, I would go along. So LET's hear from
the rest of you, quickly.

Here's why I think it's a bad idea.

The ICANN Board asked the DNSO for answers
to a specific set of questions. Sponsored vs.
unsponsored is one of them. Policy (restriction
or not) is another. To my mind,
leaving unresolved the basic contractual form
would provide both applicants and the ICANN
Board almost no guidance as to what kind of 
applicants we want them to select. It would
be an almost total abdication of our right
and responsibility to initiate policy development
and cultivate a consensus using bottom-up 
methods.

My objection should be clearer by the following
perfectly plausible scenario. Suppose ICANN receives 
4 applications:

1. a proposal calling for a highly restricted,
sponsored org
2. a proposal calling for a totally unrestricted org
run by a wholly commercial operator
3. a proposal similar to the unsponsored, unrestricted
draft I just prepared.
4. another proposal positioned somewhere between 
1 and 3. 

Now, what criteria is the Board supposed to use to 
make a selection? I suggest that insider lobbying,
the Board and manageement's whims, would replace
the policy making apparatus of DNSO. If you think
that is desirable, why bother with the DNSO at all?

Yes, to some extent our policy objectivs are
independent of the labels. But they are not
totally independent. If we want .org to be
mostly unrestricted we should say so. If we want
it to be sponsored and restricted we should say
so. 




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