[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [wg-c] Please Explain "No on 1, Yes on 2" (More)
I did an abstain/no vote/whatever (hey, Eric picked it as a "a" instead of
"A" :-) ) because I think that mixing gTLDs and chartered/limited TLDs is
mixing apples an oranges. If things are sorted out for both types at the
same time, then fine for adding whatever, but if concerns on the chartered
side are not ironed out, why block the generic side, and vice-versa.
The concerns and issues to be dealt with are VERY different in both cases
(although they have many TECHNICAL similarities).
-they are both strings of characters that would be entered in the legacy roots
-in both cases there will be an entity running a database that generates the
-in both cases there will (presumably) be multiple secondaries located in
different geographic areas for resilience.
-both will have SLDs visible under them.
(further technical requirements imposed on the entities maintaining the
database may be common sense, o BCP).
Unfortunately, apart from those generalities, I feel that it ends there.
The idea many of us in this WG (certainly not all) have of a gTLD is an
unrestricted TLD open to registration to all those who wish to register in
it through some sort of registrar facility (which many argue to keep
separate from the registry so as to allow multiple choice), with no
limitations (other than technical) on the choice of characters for the SLD,
with a pricing cheme which is dependent on the value-added services that one
may (or not) be getting packaged along together with that name (which, as
the additional services are NOT strictly linked to the registry operations,
is why we argue for separate cost-recovery no-frills backend registry
operations). Stability of these generic TLDs should not be in the hands of
the entity doing the backend registry operations (which will probably be some
sort of service company trying to make a profit running these services), but
in the hands of some entity higher up in the food chain, which as we have it
would be ICANN. The entity running the backend registry owes allegiance to
itself, and noone else, so it would just be looking at how to maximise it's
profits, not through streamlining its operations, but by raising tariffs as
far as it could go, without killing off the cashflow (if by doubling tariffs
you lose just 25% of your customers, it certainly makes sense -at least to me-
to double your tariffs, as your cashflow would be increased by 50%, and your
profits by more than that -the extra 100% is PURE profit-).
Issues to be resolved are precisely the confirmation (or denial) of much
which I mention above. Things like:
-Is the registry to be run on a cost-recovery basis? (which doesn't preclude
a for-profit company bidding to win a tender to run it and making a profit
out of that).
-Are registry/registrar functions forced to be kept separate? If so, are the
registry-registrar interface specs something that the registry entity
decides, or the registrar entity, or mandated by ICANN to use an open
-Is ICANN the ultimate authority on how/who/what are operations for a gTLD?
(like who runs them, and being able to decide to redelegate)
-How and who to decide which are the strings that constitute a gTLD? (first
choose registry and let it choose what it wants? Somehow draw up a list of
a bunch of gTLDs that some sort of consensus is given about them being a
good idea in a generic way to become gTLDs? Allow ICANN to "dictate" new
gTLDs with no community input?...)
Once those issues are resolved, presto we have everything we need to go
ahead (these ARE the issues we've been arguing over for the past few years)
On the other hand, for chartered TLDs, these are (in some ways) very similar
to ccTLDs, in that a homogeneous community is identified that wishes to have
a TLD (the community of museums, or of american indigenous people, or of ham
radio operators...), and therefore responsability for that TLD is
transferred to this community. All operations, pricing, registrar-registry
structure, profit or not, would be completely up to that community. After
all, it is THEIR TLD (and therefore, THEIR PROBLEM), as with ccTLDs...
The issue to be resolved before delegating chartered TLDs are completely
orthogonal to those for delegating generic TLDs:
-Is there really a justification for creating a TLD for this specific
community (some may argue that this is also an issue with generic TLDs)?
-Who decides what constitutes a community? (we could argue that ccTLDs are
chartered TLDs, in which the charter for creation is that they have to be in
ISO-3166, and from there they get delegated to the country -or whoever shows
up from that country/territory-).
-Is the entity requesting the delegation in the name of that community
representative of that community?
-Is there consensus within that community for this entity?
As you can see, I feel that the issues are VERY different (some may disagree
and take the stance that a TLD is just a bunch of characters and there is no
difference between .com, .mil, .fr and .to but we would just have to agree
to disagree there).
This is why I personally declined to answer in favour or not of bundling
chartered TLDs and generic TLDs in the first rollout. If I think a little
further (and if I am permitted to change my vote) I actually vote NO to
bunching them together, because the issues are so different, that they won't
necessarily be resolved simultaneously, and therefore delays in defining one
shouldn't hinder the other.
Yours, John Broomfield.
> Bret A. Fausett wrote:
> > Or is the "No" on #1 based on the concern that there are too few gTLDs to be
> > implemented? too many?
> Just for clarification, I didn't misread the question -- but I did read some
> votes against #1 (when coupled with a vote for #2) as a vote revisiting the
> 6-10 question. In my mind, affirmation of the S/K principles assumes a
> multiplicity of TLD models, "from open TLDs to restricted TLDs with more
> limited scope." But perhaps others read them differently.
> So I would also ask, does N/Y/x mean that one supports 6-10 new gTLDs
> meeting the S/K principles that but one hopes that they are all open gTLDs,
> all closed gTLDs? If so, that seems a poor test of the S/K principles
> themselves. Why am I wrong?
> -- Bret