Joe (and SM to save an extra note),
I'm a little confused by parts of your note as I don't see
anything in IETF's criteria for Internet Standards that should
be affected in any way by what ICANN is doing, what it is
requiring, who is a contracted party or not, whether ICANN
enforces its contractual provisions, etc. Your mentioning them
and their rules in this context brings up memories from a time
long ago when regulators were insisting that only products
supporting certain protocols were allowed to be sold. Many
companies and organizations who had users or customers with no
interest in those protocols responded to those requirements by
creating Implementations that were only good enough to allow the
appropriate box to be marked on a "do you comply with the
regulatory requirement" form. If that occurred with some IETF
protocol, the question for the IETF would be whether that sort
of "check-off" implementation and deployment as part of products
or systems that were primarily supporting something else should
count as deployment for Internet Standard criteria purposes.
However, I had no reason to believe that is going on here,
precisely because ICANN does not appear to be requiring it yet.
Similarly, while I believe you are probably correct about the
principal motivation for RDAP deployment to proceed, neither the
motivation, nor what might happen in the future, appear to me to
be relevant to whether the specifications should advance to
Internet Standard.
And, Subramanian, while I think we should worry, and worry a
good deal, if RDAP is deployed and in use everywhere (or almost
everywhere) but in Africa, the criterion involves deployment;
there is no requirement for deployment everywhere.
I guess the bottom line question is whether the new text
describing the justification for the advancement works for both
of you or if more tweaking is in order.
best,
john
--On Friday, February 19, 2021 13:09 -0500 Joe Abley
<jabley@xxxxxxxxxxx> wrote:
> 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
> <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
