Subject: resolution of LL52 LL54 LL55 LL56 LL57 LL58 LL59 LL60 LL61 LL62 LL64 LL65 LL66 LL67 LL68 LL69

From: Erik Guttman <[email-masked]>
Date: Tue, 25 May 2004 17:52:37 +0200 (CEST)

-----  ----------  -------------------------------

Issue Type Title                                              Recommend
----- ---- -------------------------------------------------- ---------
LL52   t    Text surrounding RFC 2119 clause is poor           Accept
LL53   e    Forward references requested                       Open
LL54   e    Consistent terminology for out of scope            Accept
LL55   e    'Prevent' is too strong                            Accept (?)
LL56   t    Contradictory text?                                Reject (?)
LL57   e    Straightforward editorial fixes                    Accept
LL58   t    Duplicate inconsistent routable address            Accept
             definition
LL59   e    Wireless comment not needed                        Accept
LL60   e    Forward reference style                            Reject
LL61   t    Remove random wait                                 Accept
LL62   t    Do not space probes randomly                       Reject
LL63   e    Text should be more explicit                       Open
LL64   e    Simplify some text                                 Accept
LL65   t    need a requirement for multihomed hosts            Reject
LL66   t    Additional statistical example                     Reject
LL67   t    Fix clause which forbids routable to LL commun-    Accept
             ication
LL68   e    Stress constants are not user configurable         Reject
LL69   e    Move constants to beginning of doc                 Reject
LL70   t    DNAv4 normative or informative?                    Open

Remarks

LL52
   ACCEPT with strong consensus: Use RFC 2119 recommended text.

    Authors who follow these guidelines
    should incorporate this phrase near the beginning of their document:

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in
       RFC 2119.

LL53
   OPEN - further discussion needed.  Se separate email.

LL54
   ACCEPT - consensus was to use 'out of scope' consistently
   dissent: this is a trivial issue

LL55
   ACCEPT: Consensus was to use a slight variation of the suggested
      text.

In 1.4 change
    In order to prevent use of IPv4 Link-Local addresses in off-link
    communication, the following cautionary measures are advised:

To:
    To preclude use of IPv4 Link-Local addresses in off-link
    communication, the following cautionary measures are advised:

LL56
   REJECT: There is not strong consensus to make this change.

LL57
   ACCEPT: Make suggested edits.
   Dissent: some changes are too trivial to bother with at this stage

   One dissenting opinion was based on a mistaken reading of the suggested
   change:  A constant changed from 'ten seconds' to WATCH_WAIT.  Sorry
   being unclear in my presentation.

   Changes are not listed for sake of brevity - see the issue text.

LL58
   ACCEPT: Strong consensus supports the change.
>1.9.  When to configure a Link-Local IPv4 address
>
>    Having addresses of multiple different scopes assigned to an
>    interface, with no adequate way to determine in what circumstances
>    each address should be used, leads to complexity for applications and
>    confusion for users.  A host with an address on a link can
>    communicate with all other devices on that link, whether those
>    devices use Link-Local addresses, or routable addresses.  For these
>    reasons, a host SHOULD NOT have both a valid routable address and a
>    Link-Local IPv4 address configured on the same interface.
>
>    A routable address is any address that is:
>
>    * a unicast address (see Section 1.2)
>    * not a loopback address
>    * not contained within the 169.254/16 prefix reserved for Link-Local
>       IPv4 addresses
>
>To
>
>1.9.  When to configure an IPv4 Link-Local address
>
>    Having addresses of multiple different scopes assigned to an
>    interface, with no adequate way to determine in what circumstances
>    each address should be used, leads to complexity for applications and
>    confusion for users.  A host with an address on a link can
>    communicate with all other devices on that link, whether those
>    devices use Link-Local addresses, or routable addresses.  For these
>    reasons, a host SHOULD NOT have both a valid routable address and an
>    IPv4 Link-Local address configured on the same interface.

And -
Replace

   This document uses the term "routable address" to refer to all
   unicast IPv4 addresses outside the 169.254/16 prefix, including
   global addresses and private addresses such as Net 10/8 [RFC1918],
   all of which may be forwarded via routers.

with

   This document uses the term "routable address" to refer to all valid
   unicast IPv4 addresses outside the 169.254/16 prefix that may be
   forwarded via routers. This includes all global IP addresses and
   private addresses such as Net 10/8 [RFC1918], but not loopback
   addresses such as 127.0.0.1

LL59
   ACCEPT:  The only reason we can come up with to keep this text is to
   appease an IESG comment.  No one supports the text.  Remove it and work
   with the IESG to resolve the issue if it becomes a problem.

Omit

>  (This example does
>            not imply that IPv4 Link-Local configuration is inapplicable
>            to wireless interfaces).

LL60
   REJECT.  The change was too large for most of the WG to accept at this
   phase.  I share concern that references within the document would change
   and require extensive editorial checking.

LL61
   ACCEPT.  The proposed solution is an amalgam of suggestions.

section 2.2.1 Text was:

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

Text becomes:

   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.

Alex Eldar noted that we have to change our terminology for:

Was:
   If during this period, from the beginning of the probing process
   until PROBE_MAX seconds after the last probe packet is sent, the host

Becomes:
   If during this period, from the beginning of the probing process
   until DEFEND_INTERVAL seconds after the last probe packet is sent, the host

And was:
   If, by PROBE_MAX seconds after the transmission of the last ARP probe
   no conflicting ARP Reply or ARP probe has been received, then the
   host has successfully claimed the desired IPv4 Link-Local address.

Becomes:
   If, by DEFEND_INTERVAL seconds after the transmission of the last ARP probe
   no conflicting ARP Reply or ARP probe has been received, then the
   host has successfully claimed the desired IPv4 Link-Local address.

LL62
   REJECT: This was consensus to reject the issue, though not strong
   consensus.
   Dissent: More than one contributor felt that the additional random
   delays are unnecessary - that a fixed delay between probes is
   sufficient.  Their arguments did not convince others in the WG.

LL63
   OPEN - further discussion needed

LL64
   ACCEPT
Change
    The application knows
    the source address of the sender to whom the application will reply.

    The first scoped address problem is source address selection. ...

to:

    The application knows
    the address of the sender to which the application will reply.

    The first scoped address problem is source address selection.

LL65
    REJECT: There was consensus to reject the issue.

LL66
    REJECT: There was consensus to reject the issue.

LL67
    ACCEPT: There was strong consensus support for this issue.

Section 6.2, From:

>    IPv4 Link-Local addresses MUST NOT be forwarded via an application
>    protocol (for example in a URL), to a destination which is not Link-
>    Local, on the same link.  This is discussed further in Section 2.9
>    and 3.

To:

>    IPv4 Link-Local addresses MUST NOT be forwarded via an application
>    protocol (for example in a URL), to a destination which is not
>    on the same link.  This is discussed further in Section 2.9 and 3.

LL68
    REJECT: There was insufficient support to make this change.

LL69
    REJECT: There was insufficient support to make this change.  Further,
    it would introduce the risk that references would no longer be accurate.

LL70
    OPEN - further discussion needed

-------------
Erik Guttman
ZEROCONF WG chair

---

From: Erik Guttman <[email-masked]>
Date: Tue, 25 May 2004 18:00:29 +0200 (CEST)

The resolutions which I included in this message are my reading of the
discussion in the preceeding last call periods.  If you believe that I
have misread the consensus, please bring this up on the working group
mailing list.  I remind participants that a very high degree of agreement
is needed to make a change at this late in the process.

I will not be able to respond to the ensuing discussion until Monday 31
May.

Best regards,

Erik Guttman
ZEROCONF WG Chair

 On Tue, 25 May 2004, Erik Guttman wrote:

> LL55   e    'Prevent' is too strong                            Accept
> LL56   t    Contradictory text?                                Reject

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 26 May 2004 10:20:21 +0100

I will reiterate my comment on one of the "editorial" changes of LL57 since the comment semems to have got lost among the mass of changes which were proposed under a single heading. I am not happy with simply accepting the proposed change as is.

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

I am in favour of parameterizing WATCH_WAIT but we should do it properly. As proposed the *parameter* WATCH_WAIT is specific to IEEE802. It should be the *value* of WATCH_WAIT that is IEE802 specific - other transports may get different values for the same parameter. The text should read:

"...and it has not seen any other conflicting ARP packets within WATCH_WAIT seconds then it MAY elect..."

and add in section 9:
WATCH_WAIT    10 seconds for IEEE 802 networks

Philip Nye