[apps-review] apps-team review of draft-ietf-mif-dns-server-selection

"Murray S. Kucherawy" <msk@cloudmark.com> Wed, 14 September 2011 06:59 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: apps-review@ietfa.amsl.com
Delivered-To: apps-review@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1DDAD21F8B70 for <apps-review@ietfa.amsl.com>; Tue, 13 Sep 2011 23:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103
X-Spam-Status: No, score=-103 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 19JhuSEmZJ5D for <apps-review@ietfa.amsl.com>; Tue, 13 Sep 2011 23:59:15 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5BC3E21F8B54 for <apps-review@ietf.org>; Tue, 13 Sep 2011 23:59:15 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([]) by spite.corp.cloudmark.com ([]) with mapi; Wed, 14 Sep 2011 00:01:23 -0700
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "draft-ietf-mif-dns-server-selection@tools.ietf.org" <draft-ietf-mif-dns-server-selection@tools.ietf.org>, "mif-chairs@tools.ietf.org" <mif-chairs@tools.ietf.org>
Date: Wed, 14 Sep 2011 00:01:22 -0700
Thread-Topic: apps-team review of draft-ietf-mif-dns-server-selection
Thread-Index: AcxyrBw6zVCShQsaRQaFoCi5Am4oqA==
Message-ID: <F5833273385BB34F99288B3648C4F06F13512DFC2A@EXCH-C2.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_"
MIME-Version: 1.0
Cc: "apps-ads@tools.ietf.org" <apps-ads@tools.ietf.org>, "apps-review@ietf.org" <apps-review@ietf.org>
Subject: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Apps Area Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2011 06:59:20 -0000

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-mif-dns-server-selection-03
Title: Improved DNS Server Selection for Multi-Homed Nodes
Reviewer: Murray S. Kucherawy
Review Date: September 13, 2011
IETF Last Call Date: N/A (not yet in IETF Last Call)
IESG Telechat Date: N/A (not scheduled)

Summary: This draft is almost ready for publication as a Standards Track RFC but has a few issues that should be fixed before publication.

NOTE: This is an early review, so please ignore the parts of this boilerplate that sound as though you're in IETF Last Call.  Also, this is a review of the -03 version of the draft.  A new version was published after I had already completed a good part of my review, so I completed it based on this version and not the new one.  I haven't looked at the diffs between the two.

Major Issues:

*         None.

Minor Issues:

*         The IANA Considerations section seems to be a little understated.  I would suggest copying the one from RFC3646 and modifying it accordingly.

*         The use of "domain" in the first paragraph of Section 1 is ambiguous.  The word "domain" is unfortunately overloaded to mean management domain, DNS domain, and probably some others, plus the usual dictionary definition.  I recommend simply saying "a solution for IPv6."  Don't be surprised if a DNS Directorate reviewer complains about this as well.

*         The document in general makes use of the term "DNS suffix".  It could be that I've simply never encountered the term before, but it took me a while of reading to realize this actually meant "domain name".  I would suggest clarifying this up front someplace, or changing it to "domain name" throughout.

*         The last paragraph of Section 2.4 is confusing.  It says "After the interface change[,] a host could have both positive and negative DNS cache entries no longer valid on the new network interface."  Should that "both...and" be "either...or"?  I'm not clear on how a single node can have both positive and negative DNS cache entries no longer valid on the new interface, unless you mean some of its cache will be positive and wrong and some of its cache will be negative and wrong (about different names) after the move.  This should be clarified.

*         I found it strange to read RFC2119 normative language Section 4.1 which describes an internal-use algorithm for collecting and organizing data learned from DHCP and DHCPv6 to build up a set of rules for deciding which nameserver(s) to use for which queries.  The same sort of thing appeared later in Sections 4.5 and 4.6.  My understanding is that, since DHCP and DHCPv6 are the wire protocols used and this section describes an internal-use mechanism, these bits of the text shouldn't include any RFC2119 language; there is nothing here that affects interoperability between two nodes implementing this protocol.  If a node implementing this gets it wrong, it only hurts itself; the wire protocols don't break.  If this section were to be separated into its own document, it would be Informational, not Standards Track.  This isn't a showstopper for me, but I did find it unusual.

*         There are a few places in the document, the Introduction and Section 4.1 for example, that talk about PTR lookup requests matching specific IPv6 prefixes.  However, the abstract mentions IPv4 support, and the mechanism is also described for IPv4.  I suggest making a quick pass through the document to be sure it doesn't appear as if IPv6 is the focus and IPv4 was added in as an after-thought.

*         The normative language in Section 4.1 around DNSSEC seems to be the kind of thing that should be left for local policy.  I can envision environments where the client isn't doing anything sensitive enough to demand DNSSEC, so the first reply it gets from any nameserver it queried is probably fine.  The same sort of thing reappears in Section 4.4.

*         In Section 4.2, the paragraph starting "If the OPTION_DNS_SERVER_SELECT contains..." was a little confusing to read.  It says in general that when learning about DNS servers available, the node can update what it knows but can't forget what it's learned, however it can ignore things it chooses to ignore.  I found this difficult to follow.  Some expansion of this paragraph, perhaps with examples, might help.

*         At the end of Section 4.2, it says "...use of generic DHCPv6 Information Refresh Time Option, as specified in [RFC4242], is envisaged."  That wording is odd; shouldn't it be RECOMMENDED?  It's too vague otherwise.

*         Section 4.4 says a node MUST NOT use the feature being described here unless specifically configured to do so.  That seems odd.  Is the intent to have implementations force this feature off-by-default?

*         I didn't understand this sentence in Section 4.5: "When both options are received from the same network interface ..., the resolver MUST make the decision which one to prefer based on preferences."

*         Section 7 says "To ensure nodes' routing ... works correctly, network administrators should also deploy related technologies for that purpose."  Are there any that can be suggested or referenced here?

*         Appendix A is called "Best Current Practice", but the first section starts out "A possible current practice..."  Where's the best one, and why is it best?


*         There are a few places where I saw RFC2119 words used in non-normative ways, such as the last sentence of Section 3.1 or the middle of Section 7.  I would suggest considering alternate words like "might" in place of "may" specifically to avoid such issues.

*         There's a discussion point at the end of Section 4.1 that asks "What about those DNS servers that instead of a negative answer always return positive reply with an IP address of some captive portal?"  I don't think software implementing this specification can determine that via a DHCP query without other supporting changes to the infrastructure.  I suggest not trying to tackle this point.

*         In Section 4.3, Figure 6, the order of "DNS-recusrive-name-server" and "prf" in the description should be swapped to match the order in which they appear in the diagram.

*         In Section 5, the explanation bullets under Figure 7 include two DHCPv6 replies.  The second one covered "example.com" and a specific IPv6 suffix, but it's not clear that there was no overlap with the first one (i.e., the first one could've said the same thing).  It should be made clear that they had disjoint replies.

*         In several places there are references to "chapters" instead of "sections" or the "section" reference is not capitalized, which xml2rfc does for you.  It seems then these are manual references rather than automatic ones, though the document does claim to have been produced by xml2rfc.   You might make your life easier by changing them to <xref...> tags.

*         Section 10 might be improved by dividing separate topics into their own subsections.  For example, the first three paragraphs could become Section 10.1, and the remaining two could go in 10.2 and 10.3.

*         Appendix A.1 uses the term "hotspot" which is colloquial and might even be trademarked.  I suggest "wireless network".

*         The document is in need of a full edit pass with attention to corrections of English grammar.