Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-11.txt

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 6 Mar 2006 12:02:18 -0500

I too have never liked the 1/3 of the lease time. But I think it is a
good recommendation for most clients as the addresses are likely to be
"static" over long periods and thus it works well as a default.
Environments where this is not the case will need to use the
configuration knobs in servers to limit the TTLs.

Yet, there's another issue that I think we might want to give a few
moments thought to (though perhaps it is a mistake for me to raise it).
For draft-ietf-dhc-dhcpv6-fqdn-04.txt (which was text moved from
draft-ietf-dhc-ddns-resolution-10.txt):

   We suggest these basic guidelines for implementers.  In general, the
   TTLs for RRs added as a result of DHCP IP address assignment activity
   SHOULD be less than the initial lifetime.  The RR TTL on a DNS record
   added SHOULD NOT exceed 1/3 of the lifetime, and SHOULD be at least
   10 minutes.  We recognize that individual administrators will have
   varying requirements: DHCP servers and clients SHOULD allow
   administrators to configure TTLs and upper and lower bounds on the
   TTL values, either as an absolute time interval or as a percentage of
   the lease lifetime.

I just wrote "lifetime". But is this the preferred or valid lifetime? I
would suggest that we request an RFC-Editor change to change "lifetime"
to "valid lifetime" in the above text.

- Bernie 

> -----Original Message-----
> From: David W. Hankins [mailto:[email-masked]] 
> Sent: Friday, March 03, 2006 10:41 PM
> To: Ted Lemon
> Cc: [email-masked]
> Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-11.txt
> 
> On Fri, Mar 03, 2006 at 05:26:13PM -0700, Ted Lemon wrote:
> > On Friday 03 March 2006 16:52, David W. Hankins wrote:
> > > 'actual lease time' or 'desired lease time'? ??Remember, failover
> > > modifies the lease time to not exceed max(TSFP,cur_time)+MCLT
> > > optimal.
> > >
> > > The obvious answer to me is 'desired lease time', that 
> the document
> > > should be read from a pre-failover mindset, and this 
> issue should be
> > > broached elsewhere (the 7,450 lines of failover draft?) if at all.
> > 
> > Failover doesn't change the meaning of "lease time".  I 
> think it would 
> > actually be a mistake to use the desired lease time - what 
> if the client 
> > doesn't renew?
> 
> To be clear, I wasn't advocating that, rather that's the way 
> I interpret
> the current wording of the document.
> 
> That is: we assume a pre-failover interpretation, and use a comparable
> value in the post-failover implementation.  I think that would be the
> 'desired lease time' then.
> 
> I tend to agree that isn't the best approach (which is why 
> I'm pointing
> it out).
> 
> > Generally speaking, it's better to err on the side of 
> shorter when it comes to 
> > TTLs for DHCP clients, not on the side of longer.   
> Otherwise you wind up 
> > with very, very stale data in peoples' caches.
> 
> So, to be clear, are you suggesting using a shorter TTL and 
> then advancing
> to a longer TTL upon renewal after binding updates, or are 
> you advocating
> using a TTL based strictly upon MCLT rather than lease time?  
> Or random
> (whatever happens to be min("TSFP+MCLT optimal",desired-lease-time))
> depending upon the time the client asked?
> 
> I think there are a lot of potential bad ideas in here.
> 
> > In practice a DHCP client isn't going to get looked up 
> except by a few 
> > interested parties, so there's not a lot of bang for the 
> buck to be had in 
> > trying to extend cache times.   My personal feeling is that 
> ten minutes is 
> > actually too _long_ for a DHCP client TTL; I agreed to that 
> number only 
> > because there seemed to be no consensus for making it shorter.
> 
> I think it's pretty reasonable to have high defaults encoded in the
> RFCs and count on operators to find lower numbers that work better for
> them.
> 
> But I'd agree that lease-time/3 is probably a little high.  I'd prefer
> something more like /10 I think in my own network.
> 
> Then again, that's precisely the draft's guidance: not to exceed l/3,
> minimum 10 minutes, unless configured by administrator.
> 
> I think that's wisdom, nothing to tune here.
> 
> -- 
> David W. Hankins		"If you don't do it right the 
> first time,
> Software Engineer			you'll just have to do 
> it again."
> Internet Systems Consortium, Inc.		-- Jack T. Hankins
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Mar 2006 10:18:35 -0700

> to "valid lifetime" in the above text.

Yup, that makes sense.