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


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

Home | Date list | Subject list