Reviewer: Dan Romascanu Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-isp-ip6rdns-06 Reviewer: Dan Romascanu Review Date: 2018-09-14 IETF LC End Date: 2018-09-25 IESG Telechat date: 2018-09-27 Summary: This is a very well-written document, useful for operators at ISPs who deploy and run DNS on IPv6 including name and address admins, and to their customers. The document is ready from a Gen-ART perspective. I have added a few editorial comments, addressing them may improve clarity. Major issues: Minor issues: Nits/editorial comments: 1. There are many abbreviations that are not expanded at first occurrence (PTR, SLAAC, SSH, etc.) and this makes the reading of the document somehow difficult. Even when references are provided, expanding abbreviations helps. 2. Section 2.3: > UDP is allowed per [RFC2136] so transmission control is not assured, though the host should expect an ERROR or NOERROR message from the server [RFC2136] No need to refer twice the same document in one sentence. 3. Also in 2.3: > Administrators should consider what domain will contain the records, and who will provide the names. If subscribers provide hostnames, they may provide inappropriate strings. Consider "ihate.example.com" or "badword.customer.example.com" or "celebrityname.committed.illegal.acts.example.com." This paragraph seems to belong or at least be pointed to the Security and Privacy Considerations Section. It does not really deal with operational or scalability issues as the rest of the surrounding material. Also the same considerations apply also to Section 3, and are not mentioned there. One more argument to group them in the Security and Privacy Considerations section. 4. Section 2.3.2 It would be good to mention that residential gateways (which usually fall under the customer responsibility) need to be capable and configured for Dynamic DNS. 5. Section 4: > Accepting SSH connections: The presence of a PTR may be inferred to mean "This host has an administrator with enough clue to set up forward and reverse DNS." This is a poor inference. I am not sure what the last sentence tries to say for readers of the document. Does it mean it's a not recommended use of PTR records? (if I am correct) Is this really the place for such a statement? 6. Having two sections, one for 'Security and Privacy Considerations' and another just for 'Privacy Considerations' seems somehow odd. Why not two separate sections (one for Security, the other for Privacy) or one section for both?
