Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
RFC 6731

[Ballot comment]
Thanks for addressing the majority of the points I raised.

Please consider the one remaining (this is not blocking - if you choose to do nothing it's up to you):

You added text discussing what the effect on a local cache would be when an interface was removed.
Should you say something about what happens if the relative priority of interfaces change? (Or are you
perhaps thinking that would be the same as removal of an interface and addition of a new one?)

[Ballot discuss]

For -11, we just have point 3 left where we agreed a sentence but I don't
see any change in 4.5.

(1) cleared

(2) cleared

(3) I don't see how a piece of DNS or DHCP code can know if the criteria
in 4.5 apply, at least as they are stated now. For example, for
criterion 1, how can a piece of code know that a given network
provides a "secure, trusted channel"? There are cases where you can
know, but they're not called out here in a way that can be implemented
it seems. My concern is that implementations will just assume its ok
and then be vulnerable. (Sentence agreed)

(4) cleared

[Ballot discuss]

In the process of updating these for -10

(1) cleared

(2) What is the lifetime of the domain/network information received in a
DHCP response? 4.2 is vague about that, talking about "general
events." Given that DHCP lease times vary enormously I'd have thought
you'd need to be more precise here. (stateful  = lease time, stateless
who knows, so implementation specific)

(3) I don't see how a piece of DNS or DHCP code can know if the criteria
in 4.5 apply, at least as they are stated now. For example, for
criterion 1, how can a piece of code know that a given network
provides a "secure, trusted channel"? There are cases where you can
know, but they're not called out here in a way that can be implemented
it seems. My concern is that implementations will just assume its ok
and then be vulnerable. (Sentence agreed)

(4) cleared

[Ballot discuss]

In the process of updating these for -10

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced that
implementations would all do the same thing based on this description
and with the same input preferences. Is it required that different
implementation's behaviour be the same in that case? If not, then lots
of the 2119 language ought to be omitted. If so, then I think you need
to re-write it more clearly, e.g. using pseudo-code. (Or convince
me this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in a
DHCP response? 4.2 is vague about that, talking about "general
events." Given that DHCP lease times vary enormously I'd have thought
you'd need to be more precise here. (stateful  = lease time, stateless
who knows, so implementation specific)

(3) I don't see how a piece of DNS or DHCP code can know if the criteria
in 4.5 apply, at least as they are stated now. For example, for
criterion 1, how can a piece of code know that a given network
provides a "secure, trusted channel"? There are cases where you can
know, but they're not called out here in a way that can be implemented
it seems. My concern is that implementations will just assume its ok
and then be vulnerable. (Sentence agreed)

(4) cleared

[Ballot discuss]

In the process of updating these for -10

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced that
implementations would all do the same thing based on this description
and with the same input preferences. Is it required that different
implementation's behaviour be the same in that case? If not, then lots
of the 2119 language ought to be omitted. If so, then I think you need
to re-write it more clearly, e.g. using pseudo-code. (Or convince
me this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in a
DHCP response? 4.2 is vague about that, talking about "general
events." Given that DHCP lease times vary enormously I'd have thought
you'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteria
in 4.5 apply, at least as they are stated now. For example, for
criterion 1, how can a piece of code know that a given network
provides a "secure, trusted channel"? There are cases where you can
know, but they're not called out here in a way that can be implemented
it seems. My concern is that implementations will just assume its ok
and then be vulnerable.

(4) section 6, 3rd para: is the MUST there expected to be enforced?  If
so how and by whom?

[Ballot comment]
I didn't udate these for -10

(This could do with an editorial pass but I'm only going to note
places where a change is more than purely grammatical.)

- Is the title ok? The spec is more about private namespaces but
the title reads as something more generic.

- abstract: s/contact to./contact./ but maybe "use" is better than
contact anyway.

- section 1, 4th para: selection of "route"? do you mean interface?
(Also is "IP connection" right given UDP is most commonly used
for DNS?)

- section 1, 4th para: be good to give some refs to the kinds of tool
you mean in the last sentence. (If possible)

- Acronyms like VLAN, WLAN etc. would be better expanded

- 4.1, 2nd para on p10 says "routes" again, which is probably wrong

- 4.1 mentions "medium priority" but that's not been introduced

- 4.1 says you "MUST" take into account trust levels but those aren't
defined and are left to implementations, so I'm not sure that 2119
MUST is usefuln (see dicsuss point 1 as well)

- The encoding of the domains and networks in figure 5 is a bit
opaque, the reference to 3315 for example is to a section that is 5
lines long and refers to 1035. Would some more descriptive material or
examples help here? I can imagine implementers going wrong here, but
perhaps its ok and the people who'd write code for this would be
fine.

- OPTION_ORO could do with a reference or brief explanation in 4.2
for the less DHCP-literate (like me:-)

- I can't parse this, from 4.5: "In the case of DHCPv4 and DHCPv6
providing conflicting RDNSS selection information on the same
interface, or on the equally trusted interfaces, the node SHALL
firstly prefer DHCP-version possibly securing
OPTION_DNS_SERVER_SELECT, and secondly prefer DHCPv6 over DHCPv4."

- last para of 4.5, would s/may choose to omit/MAY omit/ be better?

- section 7, 2nd para, that MUST is really a SHOULD isn't it?  (There
are exceptions and its not enforceable.)

[Ballot discuss]

In the process of updating these for -09

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced that
implementations would all do the same thing based on this description
and with the same input preferences. Is it required that different
implementation's behaviour be the same in that case? If not, then lots
of the 2119 language ought to be omitted. If so, then I think you need
to re-write it more clearly, e.g. using pseudo-code. (Or convince
me this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in a
DHCP response? 4.2 is vague about that, talking about "general
events." Given that DHCP lease times vary enormously I'd have thought
you'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteria
in 4.5 apply, at least as they are stated now. For example, for
criterion 1, how can a piece of code know that a given network
provides a "secure, trusted channel"? There are cases where you can
know, but they're not called out here in a way that can be implemented
it seems. My concern is that implementations will just assume its ok
and then be vulnerable.

(4) section 6, 3rd para: is the MUST there expected to be enforced?  If
so how and by whom?

[Ballot discuss]

In the process of updating these for -09

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced that
implementations would all do the same thing based on this description
and with the same input preferences. Is it required that different
implementation's behaviour be the same in that case? If not, then lots
of the 2119 language ought to be omitted. If so, then I think you need
to re-write it more clearly, e.g. using pseudo-code. (Or convince
me this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in a
DHCP response? 4.2 is vague about that, talking about "general
events." Given that DHCP lease times vary enormously I'd have thought
you'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteria
in 4.4 apply, at least as they are stated now. For example, for
criterion 1, how can a piece of code know that a given network
provides a "secure, trusted channel"? There are cases where you can
know, but they're not called out here in a way that can be implemented
it seems. My concern is that implementations will just assume its ok
and then be vulnerable.

(4) section 6, 3rd para: is the MUST there expected to be enforced?  If
so how and by whom? This is unchanged from -08.

[Ballot comment]
I didn't udate these for -09

(This could do with an editorial pass but I'm only going to note
places where a change is more than purely grammatical.)

- Is the title ok? The spec is more about private namespaces but
the title reads as something more generic.

- abstract: s/contact to./contact./ but maybe "use" is better than
contact anyway.

- section 1, 4th para: selection of "route"? do you mean interface?
(Also is "IP connection" right given UDP is most commonly used
for DNS?)

- section 1, 4th para: be good to give some refs to the kinds of tool
you mean in the last sentence. (If possible)

- Acronyms like VLAN, WLAN etc. would be better expanded

- 4.1, 2nd para on p10 says "routes" again, which is probably wrong

- 4.1 mentions "medium priority" but that's not been introduced

- 4.1 says you "MUST" take into account trust levels but those aren't
defined and are left to implementations, so I'm not sure that 2119
MUST is usefuln (see dicsuss point 1 as well)

- The encoding of the domains and networks in figure 5 is a bit
opaque, the reference to 3315 for example is to a section that is 5
lines long and refers to 1035. Would some more descriptive material or
examples help here? I can imagine implementers going wrong here, but
perhaps its ok and the people who'd write code for this would be
fine.

- OPTION_ORO could do with a reference or brief explanation in 4.2
for the less DHCP-literate (like me:-)

- I can't parse this, from 4.5: "In the case of DHCPv4 and DHCPv6
providing conflicting RDNSS selection information on the same
interface, or on the equally trusted interfaces, the node SHALL
firstly prefer DHCP-version possibly securing
OPTION_DNS_SERVER_SELECT, and secondly prefer DHCPv6 over DHCPv4."

- last para of 4.5, would s/may choose to omit/MAY omit/ be better?

- section 7, 2nd para, that MUST is really a SHOULD isn't it?  (There
are exceptions and its not enforceable.)

[Ballot comment]
UPDATE: The -09 version fixes the IANA section and makes Section 4.1 much clearer.  I know this took some back-and-forth and some bit of work, so thanks very much for taking the time to do it.  I'm also satisfied with the resolution of my non-blocking comments, and thanks for that as well.


Comments saved for posterity...
========
These were formerly DISCUSS comments, and have since been addressed; thanks.

-- 4.1 --
  The resolver MUST NOT
  prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

  The RDNSSes of
  untrusted interfaces may be of highest priority only if trusted
  interfaces specifically configure low priority RDNSSes.  The non-
  exhaustive list on figure 4 illustrates how the different trust
  levels of received RDNSS selection information SHOULD influence the
  RDNSS selection logic.

You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one.


-- IANA Considerations --
Perhaps this is clear enough for IANA, but I see registries specified without their proper names, so I worry:

1. It looks like the first option code is meant to go into the "BOOTP Vendor Extensions and DHCP Options" registry in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".

2. It looks like the second option code is meant to go into the "DHCP Option Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".

Please either confirm or correct that and put the *exact* names of the registries in (you can look for them in http://www.iana.org/protocols/ ).  That avoids problems for IANA later.

========
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

This comment is short of being a DISCUSS, because the document is generally OK and I think I've understood it.  I have great respect for the work of the non-native-English editors; still, there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing.  I'd like to see the native-English-speaking co-editor (or some other volunteer) go over the document and make sure the articles, tenses, plurals, and commas are right.  There's a lot of fixing needed.

-- 4.1 --
   For security reasons the RDNSS selection information MUST be used
   only when it is safe to do so, see Section 4.4 for details.

This phrasing is easy to misinterpret ("[x] MUST be used").  I suggest casting it more directly:
   For security reasons the RDNSS selection information MUST NOT be
   used unless it is safe to do so, see Section 4.4 for details.

-- 4.1 --
   Trustworthiness of an interface and configuration information
   received over the interface is implementation and/or node deployment
   dependent.

...and, I presume, the specification of that trust model is out of scope for this document.  I suggest you explicitly say that, before you give the (very good) examples:
   Trustworthiness of an interface and configuration information
   received over the interface is implementation and/or node deployment
   dependent, and the details of determining that trust are beyond the
   scope of this specification.  Trust might, for example, be based on the
   nature of the interface: an authenticated and encrypted VPN, or a layer
   2 connection to a trusted home network, might be considered as trusted,
   while an unauthenticated and unencrypted connection to an unknown
   visited network would likely be considered as untrusted.  In some
   situations, an interface might be considered trusted only if it has been
   explicitly configured to be.

I remind you that "shall" is a 2119 keyword (synonymous with "must"), and you should be cautious in using it casually.

   If a DNS response is not proven to be unmolested using
   DNSSEC, then a node cannot make a decision to prefer data from any
   interface with any great assurance: any response could be forged, and
   there is no way to detect the forgery without DNSSEC.

First, this is a convoluted sentence, with too many negatives; second, you're burying the lede.  The important point here is that DNSSEC is necessary, so put it up front:
   DNSSEC is necessary to detect forged responses, and without it any
   DNS response could be forged or altered.  Unless the DNS responses
   have been validated with DNSSEC, a node cannot make a decision to
   prefer data from any interface with any great assurance.

-- Figures 5 and 6 --
   Reserved:      Field reserved for the future. MUST be set to zero.

It would seem to be useful for those future applications if we made sure that implementations didn't barf on receipt of some future value here.  Would this work?:
   Reserved:      Field reserved for the future. MUST be set to zero; MUST
                            be ignored on receipt.

-- Figure 8 --
Does this diagram tell me anything useful?  If so, I can't figure out what.  The only interesting part is in the "black box".

-- 10.2 --
   An implementation may not be able to
   determine trust levels without explicit configuration provided by
   user or administrator.

OK, if you're going to go there, I have to: do you really think there's any serious possibility of user configuration here, especially in the case of a home-network user?  I think that if you mention user configuration, you have to mention that in many, if not most, scenarios, user configuration is not a realistic possibility, and administrator configuration and policy heuristics are usually the only viable mechanisms.


========
Other comments; no need to respond to these. Take them or modify them
as you please:

"timeout" should be one word, not two (but "timed out" is, correctly, two).

-- 4.1 --
   The resolver SHOULD avoid sending queries over different network
   interfaces in parallel as that wastes resources such as energy.  The
   amount of wasted energy can be significant, for example when radio
   interfaces has to be started just for the queries.

Maybe it's just an artifact of where the page break happened, but I wondered what the "energy" thing was until I saw "radio interfaces" (on the next page).  I suggest using "power" rather than "energy", and specifically noting battery-powered and constrained environments.  Perhaps this:
   The resolver SHOULD avoid sending queries over different network
   interfaces in parallel as that wastes resources such as power (in the
   case of battery powered and constrained environments).  The wasted
   power can be significant: consider starting multiple radio interfaces
   just for parallel DNS queries.

[Ballot discuss]
1) s4.2 & s4.3: Add that the reserved bits MUST be ignored on receipt.

2) s4.2 & s4.3: Need to specify what to do if the prf value 10 is received.

[Ballot comment]
I agree with Robert and Stepehen's discuss positions.

0) s1: Includes the following:

  The node ought to be able to ask right
  RDNSS for the information it needs.

by "right" you mean the RDNSS that holds the data that's been asked for  even if it's private.  how about:

  The node ought to be able to query the RDNSS that can
  resolve the query regardless of whether the answer comes
  from the public DNS or a privte namespace.

1) s2.2: r/It is worth noting is that/It is worth noting that

2) s3.1: r/instead CPE should send/instead CPE need only send

3) s3.3: r/should be send/need to be sent
  r/network may be used./network may be used for all other traffic.

4) s4.1: I tend to agree with Stephen here.  I think what you want to say is that the specific procedures here are non-normative but an implementation must end up wit h the same result.  Pseudocode would help tremendously.  Avoiding using lowercase may, shall, should, and must would also help.

5) s4.1: When you say precedence are you saying that the higher precedence should cause processing of lower precedence ones to be stopped or is this just about picking the next value to process?

6) s4.1: priority or precedence pick one ;)

7) s4.2: r/should be contacted/can be contacted

8) s4.2: r/MAY then/can then

9) s4.2: r/extent/extend

10) s4.2:

OLD:

In the case of conflicting
RDNSS address is learned from less trusted interface, the node MUST
ignore the option.

NEW:

When a conflicting RDNSS address is learned from less trusted
interface, the node MUST ignore the option.

11) s4.4: Agree with Stephen's discuss #3.

[Ballot discuss]
It's not clear from the discussion of the premise in the introduction if the document intends to cover the case of receiving different answers to queries into a public namespace depending on which interface the query was made over. For example, getting different results, per interface, for queries into e164.arpa will lead to calls using different technologies with potentially radically different security properties. This needs to be clarified throughout the document and at least discussed in the security considerations.

Building on Stephen's first discuss point - the algorithm in 4.1 relies on the interfaces having a ordered "trusted" attribute, but the source of that ordering is unspecified. The text recognizes that this is "implementation and/or node deployment dependent". Won't this also typically be application dependent? How is this specification going to help interoperability (or reliably improve the overall performance of individual nodes) without a more consistent definition of how this ordering is obtained? Is it conflating "trust" with "preference"? As Barry notes, additional discussion of what's actually likely to be used for inputs into this ordering is warranted. For example, if an end user disagrees with the typical trust ordering you call out for a cellular interface in scenario 3.2, should he expect to be able to do anything about it?

This sentence is problematic: "The non-exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic." Please rewrite that without the 2119 keyword, and ensure that the actual normative requirement is well specified.

You call out a problem with local DNS caching for hosts with a single interface that moves between networks, but don't discuss the affects of local caches when this solution is used. Should that discussion be added (at least commenting on whether this solution helps)? Would you change anything in the local cache as interfaces come and go? What do you do with cached results when the preference or trust levels of interfaces change?

Can you add guidance for how an administrator should chose the prf settings to be configured. Right now, it's hard to see why they wouldn't always chose "High". If you don't want deployments doing that, please say what they should be doing instead. An example deployment scenario showing the value of having different prf levels would go a long way.

Is there some discussion of the potential for spoofing the RDNSS (by spoofing its source address) when a client is relying on item 4 of section 4.4 somewhere?

[Ballot comment]
The reader has to make a fairly large leap to understand what "default" and "specific" mean in FIgure 4. Please consider additional introduction to the figure making what those mean more explicit.

Nit: (two occurrences) s/SHOULD NOT extent lifetime/SHOULD NOT extend the lifetime/

[Ballot discuss]

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced that
implementations would all do the same thing based on this description
and with the same input preferences. Is it required that different
implementation's behaviour be the same in that case? If not, then lots
of the 2119 language ought to be omitted. If so, then I think you need
to re-write it more clearly, e.g. using pseudo-code. (Or convince
me this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in a
DHCP response? 4.2 is vague about that, talking about "general
events." Given that DHCP lease times vary enormously I'd have thought
you'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteria
in 4.4 apply, at least as they are stated now. For example, for
criterion 1, how can a piece of code know that a given network
provides a "secure, trusted channel"? There are cases where you can
know, but they're not called out here in a way that can be implemented
it seems. My concern is that implementations will just assume its ok
and then be vulnerable.

(4) section 7, 3rd para: is the MUST there expected to be enforced?  If
so how and by whom?

[Ballot comment]

(This could do with an editorial pass but I'm only going to note
places where a change is more than purely grammatical.)

- Is the title ok? The spec is more about private namespaces but
the title reads as something more generic.

- abstract: s/contact to./contact./ but maybe "use" is better than
contact anyway.

- section 1, 4th para: selection of "route"? do you mean interface?
(Also is "IP connection" right given UDP is most commonly used
for DNS?)

- section 1, 4th para: be good to give some refs to the kinds of tool
you mean in the last sentence. (If possible)

- Acronyms like VLAN, WLAN etc. would be better expanded

- 4.1, 2nd para on p10 says "routes" again, which is probably wrong

- 4.1 mentions "medium priority" but that's not been introduced

- 4.1 says you "MUST" take into account trust levels but those aren't
defined and are left to implementations, so I'm not sure that 2119
MUST is usefuln (see dicsuss point 1 as well)

- The encoding of the domains and networks in figure 5 is a bit
opaque, the reference to 3315 for example is to a section that is 5
lines long and refers to 1035. Would some more descriptive material or
examples help here? I can imagine implementers going wrong here, but
perhaps its ok and the people who'd write code for this would be
fine.

- OPTION_ORO could do with a reference or brief explanation in 4.2
for the less DHCP-literate (like me:-)

- I can't parse this, from 4.5: "In the case of DHCPv4 and DHCPv6
providing conflicting RDNSS selection information on the same
interface, or on the equally trusted interfaces, the node SHALL
firstly prefer DHCP-version possibly securing
OPTION_DNS_SERVER_SELECT, and secondly prefer DHCPv6 over DHCPv4."

- last para of 4.5, would s/may choose to omit/MAY omit/ be better?

- section 7, 2nd para, that MUST is really a SHOULD isn't it?  (There
are exceptions and its not enforceable.)

[Ballot comment]

  Please consider the editorial comments from the Gen-ART Review by
  Christer Holmberg on 5-Jun-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07482.html

[Ballot discuss]
1. The start of section 4.1 simply states that resolvers should use DHCP to determine which RDNSSes are capable of resolving specific domain names and/or addresses. Given that the mechanism for doing such a query via DHCP is defined in this document, I would suggest that the introductory text in 4.1 give a forward pointer to section 4.2 where the mechanism is actually defined.

2. The DHCP option for determining which RDNSSes are capable of resolving certain names and prefixes seems incomplete. How many names/addresses should/can the server return within a single instance of the option?  In what situations would you recommend returning more than one instance of the option, one per RDNSS?  Additional guidance for both implementers and operators would be useful.

[Ballot comment]
1. I support the DISCUSS points raised by Barry and agree that the document needs a complete review by a native English speaking author.

2. The packet layout in Figure 5 puts the option-code name (OPTION_DNS_SERVER_SELECT) in the actual field rather than labeling the field as "option-code".

[Ballot discuss]
-- 4.1 --
   The resolver MUST NOT
   prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

   The RDNSSes of
   untrusted interfaces may be of highest priority only if trusted
   interfaces specifically configure low priority RDNSSes.  The non-
   exhaustive list on figure 4 illustrates how the different trust
   levels of received RDNSS selection information SHOULD influence the
   RDNSS selection logic.

You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one.


-- IANA Considerations --
Perhaps this is clear enough for IANA, but I see registries specified without their proper names, so I worry:

1. It looks like the first option code is meant to go into the "BOOTP Vendor Extensions and DHCP Options" registry in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".

2. It looks like the second option code is meant to go into the "DHCP Option Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".

Please either confirm or correct that and put the *exact* names of the registries in (you can look for them in http://www.iana.org/protocols/ ).  That avoids problems for IANA later.

[Ballot discuss]
-- 4.1 --
   The resolver MUST NOT
   prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

   The RDNSSes of
   untrusted interfaces may be of highest priority only if trusted
   interfaces specifically configure low priority RDNSSes.  The non-
   exhaustive list on figure 4 illustrates how the different trust
   levels of received RDNSS selection information SHOULD influence the
   RDNSS selection logic.

You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one.

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

This comment is short of being a DISCUSS, because the document is generally OK and I think I've understood it.  I have great respect for the work of the non-native-English editors; still, there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing.  I'd like to see the native-English-speaking co-editor (or some other volunteer) go over the document and make sure the articles, tenses, plurals, and commas are right.  There's a lot of fixing needed.

-- 4.1 --
   For security reasons the RDNSS selection information MUST be used
   only when it is safe to do so, see Section 4.4 for details.

This phrasing is easy to misinterpret ("[x] MUST be used").  I suggest casting it more directly:
   For security reasons the RDNSS selection information MUST NOT be
   used unless it is safe to do so, see Section 4.4 for details.

-- 4.1 --
   Trustworthiness of an interface and configuration information
   received over the interface is implementation and/or node deployment
   dependent.

...and, I presume, the specification of that trust model is out of scope for this document.  I suggest you explicitly say that, before you give the (very good) examples:
   Trustworthiness of an interface and configuration information
   received over the interface is implementation and/or node deployment
   dependent, and the details of determining that trust are beyond the
   scope of this specification.  Trust might, for example, be based on the
   nature of the interface: an authenticated and encrypted VPN, or a layer
   2 connection to a trusted home network, might be considered as trusted,
   while an unauthenticated and unencrypted connection to an unknown
   visited network would likely be considered as untrusted.  In some
   situations, an interface might be considered trusted only if it has been
   explicitly configured to be.

I remind you that "shall" is a 2119 keyword (synonymous with "must"), and you should be cautious in using it casually.

   If a DNS response is not proven to be unmolested using
   DNSSEC, then a node cannot make a decision to prefer data from any
   interface with any great assurance: any response could be forged, and
   there is no way to detect the forgery without DNSSEC.

First, this is a convoluted sentence, with too many negatives; second, you're burying the lede.  The important point here is that DNSSEC is necessary, so put it up front:
   DNSSEC is necessary to detect forged responses, and without it any
   DNS response could be forged or altered.  Unless the DNS responses
   have been validated with DNSSEC, a node cannot make a decision to
   prefer data from any interface with any great assurance.

-- Figures 5 and 6 --
   Reserved:      Field reserved for the future. MUST be set to zero.

It would seem to be useful for those future applications if we made sure that implementations didn't barf on receipt of some future value here.  Would this work?:
   Reserved:      Field reserved for the future. MUST be set to zero; MUST
                            be ignored on receipt.

-- Figure 8 --
Does this diagram tell me anything useful?  If so, I can't figure out what.  The only interesting part is in the "black box".

-- 10.2 --
   An implementation may not be able to
   determine trust levels without explicit configuration provided by
   user or administrator.

OK, if you're going to go there, I have to: do you really think there's any serious possibility of user configuration here, especially in the case of a home-network user?  I think that if you mention user configuration, you have to mention that in many, if not most, scenarios, user configuration is not a realistic possibility, and administrator configuration and policy heuristics are usually the only viable mechanisms.


========
Other comments; no need to respond to these. Take them or modify them
as you please:

"timeout" should be one word, not two (but "timed out" is, correctly, two).

-- 4.1 --
   The resolver SHOULD avoid sending queries over different network
   interfaces in parallel as that wastes resources such as energy.  The
   amount of wasted energy can be significant, for example when radio
   interfaces has to be started just for the queries.

Maybe it's just an artifact of where the page break happened, but I wondered what the "energy" thing was until I saw "radio interfaces" (on the next page).  I suggest using "power" rather than "energy", and specifically noting battery-powered and constrained environments.  Perhaps this:
   The resolver SHOULD avoid sending queries over different network
   interfaces in parallel as that wastes resources such as power (in the
   case of battery powered and constrained environments).  The wasted
   power can be significant: consider starting multiple radio interfaces
   just for parallel DNS queries.

IANA has reviewed draft-ietf-mif-dns-server-selection-09 and has the following comments:

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are two IANA actions which must be completed.

First, in the BOOTP Vendor Extensions and DHCP Options subregistry of
the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol
(BOOTP) Parameters registry located at:

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml

a new option code will be registered as follows:

Tag: [ tbd ]
Name: [ see question below ]
Data Length: [ see question below ]
Meaning: DHCPv4 RDNSS Selection option
Reference: [ RFC-to-be ]

IANA Question -> The Options subregistry requires that a short name
for the option be specified. What would the authors like to use for
the short name of this option.

IANA Question -> The Options subregistry requires that a Data Length
be specified for entries in the subregistry. What is the Data Length
for this option?

Second, in the DHCP Option Codes subregistry of the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) registry located at:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml

a new option code will be registered as follows:

Value: [ tbd ]
Description: [ see question below ]
Reference: [ RFC-to-be ]

IANA Question -> RFC 3315 provides a standard for descriptions for
IPv6 DHCP Option Codes. What would the authors like as the description
for the option code requested in this document?

IANA understands that these are the only IANA actions required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Improved Recursive DNS Server Selection for Multi-Interfaced Nodes) to Proposed Standard


The IESG has received a request from the Multiple Interfaces WG (mif) to
consider the following document:
- 'Improved Recursive DNS Server Selection for Multi-Interfaced Nodes'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  A multi-interfaced node is connected to multiple networks, some of
  which may be utilizing private DNS namespaces.  A node commonly
  receives recursive DNS server configuration information from all
  connected networks.  Some of the recursive DNS servers may have
  information about namespaces other servers do not have.  When a
  multi-interfaced node needs to utilize DNS, the node has to choose
  which of the recursive DNS servers to contact to.  This document
  describes DHCPv4 and DHCPv6 options that can be used to configure
  nodes with information required to perform informed recursive DNS
  server selection decisions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mif-dns-server-selection/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mif-dns-server-selection/ballot/


No IPR declarations have been submitted directly on this I-D.  The
following IPR declaration may be related to this I-D:

https://datatracker.ietf.org/ipr/1103/

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
==> Proposed Standard, this document is a normaltive work and request IANA
to assign two new option codes, in the title page header states "Standards Track"

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
==>A multi-interfaced node is connected to multiple networks, some of
  which may be utilizing private DNS namespaces.  A node commonly
  receives DNS server configuration information from all connected
  networks.  Some of the DNS servers may have information about
  namespaces other servers do not have.  When a multi-interfaced node
  needs to utilize DNS, the node has to choose which of the servers to
  contact to.  This document describes DHCPv4 and DHCPv6 options that
  can be used to configure nodes with information required to perform
  informed DNS server selection decisions.

Working Group Summary
  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
==> There is no controversy about this document, but There were fears
    that this document is actually ¡°promoting use of split-brain
    DNS¡±. After discussions the concern was tackled in Section 7
    ¡°Considerations for network administrators¡± with text:
    ¡±Private namespaces MUST be globally unique in order to keep DNS
    unambiguous and henceforth avoiding caching related issues and
    destination selection problems (see Section 2.3).¡±
    Another major area that caused lots of discussion was security
    implications caused by risks related to attacker redirecting some
    DNS queries to bad places. This is addressed in Section 4.4.
    ¡°Limitations on use¡± and in Section 4.1, especially with help
    of DNSSEC.

Document Quality
  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
==> There are two implementations of the protocol, one from
Nokia, the other from NTT. Microsoft also has Name Resolution
Policy Table implementation. There are thorough review, but not
lead to important changes, there is no substntive issues.
There are no MID and Media type definition which need expert review.
Personnel

  Hui Deng is the Document Shepherd, Ralph Drom is the Responsible Area
  Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
==¡· The document has been discussed in the working group which has won
the concenuss to move forward this document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
==> The document has had extensive reviews within the IETF, not just
  MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not have
  any concerns about the depth or breadth of reviews received.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
==> The document has already got review from DNSEXT,DNSOP and DHCWG,
  others are not needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
==> There is no concern or issue on this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
==> There are 3 authors in this document,
Teemu has conformed Nokia's IPR claimed.
Ted has conformed he is not aware of any IPR.
J. Kato from NTT didn't reply anything on this. Need IESG's advice
on how to handle this.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
==> Yes, it has an IPR disclosure before it has been adopted as the
working group document, but there isn't one filed in the datatracker.
working group feel that the terms in that IPR filing is acceptable.
https://datatracker.ietf.org/ipr/1103/

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
==> WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
==> No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
==> the document has passed the ID nits check, no error and warning.

(12) D escribe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
==> This document meets the required criteria, and it doesn't define
a new MIF, media type, and URL type.

(13) Have all references within this document been identified as
either normative or informative?
==> Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
==> No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.
==> No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
==> No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been sug gested (see RFC 5226).
==> Shepherd confirms that the document does request no new registries
  and pointers to existing registries

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
==> the document doesn't request new registeries to existing registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
==> Shepherd think the document is well written in the formal language

Belo are document writeup for draft-ietf-mif-dns-server-selection-08

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

==> Proposed Standard, this document is a normaltive work and request IANA
to assign two new option codes, in the title page header states "Standards Track"

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

==>A multi-interfaced node is connected to multiple networks, some of
  which may be utilizing private DNS namespaces.  A node commonly
  receives DNS server configuration information from all connected
  networks.  Some of the DNS servers may have information about
  namespaces other servers do not have.  When a multi-interfaced node
  needs to utilize DNS, the node has to choose which of the servers to
  contact to.  This document describes DHCPv4 and DHCPv6 options that
  can be used to configure nodes with information required to perform
  informed DNS server selection decisions.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

==> There is no controversy about this document, but There were fears
    that this document is actually “promoting use of split-brain
    DNS”. After discussions the concern was tackled in Section 7
    “Considerations for network administrators” with text:
    ”Private namespaces MUST be globally unique in order to keep DNS
    unambiguous and henceforth avoiding caching related issues and
    destination selection problems (see Section 2.3).”

    Another major area that caused lots of discussion was security
    implications caused by risks related to attacker redirecting some
    DNS queries to bad places. This is addressed in Section 4.4.
    “Limitations on use” and in Section 4.1, especially with help
    of DNSSEC.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

==> There are two implementations of the protocol, one from
Nokia, the other from NTT. Microsoft also has Name Resolution
Policy Table implementation. There are thorough review, but not
lead to important changes, there is no substntive issues.
There are no MID and Media type definition which need expert review.

Personnel

 
  Hui Deng is the Document Shepherd, Ralph Drom is the Responsible Area
  Director


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
==》 The document has been discussed in the working group which has won
the concenuss to move forward this document.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 
==> The document has had extensive reviews within the IETF, not just
  MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not have
  any concerns about the depth or breadth of reviews received.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
==> The document has already got review from DNSEXT,DNSOP and DHCWG,
  others are not needed.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
==> There is no concern or issue on this document.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
==> There are 3 authors in this document,
Teemu has conformed Nokia's IPR claimed.
Ted has conformed he is not aware of any IPR.
J. Kato from NTT didn't reply anything on this. Need IESG's advice
on how to handle this.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
==> Yes, it has an IPR disclosure before it has been adopted as the
working group document, but there isn't one filed in the datatracker.
working group feel that the terms in that IPR filing is acceptable.
https://datatracker.ietf.org/ipr/1103/


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
==> WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
==> No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
==> the document has passed the ID nits check, no error and warning.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
==> This document meets the required criteria, and it doesn't define
a new MIF, media type, and URL type.

(13) Have all references within this document been identified as
either normative or informative?
==> Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
==> No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.
==> No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
==> No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
==> Shepherd confirms that the document does request no new registries
  and pointers to existing registries

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
==> the document doesn't request new registeries to existing registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
==> Shepherd think the document is well written in the formal language