ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9

  • To: gaaron@xxxxxxxxxxxx
  • Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
  • From: "James M. Bladel" <jbladel@xxxxxxxxxxx>
  • Date: Tue, 02 Jun 2009 11:00:13 -0700

Greg / Mike:

This is a good topic, but I'm struggling to come up with some common
language that reconciles both positions.

Greg:  Do some registries / registry sponsors require advanced
permission before accepting volatile networks into the DNS?  If so, how
did they come by this authority?  Was it part of an RSEP request?

If so, then this might be a good example of a registry best
practice.....

Just brainstorming here, so apologies if this takes us off track.

J.


   -------- Original Message --------
 Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
 From: "Greg Aaron" <gaaron@xxxxxxxxxxxx>
 Date: Tue, June 02, 2009 12:56 pm
 To: <icann@xxxxxxxxxxxxxx>, "'Fast Flux Workgroup'"
 <gnso-ff-pdp-May08@xxxxxxxxx>
 
 
 Dear Mike:
 
 So you are suggesting that any Internet user in the world who wanted to
use
 a TTL below a certain threshold would need to go to some authority to
get
 permission?
 
 All best,
 --Greg
 
 
 
 
 -----Original Message-----
 From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx] 
 Sent: Tuesday, June 02, 2009 1:10 PM
 To: 'Fast Flux Workgroup'
 Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
 
 
 Again I disagree, as existing legitimate uses could be whitelisted,
with no
 impediment whatsoever to their existing deployment.
 
 -Mike 
 
 -----Original Message-----
 From: Greg Aaron [mailto:gaaron@xxxxxxxxxxxx] 
 Sent: Tuesday, June 02, 2009 9:46 AM
 To: icann@xxxxxxxxxxxxxx; 'Diaz, Paul'; 'Fast Flux Workgroup'
 Cc: 'Marika Konings'
 Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
 
 I suggest the statement read:
 
 "Besides their technical or practical limitations, such limitations,
 guidelines, or restrictions would impede current legitimate "volatile
 networks" that use short TTLs and frequent DNS record updates to
deliver
 their beneficial products and services."
 
 I have removed "likely" because limiting TTLs would definitely impede
 currently deployed legitimate services. 
 
 All best,
 --Greg
 
 
 
 
 -----Original Message-----
 From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx]
 Sent: Tuesday, June 02, 2009 10:00 AM
 To: 'Diaz, Paul'; 'Fast Flux Workgroup'
 Cc: 'Marika Konings'
 Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
 
 
 Hi,
 
 I disagree that limits on TTL would impede innovation of volatile
networks.
 We have no indication of that from any source, as far as I recall. I
think
 it is better to leave the first sentence, and expand upon it, rather
than
 introduce a red herring argument. 
 
 I suggest we delete that last sentence, and instead add a clause up
front:
 "As explained in section 5.8, none of the possible options..."
 
 Thanks,
 Mike
 
 Mike Rodenbaugh
 Rodenbaugh Law
 548 Market Street
 San Francisco, CA 94104
 +1.415.738.8087
 www.rodenbaugh.com
 
 
 
 -----Original Message-----
 From: owner-gnso-ff-pdp-may08@xxxxxxxxx
 [mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Diaz, Paul
 Sent: Friday, May 29, 2009 11:07 AM
 To: Fast Flux Workgroup
 Cc: Marika Konings
 Subject: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
 
 
 Here is proposed text for Section 5.9 (which also would appear in the
 Executive Summary re: Charter Question #9. Please share edits/comments
to
 the list for further discussion/approval at the next FF WG call on June
3.
 
 
 Issue
 What would be the impact of these limitations, guidelines, or
restrictions
 to product and service innovation?
 
 
 Response
 None of the possible options noted above were deemed appropriate or
 viable. Besides their technical or practical limitations, such
 limitations, guidelines or restrictions likely would impede the
 innovation of legitimate "volatile networks" that use short TTLs and
 frequent DNS record updates to deliver their beneficial products and
 services.





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

Privacy Policy | Terms of Service | Cookies Policy