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


To: Jaap Akkerhuis <jaap@sidn.nl>
cc: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, ietf-provreg@cafax.se, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Mon, 03 Mar 2003 14:57:46 -0500
In-Reply-To: Your message of "Mon, 03 Mar 2003 20:13:16 +0100." <200303031913.h23JDGue035618@bartok.sidn.nl>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry


>    
>    	[Category I participation Category I participation is open
>    	to businesses and institutions based within the European Union.] 
>
>Oh that. I thought that it was lifted. But it is still completely
>irrelevant for the privacy discussion.

OK. What, if anything, is relevant?

>    The "us" (parties having the capacity to register domain names on behalf
>    of clients) for which "the non-disclose attribute will work" appears to
>    be a scoped set of (eventual) EPP participants. The charter for this WG
>    is not to create a registry-specific, or regime-specific, or jurisdiction-
>    specific, or object-specific protocol.
>    
>I'm not bringing this up. You are.

Correct.

So there no semantic consequence to the registrar being, or not being,
"based within the European Union."

The registrar may (hypothetically) provision some datum to the .nl registry,
with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with
out difference, independent of the registrar's location. Is this correct?

I was totally mislead by the .nl registry's Dutch page on the subject of
registrar requirements. Fine. I can live with being stupid. I don't have
a lot of choice in the matter anyway.

>    How can a registrar signal in-band to a registry that it accepts
>    the general Data Protection framework, and any specific terms
>    and conditions?
>
>It doesn't need to. It should first abide to the contract. That is
>not-in band.

What contract?

Better still, if a registrar doesn't need to signal in-band it accepts
anything, then it doesn't need to even know whatever that useless thing
is.

8.4 has a MUST in it, which appears to have no meaning at all if I
finally understand you. Everything is in the contract -- Scott's opening
position, that bilateral out-of-band mechanism (contract) covered the
requirement.

>    More generally, how can any two (or more) participants in the
>    onward-transport of customer data signal in-band their data
>    collection practices, and automate the management of onward-transport?
>    
>That's not question this group has to answer. The only question is,
>what is the proper element in the protocol which help to implement
>a policy as been spelled out in the legal framework.

Well, you're a co-chair, so I guess we're finnished with

   The protocol MUST provide services to identify data collection policies.

and are on to

   "the proper element in the protocol which help to implement a policy"

Gosh this is such fun. Not.

Eric

Home | Date list | Subject list