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


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

Home | Date list | Subject list