[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-isp-ip6rdns-07: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-isp-ip6rdns-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the well-written document!  I wrote down some thoughts
I had while reading, but they should be treated as very weak suggestions
and no pressure to apply them is implied.

Section 2.1

                                            DNS administrators should
   consider the uses for reverse DNS records and the number of services
   affecting the number of users when evaluating this option.

nit: maybe this could be qualified as "number of services relying on PTR
records", as otherwise it can be read as a bit of a non sequitur.

Section 2.3

   Administrators may want to consider user creativity if they provide
   host names, as described in Section 5.4 "User Creativity."

Perhaps "the risks of user creativity"?

Section 2.3.1

                                    This option may be scalable,
   although registration following an outage may cause significant load,
   and hosts using privacy extensions [RFC4941] may update records
   daily.  [...]

I think I've heard of deployments that update more often than daily, though
it's unclear that there's a need for this document to mention such
possibilities.

Section 4

   There are six common uses for PTR lookups:

I'm a little uncomfortable asserting this as a complete and exhaustive
listing in an Informational document, but I also can't dispute its
veracity.  I'll trust that the authors and WG have done sufficient research
and not request any change here.

                                                 For residential users,
   if these four use cases are important to the ISP, the administrator
   will then need to consider how to provide PTR records.

... but I do have to wonder which four of the six the ISPs are supposed to
be considering.

                        A valid negative response (such as NXDOMAIN) is
   a valid response, if the four cases above are not essential;
   delegation where no name server exists should be avoided.

... and similarly here.

Section 5.1

   Providing location information in PTR records is useful for
   troubleshooting, law enforcement, and geolocation services, but for
   the same reasons can be considered sensitive information.

It may be worth clarifying that the sensitive nature is an argument for not
publishing, since there aren't really well-established schemes for
filtering access to the relevant DNS records.

Section 5.3

Maybe say something about "for use in other protocols" if we're not trying
to limit to DNSKEY and friends?