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

GA-DIGEST            Friday, March 8 2002            Volume 01 : Number 1068

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

Date: Thu, 07 Mar 2002 17:31:13 -0800
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] If ICANN were to collapse...

Sotiris and all stakeholders or interested parties,

  You make a good point here Sotiris.  And your more than likely
right as well.  But I would say that Verisign benefits more than
any either way.  Verisign has a well entrenched customer
core, and frankly offers the best "Overall" services as it stands
now.  All one has to do is review the Reegistry/Regisstrar
contracts with ICANN as well as the Divestiture of .ORG
and .NET agreement to understand that.

Sotiris Sotiropoulos wrote:

> Who would benefit the most?
>
> My opinion: Verisign.
>
> In Frank Herbert's sci-fi masterpiece "Dune", there is a
> line: "He who controls the spice, controls the Universe."
> "Spice" being a psychoactive natural organic chemical that
> occurs only on one planet in an Imperium of millions of
> solar systems.  This substance "spice melange" heightens
> consciousness and extends life; it is the most precious
> substance in the Universe and it forms the very basis of
> interstellar transportation and communication, as well as
> Universal economy and commerce, similar to the Gold
> Standard. [or Domain Standard?] Yet, the spice involves a
> necessary lifelong addiction, and the price is controlled
> by the Emperor. COM, NET, ORG are the spice melange in the
> Internet Universe, and the single Verisign registry is a
> monopoly like that of the Padishah Emperor Shaddam IV over
> spice production in Herbert's Known Universe.  We [domain
> owners and registrars alike] are at their mercy.
>
> [the above were just some musings for entertainment
> purposes]
>
> :)
>
> --
> Sincerely,
>
> Sotiris Sotiropoulos
>         Hermes Network Inc.
>         Toronto, Canada
>
> ----
> direct: 416.422.1034
>
> icq: 34564103
> --
> 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

Regards,
- --
Jeffrey A. Williams
Spokesman for INEGroup - (Over 121k members/stakeholdes strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-244-3801 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

- --
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, 7 Mar 2002 22:23:23 -0500
From: "Peter de Blanc" <[email-masked]>
Subject: RE: [ga] If ICANN were to collapse...

Very interesting analogy!

I too, have read the "Dune" series, and immediately "zero'd in" or
focussed on the economic model presented by Frank Herbert.

Peter de Blanc

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sotiris
Sotiropoulos
Sent: Wednesday, March 06, 2002 3:14 PM
To: ga
Subject: [ga] If ICANN were to collapse...

Who would benefit the most?

My opinion: Verisign.

In Frank Herbert's sci-fi masterpiece "Dune", there is a
line: "He who controls the spice, controls the Universe."

  (Snip snip snip  as in bandwidth conservation....)

- --
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, 8 Mar 2002 14:08:24 +1100
From: "Patrick Corliss" <[email-masked]>
Subject: Re: [ga] If ICANN were to collapse...

On Wed, 06 Mar 2002 12:13:31 -0800, Sotiris Sotiropoulos wrote:
> In Frank Herbert's sci-fi masterpiece "Dune", there is a
> line: "He who controls the spice, controls the Universe."

On Thu, 7 Mar 2002 22:23:23 -0500, Peter de Blanc wrote:
> Very interesting analogy!
>
> I too, have read the "Dune" series, and immediately "zero'd in" or
> focussed on the economic model presented by Frank Herbert.

Although I dislike "me too" posts, I will make an exception in this case.
Thank you Sotiris, a sharp comment.

Peter.  But have you seen the movie / TV miniseries?  It was on Australian TV
last week.  I only got the promo. All those flashing blue eyes!!!  Marvellous
stuff.

It makes a good sig, too !!

Best regards
Patrick Corliss
"He who controls the spice, controls the Universe"
Frank Herbert, Dune.

- --
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, 08 Mar 2002 17:07:58 +1300
From: Joop Teernstra <[email-masked]>
Subject: Re: [ga] If ICANN were to collapse...

At 12:13 6/03/02 -0800, Sotiris Sotiropoulos wrote:
>Who would benefit the most?

The question "cui bono?" is always a good one to ask.

>My opinion: Verisign.

That could perhaps be 'veri'fied by closely watching the share price, now 
still in the cellar.
An ICANN collapse and a simultaneous VRSN takeoff would make an interesting 
spectacle.

But how about new.net as a direct beneficiary?
How about Microsoft? The other GIP members?
How about the USG? Ambitious US politicians telling the world what they can 
do with their Domains :(

But somehow, I don't think ICANN  will collapse. Version 1.3 will be 
downgraded to V. 2.1 (Lynn's 2.0 is just a kite, IMHO)
It is the DNSO constituency structure that will crack up and go.

(all just 2cts idle speculation)

- --Joop

- --
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, 7 Mar 2002 21:25:41 -0800
From: William X Walsh <[email-masked]>
Subject: Re: [ga] If ICANN were to collapse...

Thursday, Thursday, March 07, 2002, 8:07:58 PM, Joop Teernstra wrote:

> But how about new.net as a direct beneficiary?

I've heard rumors of problems in new.net land.

- -- 
Best regards,
William X Walsh <[email-masked]>
- --

"There is no better way to exercise the imagination than the study of
the law. No artist ever interpreted nature as freely as a lawyer
interprets the truth."
- -- Jean Giradoux

- --
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, 08 Mar 2002 00:12:51 -0800
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] If ICANN were to collapse...

Joop and all assembly members,

Joop Teernstra wrote:

> At 12:13 6/03/02 -0800, Sotiris Sotiropoulos wrote:
> >Who would benefit the most?
>
> The question "cui bono?" is always a good one to ask.

  Indeed it is.  And whom you ask it is also an important factor
as well.

>
>
> >My opinion: Verisign.
>
> That could perhaps be 'veri'fied by closely watching the share price, now
> still in the cellar.
> An ICANN collapse and a simultaneous VRSN takeoff would make an interesting
> spectacle.

  It sure would.  Now that the US economy is on the road to recovery,
you may get that opportunity!  >;)

>
>
> But how about new.net as a direct beneficiary?

  New.net would certainly gain some benefit.  But unless or until
New.Net changes it's marketing approach and method, that
benefit would be limited.

>
> How about Microsoft? The other GIP members?
> How about the USG? Ambitious US politicians telling the world what they can
> do with their Domains :(

  Many NZ and Australian politicians also following the same political
jandra..

>
>
> But somehow, I don't think ICANN  will collapse. Version 1.3 will be
> downgraded to V. 2.1 (Lynn's 2.0 is just a kite, IMHO)

  Downgrade?

>
> It is the DNSO constituency structure that will crack up and go.
>
> (all just 2cts idle speculation)
>
> --Joop
>
> --
> 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

Regards,
- --
Jeffrey A. Williams
Spokesman for INEGroup - (Over 121k members/stakeholdes strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-244-3801 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

- --
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, 08 Mar 2002 09:58:38 +0100
From: Alexander Svensson <[email-masked]>
Subject: [ga] FYI: Staff Draft towards Mission Statement

FYI -- please don't respond with full quotes!
Best regards,
/// Alexander

ICANN Staff Draft: Toward a Statement of the ICANN Mission (7 March 2002)
http://www.icann.org/general/toward-mission-statement-07mar02.htm

[...]

What ICANN Does
Staff Draft - 7 March 2002

OVERVIEW

The Internet Corporation for Assigned Names and Numbers (ICANN) is 
responsible for coordinating the Internet's naming, address allocation, 
and protocol parameter assignment systems. These systems enable globally 
unique and universally interoperable identifiers for benefit of the 
Internet and its users.
These systems are highly distributed: hundreds of registries, 
registrars, and others, located around the world, play essential roles 
in providing naming and address allocation services for the Internet. 
ICANN's paramount concern is the stability of these remarkably robust 
services. 
As overall coordinator of the Internet's systems of unique identifiers, 
ICANN's role, while defined and limited, includes both operational and 
policymaking functions. 

Operations

In the operational sphere, the ICANN staff perform a range of day-to-day 
services, including:
  (1) maintaining the DNS root zone file, 
  (2) allocating top-level blocks of IPv4 and IPv6 addresses and AS 
  numbers to the regional Internet registries, 
  (3) maintaining 120+ registries of protocol port and parameter 
  numbers, 
  (4) publishing online databases of information about the top-level 
  domain registries included in the DNS root zone file, 
  (5) operating one of the thirteen authoritative DNS root name servers, 
  and coordinating the overall DNS root name server system, 
  (6) publishing the InterNIC website and related functions, 
  (7) operating the .int registry, 
  (8) maintaining common/technical IP address spaces, such as the 
  private-use address space, 
  (9) managing the reverse delegation namespace at the top level, and 
  (10) administering the DNS implementations of certain technical 
  registries, such as .arpa and the legacy infrastructure-related .int 
  zones. 

In addition, ICANN staff perform a set of day-to-day administrative and 
policy functions relating to the generic top-level domain (gTLD) 
registries, including:
  (1) accreditation of competitive registrars; 
  (2) supervising the administration of the Uniform Dispute Resolution 
  Policy; 
  (3) handling of complaints about registrations;
  (4) monitoring and enforcement of registry and registrar agreements, 
  and 
  (5) implementation of data escrow programs. 
For the country-code top-level domain (ccTLD) registries, ICANN staff 
handle, investigate, and process requests for delegation and 
redelegation, and for changes in the TLD nameservers specified in the 
root zone file.

Security

Finally, ICANN has the responsibility for policy coordination with 
respect to the security of the various parts of infrastructure that make 
up the operational DNS. This activity is reflected in the recent 
creation of the Standing Committee on Security and Stability. In 
addition, ICANN has certain operational security responsibilities with 
respect to ICANN's operational activities. Finally, ICANN attempts to 
nurture and encourage continuing and serious attention to security and 
stability issues by all participants in the DNS, and to ensure that 
necessary tasks are undertaken by some responsible party. 

Policymaking

In the policymaking sphere, ICANN is responsible for developing and 
implementing policies related to each of its operational functions. The 
nature and scope of ICANN's policymaking role differs for each function.
For example, in the area of IP address and AS number allocation, ICANN's 
responsibility extends only to global addressing policies; local 
policies are made by each regional Internet registry or lower-level 
Internet registries. ICANN's policy role for the country-code top-level 
domain registries (ccTLDs) is similarly limited to global policy 
coordination with deference to each local Internet community's 
responsibility to set its own registry-level policies (i.e., 
registration criteria, pricing, dispute resolution, mechanisms for local 
community participation and policymaking, etc.). In the area of protocol 
numbering, ICANN administers the IANA registries pursuant to the 
instructions of the Internet Engineering Task Force (IETF).
By contrast, ICANN plays a more direct and significant role in setting 
registry-level policies for the global top-level domain registries 
(gTLDs), such as .com, .net, .org, .info, .name, and .biz. In effect, 
ICANN serves as the global Internet community's open policymaking forum 
for the gTLD registries.
In its initial charge from the U.S. Government, embodied in the 1998 
White Paper, ICANN policymaking was to be guided by a set of 
non-technical principles: preserving stability; promoting competition; 
relying where possible on private-sector, bottom-up, participatory 
mechanisms that reflect the functional and geographic diversity of the 
Internet; development of efficient dispute resolution alternatives (for 
the gTLD registries); and promoting accountability in management (for 
all registries).
These principles are necessarily somewhat general, which has led to some 
confusion and disagreement about the exact boundaries of ICANN's 
policymaking mission. This has led some to suggest that those boundaries 
should be restated and described in as much detail as is feasible, 
taking into account the necessary flexibility required to effectively 
deal with the rapidly changing nature of the Internet. Such an effort, 
to the extent it produced useful guidance both for ICANN and the 
Internet community as a whole, would undoubtedly be a helpful 
contribution to the current ICANN reform discussions.
A note on terminology: Historically, most of the operational functions 
described above were performed under the label of the Internet Assigned 
Numbers Authority (IANA). Though administered by a single team at the 
Information Sciences Institute of the University of Southern California, 
the IANA functions were performed at the direction of two sources: the 
IETF and the U.S. Government. Pursuant to an agreement with the U.S. 
Government and a Memorandum of Understanding with the IETF, ICANN is 
currently responsible for the full set of IANA functions. Thus, one 
should keep in mind that IANA refers to a set of functions, and that 
ICANN is the organization designated separately by the U.S. Government 
and the IETF to perform the IANA functions for the benefit of the global 
Internet community.
The following sections describe ICANN's responsibilities and activities 
in greater detail.

I. NAMES

On an operational level, ICANN's Internet naming responsibilities center 
on two functions: the DNS root zone file and the DNS root name server 
system.

A. DNS Root Zone File

The DNS root zone file consists of a list of all top-level domains in 
the authoritative public DNS (currently 259 TLDs), along with the names 
and IP addresses of the primary and secondary name servers that are 
authoritative for each TLD. As part of the IANA functions, ICANN is 
responsible for defining the contents of the DNS root zone file, which 
means maintaining and updating the list of recognized TLDs and the name 
servers for each TLD. ICANN is also responsible for promulgating the 
file for publication by the 13 authoritative root name servers.
The policy tasks related to the root zone file correspond to the three 
basic operational functions required to maintain it: TLD delegation, TLD 
re-delegation, and TLD name server changes. The particular scope of 
ICANN's responsibilities for these functions differs for generic TLDs 
and country-code TLDs, and varies according to the terms of the formal 
registry agreements.
Under ICANN's existing relationship with the U.S. Government, all TLD 
delegation, re-delegation, and name server change requests require the 
final approval of the U.S. Government. Thus, at the moment ICANN's role 
in this regard is limited to making recommendations for changes to the 
US Department of Commerce, which has the operational oversight 
responsibility for the DNS root zone file.

1. gTLD Delegation

The term "delegation" refers to the addition of a new TLD to the DNS. In 
narrow technical terms, this means that a new TLD entry is added to the 
DNS root zone file, along with the names and IP addresses of the 
authoritative name servers for the new TLD. The addition of new gTLDs is 
one of the policy objectives specifically assigned by the U.S. 
Government's White Paper. In November 2000, ICANN selected an initial 
group of seven diverse new generic TLDs (.info,. .biz, .name, .pro, 
.aero, .museum, and .coop) to be added to the DNS as a proof of concept.
The policy tasks necessary to delegate new gTLDs include the preparation 
of a request for proposals, the definition of selection criteria, the 
evaluation of the proposals in light of those criteria, the analysis of 
any public or expert comments, the selection of registries and registry 
operators, and the negotiation of registry agreements (including, as 
appropriate, the documentation of registry policies like pricing, 
registrar competition, dispute resolution, data escrow, and Whois 
service).
Following the launch of a new TLD, ICANN is responsible for the 
monitoring and enforcement of the registry agreement, the implementation 
of data escrow requirements, and, in most cases, the administration of a 
registrar accreditation program.

2. gTLD Re-Delegation

The term "redelegation" refers to a change from one gTLD sponsoring 
organization or manager to another. Once created, a new gTLD is subject 
to potential redelegation if: (a) the sponsoring organization or manager 
voluntarily chooses to abandon the registry; (b) it breaches its 
registry agreement with ICANN; or (c) the term of the current registry 
agreement expires.
For example, the registry agreement for the .org TLD calls for the 
current operator's delegation to terminate by 31 December 2002. ICANN 
thus must undertake a redelegation process that covers the same basic 
elements of the delegation process noted above.

3. gTLD Name Server Changes

On occasion, TLD registries modify one or more of their existing TLD 
name servers. For example, a gTLD name server might change from one ISP 
to another, or might decide to improve overall name resolution 
performance by adding a new name server, or replacing an existing one. 
These changes involve a change request to the IANA, followed by 
verification and implementation procedures, according to the terms of 
the given registry agreement and relevant technical considerations.

4. Monitoring, Enforcement, and Implementation of gTLD Agreements

ICANN is responsible for monitoring and enforcement of the gTLD registry 
agreements, along with certain operational tasks, including the 
accreditation of competitive registrars and implementation of data 
escrow programs. Where there are formal agreements for registration 
accreditation and data escrow, ICANN must also undertake monitoring and 
enforcement of them, along with any related operational tasks, such as 
the verification that any registry data escrowed with ICANN is complete 
and generated in the correct technical format.
As part of monitoring and enforcement, ICANN staff handles complaints 
about registries and registrars, thus seeking to ensure that the 
policies embodied in the agreements are being properly implemented (for 
example, the requirement that registrars provide a free, online, 
query-based Whois service, which provides contact information for gTLD 
domain name registrants).

5. Internationalized Domain Names

As the Internet becomes more accessible to more of the world, and usage 
by non-English speaking populations increases, the need for some 
workable system of internationalized domain names also increases. This 
is both a technical and a policy issue. The technical problem is 
extremely complex, and is the subject of intense activity at the IETF 
aimed at the creation of a workable technical standard. The policy 
issues are similarly complex, as exemplified by the reports of the ICANN 
IDN Committee available on the ICANN website.

6. ccTLD Delegation

Turning to the country-code TLDs, ICANN is responsible for the DNS zone 
file administrative functions of ccTLD delegation, ccTLD re-delegation, 
ccTLD TLD name server changes, and the implementation of ccTLD registry 
agreements (where completed). ICANN policies for ccTLDs are set forth in 
ICP-1, which is an updated description of current practices for the 
implementation of RFC 1591, the 1994 document that sets forth the basic 
IANA principles and policies for TLD structure and delegation.
The term "country-code TLD" is in fact a bit of a misnomer, as a number 
of the two-letter TLDs in that category are not countries. Specifically, 
the term refers to TLDs created on the basis of the ISO 3166-1 table, 
which is the International Standards Organization's list of countries 
and geographically distinct territories together with the unique 2- and 
3-character abbreviations assigned to each. A more accurate term would 
be "geographic TLDs," since this class of TLDs is defined by their 
association with defined geographic units. The ISO 3166-1 table is 
widely used for a variety of purposes, from currency abbreviations in 
the world's banking systems and financial markets to the national origin 
stickers on the backs of automobiles. ICANN relies on the ISO 3166-1 
table both for the determination of whether a given country of 
geographic territory exists and, if so, what two-letter code should be 
used as its TLD label. By relying on this standard, ICANN keeps itself 
out of the business of determining what is and is not a country (or 
geographically distinct territory), and leaves that issue to a 
politically recognized and expert authority.
To date, 245 ccTLDs have been delegated, leaving only two undelegated 
codes. Thus, at this point, ICANN's responsibility for ccTLD delegation 
involves little day-to-day work. The existing undelegated codes - along 
with any new codes that may be added by the ISO 3166 Maintenance Agency 
- - are available for delegation under the terms set forth in ICP-1 and 
RFC 1591. Those documents require that a proposed new ccTLD manager 
demonstrate technical competence, the support of the local Internet 
community in the country or territory to be served, and a commitment to 
accept the basic community service and trusteeship responsibilities that 
lie at the heart of the ccTLD concept.

7. ccTLD Re-Delegation

Far more common than ccTLD delegation matters are requests to ICANN for 
the re-delegation of already-delegated ccTLD registries. Requests for 
redelegation are judged according to the same basic criteria as 
delegation requests, with the focus on technical competence, support 
from the local Internet community, and commitment to accept the 
fundamental public service responsibilities that are inherent in ccTLD 
trusteeship.
The handling of ccTLD redelegation requests requires significant ICANN 
staff work, for reasons that may not be obvious. In some cases, these 
requests arrive with the full support of the existing ccTLD manager; 
more often, however, the requests are submitted without the knowledge or 
with the open opposition of the current ccTLD manager. In all cases, the 
requests must be investigated and evaluated against ICANN's published 
criteria. Under ICP-1, ICANN generally makes re-delegations only with 
the cooperation of the existing ccTLD manager. Where the manager 
disagrees with the proposed re-delegation, IANA policy calls upon the 
disputing parties to engage in cooperative dialogue, together with the 
local Internet community, until a mutually agreeable solution can be 
found. Only in cases of intractable conflict or recurrent technical 
failure by the current manager has the IANA undertaken involuntary 
redelegations.
For all redelegation requests, IANA policy conducts an evaluation of the 
views of the local Internet community, seeking input from affected 
stakeholders and interested parties, including but not limited to 
governments. This investigation and evaluation function is highly 
staff-intensive and can lead to significant delays in the processing of 
re-delegation requests. For major redelegations, ICANN publishes an IANA 
Report detailing the request, its background, the results of its 
investigation, and its conclusions. 

8. ccTLD Name Server Changes

ICANN is responsible for processing ccTLD name server change requests. 
As with redelegation requests, TLD name server changes require a 
surprising amount of staff time and resources. Whenever a ccTLD manager 
wishes to change one or more of its authoritative primary or secondary 
name servers in the DNS root zone file, a name server change template 
must be submitted to ICANN. ICANN reviews the request for completeness, 
and ensures that the proposed change is consistent with published 
standards for TLD name servers, such as the requirement that secondaries 
be placed at both dispersed locations on the Internet, to minimize the 
likelihood of a single failure disabling all of them. ICANN then 
proceeds to verify the request with the delegated administrative and 
technical contacts, to make certain that it does not constitute an 
unauthorized hijacking or stealth relegation of the ccTLD. Once the 
request has been verified, ICANN tests the new name servers to see that 
they are functioning properly, and proceeds to promulgate a new DNS root 
zone file with the updated name server information for the ccTLD.

9. IANA ccTLD Database

ICANN maintains an online IANA database of contact information for each 
ccTLD registry, including the identity of the sponsoring organization 
(meaning designated "trustee" for the ccTLD); the name, physical 
address, e-mail address, and phone and fax numbers for the delegated 
administrative and technical contacts; and the URL for registration 
information. ICANN carefully investigates and verifies requested changes 
to this information to prevent unauthorized hijacking and stealth 
redelegation in violation of the IANA procedures documented in ICP-1 and 
RFC 1591.

B. DNS Root Name Server System

ICANN is responsible for coordinating the stable functioning of the DNS 
root name server system. For top-level resolution of DNS queries, the 
DNS relies upon 13 geographically distributed root name servers 
(identified by letters of the alphabet). There are 12 different root 
name server operators, ranging from universities to military 
institutions to commercial enterprises to not-for-profit organizations 
(such as ICANN). All of the root name server operators are independent 
volunteers, receiving no outside compensation for their services. ICANN 
is responsible for overall coordination of this system, which includes 
day-to-day communication on operations and incident response. Through 
its Root Server System Advisory Committee, ICANN is also responsible for 
developing and implementing policies relating to, for example, the 
distribution, location, and identity of the root name server operators.
ICANN also supports research, measurement, and testing initiatives aimed 
at the overall improvement of the DNS root name server system. For 
example, when planning and implementation testing are complete, ICANN 
will operate a dedicated primary root name server, a significant 
security enhancement that will eliminate the need of the root name 
servers to rely on one of the machines that handles public DNS queries 
to also provide the authoritative version of the root zone file. ICANN 
is also supporting research into the use of IP addressing protocols that 
would allow for a greater number of root name server machines without 
requiring disruptive changes to the existing framework.

C. L Root Name Server

ICANN is the operator of the L root name server, one of the thirteen 
authoritative DNS root name servers. This responsibility is purely 
operational and entails a significant allocation of resources to support 
the necessary technical staffing, hardware, and bandwidth.

D. InterNIC Service

ICANN is responsible for a set of Internet services designated by the 
InterNIC service mark. These include the www.internic.net website, which 
provides information on the gTLD registries, such as a listing of 
accredited registrars and FAQs on dispute resolution.

E. .int Registry

ICANN currently operates the registry for the .int TLD, which is for 
organizations established by international treaty. Historically, the 
.int registry was also used for international Internet 
infrastructure-related uses, such as .ip6.int, which was for a time 
designated as the location of the reverse delegation tree for IPv6 
addresses. In cooperation with the IETF, ICANN is working to transition 
the infrastructure-related domains away from .int into more appropriate 
TLDs, for example the new .ip6.arpa.

II. ADDRESSES

ICANN is responsible for the global allocation of top-level blocks of 
IPv4 and IPv6 addresses and blocks of autonomous system (AS) numbers to 
the recognized regional Internet registries (RIRs), which in turn 
allocate smaller blocks to ISPs and other local Internet registries 
within a particular geographic area. Currently, there are three RIRs 
(APNIC, ARIN, and the RIPE NCC); in the near future, there will likely 
be two more (LACNIC and AfriNIC). In allocating IPv4 addresses and AS 
number blocks, ICANN undertakes careful analysis of RIR requests, 
applying policies of responsible stewardship designed to balance the 
need for conservation with the principle of availability to all who need 
them. In addition, ICANN has responsibilities for the higher levels of 
the DNS reverse delegation tree, and responsibility for maintaining a 
set of common/technical address spaces, such as the private-use address 
space.
Through its Address Supporting Organization, and in close cooperation 
with the regional Internet registries, ICANN is responsible for 
developing global address policies for IP address and AS number 
allocation.

III. PROTOCOLS

ICANN creates, maintains, and disseminates over 120 registries of 
protocol port and parameter numbers and other protocol identifiers. 
Through a memorandum of understanding, ICANN has been designated by the 
Internet Engineering Task Force (IETF) to perform this set of IANA 
functions. ICANN staff do so as directed by the IETF and documented in 
the RFC series, taking guidance from the Internet Engineering Steering 
Group (IESG).
In addition, ICANN is responsible for maintaining the DNS implementation 
of certain Internet infrastructure-related registries, such as .arpa and 
the legacy technical .int domains.

[...]

- --
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, 8 Mar 2002 02:47:11 -0800 (PST)
From: "Karl Auerbach" <[email-masked]>
Subject: Re: [ga] FYI: Staff Draft towards Mission Statement

On Fri, 8 Mar 2002, Alexander Svensson wrote:

> ICANN Staff Draft: Toward a Statement of the ICANN Mission (7 March 2002)
> http://www.icann.org/general/toward-mission-statement-07mar02.htm
...
> What ICANN Does

Which is quite a different matter than what ICANN ought to do.

I won't be nearly as prolix as ICANN's staff.  One could presume that
their salaries are based on the word count of their productions. ;-)

Here's my rather shorter list of things that ICANN ought to do.  Please 
pardon the shorthand form.

		--karl--

1 Allocation of IP addresses

1.1 Is a very complex issue

1.1.1 it is a mix of technical and economic factors and there is very
little understanding of these issues outside of those who are directly
involved in the address allocation or routing systems of the Internet.

1.1.1.1 The economic ramifications are generally under appreciated.

1.2 The most basic goal is adherence to the principles of CIDR.

2 DNS Tasks

2.1 Hint file publication

2.2 Root zone entry admission and maintenance (i.e. who gets an entry in
the root zone and to where should the delegation records point.)

2.3 Periodic root zone file construction, distribution, disaster data
preservation.

2.4 Root server operation (direct or indirect)

2.5 Root server placement (involves question of "anycast" routing
technology.)

2.6 Root zone dissemination

2.7 Failure/error monitoring

2.8 Preservation of historical versions of zone files/delegations.

2.9 Huge open question: To what extent should ICANN reach into TLD
registration systems?

2.9.1 Most basic: escrow/data protection and recovery

2.9.2 Less basic: whois gathering and accuracy

2.9.3 Registry-registrar protocols

2.9.3.1 (Note, registry/registrar model is not only one possible.  E.g. it
is possible to represent domain name "ownership" by a digital certificate
[non-repudiation of transfers requires support from by a transfer agent
[who needs not know the subject matter of the certificate], much like a
"bearer bond".)

2.9.4 Least basic: DNS consumer rights, UDRP

- --
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, 8 Mar 2002 06:32:38 -0500
From: "Peter de Blanc" <[email-masked]>
Subject: RE: [ga] FYI: Staff Draft towards Mission Statement

It is truely amazing that something once  done by volunteers, like
building and co-ordinating the operation of the global Internet prior
to, say 1995 or 1996, now costs over US $ 5 million per year to sustain
a bureaucracy that did not exist prior to commercialization of the
Internet.

What is even MORE amazing is that the US $ 5 million  is just the tip of
the iceberg. Frankly, I do not see the need to pay so much for so
little. Like there is not even a QoS guarantee on the operation of the
root server system. 

Many of my ccTLD colleagues agree with me.

Peter de Blanc 

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karl
Auerbach
Sent: Friday, March 08, 2002 5:47 AM
To: Alexander Svensson
Cc: [email-masked]
Subject: Re: [ga] FYI: Staff Draft towards Mission Statement

On Fri, 8 Mar 2002, Alexander Svensson wrote:

> ICANN Staff Draft: Toward a Statement of the ICANN Mission (7 March 
> 2002) 
> http://www.icann.org/general/toward-mission-statement-07mar02.htm
....
> What ICANN Does

Which is quite a different matter than what ICANN ought to do.

I won't be nearly as prolix as ICANN's staff.  One could presume that
their salaries are based on the word count of their productions. ;-)

Here's my rather shorter list of things that ICANN ought to do.  Please 
pardon the shorthand form.

		--karl--

1 Allocation of IP addresses

1.1 Is a very complex issue

1.1.1 it is a mix of technical and economic factors and there is very
little understanding of these issues outside of those who are directly
involved in the address allocation or routing systems of the Internet.

1.1.1.1 The economic ramifications are generally under appreciated.

1.2 The most basic goal is adherence to the principles of CIDR.

2 DNS Tasks

2.1 Hint file publication

2.2 Root zone entry admission and maintenance (i.e. who gets an entry in
the root zone and to where should the delegation records point.)

2.3 Periodic root zone file construction, distribution, disaster data
preservation.

2.4 Root server operation (direct or indirect)

2.5 Root server placement (involves question of "anycast" routing
technology.)

2.6 Root zone dissemination

2.7 Failure/error monitoring

2.8 Preservation of historical versions of zone files/delegations.

2.9 Huge open question: To what extent should ICANN reach into TLD
registration systems?

2.9.1 Most basic: escrow/data protection and recovery

2.9.2 Less basic: whois gathering and accuracy

2.9.3 Registry-registrar protocols

2.9.3.1 (Note, registry/registrar model is not only one possible.  E.g.
it is possible to represent domain name "ownership" by a digital
certificate [non-repudiation of transfers requires support from by a
transfer agent [who needs not know the subject matter of the
certificate], much like a "bearer bond".)

2.9.4 Least basic: DNS consumer rights, UDRP

- --
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, 8 Mar 2002 08:19:17 -0800
From: Kent Crispin <[email-masked]>
Subject: Re: [ga] FYI: Staff Draft towards Mission Statement

On Fri, Mar 08, 2002 at 06:32:38AM -0500, Peter de Blanc wrote:
> It is truely amazing that something once  done by volunteers, like
> building and co-ordinating the operation of the global Internet prior
> to, say 1995 or 1996,

1) In 95/96 there was a paid IANA staff, though it is true that a lot 
of work was done by people who were paid under rather non-specific 
contracts. 
2) If you actually accounted for the time spent by the volunteers and
paid staff, and paid for it, the amount would have been considerable. 
3) The internet was very much smaller in 1995, no matter how you measure 
it, and was far more US centric than it is now.
4) and moreover: the complexity of the things that IANA/ICANN does don't
scale linearly with the size of the Internet.

> now costs over US $ 5 million per year to sustain
> a bureaucracy that did not exist prior to commercialization of the
> Internet.

The commercialization of the Internet changed things dramatically. 
Comparing things now with the way things were then is worse than useless
- -- it is positively misleading.  An Internet that is a fundamental part
of the infrastructure of global civilization is a vastly different
matter than the garden of eden days of the tiny non-commercial 
academic/government network it used to be.

Moreover, the "bureaucracy" is here largely because of continual demands
by people to expand it. 

> What is even MORE amazing is that the US $ 5 million  is just the tip of
> the iceberg.

No, it is not amazing at all.  If anything, given the demands made on
ICANN, it is amazingly *cheap*.  As an end user, this is working out to
around $.20/domain name per year (3% of the dominant wholesale cost) to
pay for the global coordination functions that ICANN provides.

- -- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain
- --
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 #1068
*************************