[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Mon, 21 Oct 2002 12:27:22 -0400
Content-ID: <5411.1035217642.1@nic-naa.net>
In-Reply-To: Your message of "Mon, 21 Oct 2002 10:08:29 EDT." <3CD14E451751BD42BA48AAA50B07BAD6033700A2@vsvapostal3.prod.netsol.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: "private" Element Attribute

Scott,

This is "policy".

I proposed moving 954 to historic, so there would be no "IETF Impremature" for
repurposing social data. Bob Braden seems to be of the view that changing the
status of 954 would make the protocol go away. I don't know how, but he had a
"third-rail" response when he saw the draft in the announce list. He wasn't
alone in thinking I'd come down with the IETF-equivalent to head lice.

What is out there, the ICANN zoo, data wholesalers, data miners, the EU
Directives, its beyond us.

I understand that Patrik wants to stick a bi-valued switch on each object in
the tree. Sic transit gloria whois.

This no more extensible than Hong's dohicky for registry-private (nexus and
purpose) policy cruft. It doesn't get extensible until schematized.


Unrestricted third-party access (with no guarantee of accuracy) comes from
the <recipient> element, with a value of <public/>.

We could add the pestilential form specific to the domain name industry,
mandated by 954 (which the RIRs sanely ignore, but ICANN is fixated upon),
and add a <whois> element as a child of the <recipient>, and even allow it
child elements.

The effect would be that registries that publish via 954 (private) data
could announce their (US DoD EXPIRED, ICANN CONTEMPORARY MANDATED) policy.

If the WG consensus is to adopt Patrik's proposal, I suggest that the better
default value is "true", not "false".

I don't think Patrik's proposal sensible. Here's the example from -07, with
interlinear comments, with an "or" passage:

  S:    <dcp>
  S:      <access><all/></access>
		(the originator can see his/her data, detecting error, OK)
  S:      <statement>
  S:        <purpose><admin/><prov/></purpose>
		("admin" and provisioning only, OK)
  S:        <recipient><ours/></recipient>
		(the data is provisioned only and apparently not published)
or

  S:        <recipient><ours/><public/></recipient>
		(the data is provisioned and published via :43)
  S:        <retention><stated/></retention>
  S:      </statement>
  S:    </dcp>

It appears that we ment publication via the zone file is implicit in <ours/>.

Now we could change the sense of <ours/> to no-publication, just internal
use, and add a <dns/> and a <whois/> for publication forms and allow dcp's
like these:

  S:        <recipient><ours/><dns/><whois/></recipient>
		(classical 954)
or
  S:        <recipient><ours/><dns/><whois/><public/></recipient>
		(classical 954 plus some non-43 publication, ala IM et al)
or
  S:        <recipient><ours/><dns/><whois/><unrelated/></recipient>
		(classical 954 plus bulk sale to cash-n-carry marketers)
or
  S:        <recipient><ours/><dns/></recipient>
		(a dns-only registry, yeah!)



There is an interesting nuance on one of your examples:

	<domain:name private="false">example.com</domain:name>

Why would this ever be "private"? Since we don't have a dns-or-whois flag
(yet), isn't every domain published (via dns)? Ans: This could allow the
private registration of names, moving strings out of the registry's string
space, without disclosing the fact that the string has been taken for non-
administrative purposes.


The problem is that there is an equivalency-class of registries (and also
of registrars) who MUST do whatever silly thing is in their business paper,
In particular, they must ignore jurisdictional claims which conflict with
the policies contained in their business paper, and must provide whois:43
in its US DoD form (actually in its MILNET TAC (strongest) form).

As wide-spread as this abuse is, it is not generic, it is not automatically
applicable to the ccTLD registries, who would have to be crazy to sign the
ICANN contract, and irrelevent to the RIR registries, a class of non-TLD
registries that may use EPP.

As with Hong's dohickey, existance or absence of whois:43 is registry-private
policy cruft.

Incidently, noWhois as a policy could be fulfilled and the email data sold
to 3rd-party marketers, or used to promote additional registry (or registrar,
or reseller) products and services.

More than one cork is required to keep a boat afloat that has two or more
holes. Shooting whois:43 in the head is always a good idea. Leaving the
registries free to not implement an optional <dcp> that would disclose the
bulk sale of customer profiles is not an equally good idea.

Since the additional attribute would not be "optional" (it has two defined
values), this (limited) form of "privay enablement" would be manditory to
implement, unlike the <dcp>, which we've left optional.

The proposal (bivalue attribute added to all elements) doesn't add function
not already present in the <dcp>, with the implicit nuance that <dcp>s have
EPP-session scope, which leads to an operational set-up/tear-down overhead
to delta the <dcp> on per-object basis.


I'm opposed. I'm opposed to a scopeless bivalued semantic addition. I would
not like the idea any better if the proposal was to color every element, so
long as the color was either black or white. 


Now Randy's point was different, the scope of some semantic. At present, we
have a <dcp> in a <greeting>, providing EPP-session scope to whatever sort
of data collection practices semantic we have. Could we make the granularity
scope sensibly smaller than EPP-session?


Sure.



A point of my query yesterday was that some data is participant-private, so
the access model for blobs-o-gunk during onward-transport from the originator
(registrant) to the (authoritative) repositor{y,ies} might not be uniform.
Suppose for a moment we'd wicked-good element-wise XML crypto, and the email
address (paf@paf.se) was delivered to the registry encrypted. The registry
could transparently publish "gobble@de.gook", making Patrick happy.

Comments by Janusz (enum), and Mike (<info> affected) noted while writing.
Enum is not the answer, per Scott. <info> scoping and contact-private-creep
seems reasonable and probable, assuming an outcome I'd prefer not.

Eric

> Randy:
> 
> 8.
> why do domain/contact/.. not have granular information about privacy?

Home | Date list | Subject list