Re: [ga] Fwd: LACTLD comments on Zone Transfers

["Roberto Gaetano" <ploki_xyz@hotmail.com>]

Jonathan Weinberg wrote:
>
>	I'm impressed by the degree to which everyone has managed to avoid
>talking about the elephant under the bed here.  As the LACTLD message
>below states, and as Karl's message at
><http://www.dnso.org/clubpublic/ga/Arc11/msg00268.html> explains in
>detail, the ICANN position that it needs zone file access "for purposes of
>verifying and ensuring DNS operational stability and performance" seems
>problematic.  On the other hand, I'd guess that zone file access would
>simplify ICANN's task if it chose to redelegate a ccTLD away from an
>operator unhappy with that change.  Anyone want to talk about this
>explicitly?
>

I will give a try.

I doubt that the task of redelegating will be simplified with the copy of 
the zone files, if by this you mean that the zone files will be given to a 
new Registry and they could run the TLD as if they were the old one.
So this is not the purpose, at least in the short term.

What ICANN will achieve if it gets the copy of the zone files is the 
following:
- an element of pressure on the ccTLD (it is in possession of information 
that is relevant for the operations of the TLD, and even if the information 
held will be insufficient for a smooth redelegation it will constitute 
surely a threat)
- a political statement of authority (as already noted by Alex, ICANN will 
make clear who is the master, and ccTLDs cannot claim that ICANN is only a 
"service provider")
- allow the camel to stick its nose under the tent (a precedent will be 
established, and the road is open for ICP-nn that extends the concept, and 
states the "long established policy and practice" that "in the interest of 
the stability of the Internet" complete escrow of all Registry data have to 
be provided to ICANN; somebody might give us a lecture on how this, in 
reality, has always been meant to be part of RFC1590, it just has not been 
clearly spelled out before because the editor made a mistake)

But I would like to highlight a problem on a different level, to explain why 
deNIC (and maybe others) will never give away this information.
The ccTLDs, as they have repeatedly stated, serve their "local community". 
Their legitimation does not come from ICANN.
For good or bad, the principle of having "country" TLDs has been 
established, and in one way or the other the laws of the country hosting the 
ccTLD have to have jurisdiction.
We can debate forever if a government of a country has authority to request, 
for instance, a redelegation of the ccTLD of the country. I personally 
believe it does, but the matter is irrelevant, because given the requirement 
that the contact has be in the country, it is by definition subject to the 
national laws of the country.
All this to say that the local governments have a certain degree of 
authority on the ccTLDs (again, I do believe that they have the ultimate 
authority, but this is irrelevant). Of course, this does not mean that the 
country has direct control or involvment on the operations of the ccTLD, but 
that it has national interests to defend.
Different countries have different "business models", and this is seen in 
other utilities, like water, electricity, telephone, postal service, and so 
on. They might use different approaches (nationalized industry, free 
competition, mixed economy, and what else), but one thing will be the common 
denominator: that it will be decided by them, and not by a private 
corporation in California, what model to use.

Why am I wasting bandwidth with this apparently marginal discussion? Because 
I want to give you the feeling that some ccTLDs will never give up to ICANN 
for the simple reason that their respective governments will not. ICANN is 
not an International Treaty Agency (actually, by any standard of 
"internationalism" ICANN is performing very poorly). Countries have no 
obligation towards it. Moreover, ICANN is directly controlled by one 
country. To give in about this matter is to give away property and control 
from the country that has jurisdiction over the ccTLD to the country that 
has jurisdiction over ICANN. And I can clearly see the reluctance to do so, 
in particular for European ccTLDs.
(incidentally, if the whole matter was regulated by international treaties, 
the situation would be totally different, because ICANN Staff would be 
international civil servants, reporting to the United Nations and not to the 
government of a country, and the transfer of information would be protected 
by international law and not falling under jurisdiction of a country)

The subject of escrow has been brought up by a different post. That reminds 
me the initial meeting with the 5 .com testbed registrars, in Washington DC, 
when Louis Touton announced that one of the conditions was escrow of data to 
ICANN or other trusted third party *in the US*. Two Registrars were 
vehemently opposed, and also Melbourne IT was not happy. After much 
discussion the requirement was watered down (in fact, it is still under 
discussion).
So, in summary, I do believe that the maximum that the ccTLDs could allow, 
in an extreme attempt to allow ICANN to go back without losing face, is a 
similar approach to escrow. Something like to provide the zone files to a 
trusted third party, that could preform the checks ICANN states are required 
for the stability of the Internet, but without releasing the information 
outside the legal jurisdiction of the country. I donīt know if Sabine is 
happy about DENIC making this additional effort (and expense, because I 
assume that the trusted third party has also children to feed), but at least 
Kanzler Schroeder would not oppose it.

Sorry for the length, I got carried on.
Regards
Roberto


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

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