Subject: GA-DIGEST V1 #1440
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST        Thursday, September 26 2002        Volume 01 : Number 1440

----------------------------------------------------------------------

Date: Thu, 26 Sep 2002 03:54:47 -0400
From: Sotiris Sotiropoulos <[email-masked]>
Subject: [ga] .aero 

from: http://nic.aero/dotaeroinbrief.php
".aero is a new Internet domain name (like .com, .net, .org) exclusively 
reserved for the aviation community. "

If that is so, what is the deal with nominalia.aero?  Does their status 
as an .aero registrar exempt them from the above exclusivity 
stipulation?  What about zuckermann.aero then?  Looks like a personal 
homepage...

Sincerely,

Sotiris Sotiropoulos

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 11:11:35 +0000
From: "Roberto Gaetano" <[email-masked]>
Subject: Re: [ga] .aero

Sotiris,
Explanation is at http://nic.aero/registrars.php.
Most of the other Registrars are not in the aviation business either...
Or, alternatively, we can say that registering names in .aero makes you "de 
facto" an operator in the aviation business ;>)
Regards
Roberto

>From: Sotiris Sotiropoulos <[email-masked]>
>To: [email-masked]
>Subject: [ga] .aero Date: Thu, 26 Sep 2002 03:54:47 -0400
>
>from: http://nic.aero/dotaeroinbrief.php
>".aero is a new Internet domain name (like .com, .net, .org) exclusively 
>reserved for the aviation community. "
>
>If that is so, what is the deal with nominalia.aero?  Does their status as 
>an .aero registrar exempt them from the above exclusivity stipulation?  
>What about zuckermann.aero then?  Looks like a personal homepage...
>
>Sincerely,
>
>Sotiris Sotiropoulos
>
>--
>This message was passed to you via the [email-masked] list.
>Send mail to [email-masked] to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 18:26:19 +1200
From: "Peter Dengate Thrush" <[email-masked]>
Subject: [ga] Re: on politics and trust

Hi Jonathan
Thanks.
I assume this relates to ICP-1, and the allegations of changes to policy
without proper processes being followed.
The questions are simple, really.
1. Many people have pointed out that ICP-1 involves a change of policy. The
recent FAQ issued by the staff, one assumes without Board involvement,
contains some further nonsense.
This, despite the time it takes, is being dealt to by experts.

2. The board resolution only adopts the numbering system of ICP-1, not its
contents.

3. The question for the Board to satisfy itself is: do the contents of ICP-1
constitute new policy in any respect? Or, when they were first promulgated,
did they?

4.Knowing when that question is going to be considered by the Board will
ensure that those who argue that it does can place their material before the
board, to assist in answering that question. So far, I assume only staff
information, if any at all, has been provided.

5. If so, the Board is bound to follow the policy development programme of
the bylaws.

6. If not, then a clear statement can issue from the Board, with a right to
seek Review, and ultimately, a prospect of litigation. (You, as a lawyer,
will appreciate the lack of status a staff authored FAQ has in this
context).

7. The underlying question, though, is why is this conducted by the staff in
such an adversarial fashion? Even if the staff are correct -given the hue
and cry which it causes among the very people reluctant to sign contracts
with ICANN, why not put it up as a topic for discussion at a public forum?
Even the FAQ says there has been no even implementation on the point -what
would be lost by a (further) 3 to 6 month debate? What is the cause of this
underlying distrust of open processes? How can the board work to alleviate
that? Why is there no appreciation that Sabine and others are long serving
and responsible managers trusted by the international community, and that
on-side, they would be powerful allies?  Or, is 4 cctld contracts signed
under duress (and possibly voidable as a result) a satisfactory result for 4
years work?

8. I and others have been attempting to frame a place in ICANN for the
ccTLDs. The distrust and antipathy this sort of issue causes sets back that
process by years.

9. I'm not sure what you mean by "ramp the politics down" - what I mean by
"politics" is the making of policy. What I want is for that policy to be
made in a transparent, bottom-up consensus fashion by those affected.
Frankly, I think that kind of politics should be "ramped up"

10. I look forward to you and other board members tackling  these questions.

Regards

Peter Dengate Thrush
Senior Vice Chair
Asia Pacific TLD Association
- ----- Original Message -----
From: "Jonathan Cohen" <[email-masked]>
To: "Peter Dengate Thrush" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 25, 2002 2:46 AM
Subject: RE: on politics and trust

> Peter I sent the letter to you so its in cyberspace somewhere..Who the
heck
> is running the internet anyway?!!(grin).
> I will pose your Questions to the ERC and to other Board members and see
if
> I can get you an answer.
> Jonathan
snip

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 15:08:02 +0200
From: [email-masked]
Subject: Re: [ga] .aero

Roberto,

You are right, authorised .aero registrars have been given the opportunity
to register .aero names as they provide a specific service to the aviation
community. You can look up the list of .aero registrant groups i.e. those
for whom .aero is open here:  http://nic.aero/howtoregister_a.php.

Best regards,

Marie Zitkova
SITA
www.sita.aero
.aero - the domain of aviation

________________________________________________________________________________________

From "Roberto Gaetano" <[email-masked]> on 26 September 2002
11:11:35 AM
To : [email-masked], [email-masked]
Subject : Re: [ga] .aero

Sotiris,
Explanation is at http://nic.aero/registrars.php.
Most of the other Registrars are not in the aviation business either...
Or, alternatively, we can say that registering names in .aero makes you "de
facto" an operator in the aviation business ;>)
Regards
Roberto

>From: Sotiris Sotiropoulos <[email-masked]>
>To: [email-masked]
>Subject: [ga] .aero Date: Thu, 26 Sep 2002 03:54:47 -0400
>
>from: http://nic.aero/dotaeroinbrief.php
>".aero is a new Internet domain name (like .com, .net, .org) exclusively
>reserved for the aviation community. "
>
>If that is so, what is the deal with nominalia.aero?  Does their status as
>an .aero registrar exempt them from the above exclusivity stipulation?
>What about zuckermann.aero then?  Looks like a personal homepage...
>
>Sincerely,
>
>Sotiris Sotiropoulos
>
>--
>This message was passed to you via the [email-masked] list.
>Send mail to [email-masked] to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 14:45:45 +0200
From: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Subject: RE: Long term registrations - Was: RE: [ga] Fwd: LACTLD comments  on Zone Transfers

- --=======1D115F45=======
Content-Type: text/plain; x-avg-checked=avg-ok-3B35218D; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

Dear Steven,
the real issue is the real cost of managing the registry the way you do it.

There is a basic rule when you sell networking: the customer is not the 
user but the one who needs the network to be used (the reason why 
deregulation the way it was carried was an error).

Identify who is the one who needs .nz to operate and charge him for the 
registration costs. He will foot the bill or find a way to get his money 
back. Your only problem is that he does not find a cheaper way to manage 
.nz: you would then be out of business.
jfc

At 01:28 20/09/02, Steven Heath said:

> > On Fri, 20 Sep 2002, Steven Heath wrote:
> >
> > > How would you collect payments/renewals?
>
>On Friday, 20 September 2002 11:00 a.m., Karl Auerbach wrote:
>
> > For some reason folks seem to presume that we need a system
> > in which names are periodically renewed.
>
><info about payment approach removed>
>
>I agree that many different ways exist to charge for service. I also am
>aware of ccTLD's that charge a 'one time fee' approach.
>
>However, most don't. .ca (CIRA) and .nz (InternetNZ) are perfect example's
>of ccTLD's that have gone from a no fee basis (both used volunteer time of
>University staff and systems) to a 'on going fee'.
>
>If as per the original comment of Jonathan Weinberg ICANN (or some other
>body with the same or greater power) were to use a zone file to 'replace' an
>incumbent ccTLD Manager then they would face major issues, one of the
>biggest for the current system is income collection. If this new body wished
>not to charge for further service this would not eliminate the bigger issue
>of how to identify the registrant.
>
>But back to the comments about payments. Back in the early late 80's and
>early 90's I recall reading about the cost of recording usage and then
>collection costs for long distance calls was a huge amount of the actual
>cost of long distance calls. One could say that the equivalent of per minute
>billing in the name space is charging for changes to the registry and
>compared to the 'all you can eat for a year' approach most ccTLD's have now.
>
>Registries do have a high fixed cost, while a one time fee can set to
>recover this fee over the life of the name (or more exact that registrants
>usage of that name). The issue is how do you determine a life of a name?
>
>Do we set it at 10 years?
>Do we set it at 50 years?
>Do we set it at 2 years?
>
>The expected life of the name is one of the major inputs to determine the 1
>time fee the other of course is the operational costs.
>
>Now, Karl comments on a OTF of $25 and "particularly if updates were paid
>for on a per-occurrence fee schedule.".
>
>My opinion is any fee that is based on the registrant, or their agent, being
>charged to update details would result in lower quality of data compared to
>the a fee based on unlimited changes being allowed. Lower quality is not a
>good thing.
>
>Steven Heath
>..nz news & views
>http://radio.weblogs.com/0110729/
>--
>This message was passed to you via the [email-masked] list.
>Send mail to [email-masked] to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/02

- --=======1D115F45=======--

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 08:20:53 -0500
From: Don Brown <[email-masked]>
Subject: Re: [ga] Froomkin's antitrust advice

It was not his credentials or legal acumen which were impeached in
this forum. Rather, it was his position and tactics.

It generally takes more than a CV to earn credibility, particularly
when it has already been lost.

Thursday, September 26, 2002, 1:52:28 AM, [email-masked] <[email-masked]> wrote:
ksc> On Wed, Sep 25, 2002 at 07:54:22PM -0500, Andy Gardner wrote:
>> On Wed, 25 Sep 2002, Joe Sims wrote:
>> 
>>> I suggest that readers take Professor Froomkin's advice on antitrust with a
>>> very large grain of salt; it would be an understatement to say he is not an
>>> antitrust expert.  Any competent antitrust lawyer would tell you that
>> 
>> You're hardly the one to be making a call on competence.

ksc> Joe's Bio from Jones-Day 
ksc> (http://www1.jonesday.com/attorneys/bio.asp?AttorneyID=13072):

ksc>   Joe Sims chairs both the Firm's Technology Issues practice and the
ksc>   Antitrust & Trade Regulation practice.  His practice is concentrated
ksc>   in antitrust and related areas of government regulation and includes
ksc>   litigation, counseling, and agency practice before state and federal
ksc>   courts, antitrust enforcement agencies, and various specialized
ksc>   agencies (e.g., FCC and DOT) where competition policy or antitrust
ksc>   issues arise.  He has especially broad experience in dealing with
ksc>   mergers and acquisitions and with the full range of antitrust issues
ksc>   involving technology, telecommunications, and the electronic media
ksc>   industries.  Representative clients in recent public matters include
ksc>   Abbott Laboratories; AOL Time Warner; Aventis S.A.; Ernst & Young;
ksc>   Internet Corporation for Assigned Names and Numbers (ICANN); Liberty
ksc>   Media; Nextel Communications; Procter & Gamble; R.J.  Reynolds Tobacco
ksc>   Co.; TV Guide, Inc.; Viacom; and The Williams Companies. 

ksc>   Joe is a member of the American Bar Association (Antitrust Law
ksc>   Section, former chair of the Section 1 Committee and the Civil
ksc>   Practice and Procedure Committee; Administrative Law and Regulatory
ksc>   Practice Section; Litigation Section; and Business Law Section, former
ksc>   chair of the Antitrust Law Committee).  He is a Fellow of the American
ksc>   Bar Foundation and a member of The American Law Institute.  He serves
ksc>   on the Executive Committee of the Institute for Law and Technology of
ksc>   the Center for American and International Law. 

ksc>   Joe regularly writes and lectures on antitrust and related subjects. 
ksc>   He is listed in The Best Lawyers in America, in The World's Leading
ksc>   Lawyers, and in various other publications recognizing leading
ksc>   antitrust lawyers in the world.  In 2001, he was included in a listing
ksc>   of the world's top 10 antitrust lawyers by Global Counsel magazine,
ksc>   and in 2000 was one of 15 lawyers recognized as the "Dealmakers of the
ksc>   Year" by The American Lawyer magazine.  He is admitted to practice
ksc>   before the United States Supreme Court and a majority of the federal
ksc>   courts of appeal. 

ksc> --
ksc> This message was passed to you via the [email-masked] list.
ksc> Send mail to [email-masked] to unsubscribe
ksc> ("unsubscribe ga" in the body of the message).
ksc> Archives at http://www.dnso.org/archives.html

- ----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
[email-masked]         http://www.inetconcepts.net
PGP Key ID: 04C99A55              (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
- ----

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 10:24:50 EDT
From: [email-masked]
Subject: [ga] Recent Reform Comments

In comments just recently posted to the ERC Forum, the ISPCP Chairman Tony 
Holmes makes the following statement: "I believe its appropriate to emphasise 
that there's a strong view within the ISPCP that ICANN and the ERC in 
particular are just not listening to the major issues of concern which have 
been raised."
http://forum.icann.org/reform-comments/implementation/msg00028.html

How many times have we heard this refrain from every single representative 
body in the ICANN process?  

Once more, the RIRs have written:  "The RIRs assumed the reform and evolution 
process would be implemented as an open dialog between ICANN and its 
stakeholders.  To date, this has not been the case.  From the perspective of 
the RIRs, the process used by ICANN has been less open and more rigid, with 
little by way of feedback that would be typically associated with a dialog."  
"As an attempt to engage in dialogue with stakeholders in order to reach a 
shared understanding of appropriate and necessary evolution and reform 
measures any objective judgment of the process would conclude that it falls 
far short of an effective, open, inclusive and fair process."
http://forum.icann.org/reform-comments/implementation/msg00020.html

What all of these groups have in common is a profound revulsion toward the 
top-down implementation being forced upon them by the Illusion of Reform 
Committee.  Apparently they have all failed to grasp a key point -- ICANN 
doesn't care.  ICANN will continue to draw from their reserve of hackneyed 
platitudes and will once more proceed to issue statements such as:  "while 
the Blueprint may not satisfy everyone, it provides the right foundation on 
which ICANN can build for the future."  

It matters little to the Board that their "foundation" should be resting upon 
the consent of the governed.  Time after time they have shown complete and 
utter disregard for the community consensus, their decision on WLS being but 
the latest example.  But let them go ahead and build their throne of 
bayonets, the passage of time will prove that they won't be able to sit on it 
for very long.  

The Department of Commerce acknowledged that at the moment, "no obvious 
alternative exists for long-term DNS management", but they also noted that 
"if ICANN does not make significant progress on the transition tasks, 
alternatives will be identified and considered."   I look forward to working 
with others in the community to establish an alternative to ICANN.  The ICANN 
contracts should be re-bid, and another private entity should take over the 
coordination of the DNS.

As long as ICANN seeks to be a commander instead of a coordinator this 
alternative must be pursued.

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 17:00:58 +0200
From: "DNSO Secretariat" <[email-masked]>
Subject: [ga] NC teleconf MP3 recording Sept. 26, 2002

[To: [email-masked]; [email-masked]]
[To: [email-masked]; [email-masked]]

The MP3 recording of the Names Council teleconference September 26, 2002 is
available at
http://www.dnso.org/dnso/mp3/20020926.NCteleconf.mp3

Happy listening!
DNSO Secretariat

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 10:13:33 -0500
From: "Rodrigo  Orenday Serrato" <[email-masked]>
Subject: RE: [ga] .aero

ROBERT

On your comment:

"Or, alternatively, we can say that registering names in .aero makes you "de
facto" an operator in the aviation business ;>)"

I beleive it certainly does not, but it might lead the public to beleive you
are, to their detriment and that of operators in aviation.

My opinion is that enacting new sector-specific gTLDS is of no use at all
unless checks and controls are set in place to prevent persons who are not
engaged in that sector (including registrars) from obtaining a domain in
such gTLDS. Look at the comments on the .int domain in the final report for
WIPO's Second Domain Name Process.

Cheers.

Atentamente, Regards
Rodrigo Orenday Serratos

- -----Mensaje original-----
De: [email-masked] [mailto:[email-masked]]En nombre de Roberto
Gaetano
Enviado el: Jueves, 26 de Septiembre de 2002 06:12 AM
Para: [email-masked]; [email-masked]
Asunto: Re: [ga] .aero

Sotiris,
Explanation is at http://nic.aero/registrars.php.
Most of the other Registrars are not in the aviation business either...
Or, alternatively, we can say that registering names in .aero makes you "de
facto" an operator in the aviation business ;>)
Regards
Roberto

>From: Sotiris Sotiropoulos <[email-masked]>
>To: [email-masked]
>Subject: [ga] .aero Date: Thu, 26 Sep 2002 03:54:47 -0400
>
>from: http://nic.aero/dotaeroinbrief.php
>".aero is a new Internet domain name (like .com, .net, .org) exclusively
>reserved for the aviation community. "
>
>If that is so, what is the deal with nominalia.aero?  Does their status as
>an .aero registrar exempt them from the above exclusivity stipulation?
>What about zuckermann.aero then?  Looks like a personal homepage...
>
>Sincerely,
>
>Sotiris Sotiropoulos
>
>--
>This message was passed to you via the [email-masked] list.
>Send mail to [email-masked] to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 18:05:22 +0200
From: Kim Davies <[email-masked]>
Subject: [ga] CENTR Reaction to IANA Zone Access FAQ

This is our response to the IANA Zone Access FAQ. It is also online
at http://www.centr.org/news/ICANN-Zone-Access-Comments.html
- --kim

                 Draft Comments on ICANN Zone Access Policy

                          CENTR Executive Committee
                              26 September 2002

Historical Background
- ---------------------

Historically, all Internet zones were available to retrieve using the AXFR
protocol without restriction. In earlier name server implementations, in
fact, there was no provision to limit the distribution of zones to a
restricted set of name servers.

As a result of undesirable use of this data, DNS managers requested that
the facility be incorporated into name server software to allow zone
transfers to be limited.

It is now best current practice to limit AXFR access to zone files. This is
not just limited to top level domain zones, but also in universities,
businesses, and other organisations where potentially sensitive information
can be interpreted by allowing the entire zone to be retrieved.

In May 2002, a number of ccTLD Managers moved to reduce their exposure to
problems being experienced by dominant Europe Internet provider KPNQwest.
This included a heavy reliance on ns.eu.net, a secondary name server that
was used by over 60 ccTLDs.

When redelegation requests were sent to IANA, a number of these urgent
requests were not processed. IANA would not allow the redelegations to
proceed unless the TLD name servers were reconfigured to permit zone
transfers to a large IANA network.

CENTR, based upon lengthy discussions involving all ccTLDs in Bucharest,
released a statement on this requirement (see
http://www.centr.org/news/ICANN-AXFR.html)

ICANN, currently responsible for conducting the IANA function, has
responded to the questions and statement in the form of an IANA "Frequently
Asked Questions" document <http://www.iana.org/faqs/tld-zone-access-
faq.htm> which was posted on their website on September 5th.

This document addresses our opinion on the answers given to these
Frequently Asked Questions, and how they impact the initial concerns we
raised with ICANN on this matter in June 2002.

1. Technical Reasons for Zone Access
====================================

ICANN has not, to our knowledge, provided use with a comprehensive list of
the tests IANA conducts on ccTLD zones. Rather it has given two examples on
what zone file access can provide.

These two examples are: checking that domains delegated under the ccTLD
have at least two name servers, and checking that the "master file" meets
the format set out in STD 13.

We believe ICANN does not demonstrate these are technical problems that
either substantially threaten the stability of the Internet, or are in the
province of IANA to monitor and repair.

Two Nameserver Requirement
- --------------------------

ICANN's first technical justification states it plays a role in ensuring
zones on the second level (those delegated underneath ccTLDs) operate at
least two name servers. This policy implies a broad-reaching role for ICANN
to act as the police of the DNS tree. This decision to descend to this
level seems arbitrary. ICANN seems to be expanding its mission to take
responsibility for administration of DNS zones outside their mandate, which
contravenes the principle inherent in the DNS of delegating authority.

The two NS record requirement doesn't take into account modern technical
practices, such as anycast addresses where the number of name servers can
be higher than the number of NS records.

We strongly believe it is not incumbent on IANA to force the two name
server requirement on anyone other than their immediate delegates (i.e.
those listed in the root zone), and therefore they do not need to test this
requirement within TLD zones. They may analyse other zones if they wish,
but this must be on a voluntary basis only.

Checking Zone Syntax
- --------------------

The other technical justification in the FAQ is to test the "master file"
format complies with STD 13 (RFCs 1034 and 1035).

Any such requirement is based on obsolete procedures and practices that are
largely irrelevant in today's Internet.

* Version 9 of BIND (the current standard release) uses a zone file format
  that is in part not in compliance with RFC 1034 and 1035 yet still carries
  out its function appropriately.

* The version of the zone file ICANN would received through a zone transfer
  can materially differ from any original "master file" as it is reprocessed
  through the name server.

* Recent versions of BIND and other name server software will not permit
  syntactic and semantic errors in a zone file to pass.

* Increasingly, name servers can avoid the existence of any such master file.
  Name server responses could be generated, for example, directly out of an
  SQL database where an RFC 1035 type zone file never exists.

* The concept of dynamic DNS means that a master file could realistically
  differ to the data actually being served by the name servers at any given
  time.

In essence, it is simply not necessary for a name server, or ccTLD, to
operate from a STD 13 style master file in order to carry out its function
correctly.

Any argument that IANA must test for these standards is, we believe, based
on false assumptions and is outside IANA's scope.

2. Legal Issues
===============

In addition to the lack of technical argument to justify the need for zone
files, there are a number of legal implications that arise from the zone
transfer policy.

Data Escrow
- -----------

Despite prior assertions to the contrary, ICANN has now stated in this
document that IANA intends to use zone transfers are used as a method for
data escrow.

This policy change is of utmost concern to us. Data security and disaster-
recovery mechanisms are matters of good practice that all ccTLDs should
employ, however it must be using locally developed or tailored policies.

Delicate issues such as data protection laws vary from country to country,
and the appropriate legal and responsible way to manage data must be
determined on a local level. For many ccTLDs it is only appropriate to
provide such data and responsibility to a party in their country (or the
EU) which is subject to the same laws as the ccTLD manager.

Breach of Data Protection Laws
- ------------------------------

It is our considered view that providing zone files to ICANN would
constitute a breach of data protection laws that cover many jurisdictions
within Europe. Although the EC directive 95/46/EC is implemented
differently throughout Europe, the underlying principles are identical.

Protection for Database Compilers
- ---------------------------------

The Directive 96/9/EC of the European Parliament on the legal protection of
databases empowers the creator of any database which requires the
investment of considerable human, technical and financial resources, when
said database can be replicated at considerably less expense.

As registries have a duty as trustees of a database that has been developed
by and for the local community, they have a responsibility to use this
power to protect the database against undesirable use by third parties.

Economically Sensitive Data in Zone Compilations
- ------------------------------------------------

There is potentially sensitive economic information that can be inferred
from the zone data. For example, by ranking domains associated with
particular name servers, one could infer a league-table of ISPs and
registries.  Also, access to the zone could reveal unique information not
available to the public - such as the registration of a domain for a new
unreleased product by a company.

If the registry consented to the release of the zone, which resulted in the
publication of such data, domain name holders could hold the registry
liable for any resulting damages.

Undue Burden on IANA: Disaster Recovery
- ---------------------------------------

ICANN asserts IANA has a role to play in operating a ccTLD in a case of
last resort, and the zones provide them the power to do this.

We believe this places undue burden and liability on IANA that confuses its
key role of technical co-ordination. Operating as a ccTLD Registry, even on
an interim basis, exposes IANA to many undesirable consequences under law -
including exposure to legal liability under the laws of the country the
ccTLD represents.

IANA's role should be strictly defined as a technical co-ordination body,
not as a surrogate ccTLD manager.

Undue Burden on IANA: Generic DNS Monitoring
- --------------------------------------------

IANA's declared role in checking that second level domains have two or more
name servers clearly steps over the separation of authority between the
root zone, and the ccTLD zone. IANA assumes an extra burden and legal
exposure if they their role is to police DNS data outside their specific
mandate of operating the root and ensuring accurate delegations within the
root.

Breach of Contract by ICANN
- ---------------------------

In the contract entered into between ICANN and the United States
<http://www.icann.org/general/iana-contract-09feb00.htm> ICANN undertakes
the following responsibility of

      ...facilitation and coordination of the root zone of the domain name
      system. It includes receiving requests for and making routine updates
      of ccTLD contact and name server information. It also includes
      receiving delegation and redelegation requests, investigating the
      circumstances pertinent to those requests, and reporting on the
      requests. This function, however, does not include authorizing
      modifications, additions, or deletions to the root zone file or
      associated information that constitute delegation or redelegation of
      top-level domains.

In relation to the DNS, the terms "delegation" and "redelegation" are
technical terms referring to the entry (or change of entry) of name server
records, the so called "routine updates of name server information."

It is incumbent upon ICANN on our reading of this contract to fulfil such
requests except those that amount to a reassignment of the ccTLD manager
(i.e. an administrative "redelegation", rather than a technical
redelegation). ICANN is not granted the power to exercise discretion on
fulfilling change requests based on a ccTLD's non-compliance with a zone
transfer requirement.

Furthermore, ICANN is not required in their Memorandum of Understanding
with the US Government, to conduct technical monitoring of other countries.
It is our firm belief that the responsibility for country codes rests
within the country itself.

3. Conclusion
=============

In our original questions to ICANN, we sought a list of the specific tests
conducted by IANA on the zone file. In response, ICANN has identified two
tests that could be conducted on zone files, but has not provided a
specific concrete operating procedure on how zone files are analysed and
remedied under this policy.

Based on what we have learned from the FAQ, there is no convincing case for
the requirement of zone transfers. The technical arguments given do not
hold up to scrutiny, and the questionable impact of non-compliance does not
represent a serious threat to Internet stability.

There are important tests IANA should carry out, such as ensuring that
their delegations in the root zone match the authoritative name server
records in a TLD zone. However, such tests do not require zone transfer
access. Even with this fundamental test open for IANA to monitor at any
time, brief analysis shows many instances of mismatched data. Indeed, as
many as half of the ccTLDs tested recently had problems of this nature.

Fundamentally, ccTLD Managers have a duty of care in administering the data
they hold. This responsibility involves complying with local laws, and
ensuring suitable agreements are in place so that when data is shared it is
used in a responsible and accountable way.

ICANN's demand of providing them unqualified access to the zone file,
without any contract, and without open, established and publicly agreed
policies on exactly how that data may be used, would represent a clear
failure by ccTLDs in their fiduciary duty.

IANA does have a role to play in ensuring that services under their purview
are working correctly, and that delegations are handed off correctly.
However, they are not guardians of the Internet, and each subsequent level
in the DNS must take primary responsibility for how their zones are
operated.

- --
 Kim Davies - Technical Policy Officer
 Council of European National TLD Registries
 direct: +43 662 872563 12; main: +44 1865 332400
 www.centr.org

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 26 Sep 2002 12:01:47 -0500
From: "John Palmer" <[email-masked]>
Subject: [ga] FTC Really should take action against ICANN and Neulevel for Failing to provide proper disclosures to consumers

I get two of three of these a week. The FTC really ought to take action against ICANN and Neulevel
for failing to require their retailers to disclose to the public that their version of .BIZ is a collider and is
not universally visible. There are so many hucksters out on the internet these days, you know :-)

- -- Reply to email sent to info at adns dot net---

There isnt any problem here on our end.

You see, there are two different versions of .BIZ - the original one and the colliding one that ICANN created.

Each version of .BIZ has different registrants in it.

The fact that your traceroute shows 199.5.157.11 as an address for your .BIZ says 2 things:

1. That no one has goldenpark.biz registered in the original version of .BIZ, which means you must
have registered your .BIZ in the colliding (ICANN/Neulevel) version.

2. That whatever machine that you are using to do the traceroute is using an Inclusive Namespace
nameserver that recognized the original and authentic version of .BIZ and not the pretender
version that ICANN and Neulevel created.

The only thing I can tell you now is to check your name servers and make sure you are using
nameservers which point to the ICANN/USG root. Of course, this will shut you off from the thousands of other toplevel
domains that exist out there, but such is the mess that ICANN created.

199.5.157.11 is the address of the catchall website for any non-registered .BIZ domains in the original
version of .BIZ. It will also catch any queries for websites that don't yet have A-Records.  You can't ping
or traceroute because we disallow that traffic onto our network. You can however, put 199.5.157.11 in
your browser.

I don't know what to tell you, except that ICANN/Neulevel sold you a "Bill of Goods" if they represented to
you that your domain would be universally visible since they knowingly created a duplicate version of .BIZ and
they knew that the Inclusive Namespace, used by up to 30% of the internet, would not be able to see any domains
registered in their version of .BIZ. The Original and Authentic version of .BIZ existed long before they created
a duplicate (since 1995, to be exact). I suggest you ask your registrar for your money back and file a complaint
with the FTC (www.ftc.gov).

FYI: Due to the problems that the duplication is causing, the operators of the original .BIZ will close it down
once all of the registrations in it expire (in several years). Your problem will then go away, because there will only be one
version of .BIZ. This will take us back to the stable state of affairs that occurred before ICANN broke the internet.

John Palmer
ADNS Customer Service.
- ----- Original Message -----
From: "Irate website operator" [email-masked]
To: <[email-masked]>
Sent: Thursday, September 26, 2002 10:54
Subject: technical help needed asap!!

>
> Hello!
>
> I have a web site hosted by BellSouth.net - and registered as DOMAINNAMEDELETED.BIZ - which I beleive
your company has registered.  As we try to access this site from any ISP other than BellSouth, we are getting an error
message that this domain name is not registered.A trace route of the problem showed that our "hops" are stopping at
AGN Domain Name Services, directly before the last stop at BellSouth.net.  Apparently, there is an issue there we
need help with!!  I've contacted our ISP, and they were able to tell me that the issue is outside of their network, and stops at
AGN.
>
> I originally registered this domain name with a 3 or 5 year term (registered about a year ago) - please ensure that I am still
active and call me to help resolve this issue ASAP!!  Our business at DELETED is really on hold until our web site is back up
and running!!   THANK YOU!!!
>
> Copy of trace route info:

etc . etc . etc.

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

End of GA-DIGEST V1 #1440
*************************