Subject: [ietf-provreg] again with the privacy

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Mar 2003 21:13:34 -0800

Jaap and I talked with Ted Hardie (incoming Apps Area AD) and Patrik 
Faltstrom (outgoing Apps Area AD) about the state of the WG.  (Sorry, 
no mics were present to get the verbatim record of this.)  I say this 
because in the past Jaap and I have tried hard to stay away from 
injecting technical material as chairs.  However, it seems clear that 
one more go of this is needed, so we are floating this again.

Below is the proposal that was generated in December in response to 
the IESG comments.  I'm resurrecting it again based on this:

   The IESG wants a means for a registrar to tell a registry whether or
   not a piece of data can be passed on.  (DCP goes from registry to registrar,
   we need a reverse version of this communication.)

    dnd="true" means: this info cannot leave the registry, not in DNS, not in
    whois, not in another means.

   What if a domain name's DNS server is dnd="true"?  Does it make DNS - no.
   Is this sensible?  Probably not.

This isn't expressive enough for all involved, but it is a basic step.

There were some objections to this in Dec/Jan.

>1. "do not disclose" seems non-extensible, when extensibility seems important.

It's a place holder.  More elaborate information can appear later.

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

Good question.  Info could return "value hidden".  What about 
'hiding' the provisioned name?  I think acknowledging it's 
unavailability is excuseable.

>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?

See above.

>For the server side the attribute based approach is more cumbersome.

I cannot answer that one.

The AD's conjectured that for PS, if we were to put this proposal 
into play and it went unused, it could be removed for DS...

Comments about this?

This will be discussed Thursday morning.

>X-Authentication-Warning: nic.cafax.se: majordom set sender to 
>[email-masked] using -f
>From: "Hollenbeck, Scott" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: Updated (and hopefully the last) EPP Privacy Proposal
>Date: Mon, 30 Dec 2002 09:08:46 -0500
>Importance: high
>X-Priority: 1
>Sender: [email-masked]
>Status:
>
>In ongoing background discussions with the IESG regarding our EPP documents,
>we (Jaap, Ed, several IESG members, and I) have continued to talk about the
>IESG's privacy-related comments and the responses to those comments that
>have been sent to the WG mailing list.  We've concluded that we need to add
>a "must implement" feature to the protocol to allow data elements to be
>tagged with a binary indicator of data owner preference for disclosure of
>information to third parties that aren't involved in the provisioning
>transaction.  Back in October [1] I described a proposal to use an XML
>attribute for this purpose.  Over the last few weeks ([2], [3]) I suggested
>a few other options.  Considering all of our options, I would again like to
>suggest an XML attribute-based approach to address this last remaining IESG
>review issue.
>
>This does not mean that the binary indicator is the only way that privacy
>preferences or policies can be expressed.  Expression of more specific
>privacy policies can be accomplished using the protocol's extension
>mechanism.
>
>The proposal is to add a new attribute to every object element in the
>domain, contact, and host mappings.  This boolean attribute, "dnd" (for Do
>Not Disclose), will be used to note that the value of an element should not
>be disclosed to third parties.  It will have a default value of "false"
>(meaning it is ok to disclose info) in the domain and host mappings, and a
>default value of "true" (meaning it is NOT ok to disclose info) in the
>contact mapping.  The defaults can be over-ridden and explicitly specified
>by clients.  Additional constraints can be defined using the protocol
>extension mechanism.
>
>Here are some examples:
>
><contact:email dnd="true">[email-masked]</contact:email>
><contact:email>[email-masked]</contact:email>
>Both of the above mean "do not disclose this email address to third
>parties".
>
><contact:email dnd="false">[email-masked]</contact:email>
>This means that the data owner gives permission for the email address to be
>disclosed to third parties.
>
><extension>
>   <noWhois><contact:email></noWhois>
></extension>
>
>(This extension example isn't syntactically valid, but I wanted it to be
>short, clear, and to the point without the clutter needed to make it valid.
>In this case it means that the email address should not be published via
>whois.)
>
>I'll also have to add some notes to explain that server policy might not
>recognize the value of an attribute if it's turned on (like in the email
>address example above) when turning on the attribute is counter to some
>policy.
>
>A measure of WG support or dissatisfaction with this proposal would be
>helpful.  Would you please send a note to the mailing list to let the chairs
>know if you either support the proposal as a way to move forward or if you
>do not support the proposal?  If you do not support the proposal it would be
>helpful if you explained why and could suggest modifications (if possible)
>to make it acceptable.
>
>If you do not support the proposal, please recognize that we have been stuck
>on this issue for quite a while and we need to do something.  On the one
>hand, we are aware of the differences in privacy policy, laws, et al. facing
>each registry.  On the other hand, we are being asked to define one standard
>protocol that is rigorous enough to not let privacy slide by.  So the
>question is - does this proposal (including extension support) allow for all
>known policies to be expressed within EPP?
>
>-Scott-
>
>[1]
>http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
>
>[2]
>http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html
>
>[3]
>http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html
>
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Rick Wesson <[email-masked]>
Date: Mon, 17 Mar 2003 21:41:40 -0800 (PST)

Ed,

all of the "issues" enumerated below are really non-issues, we only need
the privacy bits for social data not technical data. The IESG didn't ask
us to create a privacy framework for hiding DNS hosts (which is silly) see
[1]

the <dnd> element proposal, not to be confused with the attribute
proposal, does address registrar -> registry boolean notes of what
social data is to remain private.

[1] http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html

I propose that we don't have the problems you enumerate below if we
restrict the elements that can be enclosed by a <dnd> element are only
social data elements.

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 18 Mar 2003 07:52:12 -0500

Ed,

A mechanism to disclose the operational practices and policies of operators
of EPP servers with respect to "data collection", aka "privacy", is NOT a
requirement, and section 8.4 of rfc 3375, in particular the final sentance
of para 1, is incorrect.

I can live with being responsible for that train wreck.

Protocols developed under the imprimature of "the IETF", MUST NOT provide
mechanism(s) to disclose the data collection policies, in particular, the
polices to which data which identifies individual persons is subject, of
operators of the protocols.

Sounds grand and very Directorial.

Instead "we're supposed to" come up with some dork that will allow the
naive data we currently have, in the schema we currently have, with the
syntax we currently have, to "twinkle", and to provision, not just any
data collector, but only the registry operator, with this "twinkle"
property, for each provisioned glob of data, and this whole waste of
time is because 954 can't be moved to historic.

I'll be sure and tell my registrar that I want only the octets-pairs that
are prime when interpreted as Mayan digits (base 20) to be "published".

I'm obviously in the wrong IETF. I'm in the one where clue is not held
uniquely by management. The "IETF of Idiots".

I do not see the point in bothering to pretend to write a specification
that is in fact written by someone else. I'll just treat the eventual RFC
as having no more "consensus engineering standards" value than an equal page
count text that comes directly from Verisign. Implement it, and don't think
too hard about it.

I give up. I could use this time better playing with my kids, and making
open, interoperable (but not IETF referencing) product.

Eric