Re: Data Collection Requirements

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

Scott,

The current requirement in 8.4 [1] is:

	A generic protocol MUST provide services to identify data
	collection policies.

There is a MUST (manditory to implement) and a how "identify" (annouunce,
communicate, convay, ... and a what "policies".

The proposed change is:

	A generic protocol MUST provide services to identify
	social data use preferences.

There is a MUST (manditory to implement) and a how "identify" (annouunce,
communicate, convay, ... and a what "preferences", with a qualification
that the only data subject to this M2I requirement is "social".

Comment.

The issue was not identified in the IESG comments of 2 July (via Patrik).

Discussion I (scope: data vs social data)

"Social data" is defined [1], and [2] in the context of "thick" and "thin
models of dns name registries. A two-valued taxonomy of data transit and
repository models is not "generic", merely familiar.

In the existing context of [1], if the mechanism is sufficient to identify
the policies (note: not preferences) under which social data was collected,
and the policies for technical data are no more difficult to specify and
implement interoperably than those for social data, no apparent necessity
exists for declining to provide a mechanism to policy technical data.

Example technical data specific use case:

	provision object type == dns name, value == bar,
	in any registry of type dns name,
	except those not blackholing spammers, or unsigned, or ending in
	a stoplist (e.g., repurposed ccTLDs such as ".tv", ".bz" or ".md")

People can substitute their own zone file specific properties for the two
I picked out of my hat. Given the possibility of technical data specific
data collection policy, the necessity for precluding it in a generic protocol
is missing. 

Discussion II (substance: registry vs unknown actor)

Section 7.5 Extensibility [3] reads:

	The protocol MUST provide an optional field within all commands
	whose format and use will be controlled by individual registry
	policy.

The original is consistent with this. The proposed change is not. Registries
are not, under draft-ietf-provreg-grrp-reqs-02.txt, obliged to service those
registration requests which are inconsistent with Registry policy, other than
to generate some form of error response.

Whatever "preferences" are, they are not policies of the registry, and to
sensibly harmonize 7.5 [3] with something that isn't a registry policy, a
change to 7.5 [3] is required, or an additional Extensibility subsection
added which expresses a M2I requirement for all commands whose format and
use will be controlled by the preference and its originator (thing and actor
still TBD).

People can insert their own idea of who might be have a preference, it is
simply necessary that whoever that actor is, it is _incapable_ of binding
the registry to service its request. It isn't the registry, and it isn't
any originating or transit data collector, each of whom is likewise not
obliged to service those registration (transit) requests inconsistent with
their own respective policies, and incidently, fall outside the scope of
draft-ietf-provreg-grrp-reqs-02.txt.

Discussion II (substance: policy vs preference)

Contained in the next section. Sorry, I didn't write this top-to-bottom.

Discussion III (response to motivating comments)

Scott states two questions (which I've modified slightly to make them
symmetric):

	1. is our need to provide a way for a contact to describe the
	data it originates and what use of the data it authorizes 
	2. is our need to provide a way for a registry to describe the
	data it collects and what use of the data it authorizes

Scott suggests we need to solve the former, and not the latter. I differ.

In the P3P model, the problem of expressing user preferences, at least in
a form more general than in a single browser, is via APPEL, a language for
preferences. In the P3P model, the problem of expressing site data collection
practices, at least in a form more general than in a single web site, is via
P3P, a language for expressing data collection practices.

The first question involves a party other than a registry and a registrar
(and a resellers), to wit, a registrant. Therefore it is out of scope for
this requirements draft, and for the associated protocol(s).

The second question (as posed by Scott, and here extended by myself from
"a registry" to "an entity engaged in onward transfer of registrant data,
and a registry") involves only parties in the reseller/registry/registrar
set of entities. This is within the scope for this requirements draft, as
well as the associated protocol(s).

Scott's reading of the requirement I wrote is correct:

> As I read this requirement, it refers to a registry's data collection
> policies.  This is consistent with the way P3P is described by the W3C ("The
> Platform for Privacy Preferences Project (P3P) enables Web sites to express
> their privacy practices in a standard format that can be retrieved
> automatically and interpreted easily by user agents." [P3P]).

We are not however, as Scott continues, applying P3P by substitution, and
attempting to figure out what the Generic Registry Registrar Protocol
requirements would look like if it were a Generic HTTP Protocol requirement.
Rather, we are applying a model of data collection policy announcement to
each of the entities (thick or thin models) involved in onward transfer of
data, which are within the scope of the grrp draft. A P3P derived vocabulary
happens to be the best available tool at the moment that is consistent with
XML as the specification language [4].

This approach was also used in CPExchange version 1.0 [3].

A distinct, and previously mentioned issue is whether there actually is any
requirement for in-band data collection policy announcement. One line of
thought is that privacy has no place in the name (or address) space. Another
is that off-line contract is a sufficient mechanism to enable policy. I'm
sure there are others in addition to these to, and Scott only mentioned the
second of these. However, where interoperable standard mechanism is absent,
there is no possibility of interoperable standard policy. If we don't do the
first, we can't do the second. Maybe the American Bar Association can, or
ICANN, but the IETF simply cannot. Additionally, contract doesn't scale, and
there may be more than seven name registries and seventy name registrars in
the requirements space -- I think there is.

An even longer-winded explanation, neh?

Let's have a discussion of data collection policies and discuss P3P and how
to specify reseller/registrar/registry data collection policies on the agenda
for London.

Eric

References:
[1] draft-ietf-provreg-dn-defn-01.txt, Rader, at lines 167 and 177.
[2] draft-ietf-provreg-grrp-reqs-02.txt, Hollenbeck, at lines 202 and 206,
section 1.1 Definitions, Acronyms, and Abbreviations, and first used
in 3.4.2 Object Registration, lines 482, and subsequently.
and subsequently
[3] http://www.cpexchange.org/standard/cpexchangev1_0F.zip
[4] draft-ietf-provreg-epp-04.txt, at line 38.

[P3P] http://www.w3.org/TR/P3P/#Introduction