[gnso-rds-pdp-wg] Some reg'n data I think necessary (was Re: GNSO Next-Gen RDS PDP Working Group teleconference)

Sun Mar 20 23:39:09 UTC 2016

One further point to consider in the context of the informative exchange below.

Whether one likes it or not, whether one wishes it were otherwise or not, the fact is that over the past 20+ years, many people have come to rely on registration data not only to facilitate the functions Andrew outlines below, and not only to support the business operations of the collectors of the data (in the gTLD world,  the registrars), which was the thrust of Holly's original post, but for another purpose:  to access a public record of who has registered which domain name(s), in order to enable (or at least to facilitate) contact with that registrant when issues arise regarding the use of the domain name.

Andrew's observation that third party access to registration data is needed to deal with abuse attributable to particular registrants covers part of this purpose, but not all of it. Over the years, and most recently in the Expert Working Group, ICANN participants have compiled extensive lists of such purposes for which registration data has been used. This "public record" characteristic of the only registration data system that has ever applied to gTLD registrations is an important factor to bear in mind.   It has contributed significantly to transparency in the DNS and ultimately to accountability for how domain names are used.  Of course, those benefits to the public have also been accompanied by costs to the public. Hopefully these can be weighed objectively.

I fully agree that the fact - and it is a fact -- that gTLD registration data has always been a public record does not resolve the question of whether the members of the public who have historically relied on access to this data should continue to enjoy the same level of access to it that they do under the current system.  There may be valid and persuasive reasons for reducing or restricting that level of access in the future--- optimally, in a way that retains the public benefits of the current system while reducing the costs.   But it does suggest that if we move to a system in which the collection of this data is restricted to those elements that serve a foreseen business purpose for the collectors (registrars), then there may be significant costs to the public, which by definition could never, under any circumstances or conditions, enjoy access to data that was never collected.  This certainly should be a factor in deciding whether the public interest is best served by such restrictions on collection.

Steve Metalitz

From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Holly Raiche
Sent: Sunday, March 20, 2016 5:41 PM
To: Andrew Sullivan
Cc: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] Some reg'n data I think necessary (was Re: GNSO Next-Gen RDS PDP Working Group teleconference)

Hi Andrew

A really big thank you for this explanation. It is exactly what I was looking for. Mine was a genuine question - what information is needed and why. And it puts us just where we need to be - what information is exposed - or not.

So thank you for the time, effort and full explanation

Holly
On 21 Mar 2016, at 4:16 am, Andrew Sullivan <ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>> wrote:

> Dear colleagues,
>
> On Sun, Mar 20, 2016 at 09:30:41AM -0500, Carlton Samuels wrote:
>
>> Is there a need for the collection of registration data, and, to
>> what end?
>
> It is important for operators on the Internet to be able to contact
> operators of other domains, in order to deal with abuse, network
> misconfiguration, and so forth. Most obviously, for instance, if a
> domain has some sort of mail loop problem there is literally no way to
> contact the operator of the domain except off-Internet.
>
> Some participants in this discussion appear to believe that we need to
> prove everything from first principles before moving on to practical
> questions. Even if I understand such an impulse, I think it amounts
> to a denial of service on this effort. Therefore, I hereby offer some
> basic assertions, which I make in decreasing order of (my) commitment
> to them. I believe that each of these is relevant to technical
> operations of Internet domains. Accepting even one of these premises
> allows us to cut off (by entailment) any discussion of whether any
> registration data needs to be collected at all, and starts us on a
> discussion of how such data ought to be exposed. (I am leaving aside
> issues of trademark and so on, because quite frankly I think the
> extension of trademark issues into the domain name space was a
> terrible mistake; but I'm sure someone else could come up with a list
> similar to what I offer here while including trademarks. There are
> many lists in the world; this is mine):
>
> * Every domain on the Internet must have name servers in order to
> function. The RDS ought to contain those name servers so that, in the
> event of technical problems, other operators can detect whether there
> is a gap between what the registry contains and what the authoritative
> servers contain.
>
> * Many domans are signed, and in a signed domain that delegates the
> delegation will have a DS record. The RDS ought to contain the DS
> record for the same reason the RDS ought to contain the name servers.
> In signed domains today, this may be even more important than the NS
> records, given the frequency of DNSSEC misconfiguration (but I expect
> this issue to decline over time).
>
> * Every name server has someone responsible for its operation. The RDS
> ought to contain contact information for a given domain or the name
> server or (preferably) both, so that in the event of serious
> malfunction such that interoperation is impossible there is some
> mechanism for out-of-band contact in order to rectify the problem.
>
> * In shared registration systems, it is usually (always?) the case
> that registrations are not single-occasion, but instead are
> registration at a point in time for some term. It is therefore
> necessary, for troubleshooting interoperation, to know when a name's
> registration is expiring and also when it was last updated (to
> troubleshoot recent problems that might be related to changes).
>
> * In any registry using EPP, every domain has an authInfo associated
> with it in order to help authorize transfer requests. This data must
> be collected by the registry (it's part of the protocol. Please don't
> tell me we're going to investigate whether EPP is the correct
> protocol. It's the one we have).
>
> * In gTLDs, most (all? I know there have been exceptions in the past,
> because I made the entries in the relevant database) registrations are
> registered through a registrar. There are two reasons to be able to
> learn the registrar of a name. It is necessary for other Internet
> parties to be able to learn the registrar in order to deal with
> registration problems and other operational problems where the name
> server contact was inadequate. It is necessary for other registrars
> to be able to learn the existing registrar in order to facilitate
> registrant-demanded transfers. (This second reason of course doesn't
> require the appearance in the RDS, but we are talking about why
> registration data needs to be collected in the first place.)
>
> * Every registration is a registration by someone. Some registrations
> are the source of abuse against other networks, and it is sometimes
> necessary to be able to learn the real information about such a
> registrant in order to stop such abuse. Note that this is not an
> argument that such data need automatically be available anonymously
> through an RDS; just that it be collected.
>
> * In gTLDs, most (all? I know there have been exceptions in the past,
> because I made the entries in the relevant database) registrations
> include some cost that accrues to the registrant in exchange for the
> registration. The identities of the parties responsible for keeping
> the data up to date and for paying the registration are required in
> order to ensure continued operation by the same party at the time of
> expiry of a registration term. This ensures the utility of a domain
> name, by making it a useful name for a particular network over time
> (imagine the operational confusion if, when sending email to someone,
> you first had to figure out whether they were at the same domain name
> as yesterday). Note that this is not an argument that such data need
> automatically be available anonymously through an RDS; just that it be
> collected at least by the registrar.
>
>> Let us exercise good common-sensical judgment and resist the temptation to
>> re-invent wheels.
>
> I agree. AFAICT, the above list covers what is normally accessible in
> the whois output of contracted thick registries today, and indicates
> places where anonymous access seems optional.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>

_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160320/dd7cebfa/attachment.html>