Skip to main content

Telechat Review of draft-ietf-dnsop-isp-ip6rdns-06
review-ietf-dnsop-isp-ip6rdns-06-genart-telechat-romascanu-2018-09-14-00

Request Review of draft-ietf-dnsop-isp-ip6rdns
Requested revision 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
I-D 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
Request Telechat review on draft-ietf-dnsop-isp-ip6rdns by General Area Review Team (Gen-ART) Assigned
Reviewed revision 06 (document currently at 07)
Result Ready w/nits
Completed 2018-09-14
review-ietf-dnsop-isp-ip6rdns-06-genart-telechat-romascanu-2018-09-14-00
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?