<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_ym19_1_1493042578462_248061"><span id="yui_3_16_0_ym19_1_1493042578462_248060">The next logical question would be: are we able to change anything in the current WHOIS, and if yes, what? Many stakeholders have created a business plan around the current state and usage of WHOIS, entire sectors of the economy, in fact. I believe we need an economic assessment for stakeholders of any potential change to WHOIS. </span></div><div id="yui_3_16_0_ym19_1_1493042578462_248061"> <br></div><div class="signature" id="yui_3_16_0_ym19_1_1493042578462_247952">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 Monday, April 24, 2017 1:26 PM, Paul Keating <Paul@law.es> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div dir="ltr">Andrew,<br clear="none"><br clear="none">Thank you. That was helpful.<br clear="none"><br clear="none">""Given this registrant, what other<br clear="none">domains are registered?" is a solved problem, and has been since the<br clear="none">early 2000s.²<br clear="none"><br clear="none">This is also traceable via alternative means such as consistencies in<br clear="none">various WHOIS fields such as email, address, name, etc.<br clear="none"><br clear="none">Perhaps my comments are off point (and if so I am sorry). I think an<br clear="none">issue here is that some people are looking as the issue as being solvable<br clear="none">with one fell swoop. In reality finding out answers to questions such as<br clear="none">yours (above) requires investigation using a plethora of data. An entire<br clear="none">industry exists for this purpose and I don¹t think we should be<br clear="none">considering replacing what has already been existing in the cyber security<br clear="none">marketplace.<br clear="none"><br clear="none"><br clear="none"><br clear="none">On 4/24/17, 7:14 PM, "Andrew Sullivan" <<a shape="rect" ymailto="mailto:gnso-rds-pdp-wg-bounces@icann.org" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a><br clear="none">on behalf of <a shape="rect" ymailto="mailto:ajs@anvilwalrusden.com" href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a>> wrote:<br clear="none"><br clear="none">>On Mon, Apr 24, 2017 at 12:46:31PM -0400, allison nixon wrote:<br clear="none">>> investigative purposes. The registrant identifier of "C270-LRMS" does<br clear="none">>>yield<br clear="none">>> more than one domain in a search but it's unclear if this means they are<br clear="none">>> all on the same one paying account at the registrar, or if that happens<br clear="none">>>to<br clear="none">>> be a hash of some identifier coincidentally used by multiple different<br clear="none">>> people.<br clear="none">><br clear="none">>No, it isn't unclear at all, though it might be unclear to you.<br clear="none">><br clear="none">>The ROIDs are _Repository_ Object IDentifiers. They're generated by<br clear="none">>the Repository (i.e. the registry), and as Scott has already pointed<br clear="none">>out EPP (which every ICANN contracted party is required to use) says<br clear="none">>they have to be unique. Since nobody seems to be inclined to go and<br clear="none">>read the relevant documentation, I quote it here:<br clear="none">><br clear="none">> Globally unique identifiers can help facilitate object-information<br clear="none">> sharing between repositories. A globally unique identifier MUST be<br clear="none">> assigned to every object when the object is created; the identifier<br clear="none">> MUST be returned to the client as part of any request to retrieve the<br clear="none">> detailed attributes of an object. Specific identifier values are a<br clear="none">> matter of repository policy, but they SHOULD be constructed according<br clear="none">> to the following algorithm:<br clear="none">><br clear="none">> a. Divide the provisioning repository world into a number of object<br clear="none">> repository classes.<br clear="none">><br clear="none">> b. Each repository within a class is assigned an identifier that is<br clear="none">> maintained by IANA.<br clear="none">><br clear="none">> c. Each repository is responsible for assigning a unique local<br clear="none">> identifier for each object within the repository.<br clear="none">><br clear="none">> d. The globally unique identifier is a concatenation of the local<br clear="none">> identifier, followed by a hyphen ("-", ASCII value 0x002D),<br clear="none">> followed by the repository identifier.<br clear="none">><br clear="none">>These identifiers uniquely identify a single object (e.g. a contact or<br clear="none">>a domain name or whatever) within the repository. It is of course<br clear="none">>possible that a registrar creates new contact objects every single<br clear="none">>time they have a contact to manage, but such contact object non-reuse<br clear="none">>presents a burden to the registrar, too, so many will not do this.<br clear="none">><br clear="none">>This is not to say that the problem of someone putting (for example) a<br clear="none">>phony address in a contact object is solved. And none of this<br clear="none">>guarantees a strong mapping from registry object data to actual humans<br clear="none">>in the world (indeed, that's really unlikely: registrars typically do<br clear="none">>not want to use the contact object of a different registrar, even when<br clear="none">>permitted, because it presents intractable data-management problems).<br clear="none">>But at least the problem of, "Given this registrant, what other<br clear="none">>domains are registered?" is a solved problem, and has been since the<br clear="none">>early 2000s.<br clear="none">><br clear="none">>Best regards,<br clear="none">><br clear="none">>A<br clear="none">><br clear="none">>-- <br clear="none">>Andrew Sullivan<br clear="none">><a shape="rect" ymailto="mailto:ajs@anvilwalrusden.com" 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 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 class="yqt3309264346" id="yqtfd58755"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<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></div><br><br></div> </div> </div> </div></div></body></html>