Alan and all, Well so again the GNSO punted! How typical, how utterly sad, and a demonstration of unable to either make a difinitive decision in a timely manner or so out of touch with the relevant issues that their leadership acumen is grossly in question... But, thank you Alan for passing this predictable information along anyway. -----Original Message-----

From: Alan Greenberg <alan.greenberg@mcgill.ca> Sent: May 12, 2008 8:04 PM To: At-Large <alac@atlarge-lists.icann.org> Cc: alac-internal <alac-admin@icann.org> Subject: [At-Large] Recent GNSO actions

There was a GNSO meeting on May 8, with several substantive actions, some of which could require ALAC involvement.

FRONT RUNNING

You will recall that Danny Younger drafted a letter to the Board requesting that the Board take immediate action regarding Front Running - the practice of learning that someone is thinking about registering a domain name and then registering it first. The information could be the result of a registrar being asked if a name is available and then being registered by that registrar, or by other more circuitous or nefarious means. Following drafting of the letter, and prior to its being forwarded to the Board, it was supported by the NARALO and then the ALAC.

The Board effectively decided that the issue did not require their immediate action and requested that the GNSO investigate and take appropriate action.

The GNSO Council decided that more information was needed to delineate the problem, understand whether there are existing rules that can be used to curb the practice, and understand what effect the recent Domain Tasting recommendation would have on the practice (by restricting the used of the AGP, it may effectively stop this purely speculative registration of domains). At the same time, there was a strong feeling that the issue should not be ignored or postponed indefinitely.

The following motion was passed by Council:

...

Motion 1 Front Running ======================

Create a drafting team to look at 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?

The goal is to bring a recommendation to the Council on whether to request an Issues Report or more extensive research effort and to define the terms of the report.

This team should bring its report in time for deliberations in Paris by 7 June 2008 or sooner if possible.

Team is open to constituency members. Liaisons are invited to participate

The motion carried unanimously by voice vote.

I presume that the work will be primarily e-mail, although there may be some conference calls. I will be happy to work with the drafting team on this, but I will be somewhat unavailable for conference calls after May 29th. If anyone else has a strong interest and knowledge of this, I would be happy to suggest to the GNSO that this person augment or replace me.

FAST FLUX

Fast Flux is a process whereby the DNS entry for a domain name is changed at a very high rate. Typically this is used by phishers to make it virtually impossible for a deceptive web site to be taken down, because there are in fact many such sites, making take-down actions very difficult or impossible.

The SSAC issued a report on Fast Flux in January 2008. It identified a number of actions that might help reduce the practice. These actions included some that might be within the scope of GNSO policy (and others that were not). The GNSO requested an Issues Report from staff in March (an Issues Report is the first step in the ICANN By-Law mandated GNSO policy development process).

There was a feeling on Council that this issue should be addressed with some urgency, but some councillors were a bit worried that the issues report (in line with the SSAC Advisory Report) did not clearly identify what actions were within GNSO scope, and that this differentiation should be done prior to starting a Policy Development Process (PDP). Ultimately the following motion was made and passed, which incorporated the identification of within-scope issues as its first stage.

...

Motion 2 Fast Flux ==================

Whereas, "fast flux" DNS changes are increasingly being used to commit crime and frustrate law enforcement efforts to combat crime, with criminals rapidly modifying IP addresses and/or nameservers in effort to evade detection and shutdown of their criminal website;

Whereas, the Security and Stability Advisory Committee has reported on this trend in its Advisory SAC 025, dated January 2008: http://www.icann.org/committees/security/sac025.pdf/

Whereas, the SSAC Advisory describes the technical aspects of fast flux hosting, explains how DNS is being exploited to abet criminal activities, discusses current and possible methods of mitigating this activity, and recommends that appropriate bodies consider policies that would make practical mitigation methods universally available to all registrants, ISPs, registrars and registries,

Whereas, the GNSO resolved on March 6, 2008 to request an Issues Report from ICANN Staff, to consider the SAC Advisory and outline potential next steps for GNSO policy development designed to mitigate the current ability for criminals to exploit the NS via "fast flux" IP and/or nameserver changes;

Whereas, the ICANN Staff has prepared an Issues Report dated March 25, 2008, http://gnso.icann.org/issues/fast-flux-hosting/gnso-issues-report-fast-flux-..., recommending that the GNSO sponsor additional fact-finding and research to develop best practices guidelines concerning fast flux `hosting, and to provide data to assist policy development and illuminate potential policy options.;

Whereas, ICANN should consider whether and how it might encourage registry operators and registrars to take steps that would help to reduce the damage done by cybercriminals, by curtailing the effectiveness of these fast flux hosting exploits.

...

The GNSO Council RESOLVES:

To initiate a Policy Development Process uniquely on the issues deemed in scope in the Issues report.

Motion carried with 8 votes in favour out of 20 votes present, exceeding the Bylaws minimum threshold of 'more than 33% of the Council members present' (Bylaws, AnnexA, Section 3.c)"

8 votes in favour: Philip Sheppard, Bilal Beiram, Mike Rodenbaugh, Ute Decker, Kristina Rosette, Tony Holmes, Tony Harris, Avri Doria (one vote each)

12 votes against: Robin Gross, Norbert Klein, Carlos Souza, Olga Cavalli (one vote each) Tim Ruiz, Jordi Iparraguirre, Edmon Chung, Chuck Gomes, Greg Ruth, Adrian Kinderis dropped off call at the time of the vote.

Absent: Cyril Chua, Tom Keller, Jon Bing

Following this, the GNSO needed to decide which of the By-Law mandated mechanisms to use to address the PDP. The first motion was to create a Task Force. This motion failed (presumably not because the issue was unimportant, but rather because the structure of a formal Task Force was too limiting).

Vote summary: -8 votes in favour: Philip Sheppard, Mike Rodenbaugh, Ute Decker, Kristina Rosette, Tony Holmes, Tony Harris, Greg Ruth, Avri Doria (one vote each) -12 votes against: Robin Gross, Norbert Klein, Carlos Souza, Olga Cavalli (one vote each), Tim Ruiz, Jordi Iparraguirre, Edmon Chung, Chuck Gomes (two votes each) -Bilal Beiram, dropped off at time of vote -Absent: Tom Keller (two votes) Cyril Chua, Jon Bing (one vote each)

In its place, a working group will be formed.

...

Motion 3 ===========

Whereas the motion to initiate a Task Force Failed

Resolved the Council will create a working group to fulfill the requirement of the PDP. A charter for that working group will be presented to the council by 22 May 2008 for approval at the 29 May 2008 meeting. The schedule for the constituency reports and the public comment will be included in that charter.

Although not a formal constituency, presumably the ALAC will be able to submit a Constituency Report if we desire, and to participate in this working group. If we plan to do this, we should start sooner rather than later.

INTER-REGISTRAR TRANSFER POLICY

The Inter-Registrar Transfer Policy (IRTP) is an existing consensus policy under review by the GNSO. A working group looked at the policy last year, and identified a number of ways that the policy could be improved. One of the ones deemed most important was related to the reasons for denial or transfer, and there is an ongoing PDP addressing this. The remaining issues were prioritized. It was felt that to attempt to address all of the issues in a single PDP would be to large (and too long) and effort, and would put too much work on a single group.

Accordingly it was decided to break the issues in to six groups and address them in five manageably-sized PDPs (and take no immediate action on those in the sixth group).

The full motion is attached (it includes a table that would not be handled well by e-mail). The motion passed unanimously.

Alan

Regretful Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827