Re: grrp-reqs-06, 3.2 Identification and Authentication [3]

["Jordyn A. Buchanan" <jordyn@register.com>]

At 02:05 PM 2/14/2001 -0500, Eric Brunner-Williams in Portland Maine wrote:
>This effects "repurposing", "redistribution" or "publication", a term I can't
>think of (though I know of a registry operator which claimed it had a right
>to indefinite registry data retention, independent of any operational status),
>and introduces inconsistent cache semantics (Registrant's write-access through
>a series of R-* "caches" to a Registry). This example is worse than using the
>(current) data collection statutory regime in the US for data originating in
>the EC, but non-negligible differences exist, and most of the root delegations
>follow the principle of political geography and delegated jurisdiction.

I'm not disputing that there are differences in data policy across 
jurisdictions, between different registries, registrars, etc.  I just don't 
see the need to try to accommodate the negotiation of the differences 
within the protocol.  In your example, [i] can write [j] a letter and tell 
them their data policy, and vice versa.  Often, the decision of whose 
policies will be "obeyed" by the various parties is a matter of legal or 
policy judgement, not a rules-based calculation of the appropriate policy 
based on characteristics communicated through a technical protocol.

I agree with the original point you made--this group is not prepared to 
deal with these issues.  I don't think that implies that we can't try to 
negotiating authentication and/or identification mechanisms, however.  I'm 
prepared to acknowledge that we're not dealing with the full scope of data 
policy elements, but I don't think that means we should give up on solving 
the problems that we can or hastily adopting a transport mechanism that may 
or may not be well suited for the protocol we develop.

>Note these data collection policies are not specific to any particular datum
>(or object) within a flow between R-* entities, any more than are the A & I
>policies.

Yes they are.  A couple of examples:

- Name server objects may be subject to substantially different privacy 
restrictions than contact objects.  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.
- 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.

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.

>How the data policies are implemented is (implementation specific). How they
>are announced, let alone "negociated" is a protocol requirement, assuming that
>policy differences do in fact exist. I think they do.

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.  Additionally, they are unlikely to change with regularity, so 
there's no need for dynamic negotiation to occur.

Jordyn