Multiple Interfaces and Provisioning Domains Problem Statement
RFC 6418

Thank you for the series of revisions to this I-D which I believe go far enough to allow me to clear my Discuss.

This is an useful document. The comments below are not blocking, but in case they are considered they could improve readability: 

1. In section 3.1 the following statement is made: 

>  Network discovery and selection on lower layers as defined by
   [RFC5113] is out of scope of this document.  Moreover, lower layer
   interaction such as IEEE 802.21 is also out of scope.

It would be good to be more exact about what is IEEE 802.21 - for example 

s/lower layer interaction such as IEEE 802.21/handover and interoperability between lower layer networks such as the mechanisms defined in IEEE 802.21/

An informative reference to IEEE 802.21 would also be in place. 

2. Expanding acronyms at their first occurance would be useful.

3. The OPS-DIR review performed by Menachem Dodge also included a number of useful editorial comments which I suggest to consider.

Some of the symptoms don't derive from the stated operational environments.  For example, in section 4.1:

   3.  H1 keeps only one set of DNS server addresses from the received
       configuration objects and kept S2 address.  H1 sends the DNS
       query for a.private.example.com to S2.  S2 asks its upstream DNS
       and gets an IP address for a.private.example.com.  However, the
       IP address is not the same one S1 would have given.  Therefore,
       the application tries to connect to the wrong destination host,
       or to the wrong interface of the latter, which may imply security
       issues or result in lack of service.

seems to be in conflict with the constraint at the top of the section that 'name "a.private.example.com" [...] is within the private namespace of S1 and only resolvable by S1'; that is, if the constraint holds, H1 would not get a resolution for a.private.example.com by sending a resolution query to S2.

Also in section 4.1:

   5.  H1 has resolved an FQDN to locally valid IP address when
       connected to N1.  After movement from N1 to N2, the host tries to
       connect to the same IP address as earlier, but as the address was
       only locally valid, connection setup fails.  Similarly, H1 may
       have received NXDOMAIN for an FQDN when connected to N1.  After
       movement from N1 to N2, the host should not assume the FQDN
       continues to be nonexistent.

what does "movement from N1 to N2" mean?

Still in section 4.1:

   A MIF host may also be provisioned with a Interface-specific suffix
   search list ([I-D.ietf-mif-current-practices]).  In this situation,
   if H1 sends DNS query on I1 using the search list tied to I2, the
   namespace could be not valid on I1 and the name could be not
   resolved.

isn't the described host behavior clearly a bug in the host stack?

From Andrew Sullivan, dns-directorate review:

 First, this is an implicit recognition that the DNS namespace is not
 actually a single, unified namespace.  I think that's just
 acknowledging the facts in the world, but I know there are people
 opposed to that.

 Second, it seems to be setting up the mif WG to be trying to "solve"
 the DNS split-views problem.  I think this effectively means that
 we're (i.e. the dns-dir crowd) will need to keep on top of MIF.

Some very minor editorial suggestions:

Is there a missing word (I think "may" at "may have") in the first sentence of
the introduction?

Should the first sentence of 3.6 start with "An Application"?

  My concern is already captured in DISCUSS posiotns held by Ralph,
  so I am not going to pile on.  However, I do want to make it known
  that I also have the same concern.  (Note the same concern was
  raiseed by Roni Even in his Gen-ART Review dated 24-Aug-2010.)