<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div>Thanks Andrew </div><div><br></div><div>Chuck</div><div><br></div><div><br></div><div><br></div><div id="composer_signature"><div style="font-size:85%;color:#575757" dir="auto">Sent from my Verizon, Samsung Galaxy smartphone</div></div><div><br></div><div style="font-size:100%;color:#000000"><!-- originalMessage --><div>-------- Original message --------</div><div>From: Andrew Sullivan <ajs@anvilwalrusden.com> </div><div>Date: 7/13/17 11:17 AM (GMT-08:00) </div><div>To: gnso-rds-pdp-wg@icann.org </div><div>Subject: [gnso-rds-pdp-wg] The latest poll, the elements,
and keeping topics separated </div><div><br></div></div>Dear colleagues,<br><br>I have answered this week's poll to the best of my ability, but I am<br>concerned that the approach is making some assumptions with which I am<br>generally uncomfortable. Because of that, and because I was not able<br>to make the meeting in Johannesburg and because there's some risk I'll<br>miss next week's meeting (it's IETF week), I thought I'd send some<br>remarks to the list. I think this is a good start, but I have two<br>substantive concerns.<br><br>Before turning to them, I really like the apprach of first getting out<br>all the stuff on the table (I'm saying "stuff" and not "data elements"<br>for a reason which will be clear below) and then stating whether those<br>things are to be disclosed and under what circumstances. I also think<br>it is worthwhile noting any items that we have been discussing that<br>ought to be discarded because they should never be collected. (I find<br>the discussion of something that ought to be collected and not stored<br>mystifying -- why would anyone do this?) So, I think the basic<br>approach is right.<br><br>I am, however, a little concerned about the way we are focussing on<br>particular "data elements". This shows up in particular in the<br>different granular details about the contacts: all the different kinds<br>of contact, social media things, &c &c.<br><br>I fear what is happening is that we are failing to work at the right<br>level of abstraction. The question about contact information, for<br>instance, needs to be answered as a generic question. If it is ok to<br>collect contact information about registrants, for instance, then I<br>think the details of _which_ kind of contact info -- Skype contact?<br>Facebook page? Carrier Pigeon co-ordinates (or, equivalently, fax<br>number)? Postal address? -- is an implementation issue, and not a<br>policy problem. A few years ago, Slack didn't exist, and now XMPP is<br>a dying technology: should we have to have a new PDP every time some<br>new communications technology passes out of wide use or becomes widely<br>deployed and convenient?<br><br>Similarly, the status values from "server" and "client" are already<br>properties of the data object (EPP distinguishes between server-set<br>and client-set status values), so this isn't a new thing at all. But<br>that brings me to my second worry, which has to do with the way some<br>policy positions have major implications for underlying protocols in<br>the way that others do not.<br><br>For instance, the history of a given name (as opposed to a name<br>object) is not actually a first-class part of the underlying protocol<br>data model of EPP today. EPP works on repository objects, and a<br>domain object has a name, but that is not the primary identifier of<br>the name. Instead, the primary key is in effect the ROID of the name,<br>and you distinguish between two names that are named the same but were<br>created at different times by the ROID (since the ROID will remain<br>constant through the lifetime of the domain). At least some<br>registries probably do not have the history of every name in the<br>registry, because the creation happened before the current operator<br>was the operator, and that history is not part of the protocol<br>definition. Therefore, we need to distinguish policy desires that are<br>inconsistent with existing protocols or technical deployments if we're<br>going to propose policies that require such changes, and we need to<br>analyse what utility arises from a given desired element in the event<br>that the element is necessarily sometimes wrong. It is bad policy to<br>create elements that are likely to be the source of bad policy.<br><br>I hope these observations are useful, particularly if I can't make the<br>meeting next week.<br><br>Best regards,<br><br>A<br><br>-- <br>Andrew Sullivan<br>ajs@anvilwalrusden.com<br>_______________________________________________<br>gnso-rds-pdp-wg mailing list<br>gnso-rds-pdp-wg@icann.org<br>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<br></body></html>