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


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

Home | Date list | Subject list