April 2008 - council - lists.icann.org

RE: [council] Fast Flux Hosting
by Tim Ruiz April 16, 2008

April 16, 2008

Mike, The requirement to vote within 15 days can be dealt with by adding something like *whereas based on the Staff's recommendation the GNSO Council has chosen not to initiate a PDP at this time* or something like that. To initiate a PDP would be ignoring the Staff's recommendations that we specifically asked for. The motion said: *ICANN Staff shall prepare an Issues Report with respect to 'fast flux' DNS changes, for deliberation by the GNSO Council. Specifically the Staff shall consider the SAC Advisory [SAC 025], and shall outline potential next steps for GNSO policy development designed to mitigate the current ability for criminals to exploit the DNS via 'fast flux' IP or nameserver changes.* In the report, over and over again, the Staff recommends further study. And the GC specifically states that *the overall question of how to mitigate the use of fast flux hosting for cybercrime is broader than the GNSO policy development process.* So the very issue the motion requested the report on is not within scope. Philip suggests we make the PDP about those *some aspects relating to the subject of fast flux hosting* that are within scope. What are they? The report does not make it clear what they are. The furter research and study that the report recommends is what is needed in order to identify them. When we initiate a PDP we start a clock ticking. If we initiate a PDP on yet unknown *aspects* with the idea that identifying them is the first step, we are guaranteeing that we won't stay within the PDP timeline. I don't see the point in that. Tim -------- Original Message -------- Subject: RE: [council] Fast Flux Hosting From: "Mike Rodenbaugh" <mxrodenbaugh(a)yahoo.com> Date: Thu, April 10, 2008 7:24 pm To: "'Council GNSO'" <council(a)gnso.icann.org> Tim, I noted the Staff's recommendation and included it in a 'whereas' clause. Yet there appears no reason to delay a PDP for factfinding, since a PDP can begin with that work. Of course, this is a very time-sensitive issue as hundreds of phish attacks are launched every week, increasingly many of them using fast flux techniques. I also noted the comments apparently from ICANN Counsel with respect to scope. It seems that after this next step, Counsel may wish to give an opinion as to the outcome up to that date, so that GNSO Council does not waste time deliberating potential recommendations that are out of its scope. However, I believe my motion does not raise issues outside the scope of the GNSO. The bylaws require us to vote whether to initiate a PDP, within 15 days of the Issues Report. Only 1/3 of present Councilors needs to vote in favor of initiating a PDP after an Issues Report. I am curious to hear others' thoughts on my motion, these issues, and any reasoning as to why we should delay or forego initiation of a PDP, before deciding whether to accept your friendly amendment. Thanks, Mike -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Tim Ruiz Sent: Thursday, April 10, 2008 11:42 AM To: 'Council GNSO' Subject: RE: [council] Fast Flux Hosting Mike, Why does a PDP need to be initiated to gather the information you suggest? In fact, the Staff report specifically recommends *that the GNSO sponsor further fact-finding and research* before considering whether or not to initiate a formal PDP. Also, the GC opinion on whether or not this is in scope says that while *some aspects* are within scope, *the overall question of how to mitigate the use of fast flux hosting for cybercrime is broader than the GNSO policy development process.* Would you be agreeable to an intended friendly amendment to change the opening sentenc after RESOLVES to: *To initiate a Working Group of interested stakeholders and Constituency representatives...* Failing that amendment, I believe we would then need a Supermajority in favor of the motion to initiate a PDP. Tim -------- Original Message -------- Subject: [council] Fast Flux Hosting From: "Mike Rodenbaugh" <mxrodenbaugh(a)yahoo.com> Date: Thu, April 10, 2008 12:42 pm To: "'Council GNSO'" <council(a)gnso.icann.org> Hello, I propose the following motion for Council consideration in our next meeting on April 17th, may I please have a 'second'? Thanks, Mike Rodenbaugh 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- 25mar08.pdf, 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 in accord with the ICANN Bylaws, by forming a Task Force of interested stakeholders and Constituency representatives, to collaborate broadly with knowledgeable individuals and organizations, in order to develop potential policy options to curtail the criminal use of fast flux hosting. The Task Force initially shall 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? ..How are registry operators involved in fast flux hosting activities? ..How are registrars involved in fast flux hosting activities? ..How are registrants affected by fast flux hosting? ..How are Internet users affected by fast flux hosting? ..What 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? The Task Force shall report back to Council within 90 days, with a report discussing these questions and the range of possible answers developed by the Task Force members. The Task Force report also shall outline potential next steps for Council deliberation.

5 11

RE: [council] Fast Flux Hosting - re stated motions
by Tim Ruiz April 16, 2008

April 16, 2008

> To initiate a Policy Development Process uniquely on > the issues deemed in scope in the Issues report. What are the issues deemed to be in scope? The report does not elaborate on what those are. The report does say the GC's opinion is that *some aspects relating to the subject of fast flux hosting are within scope of the ICANN policy process* but does detail those aspects except to say "as fast flux hosting activities concern gTLDs, the issue is within the scope of the GNSO to address.* What the report is actually recommending is further research. We can do that without initiating a PDP on yet unknown *aspects* that might apply to gTLDs. What our resolution asked for was *potential next steps for GNSO policy development designed to mitigate the current ability for criminals to exploit the DNS via "fast flux" IP or nameserver changes.* The report specifically states *the overall question of how to mitigate the use of fast flux hosting for cybercrime is broader than the GNSO policy development process.* So what we asked for is clearly deemed out of scope. Any vote to initiate a valid PDP based on this issues report requires a Supermajority. I don't understand the insistance on a PDP when we can initiate the recommended research and fact-finding without one. Tim -------- Original Message -------- Subject: [council] Fast Flux Hosting - re stated motions From: "Philip Sheppard" <philip.sheppard(a)aim.be> Date: Wed, April 16, 2008 2:45 am To: "'Council GNSO'" <council(a)gnso.icann.org> Avri, you are right and the situation is no different to any PDP. I suggest this: MOTION 1 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- 25mar08.pdf, 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. (This will require a 33% vote) MOTION 2 Whereas Council has decided to launch a PDP on fast flux hosting; The GNSO Council RESOLVES: To form a Task Force of interested stakeholders and Constituency representatives, to collaborate broadly with knowledgeable individuals and organizations, in order to develop potential policy options to curtail the criminal use of fast flux hosting. The Task Force initially shall 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? ..How are registry operators involved in fast flux hosting activities? ..How are registrars involved in fast flux hosting activities? ..How are registrants affected by fast flux hosting? ..How are Internet users affected by fast flux hosting? ..What 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? The Task Force shall report back to Council within 90 days, with a report discussing these questions and the range of possible answers developed by the Task Force members. The Task Force report also shall outline potential next steps for Council deliberation. (This will require a 50% vote)

3 2

Revised Draft GNSO Council minutes 27 March 2008
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG April 16, 2008

April 16, 2008

[To: council[at]gnso.icann.org] Dear Council Members, Attached, please find the revised draft minutes of the GNSO Council teleconference held on 27 March 2008. The following phrase in: Item 11 Report on Single-Character Domain Names at the second-level Overview by Patrick Jones "At this stage, Staff was looking for the Council's input on the document and identifying experts who could create an allocation model for community discussion. Patrick Jones has been changed to read: "At this stage, Staff was looking for the Council's input on the document and finalizing its search to retain an auction design expert or experts who could develop a model for community consideration." Please let me know if you would like any other changes made. Thank you very much. Kind regards, Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Draft GNSO Council minutes 27 March 2008
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG April 16, 2008

April 16, 2008

[To: council[at]gnso.icann.org] Dear Council Members, Attached, please find the draft minutes of the GNSO Council teleconference held on 27 March 2008. Please let me know if you would like any changes made. Thank you very much. Kind regards, Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Follow up re: Soliciting Information on Previous New GTLD Rounds
by John Jeffrey April 11, 2008

April 11, 2008

As discussed during the meeting in Los Angeles today.... http://www.icann.org/topics/background-info-newgtld-apps-13feb08.htm Background Information Regarding Previous New GTLD Application Rounds 13 February 2008 In planning for implementation of the new gTLD policy recommendations, and in response to inquiries form the ICANN community, ICANN is conducting a review of the status of applications from the New gTLD round in 2000 that were not selected for negotiations.... John Jeffrey john.jeffrey(a)icann.org

1 0

compute visual similarity of tlds - link to algorithm
by Denise Michel April 11, 2008

April 11, 2008

http://hissa.nist.gov/~black/GTLD/tldVisualSimilarity.html as requested during new gTLD discussion. Regards, Denise

1 0

GNSO/Staff discussions on new gTLDs at LA meeting on 11 April 2008
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG April 11, 2008

April 11, 2008

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] Please find the MP3 recording of the GNSO /Staff discussions on new gTLDs at a face to face meeting in Los Angeles on Friday morning, 8:00 to 13:00, 11 April 2008. http://audio.icann.org/gnso/gtld-1.mp3 The afternoon session recording will be posted when the session is over. REMOTE PARTICIPATION: Keith Drazek, Edward Viltz, Jeff Neumen, Danny Younger, Michael Palage, Hal Lubsen, Thomas Lowenhaupt, Cheryl Langdon-Orr, David Maher,Lyman Chapin, Colin Strutt, Amadeu Abril l Abril, Beau Brendler Attendees Robin Gross, Norbert Klein - NCUC, Dirk Krischenowski - dot Berlin, Roger Castillo -.lat, Eric Brunner-Williams, Werner Staub -CORE Dan Schindler -CentralNic, Kristina Rosette, Steve metalitz - IPC, J. Scott Evans - IPC, Mike Rodenbaugh, Marilyn Cade - CBUC, Adrian Kinderis, Paul Stahura, James Bladel, Jon Nevett - RR, Avri Doria - NomCom GNSO Chair, Chuck Gomes - Ry GNSO Vice chair, Greg Ruth - ISP, Ken Stubbs, Ray Fassett - Ry, Olga Cavalli - NomCom, Richard Tindall - Demandmedia Staff John Jeffrey, Dan Halloran, Craig Schwartz, Olof Nordling, Karla Valente, Denise Michel, Karen Lentz -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

ICANN Posts Schedule for Paris Meeting 22-26 June
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG April 11, 2008

April 11, 2008

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] ICANN Posts Schedule for Paris Meeting 22-26 June http://www.icann.org/announcements/announcement-2-09apr08.htm 9 April 2008 ICANN today posted the schedule http://par.icann.org/schedule for its public Meeting to be held in Paris 22-26 June. "With two and a half months to go, there are some important changes to the schedule that attendees need to know." said Paul Levins, Executive Officer and Vice President, Corporate Affairs. First, the meeting will end on Thursday the 26 of June. Historically the Board meeting has been held on the Friday morning of these meetings. That has involved an additional day's time and expense by participants. In response to feedback and in the interests of economy, this meeting will see the Board meeting take place on Thursday evening with the meeting ending that night". Mr Levins said. "Furthermore, ICANN is keen to encourage participation by all stakeholders and at this meeting we will be holding a series of sessions identified on the agenda as Business Access Agenda targeted at the business community" said Paul Levins. "Finally we will be holding sessions dealing with the work of the President's strategy group, new gTLDS and the future, workshops on IDN fastrack, IPV6, protection of registrants, GNSO improvements implementation, Review of the At-Large Advisory Committee and translation." "We look forward to welcoming all attendees at Paris for what should be a fruitful and engaging meeting" Levins said. -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

RE: [council] Fast Flux Hosting
by Tim Ruiz April 11, 2008

April 11, 2008

Mike, We are all concerned about the problem, and the questions in your motion are valid and should be answered. But they should be answered BEFORE we initiate a PDP so we know what we're initiating a PDP on so that any resultant policy will have some measure of impact. Bottom line, the issue we asked about in the motion for the issues report is deemed to be out of scope. The report doesn't elaborate on what would be in scope. If you insist on putting this motion forward as is, it requires a Supermajority. If you are truly interested in getting something done, I suggest we first start with the research you suggest. And that doesn't require that we start a PDP. Tim -------- Original Message -------- Subject: RE: [council] Fast Flux Hosting From: "Mike Rodenbaugh" <mxrodenbaugh(a)yahoo.com> Date: Fri, April 11, 2008 9:46 am To: "'Council GNSO'" <council(a)gnso.icann.org> Tim and Tom, I appreciate your thoughts on this. You seem to raise only procedural objections. We ought to start the process of policy development ASAP, because this is a serious problem causing lots of harm. So let's get the procedural issues out of the way, and move forward. It seems we agree that the first step in the process is to put together a more complete factual record, in response to the questions posed by Staff in the Issues Report. In order to do that most comprehensively and effectively, we will need broad participation from GNSO constituencies and from other interests (private and public law enforcement, in particular). In order to best secure that participation, there ought to be a formal PDP underway so that people know their work is more likely to be meaningful and therefore they are more likely to participate. The terms of reference for this PDP have been narrowly tailored to remain in scope of the GNSO. Any suggested recommendations of the Task Force can then be reviewed to ensure they are in scope, before they are debated or deliberated by the Council in the next phase of the PDP. While it would be wonderful to have unanimous consensus to kick off a PDP, it is not necessary and is unrealistic with this issue as with so many others. Registrars nevertheless ought to participate in a Task Force, and hopefully they will come to understand that nobody aims to impose undue burdens on them with respect to this issue. Rather, the PDP would get a broad and knowledgeable group together to discuss the factual realities, and brainstorm about what reasonably might be done to potentially address the problem at the registry and registrar levels of the DNS. It may turn out that there is nothing that ought to be done, but at least GNSO will have taken a formal look at this (at SSAC's request), and come to that reasonable conclusion as quickly as it reasonably could. I fear that your alternative proposal would only amount in excessive delay with little or no upside benefit. We tried that approach with domain tasting. That was not necessary as the 'ad hoc' factfinding could have been the first step in a formal PDP. Had it been, the issue most likely would have resolved the same way in the Council, but several months more quickly. Thanks, Mike -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Thomas Keller Sent: Friday, April 11, 2008 4:33 AM To: 'Tim Ruiz'; 'Council GNSO' Subject: AW: [council] Fast Flux Hosting Mike, I have to agree with Tim, we do not need a PDP to do the fact finding you suggest in your motion. I personally would like to follow the staff recommendation for further research. Once we have a better picture of what the actual scope of the PDP could be we are still free to start one. Starting it now with only a few people supporting it might not be very productive in terms of ever getting by a 2/3rd majority and hence consensus policy. Best, tom > -----Urspr�ngliche Nachricht----- > Von: owner-council(a)gnso.icann.org > [mailto:owner-council@gnso.icann.org] Im Auftrag von Tim Ruiz > Gesendet: Freitag, 11. April 2008 13:09 > An: 'Council GNSO' > Betreff: RE: [council] Fast Flux Hosting > > > Mike, > > The requirement to vote within 15 days can be dealt with by > adding something like *whereas based on the Staff's > recommendation the GNSO Council has chosen not to initiate a > PDP at this time* or something like that. > > To initiate a PDP would be ignoring the Staff's > recommendations that we specifically asked for. The motion said: > > *ICANN Staff shall prepare an Issues Report with respect to > 'fast flux' > DNS changes, for > deliberation by the GNSO Council. Specifically the Staff > shall consider the SAC Advisory [SAC 025], and shall outline > potential next steps for GNSO policy development designed to > mitigate the current ability for criminals to exploit the DNS > via 'fast flux' IP or nameserver changes.* > > In the report, over and over again, the Staff recommends > further study. > And the GC specifically states that *the overall question of > how to mitigate the use of fast flux hosting for cybercrime > is broader than the GNSO policy development process.* So the > very issue the motion requested the report on is not within scope. > > Philip suggests we make the PDP about those *some aspects > relating to the subject of fast flux hosting* that are within > scope. What are they? > The report does not make it clear what they are. The furter > research and study that the report recommends is what is > needed in order to identify them. > > When we initiate a PDP we start a clock ticking. If we > initiate a PDP on yet unknown *aspects* with the idea that > identifying them is the first step, we are guaranteeing that > we won't stay within the PDP timeline. I don't see the point in that. > > > Tim > > > -------- Original Message -------- > Subject: RE: [council] Fast Flux Hosting > From: "Mike Rodenbaugh" <mxrodenbaugh(a)yahoo.com> > Date: Thu, April 10, 2008 7:24 pm > To: "'Council GNSO'" <council(a)gnso.icann.org> > > > Tim, > > I noted the Staff's recommendation and included it in a 'whereas' > clause. > Yet there appears no reason to delay a PDP for factfinding, > since a PDP can begin with that work. Of course, this is a > very time-sensitive issue as hundreds of phish attacks are > launched every week, increasingly many of them using fast > flux techniques. > > I also noted the comments apparently from ICANN Counsel with > respect to scope. It seems that after this next step, Counsel > may wish to give an opinion as to the outcome up to that > date, so that GNSO Council does not waste time deliberating > potential recommendations that are out of its scope. > However, I believe my motion does not raise issues outside > the scope of the GNSO. > > The bylaws require us to vote whether to initiate a PDP, > within 15 days of the Issues Report. Only 1/3 of present > Councilors needs to vote in favor of initiating a PDP after > an Issues Report. > > I am curious to hear others' thoughts on my motion, these > issues, and any reasoning as to why we should delay or forego > initiation of a PDP, before deciding whether to accept your > friendly amendment. > > Thanks, > Mike > > -----Original Message----- > From: owner-council(a)gnso.icann.org > [mailto:owner-council@gnso.icann.org] > On > Behalf Of Tim Ruiz > Sent: Thursday, April 10, 2008 11:42 AM > To: 'Council GNSO' > Subject: RE: [council] Fast Flux Hosting > > > Mike, > > Why does a PDP need to be initiated to gather the information > you suggest? In fact, the Staff report specifically > recommends *that the GNSO sponsor further fact-finding and > research* before considering whether or not to initiate a formal PDP. > > Also, the GC opinion on whether or not this is in scope says > that while *some aspects* are within scope, *the overall > question of how to mitigate the use of fast flux hosting for > cybercrime is broader than the GNSO policy development process.* > > Would you be agreeable to an intended friendly amendment to > change the opening sentenc after RESOLVES to: > > *To initiate a Working Group of interested stakeholders and > Constituency > representatives...* > > Failing that amendment, I believe we would then need a > Supermajority in favor of the motion to initiate a PDP. > > > Tim > > > -------- Original Message -------- > Subject: [council] Fast Flux Hosting > From: "Mike Rodenbaugh" <mxrodenbaugh(a)yahoo.com> > Date: Thu, April 10, 2008 12:42 pm > To: "'Council GNSO'" <council(a)gnso.icann.org> > > > Hello, > > I propose the following motion for Council consideration in > our next meeting on April 17th, may I please have a 'second'? > > Thanks, > Mike Rodenbaugh > > > 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-rep > ort-fast-flux- > 25mar08.pdf, 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 in accord with the > ICANN Bylaws, by forming a Task Force of interested > stakeholders and Constituency representatives, to collaborate > broadly with knowledgeable individuals and organizations, in > order to develop potential policy options to curtail the > criminal use of fast flux hosting. > > The Task Force initially shall 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? > ..How are registry operators involved in fast flux hosting activities? > ..How are registrars involved in fast flux hosting activities? > ..How are registrants affected by fast flux hosting? > ..How are Internet users affected by fast flux hosting? > ..What 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? > > The Task Force shall report back to Council within 90 days, > with a report discussing these questions and the range of > possible answers developed by the Task Force members. The > Task Force report also shall outline potential next steps for > Council deliberation. > > > > > > > > > > > >

1 0

RE: [council] Fast Flux Hosting
by Tim Ruiz April 11, 2008

April 11, 2008

Set aside I suppose, but safely? Is it safe, or wise, to ignore the repeated advice we have gotten, prior to the request for the issues report and now in the issues report itself, that further study and research is needed? Tim -------- Original Message -------- Subject: [council] Fast Flux Hosting From: "Philip Sheppard" <philip.sheppard(a)aim.be> Date: Fri, April 11, 2008 6:34 am To: "'Council GNSO'" <council(a)gnso.icann.org> Tim Ruiz wrote: "we are guaranteeing that we won't stay within the PDP timeline" The Board governance committee wrote: "Review of PDPs that have been undertaken suggests that it is not practical to complete policy work in the timeframes contained in the PDP" The LSE wrote: "it is desirable for more realistic timings for PDP phases to be formulated". Tim your concerns are well known and can be safely set aside. Philip

1 0