Re: Retiring dhclient

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 16 Nov 2011 10:21:54 +0800
    From:        Ted Lemon <mellon%fugue.com@localhost>
    Message-ID:  <844EEC57-686D-4B04-8162-27B0C678B504%fugue.com@localhost>

  | This is impossible to resolve if we treat configuration information
  | as per-host.

No, it isn't - it's impossible to resolve if the aim is to specify
a method by which it must, or should, be done (which is all the IETF
can do, which is why anything dealing with this, or related, issues
is such a quagmire there), but it's actually reasonably easy when you
get to ignore the network and just consider one host, in one evnironment,
and how that host should configure its multiple interfaces and network
stacks (depending upon which are working at the time).

That's the situation here, and NetBSD could easily (well relatively)
specify, and implement, policies that can be configured by the users
to handle all the weird cases, and yet which default to a rational enough
model that most users never need to go near the config to have everything
work well enough (perhaps not optimally in some sense, but well enough
that things at least all work).

It's only when you try and handle the hard cases (like a host multi-homed
to two different providers) and expect to have the network instruct it
somehow how it should configure itself that things get truly hard to
manage.   If the host gets to choose for itself, it can cope.

kre