September 2003 - council - lists.icann.org

ALAC statement on resolution of non-existing domain names
by Thomas Roessler Sept. 16, 2003

Sept. 16, 2003

For your information. The At-Large Advisory Committee would like to bring to ICANN's attention concerns about Verisign's surprising roll-out of the "SiteFinder" service for .com and .net. SiteFinder works by re-directing queries for non-existing domain names to the IP address of a search service that is being run by Verisign. This practice raises grave technical concerns, as it de facto removes error diagnostics from the DNS protocol, and replaces them by an error handling method that is tailored for HTTP, which is just one of the many Internet protocols that make use of the DNS. We will leave it for others to explain the details of these concerns, but note that returning resource records in a way which is countrary to the very design of the DNS certainly does not promote the stability of the Internet. These concerns are not mitigated by Verisign's efforts to work around the consequences of breaking the Internet's design on a service-by-service basis: These workarounds make specific assumptions on the conclusions that Internet software would be drawing from nonexisting domain names; these assumptions are not always appropriate. When working as intended, the service centralizes error handling decisions at the registry that are rightly made in application software run on users' computers. Users are deprived of the opportunity to chose those error handling strategies best suited for their needs, by chosing appropriate products available on a competitive marketplace. Software makers are deprived of the opportunity to compete by developing innovative tools that best match the user's needs. We urge ICANN to take whatever steps are necessary to stop this "service." -- Thomas Roessler <roessler(a)does-not-exist.org> At-Large Advisory Committee: http://alac.info/

1 0

ICANN GNSO Policy officer position
by Bruce Tonkin Sept. 16, 2003

Sept. 16, 2003

Hello All, Just a note in case others haven't seen this, that ICANN has a job opening for a GNSO Policy officer. I understand that applications will close shortly. Please pass onto to interested members in your constituencies. Regards, Bruce From: http://www.icann.org/general/jobs.htm#GNSOPolicyOfficer GNSO Policy Officer The Internet Corporation for Assigned Names and Numbers (ICANN) has an immediate job opening for a GNSO policy officer at its offices in Marina del Rey, California USA. The primary responsibility of the position is to support the GNSO Council in the smooth running of the GNSO policy process. Job duties include: Liaise with the chair and members of the Council to understand current issues of importance to the GNSO Council Assist the GNSO Council with the development of a charter or terms of reference for policy Task Forces Convene meetings of the Task Forces with the assistance of the GNSO Secretariat Prepare reports as required in the policy process, including gathering and synthesising public feedback during the policy process Assist as needed with the finalisation and implementation of policy Qualifications Bachelors degree (with postgraduate qualifications desirable); at least five years experience in developing policy in an environment with conflicting stakeholder views; understanding of technical issues involving the Internet. Candidate must have excellent verbal and writing skills and be fluent in English in a policy environment; fluency in another language an advantage. Candidate must be able to work as a member of a team. Demonstrated success in working with the cultural and language issues that arise in an international business environment would be an advantage. Compensation Salary commensurate with experience and qualifications. ICANN offers a competitive benefits package, including retirement savings plan; employer paid medical, dental, vision, disability and life insurance; and paid vacation initially three weeks each year. ICANN's office environment is friendly and casual. Work hours are flexible. For further details about the position, click here. http://www.icann.org/general/gnso-policy-support-description-15aug03.pdf Please submit your resume and cover letter via e-mail to our staff at opportunities(a)icann.org.

1 0

WHOIS top 5 extended
by GNSO SECRETARIAT Sept. 5, 2003

Sept. 5, 2003

[To: council(a)dnso.org] [To: liaison6c(a)dnso.org] [To: whois-sc(a)dnso.org] Thursday, September 4, deadline has been extended to MONDAY 15 SEPTEMBER 2003 for the Whois Steering committee request to GNSO Constituencies to select 5 top issues from the Staff Manager's Issues Report on Privacy Issues Related to WHOIS. Thank you to those who did meet the September 4 deadline! GNSO Secretariat gnso.secretariat(a)gnso.icann.org

1 0

Final ICANN Security Committee Document on new GTLDs
by Neuman, Jeff Sept. 3, 2003

Sept. 3, 2003

All, This is the final document that was sent to the ICANN Public Comments list regarding new TLDs from the Security Committee. I think it does a great job in explaining the problems and recommending next steps. I believe this paper should be endorsed by the Council in addition to the work the GNSO will undertake. ---------- SUPPORT OF NEW TOP-LEVEL DOMAINS BY INTERNET INFRASTRUCTURE OPERATORS AND APPLICATION PROVIDERS ICANN Security and Stability Committee August 25, 2003 SUPPORT OF NEW TOP LEVEL DOMAINS There are now more than 2 million domain names that use one of the new Top Level Domains (TLDs) approved by ICANN in November 2000. These include several TLDs with 4 or more characters (.aero, .coop, .info, .name, and .museum). ICANN intends to expand the list of new TLDs, including a limited number of sponsored top-level domains this year. Such expansion may take place at regular intervals. Although the implementation of the new TLDs began in 2001, compatibility problems were found with the installed base of software used by Internet infrastructure operators (including Internet Service Providers (ISPs) and corporate network operators) and application providers (such as web hosting companies, ecommerce websites, and email services). The underlying DNS protocols can easily support the introduction of new TLDs into the top-level zone files. However, some of the software written to use domain names was written without taking into account the addition of new TLDs. This includes DNS resolvers, provisioning software (e.g., to facilitate the creation of web sites or email services), and end-user application software (e.g., email programs and web forms). Sometimes, as in the case of many DNS resolvers, a configuration change is all that is needed to support the new TLDs. Other times, as in the case of checking user input against expected behavior, there are problems because a fixed list of TLDs is used or TLDs are presumed to be at most three characters in length. Some web applications use algorithms that guess or attempt to automatically complete domain name entries (e.g., search engines, directories, browsers) when a fully qualified domain name is not supplied. Problems arise when these applications use an outdated list of TLDs, or attempt to redirect users to a different TLD when the user's intent was to lookup one of the new TLDs. There are many pieces of software used in the Internet that make use of domain names. The problem of checking all existing software for support of new TLDs is a similar problem to that of checking software for the ability to handle dates beyond 2000. RECOMMENDATIONS 1. ICANN should develop an advisory regarding support for new TLDs for display on their website, and the GNSO constituencies should publicise this advisory through their membership and customer bases. 2. ICANN should recommend that the IAB consider issuing an informational RFC advising of the issue, and publicising this through the IETF technical community. 3. Internet infrastructure providers that have their own customised software for Internet service provision should test the capability of the software to support new TLDs, and correct problems quickly where they are found. 4. Internet software application developers should be encouraged to review their software for support of new TLDs. Where problems are found, application developers should upgrade their software, and provide these updates to their user base. 5. A central repository of known commonly used software that has compatibility problems (e.g., DNS resolver software used by common operating systems) with new TLDs, and instructions for how to upgrade the software should be created. This repository would facilitate Internet infrastructure providers and software application developers to provide necessary software updates to users of the Internet to resolve known compatibility issues. 6. ICANN should examine compatibility problems with the introduction of new TLDs in 2001 as a topic in its Proof of Concept study.

1 0

ICANN website review: make surfing easier- please comment!
by GNSO SECRETARIAT Sept. 2, 2003

Sept. 2, 2003

[To: council(a)dnso.org; ga(a)dnso.org] [To: liaison6c(a)dnso.org] ICANN is beginning a review of its website. http://www.icann.org/announcements/announcement-14aug03.htm Your suggestions would be greatly appreciated. Kindly send your comments directly to <website-comments(a)icann.org> Answering the questions below would be of immense help to this process. 1) How often do you visit the ICANN website? 2) What categories of information do you look for? 3) What information may be less prominent on ICANN's website than you think it should be? 4) What parts of ICANN's website do you like? 5) What parts of ICANN's website do you not like? 6) Does the ICANN website load quickly or slowly? 7) Do you like documents to be available in both Adobe Acrobat Portable Document Format (.pdf) and HTML? 8) Other comments Thank you for your cooperation and time that you may spend on this. GNSO Secretariat

1 0