Subject: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 15 Apr 2003 15:41:06 -0400

I'd like to propose adding the following text to section 2 of the contact
mapping document to move forward with the element privacy approach described
here:

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

I am assuming that we are past the point of discussing whether or not the
direction described in this new text is one we need to follow.  Specific
replacement text would be _most_ helpful if you see something that you don't
like.

"2.9 Disclosure of Data Elements and Attributes

The EPP core protocol requires a server operator to announce data collection
policies to clients; see section 2.4 of [EPP].  In conjunction with this
disclosure requirement, this mapping includes data elements that allow a
client to identify elements that require exceptional server operator
handling to allow or restrict disclosure to third parties.

A server operator announces a default disclosure policy when establishing a
session with a client.  When an object is created or updated, the client can
specify contact attributes that require exceptional disclosure handling
using an OPTIONAL <contact:disclose> element.  A server operator MAY reject
any transaction that requests disclosure practices that do not conform to
the announced data collection policy.  Once set, disclosure preferences can
be reviewed using a standard contact information query.

If present, the <contact:disclose> element MUST contain a "flag" attribute.
The "flag" attribute contains an XML Schema boolean value.  A value of
"true" or "1" (decimal one) notes a client preference to allow disclosure of
the specified elements as an exception to the stated data collection policy.
A value of "false" or "0" (decimal zero) notes a client preference to not
allow disclosure of the specified elements as an exception to the stated
data collection policy.

The <contact:disclose> element MUST contain at least one of the following
child elements:

<contact:name type="int">
<contact:name type="loc">
<contact:org type="int">
<contact:org type="loc">
<contact:addr type="int">
<contact:addr type="loc">
<contact:voice>
<contact:fax>
<contact:email>

Example <contact:disclose> element, flag="0":

<contact:disclose flag="0">
  <contact:email>
  <contact:voice>
</contact:disclose>

In this example, the contact email address and voice telephone number should
not be disclosed.  All other elements are subject to disclosure in
accordance with the server's data collection policy.

Example <contact:disclose> element, flag="1":

<contact:disclose flag="1">
  <contact:name type="int">
  <contact:org type="int">
  <contact:addr type="int">
</contact:disclose>

In this example, the internationalized contact name, organization, and
address information can be disclosed.  All other elements are subject to
disclosure in accordance with the server's data collection policy."

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

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 15 Apr 2003 17:00:59 -0400

Scott,

> A server operator MAY reject
> any transaction that requests disclosure practices ...

There is no in-band indicator of error. Why not?

"MUST reject" rather than "MAY reject", since "MAY reject" will be translated
into business English as "MAY silently modify requests."

> ... that do not conform to
> the announced data collection policy.

What if there is no <dcp> (if <dcp> goes back to OPTIONAL)?

Putting org in is a mistake. People have "privacy", non-people don't.

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 15 Apr 2003 17:39:56 -0400

----- Original Message ----- 
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
> Putting org in is a mistake. People have "privacy", non-people don't.

I disagree.
Both are legal entities.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 15 Apr 2003 17:43:01 -0400

> > Putting org in is a mistake. People have "privacy", non-people don't.

So is my dog. So is IBM. So is the United Nations. So is Antarctica.

---

From: Ed Allen Smith <[email-masked]>
Date: Tue, 15 Apr 2003 18:04:04 -0400

>> Putting org in is a mistake. People have "privacy", non-people don't.

And? Corporate entities have significantly higher requirements for public
identity information being available than do people; this is generally
considered a requirement for their being considered legal entities in the
first place.

     -Allen

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

---

From: "Ross Wm. Rader" <[email-masked]>
Date: Tue, 15 Apr 2003 18:12:27 -0400

[cc: trimmed - sorry if anyone on the line isn't on the list...]

> > Putting org in is a mistake. People have "privacy", 

I'd have to agree with Edmon's disagreement, but for different reasons.
There are very specific and very reasonable instances in which orgs
might desire some level of privacy, but this is usually called
"secrecy". Instinct tells me that the question of whether or not it is
appropriate is something that's better sorted out by local policy. 

So I think I'd like to see it left in...gotta keep local policy busy.

                       -rwr

"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Get Blog... http://www.byte.org/

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
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".

Four years ago, when I started work in this area, not all of it in PROVREG,
some was in the presence-related WGs, some in HTTP, some in the W3C's P3P
Spec WG, and some in CPEx, every knee-jerk half-wit in the IESG said before
a regular-sized sombrero could hit the floor (falling from head-height in
normal gravity and an intellectual vaccum) that "privacy" was part of
"security" (and that if the data was encrypted, why that solved everything).

In the last year I haven't heard that sound-bite, so for all the dreck this
is, there is some progress -- the issue isn't just evesdropping, it is the
use and more that the intended recipients put to the data they acquire.

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".

Eric

---

From: Andrew Newton <[email-masked]>
Date: Tue, 15 Apr 2003 19:47:24 -0400

> considered a requirement for their being considered legal entities in the

In the non-people legal entity realm, there are even distinctions 
between what may be made private and what must be public.  A large 
multinational corporation must make much more information public than 
does a one-man consulting shop, but they are both non-people legal entities.

And while there may be few or no jurisdictions making distinctions 
between the "privacy" or "secrecy" requirements of various sized, 
various functioned organizations, it doesn't mean there cannot be or 
never will be any.

So I agree with Ross.  Whether info about an org is non-public is a 
policy issue.

-andy

---

From: "Ross Wm. Rader" <[email-masked]>
Date: Tue, 15 Apr 2003 20:15:36 -0400

> I don't mind a mechanism existing for "secrecy", but I do mind calling it
<snip>

I'd agree - "non-disclosure" sounds more appropriate.

                     -rwr

Got Blog? http://www.byte.org

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 15 Apr 2003 20:36:47 -0400

> I'd agree - "non-disclosure" sounds more appropriate.

non-disclosure by a legal entity (not an individual person).

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Apr 2003 11:21:29 -0400

I've found that we have consensus to leave dcp as mandatory, not 
distinguish between personal and corporate data, and in general have 
no concerns about the words included below from Scott.  BUT, in going 
back through relevant threads and what was verbally discussed in SF I 
have a couple of items that need to be addressed.

There were questions from Joe Abley in
       http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00101.html
that seem to be unaddressed by this proposal.

Particularly:

"2. A complete proposal should specify whether a "dnd"d field should be
distinguished from a non-existent field when presenting data to clients
(e.g. via <info> commands). If it should, then the proscribed manner in
which that should be done should be included for <info>.

"3. What should <check> return if the object being checked is marked as
dnd="true" and the client doing the <check> is one to which disclosure
is prohibited?"

The proposed text here does not specify the impact of a private flag 
on the server's "write" functions.  I think that this can be fixed by 
merely specifying the protocol actions in these cases.

Adjunct to that discussion, the following needs to also be addressed: 
how can the setter of the privacy data check the privacy setting? 
How can it be changed?  (I recall asking this in SF.)  The closest 
that you come here is the text near the lower-case "should."  (Which 
in itself is a no-no. ;))

PS - could you also make sure we haven't introduced other lower case 
RFC 2119 words in the documents.  There are a few that have popped in 
(outside of the boilerplate) in recent edits.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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."