ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

Re: [ga] your comments


On Thu, 30 May 2002 15:15:37 -0400, "Joe Sims" <jsims@JonesDay.com>
wrote:
>I appreciate the clarification.  And you have certainly highlighted some
>issues that are important to some people.  The issue of cc's that act like
>gTLDs is a particularly relevant issue; if a cc registry is going to
>aggressively solicit name registrations from people all over the world,
>shouldn't it have to meet the same minimum standards as do gTLDs?  

This is an interesting issue.  First of all I should say that
personally I don't have a lot of time for ccTLDs which market
themselves as gTLDs (.bz for example) but on the other hand I don't
really regard it as my role to tell sovereign governments and the like
what to do.

>Such
>things as escrow requirements to protect against failure, dispute
>resolution procedures or something equivalent to guard against
>cybersquatting, whois systems that actually work so people can find our who
>to contact when an issue arises  -- stuff like this?  

I believe escrow requirements could well fit within that "narrow range
of technical policies" that should be centrally mandated.  However
policies on trademark rights or registrant contact info are not
something that anything short of a UN treaty should be trying to
impose globally.

>It is one thing to
>argue that a ccTLD that restricts registrations to its nationals or
>residents of the country of its charter should have the "right" to do what
>it wants on these points, since those adversely affected always have
>recourse to the national government, local courts, etc.  But when the
>registry decides to take advantage of the stable global DNS to attract
>registrants that, as a practical matter, do not have those protections, and
>can do so only because the rest of the world is working together through
>ICANN to maintain the global infrastructure that permits that behavior,
>that seems to me to be a different situation altogether.  

The notion of dividing ccTLDs up into "locally restricted" and "open"
is one that would have quite dire and unwarranted consequences.
Taking the ccTLD I know best - .nz as an example.  Now .nz does not
have any eligibility restrictions at all - mainly because it would
impose massive extra costs and time delays on the local internet
community if one did this as the registration process could no longer
be fully automated.

So to avoid being classed as an "open" ccTLD subject to gTLD policies,
.nz would have to impose restrictions which would conflict with its
duty under RFC 1591 to serve the local internet community.

Having said that .nz is open, I should point out that .nz does not
promote itself as anything other the country code for New Zealand.  It
spends next to nothing on "brand awareness" and even that minimal
amount may be scrapped.  It does not seek to make money from .nz but
just to provide a effective and efficient service to the internet
community.

So why should policies that work well for the local internet community
have to be scrapped in favour of ICANN imposed ones?  

>As I understand
>the ICANN position, there is no desire to interfere in any way with local
>policy development; that should be up to the local community.  But when the
>registry takes actions that have global implications or effects, it should
>be subject, as are all other similarly situated registries, to the global
>policy development process.  

But how do you define what is local and what is global?  I have
asserted that a split merely upon whether registrations are restricted
to local residents would be unfair.  Judging local vs global on the
basis of how a ccTLD markets itself seems pretty fraught with danger
to me.  What if the registry does not market itself globally,  but
certain registrars choose to market a ccTLD as a generic TLD without
the permission of the registry??

I understand your frustration that there are arguably some two letter
ccTLDs which have all the characteristics of a gTLD and a case exists
for treating them as an gTLD.  But the subjective judgements involved
in which are and which are not, are so great that ccTLDs are not going
to be enthusiastic about "trusting" ICANN to get it right.  A far
better approach would be to encourage ccTLDs which have the
characteristics of gTLDs to see the benefits of adhering to gTLD
policies as a marketing or security exercise?

>What I take from your post is that you want
>someone else to shoulder the burdens of preserving and protecting the
>global DNS that makes it possible for the ccTLDs to function, but to
>basically leave you alone to do with it what you please (although maybe you
>would be willing to contribute to the purely mechanical work of keeping
>your database records straight).  In antitrust economics, this is called
>"free-riding" and is generally not considered something to be admired or
>protected.

I am certainly not going to try and debate US anti-trust law with you
(as I would lose) but I will take issue with your assertion.

First of all from what I can tell the money donated by ccTLDs overall
to ICANN far outweighs any benefits received from it.  As earlier
referred to one would think that as InternetNZ has donated tens of
thousands of dollars to ICANN (and spent even more than that on
participation) that one would at least be able to get ICANN to update
our address without a years delay.

ccTLDs have said they are very willing to donate to a fair share of
the burdens of the global DNS such as the root server network.  And as
you curtly put it database management on top of that.  However
expecting ccTLDs to keep giving money to an organisation so that
organisation can use their own money to try and coerce them into
signing contracts which surrender their policy making authority is
rather naive to say the least.  

DPF
--
david@farrar.com
ICQ 29964527
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



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