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

Comments inline.

- Ralph

At 01:02 AM 5/5/2004 +0200, Erik Guttman wrote:
>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"

OK with me.

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

OK with me.

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

Is the replacement of "ten" with "WATCH_WAIT" the only proposed change?  If
so, I agree - noting that "WATCH_WAIT" needs to be added to the section
in which constants are defined.

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

Assuming 169.254.255 is what is replaced, this change is OK with me.

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

OK with me.

>---
>
>from:
>
>>  >3.4.  Unintentional Autoimmunity
>
>to:
>
>>  >3.4.  Unintentional Autoimmune Response

OK with me.

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

OK with me.

>---
>
>6.2
>From:
>
>>    If the FTP client transmits its passive IPv4
>
>to:
>
>>    If the FTP client transmits its stale out-of-date passive IPv4

OK with me.