Re: [Gen-art] Genart telechat review of draft-ietf-dnsop-isp-ip6rdns-06

[Alissa Cooper <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art