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