Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP

    Date:        Tue, 30 Sep 2003 21:44:29 +0300
    From:        Mika Liljeberg <[email protected]>
    Message-ID:  <1064947469.4768.13.camel@hades>

  | That's not exactly independent.

It is independent state machines - they are just dependencies
on when they're used.

  | In any case, in an ad-hoc scenario I need a working address within
  | approx. 10 seconds after the user activates an application and the RF is
  | powered up.

10 secs should be plenty - it only takes a couple of seconds after the
link is stable to get a DHCP assigned address, if you're going to get one,
in the vast majority of cases (and perhaps an extra second or two for
one more retry).   LL is supposed to take about 3 seconds in the current
version isn't it (I forget just what we eventually decided on the LL
timers).   That's 5-8 if run serially (assuming that you start LL
acquisition if DHCP doesn't quickly get an address, which is what I
suggest - not wait for DHCP to exhaust all its possibilities).

  | I figure the only way
  | to meet the usability requirements is to run the state machines in
  | parallel and deprecate the v4LL address later if DHCP happens to
  | succeed.

Fine, I have no problem with that.

  | Time syncing the state machines is kind of hard, as the DHCP
  | client is in user space and the v4LL protocol is in kernel space.

That's an implementation choice, you could move either to the other
space.   When one makes implementation choices, one, of course, has to
live with the consequences.

  | If synching the state machines is a requirement, I'm afraid the DHCP client
  | will have to do it.

I see no problem with that either, and I don't think Ted does either.
What he's objecting to (I believe) is changing the nature of the DHCP
exchange (the DHCP protocol), not really to changing the dhcp client code.

kre