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

Folks,

Let's arrive at a decision within the next week about these proposed
changes.  If I hear nothing or there is no serious dissent, I will
recommend we make the changes.  Please respond by June 29, 2004.

I mention the section numbers where the changes are made to assist your
evaluation.

Here is my opinion about the changes amount to:

START_WAIT

1) change:     START_WAIT renamed to PROBE_WAIT
   section:    1.3
   rationale:  esthetic
   impact      changes must be consistent

2) change      START_WAIT renamed to PROBE_WAIT
   section:    2.2.1
   rationale   esthetic
   impact      changes must be consistent

3) change      START_WAIT renamed to PROBE_WAIT
   section     9
   rationale   esthetic
   impact      changes must be consistent

ANNOUNCE_N

1) change:     ANNOUNCE_N renamed to ANNOUNCE_NUM
   section:    1.3
   rationale:  as 2)
   impact:     all references must be consistent

2) change      ANNOUNCE_N renamed to ANNOUNCE_NUM
   section     2.4
   rationale:  esthetic, maybe the new constant is slightly clearer
   impact:     all references must be consistent

3) change      ANNOUNCE_N renamed to ANNOUNCE_NUM
   section     9
   rationale   as 2)
   impact      all references must be consistent


WATCH_WAIT

1) change:     WATCH_WAIT renamed to DEFEND_INTERVAL
   section:    1.3
   rationale:  as 3)
   impact:     all references must be consistent

2) change:     WATCH_WAIT renamed to DEFEND_INTERVAL
   section:    2.5
   rationale:  as 3)
   impact:     all references must be consistent

3) change:     WATCH_WAIT renamed to DEFEND_INTERVAL
   section:    9
   rationale:  the naming change is esthetic.
               the text for WATCH_WAIT in draft 15 inappropriate, it
               should changed from:

Was:
    DEFEND_INTERVAL     10 seconds  (after probes, wait for defense)
    WATCH_WAIT          10 seconds  (time to continue to defend your address,
                                     for IEEE 802 networks)

Becomes:
    DEFEND_INTERVAL     10 seconds  (min interval between defensive ARPs)

   impact:     The change would remove the sense of the text in section
               2.5.  Argument:

               The text in section 2.5 says if a host is configured with
               an address A and has this address is in use, and the host
               detects an arp from a source address A it may elect to
               defend.  It sends its own arp from source address A and
               waits 10 seconds, for 802 networks.  If the host receives
               another arp from source address A it gives up the address.
               Otherwise it keeps the address configuration for A.

               If this 10 second interval is described as "time to
               continue to defend your address, for IEEE 802 networks"
               this indicates we are waiting and watching for 10 seconds
               to defend an address.  If the 10 second interval is
               described as "min interval between defensive ARPs" there
               is no obvious relationship to the text in section 2.5.

DEFEND_INTERVAL

1)  change     DEFEND_INTERVAL becomes ANNOUNCE_WAIT

     from:

   When ready to begin probing, the host should then wait for a random
   time interval selected uniformly in the range zero to START_WAIT
   seconds, and should then send PROBE_NUM probe packets, each of these
   probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart.

   If during this period, from the beginning of the probing process
   until DEFEND_INTERVAL seconds after the last probe packet is sent,
         ^^^^^^^^^^^^^^^
   the host receives any ARP packet (Request *or* Reply) on the
   interface where the probe is being performed where the packet's
   'sender IP address' is the address being probed for, then the host
   MUST treat this address as being in use by some other host, and MUST
   select a new pseudo-random address and repeat the process.  In
   addition, if during this period the host receives any ARP probe where
   the packet's 'target IP address' is the address being probed for, and
   the packet's 'sender hardware address' is not the hardware address of
   the interfaces the host is attempting to configure, then the host
   MUST similarly treat this as an address collision and select a new
   address as above. This can occur if two (or more) hosts attempt to
   configure the same IPv4 Link-Local address at the same time.


    section    2.2.1
    rationale  This is an error:  This adds 9 seconds of needless delay.
    impact:

      This significantly changes the protocol operation.  Given a 10
      second constant, the protocol functions as follows.

       action time span                      total time
       delay  [0..START_WAIT=1]              0-1
       probe  (instantaneous)
       wait   [PROBE_MIN=1, PROBE_MAX=2]     1-3
       probe  (instantaneous)
       wait   [PROBE_MIN=1, PROBE_MAX=2]     -5
       probe  (instantaneous)
       wait   [DEFEND_INTERVAL=10]           13-15
       announce (instantaneous)
       wait   [ANNOUNCE_INTERVAL=2]          14-17


      That is, a host will wait
2)  change:    DEFEND_INTERVAL changed to ANNOUNCE WAIT

   was:


   becomes:
     rationale:
     impact:


3)  change     add ANNOUNCE_WAIT   1 second (delay before announcing)
               instead of DEFEND_INTERVAL 10 seconds (after probes wait
                                                      for defense)
    section    9
    rationale  see 1)
    impact     see 1)



On Mon, 21 Jun 2004, Stuart Cheshire wrote:

> >Stuart,
> >
> >Please send specific FROM/TO text change proposals and specify which
> >sections would change.
> >
> >Thanks,
> >
> >Erik
>
> Specific diffs attached.
>
> It's basically just a textual cleanup so the symbolic constants make
> sense and are internally consistent. Summary:
>
> START_WAIT      -> PROBE_WAIT
> DEFEND_INTERVAL -> ANNOUNCE_WAIT
> ANNOUNCE_N      -> ANNOUNCE_NUM (for consistency with PROBE_NUM)
> WATCH_WAIT      -> DEFEND_INTERVAL (min interval between defensive ARPs)
>
> Stuart Cheshire <[email protected]>
>  * Wizard Without Portfolio, Apple Computer, Inc.
>  * www.stuartcheshire.org
>