| On-going | | | ICANN Services | | | BestPractice & Re-delegation | | | Funding | | | Bylaws/Articles | | | DNDRP | | | Language |
26 June 2000
Authors: Eva Frölich and Peter de Blanc
1. Background
In the beginning, the Internet consisted of a small number of linked university computers, funded via the US Government, and located in different cities, evolving in the US and subsequently spread out throughout the world.. These computers were connected together by means of full time long distance telephone lines, also paid for by the US Government. The telephone lines carried data, or electronic messages between computers. While the original intent was to share expensive computing resources, an interesting side effect occurred. Individual users with accounts and permissions to use those computers in one location could communicate with users in another location, and they could do so without incurring individual long distance communication charges. For example, someone with access in San Francisco could send an electronic mail message to someone in Boston. Since the computers, which were acting as electronic post offices, were already linked, or "networked", and those links were paid for, there was zero incremental cost to send those messages.
Other universities requested access to these new resources, especially the ability to send messages to locations outside their servoice area. The new universities coming on to the network paid the long distance line charges from their physical location to the nearest "Internet connected" computer site.
Similar activities in other countries resulted in the creation of many "in-country networks". One such example is Australia National University. The users of these systems manifested a strong desire to extend their free or low cost communication to beyond their National borders. Interlinking the various National systems into a coherent International network compelled the formation of various technical working groups to deal with the issues. Somehow, the focus of the work of these groups managed to remain technical and not political.
Major issues and problems to solve included interoperability between organizations' computers, messaging formats, country codes and computer naming conventions, addressing methodology, and the ability to route messages over diverse paths.
Internet pioneers employed new paradigm of governance to solve these problems. Proposed specifications and Requests for Comment(RFCs) circulated between persons interested in participating in Internet development. Through consensus formation guidelines, specifications, and, one might say "laws" came into existance that governed the operation of the Internet.
Consensus formation is the foundation of Internet Law. Technical changes and improvements across a system that spans, potentially, all countries of the world must be driven and adopted by consensus, rather than decree. Application of engineering specifications and technical policy needs to be uniform and consistent across the entire Internet system to insure availability to all users.
2. The Naming System
This document concerns itself with the Naming system.
The current Internet naming system is based on a heirarchry of "Name Servers".
The root server is placed in the top of the hierarchical tree of the Domain Name System (DNS) and contains the information about where to find the addresses of the name servers of all the top-level domains (TLDs). This includes generic (gTLDs), such as .COM and .NET as well as national (ccTLDs) such as .SE and .VI.
Any new TLD that is created in the future must be put into the root before it becomes visible on the Internet. Conversely, if any TLD is removed from the root server, that TLD and the domain names attached to that TLD would become unreachable. There is the very real potential of thousands or even millions of organizations "disappearing" from the Internet a failure should occur.
At the time of this writing, there are 13 so called root severs. Ten (10) of these are situated in different places in the US and the 3 remaining are in countries outside the US.
3. Developments in the Last 5 Years:
Rapid growth and consumer acceptance of the Internet, combined with revenue driven business opportunities in advertising and e-commerce compels formalization of the methods of Internet governance. Increased multi-national participation requires that this governance become less US-centric. Control of the sub Domain Namespace seemed to be moving out of the universities into the hands of diverse individuals, organizations, and governments. Nevertheless, control at the top level remained in the hands of the US Department of Commerce (DOC).
The US Government, in an attempt to assist in the globalisation of the governance of the Internet, directed the US Department of Commerce to privatise the system. The relevant document is called The White Paper. This led to the creation of the Internet Corporation for Assigned Names and Numbers (ICANN) in 1998. ICANN is the non-profit corporation that was formed to take over responsibility for the IP address space allocation, protocol parameter assignment, domain name system management, and root server system management functions now performed under U.S. Government contract by Internet Assigned Numbers Authority (IANA) and other entities. A Memorandum Of Understanding Between The U.S. Department Of Commerce And Internet Corporation For Assigned Names And Numbers outlines the proposed transition process. The MoU expires on 30 September, 2000.
Moving in the same direction, new regional organizations such as Council of European National Top-Level Domain Registries(CENTR) and Asia-Pacific Top Level Domain Forum(APTLD) were established to provide coordination functions for substantial blocks of countries.
During 1998 The Root Server System Advisory Committee (RSSAC) was formed and members are the individuals and organizations running the root servers. The Root Name server Year 2000 Status Document provides a table of root server locations.
An agreement was signed between the US Department of Commerce (DOC) and Network Solutions (NSI) during 1998 about the conditions of the running of the gTLDs .COM, .NET and .ORG.
One of the conditions was to separate the A-root zone from the gTLD-zones, which so far has been performed on the same servers. This work has started but is yet not finalised.
This concludes the historical perspective and background.
4. Statement of Current Work (April 2000)
Specifically, we are now defining the components and issues involved in the transition from an informal (de facto) system operated by trusted individuals working on a voluntary, usually unpaid basis, to a formal (de jure) system operated by and for corporate organizations, defined by contract, with specific deliverables and financial considerations.
4.1 Identification of the parties to the contract.
The draft committee takes the position that, until such time as a formal mechanism for interposing a third party is in place, there are only two parties to this contract. The designated ccTLD administrator, whether an individual or an organization, and ICANN are the two parties.
The act of developing and signing a contract between the ccTLD administrator and ICANN, in itself, will provide ICANN with the evidence it needs to show legitimacy of "bottom-up", "consensus based" international support, and will go a long way towards giving ICANN the independence from the US Government that ICANN desires.
The ccTLD administrator, in turn, receives the recognition that it is the designated manager of the ccTLD at the time of signing of the contract. No changes may be made without compliance with procedures that are a part of the ccTLD Best Practices Document That document is in the hands of another ccTLD working group.
There is a non-voting Governmental Advisory Committee (GAC) to ICANN, which has provided a paper in which they state their position on delegation of ccTLDs. (See URL or Attachment). The GAC paper talks about a three-party agreement between ICANN ? Government ? ccTLD delegee. This paper is of great interest to some countries and those countries may wish to implement it.
Whether there can be two types of contracts; that is, a two party contract for some ccTLDs and a three party contract for other ccTLDs remains to be determined.
4.2 Specification of Quality of Service (QoS) level and performance guarantees
The concerns over security and stability are growing amongst the individual domain name holders. Revenues from E-commerce are escalating the importance of the uninterruptible operation of the domains. Loss of connectivity for an income-generating domain would be more than unpopular. Lawsuits over liability issues, revenue losses, business interruption, damage to reputation, and other factors could lead to actual and punitive damages assessed against an Internet Service Provider, and/or a ccTLD manager.
Loss of connections can be caused by many factors, but the ccTLDs managers need to ensure that loss of connection does not result from their actions, or on the actions or inactions of the upstream root services providers.
The domain name holders will (or maybe are) today negotiating QoS service level agreements with the Internet Service Providers (ISPs). The ISPs can't sign a contact without knowing what QoS service level service they will obtain from the ccTLDs. And to follow the chain the TLDs can't agree on a level without knowing the QoS service level of the root. For those TLDs making agreements direct with the domain name holder the problem is the same except for the part of the ISP.
4.3 Scenario
A ccTLD looses root service and goes down for a period of time. The different domain name holders lose income because the customers can't reach them. They expect to get reimbursed and sue the ccTLD. The ccTLD then on its side finds out that the problem was because of a mistake in the root-zone and doesn't want to bear the liability cost on something that was not his fault. The ccTLDs then sue the root.
5. The Agreement between ccTLD and ICANN
The agreement between ccTLD and ICANN must contain a section about the security and stability of the root.
The root is crucial to the Internet Community as without them the system will break down and the customers domains will go down. There fore the TLDs need to have insurance about the stability and an agreement on the service level. The service level agreement to a domain name holder can¡¯t be stronger than its weakest link. Today there is no insurance from the root-servers about the service today.
The Root Server Consortium has to be formalised is the same way as the TLDs and they must operate in an open process.
5.1 Root Server Availability
The Root server will be available 100% of the time. Assessment of availability should be based on a procedure such as ITU - CCITT document M.1016.
5.2 Latency
The services will be deployed (mirrored) in such as way that latency (speed) of access from any major Internet carrier backbone will not fall below 85 milliseconds for an in-region round trip, and 125 milliseconds for an trans-regional round trip.
5.3 Notification
If a fault known to the root server manager causes the service to be unavailable for a period of time exceeding five (5) minutes, the root server administrator will notify the ccTLD managers in accordance with the manner agreed between the root server manager and the ccTLD manager (e-mail, phone, fax, beeper), 24 hours a day and 7 days a week(24*7).
If a fault becomes known to the ccTLD manager, the ccTLD shall notify the root server manager in accaordnace with the manner agreed between the root server manager and the ccTLD manager(e-mail, phone, fax, beeper), 24 hours a day and 7 days a week(24*7).
5.4 Escalation Procedure
Once the root server manager is aware of a fault, the time shall be logged (hard copy, wet signature).
An incident escalation system (possibly submitted by the root server manager) must be in place that causes an increased level of human resources to be applied to fault resolution over a period of time.
5.5 Costs
The root server manager must disclosed the true, unbundled costs of operating the service to the ccTLD mangers, or to a designated ccTLD constituency representative.