<font color='black' size='2' face='arial'><font size="2" style="color: black; font-family: arial;">Well said, and spot on. +1!</font>
<div style="color: black; font-family: arial;"><font size="2"><br>
</font></div>
<div><font size="2"><font face="arial">Many (most?) of the new gTLD registry agreements require searchable whois and such functionality is restricted to authenticated users. </font>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.") </font><span style="font-size: small;">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. </span></div>
<div><span style="font-size: small;"><br>
</span></div>
<div><span style="font-size: small;">The <a href="https://www.icann.org/public-comments/rdap-profile-2015-12-03-en">public comments page</a> also says "</span><font size="2">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. </font><span style="font-size: small;">Doing so would give implementers something concrete to go on. But unless </span><font size="2">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.</font></div>
<div><br>
</div>
<div>
<div style="color: black; font-family: arial; font-size: 13px; clear: both;">Ann Hammond</div>
<br>
<br>
<div style="color: black; font-family: helvetica, arial; font-size: 10pt;">-----Original Message-----<br>
From: Andrew Sullivan <asullivan@dyn.com><br>
To: gtld-tech <gtld-tech@icann.org><br>
Sent: Wed, Jan 13, 2016 9:27 pm<br>
Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars<br>
<br>
On Wed, Jan 13, 2016 at 05:05:11PM -0800, David Conrad wrote:<br>
> <br>
> a) The proposed operational profile supports the use of tiered access (if, of course, your RDAP server has the code to do it)<br>
<br>
Except that, if you're an operator of this code, you're not allowed to<br>
use that access unless you get a contractual waiver. So, if you're<br>
the development department responsible for this, you have three options:<br>
<br>
1. Get legal involved. I hope I don't need to explain to anyone in<br>
the technical end of ICANN how desirable that is.<br>
<br>
2. Build a piece of functionality and release it in the hopes that<br>
your test code actually covered everything everyone might do.<br>
<br>
2.1. Later, when whatever new profile with the new rules is<br>
released, recall the developers to fix such bugs as show up, with<br>
possibly months or years in between when they implemented the bug<br>
and when they get to fix it. This is all assuming the same<br>
developers are available.<br>
<br>
3. Just ignore the desired functionality until such time as the PDP<br>
(assuming it completes, which at least in this case seems possible)<br>
finishes _and_ the new profile shows up with whatever capabilities<br>
specified, and then implement that.<br>
<br>
(1), of course, is no guarantee that you won't need to do the latter<br>
half of (3) anyway, but let's pretend otherwise. (2) is the sort of<br>
thing that gets you fired as a program manager. (3) amounts to "do it<br>
twice".<br>
<br>
In contrast to all of this is the outline I sent, any variant of which<br>
would allow ICANN to specify now roughly any combination of fields as<br>
falling under some tier of differentiation. This has the conspicuous<br>
advantage that it provides running-code information to the PDP such<br>
that people there know what actually could work or not (a piece of<br>
information that, as nearly as I can tell, could benefit many PDPs).<br>
It simultaneously gives everyone experience with variable operational<br>
profiles before there is any policy requiring correct specification<br>
and implementation, which means that we can run various experiments<br>
and trials against real servers when we hear about things people want<br>
without a lot of deadline pressure.<br>
<br>
But if we're not to take that approach, why should bueinsses ever have<br>
to think about RDAP twice? It creates an implementation burden of a<br>
new protocol for practically no benefit to anyone. If mere<br>
machine-readability of output were the only desideratum, then we've<br>
already run the experiment to find out whether people want that (with<br>
IRIS), and the answer was no. The i18n goals are effectively already<br>
solved via the required web whois. What is the goal of implementing<br>
RDAP quickly without even the capability of differentiated access,<br>
except to check off a tick-box on someone's list of stuff to do? I'm<br>
myself very much in favour of RDAP implementation, but it's awful hard<br>
to justify any effort on this early requirement without any apparent<br>
benefit.<br>
<br>
I can imagine that an interpretation by ICANN that additional<br>
functionality that implemented differentiated access -- functionaliry<br>
not deemed part of the production service, but that is somehow offered<br>
alongside on a best-efforts, experimental basis, and that is not<br>
strictly part of the profile -- would go a long way to eliminating<br>
this objection. It's hard anyway to see how that would be a registry<br>
service as such, since it wouldn't affect any users who didn't want to<br>
play in the sandbox and wouldn't be necessary for anyone. The goal of<br>
early delivery of RDAP with a universal single-tier interface would be<br>
achieved, the PDP would get information probably useful to its work,<br>
and nobody would be inconvenienced since the service wouldn't actually<br>
make any promises. <br>
<br>
Best regards,<br>
<br>
A<br>
<br>
-- <br>
Andrew Sullivan<br>
Dyn<br>
<a href="mailto:asullivan@dyn.com">asullivan@dyn.com</a><br>
</div>
</div>
</font>