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

[S Moonesamy <[e-mail]>]

I am forwarding the review performed by  Murray S. Kucherawy:

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

Nits:
·         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.
_______________________________________________
apps-review mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-review