Re: [ietf-provreg] FYI: EPP implementation by the Polish registry

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

The distinction between "social" (billing) and "technical" (zone files)
is not quite the same as between registrar-retained-authoritative (RRP)
and registry-retained-authoritative (EPP). If we're going to create two
(or more) baskets to put data into, which would allow some alternate to
the session-scoped <dcp> that has basket-of-stuff-scope, then we need
to define the baskets, but without dependency upon the distinction of
RRP vs EPP, and "thin" vs "thick" registry models.

Humor me. In a "pure thin EPP", there'd be no whois:43 issue for the 
protocol, the registry would never see anything but NS and A records.
That liability would remain with the registrars and their whois servers.
In a "pure thick EPP" (what we're writing), there is data that is
published via 1034/35 (NS and A records), and data that is published
via 954 (everything, including personally identifying registrant data).
We can't define a distinction in a "pure thick EPP" specification by
making direct, or indirect reference or comparison to the RRP model.
At least, not without something like a dangling pointer.

I've used "pure" in the para above because some registrars are also
registries, though not necessarily of the same namespaces, and I want
to ignore the complication of a registrar who is a whois operator (RRP)
as well as a registry operator, and a registrar who is not a whois
operator (EPP) as well as a registry operator that is a whois operator.
That kind of stuff gets me dizzy.

So, if we say publication via 1034/35, of A and NS records (we're domain
name specific, at least momentarily, and "privacy/data collection" may
not mean the same thing, or anything, in an address registry context, or
other possible SRS contexts), _is_ technical data, and everything else
isn't (which is almost what we had), then we may have a useful definition.

It may help (or I may be going out unnecessarily on a limb) if we make
the distinction between non-technical data and data that is sufficient
to construct persistent unique identifiers. If it helps, in the 95/46/EC
context, the 32 bits of an ipv4 endpoint identifer is subject to data
collection disclosure, hence the (IMO lame) definition in P3P of a 25 bit
addr as something other than "personally identifying" (a unique endpoint
identifier, or one that can be resonably constructed from the collected
data).

Names, telnos, postals, ips fit into this. Admin and Tech contacts don't.

Mind, the simpler course is to stay with a session-scoped policy dingus,
and not dive into what data means what when and to whom. It may not seem
like it, but I'm a big fan of _simple_.

<dcp> manditory.

Eric