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

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 16 Apr 2003 09:39:36 -0400

Off-list yesterday evening a provreg contributor wrote me the following:

>>	... is the distinction between entity and individual actually
>>	important?

I replied (also off-list):

> It is distinguishing the requirement. 95/46/ec has data protection arising
> out of a theory of human rights contained in the Treaty of Europe. In the
> US, the FTC has privacy arising out of a theory of private contract. From
> that, you know that ICANN contract is supreme in the US, and it isn't in
> Europe -- however, 95/46/ec applies only to people, not legal fictions.
> 
> If you say "privacy" in a 95/46/ec jurisdiction, as a North American, they
> will understand you to be trying to say 95/46/ec, and data protection. If
> you then say "for corporations", they'll be confused.
> 
> No corporation in the EU can go to the local data schutz and moan about
> their human rights and data, they have to moan differently. A person on
> the other hand can have the LDS moving to enforce national implementation
> of 95/46/ec, and the Treaty of Europe, and the Dignity of Human Rights by
> a simple complaint against a data collector.

I didn't discuss the OECD set of jurisdictions, which are somewhere between
these two, both in theory and practice. Life is complicated enough.

We had (rreq, now 3375, 8.4)

	The protocol MUST provide services to identify data collection
	policies.

To this we add (IESG fiat)

	The protocol MUST provide client binary 3rd-party disclosure labels.

Since the IESG mechanism is specific -- client control of data publication,
and covertly, via 954, et seq., not via 1034/35, by the server, this is not
a design choice made in a policy vacuum. This is about data that tends to
identify an individual person.

I don't want this:

X. Privacy Considerations

   None.

Y. Client Data Control Considerations

   Redistribution of registrant contact data may be controlled by the
   <mumble> element.

I want this:

X. Privacy Considerations

   Data that may identify individual persons is identified and policied.
   See <mumble>.

Eric

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Apr 2003 10:29:12 -0700

On Wednesday, April 16, 2003, at 06:39 AM, Eric Brunner-Williams in 
Portland Maine wrote:
<way big snip>
>    Data that may identify individual persons is identified and 

One of the cases mentioned has been data for organizations
which implicitly identifies data about individual persons.  One of the
common cases would be the single-individual consulting shop;
in that case you might argue that revealing this information is
a cost of doing business as a legal entity rather than as an 
individual.  The
hot-button cases, though, are those where revealing the information
has consequences for a third party.  The shelter example is the
one most commonly cited, where the decision to reveal information
about the shelter's business address or telephone number affects
those who seek its services.

Figuring out whether or not to support specific cases seems to me
a policy decision.   Having the hook for the different policies
seems reasonable enough; whether you cast it as "Privacy Considerations"
or "Client Data Control Considerations" doesn't really matter to me.

				regards,
					Ted Hardie

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 16 Apr 2003 13:37:09 -0400

> which implicitly identifies data about individual persons.  One of the

solved by roles. [email-masked]

> a cost of doing business as a legal entity rather than as an 

solved by roles. [email-masked]

> those who seek its services.

solved by pobox and hotline. see http://www.cumberlandcounty.org/DAvr.html.

> or "Client Data Control Considerations" doesn't really matter to me.

I'm aware of that.

Eric

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Apr 2003 11:20:40 -0700

On Wednesday, April 16, 2003, at 10:37 AM, Eric Brunner-Williams in 

> solved by roles. [email-masked]

Role contact information is a useful tool, but it does not achieve
the same thing as there some forms of contact for which
roles are not available.

> solved by pobox and hotline. see 
> http://www.cumberlandcounty.org/DAvr.html.

Assumes an infrastructure not uniformly present, and assumes that
use of that infrastructure does not carry second order threats.

						regards,
							Ted Hardie

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 16 Apr 2003 15:14:01 -0400

> the same thing as there some forms of contact for which

Please be specific.

> use of that infrastructure does not carry second order threats.

Could you explain this please.

Eric

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Apr 2003 14:36:36 -0700

On Wednesday, April 16, 2003, at 12:14 PM, Eric Brunner-Williams in 

> Could you explain this please.

Taking them together:  there is no street address equivalent to a roll 
mailbox
commonly available, and the "use a pobox" answer is not available 
everywhere
as a substitute for street addresses.

I'm sure that we could dig down into various examples for some time, 
but the
main point is that how a legal entity and humans are treated for
purposes of data disclosure is a matter of local policy.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 16 Apr 2003 17:58:36 -0400

> as a substitute for street addresses.

We worked on the postal question. We considered the question of postal
address conventions where there are little that is "conventional".

> purposes of data disclosure is a matter of local policy.

Really?

So there is no architectural principle present, something that arises
in our requirements, hence in our choices of mechanisms, that causes
us to attempt to distinguish between a person and a non-person.

If, instead of personally identifying information, EPP provisioned a
SRS with the GPS data for mountain tops, or the ranges for Spring Tides
at select points on the coast of Maine, the "treat[ment] for purposes
of data disclosure" would be indistinguishable from what we were close
to agreement was necessary and sufficient.

I don't want to leave this stone unturned, so here it is again.

> use of that infrastructure does not carry second order threats.

We've already done postal. It is in the archives.

So there is your "second order threats". What are they?

Eric

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Apr 2003 15:35:39 -0700

On Wednesday, April 16, 2003, at 02:58 PM, Eric Brunner-Williams in 
> address conventions where there are little that is "conventional".

Very true.  In a little town near me, for example, the residents have
explicitly voted against home delivery because they did not
want to do away with what they saw as their addresses---really
names like "Heart's rest" etc.

> us to attempt to distinguish between a person and a non-person.

Perhaps my terms didn't match 3375 sufficiently for my point to be
clear.  As it states, registrants may be humans, corporations, and
organizations.  Social information associated with registrants
(as per 3.4.3) may thus be associated with human, corporations,
and organizations.  There may be local policy which applies to
all registrants or which defines them by type.  To expect that
  a mechanism (such as Do not distribute) applies only to a
single registrant type is to presume something about local
policy.

> to agreement was necessary and sufficient.

If you find a registrar willing to treat a mountain top or spring tide
range as a registrant, I suggest you short their stock.

> So there is your "second order threats". What are they?

I thought it was moderately obvious; sorry.  The second order threat is 
that
public data associated with an address could be correlated with other 
public
data to re-create the data distribution problem.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 16 Apr 2003 19:15:03 -0400

Oh, you're clear enough. 

"Registrants include individuals, organizations, and corporations."
A line from 3375, three buckets.

"Social information associated with registrants may thus be associated
with human, corporations, and organizations."
A line from Hardie, same water in each bucket. This ignores the minor
problem that we don't know what "social information" is. It originally
ment anything that didn't get into a zone file -- billing data, ICANN
cruft, garbage.

What this bald assertion misses is the possibility of the existance of
properties of data that are not uniform across all three buckets.

I think such an assertion is fundamentally unlearned.

"... a mechanism (dnd) applies only to a single registrant type is to
presume something about local policy."
A line from Hardie, no mechanism distinguishing non-uniformity of data
is general.

As I said, clear enough.

> data to re-create the data distribution problem.

No. We missed "correlation with other public data" (on-line or off-line)
when drafting 3375. We missed sun spots, legal intercept, and avian
transport. We're not a fun lot.

In a day of exchanges I've found you have a firm opinion. I've no idea
how you arived at it. I know that after working on cookies, profile
transport, p3p-classic, p3p-on-cookies, p3p-beyond-the-wireline, IM,
and domains, in EU, OEDC, and the US, my initial data is not my current
data.

Eric

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Apr 2003 17:08:34 -0700

On Wednesday, April 16, 2003, at 04:15 PM, Eric Brunner-Williams in 
> ment anything that didn't get into a zone file -- billing data, ICANN

You misread me here.  I didn't say that the same information
is associated with each of the three; I said that information
of the same class (social information) may be. I think this
follows from the existing documents (both 3375, and, to
some extent, the charter).

> I think such an assertion is fundamentally unlearned.

Again, I didn't say that the same information was associated with each
of the three.  That the information is all of the same class also 
doesn't
say that its other properties are uniform.

I think that quote elides a critical verb:

>   To expect that

> A line from Hardie, no mechanism distinguishing non-uniformity of data

I'm afraid this is not clear to me.  Do you mean that the mechanism 
Scott has proposed contains
no mechanism for distinguishing among different types of data along some
axis?  Or that my statement did not describe the mechanism (true, but 
not surprising,
since it was about the expectation, not the mechanism)?  Or something 
else?

> when drafting 3375.

Glad to have lifted the rock for you.
							regards,
									Ted Hardie

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 16 Apr 2003 21:24:29 -0400

> ... information of the same class ...

And that is the error. We stopped work on defining "social" data when we
stopped progressing Ross' draft. If we were still progressing it, I'd be
attempting to make it clear that data that identifies individual persons
has a distinct requirement associated with it, for some of the eventual
EPP universe, than data that identifies things that aren't individual persons,
which is the point of this discussion.

To claim there is a single, undifferentiated "social" class of data is as
uncareful as insisting that somewhere in 1034/35 et seq you are guaranteed
a bind master file format.

> of the three. 

The data can be "the same" (modulo one tends to identify an individual and
one doesn't), but it (addresses, phone numbers) means different things, on
just that "modulo" difference.

> I think that quote elides a critical verb:

Which? "To expect that" or "such as Do not distribute"?

> Do you mean that the mechanism Scott has proposed contains no mechanism
> for distinguishing among different types of data along some axis

There is no need to distinguish, if dnd applies only to individuals, and
not to non-individuals (dogs, rocks, sea shells, shell-corporations, etc.).

As soon as one adds commercial confidential, extends the dnd to entities
other than individuals, there is no need to try and find the individual,
or pretend that this was just "privacy", or in a non-FTC jurisdiction,
that there is "data protection". 

We started with a narrow "privacy" reqirement, and risk ending up with a  
commercial secrecy scheme instead of "privacy".

It is possible to have both a sensible individual "privacy", and a sensible
non-individual "secrecy", but not by asserting that the two are utterly
indistinguishable.

> Glad to have lifted the rock for you.

I don't know how we managed to get along without you. If you are serious
about on-line and off-line data correlation, and mechanisms to identify
data collection linkage, then you'll be interested in the P3P Spec WG's
archives. DoubleClick and someone else worked really, really hard to get
linkage onto cookies, in the Nov. '99 (or '00) face-to-face. We didn't
let them, but the outcome isn't as important as a good understanding of
the mechanisms and the operational practices that could have been adopted.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Apr 2003 10:04:25 -0400

As a co-chair, my thought is that the protocol should not be making a 
distinction between individuals and organizations.  I don't have any 
novel reasons (with respect to what's been expressed on the list). 
The strongest reason to me is that such a distinction (e.g., is the 
postal address that of a one-person consultant firm or of that 
person) is a policy issue.

I.e., for the WG, and just to simplify, "individual == corporation" 
here.  I can't see why the protocol ought to worry over the 
distinction.  We're talking the communication of the data here, not 
the policy over the data.

I applaud EBW's attempts to enlighten us all on privacy, however, it 
seems that it's getting to be more like teaching pigs to sing, and I 
for one would rather oink and wallow in that mud pile over here by 
now.  Yes, I'm being sarcastic, but seriously folks, I think the time 
has come to define what we have, document it, and see what the real 
world (that one with lawyers, contracts, and farmers) think.

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

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 17 Apr 2003 11:54:10 -0400

> As a co-chair, my thought is that the protocol should not ...

is this a sentence anyone should complete?

eric

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Apr 2003 13:29:31 -0400

Yes, certainly in some cases.

I don't want to go out on a limb and state guidelines for the IETF in 
this regard, but I will address my comments and why I stated them as 
the chair here.

When a discussion on a topic threatens to derail the process of 
defining a protocol from meeting the stated objectives, I think it is 
time to step in.  In our case, we have RFC 3375 plus a statement that 
you have labelled 'IESG fiat.'  Regarding the latter, the WG has 
adopted (a consensus) that the statement, with refinements, is a 
requirement in a recent thread.  Therefore, the 'fiat' has become a 
requirement too, albeit not included in RFC 3375.  (I suspect that 
there won't be an effort to update 3375 just for that.)

Also, it should be noted that my statements are directed at focusing 
the effort to achieve just the depth we need and not more.  I did not 
make any feature requests or edits to the requirements.

>is this a sentence anyone should complete?

Perhaps a more precise wording is "the discussion over the protocol" 
and not "the protocol"
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 17 Apr 2003 14:04:06 -0400

Ed,

At Pittsburg Fred said from the podium that his side of the table (the IESG)
did not have all the clue. Here we have assertion without justification for
novel functional requirements -- which is different from the prior IESG dicta
on manditory mechanisms, e.g., congestion control.

Now is it sensible?

Since London we seem to have been in agreement that some policy required a
mechanism to disclose some operational practice -- "data protection", and
"privacy" were the rationals.

This week, these rationals seem to be abandoned. There is no "protection"
no privacy, only a non-specific access mechanism.

Mind, this is only for the client-side mechanism.

Still, did Randy want the same technical specification for his personal
registration as Verisign has for its corporate registration? I don't know
that he did. Maybe that is all he ever wanted.

It concerns me, no it irks me, that IESG clowns blow in with personal opinions
and fob them off as professional opinions. Yes, we must make less-than-best
choices to actually have something multiply independently implemented, but it
does not strictly follow that we must do what Fred would not dare -- assert
that better knowledge is always on the IESG side of the table.

It is not sensible to assert the non-existance of "personal data". There is
a set of references that specify, partially, incoherently, but not negatively,
some semantic that attaches to datagram, circuit, postal, and other network
endpoints, as well as to names, when associated with individual persons.

Ed, where is the call for consensus on the IESG fiat?

I still don't think chair-hats have interesting opinions on technical issues,
ever.

This could have been so much easier if the drive-by shooters had stopped to
find out if their aim was in fact perfect.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Apr 2003 15:47:49 -0400

>on manditory mechanisms, e.g., congestion control.

It appears that I have failed to relate all of the story from the 
meeting in SF.  During the face to face meeting, Randy Bush proceeded 
to explain the basis of his comment in such a way that it became 
clear to those of us in attendance that there was an operational 
consideration here.  I submitted the notes from the meeting based on 
the Jabber log, without having the scribe notes.  Here are what lines 
I see as relevant (editing to save space here, the message was on the 
list recently):

# now on to privacy
# ted: addressing privacy brought up by randy bush
# ted: describing registry/registrar/registrant use case
# ted: dcp tells the registrar from registry about privacy
# ted: if registrant has privacy parameters, the registrar checks against
#       the registry and rejects the registration
# ted: in this model, the registrar is handling the intersection between
#       the registrant and registry
# ted: what randy has asked for is a case where the registry handles this.
# ted: in this case, randy wants a mechanism where this is possible.
# ted: mechanism allows registrar to give registrants parameters to registry
# ted: randy wants it at the per element granularity on social data
...
# ed: this is the first time I've heard this argument clear enough to
#      understand the issue

The group then formulated a problems statement from this which was 
put on the mailing list the next week.

As far as I can tell, the comment started out from the IESG, got 
hammered out in a in-person meeting, and resulted in an additional 
requirement accepted by the WG (on the list).  In my opinion, this is 
a far more reaching (and formal) acceptance of the IESG comment than 
happened for the congestion control comment you mention.

>Now is it sensible?

If the ends justify the means. OTOH, given that it took 6 months from 
the handing down of the IESG comments until my statement above, I'd 
say the IESG:WG interface could have been smoother.

>"privacy" were the rationales.
>

I suppose that you are unhappy that with server-side statement (dcp) 
the protocol is saying "the registry says how is works" and for the 
client-side statement (don't disclose) the protocol has the client 
saying "you figure it out" - as opposed to "the registrar says how it 
works."  Is that your issue?  Are you suggesting that there should be 
a requirement that either of the client and server declare their 
privacy policies?

Barring WG feedback, I don't think that such a suggestion (which are 
words I am putting in your keyboard) would pass. I don't think the 
issue is what policies are being followed, but rather what happens to 
the data sent to the registry - which means that the asymmetric 
"servers says policy or client says what" is appropriate.

>that better knowledge is always on the IESG side of the table.

Reconsider this section of your message in the light of the WG's 
acceptance of the IESG statement.

>Ed, where is the call for consensus on the IESG fiat?

    http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00104.html

The very next post is your answer to this.

The 'declaration' of consensus appears in:

    http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00128.html

>I still don't think chair-hats have interesting opinions on technical issues,

My comments to you are based on focusing the solutions and discussion 
to stay within the bounds of the problem to be solved.

>find out if their aim was in fact perfect.

Maybe so, but in this case the drivers-by eventually stopped, backed 
up, reloaded and shot repeatedly until the problem statement was 
clearly something the WG could address.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 17 Apr 2003 16:37:35 -0400

1. On the issue of when there was a consensus call, and for what.

http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00104.html
http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00105.html
and
http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00128.html

OK. Thats done. That is consensus to specify a client-side operation.

However, this little dance has assumed a client-side operation.

You need to ask for consensus on the following:

please check one box, within the scope of a client-side <dnp> oerator,

	[] there is no such thing as "personal data" semantics
	[] there is such a thing as "personal data"semantics

That is what is the present issue, get consensus on it, and there is
nothing left in it to consider.

Eric

---

From: Andrew Newton <[email-masked]>
Date: Thu, 17 Apr 2003 17:32:04 -0400

> nothing left in it to consider.

Would the following work for you?

Instead of flag being true or false, it is an enumerated type with the 
following allowable values:
   ok to disclose
   do not disclose
   do not disclose because this is personal data

-andy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Apr 2003 17:27:13 -0400

>nothing left in it to consider.

I'm pretty darned certain that that has been done too.

Look at the follow ups to:
         http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00058.html

This was two days ago, and you participated in this.

These are voices against making a distinction/or leaving this to policy.

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00065.html
http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00063.html
http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00068.html
http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00070.html

Your last message:

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00069.html

makes it sound like you agree too:

     "I can see some operators putting 'business privacy' on
      the same level as 'human privacy', and some not."

Are we to "there is nothing left in it to consider" yet, or am I mistaken?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 17 Apr 2003 18:10:19 -0400

> This was two days ago, and you participated in this.

You got consensus on this in two days. Kwel!

Would things go faster if the discussion period were shortened? 

Maybe we could simply dispense with discussion altogether.

I know this is politically charged, and many people would like to ...
gore someone else's ox, but crapy mail from infantile uber-experts,
first Randy, now Ted, and playing fast-and-loose with process is just
unnecessary.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 17 Apr 2003 18:16:28 -0400

> Would the following work for you?

Well, it isn't "me", but

>   do not disclose because this is personal data

Look! the raison d'etre for all of this covert 954 work-around, personal data.
Labeled, or meta-labeled, so someone can do something with it, or make damn
sure they don't.

Yes.

THANK YOU ANDREW!

NB, it could still be a binary type, if the silly enclosing glob been where
the de-mux of personal from non-personal was located, <glob-p> and <glob-notp>,
but it amounts to three distinct states, so a finite enum works.

Eric

---

From: Ed Allen Smith <[email-masked]>
Date: Thu, 17 Apr 2003 18:43:50 -0400

>   do not disclose because this is personal data

Should attempting to use the last for a DNS server's IP address (at least
for IPv4) be considered a syntax error? And what's the default state (I
suggest _one_ of the above be the default for _all_, to remove disputes over
"should this default on or off" and people _forgetting_ in programming,
etcetera whether things default on or off...)?

	   -Allen

-- 
Allen Smith                       http://cesario.rutgers.edu/easmith/
February 1, 2003                               Space Shuttle Columbia
Ad Astra Per Aspera                     To The Stars Through Asperity

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Apr 2003 22:08:25 -0400

>You got consensus on this in two days. Kwel!

I'd have to say that, yes, we've managed to come to a consensus on 
this.  Again refusing to put hard metrics on what this means, we did 
have a fair spread of participants contributing comments that appear 
to be in agreement.

As far as your input, it seems that in one message you did not want 
to make a distinction between personal and corporate.   Now it seems 
you do.  Whether or not you changed your mind - which I might add is 
perfectly fine - when it came time for me to make a call on 
consensus, I figured that you agreed.

I mention that you participated to say that this is something that 
happened with you involved.  I mentioned two days to point out that 
this was a fairly fresh discussion.

>Would things go faster if the discussion period were shortened?

I assume you are insinuating that we are rushing this through.

Baring any comments to the contrary, why hold up an idea that seems 
to be met with only supporting comments?  In this case, there was one 
issue raised, but then is seemed to be washed over.  Looking deeper 
at the issue, as a chair I felt that trying to make the distinction 
was too much effort given our goal.

>Maybe we could simply dispense with discussion altogether.

Keep in mind that the words that Scott put on to the list did not 
appear out of thin air.  The words he sent on last Tuesday afternoon 
(US-EDT) are based on a older proposal as described in a message he 
sent at Mon, 31 Mar 2003 08:27:51 -0500.  (I am off-net as I write, 
so I don't have access to the URLs).

The point is that the proposal has been out there for quite a while - 
December of last year - so there's reason for a co-chair to expect a 
quickly achieved consensus.

>first Randy, now Ted, and playing fast-and-loose with process is just

This is rather impolite.

In the balance of fast and slow, fast is better.  Too fast isn't 
good, but as fast as safely possible is best.  Instead of throwing 
words like this out - and in so doing more harm than good - why not 
state a reason that would make us give pause to stop and think?

It's possible you have something.  It's possible that the group might 
clear up  the issue for you.

E.g., Andy's suggestion.  That's something constructive to work from.

---

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

> to make a distinction between personal and corporate.

If it isn't too difficult, in which message?

Date: Tue, 15 Apr 2003 17:00:59 -0400
Putting org in is a mistake. People have "privacy", non-people don't.

Date: Tue, 15 Apr 2003 18:52:11 -0400
I don't mind a mechanism existing for "secrecy", but I do mind calling it
"privacy".
...
So, if a mechanism to partition the read-access on a repository is desired,
and general, that part that meets the policy meta-requirement for "privacy"
(and data protection) can be packaged as "privacy" (and dcp). That part that
meets other policy reqiurements can be packaged as "other".

Date: Tue, 15 Apr 2003 20:36:47 -0400
non-disclosure by a legal entity (not an individual person).

Date: Wed, 16 Apr 2003 08:25:38 -0400
Sounds extentional. I can see some operators putting "business privacy" on
the same level as "human privacy", and some not.

Date: Wed, 16 Apr 2003 09:39:36 -0400
Data that may identify individual persons is identified and policied.
See <mumble>.

Date: Wed, 16 Apr 2003 19:15:03 -0400
I think such an assertion is fundamentally unlearned.

Date: Wed, 16 Apr 2003 21:24:29 -0400
It is possible to have both a sensible individual "privacy", and a sensible
non-individual "secrecy", but not by asserting that the two are utterly
indistinguishable.

God am I tired of this.
Eric

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Apr 2003 10:29:33 -0400

>the same level as "human privacy", and some not.

That one.  When you said that, my interpretation was that you see 
this as a policy issue, not a protocol issue, hence EPP ought not 
distinguish.

Using the word "extentional" (which Merriam-Webster has no definition 
for) I assumed that you were urging that the distinction be shoved 
into a policy specific extension, reinforcing the notion that the 
protocol not make the distinction.

Based on my read of this, I saw that all contributors felt that the 
protocol not distinguish.  With no other comments on the text at 
hand, it certainly looked like consensus was reached.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Andrew Newton <[email-masked]>
Date: Fri, 18 Apr 2003 11:07:27 -0400

> etcetera whether things default on or off...)?

Scott's wording said this was about contact attributes (if I've got this 
wrong Scott, please correct me).  So I would think applying any of this 
to an IP address is a syntax error.

I also made the assumption that the <contact:disclose> element would 
only be sent when the value of the 'flag' attribute would be something 
other than the default disclosure policy.  Regardless of the number of 
states, this might need to be clearer.

-andy

---

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

> this as a policy issue, not a protocol issue, hence EPP ought not 

OK. Easy enough mistake.

I want "human privacy", in the client-side <mumble> (modulo I don't want
the client side <mumble>, and I don't think "privacy" should just mean
the recipient, but accepting these defects -- IMHO -- as the consensus of
this WG), as either part of the core, or as an extension.

I want "business privacy" NOT AT ALL, but if it must exist (same modulo
as above), as a DISTINCT part of the core, or as a DISTINCT extension.

I don't want "it". If "it" exists, I want "it" to come in separate units
of syntax (or a three valued type, as Andrew suggested, which has the
same semantic result).

Now the IETF fiat (or mazda) is that <mumble> be in the core. I suppose
this would apply to both "human privacy" and "business privacy", since
their best contribution on the subject is that the two are, or should be,
indistinguishable.

Thanks for the quick turn-around!
Eric

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Apr 2003 10:57:29 -0400

At 10:40 -0400 4/18/03, Eric Brunner-Williams in Portland Maine wrote:

Ah.

>of syntax (or a three valued type, as Andrew suggested, which has the

Okay, let's get some group comment on Andy's suggestion.

Calendar note: today is a holiday for quite a few, so I'll be patient...

>Now the IETF fiat (or mazda) is that <mumble> be in the core. I suppose

Interesting.  Andy and I both drive Mazdas.  My plates are IP6ARPA.  Really. ;)

---

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

Suppose a non-null <dcp> is contained in <greeting>.

Suppose the reply (to <greeting>) is <login>

Suppose a subsequent <contact:create> element containes a <contact:disclose>
element.

  An EPP error response MUST be returned if a <create> command can not  
  be processed for any reason.

  2308    "Data management policy violation"

We don't actually know the following:

	1. how to compare the comparable (if any) child elements of the
	   server-side <dcp> and the client-side <c:d>.

It is possible that dcpRecipientType=="ours" means the same thing as the
<contact:disclose flag="0">, but so far this is unspecified.

	2. if 1 (above) were answered, and the evaluation of the two blobs
	   of syntax returned a result other than "equal", which of the two
	   blobs would take precident.

It is possible that inequality (unspecified) could be totally, or partially
ordered (also unspecified), and some evaluations result in a 2308, and some
not.

  A server MAY end a session due to client inactivity or excessive
  client session longevity.  The parameters for determining excessive
  client inactivity or session longevity are a matter of server policy
  and are not specified by this protocol.

	3. if 2 (above) were answered, and some evaluation could result in
	   2308, and servers MAY terminate sessions for reasons not specified,
	   which of the two, 2308 or sever-side session termination, takes
	   precident.

It is possible that a server could "drop" sessions that would result in an
2308 error, and establish a new session with an "improved" <dcp> that would
not cause a 2308 error.

	4. if 3 (above) were answered, and a server "tunes" its <dcp> to not
	   generate a 2308 for a specific <contact:disclose>, what changes
	   to the <dcp> that are not strictly required to avoid a 2308 are
	   allowed. (I know this can be restated better.)

It is possible that a server could "abandon" its <dcp> upon discovery of a
<contact:disclose>, and restate its <dcp> as the offered :disclose only.
A non-null <contact:disclose> could remove any restriction on the collection
policy, without detection by a client.

Well, I've got to take care of some real-life stuff. I see evaluation as a
non-trivial problem. In simple terms, Randy tells GoDaddy to <dnp> him out
of whois:43, GoDaddy says "Yup", and flogs a <c:d f=0> at VGRS, which had
a EU-friendly <dcp> in its greeting, with "strong protection" (burn before
reading, no body gets anything, etc.). VGRS sees the GoDaddy <c:d f=0>, and
flickers the session, now with a DoubleClick-friendly <dcp>, which has Randy
opt-in to arbitrary repurpose, infinite data retention, and infrequent baths.
Randy isn't in whois:43. Is he happy?

Scott wrote:
> Well, that's the proposed text, with appropriate changes required elsewhere
> in the document to maintain consistency.  Fire away.

OK. I hope this helps. Of course, hopes and effects are rarely coincident.

Appologies to GoDaddy and VGRS, I simply needed some real names to (ab)use.

Eric