Re: Please review draft-ietf-zeroconf-ipv4-linklocal-15.txt !

>Over the course of the next week, ending June 15, 2004, please
>review the latest internet draft specifying IPv4LL.  The goal is
>
> * to verify the changes we have agreed upon
> * to find any additional typographic or technical errors

We are I think, very close to having something to celebrate.

I re-read the entire draft from start to end, and found only one 
technical issue to comment on. I think it's just an accidental typo, so 
I'm hoping there will be no resistance to fixing it.

In my email of 6th May, I proposed a symbolic constant "DEFEND_INTERVAL", 
to replace the text "recently (for IEEE 802, within the last ten 
seconds)" in Section 2.5. My intention was that this text:

   (b) If a host currently has active TCP connections or other reasons
   to prefer to keep the same IPv4 address, and it has not seen any
   other conflicting ARP packets recently (for IEEE 802, within the last
   ten seconds) then it MAY elect to attempt to defend its address

becomes:

   (b) If a host currently has active TCP connections or other reasons
   to prefer to keep the same IPv4 address, and it has not seen any
   other conflicting ARP packets within the last DEFEND_INTERVAL seconds
   then it MAY elect to attempt to defend its address

The value of DEFEND_INTERVAL was ten seconds (of course) and the 
description was "minimum time between defensive ARPs".

Somehow in the process of editing, a new constant was introduced for the 
minimum interval between defensive ARPs, called WATCH_WAIT, and 
DEFEND_INTERVAL got re-used for something quite different -- the pause 
between probing and announcing. The value got left at ten seconds.

Both the name and the value are inappropriate.

I think the name for this constant (time after last probe before 
beginning announcing) should be "ANNOUNCE_WAIT", and the value should be 
one second.

I hope this can be fixed without long debate. I think it's clear that no 
purpose is served by having the host sit around doing nothing for ten 
seconds before beginning to use the address it's successfully selected. 
One second is plenty long enough to receive a reply to the ARP Probe. 
More is just pointless delay.

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