Skip to main content
Resources

ICANN POLICY UPDATE | Issue 7 - September 2008

This page is available in:

http://www.icann.org/en/topics/policy/

The ICANN Policy Update contains brief summaries of issues being addressed by the ICANN community's bottom-up policy development structure, as well as information on related policy development activities. The ICANN Policy Staff provides monthly updates in response to requests from the community for periodic summaries of ICANN's policy work. The goal of the Policy Update is to maximize transparency and encourage broad community participation in ICANN's policy development activities.

Links to additional information are included and readers are encouraged to go beyond these brief summaries to learn more about the ICANN community's work. As always, the Policy Staff welcomes comments and suggestions on how to improve its policy communications efforts. Please send these comments to policy-staff@icann.org.

1. YOUR COMMENTS NEEDED ON POLICY ISSUES

Act now for an opportunity to share your views on:

  • Inter-Registrar Transfer Policy Denials Definitions PDP – The GNSO Council sent to the ICANN Board for final approval changes to two of the nine reasons registrars can use to deny the transfer of a generic domain name. Final comments are being solicited before the Board acts. Comment forum closes 6 October.
  • Inter-Registrar Transfer Policy (IRTP) Issues – The GNSO is undertaking a broad review of the IRTP and is asking for public input on issues/questions relating to registrar exchange of registrant e-mail information, the potential need for including new forms of electronic authentication and potential provisions for "partial bulk transfers." Comment forum closes 29 September.

Look for public comments to open soon on:

More Information

This is not an exhaustive list of items open for public comment or items coming soon. Please go to ICANN's public comment page, where you will find information on how to submit your comments on numerous decisions being made by the ICANN community.

ou can also automatically receive notices on public comment periods by subscribing to an RSS feed of ICANN Announcements. To have these notices fed to your computer's desktop, simply visit http://www.icann.org/en/rss/news.rss, and click on "Subscribe Now."

2. WHERE IN THE WORLD IS THE POLICY STAFF

Members of the ICANN Policy Staff are often asked to present at various conferences and meetings that take place worldwide on topics concerning ICANN policy development activities. Whenever possible, the community can participate remotely in real-time by listening to these presentations live. With more frequency, recordings and presentation materials have been made available online following presentations, and are found in languages other than English. The Policy Staff will be presenting at the following meetings this month:

ccTLDs Registries and Registrars Meeting

September 8-10 in Sofia, Bulgaria

Dave Piscitello, Senior Security Technologist, is scheduled to give two presentations at the first international conference for ccTLD registries and registrars from the Commonwealth of Independent States (CIS), Central and Eastern Europe, to be held on 8-10 September 2008 in Sofia, Bulgaria. The first presentation will be an update on the activities of ICANN's Security and Stability Advisory Committee (SSAC). Dave will share the second presentation with Pat Cain of the Anti-Phishing Working Group (APWG), and will focus on the work of the APWG, and in particular, the Global Phishing Annual Report 2007.

Meeting of Regional Registries and Registrars

September 10 – 11 in Seoul, Republic of Korea

Liz Gasster, Senior Policy Counselor, is scheduled to give an update on ICANN policy issues at the regional meeting of ICANN-accredited registrars and gTLD registries in Seoul, Republic of Korea. The briefing has been translated into Chinese, Korean and Japanese, and it, along with its translations, will be made available on the Policy webpage in the very near future.

Internet Security Operations and Intelligence (ISOI5) Workshop

September 11 – 12 in Tallinn, Estonia

Following his presentations in Sofia, Dave Piscitello will make two additional presentations during the ISOI5 workshop. With valuable input from Stacy Burnette, ICANN Director, Contractual Compliance, Dave will explain ICANN's role and constraints when dealing with criminal activities that exploit the DNS and registration services. He will also again share a panel with Pat Cain of the APWG for a discussion on the Global Phishing Annual Report 2007.

More Information

3. ICANN POLICY INFORMATION ON DEMAND

The ICANN Policy Staff is constantly looking for new and better ways to make information about policy development activities and issues more accessible to the community. The following are examples of a few of the ways that you will be able to access policy information this month, and even participate, if you so choose.

* Telephonic Policy Briefings

Every month, the Policy Staff hosts various briefings on current policy issues that the community can attend. The briefings often focus on issues from the perspective of the individual Internet user, but are usually of general interest across all ICANN stakeholder communities. Each briefing is conducted via telephone with an Adobe Connect session that allows participants to follow the presentation, and chat with each other, as well as the presenter, online. Briefings are followed by a question and answer session, and generally feature simultaneous interpretation in English, Spanish and French. Recordings are available in all three languages, along with any presentation materials from the briefings.

September 17 (1300 to 1400 UTC) - DNS Response Modification

Dave Piscitello, Senior Security Technologist, will give a briefing on DNS Response Modification on Wednesday, 17th of September from 1300 to 1400 UTC. The briefing is sponsored by the At-Large Advisory Committee (ALAC), but all stakeholder communities are welcomed and encouraged to join. The SSAC032 Preliminary Report on DNS Response Modification has recently been translated into French and Spanish. It has not yet been linked from the SSAC web site yet, but you can find it on the page for this briefing at https://st.icann.org/alac/index.cgi?dns_response_modification. Links to the report in other languages are in More Information below.

More Information

Staff Contact

At-Large Staff at staff@atlarge.icann.org.

* Subscribe to the Policy Update in English, French and Spanish

The ICANN Policy Update is posted on ICANN's website and available via online subscription. If you would like us to send these updates directly to your inbox each month, simply go to the ICANN subscriptions page, enter your e-mail address, and select "Policy Update" to subscribe. This service is free of charge to subscribers.

Last month, we also released to subscribers the first French <http://www.icann.org/fr/topics/policy/update-aug08-fr.htm> and Spanish <http://www.icann.org/es/topics/policy/update-aug08-es.htm> versions of the Policy Update. Like the English version, you can subscribe to the French and Spanish versions from the ICANN subscriptions page. In the near future, and on a trial basis to determine utility, we will make the Policy Update available to the community in all six official languages of the United Nations: English (EN), Spanish (ES), French (FR), Arabic (AR), Chinese (Simplified – siZH), and Russian (RU).

More Information

Staff Contact

ICANN Policy Staff at policy-staff@icann.org

* What's on the Calendar for today?

Keep up-to-date on what's happening in ICANN policy development by visiting the online calendars of ICANN's policy development bodies. Three of the most active calendars include:

4. GNSO IMPROVEMENTS – TWO FOR ONE

Recent Developments

In one of the final steps of the GNSO Improvements process, the ICANN Board devoted most of its 28 August 2008 meeting to a thorough discussion of the future structure of the GNSO Council. The Board approved a single body - bicameral voting structure as proposed by a special GNSO working group. The Board also established the size and composition of the two voting houses that will be used by the community to identify, discuss, manage and develop solutions to various gTLD policy and operational issues. The Board assigned Council seats as follows and asked the GNSO to submit for Board approval an implementation plan to transition the Council to this new structure by January 2009:

  • 6 seats to the "contracted party house" -- 3 representatives from each stakeholder group in this house -- Registrars and Registries, plus 1 voting Nominating Committee appointee; and
  • 12 seats to the "non-contracted party" house -- 6 representatives from the commercial stakeholder group and 6 representatives from the non-commercial stakeholder group, plus 1 voting Nominating Committee appointee.
  • 1 Nominating Committee appointee whose role and voting status is still to be determined.

Next Steps

The Board is scheduled to discuss the remaining GNSO Council restructuring matters at its next meeting scheduled for 30 September 2008. Staff is soliciting additional input on the remaining matters. The GNSO Council is expected to expeditiously follow-up on a variety of implementation matters including establishing a new GNSO policy development process and creating a new working group model to effectuate future policy development

Background

The ICANN Board has approved a comprehensive set of recommendations to improve the structure and operations of the Generic Names Supporting Organization (GNSO). This effort is part of ICANN's own ongoing commitment to evolve and improve, and follows an independent review of the GNSO by the London School of Economics and others, as well as extensive public consultation.

A working group of the ICANN Board Governance Committee (BGC WG) developed and presented these recommendations in a GNSO Improvements Report that includes ways to improve the effectiveness of the GNSO's policy development activities, structure, operations and communications. At the February 2008 Board meeting in New Delhi, the Board accepted the Report for consideration, and directed ICANN Staff to post it for public comment, draft a detailed implementation plan in consultation with the GNSO, begin implementation of the non-contentious recommendations, and then return to the Board and community for further consideration.

The GNSO Council subsequently formed a GNSO Improvement Planning Team (Planning Team), comprised of GNSO leadership, constituency representatives, ICANN Staff and a Board liaison participant, in order to develop a top-level implementation plan to organize and manage the implementation effort. On 19 May 2008, the Planning Team produced a draft version of the GNSO Improvements Top Level Plan. The plan focuses on the creation of two standing committees, GNSO Process and GNSO Operations, which would be responsible for ensuring that the work of implementing BGC WG recommendations is carried out.

On 26 June 2008 the ICANN Board of Directors endorsed the recommendations of the Board Governance Committee's (BGC) GNSO Review Working Group, with the exception of the BGC's recommendation regarding GNSO Council restructuring. The Board asked the GNSO to convene a special working group on Council restructuring and said that the group "should reach consensus and submit a consensus recommendation on Council restructuring by no later than 25 July 2008 for consideration by the ICANN Board as soon as possible." (see ICANN Board Resolution 2008.06.26.13. As directed by the Board, the group has consisted of one representative from the current NomCom appointees, one member from each GNSO constituency and one member from each liaison-appointing advisory committee.

The working group convened on 4 July 2008 and deliberated exhaustively during seven conference call meetings and extensively via email through midnight on 25 July and into the next day in an effort to develop a consensus recommendation for Board consideration. The report of the working group was formally accepted by the Board at its 31 July meeting. The Board was highly appreciative of the working group's efforts and instructed ICANN Staff to (1) perform an analysis of implementation issues presented by the consensus proposals in the report and (2) report back to the Board by August 21 with an implementation review and recommendations regarding those implementation issues.

More Information

Staff Contact

Rob Hoggarth, Senior Policy Director

5. WHOIS – HYPOTHESIS GROUP REPORT NOW A REALITY

Recent Developments

During the June 2008 Paris meeting, the GNSO Council voted to reconvene a group to review the WHOIS study recommendations offered through the public comment period and the studies requested by the Governmental Advisory Committee (GAC) and, based on those recommendations and the GAC request, prepare a concise list of hypotheses that could be the subject of research. The group completed its work and sent a WHOIS Study Hypothesis Report to the GNSO Council on 26 August 2008.

Next Steps

On 4 September 2008, the GNSO Council voted to ask Council representatives to forward the report to their respective constituencies for discussion and comment as applicable and be prepared on 25 September 2008 to develop a proposed list, if any, of recommended studies for which ICANN Staff will be asked in the Council meeting to prepare cost estimates to the Council.

Background

WHOIS services provide public access to data on registered domain names, data that currently includes contact information for Registered Name Holders. The extent of registration data collected at the time a domain name is registered, and the ways such data can be accessed, are specified in agreements established by ICANN for domain names registered in generic top-level domains (gTLDs). For example, ICANN requires accredited registrars to collect and provide free public access to (1) the name of the registered domain name and its name servers and registrar, (2) the date the domain was created and when its registration expires, and (3) the contact information for the Registered Name Holder including the technical contact, and the registrant's administrative contact.

WHOIS has been the subject of intense policy development debate and action over the last few years. Information contained in WHOIS is used for a wide variety of purposes. Some uses of WHOIS data are viewed as constructive and beneficial. For example, sometimes WHOIS data is used to track down and identify registrants who may be posting illegal content or engaging in phishing scams. Other uses of WHOIS are viewed as potentially negative, such as harvesting WHOIS contact information to send unwanted spam or fraudulent email solicitations. Privacy advocates have also been concerned about the privacy implications of unrestricted access to personal contact information.

The GNSO Council decided in October 2007 that a comprehensive, objective and quantifiable understanding of key factual issues regarding WHOIS would benefit future GNSO policy development efforts, and plans to ask the ICANN Staff to conduct several studies for this purpose. Before defining the details of these studies, the Council solicited suggestions for specific topics of study on WHOIS from community stakeholders, with possible areas of study including: a study of certain aspects of gTLD registrants and registrations; a study of certain uses and misuses of WHOIS data; a study of the use of proxy registration services, including privacy services; and a comparative study of gTLD and ccTLD WHOIS. A public comment forum was opened through 15 February 2008, in order to solicit suggestions for specific topics of study on WHOIS. Approximately 25 suggestions were received, and a summary of comments was prepared.

On 27 March 2008, the GNSO Council convened a group of volunteers to do the following : (1) review and discuss the Report on Public Suggestions on Further Studies of WHOIS; (2) develop a proposed list of recommended studies, if any, for which ICANN Staff would be asked to provide cost estimates to the Council; and (3) produce the list of recommendations with supporting rationale.

On 22 May 2008, the WHOIS study group delivered its report to the Council. In addition to considering the recommendations solicited from the public, the group also considered recommendations offered by the Governmental Advisory Committee (GAC) for WHOIS studies. The report reflected two opposing viewpoints among participants. A significant number of participants believe that no further studies should be conducted because further study (and the resulting information) would be unlikely to persuade any stakeholders to modify existing strongly held positions. The second group of participants believe further studies would be useful in informing the debate, and their comments include specific recommendations for further study in three primary areas: 1) the availability of privacy services; 2) the demand and motivation for the use of privacy services; and 3) certain studies of WHOIS misuse, detailed further in the report.

More Information

Staff Contact

Liz Gasster, Senior Policy Counselor

6. MAKING IT EASIER TO TRANSFER DOMAINS BETWEEN REGISTRARS

Recent Developments

The Inter-Registrar Transfer Policy (IRTP) aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another. As part of a broader review of this policy, two Policy Development Processes (PDPs) are currently ongoing: one on transfer denial reasons and one on new Inter-Registrar Transfer Policy issues, which includes questions relating to the exchange of registrant e-mail information, the potential for including new forms of electronic authentication and potential provisions for "partial bulk transfers." Additional detail is found in the Background section below.

Transfer Denial Reasons PDP

Following the GNSO Council call on 7 August, the Council members were invited to bring the outcome of the drafting group regarding the IRTP PDP on Clarification of Reasons for Denial to the attention of their Constituencies for any position preparations needed. The topic is expected to be addressed at the next Council call, 4 September, with a view to finalize the PDP with a vote on a Council recommendation regarding new text proposals for Denial Reasons #8 (the domain was in the first 60 days of an initial registration period) and #9 (a domain name is within 60 days of being transferred).

New IRTP Issues – Set A

The Working Group started its deliberations on 5 August 2008 and is currently working on finalizing a template for constituency responses to the charter questions and a timetable outlining the different steps in this PDP.

Next Steps

Transfer Denial Reasons PDP

The GNSO Council is expected to vote on a Council recommendation regarding new text proposals for Denial Reasons #8 and #9 on 4 September 2008.

New IRTP Issues – Set A

Following the finalization of the template for constituency responses, a public comment period will be opened on the IRTP Part A – New IRTP Issues.

Background

Consistent with ICANN's obligation to promote and encourage robust competition in the domain name space, the Inter-Registrar Transfer Policy (IRTP) aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another should they wish to do so. The policy also provides standardized requirements for registrar handling of such transfer requests from domain name holders. The policy is an existing community consensus that was implemented in late 2004 and is now being reviewed by the GNSO. As part of that effort, the GNSO Council formed a Transfers Working Group (TWG) to examine and recommend possible areas for improvements in the existing transfer policy. The TWG identified a broad list of over 20 potential areas for clarification and improvement.

The IRTP performs a critical function but the specific terms of the policy can be arcane and the work to clarify them complex. In an effort to deal with that complexity while moving to get clarifications and improvements on-line as soon as possible, the Council initiated a policy development process (Transfer PDP 1) to immediately examine four specific issues from the broader list that addressed reasons for which a registrar of record may deny a request to transfer a domain name to a new registrar. The IRTP currently enumerates nine (9) specific reasons why a registrar can deny a transfer. Those issues identified as needing clarification included the following:

  • "No payment for previous registration period" (Denial Reason #5);
  • "A domain was already in "lock" status" (Denial Reason #7);
  • The domain was in the first 60 days of an initial registration period (Denial Reason #8); and
  • A domain name is within 60 days of being transferred (Denial Reason #9)

ICANN Staff finalized and posted an Initial Report for public comment as part of this PDP and used public comments received to compile a Final Report for the Council's consideration on further steps to take. At the GNSO Council meeting on 17 April 2008, a drafting group was launched to develop suggested text modifications for the four transfer denial reasons. The drafting group addressing this first set of transfer denial reasons reported on its findings to the GNSO Council. The Council resolved on 25 June 2008 to post the proposals for transfer denial reasons #8 and #9 for public comments, while deferring denial reasons #5 and #7 to be handled in a future transfer policy development process (PDP C). The proposals of the GNSO drafting group addressing transfer denial reasons #8 and #9 were posted for public comments on 26 June 2008. One comment was received and sent to the GNSO Council for consideration.

Parallel to the above PDP process, the Council tasked a short term planning group to evaluate and prioritize the remaining 19 policy issues identified by the Transfers Working Group. In March 2008, the group delivered a report to the Council that suggested combining the consideration of related issues into five new PDPs. On 8 May 2008, the Council adopted the structuring of five additional inter-registrar transfers PDPs as suggested by the planning group (in addition to the ongoing Transfer PDP 1 on the four reasons for denying a transfer). The five new PDPs will be addressed in a largely consecutive manner, with the possibility of overlap as resources permit.

The Council requested an Issues Report from Staff on the first of the new PDP issue sets (Set A – New IRTP Issues) that has since been delivered to the Council. The three "new" issues in Set A address (1) the potential exchange of registrant email information between registrars, (2) the potential for including new forms of electronic authentication to verify transfer requests and avoid "spoofing," and (3) to consider whether the IRTP should include provisions for "partial bulk transfers" between registrars. The GNSO Council resolved on 25 June 2008 to launch a PDP ("PDP June-08") on these issues and adopted a charter for a Working Group on 17 July 2008.

More Information

Staff Contact

Marika Konings, Policy Director

7. HOW DO WE DEAL WITH FAST FLUXING CYBERCRIMINALS

Recent Developments

At its 25 June 2008 meeting, the GNSO Council initiated a fast flux policy development process and created a Working Group on this issue. The Working Group approved a template to solicit constituency statements and has been meeting weekly to consider the questions on fast flux raised by the Council (see bullets below). The deadline for constituency statements was extended to 20 August 2008. Staff has prepared a draft Initial Report that was transmitted to the Working Group for further consideration on 2 September.

Next Steps

Following publication of the Initial Report, public comments and a second round of constituency statements will be solicited (target completion by 25 September). These comments will be considered in the development of a Final Report, due to the GNSO Council for its consideration by 15 October 2008.

The Working Group's Final Report will discuss the questions outlined below and the range of possible answers developed by its members. The Report also will outline potential next steps for Council deliberation. These next steps may include further work items for the Working Group or policy recommendation for constituency and community review and comment, and for Council deliberation.

Background

Fast flux hosting refers to techniques used by cybercriminals to evade detection in which the criminals rapidly modify IP addresses and/or name servers. The ICANN Security and Stability Advisory Committee (SSAC) recently completed a study of fast flux hosting. Because fast flux hosting involves many different players — the cybercriminals and their victims, Internet service providers, companies that provide web hosting services, and DNS registries and registrars — there are many potential approaches to mitigation. Most of these will require the cooperation of a variety of actors, and some will be outside of ICANN's scope.

On 26 March 2008, Staff posted an Issues Report on fast flux hosting, as directed by the GNSO Council. In the Report, Staff recommends that the GNSO sponsor additional fact-finding and research to develop best practices concerning fast flux hosting. Staff also notes that it may be appropriate for the ccNSO to participate in such an activity.

At its 8 May 2008 meeting, the GNSO Council formally launched a policy development process (PDP), rejected a task force approach and called for creation of a working group on fast flux. Subsequently, at its 29 May 2008 meeting, the GNSO Council approved a working group charter to consider the following questions:

  • Who benefits from fast flux, and who is harmed?
  • Who would benefit from cessation of the practice and who would be harmed?
  • Are registry operators involved, or could they be, in fast flux hosting activities? If so, how?
  • Are registrars involved in fast flux hosting activities? If so, how?
  • How are registrants affected by fast flux hosting?
  • How are Internet users affected by fast flux hosting?
  • What technical (e.g. changes to the way in which DNS updates operate) and policy (e.g. changes to registry/registrar agreements or rules governing permissible registrant behavior) measures could be implemented by registries and registrars to mitigate the negative effects of fast flux?
  • What would be the impact (positive or negative) of establishing limitations, guidelines, or restrictions on registrants, registrars and/or registries with respect to practices that enable or facilitate fast flux hosting?
  • What would be the impact of these limitations, guidelines, or restrictions to product and service innovation?
  • What are some of the best practices available with regard to protection from fast flux?

The group also will obtain expert opinion, as appropriate, on which areas of fast flux are in scope and out of scope for GNSO policy making.

More Information

Staff Contact

Liz Gasster, Senior Policy Counselor and Marika Konings, Policy Director

8. DOMAIN NAME FRONT RUNNING – IF IT'S PREVALENT, WHAT SHOULD BE DONE ABOUT IT?

Recent Developments

At its 8 May 2008 meeting, the GNSO Council approved a motion to create a drafting team to consider questions such as the following:

  • How is the [domain name front running] problem defined?
  • How prevalent is the problem?
  • Will the measures relating to domain tasting affect front running?
  • Are there rules within the RAA that can be used to address this activity? 

The goal of the drafting team was to bring a recommendation to the Council on whether to request an Issues Report or a more extensive research effort that could help to define the terms of reference for further work. Subsequently, on 29 May 2008, ICANN Staff recommended that more information be obtained about other research activities that may be contemplated or underway (such as possible research by the SSAC and by ICANN) before proceeding with work by this drafting team. At the GNSO Council meeting on 25 June 2008, the Council accepted this recommendation and voted to put the drafting team effort on hold until current research efforts are completed.

At its June 2008 meeting in Paris, the ccNSO Council asked the ccNSO Secretariat to produce a high–level overview on front-running to allow further ccNSO discussion.

Next Steps

The GNSO Council may consider further work once current research efforts are completed, and the ccNSO Council will consider the Staff overview and related material.

Background

Domain name front running is the practice whereby a domain name registrar uses insider information to register domains for the purpose of re-selling them or earning revenue via ads placed on the domain's landing page. This practice is also sometimes referred to as domain reservation or cart-hold or cart-reserve. By registering the domains, the registrar locks out other potential registrars from selling the domain to a customer. The registrar typically uses the 5-day add grace period (AGP), during which the domain can be locked without permanent payment.

On 27 March 2008, after being alerted to the issue by (1) industry input, (2) a Security and Stability Advisory Committee report, and (3) a letter from the At-Large Advisory Committee to the ICANN Board requesting emergency action, the Chair of the ICANN Board referred the matter to the GNSO Council for additional information gathering and policy development, if necessary.

More Information

Staff Contact

Liz Gasster, Senior Policy Counselor, GNSO, and Gabriella Schittek, ccNSO Secretariat

9. INTERNATIONALIZING COUNTRY CODE TOP LEVEL DOMAINS

Recent Developments

The comment period on the report of the working group on IDN country code top level domains (IDNC WG) has closed. Policy Staff has summarized and published the comments. The IDNC WG recommends methods for timely ("fast-track") introduction of a limited number of IDN ccTLDs, and Staff is working on "fast-track" implementation issues in consultation with relevant stakeholders.

Next Steps

Staff will submit a detailed implementation report on the "fast-track" introduction of IDN ccTLDs to the Board in advance of the November 2008 ICANN meeting in Cairo, and currently is preparing a request for information as recommended by the IDNC WG

Background

The potential introduction of Internationalized Domain Names (IDNs) represents the beginning of an exciting new chapter in the history of the Internet. IDNs offer many potential new opportunities and benefits for Internet users of all languages around the world by allowing them to establish domains in their native languages and alphabets.

An IDN ccTLD (internationalized domain name country code top level domain) is a country code top-level domain (corresponding to a country, territory, or other geographic location as associated with the ISO 3166-1 two-letter codes) with a label that contains at least one character that is not a standard Latin letter (A through Z), a hyphen, or one of the standard numerical digits (0 through 9). The technical potential for ICANN to now make these domain names available for assignment is prompting significant discussion, study and demand within the ICANN community – particularly for territories and communities who want to make use of non-Latin characters. Current efforts are taking place on two fronts: (1) efforts to identify a "fast track" process to provide new domain opportunities to territories with immediate justifiable needs; and (2) efforts to develop a comprehensive long term plan that ensures a stable process for all interested stakeholders.

The joint IDNC WG was chartered by ICANN's Board to develop and report on feasible methods, if any, that would enable the introduction of a limited number of non-contentious IDN ccTLDs, in a timely manner that ensures the continued security and stability of the Internet while a comprehensive long-term IDN ccTLD policy is being developed. On 1 February 2008, the IDNC WG posted a Discussion Draft of the Initial Report (DDIR) for public comment and input from the ICANN community. The DDIR clarified the relationship between the "fast track" process and the broader long-term ccNSO Policy Development Process on IDN ccTLDs (IDNccPDP), and also identified the mechanisms for the selection of an IDN ccTLD and an IDN ccTLD manager. The ccNSO Council determined that those mechanisms were to be developed within the following parameters:

  • The overarching requirement to preserve the security and stability of the DNS Compliance with the IDNA protocols;
  • Input and advice from the technical community with respect to the implementation of IDNs; and
  • Current practices for the delegation of ccTLDs, which include the current IANA practices.

On 25 June 2008, the IDNC WG published its Final Report for submission to the Board. At the June 2008 Paris meeting, the Board directed Staff to: (1) post the IDNC WG final report for public comments; (2) commence work on implementation issues in consultation with relevant stakeholders; and (3) submit a detailed implementation report, including a list of any outstanding issues, to the Board in advance of the November 2008 ICANN Cairo meeting.

In parallel to considerations of a "fast track" approach, the ccNSO Council initiated a comprehensive long-term policy development process for IDNccTLDs (referred to as the IDNcc PDP). The ccNSO Council formally requested an Issues Report on 19 December 2007 and directed ICANN Staff to identify policies, procedures, and/or by-laws that should be reviewed and, as necessary revised, in connection with the development and implementation of any IDN ccTLD policy – including efforts designed to address the proposed fast-track concept. According to the ICANN bylaws, the creation of the Issue Report is the second step in launching the IDN ccPDP. The final step is the decision of the ccNSO Council to initiate the ccPDP. The ccNSO Council has reaffirmed its request for a draft Issues Report to be available at 16 September.

The GNSO and several other parties submitted comments regarding a proposed IDNcc PDP. The Issues Report will submitted to the ccNSO Council before the Cairo meeting and is the basis for the Council's ongoing IDNcc PDP discussions.

More Information

Staff Contact

Bart Boswinkel, Senior Policy Advisor, ccNSO

10. IS IT TIME TO RE-CONSIDER ICANN'S GEOGRAPHIC REGIONS?

Recent Developments

A number of ICANN communities are preparing to share their views with Staff about a proposal to form a special ICANN working group to review the ICANN Geographic Regions structure. The structure is an important component of the ICANN system and a review is timely. Staff recently reached out to get community input for Board consideration.

Next Steps

Staff is planning to collect and summarize community input on the working group concept and report that information to the Board. The Board expects a preliminary report from Staff this month.

Background

An ICANN Board resolution in 2000 directed Staff to establish a system of geographical regions to ensure regional diversity in the composition of the ICANN Board by assigning countries to geographic regions on the basis of the United Nations Statistics Division's current classifications. The system was subsequently expanded in various ways to apply to various ICANN community structures including the GNSO, ALAC and ccNSO.

The ICANN Bylaws currently define five geographic regions as Africa, North America, Latin America/Caribbean, Asia/Australia/Pacific and Europe -- and also expand the concept that "persons from an area that is not a country should be grouped together with the country of citizenship for that area" so that the area or territory itself was similarly allocated to the region of the "mother country."

Over time, various community members have developed concerns about the ICANN Geographic Regions and related representational issues. Late last year, the ccNSO Council passed a resolution recommending that the ICANN Board appoint a community-wide working group to further study and review the issues related to the definition of the ICANN Geographic Regions, to consult with all stakeholders and submit proposals to the Board to resolve the issues relating to the current definition of the ICANN Geographic Regions.

The ICANN Board determined at its 2 November 2007 meeting in Los Angeles, California that because any change to ICANN Geographic Regions could have widespread effect in ICANN, the views of other Supporting Organizations and Advisory Committees should be sought by the Board. The Board asked the ICANN community, including the GNSO, ccNSO, ASO, GAC, and ALAC, to provide the ICANN Staff with input on the ccNSO Council's resolution relating to ICANN's Geographic Regions.

More Information

Staff Contact

Robert Hoggarth, Senior Policy Director

11. CCNSO MEETING CAIRO

Recent Developments

For the first time and in accordance with its new guidelines the ccNSO sent out a first draft agenda for the ccNSO meeting at the ICANN meeting in Cairo. The focus of the meeting will be on security and stability issues as they relate broadly to IDNccTLDs. Sessions are tentatively scheduled on DNS vulnerability, ICANN's registry failover plan, and a third session on anti-phishing. Regarding IDN ccTLDs, the proposed implementation plan for the IDN ccTLD "fast track" process, and the IDN ccPDP Issues Report will be discussed.

Next Steps

The ccTLD community is requested to propose other items Based on the feed-back received the ccNSO Council will set the agenda for the ccNSO meeting.

More Information

Staff Contacts

Gabriella Schittek, ccNSO Secretariat

12. AT-LARGE FOCUSES ON RAA AMENDMENTS, REGISTRANT RIGHTS AND RESPONSIBILITIES

Recent Developments

At-Large's Registrant-Registrar Relations Working Group (RRA-WG) developed a final draft of the At-Large community's response to the proposed Registrar Accreditation Agreement (RAA) Amendments, and posted it for community comment.

Next Steps

The At-Large Advisory Committee (ALAC) will vote on the response and it will be transmitted it to the Board, if approved.

Concurrently, a call has gone out for interested members of the community to work on the first draft of a "Registrant Bill of Rights and Responsibilities." The idea for creating such a document in concert with the Registrar Constituency was proposed by the ALAC in an advisory to the Board in August 2007. This suggestion was put forward for community comment as part of the recently concluded consultation on changes to the Registrar Accreditation Agreement. A newly formed At-Large working group (RRR-WG) intends to work with the Registrar Constituency on this project.

More Information

Staff Contact

At-Large Staff at staff@atlarge.icann.org.

13. EUROPEAN ALAC MEMBERS ELECTED FOR 2008-09 WITH MORE TO COME

Recent Developments

The European Regional At-Large Organisation (EURALO) became the first of the five RALOS to conclude elections of its ALAC members for the term beginning after the Cairo ICANN Meeting. Sebastien Bachollet of France was re-elected to the ALAC, and Patrick Vande Walle of Belgium will join him. Each of the other four RALOs will elect one representative in advance of the Cairo ICANN meeting. One Nominating Committee appointee each from North America and Europe will fill-out the ALAC and will start their two-year terms at the Cairo ICANN meeting.

More elections are underway in the At-Large community: the ALAC will be electing the Liaison to the Board this month; and various RALOs will be electing or re-electing officers for the forthcoming year.

More Information

Staff Contact

At-Large Staff at staff@atlarge.icann.org

14. NEW GLOBAL ASN POLICY TO BE IMPLEMENTED, FUTURE OF GLOBAL IPV4 POLICY UNCLEAR

Recent Developments - Autonomous System Numbers (ASNs)

On 31 July 2008, the ICANN Board unanimously ratified the global policy for Autonomous System Numbers, and instructed Staff to implement it.

A proposed policy to allocate the remaining IPV4 address blocks was discussed at the most recent meetings of all Regional Internet Registries (RIRs), including APNIC, ARIN, RIPE, LACNIC and AfriNIC. The proposal has been adopted by ARIN and LACNIC, and is in final call for comments in AfriNIC, RIPE and APNIC.

Next Steps

As instructed by the Board, ICANN Staff will pursue the implementation of the ASN policy as ratified. The level of support within RIPE for the proposed IPv4 allocation policy proposal remains unclear, and discussions may continue at the next RIPE meeting in October 2008.

Background

ASNs are addresses used in addition to IP addresses for Internet routing. The new global policy proposal for ASNs will formalize the current procedure for allocation of ASNs and provide a policy basis for the transition from 2-byte (16 bits) to 4-byte (32 bits) ASNs. The final transition step is now foreseen for 31 December 2009, after which date the distinction between 2- and 4-byte ASNs will cease and all ASNs will be regarded as of 4-byte length, by appending initial zeroes to those of 2-byte original length. The policy proposal was adopted by all RIRs, submitted from the NRO Executive Committee to the ASO Address Council (ASO AC), and forwarded to the ICANN Board for ratification on 13 June 2008. The global policy proposal for ASNs was posted for public comments on the ICANN website 16 June – 7 July 2008. On 31 July 2008, the ICANN Board unanimously ratified the proposal as a global policy and instructed Staff to implement the policy.

IPv4 unallocated address blocks in IANA's pool continues to be depleted. As previously announced, a new global policy has been proposed to allocate the remaining address blocks once a given threshold is triggered. The text of the proposed policy essentially recommends that when there are five /8 blocks remaining in the IANA pool, one remaining block will be allocated to each RIR. The proposal has been discussed at the most recent meetings of all RIRs (APNIC, ARIN, RIPE, LACNIC and AfriNIC). The proposal has been adopted within ARIN and reached consensus within AfriNIC and LACNIC where the proposal is in final call for comments.

More Information

Staff Contact

Olof Nordling, Director Services Relations

15. SSAC WORKING ON DNSSEC STATUS REPORT

Recent Developments

SSAC continues to work on a comprehensive status report on Domain Name Security Extensions (DNSSEC), a deliverable SSAC committed to produce for the community in SAC026, SSAC Statement to ICANN and Community on Deployment of DNSSEC. The report will include discussions on the availability of DNSSEC on commonly used DNS server platforms, DNSSEC compatibility testing of broadband access equipment, trust anchor repositories, and key rollover processes. SSAC expects to make the report available for the ICANN meeting in Cairo in November 2008.

Next Steps

SSAC will begin studies on DNSSEC performance and error analysis, and review the current standards for protocol completeness.

More Information

Staff Contact Dave Piscitello, Senior Security Technologist

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."