Genart telechat review of draft-ietf-dnsop-isp-ip6rdns-06

[Dan Romascanu <[e-mail]>]

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?