ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Proposed additional text, section 5, answering 5.2-5.7 at 365-379

  • To: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Proposed additional text, section 5, answering 5.2-5.7 at 365-379
  • From: RLVaughn <RL_Vaughn@xxxxxxxxxx>
  • Date: Tue, 02 Sep 2008 17:30:46 -0500

The items listed on lines 304, 310, and 319 appear in the
Dave's "Who benefits from the use of short TTLs?" section
of his 11 July post which Joe referenced earlier.  So, it
seems at least some review consensus was reached in regards
to that post and that not all of Dave's suggestions were
removed from the report.

In his section labeled,
"Who is harmed by fast flux activities?"
items 1 and 2 specifically correlate with the compromised hosts
component of on line 260.  Omitting those two items in the who is
harmed section seems to devalue the statement on 260 and seems to
skew the discussion in the other direction.

Dave's claims in items 5 and 8 seem candidates for verification from the
appropriate constituency groups but fit my conception of the perceivable
harms to registrars and registries.  However, I fail to see how the
majority of registrars or registries are in a position to perceive
dealing with fastflux as any thing other than marginal cost.  Based on
my perceptions of their risk models I fully appreciate their reticence
to assume the full mantle of mitigation.


I was wondering about the spam spin off that Mike mentioned then I
realized Dave's and Joe's messages were posted while I was traveling
so I evidently missed out on that journey down the cul-de-sac.


Mike O'Connor wrote:
> 
> 
> 
> those omissions were on purpose.  we had Dave's text in a previous
> draft, and removed it.  i concluded that we never really reviewed it
> (remember, it was posted very early in the conversation) and decided
> that it would not come very close to reflecting our (later) shared
> understanding.  your text never made it in, because it was quite
> unfocused and generated a wonderful side-trip into a bunch of issues
> around Port 25.  i would propose that we leave both proposed texts out
> of this draft, and let the next group develop more concise versions once
> the basic research has been done to provide the underpinnings.
> 
> 
> 
> At 01:17 PM 9/2/2008, Joe St Sauver wrote:
> 
>> --=======AVGMAIL-48BD85F50000=======
>> Content-Type: text/plain; charset=us-ascii
>>
>>
>> Lines 365-379 list six of the questions that the working group
>> was charged with addressing, including 5.2:
>>
>>    "Who would benefit from cessation of the practice and who would be
>> harmed?"
>>
>> Dave Piscitello's provided a fine answer to that question at
>> http://forum.icann.org/lists/gnso-ff-pdp-may08/msg00048.html , one
>> which I
>> commented on at
>> http://forum.icann.org/lists/gnso-ff-pdp-may08/msg00055.html
>>
>> I propose that that text be included as a response to 5.2
>>
>> When it comes to question 5.6, "How are Internet users affected by fast
>> flux hosting?" I addressed the question 5.6 in my note at
>> http://forum.icann.org/lists/gnso-ff-pdp-may08/msg00061.html
>>
>> Again, I would propose that that text be included as a draft response to
>> 5.6
>>
>> Regards,
>>
>> Joe
>>
>> Disclaimer: all opinions strictly my own
>> --=======AVGMAIL-48BD85F50000=======
>> Content-Type: multipart/alternative;
>>         boundary="=======AVGMAIL-48BD85F50000======="
>>
>> --=======AVGMAIL-48BD85F50000=======
>> Content-Type: text/plain; x-avg=cert; charset=us-ascii
>> Content-Transfer-Encoding: quoted-printable
>> Content-Disposition: inline
>> Content-Description: "AVG certification"
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.169 / Virus Database: 270.6.14/1647 - Release Date:
>> 9/2/2008 6:=
>> 02 AM
>>
>> --=======AVGMAIL-48BD85F50000=======--
>>
>> --=======AVGMAIL-48BD85F50000=======--
> 




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy