Thank you Dan. I have entered a No Objection ballot and requested responses to your comments.
Alissa > On Sep 14, 2018, at 1:29 AM, Dan Romascanu <droma...@gmail.com> wrote: > > 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? > > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
