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? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
