Re: my response to the proposed changes

>That is what I mean by holding onto one's address.  The only point where
>I think we disagree is that the *text* for WATCH_WAIT is the same as for
>DEFENSE_INTERVAL in section 9.  Since both are set at 10 seconds
>presently, we are really only disagreeing over which version of the text
>is clearer, right?
>
>Best regards,
>
>Erik

I'm just puzzled by the choice of the term "WATCH_WAIT" for the 
ten-second time constant.

It implies that you're watching for ten seconds for something (you're not 
-- you're *always* watching for conflicting ARPs) or that you're waiting 
for ten seconds for something (you're not -- there's no waiting).

To emphasize that there's no waiting or any other disruption to normal 
operation, the draft even spells this out explicitly:

   Having done this, the host can then continue to use the address
   normally without any further special action.

The whole point of this text was to explicitly state that there's *no* 
need for the host to stop what it's doing, and wait for ten seconds 
watching to see if there's another conflicting ARP, before it can resume 
normal operation. Normal operation continues without interruption. 
Calling the constant WATCH_WAIT kind-of undermines that message.

The ONLY relevance of the ten-second time constant is that it imposes a 
rate-limit on the frequency of defensive ARPs that are allowed, to 
prevent storms. Sensible names might be:

  DEFEND_INTERVAL
  MINIMUM_DEFEND_INTERVAL
  DEFENSIVE_ARP_RATE_LIMIT
  RETALIATORY_ARP_RATE_LIMIT
  MANDATORY_RECONFIGURE_WINDOW
  ... and so on.

Stuart Cheshire <[email protected]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org