new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer

Erik Guttman <[email protected]> Fri, 05 Dec 2003 16:42:16 +0100
Newsgroups gmane.ietf.zeroconf
Message-ID <[email protected]>
We need to evaluate whether to make this change.  NOTE: TEXT IS NEEDED,
please contribute some.

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

Description of Issue  Combine and rework section 1.7 and 2.11 to be clearer
Submitter Name  Ralph Droms
Submitter Email Address  [email protected]
Date first submitted  15.10.03
Reference
Comment Type ['T'echnical | 'E'ditorial]  T
Priority ['S' Must fix | '1' Should fix | '2' May fix ]  1
Section  1.7
Rationale/Explanation of issue:

Seems to me the underlying issue is the interaction between v4LL and any
"working routable address" (a routable address that can be used for 
off-link communication). That is, I don't think it matters where the 
routable address comes from - whether it be DHCP, manual configuration, or 
some other mechanism - rather, the issue is how to get the interface to a 
state in which it can use a v4LL address when no working routable address 
is available Lengthy description of problem:

The way in which I would describe how a device uses v4LL would be to use 
the state of the interface itself as the basis for invoking v4LL. If an
interface does not have a working routable address, the device invokes 
v4LL for that interface. When the interface does have a working routable
address, v4LL is not used.

The issue of when to use v4LL is indirectly addressed in section 1.7 and
more directly in 2.11. I suggest combining 1.7 and 2.11 into a single
section that:

* states the conditions under which v4LL is used (paraphrasing what I wrote
in the previous paragraph)
- based on state of interface
- defines "working routable address"
- v4LL used when no working routable address is available
* gives pointers to other documents, such as draft-ietf-dhc-dns-ipv4-01.txt,
that define how to determine if an interface has a working routable address
* points out the it is an implementation detail for the protocol software to
monitor the state of the interface and invoke v4LL as appropriate
* emphasizes that v4Ll has no effect on the use of other configuration
mechanism

Requested Change:

<TEXT IS NEEDED!>