From owner-ietf-provreg@cafax.se Sat Feb 1 12:58:48 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12660 for ; Sat, 1 Feb 2003 12:58:47 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Hpp9p007772 for ; Sat, 1 Feb 2003 18:51:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h11Hppco007771 for ietf-provreg-outgoing; Sat, 1 Feb 2003 18:51:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Hpo9p007766 for ; Sat, 1 Feb 2003 18:51:50 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11HpnMH046835 for ; Sat, 1 Feb 2003 18:51:49 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200302011751.h11HpnMH046835@bartok.sidn.nl> To: ietf-provreg@cafax.se Subject: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Sat, 01 Feb 2003 18:51:49 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk At the DNR-forum at RIPE-44 last week, the polish registry presented their implementation of EPP. They had to make extensions to implement the somewhat draconian Polish privacy rules. One of the things they mentioned was that they were more severe then the European ones, so when they join the EC, they might change. Anyway, I don't have the presentation on line yet, but they have piblished a document about the things they did with the protocol. It can be found as ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web. jaap From owner-ietf-provreg@cafax.se Sat Feb 1 13:10:54 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13133 for ; Sat, 1 Feb 2003 13:10:53 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11I6k9p008003 for ; Sat, 1 Feb 2003 19:06:46 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11I6k73008002 for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:06:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11I6i9p007997 for ; Sat, 1 Feb 2003 19:06:45 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h11I6VRS025721; Sat, 1 Feb 2003 13:06:31 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302011806.h11I6VRS025721@nic-naa.net> To: Jaap Akkerhuis cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Sat, 01 Feb 2003 18:51:49 +0100." <200302011751.h11HpnMH046835@bartok.sidn.nl> Date: Sat, 01 Feb 2003 13:06:31 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk kwel! From owner-ietf-provreg@cafax.se Sat Feb 1 13:32:08 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13939 for ; Sat, 1 Feb 2003 13:32:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IQF9p008342 for ; Sat, 1 Feb 2003 19:26:15 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11IQFAo008341 for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:26:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IQE9p008336 for ; Sat, 1 Feb 2003 19:26:14 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11IQEMH047050 for ; Sat, 1 Feb 2003 19:26:14 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.6/8.12.6/Submit) id h11IQDcX047049 for ietf-provreg@cafax.se; Sat, 1 Feb 2003 19:26:13 +0100 (CET) Received: from eddie.Austria.EU.net (eddie.austria.eu.net [193.154.142.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IJE9p008209 for ; Sat, 1 Feb 2003 19:19:14 +0100 (MET) Received: from eddie.Austria.EU.net (localhost [127.0.0.1]) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian -4) with ESMTP id h11IJDs5012961 for ; Sat, 1 Feb 2003 19:19:13 +0100 Received: (from lendl@localhost) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian -4) id h11IJDf9012960 for ietf-provreg@cafax.se; Sat, 1 Feb 2003 19:19:13 +0100 Date: Sat, 1 Feb 2003 19:19:13 +0100 From: Otmar Lendl To: ietf-provreg@cafax.se Subject: [ietf-provreg] FYI: nic.at presentations from RIPE44 Message-ID: <20030201191913.A12932@eunet-ag.at> References: <200302011751.h11HpnMH046835@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302011751.h11HpnMH046835@bartok.sidn.nl> User-Agent: Mutt/1.3.23i Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 2003/02/01 18:02, Jaap Akkerhuis wrote: > At the DNR-forum at RIPE-44 last week, the polish registry presented > their implementation of EPP. On a related note: Our presentation from monday's Centr workshop are online as well. You can get the .ppt files (and the latest source code tarballs) from http://sourceforge.net/project/showfiles.php?group_id=66464 . /ol From owner-ietf-provreg@cafax.se Sat Feb 1 13:57:33 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14404 for ; Sat, 1 Feb 2003 13:57:32 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Ipr9p008607 for ; Sat, 1 Feb 2003 19:51:53 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11IpruU008606 for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:51:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Ipq9p008601 for ; Sat, 1 Feb 2003 19:51:53 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11IpqMH047140 for ; Sat, 1 Feb 2003 19:51:52 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200302011851.h11IpqMH047140@bartok.sidn.nl> To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: nic.at presentations from RIPE44 In-reply-to: Your message of Sat, 01 Feb 2003 19:19:13 +0100. <20030201191913.A12932@eunet-ag.at> Date: Sat, 01 Feb 2003 19:51:52 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 2003/02/01 18:02, Jaap Akkerhuis wrote: > At the DNR-forum at RIPE-44 last week, the polish registry presented > their implementation of EPP. On a related note: Our presentation from monday's Centr workshop are online as well. You can get the .ppt files (and the latest source code tarballs) from http://sourceforge.net/project/showfiles.php?group_id=66464 . Let me clarify a bit about this. At the first day of RIPE meetings there is usually a CENTR technical meeting. This time, the afternoon was devoted to EPP. SInce the meeting is limited to CENTR members and invitees (Scott Hollenbeck was there, among others) I don't feel comfortable about quoting from that, although often the meeting minutes are published on the CENTR website. Anyway, Otmar Lendl on behalf of the Austrian registry, presented at the centr-tech meeting an implementation of an EPP server as a mod_epp Apache module. It is nice to see that this is actually public information. For details, see the URL he mentions. jaap From owner-ietf-provreg@cafax.se Sat Feb 1 17:12:02 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16700 for ; Sat, 1 Feb 2003 17:12:01 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11M1v9p009555 for ; Sat, 1 Feb 2003 23:01:57 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h11M1vRj009554 for ietf-provreg-outgoing; Sat, 1 Feb 2003 23:01:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11M1u9p009549 for ; Sat, 1 Feb 2003 23:01:56 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h11M1eRS028467; Sat, 1 Feb 2003 17:01:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302012201.h11M1eRS028467@nic-naa.net> To: Otmar Lendl cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: [ietf-provreg] Re: nic.at and nic.pl implementations In-Reply-To: Your message of "Sat, 01 Feb 2003 19:19:13 +0100." <20030201191913.A12932@eunet-ag.at> Date: Sat, 01 Feb 2003 17:01:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk My complements to the implementors! Today's NY Times (US) reports that MicroSoft has announced a modification of its product(s) in response to European data protection requirements. I'm curious to know what the .pl requirements are -- I'm familiar with the EU requirements. Cheers, Eric From owner-ietf-provreg@cafax.se Sun Feb 2 09:14:22 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05959 for ; Sun, 2 Feb 2003 09:14:21 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h12E9o9p014963 for ; Sun, 2 Feb 2003 15:09:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h12E9oPL014962 for ietf-provreg-outgoing; Sun, 2 Feb 2003 15:09:50 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h12E9m9p014957 for ; Sun, 2 Feb 2003 15:09:48 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h12E9ORS030650 for ; Sun, 2 Feb 2003 09:09:24 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302021409.h12E9ORS030650@nic-naa.net> To: ietf-provreg@cafax.se Subject: [ietf-provreg] Resend: Just checking ... Date: Sun, 02 Feb 2003 09:09:24 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk All, Since Ed runs about a week behind in responding to list traffic, I'll be happy with a response from any contributor. Eric ------- Forwarded Message To: edlewis@arin.net cc: ietf-provreg@cafax.se Subject: [ietf-provreg] Just checking ... Date: Fri, 31 Jan 2003 20:02:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Is it the case that the following mechanisms are proposed: o an attribute, of type boolean, for every element o an extensible element, of type epp:dcpType, optionally for any element of type epp:greetingType, extensible to any extensible element Are any other mechanisms proposed? Eric ------- End of Forwarded Message From owner-ietf-provreg@cafax.se Mon Feb 3 11:42:04 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12715 for ; Mon, 3 Feb 2003 11:42:03 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GakoE026583 for ; Mon, 3 Feb 2003 17:36:46 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h13GakYp026582 for ietf-provreg-outgoing; Mon, 3 Feb 2003 17:36:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GahoE026577 for ; Mon, 3 Feb 2003 17:36:43 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h13GaeYm007038; Mon, 3 Feb 2003 11:36:40 -0500 (EST) Received: from [66.44.58.246] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA19815; Mon, 3 Feb 2003 11:36:39 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200302021409.h12E9ORS030650@nic-naa.net> References: <200302021409.h12E9ORS030650@nic-naa.net> Date: Mon, 3 Feb 2003 11:05:31 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Resend: Just checking ... Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 9:09 -0500 2/2/03, Eric Brunner-Williams in Portland Maine wrote: >All, > >Since Ed runs about a week behind in responding to list traffic, I'll >be happy with a response from any contributor. Sorry about that, but it's true... >Are any other mechanisms proposed? I think you've got the proposed mechanisms... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Feb 3 11:53:34 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13027 for ; Mon, 3 Feb 2003 11:53:32 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GnvoE026685 for ; Mon, 3 Feb 2003 17:49:57 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h13GnvUE026684 for ietf-provreg-outgoing; Mon, 3 Feb 2003 17:49:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GnuoE026679 for ; Mon, 3 Feb 2003 17:49:56 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h13Gn8RS050337; Mon, 3 Feb 2003 11:49:08 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302031649.h13Gn8RS050337@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] Resend: Just checking ... In-Reply-To: Your message of "Mon, 03 Feb 2003 11:05:31 EST." Date: Mon, 03 Feb 2003 11:49:08 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >Are any other mechanisms proposed? > > I think you've got the proposed mechanisms... OK. Thanks for the ACK. From owner-ietf-provreg@cafax.se Tue Feb 11 08:41:45 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04519 for ; Tue, 11 Feb 2003 08:41:43 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BDYUoE025177 for ; Tue, 11 Feb 2003 14:34:30 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BDYUcx025176 for ietf-provreg-outgoing; Tue, 11 Feb 2003 14:34:30 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BDYSoE025171 for ; Tue, 11 Feb 2003 14:34:28 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA13681 for ; Tue, 11 Feb 2003 08:34:21 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7PASAX>; Tue, 11 Feb 2003 08:30:31 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370665@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Tue, 11 Feb 2003 08:30:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > At the DNR-forum at RIPE-44 last week, the polish registry presented > their implementation of EPP. They had to make extensions to implement > the somewhat draconian Polish privacy rules. One of the things they > mentioned was that they were more severe then the European ones, > so when they join the EC, they might change. Anyway, I don't have > the presentation on line yet, but they have piblished a document > about the things they did with the protocol. It can be found as > ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf > (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web. While at the CENTR technical forum I listened intently to these and other presentations to see how they relate to our ongoing discussion of privacy specification and the unresolved comment from the IESG. The extensions described by the folks from NASK include an element that directly relates to the IESG comments: their element is described as "it specifies whether a private person gives its permission to publish personal details in WHOIS database". We now have two ccTLD registry operators (.pl (above) and .nl (via Jaap)) who've noted that having a "do not disclose" flag is something that they need and can use. In the case of .pl, where they claim to have very strict privacy rules, implementers found that a single high-level element was sufficient to mark the content appropriately. If we had a "do not disclose" element in the contact mapping they probably wouldn't have had to add this extension. In the spirit of "rough consensus and running code", maybe this is a reasonable compromise. We have registries implementing privacy policies that need some sort of "do not disclose" marker, but maybe we don't really need to mark every element -- maybe having an optional element in the various , , and structures is all that's really needed in the real world. I'd like to ask the WG members and the IESG to consider this possibility. The WG should note that implementers of real-world privacy policies are finding it necessary to add a "do not disclose" element. The IESG should note that implementers of real-world privacy policies are finding it sufficient to flag a higher-level structure instead of flagging individual elements. Is this a possible way forward? -Scott- From owner-ietf-provreg@cafax.se Tue Feb 11 11:06:48 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09355 for ; Tue, 11 Feb 2003 11:06:47 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BG1koE026647 for ; Tue, 11 Feb 2003 17:01:46 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BG1kcj026646 for ietf-provreg-outgoing; Tue, 11 Feb 2003 17:01:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BG1joE026641 for ; Tue, 11 Feb 2003 17:01:45 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1BG2AUS035823; Tue, 11 Feb 2003 11:02:10 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302111602.h1BG2AUS035823@nic-naa.net> To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 11 Feb 2003 08:30:20 EST." <3CD14E451751BD42BA48AAA50B07BAD603370665@vsvapostal3.prod.netsol.com> Date: Tue, 11 Feb 2003 11:02:10 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The WG should note that implementers of real-world privacy policies are > finding it necessary to add a "do not disclose" element. Could someone, possibly an implementor, comment on the design choice that did not utilize the element, and disclose its deficiencies? I can guess, but it would be nice to hear from someone else who considered it and found it failed to meet a requirement. Eric From owner-ietf-provreg@cafax.se Tue Feb 11 11:49:49 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11073 for ; Tue, 11 Feb 2003 11:49:47 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGjhoE027127 for ; Tue, 11 Feb 2003 17:45:43 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BGjhBB027126 for ietf-provreg-outgoing; Tue, 11 Feb 2003 17:45:43 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGjgoE027121 for ; Tue, 11 Feb 2003 17:45:42 +0100 (MET) Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18idXN-0007cn-00; Tue, 11 Feb 2003 11:45:37 -0500 Message-ID: <3E492B60.7887F48B@libertyrms.info> Date: Tue, 11 Feb 2003 11:57:05 -0500 From: janusz sienkiewicz Organization: LibertyRMS Co. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686) X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry References: <3CD14E451751BD42BA48AAA50B07BAD603370665@vsvapostal3.prod.netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Please see my comments below: "Hollenbeck, Scott" wrote: > > At the DNR-forum at RIPE-44 last week, the polish registry presented > > their implementation of EPP. They had to make extensions to implement > > the somewhat draconian Polish privacy rules. One of the things they > > mentioned was that they were more severe then the European ones, > > so when they join the EC, they might change. Anyway, I don't have > > the presentation on line yet, but they have piblished a document > > about the things they did with the protocol. It can be found as > > ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf > > (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web. > > While at the CENTR technical forum I listened intently to these and other > presentations to see how they relate to our ongoing discussion of privacy > specification and the unresolved comment from the IESG. The extensions > described by the folks from NASK include an element that directly relates to > the IESG comments: their element is described as "it > specifies whether a private person gives its permission to publish personal > details in WHOIS database". > > We now have two ccTLD registry operators (.pl (above) and .nl (via Jaap)) > who've noted that having a "do not disclose" flag is something that they > need and can use. In the case of .pl, where they claim to have very strict > privacy rules, implementers found that a single high-level element was > sufficient to mark the content appropriately. If we had a "do not disclose" > element in the contact mapping they probably wouldn't have had to add this > extension. > > In the spirit of "rough consensus and running code", maybe this is a > reasonable compromise. We have registries implementing privacy policies > that need some sort of "do not disclose" marker, but maybe we don't really > need to mark every element -- maybe having an optional > element in the various , , and structures is all > that's really needed in the real world. I'd like to ask the WG members and > the IESG to consider this possibility. I would suggest going even further. could be restricted to social data only. That practically would restrict the element to contact mapping only. applied in domain or host mapping could lead to ambigous usage. For example: may not be necessary be a privacy statement. It could be a DNS policy statement as well. I don't see any problem with handling very unlikely and potentially ambigous privacy statements (domain or host object mapping) within EPP extensions. The protocol would still offer reasonable level of _INTEROPERATIBILITY_. > > > The WG should note that implementers of real-world privacy policies are > finding it necessary to add a "do not disclose" element. > > The IESG should note that implementers of real-world privacy policies are > finding it sufficient to flag a higher-level structure instead of flagging > individual elements. > > Is this a possible way forward? > > -Scott- Janusz Sienkiewicz From owner-ietf-provreg@cafax.se Tue Feb 11 12:00:12 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11501 for ; Tue, 11 Feb 2003 12:00:11 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGufoE027254 for ; Tue, 11 Feb 2003 17:56:41 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BGufsc027253 for ietf-provreg-outgoing; Tue, 11 Feb 2003 17:56:41 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGudoE027248 for ; Tue, 11 Feb 2003 17:56:40 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA27831; Tue, 11 Feb 2003 11:56:32 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7PA5MP>; Tue, 11 Feb 2003 11:52:42 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370673@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'janusz sienkiewicz'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Tue, 11 Feb 2003 11:52:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I would suggest going even further. could be > restricted to > social data only. That practically would restrict the element > to contact > mapping only. applied in domain or host > mapping could lead to > ambigous usage. For example: [snip] I suggested this possibility to the IESG back when the topic first came up. They've disagreed so far, with the reason being that we're moving from technology to policy as soon as we try to interpret where it makes sense. -Scott- From owner-ietf-provreg@cafax.se Tue Feb 11 12:26:59 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12251 for ; Tue, 11 Feb 2003 12:26:57 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BHMroE027576 for ; Tue, 11 Feb 2003 18:22:53 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BHMrB7027575 for ietf-provreg-outgoing; Tue, 11 Feb 2003 18:22:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BHMpoE027570 for ; Tue, 11 Feb 2003 18:22:52 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1BHNGUS036077; Tue, 11 Feb 2003 12:23:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302111723.h1BHNGUS036077@nic-naa.net> To: janusz sienkiewicz cc: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 11 Feb 2003 11:57:05 EST." <3E492B60.7887F48B@libertyrms.info> Date: Tue, 11 Feb 2003 12:23:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I would suggest going even further. could be restricted to > social data only. We all know what social data is, but do we? Ross had a definitial ID on this earlier, it has been let lapse, because we'd currently no mechanism which is dependent upon this. So, I suggest a definition of SD is useful (again). > ... That practically would restrict the element to contact > mapping only. It makes no sense to speak of "privacy" or "data protection" of domain or host objects. Nor of contacts that aren't persons (not legal fictions). Not in 95/46/EU, nor OEDC Guidelines, nor FTC lack-of-rules frameworks. > ... applied in domain or host mapping could lead to > ambigous usage. For example: > > > > > > may not be necessary be a privacy statement. It could be a DNS policy statement > as well. Correct. This has nothing to do with privacy, it has everything to do with secret-buys, a product. You can buy "secret-product-name.foo" and only your registrar and registry will know, until you "go public". > I don't see any problem with handling very unlikely and potentially ambigous > privacy statements (domain or host object mapping) within EPP extensions. The > protocol would still offer reasonable level of _INTEROPERATIBILITY_. They should return errors. EPP provisions 1034/35 publication systems, and some possible other publication systems. If someone wants a string-space management protocol, with secret-exhaustion semantics, let them go somewhere else, its a distraction from the real issue, publication via 954 and 954bis. Eric From owner-ietf-provreg@cafax.se Thu Feb 13 08:35:18 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11901 for ; Thu, 13 Feb 2003 08:35:16 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDUQoE019261 for ; Thu, 13 Feb 2003 14:30:26 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DDUQw5019259 for ietf-provreg-outgoing; Thu, 13 Feb 2003 14:30:26 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDUOoE019253 for ; Thu, 13 Feb 2003 14:30:25 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1DDUOqn078301; Thu, 13 Feb 2003 08:30:24 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.57]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA04052; Thu, 13 Feb 2003 08:30:23 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD603370673@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD603370673@vsvapostal3.prod.netsol.com> Date: Wed, 12 Feb 2003 13:47:10 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "'janusz sienkiewicz'" , "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yeah, where I see a conflict is that the original comment is: "why do domain/contact/.. not have granular information about privacy?" The comment itself constrains where there is a concern about privacy metadata. It seems to me that the only real sensitivity is to social data ("in principle" as we haven't come to a formal and clear definition of what that means - as EBW points out), but the comment doesn't hint at this. At 11:52 -0500 2/11/03, Hollenbeck, Scott wrote: >> I would suggest going even further. could be >> restricted to >> social data only. That practically would restrict the element >> to contact >> mapping only. applied in domain or host >> mapping could lead to >> ambigous usage. For example: > >[snip] > >I suggested this possibility to the IESG back when the topic first came up. >They've disagreed so far, with the reason being that we're moving from >technology to policy as soon as we try to interpret where it makes sense. > >-Scott- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Thu Feb 13 08:35:27 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11942 for ; Thu, 13 Feb 2003 08:35:26 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDWBoE019302 for ; Thu, 13 Feb 2003 14:32:11 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DDWBrh019301 for ietf-provreg-outgoing; Thu, 13 Feb 2003 14:32:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDW9oE019296 for ; Thu, 13 Feb 2003 14:32:09 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DDXD9r006868; Thu, 13 Feb 2003 08:33:13 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302131333.h1DDXD9r006868@nic-naa.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message from Edward Lewis of "Wed, 12 Feb 2003 13:44:22 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 08:33:13 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Posting the schema diff wouldn't hurt either. From owner-ietf-provreg@cafax.se Thu Feb 13 09:25:53 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11902 for ; Thu, 13 Feb 2003 08:35:16 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDURoE019267 for ; Thu, 13 Feb 2003 14:30:27 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DDURVW019266 for ietf-provreg-outgoing; Thu, 13 Feb 2003 14:30:27 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDUPoE019257 for ; Thu, 13 Feb 2003 14:30:26 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1DDUNqn078298; Thu, 13 Feb 2003 08:30:23 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.57]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA04032; Thu, 13 Feb 2003 08:30:22 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: In-Reply-To: <200302111602.h1BG2AUS035823@nic-naa.net> References: <200302111602.h1BG2AUS035823@nic-naa.net> Date: Wed, 12 Feb 2003 13:44:22 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a good request. This is one of the missing pieces of the converstation. At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: >> The WG should note that implementers of real-world privacy policies are >> finding it necessary to add a "do not disclose" element. > >Could someone, possibly an implementor, comment on the design choice that >did not utilize the element, and disclose its deficiencies? I can >guess, but it would be nice to hear from someone else who considered it >and found it failed to meet a requirement. > >Eric -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Thu Feb 13 10:01:16 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14326 for ; Thu, 13 Feb 2003 10:01:14 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DEuxoE020117 for ; Thu, 13 Feb 2003 15:56:59 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DEuxZQ020116 for ietf-provreg-outgoing; Thu, 13 Feb 2003 15:56:59 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DEuvoE020111 for ; Thu, 13 Feb 2003 15:56:58 +0100 (MET) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA26347; Thu, 13 Feb 2003 09:56:49 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7S4S6D>; Thu, 13 Feb 2003 09:54:43 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370696@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 13 Feb 2003 09:56:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This is a good request. This is one of the missing pieces of the > converstation. > > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: > >> The WG should note that implementers of real-world > privacy policies are > >> finding it necessary to add a "do not disclose" element. > > > >Could someone, possibly an implementor, comment on the > design choice that > >did not utilize the element, and disclose its > deficiencies? I can > >guess, but it would be nice to hear from someone else who > considered it > >and found it failed to meet a requirement. Is Eric's request behind a thought that we are considering either the current DCP functionality, or the "do not disclose"-proposed functionality, but not both? I can easily see a need for both: - in some environments, it might be OK for the server operator to say "this is what I will/might do with data, and if you as data originator give me data you are agreeing to my policy". We have this in the protocol right now with the element. - in other environments, it might be OK for the data owner to say "this is what I will allow you as server operator to do with the data I share with you". I thought some of the European contributors have said this sort of functionality is required under recent European privacy laws. This is something we don't currently have in the protocol. I'm not sure that this is a "pick one or the other" situation, but I'm also interested in implementer perspectives. If you're not publishing a data collection policy, is there any specific issue that's driving that decision? I haven't decided what makes sense for the .com and .net registry yet, but other people who are using EPP in domain registry operations must have been through a decision process. Come on, people, please let us know what you're doing with respect to privacy and data collection and why you're doing it! We need some real data points to help close the discussion with the IESG. -Scott- From owner-ietf-provreg@cafax.se Thu Feb 13 13:13:31 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20722 for ; Thu, 13 Feb 2003 13:13:30 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DI7boE022305 for ; Thu, 13 Feb 2003 19:07:37 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DI7bVr022304 for ietf-provreg-outgoing; Thu, 13 Feb 2003 19:07:37 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DI7ZoE022299 for ; Thu, 13 Feb 2003 19:07:36 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DI8Y9r007569; Thu, 13 Feb 2003 13:08:34 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302131808.h1DI8Y9r007569@nic-naa.net> To: Edward Lewis cc: "Hollenbeck, Scott" , "'janusz sienkiewicz'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: [ietf-provreg] Is it "social" or is it "model" or is it "mechanism"? Date: Thu, 13 Feb 2003 13:08:34 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Oki all, Back when Ross wrote "Domain Name and Related Definitions", and the latest copy I have squirreled away in my cache of nuts is -dn-defn-01, May '01 [1], the defintion offered for "social" and "technical" data was couched in the language defining the "thick" and "thin" registry models, viz: Registry, Thick: A registry in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices), is stored within the registry repository. and Registry, Thin: A registry in which some element of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry. So in -dn-defn- the model constructed the distinction. Alternatives models include alternative domain registries, not just the ICANN gTLD set, and registries that aren't domain registries that may have a shared-registry model that is object-indifferent. An alternative to the SRS model constructing what we mean by data of type 1 and type 2 is to look to the publication mechanism(s). We use 1034/35, and don't mention 954. An alternative to publication mechanism(s) as a means of constructing data types (e.g., "social" or "technical"), is meta-data associated with the data, an approach that is common to both the element form I've proposed, and the attribute form the IESG proposes. A surprisingly large amount of stuff can be published by 1034/35. We could tighten up "information needed to produce zone files". A surprisingly large amount of stuff can be published by 954. We could tighten up "information needed to implement operational, business, or legal practices". More care in specification of what is published by 1034/35, and what is published by 954, doesn't cover publication by other means. It doesn't cover bulk-transfer. The element in the does. Additionally, it doesn't cover correctness, which is equivalent to defining which instance of a datum is authoritative, and how cache instances of a datum are made consistent with the authoritative copy. The element in the does. Additionally, it doesn't cover how long any party (reseller, registrar, registry, others not described, e.g., ICANN escrow agents) retains any datum, nor what purposes it uses the datum for during each's period of retention. The and the elements in the , respectively, does. The IESG's attribute provides a binary mechanism for typing. This has the same limitation as the "more care in specification" approach, and if scoped, as Scott suggested yesterday, simply reduces those limitations to a smaller collection of datums -- subsets of the current EPP schemas. Eric [1] draft-ietf-provreg-dn-defn-01.txt, expired From owner-ietf-provreg@cafax.se Thu Feb 13 14:32:46 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23013 for ; Thu, 13 Feb 2003 14:32:41 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJRooE023054 for ; Thu, 13 Feb 2003 20:27:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DJRosI023053 for ietf-provreg-outgoing; Thu, 13 Feb 2003 20:27:50 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJRnoE023048 for ; Thu, 13 Feb 2003 20:27:49 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DJSo9r007751; Thu, 13 Feb 2003 14:28:50 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302131928.h1DJSo9r007751@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Thu, 13 Feb 2003 09:56:54 EST." <3CD14E451751BD42BA48AAA50B07BAD603370696@vsvapostal3.prod.netsol.com> Date: Thu, 13 Feb 2003 14:28:50 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > This is a good request. This is one of the missing pieces of the > > converstation. > > > > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: > > >> The WG should note that implementers of real-world > > privacy policies are > > >> finding it necessary to add a "do not disclose" element. > > > > > >Could someone, possibly an implementor, comment on the > > design choice that > > >did not utilize the element, and disclose its > > deficiencies? I can > > >guess, but it would be nice to hear from someone else who > > considered it > > >and found it failed to meet a requirement. > > Is Eric's request behind a thought that we are considering either the > current DCP functionality, or the "do not disclose"-proposed functionality, > but not both? I can easily see a need for both: I'm a little more transparent than that. Jay Random-Implementor decided to do something novel. However, assume non-uniqueness of mechanism, and non-uniformity of existence, with no fewer than one mechanism defined to be "manditory to implement". What results are forseeable, asumming anything can be forseen? > - in some environments, it might be OK for the server operator to say "this > is what I will/might do with data, and if you as data originator give me > data you are agreeing to my policy". We have this in the protocol right now > with the element. Agreed. The announced data collection policy of the server allows the client to policy-based selection among servers. > - in other environments, it might be OK for the data owner to say "this is > what I will allow you as server operator to do with the data I share with > you". I thought some of the European contributors have said this sort of > functionality is required under recent European privacy laws. This is > something we don't currently have in the protocol. Disagree. The states the purpose, recipients, access-right (of the data owner), and retention period, of the policed session in which some data will conditionally flow. For a server to offer ... , it need only cycle these through a fairly small value-space to find the least-restrictive policy to which the client (and presumably the registrant) are willing to accept. APPEL attempts this, and the P3P WG attempted, and abandoned for 1.0, a negociation or owner-preference signaling mechanism. The EU DP policy requirement contributions to the W3C's P3P WG and to ccTLD registry operators, and/or gTLD interested parties, could be different. > I'm not sure that this is a "pick one or the other" situation, Disagree. See above. Manditory beats optional (IESG's point), regardless of utility. > ... but I'm also > interested in implementer perspectives. If you're not publishing a data > collection policy, is there any specific issue that's driving that decision? Agree. I can understand why a company operating under the jurisdiction of the FTC would NOT want to go beyond the regulatory minima specific to its industry, as to do so would create an unnecessary duty , or take the opt-in side, before it (ever) becomes law. I can understand why a company operating under the jurisdiction of ICANN would NOT want to suggest that the ICANN WHOIS TF profoundly lacks clue. (Their latest proposal requires registrants to respond to postal or fax spam, not just email spam.) > I haven't decided what makes sense for the .com and .net registry yet, but > other people who are using EPP in domain registry operations must have been > through a decision process. Come on, people, please let us know what you're > doing with respect to privacy and data collection and why you're doing it! > We need some real data points to help close the discussion with the IESG. Agree. Eric From owner-ietf-provreg@cafax.se Thu Feb 13 14:47:27 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23340 for ; Thu, 13 Feb 2003 14:47:25 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJgboE023225 for ; Thu, 13 Feb 2003 20:42:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DJgagu023224 for ietf-provreg-outgoing; Thu, 13 Feb 2003 20:42:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJgZoE023219 for ; Thu, 13 Feb 2003 20:42:36 +0100 (MET) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA13000; Thu, 13 Feb 2003 14:42:24 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7S4W8B>; Thu, 13 Feb 2003 14:40:18 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" Cc: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 13 Feb 2003 14:42:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > - in other environments, it might be OK for the data owner > to say "this is > > what I will allow you as server operator to do with the > data I share with > > you". I thought some of the European contributors have > said this sort of > > functionality is required under recent European privacy > laws. This is > > something we don't currently have in the protocol. > > Disagree. The states the purpose, recipients, > access-right (of the data > owner), and retention period, of the policed session in which > some data will > conditionally flow. For a server to offer ... , > it need only > cycle these through a fairly small value-space to find the > least-restrictive > policy to which the client (and presumably the registrant) > are willing to > accept. APPEL attempts this, and the P3P WG attempted, and > abandoned for 1.0, > a negociation or owner-preference signaling mechanism. Remembering our original discussions of your data collection policy proposal I know you disagree ;-). What I'm trying to understand is why some implementers and others (including, apparently, the IESG) don't agree that it's sufficient. What's driving the perceived need for a client-delivered "do not publish" notification? Is the spec not clear enough, or is the mechanism inadequate? > > I'm not sure that this is a "pick one or the other" situation, > > Disagree. See above. Manditory beats optional (IESG's point), > regardless of > utility. Well, I agree with that -- the IESG is saying they want to see some sort of "mandatory to implement" functionality. Should we be trying to convince the IESG that the DCP features address their concerns, or do we need to add something else? -Scott- From owner-ietf-provreg@cafax.se Thu Feb 13 15:22:11 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25949 for ; Thu, 13 Feb 2003 15:22:09 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DKHvoE023697 for ; Thu, 13 Feb 2003 21:17:57 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DKHvRn023696 for ietf-provreg-outgoing; Thu, 13 Feb 2003 21:17:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DKHtoE023691 for ; Thu, 13 Feb 2003 21:17:55 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DKIu9r007895; Thu, 13 Feb 2003 15:18:56 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302132018.h1DKIu9r007895@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Eric Brunner-Williams in Portland Maine'" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Thu, 13 Feb 2003 14:42:29 EST." <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> Date: Thu, 13 Feb 2003 15:18:56 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > - in other environments, it might be OK for the data owner > > to say "this is > > > what I will allow you as server operator to do with the > > data I share with > > > you". I thought some of the European contributors have > > said this sort of > > > functionality is required under recent European privacy > > laws. This is > > > something we don't currently have in the protocol. > > > > Disagree. The states the purpose, recipients, > > access-right (of the data > > owner), and retention period, of the policed session in which > > some data will > > conditionally flow. For a server to offer ... , > > it need only > > cycle these through a fairly small value-space to find the > > least-restrictive > > policy to which the client (and presumably the registrant) > > are willing to > > accept. APPEL attempts this, and the P3P WG attempted, and > > abandoned for 1.0, > > a negociation or owner-preference signaling mechanism. > > Remembering our original discussions of your data collection policy proposal > I know you disagree ;-). On selection: Assume N instances of the server, each offering a distinct value, or one, cycling through a set of N distinct values, or N distinct registries, each offering a single distinct value. On agency (who selects): EPP defines exchanges between registrars and registries, so "data owner" (originator) is not a direct actor. > ... What I'm trying to understand is why some > implementers and others (including, apparently, the IESG) don't agree that > it's sufficient. What's driving the perceived need for a client-delivered > "do not publish" notification? Is the spec not clear enough, or is the > mechanism inadequate? The mechanism is optional. That might be the burr under some blankets. Flip that bit and test again. > > > I'm not sure that this is a "pick one or the other" situation, > > > > Disagree. See above. Manditory beats optional (IESG's point), > > regardless of > > utility. > > Well, I agree with that -- the IESG is saying they want to see some sort of > "mandatory to implement" functionality. Should we be trying to convince the > IESG that the DCP features address their concerns, or do we need to add > something else? OK. Lets talk about making the M2I, and either leaving it at session scope, and see if anyone can live with it. Eric From owner-ietf-provreg@cafax.se Fri Feb 14 14:57:40 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03013 for ; Fri, 14 Feb 2003 14:57:38 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1EJqPoE005756 for ; Fri, 14 Feb 2003 20:52:25 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1EJqP2w005755 for ietf-provreg-outgoing; Fri, 14 Feb 2003 20:52:25 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1EJqNoE005750 for ; Fri, 14 Feb 2003 20:52:24 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1EJqMqn025266; Fri, 14 Feb 2003 14:52:22 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.106]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA21394; Fri, 14 Feb 2003 14:52:22 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: Date: Fri, 14 Feb 2003 14:49:36 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] just to let y'all know Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I want to keep up to date with the current discussion, but I'll be unavailable for a few days - I'm travelling to APRICOT. The 'black out' is a bit longer as we'll be setting up for the pre-conference tutorials and I don't know when the IP will be turned on... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Tue Feb 18 05:30:22 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24351 for ; Tue, 18 Feb 2003 05:30:20 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IAPLoE008558 for ; Tue, 18 Feb 2003 11:25:21 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IAPK68008557 for ietf-provreg-outgoing; Tue, 18 Feb 2003 11:25:20 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IAPHoE008552 for ; Tue, 18 Feb 2003 11:25:17 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1IAPEqn078080; Tue, 18 Feb 2003 05:25:14 -0500 (EST) Received: from [220.128.48.47] ([192.136.136.113]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id FAA16215; Tue, 18 Feb 2003 05:25:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> Date: Tue, 18 Feb 2003 11:12:58 +0800 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "'Eric Brunner-Williams in Portland Maine'" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:42 -0500 2/13/03, Hollenbeck, Scott wrote: >Well, I agree with that -- the IESG is saying they want to see some sort of >"mandatory to implement" functionality. Should we be trying to convince the >IESG that the DCP features address their concerns, or do we need to add >something else? Funny you should mention the latter. Here are some snippets of a mail exchange I had with a member of the IESG: >"Section 8.4 of RFC 3375. See the MUST part of [1]" Paraphrasing the context of that: the IESG feels that the EPP spec does not meet this requirement. I replied: >But I bet a lot will feel that this passage from the base spec: > ># "- An OPTIONAL (data collection policy) element that contains ># child elements used to describe the server's policy for data ># collection and management." > >shows that we've already met the requirement. And got this reply: >Then the exact syntax etc for this DCP element MUST be described and included, >because another requirement is that the protocol must be able to work without >human intervention (I think the word used is "automatic"). My response: >If you want a better definition of the dcp, that can be brought to the group. >Looking through the base spec, the dcp is discussed, I assume the IESG feels >that it is not presented well enough. No further happened on the exchange. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Tue Feb 18 07:34:01 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26540 for ; Tue, 18 Feb 2003 07:33:59 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1ICV5oE009430 for ; Tue, 18 Feb 2003 13:31:05 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1ICV4cM009429 for ietf-provreg-outgoing; Tue, 18 Feb 2003 13:31:04 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1ICV3oE009424 for ; Tue, 18 Feb 2003 13:31:04 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA24271; Tue, 18 Feb 2003 07:30:45 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7P2C2Z>; Tue, 18 Feb 2003 07:30:49 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033706B8@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" Cc: "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Tue, 18 Feb 2003 07:30:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >Then the exact syntax etc for this DCP element MUST be > described and included, > >because another requirement is that the protocol must be > able to work without > >human intervention (I think the word used is "automatic"). > > My response: > > >If you want a better definition of the dcp, that can be > brought to the group. > >Looking through the base spec, the dcp is discussed, I > assume the IESG feels > >that it is not presented well enough. > > No further happened on the exchange. I'd certainly like to pursue this. The exact syntax is described completely in the schema, and each element is described in the text. If we can beef this up to address the IESG's concern then I'm all for it, but I'd like to know where they feel something is lacking. -Scott- From owner-ietf-provreg@cafax.se Tue Feb 18 08:17:13 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27476 for ; Tue, 18 Feb 2003 08:17:11 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IDEaoE009783 for ; Tue, 18 Feb 2003 14:14:37 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IDEa4f009782 for ietf-provreg-outgoing; Tue, 18 Feb 2003 14:14:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IDEZoE009777 for ; Tue, 18 Feb 2003 14:14:35 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1IDFetY006868; Tue, 18 Feb 2003 08:15:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302181315.h1IDFetY006868@nic-naa.net> To: Edward Lewis cc: "Hollenbeck, Scott" , "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 18 Feb 2003 11:12:58 +0800." Date: Tue, 18 Feb 2003 08:15:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk ... >Then the exact syntax etc for this DCP element MUST be described and included, >because another requirement is that the protocol must be able to work without >human intervention (I think the word used is "automatic"). There's a schema. ... > No further happened on the exchange. I thought they were going down a substantive path, such as changing the implementation requirement from optional to manditory, or a manditory pervasive (or scoped) leaf attribute, or ... or just buggering off until they had something technical to contribute. Aside #1. Wearing my I'm-a-registrar-and-I'm-OK hat, I posted a note to to the registrars constituency mailing list on our present quandry. Nothing yet from the gTLD registrar business|requirements parties, so all of this may be a non-issue. The RC will be meeting at the end of this week, if enough Swiss dogs can be found to get us through the snows of Washington and policy requirements for operation in the EU is on the agenda. Aside #2. The geo-blah WG's docs (spam has local context, aluminum-hats and its converse, advertizing, still have mind-share) focus on the preferences of data originators, and not on the policies of data collectors. The addition of a half-room of a mixed bag of groan-bots and greed-bots, who are originator-aware (trans: registrant-aware), transport-unaware (trans: reseller/registrar/registry-unaware), won't improve the work attempted at the face-to-face. What happened to our WG-only interim via-voca? If it fell victim to duct-tape madness in the Beltway, it is time to give it oxygen. Eric From owner-ietf-provreg@cafax.se Tue Feb 18 12:49:16 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02980 for ; Tue, 18 Feb 2003 12:49:15 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IHjIoE012421 for ; Tue, 18 Feb 2003 18:45:18 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IHjIZV012420 for ietf-provreg-outgoing; Tue, 18 Feb 2003 18:45:18 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IHjGoE012415 for ; Tue, 18 Feb 2003 18:45:17 +0100 (MET) Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h1IHjDmn029682; Tue, 18 Feb 2003 09:45:13 -0800 (PST) Date: Tue, 18 Feb 2003 09:45:12 -0800 (PST) From: Rick Wesson To: Edward Lewis cc: "Hollenbeck, Scott" , "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, from this point further I request all corrispondance with the IESG be cc'ed to this list. This issue has dragged on in part because of gatekeeping by the chairs. If the IESG wants to stir the pot they need to include us in the converstaion. I hope this is the last time I will request this as standard opperating procedure. best, -rick > Funny you should mention the latter. Here are some snippets of a > mail exchange I had with a member of the IESG: > > >"Section 8.4 of RFC 3375. See the MUST part of [1]" > > Paraphrasing the context of that: the IESG feels that the EPP spec > does not meet this requirement. > > I replied: From owner-ietf-provreg@cafax.se Tue Feb 18 16:12:13 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08770 for ; Tue, 18 Feb 2003 16:12:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IL8CoE013962 for ; Tue, 18 Feb 2003 22:08:12 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IL8CPu013961 for ietf-provreg-outgoing; Tue, 18 Feb 2003 22:08:12 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IL8AoE013953 for ; Tue, 18 Feb 2003 22:08:10 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1IL96tY008082; Tue, 18 Feb 2003 16:09:06 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302182109.h1IL96tY008082@nic-naa.net> To: Rick Wesson cc: Edward Lewis , "Hollenbeck, Scott" , "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 18 Feb 2003 09:45:12 PST." Date: Tue, 18 Feb 2003 16:09:06 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Is it the co-chairs or is it us? Digression. From -47 through -49 I worked for Engage, a company that had some value proposition associated with http cookies, the results of this were contributions to draft-jaye-http-state-mgt-nn.txt, contributions to the W3C's P3P spec (in particular, the mechanism and semantic scope from -jaye- to cookies), and the Customer Profile Exchange (CPex) trade body standard for onward transport of customer profiles (wicked close to what EPP is all about, minus the ICANN psychoactive drugs), to cookie handling done in IE 5.5 et seq, and to draft-ietf-http-state-man-mec (rfc2965). So, I had a modest exposure to a particular problem domain, and had some reason to think that http's state management mechanism provided a mechanism for sophisticated 3rd-party involvement in the http client-server model, not entirely limited to Satan Worship, animal sacrifice, popups or banner ads. I mentioned at the Plenary in Pittsburg (-48) that the IESG's note on the subject (draft-iesg-http-cookies-nn.txt) was in need of some contribution from people with subject matter expertise. [People who's 9-5 was cookies, demographics, profiling, and of course, Devil Worship.] From the podium, Fred Baker was quick to agree that not all clue resided on his side of the table. Yeah Fred! The next day I went in search of the authors, both the Apps Area ADs (then). One blew me off, with attitude. The other informed me that he knew more than I did, and the majority (of some group) was on his side. This latter exchange happened with John Klensin as an onlooker, which is one reason why John and I are friends, though we disagree on the polarity of gravity. So, draft-iesg-http-cookies-nn.txt became bcp44 and rfc2964, without any further distractions to its authors. There is a quote from the back of Mike Padlipsky's "Elements" that is appropos: Just because you are Constitutionally entitled to a personal opinion doesn't mean you're constitutionally entitiled to a professional opinion. So, here we are, presumably possessed of at least enough clue to start a fire using only damp bits of XML, stopped dead in our tracks for about a half-year, by stuff that appears to be fairly aged roadkill. Is it (a) the co-chairs' fault (and I've issues there, which are neither here nor there), or is it (b) our fault? I'm inclined to (b). 2026, in particular section 6.5.4, provides an appeal procedure. If the working group fails to get either (a) adequate progress, or (b) grounds to advance an appeal under section 6.5.4 of 2026, then the working group is technically done, and has exhausted the process mechanisms it has consensus to exploit. The idea that the IESG can function like line-noise is sort of endearing. Eric From owner-ietf-provreg@cafax.se Sun Feb 23 07:46:13 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07120 for ; Sun, 23 Feb 2003 07:46:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NCg1oE007617 for ; Sun, 23 Feb 2003 13:42:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NCg1tR007616 for ietf-provreg-outgoing; Sun, 23 Feb 2003 13:42:01 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NCg0oE007611 for ; Sun, 23 Feb 2003 13:42:00 +0100 (MET) Received: from eagle (pcp01379381pcs.levtwn01.pa.comcast.net [68.81.94.117]) (authenticated) by ns01.afilias.info (8.11.6/8.11.6) with ESMTP id h1NCfMa11648; Sun, 23 Feb 2003 07:41:22 -0500 Message-ID: <045001c2db38$d131f980$7700000a@afilias.com> From: "Ram Mohan" To: "Hollenbeck, Scott" , "'Edward Lewis'" , "Eric Brunner-Williams in Portland Maine" Cc: References: <3CD14E451751BD42BA48AAA50B07BAD603370696@vsvapostal3.prod.netsol.com> Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Sat, 22 Feb 2003 14:19:52 -0500 Organization: Afilias MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >If you're not publishing a data >collection policy, is there any specific issue that's driving that decision? >I haven't decided what makes sense for the .com and .net registry yet, but >other people who are using EPP in domain registry operations must have been >through a decision process. Come on, people, please let us know what you're >doing with respect to privacy and data collection and why you're doing it! >We need some real data points to help close the discussion with the IESG. We're looking into a required policy for the .info registry; For the .org registry, we're also trying to determine the appropriate technical measures that would make PIR's proposed "OrgCloak" data-protection service viable. A session-specific mandatory approach is appealing. -ram ----- Original Message ----- From: "Hollenbeck, Scott" To: "'Edward Lewis'" ; "Eric Brunner-Williams in Portland Maine" Cc: Sent: Thursday, February 13, 2003 9:56 AM Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry > > This is a good request. This is one of the missing pieces of the > > converstation. > > > > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: > > >> The WG should note that implementers of real-world > > privacy policies are > > >> finding it necessary to add a "do not disclose" element. > > > > > >Could someone, possibly an implementor, comment on the > > design choice that > > >did not utilize the element, and disclose its > > deficiencies? I can > > >guess, but it would be nice to hear from someone else who > > considered it > > >and found it failed to meet a requirement. > > Is Eric's request behind a thought that we are considering either the > current DCP functionality, or the "do not disclose"-proposed functionality, > but not both? I can easily see a need for both: > > - in some environments, it might be OK for the server operator to say "this > is what I will/might do with data, and if you as data originator give me > data you are agreeing to my policy". We have this in the protocol right now > with the element. > > - in other environments, it might be OK for the data owner to say "this is > what I will allow you as server operator to do with the data I share with > you". I thought some of the European contributors have said this sort of > functionality is required under recent European privacy laws. This is > something we don't currently have in the protocol. > > I'm not sure that this is a "pick one or the other" situation, but I'm also > interested in implementer perspectives. If you're not publishing a data > collection policy, is there any specific issue that's driving that decision? > > I haven't decided what makes sense for the .com and .net registry yet, but > other people who are using EPP in domain registry operations must have been > through a decision process. Come on, people, please let us know what you're > doing with respect to privacy and data collection and why you're doing it! > We need some real data points to help close the discussion with the IESG. > > -Scott- > > From owner-ietf-provreg@cafax.se Sun Feb 23 14:05:09 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11303 for ; Sun, 23 Feb 2003 14:05:08 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NIumoE009424 for ; Sun, 23 Feb 2003 19:56:48 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NIumLk009423 for ietf-provreg-outgoing; Sun, 23 Feb 2003 19:56:48 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NIukoE009418 for ; Sun, 23 Feb 2003 19:56:47 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1NIuftY027625; Sun, 23 Feb 2003 13:56:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302231856.h1NIuftY027625@nic-naa.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Ram Mohan" cc: "Hollenbeck, Scott" , "'Edward Lewis'" , "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message from "Ram Mohan" of "Sat, 22 Feb 2003 14:19:52 EST." <045001c2db38$d131f980$7700000a@afilias.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Feb 2003 13:56:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > We're looking into a required policy for the .info registry; For the > .org registry, we're also trying to determine the appropriate technical > measures that would make PIR's proposed "OrgCloak" data-protection service > viable. Good. Let me know if you want my help. >A session-specific mandatory approach is appealing. I'm glad you think so. Eric From owner-ietf-provreg@cafax.se Sun Feb 23 14:27:43 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11550 for ; Sun, 23 Feb 2003 14:27:42 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NJKqoE009559 for ; Sun, 23 Feb 2003 20:20:52 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NJKqV4009558 for ietf-provreg-outgoing; Sun, 23 Feb 2003 20:20:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NJKooE009553 for ; Sun, 23 Feb 2003 20:20:51 +0100 (MET) Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h1NJKkmn018896; Sun, 23 Feb 2003 11:20:46 -0800 (PST) Date: Sun, 23 Feb 2003 11:20:47 -0800 (PST) From: Rick Wesson To: Ram Mohan cc: "Hollenbeck, Scott" , "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine , Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: <045001c2db38$d131f980$7700000a@afilias.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ram, On Sat, 22 Feb 2003, Ram Mohan wrote: > We're looking into a required policy for the .info registry; For the > .org registry, we're also trying to determine the appropriate technical > measures that would make PIR's proposed "OrgCloak" data-protection service > viable. > > A session-specific mandatory approach is appealing. I see how a registry might prefer the proposal, however I believe that the proposal, where a container allows the client to set which elements should not be disclosed. Though its simular to It potentially allows the registrant to decide which elements to protect. Also requires the policty to be set by the registry, and allows the policy to be set by the registrant. I believe empowering the registrant is the direction we should take. best -rick From owner-ietf-provreg@cafax.se Sun Feb 23 16:56:08 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13539 for ; Sun, 23 Feb 2003 16:56:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NLoqoE010479 for ; Sun, 23 Feb 2003 22:50:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NLoqMv010478 for ietf-provreg-outgoing; Sun, 23 Feb 2003 22:50:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NLonoE010473 for ; Sun, 23 Feb 2003 22:50:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1NLoatY028057; Sun, 23 Feb 2003 16:50:36 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302232150.h1NLoatY028057@nic-naa.net> To: Rick Wesson cc: Ram Mohan , "Hollenbeck, Scott" , "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Sun, 23 Feb 2003 11:20:47 PST." Date: Sun, 23 Feb 2003 16:50:36 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Rick, If rfc3375, sec. 8.4, [1], last sentance read: The protocol MUST provide services to identify registrant data publication policies. Instead of: The protocol MUST provide services to identify data collection policies. Then we'd share a common requirement statement. A friendly suggestion: pop some into a draft of 3375bis and get it with some similarly inclined co-authors in before the -00 cut date. Then we could discuss if 3375 erred (and we all know the putative error is mine). With 3375bis creating a registrant participant in EPP, we can look to the consequences, or if the scope of registrant-as-actor is limited to values. Comment #1: Regardless of the contents of a container, it does not allow any party to state the purpose, recipients, retention period, or access to the publication data, only some binary property of "disclosure". What does "disclose" mean? Comment #2: The we've got has a finite set of elements, each taking attribute values over a finite set, each with a mechanism to extend the set. I'll use to discuss, without unnecessary overspecification, the value space we're exploring, and who sets these values. If a arises from some party other than an EPP client or server, then it must take on values other than those defined between the EPP nodes, otherwise it has no independent existance. Example: if registrant_A sets to <1, 2, 3<2,2>>, and values of <0-I, 0-J, 0-K<0-L,0-M>> are within the repitoire of the registrar/registry, then there is no way of verifying that the registrar didn't set the value of to a value in its repitoire, in particular, <1, 2, 3<2,2>>. So, the registrant only becomes "visible" when s/he goes off-reservation and uses some portion of the value-space that is outside of the operational practice of the registrar/registry, either because they subset the maximal defined set of values, or because the registrant extends the maximal defined set of values. So, if the registrant creates a that is outside the space of values either defined in some standard or operational practice, then the registrant exists as an independent actor. So, that's the first awkwardness. The registrant must utter something that is a complete surprise to the registrar/registry, such as using "00" as a value for the ccType element, or defining (an extended utility type) a cc5Type with the length value 5, to allow codes outside of the 639:2 set of values, e.g., change "US" to "BUSH2". The second awkwardness is that for the registrant's access policy assertion to be non-fictional, it has to be capable of binding the conduct of some other actor, and for the conduct of that actor in varience of that policy to be detectable. So, to continue with the ccType example, the registrant would have to be able to cause an command response to be generated, and in particular, determine if the contact:postalInfoType's child element either has a value of "00" or type cc5Type. Alternatively, for valid values (subsetted by the operational practice of the registrar/registry), or valid extensions, valid values by the registrant would result in protocol errors generated by either the EPP client or server. So, what does a registrant bring to the party, and is it actually worth having? Suppose Randy wanted to no-disclosurer for his name as registrant of psg. If the exchange between Tucows and VGRS has what requirement hasn't been met? If it is then Tucows is free to error-out and fail the data propogation to VGRS. If the exchange between Randy and Tucows and VGRS has and for reasons discussed above, the semantic of is opaque to the EPP entities, under what set of circumstances could Tucows error out and fail the data propogation to VGRS? Only if VGRS generated an error? What if VGRS had an accept-all or refuse-any for non-empty elements? Why do we even need Randy to be involved in this ? If Randy can't do anything surprising, then we can whittle his set of choices down to {0,1}, without loss of generality. I don't play a lawyer on the net, but there are reasons why 46/95/EC et seq. has the exposure of the data collection policies of the data collector as the object of its descriptive focus. I believe in Satanism, mocking the IESG, depricating the brownie baking skills of Laura Bush, and that "empowering the registrant" is significantly harder than beliving in it. Worst ;-) Eric From owner-ietf-provreg@cafax.se Mon Feb 24 11:19:06 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18024 for ; Mon, 24 Feb 2003 11:19:04 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1OGEjoE019063 for ; Mon, 24 Feb 2003 17:14:45 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1OGEiYU019062 for ietf-provreg-outgoing; Mon, 24 Feb 2003 17:14:44 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1OGEhoE019057 for ; Mon, 24 Feb 2003 17:14:43 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1OGENtY030711; Mon, 24 Feb 2003 11:14:23 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302241614.h1OGENtY030711@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: [ietf-provreg] Re: Fwd: 56th IETF WG/BOF Scheduling In-Reply-To: Your message of "Thu, 09 Jan 2003 13:16:21 EST." Date: Mon, 24 Feb 2003 11:14:23 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Several people have asked me if I plan to attend -56. I'm not. I won't enter a TSA zone of control (e.g., US Airport) for any reasons other than family emergency. I passed through three TSA checkpoints on my travel to last week's meeting of the Domain Registrar Constituency, held jointly with several of the Domain Registries. I was subjected to special processing at two of the three checkpoints. The last time I flew PWD/NYC/WDC the same results obtained. Everyone's tolerance for this sort of thing is their own. Mine has simply been exceeded. Eric From owner-ietf-provreg@cafax.se Fri Feb 28 13:57:21 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08913 for ; Fri, 28 Feb 2003 13:57:20 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SIlEoE016101 for ; Fri, 28 Feb 2003 19:47:14 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SIlEU0016100 for ietf-provreg-outgoing; Fri, 28 Feb 2003 19:47:14 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SIlDoE016095 for ; Fri, 28 Feb 2003 19:47:13 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1SIlAqn067656 for ; Fri, 28 Feb 2003 13:47:10 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA14328; Fri, 28 Feb 2003 13:47:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Fri, 28 Feb 2003 13:35:11 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] our meeting slot in SF Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk THURSDAY, March 20, 2003 0900-1130 Morning Sessions APP provreg Provisioning Registry Protocol WG Time to send in agenda suggestions...there are some obvious ones, I won't disallow anyone from suggesting the obvious. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Fri Feb 28 14:29:44 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09771 for ; Fri, 28 Feb 2003 14:29:43 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SJKqoE016465 for ; Fri, 28 Feb 2003 20:20:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SJKq49016464 for ietf-provreg-outgoing; Fri, 28 Feb 2003 20:20:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SJKpoE016459 for ; Fri, 28 Feb 2003 20:20:51 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA08772; Fri, 28 Feb 2003 14:20:43 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 14:20:47 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337075A@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Subject: RE: [ietf-provreg] our meeting slot in SF Date: Fri, 28 Feb 2003 14:20:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > THURSDAY, March 20, 2003 > 0900-1130 Morning Sessions > APP provreg Provisioning Registry Protocol WG > > > Time to send in agenda suggestions...there are some obvious ones, I > won't disallow anyone from suggesting the obvious. ;) OK, then how about putting a slot in to get to the bottom of addressing the IESG privacy comment -- assuming we can get the needed IESG members in the room to get it settled. -Scott- From owner-ietf-provreg@cafax.se Fri Feb 28 15:56:17 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13062 for ; Fri, 28 Feb 2003 15:56:16 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SKi2oE017321 for ; Fri, 28 Feb 2003 21:44:02 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SKi2tw017320 for ietf-provreg-outgoing; Fri, 28 Feb 2003 21:44:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SKi1oE017315 for ; Fri, 28 Feb 2003 21:44:01 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1SKhwqn073018; Fri, 28 Feb 2003 15:43:59 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA03859; Fri, 28 Feb 2003 15:43:58 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 28 Feb 2003 15:43:47 -0500 To: Rick Wesson From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I don't know that there's a proper response to this request. Generally, I answer privately to private mail, publicly to public mail. If anyone contacts me privately, I don't differentiate based on IESG membership status. I use my judgement when it comes to deciding whether a conversation is better served on the public list. The below referenced discussion didn't yield ( or hasn't yet yielded) anything that would add to the WG. At 9:45 -0800 2/18/03, Rick Wesson wrote: >Ed, > > >from this point further I request all corrispondance with the IESG be >cc'ed to this list. This issue has dragged on in part because of >gatekeeping by the chairs. > >If the IESG wants to stir the pot they need to include us in the >converstaion. > >I hope this is the last time I will request this as standard opperating >procedure. > >best, > >-rick > > >> Funny you should mention the latter. Here are some snippets of a >> mail exchange I had with a member of the IESG: >> >> >"Section 8.4 of RFC 3375. See the MUST part of [1]" >> >> Paraphrasing the context of that: the IESG feels that the EPP spec >> does not meet this requirement. >> >> I replied: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Fri Feb 28 18:03:07 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15957 for ; Fri, 28 Feb 2003 18:03:06 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SMqToE018644 for ; Fri, 28 Feb 2003 23:52:29 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SMqTN5018643 for ietf-provreg-outgoing; Fri, 28 Feb 2003 23:52:29 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SMqSoE018638 for ; Fri, 28 Feb 2003 23:52:28 +0100 (MET) Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h1SMqOmn027098; Fri, 28 Feb 2003 14:52:24 -0800 (PST) Date: Fri, 28 Feb 2003 14:52:29 -0800 (PST) From: Rick Wesson To: Edward Lewis cc: "'ietf-provreg@cafax.se'" , Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, The private discussion the wg chairs have had with the IESG have prevented this group from moving forward; therefore I request all communication between the IESG and the wg chairs also CC the list. We have experenced 4 month delay because of this situation and it is unacceptable. We still are in a state of limbo. ed, please restate the issues, proposed solutions, wg consensus (if any appears evident) and iesg issues in a single concise e-mail to this wg so we can at the very least understand where we are in this process, and how we can move it forward. thanks, -rick On Fri, 28 Feb 2003, Edward Lewis wrote: > I don't know that there's a proper response to this request. > Generally, I answer privately to private mail, publicly to public > mail. If anyone contacts me privately, I don't differentiate based > on IESG membership status. > > I use my judgement when it comes to deciding whether a conversation > is better served on the public list. The below referenced discussion > didn't yield ( or hasn't yet yielded) anything that would add to the > WG. > > At 9:45 -0800 2/18/03, Rick Wesson wrote: > >Ed, > > > > > >from this point further I request all corrispondance with the IESG be > >cc'ed to this list. This issue has dragged on in part because of > >gatekeeping by the chairs. > > > >If the IESG wants to stir the pot they need to include us in the > >converstaion. > > > >I hope this is the last time I will request this as standard opperating > >procedure. > > > >best, > > > >-rick > > > > > >> Funny you should mention the latter. Here are some snippets of a > >> mail exchange I had with a member of the IESG: > >> > >> >"Section 8.4 of RFC 3375. See the MUST part of [1]" > >> > >> Paraphrasing the context of that: the IESG feels that the EPP spec > >> does not meet this requirement. > >> > >> I replied: > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > From owner-ietf-provreg@cafax.se Fri Feb 28 18:35:13 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17211 for ; Fri, 28 Feb 2003 18:35:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SNPnoE018957 for ; Sat, 1 Mar 2003 00:25:49 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SNPn55018956 for ietf-provreg-outgoing; Sat, 1 Mar 2003 00:25:49 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.38.143.123]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SNPloE018951 for ; Sat, 1 Mar 2003 00:25:48 +0100 (MET) Received: from ecotroph.net (64.83.37.226.dsl226-static-nova.cavtel.net [::ffff:64.83.37.226]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by zak.ecotroph.net with esmtp; Fri, 28 Feb 2003 18:25:45 -0500 Date: Fri, 28 Feb 2003 18:25:43 -0500 Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Andrew Newton , Edward Lewis , "'ietf-provreg@cafax.se'" , iesg@ietf.org To: Rick Wesson From: Andrew Newton In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, February 28, 2003, at 05:52 PM, Rick Wesson wrote: > > Ed, > > The private discussion the wg chairs have had with the IESG have > prevented > this group from moving forward; therefore I request all communication > between the IESG and the wg chairs also CC the list. I don't know how you know the private discussions have prevented this WG from moving forward, but I'm guessing that it is not true. PROVREG should use the same procedures used by all IETF working groups. And if they aren't working out, then perhaps it should be addressed in a broader manner. Perhaps this would be good input for the problem statement work currently in motion. > > We have experenced 4 month delay because of this situation and it is > unacceptable. We still are in a state of limbo. > I agree. Lack of forward motion is frustrating. > ed, please restate the issues, proposed solutions, wg consensus (if any > appears evident) and iesg issues in a single concise e-mail to this wg > so we can at the very least understand where we are in this process, > and > how we can move it forward. > This sounds like a good idea. -andy From owner-ietf-provreg@cafax.se Fri Feb 28 22:19:00 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21188 for ; Fri, 28 Feb 2003 22:18:59 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h2137soE021385 for ; Sat, 1 Mar 2003 04:07:54 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h2137rp6021384 for ietf-provreg-outgoing; Sat, 1 Mar 2003 04:07:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h2137qoE021377 for ; Sat, 1 Mar 2003 04:07:52 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h2136ZtY066683; Fri, 28 Feb 2003 22:06:35 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303010306.h2136ZtY066683@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Edward Lewis'" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: Your message of "Fri, 28 Feb 2003 14:20:47 EST." <3CD14E451751BD42BA48AAA50B07BAD60337075A@vsvapostal3.prod.netsol.com> Date: Fri, 28 Feb 2003 22:06:35 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk I second Scott's suggestion, though in the general sense that getting some substantive response from the IESG is in theory better than not getting a substantive response, as I won't attend the face-to-face meeting of some of the working group. I don't personally care if a member of the current IESG contributes in an individual capacity, or if the IESG sits en banc, during the scheduled face-to-face, though I appreciate those who've worked on this set of drafts over the past two years who are present at this meeting have a keener interest in the time and place some eventual disclosure is offered. Eric From owner-ietf-provreg@cafax.se Fri Feb 28 23:01:27 2003 Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21694 for ; Fri, 28 Feb 2003 23:01:26 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h213o7oE021679 for ; Sat, 1 Mar 2003 04:50:07 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h213o7Du021678 for ietf-provreg-outgoing; Sat, 1 Mar 2003 04:50:07 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h213o5oE021673 for ; Sat, 1 Mar 2003 04:50:05 +0100 (MET) Received: from eagle (pcp01379381pcs.levtwn01.pa.comcast.net [68.81.94.117]) (authenticated) by ns01.afilias.info (8.11.6/8.11.6) with ESMTP id h213nnP08341; Fri, 28 Feb 2003 22:49:49 -0500 Message-ID: <0c8501c2dfa5$9aca9200$4402a8c0@afilias.com> From: "Ram Mohan" To: "Hollenbeck, Scott" , "'Edward Lewis'" , References: <3CD14E451751BD42BA48AAA50B07BAD60337075A@vsvapostal3.prod.netsol.com> Subject: Re: [ietf-provreg] our meeting slot in SF Date: Fri, 28 Feb 2003 22:47:21 -0500 Organization: Afilias MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit amen -ram ----- Original Message ----- From: "Hollenbeck, Scott" To: "'Edward Lewis'" ; Sent: Friday, February 28, 2003 2:20 PM Subject: RE: [ietf-provreg] our meeting slot in SF > > THURSDAY, March 20, 2003 > > 0900-1130 Morning Sessions > > APP provreg Provisioning Registry Protocol WG > > > > > > Time to send in agenda suggestions...there are some obvious ones, I > > won't disallow anyone from suggesting the obvious. ;) > > OK, then how about putting a slot in to get to the bottom of addressing the > IESG privacy comment -- assuming we can get the needed IESG members in the > room to get it settled. > > -Scott- > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SMqToE018644 for ; Fri, 28 Feb 2003 23:52:29 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SMqTN5018643 for ietf-provreg-outgoing; Fri, 28 Feb 2003 23:52:29 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SMqSoE018638 for ; Fri, 28 Feb 2003 23:52:28 +0100 (MET) Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h1SMqOmn027098; Fri, 28 Feb 2003 14:52:24 -0800 (PST) Date: Fri, 28 Feb 2003 14:52:29 -0800 (PST) From: Rick Wesson To: Edward Lewis cc: "'ietf-provreg@cafax.se'" , Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, The private discussion the wg chairs have had with the IESG have prevented this group from moving forward; therefore I request all communication between the IESG and the wg chairs also CC the list. We have experenced 4 month delay because of this situation and it is unacceptable. We still are in a state of limbo. ed, please restate the issues, proposed solutions, wg consensus (if any appears evident) and iesg issues in a single concise e-mail to this wg so we can at the very least understand where we are in this process, and how we can move it forward. thanks, -rick On Fri, 28 Feb 2003, Edward Lewis wrote: > I don't know that there's a proper response to this request. > Generally, I answer privately to private mail, publicly to public > mail. If anyone contacts me privately, I don't differentiate based > on IESG membership status. > > I use my judgement when it comes to deciding whether a conversation > is better served on the public list. The below referenced discussion > didn't yield ( or hasn't yet yielded) anything that would add to the > WG. > > At 9:45 -0800 2/18/03, Rick Wesson wrote: > >Ed, > > > > > >from this point further I request all corrispondance with the IESG be > >cc'ed to this list. This issue has dragged on in part because of > >gatekeeping by the chairs. > > > >If the IESG wants to stir the pot they need to include us in the > >converstaion. > > > >I hope this is the last time I will request this as standard opperating > >procedure. > > > >best, > > > >-rick > > > > > >> Funny you should mention the latter. Here are some snippets of a > >> mail exchange I had with a member of the IESG: > >> > >> >"Section 8.4 of RFC 3375. See the MUST part of [1]" > >> > >> Paraphrasing the context of that: the IESG feels that the EPP spec > >> does not meet this requirement. > >> > >> I replied: > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SKi2oE017321 for ; Fri, 28 Feb 2003 21:44:02 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SKi2tw017320 for ietf-provreg-outgoing; Fri, 28 Feb 2003 21:44:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SKi1oE017315 for ; Fri, 28 Feb 2003 21:44:01 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1SKhwqn073018; Fri, 28 Feb 2003 15:43:59 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA03859; Fri, 28 Feb 2003 15:43:58 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 28 Feb 2003 15:43:47 -0500 To: Rick Wesson From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I don't know that there's a proper response to this request. Generally, I answer privately to private mail, publicly to public mail. If anyone contacts me privately, I don't differentiate based on IESG membership status. I use my judgement when it comes to deciding whether a conversation is better served on the public list. The below referenced discussion didn't yield ( or hasn't yet yielded) anything that would add to the WG. At 9:45 -0800 2/18/03, Rick Wesson wrote: >Ed, > > >from this point further I request all corrispondance with the IESG be >cc'ed to this list. This issue has dragged on in part because of >gatekeeping by the chairs. > >If the IESG wants to stir the pot they need to include us in the >converstaion. > >I hope this is the last time I will request this as standard opperating >procedure. > >best, > >-rick > > >> Funny you should mention the latter. Here are some snippets of a >> mail exchange I had with a member of the IESG: >> >> >"Section 8.4 of RFC 3375. See the MUST part of [1]" >> >> Paraphrasing the context of that: the IESG feels that the EPP spec >> does not meet this requirement. >> >> I replied: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SJKqoE016465 for ; Fri, 28 Feb 2003 20:20:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SJKq49016464 for ietf-provreg-outgoing; Fri, 28 Feb 2003 20:20:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SJKpoE016459 for ; Fri, 28 Feb 2003 20:20:51 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA08772; Fri, 28 Feb 2003 14:20:43 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 14:20:47 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337075A@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Subject: RE: [ietf-provreg] our meeting slot in SF Date: Fri, 28 Feb 2003 14:20:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > THURSDAY, March 20, 2003 > 0900-1130 Morning Sessions > APP provreg Provisioning Registry Protocol WG > > > Time to send in agenda suggestions...there are some obvious ones, I > won't disallow anyone from suggesting the obvious. ;) OK, then how about putting a slot in to get to the bottom of addressing the IESG privacy comment -- assuming we can get the needed IESG members in the room to get it settled. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SIlEoE016101 for ; Fri, 28 Feb 2003 19:47:14 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1SIlEU0016100 for ietf-provreg-outgoing; Fri, 28 Feb 2003 19:47:14 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1SIlDoE016095 for ; Fri, 28 Feb 2003 19:47:13 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1SIlAqn067656 for ; Fri, 28 Feb 2003 13:47:10 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA14328; Fri, 28 Feb 2003 13:47:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Fri, 28 Feb 2003 13:35:11 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] our meeting slot in SF Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk THURSDAY, March 20, 2003 0900-1130 Morning Sessions APP provreg Provisioning Registry Protocol WG Time to send in agenda suggestions...there are some obvious ones, I won't disallow anyone from suggesting the obvious. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1OGEjoE019063 for ; Mon, 24 Feb 2003 17:14:45 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1OGEiYU019062 for ietf-provreg-outgoing; Mon, 24 Feb 2003 17:14:44 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1OGEhoE019057 for ; Mon, 24 Feb 2003 17:14:43 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1OGENtY030711; Mon, 24 Feb 2003 11:14:23 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302241614.h1OGENtY030711@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: [ietf-provreg] Re: Fwd: 56th IETF WG/BOF Scheduling In-Reply-To: Your message of "Thu, 09 Jan 2003 13:16:21 EST." Date: Mon, 24 Feb 2003 11:14:23 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Several people have asked me if I plan to attend -56. I'm not. I won't enter a TSA zone of control (e.g., US Airport) for any reasons other than family emergency. I passed through three TSA checkpoints on my travel to last week's meeting of the Domain Registrar Constituency, held jointly with several of the Domain Registries. I was subjected to special processing at two of the three checkpoints. The last time I flew PWD/NYC/WDC the same results obtained. Everyone's tolerance for this sort of thing is their own. Mine has simply been exceeded. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NLoqoE010479 for ; Sun, 23 Feb 2003 22:50:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NLoqMv010478 for ietf-provreg-outgoing; Sun, 23 Feb 2003 22:50:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NLonoE010473 for ; Sun, 23 Feb 2003 22:50:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1NLoatY028057; Sun, 23 Feb 2003 16:50:36 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302232150.h1NLoatY028057@nic-naa.net> To: Rick Wesson cc: Ram Mohan , "Hollenbeck, Scott" , "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Sun, 23 Feb 2003 11:20:47 PST." Date: Sun, 23 Feb 2003 16:50:36 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Rick, If rfc3375, sec. 8.4, [1], last sentance read: The protocol MUST provide services to identify registrant data publication policies. Instead of: The protocol MUST provide services to identify data collection policies. Then we'd share a common requirement statement. A friendly suggestion: pop some into a draft of 3375bis and get it with some similarly inclined co-authors in before the -00 cut date. Then we could discuss if 3375 erred (and we all know the putative error is mine). With 3375bis creating a registrant participant in EPP, we can look to the consequences, or if the scope of registrant-as-actor is limited to values. Comment #1: Regardless of the contents of a container, it does not allow any party to state the purpose, recipients, retention period, or access to the publication data, only some binary property of "disclosure". What does "disclose" mean? Comment #2: The we've got has a finite set of elements, each taking attribute values over a finite set, each with a mechanism to extend the set. I'll use to discuss, without unnecessary overspecification, the value space we're exploring, and who sets these values. If a arises from some party other than an EPP client or server, then it must take on values other than those defined between the EPP nodes, otherwise it has no independent existance. Example: if registrant_A sets to <1, 2, 3<2,2>>, and values of <0-I, 0-J, 0-K<0-L,0-M>> are within the repitoire of the registrar/registry, then there is no way of verifying that the registrar didn't set the value of to a value in its repitoire, in particular, <1, 2, 3<2,2>>. So, the registrant only becomes "visible" when s/he goes off-reservation and uses some portion of the value-space that is outside of the operational practice of the registrar/registry, either because they subset the maximal defined set of values, or because the registrant extends the maximal defined set of values. So, if the registrant creates a that is outside the space of values either defined in some standard or operational practice, then the registrant exists as an independent actor. So, that's the first awkwardness. The registrant must utter something that is a complete surprise to the registrar/registry, such as using "00" as a value for the ccType element, or defining (an extended utility type) a cc5Type with the length value 5, to allow codes outside of the 639:2 set of values, e.g., change "US" to "BUSH2". The second awkwardness is that for the registrant's access policy assertion to be non-fictional, it has to be capable of binding the conduct of some other actor, and for the conduct of that actor in varience of that policy to be detectable. So, to continue with the ccType example, the registrant would have to be able to cause an command response to be generated, and in particular, determine if the contact:postalInfoType's child element either has a value of "00" or type cc5Type. Alternatively, for valid values (subsetted by the operational practice of the registrar/registry), or valid extensions, valid values by the registrant would result in protocol errors generated by either the EPP client or server. So, what does a registrant bring to the party, and is it actually worth having? Suppose Randy wanted to no-disclosurer for his name as registrant of psg. If the exchange between Tucows and VGRS has what requirement hasn't been met? If it is then Tucows is free to error-out and fail the data propogation to VGRS. If the exchange between Randy and Tucows and VGRS has and for reasons discussed above, the semantic of is opaque to the EPP entities, under what set of circumstances could Tucows error out and fail the data propogation to VGRS? Only if VGRS generated an error? What if VGRS had an accept-all or refuse-any for non-empty elements? Why do we even need Randy to be involved in this ? If Randy can't do anything surprising, then we can whittle his set of choices down to {0,1}, without loss of generality. I don't play a lawyer on the net, but there are reasons why 46/95/EC et seq. has the exposure of the data collection policies of the data collector as the object of its descriptive focus. I believe in Satanism, mocking the IESG, depricating the brownie baking skills of Laura Bush, and that "empowering the registrant" is significantly harder than beliving in it. Worst ;-) Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NJKqoE009559 for ; Sun, 23 Feb 2003 20:20:52 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NJKqV4009558 for ietf-provreg-outgoing; Sun, 23 Feb 2003 20:20:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NJKooE009553 for ; Sun, 23 Feb 2003 20:20:51 +0100 (MET) Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h1NJKkmn018896; Sun, 23 Feb 2003 11:20:46 -0800 (PST) Date: Sun, 23 Feb 2003 11:20:47 -0800 (PST) From: Rick Wesson To: Ram Mohan cc: "Hollenbeck, Scott" , "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine , Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: <045001c2db38$d131f980$7700000a@afilias.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ram, On Sat, 22 Feb 2003, Ram Mohan wrote: > We're looking into a required policy for the .info registry; For the > .org registry, we're also trying to determine the appropriate technical > measures that would make PIR's proposed "OrgCloak" data-protection service > viable. > > A session-specific mandatory approach is appealing. I see how a registry might prefer the proposal, however I believe that the proposal, where a container allows the client to set which elements should not be disclosed. Though its simular to It potentially allows the registrant to decide which elements to protect. Also requires the policty to be set by the registry, and allows the policy to be set by the registrant. I believe empowering the registrant is the direction we should take. best -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NIumoE009424 for ; Sun, 23 Feb 2003 19:56:48 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NIumLk009423 for ietf-provreg-outgoing; Sun, 23 Feb 2003 19:56:48 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NIukoE009418 for ; Sun, 23 Feb 2003 19:56:47 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1NIuftY027625; Sun, 23 Feb 2003 13:56:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302231856.h1NIuftY027625@nic-naa.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Ram Mohan" cc: "Hollenbeck, Scott" , "'Edward Lewis'" , "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message from "Ram Mohan" of "Sat, 22 Feb 2003 14:19:52 EST." <045001c2db38$d131f980$7700000a@afilias.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Feb 2003 13:56:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > We're looking into a required policy for the .info registry; For the > .org registry, we're also trying to determine the appropriate technical > measures that would make PIR's proposed "OrgCloak" data-protection service > viable. Good. Let me know if you want my help. >A session-specific mandatory approach is appealing. I'm glad you think so. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NCg1oE007617 for ; Sun, 23 Feb 2003 13:42:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1NCg1tR007616 for ietf-provreg-outgoing; Sun, 23 Feb 2003 13:42:01 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1NCg0oE007611 for ; Sun, 23 Feb 2003 13:42:00 +0100 (MET) Received: from eagle (pcp01379381pcs.levtwn01.pa.comcast.net [68.81.94.117]) (authenticated) by ns01.afilias.info (8.11.6/8.11.6) with ESMTP id h1NCfMa11648; Sun, 23 Feb 2003 07:41:22 -0500 Message-ID: <045001c2db38$d131f980$7700000a@afilias.com> From: "Ram Mohan" To: "Hollenbeck, Scott" , "'Edward Lewis'" , "Eric Brunner-Williams in Portland Maine" Cc: References: <3CD14E451751BD42BA48AAA50B07BAD603370696@vsvapostal3.prod.netsol.com> Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Sat, 22 Feb 2003 14:19:52 -0500 Organization: Afilias MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-provreg@cafax.se Precedence: bulk >If you're not publishing a data >collection policy, is there any specific issue that's driving that decision? >I haven't decided what makes sense for the .com and .net registry yet, but >other people who are using EPP in domain registry operations must have been >through a decision process. Come on, people, please let us know what you're >doing with respect to privacy and data collection and why you're doing it! >We need some real data points to help close the discussion with the IESG. We're looking into a required policy for the .info registry; For the .org registry, we're also trying to determine the appropriate technical measures that would make PIR's proposed "OrgCloak" data-protection service viable. A session-specific mandatory approach is appealing. -ram ----- Original Message ----- From: "Hollenbeck, Scott" To: "'Edward Lewis'" ; "Eric Brunner-Williams in Portland Maine" Cc: Sent: Thursday, February 13, 2003 9:56 AM Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry > > This is a good request. This is one of the missing pieces of the > > converstation. > > > > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: > > >> The WG should note that implementers of real-world > > privacy policies are > > >> finding it necessary to add a "do not disclose" element. > > > > > >Could someone, possibly an implementor, comment on the > > design choice that > > >did not utilize the element, and disclose its > > deficiencies? I can > > >guess, but it would be nice to hear from someone else who > > considered it > > >and found it failed to meet a requirement. > > Is Eric's request behind a thought that we are considering either the > current DCP functionality, or the "do not disclose"-proposed functionality, > but not both? I can easily see a need for both: > > - in some environments, it might be OK for the server operator to say "this > is what I will/might do with data, and if you as data originator give me > data you are agreeing to my policy". We have this in the protocol right now > with the element. > > - in other environments, it might be OK for the data owner to say "this is > what I will allow you as server operator to do with the data I share with > you". I thought some of the European contributors have said this sort of > functionality is required under recent European privacy laws. This is > something we don't currently have in the protocol. > > I'm not sure that this is a "pick one or the other" situation, but I'm also > interested in implementer perspectives. If you're not publishing a data > collection policy, is there any specific issue that's driving that decision? > > I haven't decided what makes sense for the .com and .net registry yet, but > other people who are using EPP in domain registry operations must have been > through a decision process. Come on, people, please let us know what you're > doing with respect to privacy and data collection and why you're doing it! > We need some real data points to help close the discussion with the IESG. > > -Scott- > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IL8CoE013962 for ; Tue, 18 Feb 2003 22:08:12 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IL8CPu013961 for ietf-provreg-outgoing; Tue, 18 Feb 2003 22:08:12 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IL8AoE013953 for ; Tue, 18 Feb 2003 22:08:10 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1IL96tY008082; Tue, 18 Feb 2003 16:09:06 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302182109.h1IL96tY008082@nic-naa.net> To: Rick Wesson cc: Edward Lewis , "Hollenbeck, Scott" , "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 18 Feb 2003 09:45:12 PST." Date: Tue, 18 Feb 2003 16:09:06 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Is it the co-chairs or is it us? Digression. From -47 through -49 I worked for Engage, a company that had some value proposition associated with http cookies, the results of this were contributions to draft-jaye-http-state-mgt-nn.txt, contributions to the W3C's P3P spec (in particular, the mechanism and semantic scope from -jaye- to cookies), and the Customer Profile Exchange (CPex) trade body standard for onward transport of customer profiles (wicked close to what EPP is all about, minus the ICANN psychoactive drugs), to cookie handling done in IE 5.5 et seq, and to draft-ietf-http-state-man-mec (rfc2965). So, I had a modest exposure to a particular problem domain, and had some reason to think that http's state management mechanism provided a mechanism for sophisticated 3rd-party involvement in the http client-server model, not entirely limited to Satan Worship, animal sacrifice, popups or banner ads. I mentioned at the Plenary in Pittsburg (-48) that the IESG's note on the subject (draft-iesg-http-cookies-nn.txt) was in need of some contribution from people with subject matter expertise. [People who's 9-5 was cookies, demographics, profiling, and of course, Devil Worship.] From the podium, Fred Baker was quick to agree that not all clue resided on his side of the table. Yeah Fred! The next day I went in search of the authors, both the Apps Area ADs (then). One blew me off, with attitude. The other informed me that he knew more than I did, and the majority (of some group) was on his side. This latter exchange happened with John Klensin as an onlooker, which is one reason why John and I are friends, though we disagree on the polarity of gravity. So, draft-iesg-http-cookies-nn.txt became bcp44 and rfc2964, without any further distractions to its authors. There is a quote from the back of Mike Padlipsky's "Elements" that is appropos: Just because you are Constitutionally entitled to a personal opinion doesn't mean you're constitutionally entitiled to a professional opinion. So, here we are, presumably possessed of at least enough clue to start a fire using only damp bits of XML, stopped dead in our tracks for about a half-year, by stuff that appears to be fairly aged roadkill. Is it (a) the co-chairs' fault (and I've issues there, which are neither here nor there), or is it (b) our fault? I'm inclined to (b). 2026, in particular section 6.5.4, provides an appeal procedure. If the working group fails to get either (a) adequate progress, or (b) grounds to advance an appeal under section 6.5.4 of 2026, then the working group is technically done, and has exhausted the process mechanisms it has consensus to exploit. The idea that the IESG can function like line-noise is sort of endearing. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IHjIoE012421 for ; Tue, 18 Feb 2003 18:45:18 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IHjIZV012420 for ietf-provreg-outgoing; Tue, 18 Feb 2003 18:45:18 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IHjGoE012415 for ; Tue, 18 Feb 2003 18:45:17 +0100 (MET) Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h1IHjDmn029682; Tue, 18 Feb 2003 09:45:13 -0800 (PST) Date: Tue, 18 Feb 2003 09:45:12 -0800 (PST) From: Rick Wesson To: Edward Lewis cc: "Hollenbeck, Scott" , "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, from this point further I request all corrispondance with the IESG be cc'ed to this list. This issue has dragged on in part because of gatekeeping by the chairs. If the IESG wants to stir the pot they need to include us in the converstaion. I hope this is the last time I will request this as standard opperating procedure. best, -rick > Funny you should mention the latter. Here are some snippets of a > mail exchange I had with a member of the IESG: > > >"Section 8.4 of RFC 3375. See the MUST part of [1]" > > Paraphrasing the context of that: the IESG feels that the EPP spec > does not meet this requirement. > > I replied: Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IDEaoE009783 for ; Tue, 18 Feb 2003 14:14:37 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IDEa4f009782 for ietf-provreg-outgoing; Tue, 18 Feb 2003 14:14:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IDEZoE009777 for ; Tue, 18 Feb 2003 14:14:35 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h1IDFetY006868; Tue, 18 Feb 2003 08:15:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302181315.h1IDFetY006868@nic-naa.net> To: Edward Lewis cc: "Hollenbeck, Scott" , "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 18 Feb 2003 11:12:58 +0800." Date: Tue, 18 Feb 2003 08:15:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk ... >Then the exact syntax etc for this DCP element MUST be described and included, >because another requirement is that the protocol must be able to work without >human intervention (I think the word used is "automatic"). There's a schema. ... > No further happened on the exchange. I thought they were going down a substantive path, such as changing the implementation requirement from optional to manditory, or a manditory pervasive (or scoped) leaf attribute, or ... or just buggering off until they had something technical to contribute. Aside #1. Wearing my I'm-a-registrar-and-I'm-OK hat, I posted a note to to the registrars constituency mailing list on our present quandry. Nothing yet from the gTLD registrar business|requirements parties, so all of this may be a non-issue. The RC will be meeting at the end of this week, if enough Swiss dogs can be found to get us through the snows of Washington and policy requirements for operation in the EU is on the agenda. Aside #2. The geo-blah WG's docs (spam has local context, aluminum-hats and its converse, advertizing, still have mind-share) focus on the preferences of data originators, and not on the policies of data collectors. The addition of a half-room of a mixed bag of groan-bots and greed-bots, who are originator-aware (trans: registrant-aware), transport-unaware (trans: reseller/registrar/registry-unaware), won't improve the work attempted at the face-to-face. What happened to our WG-only interim via-voca? If it fell victim to duct-tape madness in the Beltway, it is time to give it oxygen. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1ICV5oE009430 for ; Tue, 18 Feb 2003 13:31:05 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1ICV4cM009429 for ietf-provreg-outgoing; Tue, 18 Feb 2003 13:31:04 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1ICV3oE009424 for ; Tue, 18 Feb 2003 13:31:04 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA24271; Tue, 18 Feb 2003 07:30:45 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7P2C2Z>; Tue, 18 Feb 2003 07:30:49 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033706B8@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" Cc: "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Tue, 18 Feb 2003 07:30:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >Then the exact syntax etc for this DCP element MUST be > described and included, > >because another requirement is that the protocol must be > able to work without > >human intervention (I think the word used is "automatic"). > > My response: > > >If you want a better definition of the dcp, that can be > brought to the group. > >Looking through the base spec, the dcp is discussed, I > assume the IESG feels > >that it is not presented well enough. > > No further happened on the exchange. I'd certainly like to pursue this. The exact syntax is described completely in the schema, and each element is described in the text. If we can beef this up to address the IESG's concern then I'm all for it, but I'd like to know where they feel something is lacking. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IAPLoE008558 for ; Tue, 18 Feb 2003 11:25:21 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1IAPK68008557 for ietf-provreg-outgoing; Tue, 18 Feb 2003 11:25:20 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1IAPHoE008552 for ; Tue, 18 Feb 2003 11:25:17 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1IAPEqn078080; Tue, 18 Feb 2003 05:25:14 -0500 (EST) Received: from [220.128.48.47] ([192.136.136.113]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id FAA16215; Tue, 18 Feb 2003 05:25:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> Date: Tue, 18 Feb 2003 11:12:58 +0800 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "'Eric Brunner-Williams in Portland Maine'" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:42 -0500 2/13/03, Hollenbeck, Scott wrote: >Well, I agree with that -- the IESG is saying they want to see some sort of >"mandatory to implement" functionality. Should we be trying to convince the >IESG that the DCP features address their concerns, or do we need to add >something else? Funny you should mention the latter. Here are some snippets of a mail exchange I had with a member of the IESG: >"Section 8.4 of RFC 3375. See the MUST part of [1]" Paraphrasing the context of that: the IESG feels that the EPP spec does not meet this requirement. I replied: >But I bet a lot will feel that this passage from the base spec: > ># "- An OPTIONAL (data collection policy) element that contains ># child elements used to describe the server's policy for data ># collection and management." > >shows that we've already met the requirement. And got this reply: >Then the exact syntax etc for this DCP element MUST be described and included, >because another requirement is that the protocol must be able to work without >human intervention (I think the word used is "automatic"). My response: >If you want a better definition of the dcp, that can be brought to the group. >Looking through the base spec, the dcp is discussed, I assume the IESG feels >that it is not presented well enough. No further happened on the exchange. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1EJqPoE005756 for ; Fri, 14 Feb 2003 20:52:25 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1EJqP2w005755 for ietf-provreg-outgoing; Fri, 14 Feb 2003 20:52:25 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1EJqNoE005750 for ; Fri, 14 Feb 2003 20:52:24 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1EJqMqn025266; Fri, 14 Feb 2003 14:52:22 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.106]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA21394; Fri, 14 Feb 2003 14:52:22 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: Date: Fri, 14 Feb 2003 14:49:36 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] just to let y'all know Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I want to keep up to date with the current discussion, but I'll be unavailable for a few days - I'm travelling to APRICOT. The 'black out' is a bit longer as we'll be setting up for the pre-conference tutorials and I don't know when the IP will be turned on... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DKHvoE023697 for ; Thu, 13 Feb 2003 21:17:57 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DKHvRn023696 for ietf-provreg-outgoing; Thu, 13 Feb 2003 21:17:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DKHtoE023691 for ; Thu, 13 Feb 2003 21:17:55 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DKIu9r007895; Thu, 13 Feb 2003 15:18:56 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302132018.h1DKIu9r007895@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Eric Brunner-Williams in Portland Maine'" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Thu, 13 Feb 2003 14:42:29 EST." <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> Date: Thu, 13 Feb 2003 15:18:56 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > - in other environments, it might be OK for the data owner > > to say "this is > > > what I will allow you as server operator to do with the > > data I share with > > > you". I thought some of the European contributors have > > said this sort of > > > functionality is required under recent European privacy > > laws. This is > > > something we don't currently have in the protocol. > > > > Disagree. The states the purpose, recipients, > > access-right (of the data > > owner), and retention period, of the policed session in which > > some data will > > conditionally flow. For a server to offer ... , > > it need only > > cycle these through a fairly small value-space to find the > > least-restrictive > > policy to which the client (and presumably the registrant) > > are willing to > > accept. APPEL attempts this, and the P3P WG attempted, and > > abandoned for 1.0, > > a negociation or owner-preference signaling mechanism. > > Remembering our original discussions of your data collection policy proposal > I know you disagree ;-). On selection: Assume N instances of the server, each offering a distinct value, or one, cycling through a set of N distinct values, or N distinct registries, each offering a single distinct value. On agency (who selects): EPP defines exchanges between registrars and registries, so "data owner" (originator) is not a direct actor. > ... What I'm trying to understand is why some > implementers and others (including, apparently, the IESG) don't agree that > it's sufficient. What's driving the perceived need for a client-delivered > "do not publish" notification? Is the spec not clear enough, or is the > mechanism inadequate? The mechanism is optional. That might be the burr under some blankets. Flip that bit and test again. > > > I'm not sure that this is a "pick one or the other" situation, > > > > Disagree. See above. Manditory beats optional (IESG's point), > > regardless of > > utility. > > Well, I agree with that -- the IESG is saying they want to see some sort of > "mandatory to implement" functionality. Should we be trying to convince the > IESG that the DCP features address their concerns, or do we need to add > something else? OK. Lets talk about making the M2I, and either leaving it at session scope, and see if anyone can live with it. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJgboE023225 for ; Thu, 13 Feb 2003 20:42:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DJgagu023224 for ietf-provreg-outgoing; Thu, 13 Feb 2003 20:42:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJgZoE023219 for ; Thu, 13 Feb 2003 20:42:36 +0100 (MET) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA13000; Thu, 13 Feb 2003 14:42:24 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7S4W8B>; Thu, 13 Feb 2003 14:40:18 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337069D@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" Cc: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 13 Feb 2003 14:42:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > - in other environments, it might be OK for the data owner > to say "this is > > what I will allow you as server operator to do with the > data I share with > > you". I thought some of the European contributors have > said this sort of > > functionality is required under recent European privacy > laws. This is > > something we don't currently have in the protocol. > > Disagree. The states the purpose, recipients, > access-right (of the data > owner), and retention period, of the policed session in which > some data will > conditionally flow. For a server to offer ... , > it need only > cycle these through a fairly small value-space to find the > least-restrictive > policy to which the client (and presumably the registrant) > are willing to > accept. APPEL attempts this, and the P3P WG attempted, and > abandoned for 1.0, > a negociation or owner-preference signaling mechanism. Remembering our original discussions of your data collection policy proposal I know you disagree ;-). What I'm trying to understand is why some implementers and others (including, apparently, the IESG) don't agree that it's sufficient. What's driving the perceived need for a client-delivered "do not publish" notification? Is the spec not clear enough, or is the mechanism inadequate? > > I'm not sure that this is a "pick one or the other" situation, > > Disagree. See above. Manditory beats optional (IESG's point), > regardless of > utility. Well, I agree with that -- the IESG is saying they want to see some sort of "mandatory to implement" functionality. Should we be trying to convince the IESG that the DCP features address their concerns, or do we need to add something else? -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJRooE023054 for ; Thu, 13 Feb 2003 20:27:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DJRosI023053 for ietf-provreg-outgoing; Thu, 13 Feb 2003 20:27:50 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DJRnoE023048 for ; Thu, 13 Feb 2003 20:27:49 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DJSo9r007751; Thu, 13 Feb 2003 14:28:50 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302131928.h1DJSo9r007751@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Thu, 13 Feb 2003 09:56:54 EST." <3CD14E451751BD42BA48AAA50B07BAD603370696@vsvapostal3.prod.netsol.com> Date: Thu, 13 Feb 2003 14:28:50 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > This is a good request. This is one of the missing pieces of the > > converstation. > > > > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: > > >> The WG should note that implementers of real-world > > privacy policies are > > >> finding it necessary to add a "do not disclose" element. > > > > > >Could someone, possibly an implementor, comment on the > > design choice that > > >did not utilize the element, and disclose its > > deficiencies? I can > > >guess, but it would be nice to hear from someone else who > > considered it > > >and found it failed to meet a requirement. > > Is Eric's request behind a thought that we are considering either the > current DCP functionality, or the "do not disclose"-proposed functionality, > but not both? I can easily see a need for both: I'm a little more transparent than that. Jay Random-Implementor decided to do something novel. However, assume non-uniqueness of mechanism, and non-uniformity of existence, with no fewer than one mechanism defined to be "manditory to implement". What results are forseeable, asumming anything can be forseen? > - in some environments, it might be OK for the server operator to say "this > is what I will/might do with data, and if you as data originator give me > data you are agreeing to my policy". We have this in the protocol right now > with the element. Agreed. The announced data collection policy of the server allows the client to policy-based selection among servers. > - in other environments, it might be OK for the data owner to say "this is > what I will allow you as server operator to do with the data I share with > you". I thought some of the European contributors have said this sort of > functionality is required under recent European privacy laws. This is > something we don't currently have in the protocol. Disagree. The states the purpose, recipients, access-right (of the data owner), and retention period, of the policed session in which some data will conditionally flow. For a server to offer ... , it need only cycle these through a fairly small value-space to find the least-restrictive policy to which the client (and presumably the registrant) are willing to accept. APPEL attempts this, and the P3P WG attempted, and abandoned for 1.0, a negociation or owner-preference signaling mechanism. The EU DP policy requirement contributions to the W3C's P3P WG and to ccTLD registry operators, and/or gTLD interested parties, could be different. > I'm not sure that this is a "pick one or the other" situation, Disagree. See above. Manditory beats optional (IESG's point), regardless of utility. > ... but I'm also > interested in implementer perspectives. If you're not publishing a data > collection policy, is there any specific issue that's driving that decision? Agree. I can understand why a company operating under the jurisdiction of the FTC would NOT want to go beyond the regulatory minima specific to its industry, as to do so would create an unnecessary duty , or take the opt-in side, before it (ever) becomes law. I can understand why a company operating under the jurisdiction of ICANN would NOT want to suggest that the ICANN WHOIS TF profoundly lacks clue. (Their latest proposal requires registrants to respond to postal or fax spam, not just email spam.) > I haven't decided what makes sense for the .com and .net registry yet, but > other people who are using EPP in domain registry operations must have been > through a decision process. Come on, people, please let us know what you're > doing with respect to privacy and data collection and why you're doing it! > We need some real data points to help close the discussion with the IESG. Agree. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DI7boE022305 for ; Thu, 13 Feb 2003 19:07:37 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DI7bVr022304 for ietf-provreg-outgoing; Thu, 13 Feb 2003 19:07:37 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DI7ZoE022299 for ; Thu, 13 Feb 2003 19:07:36 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DI8Y9r007569; Thu, 13 Feb 2003 13:08:34 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302131808.h1DI8Y9r007569@nic-naa.net> To: Edward Lewis cc: "Hollenbeck, Scott" , "'janusz sienkiewicz'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: [ietf-provreg] Is it "social" or is it "model" or is it "mechanism"? Date: Thu, 13 Feb 2003 13:08:34 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Oki all, Back when Ross wrote "Domain Name and Related Definitions", and the latest copy I have squirreled away in my cache of nuts is -dn-defn-01, May '01 [1], the defintion offered for "social" and "technical" data was couched in the language defining the "thick" and "thin" registry models, viz: Registry, Thick: A registry in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices), is stored within the registry repository. and Registry, Thin: A registry in which some element of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry. So in -dn-defn- the model constructed the distinction. Alternatives models include alternative domain registries, not just the ICANN gTLD set, and registries that aren't domain registries that may have a shared-registry model that is object-indifferent. An alternative to the SRS model constructing what we mean by data of type 1 and type 2 is to look to the publication mechanism(s). We use 1034/35, and don't mention 954. An alternative to publication mechanism(s) as a means of constructing data types (e.g., "social" or "technical"), is meta-data associated with the data, an approach that is common to both the element form I've proposed, and the attribute form the IESG proposes. A surprisingly large amount of stuff can be published by 1034/35. We could tighten up "information needed to produce zone files". A surprisingly large amount of stuff can be published by 954. We could tighten up "information needed to implement operational, business, or legal practices". More care in specification of what is published by 1034/35, and what is published by 954, doesn't cover publication by other means. It doesn't cover bulk-transfer. The element in the does. Additionally, it doesn't cover correctness, which is equivalent to defining which instance of a datum is authoritative, and how cache instances of a datum are made consistent with the authoritative copy. The element in the does. Additionally, it doesn't cover how long any party (reseller, registrar, registry, others not described, e.g., ICANN escrow agents) retains any datum, nor what purposes it uses the datum for during each's period of retention. The and the elements in the , respectively, does. The IESG's attribute provides a binary mechanism for typing. This has the same limitation as the "more care in specification" approach, and if scoped, as Scott suggested yesterday, simply reduces those limitations to a smaller collection of datums -- subsets of the current EPP schemas. Eric [1] draft-ietf-provreg-dn-defn-01.txt, expired Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DEuxoE020117 for ; Thu, 13 Feb 2003 15:56:59 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DEuxZQ020116 for ietf-provreg-outgoing; Thu, 13 Feb 2003 15:56:59 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DEuvoE020111 for ; Thu, 13 Feb 2003 15:56:58 +0100 (MET) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA26347; Thu, 13 Feb 2003 09:56:49 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7S4S6D>; Thu, 13 Feb 2003 09:54:43 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370696@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , Eric Brunner-Williams in Portland Maine Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 13 Feb 2003 09:56:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This is a good request. This is one of the missing pieces of the > converstation. > > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: > >> The WG should note that implementers of real-world > privacy policies are > >> finding it necessary to add a "do not disclose" element. > > > >Could someone, possibly an implementor, comment on the > design choice that > >did not utilize the element, and disclose its > deficiencies? I can > >guess, but it would be nice to hear from someone else who > considered it > >and found it failed to meet a requirement. Is Eric's request behind a thought that we are considering either the current DCP functionality, or the "do not disclose"-proposed functionality, but not both? I can easily see a need for both: - in some environments, it might be OK for the server operator to say "this is what I will/might do with data, and if you as data originator give me data you are agreeing to my policy". We have this in the protocol right now with the element. - in other environments, it might be OK for the data owner to say "this is what I will allow you as server operator to do with the data I share with you". I thought some of the European contributors have said this sort of functionality is required under recent European privacy laws. This is something we don't currently have in the protocol. I'm not sure that this is a "pick one or the other" situation, but I'm also interested in implementer perspectives. If you're not publishing a data collection policy, is there any specific issue that's driving that decision? I haven't decided what makes sense for the .com and .net registry yet, but other people who are using EPP in domain registry operations must have been through a decision process. Come on, people, please let us know what you're doing with respect to privacy and data collection and why you're doing it! We need some real data points to help close the discussion with the IESG. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDWBoE019302 for ; Thu, 13 Feb 2003 14:32:11 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DDWBrh019301 for ietf-provreg-outgoing; Thu, 13 Feb 2003 14:32:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDW9oE019296 for ; Thu, 13 Feb 2003 14:32:09 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1DDXD9r006868; Thu, 13 Feb 2003 08:33:13 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302131333.h1DDXD9r006868@nic-naa.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Message from Edward Lewis of "Wed, 12 Feb 2003 13:44:22 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 08:33:13 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Posting the schema diff wouldn't hurt either. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDUQoE019261 for ; Thu, 13 Feb 2003 14:30:26 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DDUQw5019259 for ietf-provreg-outgoing; Thu, 13 Feb 2003 14:30:26 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDUOoE019253 for ; Thu, 13 Feb 2003 14:30:25 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1DDUOqn078301; Thu, 13 Feb 2003 08:30:24 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.57]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA04052; Thu, 13 Feb 2003 08:30:23 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD603370673@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD603370673@vsvapostal3.prod.netsol.com> Date: Wed, 12 Feb 2003 13:47:10 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "'janusz sienkiewicz'" , "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yeah, where I see a conflict is that the original comment is: "why do domain/contact/.. not have granular information about privacy?" The comment itself constrains where there is a concern about privacy metadata. It seems to me that the only real sensitivity is to social data ("in principle" as we haven't come to a formal and clear definition of what that means - as EBW points out), but the comment doesn't hint at this. At 11:52 -0500 2/11/03, Hollenbeck, Scott wrote: >> I would suggest going even further. could be >> restricted to >> social data only. That practically would restrict the element >> to contact >> mapping only. applied in domain or host >> mapping could lead to >> ambigous usage. For example: > >[snip] > >I suggested this possibility to the IESG back when the topic first came up. >They've disagreed so far, with the reason being that we're moving from >technology to policy as soon as we try to interpret where it makes sense. > >-Scott- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDURoE019267 for ; Thu, 13 Feb 2003 14:30:27 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1DDURVW019266 for ietf-provreg-outgoing; Thu, 13 Feb 2003 14:30:27 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1DDUPoE019257 for ; Thu, 13 Feb 2003 14:30:26 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1DDUNqn078298; Thu, 13 Feb 2003 08:30:23 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.57]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA04032; Thu, 13 Feb 2003 08:30:22 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: In-Reply-To: <200302111602.h1BG2AUS035823@nic-naa.net> References: <200302111602.h1BG2AUS035823@nic-naa.net> Date: Wed, 12 Feb 2003 13:44:22 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Cc: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a good request. This is one of the missing pieces of the converstation. At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote: >> The WG should note that implementers of real-world privacy policies are >> finding it necessary to add a "do not disclose" element. > >Could someone, possibly an implementor, comment on the design choice that >did not utilize the element, and disclose its deficiencies? I can >guess, but it would be nice to hear from someone else who considered it >and found it failed to meet a requirement. > >Eric -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BHMroE027576 for ; Tue, 11 Feb 2003 18:22:53 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BHMrB7027575 for ietf-provreg-outgoing; Tue, 11 Feb 2003 18:22:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BHMpoE027570 for ; Tue, 11 Feb 2003 18:22:52 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1BHNGUS036077; Tue, 11 Feb 2003 12:23:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302111723.h1BHNGUS036077@nic-naa.net> To: janusz sienkiewicz cc: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 11 Feb 2003 11:57:05 EST." <3E492B60.7887F48B@libertyrms.info> Date: Tue, 11 Feb 2003 12:23:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I would suggest going even further. could be restricted to > social data only. We all know what social data is, but do we? Ross had a definitial ID on this earlier, it has been let lapse, because we'd currently no mechanism which is dependent upon this. So, I suggest a definition of SD is useful (again). > ... That practically would restrict the element to contact > mapping only. It makes no sense to speak of "privacy" or "data protection" of domain or host objects. Nor of contacts that aren't persons (not legal fictions). Not in 95/46/EU, nor OEDC Guidelines, nor FTC lack-of-rules frameworks. > ... applied in domain or host mapping could lead to > ambigous usage. For example: > > > > > > may not be necessary be a privacy statement. It could be a DNS policy statement > as well. Correct. This has nothing to do with privacy, it has everything to do with secret-buys, a product. You can buy "secret-product-name.foo" and only your registrar and registry will know, until you "go public". > I don't see any problem with handling very unlikely and potentially ambigous > privacy statements (domain or host object mapping) within EPP extensions. The > protocol would still offer reasonable level of _INTEROPERATIBILITY_. They should return errors. EPP provisions 1034/35 publication systems, and some possible other publication systems. If someone wants a string-space management protocol, with secret-exhaustion semantics, let them go somewhere else, its a distraction from the real issue, publication via 954 and 954bis. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGufoE027254 for ; Tue, 11 Feb 2003 17:56:41 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BGufsc027253 for ietf-provreg-outgoing; Tue, 11 Feb 2003 17:56:41 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGudoE027248 for ; Tue, 11 Feb 2003 17:56:40 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA27831; Tue, 11 Feb 2003 11:56:32 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7PA5MP>; Tue, 11 Feb 2003 11:52:42 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370673@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'janusz sienkiewicz'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Tue, 11 Feb 2003 11:52:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I would suggest going even further. could be > restricted to > social data only. That practically would restrict the element > to contact > mapping only. applied in domain or host > mapping could lead to > ambigous usage. For example: [snip] I suggested this possibility to the IESG back when the topic first came up. They've disagreed so far, with the reason being that we're moving from technology to policy as soon as we try to interpret where it makes sense. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGjhoE027127 for ; Tue, 11 Feb 2003 17:45:43 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BGjhBB027126 for ietf-provreg-outgoing; Tue, 11 Feb 2003 17:45:43 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BGjgoE027121 for ; Tue, 11 Feb 2003 17:45:42 +0100 (MET) Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18idXN-0007cn-00; Tue, 11 Feb 2003 11:45:37 -0500 Message-ID: <3E492B60.7887F48B@libertyrms.info> Date: Tue, 11 Feb 2003 11:57:05 -0500 From: janusz sienkiewicz Organization: LibertyRMS Co. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686) X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry References: <3CD14E451751BD42BA48AAA50B07BAD603370665@vsvapostal3.prod.netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Please see my comments below: "Hollenbeck, Scott" wrote: > > At the DNR-forum at RIPE-44 last week, the polish registry presented > > their implementation of EPP. They had to make extensions to implement > > the somewhat draconian Polish privacy rules. One of the things they > > mentioned was that they were more severe then the European ones, > > so when they join the EC, they might change. Anyway, I don't have > > the presentation on line yet, but they have piblished a document > > about the things they did with the protocol. It can be found as > > ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf > > (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web. > > While at the CENTR technical forum I listened intently to these and other > presentations to see how they relate to our ongoing discussion of privacy > specification and the unresolved comment from the IESG. The extensions > described by the folks from NASK include an element that directly relates to > the IESG comments: their element is described as "it > specifies whether a private person gives its permission to publish personal > details in WHOIS database". > > We now have two ccTLD registry operators (.pl (above) and .nl (via Jaap)) > who've noted that having a "do not disclose" flag is something that they > need and can use. In the case of .pl, where they claim to have very strict > privacy rules, implementers found that a single high-level element was > sufficient to mark the content appropriately. If we had a "do not disclose" > element in the contact mapping they probably wouldn't have had to add this > extension. > > In the spirit of "rough consensus and running code", maybe this is a > reasonable compromise. We have registries implementing privacy policies > that need some sort of "do not disclose" marker, but maybe we don't really > need to mark every element -- maybe having an optional > element in the various , , and structures is all > that's really needed in the real world. I'd like to ask the WG members and > the IESG to consider this possibility. I would suggest going even further. could be restricted to social data only. That practically would restrict the element to contact mapping only. applied in domain or host mapping could lead to ambigous usage. For example: may not be necessary be a privacy statement. It could be a DNS policy statement as well. I don't see any problem with handling very unlikely and potentially ambigous privacy statements (domain or host object mapping) within EPP extensions. The protocol would still offer reasonable level of _INTEROPERATIBILITY_. > > > The WG should note that implementers of real-world privacy policies are > finding it necessary to add a "do not disclose" element. > > The IESG should note that implementers of real-world privacy policies are > finding it sufficient to flag a higher-level structure instead of flagging > individual elements. > > Is this a possible way forward? > > -Scott- Janusz Sienkiewicz Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BG1koE026647 for ; Tue, 11 Feb 2003 17:01:46 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BG1kcj026646 for ietf-provreg-outgoing; Tue, 11 Feb 2003 17:01:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BG1joE026641 for ; Tue, 11 Feb 2003 17:01:45 +0100 (MET) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h1BG2AUS035823; Tue, 11 Feb 2003 11:02:10 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302111602.h1BG2AUS035823@nic-naa.net> To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Tue, 11 Feb 2003 08:30:20 EST." <3CD14E451751BD42BA48AAA50B07BAD603370665@vsvapostal3.prod.netsol.com> Date: Tue, 11 Feb 2003 11:02:10 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The WG should note that implementers of real-world privacy policies are > finding it necessary to add a "do not disclose" element. Could someone, possibly an implementor, comment on the design choice that did not utilize the element, and disclose its deficiencies? I can guess, but it would be nice to hear from someone else who considered it and found it failed to meet a requirement. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BDYUoE025177 for ; Tue, 11 Feb 2003 14:34:30 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h1BDYUcx025176 for ietf-provreg-outgoing; Tue, 11 Feb 2003 14:34:30 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h1BDYSoE025171 for ; Tue, 11 Feb 2003 14:34:28 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA13681 for ; Tue, 11 Feb 2003 08:34:21 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1V7PASAX>; Tue, 11 Feb 2003 08:30:31 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370665@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Tue, 11 Feb 2003 08:30:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > At the DNR-forum at RIPE-44 last week, the polish registry presented > their implementation of EPP. They had to make extensions to implement > the somewhat draconian Polish privacy rules. One of the things they > mentioned was that they were more severe then the European ones, > so when they join the EC, they might change. Anyway, I don't have > the presentation on line yet, but they have piblished a document > about the things they did with the protocol. It can be found as > ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf > (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web. While at the CENTR technical forum I listened intently to these and other presentations to see how they relate to our ongoing discussion of privacy specification and the unresolved comment from the IESG. The extensions described by the folks from NASK include an element that directly relates to the IESG comments: their element is described as "it specifies whether a private person gives its permission to publish personal details in WHOIS database". We now have two ccTLD registry operators (.pl (above) and .nl (via Jaap)) who've noted that having a "do not disclose" flag is something that they need and can use. In the case of .pl, where they claim to have very strict privacy rules, implementers found that a single high-level element was sufficient to mark the content appropriately. If we had a "do not disclose" element in the contact mapping they probably wouldn't have had to add this extension. In the spirit of "rough consensus and running code", maybe this is a reasonable compromise. We have registries implementing privacy policies that need some sort of "do not disclose" marker, but maybe we don't really need to mark every element -- maybe having an optional element in the various , , and structures is all that's really needed in the real world. I'd like to ask the WG members and the IESG to consider this possibility. The WG should note that implementers of real-world privacy policies are finding it necessary to add a "do not disclose" element. The IESG should note that implementers of real-world privacy policies are finding it sufficient to flag a higher-level structure instead of flagging individual elements. Is this a possible way forward? -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GnvoE026685 for ; Mon, 3 Feb 2003 17:49:57 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h13GnvUE026684 for ietf-provreg-outgoing; Mon, 3 Feb 2003 17:49:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GnuoE026679 for ; Mon, 3 Feb 2003 17:49:56 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h13Gn8RS050337; Mon, 3 Feb 2003 11:49:08 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302031649.h13Gn8RS050337@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] Resend: Just checking ... In-Reply-To: Your message of "Mon, 03 Feb 2003 11:05:31 EST." Date: Mon, 03 Feb 2003 11:49:08 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >Are any other mechanisms proposed? > > I think you've got the proposed mechanisms... OK. Thanks for the ACK. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GakoE026583 for ; Mon, 3 Feb 2003 17:36:46 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h13GakYp026582 for ietf-provreg-outgoing; Mon, 3 Feb 2003 17:36:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h13GahoE026577 for ; Mon, 3 Feb 2003 17:36:43 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h13GaeYm007038; Mon, 3 Feb 2003 11:36:40 -0500 (EST) Received: from [66.44.58.246] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA19815; Mon, 3 Feb 2003 11:36:39 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200302021409.h12E9ORS030650@nic-naa.net> References: <200302021409.h12E9ORS030650@nic-naa.net> Date: Mon, 3 Feb 2003 11:05:31 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Resend: Just checking ... Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 9:09 -0500 2/2/03, Eric Brunner-Williams in Portland Maine wrote: >All, > >Since Ed runs about a week behind in responding to list traffic, I'll >be happy with a response from any contributor. Sorry about that, but it's true... >Are any other mechanisms proposed? I think you've got the proposed mechanisms... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h12E9o9p014963 for ; Sun, 2 Feb 2003 15:09:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h12E9oPL014962 for ietf-provreg-outgoing; Sun, 2 Feb 2003 15:09:50 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h12E9m9p014957 for ; Sun, 2 Feb 2003 15:09:48 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h12E9ORS030650 for ; Sun, 2 Feb 2003 09:09:24 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302021409.h12E9ORS030650@nic-naa.net> To: ietf-provreg@cafax.se Subject: [ietf-provreg] Resend: Just checking ... Date: Sun, 02 Feb 2003 09:09:24 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk All, Since Ed runs about a week behind in responding to list traffic, I'll be happy with a response from any contributor. Eric ------- Forwarded Message To: edlewis@arin.net cc: ietf-provreg@cafax.se Subject: [ietf-provreg] Just checking ... Date: Fri, 31 Jan 2003 20:02:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Is it the case that the following mechanisms are proposed: o an attribute, of type boolean, for every element o an extensible element, of type epp:dcpType, optionally for any element of type epp:greetingType, extensible to any extensible element Are any other mechanisms proposed? Eric ------- End of Forwarded Message Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11M1v9p009555 for ; Sat, 1 Feb 2003 23:01:57 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h11M1vRj009554 for ietf-provreg-outgoing; Sat, 1 Feb 2003 23:01:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11M1u9p009549 for ; Sat, 1 Feb 2003 23:01:56 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h11M1eRS028467; Sat, 1 Feb 2003 17:01:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302012201.h11M1eRS028467@nic-naa.net> To: Otmar Lendl cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: [ietf-provreg] Re: nic.at and nic.pl implementations In-Reply-To: Your message of "Sat, 01 Feb 2003 19:19:13 +0100." <20030201191913.A12932@eunet-ag.at> Date: Sat, 01 Feb 2003 17:01:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk My complements to the implementors! Today's NY Times (US) reports that MicroSoft has announced a modification of its product(s) in response to European data protection requirements. I'm curious to know what the .pl requirements are -- I'm familiar with the EU requirements. Cheers, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Ipr9p008607 for ; Sat, 1 Feb 2003 19:51:53 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11IpruU008606 for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:51:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Ipq9p008601 for ; Sat, 1 Feb 2003 19:51:53 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11IpqMH047140 for ; Sat, 1 Feb 2003 19:51:52 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200302011851.h11IpqMH047140@bartok.sidn.nl> To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: nic.at presentations from RIPE44 In-reply-to: Your message of Sat, 01 Feb 2003 19:19:13 +0100. <20030201191913.A12932@eunet-ag.at> Date: Sat, 01 Feb 2003 19:51:52 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 2003/02/01 18:02, Jaap Akkerhuis wrote: > At the DNR-forum at RIPE-44 last week, the polish registry presented > their implementation of EPP. On a related note: Our presentation from monday's Centr workshop are online as well. You can get the .ppt files (and the latest source code tarballs) from http://sourceforge.net/project/showfiles.php?group_id=66464 . Let me clarify a bit about this. At the first day of RIPE meetings there is usually a CENTR technical meeting. This time, the afternoon was devoted to EPP. SInce the meeting is limited to CENTR members and invitees (Scott Hollenbeck was there, among others) I don't feel comfortable about quoting from that, although often the meeting minutes are published on the CENTR website. Anyway, Otmar Lendl on behalf of the Austrian registry, presented at the centr-tech meeting an implementation of an EPP server as a mod_epp Apache module. It is nice to see that this is actually public information. For details, see the URL he mentions. jaap Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IQF9p008342 for ; Sat, 1 Feb 2003 19:26:15 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11IQFAo008341 for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:26:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IQE9p008336 for ; Sat, 1 Feb 2003 19:26:14 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11IQEMH047050 for ; Sat, 1 Feb 2003 19:26:14 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.6/8.12.6/Submit) id h11IQDcX047049 for ietf-provreg@cafax.se; Sat, 1 Feb 2003 19:26:13 +0100 (CET) Received: from eddie.Austria.EU.net (eddie.austria.eu.net [193.154.142.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IJE9p008209 for ; Sat, 1 Feb 2003 19:19:14 +0100 (MET) Received: from eddie.Austria.EU.net (localhost [127.0.0.1]) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian -4) with ESMTP id h11IJDs5012961 for ; Sat, 1 Feb 2003 19:19:13 +0100 Received: (from lendl@localhost) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian -4) id h11IJDf9012960 for ietf-provreg@cafax.se; Sat, 1 Feb 2003 19:19:13 +0100 Date: Sat, 1 Feb 2003 19:19:13 +0100 From: Otmar Lendl To: ietf-provreg@cafax.se Subject: [ietf-provreg] FYI: nic.at presentations from RIPE44 Message-ID: <20030201191913.A12932@eunet-ag.at> References: <200302011751.h11HpnMH046835@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302011751.h11HpnMH046835@bartok.sidn.nl> User-Agent: Mutt/1.3.23i Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 2003/02/01 18:02, Jaap Akkerhuis wrote: > At the DNR-forum at RIPE-44 last week, the polish registry presented > their implementation of EPP. On a related note: Our presentation from monday's Centr workshop are online as well. You can get the .ppt files (and the latest source code tarballs) from http://sourceforge.net/project/showfiles.php?group_id=66464 . /ol Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11I6k9p008003 for ; Sat, 1 Feb 2003 19:06:46 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11I6k73008002 for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:06:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11I6i9p007997 for ; Sat, 1 Feb 2003 19:06:45 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h11I6VRS025721; Sat, 1 Feb 2003 13:06:31 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302011806.h11I6VRS025721@nic-naa.net> To: Jaap Akkerhuis cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-Reply-To: Your message of "Sat, 01 Feb 2003 18:51:49 +0100." <200302011751.h11HpnMH046835@bartok.sidn.nl> Date: Sat, 01 Feb 2003 13:06:31 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk kwel! Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Hpp9p007772 for ; Sat, 1 Feb 2003 18:51:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h11Hppco007771 for ietf-provreg-outgoing; Sat, 1 Feb 2003 18:51:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Hpo9p007766 for ; Sat, 1 Feb 2003 18:51:50 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11HpnMH046835 for ; Sat, 1 Feb 2003 18:51:49 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200302011751.h11HpnMH046835@bartok.sidn.nl> To: ietf-provreg@cafax.se Subject: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Sat, 01 Feb 2003 18:51:49 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk At the DNR-forum at RIPE-44 last week, the polish registry presented their implementation of EPP. They had to make extensions to implement the somewhat draconian Polish privacy rules. One of the things they mentioned was that they were more severe then the European ones, so when they join the EC, they might change. Anyway, I don't have the presentation on line yet, but they have piblished a document about the things they did with the protocol. It can be found as ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web. jaap Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h111279p001862 for ; Sat, 1 Feb 2003 02:02:07 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h111270B001861 for ietf-provreg-outgoing; Sat, 1 Feb 2003 02:02:07 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h111259p001856 for ; Sat, 1 Feb 2003 02:02:06 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h11120RS020906; Fri, 31 Jan 2003 20:02:01 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200302010102.h11120RS020906@nic-naa.net> To: edlewis@arin.net cc: ietf-provreg@cafax.se Subject: [ietf-provreg] Just checking ... Date: Fri, 31 Jan 2003 20:02:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Is it the case that the following mechanisms are proposed: o an attribute, of type boolean, for every element o an extensible element, of type epp:dcpType, optionally for any element of type epp:greetingType, extensible to any extensible element Are any other mechanisms proposed? Eric