Skip to main content

ICANN POLICY UPDATE | Issue 4 - June 2008

The ICANN Policy Update is now available via online subscription. If you would like to receive these updates in your inbox each month, go to and select "Policy Update" to subscribe.

Below are brief summaries of a number of significant Internet policy issues that are being addressed by the ICANN community's bottom-up policy development structure, as well as other significant activities of interest. This latest monthly update is provided by ICANN's Policy Staff in response to community requests for periodic summaries of ICANN's policy work. Links to additional information are included below and we encourage you to go beyond these brief Staff summaries and learn more about the ICANN community's work. Our goal is to maximize transparency and broad community participation in ICANN's policy development activities.

This document is designed to accommodate ICANN issue veterans as well as new readers. Where appropriate, most issue briefings include Background, Recent Developments and Next Steps modules. As our work grows, our list of issues (and in some cases the issue briefs themselves) has expanded. Regular readers are invited to skip familiar background materials and go directly to recent developments and next steps.

We continue to investigate more effective and efficient ways to communicate the relevance, importance and status of ongoing issues to the ICANN community. Comments and suggestions on how we can improve these efforts are most welcome and should be sent to


Background: The ICANN Board is considering 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 ongoing commitment to its evolution and improvement, and follows an independent review of the GNSO and extensive public consultation. A working group appointed by ICANN's Board (BGC WG) has developed a comprehensive proposal (GNSO Improvements Report) to improve the effectiveness of the GNSO, including its policy activities, structure, operations and communications.On 15 February 2008, the Boardaccepted the GNSO Improvements Report for consideration and directed ICANN Staff to open a public comment forum on the Report, draft a detailed implementation plan in consultation with the GNSO, begin implementation of the non-contentious recommendations, and return to the Board and community for further consideration of the implementation plan. A GNSO Improvement Planning Team comprised of GNSO leadership and constituency representatives, ICANN Staff and a Board liaison participant was formed to develop a top-level implementation plan to structure the implementation efforts.

Recent Developments: On 19 May 2008, the GNSO improvements Planning Team produced a draft version of the GNSO Improvements Top Level Plan. The primary focus of the plan is the creation of two standing committees (GNSO Process and GNSO Operations) that would be responsible for ensuring that the substantive work of implementing the BGC WG recommendations is carried-out. The document is being circulated to the GNSO Council and to the community for discussions and further development.

Next Steps: Board action on the BGC WG Report could occur at the June Board meeting in Paris, France. The GNSO Council is scheduled to discuss the top-level implementation plan during the Paris meeting at the end of June. The goal, assuming the plan is approved by the Council, is to initiate the actual work of the standing committees.

More Information:

Staff Contact: Rob Hoggarth, Senior Policy Director


Background: The term "domain tasting" refers to a case when an entity registers a domain name and then tests to see if the name has sufficient traffic to generate more income than the annual registration fee (usually through the addition of pay-per-click advertising). If the address is deemed sufficiently profitable, it is kept. If not, the current "add grace period" (AGP) - where domains can be returned within five days without cost - is used to return the domain at no net cost to the registrant and no ICANN charge levied on the registrar. Among other reasons, the practice is controversial because registrants who engage in this behavior can typically register many hundreds of thousands of domain names under this practice, with these temporary registrations far exceeding the number of domain names actually licensed.

Over time, there has been a significant increase in the number of domains registered and returned prior to expiration of the AGP. A significant number of community members feel the AGP process presents a loophole that facilitates this conduct. In May 2007, ICANN's At-Large Advisory Committee (ALAC), asked the GNSO Council to review the issue. In October 2007, after significant fact finding and consideration, the GNSO Council launched a formal policy development process (PDP) on domain tasting and encouraged ICANN Staff to consider applying ICANN's annual transaction fee to all names registered and subsequently de-registered during the AGP. Subsequently, Staff included in the initial draft of ICANN's next fiscal year budget, a proposal to charge a fee for all domains added - including a substantial percentage of domains added and subsequently deleted during the AGP. Public discussion of the budget, and this proposal, is ongoing.

As part of the formal PDP process, an Initial Report was produced for public comment, outlining the problems caused by domain tasting, possible actions to be taken, and the arguments put forward for and against such actions. Public comments were incorporated into a draft Final Report posted on 8 February 2008.

On 6 March 2008, the GNSO Council considered a motion to curb the practice of domain tasting. The motion would prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Under the terms of the motion, an exemption from the limitation could be sought for a particular month, upon a showing of extraordinary circumstances detailed in the motion.

Public comments and constituency impact statements regarding the motion were solicited and incorporated into a Final Report for Council consideration at its 17 April 2008 meeting. The comments and constituency statements reflected a plurality of views on what should be done to eliminate abuse of the AGP to facilitate domain tasting and addressed three potential options including (1) views on the draft resolution itself; (2) views on eliminating the AGP entirely; and (3) views on the proposed ICANN budget changes.

Recent Developments: The GNSO Council approved the motion on 17 April 2008 by supermajority vote. The motion (now a GNSO Council recommendation by virtue of the supermajority vote) ispending Board consideration. Public comments were invited on the Council recommendation until 21 May 2008, and have been summarized by Staff.

In addition, the most recent ICANN draft budget for FY 2009 contains a new transaction fee provision that calls for the ICANN USD .20 annual fee to apply to all new registrations that exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater.

Next Steps: The Boardis expected to consider both the GNSO Council motion and the FY 09 budget proposal during its June meeting in Paris.

More Information:

Staff Contact: Liz Gasster, Senior Policy Counselor


Background: WHOIS services provide public access to data on registered domain names. That data currently includes contact information for Registered Name Holders. The extent of registration data collected at the time of registration of a domain name, 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 will 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 has solicited suggestions for specific topics of study on WHOIS from community stakeholders. Possible areas of study might include 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, or a comparative study of gTLD and ccTLD WHOIS.

A forum for public comments on suggestions for specific topics of study on WHOIS was open through 15 February 2008. Approximately 25 suggestions were received. A summary of those comments has been prepared. On 27 March the GNSO Council approved a motion to form a group of volunteers to: (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 will be asked to provide cost estimates to the Council; and (3) produce the list of recommendations with supporting rationale.

Recent Developments: 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 reflects 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) will be unlikely to persuade any stakeholders to modify existing strongly held positions. The second group of participants do believe further studies would be useful in informing the debate, and their recommendation includes 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 certain studies of WHOIS misuse, detailed further in the report.

Next Steps: During the Paris meeting, the Council will consider this report and provide additional direction to Staff on recommended data gathering and study requirements. Based on that direction, Staff will provide rough cost estimates for various components of data gathering and studies, if any are recommended by the Council. Subsequently, Council and Staff will consider what data gathering and studies should be pursued.

More Information:

Staff Contact: Liz Gasster, Senior Policy Counselor


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 that is now being reviewed by the GNSO.As part of that effort, the 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.

In an effort to get improvements on-line as soon as possible, the GNSO Council initiated a policy development process (Transfer PDP 1) to immediately clarify four specific issues regarding reasons for which a registrar of record may deny a request to transfer a domain name to a new registrar.In parallel with the 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, the group delivered a report to the GNSO Council that suggested clustering the issues for consideration in five new PDPs.

Recent Developments: ICANN Staff finalized and posted an Initial Report for public comment as part of the Transfer PDP 1 described above. The public comments received have been used by ICANN Staff to compile a Final Report for the GNSO Council's consideration of further steps to take in this PDP. At the GNSO Council meeting on 17 April 2008, a drafting group was launched to develop suggested text modifications in the current provisions. This group will report on its findings to Council following the group's last meeting on 4 June.

During its 8 May 2008 meeting, the GNSO Council adopted the structuring offiveadditional inter-registrar transfers PDPs as suggested by the drafting group(in addition to the ongoingTransfer 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), which has since been delivered to the Council.

Next Steps: At the June ICANN meeting in Paris, the Council will consider the Issues Report on Set A and decide on further steps to take. The Council will also consider the drafting group's report on the PDP on clarification of reasons for denial and resolve what the next steps should be for that PDP.

More Information:

Staff Contact: Olof Nordling, Manager, Policy Development Coordination


Background: Fast flux hosting is a term that refers to several techniques used by cyber criminals 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. The results of the study were published in January 2008 in the SSAC Advisory on Fast Flux Hosting and DNS (SAC 025). Because fast flux hosting involves many different players--the cybercriminals and their victims, ISPs, 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.

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.

Recent developments: At its 29 May 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?
  • Obtain expert opinion, as appropriate, on which areas of fast flux are in scope and out of scope for GNSO policy making.

Next Steps: The Working Group shall report back to Council within 90 days, with a report discussing these questions and the range of possible answers developed by the Working Group members. The Working Group report also will outline potential next steps for Council deliberation. These next steps may include further work items for the WG or policy recommendation for constituency and community comment and review and for Council deliberation.

More Information:

Staff Contact: Liz Gasster, Senior Policy Counselor


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 by some 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. 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, on 27 March 2008 the Chair of the ICANN Board referred the matter to the GNSO Council for additional information gathering and policy development, if necessary.

Recent Developments: The GNSO Council, at its 8 May 2008 meeting, approved a motion to create a drafting team. The team will work to develop a recommendation to the Council on whether to request an Issues Report or whether other research on domain name front running (including further defining the problem) should be pursued. The drafting team will consider questions such as:

  • How is the 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? 

Next Steps: The goal of the drafting team will be 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 the report.

More Information:

Staff Contact: Liz Gasster, Senior Policy Counselor


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 the potential for many 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.

7a. IDNC Working Group Pursues The IDN "Fast Track"

A joint IDNC Working Group (IDNC WG) was chartered by ICANN's Board to develop and report on feasible methods, if any, that would enable the introductionof 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-termprocess IDNccPDP (the ccNSO Policy Development Process on IDN ccTLDs) 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 parameters of:

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

A public workshop was held 11 February in New Delhi, India to discuss the DDIR and a comment period was opened on that document. The IDNC WG produced a first draft of the IDNC WG Methodology in the form of an Interim Report that has also been made available for public comment. Discussions on the methodology were held at the ICANN Regional Meeting in Dubai, UAE (1-3 April 2008) and public comments on the methodology were open until 25 April 2008.

Recent Developments: The IDNC WG has recently created several new opportunities for discussion of the WG methodology including at the RIPE meeting in Berlin, the APTLD meeting Kula Lumpur andthe LAAC TLD meeting in Bahia, Brasil. The IDNC WG also conducted several conference calls during May, and a face-to face meeting in Geneva, Switzerland with remote participation on 12 May.

Next Steps:A Draft Final Report, including recommendations of the IDNC WG will be published shortly for discussion at the ICANN Paris meeting.

More Information:

Staff Contact: Bart Boswinkel, Senior Policy Advisor

7b. ccNSO Comprehensive IDNccTLD Policy Development

Background: In parallel to considerations of a "fast track" approach, the ccNSOCouncil has initiated a comprehensive long-term policy development process for IDNccTLDs (referred to as the IDNccPDP). At its meeting in October 2007, the ccNSO Council resolved to call for an Issues Report to examine the need for an IDNccPDP to consider:

  • Whether Article IX of the ICANN bylaws applies to IDN ccTLDs associated with the ISO 3166-1 two letter codes, and if it does not then to establish if Article IX should apply.
  • Whether the ccNSO should launch a PDP to develop the policy for the selection and delegation of IDN ccTLDs associated with the ISO 3166-1 two-letter codes.

The Council formally requested that 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.

The GNSO and several other parties submitted comments regarding the proposal to set a comprehensive long-term policy development process for IDNccTLDs (referred to above as the IDNccPDP). An Issues Report will be submitted to the ccNSO Council and will form the basis for the Council's decision on whether or not to formally initiate the IDNccPDP.

Next Steps: Comments regarding the preparation of an Issues Reporton the IDNccPDP continue to be evaluated.

More Information: IDNccPDP Announcement:

Staff Contact: Bart Boswinkel, Senior Policy Advisor


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.

Recent Developments: The ICANN Board determined that because any change to ICANN Geographic Regions could have wide-spread effect in ICANN, the views of other Supporting Organizations and Advisory Committees should be sought by the Board. At its 2 November 2007 meeting in Los Angeles, 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. The Board directed ICANN Staff to summarize and analyze this input and prepare a report for consideration by the Board.

Next Steps: ICANN Staff has begun soliciting input from all Supporting Organizations and Advisory Committees. The results will be summarized and reported to the Board for consideration.

More Information :

Staff Contact : Robert Hoggarth, Senior Policy Director


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, a working group of the Council was established to propose administrative procedures for the ccNSO. The Council also approved creation of a new "authoritative" ccNSO email list. In addition, the ccNSO has been conducting a participation survey to understand better why ccTLDs do or do not participate in ccNSO meetings, and has developed a leaflet onparticipation both in the ccNSO and Regional Organisations.

Recent Developments: The ccNSO Council is internally reviewing the proposed new administrative procedures before they are sent out to ccNSO members for discussion at the ICANN Paris meeting. The procedures 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;
  • Guidelines for liaisons and observers with other ICANN related entities.

More Information:

Staff Contacts: Bart Boswinkel, Senior Policy Advisor and Gabriella Schittek, ccNSO Secretariat


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

  • Associación de Derecho Informático de Argentina (ADIAR): From Argentina, ADIAR is a group of legal professionals oriented towards Information Technology Law.
  • Pacific Community Networks Association (PCNA): From Canada, PCNA is one of several ALSs that work at the grassroots level helping individuals, especially in remote areas, get connected to the Internet and learn to use it effectively.
  • Association for Technology and Internet (APTI): From Romania, APTI's mission is to promote " the fair and lawful use of information society service,s and aims at protecting the Internet users against illegal activities and abuses that may occur on the Internet."

There are currently 101 total ALSs from every geographic region. Three additional applications are currently being reviewed.

More information: For information about joining ICANN'sAt-Large community, visit

Staff Contact: Nick Ashton-Hart, Director for At-Large


At-Large has been actively preparing for meetings in Paris with the Governmental Advisory Committee (GAC), the ccNSO Council, and the GNSO Council respectively. As part of that effort the At-Large Staff organised a series of briefings in early June on New GTLDs, the FY 09 Operating Plan and Budget, and Fast Flux Hosting.

At the ICANN Paris meeting, At-Large will receive additional briefings, and also will consider proposed At-Large input on new gTLDs, among other items. The At-Large New GTLDs Policy Working Group has been tasked with drafting input from the community on implementation planning for new GTLDs.

Also in Paris, the European Regional At-Large Organization (EURALO) will conduct its first General Assembly. It is expected to set a work plan for the coming year, as well as conduct nominations for the open ALAC seat recently vacated by the resignation of Veronica Cretu of Moldova.

More information: Full schedule details for At-Large at the ICANN Paris meeting may be found at

Staff Contact: Nick Ashton-Hart, Director for At-Large


Nominations are now open for ALAC's ICANN Board Liaison for the term beginning at the end of the Cairo ICANN meeting. Current nominees include the incumbent, Wendy Seltzer, and Beau Brendler of Consumer Reports. Nominations close on the eve of the Paris meeting.

Staff Contact: Nick Ashton-Hart, Director for At-Large


Background: Two significant global policy proposals on addressing matters continue to be actively studied and discussed within the addressing community. If they are (1) adopted by all Regional Internet Registries (RIRs), (2) verified by the Address Supporting Organization (ASO), and (3) subsequently ratified by the ICANN Board, the policies will govern the allocation of Internet addresses from the Internet Assigned Numbers Authority (IANA) to the RIRs. The two current proposals are described below.

Recent Developments -- Autonomous System Numbers (ASNs): ASNs are addresses used in addition to IP addresses for Internet routing. A new global policy proposal for ASNs would formalize the current procedure for allocation of ASNs and provides 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.

Next Steps: This new 4-byte proposal has been adopted by all RIRs. It will be forwarded to the ICANN Board for ratification by the ASO Address Council (ASO AC) after the Council has verified that each RIR's procedural steps have been duly followed. The final text has been submitted from the NRO Executive Committee to the ASO AC and a decision to forward the proposal to the ICANN Board is expected at the next ASO AC call on 12 June.

Recent Developments -- Remaining IPv4 address space: The IANA pool of unallocated IPv4 address blocks 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 all the RIR meetings (APNIC, ARIN, RIPE, LACNIC and AfriNIC) during the last four (4) months.

Next Steps: Discussions within RIPE and APNIC are not conclusive regarding the level of support for the proposal at this stage and may not be so until the next RIPE and APNIC meetings later in 2008.

More information:

Staff Contact: Olof Nordling, Manager Policy Development Coordination


Background: SSAC has begun a survey to determine the availability of DNSSEC features among commercial, open source, and publicly available name server software releases.A public notice web page (SAC030) announcing the survey has been published, The set of survey questions were sent to approximately 40 software vendors and developers.

Recent Developments: SSAC has received survey responses from about 25% of the vendors and products surveyed. The majority of responses come from commercial vendors. Soliciting survey responses from the Open Source community has been more difficult. The initial set of responses is being reviewed and will be published in early June.

Next Steps:A survey summary will be presented at the ICANN Paris meeting (pending sufficient responses).

More Information: SSAC

Staff Contact: Dave Piscitello, Senior Security Technologist


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.

Recent Developments: Following a one-month opportunity offered to the registrar community to review and comment, SAC028, "Registrar Impersonation in Phishing Attacks," was published 26 May 2008. The document was warmly received by the Anti Phishing Working Group, which hopes to factor some of SAC028's findings into the fast flux issues identification work being done for the GNSO.

ICANN Staff has also reviewed a new report 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 HTCIA (High Technology Crime Investigation Association) are provide valuable insights 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.

Staff suspects that public outcries to "take down" the 20 registrars and revise future registrar agreements to require registrars to do more to see that domains are used for legitimate purposes (or strengthen clauses in their UTAs) are forthcoming. In parallel, the Staff is continuing its work with phishing investigators and ICANN's compliance officers to exert pressure on one registrar (yes, among the 20) by issuing a steady stream of WHOIS inaccuracy claims.

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"""" is not an IDN."