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

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

> why do domain/contact/.. not have granular information about privacy?

Asked and answered.

1. Because operationally, policing at the session level is sufficient to
support persistent policing across multiple distinct objects, or support
single-object-session policing.

2. Because syntactically, if epp is to remain extensible, and xml-based,
adding attributes to elements is either pervasive, or specific. As this
WG lost the technical/social distinction with the expiry of Ross' draft,
we don't have a handy hook for being "specific", and "pervasive" makes
conditionally "private" even the data the registrants who have standing
to "privacy" under EU framework UNCONDITIONALLY SEEK TO PUBLISH.

3. Because semantically, it isn't simply contemporanious publication via
954 that is of issue, particularly in the EU, but also in the OEDC, and
potentially even the US. Also required is some mechanism to identify the
repurposing of registrant (and registrar) data, as bulk-access is a real
practice, with abuses. Also required is some mechanism to identify the
availability of collected registrant (and registrar) data for correction.
Also required is some mechanism to identify the duration that data is
held by the collector.

Adding these semantics to complexType elements would be complex, and has
no benefit over attaching the same semantics to aggregations of elements
that are NEVER DISAGGREGATED, aka "objects". There is little observed or
hypothetical inter-object disaggregation of policy that cannot be reasonably,
and scalably met, by bounding sessions by policy discontinuity.

See #1, above.

Ops, syn, sem, all covered.

> In a later discussion with Patrik, I was told that the EPP proposal 
> did not meet the requirement in Section 8.4 of RFC 3375. ("See the 
> MUST part of [1].")

I wrote the requirement. The mechanism is the <dcp>, and it is provided by
the protocol.

The requirement does not state:

  The protocol MUST NOT provide services if data collection policies
  are not identified.

If it had, then we'd have had <dcp> (or some other mechanism(s)) as
MANDITORY-TO-IMPLEMENT, rather than OPTIONAL. There was WG consensus that
the <dcp> is in the core schema (epp-1.0.xsd), optional to implement, and
not an optional extension.


> There are three other inputs. 

> One from Jaap - a look at how privacy concerns with .nl impact the issue.

I sent a public message about the .nl requirement to Jaap not long after
his note on the subject, that the EU residency requirement for registrars
provided a contractual equivalent to a <dcp> element, and a simpler form
(for a hypothetical deployment of epp, as .nl wasn't yet epp-operational)
of whois-token, while sufficient for endpoints within the EU, would not be  
capable of allowing non-EU endpoints to register .nl domains.

He hasn't responded.

> The second is a report and discussion on the .pl work in this area. 

I send a public message about the decision of this particular implementor
not to use the <dcp>.

I seem to have missed the response.

> The third is a message describing the EU perspective on why this must
> be solved.

Oh thank heavens! A live EU national who is a self-described "newbie" and
neither an implementor, nor an operator, nor an author, nor apparently a
specification reader. Now I can stop thinking.

Note Bene Chair:
	1. IESG (Randy or Allison) asked and answered
	2. IESG (Patrick) asked and answered
	3. .NL asked and not responsive
	4. .PL asked and not responsive
	5. Newbie noises

What part of IETF process did I miss in IETF grade school back in the
mid-80s?

I don't actually mind if folks creatively craft into "privacy" some form
of market protection, Europe for the Europeans, Africa for the Africans,
Circumpolar Regions for the Very-Well-Dressed. I simply find it amusing
that on the one hand we've people in the IAB/IESG kicking Chinese Butt
big time for attempting to fix Unicode [1], arguing "minimum astonishment"
as if it were an end-to-end principle, and people with the same, or very
similar drinking buddies, arguing that the semanitcs of "{0,1} are context
dependent.

Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0?

I'm always astonished that packets even make it anywhere.

Eric

[1] Yes Virginia, the new IRTF activity specifically BARS the work by the
Joint Engineering Team (.tw/.cn/.kr/.jp) registries and the Chinese Domain
Name Consortium (.tw/.hk/.ma/.cn) on intermediate mappings in particular,
and constructive mechanism in general. I've asked. Twice. Not for IPR reasons
either.