Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
draft-ietf-mif-dns-server-selection-12

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.

Thanks for addressing my DISCUSS points.

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?)

Support Brian's DISCUSS. Please consider rewriting this document. I found it very difficult to parse.

  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

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.

Thanks for taking my discuss points into account.