Economies covered

  • 2009-2010 Edition dr_dot2009-2010
  • 2007-2008 Edition dr_dot2007-2008
  • 2005-2006 Edition dr_dot2005-2006
  • 2003-2004 Edition dr_dot2003-2004

Click the dot to read the chapters. 

.af Afghanistan dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.au Australia dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.bd Bangladesh dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.bn Brunei Darussalam dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.bt Bhutan dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.cn China dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.hk Hong Kong dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.id Indonesia dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.in India dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.ir Iran dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006
.jp Japan dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.kh Cambodia dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.kp North Korea dr_dot2009-2010 dr_dot2007-2008

.kr South Korea
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.la Lao PDR
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.lk Sri Lanka
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.mm Myanmar
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.mn Mongolia
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.mo Macau
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.mv Maldives
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006
.my Malaysia
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.np Nepal
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.nz New Zealand
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.ph Philippines
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.pk Pakistan
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.sg Singapore
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.th Thaïland
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.tl / .tp Timor-Leste
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.tw Taiwan
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
.vn Vietnam
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006 dr_dot2003-2004
SAARC dr_dot2009-2010 dr_dot2007-2008
dr_dot2009-2010 dr_dot2007-2008 dr_dot2005-2006
APEC dr_dot2009-2010

Internet governance

Article Index
Internet governance
WSIS and governance of the internet
Enabling meaningful participation
Defining Internet governance: Scope and responsibi
Defining internet governance: key issues
Ten urgent issues and their solutions
Internet governance broadly
Internet pricing and interconnection
Network security, cyber crime and control of conte
Conclusion: Good governance in the region

Defining internet governance: key issues

The Internet Corporation for Assigned Names and Numbers (ICANN) – along with the domain name system (DNS), particularly country code top-level domains (ccTLDs), IP addresses, the root server system, and multilingual or internationalised domain names – has been the focus of the Internet governance debate. During the Geneva phase of WSIS, some developing nations complained that they were unable to participate in many of the decision-making processes about domain name policies or to manage resources they believed they had a right to manage, particularly a sovereign right in the case of ccTLDs. The disagreement was exacerbated by the perception of US domination of the Internet and its governance.

ICANN and the US government: Control of the root servers

ICANN is a California-based non-profit corporation established in November 1998 by the US government to take responsibility for the management of the DNS. The intention behind ICANN’s creation was to privatise and interna¬tionalise the DNS, to introduce competition, and over time to hand over responsibility for DNS management to the global Internet community.

The development and management of the DNS had historically been carried out by an organisation called the Internet Assigned Numbers Authority (IANA) under research and other grants from the US government. IANA is more a set of technical functions than an actual entity; and ICANN, upon its creation, took responsibility for the IANA functions under a contract with the US Department of Commerce. Those functions include the assignment of technical protocol parameters, coordination of IP address space allocation, oversight and implementation of policies for DNS registries and registrars, and oversight of the root server system. ICANN also took responsibility for the Department of Commerce’s contract with Network Solutions Inc. to manage the generic top-level domains (gTLDs) “.com”, “.net” and “.org”.7

ICANN’s relationship with the US government is defined in two documents. The first is a memorandum of understanding (MoU) which lays out a set of milestones ICANN must achieve to assure the government that ICANN and the private sector are capable of assuming the responsibilities related to the technical management of the DNS. The MoU is due to lapse in September 2006, at which time ICANN should be able to assume responsibility for the DNS. The second is a contract for the performance of IANA functions. It is a yearly contract with options extending to March 2006.

Root servers: Spreading the load across the world

The DNS root servers provide the master, or root, level of the hierarchical DNS directory. Collectively, they manage a single directory called the root zone file, which contains a reference to all top-level DNS servers, including gTLD and ccTLD servers. For a top-level domain (TLD) like “.com”, “.jp” or “.my” to appear on the global Internet, it must be installed in the root zone file by the operators of the DNS root servers.

There are 13 root servers around the world; the number is limited to 13 by the technical design of the protocols on which the DNS runs and cannot be changed. Ten root servers are located in the USA. The locations of the root servers are partly historic, the Internet being conceived and developed in the USA, but they are also based on the practical consideration that root servers should be sited so that the maximum number of users enjoy the minimum response time when sending DNS requests, that is, as close to as many users as possible. As Internet traffic has historically concentrated on the Internet exchange points located on the US east and west coasts, having root servers nearby makes sense. Root servers are also difficult to move, not physically but in terms of IP address routing.

Anycast and the deployment of “regional” root servers

The WSIS Plan of Action recommends that action should be taken to promote regional root servers in order to overcome barriers to access. The document does not explain what regional root servers are. They were discussed during the preparatory process, but what they are, how they would be implemented and would function, and what problem they would solve were not discussed. However, the recommendation seems to envision moving a root server from a current location (probably the USA) to some other place, as there certainly cannot be more than the current 13. The recommendation to create regional root servers highlights one of the potential dangers of a process like WSIS: that governments will make political demands that are technically infeasible and potentially extremely harmful.

During 2003, while WSIS was in progress, a technique called anycast was deployed that enables one root server to be “cloned” in multiple locations. By January 2004, there were more functioning root servers outside the USA than inside its borders. An anycast root server is an exact copy or mirror of one of the authoritative 13 servers, containing identical data and performing exactly the same function, but it can be located anywhere in the world. One of the 13 root servers is located in the Asia-Pacific region, in Tokyo, but there are now anycast mirrors of other root servers in multiple cities throughout the region: Australia, China, Hong Kong, Taiwan, Singapore, New Zealand, Thailand, Malaysia and Indonesia each host at least one anycast root server. In addition to operational benefits, anycast root servers go some way to reducing geopolitical pressures for countries to “own” a root server.

Since the beginning of 2003, cloned root servers have appeared on every continent, to date in 31 countries and territories. Anycast has significantly changed how DNS root services are distributed. Yet, it has been implemented with minimal involvement of ICANN, no formal policy development process, and no official consultation with the US Department of Commerce. That such a fundamental change to how the Internet works can take place with so little oversight certainly casts doubt on the view that ICANN rigidly controls the Internet as some in WSIS have claimed. However, the US Department of Commerce does control the root.

Unilateral control of the root

IANA is responsible for publishing the content of the root zone file. The contract with the US Department of Commerce specifically prohibits IANA – or ICANN, which holds the contract for IANA functions – from making any “modifications, additions, or deletions to the root zone file or associated information that constitute delegation or re-delegation of top level domains” without permission. There are two implications to this, one regarding deletion and the other redelegation, and they represent the key problems with ICANN and the DNS raised during WSIS.

The IANA contract gives the US Department of Commerce the final authority on what appears or does not appear in the root. This situation where the USA has the potential to remove a country from the root, and therefore from the Internet, is obviously a serious concern for many nations. While it is extremely unlikely that the USA would use this potential power to remove a ccTLD, it is unacceptable to these nations that one country should have such control over the resources and rights of another. It also impacts on the good governance of ccTLDs and affects the introduction of future DNS services such as internationalised domain names.

Governments must have the assurance that their country’s TLD will appear in the root: it is an essential matter of national sovereignty. It should be a particular concern to countries in Asia Pacific, where there is a strong need for internationalised domain names.

ccTLD redelegation

The IANA contract also states that the US Department of Commerce must authorise the delegation or redelegation of any TLD. Consequently, the US government has the final authority on who is responsible for administering a country’s TLD.

Historically, IANA assigned the right to administer a ccTLD to the first technically capable person from a country showing interest in this task. It made the assignment to a ccTLD manager on the basis that the manager is performing a public service on behalf of the Internet community, and the assigned person or organisation is a trustee, not owner, of the ccTLD. Some of these early delegations have become contentious as they were made before many countries had any knowledge of the Internet. Governments are now aware of the importance of the Internet and either wish to take control of the ccTLD directly or assign control to an organisation they consider more appropriate.

To begin a transfer of a ccTLD from one designated manager to another, the old and new managers must inform ICANN that the transfer is mutually agreed and that the new manager understands the responsibilities involved. ICANN procedures say it is also helpful to have supporting correspondence from other parties affected by the transfer and that it pays particular attention to the wishes of governments. Where there is a conflict – perhaps the old manager refuses to give up the responsibility – ICANN tries to have the two parties agree rather than force a decision and become involved in local politics. This can be a very long process, one that many governments that have experienced contested redelegations have found very frustrating.

This complex process is necessary as ICANN cannot redelegate a ccTLD simply because someone asks it to do so. There are occasions when it is difficult to know who is speaking for the legitimate and responsible arm of a government. There are also technical considerations to the redelegation. One of ICANN’s key responsibilities is to ensure the security and stability of the Internet, and a poorly operated or failing ccTLD could impact the operation of other parts of the global network as well as provide bad service to users of the ccTLD locally. However, under the current arrangement, no government (except the USA) owns its country’s TLD, and so it cannot order ICANN or the US Department of Commerce to make any changes regarding its country’s TLD.

Beyond the requirements of the contract with the US Department of Commerce, ICANN actually exerts very little control over ccTLD operations. It does not say what fee a ccTLD operator should charge for a domain name and sets no requirements on the structure of the ccTLD’s name space. Some ccTLDs are run as de facto gTLDs; they do not serve their local community but instead compete with the true gTLDs. Tuvalu, the Pacific island nation with the ccTLD “.tv”, sold the right to market the ccTLD to a corporation which promotes the name as a competitor to “.com” and the other gTLDs. There are many similar examples, such as “.to”, “.nu” and “.cc”.

However, the US government’s control over the root zone file and over the redelegation of TLDs casts a cloud over how ICANN is viewed by many governments. At the meeting to discuss the formation of WGIG, a representative of the Brazilian government said, “It is a myth that there really is such a thing as independent, private sector management of the Internet addressing system. In fact ICANN’s MoU with the US Department of Commerce reveals that it is closer to a government.” There will be no solution to disagreements over Internet governance until the US government makes some concessions to the legitimate concerns of other nations regarding these simple and obvious sovereign issues.

It is also important to note that while the current MoU between ICANN and the US government is expected to be the last, with ICANN assuming responsibility in September 2006, the IANA contract is a separate arrangement. The contract is linked to the MoU, but it is unclear whether the US government will also allow this contract to end in 2006 and let control of the root servers pass over permanently to ICANN.

Stakeholders from the Asia-Pacific region should make every effort to find a resolution to this problem.

Internet address space: IP numbers

IP addresses are numbers used to identify computers and devices on the Internet. No two devices on the public Internet can have the same IP address, so the addresses must be uniquely assigned; and this requires some degree of global coordination. The current IPv4 address pool has a limited number of addresses, so assignments are made with a view to conservation.

Today, organisations known as regional Internet registries (RIRs) manage the IP address space. The Asia Pacific Network Information Centre (APNIC) is responsible for Internet resource distribution in the Asia-Pacific region. The distribution of the IP addresses allocated since 1999 among the various RIRs is as follows: APNIC (for Asia-Pacific region) 32 percent, RIPE NCC (Réseaux IP Européens Network Coordination Centre, for Europe, Middle East and North Africa) 29 percent, ARIN (American Registry for Internet Numbers, for North America and Southern Africa) 37 percent, LACNIC (Latin American and Caribbean Internet Addresses Registry, for Latin America and the Caribbean) 2 percent.8

All the RIRs are open, fee-based not-for-profit member-ship organisations. They each develop policy through open, consensus-based policy development processes. The policy development process and policy decisions are archived so that they are publicly accessible. At the global level, IANA allocates IP addresses from pools of unallocated addresses to the RIRs according to their needs. The RIRs do not contract with the US government and are not subject to US government policy.

In the ICANN structure, the RIRs form the Address Supporting Organisation (ASO) and provide the ICANN board with advice on global policy issues regarding the assignment of IP addresses. The RIRs recently established a new organisation, the Number Resource Organisation (NRO), as a focal point for their global activities. NRO and ICANN signed an MoU establishing how NRO will fulfil the role, responsibilities and functions of ASO as outlined in the ICANN bylaws.

The RIRs have been operating fair and equitable allocation processes since the mid-1990s. However, that this is not understood by some governments is an indication that the relationship between the RIRs and national governments needs to be strengthened. Many governments are clearly not aware of how the RIRs operate. The RIR system of “bottom¬up” processes, in particular, may be alien when compared to ITU’s system (which assigns responsibility for the management of the telephone numbering plan to nation-states).

IPv6 allocation

IPv6 was adopted by the Internet Engineering Task Force (IETF) as the successor to IPv4 over ten years ago to provide more address space and functionality. The IPv6 address space is many orders of magnitude larger than that of IPv4 and, while not infinite, is enough to meet all foreseeable requirements. Wasteful and ill-considered allocations can of course exhaust any finite resource, but the IPv6 address space is large enough to make the conservation-oriented allocation policy adopted for IPv4 unnecessary.

Adoption of IPv6 has been much slower than anticipated, and national governments are becoming increasingly involved in developing policy to encourage deployment. Japan is typical of many Asia-Pacific countries in making IPv6 deployment an important element of the national ICT policy in the hope of stimulating innovation, for example in ubiquitous services, and strengthening the domestic IT industry. China, South Korea and Japan have begun joint initiatives to develop and promote IPv6. Governments that make IPv6 an element of their national ICT strategy will consequently take a much greater interest in allocation policies than they did for IPv4. However, like Japan, they can be expected to limit their interest to their national strategy so long as allocations are made on a fair and non¬discriminatory basis.

Houlin Zhao, director of ITU’s Telecommunication Standardisation Bureau, recently suggested that concerns over sovereignty made it necessary for nation-states to take greater control of IP address allocation and that the availability of almost unlimited IPv6 addresses made this possible. However, the primary concern regarding IP addresses, whether scarce or plentiful, is that they are globally uniquely assigned. Sovereignty, if it exists at all as a legitimate concern, is at best a secondary consideration to global uniqueness. Running a new nation-state based system side by side with the existing RIR process may result in excessive fragmentation of IPv6 address space and may cause a failure of the routing system resulting in discontinuation of services to parts of the Internet.

In Asia Pacific, where control of content by some governments is a concern, allocation of IP addresses by governments would enable questionable applications such as censorship and the tracking or restriction of the content of communications. As well as being a violation of human rights, such uses would undermine the fundamental architectural principles of the Internet.

Good governance of Internet resources

As the RIRs are responsible for the allocation of critical resources, and given the importance of the Internet, it would be irresponsible of any government not to take an interest in allocation matters. The misunderstanding that governments have about IP address allocation is an indication that the RIRs need to continue to improve their relationships with governments. However, there has been little substantive criticism during the Geneva phase of WSIS of the RIRs’ work, policies or processes, and governments taking an interest should not mean taking control or trying to enforce regulation. A positive response from the RIRs to the attention of WSIS would be to not only increase their outreach to governments but also seek to involve representatives of public interest from civil society.

Like the RIRs, the root server operators have developed their systems and processes over time in ways that have grown to meet the technology demands and increased scale and importance of the Internet. However, unlike the RIRs, their operations and processes are neither transparent nor well defined. While technologically sophisticated and extremely competent, their operational and administrative processes do not meet the standard required of critical infrastructure providers. A government representative at the first meeting of WGIG in November 2004 said that those who had been managing the root servers had done so very well so far, but there was no legal guarantee that this would continue.

Root server operators are very diverse in their organisa-tional structures – some are run by government agencies, some by R&D organisations, and others by the not-for-profit and the private sector – and in the technical systems and equipment they deploy. Such diversity is a recognised strength against the risks of monoculture. But the root server operators’ operational practices, such as how they are financed and their financial stability, are not clear. They have no agreements among themselves or with the TLD managers they serve as to the level of service they will provide or regarding best practices. They have no agreement with ICANN to provide service. Should it be necessary to select a new root server operator, there are no published technical qualifications or characteristics required of a successor operator. It is a problem of transparency and visibility, and governments have a right to know if the critical infrastructure will continue to function. The Internet today is far too important for ad hoc processes.

Operational processes and standards for root server operators should be agreed, and agreements among the root server operators and between the root server operators and ICANN signed. Reporting procedures should be put in place to show that operational standards are being met and will be met in the future. Without such procedures, it is reasonable to expect that some, if not many, governments will intensify demands for increased oversight and control.

Internationalised domain names and the promotion of multilingualism

Until the early 1980s, each computer on the Internet was identified by an IP number, a string of numbers uniquely assigned to every computer on the network. As the Internet grew, domain names were invented to map combinations of letters and numbers to an IP number so that people could identify their computers in more meaningful ways. For example, a computer that had been known as could be identified by the much easier to remember and recognise “” (the UN). But this is only easier if you understand and recognise Roman characters. The DNS is based on the Latin alphabet. It is estimated that about 80 percent of people in the Asia-Pacific region do not understand English, and many of them do not even recognise English characters. For these people, domain names might as well be numbers.

The promotion of multilingualism in the information society is one of the central features of WSIS. While the text in email or in webpages can be produced in most of the world’s languages and scripts, domain names must be typed in a subset of ASCII characters. Work has been going on since 1998 to develop internationalised domain names (IDNs) which use non-ASCII characters,9 and until recently barriers to the deployment of IDNs had been technical. However, standards are now in place, and the main obstacles to IDN deployment today are a lack of resources and perhaps also a lack of determination among some of the key players to undertake what will be a very challenging global activity.

IETF had developed most of the technical standards for IDNs by early 2003, while some important work on administrative guidelines for Chinese, Korean and Japanese characters was completed in April 2004. ICANN began work identifying the technical and policy issues in 2001, issued a comprehensive report in autumn 2002 and finalised guidelines for the implementation of IDNs in June 2003. Unfortunately, since then all sense of urgency seems to have been lost.

There are other barriers to deployment. The Internet Explorer web browser used by 90 percent of Internet users worldwide does not have native support for IDNs, and a plug-in must be installed. Microsoft is highly unlikely to support IDNs until it releases the next version of its Windows operating system known as Longhorn, expected sometime in 2006.

IDNs will also complicate law enforcement efforts to track activities across borders involving domain names and registration information that officers are unable to read. Many Chinese characters look very similar, particularly on a computer screen, and we can expect more cases of fraud as people are directed to hoax websites that have domain names looking similar to that of an online bank or payment system they are familiar with but that have actually been set up to steal their money, identity and so on.

IDNs at the second level are slowly being commercially introduced. The second level is fine for Western languages that use diacritical marks, such as French or German, as they can use an IDN below their ccTLD “.fr” or “.de” or in a gTLD such as “.com”. But for non-Western languages, like many used in Asia Pacific, their scripts also need to be used at the top level.

The introduction of a fully internationalised system will require cooperation between countries and ccTLD managers, particularly between countries of the same language group. Internationalised top-level domain names may require new governance structures and policy development processes that are representative of the language groups they will serve. It is reasonable to assume that these structures will be very different from the current systems based on a national or global scope. Furthermore, new internationalised TLDs will require entry into the root zone file, and this will make continued US unilateral control over the system even more contentious.

IDN experts admit they do not have answers to all the problems of internationalised top-level domain names. Every proposal put forward so far has some problems, be they technical, operational, political or, worst, unknown. However, the community has waited far too long and the need is becoming too great. Hence, some are suggesting that implementation of internationalised TLDs should begin as soon as possible in order to gain operational experience and to work through problems as they come along. Therefore, clear rules and procedures for applying to operate internationalised TLDs coupled with open and transparent processes for making selections of TLD managers should be established quickly by ICANN.

An IDN system is a critical enabling technology that will make the Internet more usable and attractive to the majority of the world’s population who do not recognise English. IDNs will encourage local communication and local content creation. The non-English-speaking countries of Asia Pacific have the most to gain from IDNs and must take the lead in their deployment. ICANN is currently the right forum to lead discussion and work on deploying IDNs.

ICANN has brought together technical experts from IETF and other forums, people concerned with Internet security and stability, ccTLD managers and governments, gTLD registries and registrars, and an expert policy community from the private sector, civil society and intergovernmental organisations. Implementation of IDNs will be a very significant global undertaking and no single organisation has the capacity to do all that is required, but ICANN is well placed to bring all the relevant actors together. However, ICANN has been slow since issuing its policy guidelines some years ago, and it should recognise that it is in danger of becoming an obstacle to progress. The need for IDNs is obvious, and ICANN must be willing to take some risk, shared with its community, to make sure they are deployed.


Add comment

Security code