[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
indigenous polities and constituency politics
This comment proposes some interesting ideas, but fundamentally it confuses the process of *forming constituencies to run the DNSO* with the process of
*setting policy toward new TLDs*. Basically, it proposes to create a new kind of TLD. This is an objective that I strongly support. But the creation of
any kind of new TLD--whether it be a gTLD or an i-TLD (where i = indigenous polities) -- is a policy decision that will have to wait for the DNSO to be
formed. And how will the DNSO be formed, you ask? By creating the so-called constituencies, which will elect people to the Names Council.
Further analysis of this problem underscores why there are serious and disturbing flaws in the idea of running the DNSO on the basis of pretedermined
"constituencies." The constituency model is based on advancing and protecting the interests of EXISTING stakeholders (ccTLDs, Trademark interests,
etc.). Mr. Brunner, on the other hand, is arguing for the interests of a TLD constituency that could and probably should exist, but does not exist yet.
As such, his group has no standing in the DNSO's formation. The constituency model of governance is responsive only to those organized interests that
currently have a foothold in the DNS or in the ICANN process.
That decision, however, seems to have been made already.
Accepting the vicissitudes of practical politics, I would recommend that your group link up with a DNSO constituency that is most likely to be
sensitive and responsive to the needs of your group. To my mind, that would be the so-called "non-commercial domain name holders" constituency. It
appears as if your activities are non-commercial, and it also is pretty clear that that constituency is going to be more hospitable to the kinds of
arguments and claims you are making than, say, the IP constituency or the ccTLD or so-called "gTLD" constituency.
--Milton Mueller
Brunner Eric NRC/Boston wrote:
> For those not on the dnso-ip list, this comment is from Eric Brunner, co-author
> of the comment to WIPO3 submitted from the TribalLaw list.
>
> I recommend ICANN create ab initio a third registry type, one neither associated
> with an iso3166 country code (DIN will not create "country code(s)" for indigenous
> polities, we've already tried that), nor with the existing "generic" registries (we've already tried, as governments, access to the .int registry).
>
> ICANN can create this registry type by simple declaration of intent, with the sets
> of details to be worked out in the reasonable future, and resolve a problem posed
> by the incompleteness of political geography as a model for the DNS namespace,
> both in the historic core of the Internet, the US and Canada, and elsewhere. This is
> an issue which I believe Tribal governments are firmly committed to resolving.
>
> The "New Registry" will allow access to the registry for indigenous polities which
> are claimed by more than one Country. E.g., Jay Treaty Tribes (in both Canada
> and the US) will access the New Registry, as unified polities. Additionally, Tribes
> entirely located within one, or the other of these two geographical constructs now
> associated with ccTLD registries will be allowed access to the "New Registry".
> These same principles apply to indigenous polities and access to this Registry
> in the rest of the Americas.
>
> Thus this Registry will not be "closed" in the usual sense of mutually exclusive
> (Doctrine of Discovery) political jurisdictions, based upon historical colonial
> occupation. This Registry will also not be "open" in the usual sense of no public
> policy goal beyond revenue maximization. Additionally, it will not be in the ccTLD
> nor the gTLD namespaces, as they exist currently.
>
> Assuming the existence a registry which meets broad indigenous requirements,
> minimally allowing indigenous governmental polities and other associations to
> operate independent from the policies of iso3166 registries, I offer my comment
> on the question of registrant access -- the utility of "open or closed" vs "ccTLD or
> gTLD" construction of initial DNSO constituencies, and the comment on the ICANN
> Bylaw changes.
>
> Putting back on my IETF participant hat, the underlying subject matter is registry
> access models, and people posing policy choices should first check that the
> mechanisms exist to instantiate any particular policy. There are only two efforts
> I know of on the subject of registry access mechanisms -- the "shared registry"
> mailing list (ietf-srs@core.nrw.ne) which met as a BOF at IETF-43 and I believe
> will again at IETF-45, and the "shared registration system" project at NSI (Scott
> Hollenbeck, program manager). I doubt that it would be correct to characterize
> either mechanism as limited to supporting either, or even both policy models,
> ("open or closed" vs "ccTLD or gTLD").
>
> Both characterizations appear to require significant hand waving to substitute for
> their sufficiency or necessity, however there appears to be some utility to ICANN
> distinguishing between existing constituancies -- after all, as an IRAC member
> mentioned to me yesterday, California 501(c) boards can be pretty independent.
>
> More fundamentally however, the "open vs closed" construction clearly constrasts
> those registries which are subject primarily to private law (made by a 501(c)) from
> those primarily subject to public law. The first iso3166 regestries operated under
> private law, some variation of the Friends-of-Jon-and-rough-consensus model, and
> some still do. Canada (.CA) was a good example, which recently made the transition
> to a more formal (public law) footing. Not all iso3166 registries are now primarily
> subject to "public law", so the change in characterization offerd to the two existing
> ICANN DNSO constituencies, from one which has a clear meaning within the DNS
> namespace, to one with unclear meaning within the private vs public law space, is
> something I discourage ICANN from.
>
> Kitakitamatsinopowaw, (I'll see you all again)
> Eric