[gnso-rds-pdp-wg] The latest poll, the elements, and keeping topics separated

[Andrew Sullivan]

Dear colleagues,

I have answered this week's poll to the best of my ability, but I am
concerned that the approach is making some assumptions with which I am
generally uncomfortable.  Because of that, and because I was not able
to make the meeting in Johannesburg and because there's some risk I'll
miss next week's meeting (it's IETF week), I thought I'd send some
remarks to the list.  I think this is a good start, but I have two
substantive concerns.

Before turning to them, I really like the apprach of first getting out
all the stuff on the table (I'm saying "stuff" and not "data elements"
for a reason which will be clear below) and then stating whether those
things are to be disclosed and under what circumstances.  I also think
it is worthwhile noting any items that we have been discussing that
ought to be discarded because they should never be collected.  (I find
the discussion of something that ought to be collected and not stored
mystifying -- why would anyone do this?)  So, I think the basic
approach is right.

I am, however, a little concerned about the way we are focussing on
particular "data elements".  This shows up in particular in the
different granular details about the contacts: all the different kinds
of contact, social media things, &c &c.

I fear what is happening is that we are failing to work at the right
level of abstraction.  The question about contact information, for
instance, needs to be answered as a generic question.  If it is ok to
collect contact information about registrants, for instance, then I
think the details of _which_ kind of contact info -- Skype contact?
Facebook page?  Carrier Pigeon co-ordinates (or, equivalently, fax
number)?  Postal address? -- is an implementation issue, and not a
policy problem.  A few years ago, Slack didn't exist, and now XMPP is
a dying technology: should we have to have a new PDP every time some
new communications technology passes out of wide use or becomes widely
deployed and convenient?

Similarly, the status values from "server" and "client" are already
properties of the data object (EPP distinguishes between server-set
and client-set status values), so this isn't a new thing at all.  But
that brings me to my second worry, which has to do with the way some
policy positions have major implications for underlying protocols in
the way that others do not.

For instance, the history of a given name (as opposed to a name
object) is not actually a first-class part of the underlying protocol
data model of EPP today.  EPP works on repository objects, and a
domain object has a name, but that is not the primary identifier of
the name.  Instead, the primary key is in effect the ROID of the name,
and you distinguish between two names that are named the same but were
created at different times by the ROID (since the ROID will remain
constant through the lifetime of the domain).  At least some
registries probably do not have the history of every name in the
registry, because the creation happened before the current operator
was the operator, and that history is not part of the protocol
definition.  Therefore, we need to distinguish policy desires that are
inconsistent with existing protocols or technical deployments if we're
going to propose policies that require such changes, and we need to
analyse what utility arises from a given desired element in the event
that the element is necessarily sometimes wrong.  It is bad policy to
create elements that are likely to be the source of bad policy.

I hope these observations are useful, particularly if I can't make the
meeting next week.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com