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

[luvingnc at aol.com]

Well said, and spot on.  +1!


Many (most?) of the new gTLD registry agreements require searchable whois and such functionality is restricted to authenticated users.  The RDAP profile even mentions this in 2.1 ("Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities.") Yet - though your proposal is mentioned - the public comments page glosses over the need for authentication saying "ICANN notes that for the three gTLDs that have differentiated access in their registry agreements, there are, at least two models."  Three gTLDs?  No, anyone offering searchable whois is required to do so only to authenticated users.  


The public comments page also says "The proposal indicated that differentiated access as described should be implemented by all, but not enabled until a contract change or a consensus policy on the subject had been put in place."  Without putting words in your mouth, I don't think it said exactly that.  Instead, the proposal suggested specifying three tiers in the existing RDAP profile, with varying responses, and defaulting to "authenticated-full" (i.e., unauthenticated users get authenticated responses) until ICANN policy changes.  Doing so would give implementers something concrete to go on.  But unless the community agrees (or ICANN dictates) how this is to be done, attempts to do so now run the significant risk of requiring potentially significant rework when an authentication/authorization profile is handed down.



Ann Hammond



-----Original Message-----
From: Andrew Sullivan <asullivan at dyn.com>
To: gtld-tech <gtld-tech at icann.org>
Sent: Wed, Jan 13, 2016 9:27 pm
Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars

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
twice".

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
benefit.

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,

A

-- 
Andrew Sullivan
Dyn
asullivan at dyn.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160113/f68f5f43/attachment.html>