Re: [ietf-provreg] again with the privacy

[Rick Wesson <wessorh@ar.com>]

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


On Mon, 17 Mar 2003, Edward Lewis wrote:

> 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
> >owner-ietf-provreg@cafax.se using -f
> >From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
> >To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
> >Subject: Updated (and hopefully the last) EPP Privacy Proposal
> >Date: Mon, 30 Dec 2002 09:08:46 -0500
> >Importance: high
> >X-Priority: 1
> >Sender: owner-ietf-provreg@cafax.se
> >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">jdoe@example.com</contact:email>
> ><contact:email>jdoe@example.com</contact:email>
> >Both of the above mean "do not disclose this email address to third
> >parties".
> >
> ><contact:email dnd="false">jdoe@example.com</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
>