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