<div>Thank you&nbsp;Andrew for your well thought out and presented points. &nbsp;I agree with you, as someone who's worked in the trenches and often needs to track down domain owners to deal with malware, etc. sometimes I have to reach out to the domain owner as a last resort.<br></div><div><br></div><div>-Thanks<br></div><div>Mike</div><div><br></div><blockquote class="protonmail_quote" type="cite"><div>-------- Original Message --------<br></div><div>Subject: [gnso-rds-pdp-wg] Why the thin data is necessary<br></div><div>Local Time: June 6, 2017 1:22 PM<br></div><div>UTC Time: June 6, 2017 6:22 PM<br></div><div>From: ajs@anvilwalrusden.com<br></div><div>To: gnso-rds-pdp-wg@icann.org<br></div><div><br></div><div>Hi,<br></div><div> <br></div><div> On the call today there were arguments being made about why certain<br></div><div> fields should not be publicly accessible.  In effect, what we are now<br></div><div> arguing about, in talking about what should be considered "thin data",<br></div><div> is the definition of the set of data to which unauthenticated access<br></div><div> should be permitted.  (Let us please not get distracted by what is<br></div><div> actually required by the RAA or anything like that just now, since the<br></div><div> outcome of this policy discussion might change that.)<br></div><div> <br></div><div> There were several arguments put forth about whether the created on,<br></div><div> updated on, and expiry dates should be included.  Similarly, people<br></div><div> discussed whether the domain status values should be included.  I<br></div><div> believe they must be.<br></div><div> <br></div><div> The Internet is unlike many other technologies because of its radical<br></div><div> decentralization.  That is not some sort of political choice, but<br></div><div> instead a fundamental part of the design of the Internet: it's a<br></div><div> network of networks (of networks…) formed by voluntary interoperation<br></div><div> among the participants.  Participants in the Internet interoperate<br></div><div> without setting up formal contractual arrangements between all the<br></div><div> participating parties.  This feature is part of what has made the<br></div><div> Internet so successful compared to other telecommunications systems,<br></div><div> because the barrier to entry is really low.  But that design comes at a cost.<br></div><div> <br></div><div> The cost is that there's not always a party to speak to, with whom one<br></div><div> has a pre-existing relationship.  If communications break down between<br></div><div> two telephone customers, they know whom to call: the phone company.<br></div><div> The phone company also has contractual (or sometimes treaty)<br></div><div> relationships to other phone companies.<br></div><div> <br></div><div> The Internet doesn't work that way.  If you and I are communicating<br></div><div> over the Internet, there is no guarantee of direct contractual<br></div><div> relationships all the way along the transit path: that's what open<br></div><div> peering policies ensure.  The way we make this work in fact is by<br></div><div> placing the responsibility for troubleshooting out at the edges.  And<br></div><div> because of that, when I need to troubleshoot my site I need to have<br></div><div> tools with which to do that.<br></div><div> <br></div><div> In domain-based communications (such as email, IP telephony, websites,<br></div><div> money transfer, and thousands of other applications), when I encounter<br></div><div> a problem with the communication I need to answer whether the problem<br></div><div> is in _my_ network operation, or in the other end.  Important data to<br></div><div> rule out "the other end" is in the thin RDS data.<br></div><div> <br></div><div> Obviously, the nameserver and DNSSEC information in the RDS will allow<br></div><div> me to tell whether what is in the global DNS is what ought to be<br></div><div> there.  For instance, if the RDS has one value for the name servers,<br></div><div> but the DNS returns something else, there is a problem.<br></div><div> <br></div><div> Less obvious but just as important are the status values.  If a name<br></div><div> is on Hold or is pendingTransfer or something like that, it can tell<br></div><div> me that something is up.  A name that doesn't appear in the DNS but<br></div><div> has a full complement of name servers in the RDS, for example, might<br></div><div> be on hold; and I can't tell that without seeing the status values.<br></div><div> <br></div><div> In the same way, the dates in the RDS allow a troubleshooter to<br></div><div> understand what might be wrong when things are broken.  If a name is<br></div><div> set to expire in a day and you're getting a parking page on the<br></div><div> website, you have a clue about what is going on.  Most of the examples<br></div><div> cited in<br></div><div> https://whoapi.com/blog/1582/5-all-time-domain-expirations-in-internets-history/<br></div><div> were trivial to understand for help desks that could see that a name<br></div><div> that should have existed for some time was just hours old, because the<br></div><div> created_on date was available.  And if you start having trouble and<br></div><div> see a domain was updated about the same time the trouble started, you<br></div><div> have a pretty good clue that the problem is most likely at the target<br></div><div> domain, and not in your own network.<br></div><div> <br></div><div> As for the question of why the global Internet infrastructure needs to<br></div><div> help with this, the answer is that _that's what the infrastructure is<br></div><div> for_.  We have registrars and registries in order to co-ordinate these<br></div><div> assignments and make those assignments available, in support of the<br></div><div> distributed administration and operation of the Internet.  If the<br></div><div> infrastructure isn't providing this kind of information in order to<br></div><div> help administrators of various Internet administrators, then it isn't<br></div><div> doing its job.<br></div><div> <br></div><div> The Internet is a distributed system.  If you want to make distributed<br></div><div> systems work, you have to allow the operators to have enough<br></div><div> information to do their jobs independently of one another.  So,<br></div><div> regardless of where one lands on whether any of this data is personal<br></div><div> data, it makes no difference.  If you want the domain name system to<br></div><div> continue to work reliably, you have to publish this data.<br></div><div> Centralization and locking the data up for just registrars simply<br></div><div> won't scale.<br></div><div> <br></div><div> Best regards,<br></div><div> <br></div><div> A<br></div><div> <br></div><div> -- <br></div><div> Andrew Sullivan<br></div><div> ajs@anvilwalrusden.com<br></div><div> _______________________________________________<br></div><div> gnso-rds-pdp-wg mailing list<br></div><div> gnso-rds-pdp-wg@icann.org<br></div><div> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<br></div></blockquote><div><br></div>