Re: [DNA] Proposed Resolution to DNAv4 Issue 30

[Henrik Levkowetz <henrik@levkowetz.com>]

Hi Bernard,

On 2005-07-28 01:20 Bernard Aboba said the following:
> The text of DNAv4 issue 30 is enclosed below.  This and other DNAv4 issues
> are tracked on the DNAv4 Issue page, located at:
> http://www.drizzle.com/~aboba/DNA/

Good point.  Experience with the ipUnplugged MIPv4 client implementation
indicated clearly that doing parallel (multiple) reachability testing and
DHCPv4 address acquisition is worthwhile.

> A version of the document with the proposed changes applied is available
> here:
> http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-14.txt

or http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-14.txt 

> The proposed resolution is as follows:
> 
> In Section 1.2, change the definition of MLN to:
> 
> "Most Likely Networks (MLNs)
> The attached network(s) determined by the host to be most likely."
> 
> Change Section 2, 2.1, 2.2 and 2.3 to the following:
> 

Some comments:

[...]

> Where there is more than one MLN, the host can test reachability to
> the MLN(s) in serial or in parallel. An implementation can also
> attempt to obtain IPv4 configuration via DHCPv4 in parallel with one
> or more reachability tests, with the host using the first answer
> returned. These optimizations reduce the reliance on link and
> Internet layer hints, which may not be present or may be misleading.
> Attempting to obtain IPv4 configuration via DHCPv4 in parallel is

Maybe s/in parallel/in parallel with reachability testing/ ?

> particularly valuable in implementations that only test reachability
> of a single MLN. Since confirming failure of a reachability test
> requires a timeout, mistakes are costly and therefore sending a
> DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131]
> Section 3.2 and 4.3.2 may complete more quickly than the reachability
> test.

[...]

> Appendix A discusses hints useful for the determination of the
> MLN(s). By matching received hints against network parameters
> previously stored, an implementation testing reachability to a single
> MLN can make an an educated guess as to which network it has attached
> to. Alternatively, an implementation that simultaneously tests
> reachability to multiple MLNs can select them solely based on the
> networks it has most recently connected to, in which case it may not
> be necessary to consult hints.

Reads a bit awkwardly to me, and leaves out one reasonable strategy.
Maybe something like:

  "Appendix A discusses hints useful for the determination of the
  MLN(s).  By matching received hints against network parameters
  previously stored, it is possible to select one or a set of networks
  as most likely.  An implementation that tests reachability to a single
  MLN would do its test based on the hints.  An implementation that
  simultaneously tests reachability to multiple MLNs may do the tests
  solely based on the networks it has most recently connected to, or
  may alternatively test a set of likely networks based both on
  networks recently connected to and networks selected based on the
  hints."



	Henrik