Last Call Review of draft-ietf-6man-rdnss-rfc6106bis-14
review-ietf-6man-rdnss-rfc6106bis-14-opsdir-lc-chown-2017-01-10-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document updates RFC6106 with respect to RA options for RDNSS and DNS
Search List configuration. The main change is to increase the default Lifetime
setting to minimise the potential for DNS server settings to expire when not
refreshed by new incoming RAs in lossy networks.

The document is generally well-written, and for clarity has a summary of
changes since RFC6106 in an Appendix. I assume that Appendix will remain in the
published version.

Overall, the document is Ready for publication, with Nits.

A few nit-level comments:

1) p.1 The abstract says:
"This document obsoletes RFC 6106 and allows a higher default value of
   the lifetime of the DNS RA options to avoid the frequent expiry of
   the options on links with a relatively high rate of packet loss.“

It might be better to say:
"This document, which obsoletes RFC 6106, defines a higher default value of
   the lifetime of the DNS RA options to reduce the likelihood of expiry of
   the options on links with a relatively high rate of packet loss.“

(because we are reducing the likelihood, not avoiding it, and defining a
default, not “allowing” it.)

2) There is no analysis of the impact of raising the default, from operational
measurements; it seems the default is being raised a little to make things
better, without a specific rationale. Is there any reason for the specific new
default?

3) Such DNS configuration expiry can still happen through missed RAs, but the
document has no guidance on what a node should do when an RA-based DNS setting
expires due to it not being refreshed. A node may of course have other problems
if it’s not reliably receiving RAs, but it may be useful for example for the
implementation to note whether expiry is happening due to no RA being received,
or because it has received RAs that no longer carry that DNS resolver in the
options list (with note to the removal of the text in 6106 that says "Hosts MAY
send a Router Solicitation to ensure the RDNSS information is fresh before the
interval expires”).

4) The document could emphasise that implementations that are updated to
6106-bis will still interoperate with existing versions; it’s implicit, but not
stated.

5) p.12, Section 7.2, perhaps add a reference to RFC 6105 as well as the
problem statement already there (RFC 6104)?

6) p.13 IANA Considerations. I assume the RC 6106 references are obsoleted now?
 The document can just state the IANA values.

7) p.16 Appendix A - the 4th/5th bullets (starting “The recommendation that…”)
don’t read very well. I find the points hard to parse. Can they be rewritten
more clearly?

Best wishes,
Tim