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