Re: [ietf-provreg] Our "Privacy Issue"

[Edward Lewis <edlewis@arin.net>]

At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote:
>It had one error. The assertion that to function (at all) some delta
>is required. The correct statement is to function (as required post
>rfc3375) some delta is required.

Eric, help me here.  What is your point?

>Requirement by assertion is more popular than I recall.

I'm still not getting your point.  I'm not sure if you are unhappy 
that someone wants to add client-sent statements on privacy or that 
the someone is the IESG.  I'm not sure I see a reason from you 
explaining why adding this is a bad idea.

>Question #1: If the client originated a <c-dcp> as part of session
>init, and the server responded with a <s-dcp>, and the evalution
>algorithm (tbd) was simple, e.g., equality, would that meet their
>requirement?

Initially, this might be, but as an outcome of the discussion in the 
meeting we felt that finer granularity was desirable and achievable. 
We talked about this as being a session-granular thing, but that was 
discarded.

>In eppcom-1.0.xsd we have this:

You're getting into an implementation detail.  At this point, we are 
hashing out the problem statement.

>>  The IESG is doing this through the role of protocol design engineer
>>  review - recognizing functionality that oughta be in a protocol but
>>  isn't.
>
>3375 is the requirements statement.

Yeah, it is.  Obviously, you mean something by saying that, but it is 
not clear.

>>  But the only option available to users of the client is to decide
>>  whether or not to make the registration.  We want more of an option
>>  than that.
>
>Please explain.

We want the registrar to be able to say, here's the phone number but 
don't send it anywhere.  What is meant by 'anywhere' is policy 
specific, hence outside the WG's concern.

>It is my sense that "privacy" is not simple.

Then it's not privacy we are concerned about.  It's about tagging 
data with something called 'privacy.'

Recall that this effort is to build an interoperable, general purpose 
protocol.  If there is something you think is useless and harmless, 
then don't use it and don't complain.  (Harmless = doesn't cause a 
lot of things, including [useless] bloat.)

You may decide that what is here is not enough, then use an 
extension.  You may decide what is here does not apply to you, but if 
it applies to someone else, see if you can live with it.  The process 
is about finding "common denominators" and not tailored, optimized, 
solutions.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.