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

Erik Guttman <[email protected]> Wed, 16 Jun 2004 21:04:42 +0200 (CEST)
Newsgroups gmane.ietf.zeroconf
Message-ID <[email protected]>
Stuart,

Please send specific FROM/TO text change proposals and specify which
sections would change.

Thanks,

Erik

----------------------------------------------------------
On Tue, 15 Jun 2004, Stuart Cheshire wrote:

> >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
>
>