Re: grrp-reqs-06, 11. Security Considerations [3]

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

Scott,

If the remedy is well-defined in whatever legal arrangement exists between
the parties involved, then there is no protocol requirement.

I appreciate that you were attempting to address Karl's concern, but Karl
isn't the sharpest knife in the drawer, and policy without mechanism is
de rigeur in Privacy Advocacy Circles, but [3] doesn't appear to mean any
thing in particular.

How many data collection policy octets per session instantiation is "too
much" overhead?

The whole of the P3P vocabulary we mapped onto cookies is (maximally) 53,
of which 18 may take on 3 possible modifiers, so with all pathological
possibilities left in, the range of distinct values fits in 7 familiar bits.
XMLification can expand that almost infinitely, as it can anything.

How many policy and jurisdictional scope octets per transaction is "too
much" overhead?

As I mentioned, your reaching for OIDs and URI's is unnecessary, the number
of meaningfully distinct statutory and existing business practice data
collection models is very finite, smaller than the number of ICANN accredited
registrars. We already have their identifiers, we're just per-hop (few of
those to boot) picking an index into a well-known array of data collection
statutory and business models. Fits on a small pin, possibly the pointy end,
modulo the subsequent Baroque splendor of XMLification.

> The issue I am trying to address is one of privacy WRT what a registry can
> do with social data. 

Different issue, different section. My problem isn't one of a registry's
access, but of a registrant's authorization. Data originates policied, it
isn't apolicied until a registry (or registrar) makes a grant of policy to
it.

Please also see "purpose", "retention", and "access", in my notes to Jordyn,
your whois example only touches on "recipient", not repurposing, persistence,
or originator modification.

"A registry ... may allow registrants to opt-out", now there's an idea.

The rewording of [3] is different, but it isn't sufficient to prevent any
R-* social information collector from becomming an on-line marketeer, or
from merging off-line data with on-line data.

Well, I've tried twice. As an author of the cpexchange work, which attempts
onward-transport, _exactly_ what provreg is attempting, modulo the nuance
that some data ends up in zone files, and fewer registries exist than CRM
and list manager back ends, and an author of the p3p work, particularly the
namespace-, method-, and state-specific portions of putting policy into the
initial data collection, I'm disapointed.

I'll put out a seperate requirements draft by Friday, which is easier than
iterating on inadequate wording.

Cheers,
Eric