To: Eric Brunner-Williams in Portland Maine <firstname.lastname@example.org>
Cc: Edward Lewis <email@example.com>, Eric Brunner-Williams in Portland Maine <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
From: Edward Lewis <email@example.com>
Date: Tue, 25 Mar 2003 09:51:16 -0500
Subject: Re: [ietf-provreg] Our "Privacy Issue"
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.