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