Re: Is the IANA a function performed by ICANN ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 01:49 26/06/04, Scott Bradner wrote:
see RFC 2860

Dear Scott and Karl,
thank you for your comments. I explain. I consider the interest of a draft on the digital intergovernance I do not know yet if I want to undertake such a task, how, with who, and where. I established a site (http://intergovenance.org) to gather inputs from different authorities (I play it low key as it could be too big a project if not worked in parallel with SIS). The idea I float is to extend and generalize RFC 920/1591 from ARPA Internet, to Internet, to current inter-digital-network-convergence. Mixing past, experience, specifics and future of the different technologies towards a coherent model of the digital ecosystem and of its usage. From bandwidth to users technical aspects. Not by who does what, but by what is needed and how it is best performed.


A basic need is for a generalized e-networks lexical and theory/modelization. Nothing fancy. What we do all the day long, but put into a single structured document from telecoms, to datacoms, to communication services. Analyzed for what they should do, not for history or what they currently do.

There, there is a need for a neutral, stable, reference "system". Until now, this was thought as a "center" in the global network governance. For many reasons (risk containment, sovereignty, experimentation, operational flexibility, cybernetic warfare, economic intelligence, etc.) such "centers" in network horizontal governances must become a concerted specialized vertical governance within the intergovernance of the inter-networks/technology/systems/services/usages/etc. Also, there is a clear "law": if one wants to keep an intergoverned system under a single governance, that governance will either obsolete (ITU?) or become a dominance (ICANN?), both being discarded (an intergovernance does not fight, it circumvents).

So, the future is clear. It is made of a IANA network concerted system for the very large diversity of names and numbers used for network interoperations and users interapplications. One "IANA" centers per country, region, sector, culture, city, etc. down to private ones. They will provide the ubiquitous e-continuity metastructure. Each horizontal thematic intergovernance (DNS, numbering, geonumeric bases, formats, etc; etc. ) will have to devise their ways to keep their global information matrix consistent - or to restore its consistency after a dysfunction, an attack or a sovereign zone take-over for critical reasons. ICP-3 of ICANN is a good introduction to this effort in the DNS area.

There are two good ways and a bad one to reach this from the today situation.

- good 1. the current IANA multinationalize/multilingualize/multitechnoloze into it. This looks unrealistic but matching IETF "core values". IETF already coped with other unrealistic challenges. ccTLDs could be a good existing supporting structure. But users support (@large) would be needed to establish it. IETF would have the lead.

- good 2. IANA becomes a part of ICANN. ICANN is increasingly perceived as an USG agency. So, the common international practices apply. Some countries (ccNSO) want to keep using it. Some others will create their regional, national governance structures and bodies. This will be good for QoS through competition. ITU will probably then be the best solution, if it creates an ITU-I Sector.

- bad one. to mix them both to impose an ICANN governance. This cannot technically work on medium/long term. A dominance does not fit in a distributed system. This will create an increasing instability and will be circumvented by usage and real world intergovernance. The bodies associated with the dominance will probably be discarded. RIRs have understood that. Most of the ccTLDs too.

Let be clear. I do not speak of short term political instability. But of very long term architectural instability. To understand this let recall that positions taken in minutes as obvious in 1984 are the ruling the way the name space works today. We all know the difficulty of making move the inter-networked system, ex.: IPv6. Today 88% of the mankind does not use the Internet. Also 88% of them are neither EU/US citizens.

If 70% of the mankind was connected in a decade, the increase would be 150%. If 2/3 of the new comers adopted one different parameters in an area (for example to get ML.ML denied by ICANN, or a different no spam mail system, or a different DNS RR,) we would have the same number of users than today (800 millions) using that solutions. We know the compatibility difficulty for IPv6, the threat of alt.roots for some: we would have to increasingly live for ever with this kind of problems. I have no doubt that natural evolution will correct IANA possible mishandling over the next century - the same as sometime the whole network will be IPv6, the naming multilingual, etc. But in the meanwhile?

Scott, I did not quote RFCs because on the grounds above.

1. RFC 2468 comes before. With a substantial with "a function performed by ICANN".

2. RFC 2860's is only the technical work of the IANA. Not on its architectural nor on its intergovernance aspects. It signed by Fred Baker showing that IETF is the one delegating (with silent IAB), hence my question to IETF. The given IANA definition is: "Internet Assigned Numbers Authority (a traditional name, used here to refer to the technical team making and publishing the assignments of Internet protocol technical parameters). The IANA technical team is now part of ICANN"

This refers to:
- a group of people identified as such, not to a function.
- this is a bilateral hosting agreement. Not an assimilation.
It does not match either "a function performed by ICANN".

Karl, your technical and legal points are well made. But let be candid: outside of a very few ICANN/IETF and g/s/ccTLD group of people, who cares about the NOAA Internet? This may certainly have a technical impact because someone with technical responsibilities in ICANN or IETF is affected. But this would be a bug to correct. Not something to keep, not even to discuss.
jfc








_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]