Telechat Review of draft-ietf-dnsop-isp-ip6rdns-06

Request Review of draft-ietf-dnsop-isp-ip6rdns
Requested rev. no specific revision (document currently at 07)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-09-25
Requested 2018-09-11
Authors Lee Howard
Draft last updated 2018-09-14
Completed reviews Secdir Telechat review of -06 by Derek Atkins (diff)
Genart Telechat review of -06 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-dnsop-isp-ip6rdns-06-genart-telechat-romascanu-2018-09-14
Reviewed rev. 06 (document currently at 07)
Review result Ready with Nits
Review completed: 2018-09-14


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


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


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 ""
   or "" or

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?