To:
Vittorio Bertola <vb@bertola.eu.org>
cc:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Thu, 06 Mar 2003 08:12:33 -0500
In-Reply-To:
Your message of "Thu, 06 Mar 2003 10:06:02 +0100." <7i2e6vo2jt88gtur2jupb3ok5uf5oc5a8m@4ax.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
CRISP, WHOISFIX, NOT43, ... deal with publication protocols. DNSOP, DNSSEC, ... also deal with publication protocls. Generally, they start with some authoritative instance of some datum, and unconditionally replicate non-authoritative copies of that datum. The access and persistence properties of these do not subset the maximums for both generally. PROVREG and its anticeedents, the DOMREG BoF(s) and the authors of RRP, ... deal with provisioning protocols. Generally, they start with some non-authoritative instance of some datum, and conditionally allocate an authoritative instance of that datum. The access and persistence properties of these subset the maximums for both generally. OTHER PUBLICATION PROTOCOLS EXIST. Bulk copy, with "sale", "lease" and "rent" of mailing lists, postal and electronic, exists. Some implementations use "sneaker net". Other technical mechanisms, which exploit properties of domain name data in particular, the nameserver, technical and administrative contact, even the character space properties of a domain name (marks, soundex, Hamming Distrance from, ...) which REPURPOSE data, also exist. Data provisioned via protocol (RRP, SRS, EPP, ... NEXT) may be merged with data acquired by other means. Since the beginning of this Working Group, there have been contributors who want to "solve" the 954 problem within EPP. This approach does not solve for other publication mechanisms, nor does it solve for the user informed portion of the informed consent meta-requirement placed on all data collectors by 95/46/EC and related texts that address directories, and related tools for the management of endpoint identifiers which may identify individual persons. If the better reading of 95/46/EC et seq. is that it applies to port 43, and originators need only (may only) make port-specific negative assertions, then a "publication" framework (yours and others, e.g., the IESG) may be sufficient. Having done this twice before, I don't think so. Besides, I don't know that EPP can't be used for keyword systems, that may not use :43, and for anything similar. It would work for the US, and anywhere else where the IAB (the other one, the Internet Advertising Board) and the DMA (Direct Marketing Association) and similar trade groups control the "opt-in vs opt-out" policy issue. I now know it would work in Holland also. I don't understand this, but the European Data Commissioners I've communicated with over the past three years are French and German, so I've obviously missed something. Pointing out a specific defect in the <dcp> element's sub-schema would be really useful. Eric