Subject: RE: opt-in and consensus

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 5 Apr 2003 06:05:03 -0800

> The opt-in issue has to some extent polarized the working group into 
> folks that are "for" opt-in and folks that are "against" opt-in. 

I don't see evidence for that assertion, quite the reverse. The 
clear majority of posts were in favor of opt-in. There were only 
two posts I saw outright opposed and three that said they did
not think opt-in was a good idea but would stand aside to let
us get on to the real problems of deployment. One comment agreed
with someone else without expressing a pro/anti view.

I don't think that anyone expects there to be unanimous approval
here, although I will not be surprised if some try to insist on
that as the criteria. 

There once was a principle at the IETF about complexity, complexity
is often impossible to eliminate from a protocol but you can choose
where you put it. The original concept of 'end-to-end' was that
you avoided concentrations of complexity and processing in favor
of decentralization. I find it interesting that we now have the
reverse of that argument, somehow Moore's law will provide and we
can make do with a bad design that creates a concentration of
processing costs at a few nodes rather than risk a minor variation
in end-point processing.

Somewhere out there there is a world of eight billion people. 
Someday all those people are going to be using the Internet. It
is unlikely that protocols whose design depends on salvation by
Moore's law will survive to that day.

		Phill

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 05 Apr 2003 10:24:44 -0500

("against" opt-in) ++

of course, another form of expression is that i think there is some possible
mechanisms that arise from policies that incorporate "informed prior consent"
into the requirements statement, which are not available if "ipc" is not a
requirement.

this may come as a surprise to phill, though not to ed. the provreg wg and
the iesg, in my own personal view, are divided by this very question, and
a non-trivial potential motivation for both camps there is the rasion d'etre
for this irtf tf -- spam (via whois:43 server data mining).

can the properties of data collectors be usefully characterized? there exists
at least one such attempt.

can the provisioning of end-point identifiers and other information which
tends to identify individuals, as well as other categories for which some
policies exist, be mediated by mechanisms which evaluate grammers which
characterize data collection practices? there exists several implementations
for at lesat one such grammer.

can collector evaluation mechanisms mitigate any part of this tf's problem
space? this is unknown.

it is worth keeping in mind that mechanisms which rely upon recipient or
relay properties, e.g., "consent", "content", "dnsbl", ... do not exhaust
the mechanism-space.

i mentioned that another approach exists, but that it seems to me to be
inaccessible to the ietf, and not from ipr reasons.

\begin{note-to-chair-hat-on}

it might be useful to split this shouting match into working groups.
the din is attrocious, the posturing rediculous, and the disincentive
to work tremendous.

\end{note-to-chair-hat-on}

cheers,
eric