To:
"Edmon Chung" <edmon@neteka.com>
cc:
paf@cisco.com, "Ted Hardie" <hardie@qualcomm.com>, "Ned Freed" <ned.freed@mrochek.com>, randy@psg.com, "Edward Lewis" <edlewis@arin.net>, ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Wed, 19 Mar 2003 18:39:08 -0500
In-Reply-To:
Your message of "Wed, 19 Mar 2003 15:59:57 EST." <038301c2ee5a$865c79f0$7e8a8182@neteka.inc>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] provreg's privacy issue
Edmon, Henry, Some text, on this list, before going off into the delirium of boiler-plate, would have been a blessing, neh? I see ... o a glob going from registry to registrar (don't tell the iesg), o a glob on <info> response, approximately 1k in size, o a glob on <create> response, ditto, o a bi-di glob on <update>!!! I see ... o a BEGIN END section of formal syntax with very, very little text seperating these delimeters (don't worry, we haven't gotten even a syntax clue from the IESG), I see ... o a totally irrelevent i18n section, but I understand, this is one of Neteka's sweet spots (besides, the IESG will surely appreciate the suggestion that XML will melt if "private parts" is written in Chinese, and the Chinese characters encoded in Big5), I see ... o two hooks parked at the IANA to hang some coats on, fine. So, the inference from the examples is that the syntax is a restatement of a big bit of the contact object, putting a binary, or enumerated set of value against each element -- sort of pervasive, but restricted to the contact object, attributes (but as an additional carried along "shadow" of the original, unencumbered contact object. Not only does this NOT do what our Masters in Moscow, the IESG, require, (the glob goes in the wrong direction), the scope of the extension, as it is from registry to registrar, cannot apply to any instance of WHOIS operated by the registry. Here's my you-pay-for-dinner question: registrar_N (Neteka) initiates a session with registry_V, registry_V ships back a <dcp> that says 95/46/EC applies and all data is not repurposed, there are no recipients other than the registry, that it retains the data only for the period of registration, plus some operational window for the purpose of renewal, and ... everything is _private_ (except publication via 1034/35). What data collection / privacy problem remains (that your proposal cleverly solves)? Heck, lets go for two dinners, there are two of you anyway: registrar_N (Neteka) initiates a session with registry_V, registry_V ships back a <dcp> that says says anything you want, even no <dcp> at all, registrar_N does a create for mumble, registry_V acks appropriately registrar_N ships an update on mumble that attempts to set a bit, e.g., don't publish phone #, provisioned in the prior op, registry_V nacks inappropriately, and in bad taste. Now what happens? Why "discover" access policy _after_ a committing a write? There is an Americn idiom about closing a barn door _after_ the horses have left. I'm always lacking clue, Eric