To:
ietf-provreg@cafax.se
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Fri, 16 Feb 2001 08:51:49 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: grrp-reqs-06, 11. Security Considerations [3]
Eric, The intention of requirement 11-[3] isn't to document that "a mechanism exists to to distinguish technical from social information", it's intended to note that disclosure of non-technical information may be subject to restrictions and the protocol needs to provide a way to identify information that is subject to disclosure restrictions. This was added at the request of Karl Auerbach. I have strong reservations against adding requirements to carry specific policy or jurisdictional identification information because I believe this would add a layer of complexity that we don't need on a per-transaction or per-session basis. For example, data use and data retention are a matter of operational regulatory policy that is enforced by contract in some environments. Perhaps it's not that way in all environments (other opinions, please?), but is it something that needs to be carried around in the protocol when the communicating parties have some sort of legal arrangement in place? I wouldn't object to moving 11-[3] (or a rewording of it) to a new section, though. I just don't want to open a can of worms that will eventually require us to create OIDs or URIs or whatever and associated documentation to describe the policies behind those identifiers. <Scott/> -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Thursday, February 15, 2001 7:51 PM To: shollenbeck@verisign.com Cc: ietf-provreg@cafax.se Subject: grrp-reqs-06, 11. Security Considerations [3] Scott, Elsewhere we've established the division between technical and social information (zone files vs billing files). We can be specific about the minimum necessary data collection and onward-transport policies for technical data. We can be specific about the minimum necessary data collection and onward-transport policies for social data, What your [3] manages is simply to assert a mechanism exists to to distinguish technical from social information. I propose that [3] be removed from Section 11, and a section added with the requirements statements attempted in [3] revised and placed in this new section. 1x. Data Collection Considerations [1] The protocol MUST allow each data transfer to include aggregations of information identifying the parties exchanging data, information about the jurisdiction of each party, and the data collection policies applicable to different pieces of data in the exchange. [2] The protocol MUST allow aggregations of specific policy characteristics that describe how data can be used, how long data can be retained, who may be a recipient of the data, and the data access available to the data's originator. This will allow a "record route" like feature for onward transport after initial information collection, "signed" jurisdictionally and for business practices for technical and social information [1], and This will allow object-specific expression of applicable data collection policies (purpose/recipient/retention/access) [2]. Cheers, Eric