I don't recall them saying we need a purpose for every data element but I think they said we need a purpose for collection and a different purpose for public access, etc. I could be wrong. We do need to clarify. Chuck Sent from my iPhone
On Mar 21, 2017, at 2:53 PM, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com> wrote:
Hi,
On Tue, Mar 21, 2017 at 06:06:07PM +0000, Gomes, Chuck wrote: Do you think that we need to develop a purpose for every data element in the RDS or would it suffice to develop a purpose for collection of RDS data elements, a purpose for public display of RDS data elements and a purpose for gated access to RDS data elements?
The experts last week suggested that each element needs to be evaluated. I fear the size of that rat-hole, however, and wonder whether it might not be enough to use classes.
If we considered data elements by class, what would you suggest are the classes?
Well, I suggested some here for the thin data. These turn out to be simple cases because they're all pretty much necessarily public for the functioning of the system at all (that is, if one is going to argue that one of the thin elements ought to be private, one is in effect arguing that we should not have an RDS. That's ok, but it's a different argument.)
For the other data, we have several different classes of contact information: the identity of the contact in question, the street address, phone number, and email address, and fax numbers (because everyone is using 1980s tech for communications now ;-) ). This contact info seems to me to be one dimension of the issues. The second dimension is the purpose of the contact itself: what is that contact information for? The purpose of the technical contact, for instance, is bound to be different from the admin or registrant contact data. So, I would propose first going through the contact data with the purpose-of-having-that-contact filter. Then we could discuss the disclosure of the different items I mention above.
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg