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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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

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?

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.

					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.

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