From owner-ietf-provreg@cafax.se Mon Mar 3 07: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 HAA21613 for ; Mon, 3 Mar 2003 07:47: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 h23CN5oE012214 for ; Mon, 3 Mar 2003 13:23:05 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23CN5KN012213 for ietf-provreg-outgoing; Mon, 3 Mar 2003 13:23:05 +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 h23CN2oE012208 for ; Mon, 3 Mar 2003 13:23:04 +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 h23CL0tY078881; Mon, 3 Mar 2003 07:21:00 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031221.h23CL0tY078881@nic-naa.net> To: Edward Lewis cc: 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 13:35:11 EST." Date: Mon, 03 Mar 2003 07:21:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is an issue-reminder, assuming that the IESG is responsive on the privacy/data colleciton issue. mappings over transports other than tcp. The IESG claim is that commands cannot be reordered, which seems to be reasonable for the transformational subset of epp commands, but not the informational subset of epp commands, and this "resonability" appers to be limited to com/net/org/info/biz/name transactions. Email is used, as a transport for XML and BNF, elsewhere. Non-interoperation by intent is an odd proposition, particularly by non-implementors and non-operators. The IESG claim is also that applications protocols must provide congestion control. I'm afraid this new requirement seems reflexive, not the product of actual reflection on the deployment of epp. The publication protocols commonly in use with registry provisioning include UDP, with absurdly large difference in scale. Connectionism by design is an odd proposition too, again by non-implementors and non-operators. It would be reasonable if this work were within the ITU, which is both connectionist and mandarinist. Just out of curiosity, since whois is such a problem, why on earth is the inferred provisioning of social data to the com/net/org et alia whois servers not _historic_? The US DCA is very, very, dead as an Agency of Notice or Fashion. Eric From owner-ietf-provreg@cafax.se Mon Mar 3 08:41: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 IAA24960 for ; Mon, 3 Mar 2003 08:40:50 -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 h23DNpoE012780 for ; Mon, 3 Mar 2003 14:23:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23DNpUU012779 for ietf-provreg-outgoing; Mon, 3 Mar 2003 14:23:51 +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 h23DNmoE012774 for ; Mon, 3 Mar 2003 14:23:49 +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 h23DNmqn006290 for ; Mon, 3 Mar 2003 08:23:48 -0500 (EST) Received: from [66.44.57.72] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA11372 for ; Mon, 3 Mar 2003 08:23:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 3 Mar 2003 08:23:43 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:52 -0800 2/28/03, 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. ??? "Prevented" is certainly not the right word. >We have experenced 4 month delay because of this situation and it is >unacceptable. We still are in a state of limbo. Instead of trying to find fault, there should be an offering of suggestions. All of the needed data exist in the archives. >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. The IESG comment given during the fall (message dated "Tue, 15 Oct 2002 11:16:53 +0200"): why do domain/contact/.. not have granular information about privacy? In a later discussion with Patrik, I was told that the EPP proposal did not meet the requirement in Section 8.4 of RFC 3375. ("See the MUST part of [1].") There are three other inputs. One from Jaap - a look at how privacy concerns with .nl impact the issue. The second is a report and discussion on the .pl work in this area. The third is a message describing the EU perspective on why this must be solved. First message: Fri, 10 Jan 2003 13:43:22 +0100 Second message: Sat, 01 Feb 2003 18:51:49 +0100, with a followup Tue, 11 Feb 2003 08:30:20 -0500 by Scott Hollenbeck Third message: Fri, 17 Jan 2003 11:03:26 +0100, Vittorio Bertola As far as a summary, there's a message dated "Sun, 19 Jan 2003 21:00:15 -0500" that I sent out, with an ensuing thread. In the above are proposed solutions, as well as the dcp as it sits in the base specification. The consensus of the WG (or those participating actively on the list) is that privacy is too ill defined to put in the base specification. I get the feeling from the IESG that thinks the set of those reaching this consensus is not representative enough of the Internet in general, but this is just a feeling. (Who out there is not engineering to the environment of the shared registry model? Who is engineering toward an independent registry environment? Are we representative of the Internet as a whole?) I suppose this isn't the concise message you were hoping for, but I'd rather the WG figure this out rather than have me spoon feed it to you. E.g., the comment that we don't meet the requirement above was answered by me in a thread with an IESG member that ultimately went no where. (Maybe someone else needs to try.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Mar 3 09:16: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 JAA26394 for ; Mon, 3 Mar 2003 09:16: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 h23E26oE013271 for ; Mon, 3 Mar 2003 15:02:06 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23E26FZ013270 for ietf-provreg-outgoing; Mon, 3 Mar 2003 15:02:06 +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 h23E25oE013265 for ; Mon, 3 Mar 2003 15:02:05 +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 JAA14430; Mon, 3 Mar 2003 09:01:58 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 09:02:01 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337076C@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Mon, 3 Mar 2003 09:01:53 -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 suppose this isn't the concise message you were hoping for, but I'd > rather the WG figure this out rather than have me spoon feed it to > you. E.g., the comment that we don't meet the requirement above was > answered by me in a thread with an IESG member that ultimately went > no where. (Maybe someone else needs to try.) I sent a private message about the DCP requirement to Patrik last Thursday or Friday. He hasn't yet responded. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 3 11:02: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 LAA00900 for ; Mon, 3 Mar 2003 11:02: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 h23FnioE014423 for ; Mon, 3 Mar 2003 16:49:44 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23FniWq014422 for ietf-provreg-outgoing; Mon, 3 Mar 2003 16:49: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 h23FngoE014415 for ; Mon, 3 Mar 2003 16:49: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 h23FlqtY079531; Mon, 3 Mar 2003 10:47:52 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031547.h23FlqtY079531@nic-naa.net> To: "Hollenbeck, Scott" cc: "'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 "Mon, 03 Mar 2003 09:01:53 EST." <3CD14E451751BD42BA48AAA50B07BAD60337076C@vsvapostal3.prod.netsol.com> Date: Mon, 03 Mar 2003 10:47:52 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > why do domain/contact/.. not have granular information about privacy? Asked and answered. 1. Because operationally, policing at the session level is sufficient to support persistent policing across multiple distinct objects, or support single-object-session policing. 2. Because syntactically, if epp is to remain extensible, and xml-based, adding attributes to elements is either pervasive, or specific. As this WG lost the technical/social distinction with the expiry of Ross' draft, we don't have a handy hook for being "specific", and "pervasive" makes conditionally "private" even the data the registrants who have standing to "privacy" under EU framework UNCONDITIONALLY SEEK TO PUBLISH. 3. Because semantically, it isn't simply contemporanious publication via 954 that is of issue, particularly in the EU, but also in the OEDC, and potentially even the US. Also required is some mechanism to identify the repurposing of registrant (and registrar) data, as bulk-access is a real practice, with abuses. Also required is some mechanism to identify the availability of collected registrant (and registrar) data for correction. Also required is some mechanism to identify the duration that data is held by the collector. Adding these semantics to complexType elements would be complex, and has no benefit over attaching the same semantics to aggregations of elements that are NEVER DISAGGREGATED, aka "objects". There is little observed or hypothetical inter-object disaggregation of policy that cannot be reasonably, and scalably met, by bounding sessions by policy discontinuity. See #1, above. Ops, syn, sem, all covered. > In a later discussion with Patrik, I was told that the EPP proposal > did not meet the requirement in Section 8.4 of RFC 3375. ("See the > MUST part of [1].") I wrote the requirement. The mechanism is the , and it is provided by the protocol. The requirement does not state: The protocol MUST NOT provide services if data collection policies are not identified. If it had, then we'd have had (or some other mechanism(s)) as MANDITORY-TO-IMPLEMENT, rather than OPTIONAL. There was WG consensus that the is in the core schema (epp-1.0.xsd), optional to implement, and not an optional extension. > There are three other inputs. > One from Jaap - a look at how privacy concerns with .nl impact the issue. I sent a public message about the .nl requirement to Jaap not long after his note on the subject, that the EU residency requirement for registrars provided a contractual equivalent to a element, and a simpler form (for a hypothetical deployment of epp, as .nl wasn't yet epp-operational) of whois-token, while sufficient for endpoints within the EU, would not be capable of allowing non-EU endpoints to register .nl domains. He hasn't responded. > The second is a report and discussion on the .pl work in this area. I send a public message about the decision of this particular implementor not to use the . I seem to have missed the response. > The third is a message describing the EU perspective on why this must > be solved. Oh thank heavens! A live EU national who is a self-described "newbie" and neither an implementor, nor an operator, nor an author, nor apparently a specification reader. Now I can stop thinking. Note Bene Chair: 1. IESG (Randy or Allison) asked and answered 2. IESG (Patrick) asked and answered 3. .NL asked and not responsive 4. .PL asked and not responsive 5. Newbie noises What part of IETF process did I miss in IETF grade school back in the mid-80s? I don't actually mind if folks creatively craft into "privacy" some form of market protection, Europe for the Europeans, Africa for the Africans, Circumpolar Regions for the Very-Well-Dressed. I simply find it amusing that on the one hand we've people in the IAB/IESG kicking Chinese Butt big time for attempting to fix Unicode [1], arguing "minimum astonishment" as if it were an end-to-end principle, and people with the same, or very similar drinking buddies, arguing that the semanitcs of "{0,1} are context dependent. Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0? I'm always astonished that packets even make it anywhere. Eric [1] Yes Virginia, the new IRTF activity specifically BARS the work by the Joint Engineering Team (.tw/.cn/.kr/.jp) registries and the Chinese Domain Name Consortium (.tw/.hk/.ma/.cn) on intermediate mappings in particular, and constructive mechanism in general. I've asked. Twice. Not for IPR reasons either. From owner-ietf-provreg@cafax.se Mon Mar 3 11:54: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 LAA02802 for ; Mon, 3 Mar 2003 11:54: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 h23GfDoE015080 for ; Mon, 3 Mar 2003 17:41:13 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23GfDlL015079 for ietf-provreg-outgoing; Mon, 3 Mar 2003 17:41:13 +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 h23GfCoE015074 for ; Mon, 3 Mar 2003 17:41:12 +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 h23Gf9qn012075 for ; Mon, 3 Mar 2003 11:41:09 -0500 (EST) Received: from [66.44.57.72] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA12152 for ; Mon, 3 Mar 2003 11:41:08 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303031547.h23FlqtY079531@nic-naa.net> References: <200303031547.h23FlqtY079531@nic-naa.net> Date: Mon, 3 Mar 2003 11:39:56 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: >Note Bene Chair: > 1. IESG (Randy or Allison) asked and answered > 2. IESG (Patrick) asked and answered > 3. .NL asked and not responsive > 4. .PL asked and not responsive > 5. Newbie noises I should respond to earlier parts of the mail, but I'll pick on this first. As far as 1 & 2, the IESG has taken the first step the responsible guardian. I have to admit, however, that the detail I have obtained from them has been insufficient to evaluate any proposed solution as being "the right one." I do not dispute the spirit of the IESG comments, I just wish that the comments were supported by more substance, as could be provided by 3 & 4. I cannot speak as to why 3 & 4 were not responsive. But these categories represent an important voice that I think needs to be heard. I was looking to such a constituency to give more information on what the IESG is hinting we need, but I haven't been able to introduce any discussion in this way. (I should add that I am not so disappointed that 3 and 4 haven't responded, I am more disappointed that there haven't been other organizations of similar ilk saying anything at all. Yes, that's a generalization - and the IETF is supposed to be individual participation, but the list needs to hear folks with knowledge of other environments to help pound out a solution to this issue.) The latter case - "newbie" is rather derogatory term. Whether or not any one person agrees/disagrees with the words uttered, comments of this ilk (when on topic) are good to hear. The IETF isn't about making protocols that implementors agree to - it's about making interoperable useful protocols. >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0? The answer to this is a determining factor (to me at least) of whether $dnp is in the base specification or in an extension. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Mar 3 13:15: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 NAA06022 for ; Mon, 3 Mar 2003 13:15: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 h23HpGoE015892 for ; Mon, 3 Mar 2003 18:51:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23HpGev015891 for ietf-provreg-outgoing; Mon, 3 Mar 2003 18:51:16 +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 h23HpDoE015885 for ; Mon, 3 Mar 2003 18:51:14 +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 h23HnKtY079970; Mon, 3 Mar 2003 12:49:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031749.h23HnKtY079970@nic-naa.net> To: Edward Lewis 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 "Mon, 03 Mar 2003 11:39:56 EST." Date: Mon, 03 Mar 2003 12:49:20 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The latter case - "newbie" is rather derogatory term. From <5nkf2vc69aamt50qla76umk9cscpun42ev@4ax.com> > I am a newbie of this group and of the IETF WGs in general (please > pardon me for anything inappropriate I might unvoluntarily do). > However, I have been discussing DNS privacy issues extensively in the > last years, so please allow me to give my point of view on the ongoing > privacy discussion. Note. > Not addressing the privacy issue in the base protocol would likely > imply that the service would often be deployed in real life without > any means to achieve privacy protection. Agree. > Unfortunately, the present > lack of privacy protection in the WHOIS system is plainly illegal in > many countries, and I don't think it's reasonable to think that this > situation can go on for long without actual lawsuits starting to > happen, both towards ccTLD and gTLD registries and registrars. Not relevant for a provisioning protocol. Specific to a particular post-provisioned publication protocol, and none of us should be playing lawyer on the net. Its mechanism, mechanism, mechanism, mechanism, mechanism, mechanism and once more for emphesis, mechanism. Now I'll go back to my screw driver and duct tape, cause three years working http-state, onward-transport, and provisioning just haven't left me with clue parity with jrandom Euros. I'll send a write up of where we are to the P3P list, we (I've now got a spiffy "P3P hat" on) have a meeting this Friday. At this point though, it looks as if the W3C is going one way, and the IETF is going another. XML on the one hand, and a binary token on the other. Eric From owner-ietf-provreg@cafax.se Mon Mar 3 13:25:24 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 NAA06382 for ; Mon, 3 Mar 2003 13:25:23 -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 h23I9OoE016042 for ; Mon, 3 Mar 2003 19:09:24 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23I9OcF016041 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:09:24 +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 h23I9BoE016034 for ; Mon, 3 Mar 2003 19:09:23 +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 NAA00790; Mon, 3 Mar 2003 13:09:04 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 13:02:34 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337077B@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Mon, 3 Mar 2003 13:02:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically > evaluate to 1, or 0? > > The answer to this is a determining factor (to me at least) of > whether $dnp is in the base specification or in an extension. As far as .com is concerned, I have no doubt that an extension will be required even if we were to adopt the IESG's element tagging suggestion. That being the case, my preference would be to put _all_ of the DNP syntax and semantics into an extension (where the problem can be addressed as a whole) while making the existing DCP element mandatory if that resolves the privacy issue with the IESG. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 3 13:28:26 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 NAA06465 for ; Mon, 3 Mar 2003 13:28: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 h23I8doE016028 for ; Mon, 3 Mar 2003 19:08:39 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23I8dJS016027 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:08:39 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h23I8boE016022 for ; Mon, 3 Mar 2003 19:08:37 +0100 (MET) Message-ID: <021601c2e1af$e0699f20$6801a8c0@neteka.inc> From: "Edmon Chung" To: , "Edward Lewis" Cc: References: Subject: Re: [ietf-provreg] our meeting slot in SF Date: Mon, 3 Mar 2003 13:08:20 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit I wonder if there might be interest in discussing the topic of IDN/EPP. I know that Scott's extension guideline already discussed briefly about it, but it gave no provisions to the handling of character equivlancy preparation (Charprep) issues and the related reserved variants and zone variants management. I dont have a draft yet, but am working on it. I gave a presentation on the issues and some experiments that we have done on a possible architecture for handling the charprep recently (at the APRICOT) and it received very good response. I thought it would be a good idea to present it to the group and get some feedback as I write my draft on the topic. Edmon ----- Original Message ----- From: "Edward Lewis" To: Cc: Sent: Friday, February 28, 2003 1:35 PM Subject: [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. ;) > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > From owner-ietf-provreg@cafax.se Mon Mar 3 13:32:19 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 NAA06630 for ; Mon, 3 Mar 2003 13:32:18 -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 h23IEaoE016104 for ; Mon, 3 Mar 2003 19:14:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IEa9H016103 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:14:36 +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 h23IEZoE016098 for ; Mon, 3 Mar 2003 19:14:35 +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 h23IEUmn013227; Mon, 3 Mar 2003 10:14:31 -0800 (PST) Date: Mon, 3 Mar 2003 10:14:37 -0800 (PST) From: Rick Wesson To: Edmon Chung cc: , Edward Lewis Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: <021601c2e1af$e0699f20$6801a8c0@neteka.inc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edmon, Since the EPP specs use utf8 why do we need to encode the domains in punnycode? -rick On Mon, 3 Mar 2003, Edmon Chung wrote: > I wonder if there might be interest in discussing the topic of IDN/EPP. I > know that Scott's extension guideline already discussed briefly about it, > but it gave no provisions to the handling of character equivlancy > preparation (Charprep) issues and the related reserved variants and zone > variants management. > > I dont have a draft yet, but am working on it. I gave a presentation on the > issues and some experiments that we have done on a possible architecture for > handling the charprep recently (at the APRICOT) and it received very good > response. I thought it would be a good idea to present it to the group and > get some feedback as I write my draft on the topic. > > Edmon > > > ----- Original Message ----- > From: "Edward Lewis" > To: > Cc: > Sent: Friday, February 28, 2003 1:35 PM > Subject: [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. ;) > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis +1-703-227-9854 > > ARIN Research Engineer > > > > > From owner-ietf-provreg@cafax.se Mon Mar 3 13:40:49 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06843 for ; Mon, 3 Mar 2003 13:40:48 -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 h23ILboE016162 for ; Mon, 3 Mar 2003 19:21:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23ILbJd016161 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:21:37 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h23ILXoE016156 for ; Mon, 3 Mar 2003 19:21:36 +0100 (MET) Message-ID: <023801c2e1b1$ac44b480$6801a8c0@neteka.inc> From: "Edmon Chung" To: "Rick Wesson" Cc: , "Edward Lewis" References: Subject: Re: [ietf-provreg] our meeting slot in SF Date: Mon, 3 Mar 2003 13:21:11 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit It is not about punycode. It is about the handling of character equivalence preparations (what I call charprep): i.e. the creation of reserved variants and the management of zone variants. These charprep variants need to be generated upon domain creation and conveyed to the registrant. Examples of charprep include Traditional Chinese-Simplified Chinese Mapping and visually identical characters in the LGC (Latin, Greek, Cyrilic) space. Edmon ----- Original Message ----- From: "Rick Wesson" To: "Edmon Chung" Cc: ; "Edward Lewis" Sent: Monday, March 03, 2003 1:14 PM Subject: Re: [ietf-provreg] our meeting slot in SF > > > Edmon, > > Since the EPP specs use utf8 why do we need to encode the domains in > punnycode? > > -rick > > On Mon, 3 Mar 2003, Edmon Chung wrote: > > > I wonder if there might be interest in discussing the topic of IDN/EPP. I > > know that Scott's extension guideline already discussed briefly about it, > > but it gave no provisions to the handling of character equivlancy > > preparation (Charprep) issues and the related reserved variants and zone > > variants management. > > > > I dont have a draft yet, but am working on it. I gave a presentation on the > > issues and some experiments that we have done on a possible architecture for > > handling the charprep recently (at the APRICOT) and it received very good > > response. I thought it would be a good idea to present it to the group and > > get some feedback as I write my draft on the topic. > > > > Edmon > > > > > > ----- Original Message ----- > > From: "Edward Lewis" > > To: > > Cc: > > Sent: Friday, February 28, 2003 1:35 PM > > Subject: [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. ;) > > > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > Edward Lewis +1-703-227-9854 > > > ARIN Research Engineer > > > > > > > > > > From owner-ietf-provreg@cafax.se Mon Mar 3 13:53:34 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07482 for ; Mon, 3 Mar 2003 13: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 h23IUIoE016287 for ; Mon, 3 Mar 2003 19:30:18 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IUIf9016286 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:30:18 +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 h23IUGoE016281 for ; Mon, 3 Mar 2003 19:30:16 +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 h23IU8ue035383; Mon, 3 Mar 2003 19:30:10 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303031830.h23IU8ue035383@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: "Hollenbeck, Scott" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 10:47:52 -0500. <200303031547.h23FlqtY079531@nic-naa.net> Date: Mon, 03 Mar 2003 19:30:08 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk > One from Jaap - a look at how privacy concerns with .nl impact the issue. I sent a public message about the .nl requirement to Jaap not long after his note on the subject, that the EU residency requirement for registrars provided a contractual equivalent to a element, and a simpler form (for a hypothetical deployment of epp, as .nl wasn't yet epp-operational) of whois-token, while sufficient for endpoints within the EU, would not be capable of allowing non-EU endpoints to register .nl domains. He hasn't responded. I don't recall the question, at least I don't recognize it. The basic answer is no. There is no requirement for EU residency for registars nor registrants. All contracts are under dutch law. To force this, there should be a dutch adress to which papers can be presented. But that has nothing to do with privacy apart from the fact that the dutch privacy law should be followed by .nl. jaap From owner-ietf-provreg@cafax.se Mon Mar 3 14:12:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08253 for ; Mon, 3 Mar 2003 14:12: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 h23IoqoE016604 for ; Mon, 3 Mar 2003 19:50:52 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IoqRY016603 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:50:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h23IopoE016598 for ; Mon, 3 Mar 2003 19:50:52 +0100 (MET) Received: from rraderxp.pc.internal.tucows.com ([10.0.11.248]) by toronto.mail.tucows.com with esmtp (Exim 3.36 #3) id 18pv1A-0004YR-00; Mon, 03 Mar 2003 13:50:28 -0500 Date: Mon, 03 Mar 2003 13:50:28 -0500 From: "Ross Wm. Rader" To: "Hollenbeck, Scott" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Message-ID: <533274406.1046699428@[10.0.11.248]> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337077B@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337077B@vsvapostal3.prod.netso l.com> X-Mailer: Mulberry/3.0.2 (Win32 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, March 03, 2003 1:02 PM -0500 "Hollenbeck, Scott" mentioned that: > That being the case, my preference would be to put _all_ of the DNP syntax > and semantics into an extension (where the problem can be addressed as a > whole) while making the existing DCP element mandatory We'd be happy with that as well. regards, -rwr "There's a fine line between fishing and standing on the shore like an idiot." - Steven Wright Get Blog... http://www.byte.org/ From owner-ietf-provreg@cafax.se Mon Mar 3 14:21:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08548 for ; Mon, 3 Mar 2003 14:21:13 -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 h23IsKoE016668 for ; Mon, 3 Mar 2003 19:54:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IsJXu016667 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:54:19 +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 h23IsIoE016662 for ; Mon, 3 Mar 2003 19:54:18 +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 h23IqStY080228; Mon, 3 Mar 2003 13:52:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031852.h23IqStY080228@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 "Mon, 03 Mar 2003 19:30:08 +0100." <200303031830.h23IU8ue035383@bartok.sidn.nl> Date: Mon, 03 Mar 2003 13:52:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I don't recall the question, at least I don't recognize it. The > basic answer is no. There is no requirement for EU residency for > registars nor registrants. All contracts are under dutch law. To > force this, there should be a dutch adress to which papers can be > presented. But that has nothing to do with privacy apart from the > fact that the dutch privacy law should be followed by .nl. See "Deelnemers categorie I", below. ------- Forwarded Message Return-Path: brunner@nic-naa.net Delivery-Date: Tue Jan 21 19:48:52 2003 Return-Path: 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 h0M0mp7k038586; Tue, 21 Jan 2003 19:48:51 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200301220048.h0M0mp7k038586@nic-naa.net> To: Edward Lewis cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner Subject: Re: [ietf-provreg] where are we with privacy In-Reply-To: Your message of "Tue, 21 Jan 2003 11:36:52 EST." Date: Tue, 21 Jan 2003 19:48:51 -0500 From: Eric Brunner-Williams in Portland Maine > I would also like others to comment on Jaap's message and assessment that: OK, part 2. > At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote: > ... > >So yes, the non-disclose attribute will work for us without any > >problem. It is possible that we might do extensions to aid with the > ... > > > > jaap \begin{quote} Deelnemers ... Deelnemer worden ... Deelnemers categorie I Voor het deelnemerschap categorie I komen in aanmerking bedrijven in instellingen die zijn gevestigd op het grondgebied van de Euorpese Unie. [Category I participation Category I participation is open to businesses and institutions based within the European Union.] ... Het deelnemerschap geeft recht tot: o het verzorgen van de registratie van domeinnamen ten behoeve van klanten; [Category I participants have the following rights: o To apply to register domain names on behalf of clients;] \end{quote} The "us" (parties having the capacity to register domain names on behalf of clients) for which "the non-disclose attribute will work" appears to be a scoped set of (eventual) EPP participants. The charter for this WG is not to create a registry-specific, or regime-specific, or jurisdiction- specific, or object-specific protocol. How can a registrar signal in-band to a registry that it accepts the general Data Protection framework, and any specific terms and conditions? More generally, how can any two (or more) participants in the onward-transport of customer data signal in-band their data collection practices, and automate the management of onward-transport? Eric ------- End of Forwarded Message From owner-ietf-provreg@cafax.se Mon Mar 3 14:24:28 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08687 for ; Mon, 3 Mar 2003 14:24:27 -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 h23JDIoE016971 for ; Mon, 3 Mar 2003 20:13:18 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JDIAq016970 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:13:18 +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 h23JDGoE016965 for ; Mon, 3 Mar 2003 20:13:16 +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 h23JDGue035618; Mon, 3 Mar 2003 20:13:16 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303031913.h23JDGue035618@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 13:52:28 -0500. <200303031852.h23IqStY080228@nic-naa.net> Date: Mon, 03 Mar 2003 20:13:16 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk [Category I participation Category I participation is open to businesses and institutions based within the European Union.] Oh that. I thought that it was lifted. But it is still completely irrelevant for the privacy discussion. The "us" (parties having the capacity to register domain names on behalf of clients) for which "the non-disclose attribute will work" appears to be a scoped set of (eventual) EPP participants. The charter for this WG is not to create a registry-specific, or regime-specific, or jurisdiction- specific, or object-specific protocol. I'm not bringing this up. You are. How can a registrar signal in-band to a registry that it accepts the general Data Protection framework, and any specific terms and conditions? It doesn't need to. It should first abide to the contract. That is not-in band. More generally, how can any two (or more) participants in the onward-transport of customer data signal in-band their data collection practices, and automate the management of onward-transport? That's not question this group has to answer. The only question is, what is the proper element in the protocol which help to implement a policy as been spelled out in the legal framework. jaap From owner-ietf-provreg@cafax.se Mon Mar 3 14:27:13 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08763 for ; Mon, 3 Mar 2003 14:27: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 h23J1coE016808 for ; Mon, 3 Mar 2003 20:01:38 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23J1cTo016807 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:01:38 +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 h23J1ZoE016802 for ; Mon, 3 Mar 2003 20:01:37 +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 h23IxbtY080246; Mon, 3 Mar 2003 13:59:37 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031859.h23IxbtY080246@nic-naa.net> To: "Edmon Chung" cc: "Rick Wesson" , ietf-provreg@cafax.se, "Edward Lewis" , brunner@nic-naa.net Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: Your message of "Mon, 03 Mar 2003 13:21:11 EST." <023801c2e1b1$ac44b480$6801a8c0@neteka.inc> Date: Mon, 03 Mar 2003 13:59:37 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Gosh Edmon, don't forget to mention the utility of adding "$" and other neato gizmos to the string-space. JonnyCa$h.com, JonnyCash.com, really important stuff like that. It isn't fair that I'm the only Provreg contributor that you've tried to sell shell metacharacters to. Everyone should have a crack at adding reserved regex chars to their ASCII-only zone files. I'm going to miss the dim sum in SF... Eric From owner-ietf-provreg@cafax.se Mon Mar 3 14:38:58 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09372 for ; Mon, 3 Mar 2003 14:38: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 h23JONoE017126 for ; Mon, 3 Mar 2003 20:24:23 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JON5e017125 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:24:23 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h23JOKoE017118 for ; Mon, 3 Mar 2003 20:24:21 +0100 (MET) Message-ID: <024601c2e1ba$685542e0$6801a8c0@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: "Rick Wesson" , , "Edward Lewis" , References: <200303031859.h23IxbtY080246@nic-naa.net> Subject: Re: [ietf-provreg] our meeting slot in SF Date: Mon, 3 Mar 2003 14:23:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit :-) I thought you didnt like the idea... ;-D And, I think what we want to discuss in this work group is not the actual "mapping tables", but the framework for doing provisioning. It has more to do with how the management of reserved variants and zone variants can be provisioned. Edmon ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To: "Edmon Chung" Cc: "Rick Wesson" ; ; "Edward Lewis" ; Sent: Monday, March 03, 2003 1:59 PM Subject: Re: [ietf-provreg] our meeting slot in SF > Gosh Edmon, don't forget to mention the utility of adding "$" and other > neato gizmos to the string-space. > > JonnyCa$h.com, JonnyCash.com, really important stuff like that. It isn't > fair that I'm the only Provreg contributor that you've tried to sell shell > metacharacters to. Everyone should have a crack at adding reserved regex > chars to their ASCII-only zone files. > > I'm going to miss the dim sum in SF... > > Eric > From owner-ietf-provreg@cafax.se Mon Mar 3 14:57:13 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09892 for ; Mon, 3 Mar 2003 14:57:10 -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 h23JdMoE017374 for ; Mon, 3 Mar 2003 20:39:22 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JdLpm017373 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:39:21 +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 h23JdKoE017368 for ; Mon, 3 Mar 2003 20:39:21 +0100 (MET) Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Mon, 03 Mar 2003 14:39:19 -0500 Message-ID: <3E63B200.3000505@ecotroph.net> Date: Mon, 03 Mar 2003 14:50:24 -0500 From: Andrew Newton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 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 References: <200303031749.h23HnKtY079970@nic-naa.net> In-Reply-To: <200303031749.h23HnKtY079970@nic-naa.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Eric Brunner-Williams in Portland Maine wrote: >>The latter case - "newbie" is rather derogatory term. > > > From <5nkf2vc69aamt50qla76umk9cscpun42ev@4ax.com> > > >>I am a newbie of this group and of the IETF WGs in general (please >>pardon me for anything inappropriate I might unvoluntarily do). >>However, I have been discussing DNS privacy issues extensively in the >>last years, so please allow me to give my point of view on the ongoing >>privacy discussion. > > > Note. I think it was the use of the words "newbie noises"... "noise" sometimes referencing an engineering term for signal ignored or unwanted. -andy From owner-ietf-provreg@cafax.se Mon Mar 3 15:11:01 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11124 for ; Mon, 3 Mar 2003 15:11:00 -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 h23JtMoE017580 for ; Mon, 3 Mar 2003 20:55:22 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JtM4Z017579 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:55:22 +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 h23JtKoE017574 for ; Mon, 3 Mar 2003 20:55:21 +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 h23JrStY080488; Mon, 3 Mar 2003 14:53:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031953.h23JrStY080488@nic-naa.net> To: Andrew Newton 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 "Mon, 03 Mar 2003 14:50:24 EST." <3E63B200.3000505@ecotroph.net> Date: Mon, 03 Mar 2003 14:53:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk try lack of signal. would it have been more polite to suggest a low s/n ratio? From owner-ietf-provreg@cafax.se Mon Mar 3 15:16:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11315 for ; Mon, 3 Mar 2003 15:16: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 h23JxcoE017687 for ; Mon, 3 Mar 2003 20:59:38 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JxcTX017686 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:59:38 +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 h23JxboE017681 for ; Mon, 3 Mar 2003 20:59:37 +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 h23JvktY080504; Mon, 3 Mar 2003 14:57:46 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031957.h23JvktY080504@nic-naa.net> To: Jaap Akkerhuis cc: 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 "Mon, 03 Mar 2003 20:13:16 +0100." <200303031913.h23JDGue035618@bartok.sidn.nl> Date: Mon, 03 Mar 2003 14:57:46 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > [Category I participation Category I participation is open > to businesses and institutions based within the European Union.] > >Oh that. I thought that it was lifted. But it is still completely >irrelevant for the privacy discussion. OK. What, if anything, is relevant? > The "us" (parties having the capacity to register domain names on behalf > of clients) for which "the non-disclose attribute will work" appears to > be a scoped set of (eventual) EPP participants. The charter for this WG > is not to create a registry-specific, or regime-specific, or jurisdiction- > specific, or object-specific protocol. > >I'm not bringing this up. You are. Correct. So there no semantic consequence to the registrar being, or not being, "based within the European Union." The registrar may (hypothetically) provision some datum to the .nl registry, with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with out difference, independent of the registrar's location. Is this correct? I was totally mislead by the .nl registry's Dutch page on the subject of registrar requirements. Fine. I can live with being stupid. I don't have a lot of choice in the matter anyway. > How can a registrar signal in-band to a registry that it accepts > the general Data Protection framework, and any specific terms > and conditions? > >It doesn't need to. It should first abide to the contract. That is >not-in band. What contract? Better still, if a registrar doesn't need to signal in-band it accepts anything, then it doesn't need to even know whatever that useless thing is. 8.4 has a MUST in it, which appears to have no meaning at all if I finally understand you. Everything is in the contract -- Scott's opening position, that bilateral out-of-band mechanism (contract) covered the requirement. > More generally, how can any two (or more) participants in the > onward-transport of customer data signal in-band their data > collection practices, and automate the management of onward-transport? > >That's not question this group has to answer. The only question is, >what is the proper element in the protocol which help to implement >a policy as been spelled out in the legal framework. Well, you're a co-chair, so I guess we're finnished with The protocol MUST provide services to identify data collection policies. and are on to "the proper element in the protocol which help to implement a policy" Gosh this is such fun. Not. Eric From owner-ietf-provreg@cafax.se Mon Mar 3 15:25:58 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11636 for ; Mon, 3 Mar 2003 15:25:58 -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 h23KAMoE017853 for ; Mon, 3 Mar 2003 21:10:22 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23KAMd7017852 for ietf-provreg-outgoing; Mon, 3 Mar 2003 21:10:22 +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 h23KALoE017847 for ; Mon, 3 Mar 2003 21:10:21 +0100 (MET) Received: from [10.1.2.195] (helo=DUN435) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18pwGM-0003se-00; Mon, 03 Mar 2003 15:10:14 -0500 From: "Michael Young" To: "'Ross Wm. Rader'" , "'Hollenbeck, Scott'" , "'Edward Lewis'" , Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Mon, 3 Mar 2003 15:10:10 -0500 Message-ID: <009f01c2e1c0$e4964920$c302010a@DUN435> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <533274406.1046699428@[10.0.11.248]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Likewise, we are also happy with that approach. Michael Young -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Ross Wm. Rader Sent: March 3, 2003 1:50 PM To: Hollenbeck, Scott; 'Edward Lewis'; 'ietf-provreg@cafax.se' Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry --On Monday, March 03, 2003 1:02 PM -0500 "Hollenbeck, Scott" mentioned that: > That being the case, my preference would be to put _all_ of the DNP > syntax and semantics into an extension (where the problem can be > addressed as a > whole) while making the existing DCP element mandatory We'd be happy with that as well. regards, -rwr "There's a fine line between fishing and standing on the shore like an idiot." - Steven Wright Get Blog... http://www.byte.org/ From owner-ietf-provreg@cafax.se Mon Mar 3 15:48:28 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12342 for ; Mon, 3 Mar 2003 15:48:27 -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 h23KWwoE018152 for ; Mon, 3 Mar 2003 21:32:58 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23KWwsx018151 for ietf-provreg-outgoing; Mon, 3 Mar 2003 21:32:58 +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 h23KWvoE018146 for ; Mon, 3 Mar 2003 21:32:57 +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 h23KWvue035982; Mon, 3 Mar 2003 21:32:57 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303032032.h23KWvue035982@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 14:57:46 -0500. <200303031957.h23JvktY080504@nic-naa.net> Date: Mon, 03 Mar 2003 21:32:57 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Correct. So there no semantic consequence to the registrar being, or not being, "based within the European Union." Not with respect of the privacy issues. That is under Dutch regulation, as I have said before. The registrar may (hypothetically) provision some datum to the .nl registry, with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with out difference, independent of the registrar's location. Is this correct? Yup, see above. What contract? Between registry and registrar. Better still, if a registrar doesn't need to signal in-band it accepts anything, then it doesn't need to even know whatever that useless thing is. You are twiting words. See my earlier response how this might work. 8.4 has a MUST in it, which appears to have no meaning at all if I finally understand you. Everything is in the contract -- Scott's opening position, that bilateral out-of-band mechanism (contract) covered the requirement. A MUST in a requirement document might work out differently in practice. Well, you're a co-chair, so I guess we're finnished with The protocol MUST provide services to identify data collection policies. and are on to "the proper element in the protocol which help to implement a policy" Gosh this is such fun. Not. I was not talking as co-chair. jaap From owner-ietf-provreg@cafax.se Mon Mar 3 16:18:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13213 for ; Mon, 3 Mar 2003 16:18:34 -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 h23L5poE018581 for ; Mon, 3 Mar 2003 22:05:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23L5p03018580 for ietf-provreg-outgoing; Mon, 3 Mar 2003 22:05:51 +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 h23L5ooE018575 for ; Mon, 3 Mar 2003 22:05: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 h23L3wtY080755; Mon, 3 Mar 2003 16:03:58 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303032103.h23L3wtY080755@nic-naa.net> To: Jaap Akkerhuis cc: 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 "Mon, 03 Mar 2003 21:32:57 +0100." <200303032032.h23KWvue035982@bartok.sidn.nl> Date: Mon, 03 Mar 2003 16:03:58 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'm not twisting your words, I'm not doing anything but try to get to the bottom of something. > Correct. > > So there no semantic consequence to the registrar being, or not being, > "based within the European Union." > > Not with respect of the privacy issues. That is under Dutch regulation, > as I have said before. OK. http://www.nic.nl/sidn/flat/Deelnemers/Deelnemer_worden/index.html is garbage, in this context. > The registrar may (hypothetically) provision some datum to the .nl registry, > with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with > out difference, independent of the registrar's location. Is this correct? > > Yup, see above. Good. > What contract? > > Between registry and registrar. > > Better still, if a registrar doesn't need to signal in-band it accepts > anything, then it doesn't need to even know whatever that useless thing > is. > > You are twiting words. See my earlier response how this might work. Really? It seems that Scott (ages ago, London-context) said "contracts" as the mechanism. I'm sorry but I don't know which earlier response you are referring to. Could you provide a date? I'll read it. > 8.4 has a MUST in it, which appears to have no meaning at all if I > finally understand you. Everything is in the contract -- Scott's opening > position, that bilateral out-of-band mechanism (contract) covered the > requirement. > > A MUST in a requirement document might work out differently in practice. In theory ... Yeah. Patrick's quote. > Well, you're a co-chair, so I guess we're finnished with > > The protocol MUST provide services to identify data collection policies. > > and are on to > > "the proper element in the protocol which help to implement a policy" > > Gosh this is such fun. Not. > > I was not talking as co-chair. > > jaap > These two sentences mean very different kinds of things. One attempts to describe a non-trivial policy space, without knowing a priori the constraints. A mechanism of description. A "what". One attempts to select from a set of elements (generally) the one(s) which can effect a particular policy (possibly pluralized). A mechanism of effectation. A "how". Usually "how" comes after "what" (except in cowboy and indian movies), not as an alternative to "what". Eric From owner-ietf-provreg@cafax.se Mon Mar 3 22:48:20 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 WAA22632 for ; Mon, 3 Mar 2003 22:48:19 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h243c1W1027151 for ; Tue, 4 Mar 2003 04:38:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h243c19r027150 for ietf-provreg-outgoing; Tue, 4 Mar 2003 04:38:01 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from as01.tabata.noc.humeia.net (as01.tabata.noc.humeia.net [210.156.80.71] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h243bwW1027145 for ; Tue, 4 Mar 2003 04:37:59 +0100 (MET) Received: (qmail 12846 invoked by uid 0); 4 Mar 2003 03:38:15 -0000 Received: from dhcp01.kanda.noc.humeia.ad.jp (HELO noma) (noma@tabata.humeia.net@61.195.157.157) by as01.tabata.noc.humeia.net with SMTP; 4 Mar 2003 03:38:15 -0000 To: ietf-provreg@cafax.se Subject: [ietf-provreg] URL element in contact mapping From: Hideki Noma Message-Id: <200303041237.HAD10017.NBPO@humeia.ad.jp> X-Mailer: Winbiff without EditX [Version 2.41] X-Accept-Language: ja,en Date: Tue, 4 Mar 2003 12:37:33 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hello, There will be a URL element introduced in .JP contact information in near future. And I beleive that some sort of element representing a URL of domain owner or contact is necessary.In fact whois.internic.net has both url element of whois server and web server. I understand that url element should be optional or even, extention implemented by registrars, however the element name must be standardized. I don't know why JP registry is not commenting on this but as one of JP registrar, I strongly request it. If there has been a discussion around this topic I've missed it, please point me where to look at. Hideki Noma Humeia Limited Partnership From owner-ietf-provreg@cafax.se Mon Mar 3 23:07: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 XAA23065 for ; Mon, 3 Mar 2003 23:07:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h243v3W1027322 for ; Tue, 4 Mar 2003 04:57:03 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h243v399027321 for ietf-provreg-outgoing; Tue, 4 Mar 2003 04:57:03 +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.8/8.12.8) with ESMTP id h243v1W1027316 for ; Tue, 4 Mar 2003 04:57:02 +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 h243t6tY081683; Mon, 3 Mar 2003 22:55:06 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303040355.h243t6tY081683@nic-naa.net> To: Hideki Noma cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] URL element in contact mapping In-Reply-To: Your message of "Tue, 04 Mar 2003 12:37:33 +0900." <200303041237.HAD10017.NBPO@humeia.ad.jp> Date: Mon, 03 Mar 2003 22:55:06 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hideki, I don't think there has been any discussion around this topic. Why don't you start to suggest how to specify this? Eric From owner-ietf-provreg@cafax.se Tue Mar 4 05:09: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 FAA11093 for ; Tue, 4 Mar 2003 05:09:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h249vfW1029952 for ; Tue, 4 Mar 2003 10:57:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h249vfKK029951 for ietf-provreg-outgoing; Tue, 4 Mar 2003 10:57:41 +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.8/8.12.8) with ESMTP id h249veW1029946 for ; Tue, 4 Mar 2003 10:57:40 +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 h249vbpE038572; Tue, 4 Mar 2003 10:57:37 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303040957.h249vbpE038572@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 16:03:58 -0500. <200303032103.h23L3wtY080755@nic-naa.net> Date: Tue, 04 Mar 2003 10:57:36 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Really? It seems that Scott (ages ago, London-context) said "contracts" as the mechanism. I'm sorry but I don't know which earlier response you are referring to. Could you provide a date? I'll read it. http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html jaap From owner-ietf-provreg@cafax.se Tue Mar 4 07:38:30 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 HAA15741 for ; Tue, 4 Mar 2003 07:38:29 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24COIW1001362 for ; Tue, 4 Mar 2003 13:24:18 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h24COI6E001361 for ietf-provreg-outgoing; Tue, 4 Mar 2003 13:24:18 +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.8/8.12.8) with ESMTP id h24COGW1001356 for ; Tue, 4 Mar 2003 13:24:17 +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 h24CMGtY082995; Tue, 4 Mar 2003 07:22:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041222.h24CMGtY082995@nic-naa.net> To: Jaap Akkerhuis cc: 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, 04 Mar 2003 10:57:36 +0100." <200303040957.h249vbpE038572@bartok.sidn.nl> Date: Tue, 04 Mar 2003 07:22:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Really? It seems that Scott (ages ago, London-context) said "contracts" as > the mechanism. I'm sorry but I don't know which earlier response you are > referring to. Could you provide a date? I'll read it. > > http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html It appears I did read that. I replied with about 60 lines of comment in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html and a one character correction in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html and followed up with http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html Well, my baby wants pick-up, and she won't wait 9 weeks until I get around to paying attention to her needs. Eric From owner-ietf-provreg@cafax.se Tue Mar 4 08:22: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 IAA19085 for ; Tue, 4 Mar 2003 08:22:47 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24DAZW1001940 for ; Tue, 4 Mar 2003 14:10:35 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h24DAZJu001939 for ietf-provreg-outgoing; Tue, 4 Mar 2003 14:10:35 +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.8/8.12.8) with ESMTP id h24DAWW1001934 for ; Tue, 4 Mar 2003 14:10:34 +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 h24D8EtY083151; Tue, 4 Mar 2003 08:08:14 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041308.h24D8EtY083151@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , "Rick Wesson" , ietf-provreg@cafax.se, "Edward Lewis" , brunner@nic-naa.net Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: Your message of "Mon, 03 Mar 2003 14:23:42 EST." <024601c2e1ba$685542e0$6801a8c0@neteka.inc> Date: Tue, 04 Mar 2003 08:08:14 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I thought you didnt like the idea... ;-D Correct. > And, I think what we want to discuss in this work group is not the actual > "mapping tables", but the framework for doing provisioning. What part is "interoperable", and subject to specification, assuming that a requirements statement exists, or can be frobbed up in finite time? > It has more to do with how the management of reserved variants and zone > variants can be provisioned. This doesn't seem to be a likely candidate for "interoperable", etc., but by all means, don't listen to me, you've bet your business that I'm wrong and dns operators are just dying to shell out shell metacharacters to the clammoring masses. She sells sea shells by the sea shore ... and in zone files. Cheers, Eric From owner-ietf-provreg@cafax.se Tue Mar 4 08:53:47 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 IAA21468 for ; Tue, 4 Mar 2003 08:53:46 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24DfBW1002286 for ; Tue, 4 Mar 2003 14:41:11 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h24DfBqX002285 for ietf-provreg-outgoing; Tue, 4 Mar 2003 14:41:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h24Df9W1002280 for ; Tue, 4 Mar 2003 14:41:10 +0100 (MET) Message-ID: <047d01c2e253$a2e36650$6801a8c0@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , "Rick Wesson" , , "Edward Lewis" References: <200303041308.h24D8EtY083151@nic-naa.net> Subject: Re: [ietf-provreg] our meeting slot in SF Date: Tue, 4 Mar 2003 08:40:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" > > And, I think what we want to discuss in this work group is not the actual > > "mapping tables", but the framework for doing provisioning. > > What part is "interoperable", and subject to specification, assuming that > a requirements statement exists, or can be frobbed up in finite time? The framework of the provisioning should be interoperable and subject to specification. For example, on domain create, the response should contain a list of "reserved variants". The annoucement of the list and the types of reserved variants could be specified. The actual list would be based on the registry policy. > > It has more to do with how the management of reserved variants and zone > > variants can be provisioned. > > This doesn't seem to be a likely candidate for "interoperable", etc. The policy itself would not be of the interest of this discussion. Rather the provisioning protocol should be. For further example, on query for domain info there should be additional list that contains the reserved variants and zone variants. Also for domain update, there should be ways to manage the reserved variants and zone variants. These could all be standardized even if the particular zone policies are different. Just like some TLDs might consider fax number to be "required" and some "optional", but the provisioning protocol supports the communication of fax numbers. Edmon From owner-ietf-provreg@cafax.se Tue Mar 4 09:10:14 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 JAA22388 for ; Tue, 4 Mar 2003 09:10:13 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24E0UW1002513 for ; Tue, 4 Mar 2003 15:00:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24E0Ud0002512 for ietf-provreg-outgoing; Tue, 4 Mar 2003 15:00:30 +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.8/8.12.8) with ESMTP id h24E0SW1002507 for ; Tue, 4 Mar 2003 15:00:28 +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 h24DwOtY083345; Tue, 4 Mar 2003 08:58:24 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041358.h24DwOtY083345@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , "Rick Wesson" , ietf-provreg@cafax.se, "Edward Lewis" , brunner@nic-naa.net Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: Your message of "Tue, 04 Mar 2003 08:40:32 EST." <047d01c2e253$a2e36650$6801a8c0@neteka.inc> Date: Tue, 04 Mar 2003 08:58:24 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk so, in a nutshell, you'd like a mechanism that allows for the expression of some new semantic, in particular, some form of equivalence class(es), where the semantics of "equivalence" is some property of some provisioned object. we had this at one point, in one form. containers. mind, it wasn't for octet or sequenct of octets equivalence classes (however defined). well, if you can find a general expression, i'd be interested in reading it. cheers, eric From owner-ietf-provreg@cafax.se Tue Mar 4 10:43: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 KAA27721 for ; Tue, 4 Mar 2003 10:43:03 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24FV5W1003657 for ; Tue, 4 Mar 2003 16:31:05 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24FV5uv003656 for ietf-provreg-outgoing; Tue, 4 Mar 2003 16:31:05 +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.8/8.12.8) with ESMTP id h24FV3W1003651 for ; Tue, 4 Mar 2003 16:31:03 +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 h24FV2pE026589; Tue, 4 Mar 2003 16:31:02 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303041531.h24FV2pE026589@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Tue, 04 Mar 2003 07:22:16 -0500. <200303041222.h24CMGtY082995@nic-naa.net> Date: Tue, 04 Mar 2003 16:31:02 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk It appears I did read that. I replied with about 60 lines of comment in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html and a one character correction in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html and followed up with http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html Two followups for a charater change. You said: 1. Application of the IESG proposal to "technical" data. The .NL registry defines (hypothetically of course) a dnp==true value for one or more elements as an error condition, and presumably returns some error code. Someone, Scott if my memory serves, mentioned a registry which defines a dnp==true value for one or more elements as a non-error, and presumably returns something other than an error code. Is using EPP with dcp==true for technical data a good thing? I see it as an operation to modify the string-space, with no external manifestation, other than error upon query or transform. I can't imagine an application to an address registry's operational practices, but I don't have direct knowledge of address registry or registrar operational art. That shows. Note I said, that this was a hypothetical case. 2. Application of the IESG proposal to "social" data at a registry. The .NL registry anticipates (effective 29 Jan 2003) operating under the general framework of a European Union member state's Data Protection Act. Consistent with the general framework of EU's Data Protection Directives, the access, purpose, recipient, and retention are all contractually defined. This is not generally the case for registries operating outside of the EU, nor for registrars and resellers operating outside of the EU. It would be helpful if the details of data protection between a non-EU resident .NL regsitrar and the .NL registry were available, assuming any exist. Note that we do this under dutch law. If registrars and registrations doesn't want to confirm to that, there is no point in registrting in .NL. 3. Existance of the PROVREG proposal, in the presence of the IESG proposal. Would the .NL registry operator use both the session-level data, and the element-level opt-{in|out} data? If the answer is "no", as I suspect it is, then use either a) is error, or b) is silently discarded. No, it is not discarded. Reread. And I din't mentioned both elements at all. If the answer is "yes", which takes precidence in the event of conflict? Trying to keep concrete, data originates from a registrant and is collected by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is provisioned to a .EU-Registry. Is the mechanism that provides the guidance for operational art at each onward-transport entity out-of-band (contract), or is it in-band, and if in-band, did the IESG proposal provide the same policy at each collector/onward-transporter as the European Union member state's Data Protection Act? I don't think so. I could be wrong. A p|np toggle is fine if purpose/recipient/retention/access are already taken care of (the Data Protection case). Where they are not, (OEDC and US cases), a p|np toggle may solve the 954 problem. How it can be applied to non-954 (and 954bis) is not stated. Deliver text. jaap From owner-ietf-provreg@cafax.se Tue Mar 4 11:10: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 LAA28806 for ; Tue, 4 Mar 2003 11:10:03 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24FwbW1004030 for ; Tue, 4 Mar 2003 16:58:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24Fwb4m004029 for ietf-provreg-outgoing; Tue, 4 Mar 2003 16:58: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.8/8.12.8) with ESMTP id h24FwYW1004021 for ; Tue, 4 Mar 2003 16:58:36 +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 h24FuWtY083735; Tue, 4 Mar 2003 10:56:32 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041556.h24FuWtY083735@nic-naa.net> To: Jaap Akkerhuis cc: 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, 04 Mar 2003 16:31:02 +0100." <200303041531.h24FV2pE026589@bartok.sidn.nl> Date: Tue, 04 Mar 2003 10:56:32 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Jaap, The third URL should have a value one greater than the second, it was cut and paste, and I only noticed after send. Eric From owner-ietf-provreg@cafax.se Tue Mar 4 11:54: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 LAA00966 for ; Tue, 4 Mar 2003 11:54:28 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24GamW1004517 for ; Tue, 4 Mar 2003 17:36:48 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24Gam7Z004516 for ietf-provreg-outgoing; Tue, 4 Mar 2003 17:36: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.8/8.12.8) with ESMTP id h24GajW1004510 for ; Tue, 4 Mar 2003 17:36: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 h24GYftY083827; Tue, 4 Mar 2003 11:34:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041634.h24GYftY083827@nic-naa.net> To: Jaap Akkerhuis cc: 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, 04 Mar 2003 16:31:02 +0100." <200303041531.h24FV2pE026589@bartok.sidn.nl> Date: Tue, 04 Mar 2003 11:34:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Two followups for a charater change. Covered in my prior reply. > You said: > > 1. Application of the IESG proposal to "technical" data. > ... > other than error upon query or transform. I can't imagine an application > to an address registry's operational practices, but I don't have direct > knowledge of address registry or registrar operational art. > > That shows. Note I said, that this was a hypothetical case. OK. We're past technical issues, and on to list dysfunction. It is a small matter. Eric From owner-ietf-provreg@cafax.se Wed Mar 5 22:02:14 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 WAA10953 for ; Wed, 5 Mar 2003 22:02:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h262p3W1026965 for ; Thu, 6 Mar 2003 03:51:03 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h262p3C5026964 for ietf-provreg-outgoing; Thu, 6 Mar 2003 03:51:03 +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.8/8.12.8) with ESMTP id h262p1W1026959 for ; Thu, 6 Mar 2003 03:51:02 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h262orKI025629 for ; Wed, 5 Mar 2003 21:50:58 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303060250.h262orKI025629@nic-naa.net> To: ietf-provreg@cafax.se Subject: [ietf-provreg] Synchronisity Date: Wed, 05 Mar 2003 21:50:53 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk All, Context - new IRTF trainwreck, gazillion opinion posts posing as charter wrangles. In a nutshell ... >> ...which violates german privacy laws... > I guess different cultures have different ideas of privacy... We're not alone. There is unintelligent life in the universe. Eric P.S. To be cheritable, relay is in theory some form of onward-transport problem. Contrast this with geopriv, which is a captive-leaf (roaming) problem. Geopriv has done a new document cycle, if anyone cares. ------- Forwarded Message From: Keith Moore To: Hadmut Danisch Cc: moore@cs.utk.edu, raymie@cs.ucsc.edu, Asrg@ietf.org Subject: Re: [Asrg] desirable characteristics of source tracking (was: Requirements for source tracking) ... > > > > What I might like to know are things like: > > > > a. is the sender's account new, or has it been around awhile? > > b. does the source ISP have a reliable way to bill the sender? > > (or is this from someone who got a 100 hours free CD in the mail?) > > c. have there been many complaints about mail from this sender? > > > ...which violates german privacy laws... > > Privacy is fortunately highly protected over here. let me get this straight - it's not a violation of privacy to insist on knowing the real identity of someone who sent a message, but it is a violation of privacy to provide a slight bit of additional information about an anonymous or pseudonymous sender? I guess different cultures have different ideas of privacy... that's okay - there's no reqirement for the ISP to provide such information. but if the ISP can legally do so, and is willing to do so, then the sender can provide preferential treatment of the message. I don't think we're going to end up with a uniform global solution for spam in any case, because different people and different cultures vary not only according to what kinds of protection they consider important, but also in what they consider offensive or unacceptable. Keith _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg ------- End of Forwarded Message From owner-ietf-provreg@cafax.se Thu Mar 6 04:20: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 EAA29277 for ; Thu, 6 Mar 2003 04:20:06 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26955W1029775 for ; Thu, 6 Mar 2003 10:05:05 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26955Cb029774 for ietf-provreg-outgoing; Thu, 6 Mar 2003 10:05:05 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from lazzaro.bertola.eu.org (net-197-95.noicomnet.it [194.153.197.95]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h26951W1029766 for ; Thu, 6 Mar 2003 10:05:02 +0100 (MET) Received: (qmail 19204 invoked from network); 6 Mar 2003 09:12:35 -0000 Received: from unknown (HELO PIETRO) (10.0.1.2) by 0 with SMTP; 6 Mar 2003 09:12:35 -0000 From: Vittorio Bertola To: Eric Brunner-Williams in Portland Maine Cc: "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 06 Mar 2003 10:06:02 +0100 Message-ID: <7i2e6vo2jt88gtur2jupb3ok5uf5oc5a8m@4ax.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337076C@vsvapostal3.prod.netsol.com> <200303031547.h23FlqtY079531@nic-naa.net> In-Reply-To: <200303031547.h23FlqtY079531@nic-naa.net> X-Mailer: Forte Agent 1.9/32.560 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h26952W1029767 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, 03 Mar 2003 10:47:52 -0500, you wrote: >> The third is a message describing the EU perspective on why this must >> be solved. > >Oh thank heavens! A live EU national who is a self-described "newbie" and >neither an implementor, nor an operator, nor an author, nor apparently a >specification reader. Now I can stop thinking. Just for the sake of precision... I am an ICT engineer, I've been reading and using RFCs for the last 8 years, and I am sufficiently geek to often use e-mail by telnet 25/110 :-) I do not work in the domain name business and I am a newbie in this working group, and this is why I don't want to make suggestions about the technicalities, given that you all here have been discussing them for years. So I'm just lurking the list as often as I can. But the CRISP group has found my suggestions useful enough to include them in the latest CRISP requirements draft. >Note Bene Chair: > 1. IESG (Randy or Allison) asked and answered > 2. IESG (Patrick) asked and answered > 3. .NL asked and not responsive > 4. .PL asked and not responsive > 5. Newbie noises My intention was not to produce "noise" but just to help the group understanding the issues at stake from a different perspective. Please pardon me if I failed in this. (However this thread is going off topic, so please consider replying in private.) -- vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From owner-ietf-provreg@cafax.se Thu Mar 6 08:23:55 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 IAA12568 for ; Thu, 6 Mar 2003 08:23:48 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26DCrW1002563 for ; Thu, 6 Mar 2003 14:12:53 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26DCrlA002562 for ietf-provreg-outgoing; Thu, 6 Mar 2003 14:12: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.8/8.12.8) with ESMTP id h26DCnW1002557 for ; Thu, 6 Mar 2003 14:12:52 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h26DCXKI027905; Thu, 6 Mar 2003 08:12:33 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303061312.h26DCXKI027905@nic-naa.net> To: Vittorio Bertola cc: 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, 06 Mar 2003 10:06:02 +0100." <7i2e6vo2jt88gtur2jupb3ok5uf5oc5a8m@4ax.com> Date: Thu, 06 Mar 2003 08:12:33 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk CRISP, WHOISFIX, NOT43, ... deal with publication protocols. DNSOP, DNSSEC, ... also deal with publication protocls. Generally, they start with some authoritative instance of some datum, and unconditionally replicate non-authoritative copies of that datum. The access and persistence properties of these do not subset the maximums for both generally. PROVREG and its anticeedents, the DOMREG BoF(s) and the authors of RRP, ... deal with provisioning protocols. Generally, they start with some non-authoritative instance of some datum, and conditionally allocate an authoritative instance of that datum. The access and persistence properties of these subset the maximums for both generally. OTHER PUBLICATION PROTOCOLS EXIST. Bulk copy, with "sale", "lease" and "rent" of mailing lists, postal and electronic, exists. Some implementations use "sneaker net". Other technical mechanisms, which exploit properties of domain name data in particular, the nameserver, technical and administrative contact, even the character space properties of a domain name (marks, soundex, Hamming Distrance from, ...) which REPURPOSE data, also exist. Data provisioned via protocol (RRP, SRS, EPP, ... NEXT) may be merged with data acquired by other means. Since the beginning of this Working Group, there have been contributors who want to "solve" the 954 problem within EPP. This approach does not solve for other publication mechanisms, nor does it solve for the user informed portion of the informed consent meta-requirement placed on all data collectors by 95/46/EC and related texts that address directories, and related tools for the management of endpoint identifiers which may identify individual persons. If the better reading of 95/46/EC et seq. is that it applies to port 43, and originators need only (may only) make port-specific negative assertions, then a "publication" framework (yours and others, e.g., the IESG) may be sufficient. Having done this twice before, I don't think so. Besides, I don't know that EPP can't be used for keyword systems, that may not use :43, and for anything similar. It would work for the US, and anywhere else where the IAB (the other one, the Internet Advertising Board) and the DMA (Direct Marketing Association) and similar trade groups control the "opt-in vs opt-out" policy issue. I now know it would work in Holland also. I don't understand this, but the European Data Commissioners I've communicated with over the past three years are French and German, so I've obviously missed something. Pointing out a specific defect in the element's sub-schema would be really useful. Eric From owner-ietf-provreg@cafax.se Thu Mar 6 11:15: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 LAA24115 for ; Thu, 6 Mar 2003 11:14:54 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26G4BW1004451 for ; Thu, 6 Mar 2003 17:04:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26G4BlA004450 for ietf-provreg-outgoing; Thu, 6 Mar 2003 17:04:11 +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.8/8.12.8) with ESMTP id h26G4AW1004445 for ; Thu, 6 Mar 2003 17:04:10 +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 h26G44JW012590 for ; Thu, 6 Mar 2003 11:04:04 -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 LAA09958; Thu, 6 Mar 2003 11:04:03 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 6 Mar 2003 11:03:58 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] proto-agenda Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Based on what I've seen on the list: 1) Getting to the bottom of the privacy issue - the one in front of us, that is. 2) Alternate transports 3) IDN in EPP Does anyone still want to discuss a problem with ROID? Here are action items I recorded in December: 1. Respond to the IESG comments. Most of the comments are easily addressed. A few need further discussion (and are listed as separate action items). 2. Come to a final understanding of UDP and EPP. There have been some words posted to the "outlawing" of UDP, one response was to require stream based protocols. 3. Clarify the adoption of P3P concepts. P3P was written for website environments, not a business to business situation. This is reflected in some of our examples and needs to be cleaned up. Rick Wesson volunteered to summarize a discussion on privacy issues. It might be up to us to forge new ground here as we are one of the few protocols that gathers personal information (for registration information). 4. Whether or not we adopt a work item for the SOAP 'as transport' draft. A thread has been started on the list, but the results are luke warm for now. 5. An SMTP mapping is all but dead in the water. Unless someone objects on the mail list, we're dropping all milestones relating to SMTP. 6. Continue to progress on Guidelines. No sense of urgency, at least not until we get #1 above done. Two other action items... 7. Clean up the milestones. After the meeting we talked and decided that the milestones on the web page aren't sufficiently descriptive. Before fixing them, #4 and #5 need answers. 8. Discuss 'lastVerified' - mandatory, extension or optional 9. Discuss handling of external hosts -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Thu Mar 6 11:57:50 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 LAA28187 for ; Thu, 6 Mar 2003 11:57:48 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26GokW1005102 for ; Thu, 6 Mar 2003 17:50:46 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26GokFv005101 for ietf-provreg-outgoing; Thu, 6 Mar 2003 17:50: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.8/8.12.8) with ESMTP id h26GojW1005096 for ; Thu, 6 Mar 2003 17:50:45 +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 h26GoiJW014691; Thu, 6 Mar 2003 11:50:44 -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 LAA18931; Thu, 6 Mar 2003 11:50:43 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303041237.HAD10017.NBPO@humeia.ad.jp> References: <200303041237.HAD10017.NBPO@humeia.ad.jp> Date: Thu, 6 Mar 2003 11:30:19 -0500 To: Hideki Noma From: Edward Lewis Subject: Re: [ietf-provreg] URL element in contact mapping Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk The WG (which is the mailing list) has not heard of this before, so we are unable to send you a reference. We would appreciate more information on this topic so that the protocol is capable of handling all it needs to handle. At 12:37 +0900 3/4/03, Hideki Noma wrote: >Hello, > >There will be a URL element introduced in .JP contact information in >near future. >And I beleive that some sort of element representing a URL of domain >owner or contact >is necessary.In fact whois.internic.net has both url element of >whois server and >web server. > >I understand that url element should be optional or even, extention >implemented by registrars, >however the element name must be standardized. I don't know why JP >registry is not commenting on >this but as one of JP registrar, I strongly request it. > >If there has been a discussion around this topic I've missed it, >please point me >where to look at. > >Hideki Noma >Humeia Limited Partnership -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Thu Mar 6 12:00:03 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 MAA28354 for ; Thu, 6 Mar 2003 12:00:02 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26GqbW1005140 for ; Thu, 6 Mar 2003 17:52:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26Gqb0q005139 for ietf-provreg-outgoing; Thu, 6 Mar 2003 17:52:37 +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.8/8.12.8) with ESMTP id h26GohW1005095 for ; Thu, 6 Mar 2003 17:50: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 h26GogJW014685; Thu, 6 Mar 2003 11:50:42 -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 LAA18606; Thu, 6 Mar 2003 11:49:21 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303031547.h23FlqtY079531@nic-naa.net> References: <200303031547.h23FlqtY079531@nic-naa.net> Date: Thu, 6 Mar 2003 11:14:32 -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" , "'Edward Lewis'" , "'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 At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: >adding attributes to elements is either pervasive, or specific. As this >WG lost the technical/social distinction with the expiry of Ross' draft, What parts of the material in Ross' draft need to be added (as terminology definitions) in the base spec (or base spec-bis)? >954 that is of issue, particularly in the EU, but also in the OEDC, and What is OEDC? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Thu Mar 6 12:48: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 MAA02791 for ; Thu, 6 Mar 2003 12:48:10 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26Hh1W1005865 for ; Thu, 6 Mar 2003 18:43:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26Hh1fA005864 for ietf-provreg-outgoing; Thu, 6 Mar 2003 18:43:01 +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.8/8.12.8) with ESMTP id h26HgxW1005858 for ; Thu, 6 Mar 2003 18:42:59 +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 MAA24263; Thu, 6 Mar 2003 12:42:52 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 12:40:15 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707A3@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 6 Mar 2003 12:40:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: > >adding attributes to elements is either pervasive, or > specific. As this > >WG lost the technical/social distinction with the expiry of > Ross' draft, > > What parts of the material in Ross' draft need to be added (as > terminology definitions) in the base spec (or base spec-bis)? Note that section 1.1 of requirements RFC 3375 includes parenthetical descriptions for "social" and "technical" information in the definition of a "thick" registry. -Scott- From owner-ietf-provreg@cafax.se Thu Mar 6 16:48: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 QAA14447 for ; Thu, 6 Mar 2003 16:48:06 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26LcDW1008376 for ; Thu, 6 Mar 2003 22:38:13 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26LcDl5008375 for ietf-provreg-outgoing; Thu, 6 Mar 2003 22:38:13 +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.8/8.12.8) with ESMTP id h26LcCW1008370 for ; Thu, 6 Mar 2003 22:38:12 +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 h26LcBJW030950; Thu, 6 Mar 2003 16:38:11 -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 QAA13229; Thu, 6 Mar 2003 16:38:10 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 6 Mar 2003 16:38:02 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] Fwd: Re: provreg milestones Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h26LcCW1008371 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Also to the group - as far as the privacy thing being resolved, I'm a bit hesitant to declare consensus yet to the proposal in: # From: "Hollenbeck, Scott" # Date: Mon, 3 Mar 2003 13:02:34 -0500 # # As far as .com is concerned, I have no doubt that an extension will be # required even if we were to adopt the IESG's element tagging suggestion. # That being the case, my preference would be to put _all_ of the DNP syntax # and semantics into an extension (where the problem can be addressed as a # whole) while making the existing DCP element mandatory if that resolves the # privacy issue with the IESG. (Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) So let me hear about that... >Date: Thu, 6 Mar 2003 21:48:31 +0100 >Subject: Re: provreg milestones >Cc: jaap@sidn.nl, Ted Hardie >To: Edward Lewis >From: Patrik Fältström >X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) >FILETIME=[C2ED4AE0:01C2E421] >Status: > >This looks good. > >Please send the new milestones to iesg-secretary@ietf.org. > >I also understand the privacy thing is now resolved. I saw a few >messages on the mailing list about it. > >May I suggest you (or someone) write a summary of what the solution >is, and send it to me, randy, allison (and also cc Ned and Ted as >co-AD's -- yes, Ted is formally not onboard, but anyway). You can of >course also cc the mailing list if you want to. > > paf > >On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote: > >> I've heard no response to this from 'above.' >> >> The FEB 03 milestone now should be MAR 03 I guess. >> >>> Date: Fri, 31 Jan 2003 10:14:40 -0500 >>> To: paf@cisco.com, jaap@sidn.nl >>> From: Edward Lewis >>> Subject: provreg milestones >>> Cc: edlewis@arin.net, ietf-provreg@cafax.se >>> Bcc: >>> X-Attachments: >>> >>> While we still have an open issue with regards to privacy, I want >>>to move on and at least refresh the group's milestones. >>> >>> FEB 03 Respond to the IESG Comments (for Proposed) >>> MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational) >>> APR 03 Decision on Alternate Transports >>> SEP 03 Perform Interoperability Tests >>> OCT 03 Submit Interoperability Report to IESG (Informational) >>> OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft) >>> OCT 03 Submit EPP Contact Mapping to IESG (Draft) >>> OCT 03 Submit EPP Domain Name Mapping to IESG (Draft) >>> OCT 03 Submit EPP Host Mapping to IESG (Draft) >>> OCT 03 Submit EPP Transport Over TCP to IESG (Draft) >>> >>> Look these over carefully. I added the first because we haven't >>>closed that off, as well as having some potential threads to cover >>>in addition to the privacy question. >>> >>> A "Decision on Alternate Transports" is on there because our >>>charter talks about "support for multiple operational choices, >>>such as for transport". At times support has been expressed for >>>BEEP, SMTP, and SOAP, but none have garnered much support. My >>>vague opinion is that alternate transports will need to come with >>>code, not just documents, before they can be taken seriously by >>>the WG. >>> >>> Note that SMTP and SOAP milestones are not on there. Not to >>>denigrate the work, but they haven't made it to general interest >>>for the WG. >>> >>> With this message I am asking our AD to approve these milestones, >>>we can adjust them as necessary. >> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis +1-703-227-9854 >> ARIN Research Engineer >> > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Thu Mar 6 18:10:30 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 SAA17707 for ; Thu, 6 Mar 2003 18:10:28 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26N5FW1009216 for ; Fri, 7 Mar 2003 00:05:15 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26N5FqH009215 for ietf-provreg-outgoing; Fri, 7 Mar 2003 00:05:15 +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.8/8.12.8) with ESMTP id h26N5EW1009207 for ; Fri, 7 Mar 2003 00:05:14 +0100 (MET) Received: from dev7.int.libertyrms.com ([10.1.2.225] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18r4QA-0006oy-00; Thu, 06 Mar 2003 18:05:02 -0500 Message-ID: <3E67D62A.3020609@libertyrms.info> Date: Thu, 06 Mar 2003 18:13:46 -0500 From: Daniel Manley User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.3b) Gecko/20030212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se, jaap@sidn.nl Subject: Re: [ietf-provreg] Fwd: Re: provreg milestones References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Here's my vote for consensus. Let's put this to rest. This solution addresses enough to declare privacy policy to EPP clients. With the variety of privacy policies out there in the world, putting client overrides into the extension framework keep this flexible for all parties involved. EPP's been all about extensibility from the start. Dan Edward Lewis wrote: > Also to the group - as far as the privacy thing being resolved, I'm a > bit hesitant to declare consensus yet to the proposal in: > > # From: "Hollenbeck, Scott" > # Date: Mon, 3 Mar 2003 13:02:34 -0500 > # > # As far as .com is concerned, I have no doubt that an extension will be > # required even if we were to adopt the IESG's element tagging > suggestion. > # That being the case, my preference would be to put _all_ of the DNP > syntax > # and semantics into an extension (where the problem can be addressed > as a > # whole) while making the existing DCP element mandatory if that > resolves the > # privacy issue with the IESG. > > (Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) > > So let me hear about that... > >> Date: Thu, 6 Mar 2003 21:48:31 +0100 >> Subject: Re: provreg milestones >> Cc: jaap@sidn.nl, Ted Hardie >> To: Edward Lewis >> From: Patrik Fältström >> X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) >> FILETIME=[C2ED4AE0:01C2E421] >> Status: >> >> This looks good. >> >> Please send the new milestones to iesg-secretary@ietf.org. >> >> I also understand the privacy thing is now resolved. I saw a few >> messages on the mailing list about it. >> >> May I suggest you (or someone) write a summary of what the solution >> is, and send it to me, randy, allison (and also cc Ned and Ted as >> co-AD's -- yes, Ted is formally not onboard, but anyway). You can of >> course also cc the mailing list if you want to. >> >> paf >> >> On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote: >> >>> I've heard no response to this from 'above.' >>> >>> The FEB 03 milestone now should be MAR 03 I guess. >>> >>>> Date: Fri, 31 Jan 2003 10:14:40 -0500 >>>> To: paf@cisco.com, jaap@sidn.nl >>>> From: Edward Lewis >>>> Subject: provreg milestones >>>> Cc: edlewis@arin.net, ietf-provreg@cafax.se >>>> Bcc: >>>> X-Attachments: >>>> >>>> While we still have an open issue with regards to privacy, I want >>>> to move on and at least refresh the group's milestones. >>>> >>>> FEB 03 Respond to the IESG Comments (for Proposed) >>>> MAR 03 Submit Guidelines for Extending the EPP to IESG >>>> (Informational) >>>> APR 03 Decision on Alternate Transports >>>> SEP 03 Perform Interoperability Tests >>>> OCT 03 Submit Interoperability Report to IESG (Informational) >>>> OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft) >>>> OCT 03 Submit EPP Contact Mapping to IESG (Draft) >>>> OCT 03 Submit EPP Domain Name Mapping to IESG (Draft) >>>> OCT 03 Submit EPP Host Mapping to IESG (Draft) >>>> OCT 03 Submit EPP Transport Over TCP to IESG (Draft) >>>> >>>> Look these over carefully. I added the first because we haven't >>>> closed that off, as well as having some potential threads to cover >>>> in addition to the privacy question. >>>> >>>> A "Decision on Alternate Transports" is on there because our >>>> charter talks about "support for multiple operational choices, >>>> such as for transport". At times support has been expressed for >>>> BEEP, SMTP, and SOAP, but none have garnered much support. My >>>> vague opinion is that alternate transports will need to come with >>>> code, not just documents, before they can be taken seriously by the >>>> WG. >>>> >>>> Note that SMTP and SOAP milestones are not on there. Not to >>>> denigrate the work, but they haven't made it to general interest >>>> for the WG. >>>> >>>> With this message I am asking our AD to approve these milestones, >>>> we can adjust them as necessary. >>> >>> >>> -- >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> Edward Lewis +1-703-227-9854 >>> ARIN Research Engineer >>> >> From owner-ietf-provreg@cafax.se Thu Mar 6 18:10:47 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 SAA17746 for ; Thu, 6 Mar 2003 18:10:46 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26N6eW1009233 for ; Fri, 7 Mar 2003 00:06:40 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26N6eQa009232 for ietf-provreg-outgoing; Fri, 7 Mar 2003 00:06:40 +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.8/8.12.8) with ESMTP id h26N6cW1009227 for ; Fri, 7 Mar 2003 00:06:39 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h26N6R2r038772; Thu, 6 Mar 2003 18:06:27 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303062306.h26N6R2r038772@nic-naa.net> To: "Hollenbeck, Scott" cc: "'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, 06 Mar 2003 12:40:24 EST." <3CD14E451751BD42BA48AAA50B07BAD6033707A3@vsvapostal3.prod.netsol.com> Date: Thu, 06 Mar 2003 18:06:27 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: > > >adding attributes to elements is either pervasive, or > > specific. As this > > >WG lost the technical/social distinction with the expiry of > > Ross' draft, > > > > What parts of the material in Ross' draft need to be added (as > > terminology definitions) in the base spec (or base spec-bis)? > > Note that section 1.1 of requirements RFC 3375 includes parenthetical > descriptions for "social" and "technical" information in the definition of a > "thick" registry. See: Subject: Is it "social" or is it "model" or is it "mechanism"? Sent to this list on 02.13.03 We simply need to seperate the thick/thin (registry model) from the publication mechanisms (1034/35), and be dns-specific (for a change), and speak er, write about the RRs we provision, without being Master File Format specific (and triggering a valid DJB criticism). The problem with where we left off (in 3375 and with Ross' -dn-), is that we were letting the RRP vs EPP (thick/thin) act as our framework. Here we need to look, not at who has the data, but at what data has what kind of function. Almost, but not quite, the same. Eric From owner-ietf-provreg@cafax.se Thu Mar 6 18:37:36 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 SAA18920 for ; Thu, 6 Mar 2003 18:36:56 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26NVaW1009431 for ; Fri, 7 Mar 2003 00:31:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26NVaat009430 for ietf-provreg-outgoing; Fri, 7 Mar 2003 00:31:36 +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.8/8.12.8) with ESMTP id h26NVZW1009425 for ; Fri, 7 Mar 2003 00:31:35 +0100 (MET) Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Thu, 06 Mar 2003 18:31:33 -0500 Message-ID: <3E67DD05.5030004@ecotroph.net> Date: Thu, 06 Mar 2003 18:43:01 -0500 From: Andrew Newton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] proto-agenda References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > > 2) Alternate transports Does this item need to be included? I just ran through the list, and the last talk of this seems to be in December, which might be summarized as: 1) a new draft was promised before Christmas (the current one expires this month), and 2) several people agreeing that it should be experimental. -andy From owner-ietf-provreg@cafax.se Thu Mar 6 19:35:29 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 TAA21751 for ; Thu, 6 Mar 2003 19:35:27 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h270UOW1010007 for ; Fri, 7 Mar 2003 01:30:24 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h270UNmS010006 for ietf-provreg-outgoing; Fri, 7 Mar 2003 01:30:23 +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.8/8.12.8) with ESMTP id h270UMW1010001 for ; Fri, 7 Mar 2003 01:30:23 +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 TAA16407; Thu, 6 Mar 2003 19:30:14 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 19:27:47 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707AD@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 6 Mar 2003 19:27:46 -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 > The problem with where we left off (in 3375 and with Ross' > -dn-), is that > we were letting the RRP vs EPP (thick/thin) act as our framework. Here > we need to look, not at who has the data, but at what data > has what kind > of function. Almost, but not quite, the same. This is where you start to lose me. What data functions (beyond the provisioning and management of the data itself) are in-scope for us? -Scott- From owner-ietf-provreg@cafax.se Thu Mar 6 20:05:57 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 UAA22363 for ; Thu, 6 Mar 2003 20:05:55 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2711kW1010263 for ; Fri, 7 Mar 2003 02:01:46 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2711knY010262 for ietf-provreg-outgoing; Fri, 7 Mar 2003 02: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.8/8.12.8) with ESMTP id h2711jW1010257 for ; Fri, 7 Mar 2003 02:01:45 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h2711Z2r039178; Thu, 6 Mar 2003 20:01:35 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303070101.h2711Z2r039178@nic-naa.net> To: "Hollenbeck, Scott" cc: "'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, 06 Mar 2003 19:27:46 EST." <3CD14E451751BD42BA48AAA50B07BAD6033707AD@vsvapostal3.prod.netsol.com> Date: Thu, 06 Mar 2003 20:01:35 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk The distinction between "social" (billing) and "technical" (zone files) is not quite the same as between registrar-retained-authoritative (RRP) and registry-retained-authoritative (EPP). If we're going to create two (or more) baskets to put data into, which would allow some alternate to the session-scoped that has basket-of-stuff-scope, then we need to define the baskets, but without dependency upon the distinction of RRP vs EPP, and "thin" vs "thick" registry models. Humor me. In a "pure thin EPP", there'd be no whois:43 issue for the protocol, the registry would never see anything but NS and A records. That liability would remain with the registrars and their whois servers. In a "pure thick EPP" (what we're writing), there is data that is published via 1034/35 (NS and A records), and data that is published via 954 (everything, including personally identifying registrant data). We can't define a distinction in a "pure thick EPP" specification by making direct, or indirect reference or comparison to the RRP model. At least, not without something like a dangling pointer. I've used "pure" in the para above because some registrars are also registries, though not necessarily of the same namespaces, and I want to ignore the complication of a registrar who is a whois operator (RRP) as well as a registry operator, and a registrar who is not a whois operator (EPP) as well as a registry operator that is a whois operator. That kind of stuff gets me dizzy. So, if we say publication via 1034/35, of A and NS records (we're domain name specific, at least momentarily, and "privacy/data collection" may not mean the same thing, or anything, in an address registry context, or other possible SRS contexts), _is_ technical data, and everything else isn't (which is almost what we had), then we may have a useful definition. It may help (or I may be going out unnecessarily on a limb) if we make the distinction between non-technical data and data that is sufficient to construct persistent unique identifiers. If it helps, in the 95/46/EC context, the 32 bits of an ipv4 endpoint identifer is subject to data collection disclosure, hence the (IMO lame) definition in P3P of a 25 bit addr as something other than "personally identifying" (a unique endpoint identifier, or one that can be resonably constructed from the collected data). Names, telnos, postals, ips fit into this. Admin and Tech contacts don't. Mind, the simpler course is to stay with a session-scoped policy dingus, and not dive into what data means what when and to whom. It may not seem like it, but I'm a big fan of _simple_. manditory. Eric From owner-ietf-provreg@cafax.se Fri Mar 7 07:34: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 HAA26459 for ; Fri, 7 Mar 2003 07:34:44 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27CPqW1015669 for ; Fri, 7 Mar 2003 13:25:52 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27CPqeq015668 for ietf-provreg-outgoing; Fri, 7 Mar 2003 13:25: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.8/8.12.8) with ESMTP id h27CPoW1015661 for ; Fri, 7 Mar 2003 13:25:51 +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 HAA08482; Fri, 7 Mar 2003 07:25:43 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 07:23:15 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707AF@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones Date: Fri, 7 Mar 2003 07:23:14 -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 > Also to the group - as far as the privacy thing being resolved, I'm a > bit hesitant to declare consensus yet to the proposal in: > > # From: "Hollenbeck, Scott" > # Date: Mon, 3 Mar 2003 13:02:34 -0500 > # > # As far as .com is concerned, I have no doubt that an > extension will be > # required even if we were to adopt the IESG's element > tagging suggestion. > # That being the case, my preference would be to put _all_ of > the DNP syntax > # and semantics into an extension (where the problem can be > addressed as a > # whole) while making the existing DCP element mandatory if > that resolves the > # privacy issue with the IESG. > > (Aka - > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) > > So let me hear about that... Ed, please note these supporting comments sent prior to your note: http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00015.html http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00023.html -Scott- From owner-ietf-provreg@cafax.se Fri Mar 7 08:25:23 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 IAA00327 for ; Fri, 7 Mar 2003 08:25:21 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27DDWh3016298 for ; Fri, 7 Mar 2003 14:13:32 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27DDWqA016297 for ietf-provreg-outgoing; Fri, 7 Mar 2003 14:13:32 +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.8/8.12.8) with ESMTP id h27DDVh3016292 for ; Fri, 7 Mar 2003 14:13:31 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h27DDGWs003000; Fri, 7 Mar 2003 08:13:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303071313.h27DDGWs003000@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] proto-agenda In-Reply-To: Your message of "Thu, 06 Mar 2003 11:03:58 EST." Date: Fri, 07 Mar 2003 08:13:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk [non-attendee comments on proposed agenda.] > 3. Clarify the adoption of P3P concepts. Pointing out a specific defect in the element's sub-schema would be really useful. > 5. An SMTP mapping is all but dead in the water. > > Unless someone objects on the mail list, we're dropping all > milestones relating to SMTP. I object. > 8. Discuss 'lastVerified' - mandatory, extension or optional I think this is a bad idea sneaking in from some other policy area. I could be mistaken. > 9. Discuss handling of external hosts That should be interesting. From owner-ietf-provreg@cafax.se Fri Mar 7 09:34: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 JAA04889 for ; Fri, 7 Mar 2003 09:34:39 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27EIPh3017112 for ; Fri, 7 Mar 2003 15:18:25 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27EIPSi017111 for ietf-provreg-outgoing; Fri, 7 Mar 2003 15:18: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.8/8.12.8) with ESMTP id h27EIOh3017106 for ; Fri, 7 Mar 2003 15:18: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 h27EILJW044636; Fri, 7 Mar 2003 09:18:21 -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 JAA21855; Fri, 7 Mar 2003 09:18:20 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3E67DD05.5030004@ecotroph.net> References: <3E67DD05.5030004@ecotroph.net> Date: Fri, 7 Mar 2003 09:18:19 -0500 To: Andrew Newton From: Edward Lewis Subject: Re: [ietf-provreg] proto-agenda Cc: Edward Lewis , ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Discussing alternate transports in in our charter: "The group will consider support for multiple operational choices, such as for transport..." So far, no transport other than TCP has sparked widespread interest. One person is touting SMTP, a few others expressed support for SOAP a few months ago. It doesn't appear that there's an alternative to TCP that is on the verge of being added as a WG item, but we are chartered to explore the possibility. Note too that the list of which this is a part is not an agenda list, but the remaining unresolved items from last time. If no one has any material to discuss in SF, then alternate transports won't appear on the agenda. At 18:43 -0500 3/6/03, Andrew Newton wrote: >Edward Lewis wrote: >> 2) Alternate transports > >Does this item need to be included? > >I just ran through the list, and the last talk of this seems to be >in December, which might be summarized as: 1) a new draft was >promised before Christmas (the current one expires this month), and >2) several people agreeing that it should be experimental. > >-andy -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Fri Mar 7 09:50:55 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 JAA06564 for ; Fri, 7 Mar 2003 09:50:54 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27Ej4h3017672 for ; Fri, 7 Mar 2003 15:45:04 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h27Ej4LW017671 for ietf-provreg-outgoing; Fri, 7 Mar 2003 15:45:04 +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.8/8.12.8) with ESMTP id h27Ej2h3017666 for ; Fri, 7 Mar 2003 15:45:03 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h27EiiWs003384; Fri, 7 Mar 2003 09:44:44 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303071444.h27EiiWs003384@nic-naa.net> To: Edward Lewis cc: Andrew Newton , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] proto-agenda In-Reply-To: Your message of "Fri, 07 Mar 2003 09:18:19 EST." Date: Fri, 07 Mar 2003 09:44:44 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, There has been a note to the list about an implementation over HTTP. All things considered, -56 time available, and proximity of -57 venue to the implementor, that may be the better time to do other-than-tcp. Eric From owner-ietf-provreg@cafax.se Fri Mar 7 10:12:58 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 KAA09695 for ; Fri, 7 Mar 2003 10:12:56 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27F89h3017963 for ; Fri, 7 Mar 2003 16:08:09 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27F89iM017962 for ietf-provreg-outgoing; Fri, 7 Mar 2003 16:08:09 +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.8/8.12.8) with ESMTP id h27F88h3017957 for ; Fri, 7 Mar 2003 16:08:08 +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 h27F84JW046204; Fri, 7 Mar 2003 10:08:04 -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 KAA00406; Fri, 7 Mar 2003 10:08:03 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303071444.h27EiiWs003384@nic-naa.net> References: <200303071444.h27EiiWs003384@nic-naa.net> Date: Fri, 7 Mar 2003 10:07:57 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] proto-agenda Cc: Edward Lewis , Andrew Newton , 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 I see no rush to define another transport, but keep these 'realities' in mind: There is the expectation that this WG may stick around until we get to DS. That means that we may remain active in spite of resolving the IESG comment, getting PS documents and not spending time on issues that have flared up and then seemed to go away (ROID). In that case, discussing alt. transports at -57 might not be a bad idea. However, 1) no one can promise we will still be active then and 2) starting a discussion on the mail list at any time is preferable for waiting to start a discussion at an in-face meeting. At 9:44 -0500 3/7/03, Eric Brunner-Williams in Portland Maine wrote: >Ed, > >There has been a note to the list about an implementation over HTTP. >All things considered, -56 time available, and proximity of -57 venue >to the implementor, that may be the better time to do other-than-tcp. > >Eric -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Fri Mar 7 10:27: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 KAA10628 for ; Fri, 7 Mar 2003 10:27:15 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27FNAh3018175 for ; Fri, 7 Mar 2003 16:23:10 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27FNAlq018174 for ietf-provreg-outgoing; Fri, 7 Mar 2003 16:23:10 +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.8/8.12.8) with ESMTP id h27FN8h3018164 for ; Fri, 7 Mar 2003 16:23:08 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h27FMlWs003591; Fri, 7 Mar 2003 10:22:47 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303071522.h27FMlWs003591@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , Andrew Newton , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] proto-agenda In-Reply-To: Your message of "Fri, 07 Mar 2003 10:07:57 EST." Date: Fri, 07 Mar 2003 10:22:47 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > There is the expectation that this WG may stick around until we get > to DS. That means that we may remain active in spite of resolving > the IESG comment, getting PS documents and not spending time on > issues that have flared up and then seemed to go away (ROID). Understood. HTTP WG hung until Moore and Freed screwed around with Dave Krystol's state management mechanism draft. Too similar to the current wrangle for comfort. > In that case, discussing alt. transports at -57 might not be a bad idea. > > However, 1) no one can promise we will still be active then and 2) > starting a discussion on the mail list at any time is preferable for > waiting to start a discussion at an in-face meeting. Of course. From owner-ietf-provreg@cafax.se Fri Mar 7 10:33:28 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 KAA10991 for ; Fri, 7 Mar 2003 10:33:26 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27FTlh3018270 for ; Fri, 7 Mar 2003 16:29:47 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27FTlLV018269 for ietf-provreg-outgoing; Fri, 7 Mar 2003 16:29:47 +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.8/8.12.8) with ESMTP id h27FTjh3018262 for ; Fri, 7 Mar 2003 16:29:45 +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 18rJmx-0002to-00; Fri, 07 Mar 2003 10:29:35 -0500 Message-ID: <3E68BDE8.AFEA0DB4@libertyrms.info> Date: Fri, 07 Mar 2003 10:42:32 -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" CC: "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry References: <3CD14E451751BD42BA48AAA50B07BAD60337077B@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 "Hollenbeck, Scott" wrote: > > >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically > > evaluate to 1, or 0? > > > > The answer to this is a determining factor (to me at least) of > > whether $dnp is in the base specification or in an extension. > > As far as .com is concerned, I have no doubt that an extension will be > required even if we were to adopt the IESG's element tagging suggestion. > That being the case, my preference would be to put _all_ of the DNP syntax > and semantics into an extension (where the problem can be addressed as a > whole) while making the existing DCP element mandatory if that resolves the > privacy issue with the IESG. Making existing DCP element mandatory and dealing with other specific privacy requirements within extensions looks to me like a better way of addressing privacy issues in EPP protocol than mandatory, binary DNP attribute. > > > -Scott- Janusz Sienkiewicz From owner-ietf-provreg@cafax.se Fri Mar 7 13:00: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 NAA20239 for ; Fri, 7 Mar 2003 13:00:20 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27Hs2h3019936 for ; Fri, 7 Mar 2003 18:54:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h27Hs2xj019935 for ietf-provreg-outgoing; Fri, 7 Mar 2003 18:54:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27Hs0h3019926 for ; Fri, 7 Mar 2003 18:54:01 +0100 (MET) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h27HrsC08827; Fri, 7 Mar 2003 17:53:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 12:54:02 -0500 Message-ID: <25A36E32FDC7D511827600306E1C196201325CC5@chlaexch1.va.neustar.com> From: "Liu, Hong" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones Date: Fri, 7 Mar 2003 12:56:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h27Hs1h3019928 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Ed, I think Scott's proposal is a reasonable one going forward. I will support it. --Hong -----Original Message----- From: Edward Lewis [mailto:edlewis@arin.net] Sent: Thursday, March 06, 2003 4:38 PM To: ietf-provreg@cafax.se Cc: edlewis@arin.net; jaap@sidn.nl Subject: [ietf-provreg] Fwd: Re: provreg milestones Also to the group - as far as the privacy thing being resolved, I'm a bit hesitant to declare consensus yet to the proposal in: # From: "Hollenbeck, Scott" # Date: Mon, 3 Mar 2003 13:02:34 -0500 # # As far as .com is concerned, I have no doubt that an extension will be # required even if we were to adopt the IESG's element tagging suggestion. # That being the case, my preference would be to put _all_ of the DNP syntax # and semantics into an extension (where the problem can be addressed as a # whole) while making the existing DCP element mandatory if that resolves the # privacy issue with the IESG. (Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) So let me hear about that... >Date: Thu, 6 Mar 2003 21:48:31 +0100 >Subject: Re: provreg milestones >Cc: jaap@sidn.nl, Ted Hardie >To: Edward Lewis >From: Patrik Fältström >X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) >FILETIME=[C2ED4AE0:01C2E421] >Status: > >This looks good. > >Please send the new milestones to iesg-secretary@ietf.org. > >I also understand the privacy thing is now resolved. I saw a few >messages on the mailing list about it. > >May I suggest you (or someone) write a summary of what the solution >is, and send it to me, randy, allison (and also cc Ned and Ted as >co-AD's -- yes, Ted is formally not onboard, but anyway). You can of >course also cc the mailing list if you want to. > > paf > >On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote: > >> I've heard no response to this from 'above.' >> >> The FEB 03 milestone now should be MAR 03 I guess. >> >>> Date: Fri, 31 Jan 2003 10:14:40 -0500 >>> To: paf@cisco.com, jaap@sidn.nl >>> From: Edward Lewis >>> Subject: provreg milestones >>> Cc: edlewis@arin.net, ietf-provreg@cafax.se >>> Bcc: >>> X-Attachments: >>> >>> While we still have an open issue with regards to privacy, I want >>>to move on and at least refresh the group's milestones. >>> >>> FEB 03 Respond to the IESG Comments (for Proposed) >>> MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational) >>> APR 03 Decision on Alternate Transports >>> SEP 03 Perform Interoperability Tests >>> OCT 03 Submit Interoperability Report to IESG (Informational) >>> OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft) >>> OCT 03 Submit EPP Contact Mapping to IESG (Draft) >>> OCT 03 Submit EPP Domain Name Mapping to IESG (Draft) >>> OCT 03 Submit EPP Host Mapping to IESG (Draft) >>> OCT 03 Submit EPP Transport Over TCP to IESG (Draft) >>> >>> Look these over carefully. I added the first because we haven't >>>closed that off, as well as having some potential threads to cover >>>in addition to the privacy question. >>> >>> A "Decision on Alternate Transports" is on there because our >>>charter talks about "support for multiple operational choices, >>>such as for transport". At times support has been expressed for >>>BEEP, SMTP, and SOAP, but none have garnered much support. My >>>vague opinion is that alternate transports will need to come with >>>code, not just documents, before they can be taken seriously by >>>the WG. >>> >>> Note that SMTP and SOAP milestones are not on there. Not to >>>denigrate the work, but they haven't made it to general interest >>>for the WG. >>> >>> With this message I am asking our AD to approve these milestones, >>>we can adjust them as necessary. >> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis +1-703-227-9854 >> ARIN Research Engineer >> > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Fri Mar 7 15:56:20 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 PAA02206 for ; Fri, 7 Mar 2003 15:56:18 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27KpfDc021937 for ; Fri, 7 Mar 2003 21:51:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h27Kpfq2021936 for ietf-provreg-outgoing; Fri, 7 Mar 2003 21:51:41 +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.8/8.12.8) with ESMTP id h27KpeDc021928 for ; Fri, 7 Mar 2003 21:51:40 +0100 (MET) Received: from eagle (ismtp.afilias.com [216.217.55.254]) (authenticated) by ns01.afilias.info (8.11.6/8.11.6) with ESMTP id h27KpLF32504; Fri, 7 Mar 2003 15:51:21 -0500 Message-ID: <1c2b01c2e4eb$4e5cfe80$4402a8c0@afilias.com> From: "Ram Mohan" To: "Hollenbeck, Scott" , "'Edward Lewis'" , Cc: References: <3CD14E451751BD42BA48AAA50B07BAD6033707AF@vsvapostal3.prod.netsol.com> Subject: Re: [ietf-provreg] Fwd: Re: provreg milestones Date: Fri, 7 Mar 2003 15:35:59 -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 agreed, both personally and for the .info registry. -ram ----- Original Message ----- From: "Hollenbeck, Scott" To: "'Edward Lewis'" ; Cc: Sent: Friday, March 07, 2003 7:23 AM Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones > > Also to the group - as far as the privacy thing being resolved, I'm a > > bit hesitant to declare consensus yet to the proposal in: > > > > # From: "Hollenbeck, Scott" > > # Date: Mon, 3 Mar 2003 13:02:34 -0500 > > # > > # As far as .com is concerned, I have no doubt that an > > extension will be > > # required even if we were to adopt the IESG's element > > tagging suggestion. > > # That being the case, my preference would be to put _all_ of > > the DNP syntax > > # and semantics into an extension (where the problem can be > > addressed as a > > # whole) while making the existing DCP element mandatory if > > that resolves the > > # privacy issue with the IESG. > > > > (Aka - > > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) > > > > So let me hear about that... > > Ed, please note these supporting comments sent prior to your note: > > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00015.html > > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00023.html > > -Scott- > From owner-ietf-provreg@cafax.se Mon Mar 10 13:04:51 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 NAA05977 for ; Mon, 10 Mar 2003 13:04:43 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AHsOx9019498 for ; Mon, 10 Mar 2003 18:54:24 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AHsOkq019497 for ietf-provreg-outgoing; Mon, 10 Mar 2003 18:54:24 +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.8/8.12.8) with ESMTP id h2AHsCx9019477 for ; Mon, 10 Mar 2003 18:54:12 +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 h2AHsAJW001413; Mon, 10 Mar 2003 12:54:10 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA19642; Mon, 10 Mar 2003 12:54:08 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: Date: Mon, 10 Mar 2003 08:08:29 -0800 To: paf@cisco.com, Ted Hardie , Ned Freed , randy@psg.com From: Edward Lewis Subject: [ietf-provreg] provreg's privacy issue Cc: ietf-provreg@cafax.se, shollenbeck@verisign.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk In response to the IESG comment: why do domain/contact/.. not have granular information about privacy? The provreg WG has apparently reached consensus upon this suggestion: That being the case, my preference would be to put _all_ of the DNP syntax and semantics into an extension (where the problem can be addressed as a whole) while making the existing DCP element mandatory if that resolves the privacy issue with the IESG. For the WG, Scott Hollenbeck will make the necessary changes to the base specification to reflect this consensus. (Scott: please do this as soon as you get the chance.[0]) It would help the IESG to see the formalized text based on this. Returning to the IESG review of these documents sometime around October, we feel that we have addressed all of the comments now. As soon as the new documents hit the repository, we ask that the IESG resume its review of the specifications. [0] Yeah, I realize that drafts submissions are being held up until after the IETF meeting week. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Mar 10 13:04: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 NAA05982 for ; Mon, 10 Mar 2003 13:04:48 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AHsGx9019488 for ; Mon, 10 Mar 2003 18:54:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AHsFRw019487 for ietf-provreg-outgoing; Mon, 10 Mar 2003 18:54:15 +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.8/8.12.8) with ESMTP id h2AHsEx9019482 for ; Mon, 10 Mar 2003 18:54:15 +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 h2AHsEJW001416; Mon, 10 Mar 2003 12:54:14 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA19652; Mon, 10 Mar 2003 12:54:13 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: Date: Mon, 10 Mar 2003 08:47:17 -0800 To: agenda@ietf.org, ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] provreg agenda for SF Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Provreg: Thursday, March 20, 9-11:30 1. Agenda Bashing 2. WG status (where we are document-wise) 3. Current status of the IESG review draft-ietf-provreg-epp-08.txt draft-ietf-provreg-epp-contact-06.txt draft-ietf-provreg-epp-domain-06.txt draft-ietf-provreg-epp-host-06.txt draft-ietf-provreg-epp-tcp-06.txt 4. Extending EPP document draft-ietf-provreg-epp-ext-00.txt 5. Other issues with the Base Spec Issues have been raised and mostly dropped over the past few months. No issue to date seems to have generated enough interest to halt publication as a Proposed Standard. (Speak now or hold your peace until Draft Standard.) 6. Other Transports This is in our charter, proposals to do this pop up, but no effort has been sustained. 7. Special Request: IDN in EPP A request to discuss this has been made. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Mar 10 13:24: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 NAA06702 for ; Mon, 10 Mar 2003 13:24:33 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIFlx9019803 for ; Mon, 10 Mar 2003 19:15:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIFlVS019802 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:15:47 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIFax9019797 for ; Mon, 10 Mar 2003 19:15:36 +0100 (MET) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2AIDheh004586; Mon, 10 Mar 2003 19:13:48 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 10 Mar 2003 19:15:29 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 10 Mar 2003 19:15:29 +0100 Date: Mon, 10 Mar 2003 19:15:21 +0100 Subject: [ietf-provreg] Re: provreg's privacy issue Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com To: Edward Lewis From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-Id: <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 10 Mar 2003 18:15:29.0383 (UTC) FILETIME=[08062770:01C2E731] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h2AIFax9019798 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward Lewis wrote: > Returning to the IESG review of these documents sometime around > October, we feel that we have addressed all of the comments now. Also the one from Allison which sort of disappeared in the flurry of other discussions? > As soon as the new documents hit the repository, we ask that the IESG > resume its review of the specifications. Thanks! paf From owner-ietf-provreg@cafax.se Mon Mar 10 13:47:25 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 NAA07711 for ; Mon, 10 Mar 2003 13:47:24 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIaex9020062 for ; Mon, 10 Mar 2003 19:36:40 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIaeoH020061 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:36:40 +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.8/8.12.8) with ESMTP id h2AIaSx9020056 for ; Mon, 10 Mar 2003 19:36:29 +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 NAA24774; Mon, 10 Mar 2003 13:34:55 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 13:32:21 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707CD@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Edward Lewis Cc: Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se Subject: [ietf-provreg] RE: provreg's privacy issue Date: Mon, 10 Mar 2003 13:32:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h2AIaTx9020057 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit > On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward > Lewis wrote: > > > Returning to the IESG review of these documents sometime around > > October, we feel that we have addressed all of the comments now. > > Also the one from Allison which sort of disappeared in the flurry of > other discussions? Yes -- the documents that are currently available were modified to address all of Allison's comments. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 10 13:56:37 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 NAA08105 for ; Mon, 10 Mar 2003 13:56:35 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIl0x9020183 for ; Mon, 10 Mar 2003 19:47:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIl0vk020182 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:47:00 +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.8/8.12.8) with ESMTP id h2AIknx9020177 for ; Mon, 10 Mar 2003 19:46:49 +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 h2AIknJW002947; Mon, 10 Mar 2003 13:46:49 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA28590; Mon, 10 Mar 2003 13:46:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> References: <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> Date: Mon, 10 Mar 2003 10:46:49 -0800 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Edward Lewis Subject: [ietf-provreg] Re: provreg's privacy issue Cc: Edward Lewis , Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h2AIkox9020178 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit At 19:15 +0100 3/10/03, Patrik Fältström wrote: >On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward Lewis wrote: > >> Returning to the IESG review of these documents sometime around October, we >>feel that we have addressed all of the comments now. > >Also the one from Allison which sort of disappeared in the flurry of other >discussions? We 'think' we addressed that issue long ago, the answer to it should already be in the specs in the repository. Perhaps it would be good to prepare a summary of answers to the IESG comments. >> As soon as the new documents hit the repository, we ask that the IESG >>resume its review of the specifications. > >Thanks! > > paf -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Mar 10 14:00: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 OAA08284 for ; Mon, 10 Mar 2003 14:00:10 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIpKx9020241 for ; Mon, 10 Mar 2003 19:51:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIpKdd020240 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:51:20 +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.8/8.12.8) with ESMTP id h2AIpIx9020233 for ; Mon, 10 Mar 2003 19:51:18 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h2AIoAWs064412; Mon, 10 Mar 2003 13:50:10 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303101850.h2AIoAWs064412@nic-naa.net> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Edward Lewis , Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] Re: provreg's privacy issue In-Reply-To: Your message of "Mon, 10 Mar 2003 19:15:21 +0100." <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> Date: Mon, 10 Mar 2003 13:50:10 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk I guess I missed Allison's note. It wasn't the one in reply to Rick, right? From owner-ietf-provreg@cafax.se Mon Mar 10 14:31:57 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 OAA09583 for ; Mon, 10 Mar 2003 14:31:56 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AJL7x9020691 for ; Mon, 10 Mar 2003 20:21:07 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AJL7JG020690 for ietf-provreg-outgoing; Mon, 10 Mar 2003 20:21:07 +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.8/8.12.8) with ESMTP id h2AJKux9020685 for ; Mon, 10 Mar 2003 20:20:57 +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 h2AJJ0JW004097; Mon, 10 Mar 2003 14:19:00 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA05513; Mon, 10 Mar 2003 14:18:57 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303101850.h2AIoAWs064412@nic-naa.net> References: <200303101850.h2AIoAWs064412@nic-naa.net> Date: Mon, 10 Mar 2003 11:18:52 -0800 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Re: provreg's privacy issue Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Edward Lewis , Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 13:50 -0500 3/10/03, Eric Brunner-Williams in Portland Maine wrote: >I guess I missed Allison's note. It wasn't the one in reply to Rick, right? http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html (Is that what you need?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Mar 10 22:36:55 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 WAA25790 for ; Mon, 10 Mar 2003 22:36:54 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2B3Qsx9025506 for ; Tue, 11 Mar 2003 04:26:54 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2B3Qswg025505 for ietf-provreg-outgoing; Tue, 11 Mar 2003 04:26:54 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from as01.tabata.noc.humeia.net (as01.tabata.noc.humeia.net [210.156.80.71] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2B3Qpx9025500 for ; Tue, 11 Mar 2003 04:26:53 +0100 (MET) Received: (qmail 3510 invoked by uid 0); 11 Mar 2003 03:27:07 -0000 Received: from dhcp01.kanda.noc.humeia.ad.jp (HELO noma) (noma@tabata.humeia.net@61.195.157.157) by as01.tabata.noc.humeia.net with SMTP; 11 Mar 2003 03:27:07 -0000 To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] URL element in contact mapping From: Hideki Noma References: <200303041237.HAD10017.NBPO@humeia.ad.jp> In-Reply-To: Message-Id: <200303111226.BGF35894.NOBP@humeia.ad.jp> X-Mailer: Winbiff without EditX [Version 2.41] X-Accept-Language: ja,en Date: Tue, 11 Mar 2003 12:26:24 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thank you for responding. Sorry for late action. How about this kind of element. https://ssl.d4u.jp/Contact.cgi or in case there needs some distinction on which type of url; (like as whois offered by whois.internic.net) https://ssl.d4u.jp/Contact.cgi whois.internic.net this should serve fine. Adding url parameter might help in solving the privacy issue as offering another means to contact the registrant, don't you think so? Hideki Noma Humeia Limited Partnership > The WG (which is the mailing list) has not heard of this before, so > we are unable to send you a reference. > > We would appreciate more information on this topic so that the > protocol is capable of handling all it needs to handle. > > > At 12:37 +0900 3/4/03, Hideki Noma wrote: > >Hello, > > > >There will be a URL element introduced in .JP contact information in > >near future. > >And I beleive that some sort of element representing a URL of domain > >owner or contact > >is necessary.In fact whois.internic.net has both url element of > >whois server and > >web server. > > > >I understand that url element should be optional or even, extention > >implemented by registrars, > >however the element name must be standardized. I don't know why JP > >registry is not commenting on > >this but as one of JP registrar, I strongly request it. > > > >If there has been a discussion around this topic I've missed it, > >please point me > >where to look at. > > > >Hideki Noma > >Humeia Limited Partnership > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > From owner-ietf-provreg@cafax.se Tue Mar 11 09:44:20 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 JAA20915 for ; Tue, 11 Mar 2003 09:44:18 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2BEWRx9001138 for ; Tue, 11 Mar 2003 15:32:27 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2BEWRF1001137 for ietf-provreg-outgoing; Tue, 11 Mar 2003 15:32:27 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from arachne (vianet-ispa-gw01.via.at [194.96.143.146] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2BEWQx9001129 for ; Tue, 11 Mar 2003 15:32:26 +0100 (MET) Received: from lendl by arachne with local (Exim 3.36 #1 (Debian)) id 18skno-0002vI-00 for ; Tue, 11 Mar 2003 15:32:24 +0100 Date: Tue, 11 Mar 2003 15:32:24 +0100 From: Otmar Lendl To: ietf-provreg@cafax.se Subject: [ietf-provreg] EPP/TCP server testing tools Message-ID: <20030311143224.GA11219@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Sender: owner-ietf-provreg@cafax.se Precedence: bulk As I'm in the process of polishing and testing my mod_epp (EPP as Apache 2.0 module) EPP/TCP implementation [1], I'm wondering if anybody has already done some work concerning server testing software. All the client toolkits are nice and fine for testing the EPP backend logic, but right now I'm much more interested in the EPP/TCP layer. For example: Wrong framing, arbitrary delays between header and the XML, pipelining, DoS, TCP/out-of-band, refusing to read answers, ... Can anybody share code which does these tests? /ol [1] http://sourceforge.net/projects/aepps/ (for current code see CVS.) From owner-ietf-provreg@cafax.se Tue Mar 11 10:03: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 KAA21598 for ; Tue, 11 Mar 2003 10:03:40 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2BEpxx9001356 for ; Tue, 11 Mar 2003 15:51:59 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2BEpxaJ001355 for ietf-provreg-outgoing; Tue, 11 Mar 2003 15:51: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.8/8.12.8) with ESMTP id h2BEpwx9001350 for ; Tue, 11 Mar 2003 15:51: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 JAA11660 for ; Tue, 11 Mar 2003 09:51:51 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 09:49:13 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: [ietf-provreg] Summary of IESG Comments and Disposition Date: Tue, 11 Mar 2003 09:49:12 -0500 Importance: high X-Priority: 1 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 note describes the IESG review comments that we've received and addressed in the most recent versions of the EPP specifications. Here are the references to the current documents: http://www.verisignlabs.com/draft-ietf-provreg-epp-09.txt I just finished this version today. This is a temporary location until the document is announced by the Internet-Drafts administrator after the San Francisco meeting. http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt Here are the references to the IESG comments along with a description of what was done to address them: http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html 1. Do we put mailing list names and URLs in RFCs? RESOLUTION: The paragraph describing the mailing list and archives has been removed. 2. I'd like a stronger Security Considerations section, though I think it can be added by an RFC Editor note. In particular, I want it to say that EPP "MUST NOT be used over a transport mechanism that does not provide confidentiality", or "All transport mappings for EPP MUST provide confidentiality and integrity". (I think that that's what they intend, but it's not clear enough.) RESOLUTION: The text has been changed to read "EPP instances MUST be protected using a transport mechanism or application protocol that provides integrity and confidentiality". 3. What is an "authorization token"? It's not defined, but it's mandated by the security considerations. (I suspect it's what is discussed in 2.6, but it doesn't use the same words.) RESOLUTION: The text describing an "authorization token" has been changed to use the same "authorization information" term described in section 2.6. 4. What is an "authorization token"? It's not defined, but it's mandated by the security considerations. (I suspect it's what is discussed in 2.8, but it doesn't use the same words.) RESOLUTION: The text describing an "authorization token" has been changed to use the same "authorization information" term described in section 2.8. 5. The Security Considerations section seems to require TLS client authentication, which in turn requires client certificates. Is this intended? If so, great! But in that case, what is the fate, if any, of the EPP login/password command? Is it still needed? Is it still legal? What does it mean? Must the identities agree? (The requirement for server authentication is excellent, but some more text mentioning the need to validate the certificate chain is probably a good idea.) RESOLUTION: The Security Considerations section has been modified to explicitly note the need to validate the certificate chain. The certificates used for TLS authentication authenticate the client and server machines involved in the provisioning exchange. The EPP login functionality is still needed, though, as it provides a facility to authenticate client user identities so that the server can make access control and authorization decisions based on the identity of the client, in addition to the identity of the machine the client is using to communicate with the server. 6. sec 2.1 I think it would be good to be a bit more strict about the use of congestion control protocols specifically require the use of an IETF standards track congestion control protocol such as TCP or SCTP i.e. change the following line: - The transport mapping MUST manage congestion. to: - The transport mapping MUST only be to an IETF standards track congestion control protocol such as TCP or SCTP. RESOLUTION: Section 2.1 has been modified to read as follows: "- The transport mapping MUST be onto a transport such as TCP [RFC793] or SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914 [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP [RFC3080], then the performance issues need to take into account issues of overload, server availability and so forth." 7. page 12, example greeting has: S: Example EPP server epp.example.tld in an example greeting. Did we not decide at some point that examples should be of the form: epp.example.org ?? RESOLUTION: All examples in all documents have been changed to use the example domain names (example.com, example.net, and example.org) described in RFC 2606. Sample IPv4 addresses have been changed to use the Test-Net address block listed in RFC 3330. 8. why do domain/contact/.. not have granular information about privacy? RESOLUTION: This comment has been addressed through a very lengthy discussion process that resulted in making the existing element mandatory. This change is reflected in a new version of the core protocol document that can be seen at the temporary URL provided at the top of this message. The formal announcement will be made after the San Francisco IETF meeting. http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00049.html 1. The transport mapping MUST manage congestion. RESOLUTION: See the resolution for item 6 above. http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html 1. The transport mapping MUST manage congestion. RESOLUTION: See the resolution for item 6 above. 2. Within the optional dcp (data collection policy) element: there is a non-technical spin in at least the following label definition, what kind of marketing is meant? : Contact for marketing purposes. Please add more to this definition so that is more neutral in in its terminology. RESOLUTION: The description of this element has been changed as follows: ": Contact for marketing purposes. Information can be used to contact individuals, through a communications channel other than the protocol, for the promotion of a product or service.". 3. How does IESG and the community check the extensive XML in a specification like this (analogous to the ABNF and MIB checking described that is done regularly...)? How did you check what's here? Why might it not matter? RESOLUTION: Syntax checking matters. There are a variety of freely available XML syntax checking utilities, such as the Xerces XML parser written in Java, that can be used to validate all of the schemas and examples provided in the documents. The normative schemas can be copied from the documents, edited to remove page headers and footers, and pasted together to create the formal syntax specifications for the protocol. Examples can be copied from the documents, edited to remove the "C:" and "S:" line prefixes, and pasted together to create a set of sample instances of the protocol. Scott Hollenbeck has also published external files containing all of the examples and schemas in two public places: ftp://ftp.verisign.com/pub/epp/ http://www.verisign-grs.com/files/ Other WG members are mirroring these file collections to provide additional redundancy. The examples and schemas can be run through an up-to-date validating XML parser to confirm validity. As part of the normal document editing process, Scott has been running all of the examples and schemas through the Xerces-J parser to confirm that everything remains valid according to the current W3C XML Schema specifications. 1. "An EPP client streams EPP commands to an EPP server on an established TCP connection. A client MAY establish multiple TCP connections to create multiple command exchange channels. A server MAY limit a client to a maximum number of TCP connections based on server capabilities and operational load." It is not a good thing for the net for services to choose this approach. A MAY like this is problematic for congestion control reasons. I would like to change this language from "MAY establish" to "MAY but SHOULD NOT" and from "A server MAY limit" to "A server SHOULD limit" RESOLUTION: Text changed as requested. 2. For references to TCP, besides RFC 793, you need: RFC 2581, 2914 RESOLUTION: References added. That's it! I'll try to have the updated EPP schema and example package (none of the examples changed) uploaded to the public locations as quickly as possible. -Scott- From owner-ietf-provreg@cafax.se Tue Mar 11 12:07: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 MAA28107 for ; Tue, 11 Mar 2003 12:07:20 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2BGr6x9002901 for ; Tue, 11 Mar 2003 17:53:06 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2BGr66M002900 for ietf-provreg-outgoing; Tue, 11 Mar 2003 17:53:06 +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.8/8.12.8) with ESMTP id h2BGr5x9002895 for ; Tue, 11 Mar 2003 17:53:05 +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 h2BGr2JW030793; Tue, 11 Mar 2003 11:53:02 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA21939; Tue, 11 Mar 2003 11:53:00 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> X-Priority: 1 (Highest) Date: Tue, 11 Mar 2003 08:50:12 -0800 To: "Hollenbeck, Scott" From: Edward Lewis Subject: Re: [ietf-provreg] Summary of IESG Comments and Disposition Cc: "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, thanks. I will forward the message to the IESG now (without cc'ing the list as we've all seen the text once here ;)). At 9:49 -0500 3/11/03, Hollenbeck, Scott wrote: >This note describes the IESG review comments that we've received and >addressed in the most recent versions of the EPP specifications. Here are >the references to the current documents: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Wed Mar 12 02:52:51 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 CAA25612 for ; Wed, 12 Mar 2003 02:52:48 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2C7fnx9012255 for ; Wed, 12 Mar 2003 08:41:49 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2C7fnhM012254 for ietf-provreg-outgoing; Wed, 12 Mar 2003 08:41:49 +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.8/8.12.8) with ESMTP id h2C7fmx9012249 for ; Wed, 12 Mar 2003 08:41:48 +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 h2C7faF28346; Wed, 12 Mar 2003 02:41:36 -0500 Message-ID: <008001c2e86a$cfced010$6601a8c0@afilias.com> From: "Ram Mohan" To: "Hollenbeck, Scott" , References: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> Subject: Re: [ietf-provreg] Summary of IESG Comments and Disposition Date: Wed, 12 Mar 2003 02:20:53 -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 Scott, Thanks - good work! -ram ----- Original Message ----- From: "Hollenbeck, Scott" To: Sent: Tuesday, March 11, 2003 9:49 AM Subject: [ietf-provreg] Summary of IESG Comments and Disposition > This note describes the IESG review comments that we've received and > addressed in the most recent versions of the EPP specifications. Here are > the references to the current documents: > > http://www.verisignlabs.com/draft-ietf-provreg-epp-09.txt > I just finished this version today. This is a temporary location until the > document is announced by the Internet-Drafts administrator after the San > Francisco meeting. > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt > > Here are the references to the IESG comments along with a description of > what was done to address them: > > http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html > > 1. > Do we put mailing list names and URLs in RFCs? > > RESOLUTION: The paragraph describing the mailing list and archives has been > removed. > > 2. I'd like a stronger Security Considerations section, though I think it > can be added by an RFC Editor note. In particular, I want it to say that > EPP "MUST NOT be used over a transport mechanism that does not provide > confidentiality", or "All transport mappings for EPP MUST provide > confidentiality and integrity". (I think that that's what they intend, but > it's not clear enough.) > > RESOLUTION: The text has been changed to read "EPP instances MUST be > protected using a transport mechanism or application protocol that provides > integrity and confidentiality". > > 3. > What is an "authorization token"? It's not defined, but it's mandated by > the security considerations. (I suspect it's what is discussed in 2.6, but > it doesn't use the same words.) > > RESOLUTION: The text describing an "authorization token" has been changed to > use the same "authorization information" term described in section 2.6. > > 4. > What is an "authorization token"? It's not defined, but it's mandated by > the security considerations. (I suspect it's what is discussed in 2.8, but > it doesn't use the same words.) > > RESOLUTION: The text describing an "authorization token" has been changed > to use the same "authorization information" term described in section 2.8. > > 5. > The Security Considerations section seems to require TLS client > authentication, which in turn requires client certificates. Is this > intended? If so, great! But in that case, what is the fate, if any, of the > EPP login/password command? Is it still needed? Is it still legal? What > does it mean? Must the identities agree? (The requirement for server > authentication is excellent, but some more text mentioning the need to > validate the certificate chain is probably a good idea.) > > RESOLUTION: The Security Considerations section has been modified to > explicitly note the need to validate the certificate chain. The > certificates used for TLS authentication authenticate the client and server > machines involved in the provisioning exchange. The EPP login functionality > is still needed, though, as it provides a facility to authenticate client > user identities so that the server can make access control and authorization > decisions based on the identity of the client, in addition to the identity > of the machine the client is using to communicate with the server. > > 6. sec 2.1 > I think it would be good to be a bit more strict about the use of congestion > control protocols specifically require the use of an IETF standards track > congestion control protocol such as TCP or SCTP > > i.e. change the following line: > - The transport mapping MUST manage congestion. > > to: > - The transport mapping MUST only be to an IETF standards > track congestion control protocol such as TCP or SCTP. > > RESOLUTION: Section 2.1 has been modified to read as follows: > > "- The transport mapping MUST be onto a transport such as TCP [RFC793] or > SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914 > [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP > [RFC3080], then the performance issues need to take into account issues of > overload, server availability and so forth." > > 7. > page 12, example greeting has: > > S: Example EPP server epp.example.tld > > in an example greeting. Did we not decide at some point that examples should > be of the form: epp.example.org ?? > > RESOLUTION: All examples in all documents have been changed to use the > example domain names (example.com, example.net, and example.org) described > in RFC 2606. Sample IPv4 addresses have been changed to use the Test-Net > address block listed in RFC 3330. > > 8. why do domain/contact/.. not have granular information about privacy? > > RESOLUTION: This comment has been addressed through a very lengthy > discussion process that resulted in making the existing element > mandatory. This change is reflected in a new version of the core protocol > document that can be seen at the temporary URL provided at the top of this > message. The formal announcement will be made after the San Francisco IETF > meeting. > > http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00049.html > > 1. The transport mapping MUST manage congestion. > > RESOLUTION: See the resolution for item 6 above. > > http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html > > > 1. The transport mapping MUST manage congestion. > > RESOLUTION: See the resolution for item 6 above. > > 2. Within the optional dcp (data collection policy) element: there is a > non-technical spin in at least the following label definition, what kind of > marketing is meant? > > : Contact for marketing purposes. > > Please add more to this definition so that is more neutral in in its > terminology. > > RESOLUTION: The description of this element has been changed as follows: > > ": Contact for marketing purposes. Information can be used to > contact individuals, through a communications channel other than the > protocol, for the promotion of a product or service.". > > 3. How does IESG and the community check the extensive XML in a > specification like this (analogous to the ABNF and MIB checking described > that is done regularly...)? How did you check what's here? Why might it > not matter? > > RESOLUTION: Syntax checking matters. There are a variety of freely > available XML syntax checking utilities, such as the Xerces XML parser > written in Java, that can be used to validate all of the schemas and > examples provided in the documents. The normative schemas can be copied > from the documents, edited to remove page headers and footers, and pasted > together to create the formal syntax specifications for the protocol. > Examples can be copied from the documents, edited to remove the "C:" and > "S:" line prefixes, and pasted together to create a set of sample instances > of the protocol. Scott Hollenbeck has also published external files > containing all of the examples and schemas in two public places: > > ftp://ftp.verisign.com/pub/epp/ > > http://www.verisign-grs.com/files/ > > Other WG members are mirroring these file collections to provide additional > redundancy. The examples and schemas can be run through an up-to-date > validating XML parser to confirm validity. As part of the normal document > editing process, Scott has been running all of the examples and schemas > through the Xerces-J parser to confirm that everything remains valid > according to the current W3C XML Schema specifications. > > > 1. "An EPP client streams EPP commands to an EPP server on an established > TCP connection. A client MAY establish multiple TCP connections to create > multiple command exchange channels. A server MAY limit a client to a > maximum number of TCP connections based on server capabilities and > operational load." > > It is not a good thing for the net for services to choose this approach. A > MAY like this is problematic for congestion control reasons. I would like > to change this language from "MAY establish" to "MAY but SHOULD NOT" and > from "A server MAY limit" to "A server SHOULD limit" > > RESOLUTION: Text changed as requested. > > 2. For references to TCP, besides RFC 793, you need: RFC 2581, 2914 > > RESOLUTION: References added. > > That's it! I'll try to have the updated EPP schema and example package > (none of the examples changed) uploaded to the public locations as quickly > as possible. > > -Scott- > From owner-ietf-provreg@cafax.se Sat Mar 15 14:44:14 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 OAA23180 for ; Sat, 15 Mar 2003 14:44:13 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2FJXrx9024756 for ; Sat, 15 Mar 2003 20:33:54 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2FJXrxn024755 for ietf-provreg-outgoing; Sat, 15 Mar 2003 20:33:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2FJXqx9024748 for ; Sat, 15 Mar 2003 20:33:52 +0100 (MET) Received: (qmail 93866 invoked by uid 0); 15 Mar 2003 19:33:51 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 15 Mar 2003 19:33:51 -0000 Date: Sat, 15 Mar 2003 14:33:59 -0500 Subject: [ietf-provreg] ISC OpenReg 1.0.1 Release Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joe Abley To: jabley@isc.org Content-Transfer-Encoding: 7bit Message-Id: <120FB739-571D-11D7-8411-00039312C852@isc.org> X-Mailer: Apple Mail (2.551) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit [this message is being copied to multiple mailing lists; apologies in advance for duplicates] The Internet Software Consortium is pleased to announce the first public release of OpenReg, an implementation of a DNS Shared Registry System which supports the Extensible Provisioning Protocol (EPP). For more information, and to download OpenReg, please see: http://www.isc.org/products/OpenReg/ OpenReg is free software, released under a BSD-style licence. From owner-ietf-provreg@cafax.se Mon Mar 17 00:16:50 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 AAA20471 for ; Mon, 17 Mar 2003 00:16:49 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2H568x9007303 for ; Mon, 17 Mar 2003 06:06:08 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2H568Zu007302 for ietf-provreg-outgoing; Mon, 17 Mar 2003 06:06:08 +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.8/8.12.8) with ESMTP id h2H566x9007297 for ; Mon, 17 Mar 2003 06:06:06 +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 h2H563tW004969; Mon, 17 Mar 2003 00:06:03 -0500 (EST) Received: from [130.129.137.249] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA25399; Mon, 17 Mar 2003 00:05:59 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Sun, 16 Mar 2003 21:05:56 -0800 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] thursday's meeting Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk As one might imagine, the agenda is going to be a bit flexible. Besides the published agenda, I'd like folks to be prepared to also discuss these items: Our response to the IESG. The IESG wants "a standard (as in the base, core spec) means for a registrar to tell a registry what can be disclosed at fine granularity." A means to avoid host objects. I've heard from a few folks that these topics warrant further discussion. I invite those who have been talking to me directly to send words to the list to spur discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Mon Mar 17 08:52:26 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 IAA13342 for ; Mon, 17 Mar 2003 08:52:25 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HDh0x9011109 for ; Mon, 17 Mar 2003 14:43:00 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HDh0D2011108 for ietf-provreg-outgoing; Mon, 17 Mar 2003 14:43:00 +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.8/8.12.8) with ESMTP id h2HDgwx9011101 for ; Mon, 17 Mar 2003 14:42:59 +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 IAA13181; Mon, 17 Mar 2003 08:42:52 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 08:39:45 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337082D@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] thursday's meeting Date: Mon, 17 Mar 2003 08:39:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > As one might imagine, the agenda is going to be a bit flexible. > > Besides the published agenda, I'd like folks to be prepared to also > discuss these items: > > Our response to the IESG. The IESG wants "a standard (as > in the base, > core spec) means for a registrar to tell a registry what > can be disclosed > at fine granularity." > > A means to avoid host objects. We have really got to get a grip on the first item. I thought we were past this as of last week, and here we are again. There's clearly a communications issue somewhere... I would hope that whomever wishes to bring up the "avoid host objects" topic plans to introduce information that hasn't already been talked to death on the mailing list at multiple times in the past. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 17 11:27: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 LAA18979 for ; Mon, 17 Mar 2003 11:27:57 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HGH3x9012672 for ; Mon, 17 Mar 2003 17:17:03 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HGH3p3012671 for ietf-provreg-outgoing; Mon, 17 Mar 2003 17:17:03 +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.8/8.12.8) with ESMTP id h2HGH2x9012665 for ; Mon, 17 Mar 2003 17:17:02 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HGGVGL011870; Mon, 17 Mar 2003 11:16:31 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171616.h2HGGVGL011870@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 08:39:46 EST." <3CD14E451751BD42BA48AAA50B07BAD60337082D@vsvapostal3.prod.netsol.com> Date: Mon, 17 Mar 2003 11:16:31 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > Our response to the IESG. The IESG wants "a standard (as > > in the base, > > core spec) means for a registrar to tell a registry what > > can be disclosed > > at fine granularity." > > > > A means to avoid host objects. > > We have really got to get a grip on the first item. I thought we were past > this as of last week, and here we are again. There's clearly a > communications issue somewhere... I agree. Either a session-scope mechanism, which incidently is independent of syntax and schema (it could be morphed into EBNF if RRP has not yet reached its sell-by date), or a base schema mechanism, dependent upon syntax and schema, and independent of "session" (aka, "privacy" is a property of syntax representations, and transport independent, even if it is not transported), or a mechanism which subsets the base schema, and constructs some syntax and semantics from some subset, and is also independent of "session" (see above, and add complexity for subseting in general). That should read as a switch statement, with no fall-through. Pointing out a specific defect in the element's sub-schema would be really useful. Eric From owner-ietf-provreg@cafax.se Mon Mar 17 11:32: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 LAA19283 for ; Mon, 17 Mar 2003 11:32:42 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HGNRx9012774 for ; Mon, 17 Mar 2003 17:23:27 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HGNRUg012773 for ietf-provreg-outgoing; Mon, 17 Mar 2003 17:23:27 +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.8/8.12.8) with ESMTP id h2HGNQx9012768 for ; Mon, 17 Mar 2003 17:23:26 +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 h2HGNLWC007596; Mon, 17 Mar 2003 08:23:22 -0800 (PST) Date: Mon, 17 Mar 2003 08:23:22 -0800 (PST) From: Rick Wesson To: Eric Brunner-Williams in Portland Maine cc: "Hollenbeck, Scott" , "'Edward Lewis'" , , Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: <200303171616.h2HGGVGL011870@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 17 Mar 2003, Eric Brunner-Williams in Portland Maine wrote: > > > Our response to the IESG. The IESG wants "a standard (as > > > in the base, > > > core spec) means for a registrar to tell a registry what ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > can be disclosed > > > at fine granularity." [snip] > Pointing out a specific defect in the element's sub-schema would be > really useful. The DCP proposal didn't address how a registrar can tell the registry what can be disclosed. I believe it was the proposal that did allow this fine granularity of disclosure. -rick From owner-ietf-provreg@cafax.se Mon Mar 17 11:43: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 LAA19757 for ; Mon, 17 Mar 2003 11:43:33 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HGYox9012968 for ; Mon, 17 Mar 2003 17:34:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HGYo9U012967 for ietf-provreg-outgoing; Mon, 17 Mar 2003 17:34: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.8/8.12.8) with ESMTP id h2HGYmx9012962 for ; Mon, 17 Mar 2003 17:34:49 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HGYKGL011947; Mon, 17 Mar 2003 11:34:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171634.h2HGYKGL011947@nic-naa.net> To: Rick Wesson cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 08:23:22 PST." Date: Mon, 17 Mar 2003 11:34:20 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk >> Pointing out a specific defect in the element's sub-schema would be >> really useful. > > The DCP proposal didn't address how a registrar can tell the registry > what can be disclosed. I believe it was the proposal that did > allow this fine granularity of disclosure. We don't have a negociation mechanism, for anything. I don't mind adding one. Why is the scope of negociation limited to this however? Eric From owner-ietf-provreg@cafax.se Mon Mar 17 12:31:51 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 MAA21669 for ; Mon, 17 Mar 2003 12:31:50 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HHMEx9013753 for ; Mon, 17 Mar 2003 18:22:14 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HHMEGu013752 for ietf-provreg-outgoing; Mon, 17 Mar 2003 18:22:14 +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.8/8.12.8) with ESMTP id h2HHMCx9013745 for ; Mon, 17 Mar 2003 18:22:13 +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 h2HHLuWC013612; Mon, 17 Mar 2003 09:21:56 -0800 (PST) Date: Mon, 17 Mar 2003 09:21:56 -0800 (PST) From: Rick Wesson To: Eric Brunner-Williams in Portland Maine cc: "Hollenbeck, Scott" , "'Edward Lewis'" , , Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: <200303171634.h2HGYKGL011947@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 17 Mar 2003, Eric Brunner-Williams in Portland Maine wrote: > >> Pointing out a specific defect in the element's sub-schema would be > >> really useful. > > > > The DCP proposal didn't address how a registrar can tell the registry > > what can be disclosed. I believe it was the proposal that did > > allow this fine granularity of disclosure. > > We don't have a negociation mechanism, for anything. > > I don't mind adding one. > > Why is the scope of negociation limited to this however? I suspect because the granularity requetsted is for the registrant not the session, where by one session could do many registrations for many more contacts/registrants. -rick From owner-ietf-provreg@cafax.se Mon Mar 17 13:32: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 NAA24161 for ; Mon, 17 Mar 2003 13:32:19 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HINCx9014532 for ; Mon, 17 Mar 2003 19:23:12 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HINCgf014531 for ietf-provreg-outgoing; Mon, 17 Mar 2003 19:23: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.8/8.12.8) with ESMTP id h2HINAx9014526 for ; Mon, 17 Mar 2003 19:23:11 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HIMeGL012339; Mon, 17 Mar 2003 13:22:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171822.h2HIMeGL012339@nic-naa.net> To: Rick Wesson cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 09:21:56 PST." Date: Mon, 17 Mar 2003 13:22:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I suspect because the granularity requetsted is for the registrant not the > session, where by one session could do many registrations for many more > contacts/registrants. So, in this model, there is p1, p2, p3; three distinct mumbles that have a to be defined, but not session-scoped, definition. A session between e1 and e2, two EPP endpoints, which transports d1, d2, d3, three distinct EPP datums, is: e1: session-open; send d1:p1; send d2:p2; send d3:p3; session-close e2: ack, ack, ack, ack (sort of like the Martians in "Mars Attacks") If so, then while data exhibits a property close to global uniqness within each glob of data, the value for the set {p1, p2, p3, ...} may have a much smaller cardinality. Somewhere less than 42 seems likely. If so, then connections should resemble something like this: send d1:p1, send d2:p1, send d3:p1 .... send dN:p1 \ send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1 for non-trivial sequences of sequentially identical values of p. Rewritten, to show policy-scoped sequences of data: p1{d1, d2, ... dN}, p2{dN+1}, p1{dN+2, dN+3, ... dN+M} And that looks reasonably amenable to this s1{p1{d1, d2, ... dN}}, s2{p2{dN+1}}, s3{p1{dN+2, dN+3, ... dN+M}} or three sessions, each with an associated single policy on all data. Operationally, we haven't precluded server operators from assigning well known values of p to ports, so that in practice, the above would be three distinct connections. We also haven't precluded server operators from cycling through a set of well known values of p whenever the server observes a session-end sent by a client, followed by a session-begin. We could of course add some mechanism for client and server to "dual" with values, until "trained", but until someone starts putting values for p down, we don't actually know if the size of the p value-space is as big as 42, or as small as two, or three, or four meaningfully distinct values. Eric P.S. I'm having way too much fun with the symbolic general nonsense. The proponant(s) of mumble need to attempt to be concret, soon. From owner-ietf-provreg@cafax.se Mon Mar 17 14:05:14 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 OAA25202 for ; Mon, 17 Mar 2003 14:05:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HIt1x9014944 for ; Mon, 17 Mar 2003 19:55:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HIt1rq014943 for ietf-provreg-outgoing; Mon, 17 Mar 2003 19:55:01 +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.8/8.12.8) with ESMTP id h2HIsxx9014938 for ; Mon, 17 Mar 2003 19:55:00 +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 18uzkg-0004nC-00; Mon, 17 Mar 2003 13:54:26 -0500 Message-ID: <3E761CFD.9E18F2F@libertyrms.info> Date: Mon, 17 Mar 2003 14:07:41 -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: Eric Brunner-Williams in Portland Maine CC: Rick Wesson , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl Subject: Re: [ietf-provreg] thursday's meeting References: <200303171822.h2HIMeGL012339@nic-naa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Eric Brunner-Williams in Portland Maine wrote: > > I suspect because the granularity requetsted is for the registrant not the > > session, where by one session could do many registrations for many more > > contacts/registrants. > > So, in this model, there is p1, p2, p3; three distinct mumbles that have a > to be defined, but not session-scoped, definition. > > A session between e1 and e2, two EPP endpoints, which transports d1, d2, d3, > three distinct EPP datums, is: > > e1: session-open; send d1:p1; send d2:p2; send d3:p3; session-close > e2: ack, ack, ack, ack (sort of like the Martians in "Mars Attacks") > > If so, then while data exhibits a property close to global uniqness within > each glob of data, the value for the set {p1, p2, p3, ...} may have a much > smaller cardinality. Somewhere less than 42 seems likely. > > If so, then connections should resemble something like this: > > send d1:p1, send d2:p1, send d3:p1 .... send dN:p1 \ > send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1 > Shouldn't "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of p1? > > for non-trivial sequences of sequentially identical values of p. > > Rewritten, to show policy-scoped sequences of data: > > p1{d1, d2, ... dN}, p2{dN+1}, p1{dN+2, dN+3, ... dN+M} > > > And that looks reasonably amenable to this > > s1{p1{d1, d2, ... dN}}, s2{p2{dN+1}}, s3{p1{dN+2, dN+3, ... dN+M}} > > or three sessions, each with an associated single policy on all data. > > Operationally, we haven't precluded server operators from assigning well > known values of p to ports, so that in practice, the above would be three > distinct connections. > > We also haven't precluded server operators from cycling through a set of > well known values of p whenever the server observes a session-end sent > by a client, followed by a session-begin. > > We could of course add some mechanism for client and server to "dual" with > values, until "trained", but until someone starts putting values for > p down, we don't actually know if the size of the p value-space is as big > as 42, or as small as two, or three, or four meaningfully distinct values. > > Eric > > P.S. I'm having way too much fun with the symbolic general nonsense. The > proponant(s) of mumble need to attempt to be concret, soon. Janusz Sienkiewicz From owner-ietf-provreg@cafax.se Mon Mar 17 14:26:51 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 OAA26196 for ; Mon, 17 Mar 2003 14:26:49 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HJGfx9015253 for ; Mon, 17 Mar 2003 20:16:41 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HJGfMq015252 for ietf-provreg-outgoing; Mon, 17 Mar 2003 20:16:41 +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.8/8.12.8) with ESMTP id h2HJGdx9015247 for ; Mon, 17 Mar 2003 20:16:40 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HJGDGL012537; Mon, 17 Mar 2003 14:16:13 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171916.h2HJGDGL012537@nic-naa.net> To: janusz sienkiewicz cc: Eric Brunner-Williams in Portland Maine , Rick Wesson , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 14:07:41 EST." <3E761CFD.9E18F2F@libertyrms.info> Date: Mon, 17 Mar 2003 14:16:13 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Shouldn't "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of > p1? I should have been explicit. I'm drawing on some non-provreg data -- real life with cookies. Few distinct "privacy" "policies" or "preferences" exist. The distribution of policied cookies and browser values that result in these three general categories: accept-unconditionally warn-accept-or-reject-conditionally reject-unconditionally is small, and the modality is less than the total range of values. The most likely transition will be from one domainant mode to another. So, p1 to p2 and back to p1, generally, and p1 to p3 and back to p1. Less frequently will be pN to pM, where N and M are not in the very small set of dominant modalities of meaningfully distinct policies. I wasn't trying to show p1, then p2, then p3 usage, but ...p1p1p1p1p1p2p2p1p1p1p1p1p1pp1p3p1p1... Where there really is random variation from one data glob to the next, and the variations are meaningfully distinct (a kettle of fish that is not yet opened), then clearly the "statefull encoding" of policied sequences of data globs is not going to work as well as some "statefull encoding" of policied, and uncorrolated data globs. In a sense, we're just revisiting statefull vs stateless encoding design issues. How much character-set variation do you think there is in some character stream? Design accordingly. If few transitions relative to the byte count, go for what amounts to state shifts (and variable byte counts per character). If many relative to the byte count, consider using fixed rather than variable byte counts, and accept the "padding" overhead. How many interesting ways are there to write: don't publish some or all of my mumble? Eric From owner-ietf-provreg@cafax.se Mon Mar 17 14:29: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 OAA26276 for ; Mon, 17 Mar 2003 14:29:47 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HJK9x9015345 for ; Mon, 17 Mar 2003 20:20:09 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HJK9K4015344 for ietf-provreg-outgoing; Mon, 17 Mar 2003 20:20:09 +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.8/8.12.8) with ESMTP id h2HJK8x9015339 for ; Mon, 17 Mar 2003 20:20:08 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HJJfGL012550; Mon, 17 Mar 2003 14:19:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171919.h2HJJfGL012550@nic-naa.net> To: Eric Brunner-Williams in Portland Maine cc: janusz sienkiewicz , Rick Wesson , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 14:16:13 EST." <200303171916.h2HJGDGL012537@nic-naa.net> Date: Mon, 17 Mar 2003 14:19:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Where there really is random variation from one data glob to the next, and > the variations are meaningfully distinct (a kettle of fish that is not yet > opened), then clearly the "statefull encoding" of policied sequences of > data globs is not going to work as well as some "statefull encoding" of > policied, and uncorrolated data globs. Oops. That should read > opened), then clearly the "statefull encoding" of policied sequences of > data globs is not going to work as well as some "stateless encoding" of ^^^^ Eric From owner-ietf-provreg@cafax.se Tue Mar 18 00:26:05 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 AAA18874 for ; Tue, 18 Mar 2003 00:26:03 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2I5Dpx9015207 for ; Tue, 18 Mar 2003 06:13:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2I5DoMZ015206 for ietf-provreg-outgoing; Tue, 18 Mar 2003 06:13:50 +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.8/8.12.8) with ESMTP id h2I5Dix9015201 for ; Tue, 18 Mar 2003 06:13:45 +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 h2I5DitW035962; Tue, 18 Mar 2003 00:13:44 -0500 (EST) Received: from [130.129.137.249] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA08245; Tue, 18 Mar 2003 00:13:40 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: X-Priority: 1 (Highest) Date: Mon, 17 Mar 2003 21:13:34 -0800 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] again with the privacy Cc: edlewis@arin.net, jaap@sidn.nl, Ted Hardie , paf@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Jaap and I talked with Ted Hardie (incoming Apps Area AD) and Patrik Faltstrom (outgoing Apps Area AD) about the state of the WG. (Sorry, no mics were present to get the verbatim record of this.) I say this because in the past Jaap and I have tried hard to stay away from injecting technical material as chairs. However, it seems clear that one more go of this is needed, so we are floating this again. Below is the proposal that was generated in December in response to the IESG comments. I'm resurrecting it again based on this: The IESG wants a means for a registrar to tell a registry whether or not a piece of data can be passed on. (DCP goes from registry to registrar, we need a reverse version of this communication.) dnd="true" means: this info cannot leave the registry, not in DNS, not in whois, not in another means. What if a domain name's DNS server is dnd="true"? Does it make DNS - no. Is this sensible? Probably not. This isn't expressive enough for all involved, but it is a basic step. There were some objections to this in Dec/Jan. >1. "do not disclose" seems non-extensible, when extensibility seems important. It's a place holder. More elaborate information can appear later. >2. A complete proposal should specify whether a "dnd"d field should be >distinguished from a non-existent field when presenting data to clients (e.g. >via commands). If it should, then the proscribed manner in which that >should be done should be included for . Good question. Info could return "value hidden". What about 'hiding' the provisioned name? I think acknowledging it's unavailability is excuseable. >3. What should return if the object being checked is marked as >dnd="true" and the client doing the is one to which disclosure is >prohibited? See above. >For the server side the attribute based approach is more cumbersome. I cannot answer that one. The AD's conjectured that for PS, if we were to put this proposal into play and it went unused, it could be removed for DS... Comments about this? This will be discussed Thursday morning. >X-Authentication-Warning: nic.cafax.se: majordom set sender to >owner-ietf-provreg@cafax.se using -f >From: "Hollenbeck, Scott" >To: "'ietf-provreg@cafax.se'" >Subject: Updated (and hopefully the last) EPP Privacy Proposal >Date: Mon, 30 Dec 2002 09:08:46 -0500 >Importance: high >X-Priority: 1 >Sender: owner-ietf-provreg@cafax.se >Status: > >In ongoing background discussions with the IESG regarding our EPP documents, >we (Jaap, Ed, several IESG members, and I) have continued to talk about the >IESG's privacy-related comments and the responses to those comments that >have been sent to the WG mailing list. We've concluded that we need to add >a "must implement" feature to the protocol to allow data elements to be >tagged with a binary indicator of data owner preference for disclosure of >information to third parties that aren't involved in the provisioning >transaction. Back in October [1] I described a proposal to use an XML >attribute for this purpose. Over the last few weeks ([2], [3]) I suggested >a few other options. Considering all of our options, I would again like to >suggest an XML attribute-based approach to address this last remaining IESG >review issue. > >This does not mean that the binary indicator is the only way that privacy >preferences or policies can be expressed. Expression of more specific >privacy policies can be accomplished using the protocol's extension >mechanism. > >The proposal is to add a new attribute to every object element in the >domain, contact, and host mappings. This boolean attribute, "dnd" (for Do >Not Disclose), will be used to note that the value of an element should not >be disclosed to third parties. It will have a default value of "false" >(meaning it is ok to disclose info) in the domain and host mappings, and a >default value of "true" (meaning it is NOT ok to disclose info) in the >contact mapping. The defaults can be over-ridden and explicitly specified >by clients. Additional constraints can be defined using the protocol >extension mechanism. > >Here are some examples: > >jdoe@example.com >jdoe@example.com >Both of the above mean "do not disclose this email address to third >parties". > >jdoe@example.com >This means that the data owner gives permission for the email address to be >disclosed to third parties. > > > > > >(This extension example isn't syntactically valid, but I wanted it to be >short, clear, and to the point without the clutter needed to make it valid. >In this case it means that the email address should not be published via >whois.) > >I'll also have to add some notes to explain that server policy might not >recognize the value of an attribute if it's turned on (like in the email >address example above) when turning on the attribute is counter to some >policy. > >A measure of WG support or dissatisfaction with this proposal would be >helpful. Would you please send a note to the mailing list to let the chairs >know if you either support the proposal as a way to move forward or if you >do not support the proposal? If you do not support the proposal it would be >helpful if you explained why and could suggest modifications (if possible) >to make it acceptable. > >If you do not support the proposal, please recognize that we have been stuck >on this issue for quite a while and we need to do something. On the one >hand, we are aware of the differences in privacy policy, laws, et al. facing >each registry. On the other hand, we are being asked to define one standard >protocol that is rigorous enough to not let privacy slide by. So the >question is - does this proposal (including extension support) allow for all >known policies to be expressed within EPP? > >-Scott- > >[1] >http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html > >[2] >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html > >[3] >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Tue Mar 18 00:52:10 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 AAA19775 for ; Tue, 18 Mar 2003 00:52:08 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2I5ffx9015427 for ; Tue, 18 Mar 2003 06:41:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2I5ffO5015426 for ietf-provreg-outgoing; Tue, 18 Mar 2003 06:41:41 +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.8/8.12.8) with ESMTP id h2I5fdx9015421 for ; Tue, 18 Mar 2003 06:41:40 +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 h2I5fXWC029047; Mon, 17 Mar 2003 21:41:33 -0800 (PST) Date: Mon, 17 Mar 2003 21:41:40 -0800 (PST) From: Rick Wesson To: Edward Lewis cc: , , Ted Hardie , Subject: Re: [ietf-provreg] again with the privacy 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, all of the "issues" enumerated below are really non-issues, we only need the privacy bits for social data not technical data. The IESG didn't ask us to create a privacy framework for hiding DNS hosts (which is silly) see [1] the element proposal, not to be confused with the attribute proposal, does address registrar -> registry boolean notes of what social data is to remain private. [1] http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html I propose that we don't have the problems you enumerate below if we restrict the elements that can be enclosed by a element are only social data elements. -rick On Mon, 17 Mar 2003, Edward Lewis wrote: > Jaap and I talked with Ted Hardie (incoming Apps Area AD) and Patrik > Faltstrom (outgoing Apps Area AD) about the state of the WG. (Sorry, > no mics were present to get the verbatim record of this.) I say this > because in the past Jaap and I have tried hard to stay away from > injecting technical material as chairs. However, it seems clear that > one more go of this is needed, so we are floating this again. > > Below is the proposal that was generated in December in response to > the IESG comments. I'm resurrecting it again based on this: > > The IESG wants a means for a registrar to tell a registry whether or > not a piece of data can be passed on. (DCP goes from registry to registrar, > we need a reverse version of this communication.) > > dnd="true" means: this info cannot leave the registry, not in DNS, not in > whois, not in another means. > > What if a domain name's DNS server is dnd="true"? Does it make DNS - no. > Is this sensible? Probably not. > > This isn't expressive enough for all involved, but it is a basic step. > > There were some objections to this in Dec/Jan. > > >1. "do not disclose" seems non-extensible, when extensibility seems important. > > It's a place holder. More elaborate information can appear later. > > >2. A complete proposal should specify whether a "dnd"d field should be > >distinguished from a non-existent field when presenting data to clients (e.g. > >via commands). If it should, then the proscribed manner in which that > >should be done should be included for . > > Good question. Info could return "value hidden". What about > 'hiding' the provisioned name? I think acknowledging it's > unavailability is excuseable. > > >3. What should return if the object being checked is marked as > >dnd="true" and the client doing the is one to which disclosure is > >prohibited? > > See above. > > >For the server side the attribute based approach is more cumbersome. > > I cannot answer that one. > > The AD's conjectured that for PS, if we were to put this proposal > into play and it went unused, it could be removed for DS... > > Comments about this? > > This will be discussed Thursday morning. > > >X-Authentication-Warning: nic.cafax.se: majordom set sender to > >owner-ietf-provreg@cafax.se using -f > >From: "Hollenbeck, Scott" > >To: "'ietf-provreg@cafax.se'" > >Subject: Updated (and hopefully the last) EPP Privacy Proposal > >Date: Mon, 30 Dec 2002 09:08:46 -0500 > >Importance: high > >X-Priority: 1 > >Sender: owner-ietf-provreg@cafax.se > >Status: > > > >In ongoing background discussions with the IESG regarding our EPP documents, > >we (Jaap, Ed, several IESG members, and I) have continued to talk about the > >IESG's privacy-related comments and the responses to those comments that > >have been sent to the WG mailing list. We've concluded that we need to add > >a "must implement" feature to the protocol to allow data elements to be > >tagged with a binary indicator of data owner preference for disclosure of > >information to third parties that aren't involved in the provisioning > >transaction. Back in October [1] I described a proposal to use an XML > >attribute for this purpose. Over the last few weeks ([2], [3]) I suggested > >a few other options. Considering all of our options, I would again like to > >suggest an XML attribute-based approach to address this last remaining IESG > >review issue. > > > >This does not mean that the binary indicator is the only way that privacy > >preferences or policies can be expressed. Expression of more specific > >privacy policies can be accomplished using the protocol's extension > >mechanism. > > > >The proposal is to add a new attribute to every object element in the > >domain, contact, and host mappings. This boolean attribute, "dnd" (for Do > >Not Disclose), will be used to note that the value of an element should not > >be disclosed to third parties. It will have a default value of "false" > >(meaning it is ok to disclose info) in the domain and host mappings, and a > >default value of "true" (meaning it is NOT ok to disclose info) in the > >contact mapping. The defaults can be over-ridden and explicitly specified > >by clients. Additional constraints can be defined using the protocol > >extension mechanism. > > > >Here are some examples: > > > >jdoe@example.com > >jdoe@example.com > >Both of the above mean "do not disclose this email address to third > >parties". > > > >jdoe@example.com > >This means that the data owner gives permission for the email address to be > >disclosed to third parties. > > > > > > > > > > > >(This extension example isn't syntactically valid, but I wanted it to be > >short, clear, and to the point without the clutter needed to make it valid. > >In this case it means that the email address should not be published via > >whois.) > > > >I'll also have to add some notes to explain that server policy might not > >recognize the value of an attribute if it's turned on (like in the email > >address example above) when turning on the attribute is counter to some > >policy. > > > >A measure of WG support or dissatisfaction with this proposal would be > >helpful. Would you please send a note to the mailing list to let the chairs > >know if you either support the proposal as a way to move forward or if you > >do not support the proposal? If you do not support the proposal it would be > >helpful if you explained why and could suggest modifications (if possible) > >to make it acceptable. > > > >If you do not support the proposal, please recognize that we have been stuck > >on this issue for quite a while and we need to do something. On the one > >hand, we are aware of the differences in privacy policy, laws, et al. facing > >each registry. On the other hand, we are being asked to define one standard > >protocol that is rigorous enough to not let privacy slide by. So the > >question is - does this proposal (including extension support) allow for all > >known policies to be expressed within EPP? > > > >-Scott- > > > >[1] > >http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html > > > >[2] > >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html > > > >[3] > >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > From owner-ietf-provreg@cafax.se Tue Mar 18 08:03: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 IAA09993 for ; Tue, 18 Mar 2003 08:03:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ICr1x9018757 for ; Tue, 18 Mar 2003 13:53:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ICr17p018756 for ietf-provreg-outgoing; Tue, 18 Mar 2003 13:53:01 +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.8/8.12.8) with ESMTP id h2ICqvx9018751 for ; Tue, 18 Mar 2003 13:53:00 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2ICqCGL016921; Tue, 18 Mar 2003 07:52:12 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303181252.h2ICqCGL016921@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, jaap@sidn.nl, Ted Hardie , paf@cisco.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] again with the privacy In-Reply-To: Your message of "Mon, 17 Mar 2003 21:13:34 PST." Date: Tue, 18 Mar 2003 07:52:12 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, A mechanism to disclose the operational practices and policies of operators of EPP servers with respect to "data collection", aka "privacy", is NOT a requirement, and section 8.4 of rfc 3375, in particular the final sentance of para 1, is incorrect. I can live with being responsible for that train wreck. Protocols developed under the imprimature of "the IETF", MUST NOT provide mechanism(s) to disclose the data collection policies, in particular, the polices to which data which identifies individual persons is subject, of operators of the protocols. Sounds grand and very Directorial. Instead "we're supposed to" come up with some dork that will allow the naive data we currently have, in the schema we currently have, with the syntax we currently have, to "twinkle", and to provision, not just any data collector, but only the registry operator, with this "twinkle" property, for each provisioned glob of data, and this whole waste of time is because 954 can't be moved to historic. I'll be sure and tell my registrar that I want only the octets-pairs that are prime when interpreted as Mayan digits (base 20) to be "published". I'm obviously in the wrong IETF. I'm in the one where clue is not held uniquely by management. The "IETF of Idiots". I do not see the point in bothering to pretend to write a specification that is in fact written by someone else. I'll just treat the eventual RFC as having no more "consensus engineering standards" value than an equal page count text that comes directly from Verisign. Implement it, and don't think too hard about it. I give up. I could use this time better playing with my kids, and making open, interoperable (but not IETF referencing) product. Eric From owner-ietf-provreg@cafax.se Wed Mar 19 08:55: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 IAA20884 for ; Wed, 19 Mar 2003 08:55:06 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JDa7x9003807 for ; Wed, 19 Mar 2003 14:36:07 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JDa7Ls003806 for ietf-provreg-outgoing; Wed, 19 Mar 2003 14:36: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.8/8.12.8) with ESMTP id h2JDa3x9003801 for ; Wed, 19 Mar 2003 14:36:06 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JDZCGL022220; Wed, 19 Mar 2003 08:35:13 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303191335.h2JDZCGL022220@nic-naa.net> To: ietf-provreg@cafax.se, iesg@ietf.org Subject: [ietf-provreg] EPP, data, actors, and access Date: Wed, 19 Mar 2003 08:35:12 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Oki all, We have two distinct proposals for a specification of access, data, and actors for EPP. External to EPP, but possibly relevant, is the existence of WHOIS (954). One approach scopes some meta-data to sessions, within a connectionist, client-server model, with the server originating the meta-data. As a matter of syntax, this approach is extensible as to semantics associated with a session. One approach scopes some meta-data to data only, with the client originating the meta-data. The syntax for this approach is various, but two designs of note are an element (in the degenerate case, an attribute only) for some or all elements of data, and an element for each aggregation of data, e.g., the contact object, with some mapping to some or all elements of data within the aggregation. It is possible that if both a session-scoped mechanism, and a data-scoped mechanism are presented to a pair of EPP peers, neither being semantically null, that the peers will not correctly and interoperably evaluate the semantics of both mechanisms. This is made more likely if the evaluation-spaces of the two mechanisms are not identical, nor avail trivial forward and reverse mapping between nominally equivalent mechanism-specific representations. A design choice pioneered, at least within the PROVREG context, by one contributor, is to add a binary toggle, or a set of enumerated values, that allow some new semantic. As that contributor demonstrated, and as a subsequent implementations have shown, it is possible to add payload with a distinct syntactic form. See [1] for details. I mention this to acknowledge that a WHOIS-specific optimization is a possibility, that such a "hack" need not conform to the syntax of the current protocol, and that as an implementation matter, it is tractible. I add that such an optimization presents challenges for users who may seek to modify the optimization, or to obtain transparently equivalent transaction semantics, independent of EPP endpoint operator. One statement associated with client-origination is that it is actually registrant-origination. This presents two problems, the first theoretic, as EPP is between registrars and registries. The working group chose to create an interoperable protocol for data exchange between registrars and registries. Some other working group may be formed, if an interoperable protocol for data exchange between registrants and registrars is useful. The second problem is user-interface specification. Is the value-space of the new data binary? Is it an enumerated set? Is it an enumerated set of enumerated sets? Is it a tree with some branch ordering and evaluation property? Isn't this a discussion of what boxes, knobs, and sliders exist on a registrars registrant-facing data collection API? There are instances of UI specification within the IETF, but that is not in the PROVREG charter. I've written quite a bit over the past several months, critically, but as intelligently as I can manage, on what is referred to as "the IESG privacy proposal". I have no objective indication that any member of the IESG has read anything I've contributed to the PROVREG list. That's OK, this isn't some quest for emotional gratification. What puzzles me is the utter lack of substantive contribution, whether responsive to my writings, or those of anyone else, that moves beyond a gesture towards a requirements statement. Real requirements are intelligently discussed, unless they arise from kings, presidents, and voting. Real proposals are in the form of public drafts, eventually. Eric [1] draft-liu-epp-ustld-01.txt, expired. Author at liu@cis.umassd.edu. A copy may exist in the PROVREG list mail archive. From owner-ietf-provreg@cafax.se Wed Mar 19 13:12:52 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 NAA28608 for ; Wed, 19 Mar 2003 13:12:50 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JI2Bx9006449 for ; Wed, 19 Mar 2003 19:02:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JI2Bhr006448 for ietf-provreg-outgoing; Wed, 19 Mar 2003 19:02:11 +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.8/8.12.8) with ESMTP id h2JI1px9006443 for ; Wed, 19 Mar 2003 19:01:51 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2JI1mT1041637 for ; Wed, 19 Mar 2003 19:01:48 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2JI1llU041636 for ietf-provreg@cafax.se; Wed, 19 Mar 2003 19:01:47 +0100 (CET) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JHG7x9005989 for ; Wed, 19 Mar 2003 18:16:08 +0100 (MET) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2JHFxlb022659; Wed, 19 Mar 2003 09:16:00 -0800 (PST) Received: from qualcomm.com ([10.50.0.30]) by sabrina.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2JHFtOL020740; Wed, 19 Mar 2003 09:15:58 -0800 (PST) Date: Wed, 19 Mar 2003 09:15:57 -0800 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: [ietf-provreg] EPP, data, actors, and access From: Ted Hardie To: ietf-provreg@cafax.se, iesg@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <72DDE1EC-5A2E-11D7-9130-000393CB0816@qualcomm.com> X-Mailer: Apple Mail (2.551) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Eric, Sorry that you weren't able to make the San Francisco meeting as one of the real advantages our face-to-face meetings afford is the opportunity to get high bandwidth immediate response. I think we have identified ways forward on this issue in this week. Given the press of events during the week, they are not expressed in drafts; I'm sure they will be expressed in drafts as soon as we all have a chance. After the ProvReg meeting gets a sense of the room on the discussion, all of these conversations will be confirmed on the list, so you will have a chance to discuss them. As the incoming AD here, I am trying to catch up on all this as fast as I can; I appreciate the patience of the group as I work out what I can do to help us all make progress. regards, Ted Hardie From owner-ietf-provreg@cafax.se Wed Mar 19 14:20: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 OAA01809 for ; Wed, 19 Mar 2003 14:20:03 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JJ7Kx9007589 for ; Wed, 19 Mar 2003 20:07:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JJ7KAS007588 for ietf-provreg-outgoing; Wed, 19 Mar 2003 20:07:20 +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.8/8.12.8) with ESMTP id h2JJ7Jx9007583 for ; Wed, 19 Mar 2003 20:07:19 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JJ6PGL023423; Wed, 19 Mar 2003 14:06:25 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303191906.h2JJ6PGL023423@nic-naa.net> To: Ted Hardie cc: ietf-provreg@cafax.se, iesg@ietf.org, brunner@nic-naa.net Subject: Re: [ietf-provreg] EPP, data, actors, and access In-Reply-To: Your message of "Wed, 19 Mar 2003 09:15:57 PST." <72DDE1EC-5A2E-11D7-9130-000393CB0816@qualcomm.com> Date: Wed, 19 Mar 2003 14:06:25 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ted, > I think we have identified ways forward on this issue in this week ... I've no idea what this means. We (possibly a different value of "we") thought we were getting consensus around a proposal ( manditory), some time prior to this week, e.g., last week. As to timing of meetings, I don't attend meetings held in belligerant states during periods of belligerency. It is dangerous, it requires acts of active cooperation with the security regimes of the belligerant state(s), and is an endorsement of belligerency. I'd rather not. Eric From owner-ietf-provreg@cafax.se Wed Mar 19 16:13: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 QAA08466 for ; Wed, 19 Mar 2003 16:13:39 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JL1Ux9009015 for ; Wed, 19 Mar 2003 22:01:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JL1Utq009014 for ietf-provreg-outgoing; Wed, 19 Mar 2003 22:01:30 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2JL1Hx9009009 for ; Wed, 19 Mar 2003 22:01:18 +0100 (MET) Message-ID: <038301c2ee5a$865c79f0$7e8a8182@neteka.inc> From: "Edmon Chung" To: , "Ted Hardie" , "Ned Freed" , , "Edward Lewis" Cc: , References: Subject: Re: [ietf-provreg] provreg's privacy issue Date: Wed, 19 Mar 2003 15:59:57 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Hi, ----- Original Message ----- From: "Edward Lewis" > In response to the IESG comment: > > why do domain/contact/.. not have granular information about privacy? > I am not sure if the draft that I am working on would help: http://ner2r.com/draft-ietf-provreg-epp-privacy-00.txt The document proposes an EPP extension to handle Domain Contact Privacy Profiles and is kept extremely flexible so that it should be able to adopt to registry mandated or client enforced/suggested privacy profiles. It basically describes a private/public toggle for as well as a way to announce registry policy on each attribute of each contact in a domain name. This is in fact something similar to what we have implemented for a client. Mainly for what contact info could/must be published through the WHOIS. One thing that this current draft has not addressed is if there needs to be different types of disclosure to different types of querying entities. But could be added by allowing multiple policies and to add a policy type attribute. Have to admit however that the bulk of the wordings in the document itself was stolen from Scott's enum draft. Well... I think Scott did a good job in providing a great template for EPP extension docs. :-) Edmon From owner-ietf-provreg@cafax.se Wed Mar 19 18:35:57 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 SAA15999 for ; Wed, 19 Mar 2003 18:35:55 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNQBx9010797 for ; Thu, 20 Mar 2003 00:26:11 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNQB7B010796 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:26:11 +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.8/8.12.8) with ESMTP id h2JNQ9x9010791 for ; Thu, 20 Mar 2003 00:26:10 +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 h2JNQ8tW007506; Wed, 19 Mar 2003 18:26:08 -0500 (EST) Received: from [130.129.133.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA19377; Wed, 19 Mar 2003 18:26:06 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200303191906.h2JJ6PGL023423@nic-naa.net> References: <200303191906.h2JJ6PGL023423@nic-naa.net> Date: Wed, 19 Mar 2003 14:48:30 -0800 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] EPP, data, actors, and access Cc: Ted Hardie , ietf-provreg@cafax.se, iesg@ietf.org, brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:06 -0500 3/19/03, Eric Brunner-Williams in Portland Maine wrote: >Ted, > >> I think we have identified ways forward on this issue in this week ... > >I've no idea what this means. We (possibly a different value of "we") >thought we were getting consensus around a proposal ( manditory), >some time prior to this week, e.g., last week. We = some set of people. It's not important yet, what is important is whether or not the WG as a whole also agrees. Let's not worry about the source of the proposal, let's worry about the quality of the proposal. During the face to face meeting on Thursday, we will systemically not come to a conclusion. The best use of the time is as a "bull" session, to throw ideas back and forth for some amount of time (the amount given is a function of the relative usefulness of the conversation). At the end of the bull session, it will be the job of the chairs to prepare something to put in the list and to then begin the process of drafting an approach acceptable to the group as a whole. Consensus is not achieved by voting, but by arriving at a set of statements that are acceptable to (nearly) all with a stake - WG members, IESG, and the silent masses following this work. Let's put it this way, if we want to rent a car, if 80% of the WG wants to require a red one and the other 20% wants blue, we'll settle on wanting to just rent a car. >As to timing of meetings, I don't attend meetings held in belligerant states >during periods of belligerency. It is dangerous, it requires acts of active >cooperation with the security regimes of the belligerant state(s), and is >an endorsement of belligerency. I'd rather not. Absence is perfectly permissible, after all the IETF is a volunteer organization. The sentiment expressed is that it would have been keen to have you in attendance so that we could more quickly arrive at a common understanding of the problem. It is our fault if you feel the need to defend your choice not to travel. (I'm *not* going to define "our." ;)) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Wed Mar 19 18:39:42 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 SAA16118 for ; Wed, 19 Mar 2003 18:39:41 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNQDx9010805 for ; Thu, 20 Mar 2003 00:26:13 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNQDDj010804 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:26:13 +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.8/8.12.8) with ESMTP id h2JNQBx9010799 for ; Thu, 20 Mar 2003 00:26:12 +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 h2JNQBtW007509; Wed, 19 Mar 2003 18:26:11 -0500 (EST) Received: from [130.129.133.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA19385; Wed, 19 Mar 2003 18:26:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200303191335.h2JDZCGL022220@nic-naa.net> References: <200303191335.h2JDZCGL022220@nic-naa.net> Date: Wed, 19 Mar 2003 14:54:03 -0800 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] EPP, data, actors, and access Cc: ietf-provreg@cafax.se, iesg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 8:35 -0500 3/19/03, Eric Brunner-Williams in Portland Maine wrote: >Oki all, > >We have two distinct proposals for a specification of access, data, and >actors for EPP. External to EPP, but possibly relevant, is the existence >of WHOIS (954). You are expressing a very detailed understanding of the problem. One of the issues I have with being this detailed is that it makes the chance of consensus less likely to achieve. I can see the point that perhaps I want my telephone number to appear in WHOIS but not in DNS (to pick a perverse situation). Let's do this as a first order approximation - is it possible to specify whether a data item (call it what you will) is not allowed to be repeated by the registry to any one other than the registrar that submitted it? Is this something that is common enough to be understood by all? Is this potentially sufficient to satisfy all people's needs here? (Presuming the above meets with consensus, and then while sitting at proposed we discover that the mechanism is useless, dropping it or replacing it is always an option. At that time, we will be able to point to emperical evidence of the goodness/badness of it.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From owner-ietf-provreg@cafax.se Wed Mar 19 18:49: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 SAA16422 for ; Wed, 19 Mar 2003 18:49:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNeTx9011000 for ; Thu, 20 Mar 2003 00:40:29 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNeT6X010999 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:40:29 +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.8/8.12.8) with ESMTP id h2JNeIx9010994 for ; Thu, 20 Mar 2003 00:40:18 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JNd8GL024538; Wed, 19 Mar 2003 18:39:08 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303192339.h2JNd8GL024538@nic-naa.net> To: "Edmon Chung" cc: paf@cisco.com, "Ted Hardie" , "Ned Freed" , randy@psg.com, "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:59:57 EST." <038301c2ee5a$865c79f0$7e8a8182@neteka.inc> Date: Wed, 19 Mar 2003 18:39:08 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edmon, Henry, Some text, on this list, before going off into the delirium of boiler-plate, would have been a blessing, neh? I see ... o a glob going from registry to registrar (don't tell the iesg), o a glob on response, approximately 1k in size, o a glob on response, ditto, o a bi-di glob on !!! I see ... o a BEGIN END section of formal syntax with very, very little text seperating these delimeters (don't worry, we haven't gotten even a syntax clue from the IESG), I see ... o a totally irrelevent i18n section, but I understand, this is one of Neteka's sweet spots (besides, the IESG will surely appreciate the suggestion that XML will melt if "private parts" is written in Chinese, and the Chinese characters encoded in Big5), I see ... o two hooks parked at the IANA to hang some coats on, fine. So, the inference from the examples is that the syntax is a restatement of a big bit of the contact object, putting a binary, or enumerated set of value against each element -- sort of pervasive, but restricted to the contact object, attributes (but as an additional carried along "shadow" of the original, unencumbered contact object. Not only does this NOT do what our Masters in Moscow, the IESG, require, (the glob goes in the wrong direction), the scope of the extension, as it is from registry to registrar, cannot apply to any instance of WHOIS operated by the registry. Here's my you-pay-for-dinner question: registrar_N (Neteka) initiates a session with registry_V, registry_V ships back a that says 95/46/EC applies and all data is not repurposed, there are no recipients other than the registry, that it retains the data only for the period of registration, plus some operational window for the purpose of renewal, and ... everything is _private_ (except publication via 1034/35). What data collection / privacy problem remains (that your proposal cleverly solves)? Heck, lets go for two dinners, there are two of you anyway: registrar_N (Neteka) initiates a session with registry_V, registry_V ships back a that says says anything you want, even no at all, registrar_N does a create for mumble, registry_V acks appropriately registrar_N ships an update on mumble that attempts to set a bit, e.g., don't publish phone #, provisioned in the prior op, registry_V nacks inappropriately, and in bad taste. Now what happens? Why "discover" access policy _after_ a committing a write? There is an Americn idiom about closing a barn door _after_ the horses have left. I'm always lacking clue, Eric From owner-ietf-provreg@cafax.se Wed Mar 19 18:54: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 SAA16554 for ; Wed, 19 Mar 2003 18:54:33 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNkKx9011050 for ; Thu, 20 Mar 2003 00:46:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNkKsm011049 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:46:20 +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.8/8.12.8) with ESMTP id h2JNkJx9011044 for ; Thu, 20 Mar 2003 00:46:19 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JNjMGL024573; Wed, 19 Mar 2003 18:45:22 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303192345.h2JNjMGL024573@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, iesg@ietf.org, brunner@nic-naa.net Subject: Re: [ietf-provreg] EPP, data, actors, and access In-Reply-To: Your message of "Wed, 19 Mar 2003 14:54:03 PST." Date: Wed, 19 Mar 2003 18:45:22 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, A quick reply, between kidz on my end, and distractions on yours. > Let's do this as a first order approximation - is it possible to > specify whether a data item (call it what you will) is not allowed to > be repeated by the registry to any one other than the registrar that > submitted it? Is this something that is common enough to be > understood by all? Is this potentially sufficient to satisfy all > people's needs here? The registry can assert that this is its policy via the . Where the value is in having the registrar attempt to bind such a policy to a data item (I'm partial to mumbles and globs), rather than having a policy bound to the mumble or glob by the registry is possibly an article of religious faith. I've written why the converse is true, possibly in moments of religious euphoria. Eric From owner-ietf-provreg@cafax.se Wed Mar 19 19:04:15 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 TAA16829 for ; Wed, 19 Mar 2003 19:04:13 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNsKx9011190 for ; Thu, 20 Mar 2003 00:54:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNsKPN011189 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:54:20 +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.8/8.12.8) with ESMTP id h2JNs9x9011183 for ; Thu, 20 Mar 2003 00:54:09 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JNrBGL024595; Wed, 19 Mar 2003 18:53:11 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303192353.h2JNrBGL024595@nic-naa.net> To: Randy Bush cc: Eric Brunner-Williams in Portland Maine , "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:45:56 PST." Date: Wed, 19 Mar 2003 18:53:11 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > this is quite incorrect, you just didn't like it. Am I that shallow? Well, a pointer to the item with a substantive proposal would be nice. Eric From owner-ietf-provreg@cafax.se Wed Mar 19 19:33: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 TAA17806 for ; Wed, 19 Mar 2003 19:33:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2K0Hnx9011465 for ; Thu, 20 Mar 2003 01:17:49 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2K0Hn0P011464 for ietf-provreg-outgoing; Thu, 20 Mar 2003 01:17:49 +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.8/8.12.8) with ESMTP id h2K0Hcx9011459 for ; Thu, 20 Mar 2003 01:17:38 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2K0HUT1043580 for ; Thu, 20 Mar 2003 01:17:30 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2K0HTDY043579 for ietf-provreg@cafax.se; Thu, 20 Mar 2003 01:17:29 +0100 (CET) Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNk0x9011029 for ; Thu, 20 Mar 2003 00:46:01 +0100 (MET) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18vnFv-000Oaz-00; Wed, 19 Mar 2003 15:45:59 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18vnFu-0000ET-00; Wed, 19 Mar 2003 15:45:58 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 19 Mar 2003 15:45:56 -0800 To: Eric Brunner-Williams in Portland Maine Cc: "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com Subject: Re: [ietf-provreg] provreg's privacy issue References: <038301c2ee5a$865c79f0$7e8a8182@neteka.inc> <200303192339.h2JNd8GL024538@nic-naa.net> Message-Id: Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > o a BEGIN END section of formal syntax with very, very little text > seperating these delimeters (don't worry, we haven't gotten even > a syntax clue from the IESG), this is quite incorrect, you just didn't like it. once again, data structures 101 sez that each attribute would have a privacy tag, as opposed to a blob of tags at the front. but, as far as i am aware, no one on the iesg cares that much about the syntax, it's the privacy semantics which ran aground. randy From owner-ietf-provreg@cafax.se Wed Mar 19 21:54:56 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 VAA21625 for ; Wed, 19 Mar 2003 21:54:49 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2K2VHx9013497 for ; Thu, 20 Mar 2003 03:31:17 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2K2VH9l013496 for ietf-provreg-outgoing; Thu, 20 Mar 2003 03:31:17 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2K2VFx9013491 for ; Thu, 20 Mar 2003 03:31:16 +0100 (MET) Message-ID: <043301c2ee88$b243dcb0$7e8a8182@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: References: <200303192339.h2JNd8GL024538@nic-naa.net> Subject: Re: [ietf-provreg] provreg's privacy issue Date: Wed, 19 Mar 2003 21:30:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric, Good to hear that you have read my stuff. :-) ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To > Some text, on this list, before going off into the delirium of boiler-plate, > would have been a blessing, neh? This reflects some of the things we have done for a particular client. I saw some discussion in the group earlier about possibly having an extension and a public/private toggle type thinking and thought this could be a starting point. > I see ... > o a glob going from registry to registrar (don't tell the iesg), > o a glob on response, approximately 1k in size, It is a bit bulky right now. but really it is whether this concept is good that is the discussion... we could make it a bit more efficient, but will loose some flexibility. We could make it much more efficient if we could incorporated it directly into domain mapping... > o a glob on response, ditto, > o a bi-di glob on !!! bi-di glob??... what do you mean? > I see ... > o two hooks parked at the IANA to hang some coats on, fine. Ok. Will take these away in the submission. I was just doing a plain copy and "search and replace". :-) > Not only does this NOT do what our Masters in Moscow, the IESG, require, > (the glob goes in the wrong direction), the scope of the extension, as > it is from registry to registrar, cannot apply to any instance of WHOIS > operated by the registry. I do not understand why it does not apply to the WHOIS... if the info is deemed to be "public" it is published, if it is "private" it is not published at the WHOIS. > registrar_N (Neteka) initiates a session with registry_V, > > registry_V ships back a that says 95/46/EC applies > and all data is not repurposed, there are no recipients > other than the registry, that it retains the data only > for the period of registration, plus some operational window > for the purpose of renewal, and ... everything is _private_ > (except publication via 1034/35). > > What data collection / privacy problem remains (that your proposal > cleverly solves)? While I am not familiar with 95/46/EC, I think at the least, from the response I will know which contact info I will need to disclose and which ones will be hidden and which ones I can later optionally opt-in or out. I dont think it "cleverly" solves anything, it just allows the registry to annouce its policies as well as the client to specify its preferences. > registrar_N (Neteka) initiates a session with registry_V, > > registry_V ships back a that says says anything you want, > even no at all, > > registrar_N does a create for mumble, > registry_V acks appropriately > > registrar_N ships an update on mumble that attempts to set a bit, > e.g., don't publish phone #, provisioned in the prior op, > > registry_V nacks inappropriately, and in bad taste. What do you mean? Do you mean that the registry advertises that the client may choose to make phone# private yet not allow it to change the status to private? If so, then the registry system is broken... > Now what happens? If the registry nacks the status=private operation later because of change of policy, then there should be probably be out-of-band communication to announce to all users, also, the client can always do a domain info to check the status and current registry policy for each info item. > Why "discover" access policy _after_ a committing a write? Please clarify what you mean? Edmon From owner-ietf-provreg@cafax.se Thu Mar 20 00:29: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 AAA26373 for ; Thu, 20 Mar 2003 00:28:47 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2K58px9014580 for ; Thu, 20 Mar 2003 06:08:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2K58p8I014579 for ietf-provreg-outgoing; Thu, 20 Mar 2003 06:08:51 +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.8/8.12.8) with ESMTP id h2K58nx9014574 for ; Thu, 20 Mar 2003 06:08:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2K57oGL028531; Thu, 20 Mar 2003 00:07:50 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303200507.h2K57oGL028531@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 21:30:35 EST." <043301c2ee88$b243dcb0$7e8a8182@neteka.inc> Date: Thu, 20 Mar 2003 00:07:50 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Good to hear that you have read my stuff. :-) No one reads mine, so I'll stop writing it and read yours, its the worst I can do ;-) > It is a bit bulky right now. I'll send you what I did to de-xml-ize p3p policies on cookies, where overhead did matter. Here however, overhead shouldn't. But don't optimize too early ... > > o a bi-di glob on !!! > > bi-di glob??... what do you mean? On both command and response. This is where the action is. Who cares if the server and responses have new glop? What counts is if by a write (here ) against the shared store (here registry) manages to either fail to error (glop accepted by registry as some policy description, considered by registry to be "valid"), or can generate a change in the glop that comes back in any response. If none, then either the registry had the "right" policy already, or ignored the attempted policing of data previously provisioned in the client (and nominally annotated in the new glop in the repsponse). > I do not understand why it does not apply to the WHOIS... It does, but there are some loopholes. > ... from the response I will know which contact info I will > need to disclose and which ones will be hidden and which ones I can > later optionally opt-in or out ... So you see this as a field query mechanism. Fine. > ... it just allows the registry to annouce its policies ... "Which fields are manditory to fill in?" is different from "What is done with data provisioned?" > What do you mean? Do you mean that the registry advertises that the client > may choose to make phone# private yet not allow it to change the status to > private? If so, then the registry system is broken... > >> Now what happens? > > If the registry nacks the status=private operation later because of change > of policy, then there should be probably be out-of-band communication to > announce to all users, also, the client can always do a domain info to check > the status and current registry policy for each info item. Yes I do. To be concrete, domains are sold by the COM/NET registry to a set of registrars, for periods of up to 10 years. What are the temporal properties of policy guarantees? If you assume a place-holder create, followed by the "real" create, more or less in the same session, or a real create, followed by a series of updates to "tune" the privacy policy to taste, again in more or less the same session, you've not solved for the day when policies do in fact change. But you thought that through, and decided that the temporal properties of polices is better communicated out-of-band, so they could in fact change without in-band notice. If the temporal properties of policies are better communicated out-of-band, why are the semantic properties of policies better communicated in-band? > > Why "discover" access policy _after_ a committing a write? > > Please clarify what you mean? Your proposal makes no reliance upon any policy information from the registry. You've proposed a momentary capabilities check arising from a command, but you only get the data in the response. Therefore, either each command is preceeded by some command who's side effect is to discover the present policy, or each command is followed by a series of one or more commands to conform the policy (applicable to some specific object) at the server to the policy goal held by the client. Its a hell of a lot easier to simply have the server announce its policy, and if a mechanism is necessary to select some set of values from some range of values (and I'm referring to purpose, recipient, retention and so forth, as well as which field in the contact object is optional), to get on with its specification, than finding it after assuming it even exists. Eric P.S. Get rid of everything except the glop. , , test response, repeat until correct, or failure. Upon failure, issue . If fails, issue with the personal data of the registry CEO, or the current ICANN CEO, depending on one's sense of humor. P.P.S. This only solves for WHOIS, not for any other purpose, mechanism, or period, to which provisioned data may be used without prior disclosure and informed consent, or at least the opportunity to form same, buy the registrar, and presumbly the parties it acts on behalf of. P.P.P.S. Cheers! From owner-ietf-provreg@cafax.se Thu Mar 20 14:56: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 OAA02195 for ; Thu, 20 Mar 2003 14:56:39 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2KJhax9022679 for ; Thu, 20 Mar 2003 20:43:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2KJha5F022678 for ietf-provreg-outgoing; Thu, 20 Mar 2003 20:43:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2KJhWx9022673 for ; Thu, 20 Mar 2003 20:43:34 +0100 (MET) Message-ID: <059001c2ef18$dec03ff0$7e8a8182@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , References: <200303200507.h2K57oGL028531@nic-naa.net> Subject: Re: [ietf-provreg] provreg's privacy issue Date: Thu, 20 Mar 2003 11:57:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric, ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" > I'll send you what I did to de-xml-ize p3p policies on cookies, where overhead > did matter. Here however, overhead shouldn't. But don't optimize too early ... That will be great. Yeah, we were thinking that we should maintain flexibility first and then optimize later (in fact, our actual implementation is much leaner... but because this was intended to be a protocol discussion, we made it a bit more extensible. and thus, larger overhead. > > I do not understand why it does not apply to the WHOIS... > > It does, but there are some loopholes. > > > ... from the response I will know which contact info I will > > need to disclose and which ones will be hidden and which ones I can > > later optionally opt-in or out ... > > So you see this as a field query mechanism. Fine. > > > ... it just allows the registry to annouce its policies ... > > "Which fields are manditory to fill in?" No. This will result in a failure to create, not a successful response. > is different from > "What is done with data provisioned?" Yes. This is the intent. Public means that the info will be published to the WHOIS, and Private means that it will be hidden. The current mechanism is this simple. > Yes I do. To be concrete, domains are sold by the COM/NET registry to a set > of registrars, for periods of up to 10 years. What are the temporal properties > of policy guarantees? If you assume a place-holder create, followed by the > "real" create, more or less in the same session, or a real create, followed > by a series of updates to "tune" the privacy policy to taste, again in more > or less the same session, you've not solved for the day when policies do in > fact change. So you are saying that the server should perhaps queue a msg for the client if policies are to be changed?... or something in-band to announce to the clients? > But you thought that through, and decided that the temporal properties of > polices is better communicated out-of-band, so they could in fact change > without in-band notice. Just thought it seems to make a bit more sense in a practical environment. For example, when I look at a ccTLD, they will be putting out a public statement or even consultation paper or something before they change their policies, > If the temporal properties of policies are better communicated out-of-band, > why are the semantic properties of policies better communicated in-band? Because of 2 things: 1. the client needs to know what (which info item) exactly they can manage (public/private) 2. they can toggle public/private on the aspects that are allowed to be optional > Your proposal makes no reliance upon any policy information from the > registry. You've proposed a momentary capabilities check arising from > a command, but you only get the data in the response. So perhaps it is good to extend the check command as well to return the policy statements so that clients will know what they are getting into beforehand... > Its a hell of a lot easier to simply have the server announce its policy, > and if a mechanism is necessary to select some set of values from some > range of values (and I'm referring to purpose, recipient, retention and > so forth, as well as which field in the contact object is optional), to > get on with its specification, than finding it after assuming it even > exists. dcp should be good to deal with the purpose and stuff. My proposal aims to make an effort to allow granular management of information privacy. We could extend the tags so that each facet can be further optionally bound by multiple policies based on the usage of data. Also, I think you are right, perhaps the info response should be a bit different and allow the client to query for only the privacy policy elements and not return the entire glob everytime. I will make that change. Edmon From owner-ietf-provreg@cafax.se Thu Mar 20 15:53:58 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 PAA06112 for ; Thu, 20 Mar 2003 15:53:52 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2KKgIx9023326 for ; Thu, 20 Mar 2003 21:42:18 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2KKgI38023325 for ietf-provreg-outgoing; Thu, 20 Mar 2003 21:42:18 +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.8/8.12.8) with ESMTP id h2KKgGx9023320 for ; Thu, 20 Mar 2003 21:42:16 +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 PAA01292 for ; Thu, 20 Mar 2003 15:42:09 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 15:39:14 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370873@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: [ietf-provreg] References for Today's Host Object Discussion Date: Thu, 20 Mar 2003 15:39:13 -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 After today's meeting some people asked me for a reference to an earlier discussion about host objects being used as name servers. For those of you who weren't there, we talked a little bit about the history of why we have an object concept for name server hosts. Part of the ensuing discussion touched on all of the options that have been discussed over the last few years, including: - Host objects for all name servers. (This is a simplified expression of what we have in the documents now) - Host objects for only in-zone hosts, with external hosts specified as domain object attributes. http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00008.html - Allowing a choice between name server host objects and name server domain attributes. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html I've included references to the list archives where I've been able to find them. What did we ever do before google came along... For what it's worth, I kind of like the last option (or something like it) as something to consider for the next version of the protocol. We've heard a lot of comments from people having issues with host objects as name servers; maybe we can eliminate the issues if we allow a choice. -Scott- From owner-ietf-provreg@cafax.se Thu Mar 20 17:12: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 RAA10055 for ; Thu, 20 Mar 2003 17:12:19 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2KM1ox9024338 for ; Thu, 20 Mar 2003 23:01:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2KM1ot1024337 for ietf-provreg-outgoing; Thu, 20 Mar 2003 23:01: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.8/8.12.8) with ESMTP id h2KM1jx9024332 for ; Thu, 20 Mar 2003 23:01:47 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2KM0XGL031807; Thu, 20 Mar 2003 17:00:33 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303202200.h2KM0XGL031807@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Thu, 20 Mar 2003 11:57:05 EST." <059001c2ef18$dec03ff0$7e8a8182@neteka.inc> Date: Thu, 20 Mar 2003 17:00:33 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > So you see this as a field query mechanism. Fine. > > > > > ... it just allows the registry to annouce its policies ... > > > > "Which fields are manditory to fill in?" > > No. This will result in a failure to create, not a successful response. My point was, you've designed a query mechanism, and what looks like a two command sequence. > > is different from > > "What is done with data provisioned?" > > Yes. This is the intent. Public means that the info will be published to > the WHOIS, and Private means that it will be hidden. The current mechanism > is this simple. Well, not-via-:43 is clear. "private" and "public" are terms of art that resist unambiguous specification. > > or less the same session, you've not solved for the day when policies do > > in fact change. > > So you are saying that the server should perhaps queue a msg for the client > if policies are to be changed?... or something in-band to announce to the > clients? I point out that there is a temporal property contained in the , that the retention period of the data (and the policies announced when the server announces its availability to collect data) is known to the client (along with anything else that might be in a , prior to the client submitting data to the server. > > But you thought that through, and decided that the temporal properties of > > polices is better communicated out-of-band, so they could in fact change > > without in-band notice. > > Just thought it seems to make a bit more sense in a practical environment. > For example, when I look at a ccTLD, they will be putting out a public > statement or even consultation paper or something before they change their > policies, Sense? Practicality? Taste varies. I'd like to automate privacy/datacollection handling in registration systems. > > If the temporal properties of policies are better communicated > out-of-band, > > why are the semantic properties of policies better communicated in-band? > > Because of 2 things: > > 1. the client needs to know what (which info item) exactly they can manage > (public/private) > 2. they can toggle public/private on the aspects that are allowed to be > optional But with no guarantee that the policies will be consistent between any two consequtive registrations. > > Your proposal makes no reliance upon any policy information from the > > registry. You've proposed a momentary capabilities check arising from > > a command, but you only get the data in the response. > > So perhaps it is good to extend the check command as well to return the > policy statements so that clients will know what they are getting into > beforehand... Back to the two-step. Familiar to registrars who want to know if a of "somewellknownname" will fail, before attempting it. . Not significantly different from (and optionally, if disapointed, ). > > Its a hell of a lot easier to simply have the server announce its policy, > > and if a mechanism is necessary to select some set of values from some > > range of values (and I'm referring to purpose, recipient, retention and > > so forth, as well as which field in the contact object is optional), to > > get on with its specification, than finding it after assuming it even > > exists. > > dcp should be good to deal with the purpose and stuff. My proposal aims to > make an effort to allow granular management of information privacy. We > could extend the tags so that each facet can be further optionally bound by > multiple policies based on the usage of data. Also, I think you are right, > perhaps the info response should be a bit different and allow the client to > query for only the privacy policy elements and not return the entire glob > everytime. I will make that change. . Eric From owner-ietf-provreg@cafax.se Fri Mar 21 11:02:32 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 LAA17665 for ; Fri, 21 Mar 2003 11:02:30 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2LFr9x9003814 for ; Fri, 21 Mar 2003 16:53:09 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2LFr8C9003812 for ietf-provreg-outgoing; Fri, 21 Mar 2003 16:53:08 +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.8/8.12.8) with ESMTP id h2LFqrx9003795 for ; Fri, 21 Mar 2003 16:52:55 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2LFpTGL035078; Fri, 21 Mar 2003 10:51:29 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303211551.h2LFpTGL035078@nic-naa.net> To: Randy Bush cc: Eric Brunner-Williams in Portland Maine , "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:45:56 PST." Date: Fri, 21 Mar 2003 10:51:29 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Randy, and anyone else with a view, > a privacy tag, ... > ... > ... it's the privacy semantics which ran aground. In the abstract, there exists at least two distinct values that an algorithmic evaluation of a variable may yeild. Ignoring everything else, is the IESG's guidance on this subject, that the set of values for which any algorithmic evaluation of a privacy tag is exactly two? If it is not exactly two, what is the exact characterization of the value space? Thanks in advance, Eric From owner-ietf-provreg@cafax.se Fri Mar 21 12:12: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 LAA17666 for ; Fri, 21 Mar 2003 11:02:30 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2LFr9x9003813 for ; Fri, 21 Mar 2003 16:53:09 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2LFr8Wn003811 for ietf-provreg-outgoing; Fri, 21 Mar 2003 16:53:08 +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.8/8.12.8) with ESMTP id h2LFqsx9003796 for ; Fri, 21 Mar 2003 16:52:55 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2LFpXGL035081; Fri, 21 Mar 2003 10:51:33 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303211551.h2LFpXGL035081@nic-naa.net> To: Randy Bush cc: Eric Brunner-Williams in Portland Maine , "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:45:56 PST." Date: Fri, 21 Mar 2003 10:51:33 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Randy, and anyone else with a view, > once again, data structures 101 sez that each attribute would have > a privacy tag, as opposed to a blob of tags at the front. In the abstract, there exists at least one type definition hierarchy. At least one hierarchy is non-degenerate, and the "primitive" and "constructed" model of derivation exists. Ignoring everything else, is the IESG's guidance on this subject, that the type definition hierarchies contained in the EPP spec, fundamentally err by reference to a built-in derived type, or to a primitive type? Thanks in advance, Eric From owner-ietf-provreg@cafax.se Mon Mar 24 01:20:50 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 BAA23420 for ; Mon, 24 Mar 2003 01:20:48 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2O5xax9027729 for ; Mon, 24 Mar 2003 06:59:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2O5xaoi027728 for ietf-provreg-outgoing; Mon, 24 Mar 2003 06:59:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from goose.automagic.org (goose.automagic.org [199.212.90.4]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2O5xYx9027723 for ; Mon, 24 Mar 2003 06:59:34 +0100 (MET) Received: from isc.org (dhcp-k-1.automagic.org [199.212.90.17]) by goose.automagic.org (Postfix) with ESMTP id A81C63541D; Mon, 24 Mar 2003 00:59:30 -0500 (EST) Date: Mon, 24 Mar 2003 00:59:39 -0500 Subject: Re: [ietf-provreg] References for Today's Host Object Discussion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'ietf-provreg@cafax.se'" To: "Hollenbeck, Scott" From: Joe Abley In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD603370873@vsvapostal3.prod.netsol.com> 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 Thursday, Mar 20, 2003, at 15:39 Canada/Eastern, Hollenbeck, Scott wrote: > - Allowing a choice between name server host objects and name server > domain > attributes. > http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html > > I've included references to the list archives where I've been able to > find > them. What did we ever do before google came along... > > For what it's worth, I kind of like the last option (or something like > it) > as something to consider for the next version of the protocol. We've > heard > a lot of comments from people having issues with host objects as name > servers; maybe we can eliminate the issues if we allow a choice. Thanks for posting that link; I have been hearing similar comments for some time, and I hadn't realised the issue had already been considered. Eliminating the requirement to support host objects would make EPP a viable prospect for several registries that I have talked to recently. I wonder whether it might be reasonable to accommodate the non-host-object case in the current spec before it is shipped for proposed standard. This doesn't seem like it would be a major change to the text, and the impact on existing implementations seems small (zero, maybe) considering that the spec would not change for registries which choose to include host objects. I would be happy to contribute text if this sounds like a reasonable approach. Joe From owner-ietf-provreg@cafax.se Mon Mar 24 07:40:55 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 HAA12681 for ; Mon, 24 Mar 2003 07:40:54 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OCS5x9000747 for ; Mon, 24 Mar 2003 13:28:05 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OCS5Ah000746 for ietf-provreg-outgoing; Mon, 24 Mar 2003 13:28:05 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OCS3x9000741 for ; Mon, 24 Mar 2003 13:28:04 +0100 (MET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12201; Mon, 24 Mar 2003 07:25:44 -0500 (EST) Message-Id: <200303241225.HAA12201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt Date: Mon, 24 Mar 2003 07:25:43 -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-09.txt Pages : 75 Date : 2003-3-21 This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-epp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-epp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-21155106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-21155106.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-provreg@cafax.se Mon Mar 24 09:16:32 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 JAA19370 for ; Mon, 24 Mar 2003 09:16:30 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ODudx9001663 for ; Mon, 24 Mar 2003 14:56:39 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ODud1s001662 for ietf-provreg-outgoing; Mon, 24 Mar 2003 14:56:39 +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.8/8.12.8) with ESMTP id h2ODubx9001657 for ; Mon, 24 Mar 2003 14:56:38 +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 IAA12141 for ; Mon, 24 Mar 2003 08:56:30 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 08:53:20 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370882@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt Date: Mon, 24 Mar 2003 08:53:18 -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 Aww, phooey. This is the document that was edited based on our most recent miscommunication with the IESG; the response I received from the I-D administrator said it would NOT be retained when I sent it after the submission deadline had passed. As discussed during IETF-56, I didn't send it in again. It's going to have to be edited again once we get the privacy topics discussed during the IETF meeting out on the list for open discussion (hint, hint). -Scott- > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, March 24, 2003 7:26 AM > To: IETF-Announce; @cafax.se > Cc: ietf-provreg@cafax.se > Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Provisioning Registry > Protocol Working Group of the IETF. > > Title : Extensible Provisioning Protocol > Author(s) : S. Hollenbeck > Filename : draft-ietf-provreg-epp-09.txt > Pages : 75 > Date : 2003-3-21 > > This document describes an application layer client-server protocol > for the provisioning and management of objects stored in a shared > central repository. Specified in XML, the protocol defines generic > object management operations and an extensible framework that maps > protocol operations to objects. This document includes a protocol > specification, an object mapping template, and an XML media type > registration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt From owner-ietf-provreg@cafax.se Mon Mar 24 09:57: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 JAA20598 for ; Mon, 24 Mar 2003 09:57:00 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OEW1x9002096 for ; Mon, 24 Mar 2003 15:32:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OEW1Xm002095 for ietf-provreg-outgoing; Mon, 24 Mar 2003 15:32:01 +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.8/8.12.8) with ESMTP id h2OEVvx9002090 for ; Mon, 24 Mar 2003 15:31:59 +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 h2OEVv34079001; Mon, 24 Mar 2003 09:31:57 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.46]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA13844; Mon, 24 Mar 2003 09:31:56 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: Date: Sun, 23 Mar 2003 15:23:13 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] Our "Privacy Issue" Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk During the face to face meeting in SF, we had a productive discussion of the privacy issue that has been holding up progress. Minutes, et.al. of the meeting will be forthcoming, but the first action item to arise from the meeting is a presentation to the WG (list) a detailed description of the problem. In a discussion that involved Ted Hardie, our new Area Advisor, and Randy Bush, the following comment was cast into the following requirement: The protocol must provide a mechanism to allow enforcement of privacy policy at either the registrar or registrant. This must be done in a protocol feature that is "mandatory to implement, optional to use." Further, the privacy meta-data must be to individual elements of social data. First, before going further, what is stated above is the suggestion derived during the face-to-face meeting. Being that this is a clarification of the IESG comment obtained with representatives present, this is what we need to solve. However, wording changes may be made. As EPP stands now, privacy policy decisions are only possible at the registrar. This is because the dcp element allows the registry to tell the registrar the "rules." Whatever the registrar sends to the registry is considered to be in accordance with the rules. What is desired is a mechanism that will let EPP support thick registries, in which social data is held by the registry. In such situations, the registrar needs to inform the registry of restrictions on the redistribution of the data submitted to the registry. There are limits to what the WG is being asked to do. We are not being asked to provide a very rich syntax for the mechanism. For example, we are not being asked to provide a means to say "you can publish the phone number in whois but not in any other way." (We could, if we desired, but we are not asked to do.) There's one protocol standards consideration I'd like to make. The more detail and depth in the solution of a problem often leads to a tougher job in reaching consensus. I.e., as a chair, I appreciate efforts to refine and divine the depths of privacy, but such threads are in danger of becoming distractions to the main job of this WG. During the meeting, it was suggested that a mechanism to meet the requirement has already been sent to the mailing list and discussed. The next steps for the WG is to 1) consider and discuss the requirement in this message. If the WG accepts this as the problem statement as discussion in the room did, the next step will be to open a thread on the modified proposal suggested. For procedural reasons, I'm not going to mention that proposal until the problem statement is accepted by the WG (i.e., the mailing list). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Mon Mar 24 11:58:19 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 LAA25465 for ; Mon, 24 Mar 2003 11:58:18 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OGkpx9003774 for ; Mon, 24 Mar 2003 17:46:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OGkpbn003773 for ietf-provreg-outgoing; Mon, 24 Mar 2003 17:46:51 +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.8/8.12.8) with ESMTP id h2OGkox9003768 for ; Mon, 24 Mar 2003 17:46:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2OGilGL062506; Mon, 24 Mar 2003 11:44:47 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303241644.h2OGilGL062506@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Sun, 23 Mar 2003 15:23:13 EST." Date: Mon, 24 Mar 2003 11:44:47 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk ... > The protocol must provide a mechanism to allow enforcement OK. We blew it semantically in the grrq when we stated the req as a mechanism to announce. > of privacy > policy at either the registrar or registrant. OK. We blew it semantically in the grrq when we limited the protocol to registrars and registries. > This must be done in a > protocol feature that is "mandatory to implement, optional to use." No comment. > Further, the privacy meta-data must be to individual elements of > social data. OK. We blew it syntactically by reference to an inextensible type. > ... this is what we need to solve ... I disagree with the claim that any IETF WG needs to be responsive to the IESG. The claim only begins to approximate "true" iff the WG wants IESG approval of its work-product. I'm not convinced that the issue of contention is technical. > As EPP stands now, privacy policy decisions are only possible at the > registrar. This is because the dcp element allows the registry to > tell the registrar the "rules." Whatever the registrar sends to the > registry is considered to be in accordance with the rules. Correct. The registry announces a session-policy. Implementors are free to evaluate the registry-announced policy, and implement local policy, e.g., accept the policy and propogate policied data, or decline. > What is desired is a mechanism that will let EPP support thick > registries, in which social data is held by the registry. Umm, this _is_ the current model, neh? > In such > situations, the registrar needs to inform the registry of > restrictions on the redistribution of the data submitted to the > registry. This does not follow. Where state is persistent is a different issue from how may access to that persistent state be implemented. Just to test the correctness of this reasoning however, if there did exist a mechanism for a client to select from a menu of policies in a (this begins to look like beep and the srv record), and the menu offered by a registry was _in_theory_exhaustive_, would the registrar need to do anything more exciting than pick a policy out of the extended hat? > There's one protocol standards consideration I'd like to make. The > more detail and depth in the solution of a problem often leads to a > tougher job in reaching consensus. I.e., as a chair, I appreciate > efforts to refine and divine the depths of privacy, but such threads > are in danger of becoming distractions to the main job of this WG. I'll be _happy_ to leave the problem to more capable hands than my own. To me, it _was_ just distributed read and write access mechanisms to shared store, with a specific syntax. If someone claims read-on-43 exhaustively defines "privacy", I don't care. It doesn't exhaustively define _read_. Enforcement is a whole different can of worms, unless this is just a techno-fiction. > For procedural > reasons, I'm not going to mention that proposal until the problem > statement is accepted by the WG (i.e., the mailing list). Nope. Seems technically flawed to me, and worse than what we had. YMMV. Eric From owner-ietf-provreg@cafax.se Mon Mar 24 16:33: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 QAA04334 for ; Mon, 24 Mar 2003 16:33:20 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OLMNx9007343 for ; Mon, 24 Mar 2003 22:22:23 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OLMNDd007342 for ietf-provreg-outgoing; Mon, 24 Mar 2003 22:22:23 +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.8/8.12.8) with ESMTP id h2OLMLx9007337 for ; Mon, 24 Mar 2003 22:22:21 +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 h2OLMI34095925; Mon, 24 Mar 2003 16:22:18 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.46]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA00630; Mon, 24 Mar 2003 16:22:15 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303241644.h2OGilGL062506@nic-naa.net> References: <200303241644.h2OGilGL062506@nic-naa.net> Date: Mon, 24 Mar 2003 16:21:09 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:44 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote: >I'm not convinced that the issue of contention is technical. Then I've failed in my description of the problem. As we sit, EPP requires the registrar to make decisions on whether the submission of a piece of data will be accorded the proper handling with regards to privacy. The issue is that EPP forces the registrar into this posture, there is no choice. What the IESG has asked of us is to make EPP possible to support a scenario in which a registrar gives the data and policy request to the registry and then let the registry decide what to do. Furthermore, a basic framework for this is desired to be part of the base protocol. The IESG is doing this through the role of protocol design engineer review - recognizing functionality that oughta be in a protocol but isn't. >The registry announces a session-policy. Implementors are free >to evaluate the registry-announced policy, and implement local policy, >e.g., accept the policy and propogate policied data, or decline. But the only option available to users of the client is to decide whether or not to make the registration. We want more of an option than that. >To me, it _was_ just distributed read and write access mechanisms to >shared store, with a specific syntax. If someone claims read-on-43 >exhaustively defines "privacy", I don't care. It doesn't exhaustively >define _read_. I don't think anyone is trying to link privacy to what's on port 43 (whois to most of us). The goal isn't to tie privacy to any publication mechanism. This is done with the intent that during the phase of reaching towards DS, we will have more tools for dealing with privacy. Features are more easily removed from PS to DS than added. >Enforcement is a whole different can of worms, unless this is just a >techno-fiction. Enforcement is part of policy and we are making every effort to sidestep it. >Nope. Seems technically flawed to me, and worse than what we had. I don't see how. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Mon Mar 24 18:16: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 SAA09314 for ; Mon, 24 Mar 2003 18:16:30 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ON4gx9008530 for ; Tue, 25 Mar 2003 00:04:42 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ON4gVj008529 for ietf-provreg-outgoing; Tue, 25 Mar 2003 00:04:42 +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.8/8.12.8) with ESMTP id h2ON4fx9008524 for ; Tue, 25 Mar 2003 00:04:41 +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 SAA22932; Mon, 24 Mar 2003 18:04:33 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:04:37 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337088B@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Joe Abley'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] References for Today's Host Object Discussion Date: Mon, 24 Mar 2003 18:01:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I wonder whether it might be reasonable to accommodate the > non-host-object case in the current spec before it is shipped for > proposed standard. This doesn't seem like it would be a major > change to > the text, and the impact on existing implementations seems > small (zero, > maybe) considering that the spec would not change for > registries which > choose to include host objects. I'm not one of the people responsible for determining consensus, but I can say that the domain document has completed both WG and IETF last calls with the currently specified feature set. Our chairs can, of course, direct me to change something if WG consensus is to make a change. I'd prefer to keep things as-is, though, because this is _not_ a new argument and we'll have a chance to address this again when considering what to do when going from proposed to draft. One of the things I intend to do once we're there is capture the outstanding issues in an I-D that can be used to seed the proposed-to-draft discussion. It would be helpful if people who have issues with any current features could send me a note (off-list is OK) describing what they don't like _and_ a suggested solution. We might then have the start of a pretty good problem statement for EPP 1.1 or 2.0. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 24 18:22:23 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 SAA09409 for ; Mon, 24 Mar 2003 18:22:22 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ONBDx9008644 for ; Tue, 25 Mar 2003 00:11:13 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ONBDPu008643 for ietf-provreg-outgoing; Tue, 25 Mar 2003 00:11:13 +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.8/8.12.8) with ESMTP id h2ONBBx9008638 for ; Tue, 25 Mar 2003 00:11:12 +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 SAA23241; Mon, 24 Mar 2003 18:11:03 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:11:07 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337088C@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] Our "Privacy Issue" Date: Mon, 24 Mar 2003 18:07:43 -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 > During the meeting, it was suggested that a mechanism to meet the > requirement has already been sent to the mailing list and discussed. > The next steps for the WG is to 1) consider and discuss the > requirement in this message. If the WG accepts this as the problem > statement as discussion in the room did, the next step will be to > open a thread on the modified proposal suggested. For procedural > reasons, I'm not going to mention that proposal until the problem > statement is accepted by the WG (i.e., the mailing list). I accept the problem statement as described. It reflects what I heard in the room last Thursday. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 24 18:46:24 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 SAA09972 for ; Mon, 24 Mar 2003 18:46:22 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ONZMx9008995 for ; Tue, 25 Mar 2003 00:35:23 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ONZMoV008994 for ietf-provreg-outgoing; Tue, 25 Mar 2003 00:35:22 +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.8/8.12.8) with ESMTP id h2ONZLx9008989 for ; Tue, 25 Mar 2003 00:35:21 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2ONXGGL063921; Mon, 24 Mar 2003 18:33:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303242333.h2ONXGGL063921@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Mon, 24 Mar 2003 16:21:09 EST." Date: Mon, 24 Mar 2003 18:33:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >I'm not convinced that the issue of contention is technical. > > Then I've failed in my description of the problem. It had one error. The assertion that to function (at all) some delta is required. The correct statement is to function (as required post rfc3375) some delta is required. Requirement by assertion is more popular than I recall. > As we sit, EPP requires the registrar to make decisions on whether > the submission of a piece of data will be accorded the proper > handling with regards to privacy. The issue is that EPP forces the > registrar into this posture, there is no choice. There are a lot of restrictions. RRP doesn't have this one (it has others). SRS doesn't have this one (it too has others). Etcetera. Its a nuance that may be lost on some, but the evaluation possible by the registrar isn't necessarily prospective (forward looking), it can be of the announced policy at the moment of transactional evaluation, with some explicit temporal guarantees. Mind, all of the evaluation is either optional (epp-07), manditory (epp-08), or irrelevant (iesg-any). > What the IESG has asked of us is to make EPP possible to support a > scenario in which a registrar gives the data and policy request to > the registry and then let the registry decide what to do. Question #1: If the client originated a as part of session init, and the server responded with a , and the evalution algorithm (tbd) was simple, e.g., equality, would that meet their requirement? > Furthermore, a basic framework for this is desired to be part of the > base protocol. As the formal specification of this protocol is in XML, this is more than it appears. In eppcom-1.0.xsd we have this: We use it to define type ofthe element "email". Now how does a "data structures 101" compatible tag fit into that? > The IESG is doing this through the role of protocol design engineer > review - recognizing functionality that oughta be in a protocol but > isn't. 3375 is the requirements statement. > >The registry announces a session-policy. Implementors are free > >to evaluate the registry-announced policy, and implement local policy, > >e.g., accept the policy and propogate policied data, or decline. > > But the only option available to users of the client is to decide > whether or not to make the registration. We want more of an option > than that. Please explain. > >To me, it _was_ just distributed read and write access mechanisms to > >shared store, with a specific syntax. If someone claims read-on-43 > >exhaustively defines "privacy", I don't care. It doesn't exhaustively > >define _read_. > > I don't think anyone is trying to link privacy to what's on port 43 > (whois to most of us). The goal isn't to tie privacy to any > publication mechanism. This is done with the intent that during the > phase of reaching towards DS, we will have more tools for dealing > with privacy. Features are more easily removed from PS to DS than > added. This is where the non-technical bit lives. Let's go back: > >I'm not convinced that the issue of contention is technical. Just how complex is "privacy"? Is it a property that a tag is a useful mechanism to encode it? If "privacy" is simple, something that fits in a tag, then we have one technical issue. If "privacy" is not simple, then we have another technical issue. It is my sense that "privacy" is not simple. > >Enforcement is a whole different can of worms, unless this is just a > >techno-fiction. > > Enforcement is part of policy and we are making every effort to sidestep it. To avoid non-sensicalness however, an enforcable mechanism needs to be capable of violation detection. No spitting when I'm not looking is not impressive. > >Nope. Seems technically flawed to me, and worse than what we had. > > I don't see how. Cheers, Eric From owner-ietf-provreg@cafax.se Tue Mar 25 10:10:52 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 KAA16763 for ; Tue, 25 Mar 2003 10:10:50 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PEqVx9017293 for ; Tue, 25 Mar 2003 15:52:31 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PEqVcu017292 for ietf-provreg-outgoing; Tue, 25 Mar 2003 15:52:31 +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.8/8.12.8) with ESMTP id h2PEqTx9017286 for ; Tue, 25 Mar 2003 15:52:29 +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 h2PEqR34011012; Tue, 25 Mar 2003 09:52:28 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.41]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA08471; Tue, 25 Mar 2003 09:52:26 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303242333.h2ONXGGL063921@nic-naa.net> References: <200303242333.h2ONXGGL063921@nic-naa.net> Date: Tue, 25 Mar 2003 09:51:16 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote: >It had one error. The assertion that to function (at all) some delta >is required. The correct statement is to function (as required post >rfc3375) some delta is required. Eric, help me here. What is your point? >Requirement by assertion is more popular than I recall. I'm still not getting your point. I'm not sure if you are unhappy that someone wants to add client-sent statements on privacy or that the someone is the IESG. I'm not sure I see a reason from you explaining why adding this is a bad idea. >Question #1: If the client originated a as part of session >init, and the server responded with a , and the evalution >algorithm (tbd) was simple, e.g., equality, would that meet their >requirement? Initially, this might be, but as an outcome of the discussion in the meeting we felt that finer granularity was desirable and achievable. We talked about this as being a session-granular thing, but that was discarded. >In eppcom-1.0.xsd we have this: You're getting into an implementation detail. At this point, we are hashing out the problem statement. >> The IESG is doing this through the role of protocol design engineer >> review - recognizing functionality that oughta be in a protocol but >> isn't. > >3375 is the requirements statement. Yeah, it is. Obviously, you mean something by saying that, but it is not clear. >> But the only option available to users of the client is to decide >> whether or not to make the registration. We want more of an option >> than that. > >Please explain. We want the registrar to be able to say, here's the phone number but don't send it anywhere. What is meant by 'anywhere' is policy specific, hence outside the WG's concern. >It is my sense that "privacy" is not simple. Then it's not privacy we are concerned about. It's about tagging data with something called 'privacy.' Recall that this effort is to build an interoperable, general purpose protocol. If there is something you think is useless and harmless, then don't use it and don't complain. (Harmless = doesn't cause a lot of things, including [useless] bloat.) You may decide that what is here is not enough, then use an extension. You may decide what is here does not apply to you, but if it applies to someone else, see if you can live with it. The process is about finding "common denominators" and not tailored, optimized, solutions. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Tue Mar 25 13:33:26 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 NAA24528 for ; Tue, 25 Mar 2003 13:33:24 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PIO0x9019646 for ; Tue, 25 Mar 2003 19:24:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PIO0wC019645 for ietf-provreg-outgoing; Tue, 25 Mar 2003 19:24:00 +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.8/8.12.8) with ESMTP id h2PINwx9019640 for ; Tue, 25 Mar 2003 19:23:58 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PILeGL067674; Tue, 25 Mar 2003 13:21:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303251821.h2PILeGL067674@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 09:51:16 EST." Date: Tue, 25 Mar 2003 13:21:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Ed, Long and interlinear. > At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote: > >It had one error. The assertion that to function (at all) some delta > >is required. The correct statement is to function (as required post > >rfc3375) some delta is required. > > Eric, help me here. What is your point? You wrote: What is desired is a mechanism that will let EPP support thick registries, in which social data is held by the registry. No new mechanism is required by this sentence. In such situations, the registrar needs to inform the registry of restrictions on the redistribution of the data submitted to the registry. False. It is a requirement not in 3375. It is a new requirement, one that modifies some functionality. OK, so neither of us writing or grading english compositions. EPP "works" as is (-02, -04, -06, ... for some value of "works"), and some new thing is desired by someone in -0N, for some value of N. Fair enough. > >Requirement by assertion is more popular than I recall. > > I'm still not getting your point. I'm not sure if you are unhappy > that someone wants to add client-sent statements on privacy or that > the someone is the IESG. I'm not sure I see a reason from you > explaining why adding this is a bad idea. Any requirement not in the req doc is either a) previously rejected, or b) a failure of the process that created the req doc, or c) neither a) nor b). Suppose c. We don't know it is a good idea, we do know that it is the IESG's idea. So, when we say that Scott is the editor of documents under the change control of the IETF, what we are really saying is that the actual change control is held, not by the contributors, acting in concert, under 2026, et alia, to create some specification, but by institutional authority figures other than the I-D administrator, who may add/delete/modify the text, without undertaking the corresponding action on the requirements doc, which has already had WGLC, and IETF-LC. If someone wants to modify 3375 and delete the manditory announcement clause, let them. It is possibly deficient. If someone wants to modify 3375 and add a manditory enforcement clause, let them. It is possibly sufficient. I'm "unhappy" about what I see as the technical difficulty of the proposal, the inability of the authors of the proposal to make a technical case for a mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and the process to effect change control of the provreg work product. I wasn't thrilled with the congestion issue either, or the ordering issue, but those are damp spots under prior bridges. > >Question #1: If the client originated a as part of session > >init, and the server responded with a , and the evalution > >algorithm (tbd) was simple, e.g., equality, would that meet their > >requirement? > > Initially, this might be, but as an outcome of the discussion in the > meeting we felt that finer granularity was desirable and achievable. > We talked about this as being a session-granular thing, but that was > discarded. I thought so, which is why I asked. Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select) is unrestricted, _this_isn't_what_the_iesg_wants_. On the bright side, this means that all two-step discovery kludges of the form Edmon proposed are as KIA as the . On the dim side, this seems to mean that the issue is syntax or religion, as there's a heck of a lot of values less than BIGNUM (or a full DOM tree), and a baroque richesse of choices when one is unrestricted. So semantics is possibly _not_ the issue. > > >In eppcom-1.0.xsd we have this: > > You're getting into an implementation detail. At this point, we are > hashing out the problem statement. I could be wrong, but the authors of the document offering guidance on the use of xml in IETF protocols may have failed to mention an edge case. If a type is inextensible, and is used to type a datum that cannot be semantically conditioned by any means other than extension, for reasons that are non-sytactic in nature, an "owie" occurs. I'm sure there is a better form of expressing this than "owie". The point of the implementation detail is that I think (I'd prefer to be wrong) that we need to put a layer between the syntax of EPP extensions to XML, and the basic types of XML, so that "policy" can be hidden in the syntax, which I don't see a way to do with the "mail" element's "token" type. Eventually all this garbage, mine and anyone else's, gets tossed into a validating parser. What comes out may come as a surprise to me. > >> The IESG is doing this through the role of protocol design engineer > >> review - recognizing functionality that oughta be in a protocol but > >> isn't. > > > >3375 is the requirements statement. > > Yeah, it is. Obviously, you mean something by saying that, but it is > not clear. See above. *-LC are not meaningless, and should not be "worked around". > >> But the only option available to users of the client is to decide > >> whether or not to make the registration. We want more of an option > >> than that. > > > >Please explain. > > We want the registrar to be able to say, here's the phone number but > don't send it anywhere. What is meant by 'anywhere' is policy > specific, hence outside the WG's concern. Are there any success or failure semantics? Is the transaction atomic and unitary, or is a partial write success? Is the new semantic capable of test by any in-protocol means? > >It is my sense that "privacy" is not simple. > > Then it's not privacy we are concerned about. It's about tagging > data with something called 'privacy.' How large is the policy value space? Taking the phone number example above, the value space appears to encode neatly into a single bit. If so, while I'm typing this I've found one solution to the "email" element qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal to pun the size type and signal directionality, into an octet. Violate some rule about octets in mail addrs, e.g., set a high bit in the domain name. If high-bit on, semantic one flag set and unset bit before store. If high-bit off, semantic one flag not set. mail="brunner@nic-naa.ne(eval((0x164+0x177)" Wierd. I guess the same could be done to the e164 type too. Of course, if the value space doesn't encode neatly into one bit, then this won't work, unless applied iteratively. Eric From owner-ietf-provreg@cafax.se Tue Mar 25 14:05:32 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 OAA25737 for ; Tue, 25 Mar 2003 14:05:30 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PIu0x9019989 for ; Tue, 25 Mar 2003 19:56:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PIu0KX019988 for ietf-provreg-outgoing; Tue, 25 Mar 2003 19:56:00 +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.8/8.12.8) with ESMTP id h2PItwx9019983 for ; Tue, 25 Mar 2003 19:55:59 +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 h2PItt34020498; Tue, 25 Mar 2003 13:55:56 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.66]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA13863; Tue, 25 Mar 2003 13:55:55 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303251821.h2PILeGL067674@nic-naa.net> References: <200303251821.h2PILeGL067674@nic-naa.net> Date: Tue, 25 Mar 2003 13:54:38 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 13:21 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote: >False. It is a requirement not in 3375. It is a new requirement, one that >modifies some functionality. Yup. The issue isn't whether something is new or not. The issue is whether it is a good idea. Recall that in the IETF process, an RFC is just that, a request for comments. I've stated in the past that there is never a deadline for getting it right - so long as we get it timely. We can "debate" forever on the merits of late requirements and concerns late in the game - but if you care about that, problem-statement seems to be the place. Let's focus on this problem statement and not worry about whether or not the process is a problem. >OK, so neither of us writing or grading english compositions. EPP "works" >as is (-02, -04, -06, ... for some value of "works"), and some new thing >is desired by someone in -0N, for some value of N. Fair enough. Basically, yeah. >We don't know it is a good idea, we do know that it is the IESG's idea. So, Okay, let's get over this. Forget who suggested it. Apparently you are not happy with requiring the protocol let the client include privacy meta-data to achieve the goal of allowing enforcement to happen at the server. Others have thought this is a good idea, mostly in the room and Scott so far as agreed that the statements in the room amounted to what I wrote. >when we say that Scott is the editor of documents under the change control >of the IETF, what we are really saying is that the actual change control is >held, not by the contributors, acting in concert, under 2026, et alia, to >create some specification, but by institutional authority figures other than >the I-D administrator, who may add/delete/modify the text, without undertaking >the corresponding action on the requirements doc, which has already had WGLC, >and IETF-LC. Once again - worry about this in problem-statement. I ain't about to debate the role of the document editor here - the topic is EPP, not the IETF. Scott is recording the consensus of the WG, along with much of the material he originally brought to the WG in 2000. (See the charter, it hasn't changed.) >If someone wants to modify 3375 and delete the manditory announcement clause, >let them. It is possibly deficient. > >If someone wants to modify 3375 and add a manditory enforcement clause, let >them. It is possibly sufficient. I don't think that there's much support for writing 3375bis at this time. Perhaps when a WG comes along to advance to Draft Standard it would be good to have a document that rolls in operationally derived experience, but it's way too premature to consider this now. >I'm "unhappy" about what I see as the technical difficulty of the proposal, >the inability of the authors of the proposal to make a technical case for a >mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and >the process to effect change control of the provreg work product. With the high bandwith of voice-over-soundwave (a cutsy name for face-to-face meetings) I think we were able to get deeper into the issue. >I wasn't thrilled with the congestion issue either, or the ordering issue, >but those are damp spots under prior bridges. I suppose you are referring in some way to the statement that we aren't pursuing SMTP or other transports over TCP (or other transports at all). One reason we are not pursuing them is that 1) no one has maintained a document on this for a prolonged period of time and 2) no second person has cared enough to present an interoperability-motivated reason for this to be brought into the group. I know you have had documents that discussed SMTP. My reading of them was that they were never fully developed enough to trigger me into personal action. As a WG chair, admittance of documents is based in part on a reason to use the WG's resources - i.e., the members. Without voluntary member motivation to review the documents, there's not a sufficient reason for the WG to expand its horizons. I.e., although our charter says we will investigate alternate transports - it doesn't mean we will develop an alternate transport. So far the result of the investigation is that there's been no popular support for other transports. >> >Question #1: If the client originated a as part of session >> >init, and the server responded with a , and the evalution >> >algorithm (tbd) was simple, e.g., equality, would that meet their >> >requirement? >> >> Initially, this might be, but as an outcome of the discussion in the >> meeting we felt that finer granularity was desirable and achievable. >> We talked about this as being a session-granular thing, but that was >> discarded. > >I thought so, which is why I asked. > >Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select) >is unrestricted, _this_isn't_what_the_iesg_wants_. You've lost me again here. >On the bright side, this means that all two-step discovery kludges of the >form Edmon proposed are as KIA as the . > >On the dim side, this seems to mean that the issue is syntax or religion, >as there's a heck of a lot of values less than BIGNUM (or a full DOM tree), >and a baroque richesse of choices when one is unrestricted. So semantics is >possibly _not_ the issue. > >> >> >In eppcom-1.0.xsd we have this: >> >> You're getting into an implementation detail. At this point, we are >> hashing out the problem statement. > >I could be wrong, but the authors of the document offering guidance on the >use of xml in IETF protocols may have failed to mention an edge case. > >If a type is inextensible, and is used to type a datum that cannot be >semantically conditioned by any means other than extension, for reasons >that are non-sytactic in nature, an "owie" occurs. I'm sure there is a >better form of expressing this than "owie". There may be a better form of saying "owie" but the cost-benefit of finding this seems to be discouraging to the group. (I.e., we've been running around just trying to figure out how to spell pirvayc at that point.) >The point of the implementation detail is that I think (I'd prefer to be >wrong) that we need to put a layer between the syntax of EPP extensions >to XML, and the basic types of XML, so that "policy" can be hidden in the >syntax, which I don't see a way to do with the "mail" element's "token" >type. > >Eventually all this garbage, mine and anyone else's, gets tossed into a >validating parser. What comes out may come as a surprise to me. Valid concern, but as I said before - implementation detail. >Are there any success or failure semantics? Is the transaction atomic and >unitary, or is a partial write success? It's all policy as far as we can tell. >Is the new semantic capable of test by any in-protocol means? Well, we want to be able to set, check, change and define the meaning of absence. >How large is the policy value space? > >Taking the phone number example above, the value space appears to encode >neatly into a single bit. > > >If so, while I'm typing this I've found one solution to the "email" element >qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal >to pun the size type and signal directionality, into an octet. Violate some >rule about octets in mail addrs, e.g., set a high bit in the domain name. >If high-bit on, semantic one flag set and unset bit before store. >If high-bit off, semantic one flag not set. > >mail="brunner@nic-naa.ne(eval((0x164+0x177)" > >Wierd. I guess the same could be done to the e164 type too. > >Of course, if the value space doesn't encode neatly into one bit, then >this won't work, unless applied iteratively. > >Eric Details, implementation details... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Tue Mar 25 16:40:38 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 QAA05086 for ; Tue, 25 Mar 2003 16:40:37 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PLZ0x9021764 for ; Tue, 25 Mar 2003 22:35:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PLZ0bK021763 for ietf-provreg-outgoing; Tue, 25 Mar 2003 22:35:00 +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.8/8.12.8) with ESMTP id h2PLYvx9021758 for ; Tue, 25 Mar 2003 22:34:58 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PLWdGL068436; Tue, 25 Mar 2003 16:32:39 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303252132.h2PLWdGL068436@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 13:54:38 EST." Date: Tue, 25 Mar 2003 16:32:39 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Let's get this bit out of the way. > >I wasn't thrilled with the congestion issue either, or the ordering issue, > >but those are damp spots under prior bridges. > > I suppose you are referring in some way to the statement that we > aren't pursuing SMTP or other transports over TCP (or other > transports at all). No. It isn't about what documents the WG pursues. Its about the way that session semantics crept in, and in a more exclusive form than any contributor to the WG reqested, either during the reqs period, or during the incremental deltas from -02 to -06. I wrote about this at length. Why does a stream of have to be strictly ordered? I don't know. It is worth a drink. Now this may not be what everyone, or even anyone, wants to do, but to discover in the ratrace of speculative gTLD operational art, some new _universal_ requirement that ordering must be preserved, even for some EPP-for-penguins deployment, is odd. Then there's the got-to-have-it-now problem, or why order preserving semantics aren't strong enough, they must be connectionist too. Bye bye email. Under the guiding light of the IESG we've gone from a protocol to a rather narrower operational market in the guise of a protocol. Believe me, I'm much happier with my drafts poking along dorkily to dorkimental. But these are edge cases. Transport thingies. Brunner's bad ideas. The issue before the WG today is the common syntax. Existance, or not. With that I'll go back to your note. Eric From owner-ietf-provreg@cafax.se Tue Mar 25 17:22:26 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 RAA06963 for ; Tue, 25 Mar 2003 17:22:24 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PMDkx9022153 for ; Tue, 25 Mar 2003 23:13:46 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PMDkUu022152 for ietf-provreg-outgoing; Tue, 25 Mar 2003 23:13: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.8/8.12.8) with ESMTP id h2PMDix9022147 for ; Tue, 25 Mar 2003 23:13:44 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PMBRGL068597; Tue, 25 Mar 2003 17:11:27 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303252211.h2PMBRGL068597@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 13:54:38 EST." Date: Tue, 25 Mar 2003 17:11:27 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Apparently you > are not happy with requiring the protocol let the client include > privacy meta-data to achieve the goal of allowing enforcement to > happen at the server. Actually, I don't even know what "enforcement" means. How is "enforcement" meaningfully defined in the protocol? If EPP allowed unconditional write-access to a centralized store, with only an auth-thingie to partition the store into N-registrar buckets, and allowed each writer to write the read-access (general, a la :43, or to any other registrar writer, or the blind registry store manager), then I'd have a clue what "enforcement" might mean. The registrar would hand a bitmask the size of a contact object to the registry, and could attempt to modify it without the auth-thingie, or read it back without the auth-thingie. Partial sight proved. > Apparently you > are not happy with requiring the protocol let the client include > privacy meta-data If only it were that simple. All I'm looking for is a way to distinguish one policied endpoint from another. What I'm not looking for is a way to change the policy on one policied endpoint, until it is indistinguishable from another. > Apparently you > are not happy with requiring the protocol let the client include > privacy meta-data But it isn't that simple, is it? If it were, then just sourcing the from the client, and sinking it at the server, would suffice. But that isn't it. Hey, we could go back to BNF, or whatever the people use who write the UI stuff for insurance companies, and add a little check box. For some reason, the extra bit(s) have to be just so. > >Are there any success or failure semantics? Is the transaction atomic and > >unitary, or is a partial write success? > > It's all policy as far as we can tell. No that is interesting. A functional requirement with no semantics. A mechanism with no discernable effect. Now that is worth the price of admission. > >Is the new semantic capable of test by any in-protocol means? > > Well, we want to be able to set, check, change and define the meaning > of absence. Sounds like an abstract, post-creat, access provisioning protocol, for shared, multi-reader repositories. Not the same as getting the data past creat, or mod, or ... Eric From owner-ietf-provreg@cafax.se Tue Mar 25 17:50:41 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 RAA08198 for ; Tue, 25 Mar 2003 17:50:40 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PMeox9022412 for ; Tue, 25 Mar 2003 23:40:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PMeoBV022410 for ietf-provreg-outgoing; Tue, 25 Mar 2003 23:40: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.8/8.12.8) with ESMTP id h2PMemx9022405 for ; Tue, 25 Mar 2003 23:40:48 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PMcVGL068724; Tue, 25 Mar 2003 17:38:31 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303252238.h2PMcVGL068724@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 13:54:38 EST." Date: Tue, 25 Mar 2003 17:38:31 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, I'm going to shut up and wait until Scott next delta's of the draft set. If there is no answer more ... whatever than what's been offered to my questions to Randy, well, that's life. Eric From owner-ietf-provreg@cafax.se Wed Mar 26 14:48: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 OAA09578 for ; Wed, 26 Mar 2003 14:48:10 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QJQtx9003582 for ; Wed, 26 Mar 2003 20:26:55 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QJQtVn003581 for ietf-provreg-outgoing; Wed, 26 Mar 2003 20:26:55 +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.8/8.12.8) with ESMTP id h2QJQsx9003575 for ; Wed, 26 Mar 2003 20:26:54 +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 h2QJQp34055489; Wed, 26 Mar 2003 14:26:51 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.47]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA08944; Wed, 26 Mar 2003 14:26:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303252132.h2PLWdGL068436@nic-naa.net> References: <200303252132.h2PLWdGL068436@nic-naa.net> Date: Wed, 26 Mar 2003 14:18:27 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Answering the side-bar message first: At 16:32 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote: >Ed, > >Let's get this bit out of the way. Speaking as a chair, Eric, I have to admit I am having trouble comprehending your angst here. Honestly, every time I begin to try to reply to some point you are raising, I get lost in thought and realize I've no answer. I don't want to discount a lone voice in the wilderness (as no one else is speaking out in the same way), but its that whatever is clueing you into your view is not apparent to me. Hence, I'm powerless to help. I want to avoid the appearance that EPP is perfect. (No one is running it operationally yet, so even if EPP is the most righteous protocol ever designed by mankind, there's no empirical evidence that it is perfect.) But it's also apparent that whatever flaws hiding in it are hidden so well not many of us see them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Wed Mar 26 14:51:58 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 OAA09694 for ; Wed, 26 Mar 2003 14:51:57 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QJQux9003589 for ; Wed, 26 Mar 2003 20:26:56 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QJQuAS003588 for ietf-provreg-outgoing; Wed, 26 Mar 2003 20:26:56 +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.8/8.12.8) with ESMTP id h2QJQsx9003576 for ; Wed, 26 Mar 2003 20:26:54 +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 h2QJQq34055495; Wed, 26 Mar 2003 14:26:52 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.47]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA08947; Wed, 26 Mar 2003 14:26:51 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303252211.h2PMBRGL068597@nic-naa.net> References: <200303252211.h2PMBRGL068597@nic-naa.net> Date: Wed, 26 Mar 2003 14:26:30 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 17:11 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote: >> Apparently you >> are not happy with requiring the protocol let the client include >> privacy meta-data to achieve the goal of allowing enforcement to >> happen at the server. > >Actually, I don't even know what "enforcement" means. > >How is "enforcement" meaningfully defined in the protocol? In this case, "makes a decision on whether to send some data in a message." We see the need to make decisions at either the registry or registrar. >> Apparently you >> are not happy with requiring the protocol let the client include >> privacy meta-data > >But it isn't that simple, is it? If it were, then just sourcing the >from the client, and sinking it at the server, would suffice. But that >isn't it. Part of the problem statement was that we wanted to piecemeal the privacy metadata to a finer scope. Do you think that that is a bad idea? >No that is interesting. A functional requirement with no semantics. >A mechanism with no discernable effect. Now that is worth the price of >admission. Yes, that is part of the role of being a proposed standard. We have to gain operational experience that may find that parts of the protocol are useless or a needed to be expanded - as well as the circumstances of the documents. I have heard rumors that in some business dealings swirling around the work done here, there is a need for a "standard." To some that's an RFC, to others PR, to others DS, and so yet some others Full Standard or even STD-n. As a chair, I can't deal with what others call a "standard" all I can deal with is what's in the process documents. > >> >Is the new semantic capable of test by any in-protocol means? >> >> Well, we want to be able to set, check, change and define the meaning >> of absence. > >Sounds like an abstract, post-creat, access provisioning protocol, for >shared, multi-reader repositories. > >Not the same as getting the data past creat, or mod, or ... Fortunately, this time I got lost at the end of the message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Wed Mar 26 16:34:56 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 QAA16104 for ; Wed, 26 Mar 2003 16:34:55 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QLOnx9004956 for ; Wed, 26 Mar 2003 22:24:49 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QLOn8W004955 for ietf-provreg-outgoing; Wed, 26 Mar 2003 22:24:49 +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.8/8.12.8) with ESMTP id h2QLOlx9004950 for ; Wed, 26 Mar 2003 22:24:48 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2QLMHGL073082; Wed, 26 Mar 2003 16:22:17 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303262122.h2QLMHGL073082@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Wed, 26 Mar 2003 14:18:27 EST." Date: Wed, 26 Mar 2003 16:22:17 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear Co-Chair of the PROVREG WG (and all around nice guy Ed Lewis), I have no angst. I am quite content that no working group, in particular, the PROVREG WG, has any interest in some drafts published as individual contributions. Just to be degenerate, which comes easily to me, and get to some core issues of ordering, reliability, and who is the author of requirements... EBW sez contains no fewer than zero, and possibly as many as one, maybe even three, instances of the operation "check" on the operand "bar", which might be ordered, and the temporal bounds on delivery are ... "best effort", or weaker. PAF sez contains exactly three, ordered instances of the operation "check" on the operand "bar", and the temporal bounds on delivery are ... "web time", an odd bit of transactional real-time. EBW sez for some things, it matters, for some things, it don't. PAF sez for all things, it matters equally. That disposes of epp/smtp, epp/udp, epp/http, epp/uucp, and of course epp/avian-transport (only a few days until that one, neh?). This is all done, my concern with the present question fits fairly neatly into two questions. I can wait till they're answered, or ... expire. Eric From owner-ietf-provreg@cafax.se Wed Mar 26 18:25:36 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 SAA22240 for ; Wed, 26 Mar 2003 18:25:34 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QNGJx9006016 for ; Thu, 27 Mar 2003 00:16:19 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QNGJCv006015 for ietf-provreg-outgoing; Thu, 27 Mar 2003 00:16:19 +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.8/8.12.8) with ESMTP id h2QNGFx9006010 for ; Thu, 27 Mar 2003 00:16:17 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2QNDfGL073448; Wed, 26 Mar 2003 18:13:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303262313.h2QNDfGL073448@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Wed, 26 Mar 2003 14:26:30 EST." Date: Wed, 26 Mar 2003 18:13:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > In this case, "makes a decision on whether to send some data in a > message." Which isn't the same thing as "makes a decision on whether to send any data in a message." Which is why I asked a Yes/No/Mumble question (partial write semantics), since between "none" and "all" lies "mumble". Eventually I suppose that "mumble" will take some greater detail. At least enough to make "mumble enforcement" sensible. Somewhere out there is a manditory to implement (but always optional to deploy) requirement that one end point or the other shave at least one bit (haircut optional for an additional two bits) off of some object. Which bit(s) is tbd, but some sort of mask is a given. I'd like to go on record as wanting the Mask of Zorro, er, Zero. > Part of the problem statement was that we wanted to piecemeal the > privacy metadata to a finer scope. Do you think that that is a bad > idea? I'm certain its a ... IESG idea ... to insist on the syntactic form of metadata, and insist that it be temporally scopeless, and insist that it is the terminal node in a directed acyclic graph (element attribute). Randy's an ex-compiler weenie, he knows what he's proposing. \begin{wicked_serious_mode} It depends on what one is attempting to design. If one is attempting to provision policy data (aka "metadata") in an SRS, and the SRS is not partitioned by metadata, and the data is uncorrolated w.r.t. metadata, then the metadata is sensibly encoded into the data. We did assume that there was correlation when we went for the session scoped , thinking that changes in would be infrequent, relative to the policied objects, that session encoding of the metadata was sensible, that the value-space of the was a lot smaller than the value-space of the object, and this design choice did not preclude client sourcing of , or negociation of , or .... Where the "finer is better" approach veers away from reality is in the assertion that no sensible aggregation of stuff is already well-defined in some relevant context. If 95/46/EC is a guide for anything that is remotely related to "privacy", we can expect to find in it an approval of "finer is better". I don't. What I do find is that deconstruction of the data is only part of the problem domain. Deconstruction of the purpose, recipients, temporal existance, originator write-through (aka "access"), and more define the problem domain, and that "fine structure" is less important than policing lumps, and relations between lumps, that when handled with the intent to construct or extract personally identifying information, can. I can live with "design" in the IETF social construct, with PS/DS/SS having a different frame of reference from "design" in the W2C social construct. I tried to "cross over" a gramatical framework, from the W3C to the IETF. It wasn't a success. No matter. I'm spending more time trying to prevent there being two or more core syntaxes than I will spend implementing those few I care about, so I'm way past my ROI, or my sell-by date. \end{wicked_serious_mode} > ... We have to gain operational experience ... With a mechanism with no discernable effect. OK. > I have heard rumors that in some business dealings swirling around > the work done here, there is a need for a "standard." To some that's > an RFC, to others PR, to others DS, and so yet some others Full > Standard or even STD-n. As a chair, I can't deal with what others > call a "standard" all I can deal with is what's in the process > documents. I'm happy with Dork-i-mental, and operational experience. I have very low tastes. Maybe none at all. Cheers, Eric From owner-ietf-provreg@cafax.se Thu Mar 27 22:25: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 WAA02737 for ; Thu, 27 Mar 2003 22:25:43 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2S3Awx9028137 for ; Fri, 28 Mar 2003 04:10:58 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2S3AwiL028136 for ietf-provreg-outgoing; Fri, 28 Mar 2003 04:10:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from localhost.domain (200-184-189-198.sofitel.com.br [200.184.189.198] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2S3Atx9028131 for ; Fri, 28 Mar 2003 04:10:57 +0100 (MET) Received: from eagle (unknown [192.168.1.102]) by localhost.domain (Postfix) with ESMTP id 7B7909E89; Thu, 27 Mar 2003 23:31:43 -0300 (BRT) Message-ID: <097501c2f4d7$a1464c40$1b00e494@afilias.com> From: "Ram Mohan" To: "Eric Brunner-Williams in Portland Maine" , "Edward Lewis" Cc: "Edward Lewis" , "Eric Brunner-Williams in Portland Maine" , , References: <200303252132.h2PLWdGL068436@nic-naa.net> Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Thu, 27 Mar 2003 22:10:17 -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 Ed, [snip] > I want to avoid the appearance that EPP is perfect. > No one is running it operationally yet Last time I checked, at least half a dozen registries are running EPP operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), .NL(?)plus a bunch more ccTLDs. > But it's also apparent that whatever flaws hiding in > it are hidden so well not many of us see them. Not sure the hypothesis is true; exposure of limitations has probably not happened - i know a few registry folks who have things they don't much care for in EPP, but haven't talked about it on the list. -ram From owner-ietf-provreg@cafax.se Fri Mar 28 04:40: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 EAA22272 for ; Fri, 28 Mar 2003 04:40:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2S9Swx9000880 for ; Fri, 28 Mar 2003 10:28:58 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2S9SwqX000879 for ietf-provreg-outgoing; Fri, 28 Mar 2003 10:28:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx01.gnr.com (mx01.gnr.com [193.109.220.157]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2S9Svx9000874 for ; Fri, 28 Mar 2003 10:28:57 +0100 (MET) Received: (qmail 25706 invoked by alias); 28 Mar 2003 09:28:55 -0000 Received: from unknown (HELO gnr-mailsweeper.gnr.com) (213.105.192.220) by muk-gnrmx-01.gnr.com with SMTP; 28 Mar 2003 09:28:55 -0000 Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Mar 2003 09:34:18 +0000 Received: from asbjorn.gnr.com ([192.168.3.23]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Mar 2003 09:23:43 +0000 Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" From: Asbjorn Mikkelsen To: Ram Mohan Cc: ietf-provreg@cafax.se In-Reply-To: <097501c2f4d7$a1464c40$1b00e494@afilias.com> References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> Content-Type: text/plain Message-Id: <1048843384.2732.19.camel@bubba> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 28 Mar 2003 09:23:04 +0000 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2003 09:23:43.0706 (UTC) FILETIME=[BA31B3A0:01C2F50B] Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > Last time I checked, at least half a dozen registries are running EPP > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > .NL(?)plus a bunch more ccTLDs. ...and .NAME(05)... Asbjorn -- Asbjorn Steira Senior Developer The Global Name Registry, Limited Tel: +44 (0) 207 025 2214 Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company. This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties. ***************** What's your .name? Get one at www.name ***************** From owner-ietf-provreg@cafax.se Fri Mar 28 08:58: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 IAA28790 for ; Fri, 28 Mar 2003 08:58:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SDjUx9002659 for ; Fri, 28 Mar 2003 14:45:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SDjUd9002658 for ietf-provreg-outgoing; Fri, 28 Mar 2003 14:45:30 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2SDjSx9002653 for ; Fri, 28 Mar 2003 14:45:29 +0100 (MET) Message-ID: <00c001c2f530$367185c0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> Subject: [ietf-provreg] privacy profile for domain mapping Date: Fri, 28 Mar 2003 08:44:51 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit At the SF meeting we discussed adding privacy profile for contact mapping, but I think it is important to also add it to domain mapping as well, in fact, I think being able to handle a per domain profile model is even more important because the same contact may be the admin contact as well as say the tech contact and the disclosure requirements may also be different within the same domain. Moreover, one contact may be associated with multiple domains, and each domain may have different preference. (e.g. a domain registered in EU and a domain registered in US with the same contact might have to/want to disclose/hide different info) Anyway, here are four ways I have thought of to add the privacy elements for domain mapping: (p=0: ok to disclose, p=1: privacy preserved) (1) adding an optional block: ... sh8013 sh8013 ... (2) changing element to include privacy profile for each contact/registrant ... jd1234 sh8013 sh8013 ... (3) including everything as attributes in the element ... jd1234 sh8013 sh8013 ... (4) combination of 2 & 3 (postalInfo has a further child element while others are grouped as attributes) ... jd1234 sh8013 sh8013 There could also be a (5)th apporach that is to combine 1 & 4 for a smaller block. Thoughts? Edmon From owner-ietf-provreg@cafax.se Fri Mar 28 08:59: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 IAA28824 for ; Fri, 28 Mar 2003 08:59:15 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SDn2x9002704 for ; Fri, 28 Mar 2003 14:49:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SDn2nA002703 for ietf-provreg-outgoing; Fri, 28 Mar 2003 14:49:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2SDn0x9002698 for ; Fri, 28 Mar 2003 14:49:01 +0100 (MET) Message-ID: <00da01c2f530$b178bb30$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Asbjorn Mikkelsen" , "Ram Mohan" Cc: References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> <1048843384.2732.19.camel@bubba> Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Fri, 28 Mar 2003 08:48:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > > Last time I checked, at least half a dozen registries are running EPP > > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > .NL(?)plus a bunch more ccTLDs. > > ...and .NAME(05)... > ...and .SG(04) and soon to be .BZ(04 or 07) Edmon From owner-ietf-provreg@cafax.se Fri Mar 28 10:00:29 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 KAA01232 for ; Fri, 28 Mar 2003 10:00:28 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SEn5x9003457 for ; Fri, 28 Mar 2003 15:49:05 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SEn5CB003456 for ietf-provreg-outgoing; Fri, 28 Mar 2003 15:49:05 +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.8/8.12.8) with ESMTP id h2SEn3x9003451 for ; Fri, 28 Mar 2003 15:49:04 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2SEk7GL084090; Fri, 28 Mar 2003 09:46:07 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303281446.h2SEk7GL084090@nic-naa.net> To: "Edmon Chung" cc: "Asbjorn Mikkelsen" , "Ram Mohan" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Fri, 28 Mar 2003 08:48:17 EST." <00da01c2f530$b178bb30$0f01a8c0@neteka.inc> Date: Fri, 28 Mar 2003 09:46:07 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > ...and .SG(04) and soon to be .BZ(04 or 07) congrats edmon!!! i'd thought that .bz was a vgrs property. whether you've moved on to the high-table at vgrs, or swung a spin-out deal, i'm impressed. From owner-ietf-provreg@cafax.se Fri Mar 28 11:02:37 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 LAA05086 for ; Fri, 28 Mar 2003 11:02:35 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SFpWx9004101 for ; Fri, 28 Mar 2003 16:51:32 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SFpWY2004100 for ietf-provreg-outgoing; Fri, 28 Mar 2003 16:51:32 +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.8/8.12.8) with ESMTP id h2SFpUx9004095 for ; Fri, 28 Mar 2003 16:51:31 +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 18yw8f-0004h8-00; Fri, 28 Mar 2003 10:51:29 -0500 Message-ID: <3E846F82.2A75EF14@libertyrms.info> Date: Fri, 28 Mar 2003 10:51:30 -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: Edmon Chung CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] privacy profile for domain mapping References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> <00c001c2f530$367185c0$0f01a8c0@neteka.inc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit I see a general problem with all the proposed variants. They break modular architecture of EPP protocol. With the current structure of the protocol there is not much assumed in domain object mapping about contact object mapping and other object mappings. All the proposed variants make domain object mapping depended on contact object mapping. I see also practical problems with the proposals. It is possible to set address, email privacy element/attribute to true in block. Meanwhile the owner of the contact object (which does not have to be the same as domain object) may set privacy element/attribute to false for address and email elements. That will lead to a situation when the domain owner assumes his privacy is protected and at the same time it is not. Someone can use whois to query the contact object to see address and email. Janusz Sienkiewicz Edmon Chung wrote: > At the SF meeting we discussed adding privacy profile for contact mapping, > but I think it is important to also add it to domain mapping as well, in > fact, I think being able to handle a per domain profile model is even more > important because the same contact may be the admin contact as well as say > the tech contact and the disclosure requirements may also be different > within the same domain. > > Moreover, one contact may be associated with multiple domains, and each > domain may have different preference. (e.g. a domain registered in EU and a > domain registered in US with the same contact might have to/want to > disclose/hide different info) > > Anyway, here are four ways I have thought of to add the privacy elements for > domain mapping: > (p=0: ok to disclose, p=1: privacy preserved) > > (1) adding an optional block: > > ... > > > > > > > > sh8013 > > > > > > sh8013 > > > > > ... > > (2) changing element to include privacy profile for each > contact/registrant > > ... > > jd1234 > > > > > > sh8013 > > > > > > sh8013 > > > > ... > > (3) including everything as attributes in the > element > > ... > jd1234 > sh8013 > sh8013 > ... > > (4) combination of 2 & 3 (postalInfo has a further child element while > others are grouped as attributes) > > ... > > jd1234 > > > > > > > sh8013 > > > > > > sh8013 > > > > There could also be a (5)th apporach that is to combine 1 & 4 for a smaller > block. > Thoughts? > > Edmon From owner-ietf-provreg@cafax.se Fri Mar 28 11:29:36 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 LAA06107 for ; Fri, 28 Mar 2003 11:29:35 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGIvx9004338 for ; Fri, 28 Mar 2003 17:18:57 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SGIuZq004337 for ietf-provreg-outgoing; Fri, 28 Mar 2003 17:18:56 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2SGIsx9004327 for ; Fri, 28 Mar 2003 17:18:55 +0100 (MET) Message-ID: <016501c2f545$a6bbcfb0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "janusz sienkiewicz" Cc: References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> <00c001c2f530$367185c0$0f01a8c0@neteka.inc> <3E846F82.2A75EF14@libertyrms.info> Subject: Re: [ietf-provreg] privacy profile for domain mapping Date: Fri, 28 Mar 2003 11:18:20 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit That is quite true. There could be potential conflicts. We need statements that says the registry privacy policy will prevail, next the contact privacy preference will prevail and then domain preference is taken into consideration (which is what happens in our implementation for SG). i.e. If the registry policy is that Addr MUST be displayed for the domain, then even if the contact says dnd it can be disclosed (OR the policy can say that the upate/creation must fail) If the contact privacy preference say for email is dnd while the domain profile says ok for disclosure (AND that the Registry policy allows an opt-out of the info) then the email must NOT be disclosed (OR the policy can say that the update/creation must fail) OR a registry MUST choose to do privacy for domain mapping or contact mapping only and that they are mutually exclusive. In terms of dependence on contact mapping, that is not necessarily the case. If the privacy elements in domain mapping does NOT exist in the contact mapping, then the policy may say that the field is either ignored, or that the transaction should fail. Edmon ----- Original Message ----- From: "janusz sienkiewicz" To: "Edmon Chung" Cc: Sent: Friday, March 28, 2003 10:51 AM Subject: Re: [ietf-provreg] privacy profile for domain mapping > I see a general problem with all the proposed variants. They break modular > architecture of EPP protocol. With the current structure of the protocol there > is not much assumed in domain object mapping about contact object mapping and > other object mappings. All the proposed variants make domain object mapping > depended on contact object mapping. > > I see also practical problems with the proposals. It is possible to set > address, email privacy element/attribute to true in block. > Meanwhile the owner of the contact object (which does not have to be the same > as domain object) may set privacy element/attribute to false for address and > email elements. That will lead to a situation when the domain owner assumes his > privacy is protected and at the same time it is not. Someone can use whois to > query the contact object to see address and email. > > Janusz Sienkiewicz > > Edmon Chung wrote: > > > At the SF meeting we discussed adding privacy profile for contact mapping, > > but I think it is important to also add it to domain mapping as well, in > > fact, I think being able to handle a per domain profile model is even more > > important because the same contact may be the admin contact as well as say > > the tech contact and the disclosure requirements may also be different > > within the same domain. > > > > Moreover, one contact may be associated with multiple domains, and each > > domain may have different preference. (e.g. a domain registered in EU and a > > domain registered in US with the same contact might have to/want to > > disclose/hide different info) > > > > Anyway, here are four ways I have thought of to add the privacy elements for > > domain mapping: > > (p=0: ok to disclose, p=1: privacy preserved) > > > > (1) adding an optional block: > > > > ... > > > > > > > > > > > > > > > > sh8013 > > > > > > > > > > > > sh8013 > > > > > > > > > > ... > > > > (2) changing element to include privacy profile for each > > contact/registrant > > > > ... > > > > jd1234 > > > > > > > > > > > > sh8013 > > > > > > > > > > > > sh8013 > > > > > > > > ... > > > > (3) including everything as attributes in the > > element > > > > ... > > jd1234 > > sh8013 > > sh8013 > > ... > > > > (4) combination of 2 & 3 (postalInfo has a further child element while > > others are grouped as attributes) > > > > ... > > > > jd1234 > > > > > > > > > > > > > > sh8013 > > > > > > > > > > > > sh8013 > > > > > > > > There could also be a (5)th apporach that is to combine 1 & 4 for a smaller > > block. > > Thoughts? > > > > Edmon > > From owner-ietf-provreg@cafax.se Fri Mar 28 12:09:39 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 MAA08331 for ; Fri, 28 Mar 2003 12:09:38 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxPx9005006 for ; Fri, 28 Mar 2003 17:59:25 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SGxPVE005004 for ietf-provreg-outgoing; Fri, 28 Mar 2003 17:59:25 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxIx9004985 for ; Fri, 28 Mar 2003 17:59:23 +0100 (MET) Received: from [192.149.252.108] ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA04342; Fri, 28 Mar 2003 11:59:17 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: Date: Fri, 28 Mar 2003 11:59:11 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] the privacy problem statement Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Given that we've had a week to discuss the 'problem' and nothing seems to have risen up to change it (EBW's comments notwithstanding), I think it's safe to assume that the problem is as stated. IOW - Let's start looking at the solution. 'Course, it's never to complain about the problem statement. I just want to throw open the doors on proposed answers... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Fri Mar 28 12:09: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 MAA08330 for ; Fri, 28 Mar 2003 12:09:38 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxPx9005005 for ; Fri, 28 Mar 2003 17:59:25 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SGxOam005003 for ietf-provreg-outgoing; Fri, 28 Mar 2003 17:59:24 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxHx9004984 for ; Fri, 28 Mar 2003 17:59:18 +0100 (MET) Received: from [192.149.252.108] ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA04338 for ; Fri, 28 Mar 2003 11:59:16 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337088B@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337088B@vsvapostal3.prod.netsol.com> Date: Fri, 28 Mar 2003 11:57:19 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: RE: [ietf-provreg] References for Today's Host Object Discussion Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Speaking in a co-chair capacity, I think that it is fair to reopen the issue. Jaap and I are aware of a significant number of silent speakers that really want to be host-object free. Answering to the charge that these documents sailed through last call without comment on this topic (albeit a topic discussed on the list), EPP has been generating wider interest as it progresses. There's always the trade-off of delay and feature adding, and mission creep versus focus. There is no clear rule that applies to each situation, so the question: Should EPP define a host-object-less model now? is one that can't be answered categorically (the "now" thing). But I think that it seems worthwhile to do so now - while we are also preparing to answer the privacy issue. Unless I am missing something, Scott, can you propose some text that would accommodate nameservers-as-attributes? Based on: >- Allowing a choice between name server host objects and name server domain >attributes. > http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html Joe offered to help..."I would be happy to contribute text if this sounds like a reasonable approach." At 18:01 -0500 3/24/03, Hollenbeck, Scott wrote: >I'm not one of the people responsible for determining consensus, but I can >say that the domain document has completed both WG and IETF last calls with >the currently specified feature set. Our chairs can, of course, direct me >to change something if WG consensus is to make a change. I'd prefer to keep >things as-is, though, because this is _not_ a new argument and we'll have a >chance to address this again when considering what to do when going from >proposed to draft. > >One of the things I intend to do once we're there is capture the outstanding >issues in an I-D that can be used to seed the proposed-to-draft discussion. >It would be helpful if people who have issues with any current features >could send me a note (off-list is OK) describing what they don't like _and_ >a suggested solution. We might then have the start of a pretty good problem >statement for EPP 1.1 or 2.0. > >-Scott- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. From owner-ietf-provreg@cafax.se Fri Mar 28 16:50:38 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 QAA20842 for ; Fri, 28 Mar 2003 16:50:36 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SLdux9008311 for ; Fri, 28 Mar 2003 22:39:56 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SLdu5U008310 for ietf-provreg-outgoing; Fri, 28 Mar 2003 22:39:56 +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.8/8.12.8) with ESMTP id h2SLdqx9008305 for ; Fri, 28 Mar 2003 22:39:54 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2SLasGL085733 for ; Fri, 28 Mar 2003 16:36:55 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303282136.h2SLasGL085733@nic-naa.net> To: ietf-provreg@cafax.se Subject: [ietf-provreg] Fd: Re: BH: Introducing the Beyond HTTP (BH) Task Force Date: Fri, 28 Mar 2003 16:36:54 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Anyone want this? I prefer not to "laze" (or however that is spelt), since I do such a bad job of contributing. I've re-arrainged the p3p mail to put my-take-on-epp (tm) first, for this list's benefit. ------- Forwarded Message > List-Id: > > On Friday 21 March 2003 05:48, Eric Brunner-Williams in Portland Maine > wrote: > > Here are a couple of things where I've attempted to take policies that > > are { similar to | derived from | stolen and wrecked | ... } P3P's and > > make mechanisms other than some set of HTTP methods transport apply. > > Thanks Eric ... > > I've briefly looked into each of of the apps below > looking for salient requirements and/or features of a scenario that might > be relevant. Please correct me if you think I've missed something. [this isn't the first item] > > 3. PROVREG WG, an IETF WG (current). The problem domain defined > > by Verisign's RRP protocol, using EBNF as the formal syntax, > > is slightly restated in EPP, using XML as the formal syntax. > > I'm unfamiliar with this work but I've poked about on: > http://www.ietf.org/html.charters/provreg-charter.html > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt > and see they have a : > """ - A (data collection policy) element that contains child > elements used to describe the server's privacy policy for data > collection and management.""" > with an {access, purpose, retention}, elements based on P3P. Since this is > active work, I think it makes sense to ask them why don't they use the > elements from P3P itself? And if there are reasons, we'd appreciate the > feedback. Do you have connections with this work, could you help start that > conversation? [ this is where the first item begins] > > 1. CPExchange, a customer profile exchange application-layer > > protocol, with no transport binding. The DTD for this and > > the pre-bubble bumpf are still available at > > http://www.cpexchange.org/ > > This appears to be an extension of the P3P privacy vocabulary with a more > extensive XML data profile based on XML Schema data types. It appears they > have the significant portion with {Access, Purpose, Retention, Recipient}. > Because it's based on a 2000 snapshot of P3P I can't discern any particular > divergence in the privacy vocabulary because of this app's context. I can > conclude that they felt there was a need for more extensive and XML Schema > typed data structures that would perhaps be of interest to the P3P Schema > taskforce. > > > 2. HTTP WG, an IETF WG (concluded). During the last year of the > > WG, Dan Jaye contributed a draft that extended the Kristol, > > Montulli draft on the state management mechanism, RFC 2965. > > This draft has expired, but I have it (co-author). The IESG > > published a note written by Moore and Freed (RFC 2964), on > > the problem domain, observing that some uses of the mechanism > > were harmful, and depricated policied cookies. > > I followed this work back in the day and my conclusion would be that there > was a requirement for terse expression. This appears to be satisfied with > compact policies and I would expect other apps with a similar requirement > to use them, or perhaps in the future a binary-XML representation of the > complete markup...? I've included this in > http://www.w3.org/P3P/2003/04-beyond-http#sec-Others > [part #3 delted here, moved up] > ------- End of Forwarded Message From owner-ietf-provreg@cafax.se Sat Mar 29 13:43: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 NAA26998 for ; Sat, 29 Mar 2003 13:43:42 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2TIW1x9015509 for ; Sat, 29 Mar 2003 19:32:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2TIW1lD015508 for ietf-provreg-outgoing; Sat, 29 Mar 2003 19:32:01 +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.8/8.12.8) with ESMTP id h2TIW0x9015503 for ; Sat, 29 Mar 2003 19:32:00 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2TIVxT1096405 for ; Sat, 29 Mar 2003 19:31:59 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2TIVxPZ096404 for ietf-provreg@cafax.se; Sat, 29 Mar 2003 19:31:59 +0100 (CET) Received: from ns1.ascio.com (ns1.ascio.com [213.237.145.77]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SECax9003008 for ; Fri, 28 Mar 2003 15:12:37 +0100 (MET) Received: from aries.dk.speednames.com (aries.dk.speednames.com [213.237.145.56]) by ns1.ascio.com (8.12.8/8.12.5) with ESMTP id h2SEDIAB002815 for ; Fri, 28 Mar 2003 14:13:18 GMT Received: by aries.dk.speednames.com with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Mar 2003 15:12:36 +0100 Message-ID: <2F15A97500CFA0469C9BACC2041F8AC702A0BE3F@aries.dk.speednames.com> From: Claus Dahl To: "'ietf-provreg@cafax.se'" Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Fri, 28 Mar 2003 15:12:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="UTF-8" Sender: owner-ietf-provreg@cafax.se Precedence: bulk .SG is EPP by name only - it does not conform to the specs at all. Claus -----Original Message----- From: Edmon Chung [mailto:edmon@neteka.com] Sent: 28. marts 2003 14:48 To: Asbjorn Mikkelsen; Ram Mohan Cc: ietf-provreg@cafax.se Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" > On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > > Last time I checked, at least half a dozen registries are running EPP > > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > .NL(?)plus a bunch more ccTLDs. > > ...and .NAME(05)... > ..and .SG(04) and soon to be .BZ(04 or 07) Edmon From owner-ietf-provreg@cafax.se Sat Mar 29 13:43: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 NAA26997 for ; Sat, 29 Mar 2003 13:43:42 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2TIVox9015501 for ; Sat, 29 Mar 2003 19:31:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2TIVnEl015500 for ietf-provreg-outgoing; Sat, 29 Mar 2003 19:31:49 +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.8/8.12.8) with ESMTP id h2TIVkx9015495 for ; Sat, 29 Mar 2003 19:31:46 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2TIVjT1096396 for ; Sat, 29 Mar 2003 19:31:45 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2TIVjnB096395 for ietf-provreg@cafax.se; Sat, 29 Mar 2003 19:31:45 +0100 (CET) Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SE9xx9002972 for ; Fri, 28 Mar 2003 15:09:59 +0100 (MET) Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Mar 2003 14:09:59 -0000 Message-ID: From: Antony Perkov To: ietf-provreg@cafax.se Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Fri, 28 Mar 2003 14:09:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > Last time I checked, at least half a dozen registries are > > > running EPP operationally. > > > .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > > .NL(?)plus a bunch more ccTLDs. > > > > ...and .NAME(05)... > > > ...and .SG(04) and soon to be .BZ(04 or 07) and .COOP(06) From owner-ietf-provreg@cafax.se Mon Mar 31 01:10: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 BAA14829 for ; Mon, 31 Mar 2003 01:10:12 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2V5usx9027642 for ; Mon, 31 Mar 2003 07:56:54 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2V5usBh027641 for ietf-provreg-outgoing; Mon, 31 Mar 2003 07:56:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2V5uqx9027636 for ; Mon, 31 Mar 2003 07:56:53 +0200 (MEST) Message-ID: <005801c2f748$da43af10$8e7a4b0a@neteka.inc> From: "Edmon Chung" To: "Claus Dahl" , References: <2F15A97500CFA0469C9BACC2041F8AC702A0BE3F@aries.dk.speednames.com> Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Mon, 31 Mar 2003 00:46:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit It will be soon after the RFCs are published. SG Registrars, including ascio will also get a new API (which should function the same). :-) Edmon ----- Original Message ----- From: "Claus Dahl" To: Sent: Friday, March 28, 2003 9:12 AM Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue" > .SG is EPP by name only - it does not conform to the specs at all. > > Claus > > -----Original Message----- > From: Edmon Chung [mailto:edmon@neteka.com] > Sent: 28. marts 2003 14:48 > To: Asbjorn Mikkelsen; Ram Mohan > Cc: ietf-provreg@cafax.se > Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" > > > > On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > > > Last time I checked, at least half a dozen registries are running EPP > > > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > > .NL(?)plus a bunch more ccTLDs. > > > > ...and .NAME(05)... > > > ..and .SG(04) and soon to be .BZ(04 or 07) > > Edmon > > From owner-ietf-provreg@cafax.se Mon Mar 31 08:34: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 IAA05956 for ; Mon, 31 Mar 2003 08:34:15 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDNDRN006103 for ; Mon, 31 Mar 2003 15:23:13 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VDND1X006102 for ietf-provreg-outgoing; Mon, 31 Mar 2003 15:23:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDNCRN006097 for ; Mon, 31 Mar 2003 15:23:12 +0200 (MEST) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h2VDMW2P029289; Mon, 31 Mar 2003 08:22:32 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2AQTB4F2>; Mon, 31 Mar 2003 08:17:27 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033708BE@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] References for Today's Host Object Discussion Date: Mon, 31 Mar 2003 08:17:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Unless I am missing something, Scott, can you propose some text that > would accommodate nameservers-as-attributes? Based on: > > >- Allowing a choice between name server host objects and > name server domain > >attributes. > > http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html Sure. Here's what I have in mind: This is the structure currently used in the domain mapping to specify name server host objects: This can be changed to be a choice of either host objects or host attributes, like this: I'd then have to add text to explain how this works in the descriptions of the and commands, but that text would be pretty straightforward. Note that this structure allows one to use either host objects as name servers or host attributes as name servers, but it doesn't allow mixing of the two on a domain object. I remember there being some opposition to the idea of mixing the modes back when this was originally discussed on the list, so I've elected to not allow it here. The benefit to this is that it allows client and server to specify name servers without using host objects if they so desire. A server operator would be free to implement a policy that requires host objects if they're supported, or to not support host objects at all. I might have to replicate all of the host address elements in the domain mapping to completely eliminate the dependency on the host mapping (note that the elements above require an import of the host schema to obtain the address data type). Consider what you see above as a proposal that might need to be modified once I start testing it a bit. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 31 08:43:26 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 IAA06140 for ; Mon, 31 Mar 2003 08:43:25 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDXZRN006198 for ; Mon, 31 Mar 2003 15:33:35 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VDXYkJ006197 for ietf-provreg-outgoing; Mon, 31 Mar 2003 15:33:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDXXRN006192 for ; Mon, 31 Mar 2003 15:33:33 +0200 (MEST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h2VDWs2P029610; Mon, 31 Mar 2003 08:32:54 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2AQR8SR7>; Mon, 31 Mar 2003 08:27:49 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033708BF@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Subject: RE: [ietf-provreg] the privacy problem statement Date: Mon, 31 Mar 2003 08:27:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Given that we've had a week to discuss the 'problem' and nothing > seems to have risen up to change it (EBW's comments notwithstanding), > I think it's safe to assume that the problem is as stated. > > IOW - Let's start looking at the solution. > > 'Course, it's never to complain about the problem statement. I just > want to throw open the doors on proposed answers... I'd like to propose a solution first described on the mailing list in December: http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html With a slight modification as proposed by Janusz: http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html The element structure could look like this: The above means that the email address and voice telephone numbers should not be disclosed (I've modified Janusz' proposal slightly to use a boolean value for the flag instead of a yes/no enumeration to simply the schema a bit). Server policy would determine the default value for disclosure if the element is not provided. If I remember correctly the feeling of the room in San Francisco was that this could be limited to the contact mapping. -Scott- From owner-ietf-provreg@cafax.se Mon Mar 31 10:30:38 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 KAA11283 for ; Mon, 31 Mar 2003 10:30:37 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VFBERN007412 for ; Mon, 31 Mar 2003 17:11:14 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VFBEEC007411 for ietf-provreg-outgoing; Mon, 31 Mar 2003 17:11:14 +0200 (MEST) 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.9/8.12.9) with ESMTP id h2VFBCRN007406 for ; Mon, 31 Mar 2003 17:11:13 +0200 (MEST) 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 1900wC-00056Q-00; Mon, 31 Mar 2003 10:11:04 -0500 Message-ID: <3E885A89.E0F85FA0@libertyrms.info> Date: Mon, 31 Mar 2003 10:11: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: Ram Mohan CC: ietf-provreg@cafax.se Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Ram Mohan wrote: > Ed, > [snip] > > I want to avoid the appearance that EPP is perfect. > > No one is running it operationally yet > > Last time I checked, at least half a dozen registries are running EPP > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > .NL(?)plus a bunch more ccTLDs. I don't know whether .PL is running EPP operationally but at least there is (07) implementation presented at RIPE-44. > > > > But it's also apparent that whatever flaws hiding in > > it are hidden so well not many of us see them. > > Not sure the hypothesis is true; exposure of limitations has probably not > happened - i know a few registry folks who have things they don't much care > for in EPP, but haven't talked about it on the list. > > -ram Janusz From owner-ietf-provreg@cafax.se Mon Mar 31 18:21:55 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 SAA02049 for ; Mon, 31 Mar 2003 18:21:54 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VN6wRN012254 for ; Tue, 1 Apr 2003 01:06:58 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VN6wZr012253 for ietf-provreg-outgoing; Tue, 1 Apr 2003 01:06:58 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from garlic.apnic.net (garlic.apnic.net [202.12.29.224]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VN6tRN012248 for ; Tue, 1 Apr 2003 01:06:56 +0200 (MEST) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h2VN4CHd000981; Tue, 1 Apr 2003 09:04:12 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h2VN49eL000427; Tue, 1 Apr 2003 09:04:09 +1000 (EST) Date: Tue, 1 Apr 2003 09:04:09 +1000 From: George Michaelson To: "Hollenbeck, Scott" Cc: "'Edward Lewis'" , ietf-provreg@cafax.se Subject: Re: [ietf-provreg] the privacy problem statement Message-Id: <20030401090409.026006d0.ggm@apnic.net> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD6033708BF@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD6033708BF@vsvapostal3.prod.netsol.com> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.8.10claws101 (GTK+ 1.2.10; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > I'd like to propose a solution first described on the mailing list in > December: > > http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html > > With a slight modification as proposed by Janusz: > > http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html > > The element structure could look like this: > > > > > > > The above means that the email address and voice telephone numbers should > not be disclosed (I've modified Janusz' proposal slightly to use a boolean > value for the flag instead of a yes/no enumeration to simply the schema a > bit). Server policy would determine the default value for disclosure if the > element is not provided. I think this does capture the feeling of the room thus far. The side issues are this can be set differently for different instances of contact data within one object. this can be set differrently for different objects in one stream of objects > > If I remember correctly the feeling of the room in San Francisco was that > this could be limited to the contact mapping. No. I'm less sure we agreed on that. The words I kept hearing were 'social data' but It wasn't explicit that was limited to contact mapping. It might be my misunderstanding of what 'social data' and 'contact mapping' are in this context. cheers -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VFBERN007412 for ; Mon, 31 Mar 2003 17:11:14 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VFBEEC007411 for ietf-provreg-outgoing; Mon, 31 Mar 2003 17:11:14 +0200 (MEST) 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.9/8.12.9) with ESMTP id h2VFBCRN007406 for ; Mon, 31 Mar 2003 17:11:13 +0200 (MEST) 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 1900wC-00056Q-00; Mon, 31 Mar 2003 10:11:04 -0500 Message-ID: <3E885A89.E0F85FA0@libertyrms.info> Date: Mon, 31 Mar 2003 10:11: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: Ram Mohan CC: ietf-provreg@cafax.se Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ram Mohan wrote: > Ed, > [snip] > > I want to avoid the appearance that EPP is perfect. > > No one is running it operationally yet > > Last time I checked, at least half a dozen registries are running EPP > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > .NL(?)plus a bunch more ccTLDs. I don't know whether .PL is running EPP operationally but at least there is (07) implementation presented at RIPE-44. > > > > But it's also apparent that whatever flaws hiding in > > it are hidden so well not many of us see them. > > Not sure the hypothesis is true; exposure of limitations has probably not > happened - i know a few registry folks who have things they don't much care > for in EPP, but haven't talked about it on the list. > > -ram Janusz Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDXZRN006198 for ; Mon, 31 Mar 2003 15:33:35 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VDXYkJ006197 for ietf-provreg-outgoing; Mon, 31 Mar 2003 15:33:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDXXRN006192 for ; Mon, 31 Mar 2003 15:33:33 +0200 (MEST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h2VDWs2P029610; Mon, 31 Mar 2003 08:32:54 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2AQR8SR7>; Mon, 31 Mar 2003 08:27:49 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033708BF@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Subject: RE: [ietf-provreg] the privacy problem statement Date: Mon, 31 Mar 2003 08:27:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Given that we've had a week to discuss the 'problem' and nothing > seems to have risen up to change it (EBW's comments notwithstanding), > I think it's safe to assume that the problem is as stated. > > IOW - Let's start looking at the solution. > > 'Course, it's never to complain about the problem statement. I just > want to throw open the doors on proposed answers... I'd like to propose a solution first described on the mailing list in December: http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html With a slight modification as proposed by Janusz: http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html The element structure could look like this: The above means that the email address and voice telephone numbers should not be disclosed (I've modified Janusz' proposal slightly to use a boolean value for the flag instead of a yes/no enumeration to simply the schema a bit). Server policy would determine the default value for disclosure if the element is not provided. If I remember correctly the feeling of the room in San Francisco was that this could be limited to the contact mapping. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDNDRN006103 for ; Mon, 31 Mar 2003 15:23:13 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VDND1X006102 for ietf-provreg-outgoing; Mon, 31 Mar 2003 15:23:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VDNCRN006097 for ; Mon, 31 Mar 2003 15:23:12 +0200 (MEST) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h2VDMW2P029289; Mon, 31 Mar 2003 08:22:32 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2AQTB4F2>; Mon, 31 Mar 2003 08:17:27 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033708BE@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] References for Today's Host Object Discussion Date: Mon, 31 Mar 2003 08:17:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Unless I am missing something, Scott, can you propose some text that > would accommodate nameservers-as-attributes? Based on: > > >- Allowing a choice between name server host objects and > name server domain > >attributes. > > http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html Sure. Here's what I have in mind: This is the structure currently used in the domain mapping to specify name server host objects: This can be changed to be a choice of either host objects or host attributes, like this: I'd then have to add text to explain how this works in the descriptions of the and commands, but that text would be pretty straightforward. Note that this structure allows one to use either host objects as name servers or host attributes as name servers, but it doesn't allow mixing of the two on a domain object. I remember there being some opposition to the idea of mixing the modes back when this was originally discussed on the list, so I've elected to not allow it here. The benefit to this is that it allows client and server to specify name servers without using host objects if they so desire. A server operator would be free to implement a policy that requires host objects if they're supported, or to not support host objects at all. I might have to replicate all of the host address elements in the domain mapping to completely eliminate the dependency on the host mapping (note that the elements above require an import of the host schema to obtain the address data type). Consider what you see above as a proposal that might need to be modified once I start testing it a bit. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2V5usx9027642 for ; Mon, 31 Mar 2003 07:56:54 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2V5usBh027641 for ietf-provreg-outgoing; Mon, 31 Mar 2003 07:56:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2V5uqx9027636 for ; Mon, 31 Mar 2003 07:56:53 +0200 (MEST) Message-ID: <005801c2f748$da43af10$8e7a4b0a@neteka.inc> From: "Edmon Chung" To: "Claus Dahl" , References: <2F15A97500CFA0469C9BACC2041F8AC702A0BE3F@aries.dk.speednames.com> Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Mon, 31 Mar 2003 00:46:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk It will be soon after the RFCs are published. SG Registrars, including ascio will also get a new API (which should function the same). :-) Edmon ----- Original Message ----- From: "Claus Dahl" To: Sent: Friday, March 28, 2003 9:12 AM Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue" > .SG is EPP by name only - it does not conform to the specs at all. > > Claus > > -----Original Message----- > From: Edmon Chung [mailto:edmon@neteka.com] > Sent: 28. marts 2003 14:48 > To: Asbjorn Mikkelsen; Ram Mohan > Cc: ietf-provreg@cafax.se > Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" > > > > On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > > > Last time I checked, at least half a dozen registries are running EPP > > > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > > .NL(?)plus a bunch more ccTLDs. > > > > ...and .NAME(05)... > > > ..and .SG(04) and soon to be .BZ(04 or 07) > > Edmon > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2TIW1x9015509 for ; Sat, 29 Mar 2003 19:32:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2TIW1lD015508 for ietf-provreg-outgoing; Sat, 29 Mar 2003 19:32:01 +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.8/8.12.8) with ESMTP id h2TIW0x9015503 for ; Sat, 29 Mar 2003 19:32:00 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2TIVxT1096405 for ; Sat, 29 Mar 2003 19:31:59 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2TIVxPZ096404 for ietf-provreg@cafax.se; Sat, 29 Mar 2003 19:31:59 +0100 (CET) Received: from ns1.ascio.com (ns1.ascio.com [213.237.145.77]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SECax9003008 for ; Fri, 28 Mar 2003 15:12:37 +0100 (MET) Received: from aries.dk.speednames.com (aries.dk.speednames.com [213.237.145.56]) by ns1.ascio.com (8.12.8/8.12.5) with ESMTP id h2SEDIAB002815 for ; Fri, 28 Mar 2003 14:13:18 GMT Received: by aries.dk.speednames.com with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Mar 2003 15:12:36 +0100 Message-ID: <2F15A97500CFA0469C9BACC2041F8AC702A0BE3F@aries.dk.speednames.com> From: Claus Dahl To: "'ietf-provreg@cafax.se'" Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Fri, 28 Mar 2003 15:12:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="UTF-8" Sender: owner-ietf-provreg@cafax.se Precedence: bulk .SG is EPP by name only - it does not conform to the specs at all. Claus -----Original Message----- From: Edmon Chung [mailto:edmon@neteka.com] Sent: 28. marts 2003 14:48 To: Asbjorn Mikkelsen; Ram Mohan Cc: ietf-provreg@cafax.se Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" > On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > > Last time I checked, at least half a dozen registries are running EPP > > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > .NL(?)plus a bunch more ccTLDs. > > ...and .NAME(05)... > ..and .SG(04) and soon to be .BZ(04 or 07) Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2TIVox9015501 for ; Sat, 29 Mar 2003 19:31:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2TIVnEl015500 for ietf-provreg-outgoing; Sat, 29 Mar 2003 19:31:49 +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.8/8.12.8) with ESMTP id h2TIVkx9015495 for ; Sat, 29 Mar 2003 19:31:46 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2TIVjT1096396 for ; Sat, 29 Mar 2003 19:31:45 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2TIVjnB096395 for ietf-provreg@cafax.se; Sat, 29 Mar 2003 19:31:45 +0100 (CET) Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SE9xx9002972 for ; Fri, 28 Mar 2003 15:09:59 +0100 (MET) Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Mar 2003 14:09:59 -0000 Message-ID: From: Antony Perkov To: ietf-provreg@cafax.se Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Fri, 28 Mar 2003 14:09:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > Last time I checked, at least half a dozen registries are > > > running EPP operationally. > > > .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > > .NL(?)plus a bunch more ccTLDs. > > > > ...and .NAME(05)... > > > ...and .SG(04) and soon to be .BZ(04 or 07) and .COOP(06) Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SLdux9008311 for ; Fri, 28 Mar 2003 22:39:56 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SLdu5U008310 for ietf-provreg-outgoing; Fri, 28 Mar 2003 22:39:56 +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.8/8.12.8) with ESMTP id h2SLdqx9008305 for ; Fri, 28 Mar 2003 22:39:54 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2SLasGL085733 for ; Fri, 28 Mar 2003 16:36:55 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303282136.h2SLasGL085733@nic-naa.net> To: ietf-provreg@cafax.se Subject: [ietf-provreg] Fd: Re: BH: Introducing the Beyond HTTP (BH) Task Force Date: Fri, 28 Mar 2003 16:36:54 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Anyone want this? I prefer not to "laze" (or however that is spelt), since I do such a bad job of contributing. I've re-arrainged the p3p mail to put my-take-on-epp (tm) first, for this list's benefit. ------- Forwarded Message > List-Id: > > On Friday 21 March 2003 05:48, Eric Brunner-Williams in Portland Maine > wrote: > > Here are a couple of things where I've attempted to take policies that > > are { similar to | derived from | stolen and wrecked | ... } P3P's and > > make mechanisms other than some set of HTTP methods transport apply. > > Thanks Eric ... > > I've briefly looked into each of of the apps below > looking for salient requirements and/or features of a scenario that might > be relevant. Please correct me if you think I've missed something. [this isn't the first item] > > 3. PROVREG WG, an IETF WG (current). The problem domain defined > > by Verisign's RRP protocol, using EBNF as the formal syntax, > > is slightly restated in EPP, using XML as the formal syntax. > > I'm unfamiliar with this work but I've poked about on: > http://www.ietf.org/html.charters/provreg-charter.html > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt > and see they have a : > """ - A (data collection policy) element that contains child > elements used to describe the server's privacy policy for data > collection and management.""" > with an {access, purpose, retention}, elements based on P3P. Since this is > active work, I think it makes sense to ask them why don't they use the > elements from P3P itself? And if there are reasons, we'd appreciate the > feedback. Do you have connections with this work, could you help start that > conversation? [ this is where the first item begins] > > 1. CPExchange, a customer profile exchange application-layer > > protocol, with no transport binding. The DTD for this and > > the pre-bubble bumpf are still available at > > http://www.cpexchange.org/ > > This appears to be an extension of the P3P privacy vocabulary with a more > extensive XML data profile based on XML Schema data types. It appears they > have the significant portion with {Access, Purpose, Retention, Recipient}. > Because it's based on a 2000 snapshot of P3P I can't discern any particular > divergence in the privacy vocabulary because of this app's context. I can > conclude that they felt there was a need for more extensive and XML Schema > typed data structures that would perhaps be of interest to the P3P Schema > taskforce. > > > 2. HTTP WG, an IETF WG (concluded). During the last year of the > > WG, Dan Jaye contributed a draft that extended the Kristol, > > Montulli draft on the state management mechanism, RFC 2965. > > This draft has expired, but I have it (co-author). The IESG > > published a note written by Moore and Freed (RFC 2964), on > > the problem domain, observing that some uses of the mechanism > > were harmful, and depricated policied cookies. > > I followed this work back in the day and my conclusion would be that there > was a requirement for terse expression. This appears to be satisfied with > compact policies and I would expect other apps with a similar requirement > to use them, or perhaps in the future a binary-XML representation of the > complete markup...? I've included this in > http://www.w3.org/P3P/2003/04-beyond-http#sec-Others > [part #3 delted here, moved up] > ------- End of Forwarded Message Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxPx9005005 for ; Fri, 28 Mar 2003 17:59:25 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SGxOam005003 for ietf-provreg-outgoing; Fri, 28 Mar 2003 17:59:24 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxHx9004984 for ; Fri, 28 Mar 2003 17:59:18 +0100 (MET) Received: from [192.149.252.108] ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA04338 for ; Fri, 28 Mar 2003 11:59:16 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337088B@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337088B@vsvapostal3.prod.netsol.com> Date: Fri, 28 Mar 2003 11:57:19 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: RE: [ietf-provreg] References for Today's Host Object Discussion Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Speaking in a co-chair capacity, I think that it is fair to reopen the issue. Jaap and I are aware of a significant number of silent speakers that really want to be host-object free. Answering to the charge that these documents sailed through last call without comment on this topic (albeit a topic discussed on the list), EPP has been generating wider interest as it progresses. There's always the trade-off of delay and feature adding, and mission creep versus focus. There is no clear rule that applies to each situation, so the question: Should EPP define a host-object-less model now? is one that can't be answered categorically (the "now" thing). But I think that it seems worthwhile to do so now - while we are also preparing to answer the privacy issue. Unless I am missing something, Scott, can you propose some text that would accommodate nameservers-as-attributes? Based on: >- Allowing a choice between name server host objects and name server domain >attributes. > http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html Joe offered to help..."I would be happy to contribute text if this sounds like a reasonable approach." At 18:01 -0500 3/24/03, Hollenbeck, Scott wrote: >I'm not one of the people responsible for determining consensus, but I can >say that the domain document has completed both WG and IETF last calls with >the currently specified feature set. Our chairs can, of course, direct me >to change something if WG consensus is to make a change. I'd prefer to keep >things as-is, though, because this is _not_ a new argument and we'll have a >chance to address this again when considering what to do when going from >proposed to draft. > >One of the things I intend to do once we're there is capture the outstanding >issues in an I-D that can be used to seed the proposed-to-draft discussion. >It would be helpful if people who have issues with any current features >could send me a note (off-list is OK) describing what they don't like _and_ >a suggested solution. We might then have the start of a pretty good problem >statement for EPP 1.1 or 2.0. > >-Scott- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxPx9005006 for ; Fri, 28 Mar 2003 17:59:25 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SGxPVE005004 for ietf-provreg-outgoing; Fri, 28 Mar 2003 17:59:25 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGxIx9004985 for ; Fri, 28 Mar 2003 17:59:23 +0100 (MET) Received: from [192.149.252.108] ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA04342; Fri, 28 Mar 2003 11:59:17 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: Date: Fri, 28 Mar 2003 11:59:11 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] the privacy problem statement Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Given that we've had a week to discuss the 'problem' and nothing seems to have risen up to change it (EBW's comments notwithstanding), I think it's safe to assume that the problem is as stated. IOW - Let's start looking at the solution. 'Course, it's never to complain about the problem statement. I just want to throw open the doors on proposed answers... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SGIvx9004338 for ; Fri, 28 Mar 2003 17:18:57 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SGIuZq004337 for ietf-provreg-outgoing; Fri, 28 Mar 2003 17:18:56 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2SGIsx9004327 for ; Fri, 28 Mar 2003 17:18:55 +0100 (MET) Message-ID: <016501c2f545$a6bbcfb0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "janusz sienkiewicz" Cc: References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> <00c001c2f530$367185c0$0f01a8c0@neteka.inc> <3E846F82.2A75EF14@libertyrms.info> Subject: Re: [ietf-provreg] privacy profile for domain mapping Date: Fri, 28 Mar 2003 11:18:20 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk That is quite true. There could be potential conflicts. We need statements that says the registry privacy policy will prevail, next the contact privacy preference will prevail and then domain preference is taken into consideration (which is what happens in our implementation for SG). i.e. If the registry policy is that Addr MUST be displayed for the domain, then even if the contact says dnd it can be disclosed (OR the policy can say that the upate/creation must fail) If the contact privacy preference say for email is dnd while the domain profile says ok for disclosure (AND that the Registry policy allows an opt-out of the info) then the email must NOT be disclosed (OR the policy can say that the update/creation must fail) OR a registry MUST choose to do privacy for domain mapping or contact mapping only and that they are mutually exclusive. In terms of dependence on contact mapping, that is not necessarily the case. If the privacy elements in domain mapping does NOT exist in the contact mapping, then the policy may say that the field is either ignored, or that the transaction should fail. Edmon ----- Original Message ----- From: "janusz sienkiewicz" To: "Edmon Chung" Cc: Sent: Friday, March 28, 2003 10:51 AM Subject: Re: [ietf-provreg] privacy profile for domain mapping > I see a general problem with all the proposed variants. They break modular > architecture of EPP protocol. With the current structure of the protocol there > is not much assumed in domain object mapping about contact object mapping and > other object mappings. All the proposed variants make domain object mapping > depended on contact object mapping. > > I see also practical problems with the proposals. It is possible to set > address, email privacy element/attribute to true in block. > Meanwhile the owner of the contact object (which does not have to be the same > as domain object) may set privacy element/attribute to false for address and > email elements. That will lead to a situation when the domain owner assumes his > privacy is protected and at the same time it is not. Someone can use whois to > query the contact object to see address and email. > > Janusz Sienkiewicz > > Edmon Chung wrote: > > > At the SF meeting we discussed adding privacy profile for contact mapping, > > but I think it is important to also add it to domain mapping as well, in > > fact, I think being able to handle a per domain profile model is even more > > important because the same contact may be the admin contact as well as say > > the tech contact and the disclosure requirements may also be different > > within the same domain. > > > > Moreover, one contact may be associated with multiple domains, and each > > domain may have different preference. (e.g. a domain registered in EU and a > > domain registered in US with the same contact might have to/want to > > disclose/hide different info) > > > > Anyway, here are four ways I have thought of to add the privacy elements for > > domain mapping: > > (p=0: ok to disclose, p=1: privacy preserved) > > > > (1) adding an optional block: > > > > ... > > > > > > > > > > > > > > > > sh8013 > > > > > > > > > > > > sh8013 > > > > > > > > > > ... > > > > (2) changing element to include privacy profile for each > > contact/registrant > > > > ... > > > > jd1234 > > > > > > > > > > > > sh8013 > > > > > > > > > > > > sh8013 > > > > > > > > ... > > > > (3) including everything as attributes in the > > element > > > > ... > > jd1234 > > sh8013 > > sh8013 > > ... > > > > (4) combination of 2 & 3 (postalInfo has a further child element while > > others are grouped as attributes) > > > > ... > > > > jd1234 > > > > > > > > > > > > > > sh8013 > > > > > > > > > > > > sh8013 > > > > > > > > There could also be a (5)th apporach that is to combine 1 & 4 for a smaller > > block. > > Thoughts? > > > > Edmon > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SFpWx9004101 for ; Fri, 28 Mar 2003 16:51:32 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SFpWY2004100 for ietf-provreg-outgoing; Fri, 28 Mar 2003 16:51:32 +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.8/8.12.8) with ESMTP id h2SFpUx9004095 for ; Fri, 28 Mar 2003 16:51:31 +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 18yw8f-0004h8-00; Fri, 28 Mar 2003 10:51:29 -0500 Message-ID: <3E846F82.2A75EF14@libertyrms.info> Date: Fri, 28 Mar 2003 10:51:30 -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: Edmon Chung CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] privacy profile for domain mapping References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> <00c001c2f530$367185c0$0f01a8c0@neteka.inc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk I see a general problem with all the proposed variants. They break modular architecture of EPP protocol. With the current structure of the protocol there is not much assumed in domain object mapping about contact object mapping and other object mappings. All the proposed variants make domain object mapping depended on contact object mapping. I see also practical problems with the proposals. It is possible to set address, email privacy element/attribute to true in block. Meanwhile the owner of the contact object (which does not have to be the same as domain object) may set privacy element/attribute to false for address and email elements. That will lead to a situation when the domain owner assumes his privacy is protected and at the same time it is not. Someone can use whois to query the contact object to see address and email. Janusz Sienkiewicz Edmon Chung wrote: > At the SF meeting we discussed adding privacy profile for contact mapping, > but I think it is important to also add it to domain mapping as well, in > fact, I think being able to handle a per domain profile model is even more > important because the same contact may be the admin contact as well as say > the tech contact and the disclosure requirements may also be different > within the same domain. > > Moreover, one contact may be associated with multiple domains, and each > domain may have different preference. (e.g. a domain registered in EU and a > domain registered in US with the same contact might have to/want to > disclose/hide different info) > > Anyway, here are four ways I have thought of to add the privacy elements for > domain mapping: > (p=0: ok to disclose, p=1: privacy preserved) > > (1) adding an optional block: > > ... > > > > > > > > sh8013 > > > > > > sh8013 > > > > > ... > > (2) changing element to include privacy profile for each > contact/registrant > > ... > > jd1234 > > > > > > sh8013 > > > > > > sh8013 > > > > ... > > (3) including everything as attributes in the > element > > ... > jd1234 > sh8013 > sh8013 > ... > > (4) combination of 2 & 3 (postalInfo has a further child element while > others are grouped as attributes) > > ... > > jd1234 > > > > > > > sh8013 > > > > > > sh8013 > > > > There could also be a (5)th apporach that is to combine 1 & 4 for a smaller > block. > Thoughts? > > Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SEn5x9003457 for ; Fri, 28 Mar 2003 15:49:05 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SEn5CB003456 for ietf-provreg-outgoing; Fri, 28 Mar 2003 15:49:05 +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.8/8.12.8) with ESMTP id h2SEn3x9003451 for ; Fri, 28 Mar 2003 15:49:04 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2SEk7GL084090; Fri, 28 Mar 2003 09:46:07 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303281446.h2SEk7GL084090@nic-naa.net> To: "Edmon Chung" cc: "Asbjorn Mikkelsen" , "Ram Mohan" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Fri, 28 Mar 2003 08:48:17 EST." <00da01c2f530$b178bb30$0f01a8c0@neteka.inc> Date: Fri, 28 Mar 2003 09:46:07 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > ...and .SG(04) and soon to be .BZ(04 or 07) congrats edmon!!! i'd thought that .bz was a vgrs property. whether you've moved on to the high-table at vgrs, or swung a spin-out deal, i'm impressed. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SDn2x9002704 for ; Fri, 28 Mar 2003 14:49:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SDn2nA002703 for ietf-provreg-outgoing; Fri, 28 Mar 2003 14:49:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2SDn0x9002698 for ; Fri, 28 Mar 2003 14:49:01 +0100 (MET) Message-ID: <00da01c2f530$b178bb30$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Asbjorn Mikkelsen" , "Ram Mohan" Cc: References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> <1048843384.2732.19.camel@bubba> Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Fri, 28 Mar 2003 08:48:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > > Last time I checked, at least half a dozen registries are running EPP > > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > > .NL(?)plus a bunch more ccTLDs. > > ...and .NAME(05)... > ...and .SG(04) and soon to be .BZ(04 or 07) Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2SDjUx9002659 for ; Fri, 28 Mar 2003 14:45:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2SDjUd9002658 for ietf-provreg-outgoing; Fri, 28 Mar 2003 14:45:30 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2SDjSx9002653 for ; Fri, 28 Mar 2003 14:45:29 +0100 (MET) Message-ID: <00c001c2f530$367185c0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> Subject: [ietf-provreg] privacy profile for domain mapping Date: Fri, 28 Mar 2003 08:44:51 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At the SF meeting we discussed adding privacy profile for contact mapping, but I think it is important to also add it to domain mapping as well, in fact, I think being able to handle a per domain profile model is even more important because the same contact may be the admin contact as well as say the tech contact and the disclosure requirements may also be different within the same domain. Moreover, one contact may be associated with multiple domains, and each domain may have different preference. (e.g. a domain registered in EU and a domain registered in US with the same contact might have to/want to disclose/hide different info) Anyway, here are four ways I have thought of to add the privacy elements for domain mapping: (p=0: ok to disclose, p=1: privacy preserved) (1) adding an optional block: ... sh8013 sh8013 ... (2) changing element to include privacy profile for each contact/registrant ... jd1234 sh8013 sh8013 ... (3) including everything as attributes in the element ... jd1234 sh8013 sh8013 ... (4) combination of 2 & 3 (postalInfo has a further child element while others are grouped as attributes) ... jd1234 sh8013 sh8013 There could also be a (5)th apporach that is to combine 1 & 4 for a smaller block. Thoughts? Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2S9Swx9000880 for ; Fri, 28 Mar 2003 10:28:58 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2S9SwqX000879 for ietf-provreg-outgoing; Fri, 28 Mar 2003 10:28:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx01.gnr.com (mx01.gnr.com [193.109.220.157]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2S9Svx9000874 for ; Fri, 28 Mar 2003 10:28:57 +0100 (MET) Received: (qmail 25706 invoked by alias); 28 Mar 2003 09:28:55 -0000 Received: from unknown (HELO gnr-mailsweeper.gnr.com) (213.105.192.220) by muk-gnrmx-01.gnr.com with SMTP; 28 Mar 2003 09:28:55 -0000 Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Mar 2003 09:34:18 +0000 Received: from asbjorn.gnr.com ([192.168.3.23]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Mar 2003 09:23:43 +0000 Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" From: Asbjorn Mikkelsen To: Ram Mohan Cc: ietf-provreg@cafax.se In-Reply-To: <097501c2f4d7$a1464c40$1b00e494@afilias.com> References: <200303252132.h2PLWdGL068436@nic-naa.net> <097501c2f4d7$a1464c40$1b00e494@afilias.com> Content-Type: text/plain Organization: Message-Id: <1048843384.2732.19.camel@bubba> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 28 Mar 2003 09:23:04 +0000 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2003 09:23:43.0706 (UTC) FILETIME=[BA31B3A0:01C2F50B] Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, 2003-03-28 at 03:10, Ram Mohan wrote: > Last time I checked, at least half a dozen registries are running EPP > operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), > .NL(?)plus a bunch more ccTLDs. ...and .NAME(05)... Asbjorn -- Asbjorn Steira Senior Developer The Global Name Registry, Limited Tel: +44 (0) 207 025 2214 Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company. This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties. ***************** What's your .name? Get one at www.name ***************** Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2S3Awx9028137 for ; Fri, 28 Mar 2003 04:10:58 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2S3AwiL028136 for ietf-provreg-outgoing; Fri, 28 Mar 2003 04:10:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from localhost.domain (200-184-189-198.sofitel.com.br [200.184.189.198] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2S3Atx9028131 for ; Fri, 28 Mar 2003 04:10:57 +0100 (MET) Received: from eagle (unknown [192.168.1.102]) by localhost.domain (Postfix) with ESMTP id 7B7909E89; Thu, 27 Mar 2003 23:31:43 -0300 (BRT) Message-ID: <097501c2f4d7$a1464c40$1b00e494@afilias.com> From: "Ram Mohan" To: "Eric Brunner-Williams in Portland Maine" , "Edward Lewis" Cc: "Edward Lewis" , "Eric Brunner-Williams in Portland Maine" , , References: <200303252132.h2PLWdGL068436@nic-naa.net> Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Date: Thu, 27 Mar 2003 22:10:17 -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 Ed, [snip] > I want to avoid the appearance that EPP is perfect. > No one is running it operationally yet Last time I checked, at least half a dozen registries are running EPP operationally. .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05), .NL(?)plus a bunch more ccTLDs. > But it's also apparent that whatever flaws hiding in > it are hidden so well not many of us see them. Not sure the hypothesis is true; exposure of limitations has probably not happened - i know a few registry folks who have things they don't much care for in EPP, but haven't talked about it on the list. -ram Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QNGJx9006016 for ; Thu, 27 Mar 2003 00:16:19 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QNGJCv006015 for ietf-provreg-outgoing; Thu, 27 Mar 2003 00:16:19 +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.8/8.12.8) with ESMTP id h2QNGFx9006010 for ; Thu, 27 Mar 2003 00:16:17 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2QNDfGL073448; Wed, 26 Mar 2003 18:13:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303262313.h2QNDfGL073448@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Wed, 26 Mar 2003 14:26:30 EST." Date: Wed, 26 Mar 2003 18:13:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > In this case, "makes a decision on whether to send some data in a > message." Which isn't the same thing as "makes a decision on whether to send any data in a message." Which is why I asked a Yes/No/Mumble question (partial write semantics), since between "none" and "all" lies "mumble". Eventually I suppose that "mumble" will take some greater detail. At least enough to make "mumble enforcement" sensible. Somewhere out there is a manditory to implement (but always optional to deploy) requirement that one end point or the other shave at least one bit (haircut optional for an additional two bits) off of some object. Which bit(s) is tbd, but some sort of mask is a given. I'd like to go on record as wanting the Mask of Zorro, er, Zero. > Part of the problem statement was that we wanted to piecemeal the > privacy metadata to a finer scope. Do you think that that is a bad > idea? I'm certain its a ... IESG idea ... to insist on the syntactic form of metadata, and insist that it be temporally scopeless, and insist that it is the terminal node in a directed acyclic graph (element attribute). Randy's an ex-compiler weenie, he knows what he's proposing. \begin{wicked_serious_mode} It depends on what one is attempting to design. If one is attempting to provision policy data (aka "metadata") in an SRS, and the SRS is not partitioned by metadata, and the data is uncorrolated w.r.t. metadata, then the metadata is sensibly encoded into the data. We did assume that there was correlation when we went for the session scoped , thinking that changes in would be infrequent, relative to the policied objects, that session encoding of the metadata was sensible, that the value-space of the was a lot smaller than the value-space of the object, and this design choice did not preclude client sourcing of , or negociation of , or .... Where the "finer is better" approach veers away from reality is in the assertion that no sensible aggregation of stuff is already well-defined in some relevant context. If 95/46/EC is a guide for anything that is remotely related to "privacy", we can expect to find in it an approval of "finer is better". I don't. What I do find is that deconstruction of the data is only part of the problem domain. Deconstruction of the purpose, recipients, temporal existance, originator write-through (aka "access"), and more define the problem domain, and that "fine structure" is less important than policing lumps, and relations between lumps, that when handled with the intent to construct or extract personally identifying information, can. I can live with "design" in the IETF social construct, with PS/DS/SS having a different frame of reference from "design" in the W2C social construct. I tried to "cross over" a gramatical framework, from the W3C to the IETF. It wasn't a success. No matter. I'm spending more time trying to prevent there being two or more core syntaxes than I will spend implementing those few I care about, so I'm way past my ROI, or my sell-by date. \end{wicked_serious_mode} > ... We have to gain operational experience ... With a mechanism with no discernable effect. OK. > I have heard rumors that in some business dealings swirling around > the work done here, there is a need for a "standard." To some that's > an RFC, to others PR, to others DS, and so yet some others Full > Standard or even STD-n. As a chair, I can't deal with what others > call a "standard" all I can deal with is what's in the process > documents. I'm happy with Dork-i-mental, and operational experience. I have very low tastes. Maybe none at all. Cheers, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QLOnx9004956 for ; Wed, 26 Mar 2003 22:24:49 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QLOn8W004955 for ietf-provreg-outgoing; Wed, 26 Mar 2003 22:24:49 +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.8/8.12.8) with ESMTP id h2QLOlx9004950 for ; Wed, 26 Mar 2003 22:24:48 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2QLMHGL073082; Wed, 26 Mar 2003 16:22:17 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303262122.h2QLMHGL073082@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Wed, 26 Mar 2003 14:18:27 EST." Date: Wed, 26 Mar 2003 16:22:17 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear Co-Chair of the PROVREG WG (and all around nice guy Ed Lewis), I have no angst. I am quite content that no working group, in particular, the PROVREG WG, has any interest in some drafts published as individual contributions. Just to be degenerate, which comes easily to me, and get to some core issues of ordering, reliability, and who is the author of requirements... EBW sez contains no fewer than zero, and possibly as many as one, maybe even three, instances of the operation "check" on the operand "bar", which might be ordered, and the temporal bounds on delivery are ... "best effort", or weaker. PAF sez contains exactly three, ordered instances of the operation "check" on the operand "bar", and the temporal bounds on delivery are ... "web time", an odd bit of transactional real-time. EBW sez for some things, it matters, for some things, it don't. PAF sez for all things, it matters equally. That disposes of epp/smtp, epp/udp, epp/http, epp/uucp, and of course epp/avian-transport (only a few days until that one, neh?). This is all done, my concern with the present question fits fairly neatly into two questions. I can wait till they're answered, or ... expire. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QJQux9003589 for ; Wed, 26 Mar 2003 20:26:56 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QJQuAS003588 for ietf-provreg-outgoing; Wed, 26 Mar 2003 20:26:56 +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.8/8.12.8) with ESMTP id h2QJQsx9003576 for ; Wed, 26 Mar 2003 20:26:54 +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 h2QJQq34055495; Wed, 26 Mar 2003 14:26:52 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.47]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA08947; Wed, 26 Mar 2003 14:26:51 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303252211.h2PMBRGL068597@nic-naa.net> References: <200303252211.h2PMBRGL068597@nic-naa.net> Date: Wed, 26 Mar 2003 14:26:30 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 17:11 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote: >> Apparently you >> are not happy with requiring the protocol let the client include >> privacy meta-data to achieve the goal of allowing enforcement to >> happen at the server. > >Actually, I don't even know what "enforcement" means. > >How is "enforcement" meaningfully defined in the protocol? In this case, "makes a decision on whether to send some data in a message." We see the need to make decisions at either the registry or registrar. >> Apparently you >> are not happy with requiring the protocol let the client include >> privacy meta-data > >But it isn't that simple, is it? If it were, then just sourcing the >from the client, and sinking it at the server, would suffice. But that >isn't it. Part of the problem statement was that we wanted to piecemeal the privacy metadata to a finer scope. Do you think that that is a bad idea? >No that is interesting. A functional requirement with no semantics. >A mechanism with no discernable effect. Now that is worth the price of >admission. Yes, that is part of the role of being a proposed standard. We have to gain operational experience that may find that parts of the protocol are useless or a needed to be expanded - as well as the circumstances of the documents. I have heard rumors that in some business dealings swirling around the work done here, there is a need for a "standard." To some that's an RFC, to others PR, to others DS, and so yet some others Full Standard or even STD-n. As a chair, I can't deal with what others call a "standard" all I can deal with is what's in the process documents. > >> >Is the new semantic capable of test by any in-protocol means? >> >> Well, we want to be able to set, check, change and define the meaning >> of absence. > >Sounds like an abstract, post-creat, access provisioning protocol, for >shared, multi-reader repositories. > >Not the same as getting the data past creat, or mod, or ... Fortunately, this time I got lost at the end of the message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2QJQtx9003582 for ; Wed, 26 Mar 2003 20:26:55 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2QJQtVn003581 for ietf-provreg-outgoing; Wed, 26 Mar 2003 20:26:55 +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.8/8.12.8) with ESMTP id h2QJQsx9003575 for ; Wed, 26 Mar 2003 20:26:54 +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 h2QJQp34055489; Wed, 26 Mar 2003 14:26:51 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.47]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA08944; Wed, 26 Mar 2003 14:26:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303252132.h2PLWdGL068436@nic-naa.net> References: <200303252132.h2PLWdGL068436@nic-naa.net> Date: Wed, 26 Mar 2003 14:18:27 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: side bar, was Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Answering the side-bar message first: At 16:32 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote: >Ed, > >Let's get this bit out of the way. Speaking as a chair, Eric, I have to admit I am having trouble comprehending your angst here. Honestly, every time I begin to try to reply to some point you are raising, I get lost in thought and realize I've no answer. I don't want to discount a lone voice in the wilderness (as no one else is speaking out in the same way), but its that whatever is clueing you into your view is not apparent to me. Hence, I'm powerless to help. I want to avoid the appearance that EPP is perfect. (No one is running it operationally yet, so even if EPP is the most righteous protocol ever designed by mankind, there's no empirical evidence that it is perfect.) But it's also apparent that whatever flaws hiding in it are hidden so well not many of us see them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PMeox9022412 for ; Tue, 25 Mar 2003 23:40:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PMeoBV022410 for ietf-provreg-outgoing; Tue, 25 Mar 2003 23:40: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.8/8.12.8) with ESMTP id h2PMemx9022405 for ; Tue, 25 Mar 2003 23:40:48 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PMcVGL068724; Tue, 25 Mar 2003 17:38:31 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303252238.h2PMcVGL068724@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 13:54:38 EST." Date: Tue, 25 Mar 2003 17:38:31 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, I'm going to shut up and wait until Scott next delta's of the draft set. If there is no answer more ... whatever than what's been offered to my questions to Randy, well, that's life. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PMDkx9022153 for ; Tue, 25 Mar 2003 23:13:46 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PMDkUu022152 for ietf-provreg-outgoing; Tue, 25 Mar 2003 23:13: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.8/8.12.8) with ESMTP id h2PMDix9022147 for ; Tue, 25 Mar 2003 23:13:44 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PMBRGL068597; Tue, 25 Mar 2003 17:11:27 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303252211.h2PMBRGL068597@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 13:54:38 EST." Date: Tue, 25 Mar 2003 17:11:27 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Apparently you > are not happy with requiring the protocol let the client include > privacy meta-data to achieve the goal of allowing enforcement to > happen at the server. Actually, I don't even know what "enforcement" means. How is "enforcement" meaningfully defined in the protocol? If EPP allowed unconditional write-access to a centralized store, with only an auth-thingie to partition the store into N-registrar buckets, and allowed each writer to write the read-access (general, a la :43, or to any other registrar writer, or the blind registry store manager), then I'd have a clue what "enforcement" might mean. The registrar would hand a bitmask the size of a contact object to the registry, and could attempt to modify it without the auth-thingie, or read it back without the auth-thingie. Partial sight proved. > Apparently you > are not happy with requiring the protocol let the client include > privacy meta-data If only it were that simple. All I'm looking for is a way to distinguish one policied endpoint from another. What I'm not looking for is a way to change the policy on one policied endpoint, until it is indistinguishable from another. > Apparently you > are not happy with requiring the protocol let the client include > privacy meta-data But it isn't that simple, is it? If it were, then just sourcing the from the client, and sinking it at the server, would suffice. But that isn't it. Hey, we could go back to BNF, or whatever the people use who write the UI stuff for insurance companies, and add a little check box. For some reason, the extra bit(s) have to be just so. > >Are there any success or failure semantics? Is the transaction atomic and > >unitary, or is a partial write success? > > It's all policy as far as we can tell. No that is interesting. A functional requirement with no semantics. A mechanism with no discernable effect. Now that is worth the price of admission. > >Is the new semantic capable of test by any in-protocol means? > > Well, we want to be able to set, check, change and define the meaning > of absence. Sounds like an abstract, post-creat, access provisioning protocol, for shared, multi-reader repositories. Not the same as getting the data past creat, or mod, or ... Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PLZ0x9021764 for ; Tue, 25 Mar 2003 22:35:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PLZ0bK021763 for ietf-provreg-outgoing; Tue, 25 Mar 2003 22:35:00 +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.8/8.12.8) with ESMTP id h2PLYvx9021758 for ; Tue, 25 Mar 2003 22:34:58 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PLWdGL068436; Tue, 25 Mar 2003 16:32:39 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303252132.h2PLWdGL068436@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 13:54:38 EST." Date: Tue, 25 Mar 2003 16:32:39 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Let's get this bit out of the way. > >I wasn't thrilled with the congestion issue either, or the ordering issue, > >but those are damp spots under prior bridges. > > I suppose you are referring in some way to the statement that we > aren't pursuing SMTP or other transports over TCP (or other > transports at all). No. It isn't about what documents the WG pursues. Its about the way that session semantics crept in, and in a more exclusive form than any contributor to the WG reqested, either during the reqs period, or during the incremental deltas from -02 to -06. I wrote about this at length. Why does a stream of have to be strictly ordered? I don't know. It is worth a drink. Now this may not be what everyone, or even anyone, wants to do, but to discover in the ratrace of speculative gTLD operational art, some new _universal_ requirement that ordering must be preserved, even for some EPP-for-penguins deployment, is odd. Then there's the got-to-have-it-now problem, or why order preserving semantics aren't strong enough, they must be connectionist too. Bye bye email. Under the guiding light of the IESG we've gone from a protocol to a rather narrower operational market in the guise of a protocol. Believe me, I'm much happier with my drafts poking along dorkily to dorkimental. But these are edge cases. Transport thingies. Brunner's bad ideas. The issue before the WG today is the common syntax. Existance, or not. With that I'll go back to your note. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PIu0x9019989 for ; Tue, 25 Mar 2003 19:56:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PIu0KX019988 for ietf-provreg-outgoing; Tue, 25 Mar 2003 19:56:00 +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.8/8.12.8) with ESMTP id h2PItwx9019983 for ; Tue, 25 Mar 2003 19:55:59 +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 h2PItt34020498; Tue, 25 Mar 2003 13:55:56 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.66]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA13863; Tue, 25 Mar 2003 13:55:55 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303251821.h2PILeGL067674@nic-naa.net> References: <200303251821.h2PILeGL067674@nic-naa.net> Date: Tue, 25 Mar 2003 13:54:38 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 13:21 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote: >False. It is a requirement not in 3375. It is a new requirement, one that >modifies some functionality. Yup. The issue isn't whether something is new or not. The issue is whether it is a good idea. Recall that in the IETF process, an RFC is just that, a request for comments. I've stated in the past that there is never a deadline for getting it right - so long as we get it timely. We can "debate" forever on the merits of late requirements and concerns late in the game - but if you care about that, problem-statement seems to be the place. Let's focus on this problem statement and not worry about whether or not the process is a problem. >OK, so neither of us writing or grading english compositions. EPP "works" >as is (-02, -04, -06, ... for some value of "works"), and some new thing >is desired by someone in -0N, for some value of N. Fair enough. Basically, yeah. >We don't know it is a good idea, we do know that it is the IESG's idea. So, Okay, let's get over this. Forget who suggested it. Apparently you are not happy with requiring the protocol let the client include privacy meta-data to achieve the goal of allowing enforcement to happen at the server. Others have thought this is a good idea, mostly in the room and Scott so far as agreed that the statements in the room amounted to what I wrote. >when we say that Scott is the editor of documents under the change control >of the IETF, what we are really saying is that the actual change control is >held, not by the contributors, acting in concert, under 2026, et alia, to >create some specification, but by institutional authority figures other than >the I-D administrator, who may add/delete/modify the text, without undertaking >the corresponding action on the requirements doc, which has already had WGLC, >and IETF-LC. Once again - worry about this in problem-statement. I ain't about to debate the role of the document editor here - the topic is EPP, not the IETF. Scott is recording the consensus of the WG, along with much of the material he originally brought to the WG in 2000. (See the charter, it hasn't changed.) >If someone wants to modify 3375 and delete the manditory announcement clause, >let them. It is possibly deficient. > >If someone wants to modify 3375 and add a manditory enforcement clause, let >them. It is possibly sufficient. I don't think that there's much support for writing 3375bis at this time. Perhaps when a WG comes along to advance to Draft Standard it would be good to have a document that rolls in operationally derived experience, but it's way too premature to consider this now. >I'm "unhappy" about what I see as the technical difficulty of the proposal, >the inability of the authors of the proposal to make a technical case for a >mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and >the process to effect change control of the provreg work product. With the high bandwith of voice-over-soundwave (a cutsy name for face-to-face meetings) I think we were able to get deeper into the issue. >I wasn't thrilled with the congestion issue either, or the ordering issue, >but those are damp spots under prior bridges. I suppose you are referring in some way to the statement that we aren't pursuing SMTP or other transports over TCP (or other transports at all). One reason we are not pursuing them is that 1) no one has maintained a document on this for a prolonged period of time and 2) no second person has cared enough to present an interoperability-motivated reason for this to be brought into the group. I know you have had documents that discussed SMTP. My reading of them was that they were never fully developed enough to trigger me into personal action. As a WG chair, admittance of documents is based in part on a reason to use the WG's resources - i.e., the members. Without voluntary member motivation to review the documents, there's not a sufficient reason for the WG to expand its horizons. I.e., although our charter says we will investigate alternate transports - it doesn't mean we will develop an alternate transport. So far the result of the investigation is that there's been no popular support for other transports. >> >Question #1: If the client originated a as part of session >> >init, and the server responded with a , and the evalution >> >algorithm (tbd) was simple, e.g., equality, would that meet their >> >requirement? >> >> Initially, this might be, but as an outcome of the discussion in the >> meeting we felt that finer granularity was desirable and achievable. >> We talked about this as being a session-granular thing, but that was >> discarded. > >I thought so, which is why I asked. > >Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select) >is unrestricted, _this_isn't_what_the_iesg_wants_. You've lost me again here. >On the bright side, this means that all two-step discovery kludges of the >form Edmon proposed are as KIA as the . > >On the dim side, this seems to mean that the issue is syntax or religion, >as there's a heck of a lot of values less than BIGNUM (or a full DOM tree), >and a baroque richesse of choices when one is unrestricted. So semantics is >possibly _not_ the issue. > >> >> >In eppcom-1.0.xsd we have this: >> >> You're getting into an implementation detail. At this point, we are >> hashing out the problem statement. > >I could be wrong, but the authors of the document offering guidance on the >use of xml in IETF protocols may have failed to mention an edge case. > >If a type is inextensible, and is used to type a datum that cannot be >semantically conditioned by any means other than extension, for reasons >that are non-sytactic in nature, an "owie" occurs. I'm sure there is a >better form of expressing this than "owie". There may be a better form of saying "owie" but the cost-benefit of finding this seems to be discouraging to the group. (I.e., we've been running around just trying to figure out how to spell pirvayc at that point.) >The point of the implementation detail is that I think (I'd prefer to be >wrong) that we need to put a layer between the syntax of EPP extensions >to XML, and the basic types of XML, so that "policy" can be hidden in the >syntax, which I don't see a way to do with the "mail" element's "token" >type. > >Eventually all this garbage, mine and anyone else's, gets tossed into a >validating parser. What comes out may come as a surprise to me. Valid concern, but as I said before - implementation detail. >Are there any success or failure semantics? Is the transaction atomic and >unitary, or is a partial write success? It's all policy as far as we can tell. >Is the new semantic capable of test by any in-protocol means? Well, we want to be able to set, check, change and define the meaning of absence. >How large is the policy value space? > >Taking the phone number example above, the value space appears to encode >neatly into a single bit. > > >If so, while I'm typing this I've found one solution to the "email" element >qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal >to pun the size type and signal directionality, into an octet. Violate some >rule about octets in mail addrs, e.g., set a high bit in the domain name. >If high-bit on, semantic one flag set and unset bit before store. >If high-bit off, semantic one flag not set. > >mail="brunner@nic-naa.ne(eval((0x164+0x177)" > >Wierd. I guess the same could be done to the e164 type too. > >Of course, if the value space doesn't encode neatly into one bit, then >this won't work, unless applied iteratively. > >Eric Details, implementation details... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PIO0x9019646 for ; Tue, 25 Mar 2003 19:24:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PIO0wC019645 for ietf-provreg-outgoing; Tue, 25 Mar 2003 19:24:00 +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.8/8.12.8) with ESMTP id h2PINwx9019640 for ; Tue, 25 Mar 2003 19:23:58 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2PILeGL067674; Tue, 25 Mar 2003 13:21:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303251821.h2PILeGL067674@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Tue, 25 Mar 2003 09:51:16 EST." Date: Tue, 25 Mar 2003 13:21:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Ed, Long and interlinear. > At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote: > >It had one error. The assertion that to function (at all) some delta > >is required. The correct statement is to function (as required post > >rfc3375) some delta is required. > > Eric, help me here. What is your point? You wrote: What is desired is a mechanism that will let EPP support thick registries, in which social data is held by the registry. No new mechanism is required by this sentence. In such situations, the registrar needs to inform the registry of restrictions on the redistribution of the data submitted to the registry. False. It is a requirement not in 3375. It is a new requirement, one that modifies some functionality. OK, so neither of us writing or grading english compositions. EPP "works" as is (-02, -04, -06, ... for some value of "works"), and some new thing is desired by someone in -0N, for some value of N. Fair enough. > >Requirement by assertion is more popular than I recall. > > I'm still not getting your point. I'm not sure if you are unhappy > that someone wants to add client-sent statements on privacy or that > the someone is the IESG. I'm not sure I see a reason from you > explaining why adding this is a bad idea. Any requirement not in the req doc is either a) previously rejected, or b) a failure of the process that created the req doc, or c) neither a) nor b). Suppose c. We don't know it is a good idea, we do know that it is the IESG's idea. So, when we say that Scott is the editor of documents under the change control of the IETF, what we are really saying is that the actual change control is held, not by the contributors, acting in concert, under 2026, et alia, to create some specification, but by institutional authority figures other than the I-D administrator, who may add/delete/modify the text, without undertaking the corresponding action on the requirements doc, which has already had WGLC, and IETF-LC. If someone wants to modify 3375 and delete the manditory announcement clause, let them. It is possibly deficient. If someone wants to modify 3375 and add a manditory enforcement clause, let them. It is possibly sufficient. I'm "unhappy" about what I see as the technical difficulty of the proposal, the inability of the authors of the proposal to make a technical case for a mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and the process to effect change control of the provreg work product. I wasn't thrilled with the congestion issue either, or the ordering issue, but those are damp spots under prior bridges. > >Question #1: If the client originated a as part of session > >init, and the server responded with a , and the evalution > >algorithm (tbd) was simple, e.g., equality, would that meet their > >requirement? > > Initially, this might be, but as an outcome of the discussion in the > meeting we felt that finer granularity was desirable and achievable. > We talked about this as being a session-granular thing, but that was > discarded. I thought so, which is why I asked. Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select) is unrestricted, _this_isn't_what_the_iesg_wants_. On the bright side, this means that all two-step discovery kludges of the form Edmon proposed are as KIA as the . On the dim side, this seems to mean that the issue is syntax or religion, as there's a heck of a lot of values less than BIGNUM (or a full DOM tree), and a baroque richesse of choices when one is unrestricted. So semantics is possibly _not_ the issue. > > >In eppcom-1.0.xsd we have this: > > You're getting into an implementation detail. At this point, we are > hashing out the problem statement. I could be wrong, but the authors of the document offering guidance on the use of xml in IETF protocols may have failed to mention an edge case. If a type is inextensible, and is used to type a datum that cannot be semantically conditioned by any means other than extension, for reasons that are non-sytactic in nature, an "owie" occurs. I'm sure there is a better form of expressing this than "owie". The point of the implementation detail is that I think (I'd prefer to be wrong) that we need to put a layer between the syntax of EPP extensions to XML, and the basic types of XML, so that "policy" can be hidden in the syntax, which I don't see a way to do with the "mail" element's "token" type. Eventually all this garbage, mine and anyone else's, gets tossed into a validating parser. What comes out may come as a surprise to me. > >> The IESG is doing this through the role of protocol design engineer > >> review - recognizing functionality that oughta be in a protocol but > >> isn't. > > > >3375 is the requirements statement. > > Yeah, it is. Obviously, you mean something by saying that, but it is > not clear. See above. *-LC are not meaningless, and should not be "worked around". > >> But the only option available to users of the client is to decide > >> whether or not to make the registration. We want more of an option > >> than that. > > > >Please explain. > > We want the registrar to be able to say, here's the phone number but > don't send it anywhere. What is meant by 'anywhere' is policy > specific, hence outside the WG's concern. Are there any success or failure semantics? Is the transaction atomic and unitary, or is a partial write success? Is the new semantic capable of test by any in-protocol means? > >It is my sense that "privacy" is not simple. > > Then it's not privacy we are concerned about. It's about tagging > data with something called 'privacy.' How large is the policy value space? Taking the phone number example above, the value space appears to encode neatly into a single bit. If so, while I'm typing this I've found one solution to the "email" element qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal to pun the size type and signal directionality, into an octet. Violate some rule about octets in mail addrs, e.g., set a high bit in the domain name. If high-bit on, semantic one flag set and unset bit before store. If high-bit off, semantic one flag not set. mail="brunner@nic-naa.ne(eval((0x164+0x177)" Wierd. I guess the same could be done to the e164 type too. Of course, if the value space doesn't encode neatly into one bit, then this won't work, unless applied iteratively. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2PEqVx9017293 for ; Tue, 25 Mar 2003 15:52:31 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2PEqVcu017292 for ietf-provreg-outgoing; Tue, 25 Mar 2003 15:52:31 +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.8/8.12.8) with ESMTP id h2PEqTx9017286 for ; Tue, 25 Mar 2003 15:52:29 +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 h2PEqR34011012; Tue, 25 Mar 2003 09:52:28 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.41]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA08471; Tue, 25 Mar 2003 09:52:26 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303242333.h2ONXGGL063921@nic-naa.net> References: <200303242333.h2ONXGGL063921@nic-naa.net> Date: Tue, 25 Mar 2003 09:51:16 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote: >It had one error. The assertion that to function (at all) some delta >is required. The correct statement is to function (as required post >rfc3375) some delta is required. Eric, help me here. What is your point? >Requirement by assertion is more popular than I recall. I'm still not getting your point. I'm not sure if you are unhappy that someone wants to add client-sent statements on privacy or that the someone is the IESG. I'm not sure I see a reason from you explaining why adding this is a bad idea. >Question #1: If the client originated a as part of session >init, and the server responded with a , and the evalution >algorithm (tbd) was simple, e.g., equality, would that meet their >requirement? Initially, this might be, but as an outcome of the discussion in the meeting we felt that finer granularity was desirable and achievable. We talked about this as being a session-granular thing, but that was discarded. >In eppcom-1.0.xsd we have this: You're getting into an implementation detail. At this point, we are hashing out the problem statement. >> The IESG is doing this through the role of protocol design engineer >> review - recognizing functionality that oughta be in a protocol but >> isn't. > >3375 is the requirements statement. Yeah, it is. Obviously, you mean something by saying that, but it is not clear. >> But the only option available to users of the client is to decide >> whether or not to make the registration. We want more of an option >> than that. > >Please explain. We want the registrar to be able to say, here's the phone number but don't send it anywhere. What is meant by 'anywhere' is policy specific, hence outside the WG's concern. >It is my sense that "privacy" is not simple. Then it's not privacy we are concerned about. It's about tagging data with something called 'privacy.' Recall that this effort is to build an interoperable, general purpose protocol. If there is something you think is useless and harmless, then don't use it and don't complain. (Harmless = doesn't cause a lot of things, including [useless] bloat.) You may decide that what is here is not enough, then use an extension. You may decide what is here does not apply to you, but if it applies to someone else, see if you can live with it. The process is about finding "common denominators" and not tailored, optimized, solutions. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ONZMx9008995 for ; Tue, 25 Mar 2003 00:35:23 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ONZMoV008994 for ietf-provreg-outgoing; Tue, 25 Mar 2003 00:35:22 +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.8/8.12.8) with ESMTP id h2ONZLx9008989 for ; Tue, 25 Mar 2003 00:35:21 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2ONXGGL063921; Mon, 24 Mar 2003 18:33:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303242333.h2ONXGGL063921@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Mon, 24 Mar 2003 16:21:09 EST." Date: Mon, 24 Mar 2003 18:33:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >I'm not convinced that the issue of contention is technical. > > Then I've failed in my description of the problem. It had one error. The assertion that to function (at all) some delta is required. The correct statement is to function (as required post rfc3375) some delta is required. Requirement by assertion is more popular than I recall. > As we sit, EPP requires the registrar to make decisions on whether > the submission of a piece of data will be accorded the proper > handling with regards to privacy. The issue is that EPP forces the > registrar into this posture, there is no choice. There are a lot of restrictions. RRP doesn't have this one (it has others). SRS doesn't have this one (it too has others). Etcetera. Its a nuance that may be lost on some, but the evaluation possible by the registrar isn't necessarily prospective (forward looking), it can be of the announced policy at the moment of transactional evaluation, with some explicit temporal guarantees. Mind, all of the evaluation is either optional (epp-07), manditory (epp-08), or irrelevant (iesg-any). > What the IESG has asked of us is to make EPP possible to support a > scenario in which a registrar gives the data and policy request to > the registry and then let the registry decide what to do. Question #1: If the client originated a as part of session init, and the server responded with a , and the evalution algorithm (tbd) was simple, e.g., equality, would that meet their requirement? > Furthermore, a basic framework for this is desired to be part of the > base protocol. As the formal specification of this protocol is in XML, this is more than it appears. In eppcom-1.0.xsd we have this: We use it to define type ofthe element "email". Now how does a "data structures 101" compatible tag fit into that? > The IESG is doing this through the role of protocol design engineer > review - recognizing functionality that oughta be in a protocol but > isn't. 3375 is the requirements statement. > >The registry announces a session-policy. Implementors are free > >to evaluate the registry-announced policy, and implement local policy, > >e.g., accept the policy and propogate policied data, or decline. > > But the only option available to users of the client is to decide > whether or not to make the registration. We want more of an option > than that. Please explain. > >To me, it _was_ just distributed read and write access mechanisms to > >shared store, with a specific syntax. If someone claims read-on-43 > >exhaustively defines "privacy", I don't care. It doesn't exhaustively > >define _read_. > > I don't think anyone is trying to link privacy to what's on port 43 > (whois to most of us). The goal isn't to tie privacy to any > publication mechanism. This is done with the intent that during the > phase of reaching towards DS, we will have more tools for dealing > with privacy. Features are more easily removed from PS to DS than > added. This is where the non-technical bit lives. Let's go back: > >I'm not convinced that the issue of contention is technical. Just how complex is "privacy"? Is it a property that a tag is a useful mechanism to encode it? If "privacy" is simple, something that fits in a tag, then we have one technical issue. If "privacy" is not simple, then we have another technical issue. It is my sense that "privacy" is not simple. > >Enforcement is a whole different can of worms, unless this is just a > >techno-fiction. > > Enforcement is part of policy and we are making every effort to sidestep it. To avoid non-sensicalness however, an enforcable mechanism needs to be capable of violation detection. No spitting when I'm not looking is not impressive. > >Nope. Seems technically flawed to me, and worse than what we had. > > I don't see how. Cheers, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ONBDx9008644 for ; Tue, 25 Mar 2003 00:11:13 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ONBDPu008643 for ietf-provreg-outgoing; Tue, 25 Mar 2003 00:11:13 +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.8/8.12.8) with ESMTP id h2ONBBx9008638 for ; Tue, 25 Mar 2003 00:11:12 +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 SAA23241; Mon, 24 Mar 2003 18:11:03 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:11:07 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337088C@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] Our "Privacy Issue" Date: Mon, 24 Mar 2003 18:07:43 -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 > During the meeting, it was suggested that a mechanism to meet the > requirement has already been sent to the mailing list and discussed. > The next steps for the WG is to 1) consider and discuss the > requirement in this message. If the WG accepts this as the problem > statement as discussion in the room did, the next step will be to > open a thread on the modified proposal suggested. For procedural > reasons, I'm not going to mention that proposal until the problem > statement is accepted by the WG (i.e., the mailing list). I accept the problem statement as described. It reflects what I heard in the room last Thursday. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ON4gx9008530 for ; Tue, 25 Mar 2003 00:04:42 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ON4gVj008529 for ietf-provreg-outgoing; Tue, 25 Mar 2003 00:04:42 +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.8/8.12.8) with ESMTP id h2ON4fx9008524 for ; Tue, 25 Mar 2003 00:04:41 +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 SAA22932; Mon, 24 Mar 2003 18:04:33 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:04:37 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337088B@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Joe Abley'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] References for Today's Host Object Discussion Date: Mon, 24 Mar 2003 18:01:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I wonder whether it might be reasonable to accommodate the > non-host-object case in the current spec before it is shipped for > proposed standard. This doesn't seem like it would be a major > change to > the text, and the impact on existing implementations seems > small (zero, > maybe) considering that the spec would not change for > registries which > choose to include host objects. I'm not one of the people responsible for determining consensus, but I can say that the domain document has completed both WG and IETF last calls with the currently specified feature set. Our chairs can, of course, direct me to change something if WG consensus is to make a change. I'd prefer to keep things as-is, though, because this is _not_ a new argument and we'll have a chance to address this again when considering what to do when going from proposed to draft. One of the things I intend to do once we're there is capture the outstanding issues in an I-D that can be used to seed the proposed-to-draft discussion. It would be helpful if people who have issues with any current features could send me a note (off-list is OK) describing what they don't like _and_ a suggested solution. We might then have the start of a pretty good problem statement for EPP 1.1 or 2.0. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OLMNx9007343 for ; Mon, 24 Mar 2003 22:22:23 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OLMNDd007342 for ietf-provreg-outgoing; Mon, 24 Mar 2003 22:22:23 +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.8/8.12.8) with ESMTP id h2OLMLx9007337 for ; Mon, 24 Mar 2003 22:22:21 +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 h2OLMI34095925; Mon, 24 Mar 2003 16:22:18 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.46]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA00630; Mon, 24 Mar 2003 16:22:15 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200303241644.h2OGilGL062506@nic-naa.net> References: <200303241644.h2OGilGL062506@nic-naa.net> Date: Mon, 24 Mar 2003 16:21:09 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Our "Privacy Issue" Cc: Edward Lewis , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:44 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote: >I'm not convinced that the issue of contention is technical. Then I've failed in my description of the problem. As we sit, EPP requires the registrar to make decisions on whether the submission of a piece of data will be accorded the proper handling with regards to privacy. The issue is that EPP forces the registrar into this posture, there is no choice. What the IESG has asked of us is to make EPP possible to support a scenario in which a registrar gives the data and policy request to the registry and then let the registry decide what to do. Furthermore, a basic framework for this is desired to be part of the base protocol. The IESG is doing this through the role of protocol design engineer review - recognizing functionality that oughta be in a protocol but isn't. >The registry announces a session-policy. Implementors are free >to evaluate the registry-announced policy, and implement local policy, >e.g., accept the policy and propogate policied data, or decline. But the only option available to users of the client is to decide whether or not to make the registration. We want more of an option than that. >To me, it _was_ just distributed read and write access mechanisms to >shared store, with a specific syntax. If someone claims read-on-43 >exhaustively defines "privacy", I don't care. It doesn't exhaustively >define _read_. I don't think anyone is trying to link privacy to what's on port 43 (whois to most of us). The goal isn't to tie privacy to any publication mechanism. This is done with the intent that during the phase of reaching towards DS, we will have more tools for dealing with privacy. Features are more easily removed from PS to DS than added. >Enforcement is a whole different can of worms, unless this is just a >techno-fiction. Enforcement is part of policy and we are making every effort to sidestep it. >Nope. Seems technically flawed to me, and worse than what we had. I don't see how. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OGkpx9003774 for ; Mon, 24 Mar 2003 17:46:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OGkpbn003773 for ietf-provreg-outgoing; Mon, 24 Mar 2003 17:46:51 +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.8/8.12.8) with ESMTP id h2OGkox9003768 for ; Mon, 24 Mar 2003 17:46:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2OGilGL062506; Mon, 24 Mar 2003 11:44:47 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303241644.h2OGilGL062506@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] Our "Privacy Issue" In-Reply-To: Your message of "Sun, 23 Mar 2003 15:23:13 EST." Date: Mon, 24 Mar 2003 11:44:47 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk ... > The protocol must provide a mechanism to allow enforcement OK. We blew it semantically in the grrq when we stated the req as a mechanism to announce. > of privacy > policy at either the registrar or registrant. OK. We blew it semantically in the grrq when we limited the protocol to registrars and registries. > This must be done in a > protocol feature that is "mandatory to implement, optional to use." No comment. > Further, the privacy meta-data must be to individual elements of > social data. OK. We blew it syntactically by reference to an inextensible type. > ... this is what we need to solve ... I disagree with the claim that any IETF WG needs to be responsive to the IESG. The claim only begins to approximate "true" iff the WG wants IESG approval of its work-product. I'm not convinced that the issue of contention is technical. > As EPP stands now, privacy policy decisions are only possible at the > registrar. This is because the dcp element allows the registry to > tell the registrar the "rules." Whatever the registrar sends to the > registry is considered to be in accordance with the rules. Correct. The registry announces a session-policy. Implementors are free to evaluate the registry-announced policy, and implement local policy, e.g., accept the policy and propogate policied data, or decline. > What is desired is a mechanism that will let EPP support thick > registries, in which social data is held by the registry. Umm, this _is_ the current model, neh? > In such > situations, the registrar needs to inform the registry of > restrictions on the redistribution of the data submitted to the > registry. This does not follow. Where state is persistent is a different issue from how may access to that persistent state be implemented. Just to test the correctness of this reasoning however, if there did exist a mechanism for a client to select from a menu of policies in a (this begins to look like beep and the srv record), and the menu offered by a registry was _in_theory_exhaustive_, would the registrar need to do anything more exciting than pick a policy out of the extended hat? > There's one protocol standards consideration I'd like to make. The > more detail and depth in the solution of a problem often leads to a > tougher job in reaching consensus. I.e., as a chair, I appreciate > efforts to refine and divine the depths of privacy, but such threads > are in danger of becoming distractions to the main job of this WG. I'll be _happy_ to leave the problem to more capable hands than my own. To me, it _was_ just distributed read and write access mechanisms to shared store, with a specific syntax. If someone claims read-on-43 exhaustively defines "privacy", I don't care. It doesn't exhaustively define _read_. Enforcement is a whole different can of worms, unless this is just a techno-fiction. > For procedural > reasons, I'm not going to mention that proposal until the problem > statement is accepted by the WG (i.e., the mailing list). Nope. Seems technically flawed to me, and worse than what we had. YMMV. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OEW1x9002096 for ; Mon, 24 Mar 2003 15:32:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OEW1Xm002095 for ietf-provreg-outgoing; Mon, 24 Mar 2003 15:32:01 +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.8/8.12.8) with ESMTP id h2OEVvx9002090 for ; Mon, 24 Mar 2003 15:31:59 +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 h2OEVv34079001; Mon, 24 Mar 2003 09:31:57 -0500 (EST) Received: from [192.149.252.108] ([192.136.136.46]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA13844; Mon, 24 Mar 2003 09:31:56 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: Date: Sun, 23 Mar 2003 15:23:13 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] Our "Privacy Issue" Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk During the face to face meeting in SF, we had a productive discussion of the privacy issue that has been holding up progress. Minutes, et.al. of the meeting will be forthcoming, but the first action item to arise from the meeting is a presentation to the WG (list) a detailed description of the problem. In a discussion that involved Ted Hardie, our new Area Advisor, and Randy Bush, the following comment was cast into the following requirement: The protocol must provide a mechanism to allow enforcement of privacy policy at either the registrar or registrant. This must be done in a protocol feature that is "mandatory to implement, optional to use." Further, the privacy meta-data must be to individual elements of social data. First, before going further, what is stated above is the suggestion derived during the face-to-face meeting. Being that this is a clarification of the IESG comment obtained with representatives present, this is what we need to solve. However, wording changes may be made. As EPP stands now, privacy policy decisions are only possible at the registrar. This is because the dcp element allows the registry to tell the registrar the "rules." Whatever the registrar sends to the registry is considered to be in accordance with the rules. What is desired is a mechanism that will let EPP support thick registries, in which social data is held by the registry. In such situations, the registrar needs to inform the registry of restrictions on the redistribution of the data submitted to the registry. There are limits to what the WG is being asked to do. We are not being asked to provide a very rich syntax for the mechanism. For example, we are not being asked to provide a means to say "you can publish the phone number in whois but not in any other way." (We could, if we desired, but we are not asked to do.) There's one protocol standards consideration I'd like to make. The more detail and depth in the solution of a problem often leads to a tougher job in reaching consensus. I.e., as a chair, I appreciate efforts to refine and divine the depths of privacy, but such threads are in danger of becoming distractions to the main job of this WG. During the meeting, it was suggested that a mechanism to meet the requirement has already been sent to the mailing list and discussed. The next steps for the WG is to 1) consider and discuss the requirement in this message. If the WG accepts this as the problem statement as discussion in the room did, the next step will be to open a thread on the modified proposal suggested. For procedural reasons, I'm not going to mention that proposal until the problem statement is accepted by the WG (i.e., the mailing list). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ODudx9001663 for ; Mon, 24 Mar 2003 14:56:39 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ODud1s001662 for ietf-provreg-outgoing; Mon, 24 Mar 2003 14:56:39 +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.8/8.12.8) with ESMTP id h2ODubx9001657 for ; Mon, 24 Mar 2003 14:56:38 +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 IAA12141 for ; Mon, 24 Mar 2003 08:56:30 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 08:53:20 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370882@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt Date: Mon, 24 Mar 2003 08:53:18 -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 Aww, phooey. This is the document that was edited based on our most recent miscommunication with the IESG; the response I received from the I-D administrator said it would NOT be retained when I sent it after the submission deadline had passed. As discussed during IETF-56, I didn't send it in again. It's going to have to be edited again once we get the privacy topics discussed during the IETF meeting out on the list for open discussion (hint, hint). -Scott- > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, March 24, 2003 7:26 AM > To: IETF-Announce; @cafax.se > Cc: ietf-provreg@cafax.se > Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Provisioning Registry > Protocol Working Group of the IETF. > > Title : Extensible Provisioning Protocol > Author(s) : S. Hollenbeck > Filename : draft-ietf-provreg-epp-09.txt > Pages : 75 > Date : 2003-3-21 > > This document describes an application layer client-server protocol > for the provisioning and management of objects stored in a shared > central repository. Specified in XML, the protocol defines generic > object management operations and an extensible framework that maps > protocol operations to objects. This document includes a protocol > specification, an object mapping template, and an XML media type > registration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OCS5x9000747 for ; Mon, 24 Mar 2003 13:28:05 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2OCS5Ah000746 for ietf-provreg-outgoing; Mon, 24 Mar 2003 13:28:05 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2OCS3x9000741 for ; Mon, 24 Mar 2003 13:28:04 +0100 (MET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12201; Mon, 24 Mar 2003 07:25:44 -0500 (EST) Message-Id: <200303241225.HAA12201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt Date: Mon, 24 Mar 2003 07:25:43 -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-09.txt Pages : 75 Date : 2003-3-21 This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-epp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-epp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-21155106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-21155106.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2O5xax9027729 for ; Mon, 24 Mar 2003 06:59:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2O5xaoi027728 for ietf-provreg-outgoing; Mon, 24 Mar 2003 06:59:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from goose.automagic.org (goose.automagic.org [199.212.90.4]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2O5xYx9027723 for ; Mon, 24 Mar 2003 06:59:34 +0100 (MET) Received: from isc.org (dhcp-k-1.automagic.org [199.212.90.17]) by goose.automagic.org (Postfix) with ESMTP id A81C63541D; Mon, 24 Mar 2003 00:59:30 -0500 (EST) Date: Mon, 24 Mar 2003 00:59:39 -0500 Subject: Re: [ietf-provreg] References for Today's Host Object Discussion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'ietf-provreg@cafax.se'" To: "Hollenbeck, Scott" From: Joe Abley In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD603370873@vsvapostal3.prod.netsol.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thursday, Mar 20, 2003, at 15:39 Canada/Eastern, Hollenbeck, Scott wrote: > - Allowing a choice between name server host objects and name server > domain > attributes. > http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html > > I've included references to the list archives where I've been able to > find > them. What did we ever do before google came along... > > For what it's worth, I kind of like the last option (or something like > it) > as something to consider for the next version of the protocol. We've > heard > a lot of comments from people having issues with host objects as name > servers; maybe we can eliminate the issues if we allow a choice. Thanks for posting that link; I have been hearing similar comments for some time, and I hadn't realised the issue had already been considered. Eliminating the requirement to support host objects would make EPP a viable prospect for several registries that I have talked to recently. I wonder whether it might be reasonable to accommodate the non-host-object case in the current spec before it is shipped for proposed standard. This doesn't seem like it would be a major change to the text, and the impact on existing implementations seems small (zero, maybe) considering that the spec would not change for registries which choose to include host objects. I would be happy to contribute text if this sounds like a reasonable approach. Joe Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2LFr9x9003814 for ; Fri, 21 Mar 2003 16:53:09 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2LFr8C9003812 for ietf-provreg-outgoing; Fri, 21 Mar 2003 16:53:08 +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.8/8.12.8) with ESMTP id h2LFqrx9003795 for ; Fri, 21 Mar 2003 16:52:55 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2LFpTGL035078; Fri, 21 Mar 2003 10:51:29 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303211551.h2LFpTGL035078@nic-naa.net> To: Randy Bush cc: Eric Brunner-Williams in Portland Maine , "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:45:56 PST." Date: Fri, 21 Mar 2003 10:51:29 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Randy, and anyone else with a view, > a privacy tag, ... > ... > ... it's the privacy semantics which ran aground. In the abstract, there exists at least two distinct values that an algorithmic evaluation of a variable may yeild. Ignoring everything else, is the IESG's guidance on this subject, that the set of values for which any algorithmic evaluation of a privacy tag is exactly two? If it is not exactly two, what is the exact characterization of the value space? Thanks in advance, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2LFr9x9003813 for ; Fri, 21 Mar 2003 16:53:09 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2LFr8Wn003811 for ietf-provreg-outgoing; Fri, 21 Mar 2003 16:53:08 +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.8/8.12.8) with ESMTP id h2LFqsx9003796 for ; Fri, 21 Mar 2003 16:52:55 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2LFpXGL035081; Fri, 21 Mar 2003 10:51:33 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303211551.h2LFpXGL035081@nic-naa.net> To: Randy Bush cc: Eric Brunner-Williams in Portland Maine , "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:45:56 PST." Date: Fri, 21 Mar 2003 10:51:33 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Randy, and anyone else with a view, > once again, data structures 101 sez that each attribute would have > a privacy tag, as opposed to a blob of tags at the front. In the abstract, there exists at least one type definition hierarchy. At least one hierarchy is non-degenerate, and the "primitive" and "constructed" model of derivation exists. Ignoring everything else, is the IESG's guidance on this subject, that the type definition hierarchies contained in the EPP spec, fundamentally err by reference to a built-in derived type, or to a primitive type? Thanks in advance, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2KM1ox9024338 for ; Thu, 20 Mar 2003 23:01:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2KM1ot1024337 for ietf-provreg-outgoing; Thu, 20 Mar 2003 23:01: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.8/8.12.8) with ESMTP id h2KM1jx9024332 for ; Thu, 20 Mar 2003 23:01:47 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2KM0XGL031807; Thu, 20 Mar 2003 17:00:33 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303202200.h2KM0XGL031807@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Thu, 20 Mar 2003 11:57:05 EST." <059001c2ef18$dec03ff0$7e8a8182@neteka.inc> Date: Thu, 20 Mar 2003 17:00:33 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > So you see this as a field query mechanism. Fine. > > > > > ... it just allows the registry to annouce its policies ... > > > > "Which fields are manditory to fill in?" > > No. This will result in a failure to create, not a successful response. My point was, you've designed a query mechanism, and what looks like a two command sequence. > > is different from > > "What is done with data provisioned?" > > Yes. This is the intent. Public means that the info will be published to > the WHOIS, and Private means that it will be hidden. The current mechanism > is this simple. Well, not-via-:43 is clear. "private" and "public" are terms of art that resist unambiguous specification. > > or less the same session, you've not solved for the day when policies do > > in fact change. > > So you are saying that the server should perhaps queue a msg for the client > if policies are to be changed?... or something in-band to announce to the > clients? I point out that there is a temporal property contained in the , that the retention period of the data (and the policies announced when the server announces its availability to collect data) is known to the client (along with anything else that might be in a , prior to the client submitting data to the server. > > But you thought that through, and decided that the temporal properties of > > polices is better communicated out-of-band, so they could in fact change > > without in-band notice. > > Just thought it seems to make a bit more sense in a practical environment. > For example, when I look at a ccTLD, they will be putting out a public > statement or even consultation paper or something before they change their > policies, Sense? Practicality? Taste varies. I'd like to automate privacy/datacollection handling in registration systems. > > If the temporal properties of policies are better communicated > out-of-band, > > why are the semantic properties of policies better communicated in-band? > > Because of 2 things: > > 1. the client needs to know what (which info item) exactly they can manage > (public/private) > 2. they can toggle public/private on the aspects that are allowed to be > optional But with no guarantee that the policies will be consistent between any two consequtive registrations. > > Your proposal makes no reliance upon any policy information from the > > registry. You've proposed a momentary capabilities check arising from > > a command, but you only get the data in the response. > > So perhaps it is good to extend the check command as well to return the > policy statements so that clients will know what they are getting into > beforehand... Back to the two-step. Familiar to registrars who want to know if a of "somewellknownname" will fail, before attempting it. . Not significantly different from (and optionally, if disapointed, ). > > Its a hell of a lot easier to simply have the server announce its policy, > > and if a mechanism is necessary to select some set of values from some > > range of values (and I'm referring to purpose, recipient, retention and > > so forth, as well as which field in the contact object is optional), to > > get on with its specification, than finding it after assuming it even > > exists. > > dcp should be good to deal with the purpose and stuff. My proposal aims to > make an effort to allow granular management of information privacy. We > could extend the tags so that each facet can be further optionally bound by > multiple policies based on the usage of data. Also, I think you are right, > perhaps the info response should be a bit different and allow the client to > query for only the privacy policy elements and not return the entire glob > everytime. I will make that change. . Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2KKgIx9023326 for ; Thu, 20 Mar 2003 21:42:18 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2KKgI38023325 for ietf-provreg-outgoing; Thu, 20 Mar 2003 21:42:18 +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.8/8.12.8) with ESMTP id h2KKgGx9023320 for ; Thu, 20 Mar 2003 21:42:16 +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 PAA01292 for ; Thu, 20 Mar 2003 15:42:09 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 15:39:14 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370873@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: [ietf-provreg] References for Today's Host Object Discussion Date: Thu, 20 Mar 2003 15:39:13 -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 After today's meeting some people asked me for a reference to an earlier discussion about host objects being used as name servers. For those of you who weren't there, we talked a little bit about the history of why we have an object concept for name server hosts. Part of the ensuing discussion touched on all of the options that have been discussed over the last few years, including: - Host objects for all name servers. (This is a simplified expression of what we have in the documents now) - Host objects for only in-zone hosts, with external hosts specified as domain object attributes. http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00008.html - Allowing a choice between name server host objects and name server domain attributes. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html I've included references to the list archives where I've been able to find them. What did we ever do before google came along... For what it's worth, I kind of like the last option (or something like it) as something to consider for the next version of the protocol. We've heard a lot of comments from people having issues with host objects as name servers; maybe we can eliminate the issues if we allow a choice. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2KJhax9022679 for ; Thu, 20 Mar 2003 20:43:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2KJha5F022678 for ietf-provreg-outgoing; Thu, 20 Mar 2003 20:43:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2KJhWx9022673 for ; Thu, 20 Mar 2003 20:43:34 +0100 (MET) Message-ID: <059001c2ef18$dec03ff0$7e8a8182@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , References: <200303200507.h2K57oGL028531@nic-naa.net> Subject: Re: [ietf-provreg] provreg's privacy issue Date: Thu, 20 Mar 2003 11:57:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Eric, ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" > I'll send you what I did to de-xml-ize p3p policies on cookies, where overhead > did matter. Here however, overhead shouldn't. But don't optimize too early ... That will be great. Yeah, we were thinking that we should maintain flexibility first and then optimize later (in fact, our actual implementation is much leaner... but because this was intended to be a protocol discussion, we made it a bit more extensible. and thus, larger overhead. > > I do not understand why it does not apply to the WHOIS... > > It does, but there are some loopholes. > > > ... from the response I will know which contact info I will > > need to disclose and which ones will be hidden and which ones I can > > later optionally opt-in or out ... > > So you see this as a field query mechanism. Fine. > > > ... it just allows the registry to annouce its policies ... > > "Which fields are manditory to fill in?" No. This will result in a failure to create, not a successful response. > is different from > "What is done with data provisioned?" Yes. This is the intent. Public means that the info will be published to the WHOIS, and Private means that it will be hidden. The current mechanism is this simple. > Yes I do. To be concrete, domains are sold by the COM/NET registry to a set > of registrars, for periods of up to 10 years. What are the temporal properties > of policy guarantees? If you assume a place-holder create, followed by the > "real" create, more or less in the same session, or a real create, followed > by a series of updates to "tune" the privacy policy to taste, again in more > or less the same session, you've not solved for the day when policies do in > fact change. So you are saying that the server should perhaps queue a msg for the client if policies are to be changed?... or something in-band to announce to the clients? > But you thought that through, and decided that the temporal properties of > polices is better communicated out-of-band, so they could in fact change > without in-band notice. Just thought it seems to make a bit more sense in a practical environment. For example, when I look at a ccTLD, they will be putting out a public statement or even consultation paper or something before they change their policies, > If the temporal properties of policies are better communicated out-of-band, > why are the semantic properties of policies better communicated in-band? Because of 2 things: 1. the client needs to know what (which info item) exactly they can manage (public/private) 2. they can toggle public/private on the aspects that are allowed to be optional > Your proposal makes no reliance upon any policy information from the > registry. You've proposed a momentary capabilities check arising from > a command, but you only get the data in the response. So perhaps it is good to extend the check command as well to return the policy statements so that clients will know what they are getting into beforehand... > Its a hell of a lot easier to simply have the server announce its policy, > and if a mechanism is necessary to select some set of values from some > range of values (and I'm referring to purpose, recipient, retention and > so forth, as well as which field in the contact object is optional), to > get on with its specification, than finding it after assuming it even > exists. dcp should be good to deal with the purpose and stuff. My proposal aims to make an effort to allow granular management of information privacy. We could extend the tags so that each facet can be further optionally bound by multiple policies based on the usage of data. Also, I think you are right, perhaps the info response should be a bit different and allow the client to query for only the privacy policy elements and not return the entire glob everytime. I will make that change. Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2K58px9014580 for ; Thu, 20 Mar 2003 06:08:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2K58p8I014579 for ietf-provreg-outgoing; Thu, 20 Mar 2003 06:08:51 +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.8/8.12.8) with ESMTP id h2K58nx9014574 for ; Thu, 20 Mar 2003 06:08:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2K57oGL028531; Thu, 20 Mar 2003 00:07:50 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303200507.h2K57oGL028531@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 21:30:35 EST." <043301c2ee88$b243dcb0$7e8a8182@neteka.inc> Date: Thu, 20 Mar 2003 00:07:50 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Good to hear that you have read my stuff. :-) No one reads mine, so I'll stop writing it and read yours, its the worst I can do ;-) > It is a bit bulky right now. I'll send you what I did to de-xml-ize p3p policies on cookies, where overhead did matter. Here however, overhead shouldn't. But don't optimize too early ... > > o a bi-di glob on !!! > > bi-di glob??... what do you mean? On both command and response. This is where the action is. Who cares if the server and responses have new glop? What counts is if by a write (here ) against the shared store (here registry) manages to either fail to error (glop accepted by registry as some policy description, considered by registry to be "valid"), or can generate a change in the glop that comes back in any response. If none, then either the registry had the "right" policy already, or ignored the attempted policing of data previously provisioned in the client (and nominally annotated in the new glop in the repsponse). > I do not understand why it does not apply to the WHOIS... It does, but there are some loopholes. > ... from the response I will know which contact info I will > need to disclose and which ones will be hidden and which ones I can > later optionally opt-in or out ... So you see this as a field query mechanism. Fine. > ... it just allows the registry to annouce its policies ... "Which fields are manditory to fill in?" is different from "What is done with data provisioned?" > What do you mean? Do you mean that the registry advertises that the client > may choose to make phone# private yet not allow it to change the status to > private? If so, then the registry system is broken... > >> Now what happens? > > If the registry nacks the status=private operation later because of change > of policy, then there should be probably be out-of-band communication to > announce to all users, also, the client can always do a domain info to check > the status and current registry policy for each info item. Yes I do. To be concrete, domains are sold by the COM/NET registry to a set of registrars, for periods of up to 10 years. What are the temporal properties of policy guarantees? If you assume a place-holder create, followed by the "real" create, more or less in the same session, or a real create, followed by a series of updates to "tune" the privacy policy to taste, again in more or less the same session, you've not solved for the day when policies do in fact change. But you thought that through, and decided that the temporal properties of polices is better communicated out-of-band, so they could in fact change without in-band notice. If the temporal properties of policies are better communicated out-of-band, why are the semantic properties of policies better communicated in-band? > > Why "discover" access policy _after_ a committing a write? > > Please clarify what you mean? Your proposal makes no reliance upon any policy information from the registry. You've proposed a momentary capabilities check arising from a command, but you only get the data in the response. Therefore, either each command is preceeded by some command who's side effect is to discover the present policy, or each command is followed by a series of one or more commands to conform the policy (applicable to some specific object) at the server to the policy goal held by the client. Its a hell of a lot easier to simply have the server announce its policy, and if a mechanism is necessary to select some set of values from some range of values (and I'm referring to purpose, recipient, retention and so forth, as well as which field in the contact object is optional), to get on with its specification, than finding it after assuming it even exists. Eric P.S. Get rid of everything except the glop. , , test response, repeat until correct, or failure. Upon failure, issue . If fails, issue with the personal data of the registry CEO, or the current ICANN CEO, depending on one's sense of humor. P.P.S. This only solves for WHOIS, not for any other purpose, mechanism, or period, to which provisioned data may be used without prior disclosure and informed consent, or at least the opportunity to form same, buy the registrar, and presumbly the parties it acts on behalf of. P.P.P.S. Cheers! Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2K2VHx9013497 for ; Thu, 20 Mar 2003 03:31:17 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2K2VH9l013496 for ietf-provreg-outgoing; Thu, 20 Mar 2003 03:31:17 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2K2VFx9013491 for ; Thu, 20 Mar 2003 03:31:16 +0100 (MET) Message-ID: <043301c2ee88$b243dcb0$7e8a8182@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: References: <200303192339.h2JNd8GL024538@nic-naa.net> Subject: Re: [ietf-provreg] provreg's privacy issue Date: Wed, 19 Mar 2003 21:30:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Eric, Good to hear that you have read my stuff. :-) ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To > Some text, on this list, before going off into the delirium of boiler-plate, > would have been a blessing, neh? This reflects some of the things we have done for a particular client. I saw some discussion in the group earlier about possibly having an extension and a public/private toggle type thinking and thought this could be a starting point. > I see ... > o a glob going from registry to registrar (don't tell the iesg), > o a glob on response, approximately 1k in size, It is a bit bulky right now. but really it is whether this concept is good that is the discussion... we could make it a bit more efficient, but will loose some flexibility. We could make it much more efficient if we could incorporated it directly into domain mapping... > o a glob on response, ditto, > o a bi-di glob on !!! bi-di glob??... what do you mean? > I see ... > o two hooks parked at the IANA to hang some coats on, fine. Ok. Will take these away in the submission. I was just doing a plain copy and "search and replace". :-) > Not only does this NOT do what our Masters in Moscow, the IESG, require, > (the glob goes in the wrong direction), the scope of the extension, as > it is from registry to registrar, cannot apply to any instance of WHOIS > operated by the registry. I do not understand why it does not apply to the WHOIS... if the info is deemed to be "public" it is published, if it is "private" it is not published at the WHOIS. > registrar_N (Neteka) initiates a session with registry_V, > > registry_V ships back a that says 95/46/EC applies > and all data is not repurposed, there are no recipients > other than the registry, that it retains the data only > for the period of registration, plus some operational window > for the purpose of renewal, and ... everything is _private_ > (except publication via 1034/35). > > What data collection / privacy problem remains (that your proposal > cleverly solves)? While I am not familiar with 95/46/EC, I think at the least, from the response I will know which contact info I will need to disclose and which ones will be hidden and which ones I can later optionally opt-in or out. I dont think it "cleverly" solves anything, it just allows the registry to annouce its policies as well as the client to specify its preferences. > registrar_N (Neteka) initiates a session with registry_V, > > registry_V ships back a that says says anything you want, > even no at all, > > registrar_N does a create for mumble, > registry_V acks appropriately > > registrar_N ships an update on mumble that attempts to set a bit, > e.g., don't publish phone #, provisioned in the prior op, > > registry_V nacks inappropriately, and in bad taste. What do you mean? Do you mean that the registry advertises that the client may choose to make phone# private yet not allow it to change the status to private? If so, then the registry system is broken... > Now what happens? If the registry nacks the status=private operation later because of change of policy, then there should be probably be out-of-band communication to announce to all users, also, the client can always do a domain info to check the status and current registry policy for each info item. > Why "discover" access policy _after_ a committing a write? Please clarify what you mean? Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2K0Hnx9011465 for ; Thu, 20 Mar 2003 01:17:49 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2K0Hn0P011464 for ietf-provreg-outgoing; Thu, 20 Mar 2003 01:17:49 +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.8/8.12.8) with ESMTP id h2K0Hcx9011459 for ; Thu, 20 Mar 2003 01:17:38 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2K0HUT1043580 for ; Thu, 20 Mar 2003 01:17:30 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2K0HTDY043579 for ietf-provreg@cafax.se; Thu, 20 Mar 2003 01:17:29 +0100 (CET) Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNk0x9011029 for ; Thu, 20 Mar 2003 00:46:01 +0100 (MET) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18vnFv-000Oaz-00; Wed, 19 Mar 2003 15:45:59 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18vnFu-0000ET-00; Wed, 19 Mar 2003 15:45:58 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 19 Mar 2003 15:45:56 -0800 To: Eric Brunner-Williams in Portland Maine Cc: "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com Subject: Re: [ietf-provreg] provreg's privacy issue References: <038301c2ee5a$865c79f0$7e8a8182@neteka.inc> <200303192339.h2JNd8GL024538@nic-naa.net> Message-Id: Sender: owner-ietf-provreg@cafax.se Precedence: bulk > o a BEGIN END section of formal syntax with very, very little text > seperating these delimeters (don't worry, we haven't gotten even > a syntax clue from the IESG), this is quite incorrect, you just didn't like it. once again, data structures 101 sez that each attribute would have a privacy tag, as opposed to a blob of tags at the front. but, as far as i am aware, no one on the iesg cares that much about the syntax, it's the privacy semantics which ran aground. randy Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNsKx9011190 for ; Thu, 20 Mar 2003 00:54:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNsKPN011189 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:54:20 +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.8/8.12.8) with ESMTP id h2JNs9x9011183 for ; Thu, 20 Mar 2003 00:54:09 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JNrBGL024595; Wed, 19 Mar 2003 18:53:11 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303192353.h2JNrBGL024595@nic-naa.net> To: Randy Bush cc: Eric Brunner-Williams in Portland Maine , "Edmon Chung" , paf@cisco.com, "Ted Hardie" , "Ned Freed" , "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:45:56 PST." Date: Wed, 19 Mar 2003 18:53:11 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > this is quite incorrect, you just didn't like it. Am I that shallow? Well, a pointer to the item with a substantive proposal would be nice. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNkKx9011050 for ; Thu, 20 Mar 2003 00:46:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNkKsm011049 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:46:20 +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.8/8.12.8) with ESMTP id h2JNkJx9011044 for ; Thu, 20 Mar 2003 00:46:19 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JNjMGL024573; Wed, 19 Mar 2003 18:45:22 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303192345.h2JNjMGL024573@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, iesg@ietf.org, brunner@nic-naa.net Subject: Re: [ietf-provreg] EPP, data, actors, and access In-Reply-To: Your message of "Wed, 19 Mar 2003 14:54:03 PST." Date: Wed, 19 Mar 2003 18:45:22 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, A quick reply, between kidz on my end, and distractions on yours. > Let's do this as a first order approximation - is it possible to > specify whether a data item (call it what you will) is not allowed to > be repeated by the registry to any one other than the registrar that > submitted it? Is this something that is common enough to be > understood by all? Is this potentially sufficient to satisfy all > people's needs here? The registry can assert that this is its policy via the . Where the value is in having the registrar attempt to bind such a policy to a data item (I'm partial to mumbles and globs), rather than having a policy bound to the mumble or glob by the registry is possibly an article of religious faith. I've written why the converse is true, possibly in moments of religious euphoria. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNeTx9011000 for ; Thu, 20 Mar 2003 00:40:29 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNeT6X010999 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:40:29 +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.8/8.12.8) with ESMTP id h2JNeIx9010994 for ; Thu, 20 Mar 2003 00:40:18 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JNd8GL024538; Wed, 19 Mar 2003 18:39:08 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303192339.h2JNd8GL024538@nic-naa.net> To: "Edmon Chung" cc: paf@cisco.com, "Ted Hardie" , "Ned Freed" , randy@psg.com, "Edward Lewis" , ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] provreg's privacy issue In-Reply-To: Your message of "Wed, 19 Mar 2003 15:59:57 EST." <038301c2ee5a$865c79f0$7e8a8182@neteka.inc> Date: Wed, 19 Mar 2003 18:39:08 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edmon, Henry, Some text, on this list, before going off into the delirium of boiler-plate, would have been a blessing, neh? I see ... o a glob going from registry to registrar (don't tell the iesg), o a glob on response, approximately 1k in size, o a glob on response, ditto, o a bi-di glob on !!! I see ... o a BEGIN END section of formal syntax with very, very little text seperating these delimeters (don't worry, we haven't gotten even a syntax clue from the IESG), I see ... o a totally irrelevent i18n section, but I understand, this is one of Neteka's sweet spots (besides, the IESG will surely appreciate the suggestion that XML will melt if "private parts" is written in Chinese, and the Chinese characters encoded in Big5), I see ... o two hooks parked at the IANA to hang some coats on, fine. So, the inference from the examples is that the syntax is a restatement of a big bit of the contact object, putting a binary, or enumerated set of value against each element -- sort of pervasive, but restricted to the contact object, attributes (but as an additional carried along "shadow" of the original, unencumbered contact object. Not only does this NOT do what our Masters in Moscow, the IESG, require, (the glob goes in the wrong direction), the scope of the extension, as it is from registry to registrar, cannot apply to any instance of WHOIS operated by the registry. Here's my you-pay-for-dinner question: registrar_N (Neteka) initiates a session with registry_V, registry_V ships back a that says 95/46/EC applies and all data is not repurposed, there are no recipients other than the registry, that it retains the data only for the period of registration, plus some operational window for the purpose of renewal, and ... everything is _private_ (except publication via 1034/35). What data collection / privacy problem remains (that your proposal cleverly solves)? Heck, lets go for two dinners, there are two of you anyway: registrar_N (Neteka) initiates a session with registry_V, registry_V ships back a that says says anything you want, even no at all, registrar_N does a create for mumble, registry_V acks appropriately registrar_N ships an update on mumble that attempts to set a bit, e.g., don't publish phone #, provisioned in the prior op, registry_V nacks inappropriately, and in bad taste. Now what happens? Why "discover" access policy _after_ a committing a write? There is an Americn idiom about closing a barn door _after_ the horses have left. I'm always lacking clue, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JNQDx9010805 for ; Thu, 20 Mar 2003 00:26:13 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNQDDj010804 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:26:13 +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.8/8.12.8) with ESMTP id h2JNQBx9010799 for ; Thu, 20 Mar 2003 00:26:12 +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 h2JNQBtW007509; Wed, 19 Mar 2003 18:26:11 -0500 (EST) Received: from [130.129.133.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA19385; Wed, 19 Mar 2003 18:26:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200303191335.h2JDZCGL022220@nic-naa.net> References: <200303191335.h2JDZCGL022220@nic-naa.net> Date: Wed, 19 Mar 2003 14:54:03 -0800 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] EPP, data, actors, and access Cc: ietf-provreg@cafax.se, iesg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 8:35 -0500 3/19/03, Eric Brunner-Williams in Portland Maine wrote: >Oki all, > >We have two distinct proposals for a specification of access, data, and >actors for EPP. External to EPP, but possibly relevant, is the existence >of WHOIS (954). You are expressing a very detailed understanding of the problem. One of the issues I have with being this detailed is that it makes the chance of consensus less likely to achieve. I can see the point that perhaps I want my telephone number to appear in WHOIS but not in DNS (to pick a perverse situation). Let's do this as a first order approximation - is it possible to specify whether a data item (call it what you will) is not allowed to be repeated by the registry to any one other than the registrar that submitted it? Is this something that is common enough to be understood by all? Is this potentially sufficient to satisfy all people's needs here? (Presuming the above meets with consensus, and then while sitting at proposed we discover that the mechanism is useless, dropping it or replacing it is always an option. At that time, we will be able to point to emperical evidence of the goodness/badness of it.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2JNQBx9010797 for ; Thu, 20 Mar 2003 00:26:11 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JNQB7B010796 for ietf-provreg-outgoing; Thu, 20 Mar 2003 00:26:11 +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.8/8.12.8) with ESMTP id h2JNQ9x9010791 for ; Thu, 20 Mar 2003 00:26:10 +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 h2JNQ8tW007506; Wed, 19 Mar 2003 18:26:08 -0500 (EST) Received: from [130.129.133.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA19377; Wed, 19 Mar 2003 18:26:06 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200303191906.h2JJ6PGL023423@nic-naa.net> References: <200303191906.h2JJ6PGL023423@nic-naa.net> Date: Wed, 19 Mar 2003 14:48:30 -0800 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] EPP, data, actors, and access Cc: Ted Hardie , ietf-provreg@cafax.se, iesg@ietf.org, brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:06 -0500 3/19/03, Eric Brunner-Williams in Portland Maine wrote: >Ted, > >> I think we have identified ways forward on this issue in this week ... > >I've no idea what this means. We (possibly a different value of "we") >thought we were getting consensus around a proposal ( manditory), >some time prior to this week, e.g., last week. We = some set of people. It's not important yet, what is important is whether or not the WG as a whole also agrees. Let's not worry about the source of the proposal, let's worry about the quality of the proposal. During the face to face meeting on Thursday, we will systemically not come to a conclusion. The best use of the time is as a "bull" session, to throw ideas back and forth for some amount of time (the amount given is a function of the relative usefulness of the conversation). At the end of the bull session, it will be the job of the chairs to prepare something to put in the list and to then begin the process of drafting an approach acceptable to the group as a whole. Consensus is not achieved by voting, but by arriving at a set of statements that are acceptable to (nearly) all with a stake - WG members, IESG, and the silent masses following this work. Let's put it this way, if we want to rent a car, if 80% of the WG wants to require a red one and the other 20% wants blue, we'll settle on wanting to just rent a car. >As to timing of meetings, I don't attend meetings held in belligerant states >during periods of belligerency. It is dangerous, it requires acts of active >cooperation with the security regimes of the belligerant state(s), and is >an endorsement of belligerency. I'd rather not. Absence is perfectly permissible, after all the IETF is a volunteer organization. The sentiment expressed is that it would have been keen to have you in attendance so that we could more quickly arrive at a common understanding of the problem. It is our fault if you feel the need to defend your choice not to travel. (I'm *not* going to define "our." ;)) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2JL1Ux9009015 for ; Wed, 19 Mar 2003 22:01:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JL1Utq009014 for ietf-provreg-outgoing; Wed, 19 Mar 2003 22:01:30 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2JL1Hx9009009 for ; Wed, 19 Mar 2003 22:01:18 +0100 (MET) Message-ID: <038301c2ee5a$865c79f0$7e8a8182@neteka.inc> From: "Edmon Chung" To: , "Ted Hardie" , "Ned Freed" , , "Edward Lewis" Cc: , References: Subject: Re: [ietf-provreg] provreg's privacy issue Date: Wed, 19 Mar 2003 15:59:57 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, ----- Original Message ----- From: "Edward Lewis" > In response to the IESG comment: > > why do domain/contact/.. not have granular information about privacy? > I am not sure if the draft that I am working on would help: http://ner2r.com/draft-ietf-provreg-epp-privacy-00.txt The document proposes an EPP extension to handle Domain Contact Privacy Profiles and is kept extremely flexible so that it should be able to adopt to registry mandated or client enforced/suggested privacy profiles. It basically describes a private/public toggle for as well as a way to announce registry policy on each attribute of each contact in a domain name. This is in fact something similar to what we have implemented for a client. Mainly for what contact info could/must be published through the WHOIS. One thing that this current draft has not addressed is if there needs to be different types of disclosure to different types of querying entities. But could be added by allowing multiple policies and to add a policy type attribute. Have to admit however that the bulk of the wordings in the document itself was stolen from Scott's enum draft. Well... I think Scott did a good job in providing a great template for EPP extension docs. :-) Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JJ7Kx9007589 for ; Wed, 19 Mar 2003 20:07:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JJ7KAS007588 for ietf-provreg-outgoing; Wed, 19 Mar 2003 20:07:20 +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.8/8.12.8) with ESMTP id h2JJ7Jx9007583 for ; Wed, 19 Mar 2003 20:07:19 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JJ6PGL023423; Wed, 19 Mar 2003 14:06:25 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303191906.h2JJ6PGL023423@nic-naa.net> To: Ted Hardie cc: ietf-provreg@cafax.se, iesg@ietf.org, brunner@nic-naa.net Subject: Re: [ietf-provreg] EPP, data, actors, and access In-Reply-To: Your message of "Wed, 19 Mar 2003 09:15:57 PST." <72DDE1EC-5A2E-11D7-9130-000393CB0816@qualcomm.com> Date: Wed, 19 Mar 2003 14:06:25 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ted, > I think we have identified ways forward on this issue in this week ... I've no idea what this means. We (possibly a different value of "we") thought we were getting consensus around a proposal ( manditory), some time prior to this week, e.g., last week. As to timing of meetings, I don't attend meetings held in belligerant states during periods of belligerency. It is dangerous, it requires acts of active cooperation with the security regimes of the belligerant state(s), and is an endorsement of belligerency. I'd rather not. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JI2Bx9006449 for ; Wed, 19 Mar 2003 19:02:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JI2Bhr006448 for ietf-provreg-outgoing; Wed, 19 Mar 2003 19:02:11 +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.8/8.12.8) with ESMTP id h2JI1px9006443 for ; Wed, 19 Mar 2003 19:01:51 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2JI1mT1041637 for ; Wed, 19 Mar 2003 19:01:48 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.8/8.12.6/Submit) id h2JI1llU041636 for ietf-provreg@cafax.se; Wed, 19 Mar 2003 19:01:47 +0100 (CET) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JHG7x9005989 for ; Wed, 19 Mar 2003 18:16:08 +0100 (MET) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2JHFxlb022659; Wed, 19 Mar 2003 09:16:00 -0800 (PST) Received: from qualcomm.com ([10.50.0.30]) by sabrina.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2JHFtOL020740; Wed, 19 Mar 2003 09:15:58 -0800 (PST) Date: Wed, 19 Mar 2003 09:15:57 -0800 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: [ietf-provreg] EPP, data, actors, and access From: Ted Hardie To: ietf-provreg@cafax.se, iesg@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <72DDE1EC-5A2E-11D7-9130-000393CB0816@qualcomm.com> X-Mailer: Apple Mail (2.551) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric, Sorry that you weren't able to make the San Francisco meeting as one of the real advantages our face-to-face meetings afford is the opportunity to get high bandwidth immediate response. I think we have identified ways forward on this issue in this week. Given the press of events during the week, they are not expressed in drafts; I'm sure they will be expressed in drafts as soon as we all have a chance. After the ProvReg meeting gets a sense of the room on the discussion, all of these conversations will be confirmed on the list, so you will have a chance to discuss them. As the incoming AD here, I am trying to catch up on all this as fast as I can; I appreciate the patience of the group as I work out what I can do to help us all make progress. regards, Ted Hardie Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2JDa7x9003807 for ; Wed, 19 Mar 2003 14:36:07 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2JDa7Ls003806 for ietf-provreg-outgoing; Wed, 19 Mar 2003 14:36: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.8/8.12.8) with ESMTP id h2JDa3x9003801 for ; Wed, 19 Mar 2003 14:36:06 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2JDZCGL022220; Wed, 19 Mar 2003 08:35:13 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303191335.h2JDZCGL022220@nic-naa.net> To: ietf-provreg@cafax.se, iesg@ietf.org Subject: [ietf-provreg] EPP, data, actors, and access Date: Wed, 19 Mar 2003 08:35:12 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Oki all, We have two distinct proposals for a specification of access, data, and actors for EPP. External to EPP, but possibly relevant, is the existence of WHOIS (954). One approach scopes some meta-data to sessions, within a connectionist, client-server model, with the server originating the meta-data. As a matter of syntax, this approach is extensible as to semantics associated with a session. One approach scopes some meta-data to data only, with the client originating the meta-data. The syntax for this approach is various, but two designs of note are an element (in the degenerate case, an attribute only) for some or all elements of data, and an element for each aggregation of data, e.g., the contact object, with some mapping to some or all elements of data within the aggregation. It is possible that if both a session-scoped mechanism, and a data-scoped mechanism are presented to a pair of EPP peers, neither being semantically null, that the peers will not correctly and interoperably evaluate the semantics of both mechanisms. This is made more likely if the evaluation-spaces of the two mechanisms are not identical, nor avail trivial forward and reverse mapping between nominally equivalent mechanism-specific representations. A design choice pioneered, at least within the PROVREG context, by one contributor, is to add a binary toggle, or a set of enumerated values, that allow some new semantic. As that contributor demonstrated, and as a subsequent implementations have shown, it is possible to add payload with a distinct syntactic form. See [1] for details. I mention this to acknowledge that a WHOIS-specific optimization is a possibility, that such a "hack" need not conform to the syntax of the current protocol, and that as an implementation matter, it is tractible. I add that such an optimization presents challenges for users who may seek to modify the optimization, or to obtain transparently equivalent transaction semantics, independent of EPP endpoint operator. One statement associated with client-origination is that it is actually registrant-origination. This presents two problems, the first theoretic, as EPP is between registrars and registries. The working group chose to create an interoperable protocol for data exchange between registrars and registries. Some other working group may be formed, if an interoperable protocol for data exchange between registrants and registrars is useful. The second problem is user-interface specification. Is the value-space of the new data binary? Is it an enumerated set? Is it an enumerated set of enumerated sets? Is it a tree with some branch ordering and evaluation property? Isn't this a discussion of what boxes, knobs, and sliders exist on a registrars registrant-facing data collection API? There are instances of UI specification within the IETF, but that is not in the PROVREG charter. I've written quite a bit over the past several months, critically, but as intelligently as I can manage, on what is referred to as "the IESG privacy proposal". I have no objective indication that any member of the IESG has read anything I've contributed to the PROVREG list. That's OK, this isn't some quest for emotional gratification. What puzzles me is the utter lack of substantive contribution, whether responsive to my writings, or those of anyone else, that moves beyond a gesture towards a requirements statement. Real requirements are intelligently discussed, unless they arise from kings, presidents, and voting. Real proposals are in the form of public drafts, eventually. Eric [1] draft-liu-epp-ustld-01.txt, expired. Author at liu@cis.umassd.edu. A copy may exist in the PROVREG list mail archive. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2ICr1x9018757 for ; Tue, 18 Mar 2003 13:53:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2ICr17p018756 for ietf-provreg-outgoing; Tue, 18 Mar 2003 13:53:01 +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.8/8.12.8) with ESMTP id h2ICqvx9018751 for ; Tue, 18 Mar 2003 13:53:00 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2ICqCGL016921; Tue, 18 Mar 2003 07:52:12 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303181252.h2ICqCGL016921@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, jaap@sidn.nl, Ted Hardie , paf@cisco.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] again with the privacy In-Reply-To: Your message of "Mon, 17 Mar 2003 21:13:34 PST." Date: Tue, 18 Mar 2003 07:52:12 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, A mechanism to disclose the operational practices and policies of operators of EPP servers with respect to "data collection", aka "privacy", is NOT a requirement, and section 8.4 of rfc 3375, in particular the final sentance of para 1, is incorrect. I can live with being responsible for that train wreck. Protocols developed under the imprimature of "the IETF", MUST NOT provide mechanism(s) to disclose the data collection policies, in particular, the polices to which data which identifies individual persons is subject, of operators of the protocols. Sounds grand and very Directorial. Instead "we're supposed to" come up with some dork that will allow the naive data we currently have, in the schema we currently have, with the syntax we currently have, to "twinkle", and to provision, not just any data collector, but only the registry operator, with this "twinkle" property, for each provisioned glob of data, and this whole waste of time is because 954 can't be moved to historic. I'll be sure and tell my registrar that I want only the octets-pairs that are prime when interpreted as Mayan digits (base 20) to be "published". I'm obviously in the wrong IETF. I'm in the one where clue is not held uniquely by management. The "IETF of Idiots". I do not see the point in bothering to pretend to write a specification that is in fact written by someone else. I'll just treat the eventual RFC as having no more "consensus engineering standards" value than an equal page count text that comes directly from Verisign. Implement it, and don't think too hard about it. I give up. I could use this time better playing with my kids, and making open, interoperable (but not IETF referencing) product. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2I5ffx9015427 for ; Tue, 18 Mar 2003 06:41:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2I5ffO5015426 for ietf-provreg-outgoing; Tue, 18 Mar 2003 06:41:41 +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.8/8.12.8) with ESMTP id h2I5fdx9015421 for ; Tue, 18 Mar 2003 06:41:40 +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 h2I5fXWC029047; Mon, 17 Mar 2003 21:41:33 -0800 (PST) Date: Mon, 17 Mar 2003 21:41:40 -0800 (PST) From: Rick Wesson To: Edward Lewis cc: , , Ted Hardie , Subject: Re: [ietf-provreg] again with the privacy 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, all of the "issues" enumerated below are really non-issues, we only need the privacy bits for social data not technical data. The IESG didn't ask us to create a privacy framework for hiding DNS hosts (which is silly) see [1] the element proposal, not to be confused with the attribute proposal, does address registrar -> registry boolean notes of what social data is to remain private. [1] http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html I propose that we don't have the problems you enumerate below if we restrict the elements that can be enclosed by a element are only social data elements. -rick On Mon, 17 Mar 2003, Edward Lewis wrote: > Jaap and I talked with Ted Hardie (incoming Apps Area AD) and Patrik > Faltstrom (outgoing Apps Area AD) about the state of the WG. (Sorry, > no mics were present to get the verbatim record of this.) I say this > because in the past Jaap and I have tried hard to stay away from > injecting technical material as chairs. However, it seems clear that > one more go of this is needed, so we are floating this again. > > Below is the proposal that was generated in December in response to > the IESG comments. I'm resurrecting it again based on this: > > The IESG wants a means for a registrar to tell a registry whether or > not a piece of data can be passed on. (DCP goes from registry to registrar, > we need a reverse version of this communication.) > > dnd="true" means: this info cannot leave the registry, not in DNS, not in > whois, not in another means. > > What if a domain name's DNS server is dnd="true"? Does it make DNS - no. > Is this sensible? Probably not. > > This isn't expressive enough for all involved, but it is a basic step. > > There were some objections to this in Dec/Jan. > > >1. "do not disclose" seems non-extensible, when extensibility seems important. > > It's a place holder. More elaborate information can appear later. > > >2. A complete proposal should specify whether a "dnd"d field should be > >distinguished from a non-existent field when presenting data to clients (e.g. > >via commands). If it should, then the proscribed manner in which that > >should be done should be included for . > > Good question. Info could return "value hidden". What about > 'hiding' the provisioned name? I think acknowledging it's > unavailability is excuseable. > > >3. What should return if the object being checked is marked as > >dnd="true" and the client doing the is one to which disclosure is > >prohibited? > > See above. > > >For the server side the attribute based approach is more cumbersome. > > I cannot answer that one. > > The AD's conjectured that for PS, if we were to put this proposal > into play and it went unused, it could be removed for DS... > > Comments about this? > > This will be discussed Thursday morning. > > >X-Authentication-Warning: nic.cafax.se: majordom set sender to > >owner-ietf-provreg@cafax.se using -f > >From: "Hollenbeck, Scott" > >To: "'ietf-provreg@cafax.se'" > >Subject: Updated (and hopefully the last) EPP Privacy Proposal > >Date: Mon, 30 Dec 2002 09:08:46 -0500 > >Importance: high > >X-Priority: 1 > >Sender: owner-ietf-provreg@cafax.se > >Status: > > > >In ongoing background discussions with the IESG regarding our EPP documents, > >we (Jaap, Ed, several IESG members, and I) have continued to talk about the > >IESG's privacy-related comments and the responses to those comments that > >have been sent to the WG mailing list. We've concluded that we need to add > >a "must implement" feature to the protocol to allow data elements to be > >tagged with a binary indicator of data owner preference for disclosure of > >information to third parties that aren't involved in the provisioning > >transaction. Back in October [1] I described a proposal to use an XML > >attribute for this purpose. Over the last few weeks ([2], [3]) I suggested > >a few other options. Considering all of our options, I would again like to > >suggest an XML attribute-based approach to address this last remaining IESG > >review issue. > > > >This does not mean that the binary indicator is the only way that privacy > >preferences or policies can be expressed. Expression of more specific > >privacy policies can be accomplished using the protocol's extension > >mechanism. > > > >The proposal is to add a new attribute to every object element in the > >domain, contact, and host mappings. This boolean attribute, "dnd" (for Do > >Not Disclose), will be used to note that the value of an element should not > >be disclosed to third parties. It will have a default value of "false" > >(meaning it is ok to disclose info) in the domain and host mappings, and a > >default value of "true" (meaning it is NOT ok to disclose info) in the > >contact mapping. The defaults can be over-ridden and explicitly specified > >by clients. Additional constraints can be defined using the protocol > >extension mechanism. > > > >Here are some examples: > > > >jdoe@example.com > >jdoe@example.com > >Both of the above mean "do not disclose this email address to third > >parties". > > > >jdoe@example.com > >This means that the data owner gives permission for the email address to be > >disclosed to third parties. > > > > > > > > > > > >(This extension example isn't syntactically valid, but I wanted it to be > >short, clear, and to the point without the clutter needed to make it valid. > >In this case it means that the email address should not be published via > >whois.) > > > >I'll also have to add some notes to explain that server policy might not > >recognize the value of an attribute if it's turned on (like in the email > >address example above) when turning on the attribute is counter to some > >policy. > > > >A measure of WG support or dissatisfaction with this proposal would be > >helpful. Would you please send a note to the mailing list to let the chairs > >know if you either support the proposal as a way to move forward or if you > >do not support the proposal? If you do not support the proposal it would be > >helpful if you explained why and could suggest modifications (if possible) > >to make it acceptable. > > > >If you do not support the proposal, please recognize that we have been stuck > >on this issue for quite a while and we need to do something. On the one > >hand, we are aware of the differences in privacy policy, laws, et al. facing > >each registry. On the other hand, we are being asked to define one standard > >protocol that is rigorous enough to not let privacy slide by. So the > >question is - does this proposal (including extension support) allow for all > >known policies to be expressed within EPP? > > > >-Scott- > > > >[1] > >http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html > > > >[2] > >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html > > > >[3] > >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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.8/8.12.8) with ESMTP id h2I5Dpx9015207 for ; Tue, 18 Mar 2003 06:13:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2I5DoMZ015206 for ietf-provreg-outgoing; Tue, 18 Mar 2003 06:13:50 +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.8/8.12.8) with ESMTP id h2I5Dix9015201 for ; Tue, 18 Mar 2003 06:13:45 +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 h2I5DitW035962; Tue, 18 Mar 2003 00:13:44 -0500 (EST) Received: from [130.129.137.249] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA08245; Tue, 18 Mar 2003 00:13:40 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: X-Priority: 1 (Highest) Date: Mon, 17 Mar 2003 21:13:34 -0800 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] again with the privacy Cc: edlewis@arin.net, jaap@sidn.nl, Ted Hardie , paf@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Jaap and I talked with Ted Hardie (incoming Apps Area AD) and Patrik Faltstrom (outgoing Apps Area AD) about the state of the WG. (Sorry, no mics were present to get the verbatim record of this.) I say this because in the past Jaap and I have tried hard to stay away from injecting technical material as chairs. However, it seems clear that one more go of this is needed, so we are floating this again. Below is the proposal that was generated in December in response to the IESG comments. I'm resurrecting it again based on this: The IESG wants a means for a registrar to tell a registry whether or not a piece of data can be passed on. (DCP goes from registry to registrar, we need a reverse version of this communication.) dnd="true" means: this info cannot leave the registry, not in DNS, not in whois, not in another means. What if a domain name's DNS server is dnd="true"? Does it make DNS - no. Is this sensible? Probably not. This isn't expressive enough for all involved, but it is a basic step. There were some objections to this in Dec/Jan. >1. "do not disclose" seems non-extensible, when extensibility seems important. It's a place holder. More elaborate information can appear later. >2. A complete proposal should specify whether a "dnd"d field should be >distinguished from a non-existent field when presenting data to clients (e.g. >via commands). If it should, then the proscribed manner in which that >should be done should be included for . Good question. Info could return "value hidden". What about 'hiding' the provisioned name? I think acknowledging it's unavailability is excuseable. >3. What should return if the object being checked is marked as >dnd="true" and the client doing the is one to which disclosure is >prohibited? See above. >For the server side the attribute based approach is more cumbersome. I cannot answer that one. The AD's conjectured that for PS, if we were to put this proposal into play and it went unused, it could be removed for DS... Comments about this? This will be discussed Thursday morning. >X-Authentication-Warning: nic.cafax.se: majordom set sender to >owner-ietf-provreg@cafax.se using -f >From: "Hollenbeck, Scott" >To: "'ietf-provreg@cafax.se'" >Subject: Updated (and hopefully the last) EPP Privacy Proposal >Date: Mon, 30 Dec 2002 09:08:46 -0500 >Importance: high >X-Priority: 1 >Sender: owner-ietf-provreg@cafax.se >Status: > >In ongoing background discussions with the IESG regarding our EPP documents, >we (Jaap, Ed, several IESG members, and I) have continued to talk about the >IESG's privacy-related comments and the responses to those comments that >have been sent to the WG mailing list. We've concluded that we need to add >a "must implement" feature to the protocol to allow data elements to be >tagged with a binary indicator of data owner preference for disclosure of >information to third parties that aren't involved in the provisioning >transaction. Back in October [1] I described a proposal to use an XML >attribute for this purpose. Over the last few weeks ([2], [3]) I suggested >a few other options. Considering all of our options, I would again like to >suggest an XML attribute-based approach to address this last remaining IESG >review issue. > >This does not mean that the binary indicator is the only way that privacy >preferences or policies can be expressed. Expression of more specific >privacy policies can be accomplished using the protocol's extension >mechanism. > >The proposal is to add a new attribute to every object element in the >domain, contact, and host mappings. This boolean attribute, "dnd" (for Do >Not Disclose), will be used to note that the value of an element should not >be disclosed to third parties. It will have a default value of "false" >(meaning it is ok to disclose info) in the domain and host mappings, and a >default value of "true" (meaning it is NOT ok to disclose info) in the >contact mapping. The defaults can be over-ridden and explicitly specified >by clients. Additional constraints can be defined using the protocol >extension mechanism. > >Here are some examples: > >jdoe@example.com >jdoe@example.com >Both of the above mean "do not disclose this email address to third >parties". > >jdoe@example.com >This means that the data owner gives permission for the email address to be >disclosed to third parties. > > > > > >(This extension example isn't syntactically valid, but I wanted it to be >short, clear, and to the point without the clutter needed to make it valid. >In this case it means that the email address should not be published via >whois.) > >I'll also have to add some notes to explain that server policy might not >recognize the value of an attribute if it's turned on (like in the email >address example above) when turning on the attribute is counter to some >policy. > >A measure of WG support or dissatisfaction with this proposal would be >helpful. Would you please send a note to the mailing list to let the chairs >know if you either support the proposal as a way to move forward or if you >do not support the proposal? If you do not support the proposal it would be >helpful if you explained why and could suggest modifications (if possible) >to make it acceptable. > >If you do not support the proposal, please recognize that we have been stuck >on this issue for quite a while and we need to do something. On the one >hand, we are aware of the differences in privacy policy, laws, et al. facing >each registry. On the other hand, we are being asked to define one standard >protocol that is rigorous enough to not let privacy slide by. So the >question is - does this proposal (including extension support) allow for all >known policies to be expressed within EPP? > >-Scott- > >[1] >http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html > >[2] >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html > >[3] >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2HJK9x9015345 for ; Mon, 17 Mar 2003 20:20:09 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HJK9K4015344 for ietf-provreg-outgoing; Mon, 17 Mar 2003 20:20:09 +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.8/8.12.8) with ESMTP id h2HJK8x9015339 for ; Mon, 17 Mar 2003 20:20:08 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HJJfGL012550; Mon, 17 Mar 2003 14:19:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171919.h2HJJfGL012550@nic-naa.net> To: Eric Brunner-Williams in Portland Maine cc: janusz sienkiewicz , Rick Wesson , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 14:16:13 EST." <200303171916.h2HJGDGL012537@nic-naa.net> Date: Mon, 17 Mar 2003 14:19:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Where there really is random variation from one data glob to the next, and > the variations are meaningfully distinct (a kettle of fish that is not yet > opened), then clearly the "statefull encoding" of policied sequences of > data globs is not going to work as well as some "statefull encoding" of > policied, and uncorrolated data globs. Oops. That should read > opened), then clearly the "statefull encoding" of policied sequences of > data globs is not going to work as well as some "stateless encoding" of ^^^^ Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HJGfx9015253 for ; Mon, 17 Mar 2003 20:16:41 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HJGfMq015252 for ietf-provreg-outgoing; Mon, 17 Mar 2003 20:16:41 +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.8/8.12.8) with ESMTP id h2HJGdx9015247 for ; Mon, 17 Mar 2003 20:16:40 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HJGDGL012537; Mon, 17 Mar 2003 14:16:13 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171916.h2HJGDGL012537@nic-naa.net> To: janusz sienkiewicz cc: Eric Brunner-Williams in Portland Maine , Rick Wesson , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 14:07:41 EST." <3E761CFD.9E18F2F@libertyrms.info> Date: Mon, 17 Mar 2003 14:16:13 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Shouldn't "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of > p1? I should have been explicit. I'm drawing on some non-provreg data -- real life with cookies. Few distinct "privacy" "policies" or "preferences" exist. The distribution of policied cookies and browser values that result in these three general categories: accept-unconditionally warn-accept-or-reject-conditionally reject-unconditionally is small, and the modality is less than the total range of values. The most likely transition will be from one domainant mode to another. So, p1 to p2 and back to p1, generally, and p1 to p3 and back to p1. Less frequently will be pN to pM, where N and M are not in the very small set of dominant modalities of meaningfully distinct policies. I wasn't trying to show p1, then p2, then p3 usage, but ...p1p1p1p1p1p2p2p1p1p1p1p1p1pp1p3p1p1... Where there really is random variation from one data glob to the next, and the variations are meaningfully distinct (a kettle of fish that is not yet opened), then clearly the "statefull encoding" of policied sequences of data globs is not going to work as well as some "statefull encoding" of policied, and uncorrolated data globs. In a sense, we're just revisiting statefull vs stateless encoding design issues. How much character-set variation do you think there is in some character stream? Design accordingly. If few transitions relative to the byte count, go for what amounts to state shifts (and variable byte counts per character). If many relative to the byte count, consider using fixed rather than variable byte counts, and accept the "padding" overhead. How many interesting ways are there to write: don't publish some or all of my mumble? Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HIt1x9014944 for ; Mon, 17 Mar 2003 19:55:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HIt1rq014943 for ietf-provreg-outgoing; Mon, 17 Mar 2003 19:55:01 +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.8/8.12.8) with ESMTP id h2HIsxx9014938 for ; Mon, 17 Mar 2003 19:55:00 +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 18uzkg-0004nC-00; Mon, 17 Mar 2003 13:54:26 -0500 Message-ID: <3E761CFD.9E18F2F@libertyrms.info> Date: Mon, 17 Mar 2003 14:07:41 -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: Eric Brunner-Williams in Portland Maine CC: Rick Wesson , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl Subject: Re: [ietf-provreg] thursday's meeting References: <200303171822.h2HIMeGL012339@nic-naa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric Brunner-Williams in Portland Maine wrote: > > I suspect because the granularity requetsted is for the registrant not the > > session, where by one session could do many registrations for many more > > contacts/registrants. > > So, in this model, there is p1, p2, p3; three distinct mumbles that have a > to be defined, but not session-scoped, definition. > > A session between e1 and e2, two EPP endpoints, which transports d1, d2, d3, > three distinct EPP datums, is: > > e1: session-open; send d1:p1; send d2:p2; send d3:p3; session-close > e2: ack, ack, ack, ack (sort of like the Martians in "Mars Attacks") > > If so, then while data exhibits a property close to global uniqness within > each glob of data, the value for the set {p1, p2, p3, ...} may have a much > smaller cardinality. Somewhere less than 42 seems likely. > > If so, then connections should resemble something like this: > > send d1:p1, send d2:p1, send d3:p1 .... send dN:p1 \ > send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1 > Shouldn't "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of p1? > > for non-trivial sequences of sequentially identical values of p. > > Rewritten, to show policy-scoped sequences of data: > > p1{d1, d2, ... dN}, p2{dN+1}, p1{dN+2, dN+3, ... dN+M} > > > And that looks reasonably amenable to this > > s1{p1{d1, d2, ... dN}}, s2{p2{dN+1}}, s3{p1{dN+2, dN+3, ... dN+M}} > > or three sessions, each with an associated single policy on all data. > > Operationally, we haven't precluded server operators from assigning well > known values of p to ports, so that in practice, the above would be three > distinct connections. > > We also haven't precluded server operators from cycling through a set of > well known values of p whenever the server observes a session-end sent > by a client, followed by a session-begin. > > We could of course add some mechanism for client and server to "dual" with > values, until "trained", but until someone starts putting values for > p down, we don't actually know if the size of the p value-space is as big > as 42, or as small as two, or three, or four meaningfully distinct values. > > Eric > > P.S. I'm having way too much fun with the symbolic general nonsense. The > proponant(s) of mumble need to attempt to be concret, soon. Janusz Sienkiewicz Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HINCx9014532 for ; Mon, 17 Mar 2003 19:23:12 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HINCgf014531 for ietf-provreg-outgoing; Mon, 17 Mar 2003 19:23: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.8/8.12.8) with ESMTP id h2HINAx9014526 for ; Mon, 17 Mar 2003 19:23:11 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HIMeGL012339; Mon, 17 Mar 2003 13:22:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171822.h2HIMeGL012339@nic-naa.net> To: Rick Wesson cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 09:21:56 PST." Date: Mon, 17 Mar 2003 13:22:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I suspect because the granularity requetsted is for the registrant not the > session, where by one session could do many registrations for many more > contacts/registrants. So, in this model, there is p1, p2, p3; three distinct mumbles that have a to be defined, but not session-scoped, definition. A session between e1 and e2, two EPP endpoints, which transports d1, d2, d3, three distinct EPP datums, is: e1: session-open; send d1:p1; send d2:p2; send d3:p3; session-close e2: ack, ack, ack, ack (sort of like the Martians in "Mars Attacks") If so, then while data exhibits a property close to global uniqness within each glob of data, the value for the set {p1, p2, p3, ...} may have a much smaller cardinality. Somewhere less than 42 seems likely. If so, then connections should resemble something like this: send d1:p1, send d2:p1, send d3:p1 .... send dN:p1 \ send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1 for non-trivial sequences of sequentially identical values of p. Rewritten, to show policy-scoped sequences of data: p1{d1, d2, ... dN}, p2{dN+1}, p1{dN+2, dN+3, ... dN+M} And that looks reasonably amenable to this s1{p1{d1, d2, ... dN}}, s2{p2{dN+1}}, s3{p1{dN+2, dN+3, ... dN+M}} or three sessions, each with an associated single policy on all data. Operationally, we haven't precluded server operators from assigning well known values of p to ports, so that in practice, the above would be three distinct connections. We also haven't precluded server operators from cycling through a set of well known values of p whenever the server observes a session-end sent by a client, followed by a session-begin. We could of course add some mechanism for client and server to "dual" with values, until "trained", but until someone starts putting values for p down, we don't actually know if the size of the p value-space is as big as 42, or as small as two, or three, or four meaningfully distinct values. Eric P.S. I'm having way too much fun with the symbolic general nonsense. The proponant(s) of mumble need to attempt to be concret, soon. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HHMEx9013753 for ; Mon, 17 Mar 2003 18:22:14 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HHMEGu013752 for ietf-provreg-outgoing; Mon, 17 Mar 2003 18:22:14 +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.8/8.12.8) with ESMTP id h2HHMCx9013745 for ; Mon, 17 Mar 2003 18:22:13 +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 h2HHLuWC013612; Mon, 17 Mar 2003 09:21:56 -0800 (PST) Date: Mon, 17 Mar 2003 09:21:56 -0800 (PST) From: Rick Wesson To: Eric Brunner-Williams in Portland Maine cc: "Hollenbeck, Scott" , "'Edward Lewis'" , , Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: <200303171634.h2HGYKGL011947@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 17 Mar 2003, Eric Brunner-Williams in Portland Maine wrote: > >> Pointing out a specific defect in the element's sub-schema would be > >> really useful. > > > > The DCP proposal didn't address how a registrar can tell the registry > > what can be disclosed. I believe it was the proposal that did > > allow this fine granularity of disclosure. > > We don't have a negociation mechanism, for anything. > > I don't mind adding one. > > Why is the scope of negociation limited to this however? I suspect because the granularity requetsted is for the registrant not the session, where by one session could do many registrations for many more contacts/registrants. -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HGYox9012968 for ; Mon, 17 Mar 2003 17:34:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HGYo9U012967 for ietf-provreg-outgoing; Mon, 17 Mar 2003 17:34: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.8/8.12.8) with ESMTP id h2HGYmx9012962 for ; Mon, 17 Mar 2003 17:34:49 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HGYKGL011947; Mon, 17 Mar 2003 11:34:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171634.h2HGYKGL011947@nic-naa.net> To: Rick Wesson cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 08:23:22 PST." Date: Mon, 17 Mar 2003 11:34:20 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk >> Pointing out a specific defect in the element's sub-schema would be >> really useful. > > The DCP proposal didn't address how a registrar can tell the registry > what can be disclosed. I believe it was the proposal that did > allow this fine granularity of disclosure. We don't have a negociation mechanism, for anything. I don't mind adding one. Why is the scope of negociation limited to this however? Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HGNRx9012774 for ; Mon, 17 Mar 2003 17:23:27 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HGNRUg012773 for ietf-provreg-outgoing; Mon, 17 Mar 2003 17:23:27 +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.8/8.12.8) with ESMTP id h2HGNQx9012768 for ; Mon, 17 Mar 2003 17:23:26 +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 h2HGNLWC007596; Mon, 17 Mar 2003 08:23:22 -0800 (PST) Date: Mon, 17 Mar 2003 08:23:22 -0800 (PST) From: Rick Wesson To: Eric Brunner-Williams in Portland Maine cc: "Hollenbeck, Scott" , "'Edward Lewis'" , , Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: <200303171616.h2HGGVGL011870@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 17 Mar 2003, Eric Brunner-Williams in Portland Maine wrote: > > > Our response to the IESG. The IESG wants "a standard (as > > > in the base, > > > core spec) means for a registrar to tell a registry what ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > can be disclosed > > > at fine granularity." [snip] > Pointing out a specific defect in the element's sub-schema would be > really useful. The DCP proposal didn't address how a registrar can tell the registry what can be disclosed. I believe it was the proposal that did allow this fine granularity of disclosure. -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HGH3x9012672 for ; Mon, 17 Mar 2003 17:17:03 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HGH3p3012671 for ietf-provreg-outgoing; Mon, 17 Mar 2003 17:17:03 +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.8/8.12.8) with ESMTP id h2HGH2x9012665 for ; Mon, 17 Mar 2003 17:17:02 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.8/8.12.6) with ESMTP id h2HGGVGL011870; Mon, 17 Mar 2003 11:16:31 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303171616.h2HGGVGL011870@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Edward Lewis'" , ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net Subject: Re: [ietf-provreg] thursday's meeting In-Reply-To: Your message of "Mon, 17 Mar 2003 08:39:46 EST." <3CD14E451751BD42BA48AAA50B07BAD60337082D@vsvapostal3.prod.netsol.com> Date: Mon, 17 Mar 2003 11:16:31 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > Our response to the IESG. The IESG wants "a standard (as > > in the base, > > core spec) means for a registrar to tell a registry what > > can be disclosed > > at fine granularity." > > > > A means to avoid host objects. > > We have really got to get a grip on the first item. I thought we were past > this as of last week, and here we are again. There's clearly a > communications issue somewhere... I agree. Either a session-scope mechanism, which incidently is independent of syntax and schema (it could be morphed into EBNF if RRP has not yet reached its sell-by date), or a base schema mechanism, dependent upon syntax and schema, and independent of "session" (aka, "privacy" is a property of syntax representations, and transport independent, even if it is not transported), or a mechanism which subsets the base schema, and constructs some syntax and semantics from some subset, and is also independent of "session" (see above, and add complexity for subseting in general). That should read as a switch statement, with no fall-through. Pointing out a specific defect in the element's sub-schema would be really useful. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2HDh0x9011109 for ; Mon, 17 Mar 2003 14:43:00 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2HDh0D2011108 for ietf-provreg-outgoing; Mon, 17 Mar 2003 14:43:00 +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.8/8.12.8) with ESMTP id h2HDgwx9011101 for ; Mon, 17 Mar 2003 14:42:59 +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 IAA13181; Mon, 17 Mar 2003 08:42:52 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 08:39:45 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337082D@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] thursday's meeting Date: Mon, 17 Mar 2003 08:39:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > As one might imagine, the agenda is going to be a bit flexible. > > Besides the published agenda, I'd like folks to be prepared to also > discuss these items: > > Our response to the IESG. The IESG wants "a standard (as > in the base, > core spec) means for a registrar to tell a registry what > can be disclosed > at fine granularity." > > A means to avoid host objects. We have really got to get a grip on the first item. I thought we were past this as of last week, and here we are again. There's clearly a communications issue somewhere... I would hope that whomever wishes to bring up the "avoid host objects" topic plans to introduce information that hasn't already been talked to death on the mailing list at multiple times in the past. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2H568x9007303 for ; Mon, 17 Mar 2003 06:06:08 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2H568Zu007302 for ietf-provreg-outgoing; Mon, 17 Mar 2003 06:06:08 +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.8/8.12.8) with ESMTP id h2H566x9007297 for ; Mon, 17 Mar 2003 06:06:06 +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 h2H563tW004969; Mon, 17 Mar 2003 00:06:03 -0500 (EST) Received: from [130.129.137.249] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA25399; Mon, 17 Mar 2003 00:05:59 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Sun, 16 Mar 2003 21:05:56 -0800 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] thursday's meeting Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk As one might imagine, the agenda is going to be a bit flexible. Besides the published agenda, I'd like folks to be prepared to also discuss these items: Our response to the IESG. The IESG wants "a standard (as in the base, core spec) means for a registrar to tell a registry what can be disclosed at fine granularity." A means to avoid host objects. I've heard from a few folks that these topics warrant further discussion. I invite those who have been talking to me directly to send words to the list to spur discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2FJXrx9024756 for ; Sat, 15 Mar 2003 20:33:54 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h2FJXrxn024755 for ietf-provreg-outgoing; Sat, 15 Mar 2003 20:33:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2FJXqx9024748 for ; Sat, 15 Mar 2003 20:33:52 +0100 (MET) Received: (qmail 93866 invoked by uid 0); 15 Mar 2003 19:33:51 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 15 Mar 2003 19:33:51 -0000 Date: Sat, 15 Mar 2003 14:33:59 -0500 Subject: [ietf-provreg] ISC OpenReg 1.0.1 Release Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joe Abley To: jabley@isc.org Content-Transfer-Encoding: 7bit Message-Id: <120FB739-571D-11D7-8411-00039312C852@isc.org> X-Mailer: Apple Mail (2.551) Sender: owner-ietf-provreg@cafax.se Precedence: bulk [this message is being copied to multiple mailing lists; apologies in advance for duplicates] The Internet Software Consortium is pleased to announce the first public release of OpenReg, an implementation of a DNS Shared Registry System which supports the Extensible Provisioning Protocol (EPP). For more information, and to download OpenReg, please see: http://www.isc.org/products/OpenReg/ OpenReg is free software, released under a BSD-style licence. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2C7fnx9012255 for ; Wed, 12 Mar 2003 08:41:49 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2C7fnhM012254 for ietf-provreg-outgoing; Wed, 12 Mar 2003 08:41:49 +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.8/8.12.8) with ESMTP id h2C7fmx9012249 for ; Wed, 12 Mar 2003 08:41:48 +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 h2C7faF28346; Wed, 12 Mar 2003 02:41:36 -0500 Message-ID: <008001c2e86a$cfced010$6601a8c0@afilias.com> From: "Ram Mohan" To: "Hollenbeck, Scott" , References: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> Subject: Re: [ietf-provreg] Summary of IESG Comments and Disposition Date: Wed, 12 Mar 2003 02:20:53 -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 Scott, Thanks - good work! -ram ----- Original Message ----- From: "Hollenbeck, Scott" To: Sent: Tuesday, March 11, 2003 9:49 AM Subject: [ietf-provreg] Summary of IESG Comments and Disposition > This note describes the IESG review comments that we've received and > addressed in the most recent versions of the EPP specifications. Here are > the references to the current documents: > > http://www.verisignlabs.com/draft-ietf-provreg-epp-09.txt > I just finished this version today. This is a temporary location until the > document is announced by the Internet-Drafts administrator after the San > Francisco meeting. > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt > > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt > > Here are the references to the IESG comments along with a description of > what was done to address them: > > http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html > > 1. > Do we put mailing list names and URLs in RFCs? > > RESOLUTION: The paragraph describing the mailing list and archives has been > removed. > > 2. I'd like a stronger Security Considerations section, though I think it > can be added by an RFC Editor note. In particular, I want it to say that > EPP "MUST NOT be used over a transport mechanism that does not provide > confidentiality", or "All transport mappings for EPP MUST provide > confidentiality and integrity". (I think that that's what they intend, but > it's not clear enough.) > > RESOLUTION: The text has been changed to read "EPP instances MUST be > protected using a transport mechanism or application protocol that provides > integrity and confidentiality". > > 3. > What is an "authorization token"? It's not defined, but it's mandated by > the security considerations. (I suspect it's what is discussed in 2.6, but > it doesn't use the same words.) > > RESOLUTION: The text describing an "authorization token" has been changed to > use the same "authorization information" term described in section 2.6. > > 4. > What is an "authorization token"? It's not defined, but it's mandated by > the security considerations. (I suspect it's what is discussed in 2.8, but > it doesn't use the same words.) > > RESOLUTION: The text describing an "authorization token" has been changed > to use the same "authorization information" term described in section 2.8. > > 5. > The Security Considerations section seems to require TLS client > authentication, which in turn requires client certificates. Is this > intended? If so, great! But in that case, what is the fate, if any, of the > EPP login/password command? Is it still needed? Is it still legal? What > does it mean? Must the identities agree? (The requirement for server > authentication is excellent, but some more text mentioning the need to > validate the certificate chain is probably a good idea.) > > RESOLUTION: The Security Considerations section has been modified to > explicitly note the need to validate the certificate chain. The > certificates used for TLS authentication authenticate the client and server > machines involved in the provisioning exchange. The EPP login functionality > is still needed, though, as it provides a facility to authenticate client > user identities so that the server can make access control and authorization > decisions based on the identity of the client, in addition to the identity > of the machine the client is using to communicate with the server. > > 6. sec 2.1 > I think it would be good to be a bit more strict about the use of congestion > control protocols specifically require the use of an IETF standards track > congestion control protocol such as TCP or SCTP > > i.e. change the following line: > - The transport mapping MUST manage congestion. > > to: > - The transport mapping MUST only be to an IETF standards > track congestion control protocol such as TCP or SCTP. > > RESOLUTION: Section 2.1 has been modified to read as follows: > > "- The transport mapping MUST be onto a transport such as TCP [RFC793] or > SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914 > [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP > [RFC3080], then the performance issues need to take into account issues of > overload, server availability and so forth." > > 7. > page 12, example greeting has: > > S: Example EPP server epp.example.tld > > in an example greeting. Did we not decide at some point that examples should > be of the form: epp.example.org ?? > > RESOLUTION: All examples in all documents have been changed to use the > example domain names (example.com, example.net, and example.org) described > in RFC 2606. Sample IPv4 addresses have been changed to use the Test-Net > address block listed in RFC 3330. > > 8. why do domain/contact/.. not have granular information about privacy? > > RESOLUTION: This comment has been addressed through a very lengthy > discussion process that resulted in making the existing element > mandatory. This change is reflected in a new version of the core protocol > document that can be seen at the temporary URL provided at the top of this > message. The formal announcement will be made after the San Francisco IETF > meeting. > > http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00049.html > > 1. The transport mapping MUST manage congestion. > > RESOLUTION: See the resolution for item 6 above. > > http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html > > > 1. The transport mapping MUST manage congestion. > > RESOLUTION: See the resolution for item 6 above. > > 2. Within the optional dcp (data collection policy) element: there is a > non-technical spin in at least the following label definition, what kind of > marketing is meant? > > : Contact for marketing purposes. > > Please add more to this definition so that is more neutral in in its > terminology. > > RESOLUTION: The description of this element has been changed as follows: > > ": Contact for marketing purposes. Information can be used to > contact individuals, through a communications channel other than the > protocol, for the promotion of a product or service.". > > 3. How does IESG and the community check the extensive XML in a > specification like this (analogous to the ABNF and MIB checking described > that is done regularly...)? How did you check what's here? Why might it > not matter? > > RESOLUTION: Syntax checking matters. There are a variety of freely > available XML syntax checking utilities, such as the Xerces XML parser > written in Java, that can be used to validate all of the schemas and > examples provided in the documents. The normative schemas can be copied > from the documents, edited to remove page headers and footers, and pasted > together to create the formal syntax specifications for the protocol. > Examples can be copied from the documents, edited to remove the "C:" and > "S:" line prefixes, and pasted together to create a set of sample instances > of the protocol. Scott Hollenbeck has also published external files > containing all of the examples and schemas in two public places: > > ftp://ftp.verisign.com/pub/epp/ > > http://www.verisign-grs.com/files/ > > Other WG members are mirroring these file collections to provide additional > redundancy. The examples and schemas can be run through an up-to-date > validating XML parser to confirm validity. As part of the normal document > editing process, Scott has been running all of the examples and schemas > through the Xerces-J parser to confirm that everything remains valid > according to the current W3C XML Schema specifications. > > > 1. "An EPP client streams EPP commands to an EPP server on an established > TCP connection. A client MAY establish multiple TCP connections to create > multiple command exchange channels. A server MAY limit a client to a > maximum number of TCP connections based on server capabilities and > operational load." > > It is not a good thing for the net for services to choose this approach. A > MAY like this is problematic for congestion control reasons. I would like > to change this language from "MAY establish" to "MAY but SHOULD NOT" and > from "A server MAY limit" to "A server SHOULD limit" > > RESOLUTION: Text changed as requested. > > 2. For references to TCP, besides RFC 793, you need: RFC 2581, 2914 > > RESOLUTION: References added. > > That's it! I'll try to have the updated EPP schema and example package > (none of the examples changed) uploaded to the public locations as quickly > as possible. > > -Scott- > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2BGr6x9002901 for ; Tue, 11 Mar 2003 17:53:06 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2BGr66M002900 for ietf-provreg-outgoing; Tue, 11 Mar 2003 17:53:06 +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.8/8.12.8) with ESMTP id h2BGr5x9002895 for ; Tue, 11 Mar 2003 17:53:05 +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 h2BGr2JW030793; Tue, 11 Mar 2003 11:53:02 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA21939; Tue, 11 Mar 2003 11:53:00 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> X-Priority: 1 (Highest) Date: Tue, 11 Mar 2003 08:50:12 -0800 To: "Hollenbeck, Scott" From: Edward Lewis Subject: Re: [ietf-provreg] Summary of IESG Comments and Disposition Cc: "'ietf-provreg@cafax.se'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, thanks. I will forward the message to the IESG now (without cc'ing the list as we've all seen the text once here ;)). At 9:49 -0500 3/11/03, Hollenbeck, Scott wrote: >This note describes the IESG review comments that we've received and >addressed in the most recent versions of the EPP specifications. Here are >the references to the current documents: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2BEpxx9001356 for ; Tue, 11 Mar 2003 15:51:59 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2BEpxaJ001355 for ietf-provreg-outgoing; Tue, 11 Mar 2003 15:51: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.8/8.12.8) with ESMTP id h2BEpwx9001350 for ; Tue, 11 Mar 2003 15:51: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 JAA11660 for ; Tue, 11 Mar 2003 09:51:51 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 09:49:13 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707DA@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: [ietf-provreg] Summary of IESG Comments and Disposition Date: Tue, 11 Mar 2003 09:49:12 -0500 Importance: high X-Priority: 1 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 note describes the IESG review comments that we've received and addressed in the most recent versions of the EPP specifications. Here are the references to the current documents: http://www.verisignlabs.com/draft-ietf-provreg-epp-09.txt I just finished this version today. This is a temporary location until the document is announced by the Internet-Drafts administrator after the San Francisco meeting. http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt Here are the references to the IESG comments along with a description of what was done to address them: http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html 1. Do we put mailing list names and URLs in RFCs? RESOLUTION: The paragraph describing the mailing list and archives has been removed. 2. I'd like a stronger Security Considerations section, though I think it can be added by an RFC Editor note. In particular, I want it to say that EPP "MUST NOT be used over a transport mechanism that does not provide confidentiality", or "All transport mappings for EPP MUST provide confidentiality and integrity". (I think that that's what they intend, but it's not clear enough.) RESOLUTION: The text has been changed to read "EPP instances MUST be protected using a transport mechanism or application protocol that provides integrity and confidentiality". 3. What is an "authorization token"? It's not defined, but it's mandated by the security considerations. (I suspect it's what is discussed in 2.6, but it doesn't use the same words.) RESOLUTION: The text describing an "authorization token" has been changed to use the same "authorization information" term described in section 2.6. 4. What is an "authorization token"? It's not defined, but it's mandated by the security considerations. (I suspect it's what is discussed in 2.8, but it doesn't use the same words.) RESOLUTION: The text describing an "authorization token" has been changed to use the same "authorization information" term described in section 2.8. 5. The Security Considerations section seems to require TLS client authentication, which in turn requires client certificates. Is this intended? If so, great! But in that case, what is the fate, if any, of the EPP login/password command? Is it still needed? Is it still legal? What does it mean? Must the identities agree? (The requirement for server authentication is excellent, but some more text mentioning the need to validate the certificate chain is probably a good idea.) RESOLUTION: The Security Considerations section has been modified to explicitly note the need to validate the certificate chain. The certificates used for TLS authentication authenticate the client and server machines involved in the provisioning exchange. The EPP login functionality is still needed, though, as it provides a facility to authenticate client user identities so that the server can make access control and authorization decisions based on the identity of the client, in addition to the identity of the machine the client is using to communicate with the server. 6. sec 2.1 I think it would be good to be a bit more strict about the use of congestion control protocols specifically require the use of an IETF standards track congestion control protocol such as TCP or SCTP i.e. change the following line: - The transport mapping MUST manage congestion. to: - The transport mapping MUST only be to an IETF standards track congestion control protocol such as TCP or SCTP. RESOLUTION: Section 2.1 has been modified to read as follows: "- The transport mapping MUST be onto a transport such as TCP [RFC793] or SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914 [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP [RFC3080], then the performance issues need to take into account issues of overload, server availability and so forth." 7. page 12, example greeting has: S: Example EPP server epp.example.tld in an example greeting. Did we not decide at some point that examples should be of the form: epp.example.org ?? RESOLUTION: All examples in all documents have been changed to use the example domain names (example.com, example.net, and example.org) described in RFC 2606. Sample IPv4 addresses have been changed to use the Test-Net address block listed in RFC 3330. 8. why do domain/contact/.. not have granular information about privacy? RESOLUTION: This comment has been addressed through a very lengthy discussion process that resulted in making the existing element mandatory. This change is reflected in a new version of the core protocol document that can be seen at the temporary URL provided at the top of this message. The formal announcement will be made after the San Francisco IETF meeting. http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00049.html 1. The transport mapping MUST manage congestion. RESOLUTION: See the resolution for item 6 above. http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html 1. The transport mapping MUST manage congestion. RESOLUTION: See the resolution for item 6 above. 2. Within the optional dcp (data collection policy) element: there is a non-technical spin in at least the following label definition, what kind of marketing is meant? : Contact for marketing purposes. Please add more to this definition so that is more neutral in in its terminology. RESOLUTION: The description of this element has been changed as follows: ": Contact for marketing purposes. Information can be used to contact individuals, through a communications channel other than the protocol, for the promotion of a product or service.". 3. How does IESG and the community check the extensive XML in a specification like this (analogous to the ABNF and MIB checking described that is done regularly...)? How did you check what's here? Why might it not matter? RESOLUTION: Syntax checking matters. There are a variety of freely available XML syntax checking utilities, such as the Xerces XML parser written in Java, that can be used to validate all of the schemas and examples provided in the documents. The normative schemas can be copied from the documents, edited to remove page headers and footers, and pasted together to create the formal syntax specifications for the protocol. Examples can be copied from the documents, edited to remove the "C:" and "S:" line prefixes, and pasted together to create a set of sample instances of the protocol. Scott Hollenbeck has also published external files containing all of the examples and schemas in two public places: ftp://ftp.verisign.com/pub/epp/ http://www.verisign-grs.com/files/ Other WG members are mirroring these file collections to provide additional redundancy. The examples and schemas can be run through an up-to-date validating XML parser to confirm validity. As part of the normal document editing process, Scott has been running all of the examples and schemas through the Xerces-J parser to confirm that everything remains valid according to the current W3C XML Schema specifications. 1. "An EPP client streams EPP commands to an EPP server on an established TCP connection. A client MAY establish multiple TCP connections to create multiple command exchange channels. A server MAY limit a client to a maximum number of TCP connections based on server capabilities and operational load." It is not a good thing for the net for services to choose this approach. A MAY like this is problematic for congestion control reasons. I would like to change this language from "MAY establish" to "MAY but SHOULD NOT" and from "A server MAY limit" to "A server SHOULD limit" RESOLUTION: Text changed as requested. 2. For references to TCP, besides RFC 793, you need: RFC 2581, 2914 RESOLUTION: References added. That's it! I'll try to have the updated EPP schema and example package (none of the examples changed) uploaded to the public locations as quickly as possible. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2BEWRx9001138 for ; Tue, 11 Mar 2003 15:32:27 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2BEWRF1001137 for ietf-provreg-outgoing; Tue, 11 Mar 2003 15:32:27 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from arachne (vianet-ispa-gw01.via.at [194.96.143.146] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2BEWQx9001129 for ; Tue, 11 Mar 2003 15:32:26 +0100 (MET) Received: from lendl by arachne with local (Exim 3.36 #1 (Debian)) id 18skno-0002vI-00 for ; Tue, 11 Mar 2003 15:32:24 +0100 Date: Tue, 11 Mar 2003 15:32:24 +0100 From: Otmar Lendl To: ietf-provreg@cafax.se Subject: [ietf-provreg] EPP/TCP server testing tools Message-ID: <20030311143224.GA11219@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Sender: owner-ietf-provreg@cafax.se Precedence: bulk As I'm in the process of polishing and testing my mod_epp (EPP as Apache 2.0 module) EPP/TCP implementation [1], I'm wondering if anybody has already done some work concerning server testing software. All the client toolkits are nice and fine for testing the EPP backend logic, but right now I'm much more interested in the EPP/TCP layer. For example: Wrong framing, arbitrary delays between header and the XML, pipelining, DoS, TCP/out-of-band, refusing to read answers, ... Can anybody share code which does these tests? /ol [1] http://sourceforge.net/projects/aepps/ (for current code see CVS.) Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2B3Qsx9025506 for ; Tue, 11 Mar 2003 04:26:54 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2B3Qswg025505 for ietf-provreg-outgoing; Tue, 11 Mar 2003 04:26:54 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from as01.tabata.noc.humeia.net (as01.tabata.noc.humeia.net [210.156.80.71] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h2B3Qpx9025500 for ; Tue, 11 Mar 2003 04:26:53 +0100 (MET) Received: (qmail 3510 invoked by uid 0); 11 Mar 2003 03:27:07 -0000 Received: from dhcp01.kanda.noc.humeia.ad.jp (HELO noma) (noma@tabata.humeia.net@61.195.157.157) by as01.tabata.noc.humeia.net with SMTP; 11 Mar 2003 03:27:07 -0000 To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] URL element in contact mapping From: Hideki Noma References: <200303041237.HAD10017.NBPO@humeia.ad.jp> In-Reply-To: Message-Id: <200303111226.BGF35894.NOBP@humeia.ad.jp> X-Mailer: Winbiff without EditX [Version 2.41] X-Accept-Language: ja,en Date: Tue, 11 Mar 2003 12:26:24 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thank you for responding. Sorry for late action. How about this kind of element. https://ssl.d4u.jp/Contact.cgi or in case there needs some distinction on which type of url; (like as whois offered by whois.internic.net) https://ssl.d4u.jp/Contact.cgi whois.internic.net this should serve fine. Adding url parameter might help in solving the privacy issue as offering another means to contact the registrant, don't you think so? Hideki Noma Humeia Limited Partnership > The WG (which is the mailing list) has not heard of this before, so > we are unable to send you a reference. > > We would appreciate more information on this topic so that the > protocol is capable of handling all it needs to handle. > > > At 12:37 +0900 3/4/03, Hideki Noma wrote: > >Hello, > > > >There will be a URL element introduced in .JP contact information in > >near future. > >And I beleive that some sort of element representing a URL of domain > >owner or contact > >is necessary.In fact whois.internic.net has both url element of > >whois server and > >web server. > > > >I understand that url element should be optional or even, extention > >implemented by registrars, > >however the element name must be standardized. I don't know why JP > >registry is not commenting on > >this but as one of JP registrar, I strongly request it. > > > >If there has been a discussion around this topic I've missed it, > >please point me > >where to look at. > > > >Hideki Noma > >Humeia Limited Partnership > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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.8/8.12.8) with ESMTP id h2AJL7x9020691 for ; Mon, 10 Mar 2003 20:21:07 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AJL7JG020690 for ietf-provreg-outgoing; Mon, 10 Mar 2003 20:21:07 +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.8/8.12.8) with ESMTP id h2AJKux9020685 for ; Mon, 10 Mar 2003 20:20:57 +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 h2AJJ0JW004097; Mon, 10 Mar 2003 14:19:00 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA05513; Mon, 10 Mar 2003 14:18:57 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303101850.h2AIoAWs064412@nic-naa.net> References: <200303101850.h2AIoAWs064412@nic-naa.net> Date: Mon, 10 Mar 2003 11:18:52 -0800 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] Re: provreg's privacy issue Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Edward Lewis , Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 13:50 -0500 3/10/03, Eric Brunner-Williams in Portland Maine wrote: >I guess I missed Allison's note. It wasn't the one in reply to Rick, right? http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html (Is that what you need?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2AIpKx9020241 for ; Mon, 10 Mar 2003 19:51:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIpKdd020240 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:51:20 +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.8/8.12.8) with ESMTP id h2AIpIx9020233 for ; Mon, 10 Mar 2003 19:51:18 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h2AIoAWs064412; Mon, 10 Mar 2003 13:50:10 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303101850.h2AIoAWs064412@nic-naa.net> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Edward Lewis , Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com, brunner@nic-naa.net Subject: Re: [ietf-provreg] Re: provreg's privacy issue In-Reply-To: Your message of "Mon, 10 Mar 2003 19:15:21 +0100." <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> Date: Mon, 10 Mar 2003 13:50:10 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk I guess I missed Allison's note. It wasn't the one in reply to Rick, right? Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIl0x9020183 for ; Mon, 10 Mar 2003 19:47:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIl0vk020182 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:47:00 +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.8/8.12.8) with ESMTP id h2AIknx9020177 for ; Mon, 10 Mar 2003 19:46:49 +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 h2AIknJW002947; Mon, 10 Mar 2003 13:46:49 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA28590; Mon, 10 Mar 2003 13:46:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> References: <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> Date: Mon, 10 Mar 2003 10:46:49 -0800 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Edward Lewis Subject: [ietf-provreg] Re: provreg's privacy issue Cc: Edward Lewis , Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h2AIkox9020178 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 19:15 +0100 3/10/03, Patrik Fältström wrote: >On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward Lewis wrote: > >> Returning to the IESG review of these documents sometime around October, we >>feel that we have addressed all of the comments now. > >Also the one from Allison which sort of disappeared in the flurry of other >discussions? We 'think' we addressed that issue long ago, the answer to it should already be in the specs in the repository. Perhaps it would be good to prepare a summary of answers to the IESG comments. >> As soon as the new documents hit the repository, we ask that the IESG >>resume its review of the specifications. > >Thanks! > > paf -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2AIaex9020062 for ; Mon, 10 Mar 2003 19:36:40 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIaeoH020061 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:36:40 +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.8/8.12.8) with ESMTP id h2AIaSx9020056 for ; Mon, 10 Mar 2003 19:36:29 +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 NAA24774; Mon, 10 Mar 2003 13:34:55 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 13:32:21 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707CD@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Edward Lewis Cc: Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se Subject: [ietf-provreg] RE: provreg's privacy issue Date: Mon, 10 Mar 2003 13:32:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h2AIaTx9020057 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward > Lewis wrote: > > > Returning to the IESG review of these documents sometime around > > October, we feel that we have addressed all of the comments now. > > Also the one from Allison which sort of disappeared in the flurry of > other discussions? Yes -- the documents that are currently available were modified to address all of Allison's comments. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIFlx9019803 for ; Mon, 10 Mar 2003 19:15:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AIFlVS019802 for ietf-provreg-outgoing; Mon, 10 Mar 2003 19:15:47 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AIFax9019797 for ; Mon, 10 Mar 2003 19:15:36 +0100 (MET) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2AIDheh004586; Mon, 10 Mar 2003 19:13:48 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 10 Mar 2003 19:15:29 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 10 Mar 2003 19:15:29 +0100 Date: Mon, 10 Mar 2003 19:15:21 +0100 Subject: [ietf-provreg] Re: provreg's privacy issue Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ted Hardie , Ned Freed , randy@psg.com, ietf-provreg@cafax.se, shollenbeck@verisign.com To: Edward Lewis From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-Id: <41BBDF38-5324-11D7-B1EB-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 10 Mar 2003 18:15:29.0383 (UTC) FILETIME=[08062770:01C2E731] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h2AIFax9019798 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward Lewis wrote: > Returning to the IESG review of these documents sometime around > October, we feel that we have addressed all of the comments now. Also the one from Allison which sort of disappeared in the flurry of other discussions? > As soon as the new documents hit the repository, we ask that the IESG > resume its review of the specifications. Thanks! paf Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2AHsOx9019498 for ; Mon, 10 Mar 2003 18:54:24 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AHsOkq019497 for ietf-provreg-outgoing; Mon, 10 Mar 2003 18:54:24 +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.8/8.12.8) with ESMTP id h2AHsCx9019477 for ; Mon, 10 Mar 2003 18:54:12 +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 h2AHsAJW001413; Mon, 10 Mar 2003 12:54:10 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA19642; Mon, 10 Mar 2003 12:54:08 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: Date: Mon, 10 Mar 2003 08:08:29 -0800 To: paf@cisco.com, Ted Hardie , Ned Freed , randy@psg.com From: Edward Lewis Subject: [ietf-provreg] provreg's privacy issue Cc: ietf-provreg@cafax.se, shollenbeck@verisign.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk In response to the IESG comment: why do domain/contact/.. not have granular information about privacy? The provreg WG has apparently reached consensus upon this suggestion: That being the case, my preference would be to put _all_ of the DNP syntax and semantics into an extension (where the problem can be addressed as a whole) while making the existing DCP element mandatory if that resolves the privacy issue with the IESG. For the WG, Scott Hollenbeck will make the necessary changes to the base specification to reflect this consensus. (Scott: please do this as soon as you get the chance.[0]) It would help the IESG to see the formalized text based on this. Returning to the IESG review of these documents sometime around October, we feel that we have addressed all of the comments now. As soon as the new documents hit the repository, we ask that the IESG resume its review of the specifications. [0] Yeah, I realize that drafts submissions are being held up until after the IETF meeting week. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h2AHsGx9019488 for ; Mon, 10 Mar 2003 18:54:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2AHsFRw019487 for ietf-provreg-outgoing; Mon, 10 Mar 2003 18:54:15 +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.8/8.12.8) with ESMTP id h2AHsEx9019482 for ; Mon, 10 Mar 2003 18:54:15 +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 h2AHsEJW001416; Mon, 10 Mar 2003 12:54:14 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA19652; Mon, 10 Mar 2003 12:54:13 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: Date: Mon, 10 Mar 2003 08:47:17 -0800 To: agenda@ietf.org, ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] provreg agenda for SF Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Provreg: Thursday, March 20, 9-11:30 1. Agenda Bashing 2. WG status (where we are document-wise) 3. Current status of the IESG review draft-ietf-provreg-epp-08.txt draft-ietf-provreg-epp-contact-06.txt draft-ietf-provreg-epp-domain-06.txt draft-ietf-provreg-epp-host-06.txt draft-ietf-provreg-epp-tcp-06.txt 4. Extending EPP document draft-ietf-provreg-epp-ext-00.txt 5. Other issues with the Base Spec Issues have been raised and mostly dropped over the past few months. No issue to date seems to have generated enough interest to halt publication as a Proposed Standard. (Speak now or hold your peace until Draft Standard.) 6. Other Transports This is in our charter, proposals to do this pop up, but no effort has been sustained. 7. Special Request: IDN in EPP A request to discuss this has been made. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h27KpfDc021937 for ; Fri, 7 Mar 2003 21:51:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h27Kpfq2021936 for ietf-provreg-outgoing; Fri, 7 Mar 2003 21:51:41 +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.8/8.12.8) with ESMTP id h27KpeDc021928 for ; Fri, 7 Mar 2003 21:51:40 +0100 (MET) Received: from eagle (ismtp.afilias.com [216.217.55.254]) (authenticated) by ns01.afilias.info (8.11.6/8.11.6) with ESMTP id h27KpLF32504; Fri, 7 Mar 2003 15:51:21 -0500 Message-ID: <1c2b01c2e4eb$4e5cfe80$4402a8c0@afilias.com> From: "Ram Mohan" To: "Hollenbeck, Scott" , "'Edward Lewis'" , Cc: References: <3CD14E451751BD42BA48AAA50B07BAD6033707AF@vsvapostal3.prod.netsol.com> Subject: Re: [ietf-provreg] Fwd: Re: provreg milestones Date: Fri, 7 Mar 2003 15:35:59 -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 agreed, both personally and for the .info registry. -ram ----- Original Message ----- From: "Hollenbeck, Scott" To: "'Edward Lewis'" ; Cc: Sent: Friday, March 07, 2003 7:23 AM Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones > > Also to the group - as far as the privacy thing being resolved, I'm a > > bit hesitant to declare consensus yet to the proposal in: > > > > # From: "Hollenbeck, Scott" > > # Date: Mon, 3 Mar 2003 13:02:34 -0500 > > # > > # As far as .com is concerned, I have no doubt that an > > extension will be > > # required even if we were to adopt the IESG's element > > tagging suggestion. > > # That being the case, my preference would be to put _all_ of > > the DNP syntax > > # and semantics into an extension (where the problem can be > > addressed as a > > # whole) while making the existing DCP element mandatory if > > that resolves the > > # privacy issue with the IESG. > > > > (Aka - > > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) > > > > So let me hear about that... > > Ed, please note these supporting comments sent prior to your note: > > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00015.html > > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00023.html > > -Scott- > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27Hs2h3019936 for ; Fri, 7 Mar 2003 18:54:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h27Hs2xj019935 for ietf-provreg-outgoing; Fri, 7 Mar 2003 18:54:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27Hs0h3019926 for ; Fri, 7 Mar 2003 18:54:01 +0100 (MET) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h27HrsC08827; Fri, 7 Mar 2003 17:53:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 12:54:02 -0500 Message-ID: <25A36E32FDC7D511827600306E1C196201325CC5@chlaexch1.va.neustar.com> From: "Liu, Hong" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones Date: Fri, 7 Mar 2003 12:56:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h27Hs1h3019928 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, I think Scott's proposal is a reasonable one going forward. I will support it. --Hong -----Original Message----- From: Edward Lewis [mailto:edlewis@arin.net] Sent: Thursday, March 06, 2003 4:38 PM To: ietf-provreg@cafax.se Cc: edlewis@arin.net; jaap@sidn.nl Subject: [ietf-provreg] Fwd: Re: provreg milestones Also to the group - as far as the privacy thing being resolved, I'm a bit hesitant to declare consensus yet to the proposal in: # From: "Hollenbeck, Scott" # Date: Mon, 3 Mar 2003 13:02:34 -0500 # # As far as .com is concerned, I have no doubt that an extension will be # required even if we were to adopt the IESG's element tagging suggestion. # That being the case, my preference would be to put _all_ of the DNP syntax # and semantics into an extension (where the problem can be addressed as a # whole) while making the existing DCP element mandatory if that resolves the # privacy issue with the IESG. (Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) So let me hear about that... >Date: Thu, 6 Mar 2003 21:48:31 +0100 >Subject: Re: provreg milestones >Cc: jaap@sidn.nl, Ted Hardie >To: Edward Lewis >From: Patrik Fältström >X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) >FILETIME=[C2ED4AE0:01C2E421] >Status: > >This looks good. > >Please send the new milestones to iesg-secretary@ietf.org. > >I also understand the privacy thing is now resolved. I saw a few >messages on the mailing list about it. > >May I suggest you (or someone) write a summary of what the solution >is, and send it to me, randy, allison (and also cc Ned and Ted as >co-AD's -- yes, Ted is formally not onboard, but anyway). You can of >course also cc the mailing list if you want to. > > paf > >On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote: > >> I've heard no response to this from 'above.' >> >> The FEB 03 milestone now should be MAR 03 I guess. >> >>> Date: Fri, 31 Jan 2003 10:14:40 -0500 >>> To: paf@cisco.com, jaap@sidn.nl >>> From: Edward Lewis >>> Subject: provreg milestones >>> Cc: edlewis@arin.net, ietf-provreg@cafax.se >>> Bcc: >>> X-Attachments: >>> >>> While we still have an open issue with regards to privacy, I want >>>to move on and at least refresh the group's milestones. >>> >>> FEB 03 Respond to the IESG Comments (for Proposed) >>> MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational) >>> APR 03 Decision on Alternate Transports >>> SEP 03 Perform Interoperability Tests >>> OCT 03 Submit Interoperability Report to IESG (Informational) >>> OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft) >>> OCT 03 Submit EPP Contact Mapping to IESG (Draft) >>> OCT 03 Submit EPP Domain Name Mapping to IESG (Draft) >>> OCT 03 Submit EPP Host Mapping to IESG (Draft) >>> OCT 03 Submit EPP Transport Over TCP to IESG (Draft) >>> >>> Look these over carefully. I added the first because we haven't >>>closed that off, as well as having some potential threads to cover >>>in addition to the privacy question. >>> >>> A "Decision on Alternate Transports" is on there because our >>>charter talks about "support for multiple operational choices, >>>such as for transport". At times support has been expressed for >>>BEEP, SMTP, and SOAP, but none have garnered much support. My >>>vague opinion is that alternate transports will need to come with >>>code, not just documents, before they can be taken seriously by >>>the WG. >>> >>> Note that SMTP and SOAP milestones are not on there. Not to >>>denigrate the work, but they haven't made it to general interest >>>for the WG. >>> >>> With this message I am asking our AD to approve these milestones, >>>we can adjust them as necessary. >> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis +1-703-227-9854 >> ARIN Research Engineer >> > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h27FTlh3018270 for ; Fri, 7 Mar 2003 16:29:47 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27FTlLV018269 for ietf-provreg-outgoing; Fri, 7 Mar 2003 16:29:47 +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.8/8.12.8) with ESMTP id h27FTjh3018262 for ; Fri, 7 Mar 2003 16:29:45 +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 18rJmx-0002to-00; Fri, 07 Mar 2003 10:29:35 -0500 Message-ID: <3E68BDE8.AFEA0DB4@libertyrms.info> Date: Fri, 07 Mar 2003 10:42:32 -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" CC: "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry References: <3CD14E451751BD42BA48AAA50B07BAD60337077B@vsvapostal3.prod.netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically > > evaluate to 1, or 0? > > > > The answer to this is a determining factor (to me at least) of > > whether $dnp is in the base specification or in an extension. > > As far as .com is concerned, I have no doubt that an extension will be > required even if we were to adopt the IESG's element tagging suggestion. > That being the case, my preference would be to put _all_ of the DNP syntax > and semantics into an extension (where the problem can be addressed as a > whole) while making the existing DCP element mandatory if that resolves the > privacy issue with the IESG. Making existing DCP element mandatory and dealing with other specific privacy requirements within extensions looks to me like a better way of addressing privacy issues in EPP protocol than mandatory, binary DNP attribute. > > > -Scott- Janusz Sienkiewicz Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27FNAh3018175 for ; Fri, 7 Mar 2003 16:23:10 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27FNAlq018174 for ietf-provreg-outgoing; Fri, 7 Mar 2003 16:23:10 +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.8/8.12.8) with ESMTP id h27FN8h3018164 for ; Fri, 7 Mar 2003 16:23:08 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h27FMlWs003591; Fri, 7 Mar 2003 10:22:47 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303071522.h27FMlWs003591@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , Andrew Newton , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] proto-agenda In-Reply-To: Your message of "Fri, 07 Mar 2003 10:07:57 EST." Date: Fri, 07 Mar 2003 10:22:47 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > There is the expectation that this WG may stick around until we get > to DS. That means that we may remain active in spite of resolving > the IESG comment, getting PS documents and not spending time on > issues that have flared up and then seemed to go away (ROID). Understood. HTTP WG hung until Moore and Freed screwed around with Dave Krystol's state management mechanism draft. Too similar to the current wrangle for comfort. > In that case, discussing alt. transports at -57 might not be a bad idea. > > However, 1) no one can promise we will still be active then and 2) > starting a discussion on the mail list at any time is preferable for > waiting to start a discussion at an in-face meeting. Of course. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27F89h3017963 for ; Fri, 7 Mar 2003 16:08:09 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27F89iM017962 for ietf-provreg-outgoing; Fri, 7 Mar 2003 16:08:09 +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.8/8.12.8) with ESMTP id h27F88h3017957 for ; Fri, 7 Mar 2003 16:08:08 +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 h27F84JW046204; Fri, 7 Mar 2003 10:08:04 -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 KAA00406; Fri, 7 Mar 2003 10:08:03 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303071444.h27EiiWs003384@nic-naa.net> References: <200303071444.h27EiiWs003384@nic-naa.net> Date: Fri, 7 Mar 2003 10:07:57 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: [ietf-provreg] proto-agenda Cc: Edward Lewis , Andrew Newton , 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 I see no rush to define another transport, but keep these 'realities' in mind: There is the expectation that this WG may stick around until we get to DS. That means that we may remain active in spite of resolving the IESG comment, getting PS documents and not spending time on issues that have flared up and then seemed to go away (ROID). In that case, discussing alt. transports at -57 might not be a bad idea. However, 1) no one can promise we will still be active then and 2) starting a discussion on the mail list at any time is preferable for waiting to start a discussion at an in-face meeting. At 9:44 -0500 3/7/03, Eric Brunner-Williams in Portland Maine wrote: >Ed, > >There has been a note to the list about an implementation over HTTP. >All things considered, -56 time available, and proximity of -57 venue >to the implementor, that may be the better time to do other-than-tcp. > >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.8/8.12.8) with ESMTP id h27Ej4h3017672 for ; Fri, 7 Mar 2003 15:45:04 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h27Ej4LW017671 for ietf-provreg-outgoing; Fri, 7 Mar 2003 15:45:04 +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.8/8.12.8) with ESMTP id h27Ej2h3017666 for ; Fri, 7 Mar 2003 15:45:03 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h27EiiWs003384; Fri, 7 Mar 2003 09:44:44 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303071444.h27EiiWs003384@nic-naa.net> To: Edward Lewis cc: Andrew Newton , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] proto-agenda In-Reply-To: Your message of "Fri, 07 Mar 2003 09:18:19 EST." Date: Fri, 07 Mar 2003 09:44:44 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, There has been a note to the list about an implementation over HTTP. All things considered, -56 time available, and proximity of -57 venue to the implementor, that may be the better time to do other-than-tcp. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27EIPh3017112 for ; Fri, 7 Mar 2003 15:18:25 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27EIPSi017111 for ietf-provreg-outgoing; Fri, 7 Mar 2003 15:18: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.8/8.12.8) with ESMTP id h27EIOh3017106 for ; Fri, 7 Mar 2003 15:18: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 h27EILJW044636; Fri, 7 Mar 2003 09:18:21 -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 JAA21855; Fri, 7 Mar 2003 09:18:20 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3E67DD05.5030004@ecotroph.net> References: <3E67DD05.5030004@ecotroph.net> Date: Fri, 7 Mar 2003 09:18:19 -0500 To: Andrew Newton From: Edward Lewis Subject: Re: [ietf-provreg] proto-agenda Cc: Edward Lewis , ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Discussing alternate transports in in our charter: "The group will consider support for multiple operational choices, such as for transport..." So far, no transport other than TCP has sparked widespread interest. One person is touting SMTP, a few others expressed support for SOAP a few months ago. It doesn't appear that there's an alternative to TCP that is on the verge of being added as a WG item, but we are chartered to explore the possibility. Note too that the list of which this is a part is not an agenda list, but the remaining unresolved items from last time. If no one has any material to discuss in SF, then alternate transports won't appear on the agenda. At 18:43 -0500 3/6/03, Andrew Newton wrote: >Edward Lewis wrote: >> 2) Alternate transports > >Does this item need to be included? > >I just ran through the list, and the last talk of this seems to be >in December, which might be summarized as: 1) a new draft was >promised before Christmas (the current one expires this month), and >2) several people agreeing that it should be experimental. > >-andy -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h27DDWh3016298 for ; Fri, 7 Mar 2003 14:13:32 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27DDWqA016297 for ietf-provreg-outgoing; Fri, 7 Mar 2003 14:13:32 +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.8/8.12.8) with ESMTP id h27DDVh3016292 for ; Fri, 7 Mar 2003 14:13:31 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h27DDGWs003000; Fri, 7 Mar 2003 08:13:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303071313.h27DDGWs003000@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] proto-agenda In-Reply-To: Your message of "Thu, 06 Mar 2003 11:03:58 EST." Date: Fri, 07 Mar 2003 08:13:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk [non-attendee comments on proposed agenda.] > 3. Clarify the adoption of P3P concepts. Pointing out a specific defect in the element's sub-schema would be really useful. > 5. An SMTP mapping is all but dead in the water. > > Unless someone objects on the mail list, we're dropping all > milestones relating to SMTP. I object. > 8. Discuss 'lastVerified' - mandatory, extension or optional I think this is a bad idea sneaking in from some other policy area. I could be mistaken. > 9. Discuss handling of external hosts That should be interesting. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h27CPqW1015669 for ; Fri, 7 Mar 2003 13:25:52 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h27CPqeq015668 for ietf-provreg-outgoing; Fri, 7 Mar 2003 13:25: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.8/8.12.8) with ESMTP id h27CPoW1015661 for ; Fri, 7 Mar 2003 13:25:51 +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 HAA08482; Fri, 7 Mar 2003 07:25:43 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 07:23:15 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707AF@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Cc: jaap@sidn.nl Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones Date: Fri, 7 Mar 2003 07:23:14 -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 > Also to the group - as far as the privacy thing being resolved, I'm a > bit hesitant to declare consensus yet to the proposal in: > > # From: "Hollenbeck, Scott" > # Date: Mon, 3 Mar 2003 13:02:34 -0500 > # > # As far as .com is concerned, I have no doubt that an > extension will be > # required even if we were to adopt the IESG's element > tagging suggestion. > # That being the case, my preference would be to put _all_ of > the DNP syntax > # and semantics into an extension (where the problem can be > addressed as a > # whole) while making the existing DCP element mandatory if > that resolves the > # privacy issue with the IESG. > > (Aka - > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) > > So let me hear about that... Ed, please note these supporting comments sent prior to your note: http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00015.html http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00023.html -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h2711kW1010263 for ; Fri, 7 Mar 2003 02:01:46 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h2711knY010262 for ietf-provreg-outgoing; Fri, 7 Mar 2003 02: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.8/8.12.8) with ESMTP id h2711jW1010257 for ; Fri, 7 Mar 2003 02:01:45 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h2711Z2r039178; Thu, 6 Mar 2003 20:01:35 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303070101.h2711Z2r039178@nic-naa.net> To: "Hollenbeck, Scott" cc: "'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, 06 Mar 2003 19:27:46 EST." <3CD14E451751BD42BA48AAA50B07BAD6033707AD@vsvapostal3.prod.netsol.com> Date: Thu, 06 Mar 2003 20:01:35 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk The distinction between "social" (billing) and "technical" (zone files) is not quite the same as between registrar-retained-authoritative (RRP) and registry-retained-authoritative (EPP). If we're going to create two (or more) baskets to put data into, which would allow some alternate to the session-scoped that has basket-of-stuff-scope, then we need to define the baskets, but without dependency upon the distinction of RRP vs EPP, and "thin" vs "thick" registry models. Humor me. In a "pure thin EPP", there'd be no whois:43 issue for the protocol, the registry would never see anything but NS and A records. That liability would remain with the registrars and their whois servers. In a "pure thick EPP" (what we're writing), there is data that is published via 1034/35 (NS and A records), and data that is published via 954 (everything, including personally identifying registrant data). We can't define a distinction in a "pure thick EPP" specification by making direct, or indirect reference or comparison to the RRP model. At least, not without something like a dangling pointer. I've used "pure" in the para above because some registrars are also registries, though not necessarily of the same namespaces, and I want to ignore the complication of a registrar who is a whois operator (RRP) as well as a registry operator, and a registrar who is not a whois operator (EPP) as well as a registry operator that is a whois operator. That kind of stuff gets me dizzy. So, if we say publication via 1034/35, of A and NS records (we're domain name specific, at least momentarily, and "privacy/data collection" may not mean the same thing, or anything, in an address registry context, or other possible SRS contexts), _is_ technical data, and everything else isn't (which is almost what we had), then we may have a useful definition. It may help (or I may be going out unnecessarily on a limb) if we make the distinction between non-technical data and data that is sufficient to construct persistent unique identifiers. If it helps, in the 95/46/EC context, the 32 bits of an ipv4 endpoint identifer is subject to data collection disclosure, hence the (IMO lame) definition in P3P of a 25 bit addr as something other than "personally identifying" (a unique endpoint identifier, or one that can be resonably constructed from the collected data). Names, telnos, postals, ips fit into this. Admin and Tech contacts don't. Mind, the simpler course is to stay with a session-scoped policy dingus, and not dive into what data means what when and to whom. It may not seem like it, but I'm a big fan of _simple_. manditory. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h270UOW1010007 for ; Fri, 7 Mar 2003 01:30:24 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h270UNmS010006 for ietf-provreg-outgoing; Fri, 7 Mar 2003 01:30:23 +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.8/8.12.8) with ESMTP id h270UMW1010001 for ; Fri, 7 Mar 2003 01:30:23 +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 TAA16407; Thu, 6 Mar 2003 19:30:14 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 19:27:47 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707AD@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 6 Mar 2003 19:27:46 -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 > The problem with where we left off (in 3375 and with Ross' > -dn-), is that > we were letting the RRP vs EPP (thick/thin) act as our framework. Here > we need to look, not at who has the data, but at what data > has what kind > of function. Almost, but not quite, the same. This is where you start to lose me. What data functions (beyond the provisioning and management of the data itself) are in-scope for us? -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26NVaW1009431 for ; Fri, 7 Mar 2003 00:31:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26NVaat009430 for ietf-provreg-outgoing; Fri, 7 Mar 2003 00:31:36 +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.8/8.12.8) with ESMTP id h26NVZW1009425 for ; Fri, 7 Mar 2003 00:31:35 +0100 (MET) Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Thu, 06 Mar 2003 18:31:33 -0500 Message-ID: <3E67DD05.5030004@ecotroph.net> Date: Thu, 06 Mar 2003 18:43:01 -0500 From: Andrew Newton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] proto-agenda References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edward Lewis wrote: > > 2) Alternate transports Does this item need to be included? I just ran through the list, and the last talk of this seems to be in December, which might be summarized as: 1) a new draft was promised before Christmas (the current one expires this month), and 2) several people agreeing that it should be experimental. -andy Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26N6eW1009233 for ; Fri, 7 Mar 2003 00:06:40 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26N6eQa009232 for ietf-provreg-outgoing; Fri, 7 Mar 2003 00:06:40 +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.8/8.12.8) with ESMTP id h26N6cW1009227 for ; Fri, 7 Mar 2003 00:06:39 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h26N6R2r038772; Thu, 6 Mar 2003 18:06:27 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303062306.h26N6R2r038772@nic-naa.net> To: "Hollenbeck, Scott" cc: "'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, 06 Mar 2003 12:40:24 EST." <3CD14E451751BD42BA48AAA50B07BAD6033707A3@vsvapostal3.prod.netsol.com> Date: Thu, 06 Mar 2003 18:06:27 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: > > >adding attributes to elements is either pervasive, or > > specific. As this > > >WG lost the technical/social distinction with the expiry of > > Ross' draft, > > > > What parts of the material in Ross' draft need to be added (as > > terminology definitions) in the base spec (or base spec-bis)? > > Note that section 1.1 of requirements RFC 3375 includes parenthetical > descriptions for "social" and "technical" information in the definition of a > "thick" registry. See: Subject: Is it "social" or is it "model" or is it "mechanism"? Sent to this list on 02.13.03 We simply need to seperate the thick/thin (registry model) from the publication mechanisms (1034/35), and be dns-specific (for a change), and speak er, write about the RRs we provision, without being Master File Format specific (and triggering a valid DJB criticism). The problem with where we left off (in 3375 and with Ross' -dn-), is that we were letting the RRP vs EPP (thick/thin) act as our framework. Here we need to look, not at who has the data, but at what data has what kind of function. Almost, but not quite, the same. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26N5FW1009216 for ; Fri, 7 Mar 2003 00:05:15 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26N5FqH009215 for ietf-provreg-outgoing; Fri, 7 Mar 2003 00:05:15 +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.8/8.12.8) with ESMTP id h26N5EW1009207 for ; Fri, 7 Mar 2003 00:05:14 +0100 (MET) Received: from dev7.int.libertyrms.com ([10.1.2.225] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18r4QA-0006oy-00; Thu, 06 Mar 2003 18:05:02 -0500 Message-ID: <3E67D62A.3020609@libertyrms.info> Date: Thu, 06 Mar 2003 18:13:46 -0500 From: Daniel Manley User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.3b) Gecko/20030212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se, jaap@sidn.nl Subject: Re: [ietf-provreg] Fwd: Re: provreg milestones References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Here's my vote for consensus. Let's put this to rest. This solution addresses enough to declare privacy policy to EPP clients. With the variety of privacy policies out there in the world, putting client overrides into the extension framework keep this flexible for all parties involved. EPP's been all about extensibility from the start. Dan Edward Lewis wrote: > Also to the group - as far as the privacy thing being resolved, I'm a > bit hesitant to declare consensus yet to the proposal in: > > # From: "Hollenbeck, Scott" > # Date: Mon, 3 Mar 2003 13:02:34 -0500 > # > # As far as .com is concerned, I have no doubt that an extension will be > # required even if we were to adopt the IESG's element tagging > suggestion. > # That being the case, my preference would be to put _all_ of the DNP > syntax > # and semantics into an extension (where the problem can be addressed > as a > # whole) while making the existing DCP element mandatory if that > resolves the > # privacy issue with the IESG. > > (Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) > > So let me hear about that... > >> Date: Thu, 6 Mar 2003 21:48:31 +0100 >> Subject: Re: provreg milestones >> Cc: jaap@sidn.nl, Ted Hardie >> To: Edward Lewis >> From: Patrik Fältström >> X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) >> FILETIME=[C2ED4AE0:01C2E421] >> Status: >> >> This looks good. >> >> Please send the new milestones to iesg-secretary@ietf.org. >> >> I also understand the privacy thing is now resolved. I saw a few >> messages on the mailing list about it. >> >> May I suggest you (or someone) write a summary of what the solution >> is, and send it to me, randy, allison (and also cc Ned and Ted as >> co-AD's -- yes, Ted is formally not onboard, but anyway). You can of >> course also cc the mailing list if you want to. >> >> paf >> >> On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote: >> >>> I've heard no response to this from 'above.' >>> >>> The FEB 03 milestone now should be MAR 03 I guess. >>> >>>> Date: Fri, 31 Jan 2003 10:14:40 -0500 >>>> To: paf@cisco.com, jaap@sidn.nl >>>> From: Edward Lewis >>>> Subject: provreg milestones >>>> Cc: edlewis@arin.net, ietf-provreg@cafax.se >>>> Bcc: >>>> X-Attachments: >>>> >>>> While we still have an open issue with regards to privacy, I want >>>> to move on and at least refresh the group's milestones. >>>> >>>> FEB 03 Respond to the IESG Comments (for Proposed) >>>> MAR 03 Submit Guidelines for Extending the EPP to IESG >>>> (Informational) >>>> APR 03 Decision on Alternate Transports >>>> SEP 03 Perform Interoperability Tests >>>> OCT 03 Submit Interoperability Report to IESG (Informational) >>>> OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft) >>>> OCT 03 Submit EPP Contact Mapping to IESG (Draft) >>>> OCT 03 Submit EPP Domain Name Mapping to IESG (Draft) >>>> OCT 03 Submit EPP Host Mapping to IESG (Draft) >>>> OCT 03 Submit EPP Transport Over TCP to IESG (Draft) >>>> >>>> Look these over carefully. I added the first because we haven't >>>> closed that off, as well as having some potential threads to cover >>>> in addition to the privacy question. >>>> >>>> A "Decision on Alternate Transports" is on there because our >>>> charter talks about "support for multiple operational choices, >>>> such as for transport". At times support has been expressed for >>>> BEEP, SMTP, and SOAP, but none have garnered much support. My >>>> vague opinion is that alternate transports will need to come with >>>> code, not just documents, before they can be taken seriously by the >>>> WG. >>>> >>>> Note that SMTP and SOAP milestones are not on there. Not to >>>> denigrate the work, but they haven't made it to general interest >>>> for the WG. >>>> >>>> With this message I am asking our AD to approve these milestones, >>>> we can adjust them as necessary. >>> >>> >>> -- >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> 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.8/8.12.8) with ESMTP id h26LcDW1008376 for ; Thu, 6 Mar 2003 22:38:13 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26LcDl5008375 for ietf-provreg-outgoing; Thu, 6 Mar 2003 22:38:13 +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.8/8.12.8) with ESMTP id h26LcCW1008370 for ; Thu, 6 Mar 2003 22:38:12 +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 h26LcBJW030950; Thu, 6 Mar 2003 16:38:11 -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 QAA13229; Thu, 6 Mar 2003 16:38:10 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 6 Mar 2003 16:38:02 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] Fwd: Re: provreg milestones Cc: edlewis@arin.net, jaap@sidn.nl Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h26LcCW1008371 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Also to the group - as far as the privacy thing being resolved, I'm a bit hesitant to declare consensus yet to the proposal in: # From: "Hollenbeck, Scott" # Date: Mon, 3 Mar 2003 13:02:34 -0500 # # As far as .com is concerned, I have no doubt that an extension will be # required even if we were to adopt the IESG's element tagging suggestion. # That being the case, my preference would be to put _all_ of the DNP syntax # and semantics into an extension (where the problem can be addressed as a # whole) while making the existing DCP element mandatory if that resolves the # privacy issue with the IESG. (Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html) So let me hear about that... >Date: Thu, 6 Mar 2003 21:48:31 +0100 >Subject: Re: provreg milestones >Cc: jaap@sidn.nl, Ted Hardie >To: Edward Lewis >From: Patrik Fältström >X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) >FILETIME=[C2ED4AE0:01C2E421] >Status: > >This looks good. > >Please send the new milestones to iesg-secretary@ietf.org. > >I also understand the privacy thing is now resolved. I saw a few >messages on the mailing list about it. > >May I suggest you (or someone) write a summary of what the solution >is, and send it to me, randy, allison (and also cc Ned and Ted as >co-AD's -- yes, Ted is formally not onboard, but anyway). You can of >course also cc the mailing list if you want to. > > paf > >On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote: > >> I've heard no response to this from 'above.' >> >> The FEB 03 milestone now should be MAR 03 I guess. >> >>> Date: Fri, 31 Jan 2003 10:14:40 -0500 >>> To: paf@cisco.com, jaap@sidn.nl >>> From: Edward Lewis >>> Subject: provreg milestones >>> Cc: edlewis@arin.net, ietf-provreg@cafax.se >>> Bcc: >>> X-Attachments: >>> >>> While we still have an open issue with regards to privacy, I want >>>to move on and at least refresh the group's milestones. >>> >>> FEB 03 Respond to the IESG Comments (for Proposed) >>> MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational) >>> APR 03 Decision on Alternate Transports >>> SEP 03 Perform Interoperability Tests >>> OCT 03 Submit Interoperability Report to IESG (Informational) >>> OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft) >>> OCT 03 Submit EPP Contact Mapping to IESG (Draft) >>> OCT 03 Submit EPP Domain Name Mapping to IESG (Draft) >>> OCT 03 Submit EPP Host Mapping to IESG (Draft) >>> OCT 03 Submit EPP Transport Over TCP to IESG (Draft) >>> >>> Look these over carefully. I added the first because we haven't >>>closed that off, as well as having some potential threads to cover >>>in addition to the privacy question. >>> >>> A "Decision on Alternate Transports" is on there because our >>>charter talks about "support for multiple operational choices, >>>such as for transport". At times support has been expressed for >>>BEEP, SMTP, and SOAP, but none have garnered much support. My >>>vague opinion is that alternate transports will need to come with >>>code, not just documents, before they can be taken seriously by >>>the WG. >>> >>> Note that SMTP and SOAP milestones are not on there. Not to >>>denigrate the work, but they haven't made it to general interest >>>for the WG. >>> >>> With this message I am asking our AD to approve these milestones, >>>we can adjust them as necessary. >> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis +1-703-227-9854 >> ARIN Research Engineer >> > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h26Hh1W1005865 for ; Thu, 6 Mar 2003 18:43:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26Hh1fA005864 for ietf-provreg-outgoing; Thu, 6 Mar 2003 18:43:01 +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.8/8.12.8) with ESMTP id h26HgxW1005858 for ; Thu, 6 Mar 2003 18:42:59 +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 MAA24263; Thu, 6 Mar 2003 12:42:52 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 12:40:15 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6033707A3@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 6 Mar 2003 12:40:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: > >adding attributes to elements is either pervasive, or > specific. As this > >WG lost the technical/social distinction with the expiry of > Ross' draft, > > What parts of the material in Ross' draft need to be added (as > terminology definitions) in the base spec (or base spec-bis)? Note that section 1.1 of requirements RFC 3375 includes parenthetical descriptions for "social" and "technical" information in the definition of a "thick" registry. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26GqbW1005140 for ; Thu, 6 Mar 2003 17:52:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26Gqb0q005139 for ietf-provreg-outgoing; Thu, 6 Mar 2003 17:52:37 +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.8/8.12.8) with ESMTP id h26GohW1005095 for ; Thu, 6 Mar 2003 17:50: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 h26GogJW014685; Thu, 6 Mar 2003 11:50:42 -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 LAA18606; Thu, 6 Mar 2003 11:49:21 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303031547.h23FlqtY079531@nic-naa.net> References: <200303031547.h23FlqtY079531@nic-naa.net> Date: Thu, 6 Mar 2003 11:14:32 -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" , "'Edward Lewis'" , "'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 At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: >adding attributes to elements is either pervasive, or specific. As this >WG lost the technical/social distinction with the expiry of Ross' draft, What parts of the material in Ross' draft need to be added (as terminology definitions) in the base spec (or base spec-bis)? >954 that is of issue, particularly in the EU, but also in the OEDC, and What is OEDC? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h26GokW1005102 for ; Thu, 6 Mar 2003 17:50:46 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26GokFv005101 for ietf-provreg-outgoing; Thu, 6 Mar 2003 17:50: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.8/8.12.8) with ESMTP id h26GojW1005096 for ; Thu, 6 Mar 2003 17:50:45 +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 h26GoiJW014691; Thu, 6 Mar 2003 11:50:44 -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 LAA18931; Thu, 6 Mar 2003 11:50:43 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303041237.HAD10017.NBPO@humeia.ad.jp> References: <200303041237.HAD10017.NBPO@humeia.ad.jp> Date: Thu, 6 Mar 2003 11:30:19 -0500 To: Hideki Noma From: Edward Lewis Subject: Re: [ietf-provreg] URL element in contact mapping Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk The WG (which is the mailing list) has not heard of this before, so we are unable to send you a reference. We would appreciate more information on this topic so that the protocol is capable of handling all it needs to handle. At 12:37 +0900 3/4/03, Hideki Noma wrote: >Hello, > >There will be a URL element introduced in .JP contact information in >near future. >And I beleive that some sort of element representing a URL of domain >owner or contact >is necessary.In fact whois.internic.net has both url element of >whois server and >web server. > >I understand that url element should be optional or even, extention >implemented by registrars, >however the element name must be standardized. I don't know why JP >registry is not commenting on >this but as one of JP registrar, I strongly request it. > >If there has been a discussion around this topic I've missed it, >please point me >where to look at. > >Hideki Noma >Humeia Limited Partnership -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h26G4BW1004451 for ; Thu, 6 Mar 2003 17:04:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26G4BlA004450 for ietf-provreg-outgoing; Thu, 6 Mar 2003 17:04:11 +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.8/8.12.8) with ESMTP id h26G4AW1004445 for ; Thu, 6 Mar 2003 17:04:10 +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 h26G44JW012590 for ; Thu, 6 Mar 2003 11:04:04 -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 LAA09958; Thu, 6 Mar 2003 11:04:03 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 6 Mar 2003 11:03:58 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] proto-agenda Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Based on what I've seen on the list: 1) Getting to the bottom of the privacy issue - the one in front of us, that is. 2) Alternate transports 3) IDN in EPP Does anyone still want to discuss a problem with ROID? Here are action items I recorded in December: 1. Respond to the IESG comments. Most of the comments are easily addressed. A few need further discussion (and are listed as separate action items). 2. Come to a final understanding of UDP and EPP. There have been some words posted to the "outlawing" of UDP, one response was to require stream based protocols. 3. Clarify the adoption of P3P concepts. P3P was written for website environments, not a business to business situation. This is reflected in some of our examples and needs to be cleaned up. Rick Wesson volunteered to summarize a discussion on privacy issues. It might be up to us to forge new ground here as we are one of the few protocols that gathers personal information (for registration information). 4. Whether or not we adopt a work item for the SOAP 'as transport' draft. A thread has been started on the list, but the results are luke warm for now. 5. An SMTP mapping is all but dead in the water. Unless someone objects on the mail list, we're dropping all milestones relating to SMTP. 6. Continue to progress on Guidelines. No sense of urgency, at least not until we get #1 above done. Two other action items... 7. Clean up the milestones. After the meeting we talked and decided that the milestones on the web page aren't sufficiently descriptive. Before fixing them, #4 and #5 need answers. 8. Discuss 'lastVerified' - mandatory, extension or optional 9. Discuss handling of external hosts -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.8/8.12.8) with ESMTP id h26DCrW1002563 for ; Thu, 6 Mar 2003 14:12:53 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h26DCrlA002562 for ietf-provreg-outgoing; Thu, 6 Mar 2003 14:12: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.8/8.12.8) with ESMTP id h26DCnW1002557 for ; Thu, 6 Mar 2003 14:12:52 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h26DCXKI027905; Thu, 6 Mar 2003 08:12:33 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303061312.h26DCXKI027905@nic-naa.net> To: Vittorio Bertola cc: 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, 06 Mar 2003 10:06:02 +0100." <7i2e6vo2jt88gtur2jupb3ok5uf5oc5a8m@4ax.com> Date: Thu, 06 Mar 2003 08:12:33 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk CRISP, WHOISFIX, NOT43, ... deal with publication protocols. DNSOP, DNSSEC, ... also deal with publication protocls. Generally, they start with some authoritative instance of some datum, and unconditionally replicate non-authoritative copies of that datum. The access and persistence properties of these do not subset the maximums for both generally. PROVREG and its anticeedents, the DOMREG BoF(s) and the authors of RRP, ... deal with provisioning protocols. Generally, they start with some non-authoritative instance of some datum, and conditionally allocate an authoritative instance of that datum. The access and persistence properties of these subset the maximums for both generally. OTHER PUBLICATION PROTOCOLS EXIST. Bulk copy, with "sale", "lease" and "rent" of mailing lists, postal and electronic, exists. Some implementations use "sneaker net". Other technical mechanisms, which exploit properties of domain name data in particular, the nameserver, technical and administrative contact, even the character space properties of a domain name (marks, soundex, Hamming Distrance from, ...) which REPURPOSE data, also exist. Data provisioned via protocol (RRP, SRS, EPP, ... NEXT) may be merged with data acquired by other means. Since the beginning of this Working Group, there have been contributors who want to "solve" the 954 problem within EPP. This approach does not solve for other publication mechanisms, nor does it solve for the user informed portion of the informed consent meta-requirement placed on all data collectors by 95/46/EC and related texts that address directories, and related tools for the management of endpoint identifiers which may identify individual persons. If the better reading of 95/46/EC et seq. is that it applies to port 43, and originators need only (may only) make port-specific negative assertions, then a "publication" framework (yours and others, e.g., the IESG) may be sufficient. Having done this twice before, I don't think so. Besides, I don't know that EPP can't be used for keyword systems, that may not use :43, and for anything similar. It would work for the US, and anywhere else where the IAB (the other one, the Internet Advertising Board) and the DMA (Direct Marketing Association) and similar trade groups control the "opt-in vs opt-out" policy issue. I now know it would work in Holland also. I don't understand this, but the European Data Commissioners I've communicated with over the past three years are French and German, so I've obviously missed something. Pointing out a specific defect in the element's sub-schema would be really useful. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h26955W1029775 for ; Thu, 6 Mar 2003 10:05:05 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h26955Cb029774 for ietf-provreg-outgoing; Thu, 6 Mar 2003 10:05:05 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from lazzaro.bertola.eu.org (net-197-95.noicomnet.it [194.153.197.95]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h26951W1029766 for ; Thu, 6 Mar 2003 10:05:02 +0100 (MET) Received: (qmail 19204 invoked from network); 6 Mar 2003 09:12:35 -0000 Received: from unknown (HELO PIETRO) (10.0.1.2) by 0 with SMTP; 6 Mar 2003 09:12:35 -0000 From: Vittorio Bertola To: Eric Brunner-Williams in Portland Maine Cc: "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Thu, 06 Mar 2003 10:06:02 +0100 Message-ID: <7i2e6vo2jt88gtur2jupb3ok5uf5oc5a8m@4ax.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337076C@vsvapostal3.prod.netsol.com> <200303031547.h23FlqtY079531@nic-naa.net> In-Reply-To: <200303031547.h23FlqtY079531@nic-naa.net> X-Mailer: Forte Agent 1.9/32.560 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h26952W1029767 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 03 Mar 2003 10:47:52 -0500, you wrote: >> The third is a message describing the EU perspective on why this must >> be solved. > >Oh thank heavens! A live EU national who is a self-described "newbie" and >neither an implementor, nor an operator, nor an author, nor apparently a >specification reader. Now I can stop thinking. Just for the sake of precision... I am an ICT engineer, I've been reading and using RFCs for the last 8 years, and I am sufficiently geek to often use e-mail by telnet 25/110 :-) I do not work in the domain name business and I am a newbie in this working group, and this is why I don't want to make suggestions about the technicalities, given that you all here have been discussing them for years. So I'm just lurking the list as often as I can. But the CRISP group has found my suggestions useful enough to include them in the latest CRISP requirements draft. >Note Bene Chair: > 1. IESG (Randy or Allison) asked and answered > 2. IESG (Patrick) asked and answered > 3. .NL asked and not responsive > 4. .PL asked and not responsive > 5. Newbie noises My intention was not to produce "noise" but just to help the group understanding the issues at stake from a different perspective. Please pardon me if I failed in this. (However this thread is going off topic, so please consider replying in private.) -- vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h262p3W1026965 for ; Thu, 6 Mar 2003 03:51:03 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h262p3C5026964 for ietf-provreg-outgoing; Thu, 6 Mar 2003 03:51:03 +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.8/8.12.8) with ESMTP id h262p1W1026959 for ; Thu, 6 Mar 2003 03:51:02 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h262orKI025629 for ; Wed, 5 Mar 2003 21:50:58 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303060250.h262orKI025629@nic-naa.net> To: ietf-provreg@cafax.se Subject: [ietf-provreg] Synchronisity Date: Wed, 05 Mar 2003 21:50:53 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk All, Context - new IRTF trainwreck, gazillion opinion posts posing as charter wrangles. In a nutshell ... >> ...which violates german privacy laws... > I guess different cultures have different ideas of privacy... We're not alone. There is unintelligent life in the universe. Eric P.S. To be cheritable, relay is in theory some form of onward-transport problem. Contrast this with geopriv, which is a captive-leaf (roaming) problem. Geopriv has done a new document cycle, if anyone cares. ------- Forwarded Message From: Keith Moore To: Hadmut Danisch Cc: moore@cs.utk.edu, raymie@cs.ucsc.edu, Asrg@ietf.org Subject: Re: [Asrg] desirable characteristics of source tracking (was: Requirements for source tracking) ... > > > > What I might like to know are things like: > > > > a. is the sender's account new, or has it been around awhile? > > b. does the source ISP have a reliable way to bill the sender? > > (or is this from someone who got a 100 hours free CD in the mail?) > > c. have there been many complaints about mail from this sender? > > > ...which violates german privacy laws... > > Privacy is fortunately highly protected over here. let me get this straight - it's not a violation of privacy to insist on knowing the real identity of someone who sent a message, but it is a violation of privacy to provide a slight bit of additional information about an anonymous or pseudonymous sender? I guess different cultures have different ideas of privacy... that's okay - there's no reqirement for the ISP to provide such information. but if the ISP can legally do so, and is willing to do so, then the sender can provide preferential treatment of the message. I don't think we're going to end up with a uniform global solution for spam in any case, because different people and different cultures vary not only according to what kinds of protection they consider important, but also in what they consider offensive or unacceptable. Keith _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg ------- End of Forwarded Message Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24GamW1004517 for ; Tue, 4 Mar 2003 17:36:48 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24Gam7Z004516 for ietf-provreg-outgoing; Tue, 4 Mar 2003 17:36: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.8/8.12.8) with ESMTP id h24GajW1004510 for ; Tue, 4 Mar 2003 17:36: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 h24GYftY083827; Tue, 4 Mar 2003 11:34:41 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041634.h24GYftY083827@nic-naa.net> To: Jaap Akkerhuis cc: 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, 04 Mar 2003 16:31:02 +0100." <200303041531.h24FV2pE026589@bartok.sidn.nl> Date: Tue, 04 Mar 2003 11:34:41 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Two followups for a charater change. Covered in my prior reply. > You said: > > 1. Application of the IESG proposal to "technical" data. > ... > other than error upon query or transform. I can't imagine an application > to an address registry's operational practices, but I don't have direct > knowledge of address registry or registrar operational art. > > That shows. Note I said, that this was a hypothetical case. OK. We're past technical issues, and on to list dysfunction. It is a small matter. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24FwbW1004030 for ; Tue, 4 Mar 2003 16:58:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24Fwb4m004029 for ietf-provreg-outgoing; Tue, 4 Mar 2003 16:58: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.8/8.12.8) with ESMTP id h24FwYW1004021 for ; Tue, 4 Mar 2003 16:58:36 +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 h24FuWtY083735; Tue, 4 Mar 2003 10:56:32 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041556.h24FuWtY083735@nic-naa.net> To: Jaap Akkerhuis cc: 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, 04 Mar 2003 16:31:02 +0100." <200303041531.h24FV2pE026589@bartok.sidn.nl> Date: Tue, 04 Mar 2003 10:56:32 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Jaap, The third URL should have a value one greater than the second, it was cut and paste, and I only noticed after send. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24FV5W1003657 for ; Tue, 4 Mar 2003 16:31:05 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24FV5uv003656 for ietf-provreg-outgoing; Tue, 4 Mar 2003 16:31:05 +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.8/8.12.8) with ESMTP id h24FV3W1003651 for ; Tue, 4 Mar 2003 16:31:03 +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 h24FV2pE026589; Tue, 4 Mar 2003 16:31:02 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303041531.h24FV2pE026589@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Tue, 04 Mar 2003 07:22:16 -0500. <200303041222.h24CMGtY082995@nic-naa.net> Date: Tue, 04 Mar 2003 16:31:02 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk It appears I did read that. I replied with about 60 lines of comment in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html and a one character correction in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html and followed up with http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html Two followups for a charater change. You said: 1. Application of the IESG proposal to "technical" data. The .NL registry defines (hypothetically of course) a dnp==true value for one or more elements as an error condition, and presumably returns some error code. Someone, Scott if my memory serves, mentioned a registry which defines a dnp==true value for one or more elements as a non-error, and presumably returns something other than an error code. Is using EPP with dcp==true for technical data a good thing? I see it as an operation to modify the string-space, with no external manifestation, other than error upon query or transform. I can't imagine an application to an address registry's operational practices, but I don't have direct knowledge of address registry or registrar operational art. That shows. Note I said, that this was a hypothetical case. 2. Application of the IESG proposal to "social" data at a registry. The .NL registry anticipates (effective 29 Jan 2003) operating under the general framework of a European Union member state's Data Protection Act. Consistent with the general framework of EU's Data Protection Directives, the access, purpose, recipient, and retention are all contractually defined. This is not generally the case for registries operating outside of the EU, nor for registrars and resellers operating outside of the EU. It would be helpful if the details of data protection between a non-EU resident .NL regsitrar and the .NL registry were available, assuming any exist. Note that we do this under dutch law. If registrars and registrations doesn't want to confirm to that, there is no point in registrting in .NL. 3. Existance of the PROVREG proposal, in the presence of the IESG proposal. Would the .NL registry operator use both the session-level data, and the element-level opt-{in|out} data? If the answer is "no", as I suspect it is, then use either a) is error, or b) is silently discarded. No, it is not discarded. Reread. And I din't mentioned both elements at all. If the answer is "yes", which takes precidence in the event of conflict? Trying to keep concrete, data originates from a registrant and is collected by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is provisioned to a .EU-Registry. Is the mechanism that provides the guidance for operational art at each onward-transport entity out-of-band (contract), or is it in-band, and if in-band, did the IESG proposal provide the same policy at each collector/onward-transporter as the European Union member state's Data Protection Act? I don't think so. I could be wrong. A p|np toggle is fine if purpose/recipient/retention/access are already taken care of (the Data Protection case). Where they are not, (OEDC and US cases), a p|np toggle may solve the 954 problem. How it can be applied to non-954 (and 954bis) is not stated. Deliver text. jaap Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24E0UW1002513 for ; Tue, 4 Mar 2003 15:00:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h24E0Ud0002512 for ietf-provreg-outgoing; Tue, 4 Mar 2003 15:00:30 +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.8/8.12.8) with ESMTP id h24E0SW1002507 for ; Tue, 4 Mar 2003 15:00:28 +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 h24DwOtY083345; Tue, 4 Mar 2003 08:58:24 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041358.h24DwOtY083345@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , "Rick Wesson" , ietf-provreg@cafax.se, "Edward Lewis" , brunner@nic-naa.net Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: Your message of "Tue, 04 Mar 2003 08:40:32 EST." <047d01c2e253$a2e36650$6801a8c0@neteka.inc> Date: Tue, 04 Mar 2003 08:58:24 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk so, in a nutshell, you'd like a mechanism that allows for the expression of some new semantic, in particular, some form of equivalence class(es), where the semantics of "equivalence" is some property of some provisioned object. we had this at one point, in one form. containers. mind, it wasn't for octet or sequenct of octets equivalence classes (however defined). well, if you can find a general expression, i'd be interested in reading it. cheers, eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24DfBW1002286 for ; Tue, 4 Mar 2003 14:41:11 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h24DfBqX002285 for ietf-provreg-outgoing; Tue, 4 Mar 2003 14:41:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h24Df9W1002280 for ; Tue, 4 Mar 2003 14:41:10 +0100 (MET) Message-ID: <047d01c2e253$a2e36650$6801a8c0@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , "Rick Wesson" , , "Edward Lewis" References: <200303041308.h24D8EtY083151@nic-naa.net> Subject: Re: [ietf-provreg] our meeting slot in SF Date: Tue, 4 Mar 2003 08:40:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" > > And, I think what we want to discuss in this work group is not the actual > > "mapping tables", but the framework for doing provisioning. > > What part is "interoperable", and subject to specification, assuming that > a requirements statement exists, or can be frobbed up in finite time? The framework of the provisioning should be interoperable and subject to specification. For example, on domain create, the response should contain a list of "reserved variants". The annoucement of the list and the types of reserved variants could be specified. The actual list would be based on the registry policy. > > It has more to do with how the management of reserved variants and zone > > variants can be provisioned. > > This doesn't seem to be a likely candidate for "interoperable", etc. The policy itself would not be of the interest of this discussion. Rather the provisioning protocol should be. For further example, on query for domain info there should be additional list that contains the reserved variants and zone variants. Also for domain update, there should be ways to manage the reserved variants and zone variants. These could all be standardized even if the particular zone policies are different. Just like some TLDs might consider fax number to be "required" and some "optional", but the provisioning protocol supports the communication of fax numbers. Edmon Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24DAZW1001940 for ; Tue, 4 Mar 2003 14:10:35 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h24DAZJu001939 for ietf-provreg-outgoing; Tue, 4 Mar 2003 14:10:35 +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.8/8.12.8) with ESMTP id h24DAWW1001934 for ; Tue, 4 Mar 2003 14:10:34 +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 h24D8EtY083151; Tue, 4 Mar 2003 08:08:14 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041308.h24D8EtY083151@nic-naa.net> To: "Edmon Chung" cc: "Eric Brunner-Williams in Portland Maine" , "Rick Wesson" , ietf-provreg@cafax.se, "Edward Lewis" , brunner@nic-naa.net Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: Your message of "Mon, 03 Mar 2003 14:23:42 EST." <024601c2e1ba$685542e0$6801a8c0@neteka.inc> Date: Tue, 04 Mar 2003 08:08:14 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I thought you didnt like the idea... ;-D Correct. > And, I think what we want to discuss in this work group is not the actual > "mapping tables", but the framework for doing provisioning. What part is "interoperable", and subject to specification, assuming that a requirements statement exists, or can be frobbed up in finite time? > It has more to do with how the management of reserved variants and zone > variants can be provisioned. This doesn't seem to be a likely candidate for "interoperable", etc., but by all means, don't listen to me, you've bet your business that I'm wrong and dns operators are just dying to shell out shell metacharacters to the clammoring masses. She sells sea shells by the sea shore ... and in zone files. Cheers, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h24COIW1001362 for ; Tue, 4 Mar 2003 13:24:18 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h24COI6E001361 for ietf-provreg-outgoing; Tue, 4 Mar 2003 13:24:18 +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.8/8.12.8) with ESMTP id h24COGW1001356 for ; Tue, 4 Mar 2003 13:24:17 +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 h24CMGtY082995; Tue, 4 Mar 2003 07:22:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303041222.h24CMGtY082995@nic-naa.net> To: Jaap Akkerhuis cc: 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, 04 Mar 2003 10:57:36 +0100." <200303040957.h249vbpE038572@bartok.sidn.nl> Date: Tue, 04 Mar 2003 07:22:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Really? It seems that Scott (ages ago, London-context) said "contracts" as > the mechanism. I'm sorry but I don't know which earlier response you are > referring to. Could you provide a date? I'll read it. > > http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html It appears I did read that. I replied with about 60 lines of comment in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html and a one character correction in http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html and followed up with http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html Well, my baby wants pick-up, and she won't wait 9 weeks until I get around to paying attention to her needs. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h249vfW1029952 for ; Tue, 4 Mar 2003 10:57:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h249vfKK029951 for ietf-provreg-outgoing; Tue, 4 Mar 2003 10:57:41 +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.8/8.12.8) with ESMTP id h249veW1029946 for ; Tue, 4 Mar 2003 10:57:40 +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 h249vbpE038572; Tue, 4 Mar 2003 10:57:37 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303040957.h249vbpE038572@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 16:03:58 -0500. <200303032103.h23L3wtY080755@nic-naa.net> Date: Tue, 04 Mar 2003 10:57:36 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Really? It seems that Scott (ages ago, London-context) said "contracts" as the mechanism. I'm sorry but I don't know which earlier response you are referring to. Could you provide a date? I'll read it. http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html jaap Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h243v3W1027322 for ; Tue, 4 Mar 2003 04:57:03 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.8/8.12.8/Submit) id h243v399027321 for ietf-provreg-outgoing; Tue, 4 Mar 2003 04:57:03 +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.8/8.12.8) with ESMTP id h243v1W1027316 for ; Tue, 4 Mar 2003 04:57:02 +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 h243t6tY081683; Mon, 3 Mar 2003 22:55:06 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303040355.h243t6tY081683@nic-naa.net> To: Hideki Noma cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: [ietf-provreg] URL element in contact mapping In-Reply-To: Your message of "Tue, 04 Mar 2003 12:37:33 +0900." <200303041237.HAD10017.NBPO@humeia.ad.jp> Date: Mon, 03 Mar 2003 22:55:06 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hideki, I don't think there has been any discussion around this topic. Why don't you start to suggest how to specify this? Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.8/8.12.8) with ESMTP id h243c1W1027151 for ; Tue, 4 Mar 2003 04:38:01 +0100 (MET) Received: by nic.cafax.se (8.12.8/8.12.8/Submit) id h243c19r027150 for ietf-provreg-outgoing; Tue, 4 Mar 2003 04:38:01 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from as01.tabata.noc.humeia.net (as01.tabata.noc.humeia.net [210.156.80.71] (may be forged)) by nic.cafax.se (8.12.8/8.12.8) with SMTP id h243bwW1027145 for ; Tue, 4 Mar 2003 04:37:59 +0100 (MET) Received: (qmail 12846 invoked by uid 0); 4 Mar 2003 03:38:15 -0000 Received: from dhcp01.kanda.noc.humeia.ad.jp (HELO noma) (noma@tabata.humeia.net@61.195.157.157) by as01.tabata.noc.humeia.net with SMTP; 4 Mar 2003 03:38:15 -0000 To: ietf-provreg@cafax.se Subject: [ietf-provreg] URL element in contact mapping From: Hideki Noma Message-Id: <200303041237.HAD10017.NBPO@humeia.ad.jp> X-Mailer: Winbiff without EditX [Version 2.41] X-Accept-Language: ja,en Date: Tue, 4 Mar 2003 12:37:33 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hello, There will be a URL element introduced in .JP contact information in near future. And I beleive that some sort of element representing a URL of domain owner or contact is necessary.In fact whois.internic.net has both url element of whois server and web server. I understand that url element should be optional or even, extention implemented by registrars, however the element name must be standardized. I don't know why JP registry is not commenting on this but as one of JP registrar, I strongly request it. If there has been a discussion around this topic I've missed it, please point me where to look at. Hideki Noma Humeia Limited Partnership 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 h23L5poE018581 for ; Mon, 3 Mar 2003 22:05:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23L5p03018580 for ietf-provreg-outgoing; Mon, 3 Mar 2003 22:05:51 +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 h23L5ooE018575 for ; Mon, 3 Mar 2003 22:05: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 h23L3wtY080755; Mon, 3 Mar 2003 16:03:58 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303032103.h23L3wtY080755@nic-naa.net> To: Jaap Akkerhuis cc: 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 "Mon, 03 Mar 2003 21:32:57 +0100." <200303032032.h23KWvue035982@bartok.sidn.nl> Date: Mon, 03 Mar 2003 16:03:58 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'm not twisting your words, I'm not doing anything but try to get to the bottom of something. > Correct. > > So there no semantic consequence to the registrar being, or not being, > "based within the European Union." > > Not with respect of the privacy issues. That is under Dutch regulation, > as I have said before. OK. http://www.nic.nl/sidn/flat/Deelnemers/Deelnemer_worden/index.html is garbage, in this context. > The registrar may (hypothetically) provision some datum to the .nl registry, > with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with > out difference, independent of the registrar's location. Is this correct? > > Yup, see above. Good. > What contract? > > Between registry and registrar. > > Better still, if a registrar doesn't need to signal in-band it accepts > anything, then it doesn't need to even know whatever that useless thing > is. > > You are twiting words. See my earlier response how this might work. Really? It seems that Scott (ages ago, London-context) said "contracts" as the mechanism. I'm sorry but I don't know which earlier response you are referring to. Could you provide a date? I'll read it. > 8.4 has a MUST in it, which appears to have no meaning at all if I > finally understand you. Everything is in the contract -- Scott's opening > position, that bilateral out-of-band mechanism (contract) covered the > requirement. > > A MUST in a requirement document might work out differently in practice. In theory ... Yeah. Patrick's quote. > Well, you're a co-chair, so I guess we're finnished with > > The protocol MUST provide services to identify data collection policies. > > and are on to > > "the proper element in the protocol which help to implement a policy" > > Gosh this is such fun. Not. > > I was not talking as co-chair. > > jaap > These two sentences mean very different kinds of things. One attempts to describe a non-trivial policy space, without knowing a priori the constraints. A mechanism of description. A "what". One attempts to select from a set of elements (generally) the one(s) which can effect a particular policy (possibly pluralized). A mechanism of effectation. A "how". Usually "how" comes after "what" (except in cowboy and indian movies), not as an alternative to "what". 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 h23KWwoE018152 for ; Mon, 3 Mar 2003 21:32:58 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23KWwsx018151 for ietf-provreg-outgoing; Mon, 3 Mar 2003 21:32:58 +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 h23KWvoE018146 for ; Mon, 3 Mar 2003 21:32:57 +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 h23KWvue035982; Mon, 3 Mar 2003 21:32:57 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303032032.h23KWvue035982@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 14:57:46 -0500. <200303031957.h23JvktY080504@nic-naa.net> Date: Mon, 03 Mar 2003 21:32:57 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Correct. So there no semantic consequence to the registrar being, or not being, "based within the European Union." Not with respect of the privacy issues. That is under Dutch regulation, as I have said before. The registrar may (hypothetically) provision some datum to the .nl registry, with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with out difference, independent of the registrar's location. Is this correct? Yup, see above. What contract? Between registry and registrar. Better still, if a registrar doesn't need to signal in-band it accepts anything, then it doesn't need to even know whatever that useless thing is. You are twiting words. See my earlier response how this might work. 8.4 has a MUST in it, which appears to have no meaning at all if I finally understand you. Everything is in the contract -- Scott's opening position, that bilateral out-of-band mechanism (contract) covered the requirement. A MUST in a requirement document might work out differently in practice. Well, you're a co-chair, so I guess we're finnished with The protocol MUST provide services to identify data collection policies. and are on to "the proper element in the protocol which help to implement a policy" Gosh this is such fun. Not. I was not talking as co-chair. 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 h23KAMoE017853 for ; Mon, 3 Mar 2003 21:10:22 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23KAMd7017852 for ietf-provreg-outgoing; Mon, 3 Mar 2003 21:10:22 +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 h23KALoE017847 for ; Mon, 3 Mar 2003 21:10:21 +0100 (MET) Received: from [10.1.2.195] (helo=DUN435) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18pwGM-0003se-00; Mon, 03 Mar 2003 15:10:14 -0500 From: "Michael Young" To: "'Ross Wm. Rader'" , "'Hollenbeck, Scott'" , "'Edward Lewis'" , Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Mon, 3 Mar 2003 15:10:10 -0500 Message-ID: <009f01c2e1c0$e4964920$c302010a@DUN435> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <533274406.1046699428@[10.0.11.248]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk Likewise, we are also happy with that approach. Michael Young -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Ross Wm. Rader Sent: March 3, 2003 1:50 PM To: Hollenbeck, Scott; 'Edward Lewis'; 'ietf-provreg@cafax.se' Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry --On Monday, March 03, 2003 1:02 PM -0500 "Hollenbeck, Scott" mentioned that: > That being the case, my preference would be to put _all_ of the DNP > syntax and semantics into an extension (where the problem can be > addressed as a > whole) while making the existing DCP element mandatory We'd be happy with that as well. regards, -rwr "There's a fine line between fishing and standing on the shore like an idiot." - Steven Wright Get Blog... http://www.byte.org/ 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 h23JxcoE017687 for ; Mon, 3 Mar 2003 20:59:38 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JxcTX017686 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:59:38 +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 h23JxboE017681 for ; Mon, 3 Mar 2003 20:59:37 +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 h23JvktY080504; Mon, 3 Mar 2003 14:57:46 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031957.h23JvktY080504@nic-naa.net> To: Jaap Akkerhuis cc: 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 "Mon, 03 Mar 2003 20:13:16 +0100." <200303031913.h23JDGue035618@bartok.sidn.nl> Date: Mon, 03 Mar 2003 14:57:46 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > [Category I participation Category I participation is open > to businesses and institutions based within the European Union.] > >Oh that. I thought that it was lifted. But it is still completely >irrelevant for the privacy discussion. OK. What, if anything, is relevant? > The "us" (parties having the capacity to register domain names on behalf > of clients) for which "the non-disclose attribute will work" appears to > be a scoped set of (eventual) EPP participants. The charter for this WG > is not to create a registry-specific, or regime-specific, or jurisdiction- > specific, or object-specific protocol. > >I'm not bringing this up. You are. Correct. So there no semantic consequence to the registrar being, or not being, "based within the European Union." The registrar may (hypothetically) provision some datum to the .nl registry, with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with out difference, independent of the registrar's location. Is this correct? I was totally mislead by the .nl registry's Dutch page on the subject of registrar requirements. Fine. I can live with being stupid. I don't have a lot of choice in the matter anyway. > How can a registrar signal in-band to a registry that it accepts > the general Data Protection framework, and any specific terms > and conditions? > >It doesn't need to. It should first abide to the contract. That is >not-in band. What contract? Better still, if a registrar doesn't need to signal in-band it accepts anything, then it doesn't need to even know whatever that useless thing is. 8.4 has a MUST in it, which appears to have no meaning at all if I finally understand you. Everything is in the contract -- Scott's opening position, that bilateral out-of-band mechanism (contract) covered the requirement. > More generally, how can any two (or more) participants in the > onward-transport of customer data signal in-band their data > collection practices, and automate the management of onward-transport? > >That's not question this group has to answer. The only question is, >what is the proper element in the protocol which help to implement >a policy as been spelled out in the legal framework. Well, you're a co-chair, so I guess we're finnished with The protocol MUST provide services to identify data collection policies. and are on to "the proper element in the protocol which help to implement a policy" Gosh this is such fun. Not. Eric 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 h23JtMoE017580 for ; Mon, 3 Mar 2003 20:55:22 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JtM4Z017579 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:55:22 +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 h23JtKoE017574 for ; Mon, 3 Mar 2003 20:55:21 +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 h23JrStY080488; Mon, 3 Mar 2003 14:53:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031953.h23JrStY080488@nic-naa.net> To: Andrew Newton 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 "Mon, 03 Mar 2003 14:50:24 EST." <3E63B200.3000505@ecotroph.net> Date: Mon, 03 Mar 2003 14:53:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk try lack of signal. would it have been more polite to suggest a low s/n ratio? 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 h23JdMoE017374 for ; Mon, 3 Mar 2003 20:39:22 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JdLpm017373 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:39:21 +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 h23JdKoE017368 for ; Mon, 3 Mar 2003 20:39:21 +0100 (MET) Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Mon, 03 Mar 2003 14:39:19 -0500 Message-ID: <3E63B200.3000505@ecotroph.net> Date: Mon, 03 Mar 2003 14:50:24 -0500 From: Andrew Newton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 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 References: <200303031749.h23HnKtY079970@nic-naa.net> In-Reply-To: <200303031749.h23HnKtY079970@nic-naa.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric Brunner-Williams in Portland Maine wrote: >>The latter case - "newbie" is rather derogatory term. > > > From <5nkf2vc69aamt50qla76umk9cscpun42ev@4ax.com> > > >>I am a newbie of this group and of the IETF WGs in general (please >>pardon me for anything inappropriate I might unvoluntarily do). >>However, I have been discussing DNS privacy issues extensively in the >>last years, so please allow me to give my point of view on the ongoing >>privacy discussion. > > > Note. I think it was the use of the words "newbie noises"... "noise" sometimes referencing an engineering term for signal ignored or unwanted. -andy 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 h23JONoE017126 for ; Mon, 3 Mar 2003 20:24:23 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JON5e017125 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:24:23 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h23JOKoE017118 for ; Mon, 3 Mar 2003 20:24:21 +0100 (MET) Message-ID: <024601c2e1ba$685542e0$6801a8c0@neteka.inc> From: "Edmon Chung" To: "Eric Brunner-Williams in Portland Maine" Cc: "Rick Wesson" , , "Edward Lewis" , References: <200303031859.h23IxbtY080246@nic-naa.net> Subject: Re: [ietf-provreg] our meeting slot in SF Date: Mon, 3 Mar 2003 14:23:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk :-) I thought you didnt like the idea... ;-D And, I think what we want to discuss in this work group is not the actual "mapping tables", but the framework for doing provisioning. It has more to do with how the management of reserved variants and zone variants can be provisioned. Edmon ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To: "Edmon Chung" Cc: "Rick Wesson" ; ; "Edward Lewis" ; Sent: Monday, March 03, 2003 1:59 PM Subject: Re: [ietf-provreg] our meeting slot in SF > Gosh Edmon, don't forget to mention the utility of adding "$" and other > neato gizmos to the string-space. > > JonnyCa$h.com, JonnyCash.com, really important stuff like that. It isn't > fair that I'm the only Provreg contributor that you've tried to sell shell > metacharacters to. Everyone should have a crack at adding reserved regex > chars to their ASCII-only zone files. > > I'm going to miss the dim sum in SF... > > 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 h23JDIoE016971 for ; Mon, 3 Mar 2003 20:13:18 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23JDIAq016970 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:13:18 +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 h23JDGoE016965 for ; Mon, 3 Mar 2003 20:13:16 +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 h23JDGue035618; Mon, 3 Mar 2003 20:13:16 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303031913.h23JDGue035618@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 13:52:28 -0500. <200303031852.h23IqStY080228@nic-naa.net> Date: Mon, 03 Mar 2003 20:13:16 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk [Category I participation Category I participation is open to businesses and institutions based within the European Union.] Oh that. I thought that it was lifted. But it is still completely irrelevant for the privacy discussion. The "us" (parties having the capacity to register domain names on behalf of clients) for which "the non-disclose attribute will work" appears to be a scoped set of (eventual) EPP participants. The charter for this WG is not to create a registry-specific, or regime-specific, or jurisdiction- specific, or object-specific protocol. I'm not bringing this up. You are. How can a registrar signal in-band to a registry that it accepts the general Data Protection framework, and any specific terms and conditions? It doesn't need to. It should first abide to the contract. That is not-in band. More generally, how can any two (or more) participants in the onward-transport of customer data signal in-band their data collection practices, and automate the management of onward-transport? That's not question this group has to answer. The only question is, what is the proper element in the protocol which help to implement a policy as been spelled out in the legal framework. 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 h23J1coE016808 for ; Mon, 3 Mar 2003 20:01:38 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23J1cTo016807 for ietf-provreg-outgoing; Mon, 3 Mar 2003 20:01:38 +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 h23J1ZoE016802 for ; Mon, 3 Mar 2003 20:01:37 +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 h23IxbtY080246; Mon, 3 Mar 2003 13:59:37 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031859.h23IxbtY080246@nic-naa.net> To: "Edmon Chung" cc: "Rick Wesson" , ietf-provreg@cafax.se, "Edward Lewis" , brunner@nic-naa.net Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: Your message of "Mon, 03 Mar 2003 13:21:11 EST." <023801c2e1b1$ac44b480$6801a8c0@neteka.inc> Date: Mon, 03 Mar 2003 13:59:37 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Gosh Edmon, don't forget to mention the utility of adding "$" and other neato gizmos to the string-space. JonnyCa$h.com, JonnyCash.com, really important stuff like that. It isn't fair that I'm the only Provreg contributor that you've tried to sell shell metacharacters to. Everyone should have a crack at adding reserved regex chars to their ASCII-only zone files. I'm going to miss the dim sum in SF... 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 h23IsKoE016668 for ; Mon, 3 Mar 2003 19:54:20 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IsJXu016667 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:54:19 +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 h23IsIoE016662 for ; Mon, 3 Mar 2003 19:54:18 +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 h23IqStY080228; Mon, 3 Mar 2003 13:52:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031852.h23IqStY080228@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 "Mon, 03 Mar 2003 19:30:08 +0100." <200303031830.h23IU8ue035383@bartok.sidn.nl> Date: Mon, 03 Mar 2003 13:52:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I don't recall the question, at least I don't recognize it. The > basic answer is no. There is no requirement for EU residency for > registars nor registrants. All contracts are under dutch law. To > force this, there should be a dutch adress to which papers can be > presented. But that has nothing to do with privacy apart from the > fact that the dutch privacy law should be followed by .nl. See "Deelnemers categorie I", below. ------- Forwarded Message Return-Path: brunner@nic-naa.net Delivery-Date: Tue Jan 21 19:48:52 2003 Return-Path: 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 h0M0mp7k038586; Tue, 21 Jan 2003 19:48:51 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200301220048.h0M0mp7k038586@nic-naa.net> To: Edward Lewis cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner Subject: Re: [ietf-provreg] where are we with privacy In-Reply-To: Your message of "Tue, 21 Jan 2003 11:36:52 EST." Date: Tue, 21 Jan 2003 19:48:51 -0500 From: Eric Brunner-Williams in Portland Maine > I would also like others to comment on Jaap's message and assessment that: OK, part 2. > At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote: > ... > >So yes, the non-disclose attribute will work for us without any > >problem. It is possible that we might do extensions to aid with the > ... > > > > jaap \begin{quote} Deelnemers ... Deelnemer worden ... Deelnemers categorie I Voor het deelnemerschap categorie I komen in aanmerking bedrijven in instellingen die zijn gevestigd op het grondgebied van de Euorpese Unie. [Category I participation Category I participation is open to businesses and institutions based within the European Union.] ... Het deelnemerschap geeft recht tot: o het verzorgen van de registratie van domeinnamen ten behoeve van klanten; [Category I participants have the following rights: o To apply to register domain names on behalf of clients;] \end{quote} The "us" (parties having the capacity to register domain names on behalf of clients) for which "the non-disclose attribute will work" appears to be a scoped set of (eventual) EPP participants. The charter for this WG is not to create a registry-specific, or regime-specific, or jurisdiction- specific, or object-specific protocol. How can a registrar signal in-band to a registry that it accepts the general Data Protection framework, and any specific terms and conditions? More generally, how can any two (or more) participants in the onward-transport of customer data signal in-band their data collection practices, and automate the management of onward-transport? 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 h23IoqoE016604 for ; Mon, 3 Mar 2003 19:50:52 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IoqRY016603 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:50:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h23IopoE016598 for ; Mon, 3 Mar 2003 19:50:52 +0100 (MET) Received: from rraderxp.pc.internal.tucows.com ([10.0.11.248]) by toronto.mail.tucows.com with esmtp (Exim 3.36 #3) id 18pv1A-0004YR-00; Mon, 03 Mar 2003 13:50:28 -0500 Date: Mon, 03 Mar 2003 13:50:28 -0500 From: "Ross Wm. Rader" To: "Hollenbeck, Scott" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Message-ID: <533274406.1046699428@[10.0.11.248]> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337077B@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337077B@vsvapostal3.prod.netso l.com> X-Mailer: Mulberry/3.0.2 (Win32 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On Monday, March 03, 2003 1:02 PM -0500 "Hollenbeck, Scott" mentioned that: > That being the case, my preference would be to put _all_ of the DNP syntax > and semantics into an extension (where the problem can be addressed as a > whole) while making the existing DCP element mandatory We'd be happy with that as well. regards, -rwr "There's a fine line between fishing and standing on the shore like an idiot." - Steven Wright Get Blog... http://www.byte.org/ 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 h23IUIoE016287 for ; Mon, 3 Mar 2003 19:30:18 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IUIf9016286 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:30:18 +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 h23IUGoE016281 for ; Mon, 3 Mar 2003 19:30:16 +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 h23IU8ue035383; Mon, 3 Mar 2003 19:30:10 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303031830.h23IU8ue035383@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: "Hollenbeck, Scott" , "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry In-reply-to: Your message of Mon, 03 Mar 2003 10:47:52 -0500. <200303031547.h23FlqtY079531@nic-naa.net> Date: Mon, 03 Mar 2003 19:30:08 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk > One from Jaap - a look at how privacy concerns with .nl impact the issue. I sent a public message about the .nl requirement to Jaap not long after his note on the subject, that the EU residency requirement for registrars provided a contractual equivalent to a element, and a simpler form (for a hypothetical deployment of epp, as .nl wasn't yet epp-operational) of whois-token, while sufficient for endpoints within the EU, would not be capable of allowing non-EU endpoints to register .nl domains. He hasn't responded. I don't recall the question, at least I don't recognize it. The basic answer is no. There is no requirement for EU residency for registars nor registrants. All contracts are under dutch law. To force this, there should be a dutch adress to which papers can be presented. But that has nothing to do with privacy apart from the fact that the dutch privacy law should be followed by .nl. 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 h23ILboE016162 for ; Mon, 3 Mar 2003 19:21:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23ILbJd016161 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:21:37 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h23ILXoE016156 for ; Mon, 3 Mar 2003 19:21:36 +0100 (MET) Message-ID: <023801c2e1b1$ac44b480$6801a8c0@neteka.inc> From: "Edmon Chung" To: "Rick Wesson" Cc: , "Edward Lewis" References: Subject: Re: [ietf-provreg] our meeting slot in SF Date: Mon, 3 Mar 2003 13:21:11 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk It is not about punycode. It is about the handling of character equivalence preparations (what I call charprep): i.e. the creation of reserved variants and the management of zone variants. These charprep variants need to be generated upon domain creation and conveyed to the registrant. Examples of charprep include Traditional Chinese-Simplified Chinese Mapping and visually identical characters in the LGC (Latin, Greek, Cyrilic) space. Edmon ----- Original Message ----- From: "Rick Wesson" To: "Edmon Chung" Cc: ; "Edward Lewis" Sent: Monday, March 03, 2003 1:14 PM Subject: Re: [ietf-provreg] our meeting slot in SF > > > Edmon, > > Since the EPP specs use utf8 why do we need to encode the domains in > punnycode? > > -rick > > On Mon, 3 Mar 2003, Edmon Chung wrote: > > > I wonder if there might be interest in discussing the topic of IDN/EPP. I > > know that Scott's extension guideline already discussed briefly about it, > > but it gave no provisions to the handling of character equivlancy > > preparation (Charprep) issues and the related reserved variants and zone > > variants management. > > > > I dont have a draft yet, but am working on it. I gave a presentation on the > > issues and some experiments that we have done on a possible architecture for > > handling the charprep recently (at the APRICOT) and it received very good > > response. I thought it would be a good idea to present it to the group and > > get some feedback as I write my draft on the topic. > > > > Edmon > > > > > > ----- Original Message ----- > > From: "Edward Lewis" > > To: > > Cc: > > Sent: Friday, February 28, 2003 1:35 PM > > Subject: [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. ;) > > > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > 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 h23IEaoE016104 for ; Mon, 3 Mar 2003 19:14:36 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23IEa9H016103 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:14:36 +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 h23IEZoE016098 for ; Mon, 3 Mar 2003 19:14:35 +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 h23IEUmn013227; Mon, 3 Mar 2003 10:14:31 -0800 (PST) Date: Mon, 3 Mar 2003 10:14:37 -0800 (PST) From: Rick Wesson To: Edmon Chung cc: , Edward Lewis Subject: Re: [ietf-provreg] our meeting slot in SF In-Reply-To: <021601c2e1af$e0699f20$6801a8c0@neteka.inc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edmon, Since the EPP specs use utf8 why do we need to encode the domains in punnycode? -rick On Mon, 3 Mar 2003, Edmon Chung wrote: > I wonder if there might be interest in discussing the topic of IDN/EPP. I > know that Scott's extension guideline already discussed briefly about it, > but it gave no provisions to the handling of character equivlancy > preparation (Charprep) issues and the related reserved variants and zone > variants management. > > I dont have a draft yet, but am working on it. I gave a presentation on the > issues and some experiments that we have done on a possible architecture for > handling the charprep recently (at the APRICOT) and it received very good > response. I thought it would be a good idea to present it to the group and > get some feedback as I write my draft on the topic. > > Edmon > > > ----- Original Message ----- > From: "Edward Lewis" > To: > Cc: > Sent: Friday, February 28, 2003 1:35 PM > Subject: [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. ;) > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > 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 h23I9OoE016042 for ; Mon, 3 Mar 2003 19:09:24 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23I9OcF016041 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:09:24 +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 h23I9BoE016034 for ; Mon, 3 Mar 2003 19:09:23 +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 NAA00790; Mon, 3 Mar 2003 13:09:04 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 13:02:34 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337077B@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Mon, 3 Mar 2003 13:02:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically > evaluate to 1, or 0? > > The answer to this is a determining factor (to me at least) of > whether $dnp is in the base specification or in an extension. As far as .com is concerned, I have no doubt that an extension will be required even if we were to adopt the IESG's element tagging suggestion. That being the case, my preference would be to put _all_ of the DNP syntax and semantics into an extension (where the problem can be addressed as a whole) while making the existing DCP element mandatory if that resolves the privacy issue 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 h23I8doE016028 for ; Mon, 3 Mar 2003 19:08:39 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23I8dJS016027 for ietf-provreg-outgoing; Mon, 3 Mar 2003 19:08:39 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h23I8boE016022 for ; Mon, 3 Mar 2003 19:08:37 +0100 (MET) Message-ID: <021601c2e1af$e0699f20$6801a8c0@neteka.inc> From: "Edmon Chung" To: , "Edward Lewis" Cc: References: Subject: Re: [ietf-provreg] our meeting slot in SF Date: Mon, 3 Mar 2003 13:08:20 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk I wonder if there might be interest in discussing the topic of IDN/EPP. I know that Scott's extension guideline already discussed briefly about it, but it gave no provisions to the handling of character equivlancy preparation (Charprep) issues and the related reserved variants and zone variants management. I dont have a draft yet, but am working on it. I gave a presentation on the issues and some experiments that we have done on a possible architecture for handling the charprep recently (at the APRICOT) and it received very good response. I thought it would be a good idea to present it to the group and get some feedback as I write my draft on the topic. Edmon ----- Original Message ----- From: "Edward Lewis" To: Cc: Sent: Friday, February 28, 2003 1:35 PM Subject: [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. ;) > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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 h23HpGoE015892 for ; Mon, 3 Mar 2003 18:51:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23HpGev015891 for ietf-provreg-outgoing; Mon, 3 Mar 2003 18:51:16 +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 h23HpDoE015885 for ; Mon, 3 Mar 2003 18:51:14 +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 h23HnKtY079970; Mon, 3 Mar 2003 12:49:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031749.h23HnKtY079970@nic-naa.net> To: Edward Lewis 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 "Mon, 03 Mar 2003 11:39:56 EST." Date: Mon, 03 Mar 2003 12:49:20 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The latter case - "newbie" is rather derogatory term. >From <5nkf2vc69aamt50qla76umk9cscpun42ev@4ax.com> > I am a newbie of this group and of the IETF WGs in general (please > pardon me for anything inappropriate I might unvoluntarily do). > However, I have been discussing DNS privacy issues extensively in the > last years, so please allow me to give my point of view on the ongoing > privacy discussion. Note. > Not addressing the privacy issue in the base protocol would likely > imply that the service would often be deployed in real life without > any means to achieve privacy protection. Agree. > Unfortunately, the present > lack of privacy protection in the WHOIS system is plainly illegal in > many countries, and I don't think it's reasonable to think that this > situation can go on for long without actual lawsuits starting to > happen, both towards ccTLD and gTLD registries and registrars. Not relevant for a provisioning protocol. Specific to a particular post-provisioned publication protocol, and none of us should be playing lawyer on the net. Its mechanism, mechanism, mechanism, mechanism, mechanism, mechanism and once more for emphesis, mechanism. Now I'll go back to my screw driver and duct tape, cause three years working http-state, onward-transport, and provisioning just haven't left me with clue parity with jrandom Euros. I'll send a write up of where we are to the P3P list, we (I've now got a spiffy "P3P hat" on) have a meeting this Friday. At this point though, it looks as if the W3C is going one way, and the IETF is going another. XML on the one hand, and a binary token on the other. 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 h23GfDoE015080 for ; Mon, 3 Mar 2003 17:41:13 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23GfDlL015079 for ietf-provreg-outgoing; Mon, 3 Mar 2003 17:41:13 +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 h23GfCoE015074 for ; Mon, 3 Mar 2003 17:41:12 +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 h23Gf9qn012075 for ; Mon, 3 Mar 2003 11:41:09 -0500 (EST) Received: from [66.44.57.72] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA12152 for ; Mon, 3 Mar 2003 11:41:08 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303031547.h23FlqtY079531@nic-naa.net> References: <200303031547.h23FlqtY079531@nic-naa.net> Date: Mon, 3 Mar 2003 11:39:56 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: >Note Bene Chair: > 1. IESG (Randy or Allison) asked and answered > 2. IESG (Patrick) asked and answered > 3. .NL asked and not responsive > 4. .PL asked and not responsive > 5. Newbie noises I should respond to earlier parts of the mail, but I'll pick on this first. As far as 1 & 2, the IESG has taken the first step the responsible guardian. I have to admit, however, that the detail I have obtained from them has been insufficient to evaluate any proposed solution as being "the right one." I do not dispute the spirit of the IESG comments, I just wish that the comments were supported by more substance, as could be provided by 3 & 4. I cannot speak as to why 3 & 4 were not responsive. But these categories represent an important voice that I think needs to be heard. I was looking to such a constituency to give more information on what the IESG is hinting we need, but I haven't been able to introduce any discussion in this way. (I should add that I am not so disappointed that 3 and 4 haven't responded, I am more disappointed that there haven't been other organizations of similar ilk saying anything at all. Yes, that's a generalization - and the IETF is supposed to be individual participation, but the list needs to hear folks with knowledge of other environments to help pound out a solution to this issue.) The latter case - "newbie" is rather derogatory term. Whether or not any one person agrees/disagrees with the words uttered, comments of this ilk (when on topic) are good to hear. The IETF isn't about making protocols that implementors agree to - it's about making interoperable useful protocols. >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0? The answer to this is a determining factor (to me at least) of whether $dnp is in the base specification or in an extension. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 h23FnioE014423 for ; Mon, 3 Mar 2003 16:49:44 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23FniWq014422 for ietf-provreg-outgoing; Mon, 3 Mar 2003 16:49: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 h23FngoE014415 for ; Mon, 3 Mar 2003 16:49: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 h23FlqtY079531; Mon, 3 Mar 2003 10:47:52 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031547.h23FlqtY079531@nic-naa.net> To: "Hollenbeck, Scott" cc: "'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 "Mon, 03 Mar 2003 09:01:53 EST." <3CD14E451751BD42BA48AAA50B07BAD60337076C@vsvapostal3.prod.netsol.com> Date: Mon, 03 Mar 2003 10:47:52 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > why do domain/contact/.. not have granular information about privacy? Asked and answered. 1. Because operationally, policing at the session level is sufficient to support persistent policing across multiple distinct objects, or support single-object-session policing. 2. Because syntactically, if epp is to remain extensible, and xml-based, adding attributes to elements is either pervasive, or specific. As this WG lost the technical/social distinction with the expiry of Ross' draft, we don't have a handy hook for being "specific", and "pervasive" makes conditionally "private" even the data the registrants who have standing to "privacy" under EU framework UNCONDITIONALLY SEEK TO PUBLISH. 3. Because semantically, it isn't simply contemporanious publication via 954 that is of issue, particularly in the EU, but also in the OEDC, and potentially even the US. Also required is some mechanism to identify the repurposing of registrant (and registrar) data, as bulk-access is a real practice, with abuses. Also required is some mechanism to identify the availability of collected registrant (and registrar) data for correction. Also required is some mechanism to identify the duration that data is held by the collector. Adding these semantics to complexType elements would be complex, and has no benefit over attaching the same semantics to aggregations of elements that are NEVER DISAGGREGATED, aka "objects". There is little observed or hypothetical inter-object disaggregation of policy that cannot be reasonably, and scalably met, by bounding sessions by policy discontinuity. See #1, above. Ops, syn, sem, all covered. > In a later discussion with Patrik, I was told that the EPP proposal > did not meet the requirement in Section 8.4 of RFC 3375. ("See the > MUST part of [1].") I wrote the requirement. The mechanism is the , and it is provided by the protocol. The requirement does not state: The protocol MUST NOT provide services if data collection policies are not identified. If it had, then we'd have had (or some other mechanism(s)) as MANDITORY-TO-IMPLEMENT, rather than OPTIONAL. There was WG consensus that the is in the core schema (epp-1.0.xsd), optional to implement, and not an optional extension. > There are three other inputs. > One from Jaap - a look at how privacy concerns with .nl impact the issue. I sent a public message about the .nl requirement to Jaap not long after his note on the subject, that the EU residency requirement for registrars provided a contractual equivalent to a element, and a simpler form (for a hypothetical deployment of epp, as .nl wasn't yet epp-operational) of whois-token, while sufficient for endpoints within the EU, would not be capable of allowing non-EU endpoints to register .nl domains. He hasn't responded. > The second is a report and discussion on the .pl work in this area. I send a public message about the decision of this particular implementor not to use the . I seem to have missed the response. > The third is a message describing the EU perspective on why this must > be solved. Oh thank heavens! A live EU national who is a self-described "newbie" and neither an implementor, nor an operator, nor an author, nor apparently a specification reader. Now I can stop thinking. Note Bene Chair: 1. IESG (Randy or Allison) asked and answered 2. IESG (Patrick) asked and answered 3. .NL asked and not responsive 4. .PL asked and not responsive 5. Newbie noises What part of IETF process did I miss in IETF grade school back in the mid-80s? I don't actually mind if folks creatively craft into "privacy" some form of market protection, Europe for the Europeans, Africa for the Africans, Circumpolar Regions for the Very-Well-Dressed. I simply find it amusing that on the one hand we've people in the IAB/IESG kicking Chinese Butt big time for attempting to fix Unicode [1], arguing "minimum astonishment" as if it were an end-to-end principle, and people with the same, or very similar drinking buddies, arguing that the semanitcs of "{0,1} are context dependent. Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0? I'm always astonished that packets even make it anywhere. Eric [1] Yes Virginia, the new IRTF activity specifically BARS the work by the Joint Engineering Team (.tw/.cn/.kr/.jp) registries and the Chinese Domain Name Consortium (.tw/.hk/.ma/.cn) on intermediate mappings in particular, and constructive mechanism in general. I've asked. Twice. Not for IPR reasons 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 h23E26oE013271 for ; Mon, 3 Mar 2003 15:02:06 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23E26FZ013270 for ietf-provreg-outgoing; Mon, 3 Mar 2003 15:02:06 +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 h23E25oE013265 for ; Mon, 3 Mar 2003 15:02:05 +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 JAA14430; Mon, 3 Mar 2003 09:01:58 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 09:02:01 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337076C@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Date: Mon, 3 Mar 2003 09:01:53 -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 suppose this isn't the concise message you were hoping for, but I'd > rather the WG figure this out rather than have me spoon feed it to > you. E.g., the comment that we don't meet the requirement above was > answered by me in a thread with an IESG member that ultimately went > no where. (Maybe someone else needs to try.) I sent a private message about the DCP requirement to Patrik last Thursday or Friday. He hasn't yet responded. -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 h23DNpoE012780 for ; Mon, 3 Mar 2003 14:23:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h23DNpUU012779 for ietf-provreg-outgoing; Mon, 3 Mar 2003 14:23:51 +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 h23DNmoE012774 for ; Mon, 3 Mar 2003 14:23:49 +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 h23DNmqn006290 for ; Mon, 3 Mar 2003 08:23:48 -0500 (EST) Received: from [66.44.57.72] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA11372 for ; Mon, 3 Mar 2003 08:23:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 3 Mar 2003 08:23:43 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:52 -0800 2/28/03, 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. ??? "Prevented" is certainly not the right word. >We have experenced 4 month delay because of this situation and it is >unacceptable. We still are in a state of limbo. Instead of trying to find fault, there should be an offering of suggestions. All of the needed data exist in the archives. >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. The IESG comment given during the fall (message dated "Tue, 15 Oct 2002 11:16:53 +0200"): why do domain/contact/.. not have granular information about privacy? In a later discussion with Patrik, I was told that the EPP proposal did not meet the requirement in Section 8.4 of RFC 3375. ("See the MUST part of [1].") There are three other inputs. One from Jaap - a look at how privacy concerns with .nl impact the issue. The second is a report and discussion on the .pl work in this area. The third is a message describing the EU perspective on why this must be solved. First message: Fri, 10 Jan 2003 13:43:22 +0100 Second message: Sat, 01 Feb 2003 18:51:49 +0100, with a followup Tue, 11 Feb 2003 08:30:20 -0500 by Scott Hollenbeck Third message: Fri, 17 Jan 2003 11:03:26 +0100, Vittorio Bertola As far as a summary, there's a message dated "Sun, 19 Jan 2003 21:00:15 -0500" that I sent out, with an ensuing thread. In the above are proposed solutions, as well as the dcp as it sits in the base specification. The consensus of the WG (or those participating actively on the list) is that privacy is too ill defined to put in the base specification. I get the feeling from the IESG that thinks the set of those reaching this consensus is not representative enough of the Internet in general, but this is just a feeling. (Who out there is not engineering to the environment of the shared registry model? Who is engineering toward an independent registry environment? Are we representative of the Internet as a whole?) I suppose this isn't the concise message you were hoping for, but I'd rather the WG figure this out rather than have me spoon feed it to you. E.g., the comment that we don't meet the requirement above was answered by me in a thread with an IESG member that ultimately went no where. (Maybe someone else needs to try.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 h23CN5oE012214 for ; Mon, 3 Mar 2003 13:23:05 +0100 (MET) Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h23CN5KN012213 for ietf-provreg-outgoing; Mon, 3 Mar 2003 13:23:05 +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 h23CN2oE012208 for ; Mon, 3 Mar 2003 13:23:04 +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 h23CL0tY078881; Mon, 3 Mar 2003 07:21:00 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303031221.h23CL0tY078881@nic-naa.net> To: Edward Lewis cc: 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 13:35:11 EST." Date: Mon, 03 Mar 2003 07:21:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is an issue-reminder, assuming that the IESG is responsive on the privacy/data colleciton issue. mappings over transports other than tcp. The IESG claim is that commands cannot be reordered, which seems to be reasonable for the transformational subset of epp commands, but not the informational subset of epp commands, and this "resonability" appers to be limited to com/net/org/info/biz/name transactions. Email is used, as a transport for XML and BNF, elsewhere. Non-interoperation by intent is an odd proposition, particularly by non-implementors and non-operators. The IESG claim is also that applications protocols must provide congestion control. I'm afraid this new requirement seems reflexive, not the product of actual reflection on the deployment of epp. The publication protocols commonly in use with registry provisioning include UDP, with absurdly large difference in scale. Connectionism by design is an odd proposition too, again by non-implementors and non-operators. It would be reasonable if this work were within the ITU, which is both connectionist and mandarinist. Just out of curiosity, since whois is such a problem, why on earth is the inferred provisioning of social data to the com/net/org et alia whois servers not _historic_? The US DCA is very, very, dead as an Agency of Notice or Fashion. 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 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 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 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 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 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 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