From owner-ietf-whois Tue Jan 16 18:20:07 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA09320 for ietf-whois-bks; Tue, 16 Jan 2001 18:20:07 -0800 (PST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09316 for ; Tue, 16 Jan 2001 18:20:06 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 16 Jan 2001 18:24:17 -0800 To: ietf-whois@imc.org From: Paul Hoffman / IMC Subject: Minutes from San Diego Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Welcome to the new list. Mark Kosters took the minutes in San Diego, which I have posted on the web site at . This should help get the discussion started. :-) --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-whois Wed Jan 17 07:18:29 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA09145 for ietf-whois-bks; Wed, 17 Jan 2001 07:18:29 -0800 (PST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09137; Wed, 17 Jan 2001 07:18:28 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14IuRR-000Ghf-00; Wed, 17 Jan 2001 07:24:05 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Hoffman / IMC Cc: ietf-whois@imc.org Subject: Re: Minutes from San Diego References: Message-Id: Date: Wed, 17 Jan 2001 07:24:05 -0800 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: i could not even get into the room. the minutes say whois users RIRs, routing registries, domain registries, registrars #1 and #2 are close #3 is a bit different actually, the whois port/protocol is used by all sorts of strange and arcane uses by all sorts of folk. imiho, we do not have the prerogative to break their uses by a change to the base whois/43 protocol. this is not to say that some group of applications of the whois protocol could not agree to use it in a common way, essentially forming an overlay protocol. randy From owner-ietf-whois Wed Jan 17 08:51:26 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17083 for ietf-whois-bks; Wed, 17 Jan 2001 08:51:26 -0800 (PST) Received: from h236.s254.netsol.com (h236.s254.netsol.com [216.168.254.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17077; Wed, 17 Jan 2001 08:51:25 -0800 (PST) Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f0HGoMQ01544; Wed, 17 Jan 2001 11:50:22 -0500 (EST) Date: Wed, 17 Jan 2001 11:50:17 -0500 From: Mark Kosters To: Randy Bush Cc: Paul Hoffman / IMC , ietf-whois@imc.org Subject: Re: Minutes from San Diego Message-ID: <20010117115017.D1204@slam.admin.cto.netsol.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from randy@psg.com on Wed, Jan 17, 2001 at 07:24:05AM -0800 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jan 17, 2001 at 07:24:05AM -0800, Randy Bush wrote: > actually, the whois port/protocol is used by all sorts of strange and arcane > uses by all sorts of folk. imiho, we do not have the prerogative to break > their uses by a change to the base whois/43 protocol. I agree. For anything other than -> response -> close connection, we have to move on. > this is not to say that some group of applications of the whois protocol > could not agree to use it in a common way, essentially forming an overlay > protocol. RWhois tried to do that with the intention of the client defaulting to a whois style query if no banner initially was received from the server with perhaps some uniform result. The big question is we "patch" whois to do navigation uniformly or do we start creating a new protocol that deals with internationization, access control, query syntax, schema identication, and navigation. If we create a new protocol, I think it would be prudent if ICANN publish requirements that this new service should provide before we go into protocol design. Many of the highly visible whois services are beholden to ICANN regulations and it would be good if we had a protocol that matched ICANN requirements. Mark -- Mark Kosters markk@netsol.com Verisign Applied Research PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 From owner-ietf-whois Wed Jan 17 09:39:36 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19243 for ietf-whois-bks; Wed, 17 Jan 2001 09:39:36 -0800 (PST) Received: from Salicet.ucd.ie (mail.ucd.ie [137.43.1.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19235 for ; Wed, 17 Jan 2001 09:39:34 -0800 (PST) Received: from CONVERSION-DAEMON.Salicet.ucd.ie by Salicet.ucd.ie (PMDF V6.0-24 #36961) id <0G7B00O01HETK5@Salicet.ucd.ie> for ietf-whois@imc.org; Wed, 17 Jan 2001 17:38:31 +0000 (GMT) Received: from fente.ucd.ie ([137.43.2.29]) by Salicet.ucd.ie (PMDF V6.0-24 #36961) with ESMTP id <0G7B00BL2GV0L5@Salicet.ucd.ie>; Wed, 17 Jan 2001 17:06:36 +0000 (GMT) Date: Wed, 17 Jan 2001 17:06:34 +0000 From: "Niall O'Reilly" Subject: Re: Minutes from San Diego In-reply-to: X-Sender: noreilly@pop3.ucd.ie To: Randy Bush Cc: ietf-whois@imc.org Message-id: <5.0.2.1.0.20010117170508.00ac9650@pop3.ucd.ie> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii; format=flowed References: Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Absolutely, IMNSHO; on both points. At 07:24 17/01/01 -0800, Randy Bush wrote: >actually, the whois port/protocol is used by all sorts of strange and arcane >uses by all sorts of folk. imiho, we do not have the prerogative to break >their uses by a change to the base whois/43 protocol. > >this is not to say that some group of applications of the whois protocol >could not agree to use it in a common way, essentially forming an overlay >protocol. From owner-ietf-whois Thu Jan 18 02:04:19 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA19670 for ietf-whois-bks; Thu, 18 Jan 2001 02:04:19 -0800 (PST) Received: from bureau.sidn.nl (bureau.domeinnaam-jurisprudentie.nl [193.176.144.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA19662; Thu, 18 Jan 2001 02:04:15 -0800 (PST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA87914; Thu, 18 Jan 2001 11:09:56 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA38875; Thu, 18 Jan 2001 11:09:55 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101181009.LAA38875@bartok.sidn.nl> To: Mark Kosters cc: Randy Bush , Paul Hoffman / IMC , ietf-whois@imc.org Subject: Re: Minutes from San Diego In-reply-to: Your message of Wed, 17 Jan 2001 11:50:17 -0500. <20010117115017.D1204@slam.admin.cto.netsol.com> Date: Thu, 18 Jan 2001 11:09:55 +0100 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think it would be prudent if ICANN publish requirements that this new service should provide before we go into protocol design. Many of the highly visible whois services are beholden to ICANN regulations and it would be good if we had a protocol that matched ICANN requirements. As far as I remember (but I need to dig in the archives), for whois service for domainnames, ICANN refers to the famous WIPO report, which says something that whois should provide contact information for domain name holders in case of conflicts. Of course, for IP-## whois, for RIPE, ARIN and friends, the case requirements are different. jaap From owner-ietf-whois Thu Jan 18 15:18:53 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13899 for ietf-whois-bks; Thu, 18 Jan 2001 15:18:53 -0800 (PST) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13893; Thu, 18 Jan 2001 15:18:51 -0800 (PST) Received: from nat2.tucows.com ([207.136.98.12] helo=rraderlap) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 14JOOz-00089t-00; Thu, 18 Jan 2001 18:23:33 -0500 Reply-To: From: "Ross Wm. Rader" To: "Randy Bush" , "Paul Hoffman / IMC" Cc: Subject: RE: Minutes from San Diego Date: Thu, 18 Jan 2001 18:24:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Having given this some thought, it sounds like we need two things here (maybe three)... 1) An ICANN Registrar Whois "data presentation" best practices document 1a) a larger discussion concerning the merits and practicality of extending this best practices to other related portions of the 'net (ie ccTLD whois etc)... 2) A discussion concerning the merits of and the possible need for a different and new protocol v. using the old protocol I'd be happy to kick in on the drafting of 1 if it is deemed worthwhile. As far as the other two points go, I've come to the conclusion that this effort is being driven by the well-intentioned, but misplaced belief that whois:43 is only used for domain related purposes. The commonly held belief is that it is easy to standardize the data presentation and output and modify the protocol. Obviously, this is not true. I'm pretty sure that we can satisfy the needs of the well-intentioned through a carefully constructed best practices document and kill an urban myth at the same time... -rwr < -----Original Message----- < From: owner-db-wg@ripe.net [mailto:owner-db-wg@ripe.net]On Behalf Of < Randy Bush < Sent: Wednesday, January 17, 2001 10:24 AM < To: Paul Hoffman / IMC < Cc: ietf-whois@imc.org < Subject: Re: Minutes from San Diego < < < i could not even get into the room. the minutes say < < whois users RIRs, routing registries, domain registries, registrars < #1 and #2 are close #3 is a bit different < < actually, the whois port/protocol is used by all sorts of < strange and arcane < uses by all sorts of folk. imiho, we do not have the < prerogative to break < their uses by a change to the base whois/43 protocol. < < this is not to say that some group of applications of the whois protocol < could not agree to use it in a common way, essentially forming an overlay < protocol. < < randy From owner-ietf-whois Fri Jan 19 02:26:15 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA28487 for ietf-whois-bks; Fri, 19 Jan 2001 02:26:15 -0800 (PST) Received: from bureau.sidn.nl (bureau.domeinnaam-jurisprudentie.nl [193.176.144.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28474; Fri, 19 Jan 2001 02:26:12 -0800 (PST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA93903; Fri, 19 Jan 2001 11:31:58 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA43730; Fri, 19 Jan 2001 11:31:57 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101191031.LAA43730@bartok.sidn.nl> To: ross@tucows.com cc: "Randy Bush" , "Paul Hoffman / IMC" , ietf-whois@imc.org Subject: Re: Minutes from San Diego In-reply-to: Your message of Thu, 18 Jan 2001 18:24:14 -0500. Date: Fri, 19 Jan 2001 11:31:57 +0100 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've come to the conclusion that this effort is being driven by the well-intentioned, but misplaced belief that whois:43 is only used for domain related purposes. Well, the discussion seems to circle around domain names, but that was certainly not the intention. At the BOF was also discussion about the use RIPE and friend make voor IP delegations, AS info etc. I guess that the letter part is less visible for the public, only network operators care about this. Maybe that's why the discussion is dominated by the ``name'' crowd and not the ``number'' crowd. jaap From owner-ietf-whois Fri Jan 19 03:01:19 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00220 for ietf-whois-bks; Fri, 19 Jan 2001 03:01:19 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00215 for ; Fri, 19 Jan 2001 03:01:17 -0800 (PST) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id MAA19963; Fri, 19 Jan 2001 12:06:03 +0100 (CET) Date: Fri, 19 Jan 2001 12:06:02 +0100 (CET) From: Shane Kerr To: Jaap Akkerhuis cc: ietf-whois@imc.org Subject: Re: Minutes from San Diego In-Reply-To: <200101191031.LAA43730@bartok.sidn.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 19 Jan 2001, Jaap Akkerhuis wrote: > > I've come to the conclusion that this effort > is being driven by the well-intentioned, but misplaced belief > that whois:43 is only used for domain related purposes. > > Well, the discussion seems to circle around domain names, but that > was certainly not the intention. At the BOF was also discussion > about the use RIPE and friend make voor IP delegations, AS info > etc. > > I guess that the letter part is less visible for the public, only > network operators care about this. Maybe that's why the discussion > is dominated by the ``name'' crowd and not the ``number'' crowd. I think the fact that there are only three RIR in operation today, and only two query/response formats, means that there's really not a big need for a more sophisticated Whois protocol for RIR managed data. But I guess you can use Whois for domain names too. :) I wonder what kind of query load the various Whois servers get. From the RIPE statistics page: http://www.ripe.net/ripencc/pub-services/db/mrtg/noofqueries/noofqueries.html You can see we get between 400 and 500 queries per minute, around 7 or 8 queries/second (or as I like to say, 7 or 8 Hz). >From the ARIN VI engineering status report they report over 13 queries/sec in September 2000. Can anyone running a domain Whois server report some load statistics here? I know a lot of queries from both ARIN and RIPE are people doing data mining, and I suspect that this is true for all other Whois registries as well. We may want to split any work on new and improved data distribution techniques into looking at ways for both single and aggregate lookups. As a side note on LDAP, Microsoft reports the following: "The specific load that a single LDAP server can manage will depend on several factors, including computer hardware (CPU, RAM, disk speed), resource contention with other processes on the computer, network, client application behavior and load, and underlying database performance. You can expect to get approximately 150 lookups/second, 75 modifications/second, and 20 inserts/second on a P200 with 500 MB of RAM going to a well-tuned, off-box SQL Server 6.5 computer on similar hardware and a Membership Directory of approximately 500,000 objects." That was from: http://www.microsoft.com/technet/Sitesrv/Technote/memdirct.asp I'm not (necessarily) an LDAP fan, but what this means to me is that for number registries at least, LDAP can probably meet the needs for information distribution technically. And to think, we're just about to roll out a new Whois server! :) Shane From owner-ietf-whois Fri Jan 19 03:27:36 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05386 for ietf-whois-bks; Fri, 19 Jan 2001 03:27:36 -0800 (PST) Received: from bureau.sidn.nl (bureau.domeinnaam-jurisprudentie.nl [193.176.144.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05382 for ; Fri, 19 Jan 2001 03:27:34 -0800 (PST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id MAA94248; Fri, 19 Jan 2001 12:33:20 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id MAA44146; Fri, 19 Jan 2001 12:33:20 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101191133.MAA44146@bartok.sidn.nl> To: Shane Kerr cc: ietf-whois@imc.org Subject: Re: Minutes from San Diego In-reply-to: Your message of Fri, 19 Jan 2001 12:06:02 +0100. Date: Fri, 19 Jan 2001 12:33:20 +0100 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Shane, Can anyone running a domain Whois server report some load statistics here? No problem. For .nl we don't have these nice mrtg graphs but do have some figures. It is about 75000 a day, so doing the math, you'll get less then 1 Hz average. But given that most lookups are during working days, 3 Hz might do as well. I don;t have enough datapoints on the moment. I know a lot of queries from both ARIN and RIPE are people doing data mining, and I suspect that this is true for all other Whois registries as well. We don't like datamining on our whois server. It could get us in conflict with the dutch privacy regulations. It is actually something that RIPE should probably think about as well. I've heard that some privacy advocates in the EU don't like any whois service at all. (Microsoft numbers) "... You can expect to get approximately 150 lookups/second, 75 modifications/second, and 20 inserts/second on a P200 with 500 MB of RAM going to a well-tuned, off-box SQL Server 6.5 computer on similar hardware and a Membership Directory of approximately 500,000 objects." I assume that these operations are not concurrenlty. Another datapoint. We do have more then 500K objects. jaap From owner-ietf-whois Fri Jan 19 04:01:25 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA07508 for ietf-whois-bks; Fri, 19 Jan 2001 04:01:25 -0800 (PST) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07502 for ; Fri, 19 Jan 2001 04:01:24 -0800 (PST) To: Shane Kerr Cc: ietf-whois@imc.org, jaap@sidn.nl Subject: Re: Re: Minutes from San Diego X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: From: "Sabine Dolderer/Denic" Date: Fri, 19 Jan 2001 13:06:34 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 19.01.2001 13:07:08, Serialize complete at 19.01.2001 13:07:08 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA07504 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Shane, On 19.01.01 12:06 Shane Kerr wrote: > > On Fri, 19 Jan 2001, Jaap Akkerhuis wrote: > > > > > I've come to the conclusion that this effort > > is being driven by the well-intentioned, but misplaced belief > > that whois:43 is only used for domain related purposes. > > > > Well, the discussion seems to circle around domain names, but that > > was certainly not the intention. At the BOF was also discussion > > about the use RIPE and friend make voor IP delegations, AS info > > etc. > > > > I guess that the letter part is less visible for the public, only > > network operators care about this. Maybe that's why the discussion > > is dominated by the ``name'' crowd and not the ``number'' crowd. > > I think the fact that there are only three RIR in operation today, and > only two query/response formats, means that there's really not a big > need for a more sophisticated Whois protocol for RIR managed data. > > But I guess you can use Whois for domain names too. :) > > I wonder what kind of query load the various Whois servers get. From > the RIPE statistics page: > > http://www.ripe.net/ripencc/pub-services/db/mrtg/noofqueries/noofqueries.html > > You can see we get between 400 and 500 queries per minute, around 7 or 8 > queries/second (or as I like to say, 7 or 8 Hz). > > From the ARIN VI engineering status report they report over 13 > queries/sec in September 2000. > > Can anyone running a domain Whois server report some load statistics > here? we have currently an avarage of 140 q/min and up to 400 max. That means we have an avarage of 2 - 6 Hz, Regards Sabine > > I know a lot of queries from both ARIN and RIPE are people doing data > mining, and I suspect that this is true for all other Whois registries > as well. We may want to split any work on new and improved data > distribution techniques into looking at ways for both single and > aggregate lookups. > > As a side note on LDAP, Microsoft reports the following: > > "The specific load that a single LDAP server can manage will depend on > several factors, including computer hardware (CPU, RAM, disk speed), > resource contention with other processes on the computer, network, > client application behavior and load, and underlying database > performance. You can expect to get approximately 150 lookups/second, 75 > modifications/second, and 20 inserts/second on a P200 with 500 MB of RAM > going to a well-tuned, off-box SQL Server 6.5 computer on similar > hardware and a Membership Directory of approximately 500,000 objects." > > That was from: > > http://www.microsoft.com/technet/Sitesrv/Technote/memdirct.asp > > I'm not (necessarily) an LDAP fan, but what this means to me is that for > number registries at least, LDAP can probably meet the needs for > information distribution technically. > > And to think, we're just about to roll out a new Whois server! :) > > Shane > > > > > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer@denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 From owner-ietf-whois Fri Jan 19 04:01:22 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA07495 for ietf-whois-bks; Fri, 19 Jan 2001 04:01:22 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07489 for ; Fri, 19 Jan 2001 04:01:21 -0800 (PST) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA05601; Fri, 19 Jan 2001 13:06:07 +0100 (CET) Date: Fri, 19 Jan 2001 13:06:07 +0100 (CET) From: Shane Kerr To: Jaap Akkerhuis cc: ietf-whois@imc.org Subject: Re: Minutes from San Diego In-Reply-To: <200101191133.MAA44146@bartok.sidn.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jaap, On Fri, 19 Jan 2001, Jaap Akkerhuis wrote: > I know a lot of queries from both ARIN and RIPE are people > doing data mining, and I suspect that this is true for all > other Whois registries as well. > > We don't like datamining on our whois server. It could get us in > conflict with the dutch privacy regulations. It is actually > something that RIPE should probably think about as well. I've heard > that some privacy advocates in the EU don't like any whois service > at all. Some kinds of data mining are worse than others. When we spot people mining for personal data, we block their queries and ask them to define the reason for their queries. When we spot people mining for network data, we usually ask them to download the full dataset or apply to mirror our database. Of course, you have probably noticed the "when we spot..." from the previous paragraph. The existing software does not automatically block people - it has to be done manually. The new version of our Whois server, currently in beta, tracks number of queries from a specific IP for either personal or network data, and limits them for given time periods. Continued abuse automatically disables access. It's not perfect, because it's based on IP's, and dial-up users or owners of blocks of data can bypass the blocks, but hopefully spotting the users who mine data in this fashion will be easier. I wonder about existing LDAP servers and their ability to do this kind of dynamic blocking. Hmm.... > Another datapoint. We do have more then 500K objects. As do we, I think by around two orders of magnitude. However, my hope is that a reasonable SQL database can scale this pretty easily. This should only be one or two more disk accesses per query. It may require quite a bit more RAM, but RAM is cheap, right? I wouldn't mind having an excuse to get a machine with more than a Gbyte or two of RAM. ;) Shane From owner-ietf-whois Fri Jan 19 04:17:19 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08667 for ietf-whois-bks; Fri, 19 Jan 2001 04:17:19 -0800 (PST) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08663 for ; Fri, 19 Jan 2001 04:17:17 -0800 (PST) Subject: Re: Re: Minutes from San Diego To: ietf-whois@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Marcos Sanz/Denic" Date: Fri, 19 Jan 2001 13:22:26 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 19.01.2001 13:23:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallo, > Can anyone running a domain Whois server report some load > statistics here? > > No problem. For .nl we don't have these nice mrtg graphs but do have > some figures. It is about 75000 a day, so doing the math, you'll > get less then 1 Hz average. But given that most lookups are during > working days, 3 Hz might do as well. I don;t have enough datapoints > on the moment. For .de I can report an average of 150 queries/min, with usual peaks of 400, and unusual peaks of 1000 (some people out there starting their domainname scanning tools). There is not any remarkable difference in load between working days or weekend. > We don't like datamining on our whois server. It could get us in > conflict with the dutch privacy regulations. It is actually something > that RIPE should probably think about as well. Indeed. Marcos Sanz (.de registry) From owner-ietf-whois Fri Jan 19 04:52:29 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA09848 for ietf-whois-bks; Fri, 19 Jan 2001 04:52:29 -0800 (PST) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09844 for ; Fri, 19 Jan 2001 04:52:27 -0800 (PST) Subject: Re: Re: Minutes from San Diego To: "Sabine Dolderer/Denic" Cc: ietf-whois@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Marcos Sanz/Denic" Date: Fri, 19 Jan 2001 13:57:33 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 19.01.2001 13:58:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oops, I did not see your post. Sorry! :-) From owner-ietf-whois Fri Jan 19 06:36:02 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA18369 for ietf-whois-bks; Fri, 19 Jan 2001 06:36:02 -0800 (PST) Received: from heron.verisign.com ([216.168.233.95]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18364 for ; Fri, 19 Jan 2001 06:36:01 -0800 (PST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA00476; Fri, 19 Jan 2001 09:30:52 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jan 2001 09:36:13 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Shane Kerr'" , Jaap Akkerhuis Cc: ietf-whois@imc.org Subject: RE: Minutes from San Diego Date: Fri, 19 Jan 2001 09:36:11 -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-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As another query rate data point, the VeriSign-GRS whois servers (which provide domain name and associated data lookup services) handle approximately 30 million queries per day. Doing the math yields these approximate query rates per hour, minute, and second averaged over a 24-hour period: 1,250,000 queries/hour 20,833 queries/minute 347 queries/second I don't have data handy describing peak loads. From owner-ietf-whois Fri Jan 19 07:11:47 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19168 for ietf-whois-bks; Fri, 19 Jan 2001 07:11:47 -0800 (PST) Received: from tyholt.uninett.no (IDENT:root@tyholt.uninett.no [158.38.60.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19163 for ; Fri, 19 Jan 2001 07:11:45 -0800 (PST) Received: from sverresborg.uninett.no (IDENT:root@sverresborg.uninett.no [158.38.60.92]) by tyholt.uninett.no (8.11.1/8.11.1) with ESMTP id f0JFHWU13743; Fri, 19 Jan 2001 16:17:32 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.10.1/8.10.1) id f0JFGH011416; Fri, 19 Jan 2001 16:16:17 +0100 Date: Fri, 19 Jan 2001 16:16:17 +0100 From: Stig Venaas To: Shane Kerr Cc: Jaap Akkerhuis , ietf-whois@imc.org Subject: Re: Minutes from San Diego Message-ID: <20010119161617.A11407@sverresborg.uninett.no> References: <200101191133.MAA44146@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from shane@ripe.net on Fri, Jan 19, 2001 at 01:06:07PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 19, 2001 at 01:06:07PM +0100, Shane Kerr wrote: > Of course, you have probably noticed the "when we spot..." from the > previous paragraph. The existing software does not automatically block > people - it has to be done manually. The new version of our Whois > server, currently in beta, tracks number of queries from a specific IP > for either personal or network data, and limits them for given time > periods. Continued abuse automatically disables access. It's not > perfect, because it's based on IP's, and dial-up users or owners of > blocks of data can bypass the blocks, but hopefully spotting the users > who mine data in this fashion will be easier. This is what NORID (the Norwegian registry) does in it's Whois server as well. > I wonder about existing LDAP servers and their ability to do this kind > of dynamic blocking. Hmm.... We (well, NORID) plan to put the Whois data in an LDAP server, this is one of the requirements though. We might try to implement this in Open- LDAP. I think LDAP might be a good alternative, but we should probably write up requirements first of all. Stig From owner-ietf-whois Fri Jan 19 07:59:26 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26510 for ietf-whois-bks; Fri, 19 Jan 2001 07:59:26 -0800 (PST) Received: from h236.s254.netsol.com (h236.s254.netsol.com [216.168.254.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26505 for ; Fri, 19 Jan 2001 07:59:25 -0800 (PST) Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f0JFwF208024; Fri, 19 Jan 2001 10:58:15 -0500 (EST) Date: Fri, 19 Jan 2001 10:58:09 -0500 From: Mark Kosters To: Stig Venaas Cc: Shane Kerr , Jaap Akkerhuis , ietf-whois@imc.org Subject: Re: Minutes from San Diego Message-ID: <20010119105809.D7375@slam.admin.cto.netsol.com> References: <200101191133.MAA44146@bartok.sidn.nl> <20010119161617.A11407@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010119161617.A11407@sverresborg.uninett.no>; from Stig.Venaas@uninett.no on Fri, Jan 19, 2001 at 04:16:17PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: LDAP is one of the things we are experimenting with as well. We have tuned our software and can handle loads that are similar to the NSI registry. If you want, look at http://www.ldap.research.netsol.com/. We just recently announced the availability of a public domain whois -> ldap gateway for other registrars to want experiment with us but don't want to build a backend interface right away. We also have included a demo of access control (look at the different attributes that are displayed for a query issued by an anonymous user, an attorney, or the tech contact for a domain). Personally, I torn with LDAP. It has all this crufty X.500 stuff that it has to deal with. It would be much nicer to have a textual protocol that is xml based or even tagged as attribute/value pairs. On the other hand, LDAP offers some really nice features like ACL's, automatic navigation (via v3 referrals), structured attributes, and deployed LDAP clients on the desktop. IMHO, ACLs will be one of the things registries will need to confront to deal with the balance of privacy vs operational vs attorney issues. Mark On Fri, Jan 19, 2001 at 04:16:17PM +0100, Stig Venaas wrote: > We (well, NORID) plan to put the Whois data in an LDAP server, this is > one of the requirements though. We might try to implement this in Open- > LDAP. > > I think LDAP might be a good alternative, but we should probably write > up requirements first of all. > > Stig -- Mark Kosters markk@netsol.com Verisign Applied Research PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 From owner-ietf-whois Sun Jan 21 21:19:10 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA22985 for ietf-whois-bks; Sun, 21 Jan 2001 21:19:10 -0800 (PST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22981 for ; Sun, 21 Jan 2001 21:19:08 -0800 (PST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id PAA16241 for ; Mon, 22 Jan 2001 15:24:58 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma016237; Mon, 22 Jan 01 15:24:43 +1000 Date: Mon, 22 Jan 2001 15:24:44 +1000 (EST) From: Bruce Campbell X-Sender: bc@julubu.staff.apnic.net To: ietf-whois@imc.org Subject: Re: Minutes from San Diego In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 19 Jan 2001, Shane Kerr wrote: shane> the RIPE statistics page: shane> shane> http://www.ripe.net/ripencc/pub-services/db/mrtg/noofqueries/noofqueries.html shane> shane> You can see we get between 400 and 500 queries per minute, around 7 or 8 shane> queries/second (or as I like to say, 7 or 8 Hz). shane> shane> >From the ARIN VI engineering status report they report over 13 shane> queries/sec in September 2000. APNIC is currently (so far this year) averaging slightly over 2/sec for overall queries, higher during busy periods. At the standard rate of growth, this will probably be exceeding the current box/code combination by August (by which time we should be running new code). shane> I know a lot of queries from both ARIN and RIPE are people doing data shane> mining, and I suspect that this is true for all other Whois registries shane> as well. We may want to split any work on new and improved data shane> distribution techniques into looking at ways for both single and shane> aggregate lookups. The APNIC whois server has code to automatically deny access to people based on the standard 'leaky bucket' method (exceed certain number of queries per hour, no access until the attempted query rate dies down), but this is currently not active. shane> And to think, we're just about to roll out a new Whois server! :) Heh. -- Bruce Campbell +61-7-3367-0490 Systems Administrator Regional Internet Registry Asia Pacific Network Information Centre For the Asia Pacific Region Unix means never having to live hand-to-mouse. From owner-ietf-whois Mon Jan 22 09:33:40 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02982 for ietf-whois-bks; Mon, 22 Jan 2001 09:33:40 -0800 (PST) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02978 for ; Mon, 22 Jan 2001 09:33:39 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14Kkvw-0008Vo-00 for ietf-whois@imc.org; Mon, 22 Jan 2001 12:39:12 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Mon, 22 Jan 2001 12:39:12 -0500 Date: Mon, 22 Jan 2001 12:39:12 -0500 From: George Belotsky To: ietf-whois@imc.org Subject: New Standard for Whois Message-ID: <20010122123912.B15543@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, All. The RRP group has made quite a bit of progress on a generic protocol for Registry-Registrar communication. It would save a lot of duplicated effort if the Whois and RRP protocols could be merged into a single standard. Registries, Registrars, and end users would then have to contend with a single protocol, instead of two diverging ones. At the most fundamental level, both Whois and RRP provide a view into the the repository of information associated with a domain name. A sufficiently rich protocol would allow for these views to be finely adjusted. In addition, it would be possible for other views to emerge, as necessity dictates. Implementation effort, number of bugs, testing and troubleshooting should all be positively affected by having only a single protocol to deal with. This would surely benefit everyone. ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Mon Jan 22 15:06:50 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18374 for ietf-whois-bks; Mon, 22 Jan 2001 15:06:50 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18366 for ; Mon, 22 Jan 2001 15:06:45 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0MNBZn03650; Mon, 22 Jan 2001 18:11:35 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101222311.f0MNBZn03650@nic-naa.net> To: George Belotsky cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Mon, 22 Jan 2001 14:15:11 EST." <20010122141511.C24633@register.com> Date: Mon, 22 Jan 2001 18:11:34 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: George, I brought this up during the BoF in San Diego, if only because I'd spent the last half of the previous week in Munich with the data commissioners from Berlin and Schleswig-Holstein ... Jaap made much the same point in the ietf-whois list w.r.t. the Dutch commissioners in his mail of Jan 19. Whois (as we know it, aka the absurdly underspecified thingee on port 43) if used correctly, repurposes and adds 3rd-party recipients to registrant data, without notice or consent of the registrant. As you note, RRP and Whois both provide views into repositories of data associated with a transaction, however, the interests of registrants (and their associated jurisdictions) and the interests of registrars (and their competitive business models, and eventual liquidators, ala toysmart's) and the interests of the registries (and their competitive business models, and eventual successors), aren't trivially reduced to some sensible service model. I wouldn't assume that the views are equivalent, or the scope of repository examination (temporal and spatial), or the underlying data, or even the basic original transaction. Maybe there is just one type of "original transaction", but I suspect legacy, transfer, bulk and so forth will have some property which distinguishes them from transactions in which the role of the registrar is minimal. I'm certain that the underlying data isn't equivalent, given the repurpose and recipient (marketers, law enforcement, original jurisdiction) aspects. I'm open on the unified vs disjoint model for repository examination, and examination ordering. Views just revisits the purpose and recipient issue, modified by the view construction policy. One of these two activites is critical infrastructure, the other is not. One of these two has a hard implementation date, as Ed mentioned, and the other does not, or has a schedule which requires ICANN's participation, if not other complications. Cheers, Eric From owner-ietf-whois Mon Jan 22 22:31:15 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA26841 for ietf-whois-bks; Mon, 22 Jan 2001 22:31:15 -0800 (PST) Received: from tyholt.uninett.no (IDENT:root@tyholt.uninett.no [158.38.60.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26836 for ; Mon, 22 Jan 2001 22:31:12 -0800 (PST) Received: from sverresborg.uninett.no (IDENT:root@sverresborg.uninett.no [158.38.60.92]) by tyholt.uninett.no (8.11.1/8.11.1) with ESMTP id f0N6bDU10926; Tue, 23 Jan 2001 07:37:13 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.10.1/8.10.1) id f0N6ZsN20357; Tue, 23 Jan 2001 07:35:54 +0100 Date: Tue, 23 Jan 2001 07:35:53 +0100 From: Stig Venaas To: Eric Brunner-Williams in Portland Maine Cc: George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010123073553.A20344@sverresborg.uninett.no> References: <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200101222311.f0MNBZn03650@nic-naa.net>; from brunner@nic-naa.net on Mon, Jan 22, 2001 at 06:11:34PM -0500 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jan 22, 2001 at 06:11:34PM -0500, Eric Brunner-Williams in Portland Maine wrote: > I wouldn't assume that the views are equivalent, or the scope of repository > examination (temporal and spatial), or the underlying data, or even the > basic original transaction. Maybe there is just one type of "original > transaction", but I suspect legacy, transfer, bulk and so forth will have > some property which distinguishes them from transactions in which the role > of the registrar is minimal. I'm certain that the underlying data isn't > equivalent, given the repurpose and recipient (marketers, law enforcement, > original jurisdiction) aspects. I'm open on the unified vs disjoint model > for repository examination, and examination ordering. Views just revisits > the purpose and recipient issue, modified by the view construction policy. I think one should consider merging the two but as you say the uses are a bit different. One main difference is that whois must be able to handle many queries per second and data is only read. I know this is obvious, but it may restrict our choices. > One of these two activites is critical infrastructure, the other is not. > > One of these two has a hard implementation date, as Ed mentioned, and the > other does not, or has a schedule which requires ICANN's participation, > if not other complications. It might be best to not disturb this work too much, but rather see if there are parts that can be reused, if it can be simplified for whois etc. Stig From owner-ietf-whois Tue Jan 23 08:10:29 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26254 for ietf-whois-bks; Tue, 23 Jan 2001 08:10:29 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26248 for ; Tue, 23 Jan 2001 08:10:25 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.47]) by ogma.cisco.com (Postfix) with ESMTP id 1998BCE; Tue, 23 Jan 2001 17:16:03 +0100 (MET) Received: from [193.0.5.169] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA08054; Tue, 23 Jan 2001 17:15:58 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@193.0.5.169 Message-Id: In-Reply-To: <20010122123912.B15543@register.com> References: <20010122123912.B15543@register.com> Date: Tue, 23 Jan 2001 17:11:54 +0100 To: George Belotsky , ietf-whois@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: New Standard for Whois Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12.39 -0500 01-01-22, George Belotsky wrote: >It would save a lot of duplicated effort if the Whois and RRP >protocols could be merged into a single standard. Whois is a request/response protocol, and I don't see how such a protocol can be used for RRP things. Patrik -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-whois Tue Jan 23 08:26:42 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA26899 for ietf-whois-bks; Tue, 23 Jan 2001 08:26:42 -0800 (PST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26894 for ; Tue, 23 Jan 2001 08:26:40 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14L6Mc-0001eI-00; Tue, 23 Jan 2001 11:32:10 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Tue, 23 Jan 2001 11:32:09 -0500 Date: Tue, 23 Jan 2001 11:32:09 -0500 From: George Belotsky To: Eric Brunner-Williams in Portland Maine Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010123113209.C24903@register.com> References: <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101222311.f0MNBZn03650@nic-naa.net>; from brunner@nic-naa.net on Mon, Jan 22, 2001 at 06:11:34PM -0500 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric: I realize the deadlines involved, but it is also important to understand that the decisions made now will affect many people for years to come. It is not by accident that most of the great achievements in modern times involved the discovery of some unifying principle. The process of unification allows more general constructs to emerge, and these constructs ultimately prove more practically useful than a fragmented view. Deadline pressure is today's universal disease -- I am not aware of any recent undertaking that has been given a sufficient amount of time (or money, for that matter) to be properly completed. Even in such an environment, however, calm and steadfast respect for the fundamental nature of the task at hand is the only thing that can assure success. The loss of the Space Shuttle Challenger readily comes to mind as an example of what happens when fundamental nature is ignored. As Richard Feynman said, nature cannot be fooled. A looming deadline is not a reason to try something dangerous. In many cases, however, a little thought can safely accomodate a deadline. The RRP-Whois unification is one such case. Already, the RRP is being designed to be an extensible protocol. Given that the Whois deadline is still far away, all that would be needed from the RRP group is to recognize that there will be one protocol, and leave enough hooks so that the Whois part can eventually be built. The small effort required to unify the two protocols now will save a great deal of effort in the future. On Mon, Jan 22, 2001 at 06:11:34PM -0500, Eric Brunner-Williams in Portland Maine wrote: > George, > > I brought this up during the BoF in San Diego, if only because I'd spent > the last half of the previous week in Munich with the data commissioners > from Berlin and Schleswig-Holstein ... Jaap made much the same point in > the ietf-whois list w.r.t. the Dutch commissioners in his mail of Jan 19. > > Whois (as we know it, aka the absurdly underspecified thingee on port 43) > if used correctly, repurposes and adds 3rd-party recipients to registrant > data, without notice or consent of the registrant. > > As you note, RRP and Whois both provide views into repositories of data > associated with a transaction, however, the interests of registrants (and > their associated jurisdictions) and the interests of registrars (and their > competitive business models, and eventual liquidators, ala toysmart's) and > the interests of the registries (and their competitive business models, and > eventual successors), aren't trivially reduced to some sensible service model. > > I wouldn't assume that the views are equivalent, or the scope of repository > examination (temporal and spatial), or the underlying data, or even the > basic original transaction. Maybe there is just one type of "original > transaction", but I suspect legacy, transfer, bulk and so forth will have > some property which distinguishes them from transactions in which the role > of the registrar is minimal. I'm certain that the underlying data isn't > equivalent, given the repurpose and recipient (marketers, law enforcement, > original jurisdiction) aspects. I'm open on the unified vs disjoint model > for repository examination, and examination ordering. Views just revisits > the purpose and recipient issue, modified by the view construction policy. > > One of these two activites is critical infrastructure, the other is not. > > One of these two has a hard implementation date, as Ed mentioned, and the > other does not, or has a schedule which requires ICANN's participation, > if not other complications. > > Cheers, > Eric -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Tue Jan 23 08:39:10 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27749 for ietf-whois-bks; Tue, 23 Jan 2001 08:39:10 -0800 (PST) Received: from h236.s254.netsol.com (h236.s254.netsol.com [216.168.254.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27745 for ; Tue, 23 Jan 2001 08:39:08 -0800 (PST) Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f0NGWSs07112; Tue, 23 Jan 2001 11:32:28 -0500 (EST) Date: Tue, 23 Jan 2001 11:32:22 -0500 From: Mark Kosters To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: George Belotsky , ietf-whois@imc.org Subject: Re: New Standard for Whois Message-ID: <20010123113222.N3446@slam.admin.cto.netsol.com> References: <20010122123912.B15543@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: ; from paf@cisco.com on Tue, Jan 23, 2001 at 05:11:54PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jan 23, 2001 at 05:11:54PM +0100, Patrik Fältström wrote: > At 12.39 -0500 01-01-22, George Belotsky wrote: > >It would save a lot of duplicated effort if the Whois and RRP > >protocols could be merged into a single standard. > > Whois is a request/response protocol, and I don't see how such a > protocol can be used for RRP things. I strongly agree with Patrick. One needs to separate the provisioning protocol that is used by a small community of users from the generalized lookup protocol that is available to a much larger community of users. They serve different functions and hence should not be jointly encumbered by the different requirements that they individually may have. Mark -- Mark Kosters markk@netsol.com Verisign Applied Research PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 From owner-ietf-whois Tue Jan 23 08:39:11 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27760 for ietf-whois-bks; Tue, 23 Jan 2001 08:39:11 -0800 (PST) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27751 for ; Tue, 23 Jan 2001 08:39:10 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14L6Yl-0002ve-00; Tue, 23 Jan 2001 11:44:43 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Tue, 23 Jan 2001 11:44:42 -0500 Date: Tue, 23 Jan 2001 11:44:42 -0500 From: George Belotsky To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: ietf-whois@imc.org Subject: Re: New Standard for Whois Message-ID: <20010123114442.D24903@register.com> References: <20010122123912.B15543@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from paf@cisco.com on Tue, Jan 23, 2001 at 05:11:54PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patric: The issues are actually not too difficult. The idea is to develop a new protocol, while maintaining backwards compatibility. If the Whois stays on Port 43, backwards compatibility is maintained by the following approach. 1. Accept a connection. 2. Parse the result. If XML has been received, go to step 4. 3. Not XML: as per existing Whois standard, return the result and close the connection. 4. XML has been received: must be the new protocol. Maintain the connection, and use the RRP. Access will probably be restricted, and it may not be possible to modify objects. George. On Tue, Jan 23, 2001 at 05:11:54PM +0100, Patrik Fältström wrote: > At 12.39 -0500 01-01-22, George Belotsky wrote: > >It would save a lot of duplicated effort if the Whois and RRP > >protocols could be merged into a single standard. > > Whois is a request/response protocol, and I don't see how such a > protocol can be used for RRP things. > > Patrik > > > -- > Patrik Fältström Internet Engineering Task Force > Area Director, Applications Area http://www.ietf.org > Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 > PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Tue Jan 23 08:46:14 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27926 for ietf-whois-bks; Tue, 23 Jan 2001 08:46:14 -0800 (PST) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27922 for ; Tue, 23 Jan 2001 08:46:13 -0800 (PST) Received: from 207-172-150-201.s10.as11.anp.md.dialup.rcn.com ([207.172.150.201] helo=[207.172.148.194]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14L6fu-0005zY-00 ; Tue, 23 Jan 2001 11:52:07 -0500 X-Sender: lewis@192.94.214.100 Message-Id: In-Reply-To: <20010123113209.C24903@register.com> References: <200101222311.f0MNBZn03650@nic-naa.net>; from brunner@nic-naa.net on Mon, Jan 22, 2001 at 06:11:34PM -0500 <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jan 2001 11:49:13 -0500 To: George Belotsky From: Edward Lewis Subject: Re: Merging RRP and Whois Cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:32 AM -0500 1/23/01, George Belotsky wrote: >It is not by accident that most of the great achievements in modern >times involved the discovery of some unifying principle. The process >of unification allows more general constructs to emerge, and these >constructs ultimately prove more practically useful than a fragmented >view. OTOH, there have been fatal cases of mission creep. The OSI Session Protocol comes to mind. Also, in the defense industry, adding capability (night flying) sometimes incurs costs (extra weight) that thwart the original design (maneuverability/mobility). I don't doubt that unity is a good thing, but deadlines are real constraints that need to be factored into engineering decisions. >In many cases, however, a little thought can safely accomodate a >deadline. The RRP-Whois unification is one such case. Already, the >RRP is being designed to be an extensible protocol. Given that the >Whois deadline is still far away, all that would be needed from the >RRP group is to recognize that there will be one protocol, and leave >enough hooks so that the Whois part can eventually be built. I think this is already addressed in the proposed charter: # The initial specification will allow multiple registrars to register and # maintain domain names within multiple Top Level Domains (TLDs). Subsequent # versions of the specification will extend the protocol to exchange other # information needed to organize the Internet, such as IP address allocations. # The specification should be flexible enough to support the different # operational models of registries. The specification should allow extension # to support other registration data, such as address allocation and contact # information. (Eagle-eyed observers may notice a new sentence in there: "Subsequent versions..." This was added to an update sent to Patrik this morning - in case questions of what was meant by "initial specification.") Note that the charter does not mention Whois by name - there has been no discussion up to now about a merging of Whois and RRP. Is there a copy of the Whois charter available? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. From owner-ietf-whois Tue Jan 23 08:45:12 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27890 for ietf-whois-bks; Tue, 23 Jan 2001 08:45:12 -0800 (PST) Received: from roam.psg.com (dhcp70.ripemtg.ripe.net [193.0.4.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27883 for ; Tue, 23 Jan 2001 08:45:10 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14L6eq-0001m5-00; Tue, 23 Jan 2001 17:51:00 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: George Belotsky Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , ietf-whois@imc.org Subject: Re: New Standard for Whois References: <20010122123912.B15543@register.com> <20010123114442.D24903@register.com> Message-Id: Date: Tue, 23 Jan 2001 17:51:00 +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > If the Whois stays on Port 43, backwards compatibility is maintained > by the following approach. > > 1. Accept a connection. > 2. Parse the result. If XML has been received, go to step 4. > 3. Not XML: as per existing Whois standard, return the result and > close the connection. > 4. XML has been received: must be the new protocol. Maintain the > connection, and use the RRP. Access will probably be > restricted, and it may not be possible to modify objects. what if mirjam and i have an existing application running over whois/43 that uses xml? randy From owner-ietf-whois Tue Jan 23 08:48:39 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA28057 for ietf-whois-bks; Tue, 23 Jan 2001 08:48:39 -0800 (PST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28052 for ; Tue, 23 Jan 2001 08:48:37 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.39.209]) by mail.i-dns.net (Postfix) with SMTP id 3344FFFC09; Wed, 24 Jan 2001 00:54:35 +0800 (SGT) Message-ID: <016401c0855c$fb401420$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "George Belotsky" , "Eric Brunner-Williams in Portland Maine" Cc: , References: <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> <20010123113209.C24903@register.com> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 00:53:12 +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 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I like to disagree with merging RRP and WHOIS. I think it is a mistake to merge the two because basically they are designed to solve different set of problems. Yes, they are related in the sense that they deals with Domain Names but the similarity ends there. RRP (or ProReg) is primarly designed in a enviroment where there is multi-tier tree model. The registrant will send their registration at the bottom to their reseller, which will then send the registration upwards to the next level reseller etc until it reaches the registry. In WHOIS, the model is more top down. The queries goes to the registry first and then traverse down the tree. In fact, the referer queries may not even be top-down and may goes side-ways etc. Ideally, ProReg should be generic enough without been tied down to just purely Domain Names Registration. There should be generic where by any multi-tier registration system could use. Our current implementation of RFC2832 has been extended to handle objects beyond Domain Names. What is important to specify at the ProReg is the transcation layer which allows audit and roll-back. On the other hand, WHOIS is bascically lookup system. Transcation in this case is not important and in fact, I wouldnt want to leave an audit trail of WHOIS. WHOIS have also a different set of problems to solve, such as bulk lookup. -James Seng ----- Original Message ----- From: "George Belotsky" To: "Eric Brunner-Williams in Portland Maine" Cc: ; Sent: Wednesday, January 24, 2001 12:32 AM Subject: Re: Merging RRP and Whois > Eric: > > I realize the deadlines involved, but it is also important to > understand that the decisions made now will affect many people for > years to come. > > It is not by accident that most of the great achievements in modern > times involved the discovery of some unifying principle. The process > of unification allows more general constructs to emerge, and these > constructs ultimately prove more practically useful than a fragmented > view. > > Deadline pressure is today's universal disease -- I am not aware of > any recent undertaking that has been given a sufficient amount of time > (or money, for that matter) to be properly completed. Even in such an > environment, however, calm and steadfast respect for the fundamental > nature of the task at hand is the only thing that can assure success. > > The loss of the Space Shuttle Challenger readily comes to mind as an > example of what happens when fundamental nature is ignored. As > Richard Feynman said, nature cannot be fooled. A looming deadline is > not a reason to try something dangerous. > > In many cases, however, a little thought can safely accomodate a > deadline. The RRP-Whois unification is one such case. Already, the > RRP is being designed to be an extensible protocol. Given that the > Whois deadline is still far away, all that would be needed from the > RRP group is to recognize that there will be one protocol, and leave > enough hooks so that the Whois part can eventually be built. > > The small effort required to unify the two protocols now will save a > great deal of effort in the future. > > On Mon, Jan 22, 2001 at 06:11:34PM -0500, Eric Brunner-Williams in Portland Maine wrote: > > George, > > > > I brought this up during the BoF in San Diego, if only because I'd spent > > the last half of the previous week in Munich with the data commissioners > > from Berlin and Schleswig-Holstein ... Jaap made much the same point in > > the ietf-whois list w.r.t. the Dutch commissioners in his mail of Jan 19. > > > > Whois (as we know it, aka the absurdly underspecified thingee on port 43) > > if used correctly, repurposes and adds 3rd-party recipients to registrant > > data, without notice or consent of the registrant. > > > > As you note, RRP and Whois both provide views into repositories of data > > associated with a transaction, however, the interests of registrants (and > > their associated jurisdictions) and the interests of registrars (and their > > competitive business models, and eventual liquidators, ala toysmart's) and > > the interests of the registries (and their competitive business models, and > > eventual successors), aren't trivially reduced to some sensible service model. > > > > I wouldn't assume that the views are equivalent, or the scope of repository > > examination (temporal and spatial), or the underlying data, or even the > > basic original transaction. Maybe there is just one type of "original > > transaction", but I suspect legacy, transfer, bulk and so forth will have > > some property which distinguishes them from transactions in which the role > > of the registrar is minimal. I'm certain that the underlying data isn't > > equivalent, given the repurpose and recipient (marketers, law enforcement, > > original jurisdiction) aspects. I'm open on the unified vs disjoint model > > for repository examination, and examination ordering. Views just revisits > > the purpose and recipient issue, modified by the view construction policy. > > > > One of these two activites is critical infrastructure, the other is not. > > > > One of these two has a hard implementation date, as Ed mentioned, and the > > other does not, or has a schedule which requires ICANN's participation, > > if not other complications. > > > > Cheers, > > Eric > > -- > ----------------------------- > George Belotsky > Senior Software Architect > Register.com, inc. > george@register.com > 212-798-9127 (phone) > 212-798-9876 (fax) From owner-ietf-whois Tue Jan 23 09:36:31 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01089 for ietf-whois-bks; Tue, 23 Jan 2001 09:36:31 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01083 for ; Tue, 23 Jan 2001 09:36:29 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NHfUn05975; Tue, 23 Jan 2001 12:41:30 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101231741.f0NHfUn05975@nic-naa.net> To: George Belotsky cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 11:32:09 EST." <20010123113209.C24903@register.com> Date: Tue, 23 Jan 2001 12:41:30 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: George, The decisions made now will affect rrp implementors _now_. One of the failings of "extensibility" (a token periodically emitted by bits of the W3C) is its lack of self-description. What is being extended? A schema? A state machine? An access control mechanism? Reference to rockets, and scientists, living or deceased, are not sufficiently specific. Since the specifics of privacy/data protection are fundamentally scoped (temporally as well as spatially) and hence irreconcillable with scope- free universalism(s), let alone any other actual property of a rrp or a whois-successor protocol, please accept my "non-hum" to the suggestion that A wait on B, etc. Eric From owner-ietf-whois Tue Jan 23 10:13:28 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04367 for ietf-whois-bks; Tue, 23 Jan 2001 10:13:28 -0800 (PST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04362 for ; Tue, 23 Jan 2001 10:13:26 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14L81v-0003Cp-00; Tue, 23 Jan 2001 13:18:55 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Tue, 23 Jan 2001 13:18:55 -0500 Date: Tue, 23 Jan 2001 13:18:55 -0500 From: George Belotsky To: Eric Brunner-Williams in Portland Maine Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010123131855.E24903@register.com> References: <20010123113209.C24903@register.com> <200101231741.f0NHfUn05975@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101231741.f0NHfUn05975@nic-naa.net>; from brunner@nic-naa.net on Tue, Jan 23, 2001 at 12:41:30PM -0500 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric: The notion of "specific details" is no less general than "extensibility". If the "sufficiently specific" material was already known, there would be no need to discuss designing a new protocol. In the absence of such a priori knowledge, it becomes necessary to seek out analogous situations to guide oneself towards the required specifics. These specifics are the desired end result, not the initial starting point. It is possible to make fine distinctions in virtually any case. Experience generally shows, however, that a unifying approach is both simpler and more useful. There is absolutely no need here to reconcile the specifics of privacy and data protection with scope-free universalism. The Whois data is universally accessible, but restricted in scope. In operating systems, for example, there is a huge range of access permissions from the superuser to a minimally privileged user, sometimes even an unauthenticated guest user. Authentication and restricted access are already parts of the requirement document for this protocol. There is no reason why there cannot be a 'guest user' with maximally restricted permissions. George. On Tue, Jan 23, 2001 at 12:41:30PM -0500, Eric Brunner-Williams in Portland Maine wrote: > George, > > The decisions made now will affect rrp implementors _now_. > > One of the failings of "extensibility" (a token periodically emitted > by bits of the W3C) is its lack of self-description. What is being > extended? A schema? A state machine? An access control mechanism? > > Reference to rockets, and scientists, living or deceased, are not > sufficiently specific. > > Since the specifics of privacy/data protection are fundamentally > scoped (temporally as well as spatially) and hence irreconcillable > with scope- free universalism(s), let alone any other actual property > of a rrp or a whois-successor protocol, please accept my "non-hum" > to the suggestion that A wait on B, etc. > > Eric -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Tue Jan 23 11:55:48 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA09762 for ietf-whois-bks; Tue, 23 Jan 2001 11:55:48 -0800 (PST) Received: from bureau.sidn.nl (bureau.domeinnaam-jurisprudentie.nl [193.176.144.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09757 for ; Tue, 23 Jan 2001 11:55:43 -0800 (PST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id VAA18032; Tue, 23 Jan 2001 21:01:51 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id VAA65853; Tue, 23 Jan 2001 21:01:39 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101232001.VAA65853@bartok.sidn.nl> To: Edward Lewis cc: George Belotsky , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-reply-to: Your message of Tue, 23 Jan 2001 11:49:13 -0500. Date: Tue, 23 Jan 2001 21:01:39 +0100 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For the record, I also think that is a bad idea to merge the two. Foor quite a while I'm taken the position that the registration process tries to solve something quite different then a (public) whois is lookup service. Note that the charter does not mention Whois by name - there has been no discussion up to now about a merging of Whois and RRP. Is there a copy of the Whois charter available? I'm not sure wether once was actually made. According to the minutes, it was only decided that there should another BOF on the subject. jaap From owner-ietf-whois Tue Jan 23 12:25:28 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA10795 for ietf-whois-bks; Tue, 23 Jan 2001 12:25:28 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10791 for ; Tue, 23 Jan 2001 12:25:26 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NKUSn06310; Tue, 23 Jan 2001 15:30:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101232030.f0NKUSn06310@nic-naa.net> To: George Belotsky cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 13:18:55 EST." <20010123131855.E24903@register.com> Date: Tue, 23 Jan 2001 15:30:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: George, Wearing my rrp-implementor hat, I'm implementing bulk transport of user profiles[1], including a mechanism to support registry, registrar, and also promoted registrant "hints" for policed access mechanisms. I've got all the reliable, non-repudiation, secure hurdles to clear as well. Bulk is zero-or-more user profiles, aka "registrar-provided registrant data". One "hint" I think is required is the controlling jurisdiction(s) for any specific datum, registrant originated, registrar originated, or registry originated. My idea of "extensible" is that the rrp _might_ be useful to the ccTLD actors, or any other form of Registry-Registrar model ICANN posits in the near future, as my rrp-implementor hat reads "gTLD(s) first". Wearing my who-wannabe-implementor hat, I'm implementing non-bulk-query of user profiles, and transporting data with hints intact for use at some unspecified point where policy (or hints) are evaluated, isn't part of the less-than-pelucid-spec. In fact, what spec? For all I know, the lookup could point to registries having little or nothing to do with DNS registry data, e.g., Acxiom. Finding a schema, or bits of several, that can be recycled, isn't very hard, but is it interesting? I don't think the rest of the problem is as amenable to reuse or recycling or a unifying software architectural model as the schema question. Cheers, Eric --- [1] see also www.cpexchange.org, which has a bulk user profile exchange protocol with similar properties, created by the on-line marketers and ultra-large vertically integrated vendors. From owner-ietf-whois Tue Jan 23 12:33:50 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11111 for ietf-whois-bks; Tue, 23 Jan 2001 12:33:50 -0800 (PST) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11104 for ; Tue, 23 Jan 2001 12:33:45 -0800 (PST) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id f0NKco803021; Tue, 23 Jan 2001 12:38:50 -0800 Date: Tue, 23 Jan 2001 12:38:50 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: Eric Brunner-Williams in Portland Maine cc: George Belotsky , , Subject: Re: Merging RRP and Whois In-Reply-To: <200101222311.f0MNBZn03650@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My own feeling is different. I consider that any reasonable registrar-registry mechanism needs contain mechanisms by which one asks for the existing registration state. In the RRP case, that query mechanism is pretty much registrar asking/registry responding. And since we've got to leave the door open to IPv6 and other kinds of data, the data representation needs to be exensible. It seems to me that it is only a matter of using that extensibility to make that same mechanism work so that a client/customer may ask a status question of a registry or registrar. The larger issues to me are those of a) identification/authentication of the parties and b) authorization and privacy. I'd like to think that we could be clever enough to invent mechanisms that would handle both sitations - registrar as status querier and customer as status querier. It seems to me that much of the issue of authorization and privacy can be handled by having server implementations call out out policy servers much as we are starting to do for configuration, QoS, and capacity provisioning. My sense is that if one comes up with a well structured data representation for the queries and responses that one can come up with a policy definition structure that meshes. The biggest issue - that of identification/authentication of both the querier and the responder are, to my mind, the biggest ones. In the RRP situation we have a limited set of players making it possible to simply use sneakernet techniques to get id/auth data to the various participants. --karl-- From owner-ietf-whois Tue Jan 23 12:55:04 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11590 for ietf-whois-bks; Tue, 23 Jan 2001 12:55:04 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11586 for ; Tue, 23 Jan 2001 12:55:02 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NL02n06389; Tue, 23 Jan 2001 16:00:02 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101232100.f0NL02n06389@nic-naa.net> To: Karl Auerbach cc: Eric Brunner-Williams in Portland Maine , George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 12:38:50 PST." Date: Tue, 23 Jan 2001 16:00:02 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Karl, As I mentioned earlier, when used as intended, whois repurposes and redistributes registrant-originated data. It isn't "customer as status querier" (which I think means registrant) but non-registrant, e.g., Acxiom, or DoubleClick or, ... I understand, but don't share, the view that identification/authentication of both the querier and the responder are bigger issues than what our friends in Europe refreshingly refer to as "data self-determination". Failing over to a policy server, a la Shai Herzog's original paper, is a fine idea, but (presumably) is unnecessary within the ICANN scope of an RRP, where policy is reasonably finite and well-known. How useful it may be where the restriction on query initiators is removed ("public" whois) is TBD. I also agree that with only 67 or so ICANN approved Registrars, sneakernet is a viable trust model. Eric From owner-ietf-whois Tue Jan 23 13:11:11 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA11909 for ietf-whois-bks; Tue, 23 Jan 2001 13:11:11 -0800 (PST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11904 for ; Tue, 23 Jan 2001 13:11:08 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.39.163]) by mail.i-dns.net (Postfix) with SMTP id 936CDFFC01; Wed, 24 Jan 2001 05:17:07 +0800 (SGT) Message-ID: <028601c08581$a9baa230$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Karl Auerbach" , "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , "George Belotsky" , , References: <200101232100.f0NL02n06389@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 05:15:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Why is it that people here automatically assumed that RRP/WHOIS only serves Domain Names information? And what makes ICANN the default authority beyond IP and Names and that RRP/WHOIS is only used by the 80+ Registrars? IMHO, it is best we do not discuss nor constraint our design based on ICANN or any defined policy of any group in IETF. Organisation and Policy will change but Protocol will get stuck for a long time. -James Seng > As I mentioned earlier, when used as intended, whois repurposes and > redistributes registrant-originated data. It isn't "customer as status > querier" (which I think means registrant) but non-registrant, e.g., > Acxiom, or DoubleClick or, ... > > I understand, but don't share, the view that identification/authentication > of both the querier and the responder are bigger issues than what our > friends in Europe refreshingly refer to as "data self-determination". > > Failing over to a policy server, a la Shai Herzog's original paper, is a > fine idea, but (presumably) is unnecessary within the ICANN scope of an > RRP, where policy is reasonably finite and well-known. How useful it may > be where the restriction on query initiators is removed ("public" whois) > is TBD. > > I also agree that with only 67 or so ICANN approved Registrars, sneakernet > is a viable trust model. > > Eric From owner-ietf-whois Tue Jan 23 13:52:06 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12919 for ietf-whois-bks; Tue, 23 Jan 2001 13:52:06 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12914 for ; Tue, 23 Jan 2001 13:52:04 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NLv1n06510; Tue, 23 Jan 2001 16:57:01 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101232157.f0NLv1n06510@nic-naa.net> To: Eric Brunner-Williams in Portland Maine cc: Karl Auerbach , George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 16:00:02 EST." <200101232100.f0NL02n06389@nic-naa.net> Date: Tue, 23 Jan 2001 16:57:01 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James, > Why is it that people here automatically assumed that RRP/WHOIS only > serves Domain Names information? Are you suggesting that an RRP doesn't, or making a subset arguement? Who cares, other than extensibility-in-principle, about more junk than the necessary and sufficient minimum, viz dns data? I made the assumption as those are exactly the problems I'm trying to solve, if my state of mind is that interesting. > And what makes ICANN the default authority beyond IP and Names and that > RRP/WHOIS is only used by the 80+ Registrars? That set of registrars and registries is convienient to mention, frequently in less than complete awe. There are of course ccTLD registries and their own registrars. This is the same space we worked on at the SRS BoF in Orlando, and in mini-BoF at Minneapolis. Was there something else, other than several orders of magnitude difference in the number of endpoint identifiers, between the RRP and whois models, or the rather modest span of known policies in either model, which caught your attention? These were the sole motivations I gave for mentioning ICANN. If you've some other concern, I don't yet know what it is. Eric From owner-ietf-whois Tue Jan 23 14:50:20 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14237 for ietf-whois-bks; Tue, 23 Jan 2001 14:50:20 -0800 (PST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14232 for ; Tue, 23 Jan 2001 14:50:18 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.39.163]) by mail.i-dns.net (Postfix) with SMTP id BEC99FFC07; Wed, 24 Jan 2001 06:56:08 +0800 (SGT) Message-ID: <04cf01c0858f$7eed1ca0$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: "Karl Auerbach" , "George Belotsky" , , , References: <200101232157.f0NLv1n06510@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 06:54:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric, > > Why is it that people here automatically assumed that RRP/WHOIS only > > serves Domain Names information? > > Are you suggesting that an RRP doesn't, or making a subset arguement? No, but it is too early to make a presumation or to restrict it to Domain Names only. In fact, all discussion so far did suggest RRP to go beyond Domain Names. > Who cares, other than extensibility-in-principle, about more junk than > the necessary and sufficient minimum, viz dns data? I do. If ProReg turns out to be a protocol designed just for Domain Names, then ProReg is less useful. One of the original discussion I have with various people to stop calling it RRP for the same reason because it should be a generic registration protocol, able to register objects beyond domain names. Beside, different registry have different policy, different fields in objects. Unifying all of them is a hopeless utopia dream. IMHO, it is probably better to define what is common stuff and let the rest of the registry define their own object schema. > I made the assumption as those are exactly the problems I'm trying > to solve, if my state of mind is that interesting. Your problem is only a subset of all the problems. > Was there something else, other than several orders of magnitude > difference in the number of endpoint identifiers, between the RRP > and whois models, or the rather modest span of known policies in > either model, which caught your attention? These were the sole > motivations I gave for mentioning ICANN. If you've some other concern, > I don't yet know what it is. I have no issues with ICANN wrt to IP and Names. They are charter to do that. But policy on those may change or even ICANN may not be around in a few years. Who knows? What we need is a protocol which is flexible enough to handle these changes. Beside, it is best that a technical group dont get involves in the higher level decision making process. Secondly, please think beyond DNS. There are other multi-tier model which could use ProReg such as CA/RA. Keywords system are also getting popular. And believe it or not, I know of one company which uses RRP for Email registration. And why stop there? Any registration you do today can use this in someway, e.g. Why not registration system for ID, driver license, passport? No, it is not crazy because I am involved in a project whereby I am using RRP which would really really stretch the meaning of registration. -James Seng From owner-ietf-whois Tue Jan 23 18:34:31 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19349 for ietf-whois-bks; Tue, 23 Jan 2001 18:34:31 -0800 (PST) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19345 for ; Tue, 23 Jan 2001 18:34:30 -0800 (PST) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id f0O2dWa03744; Tue, 23 Jan 2001 18:39:32 -0800 Date: Tue, 23 Jan 2001 18:39:32 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: James Seng/Personal cc: George Belotsky , Eric Brunner-Williams in Portland Maine , Subject: Re: Merging RRP and Whois In-Reply-To: <016401c0855c$fb401420$06272dd4@jamessonyvaio> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ... I wouldnt want to leave an audit trail of WHOIS. Privacy considerations may demand that such a trail be created - which, in turn, implies that before one may make an inquiry that one may have to provide an identifier - and perhaps be ready to back it up with some kind of authentication. Whois is a privacy balance - and so far all the equity stones have been piled on the requestors' end and not on the data-subjects' end. --karl-- From owner-ietf-whois Tue Jan 23 18:38:15 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19412 for ietf-whois-bks; Tue, 23 Jan 2001 18:38:15 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19405 for ; Tue, 23 Jan 2001 18:38:07 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0O2h2n07024; Tue, 23 Jan 2001 21:43:02 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101240243.f0O2h2n07024@nic-naa.net> To: "James Seng/Personal" cc: "Eric Brunner-Williams in Portland Maine" , "Karl Auerbach" , "George Belotsky" , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Wed, 24 Jan 2001 06:54:47 +0800." <04cf01c0858f$7eed1ca0$06272dd4@jamessonyvaio> Date: Tue, 23 Jan 2001 21:43:02 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James, Extensibility of schema(s) is a given, in fact, the idea of an inextensible protocol using XML is sort of funny. Unity is not a given, not merely due the differences in schemas, as one AD noted, the process models are not equivalent. Registration in arbitrary object identifier schemes which may share a property of hierarchical delegation is a fruitful field of research. To be fair, the same observation applies to self-labeled data and to labeled flows, which may share the properties of registrant data schemas. I don't expect an IETF WG charter to be quite that broad however, for either value of abstraction to the point of ... well, absurdity. (Again, to be fair, an IRTF WG charter is another matter, e.g., for labeled flows) Neither RRP nor Whois emerged from San Diego BoF with charters, and I haven't seen an announcement on ietf-announce concerning either, so I guess there is nothing wrong with your advocating a particular scoping, nor with George advocating merging, or Karl advocating ident and/or authorization over privacy, or out-calls to policy mavens. I'd like to keep the RRP-list scope closer to the SRS and RRP sense of scope, and keep the post-port-43 scope specific to some port other than 43, with a 43-like, but "improved", services. Eric From owner-ietf-whois Tue Jan 23 20:30:57 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22179 for ietf-whois-bks; Tue, 23 Jan 2001 20:30:57 -0800 (PST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22175 for ; Tue, 23 Jan 2001 20:30:54 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.39.225]) by mail.i-dns.net (Postfix) with SMTP id 65316FFC0D; Wed, 24 Jan 2001 12:36:44 +0800 (SGT) Message-ID: <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , "Karl Auerbach" , "George Belotsky" , , References: <200101240243.f0O2h2n07024@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 12:35:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric, Right. We are still probably doing scoping. However, I do want to remind everyone that if ProReg is nothing more than an improved SRS/RRP for ICANN-accredited registrar to Verisign, then IMHO we dont need this WG. SRS/RRP is so specific to Verisign design that I am not sure how useful it is to other Registries. If you are looking for an improved SRS/RRP, then Verisign can do it on their own with their registrars. In the same way, if result of this WG (if created), is not suitable for my absurd needs, I will move on design my own or modify it with my partners to suit our need. Other registries may refused to adopted SRS/RRP just because it is tailored to Verisign. I know quite a few Registries who has blantly refused to use it so as not to create an association altho there is no technical reason not to do so. Or they may use it and once again modify it to their own. Unfortunately, this means we end-up with variant of the basically same protocol but yet not exactly the same. That is interoperability nightmare. -James Seng > I'd like to keep the RRP-list scope closer to the SRS and RRP sense of > scope, and keep the post-port-43 scope specific to some port other than > 43, with a 43-like, but "improved", services. > > Eric From owner-ietf-whois Tue Jan 23 21:59:44 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25089 for ietf-whois-bks; Tue, 23 Jan 2001 21:59:44 -0800 (PST) Received: from roam.psg.com (dhcp70.ripemtg.ripe.net [193.0.4.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25083 for ; Tue, 23 Jan 2001 21:59:43 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LJ3Q-0002CG-00; Wed, 24 Jan 2001 07:05:12 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Karl Auerbach Cc: James Seng/Personal , George Belotsky , Eric Brunner-Williams in Portland Maine , Subject: Re: Merging RRP and Whois References: <016401c0855c$fb401420$06272dd4@jamessonyvaio> Message-Id: Date: Wed, 24 Jan 2001 07:05:12 +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Whois is a privacy balance no. whois is a very simple protocol on port 43. randy From owner-ietf-whois Wed Jan 24 00:13:44 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA15331 for ietf-whois-bks; Wed, 24 Jan 2001 00:13:44 -0800 (PST) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA15324 for ; Wed, 24 Jan 2001 00:13:43 -0800 (PST) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id f0O8I6704224; Wed, 24 Jan 2001 00:18:06 -0800 Date: Wed, 24 Jan 2001 00:18:06 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: Randy Bush cc: James Seng/Personal , George Belotsky , Eric Brunner-Williams in Portland Maine , Subject: Re: Merging RRP and Whois In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Whois is a privacy balance > > no. whois is a very simple protocol on port 43. Sure RFC 954 "whois" pretty much as "send a command" and maybe get an answer. But we are, I believe, talking about something rather evolved from that. There is an expressed need, particularly driven by trademark interests, for there to be a formalized way of digging through registration data, often with grep-like string matching operations, and with an increasing need for standardized formats so that it can be all done without humans reading the results. In addition, there is a pressure - driven by ICANN's contracts with the DNS registrars - to have a unified mechanism in which there would be a single service point-of-contact through which a single query operation would result in a result that is the merger of the results from any number of registrars. Moreover, there would be different classes of service rendered (i.e. some folks could do more exotic string searching) depending on whether one is a trademark practitioner (more access, higher query rate) or just one of us chickens (less access, lower query rate.) Considering that the data being scanned and delivered contains personally identifiable data, data that is frequently going to be used for an entirely distinct and different purpose than that for which the domain name registrant or IP address block delegee surrendered his/her information in the first place, we certainly do have a significant privacy concern to deal with. --karl-- From owner-ietf-whois Wed Jan 24 00:22:12 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA16274 for ietf-whois-bks; Wed, 24 Jan 2001 00:22:12 -0800 (PST) Received: from roam.psg.com (dhcp70.ripemtg.ripe.net [193.0.4.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16270 for ; Wed, 24 Jan 2001 00:22:11 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LLHr-0002PA-00; Wed, 24 Jan 2001 09:28:15 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Karl Auerbach Cc: James Seng/Personal , George Belotsky , Eric Brunner-Williams in Portland Maine , Subject: Re: Merging RRP and Whois References: Message-Id: Date: Wed, 24 Jan 2001 09:28:15 +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Sure RFC 954 "whois" pretty much as "send a command" and maybe get an > answer. But we are, I believe, talking about something rather evolved > from that. > > There is an expressed need, particularly driven by trademark interests, > .... there are a lot of applications with a lot of needs. the particular set of the domain name mega-industry is but one. like the others, it should be taken into account. but its needs should not dominate others'. this is the ietf, not icann or nsi. randy From owner-ietf-whois Wed Jan 24 02:12:58 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00561 for ietf-whois-bks; Wed, 24 Jan 2001 02:12:58 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA00547 for ; Wed, 24 Jan 2001 02:12:55 -0800 (PST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA11774; Wed, 24 Jan 2001 02:17:38 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f0OAHRh24294; Wed, 24 Jan 2001 02:17:27 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA19999; Wed, 24 Jan 2001 02:17:04 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 24 Jan 2001 10:38:18 +0100 To: Karl Auerbach , Randy Bush From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Merging RRP and Whois Cc: James Seng/Personal , George Belotsky , Eric Brunner-Williams in Portland Maine , Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 00.18 -0800 01-01-24, Karl Auerbach wrote: > > > Whois is a privacy balance >> >> no. whois is a very simple protocol on port 43. > >Sure RFC 954 "whois" pretty much as "send a command" and maybe get an >answer. But we are, I believe, talking about something rather evolved >from that. Well, what Randy sais is that what is in use on port 43 is also used for other applications that for "domain name issues" and changewi that will probably not be acceped by the IETF. If ICANN for some specific use cases have specific constraints on a function they need to provide, they should explicitly list those constraints, and then see if what is on port 43 (or LDAP or whatever) can be used or not. I would urge the group working on whois issues to differ between "what changes can be made to whatever is on port 43" and "what is needed in the application which ICANN have to implement". If ICANN publish the _requirements_ as for example an I-D, I am pretty sure that IETF can help with the evaluation of existing protocols and propose what ICANN can do. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-whois Wed Jan 24 06:10:26 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA18304 for ietf-whois-bks; Wed, 24 Jan 2001 06:10:26 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18295 for ; Wed, 24 Jan 2001 06:10:21 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0OEFJn08525; Wed, 24 Jan 2001 09:15:19 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101241415.f0OEFJn08525@nic-naa.net> To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= cc: Karl Auerbach , Randy Bush , James Seng/Personal , George Belotsky , Eric Brunner-Williams in Portland Maine , ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Wed, 24 Jan 2001 10:38:18 +0100." Date: Wed, 24 Jan 2001 09:15:19 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik, I'd the impression that the proposal to change the application running on port 43 was offered, and withdrawn upon strong non-hum, at the IETF49 BoF. Randy's note seemed like clean-up for the benefit of those not present that naive demultiplexing on port 43 was a non-starter. A distinct issue is what an application running on some other port might look like, which provided whois-like access to registration data in DNS registries. Yet another issue is what an application running on some other port might look like, which provides ICANN-specified access to ICANN-specified data in ICANN-specified DNS registries. I distinguish between the 2nd and 3rd possible reasons for this incantation of an ietf-whois list, because I know that ICANN-specified DNS registries are contractually obligated to specific conditions, and national DNS registries operate under distinct specific conditions. These differences may effect the level of (data security and data protection) service minimially, or maximally available to the group working on whois. A registry operator may seek to meet both the ICANN service requirements where applicable, and other requirements where applicable. Cheers, Eric From owner-ietf-whois Wed Jan 24 06:35:45 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA19542 for ietf-whois-bks; Wed, 24 Jan 2001 06:35:45 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19538 for ; Wed, 24 Jan 2001 06:35:43 -0800 (PST) Received: by sentry.gw.tislabs.com; id JAA15669; Wed, 24 Jan 2001 09:45:08 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma015659; Wed, 24 Jan 01 09:44:44 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> References: <200101240243.f0O2h2n07024@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jan 2001 09:34:32 -0500 To: "James Seng/Personal" From: Edward Lewis Subject: Re: Merging RRP and Whois Cc: "Eric Brunner-Williams in Portland Maine" , "Karl Auerbach" , "George Belotsky" , , Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:35 PM -0500 1/23/01, James Seng/Personal wrote: >Right. We are still probably doing scoping. However, I do want to remind >everyone that if ProReg is nothing more than an improved SRS/RRP for >ICANN-accredited registrar to Verisign, then IMHO we dont need this WG. Perhaps you should review the charter proposed for this group. (It's in the archive, I can send you a copy off-list if you want.) The charter is written to say that the results of the WG would be a generic protocol for registration information (domain names, IP addresses, etc.) but with a short term emphasis on domain names. >SRS/RRP is so specific to Verisign design that I am not sure how useful >it is to other Registries. If you are looking for an improved SRS/RRP, >then Verisign can do it on their own with their registrars. This is a "historical accident." The drafts leading up to the BOF were produced by Verisign, and although input was sought, none was forthcoming (again, prior to the BOF). Post-BOF, there have been lively discussions on the mailing list, with input coming from a number of ccTLDs and ICANN gTLDs. We are progressing on a requirements document that is intended to be the consensus of the group, not restricted to the original document as submitted by Verisign. The latest draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-06.txt As we are not a WG yet, it is listed as an individual submission - that of Scott Hollenbenck, a memeber of Verisign. To help reduce bias in the final result, the co-chairs (myself and Jaap Akerhuis) work for a non-registr* company and a ccTLD company respectively. >In the same way, if result of this WG (if created), is not suitable for >my absurd needs, I will move on design my own or modify it with my >partners to suit our need. Comments and additional text for the requirements document are welcome. I am hoping for an always wider field of input. >Other registries may refused to adopted SRS/RRP just because it is >tailored to Verisign. I know quite a few Registries who has blantly >refused to use it so as not to create an association altho there is no >technical reason not to do so. Or they may use it and once again modify >it to their own. > >Unfortunately, this means we end-up with variant of the basically same >protocol but yet not exactly the same. That is interoperability >nightmare. This is why this WG is under consideration - to avoid that "nightmare." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. From owner-ietf-whois Wed Jan 24 07:33:13 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24661 for ietf-whois-bks; Wed, 24 Jan 2001 07:33:13 -0800 (PST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24656 for ; Wed, 24 Jan 2001 07:33:11 -0800 (PST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0OFcIn08736; Wed, 24 Jan 2001 10:38:18 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101241538.f0OFcIn08736@nic-naa.net> To: James@Seng.cc cc: ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 18:39:32 PST." Date: Wed, 24 Jan 2001 10:38:18 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ... I wouldnt want to leave an audit trail of WHOIS. James, Could you please clarify this? Are you expressing: a query-originator's preference? a query-router's preference? a query-responder's preference? a queried-datum's preference? some other entitie's preference? Could you motivate/explain the prefernce(s)? Sent only to ietf-whois, despite the subject line and thread. TiA, Eric From owner-ietf-whois Wed Jan 24 07:53:46 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26524 for ietf-whois-bks; Wed, 24 Jan 2001 07:53:46 -0800 (PST) Received: from h236.s254.netsol.com (h236.s254.netsol.com [216.168.254.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26520 for ; Wed, 24 Jan 2001 07:53:45 -0800 (PST) Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f0OFnfM01370; Wed, 24 Jan 2001 10:49:41 -0500 (EST) Date: Wed, 24 Jan 2001 10:49:22 -0500 From: Mark Kosters To: Randy Bush Cc: Karl Auerbach , James Seng/Personal , George Belotsky , Eric Brunner-Williams in Portland Maine , ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124104922.D780@slam.admin.cto.netsol.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from randy@psg.com on Wed, Jan 24, 2001 at 09:28:15AM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Randy Do you think that domain name assignment and ip assignment info be required to be accessed via the same protocol? Or is this a preference since this was the way it used to work back in the InterNIC/RIPE/APNIC -> DDN NIC -> SRI NIC days? Mark On Wed, Jan 24, 2001 at 09:28:15AM +0100, Randy Bush wrote: > there are a lot of applications with a lot of needs. the particular set > of the domain name mega-industry is but one. like the others, it should > be taken into account. but its needs should not dominate others'. this > is the ietf, not icann or nsi. -- Mark Kosters markk@netsol.com Verisign Applied Research PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 From owner-ietf-whois Wed Jan 24 08:07:02 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA26897 for ietf-whois-bks; Wed, 24 Jan 2001 08:07:02 -0800 (PST) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26893 for ; Wed, 24 Jan 2001 08:07:00 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LSWd-00057p-00; Wed, 24 Jan 2001 11:11:59 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 11:11:58 -0500 Date: Wed, 24 Jan 2001 11:11:58 -0500 From: George Belotsky To: Edward Lewis Cc: James Seng/Personal , Eric Brunner-Williams in Portland Maine , Karl Auerbach , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124111158.J24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lewis@tislabs.com on Wed, Jan 24, 2001 at 09:34:32AM -0500 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It very important to keep in mind that a _protocol_ is being created here. A protocol's usefulness and longevity is dependent on how it adapts to future situations. Just solving today's immediate problem is not enough. Even with the assumption that everyone agrees to adopt the new protocol, the 'nightmare' scenario will nevertheless occur if multiple other protocols have to be developed to support the operation of the registered object repositories. There is a need to provide a consistent interface for registering, maintaining and viewing various entities. It is a historical accident that domain names are the first entity that requires this. We are indeed fortunate that many decisions about future uses do not need to be made right away. It is vital, however, that some thought be given to extensibility now, if the resulting protocol is to have longevity. There can be little doubt that a unified entity registration, view, search, etc. layer will eventually emerge. This layer will handle domain name registration, whois-like lookups, registration of other objects, etc. The alternative is a different protocol for registration of each object type , and a different protocol for whois-like lookups of objects of each type, etc., etc. Clearly a nightmare -- and enough people will eventually wake up. Our choice today is whether the protocol being developed here can evolve into the unified layer described above. If it can, then indeed this group will have done a great service to the Internet community. If it cannot, then we will all have to suffer yet another painful round of fragmentation, incompatibility, obsolescence and deprecation. On Wed, Jan 24, 2001 at 09:34:32AM -0500, Edward Lewis wrote: > At 11:35 PM -0500 1/23/01, James Seng/Personal wrote: > >Right. We are still probably doing scoping. However, I do want to remind > >everyone that if ProReg is nothing more than an improved SRS/RRP for > >ICANN-accredited registrar to Verisign, then IMHO we dont need this WG. > > Perhaps you should review the charter proposed for this group. (It's in > the archive, I can send you a copy off-list if you want.) The charter is > written to say that the results of the WG would be a generic protocol for > registration information (domain names, IP addresses, etc.) but with a > short term emphasis on domain names. > > >SRS/RRP is so specific to Verisign design that I am not sure how useful > >it is to other Registries. If you are looking for an improved SRS/RRP, > >then Verisign can do it on their own with their registrars. > > This is a "historical accident." The drafts leading up to the BOF were > produced by Verisign, and although input was sought, none was forthcoming > (again, prior to the BOF). Post-BOF, there have been lively discussions on > the mailing list, with input coming from a number of ccTLDs and ICANN > gTLDs. We are progressing on a requirements document that is intended to > be the consensus of the group, not restricted to the original document as > submitted by Verisign. > > The latest draft is: > http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-06.txt > As we are not a WG yet, it is listed as an individual submission - that of > Scott Hollenbenck, a memeber of Verisign. > > To help reduce bias in the final result, the co-chairs (myself and Jaap > Akerhuis) work for a non-registr* company and a ccTLD company respectively. > > >In the same way, if result of this WG (if created), is not suitable for > >my absurd needs, I will move on design my own or modify it with my > >par