ICANN/GNSO GNSO Email List Archives


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

Re: [ga] PLEASE COMMENT: Suggested ALAC response to sTLD RFP

  • To: ga@xxxxxxxx
  • Subject: Re: [ga] PLEASE COMMENT: Suggested ALAC response to sTLD RFP
  • From: "J-F C. (Jefsey) Morfin" <jefsey@xxxxxxxxxxxxxxxx>
  • Date: Sun, 07 Sep 2003 15:55:56 +0200
  • In-reply-to: <20030828142018.GL7314@voyager.does-not-exist.org>
  • Sender: owner-ga@xxxxxxxxxxxxxx

Dear Thomas,
I am sorry for this as you obviously put some serious
effort in this ALAC analysis, but it has two basic flaws:

1. it deals with a network system managed by ICANN
    yet it does not refer to the ICANN rules to manage
    its network system.
2. it responds to a demand of ICANN, not of the public
    and @large.

The name space doctrine of ICANN is defined in ICP-3.
Every further discussion should therefore be based
upon ICP-3. ICP-3 refers itself to RFC 920 as the
legitimate root of ICANN's legitimacy.

RFC 920 wording may be deemed obsolete, not its
principles which found the name space for 20 years,
which were consensual at that time, are confirmed
by RFC 1591, ICP-1, proposed ccTLD BP and even
by the RT/BPs we wrote for inclusive roots.

2000's TLDs extensions are odd in many ways, but
it was a first extension in 16 years, and basically
do not hurt that doctrine (except for biz and info),
ICP-3 confirmed afterward.

That doctrine is that:

1.  a TLD is the name of a real or a virtual network
     into the legacy root.

2.  legacy TLDs are registered by the NIC (today
     IANA or ICANN)
     - as per the list of the RFC 920 (the then standard
       international list)
     - for multiorganization groups gathering more
       than 500 regustrants (RDC 920).  i.e. to respond
       and existing need identified either by the Global
       Internet Community.or by a significant community.

3.  a TLD Manager is a trustee to his community and
     its Registry (a task he may delegate). gTLDs are
     under direct control of the NIC, not ccTLD nor
     multiorganization TLD Managers.

4.  the initial interconnects where experimental. ICP-3
     calls for new experimentations and lists their rules
     (non profit, by the GIC, reversible, not endangering
     the DNS operations).

The general idea is that a new TLD should respond to
the need of a significant number of identified registrants
either through non commercial pre-registration/tests or
as 3LD registrants of an existing SLD the GIC would
see an advantage to move into a TLD. In both  cases
the key word is "existing community" whose trustee is
thefuture TLD Manager. Not the other way around.

The only task of ICANN is to respond suich demandes
in making sure there is no challenge to the use of the
chosen name by another group of equivalent size, that
the entry of the name in the root does not create
technical  problems and that RFC 920 and 1591 and
ICP-1 and 3 technical requirements are met.

Everything which goes that way is OK.

Everything else is ICANN mission creep. It is most
probably to the long/medium range detriment of ICANN
and of the network stability because it goes beyond
ICANN legitimacy what will be challenged interests
affected by the decision.

The document you should propose should be a
questionnaire to a candidate TLD community's trustee,
listing all the RFC and ICP resquirments. To publish the
responses and if not challenged in a significant way
(here is where some fair imagination may be exercised)
within three months, the TLD should be entered into
the root.

Since ICANN is a defact o USG Agency, you might be
interested in the procedure of the FCC about filing a new
service or a new rate.


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