[gnso-rds-pdp-wg] Why the thin data is necessary

Tue Jun 6 18:45:35 UTC 2017

+1

Why are we still debating restricting access to thin data?

--
John Bambenek

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