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


To: "Jordyn A. Buchanan" <jordyn@register.com>
cc: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca, ietf-provreg@cafax.se, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Wed, 14 Feb 2001 17:27:45 -0500
In-Reply-To: Your message of "Wed, 14 Feb 2001 15:32:00 EST." <5.0.2.1.0.20010214150906.03000160@mail.register.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]

Jordyn, Kent,

Thanks to both of you for reading my reply.

There are two "big" issues, whether there is negociation (as originally
proposed by Andre), and whether I & A exhaust the policies for which we
have a requirement for in-band policing of subsequent data flows.

What concerns me about negociation is existence. Unless a suitable wand is
waved a simple request/reply rpc-like semantic becomes "full featured".
There are lots of wands, I'm partial to a few, but none are in grrp-reqs-06.

The second point is more nuanced. I-check and A-check are policy requirements,
and we firmly believe that mechanisms exist (modulo a scaling comment by
another commentor). Now we're ready to open the flood-gates and pour data
registry-ward ... but ... _if_ P-check is possible, and since it is a real
requirement (at least as real as the EC's data protection regime), then 
we haven't finished with required and feasible end-point property
determination prior to data transmission.

> - Name server objects may be subject to substantially different privacy 
> restrictions than contact objects.

Technical data ends up in a zone file, social data doesn't. Further,
depending on thick vs thin, social data delivery semantics differ from
those of technical data.

>                                    DNS data probably needs to be generally 
> world-readable, whereas I can certainly think of circumstances in which 
> names, address and phone numbers should be generally not world-readable.

We're not discussing whois publication, only the intra-R-* policied transport
of data. One reason why we should be careful about the rrp==whois assumption
many share.

> - A country may pass a law along the lines of "no one may publish phone 
> numbers of any citizen of our country".  Presumably, phone numbers of 
> citizens of other countries can be published, so restrictions on 
> publication vary based on the data.

Actually you may be interested in reverse and multi-criteria directories,
the subject of an EC DP WG publication, as it is germane to provreg. But,
in the example I provided, the _end-point_ policy is to publish all data
collected, w/o reference to the various policies for each originators' item
of data. I'm sorry if I didn't make that sufficiently clear.

> Even if you're right and I'm wrong, this affects only my assertion that we 
> solve this through extensions of object descriptions.  We can solve the 
> problem through the addition of commands later.

Thanks for humoring me thus far. Can we solve the problem (of I & A) through
subsequent additional mechanism?

> I agree they exist, but my point is that these policies are likely to be 
> announced and negotiated out-of-band on a contractual or regulatory 
> basis. 

The P3P profile (subset produced with a hatchet) for (dns) technical data
isn't complicated. The one for social data should be no more difficult
than the one the CPExchange group developed for the onward-transport of
customer data, or for P3P for very dull web pages.

>         Additionally, they are unlikely to change with regularity, so 
> there's no need for dynamic negotiation to occur.

I never sought dynamic negotiation of data collection, just an announcement
and consistent semantics requirement. However, now that you mention it, had
Gore won the US would have transitioned from "opt-out" to "opt-in" in the
current Congress, at least that was what all the smart marketers reckoned.

Eric (ex-Engage)

Home | Date list | Subject list