ICANN/DNSO
DNSO Mailling lists archives

[ga-full]


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

[ga] CNSO


Danny rises the question of the very nature of the ICANN namespace and 
who/how to manage it. I think we can review it seriously and positively.

I keep harping on the history of the namespace because nothing happened for 
18 years in the namespace evolution except that the use of the naming 
(apparently) dramatically decreased in the other sub-namespaces than 
Internet due to X121 (numeric names only ). This gave time to forget the 
logic of the namespace and of the delegation of ".arpa", ccTLDs, gTLDs and 
the way it actually works. And led to confusion as some obvious need seem 
not to be addressed.

Actually, ICANN faces two options (of equal interest IMHO):

- either to update to the real life of today and serve the whole 
International open network system
- either to continue its .arpa closed namespace management and concert with 
the other sub-namespaces (as it is prepared to internally - cf. RFC 920, 
multiorganizations)..

This is the only question. Either the ICANN is the center of the 
sub-namespace, because a subspace must be controlled to avoid external 
collisions and therefore is closed (TLDs level) or semi-closed as in the 
case of the RFC-920, or the ICANN supports the real center of the whole 
namespace who is the user, who freely chooses the sub-namespaces he wants 
to belong to. Because the whole name space is open (universal root level) 
and made of sub-(sub-..)namespaces.

The history of the ICANN shows that trying to be both makes them confused 
as they tend to apply their sub-namespace rules to the whole namespace. 
This will not work, this is sterile, this is not profitable.

ICANN has to understand there is a real world. If it cannot open to it, we 
can make it to enter the ICANN.

Why do I say that in the NCDNHC? Because of what a TLD really is and of RFC 
920 which lists the TLDs : .arpa as temporary, then com, net, mil, edu, 
org, ccTLDs and multiorganization TLDs to be set-up (I quote the relevant 
pars of the RFC 920 in PS).

A TLD is the community of its registrants and - except for the ICANN 255 
quoted as such in RFC 920 plus some of the 7 new ones - it is not created 
to be a DN sales business but it is an existing community organizing itself 
to be its own TLD Manager. DN registration shoul dbe free and reasonable: 
until Jon Postel had to get some contributions to help the funding of his 
network, it was that way all over.

So we have five types of TLDs (RFC 920 - 0ct. 1984 and Intlnet operations 
since 1977)

1. the private TLDs (extranets, now .mil, etc)
2. the ".arpa" (legacy) TLDs where the names are now installed and renewed 
for a fee and transferable after the US ACPA.
3. the ccTLDs which are partnering name spaces based on geography they were 
the origin and now share into that approach
4. the "open" merchant TLDs (using the called alternate roots or New.net) 
mostly due to IANA closing.
5. the community/multi-organization TLDs currently frozen or bound to so 
called alternate roots.

1, 2, 3 and 4 are not our cup of tea. 2 and 3 are accounted for by the ERC. 
1 is not of real concern to the ICANN. 4 have the TLDA and they should find 
their room by themselves as soon as IANA opens again as per RFC 920. But 5 
are our cup of tea.

We shown it in the ".org" case. Here we have an ".arpa" TLD moving towards 
a community TLD. This will not really fully happen as the ".org" community 
is not involved, the target will remain to sell DNs only, etc... BUT it has 
shown that the NCDNHC felt concerned and the support by BoD and Staff and 
in here to what Harold does shoes this is the proper place.

So, to respond Danny's right questions about the future of the NCDNHC, I 
consider that the NCDNHC should become a CNSO (Community Naming SO) and 
propose a standard process for non-profit registrants consortia to create 
stable, secure, open and innovative name, trust and services spaces 
Managers. This way we would resume the three traditional ways of TLD set-up:

1. merchant TLDs (sell network services/DNs) created at high cost by and 
for money (GNSO) and quality controled by the ICANN (acting as Top level 
domain top administrator - cf. RFC 920)

2. ccTLDs created a long ago for free by geography and political power 
distribution and quality controlled by the local Govs and their LIC.(cf. 
RFC 920 and 1591)

3. cTLD created at low cost by the people and quality controlled by their 
members, the global internet community and most of all by real life. I have 
bored enough here, but after having defined the Root and TLD Best 
practices, we are working on a community TLD creation process givnig the 
community full legitimacy and the members a serious, stable, secure, 
independent solution concerting with the other  namespaces (acting as a Top 
Level domain Regstrar - cf. RFC 920).

The question is only to know if this concerted relations are to be within 
the ICANN or with the ICANN. ie if the ICANN wants the IANA to be the 
RFC-920's NIC or it is to be a committee to build or is it to be the ITU-I? 
IMHO it should be a mix of the three.

But we cannot wait for long as the first requirement for serious community 
TLD Managers is stable, secure, reliable, independent, value added root 
operations and services. Efforts in that direction must find a fostering 
organization.
jfc


Quotes of the RFC 920
=================

Network Working Group                                          J. Postel
Request for Comments: 920                                    J. Reynolds
                                                                             ISI
                                                                            October 
1984

                           Domain Requirements

Status of this Memo

    This memo is a policy statement on the requirements of establishing a
    new domain in the ARPA-Internet and the DARPA research community.
    This is an official policy statement of the IAB and the DARPA.
    Distribution of this memo is unlimited.

...

Initial Set of Top Level Domains

    The initial top level domain names are:

       Temporary

          ARPA  =  The current ARPA-Internet hosts.

....


    Multiorganizations

          A multiorganization may be a top level domain if it is large,
          and is composed of other organizations; particularly if the
          multiorganization can not be easily classified into one of the
          categories and is international in scope

...

Possible Examples of Domains

...

    The CSNET Domain

       There may be a consortium of universities and industry research
       laboratories called, say, "CSNET".  This CSNET is not a network
       per se, but rather a computer mail exchange using a variety of
       protocols and network systems.  Therefore, CSNET is not a network
       in the sense of the ARPANET, or an Ethernet, or even the
       ARPA-Internet, but rather a community.  Yet it does, in fact, have
       the key property needed to form a domain; it has a responsible
       administration.  This consortium might be large enough and might
       have membership that cuts across the categories in such a way that
       it qualifies under the "multiorganization rule" to be a top level
       domain.

       One might see domain style names for hosts in this domain like
       these:

          CIC.CSNET
          EMORY.CSNET
          GATECH.CSNET
          HP-LABS.CSNET
          SJ.IBM.CSNET
          UDEL.CSNET
          UWISC.CSNET

Top Level Domain Requirements

...

       Multiorganizations

          A multiorganization may be a top level domain if it is large,
          and is composed of other organizations; particularly if the
          multiorganization can not be easily classified into one of the
          categories and is international in scope.

          As yet no multiorganization domains have been established.  As
          they are established information about the administrators and
          agents will be made public, and will be listed in subsequent
          editions of this memo.

...

The Roles of the Network Information Center

    The NIC plays two types of roles in the administration of domains.
    First,  the NIC is the registrar of all top level domains.  Second
    the NIC is the administrator of several top level domains (and the
    registrar for second level domains in these).

    Top Level Domain Registrar

       As the registrar for top level domains, the NIC is the contact
       point for investigating the possibility of establishing a new top
       level domain.

    Top Level Domain Administrator

       For the top level domains designated so far, the NIC is the
       administrator of each of these domains.  This means the NIC is
       responsible for the management of these domains and the
       registration of the second level domains or hosts (if at the
       second level) in these domains.
































   


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