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

GA-DIGEST         Friday, September 27 2002         Volume 01 : Number 1441

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

Date: Thu, 26 Sep 2002 19:18:42 +0200
From: "DNSO Secretariat" <[email-masked]>
Subject: [ga] Alejandro Pisanty elected to ICANN Board

[ To: [email-masked], [email-masked]]
[ To: [email-masked] [email-masked]]

26 September 2002, 

The Names Council noted and confirmed the election of
Alejandro Pisanty from Latin America/Caribbean region,
as the ICANN Board member. 

The full results including individual ballots will be made public
shortly.

The following URLs are related to the ICANN Board Director election
by the DNSO in 2002:
   A. Main document: Description of the election process in 2002
      http://www.dnso.org/elections/2002.DNSO-ICANN-election.html
   B. Procedure for nominations, acceptances and endorsements by the GA,
      and calendar for 2002:
      http://www.dnso.org/elections/2002.DNSO-ICANN-nomination-proc.html
   C. A list of nominations, acceptances and their endorsements:
      http://www.dnso.org/elections/2002.DNSO-ICANN-nominees.html
   D. The NC voting procedure:
      http://www.dnso.org/elections/2002.DNSO-ICANN-voting-proc.html

The NC members verified that the votes cast had been correctly counted.

Glen de Saint Gery
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 19:21:18 +0200
From: "DNSO Secretariat" <[email-masked]>
Subject: [ga] Alejandro Pisanty elected to ICANN Board

[ To: [email-masked], [email-masked]]
[ To: [email-masked] [email-masked]]

26 September 2002, 

The Names Council noted and confirmed the election of
Alejandro Pisanty from Latin America/Caribbean region,
as the ICANN Board member. 

The full results including individual ballots will be made public
shortly.

The following URLs are related to the ICANN Board Director election
by the DNSO in 2002:
   A. Main document: Description of the election process in 2002
      http://www.dnso.org/elections/2002.DNSO-ICANN-election.html
   B. Procedure for nominations, acceptances and endorsements by the GA,
      and calendar for 2002:
      http://www.dnso.org/elections/2002.DNSO-ICANN-nomination-proc.html
   C. A list of nominations, acceptances and their endorsements:
      http://www.dnso.org/elections/2002.DNSO-ICANN-nominees.html
   D. The NC voting procedure:
      http://www.dnso.org/elections/2002.DNSO-ICANN-voting-proc.html

The NC members verified that the votes cast had been correctly counted.

Glen de Saint Gery
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 16:26:55 -0400
From: "John Berryhill Ph.D. J.D." <[email-masked]>
Subject: Re: [ga] FTC Really should take action against ICANN and Neulevel for Failing to provide proper disclosures to consumers

John,

As you know, ICANN will claim that the original .biz was inactive for several
years despite the 1995 creation date.

Hence, it is wholly different from TLDs in the ICANN authorized name space.

You know.  Like .pro

<chuckle>

- --
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 16:08:20 -0500
From: "John Palmer" <[email-masked]>
Subject: Re: [TLDA Public] Re: [ga] FTC Really should take action against ICANN and Neulevel for Failing to provide proper disclosures to consumers

Thats not the point, John. It was inactive for awhile but came back online in Jan/Feb 2002. I remember sitting in a hotel
room in St. Louis (while working onsite at a client's office), talking to Leah for the first time on my cellphone. She had just
re-launched it.

The point is that the FTC makes a big stink about people not giving proper disclosures to consumers.

My point is that these version of the TLDs  ARE different and that ICANN and  its retailers failed to notify all of its customers
that there
was another BIZ out there and that their domains would not be universally resolvable. They didn't do that. Its the
same issue as the FTC raised about TLD Networks (the English group they and the British authorities shut down
in March). If I were TLD Networks - and if I were a ICANN/Neulevel .BIZ registrant - I would be hopping mad
(and many of them are). My suggestion to any of them is to demand a refund from their ICANN registrar if they
want one because, in my opinion,  ICANN, Neulevel and the retailers misrepresented the universality of the visibility
of their version of .BIZ.

It would make an interesting court case, no? We shall see very soon. I know something YOU don't know.....

John

- ----- Original Message -----
From: "John Berryhill Ph.D. J.D." <[email-masked]>
To: "John Palmer" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 26, 2002 15:26
Subject: [TLDA Public] Re: [ga] FTC Really should take action against ICANN and Neulevel for Failing to provide proper disclosures
to consumers

> *****TLDA PUBLIC COMMENTS FORUM*****
>
>
>
> John,
>
> As you know, ICANN will claim that the original .biz was inactive for several
> years despite the 1995 creation date.
>
> Hence, it is wholly different from TLDs in the ICANN authorized name space.
>
> You know.  Like .pro
>
> <chuckle>
>
>
> _______________________________________________
>
> Unless otherwise stated, all comments/postings to this list are the opinions of the individual persons expressing them and do not
neccessarily reflect the official position or opinions of the Top-Level Domain Association, it's Board of Directors, Executive
Management, the various TLDA committees, panels, or other elected officials of the TLDA.
>
> For more information about the TLDA, please visit the TLDA's home page located at http://www.TLDA.org
>
> _______________________________________________
> Public mailing list
> [email-masked]
> http://nomad.tallship.net/mailman/listinfo/public
>

- --
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:09:46 -0700
From: [email-masked]
Subject: Re: [ga] Alejandro Pisanty elected to ICANN Board

I know with the radicals, whom I normally associate with, it is taboo to
endorse and existing member.

But I just think that Alejandro has done an admiral job.
And I would really like it if he replaced that guy that has problems
with
Wordlcom.

Congratulations Sr. Pisanty.

Via con Dios!

Eric

DNSO Secretariat wrote:

> [ To: [email-masked], [email-masked]]
> [ To: [email-masked] [email-masked]]
>
> 26 September 2002,
>
> The Names Council noted and confirmed the election of
> Alejandro Pisanty from Latin America/Caribbean region,
> as the ICANN Board member.
>
> The full results including individual ballots will be made public
> shortly.
>
> The following URLs are related to the ICANN Board Director election
> by the DNSO in 2002:
>    A. Main document: Description of the election process in 2002
>       http://www.dnso.org/elections/2002.DNSO-ICANN-election.html
>    B. Procedure for nominations, acceptances and endorsements by the GA,
>       and calendar for 2002:
>       http://www.dnso.org/elections/2002.DNSO-ICANN-nomination-proc.html
>    C. A list of nominations, acceptances and their endorsements:
>       http://www.dnso.org/elections/2002.DNSO-ICANN-nominees.html
>    D. The NC voting procedure:
>       http://www.dnso.org/elections/2002.DNSO-ICANN-voting-proc.html
>
> The NC members verified that the votes cast had been correctly counted.
>
> Glen de Saint Gery
> 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
- --
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 23:07:32 -0400
From: Leah G <[email-masked]>
Subject: Re: [TLDA Public] Re: [ga] FTC Really should take action against ICANN and Neulevel for Failing to provide proper disclosures to consumers

On Thursday 26 September 2002 05:08 pm, John Palmer wrote:
> *****TLDA PUBLIC COMMENTS FORUM*****
>
>
> Thats not the point, John. It was inactive for awhile but came back online
> in Jan/Feb 2002. I remember sitting in a hotel room in St. Louis (while
> working onsite at a client's office), talking to Leah for the first time on
> my cellphone. She had just re-launched it.

 Just to be crystal clear, the automated web-based registry came back online 
after being down for a while.  However, the TLD / domains never ceased to 
resolve for those in existence since managment changed to ARNI in May, 2000.  
Having an online web-based registration system is incidental as long as the 
registry functions and domains resolve.  Those things have been consistently 
in place.  In that sense, the TLD has not been inactive at all.

Leah

- --
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: Fri, 27 Sep 2002 10:28:17 +1200
From: "Peter Dengate Thrush" <[email-masked]>
Subject: [ga] Re: on politics and trust

- ----- Original Message -----
From: "Jonathan Cohen" <[email-masked]>
To: "Peter Dengate Thrush" <[email-masked]>
Sent: Friday, September 27, 2002 7:41 AM
Subject: RE: on politics and trust

> Thanks,I WILL look into this seriously.
> Jonathan
>

I value this undertaking from you.
To assist, and in case you don't get it from elsewhere, I have pasted below
the response of organisation of Euorpean cc managers, Centr, on this topic.
There are further papers extant and being drafted, but this is the most
recent.

By way of summary for the board, the paper says that the change in policy:
1. contravenes  the policy of delegation of authority, inherent in the DNS
2. uses obsolete procedures
3.involves ICANN in cctld data escrow
4.involves ICANN in a breach of data protection laws
5.would make registry managers liable for damage resulting from ICANN misuse
of data
6.exposes ICANN to local liability laws
7.is in breach of the contract with the USG to run IANA
8. is outside the scope of the MoU.

It also make the general point that its underlying assumption is a crossing
of the line of "coordination" to "responsibility"

In addition to checking the numbered issues above, I'd appreciate your
confirmation, and that of as many board members as will give it, of their
support for the redrafted Mission Statement from the ERC,  visible at
http://www.icann.org/committees/evol-reform/draft-mission-core-values-02sep0
2.htm, and which confirms that ICANN's role is as a "coordinator": viz

"The mission of ICANN is to coordinate the stable and secure operation of
the
   Internet's unique identifier systems. In particular, ICANN:

       a. Coordinates the allocation and assignment of three sets of unique
       identifiers for the Internet; i.e.,

           Domain names (forming a system referred to as "DNS"); "

The role of "coordinator" implicitly recognises that others have rights,
responsibilities and authority. A coordinator is not the superior, governor
or manager of these other entities, which in ICANN s case include cctld
managers, RIR's and root server operators - with none of whom ICANN has
reached a satisfactory relationship. I suggest its because the staff have
misunderstood the role of a coordinator, confusing it with a regulator, a
governor, a monopoly provider or a manager. I'd appreciate confirmation that
this is not a board error.

In reveiwing their position on this, it would also be valuable to the
community for the Board  to endorse Core Value 3 in the Mission Statement.
In performing its mission, ICANN is to:

"3. To the extent feasible and appropriate, delegate coordination
       functions to or recognize the policy role of other responsible
entities that
       reflect the interests of affected parties."

The issues of data privacy, escrow and cctld registry performance are issues
for the cctld registry manager, and the local internet community. Properly
recognised, many of them would be willing for an approved body to coordinate
those activities which would benefit the local and global internet
communities in being coordinated.

Icann needs to establish that it is the body trusted to be that coordinator,
and then to learn how to coordinate.

It is a role which many of us will support and assist with.

My regards

Peter

> -----Original Message-----
> From: Peter Dengate Thrush [mailto:[email-masked]]
> Sent: Thursday, September 26, 2002 2:26 AM
> To: Jonathan Cohen; [email-masked]; [email-masked];
> [email-masked]
> Subject: 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?
>
snip
****************************************************************************
********
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

_______________________________________________
cctld-discuss mailing list
[email-masked]
http://www.wwtld.org/mailman/listinfo/cctld-discuss

- --
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: Fri, 27 Sep 2002 01:34:00 +0200 (CEST)
From: Marc Schneiders <[email-masked]>
Subject: Re: [ga] CENTR Reaction to IANA Zone Access FAQ

On Thu, 26 Sep 2002, at 18:05 [=GMT+0200], Kim Davies wrote:

> These two examples are: checking that domains delegated under the ccTLD
> have at least two name servers,

> 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 requirement was moreover given up in com/net/org years ago. Have the
ccTLDs to bow deeper than the gTLDs for ICANN?

And why is it, that ICANN tries to control those they have no power over,
in matters that are unimportant, while they leave those that they can
control, with whom they have contracts, in serious issues, do it their
way? ICANN is more strict for the ccTLDs (that behave well) than for the
registries and registrars in the gTLDs, where some scandal or scam is
reported each week.

Is it all about _getting_ power?

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

- --
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: Fri, 27 Sep 2002 14:43:03 EDT
From: [email-masked]
Subject: [ga] Council debate on GNSO reform

Dear Joe,

I appreciate the effort that you have made to engage the members of the 
Council in a true debate regarding the course of the proposed GNSO reform 
initiative.  For the first time in quite a long while, the Council is 
actually using their discussion list for the purpose of sustained discourse 
(a few posts) on a topic that affects them all.  This is a very positive 
development, and it points to what might be attainable should the Board or 
Staff choose to regularly involve themselves to some degree in the policy 
assessment process.  

You have essentially put forth the position that the status quo arrangement 
wasn't working, and that in view of this deficiency a change in structure was 
warranted.  Most all would share this view.  However, it should be noted that 
it is generally not prudent to devise a replacement structure without first 
examining the root cause of the deficiencies in the present structure -- one 
would not want to merely export the same set of problems into a new construct.

Let's take a look at some real examples of what occurs in the current process 
(we can even take yesterday's teleconference as a typical example):  

1.  An issue arises in the course of a Council session  (even though everyone 
knew in advance that discussion of the issue was on the agenda and what the 
expected positions of each individual constituency would most likely be, 
there are no prior efforts made to either discuss the issue in a 
cross-constituency forum (such as the General Assembly) or to arrive at any 
compromise through any other means.  Further, the scheduled agenda topic is 
never raised on any constituency discussion list.
2.  Everyone states what they purport their constituency position to be even 
though it was never formally discussed within the constituency, and an 
attempt is made to arrive at high-level language to deal with the situation 
because only some type of fairly useless high-level language has the prospect 
of bringing together those that are still fundamentally at odds with one 
another.  The operative goal seems to be to forge the perception of consensus 
even when none truly exists and, of course, in the absence of any true 
compromise hammered out by the respective parties.  It should be noted that a 
two-hour Council session with no other prior dialogue between the parties 
does not readily allow for the development of any such compromises.
3.  If push comes to shove, and one party does offer to make a concession in 
order to garner the vote of another constituency, the recipient of the offer 
is not prepared to immediately accept and indicates that his/her 
constituency's ratification will be required.  The vote on a resolution is 
postponed pending the requisite feedback.
4.  The representative then requests input from their own constituency.  I 
have seen Ken Stubbs, Paul Kane, Harold Feld and others take such action and 
on almost each such occasion the response is identical - none.  No one at the 
constituency level ever has anything to say on the topic.  
5.  At the next Council session, the representative then claims to have 
received constituency input and proceeds to cast a vote.

The basic problem is this - we have a constituency system in which nothing is 
happening at the constituency level.  There is no discussion, there is no 
analysis, and there are no longer any vehicles by which the average 
constituency member can involve themselves in the process.  

We used to have open Working Groups in which anyone could choose to 
participate.  When we had such groups, the discussion both within the WG list 
and on the constituency lists was lively and led to a thorough review of the 
issue at hand.  What we have now allows for no such broad participation, and 
the consequences of having adopted this closed TF approach are indeed 
self-evident.  

I can well understand, however, the objections of the constituencies to an 
open working group process.  Invariably the working group arrives at 
conclusions that these stakeholders don't necessarily endorse.   There is 
sufficient history to demonstrate that time after time this has been the 
case.  Accordingly, the Council collectively no longer desires to pursue such 
an approach (with the exception of the NCDNHC whose opinions are generally in 
line with working group recommendations).  

So, the first question the Board needs to answer is this:  does the Board 
seek only to continue obtaining the personal views of a very small subset of 
ICANN participants (the current constituency representatives), or do they 
seek to gain the views of all those others that choose to actually involve 
themselves in a thorough discussion of issues within the DNSO?  

The current ERC recommendations seem to favor the former approach instead of 
the latter.  Adding a few Non-Com reps into the process and changing the 
voting structure however will alone accomplish nothing to either help craft 
compromises or to forge consensus - it just changes the final tally of votes, 
and the Board will still be faced with arriving at a determination without 
the benefit of anything more than the meager input that a high-level Council 
recommendation provides.   This type of a reform accomplishes nothing of 
value.  You might as well just send a note to each constituency chair and ask 
them what their view is on a particular topic - it would certainly be more 
efficient.

If, on the other hand, you actually want to receive well-considered advice 
that has been vetted by a discussion in great depth involving a large number 
of interested parties (with the reasonable prospect that over the course of 
time some type of true consensus will emerge), then you need to consider the 
type of reform that truly embraces potential participants.  

In my view, I have only heard lip service being paid to participation.  
Although participation is now the watchword of the day (replacing 
representation), I am not convinced that the Board really desires anyone 
other than current stakeholder representatives to participate.  Of course, 
due diligence will be performed and reasonable notice-and-comment provisions 
will allow for a limited amount of public input, and this might well be what 
the Board currently wants (leaving it in the sole position to decree policy 
in the absence of either significant input or definitive consensus), but does 
the Board really want to continue a status quo that offers it little by way 
of thorough issue/policy analysis?  In the long-term, is this truly in the 
best interest of the Corporation?  

From my vantage point, the Board could benefit from a proper issue analysis 
process that leads to substantive policy recommendations.  What we have at 
the moment, however, makes it clear that Louis Touton alone, in one day, 
could do a better job of drafting an issue analysis than the entirety of the 
Council even if they were given an entire year to accomplish the same task.  

The Board is not getting from these folks what I presume the Board seeks to 
obtain.  This leaves everyone frustrated and fishing for a quick fix.  In the 
meantime, we continue to hear the refrain from constituency reps that they 
are mere "volunteers".  This seems to be the code for "we no longer have a 
commitment to devoting the time necessary to getting any job done that 
doesn't immediately impact our own special interests".  And frankly, this is 
part of the bigger problem.  

When a constituency representative decides that a particular topic is not 
overly germane to the special interest group that they represent, they choose 
not to participate in the task force that examines the issue (often showing 
up only for a final vote after the other few participants finally finish 
their work), and the Board winds up receiving a document that hasn't profited 
from the benefit of a wide range of views or from an in-depth evaluation. 

This is a lousy way of getting the job done.  As I see it, you have three 
choices.  Either you can request additional funding for dedicated staff to do 
the lion's share of the work in preparing a proper issue/policy analysis (so 
that Louis isn't always tasked with the job), or you can open up the process 
to all those others that are currently excluded from participating in any 
meaningful fashion, or you can recognize that the current constituency 
process itself requires a major overhaul and that structural changes at the 
Council level alone are insufficient to accomplish your goals -- a functional 
change is also warranted.  

Personally, I don't think that these constituencies will ever reform 
themselves, or that you will have any luck cajoling them into making 
appropriate changes in the way that they conduct their affairs.  Neither do I 
believe that the current stakeholders will ever be receptive to opening up 
their processes for anything more than sham public participation.  In view of 
these realities, I would argue that it's probably time to pump a lot of money 
into Staff positions so that the Board at least can benefit from somebody 
doing a reasonably proper job of laying out the issues and the policy 
implications.

Do I like this choice?  Not really, but the intransigence on the part of 
these entrenched stakeholders to allow others to participate, and their 
inability to generate participation within their own constituencies, seems to 
make this choice the only remaining tenable option.  Eventually, the 
constituencies might conclude that they don't appreciate the Staff doing the 
bulk of this work (as it makes them largely irrelevant) and might then act to 
finally reform the input process accordingly.    

What I would prefer, of course, is a very different approach to the problem.  
The constituency model hasn't worked, and won't work because quite frankly 
there is no incentive in this environment to achieve a consensus position, 
and neither are there any functional mechanics that will allow for 
compromises to be achieved.  Instead, I prefer to recognize that this is in 
fact the operative reality of the moment, and that rather than trying to 
force an artificial consensus, it is eminently more prudent to simply allow 
all participants in the process to articulate their unfiltered and unmangled 
views directly to the Board where the presence or lack of consensus will be 
determined.  

With this methodology, the workload returns to the constituencies that must 
then independently formulate their own assessment of the issues and their own 
recommendations to solve the problems under consideration.  In turn, this 
means that the constituencies, in order to do a responsible and proper job, 
will turn to their membership for guidance and counsel to a far greater 
degree than has heretofore been possible.  Such an approach would also allow 
the members of the General Assembly to formally tender their views, and would 
also afford the At-large structures a similar opportunity.  

In this scenario, the sole function of the Council would be to function as a 
coordinator that would determine the issues to be evaluated and the timetable 
within which these constituency and non-constituency views would be tendered. 
 I do not view the Council as a policy-recommending institution (it has 
already proven its incapacity for performing that function), but rather as a 
coordinator that allows others in a decentralized fashion to formulate 
recommendations that will independently make their own way to the Board in a 
scheduled and orderly fashion.

Supposedly ICANN is a coordinator.  Why not also have the Council function as 
a coordinator?  Let the work get done at the local level.  Bottom-up by the 
constituencies and others.  The way it should be done.
- --
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 #1441
*************************