Subject: RE: [ietf-provreg] legal entity vs individual person

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 18 Apr 2003 13:39:03 -0400

> The client-side proposal is not my proposal.
> 
> The proponants of client-side should provide the editor text 
> that works.

Proposed text is already on the list for discussion.  If you're arguing that
the text is inadequate, I've requested text from the WG to address whatever
anyone feels is inadequate.  If you're arguing that the whole approach is
inadequate I'll ask for one of two things:

1. A new, clear, concise alternative, or

2. A consensus call so we can get past this issue once and for all.

We've talked about this for months and no one has produced anything that
resembles #1.  It's (past) time to make a decision.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 18 Apr 2003 14:18:47 -0400

Scott,

I didn't drink the koolaide that was passed around at San Francisco.

I didn't propose client-side.

I didn't propose the following flawed ideas:
	"privacy" is binary valued
	"privacy" is "the same" for individuals and non-individuals
But I have spent some time on them, for very little public results.

I don't like the _theory_ of client-side. I wouldn't like it if some
QoS edge-yokle claimed that an edge-node could force arbitrary policy
on a bandwidth provisioning registry, break-da-net-but-gimme-my-MTV.

I don't like the turning away from the possibility that social data
can be usefully managed within some frameworks, whether public law or
private.

The degree of goofiness has diminished over time, it began with arbitrary
pervasive binary toggles, and has moved into something less crazy, but
it isn't yet obvious to me that it is trivial to fix, to reconcile two
mechanisms, the <dcp> and the <c:d f=N> elements.

If no one provides the editor with useful text, you have some latitude
over changes that are purely editorial in nature.

If there is consensus to approve what resembles the IESG's fiat, I do
not mind. It is optional to deploy, so it really doesn't matter if the
client-side bits can't work with the server-side bits, and after all,
the IESG might not be bright enough to detect "gundecking" (new paint
over rusty metal).

In my opinion, this hasn't been the best use of my time, or yours, or
anyone's. I was happy as a clam at high tide when we just had a <dcp>,
I wasn't even bothered that most implementors would not implement it,
or that some operators would find the whole idea foreign.

I'm going to muck with a portmaster, some switches and some routers,
and think about something else. Have a nice weekend, find some eggs.

Eric