Re: Retiring dhclient

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

First, I know the general problem is hard, and if the aim is to
specify how it should be solved, in general, then that's a very
difficult task.  Further, providing that solution is (aside from
nothing) the only thing that the IETF can really do, so the task
there truly is difficult.

My point is that in NetBSD we don't have to solve that problem
in general.   We need (well, it would be nice if we could)
provide a solution that works for most people who use NetBSD,
most of the time, and which can be configured (manually, if we
can't come up with a better way for now) to handle the other cases.

It isn't that a NetBSD device "will never be connected this way",
but that most are not, and in most cases where they are (this year
anyway) the user probably knows enough to configure the problem away.

I assume that you have your iphone working in its hotel/3g environment,
and if not, I'd guess it is because the iphone doesn't provide enough
config options, not because you are unable to work out what you want it
to do ...

For us, right now, that's enough - the number of NetBSD users who need
to manually config is going to be so small, that any who aren't able
to work it out themselves, can just ask, and someone who does understand
(whatever mechanism we create) will be able to assist.

If that ever gets to be a burden (too many users asking) we can figure
out what the common element is, as in practice (if not in theory) there
will always be one - the providers just aren't that imaginative, they
all copy from each other - and provide a canned config (or even automate if
it is reasonable) to solve that particular problem.

If the IETF ever produces a general solution, then we can implement it.
In the meantime, the experience gained by projects like NetBSD (and all
the others of course) might just be useful in providing some guidance as
to what works, what doesn't, and what missing info should be provided to
ease the task.

Now you can consider this "being a cowboy" if you like - I don't, I think
it's just a prudent and sane use of resources - we (NetBSD) don't need to
solve the general problem right now, so there's no need to attempt to do
that.  But that doesn't mean do nothing just because there isn't yet
a general solution available.   Nor do we need to limit ourselves to
"good networks" whatever they are - just to be able to work in the common
evvironments that our users (the project's users) actually find themselves
in most frequently, today (or next year) - what is needed after that, and
what is needed in less common cases, can be handled later.

kre