Skip to main content
Resources

ICANN POLICY UPDATE | Issue 6 - August 2008

This page is available in:

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

Contents

  1. YOUR COMMENTS NEEDED ON POLICY ISSUES
  2. ICANN POLICY INFORMATION AT YOUR FINGERTIPS
  3. IMPROVING THE GNSO — AND ASSIGNING COUNCIL SEATS
  4. WHOIS — TO STUDY OR NOT TO STUDY?
  5. MAKING IT EASIER TO TRANSFER DOMAINS BETWEEN REGISTRARS
  6. HOW SHOULD WE DEAL WITH FAST FLUXING CYBERCRIMINALS?
  7. DOMAIN NAME FRONT RUNNING — IF IT'S PREVALENT, WHAT SHOULD BE DONE ABOUT IT?
  8. INTERNATIONALIZNG COUNTRY CODE TOP LEVEL DOMAINS
  9. IS IT TIME TO RE-CONSIDER ICANN'S GEOGRAPHIC REGIONS?
  10. CCNSO WELCOMES .DZ, .AM
  11. CCNSO IMPROVEMENT PLAN UNDERWAY
  12. AT-LARGE INVOLVEMENT IN ICANN CONTINUES TO GROW
  13. AT-LARGE — BRINGING AN INDIVIDUAL USER PERSPECTIVE TO POLICY DEVELOPMENT
  14. AT-LARGE ELECTIONS AND APPOINTMENTS
  15. NEW GLOBAL ASN POLICY TO BE IMPLEMENTED, FUTURE OF GLOBAL IPV4 POLICY UNCLEAR
  16. SSAC WORKING ON DNSSEC STATUS REPORT
  17. SSAC ANALYZES PHISHING
  18. SSAC REPORTS AND ADVISORIES AT A GLANCE

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 — ICANN PUBLIC COMMENT PERIODS CLOSING … AND OPENING SOON

Act now for an opportunity to share your views on:

  • Final Report of IDNC Working Group on ccTLD Fast Track Mechanisms — a report submitted to ICANN's Board on methods to enable the timely and efficient ("fast track") introduction of a limited number of non-contentious, internationalized, country code top level domains; the comment period ends 15 August 2008.
  • RAA Amendments — Since French and Spanish translations of proposed changes to the Registrar Accreditation Agreement were recently posted, Spanish and French speakers will have until 31 August 2008, to submit comments on the proposal.
  • Independent Review of the ALAC — ICANN is seeking public comment on an independent evaluator's assessment of ICANN's At-Large Advisory Committee (ALAC) and related structures that involve individual Internet users in ICANN. The comment period ends 12 September 2008 .

Look for public comments to open soon on:

A draft Issue Report on the ccNSO's IDN ccTLD policy development process is expected to be posted next month. For more information, please see the ccNSO'S previous announcement on the PDP.

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.

You 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. ICANN POLICY INFORMATION AT YOUR FINGERTIPS

Subscribe to the Policy Update

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. Starting this month, the Policy Update also is available in French and Spanish and you can subscribe to these versions from the ICANN subscriptions page. This service is free of charge to subscribers.

Upcoming issues of the Policy Update, will be available to the community in the six official languages of the United Nations on a trial basis to determine utility: English (EN), Spanish (ES), French (FR), Arabic (AR), Chinese (Simplified — siZH), and Russian (RU). for French and Spanish subscribers.

Policy Issue Briefs Now Available in Six Languages

In addition to English, Policy Issue briefs are now available in Arabic, Chinese, French, Russian, and Spanish. ICANN Policy Staff publishes Policy Issue Briefs as basic introductions to important areas of Internet policy development that are being addressed by the ICANN community's bottom-up, consensus based, policymaking structure. They are designed to accommodate newcomers to ICANN, as well as ICANN issue veterans who may desire basic information on an unfamiliar issue.

Currently, Policy Issue Briefs are available on Domain Name Monetization, Internationalized Domain Names (IDNs), New gTLDs, and WHOIS. To access translated Policy Issue Briefs, please visit the Policy Issue Briefs page, and click on the language bar at the top of the page, or simply click on the following links:

Policy Development Information Online

Policy Staff recently created an online Policy area to provide the public with easy access to general ICANN policy development information. In this area, visitors will find links to key areas of policy development, as well as links to ICANN Supporting Organizations and Advisory Committees and a list of ICANN Policy Staff. Policy Issue Briefs and other policy background materials are also linked on this page, with updates and additional materials planned for the near future.

Although the Policy Area is still under construction, the Policy Staff plans to use this "home base" at ICANN.org to provide more dynamic and useful policy development information once internal technology upgrades are in place.

Policy Staff Changes

Marika Konings recently joined ICANN's Policy Staff as Policy Director. Based in Brussels, Marika supports the Generic Names Supporting Organization (GNSO) and currently is working on the fast flux policy development process (PDP) with Liz Gasster, as well as on the inter-registrar transfers PDPs with Olof Nordling, as he transitions from the Policy Staff to become Director of Services Relations on ICANN's Services Staff.

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:

More Information

Contact ICANN Policy Staff at policy-staff@icann.org

3. IMPROVING THE GNSO — AND ASSIGNING COUNCIL SEATS

Recent Developments

The GNSO Council's public comment periodon their proposed Top-Level GNSO Improvements Implementation Plan closed on 17 July 2008. The Council chose to postpone a vote on the plan — and any improvement work — pending a determination of the future Council structure by the ICANN Board.

A GNSO working group formed by the Board was given 30 days to offer a consensus recommendation on how the Council should be structured. The Board recently received the working group's report 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.

Next Steps

The Board is scheduled to discuss the matter at its next meeting scheduled for 28 August 2008.

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 Planning Team 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. The plan was posted for public comment and only one submission was received. The GNSO continues to defer further consideration of, or action on, the plan contending that they should undertake no GNSO Improvements work until the Board decides on a new Council structure.

On 26 June 2008, the ICANN Board of Directors endorsed the recommendations of the BGC WG, with the exception of the BGC's recommendation on GNSO Council restructuring. Council restructuring has been hotly debated among GNSO constituencies and was the one element of the BGC WG report that garnered opposition. The Board asked the GNSO to convene the working group noted above in hopes that a consensus recommendation could be provided by 25 July for Board consideration. As directed by the Board, the GNSO working group consisted of one representative from the current NomCom appointees, one member from each GNSO constituency and one member from each liaison-appointing advisory committee.

More Information

Staff Contact

Rob Hoggarth, Senior Policy Director

4. WHOIS — TO STUDY OR NOT TO STUDY?

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 is meeting weekly and should conclude its work by the end of August 2008.

Next Steps

Once the group has submitted the list of hypotheses to the Council, the Council will then decide whether any potential studies should be further considered, and if so, identify hypotheses that it would like the Staff to determine cost, feasibility, potential methodology, and estimated time frames for testing.

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

5. MAKING IT EASIER TO TRANSFER DOMAINS BETWEEN REGISTRARS

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.

Recent Developments

Transfer Denial Reasons PDP

The proposals of the GNSO drafting group addressing transfer denial reasons #8 (the domain name was in the first 60 days of an initial registration period) and #9 (the domain is within 60 days of being transferred) were posted for public comments on 26 June 2008. One comment was received and sent to the GNSO Council for consideration.

New IRTP Issues — Set A

Regarding the PDP on New IRTP Issues, the Council adopted a charter for the new working group at its meeting of 17 July 2008. A call for volunteers for the Inter Registrar Transfer Policy - Part A PDP Working Group also was announced on 17 July 2008.

Next Steps
With the public comment period on transfer denial reasons #8 and #9 now closed, the Council will decide next on whether to forward the two proposed texts as a Council Recommendation to the ICANN Board for modification of the IRTP provisions. On the New IRTP Issues - Set A, the Working Group is expected to convene shortly to start its deliberations.

Background
Consistent with ICANN's obligation to promote and encourage robust competition in the domain name space, the Inter-Registrar Transfer Policy 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).

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

6. HOW SHOULD 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).

Next Steps

Constituency statements were due on 8 August 2008, and Staff plans to prepare an Initial Report by 19 August. 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 is a term that refers to several 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 — it is possible to imagine a variety of different 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

7. 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

8. INTERNATIONALIZNG COUNTRY CODE TOP LEVEL DOMAINS

Recent Developments

Comments are being sought on the report of the working group on IDN country code top level domains (IDNC WG) which recommends methods for timely ("fast-track") introduction of a limited number of IDN ccTLDs. ICANN Staff is working on "fast-track" implementation issues in consultation with relevant stakeholders.

Next Steps

ICANN Staff will summarize and take into account public comments, and will submit a detailed implementation report on the "fast-track" introduction of IDN ccTLDs to the Board in advance of the November 2008 ICANN Cairo meeting.

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 was submitted to the ccNSO Council and is the basis for the Council's ongoing IDNcc PDP discussions.

More Information

Staff Contact

Bart Boswinkel, Senior Policy Advisor, ccNSO

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

Recent Developments

ICANN Staff is soliciting input from Supporting Organizations and Advisory Committees on whether the Board should appoint a community-wide working group. The working group would review and offer proposals to resolve issues relating to the current definition of the ICANN Geographic Regions.

Next Steps

Input will be summarized and reported to the Board for consideration.

Background

An ICANN Board resolution in 2000 directed Staff to assign countries to geographic regions on the basis of the United Nations Statistics Division's current classifications, and introduced the concept of "citizenship" in relation to the definition of ICANN Geographic Regions. The ICANN Geographical Regions were originally created to ensure regional diversity in the composition of the ICANN Board and were subsequently expanded in various ways to apply to the GNSO, ALAC and ccNSO.

The ICANN Bylaws 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, the ccNSO has developed concerns about the Geographic Regions and related representational issues. 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 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

10. CCNSO WELCOMES .DZ, .AM

The ccNSO welcomes the ccTLD manager for .DZ (Algeria) and t he ccTLD manager for .AM (Armenia) to its membership. The ccNSO now has 79 members, an increase of 16 members since this time last year, and 13 since January 2008.

More Information

For information about joining the ccNSO, please visit http://ccnso.icann.org/applications/.

Staff Contact
Gabriella Schittek, ccNSO Secretariat

11. CCNSO IMPROVEMENT PLAN UNDERWAY

Recent Developments

At its June 2008 meeting in Paris, the ccNSO Council adopted new administrative procedures that include:

  • Guidelines for ccNSO Council meetings;
  • Guidelines for ccNSO general meetings;
  • Setting-up Working Groups and templates to assist drafting of charters;
  • Guidelines for Selection of Board seats 11 and 12, and election of ccNSO Council members by the ccNSO; and
  • Guidelines for liaisons and observers from other ICANN related entities.

Next Steps

The ccNSO's Processes Working Group will continue its work on a few more guidelines, including one to improve the participation of ccTLDs in ICANN's yearly strategic and operational planning processes.

Background

The ccNSO Council has initiated efforts to improve its work plans, administrative procedures and communications tools. As a result of a Council workshop held at the ICANN New Delhi meeting earlier this year, a working group of the Council was established to propose administrative procedures for the ccNSO. The Council also approved the creation of a new "authoritative" ccTLD managers email list. At the time of the Paris meeting, 95 ccTLD managers had subscribed. Subscription is open to ccTLD managers and any persons they designate to be on the list.

In addition, the ccNSO has been conducting a participation survey to understand better why ccTLDs do or do not participate in ccNSO meetings. The results of the survey were presented at the ccNSO meeting and will be published on the ICANN website. The ccNSO's Participation Working Group, in close cooperation with ICANN's Regional Liaisons, developed a leaflet on participation in both the ccNSO and Regional organizations. The leaflet was presented at the ICANN meeting in Paris last month.

More Information

Staff Contacts

Bart Boswinkel, Senior Policy Advisor, ccNSO and Gabriella Schittek, ccNSO Secretariat

12. AT-LARGE INVOLVEMENT IN ICANN CONTINUES TO GROW

In July, At-Large welcomed four new Internet end-user groups (referred to as 'At-Large Structures' or 'ALSs') to the At-Large community:

Asociación Colombiana de Usuarios de Internet (ACUI): From Colombia, ACUI is a well-established Internet users association with a long history of participation in Internet policy initiatives on a local and international level. It is interested in the Internet as a tool with the potential of bringing communities together and overcoming access to knowledge problems.

Moroccan Association of Civil Society for Information Society (MACSIS): From Morocco, MACSIS's members are unified by a desire to promote new technologies in their workplaces and surroundings. The membership is mostly constituted of academics and professionals with a general interest in the Internet.

Chinese Domain Name Users Alliance (CDNUA): From China, CDNUA is open to everybody interested in Chinese-character domain names. It helps to represent the interests of internationalized domain name registrants and users and serves as an interface between Chinese-character domain names users and international Internet Governance forums.

Internet Society of New York (ISOC NY): From the United States, the ISOC New York Chapter is dedicated to "To assure the beneficial, open evolution of the global Internet and its related internetworking technologies through leadership in standards, issues, and education." ISOC NY is also a member of the Non-Commercial Users Constituency in the GNSO.

There are currently 105 total ALSs from every geographic region. Two additional applications are currently being reviewed.

More Information

For information about joining ICANN's At-Large community, visit http://www.atlarge.icann.org/.

Staff Contact

Nick Ashton-Hart, Director for At-Large

13. AT-LARGE — BRINGING AN INDIVIDUAL USER PERSPECTIVE TO POLICY DEVELOPMENT

Recent Developments

At-Large currently is involved in several policy consultations:

  • At-Large members are active in the GNSO's Fast Flux and IRTP IRTP Working Groups.
  • GNSO Improvements: ALAC participated actively in the Board-mandated GNSO Council Restructuring Working Group throughout July and is preparing an Advisory from the ALAC to the Board on the subject. Alan Greenberg's statement on behalf of the ALAC is annexed to the Final Report of the Working Group.
  • RAA Amendments: The French and Spanish translations of the Draft Proposed Changes to Registrar Accreditation Agreement are now available. To ensure non-English speakers have an opportunity to comment, Spanish and French speakers will have until 31 August 2008, to submit comments on the draft changes, although the comment period ended recently for English respondents. There will be a briefing session later in August on the issue for At-Large, and the At-large RAA Working Group is expected to lead an effort to produce an ALAC Advisory to the Board on the subject.
  • ALAC review: At-Large is reviewing the Final Report submitted by the independent evaluator, and the Board Governance Committee's ALAC Review Working Group is scheduling time with each Regional At-Large Organisation (RALO) over the course of August to discuss the review. The ALAC is expecting to produce an Advisory on the subject for the Board thereafter, involving the worldwide At-Large community in that effort.

More Information

Staff Contact

Nick Ashton-Hart, Director for At-Large

14. AT-LARGE ELECTIONS AND APPOINTMENTS

At-Large worldwide is heading into a busy season of elections prior to the ICANN annual general meeting in Cairo:

  • As per ICANN's Bylaws, the ALAC is appointing five (5) voting members of the Nominating Committee, one from each Geographic Region, with input from the Regional At-Large Organisations. This process is to conclude at the end of August and the results conveyed to the Nominating Committee chair.
  • One member of the At-Large Advisory Committee from each Geographic Region will be up for election in September/October. Nomination periods for these seats are opening over the next few weeks.
  • The ALAC is in the process of choosing a Board Liaison for the coming year. The election will be concluded in the next few weeks.

More Information

For more information about At-Large, please visit http://www.atlarge.icann.org/.

Staff Contact

Nick Ashton-Hart, Director for At-Large

15. 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 was adopted by ARIN, and is in final call for comments at AfriNIC and LACNIC.

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 and APNIC for the proposed IPv4 allocation policy propsal is unclear, and discussions will continue at the next RIPE and APNIC meetings in late 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 ASNswas 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

16. 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

17. SSAC ANALYZES PHISHING

Background

The term phishing has been used to describe criminal and fraudulent attempts by bad actors to acquire sensitive private information, such as usernames, passwords and credit card details, by masquerading as trustworthy entities in an electronic communication. SSAC has been addressing this matter through several activities.

Following a one-month opportunity offered to the Registrar community to review and comment, SAC028, Registrar Impersonation in Phishing Attacks, was published on 26 May 2008. The document was well received by the Internet Policy Committee's Anti Phishing Working Group (APWG), which hopes to factor some of SAC028's findings into the fast flux issues identification work being done for the GNSO.

ICANN Staff also reviewed a new APWG report, Global Phishing Survey: Domain Name Use and Trends in 2007, that surveys and analyzes data related to phishing attacks during 2007. Of particular interest is the report's analysis of phishing distribution across ccTLDs and a rise in the use of subdomains for phishing attacks. This report and a second report presented at the High Technology Crime Investigation Association (HTCIA) provide valuable insight into the spam and phishing "hot spots." Using spam data collected since 2005 the HTCIA report concludes that 90% of illegal web sites are hosted at domains registered through just 20 registrars.

SSAC has concluded an initial study of a practice wherein a DNS operator may return a different DNS response message in response to a non-existent domain name error from the one that would reflect content the domain registrant intended to publish in its zone file. Two variants of this practice are described in SAC032, Preliminary Advisory on DNS Response Modification (June 2008) .

Parties that a registrant entrusts to host its zone file use the first variant, where the entrusted party creates a wild card resource record that resolves any name the registrant did not explicitly include in his zone file to an IP address of the entrusted party's choosing (typically a revenue generating or advertising page). The second variant is implemented by any operator of an iterative name server that processes a client's DNS query of a name in a domain. The operator intercepts and rewrites "name error" DNS responses so that the response signals "name exists" rather than the error the domain registrant intended to return. The DNS response from such an operator also redirects the client to an IP address of the DNS operator's choosing. Both variants create several troubling security and operational stability issues for domain registrants, and also create opportunities for phishing attacks.

More Information

Staff Contact

Dave Piscitello, Senior Security Technologist

18. SSAC REPORTS AND ADVISORIES AT A GLANCE

Recent Developments

SSAC has added executive summaries for most of its recent reports and advisories. The executive summaries aim to highlight the key issues and recommendations in plain language. The summaries offer an overview of the subject for those who need to stay abreast of security issues but only require a modest level of detail. Several additional SSAC documents are being translated into the five official languages of ICANN and will be made available in more languages in the near future.

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."