Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0VDrpOh007117 for ; Thu, 31 Jan 2002 14:53:51 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0VDrpvU007116 for ietf-provreg-outgoing; Thu, 31 Jan 2002 14:53:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0VDroOh007111 for ; Thu, 31 Jan 2002 14:53:50 +0100 (MET) Received: from 208-58-216-114.s114.tnt1.annp.md.dialup.rcn.com ([208.58.216.114]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.33 #10) id 16WHep-0000T5-00; Thu, 31 Jan 2002 08:53:44 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jan 2002 08:52:37 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Minneapolis Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk FYI, Since I last sent a message, I've submitted a request for a 2-hour time slot in Minneapolis. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0TE5FOh020177 for ; Tue, 29 Jan 2002 15:05:15 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0TE5Fbt020176 for ietf-provreg-outgoing; Tue, 29 Jan 2002 15:05:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx11.nameplanet.com (mx11.nameplanet.com [62.70.3.41]) by nic.cafax.se (8.12.2/8.12.2) with SMTP id g0TE5EOh020171 for ; Tue, 29 Jan 2002 15:05:14 +0100 (MET) Received: 29 Jan 2002 14:05:13 -0000 Received: from unknown (HELO www2.nameplanet.com) (192.168.2.42) by mx11 with SMTP; 29 Jan 2002 14:05:13 -0000 Received: (qmail 2963 invoked by uid 400); 29 Jan 2002 14:05:13 -0000 Date: 29 Jan 2002 14:05:13 -0000 Message-ID: <20020129140513.2960.qmail@www2.nameplanet.com> From: asbjorn.rrp@theglobalname.org To: ietf-provreg@cafax.se MIME-Version: 1.0 Subject: RE: EPP Document Last Call Issue Summary Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, perhaps stating the obvious here, but I think the way it is being done in 06/04 is very good as it (as Scott mentions) gives the RegistrY the choice on what policy to use. And the RegistrY can also easily change their policy later without having to think about protocol compatibility... Asbjorn On Fri, 25 Jan 2002 12:08:38 -0500 "Hollenbeck, Scott" wrote: >> -----Original Message----- >> From: Rick H Wesson [mailto:wessorh@ar.com] >> I believe that the vast majority of registrars requested the ability >> to view domains. This viewpoint was overwhelmingly expressed >> to VGRS at a >> Registry meeting before the November ICANN meetings. >> >> I feel that this change is not what the vast majority of registry and >> registrars asked for but supports a position of VGRS. > >Comments from other folks on the provreg list supported the change. As-is, >what's in the draft now allows server operators (not just VeriSign) to set >their own policies -- I strongly believe that's the most reasonable >approach. -- The information transmitted in this email is intended only for the person(s) or entity to which it is addressed and may contain proprietary, confidential and/or privileged material. If you have received this email in error, please contact the sender by replying and delete this email so that it is not recoverable. If you are not the intended recipient(s), any retention, review, disclosure, distribution, copying, printing, dissemination, or other use of, or taking of any action in reliance upon, this information is strictly prohibited and without liability on our part. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PKk5Oh001104 for ; Fri, 25 Jan 2002 21:46:05 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PKk5kU001103 for ietf-provreg-outgoing; Fri, 25 Jan 2002 21:46:05 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PKk3Oh001098 for ; Fri, 25 Jan 2002 21:46:04 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA28950 for ; Fri, 25 Jan 2002 15:46:02 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 15:46:02 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5D6@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: EPP Schema and Example Files Date: Fri, 25 Jan 2002 15:46:00 -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 Compressed archives containing the EPP-06 schema and example files can be found here: ftp://ftp.verisign.com/pub/epp/20020124/ and here: http://www.verisign-grs.com/files/ -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PH8qOh029617 for ; Fri, 25 Jan 2002 18:08:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PH8qAR029616 for ietf-provreg-outgoing; Fri, 25 Jan 2002 18:08:52 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PH8pOh029611 for ; Fri, 25 Jan 2002 18:08:51 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA16980; Fri, 25 Jan 2002 12:08:44 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 12:08:43 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5D2@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Rick H Wesson'" Cc: "'ietf-provreg@cafax.se'" , Registrars List Subject: RE: EPP Document Last Call Issue Summary Date: Fri, 25 Jan 2002 12:08:38 -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 > -----Original Message----- > From: Rick H Wesson [mailto:wessorh@ar.com] > Sent: Friday, January 25, 2002 11:50 AM > To: Hollenbeck, Scott > Cc: 'ietf-provreg@cafax.se'; Registrars List > Subject: Re: EPP Document Last Call Issue Summary > > Scott, > > considerable last-minute changes. Everything significant was discussed on the list. > The one below so significantly changes how registries and > registrars have > operated in the past I must disagree with this change until we have a > much wider discussion of how the command is to work. > > I believe that the vast majority of registrars requested the ability > to view domains. This viewpoint was overwhelmingly expressed > to VGRS at a > Registry meeting before the November ICANN meetings. > > I feel that this change is not what the vast majority of registry and > registrars asked for but supports a position of VGRS. Rick, I posted the compromise position implemented in the draft twice (once at your specific request [1], [2]), and you didn't object to it until now. Comments from other folks on the provreg list supported the change. As-is, what's in the draft now allows server operators (not just VeriSign) to set their own policies -- I strongly believe that's the most reasonable approach. Plus, I conferred with the VeriSign folks who attended the meeting you referred to. Per them, the significant ask was to be able to see domain details in the context of ransfers. The updated document allows a client to see full domain details in that context without exception. -Scott- [1] http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00063.html [2] http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00064.html Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PGnsOh029490 for ; Fri, 25 Jan 2002 17:49:54 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PGnsfk029489 for ietf-provreg-outgoing; Fri, 25 Jan 2002 17:49:54 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (66.123.187.68.ar.com [66.123.187.68] (may be forged)) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PGnmOh029484 for ; Fri, 25 Jan 2002 17:49:49 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0PGnd5F023160; Fri, 25 Jan 2002 08:49:39 -0800 (PST) Date: Fri, 25 Jan 2002 08:49:39 -0800 (PST) From: Rick H Wesson To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" , Registrars List Subject: Re: EPP Document Last Call Issue Summary In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B5C9@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, considerable last-minute changes. The one below so significantly changes how registries and registrars have operated in the past I must disagree with this change until we have a much wider discussion of how the command is to work. I believe that the vast majority of registrars requested the ability to view domains. This viewpoint was overwhelmingly expressed to VGRS at a Registry meeting before the November ICANN meetings. I feel that this change is not what the vast majority of registry and registrars asked for but supports a position of VGRS. -rick On Fri, 25 Jan 2002, Hollenbeck, Scott wrote: > http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00022.html > use with command; compromise implemented. Security > considerations updated in the domain and contact mappings. > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PEAUOh028718 for ; Fri, 25 Jan 2002 15:10:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PEAUMp028717 for ietf-provreg-outgoing; Fri, 25 Jan 2002 15:10: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-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PEATOh028712 for ; Fri, 25 Jan 2002 15:10:29 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0PH7pr39635; Fri, 25 Jan 2002 09:07:52 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201251707.g0PH7pr39635@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: EPP Document Last Call Issue Summary In-Reply-To: Message from "Hollenbeck, Scott" of "Fri, 25 Jan 2002 08:47:19 EST." <3CD14E451751BD42BA48AAA50B07BAD60189B5C9@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2002 09:07:51 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, My complements on seeing this through from BoF to core document WG Last Call. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PDiDOh028577 for ; Fri, 25 Jan 2002 14:44:13 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PDiCOE028576 for ietf-provreg-outgoing; Fri, 25 Jan 2002 14:44:12 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PDiBOh028571 for ; Fri, 25 Jan 2002 14:44:11 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA05335 for ; Fri, 25 Jan 2002 08:44:10 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 08:43:33 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5C9@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: EPP Document Last Call Issue Summary Date: Fri, 25 Jan 2002 08:47:19 -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 EPP document set has been updated to address comments received during and after the WG last call period. This is a summary of the comments received and how they were addressed in the new documents. Here's a link to the last call announcement: http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00037.html The description below will note comments that resulted in document changes. Please see the "Revisions" section of each document for pointers to the specific document sections that were changed as a result of implementing the changes. On to the comments in the order they were received... http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00038.html All implemented except for "Adding elements to the domain mapping to support delegation to hosts that do not or should not need to exist as host objects" and "make the element OPTIONAL in the element". Discussion around both of these suggestions led in different directions. Text was added to the domain mapping document to describe external host handling, and there were objections to the element suggestion. http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00041.html Fix to the ROID pattern; implemented. http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00043.html Adding to the query command; implemented. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00002.html Replacement of references to ISO documents where possible; implemented. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00012.html Change to the way internationalized and localized contact postal info is exchanged; implemented. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00014.html Text fix in command description; implemented. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00016.html Data collection policy changes; implemented. Poll response format changes; implemented. Content length header in TCP transport; implemented. Contact transfers related to domain transfers; nothing done as there was no agreement on there even being an issue. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00018.html External host description and processing requirements; implemented. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00030.html Empty text element processing; implemented. http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00041.html "type" attribute in response; not implemented as subsequent discussion described already-present alternatives. http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00022.html use with command; compromise implemented. Security considerations updated in the domain and contact mappings. http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00036.html MX record provisioning; taken off-list for later action. For those who wanted to follow this, it hasn't gone anywhere yet. http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00067.html Notification assertions; implemented. Other cross-document changes made as a result of proofreading: Fixed typos, separated references into normative and informative sections, changes to "must", "may" etc. to avoid confusion with RFC 2119 directives. Core protocol proofreading fixes: Fixed a schema error that limited child elements to a single extension, and fixed another schema error that limited version numbers to single digits. Contact mapping proofreading fixes: Changed type of email and telephone number types to "token" from "normalizedString" since these values should never contain certain acceptable normalizedString characters. Domain mapping proofreading fixes: Fixed and response descriptions to note that the element is (and has been) OPTIONAL per the schema. Minor text change in section 2.3 to avoid use of the term "zone" when describing clientHold and serverHold status. Host mapping proofreading fixes: Added text to section 2.5 to reinforce that IP addresses aren't always required when a host is provisioned for use as a DNS name server. Updated IPv6 address references. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PBrROh028087 for ; Fri, 25 Jan 2002 12:53:27 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PBrRmE028086 for ietf-provreg-outgoing; Fri, 25 Jan 2002 12:53:27 +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.2/8.12.2) with ESMTP id g0PBrPOh028081 for ; Fri, 25 Jan 2002 12:53:26 +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 GAA29508; Fri, 25 Jan 2002 06:53:24 -0500 (EST) Message-Id: <200201251153.GAA29508@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: I-D ACTION:draft-ietf-provreg-epp-tcp-04.txt Date: Fri, 25 Jan 2002 06:53:23 -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 Transport Over TCP Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-tcp-04.txt Pages : 10 Date : 24-Jan-02 This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) Protocol to protect information exchanged between an EPP client and an EPP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.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-tcp-04.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-tcp-04.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: <20020124150704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-tcp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-tcp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020124150704.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PBrMOh028079 for ; Fri, 25 Jan 2002 12:53:22 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PBrMaU028078 for ietf-provreg-outgoing; Fri, 25 Jan 2002 12:53:22 +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.2/8.12.2) with ESMTP id g0PBrKOh028073 for ; Fri, 25 Jan 2002 12:53:20 +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 GAA29492; Fri, 25 Jan 2002 06:53:18 -0500 (EST) Message-Id: <200201251153.GAA29492@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: I-D ACTION:draft-ietf-provreg-epp-host-04.txt Date: Fri, 25 Jan 2002 06:53:18 -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 Host Mapping Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-host-04.txt Pages : 29 Date : 24-Jan-02 This document describes an Extensible Provisioning Protocol (EPP) map- ping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.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-host-04.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-host-04.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: <20020124150650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-host-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-host-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020124150650.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PBrHOh028071 for ; Fri, 25 Jan 2002 12:53:17 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PBrH6Q028070 for ietf-provreg-outgoing; Fri, 25 Jan 2002 12:53:17 +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.2/8.12.2) with ESMTP id g0PBrFOh028065 for ; Fri, 25 Jan 2002 12:53:15 +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 GAA29474; Fri, 25 Jan 2002 06:53:13 -0500 (EST) Message-Id: <200201251153.GAA29474@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: I-D ACTION:draft-ietf-provreg-epp-domain-04.txt Date: Fri, 25 Jan 2002 06:53:13 -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 Domain Name Mapping Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-domain-04.txt Pages : 42 Date : 24-Jan-02 This document describes an Extensible Provisioning Protocol (EPP) map- ping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-04.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-domain-04.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-domain-04.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: <20020124150636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-domain-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-domain-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020124150636.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PBrAOh028063 for ; Fri, 25 Jan 2002 12:53:10 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PBrASL028062 for ietf-provreg-outgoing; Fri, 25 Jan 2002 12:53:10 +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.2/8.12.2) with ESMTP id g0PBr9Oh028057 for ; Fri, 25 Jan 2002 12:53:09 +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 GAA29458; Fri, 25 Jan 2002 06:53:07 -0500 (EST) Message-Id: <200201251153.GAA29458@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: I-D ACTION:draft-ietf-provreg-epp-contact-04.txt Date: Fri, 25 Jan 2002 06:53:07 -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 Contact Mapping Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-contact-04.txt Pages : 39 Date : 24-Jan-02 This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as 'contacts') stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to contacts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-04.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-contact-04.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-contact-04.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: <20020124150624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-contact-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-contact-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020124150624.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0PBr6Oh028055 for ; Fri, 25 Jan 2002 12:53:06 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0PBr67d028054 for ietf-provreg-outgoing; Fri, 25 Jan 2002 12:53:06 +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.2/8.12.2) with ESMTP id g0PBr4Oh028049 for ; Fri, 25 Jan 2002 12:53:05 +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 GAA29441; Fri, 25 Jan 2002 06:53:02 -0500 (EST) Message-Id: <200201251153.GAA29441@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: I-D ACTION:draft-ietf-provreg-epp-06.txt Date: Fri, 25 Jan 2002 06:53:02 -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-06.txt Pages : 76 Date : 24-Jan-02 This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared cen- tral 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-06.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-06.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-06.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: <20020124150612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020124150612.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0OM02Oh024918 for ; Thu, 24 Jan 2002 23:00:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0OM02v6024917 for ietf-provreg-outgoing; Thu, 24 Jan 2002 23:00:02 +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 (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0OM00Oh024904 for ; Thu, 24 Jan 2002 23:00:01 +0100 (MET) Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 16TruZ-0006or-00 for ietf-provreg@cafax.se; Thu, 24 Jan 2002 16:59:59 -0500 Message-ID: <3C5085AC.4030002@tucows.com> Date: Thu, 24 Jan 2002 17:07:40 -0500 From: Daniel Manley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020104 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: Re: They're already calling for 53rd IETF Meetings References: <3CD14E451751BD42BA48AAA50B07BAD60189B5AA@vsvapostal3.bkup6> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Perhaps longer than one hour. In SLC, it seemed like we had to rush through without being able to bring some topics to a reasonable conclusion. I think we also started a little late and the next group didn't give us any spare time. Dan Hollenbeck, Scott wrote: >>-----Original Message----- >>From: Edward Lewis [mailto:lewis@tislabs.com] >>Sent: Tuesday, January 22, 2002 4:56 PM >>To: Eric Brunner-Williams in Portland Maine >>Cc: Edward Lewis; ietf-provreg@cafax.se; brunner@nic-naa.net >>Subject: Re: They're already calling for 53rd IETF Meetings >> >> >>At 7:37 PM -0500 1/17/02, Eric Brunner-Williams in Portland >>Maine wrote: >> >>>In my opinion, a time slot in Minneapolis would be time well spent. >>> >>Does anyone else feel the need for a meeting? I am not >>disputing Eric's >>reasons, but I'd like to hear from a wider set of people. >> >>Are folks holding off a decision until they see new (already promised) >>drafts and/or versions? >> > >I intend to send the updated documents to the I-D administrator some time >tomorrow. Assuming no one finds that I did anything stupid or counter to >what we've covered in the last call, I believe that the documents are ready >to be sent to the IESG. It would be nice if they could be last-called by >the IESG prior to the March meeting, and if that happens we might have some >additional topics for discussion. > >I'd prefer to see a more thorough description of Eric's suggested topics >sent to the mailing list before rendering an opinion on their suitability as >agenda items. We might be able to have a more thoughtful discussion if we >have something to look at ahead of time. > >Anyway, it sounds like it might be wise to reserve a meeting slot just to be >on the safe side. > >-Scott- > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0NGUmOh014743 for ; Wed, 23 Jan 2002 17:30:48 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0NGUmM0014742 for ietf-provreg-outgoing; Wed, 23 Jan 2002 17:30:48 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0NGUkOh014737 for ; Wed, 23 Jan 2002 17:30:47 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA20659 for ; Wed, 23 Jan 2002 11:30:46 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 11:27:29 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5AA@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: They're already calling for 53rd IETF Meetings Date: Wed, 23 Jan 2002 11:34:04 -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 > -----Original Message----- > From: Edward Lewis [mailto:lewis@tislabs.com] > Sent: Tuesday, January 22, 2002 4:56 PM > To: Eric Brunner-Williams in Portland Maine > Cc: Edward Lewis; ietf-provreg@cafax.se; brunner@nic-naa.net > Subject: Re: They're already calling for 53rd IETF Meetings > > > At 7:37 PM -0500 1/17/02, Eric Brunner-Williams in Portland > Maine wrote: > >In my opinion, a time slot in Minneapolis would be time well spent. > > Does anyone else feel the need for a meeting? I am not > disputing Eric's > reasons, but I'd like to hear from a wider set of people. > > Are folks holding off a decision until they see new (already promised) > drafts and/or versions? I intend to send the updated documents to the I-D administrator some time tomorrow. Assuming no one finds that I did anything stupid or counter to what we've covered in the last call, I believe that the documents are ready to be sent to the IESG. It would be nice if they could be last-called by the IESG prior to the March meeting, and if that happens we might have some additional topics for discussion. I'd prefer to see a more thorough description of Eric's suggested topics sent to the mailing list before rendering an opinion on their suitability as agenda items. We might be able to have a more thoughtful discussion if we have something to look at ahead of time. Anyway, it sounds like it might be wise to reserve a meeting slot just to be on the safe side. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0N7jBOh010888 for ; Wed, 23 Jan 2002 08:45:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0N7jAHY010887 for ietf-provreg-outgoing; Wed, 23 Jan 2002 08:45:10 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0N7j9Oh010882 for ; Wed, 23 Jan 2002 08:45:10 +0100 (MET) Received: by sentry.gw.tislabs.com; id CAA05354; Wed, 23 Jan 2002 02:50:20 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma005350; Wed, 23 Jan 02 02:50:06 -0500 X-Sender: lewis@193.0.4.37 Message-Id: In-Reply-To: <200201180037.g0I0b2r10712@nic-naa.net> References: Your message of "Thu, 17 Jan 2002 12:40:14 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jan 2002 16:55:47 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: They're already calling for 53rd IETF Meetings Cc: Edward Lewis , ietf-provreg@cafax.se, brunner@nic-naa.net Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 7:37 PM -0500 1/17/02, Eric Brunner-Williams in Portland Maine wrote: >In my opinion, a time slot in Minneapolis would be time well spent. Does anyone else feel the need for a meeting? I am not disputing Eric's reasons, but I'd like to hear from a wider set of people. Are folks holding off a decision until they see new (already promised) drafts and/or versions? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0JL2UF8018965 for ; Sat, 19 Jan 2002 22:02:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0JL2UKI018964 for ietf-provreg-outgoing; Sat, 19 Jan 2002 22:02:30 +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 (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0JL2SF8018959 for ; Sat, 19 Jan 2002 22:02:29 +0100 (MET) Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 16S2dA-0007GZ-00 for ietf-provreg@cafax.se; Sat, 19 Jan 2002 16:02:28 -0500 Message-ID: <3C49E098.8080701@tucows.com> Date: Sat, 19 Jan 2002 16:09:44 -0500 From: Daniel Manley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: Re: and object changes (was authInfo in commands) References: <3CD14E451751BD42BA48AAA50B07BAD60189B58F@vsvapostal3.bkup6> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk yes, well it seems that I've become a broken record... http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00041.html sorry for the repeating. Dan Hollenbeck, Scott wrote: >Dan, > >Text describing the notification needs you mentioned below is going into the >next version of the documents. > >-Scott- > >>-----Original Message----- >>From: Daniel Manley [mailto:dmanley@tucows.com] >>Sent: Friday, January 18, 2002 10:53 PM >>To: Ed Rahn >>Cc: asbjorn.rrp@theglobalname.org; ietf-provreg@cafax.se >>Subject: and object changes (was authInfo in commands) >> >> >>It's my philosophy (and perhaps this should go into the >>drafts) that an >>EPP registry should/must create a notification to sponsoring >>client of >>an object when that object is modified without that client's direct >>involvement. So a domain registrar, for example, would be >>notified of >>changes in the status of a transfer initiated by the other >>registrar or >>by the registry's auto-approve/deny mechanisms. Actually, the >>requesting registrar should also be notified if the transfer >>is denied >>by the losing registrar or auto-denied/approved by the registry. >> >>Other situations where a registry would notify a registrar of >>changes to >>objects it owns: auto-renewals, object (domain) expiry, changes >>initiated by the registry's support staff, etc... >> >>this way, the owning registrar (with regular polling, or with >>pushing) >>can count on always being in the know of changes to its >>objects in the >>registry. >> >>Dan >> Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0JE8sF8017899 for ; Sat, 19 Jan 2002 15:08:54 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0JE8sNh017898 for ietf-provreg-outgoing; Sat, 19 Jan 2002 15:08:54 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0JE8qF8017893 for ; Sat, 19 Jan 2002 15:08:53 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA24458; Sat, 19 Jan 2002 09:08:50 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Sat, 19 Jan 2002 09:05:40 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B58F@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Daniel Manley'" Cc: ietf-provreg@cafax.se Subject: RE: and object changes (was authInfo in commands) Date: Sat, 19 Jan 2002 09:12:16 -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 Dan, Text describing the notification needs you mentioned below is going into the next version of the documents. -Scott- > -----Original Message----- > From: Daniel Manley [mailto:dmanley@tucows.com] > Sent: Friday, January 18, 2002 10:53 PM > To: Ed Rahn > Cc: asbjorn.rrp@theglobalname.org; ietf-provreg@cafax.se > Subject: and object changes (was authInfo in commands) > > > It's my philosophy (and perhaps this should go into the > drafts) that an > EPP registry should/must create a notification to sponsoring > client of > an object when that object is modified without that client's direct > involvement. So a domain registrar, for example, would be > notified of > changes in the status of a transfer initiated by the other > registrar or > by the registry's auto-approve/deny mechanisms. Actually, the > requesting registrar should also be notified if the transfer > is denied > by the losing registrar or auto-denied/approved by the registry. > > Other situations where a registry would notify a registrar of > changes to > objects it owns: auto-renewals, object (domain) expiry, changes > initiated by the registry's support staff, etc... > > this way, the owning registrar (with regular polling, or with > pushing) > can count on always being in the know of changes to its > objects in the > registry. > > Dan Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0J4HZF8016853 for ; Sat, 19 Jan 2002 05:17:35 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0J4HZB6016852 for ietf-provreg-outgoing; Sat, 19 Jan 2002 05:17:35 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0J4HXF8016846; Sat, 19 Jan 2002 05:17:34 +0100 (MET) Received: from 208.184.79.252.songbird.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with SMTP id UAA09446; Fri, 18 Jan 2002 20:17:25 -0800 X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol Message-Id: <5.1.0.14.2.20020118201035.0302d648@127.0.0.1> X-Sender: dcrocker@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jan 2002 20:11:00 -0800 To: Eric Brunner-Williams in Portland Maine From: Dave Crocker Subject: Re: Filtering for content Cc: liman@autonomica.se, ietf-provreg@cafax.se In-Reply-To: <200201190257.g0J2vjr14452@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 06:57 PM 1/18/2002 -0800, Eric Brunner-Williams in Portland Maine wrote: >We need to have Jim Fleming filtered (out) of the provreg list. TiA. oh? has he been posting to this list? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0J4FKF8016841 for ; Sat, 19 Jan 2002 05:15:20 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0J4FKlj016840 for ietf-provreg-outgoing; Sat, 19 Jan 2002 05:15:20 +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 (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0J4FJF8016835 for ; Sat, 19 Jan 2002 05:15:19 +0100 (MET) Received: from cpe0050ba56ff24.cpe.net.cable.rogers.com ([24.157.140.141] helo=tucows.com) by toronto.mail.tucows.com with asmtp (TLSv1:RC4-MD5:128) (Exim 3.20 #2) id 16RmuU-0000uu-00; Fri, 18 Jan 2002 23:15:18 -0500 Message-ID: <3C48F286.1080304@tucows.com> Date: Fri, 18 Jan 2002 23:13:58 -0500 From: Daniel Manley User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Brunner-Williams in Portland Maine CC: Edward Lewis , ietf-provreg@cafax.se Subject: Re: They're already calling for 53rd IETF Meetings References: <200201180037.g0I0b2r10712@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, I'm trying to find the reference you made to message on the 29th [of November?]. I've read messages from both you and Ed and don't see a mention of a single client. Maybe I'm just missing it. Can you send links to the specific message in archives or quote snippets? Thanks, Dan Eric Brunner-Williams in Portland Maine wrote: >Ed, > >In my opinion, a time slot in Minneapolis would be time well spent. > >I sent some suggestions to the chairs prior to SLC, one is in-progress as >we speak -- the data protection (aka "privacy") bits, between Scott and I. > >Other dohickies I suggested were: > > 1. "moving out of the ICANN gTLD ghetto > + adding the "sponsoring entity" authorization mechanism > + archival logging in-band (see ) > 2. technical bells-and-whistles > + symmetric event model (see ) > + bulk (ftp) model > + restart and recovery work > 3. some unspecified security "stuff" > >Scott's suggestion that we put an Open Source server out is a good idea, >and there has been real off-list and on-list interest in that. This is a >good subject for at least 15 minutes. > >Another subject that is "ripe" now is the question of one client. Please >see Ed's note of the 29th, and my reply, also of the 29th. This is a good >subject for at least another 15 minutes. > >I'm implementing, and I'll be happy to attempt interoperability testing >with nearly anyone prior to or during the week of -53. > >So, IMO, at least an hour, two would be fine if implementors reports are >tossed in. > >Eric >wampumpeag, llc > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0J3sNF8016807 for ; Sat, 19 Jan 2002 04:54:23 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0J3sN7g016806 for ietf-provreg-outgoing; Sat, 19 Jan 2002 04:54:23 +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 (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0J3sMF8016801 for ; Sat, 19 Jan 2002 04:54:22 +0100 (MET) Received: from cpe0050ba56ff24.cpe.net.cable.rogers.com ([24.157.140.141] helo=tucows.com) by toronto.mail.tucows.com with asmtp (TLSv1:RC4-MD5:128) (Exim 3.20 #2) id 16RmaD-0007xy-00; Fri, 18 Jan 2002 22:54:21 -0500 Message-ID: <3C48EDA7.8070709@tucows.com> Date: Fri, 18 Jan 2002 22:53:11 -0500 From: Daniel Manley User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Ed Rahn CC: asbjorn.rrp@theglobalname.org, ietf-provreg@cafax.se Subject: and object changes (was authInfo in commands) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk It's my philosophy (and perhaps this should go into the drafts) that an EPP registry should/must create a notification to sponsoring client of an object when that object is modified without that client's direct involvement. So a domain registrar, for example, would be notified of changes in the status of a transfer initiated by the other registrar or by the registry's auto-approve/deny mechanisms. Actually, the requesting registrar should also be notified if the transfer is denied by the losing registrar or auto-denied/approved by the registry. Other situations where a registry would notify a registrar of changes to objects it owns: auto-renewals, object (domain) expiry, changes initiated by the registry's support staff, etc... this way, the owning registrar (with regular polling, or with pushing) can count on always being in the know of changes to its objects in the registry. Dan Ed Rahn wrote: > >If domain owners are able to make updates to domains through other >registrars, would this information be given to the previous >registrar, possible using poll.. Due to speed issues we keep most of our >data local and do reconciliation when needed. This would cause out of sync >information and make things a bit more complicated than needed. > >Ed Rahn >ItsYourDomain.com > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0INwwF8015303 for ; Sat, 19 Jan 2002 00:58:58 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0INwvdv015302 for ietf-provreg-outgoing; Sat, 19 Jan 2002 00:58:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0INwuF8015296; Sat, 19 Jan 2002 00:58:56 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0J2vjr14452; Fri, 18 Jan 2002 18:57:46 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201190257.g0J2vjr14452@nic-naa.net> To: liman@autonomica.se cc: ietf-provreg@cafax.se Subject: Filtering for content Date: Fri, 18 Jan 2002 18:57:45 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Liman, We need to have Jim Fleming filtered (out) of the provreg list. TiA. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0IMX8F8015002 for ; Fri, 18 Jan 2002 23:33:08 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0IMX8Ew015001 for ietf-provreg-outgoing; Fri, 18 Jan 2002 23:33:08 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0IMX6F8014996 for ; Fri, 18 Jan 2002 23:33:07 +0100 (MET) Received: from repligate (as1-50.chi.il.dial.anet.com [198.92.156.50]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0IMWwW9004661; Fri, 18 Jan 2002 16:33:04 -0600 (CST) Message-ID: <088601c1a070$1c267bf0$0100a8c0@repligate> From: "Jim Fleming" To: Cc: Subject: http://www.dnso.org/clubpublic/ga-full/Arc09/msg00731.html Date: Fri, 18 Jan 2002 14:32:59 -0800 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 http://www.dnso.org/clubpublic/ga-full/Arc09/msg00731.html a.. Subject: [ga] RE: [GTLD Registries List] FW: .BIZ Transfer Policy a.. From: "Neuman, Jeff" "We believe the mess in .com, .net and .org has taken way too long to resolve and often the consumer is being left out of the debate." ... "Before this can happen, however, registrars and registrants must be educated on how to generate a token, how to maintain the security of a token, and how to recover a lost token, through the EPP Protocol used by the "thick registries." This takes time." ----- What is the "mess in .COM" ?? .COM is one of the "Best of Breed" TLDs that has made it past the Proof-of-Concept phase. .BIZ and .US seem to be taking a long time and are viewed by many to be a "mess". 2002 0:201 .COM 2002 1:158 .CLUB 2002 2:143 .FAMILY 2002 3:219 .INFO 2002 4:58 .LLC 2002 5:194 .INC 2002 6:171 .TV 2002 7:195 .CHURCH How will EPP and all of this education about "tokens" help .COM ? Will that be used for the new 2002 .COM servers ?...to support mapping people's existing .COM nameservers into larger address spaces. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0ICBEF8011876 for ; Fri, 18 Jan 2002 13:11:14 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0ICBEUV011875 for ietf-provreg-outgoing; Fri, 18 Jan 2002 13:11:14 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0ICBDF8011870 for ; Fri, 18 Jan 2002 13:11:13 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA18401; Fri, 18 Jan 2002 07:11:06 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 07:10:48 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B587@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Rick H Wesson'" Cc: ietf-provreg@cafax.se Subject: RE: Command and authInfo Date: Fri, 18 Jan 2002 07:14:35 -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 > -----Original Message----- > From: Rick H Wesson [mailto:wessorh@ar.com] > Sent: Thursday, January 17, 2002 8:26 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: RE: Command and authInfo > > > > Scott, > > yes, I read those -- I was asking for the text in the draft, > to compare. > > From what I understand the command currently returns a > subset of > the object depending or not if you are the sponsoring registrar. > > Is this not waht passed last call? No, that's NOT what passed last call. The only field that is currently explicitly identified as one that shouldn't be shown to anyone other than the sponsoring client is the field. Otherwise, the schema defines the mandatory and optional fields, and those that are optional are that way only because they may or may not exist. The suggested compromise was to explicitly make more fields optional so that they can be displayed (or not) based on a server's unauthorized client policy. That is: - if you're the sponsoring client, you get it all. - if you're not the sponsoring client, but you have the auth info, you get it all. - if you're not the sponsoring client and you don't have the auth info, you get a subset defined by server policy. This is derived from comments provided by Bruce and Jens-Uwe, so if I got it wrong I hope one or both of them will correct me. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0I1PZF8009104 for ; Fri, 18 Jan 2002 02:25:35 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0I1PZFS009103 for ietf-provreg-outgoing; Fri, 18 Jan 2002 02:25:35 +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.2/8.12.2) with ESMTP id g0I1PXF8009098 for ; Fri, 18 Jan 2002 02:25:34 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0I1PWYZ029569; Thu, 17 Jan 2002 17:25:33 -0800 (PST) Date: Thu, 17 Jan 2002 17:25:32 -0800 (PST) From: Rick H Wesson To: "Hollenbeck, Scott" cc: Subject: RE: Command and authInfo In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B586@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, yes, I read those -- I was asking for the text in the draft, to compare. >From what I understand the command currently returns a subset of the object depending or not if you are the sponsoring registrar. Is this not waht passed last call? -rick On Thu, 17 Jan 2002, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Rick H Wesson [mailto:wessorh@ar.com] > > Sent: Thursday, January 17, 2002 8:00 PM > > To: Hollenbeck, Scott > > Cc: 'Patrick'; ietf-provreg@cafax.se > > Subject: RE: Command and authInfo > > > > [snip] > > > Would you mind restating the compromise position -- I didn't > > notice that > > we had one. I've seen some objections to the current draft in > > this are but > > I don't understand what our compromise is; nor have I agreeded that we > > have one. > > Look here: > http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00031.html > > http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00033.html > > -Scott- > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0I152F8009001 for ; Fri, 18 Jan 2002 02:05:02 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0I152CV009000 for ietf-provreg-outgoing; Fri, 18 Jan 2002 02:05:02 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0I151F8008995 for ; Fri, 18 Jan 2002 02:05:01 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA09091; Thu, 17 Jan 2002 20:04:54 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 20:01:46 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B586@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Rick H Wesson'" Cc: ietf-provreg@cafax.se Subject: RE: Command and authInfo Date: Thu, 17 Jan 2002 20:08:23 -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 > -----Original Message----- > From: Rick H Wesson [mailto:wessorh@ar.com] > Sent: Thursday, January 17, 2002 8:00 PM > To: Hollenbeck, Scott > Cc: 'Patrick'; ietf-provreg@cafax.se > Subject: RE: Command and authInfo > [snip] > Would you mind restating the compromise position -- I didn't > notice that > we had one. I've seen some objections to the current draft in > this are but > I don't understand what our compromise is; nor have I agreeded that we > have one. Look here: http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00031.html http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00033.html -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0I0xrF8008981 for ; Fri, 18 Jan 2002 01:59:53 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0I0xrIb008980 for ietf-provreg-outgoing; Fri, 18 Jan 2002 01:59:53 +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.2/8.12.2) with ESMTP id g0I0xpF8008974 for ; Fri, 18 Jan 2002 01:59:52 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0I0xoYZ026801; Thu, 17 Jan 2002 16:59:50 -0800 (PST) Date: Thu, 17 Jan 2002 16:59:50 -0800 (PST) From: Rick H Wesson To: "Hollenbeck, Scott" cc: "'Patrick'" , Subject: RE: Command and authInfo In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B583@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, On Thu, 17 Jan 2002, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Patrick [mailto:patrick@gandi.net] > > Sent: Thursday, January 17, 2002 5:30 PM > > To: ietf-provreg@cafax.se > > Subject: Re: Command and authInfo > > > > > > But again, we shifted, my main point was having auth info used not > > only for transfer but for other tasks. Or at least having the > > _protocol_ not forbidding things, that a policy may wish to better > > control. > > OK, here's my angst: we _had_ this in the protocol once before, and no one > objected to changing things to where they are now. If there's a strong > desire to revisit that decision, I'd really like to see a lot more support > for putting it back in before I spend the time putting text back in what I > had to rip out last year. We removed it once and there was vast agreement that it be removed, I have not seen significant comments from impementors that it should be put back. > So, I'd like to ask a basic question assuming that the compromise position > on the command has already been accepted: Would you mind restating the compromise position -- I didn't notice that we had one. I've seen some objections to the current draft in this are but I don't understand what our compromise is; nor have I agreeded that we have one. > Should we put auth info back into the base protocol for possible use with > any transform command or not? no. There has not been a ground-swell for this simpley a single request, which does not make consensus. -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0I0U0F8008900 for ; Fri, 18 Jan 2002 01:30:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0I0U0Mt008899 for ietf-provreg-outgoing; Fri, 18 Jan 2002 01:30:00 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0I0TwF8008894 for ; Fri, 18 Jan 2002 01:29:59 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA08407; Thu, 17 Jan 2002 19:29:57 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 19:29:40 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B583@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Patrick'" , ietf-provreg@cafax.se Subject: RE: Command and authInfo Date: Thu, 17 Jan 2002 19:33:26 -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 > -----Original Message----- > From: Patrick [mailto:patrick@gandi.net] > Sent: Thursday, January 17, 2002 5:30 PM > To: ietf-provreg@cafax.se > Subject: Re: Command and authInfo > > > But again, we shifted, my main point was having auth info used not > only for transfer but for other tasks. Or at least having the > _protocol_ not forbidding things, that a policy may wish to better > control. OK, here's my angst: we _had_ this in the protocol once before, and no one objected to changing things to where they are now. If there's a strong desire to revisit that decision, I'd really like to see a lot more support for putting it back in before I spend the time putting text back in what I had to rip out last year. So, I'd like to ask a basic question assuming that the compromise position on the command has already been accepted: Should we put auth info back into the base protocol for possible use with any transform command or not? -Scott- [1] http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00138.html Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HN0RF8008498 for ; Fri, 18 Jan 2002 00:00:27 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HN0QjZ008497 for ietf-provreg-outgoing; Fri, 18 Jan 2002 00:00:26 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HN0PF8008492 for ; Fri, 18 Jan 2002 00:00:26 +0100 (MET) Received: by sentry.gw.tislabs.com; id SAA25885; Thu, 17 Jan 2002 18:05:41 -0500 (EST) Received: from dhcp34.gw.tislabs.com(192.94.214.134) by sentry.gw.tislabs.com via smap (V5.5) id xma025875; Thu, 17 Jan 02 18:05:14 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <053001c19f9e$8c29e6d0$0100a8c0@repligate> References: <200201172112.g0HLCar10161@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jan 2002 17:58:07 -0500 To: From: Edward Lewis Subject: The mission of this mail list Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a reminder that this mail list has been established for the discussion of work undertaken by the Provisioning Registry Protocol (provreg) working group of the IETF. The charter of the group is found at the following URL: http://www.ietf.org/html.charters/provreg-charter.html We are engineering a particular provisioning protocol, discussing how it is designed on this mail list. Discussions regarding the legitimacy of any participant in the use of the protocol, whether registrar, registry or otherwise, is not within scope of this mail list. Discussions regarding the structure of the DNS data holdings and discussions regarding the benefits of particular network-layer and transport-layer protocols are also out of scope. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMvCF8008467 for ; Thu, 17 Jan 2002 23:57:12 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HMvCAO008466 for ietf-provreg-outgoing; Thu, 17 Jan 2002 23:57:12 +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 (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMvAF8008461 for ; Thu, 17 Jan 2002 23:57:11 +0100 (MET) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 16RLSz-0000RC-00; Thu, 17 Jan 2002 17:57:05 -0500 Message-ID: <010401c19faa$48870730$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: , References: <20020117175307.29926.qmail@www3.nameplanet.com> Subject: Re: Command and authInfo Date: Thu, 17 Jan 2002 17:57:05 -0500 Organization: Tucows Inc. 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 can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar. > As a registrar, I would have to agree with this, but on the other hand, CIRA, for instance, would probably disagree. They've deployed a hybrid model in which both the registry and the registrar maintain transactional contact with the customer. While I mostly hate it, it strikes me that the /good/bad/something of this nature/ concerning the model probably shouldn't enter into a protocol discussion. On the other hand, supporting a structure of this type might lead the wg down the path of including the kitchen sink as well - clearly not the way to go. I submit that the wg should err on the side of model inclusiveness and let the implementors make as many safe decisions as possible about their respective businesses. Anyways, this policy guy has said too much this year, I'll re-lurk now...'-) -rwr Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMU4F8008334 for ; Thu, 17 Jan 2002 23:30:04 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HMU4vk008333 for ietf-provreg-outgoing; Thu, 17 Jan 2002 23:30:04 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMU3F8008328 for ; Thu, 17 Jan 2002 23:30:03 +0100 (MET) Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g0HMU2Jb012723 for ; Thu, 17 Jan 2002 23:30:02 +0100 Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g0HMU2Ix012720 for ietf-provreg@cafax.se; Thu, 17 Jan 2002 23:30:02 +0100 Date: Thu, 17 Jan 2002 23:30:02 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: Re: Command and authInfo Message-ID: <20020117223002.GY24268@nohope.patoche.org> References: <3CD14E451751BD42BA48AAA50B07BAD60189B581@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B581@vsvapostal3.bkup6> User-Agent: Mutt/1.3.24i X-PGP-KeyID: A241FB6B X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Jan 17, 2002 at 05:15:13PM -0500, Hollenbeck, Scott took time to write: > > Or the command was badely designed. > > (it seems to me that if a Registry using EPP right now says that the > > current state is not ok to do transfers... then it is not a social > > problem of someone not willing to do something...) > > I've already read the NeuLevel document, too, and I have to agree with Ross' > assessment. What was written wasn't an indictment of the protocol at all, > but a description of a need for social education for a feature that hasn't > been available before -- and that's probably a much more difficult task than > this WG's task. Only time will tell if transfers in EPP based/using auth info Registries are faster/easier/better/whatever than in RRP based/not using auth info Registries. I think it will not, but this was not my main point. I do not disagree that *now* education is the problem, just because EPP is not known, and not used so much. I still think however, than when this step will be achieved people will realize that to do transfers they will need to do things extra that they do not need to do now. (asking the current Registrar to have access to the auth info to give it to the new Registrar, which probably will not be able to rely only on that, and will need to ask contacts or owner for approval, just like now). There are even cases of valid transfers that can be done now, that will not be possible with this new scheme. Think of a domain name ``hijacked'' by whatever company being all contacts. If the *owner* wish to do the transfer, right now a fax is a valid method of approval, and the transfer can succed, whatever old contacts will do. Now if auth info is required to do the transfer, and if this information is only sent to contacts of the domain name, ... The _idea_ of having the *owner* have control over things like that is great. The idea that using an auth info resolves that is just not correct in my eyes. But again, we shifted, my main point was having auth info used not only for transfer but for other tasks. Or at least having the _protocol_ not forbidding things, that a policy may wish to better control. I just wanted to push Bruce last email, that's all ;-) Building a protocol too restricted to current behaviors/gTLD registries will lessen its use by others. I guess it just depends if we want to replace RRP, or if we want to replace *all* aims used right now by all Registries. Patrick. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMTfF8008321 for ; Thu, 17 Jan 2002 23:29:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HMTfeB008320 for ietf-provreg-outgoing; Thu, 17 Jan 2002 23:29:41 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx.insan.co.id (mx.insan.co.id [202.138.230.11]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMTbF8008315 for ; Thu, 17 Jan 2002 23:29:38 +0100 (MET) Received: from pentium3 (bojong.indocisc.com [202.138.228.8]) by mx.insan.co.id (Postfix) with ESMTP id 3E43B1489D for ; Fri, 18 Jan 2002 05:29:07 +0700 (JAVT) From: budi@alliance.globalnetlink.com To: ietf-provreg@cafax.se Date: Fri, 18 Jan 2002 05:39:30 +0700 MIME-Version: 1.0 Subject: RE: MX records in epp Message-ID: <3C47B512.3470.31D74B@localhost> In-reply-to: <3CD14E451751BD42BA48AAA50B07BAD60189B573@vsvapostal3.bkup6> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 17 Jan 2002 at 7:16, Hollenbeck, Scott wrote: > > In the ".com.au" zone file we have MX records for some > > domains instead of NS > > records. > > > > e.g domainname.com.au IN MX 10 mailserver.com.au > > > > How do you think this should be accommodated within EPP.? ... > As Dave Crocker noted, the general provisioning case for MX records is > within leaf-node zones. If there are exceptions, like in .com.au, I'd > suggest defining a protocol extension to the domain mapping to describe MX > record provisioning. Let's take it off-list if you'd like to explore that > option. ... Put me in that list. We (.ID) domain has exactly the same thing as .AU. Historically, we grew up in the .AU environment. Our primary NS was actually physically located in Australia and managed by friends there before we moved it to Jakarta. ;-) To be frankly, I didn't understand why we have that option. But, some people *do* use/utilize it. (They don't need fancy web sites, just plain email.) Regards -- budi Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMBlF8008246 for ; Thu, 17 Jan 2002 23:11:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HMBksf008245 for ietf-provreg-outgoing; Thu, 17 Jan 2002 23:11:46 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HMBjF8008240 for ; Thu, 17 Jan 2002 23:11:46 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA01370; Thu, 17 Jan 2002 17:11:43 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 17:11:27 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B581@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Patrick'" , ietf-provreg@cafax.se Subject: RE: Command and authInfo Date: Thu, 17 Jan 2002 17:15: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 > -----Original Message----- > From: Patrick [mailto:patrick@gandi.net] > Sent: Thursday, January 17, 2002 3:50 PM > To: ietf-provreg@cafax.se > Subject: Re: Command and authInfo > > > Or the command was badely designed. > (it seems to me that if a Registry using EPP right now says that the > current state is not ok to do transfers... then it is not a social > problem of someone not willing to do something...) I've already read the NeuLevel document, too, and I have to agree with Ross' assessment. What was written wasn't an indictment of the protocol at all, but a description of a need for social education for a feature that hasn't been available before -- and that's probably a much more difficult task than this WG's task. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HM6MF8008214 for ; Thu, 17 Jan 2002 23:06:22 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HM6MH2008213 for ietf-provreg-outgoing; Thu, 17 Jan 2002 23:06:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from butterfree.innerwise.com (email.itsyourdomain.com [63.122.61.25]) by nic.cafax.se (8.12.2/8.12.2) with SMTP id g0HM6LF8008208 for ; Thu, 17 Jan 2002 23:06:21 +0100 (MET) Received: (qmail 2665 invoked by uid 0); 17 Jan 2002 23:07:38 -0000 Received: from ed@ItsYourDomain.Com by Butterfree with qmail-scanner-0.96 (uvscan: v4.1.40/v4172. . Clean. Processed in 0.337213 secs); 17 Jan 2002 23:07:38 -0000 X-Qmail-Scanner-Mail-From: ed@ItsYourDomain.Com via Butterfree X-Qmail-Scanner-Rcpt-To: asbjorn.rrp@theglobalname.org,ietf-provreg@cafax.se X-Qmail-Scanner: 0.96 (No viruses found. Processed in 0.337213 secs) Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Jan 2002 23:07:38 -0000 Date: Thu, 17 Jan 2002 17:07:38 -0600 (CST) From: Ed Rahn To: asbjorn.rrp@theglobalname.org cc: ietf-provreg@cafax.se Subject: Re: Command and authInfo In-Reply-To: <20020117175307.29926.qmail@www3.nameplanet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 17 Jan 2002 asbjorn.rrp@theglobalname.org wrote: > On Thu, 17 Jan 2002 16:43:20 +0100 Patrick wrote: > >IMNSHO auth info should enable someone having it to make > >modifications (that is update at least, maybe delete and renew) > >through any other ways (other Registrars, or even the Registry > >directly). Protocols should make that possible, and then > >local policies should specify if it is to be used or not, and if yes, > >how. > > I can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar. > > Scenario: Registrar A is extremely cheap so I register my domain there, but registrar B has a great user interface for maintaining and modifying objects, so I use their interface instead of registrar a's. Registrar A will get my money, whereas registrar B has to do all the work for a "non-customer". > > But what I might agree upon is that if you want to transfer a domain and have the authInfo, why should the losing registrar need to approve it? :-d > > > Asbjorn > Global Name Registry, Limited > > -- If domain owners are able to make updates to domains through other registrars, would this information be given to the previous registrar, possible using poll.. Due to speed issues we keep most of our data local and do reconciliation when needed. This would cause out of sync information and make things a bit more complicated than needed. Ed Rahn ItsYourDomain.com Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HLcWF8008061 for ; Thu, 17 Jan 2002 22:38:32 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HLcWkN008060 for ietf-provreg-outgoing; Thu, 17 Jan 2002 22:38: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-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HLbxF8008049 for ; Thu, 17 Jan 2002 22:38:00 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0I0b2r10712; Thu, 17 Jan 2002 16:37:02 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201180037.g0I0b2r10712@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: They're already calling for 53rd IETF Meetings In-Reply-To: Your message of "Thu, 17 Jan 2002 12:40:14 EST." Date: Thu, 17 Jan 2002 16:37:02 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, In my opinion, a time slot in Minneapolis would be time well spent. I sent some suggestions to the chairs prior to SLC, one is in-progress as we speak -- the data protection (aka "privacy") bits, between Scott and I. Other dohickies I suggested were: 1. "moving out of the ICANN gTLD ghetto + adding the "sponsoring entity" authorization mechanism + archival logging in-band (see ) 2. technical bells-and-whistles + symmetric event model (see ) + bulk (ftp) model + restart and recovery work 3. some unspecified security "stuff" Scott's suggestion that we put an Open Source server out is a good idea, and there has been real off-list and on-list interest in that. This is a good subject for at least 15 minutes. Another subject that is "ripe" now is the question of one client. Please see Ed's note of the 29th, and my reply, also of the 29th. This is a good subject for at least another 15 minutes. I'm implementing, and I'll be happy to attempt interoperability testing with nearly anyone prior to or during the week of -53. So, IMO, at least an hour, two would be fine if implementors reports are tossed in. Eric wampumpeag, llc Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HLVoF8008019 for ; Thu, 17 Jan 2002 22:31:50 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HLVoIq008018 for ietf-provreg-outgoing; Thu, 17 Jan 2002 22:31:50 +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 (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HLVnF8008013 for ; Thu, 17 Jan 2002 22:31:49 +0100 (MET) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 16RK8S-000396-00; Thu, 17 Jan 2002 16:31:48 -0500 Message-ID: <007301c19f9e$5e8554d0$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: "Patrick" , References: <20020117154320.GJ24268@nohope.patoche.org> <20020117200415.GR24268@nohope.patoche.org> <025001c19f97$05fe6240$040a000a@RRADER2K> <20020117205024.GU24268@nohope.patoche.org> Subject: Re: Command and authInfo Date: Thu, 17 Jan 2002 16:31:47 -0500 Organization: Tucows Inc. 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 > > Or the command was badely designed. > (it seems to me that if a Registry using EPP right now says that the > current state is not ok to do transfers... then it is not a social > problem of someone not willing to do something...) Sounds pretty social to me... "We also understand that many registrars are just now becoming familiar with the capabilities and functionality of the "auth-info" tokens provided by the so-called "thick registries" including .biz and .info. However, overall knowledge of the thick registry transfer process, particularly at the Registrant level, is still minimal or non-existent. Some of the problems that have come to our attention include (a) that some Registrars are generating blanket (common) tokens for all domain name registrants; (b) other registrars are not providing tokens to their customers at all; (c) registrants are neither requesting tokens nor do they have an adequate understanding about the need or use for tokens. Finally, there do not yet exist secure and efficient systems for token retrieval (re-issuance) in cases where a token is lost or stolen. The net result is that few unique, secure and valid tokens are getting into the hands of registrants, and hence to potential gaining Registrars. While this is not the result of bad faith or bad practice by Registrars, it is currently causing a gap in the education of the Registrar community and with our ultimate consumers, the Registrants. The industry and end-user population have simply not been educated in the proper use of "auth-info" tokens. This is the fault and responsibility of NeuLevel as much as anyone. We feel that it is both our responsibility and obligation to ensure that systems for the proper issue, storage and processing of tokens are institutionalized within the industry. ... Therefore, we intend to freeze .BIZ transfers for a period of 30 to 60 days and engage in a program of channel/user education regarding transfers with tokens. In this program we will work with you to create systems and awareness for the issue, storage and processing of secure, unique, valid tokens. We do not believe this is an insurmountable task. We are at fault for not initiating it sooner, and we want to advance this dialogue with you for the betterment of our industry practices and for the enhancement of the end-user experience." -rwr Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HLC2F8007938 for ; Thu, 17 Jan 2002 22:12:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HLC22Y007937 for ietf-provreg-outgoing; Thu, 17 Jan 2002 22:12:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from naptop.autonomica.se ([192.71.80.71]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HLC2F8007932 for ; Thu, 17 Jan 2002 22:12:02 +0100 (MET) Received: from naptop.autonomica.se (localhost [127.0.0.1]) by naptop.autonomica.se (8.12.1/8.12.0) with ESMTP id g0HLBqWZ000684 for ; Thu, 17 Jan 2002 22:11:53 +0100 (MET) Received: by naptop.autonomica.se (8.12.1/8.12.0/Submit) id g0HLBqtb000683 for ietf-provreg@cafax.se; Thu, 17 Jan 2002 22:11:52 +0100 (MET) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HEr9F8004813 for ; Thu, 17 Jan 2002 15:53:10 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0HEr2b10609; Thu, 17 Jan 2002 08:53:02 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 08:53:02 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181982@dc02.npac.com> From: "Liu, Hong" To: "'Hollenbeck, Scott'" , "'Bruce Tonkin'" Cc: ietf-provreg@cafax.se Subject: RE: MX records in epp Date: Thu, 17 Jan 2002 08:53:01 -0600 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 Scott, Bruce, Please also include me in this discussion. Thanks! --Hong Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKoQF8007754 for ; Thu, 17 Jan 2002 21:50:26 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HKoQ6C007753 for ietf-provreg-outgoing; Thu, 17 Jan 2002 21:50:26 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKoPF8007748 for ; Thu, 17 Jan 2002 21:50:25 +0100 (MET) Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g0HKoPJb010098 for ; Thu, 17 Jan 2002 21:50:25 +0100 Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g0HKoPKN010095 for ietf-provreg@cafax.se; Thu, 17 Jan 2002 21:50:25 +0100 Date: Thu, 17 Jan 2002 21:50:24 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: Re: Command and authInfo Message-ID: <20020117205024.GU24268@nohope.patoche.org> References: <20020117154320.GJ24268@nohope.patoche.org> <20020117200415.GR24268@nohope.patoche.org> <025001c19f97$05fe6240$040a000a@RRADER2K> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025001c19f97$05fe6240$040a000a@RRADER2K> User-Agent: Mutt/1.3.24i X-PGP-KeyID: A241FB6B X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Jan 17, 2002 at 03:39:12PM -0500, Ross Wm. Rader took time to write: > > Time will not change anything. auth_info for transfers just *adds* > > another layer of complexity, and do not help _at all_. > > If it was the contrary then why this last same week, both Afilias and > > Neulevel sent an email to all Registrars, one explaining again what > > the auth info is, the other saying that transfers will be blocked > > because *current* (and they are using EPP...) state does not allow to > > transfers without problems ? > > > Sorry to jump in here, but in the cases you describe above, the issue seems > to be largely social - and could probably be extended to any command in the > spec. If any party to the transaction induced by a command cannot/will > not/does not exhibit behavior conducive to transaction completing, then the > command will always be useless. > Or the command was badely designed. (it seems to me that if a Registry using EPP right now says that the current state is not ok to do transfers... then it is not a social problem of someone not willing to do something...) Transfers are specific because it involves 4 entities (Registry, 2 Registrars, Registrant). Other commands include only 3 (Registry, Registrar, Registrant). Patrick. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKkjF8007724 for ; Thu, 17 Jan 2002 21:46:45 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HKkjWD007723 for ietf-provreg-outgoing; Thu, 17 Jan 2002 21:46:45 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKkiF8007718 for ; Thu, 17 Jan 2002 21:46:44 +0100 (MET) Received: by sentry.gw.tislabs.com; id PAA23459; Thu, 17 Jan 2002 15:51:57 -0500 (EST) Received: from dhcp21.gw.tislabs.com(192.94.214.121) by sentry.gw.tislabs.com via smap (V5.5) id xma023429; Thu, 17 Jan 02 15:51:29 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B573@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jan 2002 12:25:46 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: MX records in epp Cc: "'Bruce Tonkin'" , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk If this matures and folks involved are so motivated, I'd like to see this come back to the list at some point. I'd like to see if this fits under the "E" in the protocol. Not that I'm promising that this would be within charter not am I inviting a WG document, but this may be an idea to explore. At 7:16 AM -0500 1/17/02, Hollenbeck, Scott wrote: >As Dave Crocker noted, the general provisioning case for MX records is >within leaf-node zones. If there are exceptions, like in .com.au, I'd >suggest defining a protocol extension to the domain mapping to describe MX >record provisioning. Let's take it off-list if you'd like to explore that >option. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKkiF8007716 for ; Thu, 17 Jan 2002 21:46:44 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HKkhb9007715 for ietf-provreg-outgoing; Thu, 17 Jan 2002 21:46:43 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKkgF8007710 for ; Thu, 17 Jan 2002 21:46:43 +0100 (MET) Received: by sentry.gw.tislabs.com; id PAA23475; Thu, 17 Jan 2002 15:51:57 -0500 (EST) Received: from dhcp21.gw.tislabs.com(192.94.214.121) by sentry.gw.tislabs.com via smap (V5.5) id xmaa23429; Thu, 17 Jan 02 15:51:32 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jan 2002 12:40:14 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: They're already calling for 53rd IETF Meetings Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk Right now we are getting the requirements document back to the IESG. (I might add that I am optimistic that the wheels are in motion.) Scott is hammering out details of the drafts for which we have held a last call, so any week now, we'll have those documents going to the IESG. I feel that it is important to progress those now so that implementations can mature more rapidly in this quarter of the year. We have a few other drafts under way. There hasn't been much in the way of activity over those documents - a least in mail list discussions. Given that and the need to produce implemenations: Do we need to have a time slot in Minneapolis? Send in your opinion(s) and, if you think we need to meet, suggest an annotated agenda item. Also - if you are implementing, begin to consider how you might want to participate in an interoperability test. PS - As one of the chairs, I'm 50-50 on the need for a meeting. But I'd suggest one only if there is a need to have one. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKdGF8007652 for ; Thu, 17 Jan 2002 21:39:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HKdFkE007651 for ietf-provreg-outgoing; Thu, 17 Jan 2002 21:39:15 +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 (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HKdEF8007646 for ; Thu, 17 Jan 2002 21:39:14 +0100 (MET) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 16RJJZ-0007lv-00; Thu, 17 Jan 2002 15:39:13 -0500 Message-ID: <025001c19f97$05fe6240$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: "Patrick" , References: <20020117154320.GJ24268@nohope.patoche.org> <20020117200415.GR24268@nohope.patoche.org> Subject: Re: Command and authInfo Date: Thu, 17 Jan 2002 15:39:12 -0500 Organization: Tucows Inc. 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 > Time will not change anything. auth_info for transfers just *adds* > another layer of complexity, and do not help _at all_. > If it was the contrary then why this last same week, both Afilias and > Neulevel sent an email to all Registrars, one explaining again what > the auth info is, the other saying that transfers will be blocked > because *current* (and they are using EPP...) state does not allow to > transfers without problems ? Sorry to jump in here, but in the cases you describe above, the issue seems to be largely social - and could probably be extended to any command in the spec. If any party to the transaction induced by a command cannot/will not/does not exhibit behavior conducive to transaction completing, then the command will always be useless. -rwr Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HK4HF8007421 for ; Thu, 17 Jan 2002 21:04:17 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HK4HsO007420 for ietf-provreg-outgoing; Thu, 17 Jan 2002 21:04:17 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HK4GF8007415 for ; Thu, 17 Jan 2002 21:04:16 +0100 (MET) Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g0HK4FJb008673 for ; Thu, 17 Jan 2002 21:04:15 +0100 Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g0HK4FQR008670 for ietf-provreg@cafax.se; Thu, 17 Jan 2002 21:04:15 +0100 Date: Thu, 17 Jan 2002 21:04:15 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: Re: Command and authInfo Message-ID: <20020117200415.GR24268@nohope.patoche.org> References: <20020117154320.GJ24268@nohope.patoche.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i X-PGP-KeyID: A241FB6B X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Jan 17, 2002 at 10:53:13AM -0800, Rick H Wesson took time to write: > > I agree with Bruce on this : the authinfo should have a bigger scope. > > > > Right now it is only for transfers (and thus should have been called > > transfer auth or something like that, not auth info), and as we > > already see it with some Registries using EPP, transfers are hard. > > so transfers are hard with auth-info, thats what i expected, it may take > some time for registrars and registrants to learn to deal with thisck > registries and epp based ones. My point is : if we added auth_info to handle transfer, and to hope that this will make transfers easier, I am sorry but the point is ALREADY missed, and will be even more in the future. This is fact and reality. This is unfortunate, I know. On the paper, everything is great. In life, not so. Time will not change anything. auth_info for transfers just *adds* another layer of complexity, and do not help _at all_. If it was the contrary then why this last same week, both Afilias and Neulevel sent an email to all Registrars, one explaining again what the auth info is, the other saying that transfers will be blocked because *current* (and they are using EPP...) state does not allow to transfers without problems ? Thus, let at least make something useful to this concept of adding an ``authorisation'' at the domain layer (instead of at the contact layer, like it is done so often). > > IMNSHO auth info should enable someone having it to make > > modifications (that is update at least, maybe delete and renew) > > through any other ways (other Registrars, or even the Registry > > directly). Protocols should make that possible, and then > > local policies should specify if it is to be used or not, and if yes, > > how. > > > the consept is that auth-info aids in identifying an entity with > authorization to transfer. The EPP mind-set is that the sponsoring > registrar can updat their own objects; thus its the sponsoring registrar > to authenticate not the registry except in the case of a transfer where by > the gaining registrar authenticates with the registry by the use of the > auth-info token. > > This approch seems reasonable because it MUST be up to the sponsoring > registrar to authenticate in this three-tear model. It mkaes the most > sense from a client-server perspective too. I am not saying this approach is never reasonable. I just say that sometimes yes, sometimes not. Things should not be done so that it can be the only option, otherwise EPP will never get used by more than 5 Registries (the ``gTLD'' ones). Patrick. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HJwfF8007384 for ; Thu, 17 Jan 2002 20:58:41 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HJwf2N007383 for ietf-provreg-outgoing; Thu, 17 Jan 2002 20:58:41 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HJweF8007378 for ; Thu, 17 Jan 2002 20:58:41 +0100 (MET) Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g0HJwdJb008578 for ; Thu, 17 Jan 2002 20:58:40 +0100 Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g0HJwdGn008575 for ietf-provreg@cafax.se; Thu, 17 Jan 2002 20:58:39 +0100 Date: Thu, 17 Jan 2002 20:58:39 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: Re: Command and authInfo Message-ID: <20020117195839.GQ24268@nohope.patoche.org> References: <20020117175307.29926.qmail@www3.nameplanet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020117175307.29926.qmail@www3.nameplanet.com> User-Agent: Mutt/1.3.24i X-PGP-KeyID: A241FB6B X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Jan 17, 2002 at 05:53:07PM -0000, asbjorn.rrp@theglobalname.org took time to write: > On Thu, 17 Jan 2002 16:43:20 +0100 Patrick wrote: > >IMNSHO auth info should enable someone having it to make > >modifications (that is update at least, maybe delete and renew) > >through any other ways (other Registrars, or even the Registry > >directly). Protocols should make that possible, and then > >local policies should specify if it is to be used or not, and if yes, > >how. > > I can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar. > > Scenario: Registrar A is extremely cheap so I register my domain there, but registrar B has a great user interface for maintaining and modifying objects, so I use their interface instead of registrar a's. Registrar A will get my money, whereas registrar B has to do all the work for a "non-customer". I misexplained myself. I myself would not like that what I describe is possible. However I think this is a policy problem, not a protocol on. Thus the protocol should not be made so that this policy is not possible, if the Registry of a given TLD chooses to do so. There are Registries dealing with customers directly. .uk comes to my mind. The case of doing changes through a different Registrars might be something very interesting when one Registrars fails or has so many problems that it is not used anymore. As for your example it is flawed, since Registrar B can totally ask for a fee to change domain names handled by other REgistrar. Your money problem disappear. So my point is that we should take into account all models, and leave place for all future ones. We should not do things as they are currently in .COM/.NET/.ORG just because they are so. If the true aim of this protocol is to be generic, and not to be just a replacement of RRP, then it must not add constraints that may be problems. Patrick. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HJWOF8007203 for ; Thu, 17 Jan 2002 20:32:24 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HJWOaU007202 for ietf-provreg-outgoing; Thu, 17 Jan 2002 20:32:24 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HJWNF8007197 for ; Thu, 17 Jan 2002 20:32:23 +0100 (MET) Received: from repligate (as1-50.chi.il.dial.anet.com [198.92.156.50]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0HJWKWp010463; Thu, 17 Jan 2002 13:32:21 -0600 (CST) Message-ID: <053001c19f9e$8c29e6d0$0100a8c0@repligate> From: "Jim Fleming" To: Cc: References: <200201172112.g0HLCar10161@nic-naa.net> Subject: Re: Command and authInfo Date: Thu, 17 Jan 2002 13:32:58 -0800 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 The year is 2002... The notion of a "gTLD" appears to be some out-dated concept from the "toy", legacy, IPv4 Internet. Registrar and Registry are artificial creations of multi-level-marketing structures. It is not clear what the IETF has to do with marketing or markets, etc. That would seem to be more of what one would find in the EPP Trade Association. http://sourceforge.net/projects/epp-ta/ As for 2002 TLDs....things are shaping up... 2002 0:201 .COM 2002 1:158 .CLUB 2002 2:143 .FAMILY 2002 3:219 .INFO 2002 4:58 .LLC 2002 5:194 .INC 2002 6:171 .TV 2002 7:195 .CHURCH Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To: Cc: ; Sent: Thursday, January 17, 2002 1:12 PM Subject: Re: Command and authInfo > Asbjorn, > > When a registrar fails, the "should" ceases to be controlling, as a "must" > may arise. It is an edge case, but for EPP deployments outside of the gTLD > market, the space of reasonable assumptions is larger, or less constrained, > than inside the gTLD market, and we have to solve for the larger problem. > > Eric > wampumpeag, llc Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HIrHF8006454 for ; Thu, 17 Jan 2002 19:53:17 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HIrHmd006449 for ietf-provreg-outgoing; Thu, 17 Jan 2002 19:53:17 +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.2/8.12.2) with ESMTP id g0HIrFF8006442 for ; Thu, 17 Jan 2002 19:53:16 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0HIrDYZ017426; Thu, 17 Jan 2002 10:53:13 -0800 (PST) Date: Thu, 17 Jan 2002 10:53:13 -0800 (PST) From: Rick H Wesson To: Patrick cc: Subject: Re: Command and authInfo In-Reply-To: <20020117154320.GJ24268@nohope.patoche.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Patrick, On Thu, 17 Jan 2002, Patrick wrote: > On Tue, Jan 15, 2002 at 10:28:50AM -0500, Hollenbeck, Scott took time to write: > > I'm not so sure of the benefit in putting into the , > > and commands given the discussion we had on the list some > > time ago (we DID have it that way, and then folks wanted it removed from all > > but ), but I understand what you're saying about the dates and the > > command. > > I agree with Bruce on this : the authinfo should have a bigger scope. > > Right now it is only for transfers (and thus should have been called > transfer auth or something like that, not auth info), and as we > already see it with some Registries using EPP, transfers are hard. so transfers are hard with auth-info, thats what i expected, it may take some time for registrars and registrants to learn to deal with thisck registries and epp based ones. > The auth info does not help anything regarding transfers. > It just complicates things (current Registrar not giving it, and if > the new Registrar already asks contacts for approval, the authinfo is > of nouse... since it will be given to contacts, thus same problems in > both case of hijacking and such). > IMNSHO auth info should enable someone having it to make > modifications (that is update at least, maybe delete and renew) > through any other ways (other Registrars, or even the Registry > directly). Protocols should make that possible, and then > local policies should specify if it is to be used or not, and if yes, > how. the consept is that auth-info aids in identifying an entity with authorization to transfer. The EPP mind-set is that the sponsoring registrar can updat their own objects; thus its the sponsoring registrar to authenticate not the registry except in the case of a transfer where by the gaining registrar authenticates with the registry by the use of the auth-info token. This approch seems reasonable because it MUST be up to the sponsoring registrar to authenticate in this three-tear model. It mkaes the most sense from a client-server perspective too. -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HIE2F8006070 for ; Thu, 17 Jan 2002 19:14:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HIE2Sm006069 for ietf-provreg-outgoing; Thu, 17 Jan 2002 19:14:02 +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-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HIE0F8006064 for ; Thu, 17 Jan 2002 19:14:00 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0HLCar10161; Thu, 17 Jan 2002 13:12:36 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201172112.g0HLCar10161@nic-naa.net> To: asbjorn.rrp@theglobalname.org cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Command and authInfo In-Reply-To: Your message of "17 Jan 2002 17:53:07 GMT." <20020117175307.29926.qmail@www3.nameplanet.com> Date: Thu, 17 Jan 2002 13:12:36 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Asbjorn, When a registrar fails, the "should" ceases to be controlling, as a "must" may arise. It is an edge case, but for EPP deployments outside of the gTLD market, the space of reasonable assumptions is larger, or less constrained, than inside the gTLD market, and we have to solve for the larger problem. Eric wampumpeag, llc Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HHr9F8005907 for ; Thu, 17 Jan 2002 18:53:09 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HHr96Z005906 for ietf-provreg-outgoing; Thu, 17 Jan 2002 18:53:09 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx13.nameplanet.com (mx13.nameplanet.com [62.70.3.43]) by nic.cafax.se (8.12.2/8.12.2) with SMTP id g0HHr7F8005901 for ; Thu, 17 Jan 2002 18:53:08 +0100 (MET) Received: 17 Jan 2002 17:53:07 -0000 Received: from unknown (HELO www3.nameplanet.com) (192.168.2.43) by mx13 with SMTP; 17 Jan 2002 17:53:07 -0000 Received: (qmail 29932 invoked by uid 400); 17 Jan 2002 17:53:07 -0000 Date: 17 Jan 2002 17:53:07 -0000 Message-ID: <20020117175307.29926.qmail@www3.nameplanet.com> From: asbjorn.rrp@theglobalname.org To: ietf-provreg@cafax.se MIME-Version: 1.0 Subject: Re: Command and authInfo Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, 17 Jan 2002 16:43:20 +0100 Patrick wrote: >IMNSHO auth info should enable someone having it to make >modifications (that is update at least, maybe delete and renew) >through any other ways (other Registrars, or even the Registry >directly). Protocols should make that possible, and then >local policies should specify if it is to be used or not, and if yes, >how. I can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar. Scenario: Registrar A is extremely cheap so I register my domain there, but registrar B has a great user interface for maintaining and modifying objects, so I use their interface instead of registrar a's. Registrar A will get my money, whereas registrar B has to do all the work for a "non-customer". But what I might agree upon is that if you want to transfer a domain and have the authInfo, why should the losing registrar need to approve it? :-d Asbjorn Global Name Registry, Limited -- The information transmitted in this email is intended only for the person(s) or entity to which it is addressed and may contain proprietary, confidential and/or privileged material. If you have received this email in error, please contact the sender by replying and delete this email so that it is not recoverable. If you are not the intended recipient(s), any retention, review, disclosure, distribution, copying, printing, dissemination, or other use of, or taking of any action in reliance upon, this information is strictly prohibited and without liability on our part. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HFhQF8005125 for ; Thu, 17 Jan 2002 16:43:26 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HFhPaP005124 for ietf-provreg-outgoing; Thu, 17 Jan 2002 16:43:25 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HFhOF8005114 for ; Thu, 17 Jan 2002 16:43:25 +0100 (MET) Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g0HFhLJb032249 for ; Thu, 17 Jan 2002 16:43:21 +0100 Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g0HFhL4Q032246 for ietf-provreg@cafax.se; Thu, 17 Jan 2002 16:43:21 +0100 Date: Thu, 17 Jan 2002 16:43:20 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: Re: Command and authInfo Message-ID: <20020117154320.GJ24268@nohope.patoche.org> References: <3CD14E451751BD42BA48AAA50B07BAD60189B566@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B566@vsvapostal3.bkup6> User-Agent: Mutt/1.3.24i X-PGP-KeyID: A241FB6B X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Jan 15, 2002 at 10:28:50AM -0500, Hollenbeck, Scott took time to write: > I'm not so sure of the benefit in putting into the , > and commands given the discussion we had on the list some > time ago (we DID have it that way, and then folks wanted it removed from all > but ), but I understand what you're saying about the dates and the > command. I agree with Bruce on this : the authinfo should have a bigger scope. Right now it is only for transfers (and thus should have been called transfer auth or something like that, not auth info), and as we already see it with some Registries using EPP, transfers are hard. The auth info does not help anything regarding transfers. It just complicates things (current Registrar not giving it, and if the new Registrar already asks contacts for approval, the authinfo is of nouse... since it will be given to contacts, thus same problems in both case of hijacking and such). IMNSHO auth info should enable someone having it to make modifications (that is update at least, maybe delete and renew) through any other ways (other Registrars, or even the Registry directly). Protocols should make that possible, and then local policies should specify if it is to be used or not, and if yes, how. Regards, Patrick. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HFQiF8004993 for ; Thu, 17 Jan 2002 16:26:44 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HFQi7L004992 for ietf-provreg-outgoing; Thu, 17 Jan 2002 16:26:44 +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.2/8.12.2) with ESMTP id g0HFQgF8004987 for ; Thu, 17 Jan 2002 16:26:42 +0100 (MET) Received: (from jaap@localhost) by bartok.sidn.nl (8.11.6/8.11.6) id g0HFQbq03676 for ietf-provreg@cafax.se; Thu, 17 Jan 2002 16:26:37 +0100 (CET) (envelope-from jaap) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HEr9F8004813 for ; Thu, 17 Jan 2002 15:53:10 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0HEr2b10609; Thu, 17 Jan 2002 08:53:02 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 08:53:02 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181982@dc02.npac.com> From: "Liu, Hong" To: "'Hollenbeck, Scott'" , "'Bruce Tonkin'" Cc: ietf-provreg@cafax.se Subject: RE: MX records in epp Date: Thu, 17 Jan 2002 08:53:01 -0600 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 Scott, Bruce, Please also include me in this discussion. Thanks! --Hong Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HD3bF8004051 for ; Thu, 17 Jan 2002 14:03:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HD3btI004050 for ietf-provreg-outgoing; Thu, 17 Jan 2002 14:03: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-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HD3aF8004045 for ; Thu, 17 Jan 2002 14:03:36 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0HG29r09327; Thu, 17 Jan 2002 08:02:09 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201171602.g0HG29r09327@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Hollenbeck, Scott" cc: "'Bruce Tonkin'" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: MX records in epp In-Reply-To: Message from "Hollenbeck, Scott" of "Thu, 17 Jan 2002 07:16:45 EST." <3CD14E451751BD42BA48AAA50B07BAD60189B573@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jan 2002 08:02:09 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, Bruce, Please copy me on this (). TiA, Eric wampumpeag, llc Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HCDrF8003759 for ; Thu, 17 Jan 2002 13:13:53 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0HCDrFs003758 for ietf-provreg-outgoing; Thu, 17 Jan 2002 13:13:53 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0HCDoF8003753 for ; Thu, 17 Jan 2002 13:13:51 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA00736; Thu, 17 Jan 2002 07:13:38 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 07:13:23 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B573@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Bruce Tonkin'" Cc: ietf-provreg@cafax.se Subject: RE: MX records in epp Date: Thu, 17 Jan 2002 07:16:45 -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 > -----Original Message----- > From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] > Sent: Wednesday, January 16, 2002 9:02 PM > To: 'Hollenbeck, Scott' > Cc: ietf-provreg@cafax.se > Subject: MX records in epp > > > Hello Scott, > > In the ".com.au" zone file we have MX records for some > domains instead of NS > records. > > e.g domainname.com.au IN MX 10 mailserver.com.au > > How do you think this should be accommodated within EPP.? > > The domain name mapping object currently has: > > > > Do we need a: > ? As Dave Crocker noted, the general provisioning case for MX records is within leaf-node zones. If there are exceptions, like in .com.au, I'd suggest defining a protocol extension to the domain mapping to describe MX record provisioning. Let's take it off-list if you'd like to explore that option. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0H2PdF8001234 for ; Thu, 17 Jan 2002 03:25:39 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g0H2Pd2E001233 for ietf-provreg-outgoing; Thu, 17 Jan 2002 03:25:39 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0H2PUF8001228 for ; Thu, 17 Jan 2002 03:25:31 +0100 (MET) Received: from 208.184.79.252.songbird.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with SMTP id SAA05398; Wed, 16 Jan 2002 18:25:24 -0800 X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol Message-Id: <5.1.0.14.2.20020116182241.03a031e8@127.0.0.1> X-Sender: dcrocker@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Jan 2002 18:26:20 -0800 To: Bruce Tonkin From: Dave Crocker Subject: Re: MX records in epp Cc: "'Hollenbeck, Scott'" , ietf-provreg@cafax.se In-Reply-To: <1595534C9032D411AECE00508BC766FB028E537B@mercury.mit> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 01:01 PM 1/17/2002 +1100, Bruce Tonkin wrote: >How do you think this should be accommodated within EPP.? hmmm. this is a case of administering entries within the domain name's leaf node, rather than administering the registry's entry pointing to that leaf node. It is, of course, an entirely reasonable service to offer, but it also can easily be viewed as a separate activity from basic domain name "registration". Given that there are a variety of additional uses and venues being contemplated for the protocol, perhaps this query raises an easy second venue to explore... once the current one is completed. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0H222F8000718 for ; Thu, 17 Jan 2002 03:02:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0H222IL000717 for ietf-provreg-outgoing; Thu, 17 Jan 2002 03:02:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from leda.mit (king22.MelbourneIT.com.au [203.31.198.22]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0H21xF8000712 for ; Thu, 17 Jan 2002 03:02:01 +0100 (MET) Received: from mercury.mit (mercury.mit [192.168.80.36]) by leda.mit (8.9.3/8.9.3) with ESMTP id NAA20472; Thu, 17 Jan 2002 13:01:40 +1100 Received: by mercury.mit with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 13:01:40 +1100 Message-ID: <1595534C9032D411AECE00508BC766FB028E537B@mercury.mit> From: Bruce Tonkin To: "'Hollenbeck, Scott'" Cc: ietf-provreg@cafax.se Subject: MX records in epp Date: Thu, 17 Jan 2002 13:01:37 +1100 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 Hello Scott, In the ".com.au" zone file we have MX records for some domains instead of NS records. e.g domainname.com.au IN MX 10 mailserver.com.au How do you think this should be accommodated within EPP.? The domain name mapping object currently has: Do we need a: ? For further info. see RFC974: MAIL ROUTING AND THE DOMAIN SYSTEM and section 8 of RFC1035. Bruce Tonkin Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0GC3eF8025816 for ; Wed, 16 Jan 2002 13:03:40 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0GC3eZv025815 for ietf-provreg-outgoing; Wed, 16 Jan 2002 13:03:40 +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.2/8.12.2) with ESMTP id g0GC3cF8025810 for ; Wed, 16 Jan 2002 13:03:38 +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 HAA04828; Wed, 16 Jan 2002 07:03:35 -0500 (EST) Message-Id: <200201161203.HAA04828@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: I-D ACTION:draft-ietf-provreg-grrp-reqs-05.txt Date: Wed, 16 Jan 2002 07:03:35 -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 : Generic Registry-Registrar Protocol Requirements Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-grrp-reqs-05.txt Pages : 24 Date : 15-Jan-02 This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-05.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-grrp-reqs-05.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-grrp-reqs-05.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: <20020115134952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-grrp-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020115134952.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0GBlwF8025753 for ; Wed, 16 Jan 2002 12:47:58 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0GBlwZf025752 for ietf-provreg-outgoing; Wed, 16 Jan 2002 12:47:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from moutng1.schlund.de (moutng1.kundenserver.de [212.227.126.171]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0GBlvF8025747 for ; Wed, 16 Jan 2002 12:47:57 +0100 (MET) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by moutng1.schlund.de with esmtp (Exim 3.22 #2) id 16QoXt-0000Ad-00; Wed, 16 Jan 2002 12:47:57 +0100 Received: from rocco.schlund.de ([172.17.0.162] helo=schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 16QoXs-0004NX-00; Wed, 16 Jan 2002 12:47:56 +0100 Message-ID: <3C45686B.B10150AD@schlund.de> Date: Wed, 16 Jan 2002 12:47:55 +0100 From: Jens-Uwe Gaspar Organization: Schlund + Partner AG X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: Command and authInfo References: <3CD14E451751BD42BA48AAA50B07BAD60189B56E@vsvapostal3.bkup6> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > > -----Original Message----- > > From: Jens-Uwe Gaspar [mailto:jug@schlund.de] > > Sent: Tuesday, January 15, 2002 1:06 PM > > To: ietf-provreg@cafax.se > > Subject: Re: Command and authInfo > > > > While registering a new object (domain, contact or host), it > > may happen, > > that in the registry the object was registered, but > > accidently our database > > will fail (cause of deadlock, DB-maintenance, or whatever). > > Because there's no transaction enclosing registry _and_ > > registrars actions, > > we must recommence registering the object (dom/contact/host): > > > > existence of object; > > if existing, do to get [sponsoring registrar]: > > if [sponsoring registrar] not equal to ourselves => we're > > sad registrar > > and stop further action for this object > > else: we're happy registrar and go on with further actions :) > > > > In practice it stands the test (.INFO/.BIZ) and we would appreciate, > > if that's also be possible in future versions of EPP. > > You can achieve exactly the same results without having to determine the > sponsoring client. Do an , if you're not the sponsor you get back a > "you're not authorized" error code => you're sad. If you are, works > and you're happy. It's also less work for the server if you're not the > sponsor as no data has to be retrieved from a local data store to generate > the error response. I'm aware of that, but when i follow Bruce Tonkin's note: BT> Bear in mind, that in future the use of EPP to talk to the BT> registry may not be restricted to entities such as authorised BT> registrars [...] then there maybe a) normal users doing an -> "not authorized", maybe because client has no access-right to do it, or b) registrar doing an -> "not authorized", because not current sponsoring registrar, c) registrar doing an -> "not authorized", because not allowed to do it (of whatever reason there could be: e.g. billing, etc). I'm not sure, if it's a good idea to use the error code "not authorized" to indicate that you're not the sponsoring registrar (b), because then you can't differ it from case (c) stated above. > > With respect to current implementations, while I can appreciate the insights > gained in writing code to the specs, we as WG can't have our focus limited > by code written to I-Ds. We need to be able to change the specs as issues > are found and explored, even if that means someone might have to change > code. Sure, i only wanted to give an example in which the -data is used. > > > Do you want to restrict returning the object data completely, or do you > > allow returning parts (changing minOccurs in the specs)? > > > > For example, reducing result-data to the output the corresponding > > whois-server list, if requested by a registrar other than the current > > sponsoring one. > > This might be a reasonable compromise. My initial thought was to restrict > it completely, but maybe there's no harm in returning a subset of the info > if the querying client isn't the sponsor and doesn't have the authInfo. > > -Scott- Best regards, Jens-Uwe Gaspar ________________________________________________________________________ Jens-Uwe Gaspar Schlund + Partner AG E-Mail: jug@schlund.de Erbprinzenstr. 4 - 12 Tel. +49-721-91374-50 76133 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0G7brF8024658 for ; Wed, 16 Jan 2002 08:37:53 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0G7br86024657 for ietf-provreg-outgoing; Wed, 16 Jan 2002 08:37:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from leda.mit (king22.MelbourneIT.com.au [203.31.198.22]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0G7boF8024652 for ; Wed, 16 Jan 2002 08:37:51 +0100 (MET) Received: from mercury.mit (mercury.mit [192.168.80.36]) by leda.mit (8.9.3/8.9.3) with ESMTP id SAA24508; Wed, 16 Jan 2002 18:36:58 +1100 Received: by mercury.mit with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 18:36:58 +1100 Message-ID: <1595534C9032D411AECE00508BC766FB028E5365@mercury.mit> From: Bruce Tonkin To: "'Hollenbeck, Scott'" , ietf-provreg@cafax.se Subject: RE: Command and authInfo Date: Wed, 16 Jan 2002 18:36:57 +1100 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 Hello Scott, > > This might be a reasonable compromise. My initial thought > was to restrict > it completely, but maybe there's no harm in returning a > subset of the info > if the querying client isn't the sponsor and doesn't have the > authInfo. > I prefer the latter option. ie returning different subsets of information depending on the credentials of the party executing the command. Bear in mind, that in future the use of EPP to talk to the registry may not be restricted to entities such as authorised registrars (that is really only an artifact of the current ".biz", ".info" etc structure). There is no reason why any member of public should not be able to query the registry via EPP (and get the advantage of structured XML responses) and get back public info (such as WHOIS info). Of course you could even create a separate WHOIS like service using separate infrastructure that responds to EPP commands. In some ways it may relieve some of the debate in WHOIS - where debate runs wild on appropriate data formats etc. Regards, Bruce Tonkin Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0G1nDF8022522 for ; Wed, 16 Jan 2002 02:49:13 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0G1nDqZ022521 for ietf-provreg-outgoing; Wed, 16 Jan 2002 02:49:13 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0G1nBF8022516 for ; Wed, 16 Jan 2002 02:49:12 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA13202; Tue, 15 Jan 2002 20:49:09 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 20:46:05 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B56E@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Jens-Uwe Gaspar'" , ietf-provreg@cafax.se Subject: RE: Command and authInfo Date: Tue, 15 Jan 2002 20:52:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Jens-Uwe Gaspar [mailto:jug@schlund.de] > Sent: Tuesday, January 15, 2002 1:06 PM > To: ietf-provreg@cafax.se > Subject: Re: Command and authInfo > > > > While registering a new object (domain, contact or host), it > may happen, > that in the registry the object was registered, but > accidently our database > will fail (cause of deadlock, DB-maintenance, or whatever). > Because there's no transaction enclosing registry _and_ > registrars actions, > we must recommence registering the object (dom/contact/host): > > existence of object; > if existing, do to get [sponsoring registrar]: > if [sponsoring registrar] not equal to ourselves => we're > sad registrar > and stop further action for this object > else: we're happy registrar and go on with further actions :) > > In practice it stands the test (.INFO/.BIZ) and we would appreciate, > if that's also be possible in future versions of EPP. You can achieve exactly the same results without having to determine the sponsoring client. Do an , if you're not the sponsor you get back a "you're not authorized" error code => you're sad. If you are, works and you're happy. It's also less work for the server if you're not the sponsor as no data has to be retrieved from a local data store to generate the error response. With respect to current implementations, while I can appreciate the insights gained in writing code to the specs, we as WG can't have our focus limited by code written to I-Ds. We need to be able to change the specs as issues are found and explored, even if that means someone might have to change code. > Do you want to restrict returning the object data completely, or do you > allow returning parts (changing minOccurs in the specs)? > > For example, reducing result-data to the output the corresponding > whois-server list, if requested by a registrar other than the current > sponsoring one. This might be a reasonable compromise. My initial thought was to restrict it completely, but maybe there's no harm in returning a subset of the info if the querying client isn't the sponsor and doesn't have the authInfo. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0G1glF8022493 for ; Wed, 16 Jan 2002 02:42:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0G1glOh022492 for ietf-provreg-outgoing; Wed, 16 Jan 2002 02:42:47 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from leda.mit (king22.MelbourneIT.com.au [203.31.198.22]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0G1ghF8022484 for ; Wed, 16 Jan 2002 02:42:45 +0100 (MET) Received: from mercury.mit (mercury.mit [192.168.80.36]) by leda.mit (8.9.3/8.9.3) with ESMTP id MAA23053; Wed, 16 Jan 2002 12:42:35 +1100 Received: by mercury.mit with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 12:42:35 +1100 Message-ID: <1595534C9032D411AECE00508BC766FB028E535A@mercury.mit> From: Bruce Tonkin To: "'Hollenbeck, Scott'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Command and authInfo Date: Wed, 16 Jan 2002 12:42:34 +1100 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 Hello Scott, > > I'm not so sure of the benefit in putting into the > , > and commands given the discussion we had on > the list some > time ago (we DID have it that way, and then folks wanted it > removed from all > but ), but I understand what you're saying about > the dates and the > command. I can't remember the previous discussions, but I am only saying that it should be available OPTIONALLY. There are some better securiy models possible, where passwords may be dynamically updated, that might result in transaction security for updates etc being done on a per domain name level, rather than relying solely on registrar security/authentication (via the login command). A potential security flaw in the current system, is that if the registrar is compromised, than an un-authorised entity could potentially have access to update etc - all records associated with that particular registrar. I think from a generic registry perspective, it should be possible to provide better security around commands that change the status of individual objects in the registry. I can think of value added services, where additional security could be purchased from the registry via registrars for some domain names. Regards, Bruce Tonkin Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0FI64F8019981 for ; Tue, 15 Jan 2002 19:06:04 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0FI64ME019980 for ietf-provreg-outgoing; Tue, 15 Jan 2002 19:06:04 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from moutng1.schlund.de (moutng1.kundenserver.de [212.227.126.171]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0FI63F8019975 for ; Tue, 15 Jan 2002 19:06:03 +0100 (MET) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by moutng1.schlund.de with esmtp (Exim 3.22 #2) id 16QXyB-0000Op-00 for ietf-provreg@cafax.se; Tue, 15 Jan 2002 19:05:59 +0100 Received: from rocco.schlund.de ([172.17.0.162] helo=schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 16QXyB-0007UM-00 for ietf-provreg@cafax.se; Tue, 15 Jan 2002 19:05:59 +0100 Message-ID: <3C446F86.9D521E77@schlund.de> Date: Tue, 15 Jan 2002 19:05:58 +0100 From: Jens-Uwe Gaspar Organization: Schlund + Partner AG X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: Re: Command and authInfo References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Rick H Wesson wrote: >... > On Mon, 14 Jan 2002, Hollenbeck, Scott wrote: >... > > You've suggested that "the status command should be open to all registrars". > > Let's change "status" to to make this about EPP and not RRP. Here's > > my question to you: other than as part of requesting a transfer, what other > > _technical_ reason(s) does a client have to perform an command on a > > domain sponsored by another client? > > durring expiration, if its a name you are competeing over its a > requirement to know if the domain is recently registered. there are other > examples but I can't disclose some other registrar's business practices While registering a new object (domain, contact or host), it may happen, that in the registry the object was registered, but accidently our database will fail (cause of deadlock, DB-maintenance, or whatever). Because there's no transaction enclosing registry _and_ registrars actions, we must recommence registering the object (dom/contact/host): existence of object; if existing, do to get [sponsoring registrar]: if [sponsoring registrar] not equal to ourselves => we're sad registrar and stop further action for this object else: we're happy registrar and go on with further actions :) In practice it stands the test (.INFO/.BIZ) and we would appreciate, if that's also be possible in future versions of EPP. Do you want to restrict returning the object data completely, or do you allow returning parts (changing minOccurs in the specs)? For example, reducing result-data to the output the corresponding whois-server list, if requested by a registrar other than the current sponsoring one. Best regards, Jens-Uwe Gaspar > [snip] ________________________________________________________________________ Jens-Uwe Gaspar Schlund + Partner AG E-Mail: jug@schlund.de Erbprinzenstr. 4 - 12 Tel. +49-721-91374-50 76133 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0FFPdF8018899 for ; Tue, 15 Jan 2002 16:25:39 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g0FFPdPF018895 for ietf-provreg-outgoing; Tue, 15 Jan 2002 16:25:39 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g0FFPZF8018888 for ; Tue, 15 Jan 2002 16:25:37 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA05203; Tue, 15 Jan 2002 10:25:23 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:22:20 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B566@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Bruce Tonkin'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Command and authInfo Date: Tue, 15 Jan 2002 10:28:50 -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 > -----Original Message----- > From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] > Sent: Monday, January 14, 2002 6:42 PM > To: 'Hollenbeck, Scott' > Cc: 'ietf-provreg@cafax.se' > Subject: RE: Command and authInfo > > > Hello Scott, > > > > > I'm wondering how people feel about adding an optional element to > > the domain command. [snip] > I would support that. I have been reviewing the EPP specs for ".au", and I > had the same thought that the authinfo element should be available with > commands other than transfer, but that it should be optional. You might > consider it for , and . > > It provides a bit more flexibility for the registry. > > I also think that some of the data elements in the epp-domain-03.txt > should be made optional (ie minOccurs="0") (ie returned to the sponsoring > registrar only, or returned to a registrar that uses the authinfo element). > For example: and . These two dates are being > used extensively in Australia for unsolicited spamming of registrants for > renewals. We don't currently display expiry date information to other than > the sponsoring reseller. Bruce, I'm not so sure of the benefit in putting into the , and commands given the discussion we had on the list some time ago (we DID have it that way, and then folks wanted it removed from all but ), but I understand what you're saying about the dates and the command. While there might be business models built around acquiring those dates, I'm not sure that it's good engineering to have _all_ domain info available to any client who cares to look. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0ENgBC2008504 for ; Tue, 15 Jan 2002 00:42:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0ENgBIi008503 for ietf-provreg-outgoing; Tue, 15 Jan 2002 00:42:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from leda.mit (king22.MelbourneIT.com.au [203.31.198.22]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0ENg8C2008498 for ; Tue, 15 Jan 2002 00:42:09 +0100 (MET) Received: from mercury.mit (mercury.mit [192.168.80.36]) by leda.mit (8.9.3/8.9.3) with ESMTP id KAA14356; Tue, 15 Jan 2002 10:41:31 +1100 Received: by mercury.mit with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:41:31 +1100 Message-ID: <1595534C9032D411AECE00508BC766FB028E5334@mercury.mit> From: Bruce Tonkin To: "'Hollenbeck, Scott'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Command and authInfo Date: Tue, 15 Jan 2002 10:41:30 +1100 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 Hello Scott, > > I'm wondering how people feel about adding an optional > element to > the domain command. Sponsoring clients wouldn't have > to use it; they > can continue to "see" all of the domains they sponsor. > Clients who need to > see something in the context of a transfer can provide the > to see > domain object info via the protocol, eliminating the need to > go out-of-band. > Data mining protections are still in place because > non-sponsoring clients > who don't have the can't see domains sponsored by > other clients. > > This sort of change would let us tighten up the EPP spec a > bit, which should > help with interoperability. I know we finished a WG last > call, but I'm in > the docs now working on wrapping up the changes based on > last-call comments > and would like to know how folks feel about this change given their > operational experience with RRP. > I would support that. I have been reviewing the EPP specs for ".au", and I had the same thought that the authinfo element should be available with commands other than transfer, but that it should be optional. You might consider it for , and . It provides a bit more flexibility for the registry. I also think that some of the data elements in the epp-domain-03.txt should be made optional (ie minOccurs="0") (ie returned to the sponsoring registrar only, or returned to a registrar that uses the authinfo element). For example: and . These two dates are being used extensively in Australia for unsolicited spamming of registrants for renewals. We don't currently display expiry date information to other than the sponsoring reseller. Regards, Bruce Tonkin Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EJctC2006731 for ; Mon, 14 Jan 2002 20:38:55 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0EJct0s006730 for ietf-provreg-outgoing; Mon, 14 Jan 2002 20:38:55 +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.1/8.12.1) with ESMTP id g0EJcsC2006725 for ; Mon, 14 Jan 2002 20:38:54 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0EJcqYZ003307; Mon, 14 Jan 2002 11:38:52 -0800 (PST) Date: Mon, 14 Jan 2002 11:38:52 -0800 (PST) From: Rick H Wesson To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" Subject: RE: Command and authInfo In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B55E@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, On Mon, 14 Jan 2002, Hollenbeck, Scott wrote: > > "This action SHOULD be limited to authorized clients; restricting this > action to the sponsoring client is RECOMMENDED." > > My contention is that this leaves room for interoperability problems. A > client who expects a server to support unrestricted commands will > likely have problems at a higher layer when working with another server that > restricts commands as described in the spec. Maybe this is a false > assumption on my part, but that's why I floated the idea in the first place. yes it does, but thick and thin registries may not interoperate? there are other areas that registry policy MAY interfere with interoperability too such as how name servers are handeled. > I recognize the problem with RRP in the context of domain transfers, and I > don't want EPP to have the same problem. The gaining client has a > legitimate reason to see domain info as part of processing a transfer > request, they have the in-hand, and if the command is > changed as I described the client can perform the command > successfully. As the specs are currently written, a server can legitimately > prevent the gaining client from performing the command. I wanted to > suggest a change to make this scenario work while sticking to the spirit of > the "authorized clients" recommendation. then may i suggest the following language. "This action SHOULD be limited to authorized clients; restricting this action to the sponsoring client is NOT RECOMMENDED." it has the same effect on interoperability. > You've suggested that "the status command should be open to all registrars". > Let's change "status" to to make this about EPP and not RRP. Here's > my question to you: other than as part of requesting a transfer, what other > _technical_ reason(s) does a client have to perform an command on a > domain sponsored by another client? durring expiration, if its a name you are competeing over its a requirement to know if the domain is recently registered. there are other examples but I can't disclose some other registrar's business practices > Sorry if you've answered that question in some other forum recently, but > what I recall was gleaned from our shared experiences of mid-1999. Knowing > that some registries will likely implement EPP to the "authorized clients" > recommendation, I wanted to propose a solution that takes care of the > problem in the context of transfers. Yes, opening up the command completely > would also eliminate the problem, but I feel very strongly that it > introduces other problems relating to privacy and load management. Yes, > some of the info returned in response to an command is publicly > available via whois, but not everything is. the issues I have here is that your suggested fix to this "problem" is that it re-enforces a position, piticular to your employer, and the VeriSign Registrar. this where our misunderstanding might stem from, your suggestion makes it much easier for VGRS to implement a policy in EPP that Registrars using RRP have found VERY cumbersome. it is hard to keep RRP out of the converstaion as it has provided us with a wealth of reasons why the command should be available to all registrars. personal regards, -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EJH1C2006553 for ; Mon, 14 Jan 2002 20:17:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0EJH077006552 for ietf-provreg-outgoing; Mon, 14 Jan 2002 20:17:00 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EJGxC2006546 for ; Mon, 14 Jan 2002 20:16:59 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA13903; Mon, 14 Jan 2002 14:16:52 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 14:16:45 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B55E@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Rick H Wesson'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Command and authInfo Date: Mon, 14 Jan 2002 14:20:27 -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 Rick, While I appreciate the apology, I still think you're misunderstanding the intent of the proposal. The EPP spec has had recommendations in it (see the last paragraph of section 2.8.2.2 of epp-05, for example) for quite some time to describe how the commands should be implemented: "This action SHOULD be limited to authorized clients; restricting this action to the sponsoring client is RECOMMENDED." My contention is that this leaves room for interoperability problems. A client who expects a server to support unrestricted commands will likely have problems at a higher layer when working with another server that restricts commands as described in the spec. Maybe this is a false assumption on my part, but that's why I floated the idea in the first place. I recognize the problem with RRP in the context of domain transfers, and I don't want EPP to have the same problem. The gaining client has a legitimate reason to see domain info as part of processing a transfer request, they have the in-hand, and if the command is changed as I described the client can perform the command successfully. As the specs are currently written, a server can legitimately prevent the gaining client from performing the command. I wanted to suggest a change to make this scenario work while sticking to the spirit of the "authorized clients" recommendation. You've suggested that "the status command should be open to all registrars". Let's change "status" to to make this about EPP and not RRP. Here's my question to you: other than as part of requesting a transfer, what other _technical_ reason(s) does a client have to perform an command on a domain sponsored by another client? Sorry if you've answered that question in some other forum recently, but what I recall was gleaned from our shared experiences of mid-1999. Knowing that some registries will likely implement EPP to the "authorized clients" recommendation, I wanted to propose a solution that takes care of the problem in the context of transfers. Yes, opening up the command completely would also eliminate the problem, but I feel very strongly that it introduces other problems relating to privacy and load management. Yes, some of the info returned in response to an command is publicly available via whois, but not everything is. Finally, there was a recent thread on the list [1] about requiring for transfer queries. Folks supported that change. Don't the same privacy concerns come into play here? -Scott- [1] http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00043.html > -----Original Message----- > From: Rick H Wesson [mailto:wessorh@ar.com] > Sent: Monday, January 14, 2002 1:01 PM > To: Hollenbeck, Scott > Cc: 'ietf-provreg@cafax.se' > Subject: RE: Command and authInfo > > > > Scott, > > ok, my comments were not meant as an ad-hominem attack on you, we have > known each other a long time and I'm not attacking you > personally, but I > do have strong opinion on the subject from a long experience with RRP. > > registries have a contract with registrars and MUST enforce those > contracts; we should not be designing defense from datamining into the > protocols. registries MUST enforce their contracts and > provide appropriate > oversite of the registrars. > > We have recent experience of registrars abusing the common > resource of a > RRP based registry, just because the Registry does not enforce their > contracts does not mean we should design mechanisms into the > protocol to > cover administrative procedures. > > I hope this clarifies my previous comment. apologies if you > thought they > were of a personal nature directed at you. > > personal regards, > > -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EI1GC2006055 for ; Mon, 14 Jan 2002 19:01:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0EI1GsO006054 for ietf-provreg-outgoing; Mon, 14 Jan 2002 19:01:16 +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.1/8.12.1) with ESMTP id g0EI1FC2006048 for ; Mon, 14 Jan 2002 19:01:15 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0EI1EYZ022914; Mon, 14 Jan 2002 10:01:14 -0800 (PST) Date: Mon, 14 Jan 2002 10:01:14 -0800 (PST) From: Rick H Wesson To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" Subject: RE: Command and authInfo In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B55B@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, ok, my comments were not meant as an ad-hominem attack on you, we have known each other a long time and I'm not attacking you personally, but I do have strong opinion on the subject from a long experience with RRP. registries have a contract with registrars and MUST enforce those contracts; we should not be designing defense from datamining into the protocols. registries MUST enforce their contracts and provide appropriate oversite of the registrars. We have recent experience of registrars abusing the common resource of a RRP based registry, just because the Registry does not enforce their contracts does not mean we should design mechanisms into the protocol to cover administrative procedures. I hope this clarifies my previous comment. apologies if you thought they were of a personal nature directed at you. personal regards, -rick On Mon, 14 Jan 2002, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Rick H Wesson [mailto:wessorh@ar.com] > > Sent: Monday, January 14, 2002 12:24 PM > > To: Hollenbeck, Scott > > Cc: 'ietf-provreg@cafax.se' > > Subject: Re: Command and authInfo > > > > > > > > please don't turn this spec into VeriSigns view of a Domain Registry. Up > > till now you have done a good job of engineering but it seems as though > > your employer is creeping into your work. > > Rick, I really object to any insinuation that there's any employer bias > creeping into anything here. My comments on RRP were provided to document > experience with a similar protocol. Data mining is a real issue, and the > current EPP spec has said for a LONG time about the way the info command > should be implemented -- and it's NOT what you suggested ("the status > command should be open to all registrars"). Instead of an ad-hominem > attack, why not address the data mining risk and merit or detriment of the > change proposal? > > -Scott- > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EHY3C2005834 for ; Mon, 14 Jan 2002 18:34:03 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g0EHY3sj005833 for ietf-provreg-outgoing; Mon, 14 Jan 2002 18:34:03 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EHY2C2005828 for ; Mon, 14 Jan 2002 18:34:02 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA03955; Mon, 14 Jan 2002 12:33:56 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 12:30:54 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B55B@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Rick H Wesson'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Command and authInfo Date: Mon, 14 Jan 2002 12:37:31 -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 > -----Original Message----- > From: Rick H Wesson [mailto:wessorh@ar.com] > Sent: Monday, January 14, 2002 12:24 PM > To: Hollenbeck, Scott > Cc: 'ietf-provreg@cafax.se' > Subject: Re: Command and authInfo > > > > please don't turn this spec into VeriSigns view of a Domain Registry. Up > till now you have done a good job of engineering but it seems as though > your employer is creeping into your work. Rick, I really object to any insinuation that there's any employer bias creeping into anything here. My comments on RRP were provided to document experience with a similar protocol. Data mining is a real issue, and the current EPP spec has said for a LONG time about the way the info command should be implemented -- and it's NOT what you suggested ("the status command should be open to all registrars"). Instead of an ad-hominem attack, why not address the data mining risk and merit or detriment of the change proposal? -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EHOVC2005771 for ; Mon, 14 Jan 2002 18:24:31 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0EHOV8E005770 for ietf-provreg-outgoing; Mon, 14 Jan 2002 18:24:31 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (66.123.187.68.ar.com [66.123.187.68] (may be forged)) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EHOSC2005765 for ; Mon, 14 Jan 2002 18:24:28 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0EHOOYZ018770; Mon, 14 Jan 2002 09:24:24 -0800 (PST) Date: Mon, 14 Jan 2002 09:24:24 -0800 (PST) From: Rick H Wesson To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" Subject: Re: Command and authInfo In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B556@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, On Mon, 14 Jan 2002, Hollenbeck, Scott wrote: > Those of you familiar with the NSI RRP, the protocol's STATUS command, and > the way it's been implemented in the com|net|org registry are probably aware > that RRP clients can only do a STATUS command on domains that they've > registered. A client who attempts to get status on a domain registered by a > different client gets an error response. > > The EPP specification is a bit more flexible in this regard, saying this > about the essentially similar command: > > "This action SHOULD be limited to authorized clients; restricting this > action to the sponsoring client is RECOMMENDED." > > VeriSign often gets registrar requests to open up the RRP STATUS command > completely so that any client can obtain information about any registered > domain. The usual argument to support this request relates to transfers: > the potential gaining client wants to be able to see what they're getting in > to before requesting the transfer. Opening the command up completely > introduces a data mining risk, so that's why the EPP text is written as it > is, but without allowing some cross-vision the gaining client has to go to > an out-of-band mechanism (like whois) to obtain info. I think we can do > better with EPP without opening a significant data mining risk. thanks to competition we now understand how usefull it is to preform a INFO command on a domain. > I'm wondering how people feel about adding an optional element to > the domain command. Sponsoring clients wouldn't have to use it; they > can continue to "see" all of the domains they sponsor. Clients who need to > see something in the context of a transfer can provide the to see > domain object info via the protocol, eliminating the need to go out-of-band. > Data mining protections are still in place because non-sponsoring clients > who don't have the can't see domains sponsored by other clients. no. please don't turn this spec into VeriSigns view of a Domain Registry. Up till now you have done a good job of engineering but it seems as though your employer is creeping into your work. Registrars believe that the status command should be open to all registrars even those that use RRP and shoreing up your employers position by altering the command so that your employer can continue to maintain their position is not the kninds of changes I think we need in EPP. > This sort of change would let us tighten up the EPP spec a bit, which should > help with interoperability. I know we finished a WG last call, but I'm in > the docs now working on wrapping up the changes based on last-call comments > and would like to know how folks feel about this change given their > operational experience with RRP. IMHO, we should not support this change, and that VGRS should open up their status command and VGRS should allow the EPP command on domains. This is what Registrars have been asking for since the registry opened, isn't anyone listening? -rick Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EGUPC2005427 for ; Mon, 14 Jan 2002 17:30:25 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0EGUPdN005426 for ietf-provreg-outgoing; Mon, 14 Jan 2002 17:30:25 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0EGUOC2005421 for ; Mon, 14 Jan 2002 17:30:24 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA28859 for ; Mon, 14 Jan 2002 11:30:22 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 11:30:15 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B556@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: Command and authInfo Date: Mon, 14 Jan 2002 11:33:56 -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 Those of you familiar with the NSI RRP, the protocol's STATUS command, and the way it's been implemented in the com|net|org registry are probably aware that RRP clients can only do a STATUS command on domains that they've registered. A client who attempts to get status on a domain registered by a different client gets an error response. The EPP specification is a bit more flexible in this regard, saying this about the essentially similar command: "This action SHOULD be limited to authorized clients; restricting this action to the sponsoring client is RECOMMENDED." VeriSign often gets registrar requests to open up the RRP STATUS command completely so that any client can obtain information about any registered domain. The usual argument to support this request relates to transfers: the potential gaining client wants to be able to see what they're getting in to before requesting the transfer. Opening the command up completely introduces a data mining risk, so that's why the EPP text is written as it is, but without allowing some cross-vision the gaining client has to go to an out-of-band mechanism (like whois) to obtain info. I think we can do better with EPP without opening a significant data mining risk. I'm wondering how people feel about adding an optional element to the domain command. Sponsoring clients wouldn't have to use it; they can continue to "see" all of the domains they sponsor. Clients who need to see something in the context of a transfer can provide the to see domain object info via the protocol, eliminating the need to go out-of-band. Data mining protections are still in place because non-sponsoring clients who don't have the can't see domains sponsored by other clients. This sort of change would let us tighten up the EPP spec a bit, which should help with interoperability. I know we finished a WG last call, but I'm in the docs now working on wrapping up the changes based on last-call comments and would like to know how folks feel about this change given their operational experience with RRP. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0E9W0C2003015 for ; Mon, 14 Jan 2002 10:32:00 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0E9W0im003014 for ietf-provreg-outgoing; Mon, 14 Jan 2002 10:32:00 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from naptop.autonomica.se (naptop.autonomica.se [213.89.0.71]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0E9VxC2003009 for ; Mon, 14 Jan 2002 10:31:59 +0100 (MET) Received: from naptop.autonomica.se (localhost [127.0.0.1]) by naptop.autonomica.se (8.12.1/8.12.0) with ESMTP id g0E9VwVh001596 for ; Mon, 14 Jan 2002 10:31:58 +0100 (MET) Received: by naptop.autonomica.se (8.12.1/8.12.0/Submit) id g0E9VwSU001595 for ietf-provreg@cafax.se; Mon, 14 Jan 2002 10:31:58 +0100 (MET) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BCGmC2018497 for ; Fri, 11 Jan 2002 13:16:48 +0100 (MET) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g0BCGMi10896; Fri, 11 Jan 2002 07:16:22 -0500 (EST) Date: Fri, 11 Jan 2002 07:16:22 -0500 (EST) From: Scott Bradner Message-Id: <200201111216.g0BCGMi10896@newdev.harvard.edu> To: ietf-provreg@cafax.se, lewis@tislabs.com, paf@cisco.com Subject: RE: Requirements Document Update Cc: mankin@isi.edu, ned.freed@mrochek.com, sob@harvard.edu Sender: owner-ietf-provreg@cafax.se Precedence: bulk >I have cc:ed the transport area directors which can correct me if/where I > have been wrong in the explanation above. the explanation is fine > IF you want to also run this protocol on for example UDP, your protocol > would end up being much more complicated. trying to build your own (instead of using TCP or SCTP) could easily add a year or more to the development effort - congestion control protocols are quite hard to get right Scott Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BF0sC2019381 for ; Fri, 11 Jan 2002 16:00:54 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g0BF0sVI019380 for ietf-provreg-outgoing; Fri, 11 Jan 2002 16:00:54 +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-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BF0qC2019375 for ; Fri, 11 Jan 2002 16:00:53 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0B6xJS02579; Thu, 10 Jan 2002 22:59:19 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201110659.g0B6xJS02579@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Scott Bradner cc: ietf-provreg@cafax.se, lewis@tislabs.com, paf@cisco.com, mankin@isi.edu, ned.freed@mrochek.com, brunner@nic-naa.net Subject: Re: Requirements Document Update In-Reply-To: Message from Scott Bradner of "Fri, 11 Jan 2002 07:16:22 EST." <200201111216.g0BCGMi10896@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jan 2002 22:59:19 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott and Allison, Thanks. The UDP problem statement ("avoid") is fine. I was concerned over the only-tcp-or-sctp construction of orthodoxy, since I don't see any reason not to provide a transport mapping for smtp/uucp. I just haven't gotten around to writing it (a-must-do-by-ICANN-Accra). Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BElQC2019277 for ; Fri, 11 Jan 2002 15:47:26 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g0BElQk5019276 for ietf-provreg-outgoing; Fri, 11 Jan 2002 15:47:26 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BElPC2019271 for ; Fri, 11 Jan 2002 15:47:25 +0100 (MET) Received: by sentry.gw.tislabs.com; id JAA00085; Fri, 11 Jan 2002 09:52:19 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma000078; Fri, 11 Jan 02 09:52:09 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200201111314.g0BDE5H06754@minotaur.nge.isi.edu> References: Your message of Thu, 10 Jan 2002 22:02:05 -0800. <330757.1010700125@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Jan 2002 09:47:34 -0500 To: mankin@isi.edu From: Edward Lewis Subject: Re: Requirements Document Update Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Edward Lewis , "'ietf-provreg@cafax.se'" , Allison Mankin , Scott Bradner , Ned Freed Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks to all for the clarifications. Scott submitted a new draft based on the comments received earlier. If we think the clarifications mean a more general edit is needed, we'll have another soon. At 8:14 AM -0500 1/11/02, Allison Mankin wrote: >Patrik, > >I would only add to what you and Scott wrote that: > >> _somewhere_ in the protocol stack there has to be congestion control > >It is not only a large undertaking to put congestion control in >the application itself, but it may greatly distort the application >protocol if it has the requirement to make the network timing >measurements needed for congestion control (taken care of by >using TCP or SCTP). > >We asked for the wording in the provreg document to encourage >provreg not to choose UDP as the transport and then be forced >to provide application congestion control as well. > >Allison > > > >Allison -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BEgdC2019246 for ; Fri, 11 Jan 2002 15:42:39 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g0BEgdNh019245 for ietf-provreg-outgoing; Fri, 11 Jan 2002 15:42:39 +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.1/8.12.1) with ESMTP id g0BEgcC2019240 for ; Fri, 11 Jan 2002 15:42:38 +0100 (MET) Received: (from jaap@localhost) by bartok.sidn.nl (8.11.6/8.11.6) id g0BEgbU78417 for ietf-provreg@cafax.se; Fri, 11 Jan 2002 15:42:37 +0100 (CET) (envelope-from jaap) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BCGmC2018497 for ; Fri, 11 Jan 2002 13:16:48 +0100 (MET) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g0BCGMi10896; Fri, 11 Jan 2002 07:16:22 -0500 (EST) Date: Fri, 11 Jan 2002 07:16:22 -0500 (EST) From: Scott Bradner Message-Id: <200201111216.g0BCGMi10896@newdev.harvard.edu> To: ietf-provreg@cafax.se, lewis@tislabs.com, paf@cisco.com Subject: RE: Requirements Document Update Cc: mankin@isi.edu, ned.freed@mrochek.com, sob@harvard.edu Sender: owner-ietf-provreg@cafax.se Precedence: bulk >I have cc:ed the transport area directors which can correct me if/where I > have been wrong in the explanation above. the explanation is fine > IF you want to also run this protocol on for example UDP, your protocol > would end up being much more complicated. trying to build your own (instead of using TCP or SCTP) could easily add a year or more to the development effort - congestion control protocols are quite hard to get right Scott Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BEgNC2019238 for ; Fri, 11 Jan 2002 15:42:23 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0BEgNKn019237 for ietf-provreg-outgoing; Fri, 11 Jan 2002 15:42:23 +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.1/8.12.1) with ESMTP id g0BEgKC2019232 for ; Fri, 11 Jan 2002 15:42:20 +0100 (MET) Received: (from jaap@localhost) by bartok.sidn.nl (8.11.6/8.11.6) id g0BEgFZ78407 for ietf-provreg@cafax.se; Fri, 11 Jan 2002 15:42:15 +0100 (CET) (envelope-from jaap) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BDEAC2018756 for ; Fri, 11 Jan 2002 14:14:10 +0100 (MET) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g0BDE5H06754; Fri, 11 Jan 2002 08:14:05 -0500 Message-Id: <200201111314.g0BDE5H06754@minotaur.nge.isi.edu> To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= cc: Edward Lewis , "'ietf-provreg@cafax.se'" , Allison Mankin , Scott Bradner , Ned Freed Reply-To: mankin@isi.edu Subject: Re: Requirements Document Update In-reply-to: Your message of Thu, 10 Jan 2002 22:02:05 -0800. <330757.1010700125@localhost> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Fri, 11 Jan 2002 08:14:05 -0500 From: Allison Mankin Sender: owner-ietf-provreg@cafax.se Precedence: bulk Patrik, I would only add to what you and Scott wrote that: > _somewhere_ in the protocol stack there has to be congestion control It is not only a large undertaking to put congestion control in the application itself, but it may greatly distort the application protocol if it has the requirement to make the network timing measurements needed for congestion control (taken care of by using TCP or SCTP). We asked for the wording in the provreg document to encourage provreg not to choose UDP as the transport and then be forced to provide application congestion control as well. Allison Allison Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0BDuvC2018910 for ; Fri, 11 Jan 2002 14:56:57 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g0BDuvdm018909 for ietf-provreg-outgoing; Fri, 11 Jan 2002 14:56:57 +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.1/8.12.1) with ESMTP id g0BDurC2018904 for ; Fri, 11 Jan 2002 14:56:55 +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 IAA14840; Fri, 11 Jan 2002 08:56:49 -0500 (EST) Message-Id: <200201111356.IAA14840@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: I-D ACTION:draft-ietf-provreg-grrp-reqs-04.txt Date: Fri, 11 Jan 2002 08:56:49 -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 : Generic Registry-Registrar Protocol Requirements Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-grrp-reqs-04.txt Pages : 24 Date : 10-Jan-02 This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-04.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-grrp-reqs-04.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-grrp-reqs-04.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: <20020110150659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-grrp-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150659.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0B6NMC2017183 for ; Fri, 11 Jan 2002 07:23:22 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0B6NMfL017182 for ietf-provreg-outgoing; Fri, 11 Jan 2002 07:23:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0B6NKC2017177 for ; Fri, 11 Jan 2002 07:23:20 +0100 (MET) Received: from 208.184.79.252.songbird.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with SMTP id WAA22893; Thu, 10 Jan 2002 22:23:17 -0800 X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol Message-Id: <5.1.0.14.2.20020110221728.03bb6e60@127.0.0.1> X-Sender: dcrocker@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Jan 2002 22:19:25 -0800 To: Bill Manning From: Dave Crocker Subject: Re: Requirements Document Update Cc: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" In-Reply-To: <20020104165040.GA20605@zed.isi.edu> References: <3CD14E451751BD42BA48AAA50B07BAD60189B4F9@vsvapostal3.bkup6> <3CD14E451751BD42BA48AAA50B07BAD60189B4F9@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 08:50 AM 1/4/2002 -0800, Bill Manning wrote: > > "The protocol MUST only be run over IETF approved protocols that feature > > congestion control, such as TCP and SCTP." > > So, the protcol is prohibited from running on non-IESG approved > protocols? How the heck are they going to enforce that? Although the wording is a bit awkward, the requirement is pretty straightforward. Enforcement is by giving or withholding the IETF standards imprimateur. Obviously requirements cannot be enforced behaviorally. You may run any darn thing you choose to run. However violating the above requirements means that what you run will not be an IETF standard. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0B67BC2017138 for ; Fri, 11 Jan 2002 07:07:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0B67B2R017137 for ietf-provreg-outgoing; Fri, 11 Jan 2002 07:07:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0B679C2017132 for ; Fri, 11 Jan 2002 07:07:09 +0100 (MET) Received: from [10.80.103.165] (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA19271; Fri, 11 Jan 2002 07:07:00 +0100 (MET) Date: Thu, 10 Jan 2002 22:02:05 -0800 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Edward Lewis , "'ietf-provreg@cafax.se'" cc: Allison Mankin , Scott Bradner , Ned Freed Subject: RE: Requirements Document Update Message-ID: <330757.1010700125@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On 2002-01-07 10.02 -0500 Edward Lewis wrote: > At 11:48 AM -0500 1/4/02, Hollenbeck, Scott wrote: >> More to the point, I think the intention is to ensure that IETF-specified >> protocol documents don't build on "problematic" transports. Maybe Ed can >> provide more detail based on the exchange he had with Patrik. > > Sorry, I can't. When I asked about the motivation of the new text, I was > told it was to ensure (okay, require) that congestion control was part of > the transport. My guess is that this is some concern that blew through > the IESG in response to some other networking technology, perhaps > telephony related. But I am just guessing. The view in the IESG on new protocols is that _somewhere_ in the protocol stack there has to be congestion control. Either one have to include congestion control in the protocol itself, or one rely on underlying technologies for it. What IESG suggested was to have a requirement that the protocol you are developing must run on a transport that itself have congestion control (like TCP or SCTP), and that way, you don't have to include such things in your protocol. IF you want to also run this protocol on for example UDP, your protocol would end up being much more complicated. I have cc:ed the transport area directors which can correct me if/where I have been wrong in the explanation above. Now, Scott seems to have created a new version, even though I still only see version -03 in the archive. Scott, Ed, can you let me know if you see the new version before me? paf Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0ALlGC2014733 for ; Thu, 10 Jan 2002 22:47:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0ALlG9a014732 for ietf-provreg-outgoing; Thu, 10 Jan 2002 22:47: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-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0ALlEC2014727 for ; Thu, 10 Jan 2002 22:47:15 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0ADk3S00244; Thu, 10 Jan 2002 05:46:03 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201101346.g0ADk3S00244@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Minutes from SLC In-Reply-To: Message from Edward Lewis of "Thu, 10 Jan 2002 13:28:33 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jan 2002 05:46:03 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The WG is open to discussion of . Good. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0ALT4C2014633 for ; Thu, 10 Jan 2002 22:29:04 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0ALT4et014632 for ietf-provreg-outgoing; Thu, 10 Jan 2002 22:29: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-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0ALT2C2014627 for ; Thu, 10 Jan 2002 22:29:03 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g0ADRcS00189; Thu, 10 Jan 2002 05:27:38 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201101327.g0ADRcS00189@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dave Crocker cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Minutes from SLC In-Reply-To: Message from Dave Crocker of "Thu, 10 Jan 2002 10:38:43 PST." <5.1.0.14.2.20020110103626.032e1008@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jan 2002 05:27:38 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dave, The sense of the meeting (London) was that , when removed from the XRP draft (like transport over BEEP), would be a WG draft. When Ed took the question to the WG (the list), there was no consensus to accept a WG draft containing . I'm just fishing for the end of a wait statement, and I didn't see it in the SLC minutes. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AIctC2013746 for ; Thu, 10 Jan 2002 19:38:55 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g0AIctiv013745 for ietf-provreg-outgoing; Thu, 10 Jan 2002 19:38:55 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AIcrC2013740 for ; Thu, 10 Jan 2002 19:38:53 +0100 (MET) Received: from 208.184.79.252.songbird.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with SMTP id KAA31614 for ; Thu, 10 Jan 2002 10:38:52 -0800 X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol Message-Id: <5.1.0.14.2.20020110103626.032e1008@127.0.0.1> X-Sender: dcrocker@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Jan 2002 10:38:43 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: Re: Minutes from SLC In-Reply-To: References: <200201101018.g0AAIFq04686@bullhead.nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk >The WG is open to discussion of . I think that the ground work is >already in place to have this enter as a WG document, given the discussion >to date. In fact, I thought that issue had been disposed of long ago, namely that we had consensus to have push be *official* as an *option*, standardized in a separate document. (or in the appendix of the main document, but that is entirely a matter of convenience.) d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AISkC2013655 for ; Thu, 10 Jan 2002 19:28:46 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g0AISkOH013654 for ietf-provreg-outgoing; Thu, 10 Jan 2002 19:28:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AISjC2013649 for ; Thu, 10 Jan 2002 19:28:45 +0100 (MET) Received: by sentry.gw.tislabs.com; id NAA12415; Thu, 10 Jan 2002 13:33:59 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma012401; Thu, 10 Jan 02 13:33:10 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200201101018.g0AAIFq04686@bullhead.nic-naa.net> References: Your message of "Thu, 10 Jan 2002 12:53:44 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jan 2002 13:28:33 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: Minutes from SLC Cc: Edward Lewis , ietf-provreg@cafax.se, brunner@bullhead.nic-naa.net Sender: owner-ietf-provreg@cafax.se Precedence: bulk The WG is open to discussion of . I think that the ground work is already in place to have this enter as a WG document, given the discussion to date. If there is an issue over "control," I think we should "burn that bridge when we come to it" as an ex-officemate used to say. At 5:18 AM -0500 1/10/02, Eric Brunner-Williams in Portland Maine wrote: >Ed, > >I'm still waiting on the-sense-of-the-wg on the question that came up on >the list post-London: what shall we do with ? > >The choices are: > > - a draft under wg change control, > - a draft outside of the wg > >I'm fine with either approach. > >Eric -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AIJgC2013626 for ; Thu, 10 Jan 2002 19:19:42 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0AIJg5o013625 for ietf-provreg-outgoing; Thu, 10 Jan 2002 19:19:42 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bullhead.nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AIJeC2013620 for ; Thu, 10 Jan 2002 19:19:41 +0100 (MET) Received: from bullhead.nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by bullhead.nic-naa.net (8.11.6/8.11.1) with ESMTP id g0AAIFq04686; Thu, 10 Jan 2002 02:18:15 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201101018.g0AAIFq04686@bullhead.nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, brunner@bullhead.nic-naa.net Subject: Re: Minutes from SLC In-Reply-To: Your message of "Thu, 10 Jan 2002 12:53:44 EST." Date: Thu, 10 Jan 2002 02:18:15 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, I'm still waiting on the-sense-of-the-wg on the question that came up on the list post-London: what shall we do with ? The choices are: - a draft under wg change control, - a draft outside of the wg I'm fine with either approach. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AHrfC2013496 for ; Thu, 10 Jan 2002 18:53:41 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g0AHreVr013495 for ietf-provreg-outgoing; Thu, 10 Jan 2002 18:53:40 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g0AHrdC2013490 for ; Thu, 10 Jan 2002 18:53:39 +0100 (MET) Received: by sentry.gw.tislabs.com; id MAA11812; Thu, 10 Jan 2002 12:58:53 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma011796; Thu, 10 Jan 02 12:58:19 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jan 2002 12:53:44 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Minutes from SLC Sender: owner-ietf-provreg@cafax.se Precedence: bulk Here are the minutes from the meeting last month. I need to turn them in, with Jim Gould's slides real soon, so let me know quickly if there are any edits you want to see. =========== Buchanan appointed as the scribe. Ed Lewis: Document status: Definitions dropped. Requirements in front of the IESG. Last call: EPP base; host, domain, and contact info mapping; and EPP over TCP. Two other documents: Containers and BEEP. Will address later. What will happen over the next couple of months? Last call was just concluded. A few comments on last call items: Scott Hollenbeck: * Slight issue with the way XML schema deals with choices. Right now could say that you want to use the same things more than once. Tradeoff between getting multiple repeated elements or an empty ("none"). * Modification to domain mapping so that could delegate to name server which is not a host object. * Last issue: want representation in more UTF-8-ful registration format. Eric's suggestion-why do you need both? We could just take whatever we get. Requirement in requirements draft. Redundancy and extra elements; get rid of Jordyn Buchanan: * The reason we added the non-registered objects as name servers was to solve the out-of-zone hosts? Hollenbeck: Yes Buchanan: I would prefer another solution to that problem if one is available. Daniel Manley: What does the new schema gain us if the first address is still ASCII? Hollenbeck: Gets rid of some elements, just have a variable number of address elements. Sheer El-Showk: Wasn't there a way to have per-registrar views of out-of zone objects. That seems like it might solve the problem. Wesson: Also, there's a difference between objects and records in the document. --- Lewis: Will do presentations on implementations now. First, Jim Gould. Jim Gould: presentation (will be attached when sent to secretariate) Rick: Was registry thick or thin? Gould: We've done both. : Did -04 release. Toolkit supports Java/C++, been out since summer. Have been playing with extensions, but not released. Have 100 registrars certified on EPP-04; looking at -05 and beyond. Wesson: Registrars noticed issues with lengths. Can you discuss: : As lengths changed, been very difficult to keep up. From an operational perspective, would be nice to get consistent. Haven't had to truncate because have been growing. Hollenbeck: Speaking of length, one last call issue was an increase of postal address from 64 to 255 characters. Lewis: Now Sheer El-Showk's presentation. El-Showk: We did both registry and registrar implementations. I'm not talking about the protocol itself. A few small points. Contact name field is only a single field, versus two (first, last) in Whois. Makes for a difficult mapping. Name/organization; name is a required field, whereas organization is not. Response codes should be more informative; not sure extension mechanism would be appropriate. New statuses may be required. Business logic for statuses horrendous to implement; a significant part of the business logic. XML very expensive for check commands. Lots of overhead that is not necessary; because form data is identical, makes it easier to do cryptanalysis. Not clear how to implement an error condition on a single check. Manley: Discussion of change in semantics of check command, adding additional returned data. El-Showk: I don't like the idea of making it more complicated, should the whole check fail if 1 out of 1000 returns an error. Gould: I would assume that if one fails. Buchanan: Scenarios may exist in which one out of many could fail exist. Gould: Then just fail the whole thing if your server logic can't figure out what to do. Wesson: There's no provision anywhere saying Whois has to say firstname/lastname, so that's not a big deal. El-Showk: I also mentioned retry commands. Relying on commands versus transaction ID means that it may make it more difficult in the future. Why not client/server ID? Hollenbeck: Idempotency is a property. By it's definition, it's the structure of the command. Take away or adding properties could hurt it. El-Showk: It's in mappings, not base protocol? Hollenbeck: Yes. El-Showk: Wouldn't it be useful in the base protocol? A unique client trans ID could allow. Hollenbeck: We said the server wouldn't necessarily track; it's not a requirement. El-Showk: In our implementation I did. Lewis: Now Dan Manley. Manley: A couple of comments; we used an early version of EPP, so many comments are now out of date. From a registrar perspective, transfers aren't handled very well in batch. May want to transfer hundreds or thousands of names. Easy to assimilate in RRP. In EPP, it's more difficult because each object could have different auth_info. Couldn't guarantee that the same domains had the same auth_info. If there was a way to group, that would be good. Other issue is contacts, and contact objects. They are cool, but even more difficult to transfer; might have to transfer many contacts. Transfer a subset of the profile. Containers could solve; extend domain transfer command to take all contacts with it. Hollenbeck: Here's a scenario-I have a domain object with a specified registrant, and a tech contact that belongs to an ISP. Should the domain transfer take the tech contact with it? Manley: True. Hard to solve. Wesson: Might be appropriate to write a document on BCP from registry/registrar perspective. Would be really good. Manley: I'll try to put my notes into a document. Gould: When you start selling other things than domains, they have to be completely decoupled. Might break other product associations. Dan: This might move onto container discussions. Buchanan: Could transfer contacts instantaneously and then act on them, since the contact has the authorization built in and generally no billing implications. El-Showk: But then your domain and contacts could be out of sync. Buchanan: I'm talking about situations when domain has already been transferred and domain has been left behind. Lewis: Should we be trying to send these documents up this month? Wesson: I would encourage the group to move the documents forward. Many of the comments have been issues dealing with tracking the protocol as opposed to actual implementation issues. Lewis: For implementations out there, over time we want to do some interoperability testing. That is the real test. Two documents still being working on. Two promised: EPP over mail; EPP push. Also some murmur of new issues. Could start considering because base has been worked well. Don't want to. Will update milestones; only one left is about to be accomplished. --- Anyone have comments on containers? Manley: Containers, at first and second glance, provide a lot of good functionality. For registrars, could help with transfers-able to transfer an entire profile in a single command. Could be scary on the server side. Billing? Objects could be in various states. Makes it easy to change and do mass changes. I had some questions that were not all answered. Tom McGarry: We'll volunteer to do push. Re: containers. Not implemented yet. What are options other than standardize? Lewis: Experimental versus standards track. McGarry: Customers like the idea. Wesson: Not convinced that transfers and containers aren't a big security issue. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07MeLC2024175 for ; Mon, 7 Jan 2002 23:40:21 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g07MeLXs024174 for ietf-provreg-outgoing; Mon, 7 Jan 2002 23:40:21 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from tomts17-srv.bellnexxia.net (tomts17-srv.bellnexxia.net [209.226.175.71]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07MeJC2024167 for ; Mon, 7 Jan 2002 23:40:20 +0100 (MET) Received: from deltaflyer ([199.243.128.145]) by tomts17-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20020107224017.TUIY16289.tomts17-srv.bellnexxia.net@deltaflyer> for ; Mon, 7 Jan 2002 17:40:17 -0500 From: "James Woods" To: Subject: RE: Open Source Server Implementation Date: Mon, 7 Jan 2002 17:39:23 -0500 Message-ID: <003f01c197cc$279b3450$6501a8c0@deltaflyer> 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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B509@vsvapostal3.bkup6> Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Scott, We have two EPP implementation services that we plan to launch soon, (the openess is under debate right now but I think I'll win this one ;) one is a modified client (ala GUI) called CuteEPP the other EPPserv. Regardless of whether these get "opened" or not our dev team would love to hook up with others wishing to do so. I can be reached by : jwoods@netstormmedia.com Cheers, James Woods -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Hollenbeck, Scott Sent: January 7, 2002 8:57 AM To: 'ietf-provreg@cafax.se' Subject: Open Source Server Implementation Is anyone aware of any efforts towards developing an open source EPP server? I have implementers who are able and willing to contribute to a collaborative effort, including contributing some of the code we've developed. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07F5TC2021944 for ; Mon, 7 Jan 2002 16:05:29 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g07F5TtF021943 for ietf-provreg-outgoing; Mon, 7 Jan 2002 16:05:29 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07F5RC2021937 for ; Mon, 7 Jan 2002 16:05:28 +0100 (MET) Received: by sentry.gw.tislabs.com; id KAA16013; Mon, 7 Jan 2002 10:10:41 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xmaa15996; Mon, 7 Jan 02 10:09:45 -0500 X-Sender: lewis@pop.tislabs.com Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B4FD@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Jan 2002 10:02:33 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: RE: Requirements Document Update Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:48 AM -0500 1/4/02, Hollenbeck, Scott wrote: >More to the point, I think the intention is to ensure that IETF-specified >protocol documents don't build on "problematic" transports. Maybe Ed can >provide more detail based on the exchange he had with Patrik. Sorry, I can't. When I asked about the motivation of the new text, I was told it was to ensure (okay, require) that congestion control was part of the transport. My guess is that this is some concern that blew through the IESG in response to some other networking technology, perhaps telephony related. But I am just guessing. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07E6KC2020927 for ; Mon, 7 Jan 2002 15:06:20 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g07E6K61020926 for ietf-provreg-outgoing; Mon, 7 Jan 2002 15:06:20 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07E6IC2020921 for ; Mon, 7 Jan 2002 15:06:18 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA20074 for ; Mon, 7 Jan 2002 09:06:13 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 09:06:29 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B509@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: Open Source Server Implementation Date: Mon, 7 Jan 2002 08:56:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Is anyone aware of any efforts towards developing an open source EPP server? I have implementers who are able and willing to contribute to a collaborative effort, including contributing some of the code we've developed. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07DFxC2020762 for ; Mon, 7 Jan 2002 14:15:59 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g07DFxD1020761 for ietf-provreg-outgoing; Mon, 7 Jan 2002 14:15:59 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from isi.edu (zed.isi.edu [128.9.160.57]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g07DFvC2020756 for ; Mon, 7 Jan 2002 14:15:58 +0100 (MET) Received: (from bmanning@localhost) by isi.edu (8.11.6/8.11.1) id g07DFp302228; Mon, 7 Jan 2002 05:15:51 -0800 (PST) (envelope-from bmanning) Date: Mon, 7 Jan 2002 05:15:51 -0800 From: Bill Manning To: Eric Brunner-Williams in Portland Maine Cc: Bill Manning , "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@bullhead.nic-naa.net Subject: Re: Requirements Document Update Message-ID: <20020107131551.GA850@zed.isi.edu> References: <20020104165040.GA20605@zed.isi.edu> <200201061242.g06Cgiu39533@bullhead.nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201061242.g06Cgiu39533@bullhead.nic-naa.net> User-Agent: Mutt/1.3.25i Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Sun, Jan 06, 2002 at 04:42:44AM -0800, Eric Brunner-Williams in Portland Maine wrote: > bill, > > nice catch. > this is boardering on goofy. Don't get me started. > i think this is the first time i've seen the congestion control on this list. > this means it is way out in left field. Nah, its just that I change hw frequently and the MUA is not always up to par. > if someone finnished doing a transport mapping for smtp, and decided to > write yet-another-mapping, for uucp (hint to self), the users would be as > concerned with the ietf as ... any users of uucp. Ah, but then it would be in violation of the spec! > > (still using uucp) > eric > wampumpeag, llc Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g06LMFC2017259 for ; Sun, 6 Jan 2002 22:22:15 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g06LMFEM017258 for ietf-provreg-outgoing; Sun, 6 Jan 2002 22:22:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from naptop.autonomica.se (as5-4-6.spa.s.bonet.se [217.215.75.155]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g06LMEC2017253 for ; Sun, 6 Jan 2002 22:22:14 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by naptop.autonomica.se (8.12.1/8.12.0) with ESMTP id g06LLSOD002242; Sun, 6 Jan 2002 22:21:28 +0100 (MET) Date: Sun, 06 Jan 2002 22:21:28 +0100 (MET) Message-Id: <20020106.222128.36853935.liman@autonomica.se> To: brunner@nic-naa.net Cc: bmanning@zed.isi.edu, shollenbeck@verisign.com, ietf-provreg@cafax.se, brunner@bullhead.nic-naa.net Subject: Re: Requirements Document Update From: Lars-Johan Liman In-Reply-To: <200201061242.g06Cgiu39533@bullhead.nic-naa.net> References: <200201061242.g06Cgiu39533@bullhead.nic-naa.net> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk brunner@nic-naa.net: > i think this is the first time i've seen the congestion control on > this list. this means it is way out in left field. > if someone finnished doing a transport mapping for smtp, and decided > to write yet-another-mapping, for uucp (hint to self), the users > would be as concerned with the ietf as ... any users of uucp. It's just me on Christmas holiday. :-) This list is "subscribers only" in the sense that Majordummy implements it. Messages with "From:" matching any subscribed address or one of the "golden VIP" addresses (like the IETF secretariat, the area directors, me, other usual suspects ... ;-) are forwarded immediately. If it doesn't match, it's sent to the moderators (Ed, Jaap and me) for manual approval (or dismissal if it's pure spam). Bill sent the message from a different address than the one he's subscribed with, so it was caught in the moderators' filter waiting for manual approval, which was done when I just happend to take a peek in my mailbox, even though I'm on vacation. (Seems like Ed and Jaap are too. ;-). This slows down a few messages, but believe me, there's a fair amount of spam out there that _doesn't_ hit you thanks to this. So, if you want speedy transport, make sure you use the right sender address. I'm of course quite willing to change the policy if there are strong voices for it. Cheers, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman ! E-mail: liman@autonomica.se # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #---------------------------------------------------------------------- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g06KiZC2017081 for ; Sun, 6 Jan 2002 21:44:35 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g06KiZ8X017080 for ietf-provreg-outgoing; Sun, 6 Jan 2002 21:44:35 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bullhead.nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g06KiXC2017075 for ; Sun, 6 Jan 2002 21:44:34 +0100 (MET) Received: from bullhead.nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by bullhead.nic-naa.net (8.11.6/8.11.1) with ESMTP id g06Cgiu39533; Sun, 6 Jan 2002 04:42:44 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200201061242.g06Cgiu39533@bullhead.nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Bill Manning cc: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" , brunner@bullhead.nic-naa.net Subject: Re: Requirements Document Update In-Reply-To: Message from Bill Manning of "Fri, 04 Jan 2002 08:50:40 PST." <20020104165040.GA20605@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jan 2002 04:42:44 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk bill, nice catch. this is boardering on goofy. i think this is the first time i've seen the congestion control on this list. this means it is way out in left field. if someone finnished doing a transport mapping for smtp, and decided to write yet-another-mapping, for uucp (hint to self), the users would be as concerned with the ietf as ... any users of uucp. (still using uucp) eric wampumpeag, llc Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g06KCvC2016909 for ; Sun, 6 Jan 2002 21:12:57 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g06KCv79016908 for ietf-provreg-outgoing; Sun, 6 Jan 2002 21:12:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from naptop.autonomica.se (as5-4-6.spa.s.bonet.se [217.215.75.155]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g06KCtC2016903 for ; Sun, 6 Jan 2002 21:12:55 +0100 (MET) Received: from naptop.autonomica.se (localhost [127.0.0.1]) by naptop.autonomica.se (8.12.1/8.12.0) with ESMTP id g06KCAOD002035 for ; Sun, 6 Jan 2002 21:12:10 +0100 (MET) Received: by naptop.autonomica.se (8.12.1/8.12.0/Submit) id g06KCAc6002034 for ietf-provreg@cafax.se; Sun, 6 Jan 2002 21:12:10 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g04GoiC2007483 for ; Fri, 4 Jan 2002 17:50:44 +0100 (MET) Received: (from bmanning@localhost) by zed.isi.edu (8.11.6/8.11.1) id g04GoeQ20755; Fri, 4 Jan 2002 08:50:40 -0800 (PST) (envelope-from bmanning) Date: Fri, 4 Jan 2002 08:50:40 -0800 From: Bill Manning To: "Hollenbeck, Scott" Cc: "'ietf-provreg@cafax.se'" Subject: Re: Requirements Document Update Message-ID: <20020104165040.GA20605@zed.isi.edu> References: <3CD14E451751BD42BA48AAA50B07BAD60189B4F9@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B4F9@vsvapostal3.bkup6> User-Agent: Mutt/1.3.25i Sender: owner-ietf-provreg@cafax.se Precedence: bulk > ago. Here's a summary of the changes: > > 1. Changed the last sentence in section 4.4. > "The protocol SHOULD be serviceable over multiple standard communications > protocols." > > was changed to > > "The protocol MUST only be run over IETF approved protocols that feature > congestion control, such as TCP and SCTP." > > -Scott- So, the protcol is prohibited from running on non-IESG approved protocols? How the heck are they going to enforce that? --bill Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g04GwKC2007519 for ; Fri, 4 Jan 2002 17:58:20 +0100 (MET) Received: by nic.cafax.se (8.12.1/8.12.1/Submit) id g04GwKnJ007518 for ietf-provreg-outgoing; Fri, 4 Jan 2002 17:58:20 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g04GwJC2007513 for ; Fri, 4 Jan 2002 17:58:19 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA08574; Fri, 4 Jan 2002 11:57:47 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 11:58:07 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B4FD@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Bill Manning'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Requirements Document Update Date: Fri, 4 Jan 2002 11:48:21 -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 > -----Original Message----- > From: Bill Manning [mailto:bmanning@zed.isi.edu] > Sent: Friday, January 04, 2002 11:51 AM > To: Hollenbeck, Scott > Cc: 'ietf-provreg@cafax.se' > Subject: Re: Requirements Document Update > > > So, the protcol is prohibited from running on non-IESG approved > protocols? How the heck are they going to enforce that? Sounds like a job for the protocol police.... ;-) More to the point, I think the intention is to ensure that IETF-specified protocol documents don't build on "problematic" transports. Maybe Ed can provide more detail based on the exchange he had with Patrik. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g04E16C2006721 for ; Fri, 4 Jan 2002 15:01:06 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.1/8.12.1/Submit) id g04E16Ym006720 for ietf-provreg-outgoing; Fri, 4 Jan 2002 15:01:06 +0100 (MET) 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.233.95]) by nic.cafax.se (8.12.1/8.12.1) with ESMTP id g04E14C2006715 for ; Fri, 4 Jan 2002 15:01:05 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA27604 for ; Fri, 4 Jan 2002 09:01:03 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 09:01:23 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B4F9@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: Requirements Document Update Date: Fri, 4 Jan 2002 08:51:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Earlier this week Ed Lewis received some additional comments from the IESG directed at draft-ietf-provreg-grrp-reqs-03.txt. I've made the requested changes, and sent an updated document to the I-D administrator a few moments ago. Here's a summary of the changes: 1. Changed the last sentence in section 4.4. "The protocol SHOULD be serviceable over multiple standard communications protocols." was changed to "The protocol MUST only be run over IETF approved protocols that feature congestion control, such as TCP and SCTP." 2. More fixes to "may", "must", and "should". Lower-case variants of these words were changed to alternate terms to avoid confusion with directives described in RFC 2119. 3. Updated the "Acknowledgements" section. I went through the list archives and collected the names of everyone who provided commentary on the document. This wasn't an IESG comment, but I took the opportunity to get it done. 4. Separated references into normative and informative subsections. The IESG apparently wants this sort of separation to help make normative reference dependencies more clear. -Scott-