Shanghai Communique

ASIA PACIFIC TOP LEVEL DOMAIN ASSOCIATION

Shanghai, China

26^th October 2002

The APTLD, meeting in Shanghai with members from Japan, China, Singapore, Korea, Malaysia, Thailand, Niue, New Zealand and Taiwan, makes the following statements:

We note that the ccNSO Assistance Group has reported on the progress in developing the scope of the Supporting Organisation and the approach taken in determining the nature of roles, responsibilities and accountabilities might have merit;

A statement on APTLD's position in relation to ICANN's Zone Transfer Policy was adopted and is attached as Appendix A;

A comprehensive report on outreach in the Asia-Pacific region was received and we noted that future activities must meet the needs of Pacific members;

We resolved to sponsor attendance by ccTLD managers at further APTLD meetings and made specific plans for the APTLD AGM scheduled for Taiwan in February 2003;

An explicit resolution on Internationalised Domain Names was passed and is attached as Appendix B; and

We commend the efforts of the ccTLD Secretariat in organising and conducting ccTLD Nameserver training for 31 people from approximately 19 ccTLDs.

We thank .cn for its efforts in making the necessary arrangements and for facilitating the holding of the APTLD meeting in Shanghai.

On behalf of the APTLD,

Ramesh Kumar Nadarajah

Chair

Asia Pacific Top Level Domains

APPENDIX A

APTLD Statement on ICANN Zone Access Policy

26 October 2002

1. Introduction

ICANN had recently issued an FAQ at http://www.iana.org/faqs/tld-zone-access-faq.htm regarding the policy to access to TLD Zone Files that was posted in September 2002 ("IANA's FAQ"). After perusing IANA's FAQ, we find that the explanations provided to justify the zone access policy unsatisfactory and we present our arguments in this document.

2. IANA's FAQ

2.1 IANA stipulates that access to TLD zone files facilitates diagnosis of DNS problems and helps in analysing DNS performance. We are of the opinion that DNS performance analysis does not require zone file access. There are tools available (such as DNS Expert) that can assist in checking a particular TLD zone.

2.2 A DNS query, such as dig or nslookup, can check on delegation accuracy and proper configuration. This query can be done quickly. Further, the design of the DNS is in such a way that ensures optimum stability such that parent TLD domains are not affected by the misconfiguration of its delegated sub-domains.

2.3 We do not agree with the assertion that the basis of IANA's zone access policy is found in RFC1591. RFC1591 does not address zone access at all and instead states the following:-

2.4 "There must be a primary and a secondary name server that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the IR and the IANA."

2.5 The ground of requiring copies of zone files in order to provide a last-resort backup to help ensure DNS stability in the event of local catastrophic failures is also questionable. The requirement of two name servers addresses the issues of zone data redundancy and network redundancy. This redundancy issue is addressed by, ideally, having geographic and network diverse secondary name servers.

2.6 Nonetheless, we find IANA's offer of providing last-resort back-up service of interest and would like to seek clarification on whether this is a service that IANA intends to offer, particularly to ccTLDs who face difficulties finding overseas secondary name servers?

2.7 We completely agree with the importance of ensuring DNS operational stability and performance. It is hoped that clear guidelines on such practices will be formulated in due course based on bottom up and transparent processes.

2.8 Any decision on methods of name servers checking should be made in consensus with the ccTLD community.

3. Conclusion

We reiterate that the IANA FAQ does not justify its grounds for requiring access to zone files. Technical updates, such as name server changes, submitted to IANA should be acted upon promptly, irrespective of whether IANA has access to a ccTLD's zone files.

Internationalised Domain Names (IDN) went through the standardisation process at IETF which approved publication of four proposed standards.

APTLD recognises the need of co-ordination on IDN, in particular in its localisation and global deployment.

APTLD specifically recommends that the global Internet community undertakes the following:

1. Development of Issues List
2. Development of Recommended Best Practices
3. Creates archives of various resources from around the world
4. Undertake public relations effort, including outreach

APTLD further recommends all stakeholders to co-ordinate on this matter, especially the ccTLD community which includes all language communities in the world.

FINALLY:

APTLD specifically recommends:

1. THAT the ccTLD Constituency (ccSO) to form IDN Working Groups to address issues for various language groups
2. THAT the global Internet community have regular fora among various stakeholders to co-ordinate activities starting with information exchanges.

See Appendix for the relevant organisations working on IDN activities and their archive.

Signed: APTLD

IETF/IDN WG www.ietf.org

ICANN/IDN Ctte www.icann.org

DNSO/IDN WG www.dnso.org

APTLD www.aptld.org

JET

CDNC www.cdnc.org

JPNIC www.nic.ad.jp

JDNA www.jdna.jp

JPRS www.jprs.jp

KRNIC www.krnic.or.kr

TWNIC www.twnic.org.tw

CNNIC www.cnnic.org.cn

MINC www.minc.org

AINC www.ainc.org

©2001 InternetNZ
Last updated 7 November 2002