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?