Re: [gnso-ff-pdp-may08] Saturday Harms

["Mike O'Connor" <mike@xxxxxxxxxx>]

At the risk of driving some of you crazy, I'm going to relaunch this 
thread.  I'm in "re-read email and extract" mode today.
My first comment is that my replies to the thread completely missed 
Eric's point.  Sorry about that.
I want to pose a question or two, based on our discussion around the 
definition of fastflux (using Randy's terminology).
- What "harms" would be eradicated by the elimination of volatile 
compromised host service networks?
- For those that wouldn't be completely eradicated, for which harms 
would "eliminating volatile compromised host service networks" be 
your first choice among all mitigation options?
For inspiration, I give you the first four photographs in Marcie's 
latest farm-blog journal entry -- Mike causing mayhem with the chain saw.
http://aprairiehaven.com/modules/AMS/article.php?storyid=616


At 10:53 AM 7/19/2008, Eric Brunner-Williams wrote:
> All,
>
> Dave's note "Jump start on answering GNSO questions regarding fast 
> flux" of July 1st restated the "benefits/harms from/by fast flux" 
> question as "benefits from short TTLs" and "harmed by fast flux", 
> which kicked off our still-incomplete attempt to correct the 
> language of our point of departure.
>
> In the list of "harmed by", Dave listed several cases. I commented 
> on several, in particular these two:
> 1. Individuals whose computers are infected ...
>
> 2. Businesses and organizations whose computers are infected ...
>
> In a nutshell, Dave pointed out that the consequences for 
> individuals, business and organizations who's computers are infected 
> and subsequently used by (and I'll leave this as "fast flux" even 
> though we've no consensus on terminology) "fast flux" are 
> non-trivial. Denial of service by their local access ISP. Far too 
> much service by their local law enforcement.
> In a nutshell, my comment was that the consequences are immanent* 
> when these computers are infected, and the infected computers are a 
> commodity, and used until "busy, hung or dead" by the author(s) of 
> the infection(s). They don't get particularly more "busy, hung or 
> dead" if used for "fast flux".
> A few days ago** I wrote that Registrants (capitalized, because I'm 
> addressing a specific, contract-created role in a set of 
> contract-defined relationships between gTLD parties, bounded above 
> by 100 million) are not harmed by "fast flux". I looked at the 
> probability of harm, and found that it is, as we say in Maine, "wicked small".
> I should have also pointed out then that while it is true that 
> Registrants are harmed by the taking of domains by non-Registrants 
> (or Other Registrants), but they are no more harmed by "fast flux" 
> than by any other non-Registrant taking that is not permitted by 
> ICANN Consensus Policies. Like repurposed (infected and exploited) 
> PCs, domains don't get particularly more "busy, hung or dead" if 
> used for "fast flux".
> Today, while Mike is out killing living things with a mower and a 
> chain saw, I'm going to offer the following:
> A. Registrants are not harmed by "fast flux". Hijacking and so forth 
> do harm Registrants, but very little is known to Registrars (and no 
> other party within ICANN is in a position to have better information 
> than Registrars) that is specific to "fast flux", so "fast flux" 
> adds no known additional harm to Registrants beyond the set of harms 
> we already know about, and have previously developed PDPs to address 
> (or are still dickering over).
> B. Registrars are not harmed by "fast flux". Credit card fraud is a 
> given, its why we have the Add Grace Period, and take-down requests 
> from a variety of sources are a given, and dispute claims and their 
> resolution processes are a given, as well as system loading for 
> dynamic update are given, so "fast flux" adds no known additional 
> harm to Registrars beyond the set of harms we already know about, 
> and have previously developed PDPs to address (or are still dickering over).
> C. Registries are not harmed by "fast flux". Transfer interventions, 
> Registrar support costs, and system loading for dynamic update are 
> all givens, so "fast flux" adds no known additional harm to 
> Registries beyond the set of harms we already know about, and have 
> previously developed PDPs to address (or are still dickering over).
> While its been most of a decade since I last operated an access ISP 
> (a dialup operation serving Maine), and its been about that long 
> since I've seen any interest in ICANN by the operational side of 
> transit or access network providers, I'm going to offer my 
> experience for that Constituency (left somewhere behind), that --
> D. ISPs are not harmed by "fast flux". A whole bunch of bad things 
> are givens for ISPs, so "fast flux" adds no known additional harm to 
> ISPs beyond the set of harms they already know about. A 
> counter-proof would be something of the form "X lost block Y because 
> Y[i,j,k] were used in a FF".
> I don't play a lawyer on the net or on TV, let alone an IP 
> practitioner, but given A, above --
> E. Intellectual Property holders are not harmed by "fast flux". A 
> counter-proof would be something of the form "X lost mark M in 
> jurisdiction Y(s) because M was used in a FF conducted or prosecuted 
> in jurisdiction Z(s)".
> Because the BC brought this (I'm sure Mike R. will correct me even 
> if I'm right), I'm assuming that some businesses are harmed by "fast 
> flux", and their harm is distinct from the harms they experience 
> from other causes.
> I'm not "At Large" either , but my guess is that --
>
> F. ALC interests are not harmed by "fast flux". A whole bunch of bad 
> things are givens for the interests represented by the ALC, and 
> "fast flux" adds no known additional harm to those interests beyond 
> the set of harms they already know about and have previously 
> developed PDPs to address (or are still dickering over).
> My goal is to try and get a better understanding, even if just for 
> my self, of what the harms are, and what they are not. I'm not 
> trying to change anyone's mind that has already come to some other 
> conclusions I haven't learned to share.
> I don't know what harm to the environment Mike will wreak tomorrow, 
> but I'll try "benefits" on Sunday.
> Eric
> ---------
> * In popular Indian culture we say "Coyote waits" (or Raven or 
> Racoon or ...), meaning that a trick, or adverse outcome, is waiting 
> for those without foresight or common sense. It is latent malice.
> ** message id: 
> <mailto:487F214F.5030402@xxxxxxxxxxxxxxxxxxxx><487F214F.5030402@xxxxxxxxxxxxxxxxxxxx>