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