RE: [gnso-ff-pdp-may08] Reminder -- today is the deadline for "replacement text" suggestions

["Greg Aaron" <gaaron@xxxxxxxxxxxx>]

Dear Mike:

Here is my list for consideration.

Line numbers below are from the "Fast Flux Initial Rep#ECE80.pdf" doc that
Glen circulated on September 2.


A.
191-194: Edit to read: "The working group conducted research which developed
evidence that legitimate high-capacity load-balancing systems, and
legitimate "volatile" or rapid-update-dependent services, rely on short
time-to-live values in the DNS records that resolve their principal domain
names (e.g., www.google.com) to IP addresses in order to propagate changes
quickly."
The evidence that various legit systems rely on short TTLs was documented in
the threads, and is not "anecdotal".

B.
199-200: Currently doc says that "More research is needed to better
understand legitimate uses [of short TTLs] and their prevalence, once a more
robust definition of "fast flux" has been developed."
That statement should be cut -- I think there was well-supported info about
the legit uses of short TTLs, and consensus that limiting TTL lengths is not
a viable solution to fast-flux.  The DNS RFCs themselves allow short TTLs
and describe such uses.  See also lines 1213-1228 for background and
references.

C.
206: please delete "anecdotally."  It was discussed as a possible legitimate
use.

D.
329: "not sure what "not fast flux" means or refers to; might need some
grammatical editing?

E.
323 ff: I suggest an addition and edit so as to read:
"Organizations that provide channels for free speech, minority advocates,
and so on may use short TTLs and operate fast-flux networks.  The group was
presented with a case study of a service that uses fast-flux methods to
purportedly allow Web users to circumvent Internet content censorship
(http://forum.icann.org/lists/gnso-ff-pdp-may08/msg00371.html)."

F.
367-368:  Rather than leaving question 5.3 blank, I suggest the following
note, which points to some useful (and factual) technical info:
"In its Constituency Input Statement (attached to this report as a annex),
the RyC provided detailed notes regarding the technical and policy options
available to registry operators regarding fast-flux hosting.  The RyC
statement includes technical notes about how the DNS functions, the data
available to registry operators, fast-flux detection methods, uses of short
TTLs, and other pertinent items. The RyC's answers to question 3 at line 936
[THIS REFERENCE WILL HAVE TO BE UPDATED AS THE DOC GETS EDITED] and question
7 from 1008 to 1252 [THIS REFERENCE WILL HAVE TO BE UPDATED AS THE DOC GETS
EDITED] are of interest.

G.
402 and 404: change "affiliated" to "contracted" and "affiliates" to
"contracted parties".  (Reasoning: a number of ccTLDs have MOUs with ICANN,
and most ccTLDs are affiliated with ICANN via their participation in GAC and
ICANN.)

H.
409, footnote 5: WHOIS is not a manual protocol, and was in fact designed
for real-time queries.  Suggest an edit to read: "5 A DNS-based system could
provide similar or additional data than WHOIS systems do, and at rates
higher than many port 43 WHOIS servers currently allow."

I. 
429: Edit to read: "The ideas for active engagement that were discussed by
the WG included the following; the group did not reach consensus on or
endorse any of them:"

J.
446: Add a bullet to the list of ideas, to read: "Allow the Internet
community to mitigate fast-flux hosting in a way similar to how it addresses
spam, phishing, pharming, malware, and other abuses that also take advantage
of the DNS and Internet protocols."

K.
492: Replace: "simply move on to another technique or method to avoid
detection" with "simply move on to another technique or method, or would
change their implementations, to avoid detection or mitigation efforts."

L.
636: I have a question about "develop algorithms."  I question whether ICANN
is the right place to develop such algorithms or specific technical
implementations.  ICANN WGs are not designed to do engineering work, and
ICANN doesn't usually commission or fund such engineering work -- it sets
policy or requirements.  (ICANN has done engineering studies and tests when
it had a direct relation to ICANN's narrow technical mandate -- an example
being the IDN TLDs test-bed.)

M.
665 and 667 (Options S3 and S4): I think these are premature/not relevant to
even list as options at this time, and I suggest deleting them.  Reasoning:
any solutions mandated by ICANN would have to be the product of a future
PDP; and any solutions will not be built, tested, or deployed by ICANN
anyhow -- they'll be done by some party or parties other than ICANN.

N.
936: Please boldface the question.

All best,
--Greg


-----Original Message-----
From: owner-gnso-ff-pdp-may08@xxxxxxxxx
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Mike O'Connor
Sent: Monday, September 08, 2008 8:27 AM
To: Fast Flux Workgroup
Subject: [gnso-ff-pdp-may08] Reminder -- today is the deadline for
"replacement text" suggestions


hi all,

Dave's note reminded me -- if you have alternate texts that you'd 
like to get into Marika's document, today's the last day to submit 
them.  that's the basis of Wednesday's call -- where we'll vote our 
way through the list and nail down what's in the Interim report.

thanks!

m


voice: 651-647-6109
fax: 866-280-2356

web: www.haven2.com