Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-epp-delete-bcp-10

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.

Thank you to Linda Dunbar for the GENART review.

IDnits reports:
  -- Obsolete informational reference (is this intentional?): RFC 8499
     (Obsoleted by RFC 9499)

Thanks for the work done in this document (and thanks to Ralf Weber for the DNS directorate reviews). Nevertheless I have some non-blocking comments.

The most important one is about the publication status of BCP (the WG was also not unanimous based on the shepherd's write-up). The document enumerates and evaluates several practices and for some of them adds `This practice MUST NOT be used`, which is rather unusual for a BCP even if the title rightfully says "Best practices" (plural form). I have more trouble with `6. Recommendations` followed by `EPP servers and clients MUST implement one of the following practices` should the "MUST" rather be a "RECOMMENDED" (of course changing the sentence structure)? All in all, an intended status of "PS" or "informational" would be more appropriate.

Minor nit: let's move the URL in the informative reference rather than inserting it in-line in the section.

Why are they only SHOULDs in Section 5.1.3.4?  Why not MUST?  Under what circumstances might an implementer or operator legitimately do something other than what it says here?