WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes

Erik Guttman <[email protected]> Wed, 5 May 2004 01:02:06 +0200
Newsgroups gmane.ietf.zeroconf
Message-ID <a05200f16bcbdce7de92d@[80.139.178.51]>
Please post discussion of this issue to the mailing list over the 
next two weeks
ending May 18, 2004.  In order to accept this issued, we will need a strong WG
consensus given that this is very late in the process.

Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of
current issues and their status.

[LL57]

Description of Issue:		Straightforward editorial fixes
Submitter Name:		Stuart Cheshire
Submitter Email Address:	[email protected]
Date first submitted:		04 May 04
Reference:
Comment Type ['t'ech|'e'dit]:	e
Prio ['S' Must|1 should|2 may]:	1
Section:			1.9
Rationale/Explanation:
Lengthy Description:
Requested Change:

---

>1.9.  When to configure a IPv4 Link-Local address

Search and replace "a IP" with "an IP"

---

[Stuart]

>2.4.  Announcing an Address
>
>    The host MUST then announce its claimed address by broadcasting
>    PROBE_N ARP announcements, spaced PROBE_MAX seconds apart.

Change to:

>  ANNOUNCE_N ARP announcements, spaced ANNOUNCE_INTERVAL seconds apart

Add to section 9:

ANNOUNCE_N        2
ANNOUNCE_INTERVAL 2 seconds

---

Section 2.5

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

    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
|  WATCH_WAIT seconds) then it MAY elect to attempt to defend its address, by
    recording the time that the conflicting ARP packet was received, and
    then broadcasting one single ARP announcement, giving its own IP and
    hardware addresses as the sender addresses of the ARP.  Having done
    this, the host can then continue to use the address normally without
    any further special action.  However, if this is not the first
    conflicting ARP packet the host has seen, and the time recorded for
    the previous conflicting ARP packet is recent (within WATCH_WAIT
    seconds for IEEE 802) then the host MUST immediately cease using this
    address and configure a new IPv4 Link-Local address as described
    above.  This is necessary to ensure that two hosts do not get stuck
    in an endless loop with both hosts trying to defend the same address.

---

2.6.2

>    Whichever interface is used, if the destination address is in the
>    169.254/16 prefix (excluding the address 169.254.255, which is the
>    broadcast address for the Link-Local prefix), then the sender MUST

169.254.244

becomes

169.254.255.255

---

3.1

>  >   This answer is usually answered by referring to a routing table,
>  >   which expresses which interface (with which address) to send, and how

becomes

   This question is usually answered by referring to a routing table,
   which expresses on which interface (with which address) to send, and how

---

from:

>  >3.4.  Unintentional Autoimmunity

to:

>  >3.4.  Unintentional Autoimmune Response

---

6.1
From:

    IPv4 Link-Local addresses used by an application may change over
    time. Some application software encountering an address change will
    fail. For example, client TCP connections will fail,

to:

    IPv4 Link-Local addresses used by an application may change over
    time. Some application software encountering an address change will
    fail. For example, existing client TCP connections will be aborted,

---

6.2
From:

>    If the FTP client transmits its passive IPv4

to:

>    If the FTP client transmits its stale out-of-date passive IPv4

---