Paul Wouters has entered the following ballot position for draft-ietf-regext-epp-delete-bcp-09: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the clear description of the problem and the operational and security issues involved. I think this is good work to get a BCP for to reduce harm. Some of my comments I left below, I felt on the border of a DISCUSS or COMMENT. I chose to leave it as COMMENTS. 5.1.3.4. Renaming to Sacrificial Name Server This description does not seem to match the idea of "sacrificial" name server. It is more a dedicated nameserver maintained by the client/registrar. Maybe "Last Resort Name Server" is a better name? The name server MAY provide any valid response. This one is tricky. Of the domain using the host object has other still valid nameservers, it would be better to ServFail. If there are no more other valid nameservers, resolving everything to a dedicated IP running a webserver hosting a message "no valid nameservers for this domain" could be useful. But such a message is harmful if the domain has other still functional nameservers. 5.1.4.2.1.2. Practice Detriments These TLDs are reserved for experimentation or testing. Their use is confusing and does not signal the client's intent. Their use may be prevented by policy. The first two sentences are not correct when ".invalid" is used. The last sentence seems a weak argument. I think ".invalid" would make a good solution here, and I would turn around the last sentence and make this document state that use of .invalid SHOULD NOT be prevented by policy. 5.1.4.3. Renaming to a Special-Use Domain Only after reading 5.1.4.3 do I realise that 5.1.4.2 meant only "invalid." as FQDN when it said ".invalid" and not SLDs inside .invalid. That is not obvious to the reader and I think should be explicitly stated. (Or 5.1.4.3 could be removed with some text moved into 5.1.4.4?) I think adding another name string Special Use Domains should be avoided. There are attempts to stop allowing Special-Use domains entirely, and taking up a "nice name" also takes that name away for real registration in the future. One could instead use something like invalid.arpa or broken-ns.arpa instead? (Oh, I see that is what 5.1.4.4 is doing) I feel Section 5.2 has little to do with IETF and protocols, and is much better handled in other venues? Like ccTLD orgs and/or ICANN ? It is harmless here, but any BCP guidance in this section is not protocol guidance but guidance for the RRR-model. I strongly dislike the term "sacrificial.invalid". Registrants will not have an intuitive grasp for what this means. For example "deleted-ns.invalid" would convey a much clearer signal of what has happened. Furthermore, "sacrificing" implies that this situation is about to change, which is almost never what is described here. It is a lasting change until the registrant or registrar fixes the domain delegation. I am not sure if the document has properly taken into account whether queries in the "sacrifcial name" in the various solutions would be handled and eaten by the Recursive DNS or be forwarded to the root nameservers. This might depend on the name used as well. But for example, my unbound nameserver (and Quad9) seem to synthesis the .invalid response, thus suppressing queries to the root, while Google DNS and Cloudflare seem to return a SOA of the root zone, implying it might have actually sent the query to the root. This might cause quite some load if a popular domain were to end up in such a bad situation. _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
