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