Registrar Provisioning Impact: Section 3.1 does not specify provisioning protocol

["(personal) Jothan Frakes" <jothan@xxxxxxxxx>]

Hi-

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

Jothan Frakes
jothan at gmail.com

I submit this personally, this is my own opinion and does not
necessarily reflect that of my employer.

http://blog.jothan.com/
http://www.icannwiki.org/Jothan_Frakes