Re: [Last-Call] Last Call: Advancing the Registration Data Access Protocol (RDAP) to Internet Standard

[Joe Abley <jabley@xxxxxxxxxxx>]

Hi John,

On 19 Feb 2021, at 12:30, John C Klensin <john-ietf@xxxxxxx> wrote:

I think that is possibly ok and thanks for suggesting the text.
I think it would be better if you (or Scott) could add a
sentence or two about _where_ RDAP is deployed and in use.   For
most of the users of the Internet who have heard of either Whois
or RDAP, "Whois" = "DNS lookup". For them, the claim that RDAP
is widely deployed is questionable.  I'd write the sentences,
but I don't have the data.  

I'm not sure I've heard of anybody who thinks that whois means DNS lookup, although if by "DNS lookup" you mean access to a domain registry, then I would say RDAP is, in fact, widely- if not fully-deployed today in that sense.

For example, if it is in wide use in the address registries,
let's say that.

I can't speak to the address registries, but there has been significant deployment in domain registries over the past couple of years, e.g. see <https://deployment.rdap.org>.

I am not current on the contractual requirement to provide RDAP service; the last I heard there some open questions about how SLAs for RDAP services should be formulated and I do not believe those have yet been resolved. However, it seems highly likely that a contractual requirement for RDAP services will emerge for all contracted parties in due course, "contracted parties" being ICANN policy speak, loosely, for accredited gTLD registries and registrars. RDAP addresses a difficult question for ICANN that otherwise does not have an obvious solution.

There have also been questions as to whether in the future whois services might be provided centrally by someone like ICANN in order to preserve the service for the benefit of legacy tools and clients that depend on it, but which itself uses RDAP services provided by registries as a back-end. Whois in effect becomes a proxy for retrieving data from RDAP services without authentication, i.e. public data. So it is possible that whois services will not go away from the perspective of clients who wish to find out information about domains, even at the same time that the contractual obligations on (for example) registry operators are reduced and no longer require individual whois services to be provided.

If it is the actual back end for the web-based
interfaces for a significant number of TLD registries, let's say
that (even if you have to weight "number of TLD registries by
number of registrants to make that true)?

I am not aware that there is any readily-available source of data that would describe the use of RDAP internally, behind web-based interfaces offered by domain registries; it also seems possible that it would be difficult to obtain accurate survey data for that question, given the potential for commercial sensitivities to make it difficult for some parties to answer.

If, when I use the
Whois protocol to access information in those registry
databases, I'm really using a front-end shim over RDAP, say that
too.

Again, I think this is a deployment choice that seems plausible in the abstract, but finding useful data regarding actual, deployed services might be a challenge.

I suspect all of those things may be true but, again, I don't
have the data.   Scott and Andy certainly should (in a more
ideal world, the information would even be in the implementation
report0, so this should be matter or a sentence or three, not a
research project.

I think the principal motivation for RDAP deployment to proceed, aside from contractual obligations, is the increasing understanding that data disclosure for legitimate reasons (e.g. law enforcement with a court order) requires authorisation. Authorisation is not possible within the whois protocol and the practical result is that much of the data that has been published through whois in the past is now routinely redacted, which makes life difficult for law enforcement and is known to hamper legitimate investigations into crime.

Joe

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call