[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
cc: brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Wed, 08 Aug 2001 08:27:47 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: technical vs social and address registries (was Re: data collection)

In my response to Scott on the two changes he proposed, I pointed out that
reducing the scope of data collection policy (preference in Scott's note)
from "data" to "social data" didn't allow data collection policy rules to
apply to technical data, where some data collection practices variation in
fact does occur (see the SIG and NXT vs NO discussions in the dnssec list,
I used a less esoteric example in my earlier note).

I also pointed out that absent a significantly greater degree of difficulty,
there was no compelling reason to make a distinction and limit the scope of
the proposed mechanism (a p3p-esque XML vocab).

An additional difficulty came to mind when discussing the issue of where
persistent state (thick vs thin) is held in the address registry model(s),
and what is "technical data". My thanks to Joao and Melissa for their time.

Address registries perform reverse mappings, so they and name registries
share the "zone vs non-zone" distinction of data use. However, address
registries view other data as technical operational data, unlike name
registries which view all other data as non-technical (e.g., billing) data.

Given this additional information (generic requirement), limiting the data
collection policy announcement mechanism (p3p-esque XML phrases) to a name
registry specific partition of data appears wrong.

Eric

Home | Date list | Subject list