ICANN São Paulo meeting site

I'm pleased that today we were able to launch a couple of discussion papers that I have been keen to start a public dialogue on to help improve management of the DNS root zone.

We've been working hard to improve the responsiveness and efficiency of IANA for some time now. In assessing how IANA does its job, it became clear some of the delays that affect us are because we have inherited some policies that aren't the most efficient to implement.

Number one on the list of things that would improve average processing time for the DNS root zone is to alter our "glue" policy. I have presented at the last few ccNSO meetings, as well as meetings of APTLD and CENTR, on this particular topic. Some name servers are shared between many different TLD operators, and simple administrative changes to these can require two confirmations from every single affected TLD operator. In practice this has made some fairly simple changes take over a year, because one or two of them would not respond to our requests.

So today we have launched a public review of this specific procedure, and I am hopeful the community will be able to suggest a new process that is both efficient, yet has the safeguards required to ensure requests are properly approved, and that affected operators are properly advised.

Another interesting topic we have launched discussion on today is how to retire some of the country code top-level domains that no longer exist in the ISO 3166 list. IANA is not required to make value judgements on what constitutes a country, or what a two letter code should be for a country. Instead, it relies on the ISO 3166 standard, maintained by an independent agency. IANA will allow codes that have been added to this list to be added to the DNS root, assuming the conditions for local community support and technical competence have been met.

However, countries don't necessarily exist forever. Over time, countries split up, merge, or rename. Therefore ISO 3166 codes have to be updated to reflect this, and ultimately users of country-code top-level domains need to migrate to the new codes that represent their country. Our second policy review asks the community to contribute on helping us define the best process for performing that migration.