[gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars

Andrew Sullivan asullivan at dyn.com
Thu Jan 14 02:26:29 UTC 2016

On Wed, Jan 13, 2016 at 05:05:11PM -0800, David Conrad wrote:
> a) The proposed operational profile supports the use of tiered access (if, of course, your RDAP server has the code to do it)

Except that, if you're an operator of this code, you're not allowed to
use that access unless you get a contractual waiver.  So, if you're
the development department responsible for this, you have three options:

1.  Get legal involved.  I hope I don't need to explain to anyone in
the technical end of ICANN how desirable that is.

2.  Build a piece of functionality and release it in the hopes that
your test code actually covered everything everyone might do.

    2.1.  Later, when whatever new profile with the new rules is
    released, recall the developers to fix such bugs as show up, with
    possibly months or years in between when they implemented the bug
    and when they get to fix it.  This is all assuming the same
    developers are available.

3.  Just ignore the desired functionality until such time as the PDP
(assuming it completes, which at least in this case seems possible)
finishes _and_ the new profile shows up with whatever capabilities
specified, and then implement that.

(1), of course, is no guarantee that you won't need to do the latter
half of (3) anyway, but let's pretend otherwise.  (2) is the sort of
thing that gets you fired as a program manager.  (3) amounts to "do it

In contrast to all of this is the outline I sent, any variant of which
would allow ICANN to specify now roughly any combination of fields as
falling under some tier of differentiation.  This has the conspicuous
advantage that it provides running-code information to the PDP such
that people there know what actually could work or not (a piece of
information that, as nearly as I can tell, could benefit many PDPs).
It simultaneously gives everyone experience with variable operational
profiles before there is any policy requiring correct specification
and implementation, which means that we can run various experiments
and trials against real servers when we hear about things people want
without a lot of deadline pressure.

But if we're not to take that approach, why should bueinsses ever have
to think about RDAP twice?  It creates an implementation burden of a
new protocol for practically no benefit to anyone.  If mere
machine-readability of output were the only desideratum, then we've
already run the experiment to find out whether people want that (with
IRIS), and the answer was no.  The i18n goals are effectively already
solved via the required web whois.  What is the goal of implementing
RDAP quickly without even the capability of differentiated access,
except to check off a tick-box on someone's list of stuff to do?  I'm
myself very much in favour of RDAP implementation, but it's awful hard
to justify any effort on this early requirement without any apparent

I can imagine that an interpretation by ICANN that additional
functionality that implemented differentiated access -- functionaliry
not deemed part of the production service, but that is somehow offered
alongside on a best-efforts, experimental basis, and that is not
strictly part of the profile -- would go a long way to eliminating
this objection.  It's hard anyway to see how that would be a registry
service as such, since it wouldn't affect any users who didn't want to
play in the sandbox and wouldn't be necessary for anyone.  The goal of
early delivery of RDAP with a universal single-tier interface would be
achieved, the PDP would get information probably useful to its work,
and nobody would be inconvenienced since the service wouldn't actually
make any promises.  

Best regards,


Andrew Sullivan
asullivan at dyn.com

More information about the gtld-tech mailing list