To:
Edward Lewis <edlewis@arin.net>
cc:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Wed, 26 Mar 2003 18:13:41 -0500
In-Reply-To:
Your message of "Wed, 26 Mar 2003 14:26:30 EST." <a05111b05baa7ad8fff8c@[192.149.252.108]>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] Our "Privacy Issue"
> In this case, "makes a decision on whether to send some data in a > message." Which isn't the same thing as "makes a decision on whether to send any data in a message." Which is why I asked a Yes/No/Mumble question (partial write semantics), since between "none" and "all" lies "mumble". Eventually I suppose that "mumble" will take some greater detail. At least enough to make "mumble enforcement" sensible. Somewhere out there is a manditory to implement (but always optional to deploy) requirement that one end point or the other shave at least one bit (haircut optional for an additional two bits) off of some object. Which bit(s) is tbd, but some sort of mask is a given. I'd like to go on record as wanting the Mask of Zorro, er, Zero. > Part of the problem statement was that we wanted to piecemeal the > privacy metadata to a finer scope. Do you think that that is a bad > idea? I'm certain its a ... IESG idea ... to insist on the syntactic form of metadata, and insist that it be temporally scopeless, and insist that it is the terminal node in a directed acyclic graph (element attribute). Randy's an ex-compiler weenie, he knows what he's proposing. \begin{wicked_serious_mode} It depends on what one is attempting to design. If one is attempting to provision policy data (aka "metadata") in an SRS, and the SRS is not partitioned by metadata, and the data is uncorrolated w.r.t. metadata, then the metadata is sensibly encoded into the data. We did assume that there was correlation when we went for the session scoped <dcp>, thinking that changes in <dcp> would be infrequent, relative to the policied objects, that session encoding of the metadata was sensible, that the value-space of the <dcp> was a lot smaller than the value-space of the <contact> object, and this design choice did not preclude client sourcing of <dcp>, or negociation of <dcp>, or .... Where the "finer is better" approach veers away from reality is in the assertion that no sensible aggregation of stuff is already well-defined in some relevant context. If 95/46/EC is a guide for anything that is remotely related to "privacy", we can expect to find in it an approval of "finer is better". I don't. What I do find is that deconstruction of the data is only part of the problem domain. Deconstruction of the purpose, recipients, temporal existance, originator write-through (aka "access"), and more define the problem domain, and that "fine structure" is less important than policing lumps, and relations between lumps, that when handled with the intent to construct or extract personally identifying information, can. I can live with "design" in the IETF social construct, with PS/DS/SS having a different frame of reference from "design" in the W2C social construct. I tried to "cross over" a gramatical framework, from the W3C to the IETF. It wasn't a success. No matter. I'm spending more time trying to prevent there being two or more core syntaxes than I will spend implementing those few I care about, so I'm way past my ROI, or my sell-by date. \end{wicked_serious_mode} > ... We have to gain operational experience ... With a mechanism with no discernable effect. OK. > I have heard rumors that in some business dealings swirling around > the work done here, there is a need for a "standard." To some that's > an RFC, to others PR, to others DS, and so yet some others Full > Standard or even STD-n. As a chair, I can't deal with what others > call a "standard" all I can deal with is what's in the process > documents. I'm happy with Dork-i-mental, and operational experience. I have very low tastes. Maybe none at all. Cheers, Eric