[council] Fast Flux Hosting - re stated motions

[Avri Doria]

Hi,

Thanks for your note.  and please ignore the note I sent that crossed  
this one.

As it has been a council practice of late to delay a vote by a meeting  
if there was at least one constituency requesting more time for  
consultations, your proposal makes sense.  I will replace the motion  
with the new motions, but mark them for discussion and not vote.

In terms of what happens if the PDP succeeds, but the Task force  
doesn't,  the by-laws dictate that we then go into deliberation in the  
council. In the past, the assumption has been that we then create a  
Drafting Team that either drafts a charter for an open working group  
or drafts a motion that for council considerations.  As we saw in the  
domain tasting case, the motion then, most probably should then go out  
for a round of constituency consideration and public comment.  The by- 
laws do not require this, and the council could just vote, but given  
the trend toward building more consensus as opposed to voting before  
having spent time finding consensus, this does not seem advisable at  
this point.


a.

On 16 Apr 2008, at 12:57, Mike Rodenbaugh wrote:
>
> Philip and Avri, I understand the process question and proposed  
> remedy you
> suggest.  I support Philip's restated motions, with some edits  
> incorporated
> below.  I consider all these changes as friendly amendments to my  
> motion
> made last week, with text of restated motions below.
>
> It is not clear what would happen if we voted to initiate a PDP by  
> 1/3 vote,
> but failed to get 1/2 vote to launch a Task Force.  Also I have  
> heard from a
> couple Councilors that they would like more time to discuss this  
> motion with
> their Constituencies.  And NCUC has not offered reasoning as to why  
> they
> opposed the motion for an issues report or whether they oppose this  
> motion.
> While this process should move forward quickly, it would be best to  
> have as
> much consensus as possible at the outset.  Since we have a full agenda
> tomorrow, perhaps we should just have a further discussion on these  
> points
> (without reiterating positions stated on the list) and hold a vote  
> til our
> next meeting.  Curious to hear others' thoughts on any of this.
>
> Thanks,
> Mike
>
>
> 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.;
>
> The GNSO Council RESOLVES:
>
> To initiate a Policy Development Process to consider whether and how  
> ICANN
> 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.
>
> (This will require a 33% vote)
>
>
> MOTION 2
> Whereas Council has decided to launch a PDP to consider potential  
> policy
> development to address 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)
>
>
>
>
>