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

[Kathy Kleiman]

Hi Andrew,
Thank you for taking seriously our call for the need to evaluate the 
information currently collected. It is not that some participants need 
to prove everything from first principles, it is that the laws of almost 
half the world require that we do so.  Appreciate your kicking off the 
detailed discussion.

I would ask the "data collectors" - /the Registrars /- to review the 
list you have created. Ultimately, they must evaluate whether the 
information being collected is "adequate, relevant and not excessive" to 
the primary purpose for which it is created.

/The list you have created needs a deeper dive -- into the amount and 
type of data collected, particularly for those fields with personal data. /

There is a special legal question regarding /the amount of personal data 
//being collected. /While every registration (as you point out) "is a 
registration by someone," and at some point we might want to reach 
someone with a position to investigate an allegation of intentional 
abuse or unintentional abuse (e.g., a botnet placed by a malicious third 
party), /what personal information is appropriate and "not excessive" to 
collect?   Do we need the Registrant's //email AND telephone number AND 
fax number AND physical address where that person might live? //
/
Is all of the personal data currently required by the RAA "adequate, 
relevant and not excessive"?

This is the right discussion to be having now and thank you for kicking 
it off.

Best,
Kathy

On 3/20/2016 1:16 PM, Andrew Sullivan 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160320/c37693ba/attachment.html>