[council] FW: Monthly Policy Update

[Glen de Saint Géry <Glen@xxxxxxxxx>]

FYI

ICANN's July Monthly Policy Update is included below.  It also will be posted 
(with hyperlinks) on ICANN's website at <http://www.icann.org/topics/policy/> 
and is available via online subscription.  To receive these updates directly 
each month, go to <http://www.icann.org/newsletter> and select "Policy Update" 
to subscribe.

Regards,
Denise Michel
ICANN VP, Policy

==============================

ICANN POLICY UPDATE - July 2008


CONTENTS

  1.  GNSO - IMPROVEMENTS
  2.  GNSO - DOMAIN NAME TASTING
  3.  GNSO - WHOIS
  4.  GNSO - INTER-REGISTRAR TRANSFER POLICY REVIEW
  5.  GNSO - FAST FLUX HOSTING
  6. MULTIPLE ENTITIES - DOMAIN NAME FRONT RUNNING
  7.  MULTIPLE ENTITIES - IDN ccTLDs
  8.  MULTIPLE ENTITIES - ICANN'S GEOGRAPHIC REGIONS
  9.  CCNSO - INTERNAL IMPROVEMENT PLANS
10.  AT-LARGE - PARIS MEETING
11.  AT-LARGE - AT-LARGE SUMMIT
12.  AT-LARGE - ELECTIONS
13.  ASO AC - GLOBAL POLICY PROPOSALS (ASNs, IPv4)
14.  SSAC - DNSSEC-CAPABLE NAME SERVER SURVEY
15.  SSAC - ANTI-PHISHING ACTIVITIES


Below are brief summaries of 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.  Comments and 
suggestions on how we can improve these efforts are most welcome and should be 
sent to policy-staff@xxxxxxxxx<mailto:policy-staff@xxxxxxxxx>.


1.     GNSO - IMPROVEMENTS

Recent Developments
On 26 June 2008, the ICANN Board approved all of the GNSO Improvement Report's 
recommendations, except for the recommendation on GNSO Council restructuring.  
The Board also requested that the GNSO convene a small working group on council 
restructuring and provide for the Board's consideration a consensus 
recommendation by 25 July 2008.

Next Steps
The public comment period on the Council's top-level GNO Improvements 
implementation plan is scheduled to close on 17 July 2008.  A small working 
group on GNSO Council restructuring has convened and expects to continue with 
its work.  Consistent with its Resolution, Board consideration of the future 
structure of the GNSO Council is expected to be resolved no later than at its 
28 August 2008 meeting.

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.

More Information
*    GNSO Improvements information page 
<http://www.icann.org/topics/gnso-improvements/>
*    Full GNSO Improvements Report 
<http://www.icann.org/topics/gnso-improvements/gnso-improvements-report-03feb08.pdf>
*    15 February 2008 Board resolution on GNSO Improvements 
<http://www.icann.org/minutes/resolutions-15feb08.htm#_Toc64545918>
*    Summary and Analysis of Comments on GNSO Improvements Report 
<http://forum.icann.org/lists/gnso-improvements-report-2008/msg00033.html>
*    GNSO Improvements - Top Level Plan, 21 June 2008 
<http://gnso.icann.org/drafts/gnso-improvements-top-level-plan-21jun08.pdf>
*    26 June Board resolution on GNSO Improvements 
<http://www.icann.org/minutes/resolutions-26jun08.htm - _Toc76113182>

Staff Contact
Rob Hoggarth, Senior Policy Director


2.     GNSO - DOMAIN NAME TASTING

Recent Developments
The ICANN Board approved the GNSO Council recommendation to curb abuse of the 
"add grace period" (AGP) for domain tasting, and also approved the draft budget 
for FY 2008-09, which includes language to curb domain tasting. Prior to Board 
approval, Staff prepared an initial "Implementation Advisory" on modifications 
to the AGP, which examined each component of the GNSO Council recommendation 
and identified particular implementation steps that should be considered to put 
the recommendation and the FY 09 Budget Plan in place.

Next Steps
Staff will be developing a detailed implementation plan for community review.

Background
The term "domain name tasting" refers to a situation where 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), that 
allows domains to 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. The practice is controversial because registrants who engage in it 
are able to temporarily register hundreds of thousands of domain names, 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.  On 17 April 2008, the GNSO Council by supermajority vote 
approved a recommendation that 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.

In addition, the provision that had been included previously in the ICANN draft 
budget for FY 2009 (applying the ICANN USD .20 annual fee to all new 
registrations) was modified to reflect the same threshold included in the GNSO 
Council recommendation.  This new language would apply the annual ICANN fee 
only to those 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.

More Information
*    Public comment request on Domain Tasting motion with summary of comments 
<http://www.icann.org/public_comment/#dt-motion-21may08>
*    GNSO Domain Tasting Issues Report, June 2007 
<http://gnso.icann.org/issues/domain-tasting/gnso-domain-tasting-report-14jun07.pdf>
*    Outcomes Report, October 2007 
<http://gnso.icann.org/drafts/gnso-domain-tasting-adhoc-outcomes-report-final.pdf>
*    Final Report, 4 April 2008 
<http://gnso.icann.org/issues/domain-tasting/gnso-final-report-domain-tasting-04apr08.pdf>
*    ICANN Board resolution on Domain Tasting 
<http://www.icann.org/minutes/resolutions-26jun08.htm#_Toc76113173>
*    Reference to relevant language in FY 09 Budget, see p. 20  
<http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun08-en.pdf>
*    16 June Staff Implementation Advisory on Domain Tasting 
<http://gnso.icann.org/issues/domain-tasting/gnso-domain-tasting-implementation-advisory-16jun08.pdf>

Staff Contact
 Liz Gasster, Senior Policy Counselor


3.     GNSO - WHOIS

Recent Developments
During the June 2008 Paris meeting, the GNSO Council voted to reconvene a group 
to review the study recommendations offered through the public comment period 
and the studies requested by the GAC and, based on those recommendations and 
the GAC request, prepare a concise list of hypotheses. The group has six (6) 
weeks to deliver this to the Council for consideration.

Next Steps
Following submission of 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
*    GNSO WHOIS Policy Work Web Page <http://gnso.icann.org/issues/whois/>
*    GAC Recommendations of 16 April 2008 
<http://www.icann.org/correspondence/karlins-to-thrush-16apr08.pdf>
*    Summary of Public Suggestions on Further Studies of WHOIS (updated 10 May 
2008 with GAC recommendations of 16 April) 
<http://gnso.icann.org/issues/whois/whois-study-suggestion-report-10may08.pdf>
*    25 June GNSO Council resolution on WHOIS 
<http://gnso.icann.org/resolutions/>

Staff Contact
Liz Gasster, Senior Policy Counselor


4.     GNSO - INTER-REGISTRAR TRANSFER POLICY REVIEW

Recent Developments
A GNSO drafting group addressing the first set of transfer denial reasons  
(called "Transfer PDP 1") 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) (see 
explanations below). The Council also decided to launch the new PDP on "New 
IRTP Issues" (aka "Set A" described below).

Next Steps
Following the public comment period regarding Transfer PDP 1, the Council will 
decide on whether to forward the two proposed texts as a Council Recommendation 
to the ICANN Board for modification of the IRTP provisions. Regarding the New 
IRTP Issues - Set A, a charter for a new working group is being developed and 
will be considered at the next GNSO Council meeting on 17 July 2008.

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.

Parallel to 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 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), which 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.

More Information
*    Draft Advisory 
<http://gnso.icann.org/issues/transfers/gnso-draft-transfer-advisory-14nov07.pdf>
*    Initial Report 
<http://www.icann.org/announcements/announcement-17mar08.htm>
*    Final Report < 
http://gnso.icann.org/drafts/final-report-irt-policy-09apr08.pdf>
*    Drafting group outcome < 
http://gnso.icann.org/issues/transfers/gnso-final-draft-denial-reasons-04jun08.pdf>
*    PDP Recommendations 
<http://gnso.icann.org/drafts/transfer-wg-recommendations-pdp-groupings-19mar08.pdf>
*    Issues Report, Set A 
(http://gnso.icann.org/issues/transfers/transfer-issues-report-set-a-23may08.pdf


 5.     GNSO - FAST FLUX HOSTING

Recent Developments
At its 25 June 2008 meeting, the GNSO Council initiated a fast flux policy 
development process and appointed a fast flux working group chair and Council 
liaison.

Next Steps
With assistance from Staff, a template for constituency statements is due 40 
days after the Working Group is initiated (5 August 2008), and constituency 
statements are then due 30 days after the template is released (no later than 4 
September 2008).  A Final Report will be submitted to the GNSO Council and 
posted for public comment at 90 days (target - 25 September 2008).

The Working Group's Final Report will discuss these questions 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. 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, 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
*    SSAC Report 025 on Fast Flux Hosting, January 2008 
<http://www.icann.org/committees/security/sac025.pdf>
*    Issues Report on Fast Flux Hosting, corrected 31 March 2008 
<http://gnso.icann.org/issues/fast-flux-hosting/gnso-issues-report-fast-flux-25mar08.pdf>
*    25 June GNSO Council resolution on Fast Flux Hosting 
<http://gnso.icann.org/resolutions/>

Staff Contact
Liz Gasster, Senior Policy Counselor


6.     MULTIPLE ENTITIES - DOMAIN NAME FRONT RUNNING

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
*    Original ALAC Correspondence Raising Front Running Issue 
<http://atlarge-lists.icann.org/pipermail/alac_atlarge-lists.icann.org/2008q1/003290.html>
*    SAC 022, SSAC Advisory on Domain Name Front Running, October 2007 
<http://www.icann.org/committees/security/sac022.pdf>
*    29 May 2008 Staff response to GNSO Council questions on Front Running 
<http://gnso.icann.org/correspondence/front-running-staff-response-to-gnso-council-08may-request-29may08.pdf>
*    25 June GNSO Council resolution on Front Running drafting team 
<http://gnso.icann.org/resolutions/>

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


7.     MULTIPLE ENTITIES - IDN CCTLDs

Recent Developments
The working group on IDN country code top level domains (IDNC WG) concluded its 
work and submitted to the ICANN Board a final report on feasible methods for 
timely (fast-track) introduction of a limited number of IDN ccTLDs associated 
with ISO 3166-1 two-letter codes while an overall, long-term IDN ccTLD policy 
is under development by the ccNSO. 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.

Next Steps
The IDNC WG Final Report has been posted for public comments. Staff will begin 
work on implementation issues in consultation with relevant stakeholders.

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 13 June 2008, the IDNC WG published a draft Final Report for discussion by 
the IDNC WG and the broader community. At the June 2008 Paris ICANN meeting, 
several workshops and meetings were conducted to discuss the draft Final 
Report, resulting in several revisions and the work necessary to enable the WG 
to submit its final report to the ICANN Board.

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 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
*    Board Proposal IDNC WG, the Final Report IDNC WG on Fast Track Process for 
IDN ccTLDs <http://www.icann.org/en/announcements/announcement-26jun08-en.htm>
*    IDNccPDP Announcement 
<http://www.icann.org/announcements/announcement-19dec07.htm>

Staff Contact
Bart Boswinkel, Senior Policy Advisor, ccNSO


8.      MULTIPLE ENTITIES - ICANN'S GEOGRAPHIC REGIONS

Recent Developments
ICANN Staff is soliciting input from Supporting Organizations and Advisory 
Committees.

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
*    ccNSO Working Group Report and Recommendations 
<http://ccnso.icann.org/workinggroups/ccnso-final-report-regions-wg-240907.pdf>
*    2 November 2007 ICANN Board Resolution 
<http://www.icann.org/minutes/resolutions-02nov07.htm#_Toc55609368>

Staff Contact
Robert Hoggarth, Senior Policy Director


9.     CCNSO - INTERNAL IMPROVEMENT PLANS

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 Processes WG 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 Participation WG, 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
*    Guidelines and ccNSO information <http://www.ccnso.icann.org/>
*    ccTLD Community Email List < 
http://www.ccnso.icann.org/about/charter-cctld-community-list.pdf>
*    ccNSO Participation Working Group 
<www.ccnso.icann.org/workinggroups/participationwg.htm<http://www.ccnso.icann.org/workinggroups/participationwg.htm>>
*    ccNSO Administrative Processes Working Group 
<http://www.ccnso.icann.org/workinggroups/processeswg.htm>

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


10.     AT-LARGE - PARIS MEETING

Recent Developments
Last month in Paris, At-Large concluded a highly productive series of meetings. 
 Highlights include:

*    Discussions on IDNs and new GTLDs at the ALAC's first meeting with the GAC;
*    Discussions on IDNs, New GTLDs, GNSO Improvements and future cooperative 
efforts at the ALAC's first meeting with the GNSO Council;
*    Discussions on Fast Track IDNs and Geographic Regions with the ccNSO 
Council;
*    The first meeting of the General Assembly of the European Regional 
At-Large Organisation (EURALO) (Regional At-Large Organizations - RALOs -- are 
the federations of At-Large user groups at the regional level);
*    Finalization of a statement to the ICANN Board on elements of the GNSO's 
New gTLD Policy Report;
*    Discussions in the At-Large community on how to create a structured, 
repeatable, bottom-up process for the development of ALAC policy statements to 
the Board;
*    Continued preparatory work on the At-Large Summit;
*    A well-attended and received workshop on the migration from IPv4 to IPv6;
*    Concentrated work and initial comments on the draft At-Large Review at two 
public sessions.

More Information
*    The European Regional At-Large Organisation (EURALO) 
<http://www.euralo.org>
*    ALAC Statement to the Board of ICANN on the GNSO New gTLD Policy's 
Objections Provisions 
<https://st.icann.org/gnso-liaison/index.cgi/AL-ALAC-MT-32-6-2%20ALAC%20Statement%20on%20New%20GTLD%20Policy%20Objections%20-%20EN.pdf?action=attachments_download;page_name=new_gtlds_documents;id=20080703094502-0-1736>

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


11.  AT-LARGE - AT-LARGE SUMMIT

Recent Developments
The ICANN Board approved funding for the At-Large Summit at its meeting in 
Paris last month. The Summit proposed by the At-Large community will bring 
together one representative from each of the worldwide community of Internet 
end-user groups participating in ICANN At-Large.  The Summit is tentatively 
scheduled to be held in conjunction with the 2009 ICANN meeting in Mexico City.

More Information
*    At-Large Summit proposal <https://st.icann.org/summit-wg>

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


12.  AT-LARGE - ELECTIONS

Recent Developments
The At-Large Advisory Committee (ALAC) Chair, Cheryl Langdon-Orr, opened the 
nominations for ALAC's ICANN Board Liaison position for the term that will 
commence at the close of the Cairo ICANN Meeting, in November 2008. The 
candidates include the incumbent, Wendy Seltzer, and Beau Brendler of Consumer 
Reports.  Members of the At-Large community will have a teleconference with the 
candidates prior to the vote.

An election also will be held in July 2008 for a vacant European seat on the 
ALAC.

A third of the members of ALAC will be up for election in advance of the Cairo 
ICANN meeting as part of the staggered election cycles adopted by the RALOs in 
2006 and 2007.

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


13.   ASO AC - GLOBAL POLICY PROPOSALS (ASNs, IPv4)

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. The policy proposal has been 
adopted by all RIRs and the final text submitted from the NRO Executive 
Committee to the ASO Address Council (ASO AC).  The proposal was forwarded to 
the ICANN Board for ratification on 13 June 2008.

Next Steps
The global policy proposal for ASNs has been posted for public comments on the 
ICANN website. Following the outcome of the public comments, the ICANN Board 
will decide on ratification of the policy within a 60-day period from the date 
of submission.

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. The proposal has been 
adopted within ARIN and is in discussion within the other RIRs, where it has 
reached consensus within AfriNIC and LACNIC.

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:
*    Background Report ASN 
<http://www.icann.org/announcements/proposal-asn-report-29nov07.htm>
*    Background Report IPV4 
<http://www.icann.org/announcements/proposal-ipv4-report-29nov07.htm>

Staff Contact
Olof Nordling, Director Services Relations


14.  SSAC - DNSSEC-CAPABLE NAME SERVER SURVEY

Recent Developments
SSAC continues to survey the availability of DNSSEC features amongst 
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. SSAC has received survey responses from about 40% 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 now published and contains responses 
from most major commercial DNS vendors. The initial results are encouraging 
-60% of products support DNSSEC core standards and have conducted 
interoperability testing. Tabularized results are online at 
http://www.icann.org/committees/security/sac030.htm.

Next Steps
SSAC will continue to collect information related to DNSSEC deployment status 
and intends to provide a more comprehensive report at the Cairo ICANN meeting.

More Information
*    SSAC <http://www.icann.org/committees/security/>

Staff Contact
Dave Piscitello, Senior Security Technologist


15.   SSAC - ANTI PHISHING ACTIVITIES

Recent Developments
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 has 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 to whom the 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
*    SAC028, Registrar Impersonation in Phishing Attacks, 26 May 2008 
<http://icann.org/committees/security/ssac-documents.htm>
*    Global Phishing Survey 2007 
<http://www.apwg.org/reports/APWG_GlobalPhishingSurvey2007.pdf>
*    SAC 032, Preliminary Advisory on DNS Response Modification, June 2008 
<http://www.icann.org/committees/security/sac032.pdf>

Staff Contact
Dave Piscitello, Senior Security Technologist


#  #  #