Pawel,
On the question of whether 5.2.2.4 "Inform Affected Clients" and 5.2.2.5 "Allow
Explicit Delete of Domain with Restore Capability" and the need for new EPP
extensions to support them, below are my thoughts. The difference between the
two options is the object that is deleted (host in 5.2.2.4 and domain name in
5.2.2.5). These options could be combined by allowing the delete of the domain
name with RGP support, but to include notification via Change Poll messages for
the impacted domain names. This cascade update and potential insert of a very
large set of Change Poll messages would be something new in EPP and represents
a scalability issue (e.g., delete of example.com with 20 child hosts and with
10,000 linked domain names). I believe the existing set of EPP RFCs can be
leveraged, but the question is how they are leveraged.
1. 5.2.2.4 "Inform Affected Clients" – The use of the Change Poll Extension
in RFC 8590 could certainly be reused for this purpose. This brings up the
question of whether the domain names are being changed in an EPP sense and the
concern of the number of change poll messages that could be generated.
* For the question, the change to the domain names is a side-effect of
the allowing for the deletion of the host, so should the domain name updated
date and updated identifier be changed as part of the side effect? There was
no domain name command executed, so an argument could be made that the domain
name itself was not modified and the updated date and updated identifier should
not be touched. If no domain name change is made, what would the Change Poll
message look like, where the updated date and the change poll date would not
match? If we considered the cascading de-linkage of the host from a domain
name as an implicit update to the domain name that does change the updated date
and updated identifier, then the Change Poll message would certainly apply.
* Dealing with the number of links from the host to the domain names is
a scalability issue that would need to be addressed for both 5.2.2.4 “Inform
Affected Clients” and 5.2.2.5 “Allow Explicit Delete of Domain with Restore
Capability”, where the de-linkage and the generation of poll messages would
need to be handled asynchronously. In this case, the host delete may need to
result in the use of the pendingDelete status until all the links are removed
and the poll messages are inserted.
2. 5.2.2.5 “Allow Explicit Delete of Domain with Restore Capability” – The
delete of a domain name with child hosts that are delegating name servers and
with restore capability is supported by the RFCs (RFC 5731 and 3915)., but the
disablement, re-enablement, and eventual purging of the links would need to be
handled asynchronously. 5.2.2.4 “Inform Affected Clients” brings up the
question of whether the disablement and re-enablement actions are implicit
updates to the linked domain names and the need for notification via the Change
Poll message.
--
JG
James Gould
Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 2/1/24, 2:44 AM, "regext on behalf of [email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]> on behalf of [email protected]
<mailto:[email protected]>> wrote:
Hi,
I support the adoption.
I think this is the right group to work on this issue, however a close
sync and thorough review by dnsop shall be assured.
One comment/question to the document: my understanding is that it
presents a mix of existing and not yet existing or proposed new
practices for handling of the issue. Chapter 5 is not specific in the
respect which methods are existing and which are proposed. Only chapter
6 makes it more clear, at least for those methods proposed as best practice.
Also, are methods 5.2.2.4. and 5.2.2.5. already covered in the existing
EPP specifications, or new extensions are required to cover them?
Kind Regards,
Pawel
On 29.01.24 16:17, Antoin Verschuren wrote:
> This is the formal adoption request for Best Practices for Deletion of Domain
> and Host Objects in the Extensible Provisioning Protocol (EPP):
>
> https://secure-web.cisco.com/1GHwQtj-dgofSM9mjdF-3jkPplcAI-VMFJNy1P1gjTGTjHuD_IE3RjI1IEuvsaZAHe4gLwV4Qld75mUIrSQj8KbOGhdpA_nkAyPv6xFyhTos0l8ssVtHQvL7IiGpOqdsSuDsJOXRYFFi6T_BQB8tG2_D6Ud0BjJJiVpnp7KRzOSDvvSng6stDMeIWuxVyPYiM6RVOFVyeE45-h5_Ehzb8Jy-cSnU1UCeqKXgOp6IuQqc0-SvN8RnIGk255FRMsErP4XABmmzmduuv21cVKqkrUShHo_0OD5GDHU3cIO5RSjk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hollenbeck-regext-epp-delete-bcp%2F
>
> <https://secure-web.cisco.com/1GHwQtj-dgofSM9mjdF-3jkPplcAI-VMFJNy1P1gjTGTjHuD_IE3RjI1IEuvsaZAHe4gLwV4Qld75mUIrSQj8KbOGhdpA_nkAyPv6xFyhTos0l8ssVtHQvL7IiGpOqdsSuDsJOXRYFFi6T_BQB8tG2_D6Ud0BjJJiVpnp7KRzOSDvvSng6stDMeIWuxVyPYiM6RVOFVyeE45-h5_Ehzb8Jy-cSnU1UCeqKXgOp6IuQqc0-SvN8RnIGk255FRMsErP4XABmmzmduuv21cVKqkrUShHo_0OD5GDHU3cIO5RSjk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hollenbeck-regext-epp-delete-bcp%2F>
>
> Please review this draft to see if you think it is suitable for adoption by
> REGEXT and comment to this message on the list, clearly stating your view.
> Andy Newton already volunteered to be a document shepherd this item will be
> adopted.
>
> This Call For Adoption will close on Monday 12 February.
>
> If there are no objections, the chairs will consider this document adopted.
>
> Thanks,
>
> Your REGEXT co-chairs Jim and Antoin
>
> _______________________________________________
> regext mailing list
> [email protected] <mailto:[email protected]>
> https://secure-web.cisco.com/1gkP4gwKstdgzdmP20eLzVfF3gPaeAUPwuifNS-FWK-zmEyn_f874ecFGn0YQm6qBOevDv3O7w0X1s61iPZsOCwXmIGI0cU0uAmpXt93Dvv2Ac_Uds9-6JNfEi8lkwNl7PRdV-DN4eQSRii2zHyFfSJ05OXkUEuryCu5MmOHlzpf_wviFHjovbhHD7GXbOa4IMK6-OQRMq6BBb74icViGBjIBlzVwhp5xBcYvI67iTJG0QhSKe9U6NtJj6u1uULlk3P6WgJv25NOahwwkVmMj9plfuSar-6JaynFrB-e7Yks/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
> <https://secure-web.cisco.com/1gkP4gwKstdgzdmP20eLzVfF3gPaeAUPwuifNS-FWK-zmEyn_f874ecFGn0YQm6qBOevDv3O7w0X1s61iPZsOCwXmIGI0cU0uAmpXt93Dvv2Ac_Uds9-6JNfEi8lkwNl7PRdV-DN4eQSRii2zHyFfSJ05OXkUEuryCu5MmOHlzpf_wviFHjovbhHD7GXbOa4IMK6-OQRMq6BBb74icViGBjIBlzVwhp5xBcYvI67iTJG0QhSKe9U6NtJj6u1uULlk3P6WgJv25NOahwwkVmMj9plfuSar-6JaynFrB-e7Yks/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
