Summary

  • The 29 September revision 03 of the individual EPP DELEG Internet-Draft adds <deleg:rem><deleg:all/></deleg:rem>: a proposed update can remove all DELEG records for the named domain without listing them one by one. It does not remove the domain or its traditional NS records.
  • The same revision changes parameter syntax and the proposed XML namespace. It is an active individual submission, not an RFC or evidence that any registry offers the operation. The operational question is who may authorize a complete DELEG-set removal and how its result would be verified.

There is a material difference between asking a registry to remove two identified records and asking it to empty a whole record set. A list lets a reviewer see the intended targets. An all instruction delegates the final count to the state the server encounters when it executes the command. That difference is the news in draft-brown-epp-deleg-03, not a report of a real deletion.

The draft extends EPP's domain update command for proposed DELEG records. Under section 5.2.2, <deleg:rem> may carry records named for removal or an empty <deleg:all/> element indicating that all the domain's DELEG records should be removed. Its worked example contains an update that removes all such records and adds none. Revision 02 had per-record removal but no all choice. The revised command therefore changes the shape of an operator decision: the client no longer needs to enumerate the DELEG records it expects to find before requesting an empty DELEG set.

The word “all” has a boundary. It means the DELEG extension's records for the domain in that update, not the domain registration, the EPP host objects, every DNSSEC record, or the conventional NS delegation. Section 6 of the proposal explicitly contemplates DELEG alongside traditional NS records. A registry response to the proposed command would not, by itself, prove what every authoritative server published or what recursive resolvers currently have cached. Provisioning state, published DNS state and resolver observation are separate evidence surfaces.

Revision 03 also repairs another part of this evolving model. It replaces the earlier attribute-based deleg:params representation with deleg:param elements and advances the proposed namespace from deleg-0.01 to deleg-0.02. The earlier schema's priority and target fields disappear. BTW previously reported the mismatch between those fields in revision 02 and a newer RDAP proposal. Their removal narrows that specific textual mismatch; it does not establish a deployed migration or a complete EPP-to-DNS-to-RDAP conversion. This article's question is instead the new removal primitive and its authorization boundary.

The security section proposes that servers reject unrecognized parameter names and invalid values, with participants periodically refreshing lists of registered DelegInfoKeys. That may help define accepted data, but a syntactically acceptable command is not an authorization receipt. Nor should a reference to a proposed key registry be read as proof that IANA has opened it: DELEG core revision 11 still requests creation of a Delegation Information registry. These texts describe designs under discussion, not current registry obligations.

The Datatracker records the EPP text as an active individual Internet-Draft with no RFC stream or responsible Area Director and an IESG state of “I-D Exists.” Its 29 September announcement establishes publication of a proposal, not working-group consensus, implementation, adoption or observed damage. The governance consequence is conditional but concrete. If a future server accepts all, the operator should distinguish permission to maintain individual DELEG records from permission to clear the set. Otherwise a routine automation credential could become a bulk-removal credential without a deliberate grant.

Sources