To:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
cc:
ietf-provreg@cafax.se
From:
Jaap Akkerhuis <jaap@sidn.nl>
Date:
Tue, 04 Mar 2003 16:31:02 +0100
In-reply-to:
Your message of Tue, 04 Mar 2003 07:22:16 -0500. <200303041222.h24CMGtY082995@nic-naa.net>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
It appears I did read that. I replied with about 60 lines of comment in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html and a one character correction in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html and followed up with http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html Two followups for a charater change. You said: 1. Application of the IESG proposal to "technical" data. The .NL registry defines (hypothetically of course) a dnp==true value for one or more elements as an error condition, and presumably returns some error code. Someone, Scott if my memory serves, mentioned a registry which defines a dnp==true value for one or more elements as a non-error, and presumably returns something other than an error code. Is using EPP with dcp==true for technical data a good thing? I see it as an operation to modify the string-space, with no external manifestation, other than error upon query or transform. I can't imagine an application to an address registry's operational practices, but I don't have direct knowledge of address registry or registrar operational art. That shows. Note I said, that this was a hypothetical case. 2. Application of the IESG proposal to "social" data at a registry. The .NL registry anticipates (effective 29 Jan 2003) operating under the general framework of a European Union member state's Data Protection Act. Consistent with the general framework of EU's Data Protection Directives, the access, purpose, recipient, and retention are all contractually defined. This is not generally the case for registries operating outside of the EU, nor for registrars and resellers operating outside of the EU. It would be helpful if the details of data protection between a non-EU resident .NL regsitrar and the .NL registry were available, assuming any exist. Note that we do this under dutch law. If registrars and registrations doesn't want to confirm to that, there is no point in registrting in .NL. 3. Existance of the PROVREG proposal, in the presence of the IESG proposal. Would the .NL registry operator use both the session-level <dcp> data, and the element-level opt-{in|out} data? If the answer is "no", as I suspect it is, then <dcp> use either a) is error, or b) is silently discarded. No, it is not discarded. Reread. And I din't mentioned both elements at all. If the answer is "yes", which takes precidence in the event of conflict? Trying to keep concrete, data originates from a registrant and is collected by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is provisioned to a .EU-Registry. Is the mechanism that provides the guidance for operational art at each onward-transport entity out-of-band (contract), or is it in-band, and if in-band, did the IESG proposal provide the same policy at each collector/onward-transporter as the European Union member state's Data Protection Act? I don't think so. I could be wrong. A p|np toggle is fine if purpose/recipient/retention/access are already taken care of (the Data Protection case). Where they are not, (OEDC and US cases), a p|np toggle may solve the 954 problem. How it can be applied to non-954 (and 954bis) is not stated. Deliver text. jaap