Registrar Provisioning Impact: Section 3.1 does not specify provisioning protocol
I have put some review to the registry failover plan, and have a comment from the registrar and consumer perspective that I'd suggest somehow be incorporated, or if someone could point me towards where I might be missing where the point I am raising is reasonably addressed, I would be grateful.
First, though, I wanted to commend ICANN staff and the many contributors on doing what looks like a quite comprehensive effort of identifying many of the key aspects of a failover plan, and their attention towards preservation of stability for the namespace represented within a TLD.
This said, I reviewed the plan from the perspective of what the experience would be like from a impacts to a registrar, and then in turn the registrants that those registrars serve.
The key point which came to mind for me as I reviewed section 3, is that there is not a specific mention of where the provisioning protocols and transports to be used by the gaining registry operator should remain consistent with the protocols and transports used by the losing registry.
Underlying changes to the transport can range from trivial to significant for a registrar to re-implement a registry connection.
Changes to the protocol, formatting, error/success responses, etc, that can represent a fair amount of programming or re-programming on behalf of the registrar.
Multiply this issue by the growing number of accredited registrars, and it creates a large issue.
Any impact to a registrar's ability to provision (add, modify, transfer, renew, etc.) domain names is vital to their ability to service their registrants, so for all of the examples below, one could multiply the impact to a registrant's ability to manage a domain in a failover TLD.
Wherever possible, I strongly recommend that the gaining registry be required to create programmatic normalization of any provisioning protocol or transport differences, so that the failover not burden all registrars with the need to have to reprogram their connections in order to continue supporting their registrants.
In addition to the protocol and transport aspects, the requirement to re-certify through an operational test after establishing encrypted connections in and of itself is non-trivial for a registrar.
There should be some clearly defined, expedited certification process that allows registrars to be quickly connected and operational to minimize the time in transition from losing registry operator to gaining registry operator.
While the provisioning is mentioned within the gTLD registry agreement, the programmatic aspects of the specific integrations and business rules are more typically provided in more detail in correspondence between the registry and the registrar.
It should be a requirement that the losing registry provide all technical documentation and specifications, which typically would be distributed to their registrars, to the gaining registry, along with any source code typically provided to registrars for the purposes of integration, so that this can also be supported.
My belief is that in setting these requirements of the losing registry and gaining registry, that the registrars and in turn their many thousands, tens of thousands, or millions of registrants that they serve can have the least disruption to business as usual in this digital economy.
Thank you to your attention to this, and I again commend these proactive efforts by ICANN and contributors to ensure the continued security and stability.
Jothan Frakes jothan at gmail.com
I submit this personally, this is my own opinion and does not necessarily reflect that of my employer.