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

[Dotzero]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170606/2d819951/attachment-0001.html>