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

["Greg Aaron" <gaaron@xxxxxxxxxxxx>]

Dear Mike:

Please see the two sections about TTLs in the RyC statement, where I
described the salient technical points.  Registries and registrars do not
have any practical control over authoritative TTLs.

You'd have to re-engineer the Internet to change that and implement your
white-list idea.  DNS RFCs 1034 and 1035 are not just any RFCs -- they have
status as Internet Official Protocol Standards.  They describe fundamentals
of how the DNS works, and are designed into systems.  So if you advocate
limits on TTLs, you must also advocate that the IETF alter the DNS RFCs.  

The only exception where a registry or registrar has authoritative impact on
TTLs is where the registrar is also acting as the registrant's hosting
provider.  However, Web hosting services are outside of the scope of GNSO
policy-making.

As a practical matter: I think businesses, governments, and the engineering
community would strongly resist the idea that they would have to obtain
permission from some body in order to set and change TTLs. 

For the above reasons, the FFWG report should not advocate options to limit
TTLs. 

All best,
--Greg



-----Original Message-----
From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx] 
Sent: Tuesday, June 02, 2009 2:05 PM
To: 'Fast Flux Workgroup'
Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9


Greg,

It is a conceivable option.  Domain registrants could be notified of
limitations and opportunity to request permission, by their registrar at
time of registration, and if they violate rules then could suffer domain
suspension until they comply.  

I am only floating this as a potential option, particularly if abuse of fast
flux exploits, and resulting harm, continues to grow unabated.  I simply do
not want our Report to foreclose the possibility, because we have not agreed
as a WG that it should be eliminated.

Thanks,
Mike



-----Original Message-----
From: James M. Bladel [mailto:jbladel@xxxxxxxxxxx] 
Sent: Tuesday, June 02, 2009 2:00 PM
To: gaaron@xxxxxxxxxxxx
Cc: icann@xxxxxxxxxxxxxx; 'fast flux workgroup'
Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9

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-----
From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx] 
Sent: Tuesday, June 02, 2009 1:15 PM
To: 'Fast Flux Workgroup'
Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9


Hi Greg,

This is an option, particularly if fast flux exploits become a much bigger
problem than they are today.  

ICANN could impose such restrictions authoritatively, in the interest of DNS
security and stability.  

RFC's are not authoritative, are often ignored and sometimes meaningless,
and can be revised if circumstances warrant. 

Thanks,
Mike


   -------- 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.