Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)

[Stig Venaas <[e-mail]>]

On Tue, Aug 24, 2004 at 09:12:01PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Mon, 23 Aug 2004 10:28:12 -0400, 
> >>>>> Ted Lemon <[e-mail]> said:
> 
> >> - even if the clients cannot get a response by the expiration, it
> >> should continue sending Information-requests.  However, it can also
> >> invalidate the expired information in some way, e.g., by preferring
> >> a "last resort" default or by using other means of configuration.
> 
> > Can you think of a real-world scenario where this would be the right 
> > thing to do?   I can't come up with one.
> 
> The scenario I thought of is that if the "lifetime" of a DNS
> (recursive) server expires with no update I'd stop using the server
> and start a local recursive server daemon (e.g., run BIND named on my
> laptop and specify ::1 in /etc/resolv.conf) as a last resort.  I'm
> quite sure that this is a "real world" scenario because I, for one,
> would like to have this feature and I'm living in the real world of
> the Internet.  I admit this might be a niche demand though.
> 
> I can also think of a scenario where I'll then prefer information
> from DHCPv4 (over the expired information from DHCPv6).  But I don't
> know this makes sense in the real world.

OK, I can see that. How about adding this:

The expiry of the lifetime in itself does not in anyway mean that the
client should remove the data. The client should keep it's current data
while attempting to refresh it. The client is however free to fall back
to other mechanisms if it cannot refresh the data within a reasonable
amount of time.

It's a bit vague, but I don't think we should standardize every detail.

> Aside from the scenarios, I'm also concerned about a (possible)
> pitfall with the "update timer" semantics.
> 
> Assume that we have a reply to Information-request containing a DNS
> server address X with update timer (or lifetime) T.  T seconds later,
> the client will restart Information-request/reply exchanges.  If we
> then get a different DNS server address Y, we'll stop using the old
> address X and switch to Y.  This should exactly be the "renumbering
> scenario", and the behavior looks reasonable.  But what if the reply
> does not contain any new DNS server address?  Can we still continue to
> use address X, or will we then lose any usable DNS server address?

It is reasonable to remove it in my opinion. However if the client
has no fallback mechanism to obtain a new resolver address, I guess it
could decide to keep using it.

If however say NTP server address is removed, and the client has no
fallback, I would say disable NTP.

Try to think what you would do without this option. Your client would
try to refresh the info at some point wouldn't it? If you move to new
link, if user requests it etc. What do you do if no server is specified
in the reply? If the DNS server address is not in the new reply, the
administrator has removed it from the DHCP server config, and is
expecting clients to obtain DNS server address in some other way, or?
It's just another hint for when to update the info.

Also, if you stop offering some service, or by accident include
something. There should be a way to remove it.

> If the former is the intent, it seems a bit odd to me that the
> behavior is different based on whether the replied set is empty or not
> (at least the specification is not very clear on this).  If the latter
> is the intent, doesn't it almost mean we invalidate the expired
> information X?
> 
> Anyway...so far, others do not seem to be very happy with the idea of
> invalidating expired information.  If the above explanation is still
> not so convincing, I won't stick to the idea.  I can live with the
> "update timer" semantics as long as the specification is clear enough
> to implement.

Well, I'm interested in hearing what you think is reasonable, and what
you would implement in your client if you don't have this options, but
renew the data for other reasons.

> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					[e-mail]
> 
> p.s. I'm afraid I won't be able to be very active on the list this
> week.  I'd apologize in advance for future delay of my responses.

NP. I hope to post my suggestions for next revision later this week.
I'll then wait several days to see if people are satisfied, in which
case I'll make it the official "02" version.

Stig

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