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

From: "David W. Hankins" <[email-masked]>
Date: Fri, 3 Mar 2006 15:52:08 -0800

On Fri, Feb 24, 2006 at 06:50:01PM -0500, [email-masked] wrote:
> 	Title		: Resolution of FQDN Conflicts among DHCP Clients
> 	Author(s)	: M. Stapp, B. Volz
> 	Filename	: draft-ietf-dhc-ddns-resolution-11.txt
> 	Pages		: 14
> 	Date		: 2006-2-24

I basically have no comments on this draft (or the other two).  But I
like hearing myself talk, and I think the dhcwg mailing list is too quiet
anyway, so I'm going to talk about failover instead, which I thought of
after reading this:

	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 lease time. The RR TTL on a DNS	
	record added SHOULD NOT exceed 1/3 of the lease time, 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 time.	

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

Just thinking out loud.

And maybe the activity will poke some folks to remind them to read if
they haven't.

Anyway, like I said, I've been through all three drafts and I have no
comments.  It looks right to me.

What's the next step?  Another last call before IESG re-review?

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Mar 2006 17:26:13 -0700

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

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.

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.

---

From: "David W. Hankins" <[email-masked]>
Date: Sat, 4 Mar 2006 03:40:49 +0000

On Fri, Mar 03, 2006 at 05:26:13PM -0700, Ted Lemon wrote:
> > 'actual lease time' or 'desired lease time'? ??Remember, failover

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

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

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