On Thu, Dec 01, 2005 at 03:00:49PM +0200, Pekka Savola wrote: > On Wed, 30 Nov 2005, David W. Hankins wrote: > >Now, perhaps RFCs shouldn't read like "Choose your own Adventure" > >novels. > > My problem is that the spec leaves the algorithm completely open. > There is at least one simple algorithm (just blindly update if there's > no DHCID) has severe problems in certain kinds of zones. This doc > should discourage or disallow that algorithm by default. As for the > rest, I don't really care (though as a user, it would likely have been > nice if the behaviour between different vendors would have been > consistent, but we aren't going to get that it seems..). I think we should take this one back to the WG. Find out how many algorithms there are which people actually want to use, within each how many "administrative policies" there are (and name them all), and who is interested in each one (more importantly, which One Bernie still has the strength to document, if any). Split up and go our separate ways, make new documents for the additional algorithms (or don't if the interested parties don't feel a need to). > > That's correct, this is the operator's decision, which may be made > > for them by software of specific manufacture (or defaults of same). > > This is exactly the problem: the software choosing what's best for the > user. Welcome to DHCP? I'm sorry, that wasn't fair. When, for example, at an IETF, where the systems operators are engineers of similar character and capability as the clients (IETF attendees), this solution can mix like water and oil. Especially if any of the involved individuals have opinions on "how things should work", and choose to share them, which is about like applying a match to the solution. An IETF Molotov cocktail, if you will. But, on a campus of some 100,000 Windows boxes, for example, where the system operator has very limited experience with networks much less DHCP much less DNS (because this is a job they give 'the new guy'), and a drinking problem to boot, and the users surprise us daily by their ability to mimic human speech, even forming rudimentary sentences such as "I want net!" or "Fix magic electric box now!", this is ultimately the only sane approach. Obviously, between those two there are a variety of equally painful scenarios, and we hope a bell curve where reasonably skilled operators are asked to preside over reasonably computer literate client users. Only some skeptics say the bell is upside-down. Software will exist that is tailored to at least those two extremes, if not more. I suspect most software (or most widely used software) will need to be readily adaptable to either. So the draft really needs to document both ends of the spectrum. > > [looks like I oversnipped bits about A/AAAA genocide] > > That would be unfortunate. Wouldn't it be sufficient that the server > removes the DNS records after the lease expires? Then if the user > doesn't reconnect anywhere else prior to lease expiry, all is cool. That is one approach, but it is the road generally not taken. Lease times in campuses are often 24 hours, or more (I've seen 3-month lease times, although they are rare...1 week is fairly common. Also let us not forget that RFC2131 explicitly has a special-case value (all-ones) for the lease-time that is defined to mean "infinite"...there are some actual field cases where this is used (I get patches from these people). Is it wise to leave forward records up indefinitely? One operational impact of lease time is frequency of interruption for the client. Some clients either return to INIT state immediately should the renewal time out (so brief interruptions in the DHCP service are painful for some sysops), and some are known to 'hang' the IP layer while the renewal is underway (painful for the user, more painful when the systems administrator gets phonecalls asking why). And in my own experimentation, I was able to consistently crash an array of Windows 95, 98, and 2000 boxes simply by using a 30 second lease time. Wether these behaviours are in the spirit of the RFCs or not is immaterial to an operator. Add to this that larger times result in lower rate of activity on a DHCP server (or cluster of same) in the center of a large campus. So, larger lease times are preferred by admins. Generally the question is "how much advance notice are you required to give for network downtime?" Often 24, or 48 hours. Letting these large times expire isn't tractable if the client has a need to be reached by its name (which would be the whole point of DDNS via DHCP - not mere vanity we would hope). -- 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
Attachment:
pgpiIfCqYsN9Y.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf