resolution of LL52 LL54 LL55 LL56 LL57 LL58 LL59 LL60 LL61 LL62 LL64 LL65 LL66 LL67 LL68 LL69
Erik Guttman <[email protected]> Tue, 25 May 2004 17:52:37 +0200 (CEST)
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
----- ---------- -------------------------------
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