<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1490053846180_45070"><span>+1</span></div><div></div><div id="yui_3_16_0_ym19_1_1490053846180_45072"> </div><div class="signature" id="yui_3_16_0_ym19_1_1490053846180_45074">Nathalie </div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <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 Monday, March 20, 2017 7:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:<br></font></div> <br><br> <div class="y_msg_container">Hi,<br><br>I left the meeting with data protection experts last week feeling<br>quite strongly the need for a specific and concrete purpose for each<br>datum we recommend to collect and to make available; and the need for<br>a definition of who the maximal (appropriate) audience is (given the<br>purpose).<br><br>At the same time, I think that a reasonably short and high-level<br>statement of purpose along the lines that we have been preparing can<br>provide a useful set of principles.<br><br>It strikes me that maybe we could take the high-level purpose<br>statement, and go through some potential data elements and link each<br>one concretely to at least one of the principles in our candidate<br>list. In what follows I name these "purpose 1", "purpose 2", &c. The<br>purposes are numbered according to the scheme in RDS PDP Phase 1: Key<br>Concepts Deliberation –Working Draft-7March2017 (on p7). I'm aware<br>that the details in the candidate list are still in flux, but I think<br>the broad strokes are pretty close anyway, so I thought I'd try it<br>with the "thin" data we agreed to start with. This mail is a little<br>long because I'm dealing with all the classes of elements in one<br>message. I suppose we could break this into one-thread-per-element<br>(or class) if we don't converge quickly on each of them. The outline<br>below is just my view, of course, though obviously I think that what I<br>say is true. I use the "maximal audience" because I think that if<br>there is any "whole public" use then there's no point considering more<br>restrictive uses. (For instance, if we need the domain name to be<br>published to everyone on the Internet because it won't work otherwise,<br>then it makes no difference if LEOs want that data under some sort of<br>authorized-access protocol, because they'll just get it under the<br>wide-open rules instead. So we don't need to care about the LEO<br>purpose in that case.) "Maximal audience" might not work for cases<br>where two different classes have different needs both of which require<br>some restrictions, but it's handy here because we're talking about<br>thin data.<br><br>I'm sorry this is long, but I hope it is a useful contribution to the<br>discussion.<br><br>Best regards,<br><br>A<br><br>---%<---cut here---<br><br>Here is a convenient example thin whois response, in case anyone wants<br>it to for reference in what follows. (Among other things, it reminds me<br>that something I started to do has never been completed, so thank you<br>to this WG for reminding me of that. :-) )<br><br> Domain Name: ANVILWALRUSDEN.COM<br> Registrar: TUCOWS DOMAINS INC.<br> Sponsoring Registrar IANA ID: 69<br> Whois Server: whois.tucows.com<br> Referral URL: <a href="http://www.tucowsdomains.com/" target="_blank">http://www.tucowsdomains.com</a><br> Name Server: NS1.SYSTEMDNS.COM<br> Name Server: NS2.SYSTEMDNS.COM<br> Name Server: NS3.SYSTEMDNS.COM<br> Status: clientTransferProhibited <a href="https://icann.org/epp#clientTransferProhibited" target="_blank">https://icann.org/epp#clientTransferProhibited</a><br> Status: clientUpdateProhibited <a href="https://icann.org/epp#clientUpdateProhibited" target="_blank">https://icann.org/epp#clientUpdateProhibited</a><br> Updated Date: 17-jan-2017<br> Creation Date: 30-jun-2010<br> Expiration Date: 30-jun-2017<br><br><br>1. DOMAIN NAME<br>---------------<br><br>a. Collection<br><br>The domain name is required to be collected under purpose 1. Without<br>this, there is no domain name, so it is literally impossible to have<br>anything to collect or publish.<br><br>b. Publication<br><br>The domain name is required to be published under purpose 1, because<br>it is a key by which data is accessed. If you wish to look up the<br>current data about a particular name, you use the name as the key by<br>which you query. (This is not the only possible key. For instance,<br>in an EPP registry you could in principle use the ROID to look up a<br>particular name object. But that does not give you the current data<br>for the thing so named; it just gives you the data about that<br>Repository Object. Two different versions of the same name -- like if<br>example.com is registered by Alice then deleted and later registered<br>by Bob -- have different ROIDs.)<br><br>c. Maximal audience<br><br>The data audience is Internet-wide under purpose 1 or purpose 2 (or<br>both). The domain name is by definition not private data, because<br>domain names registered in DNS domain name registries (i.e. every<br>registry possibly covered by ICANN policy -- the registries<br>subordinate to the IANA DNS name registries) are name registration in<br>a public name space. Note that it is not possible to keep the<br>existence of a name private, because even if a name were initially<br>undisclosed its existence would be disclosed whenever someone else<br>tried to register it.<br><br>2. REGISTRAR IDENTITY<br>-------------------<br><br>There are four items here, but three classes of data. The (i)<br>registrar ID provides data about the entity that created the entry in<br>the registry (formally, in EPP, "repository"). The (ii) Whois Server<br>and Referral URL both provide metadata necessary for the operation of<br>the distributed database that makes up the RDS (in systems other than<br>whois, approximately the same data with the same relation to identity<br>would be in place, but the details might be different. I think we can<br>treat this as a class anyway). Finally, IANA has a registry of<br>registrar IDs<br>(<a href="https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar-ids-1" target="_blank">https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml#registrar-ids-1</a>),<br>and that contains their (iii) names. This is a protocol parameter<br>registry, but it appears to be managed by ICANN so it is probably<br>appropriate for this PDP to make the policy about how that is to be<br>managed.<br><br>a. Collection<br><br>Data (i) and (ii) are all required to be collected under purposes 1<br>and 2. Without this data it is not possible to know the source of the<br>data and it is not possible to trace it further in the system. Data<br>(iii) needs to be collected in order to give (i) meaning, because it<br>is the only way to know whether two IANA ids are bound to the same<br>organization or person.<br><br>b. Publication<br><br>Data (i) are possibly required to be published under purpose 1. This<br>largely depends on whether we think the identity of who is managing an<br>object in the registry is part of the "lifecycle of a domain name".<br>My feeling is "yes". Also, this information is likely to be disclosed<br>anyway; see below.<br><br>Data (ii) are required to be published under purposes 1 and 2, as long<br>as there is at least one data element that is required under some<br>purpose and is not available from the registry. (Since the actual<br>registration life cycle is controlled by the registrar and not the<br>registry, this appears likely.) Owing to the way these work,<br>publication of these is likely to "leak" information about (i) or<br>(iii) also.<br><br>c. Maximal audience<br><br>Given purposes 2 and 3 and probably 5, and since the source of contact<br>information is registrars, the maximal audience is probably everyone<br>on the Internet. If we think that purposes 2, 3, or 5 are limited in<br>respect of who needs to make such contact or who needs to check<br>accuracy, then the maximal audience is the set of all those who have<br>such a need. It's worth observing, however, that at least the<br>technical contact for a name ought to be contactable by anyone on the<br>Internet, since when we want to "facilitate communication with domain<br>contacts" at least part of the reason is as a fallback when a site<br>breaks in some way. (This may suggest that we need to unpack the<br>details of purpose 3.)<br><br>3. NAME SERVERS<br>---------------<br><br>a. Collection<br><br>Without collecting the name servers, domain names cannot function on<br>the Internet, so this is required under purposes 1 and 2. (Given that<br>the registration of the name itself and the collection of the name<br>servers are both required for the basic functioning of the Internet<br>Domain Name System, it strikes me that we may be missing a more<br>obvious purpose in our list, but I guess (1) and (2) will be enough<br>and we're already so late that I am loathe to suggest something more.)<br><br>b. Publication<br><br>Whenever a name is available on the Internet, the name server data is<br>already available in the DNS, so this data is necessarily published.<br>Under either purpose 1 or 2 (or both), the data about nameservers in<br>the RDS provides an avenue for troubleshooting issues in the DNS, and<br>so it is required for those purposes.<br><br>c. Maximal audience<br><br>Anyone who wants to access a site must be able to find this data in<br>the DNS. Potentially anyone who has a problem with resolution can use<br>the data in the RDS to aid in troubleshooting, so the audience under<br>purpose 1 or 2 (or both) is everyone on the Internet.<br><br>4. STATUS VALUES<br>----------------<br><br>a. Collection<br><br>The status values are not exactly "collected", but are at least in<br>part the result of various actions by the sponsoring registrar and<br>registry on the name. (Some can be set directly.) These govern the<br>disposition of the name in question, and are a necessary condition for<br>having a shared registration system, so they are required under<br>purpose 1.<br><br>b. Publication<br><br>The status values govern the possible things that could be done to a<br>name, and therefore the data must be published under purpose 1.<br><br>c. Maximal audience<br><br>At leasr some status values are required for doing some<br>troubleshooting of resolution failures, so the audience for at least<br>some values under purposes 1 or 2 is "everyone on the Internet". It<br>is possible to argue that some of the status values are relevant only<br>to those people who wish to perform some actions on the domain (such<br>as transferring) or people in a position to do some kinds of activity<br>(such as updating contact information). If we really think it<br>necessary, we could undertake the exercise of audience evaluation for<br>each EPP status.<br><br>5. DATES<br>---------<br><br>While the dates might appear to be different kinds, they aren't, since<br>for our purposes they all have at least one common utility (see<br>below).<br><br>a. Collection<br><br>The dates, like status values, are not exactly "collected": they're a<br>consequence of certain activities. They're necessary for the workings<br>of the shared registration systems using the current fee-for-term<br>model that (approximately?) all gTLD registries use today, so they're<br>required under purpose 1.<br><br>b. Publication<br><br>The dates are required under purpose 1 or 2 in order to aid<br>troubleshooting of resolution. (If a name worked yesterday and not<br>today, it is helpful to know that it was just created -- meaning the<br>old one was deleted -- or that it is expired, or that someone updated<br>the name only last night.)<br><br>c. Maximal audience<br><br>Because of the troubleshooting aspects of these dates, the audience<br>under purpose 1 or 2 is everyone on the Internet.<br><br>-- <br>Andrew Sullivan<br><a ymailto="mailto:ajs@anvilwalrusden.com" href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>_______________________________________________<br>gnso-rds-pdp-wg mailing list<br><a ymailto="mailto:gnso-rds-pdp-wg@icann.org" 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" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br><br></div> </div> </div> </div></div></body></html>